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

91–100 of 132 posts

Re: Kubernetes 1.18

#91

Post by zeroxfe »

AndrewKemendo wrote: post #47
fosk wrote: post #20

Although I understand the fear that many have of being left behind the technology curve by not having the time - or the chance - to run Kubernetes in their day to day work, we really must appreciate that Kubernetes really is the future of infrastructure. For those that are looking at Kubernetes with suspicion, it is a natural instinct to think of K8s as a threat to all the knowledge we have built in the past few year…

I'm sorry but this reads like some mix of a sales pitch and religious preaching. K8S doesn't eliminate the workflow for "deployments, upgrades, monitoring, etc.." it just black boxes them. It also assumes out of the gate that everything needs to be able to do HA, scale for 1,000,000 instances/s etc... Over and over and over people show examples (I'm guilty too) of running internet scale applications on a single load…

> It also assumes out of the gate that everything needs to be able to do HA, scale for 1,000,000 instances/s etc...

k8s makes no assumptions about your workloads, it just gives you tools. And it's super useful even if you don't need to do HA or scale to a million instances.

Most production apps still need to manage deployments and rollbacks, configuration, security credentials, and a whole bunch of non-scale related things. And k8s makes a lot of that significantly more manageable.

Of course, this is overkill for a single application, but as you start adding more applications that need to be managed, the benefits really start to add up.

If you give something like GKE a chance, you might be pleasantly surprised. :-)

Re: Kubernetes 1.18

#92

Post by zwischenzug »

fosk wrote: post #20

Although I understand the fear that many have of being left behind the technology curve by not having the time - or the chance - to run Kubernetes in their day to day work, we really must appreciate that Kubernetes really is the future of infrastructure. For those that are looking at Kubernetes with suspicion, it is a natural instinct to think of K8s as a threat to all the knowledge we have built in the past few year…

I wrote a little about this here:

https://zwischenzugs.com/2019/03/25/aws-vs-k8s-is-the-new-wi...

Re: Kubernetes 1.18

#93

Post by Shish2k »

jarfil wrote: post #21
outworlder wrote: post #8

Earlier quoted context omitted.

Not sure why this disclaimer has to be posted every time there's a discussion on K8s. It is a tool, if you need to use it, do use it. If not, don't. Although I would argue that you need to know what trade offs you are making if you have the right use-case (multiple containers you need to orchestrate, preferably across multiple machines) and you are not using it or a similar tool. There are lots of best-practices and…

You can migrate docker deployments to K8s just by adding the parts you were missing, so when in doubt, it always makes sense to start with docker, docker-compose, and only consider K8s as an alternative to docker swarm.

I actually spent the past 3 days attempting to migrate my DIY “docker instances managed by systemd” setup to k8s, and found getting started to be a huge pain in the ass, eventually giving up when none of the CNIs seemed to work (my 3 physical hosts could ping each other and ping all the different service addresses, but containers couldn’t ping each other’s service addresses).

That said, if anyone REALLY wants to go the k8s route, it seems like starting with vanilla docker did allow me to get 75% of the work done before I needed to touch k8s itself :)

Re: Kubernetes 1.18

#94

Post by dx034 »

zwischenzug wrote: post #92
fosk wrote: post #20

Although I understand the fear that many have of being left behind the technology curve by not having the time - or the chance - to run Kubernetes in their day to day work, we really must appreciate that Kubernetes really is the future of infrastructure. For those that are looking at Kubernetes with suspicion, it is a natural instinct to think of K8s as a threat to all the knowledge we have built in the past few year…

I wrote a little about this here: https://zwischenzugs.com/2019/03/25/aws-vs-k8s-is-the-new-wi...

Nice post! But can you really compare AWS with k8s? With kubernetes, most companies still won't want to run it. They'll either use VMs or (where possible) a managed kubernetes. That's just one product for AWS. In the end, not everything will be k8s, you still need DNS, object storage, block storage, etc. I don't see why AWS couldn't thrive in a scenario where everyone uses k8s.

Quite the opposite. k8s isn't easy to set up, run or maintain. A large company running clusters with millions of nodes is probably more capable of letting it appear smooth than some small hoster with only a few servers.

Re: Kubernetes 1.18

#95

Post by dx034 »

ojhughes wrote: post #56
taywrobel wrote: post #2

Reminder to everyone that unless you have a truly massive or complex system, you probably don’t need to run K8s, and will save yourself a ton of headaches avoiding it in favor of a more simple system or using a managed option.

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

Re: Kubernetes 1.18

#96

Post by dx034 »

QUFB wrote: post #41

I've seen the cloud agnostic nature of Kuberbetes mentioned in many posts here. This is only true on the surface for a significant number of use cases and deployment models. Once petabytes of data are out there in your GCP or AWS environment, "portability" will be costly due to extortionistic pricing of egress bandwidth.

With petabytes you should either have a procurement team that gets a great deal or you should look at co-location. At some point, hiring a team of infrastructure experts is the cheap option, esp if you leave hardware management with data center providers.

And it's not mutually exclusive. I've seen companies working very cost efficiently by using dedicated hardware for 99% of the workload and AWS or GCP for any experiments where they wanted to try out new features.

Re: Kubernetes 1.18

#97

Post by dx034 »

thedance wrote: post #28
gbrayut wrote: post #26

Earlier quoted context omitted.

Kubernetes Deconstructed video https://vimeo.com/245778144/4d1d597c5e

I had to ragequit in the third minute. "A container is the filesystem inside your application." Just, no. This is exactly the kind of word salad approach to explaining k8s that I complained about in my other comment. All of the k8s tutorials are written by (or recorded by) people with no idea what they are talking about.

Honestly, please record a better one. It's true that most tutorials are very confusing and mix up terms. It's very hard to find good docs. If you have the time, please write something, I'm sure it'll be appreciated.

Re: Kubernetes 1.18

#98

Post by tete »

fosk wrote: post #20

Although I understand the fear that many have of being left behind the technology curve by not having the time - or the chance - to run Kubernetes in their day to day work, we really must appreciate that Kubernetes really is the future of infrastructure. For those that are looking at Kubernetes with suspicion, it is a natural instinct to think of K8s as a threat to all the knowledge we have built in the past few year…

I am making my money with Kubernetes and the ecosystem around it and I wholeheartedly disagree on K8s being the future.

However I do agree on vendor lock-in. At least to a degree. KVM and Xen didn't really prevent this for cloud environments.

I do think the main takeaway from a lot of this is the way software is designed. It is becoming more self-contained. Docker in many respects is like a static binary. FatJARs are a similar approach. Also Go in general seems to go that path.

What Kubernetes really does is providing an agreed upon standard for infrastructure, similar to what Docker gave for software packages.

They enabled concepts like Unikernels to at least become interesting, because they smoothed the way for the thinking of software that should be self-contained.

I think the future really is one where Kubernetes and Docker are just annoying overhead, where we find it odd how something "emulates" them, just how terminal emulators emulate... well, terminals.

We are in a feedback-loop where we put a more and more tight corset on the software we develop. First there were compute clouds, where developers learned it's bad to keep state around, then there was Docker, then Kubernetes where certain best practices, that have been best practices for a long time "forced" them to be followed more and more, especially because whoever provides your infrastructure and the developer are able to agree on the interface.

Docker and Kubernetes are standards due to their dominance, similar to Internet Explorer back in the days and Chrome today. As of now there is only minimal written specifications. Most of it is standardized by the implementation. Hopefully this will change some day to stabilize the interface and give opportunities for competing implementations, so more innovation can happen outside the boundaries of these projects, allowing for competition.

Maybe this has a positive influence on complexity as well.

Re: Kubernetes 1.18

#99

Post by pluies »

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.

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.
Post reply on HN