s/console/shell per the Rouge lexer list

This commit is contained in:
John Mulhausen
2016-03-17 17:36:36 -07:00
parent 02e6fff302
commit b008519b04
+25 -25
View File
@@ -28,7 +28,7 @@ bring up 3 nginx pods.
Run the example by downloading the example file and then running this command: Run the example by downloading the example file and then running this command:
```console ```shell
$ kubectl create -f docs/user-guide/nginx-deployment.yaml --record $ kubectl create -f docs/user-guide/nginx-deployment.yaml --record
deployment "nginx-deployment" created deployment "nginx-deployment" created
``` ```
@@ -37,7 +37,7 @@ Setting the kubectl flag `--record` to `true` allows you to record current comma
Then running `get` immediately will give: Then running `get` immediately will give:
```console ```shell
$ kubectl get deployments $ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 0 0 0 1s nginx-deployment 3 0 0 0 1s
@@ -47,7 +47,7 @@ This indicates that the Deployment's number of desired replicas is 3 (according
Running the `get` again a few seconds later, should give: Running the `get` again a few seconds later, should give:
```console ```shell
$ kubectl get deployments $ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 18s nginx-deployment 3 3 3 3 18s
@@ -55,7 +55,7 @@ nginx-deployment 3 3 3 3 18s
This indicates that the Deployment has created all three replicas, and all replicas are up-to-date (contains the latest pod template) and available (pod status is ready for at least deployment's `.spec.minReadySeconds`). Running `kubectl get rs` and `kubectl get pods` will show the replica set (RS) and pods created. This indicates that the Deployment has created all three replicas, and all replicas are up-to-date (contains the latest pod template) and available (pod status is ready for at least deployment's `.spec.minReadySeconds`). Running `kubectl get rs` and `kubectl get pods` will show the replica set (RS) and pods created.
```console ```shell
$ kubectl get rs $ kubectl get rs
NAME DESIRED CURRENT AGE NAME DESIRED CURRENT AGE
nginx-deployment-2035384211 3 3 18s nginx-deployment-2035384211 3 3 18s
@@ -63,7 +63,7 @@ nginx-deployment-2035384211 3 3 18s
You may notice that the name of the replica set is always `<the name of the Deployment>-<hash value of the pod template>`. You may notice that the name of the replica set is always `<the name of the Deployment>-<hash value of the pod template>`.
```console ```shell
$ kubectl get pods --show-labels $ kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-2035384211-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=2035384211 nginx-deployment-2035384211-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=2035384211
@@ -83,21 +83,21 @@ For this, we update our deployment file as follows:
We can then `apply` the new Deployment: We can then `apply` the new Deployment:
```console ```shell
$ kubectl apply -f docs/user-guide/new-nginx-deployment.yaml $ kubectl apply -f docs/user-guide/new-nginx-deployment.yaml
deployment "nginx-deployment" configured deployment "nginx-deployment" configured
``` ```
Alternatively, we can `edit` the Deployment and change `.spec.template.spec.containers[0].image` from `nginx:1.7.9` to `nginx:1.9.1`: Alternatively, we can `edit` the Deployment and change `.spec.template.spec.containers[0].image` from `nginx:1.7.9` to `nginx:1.9.1`:
```console ```shell
$ kubectl edit deployment/nginx-deployment $ kubectl edit deployment/nginx-deployment
deployment "nginx-deployment" edited deployment "nginx-deployment" edited
``` ```
Running a `get` immediately will give: Running a `get` immediately will give:
```console ```shell
$ kubectl get deployments $ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 0 3 20s nginx-deployment 3 3 0 3 20s
@@ -107,7 +107,7 @@ The 0 number of up-to-date replicas indicates that the deployment hasn't updated
The Deployment will update all the pods in a few seconds. The Deployment will update all the pods in a few seconds.
```console ```shell
$ kubectl get deployments $ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 36s nginx-deployment 3 3 3 3 36s
@@ -115,7 +115,7 @@ nginx-deployment 3 3 3 3 36s
We can run `kubectl get rs` to see that the Deployment updated the pods by creating a new replica set and scaling it up to 3 replicas, as well as scaling down the old replica set to 0 replicas. We can run `kubectl get rs` to see that the Deployment updated the pods by creating a new replica set and scaling it up to 3 replicas, as well as scaling down the old replica set to 0 replicas.
```console ```shell
$ kubectl get rs $ kubectl get rs
NAME DESIRED CURRENT AGE NAME DESIRED CURRENT AGE
nginx-deployment-1564180365 3 3 6s nginx-deployment-1564180365 3 3 6s
@@ -124,7 +124,7 @@ nginx-deployment-2035384211 0 0 36s
Running `get pods` should now show only the new pods: Running `get pods` should now show only the new pods:
```console ```shell
$ kubectl get pods $ kubectl get pods
NAME READY STATUS RESTARTS AGE NAME READY STATUS RESTARTS AGE
nginx-deployment-1564180365-khku8 1/1 Running 0 14s nginx-deployment-1564180365-khku8 1/1 Running 0 14s
@@ -144,7 +144,7 @@ For example, if you look at the above deployment closely, you will see that
it first created a new pod, then deleted some old pods and created new ones. It it first created a new pod, then deleted some old pods and created new ones. It
does not kill old pods until a sufficient number of new pods have come up, and does not create new pods until a sufficient number of old pods have been killed. It makes sure that number of available pods is at least 2 and the number of total pods is at most 4. does not kill old pods until a sufficient number of new pods have come up, and does not create new pods until a sufficient number of old pods have been killed. It makes sure that number of available pods is at least 2 and the number of total pods is at most 4.
```console ```shell
$ kubectl describe deployments $ kubectl describe deployments
Name: nginx-deployment Name: nginx-deployment
Namespace: default Namespace: default
@@ -199,14 +199,14 @@ Sometimes we may want to rollback a Deployment; for example, when the Deployment
Suppose that we made a typo while updating the Deployment, by putting the image name as `nginx:1.91` instead of `nginx:1.9.1`: Suppose that we made a typo while updating the Deployment, by putting the image name as `nginx:1.91` instead of `nginx:1.9.1`:
```console ```shell
$ kubectl apply -f docs/user-guide/bad-nginx-deployment.yaml $ kubectl apply -f docs/user-guide/bad-nginx-deployment.yaml
deployment "nginx-deployment" configured deployment "nginx-deployment" configured
``` ```
You will see that both the number of old replicas (nginx-deployment-1564180365 and nginx-deployment-2035384211) and new replicas (nginx-deployment-3066724191) are 2. You will see that both the number of old replicas (nginx-deployment-1564180365 and nginx-deployment-2035384211) and new replicas (nginx-deployment-3066724191) are 2.
```console ```shell
$ kubectl get rs $ kubectl get rs
NAME DESIRED CURRENT AGE NAME DESIRED CURRENT AGE
nginx-deployment-1564180365 2 2 25s nginx-deployment-1564180365 2 2 25s
@@ -216,7 +216,7 @@ nginx-deployment-3066724191 2 2 6s
Looking at the pods created, you will see that the 2 pods created by new replica set are stuck in an image pull loop. Looking at the pods created, you will see that the 2 pods created by new replica set are stuck in an image pull loop.
```console ```shell
$ kubectl get pods $ kubectl get pods
NAME READY STATUS RESTARTS AGE NAME READY STATUS RESTARTS AGE
nginx-deployment-1564180365-70iae 1/1 Running 0 25s nginx-deployment-1564180365-70iae 1/1 Running 0 25s
@@ -227,7 +227,7 @@ nginx-deployment-3066724191-eocby 0/1 ImagePullBackOff 0 6s
Note that the Deployment controller will stop the bad rollout automatically, and will stop scaling up the new replica set. Note that the Deployment controller will stop the bad rollout automatically, and will stop scaling up the new replica set.
```console ```shell
$ kubectl describe deployment $ kubectl describe deployment
Name: nginx-deployment Name: nginx-deployment
Namespace: default Namespace: default
@@ -258,7 +258,7 @@ To fix this, we need to rollback to a previous revision of Deployment that is st
First, check the revisions of this deployment: First, check the revisions of this deployment:
```console ```shell
$ kubectl rollout history deployment/nginx-deployment $ kubectl rollout history deployment/nginx-deployment
deployments "nginx-deployment": deployments "nginx-deployment":
REVISION CHANGE-CAUSE REVISION CHANGE-CAUSE
@@ -271,7 +271,7 @@ Because we recorded the command while creating this Deployment using `--record`,
To further see the details of each revision, run: To further see the details of each revision, run:
```console ```shell
$ kubectl rollout history deployment/nginx-deployment --revision=2 $ kubectl rollout history deployment/nginx-deployment --revision=2
deployments "nginx-deployment" revision 2 deployments "nginx-deployment" revision 2
Labels: app=nginx,pod-template-hash=1564180365 Labels: app=nginx,pod-template-hash=1564180365
@@ -282,21 +282,21 @@ No volumes.
Now we've decided to undo the current rollout and rollback to the previous revision: Now we've decided to undo the current rollout and rollback to the previous revision:
```console ```shell
$ kubectl rollout undo deployment/nginx-deployment $ kubectl rollout undo deployment/nginx-deployment
deployment "nginx-deployment" rolled back deployment "nginx-deployment" rolled back
``` ```
Alternatively, you can rollback to a specific revision by specify that in `--to-revision`: Alternatively, you can rollback to a specific revision by specify that in `--to-revision`:
```console ```shell
$ kubectl rollout undo deployment/nginx-deployment --to-revision=2 $ kubectl rollout undo deployment/nginx-deployment --to-revision=2
deployment "nginx-deployment" rolled back deployment "nginx-deployment" rolled back
``` ```
The Deployment is now rolled back to a previous stable revision. As you can see, a `DeploymentRollback` event for rolling back to revision 2 is generated from Deployment controller. The Deployment is now rolled back to a previous stable revision. As you can see, a `DeploymentRollback` event for rolling back to revision 2 is generated from Deployment controller.
```console ```shell
$ kubectl get deployment $ kubectl get deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 30m nginx-deployment 3 3 3 3 30m
@@ -334,7 +334,7 @@ You can also pause a Deployment mid-way and then resume it. A use case is to sup
Update the Deployment again and then pause the Deployment with `kubectl rollout pause`: Update the Deployment again and then pause the Deployment with `kubectl rollout pause`:
```console ```shell
$ kubectl apply -f docs/user-guide/new-nginx-deployment; kubectl rollout pause deployment/nginx-deployment $ kubectl apply -f docs/user-guide/new-nginx-deployment; kubectl rollout pause deployment/nginx-deployment
deployment "nginx-deployment" configured deployment "nginx-deployment" configured
deployment "nginx-deployment" paused deployment "nginx-deployment" paused
@@ -344,7 +344,7 @@ Note that any current state of the Deployment will continue its function, but ne
The Deployment was still in progress when we paused it, so the actions of scaling up and down replica sets are paused too. The Deployment was still in progress when we paused it, so the actions of scaling up and down replica sets are paused too.
```console ```shell
$ kubectl get rs $ kubectl get rs
NAME DESIRED CURRENT AGE NAME DESIRED CURRENT AGE
nginx-deployment-1564180365 2 2 1h nginx-deployment-1564180365 2 2 1h
@@ -354,14 +354,14 @@ nginx-deployment-3066724191 0 0 1h
To resume the Deployment, simply do `kubectl rollout resume`: To resume the Deployment, simply do `kubectl rollout resume`:
```console ```shell
$ kubectl rollout resume deployment/nginx-deployment $ kubectl rollout resume deployment/nginx-deployment
deployment "nginx-deployment" resumed deployment "nginx-deployment" resumed
``` ```
Then the Deployment will continue and finish the rollout: Then the Deployment will continue and finish the rollout:
```console ```shell
$ kubectl get rs $ kubectl get rs
NAME DESIRED CURRENT AGE NAME DESIRED CURRENT AGE
nginx-deployment-1564180365 3 3 1h nginx-deployment-1564180365 3 3 1h