데이터센터프로그래밍20(1)

20-Kubernetes Objects & Kubectl Commands (이론)

🐶 지난시간에 배운 내용

• Controller?
  : 쿠버네티스가 제공하는 좋은 기능으로, replicaset을 제어하는 Replica Control을 살펴보았다.
  : Ip address를 가지고 pods를 제어하기 어려운 이유
• Labels & Selectors?
  : yaml 파일을 만들 때, Labels or Selectors라는 이름으로 기입을 했고, 관심있는 것들을 grouping하는 역할을 함
  : yaml 파일에 Labels or Selectors을 쓴 후, 쿠버컨트롤(kubectl)로 interactive하게 쿠버네티스에서 제어를 할 때, Labels or Selectors를 주고, 이에 대한 정보 확인이 가능하다.

🔴 오늘 공부할 내용

• 쿠버네티스의 objects가 무엇인지?
• Spec & Status
• kubectl commands

🔴 Kubernetes objects?

• Presistent entities in the cluster
  : pods
  : namespaces
  : replication controller (manages pods)
  : deployment controller (manages pods)
  : statefulsets
  : daemonsets
  : services
  : configmaps
  : volumes

🔴 Record if Intent

• 쿠버네티스에서 다루는 공통적인 objects 특성은 desired state를 요청하면, 이것을 만들고 요청한다.
• desired state를 기술하기 위해서 주로 yaml 파일을 사용한다.
• yaml 파일에는 common한 meta-data가 있다 (objects의 종류에 따라서 반드시 사용해야 하는 것과 부가적으로 사용해야 하는 것이 있다).
  : meta-data 기반의 yaml 파일로 desired state를 기술하면, objects는 yaml 파일에 요청한 것을 필요시에 생성 & 모니터링 & 유지 및 관리 & 업데이트 & 살리기 및 죽이기 등의 작업을 수행하는 것이 일반적인 objects의 형태이다.

🔴 Why kubernetes objects?

• cluster 안에서 objects를 만들거나, 기존의 objects에게 일을 줄 때, 어플리케이션이 컨테이너based로 살아나서 동작을 하기 위한 것들을 의미한다.
• 필요한 resources 주고, 작업을 수행한다.

🔴 Why kubernetes API?

• 쿠버네티스 objects와 대화하는 방법은 2가지가 있다.
  (1) CLI로 필요한 것을 바로 요청하는 것이다.
  : kubectl의 명령어는 command-line interface를 통해서 사용했다.
  : command-line interface를 주로 대부분 yaml 파일을 만들어서 실행한 후에 사용한다 (yaml 파일을 사용하는 것은 default).
  (2) API
  : CLI와 동일하며, CLI를 통해서 할 수 있는 것은 쿠버네티스 objects에 대한 생성, 삭제 등을 하듯이, 동일한 작업을 API를 통해서 할 수 있다.
  🐶 kubernetes API? SW 버전을 변경 등 다양한 일을 개발자 or 운영자가 CLI로 메뉴얼하게 할 수 있지만, 프로그램을 짜서 할 수도 있는 것을 의미한다.

🔴 Nested Object Fields

• Object에 의해서 spec, status를 사용한다.
• (1) spec
  : yaml 파일에 자신이 하고자 하는 objects에 대한 desired state를 사용했다.
  : 쿠버네티스는 desired state를 만들고, 유지한다.
  : desired state에는 원하는 환경에 대한 부분에 대해 기록을 한다.
• (2) status
  : pods, get all을 통해서 실제로 쿠버네티스가 서비스를 하고 있는 것을 모니터링 할 수 있다 (objects의 실제상태).
  : 쿠버네티스 시스템의 업데이트
  : 실제 동작하고 있는 상태에서 label 이라든지, 기타 등등을 줌으로써, 변하는 것만 추출하는 것도 가능했다 (desired state가 match 되는 것에 대해서만 우리가 관리할 수 있다).

🔴 Use Cases of Spec & Status (1)

• Deployment
  : cluster 안에서 어플리케이션이 실행되는 것을 표현한다.
  🐶 replicaset의 목적은 주어진 시간에 안정적인 replica pods에 집합을 관리하는 것이다. 지정한 개수의 pods를 유지하는 것이다.
  🐶 replicaset의 대안
  : Deployment (recommended)는 replicaset을 가지고 있는 Object이다. 또한, :Deployment는 replicaset의 상위 개념이면서, replicaset 자체를 업데이트 할 수 있고, replicaset에 들어있는 pods를 업데이트 할 수 있고, rolling update를 할 수 있다.
  🐶 replicaset vs Deployment
• n개의 pods를 유지하는 것이라면, Deployment는 replicaset의 기능을 포함해서 실제로 서비스를 운영할 때, 업데이트 or rolling & 버전 up 등 다양한 기능을 포괄적으로 가지고 있다.
  🐶 replicaset은 "Use Cases"가 없는데, Deployment는 "Use Cases"가 있다 (즉, 다양한 기능을 가지고 있음을 의미한다).
• Deployment를 가지고 서비스를 생성한다는 것은 replicaset으로 어플리케이션 실행, n개 개수 유지 되는 것도 포함된다.

🔴 Use Cases of Spec & Status (2)

• Deployment는 replicaset의 상위개념이기 때문에 replicaset을 포함하고 있다.
  ex : 서비스가 죽었다면, Deployment도 확인 후 새로운 active한 instance를 만들어내는 행위들

🔴 Describing a kubernetes object

• 주로 yaml 파일(desired state)을 만들어서 쿠버네티스에게 요청한다.
• 필요시, 쿠버네티스 API를 통해서 동적으로 상황을 모니터링 한다.
• yaml 파일 (infrastructure as code)로 하는 것이 기본이다.
• 주로 json 형태를 사용한다.

🔴 ReplicaSet to Deployment

• apiVersion
  : 쿠버네티스 apiVersion을 포함한 것이다.
• kind
  : 쿠버네티스의 objects의 종류
• Metadata
  : 변경 가능