Brain dump of various kubernetes/kubectl things before I forget them all. I’m coming from the deploying analytics side, not the person who sets up kubernetes side, so this will be a list of useful day 1 type stuff for anyone who is learning kubernetes practically via deployments and kubectl.

Understand

• service - something with an IP/hostname you want to hit, e.g. a RESTful front end.
• deployment - powers a service by specifying things like number of instances, and how ports are shuffled.
• pods - basic atomic-ish unit that make up a deployment. An instance.

Suppose you want to stand up your RESTful analytic with 8 instances, available at foo.internal.com. Start with a service, then a deployment. Pods come via the deployment.

kubectl

pacman -S kubectl

Get config file from ops-type person. Put or link in ~/.kube/config, then

kubectl config show

to make sure you’re running with the correct one.

Change contexts, if needed, for various projects.

Basic commands

Pods

kubectl get pods
kubectl delete pod ...

You can delete a pod to have K8s immediately kick another one off, useful for getting info about why things aren’t working

Logs

kubectl logs pod-name
kubectl logs pod-name --previous

Get logs, or see why app crashed before via --previous. Anything else, you probably need some log aggregation service (Helm/fluentd?)

Services

kubectl deploy -f ./service.yaml
kubectl get services

Deploy services, which are sort of the interface between pods/containers and the rest of the cluster (and outside world).

Deployments

kubectl deploy -f ./deployment.yaml
kubectl delete deployment your-deployment

Deployments power services by specifying instances and memory, ports, docker images, etc.

Interaction outside cluster

kubectl port-forward services/your-service 8080:8080

Test whether or not your API/service/deployments actually work.

Next up: how Terraform does all this for you.

Here is the most important thing that all, new and old *nix/BSD admins should know about administering a machine remotely:

Always run any important administrative operations in a screen session.

Always run any important administrative operations in a screen session.

Always run any important administrative operations in a screen session.

You’re bound to lose internet at the most critical time.

Like when your BSD shell is sitting in vi waiting for you to manually merge in some changes.

Or when you’re arch package upgrades happen to make a destructive change that requires confirmation, but you weren’t paying attention.

Or you’re 4 hours into a huge build and the coffee shop is closing.

Get in the habit of doing screen -D -R any time you log in remotely and want to do administrative work. Put it on a sticky note next to your monitor. You will thank me later.

If you don’t know what screen is, just spend a few minutes learning it, even if you usually use tmux. It’s sort of like vi: the machine you’re working with probably has it by default, unlike tmux (maybe). The sixty seconds it takes to learn the basics are worth it.