1. 쿠버네티스, 운영을 자동화하는 기술의 조타수

선요약

1. 쿠버네티스는 단순히 컨테이너 실행기가 아닌 무중단 배포, 자동 복구, 자동 확장을 지원하는 현대적인 인프라 운영 플랫폼

2. 클러스터는 Control Plane과 Data Plane 으로 나뉘어 실행을 분리한다.

3. 리소스를 만들 때는 선언형 방식 중심으로 설계, 모든 길은 kube-apiserver로 통함

4. 작성한 yaml 설정 파일이 api 서버를 통해 여러 단계를 거쳐 실제 컨테이너 실행

 

쿠버네티스란?

컨테이너 애플리케이션을 자동으로 배포,확장,운영하는 오픈소스 플랫폼

2014년 Google이 오픈소스로 공개하였으며, 현재는 CNCF(Cloud Native Computing Foundation) 주도로 활발히 발전하고 있다.

 

선언적 설정을 통해 사용자가 원하는 상태를 정의 

 

쿠버네티스 사용 이유?

컨테이너의 한계

• 서버 다운시 다운타임 발생 -> 무중단 배포의 한계
• 사용량에 따른 탄력성 이슈 -> 확장 자동화
• 애플리케이션 업데이트시 서비스를 중단하지 않고 새 버전 배포 -> 복구 자동화

-> 컨테이너의 한계점 3가지를 자동화 하고 효율적인 분산 시스템 운영을 하는것이 쿠버네티스

 

쿠버네티스 구조

출처: 인프런_초보자도 딱 10일만에 쿠버네티스 감 잡기

 

Control Plane

두뇌 역할

API 서버, 스케줄러, 컨트롤러 매니저, etcd 등 관리 컴포넌트가 실행된다.

클러스터의 상태를 감시, 조정하여 원하는 상태를 유지 (지휘자)

Control Plane 구성요소

컴포넌트	역할
kube-apiserver	모든 요청의 중심인 HTTP API 서버 (비유하면 컨트롤타워)
etcd	클러스터 상태 데이터를 저장하는 Key-Value 저장소
kube-scheduler	새로운 Pod를 실행할 노드를 선택
kube-controller-manager	여러 컨트롤러(ReplicaSet, Node, Job 등)를 실행
cloud-controller-manager	클라우드 리소스와 통합 (선택적)

Data Plane(Node)

실제 애플리케이션이 동작하는 영역

Data Plane(Node) 구성 요소

컴포넌트	역할
kubelet	API 서버 지시대로 Pod을 생성, 시작, 중지하고, 상태를 주기적으로 보고
kube-proxy	서비스와 Pod 간 트래픽 라우팅 및 로드밸런싱 수행
Container Runtime	컨테이너를 실제로 실행 (예: containerd, CRI-O 등)

 

 

쿠버네티스 리소스 생성 방법

선언형 방식 (Declarative)

원하는 상태를 먼저 정의하면, Kubernetes가 자동으로 실행·조정하는 ( 비유하면 docker compose 방식)

선언형은 코드로 관리되기 때문에 GitOps, 자동화, 버전 관리에도 유리

명령형 방식 (Imperative)

한줄씩 단계별 지시

 

구분	선언형 (Declarative)	명령형 (Imperative)
접근 방식	원하는 상태를 먼저 선언	무엇을, 어떻게 할지 단계별 지시
예시	nginx 컨테이너 3개 유지	지금 nginx 하나 실행, 다음 또 하나...
장점	자동 복구, 일관성 유지, 관리 쉬움	빠르고 직관적이지만 복잡한 운영에 취약
도구	kubectl apply -f xxx.yaml	kubectl run, kubectl delete 등

 

 

kube-apiserver란?

Kubernetes에서 가장 중심이 되는 컴포넌트

kubectl, Helm, CI/CD 파이프라인 등 모든 외부 요청은 이 API 서버를 거칩니다.

즉, kube-apiserver는 쿠버네티스의 관문이자 모든 요청의 입구

 

kube-apiserver 주요 역할

• 요청을 받아들이고 인증/인가 처리
• etcd에 상태 저장 
• 적절한 컨트롤러에게 전달 -> 스케줄러나 컨트롤러 매니저 같은 컴포넌트로 요청을 전달해, 실제 동작이 수행되도록 함

 

용어 정리

• Object: 쿠버네티스 API를 통해 정의되고 클러스터에서 관리되는 구체적인 객체(예: Pod, Deployment, PVC, ConfigMap 등
• Resource: 쿠버네티스 오브젝트의 종류(예: Pod, Deployment) 또는 해당 오브젝트에 접근/조작하기 위한 API 엔드포인트(예: /api/v1/pods)를 의미
• YAML 파일: 리소스의 설정 내용을 작성하는 문서 형식.

리소스 생성 흐름

[User]
  └── kubectl apply
        ↓                # 선언적 상태(Desired State)를 YAML로 API에 전달
[kube-apiserver]
  ├── 인증/인가          # 요청 주체 확인 + RBAC 정책으로 권한 검증
  ├── 유효성 검사        # 스키마 검증 및 Admission Controller 정책 적용
  └── etcd 저장          # 클러스터의 단일 진실 소스로 Desired State 기록
        ↓                # 상태 변경 이벤트 발생 (watch 기반)
[Controller Manager]
  └── Deployment Controller
        └── ReplicaSet 생성   # 원하는 replica 수를 유지하기 위한 중간 리소스
              └── Pod 생성     # 실제 실행 단위(Pod) 생성 (아직 Node 미할당)
                    ↓          # 스케줄링 대기 상태 (Pending)
[Scheduler]
  └── Node 선택          # 리소스, affinity, taint/toleration 기반 최적 Node 결정
        ↓                # Pod에 Node 바인딩 (binding)
[Worker Node]
  ├── kubelet
  │     └── 실행 지시     # API Server에서 PodSpec 받아 컨테이너 실행 관리
  └── Container Runtime
        └── 이미지 Pull + 컨테이너 실행  # 실제 프로세스 생성 (ex: containerd)

 

즉, 작성한 YAML 설정이 API 요청으로 전달되어, 여러 컴포넌트를 거쳐 실행 중인 컨테이너로 변환

 

쿠버네티스 설정파일(yaml)

[Pod 예시]
apiVersion: v1          # 사용할 Kubernetes API 버전 (Core API 그룹)
kind: Pod              # 생성할 리소스 타입 (여기서는 Pod 단일 실행 단위)
metadata:
  name: hello-pod      # 리소스 이름 (클러스터 내에서 식별자 역할)
spec:                  # 실제 동작 정의 영역 (Desired State의 핵심)
  containers:
    - name: hello      # 컨테이너 이름 (Pod 내부에서 구분용)
      image: nginx     # 사용할 컨테이너 이미지 (Docker Hub 등에서 Pull)

 

 

---

본 글은 강의 내용을 기반으로 학습한 내용을 정리한 글입니다.

https://www.inflearn.com/challenge/%EC%B4%88%EB%B3%B4%EC%9E%90%EB%8F%84-%EB%94%B1-10%EC%9D%BC%EB%A7%8C%EC%97%90-%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EA%B0%90/dashboard?cid=339301

초보자도 딱 10일만에 쿠버네티스 감 잡기 챌린지 | 감잡아주는테크트레이너 - 인프런