Server-Agent
run을 하면 실행되고 stop하면 멈춘다.
이는 에이전트를 만들고 중앙에서 API를 사용하여 원격으로 관리할 수 있다.
Master-Node 구조
쿠버네티스 또한 중앙(Master)에 API서버와 상태 저장소를 두고 각 서버(Node)의 에이전트(kubelet)과 통신하는 구조이다.
쿠버네티스는 전체 클러스터를 관리하는 마스터와 컨테이너가 배포되는 노드로 구성되어 있다. 모든 명령언 Master의 API서버를 호출하고 노드는 Master와 통신하며 필요한 작업을 수행한다. 특정 노드의 Container에 명령하거나 로그를 조회할 때도 노드에 직접 명령하지 않고 Master가 노드에 접속하여 결과를 응답한다.
Master 구성 요소
Master 서버는 다양한 모듈이 확장성을 고려하여 기능별로 쪼개져 있는 특징이다.
Master 서버는 관리자만 접속 할 수 있도록 보안 설정을 해야하고 Master 서버가 죽으면 Cluster를 관리할 수 없기 때문에 보통 3대를 구성한다.
Node
노드 서버는 마스터 서버와 통신하면서 필요한 Pod를 생성하고 네트워크와 볼륨을 설정한다. 실제 Container들이 생성되는 곳으로 수백, 수천대로 확장할 수 있다.
Kubectl
API서버는 json 또는 protobuf 형식을 이용한 http통신을 지원한다.
이 방식을 그대로 쓰면 번거롭기 때문에 kubectl이라는 명령행 도구를 사용한다.
Master 구성 요소
API 서버 kube_apiserver
API서버는 모든 요청을 처리하는 Master의 핵심 기능이다.
kubectl의 요청 뿐 아니라 내부 모듈의 요청도 처리하여 권한을 체크하고 요청을 거부할 수 있다.
분산 데이터 저장소 ctcd
key-value 저장소다. 여러개로 분산하여 복제할 수 있기 때문에 안정성이 높고 속도도 빠른 편이다. 단순히 값을 저장하고 읽는 기능 뿐 아니라 watch 기능이 있어 상태가 변경되면 바로 체크하고 로직을 실행할 수 있다.
클러스터의 모든 설정, 상태 데이터는 여기 저장되고 나머지 모듈은 stateless하게 동작하기 때문에 etcd만 잘 백업해두면 언제든지 클러스터를 복구할 수 있다.
스케줄러
API 서버는 요청을 받으면 etcd 저장소와 통신할 뿐 실제로 상태를 바꾸는 건 스케줄러와 컨트롤러 입니다. 현재 상태를 모니터링하다가 원하는 상태와 다르면 각자 맡은 작업을 수행하고 상태를 갱신한다.
스케줄러 kube-scheduler
스케줄러는 할당되지 않은 Pod을 여러 가지 조건(필요한 자원, 라벨)에 따라 적절한 노드 서버에 할당해주는 모듈이다.
큐브 컨트롤러 kube-controller-manager
큐브 컨트롤러는 다양한 역할을 하는 모듈로. 쿠버네티스에 있는 거의 모든 오브젝트의 상태를 관리한다. 오브젝트별로 철저하게 분업화되어 Deployment는 ReplicaSet을 생성하고 ReplicaSet은 Pod을 생성하고 Pod은 스케줄러가 관리하는 식으로 동작한다.
클라우드 컨트롤러 cloud-controller-manager
클라우드 컨트롤러는 AWS, GCE, Azure 등 클라우드에 특화된 모듈이다. 노드를 추가/삭제하고 로드 밸런서를 연결하거나 볼륨을 붙일 수 있다. 각 클라우드 업체에서 인터페이스에 맞춰 구현하면 되기 때문에 확장성이 좋고 많은 곳에서 자체 모듈을 만들어 제공하고 있다.
Node 구성 요소
큐블릿 kubelet
노드에 할당된 Pod의 생명주기를 관리한다. Pod을 생성하고 Pod 안의 컨테이너에 이상이 없는지 확인하면서 주기적으로 마스터에 상태를 전달한다. API 서버의 요청을 받아 컨테이너의 로그를 전달하거나 특정 명령을 대신 수행하기도 한다.
프록시 kube-proxy
큐블릿이 Pod을 관리한다면 프록시는 Pod으로 연결되는 네트워크를 관리한다. TCP, UDP, SCTP 스트림을 포워딩하고 여러 개의 Pod을 라운드로빈 형태로 묶어 서비스를 제공할 수 있다. 초기에는 kube-proxy 자체가 프록시 서버로 동작하면서 실제 요청을 프록시 서버가 받고 각 Pod에 전달해 주었는데 시간이 지나면서 iptables를 설정하는 방식으로 변경되었다. iptables에 등록된 규칙이 많아지면 느려지는 문제 때문에 최근 IPVS를 지원하기 시작했다.
추상화
쿠버네티스는 CRI(Container runtime interface)를 구현한 다양한 컨테이너 런타임을 지원한다.
CRI 외에 CNI(네트워크), CSI(스토리지)를 지원하여 인터페이스만 구현한다면 쉽게 확장하여 사용할 수 있다.
하나의 Pod이 생성되는 과정
관리자가 애플리케이션을 배포하기 위해 ReplicaSet을 생성하면 다음과 같은 과정을 거쳐 Pod을 생성한다.
흐름을 보면 각 모듈은 서로 통신하지 않고 오직 API서버와 통신하는 것을 알 수 있다. API 서버를 통해 ETCD에 저장된 상태를 체크하고 현재 상태와 원하는 상태가 다르면 필요한 작업을 수행한다.
해당 사이트에서 공부했습니다.
https://subicura.com/2019/05/19/kubernetes-basic-1.html
