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

21–30 of 80 posts

Re: Kubernetes 1.16

#21

Post by bproven »

organsnyder wrote: post #11
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…

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.

I agree on EKS,IMO is it an unfinished bare bones "managed" service. Upgrades of control plane and nodes is a royal PITA - very manual and error prone. In GKE it is literally 2 gcloud commands.

I think AWS hamstrings kubernetes still bc it is holding onto ECS. Hopefully they see the light soon, beef it up and make it equal to AKS/GKE. At least make masters/control plane free...ugh

Re: Kubernetes 1.16

#22

Post by manigandham »

013a wrote: post #18
manigandham wrote: post #13

Earlier quoted context omitted.

Why not just used managed Kubernetes? Every cloud vendor has it, even Tier 2 operators like DigitalOcean. Running Kubernetes is vastly different for using it to run your apps. You really shouldn’t do the former unless you have to be on-Prem or have some other need.

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…

GKE and AKS both require setting up instance types for node pool(s) but you don't need to worry about the OS and related issues on either. Both also support auto-scaling and auto-upgrades.

GKE is far more managed though with advanced features like global network, aliased IPs, global load-balancing, istio/traffic manager integration, private IPs, metrics-based-autoscaling, preemptible nodes, local SSDs, GPUs, TPUs, etc.

Azure Container Instances are nice, with the GCP corollary being Cloud Run using KNative. Both products are designed to quickly run a container image with a public endpoint, but ACI is not part of AKS. You might be thinking of the Azure Virtual Kubelet which lets you burst on-demand to ACI, but this is a very advanced use-case and not the normal cluster setup.

Re: Kubernetes 1.16

#23

Post by vitalus »

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

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.

Re: Kubernetes 1.16

#24

Post by manigandham »

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

It's really not "enterprise". It's because you have a resilient platform that provides automatic deployments, rolling upgrades, failover, auto-repair, logging, monitoring, storage/stateful data management, and more out of the box with a simple declarative YAML configuration.

Kubernetes can run a simple container with 1 line if that's all you need, or you can scale up to several different services with a few more files, all the way a massive deployment with thousands of containers. How you use it is up to you, but you do need to read and understand the basics.

However there's absolutely no need to run Kubernetes yourself unless you have a serious reason to. If you must, I highly recommend using something like Rancher [1] that can install and manage the cluster for you, even on cloud providers.

1. https://rancher.com/

Re: Kubernetes 1.16

#25

Post by deepsun »

013a wrote: post #18
manigandham wrote: post #13

Earlier quoted context omitted.

Why not just used managed Kubernetes? Every cloud vendor has it, even Tier 2 operators like DigitalOcean. Running Kubernetes is vastly different for using it to run your apps. You really shouldn’t do the former unless you have to be on-Prem or have some other need.

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.

Re: Kubernetes 1.16

#26

Post by bproven »

013a wrote: post #18
manigandham wrote: post #13

Earlier quoted context omitted.

Why not just used managed Kubernetes? Every cloud vendor has it, even Tier 2 operators like DigitalOcean. Running Kubernetes is vastly different for using it to run your apps. You really shouldn’t do the former unless you have to be on-Prem or have some other need.

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…

>For example: AWS is among the most bare-bones. EKS is just a managed control plane; coming from GKE, you might click "create an cluster" then be very confused how there are no options for, say, instance size, or how many... because you have to do that all yourself. There are tools like eksctl or Rancher which can help with this, but ultimately, you're managing those instances. You're doing capacity planning (you think kube would be a great pick to integrate with spot fleets because of its ability to schedule and move workloads to a new instance when one goes down? have fun setting it up, hope you like ops work.). You're doing auto-scaling (and that ASG? its not going to know about your pod resource requests, so you either need some very smart manual coordination between the two, or you need to set up cluster-autoscaler). You're setting up cluster metrics (definitely need metrics-server. not heapster, that was last year, metrics-server is this year. but how to visualize? do i host grafana in the cluster? then i need to worry about authn. cloudwatch really isn't made for these kinds of things... maybe I'll just give datadog a few thousand bucks.) Crap, 1.16 is out already? They only support 9 months of releases with security updates?! I feel like I just upgraded my nodes! Oh well, time to lose a day replicating this update across all of my environments.

Haha - I had to chuckle on this. It really is this bad on EKS. My god, upgrades are a total joke.

As bad as it is you have to believe that AWS seems to want to ignore Kubernetes and lock you in with ECS.

They need to get EKS as easy to manage as GKE and they need to provide free control plane/masters like all the other managed k8s services. Hopefully we see something at Re:invent this year... at this point there is no reason to use EKS unless you are trapped into AWS. Which unfortunately is what AWS is counting on :(

Re: Kubernetes 1.16

#27

Post by movedx »

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…

> 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 in the completely opposite direction to K8s. I've told them to developed a monolith before they start optimising into microservices. The startups that listened to me are still around and in round C. The others closed up shop ages ago (minus one of them) because they never got to market in time.

K8s is a tool. Docker is a tool. Cloud is a tool. Businesses have to utilise tools as efficiently as possible to get their solutions out the door if they're to survive. Using K8s from the ground up is a death sentence.

Re: Kubernetes 1.16

#28

Post by atombender »

movedx wrote: post #27
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…

> 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 get from an empty cluster to a functional one.

It's a cluster with a single node, no resilience. But this is genuinely useful, and a perfectly appropriate use case for Kubernetes. The alternative is the old way — VMs, perhaps with a sprinkling of Terraform and/or Salt/Ansible/Chef/Puppet, dealing with Linux, installing OS packages, controlling everything over SSH — or some high-level PaaS like AppEngine or Heroku.

While it's an example that shows that Kubernetes "scales down", I'm now also free to scale up. While today it's a small app with essentially zero traffic, when/if the need should arise, I can just expand the nodepool, add a horizontal pod autoscaler, let the cluster span multiple regions/zones, and so on, and I'll have something that can handle whatever is thrown at it.

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.

Re: Kubernetes 1.16

#30

Post by latch »

manigandham wrote: post #13
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…

Why not just used managed Kubernetes? Every cloud vendor has it, even Tier 2 operators like DigitalOcean. Running Kubernetes is vastly different for using it to run your apps. You really shouldn’t do the former unless you have to be on-Prem or have some other need.

What makes DO tier2?

I use 1 linode for personal stuff, but otherwise, I'm all in on dedicated baremetal. From my perspective, DO is just another cloud vendor.

Post reply on HN