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

71–80 of 132 posts

Re: Kubernetes 1.18

#71

Post by chrizel »

stevepike wrote: post #27
threatofrain wrote: post #17

Anyone have a recommended guide for Kubernetes?

I don't know if it's updated for more recent versions, but I read "Kubernetes: Up and running" last year and it was excellent. It covers the motivations behind some of the decisions which helped things click for me.

Also read this book last month and it gave me a nice overview. But when doing all the examples you notice, that even with the updated second edition from the end of 2019, many of them are outdated. Not a big problem to solve, just small differences, but then you realize that Kubernetes is a fast moving target. A book about technology will always have this problem, but the K8s space seems to move especially fast currently.

Now I’m also more leaning towards the official docs as a recommendation, because they should always be more up to date... nevertheless, “Kubernetes: Up and Running” took my fear off this (at first) complex architecture. In the end, K8s is not that difficult to understand and the involved building blocks make sense, after you get the hang of it.

By the way, Microsoft is giving away “Kubernetes: Up and Running” second edition for free currently: https://azure.microsoft.com/en-us/resources/kubernetes-up-an...

Re: Kubernetes 1.18

#72

Post by gnaritas »

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…

> we really must appreciate that Kubernetes really is the future of infrastructure

No, it isn't. It's extra complexity most don't need.

Re: Kubernetes 1.18

#73

Post by Legogris »

Legogris wrote: post #62
merb wrote: post #23

Earlier quoted context omitted.

which is way more complex to setup than k3s

When was the last time you used it? I found it straightforward and not so many knobs to twist. ACLs and cert management can be a bit of a PITA the first time (especially the former, and it’s something you really want to do before you’re replying on Consul for mission-critical stuff), but that’s about it. Still, those two things are mainly confusing due to poor documentation and not that complicated once you get up to…

Downvoters: Care to elaborate what you think is wrong with my comment?

Re: Kubernetes 1.18

#74

Post by MrBuddyCasino »

hodgesrm wrote: post #67
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.

A lot of people think of multi-cloud as some kind of arbitrage where you jump quickly between markets. Running applications in cloud environments is a lot more like leasing property. Once you set up there are costs to moving. The portability argument boils down to saying you are not boxed in. If things get bad enough you can move. This is a big long-term advantage for businesses because it means you can correct mista…

It also leads to nullifying the advantages of the cloud. The whole point are the proprietary services they offer, and use those instead of building them yourself. Trying to be „cloud agnostic“ is one of the biggest mistakes one could make.

Re: Kubernetes 1.18

#75

Post by alpb »

gtaylor wrote: post #70
alpb wrote: post #30

Earlier quoted context omitted.

Not really, no. Cloud Run implements the Knative API, so you can actually take it away and run it on any Kubernetes cluster anywhere on a cloud or in your datacenter.

Doesn't that require Istio and a few other things as well? I wouldn't wish Istio configuration and maintenance on anyone but the larger shops/teams. You might not be technically locked in, but not everyone can afford to dedicate the attention to tuning and maintaining Istio. Source: at mid-sized company who has Istio in the stack.

Knative just needs a gateway (LB); not a full mesh. Istio is the default option. Alternatively you can use Gloo, Ambassador or something specifically built for Knative such as Kourier.

Re: Kubernetes 1.18

#76

Post by closeparen »

MrBuddyCasino wrote: post #74
hodgesrm wrote: post #67

Earlier quoted context omitted.

A lot of people think of multi-cloud as some kind of arbitrage where you jump quickly between markets. Running applications in cloud environments is a lot more like leasing property. Once you set up there are costs to moving. The portability argument boils down to saying you are not boxed in. If things get bad enough you can move. This is a big long-term advantage for businesses because it means you can correct mista…

It also leads to nullifying the advantages of the cloud. The whole point are the proprietary services they offer, and use those instead of building them yourself. Trying to be „cloud agnostic“ is one of the biggest mistakes one could make.

You're deploying to clusters of x86 machines in the first place because people in the 90s realized they were a little too into the proprietary APIs of their big iron vendors.

Re: Kubernetes 1.18

#77

Post by bg24 »

yahyaheee wrote: post #16
alpb wrote: post #6

Earlier quoted context omitted.

Google Cloud Run, AWS Fargate, Google App Engine, Heroku etc. are comparable experiences to Kubernetes if you have the flexibility of (1) running on cloud (2) not having to configure host OS or rely on host GPUs etc. Disclaimer: I work at Google Cloud Run.

You have vendor lock-in with all of these though

Vendor lock-in does not come from using GKE/EKS/AKS or derivatives.

What ends up happening is that your application consumes services (storage, analytics, etc.). You start using those services from the cloud provider, which makes sense as long as it is the right thing for your business (aligns w/ your cloud-native blueprint).

Kubernetes, by itself, is cloud-provider agnostic.

Re: Kubernetes 1.18

#78

Post by rumanator »

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…

> K8S doesn't eliminate the workflow for "deployments, upgrades, monitoring, etc.." it just black boxes them.

Kubernetes does not black box anything. At most it abstracts the computer cluster comprised of heterogeneous COTS computers, as well as the heterogeneous networks they communicate over and the OS they run on.

I'm starting to believe that the bulk of the criticism directed at Kubernetes is made up by arrogant developers who look at a sysadmin job, fail to undertand or value it, and proceed to try to pin the blame on a tool just because their ubriss doesn't allow them to acknowledge they are not competent in a different domain. After all, if they are unable to get containerized applications to deploy, configure, and run on a cluster of COTS hardware communicating over a software-defined network abstracting both intra and internet then of course the tool is the problem.

Re: Kubernetes 1.18

#80

Post by rumanator »

dilyevsky wrote: post #49
eric_khun wrote: post #48

Anyone solved properly the CPU Throttling issues they are seeing with kubernetes ? Is this release solved it? We are seeing a lot of throttling on every deployments, what impact our latency, even when setting a really high cpu limit. The solutions seems to be: - remove the limit completely. Not a fan of this one since we really don't want a service going over a given limit... - using the static management cpu policy…

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.

Post reply on HN