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

출처

- 원글 : Paul Butler – The hater’s guide to Kubernetes

- 번역 : 쿠버네티스를 싫어하는 이들을 위한 안내서 | GeekNews (hada.io)

 

이 글은 원글과 GeekNews의 요약을 보고 개인 의견 메모를 위해 작성되었습니다.

---

요약

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를 선택함으로써 얻을 수 있는 이점은 확장성, 높은 가용성, 그리고 다양한 클라우드 환경에서의 일관된 배포 경험임. 그러나 이를 위해 필요한 리소스 관리와 오케스트레이션에 대한 이해가 필요함.

 

---

개인 의견

개인적으로 Kubernetes를 굉장히 완성도 높은 기술의 집합체라고 생각하고 있었다.
그러다보니, 어떤 상황에서도 Kubernetes 위에서 동작하는 것을 기준으로 생각하게 되었다.

(아마 내가 DevOps 관련 직무를 맡고 있기 때문일지도 모른다.)

 

하지만, 여러 개발자분들과 이야기해보면 내가 우물 안의 개구리임을 여실히 깨닫는다.

아직 내가 이름도 몰랐던 AWS 서비스만으로도 안정적인 운영이 가능하다는 단순한 사실 덕분에.

 

위의 글에 전부 다 동의하는 것은 아니지만 대부분 공감한다.

이 일을 하다보면 어느 정도 복잡성을 감수해야 하기도, 간단하게 풀어야 하기도 한다.

결국 기술, 언어에 의존하는 것이 중요한 것이 아니다.

적절한 상황에 적절한 도구를 선택할 수 있는 안목이 중요하다는 생각이 든다.