From 922e60eff503603cf62c7c8a5aff60201a32abcc Mon Sep 17 00:00:00 2001 From: steveperry-53 Date: Tue, 6 Dec 2016 17:22:21 -0800 Subject: [PATCH] Write new task: Configuring a Pod to Use a Volume for Storage. --- _data/tasks.yml | 8 +- .../configure-volume-storage.md | 109 ++++++++++++++++++ .../configure-pod-container/pod-redis.yaml | 14 +++ 3 files changed, 129 insertions(+), 2 deletions(-) create mode 100644 docs/tasks/configure-pod-container/configure-volume-storage.md create mode 100644 docs/tasks/configure-pod-container/pod-redis.yaml diff --git a/_data/tasks.yml b/_data/tasks.yml index d4f6071bf1..ee468f48d6 100644 --- a/_data/tasks.yml +++ b/_data/tasks.yml @@ -3,6 +3,7 @@ abstract: "Step-by-step instructions for performing operations with Kuberentes." toc: - title: Tasks path: /docs/tasks/ + - title: Configuring Pods and Containers section: - title: Defining Environment Variables for a Container @@ -11,18 +12,19 @@ toc: path: /docs/tasks/configure-pod-container/define-command-argument-container/ - title: Assigning CPU and RAM Resources to a Container path: /docs/tasks/configure-pod-container/assign-cpu-ram-container/ + - title: Configuring a Pod to Use a Volume for Storage + path: /docs/tasks/configure-pod-container/configure-volume-storage/ + - title: Accessing Applications in a Cluster section: - title: Using Port Forwarding to Access Applications in a Cluster path: /docs/tasks/access-application-cluster/port-forward-access-application-cluster/ - - title: Debugging Applications in a Cluster section: - title: Determining the Reason for Pod Failure path: /docs/tasks/debug-application-cluster/determine-reason-pod-failure/ - - title: Accessing the Kubernetes API section: - title: Using an HTTP Proxy to Access the Kubernetes API @@ -54,3 +56,5 @@ toc: section: - title: Debugging Init Containers path: /docs/tasks/troubleshoot/debug-init-containers/ + - title: Configuring Access Control and Identity Management + path: /docs/tasks/administer-cluster/access-control-identity-management/ diff --git a/docs/tasks/configure-pod-container/configure-volume-storage.md b/docs/tasks/configure-pod-container/configure-volume-storage.md new file mode 100644 index 0000000000..9097548ada --- /dev/null +++ b/docs/tasks/configure-pod-container/configure-volume-storage.md @@ -0,0 +1,109 @@ +--- +--- + +{% capture overview %} + +This page shows how to configure a Pod to use a Volume for storage. + +A Container's file system lives only as long as the Container does, so when a +Container terminates and restarts, changes to the filesystem are lost. For more +consistent storage that is independent of the Container, you can use a +[Volume](/docs/user-guide/volumes). This is especially important for stateful +applications, such as key-value stores and databases. For example, Redis is a +key-value cache and store. + +{% endcapture %} + +{% capture prerequisites %} + +{% include task-tutorial-prereqs.md %} + +{% endcapture %} + +{% capture steps %} + +### Configuring a volume for a Pod + +In this exercise, you create a Pod that runs one Container. This Pod has a +Volume of type +[emptyDir](/docs/user-guide/volumes/#emptydir) +that lasts for the life of the Pod, even if the Container terminates and +restarts. Here is the configuration file for the Pod: + +{% include code.html language="yaml" file="pod-redis.yaml" ghlink="/docs/tasks/configure-pod-container/pod-redis.yaml" %} + +1. Create the Pod: + + kubectl create -f http://k8s.io/docs/tasks/configure-pod-container/pod-redis.yaml + +1. Verify that the Pod's Container is running, and then watch for changes to +the Pod: + + kubectl get --watch pod redis + + The output looks like this: + + NAME READY STATUS RESTARTS AGE + redis 1/1 Running 0 13s + +1. In another terminal, get a shell to the running Container: + + kubectl exec -it redis -- /bin/bash + +1. In your shell, go to `/data/redis`, and create a file: + + root@redis:/data/redis# echo Hello > test-file + +1. In your shell, list the running processes: + + root@redis:/data/redis# ps aux + + The output is similar to this: + + USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND + redis 1 0.1 0.1 33308 3828 ? Ssl 00:46 0:00 redis-server *:6379 + root 12 0.0 0.0 20228 3020 ? Ss 00:47 0:00 /bin/bash + root 15 0.0 0.0 17500 2072 ? R+ 00:48 0:00 ps aux + +1. In your shell, kill the redis process: + + root@redis:/data/redis# kill + + where `` is the redis process ID (PID). + +1. In your original terminal, watch for changes to the redis Pod. Eventually, +you will see something like this: + + NAME READY STATUS RESTARTS AGE + redis 1/1 Running 0 13s + redis 0/1 Completed 0 6m + redis 1/1 Running 1 6m + +At this point, the Container has terminated and restarted. This is because the +redis Pod has a +[restartPolicy](http://kubernetes.io/docs/api-reference/v1/definitions#_v1_podspec) +of `Always`. + +1. Get a shell into the restarted Container: + + kubectl exec -it redis -- /bin/bash + +1. In your shell, goto `/data/redis`, and verify that `test-file` is still there. + +{% endcapture %} + +{% capture whatsnext %} + +* See [Volume](/docs/api-reference/v1/definitions/#_v1_volume). + +* See [Pod](http://kubernetes.io/docs/api-reference/v1/definitions#_v1_pod). + +* In addition to the local disk storage provided by `emptyDir`, Kubernetes +supports many different network-attached storage solutions, including PD on +GCE and EBS on EC2, which are preferred for critical data, and will handle +details such as mounting and unmounting the devices on the nodes. See +[Volumes](/docs/user-guide/volumes) for more details. + +{% endcapture %} + +{% include templates/task.md %} diff --git a/docs/tasks/configure-pod-container/pod-redis.yaml b/docs/tasks/configure-pod-container/pod-redis.yaml new file mode 100644 index 0000000000..cb06456d4b --- /dev/null +++ b/docs/tasks/configure-pod-container/pod-redis.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Pod +metadata: + name: redis +spec: + containers: + - name: redis + image: redis + volumeMounts: + - name: redis-storage + mountPath: /data/redis + volumes: + - name: redis-storage + emptyDir: {}