쿠버네티스 Pod [2]

yoongyum·2022년 5월 15일

k8s pod 쿠버네티스

쿠버네티스 삽질하기 🚢

목록 보기

6/9

pod의 기능에 대해 이어서 실습해보겠습니다.

🪧 실행 명령 및 파라미터 지정

Pod 생성 시, 실행 명령과 파라미터를 전달할 수 있습니다.

지금까지는 nginx이미지의 기본 실행 명령만 사용했습니다.

하지만 사용자가 원하는 명령으로 바꿔서 실행할 수도 있습니다.

nginx이미지에 실행 명령과 파라미터를 수정했을 때 Pod가 어떻게 동작하는지 살펴보겠습니다.

cmd.yaml

apiVersion: v1
kind: Pod
metadata:
	name: cmd
spec:
	restartPolicy: OnFailure
	containers:
    - name: nginx
      image: nginx
      command: ["/bin/echo"]
      args: ["hello"]

restartPolicy는 Pod의 재시작 정책을 설정합니다. 설정 옵션 3가지가 있습니다.

Always: Pod의 재시작 정책을 설정합니다.
Never: 재시작 시도를 하지 않습니다.
OnFailure: 실패 시에만 재시작을 시도합니다.

command는 컨테이너의 시작 실행 명령을 지정합니다. Docker의 ENTRYPOINT와 대응되는 property입니다.

args는 실행 명령에 넘겨줄 파라미터를 지정합니다. Docker의 CMD에 대응되는 property입니다.

echo 명령은 실행 후 종료되기 때문에 실패 시 (OnFailure)에만 재시작합니다. 그렇지 않으면 계속 반복해서 명령이 실행됩니다.

🪢 환경변수 설정

이번에는 Pod에 환경변수를 전달하는 법을 실습해보겠습니다.

env property를 활용하여 환경변수를 설정할 수 있습니다.

env.yaml

apiVersion: v1
kind: Pod
metadata:
	name: env
spec:
	containers:
    - name: nginx
      image: nginx
      env:
      - name: hello
        value: "world!"

env는 환경변수를 설정하는 property를 선언합니다.

name: 환경변수의 key입니다.
value: 환경변수의 value입니다.

Pod을 생성후 exec 명령으로 실행중인 env Pod에 printenv명령을 전달합니다.

🛢️ 볼륨 연결

Pod의 내부 스토리지의 생명주기는 Pod가 사라지면 저장된 데이터도 함께 삭제됩니다.

Pod내에서 생성된 데이터를 Pod생명주기와 상관없이 지속적으로 생성하려면 볼륨을 따로 연결해야 합니다.

쿠버네티스에는 여러가지 볼륨 타입이 존재합니다.

그중 가장 기본이 되는 host Volume을 사용하겠습니다.
host Volume은 도커의 -v 옵션과 유사하게 host서버의 볼륨 공간에 Pod가 데이터를 저장하는 것입니다.

volume.yaml

apiVersion: v1
kind: Pod
metadata:
	name: volume
spec:
	containers:
    - name: nginx
      image: nginx
      
      volumeMounts:
      - mountPath: /container-volume
      	name: my-volume
        
    volumes:
    - name: my-volume
   	  hostPath:
      	path: /home

volumeMounts은 컨테이너 내부에 사용될 볼륨을 선언합니다.

mountPath: 컨테이너 내부에 볼륨이 연결될 위치를 지정합니다.
name: volumeMounts와 volumes를 연결하는 식별자로 사용합니다.

volumes는 Pod에서 사용할 volume을 지정합니다.

name: volumeMounts와 volumes를 연결하는 식별자로 사용합니다.
hostPath: 호스트 서버의 연결 위치를 지정합니다.

volume Pod를 생성해서 /container-volume내부를 살펴보면 호스트 서버의 /home과 동일한 것을 확인할 수 있습니다.

🎚️ 리소스 관리

쿠버네티스는 컨테이너 실행에 필요한 리소스(일반적으로 Cpu와 Ram 등)를 resources property를 활용하여 리소스를 관리합니다.

resources에는 2가지 관리 기능이 있습니다.

1. requests

requests는 최소 리소스 사용량을 지정해주는 property입니다.

requests.yaml

apiVersion: v1
kind: Pod
metadata: 
	name: requests
spec:
	containers:
    - name: nginx
      image: nginx
      resources:
      	requests:
        	cpu: "250m"
            memory: "500Mi"

cpu는 1000m 당 1core를 나타냅니다. 즉, 250m = 0.25core를 뜻합니다.

memory의 mi는 1MiB(2^20 Bytes)단위를 나타냅니다.

2. limits

limits는 최대 리소스 사용량을 지정해주는 property입니다.

limits.yaml

apiVersion: v1
kind: Pod
metadata:
	name: limits
spec:
	restartPolicy: Never
    containers:
    - name: mynginx
      image: python:3.7
      command: [ "python" ]
      args: [ "-c", "arr = []\nwhile True: arr.append(range(1000))" ]
      resources:
      	limits:
        	cpu: "500m"
            memory: "1Gi"

컨테이너가 최대 리소스 사용량을 넘게 사용하면 CPU인 경우 throttling이 발생하고, 메모리인 경우 Out of Memory 에러가 발생합니다.

Pod를 생성한 후 watch kubectl get pod명령어를 사용하여 컨테이너 정보를 몇초간격으로 확인합니다.
(ctrl + c로 종료할 수 있습니다.)

args에 while True문을 넣어서 파이썬 스크립트가 무한히 메모리 리소스를 사용하게 됩니다.

무한히 메모리를 소비하다가 최대 메모리 제한에 도달하면 강제로 프로세스가 중단되는 것을 확인할 수 있습니다.

쿠버네티스는 이러한 기능을 통해서 해당 프로세스만 특정적으로 관리할 수 있기 때문에 안정적인 운영이 가능합니다.

requests와 limits를 조합해서 최대/최소 사용량을 지정할 수도 있습니다.

❤️ 상태확인 (health check)

이번에는 Pod이 정상적으로 동작하고 있는지 health check를 해보겠습니다.

💛 livenessProbe

livenessProbe Property를 사용하면 컨테이너가 정상 동작하고 있는 지 확인할 수 있습니다.

쿠버네티스는 livenessProbe를 통해 자가치유 판단 기준으로 사용합니다.

liveness.yaml

apiVersion: v1
kind: Pod
metadata:
	name: liveness
spec:
	containers:
    - name: nginx
      image: nginx
      livenessProbe:
      	httpGet:
        	path: /live
            port: 80

httpGet는 HTTP GET 메서드로 healthcheck를 합니다.

path: HTTP PATH를 지정합니다.
port: HTTP 포트를 지정합니다.

위 명세서에서 HTTP GET을 사용하여 /live 위치의 80번 포트를 지속적으로 호출합니다.

HTTP 리턴코드로 200-300번대 응답코드를 정상으로 판단하고, 그 이외는 비정상으로 판단해서 종료되고 재시작합니다.

RESTARTS가 계속 증가하는 것을 보실 수 있습니다.
로그확인을 해봅니다.

$ kubectl logs -f liveness

nginx에는 /live라는 API가 존재하지 않기 때문에 /live 호출에 404에러코드를 반환을 받아서 Pod가 정상적이지 않다고 판단을 하게 됩니다. 따라서 Pod를 강제로 재시작하여 RESTARTS가 증가하고 있는 이유로 보시면 됩니다.

live파일을 생성해서 정상적으로 호출에 응답하도록 해보겠습니다.

$ kubectl exec liveness -- touch /usr/share/nginx/html/live

$ kubectl logs liveness

/live 호출에 200으로 응답하여 더 이상 재시작을 하지 않습니다.

💛 readinessProbe

livenessProbe는 Pod가 살아있는지 확인하는 용도라면 readinessProbe는 Pod를 생성한 직후, 트래픽을 받을 준비가 완료되었는지 확인하는 property입니다.

Jenkins서버와 같이 처음 구동하는데 시간이 오래 걸리는 웹서비스라면 구동이 완료된 이후에 트래픽을 받아야합니다.

이런 경우, 해당 Pod의 초기화가 완료되었다는 정보를 쿠버네티스에게 알리는 용도로 사용됩니다.

readiness.yaml

apiVersion: v1
kind: Pod
metadata:
	name: readiness
spec:
	containers:
    - name: nginx
      image: nginx
      readinessProbe:
      	httpGet:
        	path: /ready
            port: 80

아래 코드를 실행합니다.

$ kubectl apply -f readiness.yaml

$ kubectl logs -f readiness

마찬가지로 /read가 존재하지 않아서 404에러 코드를 응답하여 준비상태가 0입니다.

read 파일을 생성하면 준비상태가 1이 됩니다.

livenessProbe, readinessProbe안에 exec(명령 실행)을 통해서도 정상여부를 확인할 수 있습니다.

readiness-cmd.yaml

apiVersion: v1
kind: Pod
metadata:
	name: readiness-cmd
spec:
	containers:
    - name: nginx
      image: nginx
      readinessProbe:
      	exec:
        	command:
            - cat
            - /tmp/ready