쿠버네티스 확장하기

쿠버네티스 확장하기 (Extending Kubernetes)

쿠버네티스 클러스터의 동작을 바꾸는 다양한 방법을 소개하는 랜딩 페이지예요. 쿠버네티스는 매우 구성 가능하고 확장 가능해요. 그 결과 쿠버네티스 프로젝트 코드를 포크하거나 패치를 제출할 필요가 거의 없어요.

출처: 문서

본문

이 가이드는 쿠버네티스 클러스터를 커스터마이즈하는 옵션을 설명해요. 자신의 작업 환경 요구에 맞게 쿠버네티스 클러스터를 조정하는 방법을 이해하려는 클러스터 운영자를 대상으로 해요. 예비 플랫폼 개발자나 쿠버네티스 프로젝트 기여자가 되려는 개발자도 확장 포인트와 패턴, 그리고 그 트레이드오프와 한계를 소개하므로 유용할 거예요.

커스터마이즈 접근 방식은 크게 둘로 나눌 수 있어요.

  • 구성(Configuration): 명령줄 인자, 로컬 구성 파일, API 리소스만 변경하는 것.
  • 확장(Extensions): 추가 프로그램, 추가 네트워크 서비스, 또는 둘 다를 실행하는 것.

이 문서는 주로 확장에 관한 것이에요.

구성 (Configuration)

구성 파일과 명령 인자는 온라인 문서의 Reference 섹션에 각 바이너리마다 페이지로 문서화돼 있어요.

  • kube-apiserver
  • kube-controller-manager
  • kube-scheduler
  • kubelet
  • kube-proxy

명령 인자와 구성 파일은 관리형 설치가 있는 호스팅 쿠버네티스 서비스에서는 항상 변경할 수 있는 것은 아니에요. 변경할 수 있을 때도 보통 클러스터 운영자만 변경할 수 있어요. 또한 향후 쿠버네티스 버전에서 변경될 수 있고, 설정하면 프로세스 재시작이 필요할 수 있어요. 그런 이유로 다른 옵션이 없을 때만 사용해야 해요.

ResourceQuota, NetworkPolicy, 역할 기반 접근 제어(RBAC) 같은 내장 정책 API는 선언적으로 구성된 정책 설정을 제공하는 내장 쿠버네티스 API예요. API는 일반적으로 호스팅 쿠버네티스 서비스와 관리형 쿠버네티스 설치에서도 사용할 수 있어요. 내장 정책 API는 Pod 같은 다른 쿠버네티스 리소스와 같은 규칙을 따라요. 안정적인 정책 API를 사용하면 다른 쿠버네티스 API처럼 정의된 지원 정책의 혜택을 받아요. 이런 이유로 정책 API는 적합한 경우 구성 파일과 명령 인자보다 권장돼요.

확장 (Extensions)

확장은 쿠버네티스를 확장하고 깊이 통합하는 소프트웨어 컴포넌트예요. 새로운 유형과 새로운 종류의 하드웨어를 지원하도록 조정해요.

많은 클러스터 관리자는 호스팅 또는 배포 인스턴스의 쿠버네티스를 사용해요. 이 클러스터에는 확장이 사전 설치되어 있어요. 결과적으로 대부분의 쿠버네티스 사용자는 확장을 설치할 필요가 없고, 새 확장을 작성할 필요가 있는 사용자는 훨씬 적어요.

확장 패턴 (Extension patterns)

쿠버네티스는 클라이언트 프로그램을 작성해 자동화되도록 설계돼 있어요. 쿠버네티스 API를 읽고/쓰는 어떤 프로그램도 유용한 자동화를 제공할 수 있어요. 자동화는 클러스터 안이나 밖에서 실행될 수 있어요. 쿠버네티스와 잘 작동하는 클라이언트 프로그램을 작성하는 특정 패턴이 있는데, 이를 컨트롤러 패턴(controller pattern)이라고 불러요. 컨트롤러는 일반적으로 객체의 .spec을 읽고, 일을 처리한 다음 객체의 .status를 업데이트해요.

컨트롤러는 쿠버네티스 API의 클라이언트예요. 쿠버네티스가 클라이언트가 되어 원격 서비스를 호출할 때, 쿠버네티스는 이를 웹훅(webhook)이라고 불러요. 원격 서비스는 웹훅 백엔드(webhook backend)라고 불러요. 커스텀 컨트롤러처럼 웹훅도 실패 지점을 추가해요.

참고: 쿠버네티스 밖에서 "webhook"이라는 용어는 일반적으로 비동기 알림을 위한 메커니즘을 의미하며, 웹훅 호출이 다른 시스템 또는 컴포넌트에 대한 단방향 알림으로 작동해요. 쿠버네티스 생태계에서는 동기식 HTTP 호출도 종종 "webhook"으로 설명돼요.

웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 해요. 대안인 바이너리 Plugin 모델에서는 쿠버네티스가 바이너리(프로그램)를 실행해요. 바이너리 플러그인은 kubelet(예: CSI 스토리지 플러그인과 CNI 네트워크 플러그인)과 kubectl이 사용해요(플러그인으로 kubectl 확장하기 참고).

확장 포인트 (Extension points)

다이어그램은 쿠버네티스 클러스터의 확장 포인트와 접근하는 클라이언트를 보여줘요. 사용자는 보통 kubectl로 쿠버네티스 API와 상호작용해요. 플러그인은 클라이언트의 동작을 커스터마이즈해요. 다른 클라이언트에 적용할 수 있는 일반 확장과 kubectl을 확장하는 특정 방법이 있어요.

  • API 서버는 모든 요청을 처리해요. API 서버의 여러 유형의 확장 포인트는 요청을 인증하거나, 콘텐츠에 따라 차단하거나, 콘텐츠를 편집하고, 삭제를 처리하는 것을 허용해요. API 접근 확장 섹션에 설명돼 있어요.
  • API 서버는 다양한 종류의 리소스를 제공해요. pods 같은 내장 리소스 종류는 쿠버네티스 프로젝트가 정의하며 변경할 수 없어요. API 확장을 읽어 쿠버네티스 API를 확장하는 방법을 알아보세요.
  • 쿠버네티스 스케줄러는 파드를 어느 노드에 배치할지 결정해요. 스케줄링 확장 섹션에 설명된 여러 방식으로 스케줄링을 확장할 수 있어요.
  • 쿠버네티스 동작의 대부분은 API 서버의 클라이언트인 컨트롤러라는 프로그램으로 구현돼요. 컨트롤러는 종종 커스텀 리소스와 함께 사용돼요.
  • kubelet은 서버(노드)에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이게 해줘요. 네트워크 플러그인은 파드 네트워킹의 다른 구현을 허용해요.
  • 디바이스 플러그인으로 커스텀 하드웨어나 다른 특수한 노드 로컬 설비를 통합하고, 클러스터에서 실행되는 Pod에 사용 가능하게 할 수 있어요. kubelet은 디바이스 플러그인 작업 지원을 포함해요. kubelet은 또한 파드와 그 컨테이너의 볼륨을 마운트하고 마운트 해제해요. 스토리지 플러그인으로 새로운 종류의 스토리지와 다른 볼륨 유형에 대한 지원을 추가할 수 있어요.

클라이언트 확장 (Client extensions)

kubectl용 플러그인은 특정 하위 명령의 동작을 추가하거나 대체하는 별도 바이너리예요. kubectl 도구는 자격 증명 플러그인과도 통합될 수 있어요. 이러한 확장은 개별 사용자의 로컬 환경에만 영향을 주므로 사이트 전체 정책을 강제할 수 없어요.

API 확장 (API extensions)

  • 커스텀 리소스 정의(Custom resource definitions): 새 컨트롤러, 애플리케이션 구성 객체 또는 다른 선언적 API를 정의하고 kubectl 같은 쿠버네티스 도구로 관리하려면 커스텀 리소스를 추가하는 것을 고려해요.
  • API 애그리게이션 레이어(API aggregation layer): 쿠버네티스의 API Aggregation Layer를 사용해 쿠버네티스 API를 Metrics API 같은 추가 서비스와 통합할 수 있어요.
  • 새 API와 자동화 결합: 커스텀 리소스 API와 컨트롤 루프의 조합을 컨트롤러 패턴(controllers pattern)이라고 불러요. 컨트롤러가 원하는 상태를 기반으로 인프라스트럭처를 배포하는 인간 운영자의 역할을 대체한다면, 컨트롤러는 운영자 패턴(operator pattern)을 따르는 것일 수도 있어요. 운영자 패턴은 특정 애플리케이션을 관리하는 데 사용돼요. 보통 상태를 유지하고 관리 방식에 주의가 필요한 애플리케이션이에요.
  • 내장 리소스 변경: 커스텀 리소스를 추가해 쿠버네티스 API를 확장할 때, 추가되는 리소스는 항상 새 API 그룹에 속해요. 기존 API 그룹을 대체하거나 변경할 수는 없어요.

API 접근 확장 (API access extensions)

요청이 쿠버네티스 API 서버에 도달하면 먼저 인증(authN)되고, 그 다음 인가(authZ)되며, 그 후 다양한 유형의 승인 제어(admission control)를 거쳐요. 인증/인가 흐름의 각 단계마다 확장 포인트가 있어요.

  • 인증(Authentication): 인증은 모든 요청의 헤더나 인증서를 요청하는 클라이언트의 사용자 이름에 매핑해요. 내장 인증 방법과 더불어 인증 프록시 뒤에 설 수 있고, Authorization: 헤더의 토큰을 검증용 원격 서비스(인증 웹훅)로 보낼 수도 있어요.
  • 인가(Authorization): 인가는 특정 사용자가 API 리소스에 대해 읽기, 쓰기 및 기타 작업을 할 수 있는지 결정해요. 전체 리소스 수준에서 작동해요.
  • 동적 승인 제어(Dynamic admission control): 요청이 인가된 후 쓰기 작업이라면 승인 제어 단계를 거쳐요. Image Policy 웹훅은 컨테이너에서 실행할 수 있는 이미지를 제한해요. 일반 Admission 웹훅으로 임의의 승인 제어 결정을 내릴 수 있어요.

인프라스트럭처 확장 (Infrastructure extensions)

  • 디바이스 플러그인(Device plugins): 디바이스 플러그인은 노드가 새 노드 리소스(cpu, memory 같은 내장 리소스 외에)를 발견하도록 해줘요.
  • 스토리지 플러그인(Storage plugins): Container Storage Interface (CSI) 플러그인은 새 종류의 볼륨 지원으로 쿠버네티스를 확장하는 방법을 제공해요. 쿠버네티스는 Kubernetes v1.23부터 폐기된(CSI를 선호) FlexVolume 플러그인 지원도 포함해요.
  • 네트워크 플러그인(Network plugins): 클러스터는 작동하는 Pod 네트워크를 갖고 쿠버네티스 네트워크 모델의 다른 측면을 지원하기 위해 네트워크 플러그인이 필요해요.
  • Kubelet 이미지 자격 증명 제공자 플러그인: 기능 상태: Kubernetes v1.26부터 Stable. kubelet이 이미지 레지스트리 자격 증명을 동적으로 검색하기 위한 플러그인이에요.

스케줄링 확장 (Scheduling extensions)

스케줄러는 파드를 관찰하고 파드를 노드에 할당하는 특수한 유형의 컨트롤러예요. 기본 스케줄러를 완전히 교체하거나, 여러 스케줄러를 동시에 실행할 수 있어요. 어떤 스케줄링 플러그인이 활성화될지 제어하거나, 플러그인 집합을 다른 이름의 스케줄러 프로파일과 연관시킬 수도 있어요. 또한 kube-scheduler의 하나 이상의 확장 포인트와 통합하는 자신만의 플러그인을 작성할 수도 있어요. 마지막으로 내장 kube-scheduler 컴포넌트는 원격 HTTP 백엔드(스케줄러 확장)가 kube-scheduler가 파드를 위해 선택하는 노드를 필터링 및/또는 우선순위 지정하도록 허용하는 웹훅을 지원해요.

참고: 스케줄러 extender 웹훅으로는 노드 필터링과 노드 우선순위 지정에만 영향을 줄 수 있어요. 다른 확장 포인트는 웹훅 통합을 통해 사용할 수 없어요.

다음 단계 (What's next)

  • 인프라스트럭처 확장에 대해 더 알아보기: 디바이스 플러그인, 네트워크 플러그인, CSI 스토리지 플러그인.
  • kubectl 플러그인에 대해 알아보기.
  • 커스텀 리소스에 대해 더 알아보기.
  • 확장 API 서버에 대해 더 알아보기.
  • 동적 승인 제어에 대해 알아보기.
  • 운영자 패턴에 대해 알아보기.

더 알아보기 (Learn more)