17. Core Concepts - Kube API Server

이 글은 아래 자료를 참고하여 작성되었습니다.

Udemy [Certified Kubernetes Administrator (CKA) with Practice Tests]

 

1. API Server란?

API 서버는 클러스터의 중심적 요소로서, 클러스터의 제어 평면(Control Plane)의 일부이다. API 서버는 Kubernetes 시스템이 외부에서 오는 모든 요청을 처리하고, 클러스터 내부에서 발생하는 작업들을 조율하는 역할을 한다. API 서버는 클러스터에 대한 중앙화된 인터페이스로서, 리소스 관리와 상태 유지에 필수적이다.

 

2. API Server의 주요 역할과 기능

2-1. 데이터 관리

API 서버는 클러스터 내 모든 상태 정보를 관리하는 핵심 역할을 한다. ETCD와 상호작용하는 유일한 컴포넌트로, 클러스터 리소스의 실시간 상태와 과거 기록을 안전하게 관리한다.

• 기능:
  • 리소스의 생성, 수정, 삭제 요청을 처리
  • ETCD에 상태를 기록 및 조회
  • 클러스터의 리소스 상태를 유지 및 추적

2-2. 보안 관리

API 서버는 클러스터 접근을 제어하고, 인증(Authentication) 및 권한 부여(Authorization)를 통해 보안을 관리한다. 이를 통해 클러스터는 비인가된 접근이나 잘못된 요청으로부터 보호된다.

• 기능:
  • 사용자와 요청에 대한 인증 처리
  • RBAC(Role-Based Access Control) 같은 권한 부여 메커니즘을 통해 요청 권한 확인
  • TLS(Transport Layer Security)로 통신 암호화

2-3. 요청 및 리소스 관리

API 서버는 클러스터에 들어오는 모든 요청을 처리하며, 리소스의 생성 및 업데이트 작업을 수행한다. 내부 컴포넌트나 클라이언트 도구인 kubectl을 통해 API 서버로 전달된 요청을 처리하고, 리소스 상태를 조정한다.

• 기능:
  • REST API 요청 수신 및 처리
  • 애드미션 컨트롤러와 협력하여 요청을 검토 및 승인
  • 성공적으로 처리된 요청에 대한 응답 반환

2-4. 다른 컴포넌트와의 통신

API 서버는 Kubernetes 스케줄러, 컨트롤러, 노드(실제 Kubelet) 등과 상호작용하며, 클러스터 상태를 조율한다. 스케줄러가 작업을 배포하고, 컨트롤러가 리소스 상태를 모니터링하며 유지할 수 있도록 지원한다.

• 기능:
  • 스케줄러에게 새로운 작업 전달
  • 컨트롤러와 리소스 상태 정보 교환
  • 클러스터 내 컴포넌트 간 통신을 조정

2-5. 확장성 및 성능 관리

API 서버는 클러스터의 확장성을 지원하며, 대규모 클러스터에서도 안정적으로 동작할 수 있도록 설계되어 있다. 여러 API 서버 인스턴스를 배포함으로써 트래픽을 효율적으로 분산 처리하고, 성능을 유지할 수 있다.

• 기능:
  • API 서버의 수평 확장 지원
  • 트래픽 분산 처리
  • 높은 가용성 제공

 

3. API Server 동작 흐름

1. API 요청 수신
   • 사용자가 kubectl을 통해 명령을 입력하거나, API 요청을 직접 보낸다.
   • 이 요청은 API server가 수신한다. 이때 클라이언트는 인증 정보(예: 토큰, 인증서 등)를 함께 전달한다.
2. Authentication (인증)
   • API Server는 요청에 포함된 해당 인증 정보를 바탕으로 외부 인증 시스템 또는 자체 인증서를 사용해 요청자의 신원을 검증한다. (사용자가 누군지 확인)
   • 만약 인증이 실패하면 요청은 즉시 거부되며, 클러스터의 다른 단계로 진행되지 않는다.
   • 인증 방식
     • 클라이언트 인증서(Client Certificates): TLS 인증서를 통해 사용자 신원을 확인하는 방식.
     • Bearer Token: 사용자가 API 요청에 포함하는 토큰을 이용한 인증.
     • OpenID Connect (OIDC): 외부 인증 서버와 통신하여 사용자를 인증.
     • Webhook Authentication: 외부 시스템과 연동하여 사용자 인증을 수행.
3. Authorization (권한 부여)
   • API Server는 인증된 사용자가 요청한 작업(예: Pod 생성, Service 삭제 등)을 확인한다.
   • RBAC 같은 권한 부여 메커니즘을 사용하여 해당 작업이 허용된 작업인지 결정한다.
   • 만약 사용자가 해당 작업을 수행할 권한이 없다면 요청은 거부된다.
   • 권한 부여 방식:
     • RBAC (Role-Based Access Control): 역할 기반 접근 제어. 사용자는 특정 역할(Role)과 연관되어 있으며, 역할에 따라 클러스터에서 허용된 작업이 결정된다.
     • ABAC (Attribute-Based Access Control): 속성 기반 접근 제어. 사용자가 속성에 따라 클러스터에서 작업을 수행할 권한을 가진다.
     • Webhook Authorization: 외부 서비스와 연동하여 권한 검증을 수행할 수 있다.
4. Admission Controller 개입
   • 어드미션 컨트롤러는 요청이 클러스터에 적용되기 전에, 해당 요청이 추가적인 정책 검사를 수행한다. 이는 클러스터의 보안, 자원 제약, 정책 준수를 보장하기 위한 마지막 검증이다.
   • 예를 들어, PodSecurityPolicy를 통해 Pod가 보안 기준에 맞는지, ResourceQuota를 통해 클러스터 자원 사용량을 초과하지 않는지 확인할 수 있다.
   • 요청이 클러스터 정책을 위반하면 거부되거나 수정될 수 있다.
   • 주요 어드미션 플러그인:
     • PodSecurityAdmission: Pod의 보안 정책을 검사.
     • ResourceQuota: 사용자가 요청한 자원이 클러스터의 자원 할당량을 초과하지 않는지 확인.
     • LimitRange: Pod에 대한 자원 제한(예: CPU, 메모리) 적용.
     • MutatingAdmissionWebhook: 요청을 변형할 수 있는 웹훅 플러그인.
     • ValidatingAdmissionWebhook: 요청을 검증할 수 있는 웹훅 플러그인.
5. Request Validation (유효성 검사)
   • API Server는 요청의 형식이 올바른지, 필수 필드가 포함되어 있는지 등의 요청 자체의 유효성을 검사한다.
   • 이 검사는 주로 Kubernetes 리소스의 스키마와 요청 데이터가 일치하는지 확인하는 역할을 한다.
6. Retrieve Data (데이터 조회)
   • 요청이 인증되고 유효성이 확인되면, 필요한 데이터를 etcd에서 조회한다.
   • 예를 들어, 사용자가 기존의 Pod나 Service에 대한 정보를 요청했다면 API Server는 etcd에서 해당 리소스의 현재 상태를 조회한다.
7. Update ETCD (데이터 업데이트)
   • 만약 요청이 클러스터의 상태를 변경하는 작업(예: 새로운 Pod 생성, 기존 리소스 수정 등)이라면, API Server는 그 요청에 따른 변경 사항을 etcd에 기록한다.
   • 예를 들어, 사용자가 새로운 Pod를 생성하면 API Server는 이 정보를 etcd에 기록하여 상태를 저장한다. 이 단계에서는 아직 Pod이 어느 노드에서 실행될지는 결정되지 않은 상태이다.
8. Controller Manager 개입
   • kube-controller-manager는 Kubernetes 클러스터에서 여러 종류의 컨트롤러를 관리하는 역할을 수행한다. 컨트롤러는 클러스터 리소스가 "원하는 상태(desired state)"와 "현재 상태(current state)"를 유지하도록 돕는다
   • 예를 들어, 사용자가 Deployment를 생성하면 Deployment Controller는 그에 맞는 ReplicaSet을 생성하도록 API Server에 요청한다.
   • ReplicaSet Controller는 실행 중인 Pod 수가 설정된 값과 일치하는지 지속적으로 확인하고, 만약 Pod가 중단되면 새로운 Pod를 생성하도록 API Server에 요청한다.
   • 컨트롤러 매니저는 클러스터 상태를 지속적으로 모니터링하여, 리소스가 항상 "원하는 상태"에 맞게 유지되도록 자동으로 조치를 취한다.
   • 주요 컨트롤러:
     • Deployment Controller: Deployment 객체를 관리하며, 애플리케이션을 점진적으로 롤아웃(업데이트)하거나 롤백하는 역할을 한다.
     • Replication Controller/ReplicaSet Controller: 설정된 수의 Pod가 항상 실행 중인지 확인하고, 부족할 경우 새로운 Pod를 생성한다.
     • Node Controller: 노드의 상태를 감시하고, 노드가 다운되었을 경우 이에 따른 조치를 취한다.
     • Job Controller: Job 객체를 관리하며, 요청된 작업이 성공적으로 완료될 때까지 Pod를 실행한다.
9. kube-scheduler 개입
   • 스케줄러(kube-scheduler)는 클러스터에서 실행되지 않은 Pod가 있는지 모니터링한다. 새로운 Pod가 생성되면, 스케줄러는 클러스터의 리소스 상태(예: CPU, 메모리 등)를 기반으로 최적의 노드를 선택한다.
   • 스케줄러는 선택된 노드를 API Server에 전달하고, API Server는 이 정보를 etcd에 업데이트한다.
10. kubelet 상호작용
    • Kubelet은 각 노드에서 실행되는 에이전트로, 자신에게 할당된 Pod를 감지하고, 실제로 Pod를 실행하기 위해 컨테이너 런타임(예: Docker, containerd)을 호출한다.
    • kubelet은 노드와 Pod의 상태를 주기적으로 API Server에 보고한다. API Server는 이 정보를 etcd에 기록하여 클러스터 상태를 업데이트한다.

 

4. API Server 설치 및 구성

• 설치 방법: API Server는 Kubernetes 릴리스 페이지에서 바이너리로 제공되며, 이를 다운로드하여 마스터 노드에서 서비스로 실행하거나 Kubeadm을 이용해 설치할 수 있다.
• 옵션 설정: Kube-apiserver는 다양한 매개변수와 함께 실행된다. 이러한 매개변수들은 클러스터의 인증, 권한 부여, 암호화 및 보안 설정, etcd 서버 연결 등을 관리하는 데 사용된다.
• 옵션 조회 방법
  • 바이너리 설치 시: /etc/systemd/system/kube-apiserver.service 파일에서 옵션을 확인할 수 있다.
  • kubeadm 설치 시: API server는 master node의 kube-system 네임스페이스의 pod으로 배포되며, 옵션은 /etc/kubernetes/manifest/kube-apiserver.yaml 파일에서 확인할 수 있다
  • process 조회로 알아보기: master node에서 ps -aux | grep kube-apiserver