1. 개요

쿠버네티스는 컨테이너의 자동 배포, 스케일링, 운영을 위한 오케스트레이션 플랫폼이다.

• 2014년에 구글에서 개발한 컨테이너 관리 플랫폼
• 채 10년이 안되는 시간에 컨테이너 생태계 지배
• 개발을 위한 효율성을 대폭 증가시킴
  • 개발 환경 구축 시간, 분리된 공간으로 실험 환경 구성 가능

💡단일 노드 기반이었던 도커 환경에서 → 멀티 노드 기반으로 넘어가게 되는 기점

노드(VM 머신)가 여러 개 → 중앙 컨트롤러

1-1. 특징

1. 컨테이너 서비스의 자동화
   1. 컨테이너의 배포, 스케일링, 롤백 등을 자동으로 수행
   2. 사람의 개입 없이 안정적인 운영 가능
2. 운영의 안정성과 복구력 강화
   1. 장애가 발생한 컨테이너를 자동 감지 → 복구
   2. 필요한 만큼의 컨테이너 수 항상 유지
3. 배포/업데이트의 유연함
   1. 롤링 업데이트로 무중단 배포(Zero Downtime Deployment) 가능
   2. 롤백을 통한 문제 발생 이전 버전으로 복원
4. 확장성 및 자원 효율성
   1. 여러 대의 기기를 하나의 클러스터 형태로 구성하여 운영
   2. 사용 가능한 자원을 고려하여 컨테이너를 자동으로 배치

1-2. 도커 vs 쿠버네티스

역할

• 도커: 컨테이너 생성, 실행, 배포를 위한 엔진
  • 컨테이너를 실행하는 주체
• 쿠버네티스 : 컨테이너들을 자동화, 관리하기 위한 플랫폼
  • 컨테이너 관리 → 생성 및 실행 X
  • 초기에는 도커를 사용했지만 최근에는 containerd 라는 솔루션을 사용
    • 도커도 내부적으로 containerd 기술 사용

containerd : 컨테이너의 실행, 삭제, 생성하는 데 필요한 핵심 기능을 제공하는 오픈소스 프로젝트

• 컨테이너의 —name 옵션으로 이름을 지정하는 것과 같은 부가 기능들은 docker가 사용자 편의성을 위해 제공하는 것
  • 즉, containerd는 이름 지정 같은 옵션이 없고 순수 실행,삭제,생성 등의 작업만 수행

운영 환경

• 도커 : 단일 노드에서의 컨테이너 서비스 실행에 초점
• 쿠버네티스 : 다중 노드를 하나의 시스템처럼 관리

1-3. 쿠버네티스의 필요성

기존 도커 기반 시스템의 문제점

1. 배포해야 될 서비스가 수백 개, 대상 머신이 수백 개인 경우 사람이 모두 처리하는 것이 어려움
2. 수많은 서비스에서 발생하는 에러, 이슈 처리에 어려움
3. 도커에서 발생하는 보안 문제점

1-3-1. 자동 스케줄링

별도의 노드를 수동으로 선택할 필요 없이 자동으로 컨테이너 서비스를 배치

• 쿠버네티스는 클러스터 내 가용 자원을 알아서 판단 후 실행될 환경을 선택해 컨테이너를 배치

💡수백 개의 노드가 존재하는 상황에서 컨테이너를 실행해야 할 때 어떤 노드에 이를 배치해야 할지 알아서 관리해준다.

• 차례대로 할당
• 가용 자원이 가장 많은 노드에 할당 등

1-3-2. 자가 치유

수동으로 컨테이너 상태를 체크할 필요 없이, 자동으로 안정성 유지

• 쿠버네티스는 비정상적인 컨테이너를 자동으로 감지하여 재시작시켜 줌

1-3-3. 롤링 업데이트 및 롤백

기존 서비스를 중단하지 않고 새로운 버전의 컨테이너를 교체, 복원 가능

• 자가 치유와 동일한 동작 방식을 갖음

1-3-4. 구성 외부화

환경변수, 설정 파일 등의 민감 정보를 이미지에 포함시키지 않고 외부에서 지원

• ConfigMap, Secret 을 통해 설정을 외부에서 구성하고, 이를 컨테이너가 참조할 수 있도록 지원

• 도커에서 환경 변수를 일일이 정의하던 작업을 하나의 configMap, Secret 등에 정의 후 공유해서 사용 가능

1-3-5. 보안 및 접근 제어

API 접근 권한을 RBAC 으로 정교하게 제어 가능

• RBAC : Roll Based Access Control

---

2. 주요 개념

2-1. 주요 기능

• 자동 확장, 축소
• 로드 밸런싱, 자동 롤링 배포
• 자가 치유, 영속성 볼륨, 컨테이너 관리

2-1-1. Kubernets Reconciliation Model

원하는 상태와 현재 상태를 비교해 원하는 상태로 자동 업데이트

기존 도커를 사용할 때는 도커에게 직접 명령을 내렸다.

docker run ubuntu

쿠버네티스는 직접 명령을 하는 것이 아니라, “이렇게 됐으면 좋겠어(desirable)” 라고 지시하면, 이를 만족할 때 까지 진행

1. 현재 상태를 계속 모니터링한다.
2. 현재 상태와 원하는 상태를 비교한다.
3. 다른 경우 원하는 상태로 조정한다.

💡이렇게 desirable한 방식으로 동작하기 때문에 오토 스케일링, 로드 밸런서, 무중단 배포 등과 같은 여러 기능들을 구현 가능

2-2. 쿠버네티스 아키텍처

2-2-1. 마스터 노드 (컨트롤 플레인 - Control Plane)

클러스터에 관한 전반적인 결정을 수행하고 클러스터의 이벤트를 감지 및 반응하는 노드

💡아래 4가지 구성 요소를 포함하며, 이렇게 모인 집합을 컨트롤 플레인이라고 함

1. kube-apiserver (API 서버)
   1. Control Plane의 프론트엔드 역할
   2. 쿠버네티스 API의 중추 역할
   3. 모든 클러스터와의 상호작용을 담당
      1. 클러스터 상태 조회, 변경
2. kube-scheduler
   1. 노드가 배정되지 않은 새로 생성된 Pod를 감지하고, 이를 실행할 노드 선택
   2. Pod를 적절한 노드에 할당
3. kube-controller-manager
   1. 컨테이너 관리, 노드 다운 시 통지 및 대응
   2. 컨테이너 수를 사용자가 원하는 상태만큼 조절
   3. 시스템 네임스페이스 관리
4. etcd
   1. 쿠버네티스에 필요한 모든 데이터를 Key-Value 형태로 저장하는 데이터베이스
   2. configmap, secret 같은 파일들이 여기 포함

2-2-2. 워커 노드

동작 중인 컨테이너를 유지시키고 쿠버네티스 런타임 환경 제공

아래 3가지 구성요소를 가짐

1. kubelet
   1. 워커 노드에서 실행되는 에이전트
   2. 컨트롤 플레인에서 전달된 명령을 실제 수행
   3. 각 노드에서 Pod를 실행하고 파드의 상태를 API 서버에 보고
2. kube-proxy
   1. 네트워크 프록시
   2. 서비스와 파드 간의 네트워크 트래픽 관리
   3. 포트 포워딩 같은 기능 수행
3. container runtime
   1. (e.g. Docker, containerd 구동)
   2. 실제로 컨테이너를 실행하는 소프트웨어
   3. 각 워커 노드에는 컨테이너 런타임이 설치되어 있으며, 이를 통해 쿠버네티스에 정의된 파드를 실행
   4. kubelet과 협력

2-3. 오브젝트

• 리소스의 가장 기본적인 구성 단위
• 시스템에서 영속성을 가지는 객체

2-3-1. 기본 오브젝트

1. Pod
   1. 가장 기본적인 배포 단위로, 하나의 Pod은 하나의 노드에만 배치됨
   2. 한 개의 Pod 안에는 여러 개의 컨테이너를 포함 가능
      1. 이때 IP와 Port, Volume을 공유 -> 파드 내 컨테이너는 한 개의 IP 주소를 가짐
2. Service
   1. 클러스터 내에서 실행 중인 Pod들을 내부, 외부 클러스터의 Pod와 연결해주는 추상화된 네트워크
   2. 외부 네트워크와 내부 네트워크의 Endpoint 관리
   3. 잦은 Pod 교체에도 네트워크 상태 유지
   4. 도커 bridge 확장 버전으로 이해하자.
3. Volume
   1. 논리 디스크, 잦은 Pod 교체에도 디스크의 영속성 보장
4. Namespace
   1. 클러스터 내 논리적인 공간 단위, 개별 접근 권한 및 리소스 할당량 제어

💡도커의 네임 스페이스와 쿠버네티스의 네임 스페이스는 다름

• 도커 네임스페이스 : 프로세스 가상화를 위한 리눅스 커널 기술로, 운영체제 수준의 가상화 기술임
• 쿠버네티스 네임스페이스 : 클러스터 관리 기술로, 클러스터 자원 관리 및 조직화를 위한 논리적 구분임

기본 오브젝트 : 파드, 서비스, 볼륨, 네임 스페이스

---

2-4. 컨트롤러

오브젝트의 상태가 의도된 상태로 잘 동작하는지 추적

• 잘 동작하는지 추적하고, 만약 의도한대로 동작하지 않으면 의도한 상태로 만드는 역할 -> Kubernetess Reconciliation Model
  

2-4-1. 컨트롤러 종류

1. Replica Set
   1. Pod 집합의 실행을 항상 안정적으로 유지하는 컨트롤러
   2. 명시된 Pod 개수에 대한 가용성을 보증함
   3. ‘정원사’에 비유하고, 정해진 수의 꽃이 정원에 있도록 관리하는 관리자
2. Deployment
   1. Pod와 ReplicaSet에 대한 선언적 업데이트를 제공하는 컨트롤러
   2. ReplicaSet이 의도한 Pod의 개수를 조정
   3. ReplicaSet의 Roll-Out을 통해 시스템의 스케일 관리
   4. ‘자동 업데이트 관리자’에 비유하고, "앱을 v2 버전으로 배포해줘" 라고 선언하면, 기존 버전을 새 버전으로 안전하게 교체해주는 관리자

💡컨트롤러로 레플리카 셋과 디플로이먼트가 가장 많이 사용되고, 레플리카는 컨테이너 수 → Pod 를 관리하고, 디플로이먼트 컨트롤러는 레플리카 컨트롤러를 관리한다고 보면 된다.

• 레플리카 셋 : 개수 조정
• 디플로이먼트 : 부가적인 것 조절

3. DaemonSet
   1. Replica와 비슷하지만, 노드마다 Pod의 개수만큼 실행
   2. 애플리케이션이 클러스터 전체 노드나 특정 집합에서 동작할 때 사용
   3. 시스템, Security 컨테이너들이 사용
      1. 각각의 머신에서 컨테이너들의 리소스 사용량을 추적하고자 할 때 유용
      2. 서버(노드)마다 한 개의 Pod을 배포하여 데이터 수집
4. StatefulSet
   1. Deployment와 유사하게 스케일링을 관리
   2. Pod들의 순서 보장
   3. 애플리케이션의 순차적인 배포에 적합
   4. 도커의 depends_on과 유사
5. Job
   1. 하나 이상의 Pod를 생성하고 저장된 수의 Pod가 성공적으로 종료될 때까지 계속해서 Pod의 실행을 재시도
   2. Pod가 성공적으로 완료 → 완료된 Job을 추적
   3. Job이 성공적으로 완료 → Job이 완료된 상태로 변경
   4. Job 을 삭제하면 Job이 생성한 Pod도 정리
   5. 항시 운영이 되는 서비스가 아니라, 한 번 돌았다가 끝나는 구조(ex 배치)
      1. 일회성 작업

---

3. 주요 용어

3-1. 파드(Pod)

컨테이너가 실행되는 쿠버네티스의 가장 작은 배포 단위

• 하나 이상의 컨테이너가 동일한 네트워크/스토리지를 공유하거 함께 실행됨
  • 애플리케이션의 실행 단위를 캡슐화하여 배포를 용이하게 함
• 스케줄링 및 제어를 담당하는 구성 요소들 또한 파드 단위로 구성되어 역할을 수행
  • api-server, scheduler, controller 등 제어 노드에 파드 형태로 설치되어 동작

3-2. 노드(Node)

클러스터에서 파드를 실행시키는 물리/가상 머신의 단위

• 각 노드에 설치된 kublet, kube-proxy, container 런타임 등을 통해 파드의 실행을 담당
  • 클러스터 내에서 실제 애플리케이션이 구동되는 실행 환경을 제공

3-3. 클러스터(Cluster)

하나 이상의 노드들을 하나로 묶어 리소스를 통합적으로 관리하는 단위

• 컨트롤 플레인 및 워커 노드로 구성되어 전체 시스템을 제어하고 파드를 분산 배포 수행
  • 확장성 및 고가용성을 갖춘 대규모 애플리케이션 인프라를 구성 가능

3-4. 서비스(Service)

파드에 고정된 접근 경로를 제공하는 네트워크 리소스

• IP나 이름이 수시로 변경되는 Pod 대신에 클라이언트가 항상 접근할 수 있는 추상화 계층 제공
  • 파드의 변경이나 확장과 무관하게 안정적인 접근을 가능하게 함
  • 로드밸런싱도 자동으로 변경

• 로드밸런서 -> 노드포트 -> 클러스터 IP 순으로 외부와 통신

---

Pod

• 쿠버네티스가 사용하는 기본 단위 (도커에서는 컨테이너)

💡그럼 파드랑 컨테이너랑 같은 것인가?🤔

• 하나의 파드 안에는 여러 개의 컨테이너 포함 가능
• 보조 컨테이너가 생길 수 있음.
  • SideCar(SubContainer)
  • mini container : 실행 전 설정해야 하는 서비스를 미리 실행
• 하나의 컨테이너 + α ⇒ Pod
  • 알파에 해당하는 서브 컨테이너들은 네트워크/스토리지를 공유해서 사용

💡
쿠버네티스 디자인 원칙에 따라 보통 하나의 Pod 안에는 하나의 주요 컨테이너만 배치한다. 그리고 필요에 따라 보조 컨테이너(SideCar) 등을 함께 넣는다.

🧠 대표적인 다중 컨테이너 사용 예시

예시	main	sidecar
로그 수집	앱 서버	Fluentd
보안	웹 서버	IDS/IPS 프록시
프록시	앱	Envoy/Nginx
파일 변환기	업로더	이미지 리사이저

5. 기본 명령어

kubectl

쿠버네티스 클러스터를 제어하기 위한 CLI 도구

• 기본적으로 kubectl [action][resource] [name]의 명령어 구조를 가짐
• 명령어는 kube-apiserver로 전달 후, 인증-인가-검증 과정을 거쳐 스케줄러, 컨트롤러 등에 반영
  • kubectl → kube-apiserver → scheduler → controller

클러스터 노드 상태 확인, 실행 정보 확인

• kubectl get nodes
• kubectl cluster-info

리소스 조회

• kubectl get pods

파드 목록 조회

1. -n 옵션 : 해당 네임스페이스에 설치된 파드 목록 확인
   1. kubectl get pods -n kube-system
2. -A 옵션 : 모든 네임스페이스에 설치된 파드 목록 확인
   1. kubectl get pods -A

• kubectl get svc
  • 서비스 목록 확인
• kubectl get all
  • 특정 네임스페이스 내 모든 리소스의 목록 확인
• kubectl describe pod [podname]
  • 특정 파드에 대한 상세 정보 조회
  • 특정 네임스페이스에 존재하는 파드의 경우 -n 옵션을 사용하여 네임스페이스 명시
• kubectl logs [PODNAME]
  • 파드 내 컨테이너의 로그 출력
• kubectl run [pod]
• 특정 파드를 빠르게 실행
  • --image 옵션을 통해 파드를 생성할 때 사용할 대상 이미지를 명시
    • 주로 테스트 용도로 파드를 임시 실행할 때 사용
• kubectl apply -f [file].yaml
  • Yaml 파일을 통해 파드를 포함한 리소스 들을 선언적 방식으로 생성 또는 수정