Pod
- Pod은 쿠버네티스에서 관리하는 가장 작은 배포 단위이다.
- 쿠버네티스와 도커의 차이점은 도커는 컨테이너를 만들지만, 쿠버네티스는 컨테이너 대신 Pod을 만든다. Pod은 한 개 또는 여러 개의 컨테이너를 포함한다.
빠르게 Pod 만들기
kubectl run
kubectl run echo --image ghcr.io/subicura/echo:v1
→ echo 라는 이름의 pod이 생성됨
Pod이 생성되는 과정

Scheduler
는 API서버를 감시하면서 할당되지 않은Pod
이 있는지 체크
Scheduler
는 할당되지 않은Pod
을 감지하고 적절한노드
에 할당 (minikube는 단일 노드)
- 노드에 설치된
kubelet
은 자신의 노드에 할당된Pod
이 있는지 체크
kubelet
은Scheduler
에 의해 자신에게 할당된Pod
의 정보를 확인하고 컨테이너 생성
kubelet
은 자신에게 할당된Pod
의 상태를API 서버
에 전달
YAML로 설정파일(Spec) 작성하기
실무에서는 kubectl run 명령어는 거의 사용하지 않음(복잡하고 다양한 설정이 필요할때, 복잡해지고 관리가 어렵기 때문) → YAML 파일로 작성하면 복잡한 내용을 표현하기 좋고, 변경된 내용을 버전 관리할 수 있다.
// YAML 설정파일 예시 : echo_pod.yml apiVersion: v1 kind: Pod metadata: name: echo labels: app: echo spec: containers: - name: app image: ghcr.io/subicura/echo:v1

version
, kind
, metadata
, spec
는 리소스를 정의할 때 반드시 필요한 요소이다.컨테이너 상태 모니터링
livenessProbe
- 컨테이너가 정상적으로 동작하는지 체크하고 정상적으로 동작하지 않는다면 컨테이너를 재시작하여 문제를 해결한다.
- 정상 확인에는 여러 방식이 있는데, 밑의 예시는 http get 요청을 보내 확인하는 방법을 사용함
readinessProbe
- 컨테이너가 준비되었는지 체크하고 정상적으로 준비되지 않았다면 Pod으로 들어오는 요청을 제외한다.
- livenessProbe와 차이점은 문제가 있어도 Pod을 재시작하지 않고 요청만 제외한다는 것
⇒ 보통
livenessProbe
와 readinessProbe
를 같이 적용한다apiVersion: v1 kind: Pod metadata: name: echo-health labels: app: echo spec: containers: - name: app image: ghcr.io/subicura/echo:v1 livenessProbe: httpGet: path: / port: 3000 readinessProbe: httpGet: path: / port: 3000
다중 컨테이너
대부분은 1 Pod = 1 컨테이너지만, 여러개의 컨테이너를 가진 경우도 많다.
하나의 Pod에 속한 컨테이너는 서로 네트워크를 localhost로 공유하고 동일한 디렉토리를 공유할 수 있다.
apiVersion: v1 kind: Pod metadata: name: counter labels: app: counter spec: containers: - name: app image: ghcr.io/subicura/counter:latest env: - name: REDIS_HOST value: "localhost" - name: db image: redis
→ 같은 Pod 안에 컨테이너 생성되었으므로, counter 앱은 redis를 localhost로 접근할 수 있다.
Share article