Kubernetes Blog

https://kubernetes.io/blog/2025/09/15/kubernetes-v1-34-decoupled-taint-manager-is-now-stable/

오케스트레이션이란 ?

오케스트레이션은 여러 개의 컴퓨터 시스템, 애플리케이션 및/또는 서비스를 조율하고 관리하는 것으로, 여러 개의 작업을 함께 연결하여 크기가 큰 워크플로나 프로세스를 실행하는 방식을 취합니다. 이러한 프로세스는 여러 개의 자동화된 작업으로 구성될 수 있으며 관련되는 시스템도 여러 개일 수 있습니다.

Part 1

1. 쿠버네티스란 무엇인가?

• 구글에서 시작된 오픈소스 컨테이너 오케스트레이션 도구

• 다수의 컨테이너를 효율적으로 관리하고, 자동화된 배포, 스케일링, 로드밸런싱 제공

• 핵심 목적: 운영 효율성과 확장성 보장

즉, 쿠버네티스는 단순히 컨테이너를 실행하는 것이 아니라, 서비스 운영에 필요한 전반적인 관리 자동화를 제공하는 플랫폼입니다.

2. 쿠버네티스의 필요성

컨테이너만으로 운영할 때 발생하는 문제:

• 컨테이너 개수가 많아질수록 관리 어려움 증가

• 수동 배포 시 서비스 중단 위험

• 확장/축소 과정이 번거로움

• 자원 최적화 부족

쿠버네티스는 이러한 문제를 해결하기 위해 등장했습니다. 자동화된 방식으로 배포/관리/복구를 제공하여 운영자의 부담을 최소화합니다.

3. 쿠버네티스 아키텍처 개요

쿠버네티스는 크게 Control Plane과 Worker Node로 구성됩니다.

• Control Plane: 클러스터를 전체적으로 관리하는 두뇌 역할

  • API Server, etcd, Scheduler, Controller Manager 등으로 구성

• Worker Node: 실제 컨테이너가 실행되는 곳

  • Kubelet, Kube Proxy, Container Runtime 포함

이 구조를 통해 쿠버네티스는 중앙집중식 관리 + 분산 실행을 가능하게 합니다.

Control Plane과 Worker Node 구성 요소(API Server, etcd, Scheduler, Kubelet 등)를 한눈에 볼 수 있음

4. 주요 컴포넌트 소개

(1) API Server

• 클러스터와의 모든 통신 창구 역할

• kubectl 명령어와 상호작용

(2) etcd

• 분산 Key-Value 저장소

• 클러스터 상태와 메타데이터 저장

(3) Scheduler

• 새로운 파드(Pod)를 적절한 노드에 배치

• 리소스 상황을 고려하여 최적의 위치 선정

(4) Controller Manager

• 클러스터 상태를 지속적으로 모니터링

• 실제 상태가 원하는 상태(Desired State)와 다르면 조정

(5) Worker Node 구성요소

• Kubelet: 노드의 에이전트, Pod 상태 관리

• Kube Proxy: 네트워크 트래픽 관리

• Container Runtime: 컨테이너 실행(Docker, containerd 등)

이미지 출처 : https://www.kerno.io/learn/kubernetes-services

5. 쿠버네티스의 핵심 개념

(1) Pod

• 쿠버네티스에서 배포 가능한 가장 작은 단위

• 하나 이상의 컨테이너를 포함할 수 있음

(2) ReplicaSet

• 동일한 Pod를 여러 개 유지하여 가용성 확보

(3) Deployment

• Pod와 ReplicaSet을 관리하는 상위 개념

• 롤링 업데이트, 롤백 기능 지원

(4) Service

• Pod는 동적으로 생성/삭제되므로 IP가 바뀔 수 있음 → Service를 통해 안정적인 네트워크 엔드포인트 제공

• Load Balancer, ClusterIP, NodePort 등 다양한 유형 존재

(5) Namespace

• 클러스터 내 자원을 논리적으로 분리하는 공간

Pod는 동적으로 변하므로, Service가 안정적인 엔드포인트를 제공하는 과정

이미지 출처 :   https://happycloud-lee.tistory.com/248

6. Desired State와 Current State

• 사용자가 매니페스트 파일(YAML)로 원하는 상태(Desired State)를 정의

• 쿠버네티스는 이를 기준으로 실제 상태(Current State)를 자동 조정

• Self-Healing 기능: Pod가 죽으면 자동으로 새 Pod를 생성해 원하는 상태 유지

Part 2

앞서 Part 1에서 쿠버네티스의 개요와 주요 컴포넌트를 살펴보았습니다. 이번에는 쿠버네티스의 동작 방식과 실제 운영에서의 활용 방법을 다룹니다.

7. 쿠버네티스 동작 원리

쿠버네티스는 항상  선언적 방식(Declarative)으로 동작합니다.

1. 사용자가 YAML 매니페스트 파일로 원하는 상태(Desired State)를 선언

2. API Server가 요청을 받아 etcd에 저장

3. Scheduler가 적절한 노드를 선택하여 Pod 배치

4. Kubelet이 해당 노드에서 Pod 실행

5. Controller Manager가 지속적으로 상태를 모니터링하여 원하는 상태를 유지

즉, 운영자가 직접 제어하기보다는 원하는 상태를 정의하면 시스템이 알아서 맞춰주는 구조입니다.

8. 서비스 디스커버리와 로드밸런싱

쿠버네티스는 동적으로 변하는 Pod를 안정적으로 접근할 수 있도록 Service 객체를 제공합니다.

• ClusterIP: 클러스터 내부에서만 접근 가능

• NodePort: 각 노드의 특정 포트를 통해 외부 접근 가능

• LoadBalancer: 클라우드 환경에서 외부 로드밸런서와 연동 가능

• Ingress: 도메인 기반의 라우팅, SSL 적용 지원

이를 통해 외부 사용자는 Pod의 변동 여부와 상관없이 안정적인 접근이 가능합니다.

9. 스케일링(Scaling)

• 수평 스케일링(Horizontal Pod Autoscaler, HPA): 트래픽 증가 시 Pod 수를 자동으로 늘림

• 수직 스케일링: Pod 하나에 할당되는 자원을 늘리거나 줄임

• Cluster Autoscaler: 필요 시 새로운 Worker Node를 자동으로 추가

스케일링은 쿠버네티스의 핵심 장점 중 하나로, 클라우드 환경에서 효율적인 자원 활용을 가능하게 합니다.

10. 상태 관리와 복구(Self-Healing)

쿠버네티스는 장애가 발생해도 자동으로 복구합니다.

• Pod가 죽으면 새로 생성

• 노드 장애 시 다른 노드로 Pod 재배치

• Deployment 롤백 가능

즉, 관리자가 개입하지 않아도 시스템이 스스로 안정성을 유지합니다.

11. ConfigMap과 Secret

• ConfigMap: 애플리케이션의 환경변수, 설정값을 Pod에 주입

• Secret: 비밀번호, API 키와 같은 민감 정보를 안전하게 저장

이를 활용하면 애플리케이션을 환경에 따라 유연하게 배포할 수 있습니다.

12. Persistent Volume(PV)과 Persistent Volume Claim(PVC)

컨테이너는 기본적으로 휘발성(Stateless)이지만, 데이터는 영속적으로 저장해야 합니다. 이를 위해 쿠버네티스는 스토리지 관리 기능을 제공합니다.

• Persistent Volume (PV): 클러스터에서 제공하는 스토리지 자원

• Persistent Volume Claim (PVC): 사용자가 요청하는 스토리지 요구사항

이를 통해 데이터베이스와 같은 상태 기반(Stateful) 애플리케이션도 운영할 수 있습니다.

Part 3

앞선 Part 1과 Part 2에서는 쿠버네티스의 기본 개념과 동작 방식을 살펴보았습니다. 이번 Part 3에서는 보안, 모니터링, 운영 환경에서의 모범 사례를 정리합니다.

13. 보안(Security)

쿠버네티스는 대규모 환경에서 보안을 보장하기 위해 다양한 기능을 제공합니다.

• RBAC(Role-Based Access Control)

  • 사용자/서비스 계정별 권한 제어

  • 최소 권한 원칙 적용

• Network Policy

  • Pod 간 통신을 제어하는 방화벽 규칙

  • 특정 서비스 간에만 트래픽 허용 가능

• Secrets 암호화

  • Secret 데이터를 etcd에 저장할 때 암호화

• Pod Security Standards (PSS)

  • Pod 실행 시 보안 정책 강제 (root 권한 제한 등)

14. 모니터링 & 로깅

운영 환경에서는 시스템 상태를 지속적으로 관찰하는 것이 중요합니다.

• Prometheus: 메트릭 수집 및 모니터링

• Grafana: 시각화 대시보드

• ELK Stack (Elasticsearch, Logstash, Kibana): 로그 수집 및 분석

• Jaeger / OpenTelemetry: 분산 트레이싱

이를 통해 장애 원인을 빠르게 파악하고 성능 병목을 분석할 수 있습니다.

15. 운영 모범 사례

1. 매니페스트 형상 관리

   • GitOps 방식을 활용해 YAML 파일을 Git으로 관리

2. 리소스 요청/제한 설정

   • CPU, 메모리 요청(Request)과 제한(Limit)을 반드시 정의

3. 헬스 체크

   • Readiness Probe, Liveness Probe를 통해 Pod 상태를 모니터링

쿠버네티스 Pod 상태 모니터링: Readiness Probe vs Liveness Probe

쿠버네티스(Kubernetes)에서 애플리케이션을 안정적으로 운영하기 위해 중요한 기능 중 하나가 헬스 체크(Health Check) 입니다.

특히 Readiness Probe와 Liveness Probe는 Pod 상태를 모니터링하여 트래픽 라우팅과 자동 복구를 지원합니다.

아래에서는 두 Probe의 개념과 차이점, 그리고 실제 예시를 통해 자세히 설명하겠습니다.

1. Readiness Probe (준비 상태 확인)

• 역할: 해당 컨테이너가 서비스 트래픽을 받을 준비가 되었는지 확인합니다.

• 동작 원리: Probe가 성공해야만 해당 Pod의 IP가 Service의 엔드포인트(Endpoints) 목록에 추가되어 트래픽이 전달됩니다.

• 사용 예시: 애플리케이션이 초기화 작업(예: DB 연결, 캐시 로드 등)을 완료해야만 정상적으로 요청을 처리할 수 있을 때.

예제

apiVersion: v1
kind: Pod
metadata:
  name: readiness-example
spec:
  containers:
  - name: app-container
    image: my-app:latest
    readinessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10

✅ 이 경우 컨테이너가 실행된 후 5초 뒤부터 /healthz 경로를 10초마다 확인합니다. 응답이 200 OK라면 Service 트래픽을 받을 수 있습니다.

2. Liveness Probe (생존 상태 확인)

• 역할: 해당 컨테이너가 정상적으로 실행 중인지 확인합니다.

• 동작 원리: Probe가 실패하면 쿠버네티스가 해당 컨테이너를 자동으로 재시작합니다.

• 사용 예시: 애플리케이션이 실행 중이더라도 내부적으로 데드락(Deadlock) 상태에 빠지거나 무한 루프에 걸릴 수 있을 때.

예제

apiVersion: v1
kind: Pod
metadata:
  name: liveness-example
spec:
  containers:
  - name: app-container
    image: my-app:latest
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

✅ 이 경우 컨테이너 실행 후 15초 뒤부터 20초마다 8080 포트에 TCP 연결을 시도합니다. 연결이 되지 않으면 쿠버네티스가 해당 컨테이너를 재시작합니다.

3. 두 Probe의 차이점 정리

항목Readiness ProbeLiveness Probe

목적서비스 트래픽을 받을 준비 상태 확인컨테이너가 살아있는지 확인

실패 시 동작Pod 엔드포인트에서 제외 (트래픽 차단)컨테이너 재시작

활용 상황초기화 지연, 외부 리소스 연결 필요 시무한 루프, 데드락 등 실행 오류 시

4. 실전 시나리오

예를 들어, 웹 애플리케이션 서버를 운영한다고 가정해봅시다.

• 서버는 시작 후 DB 연결이 완료될 때까지 정상 요청을 처리할 수 없습니다. 이 경우 Readiness Probe를 /ready 엔드포인트로 설정하여 DB 연결이 완료될 때만 트래픽을 받도록 합니다.

• 서버가 운영 중 갑자기 메모리 누수로 인해 응답 불가 상태에 빠졌다면, Liveness Probe가 이를 감지해 컨테이너를 자동으로 재시작시켜 장애를 최소화합니다.

결론

• Readiness Probe는 “준비 완료 여부”를, Liveness Probe는 “살아 있는지 여부”를 체크합니다.

• 두 기능을 적절히 활용하면, 애플리케이션의 무중단 서비스와 자동 복구를 구현할 수 있습니다.

✅ 실제 운영 환경에서는 두 Probe를 함께 설정하여 안정적인 Pod 상태 관리 전략을 세우는 것이 중요합니다.

1. 네임스페이스 전략적 분리

   • 개발/스테이징/프로덕션 환경을 Namespace로 구분

2. 오토스케일링 적극 활용

   • HPA, VPA, Cluster Autoscaler를 통한 자원 최적화

16. 쿠버네티스와 클라우드 네이티브

쿠버네티스는 단순히 컨테이너 오케스트레이션 도구를 넘어 클라우드 네이티브 애플리케이션 운영의 표준 플랫폼으로 자리 잡았습니다.

• 클라우드 서비스와 연동 (AWS EKS, GCP GKE, Azure AKS)

• CNCF 생태계와 결합 (Service Mesh, Serverless, CI/CD)