64개의 Enhancement
- Alpha 24
- Beta 20
- Stable 18
- Deprecated 2
SIG-Network
1. Multiple Service CIDRS (status: stable)
Service IP를 할당하는 logic을 새롭게 구현.
ClusterIP는 유니크한 주소를 가지며, Service CIDR라고 불리는 사전에 정의된 IP 풀에서 할당.
문제: CIDR 범위 변경 어려움, CIDR가 부족하면 서비스 생성 실패.
Kubernetes는 이를 해결하기 위해 두 개의 새로운 API 오브젝트를 도입했고, 현재는 stable 상태로 사용 가능:
-
ServiceCIDR 오브젝트
관리자가 클러스터에 새로운 CIDR 블록을 추가 가능.
=> 서비스 IP 풀을 동적으로 확장 -
IPAddress 오브젝트
각 서비스에 할당된 IP를 오브젝트 단위로 추적 및 관리 가능.
=> 클러스터 내부에서 IP 추적 가능, 향후 IP 재사용, 모니터링, 감사 등에 유용함
2. nftables backend for kube-proxy (status: stable)
**호환성 문제로 iptables는 linux node에서 default로 남음.
현재 Linux에서 공식적으로 지원되는 kube-proxy 백엔드는 iptables와 ipvs.
iptables 에서 아래의 문제가 존재
- 컨트롤 플레인에서의 문제: iptables ruleset을 바꾸는 과정에서 성능 문제
단순 rule 추가 과정도 아래와 같음
lock
kernel에서 rule 전체 다운로드
rule 파싱 및 규칙 추가
커널 업로드
lock 해제- 데이터 플레인에서의 문제: 서비스 수가 많아질수록 iptables 규칙도 증가
들어오는 모든 패킷이 모든 규칙을 순차적으로 거쳐야 함 -> 병목 지점
위 문제를 해결하기 위해 nftables를 backend로 도입:
- Map 구조를 활용하기 때문에 전체 rule을 조회할 필요 없어 기존 성능 문제 해결.
- atomic 트랜잭션 적용.
GA는 아직 아니나 도입 예정
kube-proxy를 라이브러리로 제공하기 위한 리팩토링이 진행될 예정
3. Topology aware routing with trafficDistribution: PreferClose (status: stable)
multi-zone cluster의 경우 최적화된 service traffic을 제공하는 기능이 GA 승격
cross-zone의 데이터 송수신의 비용 증가 및 latency 발생(kube-proxy는 서비스 트래픽을 무작위로 백엔드에 라우팅) => v1.23 에서 topology routing 기능을 제공했으나 아래와 같은 문제가 발생
1. 기존 topologyKeys는 표준이 없어 예상치 못한 결과를 낳기도 했음.
2. topology-mode: Auto는 예측 불가능성과 제어 부족.
따라서 위를 해결하기 위한 새로운 필드가 도입,
-
trafficDistribution: PreferClose필드:
서비스 정의에 이 필드를 추가하면, kube-proxy가 클라이언트와 동일한 영역의 엔드포인트로 트래픽을 우선 라우팅 -
자동 페일오버 지원:
동일한 영역에 사용 가능한 엔드포인트가 없을 경우, Kubernetes는 자동으로 다른 영역의 엔드포인트로 트래픽을 라우팅하여 서비스 가용성을 유지
** 다만, 특정 zone의 엔드포인트가 과부하되는 문제는 계속 고려해야 함. 이 경우 다른 라우팅 전략 고려하거나, 그 zone의 엔드포인트 수 증가, 오토스케일링과 같은 리소스 제어 필요
SIG-Apps
1. Backoff limits per index for indexed Jobs (status: stable)
현재 Kubernetes Indexed Job은 전체 인덱스가 하나의 backoff limit을 공유함.
하나의 인덱스가 반복 실패하면, 아직 실행 중인 다른 인덱스까지 모두 종료됨.
각 인덱스에 독립적인 backoff limit을 부여:
- Per-index backoff limit 도입
인덱스마다 독립적으로 재시도 횟수를 관리 가능
하나의 인덱스가 실패해도 다른 인덱스는 계속 실행됨.
2. Job success policy (status: stable)
현재 Kubernetes에서는 모든 인덱스가 성공해야만 Job을 성공으로 간주
→ 이게 너무 엄격하고, 불필요한 리소스 낭비를 일으킴.
SuccessPolicy 라는 새로운 필드 도입:
- SuccessPolicy를 정의해서 Job이 성공으로 간주되는 기준을 명시
- 정책이 충족되면 SuccessCriteriaMet 라는 새로운 Job Condition을 추가.
- 정책이 충족되면 나머지 실행 중인 Pod들은 종료 (불필요한 리소스 해소)
Sig-Auth
1. Bound ServiceAccount token security improvements (status: stable)
-
unique token identifier(JTI)와 노드 정보를 토큰에 포함하여,
더 정확한 검증과 audit가 가능. -
노드 전용 제약 조건을 지원하여,
특정 노드에서만 토큰을 사용할 수 있도록 제한할 수 있게 되었고,
이를 통해 토큰 오용이나 보안 사고 위험을 감소
현재 GA 제공
SIG-CLI
1. Subresource support in kubectl (status: stable)
--subresource 플래그가 GA(General Availability)로 승격
이제 kubectl 명령어에서 --subresource 플래그를 사용해 서브리소스에 직접 접근하고 수정할 수 있습니다.
🛠️ 지원되는 명령어
get, patch, edit, apply, replace
SIG-Node
1. Sidecar containers (status: stable)
사이드카 컨테이너 기능이 Kubernetes v1.33에서 GA 승격
sidecar container는 restartPolicy: Always 속성을 가지며, 다음과 같은 동작을 보장:
- 애플리케이션 컨테이너보다 먼저 시작되고,
- Pod의 전체 수명 동안 계속 실행되며,
- 주 컨테이너들이 종료된 후 자동으로 종료됩니다.
2. Options to reject non SMT-aligned workload (status: stable)
SMT 환경에서 latency가 중요한 application의 운영 대한 예측 가능성을 높이기 위해 도입, GA 승격.
static CPU Manager 정책에 full-pcpus-only 옵션을 추가하면:
- 항상 물리 코어 단위로 CPU를 할당
- SMT가 켜져 있어도 스레드 공유를 막아 성능 간섭 방지
** 참고) vcpu로 논리적으로 나눠져 있어도 메모리 버스, L1-L2 캐시, 네트워크 등 자원을 공유함.
SIG-Scheduling
1. Defining Pod affinity or anti-affinity using matchLabelKeys and mismatchLabelKeys (status: stable)
MatchLabelKeys 와 MismatchLabelKeys 추가
사용 예시
1. 롤링 업데이트 시, 구버전과 신버전의 파드를 각각 버전별로 같은 존(Zone)에 배치하도록 설정
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- database
topologyKey: topology.kubernetes.io/zone
matchLabelKeys: # ADDED
- pod-template-hash2. MutatingWebhookConfiguration을 이용해 tenant 라벨을 자동으로 붙이고, tenant별로 Pod가 섞이지 않도록 배치할 수 있음.
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- matchLabelKeys:
- tenant # 나랑 같은 tenant만 affinity 대상
topologyKey: node-pool
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- mismatchLabelKeys:
- tenant 2. Considering taints and tolerations when calculating Pod topology spread skew (status: stable)
PodTopologySpread를 사용할 때,
taints와 tolerations도 스케줄링 계산에 포함할 수 있게 하자는 기능
예를 들어
node가 A, B가 존재하고 node B에는 taint/toleration이 foo=bar:NoSchedule로 걸려 있음.
deployment는 replica가 2개, topology 정책이 maxSkew:1 로 걸려있음.
scheduling시 node B를 계산에 포함하기 때문에 node b에 배치되려던 pod는 pending 상태에 빠지게 됨.
=> nodeTaintsPolicy의 default 값은 Ignore로 설정되어 있기 떄문
nodeTaintsPolicy: Honor 옵션을 사용하면:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: DoNotSchedule
nodeTaintsPolicy: Honor- taint를 toleration 하지 못하는 노드는 계산 대상에서 아예 제외
그럼 처음부터 node b는 고려되지 않음
skew 계산 정확해지고, Unexpected Pending 방지 가능
Sig-Storage
1. Volume populators (status: stable)
Kubernetes 1.12부터 PVC에 dataSource 필드 생김.
이는 기존 PVC 또는 VolumeSnapshot을 통해 클론하거나 복원할 수 있도록 만든 기능
다만,
- 현재 dataSource는 CSI(컨테이너 스토리지 인터페이스)가 지원하는 경우에만 동작하고,
- 특정한 타입만 허용하는 화이트리스트 구조(예: PVC, Snapshot만 가능).
- 사용자가 새로운 데이터 소스(Custom Resource 등)를 쓰고 싶어도 API 상으로 거부되거나 무시됨. 예를 들어 VM 이미지, 백업 데이터, 외부 오브젝트 등을 볼륨에 넣고 싶어도 방법이 없음.
=> DataSourceRef 필드 도입, 동작 방식이 바뀜
data-source-validator가 아래와 같이 "처리 가능 여부"를 미리 알려줌.
PVC 생성됨
↓
dataSourceRef 확인: git.example.com/GitRepository
↓
등록된 VolumePopulator 목록에서 검색
↓
매치되는 VolumePopulator 발견?
├─ YES → "OK, 누군가 처리할 것임" (이벤트 생성 안함)
└─ NO → "어? 이걸 처리할 populator가 없네!" (경고 이벤트 생성)
=>"S3 populator가 설치되지 않았습니다" 같은 명확한 메시지 전달Always honor PersistentVolume recalim policy (status: stable)
PersistentVolume 누수 방지 기능이 GA(General Availability)로 승격
기존 문제점 (v1.33 이전)
- 정상적인 삭제 순서:
PVC → PV 순서로 삭제하면 reclaim policy가 정상 작동
외부 스토리지 자원이 올바르게 정리됨- 문제가 되는 삭제 순서:
PV → PVC 순서로 삭제하면 reclaim policy가 무시됨
외부 인프라의 스토리지 자산이 삭제되지 않아 자원 누수 발생개선 후:
- finalizer 메커니즘을 사용하여 문제 해결: finalizer 때문에 PV는 즉시 삭제되지 않고 Terminating 상태로 남음.
- Delete reclaim policy가 올바르게 적용: PV가 완전히 삭제되기 전에 (즉, PVC가 삭제되어 finalizer가 제거된 후에) Delete reclaim policy에 따라 볼륨 삭제 프로세스가 진행.
이외 개선사항
DRA
VPA가 in-place로 downtime 없이 진행될 수 있음(Beta).
