출저 : Udemy Docker & Kubernetes 실전 가이드
Pod
쿠버네티스의 용어이고 쿠버네티스에서 가장 작은 단위입니다. 혼자 또는 함께 작동해야하는 컨테이너들을 보유합니다.
하나 이상의 애플리케이션 컨테이너와 컨테이너 속한 모든 리소스를 호스팅합니다. 실행하기 위한 구성 뿐만 아니라 볼륨과 같은 것도 리소스에 포함됩니다.
어플리케이션 컨테이너 뿐만 아니라 pod가 실행될 때 실행되는 init 컨테이너가 포함될 수 있습니다.
Pod 예시
Nginx:1.14.2 이미지를 실행하는 컨테이너로 구성된 Pod의 예시
# simple-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80Workload resource for managing pods
일반적으로 pod는 직접 생성하지 않고 워크로드의 리소스(Deployment or Job)를 사용하여 생성합니다.
Deployment
지속적으로 유지하며 실행되어야 하는 애플리케이션 또는 서비스 관리를 위해 사용됩니다.
지정된 수의 Pods 복제본을 유지하면서 스케일링, 롤아웃을 관리할 수 있습니다.
모니터링, 스케일링, 롤아웃에 대한 설정을 제어할 수 있습니다.
Job
일회성 작업(DB Migration 등)이나 배치 작업(배치 처리 작업 등)을 실행하기 위해 사용됩니다.
하나 이상의 Pod를 생성해서 특정 작업을 실행하고 작업이 성공적으로 완료되면 pod를 종료합니다.
작업의 성공, 실패 여부와 재시도 횟수, 리소스 정리 등을 설정을 제어할 수 있습니다.
Pod는 주어진 애플리케이션의 단일 인스턴스를 실행하기 위한 것입니다. 애플리케이션을 수평으로 확장하려면 각 인스턴스마다 하나의 pod를 사용해야 합니다. 이것을 k8s에서는 일반적으로 replication(복제)이라 합니다.
복제된 pod는 워크로드 리소스와 그 컨트롤러에 의해 그룹으로 생성되고 관리됩니다.
Working with Pods
Pod가 이러식으로 직접 생성하는 방식이 드문 이유는 pod가 비교적 일시적이고 일회용 엔티티로 설계되어서 입니다.
pod가 (어떠한 방식으로든)생성되면 클러스터 내의 노드 중 하나에서 실행되도록 예약이 되고
- 실행을 마칠 때까지
- pod객체가 삭제될 때 까지
- 리소스 부족으로 pod가 추방될 때 까지
- 할당된 노드에 문제가 생기기 전까지
해당 노드에 남아 있습니다.
주의사항
pod는 컨테이너가 아닌 컨테이너를 실행하기 위한 '환경'이라는 점입니다. pod 내 컨테이너를 재시작 하는 것과 pod를 재시작 하는 것은 다릅니다.
- 컨테이너 재시작은 k8s에서 자동으로 재시작할 수 있습니다.
- pod를 재시작 한다는 것은 존재하는 pod를 종료하고 동일한 설정으로 새로운 pod를 생성하는 것을 의미합니다.
(pod의 재시작은 '삭제 후 생성')
Pod name & DNS
- pod name은 클러스터 내에서 pod의 식별하는데 사용됩니다. 이 이름은 유효한 DNS 서브도메인 값이어야 합니다.
- Pod name은 host name으로 사용될 수 있지만 항상은 아닙니다.
nginx_pod와 같이_가 포함되어 있다면 DNS 서브도메인으로 가능하지만 host name은 될 수 없습니다. - 최상의 호환성을 위해선 DNS label에 대한 규칙을 준수해야 합니다.
Pod OS
Pod 운영체제를 지정하려면 .spec.os.name 필드를 window, linux 하나로 설정해야 합니다. (2024.03.26 기준 두 개만 가능함)
- 이 설정이 pod의 스케줄링에 영향을 주지 않습니다.
- 운영체제 식별에 도움, 검증을 위해 사용됩니다.
- pod의 운영체제가 실행중인 노드와 다른 os라면
kubelet이 pod 실행을 거부합니다.
Pods & Controllers
워크로드 리소스를 사용해서 여러 파드를 생성하고 관리할 수 있습니다. 복제, 롤아웃, 자동 복구 등을 담당합니다.
대표적인 워크로드 리소스
Deployment
애플리케이션의 상태를 지속적으로 유지하며 실행해야 하는 경우 사용합니다. stateless 애플리케이션에 주로 사용되며, 애플리케이션의 복제본을 유지하고 자동으로 스케일링하며, 업데이트를 관리할 수 있습니다.
StatefulSet
Pod에 영구적인 식별자와 스토리지를 제공해서 stateful 애플리케이션을 실행하는데 적합합니다. 이는 각 인스턴스가 고유한 데이터를 관리해야 하는 데이터베이스 클러스터와 같은 애플리케이션에 주로 사용됩니다.
DaemonSet
클러스터의 모든 노드(또는 지정된 노드들)에서 하나의 파드 복사본을 실행해야 할 때 사용됩니다. 이는 각 노드에서 로그 수집기나 모니터링 에이전트와 같은 백그라운드 서비스를 실행하는 데 유용합니다.
Proxy
워커 노드의 포드 네트워크 트래픽 제어를 설정하는 또다른 도구입니다. 간단히 말하면 컨테이너에 접근하는 트래픽에 대한 설정을 관리합니다.
node
하나 이상의 포드를 호스팅하는 특정 하드웨어 용량을 가지며 클러스터와 통신하거나 클러스터 내에서 통신하는 물리 또는 가상의 머신입니다.
Worker node
한 개 이상의 Pod를 실행하는 주체입니다. ECS 개념 글에서 EC2 인스턴스의 역할을 한다고 비교해볼 수 있습니다. Pod와 Proxy를 포함합니다.
트래픽 분산을 목적으로 보통 하나 이상의 복제 컨테이너를 가지고 있습니다.
워커 노드는 인터넷 어딘가의 특정량의 CPU와 메모리 머신일 뿐입니다.
때문에 이런 워커 노드가 실행될 수 있도록 여러 소프트웨어를 가지고 있어야 합니다.
Software
kubelet : 마스터 노드와의 통신을 하기 위한 소프트웨어입니다.
Docker : 컨테이너 관련 기능을 담당합니다. 쿠버네티스에서 컨테이너를 생성하다면 docker run을 명령한 것과 같습니다.
Proxy : 워커 노드의 트래픽을 관리합니다.
Master node
모든 워커 노드와 그 노드에서 실행되는 포드(컨테이너)를 제어해야 합니다. 마스터 노드는 이런 모든 워커 노드를 컨트롤합니다.
워커 노드처럼 어떤 앱을 실행시키는 목적이 아닌 다른 서버, 다른 리모트 머신입니다.
software
API Server : 마스터 노드가 가지고 있는 가장 중요한 소프트웨어입니다. 워커 노드에서 실행되는 kubelet 서비스에 대한 연결점입니다.
Scheduler : 포드를 관찰하고 새 포드가 생성되어야 하는 워커 노드를 선택합니다. 포드가 비정상적으로 다운되었거나 스케일링이 필요할 때 워커 노드에게 무엇을 알려야 하는지 API Server에게 알리는 역할을 합니다.
Kube-Controller-Manager : 워커 노드 전체를 감시하고 제어하며 적당한 수의 포드가 가동중인지 확인하는 역할을 합니다.
이를 위해 Scheduler와 밀접하게 연동됩니다.
Cloud-Controller-Manager : 클라우드 프로바이더에게 무엇을 할 지 알려줍니다. 명령을 번역하여 배포를 위한 서비스를 자동화해줍니다.
Control Plane
마스터 노드가 워커 노드를 컨트롤하기 위한 컨트롤 센터입니다. 컨테이너, 포드를 만들고 시작하고, 충돌로 인한 정지된 컨테이너 교체, 종료 등을 담당합니다.
워커 노드와 상호작용하여 제어합니다. 스스로 실행하는 것이 아닌 이러한 제어를 워커 노드에게 전달합니다.
Service
포드들의 논리적 집합입니다. 포드들의 고유 IP주소 그룹이라 볼 수 있고 자연스럽게 프록시와 관련이 있음을 알 수 있습니다.
특정 포드를 외부로 노출하여 IP 또는 도메인으로 연결할 수 있도록 하기위한 용어로도 볼 수 있습니다.
Cluster
위의 구성요소 전체를 포함하여 형성된 묶음입니다. 클러스터 내의 모든 노드끼리 네트워크를 형성합니다. 그리고 마스터 노드는 클라우드 프로바이더 API에게 명령을 보내 클러스터의 최종 상태를 클라우드 프로바이더에게 복제하도록 지시할 수 있습니다.
즉, 배포 혹은 원하는 최종 상태를 구성하는 모든 것의 컬렉션 세트입니다.
