[Cloude Navtive Devops with Kubernetes] 4. 쿠버네티스 오트젝트 다루기

Pod

Deployment

Service

 

4.1 Deployment

 4.1.1 관리와 스케줄링

쿠버네티스는 각 프로그램을 관리하기 위해 Deployment Object를 생성.

Controller : Deployment resource를 관리.

실제로 Deployment는 Replica를 직접 관리하지 않는다. 대신, ReplicaSet이라는 Object를 자동으로 생성해서 처리하게 한다.

 

 4.1.2 Restarting Containers

Deployment는 재시작을 한다. 

컨테이너마다 재시작 정책을 다르게 설정할 수 있지만, 일반적으로 요구되는 사항은 '항상 재시작'이라 기본값으로 설정되어 있다. (default behavior : restart always)

 

 4.1.3 Querying Deployments

kubectl get deployments
kubectl describe deployments/demo

 

 

4.2 Pods

Pod : 하나 이상의 컨테이너 그룹으로 구성된 Kubernetes Object.

Deployment는 개별 컨테이너를 직접 관리하지 않는다. 

-> 왜? 컨테이너의 집합은 때때로 함께 스케줄링되고, 동일 노드에서 실행되며, 로컬로 통신하거나 저장 공간을 공유해야 하기 때문이다.

 

kubectl run명령이 실제로 Pod를 직접 생성하지는 않는다.

Deployment가 만들어지고 Deployment가 Pod를 실행한다. Deployment는 Pod의 상태를 선언한다.

 

4.3 ReplicaSets

Deployment는 Pod를 직접 관리하지 않고, 이는 ReplicaSet Object가 수행한다.

ReplicaSet은 동일한 Pod 집합이나 replica들을 관리한다.

 

4.4 Maintaining Desired State

Kubernetes controller는 각 리소스에서 지정한 '의도한 상태'를 클러스터이 실제 상태와 지속적으로 비교하고 동기화하기 위해 필요한 작업을 수행한다. 의도한 상태와 실제 상태를 일치시키기 위한 조정 작업이 영원히 반복되므로 이 과정을 reconciliation loop라고 한다.

 

4.5 The Kubernetes Scheduler

"Deployment will create Pods and Kubernetes will start the required Pod."

 

Kubernetes Scheduler는 이 과정을 책임지는 Component다. Scheduler의 역할은 대기열에서 스케줄링되지 않은 Pod를 찾아 배치하고 실행할 노드를 찾는 것이다. Pod가 노드에 스케줄링되면 노드에서 실행 중인 kubelet이 실제로 컨테이너를 실행한다.

 

4.6 Resource Manifests in YAML Format

Kubernetes는 근본적으로 선언형 시스템이기 때문에 실제 상태와 의도한 상태를 계속해서 조정해 맞춰나간다. 의도한 상태에서 Deployment 스펙만 수정하면 Kubernetes가 나머지 일을 모두 처리한다. 

 

 4.6.1 Resources Are Data

Kubernetes를 제어하기 위해서 kubectl run 명령어를 사용하지 않아도 된다. Resource Manifest(리소스에 대한 의도한 상태의 스펙)를 직접 생성하고 수정하면 된다. manifest 파일을 소스 제어에 보관하고 수정한 후 Kubernetes가 이를 반영하도록 요청하면 된다. 

 

 4.6.2 Deployment Manifests

Kubernetes Manifest 파일로 일반적으로 YAML 형식을 사용한다.

 

 4.6.3 Using kubectl apply

선언형 인프라 코드 시스템으로서의 쿠버네티스 기능을 충분히 잘 활용하려면 kubectl apply 명령어를 사용하여 YAML Manifest를 클러스터에 직접 전달해야 한다.

 

 4.6.4 Service Resources

Service Resource는 Pod에 자동으로 라우팅되는 영구적인 IP 주소와 DNS 주소를 제공한다. 

Kubernetes 서비스는 전통적인 Load Balancer와 유사하다.

Deployment는 Application의 Pod의 세트를 관리하고 서비스는 요청을 Pod에 전달하는 단일 엔트리 포인트를 제공한다.

 

 4.6.5 Querying the Cluster with kubectl

kubectl get : 클러스터에 존재하는 노드를 확인할 수 있다. (kubectl get nodes)

kubectl get all : 모든 타입의 리소스를 확인할 수 있다.

kubectl describe : 개별 Pod(또는 다른 리소스)에 대한 포괄적인 정보를 확인할 수 있다.

 

 4.6.6 Taking Resources to the Next Level

파일의 중복을 줄이고, 변수로 관리할 수 있도록 하는 도구 : Helm(헬름)

 

4.7 Helm : A Kubernetes Package Manager

helm 명령줄 도구를 사용하면 애플리케이션을 설치하고 설정할 수 있다. 

helm 차트라 불리는 패키지를 생성하면 애플리케이션을 실행하는 데 필요한 리소스, 의존성, 구성 가능한 변수를 지정할 수 있다.

Helm은 Cloud Native Computing Foundation(CNCF) 프로젝트의 일부로 만들어졌으며, 안정성과 개방성을 자랑한다.

 

 4.7.1 Installing Helm

 4.7.2 Installing a Helm Chart

 4.7.3 Charts, Repositories, and Releases

Chart : Kubernetes에서 애플리케이션을 실행하는 데 필요한 모든 리소스 정의를 포함한 헬름 패키지다.

Repository : Chart가 모여 있는 공유할 수 있는 공간이다.

Release : Kubernetes Cluster에서 실행되는 차트의 특정 인스턴스다. 고유한 이름을 가지며 helm install에 -name 플래그로 지정된다. 

 

 4.7.4 Listing Helm Releases

helm list

4.8 Summary

1. Pod는 Kubernetes의 기본 작업 단위로 스케줄링이 될 단일 컨테이너나 컨테이너의 그룹을 지정한다.
2. Deployment는 Pod를 선언적으로 관리하는 high-level Kubernetes resource다.
3. Service는 Kubernetes의 Load Balancer나 Proxy에 해당하며 IP주소나 DNS 이름을 통해 트래픽을 일치하는 Pod로 라우팅한다.
4. Kubernetes Scheduler는 노드에서 아직 실행되지 않는 Pod를 감시하고 적합한 노드를 찾은 다음 해당 노드의 kubelet이 Pod를 실행하도록 지시한다.
5. Deployment와 같은 리소스는 Kubernetes의 내부 데이터베이스에 레코드로 표시된다. 외부적으로 이러한 리소스는 YAML 형식의 텍스트 파일(Manifest)로 표현된다. Manifest는 리소스의 의도한 상태를 선언한다.
6. kubectl은 Kubernetes와 상호작용하기 위한 주요 도구로 Manifest를 적용하고 리소스를 조회, 변경, 삭제하는 등의 많은 작업을 수행할 수 있다.
7. Helm은 Kubernetes 패키지 매니저로 Kubernetes 애플리케이션을 쉽게 구성하고 배포할 수 있게 해준다. 직접 원시 YAML 파일을 관리할 필요 없이 하나의 값 세트나 템플릿의 세트를 사용하여 Kubernetes YAML 파일을 생성할 수 있게 해준다.