K8S 도입 전에 '진짜' 알아두어야 할 것

Kubernetes를 처음 검토할 때는 보통 장점부터 눈에 들어온다.

자동 복구, 오토스케일링, 롤링 업데이트, 서비스 디스커버리, 선언형 배포 같은 기능은 분명 매력적이다. 컨테이너 기반으로 여러 서비스를 운영한다면 Kubernetes가 사실상 표준처럼 느껴지기도 한다.

그런데 실제로 도입을 검토하다 보면 기능보다 먼저 알아두어야 할 부분이 있다.

K8S를 도입한다는 것은 애플리케이션뿐 아니라 K8S라는 플랫폼 자체도 계속 운영한다는 뜻이다.

 

설치하고 서비스를 올리는 것보다, 그 이후 몇 년간 어떻게 유지할 것인지가 더 중요할 수 있다.

---

1. Kubernetes는 한 번 설치하고 오래 쓰는 제품이 아니다

기존 서버 소프트웨어는 특정 버전을 설치한 뒤 몇 년 동안 유지하는 경우가 많다.

Kubernetes는 조금 다르다.

매년 여러 개의 minor version이 나오고 각 버전의 지원 기간도 비교적 짧다. 따라서 몇 년 동안 같은 버전을 유지하는 방식으로 운영하기 어렵다.

결국 이런 과정이 계속 반복된다.

1.34
 ↓
1.35
 ↓
1.36
 ↓
1.37

즉 Kubernetes에서는 버전 업그레이드가 특별한 이벤트가 아니라 정기적인 운영 업무에 가깝다.

Managed Kubernetes인 EKS를 사용한다고 해도 이 부분이 완전히 없어지지는 않는다.

AWS가 Control Plane 운영을 맡아주기는 하지만 Kubernetes 버전, Node Group, Node AMI, CNI, CoreDNS, kube-proxy 같은 부분은 여전히 신경 써야 한다.

EKS를 쓴다
≠
K8S 운영을 안 해도 된다

정도로 이해하는 것이 맞다.

---

2. 그런데 K8S는 왜 이렇게 운영할까?

처음 이 내용을 보면 이런 의문이 든다.

왜 Kubernetes는 Ubuntu LTS처럼 하나의 버전을 몇 년 동안 오래 지원하지 않을까?

 

Kubernetes가 단순한 서버 프로그램이라기보다 여러 인프라 기술 사이에 위치한 플랫폼이라는 점을 생각해보면 조금 이해하기 쉽다.

Kubernetes 주변에는 계속 변하는 기술들이 있다.

Container Runtime
Network
Storage
Cloud
Linux
Security
Observability

이 기술들이 변하면 Kubernetes도 그에 맞춰 API와 내부 구조를 계속 바꿔야 한다.

오래된 기능과 API를 계속 유지하면 사용자 입장에서는 편하지만, Kubernetes 내부에는 계속 이전 방식이 쌓이게 된다.

그래서 Kubernetes는 대체로 다음과 같은 방식을 취한다.

새로운 기능 제공
 ↓
기존 방식 Deprecated
 ↓
일정 기간 호환
 ↓
오래된 기능 제거

기존 기능을 무한정 유지하기보다는 일정 기간 전환 기회를 주고 이후에는 정리하는 방식이다.

덕분에 Kubernetes 자체는 빠르게 발전할 수 있지만, 반대로 사용하는 쪽에서도 그 변화에 계속 따라가야 한다.

기업 입장에서는 조금 불편한 부분이다.

애플리케이션은 안정적으로 몇 년씩 운영하고 싶은데, 그 아래 플랫폼은 계속 움직이기 때문이다.

결국 Kubernetes에서는 변화를 피하는 것보다 작은 변화를 계속 받아들이는 운영 방식이 중요해진다.

---

3. 버전만 올리면 끝나는 것도 아니다

처음에는 Kubernetes 버전만 올리면 되는 것으로 생각하기 쉽다. 실제로는 그 주변에 있는 컴포넌트의 호환성을 같이 확인해야 한다. 예를 들어 다음과 같은 것들이다.

Kubernetes Control Plane
        ↓
Worker Node / Node AMI
        ↓
CNI
CoreDNS
kube-proxy
        ↓
Ingress Controller
CSI Driver
        ↓
Helm Chart
Operator
CRD
Admission Controller
        ↓
Application

새로운 Kubernetes 버전에서 기존 API가 deprecated되거나 제거될 수도 있고, 사용하고 있는 Helm Chart나 Operator가 해당 버전을 아직 지원하지 않을 수도 있다.

그래서 Kubernetes 업그레이드는 단순히

1.34 → 1.35

숫자 하나를 바꾸는 작업이라기보다 플랫폼 전체의 호환성을 확인하는 작업에 가깝다.

---

4. 업그레이드를 미루면 나중에 더 힘들어진다

그러면 귀찮으니 최대한 오래 버티다가 한 번에 올리는 것이 나을까? 보통은 반대다.

오래된 버전을 계속 유지하면 여러 단계의 변경 사항이 한꺼번에 쌓인다.

예를 들어 1.31을 오래 사용하다가 최신 버전까지 따라가야 한다면 다음과 같은 작업이 될 수 있다.

1.31
 ↓
1.32
 ↓
1.33
 ↓
1.34
 ↓
1.35

그 사이에 API가 사라지고, Helm Chart가 바뀌고, Node OS가 바뀌고, Add-on 요구사항까지 변경되면 업그레이드 작업의 범위가 훨씬 커진다. 그래서 Kubernetes는 몇 년에 한 번 큰 업그레이드를 하는 것보다 지원 기간 안에서 조금씩 계속 따라가는 편이 오히려 안전하다.

---

5. Managed Kubernetes도 운영 부담이 사라지는 것은 아니다

AWS EKS, Azure AKS, Google GKE 같은 Managed Kubernetes를 사용하면 직접 Kubernetes Cluster를 구성하는 것에 비해 운영 부담이 크게 줄어든다. 특히 Control Plane을 직접 관리하지 않아도 되는 것은 큰 장점이다.

하지만 Managed Kubernetes가

Kubernetes 운영을 하지 않아도 된다

 

는 뜻은 아니다.

예를 들어 EKS를 사용하더라도 다음과 같은 영역은 계속 관리 대상이 된다.

Kubernetes Version
Managed Node Group
Node AMI
VPC CNI
CoreDNS
kube-proxy
Ingress Controller
CSI Driver
Helm Chart
CRD
Operator

Managed Kubernetes는 Kubernetes 운영을 없애주는 서비스라기보다, 운영 영역 일부를 클라우드 사업자가 대신 담당해주는 서비스에 가깝다고 생각한다.

---

6. Kubernetes를 도입하면 플랫폼이 하나 더 생긴다

개인적으로 Kubernetes의 숨은 비용은 클라우드 비용보다 이 부분이 더 크다고 생각한다.

예를 들어 운영하려는 서비스가 다음과 같다고 하자.

Agent API
MCP Server
LLM Gateway
Redis
PostgreSQL
Observability

Kubernetes 없이 운영한다면 주로 애플리케이션과 AWS 인프라를 관리하면 된다.

그런데 Kubernetes를 도입하면 새로운 관리 영역이 생긴다.

Application
AWS Infrastructure

+

Kubernetes
Helm
Ingress
CNI
CSI
CRD
Operator
Node Group
RBAC
Namespace
Resource Limit
Autoscaling
Pod Scheduling

Kubernetes가 애플리케이션 운영을 편하게 해주는 것은 맞다. 하지만 동시에 Kubernetes라는 또 하나의 플랫폼을 운영하는 일도 생긴다. 이 비용은 단순히 서버 비용으로 계산하기 어렵다. 이를 운영하고 문제를 분석할 사람과 경험도 필요하기 때문이다.

---

7. 장애 분석 범위도 넓어진다

Kubernetes가 정상적으로 동작하면 상당히 편리하다. Pod가 죽으면 다시 띄워주고, Node에 문제가 발생하면 다른 Node에서 서비스를 실행할 수도 있다. 하지만 문제가 발생했을 때는 원인 후보가 많아진다.

예를 들어 단순히

Pod가 안 뜬다.

라는 문제가 생겼다고 해도 확인해야 할 것은 많다.

Application 문제?
Container Image 문제?
Resource 부족?
Node 문제?
Scheduler 문제?
CNI 문제?
DNS 문제?
Volume 문제?
IAM 문제?
Ingress 문제?
Admission Controller 문제?

결국 Kubernetes를 사용하려면 YAML을 작성하고 kubectl apply를 할 수 있는 것만으로는 부족하다. 장애가 발생했을 때 어느 계층에 문제가 있는지를 추적할 수 있는 운영 역량도 필요하다.

---

8. 컨테이너를 쓴다고 Kubernetes가 필요한 것은 아니다

Kubernetes를 검토할 때 가장 조심해야 하는 판단 중 하나가 이것이라고 생각한다.

우리는 컨테이너를 사용하니까 Kubernetes로 가자.

 

컨테이너와 Kubernetes는 같은 이야기가 아니다.

서비스가 몇 개 안 되고 트래픽도 예측 가능하다면 다음과 같은 구조가 훨씬 단순할 수도 있다.

ALB
 ↓
ECS / Fargate
 ↓
Application Container

반대로 서비스가 계속 늘어나고 여러 팀이 독립적으로 개발하고 배포하기 시작하면 Kubernetes의 장점이 커진다.

예를 들면 이런 환경이다.

• 서비스 수가 많다.
• 서비스별 배포 주기가 다르다.
• 여러 개발팀이 하나의 플랫폼을 사용한다.
• 리소스 관리가 복잡하다.
• 다양한 워크로드를 운영해야 한다.
• 배포 전략과 트래픽 제어가 복잡하다.
• 회사 차원의 공통 플랫폼이 필요하다.

이 정도 규모가 되면 Kubernetes가 제공하는 표준화와 자동화의 가치가 확실히 커진다.

그래서 중요한 질문은

Kubernetes로 할 수 있는가?

 

가 아니다.

대부분의 서비스는 Kubernetes로 만들 수 있다.

더 중요한 질문은

우리 규모에서 Kubernetes까지 운영할 필요가 있는가?

 

이다.

---

9. 그렇다면 K8S 운영은 어떻게 해야 할까?

Kubernetes를 쓰기로 했다면 버전 업그레이드를 이벤트성 작업으로 두지 않는 것이 중요하다.

처음부터 정기적인 운영 프로세스에 넣는 편이 좋다.

예를 들어 다음과 같은 흐름이다.

1. 현재 Kubernetes 버전과 지원 종료 시점 확인

2. 다음 버전 Release Note 확인

3. Deprecated API 확인

4. CNI / CSI / Ingress / Helm / Operator
   호환성 확인

5. 개발 환경 Upgrade

6. 주요 기능 및 배포 테스트

7. Staging 환경 Upgrade

8. Production Control Plane Upgrade

9. Node Group Rolling Update

10. Add-on Upgrade

11. 모니터링 및 이상 여부 확인

12. 이전 Node 제거

중요한 것은 Production Cluster에서 바로 시도하지 않는 것이다.

Development
    ↓
Staging
    ↓
Production

순서로 먼저 검증할 환경이 필요하다.

가능하다면 몇 가지 작업은 CI/CD와 운영 도구에 넣어 자동화하는 것이 좋다.

예를 들어 다음과 같은 것들이다.

Deprecated API 검사
K8S / Add-on 버전 확인
Helm Chart 검증
배포 후 Smoke Test
Node Rolling Update
기본 Health Check
Monitoring

결국 Kubernetes 운영에서 중요한 것은 업그레이드 경험이 많은 특정 사람 한 명에게 의존하는 것이 아니다.

누가 수행하더라도 반복할 수 있는 업그레이드 절차를 만드는 것

 

이 더 중요하다.

---

10. 결국 도입 전에 확인해야 할 것

Kubernetes를 도입하기 전에 최소한 다음 질문에는 답할 수 있어야 한다고 생각한다.

서비스 규모

현재 서비스가 몇 개인가?
앞으로 얼마나 늘어날 것인가?

운영 조직

K8S를 누가 운영할 것인가?
장애 발생 시 누가 분석할 것인가?

Upgrade

정기적인 Upgrade를 수행할 수 있는가?
검증할 Development / Staging 환경이 있는가?

Platform Component

Ingress
CNI
CSI
Helm
Operator
Observability

이런 컴포넌트는 누가 관리할 것인가?

대안

ECS
Fargate
VM
Serverless

같은 더 단순한 구조로도 요구사항을 만족할 수 있지 않은가?

---

마무리

Kubernetes는 분명 좋은 기술이다.

서비스와 조직의 규모가 커질수록 Kubernetes가 제공하는 자동화, 표준화, 배포 방식의 장점은 커진다.

다만 Kubernetes는 설치하고 끝나는 제품이 아니다.

버전 Upgrade
Node 관리
Add-on 관리
보안 Update
호환성 확인
장애 분석
Monitoring
운영 자동화

를 계속 수행해야 하는 플랫폼이다.

그리고 Kubernetes가 빠르게 변하는 것도 우연이 아니다.

Container, Network, Storage, Cloud 같은 주변 기술의 변화를 받아들이면서 오래된 API와 구조를 지속적으로 정리하는 것이 Kubernetes 생태계가 발전해온 방식이기 때문이다.

결국 Kubernetes를 잘 운영한다는 것은 특정 버전을 오래 유지하는 것이 아니라,

계속 변하는 플랫폼을 안전하게 따라갈 수 있는 프로세스를 갖추는 것

 

에 더 가깝다.

그래서 Kubernetes 도입을 결정할 때는

"Kubernetes가 좋은 기술인가?"

 

보다 먼저

"우리 조직은 앞으로 몇 년 동안 K8S라는 플랫폼을 계속 운영할 준비가 되어 있는가?"

 

를 물어봐야 하지 않을까 싶다.