코알못

[kubernetes] 쿠버네티스 Pod, Label, Selector 소개 본문

ETC

[kubernetes] 쿠버네티스 Pod, Label, Selector 소개

코린이s 2023. 5. 7. 15:22
728x90

파드가 무엇인지 보자!

Pod는 콩껍질이라는 뜻으로 안에 콩은 컨테이너라고 생각 하면 된다.

풀이 해보자면 여러 컨테이너를 담을 수 있는 가장 기본적인 배포 단위로 노드 하나에 1개 이상의 Pod를 배치 할 수 있다.

Pod는 노드에서 유일한 IP가 할당 되며 Pod 내부에서 컨테이너간에 localhost로 통신 가능하다.

Pod IP는 클러스터 내에서만 유효하며 외부에서 접근하기 위해서는 Service 또는 Ingress 오브젝트가 필요하다.

컨테이너의 라이프사이클이 같고, 스케일링 요구 사항(예를 들어 트래픽이 비슷한)이 같고, 인프라 활용도가 더 높아지는 방향으로 묶는것이 좋다.(파드가 너무 크다면 노드에 남은 리소스가 있더라도 맞지 않으면 배치 되지 않아 노드 활용도가 떨어지므로 적절하게 묶는것이 좋다.)

이제 파드가 노드에 배포 되는 과정을 보자!

Pod 노드 배포 과정

순서 설명
사용자가 Pod 생성 요청을 한다.
요청 받은 Pod 수와 현재 생성된 Pod수와 비교하며 Replica를 생성한다.(처음 생성 요청이라면 현재 생성수가 0이므로 요청수만큼 생성 한다.)
Pod 를 배포할 노드를 선택한다.
선택된 노드에 Pod 생성 요청을 한다.
컨테이너 런타임(현재는 도커)에게 이미지 다운 하도록 명령하고, Pod 실행 준비 및 상태 업데이트 한다.

이제 Pod 생성 관련 yaml 파일을 보자!

apiVersion: v1 					# kubernetes API 버전
kind: Pod      					# 오브젝트 타입
metadata:      					# 오브젝트를 유일하게 식별하기 위한 정보
  name: kube-basic 				# 오브젝트 이름
  labels:						# 오브젝트 구분값
    app: kube-basic	
    project: fastcampus
  spec:							# 사용자가 원하는 스펙
    nodeSelector:				# Pod를 배포할 노드 (gpu가 true인 노드에만 배포)
    	gpu: "true"
    containers:					# Pod 안에서 실행할 컨테이너
    -name: kube-basic			# 컨테이너 이름 
     image: kube-basic:1.0		# 도커 이미지 주소
     imagePullPolicy: "Always"	# 도커 이미지 다운 정책(Always/IfNotPresent/Naver)
     ports:         
     -containerPort: 80			# 통신에 사용할 컨테이너 포트
     volumeMounts:				# 컨테이너 볼륨 마운트
     -name: html				# 볼륨명
      mountPath: /var/html		# 마운트 경로
     -name: html
      mountPath: /usr/share		# 볼륨명은 같으나 마운트는 다르게 줄 수 있음
      readOnly: true
     env:						# 컨테이너 환경 변수 목록
     -name: PROFILE				# 환경변수명
      value: production			# 환경변수값
     -name: LOG_DIRECTORY
      value: /logs
     -name: MESSAGE				
      value: env is ${PROFILE}	# 다른 환경변수값 참조
    volumes:					# 컨테이너가 사용할 볼륨
    -name: host-volume			# 볼륨 이름
     hostPath:					# 볼륨 타입
       path: /data/mysql		# 볼륨 경로

도커 이미지 다운 정책은 세가지가 있으며 설명은 아래와 같다!

도커 이미지 다운 정책 설명
Always 항상 이미지 다운로드
IfNoyPresent 일치하는 이미지가 노드에 있다면 다운로드 하지 않음
Naver 다운로드 하지 않음

추가로 아래와 같은 질문이 있을수 있다.

파드가 종료 된다면? ReplicaSet 오브젝트 사용시 자동으로 복구 된다.

Pod 생성 할 때 마다 IP가 변경되니 외부에서 접근하려면? > Service 오브젝트 이용

Pod, Container는 어떻게 구조를 잡아야 하나 ? > 기본적으로 1:1로 하나 특별한 사유가 있을시 1:N 구조를 고민한다.

이제 Lable, Selector를 알아보자!

Label(=이름표)은 쿠버네티스 오브젝트를 식별하기 위한 Key/Value 쌍의 메타 정보로

Selector(=선택방법) query로 Label 조건을 넣어 원하는 리소스 집합을 구할 수 있다.

예를 들어 Label의 'gpu' 키의 값이 'true'인 값만 pod 생성하고 싶다면 Selector query를 통해 해당 집합만 배포할 수 있다

파드의 라벨값을 확인하고자 하면 아래와 같이 확인 가능하다.

$ kubectl get pod my-pod --show-labels

만약 Label값이 너무 많아서 몇개만 선택하여 보고 싶다면 아래와 같이 조회한다.

$ kubectl get pod/my-pod --label-columns app,env # app, env 라벨만 확인
$ kubectl get pod/my-pod -L app,env

Label을 붙이는것도 가능하다.

$ kubectl label pod my-pod app=backend
$ kubectl get pod my-pod --show-labels
NAME		READY	STATUS		LABELS
my-pod		1/1		Running		app=backend

이미 Label의 키값이 존재하여 오류가 발생한다면 overwrite 옵션을 붙여 진행하면 된다.

$ kubectl label pod my-pod version=v2 --overwrite

Label을 삭제하고 싶다면 아래와 같이 - 를 붙인다.

$ kubectl lavel pod/my-pod app-

이제 selector 를 이용하여 라벨을 조회해보자!

$ kubectl get pod --show-labels
NAME	READY	STATUS	LABELS
pod1	1/1	Running	env=dev
pod2	1/1	Running	env=stage
pod3	1/1	Running	env=prod
pod4	1/1	Running	env=prod
pod5	1/1	Running

만약 여기서 env 가 prod 인 값만 조회한다면 아래와 같다.

$ kubectl get pod --selector env=prod
NAME	READY	STATUS	LABELS
pod3	1/1	Running	env=prod
pod4	1/1	Running	env=prod

만약 env 가 pod 가 아닌값을 조회하면 env Label 이 없어도 조회 된다.

$ kubectl get pod --selector env!=prod
NAME	READY	STATUS	LABELS
pod1	1/1	Running	env=dev
pod2	1/1	Running	env=stage
pod5	1/1	Running

새로운 Lable 을 추가해보자!

$ kubectl label pod pod1 pod2 pod3 app=backend
NAME	READY	STATUS	LABELS
pod1	1/1	Running	app=backend,env=dev
pod2	1/1	Running	app=backend,env=stage
pod3	1/1	Running	app=backend,env=prod
pod4	1/1	Running	env=prod
pod5	1/1	Running

이제 app이 backend 이면서 env 가 prod 인 pod 를 검색해보자!

$ kubectl get pod --selector app=backend,env=prod
NAME	READY	STATUS	LABELS
pod3	1/1	Running	app=backend,env=prod

이제 app이 backend가 아니고 env 가 prod 인 pod 를 검색해보자!

$ kubectl get pod --selector app!=backend,env=prod
NAME	READY	STATUS	LABELS
pod4	1/1	Running	env=prod

이제 app이 backend가 아니고 env가 prod가 아닌 pod 를 검색해보자!

$ kubectl get pod --selector app!=backend,env!=prod
NAME	READY	STATUS	LABELS
pod5	1/1	Running

이제 env가 dev 또는 stage 또는 prod 인 pod 를 조회한다.

$ kubectl get pod --selector 'env in (dev,stage,prod)'
NAME	READY	STATUS	LABELS
pod1	1/1	Running	app=backend,env=dev
pod2	1/1	Running	app=backend,env=stage
pod3	1/1	Running	app=backend,env=prod
pod4	1/1	Running	env=prod

이제 env가 dev,stage,prod 가 아닌 pod 를 조회한다.

$ kubectl get pod --selector 'env notin (dev,stage,prod)'
NAME	READY	STATUS	LABELS
pod5	1/1	Running

이제 env 키값이 있는 pod를 조회한다.

$ kubectl get pod --selector env
NAME	READY	STATUS	LABELS
pod1	1/1	Running	app=backend,env=dev
pod2	1/1	Running	app=backend,env=stage
pod3	1/1	Running	app=backend,env=prod
pod4	1/1	Running	env=prod

app 이 backend 이면서 env 가 dev 또는 stage 인 값을 조회한다.

$ kubectl get pod --selector app=backend,env in (dev,stage)
NAME	READY	STATUS	LABELS
pod1	1/1	Running	app=backend,env=dev
pod2	1/1	Running	app=backend,env=stage

 env 가 dev, stage 가 아닌 파드만 조회한다.

$ kubectl get pod --selector 'env notin (dev,stage)'
NAME	READY	STATUS	LABELS
pod3	1/1	Running	app=backend,env=prod
pod4	1/1	Running	env=prod
pod5	1/1	Running

 env 가 dev, stage 가 아니며 env 키값이 있는 파드만 조회한다.

$ kubectl get pod --selector 'env,env notin (dev,stage)'
NAME	READY	STATUS	LABELS
pod3	1/1	Running	app=backend,env=prod
pod4	1/1	Running	env=prod

끝!

728x90
Comments