Kubernetes 아키텍처 기본 구조: Control Plane과 Worker Node

Kubernetes 클러스터는 Control Plane(관리 영역)과 Worker Node(실행 영역)로 나뉩니다. Control Plane이 "무엇을 어디에 배치할지" 결정하고, Worker Node가 "실제 컨테이너를 실행"합니다.

핵심 요약

Kubernetes 클러스터는 Control Plane과 Worker Node의 2계층 구조입니다.
Control Plane은 클러스터의 상태를 관리하고 스케줄링을 담당합니다. 핵심 컴포넌트는 API Server, etcd, Scheduler, Controller Manager입니다.
Worker Node는 실제 애플리케이션 컨테이너를 실행합니다. kubelet, kube-proxy, Container Runtime이 동작합니다.
매니지드 Kubernetes(EKS, AKS, GKE)에서는 Control Plane을 클라우드 벤더가 관리합니다. 운영 부담은 줄지만 커스터마이징에 제약이 있습니다.
모든 통신은 API Server를 중심으로 이루어집니다. API Server가 단일 진입점(Single Point of Entry) 역할을 합니다.

1. 왜 Kubernetes 아키텍처를 이해해야 하는가

컨테이너 3개를 Docker Compose로 운영하던 서비스가 성장해서 컨테이너 50개를 관리해야 하는 상황을 가정합니다.

이때 발생하는 문제들:

서버 A에 컨테이너가 몰려서 CPU가 90%인데, 서버 B는 놀고 있습니다.
컨테이너가 죽었는데 아무도 모릅니다. 사용자가 먼저 알려줍니다.
새 버전을 배포하려면 서버 3대에 하나씩 수동으로 올려야 합니다.
트래픽이 급증했는데 컨테이너를 수동으로 늘리는 동안 서비스가 느려집니다.

Kubernetes는 이 문제들을 자동화합니다. 다만 "어떻게 자동화하는가"를 이해하려면 아키텍처를 알아야 합니다.

문제	Kubernetes가 해결하는 방식	담당 컴포넌트
리소스 불균형	리소스 상태를 보고 적절한 노드에 배치	Scheduler
컨테이너 장애	상태를 지속 감시하고 자동 재시작	kubelet, Controller Manager
수동 배포	선언적 배포 (원하는 상태를 정의하면 자동 적용)	Controller Manager, API Server
트래픽 급증	메트릭 기반 자동 스케일링	HPA, Scheduler

아키텍처를 모르면 "Pod가 Pending 상태인데 왜 그런지 모르겠다", "Node가 NotReady인데 어디를 봐야 하는지 모르겠다"는 상황에서 막히게 됩니다. 각 컴포넌트의 역할을 알면 장애 원인을 빠르게 좁힐 수 있습니다.

2. 한 줄 정의

Kubernetes는 컨테이너화된 워크로드를 여러 서버에 자동으로 배포, 스케일링, 관리하는 오케스트레이션 플랫폼입니다. "원하는 상태(Desired State)"를 선언하면 현재 상태를 원하는 상태로 맞추는 것이 핵심 동작 원리입니다.

3. 전체 아키텍처 구조

Kubernetes 클러스터는 크게 두 영역으로 나뉩니다.

영역	역할	구성 요소
Control Plane	클러스터 상태 관리, 스케줄링, API 제공	API Server, etcd, Scheduler, Controller Manager, Cloud Controller Manager
Worker Node	실제 컨테이너 실행	kubelet, kube-proxy, Container Runtime

이 구조를 비유하면: Control Plane은 "관제탑"이고, Worker Node는 "활주로에서 실제로 이착륙하는 비행기"입니다. 관제탑이 어떤 비행기를 어느 활주로에 배치할지 결정하고, 비행기는 지시에 따라 동작합니다.

핵심 설계 원칙은 선언적 모델(Declarative Model)입니다. "컨테이너 3개를 실행해라"라고 명령하는 것이 아니라, "이 서비스는 항상 3개의 복제본이 실행되어야 한다"고 선언합니다. Kubernetes가 현재 상태를 지속적으로 확인하고, 선언된 상태와 다르면 자동으로 조정합니다.

4. Control Plane 컴포넌트

Control Plane은 클러스터의 "두뇌" 역할을 합니다. 모든 관리 작업은 Control Plane을 통해 이루어집니다.

4.1 kube-apiserver

API Server는 Kubernetes의 중앙 통신 허브입니다. 모든 컴포넌트는 API Server를 통해서만 클러스터 상태를 읽고 쓸 수 있습니다.

역할: - 클러스터 외부(kubectl, CI/CD)와 내부(Scheduler, Controller) 간의 유일한 인터페이스 - RESTful API를 제공하며, 모든 요청에 대해 인증(Authentication) → 인가(Authorization) → Admission Control 순서로 처리 - etcd와 직접 통신하는 유일한 컴포넌트

실무에서 중요한 이유:

# kubectl 명령어는 모두 API Server로 요청을 보냅니다
kubectl get pods
# 실제로는: GET https://<api-server>:6443/api/v1/namespaces/default/pods

kubectl apply -f deployment.yaml
# 실제로는: POST/PUT https://<api-server>:6443/apis/apps/v1/namespaces/default/deployments

API Server가 응답하지 않으면 kubectl 명령어가 동작하지 않고, 새로운 Pod 생성이나 스케일링도 불가능합니다. 다만 이미 실행 중인 Pod는 계속 동작합니다. kubelet이 독립적으로 컨테이너를 관리하기 때문입니다.

4.2 etcd

etcd는 클러스터의 모든 상태 데이터를 저장하는 분산 키-값 저장소입니다.

저장하는 데이터: - 모든 Kubernetes 오브젝트 (Pod, Service, ConfigMap, Secret 등) - 클러스터 설정 정보 - 현재 상태와 원하는 상태(Desired State)

설계 특성: - 분산 합의 알고리즘(Raft)을 사용하여 데이터 일관성을 보장합니다. - 운영 환경에서는 일반적으로 3개 또는 5개의 etcd 노드를 구성합니다. 과반수(quorum)가 살아있어야 쓰기가 가능합니다. - 3개 노드: 1개 장애 허용 / 5개 노드: 2개 장애 허용

왜 etcd가 중요한가:

etcd가 손상되면 클러스터의 모든 상태 정보가 사라집니다. Pod 정의, Service 설정, Secret 데이터가 모두 유실됩니다. 따라서 etcd 백업은 Kubernetes 운영에서 가장 중요한 작업 중 하나입니다.

# etcd 스냅샷 백업 (자체 운영 클러스터에서)
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

4.3 kube-scheduler

Scheduler는 새로 생성된 Pod를 어떤 Worker Node에 배치할지 결정합니다.

스케줄링 과정:

Filtering: 조건을 충족하지 못하는 노드를 제외합니다 (리소스 부족, taint 불일치, nodeSelector 불일치 등).
Scoring: 남은 노드들에 점수를 매깁니다 (리소스 균형, affinity 규칙, 데이터 지역성 등).
Binding: 가장 높은 점수의 노드에 Pod를 할당합니다.

실무 시나리오:

Pod에 resources.requests.cpu: 500m을 설정했는데 모든 노드의 가용 CPU가 300m 이하라면, Scheduler는 적합한 노드를 찾지 못하고 Pod는 Pending 상태로 남습니다.

# Pod가 Pending인 이유 확인
kubectl describe pod <pod-name>
# Events 섹션에서 "0/3 nodes are available: 3 Insufficient cpu" 같은 메시지 확인

Tip
Pod가 Pending 상태일 때 가장 먼저 확인할 것은 kubectl describe pod의 Events 섹션입니다. Scheduler가 왜 배치하지 못했는지 이유를 명시합니다.

4.4 kube-controller-manager

Controller Manager는 클러스터의 현재 상태를 원하는 상태로 맞추는 제어 루프(Control Loop)를 실행합니다.

내부에 여러 컨트롤러가 포함되어 있으며, 각각 특정 리소스를 담당합니다:

컨트롤러	역할
Deployment Controller	Deployment의 ReplicaSet을 관리, 롤링 업데이트 수행
ReplicaSet Controller	지정된 수의 Pod 복제본을 유지
Node Controller	노드 상태를 모니터링, 응답 없는 노드의 Pod를 재배치
Job Controller	일회성 작업(Job)의 완료를 추적
ServiceAccount Controller	새 네임스페이스에 기본 ServiceAccount 생성

동작 원리 — Reconciliation Loop:

1. 원하는 상태 확인: "replicas: 3이 선언되어 있다"
2. 현재 상태 확인: "현재 Pod가 2개만 실행 중이다"
3. 차이 감지: "1개가 부족하다"
4. 조정 실행: "Pod 1개를 추가 생성한다"

이 루프가 지속적으로 반복됩니다. Pod가 죽으면 Controller가 감지하고 새 Pod를 생성합니다. 이것이 Kubernetes의 "자가 치유(Self-healing)" 기능의 핵심입니다.

4.5 cloud-controller-manager

Cloud Controller Manager는 클라우드 벤더 고유의 기능을 Kubernetes와 연결합니다.

기능	설명
Node Controller	클라우드 API로 노드 존재 여부 확인, 삭제된 VM의 노드 정리
Route Controller	클라우드 네트워크에 Pod 간 라우팅 설정
Service Controller	LoadBalancer 타입 Service 생성 시 클라우드 LB 프로비저닝

자체 운영(on-premise) 클러스터에서는 이 컴포넌트가 없거나 별도 구현이 필요합니다. 매니지드 Kubernetes에서는 벤더가 이 부분을 관리합니다.

5. Worker Node 컴포넌트

Worker Node는 실제 애플리케이션 컨테이너가 실행되는 서버입니다. 각 Worker Node에는 3개의 핵심 컴포넌트가 동작합니다.

5.1 kubelet

kubelet은 각 Worker Node에서 실행되는 에이전트로, Pod의 생명주기를 관리합니다.

역할: - API Server로부터 Pod 스펙(PodSpec)을 받아 컨테이너를 실행 - 컨테이너의 상태를 주기적으로 확인하고 API Server에 보고 - Liveness Probe, Readiness Probe를 실행하여 컨테이너 건강 상태 판단 - 문제가 있는 컨테이너를 재시작

중요한 특성:

kubelet은 API Server와 독립적으로 동작할 수 있습니다. Control Plane과 통신이 끊어져도 이미 실행 중인 Pod는 계속 동작합니다. 다만 새로운 Pod 배치나 상태 업데이트는 불가능합니다.

# kubelet 상태 확인 (Worker Node에서)
systemctl status kubelet

# kubelet 로그 확인 (장애 진단 시)
journalctl -u kubelet -f

5.2 kube-proxy

kube-proxy는 각 Worker Node에서 네트워크 규칙을 관리하여 Pod 간 통신과 Service 기반 로드 밸런싱을 구현합니다.

동작 방식:

Service를 생성하면 kube-proxy가 각 노드에 네트워크 규칙을 설정합니다. 클라이언트가 Service IP로 요청하면 이 규칙에 따라 실제 Pod로 트래픽이 전달됩니다.

모드	구현 방식	특징
iptables (기본)	iptables 규칙으로 패킷 라우팅	대부분의 환경에서 사용, 규칙이 많아지면 성능 저하 가능
IPVS	Linux IPVS로 로드 밸런싱	대규모 클러스터에서 성능 우위가 있었으나, 현재 deprecated 상태
nftables	nftables 기반 (Kubernetes 1.31+ beta)	iptables와 IPVS 모두를 대체하는 후속 모드, 향후 기본값 전환 예정

Tip
IPVS 모드는 deprecated 되었으며, nftables 모드가 후속으로 설계되었습니다. 새로운 클러스터를 구성한다면 iptables(현재 기본값)를 유지하거나, Kubernetes 1.31 이상에서 nftables 모드를 검토할 수 있습니다. Kubernetes 1.33부터는 nftables가 기본값입니다.

5.3 Container Runtime

Container Runtime은 실제로 컨테이너를 생성하고 실행하는 소프트웨어입니다.

Kubernetes는 CRI(Container Runtime Interface)라는 표준 인터페이스를 통해 다양한 런타임을 지원합니다.

런타임	특징	사용 환경
containerd	Docker에서 분리된 경량 런타임, 현재 가장 많이 사용	EKS, AKS, GKE 기본값
CRI-O	Kubernetes 전용으로 설계된 경량 런타임	OpenShift 기본값

Kubernetes 1.24부터 Docker를 직접 런타임으로 사용하는 dockershim이 제거되었습니다. 현재는 containerd 또는 CRI-O를 사용합니다. Docker로 빌드한 이미지는 OCI 표준을 따르므로 containerd에서도 동일하게 실행됩니다.

6. 동작 원리: Pod 생성 흐름

kubectl apply -f deployment.yaml을 실행했을 때 내부에서 일어나는 과정을 단계별로 설명합니다.

시나리오: replicas: 3인 Deployment 생성

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: nginx:1.25
        resources:
          requests:
            cpu: 100m
            memory: 128Mi

처리 흐름:

kubectl → API Server: YAML을 API Server에 전송합니다.
API Server → 인증/인가: 요청자의 권한을 확인합니다 (RBAC).
API Server → Admission Controller: 정책 검증을 수행합니다 (리소스 제한, 네임스페이스 정책 등).
API Server → etcd: 검증을 통과하면 Deployment 오브젝트를 etcd에 저장합니다.
Deployment Controller: Deployment를 감지하고 ReplicaSet을 생성합니다.
ReplicaSet Controller: ReplicaSet을 감지하고 Pod 3개를 생성합니다 (아직 노드 미할당).
Scheduler: 미할당 Pod를 감지하고, 각 Pod에 적합한 노드를 선택하여 바인딩합니다.
kubelet (각 노드): 자신에게 할당된 Pod를 감지하고, Container Runtime을 통해 컨테이너를 실행합니다.
kubelet → API Server: 컨테이너 실행 상태를 보고합니다.

이 전체 과정은 일반적으로 수 초 내에 완료됩니다. 다만 이미지 Pull이 필요한 경우 네트워크 상태에 따라 더 걸릴 수 있습니다.

Tip
각 컴포넌트는 API Server를 Watch하고 있습니다. 새로운 오브젝트가 생성되면 이벤트를 받아 자신의 역할을 수행합니다. 이 "이벤트 기반 아키텍처" 덕분에 컴포넌트 간 직접 통신 없이도 협력이 가능합니다.

7. 매니지드 vs 자체 운영: 무엇이 다른가

Kubernetes를 운영하는 방식은 크게 두 가지입니다. 선택에 따라 운영 부담과 제어 범위가 달라집니다.

구분	매니지드 (EKS/AKS/GKE)	자체 운영 (kubeadm/kops)
Control Plane 관리	벤더가 관리 (고가용성, 패치, 백업)	직접 구성, 모니터링, 백업
etcd 관리	벤더가 관리 (백업 자동화)	직접 백업, 복구 계획 수립
Worker Node 관리	사용자가 관리 (Node Group/Pool 설정)	사용자가 관리
업그레이드	벤더가 Control Plane 업그레이드 지원	직접 순서대로 업그레이드
비용	Control Plane 관리 비용 발생 (EKS: $0.10/시간)	인프라 비용만 (운영 인력 비용 별도)
커스터마이징	제한적 (API Server 플래그 변경 불가 등)	완전한 제어 가능

실무 선택 기준

매니지드를 선택하는 경우: - 전담 인프라 팀이 없거나 소규모인 경우 - Control Plane 운영보다 애플리케이션 개발에 집중해야 하는 경우 - SLA가 필요한 프로덕션 환경 (EKS/AKS/GKE 모두 Control Plane SLA 제공)

자체 운영을 선택하는 경우: - 규제 요건으로 클라우드를 사용할 수 없는 경우 (금융, 공공) - Control Plane 설정을 세밀하게 제어해야 하는 경우 - 비용 최적화가 최우선이고 운영 역량이 충분한 경우

주의
매니지드 Kubernetes에서도 Worker Node, 네트워크 설정, RBAC, Pod 보안은 사용자 책임입니다. "매니지드 = 모든 것을 벤더가 관리"가 아닙니다. Control Plane만 위임하는 것이며, 나머지 운영 영역은 여전히 사용자가 설계하고 관리해야 합니다.

8. 실무 사용 사례

사례: 스타트업 웹 서비스의 EKS 클러스터 설계

10명 규모의 개발팀에서 마이크로서비스 5개를 운영합니다. 트래픽은 평일 낮에 집중되고, 야간에는 10% 수준으로 줄어듭니다.

설계 결정:

항목	선택	이유
Control Plane	EKS (매니지드)	인프라 팀 2명으로 Control Plane까지 관리하기 어려움
Worker Node	Managed Node Group	노드 프로비저닝과 AMI 업데이트를 AWS가 지원
노드 인스턴스	m5.large (2 vCPU, 8GB)	마이크로서비스 5개의 리소스 요구량 기준
노드 수	최소 2개, 최대 6개 (Cluster Autoscaler)	야간 비용 절감 + 피크 대응
가용 영역	2개 AZ에 분산	단일 AZ 장애 시에도 서비스 유지

이 설계의 trade-off:

EKS Control Plane 비용($0.10/시간 ≈ $73/월)이 발생하지만, etcd 백업/복구/모니터링을 직접 하는 인력 비용보다 저렴하다고 판단
Managed Node Group은 커스텀 AMI 사용에 제약이 있지만, 표준 워크로드에서는 문제없음
2개 AZ는 3개 AZ보다 가용성이 낮지만, 비용과 복잡도를 고려한 선택

kubectl로 확인하는 클러스터 상태:

# 노드 목록과 상태 확인
kubectl get nodes -o wide
# NAME                          STATUS   ROLES    AGE   VERSION   OS-IMAGE         
# ip-10-0-1-100.ec2.internal   Ready    <none>   3d    v1.29.0   Amazon Linux 2023
# ip-10-0-2-200.ec2.internal   Ready    <none>   3d    v1.29.0   Amazon Linux 2023

# Control Plane 컴포넌트 상태 확인 (매니지드에서는 제한적)
kubectl get componentstatuses  # deprecated in 1.19+
kubectl get --raw='/readyz?verbose'  # API Server 상태 확인

# 시스템 Pod 확인 (kube-proxy, CoreDNS 등)
kubectl get pods -n kube-system

9. 보안 고려사항

Security Note
Kubernetes 클러스터에서 가장 중요한 보안 대상은 API Server와 etcd입니다. API Server는 클러스터의 모든 작업을 제어하고, etcd는 Secret을 포함한 모든 데이터를 저장합니다.

API Server 보안

위협	완화 방법
무단 접근	RBAC으로 최소 권한 부여, Anonymous 접근 비활성화
네트워크 노출	API Server를 Private Subnet에 배치, 접근 IP 제한
인증 우회	서비스 계정 토큰 자동 마운트 비활성화 (`automountServiceAccountToken: false`)

etcd 보안

etcd 통신은 반드시 TLS로 암호화해야 합니다 (peer 간, client 간 모두).
etcd에 저장되는 Secret은 기본적으로 Base64 인코딩만 됩니다. 암호화가 필요하면 EncryptionConfiguration을 설정해야 합니다.
etcd 접근은 API Server만 가능하도록 네트워크를 격리합니다.

Worker Node 보안

kubelet API 포트(10250)에 대한 접근을 제한합니다.
노드에 SSH 접근을 최소화하고, 필요 시 감사 로그를 남깁니다.
Container Runtime을 최신 버전으로 유지하여 컨테이너 탈출(Container Escape) 취약점을 방지합니다.

# Pod에서 서비스 계정 토큰 자동 마운트 비활성화 예시
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  automountServiceAccountToken: false
  containers:
  - name: app
    image: my-app:1.0

10. 비용/운영 고려사항

주의
Kubernetes 자체는 오픈소스이지만, 운영 비용은 인프라 비용 + 관리 인력 비용 + 도구 비용으로 구성됩니다. 소규모 서비스에서는 Kubernetes 도입이 오히려 비용을 증가시킬 수 있습니다.

비용 구조

항목	매니지드 (EKS 기준)	자체 운영
Control Plane	$0.10/시간 (≈$73/월)	EC2 인스턴스 비용 (최소 3대 권장)
Worker Node	EC2 인스턴스 비용	동일
네트워크	NAT Gateway, LB, 데이터 전송 비용	동일 (또는 자체 네트워크)
스토리지	EBS (PersistentVolume)	동일
추가 도구	모니터링, 로깅, 서비스 메시 등	동일

운영 복잡도를 줄이는 방법

전략	설명
Managed Node Group 사용	노드 프로비저닝, OS 패치를 벤더에 위임
Cluster Autoscaler / Karpenter	트래픽에 따라 노드 수를 자동 조정하여 비용 절감
Spot/Preemptible Instance	비중요 워크로드에 저렴한 인스턴스 활용 (중단 허용 필요)
리소스 요청/제한 설정	과도한 리소스 할당을 방지하여 노드 활용률 향상
네임스페이스별 ResourceQuota	팀/서비스별 리소스 사용량 제한

Kubernetes 도입이 적합하지 않은 경우

컨테이너가 5개 미만이고 트래픽 변동이 적은 경우 → ECS, Cloud Run 등 더 단순한 대안 검토
팀에 Kubernetes 운영 경험이 없고 학습 비용을 감당하기 어려운 경우
단일 서버로 충분한 워크로드에 Kubernetes를 도입하면 오버엔지니어링

11. 자주 하는 실수

1. Control Plane과 Worker Node의 역할을 혼동

"Control Plane이 죽으면 서비스가 중단된다"고 생각하는 경우가 있습니다. 실제로는 Control Plane이 일시적으로 중단되어도 이미 실행 중인 Pod는 계속 동작합니다. 다만 새로운 배포, 스케일링, 장애 복구가 불가능해집니다.

2. etcd 백업을 하지 않음

매니지드 환경에서는 벤더가 etcd를 관리하므로 문제가 적습니다. 자체 운영 클러스터에서 etcd 백업 없이 운영하다가 디스크 장애가 발생하면 클러스터 전체를 처음부터 재구성해야 합니다.

3. 리소스 요청(requests)을 설정하지 않음

Pod에 resources.requests를 설정하지 않으면 Scheduler가 리소스 상태를 고려하지 않고 배치합니다. 결과적으로 특정 노드에 Pod가 몰려서 OOM(Out of Memory)이 발생할 수 있습니다.

4. 단일 Worker Node로 운영

Worker Node가 1개뿐이면 해당 노드 장애 시 모든 Pod가 중단됩니다. 운영 환경에서는 최소 2개 이상의 Worker Node를 서로 다른 가용 영역에 배치하는 것이 일반적입니다.

5. kube-system 네임스페이스의 Pod를 무시

CoreDNS, kube-proxy 등 시스템 컴포넌트가 정상 동작하지 않으면 서비스 디스커버리나 네트워크가 깨집니다. 모니터링 대상에 kube-system Pod를 반드시 포함해야 합니다.

12. 정리

Kubernetes 클러스터는 Control Plane(API Server, etcd, Scheduler, Controller Manager)과 Worker Node(kubelet, kube-proxy, Container Runtime)의 2계층 구조입니다.
모든 통신은 API Server를 중심으로 이루어지며, etcd가 클러스터의 유일한 상태 저장소입니다.
선언적 모델과 Reconciliation Loop가 Kubernetes의 자가 치유와 자동화를 가능하게 합니다.
매니지드 Kubernetes는 Control Plane 운영 부담을 줄여주지만, Worker Node와 보안 설계는 여전히 사용자 책임입니다.
아키텍처를 이해하면 장애 발생 시 "어떤 컴포넌트를 확인해야 하는가"를 빠르게 판단할 수 있습니다.

참고 문서

'Kubernetes' 카테고리의 다른 글

Kubernetes HPA가 동작하지 않는 이유 (0)	2026.06.07
EKS vs AKS vs GKE: 매니지드 Kubernetes 비교 (0)	2026.06.06
Kubernetes RBAC란 무엇인가: Role, ClusterRole, Binding으로 권한 설계하기 (0)	2026.06.01
Kubernetes Service 종류: ClusterIP, NodePort, LoadBalancer, Ingress 비교 (0)	2026.05.31

wero90

Kubernetes 아키텍처 기본 구조: Control Plane과 Worker Node

핵심 요약

1. 왜 Kubernetes 아키텍처를 이해해야 하는가

2. 한 줄 정의

3. 전체 아키텍처 구조

4. Control Plane 컴포넌트

4.1 kube-apiserver

4.2 etcd

4.3 kube-scheduler

4.4 kube-controller-manager

4.5 cloud-controller-manager

5. Worker Node 컴포넌트

5.1 kubelet

5.2 kube-proxy

5.3 Container Runtime

6. 동작 원리: Pod 생성 흐름

시나리오: replicas: 3인 Deployment 생성

7. 매니지드 vs 자체 운영: 무엇이 다른가

실무 선택 기준

8. 실무 사용 사례

사례: 스타트업 웹 서비스의 EKS 클러스터 설계

9. 보안 고려사항

API Server 보안

etcd 보안

Worker Node 보안

10. 비용/운영 고려사항

비용 구조

운영 복잡도를 줄이는 방법

Kubernetes 도입이 적합하지 않은 경우

11. 자주 하는 실수

1. Control Plane과 Worker Node의 역할을 혼동

2. etcd 백업을 하지 않음

3. 리소스 요청(requests)을 설정하지 않음

4. 단일 Worker Node로 운영

5. kube-system 네임스페이스의 Pod를 무시

12. 정리

참고 문서

'Kubernetes' 카테고리의 다른 글

티스토리툴바

Kubernetes 아키텍처 기본 구조: Control Plane과 Worker Node

핵심 요약

1. 왜 Kubernetes 아키텍처를 이해해야 하는가

2. 한 줄 정의

3. 전체 아키텍처 구조

4. Control Plane 컴포넌트

4.1 kube-apiserver

4.2 etcd

4.3 kube-scheduler

4.4 kube-controller-manager

4.5 cloud-controller-manager

5. Worker Node 컴포넌트

5.1 kubelet

5.2 kube-proxy

5.3 Container Runtime

6. 동작 원리: Pod 생성 흐름

시나리오: replicas: 3인 Deployment 생성

7. 매니지드 vs 자체 운영: 무엇이 다른가

실무 선택 기준

8. 실무 사용 사례

사례: 스타트업 웹 서비스의 EKS 클러스터 설계

9. 보안 고려사항

API Server 보안

etcd 보안

Worker Node 보안

10. 비용/운영 고려사항

비용 구조

운영 복잡도를 줄이는 방법

Kubernetes 도입이 적합하지 않은 경우

11. 자주 하는 실수

1. Control Plane과 Worker Node의 역할을 혼동

2. etcd 백업을 하지 않음

3. 리소스 요청(requests)을 설정하지 않음

4. 단일 Worker Node로 운영

5. kube-system 네임스페이스의 Pod를 무시

12. 정리

참고 문서

'Kubernetes' 카테고리의 다른 글

'Kubernetes' Related Articles

티스토리툴바