148422597X Kubernetes Management Design Patterns [Vohra 2017-01-29] {E559F6BB}
Chapter 8 ■ Using Rolling UpdatesTable 8-1. Fields for Rolling Update to a DeploymentField Description ExamplemaxUnavailablemaxSurgeThe maximum number of podsthat may become unavailableduring the update. The value maybe an absolute number, such as 3,or a percentage, for example 30%.Default value is 1. The value cannotbe 0 if maxSurge is 0.The maximum number of podsthat may be running abovethe configured or desired levelspecified as a number or apercentage. Default value is 1.Cannot be 0 if maxUnavailable is 0.If set to 20% the maximum number of pods thatmay be unavailable cannot exceed 20%, and 80%of the pods must always be available. When theupdate starts, the old RC is scaled down to 80%immediately and new pods started for the newRC. As new pods are started old RC pods arestopped, so that the number of pods available isalways 80% of the configured replication level.If set to 10% the new RC may surge to 110%of the configured or desired number of podsimmediately when the update is started, but notmore than 110% of the configured replicationlevel. As old RC pods are stopped more new RCpods are started, but at any given time the totalnumber of pods must not exceed 110%.The Deployment spec provides two fields (Table 8-2) for the rolling update rollback. Neither of thesefields are required.Table 8-2. Fields for Rolling Update RollbackFieldrollbackTorevisionHistoryLimitDescriptionThe config the deployment is rolled back to in a rollback. The RollbackConfigprovides a field revision to specify the revision to roll back to. If set to 0 rollsback to the last revision.The number of old replica sets to retain to allow a rollback.Next, we shall demonstrate rolling update of a deployment. Create a deployment file mysqldeployment.yaml:sudo vi mysql-deployment.yamlCopy the following listing to the definition file:apiVersion: extensions/v1beta1kind: Deploymentmetadata:name: mysql-deploymentspec:replicas: 5template:metadata:labels:app: mysql187
Chapter 8 ■ Using Rolling Updatesspec:containers:- name: mysqlimage: mysql:5.5ports:- containerPort: 80strategy:type: RollingUpdaterollingUpdate:maxUnavailable: 75%maxSurge: 30%rollbackTo:revision: 0Figure 8-23 shows the definition file in a vi editor.Figure 8-23. Definition file for a deployment188
- Page 151 and 152: Chapter 6 ■ Using VolumesPodDocke
- Page 153 and 154: Chapter 6 ■ Using VolumesObtain t
- Page 155 and 156: Chapter 6 ■ Using VolumesFigure 6
- Page 157 and 158: Chapter 6 ■ Using VolumesThe prec
- Page 159 and 160: Chapter 6 ■ Using VolumesFigure 6
- Page 161 and 162: Chapter 6 ■ Using VolumesFigure 6
- Page 163 and 164: Chapter 6 ■ Using VolumesThe kube
- Page 165 and 166: Chapter 6 ■ Using Volumesvolumes:
- Page 167 and 168: Chapter 6 ■ Using VolumesChange d
- Page 169 and 170: Chapter 7 ■ Using ServicesAnother
- Page 171 and 172: Chapter 7 ■ Using ServicesCreatin
- Page 173 and 174: Chapter 7 ■ Using ServicesSimilar
- Page 175 and 176: Chapter 7 ■ Using ServicesList th
- Page 177 and 178: Chapter 7 ■ Using ServicesFigure
- Page 179 and 180: Chapter 7 ■ Using ServicesInvoke
- Page 181 and 182: Chapter 7 ■ Using ServicesFigure
- Page 183 and 184: Chapter 7 ■ Using ServicesFigure
- Page 185 and 186: Chapter 7 ■ Using ServicesIn addi
- Page 187 and 188: Chapter 8 ■ Using Rolling Updates
- Page 189 and 190: Chapter 8 ■ Using Rolling Updates
- Page 191 and 192: Chapter 8 ■ Using Rolling Updates
- Page 193 and 194: Chapter 8 ■ Using Rolling Updates
- Page 195 and 196: Chapter 8 ■ Using Rolling Updates
- Page 197 and 198: Chapter 8 ■ Using Rolling Updates
- Page 199 and 200: Chapter 8 ■ Using Rolling Updates
- Page 201: Chapter 8 ■ Using Rolling Updates
- Page 205 and 206: Chapter 8 ■ Using Rolling Updates
- Page 207 and 208: Chapter 8 ■ Using Rolling Updates
- Page 209 and 210: Chapter 8 ■ Using Rolling Updates
- Page 211 and 212: Chapter 8 ■ Using Rolling Updates
- Page 213 and 214: Chapter 8 ■ Using Rolling Updates
- Page 215 and 216: Chapter 9 ■ Scheduling Pods on No
- Page 217 and 218: Chapter 9 ■ Scheduling Pods on No
- Page 219 and 220: Chapter 9 ■ Scheduling Pods on No
- Page 221 and 222: Chapter 9 ■ Scheduling Pods on No
- Page 223 and 224: Chapter 9 ■ Scheduling Pods on No
- Page 225 and 226: Chapter 9 ■ Scheduling Pods on No
- Page 227 and 228: Chapter 9 ■ Scheduling Pods on No
- Page 229 and 230: Chapter 9 ■ Scheduling Pods on No
- Page 231 and 232: Chapter 9 ■ Scheduling Pods on No
- Page 233 and 234: Chapter 9 ■ Scheduling Pods on No
- Page 235 and 236: Chapter 9 ■ Scheduling Pods on No
- Page 237 and 238: Chapter 9 ■ Scheduling Pods on No
- Page 239 and 240: Chapter 9 ■ Scheduling Pods on No
- Page 241 and 242: Chapter 9 ■ Scheduling Pods on No
- Page 243 and 244: Chapter 9 ■ Scheduling Pods on No
- Page 245 and 246: Chapter 9 ■ Scheduling Pods on No
- Page 247 and 248: Chapter 9 ■ Scheduling Pods on No
- Page 249 and 250: Chapter 9 ■ Scheduling Pods on No
- Page 251 and 252: Chapter 9 ■ Scheduling Pods on No
Chapter 8 ■ Using Rolling Updates
Table 8-1. Fields for Rolling Update to a Deployment
Field Description Example
maxUnavailable
maxSurge
The maximum number of pods
that may become unavailable
during the update. The value may
be an absolute number, such as 3,
or a percentage, for example 30%.
Default value is 1. The value cannot
be 0 if maxSurge is 0.
The maximum number of pods
that may be running above
the configured or desired level
specified as a number or a
percentage. Default value is 1.
Cannot be 0 if maxUnavailable is 0.
If set to 20% the maximum number of pods that
may be unavailable cannot exceed 20%, and 80%
of the pods must always be available. When the
update starts, the old RC is scaled down to 80%
immediately and new pods started for the new
RC. As new pods are started old RC pods are
stopped, so that the number of pods available is
always 80% of the configured replication level.
If set to 10% the new RC may surge to 110%
of the configured or desired number of pods
immediately when the update is started, but not
more than 110% of the configured replication
level. As old RC pods are stopped more new RC
pods are started, but at any given time the total
number of pods must not exceed 110%.
The Deployment spec provides two fields (Table 8-2) for the rolling update rollback. Neither of these
fields are required.
Table 8-2. Fields for Rolling Update Rollback
Field
rollbackTo
revisionHistoryLimit
Description
The config the deployment is rolled back to in a rollback. The RollbackConfig
provides a field revision to specify the revision to roll back to. If set to 0 rolls
back to the last revision.
The number of old replica sets to retain to allow a rollback.
Next, we shall demonstrate rolling update of a deployment. Create a deployment file mysqldeployment.yaml:
sudo vi mysql-deployment.yaml
Copy the following listing to the definition file:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: mysql-deployment
spec:
replicas: 5
template:
metadata:
labels:
app: mysql
187