on
4. Pod(1)
4. Pod(1)
4.1 Pod란
출처 : 수비쿠라님 youtube https://www.youtube.com/watch?v=-gIyfII5eak&ab;_channel=44BITS
Pod는 쿠버네티스 최소 실행 단위 입니다. 쿠버네티스는 Pod를 통해 기본 가상환경을 제공합니다.
가상환경 플랫폼 실행단위
가상머신 : Instance
도커 : Container
쿠버네티스 : Pod
Pod 특징
1개 이상의 컨테이너 실행 : 보통 한 개 Pod내에 한 개 컨테이너를 실행합니다. 이론상 3개까지 가능하지만 그런경우는 드뭅니다
동일 노드에 할당 : Pod 내에 실행되는 컨테이너들은 반드시 동일한 노드에 할당되며 동일한 생명주기를 갖습니다.
고유의 Pod IP : 노드 IP와 별개로 클러스터 내에서 접근 가능한 고유의 IP를 할당 받습니다. 쿠버네티스에서는 다른 노드에 위치한 Pod여도 NAT 없이 고유의 IP를 이용하여 접근합니다.
IP 공유 : Pod 내에 있는 컨테이너들은 서로 IP를 공유 합니다.
volume 공유 : Pod안의 컨테이너들은 동일한 볼륨과 연결이 가능하여 파일 시스템을 기반으로 파일을 주고 받습니다.
Pod yaml 정의서
--dry-run, -o yaml 옵션을 사용하면 Pod를 실제 생성하지 않고 템플릿 파일을 생성할 수 있습니다.
# mynginx.yaml 이라는 yaml 정의서 생성
kubectl run mynginx --image nginx --dry-run=client -o yaml > mynginx.yaml
vim mynginx.yaml
# mynginx.yaml
apiVersion: v1
kind: Pod
metadata:
labels:
run: mynginx
name: mynginx
spec:
containers:
- image: nginx
name: mynginx
restartpolicy: Never
apiVersion : 리소스의 이름이 동일한 경우, 이름 충돌을 피하기 위해 scope를 정의
kind : 리소스 타입
metadata : 리소스 메타정보 labels : 리소스 라벨 정보 name : 리소스 이름(mynginx)
spec : 리소스 스펙. 리소스마다 다르게 정의 containers : 1개 이상의 컨테이너를 정의 name : 컨테이너 이름 image : 컨테이너 이미지의 주소
kubectl apply -f mynginx.yaml
# pod/mynginx created
4.2 라벨링 시스템
라벨링 시스템은 쿠버네티스에서 굉장히 중요합니다. 특정 리소스를 참조하기 위해 라벨링 시스템을 이용하기도 하고 Pod에 트래픽을 전달할 때도 사용합니다. key, value 형태의 문자열을 Pod의 metadata property에 추가하는 것입니다. 이 라벨을 다양하게 활용할 수 있습니다.
라벨 정보 부여
# label 명령을 이용하는 방법
kubectl label pod =
# 선언형 명령을 이용하는 방법
cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
# hello=world 라벨 지정
labels:
hello: world
run: mynginx
name: mynginx
spec:
containers:
- image: nginx
name: mynginx
EOF
라벨 정보 확인
Pod에 부여된 라벨을 확인하기 위해서 -L 옵션을 사용합니다. 특정 라벨이 아닌 전체 라벨을 확인은 --show-labels 옵션을 사용합니다.
# 키 run에 대한 값 표시
kubectl get pod mynginx -L run
# 모든 라벨 정보 표시
kubectl get pod mynginx -- show-labels
라벨을 이용한 조건 필터링
특정 라벨을 가진 Pod만 필터해서 보기 원한다면 -l 옵션을 사용합니다. 특정 key를 기준으로 필터 할 수 있으며 key, value 전체를 이용하여 필터링 가능합니다.
kubectl get pod -l
kubectl get pod -l =
nodeSelector를 이용한 노드 선택
라벨링 시스템을 이용하여 pod가 특정 노드에 할당되도록 스케줄링할 수 있습니다. 사용자가 별도 지정 없이 pod를 생성하면 마스터가 판단하여 스케줄링합니다.
하지만 간혹 특정 노드를 명시적으로 선택해서 실행시켜야 하는 경우도 있습니다.
노드 그룹
만약 2개 이상의 노드에 동일한 라벨이 부여되어 있는 경우, 쿠버네티스가 노드의 상태(리소스 사용량 등)를 확인하여 최적의 노드를 선택합니다.
# node-selector pod 예시
apiVersion: v1
kind: Pod
metadata:
name: node-selector
spec:
containers:
- name: nginx
image: nginx
# 특정 노드 라벨 선택
nodeSelector:
disktype: ssd
4.3 실행 명령 및 파라미터 지정
pod 생성할 때 실행 명령과 파라미터를 전달할 수 있습니다.
# cmd.yaml
apiVersion: v1
kind: Pod
metadata:
name: cmd
spec:
restartPolicy: OnFailure
containers:
- name: nginx
image: nginx
# 실행 명령
command: ["/bin/echo"]
# 파라미터
args: ["hello"]
command : 컨테이너 시작 실행 명령 지정. 도커의 ENTRYPOINT
args : 실행 명령에 넘겨줄 파라미터를 지정. 도커의 CMD
restartPolicy : pod의 재시작 정책 설정 Always: Pod 종료 시 항상 재시작 시도(default 값) Never: 재시작 시도하지 않음 OnFailure :실패 시에만 재시작 시도
4.4 환경변수 설정
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 명령으로 실행중인 pod에 rpintenv 명령을 전달합니다.
kubectl apply -f env.yaml
# 환경변수 hello 확인
kubectl env -- printenv | grep hello
4.5 볼륨 연결
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
# host 서버의 연결 위치 지정
volumes:
- name: my-volume
hostPath:
path: /home
voluemMounts: 컨테이너 내부에 사용될 볼륨 선언 mounthPath: 컨테이너 내부에 볼륨이 연결될 위치 지정(/container-volume) name: volumeMounts와 volumes를 연결하는 식별자(my-volume)
volumes: pod에서 사용할 volume 지정 name: volumeMounts와 volumes를 연결하는 식별자(my-volume) hostPath: 호스트 서버의 연결 위치 지정(/home)
# 다음 실행의 결과가 같음
kubectl exec volume -- ls /container-volume
ls /home
호스트 서버의 디렉터리를 연결하는 hostPath 외에 pod내에 임시로 생성하는 emptyDir도 존재합니다. emptyDir volume은 주로 컨테이너 끼리 파일 데이터를 주고받을 때 자주 사용합니다.
# volume-empty.yaml
apiVersion: v1
kind: Pod
metadata:
name: volume-empty
spec:
containers:
- name: nginx
image: nginx
# 컨테이너 내부의 연결 위치 지정
volumeMounts:
- mountPath: /container-volume
name: my-volume
# host 서버의 연결 위치 지정
volumes:
- name: my-volume
emptyDir: {}
emptDir : pod의 생명 주기를 따라가는 임시 volume입니다. 컨테이너 내부에 데이터를 저장하는것과 다르지 않지만 2개의 이상의 컨테이너가 서로 디렉터리 공간을 공유할 수 있다는 차이점이 있습니다.
4.6 리소스 관리
쿠버네티스는 컨테이너 실행에 필요한 리소스를 resources라는 property로 관리합니다. 최소 리소스 사용량을 보장해주는 requests, 최대 리소스 사용량을 제한하는 limits property 가 있습니다.
requests
# requests.yaml
apiVersion: v1
kind: Pod
metadata:
name: requests
spec:
containers:
- name: nginx
image: nginx
resources:
requests:
cpu: "250m"
memory: 500Mi"
requests: 최소 리소스 사용량 cpu: CPU 최소 사용량 memory: 메모리 최소 사용량
cpu에서 1000m은 1core 이므로 예제에서 250m은 0.25core, memory에서 Mi는 1MiB(2^20 bytes)
limits
# limits.yaml
apiVersion: v1
kind: Pod
metadata:
name: limits
spec:
restartPolicy: Never
containers:
- name: nginx
image: nginx
resources:
limits:
cpu: "500m"
memory: "1Gi"
limits : 최대 리소스 사용량 cpu : CPU 최대 사용량 memory : 메모리 최대 사용량
컨테이너가 최대 리소스 사용량을 넘게되면 CPU인 경우에는 throttling, 메모리는 Out of Memory 에러가 발생합니다. 최대 메모리 시소스 사용량을 넘으면 강제로 프로세스가 중단됩니다. 이러한 기능을 통해 특정 프로세스의 리소스 소진이 전체 서버에 영향을 주지 않아 안정된 운영이 가능합니다.
5.7 상태 확인(health check)
livenessProbe
쿠버네티스가 정상적으로 살아있는지 확인하기위해 livenessProbe property를 이용합니다. Pod가 정상적으로 동작하는지 확인하며 자가치유를 위한 판단기준이 됩니다.
# liveness.yaml
apiVersion: v1
kind: Pod
metadata:
name: liveness
spec:
containers:
- name: nginx
image: nginx
livenessProbe:
httpGet:
path: /test
port: 80
livenessProbe : Pod가 정상적으로 동작하는지 확인 httpGet : HTTP GET method를 이용하여 상태 확인을 합니다. path : HTTP PATH를 지정합니다. port : HTTP 포트를 지정합니다.
HTTP 프로토콜의 GET method를 이용하여 /live 위치의 80 포트를 지속적으로 호출합니다. HTTP 리턴 코드가 2~300번대인 응답코드는 정상 판단, 그 외의 코드는 비정상으로 판단하여 컨테이너가 종료되고 재시작됩니다.
해당 예제의 Pod를 생성하면 nginx에는 기본적으로 /test 라는 api가 없기 때문에 계속해서 404 에러를 반환하면서 Pod의 Restarts 값이 증가 합니다. test 파일을 생성하여 정상 응답하도록 수정해야합니다.
kubectl exec liveness -- touch /usr/share/nginx/html/test
readinessProbe
livenessProbe가 Pod가 살아있는지 확인하는 용도라면, readinessProbe는 Pod가 생성 직후 트래픽을 받을 준비가 되었는지 확인하는 property입니다. 해당 Pod의 초기화가 완료되었다는 것을 쿠버네티스에 알려줍니다.
# readiness.yaml
apiVersion: v1
metadata:
name: readiness
spec:
containers:
- name: nginx
image: nginx
readinessProbe:
httpGet:
path: /ready
port: 80
readinessProbe: Pod의 준비 완료를 확인합니다. httpGet: HTTP GET method를 이용합니다.
path: HTTP PATH(/ready)를 지정합니다. port: HTTP 포트를 지정합니다.
from http://minimun92.tistory.com/60 by ccl(A) rewrite - 2021-09-13 03:26:35