Fearture of Kubernetes Deployment
ReplicaSets = Replication+Controller in the Deployment
$ kubectl explain deploy.spec.strategy.type
Type of deployment. Can be “Recreate” or “RollingUpdate”. Default is
Kubernetes Deployement Strategy
Type of deployment
.spec.strategy specifies the strategy used to replace old Pods by new ones. .spec.strategy.type can be “Recreate” or “RollingUpdate”. “RollingUpdate” is the default value
All existing Pods are killed before new ones are created when .spec.strategy.type==Recreate.
This will only guarantee Pod termination previous to creation for upgrades. If you upgrade a Deployment, all Pods of the old revision will be terminated immediately. Successful removal is awaited before any Pod of the new revision is created. If you manually delete a Pod, the lifecycle is controlled by the ReplicaSet and the replacement will be created immediately (even if the old Pod is still in a Terminating state). If you need an “at most” guarantee for your Pods, you should consider using a StatefulSet.
Rolling Update Deployment
The advantage of the rolling update strategy is that the update is applied Pod-by-Pod so the greater system can remain active.
There is a minor performance reduction during this update process because the system is consistently one active Pod short of the desired number of Pods. This is often much preferred to a full system deactivation.
The rolling update strategy is used as the default update strategy but isn’t suited for all situations.
The Deployment updates Pods in a rolling update fashion when .spec.strategy.type==RollingUpdate. You can specify maxUnavailable and maxSurge to control the rolling update process. maxSurge <string> The maximum number of pods that can be scheduled above the desired number of pods. Value can be an absolute number (ex: 5) or a percentage of desired pods (ex: 10%). This can not be 0 if MaxUnavailable is 0. Absolute number is calculated from percentage by rounding up. Defaults to 25%. Example: when this is set to 30%, the new ReplicaSet can be scaled up immediately when the rolling update starts, such that the total number of old and new pods do not exceed 130% of desired pods. Once old pods have been killed, new ReplicaSet can be scaled up further, ensuring that total number of pods running at any time during the update is at most 130% of desired pods. maxUnavailable <string> The maximum number of pods that can be unavailable during the update. Value can be an absolute number (ex: 5) or a percentage of desired pods (ex: 10%). Absolute number is calculated from percentage by rounding down. This can not be 0 if MaxSurge is 0. Defaults to 25%. Example: when this is set to 30%, the old ReplicaSet can be scaled down to 70% of desired pods immediately when the rolling update starts. Once new pods are ready, old ReplicaSet can be scaled down further, followed by scaling up the new ReplicaSet, ensuring that the total number of pods available at all times during the update is at least 70% of desired pods.
kubernetes deployment strategy example: Recreate
apiVersion: apps/v1 kind: Deployment metadata: name: hello-deploy spec: replicas: 10 selector: matchLabels: app: hello-world minReadySeconds: 10 strategy: type: Recreate rollingUpdate: maxUnavailable: 1 maxSurge: 1 template: metadata: labels: app: hello-world spec: containers: - name: hello-Pod image: scmgalaxy/nginx-devopsschoolv1 ports: - containerPort: 80
kubernetes deployment strategy example: Rollingupdate
apiVersion: apps/v1 kind: Deployment metadata: name: helloworld spec: replicas: 3 strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 1 minReadySeconds: 5 template: metadata: labels: app: helloworld track: stable spec: containers: - name: helloworld image: scmgalaxy/nginx-devopsschoolv1 ports: - containerPort: 80 resources: requests: cpu: 50m limits: cpu: 100m