728x90

Kubernetes

공식 문서: https://kubernetes.io/ko/docs/concepts/overview/what-is-kubernetes/

쿠버네티스를 사용하는 이유

서비스 디스커버리와 로드 밸런싱 쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다. 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다.
스토리지 오케스트레이션 쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재 할 수 있다.
자동화된 롤아웃과 롤백 쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다. 예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다.
자동화된 빈 패킹(bin packing) 컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 지시한다. 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해준다.(bin 은 실행 파일)
자동화된 복구(self-healing) 쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
시크릿과 구성 관리 쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.

쿠버네티스가 지원하지 못하는 작업들

지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(stateless) 워크로드, 상태 유지가 필요한(stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작할 것이다. k8s 와 컨테이너는 stateless 를 지원하기에 최적화되어 있다. 물론 stateful 워크로드도 지원한다.
소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합과 전달과 배포, 곧 CI/CD 워크플로우는 조직 문화와 취향에 따를 뿐만 아니라 기술적인 요구사항으로 결정된다.
애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, MySQL), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 Open Service Broker 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다.
로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다. 프로메테우스를 사용해서 모니터링을 제공한다.
기본 설정 언어/시스템(예, Jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다. 기본적으로 yaml 포맷을 사용한다.
포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다. 퍼블릭 클라우드에서는 관리형 쿠버네티스를 제공해준다. 위와 같은 기능을 제공해주는 것.
추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도한 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.
중요한 것은 Log Monitoring, CI/CD 을 쿠버네티스 자체에서는 지원하지 않는다는 것이다.

관리형 쿠버네티스

각각의 public coloud(AWS EKS, Azure AKS, Google GKE) 마다 관리형 쿠버네티스 서비스가 존재한다.

Control Plane 이 추상화되어 없다. 즉, Control Plane 을 퍼블릭 클라우드가 관리해주는 것이다. Control Plane 을 신경쓸 필요가 전혀 없다는 것이다.

요즘 트렌드는 Control Plane 뿐 만 아니라 Node 도 추상화시켜서 없애는 추세이다.

클러스터는 짝수로 설정하지 않는다.

VM 4개 중에 네트워크가 끊겨 1개가 에러가 발생했다. 이 경우 과반수 정책(정족수)로 인해 나머지 3대로 운영을 한다.

만약, 2대가 에러가 발생할 경우, 과반수를 넘지 않기 때문에 클러스터에 문제가 발생한다.

쿠버네티스 아키텍쳐

클러스터는 물리적 혹은 논리적으로 여러개의 리소스를 하나로 묶어서 사용하는 것을 뜻한다.

기본적으로 Docker 는 클러스터라는 기능은 없다. 도커 컨테이너들은 각각 따로 관리된다. 이를 하나로 한꺼번에 관리할 수는 없다.

이런 형태를 stand alone 이라고 부르며, stand alone 형태는 관리하기가 힘들다.

즉, 클러스터는 리소스를 하나로 묶어서 한번에 관리를 하는 것이다.

쿠버네티스 클러스터의 핵심

Control Plane
Node

Node(구 명칭 worker, Minions)

Control Plane 과 Node 라는 VM 형태로 나눠진다. 즉 역할이 분리되는 것이다.

Node 는 실제 컨테이너를 실행해준다. 즉, Node 안에 도커(podman, CRIO...)가 설치되있어야 한다.

일반적으로 Control Plane 보다 Node 의 갯수가 더 많다.

Control Plane(구 명칭 Master)

Node 를 관리해주는 녀석이다. 그래서 Control Plane 에 장애가 발생하면 Node 를 관리할 수 없다. 그래서 SPoF 를 방지하기 위해 여러 대의 Control Plane 을 띄워둔다. 일반적으로는 3대이상을 Control Plane 으로 띄운다.

Control Plane 을 클러스터링 할 때 절대 짝수개로 두면 안된다.

Control Plane 컴포넌트

kube-apiserver

kube-apiserver ****는 쿠버네티스 API를 노출하는 쿠버네티스 컨트롤 플레인 컴포넌트이다.

모든 통신은 kube-apiserver 을 통해 통신이 된다.

쿠버네티스 API 서버의 주요 구현은 kube-apiserver 이다. kube-apiserver는 수평으로 확장되도록 디자인되었다. 즉, 더 많은 인스턴스를 배포해서 확장할 수 있다. 여러 kube-apiserver 인스턴스를 실행하고, 인스턴스간의 트래픽을 균형있게 조절할 수 있다.

kube-controller-manager

쿠버네티스 핵심으로 쿠버네티스 전체를 관리한다.

쿠버네티스는 컨테이너를 관리하지 않는다.

쿠버네티스는 Pod 를 관리하고, Pod 는 컨테이너가 아니다.

컨트롤러는 다음을 포함한다.

노드 컨트롤러: 노드가 다운되었을 때 통지와 대응에 관한 책임을 가진다.
레플리케이션 컨트롤러: 시스템의 모든 레플리케이션 컨트롤러 오브젝트에 대해 알맞은 수의 파드들을 유지시켜 주는 책임을 가진다. (쿠버네티스의 핵심은 컨테이너의 복제이다.)
엔드포인트 컨트롤러: 엔드포인트 오브젝트를 채운다(즉, 서비스==Network(LB) 와 파드를 연결시킨다.)
서비스 어카운트 & 토큰(인증) 컨트롤러: 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰을 생성한다.

cloud-controller-manager

쿠버네티스가 클라우드에 있을 경우(EKS, AKS, GKE), 클러스터를 클라우드 공급자의 API에 연결하고, 해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와만 상호 작용하는 컴포넌트를 구분할 수 있게 해 준다.

kube-scheduler

노드가 배정되지 않은 새로 생성된 Pod 를 감지하고, 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트이다.

즉, Pod 를 어느 노드에 어떻게 배치할 것인지 설정해준다.

etcd(etc daemon)

모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 key value 스토리지이다.(DB)

쿠버네티스 클러스터에서 etcd를 뒷단의 저장소로 사용한다면, 이 데이터를 백업하는 계획은 필수이다.

Node 컴포넌트

**kubelet

클러스터의 각 노드에서 실행되는 에이전트이다. Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리한다.

kube-apiserver 에 컨테이너를 만들어달라고 요청을 보내면 kubelet 이 파드를 만들고 파드에서 컨테이너가 동작하도록 한다.

kube-proxy

docker proxy 는 네트워크의 정책(iptables 정책)을 관리한다. 예를 들어 포트 포워딩 할 때 이 녀석을 사용한다.

kube-proxy 도 똑같이 네트워크 정책을 담당한다.

쉽게 얘기하자면 kubelet 은 컨테이너를 담당하는 녀석이고, kube-proxy 는 네트워크를 담당하는 녀석이다.

Control Plane 의 컴포넌트들도 모두 컨테이너이기 때문에 해당 컨테이너를 관리하는 kubelet 과 kube-proxy 가 Control Plane 에도 존재한다.

애드온

기본적으로 쿠버네티스가 하지 못하는 작업들이 많다.. 배포, 모니터링 등..

그래서 쿠버네티스에 추가 기능을 붙여서 하지 못한 작업들을 할 수 있게 한다.

최소한 아래 3개 애드온은 구성해줘야 한다.

DNS 애드온

애드온이지만 거의 필수불가결적으로 사용해야 한다.

kube-dns 라고 부른다. 쿠버네티스 내부에서 DNS 서비스를 갖춰준다.

모든 쿠버네티스는 클러스터 DNS(Service Discovery) 를 갖춰야 한다. 이 클러스터 DNS 는 docker compose 에서 컨테이너의 이름으로 다른 네트워크를 찾아가거나 호스트 이름으로 사용할 수 있던 것처럼 클러스터 내부에서도 이와 동일한 기능을 하도록 해주는 녀석이다.

쉽게 말해서 컨테이너가 다른 컨테이너를 어떻게 찾을지 정해주는 녀석이다. 즉, 이 kube-dns 는 클러스터 내부에서 다른 컨테이너들을 찾을 수 있게 해주는 녀석이다.

컨테이너 리소스 모니터링 애드온

컨테이너 리소스 모니터링은 중앙 데이터베이스 내의 컨테이너들에 대한 포괄적인 시계열 매트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다.

클러스터-레벨 로깅

클러스터-레벨 로깅 메커니즘은 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 진다.