Kubernetes Basics for Everyday Devs

Kubernetes is a big complicated scary beast. You’re now working for
a company that is on the bigger scale of things, so now you have
to deal with the big complicated scary beast. You just learned how
to whip up a Dockerfile, and you were provided a Helm chart (what
even is a Helm chart, you ask yourself in disbelief), so you didn’t
really need to worry about it, but now you’re on call and you need
to figure out why the frobulator service is all out of whack and
stuff.

First off, calm down, it’s all gonna be fine, it’s just a computer-thing,
you know computer-things, and this is one of them.

Now let’s see what’s up.

See cluster

First things first: DO YOU EVEN HAVE A CLUSTER TO TALK TO. If you
don’t, all of these efforts will be in vain. In my case, I’m running
on Docker for Mac, so I can install a Kubernetes cluster at the click of a mouse (and it also takes care of setting up my kubeconfig file)
so that I can access it by command line using kubectl (which we’ll
do for the rest of this episode). My battery life will drastically
decrease.

You can otherwise install Minikube. You’ll quickly
realize how complicated k8s really is when you see stuff like
this two jumps out of the Minikube homepage:

Before you begin

You must use a kubectl version that is within one minor version
difference of your cluster. For example, a v1.2 client should work
with v1.1, v1.2, and v1.3 master. Using the latest version of
kubectl helps avoid unforeseen issues.

See cluster run

If your cluster is set up correctly, you should be able to run
kubectl cluster-info.

Output on my computer is as follows:

$ kubectl cluster-info
Kubernetes master is running at https://localhost:6443
KubeDNS is running at https://localhost:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
To further debug and diagnose cluster problems, use 'kubectl
cluster-info dump'.

Parting notes

There’s many more things you can do with kubectl. One of my main
diagnosis tool is kubectl describe, which you can use to describe
some (or all) resources. I find it useful in diagnosing why my
deployment has entered a CrashLoopBackOff. Usually it’s because of
me.