워크로드 API 카테고리(파드)

참고 사이트: https://arisu1000.tistory.com/27863

워크로드 API 카테고리

컨테이너 실행에 관련된 리소스

- 파드

- 레플리케이션 컨트롤러

- 레플리카셋

- 디플로이먼트

- 데몬셋

- 스테이트풀셋

- 잡

- 크론잡

파드

• 실행 최소 단위
• 한 개 이상의 컨테이너로 구성
• 같은 파드 내 컨테이너들은 IP를 공유

파드 디자인 패턴

파드 디자인 패턴에는 크게 세 종류가 있다.

종류	개요
사이드카 패턴(sidecar pattern)	메인 컨테이너에 기능을 추가한다.
앰배서더 패턴(ambassador pattern)	외부 시스템과의 통신을 중계한다.
어댑터 패턴(adapter pattern)	외부 접속을 위한 인터페이스를 제공한다.

 

사이드카 패턴(sidecar pattern)

• 사이드카 패턴은 메인 컨테이너의 기능 확장하거나 보조하는 용도의 컨테이너를 추가하는 패턴이다. 
• 예)
  노드의 로그 파일을 수집하여 오브젝트 스토리지에 전송하는 컨테이너
  (쿠버네티스는 자체 로그 수집 솔루션이 없어서 로그 수집 서버 역할하는 컨테이너를 생성한 것)

 

앰배서더 패턴(ambassador pattern)

메인 컨테이너가 외부 시스템(파드 외)과 접속할 때 중계해주는 서브 컨테이너 패턴이다.

메인 컨테이너는 localhost로만 접근하여 앰배서더 컨테이너에 접속하고,실제 통신은 앰배서더 컨테이너가 수행한다.

 

Service Mesh (=proxy)

• 파드 간 통신 경로에 Proxy용 파드를 생성하고, Proxy용 파드가 통신을 중계한다. (트래픽 제어 및 모니터링)
• Proxy 없이 동작하는 마이크로 서비스는 서비스 간 커뮤니케이션을 통제하는 로직을 코딩해야하므로 개발자들이 비즈니스 로직에 집중하지 못하게 된다. 
• 애플리케이션에 구축된 인프라 레이어

 

어댑터 패턴(adapter pattern)

데이터 형식을 변환해주는 컨테이너(어댑터 컨테이너) 패턴이다.

예를 들어, 프로메테우스 등의 모니터링 솔루션은 특정 형식으로만 메트릭을 수집해야 한다.

그러나 대부분의 미들웨어가 제공하는 메트릭 출력 형식은 프로메테우스 메트릭 형식을 지원하지 않는다.

이러한 경우, 어댑터 컨테이너를 사용하여 요청에 맞게 데이터 형식으로 변환하고 반환한다.

 

하나의 컨테이너 포함한 파드 실행 

manifest

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:1.16

nginx:1.16 이미지를 사용한 컨테이너 하나를 기동하고 80/TCP 포트를 바인드하는 단순한 파드이다.

 

manifest를 사용하여 파드를 생성한다.

# 파드 생성
$ kubectl apply -f sample-pod.yaml
pod/sample-pod created

 

기동한 파드가 정상적으로 동작하는지 확인한다.

# 파드 목록 표시
$ kubectl get pods
NAME		READY	STATUS	RESTARTS	AGE
sample-pod	1/1	Running    0      	5h53m

 

좀 더 상세한 리소스 정보를 보기 위해 --output wide 옵션을 사용하여 출력한다.

# 파드 상세 정보 표시
$ kubectl get pods --output wide
NAME		READY	STATUS  RESTARTS   AGE	   IP	      NODE
sample-pod	1/1	Running	  0	   5h54m   10.0.2.7   gke-k8s-default-pool-be722

 

 

두 개의 컨테이너를 포함한 파드 생성

apiVersion: v1
kind: Pod
metadata:
  name: sample-2-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:1.16
  - name: redis-container
    image: redis:3.2

 

# 파드 생성
$ kubectl apply -f sample-2-pod.yaml
pod/sample-2-pod created

 

# 파드 상세 정보 표시
$ kubectl get pods --output wide
NAME		READY	STATUS  RESTARTS   AGE	   IP	      NODE
sample-2-pod	2/2	Running	  0	   5h54m   10.0.2.7   gke-k8s-default-pool-be722

 

만약 컨테이너 2개 모두 80/TCP 포트를 사용한다면 두 컨테이너 중 하나만 기동한다.

 

컨테이너 로그인

ssh와 같은 로그인한 것이 아니다.

실제로는 가상 터미널을 생성(-t)하고, 표준 입력을 패스 스루(-i) 하면서 /bin/sh를 실행한 것으로

마치 ssh로 로그인한 것같은 상태가 된다.

 

$ kubectl exec -it [컨테이너명] -- [command]

[컨테이너명] 내에서 [command] 실행 결과값을 출력하라.

 

# 컨테이너에서 /bin/bash 실행
$ kubectl exec -it sample-pod -- /bin/bash
root@sample-pod:/#

이후부터 컨테이너 내부에서 명령어 실행 가능하다.

 

프로세스 동작 확인

# 확인 작업에 필요한 패키지 설치
root@sample-pod:/$ apt update && apt -y install iproute2 procps

# 컨테이너 내부에서 IP 주소 확인
root@sample-pod:/$ ip a | grep "inet "
	inet 127.0.0.1/8 scope host lo
    inet 10.0.2.7/32 scope global eth0

# 컨테이너 내부에서 바인드(listen)하는 포트 확인
root@sample-pod:/$ ss -napt | grep LISTEN
LISTEN  0  511  0.0.0.0:80  0.0.0.0:*
users:(("nginx",pid=1,fd=6))

# 컨테이너 내부에서 프로세스 확인
root@sample-pod:/$ ps aux
USER	PID %CPU %MEM	VSZ	  RSS	  TTY	STAT	START	TIME	COMMAND
root	1    0.0  0.0   10624	  5512    ?	Ss	Mar24	0:00	nginx:master process nginx -g daemon off;

 

프로세스가 정상적으로 동작하는지 확인한다.

 

command 명령과 args 명령

Docker에서는 ENTRYPOINT 명령과 CMD 명령이 

Kubernetes에서 command 명령과 args 명령으로 역할을 대신한다. 

 

apiVersion: v1
kind: Pod
metadata:
  name: sample-command
spec:
  containers:
  - name: nginx-container-112
    image: nginx:1.16
    command: ["/bin/sleep"]
    args: ["3600"]

 

hostNetwork

파드에 할당된 IP주소는 파드가 실행중인 노드의 호스트 IP 주소와 범위가 다르다.만약 hostNetwork를 사용하면 IP 주소 및 호스트, DNS 등 모든 네트워크 설정이쿠버네티스의 노드에게 상속받는다.

apiVersion: v1
kind: Pod
metadata:
  name: sample-command
spec:
  hostNetwork: true
  containers:
  - name: nginx-container-112
    image: nginx:1.16