카레제육 블로그

AI API 게이트웨이 및 시맨틱 라우터 가이드

kare jeyuk — Sun, 10 May 2026 15:43:08 +0900

최근 AI API 게이트웨이와 시맨틱 라우터에 대한 논의가 뜨겁다고 한다. 인프라 관점에서는 이 기술들이 기존의 체계를 어떻게 바꾸고 보완할 것인지가 핵심이다. CNCF 거버넌스 보드 멤버인 Max Körbächer의 발표를 정리했다.

https://youtu.be/SxRKXfBsd1c

반년 전쯤 현장에서 흥미로운 대화가 오갔다. 누군가는 모든 게이트웨이를 AI로 교체해 똑똑하게 만들겠다고 했고 다른 누군가는 시맨틱 라우터가 있으니 AI API 게이트웨이는 필요 없다고 주장했다. 무언가에 AI를 붙이면 즉시 기존 기술을 대체할 수 있다고 생각하기 쉽지만 인프라 중심의 관점에서 그것이 항상 정답은 아니다. 이 둘은 대립하는 개념이 아니라 해결하려는 문제의 성격이 다르다.

1. 전통적인 API 트래픽과 AI/LLM 트래픽

전통적인 API 세계에서 가장 중요한 가치는 속도 신뢰성 확장성이다. API는 기민하게 움직여야 하고 모든 시스템은 이를 중심으로 빠르게 응답해야 한다. 반면 대규모 언어 모델 중심의 AI 세계는 문법이 다르다.

지연 시간은 전통적인 API에 비해 응답이 상당히 느리다. 데이터 형식은 서버 센트 이벤트 세션을 통해 거대한 데이터 덩어리를 주고받으며 문맥을 유지해야 한다. 결국 인증 권한 부여 같은 기본 작업은 유지하면서도 AI 특유의 무겁고 느린 트래픽을 어떻게 관리할 것인가가 인프라 엔지니어의 숙제다.

2. AI 게이트웨이의 역할과 혜택

AI 게이트웨이가 제공하는 가치는 전통적인 API 게이트웨이와 본질적으로 맞닿아 있다.

비용 관리는 전체적인 비용 개요를 파악하는 시작점이다. 보안은 적절한 사용자가 허용된 리소스에 접근하는지 확인한다. 로드 밸런싱 및 모델 폴백은 엔드포인트 장애 시 다른 모델로 자동 전환한다. 관측성 및 시맨틱 캐싱은 모든 게이트웨이가 지원하진 않지만 매우 흥미로운 확장 영역이다. 통합 API는 OpenAI 호환 엔드포인트를 통해 표준화된 인터페이스를 제공하여 애플리케이션 도입을 돕는다.

3. AI 게이트웨이 vs 시맨틱 라우터

이 두 개념은 역할이 명확히 나뉜다. AI API 게이트웨이는 트래픽 라우팅 권한 부여 비용 추적 그리고 오픈 텔레메트리를 통한 추적의 시작점 역할을 수행한다. 시맨틱 라우터는 요청의 의도를 분류해 모델 크기를 최적화하고 비용과 품질을 개선하는 데 집중한다. 비교적 최근에 등장해 빠르게 진화 중인 분야다.

4. 주요 오픈소스 도구 탐색

Envoy AI Gateway

Bloomberg와 같은 엔드 유저들이 개발에 깊이 투자하고 있는 도구. 구조적으로 두 계층으로 나뉜다. 티어 1(Central Gateway) 은 클라이언트 트래픽의 중앙 진입점으로, 인증·권한·레이트 리밋·비용 추적 등을 처리한 뒤 OpenAI·Anthropic·Bedrock·Vertex 같은 외부 LLM 제공자로 직접 라우팅하거나, 내부 모델로 가야 할 트래픽이라면 적절한 티어 2 게이트웨이로 넘긴다. 티어 2(Internal Gateway) 는 KServe 같은 모델 서빙 스택과 함께 클러스터 내부에 배치되어 자체 호스팅 모델 트래픽에 집중하며, 모델 버전 관리·릴리스·세분화된 보안 정책, 그리고 LLM 추론 최적화를 위한 엔드포인트 피커(endpoint picker)를 제공한다. 이 분리 덕분에 플랫폼 팀은 외부 클라이언트 영향 없이 내부 모델 운영 정책을 독립적으로 바꿀 수 있다.

장점은 여러 공급업체를 쓸 때 유용하며 유료 결제 유도가 없는 순수 오픈소스다. 단점은 단일 공급업체 사용 시 설정 오버헤드가 크고 개발 속도가 너무 빨라 안정성을 중시하는 아키텍트에게는 다소 불안할 수 있다.

LiteLLM

조직 내 셀프 서비스 환경을 구축하기에 최적화된 도구다. 특징은 유아이를 통해 팀별로 허용된 모델을 선택하고 API 키를 즉시 발급할 수 있다.

장점은 비용 지출이 투명하게 관리된다. 단점은 엔터프라이즈 규모로 확장 시 비용이 발생할 수 있고 데이터베이스나 레디스 등 운영 부담이 존재한다.

vLLM Semantic Router

요청을 차별화하여 서로 다른 모델로 전달하는 기능에 극도로 최적화되어 있다. 작동 방식은 사내 챗봇에 점심 메뉴가 뭐야라고 물으면 가벼운 모델로 답하고 마케팅 컨셉을 짜줘라고 하면 대형 모델로 연결한다. 임팩트는 거대한 모델에 단순 질문을 던지는 낭비를 줄여 지연 시간을 단축하고 비용을 극적으로 절감한다. 수천억 파라미터 모델 대신 수십억 모델로도 충분한 처리가 가능해지기 때문이다.

Kong AI Gateway

는 이미 Kong 생태계를 사용 중인 조직에 적합하다.

KGateway + Agent Gateway

클라우드 네이티브 환경에 최적화되어 있다. 특히 Agent Gateway는 쿠버네티스 클러스터 내 수많은 에이전트가 실수로 데이터베이스를 지우는 행위를 하지 못하도록 제어 장치 역할을 한다.

5. 최종 결정을 위한 가이드라인

도구 선택은 현재 팀의 환경과 우선순위에 달려 있다. 쿠버네티스 기반이며 Envoy 생태계에 익숙하다면 Envoy AI Gateway를 고려한다. 수많은 모델 공급업체 연동과 팀 단위 관리가 시급하다면 LiteLLM을 고려한다. 자체 호스팅 모델과 데이터 주권이 중요하다면 vLLM 시맨틱 라우터를 고려한다.

결국 AI 게이트웨이냐 시맨틱 라우터냐는 양자택일의 문제가 아니다. 이들은 서로 확장하고 보완할 수 있는 존재다. LiteLLM으로 모델 접근을 관리하면서 특정 요청은 시맨틱 라우터로 보내고 그 전체를 다시 envoy proxy로 감싸는 식으로 도구들을 쌓아서 자신만의 AI 플랫폼을 구축하는 것이 정답에 가깝다. CNCF 생태계는 빠르게 진화하고 있다. 관련 워킹그룹과 화이트페이퍼가 활발히 나오고 있는 만큼 이러한 흐름을 놓치지 않고 자신의 환경에 맞는 최적의 스택을 찾아가는 과정이 필요하다.

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에서 모든 변경 사항이 공식 발표될 예정입니다.