1. etcd
- key:value 형태의 데이터를 저장하는 스토리지
쿼럼
→ 정족수 즉, 의사결정에 필요한 최소한의 서버 수
→ ex) RSM을 구성하는 서버의 숫자가 3대인 경우 쿼럼 값은 2(3/2+1)
- etcd는 고가용성을 위해 2개 이상의 인스턴스로 구성할 수 있다.
- etcd는 RAFT 합의 알고리즘을 사용해 어느 순간이든 각 노드 상태가 대다수의 노드가 동의하는 현재 상태이거나 이전에 동의된 상태 중에 하나임을 보장한다.
- 합의 알고리즘은 클러스터가 다음 상태로 진행하기 위해 과반수가 필요하다. 만약 세 노드가 있는 클러스터에서 한 노드의 연결이 끊어지면 나머지 두 개의 노드를 포함하는 그룹이 여전히 과반을 가지고 있기 때문에 클러스터의 상태를 계속 변경할 수 있다. 그리고 나중에 끊어졌던 노드가 다시 연결될 경우 과반 그룹의 상태를 따라갈 수 있다.
—> 이러한 이유로 etcd는 홀수로 배포한다. 대규모 etcd 클러스터에서 5대 혹은 7대의 노드면 각각 2대, 3대 노드의 실패도 감당할 수 있기 때문이다.
- etcd 클러스터에 세 노드가 있다는 것을 알고 있다. (상태 변경 가능)
- 두개의 노드는 여전히 과반을 가지고 있다. (상태 변경 가능)
- 과반을 충족하지 못한다. (상태 변경 불가)
2. kube-apiserver
- Kubernetes 컨트롤 플레인의 프론트엔드 즉, 쿠버네티스 클러스터로 들어오는 요청을 가장 앞에서 접수한다. 구성요소 끼리는 서로 직접 통신하지 않는다. apiserver를 통해 서로의 상태를 주고받고 통신한다. kube-apiserver는 REST를 기반으로 만들어졌다.
REST(*Representational State Transfer)란?
- 자원을 이름으로 구분해 해당 자원의 상태(정보)를 주고받는 모든 것
- HTTP URI(식별자)를 통해 자원을 명시
- HTTP Method(POST, GET, PUT, DELETE, PATCH 등)을 사용
- 해당 자원(URI)에 대한 CRUD(Create, Read, Update, Delete) Operation을 적용하는 것
- kubectl 명령줄 인터페이스 또는 API를 사용하는 kubeadm을 통해 명령을 내릴 경우 kube-apiserver로 전송된다.
- 전달된 명령은 kube-apiserver에서 요청 처리 흐름에 따라 적절한 컴포넌트(contoller-manager, scheduler)로 요청을 전달한다.
- 인증 플러그인으로 클라이언트 인증
→ API 서버는 요청을 보낸 클라이언트를 인증한다. 하나 이상의 플러그인에 의해 수행된다. 이는 HTTP 요청을 검사해 수행되는데 ,인증 방법에 따라 인증서 혹은 HTTP헤더에서 정보를 가져온다. 플러그인은 클라이언트 사용자의 이름, 사용자 ID, 속해있는 그룹 정보를 추출하고 이 데이터는 다음 단계인 인가 단계에서 사용한다.
- 인가 플러그인을 통한 클라이언트 인가
→ API 서버는 요청한 작업이 요청한 리소스를 대상으로 수행할 수 있는지 판별한다. 예를 들어 파드 생성 시 요청한 네임 스페이스 안에 파드를 생성할 수 있는지 등을 결정한다.
- 어드미션 컨트롤러 플러그인으로 요청된 리소스 확인 및 수정
→ 리소스를 생성, 수정, 삭제하려는 경우 해당 요청은 어드미션 컨트롤러로 보내진다. 이 플러그인은 리소스를 여러 이유로 수정할 수 있는데, 누락된 필드를 초기값으로 설정하거나 재정의할 수 있다.
- 리소스 유효성 확인 및 저장
→ 요청이 모든 어드미션 컨트롤 플러그인을 통과하면 API 서버는 오브젝트의 유효성을 검사하고 etcd에 상태를 저장한 뒤 클라이언트에 응답을 반환한다.
3. kube-controller-manager
컨트롤러는 모두 API 서버에서 리소스가 변경되는 것을 감시하고 각 변경 작업을 수행한다. 컨트롤러는 감시 매커니즘을 이용해 변경 사항을 통보 받지만 모든 이벤트를 놓치지 않고 받는 것을 보장하지 않기 때문에 정기적으로 목록을 가져오는 작업을 수행해 누락된 이벤트가 없는지 확인한다.
Controller 역할
- Auto Healing
- pod 또는 pod가 실행되고 있는 node에 문제가 생겼을 경우 자동으로 복구하는 기능
- ex) ReplicaSet, DaemonSet - Software Update
- pod을 업데이트하는 기능, 롤백 기능
- ex) Deployment - Auto Scaling
- Pod의 리소스가 부족할 때 pod를 추가적으로 생성하는 기능 - Job
- 일시적인 작업을 위해 필요한 순간에만 pod을 생성했다가 삭제할 수 있는 기능
- ex) job, cron job
- Node Controller
→ 노드가 다운될 때 이를 인지하고 대응하는 역할
- Job Controller
→ 일회성 작업을 나타내는 작업 개체를 감시한 다음 해당 작업을 완료할 때 까지 실행하는 pod 생성
- EndpointSlice Controller
→ EndpointSlice 개체를 채운다.(서비스와 포드 간의 링크 제공)
- Service Account Controller
→ 새 네임스페이스에 대한 기본 Service Account를 생성
4. kube-scheduler
파드를 어느 노드에 위치 시킬지 결정하는 역할을 한다. API 서버의 감시 매커니즘을 통해 새로 생성될 파드를 기다리고 있다가 할당된 노드가 없는 새로운 파드를 노드에 할당하기만 한다.
Scheduling Algorithm
- 모든 노드 중 파드를 스케줄링할 수 있는 노드 목록 필터링
- 수용 가능한 노드의 우선순위를 정하고 점수가 높은 노드 선택
- 만약 동점인 노드가 여러개라면 라운드로빈 적용
CPU와 메모리 단위
Scheduler가 pod를 효과적으로 배치하려면 각 파드가 최소/최대로 사용하고자 하는 자원이 어느 정도인지를 알고 있어야 한다. kubernetes는 여러 종류의 자원 중 CPU와 메모리 만을 관리할 수 있다.
- CPU 리소스
→ 1개 CPU가 단위가 되며, 언제나 절대량을 표시한다.
ex) 클러스터가 쿼드코어 CPU라고 해도 0.5를 명시한다면 코어 2개가 아닌 0.5 코어를 의미함
→ m은 밀리를 의미하며 1000m이 1코어
- 메모리 리소스
→ 1바이트가 단위가 되며 대소문자를 구분함
ex) 400m → 0.4byte / 400M → 400MB
리소스 요청 및 제한
쿠버네티스의 리소스 요청은 파드를 실행하기 위한 최소한의 자원을 요청하는 것을 의미한다.
리소스 요청이 파드 실행을 위해 필요한 최소한의 자원을 명시했다면, 리소스 제한은 파드가 최대로 사용할 수 있는 자원을 의미한다.
- CPU
→ 만약 파드가 배정된 CPU 이상을 사용하려 한다면 Throttling에 걸리게 되고 성능이 저하됨
- 메모리
→ 파드가 배정된 메모리 이상을 사용하려 한다면 해당 파드는 메모리 부족(out of memory, OOM) 오류와 함께 즉시 종료되고 재실행된다.
수용가능한 노드 찾기
파드를 수용할 수 있는 노드를 찾기 위해 스케줄러는 미리 설정된 조건 함수 목록에 각 노드를 전달한다.
다음와 같은 조건을 확인한다.
- 노드가 하드웨어 리소스에 대한 파드 요청을 충족하는가?
- 노드에 리소스가 부족한가?
- 파드를 특정 노드로 스케줄하도록 요청한 경우, 해당 노드인가?
- 노드가 파드 정의에 있는 노드 셀렉터와 일치하는 라벨을 갖고 있는가?
- 파드가 특정 포트를 쓰려는 경우 해당 포트가 노드에서 이미 사용중인가?
등등 이 모든 검사를 통과하면 노드가 파드를 수용할 수 있는 자격을 얻게 된다.
5. Service Account
Kubernetes Service Account는 쿠버네티스 클러스터 내에서 실행되는 Pod이 API 서버와 상호작용할 수 있도록 권한을 부여하는 데 사용되는 자격증명이다.
Kubernetes 1.24 이전까지는 서비스 어카운트 생성시 서비스 어카운트 토큰이 생성됐지만, 현재는 보안 강화로 자동으로 생성되지 않는다.
Service Accounts Properties
- 네임스페이스 : 각 service account가 kubernetes namespace에 바인딩 된다. 모든 네임스페이스 생성시 default Service Account가 생성된다.
- 경량 : 서비스 계정은 클러스터에 존재하며 Kubernetes API에 정의된다. 서비스 계정을 빠르게 생성하여 특정 작업을 활성화할 수 있다.
- 이식성 : Service Account와 namespace ID의 경량 특성으로 인해 구성을 이식할 수 있다.
'kubernetes' 카테고리의 다른 글
| [Kubernetes-Storage]Minio (0) | 2024.08.28 |
|---|---|
| #2. Worker Node Components (1) | 2023.12.28 |
