24P by jujumilk3 16일전 | favorite | 댓글 13개

얼리스테이지에 있는 스타트업들은 쿠버네티스를 섣불리 도입하지 마라.
시기상조인 경우가 대부분.

작은 규모의 팀(1~10명)은 Serverless container service를 사용하는 것이 좋다.
(AWS ECS - Fargate, GCP의 Google cloud run)

sungwoo 3일전  [-]

k8s는 이미 호불호의 문제가 아니라 생존의 문제 아닐까요?
AWS는 몰라도 k8s는 알아야 하는 상황이 되었다고 생각하는데요.

답변달기
kbumsik 16일전  [-]

해커뉴스 댓글에도 아주 많이 달린 의견인데..... [1]
글이 "쿠버네티스는 어렵다" 라는 게 전제가 깔려있어서 좀 혼란스럽네요.

요즘은 쿠버네티스 에코시스템이 많이 발전해서 온프렘에서 쿠버네티스를 직접 설치하지 않는 이상 그렇게 어려운 것이 아닙니다.
또한 쿠버네티스 운영은 복잡도를 스스로 어느정도 결정할 수 있는데, 기본적인 구성만 만드는 데는 힘들지 않습니다. 나중에 이것저것 애드온들 붙이면 당연히 힘들어지고요.
저 같이 신입때 EKS 부터 배포환경을 경험한 사람도 많이 생겼고요.

콕 찝에서 말하자면,, 기본적인 k8s Deployment, Ingress (물론 DB는 별도의 매니지드 서비스) 를 구성하는 것이 저기 글에서 말하는 AWS ECS Fargate 를 직접 구성하는 것보다 딱히 어려운 것인지 이해가 가지 않네요.
둘 다 같이 VPC, 클러스터, CDN, 로드밸런서 구성을 해야하는 건 똑같은 걸요...댓글에서는 오히려 ECS가 더 불편했다는 글도 많고요.

[1] https://news.ycombinator.com/item?id=31795160

답변달기
sixmen 15일전  [-]

저희 회사는 개발자가 100명을 넘어가면서 필요성이 느껴져서 ECS -> EKS 전환을 하고 있는데 조금 후회할 때도 있습니다.

"쿠버네티스 운영은 복잡도를 스스로 어느정도 결정할 수 있는데" 라고 하시지만, 잘 모르는 입장에서는 쿠버네티스 생태계에 말이 나오는 것은 다 필요한 것인가보다라고 생각하고 다 넣게되는 측면이 있습니다.

로드밸런서 구성을 해야 하는 건 똑같다고 하셨지만, ALB만 알면 되는 것 vs ALB + Ingress를 알아야 하는 것의 차이가 있다고 생각합니다.

작은 규모에서 MSA가 필요하지 않은 것처럼, 쿠버네티스는 생각보다는 알아야 할게 많아서 '어플리케이션에 집중해야 하는 규모'에서는 오버 스펙은 맞다고 생각합니다.

다만 쿠버네티스 환경을 누군가 잘 구축해뒀다면, 그 위에서 어플리케이션 배포하는 것은 클라우드 독립적인 표현으로 정의하다보니 락인 효과가 적을 것 같긴 했습니다.

답변달기
kbumsik 15일전  [-]

말씀들어보니 확실히 그런 측면들이 있을 거 같네요. 제가 쿠버네티스 쓰면서 알게 된 것들을 너무 당연하게 생각한거 같네요.
그리고 요즘 쿠버네티스에서 나오는 애드온들 너무 많다보니 취사선택 결정에 어려움이 있다는 것도 인정하고요.

제가 ECS -> EKS 같이 마이그레이션 경험이 없다보니...혹시 락인 효과 같은 거 말고 전환 이후에 좀 나아진 점이 있으신지 궁금합니다.

답변달기
colus001 14일전  [-]

동감입니다.기본적인 셋업이 그렇게 어렵지도 않고, 유지보수 난이도가 높은편도 아니라고 생각해요. 클라우드에서 복잡한 셋업 하나, 쿠버네티스 yml 셋업으로 넘기나 딱히 뭐가 더 좋다고 말 못하겠네요.

답변달기
kbumsik 16일전  [-]

아 참고로 제 경험은 EKS 기준으로 말씀드리는겁니다. 온프램에서 직접 k8s 설치해서 etcd, Control Plane 을 직접 운영하는 것과 많이 다르죠 ㅎ

k8s부터 시작한 사람 입장에서는, 글을 읽으면서 드는 생각이 반대로 굳이 ECS를 시간들여가며 공부를 해야하나...라는 생각이 들더라고요.
여튼 꼭 저렇게 공식 지정할 필요 없이 우선 팀에서 편하다고 느끼는 방식으로 쓰는게 맞지 않나 생각합니다.

답변달기
525hm 15일전  [-]

k8s 시작 입장에 동의합니다.

답변달기
pppqqq 16일전  [-]

"비즈니스에 집중해라" 이런 원론적인 차원의 얘기가 아니라 뭔가 특수한 기술에 락인되는 결정에는 동의하기 어렵네요.
beanstalk/app engine/heroku 같은 PaaS를 적극 활용하라는 글이었다면 적극 동의했을 텐데 작은 팀에서 ECS/cloud run/docker swarm을 선택해서 얻는 장점은 요즘은 거의 없다시피 합니다 . 4~5년 전이었다면 모를까요.

답변달기
bravomylife 11일전  [-]

저는 이 의견에 반대합니다.

k8s가 가지는 유일한 단점은 러닝 커브 딱 하나라고 생각합니다.

팀원이 5명 정도 수준일지라도 처음이야 어렵겠지만, 일정 수준 이상 k8s에 대한 수준이 올라오면, 절때 이전으로 돌아 갈 수 없습니다. 그로 인한 생산성 향상은 비교가 되질 않습니다.

ci/cd, gitops, 카나리 배포 등등 k8s 없이도 할 수 있지만, k8s위에 함께 하는것이 더 이해하기 쉽고 관리하기 간편합니다.

직접 이전기를 경험해본 저로서는 아직 시기 상조라고 말하는것은
마치 aws cloud 가 생소하다고 해서 도입을 망설이던 on premise 시절을 떠올리게 합니다.

답변달기
jjpark78 16일전  [-]

비용적인 측면에서 보면 serverless가 압도적으로 유리하죠

답변달기
tribela 16일전  [-]

저도 공감합니다. 대부분의 경우엔 docker-swarm 내지는 docker-compose로 충분하고도 넘칩니다

답변달기
mrchypark 16일전  [-]

매우 공감갑니다.

10명 뿐만 아니라 어지간한 크기의 회사에서 k8s 도입하는 것에 저는 부정적입니다.

클라우드 벤더 락인이 크리티컬한 수준이 되거나 온프람등의 인프라가 함께 사용되는 수준이나 되야 의미있지 않나 싶습니다.

답변달기
jujumilk3 16일전  [-]

엔터프라이즈급 회사들의 기술스택을 관성적으로 따라가는 면이 없잖아 있다고 생각했었는데
마침 글로 정리된 게 해커뉴스에 떠서 공유해봅니다

답변달기