# 저는 Kubernetes가 필요하지 않았고, 여러분도 아마 필요하지 않을겁니다 > Clean Markdown view of GeekNews topic #17991. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=17991](https://news.hada.io/topic?id=17991) - GeekNews Markdown: [https://news.hada.io/topic/17991.md](https://news.hada.io/topic/17991.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2024-11-28T09:51:15+09:00 - Updated: 2024-11-28T09:51:15+09:00 - Original source: [benhouston3d.com](https://benhouston3d.com/blog/why-i-left-kubernetes-for-google-cloud-run) - Points: 19 - Comments: 12 ## Summary Kubernetes는 최근 인프라에서는 필수적인 것 처럼 얘기되지만 복잡성과 비용 문제로 인해 관리가 어려우며, 특히 간단한 프로젝트에서는 비효율적일 수 있습니다. 필자는 Google Cloud Run은 Kubernetes의 복잡성을 줄이고, 비용 효율적이며 빠른 오토스케일링을 제공하여 더 나은 대안이 될 수 있다고 추천하고 있습니다. Cloud Run은 Docker 기반으로 작동하며, Kubernetes의 관리 부담 없이 간단한 비동기 작업과 자동 스케일링을 지원합니다. ## Topic Body ### Kubernetes를 떠나 Google Cloud Run을 선택한 이유 #### **Kubernetes 도입의 배경** - 2013년 출시한 온라인 3D 편집 플랫폼 **Clara.io**에서 **베어메탈 서버**를 사용해 인프라를 최적화했으나, 하드웨어 관리와 모니터링에 과도한 작업 필요. - 2018년 **Threekit.com** 프로젝트에서 **Kubernetes**를 선택. 당시 **Azure, AWS, Docker**가 Kubernetes를 표준으로 채택하며 주류화. #### **Kubernetes의 한계** 1. **비용 문제**: - 관리 노드, 클러스터 중복 구성 등 기본 클러스터 구축 비용이 큼. - 느린 오토스케일링으로 서비스 과잉 프로비저닝 필요, 미사용 리소스 비용 발생. 2. **작업량 관리의 어려움**: - 작업 스케줄링이 복잡하며, 내장 스케줄러 및 Argo도 대량 작업에서는 비효율적. 3. **복잡성 과부하**: - 풍부한 기능이 단순 작업도 복잡하게 만듦. - Kubernetes 관리에 전담 DevOps 인력이 필요하며, 이는 비용 상승으로 이어짐. #### **Google Cloud Run으로 전환** **Cloud Run**은 Kubernetes의 복잡성을 대체하며 간소화된, 비용 효율적인 환경을 제공. ##### **새로운 설정** - **Docker 컨테이너 기반** 인프라: - **자동 스케일링 서비스**와 **장기 실행 작업**용 컨테이너 포함. - Cloud Run은 컨테이너 배포, 스케일링, 가동 중단 관리 및 작업 실행을 자동화. ##### **Cloud Run의 장점** 1. **비용 효율성**: - CPU 및 메모리 사용 시간에 따라 요금 부과. - 유휴 서비스에는 비용이 발생하지 않음. - 예: **Web3D Survey** 사이트는 월 **500,000회 트래픽**을 처리하면서 **$4/월**로 운영 가능. 2. **빠르고 안정적인 오토스케일링**: - Kubernetes보다 빠른 몇 초 내 스케일링. - 수요 급증을 신속히 처리 가능. 3. **Kubernetes 관리 부담 없음**: - Cloud Run은 Google의 Borg 기반으로 Kubernetes 클러스터 관리 불필요. 4. **간단한 비동기 작업**: - **Cloud Run Tasks**를 사용해 자동 재시도, 대량 작업 실행이 간편. ##### **Kubernetes의 잠재적 문제: 클러스터 락인** - Kubernetes 기능에 의존하면 클러스터 외부 리소스 통합이나 확장이 어려워짐. - 특정 인프라에 의존하게 되어 확장과 마이그레이션이 복잡하고 비용 증가. #### **Cloud Run 사용에 대한 일반적인 질문** ##### **“GCP 종속성이 걱정되지 않나요?”** - Docker 기반 설정으로 AWS 같은 다른 클라우드로의 마이그레이션이 약 1주일이면 가능. - 현실적으로 정치적 요인 외에는 클라우드 제공자를 변경하는 경우가 드물음. ##### **“Cloud Run도 결국 Managed Kubernetes 아닌가요?”** - Cloud Run은 Knative 인터페이스를 사용하나, Kubernetes가 아닌 Google의 Borg 위에서 작동. - Kubernetes의 복잡성을 없애고 간소화된 인터페이스 제공. #### **현 워크플로의 단점** 1. **서비스 이름 관리의 불편함**: - 로컬 및 서버에서 일관된 구성 관리를 위한 추상화 계층 필요. - Kubernetes의 네임 관리 기능이 부재. 2. **Cloud Run Task 에뮬레이션 부족**: - 로컬에서 작업 개발 시 로그 출력 캡처 및 추적을 포함한 간단한 에뮬레이션 환경 부재. #### **결론** - **Cloud Run**은 비용, 속도, 확장성, 간소화 측면에서 최적의 솔루션 - **대기업**이나 복잡한 요구사항이 있는 경우 Kubernetes가 유용할 수 있으나, - **간소성과 효율성**이 중요한 프로젝트에서는 **Cloud Run**이 훨씬 실용적 - **PS**: Kubernetes의 특정 확장을 추가하는 것으로 문제를 해결할 수도 있겠지만, 이는 복잡성을 더할 뿐이며, 단순한 필요를 초과하는 Kubernetes 환경에 의존하고 싶지 않음 ## Comments ### Comment 31889 - Author: blurblah - Created: 2024-12-01T11:04:33+09:00 - Points: 1 silver bullet이 어디 있겠습니까. 상황에 맞게 잘 쓰면 되는거겠죠 ㅎㅎ 트렌디한거라고 무비판적으로 kubernetes를 도입하면 힘들어질 수 있는데 그래도 좀 규모가 큰 환경에서는 괜찮은 도구라고 생각하고 있습니다. 도입을 하더라도 도입만 하고 끝나면 제대로 못쓰게 될거에요. 그리고 어떤 도구든 마찬가지지만 100% 개발자나 사용자의 니즈를 충족시킬 수는 없기 때문에 적절한 수준의 자동화는 필수일 것 같습니다. ### Comment 31844 - Author: bungker - Created: 2024-11-29T13:04:08+09:00 - Points: 1 쿠버네티스는 구축만 되면 꿀빠는 일만 남았는데 ... ㅠㅠ ### Comment 31827 - Author: riki3 - Created: 2024-11-29T09:34:41+09:00 - Points: 2 kubernetes 가 제 밥줄이고 한때는 이것이 정답이다 라고 믿었던 시절이 있습니다만 시간이 지날수록 많은 문제들을 경험하고 시간을 낭비하게 되는 스스로를 찾게되네요. 남한테는 k8s 추천하지만 제 서비스에 사용하진 않을 것 같습니다. k8s도 k8s지만 그냥 컨테이너도 지쳤습니다. ### Comment 31815 - Author: joon14 - Created: 2024-11-28T16:27:42+09:00 - Points: 1 AWS 를 사용중이라면 ECS 와 비슷하다고 생각하면 될까요? ### Comment 31824 - Author: tujuc - Created: 2024-11-29T08:53:37+09:00 - Points: 1 - Parent comment: 31815 - Depth: 1 네 그것이라고 보시면 됩니다. :) ### Comment 31814 - Author: eclipsense - Created: 2024-11-28T15:55:54+09:00 - Points: 1 kubernetes를 못쓰는게 잘못이지 kubernetes가 별로 라고 하기에는 좀 그렇네요. ### Comment 31810 - Author: tujuc - Created: 2024-11-28T13:43:29+09:00 - Points: 2 저도 글쓴이의 생각과 비슷합니다. 아직 회사 규모가 kube를 사용할정도가 아니기도하구요. 모든 개발자가 Kube를 이용해서 관리를 할 수 있을꺼라는 것은 저만의 생각이었어요. 회사의 개발자의 평균보다 못하게 인프라를 구축하고 문제를 해결할 수 있도록 가이드해주는게 더 낫더라구요... ### Comment 31801 - Author: doolayer - Created: 2024-11-28T12:29:30+09:00 - Points: 1 ???: 저는 AI 가 필요하지 않았고, 여러분도 아마 필요하지 않을겁니다. ### Comment 31800 - Author: ilbanin00 - Created: 2024-11-28T12:22:35+09:00 - Points: 1 어떤 제품이건 트레이드오프가 되는 부분들이 있을텐데 ### Comment 31795 - Author: bbulbum - Created: 2024-11-28T11:18:13+09:00 - Points: 1 managed 서비스를 쓰면 딱히 관리에 어려움을 느끼진 못했어서,, 어떤 도구든 적당한 선에서 사용하면 유용한데 쿠버네티스는 유독 '복잡한 설정이 가능함'이 주로 비판되는 것 같다는 생각이 드네요. ### Comment 31811 - Author: tujuc - Created: 2024-11-28T13:44:50+09:00 - Points: 1 - Parent comment: 31795 - Depth: 1 거의 모든 것을 내가 원하는데로 만들 수 기술이다보니... :) 복잡하게 사용하는 경우가 많아서 그럴꺼같네요 ㅎㅎㅎㅎ... ### Comment 31782 - Author: neo - Created: 2024-11-28T09:51:15+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=42252336) - "클라우드 기술"에 대한 불만을 표현하며, Kubernetes 사용 시 YAML 파일을 수정하고 오류를 해결하는 데 많은 시간을 소비하게 됨을 언급함. 클라우드 통합을 피하고 직접 서버를 설정하고 싶다는 의견을 가짐 - Kubernetes는 DevOps와 관리 시간 외에도 상당한 인프라 비용이 발생함. 클라우드 제공자의 관리형 Kubernetes를 사용하는 것이 더 효율적임을 제안함 - Kubernetes는 컨테이너 오케스트레이션 도구가 아닌 컴퓨터 클러스터를 만드는 도구로, 클러스터가 필요하지 않다면 Kubernetes를 사용하지 않아도 됨을 설명함 - DevOps에 대한 과도한 투자가 줄어들고 있으며, Kubernetes에 대한 비판적인 시각을 공유함. 작은 스타트업에서는 단일 서버로도 충분할 수 있음을 강조함 - Cloud Run 사용 시 주의할 점으로 TCP 연결 제한, 실행 환경 선택, 자동 확장 설정 등을 언급함 - Cloud Run은 작은 스타트업에 적합하지만, 보안 아키텍처의 기본 요소인 방화벽 제어가 부족함을 지적함. 결국 VPC가 필요하게 될 것임을 설명함 - Google Cloud Run과 Kubernetes의 비교는 공정하지 않다고 주장하며, 각각의 장단점을 설명함. Kubernetes는 복잡한 작업에 적합함을 강조함 - Kubernetes는 학습 곡선이 가파르지만 적절히 사용하면 강력한 도구임을 설명함 - Kubernetes에 대한 비판에 동의하지 않으며, 복잡한 앱을 배포할 때 Kubernetes API가 필요할 수 있음을 강조함 - Kubernetes의 복잡성은 주로 시스템 관리 작업에서 발생하며, Kubernetes 자체는 안정적임을 설명함 - IaC와 CM은 구성을 줄이고 관리하기 쉽게 만들어야 하지만, 실제로는 더 많은 노력이 필요하다는 점을 지적함. 많은 경우 Kubernetes가 필요하지 않으며, 좋은 시스템 관리자가 더 중요함을 강조함