Kubernetes 04 - Kubernetes Architecture 1

Introduction to Kubernetes

출처 : https://courses.edx.org/courses/course-v1:LinuxFoundationX+LFS158x+3T2020/course/#block-v1:LinuxFoundationX+LFS158x+3T2020+type@chapter+block@48d68448eff24f02bcb78470dec9c6a1

이미지 출처 : https://kubernetes.io/docs

Will Be Check

• Discuss the Kubernetes architecture.

• Explain the different components for master and worker nodes.

• Discuss about cluster state management with etcd.

• Review the Kubernetes network setup requirements.

  내용이 많아서 다음 글에서 풀이 올립니다.

• Kubernetes Architecture

Introduction

이번 쳅터에서는 쿠버네티스의 아키텍처에 대해서 배울 겁니다. 다시 말해 Control Plane의 구성 요소와 마스터 노드, 워커 노드, 클러스터 상태 관리자, 네트워크 설정 요구사항 등으로 구성된 아키텍처에 대하여 배울 예정입니다.

Kubernetes Architecture

위의 그림은 매우 high level에 해당하는 구조 입니다.

control plane에 존재하는 하나 이상의 master 노드들이 있고, 그 외로 존재하는 Node : worker node를 볼 수 있습니다.

Master node overview

마스터 노드는 Control plane 영역에 있어서 (이하 통제부) 쿠버네티스의 클러스터에 대한 통제를 하기 위한 환경을 제공합니다.

즉, 클러스터의 모든 연산의 뒤에서 담당하는 두뇌입니다. 유저들은 CLI, WebUI, API 등을 통해서 request를 보낼 수 있습니다.

뇌인 마스터 노드가 죽게 되면 통제부는 중지되고 이로 인해 서비스는 중단 혹은 붕괴되어 버립니다. 그래서 마스터 노드는 High Availability (고가용성) 모드로 작동됩니다. 또한 작동하는 마스터 노드가 중단될 때를 고려해서 클러스터 일에 관여해서 작동하는 일은 하나의 마스터 노드가 하지만 복제본들을 만들며 동기화를 통해서 같은 정보를 가지게 합니다. 이는 복원력을 보장하게 됩니다.

물론 사용하지도 않는 고가용성의 노드를 생성해야 하는 건 막대한 자원 낭비일 수 있으나 앞서 말했다시피 마스터 노드의 중단은 서비스의 중단을 뜻하므로 얼마의 자원 혹은 비용이 들던 유지해야 한다는 입장입니다.

etcd는 클러스터의 상태를 유지하기 위한 데이터를 key-value 쌍으로 들고 있는 저장소입니다. master node 위에 존재하거나 아니면 다른 통제부 요서의 간섭을 받지 않게 해서 데이터의 손실이 발생할 일을 줄이기 위해서 외부의 분리된 호스트에 저장되기도 합니다.

하지만 외부에 저장하지 않고 마스터 노드에 etcd 가 있다면 마스터 노드의 복제본에 의해서 etcd 또한 복제되어 resiliency(복원력)을 보장받습니다.

Master Node Components

마스터 노드가 실행하는 통제부 요소들

• API Server
• Scheduler
• Controller Managers
• Data Store

추가 적으로 마스터 노드에서 실행되는 요소들

• Container Runtime
• Node Agent
• Proxy

Components Running On The Master Node

API Server

API Server는 클러스터 상태에 대한 문의가 필요한 일을 처리하는 통제부(Control plane)의 중간 인터페이스인 API Server입니다.

사용자, 운영자 및 외부 에이전트로부터 호출된 RESTful 호출을 가로 채서 유효성 검사와 처리를 합니다.

이부에서 출된 일을 처리하면서 k8s의 현재 상황을 확인하기 위해서 유일하게 etcd에서 현재 상태를 읽고, 일을 처리한 후에 key-value 데이터 형태로 저장합니다.

API Server는 많은 요소들을 커스터 마이징 할 수 있습니다.

또한 기본 API 서버를 모든 보조 사용자 지정 API 서버에 대한 프록시로 변환하고 사용자 정의 정의 규칙에 따라 수신되는 모든 RESTful 호출을 해당 서버로 라우팅 하는 구성인 사용자 지정 보조 API 서버의 추가도 지원합니다.

Scheduler

스케줄러는 쿠버네티스의 상태 및 새로운 오브젝트의 요구사항을 가지고 어디에 배포하면 좋을지, 언제 배포하면 좋을지, 누구를 먼저 배포할지 결정합니다.

자세히 들어가면 스케줄러는 앞서 말한 API server를 통해서 새로운 오브젝트의 요구사항과 worker node들에 대해서 사용하고 있는 리소스의 사용량을 가져옵니다.

요구사항에는 사용자 및 운영자가 지정한 (disk === ssd 같은) 제약 조건 등이 들어가 있습니다.

이러한 요구사항들과 현재 상태를 통해서 먼저 배포될 오브젝트들에 우선순위를 매기고 과 배포되기 좋은 worker node들에 대해서 가능한 후보들을 추립니다.

이러한 의사 결정 프로세스의 결관 API Server를 통해서 다른 배포 처리 기관에게 새로운 object에 대한 배포를 위임합니다.

스케줄러도 앞서 언급한 API Server처럼 커스터 마이징이 가능합니다. 물론 추가적인 스케줄러도 생성 가능합니다. 특정 object에 대해서는 스케줄러를 지정해 줄 수 있으며 지정해주지 않을 시 default Scheduler에 의해서 관리됩니다.

Controller Managers

우선 컨트롤러는 지속 적으로 쿠버네티스의 상태와 바람직한 상태를 비교합니다. 불일치할 시 일 치 할 때까지 시정 조치를 취합니다.

Controller Manager는 통제부의 구성요소로 위에서 설명한 컨트롤러가 마스터 노드에서 작동하도록 관리합니다.

kube controller manager는 노드가 사용할 수 없을 때 컨트롤러를 사용하여 바람직한 상태인지 확인하고 엔드 포인트 , 서비스 어카운트, API 접근 토큰을 생성합니다.

cloud-controller-manager는 노드가 사용할 수 없을 때 컨트롤러를 사용하여 클라우드 공급자의 인프라와 상호 작용하며 스토리지 볼륨을 관리하고 밸런싱 및 라우팅을 관리합니다.

Data Store

etcd는 쿠버네티스의 클러스터 상태를 관리하는 데 사용되는 key-value 데이터 저장소입니다. 새 데이터는 저장소에 추가만 되며 대체되거나 수정되지는 않습니다.

앞서 언급한 것처럼 etcd는 무조건 apiserver를 통해서만 접근 가능합니다.

사용되지 않는 데이터는 데이터 저장소 크기를 최소화하기 위해 주기적으로 압축될 뿐입니다.

etcd는 cli 툴을 제공하는데 (etcdctl) 이를 통해서 백업, 스냅숏 및 복원이 가능하고 이는 단일 etcd를 사용하는 클러스트에서 매우 유용합니다.

그러나 STG or PROD 환경에서는 클러스터 구성 데이터 복원력을 위해서는 가용성 모드로 마스터 노드들을 복제하는 것이 매우 중요합니다. (아래 그림과 같은 구조로)

외부 host에 etcd host를 따로 둔다면 아래 그림처럼 됩니다.

독립된 공간에 etcd를 두기 때문에 장애 발생 가능성을 낮출 수 있습니다.(아래 그림과 같은 구조로)

위의 두 방법 모드 가용성 높은 구성입니다.

추가 적으로 etcd는 RAFT CONsensus Algorithm (https://web.stanford.edu/~ouster/cgi-bin/papers/raft-atc14) 아..못보겠다.. 를 통해서 일부가 망가져도 일부는 살아남아서 일관된 그룹으로 작동 할수 있도록 합니다.(항상성 유지)

즉 언제든지 그룹의 노드 중 하나가 마스터가 되고 나머지는 팔로워 상태를 유지하다가 마스터 노드가 실패하면 나머지 노드 중 하나가 마스터가 되고 나머지는 팔로워가 되면서 항상성을 유지합니다.

etcd는 GO언어로 작성되었으며 앞서 말한 kubernetes의 상태를 저장하는 외에도 서브넷, configMap, Secrets등과 같은 세부 정보를 저장합니다.

다음 장에는 worker node에 대해서 다루어 보겠습니다. 이번 글은 특히 길었네요 :) 항상 파이팅입니다.