쿠버네티스는 오픈소스입니다.
여기서 바로 Red Hat OpenShift가 필요합니다. OpenShift는 기업의 쿠버네티스 뿐만 아니라 다양한 분야에도 사용할 수 있습니다. OpenShift에는 레지스트리, 네트워킹, 텔레메트리, 보안, 자동화, 서비스 등을 비롯한 부가 기술이 모두 내장되어 있어서 기업이 강력하고 실효성 있는 쿠버네티스를 구축할 수 있습니다. OpenShift를 사용하면 개발자는 확장성, 제어, 오케스트레이션을 통해 컨테이너화 된 새 애플케이션을 구축하고 호스팅하고 클라우드에 배포함으로써 우수한 아이디어를 새로운 비즈니스에 신속하게 연결할 수 있습니다.
쿠버네티스 기술과 방식
마스터 Master
: 쿠버네티스 노드를 제어하는 머신입니다. 여기에서 모든 태스크 할당이 시작됩니다.
노드 Node
: 할당된 태스크를 요청대로 수행하는 시스템입니다. 쿠버네티스 마스터가 이러한 노드를 제어합니다.
포드 pod
: 단일 노드에 배포된 하나 이상의 컨테이너 그룹입니다. (가장 작은 단위)
포드에 있는 모든 컨테이너는 IP 주소, IPC, 호스트 이름, 기타 리소스를 공유하며 포드는 기본 컨테이너에서 네트워크와 스토리지를 추상화합니다. 이렇게 하면 클러스터에서 컨테이너를 더 쉽게 이동할 수 있습니다.
컨트롤 플레인
컨트롤 플레인은 쿠버네티스 클러스터의 기능을 제어하는 역할을 합니다. 컨트롤 플레인은 다음과 같은 구성요소로 이루어져 있습니다.
- API Server
- Scheduler
- Controller Manager
- etcd
컨트롤 플레인에서 해당 요소들은 개별적인 프로세스로 동작합니다. 그렇다면 각 구성 요소들은 어떤 방식으로 통신을 하게 될까요? 정답은 '모든 구성요소는 API 서버로만 통신한다'입니다. 예를 들어 컨트롤러 매니저가 etcd의 데이터를 변경하기 위해서는 API 서버를 통해 요청을 보내야 합니다.
etcd
쿠버네티스에서 생성된 모든 오브젝트는 상태와 메니페스트를 영속적으로 유지해야 합니다. 이를 위해서 쿠버네티스는 분산 key-value 저장소인 etcd를 사용합니다.
etcd는 분산된 아키텍처 형태를 가질 수 있으며 이를 통해 고가용성 및 빠른 성능을 제공하게 됩니다.
- 유효성 검사 : etcd에 저장하기 전 API 서버를 통해 저장하려는 데이터의 유효성을 검증할 수 있습니다.
- 낙관적 동시성 제어 : 낙관적 동시성 제어는 데이터에 잠금을 설정해 업데이트를 막는 대신 데이터에 버전을 포함하는 방식입니다.
API Server
API Server는 클러스터의 모든 구성요소가 다른 구성요소와 통신하기 위해 필요한 중요 구성요소입니다. API Server는 클러스터와 관련된 다양한 REST API를 제공합니다.
클라이언트가 API 서버에 리소스 생성 및 조회의 요청을 보내게 되면 다음과 같은 과정을 거치게 됩니다.
- 요청을 보낸 클라이언트가 인증된 클라이언트인지 확인
- 인증된 사용자가 현재 보낸 요청을 수행할 수 있는 권한이 있는지 확인
- (리소스 생성 및 수정, 삭제) 리소스를 기존에 정의된 플러그인을 통해 수정
- 리소스의 유효성을 확인한 후 etcd에 저장
- 리소스의 변경 사항을 리소스를 감시하고 있는 모든 클라이언트에게 통보
Scheduler
클라이언트가 Pod을 생성하면 리소스를 고려해 어떤 노드에 배치될지는 Scheduler가 결정하게 됩니다. 좀 더 자세히 말하면 어떤 노드에 스케줄링될지 결정하여 Pod의 Spec을 변경하고 이를 API 서버에게 전송합니다. 최종적으로 API 서버는 워커 노드의 Kubelet에게 이 정보를 보냄으로써 Pod이 해당 노드에서 실행됩니다.
Controller Manager
Scheduler를 통해 Pod이 스케줄링 되었다면 다음으로 해야 하는 작업은 해당 리소스를 원하는 상태로 만드는 작업입니다. 쿠베네티스에서 이러한 작업을 수행하는 컴포넌트를 Controller라고 합니다. 컨트롤러 매니저는 다양한 컨트롤러들을 실행하는 역할을 담당합니다.
Controller
Controller는 API 서버를 통해 리소스의 변경을 감시하고 변경하는 작업을 담당합니다. 클라이언트가 선언한 Spec으로 조정하며 새롬게 변경된 상태를 Status에 저장합니다. 쿠버네티스에는 기본적으로 제공되는 다양한 Controller가 존재합니다. (ex. Deployment, ReplicaSet, StatefulSet 등)
Worker Node
워커 노드는 실제 어플리케이션이 실행되는 노드로 kubelet과 kube-proxy라는 구성요소를 가지고 있습니다.
Kubelet
Scheduler에 의해 Pod이 스케줄링되면 API 서버는 Kubelet에게 Pod을 생성하라는 요청을 보냅니다. 이 요청을 받은 Kubelet은 지정된 컨테이너 런타임과 이미지를 사용해 컨테이너를 생성합니다. 또한, 실행 중인 컨테이너를 모니터링하며 관련된 정보를 API 서버에게 보내게 됩니다. 추가로 Liveness Probe가 설정되어 있는 경우, 컨테이너를 재시작하는 역할도 kubulet에서 담당합니다.
Kube-Proxy
Kube-Proxy는 서비스의 IP 및 포트로 들어온 접속을 서비스의 엔드포인트에 해당하는 Pod에 연결하는 역할을 담당합니다. Proxy라는 이름이 붙은 이유는 초기 쿠버네티스 버전에서 kube-proxy는 userspace에서 동작하던 프록시였기 때문입니다. 하지만 현재는 성능이 더 우수한 iptables 프록시 모드로 수행됩니다.
출처 :
https://blog.heptio.com/core-kubernetes-jazz-improv-over-orchestration-a7903ea92ca
'INFRA > DevOps' 카테고리의 다른 글
| kubernetes 설치 방법 (0) | 2022.04.20 |
|---|---|
| 애자일 소프트웨어 개발 방법론 (0) | 2022.04.14 |
| DevOps란 무엇일까? (0) | 2022.04.08 |
| 쿠버네티스란 ? (0) | 2022.04.06 |
| Container & Docker 기본 (0) | 2022.04.06 |
댓글