수업정리 6) Kubernetes in action

Pod

• 관련있는 하나 이상의 containers 집합
• depolyment(배포)의 basic unit이다.
• each pod는 자신만의 IP, hostname, process, newtork interface 및 다른 Resource를 가진다.

-> 위의 그림을 보면 하나의 worker node에 두 개 이상의 pod가 있을 수 있으며 각 pod마다 ip가 다름
-> 참고로, pod는 컨테이너의 실행단위이며, depolyment는 애플리케이션의 배포와 업데이트를 관리하는 쿠버네티스 리소스. depolyment를 사용하여 pod를 만들고 관리할 수 있음.

Behind the Scenes

• 1) 'kubectl' 명령을 사용하여 쿠버네티스에 depolyment를 생성하도록 지시한다. depolyment는 쿠버네티스에서 애플리케이션을 관리하는데 사용되는 리소스 객체이다.
• 2) 'kubectl'은 쿠버네티스 API에 depolyment를 생성하도록 요청한다.
• 3) kubernetes는 depolyment 객체를 기반으로 pod를 create한다. 각 pod에는 하나 이상의 container가 포함될 수 있다.
• 4) pod는 worker node에 할당된다.kubernetes master node는 pod를 실행할 적합한 worker node를 골라 pod에 할당한다.
• 5) 할당된 worker node의 kublet은 해당 node에서 pod를 실행하는 역할을 수행한다. kubelet은 docker 또는 다른 컨테이너 런타임을 사용하여 컨테이너 이미지를 다운로드하고 컨테이너를 실행한다.
• 6) application이 워커노드에 있는 container에서 실행된다.

Kubernetes를 쓰지 않고 workload를 depoly하려면?

모든 container와 node의 상태를 모니터링해야하고, missed call을 발생시킨 failed node를 잡아내야한다. 너무 귀찮은 작업..

Kubernetes principle #1

Kubernetes APIs are declarative rather than imperative.

• Decalrative(선언적)는 원하는 상태를 기술하면 시스템은 해당 상태를 달성하도록 노력함. 어떤 작업을 수행하는 명령을 내리는 것이 아니라 원하는 최종상태를 정의함. Automatic recovery를 하기 때문에 굉장히 편리하다!!!
• Imperative(명령적)은 어떤 작업을 단계별로 지시하며, 시스템에 직접 명령을 내린다.

따라서 Decalaritve Api인 쿠버네티스를 사용하기 전후 작업을 비교하면

• Before
  
  • you) desired state로 도달하기 위한 exact set of instruction을 제공한다.
  • system) instruction을 수행한다.
  • you) system을 모니터링하고 추가적인 instruction을 제공한다.
• After
  
  • you) desired state를 기술한다.
  • system) 해당 state로 가기 위해 work한다.

-> Master node가 모든 component를 monitor하고 filaed component를 잡아낸다.
-> Master node는 좀 복잡하고, 확장하기 쉽지 않다. (Kubernetes prinicple #2를 통해 극복되는 특징인듯)

Kubernetes principle #2

The Kubernetes control plane is transparent. There are no hidden internal APIs.

• Kubernetes Control Plane은 Kubernetes cluster의 중심 역할을 하는 곳으로, 클러스터의 상태를 관찰하고 리소스를 제어하는 역할을 하는 곳이다. master node에 위치한다.
• 이때 transparent 하다는 뜻은 내부 동작과 상태를 외부로 노출하지 않는다는 의미이다.
• 또한 외부에 숨겨진 내부 api를 사용하지 않으며 공개된 api를 통해 모든 조작과 통신이 이루어진다.

-> 즉, 쿠버네티스는 자신의 control plane을 투명하게 구성하고 공개된 api만 사용하여 cluster를 관리하기 때문에 굉장히 단순하다.
따라서 transparent한 control plane을 사용하는 쿠버네티스를 사용하기 전후 작업을 비교하면

• Before
  
  • Maseter) desired state로 도달하기 위한 exact set of instruction을 제공한다.
  • Node) instruction을 수행한다.
  • Master) system을 모니터링하고 추가적인 instruction을 제공한다.
• After
  
  • Master) desired state를 기술한다.
  • Node) 해당 state로 가기 위해 independently work한다.

-> 즉, 우리가 쿠버네티스에게 하는 방식과 똑같은 방식으로 Master가 Node에게 요청한다.

왜 hidden internel API가 없을까?

• decalaritive api는 외부에서와 마찬가지로 내부에도 같은 benefit을 준다.
  • -> 쿠버네티스는 component level triggered 방식을 사용하는데 이것은 컴포넌트가 원하는 상태를 지속적으로 유지하도록 노력하는 방식을 의미한다. 즉 컴포넌트가 특정 이벤트가 발생했을 때만 반응하는 대신, 지속적으로 원하는 상태를 유지하기 위해 노력한다. 이렇게 되면 missing event 문제가 발생하지 않는다.
• 결과적으로 더 simple하고 Robust하고 failure of component를 더 쉽게 회복할 수 있는 시스템이 만들어졌다.
• 또한 쿠버네티스를 자신의 필요에 맞게 조정하고 확장할 수 있다.
  • -> 디폴트 컴포넌트가 맞지 않는 경우 이를 비활성화 시키고 자체 component로 대체할 수 있으며
  • -> additional 기능을 작성하고 추가하는 것도 쉽게 가능하다.

Kubernetes principle #3

Meet the user where they are

쿠버네티스의 설계 철학 중 하나로, 사용자가 쿠버네티스를 설계할 때, 기존 애플리케이션과 환경을 가능한한 변경하지 않고 통합할 수 있게 하는 것이다.
 

• Before
  
  • 애플리케이션을 쿠버네티스에서 실행하려면 애플리케이션을 "Kubernetes-aware"하게 만들어야했다. 쿠버네티스 환경에 맞게 애플리케이션을 변경해야함을 의미한다.
• After
  
  • 쿠버네티스를 사용하는 애플리케이션을 변경하지 않고도, 쿠버네티스와 통합할 수 있게 하였다.
  • 애플리케이션이 config 또는 파일의 secrete data나 환경변수를 load하면 Modified될 필요 없다.

 

Remote Storage

pod definition에서 Remote volume을 directly하게 Reference할 수 있다. (AWS EVS, NFS 등..) 그럼 kubernetes가 자동으로 remote volume을 사용할 수 있게 해준다.

Kubernetes principle #4

Workload protability

-> 쿠버네티스가 여러 환경에서 Workload를 쉽게 이동하고 실행할 수 있다.
-> 쿠버네티스는 PCV/PV를 추상화한다. 

• PV(PersistentVolume): PV는 클러스터 내에서 사용 가능한 stoarge volume을 나타내는 kubernetes object이다. pv는 클러스터 관리자에 의해 설정된다. 여러 pod에서 공유되거나 단일 pod에서 독점적으로 사용될 수 있다.
• PVC(PersistentVolumeClaim): Pod에서 사용할 스토리지를 요청하는 kubernetes object이다. pvc는 클러스터 사용자나 개발자에 의해 생성된다. 필요한 stoarge 세부사항을 정의하며, PVC는 정의와 일치하는 PV를 찾아 할당받고 이를 Pod에 마운트하여 스토리지를 사용한다.

-> workload protability가 왜 중요할까?

• 어플리케이션 개발과 클러스터 구현을 분리하여, 개발자가 클러스터를 걱정하지 않고 애플리케이션을 개발할 수 있다.
• 쿠버네티스를 운영체제처럼 작동하는 진정한 추상화 layer로 만들어야하므로. 즉, 클러스터 구현의 복잡성을 숨기고, 클러스터를 전혀 걱정하지 않고 실행되도록 하는 추상화 레이어로 작동시켜야한다.

 

Introducing the Kubernetes API Objects

Kubernetes API

• http 기반의 RESTful API
• CRUD operations on resource using stanrad HTTP method
• Resource(or objects) represent the configuration of the cluster

Object Manifest

쿠버네티스 리소스나 객체를 정의하고 설명하는데 사용되는 구조이다. 각 구성요소는 다음과 같다.
1) Type MetaData -> object type, group, api 버전을 나타낸다.
2) Object Metadata -> object name, creation time(생성시간), owner, 다른 식별 정보 등..
3) Spec -> 원하는 오브젝트의 희망상태. ex) 예를 들어 Pod object의 경우, 원하는 컨테이너 이미지, 리소스 요구사항, 네트워크 설정등의 내용이 들어갈 수 있다. (그림에서 user가 작성하는건 spec)
4) Status -> 오브젝트의 현재 상태 ex) 예를 들어 Pod의 경우, 현재 실행 중인 컨테이너 및 상태 정보를 포함할 수 있다. (그림에서 user가 object로부터 읽어오는건 status)

Managing an Object

쿠버네티스에서 객체 관리는 컨트롤러라고 불리는 구성 요소에 의해 수행된다.

각 컨트롤러는 특정 유형의 객체(예: Pod, Deployment, Service)를 관리하며, 객체의 상태를 원하는 상태로 유지하려고 노력함.
컨트롤러는 객체의 "Spec" 섹션을 확인하여 원하는 상태를 파악하고, 필요한 작업을 수행하여 객체를 원하는 상태로 유지한다. 그리고 컨트롤러는 객체의 "Status" 섹션을 업데이트하여 현재 상태를 기록하고 모니터링한다.
이런 방식으로 쿠버네티스는 객체를 자동으로 관리하고 유지한다.

 

<전체 요약. 쿠버네티스의 주요 구성요소와 설명>

* Computing building block - Pod ) Pod는 쿠버네티스에서 실행된느 컨테이너화된 애플리케이션의 최소단위이다.
* Communication building block- Service
* Grouping: Labels and Annotation
* Configuration: ConfigMap and Secrets ) CofigMap은 애플리케이션 설정 정보를 저장하는데 사용되며, Secretes는 민감한 데이터를 안전하게 저장하는데 사용된다.
* Application updates: Depolyment ) Depolyment는 롤링 업데이트, 롤백, 스케일링, 버전 관리 등을 지원한다.
* Storage building block: PersistentVolumeClaim on top of PersistentVolume ) PersistentVolumeClaim은 스토리지 요청을 의미하며, PersistentVolume은 실제 스토리지 자원을 나타낸다. 이 두 요소를 사용해 Pod에 스토리지를 동적으로 할당하고 관리한다.