Kubernetes
kind
Terms
Links
- 공식 쿠버네티스 슬랙 채널 http://slack.k8s.io
- 쿠버네티스 공개 포럼 https://discuss.kubernetes.io
- 쿠버네티스 팟캐스트 https://kubernetespodcast.com
- TGI Kubernetes https://github.com/heptio/tgik
Docs
새로 개발한 애플리케이션을 쿠버네티스에서 사용하는 과정
쿠버네티스 기능
- 배포 계획에 맞춰 애플리케이션을 신속하게 배포할 수 있다
- 컨테이너 개수, CPU 사용률, 메모리 사용량을 설정 가능
- 저장 공간, 네트워크 접근 제어, 로드밸런싱 기능 설정 가능
- 가동 중인 애플리케이션을 스케일 업/다운할 수 있다
- 요청이 많을 때는 컨테이너 수를 늘려서 처리 능력을 높임
- 요청이 적을 때는 컨테이너 수를 줄여서 자원 점유율이나 요금을 줄임
- 새로운 버전의 애플리케이션을 무정지로 업그레이드 할 수 있다
- 하드웨어 가동률을 높여 자원 낭비를 줄인다
쿠버네티스 특징
k8s 클러스터를 구성하는 코어 프로세스
- kubectl: k8s 클러스터를 조작하기 위한 도구로 가장 빈번하게 이용되는 커맨드 라인 인터페이스다
- kube-apiserver: kubectl 등의 API 클라이언트로부터 오는 REST 요청을 검증하고, API 오브젝트를 구성하고 상태를 보고한다.
- kube-scheduler: 쿠버네티스의 기본 스케줄러이며, 새로 생성된 모든 파드에 대해 실행할 최적의 노드를 선택한다. 스케줄러는 파드가 실행 가능한 노드를 찾은 다음 점수를 계산하여 가장 점수가 높은 노드를 선택한다.
- kube-controller-manager: 컨트롤러를 구동하는 마스터상의 컴포넌트
- cloud-controller-manager: API를 통해서 클라우드 서비스와 연계하는 컨트롤러로, 클라우드 업체에서 개발한다.
- etcd: k8s 클러스터의 모든 관리 데이터는 etcd에 저장된다. 이 etcd는 CoreOS가 개발한 분산 키/값 저장소로 신뢰성이 요구되는 핵심 데이터의 저장 및 접근을 위해 설계 되었다
- kubelet: kubelet은 각 노드에서 다음과 같은 역할을 수행한다.
- 파드와 컨테이너의 샐행
- 파드와 노드의 상태를 API 서버에 보고
- 컨테이너의 동작을 확인하는 프로브 실행
- 내장된 cAdvisor를 통해 메트릭 수집 및 공개
- kube-proxy: kube-proxy 는 각 노드에서 동작하며 로드밸런싱 기능을 제공한다
- 서비스와 파드의 변경을 감지하여 최신 상태로 유지
- iptables 규칙을 관리
- coredns: 파드가 서비스 이름으로부터 IP 주소를 얻기 위해 사용된다
애드온 컴포넌트
- kube-flannel: 모든 노드에서 실행되어 여러 노드 사이에서 IPv4 네트워크를 제공한다.
- calico-kube-controllers: calico를 위한 컨트롤러. 데이터 스토어로서 etcd를 이용하기 위하여 사용된다
- calico-node: 모든 노드에서 실행되어 노드 간 파드의 통신, 라우팅, 네트워크 접근 관리 기능을 제공한다
- kubernetes-dashboard: Web 대시보드
- metrics-server: heapster를 대신하여 버전 1.8부터 도입되었다. API의 aggregation layer를 통해서 k8s 클러스터 전체로부터 메트릭을 수집한다
개발자를 위한 쿠버네티스 개념
주요 구성 요소
kubectl
쿠버네티스는 kubectl이라는 커맨드라인 인터페이스를 제공한다. 쿠버네티스 클러스터의 커맨드를 실행하거나 상호 작용하는데 사용한다.
마스터 노드
마스터는 쿠버네티스의 두뇌와 같다. 여러 가지 지원 서비스의 도움을 받아 클러스터 동작을 조율한다. API 서버와 스케줄러와 리플리케이션 컨트롤러로 구성된다. 애플리케이션의 상태를 관리하고 스케줄링하고 규모를 늘리거나 줄이는 등의 작업을 관리한다.
API 서버
API 서버는 쿠버네티스와 상호 작용하는 데 필요한 REST API를 외부에 제공한다.
클라이언트(kubectl)와 쿠버네티스 클러스터 사이에서 일어나는 외부 통신음 모두 이러한 API 서버를 이용해 처리된다.
또한 워커 노드와 마스터 노드 사이에서 발생하는 클러스터 내부 통신도 API 서버를 거친다.
오브젝트의 상태를 저장하기 위해 분산 키-밸류 스토어(etcd)와 통신하는 유일한 컴포넌트다.
kubectl run myTomcat --image=Tomcat --replicas=3
kubectl은 클러스터 안에 톰캣 인스턴스 3개를 구동하려는 사용자의 '의도', 즉 요청을 API 서버로 전달한다.
그러면 API 서버는 스케줄러, 리플리케이션 컨트롤러와 연동해 요청을 처리함으로써 클러스터를 원하는 상태로 전환한다.
워커 노드
워커 노드(worker node)는 포드가 스케쥴링돼 실제로 구동되는 곳이다. 각 워커 노드마다 큐브릿(kubelet)이라 부르는 에이전트가 실행된다.
쿠버네티스 클러스터 외부 저장소를 사용하는 것이 적합한 사용 사례
- 스토리지 클러스터는 일부 완전 다른 하드웨어를 사용하거나 네트워킹에 기반한 내부 또는 CSI 플러그인이 없다. (CSI가 표준이 됨에 따라 드물게 나타남)
- 클라우드 공급자에 쿠버네티스를 실행하면 너무 비싸고, 위험하며, 모든 데이터를 마이크레이션하기에 너무 느릴 수 있다.
- 조직의 다른 애플리케이션은 동일한 스토리지 클러스터를 사용하며, 조직의 모든 애플리케이션과 시스템을 쿠버네티스로 마이그레이션하는 것은 실용적이지 않고 비경제적인 경우가 많다.
- 규제 요건 때문에 데이터의 통제 유지가 필요하다
- 쿠버네티스 외부에서 스토리지를 관리하는 데는 몇 가지 단점이 있다.
- 보안 (워크로드에서 별도의 스토리지 클러스터로 네트워크 액세스를 제공해야 한다)
- 스토리지 클러스터의 확장, 가용성, 모니터링, 구성을 구현해야 한다.
- 스토리지 클러스터 측에서 상황이 변경될 때 종종 쿠버네티스 측에서 해당 구성을 변경해야 한다.
- 추가 네트워크 단계나 인증, 권한 부여 또는 암호화로 인해 성능 또는 대기 시간 오버헤드가 발생할 수 있다.