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

Kubernetes 1.16

kubernetes.io

Post reply on HN
Print view View original

41–50 of 80 posts

Re: Kubernetes 1.16

#41

Post by EdwardDiego »

vitalus wrote: post #23
sergiotapia wrote: post #19

Earlier quoted context omitted.

I'm saying we didn't have a problem that Kubernetes solved. A lot of seed-round/Series A startups also are quite simple, but hopping onto Kubernetes because it's "enterprise".

Adopting any piece of technology just because it's a fad or otherwise trendy is rarely a good justification. It sounds like the primary reason you're deciding to move away from it is because you don't face any of the problems that it's there to solve, rather than it being an operational burden.

To be fair, k8s imposes a large complexity load. So what it gives you has got to be worth the time your developers/devops/sysops will spend learning to work with it.

We're migrating to k8s, and it's fantastic for us, but we have a large complex system that we're moving into the cloud, which really benefits from k8s features - loving the horizontal pod autoscalers, especially when I can expose Kafka topic lag to them (via Prometheus) as a metric to scale certain apps on.

Re: Kubernetes 1.16

#42

Post by thenewnewguy »

EdwardDiego wrote: post #39
sergiotapia wrote: post #19

Earlier quoted context omitted.

I'm saying we didn't have a problem that Kubernetes solved. A lot of seed-round/Series A startups also are quite simple, but hopping onto Kubernetes because it's "enterprise".

Really disappointed in the people downvoting you for sharing your personal experiences.

"I had a bad experience with Kubernetes" isn't really relevant discussion on a post about a kubernetes release. It's already well known that kubernetes is used by companies all over that don't need it and don't benefit from it because of its popularity.

Re: Kubernetes 1.16

#43

Post by dward »

winrid wrote: post #34

So, do we expect Kubernetes to ever replace Borg?

An ecosystem has evolved around Borg. Custom hardware, kernel, schedulers, telemetry, atomic clocks, networking, security, management... have all evolved around Borg proper to meet the "enterprise" needs of one of the largest enterprises in the world. It has many niche (i.e. not generally useful) cababilites built to service hardware melting XXX megawatt applications like web indexing, gmail, colossus. Even if Kubernetes targeted this customer, Borg has a significant head start. At this point the Borg ecosystem is almost old enough to by cigarettes in Mountain View.

Re: Kubernetes 1.16

#44

Post by pbar »

atombender wrote: post #28
movedx wrote: post #27

Earlier quoted context omitted.

> Kubernetes is meant for enterprises Actually it's meant for virtually no one, because very few people have the problems it solves. Like AutoScaling Groups, Serverless, and Cloud its self, it's a tool that solves a pain point in a specific domain. About 0.001% of the business world have that problem. > We're happy with the move and the pressure relief is tremendous. I'll bet it was. I've convinced businesses to go i…

The "Kubernetes is only for Google-scale companies" meme needs to die. Kubernetes is a useful tool even if you have a single node . As a case in point: I just set up a small new app on GKE. Because I'm experienced with Kubernetes, within a few minutes I had my app (a React front-end written in TypeScript and a backend written in Go) running and receiving HTTPS traffic. I entered just a handful of shell commands to ge…

Agree totally. One win Kubernetes provides my current team has been the fact that it is the interface on top of a cloud with agnostic primitives, allowing for multi cloud scaling. There are a lot of primitives, and a lot of things to monitor to ensure a running cluster, but the complexity of the system is IMO overblown in the popular mind. Isn't the core tenant of SRE to have the stability of the system automated?

Re: Kubernetes 1.16

#45

Post by 9nGQluzmnq3M »

deepsun wrote: post #25
013a wrote: post #18

Earlier quoted context omitted.

There's a ton at play here. "Managed Kubernetes" really runs the spectrum between "one step above just installing it yourself on a bunch of VMs" and "I spend 1% of my time managing anything below the product." Each cloud provider exists somewhere different on this spectrum, with none of them being in quite the same location, and some of them have multiple different products which exist at different points. For exampl…

> The holy grail (for some companies) is really something like Azure AKS + Azure Container Instances. No instances to manage... Google Cloud have been having that since before it's being called Google Cloud -- I mean Google App Engine. It has all those features, and with its "Standard" environment you don't even need to build docker image.

Cloud Run is even closer. App Engine Standard requires you to use the sandbox, App Engine Flex is tied to VMs, but Cloud Run makes containers serverless:

https://cloud.google.com/run/

...and since it's based on Knative, it's portable-ish.

Re: Kubernetes 1.16

#46

Post by dejj »

atombender wrote: post #28
movedx wrote: post #27

Earlier quoted context omitted.

> Kubernetes is meant for enterprises Actually it's meant for virtually no one, because very few people have the problems it solves. Like AutoScaling Groups, Serverless, and Cloud its self, it's a tool that solves a pain point in a specific domain. About 0.001% of the business world have that problem. > We're happy with the move and the pressure relief is tremendous. I'll bet it was. I've convinced businesses to go i…

The "Kubernetes is only for Google-scale companies" meme needs to die. Kubernetes is a useful tool even if you have a single node . As a case in point: I just set up a small new app on GKE. Because I'm experienced with Kubernetes, within a few minutes I had my app (a React front-end written in TypeScript and a backend written in Go) running and receiving HTTPS traffic. I entered just a handful of shell commands to ge…

> It's a cluster with a single node, no resilience. But this is genuinely useful Can you elaborate? Sounds like replacing one kind of server management overhead with a new kind otherwise.

Re: Kubernetes 1.16

#47

Post by zeeZ »

jcastro wrote: post #20

Just a reminder to check out the API deprecations on 1.16: https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-...

> DaemonSet, Deployment, StatefulSet, and ReplicaSet (in the extensions/v1beta1 and apps/v1beta2 API groups)

That seems quite significant. I still come across those regularly.

Re: Kubernetes 1.16

#48

Post by MichaelMoser123 »

haimez wrote: post #38
MichaelMoser123 wrote: post #29

A question on endpoint slices:why dont they send patch updates? A patch is the delta that changes an object instance.

Because safe generalized PATCH operations require the client and server to agree on the immediately prior state and the order of application of patches to avoid creating “Frankenstates”. They’re not a good general purpose API building block.

The client could do a full list request when it starts to get the baseline and then listen for patch updates.

That would be kind of an operator in reverse.

Re: Kubernetes 1.16

#49

Post by wereHamster »

zeeZ wrote: post #47
jcastro wrote: post #20

Just a reminder to check out the API deprecations on 1.16: https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-...

> DaemonSet, Deployment, StatefulSet, and ReplicaSet (in the extensions/v1beta1 and apps/v1beta2 API groups) That seems quite significant. I still come across those regularly.

You gave me a heart attack. I thought they were deprecating Deployment, StatefulSet… But it's only the old API versions they are deprecating, not the features themselves…

Re: Kubernetes 1.16

#50

Post by ngrilly »

dward wrote: post #43
winrid wrote: post #34

So, do we expect Kubernetes to ever replace Borg?

An ecosystem has evolved around Borg. Custom hardware, kernel, schedulers, telemetry, atomic clocks, networking, security, management... have all evolved around Borg proper to meet the "enterprise" needs of one of the largest enterprises in the world. It has many niche (i.e. not generally useful) cababilites built to service hardware melting XXX megawatt applications like web indexing, gmail, colossus. Even if Kubern…

Custom hardware? What kind and how is it related to Borg?
Post reply on HN