Newbernetes: kubectl the Kubernetes CLI

Hopefully you are all set up with Kubernetes running on Docker. If not, check out the previous post for instructions.

Before we deploy our first app to Kubernetes let’s run a few commands to make sure everything is configured.

Run: kubectl cluster-info

You should see “Kubernetes Master …” and “KubeDNS …” Both of these should be running on localhost.

Run: kubectl get nodes — this will list all the nodes in your cluster. You will probably have only one if you are running in Docker.

You should see:

NAME                 STATUS    ROLES     AGE       VERSION
docker-for-desktop   Ready     master    10m       v1.9.2

Pro Tip: Save your fingers: Alias those commands and add autocompletion!

# Stick this in your .bash_profile, .bashrc, .zshrc
alias kc="kubectl"
alias kx="kubectx"
alias kn="kubens"
source <(kubectl completion bash)
# or 
source <(kubectl completion zsh)

Now we’ll create a namespace to run the tutorial in.

kubectl create namespace newb # creates the namespace
kubens newb # switches to that namespace

Ok, we are going to jump in the deep end with kubectl run.

The kubectl run subcommand is extremely powerful. Generally it’s not used in day-to-day operations. Typically you’ll use YAML resource files (Infrastructure-as-Code) to deploy your services.

kubectl run can do pretty much everything that can be done via YAML files.

If you are up for being overwhelmed, I invite you to run kubectl run -h and look at all the things it can do.

Let’s spin up two nginx servers using the offical NGiNX image.

# kubectl run FRIENDLY_NAME [OPTS]
kubectl run nginx --image=nginx --replicas=2

Woah, you’re devops now!

Good Job, but the printer isn’t working.

Let’s get some info on our nginx servers. The first subcommand we will use is kubectl get which exposes basic information about one or more resources.

kubectl get pods
NAME                   READY     STATUS    RESTARTS   AGE
nginx-8586cf59-7zknj   1/1       Running   0          15m
nginx-8586cf59-m2ffm   1/1       Running   0          15m

Nice, they’re running! The auto-generated names will be different for you, but they will be prefixed with the friendly name from kubectl run.

Now let’s get some more details, be prepared to have your scroll buffer blown back.

kubectl describe pod/YOUR_POD_NAME_HERE

That’s a lot of information and we don’t need to understand it all right now. ;)

The important thing is that get and describe are tools that you will frequently use to get information about a running application (called a deployment) or service.

Under the hood Kubernetes exposes an HTTP API with many resource endpoints. get and describe are tools that interact with the API in your cluster to let provide details on your resources.

If you really want to get into the nitty gritty of the API, check out the docs.

kubectl also has a delete command for deleting resources.

kubectl delete pod/YOUR_NGINX_POD_NAME_HERE

A deletion confirmation should be printed out, but guess what! You still have two nginx pods running.

kubectl get pods

We asked kubectl to run two replicas and come hell or high water, that’s what it is going to do. In later tutorials we’ll go into health probes, which are ways to let kube automate removing unhealthy pods, but in a pinch the delete command can be useful. It can also be used for deleting any other type of resource. Which we’ll see at the end of the tutorial.

Sometimes you need to get into a running container. kubectl exec is the command you are looking for. You can run any binary that is in the container, including starting up a bash shell:

kubectl exec -it YOUR_POD_NAME_HERE /bin/bash
echo "I wuz here, 2018" > README

Feel free to poke around, make yourself at home. Nice place, huh?

kubectl logs is another tool you will use day-to-day to debug running containers.

Let’s run something else that has some good output to read logs from, a cronjob.

kubectl run pi --schedule="0/1 * * * ?" --image=perl --restart=OnFailure -- perl -Mbignum=bpi -wle 'print bpi(2000)'

Now run kubectl get pod… you won’t see anything new.

We scheduled the job to happen every minute and it probably hasn’t run yet. kubectl get takes a -w flag will cause the get command to wait for new pods.

kubectl get pods -w

In about a minute we should see a new pi pod spin up. Did you see it!

So we have been using kubectl get pods to find out information about what we are running. The pod is the smallest resource in Kubernetes. The get and describe commands can display information on other resources too.

Other resources are built around pods, kind of like a russian nesting doll. We can build replica sets, stateful sets, deployments, jobs and cronjobs. Each of those resource types can also be viewed from the CLI.

kubectl get cronjob -w

And if you wait another minute you’ll see the job become active. Pretty cool huh? Now what about those logs?

kubectl logs YOUR_PI_POD_NAME_HERE

That should spit out a big number. Impressive, huh?

There are many flags for the logs subcommand:

kubectl logs POD_NAME -f # will follow the log
kubectl logs POD_NAME --tail=20 # will display last 20 lines
kubectl logs --since=2h # will display the last 2 hours of logs

So that is a basic whirlwind tour of the Kubernetes CLI. In the next post we will begin building pods as the basis for learning about all the resources Kubernetes has to offer.

Time to clean up:

kubectl delete namespace newb

An aside:

kubectl lets you be really lazy about typing, which is nice since the tool can be verbose at times. Running kubectl get will output all the resources that kubectl can get. You’ll also see abbreviations in parentheses after the resource name. These are shorthand names you can use.

I won’t use them in the tutorials, but you can!

kubectl get po # this will get pods
kubectl get ns # this will get namespaces