Devops
Kubernetes
Kubernetes
Architecture

Architecture

쿠버네티스 아키텍처 (Kubernetes Architecture)

쿠버네티스(Kubernetes)는 컨테이너화된 애플리케이션을 자동으로 배포, 확장 및 운영할 수 있도록 설계된 오픈소스 컨테이너 오케스트레이션 플랫폼이다.
이를 가능하게 하는 구조는 크게 컨트롤 플레인(Control Plane)과 워커 노드(Worker Node) 로 나뉜다.

Kubernetes 아키텍처 개요
출처: Kubernetes 공식 문서

1️⃣ 컨트롤 플레인 (Control Plane)

컨트롤 플레인은 쿠버네티스 클러스터의 두뇌 역할을 하며, 클러스터의 상태를 유지하고 변경 사항을 관리한다.
여러 개의 노드를 제어하는 역할을 하며, 주요 구성 요소는 다음과 같다.

🔹 1.1 API Server (kube-apiserver)

역할:

  • 모든 쿠버네티스 리소스를 관리하는 중심적인 컴포넌트
  • 클라이언트(kubectl, Dashboard, 외부 API 요청)와 쿠버네티스 내부 컴포넌트 간의 통신을 처리
  • etcd와 직접 통신하여 클러스터 상태를 저장하고 조회

예제:
kubectl을 사용하여 새로운 Pod를 생성할 때 API 서버가 이를 어떻게 처리하는지 보자.

kubectl run nginx --image=nginx

✅ 위 명령어 실행 시 API 서버는 다음 과정을 수행한다:

  1. 사용자의 요청을 JSON 형태로 변환
  2. etcd에 저장하여 클러스터의 상태를 업데이트
  3. Scheduler가 해당 Pod를 적절한 노드에 배치하도록 요청
  4. Kubelet이 해당 노드에서 컨테이너를 실행

🔹 1.2 etcd

역할:

  • 쿠버네티스 클러스터의 상태 정보를 저장하는 분산 Key-Value 저장소
  • 고가용성을 위해 다중 노드로 구성 가능
  • 모든 클러스터 리소스(Pod, Service, ConfigMap 등)의 선언적 상태를 저장

예제:
etcd에 저장된 데이터를 확인하는 명령어:

ETCDCTL_API=3 etcdctl get /registry/pods --prefix --keys-only

✅ 위 명령어를 실행하면 현재 클러스터에 존재하는 모든 Pod 목록을 가져올 수 있다.

🔹 1.3 Scheduler (kube-scheduler)

역할:

  • 새로운 Pod가 생성될 때 적절한 워커 노드를 선택
  • CPU, 메모리, 스토리지, 노드 라벨, affinity 등의 리소스 조건을 기반으로 스케줄링 결정

예제:
Pod가 특정 노드에서 실행되도록 강제하는 nodeSelector 설정:

apiVersion: v1
kind: Pod
metadata:
  name: my-nginx
spec:
  nodeSelector:
    disktype: ssd  # SSD를 사용하는 노드에 배치
  containers:
  - name: nginx
    image: nginx

✅ 위 설정을 적용하면 SSD 스토리지가 있는 노드에서만 Pod가 실행된다.

🔹 1.4 Controller Manager (kube-controller-manager)

역할:

  • 쿠버네티스의 다양한 컨트롤러(Controller)를 실행하는 역할
  • 각 리소스의 현재 상태(Current State)와 원하는 상태(Desired State) 를 비교하고 조정
  • 주요 컨트롤러:
    • ReplicaSet Controller: 원하는 개수만큼 Pod 유지
    • Node Controller: 노드 상태 감지 및 장애 감지
    • Service Account Controller: 서비스 계정과 API 토큰 관리

예제:
Pod 개수를 자동으로 유지하는 ReplicaSet 예제:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-replicaset
spec:
  replicas: 3  # 항상 3개의 Pod 유지
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx

✅ 만약 하나의 Pod가 삭제되면 Controller Manager가 자동으로 새로운 Pod를 생성하여 3개를 유지한다.

2️⃣ 워커 노드 (Worker Node)

컨트롤 플레인에서 지시한 작업을 실제 수행하는 노드이다.
각 워커 노드는 다음과 같은 핵심 컴포넌트로 구성된다.

🔹 2.1 Kubelet

역할:

  • 노드에서 실행되는 핵심 에이전트
  • API 서버로부터 Pod 배치 명령을 받아 실행
  • 컨테이너 상태를 모니터링하고, 장애 발생 시 재시작

예제:
특정 노드의 Kubelet 상태 확인:

systemctl status kubelet

✅ Kubelet이 실행 중이어야 노드가 정상적으로 작동한다.

🔹 2.2 Kube Proxy

역할:

  • Kubernetes 네트워크를 관리하는 서비스
  • Service를 통해 Pod 간 트래픽을 라우팅
  • iptables 또는 IPVS 기반으로 트래픽을 처리

예제:
쿠버네티스 서비스 목록 확인:

kubectl get svc

✅ Service가 생성되면 Kube Proxy가 이를 인식하고 네트워크 경로를 자동으로 설정한다.

🔹 2.3 컨테이너 런타임 (Container Runtime)

역할:

  • 컨테이너 실행을 담당하는 소프트웨어
  • 대표적인 런타임:
    • Docker
    • containerd
    • CRI-O
    • Firecracker

예제:
현재 노드에서 사용 중인 컨테이너 런타임 확인:

kubectl get nodes -o wide

✅ CONTAINER-RUNTIME 필드에서 어떤 런타임이 사용되는지 확인할 수 있다.

3️⃣ 서비스 디스커버리 및 네트워킹 개념

쿠버네티스에서 Pod는 동적으로 생성/삭제되므로, IP 주소가 변경될 가능성이 높다.
이를 해결하기 위해 Service와 Ingress를 활용하여 트래픽을 안정적으로 관리한다.

🔹 3.1 Cluster Networking

쿠버네티스 네트워킹의 주요 특징:

  • 모든 Pod는 고유한 IP를 가지며 동일한 네트워크 내에서 서로 통신 가능
  • CNI (Container Network Interface)를 사용하여 네트워크 정책을 관리
    (예: Flannel, Calico, Cilium)

🔹 3.2 Service를 통한 트래픽 관리

Pod가 삭제되더라도 고정된 엔드포인트를 제공하는 Service 예제:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

✅ 위 설정을 적용하면 my-service라는 고정된 DNS 이름을 사용하여 Pod와 통신할 수 있다.

🔹 결론

쿠버네티스의 아키텍처는 컨트롤 플레인과 워커 노드로 구성되며,
각 컴포넌트가 유기적으로 작동하여 컨테이너를 안정적으로 관리한다.
쿠버네티스를 운영할 때는 API Server, Scheduler, Controller Manager, Kubelet, Kube Proxy의 역할을 명확히 이해하는 것이 중요하다.

RSS Feed
KubernetesInstallation