Hacker News new | ask | show | jobs
by Kamshak 2390 days ago
There are for sure a few concepts you need to learn with k8s, however I wonder if it would be much shorter if you did a guide like this for manually done / bash script powered / ansible deployments
3 comments

Every other large-ish product I've maintained would have a chart at least this large. Complex systems are complicated to maintain, regardless of platform.
You've worked on complex systems with charts? Most places I've worked lack charts and documentation. The flow chart only exists in pieces of the people's heads still working there, the rest in employees who left.

That's one of the strengths with K8s, at least there is documentation, unlike a 1000 line perl script with no tests which does service discovery.

I said "would have a chart" not "had a chart". :-D Of course it wasn't properly documented. :-(

I fully agree on that being a major strength of k8s. Looking at the resource manifests gives a ton of insight into how a system is supposed to function.

I dunno, I did an install using the k8s install instructions, and got to a point where I could access the containers locally but not from other nodes in the cluster. I could see a bunch of routing and iptables rules, but I didn't have any model for what it SHOULD look like, so I was at a loss for untangling all that spaghetti.
Go through Kubernetes the Hard Way to get a low level grasp and once you understand what’s going on use a managed service.
that sounds like your pod-cidr, service-cidr, or network plugin are misconfigured. As another person said, going through the hard way could help you understand, but realistically you need to take some time to understand your network plugins config and the kubeadm flags for configuring cidrs.

I went through your problem before on a practice cluster and ended up giving up on that one.

Realistically the hard way doesn't actually explain much of the commands you're running, and much of it covers the tedium of getting the many many certs you need to bootstrap everything (which will then expire and not rotate automatically). It's much better to just use kubeadm, and take some time to read all the args to kubelet, kubeadm, kubeproxy, etc...

> manually done / bash script powered / ansible deployments

Sure but I am not comparing it against manually done / bash script powered / Ansible deployments. Even if I was the CI/CD pipeline would capture many of the problems early and than I have an immutable AMI with autoscaling groups that is very easy to debug, networking setup is super simple and load-balancing is also straightforward to troubleshoot. Cramming all of these into a simple project that is not as easy to debug is not worth the effort for us.