Kubernetes v1.34: 바람과 의지 (Of Wind & Will) 업데이트 핵심

Kubernetes v1.34 바람과 의지 (Of Wind & Will)

Kubernetes v1.34, 코드명 "Of Wind & Will" (O' WaW)은 2025년 8월 27일 수요일에 발표됐다.   이번 릴리스는 총 58개의 개선 사항으로 구성됐다.  이 중 23개는 안정화(Stable) 단계, 22개는 베타(Beta) 단계, 13개는 알파(Alpha) 단계로 진입했다. 

공식 사이트

광고 클릭은 큰 힘이 됩니다!

Kubernetes v1.34: Of Wind & Will (O' WaW)

728x90

(공식 사이트에서 발췌한 내용을 기반으로 작성하였으나, 명확하지 않은 부분은 경험을 토대로 작성하였습니다. 이는 정확한 정보가 아닐 수 있음을 알려드립니다.)

---

Kubernetes 1.34 O' WaW 주요 핵심 사항

이번 릴리스 팀이 강조하는 주요 업데이트 중 다음 다섯 가지를 중심으로 정리한다.

1. 동적 리소스 할당 (DRA) GA (KEP #4381) - 안정화됨
2. 정렬된 네임스페이스 삭제 (KEP #5080) - 안정화 됨
3. kubelet 이미지 인증 공급자를 위한 투영된 ServiceAccount 토큰 (KEP #4412) - 베타 진입
4. Linux 노드 스왑 지원 (KEP #2400) - 안정화됨
5. KYAML, Kubernetes 방언 YAML 지원 (KEP #5295) - 알파 진입

요점 정리

1. 유연성: DRA의 코어가 GA로 안정화되어 GPU, TPU, NIC 등의 리소스 관리 방식이 더욱 강력해졌다.
2. 효율성: 멀티 컨테이너 파드에 대한 리소스 관리가 Pod 수준으로 정의 가능해져 설정이 간소화되고 리소스 활용이 향상됐다.
3. 보안성: 단기적이고 청중 바운드(audience-bound) ServiceAccount 토큰을 사용하여 이미지 풀 인증 방식의 보안 위험을 크게 줄였다.
4. 안정성: Linux 노드 스왑 지원이 안정화되어 메모리 부족 상황에서 워크로드 안정성이 개선됐다.
5. 사용성: KYAML 알파 기능을 통해 kubectl의 YAML 출력 및 입력이 더욱 안전하고 모호하지 않게 됐다.

운영자는 반드시 스테이징 환경에서 테스트 후 프로덕션에 적용해야 하며, 특히 알파/베타 기능 도입 시에는 세심한 주의가 필요함.

---

1. 동적 리소스 할당 (KEP #4381) - State: Stable

동적 리소스 할당(DRA)은 Kubernetes v1.34에서 안정화(Stable) 단계로 진입했으며, 기본적으로 활성화됐다. DRA는 Pod이 클러스터 내의 부착된 장치(예: 하드웨어 가속기)와 같은 리소스를 유연하게 요청하고 공유할 수 있게 하는 기능이다.

DRA를 통한 리소스 할당은 PersistentVolumeClaims를 사용하여 스토리지 용량을 요청하는 동적 볼륨 프로비저닝 경험과 유사하다.

기존 문제

기존 Kubernetes는 Storage를 제외한 GPU, TPU와 같은 장치(Device)를 선택, 할당, 공유, 구성하는 데 있어 강력하고 유연한 메커니즘이 부족했다.

1.34 개선

• 코어 DRA GA: 동적 리소스 할당(DRA)의 핵심 기능이 안정화(GA)됐다.
• 구조화된 매개변수 기반: DRA는 스토리지 볼륨의 동적 프로비저닝에서 영감을 받아, Kubernetes 코어에는 불투명한 구조화된 매개변수를 사용하여 장치를 요청한다.
• API 종류 안정화: resource.k8s.io/v1 API가 안정화됐으며, 기본적으로 사용 가능하다.

즉 DRA는 이제부터 쿠버네티스 클러스터 내 모든 하드웨어 자원을 클래스화 시켜서 사용한다는 뜻으로 생각하면 편할듯 하다.
스토리지 클래스에서 하드웨어 클래스로 승격한 느낌

DRA의 주요 이점

DRA는 기존 Device Plugin 방식에 비해 다음과 같은 이점을 제공하며, 장치 할당 워크플로우를 크게 개선했다:

1. 유연한 장치 필터링: CEL(Common Expression Language)을 사용하여 특정 장치 속성에 대해 세밀한 필터링을 수행할 수 있다.
2. 장치 공유: 동일한 리소스를 여러 컨테이너나 Pod이 ResourceClaim을 참조하여 공유할 수 있다.
3. 중앙 집중식 분류: 장치 드라이버나 클러스터 관리자가 DeviceClass를 사용하여 사용 사례에 최적화된 하드웨어 카테고리를 제공할 수 있다.
4. 간소화된 요청: 애플리케이션 운영자가 Pod 리소스 요청에 장치 수량을 명시할 필요 없이, ResourceClaim을 참조하여 장치 구성을 Pod에 적용한다.

사례

• GPU나 TPU가 필요한 복잡한 AI/ML 워크로드에서 요구 사항에 맞춰 동적으로 리소스를 할당하고 구성한다.

주의 및 활성 방법

• resource.k8s.io/v1 API는 안정화되어 기본적으로 사용할 수 있다.
• 이 기능은 SIG Device Management 주도로 진행됐다.

DRA를 통해 GPU, TPU, NIC 등 장치 관리 방식이 유연해지고 효율성이 높아졌으며, v1.34에서 핵심 코드가 안정화되면서 더욱 강력한 리소스 관리 기반을 제공한다.

---

2. 정렬된 네임스페이스 삭제 (KEP #5080) - State: Stable

기존 문제

기존 네임스페이스 삭제시 네임스페이스 내 리소스가 랜덤하게 삭제되며 의도치 않은 동작 이상을 야기하는 경우가 있었다. 체계적인 삭제 프로세스를 도입하여 안전하고 결정론적인 리소스 삭제를 보장한다.

1.34 개선

• 이 기능은 v1.33에서 베타로 도입되었고, v1.34에서 Stable(GA) 로 승격됨. 
• 이제 네임스페이스 삭제 시 더 구조화된 삭제 순서가 적용되어, Pod가 먼저 제거된 뒤 다른 리소스가 삭제되는 흐름을 보장함. 
• 이러한 순차적 삭제는 논리적/보안 종속성(logical & security dependencies) 을 고려한 설계임. 
• 이 기능은 CVE-2024-7598 (비결정론적 삭제로 인한 보안 취약점) 대응을 목적으로 일부 거론됨. 

 일반적 네임스페이스 삭제 로직이 “자원 종류 무작위 순서로 제거 → 네임스페이스 종료”였던 것을, “Pod 우선 삭제 → 나머지 리소스 삭제” 등 더 명확한 단계로 바꾸었다는 의미다.

사례

• 보안 민감한 클러스터에서, NetworkPolicy/Ingress/방화벽 규칙보다 먼저 Pod이 삭제되는 것을 방지
• 삭제 시 리소스 종속성 깨짐 현상 최소화
• 운영자가 예상 가능한 삭제 흐름을 기대할 수 있음
• 실수로 정책이 먼저 없어지는 경우 Pod이 위험 상태에 노출되는 시간 최소화

예를 들면, A 네임스페이스에 Pod + NetworkPolicy가 있을 때, kubectl delete namespace A 하면:

1. 먼저 모든 Pod가 종료됨
2. Pod이 모두 사라진 이후 NetworkPolicy, Service, ConfigMap, RoleBinding 등 나머지 리소스가 삭제됨

주의 및 활성 방법

• 기본 활성: v1.34에서 이 기능은 Stable 상태로 기본 활성화되어 작동함. 릴리스 노트에서 이 기능이 “graduated to stable”이라고 명시됨.
• 비활성화 방법: 문서에는 별도의 feature gate을 끄는 옵션이 명시되어 있지 않다. KEP 이슈에서는 ‘promote to stable’ 논의만 있음. 

---

3. kubelet 이미지 인증 공급자를 위한 투영된 ServiceAccount 토큰 (KEP #4412) - State: Beta

기존 문제

기존 Kubernetes 환경에서 kubelet이 개인 컨테이너 레지스트리로부터 이미지를 가져올 때 사용된 인증 방식은 장기간 유효한 Secret 기반의 고정 자격 증명 방식이었다. 이 Secret은 보통 노드나 네임스페이스 단위로 공유되어 특정 워크로드와 연결되지 않았으며, 자동으로 순환되지 않아 관리 부담과 보안 취약점을 동시에 초래했다. 

1.34 개선

• 단기 토큰 요청: kubelet이 컨테이너 레지스트리 인증을 위해 짧은 수명(short-lived) 과 청중 바운드(audience-bound) 특성을 가진 ServiceAccount 토큰을 자동으로 요청하고 관리할 수 있다.
• Pod ID 기반 인증: 이제 이미지 풀 인증은 노드 전체가 아닌 각 Pod의 ServiceAccount 정체성 을 기반으로 수행되어, 워크로드 단위의 세밀한 접근 제어가 가능하다.
• 보안 강화: 장기 Secret이 제거됨으로써 공격자가 사용할 수 있는 자격 증명이 대폭 줄어들고, 토큰 만료 시 자동 폐기된다.
• 자동 갱신 및 관리 단순화: kubelet이 주기적으로 새로운 토큰을 요청하므로 관리자는 별도의 갱신 작업을 수행할 필요가 없다.
• Credential Provider 통합: kubelet credential provider exec 플러그인을 통해 HSM, Vault, KMS 등의 외부 인증 시스템과 직접 연계할 수 있다.

예전엔 kubelet이 오래된 비밀번호로 이미지를 가져왔는데, 이제는 각 파드가 자기 전용의 일회용 토큰으로 안전하게 이미지를 가져온다.

사례

• 개인 레지스트리(예: registry.example.com)에서 모델 이미지를 가져오는 AI 워크로드의 경우, 파드가 실행될 때 kubelet은 해당 파드의 ServiceAccount를 기반으로 audience가 registry.example.com 인 토큰을 요청하고 이를 자동으로 레지스트리 인증에 사용한다.
• 토큰은 수 분 내 만료되며 kubelet이 자동 갱신하므로, 공격자가 획득하더라도 재사용이 어렵다.
• 이를 통해 워크로드 단위 정체성 기반 인증(Workload Identity) 을 구현하고, Secret 관리 부담을 제거할 수 있다.

주의 및 활성 방법

1) 활성화 방법

• kubelet 설정에서 기능 게이트 확인

--feature-gates=ServiceAccountTokenForKubeletCredentialProviders=true

• Credential provider 설정(/etc/kubernetes/credential-provider-config.yaml) 구성

apiVersion: kubelet.config.k8s.io/v1
kind: CredentialProviderConfig
providers:
  - name: registry-provider
    matchImages:
      - "registry.example.com/*"
    tokenAttributes:
      serviceAccountTokenAudience: "registry.example.com"
      serviceAccountAnnotationKeys:
        - "kubernetes.io/service-account.name"
    cacheType: Token
    requireServiceAccount: true

• API 서버에서 허용된 audience 정의

--allowed-kubelet-audiences=registry.example.com

• 구성 후 kubelet 재시작

systemctl restart kubelet

2) 비활성화(기본 상태로 되돌리기)

 

• kubelet feature gate 비활성화

--feature-gates=ServiceAccountTokenForKubeletCredentialProviders=false

 

• Credential provider 설정에서 tokenAttributes 항목 제거
• kubelet 재시작

 

주의 사항

• 토큰은 단기 유효(기본 10분 내외) 이므로, provider 캐싱이 올바르게 설정되지 않으면 이미지 풀 실패가 발생할 수 있다.
• audience 제한이 활성화된 클러스터에서는, 설정된 audience가 --allowed-kubelet-audiences 에 포함되지 않으면 kubelet 인증 요청이 거부된다.
• 외부 인증 시스템(Vault, KMS 등)을 사용하는 경우 provider가 exec 인터페이스를 통해 올바르게 토큰을 전달해야 한다.

사실상 이 기능은 쿠버네티스 내부에서 인증 기능을 떼어낸 뒤 레지스트리로 넘겨버린 느낌이라 어떤 의미를 갖는지 잘 모르겠다.

---

4. Linux 노드 스왑 지원 (KEP #2400) - State: Stable

기존 문제

역사적으로 Kubernetes 환경에서는 스왑이 기본적으로 금지(NoSwap) 되어 있었다.

이는 파드가 요청한 리소스(requests/limits)에 맞춰 스케줄링되기 때문에, OS 단에서 메모리를 스왑으로 넘기면 리소스 제어가 깨지고 성능 예측이 불가능해질 수 있었기 때문이다.

 

결과적으로, 노드의 물리 메모리가 한계에 도달하면 OOMKiller가 파드를 강제 종료시켰고, 이로 인해 워크로드가 불안정해지고 장애가 발생하는 문제가 빈번했다.

1.34 개선

v1.22에서 알파로 도입된 스왑 기능이 v1.34에서 Stable(정식) 로 승격되었다.

이제 운영자는 kubelet 단위로 스왑 허용 정책(SwapBehavior) 을 세밀하게 지정할 수 있다.

• LimitedSwap 모드 이 모드에서는 파드가 요청한 메모리 한도(memory.limit)를 초과하지 않는 선에서만 스왑을 사용할 수 있다. 즉, Pod의 limit 내부에서만 스왑이 가능하며 limit 초과 시에는 기존처럼 OOM이 발생한다.
• 시스템 안정성 강화 Redis나 Elasticsearch처럼 메모리를 일시적으로 많이 사용하는 애플리케이션이 순간적인 사용량 증가로 인해 종료되지 않고 스왑으로 완화된다.
• 효율적 리소스 활용 메모리를 전부 사용하지 않는 파드와 스왑을 필요로 하는 파드가 공존할 수 있어 전체 노드의 메모리 활용 효율이 향상된다.

사례

예를 들어, 한 노드에 다음 두 파드가 있다고 하자.

• Pod A: 1Gi 요청 / 2Gi 제한
• Pod B: 2Gi 요청 / 4Gi 제한

노드 전체 메모리가 6Gi라면, 두 파드가 모두 4Gi 이상 사용하려고 하면 기존에는 OOMKiller가 하나를 죽였지만, LimitedSwap 모드에서는 메모리 초과분을 스왑 공간에 잠시 저장하여 프로세스를 유지할 수 있다.

이는 대용량 로그 처리, 배치 작업, AI 모델 로딩처럼 일시적으로 메모리 피크가 있는 워크로드에 특히 유용하다.

주의 및 활성 방법

스왑 지원은 여전히 기본적으로 비활성화(NoSwap) 상태다. 운영자는 kubelet 설정 파일을 수정해 명시적으로 활성화해야 한다.

1) 활성화 방법

/var/lib/kubelet/config.yaml 또는 kubelet 실행 옵션에 다음을 추가한다.

failSwapOn: false
memorySwap:
  swapBehavior: LimitedSwap

이후 kubelet을 재시작한다.

systemctl restart kubelet

 

2) 비활성화(기본 상태로 되돌리기)

failSwapOn: true
memorySwap:
  swapBehavior: NoSwap

 

---

5. KYAML, Kubernetes 방언 YAML 지원 (KEP #5295) - State: Alpha

기존 문제

표준 YAML은 들여쓰기나 선택적 문자열 인용으로 인해 예기치 않은 유형 강제 변환을 초래하는 등 특정 문제를 야기했다. JSON은 주석 지원이 부족하여 구성 파일을 다룰 때 오류 발생 가능성을 높였다.

1.34 개선

• KYAML 도입(알파): 쿠버네티스를 위해 설계된 “안전하고 덜 모호한 YAML 서브셋”. 목적은 YAML/JSON의 단점을 피하면서, 쿠버네티스 구성에 더 예측 가능한 문법을 제공한다.
• 출력 포맷 추가: kubectl에서 -o kyaml 출력 형식을 선택할 수 있음.
• 입력 호환성: KYAML 파일은 그 자체로 유효한 YAML이므로, 모든 버전의 kubectl에 입력으로 전달 가능(즉, kubectl apply -f file.kyaml처럼 사용 가능). 

사례

• 검토·코드리뷰 친화 출력: CI나 리뷰 단계에서 kubectl get … -o kyaml로 더 덜 모호한 표기 형태를 얻어, 의도치 않은 형변환·포맷팅 놀람을 줄임.
• 사람이 쓰는 아티팩트: 샘플/문서/가이드 아웃풋을 KYAML로 고정해 독자들의 해석 일관성을 높임. 

1. 출력(클라이언트에서만 동작)

export KUBECTL_KYAML=true
kubectl get pods -A -o kyaml
kubectl get deploy myapp -n web -o kyaml

• 특정 쉘에서만 쓰고 싶다면 export 대신 한 줄로:

KUBECTL_KYAML=true kubectl get svc -o kyaml

• 비활성화(끄는 법):

unset KUBECTL_KYAML
# 또는 출력 형식을 명시적으로 변경
kubectl get pods -o yaml
kubectl get pods -o json

 

1. 입력(매니페스트 적용)

kubectl apply -f ./manifests/app.kyaml   # KYAML은 YAML과 호환되므로 그대로 apply 가능

 

입력은 항상 YAML Parser를 타기 때문에, 구버전 kubectl도 적용 가능(단, 출력 -o kyaml은 1.34+만 지원). 

 

주의 및 활성 방법

기본값은 비활성화

 

활성화: KUBECTL_KYAML=true 설정 후 -o kyaml 사용

비활성화: unset KUBECTL_KYAML 또는 -o yaml/json 사용

---

중요

잘못된 정보나, 문의등은 댓글로 메일과 함께 적어주시면 감사하겠습니다.