쿠버네티스[3] API

쿠버네티스 API
  구버네티스 컨트롤 플레인의 핵심은 API서버이다.
API 서버는 최종 사용자, 클러스터의 다른 부분 그리고 외부 컴포넌트가 서로 통신할 수 있도록 http API를 제공한다.
쿠머네티스 API를 사용하면 쿠버네티스의 API오브젝트(예 : 파드 POD), 네잌스페이스(Namespace), 컨피그맵(ConfigMap)그리고 이벤트(Event)를 질의(query)하고 조작할 수 있다.

대부분의 작업은 kubectl 커맨드 라인 인터페이스 또는 API를 사용하는 Kubeadm과 같은 다른 커맨드 라인 도구를 통해 수행할 수 있다. 그러나 REST 호추을 사용하여 API에 직접 접근할 수도 있다

OpenAPI 명세
  * OpenAPI V2
   - 쿠버네틱스 API서버는 /openapi/v2 엔트포인트를 통해 통합된(aggrgated) OpenAPI V2 스펭을 제공한다 요청 헤더에 다음과 같이 기재하여 하여 응답형식을 지정할 수 있다

헤더 : Accept-Encoding 
사용할 수 있는값 : gzip 
참고 : 이헤더를 제공하지 않는 것도 가능

헤더 : Accept
사용할 수 있는 값 : application/com.github.proto-openapi.spec.v2@v1.0+protobuf 
                        주로 클러스터 내부 용도로 사용
사용할 수 있는 값 : application/jsom  
                         기본값
사용할 수 있는 값 : *
                         JSON으로 응답

쿠버네티스는 주로 클러스터 내부 통신을 위해 대안적인 Protobuf에 기반한 직렬화 형식을 구현한다

* OpenAPI V3
 쿠버네티스 V1.25 버전은 OpenAPI 발행 (publishing)에 대한 베타 지원을 제공
 이 기능은 베타 기능이본 기본적으로 비활성화 되어 있다.

*지속성
 쿠버네티스는 오브젝트의 직렬화된 상태를 etcd에 기록하여 저장한다.

*API 그룹과 버전 규칙
 필드를 쉽게 제거하거나 리소르 표현을 재구성하기 위해, 쿠버네티스는 각각 /api/v1 또는 
 /apis/rbac.authorization.K8s,io/v1alpha1 과 같은 서로 다른 API 경로에서 여러 API버전을 지원한다.
버전 규칙은 리소스나 필드 수준이 아닌 API 수준에서 수행되어 API가 시스템 리소스 및 동작에 대한 명확하고 일관된 보기를 제공하고 수명 종료 및 실험적 API에 대한 접근을 제어할 수 있도록 한다.
API를 확장하기 위해 쿠버네티스는 활성화 또는 비활성화가 가능한 API 그룹을 구현
API 리소스는 API 그룹, 리소스 유형,네임스페이스(네임스페이스 리소스용) 및 이름으로 구분
API 서버는 API버전 간의 변환을 투명하게 처리한다.
서로 다른 모든 버전은 실제로 동일한 지속 데이터의 표현이다 
API서버는 여러 API버전을 통해 동일하 기본 데이터를 제공할 수 있다.
동일한 리소스에 대해 V1과 V1beta1 이라는 두가지 API 버전이 있다고 가정
  기존 API의 V1beta1 버전을 사용하여 오브젝트를 만든 경우, V1beta1또는 V1 API 버전을 사용하여 해당 오브젝트를 읽거나 업데이터하거나 삭제할 수 있다
*API 변경 사항
  쿠버네티스 프로젝트는 기존 클라이언트와의 호환성을 깨지 않고 다른 프로젝트가 적응할 기회를 가질 수 있도록 장기간 해당 호환성을 유지하는 것을 목표
  새 API리소스와 새 리소스 필드는 자추 추가될 수 있다 리소스 또는 필드를 제거하려면 API지원 중단 정책을 따라햐 한다
*API 확장
  쿠버네티스 API는 다음 두가지 방법 중 하나로 확장할 수 있다
    커스텀 리소스를 사용하면 API서버가 선택한 리소스 API를 제공하는 방법을 선엊걱으로 정의
   애그리게이션 레이러(aggregation layer)를 구현하면 쿠버네티스 API를 확장할 수도 있다