Kubernetes Cheat Sheet

Container management

Physical Layout

Kubernetes Physical Layout

Query the server/client version used:

kubectl version

Get cluster info:

kubectl cluster-info

Get configuration info:

kubectl config view

Watch nodes continuously:

kubectl get nodes -w

Get info about ‘node123’:

kubectl describe node123

From a physical perspective, a Kubernetes cluster consists of:

  1. A master (with several independent sub-components, details below) that coordinates the work.
  2. A distributed key-value store, currently etcd, for maintaining the resource state in a persistent and reliable manner, throughout the cluster.
  3. A number of nodes that carry out the work.
  4. A command line tool called kubectl allowing to query and manipulate the cluster state; this is a fancy way of saying: running containers, creating services and administrating the cluster (logging, monitoring, debugging).

Abstractions Overview

Kubernetes Abstractions Overview

List pods:

kubectl get pods

Get info about pod ‘nginx-hl2nb’:

kubectl describe pod nginx-hl2nb

List replication controllers:

kubectl get rc

Get info about replication controller ‘nginx’:

kubectl describe rc nginx

Expose replication controller ‘nginx’ as a service on port 80:

kubectl expose rc nginx --port=80 --target-port=8000

List services:

kubectl get svc

Get info about service ‘nginx’:

kubectl describe svc nginx

Destroy/remove a resource :

kubectl delete pod nginx-hl2nb
kubectl delete rc nginx
kubectl delete svc nginx

Organize your resources

The primary organization mechanism in Kubernetes are so called labels: these key/value pairs allow you to tag any sort of resource such as a pod or a RC. Both the key and the value are transparent to Kubernetes, which is an elaborate way to say: Kubernetes doesn’t know and doesn’t care about it; labels only have a meaning to you. Kubernetes, however, will use the labels to, for example, select pods that belong to a service, select pods that a certain RC is supposed to look after, for rolling upgrades and to debug containers online.


In order to troubleshoot the cluster, you may wish to use the following commands:

  • To debug a container, enter it so: kubectl exec nginx-hl2nb /bin/sh (note: in this case the first container will be used, otherwise use -c $NAME_OF_CONTAINERto specify which container to enter)
  • To see the logs of a pod in a rolling fashion use kubectl logs -f nginx-hl2nb(note: same as with exec, you can specify the container if you wish to)
  • The Kubelet logs are per default at: /var/log/kubelet.log
  • To check the status of components such as the scheduler, etcd, and controller manager use: kubectl get cs

Abstractions Details

Kubernetes Abstractions Details

The interactions are as follows:

  1. A replication controller (RC) looks after one or more pods. The RC keeps a number of pods (so called replicas) up and running.
    • To launch a pod and implicitly create a RC: kubectl run ubuntu --image=ubuntu
    • To create a RC from a manifest, use: kubectl create -f nginx-rc.yaml. See the YAML formatted RC manifest file itself for the actual definition.
    • To list all RCs in a certain namespace:kubectl get rc --namespace="kube-system"
    • To change the number of pods in a RC, scale it like so: kubectl scale --replicas=2 rc nginx
    • Containers in a pod may use ephemeral local disk space but for sustainable, persistent scenarios as well as sharing data between containers in a pod you can use volumes.
    • Implement health checks via readinessProbe and livenessProbe fields on the pod-level.
  2. A service represents a logical group of pods (backed by a RC). It provides a stable interface to interact with the pods. To create a service from a YAML file, use: kubectl create -f my-service.yaml. The service selects the targeted pods it routes traffic to via labels, for example, to list all pods labelled with ‘app=webserver’ use:
    kubectl get pods -l="app=webserver".
  3. From either the end-user perspective or other services in a cluster, one interacts with a service. To expose a RC named ‘nginx’ that has a pod serving on port 8000 as a service on port 80, use kubectl expose rc nginx --port=80 --target-port=8000. Also to list the endpoints, use: kubectl get ep
  4. On each node a local proxy runs that provides for basic service discovery and load balancing.
  5. A container in a pod may use one or more secrets to handle sensitive information such as passwords or API credentials. To list all secrets, use:kubectl get secrets
  6. A autoscaler is available on a per-RC basis. It scales the replicas depending on the average CPU utilization of the RC’s pods.
  7. For batch workloads, you can use jobs. To view completed pods of a job, use:kubectl get pods --show-all
  8. Changes to resources such as pods, RCs, services, etc. are available through events: kubectl get events
  9. To separate users, groups or applications use namespaces.To list all namespaces, use: kubectl get ns and to see the resource quotas of a namespace use kubectl get quota. When a pod doesn’t specify its resource constraints such as CPU shares or memory requested it effectively can consume unbounded resources. You really want to specify default limitsalong with the quotas. Note: while quotas work on the namespace-level for, say, entire groups of users or projects, the limits work on a per-pod level.


Manage Resources

  • Get documentation for pod or service kubectl explain pods,svc
  • Create resource(s) like pods, services or daemonsets kubectl create -f ./my-manifest.yaml
  • Apply a configuration to a resource kubectl apply -f ./my-manifest.yaml
  • Start a single instance of Nginx kubectl run nginx --image=nginx
  • Create a secret with several keys
      cat <<EOF | kubectl create -f -
      apiVersion: v1
      kind: Secret
        name: mysecret
      type: Opaque
        password: $(echo -n "s33msi4" | base64)
        username: $(echo -n "jane" | base64)
  • Delete a resource kubectl delete -f ./my-manifest.yaml

Viewing, Finding Resources

  • List all services in the namespace kubectl get services
  • List all pods in all namespaces in wide format kubectl get pods -o wide --all-namespaces
  • List all pods in json (or yaml) format kubectl get pods -o json
  • Describe resource details (node, pod, svc) kubectl describe nodes my-node
  • List services sorted by name kubectl get services --sort-by=.metadata.name
  • List pods sorted by restart count kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'
  • Rolling update pods for frontend-v1 kubectl rolling-update frontend-v1 -f frontend-v2.json
  • Scale a replicaset named ‘foo’ to 3 kubectl scale --replicas=3 rs/foo
  • Scale a resource specified in “foo.yaml” to 3 kubectl scale --replicas=3 -f foo.yaml
  • Execute a command in every pod / replica for i in 0 1; do kubectl exec foo-$i -- sh -c 'echo $(hostname) > /usr/share/nginx/html/index.html'; done

Monitoring & Logging

  • Deploy Heapster from Github repository https://github.com/kubernetes/heapster kubectl create -f deploy/kube-config/standalone/
  • Show metrics for nodes kubectl top node kubectl top node my-node-1
  • Show metrics for pods kubectl top pod kubectl top pod my-pod-1
  • Show metrics for a given pod and its containers kubectl top pod pod_name --containers
  • Dump pod logs (stdout) kubectl logs pod_name
  • Stream pod container logs (stdout, multi-container case) kubectl logs -f pod_name -c my-container
  • Create a daemonset from stdin. The example deploys Sematext Docker Agent to all nodes for the cluster-wide collection of metrics, logs and events. There is NO need to deploy cAdvisor, Heapster, Prometheus, Elasticsearch, Grafana, InfluxDb on your local nodes. Please replace YOUR_SPM_DOCKER_TOKEN and YOUR_LOGSENE_TOKEN with your tokens created in Sematext Cloud UI before you run the command.
apiVersion: extensions/v1beta1
kind: DaemonSet
  name: sematext-agent
        app: sematext-agent
      nodeSelector: {}
      hostNetwork: true
      dnsPolicy: "ClusterFirst"
      restartPolicy: "Always"
      - name: sematext-agent
        image: sematext/sematext-agent-docker:latest
        imagePullPolicy: "Always"
        - name: SPM_TOKEN
          value: "YOUR_SPM_DOCKER_TOKEN"
        - name: LOGSENE_TOKEN
          value: "YOUR_LOGSENE_TOKEN"
          - mountPath: /var/run/docker.sock
            name: docker-sock
          - mountPath: /etc/localtime
            name: localtime
          privileged: true
        - name: docker-sock
            path: /var/run/docker.sock
        - name: localtime
            path: /etc/localtime

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: