[kubernetes] 클러스터(cluster) - 컨트롤 플레인(Control Plane) 컴포넌트

클러스터(Cluster)란?

 클러스터(Cluster)는 여러 대의 서버(Node)를 하나의 시스템처럼 묶어 컨테이너화된 애플리케이션을 관리하는 쿠버네티스의
운영 단위이다.

• 서버1 : 관리자 역할
• 서버2 : 애플리케이션 실행
• 서버3 : 애플리케이션 실행

 이 3대의 서버를 쿠버네티스로 하나로 묶어 관리하는데, 이 전체를 Kubernetes cluster라고 부른다.  쿠버네티스가 왜 여러 서버를 하나로 묶는 이유는 아래와 같다.

• 애플리케이션을 여러 서버에 분산해 실행할 수 있다.
• 특정 서버에 장애가 발생해도 다른 서버에서 계속 서비스할 수 있다.
• 트래픽이 증가하면 서버를 추가하여 쉽게 확장할 수 있다.

 즉, 클러스터는 여러 대의 서버를 하나의 거대한컴퓨터처럼 사용하기 위한 개념이다.

 

 1. Node란?

  Node는 Kubernetes Cluster를 구성하는 각각의 서버(물리 서버 또는 가상 머신)이다.  쿠버네티스는 여러 대의 서버를 하나의
 클러스터로 묶어 관리하는데, 이 때 클러스터를 구성하는 개별 서버를 Node라고 부른다.

• Pod와 컨테이너는 실제 실행될 공간이 필요. 쿠버네티스는 Pod를 실행한 서버를 선택 배치하는데 그게 Node이다.
• 모든 Node는 역할에 따라 두종류로 나뉜다.(Control Plane Node, WorkerNode)
• Control Plane Node : 클러스터를 관리하는 서버
• Worker Node : 실제 Pod와 컨테이너를 실행하는 서버

 2. Pod란?

  Pod는 쿠버네티스에서 배포할 수 있는 가장 작은 실행 단위이다. 도커가 개별 컨테이너를 관리하는 것과 달리, 쿠버네티스는
 컨테이너뿐만 아니라 네트워크, 스토리지, 재시작 정책 등의 실행 환경도 함께 관리해야 한다.

  이를 위해 쿠버네티스는 하나 이상의 컨테이너와 해당 컨테이너들이 공유하는 실행 환경을 하나의 단위인 Pod로 묶어 관리한다.
 실제 애플리케이션은 Node 위에서 Pod 형태로 실행된다.

 

 3. Deployment란?

  Deployment는 Pod를 원하는 개수만큼 유지하고, 배포와 업데이트를 관리해주는 쿠버네티스 객체(Object)이다. 
 이는 쿠버네티스의 관리 객체이고, Control Plane이 관리한다.

 

 4.  컨트롤 플레인(Control Plane) 컴포넌트란?

  컨트롤 플레인의 컴포넌트들은 클러스터에 대한 전반적인 결정(예:스케줄링)을 내리고, 클러스터 이벤트를 감지하고 응답한다. 

 (예: Deployment의 replicas 필드가 충족되지 않을 때 새로운 파트 시작)   간단하게 말해 관리자라고 볼 수 있다.

  소규모 환경에서는 하나의 머신에 모두 배치하는 경우가 많지만, 운영(Production) 환경에서는 고가용성(HA)을 위해 여러 서버에
 분산 배치하는 경우가 일반적이다.  또한 컨트롤 플레인 서버는 클러스터 전체를 관리하는 핵심 컴포넌트가 실행되는 곳이므로, 안정성과 보안을 위해 일반 사용자 워크로드(Pod)를 함께 실행하지 않는 것이 일반적이다. 

• 어떤 서버에 컨테이너를 띄울지 결정
• 장애가 나면 다시 실행
• 노드 상태 감시
• 사용자가 내린 명령 처리

  1) kube-apiserver :"단순한 프론트엔드가 아닌 '관문의 중심'"

  쿠버네티스 API를 외부에 노출하는 컨트롤 플레인 컴포넌트로, 컨트롤 플레인의 프론트엔드 역할을 한다. 

 수평확장이 가능하도록 설계되어 있어, 인스턴스를 여러 개 띄우고 트래픽을 분산 시킬 수 있다.  

• 인증 및 인가 (Auth)
  : 아무나 클러스터를 제어하지 못하도록, 누가(인증), 무엇을(인가) 할 수 있는지 검증하는  보안의 핵심 관문
• 상태 저장소와의 유일한 통신 창구
  : 클러스터 내의 다른 모든 컴포넌트(스케줄러, 컨트롤러 매니저, 노드의 kubelet 등)는 etcd와 직접 통신하지 않는다.
   통신은 오직 API 서버만 etcd 에 접근(권한)할 수 있으며, 나머지는 API서버를 통해서만 데이터를 읽고 쓴다(행위).
• 워크플로우의 시작
  : 사용자가 kubectl을 통해 명령을 내리는 것도, 내부 컴포넌트가 상태를 변경하는 것도 모두 API서버를 거쳐
   이벤트를 기록한다.

  2) etcd : "단순 저장이 아닌 '클러스터의 뇌'"

   모든 클러스터 데이터를 저장하는 쿠버네티스의 백업 저장소로 사용되는 단순 저장이 아닌 클러스터의 뇌라고 볼 수 있으며
  일관성 있고 고가용성을 갖춘 키-값(key-value) 저장소이다.  etcd를 백업 저장소로 사용하는 경우 반드시 백업 계획을
  마련해야 한다.

• 최종 상태(Desired State)의 보관소
  : 사용자가 "웹 서버 3개를 띄워달라"고 요청하면, API 서버는 이 정보를 etcd에 저장한다.  이후 클러스터 내 모든 작업은
   etcd에 기록된 이 '목표 상태'와 '현재 상태'를 비교하며 진행된다.
• 분산 합의 알고리즘(Raft)
  : etcd는 Raft 알고리즘을 사용해 데이터의 일관성을 유지한다.  노드 중 일부가 죽어도 데이터가 유실되지 않토록 투표 과정을
   거치는데, 이 때문에 홀수 개(보통 3개, 5개)로 구성하는 것이 관례이다.
• 백업의 중요성
  : etcd가 손상되면 쿠버네티스는 클러스터의 현재 상태(Pod의 개수, 네트워크 설정 등)를 완전히 잃어버리게 되어
   클러스터 전체 복구가 불가능한 장애로 직결되므로 백업을 철저히 해야한다.

  3) kube-scheduler : "최적에 장소를 찾는 부동산 중개인"

   노드가 배정되지 않은 새로 생성된 파드(Pod)를 감지하고, 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트이다. 

• 스케줄링 결정 시 고려되는 요소들
  : 개별/전체 리소스 요구사항, 하드웨어/소프트웨어/정책 제약, 어피니티(친화성) 및 안티-어피니티 설정,
   데이터 지역성, 워크로드간 간섭, 데드라인
• 동작 방식
  : 스케줄러는 etcd를 직접 보지 않는다. kube-apiserver 에게 "혹시 노드가 안 정해진 파드(Pending상태)가 있나?" 라고
   끊임없이 물어보거나(Watch), API 서버로부터 정보를 받는다.
• 핵심 결과
  : 결정을 내린 뒤, 다시 kube-apiserver 에게 "이 파드(Pod)는 A 노드에 배치하세요"라고 '바인딩(Binding)' 요청을 보낸다.
• 중요한 점
  : 스케줄러는 파드(Pod)를 직접 실행(Running)시키지 않고 "어디서 실행해라"라고 지정만 하고 끝낸다.  실제 실행은
   각 노드에 있는 kubelet 이 담당한다.

  4) kube-controller-manager: "지치지 않는 감시자(Self-healing)"

   컨트롤러 프로세스들을 실행하는 컨트롤 플레인 컴포넌트이다.  논리적으로는 각 컨트롤러가 별개의 프로세스이지만, 복잡성을
  줄이기 위해 하나의 바이너리로 컴파일되어 단일 프로세스로 실행된다.

• 왜 'Controller' 인가
  : 쿠버네티스는 "현재 상태(Current State)를 희망 상태(Desired State)와 일치 시키는 것" 이 목표이다.
   컨트롤러 메니저는 수 많은 컨트롤러들을 묶어놓은 관리자로서, 끊임없이 두 상태를 비교한다.
  
  
• Node 컨트롤러
  : 노드가 다운될 때 감지하고 대응하는 컨트롤러이며 클러스터에 등록된 모든 노드는 '준비됨(Ready) 상태여야 한다.
       ex) 상황 : "원래 노드가 5개여야 하는데 , 하나가 응답이 없네? (장애 감지)
             수행 : 해당 노드를 NotReady 상태로 표시하고, 기존 파드(Pod)를 종료(Evication)한 뒤 다른 노드에
                      새로운 파드(Pod)를 재생성하도록 한다.
  
  
• ReplicaSet 컨트롤러
  : 사용자가 Deployment를 생성하면 내부적으로 Replicaset이 만들어지고, 그 ReplicaSet을 관리하는 것이
   ReplicaSet 컨트롤러이다.  이 컨트롤러는 사용자가 지정한 개수만큼 파드(Pod)가 항상 떠 있도록 보장한다.
       ex) 상황 : "원래 파드(Pod)가 3개여야 하는데, 2개밖에 없네? (개수 불일치)
             수행 : 부족한 파드 1개를 즉시 새로 생성한다.
  
  
• Job 컨트롤러
  : 일회성 작업을 나타내는 Job 오브젝트를 감시하고 파드를 생성하며 특정 작업(Job)이 성공적으로 끝날때까지
   수행되어야 한다.
       ex) 상황 : "백업 작업 파드가 0개네?" (목표미달)
             수행 : 즉시 백업 파드를 하나 새로 생성한다.
  
  
• EndpointSlice 컨트롤러
  : 서비스와 파드를 연결하는 EndpointSlice 오브젝트를 관리한다.
       ex) 상황 : "파드 IP가 10.0.0.1에서 10.0.0.2로 바뀌었네?" (변경 감지)
             수행 : 서비스가 트래픽을 전달 할 수 있도록 EndpointSlice 정보를 갱신한다.
  
  
• ServiceAccount 컨트롤러
  : 새 네임스페이스에 기본 ServiceAccount를 생성한다.
       ex) 상황 : "새 네임스페이스에 신분증(SA)가 없네?" (계정 부재)
             수행 : 기본 default 신분증을 생성하여 넣어준다.
  
  

  5) cloud-controller-manager

   클라우드 특화 제어 로직을 포함하는 컨트롤 플레인 컴포넌트이다.  클러스터를 클라우드 제공업체(AWS, GCP, Azure)의 API와
  연결하여, 클라우드 플랫폼과 상호작용하는 컴포넌트를 클러스터 내부 컴포넌트와 분리한다.
  (온프레미스 환경이나 로컬환경에서는 존재하지 않음)

 

• cloud-controller-manager의 존재이유
  : 과거 초기 쿠버네티스는 kube-controller-manager안에 AWS, GCP를 제어하는 코드가 포함되어 있었으나 다음과 같은
   문제들이 발생했었다.  아래와 같은 문제들을 해소하기 위해 클라우드 관련 로직만 분리해서 만들어 관리하게 되었다.
    ⇒ AWS기능이 업데이트 시 쿠버네티스 전체를 업데이트 해야한다.
    ⇒ 새로운 클라우드 환경이 쿠버네티스를 지원하려면 쿠버네티스의 소스와 코드를 합쳐야 했다.
  
  
• 온프레미스(On-premise)에 없는 이유
  : 자체 서버실(내컴퓨터, 회사서버)에서 쿠버네티스를 돌릴 때는 명령을 내릴 외부 '클라우드 API(AWS 등)'가 없기 때문에
   컴포넌트 자체를 둘 피료가 ㅇ벗다.
  
  
• Node 컨트롤러
  : Node 컨트롤러는 응답하지 않는 노드가 단순한 장애 상태인지, 아니면 클라우드에서 실제로 삭제된 인스턴스인지를
   확인하는 역할을 수행한다.  
    일반적 온프레미스 환경(개인서버나 회사서버)에서는 노드가 응답하지 않으면 장애로 판단하고 복구 작업을 진행하면
   되지만 클라우드 환경에서는 사용자가 AWS 콘솔같은 관리 화면에서 몇번의 클릭만으로 가상 머신(EC2 등)을
   종료(Terminate)하거나 삭제할 수 있다.
       ex) 상황 : 특정 노드의 응답이 없음.  단순 네트워크 끊김인지 사용자가 클라우드 콘솔(AWS 등)에서 삭제한건지 확인.
             수행 : AWS API와 상호작용을 통해 인스턴스 삭제여부를 확인해 삭제 되었다면 쿠버네티스 해당 노드 삭제 처리.
  
  
• Route 컨트롤러
  : Route 컨트롤러는 쿠버네티스 노드 간 네트워크 통신이 가능하도록 클라우드 인프라의 라우팅 정보를 관리하는 역할을 한다.
   클라우드 환경에서는 노드가 추가되거나 삭제될 때 각 노드의 Pod 네트워크 대역(CIDR)에 대한 라우팅 정보를
   클라우드 라우팅 테이블에 등록해야 한다.  Route 컨트롤러는 이러한 라우팅 규칙을 자동으로 생성/수정/삭제하여 서로 다른
   노드에 있는 Pod들의 정상적으로 통신할 수 있도록 지원한다.
       ex) 상황 : 클러스터에 새 노드가 추가되어 다른 노드들과 통신을 위한 경로 설정 필요.
             수행 : 클라우드 인프라(VPC 라우팅 테이블 등)의 네트워크 경로 설정을 자동으로 업데이트 처리.
  
  
• Servie 컨트롤러 
  : Service 컨트롤러는 로드밸런서(LoadBalancer) 타입의 Service가 생성되거나 변경될 때 클라우드 제공자의 로드밸런서를 
   자동으로 생성/수정/삭제하는 역할을 한다.
    예를 들어 AWS에서 type : LoadBalancer인 Service 생성하면, Service 컨트롤러가 자동으로 AWS의
   로드밸런서(예: ELB 또는 NLB)를 생성하고 이를 쿠버네티스 Service와 연결한다.  이후 Service가 변경되면 로드밸런서
   설정을 갱신하고, Service가 삭제되면 관련 로드밸런서도 함께 제거한다.
      ex) 상황 : "사용자가 외부 노출용 Service(Type: LoadBalancer)를 신청. (요청감지)
            수행 : AWS의 ELB/NLB 같은 실제 클라우드 로드밸런서를 자동으로 생성하고 연결해준다. 
                     반대로 서비스 삭제 시 클라우드 로드밸런서도 알아서 삭제한다.