2024년 8월 23일(금) 주간 개발트렌드

![image](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/2a3741f8-626e-4237-b985-d52de10bb444_thumbnail_1.png)

## Cloud / DevOps — Kubernetes 1.31 출시

Kubernetes가 **8월 13일 Kubernetes 1.31 `Elli`**를 정식 출시했습니다.

이번 버전에는 총 **45개의 Enhancement**가 포함됐으며 단계별로는 다음과 같이 구성됐습니다.

- Stable: 11개
- Beta: 22개
- Alpha: 12개

Kubernetes는 여전히 새로운 기능을 추가하고 있었지만, 동시에 기존 기능을 Stable 단계로 끌어올리고 API와 운영 체계를 정리하면서 **성숙한 Infrastructure Platform으로 안정화되는 흐름**을 보여주고 있었습니다.

---

### Kubernetes 기능의 Lifecycle

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

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

각 단계는 단순한 버전 번호가 아니라 해당 기능을 Production에서 얼마나 안정적으로 사용할 수 있는지를 나타냅니다.

```text
Alpha

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


Beta

기능이 어느 정도 안정화
기본 활성화될 수도 있음
API 변경 가능성 존재


Stable

Production 사용을 위한 안정 단계
장기적인 호환성을 고려
```

Kubernetes 1.31에서 11개의 Enhancement가 Stable 단계에 도달했다는 것은 새로운 기능의 추가뿐 아니라 **기존 기능을 운영 환경에서 안정적으로 사용할 수 있도록 다듬는 작업이 계속되고 있었다는 의미**입니다.

---

### 왜 중요한가

Kubernetes 초기에는 새로운 Container Orchestration 기능이 빠르게 추가되는 것이 중요했습니다.

```text
초기 Kubernetes

새로운 기능
    ↓
새로운 Controller
    ↓
새로운 API
    ↓
빠른 Platform 확장
```

하지만 Kubernetes가 기업 Infrastructure의 핵심 Platform으로 자리 잡으면서 상황이 달라졌습니다.

```text
성숙한 Kubernetes

Feature
+
Stability
+
Compatibility
+
Upgrade Strategy
```

Production 환경에서는 새로운 기능 하나를 추가하는 것보다 **기존 Cluster를 문제없이 업그레이드하고 Application을 계속 운영할 수 있는가**가 더 중요합니다.

---

### Cluster Upgrade가 중요한 이유

Kubernetes Cluster는 한번 구축하고 계속 같은 버전을 사용하는 Infrastructure가 아닙니다.

새로운 Kubernetes Version으로 지속적으로 Upgrade해야 합니다.

```text
Kubernetes 1.29
      ↓
Kubernetes 1.30
      ↓
Kubernetes 1.31
```

하지만 Cluster Upgrade는 단순히 Kubernetes Version만 변경하는 작업이 아닙니다.

Cluster 내부에는 다양한 Component가 연결돼 있습니다.

```text
Kubernetes Cluster

├─ API Server
├─ Controller
├─ Scheduler
├─ CNI
├─ CSI
├─ Ingress Controller
├─ Operator
├─ CRD
└─ Application
```

따라서 Kubernetes Version이 올라가면 각 Component가 새로운 Version에서도 정상적으로 동작하는지 확인해야 합니다.

---

### API Deprecation

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

Kubernetes Resource의 API Version은 시간이 지나면서 변경될 수 있습니다.

```yaml
apiVersion: example/v1beta1
```

이 API가 Deprecated 된 이후 제거되면 기존 Manifest가 새로운 Cluster에서 동작하지 않을 수 있습니다.

```text
Old Kubernetes

v1beta1
   ↓
사용 가능


New Kubernetes

v1beta1
   ↓
Removed
   ↓
Deployment 실패
```

따라서 Cluster Upgrade 전에 기존 Manifest와 Helm Chart가 어떤 API Version을 사용하고 있는지 확인하는 작업이 중요합니다.

---

### Controller Compatibility

Kubernetes Cluster에는 Core Component 외에도 다양한 Controller가 존재합니다.

예를 들어 다음과 같은 것들입니다.

```text
Kubernetes

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

Cluster Version을 Upgrade한다고 해서 이러한 Component들이 자동으로 호환되는 것은 아닙니다.

따라서 Upgrade 전에 다음 구조를 확인해야 합니다.

```text
Kubernetes Version
        ↓
Controller Version
        ↓
Compatibility 확인
```

특히 Ingress Controller, CNI, CSI처럼 Cluster Networking이나 Storage에 직접 연결되는 Component는 호환성 문제가 발생하면 서비스 전체에 영향을 줄 수 있습니다.

---

### CRD Compatibility

Kubernetes에서는 CRD(Custom Resource Definition)를 이용해 새로운 Resource Type을 추가할 수 있습니다.

```text
Kubernetes 기본 Resource

Pod
Deployment
Service

        +

Custom Resource

Certificate
Application
ServiceMonitor
etc.
```

Operator나 Kubernetes 기반 Platform을 많이 사용하는 환경에서는 CRD가 Cluster 내부에 상당히 많아질 수 있습니다.

문제는 Kubernetes Version이나 Operator Version이 변경되면서 **CRD Schema와 API Version도 변경될 수 있다는 점**입니다.

```text
Cluster Upgrade
      ↓
Operator Upgrade
      ↓
CRD 변경
      ↓
Custom Resource 호환성 확인
```

따라서 Production Cluster에서는 Kubernetes 자체뿐 아니라 **Cluster 위에서 동작하는 Extension 생태계 전체를 함께 관리해야 합니다.**

---

### DevOps 관점에서의 변화

Kubernetes 운영의 핵심은 점점 새로운 기능을 얼마나 많이 알고 있느냐보다 **Cluster Lifecycle을 얼마나 안정적으로 관리하느냐**에 가까워지고 있습니다.

```text
Kubernetes Operations

├─ Cluster Upgrade
├─ API Deprecation
├─ Controller Compatibility
├─ CRD Compatibility
├─ Helm Chart Compatibility
├─ CNI / CSI Compatibility
└─ Application Validation
```

즉 Kubernetes가 성숙할수록 DevOps와 Platform Engineer에게 요구되는 역할도 달라집니다.

단순히

```text
kubectl apply
```

로 Application을 배포하는 것에서 끝나는 것이 아니라 Infrastructure 전체의 Compatibility를 관리해야 합니다.

---

### Production 환경의 Upgrade 흐름

실제 운영 환경에서는 Kubernetes Version을 바로 올리는 것보다 단계적으로 검증하는 것이 중요합니다.

```text
Release Note 확인
      ↓
Deprecated API 확인
      ↓
Controller Compatibility 확인
      ↓
CRD / Helm Chart 확인
      ↓
Development Cluster Upgrade
      ↓
Staging 검증
      ↓
Production Upgrade
```

특히 다음 항목들을 사전에 확인할 필요가 있습니다.

- Kubernetes Release Note
- Deprecated / Removed API
- CNI Version
- CSI Driver Version
- Ingress Controller Version
- Operator Version
- CRD Version
- Helm Chart Compatibility
- Monitoring Stack Compatibility

---

### Application 개발자에게도 중요한 이유

Kubernetes Upgrade는 DevOps 담당자만의 문제는 아닙니다.

Application 팀에서도 Deployment, Service, Ingress, HPA 등의 Resource를 직접 관리한다면 영향을 받을 수 있습니다.

```text
Application
     ↓
Helm Chart / Manifest
     ↓
Kubernetes API
```

Kubernetes API가 변경되면 Application 배포 설정 역시 수정해야 할 수 있기 때문입니다.

GitOps 환경에서는 이러한 변화가 Repository에 직접 반영됩니다.

```text
Git Repository
      ↓
Manifest / Helm
      ↓
Argo CD
      ↓
Kubernetes
```

따라서 Kubernetes Version 관리와 Application Configuration 관리가 점점 더 밀접하게 연결됩니다.

---

### 실무 영향

Kubernetes 1.31 같은 새로운 Version이 등장했을 때 중요한 질문은 단순히

```text
어떤 새로운 기능이 추가됐는가?
```

만이 아닙니다.

운영 환경에서는 오히려 다음 질문이 더 중요할 수 있습니다.

```text
현재 Cluster에서 Upgrade 가능한가?

Deprecated API가 있는가?

CNI / CSI는 지원하는가?

Ingress Controller는 호환되는가?

Operator와 CRD는 문제없는가?

기존 Application은 정상 동작하는가?
```

결국 Kubernetes 운영은 단순한 Container 배포 기술을 넘어,

> **Cluster와 주변 생태계 전체의 Lifecycle과 Compatibility를 관리하는 Infrastructure Engineering 영역**

으로 발전하고 있습니다.

Kubernetes 1.31은 새로운 기능을 계속 추가하면서도 많은 기능을 Stable 단계로 이동시키며 **Kubernetes가 기능 확장 중심의 Platform에서 안정적인 운영 표준을 만들어가는 Platform으로 성숙하고 있음을 보여주는 Release**였습니다.

2024년 8월 16일(금) 주간 개발트렌드

독자의 메모