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

71–80 of 80 posts

Re: Kubernetes 1.16

#71

Post by bt848 »

rumanator wrote: post #57
jeffdavis wrote: post #15

Earlier quoted context omitted.

"But a resource and its endpoint can be thought of as the same thing, in that the endpoint is the resource's canonical URI." After reading your description, "a resource is an endpoint" still seems wrong. Perhaps just lazy, but laziness in technical docs gets confusing fast.

It's not laziness at all. It's the project's Ubiquitous Language, which helps refer to concepts objectively and free from ambiguities. You're complaining because you are not familiar with Kubernetes, and thus you are not the target audience. Do keep in mind you're reading the release notes of a minor release.

With respect I disagree and my objection is that this verbiage is ambiguous and imprecise, the opposite of a ubiquitous domain language. Why does the “declarative API” allow one to “declare or specify”? Which is it? Is there meaning in the clause “or specify”, or is it a superfluous verbal tic? If the API is declarative why is it called a Definition? Declaration and definition are well-used terms of art in our industry but they are not synonymous. And what about “tries to keep them in sync”? Tried by what means? Are they eventually synchronized or not?

Re: Kubernetes 1.16

#72

Post by rmetzler »

sergiotapia wrote: post #10

We're moving away from Kubernetes because managing even a simple implementation is a full-time job. Obviously Kubernetes is meant for enterprises, but I've seen seed round/series A startups with a small engineering team using it. We were at a crossroad. Either we hire an SRE that has extensive kubernetes experience for $130K/year or we move to a managed platform until we actually need those capabilities. We're happy…

Don’t do Kubernetes or any other container orchestration when you don’t have CI/CD in place yet. I really think this is meant to work in tandem and changing Kubernetes YAML on a developer laptop can blow up fast.

Re: Kubernetes 1.16

#73

Post by atombender »

dejj wrote: post #46
atombender wrote: post #28

Earlier quoted context omitted.

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.

It's replacing one thing with something else, but the management overhead on GKE is significantly less.

I've also managed a built-from-ground-up Kubernetes cluster. It's not rocket science. That said, I wouldn't do it in a company without a dedicated ops person.

Re: Kubernetes 1.16

#74

Post by hinkley »

imtringued wrote: post #66
hinkley wrote: post #62

Earlier quoted context omitted.

What the actual fuck.

Cartoon giraffes in general look very disturbing to me. Generally the length of the neck and legs are about the same but somehow every cartoon giraffe has amputated legs.

The horse with dwarfism and hightops is making me uncomfortable. But the gopher will haunt my dreams.

Re: Kubernetes 1.16

#75

Post by zeeZ »

wereHamster wrote: post #49
zeeZ wrote: post #47

Earlier quoted context omitted.

> 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…

Sorry about that. Yeah I meant the old API groups that I still come across.

Re: Kubernetes 1.16

#76

Post by movedx »

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…

> My company has a ton of apps on multiple Kubernetes clusters, none of them very big. From my perspective, it's a huge win in operational simplicity over the "old" way. Docker itself is a benefit, but the true benefits come when you can treat your entire cluster as a virtualized resource and just throw containers and load balancers and persistent disks at it.

And I agree. However...

I'm referring to the companies and people who don't think like you do and instead think, "We need to build everything as a microservice and have it orchestrated on K8s". I'm thinking of the people who have a monolith that's scaling fine, solving a problem, and generating income, but an executive has been sold on K8s and now wants to refactor it.

Your use case makes perfect sense, but very few people are thinking like that, sadly.

In my opinion if you're starting out with Docker and K8s, you're going down the right path, but only provided you're not starting with microservices.

Like you said it's a tool and like with most tools there is a balance between over engineering its use.

Re: Kubernetes 1.16

#77

Post by atombender »

movedx wrote: post #76
atombender wrote: post #28

Earlier quoted context omitted.

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…

> My company has a ton of apps on multiple Kubernetes clusters, none of them very big. From my perspective, it's a huge win in operational simplicity over the "old" way. Docker itself is a benefit, but the true benefits come when you can treat your entire cluster as a virtualized resource and just throw containers and load balancers and persistent disks at it. And I agree. However... I'm referring to the companies an…

That sounds more like a criticism of microservices, which can definitely be overdone.

Re: Kubernetes 1.16

#78

Post by whotheffknows »

atombender wrote: post #14
bt848 wrote: post #4

I wish their tech writers would give us more English and less jargon. I pondered these release notes and the documentation earlier today and I still can't puzzle out why "custom resource" is initialized as "CRD". And the rest of this gibberish is just meaningless. """A resource is an endpoint in the Kubernetes API that stores a collection of API objects of a certain kind.""" OK, almost completely free of meaning ...…

It's not gibberish, though. A resource has an endpoint, i.e. a URL that represents its configuration and state. But a resource and its endpoint can be thought of as the same thing, in that the endpoint is the resource's canonical URI. Think REST/HATEOAS. A resource is any object that Kubernetes can track. They include objects like services, pods, nodes, ingresses and so on. Together resources form an API. A CRD is a…

Ok but ingress controllers don't talk to the kube-controller-manager though, so I wouldn't lump them in as a standard object. In fact k8s doesn't even have a standard ingress controller object.

Re: Kubernetes 1.16

#79

Post by whotheffknows »

I enjoy Kubernetes because it weeds me out from all the people who aren't used to actually having to read docs to understand the layered concepts of k8s as a networking model, of which there can me multiple opensource Implementations.

The opsys bros I know who are used to hacking together docker-composes that are more insecure than your grandmother's internet explorer browser in 30 seconds and calling themselves geniuses fail miserably when they are left to design construct and optimise secure kubernetes clusters and elegantly port a variety of full stack web applications in a coat efficient manner.

It requires planning and design. Just because you haven't invested hundreds of hours into reading the docs.and testing, and building k8s clusters for which the docs are incredibly useful...

Also "kind" represents the type of k8s object, like service or deployment. It's not ambiguous at all, it just requires reading to the third paragraph of "general Kubernetes concepts" in the Kubernetes docs to understand it.

Re: Kubernetes 1.16

#80

Post by whotheffknows »

bt848 wrote: post #4

I wish their tech writers would give us more English and less jargon. I pondered these release notes and the documentation earlier today and I still can't puzzle out why "custom resource" is initialized as "CRD". And the rest of this gibberish is just meaningless. """A resource is an endpoint in the Kubernetes API that stores a collection of API objects of a certain kind.""" OK, almost completely free of meaning ...…

I enjoy Kubernetes because it weeds me out from all the people who aren't used to actually having to read docs to understand the layered concepts of k8s as a networking model, of which there can be multiple opensource Implementations.

The opsys bros I know who are used to hacking together docker-composes that are more insecure than your grandmother's internet explorer browser in 30 seconds, slapping a json parsing logger on it and calling themselves geniuses fail miserably when they are left to design construct and optimise secure kubernetes clusters and elegantly port a variety of full stack web applications in a cost efficient manner.

It requires planning and design. Just because you haven't invested hundreds of hours into reading the docs and testing, and building k8s clusters for which the docs are incredibly useful doesn't mean you have to attack the verbage, just read the docs. If you can't do that then maybe your best investing your criticism into a domain of expertise you're actually knowledgeable and/or experienced in.

Also "kind" represents the type of k8s object, like service or deployment. It's not ambiguous at all, it just requires reading to the third paragraph of "general Kubernetes concepts" in the Kubernetes docs to understand it.

Post reply on HN