Change Task titles to imperative. (#4022)
parent
67ece8bc15
commit
adf00a04a2
|
@ -9,7 +9,7 @@ toc:
|
|||
- docs/tasks/tools/install-minikube.md
|
||||
- docs/setup/independent/install-kubeadm.md
|
||||
|
||||
- title: Configuring Pods and Containers
|
||||
- title: Configure Pods and Containers
|
||||
section:
|
||||
- docs/tasks/configure-pod-container/assign-cpu-ram-container.md
|
||||
- docs/tasks/configure-pod-container/configure-volume-storage.md
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Assigning CPU and RAM Resources to a Container
|
||||
title: Assign CPU and RAM Resources to a Container
|
||||
description: When you create a Pod, you can request CPU and RAM resources for the containers that run in the Pod. You can also set limits for CPU and RAM use.
|
||||
---
|
||||
|
||||
|
@ -20,7 +20,7 @@ in a Kubernetes Pod.
|
|||
|
||||
{% capture steps %}
|
||||
|
||||
## Assigning CPU and RAM resources to a container
|
||||
## Assign CPU and RAM resources to a container
|
||||
|
||||
When you create a Pod, you can request CPU and RAM resources for the containers
|
||||
that run in the Pod. You can also set limits for CPU and RAM resources. To
|
||||
|
@ -65,7 +65,7 @@ for the `Pod`:
|
|||
cpu: 250m
|
||||
memory: 64Mi
|
||||
|
||||
## Understanding CPU and RAM units
|
||||
## CPU and RAM units
|
||||
|
||||
The CPU resource is measured in *cpu*s. Fractional values are allowed. You can
|
||||
use the suffix *m* to mean mili. For example 100m cpu is 100 milicpu, and is
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Assigning Pods to Nodes
|
||||
title: Assign Pods to Nodes
|
||||
redirect_from:
|
||||
- "/docs/tasks/administer-cluster/assign-pods-nodes/"
|
||||
- "/docs/tasks/administer-cluster/assign-pods-nodes.html"
|
||||
|
@ -18,7 +18,7 @@ Kubernetes cluster.
|
|||
|
||||
{% capture steps %}
|
||||
|
||||
## Adding a label to a node
|
||||
## Add a label to a node
|
||||
|
||||
1. List the nodes in your cluster:
|
||||
|
||||
|
@ -52,7 +52,7 @@ Kubernetes cluster.
|
|||
In the preceding output, you can see that the `worker0` node has a
|
||||
`disktype=ssd` label.
|
||||
|
||||
## Creating a pod that gets scheduled to your chosen node
|
||||
## Create a pod that gets scheduled to your chosen node
|
||||
|
||||
This pod configuration file describes a pod that has a node selector,
|
||||
`disktype: ssd`. This means that the pod will get scheduled on a node that has
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Attaching Handlers to Container Lifecycle Events
|
||||
title: Attach Handlers to Container Lifecycle Events
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
@ -21,7 +21,7 @@ Container is terminated.
|
|||
|
||||
{% capture steps %}
|
||||
|
||||
## Defining postStart and preStop handlers
|
||||
## Define postStart and preStop handlers
|
||||
|
||||
In this exercise, you create a Pod that has one Container. The Container has handlers
|
||||
for the postStart and preStop events.
|
||||
|
|
|
@ -24,7 +24,7 @@ This page shows you how to configure an application using a ConfigMap.
|
|||
|
||||
{% capture steps %}
|
||||
|
||||
## Using kubectl to create a ConfigMap
|
||||
## Use kubectl to create a ConfigMap
|
||||
|
||||
Use the `kubectl create configmap` command to create configmaps from [directories](#creating-configmaps-from-directories), [files](#creating-configmaps-from-files), or [literal values](#creating-configmaps-from-literal-values):
|
||||
|
||||
|
@ -41,7 +41,7 @@ The data source corresponds to a key-value pair in the ConfigMap, where
|
|||
|
||||
You can use [`kubectl describe`](docs/user-guide/kubectl/v1.6/#describe) or [`kubectl get`](docs/user-guide/kubectl/v1.6/#get) to retrieve information about a ConfigMap. The former shows a summary of the ConfigMap, while the latter returns the full contents of the ConfigMap.
|
||||
|
||||
### Creating ConfigMaps from directories
|
||||
### Create ConfigMaps from directories
|
||||
|
||||
You can use `kubectl create configmap` to create a ConfigMap from multiple files in the same directory.
|
||||
|
||||
|
@ -106,7 +106,7 @@ metadata:
|
|||
uid: b4952dc3-d670-11e5-8cd0-68f728db1985
|
||||
```
|
||||
|
||||
### Creating ConfigMaps from files
|
||||
### Create ConfigMaps from files
|
||||
|
||||
You can use `kubectl create configmap` to create a ConfigMap from an individual file, or from multiple files.
|
||||
|
||||
|
@ -188,7 +188,7 @@ metadata:
|
|||
uid: 05f8da22-d671-11e5-8cd0-68f728db1985
|
||||
```
|
||||
|
||||
### Creating ConfigMaps from literal values
|
||||
### Create ConfigMaps from literal values
|
||||
|
||||
You can use `kubectl create configmap` with the `--from-literal` argument to define a literal value from the command line:
|
||||
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
redirect_from:
|
||||
- "/docs/user-guide/liveness/"
|
||||
- "/docs/user-guide.liveness.html"
|
||||
title: Configuring Liveness and Readiness Probes
|
||||
title: Configure Liveness and Readiness Probes
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
@ -30,7 +30,7 @@ When a Pod is not ready, it is removed from Service load balancers.
|
|||
|
||||
{% capture steps %}
|
||||
|
||||
## Defining a liveness command
|
||||
## Define a liveness command
|
||||
|
||||
Many applications running for long periods of time eventually transition to
|
||||
broken states, and cannot recover except by being restarted. Kubernetes provides
|
||||
|
@ -117,7 +117,7 @@ NAME READY STATUS RESTARTS AGE
|
|||
liveness-exec 1/1 Running 1 1m
|
||||
```
|
||||
|
||||
## Defining a liveness HTTP request
|
||||
## Define a liveness HTTP request
|
||||
|
||||
Another kind of liveness probe uses an HTTP GET request. Here is the configuration
|
||||
file for a Pod that runs a container based on the `gcr.io/google_containers/liveness`
|
||||
|
@ -174,7 +174,7 @@ the Container has been restarted:
|
|||
kubectl describe pod liveness-http
|
||||
```
|
||||
|
||||
## Defining a TCP liveness probe
|
||||
## Define a TCP liveness probe
|
||||
|
||||
A third type of liveness probe uses a TCP Socket. With this configuration, the
|
||||
kubelet will attempt to open a socket to your container on the specified port.
|
||||
|
@ -196,7 +196,7 @@ starts. Just like the readiness probe, this will attempt to connect to the
|
|||
`goproxy` container on port 8080. If the liveness probe fails, the container
|
||||
will be restarted.
|
||||
|
||||
## Using a named port
|
||||
## Use a named port
|
||||
|
||||
You can use a named
|
||||
[ContainerPort](/docs/api-reference/v1.6/#containerport-v1-core)
|
||||
|
@ -214,7 +214,7 @@ livenessProbe:
|
|||
port: liveness-port
|
||||
```
|
||||
|
||||
## Defining readiness probes
|
||||
## Define readiness probes
|
||||
|
||||
Sometimes, applications are temporarily unable to serve traffic.
|
||||
For example, an application might need to load large data or configuration
|
||||
|
@ -244,7 +244,7 @@ Readiness and liveness probes can be used in parallel for the same container.
|
|||
Using both can ensure that traffic does not reach a container that is not ready
|
||||
for it, and that containers are restarted when they fail.
|
||||
|
||||
## Configuring Probes
|
||||
## Configure Probes
|
||||
|
||||
{% comment %}
|
||||
Eventually, some of this section could be moved to a concept topic.
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Configuring a Pod to Use a PersistentVolume for Storage
|
||||
title: Configure a Pod to Use a PersistentVolume for Storage
|
||||
redirect_from:
|
||||
- "/docs/user-guide/persistent-volumes/walkthrough/"
|
||||
- "/docs/user-guide/persistent-volumes/walkthrough.html"
|
||||
|
@ -34,7 +34,7 @@ do not already have a single-node cluster, you can create one by using
|
|||
|
||||
{% capture steps %}
|
||||
|
||||
## Creating an index.html file on your Node
|
||||
## Create an index.html file on your Node
|
||||
|
||||
Open a shell to the Node in your cluster. How you open a shell depends on how
|
||||
you set up your cluster. For example, if you are using Minikube, you can open a
|
||||
|
@ -48,7 +48,7 @@ In the `/tmp/data` directory, create an `index.html` file:
|
|||
|
||||
echo 'Hello from Kubernetes storage' > /tmp/data/index.html
|
||||
|
||||
## Creating a PersistentVolume
|
||||
## Create a PersistentVolume
|
||||
|
||||
In this exercise, you create a *hostPath* PersistentVolume. Kubernetes supports
|
||||
hostPath for development and testing on a single-node cluster. A hostPath
|
||||
|
@ -85,7 +85,7 @@ means it has not yet been bound to a PersistentVolumeClaim.
|
|||
task-pv-volume 10Gi RWO Retain Available 17s
|
||||
|
||||
|
||||
## Creating a PersistentVolumeClaim
|
||||
## Create a PersistentVolumeClaim
|
||||
|
||||
The next step is to create a PersistentVolumeClaim. Pods use PersistentVolumeClaims
|
||||
to request physical storage. In this exercise, you create a PersistentVolumeClaim
|
||||
|
@ -124,7 +124,7 @@ The output shows that the PersistentVolumeClaim is bound to your PersistentVolum
|
|||
NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
|
||||
task-pv-claim Bound task-pv-volume 10Gi RWO 5s
|
||||
|
||||
## Creating a Pod
|
||||
## Create a Pod
|
||||
|
||||
The next step is to create a Pod that uses your PersistentVolumeClaim as a volume.
|
||||
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Using ConfigMap Data in Pods
|
||||
title: Use ConfigMap Data in Pods
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
@ -14,7 +14,7 @@ This page provides a series of usage examples demonstrating how to configure Pod
|
|||
{% capture steps %}
|
||||
|
||||
|
||||
## Defining Pod environment variables using ConfigMap data
|
||||
## Define Pod environment variables using ConfigMap data
|
||||
|
||||
### Define a Pod environment variable with data from a single ConfigMap
|
||||
|
||||
|
@ -144,7 +144,7 @@ Note: This functionality is available to users running Kubernetes v1.6 and later
|
|||
1. Save the changes to the Pod specification. Now, the Pod's output includes `SPECIAL_LEVEL=very` and `SPECIAL_TYPE=charm`.
|
||||
|
||||
|
||||
## Using ConfigMap-defined environment variables in Pod commands
|
||||
## Use ConfigMap-defined environment variables in Pod commands
|
||||
|
||||
You can use ConfigMap-defined environment variables in the `command` section of the Pod specification using the `$(VAR_NAME)` Kubernetes substitution syntax.
|
||||
|
||||
|
@ -182,7 +182,7 @@ produces the following output in the `test-container` container:
|
|||
very charm
|
||||
```
|
||||
|
||||
## Adding ConfigMap data to a Volume
|
||||
## Add ConfigMap data to a Volume
|
||||
|
||||
As explained in [Configure Containers Using a ConfigMap](/docs/tasks/configure-pod-container/configmap.html), when you create a ConfigMap using ``--from-file``, the filename becomes a key stored in the `data` section of the ConfigMap. The file contents become the key's value.
|
||||
|
||||
|
@ -268,7 +268,7 @@ When the pod runs, the command (`"cat /etc/config/keys/special.level"`) produces
|
|||
very
|
||||
```
|
||||
|
||||
### Projecting keys to specific paths and file permissions
|
||||
### Project keys to specific paths and file permissions
|
||||
|
||||
You can project keys to specific paths and specific permissions on a per-file
|
||||
basis. The [Secrets](/docs/concepts/configuration/secret#using-secrets-as-files-from-a-pod) user guide explains the syntax.
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Configuring Pod Initialization
|
||||
title: Configure Pod Initialization
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
@ -16,7 +16,7 @@ application Container runs.
|
|||
|
||||
{% capture steps %}
|
||||
|
||||
## Creating a Pod that has an Init Container
|
||||
## Create a Pod that has an Init Container
|
||||
|
||||
In this exercise you create a Pod that has one application Container and one
|
||||
Init Container. The init container runs to completion before the application
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
assignees:
|
||||
- jpeeler
|
||||
- pmorie
|
||||
title: Configuring a Pod to Use a Projected Volume for Storage
|
||||
title: Configure a Pod to Use a Projected Volume for Storage
|
||||
redirect_from:
|
||||
- "/docs/tasks/configure-pod-container/projected-volume/"
|
||||
- "/docs/user-guide/projected-volume/"
|
||||
|
|
|
@ -3,7 +3,7 @@ assignees:
|
|||
- bprashanth
|
||||
- liggitt
|
||||
- thockin
|
||||
title: Configuring Service Accounts for Pods
|
||||
title: Configure Service Accounts for Pods
|
||||
redirect_from:
|
||||
- "/docs/user-guide/service-accounts/"
|
||||
- "/docs/user-guide/service-accounts.html"
|
||||
|
@ -26,7 +26,7 @@ cluster). Processes in containers inside pods can also contact the apiserver.
|
|||
When they do, they are authenticated as a particular Service Account (e.g.
|
||||
`default`).
|
||||
|
||||
## Using the Default Service Account to access the API server.
|
||||
## Use the Default Service Account to access the API server.
|
||||
|
||||
When you create a pod, if you do not specify a service account, it is
|
||||
automatically assigned the `default` service account in the same namespace.
|
||||
|
@ -65,7 +65,7 @@ spec:
|
|||
|
||||
The pod spec takes precedence over the service account if both specify a `automountServiceAccountToken` value.
|
||||
|
||||
## Using Multiple Service Accounts.
|
||||
## Use Multiple Service Accounts.
|
||||
|
||||
Every namespace has a default service account resource called `default`.
|
||||
You can list this and any other serviceAccount resources in the namespace with this command:
|
||||
|
@ -164,7 +164,7 @@ namespace: 7 bytes
|
|||
|
||||
> Note that the content of `token` is elided here.
|
||||
|
||||
## Adding ImagePullSecrets to a service account
|
||||
## Add ImagePullSecrets to a service account
|
||||
|
||||
First, create an imagePullSecret, as described [here](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)
|
||||
Next, verify it has been created. For example:
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Configuring a Pod to Use a Volume for Storage
|
||||
title: Configure a Pod to Use a Volume for Storage
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
@ -23,7 +23,7 @@ key-value cache and store.
|
|||
|
||||
{% capture steps %}
|
||||
|
||||
## Configuring a volume for a Pod
|
||||
## Configure a volume for a Pod
|
||||
|
||||
In this exercise, you create a Pod that runs one Container. This Pod has a
|
||||
Volume of type
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Pulling an Image from a Private Registry
|
||||
title: Pull an Image from a Private Registry
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
@ -20,7 +20,7 @@ private Docker registry or repository.
|
|||
|
||||
{% capture steps %}
|
||||
|
||||
## Logging in to Docker
|
||||
## Log in to Docker
|
||||
|
||||
docker login
|
||||
|
||||
|
@ -45,7 +45,7 @@ The output contains a section similar to this:
|
|||
|
||||
NOTE: If you use a Docker credentials store, you won't see that `auth` entry but a `credsStore` entry with the name of the store as value.
|
||||
|
||||
## Creating a Secret that holds your authorization token
|
||||
## Create a Secret that holds your authorization token
|
||||
|
||||
Create a Secret named `regsecret`:
|
||||
|
||||
|
@ -95,7 +95,7 @@ The output is similar to this:
|
|||
Notice that the secret data contains the authorization token from your
|
||||
`config.json` file.
|
||||
|
||||
## Creating a Pod that uses your Secret
|
||||
## Create a Pod that uses your Secret
|
||||
|
||||
Here is a configuration file for a Pod that needs access to your secret data:
|
||||
|
||||
|
|
|
@ -3,7 +3,7 @@
|
|||
assignees:
|
||||
- cdrage
|
||||
|
||||
title: Translating a Docker Compose File to Kubernetes Resources
|
||||
title: Translate a Docker Compose File to Kubernetes Resources
|
||||
redirect_from:
|
||||
- "/docs/tools/kompose/"
|
||||
- "/docs/tools/kompose/index.html"
|
||||
|
|
Loading…
Reference in New Issue