1. 쿠버네티스 등장 배경

컨테이너 기술이 가벼운 가상화, 일관성 있는 환경 등 좋은 기술인 것은 컨테이너를 통해 배포해 본 개발자라면 모두 느낄 것이다.
하지만 관리해야 할 컨테이너가 많다면?
예를 들어 서버가 3개 있다면, 각각의 서버에 접속해서 docker run을 해줘야한다.
100개, 1000개라면?
버전 관리를 하려면? 전체 컨테이너를 바꿔줘야 한다.
버전이 이상해서 다시 롤백해야 하면? 전체 컨테이너를 바꿔줘야 한다.
컨테이너의 로드밸런싱을 할 때, 아이피를 설정하고 서비스 검색 작업들이 많아지면?
nginx와 같이 public ip를 두고 서버 내부로 연결하기 위해서 설정 파일을 직접 작성해야하기 귀찮다..
서비스 이상, 부하 모니터링은 어떻게 할까? (모니터링 도구를 계속 쳐다보기엔.. 새벽에는?..)

2. 컨테이너 오케스트레이션 플랫폼

복잡한 컨테이너 환경을 효과적으로 관리하기 위한 플랫폼이다.
즉, 컨테이너를 쉽고 빠르게 배포, 확장하고 관리를 자동화해주는 도구이다.

그리고 도커 스웜, 노마드 등 많은 컨테이너 오케스트레이션이 존재한다.(춘추전국시대)

당연히 의문이 생긴다.
왜 쿠버네티스를 많이 쓰는 걸까?

우선 쿠버네티스의 시작점은 구글의 내부적인 컨테이너 배포 시스템 borg에서 시작되었다.
구글은 1주일에 20억개의 컨테이너를 생성하고, 내부적으로 borg를 통해 관리했다.
쿠버네티스는 borg를 기반으로 만들어진 오픈소스이다. (지금은 구글 소속이 아니다.)

3. 쿠버네티스를 많이 쓰는 이유

• 오픈 소스이다. 또한 쟁쟁한 기업이 참여했고, 커뮤니티가 발달해있다.
• 인프라를 돌리기 위해서 필요한 라이브러리는 왠만하면 다 존재한다.
• 무한한 확장성. Kubeflow(머신러닝), TEKTON(CI/CD), 서비스메시, 서버리스 등 다양한 프로그램들이 쿠버네티스 위에서 동작하고 있다. 하나의 플랫폼으로써 자리 잡았다.
• 사실상의 표준. (데 팍토)
  • 아마존, Azure, Google 등 매니지먼트 쿠버네티스를 지원한다.

4. 쿠버네티스 기본 개념

[ 개요 ]

• k8s는 여러 서버로 구성된 클러스터 환경에서 컨테이너화 된 프로세스를 관리하기 위한 Container Orchestration
• 컨테이너 방식은 가상 머신 방식과 다르게 host OS를 공유한다.
• 사용자는 개별 노드(서버)를 직접 제어하지 않고 k8s라는 추상화된 레이어를 통해 클러스터를 제어한다.
• 쿠버네티스는 모든 서버들을 Master / Worker 노드로 구분한다.

[ Desired State ]

• 바라는 상태라는 개념이 있다.
• YAML 형식과 같이 Desired State를 선언하면, Current State 체크해서 반영한다.

[ Controller ]

• 현재 상태를 Desired Stats로 변경하는 주체이다.
• control-loop 라는 루프를 돌며 특정 리소스를 지속적으로 모니터링한다.
• 사용자가 생성한 리소스의 이벤트에 따라 사전에 정의된 작업을 수행한다.
• 하나의 쿠버네티스 리소스는 하나의 컨트롤러를 가진다.

[k8s resource ]

• k8s는 모든 것을 리소스로 표현
• Pod / ReplicaSet / Deployment / Service / Ingress 등 다양한 리소스 존재

[ 선언형 커맨드 ]

• k8s는 사용자가 직접 시스템의 상태를 바꾸지 않고, 바라는 상태(Desired State)를 선언적으로 기술하여 명령을 내리는 선언형(Declarative) 커맨드 방식을 지향한다.
• k8s 리소스를 YAML 정의서(description) 형식으로 구성한다.
  • apiVersion
  • kind : Pod, Deployment, Service, Ingress …
  • metadata
  • spec : 각종 설정
  • status (read-only) : 시스템에서 관리하는 최신 상태
• 원하는 상태 (Desired State)를 다양한 오브젝트로 정의(spec)하고 API 서버에 YAML 형식으로 전달한다.

[ Namespace ]

• 클러스터를 논리적으로 분리하는 개념
• default : 기본 네임스페이스
• kube-system : 쿠버네티스의 핵심 컴포넌트들이 들어있는 네임스페이스
• kube-public : 외부로 공개 가능한 리소스가 들어있는 네임스페이스
• kube-node-lease : 노드가 살아있는지 Master에게 알리는 용도로 존재하는 네임스페이스

[ Label & Selector ]

• Label : k8s 리소스에 존재하는 key-value 형식의 태그 정보
• Selector : 태깅한 Label을 찾기 위한 것
• Label & Selector를 이용한 매커니즘을 통해 k8s 리소스간 관계를 느슨하게 연결 가능
• 특정 리소스(또는 리소스 그룹)에 명령을 전달하거나 정보를 확인하고 싶을 때 라벨링 시스템을 이용한다.

[ Service Discovery ]

• 사용자가 서비스에 접근하기 위해 Endpoint의 접속 정보를 탐색하는 것
• 동일하게, 클러스터 내에서 각 노드에 상관 없이 통신하기 위해서는 서비스 Endpoint가 필요
• k8s에서는 DNS 기반의 서비스 탐색 지원 -> Service라는 k8s 리소스를 통해 지원

[ 설정 관리 ]

• k8s에서는 컨테이너를 실행할 때 필요한 설정값 및 credentials를 플랫폼 레벨에서 관리하는 매커니즘 제공
• ConfigMap / Secret 리소스를 통해 컨테이너의 설정 관리

[ Master ]

• Manage, Plan, Sechdule, Monitor Nodes
• 마스터는 단일 서버로 구성될 수도 있고, 고가용성을 위해 여러 서버로(클러스터 마스터) 구성될 수도 있다.
• 핵심 컴포넌트
  • kube-apiserver : 마스터로 전달되는 모든 요청을 받는 REST API 서버
  • etcd : 클러스터 내 모든 메타 정보를 저장하는 저장소
  • kube-scheduler : 사용자 요청에 따라 적절하게 컨테이너를 워커 노드에 배치하는 스케줄러
  • kube-controller-manager : 현재 상태와 바라는 상태를 지속적으로 확인하며 특정 이벤트에 따라 특정 동작을 수행하는 컨트롤러
  • cloud-controller-manager : 클라우드 플랫폼(AWS / GCP / Azure)에 특화된 리소스를 제어하는 클라우드 컨트롤러

kube-apiserver

• 클러스터 내에서 모든 작업을 조율한다. (상태를 바꾸거나 조회)
• etcd와 유일하게 통신하는 모듈이다.
• 권한을 체크하여 적절한 권한이 없을 경우 요청을 차단
• 관리자 요청 뿐 아니라 다양한 내부 모듈과 통신한다.
• Kubelet으로 부터 주기적으로 상태 보고저를 가져온다. -> 노드, 컨테이너 상태 모니터링

etcd

• Key-Value 형태의 데이터베이스 -> 모든 상태와 데이터를 저장한다.
• 분산 시스템으로 구성하여 안전성을 높임 (고가용성)
• 가볍고 빠르면서 정확하게 설계 (일관성)
• TTL(Time To Live), Watch같은 부가 기능 제공

kube-scheduler

• 새로 생성된 Pod을 감지하고 실행할 노드를 선택
• 워커 노드의 현재 상태와 Pod의 요구사항을 체크 (컨테이너 리소스 요구 사항, 워커 노드 요량, 등)

controller-manager

• 논리적으로 다양한 컨트롤러가 존재한다.
  • replication-controller
  • node-controller
  • endpoint controller 등등
• 끊임 없이 상태를 체크하고 원하는 상태를 유지
• 복잡성을 낮추기 위해 하나의 프로세스로 실행

[ Worker Nodes ]

• Host Application as Containers
• 워커 노드에 위치하여 마스터로부터 명령을 전달받아 컨테이너를 실제로 실행시키는 주체(kubelet)가 존재한다.
• 컨테이너가 정상적으로 실행 될 수 있도록 도와주는 네트워크 프록시(kube-proxy)와 실행환경(runtime)도 존재한다.
• 구성
  • kubelet : 각 워커 노드마다 위치하여 마스터의 명령에 따라 컨테이너의 라이프사이클을 관리하는 노드 관리자
  • kube-proxy : 컨테이너의 네트워킹을 책임지는 프록시
  • container runtime : 실제 컨테이너를 실행하는 컨테이너 실행 환경

kubelet

• 클러스터의 각 노드에서 실행되는 에이전트
• 마스터로부터 특정 컨테이너를 실행시키기 위해 상세 명세(spec)을 받아 실행
• kube-apiserver의 지시를 듣고 필요한대로 노드에서 컨테이너를 배포하거나 파괴한다.

kube-proxy

• 각 노드에 위치하여 k8s 서비스 네트워킹을 담당하는 컴포넌트
• 서비스마다 개별 IP를 가지도록 구성
• 성능상의 이유로 별도의 프록시 프로그램 대신 iptables 또는 IPVS를 사용 (설정만 관리)
• 내/외부의 트래픽을 Pod으로 전달할 수 있도록 패킷을 라우팅

container-runtime

• 실제 컨테이너를 실행하기 위한 환경
• CRI(Container Runtime Interface)규약을 따르면 k8s의 컨테이너 런타임으로 사용이 가능하다. -> 일반적으로 Docker 많이 사용
  

출처
https://subicura.com/k8s/guide/
https://www.youtube.com/watch?v=d6WC5n9G_sM
https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/