on
파드 배포 중심 쿠버네티스 구성 요소
파드 배포 중심 쿠버네티스 구성 요소
설명은 안했지만 앞서 쿠버네티스 구성하기에서 쿠버네티스 실습 환경을 구성하기 위해 필요한 파일에는
kubectl, kubelet, API 서버, 캘리코, etcd, 컨트롤러 매니저, 스케줄러,
kube-proxy, 컨테이너 런타임, 파드 등 쿠버네티스 클러스터를 이루는 구성 요소 가 있었습니다.
이 요소들이 어떤 역할인지 알아보겠습니다.
쿠버네티스 구성 요소를 가상머신(m-k8s)에 접속하여 kubectl get pods --all-namespaces 명령으로 위와 같이 확인합니다. --all-namespaces는 기본 네임 스페이스인 default 외에 모든 것을 표시하겟다는 의미 입니다.
따라서 모든 네임스페이스에서 파드를 수집해서 보여줍니다. 쿠버네티스 클러스터를 이루는 구성 요소들은 파드 형태로 이루어져 있음 을 알 수 있습니다.
쿠버네티스의 구성 요소의 유기적인 연결 관계
쿠버네티스의 구성 요소 간 통신
위의 이미지는 관리자나 개발자가 파드 배포 명령을 수행했을 때 실행되는 순서 입니다.
파드를 배포하는 순서에 따라 요소들의 역할은 다음과 같습니다.
마스터 노드
0 kubectl : 쿠버네티스 클러스터에 명령을 내리는 역할 을 합니다. 바이너리(Binary)형태로 배포되기 때문에 마스터 노드에 있을 필요는 없지만 API 서버와 주로 통신하기 때문에 위의 이미지에서 마스터 노드에 구성이 되었습니다.
1 API 서버 : 쿠버네티스 클러스터의 중심 역할을 하는 통로 입니다. 주로 상태 값을 저장하는 etcd와 통신합니다.
다른 요소또한 API 서버를 중심으로 통신하기 때문에 그 역할이 중요합니다.
2 etcd : 구성 요소들의 상태 값이 저장되는 곳 입니다. 실제로 etcd 외의 다른 구성 요소는 상태 값을 관리하지 않습니다.
그러므로 etcd의 정보만 백업돼 있다면 긴급한 장애 상황에서도 쿠버네티스 클러스터는 복구 할 수 있습니다.
또한 etcd는 분산 저장이 가능한 key-value 저장소이므로, 복제해서 여러 곳에 저장해 두면 하나의 etcd에서 장애가 나더라도 시스템의 가용성을 확보할 수 있습니다.
3 컨트롤러 매니저 : 쿠버네티스 클러스터의 오브젝트 상태를 관리 합니다.
예를 들어, 워커 노드에서 통신이 되지 않는 경우, 상태 체크와 복구는 컨트롤러 매니저에 속한 노드 컨트롤러에서 이루어집니다.
또다른 예는 레플리카셋 컨트롤러는 레플리카셋에 요청받은 파드 개수대로 파드를 생성합니다. 뒤에 나오는 서비스와 파드를 연결하는 역할을 한는 엔드 포인트 컨트롤러 또한 컨트롤러 매니저입니다.
이와같이 다양한 상태 값을 관리하는 주체들이 컨트롤러 매니저에 소속돼 각자의 역할을 수행 합니다.
4 스케줄러 : 노드의 상태와 자원 ,레이블, 요구 조건 등을 고려해 파드를 어떤 워커 노드에 생성할 것인지 결정하고 할당 합니다.
워커 노드
5 kubelet : 파 드의 구성 내용(PodSpec)을 받아서 컨테이너 런타임으로 전달하고, 파드 안의 컨테이너들이 정상적으로
작동하는지 모니터링 합니다.
6 컨테이너 런타임(CRI, Container Runtime Interface) : 파드를 이루는 컨테이너의 실행을 담당 합니다.
7 파드(Pod) : 한 개 이상의 컨테이너로 단일 목적의 일을 하기 위해서 모인 단위 입니다.
즉, 웹 서버의 역할을 할 수도 있고 로그나 데이터를 분석할 수도 있습니다. 여기서 중요한 것은 파드는 언제라도
죽을 수 있는 존재라는 것입니다.
파드는 언제라도 죽을 수 있다고 가정하고 설계됐기 때문에 쿠버네티스는 여러 대안을 디자인했습니다.
0번부터 7번까지는 기본 설정으로 배포된 쿠버네티스에서 이루어지는 통신 단계를 구분할 것입니다.
다음 요소는 이런 요소가 있다는 것만 알면 충분합니다.
네트워크 플러그인 : 쿠버네티스 클러스터의 통신을 위해서 네트워크 플러그인을 선택하고 구성 해야 합니다.
네트워크 플러그인은 일반전으로 CNI(Container Network Interface)로 구성하는데, 주로 사용하는 CNI에는 캘리코, 플래널, 실리움 등이 있는데, 여기 실습은 캘리코(Calico)를 선택해 구성했습니다.
CoreDNS : 클라우드 네이티브 컴퓨팅 재단에서 보증하는 프로젝트로, 빠르고 유연한 DNS 서버 입니다.
쿠버네티스 클러스터에서 도메인 이름을 이용해 통신하는 데 사용합니다.
사용자가 배포된 파드에 접속할 때
사용자 입장에서 배포된 파드에 접속하는 과정은 다음과 같습니다.
1. kube-proxy : 쿠 버네티스 클러스터는 파드가 위치한 노드에 kube-proxy를 통해 파드가 통신할 수 있는 네트워크를 설정 합니다. 이때 실제 통신은 br_netfilter와 iptables로 관리합니다.
2. 파드 : 이 미 배포된 파드에 접속하고 필요한 내용을 전달받습니다.
파드의 생명주기로 쿠버네티스 구성 요소 알아보기
파드의 생명주기
생명주기(Life Cycle)는 파드가 생성, 수정, 삭제되는 과정을 나타냅니다.
1. kubectl을 통해 API 서버에 파드 생성을 요청 합니다.
2. API 서버에 전달된 내용이 있으면 API 서버는 etcd에 전달된 내용을 모두 기록해 클러스터의 상태 값을 최신으로
유지 합니다. 따라서 각 요소가 상태를 업데이트할 때마다 모두 API 서버를 통해 etcd에 기록됩니다.
3. API 서버에 파드 생성이 요청된 것을 컨트롤러 매니저가 인지하면 컨트롤러 매니저는 파드를 생성하고,
이 상태를 API 서버에 전달 합니다.
4. API 서버에 파드가 생성됐다는 정보를 스케줄러가 인지합니다. 스케줄러는 생성된 파드를 어떤 워커 노드에
적용할지 조건을 고려해 결정하고 해당 워커 노드에 파드를 띄우도록 요청 합니다.
5. API 서버에 전달된 정보대로 지정한 워커 노드에 파드가 속해 있는지, 스케줄러가 kubectl으로 확인 합니다.
6. kubectl에서 컨테이너 런타임으로 파드 생성을 요청 합니다.
7. 파드가 생성 됩니다.
8. 파드가 사용 가능한 상태 가 됩니다.
쿠버네티스는 작업을 순서대로 진행하는 워크플로(workflow)구조가 아니라 선언적인(declarative) 시스템 구조를
가지고 있습니다. 즉, 각 요소가 추구하는 상태를 선언하면 현재 상태와 맞는지 점검하고 그것에 맞추려고 노력하는 구조로 돼 있다는 뜻 입니다.
따라서 추구하는 상태를 API 서버에 선언하면 다른 요소들이 API 서버에 와서 현재 상태와 비교하고 그에 맞게 상태를 변경하려고 합니다. API 서버와 etcd는 거의 한몸처럼 움직이도록 설계됐습니다.
그 이유는 API 서버는 현재 상태 값을 가지고 있는데, 이것을 보존해야 해서 etcd가 필요합니다.
참조 - 컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커 (조훈, 심근우, 문성주 지음)
from http://puzzle-moon.tistory.com/83 by ccl(A) rewrite - 2021-12-28 23:26:43