이 섹션의 다중 페이지 출력 화면임. 여기를 클릭하여 프린트.

이 페이지의 일반 화면으로 돌아가기.

API 개요

이 섹션은 쿠버네티스 API에 대한 참조 정보를 제공한다.

REST API는 쿠버네티스의 근본적인 구조이다. 모든 조작, 컴포넌트 간의 통신과 외부 사용자의 명령은 API 서버에서 처리할 수 있는 REST API 호출이다. 따라서, 쿠버네티스 플랫폼 안의 모든 것은 API 오브젝트로 취급되고, API에 상응하는 항목이 있다.

쿠버네티스 API 참조는 쿠버네티스 버전 v1.25에 대한 API가 나열되어 있다.

일반적인 배경 정보를 보려면, 쿠버네티스 API를 참고한다. 쿠버네티스 API에 대한 접근 제어는 클라이언트가 쿠버네티스 API 서버에 인증하는 방법과 요청이 승인되는 방법을 설명한다.

API 버전 규칙

JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서 동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다.

API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관된다. API와 릴리스 버전 부여에 관한 제안에는 API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다.

API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. API 변경 문서에서 각 수준의 기준에 대한 더 많은 정보를 찾을 수 있다.

아래는 각 수준의 기준에 대한 요약이다.

  • 알파(Alpha):

    • 버전 이름에 alpha가 포함된다(예: v1alpha1).
    • 버그가 있을 수도 있다. 이 기능을 활성화하면 버그에 노출될 수 있다. 기본적으로 비활성화되어 있다.
    • 기능에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다.
    • 다음 소프트웨어를 릴리스할 때 공지 없이 API의 호환성이 깨지는 방식으로 변경될 수 있다.
    • 버그에 대한 위험이 높고 장기간 지원되지 않으므로 단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다.

  • 베타(Beta):

    • 버전 이름에 beta가 포함된다(예: v2beta3).

    • 코드가 잘 테스트 되었다. 이 기능을 활성화해도 안전하다. 기본적으로 활성화되어 있다.

    • 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다.

    • 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로 이관할 수 있는 가이드가 제공된다. 스키마 변경은 API 오브젝트의 삭제, 편집 또는 재생성이 필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다.

    • 이 소프트웨어는 프로덕션 용도로 권장하지 않는다. 이후 여러 버전에서 호환되지 않는 변경 사항이 적용될 수 있다. 복수의 클러스터를 가지고 있어서 독립적으로 업그레이드할 수 있다면, 이런 제약에서 벗어날 수도 있다.

  • 안정화(Stable):

    • 버전 이름이 vX이고 X 는 정수다.
    • 안정화 버전의 기능은 이후 여러 버전에 걸쳐서 소프트웨어 릴리스에 포함된다.

API 그룹

API 그룹은 쿠버네티스 API를 더 쉽게 확장할 수 있도록 해 준다. API 그룹은 REST 경로와 직렬화된 오브젝트의 apiVersion 필드에 명시된다.

쿠버네티스에는 다음과 같은 다양한 API 그룹이 있다.

  • 핵심 (또는 레거시 라고 불리는) 그룹은 REST 경로 /api/v1에 있다. 핵심 그룹은 apiVersion 필드의 일부로 명시되지 않는다. 예를 들어, apiVersion: v1 과 같다.
  • 이름이 있는 그룹은 REST 경로 /apis/$GROUP_NAME/$VERSION에 있으며 apiVersion: $GROUP_NAME/$VERSION을 사용한다(예를 들어, apiVersion: batch/v1). 지원되는 API 그룹 전체의 목록은 쿠버네티스 API 참조 문서에서 확인할 수 있다.

API 그룹 활성화 또는 비활성화

특정 리소스 및 API 그룹은 기본적으로 활성화된다. API 서버에서 --runtime-config 를 설정하여 활성화 또는 비활성화할 수 있다. --runtime-config 플래그는 API 서버의 런타임 구성을 설명하는 쉼표로 구분된 <key>=<value> 쌍을 허용한다. 만약 =<value> 부분을 생략하면, =true 가 명시된 것처럼 취급한다. 예를 들면, 다음과 같다.

  • batch/v1 을 비활성화하려면, --runtime-config=batch/v1=false 로 설정
  • batch/v2alpha1 을 활성화하려면, --runtime-config=batch/v2alpha1 으로 설정
  • 예를 들어 storage.k8s.io/v1beta1/csistoragecapacities와 같이 특정 버전의 API를 활성화하려면, --runtime-config=storage.k8s.io/v1beta1/csistoragecapacities와 같이 설정

지속성

쿠버네티스는 etcd에 기록하여 API 리소스 측면에서 직렬화된 상태를 저장한다.

다음 내용

1 - 클라이언트 라이브러리

이 페이지는 다양한 프로그래밍 언어에서 쿠버네티스 API를 사용하기 위한 클라이언트 라이브러리에 대한 개요를 포함하고 있다.

쿠버네티스 REST API를 사용해 애플리케이션을 작성하기 위해 API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다. 사용하고 있는 프로그래밍 언어를 위한 클라이언트 라이브러리를 사용하면 된다.

클라이언트 라이브러리는 대체로 인증과 같은 공통의 태스크를 처리한다. 대부분의 클라이언트 라이브러리들은 API 클라이언트가 쿠버네티스 클러스터 내부에서 동작하는 경우 인증 또는 kubeconfig 파일 포맷을 통해 자격증명과 API 서버 주소를 읽을 수 있게 쿠버네티스 서비스 어카운트를 발견하고 사용할 수 있다.

공식적으로 지원되는 쿠버네티스 클라이언트 라이브러리

다음의 클라이언트 라이브러리들은 쿠버네티스 SIG API Machinery에서 공식적으로 관리된다.

언어 클라이언트 라이브러리 예제 프로그램
C github.com/kubernetes-client/c 둘러보기
dotnet github.com/kubernetes-client/csharp 둘러보기
Go github.com/kubernetes/client-go/ 둘러보기
Haskell github.com/kubernetes-client/haskell 둘러보기
Java github.com/kubernetes-client/java 둘러보기
JavaScript github.com/kubernetes-client/javascript 둘러보기
Perl github.com/kubernetes-client/perl/ 둘러보기
Python github.com/kubernetes-client/python/ 둘러보기
Ruby github.com/kubernetes-client/ruby/ 둘러보기

커뮤니티에 의해 관리되는 클라이언트 라이브러리

다음의 쿠버네티스 API 클라이언트 라이브러리들은 쿠버네티스 팀이 아닌 각각의 저자들이 제공하고 관리한다.

언어 클라이언트 라이브러리
Clojure github.com/yanatan16/clj-kubernetes-api
DotNet github.com/tonnyeremin/kubernetes_gen
DotNet (RestSharp) github.com/masroorhasan/Kubernetes.DotNet
Elixir github.com/obmarg/kazan
Elixir github.com/coryodaniel/k8s
Go github.com/ericchiang/k8s
Java (OSGi) bitbucket.org/amdatulabs/amdatu-kubernetes
Java (Fabric8, OSGi) github.com/fabric8io/kubernetes-client
Java github.com/manusa/yakc
Lisp github.com/brendandburns/cl-k8s
Lisp github.com/xh4/cube
Node.js (TypeScript) github.com/Goyoo/node-k8s-client
Node.js github.com/ajpauwels/easy-k8s
Node.js github.com/godaddy/kubernetes-client
Node.js github.com/tenxcloud/node-kubernetes-client
Perl metacpan.org/pod/Net::Kubernetes
PHP github.com/allansun/kubernetes-php-client
PHP github.com/maclof/kubernetes-client
PHP github.com/travisghansen/kubernetes-client-php
PHP github.com/renoki-co/php-k8s
Python github.com/fiaas/k8s
Python github.com/gtsystem/lightkube
Python github.com/mnubo/kubernetes-py
Python github.com/tomplus/kubernetes_asyncio
Python github.com/Frankkkkk/pykorm
Ruby github.com/abonas/kubeclient
Ruby github.com/k8s-ruby/k8s-ruby
Ruby github.com/kontena/k8s-client
Rust github.com/clux/kube-rs
Rust github.com/ynqa/kubernetes-rust
Scala github.com/hagay3/skuber
Scala github.com/joan38/kubernetes-client
Swift github.com/swiftkube/client

2 - 쿠버네티스 API 헬스(health) 엔드포인트

쿠버네티스 API 서버는 현재 상태를 나타내는 API 엔드포인트를 제공한다. 이 페이지에서는 API 엔드포인트들에 대해 설명하고 이를 사용하는 방법을 다룬다.

헬스를 위한 API 엔드포인트

쿠버네티스 API 서버는 현재 상태를 나타내는 세 가지 API 엔드포인트(healthz, livez 와 readyz)를 제공한다. healthz 엔드포인트는 사용 중단(deprecated)됐으며 (쿠버네티스 v1.16 버전 이후), 대신 보다 구체적인 livez 와 readyz 엔드포인트를 사용해야 한다. livez 엔드포인트는 --livez-grace-period 플래그 옵션을 사용하여 시작 대기 시간을 지정할 수 있다. /readyz 엔드포인트는 --shutdown-delay-duration 플래그 옵션을 사용하여 정상적(graceful)으로 셧다운할 수 있다. API 서버의 healthz/livez/readyz 를 사용하는 머신은 HTTP 상태 코드에 의존해야 한다. 상태 코드 200은 호출된 엔드포인트에 따라 API 서버의 healthy/live/ready 상태를 나타낸다. 아래 표시된 더 자세한 옵션은 운영자가 클러스터를 디버깅하거나 특정 API 서버의 상태를 이해하는 데 사용할 수 있다.

다음의 예시는 헬스 API 엔드포인트와 상호 작용할 수 있는 방법을 보여준다.

모든 엔드포인트에 대해, verbose 파라미터를 사용하여 검사 항목과 상태를 출력할 수 있다. 이는 운영자가 머신 사용을 위한 것이 아닌, API 서버의 현재 상태를 디버깅하는데 유용하다.

curl -k https://localhost:6443/livez?verbose

인증을 사용하는 원격 호스트에서 사용할 경우에는 다음과 같이 수행한다.

kubectl get --raw='/readyz?verbose'

출력은 다음과 같다.

[+]ping ok
[+]log ok
[+]etcd ok
[+]poststarthook/start-kube-apiserver-admission-initializer ok
[+]poststarthook/generic-apiserver-start-informers ok
[+]poststarthook/start-apiextensions-informers ok
[+]poststarthook/start-apiextensions-controllers ok
[+]poststarthook/crd-informer-synced ok
[+]poststarthook/bootstrap-controller ok
[+]poststarthook/rbac/bootstrap-roles ok
[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
[+]poststarthook/start-cluster-authentication-info-controller ok
[+]poststarthook/start-kube-aggregator-informers ok
[+]poststarthook/apiservice-registration-controller ok
[+]poststarthook/apiservice-status-available-controller ok
[+]poststarthook/kube-apiserver-autoregistration ok
[+]autoregister-completion ok
[+]poststarthook/apiservice-openapi-controller ok
healthz check passed

또한 쿠버네티스 API 서버는 특정 체크를 제외할 수 있다. 쿼리 파라미터는 다음 예와 같이 조합될 수 있다.

curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'

출력에서 etcd 체크가 제외된 것을 보여준다.

[+]ping ok
[+]log ok
[+]etcd excluded: ok
[+]poststarthook/start-kube-apiserver-admission-initializer ok
[+]poststarthook/generic-apiserver-start-informers ok
[+]poststarthook/start-apiextensions-informers ok
[+]poststarthook/start-apiextensions-controllers ok
[+]poststarthook/crd-informer-synced ok
[+]poststarthook/bootstrap-controller ok
[+]poststarthook/rbac/bootstrap-roles ok
[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
[+]poststarthook/start-cluster-authentication-info-controller ok
[+]poststarthook/start-kube-aggregator-informers ok
[+]poststarthook/apiservice-registration-controller ok
[+]poststarthook/apiservice-status-available-controller ok
[+]poststarthook/kube-apiserver-autoregistration ok
[+]autoregister-completion ok
[+]poststarthook/apiservice-openapi-controller ok
[+]shutdown ok
healthz check passed

개별 헬스 체크

기능 상태: Kubernetes v1.25 [alpha]

각 개별 헬스 체크는 HTTP 엔드포인트를 노출하며 개별적으로 체크할 수 있다. 개별 체크를 위한 스키마는 /livez/<healthcheck-name> 이고, 여기서 livez 와 readyz 는 API 서버의 활성 상태 또는 준비 상태인지를 확인할 때 사용한다. <healthcheck-name> 경로 위에서 설명한 verbose 플래그를 사용해서 찾을 수 있고, [+] 와 ok 사이의 경로를 사용한다. 이러한 개별 헬스 체크는 머신에서 사용되서는 안되며, 운영자가 시스템의 현재 상태를 디버깅하는데 유용하다.

curl -k https://localhost:6443/livez/etcd