혼합 버전 프록시
혼합 버전 프록시 (Mixed Version Proxy)
Feature state: Kubernetes v1.36부터 Beta; 기본적으로 활성화
Kubernetes 1.37은 API 서버가 다른 피어(peer) API 서버로 리소스 요청을 프록시할 수 있게 하는 베타 기능을 포함해요. 또한 클라이언트가 전체 클러스터에서 제공되는 리소스를 discovery를 통해 전체적으로 볼 수 있게 해줍니다.
이는 한 클러스터 안에 서로 다른 버전의 Kubernetes를 실행하는 API 서버가 여러 개 있을 때 유용해요(예: Kubernetes 새 릴리스로의 장기 롤아웃 기간 동안).
이 기능을 통해 클러스터 관리자는 더 안전하게 업그레이드할 수 있는 고가용성 클러스터를 구성할 수 있어요. 방법은:
- 중요한 작업을 위해 discovery에 의존해서 포괄적인 리소스 목록을 보여주는 컨트롤러가 항상 모든 리소스의 완전한 뷰를 얻도록 보장합니다. 이 클러스터 전체의 완전한 discovery를 Peer-aggregated discovery 라고 불러요.
- (업그레이드 중에 발생하는) 리소스 요청을 올바른 kube-apiserver로 보냅니다.
이 프록시는 업그레이드 과정에서 발생하는 예상치 못한 404 Not Found 오류를 사용자가 보지 않게 막아줘요. 이 메커니즘을 Mixed Version Proxy 라고 부릅니다.
Peer-aggregated Discovery와 Mixed Version Proxy 활성화하기
API 서버를 시작할 때 UnknownVersionInteroperabilityProxy 기능 게이트가 활성화되어 있는지 확인하세요.
API 서버 사이의 프록시 전송과 인증
- 소스 kube-apiserver는 기존 APIserver 클라이언트 인증 플래그
--proxy-client-cert-file과--proxy-client-key-file을 재사용해서 피어(목적지 kube-apiserver)가 검증할 자신의 아이덴티티를 제시해요. 목적지 API 서버는--requestheader-client-ca-file커맨드 라인 인자로 지정한 구성에 기반해 피어 연결을 검증합니다. - 목적지 서버의 서빙 인증서를 인증하려면 소스 API 서버에
--peer-ca-file커맨드 라인 인자를 지정해서 인증 기관 번들(certificate authority bundle)을 구성해야 해요.
피어 API 서버 연결성 구성
피어가 요청을 프록시하는 데 사용할 kube-apiserver의 네트워크 위치를 설정하려면 kube-apiserver에 --peer-advertise-ip와 --peer-advertise-port 커맨드 라인 인자를 사용하거나, API 서버 구성 파일에서 이 필드들을 지정하세요.
이 플래그들이 지정되지 않으면 피어는 kube-apiserver의 --advertise-address나 --bind-address 커맨드 라인 인자의 값을 사용해요. 그것도 설정되지 않았다면 호스트의 기본 인터페이스가 사용됩니다.
Peer-aggregated discovery
기능을 활성화하면 discovery 요청이 기본적으로 (클러스터의 어떤 apiserver든 제공하는 모든 리소스를 나열한) 포괄적인 discovery 문서를 제공하도록 자동 활성화돼요.
참고:
Peer-aggregated discovery는 /apis 엔드포인트에 대한 Aggregated Discovery 요청에서만 지원되며, 비집계(unaggregated, legacy) Discovery 요청에서는 지원되지 않아요.
혼합 버전 프록싱 (Mixed version proxying)
내부에서 어떻게 동작하는지 (How it works under the hood)
피어의 정보가 컨트롤 플레인에 등록되기 전에 요청(피어의 정보를 등록하는 컨트롤러가 수신하는 요청)이 들어오면, 처리하는 API 서버는 503("Service Unavailable") 오류로 응답해요.