쿠버네티스 구성요소(2/5) - Pod 구성 및 특징

Pod (파드)

컨테이너화 된 애플리케이션 오브젝트 

쿠버네티스에서 배포할 수 있는 가장 기본적인 단위

즉, 컨테이너를 여러개로 묶어서 관리하는 배포하는 단위  (컨테이너 서비스들을 담는 그릇)

워커노드 안에서 실행되는 컨테이너들의 집합

쿠버네티스는 컨테이너를  pod라는 단위로 묶어서 한꺼번에 배포할 수 있음
그래서 컨테이너들을 개별적으로 관리하는게 아니라 pod라는 단위로 묶어서 컨테이너들을 관리함

출처 subicura.com/2019/05/19/kubernetes-basic-1.html

1) pod 구성

한개 이상의 컨테이너를 가지고 있음 (일반적으로 1pod 1Container)

스토리지, 네트워크 속성을 가지고 서로 공유하고 있음  

 

 

 

2) pod 특징 

 한 개 이상의 컨테이너를 묶어서 배포한다 
예를 들어 nginx,wsgi, django 컨테이너가 하나의 pod안에 들어가서 한꺼번에 띄울 수 있음

또는 아래 그림처럼 웹서버(nginx), 로그수집기, 볼륨컨테이너가 하나의 pod에 들어갈 수 있음

https://arisu1000.tistory.com/27829?category=787056

 

- pod내의 컨테이너는 하나의 ip/Port를 공유한다

외부에서 이 pod에 접근할때 하나의ip를 가지고 접근

pod내부의 컨테이너끼리는 localhost를 통해서 통신가능 (컨테이너마다 포트를 구분해서 사용)

컨테이너 A가 8080, 컨테이너 B 가 80로 배포가 된다면

A->B로 호출할때, localhost:80

B->A로 호출할때, localhost:8080
즉, 2개의 컨테이너가 하나의 pod로 배포되면 localhost를 통해서 컨테이너끼리 통신이 가능하다

 

- pod가 재시작되면 ip가 변경된다

pod내의 컨테이너들의 로컬디스크 내용이 사라진다

 

- pod내의 컨테이너는 디스크 볼륨을 공유한다
그래서 컨테이너A는 컨테이너B가 가지고 있는 파일을 읽어올 수 있다.

https://galid1.tistory.com/413?category=767345

 

 

 

 

 

3)  pod object spec (오브젝트 스펙)
간단한 pod의 설정파일을 저장한 object spec(yaml파일)

apiVersion: v1 
kind: Pod
metadata:
 name: nginx
spec:
 containers:
 - name: nginx
   image: nginx:1.7.9
   ports:
   - containerPort: 8090

apiVersion : yml파일을 실행하기 위한 쿠버네티스 API버전 

kind: 리소스 종류

metadata : 리소스의 메타데이터(리소스의 이름)

spec : 리소스에 대한 상세스펙 

pod는 컨테이너를 가지고 있기 때문에 container를 정의하고, 
그 컨테이너의 이름( name: nginx ) 정의하고
컨테이너를 띄울 도커이미지( image: nginx:1.7.9 )를 사용하고

컨테이너 포트인 8090을 오픈한다

 

컨테이너들을 여러개 한꺼번에 띄울때 컨테이너가 각각의 역할을 할 수 있도록 설정함
하나의 pod에 속하는 컨테이너들은 모두 1개의 노드(워커노드)안에서 같이 실행된다.

출처 https://sysnet4admin.blogspot.com/2019/09/k8s-scale-replicas.html#.XpxsT8j7RPY

 

4) pod 생명주기

생성되고 삭제되는 동안 생명주기(lifecycle)가지고 있음

명령어 : kubectl decribe pods pod이름

• pending : pod 생성중 -> 이미지를 가지고 실행되는 중 
• running : pod내의 모든 컨테이거나 실행되고 있는 경우 
• succeeded : pod 내에 모든 컨테이너가 정상적으로 종료
• failed : pod내에 컨테이너 중 종료에 실패한 컨테이너가 존재할 경우
• Unknown : pod 상태확인불가 -> 노드와 통신불가일 경우

 

5) Pod의 컨테이너 상태모니터링(Probe)

-  livenessProbe

컨테이너가 실행된 상태인지 확인

상태확인 실패 -> 컨테이너 kill  -> 재시작 정책에 따라서 컨테이너 restart 

어떻게 할지 명시되어 있지 않으면 기본 상태는 success로 인식

- readinessProbe

컨테이너가 실행된 후 실제로 서비스 요청에 응답할 수 있는 상태인지 확인

상태확인 실패 -> endpoint컨트롤러가 해당 포트에 연결된 모든 서비스에서 endpoint 정보 제거

첫번째 readinessProbe가 있기 전까지 디폴트 상태는 failure로 인식

어떻게 할지 명시되어 있지 않으면 기본 상태는 success로 인식

 

readinessProbe를 별도로 둠으로써

컨테이너가 실행된 다음에 바로 서비스에 투입되서 트래픽을 받는게 아니라

실제 트래픽을 받을 준비가 되어 있는지를 확인한 후에 트래픽을 받을 수 있음

 

 

 출처

https://bcho.tistory.com/1256?category=731548

쿠버네티스 #2 - 개념 이해 (1/2)

 

https://twofootdog.tistory.com/5?category=845779

쿠버네티스 시작하기(2) - 쿠버네티스 구성요소(1/2)

https://arisu1000.tistory.com/27829?category=787056

쿠버네티스(kubernetes) 포드(POD)