Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A story about a Kubernetes migration

medium.com

Post reply on HN
Print view View original

51–60 of 60 posts

Re: A story about a Kubernetes migration

#51

Post by user5994461 »

halbritt wrote: post #30
zedpm wrote: post #24

It sounds like they really wanted to switch to K8s and rationalized it. The cons of their existing solution are minor and easily addressed with correct use of Ansible, and the massive complexity of K8s is understated. As an example, they suggest that there's a heavy cognitive load associated with having devs run some Ansible playbooks, and then argue that to avoid that, they just have to introduce an entirely new too…

Regardless of your skepticism, the benefits are real. Scaling applications in k8s, updating, and keeping configs consistent are a great deal easier for me than using Ansible or any other config management tool. In the end, it's a singular platform that one can build tooling against that allows an organization to abstract away the infrastructure. My team has done that (on top of k8s). As such, a developer can spin up…

You still need ansible to setup the hosts and the databases.

Re: A story about a Kubernetes migration

#52

Post by tlynchpin »

Fishkins wrote: post #39

Since they mention it a couple times in the article, how do other folks handle auth for their k8s dashboards? I'm trying to figure out the best approach that right now.

Me too. I haven't tried any of this but here's a suggestion:

https://akomljen.com/protect-kubernetes-external-endpoints-w...

Re: A story about a Kubernetes migration

#53

Post by halbritt »

falcolas wrote: post #46
adwf wrote: post #45

Earlier quoted context omitted.

Only if you've got a homogeneous workload that can scale out. More typical is Team A working on Project A spin up a test DB + test app server. Team B also spin up a test app server + web server + DB for project B Then Project A gets productionized and you have SIT/UAT/Stage copies of all of that sitting mostly idle. Then project C comes along and the devs need to test on a 3 node C* cluster with 3 kafka brokers... Su…

But those use cases don't change between AWS and GCE. They only change if you start using containers in a container environment; something possible in AWS and GCE.

The distinction is between traditional config management and instances vs. Kubernetes. I could've seen similar benefits running k8s in AWS. I simply chose GKE because it's superior to other offerings.

There are other things to like about GCP vs. AWS, but that's a bit tangential.

Re: A story about a Kubernetes migration

#54

Post by halbritt »

falcolas wrote: post #43
halbritt wrote: post #30

Earlier quoted context omitted.

Regardless of your skepticism, the benefits are real. Scaling applications in k8s, updating, and keeping configs consistent are a great deal easier for me than using Ansible or any other config management tool. In the end, it's a singular platform that one can build tooling against that allows an organization to abstract away the infrastructure. My team has done that (on top of k8s). As such, a developer can spin up…

With ECS running on Fargate, idle instances don't exist. Throw in service autoscaling, and you have a simple scaling solution with no K8s cluster management required.

Given the adoption of Kubernetes, would you honestly recommend that someone seriously consider ECS?

Re: A story about a Kubernetes migration

#55

Post by halbritt »

oppositelock wrote: post #48
falcolas wrote: post #43

Earlier quoted context omitted.

With ECS running on Fargate, idle instances don't exist. Throw in service autoscaling, and you have a simple scaling solution with no K8s cluster management required.

Or, you use EKS, no k8s cluster management required either. I'm running a production service on EKS, also tried it on GKE. Both take away most of the cluster management pain.

Agreed.

Re: A story about a Kubernetes migration

#56

Post by halbritt »

user5994461 wrote: post #51
halbritt wrote: post #30

Earlier quoted context omitted.

Regardless of your skepticism, the benefits are real. Scaling applications in k8s, updating, and keeping configs consistent are a great deal easier for me than using Ansible or any other config management tool. In the end, it's a singular platform that one can build tooling against that allows an organization to abstract away the infrastructure. My team has done that (on top of k8s). As such, a developer can spin up…

You still need ansible to setup the hosts and the databases.

Not in my environment.

Creating a cluster is a one-liner, no Ansible required. The node pool comes with that, which sets up the hosts. Databases are all created in cluster with a helm chart.

Many people will advise against running stateful workloads in k8s. It's tricky, sure, but the benefits are still there.

As a result of the orchestration my team has built on top of k8s, any developer in my organization can clone any production environment at any time with production data. Those cloned environments can be configured to receive streaming updates from the production environment, once created.

Developers can test bug fixes and features on live streaming production data with absolute certainty that they won't break anything. This capability is immensely valuable.

Re: A story about a Kubernetes migration

#57

Post by zedpm »

halbritt wrote: post #54
falcolas wrote: post #43

Earlier quoted context omitted.

With ECS running on Fargate, idle instances don't exist. Throw in service autoscaling, and you have a simple scaling solution with no K8s cluster management required.

Given the adoption of Kubernetes, would you honestly recommend that someone seriously consider ECS?

Yeah, I would recommend it in certain circumstances. EKS has $150/month base cost for the control plane, so for small environments it's too expensive. For groups with existing experience with Docker and Docker Compose but no experience with Kubernetes, it's fairly easy to get things working on ECS. If you don't have a whole ops team with time to build out all the tooling to make k8s use easy for devs, then again k8s probably isn't the right answer.

Kubernetes is great, but you're not being honest with yourself if you can't acknowledge the difficulty in going from 0 to production-ready. There is a ton of complexity and lots of grief on the path to a fully functional k8s environment.

Re: A story about a Kubernetes migration

#58

Post by falcolas »

halbritt wrote: post #54
falcolas wrote: post #43

Earlier quoted context omitted.

With ECS running on Fargate, idle instances don't exist. Throw in service autoscaling, and you have a simple scaling solution with no K8s cluster management required.

Given the adoption of Kubernetes, would you honestly recommend that someone seriously consider ECS?

In addition to Zed’s comment, ECS is remarkably mature and for many cases has feature parity with K8s. It’s much more mature and better supported than EKS right now.

Migrating between the two isn’t even all that difficult if you change your mind later.

Re: A story about a Kubernetes migration

#60

Post by halbritt »

zedpm wrote: post #57
halbritt wrote: post #54

Earlier quoted context omitted.

Given the adoption of Kubernetes, would you honestly recommend that someone seriously consider ECS?

Yeah, I would recommend it in certain circumstances. EKS has $150/month base cost for the control plane, so for small environments it's too expensive. For groups with existing experience with Docker and Docker Compose but no experience with Kubernetes, it's fairly easy to get things working on ECS. If you don't have a whole ops team with time to build out all the tooling to make k8s use easy for devs, then again k8s…

That last part, I wholly agree with. The learning curve is steep and difficult.
Post reply on HN