Kubernetes란?
Google이 만든 Container Ochestration을 하기 위한 도구임
Container Ochestration이란?
- Container를 자동으로 관리해줌
=> 중앙에서 관리 - Cluster 차원으로 관리
- 일반 Docker만 사용하는 것과 다르게 확장의 용이성을 제공해주고 여러 서버를 동시에 관리할 수 있음
Kubernetes가 제공해주는 가치?
- 관리 측면에서 여러가지를 자동으로 관리해주고, 추상화된 개념에서 접근하기에 훨씬 편함
=> 대규모 환경 관리 - 배포같은 것들도 매우 편리하고 합리적으로 해줌
Kubernetes 컴포넌트
쿠버네티스 Cluster는 컴퓨터 집합인 Node와 Control Plain 으로 구성됨
우선 Node는 두 가지 종류가 있음
- Master Node
- Cluster를 관리하는 관리자 Node
- Amazon EKS의 경우에는 Master Node를 Fully-Managed로 제공
- Master Node 또한, High-Availability 구성이 필요
- Kubernetes는 특이하게, 홀수 단위의 클러스터만 지원을 함
- 최소 고가용성 구성 필요 노드가 3개임
- Kubernetes는 특이하게, 홀수 단위의 클러스터만 지원을 함
- Cluster를 관리하는 관리자 Node
- Worker Node
- 실제로 일을 하는 Node
- 여기에 실제로 배치할 Container들이 생성되고, 실행됨
- 실제로 일을 하는 Node
쿠버네티스를 배포하면 Cluster를 얻는데
위에서 말했듯이 Cluster는 컨테이너화된 애플리케이션을 실행하는 Node라고 하는 워커 머신의 집합임
=> 모든 cluster는 최소 한 개의 Worker Node를 가짐
Worker Node는 애플리케이션의 구성요소인 Pod를 호스트함
Control Plane은 Worker Node와 Cluster 내 Pod를 관리함
(실제 어플리케이션의 실행과는 무관하고, 클러스터의 상태를 관리하고 조정하는 데 초점을 맞춤)
프로덕션 환경에서는 일반적으로 Control Plane이 여러 컴퓨터에 걸쳐 실행되고, Cluster는 일반적으로 여러 Node를 실행하므로 내결함성과 고가용성이 제공됨
Control Plane의 구성 요소
Control Plane은 cluster에 관한 전반적인 결정 관련 작업(ex. 스케줄링) 을 수행하고 cluster 이벤트를 감지하고 반응함
(ex. deployment의 replicas 필드에 대한 요구 조건이 충족되지 않을 경우 새로운 pod를 구동 시키는 등의 이벤트)
- kube-apiserver
API 서버는 쿠버네티스 API를 노출하는 쿠버네티스 control plane 컴포넌트임
(쿠버네티스 contorl plane의 프론트 엔드라고 생각)
=> kube-apiserver는 수평으로 확장되도록 디자인되었기에 더 많은 인스턴스를 배포해서 확장할 수 있음 - etcd
모든 cluster 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 key-value 저장소임 - kube-scheduler
Node가 배정되지 않은 새로 생성된 Pod를 감지하고, 실행할 Node를 선택하는 Control Plane 컴포넌트 - kube-controller-manager
controller process를 실행하는 control plane 컴포넌트
=> 논리적으로, 각 controller는 분리된 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행됨 - cloud-controller-manager
클라우드별 control 로직을 포함하는 쿠버네티스 controll plane 컴포넌트임
=> cloud-controller-manager를 통해 cluster를 클라우드 공급자의 API에 연결하고, 해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 cluster와만 상호 작용하는 컴포넌트를 구분할 수 있게 해줌
(클라우드 제공자 컨트롤러만 실행하기 때문에 PC 내부 학습 환경에서 쿠버네티스를 실행 중인 경우 cluster에는 cloud-controller-manager가 없음)
Node의 구성 요소
Node 컴포넌트는 동작 중인 pod를 유지시키고 쿠버네티스 런타임 환경을 제공하며, 모든 node 상에서 동작함
- kubelet
cluster의 각 node에서 실행되는 에이전트로 kubelet은 pod에서 container가 확실하게 동작하도록 관리함
=> kubelet은 pod Spec 집합을 받아서 container가 해당 pod Spec에 따라 healthy 하게 동작하는 것을 확실히함
(쿠버네티스를 통해 생성되지 않는 container는 관리하지 않음) - kube-proxy (각 Kubernetes Node별 Endpoint)
kube-proxy는 cluster의 각 node에서 실행되는 네트워크 프록시로, 쿠버네티스의 서비스 개념의 구현부임
=> node의 네트워크 규칙을 유지관리하고 이 네트워크 규칙이 내부 네트워크 세션이나 cluster의 바깥에서 pod로 네트워크 통신을 할 수 있게 해줌
(kube-proxy는 운영 체제게 가용한 패킷 필터링 계층이 있는 경우, 이를 사용하고 아니라면 트래픽 자체를 forward함)
이해가 잘 안돼서 더 찾아보았는데 kube-controller-manager는 클러스터 상태를 모니터링하고, 정의된 상태(desired state)와 실제 상태(actual state)가 일치하지 않을 경우 이를 조정하는 역할을함
=> 이를 컨트롤 루프(Control Loop) 라고 함
kubernetes는 사용자가 원하는 상태를 선언하고(pod 3개가 실행 되기를 원함) 이에 맞춰 조정함
=> cluster 상태를 유지하기 위해 pod 생성, 삭제 등을 관리하는 역할인데 정확히는 이를 감지하고 작업을 스케줄링함
(직접 pod 생성하는게 아니라 scheduler와 kubelet에 위임)
- container runtime
컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어임
=> containerd, CRI-O와 같은 컨테이너 런타임 및 모든 Kubernetes CRI 구현체를 지원함
pod 생성 flow 간단하게 살펴보기
1. 사용자가 kubectl로 요청을 보냄
=> kubectl은 kubernetes에서 cluster에 명령을 내리는 CLI임
2. kube-apiserver가 이 요청을 받아 처리하는데 권한 확인 후 etcd에 상태를 기록함
3. kube-controller-manager가 상태 변경 이벤트를 감지하고 cluster의 상태를 조정함
4. kube-scheduler가 아직 Node가 배정되지 않은 Pod를 확인하고 Pod의 실행 위치를 결정함
5. kubelet이 Node에서 Pod의 container를 실행하고 상태를 모니터링함
'Infra > Kubernetes' 카테고리의 다른 글
Kubernetes Basic (0) | 2024.12.17 |
---|