Getting Started with Kubernetes

kubectl is the CLI client that talks to a cluster’s API server over HTTPS; it does not need a running cluster to be installed. There are three supported ways to get it on a developer machine:

A local cluster removes the cost of a cloud account while learning the API. All the examples in this section run on one of the three options below; Cluster Setup and Administration covers kubeadm and real multi-node clusters, and Managed Kubernetes and Distributions covers cloud-managed options.

A kubeconfig file (~/.kube/config by default, or the KUBECONFIG environment variable) holds one or more clusters (an API server address and CA certificate), users (credentials) and contexts (a cluster/user/ namespace triple with a name). kind and minikube each add their own cluster, user and context automatically when a cluster starts.

kubectl config use-context switches which cluster and user every subsequent command targets; set-context --current --namespace changes only the default namespace for the active context, so kubectl get pods means kubectl get pods -n bookshelf without repeating -n on every command. Both changes are stored in the kubeconfig file itself, so they persist across shells. Namespaces themselves — what they are for and when to use them — are covered in Objects and the Kubernetes API.

Source: Configure Access to Multiple Clusters

Derived also from kubectl config reference.

The rest of this section builds out the full Bookshelf application — catalog-api, reviews-api, web, PostgreSQL, Redis and a notifier worker — but the very first deploy only needs one piece of it, following the same imperative-command flow as the official Kubernetes Basics tutorial: create a Deployment, expose it, look at it, scale it, update it, and delete it.

create deployment wraps the Pod template in a Deployment (see ReplicaSets and Deployments for what that buys you over a bare Pod), and expose creates a matching ClusterIP Service selecting the Deployment’s pods (see Services). Reach the Service from the local machine with port-forward, which tunnels a local TCP port straight to a Pod without going through the cluster’s networking at all:

Scale it, roll out a new version and watch the rollout, then roll back:

kubectl create deployment names the container after the image (bookshelf-web), which is the name set image targets. set image changes the Pod template’s image, which the Deployment controller turns into a new ReplicaSet and a rolling update; rollout status blocks until the update finishes (or reports why it hasn’t), and rollout undo reverts to the previous ReplicaSet. ReplicaSets and Deployments covers the update strategy fields (maxSurge, maxUnavailable) and the rest of kubectl rollout behind these commands.

Clean up:

Source: Kubernetes Basics

(in particular the "Using kubectl to Create a Deployment", "Viewing Your Application", "Using kubectl to Expose an App", "Scale an Application" and "Update an Application" modules); see also Hello Minikube, which walks the same flow specifically against minikube.

Putting the pieces above together, a typical inner-loop iteration on a kind cluster looks like this: change code, rebuild the image, load it into the cluster (no registry needed), re-apply the manifest so the new image is picked up, and re-open the port-forward to try it.

kubectl apply (rather than set image) is the declarative form used from here on, once a manifest exists on disk; kubectl Essentials contrasts the imperative commands used above with apply in depth. imagePullPolicy: IfNotPresent (or Never) on the Deployment’s container keeps kubectl apply from trying to pull bookshelf-web:dev from a registry that does not have it, now that kind load docker-image has already placed it on every node.

Read kubectl Essentials for the rest of the kubectl surface used throughout this section, then Objects and the Kubernetes API for the object model and namespaces this page only introduced in passing. The full reading order is on the section landing page.