Pods: K8S에서 구동되는 컨테이너들

오늘 presentation의 진행 순서

1. Overview
  1-1. Pod내 Container간 리소스를 공유하는 구조
  1-2. Pod 내 Container 간의 Networking
  1-3. Pod 간의 Networking
2. Pod organization - 라벨을 이용하는 것을 중심으로..
3. YAML, JSON을 이용해 Pod를 생성해보기
4. Label Selectors - 응용편

1. Overview

Kubernetes 의 3장에서는 Pod를 다룬다.

Pod란

• 컨테이너들의 그룹으로
• “쿠버네티스 상에서 서비스를 배포할 때 배포의 가장 기본이 되는 단위” 가 된다.
• 여러 container가 Pod하나에 배포 되었을 때, worker node하나에서만 run할 수 있으며, container들은 여러 worker node에 거쳐 배포될 수 없다.

기존에 쓰이던 VM의 개념에서 Pod / Container를 비교했을 때
| | Pod | Container |
|——-|——|——|
|Similar to..| Pysical host, VMs | 같은 물리vm에 올라가있는 Process|

정도로 비교할 수 있다.

여러개의 컨테이너 vs 하나의 컨테이너에서 여러개 프로세스

그럼 여러개의 컨테이너를 배포하느니 하나의 컨테이너에서 여러개의 프로세스를 구동하면 되지 않나? 라는 의문이 생긴다.

그러나

• Container는 container 당 한번에 single process를 run 하도록 디자인되어있다. 왜냐하면, 상관 없는 여러개의 프로세스들을 한 컨테이너에서 동작시켰을 때, 컨테이너가 담당하는 log처리나 process running에 대한 책임 (process간의 충돌 및 재시작) 이 있기 때문.

• 여기서 서로 관련 있는 Process들이 있다면 거의 같은 환경에서 run할 수 있도록 지원하는 container보다 한 단계 높은 레벨의 구조체인 pod가 필요하게 된다.

1-1. Pod내 Container간 리소스를 공유하는 구조

• Pod 내 container 들은 Pod의 resource를 부분적으로 공유한다. 여기서 resource란 Network(Host name, Network interfaces.. / Linux namespaces 등 OS자원 등을 의미한다.
• Pod의 container는 같은 IPC namespace 아래서 구동되고, container들끼리 IPC를 통해 통신한다.

• IPC namespace: Inter-process communication의 약자로, IPC란 프로세스끼리 데이터를 주고 받는 경로를 뜻한다. Linux 에서 사용되는 대표적인 IPC에는 socket / signal / pipe등이 있다. IPC namespace는 이런 IPC 리소스를 격리시켜서 제공하는 개념임.

같은 IPC namespace 아래에서 구동 == 프로세스끼리 데이터를 주고 받는 경로를 공유함

• 이 모든 것을 담당하는 주체는 Kubernetes다. Pod의 모든 container가 same Linux namespace set를 공유하도록 Docker를 구성한다.

1-2 & 1-3. Pod내 container간 networking / Pod 끼리의 Networking

• Pod끼리의 통신 보충사항

• NAT Gateway (Network Address Translation) 이 Pod들 사이에 존재하지 않는다.

• Network Address Translation? IP packet에 있는 출발지 / 목적지의 IP 주소와 TCP/UDP port # 를 바꿔 재기록하면서 네트워크 트래픽을 주고받게 하는 기술. (공인 ip address를 절약할 수 있고, 직접 목적지의 ip를 노출하지 않으므로)

2. Pod organization

본격 Pod 정리하기~

Pod는 lightweight, overhead가 거의 없이 생성된다.

오늘의 미션 : 성공적으로 Multiple pods에 내 App을 splitting하기

전략 1. Multi-tier app 들은 multiple pods로

Frontend와 Backend가 같은 pod에 있다면, 언제나 같은 machine에서 구동될 것이고, 결국 하나의 worker node만 이용하게 되기 때문에 클러스터 내에 다른 node의 compute resource를 스케일러블하게 사용할 수 있다는 장점을 전혀 취할 수 없다.

전략2. 독립적인 scaling이 가능한 단위로 여러 pod에 배치하기

Pod는 scaling의 기본 단위가 된다.

• Container를 scaling하는 것 (X)
• Pod를 scaling하는 것 (O).

ex) Backend 와 Frontend App 서비스를 각각 2개의 컨테이너로 구성해서 배포하기로 결정했다고 하면, 장애가 날 시 Backend container 2개, Front 2개의 방식으로 scaling됨.

그럼 Multiple containers는 언제 이용하는가?

Application이 main process를 가지고 있고, 다른 보조 프로세스 (근데 이제 main process를 서포트 하는..) 를 갖고 있을 때 사용한다.

예를 들어서 main container가 web server이고, 추가적인 컨테이너가 주기적으로 외부 소스에서 컨텐츠를 다운받아서 webserver의 directory에 넣어주는 것과 같은 경우!

2. Label을 이용한 Pod organizing

마이크로서비스 구조에서 각 서비스의 개수는 보통 20개를 훌쩍 넘기기 때문에, 한번에 함께 돌아가는 multiple copy본 / multiple versions에 대한 관리가 필요하다.

Labels

• 간단하고, 파워풀한 K8S feature로 pod외 다른 K8S resource에도 적용할 수 있다.
• Key-Value pair의 형식으로 resource에 attach한다.

3. YAML, JSON을 이용한 Pod 생성

Kubernetes resource를 생성하고 싶을 때에는, Kubernetes API server에 YAML이나 JSON의 형식으로 된 manifest를 POST 요청해서 생성한다.

YAML / JSON 파일을 관리해서 형상관리가 가능하고, version control도 쉽게 가능

Kubernetes resource의 YAML을 빠르게 훑어보자

YAML의 형식은 3개의 섹션으로 되어 있음.

• Metadata : Pod name, namespace, labels, other information..
• Spec : Pod의 Containers, volumes, other data 와 같은 실제 스펙(설명)을 기록
• Status : description, 각 컨테이너의 상태, running pod의 current information

Pod를 생성하는 yaml파일 예시는 다음과 같다.

apiVersion: v1     # Descriptor conforms to version v1 of Kubernetes APi
kind: Pod
metadata:
  name: kubia-manual
spec:
  containers:
  - image: luksa/kubia
#name of pod
name: kubia
ports:
- containerPort: 8080
  protocol: TCP
# The port the app is listening on

이제 이 파일을 저장하고,
`kubectl create -f “file_name.yaml”을 실행하면 pod가 생성된다.

mzc01-jiyoon@MZC01-JIYOON kuber study % kubectl create -f kubia-manual.
yaml
pod/kubia-manual created

mzc01-jiyoon@MZC01-JIYOON kuber study % kubectl get po
NAME           READY   STATUS              RESTARTS   AGE
kubia-manual   0/1     ContainerCreating   0          4s
mzc01-jiyoon@MZC01-JIYOON kuber study % kubectl get po kubia-manual -o
yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2021-06-15T16:06:49Z"
  name: kubia-manual
  namespace: default
  resourceVersion: "18141"
  uid: 3466bba7-7568-40f7-8784-74f1fdd53e10
spec:
  containers:
  - image: luksa/kubia
… 이하생략

Container의 로그 보기

Pod안에 Container가 여러 개 있다면 -c 옵션으로 container 이름을 명시해야한다.

mzc01-jiyoon@MZC01-JIYOON kuber study % kubectl logs kubia-manual
Kubia server starting...

mzc01-jiyoon@MZC01-JIYOON kuber study % kubectl logs kubia-manual -c kubia
Kubia server starting...

Pod에 Labels를 붙여서 생성하기

apiVersion: v1
kind: Pod
metadata:
  name: kubia-manual-v2
  labels:   ##### 여기!!!! -> key- value pair로 labels에 명시
    creation_method : manual
    env: prod
spec:
  containers:
  - image: luksa/kubia
    name: kubia
    ports:
    - containerPort: 8080
      protocol: TCP

Show labels

mzc01-jiyoon@MZC01-JIYOON chapter3 % kubectl get po --show-labels
NAME              READY   STATUS    RESTARTS   AGE     LABELS
kubia-manual      1/1     Running   0          8h      <none>
kubia-manual-v2   1/1     Running   0          4m46s
creation_method=manual,env=prod

4. Label Selectors