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

61–70 of 80 posts

Re: Kubernetes 1.16

#61

Post by rumanator »

sergiotapia wrote: post #19
kissgyorgy wrote: post #17

Earlier quoted context omitted.

I don't understand. You had a problem; you needed to run a distributed system with containers which Kubernetes is perfect for. Did your problem disappeared or did your requirement changed or did you change to a different container orchestrator tool?

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

> I'm saying we didn't have a problem that Kubernetes solved.

So why did you adopted a tool you had no use for to begin with? Sounds like poor judgement all around, from the adoption to the complains.

Re: Kubernetes 1.16

#63

Post by movedx »

pjmlp wrote: post #60
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…

You are being downvoted by the Kubernetes crowd, but you are quite right, it is the new NoSQL.

People realise their time has been wasted and their feelings are hurt as a result... oh well.

Re: Kubernetes 1.16

#64

Post by k__ »

ngrilly wrote: post #51
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…

Moving away to what?

Maybe a serverless stack?

Re: Kubernetes 1.16

#65

Post by znpy »

My biggest quarrel with kubernetes is that its API Reference often contains broken link to non-existing documentation page, usually pages that have been moved somewhere else (but who knows where?).

Re: Kubernetes 1.16

#66

Post by imtringued »

hinkley wrote: post #62
dankohn1 wrote: post #32

Earlier quoted context omitted.

That's Captain Kube. More info at https://phippy.io/

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.

Re: Kubernetes 1.16

#67

Post by bpicolo »

merb wrote: post #58
organsnyder wrote: post #11

Earlier quoted context omitted.

In my experience, Kubernetes is a lot of work to install and maintain. However, I've found managed offerings—especially ones like Azure that actually abstract away the complexity (Amazon exposes all the nitty-gritty, in my experience)—make it easy to use for even smaller shops. Of course, not every workload benefits from the features k8s provides.

did you ever looked at k3s? what is more difficult about k3s than managing ansible? what about kubespray? it's basically k8s managed via ansible? what makes it so difficult?

When folk want managed k8s, they effectively wanted something akin to a "serverless" compute pool that they point the k8s API at and worry about nothing else - not underlying hosts, networking configuration, storage, etc. The ideal is how close it gets to that. K3s still leaves hardware management to you.

Re: Kubernetes 1.16

#68

Post by merb »

bpicolo wrote: post #67
merb wrote: post #58

Earlier quoted context omitted.

did you ever looked at k3s? what is more difficult about k3s than managing ansible? what about kubespray? it's basically k8s managed via ansible? what makes it so difficult?

When folk want managed k8s, they effectively wanted something akin to a "serverless" compute pool that they point the k8s API at and worry about nothing else - not underlying hosts, networking configuration, storage, etc. The ideal is how close it gets to that. K3s still leaves hardware management to you.

ansible, etc, vm's, etc as well?!

Re: Kubernetes 1.16

#69

Post by organsnyder »

merb wrote: post #58
organsnyder wrote: post #11

Earlier quoted context omitted.

In my experience, Kubernetes is a lot of work to install and maintain. However, I've found managed offerings—especially ones like Azure that actually abstract away the complexity (Amazon exposes all the nitty-gritty, in my experience)—make it easy to use for even smaller shops. Of course, not every workload benefits from the features k8s provides.

did you ever looked at k3s? what is more difficult about k3s than managing ansible? what about kubespray? it's basically k8s managed via ansible? what makes it so difficult?

For work projects, I don't want to care about hardware—or "machines" of any sort, for that matter. Give me a ready-to-go platform with networking, storage, node management, etc. already configured. I don't even want to have to run scripts.

At home, I'm happy to play around with such things—and just might (I just purchased an old Dell server to take care of some home tasks and provide a sandbox environment). But at work I want to be as far away from the bare metal (physical machines or VMs) as possible.

Re: Kubernetes 1.16

#70

Post by rmetzler »

jeffdavis wrote: post #15
atombender wrote: post #14

Earlier quoted context omitted.

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…

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

Resource as in URI. What’s wrong about that?
Post reply on HN