Deployment advantages relative to RC
RS and deployment are mainly used to replace RC. RS is all called Replica Set. The advantages relative to rc,rs and deployment are as follows:
- RC only supports equation-based selector, such as Env=dev or ENVIRONMENT!=QA. However, in RS, a new set-based selector, such as version in (v1.0,v2.0) or env not in (DEV,QA), is also supported. This brings convenience to complex operations management.
- Upgrading the pod with deployment only requires defining the final state of the pod, and k8s will perform the necessary actions for you. Although the use of Kubectl Rolling-update can also complete the rolling upgrade, but it is in the client and the server multiple interactive control RC completed, so the rest API does not have a rolling-update interface, which has brought some trouble to customize their own management system. The deployment has a more flexible upgrade and rollback capability.
Replica set currently differs from RC only in support of selector, and additional functionality will be added later. Deployment uses the replica Set, which is the concept of a higher layer. Unless you need to customize the upgrade feature or do not need to upgrade the pod at all, it is recommended that you use deployment instead of using replica Set directly.
Deployment configuration file
Deployment configuration is basically the same as RC, detailed configuration can refer to the official document directly below a configuration example DEPLOYMENT.YML content as follows:
apiVersion: extensions/v1beta1kind: Deploymentmetadata:name: hello-deploymentspec: strategy: type: RollingUpdate rollingUpdate: maxSurge: 10% maxUnavailable: 0 replicas: 3 template: metadata: labels: name: hello-deployment spec: containers: - name: pod image: index.tenxcloud.com/tailnode/hello:v1.0 ports: - containerPort:80
The strategy section needs to be described to define the upgrade strategy for the deployment. The detailed operation of the specific deployment rolling upgrade can be referred to another article, "Service rollover". Here are some of the meanings of these configuration items:
- spec.strategy: A policy for defining upgrades
- Spec.strategy.type: Defines how the upgrade is used. One is rollingupdate, that is, rolling upgrades. Another way is recreate. Stop all the old pods before starting the new pod. The default policy is Rollingupdate
- spec.strategy.type.rollingUpdate: If you are upgrading using Rollingupdate, you can define a more detailed rolling upgrade strategy
- Spec.strategy.type.rollingUpdate.maxSurge: Specifies the maximum number of pods that can be created when upgrading. This value can be either an absolute number or a percentage. For example, when this value is specified as 30%, that is, the total number of new and old pods cannot exceed 130%. Simply put, the 30% new pod is started when you roll up the upgrade. And then start killing the old pod, and whenever an old pod is killed, a new pod will be started, and the total amount won't be more than 130% until the update is complete. It is necessary to note that when maxunavailable is 0 o'clock, the value of Maxsurge cannot be 0.
- spec.strategy.type.rollingUpdate.maxUnavailable: Specifies the maximum number of pods values that are not available at upgrade time. Can be an absolute number or a percentage. For example, when this value is specified as 30%, the least available pod is 70%, that is, when rolling the upgrade, the 30% old pod is killed first, and then the new pod is started. When a new pod is created, an old pod is destroyed. Always keep the pod available at 70% of the total until the upgrade is complete. It is necessary to note that when Maxsurge is 0 o'clock, the value of maxunavailable cannot be 0.
Create Deployment:
kubectl create -f deployment.yml --recode
Kubernetes Deployment and Replica Set
