[Kubernetes 내부 구조 이해하기] 1. 쿠버네티스 클러스터 구성 요소

그동안 쿠버네티스를 사용하면서 헷갈렸던 부분이나 사용은 했지만 원리를 알지 못했던 부분들에 대해 정리해보고자 글을 작성하려고 합니다. 이 글은 Kubernetes In Action을 읽고 참고하여 작성하는 글입니다.

---

이번 글에서는 쿠버네티스 내부 아키텍쳐에 대해 알아보겠습니다. 쿠버네티스 클러스터는 컨트롤 플레인(마스터 노드)와 워커 노드로 이루어집니다. 먼저 컨트롤 플레인부터 살펴보겠습니다.

Kubernetes Architecture (출처 : https://kubernetes.io/ko/docs/concepts/overview/components/)

---

컨트롤 플레인

컨트롤 플레인은 쿠버네티스 클러스터의 기능을 제어하는 역할을 합니다. 컨트롤 플레인은 다음과 같은 구성요소로 이루어져 있습니다.

• API Server
• Scheduler
• Controller Manager
• etcd

컨트롤 플레인에서 해당 요소들은 개별적인 프로세스로 동작합니다. 그렇다면 각 구성 요소들은 어떤 방식으로 통신을 하게 될까요? 정답은 '모든 구성요소는 API 서버로만 통신한다' 입니다. 예를 들어 컨트롤러 매니저가 etcd의 데이터를 변경하기 위해서는 API 서버를 통해 요청을 보내야합니다.

쿠버네티스 클러스터의 기능을 제어하기 때문에 컨트롤 플레인이 제 기능을 수행하지 못한다면 쿠버네티스 클러스터도 마찬가지로 본래의 기능을 수행하지 못하게 됩니다. 따라서 컨트롤 플레인이 단일 실패 지점(SPOF)이 되지 않도록 가용성을 확보해야 합니다.

구성 요소가 같은 노드에 존재해야하는 워커 노드와 다르게 컨트롤 플레인의 구성 요소는 여러 서버에 구축될 수 있습니다. 따라서 여러 노드에 컨트롤 플레인의 구성 요소 인스턴스를 여러개 띄워 가용성을 향상시킬 수 있습니다. 이 때 알아둬야 할 점은 etcd와 API 서버는 여러 인스턴스를 동시에 활성화시켜 병렬로 실행이 가능하지만, 스케줄러와 컨트롤러 매니저는 나머지 인스턴스는 대기 상태로 유지한다는 점입니다.

그럼 각 컴포넌트가 어떤 역할을 담당하는지 좀 더 자세히 알아보겠습니다.

---

etcd

쿠버네티스에서 생성된 모든 오브젝트는 상태와 메니페스트를 영속적으로 유지해야 합니다. 이를 위해서 쿠버네티스는 분산 key-value 저장소인 etcd를 사용합니다. etcd는 분산된 아키텍처 형태를 가질 수 있으며 이를 통해 고가용성 및 빠른 성능을 제공하게 됩니다. 쿠버네티스는 etcd v2나 v3를 모두 지원하지만 v3가 더 나은 성능을 보여주기 때문에 v3를 사용하는 것을 권장합니다. 따라서 v3 기준으로 데이터가 어떻게 되는지 살펴보면 etcd는 계층적 key 구조를 통해 쿠버네티스의 데이터를 저장합니다. 이 때, /registry 아래에 모든 데이터를 저장하게 됩니다.

앞서 말씀드린 것과 같이 컨트롤 플레인 내부의 다른 컴포넌트는 API 서버를 통해서만 etcd와 통신하게 됩니다. 이렇게 간접적으로 데이터를 읽거나 쓰면서 다음과 같은 이점을 얻을 수 있습니다.

• 유효성 검사
  etcd에 저장하기 전 API 서버를 통해 저장하려는 데이터의 유효성을 검증할 수 있습니다.
• 낙관적 동시성 제어
  낙관적 동시성 제어는 데이터에 잠금을 설정해 업데이트를 막는 대신 데이터에 버전을 포함하는 방식입니다. 만약 클라이언트가 데이터를 읽고 업데이트를 제출하는 사이에 버전 번호가 변경되었다면 해당 업데이트는 거부되고 이전에 업데이트 된 내용을 읽고 다시 업데이트를 수행하게 됩니다.
  
  이와 반대대는 개념인 비관적 동시성 제어는 다른 클라이언트가 데이터를 수정 및 읽을 때 데이터를 선점하여 다른 클라이언트가 작업을 수행하지 못하도록 합니다. 하지만 낙관적 동시성 제어는 데이터를 선점하지 않기때문에 성능상 이점을 가지게 됩니다. 또한, 이를 통해 오류가 발생할 가능성을 줄이고 일관성을 유지할 수 있게 해줍니다.

RAFT 합의 알고리즘

분산된 etcd 클러스터는 RAFT 합의 알고리즘을 통해 데이터의 일관성을 유지하게 됩니다. RAFT 합의 알고리즘을 간단하게 말하자면 클러스터에 Split Brain 현상이 발생하게 되면 과반수가 넘는 노드가 있는 쪽만 유효한 요청을 수행할 수 있다는 알고리즘입니다. RAFT 합의 알고리즘과 관련된 내용은 이 글을 살펴보시면 더 자세한 내용을 보실 수 있습니다. 추가적으로 etcd 인스턴스 수를 일반적으로 홀수로 배포하게 되는데 이는 짝수인 경우 과반이 존재하지 않을 가능성이 높아지기 때문입니다.

---

API Server

API Server는 클러스터의 모든 구성요소가 다른 구성요소와 통신하기 위해 필요한 중요 구성요소입니다. API Server는 클러스터와 관련된 다양한 REST API를 제공합니다.

클라이언트가 API 서버에 리소스 생성 및 조회의 요청을 보내게 되면 다음과 같은 과정을 거치게 됩니다.

1. 요청을 보낸 클라이언트가 인증된 클라이언트인지 확인
2. 인증된 사용자가 현재 보낸 요청을 수행할 수 있는 권한이 있는지 확인
3. (리소스 생성 및 수정, 삭제) 리소스를 기존에 정의된 플러그인을 통해 수정
4. 리소스의 유효성을 확인한 후 etcd에 저장
5. 리소스의 변경 사항을 리소스를 감시하고 있는 모든 클라이언트에게 통보

---

Scheduler

클라이언트가 Pod을 생성하면 리소스를 고려해 어떤 노드에 배치될지는 Scheduler가 결정하게 됩니다. 좀 더 자세히 말하면 어떤 노드에 스케줄링 될지 결정하여 Pod의 Spec을 변경하고 이를 API 서버에게 전송합니다. 최종적으로 API 서버는 워커 노드의 Kubelet에게 이 정보를 보냄으로써 Pod이 해당 노드에서 실행됩니다.

Scheduler는 먼저 디스크, 메모리, 포트, affinity, taint와 같은 다양한 조건을 통해 스케줄링 될 수 있는 노드를 선정합니다. 이렇게 선출된 노드 목록 중 우선순위를 부여하고 가장 높은 우선순위를 갖는 노드에 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 프록시 모드로 수행됩니다. 이와 관련된 내용은 커피고래님의 글을 통해 자세한 내용을 확인하실 수 있습니다. (쿠버네티스의 네트워크와 관련된 내용은 다음 글에서 다뤄보도록 하겠습니다.)

---

Deployment 생성 과정 살펴보기

마지막으로 이러한 쿠버네티스의 컴포넌트들이 어떻게 연결되어 동작하는지 알아보겠습니다. 예시는 일반적으로 생성하는 Deployment를 사용하겠습니다. 메니페스트는 쿠버네티스 문서에 나와있는 Nginx Deployment 예시를 사용하였습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

 

kubectl get events를 통해 내부적으로 발생하는 이벤트를 확인해보면 다음과 같은 로그를 얻을 수 있습니다.

Event Log

이를 통해 다음과 같은 과정을 수행함을 알 수 있습니다.

1. 요청을 보내게 되면 Deployment Controller가 새롭게 생성된 Deployment Manifest를 발견하고 해당 정보를 통해 ReplicaSet을 생성합니다.
2. ReplicaSet의 생성이 감지되면 ReplicaSet Controller는 ReplicaSet의 Pod Template을 기반으로 Pod을 생성합니다.
3. Scheduler는 적합한 노드에 Pod을 스케줄링합니다.
4. Kubelet은 Pod의 컨테이너 런타임과 이미지를 통해 컨테이너를 실행합니다.

---

이번 글에서는 Kubernetes의 내부 컴포넌트에 대해 알아보았습니다. 다음 글에서는 Pod 내부의 컨테이너들이 어떻게 같은 네트워크를 공유하는지, 그리고 쿠버네티스에서 Pod간의 네트워킹과 서비스가 어떤 방식으로 동작하는지와 같이 네트워크 부분에 대해서 다루어 보겠습니다.

 

참고자료

• RAFT 합의 알고리즘 : https://d2.naver.com/helloworld/5663184
• 쿠버네티스 네트워크 이해하기 [Service] https://coffeewhale.com/k8s/network/2019/05/11/k8s-network-02/
• Kubernetes In Action