GN⁺: 친애하는 친구야, 넌 Kubernetes를 만들었어

• 친구에게 보내는 편지

  • Kubernetes를 피하려고 했지만 결국 비슷한 시스템을 만들게 되었음을 설명하는 내용.
  • 친구는 "지루한 기술"을 선택하여 간단한 컨테이너 실행을 원했지만, 결국 복잡한 스크립트와 설정으로 인해 문제가 발생함.
  • Docker Compose로 전환해도 모든 문제를 해결할 수는 없으며, 배포, 롤링 업데이트, 롤백, 스케일링을 위한 별도의 솔루션이 필요함을 깨달음.

• 서버 확장과 네트워크 복잡성

  • 두 번째 서버로 확장할 필요성을 느끼게 됨.
  • Tailscale과 같은 오버레이 네트워크를 사용하여 서비스 발견을 시도함.
  • 네트워크 복잡성을 해결하려고 노력하지만, 결국 더 많은 문제에 직면하게 됨.

• 유지보수와 자동화

  • 스크립트를 만든 당사자가 휴가를 가거나 퇴사하면, 복잡한 설정과 문서화되지 않은 설정 변경 사항을 누가 관리할 것인가라는 질문이 발생.
  • 커스텀 스크립트의 유지보수 문제를 해결하기 위해 Ansible을 사용하여 VM을 불변하고 버전 관리 가능하게 만듦.
  • Kubernetes를 사용하지 않기 때문에 더 쉽게 유지보수할 수 있을 것이라 생각함.

• 컨테이너 스포닝과 보안 문제

  • 프로그램적으로 다른 컨테이너를 생성해야 하는 요구사항이 생김.
  • Docker 소켓을 웹 앱에 마운트하는 것은 보안상 위험하기 때문에, 이를 해결하기 위한 별도의 서비스 작성.
    • Docker API의 안전한 부분만 노출하는 별도의 서비스를 작성하여 문제를 해결함.

• 결론

  • 결국 Kubernetes와 유사한 시스템을 구축하게 되었음을 깨달음.
    • 표준 설정 포맷, 배포 방법, 오버레이 네트워크, 서비스 디스커버리, 불변 노드, API 서버를 포함한 복잡한 시스템 완성

• PS

  • 쿠버네티스를 대체할 더 나은 솔루션이 존재할 수 있다는 가능성을 부정하는 것은 아님.
  • 단, 쿠버네티스를 복잡하다고 단정짓기 전에, 그것이 해결하려는 문제를 충분히 이해하길 권장.

[savvykang]

배포 인수인계를 해결하기 위해 쿠버네티스를 도입한다는 이야기는 잘 이해가 안되네요

[kandk]

유지보수와 자동화 가 코드레벨로 쉽게 되어있습니다.
Infra as code도 가능합니다.

[savvykang]

EKS같은 매니지드 k8s 서비스 환경에서는 로드밸런서도 있고 Route 53도 연동 가능하지만, 셀프호스팅 k8s는 로드밸런서 구현체도 없고 DNS 연동도 제한적이더라구요. k8s 관리팀이 따로 있는 회사에서는 말씀하신 장점이 사실일 수도 있겠네요

언뜻 들으면 괜찮은 솔루션 같아 보이지만 막상 써보면 모든 상황에서 동작하지는 않습니다

[kandk]

k8s 관리팀 없어도 사용하기 쉽습니다. EKS사용하면됩니다.

[savvykang]

소스코드만 주면 인수인계 끝이라는 주장이랑 똑같지 않나요? 업무 매뉴얼이랑 업무 수행 이력은 여전히 필요할거 같은데요

[kbumsik]

Infra as Code 자체가 소스코드만 주면 끝내려고 있는거긴 하죠.
아 물론 어느 코드나 다 마찬가지로 기본적인 문서화는 되어있어야죠.

[kandk]

소스코드가 잘짜있고, 문서가 잘되어 있으면 가능합니다.
업무 매뉴얼이랑 업무 수행 이력은 따로 있으면 도움이 되겠지만, 이 글이랑은 다른 이야기 같네요.

[neo]

Hacker News 의견

• 여러 회사에서 쉘 스크립트를 사용하여 배포를 성공적으로 수행한 경험이 있음

  • PHP 서비스 2개로 하루에 10억 건 이상의 요청을 처리하며, 서버에 파일을 전송하고 마이그레이션을 실행하여 다운타임 없이 배포를 수행함
  • 은퇴 계좌와 같은 웹스케일이 필요 없는 산업에서 Jenkins를 통해 Docker 명령어로 배포를 수행함
  • 테스트 환경을 몇 분 안에 필요에 따라 사용할 수 있었음
  • 현재 회사는 Kubernetes를 도입하려고 하지만 복잡성 때문에 어려움을 겪고 있음

• Kubernetes는 YAML 파일을 관리하기 위해 두세 명의 전담 직원이 필요함

  • 클라우드 제공업체를 선택하면 복잡한 부분을 해결할 수 있지만 추가 비용이 발생함
  • YAML 파일은 사람이 작성하는 것이 아니라 도구가 생성해야 하는 구성 파일임
  • 대부분의 웹사이트와 서비스에는 Kubernetes가 필요하지 않음

• 단순한 것이 취약하다는 생각은 잘못된 것임

  • YAML 파일과 Kubernetes의 복잡성을 이해하고 디버깅하는 것이 더 어려움
  • Kubernetes의 대안으로는 쉘 스크립트가 있음

• Kubernetes가 필요하지 않은 경우도 있음

  • EC2 인스턴스와 간단한 쉘 스크립트로 100,000명 이상의 동시 사용자 처리 가능
  • 문제가 없으면 굳이 변경할 필요가 없음

• 쉘 스크립트로 iptables 규칙과 sysctl 편집을 쉽게 관리할 수 있음

  • 작업 큐를 사용하여 컨테이너를 프로그래밍적으로 생성하는 대신 작업을 푸시할 수 있음

• Kubernetes를 비판하는 것은 비전문적임

  • Google이나 Netflix 같은 대규모 애플리케이션이 아니라면 간단한 스크립트를 작성하는 것이 더 나음

• 홈그로운 시스템의 제약이 모두 비용이라는 가정과 범용 솔루션의 유연성이 모두 이점이라는 가정은 잘못됨

  • 코드베이스에서 유사한 패턴을 따르고 서비스가 동일한 방식으로 배포되기를 원함

• Kubernetes의 문제는 수많은 오픈 소스 라이브러리가 시스템을 이해하기 어렵게 만들고 버그를 유발함

• Kubernetes의 학습 곡선을 넘은 사람들은 복잡성이 그렇게 나쁘지 않다고 말함

  • 개발자에게 Kubernetes를 가르치는 강의는 30분 정도 소요되며 Helm 차트를 작성할 수 있게 함