회의론자의 Kubernetes 첫 탐색 (2024)

K8s가 문자열 보간으로 돌아간다는 사실을 발견하는 대목이 특히 좋았음. 그 느낌은 사라지지 않으며, nindent를 만질 때마다 정신력이 조금씩 깎임.

조금 옆길로 새지만, 소프트웨어 인프라 관리 문화는 참 이상함. 더 나은 방법이 많을 텐데도 업계의 다른 영역에서 배운 교훈이 이쪽에는 충분히 퍼지지 않아, 주류 인프라 관리 관행과 비교하면 은행조차 영리하고 혁신적으로 보임.
버전이 있는 소프트웨어 패키지와 설정의 계층 구조를 셸 스크립트와 YAML로 기술하거나, Git의 텍스트 파일을 데이터베이스로 쓰거나, 제대로 된 서비스 대신 CI를 쓰면 오류가 나기 쉬움. 간단한 작업 하나를 하려고 매번 세상을 처음부터 만들어야 하는 셈임.
다른 영역에서는 타입, 프로그래밍 언어, 관계형 데이터베이스, 그래프를 널리 활용하지만 인프라에는 충분히 스며들지 못함. 타입의 가치는 소프트웨어와 데이터베이스를 만들며 피땀 흘려 배운 교훈임. 기본적인 SQL 데이터베이스를 쓰는 평범한 CRUD 애플리케이션만으로도 이런 누더기 시스템을 안전성, 속도, 확장성에서 압도할 수 있음.

하필 Go의 문자열 보간이라 더 골치 아픔. Helm이 YAML을 메모리상의 트리로 다뤄서 공백을 신경 쓰지 않게 만들지 않은 이유를 모르겠음.

문자열 보간을 하는 Helm보다는 kustomize를 쓰는 편을 확실히 선호함.

YAML 대신 JSON을 써도 됨. 하지만 훨씬 보기 흉해서 아무도 그렇게 하지 않음. 프로그램이 못생겨지는 건 싫으니 정신적 평온도 포기해야 하는 걸까?

Helm의 텍스트 보간을 싫어하는 이유를 길게 쓴 적이 있음. 간단한 설정 언어로 이 문제를 풀려는 Apple의 Pkl과 CNCF의 KCL도 실험해 봄.
둘 다 아직 널리 쓰이지는 않는 듯하지만, 얼마 전 Apple이 내부에서 Pkl을 쓴다는 이야기는 들었음.

LLM이 YAML 렌더링의 간접 참조 세 겹을 추적해 실제 버그를 찾아주는 데 놀라울 정도로 능숙해서 고마움. 원칙론자라면 이런 시스템에 질겁하겠지만, 실용적으로 보면 유지보수의 큰 골칫거리였던 복잡한 템플릿 작업이 훨씬 덜 부담스러워짐.
Helm의 텍스트 보간 자체는 그리 거슬리지 않음. 정말 골치 아파지는 건 외부 시스템이 Helm에 넘길 텍스트를 생성하고, 그 결과를 다시 Kustomize로 처리할 때임. 클러스터에 도착하기까지 YAML 렌더링 파이프라인을 3~4개나 거칠 수 있으니 제정신이 아닌 구조임.
HashiCorp도 비슷한 설정 언어를 구상해 HCL이라고 이름 붙였음. 결과는 다들 알지만, 접근법 자체보다는 설계가 미심쩍었던 탓일 수도 있음.

그래서 외부에서 제공하는 차트를 제외하면, 가능한 한 kubecfg를 통한 jsonnet만 사용함. 문자열 보간은 생태계의 골칫거리이며, 특히 YAML이 원래 디버깅 보조 도구에 불과했다는 점을 생각하면 더 그럼.

노드 쪽에 해당하는 도구는 KEDA이며, 비용 효율적인 클라우드 환경을 구축하는 데도 아주 유용함.

클러스터 상태가 불안정한지 묻는 건 각자가 생각하는 안정성의 정의에 달려 있어 답하기 어려울 수 있음.
예를 들어 파드가 며칠에 한 번씩 OOM으로 죽는 클러스터도 불안정하다고 볼 수 있음. 이는 클러스터보다는 워크로드의 버그지만, 제어 루프가 파드를 재시작하거나 퇴거 후 다시 생성하므로 장애를 복구한다는 의미에서는 제 역할을 함. 물론 모니터링으로 잡아야 하며, 파드 실패를 감시하면 OOM뿐 아니라 다른 원인의 종료도 포착할 수 있음.
실제로는 제어 루프가 막히는 경우가 더 골치 아팠음. 거의 언제나 불가능한 상태를 요구해서 발생하지만, 각 구성 요소는 “해결 불가” 이상의 정보를 주기 어려울 때가 있음. 왜 해결할 수 없는지는 대개 사람이 추론해야 함.

큰 시스템은 기껏해야 준안정 상태(metastable) 에 있다고 표현하면 적절함.

Helm만 아닌 다른 도구를 쓰면 K8s를 다루는 삶이 100배는 나아짐.

Helm은 단순하게 유지하면 훌륭한 도구임. 직장에서는 차트의 95%를 하드코딩한 YAML 템플릿으로 두고, 개발·테스트·운영 환경마다 다른 값에만 가끔 Helm 변수를 사용함.
아주 잘 작동하고, 이 용도에서는 Kustomize보다 훨씬 쉬움. 다만 공개 저장소에서 흔히 보는 초복잡한 Helm 차트는 절대 유지보수하고 싶지 않음.

K8s를 처음 쓸 때는 훨씬 복잡할 줄 알았는데 의외로 괜찮아서 기분 좋게 놀랐음. 그러다가 주변 생태계의 복잡성을 보고 크게 충격받음.

K8s는 인프라 분야의 다른 기술들처럼 원하는 상태로 수렴시키는 조정 엔진임. 이를 구동하는 YAML, JSON, 타입 부재, 템플릿 계층을 싫어한다고 핵심 가치를 부정하는 건 SQL이나 ORM이 마음에 안 든다는 이유로 데이터베이스를 싫어하는 것과 비슷함. CSV 텍스트 파일로 돌아가기 전에 다른 계층을 고려할 만함. tofu와 HCL로 Kubernetes를 구동하거나, 오퍼레이터나 이벤트 중심으로 구성하거나, 여러 SDK와 CDK를 활용할 수 있음. 문제에 맞는 개념이 FaaS나 오케스트레이션이라면 완전히 다른 계층을 얹어도 됨. 그 모든 것이 K8s 위에서 돌아간다는 게 핵심임.

컨트롤러 패턴이 있는데 왜 클라우드 네이티브 아키텍처를 지원하지 않느냐면, 직접 구현하도록 되어 있기 때문임.
스토리지와 네트워크 구현은 외부에 두면서 클라우드 제공업체는 왜 명시적으로 지원하느냐면, 처음에는 코드가 본체에 들어 있었고 수년에 걸쳐 조금씩 분리하고 있기 때문임.

본체에 통합된 구현은 유지보수와 CI 측면에서 재앙임. OpenStack은 이를 내부에 유지했는데, 프로젝트에는 코드 검토 비용이, 공급업체에는 CI 운영 의무가 크게 부담됨. 검토자 부족으로 진행 속도도 극도로 느려짐.