[CKA] 9. POD

Date

2024/11/12

POD

•

쿠버네티스는 Worker Node에 직접 컨테이너를 배포하지 않음

•

쿠버네티스에서는 컨테이너를 Pod라는 객체에 캡슐화됨

•

Pod는 애플리케이션의 단일 인스턴스이며, 쿠버네티스에서의 가장 작은 객체이다

•

일반적으로 Pod는 앱을 실행하는 컨테이너와 1대1 관계를 갖는다

◦

스케일업 - 새 Pod 생성

◦

스케일다운 - 기존 Pod 제거

◦

스케일 업을 위해 기존 Pod에 컨테이너를 추가하지 않음

스케일업

•

액세스가 증가하여 앱 규모를 늘려야 할 경우

◦

Load를 공유하려면 웹 앱의 추가 인스턴스를 생성해야함

▪

같은 Pod 내에서 새 컨테이너 인스턴스를 생성 X

▪

같은 애플리케이션의 새로운 인스턴스로 새로운 Pod 생성

•

액세스가 더 증가했고, Node가 충분한 용량을 확보하지 못한 경우

◦

Node에 새로운 Pod를 생성할 용량이 없으니 다른 Node에 추가 Pod를 배포함

Multi-Container PODs

•

한 Pod 내에 여러 컨테이너일 수 있지만 드문 케이스임

•

Pod 내의 컨테이너는 localhost로 서로 직접 통신이 가능함

•

Storage Space도 공유 가능

•

이때는 같은 종류의 컨테이너가 여러 개가 아닌 다른 종류의 컨테이너를 담음

◦

스케일업을 위해선 Pod를 추가 생성하기 때문

•

한 Pod 내에 여러 컨테이너를 두는 시나리오 예시:

◦

웹 애플리케이션을 지원하는 Helper Container

▪

데이터 처리 프로세스

배포

•

kubectl run <container-name> --image=<image-name> 

◦

Docker 이미지의 인스턴스 기반 Docker 컨테이너 배포

•

kubectl get pods

◦

Pod 목록 확인

◦

Pod의 상태를 확인할 수 있음

•

단순히 Pod만 배포된 상태에선 외부 사용자에게 웹 서버 액세스를 제공하지 않음

•

내적으로 액세스는 가능

•

kubectl describe pod <pod-name>

◦

Pod 생성 시간

◦

Label

◦

내장 컨테이너

◦

Pod Events

POD With YAML

•

쿠버네티스는 YAML 파일을 Pod, Replicas, Deployment, Service 등 객체 생성을 위한 입력으로 사용

•

yaml 사용시 공백을 잘 맞춰야 함

◦

2 spaces와 tab을 사용할 수 있는데 2칸 공백을 추천함

Root Level Properties

•

쿠버네티스 정의 파일은 항상 4개의 상위 레벨 필드를 포함

◦

필수 필드이므로, 구성 파일에 반드시 존재해야 함

I. apiVersion

•

생성할 때 사용하는 쿠버네티스 API 버전

•

만드려는게 무엇이냐에 따라 올바른 API 버전을 사용해야 함

◦

POD - v1

◦

Service - v1

◦

ReplicaSet - apps/v1

◦

Deployment - apps/v1

II. kind

•

생성하려는 객체의 유형

III. metadata

•

객체 위의 데이터

◦

name, labels, 등등

•

apiVersion, kind 같은 문자열과 달리 딕셔너리 형태를 가짐

•

name은 String을 값으로 가지고, labels는 딕셔너리를 값으로 가짐

•

labels은 객체를 식별하는데 도움이 됨

◦

예시로 FE, BE 애플리케이션을 labels를 통해 필터링할 수 있음

IV. spec

•

생성하려는 객체에 따라 쿠버네티스에 그 객체에 관련된 정보를 제공

•

딕셔너리를 값으로 가짐

•

Pod 생성시 containers 라는 property 필요

◦

containers는 List/Array을 가짐

◦

- 로 리스트를 나눔

◦

리스트를 가지는 이유는 한 Pod 안에 여러 컨테이너를 담을 수 있기 때문