Try Kubernetes

Tutorials

Documentation for Kubernetes v1.10 is no longer actively maintained. The version you are currently viewing is a static snapshot. For up-to-date documentation, see the latest version.

Edit This Page

Kubernetes 101

Kubectl CLI and Pods

For Kubernetes 101, we will cover kubectl, Pods, Volumes, and multiple containers.

You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using Minikube, or you can use one of these Kubernetes playgrounds:

To check the version, enter kubectl version.

In order for the kubectl usage examples to work, make sure you have an example directory locally, either from a release or the latest .yaml files located here.

Kubectl CLI

The easiest way to interact with Kubernetes is through the kubectl command-line interface.

For more info about kubectl, including its usage, commands, and parameters, see Overview of kubectl.

For more information about installing and configuring kubectl, see Install and Set Up kubectl.

Pods

In Kubernetes, a group of one or more containers is called a Pod. Containers in a Pod are deployed together, and are started, stopped, and replicated as a group.

For more information, see Pods.

Pod Definition

The simplest Pod definition describes the deployment of a single container. For example, an nginx web server Pod might be defined as:

pod-nginx.yaml docs/tutorials 
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
    ports:
    - containerPort: 80

A Pod definition is a declaration of a desired state. Desired state is a very important concept in the Kubernetes model. Many things present a desired state to the system, and Kubernetes’ ensures that the current state matches the desired state. For example, when you create a Pod and declare that the containers in it to be running. If the containers happen not to be running because of a program failure, Kubernetes continues to (re-)create the Pod in order to drive the pod to the desired state. This process continues until you delete the Pod.

For more information, see Kubernetes Design Documents and Proposals.

Pod Management

Create a Pod containing an nginx server (pod-nginx.yaml):

$ kubectl create -f docs/tutorials/pod-nginx.yaml

List all Pods:

$ kubectl get pods

On most providers, the Pod IPs are not externally accessible. The easiest way to test that the pod is working is to create a busybox Pod and exec commands on it remotely. For more information, see Get a Shell to a Running Container.

If the IP of the Pod is accessible, you can access its http endpoint with wget on port 80:

$ kubectl run busybox --image=busybox --restart=Never --tty -i --generator=run-pod/v1 --env "POD_IP=$(kubectl get pod nginx -o go-template='{{.status.podIP}}')"
u@busybox$ wget -qO- http://$POD_IP # Run in the busybox container
u@busybox$ exit # Exit the busybox container
$ kubectl delete pod busybox # Clean up the pod we created with "kubectl run"

To delete a Pod named nginx:

$ kubectl delete pod nginx

Volumes

That’s great for a simple static web server, but what about persistent storage?

The container file system only lives as long as the container does. So if your app’s state needs to survive relocation, reboots, and crashes, you’ll need to configure some persistent storage.

In this example you can create a Redis Pod with a named volume, and a volume mount that defines the path to mount the Volume.

  1. Define a Volume:
volumes:
    - name: redis-persistent-storage
      emptyDir: {}
  1. Define a Volume mount within a container definition:
volumeMounts:
    # name must match the volume name defined in volumes
    - name: redis-persistent-storage
      # mount path within the container
      mountPath: /data/redis

Here is an example of Redis Pod definition with a persistent storage volume (pod-redis.yaml):

pod-redis.yaml docs/tutorials 
apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: redis
    volumeMounts:
    - name: redis-persistent-storage
      mountPath: /data/redis
  volumes:
  - name: redis-persistent-storage
    emptyDir: {}

Where:

Volume Types

For more information, see Volumes.

Multiple Containers

Note: The examples below are syntactically correct, but some of the images (e.g. kubernetes/git-monitor) don’t exist yet. We’re working on turning these into working examples.

However, often you want to have two different containers that work together. An example of this would be a web server, and a helper job that polls a git repository for new updates:

apiVersion: v1
kind: Pod
metadata:
  name: www
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - mountPath: /srv/www
      name: www-data
      readOnly: true
  - name: git-monitor
    image: kubernetes/git-monitor
    env:
    - name: GIT_REPO
      value: http://github.com/some/repo.git
    volumeMounts:
    - mountPath: /data
      name: www-data
  volumes:
  - name: www-data
    emptyDir: {}

Note that we have also added a Volume here. In this case, the Volume is mounted into both containers. It is marked readOnly in the web server’s case, since it doesn’t need to write to the directory.

Finally, we have also introduced an environment variable to the git-monitor container, which allows us to parameterize that container with the particular git repository that we want to track.

What’s Next?

Continue on to Kubernetes 201 or for a complete application see the guestbook example

Analytics

Create an Issue Edit this Page