역할: 쿠버네티스의 프론트엔드이자 중앙 허브

API 서버는 쿠버네티스 클러스터의 모든 통신이 지나가는 관문이야. 사용자가 kubectl 명령어를 입력하든, 다른 컴포넌트들이 서로 통신하든, 모든 요청은 API 서버를 거쳐야 해. 🚪

주요 기능:
• REST API를 통한 클러스터 상태 노출
• 인증(Authentication)과 인가(Authorization) 처리
• 요청 검증(Validation)
• etcd와의 유일한 통신 창구
• 모든 컴포넌트 간 통신의 중개자

API 서버는 수평 확장이 가능해서, 트래픽이 많으면 여러 개의 API 서버를 띄워서 로드 밸런싱할 수 있어. 실제로 대규모 클러스터에서는 3개 이상의 API 서버를 운영하는 게 일반적이지! 📈

역할: 클러스터의 모든 데이터를 저장하는 데이터베이스

etcd는 쿠버네티스의 모든 클러스터 상태 정보를 저장하는 일관성 있고 고가용성을 가진 키-값 저장소야. 클러스터의 "진실의 원천(Source of Truth)"이라고 할 수 있지! 📚

저장하는 정보:
• 클러스터 설정 정보
• 모든 리소스의 상태 (Pod, Service, Deployment 등)
• 네트워크 설정
• 시크릿(Secret)과 컨피그맵(ConfigMap)

etcd는 Raft 합의 알고리즘을 사용해서 데이터 일관성을 보장해. 그래서 여러 개의 etcd 인스턴스를 클러스터로 구성하면, 일부가 죽어도 데이터가 안전하게 보존돼. 보통 3개 또는 5개의 홀수 개로 구성하는 게 권장사항이야! 🔐

⚠️ 중요: etcd는 매우 중요한 컴포넌트라서 정기적인 백업이 필수야. etcd 데이터가 날아가면 클러스터 전체를 잃는 거나 마찬가지거든!

역할: 새로운 Pod를 어느 노드에 배치할지 결정하는 배치 전문가

스케줄러는 아직 노드에 할당되지 않은 새로운 Pod를 감지하고, 그 Pod를 실행할 최적의 노드를 선택하는 역할을 해. 마치 테트리스 게임에서 블록을 어디에 놓을지 결정하는 것과 비슷해! 🎮

스케줄링 고려 사항:
• 노드의 리소스 가용성 (CPU, 메모리)
• Pod의 리소스 요구사항과 제한
• 하드웨어/소프트웨어 제약 조건
• 어피니티(Affinity)와 안티-어피니티(Anti-affinity) 규칙
• 데이터 지역성(Data locality)
• 테인트(Taint)와 톨러레이션(Toleration)

스케줄러는 2단계 프로세스로 작동해:
1. 필터링(Filtering): Pod를 실행할 수 없는 노드들을 제외
2. 스코어링(Scoring): 남은 노드들에 점수를 매겨서 가장 적합한 노드 선택

커스텀 스케줄러를 만들어서 사용할 수도 있어. 특별한 스케줄링 로직이 필요한 경우에 유용하지! 🎯

역할: 여러 개의 컨트롤러들을 실행하는 관리자

컨트롤러 매니저는 사실 여러 개의 컨트롤러를 하나의 프로세스로 묶어서 실행하는 컴포넌트야. 각 컨트롤러는 클러스터의 특정 측면을 관리하는 제어 루프(Control Loop)를 실행해. 🔄

주요 컨트롤러들:

• Node Controller: 노드의 상태를 모니터링하고, 노드가 다운되면 대응
• Replication Controller: 지정된 수의 Pod 복제본이 항상 실행되도록 보장
• Endpoints Controller: Service와 Pod를 연결하는 Endpoints 객체 관리
• Service Account & Token Controllers: 새 네임스페이스에 대한 기본 계정과 API 액세스 토큰 생성
• Deployment Controller: Deployment 리소스 관리
• Job Controller: 일회성 작업을 나타내는 Job 객체 관리

컨트롤러들은 "현재 상태"를 "원하는 상태"로 만들기 위해 끊임없이 작동해. 예를 들어, Deployment에서 replica를 3으로 설정했는데 Pod가 2개만 실행 중이면, 컨트롤러가 자동으로 1개를 더 생성하는 식이지! 🎛️

역할: 클라우드 제공자별 로직을 처리하는 컨트롤러

클라우드 환경(AWS, GCP, Azure 등)에서 쿠버네티스를 실행할 때만 사용되는 컴포넌트야. 클라우드 제공자의 API와 상호작용하면서 클라우드 리소스를 관리하지. ☁️

주요 컨트롤러들:
• Node Controller: 클라우드에서 노드가 삭제되었는지 확인
• Route Controller: 클라우드 인프라에서 라우트 설정
• Service Controller: 클라우드 로드 밸런서 생성/업데이트/삭제

온프레미스 환경에서는 이 컴포넌트가 필요 없어!

역할: 각 노드에서 실행되는 에이전트, Pod 실행을 책임짐

kubelet은 각 Worker Node에서 실행되는 가장 중요한 컴포넌트야. Control Plane과 통신하면서 해당 노드에서 Pod를 실행하고 관리하는 역할을 해. 노드의 "현장 관리자"라고 생각하면 돼! 👷

주요 기능:
• API 서버로부터 PodSpec을 받아서 Pod 실행
• 컨테이너가 정상적으로 실행되고 있는지 모니터링
• 컨테이너 런타임과 통신하여 컨테이너 생성/삭제
• 노드와 Pod의 상태를 API 서버에 보고
• 볼륨 마운트 관리
• 리소스 사용량 모니터링

kubelet은 여러 소스로부터 PodSpec을 받을 수 있어:
• API 서버 (가장 일반적)
• 로컬 파일 시스템
• HTTP 엔드포인트

kubelet은 주기적으로 컨테이너의 헬스 체크를 수행해. Liveness Probe와 Readiness Probe를 통해 컨테이너가 살아있는지, 트래픽을 받을 준비가 되었는지 확인하지! 🏥

역할: 각 노드에서 네트워크 규칙을 관리하는 네트워크 프록시

kube-proxy는 쿠버네티스 Service의 네트워크 규칙을 구현하는 컴포넌트야. Service로 들어오는 트래픽을 적절한 Pod로 전달하는 역할을 하지. 네트워크 트래픽의 "교통 경찰"이라고 할 수 있어! 🚦

주요 기능:
• Service의 가상 IP를 실제 Pod IP로 매핑
• 로드 밸런싱 구현
• 네트워크 규칙 유지 관리

kube-proxy는 여러 모드로 동작할 수 있어:

• userspace 모드: 초기 버전에서 사용, 성능이 낮음
• iptables 모드: 가장 일반적, Linux iptables 규칙 사용
• IPVS 모드: 대규모 클러스터에 적합, 더 나은 성능과 로드 밸런싱 알고리즘

최신 쿠버네티스에서는 iptables 또는 IPVS 모드를 주로 사용해. IPVS는 특히 많은 수의 Service가 있을 때 성능이 훨씬 좋아! ⚡

역할: 실제로 컨테이너를 실행하는 소프트웨어

컨테이너 런타임은 컨테이너를 실행하는 저수준 소프트웨어야. kubelet이 컨테이너를 실행하라고 명령하면, 실제로 그 작업을 수행하는 게 컨테이너 런타임이지! 🐳

지원되는 컨테이너 런타임:

• containerd: 현재 가장 널리 사용되는 런타임, Docker에서 분리됨
• CRI-O: 쿠버네티스 전용으로 설계된 경량 런타임
• Docker Engine: 과거에 많이 사용했지만, 1.24 버전부터 공식 지원 중단

쿠버네티스는 CRI(Container Runtime Interface)라는 표준 인터페이스를 정의해서, 다양한 컨테이너 런타임을 플러그인 방식으로 사용할 수 있어. 덕분에 특정 런타임에 종속되지 않고 유연하게 선택할 수 있지! 🔌

참고: Docker가 쿠버네티스에서 공식 지원이 중단됐다고 해서 Docker 이미지를 못 쓰는 건 아니야! Docker 이미지는 OCI(Open Container Initiative) 표준을 따르기 때문에 containerd나 CRI-O에서도 문제없이 실행돼. 😊

Pod는 쿠버네티스에서 배포 가능한 가장 작은 단위야. 하나 이상의 컨테이너를 포함할 수 있고, 같은 Pod 안의 컨테이너들은 네트워크와 스토리지를 공유해.

Pod의 특징:
• 고유한 IP 주소를 가짐
• 같은 Pod 내 컨테이너들은 localhost로 통신 가능
• 일시적(ephemeral)이며, 언제든 재생성될 수 있음
• 보통 하나의 컨테이너만 포함하지만, 밀접하게 결합된 여러 컨테이너를 포함할 수도 있음

Multi-container Pod 패턴:
• Sidecar: 메인 컨테이너를 보조하는 컨테이너 (로그 수집, 프록시 등)
• Ambassador: 외부 서비스와의 통신을 대행
• Adapter: 메인 컨테이너의 출력을 표준화

ReplicaSet은 지정된 수의 Pod 복제본이 항상 실행되도록 보장하는 컨트롤러야. Pod가 죽으면 자동으로 새로운 Pod를 생성해서 원하는 개수를 유지하지.

하지만 실제로는 ReplicaSet을 직접 사용하기보다는, Deployment를 통해 간접적으로 사용하는 게 일반적이야. Deployment가 ReplicaSet을 관리해주거든! 🎭

Deployment는 선언적 업데이트를 제공하는 고수준 리소스야. ReplicaSet을 관리하면서 롤링 업데이트, 롤백 등의 기능을 제공해.

Deployment의 장점:
• 선언적 업데이트: 원하는 상태만 선언하면 자동으로 달성
• 롤링 업데이트: 무중단 배포 가능
• 롤백: 이전 버전으로 쉽게 되돌리기
• 스케일링: replica 수를 쉽게 조정
• 배포 히스토리 관리

대부분의 stateless 애플리케이션은 Deployment로 배포해! 🎯

Service는 Pod 집합에 대한 안정적인 네트워크 엔드포인트를 제공해. Pod는 언제든 재생성될 수 있고 IP가 바뀔 수 있는데, Service는 변하지 않는 IP와 DNS 이름을 제공하지.

Service 타입:

• ClusterIP (기본값): 클러스터 내부에서만 접근 가능한 IP
• NodePort: 각 노드의 특정 포트로 외부 접근 허용
• LoadBalancer: 클라우드 제공자의 로드 밸런서 생성
• ExternalName: 외부 DNS 이름으로 매핑

Service는 Label Selector를 사용해서 어떤 Pod들을 대상으로 할지 결정해. 라벨이 일치하는 모든 Pod로 트래픽을 분산시키지! 🎪

Namespace는 가상 클러스터를 만들어서 리소스를 논리적으로 분리하는 방법이야. 하나의 물리적 클러스터를 여러 팀이나 프로젝트가 공유할 때 유용해.

기본 Namespace:
• default: 별도 지정 없을 때 사용되는 기본 네임스페이스
• kube-system: 쿠버네티스 시스템 컴포넌트용
• kube-public: 모든 사용자가 읽을 수 있는 공개 네임스페이스
• kube-node-lease: 노드 하트비트 정보 저장

프로덕션 환경에서는 dev, staging, production 같은 네임스페이스를 만들어서 환경을 분리하는 게 일반적이야! 🏢

Volume은 데이터를 영구적으로 저장하기 위한 메커니즘이야. 컨테이너는 일시적이라서 재시작하면 데이터가 사라지는데, Volume을 사용하면 데이터를 보존할 수 있어.

주요 Volume 타입:
• emptyDir: Pod와 생명주기를 같이하는 임시 디렉토리
• hostPath: 호스트 노드의 파일시스템 마운트
• persistentVolumeClaim: 영구 스토리지 요청
• configMap / secret: 설정 데이터 마운트
• nfs, cephfs, glusterfs: 네트워크 파일시스템
• awsElasticBlockStore, gcePersistentDisk, azureDisk: 클라우드 스토리지

프로덕션에서는 주로 PersistentVolume과 PersistentVolumeClaim을 사용해서 스토리지를 관리해! 💿

ConfigMap: 설정 데이터를 키-값 쌍으로 저장
Secret: 비밀번호, 토큰 같은 민감한 데이터를 base64 인코딩해서 저장

이 둘을 사용하면 애플리케이션 코드와 설정을 분리할 수 있어. 같은 이미지를 다른 환경에서 다른 설정으로 실행할 수 있지! 🔑

주의: Secret은 base64로 인코딩만 되어 있을 뿐 암호화는 되지 않아. 프로덕션에서는 etcd 암호화를 활성화하거나, 외부 시크릿 관리 도구(Vault, Sealed Secrets 등)를 사용하는 게 좋아!

StatefulSet은 상태를 가진 애플리케이션을 관리하기 위한 컨트롤러야. Deployment와 비슷하지만, 각 Pod에 고유한 식별자와 안정적인 네트워크 ID를 제공해.

StatefulSet의 특징:
• 순서가 보장된 배포와 스케일링
• 안정적이고 고유한 네트워크 식별자
• 안정적이고 영구적인 스토리지
• 순서가 보장된 롤링 업데이트

데이터베이스(MySQL, PostgreSQL, MongoDB), 메시지 큐(Kafka, RabbitMQ) 같은 stateful 애플리케이션에 사용해! 🗄️

DaemonSet은 모든 노드(또는 특정 노드)에 Pod를 하나씩 실행하는 컨트롤러야. 노드가 추가되면 자동으로 그 노드에도 Pod가 생성되고, 노드가 제거되면 Pod도 삭제돼.

사용 사례:
• 로그 수집 에이전트 (Fluentd, Logstash)
• 모니터링 에이전트 (Prometheus Node Exporter, Datadog Agent)
• 네트워크 플러그인
• 스토리지 데몬

클러스터의 모든 노드에서 실행되어야 하는 인프라 관련 작업에 완벽해! 🔧

Job: 일회성 작업을 실행하고 완료되면 종료
CronJob: 주기적으로 실행되는 작업 (Linux cron과 유사)

사용 사례:
• 배치 처리
• 데이터 백업
• 정기적인 데이터 정리
• 리포트 생성
• ETL 작업

예를 들어, 매일 밤 12시에 데이터베이스 백업을 실행하는 CronJob을 만들 수 있어! ⏰

Ingress는 HTTP/HTTPS 라우팅을 관리하는 API 객체야. 클러스터 외부에서 내부 Service로의 접근을 제어하고, 로드 밸런싱, SSL 종료, 이름 기반 가상 호스팅 등을 제공해.

Ingress의 기능:
• URL 경로 기반 라우팅
• 호스트 기반 라우팅
• SSL/TLS 종료
• 리다이렉션
• 로드 밸런싱

Ingress를 사용하려면 Ingress Controller가 필요해. NGINX Ingress Controller, Traefik, HAProxy 등 다양한 구현체가 있어! 🚪

예를 들어, example.com/api는 API 서비스로, example.com/web은 웹 서비스로 라우팅하는 식으로 사용할 수 있지!

HPA는 자동으로 Pod 수를 조정하는 기능이야. CPU 사용률, 메모리 사용률, 또는 커스텀 메트릭을 기반으로 Pod를 자동으로 늘리거나 줄여.

동작 방식:
• 주기적으로 메트릭 수집 (기본 15초)
• 현재 메트릭과 목표 메트릭 비교
• 필요한 replica 수 계산
• Deployment/ReplicaSet의 replica 수 조정

예를 들어, CPU 사용률이 70%를 넘으면 Pod를 추가하고, 30% 이하로 떨어지면 Pod를 줄이는 식으로 설정할 수 있어. 트래픽 변화에 자동으로 대응하니까 정말 편리해! 📈

Labels는 리소스에 붙이는 키-값 쌍의 메타데이터야. Selectors는 이 Label을 사용해서 리소스를 선택하는 방법이고.

Label 예시:
• environment: production
• tier: frontend
• app: nginx
• version: v1.2.3

Service, Deployment, NetworkPolicy 등 많은 쿠버네티스 리소스가 Label Selector를 사용해서 대상을 지정해. Label을 잘 설계하면 리소스 관리가 훨씬 쉬워져! 🏷️

RBAC는 역할 기반 접근 제어 시스템이야. 누가 어떤 리소스에 어떤 작업을 할 수 있는지 세밀하게 제어할 수 있어.

주요 개념:
• Role / ClusterRole: 권한의 집합 정의
• RoleBinding / ClusterRoleBinding: 사용자/그룹에 Role 할당
• ServiceAccount: Pod가 사용하는 계정

프로덕션 환경에서는 반드시 RBAC를 설정해서 최소 권한 원칙을 적용해야 해. 보안은 아무리 강조해도 지나치지 않아! 🔐

고가용성(HA) Control Plane: • 최소 3개의 Control Plane 노드 (홀수 개 권장)
• etcd 클러스터 구성 (3개 또는 5개)
• 로드 밸런서를 통한 API 서버 분산

Worker Node 구성:
• 워크로드 타입별로 노드 그룹 분리
• Node Taints와 Tolerations 활용
• 리소스 쿼터와 리밋 설정

네트워크:
• CNI 플러그인 선택 (Calico, Flannel, Cilium 등)
• NetworkPolicy로 트래픽 제어
• Ingress Controller 구성

스토리지:
• StorageClass 정의
• 동적 프로비저닝 설정
• 백업 전략 수립

모니터링 & 로깅:
• Prometheus + Grafana로 메트릭 수집
• EFK/ELK 스택으로 로그 수집
• Alerting 설정

이런 구성을 처음부터 직접 하기는 어려울 수 있어. 그럴 때는 재능넷 같은 플랫폼에서 쿠버네티스 전문가의 도움을 받는 것도 좋은 방법이야! 전문가의 컨설팅을 받으면 시행착오를 줄이고 안정적인 클러스터를 구축할 수 있거든. 😊

쿠버네티스는 마이크로서비스 아키텍처와 완벽하게 어울려! 각 마이크로서비스를 독립적인 Deployment로 배포하고, Service로 연결하면 돼.

패턴:
• 각 마이크로서비스는 별도의 Deployment
• Service Mesh (Istio, Linkerd) 도입 고려
• API Gateway 패턴 적용
• 서비스 간 통신은 Service DNS 사용
• ConfigMap/Secret으로 설정 관리
• Namespace로 환경 분리

예시 구조:
• Frontend Service (React/Vue)
• API Gateway (Kong/Ambassador)
• Auth Service
• User Service
• Order Service
• Payment Service
• Notification Service
• Database (StatefulSet 또는 외부 관리형 DB)

각 서비스는 독립적으로 배포, 스케일링, 업데이트할 수 있어! 🚀

쿠버네티스와 CI/CD를 결합하면 진정한 DevOps를 실현할 수 있어!

일반적인 파이프라인:
1. 코드 커밋 (Git)
2. CI 서버가 감지 (Jenkins, GitLab CI, GitHub Actions)
3. 테스트 실행
4. Docker 이미지 빌드
5. 이미지 레지스트리에 푸시
6. Kubernetes manifest 업데이트
7. kubectl apply 또는 Helm upgrade
8. 롤링 업데이트 진행
9. 헬스 체크 확인
10. 문제 발생 시 자동 롤백

GitOps 패턴:
• ArgoCD, Flux 같은 도구 사용
• Git을 단일 진실 공급원(Single Source of Truth)으로
• 선언적 배포
• 자동 동기화

GitOps를 사용하면 배포가 Git 커밋만큼 쉬워져! 🎉

📦 패키지 관리

Helm: 쿠버네티스의 패키지 매니저. 복잡한 애플리케이션을 차트(Chart)로 패키징해서 쉽게 배포하고 관리할 수 있어. apt나 yum 같은 거라고 생각하면 돼!

Kustomize: YAML 파일을 템플릿 없이 커스터마이징하는 도구. 쿠버네티스에 내장되어 있어서 kubectl과 함께 사용할 수 있어.

🌐 Service Mesh

Istio: 가장 인기 있는 서비스 메시. 트래픽 관리, 보안, 관찰성 제공
Linkerd: 경량 서비스 메시. Istio보다 간단하고 빠름
Consul: HashiCorp의 서비스 메시 솔루션

서비스 메시는 마이크로서비스 간 통신을 관리하고, 트래픽 제어, 보안, 모니터링을 제공해!

🔐 보안

Falco: 런타임 보안 모니터링
OPA (Open Policy Agent): 정책 기반 제어
Vault: 시크릿 관리
Cert-Manager: TLS 인증서 자동 관리
Trivy: 컨테이너 이미지 취약점 스캔

🚀 CI/CD

ArgoCD: GitOps 기반 지속적 배포
Flux: GitOps 도구
Tekton: 쿠버네티스 네이티브 CI/CD
Jenkins X: 쿠버네티스용 Jenkins
Spinnaker: 멀티 클라우드 배포 플랫폼

🎛️ 관리 도구

Lens: 쿠버네티스 IDE. 클러스터 관리가 정말 편해져!
K9s: 터미널 기반 쿠버네티스 UI
Octant: VMware의 웹 기반 쿠버네티스 대시보드
Rancher: 멀티 클러스터 관리 플랫폼
Kubeapps: 웹 기반 애플리케이션 배포 도구

🎯 주요 트렌드

1. Edge Computing 지원 강화
K3s, MicroK8s 같은 경량 쿠버네티스 배포판이 인기를 얻고 있어. IoT 디바이스나 엣지 환경에서도 쿠버네티스를 사용할 수 있게 되었지!

2. Serverless와의 통합
Knative 같은 프로젝트를 통해 쿠버네티스 위에서 서버리스 워크로드를 실행할 수 있어. FaaS(Function as a Service)와 컨테이너의 장점을 모두 활용할 수 있지!

3. 멀티 클러스터 관리
여러 클러스터를 하나처럼 관리하는 기술이 발전하고 있어. Cluster API, KubeFed 같은 프로젝트가 이를 가능하게 해.

4. AI/ML 워크로드 지원
Kubeflow 같은 프로젝트를 통해 머신러닝 파이프라인을 쿠버네티스에서 실행할 수 있어. GPU 스케줄링도 점점 더 정교해지고 있지!

5. 보안 강화
Zero Trust 네트워킹, 런타임 보안, 정책 기반 제어 등 보안 기능이 계속 강화되고 있어.

6. 사용성 개선
복잡한 쿠버네티스를 더 쉽게 사용할 수 있도록 다양한 도구와 추상화 레이어가 개발되고 있어. 개발자 경험(DX)이 점점 좋아지고 있지!