Kubernetes (1)

쿠버네티스

---

간단한 구조도

쿠버네티스(Kubernetes)는 컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동화하고 조율하기 위한 오픈소스 플랫폼이다. 구글이 개발한 이 시스템은 일주일에 수십억 개의 컨테이너를 생성하고 관리하던 경험을 바탕으로 만들어졌으며, 현재는 클라우드 네이티브 컴퓨팅 재단(CNCF)에서 관리하고 있다. 흔히 'K8s'라고도 불리는데, 이는 'K'와 's' 사이에 8개의 문자가 있다는 의미에서 비롯되었다.

쿠버네티스 아키텍처 구성요소

출처 : 쿠버네티스 공식홈페이지

클러스터(Cluster)

클러스터 아키텍쳐 (출처 : medium)

클러스터는 쿠버네티스의 가장 기본적인 단위로, 노드라고 불리는 머신들의 집합이다. 이 클러스터는 컨테이너화된 애플리케이션을 실행하며, 컴퓨팅 리소스를 공유하여 애플리케이션의 배포와 관리를 담당한다.

마스터 노드(Master Node/Control Plane)

마스터 노드는 쿠버네티스 클러스터를 관리하는 컨트롤러이다. 클러스터의 상태가 요구하는 조건에 맞게 유지되도록 관리하며, 다음과 같은 주요 컴포넌트로 구성된다:

kube-apiserver

• 클러스터 내 모든 작업을 다룬다.(오케스트레이션)
• 요청 문법 검사, 노드 상태 확인, 실행 명령 전달 등의 역할을 수행한다
• kubectl의 모든 명령어는 kube-api server에 의해 실행을 완료할 수 있다.

아래는 kubectl 명령어를 실행하는 과정이다. 예를 들어, 한 클러스터 내 모든 노드의 정보를 가져오려면 kubectl get nodes와 같은 명령어를 실행한다. 그러면 kubectl이 내부 kubeconfig를 참조하여 kube-apiserver에 https 요청을 보낸다.

  

    
    
    
    
  
   User
     │
  kubectl
     │  (1) REST API 요청 (kubeconfig 참조)
     ▼
┌──────────────┐
│ API Server   │
│ ──AuthN/Z──  │
│ ──Validate─  │
│ ──etcd I/O── │
└──────────────┘
     │
     ▼
   etcd
 (분산 키-값 저장소)

etcd

• 클러스터의 모든 데이터를 저장하는 고가용성 키-값 저장소
• 워커노드의 kubelet에서 보내는 노드 상태 정보를 저장한다
• 클러스터의 데이터는 다양한데, node, pods, config, bindings 등등. kubectl에 필요한 정보는 모두 etcd에서 온다.
• 관련된 모든 변경사항은 곧바로 업데이트된다.
• 고가용성 환경에서는 여러 마스터 노드가 있다. 따라서 여러 etcd가 있는데 이때는 etcd가 서로의 데이터를 공유해야 한다.

아래는 쿠버네티스 레포지토리에서 볼 수 있는 etcd 코드 중 일부다.

  

    
    
    
    
  
// NewFromCluster creates an etcd client for the etcd endpoints present in etcd member list. In order to compose this information,
// it will first discover at least one etcd endpoint to connect to. Once created, the client synchronizes client's endpoints with
// the known endpoints from the etcd membership API, since it is the authoritative source of truth for the list of available members.
func NewFromCluster(client clientset.Interface, certificatesDir string) (*Client, error) {
    // Discover at least one etcd endpoint to connect to by inspecting the existing etcd pods

    // Get the list of etcd endpoints
    endpoints, err := getEtcdEndpoints(client)
    if err != nil {
        return nil, err
    }
    klog.V(1).Infof("etcd endpoints read from pods: %s", strings.Join(endpoints, ","))

    // Creates an etcd client
    etcdClient, err := New(
        endpoints,
        filepath.Join(certificatesDir, constants.EtcdCACertName),
        filepath.Join(certificatesDir, constants.EtcdHealthcheckClientCertName),
        filepath.Join(certificatesDir, constants.EtcdHealthcheckClientKeyName),
    )
    if err != nil {
        return nil, errors.Wrapf(err, "error creating etcd client for %v endpoints", endpoints)
    }

    // synchronizes client's endpoints with the known endpoints from the etcd membership.
    err = etcdClient.Sync()
    if err != nil {
        return nil, errors.Wrap(err, "error syncing endpoints with etcd")
    }
    klog.V(1).Infof("update etcd endpoints: %s", strings.Join(etcdClient.Endpoints, ","))

    return etcdClient, nil
}

kube-controller-manager

• 노드, 파드, 서비스 등을 모니터링하여 요구된 명세와, 현재 상태가 일치하도록 유지한다
• 앞으로 다룰 다양한 컨트롤러(Job, Replicaset, DaemonSet, CronJob, deployment 등등)가 전부 이를 통해 구현된다. 다시 말해, 컨트롤러의 통합 관리자이다.

기본적으로 kube-system namespace 안에 Pod 형태로 작동된다!

kube-scheduler

• 노드의 상태(하드웨어/소프트웨어, 리소스, 요구사항 등)를 확인하여 파드를 어떤 노드에 배치할지 결정한다. 정확히 이 역할만 한다.
• 파드를 두는 것이 아닌 '어느 노드에 둘지 결정'만 하는 것.

각 노드에 점수를 매겨서 파드 생성 요청이 들어오면 파드의 요구 자원할당량에 따라 어느 노드에 배치할지 결정하도록 한다.

워커 노드(Worker Node)

워커 노드는 마스터의 명령을 받아 실제로 컨테이너가 실행되는 서버이다. 다음과 같은 주요 컴포넌트로 구성된다:

kubelet

• 노드에 배포되는 에이전트로, 파드 내의 컨테이너가 올바르게 동작하도록 관리한다
• cAdvisor를 통해 노드 리소스를 수집하고, 일정한 가격으로 마스터 노드(정확히는 kube-apiserver)에 정보를 전송한다.

kube-proxy

• 서비스를 구현하는 네트워크 프록시로, 노드로 들어오는 트래픽을 적절한 컨테이너로 라우팅한다.
• CNI(Container Network Interface) 규격에 통합되면 어떤 것도 대체할 수 있다.
• kubernetes에 내장된 kube-proxy를 사용할 수 있지만 정교한 기능 사용을 위해 다른 네트워크 인터페이스를 사용할 수 있다. 대표적인 예로 Calico가 있다.

컨테이너 런타임(Container Runtime)

• 파드에 배포된 컨테이너를 실행하는 소프트웨어
• Docker, CRI-O, containerd 등이 있으며, Kubernetes 1.24부터는 컨테이너 런타임 인터페이스(CRI)를 준수해야 한다.

간단한 쿠버네티스 Yaml 파일 작성

---

yaml 파일로 쿠버네티스의 모든 컴포넌트를 생성할 수 있다. 가장 기본이 되는 파일의 속성은 다음과 같다.

  

    
    
    
    
  
apiVersion:
kind:
metadata:
    name:
    label:
        label_name:lavbel_value
spec:
    containers:
        - name: nginx-container
          image: nginx

• apiversion : 각 컴포넌트에 따른 쿠버네티스 api 버전이 필요하다. Pod를 생성한다고 가정했을 때 초기에는 v1으로 명명한다. controller는 보통 'app/v1'으로 시작한다.
• kind : 컴포넌트 유형을 가르킨다. 대문자부터 시작한다. 파드일 경우 'Pod'로 작성한다.
• metadata : 말그래도 부가적인 정보, 메타데이터다. 컴포넌트의 명칭 혹은 집단화를 위한 라벨링 정보를 담는다.
• label : 라벨에서는 사용자가 원하는 어떤 명칭으로든 분류할 수 있다. front라는 키로 묶고, 구분을 위해 f1이란 값을 넣을 수 있다. 그럼 front : f1이 되는 것이다.
• spec : 파일 내 실직적인 사양이나 이미지를 할당하기 위한 속성이다.
  • containers : 여러 개의 컨테이너 생성 가능