Kubernetes 1.33 “Octarine” 업데이트 핵심

Kubernetes 1.33 Octarine

Kubernetes v1.33, 코드명 “Octarine”은 2025년 4월 출시된 이번 버전에는 안정성, 보안, 사용성을 강화하는 64개의 개선 사항이 포함됐다.

이 중 18개는 GA, 20개는 베타, 24개는 알파 단계에 도달했고 일부 기능은 더 이상 사용되지 않는다. 본 글에서는 중급 및 고급 사용자가 주목할 만한 다섯 가지 핵심 업데이트를 정리한다.

추가로 이 글은 kodecloud 유튜브를 참고하여 작성했다. 굉장히 좋은 영상이므로 시청후 글 작성을 마음 먹었다.

(자동 번역 자막 외에는 제공되는 한국어가 제대로 없기에 이 글을 작성한다.)

kodecloud kubernetes 1.33

(공식 사이트에서 발췌한 내용을 기반으로 작성하였으나, 명확하지 않은 부분은 경험을 토대로 작성하였습니다.

이는 정확한 정보가 아닐 수 있음을 알려드립니다.)

공식 사이트

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

Kubernetes v1.33: Octarine

Editors: Agustina Barbetta, Aakanksha Bhende, Udi Hofesh, Ryota Sawada, Sneha Yadav Similar to previous releases, the release of Kubernetes v1.33 introduces new stable, beta, and alpha features. The consistent delivery of high-quality releases underscores

kubernetes.io

Kubernetes 1.33 Octarine 주요 핵심 사항

안정적인 사이드카 컨테이너 (KEP-753)
인플레이스 포드 수직 확장 (KEP-1287)
OCI 이미지 볼륨 (KEP-4639)
사용자 네임스페이스 보안 (KEP-127)
kubectl 사용자 설정 .kuberc (KEP-3104)

요점 정리

안정성: 사이드카를 GA로 정식 지원해 멀티컨테이너 파드 안정성 확보
효율성: 실행 중 파드 리소스를 즉시 조정 가능해 운영 단순화
모듈성: OCI 이미지 볼륨으로 중복 없는 데이터 공유 가능
보안성: 사용자 네임스페이스로 rootless 환경에 한 걸음
사용성: kubectl .kuberc로 개인화된 CLI 환경 제공

운영자는 반드시 스테이징 환경에서 테스트 후 프로덕션에 적용해야 하며, 특히 OCI 이미지 볼륨과 인플레이스 리사이즈는 실무에서 세심한 주의가 필요합니다.

1. 안정적인 사이드카 컨테이너 (KEP-753) - State: GA

기존 문제

사이드카 패턴은 로깅, 모니터링, 프록시와 같은 보조 기능을 메인 컨테이너와 함께 실행하는 방식이며 다들 GA 처럼 사용했지만,

사실 GA가 아니였기에 이전 사이드카는 다음 문제를 야기 할 수 있었다.

시작 순서 보장 불가
메인 컨테이너보다 먼저 종료 가능성 존재
OOM 상황에서 사이드카가 우선 종료될 수 있음

1.33 개선

시작 종료 순서 보장: 사이드카는 항상 먼저 시작하고 마지막에 종료된다.
initContainers 확장: restartPolicy: Always를 사용해 init 컨테이너를 장기 실행 사이드카로 전환.
프로브 지원: 일반 컨테이너처럼 liveness/readiness/startup probe 사용 가능.
OOM 점수 동일: 메인과 동일한 우선순위를 받아 불필요한 종료 방지.
우아한 종료: 메인 컨테이너 종료 이후에 사이드카가 종료.

사례

서비스 메시: Envoy 같은 프록시가 항상 먼저 기동해 네트워크 안정성 확보
로그 수집기: Filebeat 같은 사이드카가 끝까지 로그를 처리
데이터 동기화: 메인 컨테이너 실행 전 필요한 데이터를 준비

주의 및 활성 방법

1.33 이전 버전 부터는 베타 기능으로 수동 활성화가 필요하다. 문서를 확인하면 4개의 컴포넌트에 모두 설정이 필요해 보인다.

Feature Enablement and Rollback
How can this feature be enabled / disabled in a live cluster?
 Feature gate (also fill in values in kep.yaml)
Feature gate name: SidecarContainers
Components depending on the feature gate:
kubelet
kube-apiserver
kube-controller-manager
kube-scheduler

enhancements/keps/sig-node/753-sidecar-containers at master · kubernetes/enhancements

Enhancements tracking repo for Kubernetes. Contribute to kubernetes/enhancements development by creating an account on GitHub.

github.com

네 컴포넌트 중 한 곳이라도 꺼져 있으면
- apiserver가 새 필드를 거부/드롭하거나
- kubelet이 Pod를 거부하거나
- 스케줄러가 자원 계산 빗나감(over/under scheduling) 등 문제를 일으킬 수 있다
롤백: 끄려면 동일 위치에서 SidecarContainers=false로 되돌리거나 인자를 제거하고, 사이드카 문법(initContainers+restartPolicy: Always)을 쓰는 Pod는 재배포해야 한다.

참고

2. 인플레이스 포드 수직 확장 (KEP-1287) - State: Beta

기존 문제

Kubernetes는 수평 확장에는 강했지만 실행 중인 포드의 리소스(CPU/메모리)를 변경하려면 파드를 삭제 후 재생성해야 했다.

이로 인해 다운타임, 운영 복잡성, 비효율성 문제가 있었다.

일례로 edit, patch 등을 통해 Workload의 리소스를 재 조정하면 POD는 필연적으로 재시작 되며, 이 과정에서 다운 타임은 어쩔수 없이 발생하게 된다. 이런 리소스 재 조정에 의한 다운 타임을 제거 할 수 있다는것이다.

1.33 개선

리소스 동적 변경: 실행 중인 포드의 CPU/메모리를 직접 조정 가능
다운타임 없음: 애플리케이션은 중단되지 않고 계속 동작
활용 예시
- 데이터베이스에 메모리 즉시 확장 적용
- JVM 애플리케이션 초기 구동 시 큰 메모리 할당 후 축소
- 향후 수직 오토스케일러와 결합해 자동화

주의 및 활성 방법

Deployment/StatefulSet 스펙 변경만으로는 불가능 → 반드시 Pod의 resize 서브리소스를 사용해야 한다.

kubectl edit pod –subresource resize
kubectl patch pod –subresource resize -p ‘…’

메모리 축소 위험: 현재 사용량보다 낮게 줄이면 OOM/Eviction 발생 가능. kubelet은 best-effort로 막지만 완전 보장 불가.
컨테이너 리사이즈 정책(resizePolicy)을 통해 CPU/메모리별로 재시작 필요 여부를 세분화 가능
- NotRequired: 실행 중 컨테이너 그대로 적용 (CPU 기본값)
- RestartContainer: 해당 리소스 변경 시 컨테이너 재시작 (메모리에서 흔히 필요)

Feature Gate 관리 (kube-apiserver / kubelet)
v1.27~v1.32 → 기본 비활성화 --feature-gates=InPlacePodVerticalScaling=true를 apiserver와 모든 kubelet에 추가
v1.33 → 기본 활성화 필요 시 비활성을 위해선 InPlacePodVerticalScaling=false 지정

1. /var/lib/kubelet/config.yaml에 추가
2-1. featureGates: InPlacePodVerticalScaling: true 
2-2. 또는 systemd 서비스 args에 직접 추가 --feature-gates=InPlacePodVerticalScaling=true
3. 적용 후 systemctl restart kubelet

제약

init/ephemeral 컨테이너는 불가
QoS 클래스(Guaranteed/Burstable/BestEffort)는 생성 시점에서 고정
Windows Pod는 미지원

참고

Kubernetes 공식 문서 – Resize CPU and Memory Resources assigned to Containers
KEP-1287: In-place Pod Vertical Scaling
Kubernetes v1.33 Release Blog (2025-04-23)
Tim Allclair (Google), “Kubernetes v1.33: In-Place Pod Resize Graduated to Beta”

3. OCI 이미지 볼륨 (KEP-4639) - State: Beta

기존 문제

여러 컨테이너에서 동일한 정적 데이터를 공유하려면 기존에는 아래 방법들을 사용해야 했다.

동일 데이터를 각각의 애플리케이션 이미지에 중복 포함
init 컨테이너를 통해 데이터를 복사 후 공유 디렉토리에 배치
PersistentVolume(PV) 생성하고 마운트하여 데이터 공유

이 방식은 이미지 사이즈 증가, 배포 속도 저하, 스토리지 관리 복잡성 등의 문제가 있었다.

1.33 개선

이미지 직접 마운트: OCI 이미지의 파일 시스템을 읽기 전용 볼륨으로 바로 탑재 가능
컨테이너 실행 불필요: 단순 데이터 제공만 할 경우 컨테이너 실행이 필요 없음
멀티 컨테이너 공유: 동일 파드 내 여러 컨테이너가 동일한 데이터 세트를 활용 가능

사례

경량 앱 유지: 애플리케이션 이미지는 최소화하고, 정적 데이터(이미지·비디오·라이브러리 등)는 별도 이미지로 관리
정적 웹 콘텐츠 제공: Nginx 같은 웹 서버에 HTML/CSS/이미지·비디오를 포함한 콘텐츠 이미지를 마운트
공통 자산 공유: 인증서, 공통 라이브러리, 머신러닝 모델 파일 등을 별도 이미지로 관리 후 공유

주의 및 활성 방법

Feature Gate: Kubelet, kube-apiserver, controller-manager, scheduler 등에 아래 플래그 추가

--feature-gates=OCIImageVolumes=true

읽기 전용 전용: 쓰기 작업에는 부적합, 데이터 변경은 새로운 이미지 빌드·배포 필요

YAML 예시

apiVersion: v1
kind: Pod
metadata:
  name: nginx-with-oci-volume
spec:
  volumes:
    - name: static-content
      image:
        reference: registry.example.com/static-assets:1.0
  containers:
    - name: nginx
      image: nginx:1.25
      volumeMounts:
        - name: static-content
          mountPath: /usr/share/nginx/html
          readOnly: true

참고

구분	PV	ConfigMap	OCI 이미지 볼륨
데이터 성격	지속적 데이터 (읽기·쓰기 가능)	경량 설정·텍스트 데이터	정적 파일/바이너리, 읽기 전용
데이터 저장 위치	외부 스토리지 (디스크, NFS, 클라우드 볼륨 등)	etcd (쿠버네티스 API 오브젝트)	OCI 레지스트리 (이미지 레이어)
읽기/쓰기 가능 여부	읽기 + 쓰기 가능	읽기 전용 (Pod 내부)	읽기 전용
Pod 종료 후 데이터 유지	유지됨 (Persistence 보장)	유지 안 됨 (ConfigMap 오브젝트가 원본)	유지 안 됨 (이미지 자체는 불변)
데이터 크기	대규모 DB, 로그 등 대용량 데이터	작은 텍스트, 설정 파일	수 MB ~ GB 단위 정적 리소스 가능
사용 목적	데이터베이스, 로그, 사용자 업로드 파일	환경 변수, 애플리케이션 설정	정적 웹 리소스, 모델 파일, 인증서 번들
버전 관리	스토리지 기반, 버전 관리 어려움	리비전 변경(쿠버네티스 리소스 수준)	이미지 태그를 통한 버전 관리 용이
활용 예시	MySQL PV, NFS 마운트	Nginx 설정 ConfigMap	Nginx + 정적 HTML 이미지
활성/구성	PVC/PV 정의 필요	ConfigMap 리소스 생성	--feature-gates=OCIImageVolumes=true (apiserver, kubelet)
장점	데이터 지속성, 쓰기 가능	관리 간단, 설정 변경 편리	이미지 기반 관리, DevOps 파이프라인과 잘 맞음
제약	스토리지 인프라 필요, 운영 복잡	대용량/바이너리 관리 부적합	읽기 전용, 쓰기 불가

4. 사용자 네임스페이스 보안 (KEP-127) - State: Beta

기존 문제

컨테이너 안에서 root(UID 0)로 실행되면 호스트에서도 root로 매핑되어, 컨테이너 탈출·취약점 악용 시 호스트 권한 상승 위험이 컸다.

1.33 개선

자동/비중복 UID/GID 할당
kubelet이 각 파드에 대해 서로 겹치지 않는 호스트 UID/GID 범위를 자동 매핑한다. (기본 0–65535 컨테이너 UID/GID ↔ 노드의 별도 범위)
루트 착각(inside root, outside non-root)
파드 내부에서 root처럼 보이지만, 호스트에서는 비-루트 UID로 매핑되어 특권 상승 위험을 낮춘다.

활용 예시

멀티테넌트 격리 강화: 서로 다른 파드 간 파일/프로세스 권한 충돌 완화
보안 민감 워크로드: 컨테이너 내부는 root로 운영하되(예: 패키지 설치), 호스트 권한은 비-루트로 제한
PSA와 병행: root 요구 애플리케이션도 사용자 네임스페이스로 실질 권한을 낮춰 운영

주의 및 활성 방법

spec.hostUsers: false를 넣으면 해당 파드에 사용자 네임스페이스가 적용된다.
설정 후, 파드 안에서는 id가 root로 보이지만 호스트에서 보면 비-루트 UID로 매핑된다.

apiVersion: v1
kind: Pod
metadata:
  name: demo-userns
spec:
  hostUsers: false     # ← 사용자 네임스페이스 “사용”
  containers:
  - name: app
    image: busybox
    command: ["sh","-c","id && sleep 3600"]

노드 전제 조건 확인(중요)

커널/파일시스템: idmapped mount 지원(예: Linux 6.3의 ext4/xfs/overlayfs 등)
OCI 런타임: runc ≥ 1.2 또는 crun ≥ 1.9
컨테이너 런타임: containerd ≥ 2.0, CRI-O ≥ 1.25
subuid/subgid에 kubelet용 범위가 충분히 구성되어 있어야 함 (예: /etc/subuid, /etc/subgid에 kubelet:65536:… 형태, 파드 수 × 65536 이상 확보)

파드별 UID/GID 블록 크기 조정(선택)

v1.33부터 KubeletConfiguration에서 userNamespaces.idsPerPod(65536 배수)로 파드당 할당 크기를 조절 가능.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
userNamespaces:
  idsPerPod: 1048576  # 65536의 배수, 기본 65536

제약

hostUsers: false와 동시에 사용 불가: hostNetwork: true, hostPID: true, hostIPC: true
Linux 전용(Windows POD 미지원)
파일 소유권은 “컨테이너 내부 관점”으로 유지 → 같은 볼륨을 사용자 네임스페이스 미적용 파드와도 공유 가능
(적절한 runAsUser/fsGroup 설정 전제)

참고

5. kubectl .kuberc 설정 (KEP-3104) - State: Alpha

기존 문제

개인별 kubectl 사용 습관(별칭, 기본 출력 형식, 기본 플래그 등)을 kubeconfig와 한 파일에 섞어 쓰면 클러스터 접근 정보와 개인 선호 설정이 뒤엉켜 관리·공유가 불편했다.

1.33 개선

사용자 선호 분리 파일 .kuberc(Alpha): 클러스터/자격증명은 kubeconfig, 개인 선호는 .kuberc에 저장.
적용 범위: 별칭(aliases)과 명령별 기본 플래그(overrides)를 선언해, 사용자가 명시하지 않아도 기본값을 자동 주입.
경로/옵션

활용 예시

팀 공통 별칭 공유(예: getn → kubectl get namespace …)
kubectl apply 기본을 Server-Side Apply로 고정
삭제 기본 대기(--wait), 기본 종료 유예(--grace-period) 등 안전한 기본값 주입

# ~/.kube/kuberc
apiVersion: kubectl.config.k8s.io/v1alpha1
kind: Preference

# 1) 별칭: 'getn' → 'kubectl get namespace ...'
aliases:
  - name: getn
    command: get
    prependArgs: [ "namespace" ]        # 하위 리소스 고정
    flags:
      - name: output
        default: json                   # -o json 기본

# 2) 명령별 기본 옵션(사용자가 CLI에서 주면 그 값이 우선)
overrides:
  - command: apply
    flags:
      - name: server-side
        default: "true"                 # SSA 기본 적용
      - name: force-conflicts
        default: "true"                 # 충돌 시 서버 쪽 병합(팀 정책에 맞춰 조절)
  - command: delete
    flags:
      - name: wait
        default: "true"                 # 삭제 완료까지 대기
      - name: grace-period
        default: "30"                   # 기본 종료 유예 30초
      - name: cascade
        default: "background"           # 종속 리소스 처리 방식

kubectl apply -f app.yaml → 내부적으로 --server-side=true --force-conflicts=true가 기본 주입
kubectl apply -f app.yaml --server-side=false → 사용자 지정이 우선(기본값 덮어씀)

주의 및 활성 방법

전제 조건

kubectl v1.33+에서 제공되는 Alpha 기능. (형식/필드가 향후 바뀔 수 있음)
서버 컴포넌트와 무관한 클라이언트 전용 기능(클러스터에 영향 없음)

활성 절차

영구 적용(쉘 프로필에 추가):

echo 'export KUBECTL_KUBERC=true' >> ~/.bashrc    # 또는 ~/.zshrc
. ~/.bashrc

동작

우선순위: 사용자가 CLI에 직접 준 값 > .kuberc 기본값 > kubectl 내장 기본값
.kuberc는 새 플래그를 만들지 않는다. kubectl이 원래 지원하는 플래그의 기본값만 바꿈

제약

버전 호환: 오래된 kubectl에선 인식 못 하거나 경고 발생 가능 → kubectl <cmd> -h로 해당 플래그 존재 여부 확인 권장
보안: .kuberc에는 자격증명/토큰을 넣지 말 것(그건 kubeconfig의 몫)

참고

KEP-3104: kubectl 사용자 선호를 클러스터 설정에서 분리
Kubernetes v1.33 릴리스 노트/블로그의 .kuberc(SIG CLI 소개)
kubectl 명령 도움말(kubectl <subcmd> -h) — 각 플래그의 실제 지원 여부 확인

중요

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

저작자표시 비영리 (새창열림)

'Kubernetes > Kubernetes 버전별 변경 이력' 카테고리의 다른 글

Kubernetes v1.35 업데이트 미리보기 (1)	2025.11.26
Kubernetes v1.34: 바람과 의지 (Of Wind & Will) 업데이트 핵심 (0)	2025.10.07
KUBERNETES 1.28 변경이력 [ 번역본 ] (1)	2024.08.07
KUBERNETES 1.29 변경이력 [ 번역본 ] (1)	2024.08.07
KUBERNETES 1.30 변경이력 [ 번역본 ] (2)	2024.08.07