카레제육 블로그

KubeCon + CloudNativeCon Europe 2026 기초연설

kare jeyuk — Thu, 2 Apr 2026 11:55:33 +0900

최근 열린 KubeCon 2026에서는 클라우드 네이티브 생태계가 AI 시대를 맞이하여 어떻게 진화하고 있는지 엿볼 수 있었다. 특히 AI 인프라의 핵심으로 자리 잡은 쿠버네티스의 역할과, 글로벌 빅테크 기업들의 적극적인 오픈소스 기여가 눈에 띈다. 이번 행사에서는 특히 엔비디아의 CNCF 합류를 강조한것으로 보였다.

AI 추론(Inference), 인프라의 패러다임을 바꾸다

AI 모델의 중심이 학습(Training)에서 추론(Inference)으로 빠르게 이동하고 있다. 2023년까지만 해도 AI 컴퓨팅 리소스의 3분의 2가 모델 학습에 사용되었으나, 올해 말에는 이 비율이 역전되어 전체 AI 컴퓨팅의 3분의 2가 추론 워크로드에 할당될 전망이다. 2020년대 말에는 추론 전용 컴퓨팅 용량이 93.3기가와트를 넘어서며, 이는 다른 모든 컴퓨팅 부하를 합친 것보다 더 큰 규모가 될 것으로 예상된다. 단순한 챗봇을 넘어 코딩 에이전트와 같은 자율적인 AI 에이전트들이 추론 플랫폼의 '슈퍼 유저'로 활동하면서 사용량이 기하급수적으로 폭증하고 있기 때문이다.

엔비디아(NVIDIA), CNCF 플래티넘 회원으로 합류

이번 행사에서 가장 주목받은 소식 중 하나는 엔비디아가 CNCF의 최고 등급인 플래티넘 회원으로 합류했다는 점이라고 생각한다. 엔비디아는 AI의 미래가 쿠버네티스와 마찬가지로 커뮤니티 주도적이고 개방적인 형태(open)로 구축되어야 한다고 강조한다. 앞으로 AI가 직면할 과제들은 단순한 모델의 문제가 아니라 인프라, 확장성, 상호 운용성 등의 문제이며, 이는 단일 기업이 독자적으로 해결할 수 없기 때문이다.

엔비디아는 생태계 발전을 위해 아래와 같은 실질적이고 대대적인 기여를 약속했다.

- GPU 드라이버 기증: 쿠버네티스 SIG Node에 NVIDIA GPU 드라이버를 직접 기증하여 벤더 중립적인 쿠버네티스 DRA(Dynamic Resource Allocation) API의 참조 구현체(reference implementation) 역할을 하여 AI 인프라 표준화에 크게 기여할 것으로 보인다.

- 컴퓨팅 자원 지원: 향후 3년간 400만 달러를 약정하여, NVIDIA GPU가 필요한 모든 CNCF 프로젝트가 관련 컴퓨팅 자원에 원활하게 접근할 수 있도록 보장한다.

- 오픈소스 프로젝트 공유: AI 클러스터 런타임인 'Acre'를 오픈소스로 공개하였으며, 스케줄러인 'Kai'를 CNCF 샌드박스 프로젝트에 기여하는 등 직접적인 기술 공유를 확대한다.

AI 네이티브로 진화하는 쿠버네티스와 새로운 생태계

전체적인 생태계 역시 AI 워크로드를 효과적으로 지원하기 위한 다양한 변화를 맞이하고 있다. 최근 CNCF를 졸업(Graduated)한 프로젝트로는 보안 및 정책에 중점을 둔 Kyverno와 대용량 바이너리 및 AI 모델 배포에 특화된 Dragonfly가 있으며, Fluid와 Tekton은 지속적 제공 및 AI 활용 가속화를 목표로 인큐베이션(Incubation) 단계에 진입했다.

또한, 새롭게 CNCF 샌드박스에 합류한 llm-d는 클러스터 전체의 분산형 AI 추론을 최적화하는 프로젝트다. 단순한 라우팅을 넘어 프롬프트를 검사해 특정 데이터를 KV 캐시에 보유한 GPU로 요청을 보내는 추론 게이트웨이(Inference Gateway) 기능과, 연산 집약적인 '프리필(prefill)' 단계와 메모리 집약적인 '디코드(decode)' 단계를 분리하여 독립적으로 스케일링하는 세분화된 추론(Disaggregated Inference) 아키텍처를 지원한다.

쿠버네티스는 이러한 기술들을 표준화하기 위해 AI 적합성(AI Conformance) 프로그램을 개편했다. 플랫폼이 쿠버네티스 Gateway API 및 지능형 추론 라우팅(Inference Extension)을 지원하는지, 그리고 세분화된 추론을 지원하는지를 새로운 필수 인증 요건으로 추가하여 일관된 AI 인프라 환경을 검증하고 있다

CNCK 활동

kare jeyuk — Sat, 7 Feb 2026 23:38:54 +0900

얼마 전, CNCK(Cloud Native Community Korea)라는 커뮤니티의 오거나이저로 합류하게 됐다.

CNCK는 CNCF(Cloud Native Computing Foundation)의 벤더 중립 철학을 한국에 확산한다는 목표로 만들어진 커뮤니티로, 클라우드 네이티브, AI 네이티브, 오픈소스 키워드들에 관심 있는 사람이라면 누구든 함께할 수 있는 열린 공간을 지향하고 있다.

글로벌 클라우드 네이티브 생태계는 빠르게 움직이는데, 한국 현장의 목소리가 그 흐름에 자연스럽게 닿을 수 있는 채널은 보이지 않았다. 그리고 반대로 글로벌에서 일어나는 논의와 변화가 국내에 전해지는 속도도 늘 한 박자 느린 느낌이었다. CNCK는 바로 그 간극을 메우려는 시도다. 국내 현장의 요구와 의견을 글로벌 업스트림에 전달하고, 동시에 글로벌 생태계의 흐름을 국내로 가져오는 연결 고리가 되는 것이 목표다.

이제 시작하는 커뮤니티 조직의 오거나이저라는 타이틀이 주는 무게감이 없다고 하면 거짓말이겠지만, 솔직히 그보다는 기대가 훨씬 크다. 아직 아무것도 정해지지 않은 단계에서부터 함께 만들어간다는 것 자체가 재밌다.

세미나도 하고 싶고, 밋업도 열고 싶고, 국내 엔지니어들이 글로벌 오픈소스 프로젝트에 기여하는 경험을 더 쉽게 해볼 수 있도록 돕는 활동도 해보고 싶다.

정식 오프라인 킥오프 미팅이 기다려진다

AWS EKS 파드 수 제한 계산기

kare jeyuk — Mon, 30 Jun 2025 13:07:43 +0900

AWS EKS를 사용하다보면, 가끔 리소스가 충분함에도 파드가 동작하지 못하는 경우를 확인할 수 있는데요 이는 노드의 인스턴스 유형에 따라서 파드 수 제한 (네트워크 인터페이스에 따른 갯수 제한)이 존재하기 때문입니다.

이 제한은 노드의 네트워크 인터페이스(ENI)와 IP 주소 할당 가능 수에 따라 결정되며, 각 인스턴스 유형마다 최대 파드 수가 다릅니다. 이를 이해하면 클러스터 리소스 계획 및 파드 스케줄링 문제를 해결하는 데 도움이 됩니다.

공식에 따라 직접 계산할 수 있고, AWS 공식 Github 에서 해당 내용을 확인할 수 있지만 간단히 검색할 수 있는 홈페이지를 공유드립니다!!

https://aws-eks-max-pods.devops.ai.kr

gateway api docs l10n 진행 2주가 흘렀다.

kare jeyuk — Sun, 1 Jun 2025 17:12:57 +0900

먼저 주소부터 공유드린다. https://korean-mirror-gateway-api.netlify.app/

Introduction - Kubernetes Gateway API

Introduction Gateway API is an official Kubernetes project focused on L4 and L7 routing in Kubernetes. This project represents the next generation of Kubernetes Ingress, Load Balancing, and Service Mesh APIs. From the outset, it has been designed to be gen

korean-mirror-gateway-api.netlify.app

이전에 시작했다는 글을 작성한 지 2주가 지났지만, 이제서야 용어집과 대문인 소개 페이지의 한글화를 진행하였다. 현재 진행률은 PR 기준 약 12%로, 생각보다 매우 느린 진척도를 보이고 있다. 큰일이다!

한 페이지 작업에 많은 시간이 소요되는 이유도 한몫한다. 해당 용어가 공식 용어인지, 표현은 적절한지 등 확인해야 할 부분이 생각보다 많기 때문이다. PR을 올리게 된다면, 이후에는 Contributing을 진행하고, Guides, Reference, 그리고 Enhancements 순으로 진행할 예정이다.

그런데, 정말 많은 공부가 되고 있다. 용어집을 제외하면 개요만 진행하였는데도, 벌써 왜 Gateway API가 생겨났는지 그 사상에 대해 이해할 수 있었다. 이 점은 기술 자체를 이해하는 데 생각보다 많은 도움이 되었다. (사실 쿠버네티스의 경우, 처음에는 그냥 사용하다가 왜 이 기술이 등장했는지를 나중에 찾아보며 익혔기 때문에, 공부에 공감과 이해가 필요했던 나로서는 처음 시작에 많은 어려움이 있었다.)

더 힘내 보자.

공식 페이지:

한글화 미러 페이지:

gateway api docs l10n 시작

kare jeyuk — Sat, 17 May 2025 18:42:58 +0900

먼저 주소부터 공유드린다. https://korean-mirror-gateway-api.netlify.app/

Introduction - Kubernetes Gateway API

korean-mirror-gateway-api.netlify.app

이전부터 관심을 가지고 있던 gateway api에 운 좋게도 업무와의 접점이 생기기 시작했다.
문서를 읽을 때마다 DeepL에 의존하며 많은 리소스를 소모하고 있었는데, 종종 다른 분들도 같은 노력을 하고 있다는 걸 알게 되면서 바로 한글화를 시작하기로 마음먹었다. (AI의 발전이 언어 장벽부터 없애줄거라 생각했는데... ㅠㅠ)

첫 시작은 자연스럽게 용어집부터였다.
(여담으로, 예전에 Kubernetes 문서를 한글화했던 경험이 있어 그때 배운 노하우를 그대로 적용하고 있다. 그 과정에서 느꼈던 즐거움과 열정이 떠올랐고, 지금의 내 모습과 비교되면서 반성도 하게 되었다.)

미러 홈페이지를 처음 구성할 때, 생각보다 난관이 있었다. kubernetes docs는 Hugo 라이브러리를 사용하여 UI 생성과 l10n을 위한 구성이 되어있었는데, gateway api의 경우 Mkdocs로 만들어져 있었고 l10n를 고려하지 않았던 것인지 디렉터리 구조와 동적 변경을 위한 javascipt를 따로 추가해야했다. 이 내용은 나중에 회고에 작성할 예정이다.

개인적인 목표로 Overvice 페이지 한글화 진행이 완료 되는날, 공식 리포지터리에 이슈를 생성을 하고자한다.

힘내보자.

공식 페이지:

한글화 미러 페이지:

Kubernetes CSR (CertificateSigningRequest) 리소스

kare jeyuk — Sat, 17 May 2025 17:43:18 +0900

주변에서 생각보다 Kubernetes CSR의 존재를 잘 모르거나, 단순히 cert-manager에서 사용하는 리소스 정도로 알고있는 경우가 있어 이번 기회에 정리하고자 한다.

Kubernetes CSR은 v1.19에서 GA된 기능으로 admission controller가 한창 이목을 끌며 떠오를때 함께 알게되었던 개념이었다.

CSR 리소스의 개념

CertificateSigningRequest는 Kubernetes API 리소스 중 하나로, 사용자가 클러스터 내에서 인증서 서명 요청을 제출하고, 클러스터 내 CA가 이를 승인하여 X.509 인증서를 발급해주는 과정을 위한 리소스이다.

CSR 리소스를 사용하면 외부에서 수작업 없이, 자동화된 방식으로 인증서를 생성하고 관리할 수 있다.

경험을 바탕으로 설명하자면, multi cluster를 관리하는 플랫폼 혹은 제품들에서 service account를 생성하고, cluster admin 권한을 할당하여 auto generate 되는 secret token을 kubeconfig에 주입해 사용하는 일반적인 방법과 달리 kubelet, 사용자 kubeconfig, 서비스메쉬 등 관리 측면의 역할(Role) 인증에서 주로 사용되는 방법이다.

이때 사용되는 방법이 두 가지가 있다.

1. 쿠버네티스 CA와 조합하여 CRT 인증을 만들어 사용하기

2. CertificateSigningRequest를 사용하기

CSR 리소스의 구조부터 사용 방법을 차례로 알아보자

CSR 리소스의 구조

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: my-csr
spec:
  request: <Base64-encoded CSR>
  signerName: kubernetes.io/kube-apiserver-client
  usages:
    - client auth
  username: alice
  groups:
    - system:authenticated
status:
  conditions:
    - type: Approved
      reason: ...
      message: ...
  certificate: <Base64-encoded X.509 certificate> # 서명된 인증서

spec.request: openssl 등으로 생성한 CSR 파일을 base64 인코딩한 값
spec.signerName: 어떤 인증서 발급자가 서명할 것인지 (예: kubernetes.io/kube-apiserver-client)
spec.usages: 인증서의 용도 (예: client auth, server auth)

digital signature	서명용 (TLS 핸드셰이크, 인증서 증명)	KeyUsage: digitalSignature
key encipherment	키 암호화 (TLS 키 교환)	KeyUsage: keyEncipherment
server auth	서버 인증용 인증서	ExtendedKeyUsage: serverAuth
client auth	클라이언트 인증용 인증서	ExtendedKeyUsage: clientAuth

status.certificate: 인증기관(CA)이 서명한 최종 X.509 인증서가 여기에 포함됨
status.conditions: 승인(Approved) 혹은 거절(Denied) 여부

다음으로, CSR을 생성하고 사용하는 방법을 살펴보자.

CSR 발급 워크플로우

CSR 생성
사용자 또는 노드가 CSR (X.509 Certificate Signing Request)을 생성
→ 일반적으로 OpenSSL 또는 Go 코드로 .csr 파일 생성
CSR 리소스 제출
Base64 인코딩된 CSR을 포함하여 Kubernetes에 CertificateSigningRequest 리소스로 제출
CSR 승인 or 거부
클러스터 관리자 또는 승인 컨트롤러가 CSR을 Approved 또는 Denied로 설정
(수동 승인: kubectl certificate approve, 자동화 가능)
CA 서명 및 인증서 발급
Kubernetes의 CA가 서명을 진행하고 .status.certificate 필드에 서명된 인증서를 넣고
인증서 수령 및 사용
CSR 리소스를 조회하여 발급된 인증서를 추출하고, 클라이언트는 이를 자신의 신원 증명에 사용

사용 예시

# key 파일을 만든다. (개인키)
openssl genrsa -out 00103.key 2048

# Certificate Signing Request
# 아래 명령어로 csr 파일을 만든다. key를 기반으로 만듦
# csr 파일은 인증서를 요청할 때 인증 기관에 제출하는 인증서 서명 요청 파일 (.csr 또는 .pem)
openssl req -new -key 00103.key -out 00103.csr

# 위 명령 진행시 각종 정보를 입력함 이때, Common Name에 입력하는 내용이 user named가 된다.
openssl req -new -key 00103.key -out 00103.csr

위 과정까지 진행한 후 CSR 리소스를 사용하느냐, 수동 생성하느냐의 선택지로 나뉘어진다.

k8s CA로 인증하여 crt를 만드는게 아닌 CertificateSigningRequest를 사용한 방법은 다음과 같다.

# 위에서 이어서, 아래 명령어로 token을 인코딩된 출력에서 줄바꿈 없이 한 줄로 출력 후 복사
cat 00103.csr | base64 -w 0 

```yaml
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: 00103@internal.users # ADD
spec:
  groups:
  - system:authenticated
  request: LS0tLS1CRUdJTiABCDEFGHIJK0JIHGFEDCBA... # ADD
  signerName: kubernetes.io/kube-apiserver-client
  usages:
  - client auth
```

kubectl get csr # 하면 pending을 확인할 수 있음. 허가해줘야함
kubectl certificate approve 00103@internal.users

# 그리고 서명된 crt 파일을 받음
kubectl get csr 00103@internal.users -ojsonpath="{.status.certificate}" | base64 -d > 00103.crt`

kubectl config set-credentials 00103@internal.users --client-key=00103.key --client-certificate=00103.crt
kubectl config set-context 00103@internal.users --cluster=kubernetes --user=00103@internal.users
kubectl config get-contexts
kubectl config use-context 00103@internal.users

SignerName 종류

Kubernetes에서 제공하는 기본 signer는 다음과 같다.

Signer Name	설명
kubernetes.io/kube-apiserver-client	kube-apiserver 클라이언트 인증서
kubernetes.io/kubelet-serving	kubelet의 서버 인증서 (TLS)
kubernetes.io/kube-apiserver-client-kubelet	kubelet의 클라이언트 인증서
kubernetes.io/legacy-unknown	이전 버전 호환용, 되도록 사용 지양

cert-manager의 signer와 같이 커스텀 signer를 설치하여 사용할 수도 있다.

Admission Controller와 CSR

CSR 리소스를 처리하기 위해 사용하는 Admission Controller는 다음과 같다.

Controller 이름	역할
CertificateApproval	사용자의 kubectl certificate approve 요청을 감지하고 상태를 업데이트
CertificateSigning	승인된 CSR을 감지하고, cluster CA로 서명된 인증서를 발급
CertificateSubjectRestriction	(옵션) 사용자 또는 그룹이 CSR에서 특정 주체(subject)를 요청하지 못하게 막음

더 알아보기: ServiceAccount token vs CSR-based 인증서

항목	ServiceAccount Token (automount)	CSR 기반 X.509 인증서
인증 방식	JWT (JSON Web Token)	X.509 인증서 (TLS 인증)
주체	Pod 내부의 ServiceAccount	노드, 사용자, 외부 서비스 등
자동 발급 여부	✅ Pod 생성 시 자동 마운트	❌ CSR 제출 및 승인 필요
저장 위치	Pod 내부 /var/run/secrets/kubernetes.io/serviceaccount/token	별도 파일로 저장 (.crt, .key)
사용 목적	주로 Pod → API Server 호출	노드 인증, 사용자 인증, mTLS
인증 대상	Kubernetes API Server	주로 API Server or peer component
유효기간	짧음 (default 1hr~3hrs), 자동 회전 가능	일반적으로 더 길고 수동 회전 필요
보안 특성	서명된 JWT → API Server에서 검증	표준 TLS 핸드셰이크 사용
주요 사용처	일반 Pod 인증	kubelet, 사용자 kubeconfig, 서비스메쉬 등

더 알아보기: ServiceAccount Signing Key vs Kubernetes CA

항목	ServiceAccount Signing Key (--service-account-signing-key-file)	Kubernetes CA (ca.crt/ca.key)
키 종류	JWT 서명용 RSA 키 쌍 (PEM 포맷)	X.509 인증서용 RSA/EC 키 쌍
파일 예	/etc/kubernetes/pki/sa.pub, sa.key	/etc/kubernetes/pki/ca.crt, ca.key
사용 목적	ServiceAccount JWT 토큰 서명 및 검증	인증서(CSR) 서명, TLS 통신 검증
사용 위치	kube-apiserver의 JWT 검증 및 발급 (--service-account-...)	kube-apiserver, kubelet 등 X.509 인증서 관련 구성
교차 사용 가능?	❌ 서로 호환되지 않음	❌ 전혀 다름

killercoda CKS Scenario Issue] Falco Change Rule

kare jeyuk — Sun, 11 May 2025 23:18:56 +0900

CKS 시나리오 중 Falco Change Rule 에서 버그가 있다.

service falco-modern-bpf restart 명령을 통해 falco 재기동시, 편집한 falco_rules.yaml 가 초기화된다.

아마도 시나리오 세팅을 위한 작업이 어디선가 동작하는거 같은데 다음으로 넘어가기 위해서는 restart 없이 check로 진행할 수 있었다.

티켓 등록해놨는데 답변 오면 업데이트 하겠다!

Kubestronaut 취득 도전기..

kare jeyuk — Sat, 26 Apr 2025 19:59:44 +0900

Kubestronaut Program이라는 Kubernetes 관련 인증 제도가 있다. 아래의 CNCF 인증을 모두 취득한 개인에게 부여되는 칭호인 Kubestronaut에 대한 설명은 검색하면 아주 많은 정보를 알 수 있으니 생략하고, 이 글에서는 나에게 애증의 존재가 된 이야기를 기록하고자 한다

KCNA (Kubernetes and Cloud Native Associate)
KCSA (Kubernetes and Cloud Security Associate)
CKA (Certified Kubernetes Administrator)
CKAD (Certified Kubernetes Application Developer)
CKS (Certified Kubernetes Security Specialist)

사실 이 프로그램이 등장한 지 꽤 오래된 점이 있어서 지금에서야 많은 사람이 관련 내용을 알고 있으며 취득하였지만, 등장 당시에 나는 CNCF LF 멤버십 구독을 통해 소식을 바로 알았던 점과, 주변 몇몇 지인과 LinkedIn 1촌인 분들이 초기에 취득하고 관련 내용을 공유해주신 덕분에 다른 분들보다 정보를 더 많이 알고 었다고 생각한다.
이런 좋은 환경과 더불어 뭔가 멋지게 보이는 저 칭호를 얻고 싶다는 생각을 하는 건 당연했고, 당시 CKA와 CKAD를 가지고 있던 나는 빠르게 다음 과정인 CKS에 도전했었다.

그러나 처참하게, CKS에서 절망했다. 두 번의 시험에도 불구하고 낙제점을 받아 도전에 실패했고, 'S'가 붙은 시험은 두려움의 대상이 되었다. 그렇게 언젠가 다시 도전해야지라는 막연한 생각만 가지고 마음의 짐으로 남겨두었다가, 최근에 '그 언젠가가 바로 지금이구나'라는 생각이 들어 준비하게 되었다.

그리고 KCNA와 더불어 며칠 전 두려움의 대상인 'S'가 들어있는 KCSA까지 취득하여, 이제 드디어 CKS 한 개만 남아 있는 상황이 되었다. 사실 뜬금없이 이 글을 작성하는 이유도 여기에 있다. 업무가 끝난 평일 저녁을 투자하고 주말까지 CKS를 공부하다 보니 뭔지 모를 현자 타임이 와서, 각오를 다지고자 하는 마음의 기록이다.

클라우드 애플리케이션 엔지니어로 5년째 근무 중인 입장에서, 개인적인 경험을 바탕으로 시험 난이도를 평가하자면 다음과 같다.

KCNA << CKAD < CKA <<<<< KCSA < 고난의 행군 < CKS

이유는 다음과 같다.

KCNA: 실무와 관계없이 쿠버네티스와 클라우드 네이티브에 관심이 있다면 쉽게 합격할 수 있는 수준
CKAD: 쿠버네티스를 공부하는 취준생이라면 합격할 수 있는 수준
CKA: 쿠버네티스 실무를 2년 이상 했다면 킬러셸(killershell) 한번 연습 후 바로 합격할 수 있는 수준
KCSA: 클라우드 네이티브 환경을 잘 알고, 관련 내용을 적절한 영어로 표현할 수 있다면 합격할 수 있는 수준 (개인적으로 매우 어려움)
CKS: 쿠버네티스에 대해 심도 있게 공부해 본 사람이 보안과 관련한 컨트롤 플레인 유지보수에 관한 기본 지식을 갖춘다면 합격할 수 있는 수준 (진정한 공포의 대상)

개인 경험이 들어가 있어서 매우 매우 주관적인 평가라고 생각한다. 하지만 현업과 시험을 모두 경험해 본 사람이라면 공감할 수 있을 것이다. CKS 시험은 쿠버네티스 시험의 온몸 비틀기였다. (~~그래서 두 번이나 떨어졌나 보다.~~)

시험 정보를 얻고자 들어온 독자분들에게 정보를 주지는 못했지만, 응원은 드리고 싶다. 그리고 나도 다시 한 번 각오를 다진다.
우리 함께 힘내 보자.
언젠가 Kubestronaut 페이지에서 얼굴을 마주하고, 그곳이 한국인으로 가득 찰 그날까지...

Kubernetes v1.33 스포일러

kare jeyuk — Sat, 19 Apr 2025 15:33:55 +0900

Kubernetes v1.33 미리 보기

작성자: Agustina Barbetta, Aakanksha Bhende, Udi Hofesh, Ryota Sawada, Sneha Yadav | 2025년 3월 26일 수요일

Kubernetes v1.33 릴리스가 다가오면서, Kubernetes 프로젝트는 계속해서 진화하고 있습니다. 전체 프로젝트의 건강한 발전을 위해 기능이 폐지되거나 제거되거나 교체될 수 있습니다. 이 블로그 포스트에서는 v1.33 릴리스 팀이 사용자가 알아야 한다고 판단한 주요 변경 사항을 정리했습니다. 아래 정보는 현재 시점의 v1.33 릴리스 계획을 기반으로 하며, 최종 릴리스 이전에 변경될 수 있습니다.

Kubernetes API 제거 및 폐지 프로세스

Kubernetes 프로젝트는 기능 폐지에 대한 명확한 정책을 문서화해 두고 있습니다. 이 정책에 따르면,

Generally available(GA) API는 새로운 안정 버전이 존재할 때만 폐지될 수 있으며, 폐지된 이후 최소 1년 동안 유지됩니다.
Beta 또는 pre-release API는 폐지 이후 3개의 릴리스 동안 지원되어야 합니다.
Alpha 또는 experimental API는 별도의 사전 경고 없이 어느 릴리스에서든 제거될 수 있습니다.

API가 베타에서 안정 버전으로 승격되거나, 실패하여 제거되는 경우 모두 이 정책을 따릅니다. API가 제거될 때는 마이그레이션 경로가 명시된 가이드가 제공됩니다.

v1.33에서의 주요 API 폐지 및 제거

Endpoints API의 안정 버전 폐지

EndpointSlices API는 v1.21부터 stable 버전으로 제공되며, 기존 Endpoints API를 효과적으로 대체합니다. 기존 API는 단순했지만, 대규모 네트워크 엔드포인트에서는 확장성 문제가 있었습니다. EndpointSlices는 듀얼 스택 네트워킹 등의 기능을 제공하며, 이제 기존 Endpoints API는 폐지 수순에 들어갑니다.

이 변경은 Endpoints API를 직접 사용하는 사용자(스크립트, 워크로드 등)에만 영향을 미치며, EndpointSlices로 마이그레이션해야 합니다. KEP-4974를 참고하세요.

노드 상태의 kube-proxy 버전 정보 제거

v1.31에서 폐지된 후, status.nodeInfo.kubeProxyVersion 필드는 v1.33에서 완전히 제거됩니다. 이 필드는 kubelet에 의해 설정되었으나 정확하지 않았으며, v1.31 이후 기본적으로 비활성화되었습니다. 관련 정보는 KEP-4004를 참고하세요.

Windows Pod의 hostNetwork 지원 제거

Windows Pod 네트워킹은 Linux와의 기능 동등성을 목표로 했으며, host 네트워크 네임스페이스 사용을 통해 클러스터 밀도를 높이고자 했습니다. 그러나 containerd의 예기치 않은 동작과 대체 솔루션의 존재로 인해 해당 기능(Kep-3503)은 철회되며, v1.33에서 완전히 제거될 예정입니다.

v1.33의 주요 개선 사항

Linux Pod 내 사용자 네임스페이스 지원

가장 오래된 KEP 중 하나인 KEP-127은 Pod 보안을 강화하기 위해 Linux 사용자 네임스페이스를 도입합니다. 이 기능은 v1.25에 알파, v1.30에 베타(기본 비활성화)로 출시되었고, 이제 v1.33에서 기본 활성화됩니다.

이 기능은 기존 Pod에는 영향을 주지 않으며, pod.spec.hostUsers를 명시하여 수동으로 활성화해야 합니다. 이는 보안 취약점을 완화하기 위한 중요한 이정표입니다.

v1.33의 기타 주요 기능들

Pod 리소스의 인플레이스(무중단) 수직 확장

Pod의 리소스를 수정하려면 이전에는 Pod를 재시작해야 했습니다. 그러나 KEP-1287을 통해 Pod를 재생성하지 않고도 CPU/메모리 등의 리소스를 동적으로 수정할 수 있습니다.

이 기능은 v1.27에 알파로 도입되었으며, v1.33에서 베타로 예정되어 있습니다.
초기 부팅 시 많은 리소스를 할당하고 이후 줄이거나, 상태 저장 서비스의 무중단 확장에 유용합니다.

DRA의 ResourceClaim 장치 상태(Device Status) 베타 전환

v1.32에서 도입된 devices 필드는 ResourceClaim의 상태에 장치 상태 정보를 포함할 수 있도록 해줍니다. 이 필드는:

네트워크 인터페이스의 이름, MAC 주소, IP 주소 등을 보고하여 관측성과 디버깅을 향상시킵니다.
관련 KEP는 KEP-4817입니다.

네임스페이스 삭제 순서 지정

현재 네임스페이스 삭제는 순서가 랜덤하여, 관련 리소스가 잘못된 순서로 제거될 수 있는 보안 문제가 있었습니다.

KEP-5080은 논리적·보안적 종속성을 고려한 삭제 순서를 도입하여, Pod가 먼저 삭제된 후 NetworkPolicy 등이 제거되도록 보장합니다.

인덱스 잡(Indexed Jobs) 처리 향상

KEP-3850과 KEP-3998은 인덱스 잡에 대한 신뢰성과 제어력을 향상시킵니다.

인덱스별 백오프 한계를 정의할 수 있어, 실패한 인덱스만 재시도하게 할 수 있습니다.
일부 인덱스가 실패해도 잡을 성공적으로 완료된 상태로 처리할 수 있습니다.

더 알아보기

Kubernetes v1.33 릴리스는 2025년 4월 23일 수요일에 예정되어 있으며, 릴리스 노트와 CHANGELOG에서 모든 변경 사항이 공식 발표될 예정입니다.

Ingress-nginx v1.12.1 및 v1.11.5 취약점 패치

kare jeyuk — Sat, 19 Apr 2025 15:01:58 +0900

Ingress-nginx CVE-2025-1974: 반드시 알아야 할 사항

Tabitha Sable (Kubernetes 보안 대응 위원회) | 2025년 3월 24일 월요일

오늘 ingress-nginx 유지관리자들은 Kubernetes 클러스터를 공격자가 장악할 수 있게 만들 수 있는 치명적인 취약점 다수를 수정한 패치를 배포했습니다. 전체 Kubernetes 관리자의 40% 이상이 ingress-nginx를 사용하고 있다면, 사용자와 데이터를 보호하기 위해 즉시 조치를 취해야 합니다.

배경

Ingress는 워크로드 Pod를 외부에 노출하여 실제로 사용할 수 있도록 해주는 Kubernetes의 전통적인 기능입니다. Kubernetes 사용자는 애플리케이션이 네트워크상에서 어떻게 노출되어야 하는지를 구현에 독립적인 방식으로 정의할 수 있습니다. 그런 다음 Ingress 컨트롤러는 해당 정의를 기반으로, 사용자의 상황과 요구에 맞는 로컬 또는 클라우드 리소스를 설정합니다.

다양한 클라우드 공급자나 로드 밸런서 브랜드에 맞게 여러 종류의 Ingress 컨트롤러가 존재합니다. ingress-nginx는 Kubernetes 프로젝트에서 제공하는 소프트웨어 전용 Ingress 컨트롤러입니다. 그 다양성과 사용 편의성 덕분에 ingress-nginx는 매우 인기 있으며, Kubernetes 클러스터의 40% 이상에 배포되어 있습니다.

ingress-nginx는 Ingress 객체의 요구사항을 강력한 오픈소스 웹 서버인 nginx 설정으로 변환합니다. nginx는 이 설정을 바탕으로 Kubernetes 클러스터 내 다양한 애플리케이션으로 요청을 수락하고 라우팅합니다. 이 nginx 설정을 올바르게 처리하는 것은 매우 중요합니다. ingress-nginx는 사용자에게 상당한 유연성을 제공해야 하며, 동시에 nginx가 의도치 않게 오용되지 않도록 방지해야 하기 때문입니다.

오늘 패치된 취약점들

오늘 공개된 ingress-nginx 취약점 중 네 가지는 nginx 설정을 처리하는 ingress-nginx의 방식 개선에 해당합니다. 이러한 취약점이 존재할 경우, 특수하게 조작된 Ingress 객체로 인해 nginx가 잘못 동작하게 만들 수 있습니다. 이로 인해 ingress-nginx가 접근 가능한 Secret 값을 노출시키는 결과를 초래할 수 있습니다. ingress-nginx는 기본적으로 클러스터 전체의 Secret에 접근할 수 있으므로, Ingress 객체를 생성할 수 있는 권한이 있는 사용자 또는 엔티티는 클러스터 전체를 장악할 수 있습니다.

가장 심각한 취약점인 CVE-2025-1974는 CVSS 9.8점으로 평가되며, ingress-nginx의 Validating Admission Controller 기능을 통해 Pod 네트워크에 존재하는 어떤 것이라도 설정 인젝션 취약점을 악용할 수 있게 만듭니다. 보통 Ingress 객체를 생성하려면 높은 권한이 필요하지만, 이 취약점과 오늘 발표된 다른 취약점들을 결합하면 클러스터 관리자 권한 없이도 Kubernetes 클러스터를 장악할 수 있습니다. 일반적인 클라우드 환경에서는 Pod 네트워크가 모든 워크로드에 개방되어 있거나, 심지어 사내망에 연결된 사용자라면 누구나 접근 가능한 경우도 많아 매우 위험합니다.

오늘 릴리스된 ingress-nginx v1.12.1 및 v1.11.5는 이 다섯 가지 취약점 모두에 대한 패치를 포함하고 있습니다.

다음 단계

클러스터에서 ingress-nginx를 사용하는지 확인하세요.
다음 명령어로 확인할 수 있습니다 (클러스터 관리자 권한 필요)

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

ingress-nginx를 사용 중이라면 즉시 조치 계획을 수립하세요.
가장 쉽고 효과적인 방법은 오늘 배포된 패치 버전으로 업그레이드하는 것입니다. 모든 취약점이 이 버전에서 해결되었습니다.
즉시 업그레이드가 어렵다면, 위험을 줄이기 위해 ingress-nginx의 Validating Admission Controller 기능을 비활성화하세요.

Helm으로 설치한 경우:

helm upgrade --reuse-values my-ingress-nginx ingress-nginx/ingress-nginx \ --set controller.admissionWebhooks.enabled=false

수동 설치한 경우:

ingress-nginx-admission이라는 ValidatingWebhookConfiguration을 삭제
ingress-nginx-controller의 Deployment 또는 DaemonSet에서 --validating-webhook 인자를 제거

단, 이 기능은 사용자의 Ingress 설정 오류를 사전에 알려주는 유용한 기능이므로 업그레이드 후 반드시 다시 활성화하는 것이 좋습니다.

결론 및 참고 자료

CVE-2025-1974를 포함한 ingress-nginx 취약점은 많은 Kubernetes 사용자와 그들의 데이터를 위협하는 매우 심각한 문제입니다. ingress-nginx를 사용 중이라면 지체 없이 조치를 취하시기 바랍니다.

이번 취약점을 책임감 있게 공개하고 해결에 협력해준 Wiz의 Nir Ohfeld, Sagi Tzadik, Ronen Shustin, Hillai Ben-Sasson과 ingress-nginx 유지관리자 Marco Ebert, James Strong, 그리고 Kubernetes 보안 대응 위원회에 감사드립니다.

더 자세한 내용은 다음을 참고하세요.

[GitHub 이슈 목록]: CVE-2025-24513, CVE-2025-24514, CVE-2025-1097, CVE-2025-1098, CVE-2025-1974
ingress-nginx의 유지보수와 향후 계획에 대한 정보는 이 GitHub 이슈 또는 KubeCon/CloudNativeCon EU 2025에서 James와 Marco의 발표를 참고하세요.