API 개요
이 섹션은 쿠버네티스 API에 대한 참조 정보를 제공한다.
REST API는 쿠버네티스의 근본적인 구조이다. 모든 조작,
컴포넌트 간의 통신과 외부 사용자의 명령은 API 서버에서 처리할 수 있는
REST API 호출이다. 따라서, 쿠버네티스 플랫폼 안의 모든 것은
API 오브젝트로 취급되고,
API에 상응하는 항목이 있다.
쿠버네티스 API 참조는
쿠버네티스 버전 v1.20에 대한 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
으로 설정
참고: 그룹이나 리소스를 활성화 또는 비활성화하려면, apiserver와 controller-manager를 재시작하여
--runtime-config
변경을 반영해야 한다.
지속성
쿠버네티스는 etcd에 기록하여 API 리소스 측면에서
직렬화된 상태를 저장한다.
다음 내용
1 - 클라이언트 라이브러리
이 페이지는 다양한 프로그래밍 언어에서 쿠버네티스 API를 사용하기 위한
클라이언트 라이브러리에 대한 개요를 포함하고 있다.
쿠버네티스 REST API를 사용해 애플리케이션을 작성하기 위해
API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다.
사용하고 있는 프로그래밍 언어를 위한 클라이언트 라이브러리를 사용하면 된다.
클라이언트 라이브러리는 대체로 인증과 같은 공통의 태스크를 처리한다.
대부분의 클라이언트 라이브러리들은 API 클라이언트가 쿠버네티스 클러스터 내부에서 동작하는 경우 인증
또는 kubeconfig 파일 포맷을 통해
자격증명과 API 서버 주소를 읽을 수 있게
쿠버네티스 서비스 어카운트를 발견하고 사용할 수 있다.
공식적으로 지원되는 쿠버네티스 클라이언트 라이브러리
다음의 클라이언트 라이브러리들은
쿠버네티스 SIG API Machinery에서 공식적으로 관리된다.
커뮤니티에 의해 관리되는 클라이언트 라이브러리
주의:
이 섹션은 쿠버네티스에 필요한 기능을 제공하는 써드파티 프로젝트와 관련이 있다. 쿠버네티스 프로젝트 작성자는 써드파티 프로젝트에 책임이 없다. 이 페이지는 CNCF 웹사이트 가이드라인에 따라 프로젝트를 알파벳 순으로 나열한다. 이 목록에 프로젝트를 추가하려면 변경사항을 제출하기 전에 콘텐츠 가이드를 읽어본다.
다음의 쿠버네티스 API 클라이언트 라이브러리들은 쿠버네티스 팀이 아닌
각각의 저자들이 제공하고 관리한다.
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 서버의 health
/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
개별 헬스 체크
FEATURE STATE: Kubernetes v1.20 [alpha]
각 개별 헬스 체크는 http 엔드포인트를 노출하고 개별적으로 체크가 가능하다.
개별 체크를 위한 스키마는 /livez/<healthcheck-name>
이고, 여기서 livez
와 readyz
는 API 서버의 활성 상태 또는 준비 상태인지를 확인할 때 사용한다.
<healthcheck-name>
경로 위에서 설명한 verbose
플래그를 사용해서 찾을 수 있고, [+]
와 ok
사이의 경로를 사용한다.
이러한 개별 헬스 체크는 머신에서 사용되서는 안되며, 운영자가 시스템의 현재 상태를 디버깅하는데 유용하다.
curl -k https://localhost:6443/livez/etcd