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

Kubernetes 1.18

kubernetes.io

Post reply on HN
Print view View original

111–120 of 132 posts

Re: Kubernetes 1.18

#111

Post by ojhughes »

dx034 wrote: post #95
ojhughes wrote: post #56

Earlier quoted context omitted.

This false information really needs to die. k8s is a sane choice in many cases not just hyper scale. Regular business apps benefit from rolling upgrades and load balancing between replicas. Managed k8s platforms like GKE make cluster management a breeze. Developer tooling such as Skaffold makes developing with k8s seamless. I expect k8s to continue growing and will soon take over much of the existing Cloud Foundry es…

Running k8s is much harder and takes more time than just having a few VMs with docker on it. Many applications never need to scale. I really like k8s from a user perspective but it's no easy task to set up. And managed solutions don't always work for everyone (and aren't always cost efficient).

Most companies will have an Ops team to manage the prod clusters

Re: Kubernetes 1.18

#112

Post by ojhughes »

lprd wrote: post #110

I've taken a couple k8s courses, I understand all the small parts that make up k8s, but yet it seems that there are still no easy solutions to install on bare metal. The default recommendation is to always just roll with a managed solution. This is slightly irritating considering there are plently of companies out there who own their own infrastructure. There are plenty of great developer distributions out there (k3s…

k3s supports multinode

Re: Kubernetes 1.18

#113

Post by ithkuil »

dx034 wrote: post #95
ojhughes wrote: post #56

Earlier quoted context omitted.

This false information really needs to die. k8s is a sane choice in many cases not just hyper scale. Regular business apps benefit from rolling upgrades and load balancing between replicas. Managed k8s platforms like GKE make cluster management a breeze. Developer tooling such as Skaffold makes developing with k8s seamless. I expect k8s to continue growing and will soon take over much of the existing Cloud Foundry es…

Running k8s is much harder and takes more time than just having a few VMs with docker on it. Many applications never need to scale. I really like k8s from a user perspective but it's no easy task to set up. And managed solutions don't always work for everyone (and aren't always cost efficient).

If you run the whole thing (app + k8s) then I do agree with you that it's more complex and you're likely be better off without it.

But, k8s offers a very good way to split the responsibility of managing the infrastructure and managing the applications that run on top. Many people work in medium to big corporations that have a bunch of people that are in charge of managing the compute infrastructure.

I certainly prefer k8s as an API between me and the infrastructure, as opposed to filing tickets and/or using some ad-hoc and often in-house automation that lets me deploy my stuff in a way that is acceptable for the "infrastructure guys".

Re: Kubernetes 1.18

#114

Post by lprd »

ojhughes wrote: post #112
lprd wrote: post #110

I've taken a couple k8s courses, I understand all the small parts that make up k8s, but yet it seems that there are still no easy solutions to install on bare metal. The default recommendation is to always just roll with a managed solution. This is slightly irritating considering there are plently of companies out there who own their own infrastructure. There are plenty of great developer distributions out there (k3s…

k3s supports multinode

Ah, I wasn't aware. Does it support HA as well?

Re: Kubernetes 1.18

#115

Post by throwaway894345 »

coredog64 wrote: post #109
throwaway894345 wrote: post #105

Earlier quoted context omitted.

> It's the exact opposite. I don't think that's stuff should be abstracted away. Why not? The Kubernetes/serverless/DevOps people have a compelling argument--organizations can move faster when dev teams don't have to coordinate with an ops/sysadmin function to get anything done. If the ops/sysadmin/whatever team instead manages a Kubernetes cluster and devs can simply be self-service users of that cluster, then they…

One of the things I see ignored in these discussions is the strategic timeline. Yes, dev teams can yeet out software like crazy without an ops team. But eventually you build up this giant mass of software the dev team is responsible for. Ops was never involved until one day the mgmt chain for the dev team realizes he can free up a bunch of capacity by dumping his responsibilities onto ops. IMO, some of these practice…

I might be misunderstanding you, but this line makes me think you misunderstood the k8s/serverless/devops argument:

> your tiny DevOps team is spending 80% of their time managing a huge portfolio of small apps

In a DevOps world (the theory goes), the DevOps team supports the core infrastructure (k8s, in this case) while the dev teams own the CI pipelines, deployment, monitoring, etc. The dev teams operate their own applications (hence DevOps), the "DevOps team" just provides a platform that facilitates this model--basically tech like k8s, serverless, docker, etc free dev teams from needing to manage VMs (bin packing applications into VM images, configuring SSH, process management, centralized logging, monitoring, etc) and having the sysadmin skillset required to do so well [^1]. You can disagree with the theory if you like, but your comment didn't seem to be addressing the theory (sincere apologies and please correct me if I misunderstood your argument).

[^1] Someone will inevitably try to make the argument that appdevs should have to learn to "do it right" and learn the sysadmin skillset, but such sysadmin/appdev employees are rare/expensive and it's cheaper to have a few of them who can build out kubernetes solutions that the rest of the non-sysadmin appdevs can use much more readily.

Re: Kubernetes 1.18

#116

Post by gnaritas »

tedk-42 wrote: post #89
gnaritas wrote: post #72

Earlier quoted context omitted.

> we really must appreciate that Kubernetes really is the future of infrastructure No, it isn't. It's extra complexity most don't need.

Oh yeah? How are you (or your company) running their applications?

The way apps have always been run, directly on the server with no intermediate magic layer trying to abstract away running on a server. Deployment and rollback, simple git, centralized logging, good old syslog, load balancing it all, haproxy. No fuss, no muss, simple and straight forward with no magic required.

Re: Kubernetes 1.18

#117

Post by dilyevsky »

rumanator wrote: post #80
dilyevsky wrote: post #49

Earlier quoted context omitted.

1. It makes no sense to quota your cpu with the exception of very specific cases (like metered usage). You’re just throwing away compute cycles 2. Same applies to dedicate cores for pretty much same reasons Having said that if you really really want quota but don’t want shit tail latency I suggest setting cfs_quota_period to under 5ms via kubelet flag

> It makes no sense to quota your cpu with the exception of very specific cases (like metered usage). This is not true at all. Autoscaling depends on CPU quotas. More importantly, if you want to keep your application running well without getting chatty neighbors or getting your containers redeployed around for no apparent reason, you need to cover all resources with quotas.

Autoscaling depends on requests not limits. Read my explanation on “chatty neighbors” in other thread.

Re: Kubernetes 1.18

#118

Post by dilyevsky »

EdSchouten wrote: post #107
pluies wrote: post #99

Earlier quoted context omitted.

Agree re noisy neighbours, but autoscaling depends on _requests_ rather than _limits_, so you could define requests for HPA scaling but leave out the limits and have both autoscaling and no throttling.

The problem with having no throttling is that the system will just keep on running happily, until you get to the point where resources become more limited. You will not get any early feedback that your system is constantly underprovisioned. Try doing this on a multi-tenant cluster, where new pods spawned by other teams/people come and go constantly. You won't be able to get any reliable performance characteristics in…

And how will you get feedback on being throttled other than shit is randomly failing e.g connection timeouts?
Post reply on HN