쿠버네티스란?
- 2014년에 쿠버네티스 프로젝트를 오픈소스화
- 쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다.
- 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다.
- 전통적인 배포 시대
- 물리 서버에서 실행
- 한 물리 서버에서 여러 애플리케이션의 리소스 한계를 정의할 방법이 없었기에, 리소스 할당의 문제가 발생
- 가상화된 배포 시대
- 단일 물리 서버의 CPU에서 여러 가상 시스템 (VM)을 실행할 수 있게 한다.
- 다른 애플리케이션에서 자유롭게 액세스 할 수 없으므로, 일정 수준의 보안성을 제공
- 컨테이너 개발 시대
- 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유
- VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있다
- 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다.
장점
- 기민한 애플리케이션 생성과 배포 : VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임
- 지속적인 개발, 통합 및 배포 : 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 효율적으로 롤백할 수 있다.
- 개발과 운영의 관심사 분리 : 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리
- OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
- 개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다.
- 클라우드 및 OS 배포판 간 이식성: Ubuntu, RHEL, CoreOS, 온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동된다.
- 애플리케이션 중심 관리: 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS 상에서 애플리케이션을 실행하는 수준으로 추상화 수준이 높아진다.
- 느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스: 애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로 구동되지 않고 보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 관리될 수 있다.
- 리소스 격리: 애플리케이션 성능을 예측할 수 있다.
- 자원 사용량: 리소스 사용량: 고효율
쿠버네티스가 필요한 이유?
- 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 무중단 배포를 할수 있다.
쿠버네티스가 제공하는 기능
- 서비스 디스커버리
- 쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다. - 로드 밸런싱
- 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다.
- 스토리지 오케스트레이션
- 쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재 할 수 있다.
- 자동화된 롤아웃과 롤백
- 쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다. 예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다.
- 자동화된 빈 패킹(bin packing)
- 컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 지시한다. 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해준다.
- 자동화된 복구(self-healing)
- 쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
- 시크릿과 구성 관리
- 쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.
Kubernetes 구성
마스터 구성요소
마스터 구성요소들은 실질적으로 클러스터의 전체적인 관리를 하는 것들입니다. etcd, kube-apiserver, kube-scheduler, kube-controller-manager, cloud-controller-manager등이 마스터 구성요소입니다.
ETCD
etcd는 고가용성을 제공하는 키-밸류(key-value) 저장소입니다. 쿠베네티스에서 필요한 모든 데이터를 저장하는 실질적인 데이터베이스입니다. 원래 쿠버네티스는 처음에 구글내부의 보그(borg)라는 컨테이너 오케스트레이션 도구의 오픈소스화를 진행하면서 나왔습니다. 보그가 구글에서 사용될때는 구글 내부의 처비(chubby)라는 분산 저장 솔루션을 사용했었습니다. 이와 비슷한 솔루션을 사용하기 위해서 쿠버네티스로 오픈소스화할때 etcd를 사용하게 되었습니다. etcd는 프로세스 1개만 띄워서 사용할수도 있지만 데이터의 안정성을 위해서는 여러개의 장비에 분산해서 etcd자체를 클러스터링을 구성해서 띄우는게 일반적인 방법입니다. etcd가 안정적이기는 하지만 보다 안정적으로 쿠버네티스를 운영하려면 주기적으로 etcd에 있는 데이터를 백업해 두는게 좋습니다.
kube-apiserver
쿠버네티스는 MSA(마이크로서비스아키텍처, Micoro Service Architecture) 구조로 되어 있습니다. 그래서 여러개의 분리된 프로세스로 구성되어 있습니다. 그중에서 kube-apiserver는 쿠버네티스 클러스터의 api를 사용할수 있게 해주는 프로세스입니다. 클러스터로 요청이 왔을때 그 요청이 유효한지 검증하는 역할을 합니다. 쿠버네티스로의 모든 요청은 kube-apiserver를 통해서 다른 곳으로 전달되도록 되어 있습니다. kube-apiserver는 수평적으로 확장이 가능하게 설계가 되어 있어서, 여러대의 장비에 여러개를 띄워놓고 사용할 수 있습니다. kube-apiserver를 실행할때 사용할 수 있는 다양한 옵션은 다음과 같습니다.
kube-scheduler
kuber-scheduler는 이름에서 알 수 있듯이 새로운 포드들이 만들어질때 현재 클러스터내에서 자원할당이 가능한 노드들 중에서 알맞은 노드를 선택해서 그곳에 포드를 띄우는 역할을 합니다. 포드는 처음 실행될때 여러가지 조건을 지정해서 실행하는데, kube-scheduler가 그 조건에 맞는 노드를 찾아주는 역할을 합니다. 필요한 하드웨어 요구사항이라던가, 어피니티/안티어피니티(affinity/anti-affinity) 조건을 만족하는지, 특정 데이터가 있는 노드에 할당한다던가 하는 다양한 설정을 할 수 있습니다.
kube-controller-manager
쿠버네티스는 각각의 컨트롤러(controller)들이 포드들을 관리하는 역할을 합니다. kube-controller-manager는 이런 각각의 컨트롤러들을 실행하는 역할을 합니다. 각 컨트롤러들은 논리적으로는 개별 프로세스이지만 복잡도를 줄이기 위해서 하나의 바이너리 파일로 컴파일되어 있고, 하나의 단일 프로세스로 실행됩니다. 쿠버네티스는 golang언어로 개발되어 있는데, 클러스터내에서 새로운 컨트롤러가 사용될때는 그 컨트롤러에 해당하는 구조체가 만들어진 다음에 그걸 kube-controller-manager가 관리하는 큐에 넣어서 실행하는 방식으로 작동합니다.
노드 컨트롤러: 노드가 다운되었을 때 통지와 대응에 관한 책임을 가진다.
레플리케이션 컨트롤러: 시스템의 모든 레플리케이션 컨트롤러 오브젝트에 대해 알맞은 수의 파드들을 유지시켜 주는 책임을 가진다.
엔드포인트 컨트롤러: 엔드포인트 오브젝트를 채운다(즉, 서비스와 파드를 연결시킨다.)
서비스 어카운트 & 토큰 컨트롤러: 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰을 생성한다.
cloud-controller-manager
cloud-controller-manager 는 클라우드 서비스를 제공해 주는 곳들에서 쿠버네티스의 컨트롤러들을 자신들의 서비스와 연계해서 사용하기 위해서 사용합니다. 관련된 코드는 각 클라우드 서비스 제공사들에서 직접 관리하도록 되어 있습니다. 다음 4가지 컨트롤러들이 관련있는 컨트롤러들입니다.
노드 컨트롤러(Node Controller) : 클라우드 서비스 내에서 노드를 관리하기 위해서 사용합니다.
라우트 컨트롤러(Route Controller) : 각 클라우드 인프라내에서의 네트워크 라우팅을 관리하는데 사용합니다.
서비스 컨트롤러(Service Controller) : 각 클라우드 서비스에서 제공하는 로드밸런서를 생성/갱신/삭제하는데 사용합니다.
볼륨 컨트롤러(Volume Controller) : 클라우드 서비스에서 볼륨을 생성해서 노드에 붙이고 마운트해서 볼륨을 관리하는데 사용합니다.
노드 구성요소
노드 구성요소는 모든 노드에서 실행되면서, 각 노드에서 포드가 실행되는걸 관리하고 쿠버네티스 실행환경을 관리하는 역할을 합니다. kubelet, kube-proxy, 컨테이너 런타임 등이 있습니다.
kubelet
kubelet은 클러스터내의 모든 모드에서 실행되는 에이전트 입니다. 포드내의 컨테이너들이 실행되는걸 직접적으로 관리하는 역할을 합니다. kubelet은 PodSpecs라는 설정을 받아서 그 조건에 맞게 컨테이너를 실행하고 컨테이너가 정상정으로 실행되고 있는지 상태 체크를 진행합니다. 노드안에 있는 컨테이너라고 하더라도 쿠버네티스가 만들지 않은 컨테이너는 관리하지 않습니다.
kube-proxy
쿠버네티스는 클러스터 내부에 별도의 가상 네트워크를 설정하고 관리합니다. kube-proxy는 이런 가상 네트워크가 동작할 수 있게 하는 실질적인 역할을 하는 프로세스입니다. 호스트의 네트워크 규칙을 관리하거나 커넥션 포워딩을 하기도 합니다.
컨테이너 런타임(Container Runtime)
컨테이너 런타임은 실제로 컨테이너를 실행시키는 역할을 합니다. 가장 많이 알려진 런타임으로는 도커(Docner)가 있고, 그외 rkt, runc같은 런타임도 지원합니다. 그외에도 컨테이너에 관한 표준을 제정하는 역할을 하는 OCI(Open Container Initiative, https://www.opencontainers.org/)의 런타임 규격(runtime-spec)을 구현하고 있는 컨테이너 런타임이라면 쿠버네티스에서 사용할 수 있습니다.
애드온(Addons)
애드온은 클러스터 내부에서 필요한 기능들을 위해 실행되는 포드들입니다. 애드온에 사용되는 포드들은 디플로이먼트, 리플리케이션컨트롤러등에 의해 관리됩니다. 애드온이 사용하는 네임스페이스는 kube-system입니다. 애드온에는 몇가지 종류들이 있습니다.
네트워킹 애드온
쿠버네티스는 클러스터 내부에 가상네트워크를 구성해서 사용하는데, 이때 kuby-proxy이외에 네트워킹 관련한 애드온을 사용합니다. AWS, 애저, 구글클라우드같은 클라우드 서비스에서 제공하는 쿠버네티스를 사용한다면 별도의 네트워킹 애드온을 사용하지 않더라도 각 클라우드 벤더에서 구현하고 있으니 신경쓰지 않아도 됩니다. 하지만 쿠버네티스를 직접 보유중인 서버들에 설치해서 구성을 하려고 하려면 네트워킹 관련 애드온을 설치해서 사용해야합니다. 이 부분이 쿠버네티스를 직접 설치할때 가장 까다로운 부분이기도 합니다. 네트워킹 애드온의 종류는 10개가 넘을 정도로 다양하게 있습니다. ACI, Calico, Canal, Cilium, CNI-Genie, Contiv, Falannel, Multus, NSX-T, Nuage, Romana, Weave Net등이 있고, OCI의 CNI(Container Network, Interface) 를 구현하고 있다면 다른 애드온들도 사용할 수 있습니다.
DNS 애드온
DNS 애드온의 경우 실제로 클러스터 내에서 작동하는 DNS 서버입니다. 쿠버네티스 서비스들에 DNS 레코드를 제공하는 역할을 합니다. 쿠버네티스 내부에서 실행된 컨테이너들은 자동으로 DNS서버에 등록됩니다. dns 서비스로는 kube-dns와 core-dns가 있습니다.
대시보드 애드온
쿠버네티스를 소개할때 대부분의 경우 kubectl이라는 CLI(Command Line Interface)를 많이 사용합니다. 하지만 웹 UI가 필요한 경우가 있을수도 있는데, 이런경우에 사용할수 있는 대시보드가 있습니다. 보이는 것 처럼 클러스터 현황을 한눈에 쉽게 파악할 수 있습니다.
컨테이너 자원 모니터링
클러스터 내부에서 실행중인 컨테이너의 상태를 모니터링하기 위해서는 cpu, 메모리 같은 필요한 메트릭 데이터들을 시계열형식으로 저장하고 볼수 있는 방법을 제공하는데 필요한 애드온입니다. kubelet안에 cAdvisor라는 컨테이너 모니터링 도구가 포함되어 있는데요. 이 데이터들을 수집해서 사용할 수 있는 힙스터(heapster)를 이용하면 손쉽게 필요한 데이터들을 수집해서 모니터링에 이용할 수 있습니다.
클러스터 로깅
클러스터내의 각 개별 컨테이너에서 나오는 로그와 쿠버네티스 구성요소들에서 나오는 로그들을 중앙화된 로그 수집 시스템에 모아서 볼 수 있습니다. 이것 역시 클라우드 서비스를 이용중이라면 각 클라우드 벤더에서 제공해주는 로깅 서비스들과 잘 연동이 되어 있겠지만, 직접 쿠베네티스를 설치해서 사용할때는 고려해야 하는 요소입니다. 클러스터 내의 각 노드에 로그를 수집하는 포드를 실행해서 한곳으로 로그를 수집하도록 합니다. 로그를 수집해서 제공해주는 역할로는 ELK(ElasticSearch, Logstash, Kibana)를 많이 사용합니다.
