Merge pull request #20920 from sftim/20200512_fix_deployment_concept_markdown

Fix note shortcodes in Deployment concept
pull/20806/head
Kubernetes Prow Robot 2020-05-12 12:48:22 -07:00 committed by GitHub
commit 9f82c32a61
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 73 additions and 65 deletions

View File

@ -53,10 +53,10 @@ In this example:
In this case, you simply select a label that is defined in the Pod template (`app: nginx`).
However, more sophisticated selection rules are possible,
as long as the Pod template itself satisfies the rule.
{{< note >}}
The `.spec.selector.matchLabels` field is a map of {key,value} pairs. A single {key,value} in the `matchLabels` map is equivalent to an element of `matchExpressions`, whose key field is "key" the operator is "In", and the values array contains only "value". All of the requirements, from both `matchLabels` and `matchExpressions`, must be satisfied in order to match.
{{< /note >}}
{{< note >}}
The `.spec.selector.matchLabels` field is a map of {key,value} pairs. A single {key,value} in the `matchLabels` map is equivalent to an element of `matchExpressions`, whose key field is "key" the operator is "In", and the values array contains only "value". All of the requirements, from both `matchLabels` and `matchExpressions`, must be satisfied in order to match.
{{< /note >}}
* The `template` field contains the following sub-fields:
* The Pods are labeled `app: nginx`using the `.metadata.labels` field.
@ -65,83 +65,91 @@ In this example:
[Docker Hub](https://hub.docker.com/) image at version 1.14.2.
* Create one container and name it `nginx` using the `.spec.template.spec.containers[0].name` field.
Follow the steps given below to create the above Deployment:
Before you begin, make sure your Kubernetes cluster is up and running.
Follow the steps given below to create the above Deployment:
Before you begin, make sure your Kubernetes cluster is up and running.
1. Create the Deployment by running the following command:
1. Create the Deployment by running the following command:
{{< note >}}
You may specify the `--record` flag to write the command executed in the resource annotation `kubernetes.io/change-cause`. It is useful for future introspection. For example, to see the commands executed in each Deployment revision.
{{< /note >}}
```shell
kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
```
```shell
kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
```
{{< note >}}
You can specify the `--record` flag to write the command executed in the resource annotation `kubernetes.io/change-cause`. The recorded change is useful for future introspection. For example, to see the commands executed in each Deployment revision.
{{< /note >}}
2. Run `kubectl get deployments` to check if the Deployment was created. If the Deployment is still being created, the output is similar to the following:
```shell
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 0/3 0 0 1s
```
When you inspect the Deployments in your cluster, the following fields are displayed:
* `NAME` lists the names of the Deployments in the namespace.
* `READY` displays how many replicas of the application are available to your users. It follows the pattern ready/desired.
* `UP-TO-DATE` displays the number of replicas that have been updated to achieve the desired state.
* `AVAILABLE` displays how many replicas of the application are available to your users.
* `AGE` displays the amount of time that the application has been running.
2. Run `kubectl get deployments` to check if the Deployment was created.
Notice how the number of desired replicas is 3 according to `.spec.replicas` field.
If the Deployment is still being created, the output is similar to the following:
```shell
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 0/3 0 0 1s
```
When you inspect the Deployments in your cluster, the following fields are displayed:
* `NAME` lists the names of the Deployments in the namespace.
* `READY` displays how many replicas of the application are available to your users. It follows the pattern ready/desired.
* `UP-TO-DATE` displays the number of replicas that have been updated to achieve the desired state.
* `AVAILABLE` displays how many replicas of the application are available to your users.
* `AGE` displays the amount of time that the application has been running.
3. To see the Deployment rollout status, run `kubectl rollout status deployment.v1.apps/nginx-deployment`. The output is similar to this:
```shell
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment.apps/nginx-deployment successfully rolled out
```
Notice how the number of desired replicas is 3 according to `.spec.replicas` field.
4. Run the `kubectl get deployments` again a few seconds later. The output is similar to this:
```shell
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 18s
```
Notice that the Deployment has created all three replicas, and all replicas are up-to-date (they contain the latest Pod template) and available.
3. To see the Deployment rollout status, run `kubectl rollout status deployment.v1.apps/nginx-deployment`.
5. To see the ReplicaSet (`rs`) created by the Deployment, run `kubectl get rs`. The output is similar to this:
```shell
NAME DESIRED CURRENT READY AGE
nginx-deployment-75675f5897 3 3 3 18s
```
ReplicaSet output shows the following fields:
* `NAME` lists the names of the ReplicaSets in the namespace.
* `DESIRED` displays the desired number of _replicas_ of the application, which you define when you create the Deployment. This is the _desired state_.
* `CURRENT` displays how many replicas are currently running.
* `READY` displays how many replicas of the application are available to your users.
* `AGE` displays the amount of time that the application has been running.
Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[RANDOM-STRING]`. The random string is
randomly generated and uses the `pod-template-hash` as a seed.
The output is similar to:
```shell
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment.apps/nginx-deployment successfully rolled out
```
6. To see the labels automatically generated for each Pod, run `kubectl get pods --show-labels`. The following output is returned:
```shell
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
```
The created ReplicaSet ensures that there are three `nginx` Pods.
4. Run the `kubectl get deployments` again a few seconds later.
The output is similar to this:
```shell
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 18s
```
Notice that the Deployment has created all three replicas, and all replicas are up-to-date (they contain the latest Pod template) and available.
{{< note >}}
You must specify an appropriate selector and Pod template labels in a Deployment (in this case,
`app: nginx`). Do not overlap labels or selectors with other controllers (including other Deployments and StatefulSets). Kubernetes doesn't stop you from overlapping, and if multiple controllers have overlapping selectors those controllers might conflict and behave unexpectedly.
{{< /note >}}
5. To see the ReplicaSet (`rs`) created by the Deployment, run `kubectl get rs`. The output is similar to this:
```shell
NAME DESIRED CURRENT READY AGE
nginx-deployment-75675f5897 3 3 3 18s
```
ReplicaSet output shows the following fields:
* `NAME` lists the names of the ReplicaSets in the namespace.
* `DESIRED` displays the desired number of _replicas_ of the application, which you define when you create the Deployment. This is the _desired state_.
* `CURRENT` displays how many replicas are currently running.
* `READY` displays how many replicas of the application are available to your users.
* `AGE` displays the amount of time that the application has been running.
Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[RANDOM-STRING]`.
The random string is randomly generated and uses the `pod-template-hash` as a seed.
6. To see the labels automatically generated for each Pod, run `kubectl get pods --show-labels`.
The output is similar to:
```shell
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
```
The created ReplicaSet ensures that there are three `nginx` Pods.
{{< note >}}
You must specify an appropriate selector and Pod template labels in a Deployment
(in this case, `app: nginx`).
Do not overlap labels or selectors with other controllers (including other Deployments and StatefulSets). Kubernetes doesn't stop you from overlapping, and if multiple controllers have overlapping selectors those controllers might conflict and behave unexpectedly.
{{< /note >}}
### Pod-template-hash label
{{< note >}}
{{< caution >}}
Do not change this label.
{{< /note >}}
{{< /caution >}}
The `pod-template-hash` label is added by the Deployment controller to every ReplicaSet that a Deployment creates or adopts.