쿠버네티스란 무엇인가?

https://kubernetes.io/ko/docs/concepts/overview/what-is-kubernetes/

쿠버네티스란 무엇인가?

https://www.redhat.com/ko/topics/containers/what-is-kubernetes

쿠버네티스(Kubernetes) 개‭념,  사‭용 방‭법,  차‭이‭점

 

쿠버네티스란 무엇인가요?

쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다.
쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다고 한다.

쿠버네티스 필요성 및 제공 기능

컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 쿠퍼네티스는 전통적인 어플리케이션 배포 방식에서 컨테이너 기반의 배포 방식으로 변경되는 시대의 흐름에 부합하는 기능을 제공하고 있다.

쿠버네티스 제공 기능은 다음과 같다.

• 서비스 디스커버리와 로드 밸런싱
  쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다. 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다.
• 스토리지 오케스트레이션
  쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재 할 수 있다.
• 자동화된 롤아웃과 롤백
  쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다. 예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다.
• 자동화된 빈 패킹(bin packing)
  컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 지시한다. 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해준다.
• 자동화된 복구(self-healing)
  쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
• 시크릿과 구성 관리
  쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.

쿠버네티스가 아닌 것

쿠버네티스는 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱과 같은 기능을 제공하며, 사용자가 로깅, 모니터링 및 알림 솔루션을 통합할 수 있다. 하지만, 쿠버네티스는 모놀리식(monolithic)이 아니어서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다.

• 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(stateless) 워크로드, 상태 유지가 필요한(stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작할 것이다.
• 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합과 전달과 배포, 곧 CI/CD 워크플로우는 조직 문화와 취향에 따를 뿐만 아니라 기술적인 요구사항으로 결정된다.
• 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, MySQL), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 Open Service Broker 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다.
• 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다.
• 기본 설정 언어/시스템(예, Jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
• 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다.
• 추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도한 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.

 

쿠버네티스 컴포넌트

쿠버네티스를 구성(배포)하면 클러스터가 생성된다.

 

K8S Cluster는 container 를 실행하는 Node 라고 하는 워커 머신의 집합이며, 모든 클러스터는 최소 한개 이상의 워커 노드를 포함한다.

Node : 가상 또는 물리적 머신으로, kubelet, container runtime, kube-proxy 를 포함한다.

Pod : 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다. pod(pod of whales)는 하나 이상의 컨테이너 그룹으로 스토리지 및 네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다.
각 파드는 특정 애플리케이션의 단일 인스턴스를 실행하기 위한 것이다. 더 많은 인스턴스를 실행하여 더 많은 전체 리소스를 제공하기 위해 애플리케이션을 수평적으로 확장하려면, 각 인스턴스에 하나씩, 여러 파드를 사용해야 한다. 쿠버네티스에서는 이를 일반적으로 레플리케이션이라고 한다.

워커 노드는 Pod를 호스팅한다. Control Plane은 워커 노드와 클러스터 내 Pod를 관리한다. Production 환경에서는 Control Plane은 보통 여러 컴퓨터에서 실행되며 Cluster는 통상 여러 Node를 실행하기 대문에 내결함성 및 고가용성이 제공된다.

 

Control Plane Component

control plane component 는 cluster에 대한 전반적인 행위를 수행하고, 클러스터 이벤트를 감지하고 처리한다. 예를 들면 deployment의 replicas 필드의 요구 조건이 충족되지 않을 경우 새로운 pod를 구동시키는 행위등을 한다.

 

control plane component 는 cluster 내 어떤 머신에서도 동작할 수 있다.

 

Kube-apiserver

kubernetes API를 노출하는 control plane component이며, k8s control plane의 프론트엔드이다.

 

etcd

cluster의 모든 데이터를 담는 k8s의 저장소로 일관성/고가용성을 제공하는 key-value store이다. 

 

kube-scheduler

Node가 배정되지 않은 새로 생성된 Pod를 감지하고 실행할 Node를 선택하는 Control Plane component

 

kube-controller-manager

Controller process를 실행하는 컴포넌트로, 다음을 포함한다.

• Node controller : 노드의 down 상태에 대한 notification 및 대응
• Replication controller : 명세에 작성된 내용에로 적절한 수의 pod 를 유지시킴
• endpoint controller : Service와 Pod를 연결
• Service Account & token controller : 새로운 네임스페이스에 대한 계정 및 API 접근 토큰 생성

cloud-controller-manager

cloud 별 컨트롤 로직을 포함하는 컴포넌트로, CSP가 제공하는 기능에 대한 의존성을 가지며, Node/Route/Service Controller 가 있다.

 

 

Node component

동작 중인 파드를 유지시키고 쿠버네티스 런타임 환경을 제공하며, 모든 노드 상에서 동작한다

kubelet

Cluster의 모든 Node에서 실행되는 agent로, Pod에서 Container 가 동작하도록 관리한다.

(kubernetes를 통해 생성되지 않은 container는 관리 대상이 아니다)

kube-proxy

Cluster의 각 Node에서 실행되는 Network Proxy로 쿠버네티스의 Service 개념의 구현부이다. Node의 네트워크 규칙을 유지/관리하고, 이 규칙을 통해 내부 네트워크 세션이나 클러스터 바깥에서 Pod로의 네트워크 통신을 가능하게 한다.

Container runtime

Container의 실행을 담당하는 Software로, containerd 등의 컨테이너 런타임을 지칭한다.

 

 

Addons

Kubernetes Resoiurces(daemon set, deployment 등)를 이용하여 cluster 기능을 구현한다. Addons은 Cluster 단위의 기능을 제공하기 때문에 이에 대한 namespace resources 는 kube-system 네임스페이스에 속한다.

DNS

DNS record를 제공하는 DNS 서버로 기본 구성이다.

web UI(대시보드)

쿠버네티스 클러스터를 위한 범용의 웹 기반 UI

container resource monitoring

컨테이너들의 시계열 매트릭 기록 및 모니터링을 위한 UI 제공

cluster-level logging

검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장