Kubernetes Basics for Everyday Devs

Mar 4, 2019 06:37 · 571 words · 3 minute read Kubernetes Tools Ops

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'.

That’s super cool, my cluster is apparently up! What’s running in it?

$ kubectl get all
NAME                                        READY     STATUS      RESTARTS   AGE
pod/tailored-macaw-nginx-6c7dcdb5f5-vglz6   1/1       Running     0          27d
pod/tailored-macaw-nginx-gmcm8              0/1       Completed   0          27d
NAME                           TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
service/kubernetes             ClusterIP   10.96.0.1        <none>        443/TCP          27d
service/tailored-macaw-nginx   NodePort    10.104.102.226   <none>        8888:32123/TCP   27d
NAME                                   DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/tailored-macaw-nginx   1         1         1            1           27d
NAME                                              DESIRED   CURRENT   READY     AGE
replicaset.apps/tailored-macaw-nginx-6c7dcdb5f5   1         1         1         27d
NAME                             DESIRED   SUCCESSFUL   AGE
job.batch/tailored-macaw-nginx   1         1            27d

Things! I have things! You’ll see that said things are split by “kinds of things”, which you can see by the “NAME” field’s portion before the /.

Above you’ll see that I have an nginx service running. k8s is mapping port 32123 on my machine to 8888, on which nginx is listening. See:

$ curl localhost:32123
<h1>Hello</h1> <p>This is a test</p>

And now for the logs! Taking the pod’s full name, and append it to kubectl logs. That’s it. No huge mystery there. You can even do kubectl logs -f to tail the logs!

$ kubectl logs tailored-macaw-nginx-6c7dcdb5f5-vglz6
192.168.65.3 - - [04/Mar/2019:12:01:45 +0000] "GET / HTTP/1.1" 200 36 "-" "curl/7.54.0" "-"
192.168.65.3 - - [04/Mar/2019:12:05:18 +0000] "GET / HTTP/1.1" 200 36 "-" "curl/7.54.0" "-"

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.