쿠버네티스 클러스터를 이루는 구성요소를 알아보자.
쿠버네티스 클러스터는 크게 “쿠버네티스 컨트롤 플레인 & 워커 노드“로 구성되어있다.
쉽게 비유하자면, 컨트롤 플레인은 관제탑 역할을 워커노드는 쫄병? 역할 이라고 보시면 됩니다.
하나씩 자세히 알아봅시다.
각 구성요소
컨트롤 플레인
컨트롤 플레인은 클러스터 기능을 제어하하고 전체 클러스터가 동작하게 만드는 역할을 합니다.
클러스터 플레인의 구성요소는 다음과 같습니다.
- etcd (분산 저장 스토리지)
- API 서버
- 스케줄러
- 컨트롤러 매니저
포인트는 해당 구성요소들은 클러스터 상태를 저장하고 관리하지
어플리케이션 컨테이너를 직접 실행하는 것은 아닙니다!
( 그냥 브레인! 경영진!? 이라고 보시면 됩니다!)
워커노드 구성요소
컨테이너를 실행하는 작업은 각 워커 노드에서 실행되는 구성요소가 담당합니다.
- kubelet
- kube-proxy
- 컨테이너 런타임
add-on 구성 요소
컨트롤 플레인과 노드에서 실행되는 구성 요소 외 클러스터 기능을 위해 존재하는 추가 구성 요소
- 쿠버네티스 DNS 서버
- 대시보드
- 인그레스 컨트롤러
쿠버네티스 구성요소의 분산 특성
앞의 구성 요소들은 모두 개별 프로세스로 실행됩니다.
맨 처음 보여드린 사진에서도 알 수 있듯 각 수성요소는 긴밀한 상호 통신과 종속성을 가집니다.
쿠버네티스가 제공하는 모든 기능을 사용하려면, 이런 모든 구성요소가 실행중이어야합니다. (일부 제외)
그렇다면 구성 요소들은 어떻게 통신하는 걸까요?
쿠버네티스 시스템 구성 요소는 오직 API 서버하고만 통신합니다.
쿠버네티스 시스템의 센터!! API 서버
구성 요소들은 서로 직접 통신 x!!
오직 API 서버하고만 통신
즉, API 서버는 etcd와 통신할 수 있게 해주는 유일한 구성요소입니다.
다른 구성요소는 etcd와 직접 통신하지 않고 API 서버를 프록시 처럼 통하여 클러스터 상태를 변경합니다.
etcd
위에서 살짝 언급된 etcd가 쿠버네티스에서 어떤 역할일까?
쿠버네티스에서 생성한 모든 오브젝트는 API 서버가 다시 시작되거나 실패하더라도 유지하기 위해 매니패스트를 영구적으로 저장할 필요가 있습니다.
( 쉽게, 장애가 나도 이전에 어떤 상태였는지를 상태 백업이 필요하다)
이를 위해 쿠버네티스는 빠르고, 분산해서 저장, 일관된 키-값 저장소를 제공하는데 그것이 etcd입니다.
분산되어 있기 때문에 둘 이상의 etcd 인스턴스를 실행해 고가용성과 우수한 성능을 제공할 수 있습니다.
이 부분이 이해안되는 분을 위한 추가 설명
워커노드의 구성요소와 달리 컨트롤 플레인의 구성요소는 여러 서버에 걸쳐 실행될 수 있습니다.
즉, 여러 서버에 컨트롤 플레인 구성 요소 인스턴스를 구성시켜 가용성을 높일 수 있습니다.
또한 앞서도 말했듯 etcd와 통신을 직접할 수는 없고 API 서버를 통해서만 통신이 가능합니다.
이로써 다른 구성요소들로부터 강력한 낙관적 잠금 시스템 뿐만 아니라 유효성을 검사하는 등의 이점을 얻을 수 있습니다.
etcd가 중앙 저장소와 같은 느낌으로 클러스터의 상태를 저장하고 있습니다.
만일, 구성요소들이 곧바로 etcd에 접근하여 값을 변경할 수 있다면 충돌이 발생할 수 있고 메커니즘을 올바르게 따르지 않는 구성요소 하나로 인해 데이터의 불일치가 발생할 수 있습니다.따라서, 쿠버네티스는 다른 구성요소가 API 서버를 통하도록 함으로써 이를 개성하였고 API 서버 한곳에서 낙관적 잠금 메커니즘을 구현해서 클러스터의 상태를 업데이트하기에 오류가 발생할 가능성을 줄이고 항상 일관성을 가질 수 있습니다.
또한, API 서버는 저장소에 기록된 데이터가 항상 유효하고 데이터의 변경이 올바른 권한을 가진 클라이언트에 의해서만 수행되도록 합니다.
또한, 실제 저장소 메커니즘을 추상화해 다른 모든 구성요소에 제공해 나중에 교체하기 쉽도록 합니다.
(쉽게, 하나의 마스터 서버가 장애 시 살아있는 나머지 마스터 서버의 etcd를 비교하여 빠르게 복구)
즉, 쿠너베이트가 클러스터 상태와 메타데이터를 저장하는 유일한 장소가 etcd라는 것을 강조할만한 가치가 있습니다.
클러스터링된 etcd의 일관성 보장
고가용성을 보장하기 위해 두개 이상의 etcd 인스턴스를 실행하는 것이 일반적입니다. 이 경우 여러 etcd 인스턴스는 일관성을 유지해야 합니다.
즉, 분산된 etcd 들은 쿠버네티스 시스템의 실제 상태가 무엇인지 합의에 도달해야하는데요.
Etcd는 RAFT 합의 알고리즘을 사용해 어느 순간이든 각 노드 상태가 대다수의 노드가 동의하는 현재 상태이거나 이전 동의 상태 중에 하나임을 보장합니다.
클라이언트는 etcd 클러스터의 서로 다른 노드에 접속해 실제 현재 상태 또는 과거 상태 중에 하나를 보게 됩니다.
이러한 합의 알고리즘은 클러스터가 다음 상태로 진행하기 위해 과반수가 필요합니다. 따라서, etcd 인스턴스 수는 홀수개여야합니다.
API 서버
쿠버네티스의 API 서버는 다른 모든 구성요소와 Kubectl 같은 클라이언트에서 사용하는 중심구성 요소 입니다.
클러스터 상태를 조회하고 변경하기 위해 RESTful API로 CRUD 인터페이스를 제공합니다.
(상태는 etcd 안에 저장)
오브젝트를 etcd에 저장하는 일관된 방법을 제공하는 것 뿐만 아니라, 오브젝트 유효성 검사 작업도 수행하기 때문에 잘못 설정된 오브젝트를 저장할 수 없습니다.
(유효성 검사와 낙관점 작금 기능)
API 서버 동작
API 서버가 요청을 받을 때 내부에서 발생하는 상황입니다.
https://kubernetes.io/ko/docs/concepts/security/controlling-access/
- 클라이언트 인증
먼저 API 서버는 요청을 보낸 클라이언트를 인증해야합니다.
이 작업은 API 서버에 구성된 하나 이상의 플러그인에 의해 수행됩니다.
API 서버는 누가 요청을 보낸 것인지 결정할 수 있을깨까지 이들 플러그인을 차례로 호출합니다. (HTTP 요청을 검사함으로써)
인증 방법에 따라 사용자를 클라이언트 인증서나 HTTP 헤더에서 가져옵니다.
무튼 플러그인은 클라이언트의 사용자 이름, 사용자 ID, 속해있는 그룹 정보를 추출합니다.
( 너 누구니?)
- 클라이언트 인가
API 서버는 인증 플러그인 외에도 하나 이상의 인가 플러그인을 사용하도록 설정되어있습니다.
이 작업은 인증된 사용자가 요청한 작업이 요청한 리소스를 대상으로 수행할 수 있는지를 판별합니다.
(즉, 오케이 너 누군지 알겠어 근데 너 이거 할 수 있는 사람 맞아?)
사용자가 해당 동작을 할 수 있다고 보면 API 서버는 다음단계로 진행합니다.
- 요청된 리소스 확인 및 수정
리소스를 생성, 수정, 삭제하려는 요청인 경우 해당 요청은 어듸션 컨트롤러 보내집니다.
이어서의 내용은 포스팅의 길이를 생각하여 나눠서 올리도록 하겠습니다.
