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를 사용하는 것을 선호함.