쿠버네티스(Kubernetes)
쿠버네티스 혹은 큐브라고 한다. Linux 컨테이너 작업을 자동화하는 오픈소스 플랫폼을 뜻한다. 컨테이너화된 애플리케이션을 배포하고 확장하는 데 수동프로세스가 필요하지 않다. 리눅스 컨테이너를 실행하는 호스트 그룹을 함께 클러스터링 할 수 있고 쿠버네티스를 통해 이러한 클러스터를 쉽고 효율적으로 관리할 수 있다. 클러스터는 퍼블릭 클라우드, 프라이빗 클라우드 또는 하이브리드 클라우드 전체로 호스트를 확장할 수 있다. 아파치 카프카를 통한 실시간 데이터 스트리밍과 같이 신속한 확장을 요하는 클라우드 네이티브 애플리케이션을 호스팅하는 데 이상적인 플랫폼이다.
기능
워크로드를 위해 규모에 알맞는 컨테이너를 배포하는 데 필요한 오케스트레이션(컴퓨터 시스템, 애플리케이션, 서비스의 자동화된 설정, 관리, 조정을 의미) 및 관리 기능을 제공한다. 여러 컨테이너를 걸쳐 애플리케이션 서비스를 구축하고 클러스터 전체에서 컨테이너의 일정을 계획하고 이러한 컨테이너를 확장하여 컨테이너의 상태를 지속 관리할 수 있다. IT 보안을 한층 강화할 수 있다.
컨테이너를 포드(pod)로 분류하여 컨테이너 급증과 관련된 여러 가지 문제를 해결한다. 포드는 그룹화된 컨테이너에 추상화 계층을 추가하므로 네트워킹, 저장소와 가은 필수 서비스를 컨테이너에 제공할 수 있다. 쿠버네티스의 또 다른 부분을 이용해 포드 전체에서 부하를 분산하고 적합한 수의 컨테이너를 실행하여 워크로드를 지원할 수 있다.
여러 호스트에 걸쳐 컨테이너를 오케스트레이션한다.
애플리케이션을 실행하는 데 필요한 리소스를 극대화한다.
애플레케이션 배포 및 업데이트를 제어하고 자동화한다.
배포한 애플리케이션이 항상 배포 목적대로 실행되도록 한다.
자동화된 롤아웃 롤백: 애플리케이션 변경시 점진적으로 롤아웃하는 동시에 모든 인스턴스가 동시에 종료되지 않도록 보장한다.
서비스 토폴로지: 클러스트 토폴로지를 기반으로 서비스 트래픽 라우팅
시크릿과 구성 관리: 사용자 이미지를 다시 빌드하거나 스택 구성의 시크릿을 노출하지 않고 시크릿과 애플리케이션 구성을 배포하고 업데이트한다.
배치 실행: 서비스 외에도 배치와 CI 워크로드를 관리할 수 있고 실패한 컨테이너를 교체할 수도 있다.
Horizontal 스케일링: 명렁어나 UI를 통해서 자동으로 애플리케이션의 스케일 업다운을 한다.
서비스 디스커버리와 로드 밸런싱: pod에게 고유한 IP 주소와 pod 집합에 대해 단일 DNS명을 부여하고, 그것들 간에 로드밸런스를 수행할 수 있다.
스토리지 오케스트레이션: 클라우드 공급자, 네트워크 스토리지 시스템에서 원하는 스토리지 시스템을 자동으로 마운트한다.
자동 빈 패킹: 리소스 요구 사항과 기타 제약 조건에 따라 컨테이너를 자동으로 배치, 가용성은 그대로 유지
IPv4/IPv6 이중 스택: pod와 서비스에 IPv4와 IPv6 주소 할당
자가 치유
오류가 발생한 컨테이너 재시작
노드가 죽었을 때 컨테이너 교체 스케쥴 시작
사용자 정의 상태 체크에 응답하지 않는 컨테이너 제거
서비스를 제공할 준비가 될때까지 클라이언트에 해당 컨테이너를 알리지 않음
쿠버네티스는 다른 프로젝트를 사용해 오케스트레이션된 서비스 전체를 제공한다.
- 레지스트리: Atomic Registry 또는 도커 레지스트리와 같은 프로젝트
- 네트워킹: OpenvSwitch 및 인텔리전트 엣지 라우팅 같은 프로젝트
- 텔레메트리: heapster, kibana, hawkular, elastic과 같은 프로젝트
- 보안: 멀티테넌시 계층을 갖춘 LDAP, SELinux, RBAC, OAUTH와 같은 프로젝트
- 자동화: 설치 및 클러스터 라이프 사이클 관리를 위한 Ansible 플레이북 추가
- 서비스: 인지도 높은 어플리케이션 패턴을 사용하여 사전 생성된 풍부한 콘텐츠로 구성된 카탈로그
용어
- 마스터: 쿠버네티스 노드를 제어하는 머신이다. 여기에서 모든 태스크가 할당이 된다.
- 노드: 할당된 테스크를 요청대로 수행하는 시스템이다. 쿠버네티스 마스터가 이러한 노드를 제어한다.
- 포드: 단일 노드에 배포된 하나 이상의 컨테이너 그룹이다. 포드에 있는 모든 컨테이너는 IP 주소, IPC, 호스트 이름, 기타 리소스를 공유하며 포드는 기본 컨테이너에서 네트워크와 스토리지를 추상화한다. 이렇게 하면 클러스터에서 컨테이너를 더 쉽게 이동할 수 있다.
- 복제 컨트롤러: 클러스터에서 실행되어야 하는 동일한 포드 사본의 개수를 제어한다.
- 서비스: 포드에서 작업 정의를 분리한다. 쿠버네티스 서비스 프록시는 클러스터에서 다른 위치로 이동한 경우든 교체된 경우든 서비스 요청을 적절한 포드로 자동 수신한다.
- Kubelet: 이 서비스는 노드에서 실행되며 컨테이너 매니페스트(집합의 일부 또는 논리정연한 단위인 파일들의 그룹을 위한 메타데이터를 포함하는 파일)를 읽고, 정의된 컨테이너가 시작되어 실행 중인지 확인한다.
- kubectl: 쿠버네티스 명령줄 설정 툴
특성
- 보안성
- 사용 편이성
- 확장 가능성
구성 요소
- 클러스터: 작동중인 쿠버네티스 배포, 2가지 구성요소가 있음
- 컨트롤 플레인(control plane)
- 컴퓨팅 머신(노드, compute machine): 컨테이너로 이루어진 pod 실행
컨트롤 플레인(Control Plane)
- kube-apiserver: 쿠버네티스 API는 쿠버네티스 컨트롤 플레인의 프론트엔드로 내부 및 외부 요청을 처리한다. REST호출이나 kubectl 커맨드라인 인터페이스, kubeadm과 같은 CLI를 통해 API 액세스 가능
- kube-scheduler: 클러스타가 양호한 상태인가, 컨테이너가 어디에 적합한가 등을 다룬다. cpu또는 메모리와 같은 pod의 리소스 요구사항과 함께 클러스터의 상태를 고려한다. 그런 다음 pod를 적절한 컴퓨팅 노드에 예약한다.
- kube-controller-manager: 컨트롤러는 실제로 클러스터를 실행하고 쿠버네티스 controller-manager에는 여러 컨트롤러 기능이 하나로 통합되어 있다. 한 컨트롤러는 스케줄러를 참고하여 정확한 수의 pod가 실행되게 한다. pod에 문제가 생기면 다른 컨트롤러가 이를 감지하고 대응한다. 컨트롤러는 서비스를 pod에 연결하므로 요청이 적절한 엔드포인트로 이동한다. 계정 및 api 액세스 토큰 생성을 위한 컨트롤러도 존재
- etcd: 설정 데이터, 클러스터의 상태에 관한 정보는 key-value 저장소 데이터베이스인 etcd에 상주한다.
Compute Machine
노드
최소 1개 이상의 컴퓨팅 노드가 필요하지만 일반적으로 여러개가 있다. pod는 노드에서 실행된다.
Pod
가장 작고 단순한 유닛으로 애플리케이션의 단일 인스턴스를 나타낸다. 각 pod는 컨테이너 실행 방식을 제어하는 옵션과 함께 컨테이너 하나 또는 결합된 일련의 컨테이너로 구성되어 있다. pod를 퍼시스턴트 스토리지에 연결하여 stateful 애플리케이션을 실행할 수 있다.
컨테이너 런타임 엔진
컨테이너 실행을 위해 각 컴퓨터 노드에는 컨테이너 런타임 엔진이 있다. 그 중 하나가 Docker이다. 다른 런타임도 지원한다.
kubelet
각 노드에 컨트롤 플레인과 통신하는 작은 애플리케이션인 kubelet이 있다. kubelet은 컨테이너가 포드에서 실행되게 한다. 컨트롤 플레인에서 노드에 작업을 요청한 경우 kubelet이 이작업을 실행한다
kube-proxy
각 컴퓨팅 노드에는 쿠버네티스 네트워킹 서비스를 용이하게 하기 위한 네트워크 프록시인 kube-proxy도 있다. kube-proxy는 운영 체제의 패킷 필터링 계층에 의존하거나 트래픽 자체를 전달하여 클러스터 내부 또는 외부의 네트워크 통신을 처리한다.
그 외
퍼시스턴트 스토리지
애플리케이션을 실행하는 컨테이너 뿐만 아니라 클러스터에 연결된 애플리케이션 데이터도 관리가 가능하다. 사용자가 기본 스토리지 인프라에관한 것을 알지 못해도 스토리지 리소스를 요청할 수 있다.
컨테이너 레지스트리
쿠버네티스가 의존하는 컨테이너 이미지는 컨테이너 레지스트리에 저장된다.
기본 인프라
쿠버네티스를 원하는 곳에서 실행할 수 있다.
