Kubernetes v1.32 - Penelope

#cncf #cloud-native #kubernetes/version/1-32-penelope

노트 속성
created 2024-12-17 17:22
is-folder false
aliases 쿠버네티스 페넬로페
related 버전
index 2
webaddress https://kubernetes.io/blog/2024/12/11/kubernetes-v1-32-release/

개요

|700

Kubernetes v1.31 - Elli 이후 나온 새로운 쿠버네티스 버전![1]
이 노트는 위의 문서를 정리하는 노트이다.
쿠버네티스는 고대 그리스어로 조타수를 의미한다.
이 릴리즈의 이름이 페넬로페인 이유는 지난 10년 간 걸어온 발걸음과 이뤄낸 성취를 나타내기 위함이다.
오디세이아에서 페넬로페는 오디세우스를 기다리며 10년 간 직물을 짜는데, 이것은 마치 쿠버네티스의 다양한 변화를 통해 나아간 꾸준함과 비슷하다.
매번 이뤄진 각 릴리즈는 매번 쿠버네티스를 발전시켰으나, 이 릴리즈는 10년을 마무리하는 것으로서 더욱 상징적이다.

Title

쿠버 기여자라면 살짝 감동받을 듯..나도 언젠가 그런 감동을 받는 사람이 되고 싶다.
내가 이렇게 문서를 정리하는 것은 독해 속도와 이를 정리하는 능력을 향상시키는 동시에 지속적으로 쿠버네티스의 방향성과 기술들을 학습하기 위함이다.
어느 정도는 내가 핵심이라 생각되는 부분만 남기고, 적절하게 수정한다.
공식 문서에 변경된 부분까지 가져와서 예시도 넣는다.
내가 이해한 만큼만 정리되는 것이기에 조금씩 틀리는 부분이 있을 수도 있다.

총 44개의 기능이 생겼는데, 13개는 stable, 12개는 베타, 19개의 알파 기능이 도입됐다.

최신 주요 기능

DRA 개선

이번 버전 역시 이전과 마찬가지로 동적 자원 할당(Dynamic Resource Allocation)에 주력을 다하고 있다.
GPU, FPGA나 네트워크 어댑터와 같은 리소스를 요구하는 워크로드들을 더 유연하게 지원하기 위함이다.
이를 통해 머신러닝, 고성능 컴퓨팅이 필요한 아키텍쳐를 지원하고자 한다.
이와 관련된 각종 기능들이 Beta로 전환되었다.

노드와 사이드카 컨테이너에 대한 라이프 퀄리티 개선

이제 systemd의 감시 기능은 kubelet 헬스체크를 통해 서비스를 재시작한다.
물론 최대 횟수와 시간 제한을 설정할 수 있다.

Image pull back-off 에러가 나올 때 파드 상태에 대해 나오는 메시지가 조금 더 사람-친화적으로 바뀌었다.
구체적으로 왜 이 파드가 이런 상태가 되었는지 제공해준다는 것이다.
이 상태는 statsus.containerStatuses[].state.waiting.message에 제공된다.
에러가 발생할 시 이 필드가 추가된다.

Title

이런 필드가 없더라도 여태 터미널로는 잘 확인할 수 있기는 하다만, 이렇게 필드가 생긴다면 알림 자동화에서는 상당한 도움이 될 것이다.

사이드카 컨테이너 기능은 1.33에서 안정 상태가 될 것이다.

Title

처음 쿠버 문서를 정독하면서 공부할 당시 현업자들과 이 표현 때문에 엄청 혼선이 있었던 그 기능..
당시 초기화 컨테이너의 일부로서 사용해야 하는 기능이라 사이드카 패턴의 용례와 너무 달라서 빚어진 문제라고 생각한다.
솔직히 사이드카 컨테이너는 분명 유용한 기능이지만 역시 초기화 컨테이너에 들어가 있다는 것이 나는 탐탁치 않다.
차라리 그냥 spec 하위 필드로 sidecar container가 추가되는 것이 훨씬 직관적일 것이라 생각한다.

스테이블로 전환되는 것들

커스텀 리소스에 필드 셀렉터 기능이 추가된다.
이는 더 좋은 api 디자인 방식을 제공하여 내부 모니터링이나 각종 개발에 유연성, 효율성을 허용한다.
https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#crd-selectable-fields

무엇인가 했는데, 그냥 사용하는 라벨 셀렉터와는 다른 녀석이다.

메모리 기반 볼륨의 사이징을 지원한다.
동적으로 파드 리소스 제한 메모리 기반 볼륨들을 조정하여 워크로드의 이식성과 노드 리소스 유틸성을 높인다.

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: registry.k8s.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir:
      sizeLimit: 500Mi
      medium: Memory

emptyDir를 쓰면 tmpfs를 통해 메모리 공간을 활용할 수 있는데, 이때 이 부분을 동적으로 조정할 수 있게 된다는 것이다.[2]

ServiceAccount 토큰 바운딩 개선.
노드 이름을 서비스 어카운트 토큰 요청에 포함하여 이 정보를 유효성 검사(ValidatingAdmissionPolicy)에서 활용할 수 있게 됐다.
이는 서비스 어카운트에 대한 권한 허용이 노드에 대한 권한으로 상승되는 것을 방지한다.

서비스 어카운트 토큰은 특정 오브젝트에서 양식으로 지정할 수 있다.
이때, 노드 네임 정보도 지정할 수 있게 된 것이다.[3]

구조화된 권한 설정.
API 서버에서 여러 권한 부여자를 설정하여 구조화된 권한 결정을 할 수 있으며, 웹훅에서 CEL 일치 조건을 지원한다.

구조화된 권한이라는 것은 1.30에서 베타로 옮겨졌다.[4]

apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
# Someone with a valid token from either of these issuers could authenticate
# against this cluster.
jwt:
- issuer:
    url: https://issuer1.example.com
    audiences:
    - audience1
    - audience2
    audienceMatchPolicy: MatchAny
  claimValidationRules:
    expression: 'claims.hd == "example.com"'
    message: "the hosted domain name must be example.com"
  claimMappings:
    username:
      expression: 'claims.username'
    groups:
      expression: 'claims.groups'
    uid:
      expression: 'claims.uid'
    extra:
    - key: 'example.com/tenant'
      expression: 'claims.tenant'
  userValidationRules:
  - expression: "!user.username.startsWith('system:')"
    message: "username cannot use reserved system: prefix"
# second authenticator that exposes the discovery document at a different location
# than the issuer
- issuer:
    url: https://issuer2.example.com
    discoveryURL: https://discovery.example.com/.well-known/openid-configuration
    audiences:
    - audience3
    - audience4
    audienceMatchPolicy: MatchAny
  claimValidationRules:
    expression: 'claims.hd == "example.com"'
    message: "the hosted domain name must be example.com"
  claimMappings:
    username:
      expression: 'claims.username'
    groups:
      expression: 'claims.groups'
    uid:
      expression: 'claims.uid'
    extra:
    - key: 'example.com/tenant'
      expression: 'claims.tenant'
  userValidationRules:
  - expression: "!user.username.startsWith('system:')"
    message: "username cannot use reserved system: prefix"

원래 인증은 JWT만으로 이뤄졌으나 다양한 방식과 상세 설정이 가능하도록 양식으로 설정하는 기능이 안정화됐다는 것.

StatefulSet으로 만들어진 PersistentVolume가 자동으로 제거된다.
데이터 영속성을 유지하며 노드를 보수한다!
이는 고립된 pvc 관련한 스토리지 관리를 단순화시킬 것이다.

apiVersion: apps/v1
kind: StatefulSet
...
spec:
  persistentVolumeClaimRetentionPolicy:
    whenDeleted: Retain
    whenScaled: Delete
...

feature gate를 활성화해야 한다.

베타로 전환되는 것들

여기 것들은 거의 다 피쳐 게이트를 활성화해야 한다.

managedBy 필드는 외부 컨트롤러가 잡 동기화를 할 때 도움을 준다.

익명에 지정한 엔드포인트만 허용하기.
가령 익명의 접근에 대해 헬스포인트 요청을 허용하고 싶다면 그렇게 세부 설정이 가능하다.
이는 쿠버 RBAC 설정을 하지 않은 클러스터에 대해 익명의 접근을 일차적으로 막아주게 된다.

이건 기본으로 설정돼있다.

apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
anonymous:
  enabled: true
  conditions:
  - path: /livez
  - path: /readyz
  - path: /healthz

이런 식으로 설정 가능하다.
보안에 대한 구체적인 설정을 하지 않았을 때, api server에 대해 이 정도의 접근만 허용하는 식으로 활용된다.

플러그인 별 콜백 함수 지정을 통한 kube-scheduler 정확한 재큐잉 개선
이 기능은 QueueingHint를 제공하여 효율적인 스케줄링 처리량이 가능하게 한다.


스케줄링 프레임워크라는 걸 통해 스케줄링을 관리할 수 있는데, 이때 큐잉힌트를 통해 조금 더 편하게 관리할 수 있도록 도와준다는 것.[5]
스케줄링 프레임워크를 아직 내가 잘 몰라서 이 이상의 이해는 조금 어렵다..

볼륨 확장 실패에 대한 복구
이 기능은 볼륨 확장이 실패했을 때 작은 사이즈로 재시도하게 만든다.
이를 통해 데이터 손실, 충돌에 대한 위험을 줄일 수 있다.

디폴트 기능으로, 구체적으로는 pvc 확장을 이야기한다.
원래 pv에 대해 클레임에 용량을 확장할 때, 용량이 안 맞아 실패하면 pvc 지웠다가 다시 만들고 사이즈 조정하는 짓거리를 해야 한다.
그냥 하면 데이터가 날아가니까, 일단 pv를 retain으로 만들고 하는 등의 아주아주 귀찮은 짓거리를 해야 하는데..
근데 그렇게 하지 않고 바로 양식 수정해서 다시 apply만 해도 되게 하는 기능.

볼륨 그룹 스냅샷.
VolumeGroupSnapshot API를 통해 유저가 여러 볼륨을 한꺼번에 스냅샷으로 딸 수 있다.

특정 CSI 드라이버는 볼륨들을 스냅샷하는 기능을 제공하는데, 이때 여러 개를 할 수 있는 api를 만들었다는 것.[6]

구조화된 파라미터 지원
DRA의 코어 파트가 베타로 승격됐다.
이건 쿠베 스케줄러와 클러스터 오토스케일러가 직접적으로 할당을 시뮬레이션할 수 있도록 돕는다.
이제 요소들은 실제로 할당하지 않더라도 현재 클러스터의 상태를 보고 리소스 요청이 충족 가능한지 예측할 수 있다.
서드파티 솔루션의 도움 없이 스케일링과 스케줄링 프로세스가 더 효율저긍로 이뤄질 수 있게 된다.

라벨, 필드 셀렉터 인가
셀렉터들이 인가 결정에 사용될 수 있다.
노드 인가자는 자동으로 노드에 대한 파드 리스팅과 조회에 대한 이점을 가지게 된다.
웹훅 인가자는 셀렉터 기반으로 요청을 제한할 수 있다.

기본으로 설정되는 기능으로, 각 노드 kubelet이 자신의 노드에 대해서만 상태 조회를 할 수 있도록 만든다.[7]

이 모드들 중, Node, Webhook에 대해 제공되는 기능인 듯.

알파로 전환되는 것들

쿠베 스케줄러의 비동기적인 선점.
비동기로 선점 동작을 하며 스케줄링 처리량을 높인다.
우선순위 높은 파드들이 자원을 갖도록 하는 선점 방식은 원래 api 콜을 통해 파드를 제거하느라 무거웠다.
이 기능을 통해 앞으로는 선점 동작을 하면서도 다음 요청을 수행할 수 있게 된다.
파드 교체나 스케줄링 실패가 많은 클러스터에서 유용할 것이다.

스케줄링에 있어서 비동기 방식은 좋을 수 있긴 한데, 비동기가 되려 문제를 수반하는 케이스는 없으려나.
스케줄링에 대해서만 기능하니까 크게 문제될 것은 없을 것 같기도 하다.
축출되려는 파드에 대해 스케줄러가 접근할 이유도 없으니까..
근데 축출되는 순간의 노드의 상태를 토대로 다음 스케줄링을 행하나?
만약 축출이 진짜 되기도 전에 축출된 상태라고 etcd에 노드 상태를 기록하고 스케줄러가 동작한다면?
실제로는 자원이 부족한 노드에 파드가 스케줄링이 될 수도 있는 것 아닌가?
결국 파드가 축출된 이후에는 kubelet이 pending 상태인 파드에ㅔ 대해 알아서 실행을 시켜주겠지만, 짧은 지연이 발생할 수도 있겠다는 생각이 든다.
한편 생각해보면 어차피 스케줄러 차원에서도 동기 지연이 발생할 건데 이 정도 지연을 스케줄러가 감당할 필요가 없다는 것이 이 기능의 개발 이유일 것 같다.

CEL 표현식을 통한 변형 승인 정책

gpt 번역

이 기능은 CEL의 객체 인스턴스화 및 JSON 패치 전략을 활용하고, 서버 측 적용의 병합 알고리즘과 결합됩니다. 정책 정의를 간소화하고, 변형 충돌을 줄이며, 승인 제어 성능을 향상시키면서 Kubernetes에서 더 강력하고 확장 가능한 정책 프레임워크의 기초를 마련합니다.
Kubernetes API 서버는 이제 CEL 기반의 변형 승인 정책을 지원하여 변형 승인 웹후크에 대한 경량의 효율적인 대안을 제공합니다. 이 개선을 통해 관리자는 CEL을 사용하여 레이블 설정, 필드 기본값 지정 또는 사이드카 주입과 같은 변형을 간단하고 선언적인 표현으로 선언할 수 있습니다. 이 접근 방식은 운영 복잡성을 줄이고 웹후크의 필요성을 없애며 kube-apiserver와 직접 통합되어 더 빠르고 신뢰할 수 있는 프로세스 내 변형 처리를 제공합니다.

이 부분은 아직 잘 모르겠습니다..

파드 레벨의 자원 명시
파드 단위로 리소스 제한을 걸 수 있다.
파드 내에서 동적으로 사용하는 공유 자원에 대해 제약을 걸기 쉽게 된다.
변동성이 심한 컨테이너를 품은 파드에 대해 오버 프로비저닝을 줄이는데 도움을 줄 수 있다.
이 기능은 컨테이너 레벨의 리소스 제한과 호환되어 기존의 세팅과 충돌하지 않는다.
멀티 컨테이너 파드에 대해서 복잡성을 줄여줄 것이다.
사이드카 컨테이너를 삽입할 때도 특히 도움을 줄 것으로 생각된다.

위에서 잠깐 봤던 emptyDir의 메모리 기능을 사용할 때 유용할 것으로 생각된다.

프리 스톱 훅 sleep 행동에 대한 0값 허용
프리스톱 라이프사이클 훅을 걸 때, 유연한 옵션을 제공한다.
이전에는 유효성 에러를 일으켰다.
그러나 이제는 sleep 0도 유효하게 되어 그냥 바로 종료하는 동작을 가능케 한다.
PodLifecycleSleepActionAllowZero 피처 게이트를 걸어야 하며, 이것도 기존과 호환된다.

라이프사이클 훅을 사용해본 적 없어서 0이 허용 안 되는 줄도 모르고 있었다;;

DRA: 리소스 요청 상태에 대한 표준화된 네트워크 인터페이스 데이터.
새로운 필드를 제공한다.
이를 통해 장치 상태를 요청 오브젝트에 제공한다.
네트워크 정보에 대해 표준화된 방법을 제시한다.

코어 요소에 대해 새로운 statusz, flagz 엔드포인트.
새로운 두 엔드포인트가 생겼다.
클러스터 디버깅과 요소의 버전에 대한 인사이트를 제공해준다.
업타임과, 어떤 플래그로 실행되는지도 알려주게 될 것이다.

어? 이거 엄청난 거 아님?? ㅋㅋ
그러니까 매번 컨트롤 노드에 정적 파드 위치에 들어가서 확인 안 해도 되게 해준다는 거임?
위에서 익명 요청을 가능하게 하는 옵션과 함께 동작하면, 편하게 피처 게이트들을 확인할 수 있게 되는 건가..
각 요소들이 어떤 버전인지에 대해서 내가 쓸 일은 없어보이지만 아무튼 좋은 엔드포인트임에는 분명하다고 생각한다.
오잉 한글화가 된 문서가 있다.[8]

이전에는 리눅스 노드에 대해서만 지원하던 안정적인 종료를 윈도우 노드에도 지원한다.
윈도우의 kubelet이 알아서 시스템을 종료하게 될 것이다.
예정된 유지 보수, 업데이트에 대해서 클러스터의 안정성을 향상시켜줄 것이다.
cpu, 메모리 어피니티도 추가된다.

윈도우에서 돌아갈 수 있다는 것조차 처음 알았다 ㅋㅋ

졸업, 제거된 기능들

졸업된, 안정이 된 모든 기능의 리스트는 아래와 같다.

제거된 기능들

추후 이벤트

March 2025

April 2025

May 2025

June 2025

Upcoming release webinar

1.9일 목요일에 릴리즈팀 웨비나가 있다.

참고

  1. https://kubernetes.io/blog/2024/12/11/kubernetes-v1-32-release/ ↩︎

  2. https://kubernetes.io/docs/concepts/storage/volumes/ ↩︎

  3. https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/ ↩︎

  4. https://kubernetes.io/blog/2024/04/25/structured-authentication-moves-to-beta/ ↩︎

  5. https://kubernetes.io/docs/concepts/scheduling-eviction/scheduling-framework/ ↩︎

  6. https://kubernetes.io/docs/concepts/storage/volume-snapshots/ ↩︎

  7. https://kubernetes.io/docs/reference/access-authn-authz/node/ ↩︎

  8. https://kubernetes.io/ko/docs/reference/using-api/health-checks/ ↩︎