👉이전글에서 Container환경과 Kubernetes와 같은 Container Ochestration툴이 뭔지 알아봤습니다.

그리고 이번글에서는 Container Ochestration툴 중 가장 대중적인 툴인 Kubernetes의 클러스터에 대해 알아보겠습니다.

Kubernetes 클러스터

Kubernetes 클러스터는 오토스케일링, 버전관리 등과 같은 Container Ochestration의 다양한 기능들을 제공하기 위해 배포된 Kubernetes 환경이라고 보면 될 것 같습니다.

위 사진과 같은 Kubernetes 클러스터의 구조를 통해 Kubernetes(k8s)기반의 애플리케이션을 안정성있고 확장성있게 운영할 수 있습니다.
k8s클러스터는 크게 Control Plane과 Application Node로 구분할 수 있습니다.

• Control Plane : k8s클러스터 내부에서 발생하는 이벤트는 실시간으로 감지하거나 배포관리 등과 같은 클러스터 전반의 관리를 수행하기 위한 컴포넌트
• Application Node : 실제 application이 배포되는 컴포넌트
  
  

위 두 개의 컴포넌트는 하나의 노드상에 같이 배포되거나 개별 노드로 배포될 수 있습니다. (한 개의 노드는 한 개의 VM이라고 생각하면 이해하기 쉬움)
이제 클러스터를 구성하는 컴포넌트들을 세부적으로 살펴보겠습니다.

Control Plane

kube-apiserver

kube-apiserver는 application node를 제어하기 위한 여러 동작을 호출하는 Control Plane의 프론트엔드 api server입니다. (application node 입장에서는 endpoint api server)

Control Plane의 CLI(Command Line Interface) 환경에서 사용자가 직접 kuber-apiserver를 호출할 수도 있습니다. (명령어 : kubectl)
해당 명령어는 실습을 진행할 때 자주 활용될 것입니다. (다음글)

etcd

k8s클러스터 내부에 application을 어떤 방식으로 배포할지? scaling은 어떻게 진행할지? 등과 같은 클러스터 정보들을 key-value 형태로 저장하는 저장소입니다. 해당 정보들은 사용자가 yaml파일 형태로 작성하여 적용될 수 있는데, 이 또한 실습에서 작성해볼 것입니다. (다음글)

kube-scheduler

application node가 배정되지 않아 미배포 상태인 pod를 실시간으로 감지하고, 해당 pod를 실행시키기 위해 application node를 선택하는 기능을 가진 컴포넌트입니다. pod가 배포될 application node는 컴퓨팅 리소스나 pod의 리소스 요구사항 등과 같은 기준에 따라 결정됩니다.

• pod : k8s에서의 배포 최소단위, application이 동작하는 여러개의 Container를 k8s에서의 최소단위로 묶어놓은 컴포넌트 (다음글에서 다룰 예정)
  
  

kube-controller-manager

k8s클러스터에서 실행되는 여러 개의 컨트롤러를 통합 관리하는 프로세스입니다. 해당 컨트롤러들은 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되는데, 클러스터 내의 리소스를 감시하고 사용자가 정의한 상태로 클러스터를 유지하기 위해 조치를 취하는 역할을 수행합니다.

해당 컨트롤러들은 대표적으로 아래를 포함합니다.

• node controller : Node를 실시간으로 모니터링합니다. Node에 문제가 발생하였을 경우, 이상이 있는 pod를 종료시켜 node를 정상화합니다.
  
  

• replication controller : kube-apiserver를 통해 각 노드의 상태를 받아오고, 사용자가 설정한 Replica의 수에 일치하도록 노드상에 배포된 pod를 생성하거나 삭제하는 역할을 수행합니다.
• job controller : 일회성 작업을 수행하는 오브젝트를 실시간으로 모니터링하고, 수행이 필요한 작업이 있을 경우 해당 작업을 위한 일회성 pod를 생성합니다.
  
  

이외에도 아래 사진과 같은 다양한 컨트롤러가 포함됩니다.

cloud-controller-manager

k8s클러스터가 AWS와 같은 public cloud에 배포되어 있을 경우, application node를 제어하기 위한 controller-manager입니다. 해당 컴포넌트는 클라우트 플랫폼(ex. AWS, Azure 등)별 전용 cloud-controller-manager를 실행합니다.

Application Node

kubelet

kubelet은 각 application node에서 실행되는 Agent 프로세스입니다. control plane으로부터 명령을 받아 수행하거나, node내 파드들의 상태를 실시간 감시하고 control plane으로 보고하는 application node내 중추적인 역할을 수행합니다.

주요기능은 아래와 같습니다.

1. 파드관리 : Control Plane으로부터 할당된 파드를 노드에 배치하고 실행합니다. 해당 파드에 문제가 발생한 경우, 파드를 재시작하거나 재스케줄링하여 안정성을 유지합니다.
2. 컨테이너 실행 : 컨테이너 런타임(ex. docker 등)을 사용하여 파드에 정의된 컨테이너를 실행하고 관리합니다.
3. 리소스 모니터링 : node의 리소스 사용량을 파악하여 Control Plane에 보고합니다.
4. 상태 보고 : node내 배포된 파드의 상태와 노드의 상태를 주기적으로 Control Plane에 보고합니다.
5. 노드의 자동복구 : 노드가 비정상적으로 종료되었을 때, 자동으로 복구를 시도합니다.
   
   

kube-proxy

kube-proxy는 각 application node에서 실행되고, node간 네트워크를 관리하고 클러스터 바깥에서 접근할 수 있도록 해주는 컴포넌트입니다.

해당 컴포넌트는 node나 pod의 교체가 쉬운 k8s클러스터 환경에서의 원활한 통신을 보장합니다.
문제가 생겨 node나 pod가 새로 교체되는 경우가 발생할 수도 있는데, 이 때 ip가 교체되어 통신이 안되는 상황을 방지하기 위해
pod가 새로 생성될 때 별도 node iptable에 신규 생성된 pod의 네트워크 정보를 현행화합니다.

reference

• kubernetes conponents : https://kubernetes.io/ko/docs/concepts/overview/components/
• kube scheduler : https://velog.io/@gun_123/Kubernetes-Scheduler
• kube controller manager : https://m.blog.naver.com/ijoos/222125981319
• kube proxy : https://velog.io/@squarebird/Worker-Node-Kube-Proxy
• kubelet : https://velog.io/@gun_123/Kubernetes-Kubelet

Kubernetes 개요

Kubernetes는 컨테이너를 쉽고 빠르게 배포/확장하고, 관리 또한 자동화해주는 오픈소스 플랫폼입니다. 대량의 컨테이너를 관리해주는 플랫폼을 통칭하는 말인 Container Ochestration중 하나죠. (약칭 : k8s)

Kubernetes를 처음 접하신 분들은 여기서 Container는 무엇이고, Container Ochestration가 뭔지도 궁금해하실 것 같습니다.
먼저, Container에 대해 짚고 넘어가겠습니다.

Container

Container는 애플리케이션 실행 시 필요한 모든 파일을 포함한 전체 실행(runtime) 환경에서 애플리케이션을 패키징하고 격리할 수 있는 기술입니다. 각 애플리케이션당 독립된 실행환경을 제공하기 때문에 애플리케이션간 영향도를 최소화하여 안정성을 확보할 수 있습니다.

또한, 하나의 application이 실행되는 각각의 Container들은 한 개의 VM내에서 서로 Host OS를 공유하기 때문에,
Container환경 배포 시에는 VM에 배포하는 것처럼 OS를 별도 배포하지 않아도 되고, alpine-linux 등과 같은 경량 OS를 활용하게 됩니다.
이를 통해 빠른 배포가 가능하여 확장성을 보장할 수 있습니다.

결론적으로 Container 기술을 활용하면,

1. 애플리케이션간 독립된 환경을 보장받기 때문에 애플리케이션간 영향도 최소화를 통한 안정성
2. 애플리케이션 배포 시, 별도 OS의 배포는 필요하지 않기 때문에 빠른 배포를 통한 확장성

위 두 가지 이점을 챙길 수가 있게 됩니다.

그렇다면... Container 기술의 원리가 무엇일까?

Container 기술은 아래 두 가지 linux 기능을 활용하게 됩니다.

1. namespaces : 프로세스마다 독립적인 공간을 제공하고, 서로가 충돌하지 않게끔 namespaces를 만들어 프로세스를 실행시킬 수 있습니다.
2. cgroups : 각 컨테이너가 공유 컴퓨팅자원에 대한 제어권을 가질 수 있도록 하는 리눅스 커널의 기능입니다.
   
   

본 글에서 Container 기술의 원리까지는 딥하게 다루지 않겠습니다.
자세한 내용은 아래 링크를 참고바랍니다.
https://tech.ssut.me/what-even-is-a-container/

Container Ochestration

Container Ochestration은 Container가 많아짐에 따라 발생하는 관리의 복잡성을 해소하기 위한 플랫폼들을 통칭하는 말입니다. 본 글에서 다룰 kubernetes와 Docker Swarm 등이 이에 해당합니다.

Container Ochestration은 기본적으로 아래와 같은 기능을 제공합니다.

1. cluster : 관리자가 컨테이너 서버들을 cluster 단위로 추상화시켜 놓고, master 서버를 통해 해당 cluster 내부를 관리합니다.
2. state : 특정 애플리케이션이 동일하게 실행되는 container의 갯수를 자동으로 유지시켜줍니다.
3. scheduling : 여러 노드, 여러 컨테이너 서버에 어떤 프로그램이 있는지 확인한 후에 특정 프로그램을 적절한 공간에 넣어줍니다.
4. Rollout Rollback : 자동 버전관리가 가능합니다.
5. Service Discovery : 특정 컨테이너 서버의 정보(ex. host name 등)가 바뀌면 자동으로 확인하고 등록해주는 proxy가 있습니다.
6. Volume : 데이터를 container 서버의 업/다운과 관계없이 영구히 관리하기 위해 별도 공간을 활용하여 container서버에 자동으로 연결시켜 줍니다.
   
   

kubernetes는 위 Container Ochestration의 특징을 모두 갖습니다.

이어서

다음 글에서 Kubernetes cluster에 대해 알아보겠습니다.