K8s는 여러 컨테이너 런타임을 지원하며, 여기서는 Docker 런타임을 기본으로 설명한다.
(Docker 18.09 이상에서는 containerd를 Docker에서 기본으로 탑재한다)
그러므로, Docker에 대한 기본 개념 및 사용법을 알고 있다고 가정한다.

Overview

Concept

K8s는 하나 이상의 container로 이루어진 pod cluster를, 하나의 어플리케이션인 것처럼 운영하는 방법을 제시한다는 철학을 기반으로 하여, planning 하고 독립적이고 조합 가능한 제어 프로세스들로 구성된 오픈소스 플랫폼.

기존 전통적 방식(monolithic)의 서비스 운영에서의 난제인 CD 및 어플리케이션 운영 자동화/관리를, 컨테이너 기반의 마이크로 서비스 기반으로 전환 관리하기 위해 보다 쉽고 나은 solution을 제시한다.

Key Features - K8s provide you with:

Service discovery and load balancing
- Kubernetes can expose a container using the DNS name or using their own IP address. If traffic to a container is high, Kubernetes is able to load balance and distribute the network traffic so that the deployment is stable.
Storage orchestration
- Kubernetes allows you to automatically mount a storage system of your choice, such as local storages, public cloud providers, and more.
Automated rollouts and rollbacks
- You can describe the desired state for your deployed containers using Kubernetes, and it can change the actual state to the desired state at a controlled rate. For example, you can automate Kubernetes to create new containers for your deployment, remove existing containers and adopt all their resources to the new container.
Automatic bin packing
- You provide Kubernetes with a cluster of nodes that it can use to run containerized tasks. You tell Kubernetes how much CPU and memory (RAM) each container needs. Kubernetes can fit containers onto your nodes to make the best use of your resources.
Self-healing
- Kubernetes restarts containers that fail, replaces containers, kills containers that don’t respond to your user-defined health check, and doesn’t advertise them to clients until they are ready to serve.
Secret and configuration management
- Kubernetes lets you store and manage sensitive information, such as passwords, OAuth tokens, and SSH keys. You can deploy and update secrets and application configuration without rebuilding your container images, and without exposing secrets in your stack configuration.

What K8s is not:

지원하는 애플리케이션의 유형을 제약하지 않는다.
소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다.
애플리케이션 레벨의 서비스를 제공하지 않는다.
로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 즉, 메트릭을 수집하고 노출하는 메커니즘을 제공한다.
K8s는 단순한 오케스트레이션 시스템이 아니다. 사실, K8s는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, K8s는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도한 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.

Architecture Components

Master node: 컨트롤 플레인(control plane) 컴포넌트

kube-apiserver
- API 서버는 K8s 컨트롤 플레인의 프론트 엔드이다.
etcd
- 모든 cluster 데이터를 담는 K8s backend consistent and highly-available key value storestore.
kube-scheduler
- Node가 배정되지 않은 새로 생성된 pod를 감지하고, 실행할 node를 선택하는 컨트롤 플레인 컴포넌트.
- 스케줄링 결정을 위해서 고려되는 요소는 resource에 대한 개별 및 총체적 요구 사항, 하드웨어/소프트웨어/정책적 제약, 어피니티(affinity) 및 안티-어피니티(anti-affinity) 명세, 데이터 지역성, 워크로드-간 간섭, 데드라인을 포함한다.
kube-controller-manager
- 컨트롤러를 구동하는 마스터 상의 컴포넌트.
- 여러 Workload 모델들을 구동시키는 역할을 담당한다.
- 논리적으로, 각 컨트롤러는 개별 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행된다.
- 이들 컨트롤러는 다음을 포함한다.
  - 노드 컨트롤러(NC): 노드가 다운되었을 때 통지와 대응에 관한 책임을 가진다.
  - 리플리케이션 컨트롤러(RC): 시스템의 모든 레플리케이션 컨트롤러 object에 대해 알맞은 수의 파드들을 유지시켜 주는 책임을 가진다.
  - 엔드포인트 컨트롤러(EC): 엔드포인트 object를 채운다(즉, 서비스와 파드를 연결시킨다.)
  - 서비스 어카운트(SAC) & 토큰 컨트롤러(TC): 새로운 Namespace에 대한 기본 계정과 API 접근 토큰을 생성한다.
cloud-controller-manager
- 클라우드별 컨트롤 로직을 포함하는 K8s 컨트롤 플레인 컴포넌트
- cloud-controller-manager는 클라우드 제공자 전용 컨트롤러만 실행한다. 자신의 사내 또는 PC 내부의 학습 환경에서 K8s를 실행 중인 경우 cluster에는 클라우드 컨트롤러 매니저가 없다
- kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적으로 독립적인 여러 컨트롤 루프를 단일 프로세스로 실행하는 단일 바이너리로 결합한다. 수평으로 확장(두 개 이상의 복제 실행)해서 성능을 향상시키거나 장애를 견딜 수 있다.
- 다음 컨트롤러들은 클라우드 제공 사업자의 의존성을 가질 수 있다.
  - 노드 컨트롤러: 노드가 응답을 멈춘 후 클라우드 상에서 삭제되었는지 판별하기 위해 클라우드 제공 사업자에게 확인하는 것
  - 라우트 컨트롤러: 기본 클라우드 인프라에 경로를 구성하는 것
  - 서비스 컨트롤러: 클라우드 제공 사업자 로드밸런서를 생성, 업데이트 그리고 삭제하는 것

Worker Node 컴포넌트

kubelet
- cluster의 각 노드에서 실행되는 에이전트.
  Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리.
- Kubelet은 8s를 통해 생성되지 않는 컨테이너는 관리하지 않는다.
kube-proxy
- kube-proxy는 cluster의 각 노드에서 실행되는 네트워크 프록시로, K8s의 서비스 개념의 구현부
- kube-proxy는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 cluster 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다.
- kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다.
Container runtime
- 컨테이너 실행을 담당하는 소프트웨어
- 도커(Docker), containerd, CRI-O 그리고 Kubernetes CRI (컨테이너 런타임 인터페이스)를 구현한 모든 소프트웨어 지원.

Addon

애드온은 K8s resource(데몬셋, 디플로이먼트 등)를 이용하여 cluster 기능을 구현한다.
이들은 cluster 단위의 기능을 제공하기 때문에 애드온에 대한 Namespace resource는 kube-system Namespace에 속한다.(Not all).

선택된 일부 애드온은 아래에 설명하였고, 사용 가능한 전체 확장 애드온 리스트는 애드온을 참조한다

DNS
- K8s에 의해 구동되는 컨테이너는 DNS 검색에서 이 DNS 서버를 자동으로 포함한다
웹 UI (대시보드)
컨테이너 resource 모니터링
- 컨테이너 resource 모니터링은 중앙 데이터베이스 내의 컨테이너들에 대한 포괄적인 시계열 매트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다.
cluster-레벨 로깅
- cluster-레벨 로깅 메커니즘은 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 진다.

Understanding Terms(중요)

여기서는 아래 블로그를 포함하여 각종 관련 사이트 및 K8s 공식 사이트 문서를 참고하여, 보다 간략히 k8s에 대한 이해에 반드시 필요한 개념 위주로 추려서 기술한다.
즉, 각각의 정책 object(pod, service, deployment, replica 등)마다 많은 기능과 옵션을 포함하기 때문에, deep dive한 설명은 생략될 수 있다.

내용 中 일부 출처: https://bcho.tistory.com/1256?category=731548 [조대협의 블로그]

아래 object들은 대부분 [yaml or json] 파일 형식으로 선언 및 정의하여, 사용 혹은 재 사용 된다.
상세한 명세는 k8s 공식 가이드를 참고할 수 있으며, 여기에서는 이후 별도로 다룰 예정이다.

참고로, 현재는 거의 모든 오픈소스 소프트웨어든 특정 벤더 소프트웨어든 간에, dockerfile, docker 이미지 및 k8s object 명세 파일을 각 제품의 배포(설치) 방식에 포함하고 있다.
따라서 대부분의 경우, 해당 소프트웨어의 k8s object 명세 파일을 받아서 사용 환경에 맞게 커스터마이즈하여 사용하게 된다.

Namespace

Namespace 는 한 K8s cluster내의 논리적인 분리 단위라고 보면 된다.

Pod,Service 등은 Namespace 별로 생성이나 관리가 될 수 있고, 사용자의 권한 역시 이 Namespace 별로 나눠서 부여할 수 있다.

즉 하나의 cluster 내에, 개발/운영/테스트 환경이 있을 때, cluster를 개발/운영/테스트 3개의 Namespace 로 나눠서 운영할 수 있다. Namespace로 할 수 있는 것은,

사용자 별로 Namespace 별 접근 권한을 다르게 운영할 수 있다.
Namespace 별로 resource quota(할당량)을 지정할 수 있다. 개발계에는 CPU 100, 운영계에는 CPU 400과 GPU 100개 식으로, 사용 가능한 resource량을 지정할 수 있다.
Namespace 별로 resource를 나눠서 관리할 수 있다. (Pod, Service 등)

K8s는 처음에 네 개의 초기 namespace를 갖는다.

default 다른 namespace가 없는 object를 위한 default namespace.
kube-system K8s 시스템에서 생성한 object를 위한 namespace.
kube-public 이 namespace는 자동으로 생성되며 모든 사용자(인증되지 않은 사용자 포함)가 읽기 권한으로 접근할 수 있다. 이 namespace는 주로 전체 cluster 중에 공개적으로 드러나서 읽을 수 있는 resource를 위해 예약되어 있다. 이 namespace의 공개적인 성격은 단지 관례이지 요구 사항은 아니다.
kube-node-lease cluster가 스케일링될 때 노드 하트비트의 성능을 향상시키는 각 노드와 관련된 리스(lease) object에 대한 namespace.

모든 object가 특정 namespace에 속하지는 않으며, namespace에 속할 수 없는 속성의 것들도 있다.
예를 들어, Node나 Persistent Volume Claims과 같은 저수준 resource는 어느 namespace에도 속하지 않는다.

다음은 namespace에 속하거나 속하지 않는 K8s resource에 대한 전체 목록을 조회하는 방법이다.

# 네임스페이스에 속하는 리소스
$ kubectl api-resources --namespaced=true
NAME                              SHORTNAMES   APIGROUP                       NAMESPACED   KIND
componentstatuses                 cs                                          false        ComponentStatus
namespaces                        ns                                          false        Namespace
nodes                             no                                          false        Node
persistentvolumes                 pv                                          false        PersistentVolume
mutatingwebhookconfigurations                  admissionregistration.k8s.io   false        MutatingWebhookConfiguration
validatingwebhookconfigurations                admissionregistration.k8s.io   false        ValidatingWebhookConfiguration
customresourcedefinitions         crd,crds     apiextensions.k8s.io           false        CustomResourceDefinition
apiservices                                    apiregistration.k8s.io         false        APIService
tokenreviews                                   authentication.k8s.io          false        TokenReview
selfsubjectaccessreviews                       authorization.k8s.io           false        SelfSubjectAccessReview
selfsubjectrulesreviews                        authorization.k8s.io           false        SelfSubjectRulesReview
subjectaccessreviews                           authorization.k8s.io           false        SubjectAccessReview
certificatesigningrequests        csr          certificates.k8s.io            false        CertificateSigningRequest
ingressclasses                                 networking.k8s.io              false        IngressClass
runtimeclasses                                 node.k8s.io                    false        RuntimeClass
podsecuritypolicies               psp          policy                         false        PodSecurityPolicy
clusterrolebindings                            rbac.authorization.k8s.io      false        ClusterRoleBinding
clusterroles                                   rbac.authorization.k8s.io      false        ClusterRole
priorityclasses                   pc           scheduling.k8s.io              false        PriorityClass
csidrivers                                     storage.k8s.io                 false        CSIDriver
csinodes                                       storage.k8s.io                 false        CSINode
storageclasses                    sc           storage.k8s.io                 false        StorageClass
volumeattachments                              storage.k8s.io                 false        VolumeAttachment

# 네임스페이스에 속하지 않는 리소스
$ kubectl api-resources --namespaced=false
NAME                        SHORTNAMES   APIGROUP                    NAMESPACED   KIND
bindings                                                             true         Binding
configmaps                  cm                                       true         ConfigMap
endpoints                   ep                                       true         Endpoints
events                      ev                                       true         Event
limitranges                 limits                                   true         LimitRange
persistentvolumeclaims      pvc                                      true         PersistentVolumeClaim
pods                        po                                       true         Pod
podtemplates                                                         true         PodTemplate
replicationcontrollers      rc                                       true         ReplicationController
resourcequotas              quota                                    true         ResourceQuota
secrets                                                              true         Secret
serviceaccounts             sa                                       true         ServiceAccount
services                    svc                                      true         Service
controllerrevisions                      apps                        true         ControllerRevision
daemonsets                  ds           apps                        true         DaemonSet
deployments                 deploy       apps                        true         Deployment
replicasets                 rs           apps                        true         ReplicaSet
statefulsets                sts          apps                        true         StatefulSet
localsubjectaccessreviews                authorization.k8s.io        true         LocalSubjectAccessReview
horizontalpodautoscalers    hpa          autoscaling                 true         HorizontalPodAutoscaler
cronjobs                    cj           batch                       true         CronJob
jobs                                     batch                       true         Job
leases                                   coordination.k8s.io         true         Lease
endpointslices                           discovery.k8s.io            true         EndpointSlice
events                      ev           events.k8s.io               true         Event
ingresses                   ing          extensions                  true         Ingress
ingresses                   ing          networking.k8s.io           true         Ingress
networkpolicies             netpol       networking.k8s.io           true         NetworkPolicy
poddisruptionbudgets        pdb          policy                      true         PodDisruptionBudget
rolebindings                             rbac.authorization.k8s.io   true         RoleBinding
roles                                    rbac.authorization.k8s.io   true         Role

Pod

Pod 는 K8s에서 가장 기본적인 배포 단위로, 적어도 하나 이상의 컨테이너를 포함하는 단위이다.
다시 말해서, K8s는 컨테이너 하나하나의 단위로 관리하지 않고, 하나 이상의 컨테이너로 묶인 pod 단위로 관리한다.

여기서, Pod의 중요한 특징이 있는데,

Pod 단위로 internal IP가 할당된다.
Pod 안의 컨테이너들은 IP주소와 포트 공간을 공유한다. 즉, port만 다르다면 서로를 localhost 를 통해 통신할 수 있다.
이들은 또한 SystemV 세마포어나, POSIX 공유 메모리와 같은 표준 프로세스 간 통신 방식으로 서로 통신할 수 있다.
Pod 내에 배포된 컨테이너 간에는 디스크 볼륨을 공유할 수 있다.
따라서 아래 그림과 같이, Web server에 항상 부착되어야 할 프로그램을 묶어서 배포할 수 있으며,
가장 일반적 시나리오는 웹(Nginx) 서비스하면서 access 로그를 pod volume에 남기고, 그 로그는 fluentd로 다시 수집하여 로그 분석 서버(ELK Stack 등)에 전송하는 경우가 있을 수 있다.

K8s는 위 특징을 활용하여, 반드시 같이 묶여서 배포되는 application을 하나의 단위로 관리할 수 있게 해준다.

참고로 Pod에 cpu, memory 사용에 대한 limit을 지정할 수 있으며, Linux CGroup(Control Group)을 사용하여 관리된다.

Pod는 단독으로 yaml 파일로 정의하거나 kubectl 명령 등으로 생성할 수도 있으나,
만일 컨테이너 내 작업이 종료되거나, crash등이 발생하면 node에서 사라진다(terminate).

따라서, Production 환경에서 Pod는 테스트 목적이 아니라면 단독으로 생성하지 않고,
아래 섹션에서 다룰 Controller들로 workload 종류에 알맞게 선택하여 자동화 관리하는 것이 일반적이다.

[Workload] Controller

사용자 application workload model에 따라 - 예를 들어, 대게 Webserver와 DB는 배포 방식을 달리한다. - 아래와 같은 대표적인 배포 방식들이 있으며, 이를 보다 편리하게 관리하기 위해 Controller라는 개념을 사용한다.

Job

Workload model에서 batch나 한번 실행되고 끝나는 형태의 작업이 있을 수 있다.

예를 들어 원타임으로 파일 변환 작업을 하거나, 또는 주기적으로 ETL 배치 작업을 하는 경우에는 웹서버 처럼 계속 Pod가 떠 있을 필요 없이 작업을 할 때만 Pod를 띄우면 된다.

이러한 형태의 workload model을 지원하는 Controller를 Job이라고 한다.

Restart policy 지정

만일, Job이 끝나기 전에 만약에 비정상적으로 종료된다면?
아래 그림과 같이 job에 적절한 restart policy를 부여할 수 있다.

Completions 횟수 및 parallelism 개수 지정

또한, spec에 completions 횟수를 지정하여, 하나의 작업을 여러 차례 수행하도록 할 수도 있다.(데이타가 클 경우 범위를 나눠서 작업하는 경우 등)

만일 parallelism 개수와 함께 적용한다면, parallelism 개수만큼 동시에 실행되며, completions 횟수만큼 모두 수행되면 종료될 것이다.

Cron Job

특정 날짜/시간마다 주기적으로 실행되어야 하는 작업일 경우, unix cron에 설정하듯이 설정하면 된다.
개념 및 방식 또한 unix cron과 같다.

Daemon Set

DaemonSet (이하 DS) 은 Pod가 각각의 노드에서 하나씩만 돌게 하는 형태로 Pod를 관리하는 컨트롤러이다.

아래 그림과 같이, RC나 RS에 의해서 관리되는 Pod 는 여러 노드의 상황에 따라서 일반적으로 비균등적으로 배포가 되지만, DS에 의해 관리되는 Pod는 모든 노드에 균등하게 하나씩만 배포 된다.
이런 형태의 워크로드는 서버의 모니터링이나 로그 수집 용도로 많이 사용된다.

또한, node selector(label)를 지정하여, 특정 노드에만 하나씩 배포할 수도 있다.
예를 들어 아래 그림과 같이 GPU를 포함하고 있는 서버에만 배포할 수 있다.

Stateful Set

RS/RC나 다른 controller로는 DB와 같이 상태를 가지는 애플리케이션을 관리하기가 어렵다.

그래서 이렇게 DB등과 같이 상태를 가지고 있는 Pod를 지원하기 위해서 Stateful Set 이라는 것이 새로 소개되었는데, 이를 이해하기 위해서는 K8s의 디스크 볼륨에 대한 이해가 필요하다.

Stateful Set은 다음 중 하나 또는 이상이 필요한 애플리케이션에 유용하다.

안정된, 고유한 네트워크 식별자.
안정된, 지속성을 갖는 스토리지.
순차적인, 정상 배포(graceful deployment)와 스케일링.
순차적인, 자동 롤링 업데이트.

Replication controller or Replica Set

Replica Set의 목적은 Replica Pod집합의 실행을 항상 안정적으로 유지하는 것이다. 이처럼 Replica Set은 보통 명시된 동일 Pod 개수에 대한 가용성을 보증하는데 사용한다.

Replica Set은 Replication Controller 의 새 버전으로 생각하면 된다.

큰 차이는 없고 Replication Controller 는 Equality 기반 Selector를 이용하는데 반해, Replica Set은 Set 기반의 Selector를 이용한다.

크게 3가지 파트로 구성되는데, Replica의 수, Pod Selector, Pod Template 3가지로 구성된다.

Selector : 먼저 Pod selector는 라벨을 기반으로 하여, RC가 관리한 Pod를 가지고 오는데 사용한다.
Replica 수 : RC에 의해서 관리되는 Pod의 수인데, 그 숫자만큼 Pod 의 수를 유지하도록 한다.예를 들어 replica 수가 3이면, 3개의 Pod만 띄우도록 하고, 이보다 Pod가 모자르면 새로운 Pod를 띄우고, 이보다 숫자가 많으면 남는 Pod를 삭제한다.
Pod를 추가로 기동할 때 그러면 어떻게 Pod를 만들지 Pod에 대한 정보 (도커 이미지, 포트,라벨등)에 대한 정보가 필요한데, 이는 Pod template이라는 부분에 정의 한다.

Deployment

실제 환경에서는 replica 수만 유지하는 것만 필요한 것이 아니라, 배포 방식 및 업데이트 방식과 함께 정책을 정하고 이를 반영해야 한다. 이를 위해 Deployment라는 선언적/추상적 상위 개념이 존재한다.

따라서, 사용자 지정 오케스트레이션이 필요하거나 업데이트가 전혀 필요하지 않은 경우라면 Replica Set을 직접적으로 사용하기 보다는 Deployment를 사용하는 것을 권장한다.

Blue/Green 배포 방식

가장 단순한 업데이트 배포 방식으로, 블루(예전)버전으로 서비스 하고 있던 시스템을 그린(새로운)버전을 배포한 후, 트래픽을 블루에서 그린으로 한번에 돌리는 방식이다.

위 그림에서 보는 바와 같이 이 방식을 사용하기 위해서는 일시적으로 나마 시스템 리소스가 (대략) 2배가 필요하다.
즉, 항상 업데이트 할 수 있는 정도의 여유 Stage가 필요하다.

Rolling update

가장 많이 사용되는 배포 방식 중의 하나 이며, 단순화된 과정은 다음 그림과 같다.
(아래 예에서는 RC를 사용하였으나, RS(Replica Set)으로 대체해도 무관하다, 최근에는 RS가 대세로 사용된다.)
먼저 RC를 하나 만들어서 기존 RC에서 replica 수를 하나 줄이고, 새로운 RC에는 replica 수를 하나만 준다.

기존 RC에서 replica 수를 또 하나 줄이고, 새로운 RC에는 replica 수를 하나 더 추가해준다.

마찬가지 작업을 반복하게 되면, 아래 그림과 같이 예전 버전의 Pod가 모두 빠지고 새 버전의 Pod만 서비스 되게 된다.

만약에 배포가 잘못되었을 경우에는 기존 RC의 replica 수를 원래대로 올리고, 새 버전의 replica 수를 0으로 만들어서 예전 버전의 Pods로 Rollback이 가능하다.

Deployment controller

여러가지 배포 방식을 RC나 RS를 이용해서 구현할 수 있지만, 운영이 복잡해지는 단점이 있다. 그래서 쿠k8s에서는 일반적으로 RC나 RS를 이용해서 배포하지 않고 Deployment라는 개념을 사용한다.

앞에서 보았듯이 rolling update 등을 할 때, RC를 두 개를 만들어야 하고, 하나씩 Pod의 수를 수동으로 조정해야 하기 때문에, 이를 자동화해서 추상화한 개념이 Deployment 이다.

위 rolling update에서의 과정을 아래 그림과 같이 Deployment controller가 대신하여 자동으로 관리해 준다.

위에서 각 RC[S]와 Pod들, 서비스들, deployment들 간의 연결 구조 즉, 포함 관계는 label 및 seletor라는 개념으로 서로 간에 매핑한다.

이들 label은 각 yaml spec에 정의하도록 되어 있다.
이에 대해서는 실제 예제를 다룰 때 설명하도록 한다.