[Kubernetes] 쿠버네티스 입문: Part II. 쿠버네티스 기본 개념(아키텍처, 파드, ...)

💡 본 문서는 '쿠버네티스 입문: Part II. 쿠버네티스 기본 개념'에 대해 정리해놓은 글입니다.
'쿠버네티스 입문'이라는 Kubernetest의 개념 및 실습을 다룬 책을 읽으며 관련 핵심 내용을 정리하였습니다. 본 문서의 경우 '쿠버네티스 입문: Part II. 쿠버네티스 기본 개념'의 내용인 쿠버네티스를 처음 접하는 사람이 꼭 알아야 할 내용에 대해 다루었으니 참고하시기 바랍니다. 추가로, 해당 책의 샘플 예제는 [github] kubernetes-book-sample에서 다운 받아 kubectl apply -f <filename>.yaml 명령을 통해 실습할 수 있으니 참고하시기 바랍니다.

1. 쿠버네티스 아키텍처

1.1 쿠버네티스 클러스터의 전체 구조

쿠버네티스 클러스터는 크게 두 종류의 서버로 구성합니다. 클러스터를 관리하는 마스터(Control Plane, cp)와 실제 컨테이너를 실행시키는 노드(Worker Node)입니다.

마스터에는 etcd, kube-apiserver, kube-schduler, kube-controller-manager, kubelet, kube-proxy, docker 등의 컴포넌트가 실행됩니다. 컴포넌트 각각이 다른 마스터나 노드 서버에서 별개로 실행되어도 실제 쿠버네티스 클러스터를 운영하는 데 이상은 없으나, 마스터가 서버 1대라면 프로세스 한 묶음으로 해당 서버에서 같이 실행하는 것이 일반적인 구성입니다(보통 고가용성을 위해 3대를 구성해서 운영합니다.). 노드(초기에 미니언이라고도 함)에는 kubelet, kube-proxy, docker 등의 컴포넌트가 실행됩니다.

각 컴포넌트의 중심에는 kube-apiserver가 있으며, 모든 통신의 중심으로 kube-apiserver를 거쳐 다른 컴포넌트가 서로 필요한 정보를 주고 받습니다. 특히 별도의 프로세스인 etcd에는 kube-apiserver만 접근할 수 있습니다.
- 마스터 내부 etcd는 컨테이너로 관리할수도 있지만, 서버 프로세스로 실행하도록 구성할 수 있습니다.
kubelet이 마스터에 있는 도커를 관리하며, 도커 내부에는 쿠버네티스 관리용 컴포넌트 kube-scheduler, kube-controller-manager, kube-apiserver, kube-proxy가 있습니다. 관리용 컴포넌트는 모두 hyperkube라는 바이너리 파일로 컴파일 되었고 실행할 때 옵션을 설정해 각 컴포넌트의 역할을 수행합니다.
노드 역시 kubelet으로 도커를 관리합니다. kubelet은 마스터의 kube-apiserver와 통신하면서 파드의 생성, 관리, 삭제를 담당합니다.
- 노드 내부 kube-proxy는 컨테이너로 관리할수도 있지만, 서버 프로세스로 실행하도록 구성할 수 있습니다.

1.2 쿠버네티스의 주요 컴포넌트

쿠버네티스의 컴포넌트는 세 가지로 구분합니다. 클러스터를 관리하는 데 필수인 마스터용 컴포넌트, 노드용 컴포넌트, 필수는 아니지만 추가로 사용할 수 있는 애드온용 컴포넌트입니다.

1.2.1 마스터용 컴포넌트

etcd

코어 OS에서 raft 알고리즘으로 개발한 고가용성을 제공하는 'key-value 저장소'
- raft 알고리즘: 노드 사이의 상태 공유하는 합의 알고리즘
서버 하나당 프로세스 1개만 사용할 수 있으며, 보통 etcd 자체를 클러스터링 한 후 여러 개 마스터 서버에 분산해서 실행해 데이터의 안정성을 보장함
- 클러스터링: 여러 대 컴퓨터를 연결해 시스템 하나처럼 구성
etcd 자체도 꽤 안정적이지만, 더 안정적으로 쿠버네티스를 운영하려면 주기적으로 etcd에 있는 데이터를 백업할 것을 권장

kube-apiserver

쿠버네티스 클러스터의 API를 사용할 수 있도록 해주는 컴포넌트
Kube-api를 통해 특정 자원의 조회 명령을 받으면, 요청이 유효하고 실행할 권한이 있는지 검사한 후 해당 작업을 수행하여 전달하는 역할
쿠버네티스는 Micro Service Architecture(MSA)이므로, 컴포넌트들이 서로 분리되어 있으며 모든 요청은 kube-apiserver를 통해 전달됨

kube-scheduler

새롭게 실행할 '파드'의 조건에 알맞는 노드를 탐색하고, 파드를 할당하는 역할을 수행
pod의 조건: 하드웨어 요구사항, affinity와 anti-affinity 만족 여부, 특정 데이터가 있는 노드에 할당 등
- affinity: 함께 있어야 하는 파드들을 같은 노드에 실행
- anti-affinity: 파드를 다양한 노드로 분산해서 실행

kube-controller-manager

쿠버네티스에서 파드들을 관리하는 '컨트롤러(controller)' 프로세스를 실행하는 컴포넌트
컨트롤러 각각은 논리적으로 개별 프로세스지만 복잡도를 줄이려고 모든 컨트롤러를 바이너리 파일 하나로 컴파일해 단일 프로세스로 실행

cloud-controller-manager

쿠버네티스의 '컨트롤러'들을 클라우드 서비스와 연결하여 관리하는 컴포넌트
보통 네 가지 컨트롤러 컴포넌트를 관리함
- 노드 컨트롤러: 클러우드 서비스 안에서 노드를 관리하는 데 사용
- 라우트 컨트롤러: 각 클라우드 서비스 안의 네트워크 라우팅을 관리하는 데 사용
- 서비스 컨트롤러: 각 클라우드 서비스에서 제공하는 로드밸런서를 생성, 갱신, 삭제하는 데 사용
- 볼륨 컨트롤러: 클라우드 서비스에서 생성한 볼륨을 노드에 연결하거나 마운트 하는 등에 사용

1.2.2 노드용 컴포넌트

kubelet

마스터의 kube-apiserver와 통신하며 pod container의 실행을 관리
- 단, 파드 내에서도 쿠버네티스에 의해 만들어지지 않은 컨테이너들은 관리하지 않음
PodSpecs 조건이 담긴 설정을 전달받아서 컨테이너를 실행하고 관리함

kube-proxy

쿠버네티스는 클러스터 내부의 별도 가상 네트워크를 설정하고 관리하는데, 이러한 가상 네트워크의 동작을 관리하기 위한 컴포넌트

컨테이너 런타임(e.g. Docker)

실제로 컨테이너를 실행시키며, 가장 많이 알려진 런타임은 Docker가 있음(continerd, runc 같은 런타임도 지원)

1.2.3 애드온용 컴포넌트

클러스터 안에서 필요한 기능을 실행하는 파드로, 네임스페이스는 kube-system입니다. 애드온으로 사용하는 파드들은 디플로이먼트, 리플리케이션 컨트롤러 등으로 관리합니다.

네트워크 애드온

쿠버네티스는 클러스터 안에 가상 네트워크를 구성해 사용할 때 kube-proxy 이외에 네트워킹 에드온을 사용함
AWS, Azure 등 클라우드 서비스에서 제공하는 쿠버네티스를 사용한다면, 별도로 구성할 필요는 없으나 직접 서버에 구성한다면 설치해서 사용해야 함

DNS 애드온

클러스터 안에서 동작하는 DNS 서버로, 쿠버네티스 서비스에 DNS 레코드를 제공함
쿠버네티스 안에 실행된 컨테이너들은 자동으로 DNS 서버에 등록됨
주로 사용하는 DNS 애드온: kube-dns, CoreDNS

대시보드 애드온(웹 UI)

kubectl 이라는 CLI 외에 웹 UI 쿠버네티스를 사용을 원할 경우 대시보드 애드온을 사용함.
쿠버네티스 클러스터를 위한 범용 웹 기반 UI를 제공

컨테이너 자원(리소스) 모니터링

컨테이너 자원 모니터링 은 클러스터 안에서 실행중인 컨테이너의 상태를 모니터링하는 애드온
CPU, 메모리 사용량 같은 데이터들을 시계열 형식으로 기록하며, kubelet 안에 포함된 cAdvisor라는 컨테이너 모니터링 도구를 사용하여 데이터를 확인할 수 있음

클러스터 로깅

클러스터 안 개별 컨테이너의 로그와 쿠버네티스 구성 요소의 로그들을 수집하는 파드를 실행해서 중앙화한 로그 수집 시스템에 모아서 보는 애드온
로그 수집해서 보여줄 때는 ElasticSearch Logstash Kibana(ELK), ElasticSearch Fluentd Kibans(EFK)를 많이 사용함

1.3 오브젝트와 컨트롤러

쿠버네티스는 크게 사용자가 제시한 desired state를 유지하고 작업을 수행하는 '오브젝트'와 오브젝트를 관리하는 '컨트롤러'로 나눕니다.

오브젝트: pod, service, volume, namespace 등
컨트롤러: ReplicaSet, Deployment, StatefulSet, DaemonSet, Job 등

오브젝트, 컨트롤러는 다음 쳅터에서 설명할 예정이며, 여기서는 클러스터를 논리적인 단위로 나누는 '네임스페이스'와 오브젝트 및 컨트롤러가 어떤 상태여야 하는지 설정하는 '템플릿'을 살펴보겠습니다.

1.3.1 네임스페이스

네임스페이스는 쿠버네티스 클러스터 하나를 여러 개 논리적인 단위로 나눠서 사용하도록 도와주며, 이로 인해 여러 사용자가 하나의 클러스터를 공유할 수 있습니다. 또한 네임스페이스 별로 별도의 쿼터를 설정해서 특정 네임스페이스의 사용량을 제한할 수 있습니다.

쿠버네티스를 처음 설치하면 기본으로 몇 개의 네임스페이스가 생성되며, 'kubectl get namespaces' 명령으로 확인할 수 있습니다.

% kubectl get namespace
NAME              STATUS   AGE
default           Active   36d
kube-node-lease   Active   36d
kube-public       Active   36d
kube-system       Active   36d

default: 기본 네이스페이스이며, 쿠버네티스에서 명령을 실행할 때 별도의 네임스페이스를 지정하지 않는다면 항상 default 네임스페이스에 명령을 적용합니다.
kube-system: 쿠버네티스 시스템에서 관리하는 네임스페이스이며, 이 네임스페이스에는 쿠버네티스 관리용 파드나 설정이 있습니다.
kube-public: 클러스터 안 모든 사용자가 읽을 수 있는 네임스페이스 입니다. 보통 클러스터 사용량 같은 정보를 이 네임스페이스에서 관리합니다.
kube-node-lease: 각 노드의 lease object 들을 관리하는 네임스페이스 이며, 쿠버네티스 1.13 이후 알파로 추가되었습니다.

kubectl로 네임스페이스를 지정해서 사용할 때는 --namespace=kube-system 처럼 네임스페이스를 지정해야하며, 지정하지 않으면 default로 설정됩니다.

추가로 일일이 지정하지 않고 기본 네임스페이스를 바꾸는 방법은 두가지가 있습니다. kubectl로 제공하는 방법은 다음과 같습니다.

% kubectl config set-context {컨텍스트 이름} --namespace={변경할 네임스페이스}

그리고 kubctx 라는 패키지를 설치하면, kubens 라는 명령어를 통해 쉽게 기본 namespace 변경이 가능하다고 합니다.

% brew install kubectx
% kubeens {namespace name}

1.3.2 템플릿

쿠버네티스 클러스터의 '오브젝트'나 '컨트롤러'가 어떤 상태여야 하는지(desired state)를 적용할 때는 YAML 형식의 템플릿을 이용합니다.

YAML에서 사용하는 data type은 다음과 같습니다.

Scalars (strings/number)	Sequence (arrays/lists)	Mappings (hashes/dictionaries)
Name: choi Birth: 2000	ProgrammingSkills: - C++ - Python	Data: Height: 173 Weight: 73

템플릿의 기본 형식은 다음과 같으며, 공식 문서를 참조하면 YAML에서 사용하는 field에 대해 자세히 알 수 있습니다.

apiVersion: v1
kind: Pod
metadata:
spec:

apiVersion: 사용하려는 쿠버네티스 API 버전을 명시합니다. kubectl api-versions 명령을 통해 현재 클러스터에서 사용가능한 API 버전을 확인할 수 있습니다.
kind: 어떤 종류의 오브젝트 혹은 컨트롤러에 작업인지 명시합니다. pod이라 명시하면 파드에 관한 템플릿입니다.

2. 파드

2.1. 파드 개념

k8s는 파드라는 최소 단위로 컨테이너를 '묶어' 관리하며, 파드는 컨테이너 여러개로 구성됩니다. 컨테이너 여러개를 한꺼번에 관리할 때는 컨테이너마다 역할 부여할 수 있으며, 대게 하나의 컨테이너에는 하나의 역할을 부여합니다(e.g. 로그, 볼륨 등).

한 파드 안에 있는 컨테이너는 같은 IP 하나를 공유하며, 외부에서 이 파드에 접근한다면? 정해진 하나의 IP로 접근하여 컨테이너마다 부여된 포트를 통해 컨테이너와 통신합니다.

2.2. 파드 사용하기

교재의 파드의 탬플릿 설정 예시인 pod/pod-sample.yaml 파일을 살펴봅시다.

apiVersion: v1
kind: Pod
metadata:
    name: kubernetes-simple-pod
    labels:
    	app: kubernetes-simple-pod
spec:
    containers:
    - name: kubernetes-simple-pod
      image: arisu1000/simple-container-app:latest
      ports:
      - containerPort: 8080

.metadata.name : 파드 이름 설정.
.metatdata.labels.app : 오브젝트 식별 레이블 설정.
.spec.containers[].name : 컨테이너 이름 설정. name 앞의 '-' 표시는 배열을 의미함. .spec.containers의 하위 필드를 배열형태로 묶겠다는 것을 의미하며, 이는 대게 .spec.containers[] 라고 표기함.
.spec.containers[].image : 컨테이너에서 사용할 이미지를 지정.
.spec.containers[].ports[].containerPort : 해당 컨테이너에 접속할 포트 번호를 설정함.

해당 샘플의 경우, 저자의 github에서 pod/pod-sample.yaml에 저장되어 있으니 해당 yaml 파일을 실행합시다. 이후 'kubectl get pod' 명령으로 STATUS 항목이 Running 이면 정상적으로 실행된 것입니다.

% kubectl apply -f pod/pod-sample.yaml
pod/kubernetes-simple-pod created

% kubectl get pod                     
NAME                    READY   STATUS    RESTARTS   AGE
kubernetes-simple-pod   1/1     Running   0          8s

2.3 파드 생명 주기

파드는 생성부터 삭제까지의 과정에 생명주기(Lifecycle)이 있습니다.

Pending: k8s system에 파드를 생성하는 중임. 이 상태에 컨테이너 이미지를 다운로드한 후 전체 컨테이너를 실행하므로 시간이 걸림.
Running: 파드 안 모든 컨테이너가 실행 중인 상태.
Succeeded: 파드 안 모든 컨테이너가 정상 실행 종료된 상태로 재시작되지 않음.
Failed: 파드 안 모든 컨테이너 중 정상적으로 실행 종료되지 않은 컨테이너가 있는 상태. 컨테이너 종료 코드가 0이 아니면 비정상 종료이거나 시스템이 직접 컨테이너를 종료한 것.
Unknown: 파드의 상태를 확인할 수 없는 상태이다 보통 파드가 있는 노드와 통신할 수 없을 때.

'kubectl get pod', 'kubectl describe pod kubernetes-simple-pod' 명령을 통해 확인할 수 있습니다.

% kubectl get pod                     
NAME                    READY   STATUS    RESTARTS   AGE
kubernetes-simple-pod   1/1     Running   0          8s

% kubectl describe pod kubernetes-simple-pod 
Name:             kubernetes-simple-pod
Namespace:        default
Priority:         0
Service Account:  default
Node:             docker-desktop/192.168.65.4
Start Time:       Sun, 26 Mar 2023 13:55:52 +0900
Labels:           app=kubernetes-simple-pod
Annotations:      <none>
Status:           Running
IP:               10.1.0.14
IPs:
  IP:  10.1.0.14
Containers:
  kubernetes-simple-pod:
  
...

Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
  
...

Condition 항목은 파드의 현재 상태를 나타내며, Type과 Status로 구분되어 있습니다.

Status는 해당 Type이 활성화(True), 비활성화(False), 알 수 없음(Unknown) 인지에 따라 상태를 표시하며, Type에는 다음 같은 정보가 있다.

Initialized: 모든 초기화 컨테이너가 성공적으로 시작 완료되었다는 뜻.
Ready: 파드는 요청들을 실행할 수 있고 연결된 모든 서비스의 로드밸런싱 풀에 추가되어야 한다는 뜻.
ContainersReady: 파드 안 모든 컨테이너가 준비 상태라는 뜻.
PodScheduled: 파드가 하나의 노드로 스케줄을 완료했다는 뜻.
Unschedulable: 스케줄러가 자원의 부족하거나 다른 제약 등으로 지금 당장 파드를 스케줄할 수 없다는 뜻.

2.4. kubelet으로 컨테이너 진단

컨테이너 실행 후에는 kubelet이 컨테이너를 주기적으로 진단합니다. 이때 필요한 프로브(probe)에는 다음 세가지가 있습니다.

livenessProbe: 컨테이너가 실행되었는지 확인하며, 이 진단이 실패했을 경우 정책에 따라 컨테이너를 재시작함.
readinessProbe: 컨테이너가 실행된 후 실제 서비스 요청에 응답할 수 있는지 진단
- 특히 실행하여 실제로 서비스 요청을 받을 수 있을때 까지의 시간이 필요한 어플리케이션의 서비스에 유리
- e.g. 자바 app 처럼 프로세스 시작 후 앱이 초기화될 때까지 시간이 걸리는 상황, 대용량 데이터가 필요한 앱 등에 유용

컨테이너 진단은 컨테이너가 구현한 핸들러(handler)를 kubelet이 호출하며, handler에는 세가지가 있습니다.

ExecAction: 컨테이너 안에 지정된 명령을 실행하고 종료 코드가 0일때 Success라고 진단.
TCPSocketAction: 컨테이너 안에 지정된 IP와 포트로 TCP 상태를 확인하고 포트가 열려 있으면 Success라고 진단.
HTTPGetAction: 컨테이너 안에 지정된 IP, 포트, 경로로 HTTP GET 요청을 보낸다. 응답 상태 코드가 200~400이면 Success라고 진단한다.

진단 결과 역시 세가지가 있습니다.

Success : 컨테이너 진단 성공
Failure : 컨테이너 진단 실패
Unknown : 진단 자체가 실패해 컨테이너 상태를 알 수 없음

2.5 초기화 컨테이너(init container)

초기화 컨테이너(init container)는 app container가 실행되기 전 파드를 초기화하며, 보안상 이유로 같이 두면 안되는 앱의 소스코드를 별도 관리할 때 유용합니다. 이는 다음과 같은 특징이 있습니다.

초기화 컨테이너는 여러개 구성 가능하며, pod tamplate에 명시한 순서대로 실행된다.
초기화 컨테이너는 실행 실패하면 성공할 때까지 재시작합니다. 이를 이용하면 k8s의 '선언적' 특징에서 벗어, 필요한 명령들을 순서대로 실행하는 데 사용할 수 있습니다.
초기화 컨테이너가 모두 실행된 후에야 app container가 실행됩니다.

이런 특징을 이용해 pod 실행 시 app container가 외부 특정 조건을 만족할 때까지 기다렸다 실행하도록 만들 수 있습니다. 물론, 초기화 컨테이너의 단점도 있습니다. pod가 모두 준비되기 전 실행한 후 종료되어야 하는 컨테이너이기 때문에 readinessProbe를 지원하지 않습니다.

초기화 컨테이너를 설정한 파드 설정의 예시는 pod/pod-init.yaml를 살펴봅시다.

spec:
  initContainers:
  - name: init-myservice
    image: arisu1000/simple-container-app:latest
    command: ['sh', '-c', 'sleep 2; echo helloworld01;']
  - name: init-mydb
    image: arisu1000/simple-container-app:latest
    command: ['sh', '-c', 'sleep 2; echo helloworld02;']
  containers:
  - name: kubernetes-simple-pod 
    image: arisu1000/simple-container-app:latest
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']

초기화 컨테이너는 .spec.initContainers[] 의 하위 필드에 정의되며, 앱 컨테이너는 .spec.containers[] 하위에 정의됩니다.

따라서 해당 yaml 파일을 실행하면? 해당 파드를 실행하기 전에 'init-service', 'init-mydb' 컨테이너를 실행한 후 'kubernetes-simple-pod' 컨테이너를 실행시켜 하나의 pod로 실행합니다.

2.6 파드 인프라 컨테이너

k8s에는 모든 파드에서 항상 실행되는 pause라는 컨테이너가 있습니다. 이 pause를 '파드 인프라 컨테이너(Pod infrastructure container)' 라고 합니다.

pause는 파드 안 기본 네트워크로 실행되며, 프로세스 식별자가 1(PID 1)로 설정되므로 다른 컨테이너의 부모 역할을 합니다. 다른 컨테이너는 pause가 제공하는 네트워크를 공유해 사용합니다. 그래서 파드 안 다른 컨테이너가 재시작됐을 때는 파드의 IP를 유지하지만, pause가 재시작된다면 파드 안의 다른 모든 컨테이너도 재시작됩니다.

kubelet에는 명령 옵션으로 '--pod-infra-container-image'로 pause가 아닌 다른 컨테이너를 파드 인프라 컨테이너로 지정할 수 있습니다.

2.7. 스태틱 파드

스태틱 파드(static pod)는 kube-apiserver를 통하지 않고 kubelet이 직접 실행하는 파드입니다. kubelet 설정의 '--pod-manifest-path'라는 옵션에 지정한 디렉터리에 static pod로 실행하려는 파드를 넣어두면, kubelet이 그걸 감지해 static pod로 실행합니다.

static pod는 kubelet이 직접 관리하며 이상이 생긴다면 재시작합니다. 또 kubelet이 실행중인 노드에서만 실행되고 다른 노드에서는 실행되지 않습니다. kube-apiserver로 pod를 조회 가능하지만 static pod에 어떠한 명령을 실행할 수는 없습니다.

보통 static pod는 kube-apiserver, etcd같은 system pod를 실행하는 용도로 많이 쓰입니다. k8s에서 파드를 실행하려면 kube-apiserver가 필요한데 kube-apiserver 자체를 처음 실행하는 별도의 수단으로 static pod를 이용하는 것입니다.

2.8 파드에 CPU와 메모리 자원 할당

노드 하나에 여러 개 파드를 실행하는 일이 자주 있습니다. 이때 자원 사용량이 큰 파드가 노드 하나에 모여있다면 파드들의 성능이 나빠지며 전체 클러스터 자원 효율도 낮아집니다.

k8s에서는 이를 막는 여러 방법이 있으며, 가장 기본적인 것은 파드 설정시 파드 안 각 컨테이너가 CPU나 메모리의 최소 요구량(request)와 상한선(limits)을 지정하는 것입니다. pod/pod-resource.yaml 파일에서 자원 할당량을 지정하는 방법을 익혀보도록 합시다.

spec:
  containers:
  - name: kubernetes-simple-pod
    image: arisu1000/simple-container-app:latest
    resources:
      requests:
        cpu: 0.1 --- 1
        memory:200M --- 2
      limits:
        cpu: 0.5 --- 3
        memory: 1G --- 4
    ports:
    - containerPort: 8080

.spec.continers[].resource.request 필드를 통해 최소 자원 요구량을 지정
- 이 필드에 설정된 만큼 자원 여유가 있는 노드여야 그곳에 파드가 스케줄링되어 실행됨
- 자원이 요구하는 만큼 있는 노드가 없다면 파드는 Pending 상태로 실행되지 않으며 클러스터 내에 자원 여유가 생길 때까지 대기함.
.spec.continers[].resource.request 필드를 통해 자원 상한선을 지정
- 평소에 사용량이 적더라도 갑자기 늘어날 수 있으며, 이때 limit 설정이 따로 없다면 해당 컨테이너가 노드의 모든 자원을 사용할 것
- 그럼 같은 노드에 실행된 다른 컨테이너가 모두 영향을 받을수 있으며, 최악엔 클러스터 안 모든 서비스에 영향을 끼칠 수도 있기에 limit설정으로 이를 막아줌
추가로, 여기서 지정한 CPU 필드는 0.1, 0.5 등으로 표현하며, 여기서 1은 코어 하나의 연산 능력을 전부 쓰도록 설정했다는 뜻이다. 따라서 0.1이라면 CPU 코어 하나의 10%만큼 연산능력을 할당한다는 의미가 됩니다.

2.9. 파드에 환경 변수 설정하기

파드의 환경 변수 설정 방법은 .spec.containers[].env[] 필드에서 설정하며, 다음과 같은 의미를 지닙니다.

name : 사용할 환경변수의 이름을 설정.
value : 문자열이나 숫자 형식의 값을 설정.
valueFrom: 값을 직접 할당하는 것이 아니라 어딘가 다른 곳에서 참조하는 값 설정.
fieldRef : 파드의 현재 설정 내용을 값으로 설정한다는 선언.
fieldPath : .fieldRef에서 어디서 값을 가져올 것인지 지정. 값을 참조하려는 항목의 위치를 지정.
resourceFieldRef : 컨테이너에 CPU, 메모리 사용량을 얼마나 할당했는지에 관한 정보를 가져옴.
containerName: 환경 변수 설정을 가져올 컨테이너 이름을 설정.
resource : 어떤 자원의 정보를 가져올지 설정.

사용예시는 'pod/pod-env.yaml' 파일을 참고하도록 합시다. 해당 환경 변수가 적용되었는지 확인하는 방법은, 해당 컨테이너에 접속하여 env명령어로 환경변수를 확인하는 것입니다.

% kubectl apply -f pod/pod-env.yaml

% kubectl exec -it kubernetes-simple-pod sh

- # env
POD_IP=10.1.0.5
...(환경변수 내용)

2.10. 파드 구성 패턴

파드로 여러 개의 컨테이너를 묶어서 구성하고 실행할 때 몇가지 패턴을 적용할 수 있습니다. 이는 구글의 '컨테이너 기반의 분산 시스템 디자인 패턴' 을 참고하면 도움이 됩니다.

2.10.1. 사이드카 패턴(Sidecar)

원래 사용하려던 기본 컨테이너의 기능을 확장/강화하는 용도의 컨테이너를 추가하는 것입니다. 기본 컨테이너는 원래 목적의 기능에만 충실하도록 구성하고, 나머지 공통 부가 기능들은 사이드카 컨테이너를 추가해서 사용합니다.

일반적인 웹 서버의 예라면? 웹 서버 컨테이너는 그 역할만 하고, 로그는 파일로 남깁니다. 사이드카 역할인 로그 수집 컨테이너가 파일 시스템에 쌓이는 로그를 수집해 외부의 로그 수집 시스템으로 보냅니다. 이러면 웹 서버 컨테이너를 다른 역할을 하는 컨테이너로 변경했을 때도 로그 수집 컨테이너는 그대로 사용 가능하며, 공통 역할을 하는 컨테이너의 재사용성을 높일 수 있습니다.

2.10.2. 앰버서더 패턴(Ambassador)

파드 안에서 프록시 역할을 하는 컨테이너를 추가하는 패턴입니다. 파드 안에서 외부 서버에 접근할 때 내부 프록시에 접근하도록 설정하고, 실제 외부와 연결은 프록시에서 알아서 처리합니다.

웹 서버 컨테이너는 캐시에 localhost로만 접근하고, 외부 캐시 중 어디로 접근할지는 프록시 컨테이너가 처리합니다. 이 방식은 파드의 트래픽을 더 세밀하게 제어할 수 있다는 장점이 있습니다.

2.10.3. 어댑터 패턴(Adapter)

파드 외부로 노출되는 정보를 표준화하는 어댑터 컨테이너를 사용한다는 뜻입니다. 주로 어댑터 컨테이너로 파드의 모니터링 데이터를 노출시키고, 외부 모니터링 시스템에서 해당 데이터를 주기적으로 가져가 모니터링하는데 이용합니다.

3. 컨트롤러

컨트롤러(controller)는 파드들을 관리하는 역할을 하며 ReplicaSet, Deployment, StatefulSet, DaemonSet, Job 등 다양한 목적에 맞는 컨트롤러가 있습니다.

Replication Controller, ReplicaSet, Deployment: 오랜 시간동안 계속 실행되어야 하는 파드들을 관리할 때
DaemonSet: 클러스터의 전체 노드에 같은 파드를 실행할 때
StatefulSet: 보통 stateless 앱을 실행하는 데 사용하는 컨테이너를 stateful 앱을 실행할 때 사용하도록
Job: 1회성 작업을 할 때하며, 주기적인 배치 작업을 실행할때는 cronjob을 사용

3.1. 레플리케이션 컨트롤러

레플리케이션 컨트롤러(Replication Controller)는 지정한 숫자만큼의 파드가 항상 클러스터 안에서 실행하도록 관리하는 가장 기본적인 컨트롤러입니다. 장애와 같은 이유로 파드가 죽더라도 지정한 숫자만큼 파드를 실행하도록 조정합니다.

레플리케이션 컨트롤러는 k8s 초기부터 있었으나 요즘은 비슷한 역할을 하는 레플리카세트를 사용하는 추세입니다. 또한 앱의 배포에는 디플로이먼트를 주로 사용합니다.

3.2. 레플리카세트

레플리카세트(ReplicaSet)는 레플리케이션 컨트롤러의 발전형으로 '집합 기반의 셀렉터(set-based selector)'를 지원합니다. 레플리케이션 컨트롤러의 경우 셀렉터가 등호기반으로 레이블을 선택할 때 같은지 다른지만 확인했으나, 집합기반의 셀렉터는 in, notin, exists 같은 연산을 지원합니다. 추가로 레플리카세트는 레플리케이션 컨트롤러에서 지원하던 rolling-update 옵션을 지원하지 않아 필요할 경우 디플로이먼트를 사용해야합니다.

3.2.1. 레플리카세트 사용하기

레플리카세트를 이용해 파드를 관리하는 사용하기 위한 템플릿을 살펴보겠습니다. 예제의 replicaset/replicaset-nginx.yaml을 참고하시면 됩니다.

% kubectl apply -f replicaset-nginx.yaml
replicaset.apps/nginx-replicaset created
% kubectl get pods
nginx-replicaset-4v65n       1/1     Running   0               78s
nginx-replicaset-jhd5g       1/1     Running   0               78s
nginx-replicaset-r6hrk       1/1     Running   0               78s

예제를 살펴보면 템플릿 내 Kind가 ReplicaSet인 것을 확인할 수 있으며, 이를 실행시키면 replicas에 지정되어 있는 개수대로 파드가 실행됩니다. 실행될 때 .spec.selector.matchLabels 하위에 지정된 라벨과 동일한 라벨을 .spec.template.metadata.labels의 하위에서 찾아서 해당 컨테이너를 replicas 에 지정된 개수대로 실행하는 구조입니다.

이때 특정 파드를 선택하여 'kubectl delete pods <pod name>'로 지우더라도 다시 실행되는 것을 확인할 수 있습니다. 파드의 개수를 조정하려면 템플릿(*.yaml) 내의 .spec.replicas 필드 값을 수정한 후 'kubectl apply -f replicaset-nginx.yaml' 템플릿을 다시 실행해야 합니다.

3.2.2. 레플리카세트와 파드의 연관 관계

템플릿을 활용하여 생성한 레플리카세트가 정상적으로 실행되었는지 확인하기 위해서는 다음의 명령으로 확인할 수 있습니다.

% kubectl get pods,replicaset
NAME                             READY   STATUS    RESTARTS      AGE
pod/nginx-replicaset-4v65n       1/1     Running   0             21m
pod/nginx-replicaset-jhd5g       1/1     Running   0             22m
pod/nginx-replicaset-r6hrk       1/1     Running   0             21m

NAME                                   DESIRED   CURRENT   READY   AGE
replicaset.apps/nginx-replicaset       3         3         3       59s

여기서 DESIRED는 레플리카 세트 설정에 지정한 파드의 개수이며, CURRENT는 현재 클러스터에서 동작하는 실제 파드의 개수입니다. 정상적으로 띄워진 것을 확인할 수 있죠? 여기서 파드를 제외한 레플리카세트만 죽일 수 있을까요? 이는 파드와 레플리카세트와의 관계를 통해 확인할 수 있습니다.

파드는 레이블 기준으로 관리하므로 레플리카세트와 파드는 느슨하게 결합되어 있습니다. 따라서 레플리카세트와 파드를 한꺼번에 삭제할 때는 kubectl delete replicaset <컨테이너 이름> 명령으로 삭제하지만, 레플리카세트만 삭제하기 위해서는 --cascade=orphan 옵션을 사용하여야 합니다.

% kubectl delete replicaset nginx-replicaset --cascade=orphan 
replicaset.apps "nginx-replicaset" deleted

% kubectl get pods,replicaset                                
NAME                             READY   STATUS    RESTARTS      AGE
pod/nginx-replicaset-4v65n       1/1     Running   0             24m
pod/nginx-replicaset-jhd5g       1/1     Running   0             26m
pod/nginx-replicaset-r6hrk       1/1     Running   0             24m

3.3 디플로이먼트

디플로이먼트(Deployment)는 쿠버네티스에서 stateless 앱을 배포할 때 사용하는 가장 기본적인 컨트롤러입니다. 이는 단순히 실행시켜야 할 파드 개수를 유지하는 것 뿐만 아니라 앱을 배포할 때 롤링 업데이트, 앱 배포 도중 잠시 멈췄다가 재배포, 배포 후 이전 버전으로 롤백 기능도 지원합니다.

디플로이먼트에 사용하는 템플릿은 예제 deployment/deployment-nginx.yaml를 참고하시면 됩니다.

% kubectl apply -f deployment/deployment-nginx.yaml
deployment.apps/nginx-deployment created

% kubectl get deploy,rs,rc,pods
NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx-deployment   3/3     3            3           69s

NAME                                         DESIRED   CURRENT   READY   AGE
replicaset.apps/nginx-deployment-dfcbd5fd6   3         3         3       69s

NAME                                   READY   STATUS    RESTARTS   AGE
pod/nginx-deployment-dfcbd5fd6-jdtrh   1/1     Running   0          69s
pod/nginx-deployment-dfcbd5fd6-s8mx7   1/1     Running   0          69s
pod/nginx-deployment-dfcbd5fd6-x4n5d   1/1     Running   0          69s

예제를 살펴보면 템플릿 내 Kind가 Deployment인 것을 확인할 수 있으며, 이를 실행시키면 nginx-deployment라는 디플로이먼트와 이 디플로이먼트가 관리하는 레플리카세트도 생성되었습니다. 여기서 생성확인을 위해 사용된 'kubectl get deploy,rs,rc,pods'에서 deploy는 디플로이먼트, rs는 리플리카세트, pods는 파드, rc는 리플리케이션 컨트롤러를 의미하며 리플리케니션 컨트롤러는 사용하지 않는다는 것을 보여주기 위해서 넣었습니다.

이 상태에서 nginx-deployment의 컨테이너 이미지 설정 정보를 확인하는 방법은 다음과 같습니다.

% kubectl get deploy nginx-deployment -o=jsonpath="{.spec.template.spec.containers[0].image}{'\n'}"
nginx

nginx 이미지를 확인할 수 있으며, 이를 변경하는 방법은 다음과 같은 3가지가 있습니다.

1. kubectl set 명령으로 직접 컨테이너 이미지를 지정

% kubectl set image deployment/nginx-deployment nginx-deployment=nginx:1.10.1                    
deployment.apps/nginx-deployment image updated

2. kubectl edit 명령으로 현재 파드의 설정 정보를 연 다음 컨테이너 이미지 정보를 수정

% kubectl edit deploy nginx-deployment

위의 명령어를 실행하면 기본 editor(e.g. vi 에디터)에 실행했던 템플릿이 뜨는 것을 확인할 수 있고 여기서 수정하면 됩니다(물론, 기존에 작성했던 *.yaml 파일은 수정되지 않습니다.).

3. 처음 적용했던 템플릿의 컨테이너 이미지 정보를 수정한 다음 kubectl apply 명령을 실행해서 변경

실제 파일로 남기에 필자가 가장 추천하는 방법이며, 가장 쉽고 편리한 방법입니다.

3.3.2. 디플로이먼트 롤벡하기

컨테이너의 변경 내역은 다음의 명령어로 확인할 수 있으며, 특정 버전에 대한 세부 정보를 알고 싶다면 --rivision=<리비전 숫자> 옵션으로 확인할 수 있습니다.

% kubectl rollout history deploy nginx-deployment
deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
2         <none>
3         <none>
4         <none>

% kubectl rollout history deploy nginx-deployment --revision=3  
deployment.apps/nginx-deployment with revision #3
Pod Template:
  Labels:       app=nginx-deployment
        pod-template-hash=748b8dbccc
  Containers:
   nginx-deployment:
    Image:      nginx:1.10.1
    Port:       80/TCP
    Host Port:  0/TCP
    Environment:        <none>
    Mounts:     <none>
  Volumes:      <none>

여기서 특정 리비전으로 실행중인 파드를 되돌리려면 --to-revision=<리비전 숫자> 옵션과 함께 다음의 명령어를 사용할 수 있습니다.

% kubectl rollout undo deploy nginx-deployment --to-revision=3
deployment.apps/nginx-deployment rolled back

이렇게 롤백을 사용하기 위해서는 리비전마다 버전정보를 붙여주어 관리하면 보다 쉽게 파악할 수 있는데, 이는 *.yaml 파일 내에 .metadata.annotations 필드를 추가하면 history를 확인할 때 CHANGE-CAUSE에 버전 정보가 기재됩니다.

metadata:
  name: nginx-deployment
  labels:
    app: nginx-deployment
  annotations:
    kubernetes.io/change-cause: version 1.10.1

3.3.3. 파드 개수 조정하기

실행 중인 디플로이먼트의 파드 개수를 조정하려면 kubectl scale 명령에 --replicas 옵션으로 파드 개수를 지정해줄 수 있습니다.

% kubectl scale deploy nginx-deployment --replicas=5
deployment.apps/nginx-deployment scaled

3.3.4. 디플로이먼트 배포 정지, 배포 재개, 재시작하기

kubectl rollout 명령을 이용해서 진행중인 배포를 pause를 통해 잠시 멈췄다가 resume으로 다시 시작할 수 있습니다.

% kubectl rollout pause deployment/nginx-deployment
% kubectl rollout resume deploy/nginx-deployment

pause를 통해 멈춘 상태에서 set, patch와 같은 명령으로 수정한 후 resume을 통해 재개하는 구조입니다.

% kubectl set image deploy/nginx-deployment nginx-deployment=nginx:1.11
deployment.apps/nginx-deployment image updated
% kubectl patch deployment/nginx-deployment -p "{\"metadata\":{\"annotations\":{\"kubernetes.io/change-cause\":\"version 1.11\"}}}"
deployment.apps/nginx-deployment patched

3.3.5. 디플로이먼트 상태

배포 중에는 디플로이먼트 상태가 변합니다. 우선 Progressing 상태였다가 성공이면 Complete, 실패면 Failed 상태로 변합니다. kubectl rollout status 명령으로 배포 진행 상태를 확인합니다.

여기서 템플릿에 .spec.progressDeadlineSeconds 항목이 있을 경우, 여기서 지정된 시간이 지났을 때까지 배포를 하지 못할 경우 상태를 false로 바뀌도록 구성할 수 있습니다.

3.4. 데몬세트

데몬세트(Daemonset)는 클러스터 전체 노드에 특정 파드를 실행할 때 사용하는 컨트롤러입니다. 클러스터 안에 새롭게 노드가 추가되었을 때 데몬세트가 자동으로 해당 노드에 파드를 실행시킵니다. 반대로 노드가 클러스터에서 빠질때는 해당 노드에 있떤 파드는 그대로 사라질 뿐 다른곳으로 옮겨가서 실행되거나 하지 않습니다. 그러므로 데몬세트는 보통 로그 수집기를 실행하거나 노드를 모니터링하는 모니터링용 데몬 등 클러스터 전체에 항상 실행시켜두어야 하는 파드에 사용합니다.

3.4.1. 데몬세트 사용하기

데몬세트를 이용해 로그수집기를 사용하기 위한 템플릿을 살펴보겠습니다. 예제의 daemonset/daemonset.yaml을 참고하시면 됩니다.

여기서 .metadata.namespace 필드값으로 kube-system 네임스페이스를 별도로 설정하였으며, 데몬세트의 파드를 업데이트하는 방법을 RollingUpdate(기본값)로 설정하여 탬플릿 변경시 바로 변경사항을 반영하도록 합니다. 추가로 .spec.updateStrategy.rollingUpdate.maxUnavailable 필드로 한번에 삭제하는 파드 개수를 지정할 수 있으며, .spec.minReadySeconds 필드로 새로 실행하는 파드가 준비상태가 되는 최소시간을 설정할 수 있습니다.

% kubectl apply -f daemonset/daemonset.yaml
daemonset.apps/fluentd-elasticsearch created
% kubectl get daemonset -n kube-system
NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
fluentd-elasticsearch   1         1         1       1            1           <none>                   14s
kube-proxy              1         1         1       1            1           kubernetes.io/os=linux   67d

3.4.2. 데몬세트의 파드 업데이트 방법 변경하기

'kubectl edit daemonset fluentd-elasticsearch -n kube-system' 명령으로 앞에서 실행한 데몬세트의 설정을 열어 다른 값으로 변경할 수 있습니다. 예시로 .spec.template.spec.containers[].env[].value 필드값을 value01로 바꾸고 저장하였으며, 현재 업데이트방식이 RollingUpdate이므로 파드는 즉시 재시작됩니다. 'kubectl describe daemonset -n kube-system'으로 변경사항을 확인할 수 있습니다.

% kubectl edit daemonset fluentd-elasticsearch -n kube-system
% kubectl describe daemonset -n kube-system

여기서 만약 업데이트 방식이 RollingUpdate가 아닌 OnDelete라면? 변경사항이 바로 적용되지 않고 데몬세트로 실행한 파드를 직접 지워야 해당 노드에 새로운 탬플릿버전의 파드가 실행되는 방식입니다.

이를 테스트하기 위해 .spec.template.spec.containers[].env[].value 필드값을 value02로, .spec.updateStrategy.type 필드값을 OnDelete로 변경 후 'kubectl get daemonset -n kube-system'로 데몬세트를 확인해보면? UP-TO-DATE 항목이 0으로 변경은 했으나 최신 설정으로 변경되지 않았습니다.

% kubectl delete pods [파드이름] -n kube-system

이때 위와 같은 명령으로 해당파드를 지웠다가 다시 'kubectl describe daemonset -n kube-system'로 확인해보면 데몬세트가 최신상태로 변경되었음을 알 수 있다.

3.5. 스테이트풀세트

앞서 배웠던 1,2,3절의 컨트롤러들은 모두 상태가 없는(Stateless) 파드들을 관리하는 용도였으며, 스테이트풀세트(StatefullSets)는 상태가 있는 파드들을 관리하는 컨트롤러입니다.

스테이트풀세트를 사용하면 볼륨(volume)을 사용해 특정 데이터를 저장한 후 파드를 재시작했을 때 해당 데이터를 유지합니다. 여러 개의 파드 사이에 순서를 지정해 그대로 실행되도록 할 수도 있습니다. 이런 방식으로 어떠한 상태가 있어야 할 때 사용합니다.

3.5.1. 스테이트풀세트 사용하기

스테이트풀세트를 사용하기 위한 템플릿을 살펴보겠습니다. 예제의 statefulset/statefulset.yaml을 참고하시면 됩니다.

해당 템플릿의 kind는 Service로 7장에서 설명할 내용입니다. 이는 .spec.serviceName 필드값으로 설정할 서비스를 정의하며, 서비스 이름과 스테이트풀세트에서 만들어진 파드 이름을 조합하면 k8s 클러스터 안에서 사용하는 도메인을 만들 수 있습니다([파드이름].[서비스이름] 형식). 추가로 .spec.template.spec.terminationGracePeriodSeconds 필드로 그레이스풀의 대기시간을 설정합니다. 여기서 그레이스풀이란? 실행중인 프로세스를 종료할 때 바로 하는것이 아니라 하던 작업을 마무리 후 정상종료하는 것입니다.

% kubectl apply -f statefulset/statefulset.yaml
service/nginx-statefulset-service created
statefulset.apps/web created

% kubectl get svc,statefulset,pods
NAME                                TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes                  ClusterIP   10.96.0.1    <none>        443/TCP   67d
service/nginx-statefulset-service   ClusterIP   None         <none>        80/TCP    2m26s

NAME                   READY   AGE
statefulset.apps/web   3/3     2m26s

NAME                        READY   STATUS    RESTARTS   AGE
pod/kubernetes-simple-pod   1/1     Running   2          14d
pod/web-0                   1/1     Running   0          2m26s
pod/web-1                   1/1     Running   0          2m16s
pod/web-2                   1/1     Running   0          2m13s

기존과 다르게 파드이름의 UUID 형식의 접미사가 붙는게 아니라 web- 이란 이름 뒤에 0,1,2처럼 숫자가 순서대로 붙는 것을 확인할 수 있으며, 파드가 실행될 때 해당 순서로 실행되어 앞에 것이 정상 실행되지 않았다면 뒤의 파드는 실행되지 않습니다. 추가로 삭제는 실행의 역순이며, .spec.replicas 필드값을 줄이면 큰 수부터 줄인 숫자 개수만큼 삭제된다.

% kubectl edit statefulset web

위의 명령으로 실행중인 스테이트풀세트의 설정에서 .spec.replicas 필드값을 3에서 2로 변경하면 web-2 파드가 사라집니다.

3.5.2. 파드를 순서 없이 실행하거나 종료하기

스테이트풀세트의 기본동작은 순서대로 파드를 관리하는 것이지만 .spec.podManagementPolicy 필드로 순서를 없앨 수도 있습니다. 기본 값은 OrderedReady이고 파드를 순서대로 관리하지만, 이를 Parallel로 변경하면 파드들이 순서없이 실행되거나 종료되도록 할 수 있습니다. 기존 스테이트풀세트에선 이를 변경할수 없다고 하니 새로운 스테이트풀세트를 설정하겠습니다.

스테이트풀세트를 이용해 파드를 순서 없이 실행/종료 사용하기 위한 템플릿을 살펴보겠습니다. 예제의 statefulset/statefulset-parallel.yaml을 참고하시면 됩니다. 이를 실행해보면 이전과 다르게 파드가 한꺼번에 만들어지며, replicas를 조정하더라도 랜덤으로 삭제되는 것을 확인할 수 있습니다.

3.5.3. 스테이트풀세트로 파드 업데이트하기

스테이트풀세트의 업데이트 방법은 .spec.updateStrategy.type 필드에서 설정할 수 있습니다. 기본 값은 RollingUpdate이며 탬플릿 변경시 자동으로 예전 파드 삭제 후 새로운 파드를 실행합니다.

web 스테이트풀 세트에 kubectl edit statefulset web 명령을 실행해 .spec.template.spec.containers[].env[] 환경변수를 추가하고 저장하면 탬플릿을 변경함에 따라 파드들이 재시작되는 걸 알 수 있습니다.

여기서 .spec.updateStrategy. rollingUpdate.partition 필드 값을 바꾸면 해당 필드에 지정된 값보다 큰 번호를 가진 파드들만 업데이트를 적용시킨다. 말 그대로 파드들을 분할하는 역할이며, 이 값을 1로 지정하고 .spec.containers[].env[].value 필드값을 testvalue04로 변경해 저장해보면 partition 필드에 값보다 큰 1, 2번 파드만 업데이트가 적용됩니다. 다음의 명령어로 변경된 것을 확인할 수 있습니다.

% kubectl get pods -o jsonpath="{range .items[*]}{.metadata.name}{.spec.containers[0].env}{'\n'}{end}"

만약 partition 필드 값이 replicas 필드보다 크다면 .spec.template 필드에 변경사항이 있어도 업데이트하지 않습니다.

% kubectl describe pod web-0

위 명령으로 파드상태를 확인해보면 labels 항목에 statefulset.kubernetes.io/pod-name=web-0처럼 레이블이 추가된 것도 확인할 수 있습니다. 이 레이블을 이용하면 스테이트풀세트가 관리하는 전체 파드중 특정 파드에만 서비스를 연결할 수도 있습니다.

4. 서비스

서비스는 여러 개 파드에 접근할 수 있는 IP 하나를 제공합니다. 다양한 기능을 제공하지만 본질적으로 로드밸런서 역할입니다. 이장에서는 서비스의 개념, 타입, 사용 방법들을 알아봅니다. 그리고 실제 서비스를 다루는 kube-proxy도 소개합니다.

4.1. 서비스의 개념

쿠버네티스 클러스터 안에 컨트롤러를 이용해서 파드를 실행했다면 해당 파드에 접근하는 방법을 알아봐야 할 때입니다. 파드는 컨트롤러가 관리하므로 한군데에 고정해서 실행되지 않고 클러스터 안을 옮겨 다닙니다. 이 과정에서 노드를 옮기면서 클러스터 내 파드의 IP가 변경되기도 하는데, 이렇게 동적으로 변하는 파드들에 고정적으로 접근할 때 사용하는 방법이 쿠버네티스의 서비스입니다.

서비스를 사용하면 파드가 클러스터 안 어디에 있든 고정 주소를 이용해 접근할 수 있습니다. 클러스터 외부에서 클러스터 안 파드에 접근할 수 있습니다. '5. 인그레스(책 내 8장)'에서 설명할 인그레스로 접근할수 있지만, 서비스는 주로 L4 영역이며 인그레스는 L7 영역에서 통신할 때 사용한다는 차이가 있습니다.

4.2. 서비스 타입

서비스 타입에는 크게 네가지가 있습니다.

ClusterIP:
- 기본 서비스 타입이며 쿠버네티스 클러스터 안에서만 사용할 수 있으며, 클러스터 외부에서는 이용할 수 없습니다.
- 클러스터 안 노드나 파드에서는 클러스터 IP를 이용해서 서비스에 연결된 파드에 접근합니다.
NodePort:
- 서비스 하나에 모든 노드의 지정된 포트를 할당합니다.
- 노드에 상관없이 서비스에 지정된 포트번호만 사용하면 파드에 접근할 수 있습니다.
- 노드의 포트를 사용하므로 클러스터 안 뿐만 아니라 클러스터 외부에서도 접근할 수 있습니다.
LoadBalancer:
- AWS, GCP 같은 퍼블릭 클라우드 서비스, 오픈스택같은 프라이빗 클라우드, 쿠버네티스를 지원하는 로드밸런서 장비에서 사용합니다.
- 클라우드에서 제공하는 로드밸런서와 파드를 연결한 후 해당 로드밸런서의 IP를 이용해 클러스터 외부에서 파드에 접근할 수 있도록 해줍니다.
- kubectl get service 명령으로 서비스 상태를 확인하면 EXTERNAL -IP 항목에 로드밸런서 IP를 표시합니다. 해당 로드밸런서 IP를 이용하여 클러스터 외부에서 파드에 접근합니다.
ExternalName:
- 서비스를 .spec.externalName 필드에 설정한 값과 연결하며, 클러스터 안에서 외부에 접근할 때 주로 사용합니다.
- 이 서비스로 클러스터 외부에 접근하면 설정해둔 CNAME 값을 이용해 접근할 수 있습니다.
- 클러스터 외부에 접근할 때 사용하는 값이므로 설정할 때 셀렉터(spec.selector 필드)가 필요없습니다.

4.3. 서비스 사용하기

서비스 템플릿의 기본 구조는 service/service.yaml 과 같습니다.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: ClusterIP
  clusterIP: 10.0.10.10
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376

.spec.type 필드에서 서비스 타입을 설정할 수 있습니다. .spec.type 필드 값을 설정하지 않으면 기본 타입인 ClusterIP입니다.
.spec.clusterIP 필드에서 클러스터 IP를 직접 설정할 수 있습니다. 설정하지 않으면 자동으로 IP 값이 할당됩니다.
.spec.selector 필드에는 서비스와 연결할 파드에 설정한 .labels 필드 값을 설정합니다.
.spec.ports[] 필드는 배열 형태입니다. 서비스에서 한꺼번에 포트 여러 개를 외부에 제공할 때는 .spec.ports[] 하위에 필드 값을 설정하면 됩니다.

지금부터 서비스 타입 각각을 만들고 사용해보겠습니다. 먼저 다음 명령으로 디플로이먼트로 생성하는 서비스에 연결할 파드를 실행합니다.

% kubectl create deployment nginx-for-service --image=nginx --replicas=2 --port=80 
deployment.apps/nginx-for-service created

nginx 컨테이너를 실행하는 nginx-for-service라는 이름의 파드입니다. 포트 번호는 80, 서비스에서 사용할 레이블은 키 app, 값은 nginx-for-svc로 정의했습니다.

4.3.1. ClusterIP 타입 서비스 사용하기

서비스타입이 ClustreIP인 서비스를 만드는 설정은 service/clusterip.yaml 과 같습니다.

% kubectl apply -f ./service/clusterip.yaml     
service/clusterip-service created
% kubectl get svc
NAME                        TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
clusterip-service           ClusterIP   10.104.210.96   <none>        80/TCP    72s
kubernetes                  ClusterIP   10.96.0.1       <none>        443/TCP   80d
nginx-statefulset-service   ClusterIP   None            <none>        80/TCP    13d

TYPE 항목이 ClusterIP고 CLUSTER-IP 항목에 10.104.210.96로 클러스터 IP가 생성되었으며, PORT는 80 포트에 연결되었습니다.
또한 ClusterIP은 외부에서 접근할 수 없으므로 외부 IP가 없으므로 EXTERNAL-IP 항목은 <none>입니다.

kubectl describe service <NAME>으로 해당 서비스에 대해 더욱 자세히 확인할 수 있습니다.

% kubectl describe service clusterip-service
Name:              clusterip-service
Namespace:         default
Labels:            <none>
Annotations:       <none>
Selector:          app=nginx-for-svc
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.104.210.96
IPs:               10.104.210.96
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.1.0.22:80
Session Affinity:  None
Events:            <none>

이제 10.104.210.96라는 IP로 파드에 접근할 수 있는지 확인해보겠습니다. 클러스터 IP는 쿠버네티스 클러스터 안에서만 사용할 수 있는 IP 입니다. 그러므로 쿠버네티스 클러스터 안에 파드를 하나 실행하고 해당 파드 안에서 앞서 만든 클러스터 IP로 접속해보겠습니다.

이는 앞서 설명한 netshoot 컨테이너 이미지를 사용합니다.

% kubectl run -it --image nicolaka/netshoot testnet -- bash

bash-5.0# curl 10.104.210.96
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...

4.3.2. NodePort 타입 서비스 사용하기

서비스타입이 NodePort인 서비스를 만드는 설정은 service/nodeport.yaml 과 같습니다.

% kubectl apply -f ./service/nodeport.yaml
service/nodeport-service created

NodePort의 경우 해당 포트로 외부에서 접근가능하며, 해당 템플릿에서는 .spec.ports[].nodePort: 30080로 포트가 설정되어 있습니다. 따라서 웹 브라우저에서 localhost:30080으로 접속하면 nginx 기본 화면이 나오는 것을 확인할 수 있습니다.

4.3.3. LoadBalancer 타입 서비스 사용하기

서비스타입이 LoadBalancer인 서비스를 만드는 설정은 service/loadbalancer.yaml 과 같습니다.

% kubectl apply -f ./service/loadbalancer.yaml
service/loadbalancer-service created

% kubectl get svc
NAME                        TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)       80d
loadbalancer-service        LoadBalancer   10.104.228.235   localhost     80:30920/TCP   58s

현재 실습환경이 도커 데스트톱이기에 외부 로드밸런서가 없어 EXTERNAL-IP 항목이 localhost로 나타납니다. 만약 외부 로드밸런서와 연계되어 쿠버네티스 클러스터가 설정된 상태라면 실제 외부에서 접근가능한 IP가 나타날 것입니다.

4.3.3. ExternalName 타입 서비스 사용하기

서비스타입이 ExternalName인 서비스를 만드는 설정은 service/externalname.yaml 과 같습니다.

% kubectl apply -f ./service/externalname.yaml
service/externalname-service created

% kubectl get svc                             
NAME                        TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
externalname-service        ExternalName   <none>           google.com    <none>         15s

클러스터 안에서 사용하지 않으므로 CLUSTER-IP 항목이 <none>입니다. 또한 EXTERNAL-IP는 .spec.externalName에서 설정한 google.com으로 확인할 수 있습니다.

% kubectl run -it --image nicolaka/netshoot testnet -- bash

bash-5.0# curl externalname-service.default.svc.cluster.local
<!DOCTYPE html>
<html lang=en>
  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 404 (Not Found)!!1</title>
...

ExternalName 타입 서비스의 클러스터 내부 도메인은 externalname-service.default.svc.cluster.local이며, curl로 해당 도메인에 접속보면 실제 google.com의 HTML 마크업이 출력되는 것을 확인할 수 있습니다.

4.4. 헤드리스 서비스

.spec.clusterIP 필드 값을 None으로 설정하면 클러스터 IP가 없는 서비스를 만들 수 있으며, 이를 헤드리스 서비스라 합니다. 로드밸런싱이 필요 없거나 단일 서비스 IP가 필요없을 때 사용합니다.

헤드리스 서비스에 셀렉터를 설정하면 쿠버네티스 API로 확인할 수 있는 엔드포인트가 만들어집니다. 여기서 셀렉터가 없으면 엔드포인트가 만들어지지 않으며 셀렉터가 없더라도 DNS 시스템은 ExternalName 타입의 서비스에서 사용한 CNAME 레코드가 만들어집니다.

% kubectl apply -f ./service/headless.yaml    
service/headless-service created

% kubectl get svc
NAME                        TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
headless-service            ClusterIP      None             <none>        80/TCP         7s

% kubectl describe svc headless-service
...
Endpoints:         10.1.0.22:80

IP 항목은 None이지만 Endpoints 항목에는 .spec.selector필드에서 선택한 조건에 맞는 파드들의 IP와 포트 정보를 확인할 수 있습니다.

DNS A 레코드가 만들어져 있는지 확인하려면 nicolaka/netshoot 이미를 이용한 파드를 만들고 dig <도메인 이름> 명령을 실행합니다.

% kubectl run -it --image nicolaka/netshoot testnet -- bash

bash-5.0# dig headless-service.default.svc/cluster.local

4.5. kube-proxy

kube-proxy는 쿠버네티스에서 서비스를 만들었을 때 클러스터 IP나 노드 포트로 접근할 수 있게 만들어 실제 조작을 하는 컴포넌트입니다. 쿠버네티스 클러스터의 노드마다 실행되면서 클러스터 내부 IP로 연결하려는 요청을 적절한 파드로 전달합니다.

kube-proxy가 네트워크를 관리하는 방법은 userspace, iptables, IPVS가 있습니다. 초기에 userspace가 기본 관리모드였고 현재 iptables가 기본 관리 모드입니다. 앞으로는 IPVS로 기본 관리 모드가 바뀔 것으로 예상합니다.

4.5.1. userspace 모드

https://kubernetes.io/ko/docs/concepts/services-networking/service/#proxy-mode-userspace

클라이언트에서 서비스의 클러스터 IP를 통해 어떤 요청을 하면 iptable을 거쳐서 kube-proxy가 요청을 받습니다.
그리고 서비스의 클러스터 IP는 연결되어야 하는 적절한 파드로 연결해줍니다.
이때 요청을 나워줄 때는 라운드 로빈 방식을 사용합니다.

4.5.2. iptables 모드

https://kubernetes.io/docs/reference/networking/virtual-ips/#proxy-mode-iptables

userspace 모드와 다른 점은 kube-proxy가 iptable를 관리하는 역할만 하여, 직접 클라이언트에서 트래픽을 받지 않습니다.

4.5.3. IPVS 모드

https://kubernetes.io/docs/reference/networking/virtual-ips/#proxy-mode-ipvs

IPVS 모드는 리눅스 커널 안 네트워크 관련 프레임워크인 넷필터에 포함되어 있는 L4 로드밸런싱 기술입니다. 따라서 IPVS 커널 모듈이 노드에 설치되어야 합니다.
IPVS 모드는 커널 공간에서 동작하고 데이터 구조를 해시 테이블로 저장하기 때문에 iptables 모드보다 빠르고 좋은 성능을 냅니다. 또한 더 많은 로드밸런싱 알고리즘이 있어서 이를 이용할 수 있습니다.

참고

정원천, 홍석용, 정경록, 공용준. 『쿠버네티스 입문: 90가지 예제로 배우는 컨테이너 관리 자동화 표준』. 옮긴이(역). 동양북스(동양books), 2020.01.
[Github] kubernetes-book-sample: https://github.com/arisu1000/kubernetes-book-sample
[Official Docs] Hello Minikube: https://kubernetes.io/docs/tutorials/hello-minikube/
[Official Docs] : https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/

저작자표시 비영리 변경금지 (새창열림)

'Study: DeveloperTools(DevTool) > DevTool: Container' 카테고리의 다른 글

[Docker] 도커 이미지를 tar 파일로 저장 (export / import / save / load) (0)	2023.10.10
[Docker] Slicon M1 Mac에서 Lima로 Docker Desktop 대체 하기 (0)	2023.04.28
[Kubernetes] 쿠버네티스 입문: Part I. 쿠버네티스 시작하기 (0)	2023.02.23
[Docker] docker-compose에서 links와 depends_on의 차이점 (0)	2023.01.11
[Docker] 컨테이너 내부 파일에 접근하는 4가지 방법 (0)	2022.12.20

« 2025/06 »
일	월	화	수	목	금	토
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30