공부기록장

노드용 컴포넌트

동작중인 파드를 유지하고, 관리하며, 쿠버네티스 런타임 환경을 제공합니다.

kubelet

쿠버네티스가 만든 컨테이너들을 파드스펙(PodSpecs) 조건에 맞게 실행하고 컨테이너가 정상인지 헬스체크를 진행합니다.

kube-proxy 

클러스터의 각 노드에서 실행되는 네트워크 프록시입니다.

노드의 네트워크 규픽을 유지 관리하고, 내부 가상 네트워크 섹션관리나 클러스터 바깥에서 파트로 네트워크 통신을 할 수 있도록 해줍니다.

kube-proxy는 운영체제에 가용한 패킷 필터링 계층이 있는 경우 이를 사용하지만, 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드 합니다. 

컨테이너 런타임 

컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어이다.

가장 유명한 Docker가 있다. 

출처 - 쿠버네티스 마스터-컴포넌트

클러스터 

쿠버네티스를 배포하면 클러스터를 얻는데, 이런 클러스터는 여러 머신의 묶음이고, 머신은 여러 컴포넌트를 포함합니다.

그런 컴포넌트는 용도에 따라 3가지 정도로 분류 됩니다. Master, Node 그리고 선택적인 Addon 이 있습니다.

Master용 컴포넌트

마스터 노드는 워커 노드와 클러스터 내 파드를 관리 합니다. 또 다수의 마스터 노드는 장애극복(failover)와 고가용성의 클러스터에서 사용합니다. 

마스터 노드가 속한 클러스터를 관리 하기 위해 구성된 마스터용 컴포넌트는 다음과 같습니다.

etcd 

key-value 저장소이며, 백업을 권하고 있습니다.

etcd는 서버 하나당 프로세스 1개만 사용할 수 있습니다. 때문에, etcd 자체를 클러스터링한 후 각 마스터에 설치해 사용을 합니다.

kube-apiserver 

컨트롤 플레인의 프론트 엔드이다. 클러스터로 온 요청이 유효한지 검증 및 권한확인 등을 하고 요청에 따른 행위를 한다. kube-apiserver는 수평으로 확장가능 하도록 하기 위해 MSA로 디자인 되어 인스턴스간의 트래픽을 균형 있게 조절할수 있다.

kube-scheduler 

새롭게 생성된 파드를 감지하여, 파드를 실행할 노드를 배정하고 파드를 구동합니다. 노드를 배정할때 여러 조건을 확인 하는데, 고려되는 요소는 리소스에 대한 개별 및 총제적 요구 사항, 하드웨어/소프트웨어/정책적 제약, 어피니티(affinity) 및 안티-어피니티(anti-affinity)명세, 데이터 지역성, 워크로드-간 간섭, 데드라인을 포함합니다. 

kube-controller-manager

노드를 관리하는 컨트롤러이다.

논리적으로는 각 컨트롤러는 별개의 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 단일 프로세스내에서 실행됩니다.

각 컨트롤러는 노드컨트롤러, 레플리케이션 컨트롤러, 엔드포인트 컨트롤러, 서비스 어카운트 & 토큰 컨트롤러로 구성됩니다.

cloud-controller-manager 

클라우드 서비스와 연결해 관리하는 컴포넌트입니다.

네가지의 컨트롤러를 제공 합니다. 노드 컨트롤러, 라우트 컨트롤러, 서비스 컨트롤러, 볼륨 컨트롤러 입니다. 

출처 - 쿠버네티스가 왜 필요하고 무엇을 할 수 있나?

컨테이너를 활용하여 애플리케이션을 포장을 실행을 하는 방법은 좋은 방법이다. 하지만, 배포시 서비스가 중단 없이 배포 되고, 문제가 생겼을때 알아서 장애를 처리해주며, 분산시스템을 탄력적으로 관리 해준다면 얼마나 좋을까? 그래서 쿠버네티스가 존재한다. 쿠버네티스는 애플리케이션의 확장과 장애조치를 처리하고, 배포 패턴 등을 제공한다. ( 롤링업데이트, 카나리아 배포 )

하지만, 쿠버네티스틑 PasS(Platform as a Service)는 아니다. 배포, 스케일링, 로드밸런싱, 로깅 및 모니터링과 같은 기능에서 공통점도 있지만, 이것을 모놀리식하게 제공 하는 것이 아니라, 선택적으로 제공하여, 추가제거가 용이하다. 즉 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다.

• 서비스 디스커버리와 로드 밸런싱 : 네트워크 트래픽을 로드밸런싱 하고, 배포하여 배포가 안정적으로 이루어질 수 있다.
• 스토리지 오케스트레이션 : 로컬 저장소, 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재 할수 있다.
• 자동화된 롤 아웃과 롤백 : 쿠버네티스를 사용하여 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새컨테이너에 적용 할수 있다.
• 자동화된 빈 패킹(bin packing) : 컨테이너화된 작업을 실행하는데 필요한 쿠버네티스 클러스터 노드를 제공하고, 리소스를 관리한다.
• 자동화된 복구 (self-healing) : 실패한 컨테이너를 다시 시작, 교체, 사용자 정의에 따른 상태에 맞지 않는 컨테이너를 죽이고, 관리하여, 모든 준비가 완료 되었을때 클라이언트에 노출한다.
• 시크릿과 구성 관리 : 암호, OAuth 토큰, SSH 키와 같은 중요한 정보를 저장하고 관리 한다.

컨테이너

출처 - [쿠버네티스 - 여정 돌아보기]

위 그림은 전통적인 배포 -> 가상화 장비에 배포 -> 컨테이너 배포를 의미한다.

전통적인 환경은 일반적으로 물리 장비 한대에 여러개의 어플리케이션(그림에서 "App"으로 표현)를 배포 하였는데, 이렇게 할경우, 어플리케이션의 리소스 한계를 정의 하지 못해서 하나의 어플리케이션이 많은 리소스를 필요로 할때, 장비의 모든 리소스를 찾지하여, 다른 어플리케이션에 영향을 주게 된다. 반대로, 어플리케이션의 독립성을 보장하기 위해, 하나의 물리장비에 하나의 어플리케이션을 설치 할경우, 물리장비의 많은 리소스가 낭비될수 있어, 리소스의 비효율성이 들어난다. 때문에 전통적인 환경에서는 어플리케이션의 리소스 관리가 어려웠다.

가장화된 배포 환경 의 경우 하이퍼바이져 위에 VM(Vertual Machine)을 생성하고, 별도의 운영체제를 설치 하고, 해당 운영체제 위에 어플리케이션을 설치 하는 방식이다. VM의 리소스를 제한할수 있고, 복제 및 증설이 용이해져서, 많은 이득을 준다. 

컨테이너와 차이는 무엇일까? 위 그림에서 알수 있듯이, Hypervisor가 Container Runtime으로 변경 되고, 회색 박스 안에서 Operating System(OS:운영체제)가 빠졌다. 각 회색박스로 자원은 격리 되면서, 운영체제가 빠지면서 컨테이너는 더 가벼워지고, 작아 진것이다. 이것은 어플리케이션을 분산 배포 함에 있어, 기민한 애플리케이션 생성과 배포를 가능하게 한다.