내가 Self‑Healing Kubernetes 플랫폼을 만든 방법 (On‑Call을 35% 줄임)

Source: Dev.to

대부분의 쿠버네티스 클러스터가 여전히 인간에 의존하는 이유

많은 팀에서 쿠버네티스는 자동화된 것처럼 보이지만, 노드가 포화 상태가 되면 현실이 드러납니다:

• 새벽 2시에 페이지가 울림
• 그들은 클러스터에 SSH 혹은 kubectl 접속
• 노드에 코든 적용
• 워크로드를 드레인
• 자동 스케일링이나 Karpenter가 올바르게 교체해 주길 기대

이 수동 루프는 트래픽이 많은 환경에서 한 달에 수십 번 반복됩니다.

팀과 작업할 때 저는 보통 이렇게 묻습니다:

왜 인간이 아직도 결정적인 인프라 작업을 하고 있나요?

이 질문이 쿠버네티스 오퍼레이터, Prometheus 인텔리전스, Karpenter를 활용한 자체 치유 노드 복구 플랫폼을 만들게 했습니다.

플랫폼 엔지니어링 접근법 (단순 DevOps 스크립트가 아님)

알림을 쉘 스크립트에 연결하는 대신, 이를 플랫폼 문제로 접근했습니다:

• 시스템은 상태를 유지해야 함
• 가드레일을 강제해야 함
• 감사 가능해야 함
• 쿠버네티스 기본 요소와 깔끔하게 통합돼야 함

그래서 해결책을 크론 잡이나 웹훅이 아닌 쿠버네티스 오퍼레이터로 구현했습니다.

플랫폼이 하는 일

플랫폼은 kubelet 상태만이 아니라 실제 노드 건강을 지속적으로 평가합니다.

사용되는 신호

• 시간에 따른 CPU 포화
• 메모리 압박
• 디스크 고갈
• 파드 퇴거 폭풍

모든 신호는 Prometheus 메트릭에서 나오며, 이는 노드 상태만으로는 얻을 수 없는 풍부한 컨텍스트를 제공합니다.

아키텍처 개요

flowchart TD
    Prometheus --> Alertmanager --> NodeRemediationOperator
    NodeRemediationOperator -->|cordon node| Node
    NodeRemediationOperator -->|drain workloads safely| Node
    NodeRemediationOperator -->|delete node| Node
    NodeRemediationOperator -->|Karpenter provisions replacement| Karpenter

왜 자동화 스크립트가 아니라 오퍼레이터인가

오퍼레이터가 제공하는 장점:

• 속도 제한된 복구(연쇄 실패 방지)
• 작업 간 쿨다운 윈도우
• CRD를 통한 정책 기반 동작
• 선언형 안전 제어
• 클러스터 내부에서의 상태 가시성

모두 쿠버네티스 네이티브이며 관찰 가능함.

안전 우선: 프로덕션 가드레일

안전 장치 없이 자동 복구는 혼돈 엔지니어링에 불과합니다. 플랫폼은 다음을 강제합니다:

• 시간당 최대 복구 횟수
• 필수 쿨다운
• PodDisruptionBudget 인식
• 라벨 기반 옵트인 (remediable=true)
• 신규 클러스터를 위한 드라이런 모드

이를 통해 팀은 자동화를 두려워하지 않고 신뢰할 수 있습니다.

노드가 포화될 때 일어나는 일

1. Prometheus가 지속적인 포화를 감지
2. Alertmanager가 오퍼레이터에 알림
3. 오퍼레이터가 정책과 쿨다운을 검증
4. 노드에 코든 적용
5. 워크로드를 안전하게 드레인
6. 노드 삭제
7. Karpenter가 새로운 용량을 프로비저닝

SSH도, 런북도, 인간도 필요 없습니다.

측정 가능한 비즈니스 영향

이는 엔지니어를 더 늘려서 달성한 것이 아니라, 더 나은 플랫폼을 구축해서 얻은 결과입니다.

엔지니어링 팀에게 왜 중요한가

이 패턴은 다음 환경에 걸쳐 확장됩니다:

• EKS, GKE, AKS
• 무상태 및 상태 저장 워크로드
• 규제 및 고가용성 환경

팀을 반응형 운영에서 의도 기반 인프라로 전환시킵니다.

더 큰 플랫폼에 어떻게 녹아드는가

오퍼레이터는 보통 다음과 함께 배포됩니다:

• GitOps 파이프라인 (ArgoCD / Flux)
• Terraform 기반 클러스터 프로비저닝
• SLO 기반 알림
• 개발자 셀프 서비스 템플릿
• 비용 인식 자동 스케일링

이 모두가 합쳐져 툴 모음이 아닌 자체 서비스형 내부 플랫폼을 형성합니다.

클러스터에 이런 것이 필요하신가요?

팀이 다음에 해당한다면:

• 대규모 쿠버네티스를 운영 중
• 아직도 노드 문제를 수동으로 처리하고 있음
• 페이지 수를 줄이고 신뢰성을 높이고 싶음

저는 오퍼레이터부터 내부 개발자 플랫폼까지 프로덕션 급 플랫폼 자동화를 설계·구현하는 데 도움을 드립니다.

논의하고 싶다면 연락 주세요:

• 쿠버네티스 오퍼레이터
• EKS 플랫폼 아키텍처
• 자동 복구 & 자체 치유 시스템
• 플랫폼 엔지니어링 모범 사례

aws #kubernetes #platform-engineering #devops #karpenter

자동화는 인간의 스트레스를 줄여야 합니다 — 늘리는 것이 아니라. 🚀