Kubernetes Deep Dive - (1). 구성요소

Why Kubernetes

• Docker Container의 Orchestration Tool
• 컨테이너화된 애플리케이션을 배포하는 등, manage 작업을 자동화할 수 있는 오픈소스 도구

• 주어진 제약조건에 맞게 컨테이너를 클러스터 노드에 배포하는 것
• Health Check + Healing. 특정 노드에 문제가 있을 경우 자동으로 조치
• rolling updates / rollbacks. 서비스 downtime 없이 배포가 가능하며, 문제 있을 경우 롤백도 용이함

• storage 시스템을 붙이기도 편리하며
• Secret 관리도 지원함.

Architecture of Kubernetes

기본적으로는 Master - Slave 아키텍처.

• Master Node: Cluster Management의 핵심이자, admin 관련 작업이 필요할 때 접근해야 할 리소스.

• 사용자는 CLI, API 또는 kubernetes에서 제공하는 dashboard UI로 Master Node에 접근 가능하다.
• Master Node 내부에는 여러 컴포넌트가 포함되어 있고, 얘네를 합쳐서 'Control Plane' 이라고 부른다.
  • Kube Controller, kube API server, kube scheduler, kube key-value store (etcd)가 보통 포함됨.
  • 이 Master Node가 worker Node에 접근한다.
• Worker Node에는 kube proxy, Pods, Kubelet 등이 존재함.

Master Node를 좀 더 뜯어보면

1. API Server: Cluster 컨트롤을 위한 모든 명령어의 EntryPoint. Kubernetes와의 Interaction Point이기도 하다.

2. ETCD: 클러스터의 상태를 저장하기 위한 distributed Key-Value Store. Kubernetes의 백엔드 개념이며, 여기에 저장된 state를 토대로 recover 등의 작업을 수행한다.
   • Production Level의 경우, 이 백엔드 DB를 externalize해서 안정성을 높일 수 있음. (마스터 노드 자체가 죽으면, etcd 데이터도 같이 날라가기 때문.)

3. Scheduler: slave Node의 작업을 관장함. 각 slave node의 리소스 사용량을 저장하고 있음. 이 정보를 토대로 특정 작업이 할당됐을 때 적절한 slave node에 배분할 수 있다.

4. Controller (kube Controller Manager): 자동화되어 있는 수많은 작업을 싱글 프로세스가 작업할 수 있도록 만든 컴포넌트.

Worker Node

• Cluster가 관리하는 서버 (VM / Physical Machine)
• 컨테이너 간 통신을 위한 Networking, 리소스가 필요한 컨테이너에게 리소스 할당, 마스터 노드와의 통신 등을 담당한다.
  • 즉, manage the containers / manage the resources 둘 다 가능함.

• Kubelet: worker node에 있는 k8s Agent.
  • 마스터 노드의 api-server 컴포넌트와 통신하고, worker node의 state를 관리하는 역할.
  • 필요한 Service의 종류는 뭔지, Config 구성은 어떠한지 api server에게서 받아 worker node에서 실행한다.

Pod

• storage / network를 공유하는 컨테이너(들)의 집합. 반드시 동일한 컨테이너의 집합일 필요는 없다.
• 하나의 pod 안에서 작동하는 containers -> similar Configuration이어야 함.
  • Separate Config이 필요하면 별도의 pod으로 구성하고 관리하는 게 맞다.

하나의 pod에 있는 컨테이너들은 IP를 공유한다. 즉, IP는 개별 컨테이너와는 아무 상관이 없어진다.
pod 내부의 컨테이너끼리는 Localhost로 통신한다.

cf. 보통 95% 정도의 pod는 single container + Single Port라고 한다. 즉 사실상 IP와 개벌 컨테이너는 일대일 관계일 가능성이 높은 편.

Kube-Proxy

• Individual host Sub-netting. + Pod에 올라간 서비스 (Container)가 외부에서 사용될 수 있도록 하는 역할.

Namespaces

• 논리 단위로 클러스터를 분리하는 Virtual Cluster라고 생각하면 됨. k8s Objects는 namespace를 기반으로 logically 분리되어 있다.

Installation

설치 방법은 크게 두 가지.

• Hight Avaliability Deployment. (1 Master - 2 Worker) 형태로, Production 레벨에서 적절함
• Single Node Deployment (MiniKube K8s Cluster). Minikube를 사용해서 k8s 실행하는 식으로, Development 환경에 적절함.