Live data from Hacker News

Kubernetes 1.18

kubernetes.io

81–90 of 132 posts

Re: Kubernetes 1.18

#81
post #11

Earlier quoted context omitted.

When I think about k8s complexity, I can only understand this argument if I'm the one dealing with the infrastructure required. If I have to install k8s in my servers, then I'll probably need to think hard about security, certificates, hardware failures, monitoring, alerting, etc. It's a lot of work. However, if I use a managed k8s service, I probably don't have to think about any of that. I can focus on the metrics…

Honestly getting a cluster running is the easiest part. It’s all the add one like istio that make it complicated.

> Honestly getting a cluster running is the easiest part. It’s all the add one like istio that make it complicated.

That's like saying running windows is the easy part, it's all the add-ons like Microsoft office that make it complicated.

Re: Kubernetes 1.18

#82
post #6

Earlier quoted context omitted.

What are recommendable simpler system examples, or managed options you allude to?

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.

Since you mentioned about CloudRun, I had one query.

I run docker compose locally for development. For prod, I just use a different docker compose file (with some values changed, for example the postgres database url etc.). I do this from a 5 USD per month droplet/vm. I can launch multiple services like this for my microservices platform. I can use a hosted database solution for another 15 USD per month, to get backups etc. Also I get a generous 1 TB bandwidth and predictable performance for my system as a whole.

In the past I have used appengine and been bitten by their update times (took more than 20 mins for a single code update, things could have improved now). Also I need to write deployment artifacts for each service.

Now is there any benefit that cloud run (or any paas) could offer compared to this ? Would it be not easier to just stay with docker-compose and defer upgrading to kubernetes until you turn profitable or become unmanageable with a single VM ?

Re: Kubernetes 1.18

#83

Reminder to everyone that unless you have a truly massive or complex system, you probably don’t need to run K8s, and will save yourself a ton of headaches avoiding it in favor of a more simple system or using a managed option.

Yeah, why would anyone with a simple system want an elegant way to declaratively describe the state of their runtime?

Re: Kubernetes 1.18

#84

Earlier quoted context omitted.

Not sure why this disclaimer has to be posted every time there's a discussion on K8s. It is a tool, if you need to use it, do use it. If not, don't. Although I would argue that you need to know what trade offs you are making if you have the right use-case (multiple containers you need to orchestrate, preferably across multiple machines) and you are not using it or a similar tool. There are lots of best-practices and…

I would stress the out-of-the-box support for blue-green deployments in a system that is fully versioned, thus supports rollbacks like a champ.

This is news to me, do you have any links to k8s's support for blue-green deploys?

I've been holding off setting up a system like Spinnaker because I'd read it was coming (in the form of custom deployment strategies), but can't find anything current on the subject.

Re: Kubernetes 1.18

#85

Anyone have a recommended guide for Kubernetes?

What would you like to learn about kubernetes? I'd be interested in helping. I don't have any knowledge in manually running a kubernetes cluster, BUT, if it's how to use it once you've spun up a managed kubernetes server, I'd be happy to help here (invitation open to others too). I'm not an expert by any means but I do work on our cluster at Buffer on a daily basis and can share knowledge I've acquired so far :) .

Re: Kubernetes 1.18

#86

Reminder to everyone that unless you have a truly massive or complex system, you probably don’t need to run K8s, and will save yourself a ton of headaches avoiding it in favor of a more simple system or using a managed option.

Not sure why this disclaimer has to be posted every time there's a discussion on K8s. It is a tool, if you need to use it, do use it. If not, don't. Although I would argue that you need to know what trade offs you are making if you have the right use-case (multiple containers you need to orchestrate, preferably across multiple machines) and you are not using it or a similar tool. There are lots of best-practices and…

I like the idea of kubernetes, and (some time ago) worked through a basic tutorial. My main confusion is how to set up a development environment. Are there any guides you could suggest that cover basic workflows?

Re: Kubernetes 1.18

#87

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.

I'd argue the whole point is actually the fact that you can lease CPU/Memory/space as you need it, and capacity constraints now become simple cash constraints. You don't need to shell out millions of dollars on a specialist enormous hardware just to be able to use it for an hour.

Lots of big companies that operate extensively in AWS/Azure/GCP don't go anywhere near the managed services they offer, because they end up being a horror show in terms of scalability, functionality and troubleshootability. Depending on your risk appetite, running Kafka on Fargate/EC2 is a lot more attractive than using Kinesis (for example).

Re: Kubernetes 1.18

#88
post #86

Earlier quoted context omitted.

Not sure why this disclaimer has to be posted every time there's a discussion on K8s. It is a tool, if you need to use it, do use it. If not, don't. Although I would argue that you need to know what trade offs you are making if you have the right use-case (multiple containers you need to orchestrate, preferably across multiple machines) and you are not using it or a similar tool. There are lots of best-practices and…

I like the idea of kubernetes, and (some time ago) worked through a basic tutorial. My main confusion is how to set up a development environment. Are there any guides you could suggest that cover basic workflows?

Minikube is super easy to use, or k3s.

Re: Kubernetes 1.18

#89
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.

Oh yeah? How are you (or your company) running their applications?

Re: Kubernetes 1.18

#90

Earlier quoted context omitted.

I would stress the out-of-the-box support for blue-green deployments in a system that is fully versioned, thus supports rollbacks like a champ.

This is news to me, do you have any links to k8s's support for blue-green deploys? I've been holding off setting up a system like Spinnaker because I'd read it was coming (in the form of custom deployment strategies), but can't find anything current on the subject.

At the service level Kubernetes offers deployments

https://github.com/kubernetes/kubernetes/tree/master/pkg/con...

At an application level then the strategy consists of having two applications deployed and update the application's ingress after the deployment controller finishes updating the deployments.

Post reply on HN