Kubernetes Pod

https://subicura.com/k8s/guide/pod.html

Pod

 

 

Pod

 

Pod는 쿠버네티스에서 관리하는 가장 작은 배포 단위.

 

Pod는 run 명령어로 직접 만들수도 있지만 거의 그렇게 하지 않는다.

원하는 리소스를 yml 파일로 작성하고 apply 명령어로 실행한다.

 

yaml로 설정파일 작성

echo.yml

apiVersion: v1
kind: Pod
metadata:
  name: echo
  labels:
    app: echo
spec:
  containers:
    - name: app
      image: ghcr.io/subicura/echo:v1

 

 

 

필수요소

version	오브젝트 버전	v1, app/v1, networking.k8s.io/v1, ...
kind	종류	Pod, ReplicaSet, Deployment, Service, ...
metadata	메타데이터	name과 label, annotation(주석)으로 구성
spec	상세명세	리소스 종류마다 다름

 

위의 4가지는 yml 파일에서 스펙을 정의할때 필수적으로 들어가야 한다.

 

 

위의 yml 파일을 apply 로 실행했다.

get all 로 보면 echo pod 이 생성 된걸 볼 수 있다.

 

# Pod 생성
kubectl apply -f echo-pod.yml

# Pod 목록 조회
kubectl get pod

# Pod 로그 확인
kubectl logs echo
kubectl logs -f echo

# Pod 컨테이너 접속
kubectl exec -it echo -- sh
# ls
# ps
# exit

# Pod 제거
kubectl delete -f echo-pod.yml

 

 

---

 

컨테이너 상태 모니터링

docker-compose 에서 app,db 두 개의 서비스가 있을때 depends_on 으로 app 컨테이너 실행이 db 컨테이너 실행 이후에 되도록 보장받을수 있다.

 

하지만 이건 app 컨테이너 실행이 db 컨테이너 실행 이후를 보장 받을 뿐이고, db 컨테이너는 실행되었지만 컨테이너 내부에서 db 자체는 아직 준비 완료 상태가 아닐 수 있다.

 

쿠버네티스는 컨테이너가 생성되고 서비스 준비가 완료 되었다는 옵션을 제공해 초기화되는 동안 서비스되는 것을 막을수 있다.

 

livenessProbe

컨테이너가 정상적으로 동작하는지 확인하고, 정상적으로 동작하지 않는다면 컨테이너를 재시작한다.

정상 상태인지는 여러가지 방식으로 체크할수 있는데 여기서는 HTTP GET 요청을 보내 확인하는 방법이다.

 

apiVersion: v1
kind: Pod
metadata:
  name: echo-lp
  labels:
    app: echo
spec:
  containers:
    - name: app
      image: ghcr.io/subicura/echo:v1
      livenessProbe:
        httpGet:
          path: /not/exist
          port: 8080
        initialDelaySeconds: 5
        timeoutSeconds: 2 # Default 1
        periodSeconds: 5 # Defaults 10
        failureThreshold: 1 # Defaults 3

 

livenessProbe:

  httpGet:

    path: /not/exist

    port: 8080

 

8080 포트의 /not/exist 경로에 GET 요청을 보내 응답 받는다면 정상, 못받으면 비정상으로 판단한다.

 

 

yml 파일을 apply 한 후에, get pod 으로 상태를 확인해보자.

뭔가 문재가 있어 두번 재시작했고, 상태는 CrashLoopBackOff 이다.

 

테스트를 위한 /not/exist 경로에는 아무것도 없기 때문에 비정상으로 판단해서 재시작하고 있는 것이다.

 

readinessProbe

컨테이너가 준비되었는지 체크하고 정상적으로 준비되지 않았다면 Pod으로 들어오는 요청을 제외한다.

livenessProbe는 체크 후 정상적으로 준비 되지 않았다면 재시작 하는 반면 

readinessProbe는 재시작 하지 않고 요청만 제외한다.

 

apiVersion: v1
kind: Pod
metadata:
  name: echo-rp
  labels:
    app: echo
spec:
  containers:
    - name: app
      image: ghcr.io/subicura/echo:v1
      readinessProbe:
        httpGet:
          path: /not/exist
          port: 8080
        initialDelaySeconds: 5
        timeoutSeconds: 2 # Default 1
        periodSeconds: 5 # Defaults 10
        failureThreshold: 1 # Defaults 3

 

 

readinessProbe를 적용한 echo-rp.yml 을 apply 한 결과다.

 

echo-rp 는 RESTARTS=0 으로 재시작하지 않고 STATUS=Running 으로 아직 pod 이 실행중이다.

그리고 READY=0/1 로 준비가 되지 않아 접속을 막고 있다.

 

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

 

 

path: / 로 정상적인 경로를 health check 로 설정했기 때문에 READY 상태이다.

 

---

다중 컨테이너

하나의 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

 

이름이 app, db 인 두 개의 컨테이너가 있다.

그런데 보면 app이 db에 접근할때 "localhost" 로 접근한다.

 

이 두 개의 컨테이너들은 하나의 pod 에 속해있기 때문에 네트워크를 localhost 로 공유할수 있다.

 

---

 

kubectl delete -f [pod 이름| url | yml 파일] 로 pod 를 삭제

 

./ 로 현재 디렉토리의 모든 yml 파일에 대한 pod를 삭제한다.