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

131–140 of 162 posts

Re: What we learned after a year on Kubernetes

#131

Post by kkapelon »

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…

>We've also not had any issues with maintaining production VMs, ... If you need to roll back just deploy the previous VM image version. ...

We've also not had any issues with breeding horses....If I just need to go somewhere I just ride my horse...

I don't see any value in cars(k8s). They are complex (oil changes, fuel consumption etc...)

Re: What we learned after a year on Kubernetes

#132

Post by kkapelon »

secondcoming wrote: post #130
auspex wrote: post #126

Earlier quoted context omitted.

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.

This is of course important but only for people who actually need this guarantee.

Yes if you are developing C/C++/Assembly then Kubernetes/containers might not be for you.

But for several other companies (e.g. Java users) the kernel version is not important.

So we are back to same argument. Just because that you personally don't see value in something, doesn't mean that it is a fad.

Re: What we learned after a year on Kubernetes

#133

Post by pjmlp »

kkapelon wrote: post #123
pjmlp wrote: post #111

Earlier quoted context omitted.

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

I am saying that apparently they are not good enough for the Kubernetes generation.

Eventually there will come the post-Kubernetes generation and the cycle does yet another turn.

Re: What we learned after a year on Kubernetes

#134

Post by pjmlp »

kkapelon wrote: post #132
secondcoming wrote: post #130

Earlier quoted context omitted.

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

This is of course important but only for people who actually need this guarantee. Yes if you are developing C/C++/Assembly then Kubernetes/containers might not be for you. But for several other companies (e.g. Java users) the kernel version is not important. So we are back to same argument. Just because that you personally don't see value in something, doesn't mean that it is a fad.

Java users are doing just fine with application containers.

Re: What we learned after a year on Kubernetes

#135

Post by kkapelon »

pjmlp wrote: post #134
kkapelon wrote: post #132

Earlier quoted context omitted.

This is of course important but only for people who actually need this guarantee. Yes if you are developing C/C++/Assembly then Kubernetes/containers might not be for you. But for several other companies (e.g. Java users) the kernel version is not important. So we are back to same argument. Just because that you personally don't see value in something, doesn't mean that it is a fad.

Java users are doing just fine with application containers.

That is a whole different discussion. If by application container you mean Tomcat then maybe. But if you mean Weblogic or Oc4j or WebSphere then hell no :-)

Then maybe you agree that Kubernetes brought some advantages that until recently only Java devs enjoyed to the rest of the world (PHP, Python etc)?

Re: What we learned after a year on Kubernetes

#136

Post by crowquill »

nuker wrote: post #81
pjmlp wrote: post #54

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

> I learned not to use it and wait until the k8s fad goes away. Yup, pretty happy with our move from k8s to ECS. Almost there.

Another happy ECS user here. You get most of the benefits of Kubernetes, without a lot of its complexity and maintenance. Yes, it’s a proprietary service and all, but that’s not really an issue. The applications are already containerized and could be moved to any other vendor/tool with relatively low effort if you ever needed to.

Re: What we learned after a year on Kubernetes

#137

Post by secondcoming »

kkapelon wrote: post #132
secondcoming wrote: post #130

Earlier quoted context omitted.

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

This is of course important but only for people who actually need this guarantee. Yes if you are developing C/C++/Assembly then Kubernetes/containers might not be for you. But for several other companies (e.g. Java users) the kernel version is not important. So we are back to same argument. Just because that you personally don't see value in something, doesn't mean that it is a fad.

> Just because that you personally don't see value in something, doesn't mean that it is a fad

GP is the one who made blanket statement 'developers don't want a VM', not me.

Re: What we learned after a year on Kubernetes

#138

Post by pjmlp »

kkapelon wrote: post #135
pjmlp wrote: post #134

Earlier quoted context omitted.

Java users are doing just fine with application containers.

That is a whole different discussion. If by application container you mean Tomcat then maybe. But if you mean Weblogic or Oc4j or WebSphere then hell no :-) Then maybe you agree that Kubernetes brought some advantages that until recently only Java devs enjoyed to the rest of the world (PHP, Python etc)?

Yes I mean WebSphere.

Kubernetes is a kludge to solve problems that should be sorted out by the respective language communities.

Then there is the whole issue that interpreters without JIT/AOT should only be used for scripting.

Re: What we learned after a year on Kubernetes

#139

Post by cbushko »

pjmlp wrote: post #54

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

It must not fit your use case and that is ok.

Kubernetes is made for the people that have to run your systems and keep them operational (ops/devops). It makes our lives a billion times easier on two fronts. Disclaimer, I am referring to a managed solution like GKE, I can imagine running k8s on your own hardware would be harder.

Uptime & Stability: autoscaling, health checks, replacing nodes, restarting containers. These are all things that an Ops person does not have to worry about during day to day operations.

Visibility: This is the biggest thing for me. People hate CLIs but kubectl and it's standard commands (get, describe, etc) make my life so much easier as it allows me to quickly figure out why something is breaking. A typical troubleshooting session goes like:

- What customer are you looking at? (kubectl get namespaces) - What service is failing (kubectl get pods -> kubectl describe pod -> kubectl logs -f -c

and the error is often quite obvious.

This visibility is powerful and is something you can easily treat your developers to do on their own. Even though Ops owns the systems they do not have to be a black box to the Developers that use them.

Re: What we learned after a year on Kubernetes

#140

Post by nuker »

marinj wrote: post #98
nuker wrote: post #42

It reads like a press release, no gotchas, no complaints... https://k8s.af/

There are some complains that we can share, but honestly they are not really that fun to read. We are still early in our transition and one major complaint I have is about helm and lack of flexibility of it and operator being very flexible but a huge time sink. I think a lot of complaints we would usually have are reduced due to the fact that we use managed K8s with GKE. All other complaints I can think of are relate…

> complains that we can share, but honestly they are not really that fun to read.

"You are mistaken counselor" (c) The Descendants

Post reply on HN