Deployment
Quick Overview
Deployments offer a declarative definition for Pods and ReplicaSets, making application management more straightforward as compared to the former ReplicationControllers.
A Handy Version Guide
v1.5-v1.6
extensions/v1beta1
v1.7-v1.15
apps/v1beta1
v1.8-v1.15
apps/v1beta2
v1.9+
apps/v1
For example, you can define a simple nginx application as follows:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
Scale up:
kubectl scale deployment nginx-deployment --replicas 10
If your cluster supports horizontal pod autoscaling, you can even set automatic expansion for Deployment:
kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80
Updating images is also straightforward:
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
Roll back:
kubectl rollout undo deployment/nginx-deployment
Typical use cases for Deployment include:
Define Deployment to create Pod and ReplicaSet
Roll up and roll back applications
Scale up and scale down
Pause and resume Deployment
A Brief Explanation of the Deployment Concept
Deployment provides a declarative update for Pod and ReplicaSet (the next generation of Replication Controller).
You only need to describe what you want the target state to be in the Deployment, and the Deployment controller will help you change the actual state of the Pod and ReplicaSet to your target state. You can define a brand new Deployment, or create a new one to replace the old Deployment.
For example:
Use Deployment to create a ReplicaSet. ReplicaSet creates pods in the background. Check the startup status to see if it is successful or not.
Then, declare the new state of the Pod by updating the Deployment's PodTemplateSpec field. This creates a new ReplicaSet, and Deployment will move the pod from the old ReplicaSet to the new ReplicaSet at a controlled rate.
If the current state is unstable, roll back to the previous Deployment revision. Every rollback updates the Deployment's revision.
Scale the Deployment to meet higher loads.
Pause Deployment to apply multiple fixes to PodTemplateSpec and then resume operation.
Determine whether the launch is hung based on the status of Deployment.
Clear unnecessary old ReplicaSet.
Creating a Deployment
The following is an example of Deployment, which creates a ReplicaSet to start 3 nginx pods.
Download the sample file and perform the command:
$ kubectl create -f docs/user-guide/nginx-deployment.yaml --record
deployment "nginx-deployment" created
Setting the —record
flag of kubectl to true
can record the command that creates or upgrades the resource in the annotation. This will be useful in the future, for example, to see which commands were executed in each Deployment revision.
Executing get
immediately afterwards will give the following result:
$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 0 0 0 1s
The output indicates that our desired number of replicas is 3 (based on the configuration in the deployment's .spec.replicas
). The current number of replicas ( .status.replicas
) is 0, the newest number of replicas ( .status.updatedReplicas
) is 0, and the available number of replicas ( .status.availableReplicas
) is 0.
A few seconds later, performing the get
command again will give the following output:
$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 18s
As you can see, Deployment has created 3 replicas, all of which are updated (contain the latest pod template), and are available (based on Deployment's .spec.minReadySeconds
declaration, the minimum number of pods in ready status). Executing kubectl get rs
and kubectl get pods
will display the created ReplicaSets (RS) and Pods.
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-2035384211 3 3 0 18s
You may notice that the name of a ReplicaSet is always <Deployment name>-<pod template hash value>
.
$ kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-2035384211-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=2035384211
nginx-deployment-2035384211-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=2035384211
nginx-deployment-2035384211-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=2035384211
The newly created ReplicaSet will ensure that there are always 3 nginx pods present.
Note: You must specify the correct pod template label (app = nginx
) in the Deployment selector. Do not mix it up with other controllers, including other Deployments, ReplicaSets, ReplicationController, and so on. Although Kubernetes itself does not prevent you from doing this, if you do, these controllers will fight each other and may result in incorrect behavior.
Updating Deployment
Note: Only when the Deployment pod template (such as .spec.template
) is updated, which includes updating labels or container images in Deployment, will it trigger a rollout. Other updates, such as scaling up the Deployment, do not trigger a rollout.
Assuming we now want to use the nginx:1.9.1
image instead of the original nginx:1.7.9
image.
$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
deployment "nginx-deployment" image updated
We can use the edit
command to edit the Deployment. We modify .spec.template.spec.containers[0].image
, changing nginx:1.7.9
to nginx:1.9.1
.
$ kubectl edit deployment/nginx-deployment
deployment "nginx-deployment" edited
To see the status of the rollout,
最后更新于