Kubernetes Engine 주요 업데이트: 클러스터 운영부터 노드·시크릿 자동화까지
워크로드가 늘면 노드 용량을 조정해야 하고, 비밀번호나 API 키가 바뀌면 이를 사용하는 애플리케이션에도 반영해야 합니다. 클러스터 접근 범위와 노드 상태를 점검하는 일도 꾸준히 필요합니다. 특히 노드와 시크릿을 수동으로 관리하면 반복 작업이 늘고, 설정 변경이 일부 환경에만 적용될 수 있습니다.
최근 Kubernetes Engine 업데이트는 이 운영 과제를 클러스터 기능, 노드 자동화, 중앙 집중식 시크릿 연동의 관점에서 다룹니다. Karpenter와 External Secrets Operator(ESO)는 Kubernetes 생태계의 오픈소스 프로젝트이며, Kubernetes Engine은 카카오클라우드 자원과 Secrets Manager를 사용할 수 있도록 Provider와 배포판을 제공합니다. 이 글에서는 각 프로젝트가 담당하는 부분과 카카오클라우드에서 추가로 준비해야 하는 구성을 구분해 소개합니다.
클러스터 운영 기능 개선
API 서버의 접근 범위를 세밀하게 설정하고 노드 상태와 네트워크 구성을 더 쉽게 확인할 수 있도록 운영 기능을 개선했습니다.
주요 변경 사항은 다음과 같습니다.
- API 서버 엔드포인트 접근 제어: 접근 범위를 전체 허용하거나 허용할 IPv4 CIDR 목록으로 제한할 수 있습니다. 기존 클러스터에서도 허용 범위를 변경할 수 있습니다.
- Admission Webhook 통신 개선: Kubernetes 1.34 이상에서는 Konnectivity를 통해 API 서버와 Admission Webhook 서버가 통신하므로, Webhook 서버 파드에
hostNetwork: true를 설정하지 않아도 됩니다. - 노드 상태 진단 및 토폴로지 확인: Kubernetes 1.34 이상 클러스터에는 Node Problem Detector가 기본 설치되고 Kubernetes Engine에서 관리합니다. 클러스터와 노드 풀 상세 화면의 토폴로지 탭에서는 서브넷과 노드 구성을 확인할 수 있습니다.
- 로드 밸런서 구성 방식 개선: Kubernetes 1.30 이상에서
loadBalancerClass와 신규 annotation으로 로드 밸런서를 구성할 수 있습니다.
Kubernetes 1.30 이상 클러스터에서 기존 annotation 방식으로 로드 밸런서를 구성하고 있다면 전환을 준비해 주세요. 기존 방식은 2026년 12월 31일 지원이 종료될 예정입니다. Service와 로드 밸런서를 신규 방식으로 구성하고 트래픽을 옮기는 과정은 기존 방식에서 이전하기에서 확인할 수 있습니다.
워크로드 요구에 맞춰 워커 노드 자동 관리하기
트래픽과 작업량은 늘 일정하지 않습니다. 요청이 몰리거나 대규모 작업이 시작되면 파드를 실행할 노드가 더 필요하고, 작업이 끝나면 남는 용량을 줄여야 합니다. Karpenter는 클러스터 안에서 스케줄되지 않은 파드를 감시하고, 파드의 리소스 요구 사항과 배치 조건에 맞는 노드를 준비하는 컨트롤러입니다. Kubernetes Engine에서는 카카오클라우드 Virtual Machine API와 연결되는 Karpenter Provider를 함께 설치해 이 동작을 구현합니다.
Karpenter는 파드의 리소스 요구 사항과 노드 정책을 기준으로 Virtual Machine을 생성하고, 사용량이 낮아지면 필요하지 않은 노드를 회수합니다. 생성한 노드는 관리형 노드 풀과 별도로 관리되므로, 관리형 노드 풀의 노드 수를 직접 조정하지 않고도 변동성이 큰 워크로드에 필요한 용량을 확보할 수 있습니다.
Karpenter는 기존 관리형 노드 풀을 대체하기보다, 변동성이 큰 워크로드를 위한 별도 노드 자동화 계층으로 활용할 수 있습니다. GPU 워크로드는 GPU 전용 NodePool로 분리할 수 있으며, 필요한 설정은 GPU 워커 노드 구성에서 확인할 수 있습니다.
Kubernetes Engine의 Karpenter 연동은 현재 얼리 액세스로 제공되며 지원 리전과 인스턴스 유형이 정해져 있습니다. 생성한 Virtual Machine과 루트 볼륨에는 요금이 부과되므로, 지원 범위와 비용을 확인한 뒤 Karpenter 설치 및 노드 구성을 따라 설치하세요.
Secrets Manager의 시크릿을 클러스터에서 사용하기
데이터베이스 비밀번호나 API 키는 여러 워크로드에서 사용되고 주기적으로 변경됩니다. 이 값을 클러스터마다 직접 복사하지 않고 Secrets Manager를 원본으로 관리하면, 오픈소스 External Secrets Operator(ESO)가 필요한 값을 Kubernetes Secret으로 동기화합니다. 애플리케이션은 기존처럼 Kubernetes Secret을 환경 변수나 볼륨으로 참조하므로, Secrets Manager API를 직접 호출하도록 코드를 변경할 필요가 없습니다.
Kubernetes Engine에서는 카카오클라우드용 ESO 배포판의 Secrets Manager Provider를 사용합니다. 연동 설정에서 조회할 시크릿과 대상 Kubernetes Secret, 갱신 주기를 지정하면 ESO가 Secrets Manager의 값을 주기적으로 조회해 Kubernetes Secret을 생성하거나 갱신합니다.
연동 과정을 직접 확인하려면 다음 두 튜토리얼을 순서대로 진행해 보세요.
- Kubernetes Engine과 Secrets Manager 연동: ESO를 설치하고 인증정보와 동기화 리소스를 구성해 기본 연동을 확인합니다.
- Kubernetes Engine 클러스터에서 ESO 시크릿 활용하기: 문자열 시크릿을 동기화하고, Secrets Manager의 기본 버전 변경이 쿠버네티스 시크릿에 반영되는지 확인합니다.
- 카카오클라우드용 ESO Provider는 읽기 전용이므로 시크릿 생성·수정·삭제는 Secrets Manager에서 수행합니다.
- Kubernetes Secret이 갱신되어도 실행 중인 파드의 환경 변수는 자동으로 바뀌지 않으므로, 파드 재시작 또는 별도 갱신 정책이 필요합니다.
운영 환경에 적용해 보세요
이번 글에서 소개한 기능은 한 번에 모두 적용하기보다 운영 환경의 과제에 맞춰 선택하는 것이 좋습니다. API 서버 접근 제어와 클러스터 운영 기능은 운영 가이드에서, Karpenter와 ESO는 각각의 설치 가이드와 튜토리얼에서 사전 조건과 적용 절차를 확인해 보세요. 특히 기존 로드 밸런서 annotation을 사용 중이라면 2026년 12월 31일 지원 종료 전에 신규 방식으로 이전을 준비해 주세요.
구성 중 궁금한 점이나 지원이 필요한 경우에는 헬프데스크 > 기술 문의에 문의해주시기 바랍니다.
감사합니다.