Kubernetes 확장 메커니즘

지원 버전: Kubernetes 1.31, 1.32, 1.33 마지막 업데이트: 2026년 2월 21일

개요

Kubernetes는 다양한 확장 메커니즘을 제공하여 기본 기능을 확장하고 사용자 정의할 수 있습니다. 이 문서에서는 Kubernetes의 주요 확장 메커니즘을 살펴보고, 실제 사용 사례와 구현 방법을 설명합니다.

커스텀 리소스 정의(CRD)

커스텀 리소스 정의(Custom Resource Definition, CRD)는 Kubernetes API를 확장하여 사용자 정의 리소스를 정의할 수 있게 해주는 메커니즘입니다.

CRD 기본 개념

CRD를 사용하면 다음과 같은 이점을 얻을 수 있습니다:

  1. 선언적 API: Kubernetes의 선언적 API 모델을 활용할 수 있습니다.

  2. kubectl 통합: 기본 Kubernetes 리소스와 동일한 방식으로 커스텀 리소스를 관리할 수 있습니다.

  3. 버전 관리: API 버전 관리를 통해 리소스 스키마를 진화시킬 수 있습니다.

  4. 검증: OpenAPI v3 스키마를 통해 리소스 유효성 검사를 수행할 수 있습니다.

CRD 생성 예시

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: webapps.example.com
spec:
  group: example.com
  names:
    kind: WebApp
    listKind: WebAppList
    plural: webapps
    singular: webapp
    shortNames:
      - wa
  scope: Namespaced
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                replicas:
                  type: integer
                  minimum: 1
                image:
                  type: string
                port:
                  type: integer
              required: ["image"]
            status:
              type: object
              properties:
                availableReplicas:
                  type: integer
                conditions:
                  type: array
                  items:
                    type: object
                    properties:
                      type:
                        type: string
                      status:
                        type: string
                      lastTransitionTime:
                        type: string
      additionalPrinterColumns:
        - name: Replicas
          type: integer
          jsonPath: .spec.replicas
        - name: Image
          type: string
          jsonPath: .spec.image
        - name: Age
          type: date
          jsonPath: .metadata.creationTimestamp
      subresources:
        status: {}
        scale:
          specReplicasPath: .spec.replicas
          statusReplicasPath: .status.availableReplicas

커스텀 리소스 인스턴스 생성

커스텀 컨트롤러

커스텀 리소스만으로는 실제 동작을 구현할 수 없습니다. 커스텀 컨트롤러는 커스텀 리소스의 상태를 감시하고 원하는 상태를 달성하기 위한 작업을 수행합니다.

컨트롤러 패턴

Kubernetes 컨트롤러는 다음과 같은 패턴을 따릅니다:

  1. 관찰(Observe): 리소스의 현재 상태를 관찰합니다.

  2. 분석(Analyze): 현재 상태와 원하는 상태의 차이를 분석합니다.

  3. 조치(Act): 원하는 상태를 달성하기 위한 조치를 취합니다.

컨트롤러 구현 방법

1. client-go 사용

2. controller-runtime 사용

Operator 패턴

Operator는 CRD와 컨트롤러를 결합하여 애플리케이션별 운영 지식을 자동화하는 패턴입니다.

Operator의 주요 특징:

  1. 도메인 지식 자동화: 애플리케이션 도메인 지식을 코드로 구현합니다.

  2. 선언적 관리: 사용자는 원하는 상태를 선언하고, Operator는 이를 달성하기 위한 작업을 수행합니다.

  3. 자가 복구: 장애 상황을 감지하고 자동으로 복구합니다.

  4. 업그레이드 관리: 애플리케이션 업그레이드를 안전하게 처리합니다.

Operator 예시:

  • Prometheus Operator: Prometheus 모니터링 스택을 관리합니다.

  • Elasticsearch Operator: Elasticsearch 클러스터를 관리합니다.

  • PostgreSQL Operator: PostgreSQL 데이터베이스를 관리합니다.

Operator SDK

Operator SDK는 Operator 개발을 간소화하는 도구입니다.

Operator 생성:

API 서버 확장

API 서버 확장은 Kubernetes API 서버의 기능을 확장하는 방법을 제공합니다.

1. 어그리게이션 레이어(Aggregation Layer)

어그리게이션 레이어는 Kubernetes API 서버에 추가 API를 등록할 수 있게 해주는 메커니즘입니다.

주요 특징:

  1. API 확장: 기존 API 서버에 새로운 API를 추가할 수 있습니다.

  2. 클러스터 내 실행: 확장 API 서버는 클러스터 내에서 실행됩니다.

  3. 인증 위임: 기본 API 서버가 인증을 처리하고 확장 API 서버로 위임합니다.

APIService 예시:

확장 API 서버 구현:

2. 웹훅(Webhook)

웹훅은 Kubernetes API 서버가 특정 이벤트 발생 시 외부 서비스를 호출하여 추가 처리를 수행하는 메커니즘입니다.

어드미션 웹훅(Admission Webhook)

어드미션 웹훅은 API 요청이 영구 저장소에 저장되기 전에 요청을 검증하거나 수정할 수 있습니다.

주요 유형:

  1. 변경 어드미션 웹훅(MutatingAdmissionWebhook): 요청을 수정할 수 있습니다.

  2. 검증 어드미션 웹훅(ValidatingAdmissionWebhook): 요청을 검증만 하고 수정하지 않습니다.

웹훅 구성 예시:

웹훅 서버 구현:

스케줄러 확장

Kubernetes 스케줄러는 파드를 어떤 노드에 배치할지 결정하는 역할을 합니다. 스케줄러 확장을 통해 이 결정 과정을 사용자 정의할 수 있습니다.

1. 스케줄러 프레임워크

스케줄러 프레임워크는 스케줄링 파이프라인의 다양한 단계에 플러그인을 추가할 수 있는 확장 메커니즘을 제공합니다.

주요 확장 포인트:

  1. Filter: 파드를 실행할 수 없는 노드를 필터링합니다.

  2. Score: 적합한 노드에 점수를 매깁니다.

  3. Bind: 파드를 노드에 바인딩합니다.

  4. Reserve/Unreserve: 노드의 리소스를 예약하거나 해제합니다.

  5. Permit: 파드 스케줄링을 허용, 거부 또는 지연시킵니다.

스케줄러 구성 예시:

스케줄러 플러그인 구현:

2. 스케줄러 익스텐더(Scheduler Extender)

스케줄러 익스텐더는 HTTP 웹훅을 통해 스케줄링 결정에 영향을 미칠 수 있는 외부 프로세스입니다.

스케줄러 구성 예시:

익스텐더 서버 구현:

네트워크 플러그인

Kubernetes는 컨테이너 네트워크 인터페이스(CNI)를 통해 네트워크 플러그인을 지원합니다.

CNI(Container Network Interface)

CNI는 컨테이너 런타임과 네트워크 플러그인 간의 표준 인터페이스를 정의합니다.

주요 CNI 플러그인:

  1. Calico: BGP 기반의 네트워킹 및 네트워크 정책을 제공합니다.

  2. Cilium: eBPF 기반의 네트워킹, 보안 및 관찰성을 제공합니다.

  3. Flannel: 간단한 오버레이 네트워크를 제공합니다.

  4. Weave Net: 멀티 호스트 컨테이너 네트워킹을 제공합니다.

CNI 구성 예시:

CNI 플러그인 구현:

스토리지 플러그인

Kubernetes는 컨테이너 스토리지 인터페이스(CSI)를 통해 스토리지 플러그인을 지원합니다.

CSI(Container Storage Interface)

CSI는 컨테이너 오케스트레이션 시스템과 스토리지 제공자 간의 표준 인터페이스를 정의합니다.

주요 CSI 플러그인:

  1. AWS EBS CSI Driver: Amazon EBS 볼륨을 제공합니다.

  2. GCE PD CSI Driver: Google Compute Engine 영구 디스크를 제공합니다.

  3. Azure Disk CSI Driver: Azure 디스크를 제공합니다.

  4. Ceph CSI: Ceph RBD 및 CephFS를 제공합니다.

CSI 드라이버 배포 예시:

CSI 드라이버 구현:

CSI 드라이버는 다음과 같은 세 가지 주요 서비스를 구현해야 합니다:

  1. Identity Service: 드라이버 식별 및 기능 검색

  2. Controller Service: 볼륨 프로비저닝 및 관리

  3. Node Service: 노드에 볼륨 마운트 및 마운트 해제

결론

Kubernetes 확장 메커니즘은 다양한 사용 사례와 요구 사항에 맞게 Kubernetes를 사용자 정의할 수 있는 강력한 방법을 제공합니다. CRD와 커스텀 컨트롤러를 통해 새로운 API를 정의하고, 어드미션 웹훅을 통해 API 요청을 검증하거나 수정하며, 스케줄러 확장을 통해 파드 배치 결정을 사용자 정의하고, CNI 및 CSI를 통해 네트워킹 및 스토리지 솔루션을 통합할 수 있습니다.

이러한 확장 메커니즘을 활용하면 Kubernetes를 조직의 특정 요구 사항에 맞게 조정하고, 복잡한 애플리케이션 관리를 자동화하며, 클라우드 네이티브 생태계의 이점을 최대한 활용할 수 있습니다.

마지막 업데이트