Live data from Hacker News

A story about a Kubernetes migration

medium.com

11–20 of 60 posts

Re: A story about a Kubernetes migration

#11
post #6
post #4

For me kubernetes is also a breeze. There is some learning curve because we started with Helm, Tiller, Grafana, Prometheus right from the start. But the kubectl command is easy to work with, and the k8s yaml files are really a breeze of fresh air compared to Ansible playbooks. We're not on production yet, but moving soon.

Uuuh, seriously? I always preferred ansibles to kubernetes yaml I'm using both daily and can work with either though

Can't speak for the OP but I dislike the direction they seem to be heading, incrementally (and perhaps accidentally) - yaml as a Turing complete programming language.

Re: A story about a Kubernetes migration

#12
post #7

I hope that the original title of the story was intended sarcasm: "Unbabel migrated to Kubernetes and you won’t believe what happened next!" But so they managed to consolidate their infrastructure around Kubernetes and Google Cloud which made the management of their servers easier and faster? I wonder how much actual money they saved but I guess it will pay off for them in the long run. I've been dabbling with Kubern…

Saying that Kubernetes is a bit complicated seems like saying that water can be a bit wet.

Even their documentation can't keep up. And with a release cycle of 3 months, and a deprecation cycle of 6 months, you need a team dedicated to keeping up with K8s state-of-the-art; so much of that knowledge you picked up a year ago is at best stale, and at worst wrong.

Sure, it makes setting up and keeping a set of containers up simple. But that's never really been that hard.

To paraphrase an article from a few weeks ago:

"We made microservices to address the problems with monoliths."

"We made containers to address the problems with microservices."

"We made Kubernetes to address the problems with containers."

Re: A story about a Kubernetes migration

#13
post #8
post #4

For me kubernetes is also a breeze. There is some learning curve because we started with Helm, Tiller, Grafana, Prometheus right from the start. But the kubectl command is easy to work with, and the k8s yaml files are really a breeze of fresh air compared to Ansible playbooks. We're not on production yet, but moving soon.

I have not worked with Kubernetes yet, but I do have experience with ansible and I was under the impression that Kubernetes is working on a higher abstraction level than ansible. Do kubernetes files really concern themselves with little details such as how a database or application is configured ? I assumed that kubernetes is more about having 'images' of pre-installed machines (e.g via ansible) and having kubernetes…

You are correct, Kubernetes does operate at a higher level of abstraction. By the time you're deploying to Kubernetes, you'll already have images that can be used to run your applications.

However, those images typically will be unconfigured aside from sane defaults. The final configuration (connecting an application to a database, etc) is indeed handled through Kubernetes.

Re: A story about a Kubernetes migration

#14

I am setting up a swarm deployment of one of my apps as an experiment and I must say the learning curve is hardly there. I tried kubernetes, but I found that most resources that try to explain how it works are focussing too much on github-size deployments. I just want 2 instances of my app, a database and traefik with lets encrypt. Does anyone know of a proper resource for the 'just a tad more than dokku' size?

Same here. I think if you have less than 100 servers, then k8s is a real overkill.

Swarm is much easier to reason about and run. It's a godsend for startups without dedicated devops.

Re: A story about a Kubernetes migration

#15

I am setting up a swarm deployment of one of my apps as an experiment and I must say the learning curve is hardly there. I tried kubernetes, but I found that most resources that try to explain how it works are focussing too much on github-size deployments. I just want 2 instances of my app, a database and traefik with lets encrypt. Does anyone know of a proper resource for the 'just a tad more than dokku' size?

Setting up a kubernetes cluster itself is probably the biggest hurdle. Also, bear in mind if it's just for a single service the resource overhead of kubernetes may be significant, possibly even more than 50%.

I'd strongly recommend using a hosted k8s - either GKE, EKS, or I believe digital ocean have just released one.

If you want to use an existing VPS just to test it out, see the docs here https://kubernetes.io/docs/setup/independent/create-cluster-...

Once you have the cluster running, kompose[1] might be a nice tool if you're used to using docker-compose, however I'd say just use it as a guideline - you'll probably want to rewrite most of what it generates at one point or another

[1] https://github.com/kubernetes/kompose

Re: A story about a Kubernetes migration

#16
post #4

For me kubernetes is also a breeze. There is some learning curve because we started with Helm, Tiller, Grafana, Prometheus right from the start. But the kubectl command is easy to work with, and the k8s yaml files are really a breeze of fresh air compared to Ansible playbooks. We're not on production yet, but moving soon.

> k8s yaml files are really a breeze of fresh air compared to Ansible playbooks

Hah. I'm a huge kubernetes fan but not sure I can agree here.

k8s yaml files are the most verbose and spammy things imaginable.

granted, ansible playbooks can be horrific, but i'd say that's more down to the authors of the playbook than ansible itself.

Re: A story about a Kubernetes migration

#17

I am setting up a swarm deployment of one of my apps as an experiment and I must say the learning curve is hardly there. I tried kubernetes, but I found that most resources that try to explain how it works are focussing too much on github-size deployments. I just want 2 instances of my app, a database and traefik with lets encrypt. Does anyone know of a proper resource for the 'just a tad more than dokku' size?

Maybe you can find a similar configuration as a helm chart (https://helm.sh/) (i.e. a k8s pkg manager of sorts).

Re: A story about a Kubernetes migration

#18

I am setting up a swarm deployment of one of my apps as an experiment and I must say the learning curve is hardly there. I tried kubernetes, but I found that most resources that try to explain how it works are focussing too much on github-size deployments. I just want 2 instances of my app, a database and traefik with lets encrypt. Does anyone know of a proper resource for the 'just a tad more than dokku' size?

Have you taken a look at Rancher [0]? Easy to spin up a couple nodes and manage them in a single place. It takes care of most of the issues I've found tedious for you with no issue.

[0] https://rancher.com/

Re: A story about a Kubernetes migration

#19

I am setting up a swarm deployment of one of my apps as an experiment and I must say the learning curve is hardly there. I tried kubernetes, but I found that most resources that try to explain how it works are focussing too much on github-size deployments. I just want 2 instances of my app, a database and traefik with lets encrypt. Does anyone know of a proper resource for the 'just a tad more than dokku' size?

You can try Nomad. It's almost stupidly easy to setup and as long as you're comfortable in a command line- easy to hit the ground running.

The one downside is that it doesn't have a feature complete UI and there arn't any good ones out there that do what the Kubernetes webui does.

Re: A story about a Kubernetes migration

#20
post #7

I hope that the original title of the story was intended sarcasm: "Unbabel migrated to Kubernetes and you won’t believe what happened next!" But so they managed to consolidate their infrastructure around Kubernetes and Google Cloud which made the management of their servers easier and faster? I wonder how much actual money they saved but I guess it will pay off for them in the long run. I've been dabbling with Kubern…

Saying that Kubernetes is a bit complicated seems like saying that water can be a bit wet. Even their documentation can't keep up. And with a release cycle of 3 months, and a deprecation cycle of 6 months, you need a team dedicated to keeping up with K8s state-of-the-art; so much of that knowledge you picked up a year ago is at best stale, and at worst wrong. Sure, it makes setting up and keeping a set of containers…

"Now we have a distributed monolith that requires 2x less developers to build and 5x more system engineers to deploy"
Post reply on HN