Kubernetes 구성 Overview

출철 : https://blog.naver.com/freepsw/220882543182

http://kubernetes.io/docs/whatisk8s/ 참고
https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes 

먼저 Kubernetes의 발음은 쿠버네티스(koo-ber-net-eez)라고 한다. 그리스어로 의미는 "배의 키잡이"라는데... 작명이 왠지 좋아보인다.  그리고 K8s 은 첫글자 K와 끝글자 s를 제외한 8 글자인 “ubernete”를  8로 대체한 약어임. 
구글이 2014년 오픈소스로 공개했고, 구글 자체 인프라 기반의 대규모 서버 클러스터에서 구동하는 컨테이너를 관리하기 위한 엔진이다. (Google Cloud platform에서도 사용)
전체적인 기능은 docker swarm, mesos의 실행엔진인 marathon과 유사한 기능을 제공한다. (클러스터 환경에서 어플리케이션을 쉽게 배포, 디스커버리, 확장 할 수 있는 기능)

0. Why kubernetes?

1) 왜 필요한가?

- 대부분의 어플리케이션/서비스 들은 자신에게 필요한 환경설정이 따로 있다. 그러나 많은 인프라환경에서 이를 독립적으로 사용하지 못하고, 다른 수많은 어플리케이션의 환경설정을 공유해야 하는 문제(환경설정으로 인한 오류 등..)가 있다. 
- kubernetes는 이렇게 기존 서버(인프라)와의 단절(독립성)을 통해 안정적인 어플리케이션을 실행할 수 있도록 지원한다 (컨테이너 기술). 이는 다양한 어플리케이션으로 구성된 서비스에도 동일하게 적용된다.
- kubernetes는 클러스터에 구동중인 어플리케이션 컨테이너의 실행/스케줄링을 할 수 있으며, 개발자들이 물리/가상 머신과 개발환경을 독립적으로 구성하여 컨테이너기반의 배포가 가능하도록 도와준다. 
- 운영자들은 아래 기능들을 이용하여 PaaS 플랫폼을 단순하게 구성할 수 있으며, 다양한 인프라에 쉽게 적용할 수 있다 
https://deis.com/blog/2016/kubernetes-illustrated-guide/ 동화 형식으로 k8s가 왜 필요한지에 대해서 잘 설명해 주고 있다. 

2) 핵심기능은?

- 어플리케이션의 배포를 변경없이 빠르게 할 수 있다.
- 동적으로 어플리케이션의 확장이 가능하다.
- 새로운 버전으로 중단없이 업드레이드 가능하다.
- 하드웨어 자원을 최적화하여 사용할 수 있다.

1. Portable : 다양한 환경에 배포(public, private, cloud...) 2. extensible : 컨테이너간의 다양한 조합으로 확장가능 3. self-healing : 자동배포, 자동재시작, 자동복제, 자동확장...

3) kubernetes is not ...

- 전통적인, 모든 기능이 포함된 PaaS는 아니다.(좀 더 사용자가 중요하게 생각하는 점에 중점을 두었음)
- 따라서 미들웨어나 메세지버스를 제공하지 않으며, 정해진 개발언어 및 설정을 강제하지 않는다. 사용자는 원하는 로깅/모니터링/프레임워크를 선택할 수 있고, 이를 kubernetes에서 구동할 수 있다.
- 그렇다고 kubernetes가 단순히 관리만 제공하는 시스템은 아니며, 다양한 독립적인 컨테이너들로 구성되며, 이들의 상태를 끊임없이 체크하고 이상적인 상태를 유지하도록 한다.

1. Kubernetes and Container Operation

지난 3년간 Linux Container기술(Docker)은 수많은 서버 인프라분야에  적용되면서 소프트웨어 배포에 대한 혁명적인 발전을 가져왔다. (다양한 인프라별로 어플리케이션의 설정과 배포를 독립적으로 구성하게 됨)

1) Container란?

컨테이너 기술의 핵심은 cGroup과 namespace로 구성된다. 도커는 추가적으로 union filesystem을 이용하여 컨테이너 개발의 잇점을 더하였다.

Why Container? (http://kubernetes.io/images/docs/why_containers.svg)

[cGroups] Control groups란?
- 호스트의 자원을 프로세스/컨테이너 별로 공유/제한하는 기술. 자원활용 및 보안측면에서 중요하다.(DDos와 같은 자원 점유를 막아줌)

[namespaces] 란?
- 정해진 네임스페이스 내에 존재하는 process ID만 접근할 수 있도록 isolation을 제공하는 기술요소. (다른 네임스페이스에 존재하는 프로세스는 접근이 불가)

[union file system] 이란?
- 도커에서 이미지파일을 관리하기 위해서 제공하는 가장 큰 장점을 제공한다. (3단 케이크와 같은 층이 있는 구조로, 원하는 어플리케이션을 계속 추가할 수 있는 구조)
- layered image 구조로 예를들면, 가장 먼저 Linux Kernel를 설치하고, Ubuntu, apache httpd 이렇게 단계별로 설치할 수 있다, 
- 이렇게 구성하면 내부적으로 image cache를 이용할 수 있어서, 나중에 ubunbu기반의 nginx 컨테이너를 설치할 때, 기존에 사용한 ubuntu image를 재사용할 수 있다. 

오른쪽에서 도커는 base image를 공유함 (https://insights.sei.cmu.edu/assets/content/VM-Diagram.png)

2) 왜 Container가 대세인가?

컨테이너 기술자체는 전혀 새로운 것이 아니다. 도커가 이를 이용하여 다양한 배포 환경에서 활용할 수 있도록 커뮤니티에 제공하면서 엄청난 인기를 누리게 된것.

2. Kubernetes Cluster 란?

1) Kubernetes Core Architecture

- k8s는 모든 컨테이너 어플리케이션 스택의 관리와 함께 확장에 대한 관리까지 지원한다. (도커와 일부 유사)
- 어플리케이션과 서비스레벨의 관리가 가능하게 하며, 고가용성을 위한 자동화, 서비스의 이동성 등을 지원하고, 자원에 대한 세밀한 제어가 가능하다.
- k8s는 언제, 어디서, 얼마나 많은 stack과 component이 있는지 관리할 수 있도록 툴을 제공한다.

핵심 구성요소 (https://www.upcloud.com/support/wp-content/uploads/2016/09/Kubernetes-Cluster-Master-1024x456.png)

관리를 위한 통신은 kubelet 또는 REST API를 사용하고 있다. 여기서 중요한 포인트는 desired status와 actual states라는 개념이다. 이 핵심 개념을 기반으로 k8s는 클러스터와 작업들을 관리하게 된다. 즉, 모든 k8s의 요소들은 현재 actual states를 모니터링하고 있으며, 이를 관리자가 설정한 desired stats와 동일한 상태로 유지하려고 한다.(kubelet과 REST API를 이용해서)

Master 구성요소

- 클러스터를 관리하는 서버(노드)로 worker 노드들과 통신하여 desired states를 유지하기 위한 제어를 수행한다.

1) Etcd - go언어로 구성된 Key-Value 저장소이며, 변경된 값에 대한 watch 가능 - 도커에서 컨테이너에게 모든 IP를 부여할 수 없어, IP가 아닌 별도 어드레스를 부여하여 컨테이너를 찾을 수 있게 하는 기술 - 암호화 기능을 제공하여 보안된 통신이 가능하다. - k8s에서는 모든 노드에서 사용할 config데이터를 저장하고, 이를 통해서 서비스 discovery와 클러스터 상태정보를 표현한다. - REST API를 이용해 값을 저장/조회가능하다. 2) API Server - 전체 클러스터의 핵심 관리 포인트로 사용자들이 k8s에 대한 작업을 정의하고, 배포된 컨테이너들이 정상적으로 실행되는지 확인한다. - 클러스터를 정상적인 상태로 유지하기 위해서 다양한 컴퍼넌트간의 브릿지 역할을 수행한다. - REST API로 구성되며 kubecfg라는 클라이언트 패키지가 서버 사이트 툴로 제공되어 로컬 컴퓨터에서 k8s 클러스터와 통신이 가능하게 해 준다. 3) Controller Manager Service - 많은 컨트롤러의 상태와 task 실행에 대한 책임이 있다. 예를 들면 replication 컨트롤러는 서비스에 정의된 갯수만큼의 복제된 수가 클러스터에 구동되어 있는지 보장하는 책임이 있다. - 만약 변경이 발생하면 컨트롤러는 새로운 정보를 읽어서, 변경된 desired state로 작업들을 실행한다. (서비스 확장,축소 ..) 4) Scheduler Service - 실제 작업을 클러스터의 특정 노드에 할당한다. (서비스 운영 요건, 현재 자원 현황, 수용가능한 노드에 대한 정보를 읽어서 ) - 가용자원을 초과하여 스케줄링되지 못한 작업들을 확인하기 위하여 각 호스트 자원 활용에 대한 추적을 담당한다. (현재 자원과 요청자원에 대한 정보 관리)

Node 구성요소

정의된 작업은 노드 서버에서 실행된다. 노드 서버는 몇가지 필수 요건이 있다
master 컴퍼넌트들과 통신이 가능해야 하고, 컨테이너를 위한 네트워크가 설정되어야 하며, 할당된 작업을 실행해야 한다. 

1) 특정 subnet에서 구동하는 Docker - 도커는 독립적인 환경을 가진 어플리케이션 컨테이너를 구동한다. - 한가지 필요한 전제로, 각 노드서버에서 지정된 subnet이 반드시 구성되어야 한다. - 이는 도커가 port를 외부로 노출하기 위해 필요한 네트워크 구성이다. - 정해진 표준은 없으며 CoreOS의 경우 flannel이라는 분리된 네트워크가 필요하다. 2) Kubelet Service - 각 노드들에서 클러스터 그룹에 접속하기 위한 서비스 - control plane서비스에 정보를 전달하고, etcd에 저장된 설정정보를 R/W 하는 역할을 수행한다. - 또한 마스터와 통신하여 command와 work를 수신하는데, work는 'manifest'(작업과 운영 파라미터를 정의한 파일)의 형태로 수신된다. - 노드 서버에서 작업의 상태를 관리하는 책임도 있다. 3) Proxy Service - proxy는 외부에서 서비스에 접속하거나, 개별 호스트 서브넷을 처리하기 위해 사용 - 각 노드서버에서 실행되며, 각 요청을 올바른 컨테이너로 포워딩해 준다. - 또한 포워딩 전에 로드밸런싱을 지원한다.

Kubernetes Work 단위

컨테이너들은 어플리케이션을 배포하는 용도로 사용되는 반면에, 각 work의 타입을 정의한 workload는 k8s에 특화된 용도로 사용된다. 아래 정의된 다양한 work type을 보자.

1) Pods - pod는 k8s가 처리하는 가장 기본 단위이다. - 컨테이너 그 자체는 호스트들에게 할당되지 않는다. 대신에 아주 밀접하게 연관된 컨테이너들은 하나의 pod에 할당될 수 있다. - 하나의 pod는 1개 이상의 컨테이너로 구성될 수 있고, 거기에 포함된 컨테이너는 각각 하나의 어플리케이션을 제어할 수 있다. - 이러한 연관관계가 관련된 모든 컨테이너들이 동일한 호스트에서 스케줄링될 수 있도록 해 준다. 즉, pod에 속한 컨테이너들은 volume과 ip공간을 공유하고, 1개의 어플리케이션처럼 배포 및 확장이 가능하다는 의미 - pod는 핵심 컨테이너와 이를 위해 필요한 관련 컨테이너로 구성된다. (웹서버와 db와 같은 개념인듯) - 하지만 수평적인 확장을 pod level에서 하는 것은 권장하지 않는다. 이보다 더 효율적인 확장단위가 많으므로(경우에 따라서 다를 것 같음.) 2) Services - service는 여러 컨테이너를 하나의 논리적인 단위로 그룹화 하여, 외부에서 접속할 수 있는 단일한 endpoint를 제공한다. (로드밸런싱도) - Service ip는 고정되어야 하며, 내부적으로 컨테이너 또는 pod의 ip변경에 영향을 받지 않아야 한다. 3) Replication Controllers - pod의 좀 더 복잡한 버전이 replicated pod라고 한다. - replication controller로 알려진 work unit type에 의해서 관리된다. - 주요 역할은 정의된 복사본의 수를 유지하는 것이다. 즉 일부 컨테이너가 다운되어도 replication controller는 다른 컨테이너를 구동하여 복제본을 유지한다. 4) Labels - 각 work unit에 설정하는 key-value기반의 속성 tag로 1개 이상 설정 가능 - service와 replication controller는 label기반으로 작업을 수행한다. - name, development/product, private/public등의 기준을 정의해서 사용가능 - 많은 경우 작업의 세밀한 제어를 위해서 label을 사용