2025년 5월 2일(금) 주간 개발트렌드

![image](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/b28d786c-9ec3-46ec-8055-adcd53a303c5_thumbnail_2.png)

## Cloud / DevOps — Kubernetes 1.33 출시

Kubernetes가 **25년 4월 23일 Kubernetes 1.33 Octarine**을 정식 출시했습니다.

이번 버전에는 총 **64개의 Enhancement**가 포함됐으며, 그중 **18개가 Stable 단계로 승격**됐습니다.

Kubernetes는 여전히 새로운 기능을 추가하고 있지만, 최근 Release의 핵심은 새로운 기능의 숫자보다 **기존 기능을 안정화하고 운영 환경에서 장기간 사용할 수 있도록 Platform을 성숙시키는 것**에 가까워지고 있습니다.

특히 Resource Management, Storage, Security, Scheduling 등 Kubernetes의 핵심 Infrastructure 영역이 지속적으로 개선되면서 Kubernetes가 새로운 Container Platform을 넘어 **Cloud-native Infrastructure의 사실상 표준 운영 Platform**으로 자리 잡았다는 흐름을 보여줬습니다.

[Kubernetes - Kubernetes v1.33: Octarine](https://kubernetes.io/blog/2025/04/23/kubernetes-v1-33-release/)

---

### Kubernetes의 Release Lifecycle

Kubernetes의 새로운 기능은 일반적으로 여러 단계를 거쳐 안정화됩니다.

```text
Alpha
  ↓
Beta
  ↓
Stable
```

각 단계는 단순한 Version 표시가 아니라 해당 기능의 성숙도를 의미합니다.

```text
Alpha

실험적인 기능
변경 가능성 높음
Production 사용 주의


Beta

기능이 어느 정도 안정화
API 변경 가능성 존재
실제 사용 사례 축적


Stable

Production 사용을 고려한 안정 단계
호환성과 장기적인 유지보수 중요
```

Kubernetes 1.33에서는 18개의 Enhancement가 Stable 단계로 이동했습니다.

이는 Kubernetes가 계속 기능을 추가하는 동시에 **기존 기능을 Production 수준으로 끌어올리는 작업에도 많은 비중을 두고 있다는 의미**입니다.

---

### 초기 Kubernetes

Kubernetes 초기에는 Container Orchestration 자체가 새로운 기술이었습니다.

당시 중요한 문제는 다음과 같았습니다.

```text
Container를 어떻게 배포할까?

Container가 죽으면 어떻게 복구할까?

Traffic은 어떻게 분산할까?

Container를 어떻게 Scale-out 할까?
```

Kubernetes는 이런 문제를 해결하기 위한 기능을 빠르게 추가했습니다.

```text
Pod

Deployment

Service

Ingress

ConfigMap

Secret

StatefulSet

DaemonSet
```

Platform 자체가 빠르게 확장되던 시기였습니다.

---

### 현재 Kubernetes

현재 Kubernetes는 이미 매우 많은 Production Infrastructure에서 사용되고 있습니다.

따라서 Platform의 우선순위도 달라집니다.

```text
초기

새로운 Feature
      ↓
Platform Capability 확대


현재

Stability
+
Compatibility
+
Security
+
Resource Management
+
Upgrade
```

새로운 기능을 추가하는 것만큼 **기존 Cluster를 안전하게 유지하고 Upgrade할 수 있는가**가 중요해진 것입니다.

---

### Kubernetes는 Infrastructure Platform이 됐다

Kubernetes를 단순한 Container Scheduler라고 보기에는 역할이 너무 커졌습니다.

```text
Kubernetes

├─ Scheduling
├─ Networking
├─ Storage
├─ Security
├─ Service Discovery
├─ Configuration
├─ Autoscaling
├─ Resource Management
└─ Extension API
```

그리고 Kubernetes 위에는 다양한 생태계가 올라옵니다.

```text
Kubernetes
   ↓
Cloud-native Ecosystem

├─ Argo CD
├─ Prometheus
├─ cert-manager
├─ Ingress Controller
├─ Service Mesh
├─ Operators
└─ Custom Resources
```

Kubernetes 자체의 Version 변경이 단순한 Package Upgrade가 아닌 이유입니다.

---

### Cluster Upgrade가 중요한 이유

Kubernetes는 일정한 Release Cycle을 가지고 지속적으로 새로운 Version을 공개합니다.

따라서 운영 Cluster도 언젠가는 Version을 올려야 합니다.

```text
Kubernetes 1.31
      ↓
Kubernetes 1.32
      ↓
Kubernetes 1.33
```

하지만 실제 Cluster에는 Kubernetes Core만 존재하지 않습니다.

```text
Cluster

├─ Kubernetes
├─ CNI
├─ CSI
├─ Ingress Controller
├─ Monitoring
├─ GitOps
├─ Operators
├─ CRD
└─ Workloads
```

Kubernetes Version을 바꾸면 이 전체 생태계의 Compatibility를 함께 확인해야 합니다.

---

### 신규 기능보다 Upgrade Strategy

Kubernetes가 성숙하면서 운영팀의 관심도 달라지고 있습니다.

초기에는 다음과 같은 질문이 중요했습니다.

```text
이번 Version에
무슨 기능이 추가됐지?
```

하지만 Production Cluster에서는 점점 다음 질문이 더 중요해집니다.

```text
현재 Version에서
안전하게 Upgrade 가능한가?

Deprecated API는 무엇인가?

삭제되는 기능은 있는가?

CNI와 CSI는 호환되는가?

Ingress Controller는 지원하는가?

Operator는 정상 동작하는가?
```

즉 관심의 중심이 Feature Adoption에서 **Lifecycle Management**로 이동합니다.

---

### API Deprecation

Kubernetes Upgrade에서 특히 중요한 것이 **API Deprecation**입니다.

Kubernetes Resource는 `apiVersion`을 사용합니다.

```yaml
apiVersion: apps/v1
kind: Deployment
```

새로운 API가 등장하면서 기존 API Version이 Deprecated될 수 있습니다.

```text
v1beta1
   ↓
Deprecated
   ↓
Removed
```

문제는 Deprecated된 API가 완전히 제거되면 기존 Manifest가 더 이상 동작하지 않을 수 있다는 점입니다.

```text
Old Cluster

v1beta1
   ↓
정상 동작


New Cluster

v1beta1
   ↓
Removed
   ↓
Deployment 실패
```

---

### Deprecated와 Removed는 다르다

Deprecated됐다고 바로 사용할 수 없는 것은 아닙니다.

```text
Deprecated

현재는 사용 가능
하지만 향후 제거 예정
```

반면 Removed 상태가 되면 실제로 사용할 수 없습니다.

```text
Removed

API Server에서 지원하지 않음
```

따라서 Kubernetes Upgrade를 준비할 때는 **현재 Deprecated된 API뿐 아니라 Target Version에서 실제 제거되는 API까지 확인해야 합니다.**

---

### Helm Chart도 확인해야 한다

Application Manifest를 직접 관리하지 않고 Helm을 사용하는 조직도 많습니다.

```text
Application
    ↓
Helm Chart
    ↓
Kubernetes Resource
```

Helm Chart 안에서도 Kubernetes API Version을 사용합니다.

따라서 Cluster Version이 올라가면 Chart Compatibility도 확인해야 합니다.

```text
Kubernetes Upgrade
       ↓
Helm Chart 확인
       ↓
Deprecated API 확인
       ↓
Chart Upgrade
```

Application Code가 바뀌지 않았더라도 Deployment Configuration 때문에 문제가 발생할 수 있습니다.

---

### CRD Compatibility

Kubernetes는 CRD(Custom Resource Definition)를 통해 Platform 기능을 확장할 수 있습니다.

```text
Kubernetes 기본 Resource

Pod
Deployment
Service

        +

Custom Resource

Application
Certificate
ServiceMonitor
etc.
```

예를 들어 Argo CD는 `Application`, Prometheus Operator는 `ServiceMonitor` 같은 Custom Resource를 사용합니다.

```text
Kubernetes
    ↓
CRD
    ↓
Custom Controller
```

Cluster Version을 Upgrade할 때는 이런 CRD와 Controller의 Compatibility도 확인해야 합니다.

---

### Controller Compatibility

Kubernetes 환경에는 수많은 Controller가 존재할 수 있습니다.

```text
Controllers

├─ Ingress Controller
├─ cert-manager
├─ Prometheus Operator
├─ Argo CD
├─ External Secrets
└─ Custom Operator
```

Kubernetes 자체가 정상적으로 Upgrade됐더라도 Controller가 새로운 Version을 지원하지 않으면 문제가 발생할 수 있습니다.

```text
Kubernetes Upgrade
       ↓
Controller Compatibility 문제
       ↓
Resource Reconciliation 실패
```

따라서 Platform Engineer는 Kubernetes뿐 아니라 주변 생태계 전체의 Version Matrix를 관리해야 합니다.

---

### CNI

CNI(Container Network Interface)는 Kubernetes Networking을 담당합니다.

대표적으로 다음과 같은 Solution이 있습니다.

```text
CNI

Calico

Cilium

Flannel

Cloud Provider CNI
```

Pod Networking은 Cluster의 핵심 기능이기 때문에 CNI 문제가 발생하면 전체 Application 통신에 영향을 줄 수 있습니다.

```text
Pod A
  ↓
Network
  ↓
Pod B
```

Cluster Upgrade 전에 CNI가 Target Kubernetes Version을 지원하는지 확인하는 것이 중요합니다.

---

### CSI

Storage 역시 마찬가지입니다.

Kubernetes에서는 CSI(Container Storage Interface)를 통해 Storage Provider와 연결합니다.

```text
Pod
 ↓
PVC
 ↓
CSI
 ↓
Storage
```

Database나 Stateful Workload가 존재한다면 CSI Compatibility 문제는 더욱 중요합니다.

```text
Database Pod
     ↓
Persistent Volume
     ↓
Storage
```

Storage 문제는 단순 Application Restart보다 훨씬 큰 장애로 이어질 수 있기 때문입니다.

---

### Resource Management

Kubernetes가 성숙하면서 Resource Management 역시 계속 발전하고 있습니다.

기본 Resource는 다음과 같습니다.

```text
CPU

Memory
```

Pod에서 요청과 제한을 정의합니다.

```yaml
resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    cpu: "1"
    memory: "1Gi"
```

Scheduler는 이 정보를 기준으로 Pod를 적절한 Node에 배치합니다.

```text
Pod Resource Request
        ↓
Scheduler
        ↓
Node 선택
```

---

### Resource 관리가 중요한 이유

Resource 설정이 잘못되면 Cluster 운영에 직접적인 문제가 생길 수 있습니다.

Requests가 너무 크면,

```text
Resource 과다 요청
      ↓
Pod Scheduling 어려움
      ↓
Cluster Resource 낭비
```

반대로 너무 작으면,

```text
Resource 부족
      ↓
CPU Throttling

또는

OOMKill
```

문제가 발생할 수 있습니다.

Kubernetes Platform이 성숙하면서 단순히 Pod를 실행하는 것보다 **Cluster Resource를 얼마나 효율적으로 활용하는가**가 중요해지고 있습니다.

---

### Storage 기능의 성숙

초기 Kubernetes는 Stateless Web Application에 특히 적합하다는 이미지가 강했습니다.

```text
Web App
 ↓
Pod
 ↓
Stateless
```

하지만 StatefulSet, Persistent Volume, CSI 등이 발전하면서 Database나 Stateful Workload도 Kubernetes에서 운영하는 사례가 증가했습니다.

```text
Kubernetes

├─ Web
├─ Backend
├─ Queue
├─ Search
└─ Stateful Workload
```

따라서 Storage의 안정성과 Lifecycle도 Kubernetes Release에서 중요한 영역이 됐습니다.

---

### Security도 Platform 기본 기능이다

Kubernetes Cluster는 수많은 Workload와 Secret, Network Resource를 관리합니다.

```text
Cluster

├─ Application
├─ Database Credential
├─ API Token
├─ Service Account
└─ Network
```

따라서 Kubernetes Security는 별도의 부가 기능이 아니라 Platform 자체의 핵심 영역입니다.

주요 개념은 다음과 같습니다.

```text
RBAC

Service Account

Pod Security

Network Policy

Secrets

Admission Control
```

Kubernetes Version이 발전하면서 Security Model 역시 지속적으로 정리되고 강화됩니다.

---

### Version Skew

Kubernetes Upgrade에서는 Control Plane과 Node Component 사이의 Version Compatibility도 고려해야 합니다.

```text
Control Plane
     ↓
kubelet
     ↓
Node
```

모든 Component를 아무 Version 조합으로 사용할 수 있는 것은 아닙니다.

따라서 Upgrade 순서와 지원되는 Version Skew를 확인해야 합니다.

```text
Control Plane Upgrade
        ↓
Node Upgrade
        ↓
Addon Upgrade
```

Managed Kubernetes라고 하더라도 이런 Lifecycle 자체가 완전히 사라지는 것은 아닙니다.

---

### Managed Kubernetes도 Upgrade가 필요하다

EKS, GKE, AKS 같은 Managed Kubernetes를 사용하면 Control Plane 관리 부담은 줄어듭니다.

```text
Cloud Provider
      ↓
Managed Control Plane
```

하지만 Application과 Add-on Compatibility까지 Cloud Provider가 자동으로 해결해주는 것은 아닙니다.

```text
Managed Kubernetes Upgrade
         ↓
Application
CNI
CSI
Ingress
CRD
Controller
```

따라서 Managed Kubernetes에서도 Upgrade Planning은 여전히 필요합니다.

---

### Production Cluster Upgrade Workflow

실제 운영 환경에서는 다음과 같은 흐름을 사용할 수 있습니다.

```text
Release Note 확인
      ↓
Deprecated / Removed API 확인
      ↓
CNI / CSI Compatibility 확인
      ↓
Controller / Operator 확인
      ↓
Helm / Manifest 확인
      ↓
Development Cluster Upgrade
      ↓
Staging 검증
      ↓
Production Upgrade
      ↓
Monitoring
```

Version 숫자만 변경하는 작업이 아니라 **전체 Platform Compatibility를 검증하는 과정**입니다.

---

### Pre-upgrade Check

Upgrade 전에 자동화된 검사 Tool을 사용할 수도 있습니다.

예를 들어 Repository에서 사용 중인 Kubernetes Resource를 분석해 Deprecated API를 탐지할 수 있습니다.

```text
Git Repository
      ↓
Manifest Scan
      ↓
Deprecated API
      ↓
Upgrade 전에 수정
```

GitOps 환경이라면 특히 효과적입니다.

```text
Git
 ↓
Manifest
 ↓
Argo CD
 ↓
Kubernetes
```

Cluster에 적용되기 전에 Configuration 단계에서 문제를 발견할 수 있기 때문입니다.

---

### GitOps와 Upgrade

GitOps 환경에서는 Infrastructure와 Application Configuration이 Git Repository에 존재합니다.

```text
Git
 ↓
Desired State
 ↓
Argo CD
 ↓
Cluster
```

Kubernetes Upgrade를 준비할 때도 Manifest와 Helm Chart를 먼저 수정할 수 있습니다.

```text
Target Version 분석
        ↓
Git 변경
        ↓
Review
        ↓
Staging
        ↓
Production
```

Cluster Lifecycle 역시 Code Review와 자동화된 Workflow 안으로 들어오는 것입니다.

---

### Rollback도 중요하다

Upgrade는 항상 성공한다는 보장이 없습니다.

```text
Upgrade
 ↓
Problem
 ↓
Rollback?
```

Kubernetes에서는 Component와 API 변화 때문에 단순 Downgrade가 항상 쉬운 것은 아닙니다.

따라서 Upgrade 전에

```text
Backup

etcd Strategy

Application Rollback

Node Rollout Strategy

Disaster Recovery
```

등을 준비해야 합니다.

---

### 신규 기능보다 운영 능력이 중요해진다

Kubernetes가 성숙하면서 기술 역량의 기준도 조금씩 달라집니다.

초기에는

```text
Deployment 만들기

Service 만들기

Ingress 만들기
```

정도를 알아도 Kubernetes를 사용할 수 있었습니다.

Production 환경에서는 훨씬 많은 것을 이해해야 합니다.

```text
Kubernetes Operations

├─ Upgrade
├─ Resource Management
├─ Networking
├─ Storage
├─ Security
├─ Observability
├─ Backup
└─ Failure Recovery
```

Kubernetes를 **사용할 줄 아는 것과 운영할 줄 아는 것은 다른 문제**가 된 것입니다.

---

### Platform Engineering과 Kubernetes

최근 Kubernetes 운영은 점점 Platform Engineering 영역으로 이동하고 있습니다.

개별 개발자가 Kubernetes Resource를 모두 직접 다루기보다 Platform Team이 공통 환경을 제공합니다.

```text
Platform Team

Kubernetes
+
CI/CD
+
GitOps
+
Observability
+
Security
+
Developer Platform
```

Application Team은 그 위에서 서비스를 배포합니다.

```text
Developer
    ↓
Internal Platform
    ↓
Kubernetes
```

Kubernetes가 Infrastructure 내부 구현으로 내려가는 방향입니다.

---

### Kubernetes가 인프라 표준이 됐다는 의미

기술이 성숙하면 사용자가 내부 구현을 덜 신경 쓰게 되는 경우가 많습니다.

```text
초기

Kubernetes 자체가 Product


성숙

Kubernetes가 Platform 기반
```

새로운 서비스를 만들 때 Kubernetes 자체를 도입하는 것이 프로젝트의 목표가 아니라,

```text
서비스를 안정적으로 운영하기 위한
Infrastructure 기반
```

으로 사용하는 것입니다.

---

### Feature Competition에서 Lifecycle Management로

Kubernetes의 변화는 다음처럼 정리할 수 있습니다.

```text
초기

새 기능
+
빠른 Platform 확장


현재

Stable Feature
+
Compatibility
+
Security
+
Upgrade
+
Operations
```

Platform이 성숙할수록 Feature 숫자보다 **운영 안정성과 Lifecycle 관리 능력**이 더 중요해집니다.

---

### 개발자에게도 영향을 준다

Cluster Upgrade는 Platform Engineer만의 문제는 아닙니다.

Application 개발자가 작성한 Manifest나 Helm Chart도 영향을 받을 수 있습니다.

```text
Application
    ↓
Deployment / Service
    ↓
Kubernetes API
```

Deprecated API를 사용하거나 오래된 Chart에 의존하고 있다면 Platform Upgrade가 막힐 수 있습니다.

따라서 Application Team도 최소한 다음 요소는 관리할 필요가 있습니다.

```text
Manifest Version

Helm Chart

Resource Requests

Health Check

Security Context
```

Infrastructure와 Application 사이의 책임이 완전히 분리되는 것은 아닙니다.

---

### 왜 중요한가

Kubernetes 1.33의 핵심 의미는 특정 Feature 하나에 있지 않습니다.

총 64개의 Enhancement가 진행되고 18개가 Stable 단계로 이동했다는 것은 Kubernetes가 계속 발전하면서도 **많은 기능을 안정적인 Production 기능으로 정착시키고 있다는 흐름**을 보여줍니다.

Kubernetes의 역할도 다음처럼 변해왔습니다.

```text
초기

Container Scheduler


이후

Container Orchestrator


현재

Cloud-native Infrastructure Platform
```

그리고 Platform이 성숙하면서 운영자의 관심도 달라졌습니다.

```text
새 기능 도입

보다

Version Policy
+
API Compatibility
+
Cluster Upgrade
```

가 더 중요해지고 있습니다.

---

### 실무 영향

Kubernetes 1.33 같은 새로운 Version이 출시됐을 때 Production 운영팀이 가장 먼저 해야 할 일은 새로운 기능을 전부 적용하는 것이 아닙니다.

다음 항목을 먼저 확인하는 것이 중요합니다.

```text
Target Kubernetes Version

        ↓

Deprecated API

Removed Feature

CNI Compatibility

CSI Compatibility

Ingress Controller

Operator / CRD

Helm Chart

Monitoring Stack
```

그리고 단계적으로 Upgrade합니다.

```text
Development
    ↓
Staging
    ↓
Production
```

결국 Kubernetes 1.33은,

> **Kubernetes가 빠르게 기능을 추가하는 초기 Container Platform에서 안정적인 Lifecycle과 Compatibility를 관리해야 하는 성숙한 Infrastructure Standard로 이동했음을 보여주는 Release**

라고 볼 수 있습니다.

Kubernetes 운영에서 중요한 역량 역시 새로운 YAML Syntax를 많이 아는 것보다 **Version Policy를 이해하고, Deprecated API를 관리하며, Cluster와 주변 Ecosystem을 안전하게 Upgrade할 수 있는 능력**으로 이동하고 있습니다.

2025년 4월 25일(금) 주간 개발트렌드

독자의 메모