Hacker News new | ask | show | jobs
by reacharavindh 2426 days ago
I’ve been trying hard to find time to setup and play with a Kubernetes cluster for learning purposes.

Considering it is built with Go, why is such a aggregation playbook needed? Shouldn't this be the default documentation of Kubernetes?

Do the following to use Kubernetes for what it is meant for! If you want to simply run containers in 1-5 machines - may be look at Docker/Podman + Ansible instead?

HA for controller,

Software defined networking,

Autoscaling pods,

Deployment policies,

Auto discovering DNS

Disaster recovery etc.

If these are not what you _need_, then looking at Kubernetes is probably not smart right?
2 comments
ownagefool 2426 days ago
None of these things are really needs but lets take a look at the bigger picture of what you do want.

You want well tested software?

kubectl create namespace pr-12-fix-banner-clipping

helm upgrade --install --wait --set url=pr-12-fix-banner-clipping.example.com pr-12-fix-banner-clipping . --namespace pr-12-fix-banner-clipping

./end2end --url https://pr-12-fix-banner-clipping.example.com

helm delete --purge pr-12-fix-banner-clipping

kubectl delete namespace pr-12-fix-banner-clipping

This assumes infrastructure as code, production like environments, ephemeral compute, etc. It's one of the easiest ways to achieve this and it's available anywhere.

You also don't want something like software defined networking. You want the ability for services to talk to each other, and firewalling at the service level, and when you throw multiple services on shared infrastructure together, the SDN helps you do this.

When you add it altogether, pretty much everyone wants all this stuff if they're going to deliver services at a professional level, but its obviously not the only way to do it, and most people don't want to be working at the kubernetes abstraction level.

link
researchiteng 2426 days ago
what you are looking for is called kubeadm, which is an official CNCF project, in go. BUT: 1. kubeadm won't change your kernel params, or docker or anything on your hosts. It expects someone took care of it (and according to their docs). And that's how we started. 2. your list of features: it's not one size fits all. Not everyone wants the overhead of _all_ of these, and not all developed under CNCF. Therefore one needs the post cluster deploy steps, with these things. Also, things like DNS, HA does depend on your infrastructure (it's where things get hard). E.g. We tried to solve HA on prem by using keepalived.
link