Deployment
最后更新于
最后更新于
Deployments offer a declarative definition for Pods and ReplicaSets, making application management more straightforward as compared to the former ReplicationControllers.
Kubernetes Version | Deployment Version |
---|---|
For example, you can define a simple nginx application as follows:
Scale up:
If your cluster supports horizontal pod autoscaling, you can even set automatic expansion for Deployment:
Updating images is also straightforward:
Roll back:
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
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.
The following is an example of Deployment, which creates a ReplicaSet to start 3 nginx pods.
Download the sample file and perform the command:
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:
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:
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.
You may notice that the name of a ReplicaSet is always <Deployment name>-<pod template hash value>
.
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.
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.
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
.
To see the status of the rollout,
v1.5-v1.6
extensions/v1beta1
v1.7-v1.15
apps/v1beta1
v1.8-v1.15
apps/v1beta2
v1.9+
apps/v1