Kubernetes the Easy Way | Hacker News Reader

Kubernetes the Easy Way

blogs.cisco.com

78 pointsalexellisuk26 comments

Every time (Before reading it) some article is published about 'the easy way' I hope it actually is an 'easy' 'way' but it often is neither; it's almost always "use this script" or "use this prepackaged version" and then turns to shit as soon as you actually need to use or maintain it because you'll still need knowledge and experience.

Until there is an 'easy way' to instantly get that knowledge and experience, it all just smells like PR and marketing to me..

In this specific case: k3s is not k8s, and setting up an empty system has very little to do with actual working systems. Yes, it allows some local sandboxing, but so does docker or running plain static compiled binaries on your system. You can have PaaS or FaaS but as soon as you need more than that you suddenly need to learn a bit more than what code to write for your specific app.

k3s is k8s compatible (though with sqlite rather than etcd, and no legacy features) though, no?

I swear 90% of k8s tutorial is "use this super long opaque bash script / helm chart" it's so easy!

kubernetes is complex and maybe not for all of us. i am starting to think, maybe we should leave operations to operation teams at this point and just be developers. i would be totally fine with it to be honest.

The trend has been to blur the lines between roles to get people that are just good enough at all the things to make it work. Hence back-end, front-end -> full stack and DevOps and DevSecOps roles (those weren't meant to be roles)

I don't know if it's a cost-saving measure, business optimization, or just straight ego.

I sort of agree, but beyond deploying, we need to understand how and what to write in order for our code to support scaling to N instances (including N=0), and knowing the target "platform" is a good way to do that.

Right. There are some cases when developers want Kubernetes because it is easy to deploy their application on it and autoscale it but in my experience, this is almost as easy with many other options that do not mean to pull in a giant black box dependency into your project. For those who think Kubernetes is not a black box, just wait for the first outage and measure the time how fast you can recover and what steps are involved. In my limited experience, it is much simpler to recover an autoscaling application on AWS or other cloud platforms that do not have Kubernetes. Why? Because there are significantly fewer things that can go wrong. Some people are ok to trade operational complexity for developer experience. I am fine with that.

> maybe we should leave operations to operation teams at this point and just be developers

The whole misconception about devops, imho, is that people mistakenly expect everybody to do everything: operations people writing code (have you seen code written by an operations engineer?) and developers maintaining services and infrastructure (have you seen an infrastructure designed/maintained by a developer?).

The whole point of devops is to enable ops and dev to collaborate. Articles about setting up kubernetes are mostly pointless. I've been there, and getting a cluster up in a basic way is as simple as pointless. The complexity is somewhere else.

People willing to advocate about kubernetes should assume a cluster is already running (developers who don't want to get into operations can either download minikube or get a managed instance off digitalocean, google cloud or amazon aws) and start from there, but teaching about the applicative side of k8s: how do I run my workload on a k8s cluster? How do I expose it? How do I get the scheduler and affinity/antiaffinity to work with me instead of agaist me ? How do I manage storage? How do I get traffic routed to my application? How do I observe my application ? How do I poke it with a stick when it's not working as expected?

It's fine not to know everything.

It's fine to read just enough to understand what's going on, but then letting someone else handle the problem.

This is the kind of technology that will die and be replaced by something easier and better one day.

Kubernetes is designed for this separation of duties.

Even the official certifications are separated into CKAD (Certified Kubernetes Application Developer) and CKA (Certified Kubernetes Administrator).

* https://www.cncf.io/certification/ckad/

* https://www.cncf.io/certification/cka/

> kubernetes is complex and maybe not for all of us

Couldn't disagree more. Kubernetes is extremely easy. I work mostly in frontend, and despise devops. Or used to. Until Kubernetes came along I had no way of easily creating a load-balanced scalable service.

First learn Docker. This is independent of Kubernetes. Docker is awesome in and of itself. In Azure you can deploy web sites as docker images and there are tremendous advantages to that over traditional deployment. Once you have learned Docker you are ready to learn Kubernetes.

If your app consists of multiple microservices then you have more than one docker container. This is where Kubernetes is helpful. Kubernetes has built-in DNS, so your microservices can contact each other using DNS names.

Learn how to deploy containers as Kubernetes ReplicaSets. Then learn how to add a Kubernetes Service on top of it, then learn how to add Ingress. None of this is hard.

Kubernetes is a pleasure to use, because of commands such as "kubectl exec" to log into the container, "kubectl log" to see the log without logging into the container, "kubectl cp" to copy files in and out, "kubectl port-forward" to make a service appear to be running on your devbox and so on.

So compared to docker-compose (which is strangely straightforward, but missing some pieces you'd want for scalable deployments) Kubernetes is more complicated. Or at least getting up to speed takes a fair bit longer.

I would not say Kubernetes is extremely easy. Running kubectl commands is easy. Setting up and building a cluster from scratch is not easy. You may have had an easier time, but I wouldn't label the whole process as easy.

You don't have to set up your own cluster if you use Azure or Google cloud. AWS charges for cluster management, but Azure and Google don't.

That means it isn't easy though. If you are piggybacking on someone else doing 90% of the work then you can only call their service including it easy, not the tech itself.

Anything that promise k8s the easy way is a click-bait, I'm a ML researcher and was promised that KubeFlow will help me deploy my models from my notebook with the infrastructure I needed...well it happens to be that we didn't have Kubernetes. I started with KubeFlow then K8s and then I got lost in all the terminology, which became a full time job, not as ML researcher but as DevOps. K8s is powerful but for my use case is a non-starter: maintain all the components+infra and don't talk about day 2 operations because I would have no idea where to start if something fails. I will definitely prefer Sagemaker or Cloud ML engine, and if get the budget maybe hire a k8s expert to handle that

Shameless self-plug, but have you looked at Cortex? It deploys trained models as APIs and automates the underlying devops. It's also free and open source.

GitHub: https://github.com/cortexlabs/cortex

Thanks this looks promising will take a look

Minor clarification, knowing K8s is not DevOps. You were boarding a hype train that is fueled by many parties and just needed to realize that it is going in the wrong direction. Luckily you got off on time there are higher abstractions for ML as you pointed out, which you can use with less time investment.

Thanks, k8s would be Infrastructure I guess?

Kubernetes articles are just marketing drivel. Most serious engineers I know dont use it because it is insecure, performance sucks and it is overly complex for no good reason.

I wish we could start marking these as spam.

We downweighted this one as unubstantive.

If you feel that an article isn't intellectually interesting and therefore isn't on topic for HN, you should flag it. (That requires karma > 30, but it isn't hard to get here.)

Oh yeah, I'm going to download a script from a website I've never heard of and pipe it into shell without review.

Even if 99 percent of the time nothing benign is happening, why get people used to doing this?

Global domination?

Where I work, while kubernetes isn't blissful, integrating everything else with it is where the work really starts.

Kubernetes the easy way is just the long way of saying "Rancher."

Reply on news.ycombinator.com