[쿠버네티스 인 액션] 1. 쿠버네티스 소개 (2)

1.3 쿠버네티스 소개

1.3.1 쿠버네티스의 기원

• 오랫동안 구글은 보그(이후로 오메가로 바뀐 시스템)라는 내부 시스템을 개발해 애플리케이션 개발자와 시스템 관리자가 수천 개의 애플리케이션과 서비스를 관리하는 데 도움을 줬다.
• 구글은 10년 간 이 기술을 비밀로 유지하다가 2014년 보그, 오메가, 기타 내부 구글 시스템으로 얻은 경험을 기반으로 오픈소스 시스템인 쿠버테니스를 출시했다.

---

1.3.2 넓은 시각으로 쿠버네티스 바라보기

• 쿠버네티스는 컨테이너화된 애플리케이션을 쉽개 배포하고 관리할 수 있게 해주는 소프트웨어 시스템이다.
• 쿠버네티스를 사용하면 모든 노드가 하나의 거대한 컴퓨터인 것처럼 수천 대의 컴퓨터 노드에서 소프트웨어 애플리케이션을 실행할 수있다.
• 기본 인프라를 추상화하고 개발과 운영 팀 모두의 개발, 배포, 관리를 단순화한다.

쿠버네티스 핵심 이해

• 시스템은 마스터 노드(master node)와 워커 노드(worker node)로 구성된다.
• 개발자가 애플리케이션 매니페스트를 마스터에 게시하면 쿠버네티스는 해당 애플리케이션을 워커 노드 클러스터에 배포한다.
• 구성 요소가 어떤 노드에 배포되는지는 개발자와 시스템 관리자에게 중요하지 않다.
• 개발자는 특정 애플리케이션이 함께 실행되도록 지정할 수도 있으며 쿠버네티스는 여러 애플리케이션을 동일한 워커 노드에 배포한다.

개발자가 애플리케이션 핵심 기능에 집중할 수 있도록 지원

• 쿠버네티스는 서비스 디스커버리, 스케일링, 로드밸런싱, 자가 치유, 리더 선출 같은 인프라 관련 서비스를 제공한다.
• 개발자는 애플리케이션의 실제 기능을 구현하는 데 집중할 수 있으며 인프라와 통합하는 방법을 찾지 않아도 된다.

운영 팀이 효과적으로 리소스를 활용할 수 있도록 지원

• 애플리케이션은 어떤 노드에서 실행되든 상관이 없기 때문에 쿠버네티스는 언제든지 애플리케이션을 재배치하고 조합함으로써 수동 스케줄링보다 리소스를 잘 활용할 수 있다.

---

1.3.3 쿠버네티스 클러스터 아키텍처 이해

하드웨어 수준에서 쿠버네티스 클러스터는 여러 노드로 구성되며, 두 가지 유형으로 나눌 수 있다.

• 마스터 노드는 전체 쿠버네티스 시스템을 제어하고 관리하는 쿠버네티스 컨트롤 플레인을 실행한다.
• 워커 노드는 실제 배포되는 컨테이너 애플리케이션을 실행한다.

컨트롤 플레인

• 컨트롤 플레인은 클러스터를 제어하고 작동시킨다.
• 하나의 마스터 노드에서 실행되거나 여러 노드에 분할되고 복제되어 고가용성을 보장할 수 있는 여러 구성 요소로 구성된다.
• 컨트롤 플레인의 구성요소는 클러스터 상태를 유지하고 제어하지만 애플리케이션을 실행하진 않는다.
• 구성요소
  • 쿠버네티스 API 서버 : 사용자, 컨트롤 플레인 구성 요소와 통신
  • 스케줄러 : 애플리케이션의 배포를 담당 (배포 가능한 각 구성 요소를 워커 노드에 할당)
  • 컨트롤러 매니저 : 구성요소 복제본, 워커 노드 추적, 노드 장애 처리 등과 같은 클러스터 단의 기능 수행
  • etcd : 클러스터 구성을 지속적으로 저장하는 신뢰할 수 있는 분산 데이터 저장소

노드

• 워커 노드는 컨테이너화된 애플리케이션을 실행한다.
• 애플리케이션의 실행, 모니터링, 서비스 제공 작업은 다음 구성요소에 의해 실행된다.
  • 컨테이너를 실행하는 도커, rkt 또는 다른 컨테이너 런타임
  • API 서버와 통신하고 노드의 컨테이너를 관리하는 Kubelet
  • 애플리케이션 구성 요소 간에 네트워크 트래픽을 로드밸런싱하는 쿠버네티스 서비스 프록시(kube-proxy)

---

1.3.4 쿠버네티스에서 애플리케이션 실행

• 쿠버네티스에서 애플리케이션을 실행하려면 먼저 애플리케이션을 하나 이상의 컨테이너 이미지로 패키징하고 해당 이미지를 이미지 레지스트리로 푸시한 다음 쿠버네티스 API 서버에 애플리케이션 디스크립션을 게시해야한다.
• 이 디스크립션에는 컨테이너 이미지, 애플리케이션 구성 요소가 포함된 이미지, 해당 구성 요소가 서로 통신하는 방법, 동일 서버에 함께 배치되어야 하는 구성 요소와 같은 정보가 포함된다.

디스크립션으로 컨테이너를 실행하는 방법 이해

• API 서버가 애플리케이션 디스크립션을 처리할 때 스케줄러는 각 컨테이너에 필요한 리소스를 계산하고 해당 시점에 각 노드에 할당되지 않은 리소스를 기반으로 사용 가능한 워커 노드에 지정된 컨테이너를 할당한다.
• 그런 다음 해당 노드의 Kubelet은 컨테이너 런타임(ex. Docker)에 필요한 컨테이너 이미지를 가져와 컨테이너를 실행하도록 지시한다.

실행된 컨테이너 유지

• 애플리케이션이 실행되면 쿠버네티스는 애플리케이션의 배포 상태가 사용자가 제공한 디스크립션과 일치하는지 지속적으로 확인한다.
• 프로세스가 중단되거나 응답이 중지될 때와 같이 인스턴스가 제대로 작동하지 않으면 쿠버네티스가 자동으로 다시 시작한다.
• 워커 노드 전체가 종료되거나 액세스 할 수 없게 되면 쿠버네티스는 실행중인 모든 컨테이너의 노드를 새로 스케쥴링하고, 새로 선택한 노드에서 실행한다.

복제본 수 스케일링

• 애플리케이션이 실행되는 동안 복제본 수를 늘리거나 줄일지 결정할 수 있으며 최적의 복제본 수를 결정하는 작업을 쿠버네티스에 맡길 수도 있다.
• CPU 부하, 메모리 사용량, 초당 요청 수, 애플리케이션이 노출하는 다른 메트릭과 같은 실시간 메트릭을 기반으로 복제본 수를 자동으로 조절할 수 있다.

이동한 애플리케이션에 접근하기

• 외부 클라이언트나 다른 컨테이너에 서비스를 제공하는 컨테이너가 클러스에서 지속적으로 이동한다면 어떻게 접근할 수 있을까?
• 클라이언트가 특정 서비스를 제공하는 컨테이너를 쉽게 찾을 수있도록 쿠버네티스에게 동일한 서비스를 제공하는 컨테이너를 알려주면 쿠버네티스는 하나의 고정 IP 주소로 모든 컨테이너를 노출하고 해당 주소를 클러스터에 실행중인 모든 애플리케이션에 노출한다.
• kupe-proxy는 서비스를 제공하는 모든 컨테이너에 서비스 연결이 로드밸런싱되도록 한다.

---

1.3.5 쿠버네티스 사용의 장점

애플리케이션 배포의 단순화

• 모든 워커 노드를 하나의 배포 플랫폼으로 제공하기 때문에 애플리케이션 개발자는 자체적으로 애플리케이션 배포를 시작할 수 있으며 클러스터를 구성하는 서버에 관해 알 필요가 없다.
• 애플리케이션이 특정 종류의 하드웨어에서 실행하는 경우 쿠버네티스를 통해 해당 하드웨어가 있는 노드를 선택하도록 지시할 수 있다.

하드웨어 활용도 높이기

• 애플리케이션의 리소스 요구사항에 대한 디스크립션과 각 노드에서 사용 가능한 리소스에 따라 애플리케이션을 실행할 가장 적합한 노드를 선택할 수 있다.
• 애플리케이션 구성 요소가 많고 배포할 서버 노드가 많은 경우와 같이, 가능한 옵션의 수가 많을수록 활용도가 높아진다.

상태 확인과 자가 치유

• 애플리케이션 구성 요소와 애플리케이션을 구동 중인 노드를 모니터링하다가 장애 발생 시 자동으로 애플리케이션을 다른 노드로 스케줄링한다.

오토 스케일링

• 각 애플리케이션에서 사용하는 리소스를 모니터링하고 각 애플리케이션의 실행중인 인스턴스 수를 조정하도록 지시할 수 있다.

애플리케이션 개발 단순화

• 개발과 프로덕션 환경이 동일하여 빠르게 버그를 발견하고 해결할 수 있다.
• 클러스터된 애플리케이션에서 서비스나 피어를 검색하는 기능을 포함하여 개발자가 일반적으로 구현해야할 기능을 대신 수행한다.
• 새로운 버전의 애플리케이션을 출시할 때 새로운 버전이 잘못됐는지 자동으로 감지하고 즉시 롤아웃을 중지하므로 개발자들의 신뢰성이 증가하고, 애플리케이션의 지속적인 전달을 가속화한다.