kubernetes 내부 이해

쿠버네티스 아키텍처 이해

 

쿠버네티스 클러스터 구성요소

• 컨트롤 플레인 (마스터 노드)
• 워커 노드

컨트롤 플레인은 클러스터 기능을 제어해서 전체 클러스터가 동작하게 만드는 역할이다.

 

컨트롤 플레인 구성요소

• etcd 분산 저장 스토리지
• API 서버
• 스케줄러
• 컨트롤러 매니저

 

워커 노드 구성요소

• Kubelet
• 쿠버네티스 서비스 프록시
• 컨테이너 런타임 (도커)

 

애드온 구성요소

컨트롤 플레인과 노드에서 실행되는 구성 요소 외에 클러스터에 추가 기능을 위한 구성요소

• 쿠버네티스 DNS 서버
• 대시보드
• 인그레스 컨트롤러
• 힙스터
• 컨테이너 네트워크 인터페이스 플러그인

쿠버네티스 구성요소들은 모두 API server와 통신한다.

API server 는 유일하게 etcd 와 통신

 

etcd

API 서버가 다시 시작하거나 실패하더라도 유지하기 위해 매니페스트가 영구적으로 저장될 필요가 있는데

이런 상태를 저장하기 위해 키 - 값 저장소를 제공하는 etcd 를 사용한다.

 

- 모든 구성요소들이 API 서버를 통해 etcd 에 접근을 한다.

- 둘 이상의 etcd 를 사용하면 우수한 성능을 제공 할 수 있다.

 

낙관적 동시성 제어

데이터 조작에 잠금을 설정해서 데이터를 읽거나 업데이트 하지 못하게 업데이트 시 버전 번호를 포함시키는 방법

 

API서버에서 낙관적 잠금 방법으로 상태 업데이트를 한다.

 

 

API 서버

쿠버네티스의 API 서버는 모든 구성요소들과 kubectl 같은 클라이언트가 사용하는 중심 구성 요소다.

클러스터 상태 조회/ 변경을 위해 RestFul API 로 CRUD를 제공한다.

낙관적락(positive lock) 으로 일관성 유지되기 떄문에 동시에 업데이트 하더라도 변경사항이 재정의 되지 않는다.

 

kubetcl을 이용해 처리하는 과정

kubectl은 파일의 내용을 API 서버에 전달하면 내부에서는

인증, 인가 머드미션 플러그인을 거쳐서 리소스 검사 후 etcd 에 데이터를 처리한다.

 

인증 플러그인으로 클라이언트 인증

• 클라이언트가 인증되었는지 인증서 혹은 HTTP 헤더를 가져와서 인증한다.

인가 플러그인을 통한 클라이언트 인가

• 인증된 사용자가 요청한 작업이 요청한 리소스를 대상으로 수행 할 수 있는지 판별

어드미션 컨트롤 요청된 리소스 확인 과 수정

• 누락된 필드가 있는지

리소스 유효성 확인 및 저장

• API 서버는 오브젝트의 유효성을 검증하고 etcd 에 저장한다.

 

 

API 서버가 리소스 변경을 클라이언트에게 통보하는 방법

 

여러 클라이언트는 HTTP 연결을 맺고 변경사항을 감지한다.

변경이 될 때마다 연결된 모든 클라이언트에 새로운 버전을 보낸다.

 

kubectl 역시 리소스 변경을 감시 할 수 있는 클라이언트 중 하나다.

 

이 과정들 제외하곤 다른 일은 하지 않는다. 파드 생성, 서비스 엔드 포인트 관리 등은 컨트롤러 매니저의 역할이다.

 

스케줄러

 

파드를 적절한 노드에 할당하는 역할

 

스케줄러는 API 서버를 watch 하고 있다가 새로 생성될 파드를 기다리고 있다가 할당된 노드가 없는 새로운 파드를 노드에 할당한다.

 

스케줄러는 API 서버로 파드 정의를 갱신하고 API 서버는 kubelet에 파드 스케줄링 된 걸 통보 하고

kubelet이 파드의 컨테이너를 생성하고 실행한다.

 

스케줄러는 파드의 적합한 노드를 선택하는데 라운드로빈을 쓰기도 하고 여러 방법들이 있다.

 

 

컨트롤러 매니저에서 실행되는 컨트롤러

컨테이너에게 pod 의 복제 배포 명령등 수행

 

컨트롤러 매니저는 다양한 조정작업을 하는 여러 컨트롤러들이 하나의 컨트롤러 매니저 프로세스에서 실행된다.

작업마다 해당되는 컨트롤러 들이있다. (ex 노드 컨트롤러, 서비스 컨트롤러...)

컨트롤러는 리소스를 배포해 실제 작업을 수행

 

 

 

컨트롤러 역할과 동작 방식 이해

 

모든 API 서버에서 리소스가 변경되는 것을 감시하고 변경 작업을 수행한다.

 

 

Kubelet

 

워커 노드에서 실행하는 모든 것을 담당하는 구성요소

 

kubelet의 작업

 

먼저 kubelet 은 실행 중인 노드를 노드 리소스로 만들어 API 서버에 등록한다.

 그 후 API 서버를 모니터링 하고 있다가 노드에 파드가 스케줄링 되면 파드에 컨테이너를 실행시킨다.

실행중인 컨테이너를 모니터링 하면서 상태, 이벤트 들을 API 서버에 보고한다.

컨테이너 라이브니스 프로브를 실행하는 역할도 한다.

 

 

쿠버네티스 서비스 프록시의 역할

 

워커노드에는 클라이언트가 서비스에 연결 할 수 있도록 해주는 kube-proxy도 실행시켜준다.

kube-proxy는 서비스의 ip 와 포트로 들어온 접속을 하나의 파드와 연결시켜준다.

파드간에 로드 밸런싱도 수행해준다.

 

 

 

컨트롤러가 협업하는 방법

 

kubectl 을 통해 Deployement 리소스가 생성되고

watch하고 있던 컨트롤러에 알린다.

디플로이먼트 컨트롤러는 레플리카셋을 생성하고 레플리카셋이 생성되면 레플리카셋 컨트롤러에 알린다.

레플리카셋 컨트롤러가 파드를 만들고 만들어진 파드는 스케줄러에 알리게 되고

스케줄러는 적절한 노드를 찾아서 알려주고

해당 노드 kubelet에 파드를 생성하라고 알린다.

kubelet은 해당 파드 컨테이너를 실행 시킨다.

 

 

파드간 네트워킹

쿠버네티스 클러스터에서는 파드들은 각자 고유 IP 주소를 가지고 있고 다른 파드와 플랫 네트워크로 연결이 되어있어서 서로 통신 할 수 있다. NAT 같은게 필요없다.

 

 

동일한 노드에서 파드 간의 통신 활성화

컨테이너를위한 veth(가상 이더넷 인터페이스)가 생성된다.

이 이더넷은 브릿지의 주소 범위 안에서 ip를 할당 받고 컨테이너에서 패킷을 전송할때 eth0 에서 veth를 통해 브릿지로 다른곳으로 전달한다.

 

노드에 있는 모든 컨테이너들은 브릿지로 연결되어있어서 서로 통신이 가능하다.

다른 노드에서 실행중인 컨테이너에 연결하려면 노드 사이의 브릿지가 서로 연결 되어있으면 가능하다

 

서로 다른 노드에서 파드간의 통신 활성화

 

다른 노드로 패킷을 전송할때는 패킷이 veth 를 지나 브릿지를 통해 노드 물리 어댑터로 전달된다.

케이블을 통해 다른 노드에 전달되고 해당 파드에 전달된다.

 

두 노드가 같은 네트워크 스위치에 있을때만 동작한다.

 

 

서비스 구현 방식

 

kube-proxy

서비스 리소스가 생성되면 가상 ip를 할당하고 API 서버는 모든 워커 노드에 kube-proxy 에 

서비스가 생성되었다고 알린다.

 

kube-proxy는 실행 중인 노드에 해당 서비스 주소로 접근 할 수 있게 해준다.

 

처음 패킷의 목적지가 서비스 ip와 포트로 설정이 되어서 보내지면

패킷이 네트워크로 전송되기 전에 노드에서 설정된 iptables 규칙에 따라 처리가 되고 임의의 파드 ip 포트로 목적지 주소를 바꾼다.

 

 

고가용성 클러스터

 

etcd

• 모든 인스턴스에 데이터 복제
• 한 노드가 실패하더라도 읽기 쓰기 가능

API 서버

• stateless 하기 때문에 늘려도 상관이 없다.

컨트롤러 매니저/ 스케줄러

• 한번에 하나의 인스턴스만 활성화