Hacker News Reader

Comment by paxys | Hacker News Reader

This should be titled "Kubernetes API is so simple you can explore it with curl". Which is true. I really like the API consistency, clear resource schema, use of HTTP verbs and conventions, official SDKs and even the kubectl CLI.

However, behind this simple and intuitive API there is still a massively complex and mostly unintuitive system which cannot be reduced to "just make some curl calls and you are good to go". While it is easy to do things in Kubernetes, figuring out what to do and why to do it is anything but.

View on HN

I've been working in distributed systems for 20 years and k8s is the best yet. The docs are quite good: https://kubernetes.io/docs/home/ The community is growing and despite the Google connection, it's not dominated or controlled by them. Distributed systems are a huge problem space to learn and IMHO I think too many people get frustrated trying to learn all of that, on top of all the k8s tooling and conventions. There's no real shortcut other than getting in and building experience. K8s is by far the easiest system yet to do that--spin up a cluster with kind right now (https://kind.sigs.k8s.io/), it will take 5 minutes, and start playing with the learning tutorials: https://kubernetes.io/docs/tutorials/kubernetes-basics/

I think you’re both right. It is definitely the easiest and most intuitive distributed system, and it’s also difficult to understand how all the pieces fit together. Just getting a typical web app deployed requires a container for the app, a pod definition, a DB container, a stateful set, a persistent volume for DB and possibly app storage, a persistent volume claim, a service, an ingress, something like cert manager to to handle creating a cert and attaching it to the ingress, etc. It all makes sense when you’ve done it a few times but it can seem quite overbearing even to someone who’s a fan of docker-compose.

most of that is boilerplate and not actually anything difficult

I'm new to distributed systems and k8s was a long steep learning curve to even get something running. Unfortunately, most of what i've learnt is by running into "how can I do that" followed by intense googling, reading blogs, docs and stackoverflow. Its after i've spent hours getting it to work, that i now can start looking into why and how it works which are usually rabbit holes on their own.

I wish i could start with the concepts of distributed systems, play around in something meant for learning and then map that knowledge to the kubernetes world.

But nothing i could find was even remotely helpful. Most content around this originates in research or academia making it harder to apply and learn on real problems -- the way I'm used to learning.

When learning trying to learn k8s, I found that k3s was a great starting point.

Having the ingress controller already preconfigured meant it was much easier to get up and running with a deployment and service.

I’ve just started down this path and I agree. K3os makes setting up a cluster in a VM dead simple and from there it’s really easy to play around with. Especially using snapshots for the VM in case you break your cluster and need to revert.

> However, behind this simple and intuitive API there is still a massively complex and mostly unintuitive system

And that's a good thing! You can't expect such a complex use case to be resolved by something simple.

Having such an easy, consistent and coherent API to abstract away all that complexity is truly a godsend.

K8S on single node cluster, or hundreds of nodes, it just work the same. Moving from one company to another, you don't have to relearn everything. What works on your local kind cluster will most likely work on GKE.

What other system do that? And would that system be "simple"?

The API absolutely does not "abstract away all that complexity" though. Which is fine. Any massive distributed system like Kubernetes is either complex or useless.

My problem is that in today's "devops" world developers are more and more just expected to be familiar with Kubernetes as another tool in their belt. Speaking from experience at my own workspace, that is a recipe for disaster.

As long as the learning curve (which could be weeks or even months) is acknowledged and factored in, Kubernetes can be a very powerful weapon to wield.

I don't have the same experience.

At my previous job, the developers were only expected to provide a Docker image with a list of requirements to run it (volumes, environment, configuration). Then it was my job to write the Helm chart and CI/CD pipeline. It was also my job to teach the developers to be autonomous on that aspect.

I never got a job where developers were expected to know how to deal with (pre)production servers. Except maybe in startups where everyone is expected to do everything because you never got enough people with the right skill.

I even got a developer in my team who didn't even know that Kubernetes existed while the company was migrating from on-premise to Kubernetes (and probably still does not).

Ok, we've changed the title to be about the API.

Kubectl get, edit, delete and describe work roughly the same way on every object type. If that's a service, pod, deployment, or cronjob, once you know the verbs you can interact with all of them.

Every object has a kind, metadata, and spec.

If that doesn't lead to some intuition on how to use it...

The complexity is in what is a service, pod, job, etc. not in the CRUD model. It's like describing driving a car as "the accelerator, brake, and clutch are all pedals; you press them to activate their functionality; pretty intuitive"

I would think a vehicle is a better analogy.

This car has tires, you create, delete and patch them. It also has an axels, gas tank, etc.

This truck has tires, axels, has tank

This motorcycle has tires, axels, etc

when the user simply wants to get from point A to point B - you give them API to deal with axles, pedals, tires, transmission, etc...

sounds like kubernetes?

Reply on news.ycombinator.com