쿠버네티스 기본 개념

 

 

 

핫한 기술인 컨테이너부터 시작해서 쿠버네티스까지 학습해보자

 

---

 

 

노드, Node

Pod가 동작하는 곳
Pod 는 항상 노드 위에서 작동한다.
컨테이너 런타임(도커와 같은)은 레지스트리에서 컨테이너 이미지를 가져와 묶여 있는 것을 풀고 애플리케이션을 동작시키는 책임을 맡는다.

 

쿠버네티스에서 노드란 워커머신을 말하며 클러스터에 따라 가상 또는 물리 머신이 된다. 

=> 물리적 단위, 논리적 단위 둘 다 된다는 뜻.
=> 하나의 노드는 여러 개의 Pod를 가질 수 있음.
=> 쿠버네티스 컨트롤 플레인은 클러스터 내 노드를 통해서 Pod에 대한 스케줄링을 자동 처리함. 

 

** 다시 말하면 노드라는 인터페이스를 통해서 Pod 에 접근(외부에 IP 노출)

 

 

Kubelet이란?

쿠버네티스 컨트롤 플레인과 노드 간 통신을 책임지는 프로세스로

하나의 머신 상에서 동작하는 파드와 컨테이너를 관리한다.
=> Node를 조절하는 process

 

CLI에서 항상 붙는 명령 접두어다.

Deployment란?

배포란 뜻을 가짐.

Deployment를 할 때 해당 배포는 컨테이너 내부에서 컨테이너와 함께 파드를 생성함.
각 파드는 스케쥴 되어진 노드에게 묶여지게 된다.

 그리고 (재구동 정책에 따라) 소멸되거나 삭제되기 전까지 그 노드에 유지된다.
 노드에 실패가 발생할 경우, 클러스터 내에 가용한 다른 노드들을 대상으로 스케줄링되어 진다.

 

트래픽이 증가하면, 사용자 요청에 맞추어 애플리케이션의 규모를 조정할 필요가 있다.
디플로이먼트의 복제 수를 변경하면 스케일링이 수행된다

디플로이먼트를 스케일 아웃하면 신규 파드가 생성되어서 가용한 자원이 있는 노드에 스케줄된다.
 스케일링 기능은 새로 의도한 상태(desired state)까지 파드의 수를 늘린다.


** 중요사항
애플리케이션의 인스턴스를 복수로 구동하게 되면 트래픽을 해당 인스턴스 모두에 분산시킬 방법이 필요해진다.
서비스는 노출된 디플로이먼트의 모든 파드에 네트워크 트래픽을 분산시켜줄 통합된 로드밸런서를 갖는다. 
서비스는 엔드포인트를 이용해서 구동중인 파드를 지속적으로 모니터링함으로써 가용한 파드에만 트래픽이 전달되도록 해준다.




참고사항
 0까지 스케일링하는 것도 가능하다. 이 경우 해당 디플로이먼트의 모든 파드가 종료된다.



Deployment 가 뜻하는 바
Terminal 에서의 Deployment

NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
kubernetes-bootcamp   1/1     1            1           11m

- NAME lists the names of the Deployments in the cluster.
- READY shows the ratio of CURRENT/DESIRED replicas
- UP-TO-DATE displays the number of replicas that have been updated to achieve the desired state.
- AVAILABLE displays how many replicas of the application are available to your users.
- AGE displays the amount of time that the application has been running.

 

 

 

ReplicaSet은 Deployment에 의해 생성됨 => 늘어날 수 있고 줄어들 수 있음.

이렇게 만들어지는 Pod들은 Exposed IP에 대해 접근하게 될 때 요청마다 각각 다른 Pods에게 접근해서 서비스를 제공받음.

ReplicaSet이 뜻하는 바

NAME                            DESIRED   CURRENT   READY   AGE
kubernetes-bootcamp-fb5c67579   1         1         1       91s


- DESIRED displays the desired number of replicas of the application, which you define when you create the Deployment. This is the desired state.
- CURRENT displays how many replicas are currently running.


**ReplicaSet의 이름 형식은 정해져있음 EX) [DEPLOYMENT-NAME]-[RANDOM-STRING] => "kubernetes"-"bootcamp"-"fb5c67579"

참고 사항
Random String은 Seed 값에 의해 결정(pod-template-hash as a seed.)

롤링 업데이트란?

파드 인스턴스를 점진적으로 새로운 것으로 업데이트하여 

디플로이먼트 업데이트가 서비스 중단 없이 이루어질 수 있도록 해준다. 

새로운 파드는 가용한 자원을 보유한 노드로 스케줄될 것이다.
=> 서비스를 제공하면서도 업데이트를 할 수 있는 것 => 배포하면서도 빌드가 된다는 말과 같은듯?

 

 

proxy access란?

...

 

 

Pod란??

running inside Kubernetes are running on a private, isolated network.
By default they are visible from other pods and services within the same kubernetes cluster, but not outside that network.

파드는 하나 또는 그 이상의 어플리케이션 컨테이너(도커)들의 그룹을 나타냄

 => 일부는 컨테이너에 대한 자원을 공유함.

**자원이란 여기서 공유 storage, 클러스터 IP와 같은 네트워킹, 컨테이너 Image version, 사용할 특정 포트 등

쿠버네티스 상에서 최소 단위.


**참고 

쿠버네티스 파드들 은 언젠가는 죽게된다.
 실제 파드들은 생명주기를 갖는다.
 워커 노드가 죽으면, 노드 상에서 동작하는 파드들 또한 종료된다.

 레플리카셋(ReplicaSet)은 애플리케이션이 지속적으로 동작할 수 있도록 새로운 파드들의 생성을 통해 동적으로 클러스터를 미리 지정해 둔 상태로 되돌려 줄 수도 있다.
=> 파드가 죽어도 어플리케이션이 계속 실행될 수 있는 이유

파드가 재성성 시 알아야 할 점
그 복제본들은 교체 가능한 상태이다.

그래서 프론트엔드 시스템은 하나의 파드가 소멸되어 재생성이 되더라도, 백엔드 복제본들에 의한 영향을 받아서는 안된다.

 즉, 동일 노드 상의 파드들이라 할지라도, 쿠버네티스 클러스터 내 각 파드는 유일한 IP 주소를 가지며, 여러분의 애플리케이션들이 지속적으로 기능할 수 있도록 파드들 속에서 발생하는 변화에 대해 자동으로 조정해 줄 방법이 있어야 한다.
=> 다시 말해서 대체 되는 파드는 파괴된 파드에 대한 정보를 동기시켜야 한다는 말이다.
=> 여기서 동기는 같은 상태를 말한다.



파드의 IP가 외부로 노출되어질 수 있는 방법 (정답 : 서비스)

비록 각 파드들이 고유의 IP를 갖고 있기는 하지만, 그 IP들은 서비스의 도움없이 클러스터 외부로 노출되어질 수 없다.

서비스들은 애플리케이션들에게 트래픽이 실릴 수 있도록 허용해준다. 
서비스들은 ServiceSpec에서 type을 지정함으로써 다양한 방식들로 노출시킬 수 있다:

대표적인 4가지 (ClusterIP, NodePort, LoadBalancer, ExternalName) 등이 있음

 

쿠버네티스에서 서비스

(1)하나의 논리적인 파드 셋과 (2)그 파드들에 접근할 수 있는 정책을 정의하는 추상적 개념이다.
서비스는 종속적인 파드들 사이를 느슨하게 결합되도록 해준다.
=> 느슨하다.
서비스는 모든 쿠버네티스 오브젝트들과 같이 YAML (보다 선호하는) 또는 JSON을 이용하여 정의된다. 

서비스는 파드 셋에 걸쳐서 트래픽을 라우트한다.
애플리케이션에 영향을 주지 않으면서 쿠버네티스에서 파드들이 죽게도 하고, 복제가 되게도 해주는 추상적 개념이다.
종속적인 파드들 사이에서의 디스커버리와 라우팅은 (하나의 애플리케이션에서 프로트엔드와 백엔드 컴포넌트와 같은) 쿠버네티스 서비스들에 의해 처리된다.

서비스는 쿠버네티스의 객체들에 대해 논리 연산을 허용해주는 기본 그룹핑 단위인, ""레이블""과 ""셀렉터""를 이용하여 파드 셋과 매치시킨다. 
레이블은 오브젝트들에 붙여진 키/밸류 쌍으로 다양한 방식으로 이용 가능하다:


** 디스커버리??


참고
서비스가 대상으로 하는 파드 셋은 보통 LabelSelector에 의해 결정된다

 

 

쿠버네티스란 무엇인가?

컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성 + 확장성 플랫폼
(컨테이너 오케스트레이션 툴)


**컨테이너 오케스트레이션 : 컨테이너의 배포, 관리, 확장, 네트워킹을 자동화.
수백, 수천개의 컨테이너와 호스트를 배포에 도움을 줌.

**워크로드 : 쿠버네티스에서 구동되는 어플리케이션을 뜻함.
워크로드가 단일 컴포넌트이거나 함께 작동하는 여러 컴포넌트이든 관계없이, 쿠버네티스에서는 워크로드를 일련의 파드 집합 내에서 실행한다.

**워크로드 리소스: 파드 집합을 관리하는 워크로드 리소스, 이러한 리소스는 지정한 상태와 일치하도록 올바른 수의 올바른 파드 유형이 실행되고 있는지 확인하는 컨트롤러를 구성한다.



프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야 한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야 한다.
 

이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까?
그것이 쿠버네티스가 필요한 이유이다!

쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 
애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다.

 

 

HPA, Horizontal Pod Autoscaling

 

HPA가 작동 기제

쿠버네티스는 HPA를 간헐적으로 실행되는 컨트롤 루프 형태로 구현함

실행 주기 : kube-controller-manager의 --horizontal-pod-autoscaler-sync-period 파라미터에 의해 설정된다

(기본 주기는 15초이다).


1. 실행주기마다 지정된 Metric에 대해 Resource Usage를 Querying하면
2. Controller Manager가 scaleTargetRef을 이용해서 Target Resource를 찾는다.
3. Target Resource의 .spec.selector Label을 탐색하여 Pod를 선택함
4. Resource Metric API or Customized Metric API로 Metric을 수집함.
5. API를 통해 가져온 Metric을 가져옴
6. 목표 사용률 값(Target Usage ratio)이 설정되면 Controller가 각 Pod의 컨테이너에 대한 동등한 자원 요청을 Percentage 단위로 하여 사용률 값을 계산한다.
7. 대상 원시 값이 설정된 경우 원시 메트릭 값이 직접 사용된다.
8. Controller는 모든 대상 Pod에서 사용된 사용률의 평균 또는 원시 값을 가져와서 원하는 레플리카의 개수를 스케일하는데 사용되는 비율을 생성한다.

예외 : Pod의 컨테이너 중 일부라도 적절한 리소스 요청이 설정되지 않는다면
Pod의 CPU 사용률이 정의되지 않고 AutoScale이 되지 않는다.


HPA Controller는 스케일링을 지원하는 워크로드 리소스에 접근한다.
이들 각각은 Scale이라는 하위 리소스를 가지고 있다.
하위 리소스는 레플리카의 수를 동적으로 설정하고 각각의 현재의 상태를 확인할 수 있는 Interface이다.

워크로드 스케일링의 안정성

HPA를 이용해서 레플리카 그룹의 크기를 관리하면
측정하는 Metric에 따라 레플리카 수가 크게 요동칠 수 있다.
=> Flapping,  Thrashing이 발생했을 때, 어떻게 해야할 지를 고민해야할 듯 하다.

 

롤링 업데이트 중 오토스케일링

쿠버네티스는 디플로이먼트에 대한 롤링 업데이트를 지원한다.
 이 경우, 디플로이먼트가 기저 레플리카셋을 알아서 관리한다. 

디플로이먼트에 오토스케일링을 설정하려면, 각 디플로이먼트에 대한 HorizontalPodAutoscaler를 생성한다.

 HorizontalPodAutoscaler는 디플로이먼트의 replicas 필드를 관리한다. 
디플로이먼트 컨트롤러는 기저 레플리카셋에 replicas 값을 적용하여 롤아웃 과정 중/이후에 적절한 숫자까지 늘어나도록 한다.

오토스케일된 레플리카가 있는 스테이트풀셋의 롤링 업데이트를 수행하면, 스테이트풀셋이 직접 파드의 숫자를 관리한다(즉, 레플리카셋과 같은 중간 리소스가 없다).

 

 

 

클러스터란?

컨트롤 플레인 및 하나 이상의 컴퓨팅 머신 또는 노드