WIPI

프로그래밍과 기술 이슈를 빠르게 정리하는 개발 블로그

목록으로

Programming Notes

쿠버네티스 v1.36: 혼합 버전 프록시(Mixed Version Proxy) 베타로 승급

작성자

쿠버네티스 1.28에서 이전 블로그 포스트를 통해 혼합 버전 프록시(Mixed Version Proxy, MVP)를 알파 기능(기능 게이트 UnknownVersionInteroperabilityProxy 사용)으로 처음 소개했습니다. 이 기능의 목표는 단순하지만 매우 중요했습니다. 구버전 API 서버가 아직 알지 못하는 리소스에 대한 요청을 더 최신 버전의 피어(peer) API 서버로 올바르게 라우팅하여, 잘못된 404 Not Found를 반환하는 대신 클러스터 업그레이드를 더욱 안전하게 만드는 것이었습니다.

쿠버네티스 1.36에서 혼합 버전 프록시가 베타 단계로 승급되었으며, 기본적으로 활성화된다는 소식을 전해드리게 되어 기쁩니다! 이 기능은 초기 출시 이후 주요 공백을 메우고 아키텍처를 현대화하며 크게 발전했습니다.

기능이 어떻게 진화했는지, 그리고 클러스터에서 이를 활용하기 위해 알아야 할 사항을 살펴보겠습니다.

어떤 문제를 해결하나요?

업그레이드가 진행 중인 고가용성(HA) 컨트롤 플레인에서는 여러 버전의 API 서버가 동시에 실행되는 경우가 많습니다. 이러한 서버들은 서로 다른 API 세트(그룹, 버전, 리소스)를 제공할 수 있습니다.

MVP가 없다면, 클라이언트 요청이 해당 리소스를 제공하지 않는 API 서버(예: 업그레이드 과정에서 새로 도입된 API 버전)에 도달할 경우, 해당 서버는 404 Not Found를 반환합니다. 하지만 해당 리소스가 클러스터 내의 다른 서버에는 존재하기 때문에 이는 기술적으로 잘못된 응답입니다. 이는 잘못된 가비지 컬렉션(garbage collection)이 발생하거나 네임스페이스 삭제가 차단되는 등 심각한 부작용을 초래할 수 있습니다. MVP는 해당 요청을 처리할 수 있는 피어 API 서버로 요청을 프록시하여 이 문제를 해결합니다.

sequenceDiagram participant Client as 클라이언트 participant API_Server_A as API 서버 A (구버전/상이) participant API_Server_B as API 서버 B (신버전/가능) Client->>API_Server_A: 1. 리소스 요청 (예: v2) Note over API_Server_A: 로컬에서 처리할 수 없음을 확인 API_Server_A->>API_Server_A: 2. 디스커버리 캐시에서 가능한 피어 조회 API_Server_A->>API_Server_B: 3. 요청 프록시 (x-kubernetes-peer-proxied 헤더 추가) API_Server_B->>API_Server_B: 4. 요청을 로컬에서 처리 API_Server_B-->>API_Server_A: 5. 응답 반환 API_Server_A-->>Client: 6. 응답 전달

1.28 이후 어떻게 진화했나요?

초기 알파 구현은 훌륭한 개념 증명(PoC)이었지만, 몇 가지 제한 사항이 있었고 오래된 메커니즘에 의존했습니다. 베타 버전을 위해 어떻게 현대화되었는지는 다음과 같습니다.

  1. StorageVersion API에서 집계된 디스커버리(Aggregated Discovery)로 전환 알파 버전에서 API 서버는 어떤 피어가 어떤 리소스를 제공하는지 확인하기 위해 StorageVersion API에 의존했습니다. 이 방식은 기능적으로는 작동했지만, StorageVersion API가 CRD 및 집계된 API(aggregated APIs)를 아직 지원하지 않는다는 중대한 한계가 있었습니다. 베타 버전에서는 StorageVersion API 호출 대신 집계된 디스커버리(Aggregated Discovery) 데이터를 사용하도록 교체했습니다. 이제 API 서버는 집계된 디스커버리 데이터를 사용하여 피어의 기능을 동적으로 파악합니다.

  2. 빠졌던 퍼즐 조각: 피어 집계 디스커버리(Peer-Aggregated Discovery) 1.28 블로그 포스트에서 언급했듯이, 리소스 요청은 프록시할 수 있었지만 디스커버리 요청은 여전히 로컬 API 서버가 아는 정보만 보여준다는 한계가 있었습니다. 1.36에서는 피어 집계 디스커버리(Peer-Aggregated Discovery) 지원을 추가했습니다! 이제 클라이언트가 디스커버리를 수행할 때(예: 사용 가능한 API 목록 조회), API 서버는 자신의 로컬 뷰와 활성 상태인 모든 피어의 디스커버리 데이터를 병합합니다. 이를 통해 클라이언트는 어떤 API 서버에 연결되든 클러스터 전체에서 사용 가능한 모든 API에 대한 완전하고 통합된 뷰를 제공받게 됩니다.

sequenceDiagram participant Client as 클라이언트 participant API_Server_A as API 서버 A participant API_Server_B as API 서버 B Client->>API_Server_A: 1. 디스커버리 문서 요청 API_Server_A->>API_Server_A: 2. 로컬 API 목록 조회 API_Server_A->>API_Server_B: 3. 피어 API 목록 조회 (캐시 또는 직접 조회) API_Server_A->>API_Server_A: 4. 목록을 병합하고 결정론적으로 정렬 API_Server_A-->>Client: 5. 통합된 디스커버리 문서 반환

피어 집계 디스커버리가 기본 동작이 되지만(참고: --peer-ca-file 플래그가 설정된 경우 활성화되며, 그렇지 않으면 서버는 로컬 API만 표시하는 방식으로 되돌아갑니다), 특정 API 서버에서 제공하는 리소스만 확인해야 하는 경우도 있을 수 있습니다. 이 경우 요청의 Accept 헤더에 profile=nopeer 매개변수를 포함하여 비집계 뷰를 요청할 수 있습니다 (예: Accept: application/json;g=apidiscovery.k8s.io;v=v2;as=APIGroupDiscoveryList;profile=nopeer).

필수 구성 설정

기능 게이트는 기본적으로 활성화되지만, 피어 API 서버 간의 보안 통신을 허용하기 위해 특정 플래그를 설정해야 합니다. MVP가 올바르게 작동하려면 API 서버가 다음 플래그와 함께 구성되었는지 확인하십시오.

  • --feature-gates=UnknownVersionInteroperabilityProxy=true: 1.36에서는 기본값이지만, 확인하는 것이 좋습니다.
  • --peer-ca-file=<path-to-ca>: [중요] 필수 플래그입니다. 소스 API 서버가 대상 피어 API 서버의 서빙 인증서를 인증하는 데 사용할 CA 번들을 제공해야 합니다. 이 설정이 없으면 TLS 검증 오류로 인해 프록시가 실패합니다.
  • --peer-advertise-ip 및 --peer-advertise-port: 피어들이 이 API 서버에 도달하기 위해 사용해야 하는 네트워크 주소를 설정합니다. 설정하지 않으면 --advertise-address 또는 --bind-address 값이 사용됩니다. API 서버가 특정 내부 인터페이스를 통해 통신하는 복잡한 네트워크 토폴로지의 경우, 이 플래그를 명시적으로 설정하는 것을 적극 권장합니다.

kubeadm으로 구성하기

kubeadm으로 클러스터를 관리하는 경우, ClusterConfiguration 파일에서 다음과 같이 플래그를 설정할 수 있습니다.

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
apiServer:
 extraArgs:
   peer-ca-file: "/etc/kubernetes/pki/ca.crt"
 # 필요한 경우 peer-advertise-ip 및 port 설정

권장 사항

다중 마스터 클러스터를 운영하고 정기적으로 업그레이드한다면, 혼합 버전 프록시는 안전성을 크게 향상해 주는 기능입니다. 1.36에서 기본적으로 활성화됨에 따라 다음을 권장합니다.

  1. API 서버 플래그를 검토하여 --peer-ca-file이 제대로 설정되었는지 확인하십시오.
  2. 1.36 업그레이드를 준비하면서 스테이징 환경에서 이 기능을 테스트하십시오.
  3. 경험한 내용을 SIG API Machinery(Slack, 메일링 리스트, 또는 SIG API Machinery 회의 참석)를 통해 피드백해 주십시오.