쿠버네티스를 싫어하는 이들을 위한 안내서

Kubernetes에 대한 비판적 안내서

• Kubernetes는 일부 기술자들 사이에서 불필요하게 복잡하고 시간 낭비라는 평판을 얻었으며, 작은 팀에서 사용하는 것은 과잉 설계로 여겨짐.
• Jamsocket에서는 몇 년간 Kubernetes를 생산 환경에서 운영하며, 필요한 기능만 사용하고 나머지는 무시하는 방식으로 효율적인 사용법을 찾음.

Kubernetes를 사용하는 이유

• Kubernetes는 다음 세 가지를 모두 원할 때 가장 잘 다져진 길임:
  • 여러 프로세스/서버/예약된 작업을 실행하고자 할 때.
  • 이를 중복으로 실행하고 부하를 분산시키고자 할 때.
  • 코드로 이들의 설정과 상호 관계를 구성하고자 할 때.
• Kubernetes는 컴퓨터 풀을 하나의 무두(headless) 컴퓨터처럼 다룰 수 있는 추상화 계층임.
• Jamsocket은 하루에 여러 번 배포를 하며, 제품에 문제가 생기면 고객의 제품도 영향을 받으므로, 롤링 배포를 통해 자주 배포할 수 있는 자신감을 얻음.

Kubernetes 사용 방법

• Jamsocket은 웹 앱과 통신할 수 있는 동적 프로세스를 생성하는 서비스로, AWS Lambda와 유사하지만 프로세스 수명이 단일 요청/응답이 아닌 WebSocket 연결에 종속됨.
• Kubernetes는 API 서버, 컨테이너 레지스트리, 컨트롤러, 로그 수집기, 일부 DNS 서비스, 메트릭 수집 등 장기 실행 프로세스를 운영하는 데 사용됨.
• Kubernetes를 사용하지 않는 것들: 일시적 프로세스, 정적/마케팅 사이트, 직접 데이터를 저장하는 것들.
• Google Kubernetes Engine을 사용하여 Kubernetes 관리를 외부에 위임하고 있으며, 필요한 경우 Amazon EKS로의 이전이 비교적 간단함.

적극적으로 사용하는 Kubernetes 리소스

• Deployments: 대부분의 파드는 배포를 통해 생성됨.
• Services: 내부 서비스용 ClusterIP와 외부 서비스용 LoadBalancer 사용.
• CronJobs: 정리 스크립트 등을 위해 사용.
• ConfigMaps과 Secrets: 위 리소스에 데이터를 전달하기 위해 사용.

신중하게 사용하는 것들

• StatefulSet과 PersistentVolumeClaim은 사용하고 있지만, 중요한 데이터는 Kubernetes 외부의 관리 서비스에 저장하는 것을 선호함.
• RBAC은 복잡성을 추가하기 때문에 가능한 한 피함.

적극적으로 피하는 것들

• 수작업으로 YAML 작성: TypeScript와 Pulumi를 사용하여 Kubernetes 리소스 정의 생성.
• 비표준 리소스 및 오퍼레이터: 제3자 소프트웨어가 Kubernetes의 인프라를 사용할 수 있게 하지만, 실제로는 사용하기 까다로움.
• Helm: 연산자 및 YAML 규칙 때문에 사용하지 않음.
• "mesh"가 이름에 포함된 모든 것: 필요하지 않다고 판단함.
• Ingress 리소스: 불필요한 간접성을 추가하는 것을 피함.
• 전체 k8s 스택을 로컬에서 복제하기: Docker Compose나 자체 스크립트를 사용하여 필요한 시스템의 일부만 시작함.

사람이 Pod를 기다려서는 안 됨

• Kubernetes는 컨테이너 시작 시간보다 견고함과 모듈성에 중점을 두고 설계되었으며, 사람이 Pod 시작을 기다리는 경우에는 적합하지 않음.
• Jamsocket은 Plane이라는 MIT 라이선스의 Rust 오케스트레이터를 사용하여 대화형 워크로드를 위한 프로세스를 빠르게 예약하고 실행함.

상위 수준의 추상화

• Kubernetes 대안 중 일부는 매우 좋으며, 특히 인프라를 코드로 지정할 필요가 없는 경우에 유용함.
• Railway, Render, Flight Control과 같은 서비스를 사용하여 Kubernetes 대신 다른 솔루션을 선택할 수도 있음.
• Kubernetes에 대한 접근 방식을 체계적으로 관리한다면, 누구도 너무 이르다고 말할 수 없음.

GN⁺의 의견

• Kubernetes는 특히 대규모 시스템에서의 복잡성 관리와 자동화에 강력한 도구임에도 불구하고, 그 복잡성이 작은 규모의 프로젝트나 스타트업에게는 부담이 될 수 있음.
• 이 글은 Kubernetes를 사용할 때 발생할 수 있는 과도한 복잡성을 피하는 방법을 제시함으로써, 초보자나 작은 팀도 Kubernetes의 이점을 활용할 수 있도록 도움을 줌.
• Kubernetes를 사용하기 전에, 실제로 필요한 기능과 팀의 기술적 역량을 고려하여, 관리의 복잡성과 비용 대비 이점을 신중히 평가해야 함.
• Kubernetes 대신 간단하고 관리가 용이한 서비스를 사용하는 것이 더 나을 수 있음. 예를 들어, Docker Swarm, Apache Mesos, Nomad 등이 있으며, 이들은 각각의 장단점을 가지고 있음.
• Kubernetes를 도입할 때는 기존 인프라와의 통합, 보안, 관리 비용, 그리고 학습곡선 등을 고려해야 함.
• Kubernetes를 선택함으로써 얻을 수 있는 이점은 확장성, 높은 가용성, 그리고 다양한 클라우드 환경에서의 일관된 배포 경험임. 그러나 이를 위해 필요한 리소스 관리와 오케스트레이션에 대한 이해가 필요함.

[GN⁺]

Hacker News 의견

• 첫 번째 댓글 요약:

  • Kubernetes와 같은 복잡한 시스템을 도입하면, 그 복잡성이 계속 확장되어 다양한 컴포넌트가 서로를 강화하며 필수적으로 여겨지게 됨.
  • 클라우드가 처음 등장했을 때, 사람들은 로드 밸런서와 데이터베이스 관리의 복잡성을 줄이는 것에 매력을 느낌.
  • 상태가 없는(stateless) 앱 서버는 큰 유지 관리 문제가 아니었지만, 마이크로서비스를 전도함으로써 존재하지 않던 문제를 만들어냄.
  • 이제 이러한 문화가 정착되어 마이크로서비스가 필수라는 주장에 손을 흔들며 동의하기 어려워짐.

• 두 번째 댓글 요약:

  • 중소기업에 Kubernetes를 도입하는 사람으로서, 불만을 가진 엔지니어들이 있었지만 대부분은 만족한다고 응답함.
  • Kubernetes는 복잡하지만, 복잡한 문제에 맞는 도구임.
  • 표준을 갖는 것은 문서화되지 않은 간단한 혼돈보다 낫고, "kubectl explain X"는 AWS 문서보다 훨씬 낫다고 주장함.
  • Kubernetes가 복잡하긴 하지만, 개발자들이 이전 직장에서 사용했던 방식과 동일하게 작동하며, 속도가 중요함.

• 세 번째 댓글 요약:

  • Kubernetes에 대한 비판이 유행이지만, 여전히 최고의 솔루션임.
  • 인프라를 선언적으로 정의하고, 로드 밸런싱, 자동 복구 및 스케일링을 제공함.
  • 전체 스택에 대한 훌륭한 관찰 가능성을 제공하고, 많은 사전 패키지 소프트웨어를 사용할 수 있음.
  • 클라우드, 자체 서버, 로컬 환경에서 거의 동일한 인프라를 구축할 수 있어 특정 클라우드 제공업체에 종속되지 않음.

• 네 번째 댓글 요약:

  • Kubernetes의 큰 이점은 Helm이나 Operators임.
  • 복잡성 비용을 지불하는 경우, 인프라 컴포넌트의 '앱 스토어'와 운영을 프로그래밍 방식으로 관리할 수 있는 이점을 얻어야 함.
  • 예를 들어 Ceph와 같은 복잡한 것을 설정하려면 Rook이 좋은 방법임.
  • Helm이나 Operators는 인프라를 관리형 '턴키' 어플라이언스로 만들지 않지만, 선언적 인터페이스는 일반적으로 관리하기 더 좋음.

• 다섯 번째 댓글 요약:

  • Kubernetes는 좋은 기술이지만, 복잡성 때문에 유지 관리자들이 회사의 영웅이 되는 경향이 있음.
  • 많은 조정 사항과 레버가 프로젝트의 실제 목표에서 벗어나게 만들 수 있음.

• 여섯 번째 댓글 요약:

  • 현재 회사는 Kubernetes와 Ansible 기반의 맞춤형 배포 시스템으로 나뉨.
  • Ansible 방식은 잘 작동하지만, Kubernetes로 이전하면 배포 시간을 몇 시간에서 몇 분으로 단축시키고, 더 빠르고 효율적으로 자동 스케일링할 수 있음.
  • Helm 배포 실패 원인 파악의 어려움과 새로운 운영 방식 학습 필요성 등이 이전 팀들로부터 들은 일관된 피드백임.

• 일곱 번째 댓글 요약:

  • 전 구글 사이트 신뢰성 엔지니어와의 대화에서, 실제로 Kubernetes가 필요한 회사는 손에 꼽힌다고 함.
  • 많은 사람들이 유행을 따라 개발하는 경향이 있음.

• 여덟 번째 댓글 요약:

  • Kubernetes가 올바른 도구일 수 있지만, 필요악으로 받아들여야 함.
  • 여러 당사자의 실패로 인해 협업에 실패할 가능성이 있는 소프트웨어는 자주 문제를 일으킬 수 있음.

• 아홉 번째 댓글 요약:

  • YAML을 직접 작성하는 것은 문제가 될 수 있으므로, 대신 TypeScript와 Pulumi를 사용하여 Kubernetes 리소스 정의를 생성함.
  • YAML을 린팅하는 대신 전체 프로그래밍 언어 런타임과 서드파티 라이브러리를 도입하고, 버전 유지 관리, 프로젝트 컴파일 등의 추가적인 복잡성을 감수함.

• 열 번째 댓글 요약:

  • Kubernetes에 대한 열정을 가졌던 사람으로서, Kubernetes의 좋은 부분은 기본 요소(배포, 서비스, configmaps)이며 나머지는 특별한 상황에만 사용해야 함.
  • 팀은 설정을 명확하고 분명하게 유지하기 위해 원시 YAML을 작성하고 kustomize를 사용하는 것을 선호함.