[K8S] 쿠버네티스 개념 및 Architecture

 

쿠버네티스 공식 문서 : https://kubernetes.io/ko/docs/home/

쿠버네티스 문서

 

K8S가 필요한 이유?

The purpose of Kubernetes is to host your applications in the form of containers in an automated fashion so that you can easily deploy as many instances of your application.

1. 수많은 마이크로서비스를 여러 서버에 효율적으로 배치하는 것이 어렵다.
2. 여러 서버와 마이크로서비스 배포 조합 수를 사람이 계산하기 어려운데, 이때 충분한 리소스를 할당한다면 리소스 낭비, 비용이 발생한다.
3. Restart 등 복구 시간이 오래 걸린다 : 서비스가 어떤 서버에서 실행하는지, 확인 후 재 시작

✔ Borg : Google에서 개발한 최초의 통합 컨테이너 관리 시스템

     ✔ 서비스 디스커버리 : 

  MSA에서 수많은 애플리케이션이 예고없이 종료/재시작 되는데 이때 서버 Instance IP 등이 바뀐다.

  이에 Service Registry 서버를 두면 Micro service instance의 주소 목록을 관리할 수 있다.

  따라서 Service Registry 서버를 항상 최신으로 유지하는 것이 중요해서, Intance가 주기적으로 Heartbeat를 보낸다.

✔ Omega: 클러스터 상태 저장, 낙관적 동시성 제어 등을 추가

 

👉 쿠버네티스는 컨테이너 오케스트레이션 시스템 보그(borg)를 오픈 소스 소프트웨어로 공개한 것이다.

👉 구글은 리눅스 재단과 협업해서 CNCF를 만들고 쿠버네티스를 기부했다.

👉 Borg, Omega와 달리 오픈소스로, Public Cloud 인프라 사업을 성장시키기 위해 개발함

- 더 높은 추상화를 위해 REST API를 통해서만 공유저장소에 접근할 수 있도록 바뀌었음.

 

 

K8S의 기능

• 자동화된 빈 패킹(bin packing) : 각 컨테이너가 필요로 하는 CPU와 RAM을 K8S에게 지시함으로서, 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 도와준다.
• 자동화된 복구(self-healing) : 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, 죽이는 이런 과정을 클라이언트에게 보여주지 않는다.
• 자동화된 롤아웃(배포)과 롤백 : 원하는 상태를 서술해주기만 하면 원하는 상태로 배포가 가능하다.

 

K8S의 특징

• 선언적 API
• 컴포넌트를 여러 개 실행해둘 수 있으므로 단일 장애점(SPOF)이 없다.
  • Single Point of Failure: 시스템 구성 요소 중 동작하지 으면 전체 시스템이 중단되는 요소

 

---

용어 정의

Cluster  : 여러 개의 서버를 하나로 묶은 집합

쿠버네티스 클러스터 구성 도구

Kubeadm	쿠버네티스에서 제공하는 클러스터 생성/관리 도구
kubespray	- 상용 서비스에 적합한 보안성과 고가용성이 있는 K8S 클러스터를 배포하는 오픈 소스 프로젝트  - 서버 환경 설정 자동화 도구인 ansible기반으로 개발되어, 사용자에게 맞는 다양한 형식으로 쿠버네티스 클러스터를 구성할 수 있다. (온프레미스 환경에서 유용) - kubeadm처럼 별도의 로드밸런서를 사용하지 않고 노드 각각의 nginx가 리버스 프록시로 실행된다. (nginx-proxy가 전체 마스터 노드를 바라보는 구조)
CNI	Container간 통신을 지원하는 VxLAN, Pod Network

 

# kubespray가 지원하는 네트워크 플러그인

• flannel: 가장 오래되어 안정성이 높은 플러그인 (네트워크 정책 기능 지원 X, 네트워크 주소가 제한된 환경에서 추천)
• Calico: BGP 기반 네트워킹 지원.  
• Weavenet: 외부 키/값 데이터베이스 클러스터(etcd)가 필요 없는 경량 컨테이너 오버레이 네트워킹 지원
  • (최대 500개 노드까지 지원하므로 작은 중규모 클러스터 운영에 적합)
• kube-router: IPVS 기반의 네트워킹 지원

 

# 쿠버네티스 컴포넌트

 

마스터 노드 : 노드들의 상태를 관리하고 제어한다.

Master Component (Control Plane)	클러스터의 상태를 저장 및 관리하는 컴포넌트들이 속해있는 서버
etcd (key-value data store)	key-value 타입의 저장소, 쿠버네티스에서 필요한 모든 데이터를 저장하는 DB 역할. (Worker node에 대한 상태 정보, = 클러스터에 배포된 애플리케이션 실행 정보/ 상태 정보 저장) 컨테이너가 아닌 서버 프로세스로 실행하도록 구성되어 있음.
kube-apiserver	⭐쿠버네티스의 모든 통신은 kube-apiserver가 중심이다. (kube-apiserver를 거쳐 다른 컴포넌트가 서로 필요한 정보를 주고 받는데, 특히 etcd에는 kube-apiserver만 접근이 가능하다.) K8S  API를 사용하도록 요청을 받고, 요청이 유효한지 검사 클러스터 상태 조회, 변경을 위한 API 인터페이스 제공
kube- scheduler	파드를 실행할 노드 선택
kube-contorller-manager	파드를 관찰하여 갯수 보장 즉, : user가 요청한 container의 갯수/상태 등이 현재 잘 운영되는지 감시 일치하지 않는다면 API 서버에 추가적인 리소스 요청

 

📖 etcd

분산 시스템에서 노드 사이의 상태를 공유하는 합의 알고리즘 중 하나인 raft 알고리즘 구현

서버 하나당 프로세스 1개만 사용 가능하다.

📖 kube-apiserver

 kube-apiserver는 쿠버네티스 클러스터의 API를 사용할 수 있도록 하는 컴포넌트로, 클러스터로 온 요청이 유효한 지 검증한다.

쿠버네티스에 보내는 모든 요청은 kube-apiserver를 이용해서 다른 컴포넌트로 전달한다.

📖 kube- scheduler

클러스터 안에서 자원 할당이 가능한 노드 중 조건에 맞는 노드를 선택해서 새롭게 만든 파드를 실행한다. 

📖 kube-contorller-manager

쿠버네티스는 파드들을 관리하는 컨트롤러가 있다.

컨트롤러 각각은 논리적으로 개별프로세스지만, 복잡도를 줄이려고 모든 컨트롤러를 바이너리 파일 하나로 컴파일해 단일 프로세스로 실행된다.

kube-contorller-manager는 컨트롤러 각각을 실행하는 컴포넌트다. 

 

워커노드: kubelet이라는 프로세스(에이전트)가 동작하며, 마스터 노드의 명령을 받아 사용자가 선언한 Pod, Job을 실행

 

Worker node Component	컨테이너 실행 담당
kubelet	모든 노드에서 실행되는 K8S 에이전트 데몬 형태로 동작
kube-proxy	K8S의 네트워크 설정 및 관리 - iptables rule 구성
Container runtime	컨테이너를 실행하는 엔진 ex. docker, containerd, runc - k8s 버전 1.10부터는 쿠버네티스와 같은 CNCF 소속인 containerd를 도커없이 기본 런타임으로 사용할 수 있다.

 

쿠버네티스에 어플리케이션 컨테이너를 배포한다?

: 쿠버네티스 오브젝트를 정의하는 Manifest 파일을 작성해서 마스터 노드에 있는 API server에게 (http request로) 요청을 보내는 행위

• Manifest 파일 :  쿠버네티스 오브젝트를 생성하기 위한 필수 정보 "일을 시키기 위한 지시서"

📖  kubelet

파드 컨테이너들의 실행을 직접 관리한다.

ex. PodSpecs가 담긴 설정을 전달받아서 컨테이너를 실행하고 컨테이너가 정상적으로 실행되는지 헬스 체크를 진행한다.

kubelet(데몬) 안에는 cAdvisor라는 container monitoring tool이 있고, Master node는 각종 상태 정보들을 etcd 안에 저장한다. 

 

 

API Server

스케줄러에게 nginx를 실행하기 위해 어떤 worker node에서 실행하면 가장 좋을까? 하고 질의를 함.

Scheduler

노드 상태를 보고 응답을 해주고, API server는 해당 노드의 kubelet에게 nginx 실행을 요청함.

 

🌞 그럼 그 노드에 있는 kubelet은 docker 명령어로 바꿔서 docker demone에게 container 실행 요청을 함.

데몬은 docker Hub 에 nginx container가 있는지 검색한 뒤 받아아서 container로(=Pod) 실행해준다.

 

📖  Addon (클러스터 안에서 필요한 기능 실행하는 파드)

네임스페이스는 kube-system이며,

애드온으로 사용하는 파드들은 디플로이먼트, 레플리케이션 컨트롤러 등으로 관리한다.

 

• CNI (Container Network Interface) : Network Addon 프로그램
  • 컨테이너간의 통신을 지원해주는 기능 ex. Weave, calico, flaneId, kube-route
• DNS Addon : kube-dns, coreDNS(기본)
• 대시보드 Addon 
• 컨테이너 자원 모니터링 : cAdvisor(컨테이너 모니터링 도구)
  • 자원 사용량 데이터를 수집하는 metrics 서버를 손쉽게 모니터링에 이용한다.
• 클러스터 로깅:
  • 컨테이너 로그, k8s 구성 요소들의 운영 로그들을 수집해서 중앙화
  • ELK(ElastricSearch, Logstash, Kibana), EFK(ElasticSearch, Fluent Kibana), DataDog

# 오브젝트와 컨트롤러

• 오브젝트 : 쿠버네티스에 자원의 '바라는 상태' 정의
  • Pod, Service, Volume, namespace
• 컨트롤러: 바라는 상태와 현재 상태가 일치하도록 오브젝트 생성/삭제
  • ReplicaSet, Deployment, Statefulset. DaemonSet, Job..

# 자세한 작동 원리 

1. API Server가 command 요청이 들어오면 etcd라는 영구 저장소에 상태 저장

2. 어떤 리소스 이벤트에 대해 구독을 하겠다는 내용이 scheduler에 설정이 되어있는데 

controller manager 컴포넌트가 신규 리소스 이벤트를 받으면 API server로 추가 리소스 생성 요청을 보낸다.

3. API 서버가 파드에 대한 생성 요청/생성 정보를 etcd에 저장한다.

4. 스케줄러는 노드에 배포되지 않은 파드를 읽어오게 되고, 그 파드가 배포가 되려면 어느정도 리소스가 필요한지 확인한다.

5. 최적의 조건인 노드를 선택하고, 그 노드 정보를 파드 정보에 추가해서 다시 API 서버로 전송한다.

6. API 서버는 그 정보를 etcd에 기록한다 = 노드 할당 완료 (A)

7. A라는 노드에서 실행중인 kubelet 프로세스가 배포해야할 파드가 있구나! 라는 이벤트를 받게되서

컨테이너런타임(ex.도커)에게 컨테이너 생성/ 실행 명령을 내리게 된다.