-
Notifications
You must be signed in to change notification settings - Fork 38
/
Deployment.yaml
397 lines (216 loc) · 7.83 KB
/
Deployment.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
# Deployments
In real world thing starts from here, we write deployment to launch Pods. A Deployment provides declarative updates for Pods and ReplicaSets.
- A Deployment is a Kubernetes object that acts as a wrapper around a ReplicaSet and makes it easier to use.
- In order to manage replicated services, it's recommended that you use Deployments that, in turn, manage the ReplicaSet and the Pods created by the ReplicaSet.
- The major motivation for using a Deployment is that it maintains a history of revisions.
- Every time a change is made to the ReplicaSet or the underlying Pods, a new revision of the ReplicaSet is recorded by the Deployment.
- This way, using a Deployment makes it easy to roll back to a previous state or version. Keep in mind that every rollback will also create a new revision for the Deployment
```yaml
Here's an example of a Deployment configuration:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
selector:
matchLabels:
app: nginx
environment: production
template:
metadata:
labels:
app: nginx
environment: production
spec:
containers:
- name: nginx-container
image: nginx
```
The value for the kind field is Deployment. The rest of the configuration remains the same as that for ReplicaSets. Deployments also have the replicas, selector, and Pod template fields used in the same way as ReplicaSets.
**Strategy**
In the strategy field under spec, we can specify which strategy the Deployment should use when it replaces old pods with new ones. This can either be RollingUpdate or Recreate. The default value is RollingUpdate.
**Rollig Update**:
- This is a strategy used to update a Deployment without having any downtime.
- With the **RollingUpdate** strategy, the controller updates the Pods one by one.
- Hence, at any given time, there will always be some Pods running.
- This strategy is particularly helpful when you want to update the Pod template without incurring any downtime for your application.
- However, be aware that having a rolling update means that there may be two different versions of Pods (old and new) running at the same time.
```
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
```
- **maxUnavailable** is the maximum number of Pods that can be unavailable during the update.
- **maxSurge** is the maximum number of Pods that can be scheduled/created above the desired number of Pods (as specified in the **replicas** field).
The two parameters—**maxUnavailable** and **maxSurge**—can be tuned for availability and the speed of scaling up or down the Deployment.
**Recreate**
- In this strategy, all the existing pods are killed before creating the new Pods with an updated configuration.
- This means there will be some downtime during the update.
- This, however, ensures that all the Pods running in the Deployment will be on the same version (old or new).
```
strategy:
type: Recreate
```
UseCase: A good use case for using the **Recreate** update strategy is if we need to run some data migration or data processing before the new code can be used. In this case, we will need to use the **Recreate** strategy because we can't afford to have any new code running along with the old one without running the migration or processing first for all the Pods.
**Examples**
```
Creating Deployment with Nginx COntainers
vi nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
environment: production
template:
metadata:
labels:
app: nginx
environment: production
spec:
containers:
- name: nginx-container
image: nginx
kubectl apply -f nginx-deployment.yaml
kubectl get deployment nginx-deployment
kubectl get pods
kubectl describe rs nginx-deployment
```
```
Updating a Deployment
==========================
vi nginx-deployment2.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
kubectl apply -f nginx-deployment2.yaml
kubectl get deployments
Let's update the nginx Pods to use the nginx:1.16.1 image instead of the nginx:1.14.2 image.
kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
or use the following command:
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
Alternatively, you can edit the Deployment and change .spec.template.spec.containers[0].image from nginx:1.14.2 to nginx:1.16.1:
kubectl edit deployment/nginx-deployment
To see the rollout status, run:
kubectl rollout status deployment/nginx-deployment
After the rollout succeeds, you can view the Deployment by running:
kubectl get deployments
kubectl get rs
kubectl get pods
kubectl describe deployments
```
## Rolling Back a Deployment
- In a real-life scenario, you may make a mistake when making a change in the Deployment configuration.
- You can easily undo a change and roll back to a previous stable revision of the Deployment.
- use the **kubectl rollout** command to check the revision history and rollback
```
kubectl rollout history deployment <deployment_name>
```
```
vi app-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-deployment
labels:
environment: production
spec:
replicas: 3
selector:
matchLabels:
app: nginx
environment: production
template:
metadata:
labels:
app: nginx
environment: production
spec:
containers:
- name: nginx-container
image: nginx
kubectl apply -f app-deployment.yaml
kubectl rollout history deployment app-deployment
For the first update, let's change the name of the container to nginx instead of nginx-container.
Update the content of the app-deployment.yaml file with the following:
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-deployment
labels:
environment: production
spec:
replicas: 3
selector:
matchLabels:
app: nginx
environment: production
template:
metadata:
labels:
app: nginx
environment: production
spec:
containers:
- name: nginx
image: nginx
Apply the changed configuration:
kubectl apply -f app-deployment.yaml --record
Wait for a few seconds to allow the Deployment to recreate the Pods with the updated Pod configuration:
kubectl rollout history deployment app-deploymen
```
**Rolling Back to a Previous Revision**
```YAML
Now you've decided to undo the current rollout and rollback to the previous revision:
kubectl rollout undo deployment/nginx-deployment
The output is similar to this:
deployment.apps/nginx-deployment rolled back
Alternatively, you can rollback to a specific revision by specifying it with --to-revision:
kubectl rollout undo deployment/nginx-deployment --to-revision=2
The output is similar to this:
deployment.apps/nginx-deployment rolled back
Check if the rollback was successful and the Deployment is running as expected, run:
kubectl get deployment nginx-deployment
Get the description of the Deployment:
kubectl describe deployment nginx-deployment
```
## Scaling a Deployment
```YAML
You can scale a Deployment by using the following command:
kubectl scale deployment/nginx-deployment --replicas=10
```