No more READMEs
This commit is contained in:
johndmulhausen
@@ -1,90 +0,0 @@
|
||||
---
|
||||
title: "Kubernetes User Guide: Managing Applications"
|
||||
---
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
The user guide is intended for anyone who wants to run programs and services on an existing Kubernetes cluster. Setup and administration of a Kubernetes cluster is described in the [Cluster Admin Guide](/{{page.version}}/docs/admin/). The [Developer Guide](/{{page.version}}/docs/devel/) is for anyone wanting to either write code which directly accesses the Kubernetes API, or to contribute directly to the Kubernetes project.
|
||||
|
||||
Please ensure you have completed the [prerequisites for running examples from the user guide](prereqs).
|
||||
|
||||
## Quick walkthrough
|
||||
|
||||
1. [Kubernetes 101](walkthrough/)
|
||||
1. [Kubernetes 201](walkthrough/k8s201)
|
||||
|
||||
## Thorough walkthrough
|
||||
|
||||
If you don't have much familiarity with Kubernetes, we recommend you read the following sections in order:
|
||||
|
||||
1. [Quick start: launch and expose an application](quick-start)
|
||||
1. [Configuring and launching containers: configuring common container parameters](configuring-containers)
|
||||
1. [Deploying continuously running applications](deploying-applications)
|
||||
1. [Connecting applications: exposing applications to clients and users](connecting-applications)
|
||||
1. [Working with containers in production](production-pods)
|
||||
1. [Managing deployments](managing-deployments)
|
||||
1. [Application introspection and debugging](introspection-and-debugging)
|
||||
1. [Using the Kubernetes web user interface](ui)
|
||||
1. [Logging](logging)
|
||||
1. [Monitoring](monitoring)
|
||||
1. [Getting into containers via `exec`](getting-into-containers)
|
||||
1. [Connecting to containers via proxies](connecting-to-applications-proxy)
|
||||
1. [Connecting to containers via port forwarding](connecting-to-applications-port-forward)
|
||||
|
||||
## Concept guide
|
||||
|
||||
[**Overview**](overview)
|
||||
: A brief overview of Kubernetes concepts.
|
||||
|
||||
[**Cluster**](/{{page.version}}/docs/admin/)
|
||||
: A cluster is a set of physical or virtual machines and other infrastructure resources used by Kubernetes to run your applications.
|
||||
|
||||
[**Node**](/{{page.version}}/docs/admin/node)
|
||||
: A node is a physical or virtual machine running Kubernetes, onto which pods can be scheduled.
|
||||
|
||||
[**Pod**](pods)
|
||||
: A pod is a co-located group of containers and volumes.
|
||||
|
||||
[**Label**](labels)
|
||||
: A label is a key/value pair that is attached to a resource, such as a pod, to convey a user-defined identifying attribute. Labels can be used to organize and to select subsets of resources.
|
||||
|
||||
[**Selector**](labels/#label-selectors)
|
||||
: A selector is an expression that matches labels in order to identify related resources, such as which pods are targeted by a load-balanced service.
|
||||
|
||||
[**Replication Controller**](replication-controller)
|
||||
: A replication controller ensures that a specified number of pod replicas are running at any one time. It both allows for easy scaling of replicated systems and handles re-creation of a pod when the machine it is on reboots or otherwise fails.
|
||||
|
||||
[**Service**](services)
|
||||
: A service defines a set of pods and a means by which to access them, such as single stable IP address and corresponding DNS name.
|
||||
|
||||
[**Volume**](volumes)
|
||||
: A volume is a directory, possibly with some data in it, which is accessible to a Container as part of its filesystem. Kubernetes volumes build upon [Docker Volumes](https://docs.docker.com/userguide/dockervolumes/), adding provisioning of the volume directory and/or device.
|
||||
|
||||
[**Secret**](secrets)
|
||||
: A secret stores sensitive data, such as authentication tokens, which can be made available to containers upon request.
|
||||
|
||||
[**Name**](identifiers)
|
||||
: A user- or client-provided name for a resource.
|
||||
|
||||
[**Namespace**](namespaces)
|
||||
: A namespace is like a prefix to the name of a resource. Namespaces help different projects, teams, or customers to share a cluster, such as by preventing name collisions between unrelated teams.
|
||||
|
||||
[**Annotation**](annotations)
|
||||
: A key/value pair that can hold larger (compared to a label), and possibly not human-readable, data, intended to store non-identifying auxiliary data, especially data manipulated by tools and system extensions. Efficient filtering by annotation values is not supported.
|
||||
|
||||
## Further reading
|
||||
|
||||
* API resources
|
||||
* [Working with resources](working-with-resources)
|
||||
|
||||
* Pods and containers
|
||||
* [Pod lifecycle and restart policies](pod-states)
|
||||
* [Lifecycle hooks](container-environment)
|
||||
* [Compute resources, such as cpu and memory](compute-resources)
|
||||
* [Specifying commands and requesting capabilities](containers)
|
||||
* [Downward API: accessing system configuration from a pod](downward-api)
|
||||
* [Images and registries](images)
|
||||
* [Migrating from docker-cli to kubectl](docker-cli-to-kubectl)
|
||||
* [Tips and tricks when working with config](config-best-practices)
|
||||
* [Assign pods to selected nodes](node-selection/)
|
||||
* [Perform a rolling update on a running group of pods](update-demo/)
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
title: "Downward API example"
|
||||
---
|
||||
Following this example, you will create a pod with a container that consumes the pod's name and
|
||||
namespace using the [downward API](../downward-api).
|
||||
|
||||
## Step Zero: Prerequisites
|
||||
|
||||
This example assumes you have a Kubernetes cluster installed and running, and that you have
|
||||
installed the `kubectl` command line tool somewhere in your path. Please see the [getting
|
||||
started](/{{page.version}}/docs/getting-started-guides/) for installation instructions for your platform.
|
||||
|
||||
## Step One: Create the pod
|
||||
|
||||
Containers consume the downward API using environment variables. The downward API allows
|
||||
containers to be injected with the name and namespace of the pod the container is in.
|
||||
|
||||
Use the [`examples/downward-api/dapi-pod.yaml`](dapi-pod.yaml) file to create a Pod with a container that consumes the
|
||||
downward API.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/downward-api/dapi-pod.yaml
|
||||
|
||||
```
|
||||
### Examine the logs
|
||||
|
||||
This pod runs the `env` command in a container that consumes the downward API. You can grep
|
||||
through the pod logs to see that the pod was injected with the correct values:
|
||||
|
||||
```shell
|
||||
$ kubectl logs dapi-test-pod | grep POD_
|
||||
2015-04-30T20:22:18.568024817Z MY_POD_NAME=dapi-test-pod
|
||||
2015-04-30T20:22:18.568087688Z MY_POD_NAMESPACE=default
|
||||
2015-04-30T20:22:18.568092435Z MY_POD_IP=10.0.1.6
|
||||
|
||||
```
|
||||
@@ -1,67 +0,0 @@
|
||||
---
|
||||
title: "Downward API volume plugin"
|
||||
---
|
||||
Following this example, you will create a pod with a downward API volume.
|
||||
A downward API volume is a k8s volume plugin with the ability to save some pod information in a plain text file. The pod information can be for example some [metadata](..//{{page.version}}/docs/devel/api-conventions/#metadata).
|
||||
|
||||
Supported metadata fields:
|
||||
|
||||
1. `metadata.annotations`
|
||||
2. `metadata.namespace`
|
||||
3. `metadata.name`
|
||||
4. `metadata.labels`
|
||||
|
||||
### Step Zero: Prerequisites
|
||||
|
||||
This example assumes you have a Kubernetes cluster installed and running, and the ```kubectl```
|
||||
command line tool somewhere in your path. Please see the [gettingstarted](..//{{page.version}}/docs/getting-started-guides/) for installation instructions for your platform.
|
||||
|
||||
### Step One: Create the pod
|
||||
|
||||
Use the `docs/user-guide/downward-api/dapi-volume.yaml` file to create a Pod with a downward API volume which stores pod labels and pod annotations to `/etc/labels` and `/etc/annotations` respectively.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/downward-api/volume/dapi-volume.yaml
|
||||
|
||||
```
|
||||
### Step Two: Examine pod/container output
|
||||
|
||||
The pod displays (every 5 seconds) the content of the dump files which can be executed via the usual `kubectl log` command
|
||||
|
||||
```shell
|
||||
$ kubectl logs kubernetes-downwardapi-volume-example
|
||||
cluster="test-cluster1"
|
||||
rack="rack-22"
|
||||
zone="us-est-coast"
|
||||
build="two"
|
||||
builder="john-doe"
|
||||
kubernetes.io/config.seen="2015-08-24T13:47:23.432459138Z"
|
||||
kubernetes.io/config.source="api"
|
||||
|
||||
```
|
||||
### Internals
|
||||
|
||||
In pod's `/etc` directory one may find the file created by the plugin (system files elided):
|
||||
|
||||
```shell
|
||||
$ kubectl exec kubernetes-downwardapi-volume-example -i -t -- sh
|
||||
/ # ls -laR /etc
|
||||
/etc:
|
||||
total 32
|
||||
drwxrwxrwt 3 0 0 180 Aug 24 13:03 .
|
||||
drwxr-xr-x 1 0 0 4096 Aug 24 13:05 ..
|
||||
drwx------ 2 0 0 80 Aug 24 13:03 ..2015_08_24_13_03_44259413923
|
||||
lrwxrwxrwx 1 0 0 30 Aug 24 13:03 ..downwardapi -> ..2015_08_24_13_03_44259413923
|
||||
lrwxrwxrwx 1 0 0 25 Aug 24 13:03 annotations -> ..downwardapi/annotations
|
||||
lrwxrwxrwx 1 0 0 20 Aug 24 13:03 labels -> ..downwardapi/labels
|
||||
|
||||
/etc/..2015_08_24_13_03_44259413923:
|
||||
total 8
|
||||
drwx------ 2 0 0 80 Aug 24 13:03 .
|
||||
drwxrwxrwt 3 0 0 180 Aug 24 13:03 ..
|
||||
-rw-r--r-- 1 0 0 115 Aug 24 13:03 annotations
|
||||
-rw-r--r-- 1 0 0 53 Aug 24 13:03 labels
|
||||
/ #
|
||||
|
||||
```
|
||||
The file `labels` is stored in a temporary directory (`..2015_08_24_13_03_44259413923` in the example above) which is symlinked to by `..downwardapi`. Symlinks for annotations and labels in `/etc` point to files containing the actual metadata through the `..downwardapi` indirection. This structure allows for dynamic atomic refresh of the metadata: updates are written to a new temporary directory, and the `..downwardapi` symlink is updated atomically using `rename(2)`.
|
||||
@@ -1,89 +0,0 @@
|
||||
---
|
||||
title: "Environment Guide Example"
|
||||
---
|
||||
This example demonstrates running pods, replication controllers, and
|
||||
services. It shows two types of pods: frontend and backend, with
|
||||
services on top of both. Accessing the frontend pod will return
|
||||
environment information about itself, and a backend pod that it has
|
||||
accessed through the service. The goal is to illuminate the
|
||||
environment metadata available to running containers inside the
|
||||
Kubernetes cluster. The documentation for the Kubernetes environment
|
||||
is [here](/{{page.version}}/docs/user-guide/container-environment).
|
||||
|
||||
|
||||
|
||||
## Prerequisites
|
||||
|
||||
This example assumes that you have a Kubernetes cluster installed and
|
||||
running, and that you have installed the `kubectl` command line tool
|
||||
somewhere in your path. Please see the [getting
|
||||
started](/{{page.version}}/docs/getting-started-guides/) for installation instructions
|
||||
for your platform.
|
||||
|
||||
### Optional: Build your own containers
|
||||
|
||||
The code for the containers is under
|
||||
[containers/](containers/)
|
||||
|
||||
## Get everything running
|
||||
|
||||
kubectl create -f ./backend-rc.yaml
|
||||
kubectl create -f ./backend-srv.yaml
|
||||
kubectl create -f ./show-rc.yaml
|
||||
kubectl create -f ./show-srv.yaml
|
||||
|
||||
## Query the service
|
||||
|
||||
Use `kubectl describe service show-srv` to determine the public IP of
|
||||
your service.
|
||||
|
||||
> Note: If your platform does not support external load balancers,
|
||||
you'll need to open the proper port and direct traffic to the
|
||||
internal IP shown for the frontend service with the above command
|
||||
|
||||
Run `curl <public ip>:80` to query the service. You should get
|
||||
something like this back:
|
||||
|
||||
```
|
||||
Pod Name: show-rc-xxu6i
|
||||
Pod Namespace: default
|
||||
USER_VAR: important information
|
||||
|
||||
Kubernetes environment variables
|
||||
BACKEND_SRV_SERVICE_HOST = 10.147.252.185
|
||||
BACKEND_SRV_SERVICE_PORT = 5000
|
||||
KUBERNETES_RO_SERVICE_HOST = 10.147.240.1
|
||||
KUBERNETES_RO_SERVICE_PORT = 80
|
||||
KUBERNETES_SERVICE_HOST = 10.147.240.2
|
||||
KUBERNETES_SERVICE_PORT = 443
|
||||
KUBE_DNS_SERVICE_HOST = 10.147.240.10
|
||||
KUBE_DNS_SERVICE_PORT = 53
|
||||
|
||||
Found backend ip: 10.147.252.185 port: 5000
|
||||
Response from backend
|
||||
Backend Container
|
||||
Backend Pod Name: backend-rc-6qiya
|
||||
Backend Namespace: default
|
||||
```
|
||||
|
||||
First the frontend pod's information is printed. The pod name and
|
||||
[namespace](https://github.com/kubernetes/kubernetes/blob/master/docs/design/namespaces) are retrieved from the
|
||||
[Downward API](/{{page.version}}/docs/user-guide/downward-api). Next, `USER_VAR` is the name of
|
||||
an environment variable set in the [pod
|
||||
definition](show-rc.yaml). Then, the dynamic Kubernetes environment
|
||||
variables are scanned and printed. These are used to find the backend
|
||||
service, named `backend-srv`. Finally, the frontend pod queries the
|
||||
backend service and prints the information returned. Again the backend
|
||||
pod returns its own pod name and namespace.
|
||||
|
||||
Try running the `curl` command a few times, and notice what
|
||||
changes. Ex: `watch -n 1 curl -s <ip>` Firstly, the frontend service
|
||||
is directing your request to different frontend pods each time. The
|
||||
frontend pods are always contacting the backend through the backend
|
||||
service. This results in a different backend pod servicing each
|
||||
request as well.
|
||||
|
||||
## Cleanup
|
||||
|
||||
kubectl delete rc,service -l type=show-type
|
||||
kubectl delete rc,service -l type=backend-type
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
title: "Building"
|
||||
---
|
||||
For each container, the build steps are the same. The examples below
|
||||
are for the `show` container. Replace `show` with `backend` for the
|
||||
backend container.
|
||||
|
||||
## Google Container Registry ([GCR](https://cloud.google.com/tools/container-registry/))
|
||||
|
||||
docker build -t gcr.io/<project-name>/show .
|
||||
gcloud docker push gcr.io/<project-name>/show
|
||||
|
||||
## Docker Hub
|
||||
|
||||
docker build -t <username>/show .
|
||||
docker push <username>/show
|
||||
|
||||
## Change Pod Definitions
|
||||
|
||||
Edit both `show-rc.yaml` and `backend-rc.yaml` and replace the
|
||||
specified `image:` with the one that you built.
|
||||
|
||||
|
||||
|
||||
@@ -1,186 +0,0 @@
|
||||
---
|
||||
title: "Horizontal Pod Autoscaler"
|
||||
---
|
||||
Horizontal pod autoscaling is a [beta](/{{page.version}}/docs/api/#api-versioning) feature in Kubernetes 1.1.
|
||||
It allows the number of pods in a replication controller or deployment to scale automatically based on observed CPU usage.
|
||||
In the future also other metrics will be supported.
|
||||
|
||||
In this document we explain how this feature works by walking you through an example of enabling horizontal pod autoscaling with the php-apache server.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
This example requires a running Kubernetes cluster and kubectl in the version at least 1.1.
|
||||
[Heapster](https://github.com/kubernetes/heapster) monitoring needs to be deployed in the cluster
|
||||
as horizontal pod autoscaler uses it to collect metrics
|
||||
(if you followed [getting started on GCE guide](/{{page.version}}/docs/getting-started-guides/gce),
|
||||
heapster monitoring will be turned-on by default).
|
||||
|
||||
|
||||
## Step One: Run & expose php-apache server
|
||||
|
||||
To demonstrate horizontal pod autoscaler we will use a custom docker image based on php-apache server.
|
||||
The image can be found [here](https://releases.k8s.io/release-1.1/docs/user-guide/horizontal-pod-autoscaling/image).
|
||||
It defines [index.php](image/index.php) page which performs some CPU intensive computations.
|
||||
|
||||
First, we will start a replication controller running the image and expose it as an external service:
|
||||
|
||||
<a name="kubectl-run"></a>
|
||||
|
||||
```shell
|
||||
$ kubectl run php-apache --image=gcr.io/google_containers/hpa-example --requests=cpu=200m
|
||||
replicationcontroller "php-apache" created
|
||||
|
||||
$ kubectl expose rc php-apache --port=80 --type=LoadBalancer
|
||||
service "php-apache" exposed
|
||||
|
||||
```
|
||||
Now, we will wait some time and verify that both the replication controller and the service were correctly created and are running. We will also determine the IP address of the service:
|
||||
|
||||
```shell
|
||||
$ kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
php-apache-wa3t1 1/1 Running 0 12m
|
||||
|
||||
$ kubectl describe services php-apache | grep "LoadBalancer Ingress"
|
||||
LoadBalancer Ingress: 146.148.24.244
|
||||
|
||||
```
|
||||
We may now check that php-apache server works correctly by calling ``curl`` with the service's IP:
|
||||
|
||||
```shell
|
||||
$ curl http://146.148.24.244
|
||||
OK!
|
||||
|
||||
```
|
||||
Please notice that when exposing the service we assumed that our cluster runs on a provider which supports load balancers (e.g.: on GCE).
|
||||
If load balancers are not supported (e.g.: on Vagrant), we can expose php-apache service as ``ClusterIP`` and connect to it using the proxy on the master:
|
||||
|
||||
```shell
|
||||
$ kubectl expose rc php-apache --port=80 --type=ClusterIP
|
||||
service "php-apache" exposed
|
||||
|
||||
$ kubectl cluster-info | grep master
|
||||
Kubernetes master is running at https://146.148.6.215
|
||||
|
||||
$ curl -k -u <admin>:<password> https://146.148.6.215/api/v1/proxy/namespaces/default/services/php-apache/
|
||||
OK!
|
||||
|
||||
```
|
||||
## Step Two: Create horizontal pod autoscaler
|
||||
|
||||
Now that the server is running, we will create a horizontal pod autoscaler for it.
|
||||
To create it, we will use the [hpa-php-apache.yaml](hpa-php-apache.yaml) file, which looks like this:
|
||||
|
||||
```yaml
|
||||
apiVersion: extensions/v1beta1
|
||||
kind: HorizontalPodAutoscaler
|
||||
metadata:
|
||||
name: php-apache
|
||||
namespace: default
|
||||
spec:
|
||||
scaleRef:
|
||||
kind: ReplicationController
|
||||
name: php-apache
|
||||
namespace: default
|
||||
minReplicas: 1
|
||||
maxReplicas: 10
|
||||
cpuUtilization:
|
||||
targetPercentage: 50
|
||||
|
||||
```
|
||||
This defines a horizontal pod autoscaler that maintains between 1 and 10 replicas of the Pods
|
||||
controlled by the php-apache replication controller we created in the first step of these instructions.
|
||||
Roughly speaking, the horizontal autoscaler will increase and decrease the number of replicas
|
||||
(via the replication controller) so as to maintain an average CPU utilization across all Pods of 50%
|
||||
(since each pod requests 200 milli-cores by [kubectl run](#kubectl-run), this means average CPU utilization of 100 milli-cores).
|
||||
See [here](https://github.com/kubernetes/kubernetes/blob/master/docs/design/horizontal-pod-autoscaler/#autoscaling-algorithm) for more details on the algorithm.
|
||||
|
||||
We will create the autoscaler by executing the following command:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/horizontal-pod-autoscaling/hpa-php-apache.yaml
|
||||
horizontalpodautoscaler "php-apache" created
|
||||
|
||||
```
|
||||
Alternatively, we can create the autoscaler using [kubectl autoscale](../kubectl/kubectl_autoscale).
|
||||
The following command will create the equivalent autoscaler as defined in the [hpa-php-apache.yaml](hpa-php-apache.yaml) file:
|
||||
|
||||
```
|
||||
$ kubectl autoscale rc php-apache --cpu-percent=50 --min=1 --max=10
|
||||
replicationcontroller "php-apache" autoscaled
|
||||
|
||||
```
|
||||
We may check the current status of autoscaler by running:
|
||||
|
||||
```shell
|
||||
$ kubectl get hpa
|
||||
NAME REFERENCE TARGET CURRENT MINPODS MAXPODS AGE
|
||||
php-apache ReplicationController/default/php-apache/ 50% 0% 1 10 27s
|
||||
|
||||
```
|
||||
Please note that the current CPU consumption is 0% as we are not sending any requests to the server
|
||||
(the ``CURRENT`` column shows the average across all the pods controlled by the corresponding replication controller).
|
||||
|
||||
## Step Three: Increase load
|
||||
|
||||
Now, we will see how the autoscaler reacts on the increased load of the server.
|
||||
We will start an infinite loop of queries to our server (please run it in a different terminal):
|
||||
|
||||
```shell
|
||||
$ while true; do curl http://146.148.6.244; done
|
||||
|
||||
```
|
||||
We may examine, how CPU load was increased (the results should be visible after about 3-4 minutes) by executing:
|
||||
|
||||
```shell
|
||||
$ kubectl get hpa
|
||||
NAME REFERENCE TARGET CURRENT MINPODS MAXPODS AGE
|
||||
php-apache ReplicationController/default/php-apache/ 50% 305% 1 10 4m
|
||||
|
||||
```
|
||||
In the case presented here, it bumped CPU consumption to 305% of the request.
|
||||
As a result, the replication controller was resized to 7 replicas:
|
||||
|
||||
```shell
|
||||
$ kubectl get rc
|
||||
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS AGE
|
||||
php-apache php-apache gcr.io/google_containers/hpa-example run=php-apache 7 18m
|
||||
|
||||
```
|
||||
Now, we may increase the load even more by running yet another infinite loop of queries (in yet another terminal):
|
||||
|
||||
```shell
|
||||
$ while true; do curl http://146.148.6.244; done
|
||||
|
||||
```
|
||||
In the case presented here, it increased the number of serving pods to 10:
|
||||
|
||||
```shell
|
||||
$ kubectl get hpa
|
||||
NAME REFERENCE TARGET CURRENT MINPODS MAXPODS AGE
|
||||
php-apache ReplicationController/default/php-apache/ 50% 65% 1 10 14m
|
||||
|
||||
$ kubectl get rc
|
||||
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS AGE
|
||||
php-apache php-apache gcr.io/google_containers/hpa-example run=php-apache 10 24m
|
||||
|
||||
```
|
||||
## Step Four: Stop load
|
||||
|
||||
We will finish our example by stopping the user load.
|
||||
We will terminate both infinite ``while`` loops sending requests to the server and verify the result state:
|
||||
|
||||
```shell
|
||||
$ kubectl get hpa
|
||||
NAME REFERENCE TARGET CURRENT MINPODS MAXPODS AGE
|
||||
php-apache ReplicationController/default/php-apache/ 50% 0% 1 10 21m
|
||||
|
||||
$ kubectl get rc
|
||||
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS AGE
|
||||
php-apache php-apache gcr.io/google_containers/hpa-example run=php-apache 1 31m
|
||||
|
||||
```
|
||||
As we see, in the presented case CPU utilization dropped to 0, and the number of replicas dropped to 1.
|
||||
|
||||
|
||||
|
||||
@@ -1,77 +0,0 @@
|
||||
---
|
||||
title: "Checking Pod Health"
|
||||
---
|
||||
|
||||
This example shows two types of pod [health checks](../production-pods/#liveness-and-readiness-probes-aka-health-checks): HTTP checks and container execution checks.
|
||||
|
||||
The [exec-liveness.yaml](exec-liveness.yaml) demonstrates the container execution check.
|
||||
|
||||
```yaml
|
||||
livenessProbe:
|
||||
exec:
|
||||
command:
|
||||
- cat
|
||||
- /tmp/health
|
||||
initialDelaySeconds: 15
|
||||
timeoutSeconds: 1
|
||||
|
||||
```
|
||||
Kubelet executes the command `cat /tmp/health` in the container and reports failure if the command returns a non-zero exit code.
|
||||
|
||||
Note that the container removes the `/tmp/health` file after 10 seconds,
|
||||
|
||||
```shell
|
||||
echo ok > /tmp/health; sleep 10; rm -rf /tmp/health; sleep 600
|
||||
|
||||
```
|
||||
so when Kubelet executes the health check 15 seconds (defined by initialDelaySeconds) after the container started, the check would fail.
|
||||
|
||||
|
||||
The [http-liveness.yaml](http-liveness.yaml) demonstrates the HTTP check.
|
||||
|
||||
```yaml
|
||||
livenessProbe:
|
||||
httpGet:
|
||||
path: /healthz
|
||||
port: 8080
|
||||
initialDelaySeconds: 15
|
||||
timeoutSeconds: 1
|
||||
|
||||
```
|
||||
The Kubelet sends an HTTP request to the specified path and port to perform the health check. If you take a look at image/server.go, you will see the server starts to respond with an error code 500 after 10 seconds, so the check fails. The Kubelet sends the probe to the container's ip address by default which could be specified with `host` as part of httpGet probe. If the container listens on `127.0.0.1`, `host` should be specified as `127.0.0.1`. In general, if the container listens on its ip address or on all interfaces (0.0.0.0), there is no need to specify the `host` as part of the httpGet probe.
|
||||
|
||||
This [guide](../walkthrough/k8s201/#health-checking) has more information on health checks.
|
||||
|
||||
## Get your hands dirty
|
||||
|
||||
To show the health check is actually working, first create the pods:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/liveness/exec-liveness.yaml
|
||||
$ kubectl create -f docs/user-guide/liveness/http-liveness.yaml
|
||||
|
||||
```
|
||||
Check the status of the pods once they are created:
|
||||
|
||||
```shell
|
||||
$ kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
[...]
|
||||
liveness-exec 1/1 Running 0 13s
|
||||
liveness-http 1/1 Running 0 13s
|
||||
|
||||
```
|
||||
Check the status half a minute later, you will see the container restart count being incremented:
|
||||
|
||||
```shell
|
||||
$ kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
[...]
|
||||
liveness-exec 1/1 Running 1 36s
|
||||
liveness-http 1/1 Running 1 36s
|
||||
|
||||
```
|
||||
At the bottom of the *kubectl describe* output there are messages indicating that the liveness probes have failed, and the containers have been killed and recreated.
|
||||
|
||||
```shell
|
||||
$ kubectl describe pods liveness-exec
|
||||
@@ -1,18 +0,0 @@
|
||||
---
|
||||
title: "Elasticsearch/Kibana Logging Demonstration"
|
||||
---
|
||||
This directory contains two [pod](/{{page.version}}/docs/user-guide/pods) specifications which can be used as synthetic
|
||||
logging sources. The pod specification in [synthetic_0_25lps.yaml](synthetic_0_25lps.yaml)
|
||||
describes a pod that just emits a log message once every 4 seconds. The pod specification in
|
||||
[synthetic_10lps.yaml](synthetic_10lps.yaml)
|
||||
describes a pod that just emits 10 log lines per second.
|
||||
|
||||
See [logging document](../logging) for more details about logging. To observe the ingested log lines when using Google Cloud Logging please see the getting
|
||||
started instructions
|
||||
at [Cluster Level Logging to Google Cloud Logging](/{{page.version}}/docs/getting-started-guides/logging).
|
||||
To observe the ingested log lines when using Elasticsearch and Kibana please see the getting
|
||||
started instructions
|
||||
at [Cluster Level Logging with Elasticsearch and Kibana](/{{page.version}}/docs/getting-started-guides/logging-elasticsearch).
|
||||
|
||||
|
||||
|
||||
@@ -1,64 +0,0 @@
|
||||
---
|
||||
title: "Node selection example"
|
||||
---
|
||||
This example shows how to assign a [pod](../pods) to a specific [node](/{{page.version}}/docs/admin/node) or to one of a set of nodes using node labels and the nodeSelector field in a pod specification. Generally this is unnecessary, as the scheduler will take care of things for you, but you may want to do so in certain circumstances like to ensure that your pod ends up on a machine with an SSD attached to it.
|
||||
|
||||
### Step Zero: Prerequisites
|
||||
|
||||
This example assumes that you have a basic understanding of Kubernetes pods and that you have [turned up a Kubernetes cluster](https://github.com/kubernetes/kubernetes#documentation).
|
||||
|
||||
### Step One: Attach label to the node
|
||||
|
||||
Run `kubectl get nodes` to get the names of your cluster's nodes. Pick out the one that you want to add a label to.
|
||||
|
||||
Then, to add a label to the node you've chosen, run `kubectl label nodes <node-name> <label-key>=<label-value>`. For example, if my node name is 'kubernetes-foo-node-1.c.a-robinson.internal' and my desired label is 'disktype=ssd', then I can run `kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd`.
|
||||
|
||||
If this fails with an "invalid command" error, you're likely using an older version of kubectl that doesn't have the `label` command. In that case, see the [previous version](https://github.com/kubernetes/kubernetes/blob/a053dbc313572ed60d89dae9821ecab8bfd676dc/examples/node-selection/README.md) of this guide for instructions on how to manually set labels on a node.
|
||||
|
||||
Also, note that label keys must be in the form of DNS labels (as described in the [identifiers doc](https://github.com/kubernetes/kubernetes/blob/master/docs/design/identifiers)), meaning that they are not allowed to contain any upper-case letters.
|
||||
|
||||
You can verify that it worked by re-running `kubectl get nodes` and checking that the node now has a label.
|
||||
|
||||
### Step Two: Add a nodeSelector field to your pod configuration
|
||||
|
||||
Take whatever pod config file you want to run, and add a nodeSelector section to it, like this. For example, if this is my pod config:
|
||||
|
||||
<pre>
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: nginx
|
||||
labels:
|
||||
env: test
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
</pre>
|
||||
|
||||
Then add a nodeSelector like so:
|
||||
|
||||
<pre>
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: nginx
|
||||
labels:
|
||||
env: test
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
imagePullPolicy: IfNotPresent
|
||||
<b>nodeSelector:
|
||||
disktype: ssd</b>
|
||||
</pre>
|
||||
|
||||
When you then run `kubectl create -f pod.yaml`, the pod will get scheduled on the node that you attached the label to! You can verify that it worked by running `kubectl get pods -o wide` and looking at the "NODE" that the pod was assigned to.
|
||||
|
||||
### Conclusion
|
||||
|
||||
While this example only covered one node, you can attach labels to as many nodes as you want. Then when you schedule a pod with a nodeSelector, it can be scheduled on any of the nodes that satisfy that nodeSelector. Be careful that it will match at least one node, however, because if it doesn't the pod won't be scheduled at all.
|
||||
|
||||
|
||||
|
||||
@@ -1,98 +0,0 @@
|
||||
---
|
||||
title: "How To Use Persistent Volumes"
|
||||
---
|
||||
The purpose of this guide is to help you become familiar with [Kubernetes Persistent Volumes](../persistent-volumes). By the end of the guide, we'll have
|
||||
nginx serving content from your persistent volume.
|
||||
|
||||
This guide assumes knowledge of Kubernetes fundamentals and that you have a cluster up and running.
|
||||
|
||||
See [Persistent Storage design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/persistent-storage) for more information.
|
||||
|
||||
## Provisioning
|
||||
|
||||
A Persistent Volume (PV) in Kubernetes represents a real piece of underlying storage capacity in the infrastructure. Cluster administrators
|
||||
must first create storage (create their Google Compute Engine (GCE) disks, export their NFS shares, etc.) in order for Kubernetes to mount it.
|
||||
|
||||
PVs are intended for "network volumes" like GCE Persistent Disks, NFS shares, and AWS ElasticBlockStore volumes. `HostPath` was included
|
||||
for ease of development and testing. You'll create a local `HostPath` for this example.
|
||||
|
||||
> IMPORTANT! For `HostPath` to work, you will need to run a single node cluster. Kubernetes does not
|
||||
support local storage on the host at this time. There is no guarantee your pod ends up on the correct node where the `HostPath` resides.
|
||||
|
||||
|
||||
|
||||
```shell
|
||||
# This will be nginx's webroot
|
||||
$ mkdir /tmp/data01
|
||||
$ echo 'I love Kubernetes storage!' > /tmp/data01/index.html
|
||||
|
||||
```
|
||||
PVs are created by posting them to the API server.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/persistent-volumes/volumes/local-01.yaml
|
||||
NAME LABELS CAPACITY ACCESSMODES STATUS CLAIM REASON
|
||||
pv0001 type=local 10737418240 RWO Available
|
||||
|
||||
```
|
||||
## Requesting storage
|
||||
|
||||
Users of Kubernetes request persistent storage for their pods. They don't know how the underlying cluster is provisioned.
|
||||
They just know they can rely on their claim to storage and can manage its lifecycle independently from the many pods that may use it.
|
||||
|
||||
Claims must be created in the same namespace as the pods that use them.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/persistent-volumes/claims/claim-01.yaml
|
||||
|
||||
$ kubectl get pvc
|
||||
NAME LABELS STATUS VOLUME
|
||||
myclaim-1 map[]
|
||||
|
||||
|
||||
# A background process will attempt to match this claim to a volume.
|
||||
# The eventual state of your claim will look something like this:
|
||||
|
||||
$ kubectl get pvc
|
||||
NAME LABELS STATUS VOLUME
|
||||
myclaim-1 map[] Bound pv0001
|
||||
|
||||
$ kubectl get pv
|
||||
NAME LABELS CAPACITY ACCESSMODES STATUS CLAIM REASON
|
||||
pv0001 type=local 10737418240 RWO Bound default/myclaim-1
|
||||
|
||||
```
|
||||
## Using your claim as a volume
|
||||
|
||||
Claims are used as volumes in pods. Kubernetes uses the claim to look up its bound PV. The PV is then exposed to the pod.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/persistent-volumes/simpletest/pod.yaml
|
||||
|
||||
$ kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
mypod 1/1 Running 0 1h
|
||||
|
||||
$ kubectl create -f docs/user-guide/persistent-volumes/simpletest/service.json
|
||||
$ kubectl get services
|
||||
NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR AGE
|
||||
frontendservice 10.0.0.241 <none> 3000/TCP name=frontendhttp 1d
|
||||
kubernetes 10.0.0.2 <none> 443/TCP <none> 2d
|
||||
|
||||
```
|
||||
## Next steps
|
||||
|
||||
You should be able to query your service endpoint and see what content nginx is serving. A "forbidden" error might mean you
|
||||
need to disable SELinux (setenforce 0).
|
||||
|
||||
```shell
|
||||
$ curl 10.0.0.241:3000
|
||||
I love Kubernetes storage!
|
||||
|
||||
```
|
||||
Hopefully this simple guide is enough to get you started with PersistentVolumes. If you have any questions, join the team on [Slack](../../troubleshooting/#slack) and ask!
|
||||
|
||||
Enjoy!
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +0,0 @@
|
||||
---
|
||||
title: "Resource Quota"
|
||||
---
|
||||
This page has been moved to [here](/{{page.version}}/docs/admin/resourcequota/)
|
||||
|
||||
|
||||
@@ -1,60 +0,0 @@
|
||||
---
|
||||
title: "Secrets example"
|
||||
---
|
||||
Following this example, you will create a [secret](../secrets) and a [pod](../pods) that consumes that secret in a [volume](../volumes). See [Secrets design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/secrets) for more information.
|
||||
|
||||
## Step Zero: Prerequisites
|
||||
|
||||
This example assumes you have a Kubernetes cluster installed and running, and that you have
|
||||
installed the `kubectl` command line tool somewhere in your path. Please see the [getting
|
||||
started](/{{page.version}}/docs/getting-started-guides/) for installation instructions for your platform.
|
||||
|
||||
## Step One: Create the secret
|
||||
|
||||
A secret contains a set of named byte arrays.
|
||||
|
||||
Use the [`examples/secrets/secret.yaml`](secret.yaml) file to create a secret:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/secrets/secret.yaml
|
||||
|
||||
```
|
||||
You can use `kubectl` to see information about the secret:
|
||||
|
||||
```shell
|
||||
$ kubectl get secrets
|
||||
NAME TYPE DATA
|
||||
test-secret Opaque 2
|
||||
|
||||
$ kubectl describe secret test-secret
|
||||
Name: test-secret
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
|
||||
Type: Opaque
|
||||
|
||||
Data
|
||||
====
|
||||
data-1: 9 bytes
|
||||
data-2: 11 bytes
|
||||
|
||||
```
|
||||
## Step Two: Create a pod that consumes a secret
|
||||
|
||||
Pods consume secrets in volumes. Now that you have created a secret, you can create a pod that
|
||||
consumes it.
|
||||
|
||||
Use the [`examples/secrets/secret-pod.yaml`](secret-pod.yaml) file to create a Pod that consumes the secret.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/secrets/secret-pod.yaml
|
||||
|
||||
```
|
||||
This pod runs a binary that displays the content of one of the pieces of secret data in the secret
|
||||
volume:
|
||||
|
||||
```shell
|
||||
$ kubectl logs secret-test-pod
|
||||
2015-04-29T21:17:24.712206409Z content of file "/etc/secret-volume/data-1": value-1
|
||||
|
||||
```
|
||||
@@ -1,122 +0,0 @@
|
||||
---
|
||||
title: "Rolling update example"
|
||||
---
|
||||
|
||||
<!--
|
||||
Copyright 2014 Google Inc. All rights reserved.
|
||||
|
||||
Licensed under the Apache License, Version 2.0 (the "License");
|
||||
you may not use this file except in compliance with the License.
|
||||
You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing, software
|
||||
distributed under the License is distributed on an "AS IS" BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||
See the License for the specific language governing permissions and
|
||||
limitations under the License.
|
||||
|
||||
-->
|
||||
|
||||
# Rolling update example
|
||||
|
||||
This example demonstrates the usage of Kubernetes to perform a [rolling update](../kubectl/kubectl_rolling-update) on a running group of [pods](/{{page.version}}/docs/user-guide/pods). See [here](../managing-deployments/#updating-your-application-without-a-service-outage) to understand why you need a rolling update. Also check [rolling update design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/simple-rolling-update) for more information.
|
||||
|
||||
### Step Zero: Prerequisites
|
||||
|
||||
This example assumes that you have forked the repository and [turned up a Kubernetes cluster](/{{page.version}}/docs/getting-started-guides/):
|
||||
|
||||
```shell
|
||||
$ cd kubernetes
|
||||
$ ./cluster/kube-up.sh
|
||||
|
||||
```
|
||||
### Step One: Turn up the UX for the demo
|
||||
|
||||
You can use bash job control to run this in the background (note that you must use the default port -- 8001 -- for the following demonstration to work properly).
|
||||
This can sometimes spew to the output so you could also run it in a different terminal. You have to run `kubectl proxy` in the root of the
|
||||
Kubernetes repository. Otherwise you will get "404 page not found" errors as the paths will not match. You can find more information about `kubectl proxy`
|
||||
[here](/{{page.version}}/docs/user-guide/kubectl/kubectl_proxy).
|
||||
|
||||
```shell
|
||||
$ kubectl proxy --www=docs/user-guide/update-demo/local/ &
|
||||
I0218 15:18:31.623279 67480 proxy.go:36] Starting to serve on localhost:8001
|
||||
|
||||
```
|
||||
Now visit the the [demo website](http://localhost:8001/static). You won't see anything much quite yet.
|
||||
|
||||
### Step Two: Run the replication controller
|
||||
|
||||
Now we will turn up two replicas of an [image](../images). They all serve on internal port 80.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/update-demo/nautilus-rc.yaml
|
||||
|
||||
```
|
||||
After pulling the image from the Docker Hub to your worker nodes (which may take a minute or so) you'll see a couple of squares in the UI detailing the pods that are running along with the image that they are serving up. A cute little nautilus.
|
||||
|
||||
### Step Three: Try scaling the replication controller
|
||||
|
||||
Now we will increase the number of replicas from two to four:
|
||||
|
||||
```shell
|
||||
$ kubectl scale rc update-demo-nautilus --replicas=4
|
||||
|
||||
```
|
||||
If you go back to the [demo website](http://localhost:8001/static/index) you should eventually see four boxes, one for each pod.
|
||||
|
||||
### Step Four: Update the docker image
|
||||
|
||||
We will now update the docker image to serve a different image by doing a rolling update to a new Docker image.
|
||||
|
||||
```shell
|
||||
$ kubectl rolling-update update-demo-nautilus --update-period=10s -f docs/user-guide/update-demo/kitten-rc.yaml
|
||||
|
||||
```
|
||||
The rolling-update command in kubectl will do 2 things:
|
||||
|
||||
1. Create a new [replication controller](/{{page.version}}/docs/user-guide/replication-controller) with a pod template that uses the new image (`gcr.io/google_containers/update-demo:kitten`)
|
||||
2. Scale the old and new replication controllers until the new controller replaces the old. This will kill the current pods one at a time, spinning up new ones to replace them.
|
||||
|
||||
Watch the [demo website](http://localhost:8001/static/index), it will update one pod every 10 seconds until all of the pods have the new image.
|
||||
Note that the new replication controller definition does not include the replica count, so the current replica count of the old replication controller is preserved.
|
||||
But if the replica count had been specified, the final replica count of the new replication controller will be equal this number.
|
||||
|
||||
### Step Five: Bring down the pods
|
||||
|
||||
```shell
|
||||
$ kubectl delete rc update-demo-kitten
|
||||
|
||||
```
|
||||
This first stops the replication controller by turning the target number of replicas to 0 and then deletes the controller.
|
||||
|
||||
### Step Six: Cleanup
|
||||
|
||||
To turn down a Kubernetes cluster:
|
||||
|
||||
```shell
|
||||
$ ./cluster/kube-down.sh
|
||||
|
||||
```
|
||||
Kill the proxy running in the background:
|
||||
After you are done running this demo make sure to kill it:
|
||||
|
||||
```shell
|
||||
$ jobs
|
||||
[1]+ Running ./kubectl proxy --www=local/ &
|
||||
$ kill %1
|
||||
[1]+ Terminated: 15 ./kubectl proxy --www=local/
|
||||
|
||||
```
|
||||
### Updating the Docker images
|
||||
|
||||
If you want to build your own docker images, you can set `$DOCKER_HUB_USER` to your Docker user id and run the included shell script. It can take a few minutes to download/upload stuff.
|
||||
|
||||
```shell
|
||||
$ export DOCKER_HUB_USER=my-docker-id
|
||||
$ ./docs/user-guide/update-demo/build-images.sh
|
||||
|
||||
```
|
||||
To use your custom docker image in the above examples, you will need to change the image name in `docs/user-guide/update-demo/nautilus-rc.yaml` and `docs/user-guide/update-demo/kitten-rc.yaml`.
|
||||
|
||||
@@ -1,174 +0,0 @@
|
||||
---
|
||||
title: "Kubernetes 101 - Kubectl CLI and Pods"
|
||||
---
|
||||
|
||||
For Kubernetes 101, we will cover kubectl, pods, volumes, and multiple containers
|
||||
|
||||
In order for the kubectl usage examples to work, make sure you have an examples directory locally, either from [a release](https://github.com/kubernetes/kubernetes/releases) or [the source](https://github.com/kubernetes/kubernetes).
|
||||
|
||||
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
## Kubectl CLI
|
||||
|
||||
The easiest way to interact with Kubernetes is via the [kubectl](../kubectl/kubectl) command-line interface.
|
||||
|
||||
For more info about kubectl, including its usage, commands, and parameters, see the [kubectl CLI reference](../kubectl/kubectl).
|
||||
|
||||
If you haven't installed and configured kubectl, finish the [prerequisites](../prereqs) before continuing.
|
||||
|
||||
## 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.
|
||||
|
||||
See [pods](/{{page.version}}/docs/user-guide/pods) for more details.
|
||||
|
||||
|
||||
#### Pod Definition
|
||||
|
||||
The simplest pod definition describes the deployment of a single container. For example, an nginx web server pod might be defined as such:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
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 it is Kubernetes' responsibility to make sure that the current state matches the desired state. For example, when you create a Pod, you declare that you want the containers in it to be running. If the containers happen to not be running (e.g. program failure, ...), Kubernetes will continue to (re-)create them for you in order to drive them to the desired state. This process continues until the Pod is deleted.
|
||||
|
||||
See the [design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/) for more details.
|
||||
|
||||
|
||||
#### Pod Management
|
||||
|
||||
Create a pod containing an nginx server ([pod-nginx.yaml](pod-nginx.yaml)):
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/walkthrough/pod-nginx.yaml
|
||||
|
||||
```
|
||||
List all pods:
|
||||
|
||||
```shell
|
||||
$ 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. See the [command execution documentation](../kubectl/kubectl_exec) for details.
|
||||
|
||||
Provided the pod IP is accessible, you should be able to access its http endpoint with curl on port 80:
|
||||
|
||||
```shell
|
||||
$ curl http://$(kubectl get pod nginx -o go-template={{.status.podIP}})
|
||||
|
||||
```
|
||||
Delete the pod by name:
|
||||
|
||||
```shell
|
||||
$ 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.
|
||||
|
||||
For this example we'll be creating a Redis pod with a named volume and volume mount that defines the path to mount the volume.
|
||||
|
||||
1. Define a volume:
|
||||
|
||||
```yaml
|
||||
volumes:
|
||||
- name: redis-persistent-storage
|
||||
emptyDir: {}
|
||||
|
||||
```
|
||||
2. Define a volume mount within a container definition:
|
||||
|
||||
```yaml
|
||||
volumeMounts:
|
||||
# name must match the volume name below
|
||||
- name: redis-persistent-storage
|
||||
# mount path within the container
|
||||
mountPath: /data/redis
|
||||
|
||||
```
|
||||
Example Redis pod definition with a persistent storage volume ([pod-redis.yaml](pod-redis.yaml)):
|
||||
|
||||
<!-- BEGIN MUNGE: EXAMPLE pod-redis.yaml -->
|
||||
|
||||
```yaml
|
||||
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: {}
|
||||
|
||||
```
|
||||
[Download example](pod-redis.yaml)
|
||||
<!-- END MUNGE: EXAMPLE pod-redis.yaml -->
|
||||
|
||||
Notes:
|
||||
- The volume mount name is a reference to a specific empty dir volume.
|
||||
- The volume mount path is the path to mount the empty dir volume within the container.
|
||||
|
||||
##### Volume Types
|
||||
|
||||
- **EmptyDir**: Creates a new directory that will persist across container failures and restarts.
|
||||
- **HostPath**: Mounts an existing directory on the node's file system (e.g. `/var/logs`).
|
||||
|
||||
See [volumes](/{{page.version}}/docs/user-guide/volumes) for more details.
|
||||
|
||||
|
||||
#### 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:
|
||||
|
||||
```yaml
|
||||
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: {}
|
||||
|
||||
```
|
||||
Reference in New Issue
Block a user