Live data from Hacker News

What we learned after a year on Kubernetes

about.gitlab.com

61–70 of 162 posts

Re: What we learned after a year on Kubernetes

#61
post #60

Was anyone else surprised by the timeline of this post? I was under the impression that Gitlab had been fully on K8S for years now, given the hard push of their K8S offering 18 months ago.

It has been possible to run GitLab the application on K8s for some time now for the majority of self-managed deployments. There were some limitations however, for running GitLab on K8s at the very large scale of GitLab.com that we have been working through in the last year. (disclaimer: blog post author)

> August 2019 when we migrated the GitLab Container Registry to Kubernetes, the first service to move. Though this was a critical and high traffic service, it was a good choice for the first migration because it is a stateless application with only a few external dependencies

I was under the impression that porting a large stateless service was something that wasn't too bad to do with K8S? What limitations prevented this from going ahead earlier?

Re: What we learned after a year on Kubernetes

#62
post #55
post #54

I learned not to use it and wait until the k8s fad goes away.

i'm curious to hear about your alternative deployment strategy (no snark intended)

We use Nomad from Hashicorp at $dayjob and I'm quite happy with it.

https://www.nomadproject.io/

https://www.hashicorp.com/resources/introduction-nomad

https://blog.cloudflare.com/how-we-use-hashicorp-nomad/

Re: What we learned after a year on Kubernetes

#64

I do have only very minimal xp in k8s, as I have tried to use it only once (and never again). To me it seem like mOst of the comments are about the unusable and unmaintainable yaml configuration files. This seems like exactly the issue I had a few years ago, when I was cursing, because I could not find a spec or docs for the yaml stuff in all the pages and pages of seemingly important documentation and thus could not…

There's definitely a need for an opinionated layer over the top, with much simpler configuration. Probably more than one, with different use cases. Nobody should have to wrangle that much yaml.

Re: What we learned after a year on Kubernetes

#65
post #60

Earlier quoted context omitted.

It has been possible to run GitLab the application on K8s for some time now for the majority of self-managed deployments. There were some limitations however, for running GitLab on K8s at the very large scale of GitLab.com that we have been working through in the last year. (disclaimer: blog post author)

> August 2019 when we migrated the GitLab Container Registry to Kubernetes, the first service to move. Though this was a critical and high traffic service, it was a good choice for the first migration because it is a stateless application with only a few external dependencies I was under the impression that porting a large stateless service was something that wasn't too bad to do with K8S? What limitations prevented…

Yeah, this is why we decided to migrate it first about a year ago, and we probably could have done it sooner than that. Other services were not yet ready to migrate until recently due to some blocking issues which was a factor in the decision.

disclaimer: blog post author

Re: What we learned after a year on Kubernetes

#66

I do have only very minimal xp in k8s, as I have tried to use it only once (and never again). To me it seem like mOst of the comments are about the unusable and unmaintainable yaml configuration files. This seems like exactly the issue I had a few years ago, when I was cursing, because I could not find a spec or docs for the yaml stuff in all the pages and pages of seemingly important documentation and thus could not…

You can start off with an example you would find online, then use "kubectl explain" to read about the options used and other ones you want to use.

Re: What we learned after a year on Kubernetes

#68
post #54

I learned not to use it and wait until the k8s fad goes away.

My disappointment with Kubernetes as the next/current big thing is that it practically didn't change a thing for companies as a whole. You still need dedicated devops people / a dedicated team. There is so much to get wrong regarding security, reliability and performance. Most application developers stay away from k8 configuration and could not quickly replace a devops engineer. They are the wizards holding the power.

It's an incredible mess of artificial complexity. You finally understood kubernetes and can work with the manifest files? Oh, no, no, no, nobody does that. You need to at least learn helm and a dozen of other kubernetes ecosystem tools! Every company has a different setup for it.

* I have a GKE cluster running to learn Kubernetes. Once you understood the basics it's indeed a simple way to get applications up and running, but my points stand. I am far away from enterprise readiness.

Re: What we learned after a year on Kubernetes

#69
post #67
post #54

I learned not to use it and wait until the k8s fad goes away.

Every time I read an article on k8 it feels like one of those last 90s XML “now you have two problems” jokes...

Frankly K8 reminds me more J2EE EJB 2.X. Horrific complexity that provides not that much after all.
Post reply on HN