Skip to content

Commit 131970a

Browse files
committed
Merge pull request kubernetes#11530 from satnam6502/doc25
Fix console formatting of managing deployments doc
2 parents 9ca884e + d1fd54a commit 131970a

File tree

1 file changed

+20
-20
lines changed

1 file changed

+20
-20
lines changed

docs/user-guide/managing-deployments.md

Lines changed: 20 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -90,7 +90,7 @@ spec:
9090
9191
Multiple resources can be created the same way as a single resource:
9292
93-
```bash
93+
```console
9494
$ kubectl create -f ./nginx-app.yaml
9595
services/my-nginx-svc
9696
replicationcontrollers/my-nginx
@@ -100,13 +100,13 @@ The resources will be created in the order they appear in the file. Therefore, i
100100

101101
`kubectl create` also accepts multiple `-f` arguments:
102102

103-
```bash
103+
```console
104104
$ kubectl create -f ./nginx-svc.yaml -f ./nginx-rc.yaml
105105
```
106106

107107
And a directory can be specified rather than or in addition to individual files:
108108

109-
```bash
109+
```console
110110
$ kubectl create -f ./nginx/
111111
```
112112

@@ -116,7 +116,7 @@ It is a recommended practice to put resources related to the same microservice o
116116

117117
A URL can also be specified as a configuration source, which is handy for deploying directly from configuration files checked into github:
118118

119-
```bash
119+
```console
120120
$ kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/kubernetes/master/docs/user-guide/replication.yaml
121121
replicationcontrollers/nginx
122122
```
@@ -125,29 +125,29 @@ replicationcontrollers/nginx
125125

126126
Resource creation isn’t the only operation that `kubectl` can perform in bulk. It can also extract resource names from configuration files in order to perform other operations, in particular to delete the same resources you created:
127127

128-
```bash
128+
```console
129129
$ kubectl delete -f ./nginx/
130130
replicationcontrollers/my-nginx
131131
services/my-nginx-svc
132132
```
133133

134134
In the case of just two resources, it’s also easy to specify both on the command line using the resource/name syntax:
135135

136-
```bash
136+
```console
137137
$ kubectl delete replicationcontrollers/my-nginx services/my-nginx-svc
138138
```
139139

140140
For larger numbers of resources, one can use labels to filter resources. The selector is specified using `-l`:
141141

142-
```bash
142+
```console
143143
$ kubectl delete all -lapp=nginx
144144
replicationcontrollers/my-nginx
145145
services/my-nginx-svc
146146
```
147147

148148
Because `kubectl` outputs resource names in the same syntax it accepts, it’s easy to chain operations using `$()` or `xargs`:
149149

150-
```bash
150+
```console
151151
$ kubectl get $(kubectl create -f ./nginx/ | grep my-nginx)
152152
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS
153153
my-nginx nginx nginx app=nginx 2
@@ -187,7 +187,7 @@ and
187187

188188
The labels allow us to slice and dice our resources along any dimension specified by a label:
189189

190-
```bash
190+
```console
191191
$ kubectl create -f ./guestbook-fe.yaml -f ./redis-master.yaml -f ./redis-slave.yaml
192192
replicationcontrollers/guestbook-fe
193193
replicationcontrollers/guestbook-redis-master
@@ -240,8 +240,8 @@ The frontend service would span both sets of replicas by selecting the common su
240240

241241
Sometimes existing pods and other resources need to be relabeled before creating new resources. This can be done with `kubectl label`. For example:
242242

243-
```bash
244-
kubectl label pods -lapp=nginx tier=fe
243+
```console
244+
$ kubectl label pods -lapp=nginx tier=fe
245245
NAME READY STATUS RESTARTS AGE
246246
my-nginx-v4-9gw19 1/1 Running 0 14m
247247
NAME READY STATUS RESTARTS AGE
@@ -265,7 +265,7 @@ my-nginx-v4-wfof4 1/1 Running 0 16m fe
265265

266266
When load on your application grows or shrinks, it’s easy to scale with `kubectl`. For instance, to increase the number of nginx replicas from 2 to 3, do:
267267

268-
```bash
268+
```console
269269
$ kubectl scale rc my-nginx --replicas=3
270270
scaled
271271
$ kubectl get pods -lapp=nginx
@@ -304,14 +304,14 @@ spec:
304304

305305
To update to version 1.9.1, you can use [`kubectl rolling-update --image`](../../docs/design/simple-rolling-update.md):
306306

307-
```bash
307+
```console
308308
$ kubectl rolling-update my-nginx --image=nginx:1.9.1
309309
Creating my-nginx-ccba8fbd8cc8160970f63f9a2696fc46
310310
```
311311

312312
In another window, you can see that `kubectl` added a `deployment` label to the pods, whose value is a hash of the configuration, to distinguish the new pods from the old:
313313

314-
```bash
314+
```console
315315
$ kubectl get pods -lapp=nginx -Ldeployment
316316
NAME READY STATUS RESTARTS AGE DEPLOYMENT
317317
my-nginx-1jgkf 1/1 Running 0 1h 2d1d7a8f682934a254002b56404b813e
@@ -324,7 +324,7 @@ my-nginx-q6all 1/1 Running 0
324324

325325
`kubectl rolling-update` reports progress as it progresses:
326326

327-
```bash
327+
```console
328328
Updating my-nginx replicas: 4, my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 replicas: 1
329329
At end of loop: my-nginx replicas: 4, my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 replicas: 1
330330
At beginning of loop: my-nginx replicas: 3, my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 replicas: 2
@@ -346,7 +346,7 @@ my-nginx
346346

347347
If you encounter a problem, you can stop the rolling update midway and revert to the previous version using `--rollback`:
348348

349-
```bash
349+
```console
350350
$ kubectl kubectl rolling-update my-nginx --image=nginx:1.9.1 --rollback
351351
Found existing update in progress (my-nginx-ccba8fbd8cc8160970f63f9a2696fc46), resuming.
352352
Found desired replicas.Continuing update with existing controller my-nginx.
@@ -385,7 +385,7 @@ spec:
385385

386386
and roll it out:
387387

388-
```bash
388+
```console
389389
$ kubectl rolling-update my-nginx -f ./nginx-rc.yaml
390390
Creating my-nginx-v4
391391
At beginning of loop: my-nginx replicas: 4, my-nginx-v4 replicas: 1
@@ -413,7 +413,7 @@ You can also run the [update demo](update-demo/) to see a visual representation
413413

414414
Sometimes it’s necessary to make narrow, non-disruptive updates to resources you’ve created. For instance, you might want to add an [annotation](annotations.md) with a description of your object. That’s easiest to do with `kubectl patch`:
415415

416-
```bash
416+
```console
417417
$ kubectl patch rc my-nginx-v4 -p '{"metadata": {"annotations": {"description": "my frontend running nginx"}}}'
418418
my-nginx-v4
419419
$ kubectl get rc my-nginx-v4 -o yaml
@@ -429,7 +429,7 @@ The patch is specified using json.
429429

430430
For more significant changes, you can `get` the resource, edit it, and then `replace` the resource with the updated version:
431431

432-
```bash
432+
```console
433433
$ kubectl get rc my-nginx-v4 -o yaml > /tmp/nginx.yaml
434434
$ vi /tmp/nginx.yaml
435435
$ kubectl replace -f /tmp/nginx.yaml
@@ -443,7 +443,7 @@ The system ensures that you don’t clobber changes made by other users or compo
443443

444444
In some cases, you may need to update resource fields that cannot be updated once initialized, or you may just want to make a recursive change immediately, such as to fix broken pods created by a replication controller. To change such fields, use `replace --force`, which deletes and re-creates the resource. In this case, you can simply modify your original configuration file:
445445

446-
```bash
446+
```console
447447
$ kubectl replace -f ./nginx-rc.yaml --force
448448
replicationcontrollers/my-nginx-v4
449449
replicationcontrollers/my-nginx-v4

0 commit comments

Comments
 (0)