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

Will Kubernetes Collapse Under the Weight of Its Complexity?

influxdata.com

Post reply on HN
Print view View original

201–210 of 213 posts

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#201

Post by jgr447 »

erikb wrote: post #128

Exactly what I'm always saying. It's also nearly impossible in an Enterprise IT environment to get Kubernetes working on your laptop. Minikube and Docker Edge both seem to fail way too often. As a developer one wants to spin up a system to work on, then work on it, then push results to some repo. And this loop simply isn't possible (yet?). Also what the author didn't mention is that even the vanilla k8s stuff is alre…

+1 on challenges in enterprise environments for local container-based development, this seems an unsolved problem for now

iterating on docker-compose might be easier/faster locally, then pushing to a dev k8s cluster for testing in ci/cd

curious if people are using k8s locally and why

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#202

Post by jgr447 »

bigdubs wrote: post #22

Kubernetes isn't supposed to be simple; it's supposed to be a box of tools that you pull from to represent literally any workload. Once you know what tools to ignore, and build scripts around the ones you need, it's very powerful. This line of thinking is like faulting the golang stdlib for having a lot of useful stuff in it.

> Kubernetes isn't supposed to be simple

Disagree, it's a tool designed to abstract away the complexity of deployment and operations, simplicity of use/management sound like should be a design goal.

It will probably get there but for now it's hard to disagree with the "complex" label.

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#203

Post by jgr447 »

hliyan wrote: post #79

This whole image, to me, represents a big problem with software engineering today: https://twitter.com/dankohn1/status/989956137603747840 The industry is full of engineers who are experts in weirdly named "technologies" (which are really just products and libraries) but have no idea how the actual technologies (e.g. TCP/IP, file systems, memory hierarchy etc.) work. I don't know what to think when I meet engineers wh…

Looking distractly it seems one of those "hot new javascript frameworks of the month" infographics.

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#204

Post by jgr447 »

Not having used it in any meaningful way, after a lot of reading I am sometimes still unclear with the value proposition.

The value imho could be in being able to package distributed applications and deploy across cloud providers or on prem, seamlessly.

I don't think this is true though short of doing a lot of effort to abstract access to a gcp/aws/azure managed service (say, a db), which is probably a bad idea.

If you take that away, then a lot of the replication, autoscaling, load balancing, failover etc. can be implemented using cloud providers without having to manage the complexity of k8s.

Hope to be proven wrong here.

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#205

Post by jgr447 »

hliyan wrote: post #79

This whole image, to me, represents a big problem with software engineering today: https://twitter.com/dankohn1/status/989956137603747840 The industry is full of engineers who are experts in weirdly named "technologies" (which are really just products and libraries) but have no idea how the actual technologies (e.g. TCP/IP, file systems, memory hierarchy etc.) work. I don't know what to think when I meet engineers wh…

Before rdbms became a commodity, companies would build them in house and required very specialized skills.

Then it became a commodity and now you can just use postgresql for a basic web app without knowing much about dbs.

Start adding scale and availability requirements in the mix, and you're back in need of specialized knowledge on indices, query planning, disk access patterns and db admin in general.

Same for cloud providers imho: you can throw an app online quicker than ever before, but as things get more complex you will still need an understanding of infrastructure, network, availability, security etc.

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#206

Post by xtracto »

hliyan wrote: post #141
zachlatta wrote: post #136

Earlier quoted context omitted.

We trust surgeons who proclaim expertise in specific named procedures. Whether we like it or not, software engineering is becoming a trade. Trades aren't inherently low skill or high skill.

Who are also heavily trained in the physiology of the organs they operate on, long before they're allowed anywhere near a scalpel. What you say about trades is true, but then we need to start making the distinction between software engineers and software technicians. I doubt that will go down well in an industry where everyone wants to be a senior software engineer, a tech lead or higher...

Interesting, in Mexico we do have that difference: We have got an "Informatics Technician" ( http://cecytev.edu.mx/wp-content/uploads/2012/03/Informatica... ) and Informatics Licenciate ( http://www.uabc.mx/formacionbasica/FichasPE/Lic_en_Informati... ) with all the flavours (Software Engineer, CompSci, etc).

I only wish that Informatics Technicial would be more prepared. And that Software Engineers/Licenciates would really be worth their salt.

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#207

Post by adrianratnapala »

tananaev wrote: post #90
hliyan wrote: post #79

This whole image, to me, represents a big problem with software engineering today: https://twitter.com/dankohn1/status/989956137603747840 The industry is full of engineers who are experts in weirdly named "technologies" (which are really just products and libraries) but have no idea how the actual technologies (e.g. TCP/IP, file systems, memory hierarchy etc.) work. I don't know what to think when I meet engineers wh…

I have a mixed feeling about this. On one hand I definitely agree that it's good to know lower level technologies and that's something I always ask people in the interviews. I think it's important because I know it. On the other hand there is no end on how low you can go in the technology stack. Do you need to know how sockets works underneath? Low level network protocols? Do you need to know how hardware works becau…

Why not go all the way down to device physics? It does harm.

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#208

Post by jakevn »

merb wrote: post #163
hliyan wrote: post #138

Earlier quoted context omitted.

We do have a hundred or so servers with multiple redundancies, but we've done okay without Kubernetes...

* what do you use to scale your databases * what do you use for master election * what do you use to deploy your stuff * what do you use on the tcp level for HA (keepalived?) * what do you use to keep your system up to date these would be my first questions about your system. and if you would use k8s all of them could be answered with "kubernetes"

Could you link to the k8s docs that does each of those?

Not trying to be snide, but so far I haven't found k8s to be much more than primitives with which to build those things.

I've also only begun working with it recently, so I do not have much experience, and any guidance would be much appreciated.

Re: Will Kubernetes Collapse Under the Weight of Its Complexity?

#210

Post by merb »

jakevn wrote: post #208
merb wrote: post #163

Earlier quoted context omitted.

* what do you use to scale your databases * what do you use for master election * what do you use to deploy your stuff * what do you use on the tcp level for HA (keepalived?) * what do you use to keep your system up to date these would be my first questions about your system. and if you would use k8s all of them could be answered with "kubernetes"

Could you link to the k8s docs that does each of those? Not trying to be snide, but so far I haven't found k8s to be much more than primitives with which to build those things. I've also only begun working with it recently, so I do not have much experience, and any guidance would be much appreciated.

well you actually should be a little bit more familiar with all the concepts of the system to do the stuff.

what do you use to scale your databases:

databases can be scaled with statefulsets there is a good library that helps with that: github.com/zalando/spilo it is actually way easier than scaling over vms (especially on bare metal) since 1.10 you can even use block storage with local storage, so no need for a storage system. so basically k8s is just a good layer to scale such things, before we used patroni without k8s and it is way harder to actually do service discovery (more on that later)

what do you use for master election:

master election can be done with configmap or endpoints (actually github.com/zalando/spilo uses github.com/zalando/patroni for running postgresql and does master election over endpoints or configmap annotations) actually etcd also exists when you use k8s (actually it's the hardest thing to install when you deploy k8s)

what do you use to deploy your stuff:

well deployment/apps are extremly easy to use and do zero downtime deployments when you just change your image version

what do you use on the tcp level for HA (keepalived?): some folks at google created metallb: https://metallb.universe.tf/ it's actually a load balancer on top of k8s that is so simple to use (just run https://metallb.universe.tf/tutorial/layer2/ and it will work)

what do you use to keep your system up to date: well that's more tricky however ContainerLinux (formerly CoreOS) (not related to k8s) works very well for keeping the os up to date. you can even use https://github.com/coreos/container-linux-update-operator to only update one node at the time in a k8s env. however it also works without k8s, but you still need to run mostly container software on ContainerLinux.

If you are new to k8s and want to know more about "easy" to use on bare-metal stuff you should look into ContainerLinux ignition and kubeadm, it's really simple to get up and running from scratch, it's mostly just creating a nice cloud-config and run kubeadm once on the nodes you wanna install.

Post reply on HN