Udemy CKA 강의 정리 157: API Groups

해당 내용은 Udemy의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의를 공부한 내용입니다. 내용을 그대로 번역하기보다는, 제가 이해하기 쉬운 대로 수정한 부분들이 있습니다.

⚠️ 영어 독해가 많이 부족합니다. 틀린 내용이 있으면 알려주시면 감사하겠습니다.

---

인증에 대해 알아보기 전에 먼저 Kubernetes의 API 그룹에 대해 이해해야 합니다. 쿠버네티스 API란 무엇일까요?
우리는 전에 Kube API 서버에 대해 알아보았습니다. 지금까지 클러스터에서 수행한 작업이 무엇이든 Kube control 유틸리티 또는 REST를 통해 직접 API 서버와 상호 작용했습니다.
우리는 마스터 노드 주소 + 6443포트(디폴트) + API version 으로 API 서버에 액세스할 수 있습니다. 아래 커맨드는 버전을 반환합니다.

마찬가지로 파드 목록을 얻으려면 URL api/v1/pods에 액세스합니다.
이 강의에서 초점을 두는 것은 이러한 API 파드 버전 및 API에 관한 것입니다. Kubernetes API는 목적에 따라 APIs, healthz, metrics , logs 등 여러 그룹으로 그룹화됩니다.
 버전 API는 방금 본 것처럼 클러스터의 버전을 보기 위한 것입니다. Metrics 및 Health API는 클러스터의 상태를 모니터링하는 데 사용됩니다. 로그는 타사 로깅 애플리케이션과 통합하는 데 사용됩니다.

이 강의에서는 클러스터 기능을 담당하는 API에 중점을 둘 것입니다.

API and APIs

이러한 API는 core 그룹과 named 그룹, 두 가지로 분류됩니다. 
코어 그룹은 name, spaces, pods, replication controllers, events, endpoints, nodes, bindings, persistent volumes, persistent volume claims, conflict maps, secrets, services 등과 같은 모든 핵심 기능이 존재하는 곳입니다.

네임드 그룹 API는 더욱 체계화되어 있으며, 앞으로 네임드 그룹을 통해 모든 최신 기능을 사용할 수 있게 됩니다. apps, extensions, networking, storage, authentication, authorization 등이 있습니다. 방금 언급한 것은 일부에 불과합니다.
/apps 안에는 deployments, replica sets, stateful sets 가 있습니다.
/networking.k8s.io 안에는 네트워크 정책이 있습니다.
/certificates.k8s.io 에는 섹션 앞부분에서 설명한 인증서 서명 요청이 있습니다.

따라서 상단에 있는 것은 API 그룹이고 하단에 있는 것은 해당 그룹의 리소스입니다. 각 리소스에는 연결된 일련의 작업이 있습니다. 이러한 리소스로 수행할 수 있는 작업으로는 deployment 나열, 이러한 deployment 중 하나에 대한 정보 가져오기, delpoyment 만들기, deployment 삭제, deployment 업데이트, deployment 보기 등이 있습니다. 이런 작업들을 Verbs라고 합니다.
Kubernetes API 공식문서 페이지에서 각 개체에 대한 API 그룹이 무엇인지 알 수 있습니다. 오브젝트를 선택하면 설명서 페이지의 첫 번째 섹션에 그룹 세부 정보가 표시되며 여기서 v1 코어의 버전은 v1이라는 것을 확인할 수 있습니다.
Kubernetes 클러스터에서도 이를 볼 수 있습니다. 아무 path에 6443포트에서 Kube API 서버에 액세스하면 사용 가능한 API 그룹이 나열됩니다.

그런 다음 위 커맨드로 named API 그룹 내에서 지원되는 모든 리소스 그룹을 반환합니다.

Note on accessing the kube-apiserver

이와 같은 클러스터 API 액세스에 대한 참고할 내용이 있습니다.

여기에 표시된 것처럼 curl을 통해 직접 API에 액세스하는 경우 인증 메커니즘을 지정하지 않았으므로 버전과 같은 특정 API를 제외하고는 액세스가 허용되지 않습니다. 따라서 인증서 파일을 위와 같이 커맨드라인에 전달하여 API에 인증해야 합니다.
alternate option은 Kube control proxy client를 시작하는 것입니다.

kubectl proxy 커맨드는 8001포트에서 로컬로 프록시 서비스를 시작하고 kube configuration 파일의 자격 증명과 인증서를 사용하여 클러스터에 액세스합니다. 이렇게 하면 curl 커맨드에서 따로 지정할 필요가 없습니다.
이제 8001포트에서 kubectl proxy 서비스에 액세스할 수 있으며 프록시는 kube configuration 파일의 자격 증명을 사용하여 Kube API 서버에 요청을 전달합니다. 그러면 루트에서 사용 가능한 모든 API가 나열됩니다.

kube proxy vs kubectl proxy

비슷한 두 용어가 있습니다. kube proxy 와 kubectl proxy입니다.  차이점에 대해 알아보겠습니다.

이 과정 초반에 Kube 프록시에 대해 논의했습니다. 클러스터의 여러 노드에서 파드와 서비스 간의 연결을 활성화하는 데 사용됩니다. Kube 프록시에 대해서는 이 과정의 뒷부분에서 훨씬 더 자세히 설명합니다.
반면 Kubectl 프록시는 Kube API 서버에 액세스하기 위해 Kubectl 유틸리티에서 만든 http 프록시 서비스입니다.

Key Takeaways

Kubernetes의 모든 리소스는 서로 다른 API 그룹으로 그룹화됩니다.
최상위 수준에는 core API 그룹과 named API 그룹이 있습니다.
named API 그룹 아래에는 섹션마다 하나씩 있습니다.
이러한 API 그룹에는 서로 다른 리소스가 있으며 각 리소스에는 Verb라고 하는 연결된 작업 집합이 있습니다.
권한 부여에 대한 다음 섹션에서는 이를 사용하여 사용자에 대한 액세스를 허용하거나 거부하는 방법을 확인할 수 있습니다.