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.
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
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
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
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
Above you’ll see that I have an
nginx service running.
mapping port 32123 on my machine to 8888, on which
$ 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" "-"
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