이제 나도 클라우드 네이티브 전문가: 쿠버네티스 구축부터 운영 완전 정복

독자 여러분, 지금까지 쿠버네티스 클러스터의 핵심 구성 요소인 컨트롤 플레인과 워커 노드의 내부를 살펴보았습니다. 이들은 쿠버네티스가 컨테이너화된 애플리케이션을 안정적으로 실행하고 관리하는 데 필수적인 뼈대와 같습니다. 하지만 실제 운영 환경에서는 이러한 기본적인 기능 외에도 클러스터의 사용 편의성을 높이고, 관리 효율성을 증대시키며, 다양한 부가 기능을 제공하는 요소들이 필요합니다. 바로 이러한 역할을 수행하는 것이 애드온(Add-ons)입니다.

애드온은 쿠버네티스의 핵심 기능 자체는 아니지만, 클러스터의 전반적인 기능을 확장하고 풍부하게 만들어주는 매우 유용한 ‘부가 기능’ 또는 ‘편의 장치’들이라고 생각할 수 있습니다. 마치 스마트폰에 다양한 앱을 설치하여 그 활용도를 극대화하는 것처럼, 쿠버네티스도 애드온을 통해 더욱 강력하고 사용자 친화적인 플랫폼으로 거듭날 수 있습니다. 애드온은 대부분 쿠버네티스 오브젝트(예: Deployment, Service, ConfigMap 등)를 사용하여 클러스터 내에 배포되며, 다른 일반적인 애플리케이션과 마찬가지로 관리될 수 있습니다. 이제 쿠버네티스 클러스터에서 흔히 사용되는 주요 애드온들을 하나씩 자세히 살펴보겠습니다.

쿠버네티스 클러스터 내에서 실행되는 애플리케이션들은 종종 서로 통신해야 합니다. 하지만 앞서 kube-proxy 설명에서 언급했듯이, 파드(Pod)의 IP 주소는 동적으로 변경될 수 있기 때문에, 애플리케이션이 다른 서비스의 IP 주소를 직접 하드코딩하여 사용하는 것은 매우 불안정한 방식입니다. 이 문제를 해결하기 위해 쿠버네티스는 DNS(Domain Name System) 기반의 서비스 디스커버리(Service Discovery) 메커니즘을 제공하며, 이 기능을 구현하는 핵심 애드온이 바로 클러스터 DNS 서버입니다. 현재 대부분의 쿠버네티스 클러스터에서는 CoreDNS가 기본 클러스터 DNS 서버로 사용되고 있습니다. 과거에는 kube-dns라는 애드온이 사용되었지만, CoreDNS가 더 유연하고 확장성이 뛰어나 대체되었습니다.

CoreDNS의 역할과 작동 방식:

CoreDNS는 쿠버네티스 클러스터 내에서 실행되는 파드들이 다른 서비스들을 안정적인 서비스 이름(Service Name)을 통해 찾을 수 있도록 해주는, 마치 클러스터 내부의 ‘전화번호부’와 같은 역할을 수행합니다.

• 새로운 Service 오브젝트가 생성되면, 쿠버네티스 컨트롤 플레인(구체적으로는 kube-controller-manager의 엔드포인트 컨트롤러 등)은 해당 서비스에 대한 DNS 레코드를 자동으로 생성하도록 CoreDNS와 (직간접적으로) 연동됩니다.
• 일반적으로 서비스에 대한 DNS 레코드는 다음과 같은 형식을 따릅니다.
  • A 레코드 (IPv4 주소): <service-name>.<namespace-name>.svc.<cluster-domain> 형식을 가집니다. 예를 들어, default 네임스페이스에 my-svc라는 이름의 서비스가 있다면, my-svc.default.svc.cluster.local (여기서 cluster.local은 기본 클러스터 도메인)과 같은 FQDN(Fully Qualified Domain Name)으로 해당 서비스의 ClusterIP 주소를 조회할 수 있습니다.
  • SRV 레코드 (서비스 위치 정보): <port-name>._<protocol>.<service-name>.<namespace-name>.svc.<cluster-domain> 형식을 가집니다. 이는 서비스가 여러 포트를 노출하거나, 이름 있는 포트(named port)를 사용할 때 유용합니다. 예를 들어, http._tcp.my-svc.default.svc.cluster.local은 my-svc 서비스의 http라는 이름의 TCP 포트에 대한 정보를 제공합니다.
• 헤드리스 서비스(Headless Service, spec.clusterIP가 None으로 설정된 서비스)의 경우, 서비스 이름으로 조회하면 해당 서비스에 속한 개별 파드들의 IP 주소 목록을 A 레코드로 반환합니다. 이는 상태 저장 애플리케이션(예: 데이터베이스 클러스터)에서 각 파드 인스턴스를 직접 식별하고 접근해야 할 때 유용합니다.

• kubelet은 새로운 파드를 시작할 때, 해당 파드 내의 컨테이너들이 클러스터 DNS 서버(CoreDNS)를 사용하도록 /etc/resolv.conf 파일을 자동으로 구성합니다. (파드의 dnsPolicy 설정에 따라 달라질 수 있습니다.)
• 기본적으로 /etc/resolv.conf 파일에는 CoreDNS 서비스의 ClusterIP 주소가 네임서버(nameserver)로 지정되고, 검색 경로(search path)에는 해당 파드가 속한 네임스페이스(예: <namespace>.svc.cluster.local)와 기본 클러스터 도메인(예: svc.cluster.local, cluster.local) 등이 포함됩니다.
• 이러한 자동 설정 덕분에, 파드 내의 애플리케이션은 다른 서비스를 호출할 때 단순히 서비스 이름(예: my-svc)만 사용해도, DNS 해석기가 검색 경로를 활용하여 전체 FQDN(예: my-svc.default.svc.cluster.local)으로 변환하고 CoreDNS에 질의하여 해당 서비스의 IP 주소를 얻을 수 있습니다. 같은 네임스페이스 내의 서비스는 서비스 이름만으로, 다른 네임스페이스의 서비스는 <service-name>.<namespace-name> 형태로 호출할 수 있습니다.

• CoreDNS는 Go 언어로 작성된 매우 유연하고 플러그인 기반의 DNS 서버입니다. 그 설정은 Corefile이라는 텍스트 파일을 통해 이루어지며, 이 파일은 보통 쿠버네티스 ConfigMap 오브젝트로 관리됩니다.
• CoreDNS는 다양한 플러그인을 지원하여 기능을 확장할 수 있습니다. 예를 들어, kubernetes 플러그인은 쿠버네티스 API 서버를 감시하여 서비스와 파드 정보를 가져와 DNS 레코드를 제공하는 핵심 역할을 합니다. forward 플러그인을 사용하면 클러스터 내부에서 해석할 수 없는 외부 도메인에 대한 질의를 업스트림 DNS 서버(예: ISP의 DNS 서버 또는 Google Public DNS)로 전달할 수 있습니다. cache 플러그인은 DNS 응답을 캐싱하여 성능을 향상시키고, rewrite 플러그인은 DNS 질의나 응답을 수정하는 등 다양한 고급 기능을 플러그인을 통해 구현할 수 있습니다.
• 관리자는 CoreDNS의 Corefile을 수정하여 DNS 해석 정책을 커스터마이징하거나, 스텁 도메인(stub domains)을 설정하여 특정 도메인에 대한 질의를 별도의 DNS 서버로 전달하도록 구성하는 등 필요에 맞게 DNS 환경을 조정할 수 있습니다.

CoreDNS는 일반적으로 쿠버네티스 클러스터 내에 Deployment와 Service 형태로 배포됩니다. 안정적인 DNS 서비스를 위해 보통 여러 개의 CoreDNS 파드 복제본이 실행되며, 로드 밸런싱을 통해 요청이 분산됩니다. CoreDNS 서비스 자체의 ClusterIP 주소는 kubelet이 각 파드의 /etc/resolv.conf 파일에 설정하는 네임서버 주소로 사용됩니다.

클러스터 DNS는 쿠버네티스 네트워킹의 핵심적인 부분이며, 이것이 제대로 작동하지 않으면 서비스 간 통신이 불가능해져 클러스터 전체가 마비될 수 있습니다. 따라서 CoreDNS의 안정적인 운영과 적절한 리소스 할당(CPU, 메모리)은 매우 중요합니다. kubeadm과 같은 대부분의 클러스터 설치 도구는 CoreDNS를 기본 클러스터 DNS 애드온으로 자동으로 설치하고 구성합니다.

쿠버네티스는 기본적으로 kubectl이라는 강력한 커맨드라인 인터페이스(CLI)를 통해 클러스터를 관리하고 상호작용하도록 설계되었습니다. 하지만 때로는 그래픽 사용자 인터페이스(GUI)를 통해 클러스터의 상태를 시각적으로 확인하고, 간단한 작업을 수행하는 것이 더 편리할 수 있습니다. 쿠버네티스 대시보드(Kubernetes Dashboard)는 바로 이러한 목적을 위해 제공되는 웹 기반의 범용 UI 애드온입니다.

• OPENMARU COP(NODE LIST)

• OPENMARU COP(워크로드)

• 클러스터 리소스 시각화: 대시보드를 통해 클러스터에 배포된 다양한 리소스(예: 노드, 네임스페이스, 파드, 디플로이먼트, 서비스, 컨피그맵, 시크릿 등)의 목록과 상태를 한눈에 파악할 수 있습니다. 각 리소스의 상세 정보, YAML 명세, 관련 이벤트 등도 쉽게 조회할 수 있습니다.
• 애플리케이션 배포 및 관리: 간단한 폼 입력이나 YAML/JSON 명세 업로드를 통해 새로운 애플리케이션을 배포하거나 기존 애플리케이션을 수정(예: 스케일 아웃/인)하고 삭제하는 작업을 수행할 수 있습니다.
• 리소스 사용량 모니터링 (기본적인 수준): 노드나 파드의 CPU 및 메모리 사용량과 같은 기본적인 메트릭 정보를 그래프 형태로 보여줄 수 있습니다. (이는 보통 Metrics Server 애드온과의 연동을 통해 제공됩니다.)
• 로그 조회 및 컨테이너 접근: 실행 중인 파드의 컨테이너 로그를 웹 UI 상에서 직접 확인할 수 있으며, 컨테이너 내부로 exec (터미널 접속)하는 기능도 제공합니다.
• 문제 해결 지원: 파드 이벤트나 로그를 통해 애플리케이션 배포나 실행 중 발생한 문제를 진단하는 데 도움을 줄 수 있습니다.

쿠버네티스 대시보드는 클러스터에 직접 배포해야 하는 애드온입니다. 공식 GitHub 저장소에서 제공하는 YAML 매니페스트 파일을 사용하여 kubectl apply -f <manifest-url> 명령으로 쉽게 설치할 수 있습니다. 대시보드 파드는 kubernetes-dashboard 네임스페이스에 Deployment와 Service 형태로 생성됩니다.

대시보드에 접근하기 위해서는 인증 및 인가 과정이 필요합니다. 보안상의 이유로, 대시보드는 기본적으로 제한된 권한을 가진 서비스 어카운트로 실행되며, 사용자가 대시보드를 통해 수행할 수 있는 작업은 해당 사용자의 권한(보통 Bearer 토큰이나 Kubeconfig 파일을 통해 인증)에 따라 결정됩니다. 운영 환경에서는 최소 권한 원칙에 따라 각 사용자에게 적절한 RBAC(Role-Based Access Control) 규칙을 설정하여 대시보드 접근 권한을 신중하게 관리해야 합니다.

로컬 개발 환경에서는 kubectl proxy 명령을 사용하여 로컬 머신에서 대시보드 UI에 안전하게 접근할 수 있는 HTTP 프록시를 실행할 수 있습니다.

대시보드는 쿠버네티스를 처음 접하는 사용자나, 복잡한 kubectl 명령어에 익숙하지 않은 사용자에게 클러스터의 상태를 직관적으로 파악하고 간단한 작업을 수행하는 데 매우 유용할 수 있습니다. 또한, 시각적인 피드백을 통해 문제 상황을 빠르게 인지하는 데도 도움이 됩니다.

하지만 대시보드는 kubectl이 제공하는 모든 기능을 완벽하게 대체할 수는 없습니다. 복잡한 작업이나 자동화된 스크립팅, 세밀한 리소스 제어 등은 여전히 kubectl을 사용하는 것이 더 효율적이고 강력합니다. 또한, 대시보드 자체도 하나의 웹 애플리케이션이므로 보안 취약점에 노출될 수 있으며, 운영 환경에서는 접근 제어 및 보안 설정에 각별히 주의해야 합니다. 많은 상용 쿠버네티스 플랫폼(예: Rancher, OpenShift, Lens 등)은 자체적으로 더욱 강력하고 다양한 기능을 제공하는 대시보드나 관리 도구를 제공하기도 합니다.

결론적으로, 쿠버네티스 대시보드는 유용한 선택적 애드온이지만, 클러스터 관리의 필수 요소는 아닙니다. 팀의 기술 수준, 운영 정책, 보안 요구사항 등을 고려하여 도입 여부와 활용 범위를 결정하는 것이 좋습니다.

쿠버네티스 클러스터와 그 위에서 실행되는 애플리케이션의 건강 상태, 성능, 자원 사용량을 지속적으로 파악하고 문제 발생 시 신속하게 대응하기 위해서는 강력한 모니터링 시스템이 필수적입니다. 쿠버네티스 자체는 기본적인 리소스 사용량 정보(예: kubectl top node, kubectl top pod)를 제공하기 위해 Metrics Server라는 경량 애드온을 사용하지만, 이는 단기적인 현재 상태 정보만 제공하며 영구 저장이나 복잡한 분석 기능은 부족합니다. 따라서 실제 운영 환경에서는 보다 포괄적이고 장기적인 모니터링 솔루션을 애드온 형태로 구축하는 것이 일반적입니다.

주요 모니터링 구성 요소 및 솔루션:

• 앞서 언급했듯이, 클러스터 내의 노드와 파드로부터 리소스 사용량(CPU, 메모리 등)을 수집하여 kube-apiserver를 통해 집계된 형태로 제공하는 핵심적인 애드온입니다.
• 수집된 메트릭은 kubectl top 명령어뿐만 아니라, HPA(Horizontal Pod Autoscaler)가 파드의 CPU 또는 메모리 사용량에 기반하여 자동으로 스케일링 결정을 내리는 데 사용됩니다. 또한, 쿠버네티스 대시보드에서도 이 메트릭을 사용하여 간단한 리소스 사용량 그래프를 보여줍니다.
• Metrics Server는 단기적인 인메모리 저장소만 사용하며, 장기적인 데이터 보관이나 복잡한 쿼리 기능은 제공하지 않습니다.

• CNCF의 졸업 프로젝트(Graduated Project)이자, 현대 클라우드 네이티브 환경에서 사실상의 표준으로 자리 잡은 오픈 소스 모니터링 및 알림 시스템입니다.
• Prometheus는 풀(pull) 방식으로 모니터링 대상(target)으로부터 주기적으로 메트릭을 수집합니다. 쿠버네티스 환경에서는 노드 익스포터(Node Exporter, 노드의 하드웨어 및 OS 메트릭 수집), kube-state-metrics(쿠버네티스 API 오브젝트의 상태 메트릭 수집), cAdvisor (컨테이너 리소스 사용량 메트릭, kubelet에 내장 또는 별도 실행) 등 다양한 익스포터(exporter)를 통해 메트릭을 수집할 수 있습니다.
• 수집된 메트릭은 시계열 데이터베이스(Time Series Database, TSDB)에 저장되며, **PromQL(Prometheus Query Language)**이라는 강력한 쿼리 언어를 사용하여 데이터를 조회하고 분석할 수 있습니다.
• Prometheus는 서비스 디스커버리 기능과 통합되어 쿠버네티스 클러스터 내의 모니터링 대상을 동적으로 발견하고 설정할 수 있습니다.
• 알림(Alerting) 기능도 내장하고 있어, 특정 조건(예: CPU 사용률 임계치 초과)이 충족되면 Alertmanager라는 별도의 컴포넌트를 통해 다양한 채널(이메일, Slack, PagerDuty 등)로 알림을 보낼 수 있습니다.

• Prometheus와 같은 다양한 데이터 소스(datasource)에 저장된 시계열 데이터를 시각화하여 보여주는 오픈 소스 대시보드 및 시각화 도구입니다.
• 사용자는 Grafana를 사용하여 Prometheus에 저장된 메트릭을 기반으로 다양한 종류의 그래프, 차트, 테이블 등으로 구성된 맞춤형 대시보드를 쉽게 만들 수 있습니다. 이를 통해 클러스터 및 애플리케이션의 상태를 직관적으로 파악하고 추세를 분석하는 데 매우 유용합니다.
• 쿠버네티스 모니터링을 위한 다양한 사전 정의된 Grafana 대시보드 템플릿도 커뮤니티를 통해 공유되고 있어, 빠르게 모니터링 환경을 구축하는 데 도움이 됩니다.

일반적으로 Prometheus와 Grafana는 쿠버네티스 클러스터 내에 함께 배포되어 강력한 모니터링 스택을 구성합니다.

• Prometheus는 클러스터의 메트릭을 수집하고 저장하며, 알림 규칙을 평가합니다.
• Grafana는 Prometheus를 데이터 소스로 연결하여 수집된 메트릭을 시각화하고, 운영자가 클러스터 상태를 모니터링할 수 있는 대시보드를 제공합니다.
• prometheus-operator와 같은 쿠버네티스 오퍼레이터(Operator)를 사용하면 Prometheus, Alertmanager, Grafana 및 관련 익스포터들의 배포와 설정을 더욱 쉽고 자동화된 방식으로 관리할 수 있습니다.

• 로깅(Logging): 애플리케이션 및 시스템 로그를 중앙에서 수집, 저장, 검색, 분석하기 위한 로깅 시스템도 중요한 애드온입니다. 일반적으로 Elasticsearch (또는 OpenSearch), Fluentd (또는 Fluent Bit), Kibana (또는 OpenSearch Dashboards)로 구성되는 EFK (또는 OFK) 스택이나, Loki, Promtail, Grafana로 구성되는 PLG 스택 등이 널리 사용됩니다. 이러한 로깅 솔루션은 문제 해결, 감사 추적, 성능 분석 등에 필수적입니다.
• 네트워크 정책(Network Policy) 적용: CNI(Container Network Interface) 플러그인에 따라 다르지만, Calico, Cilium, Weave Net과 같은 일부 CNI 플러그인은 자체적으로 네트워크 정책을 적용하는 기능을 제공하거나, 이를 위한 추가적인 컴포넌트를 애드온 형태로 배포해야 할 수 있습니다. 네트워크 정책은 파드 간의 네트워크 트래픽을 제어하여 보안을 강화하는 데 중요합니다.
• 인그레스 컨트롤러(Ingress Controller): 클러스터 외부에서 내부의 서비스로 HTTP/HTTPS 트래픽을 라우팅하고 관리하기 위한 인그레스 컨트롤러(예: Nginx Ingress Controller, Traefik, HAProxy Ingress 등)도 중요한 애드온입니다. Service의 LoadBalancer 타입보다 더 유연하고 다양한 라우팅 규칙(호스트 기반, 경로 기반 등), SSL/TLS 종료, 로드 밸런싱 알고리즘 등을 제공합니다.
• 인증서 관리(Certificate Management): 클러스터 내 서비스의 TLS 인증서를 자동으로 발급하고 갱신하기 위한 애드온으로 cert-manager가 널리 사용됩니다. Let’s Encrypt와 같은 ACME 프로토콜 지원 CA나 사설 CA와 연동하여 HTTPS 통신을 쉽게 구현할 수 있도록 도와줍니다.

결론적으로, 애드온은 쿠버네티스 클러스터의 기능을 특정 요구사항에 맞게 확장하고 완성도를 높이는 데 핵심적인 역할을 합니다. 클러스터 DNS를 통한 서비스 디스커버리, 웹 UI를 통한 시각적 관리, 그리고 컨테이너 리소스 및 애플리케이션 상태에 대한 포괄적인 모니터링 시스템은 현대적인 쿠버네티스 운영 환경에서 거의 필수적인 요소로 간주됩니다. 이 외에도 다양한 종류의 애드온들이 존재하며, 클러스터의 목적과 규모, 운영 환경, 보안 요구사항 등을 종합적으로 고려하여 적절한 애드온들을 선택하고 구성하는 것이 성공적인 쿠버네티스 도입과 운영의 중요한 열쇠가 될 것입니다.