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.
You should see “Kubernetes Master …” and “KubeDNS …” Both of these should be running on localhost.
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
source <(kubectl completion bash)
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 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!
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 podsNAME 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
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
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.
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)'
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
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