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

What we learned after a year on Kubernetes

about.gitlab.com

Post reply on HN
Print view View original

121–130 of 162 posts

Re: What we learned after a year on Kubernetes

#121

Post by kkapelon »

Traubenfuchs wrote: post #68
pjmlp wrote: 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…

>You still need dedicated devops people / a dedicated team.

Why is this surprising? You always need people to manage stuff. Was there any point where Kubernetes was advertised as a way to NOT have sys admins/devops?

Don't even get me started on "serverless"....

Re: What we learned after a year on Kubernetes

#122

Post by louwrentius »

smt88 wrote: post #76
Keycap wrote: post #72

Earlier quoted context omitted.

Why would you think it would go away? Its literaly the best option currently for what it is doing. It has an unprecedented support behind it as well. Multiply Vendors support it through a certificate k8s managed service. It solves really problems out ouf the box like load balancing, ingress, cert management, autoscaling, health checks, autorepair. It allows for simple IaaC. Is it young? Yes. Do we need more people wi…

"out of the box" is a huge stretch. So is "simple". > Is it young? Yes. Do we need more people with more expierence? yes. Of course this is a problem! It's costly (in time, money, and security) to pay your team to ramp up on Kubernetes. The question is, what is the actual benefit? 99% of companies don't need it at all.

I agree so much with your sentiment.

This is what will get lost on hn: 99.99% of companies don't need FAANG-level capabilities.

I bet that 80% of people moving to K8s just follow hype and don't even benefit in any netto positive way.

And it's probably 99% but I'm just too afraid to be wrong.

Re: What we learned after a year on Kubernetes

#123

Post by kkapelon »

pjmlp wrote: post #111
Keycap wrote: post #101

Earlier quoted context omitted.

Do you have any argument for it or is it a generic statement independent of anything? Because there have been other 'fads' still being strong today. Kubernetes solves real problems which have been hard for a long time. Its the first thing you, as an infrastructure team, want to have to be able to provide your teams a manageable environment for yourself. mesos, nomad, docker swarm and co. Developers don't want a VM an…

> ________ solves real problems which have been hard for a long time. Please replace with Ansible, Chef, Puppet, HP Vault, Solaris Zones, OpenMosix, Bewolf, Grid Computing, MTS, CORBA, JEE ..... An argument based on seeing hype come and go, sellig conferences, books, certifications, consulting, training, and naturally one selfs curriculum. Speaking of which, "Kubernetes Certified Application Developer (CKAD) with Tes…

So you are saying that Ansible, Chef and puppet are fads? That solve no real problems?

OpenMosix, Bewolf and Grid computing were mostly confined on research circles. I never saw them took off like K8s did.

So comparing K8s with OpenMosix is a bit unfair...

Re: What we learned after a year on Kubernetes

#124

Post by starfox64_ »

sippeangelo wrote: post #100
zelphirkalt wrote: post #49

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…

This. I'm currently trying to figure this mess out and all I want is a reference for the different objects and what parameters they take, or what the hell an "apiVersion" is and which ones are available. Instead their "documentation" is a bunch of unhelpful guides that never show examples of what I need to know. How this has reached widespread adoption is beyond me.

I find that the best place to have an actual documentation for writing yaml files is the API Reference[0] and falling back to the "regular" documentation for more detailed explanations about specific topics. The reference lists all properties and type for everything that you can shove in your yaml files.

[0] https://kubernetes.io/docs/reference/generated/kubernetes-ap...

Re: What we learned after a year on Kubernetes

#125

Post by ex_amazon_sde »

kkapelon wrote: post #118
ex_amazon_sde wrote: post #117

Earlier quoted context omitted.

I did, it's called Amazon. It does not need k8s or containers at all.

Great. So you also believe that Kubernetes is a fad and doesn't solve any problems for anybody and we should all stick with VMs?

I know what problems it solves, what problems it creates and how very expensive it is to learn, operate, optimize and debug.

Its features do not justify its complexity and the cost of operating it.

Re: What we learned after a year on Kubernetes

#126

Post by auspex »

secondcoming wrote: post #105
Keycap wrote: post #101

Earlier quoted context omitted.

Do you have any argument for it or is it a generic statement independent of anything? Because there have been other 'fads' still being strong today. Kubernetes solves real problems which have been hard for a long time. Its the first thing you, as an infrastructure team, want to have to be able to provide your teams a manageable environment for yourself. mesos, nomad, docker swarm and co. Developers don't want a VM an…

> Developers don't want a VM and you can't manage and maintain VMs if someone else is doing something with them. I want a VM because I want my dev environment to exactly replicate the production environment, down to the kernel. It also means that if I leave my employer I can just delete my VM on my personal machine. We've also not had any issues with maintaining production VMs, our release pipeline packages up our co…

Having the application run the same in dev as in production is one of the main selling features of a containerized environment.

Re: What we learned after a year on Kubernetes

#127

Post by auspex »

ChicagoDave wrote: post #95

My question. Why not convert the rails code/APIs to blob/FaaS and skip all the DevOps complexity? Are containers providing enough long-term cost-effectiveness to a complete cloud-native application architecture? Or is it just mapping VMs to something “like” VMs so your topology remains mostly the same?

Serverless has its own complexity. Deploying a smaller, lightweight purpose built image, with no orchestration lock-in is the main benefit.

Re: What we learned after a year on Kubernetes

#128

Post by kkapelon »

ishcheklein wrote: post #3

We are using k8s as well for a project that we also provide on-prem install too. We decided to use kustomize for now vs doing helm for now. Curious, have someone had experience with both to compare. What are the benefits of using helm?

Helm is a full package manager. Kustomize is just a templating mechanism.

They are not comparable.

For example, with Helm you can rollback applications to previous versions

Re: What we learned after a year on Kubernetes

#129

Post by kkapelon »

escardin wrote: post #28
creztoe wrote: post #14

Earlier quoted context omitted.

Could you explain why helm is garbage? I think it suits its purpose rather well without being too complex. You can essentially "plug-in" different types of resources rather easily. Especially in v3 now that you don't need to install Tiller and can avoid setting those cluster permission requirements. Have you tried some Kubernetes api libraries? You can generate and configure resources with [python kubernetes-client](…

I also think helm is terrible. Helm's stated goal is to be something of a package manager for apps in k8s, but this is fundamentally unworkable as shown by... Helm. It's hard to describe just how unworkable this idea is. Let's start with an example, you want to install an app (let's say Jira) and a DB backend of your choice, postgres or mysql. The first step where this all falls down is, it may or may not support you…

I understand your pain and can see where you are coming from.

But Helm is just a package manager and not a software delivery platform like you ask.

I mean do you have the same expectations from a Deb or RPM package?

If I give you a deb package that "contains" Jira, won't you have the exact same concerns?

Re: What we learned after a year on Kubernetes

#130

Post by secondcoming »

auspex wrote: post #126
secondcoming wrote: post #105

Earlier quoted context omitted.

> Developers don't want a VM and you can't manage and maintain VMs if someone else is doing something with them. I want a VM because I want my dev environment to exactly replicate the production environment, down to the kernel. It also means that if I leave my employer I can just delete my VM on my personal machine. We've also not had any issues with maintaining production VMs, our release pipeline packages up our co…

Having the application run the same in dev as in production is one of the main selling features of a containerized environment.

As far as I'm aware containers do not replace the kernel, only userland.
Post reply on HN