[Kubernetes]쿠버네티스 클러스터의 전체 구조

 

쿠버네티스 클러스터의 전체구조

마스터는 보통 고가용성을 만족시키기 위해 서버 3대 정도 구성해서 운영한다.
실제 클러스터를 관리하는 리더 마스터는 1대고 나머지 2대는 대기한다.
만약 리더 마스터에 장애가 발생하면 자연스럽게 2대 중 1대가 리더를 위임한다.
클러스터를 좀 더 안정적으로 운영하려면 마스터를 서버 5대로 구성할 수도 있다.

각 컴포넌트 중심에 kube-apiserver가 있다.
모든 통신은 kube-apiserver가 중심이된다.
특히 etcd에는 kube-apiserver만 접근 가능하다.

마스터를 보면 kublet이 마스터에 있는 도커를 관리한다.
관리용 컴포넌트 모두는 하이퍼큐브라는 바이너리 파일로 컴파일 되어 있고,

실행할 때 옵션을 설정해 각 컴포넌트의 역할을 수행한다.

etcd는 컨테이너가 아니라 별도의 프로세스로 설정되어 있음.
노드 역시 kublet으로 관리 한다. kublet은 마스터의 kube-apiserver와 통신하면서 파드의 생성, 관리, 삭제를 담당한다.

쿠버네티스의 주요 컴포넌트

쿠버네티스는 근본적으로 클러스터를 관리한다.
즉, 여러가지 컴포넌트를 관리한다.

쿠버네티스의 컴포넌트는 세 가지로 구분한다.

1. 마스터용 컴포넌트
2. 노드용 컴포넌트
3. 애드온용 컴포넌트

1. 마스터용 컴포넌트

마스터용 컴포넌트는 실제 클러스터 전체를 관리한다.
마스터용 컴포넌트 종류는 아래와 같다.

1. etcd
2. kube-apiserver
3. kube-scheduler
4. kube-controller-manager
5. cloud-controller-manager

1-1. etcd
etcd는 코어에서 개발한 key-value 저장소이다. 분산 시스템에서 노드사이의 상태를 공유하는 raft알고리즘을 구현한 것이다. 쿠버네티스에서 필요한 모든 데이터를 저장하는 데이터 베이스이다.

 

1-2. kube-apiserver
kube-apiserver는 쿠버네티스 클러스터의 API를 사용할 수 있도록 하는 컴포넌트다. 클러스터로 온 요청이 유요한지 검증한다. 쿠버네티스는 MSA로 서로 분리된 컴포넌트 여러개로 구성되어 있다. 쿠버네티스로 보내는 모든 요청은 kube-apiserver를 이용해서 다른 컴포넌트로 전달 된다. 또한, 확장할 수 있도록 설계했으므로 서버 여러대에 여러개의 kube-apiserver를 구성할 수 있다.

 

1-3. kube-scheduler
kube-scheduler는 현재 클러스터 안에서 자원 할당이 가능한 노드 중 알맞은 노드를 선택해서 새롭게 만든 파드를 실행한다. 파드는 처음 실행할 때 여러가지 조건을 설정하며, kube-scheduler가 조건에 맞는 노드를 찾는다.

 

1-4. kube-controller-manager

쿠버네티스는 파드들을 관리하는 컨트롤러가 있다. 컨트롤러 각각은 롤시적으로 개별 프로세스이지만 복잡도를 줄이기 위해 바이너리 파일 하나로 컴파일해서 단일 프로세스로 실행된다.

 

1-5. cloud-controller-manager

쿠버네티스의 컨트롤러들을 클라우드 서비스와 연결해 관리하는 컴포넌트이다. 보통 아래의 네가지 컨트롤러 컴포넌트를 관리한다.

- node controller

- route controller

- service controller

- volume controller

 

2. 노드용 컨포넌트

노드용 컴포넌트는 쿠버네티스 실행환경을 관리한다.
대표적으로 각 노드의 파드 실행을 관리하며, 컴포넌트는 kublet, kube-proxy, 컨테이너 런타임 등이 있다.

 

2-1. kubelet
kubelet은 클러스터 안 모든 노드에서 실행되는 에이전트다. 파드 컨테이너들의 실행을 직접 관리한다. kubelet은 파드스펙이라는 조건이 담긴 설정을 전달받아서 컨테이너를 실행하며, 컨테이너가 정상적으로 실행되는지 헬스 체크를 한다.

 

2-2. kube-proxy
쿠버네티스는 클러스터 안에 별도의 가상 네트워크를 설정하고 관리한다.
kube-proxy는 이런 가상 네트워크의 동작을 관리하는 컴포넌트이다.

 

2-3. container runtime

컨테이너 런타임은 실제로 컨테이너를 실행시킨다. 가장 많이 알려진 런타임이 바로 도커이다.

 

3. 애드온

애드온은 클러스터 안에서 필요한 기능을 실행하는 파드이다.
네임스페이스는 kube-system이며 애드온으로 사용하는 파드들을 관리한다.

 

3-1. 네트워킹 애드온
쿠버네티스는 클러스터 안에 가상 네트워크를 구성할 때 kube-proxy 외에 네트워킹 애드온(플러그인)을 시용한다. AWS, 애저, gcp 같은 클러우드 서비스에서 제공하는 쿠버네티스를 사용한다면 별도의 네트워킹 애드온을 제공하니 신경쓰지 않아도 된다.

 

3-2. DNS 애드온
DNS 애드온은 클러스터 안에서 동작하는 DNS 서버이다. 쿠버네티스 안에 실행된 컨테이너들은 자동으로 DNS 서버에 등록된다. 주로 사용하는 DNS애드온은 kube-dns와 CoreDNS가 있는데, 최근에는 CoreDNS를 위주로 사용한다.

 

3-3. 컨테이너 자원 모니터링

컨테이너 자원 모니터링은 클러스터 안에서 실행중인 컨테이너의 상태를 모니터링 하는 애드온이다.

 

3-4. 클러스터 로깅

클러스터 안 개별 컨테이너의 로그와 쿠버네티스 구성 요소의 로그들을 중앙화하여 로그 수집 시스템에 모아서 보는 애드온 이다. 이것 역시 클라우드 서비스를 이용 중이라면 제공하는 로깅서비스를 사용하면 되지만, 직접 쿠버네티스를 설치해서 사용할 때는 애드온 사용을 고려해야한다.
주로 ElasticSearch kibana를 사용한다.

 

Object와 Controller

쿠버네티스는 크게 오브젝트와 오브젝트를 관리하는 컨트롤러로 나눈다.
사용자는 템플릿 등으로 쿠버네티스의 자원에 desired state를 정의하고 컨트롤러는 사용자의 요구의 맞게 현재 상태가 일치하도록 오브젝트를 생성, 삭제한다.
대표적인 오브젝트와 컨트롤러는 아래와 같다.

• 오브젝트

  • pod
  • service
  • volume
  • namespace

• 컨트롤러

  • ReplicaSet
  • Deployment
  • StatefulSet
  • DaemonSet
  • Job

네임스페이스(namespace)

 

네임스페이스는 쿠버네티스 클러스터 하나를 여러 개 논리단위로 나눠서 사용하는 것이다. 덕분에 쿠버네티스 클러스터 하나를 여러 개 팀이나 사용자가 공유할 수 있다.
또한, 클러스터 안에서 용도에 따라 실행해야 하는 앱을 구분할 때도 네임스페이스를 사용한다.

쿠버네티스를 처음 설치하면 기본으로 몇 개의 네임스페이스가 생성된다. 아래 명령어로 확인해보자.

현재 name-space 확인 
$ kubectl get namespaces

• default : 기본 네임스페이스이다. 쿠버네티스에서 명령을 실행할 때 별도의 네임스페이스를 설정하지 않으면 항상 default에 명령이 적용된다.
• kube-system : 쿠버네티스 시스템에서 관리하는 네임스페이스이다. 이 네임스페이스에는 쿠버네티스 관리용 파드나 설정이 있다.
• kube-public : 클러스터 안 모든 사용자가 읽을 수 있는 네임스페이스로, 보통 클러스터 사용량 같은 정보를 여기서 관리한다.
• kube-node-lease : 각 노드의 lease object들을 관리하는 네임 스페이스이다.

kubectl로 네임을 지정해서 사용할 때는 네임스페이스를 명시해야 한다.
근데 default이외의 네임스페이스를 사용할 때 매번 옵션을 입력하는 것은 번거롭다.
이때는 기본 네임스페이스를 변경해 사용할 수 있다.
기본 네임스페이스를 변경하기 위해서는 먼저 컨텍스트 정보를 확인해야 한다.

 

현재 context 정보 확인

$ kubectl config current-context docker-desktop

해당 컨텍스트의 상세정보 확인

$ kubectl config get-contexts docker-desktop

 

namespace가 기본으로 되어 있을 경우 비어있다.
원하는 namespace로 바꿔주자.

 

$ kubectl config set-context docker-desktop --namespace=kube-system

 

다시 상세정보가 확인하면 바뀐것을 알 수 있다.

기본 네임스페이스가 제대로 변경 됬는지 확인한다.

 

$ kubectl config view | grep namespace

다시 default로 돌릴때는 --namespace=default로 설정해주면 된다.
namespace를 쉽게하고 싶다면 kubens 를 다운 받아서 사용할 수도 있다.

 

 

템플릿

쿠버네티스 클러스터의 오브젝트나 컨트롤러가 어떤 상태여야 하는지 적용할 때는 YAML형식의 템플릿을 사용한다. 자주 사용하는 필드 위주로 앞으로 설명할 예정이다.

 

 

 

출처 : 쿠버네티스 입문 (저.정원천)