[K8s] Pods

 

쿠버네티스에서의 궁극적인 목표는 워커 노드로 구성된 컨테이너 형태로 애플리케이션을 배포하는 것이다. 그러나, 쿠버네티스는 컨테이너를 워커 노드에서 직접 배포하지 않는다. 컨테이너들은 Pod라는 쿠버네티스 오브젝트로 캡슐화 되어 있다.

---

Pod

 파드는 애플리케이션의 단일 인스턴스이며, 쿠버네티스에서 만들 수 있는 가장 작은 단위이다. 기본적으로 파드의 컨테이너는 동일한 스토리지, 동일한 네트워크 네임스페이스에 액세스 권한을 갖는다. 또한 파드의 컨테이너들은 함께 생성되고 함께 파괴된다.

 쿠버네티스 클러스터에 하나의 노드가 있고, 노드 안에서 애플리케이션 인스턴스 하나가 도커 컨테이너로 캡슐화된 파드에서 실행되고 있다. 만약 애플리케이션에 접속하는 유저 수가 증가해서 애플리케이션을 확장해야 한다면, 트래픽을 분산하기 위해 애플리케이션의 인스턴스를 추가해야 한다. 

 이 때, 추가 인스턴스는 새 인스턴스와 함께 새로운 파드를 만들어야 한다. 새로운 인스턴스와 파드를 만들게 되면 같은 노드 안에 두 개의 별도 파드에서 실행되는 애플리케이션의 두 인스턴스가 있게 된다. 만일 유저 수가 증가해서 노드에 충분한 공간이 없어지면 새 노드를 만들어서 추가 파드를 배포할 수 있다.

즉, 파드는 일반적으로 컨테이너와 1 : 1 관계를 가진다. 하지만, 쿠버네티스가 한 파드에서는 하나의 컨테이너만 가질 수 있게 제한해둔 것은 아니다. 한 파드는 같은 종류의 컨테이너가 아니라면, 여러 컨테이너를 가질 수 있다.

• 시나리오 1 / 애플리케이션 확장 O : 같은 종류의 인스턴스(컨테이너)를 추가해야 하는 것이므로 추가 파드를 생성해야함
• 시나리오 2 / 애플리케이션 확장 X : 다른 종류의 인스턴스(컨테이너)를 추가해야 할 경우(이 경우 *헬퍼 컨테이너라고 가정), 추가 파드 생성을 안하고 여러 컨테이너를 가지게 할 수 있음 (= 종류가 다른 여러 컨테이너를 가질 수 있음)
  
  
  • 종류가 다른 두 컨테이너는 같은 파드 안에 있으면서 동일한 네트워크 스페이스를 공유한다.
  • 두 컨테이너는 서로를 localhost로 참조하여 직접 소통할 수 있고, 동일한 저장 공간을 쉽게 공유할 수도 있다.
  • 새 어플리케이션 컨테이너가 생성되면 헬퍼 컨테이너도 같이 생성이 되고, 기존 애플리케이션 컨테이너가 죽으면 헬퍼 컨테이너도 죽게된다. (헬퍼 컨테이너와 애플리케이션 컨테이너는 1 : 1 관계)

---

helper 컨테이너 : 유저 처리, 업로드된 파일 데이터 프로세싱 등 지원 작업을 수행하는 컨테이너

• 헬퍼 컨테이너를 사용하기 위해서는 컨테이너들 사이의 네트워크 연결을 설정해야 한다. 
• 데이터 접근을 위해 공유 가능한 볼륨을 생성하고 컨테이너들에게 공유해야 하며, 이러한 것들은 맵으로 관리해야한다.
• 가장 중요한 것은 애플리케이션 상태 모니터링이다. 새로 생기거나 파괴되는 애플리케이션 컨테이너가 생기면 헬퍼 컨테이너도 그 수에 맞게 컨테이너를 배포하거나 죽여야 한다.
• 하지만 파드를 이용해 파드가 어떤 컨테이너로 구성되는지 정의하면 쿠버네티스가 이 모든 작업을 자동으로 수행한다. 

# 네트워크 설정

$ docker run helper -link app1

---

Deploy Pods

# docker hub로부터 nginx 이미지 pull
$ kubectl run nginx --image nginx
pod/nginx created

# 사용 가능한 pod 조회
$ kubectl get pods
NAME    READY   STATUS              RESTARTS   AGE
nginx   0/1     ContainerCreating   0          4s

# In a little while
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          4m2s

# READY의 1/1은 
# Pod 내에서 실행중인 컨테이너 수 / Pod 내의 총 컨테이너 수
# 를 뜻한다.

 

nginx 이미지를 pull하고 run한 뒤, nginx 컨테이너는 Creating 상태인데 잠시 뒤 Running 상태로 변경되며 실제로 실행이 된다. 현재 상태에서는 외부 사용자가 웹 서버에 접근할 수 있도록 만들지 않았으며, 노드 내부에서만 접근할 수 있다.

---

Kubernetes Yaml

Kubernetes definition file은 루트(최상위) 레벨에 4가지가 있는데, 이 4가지 속성들은 필수로 입력해야 한다. 

• apiversion : 오브젝트를 생성하는 데 사용하는 API 버전
  
  
  • 사용 가능한 값
    Pod : v1
    Service : v1
    ReplicaSet : apps/v1
    Deployment : apps/v1
    
    
• kind : 만들려고 하는 오브젝트의 타입
  
  
  • 사용 가능한 값 : Pod, Service, ReplicaSet, Deployment
    
    
• metadata : 오브젝트에 대한 데이터들
  
  
  • 사용 가능한 값
    name : pod 이름을 지정할 string 값이 들어간다.
    labels : metadata dictionary 값이 들어가며,  오브젝트 식별을 위해 주는 값이다. 원하는 대로 key와 value 쌍을 넣을 수 있다.
    
    
• spec : 만들 오브젝트에 따라 쿠버네티스에 제공할 오브젝트 관련 추가 정보
  
  
  • 사용 가능한 값 : containers, (containers 하위 값) name, image 등

# nginx-container.yml

apiVersion: v1
kind : Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
    type: front-end
spec:
  containers:
        # name 앞의 대시(-)는 이것이 리스트의 첫번째 아이템이라는 것을 뜻한다.
  	- name: nginx-container
	  image: nginx

 

# 위와 같이 yaml을 모두 작성한 뒤, 다음 커맨드를 실행하면 입력한 요구사항대로 파드가 생성된다.
$ kubectl create -f nginx-container.yml

 

---

이외의 명령어

# Pod 조회
$ kubectl get pods

# Pod의 더 자세한 정보
$ kubectl describe pod <pod_name>

# Pod의 이미지 바꾸기
$ kubectl set image pod/<pod_name> <container_name>=<new_image>

# Pod가 속한 Node 조회
$ kubectl get pods -o wide

# Pod를 실행하며 Pod의 yaml 정의 조회
$ kubectl run <container_name> --image=<image_name> --dry-run=client -o 

# yaml 정의를 파일로 생성하기 예시
$ kubectl run pod_container --image=pod_image --dry-run=client -o > pod.yaml

# 생성한 yaml 파일을 pod로 만들기
$ kubectl create -f pod.yaml