쿠버네티스(1) - 파드

1-1 파드의 개념

• 파드란 컨테이너를 표현하는 쿠버네티스의 API의 최소단위
• Pod에는 하나 또는 여러 개의 컨테이너가 포함될 수 있음
  Pod안에 여러 컨테이너가 존재하더라도 Pod의 IP는 무저건 하나다.
• 2가지 파드 생성방법
  • 1. kubectl run 명령어
  • 2. pod yaml을 이용해서 생성

multiple pod

apiVersion: v1
kind: Pod
metadata:
  name: multipod
spec:
  containers:
  - name: nginx-container1
    image: nginx:1.14
    ports:
      - containerPort: 80
  - name: nginx-container2
    image: nginx:1.14
    ports:
      - containerPort: 81

 

1-2 파드 동작 Flow

파드 동작 Flow

• Pod는 스케줄링 받을때까지는 pending 상태에 머물게 된다.
• 파드의 상태로그를 보고싶으면 $kubectl get pod -o wide —watch

 

1-3 livenessPorbe를 사용한 self-healing Pod

livenessProbe란?

• livenessPorbe은 Pod가 계속 실행할 수 있음을 보장
• livenessPorbe는 Pod의 spec에 정의 파드의 port 80에 http 프로토콜 get으로 “/” 에 신호를 보내서 응답이 잘되는지 확인한다. 확인을 3번하는데 3번다 응답코드가 정상적이 않다면 쿠버네티스는 pod를 삭제한 후 image를 다시 pull해서 container를 restart한다. 컨테이너를 restart한다. 컨테이너, 파드아니다!!!

livenessProbe

livenessProbe 매커니즘

애플리케이션마다 건강검진하는 법은 다르다.
따라서 쿠버네티스는 3가지 형태로 livenessPorbe를 제공하고있다.
이것은 livenessProbe 메커니즘이라고 부른다.

 

liveness probe 매개변수

• periodSeconds: health check 반복 실행시간 (초)
• initialDelaySeconds: Pod 실행 후 delay할 시간(초)
• timeoutSeconds: health check후 응답을 기다리는 시간(초)
• success=1 // 한번 성공하면 성공으로 본다는 뜻
• failrue=3 // 3번실패하면 실패로 본다는 뜻 (연속검사x, periodSeconds 시간 지날때마다 검사)

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/liveness
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

$ kubectl get pod nginx-pod-liveness -o yaml로 liveness probe 값들 확인가능 

 

Probe (liveness probe, readinessProbe, startupProbe)

1. Readiness Probe: Pod가 트래픽을 받을 준비가 되었는지 확인합니다.
2. Startup Probe: 애플리케이션이 완전히 시작되었는지 확인합니다.

위에서 liveness probe를 소개했지만, liveness probe외에도 readinessProbe, startupProbe등이 있다.

Probe는 컨테이너에서 kubelet에 의해 주기적으로 수행되는 진단이다.

이 Probe를 통해 쿠버네티스는 각 컨테이너의 상태를 주기적으로 체크한 후,
문제가 있는 컨테이너를 자동으로 재시작하거나 또는 문제가 있는 컨테이너를 서비스에서 제외할 수 있다.

kubelet은 컨테이너의 상태를 진단하기 위해 핸들러를 호출하는데 핸들러는 수행하는 작업의 분류에 따라서
ExecAction, TCPSocketAction, HttpGetAction로 나뉜다.

 

1-4 init container

• init 컨테이너는 메인 컨테이너가 실행하기 이전의 전에 미리 동작시킬 컨테이너이다.
• intit 컨테이너는 메인 컨테이너가 실행되기 전에 사전 작업이 필요한 경우 사용한다.
• 메인 컨테이너는 init 컨테이너가 모두 실행된 후에 실행된다.

# myapp.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app.kubernetes.io/name: MyApp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
  - name: init-mydb
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]

위의 파드 myapp-pod.yaml을 보면 init 컨테이너가 2개가 있다. 
각각의 init 컨테이너는 myservice와 mydb라는 도메인의 정보를 검색하는 컨테이너로 
도메인을 찾을때까지 무한루프를 도는 형태이다.
현재는 myservice와 mydb라는 것이 도메인등록이 안됬기 때문에 init 컨테이너들이 계속 무한루프를
돌고있어서 메인 컨테이너가 실행되지 못한다.
하지만 myservice와 mydb를 도메인에 등록해주면 init-myservice와 init-mydb컨테이너가 실행되고
그 다음에 메인 컨테이너인 myapp-pod가 실행될 수 있다.

밑의 services.yaml파일은 myservice와 mydb를 도메인으로 등록해주기 위한 파일이다.
# services.yaml
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
---
apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9377

 

1-5 infra container(pause)

• 파드를 생성하면 무저건 생기는 container가 있는데 그게 바로 pause container이다.
• pause container는 파드에 대한 인프라 ip, hostname etc 등등 관리하고 생성해준다.
• 이 pause container의 존재를 몰라도 사실 크게 문제는 없다. 그냥 이러한 컨테이너가 존재한다는 것만 알면될꺼같다.

 

1-6 static pod

• static pod는 기존의 Pod 와 동작방식이 조금은 다르다.1-1 파드의 개념
• static pod는 클러스터의 각 노드에서 직접 실행되며 API 서버와의 관계 없이 kubelet에 의해 관리된다.
• 주로 시스템 레벨의 파드나, kubelet 자체가 실행해야 하는 중요한 파드를 static pod로 정의하여 사용한다.
• static pod는 각 노드의 /etc/kubernetes/manifests 디렉토리나 다른 지정된 디렉토리에 YAML 파일 형식으로 정의됩니다.
  •  

1-7 Pod에 resource 할당하기

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: myimage
    resources:
      requests:
        memory: "256Mi"
        cpu: "100m"
      limits:
        memory: "512Mi"
        cpu: "200m"

• requests: Pod이 요청하는 최소 리소스 양을 설정한다. 예를 들어, 이 Pod은 최소 256Mi 메모리와 100m CPU를 요청한다.
• limits: Pod이 사용할 수 있는 최대 리소스 양을 설정한다. 예를 들어, 이 Pod은 최대 512Mi 메모리와 200m CPU를 사용할 수 있다.

 

1-8 환경변수를 이용해 컨테이너에 데이터 전달하기

 

Kubernetes에서 파드에 환경변수를 설정하는 방법은 크게 세 가지입니다

1. Pod YAML 파일에 직접 설정하기
2. ConfigMap을 사용하여 설정하기
3. Secret을 사용하여 설정하기

 

1. Pod YAML 파일에 직접 설정하기

spec:
  containers:
  - name: mycontainer
    image: myimage
    env:
      - name: DEMO_ENV_VAR
        value: "example_value"

 

 

2. ConfigMap을 사용하여 설정하기

spec:
  containers:
  - name: mycontainer
    image: myimage
    envFrom:
      - configMapRef:
          name: myconfigmap

 

 

3. Secret을 사용하여 설정하기

spec:
  containers:
  - name: mycontainer
    image: myimage
    envFrom:
      - secretRef:
          name: mysecret