Karpenter 트러블슈팅 — 비용과 안정성 두 마리 토끼 잡기안녕하세요, 저는 당근페이 인프라팀에서 Site Reliability Engineer로 일하고 있는 Yany라고 해요. 저희 팀은 당근페이의 인프라를 안정적으로 관리해요. 개발자들의 프로덕트 개발 속도를 향상하고, 동시에 비용도 최적화하죠.저희는 클러스터 오토스케일링 없이 ASG(AWS EC2 AutoScaling Group)로, 그리고 HorizontalPodAutoscaler 없이 클러스터를 관리하고 있었어요. 여기에는 몇 가지 문제가 있었어요:스케일 아웃 과정에서 네트워크에 여러 병목 지점이 생겼어요.클러스터 업데이트를 진행하면서 ASG마다 AMI를 업데이트해야 했고, 오토스케일링이 원활하지 못했어요.컴플라이언스 이슈로 인해 분리된 노드, 서브넷에서 동작해야 하는 워크로드가 증가하면서 ASG가 늘어나 관리 포인트가 증가하고 있었어요.새벽 시간대에 트래픽이 현저히 적은 것에 비해 리소스를 너무 많이 사용하고 있었어요.당근페이의 거래량과 유저 수가 급격히 증가하면서, 기존의 ASG 기반 인프라 운영 방식으로는 한계가 명확해졌어요. 이에 따라 더 유연하고 자동화된 클러스터 스케일링이 필요했고, 그 해답으로 Karpenter를 도입하게 되었어요.그 여정은 저희가 생각한 것만큼 마냥 쉽지만은 않았는데요. 이번 글에서는 그 트러블슈팅 과정을 구체적으로 소개해드리려고 해요. Karpenter 도입을 고민 중이시거나 더 효율적으로 사용할 방법을 찾고 계신다면, 이 글이 큰 도움이 되길 바라요.Karpenter란?Karpenter는 쿠버네티스 클러스터에서 파드의 수요에 맞춰 노드의 양을 조절하는 Cluster Autoscaling Operator에요. 여러 컴포넌트를 통해 원하는 규격의 노드를 생성하고, 생성된 노드의 생명주기를 관리하도록 도와줘요.출처: [https://karpenter.sh/]대표적인 기능은 아래와 같아요:ProvisioningPending 상태의 파드가 존재하면, 스케줄링을 통해 필요한 노드를 생성하여 해당 파드가 스케줄링될 수 있도록 해요.각 CSP(Cloud Service Provider, 저희의 경우 AWS가 여기에 해당해요.)에서 만든 NodeClass 구현체를 통해 인스턴스의 규격을 정해요.- AWS로 가정했을 때 AMI, Subnet, Storage, Security Group, Userdata 등 EC2 인스턴스 자체와 관련된 설정을 진행할 수 있어요.NodePool을 통해 기존 ASG처럼 목적별로 노드를 생성할 수 있어요.- 여러 타입의 인스턴스를 생성할 수 있어, Cluster Autoscaler (이하 CA)보다 훨씬 효율적으로 스케일링을 진행할 수 있어요.DisruptionDrift: NodeClass, NodePool이 바뀌면 Drift를 통해 노드들을 원하는 상태로 Sync할 수 있어요.Consolidation: 충분히 사용하고 있지 않은 노드를 삭제해서 최적화된 양의 리소스를 사용할 수 있어요.- SingleNodeConsolidation

도입 배경안녕하세요. 중고나라 DevOps 엔지니어 조상현, 김지헌입니다.복잡한 아키텍처를 개선하며, 자원 효율화를 위해 새롭게 도입한 Istio Ambient Mode에 대해 공유하려 합니다.중고나라는 회사의 성장과 함께 서비스 트래픽이 증가하면서 네트워크 관리의 중요성이 더욱 커졌습니다. 이를 해결하기 위해 Istio를 도입하여 서비스 메쉬를 구축했지만, 기존 Istio Sidecar Mode 기반 아키텍처는 몇 가지 한계를 보였습니다.Why Ambient Mode?간단하게 기존의 Sidecar Mode 형태의 아키텍처를 간단하게 소개하면 아래와 같습니다.큰 특징으로는 각 Pod마다 Envoy proxy를 Sidecar로 주입하여 트래픽을 전달하는 방식입니다.하지만 Sidecar Mode는 리소스 사용량 증가와 운영 복잡도 같은 문제를 야기했습니다.리소스 증가각 Pod마다 Envoy Proxy를 Sidecar로 주입하므로, 각 Pod의 컨테이너 개수는 (애플리케이션 컨테이너 1개 + Sidecar Proxy 컨테이너 1개)로 총 2개가 됩니다.따라서 Pod 수가 증가할수록 CPU와 Memory 사용량(요청량)이 크게 증가했고, 이는 전체적인 인프라 비용 증가로 이어졌습니다.2. 운영 복잡도Pod에 문제가 발생했을 때, 애플리케이션 컨테이너의 문제인지 Envoy Proxy의 문제인지 즉시 구분하기 어려웠습니다.Envoy Proxy와 애플리케이션이 강하게 결합(Coupling)된 형태여서, 하나의 문제로 인해 전체 Pod의 장애로 확대되는 경우가 많았습니다.저희는 이러한 문제를 해결하기 위해 새롭게 출시한 Ambient Mode로 전환하는 결정을 내렸습니다.새롭게 도입한 Ambient Mode 아키텍처를 간단하게 소개하면 아래와 같습니다.Ambient Mode는 기존의 Sidecar Mode와 달리, Envoy Proxy Sidecar의 역할을 Layer 4(ztunnel)와 Layer 7(waypoint)로 분리하여 네트워크 트래픽을 처리하는 방식으로 모든 pod 간 통신은 ztunnel 을 통하고, L7 기반 로직 처리 필요 시 waypoint 를 경유합니다. 이러한 구조적 변화로 인해 인프라 운영이 더욱 가볍고 효율적으로 설계되었습니다.key point는 아래와 같습니다.리소스 절감Pod마다 Envoy Proxy Sidecar가 존재하지 않으므로 CPU와 Memory 사용량(요청량)이 감소하였고, 더 적은 Worker Node로 동일한 트래픽을 처리할 수 있게 되었습니다.2. 운영 단순화Istio의 정책을 별도의 Proxy(ztunnel, waypoint)로 관리하여, 네트워크 정책 적용과 디버깅이 더욱 간편해졌습니다.애플리케이션을 Service Mesh에 포함하거나 제외할 때, 애플리케이션 Pod 재시작할 필요가 없습니다.Istio 버전을 업그레이드 할 때, 애플리케이션 Pod를 재시작할 필요가 없습니다.물론 Ambient Mode 전환 과정에서 기존 Sidecar Mode와의 호환성을 고려해야 했으며, 트래픽 라우팅 및 보안 정책이 기대한 대로 동작하는지 충분한 테스트가 필요했습니다.다음으로, Ambient Mode 전환 과정에서 맞닥뜨린 문제와 이를 어떻게 해결했는지, 그리고 현재 운영 방식에 대해 더 자세히 풀어보겠습니다!도입 과정Helm + Argo를 통한 Istio Ambient Mode 설치초기에 Istio를 도입할 당시, 중고나라는 Istio Operator를 활용하여 배포 및 운영을 진행하였습니다.그러나 Istio 1.18 버전 이후 Operator 기반의 방식이 Deprecated됨에 따라, 기존 방식으로는 더 이상 업그레이드가 불가능한 상황이 되었습니다.이에 따라 다양한 배포 방법을 검토하였으며, 잦은 업그레이드, 커스텀 설정, GitOps 등 유연한 운영이 가능한 방법을 찾고자 하였습니다.그 결과, Helm을 활용하여 환경별 세부 설정을 커스텀하고, Argo CD 기반의 GitOps 배포 방식을 도입하여 지속적인 운영 및 유지보수를 최적화하기로 결정하였습니다Kubernetes Gateway API 도입기존에는 Istio Gateway를 사용하여 트래픽을 관리하였지만, Gateway API를 도입한 이유는 다음과 같습니다.Istio 측에서 Gateway API를 향후 표준으로 자리 잡을 것이라고 언급했습니다.(참고 문서)Waypoint 트래픽을 세밀하게 제어하기 위해 Gateway API의 HTTPRoute 리소스를 활용할 필요가 있었습니다.이에 따라 기존의 VirtualService 및 DestinationRule 설정을 HTTPRoute 기반으로 재구성하였습니다.또한, Argo Rollout Controller 설치 시 gatewayAPI plugin을 같이 생성하고 Argo Rollout 의 트래픽 라우팅 방식도 기존 trafficRouting.istio에서 trafficRouting.plugins을 활용하는 방식으로 변경하여, Gateway API를 통해 트래픽을 분배할 수 있도록 수정하였습니다. (참고 문서1, 참고 문서2) trafficRouting: plugins: argoproj-labs/gatewayAPI: namespace: {{ .Release.Namespace }} httpRoute: {{ .Release.Name }}-httproute하지만 아직 HTTPRoute에서는 VirtualService, DestinationRule에서 제공하는 트래픽 관리 설정을 완벽하게 지원하지 않습니다.!! 예를 들어 Fault Injection 등은 아직 제공하지 않아 꼭 해당 기능이 필요한 상황이라면 Gateway API의 도입을 신중하게 검토해야합니다!!Ztunnel ProxyConfigAmbient Mode를 도입하면서 가장 큰 변화 중 하나는 L4 트래픽을 처리하는 ztunnel이 등장했다는 점입니다.그렇다면, 기존에 Istiod가 관리하던 ProxyConfig 설정이 ztunnel에도 그대로 적용될까요? 정답은 아니오 입니다.ztunnel은 Envoy 기반이 아니라 독립적인 L4 터널링 컴포넌트입니다.즉, 기존 ProxyConfi

이 글에서는 리눅스 커널 기능인 Control Groups(이하 cgroups)에 대해서 간단히 알아보고, Kubernetes(이하 k8s)가 cgroups를 어떻게 사용하는지 살펴보겠습니다. Kubernetes와 cgroups 간의 관계를 이해하는 데 도움이 되기를 바랍니다.cgroups란cgroups는 시스템에서 실행되는 여러 프로세스를 그룹으로 묶고, 각 그룹이 사용할 수 있는 CPU, 메모리, I/O, 네트워크 등의 자원 사용을 제한하고 격리하는 리눅스 커널 기능입니다.이 글에서는 여러 자원 중 k8s와 관련이 깊은 CPU와 메모리 자원에 대해 살펴보겠습니다.출처: How I Used CGroups to Manage System Resources리눅스에서 cgroups를 사용하는 방법에는 여러 가지가 있지만 여기에서는 간단한 cgroupfs를 통해서 진행해 보겠습니다.(이 글에서는 cgroups v1을 이용합니다.)셸에서 mount 명령어를 실행하면 다음과 같이 cgroups를 사용하기 위한 가상의 파일 시스템이 있는 것을 볼 수 있습니다. 디렉터리를 만들거나 파일 내용을 수정하는 것으로 cgroups의 기능을 사용할 수 있습니다.$ mount...cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) .../sys/fs/cgroup 하위 디렉터리를 보면 다음과 같이 다양한 자원을 볼 수 있습니다. 이 글에서는 이 중에서 cpu,cpuacct와 memory 디렉터리만을 사용하겠습니다.$ ll /sys/fs/cgroupdr-xr-xr-x 6 root root 0 6월 19 15:11 blkio lrwxrwxrwx 1 root root 11 6월 19 15:11 cpu -> cpu,cpuacct dr-xr-xr-x 6 root root 0 6월 19 15:11 cpu,cpuacct lrwxrwxrwx 1 root root 11 6월 19 15:11 cpuacct -> cpu,cpuacct dr-xr-xr-x 3 root root 0 6월 19 15:11 cpuset dr-xr-xr-x 6 root root 0 6월 19 15:11 devices dr-xr-xr-x 3 root root 0 6월 19 15:11 freezer dr-xr-xr-x 3 root root 0 6월 19 15:11

소프트웨어 배포 자동화는 코드 변경 및 테스트 이후 프로덕션 환경에 배포하는 과정을 자동화하여 배포 속도를 향상시키고 품질을 보장하는 중요한 기술이며, 이를 통해 배포 빈도를 증가시키면서도 일관된 환경을 유지하고 보안성을 강화할 수 있습니다.AWX(Ansible Web eXecutable)는 Ansible 기반의 오픈 소스 IT 자동화 플랫폼으로, GUI 및 API를 제공하여 Ansible 플레이북 실행을 보다 쉽게 관리하고 스케줄링할 수 있도록 지원합니다. 본 글에서는 AWX를 활용하여 배포 자동화 시스템을 구축하는 방법과 고려해야 할 주요 요소를 살펴봅니다.소프트웨어 배포 자동화 개념은 이미 개발 프로세스에서 필수적인 역할을 합니다. 이는 개발자가 코드를 변경하고 테스트한 후 프로덕션 환경에 배포하는 과정을 자동화하여 시간을 절약하고 오류 가능성을 줄이는 데 도움이 되기 때문입니다.• 효율성 향상: 수동 배포 프로세스는 시간 소모가 크고 반복적이며, 오류가 발생할 가능성이 높습니다. 배포 자동화는 이러한 프로세스를 자동화하여 개발자가 더 중요한 다른 업무에 집중할 수 있도록 시간을 확보해 줍니다. 또한 배포 프로세스의 일관성을 유지하면, 오류 가능성을 줄이고 배포 시간을 단축할 수 있습니다.• 품질 향상: 배포 자동화는 배포 프로세스를 표준화하고 일관성을 유지하여 소프트웨어 품질이 향상됩니다. 자동화된 테스트를 통해 배포 전에 코드의 버그를 발견하고 해결할 수 있습니다. 이는 시스템 안정성을 높이고 사용자 경험을 개선하는 데 도움이 됩니다.• 배포 빈도 증가: 배포 자동화는 배포 프로세스를 간소화하여 배포 빈도를 높여 줍니다. 이는 새로운 기능 및 업데이트를 사용자에게 더 빠르게 제공해 주며,문제 발생 시 신속하게 핫픽스(긴급히 배포되는 패치 프로그램)를 배포하여 시스템 가동 시간을 늘릴 수 있습니다.• 보안 강화: 배포 자동화는 프로세스를 표준화하고 일관성을 유지하여 보안 취약점을 줄일 수 있습니다. 자동화된 보안 테스트를 통해 배포 전에 시스템의 보안 취약점을 발견하고 해결할 수 있습니다. 따라서 배포 자동화는 소프트웨어 개발 프로세스의 효율성, 품질, 빈도, 비용 및 보안성을 향상시키는 데 중요한 역할을 하는 기술입니다.이 글에서 소개할 AWX를 이용한 배포 자동화 툴 개발은 다음과 같은 장점을 제공합니다.• 간편한 설치와 사용: AWX는 오픈 소스 플랫폼이며, 설치 및 사용이 간편합니다.• 다양한 기능: AWX는 다양한 배포 관련 기능을 제공합니다.• 확장성: AWX는 확장 가능하며, 다양한 환경에 적용할 수 있습니다.• 커뮤니티 지원: AWX는 활발한 커뮤니티를 가지고 있으며, 기술 지원을 받을 수 있습니다.AWX를 이용한 배포 자동화 툴 개발은 소프트웨어 배포 프로세스를 개선하고 다양한 장점이 있는 효과적인 방법입니다.AWX는 Ansible 기반의 오픈 소스 IT 자동화 플랫폼으로써, 웹 기반 인터페이스를 통해 Ansible Playbook을 관리, 실행, 배포, 모니터링 등을 수행할 수 있는 강력한 기능을 제공합니다.•