Live data from Hacker News

A story about a Kubernetes migration

medium.com

1–10 of 60 posts

Re: A story about a Kubernetes migration

#2
It seems that k8s has won the deployment race by and large. I see a lot of success stories around (I'm hearing nice things from the DevOps teams in my organization as well). Yet I'm curious to hear a few cases where things did not pan out quite right.

Note: The 5-15s DNS problem seems a pretty serious one. Weird that it didn't get more publicity (and a proper fix).

Re: A story about a Kubernetes migration

#3
I'm working with Kubernetes recently and the learning curve is quite hard. I hope the team will improve kubectl to make it more user-friendly (error messages are hard to understand for beginners).

A lot of cloud providers now have a way to easily deploy and manage a k8s cluster on their servers but I cannot find a tools that help with the deployment of a basic service, something like dokku but on Kubernetes.

http://dokku.viewdocs.io/dokku/

Re: A story about a Kubernetes migration

#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.

Re: A story about a Kubernetes migration

#5
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?

Re: A story about a Kubernetes migration

#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

Re: A story about a Kubernetes migration

#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 Kubernetes for some time now but God forbid it can be a bit complicated. Time required to become well-versed with Kubernetes is a hefty investment which is not for all organizations. Lots of small things that can drive up your blood-pressure when figuring them out. Were it simpler I would be much more inclined to be using it but now it's only in the "learning for funsies" -category. I feel people who've developed k8s have been more of the theoretical sort and not the regular-joe-dummy-kind like me.

Re: A story about a Kubernetes migration

#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 just 'clone' them into production and interconnect them.

Re: A story about a Kubernetes migration

#9
post #2

It seems that k8s has won the deployment race by and large. I see a lot of success stories around (I'm hearing nice things from the DevOps teams in my organization as well). Yet I'm curious to hear a few cases where things did not pan out quite right. Note: The 5-15s DNS problem seems a pretty serious one. Weird that it didn't get more publicity (and a proper fix).

There are a lot of things that can go wrong with K8s but there is always a way to fix them. For example a common mistake it to forget to allocate limits on pods, which then brings the worker node to capacity. I think the failure scenario is soft, it's just going to cost more engineering time to figure out how to upgrade the cluster to the new version, find out why this network overlay isn't performing as expected or debug this external resource that isn't being allocated properly, configure RBAC properly, play with various resource deployment strategies, tune how pods are being moved during a node auto-scaling event... The nice thing is that at the end it gives a unified API for all of the things, it forces some consistency in the infrastructure.

My personal rule of thumb is that unless the client specifically need auto-scaling or have more than 100 services to run, have a 5 people devops team, just use Terraform.

For a small number of servers a better strategy is to have a base image with Docker and monitoring, and use Terraform to deploy the infrastructure. CI can then use docker-compose to deploy the containers onto the hosts directly. This approach is much more stable and doesn't require to learn as many things as K8s. This can be run by a 1 man DevOps team without a sweat.

Re: A story about a Kubernetes migration

#10
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'm having the same experience, more or less.

The one pain point, for me, is still the development workflow, which is still lacking compared with told like docker-compose.

However, skaffold seems to be quickly closing that gap and I'm pretty excited about it.

Post reply on HN