CKA를 따기 위한 공부 여정을 블로그에 기록하려고 한다,,,! 그 첫 번째 쿠버네티스란 무엇인지 알아보자!

0. 컨테이너 환경?

먼저 쿠버네티스에 대하여 알기 전에 컨테이너 환경에 대하여 알 필요가 있다. 컨테이너는 VM(가상머신)과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 OS를 공유한다. 그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다. 쉽게 말해 가상화 환경보다 더 많이 애플리케이션을 실행가능하게 해준다는 뜻이다.

1. 쿠버네티스란?

쿠버네티스란 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다. 자동화를 용이하게 하고 크고 빠르게 성장하는 생태계를 가지고 있다. 쉽게 말해 여러 개의 컨테이너들을 잘 운영하고 문제가 생기면 도와준다,,!

1-1. 쿠버네티스의 구성요소

• 파드: 파드란 하나의 일을 하기 위해 묶여진 컨테이너의 집합을 의미한다. 이 그룹은 스토리지 및 네트워크를 공유하고 컨테이너를 구동하는 방식에 대한 명세를 갖는다. 파드의 콘텐츠는 항상 함께 배치되고, 함께 스케줄되며, 공유 콘텍스트에서 실행된다.

• Kube-apiserver: 쿠버네티스에서 kube-apiserver는 쿠버네티스의 중심이라 해도 과언이 아니다. Kube-apiserver 수평으로 확장되도록 디자인되었다. 즉 더 많은 인스턴스를 배포해서 확장 가능하고 여러 Kube-apiserver 인스턴스를 실행, 생성하고 인스턴스 간 트래픽을 균형있게 조절할 수 있다.
  (이미지 출처: https://blog.heptio.com/core-kubernetes-jazz-improv-over-orchestration-a7903ea92ca)
  

위와 같이 Pod 생성 시 kube-apiserver가 하는 일을 보면,,,
1) kubectl create pods 명령어 입력
2) Kube-apiserver에서 컨트롤러 매니저에게 파드 생성 요청
3) Kube-apiserver가 컨트롤러 감시
4) 스케줄러가 api 서버에 와서 값을 보고 워커 노드 스케줄, api 서버가 스케줄러 감시
5) api 서버가 kubelet 파드와 동작 관리
6) 도커 컨테이너 런터임을 거쳐 컨테이너 생성
7) kubelet 파드 상태 정보를 Kube-apiserver 서버에 전달
8) 파드 생성 및 사용 가능
파드 생성 과정만 봐도 Kube-apiserver가 쿠버네티스의 중심인 걸 알 수 있다. API 서버는 json, protobuf 형식을 사용하여 http 통신을 지원하지만 편하게 사용하기 위해 주로 kubectl 이라는 CLI 도구를 사용한다.

• Etcd: 모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성, 고가용성 키 값 저장소 etcd는 더욱 안전한 자동 업데이트를 지원하고, 호스트에 스케줄링되는 작업을 조정하며 컨테이너에 대한 오버레이 네트워킹(서로다른 분산 네트워크 인프라를 봉합하는 논리적 구조) 설정을 지원한다

• Kube-Controller-manager: 컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트. 컨트롤러는 노드, 잡, 엔드포인트 등의 컨트롤러로 구성되있는 집합이다. 논리적으로 각 컨트롤러는 분리된 프로세스이지만 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행된다.

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

1-2. 쿠버네티스가 하는 일

그러면 쿠버네티스가 위와 같은 구성요소를 가지고 무엇을 할까? 가장 대표적인 예로 실행 중인 컨테이너가 장애가 생겨서 다른 컨테이너로 빠르게 대처해야하는 경우 개발자가 24시간 모니터링을 하면서 직접 장애에 대한 조치를 수행하면 좋지만,,, 인력과 비용에 대한 문제가 발생하기 때문에 시스템에 의해 처리하여 조치하는 것이 더 현명한 선택이다! 쿠버네티스는 이러한 일을 한다! 아래를 좀 더 살펴보면

• 서비스 디스커버리와 로드 밸런싱: kubectl get pods -o wide 명령어를 입력하면 각 마스터, 워커 노드의 IP 등이 출력되는데 쿠버네티스는 DNS 이름을 사용하거나 노드들의 자체 IP 주소를 사용하여 컨테이너를 노출 할 수있다. 또한, 컨테이너에 대한 트래픽이 많으면 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어 질 수 있다.

• 스토리지 오케스트레이션: 쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재할 수 있다.

• 자동화 된 롤아웃과 롤백: 쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태로 설정가능하며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경이 용이하다. 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고 모든 리소스를 새 컨테이너에 적용 할 수 있다.

• 자동화 된 복구: 쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다. 마스터 노드에 대한 복구 능력이 굉장하다,,,거의 좀비 수준,,,,(후에 다양한 실패 상황에 대한 게시글에서 작성하겠다!)

2. 쿠버네티스의 핵심 설계 원칙

쿠버네티스 핵심 설계 원칙 중에 가장 중요한 것은 선언적 구성이다. 이게 무슨 말이냐 하면
예를 들어 "우리 매장 진열대 상품은 항상 5개여야해" 로 동작을 지시하는 것이 아닌 원하는 상태를 선언하는 개념을 주로 사용한다. 쿠버네티스는 현재의 상태가 사용자가 원하는 상태와 일치하는지 지속적으로 감시하고 체크하고 업데이트 한다. 따라서 내가 원하는 상태를 선언하는 것만으로 현재 리소스 상태를 내가 원하는 리소스 형태로 배포되거나 유지된다. (쏘 편리,,,)

Reference:

https://kubernetes.io/ko/docs/concepts/overview/
https://kubernetes.io/ko/docs/concepts/overview/components/
https://velog.io/@whattsup_kim/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4kubernetes%EB%9E%80
https://www.arubanetworks.com/ko/faq/what-is-a-network-overlay/
https://www.redhat.com/ko/topics/containers/what-is-etcd