Kube-apiserver

Kube-apiserver란?

마스터 노드의 컨트롤 플레인에 위치하여, 쿠버네티스 클러스터의 유일한 관문(Gateway) 역할을 하는 핵심 컴포넌트이다. etcd가 클러스터의 상태를 저장하는 두뇌라면, apiserver는 그 두뇌와 소통하기 위한 입과 귀 역할을 한다.

전통적인 시스템에서는 각 관리 도구나 사용자가 시스템의 여러 구성 요소에 직접 접근하는 경우가 많았다. 만약 회사의 여러 부서(스케줄러, 컨트롤러, 노드)가 있다고 가정해 보자.

외부 방문객(kubectl 사용자)이나 내부 직원(클러스터 컴포넌트)이 각 부서의 책임자에게 직접 찾아가 업무를 요청하고, 파일 보관실(etcd)의 문서를 마음대로 수정한다면 어떻게 될까?

요청자	대상 부서	작업 내용	결과
사용자 A	파일 보관실(`etcd`)	파드 정보 직접 수정	혼란 발생 (데이터 불일치)
사용자 B	노드 3	특정 파드 즉시 실행 요청	규칙 무시 (스케줄링 원칙 위배)
스케줄러	파일 보관실(`etcd`)	노드 정보 직접 조회	정보 충돌 가능성

이처럼 중앙 통제 없이 각자 소통하면, 권한 없는 작업이 실행되거나 데이터가 꼬이는 등 전체 시스템에 혼란이 발생한다.

Kube-apiserver는 이러한 문제를 해결하기 위해 마치 회사의 유일한 안내 데스크 또는 비서실처럼 동작한다. 모든 요청은 반드시 이 apiserver라는 단일 창구를 거쳐야 한다.

신원 확인 (인증): 방문객의 신분증을 확인하여 누구인지 파악.
방문 목적 및 권한 검토 (권한 부여, 유효성 검사): 방문 목적이 타당한지, 해당 업무를 요청할 권한이 있는지 확인.
업무 전달 및 결과 수신 (요청 처리 및 조정): 검토가 끝나면 요청을 담당 부서(스케줄러, Kubelet 등)에 전달하고, 파일 보관실(etcd)에 유일하게 접근하여 상태를 기록하며, 처리 결과를 요청자에게 알림.

요청자	Kube-apiserver (단일 창구)	담당 부서 / etcd
사용자 A	인증/권한/유효성 검사	`etcd`에 상태 변경
스케줄러	API로 통신	`etcd`에 상태 변경
Kubelet	API로 통신	`etcd`에서 상태 조회

이러한 중앙 통제 방식 덕분에 클러스터의 모든 변경 사항은 일관되고 안전하게 관리된다.

Kube-apiserver는 클러스터의 모든 관리 작업을 처리하는 중앙 허브 역할을 한다.

인증(Authentication): kubectl이나 다른 클라이언트의 요청이 오면, 사용자가 누구인지 인증한다. (예: 인증서, 토큰 확인)
권한 부여(Authorization): 인증된 사용자가 해당 요청을 실행할 권한(RBAC)이 있는지 확인한다.
유효성 검사(Validation): 요청 내용(예: Pod YAML 파일)이 쿠버네티스 문법에 맞는지, 필수 필드가 포함되었는지 등을 검사한다.

etcd와의 상호작용: 클러스터의 상태를 조회하거나 변경하는 모든 요청을 처리한다. etcd와 직접 통신하는 유일한 컴포넌트로서 데이터의 일관성을 보장한다.
상태 업데이트: Pod 생성, Service 설정 변경 등 모든 변경 사항을 etcd에 기록한다.

스케줄러(Scheduler): 노드가 배정되지 않은 Pod가 있는지 apiserver를 통해 감시하고, 적절한 노드를 찾으면 apiserver에 알려 Pod 정보를 업데이트한다.
Kubelet: 자신의 노드에 할당된 Pod가 있는지 apiserver에 주기적으로 확인하고, Pod의 상태를 apiserver에 보고한다.
컨트롤러 매니저(Controller Manager): Deployment의 복제본 수가 맞는지 등을 apiserver를 통해 감시하고, 상태가 다르면 apiserver를 통해 필요한 조치를 요청한다.

사용자가 kubectl apply -f nginx-pod.yaml 명령을 실행하면 다음과 같은 일이 벌어진다.

요청 접수: kubectl은 nginx-pod.yaml 파일의 내용을 apiserver에 HTTP POST 요청으로 보낸다.
검사 수행: apiserver는 요청을 보낸 사용자를 인증하고, Pod를 생성할 권한이 있는지 확인하며, YAML 내용이 유효한지 검사한다.
1차 저장: apiserver는 "아직 노드가 배정되지 않은" 상태의 Pod 정보를 etcd에 저장하고, 사용자에게 "생성 요청이 접수되었다"고 응답한다.
조정 시작:
- 스케줄러가 apiserver를 통해 이 Pod를 발견하고, node-1에 배정하라고 apiserver에 다시 알린다.
- apiserver는 Pod 정보를 etcd에 업데이트한다.
- node-1의 Kubelet이 apiserver를 통해 자신에게 할당된 Pod를 발견하고, 컨테이너를 생성한 후 "Running" 상태를 apiserver에 보고한다.
- apiserver는 최종 상태를 etcd에 기록한다.

개념을 넘어 실제 클러스터에서 apiserver를 어떻게 설정하고 확인하는지에 대한 방법이다.

apiserver의 모든 동작은 실행 시 주어지는 옵션(플래그)에 의해 결정된다.

Kubeadm 환경 (대부분의 경우): apiserver는 스태틱 파드로 실행되며, 설정 파일은 /etc/kubernetes/manifests/kube-apiserver.yaml 이다. 이 파일을 수정하면 kubelet이 자동으로 apiserver를 재시작한다.
수동 설치 환경: systemd 서비스로 실행되며, 설정 파일은 /etc/systemd/system/kube-apiserver.service 등이다. 수정 후에는 systemctl restart kube-apiserver 와 같은 명령어로 재시작이 필요하다.
공통 확인법: 마스터 노드에서 ps aux | grep kube-apiserver 명령어를 실행하면, 현재 적용된 모든 옵션을 직접 확인할 수 있다.

클러스터의 동작을 제어하는 중요한 플래그들이다.

ETCD 연동: --etcd-servers, --etcd-cafile, --etcd-certfile, --etcd-keyfile 등 etcd와의 통신 및 보안을 설정한다.
보안 및 인증/인가: --authorization-mode=Node,RBAC (인가 방식 지정), --client-ca-file (클라이언트 인증), --enable-admission-plugins (어드미션 컨트롤러 활성화) 등 클러스터 보안의 핵심을 담당한다.
감사(Audit) 로그: --audit-log-path, --audit-policy-file 등 보안 감사를 위해 모든 API 요청 기록을 설정한다.

고가용성 (HA): 안정적인 운영을 위해 여러 마스터 노드에 apiserver를 복제하여 실행하고, 앞단에 로드 밸런서를 둔다. 이를 통해 하나의 apiserver에 장애가 발생해도 클러스터 전체가 중단되는 것을 방지한다.
API 애그리게이션 (Aggregation): 사용자가 직접 만든 커스텀 API를 apiserver에 연결하여 쿠버네티스 API를 확장하는 기능이다. 이를 통해 코어 수정 없이 새로운 기능을 유연하게 추가할 수 있다.

728x90