Nailer's blog

• 쿠버네티스는 구글이 지난 10여년 간 컨테이너를 프로덕션 환경에서 사용하면서 얻은 경험을 바탕으로 개발한 컨테이너-통합도구이다.

• 여러 개의 호스트를 하나로 묶어 Docker를 이용하기 위한 오케스트레이션 툴

분산 환경에서 한 대의 컴퓨터처럼 투과적으로 컨테이너에 엑세스할 수 있다.

시스템 이용자로부터 오는 부하의 급증에 대해 스케일하거나 여러 컨테이너를 효율적으로 통합 관리하는 장치도 있다.

주요 기능들

• 여러 서버들에서의 컨테이너 관리
• 컨테이너 간 네트워크 관리
• 컨테이너의 부하 분산
• 컨테이너의 감시
• 무정지로 업데이트

Kubernetes의 서버 구성

Master Server

• kubernetes 클러스터 안의 컨테이너를 조작하기 위한 server

kubect1¹ 명령을 사용하여 클러스터를 구성하거나 리소스를 조작할 때 Master Server가 command로부터 request를 받아 처리한다. 클러스터 내의 노드의 리소스 사용 현황을 확인하고, 컨테이너를 시작할 노드를 자동으로 선택한다. 다중화를 검토할 필요가 있다.

Back-end Database(etcd)

• 분산 key-value store, 클러스터의 구성 정보를 관리한다.

클러스터를 구축하기 위한 설정 정보가 들어 있다.

시스템 구성에 따라서 etcd를 master server상에 구축하는 경우도 있다. master server와 마찬가지로 다중화를 검토할 필요가 있다.

Node

• 실제로 Docker container를 작동시키는 서버

노드를 여러 개 마련하여 cluster를 구성한다. master server의 관리를 받는다. 노드를 몇 대 마련할지는 시스템의 규모나 부하에 따라 달라진다. 클라우드 환경에서는 Node 하나가 가상 머신의 인스턴스 하나가 된다.

Application 구성 관리

application 실행 환경의 orchestration 을 유연하게 수행하기 위해 다양한 추상화를 하고 있다.

Pod

• 여러개의 컨테이너를 모아서 **'pod'**로 관리한다.

app server용 컨테이너와 proxy server용 컨테이너 등 관련된 것들을 pod로 모은다. Pod는 application의 Deployment 단위가 되며 Pod 단위로 컨테이너 작성/시작/정지/삭제 와 같은 조작을 수행한다. 따라서 웹 프론트 서버와 데이터베이스 서버처럼 다른 기능을 하나의 Pod에 저장하면 안된다.

Pod는 반드시 동일한 노드 상에 동시에 전개된다. Pod 안의 여러 컨테이너가 가상 NIC(private IP)²를 공유하는 구성을 취하기 때문에 컨테이너끼리 localhost 경유로 통신할 수 있다.

Replica Set

• 클러스터 상에 미리 지정된 Pod를 작성하여 실행시켜두는 장치

클러스터 상에 정해진 수의 Pod를 반드시 실행시켜 둔다는 것 실행중인 Pod를 감시하고 정지된 경우에 해당 Pod를 삭제하고, 새로운 Pod를 실행시킨다. 클라우드 안에 pod를 얼마나 실행시켜 둘지를 **'Replica 수'**라고 한다. pod의 수를 동적으로 변경하여 오토스케일을 구현할 수 있다.

Deployment

• Pod와 ReplicaSet을 모은 것 ReplicaSet의 이력을 관리하는 것이다.

ReplicaSet의 템플릿을 가지고 거기서 Pod의 구성을 정의하여 해당 템플릿을 따르는 ReplicaSet을 만든다. 이력을 관리할 수 있기 때문에 pod 안의 컨테이너의 버전업을 하고 싶을 때 롤링 업데이트³를 하거나 이전 세대로 롤백할 수 있다. 기본적으로 'Blue-Green Deployment' 방법이 있다.

이 외에도

• DeamonSet : Node별로 감시 에이전트와 같은 특정 pod를 반드시 배치하고 싶을 때 사용
• Jobs : 상주 서비스가 아닌 수치연산 처리와 같이 프로그램의 시작부터 종료까지로 완료되는 프로그램을 Pod에서 실행시킨다.
• CronJob : Linux의 cron⁴과 같이 Pod를 실행시킬 타이밍을 지정한다.

등의 관리 툴들이 있다.

Network 관리(Service)

클러스터 안에서 실행되는 Pod에 대해 외부로부터 엑세스할 때는 서비스를 정의한다. Service는 네트워크를 관리하는 것으로 종류가 다양하다.

• Load Balancer : Service에 대응하는 IP 주소 + 포트번호에 엑세스하면 여러 Pod에 대한 L4 level의 로드벨런싱이 일어난다.

Service에 할당되는 IP 주소는

• Cluster IP : cluster 내부의 Pod끼리의 통신을 위한 Private IP pod에서 보내는 패킷은 Node 상의 Proxy 데몬이 받아 수신 Pod로 전송된다.
• External IP : 외부 client와 연결하기 위한 public IP 주소 Pod를 새로 실행하면 기존 서비스의 IP 주소와 포트 번호는 환경변수로 참조할 수 있다.

Service 외에..

Ingress라는 pod에 대한 통신을 제어하는 기능이 있다. Ingress는 Service와 연결되어 통신 내용을 중계(proxy)한다. 이는 작동하는 환경에 따라 다른데, GCP의 경우 HTTP Load Balancer를 사용한다. L7에서 작동하기 때문에 request url 별 분류나 virtual host 기능 등 보다 세세한 네트워크 제어를 할 수 있다.

Label을 사용한 리소스 식별

리소스를 식별하기 위해 내부에서 자동으로 랜덤한 이름이 부여됨 이 이름으로 적절히 관리하기 어렵기 때문에 Label을 붙여서 관리한다.

• 리소스를 식별하기 위한 Key-Value 형태의 임의의 문자열

Label을 identifier로 하여 리소스를 일괄적으로 처리한다.

Label은 하나의 리소스에 여러개를 설정할 수 있어서 Pod의 역할별로 임의의 이름을 붙이거나 관련 있는 Pod 별로 모아서 유연하게 관리하고자 할때 유용하다.

또한 매니페스트 라는 kubernetes의 정의 파일을 참조할 때도 사용됩니다.

ex)

labels:
  app: v1.0
selector:
  type: webserver
  app: v1.0

Kubernetes의 구조

마스터, 데이터 스토어, 노드가 서로 협력하면서 컨테이너의 실행환경을 관리한다.

Master

• API Server

  kubernetes의 리소스 정보를 관리하기 위한 Front-end REST API

  각 component로부터 리소스 정보를 받아 etcd에 저장한다.

  component들은 etcd에 접근하기위해 API server를 거치고

  프로그래머는 웹의 GUI툴이나 kubectl 명령을 사용하고, app 내에서 API Server를 호출한다.

  인증, 인가 기능을 갖고 있음

• Scheduler

  Pod를 어떤 Node에서 작동시킬지 제어하는 Back-end component

  Node가 할당되지 않은 Pod를 클러스터의 상태를 확인하고 빈 영역을 가진 Node를 찾아

  실행시키는 스캐쥴링을 수행

• Controller Manager

  Kubernetes 클러스터의 상태를 항상 감시하는 Back-end Component

  정의 파일에서 정의한 것과 실제 Node나 Container에서 움직이고 있는 상태를 모아서 관리

Data Store(etcd)

클러스터 구성을 유지 관리하는 KVS(key value store)

어떤 pod를 어떻게 배치할지와 같은 구성 정보를 갖고 있으며 API server가 참조한다.

Node

• kubelet

  Node에서 작동하는 에이전트

  Pod의 정의 파일에 따라 Docker 컨테이너를 실행하거나 Storage를 마운트하는 기능을 갖는다.

  Node의 status를 정기적으로 감시하는 기능을 갖고, status가 변경되면 API server에게 알린다.

kubernetes의 클러스터 구성정보를 YAML이나 JSON으로 관리하는데 이 정의파일을 Manifest file이라고 한다. Jenkins와 같은 소프트웨어 버전관리 시스템과 연계할 수 있다.