kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

New deployments endpoint (#2986) 

* Update deployments for 1.6

* Update all deployments in docs to use the new endpoint
reviewable/pr2976/r1
Maciej Szulik 2017-03-24 19:03:01 +01:00 committed by Andrew Chen
parent ddc206709f
commit c4dca21649
41 changed files with 135 additions and 135 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
docs/admin/authentication.md
View File

@ -151,8 +151,8 @@ authentication is currently supported for convenience while we finish making the
more secure modes described above easier to use.
The basic auth file is a csv file with a minimum of 3 columns: password, user name, user id.
In Kubernetes version 1.6 and later, you can specify an optional fourth column containing
comma-separated group names. If you have more than one group, you must enclose the fourth
In Kubernetes version 1.6 and later, you can specify an optional fourth column containing
comma-separated group names. If you have more than one group, you must enclose the fourth
column value in double quotes ("). See the following example:
```conf
@ -181,7 +181,7 @@ talk to the API server. Accounts may be explicitly associated with pods using th
NOTE: `serviceAccountName` is usually omitted because this is done automatically.
```
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
@ -568,13 +568,13 @@ For example, on a server with token authentication configured, and anonymous acc
a request providing an invalid bearer token would receive a `401 Unauthorized` error.
A request providing no bearer token would be treated as an anonymous request.
In 1.5.1-1.5.x, anonymous access is disabled by default, and can be enabled by
In 1.5.1-1.5.x, anonymous access is disabled by default, and can be enabled by
passing the `--anonymous-auth=false` option to the API server.
In 1.6+, anonymous access is enabled by default if an authorization mode other than `AlwaysAllow`
is used, and can be disabled by passing the `--anonymous-auth=false` option to the API server.
Starting in 1.6, the ABAC and RBAC authorizers require explicit authorization of the
`system:anonymous` user or the `system:unauthenticated` group, so legacy policy rules
Starting in 1.6, the ABAC and RBAC authorizers require explicit authorization of the
`system:anonymous` user or the `system:unauthenticated` group, so legacy policy rules
that grant access to the `*` user or `*` group do not include anonymous users.
## Plugin Development

4
docs/admin/multiple-schedulers/my-scheduler.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
labels:
@ -10,7 +10,7 @@ spec:
replicas: 1
template:
metadata:
labels:
labels:
component: scheduler
tier: control-plane
version: second

2
docs/concepts/abstractions/nginx-deployment.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx-deployment

42
docs/concepts/cluster-administration/manage-deployment.md
View File

@ -85,8 +85,8 @@ NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-nginx-svc 10.0.0.208 80/TCP 0s
```
With the above commands, we first create resources under docs/user-guide/nginx/ and print the resources created with `-o name` output format
(print each resource as resource/name). Then we `grep` only the "service", and then print it with `kubectl get`.
With the above commands, we first create resources under docs/user-guide/nginx/ and print the resources created with `-o name` output format
(print each resource as resource/name). Then we `grep` only the "service", and then print it with `kubectl get`.
If you happen to organize your resources across several subdirectories within a particular directory, you can recursively perform the operations on the subdirectories also, by specifying `--recursive` or `-R` alongside the `--filename,-f` flag.
@ -102,7 +102,7 @@ project/k8s/development
└── my-pvc.yaml
```
By default, performing a bulk operation on `project/k8s/development` will stop at the first level of the directory, not processing any subdirectories. If we tried to create the resources in this directory using the following command, we'd encounter an error:
By default, performing a bulk operation on `project/k8s/development` will stop at the first level of the directory, not processing any subdirectories. If we tried to create the resources in this directory using the following command, we'd encounter an error:
```shell
$ kubectl create -f project/k8s/development
@ -131,7 +131,7 @@ deployment "my-deployment" created
persistentvolumeclaim "my-pvc" created
```
If you're interested in learning more about `kubectl`, go ahead and read [kubectl Overview](/docs/user-guide/kubectl-overview).
If you're interested in learning more about `kubectl`, go ahead and read [kubectl Overview](/docs/user-guide/kubectl-overview).
## Using labels effectively
@ -185,9 +185,9 @@ guestbook-redis-slave-qgazl 1/1 Running 0 3m
## Canary deployments
Another scenario where multiple labels are needed is to distinguish deployments of different releases or configurations of the same component. It is common practice to deploy a *canary* of a new application release (specified via image tag in the pod template) side by side with the previous release so that the new release can receive live production traffic before fully rolling it out.
Another scenario where multiple labels are needed is to distinguish deployments of different releases or configurations of the same component. It is common practice to deploy a *canary* of a new application release (specified via image tag in the pod template) side by side with the previous release so that the new release can receive live production traffic before fully rolling it out.
For instance, you can use a `track` label to differentiate different releases.
For instance, you can use a `track` label to differentiate different releases.
The primary, stable release would have a `track` label with value as `stable`:
@ -227,13 +227,13 @@ The frontend service would span both sets of replicas by selecting the common su
```
You can tweak the number of replicas of the stable and canary releases to determine the ratio of each release that will receive live production traffic (in this case, 3:1).
Once you're confident, you can update the stable track to the new application release and remove the canary one.
Once you're confident, you can update the stable track to the new application release and remove the canary one.
For a more concrete example, check the [tutorial of deploying Ghost](https://github.com/kelseyhightower/talks/tree/master/kubecon-eu-2016/demo#deploy-a-canary).
## Updating labels
Sometimes existing pods and other resources need to be relabeled before creating new resources. This can be done with `kubectl label`.
Sometimes existing pods and other resources need to be relabeled before creating new resources. This can be done with `kubectl label`.
For example, if you want to label all your nginx pods as frontend tier, simply run:
```shell
@ -243,8 +243,8 @@ pod "my-nginx-2035384211-u2c7e" labeled
pod "my-nginx-2035384211-u3t6x" labeled
```
This first filters all pods with the label "app=nginx", and then labels them with the "tier=fe".
To see the pods you just labeled, run:
This first filters all pods with the label "app=nginx", and then labels them with the "tier=fe".
To see the pods you just labeled, run:
```shell
$ kubectl get pods -l app=nginx -L tier
@ -284,7 +284,7 @@ $ kubectl scale deployment/my-nginx --replicas=1
deployment "my-nginx" scaled
```
Now you only have one pod managed by the deployment.
Now you only have one pod managed by the deployment.
```shell
$ kubectl get pods -l app=nginx
@ -294,25 +294,25 @@ my-nginx-2035384211-j5fhi 1/1 Running 0 30m
To have the system automatically choose the number of nginx replicas as needed, ranging from 1 to 3, do:
```shell
```shell
$ kubectl autoscale deployment/my-nginx --min=1 --max=3
deployment "my-nginx" autoscaled
```
Now your nginx replicas will be scaled up and down as needed, automatically.
Now your nginx replicas will be scaled up and down as needed, automatically.
For more information, please see [kubectl scale](/docs/user-guide/kubectl/kubectl_scale/), [kubectl autoscale](/docs/user-guide/kubectl/kubectl_autoscale/) and [horizontal pod autoscaler](/docs/user-guide/horizontal-pod-autoscaler/) document.
## In-place updates of resources
Sometimes it's necessary to make narrow, non-disruptive updates to resources you've created.
Sometimes it's necessary to make narrow, non-disruptive updates to resources you've created.
### kubectl apply
It is suggested to maintain a set of configuration files in source control (see [configuration as code](http://martinfowler.com/bliki/InfrastructureAsCode.html)),
so that they can be maintained and versioned along with the code for the resources they configure.
Then, you can use [`kubectl apply`](/docs/user-guide/kubectl/kubectl_apply/) to push your configuration changes to the cluster.
Then, you can use [`kubectl apply`](/docs/user-guide/kubectl/kubectl_apply/) to push your configuration changes to the cluster.
This command will compare the version of the configuration that you're pushing with the previous version and apply the changes you've made, without overwriting any automated changes to properties you haven't specified.
@ -357,13 +357,13 @@ For more information, please see [kubectl edit](/docs/user-guide/kubectl/kubectl
Suppose you want to fix a typo of the container's image of a Deployment. One way to do that is with `kubectl patch`:
```shell
# Suppose you have a Deployment with a container named "nginx" and its image "nignx" (typo),
# Suppose you have a Deployment with a container named "nginx" and its image "nignx" (typo),
# use container name "nginx" as a key to update the image from "nignx" (typo) to "nginx"
$ kubectl get deployment my-nginx -o yaml
```
```yaml
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
...
spec:
@ -382,7 +382,7 @@ $ kubectl get pod my-nginx-1jgkf -o yaml
```
```yaml
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
...
spec:
@ -414,8 +414,8 @@ deployment "my-nginx" replaced
At some point, you'll eventually need to update your deployed application, typically by specifying a new image or image tag, as in the canary deployment scenario above. `kubectl` supports several update operations, each of which is applicable to different scenarios.
We'll guide you through how to create and update applications with Deployments. If your deployed application is managed by Replication Controllers,
you should read [how to use `kubectl rolling-update`](/docs/tasks/run-application/rolling-update-replication-controller/) instead.
We'll guide you through how to create and update applications with Deployments. If your deployed application is managed by Replication Controllers,
you should read [how to use `kubectl rolling-update`](/docs/tasks/run-application/rolling-update-replication-controller/) instead.
Let's say you were running version 1.7.9 of nginx:
@ -424,7 +424,7 @@ $ kubectl run my-nginx --image=nginx:1.7.9 --replicas=3
deployment "my-nginx" created
```
To update to version 1.9.1, simply change `.spec.template.spec.containers[0].image` from `nginx:1.7.9` to `nginx:1.9.1`, with the kubectl commands we learned above.
To update to version 1.9.1, simply change `.spec.template.spec.containers[0].image` from `nginx:1.7.9` to `nginx:1.9.1`, with the kubectl commands we learned above.
```shell
$ kubectl edit deployment/my-nginx

2
docs/concepts/cluster-administration/nginx-app.yaml
View File

@ -11,7 +11,7 @@ spec:
selector:
app: nginx
---
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: my-nginx

2
docs/concepts/overview/working-with-objects/nginx-deployment.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx-deployment

2
docs/concepts/services-networking/curlpod.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: curl-deployment

2
docs/concepts/services-networking/nginx-secure-app.yaml
View File

@ -17,7 +17,7 @@ spec:
selector:
run: my-nginx
---
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: my-nginx

2
docs/concepts/services-networking/run-my-nginx.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: my-nginx

6
docs/getting-started-guides/meanstack.md
View File

@ -198,7 +198,7 @@ Now, we need to create a Deployment that will run the database. I'm using a Depl
### `db-deployment.yml`
```yaml
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: mongo-deployment
@ -317,7 +317,7 @@ Let's look at the Deployment configuration:
### `web-deployment.yml`
```yaml
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: web-deployment
@ -371,7 +371,7 @@ At this point, the local directory looks like this
```shell
$ ls
Dockerfile
Dockerfile
app
db-deployment.yml
db-service.yml

2
docs/tasks/administer-cluster/dns-horizontal-autoscaler.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: kube-dns-autoscaler

2
docs/tutorials/connecting-apps/frontend.yaml
View File

@ -12,7 +12,7 @@ spec:
targetPort: 80
type: LoadBalancer
---
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: frontend

2
docs/tutorials/connecting-apps/hello.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: hello

22
docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md
View File

@ -89,7 +89,7 @@ metadata:
# This is the json representation of simple_deployment.yaml
# It was written by kubectl apply when the object was created
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"extensions/v1beta1","kind":"Deployment",
{"apiVersion":"apps/v1beta1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"minReadySeconds":5,"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx",
@ -160,7 +160,7 @@ metadata:
# This is the json representation of simple_deployment.yaml
# It was written by kubectl apply when the object was created
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"extensions/v1beta1","kind":"Deployment",
{"apiVersion":"apps/v1beta1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"minReadySeconds":5,"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx",
@ -204,7 +204,7 @@ The output shows that the `replicas` field has been set to 2, and the `last-appl
annotation does not contain a `replicas` field:
```
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
annotations:
@ -212,7 +212,7 @@ metadata:
# note that the annotation does not contain replicas
# because it was not updated through apply
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"extensions/v1beta1","kind":"Deployment",
{"apiVersion":"apps/v1beta1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"minReadySeconds":5,"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx",
@ -264,7 +264,7 @@ The output shows the following changes to the live configuration:
- The `last-applied-configuration` annotation no longer contains the `minReadySeconds` field.
```shell
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
annotations:
@ -272,7 +272,7 @@ metadata:
# The annotation contains the updated image to nginx 1.11.9,
# but does not contain the updated replicas to 2
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"extensions/v1beta1","kind":"Deployment",
{"apiVersion":"apps/v1beta1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.11.9","name":"nginx",
@ -395,7 +395,7 @@ Here's an example. Suppose this is the configuration file for a Deployment objec
Also, suppose this is the live configuration for the same Deployment object:
```shell
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
annotations:
@ -403,7 +403,7 @@ metadata:
# note that the annotation does not contain replicas
# because it was not updated through apply
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"extensions/v1beta1","kind":"Deployment",
{"apiVersion":"apps/v1beta1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"minReadySeconds":5,"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx",
@ -446,7 +446,7 @@ Here are the merge calculations that would be performed by `kubectl apply`:
Here is the live configuration that is the result of the merge:
```shell
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
annotations:
@ -454,7 +454,7 @@ metadata:
# The annotation contains the updated image to nginx 1.11.9,
# but does not contain the updated replicas to 2
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"extensions/v1beta1","kind":"Deployment",
{"apiVersion":"apps/v1beta1","kind":"Deployment",
"metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
"spec":{"template":{"metadata":{"labels":{"app":"nginx"}},
"spec":{"containers":[{"image":"nginx:1.11.9","name":"nginx",
@ -693,7 +693,7 @@ The output shows that the API server set several fields to default values in the
configuration. These fields were not specified in the configuration file.
```shell
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
# ...
spec:

2
docs/tutorials/object-management-kubectl/simple_deployment.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx-deployment

2
docs/tutorials/object-management-kubectl/update_deployment.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx-deployment

2
docs/tutorials/stateful-application/mysql-deployment.yaml
View File

@ -20,7 +20,7 @@ spec:
requests:
storage: 20Gi
---
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: mysql

2
docs/tutorials/stateless-application/deployment-scale.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx-deployment

2
docs/tutorials/stateless-application/deployment-update.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx-deployment

2
docs/tutorials/stateless-application/deployment.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx-deployment

2
docs/user-guide/bad-nginx-deployment.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx-deployment

2
docs/user-guide/curlpod.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: curl-deployment

4
docs/user-guide/debugging-services.md
View File

@ -83,12 +83,12 @@ $ kubectl run hostnames --image=gcr.io/google_containers/serve_hostname \
deployment "hostnames" created
```
`kubectl` commands will print the type and name of the resource created or mutated, which can then be used in subsequent commands.
`kubectl` commands will print the type and name of the resource created or mutated, which can then be used in subsequent commands.
Note that this is the same as if you had started the `Deployment` with
the following YAML:
```yaml
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: hostnames

2
docs/user-guide/deployment.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx-deployment

96
docs/user-guide/deployments.md
View File

@ -19,9 +19,9 @@ by new ones.
A typical use case is:
* Create a Deployment to bring up a Replica Set and Pods.
* Check the status of a Deployment to see if it succeeds or not.
* Check the status of a Deployment to see if it succeeds or not.
* Later, update that Deployment to recreate the Pods (for example, to use a new image).
* Rollback to an earlier Deployment revision if the current Deployment isn't stable.
* Rollback to an earlier Deployment revision if the current Deployment isn't stable.
* Pause and resume a Deployment.
## Creating a Deployment
@ -48,7 +48,7 @@ NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 0 0 0 1s
```
This indicates that the Deployment's number of desired replicas is 3 (according to deployment's `.spec.replicas`), the number of current replicas (`.status.replicas`) is 0, the number of up-to-date replicas (`.status.updatedReplicas`) is 0, and the number of available replicas (`.status.availableReplicas`) is also 0.
This indicates that the Deployment's number of desired replicas is 3 (according to deployment's `.spec.replicas`), the number of current replicas (`.status.replicas`) is 0, the number of up-to-date replicas (`.status.updatedReplicas`) is 0, and the number of available replicas (`.status.availableReplicas`) is also 0.
Running the `get` again a few seconds later, should give:
@ -63,10 +63,10 @@ This indicates that the Deployment has created all three replicas, and all repli
```shell
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-2035384211 3 3 0 18s
nginx-deployment-2035384211 3 3 0 18s
```
You may notice that the name of the Replica Set is always `<the name of the Deployment>-<hash value of the pod template>`.
You may notice that the name of the Replica Set is always `<the name of the Deployment>-<hash value of the pod template>`.
```shell
$ kubectl get pods --show-labels
@ -83,8 +83,8 @@ The created Replica Set will ensure that there are three nginx Pods at all times
## Updating a Deployment
**Note:** a Deployment's rollout is triggered if and only if the Deployment's pod template (i.e. `.spec.template`) is changed,
e.g. updating labels or container images of the template. Other updates, such as scaling the Deployment, will not trigger a rollout.
**Note:** a Deployment's rollout is triggered if and only if the Deployment's pod template (i.e. `.spec.template`) is changed,
e.g. updating labels or container images of the template. Other updates, such as scaling the Deployment, will not trigger a rollout.
Suppose that we now want to update the nginx Pods to start using the `nginx:1.9.1` image
instead of the `nginx:1.7.9` image.
@ -117,9 +117,9 @@ NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 36s
```
The number of up-to-date replicas indicates that the Deployment has updated the replicas to the latest configuration.
The current replicas indicates the total replicas this Deployment manages, and the available replicas indicates the
number of current replicas that are available.
The number of up-to-date replicas indicates that the Deployment has updated the replicas to the latest configuration.
The current replicas indicates the total replicas this Deployment manages, and the available replicas indicates the
number of current replicas that are available.
We can run `kubectl get rs` to see that the Deployment updated the Pods by creating a new Replica Set and scaling it up to 3 replicas, as well as scaling down the old Replica Set to 0 replicas.
@ -143,10 +143,10 @@ nginx-deployment-1564180365-z9gth 1/1 Running 0 14s
Next time we want to update these Pods, we only need to update the Deployment's pod template again.
Deployment can ensure that only a certain number of Pods may be down while they are being updated. By
default, it ensures that at least 1 less than the desired number of Pods are
up (1 max unavailable).
default, it ensures that at least 25% less than the desired number of Pods are
up (25% max unavailable).
Deployment can also ensure that only a certain number of Pods may be created above the desired number of Pods. By default, it ensures that at most 1 more than the desired number of Pods are up (1 max surge).
Deployment can also ensure that only a certain number of Pods may be created above the desired number of Pods. By default, it ensures that at most 25% more than the desired number of Pods are up (25% max surge).
For example, if you look at the above Deployment closely, you will see that
it first created a new Pod, then deleted some old Pods and created new ones. It
@ -204,13 +204,13 @@ before changing course.
## Rolling Back a Deployment
Sometimes you may want to rollback a Deployment; for example, when the Deployment is not stable, such as crash looping.
By default, all of the Deployment's rollout history is kept in the system so that you can rollback anytime you want
(you can change that by specifying [revision history limit](/docs/user-guide/deployments/#revision-history-limit)).
By default, two previous Deployment's rollout history are kept in the system so that you can rollback anytime you want
(you can change that by modifying [revision history limit](/docs/user-guide/deployments/#revision-history-limit)).
**Note:** a Deployment's revision is created when a Deployment's rollout is triggered. This means that the new revision is created
if and only if the Deployment's pod template (i.e. `.spec.template`) is changed, e.g. updating labels or container images of the template.
**Note:** a Deployment's revision is created when a Deployment's rollout is triggered. This means that the new revision is created
if and only if the Deployment's pod template (i.e. `.spec.template`) is changed, e.g. updating labels or container images of the template.
Other updates, such as scaling the Deployment, will not create a Deployment revision -- so that we can facilitate simultaneous manual- or
auto-scaling. This implies that when you rollback to an earlier revision, only the Deployment's pod template part will be rolled back.
auto-scaling. This implies that when you rollback to an earlier revision, only the Deployment's pod template part will be rolled back.
Suppose that we made a typo while updating the Deployment, by putting the image name as `nginx:1.91` instead of `nginx:1.9.1`:
@ -222,7 +222,7 @@ deployment "nginx-deployment" image updated
The rollout will be stuck.
```shell
$ kubectl rollout status deployments nginx-deployment
$ kubectl rollout status deployments nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
```
@ -241,7 +241,7 @@ nginx-deployment-3066724191 2 2 2 6s
Looking at the Pods created, you will see that the 2 Pods created by new Replica Set are stuck in an image pull loop.
```shell
$ kubectl get pods
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-deployment-1564180365-70iae 1/1 Running 0 25s
nginx-deployment-1564180365-jbqqo 1/1 Running 0 25s
@ -278,7 +278,7 @@ Events:
13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 2
```
To fix this, we need to rollback to a previous revision of Deployment that is stable.
To fix this, we need to rollback to a previous revision of Deployment that is stable.
### Checking Rollout History of a Deployment
@ -293,7 +293,7 @@ REVISION CHANGE-CAUSE
3 kubectl set image deployment/nginx-deployment nginx=nginx:1.91
```
Because we recorded the command while creating this Deployment using `--record`, we can easily see the changes we made in each revision.
Because we recorded the command while creating this Deployment using `--record`, we can easily see the changes we made in each revision.
To further see the details of each revision, run:
@ -330,16 +330,16 @@ $ kubectl rollout undo deployment/nginx-deployment --to-revision=2
deployment "nginx-deployment" rolled back
```
For more details about rollout related commands, read [`kubectl rollout`](/docs/user-guide/kubectl/kubectl_rollout/).
For more details about rollout related commands, read [`kubectl rollout`](/docs/user-guide/kubectl/kubectl_rollout/).
The Deployment is now rolled back to a previous stable revision. As you can see, a `DeploymentRollback` event for rolling back to revision 2 is generated from Deployment controller.
The Deployment is now rolled back to a previous stable revision. As you can see, a `DeploymentRollback` event for rolling back to revision 2 is generated from Deployment controller.
```shell
$ kubectl get deployment
$ kubectl get deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 30m
$ kubectl describe deployment
$ kubectl describe deployment
Name: nginx-deployment
Namespace: default
CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700
@ -369,8 +369,8 @@ Events:
### Clean up Policy
You can set `.spec.revisionHistoryLimit` field to specify how much revision history of this deployment you want to keep. By default,
all revision history will be kept; explicitly setting this field to `0` disallows a deployment being rolled back.
You can set `.spec.revisionHistoryLimit` field to specify how much revision history of this deployment you want to keep. By default,
all revision history will be kept; explicitly setting this field to `0` disallows a deployment being rolled back.
## Scaling a Deployment
@ -441,9 +441,9 @@ nginx-deployment-1989198191 7 7 0 7m
nginx-deployment-618515232 11 11 11 7m
```
## Pausing and Resuming a Deployment
## Pausing and Resuming a Deployment
You can also pause a Deployment mid-way and then resume it. A use case is to support canary deployment.
You can also pause a Deployment mid-way and then resume it. A use case is to support canary deployment.
Update the Deployment again and then pause the Deployment with `kubectl rollout pause`:
@ -453,12 +453,12 @@ deployment "nginx-deployment" image updated
deployment "nginx-deployment" paused
```
Note that any current state of the Deployment will continue its function, but new updates to the Deployment will not have an effect as long as the Deployment is paused.
Note that any current state of the Deployment will continue its function, but new updates to the Deployment will not have an effect as long as the Deployment is paused.
The Deployment was still in progress when we paused it, so the actions of scaling up and down Replica Sets are paused too.
The Deployment was still in progress when we paused it, so the actions of scaling up and down Replica Sets are paused too.
```shell
$ kubectl get rs
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-1564180365 2 2 2 1h
nginx-deployment-2035384211 2 2 0 1h
@ -468,7 +468,7 @@ nginx-deployment-3066724191 0 0 0 1h
In a separate terminal, watch for rollout status changes and you'll see the rollout won't continue:
```shell
$ kubectl rollout status deployment/nginx-deployment
$ kubectl rollout status deployment/nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
```
@ -482,7 +482,7 @@ deployment "nginx-deployment" resumed
Then the Deployment will continue and finish the rollout:
```shell
$ kubectl rollout status deployment/nginx-deployment
$ kubectl rollout status deployment/nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment spec update to be observed...
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
@ -490,7 +490,7 @@ deployment nginx-deployment successfully rolled out
```
```shell
$ kubectl get rs
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-1564180365 3 3 3 1h
nginx-deployment-2035384211 0 0 0 1h
@ -518,7 +518,7 @@ You can monitor the progress for a Deployment by using `kubectl rollout status`.
### Complete Deployment
Kubernetes marks a Deployment as _complete_ when it has the following characteristics:
Kubernetes marks a Deployment as _complete_ when it has the following characteristics:
* The Deployment has minimum availability. Minimum availability means that the Deployment's number of available replicas
equals or exceeds the number required by the Deployment strategy.
@ -659,12 +659,12 @@ $ echo $?
All actions that apply to a complete Deployment also apply to a failed Deployment. You can scale it up/down, roll back
to a previous revision, or even pause it if you need to apply multiple tweaks in the Deployment pod template.
## Use Cases
## Use Cases
### Canary Deployment
If you want to roll out releases to a subset of users or servers using the Deployment, you can create multiple Deployments, one for each release,
following the canary pattern described in [managing resources](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments).
following the canary pattern described in [managing resources](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments).
## Writing a Deployment Spec
@ -696,7 +696,7 @@ to 1.
### Selector
`.spec.selector` is an optional field that specifies a [label selector](/docs/user-guide/labels/#label-selectors) for the Pods
targeted by this deployment.
targeted by this deployment.
If specified, `.spec.selector` must match `.spec.template.metadata.labels`, or it will
be rejected by the API. If `.spec.selector` is unspecified, `.spec.selector.matchLabels` will be defaulted to
@ -774,32 +774,32 @@ If specified, this field needs to be greater than `.spec.minReadySeconds`.
### Min Ready Seconds
`.spec.minReadySeconds` is an optional field that specifies the
`.spec.minReadySeconds` is an optional field (with default value of 600s) that specifies the
minimum number of seconds for which a newly created Pod should be ready
without any of its containers crashing, for it to be considered available.
This defaults to 0 (the Pod will be considered available as soon as it is ready).
To learn more about when a Pod is considered ready, see [Container Probes](/docs/user-guide/pod-states/#container-probes).
### Rollback To
### Rollback To
`.spec.rollbackTo` is an optional field with the configuration the Deployment is rolling back to. Setting this field will trigger a rollback, and this field will be cleared every time a rollback is done.
`.spec.rollbackTo` is an optional field with the configuration the Deployment is rolling back to. Setting this field will trigger a rollback, and this field will be cleared every time a rollback is done.
#### Revision
`.spec.rollbackTo.revision` is an optional field specifying the revision to rollback to. This defaults to 0, meaning rollback to the last revision in history.
`.spec.rollbackTo.revision` is an optional field specifying the revision to rollback to. This defaults to 0, meaning rollback to the last revision in history.
### Revision History Limit
A deployment's revision history is stored in the replica sets it controls.
A deployment's revision history is stored in the replica sets it controls.
`.spec.revisionHistoryLimit` is an optional field that specifies the number of old Replica Sets to retain to allow rollback. Its ideal value depends on the frequency and stability of new deployments. All old Replica Sets will be kept by default, consuming resources in `etcd` and crowding the output of `kubectl get rs`, if this field is not set. The configuration of each Deployment revision is stored in its Replica Sets; therefore, once an old Replica Set is deleted, you lose the ability to rollback to that revision of Deployment.
`.spec.revisionHistoryLimit` is an optional field (with default value of two) that specifies the number of old Replica Sets to retain to allow rollback. Its ideal value depends on the frequency and stability of new deployments. All old Replica Sets will be kept by default, consuming resources in `etcd` and crowding the output of `kubectl get rs`, if this field is not set. The configuration of each Deployment revision is stored in its Replica Sets; therefore, once an old Replica Set is deleted, you lose the ability to rollback to that revision of Deployment.
More specifically, setting this field to zero means that all old replica sets with 0 replica will be cleaned up.
More specifically, setting this field to zero means that all old replica sets with 0 replica will be cleaned up.
In this case, a new deployment rollout cannot be undone, since its revision history is cleaned up.
### Paused
`.spec.paused` is an optional boolean field for pausing and resuming a Deployment. It defaults to false (a Deployment is not paused).
`.spec.paused` is an optional boolean field for pausing and resuming a Deployment. It defaults to false (a Deployment is not paused).
## Alternative to Deployments

2
docs/user-guide/horizontal-pod-autoscaling/hpa-php-apache.yaml
View File

@ -5,7 +5,7 @@ metadata:
namespace: default
spec:
scaleTargetRef:
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
name: php-apache
minReplicas: 1

6
docs/user-guide/horizontal-pod-autoscaling/walkthrough.md
View File

@ -147,7 +147,7 @@ metadata:
namespace: default
spec:
scaleTargetRef:
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
name: php-apache
minReplicas: 1
@ -227,7 +227,7 @@ metadata:
namespace: default
spec:
scaleTargetRef:
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
name: php-apache
minReplicas: 1
@ -280,7 +280,7 @@ metadata:
namespace: default
spec:
scaleTargetRef:
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
name: php-apache
minReplicas: 1

8
docs/user-guide/introspection-and-debugging.md
View File

@ -17,7 +17,7 @@ your pods. But there are a number of ways to get even more information about you
For this example we'll use a Deployment to create two pods, similar to the earlier example.
```yaml
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
@ -87,7 +87,7 @@ Containers:
Environment Variables:
Conditions:
Type Status
Ready True
Ready True
Volumes:
default-token-4bcbi:
Type: Secret (a volume populated by a Secret)
@ -137,7 +137,7 @@ $ kubectl describe pod nginx-deployment-1370807587-fz9sd
Node: /
Labels: app=nginx,pod-template-hash=1370807587
Status: Pending
IP:
IP:
Controllers: ReplicaSet/nginx-deployment-1370807587
Containers:
nginx:
@ -275,7 +275,7 @@ Labels: kubernetes.io/hostname=kubernetes-node-861h
CreationTimestamp: Fri, 10 Jul 2015 14:32:29 -0700
Conditions:
Type Status LastHeartbeatTime LastTransitionTime Reason Message
Ready Unknown Fri, 10 Jul 2015 14:34:32 -0700 Fri, 10 Jul 2015 14:35:15 -0700 Kubelet stopped posting node status.
Ready Unknown Fri, 10 Jul 2015 14:34:32 -0700 Fri, 10 Jul 2015 14:35:15 -0700 Kubelet stopped posting node status.
Addresses: 10.240.115.55,104.197.0.26
Capacity:
cpu: 1

2
docs/user-guide/new-nginx-deployment.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx-deployment

2
docs/user-guide/nginx-app.yaml
View File

@ -11,7 +11,7 @@ spec:
selector:
app: nginx
---
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: my-nginx

2
docs/user-guide/nginx-deployment.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx-deployment

2
docs/user-guide/nginx-lifecycle-deployment.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx

2
docs/user-guide/nginx-probe-deployment.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx

2
docs/user-guide/nginx-secure-app.yaml
View File

@ -17,7 +17,7 @@ spec:
selector:
run: my-nginx
---
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: my-nginx

2
docs/user-guide/nginx/nginx-deployment.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: my-nginx

2
docs/user-guide/redis-deployment.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: redis

2
docs/user-guide/redis-resource-deployment.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: redis

4
docs/user-guide/redis-secret-deployment.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: redis
@ -12,7 +12,7 @@ spec:
volumes:
- name: data
emptyDir: {}
- name: supersecret # The "mysecret" secret populates this "supersecret" volume.
- name: supersecret # The "mysecret" secret populates this "supersecret" volume.
secret:
secretName: mysecret
containers:

2
docs/user-guide/run-my-nginx.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: my-nginx

4
docs/user-guide/walkthrough/deployment-update.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
@ -13,4 +13,4 @@ spec:
- name: nginx
image: nginx:1.8 # Update the version of nginx from 1.7.9 to 1.8
ports:
- containerPort: 80
- containerPort: 80

4
docs/user-guide/walkthrough/deployment.yaml
View File

@ -1,4 +1,4 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
@ -15,4 +15,4 @@ spec:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
- containerPort: 80