whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Code snippents shouldn't include the command prompt (#12779)

Browse Source
This commit is contained in:
Neha Yadav
2019-03-07 15:01:05 +05:30
committed by Kubernetes Prow Robot
parent 99e4d3bac6
commit d3cca48e3f
40 changed files with 1052 additions and 441 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/run-application/configure-pdb.md
+9 -3
View File
@@ -179,7 +179,9 @@ Assuming you don't actually have pods matching `app: zookeeper` in your namespac
then you'll see something like this:
```shell
$ kubectl get poddisruptionbudgets
kubectl get poddisruptionbudgets
```
```
NAME MIN-AVAILABLE ALLOWED-DISRUPTIONS AGE
zk-pdb 2 0 7s
```
@@ -187,7 +189,9 @@ zk-pdb 2 0 7s
If there are matching pods (say, 3), then you would see something like this:
```shell
$ kubectl get poddisruptionbudgets
kubectl get poddisruptionbudgets
```
```
NAME MIN-AVAILABLE ALLOWED-DISRUPTIONS AGE
zk-pdb 2 1 7s
```
@@ -198,7 +202,9 @@ counted the matching pods, and updated the status of the PDB.
You can get more information about the status of a PDB with this command:
```shell
$ kubectl get poddisruptionbudgets zk-pdb -o yaml
kubectl get poddisruptionbudgets zk-pdb -o yaml
```
```yaml
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+32 -12
View File
@@ -65,7 +65,9 @@ It defines an index.php page which performs some CPU intensive computations:
First, we will start a deployment running the image and expose it as a service:
```shell
$ kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --expose --port=80
kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --expose --port=80
```
```
service/php-apache created
deployment.apps/php-apache created
```
@@ -82,14 +84,18 @@ Roughly speaking, HPA will increase and decrease the number of replicas
See [here](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#autoscaling-algorithm) for more details on the algorithm.
```shell
$ kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
```
```
horizontalpodautoscaler.autoscaling/php-apache autoscaled
```
We may check the current status of autoscaler by running:
```shell
$ kubectl get hpa
kubectl get hpa
```
```
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 18s
@@ -104,17 +110,19 @@ Now, we will see how the autoscaler reacts to increased load.
We will start a container, and send an infinite loop of queries to the php-apache service (please run it in a different terminal):
```shell
$ kubectl run -i --tty load-generator --image=busybox /bin/sh
kubectl run -i --tty load-generator --image=busybox /bin/sh
Hit enter for command prompt
$ while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done
while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done
```
Within a minute or so, we should see the higher CPU load by executing:
```shell
$ kubectl get hpa
kubectl get hpa
```
```
NAME REFERENCE TARGET CURRENT MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache/scale 305% / 50% 305% 1 10 1 3m
@@ -124,7 +132,9 @@ Here, CPU consumption has increased to 305% of the request.
As a result, the deployment was resized to 7 replicas:
```shell
$ kubectl get deployment php-apache
kubectl get deployment php-apache
```
```
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
php-apache 7 7 7 7 19m
```
@@ -145,11 +155,17 @@ the load generation by typing `<Ctrl> + C`.
Then we will verify the result state (after a minute or so):
```shell
$ kubectl get hpa
kubectl get hpa
```
```
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 11m
```
$ kubectl get deployment php-apache
```shell
kubectl get deployment php-apache
```
```
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
php-apache 1 1 1 1 27m
```
@@ -172,7 +188,7 @@ by making use of the `autoscaling/v2beta2` API version.
First, get the YAML of your HorizontalPodAutoscaler in the `autoscaling/v2beta2` form:
```shell
$ kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml
kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml
```
Open the `/tmp/hpa-v2.yaml` file in an editor, and you should see YAML which looks like this:
@@ -401,7 +417,9 @@ The conditions appear in the `status.conditions` field. To see the conditions a
we can use `kubectl describe hpa`:
```shell
$ kubectl describe hpa cm-test
kubectl describe hpa cm-test
```
```shell
Name: cm-test
Namespace: prom
Labels: <none>
@@ -454,7 +472,9 @@ can use the following file to create it declaratively:
We will create the autoscaler by executing the following command:
```shell
$ kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml
kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml
```
```
horizontalpodautoscaler.autoscaling/php-apache created
```
content/en/docs/tasks/run-application/rolling-update-replication-controller.md
+19 -11
View File
@@ -37,7 +37,7 @@ A rolling update works by:
Rolling updates are initiated with the `kubectl rolling-update` command:
$ kubectl rolling-update NAME \
kubectl rolling-update NAME \
([NEW_NAME] --image=IMAGE | -f FILE)
{{% /capture %}}
@@ -50,7 +50,7 @@ Rolling updates are initiated with the `kubectl rolling-update` command:
To initiate a rolling update using a configuration file, pass the new file to
`kubectl rolling-update`:
$ kubectl rolling-update NAME -f FILE
kubectl rolling-update NAME -f FILE
The configuration file must:
@@ -66,17 +66,17 @@ Replication controller configuration files are described in
### Examples
// Update pods of frontend-v1 using new replication controller data in frontend-v2.json.
$ kubectl rolling-update frontend-v1 -f frontend-v2.json
kubectl rolling-update frontend-v1 -f frontend-v2.json
// Update pods of frontend-v1 using JSON data passed into stdin.
$ cat frontend-v2.json | kubectl rolling-update frontend-v1 -f -
cat frontend-v2.json | kubectl rolling-update frontend-v1 -f -
## Updating the container image
To update only the container image, pass a new image name and tag with the
`--image` flag and (optionally) a new controller name:
$ kubectl rolling-update NAME [NEW_NAME] --image=IMAGE:TAG
kubectl rolling-update NAME [NEW_NAME] --image=IMAGE:TAG
The `--image` flag is only supported for single-container pods. Specifying
`--image` with multi-container pods returns an error.
@@ -95,10 +95,10 @@ Moreover, the use of `:latest` is not recommended, see
### Examples
// Update the pods of frontend-v1 to frontend-v2
$ kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2
kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2
// Update the pods of frontend, keeping the replication controller name
$ kubectl rolling-update frontend --image=image:v2
kubectl rolling-update frontend --image=image:v2
## Required and optional fields
@@ -165,14 +165,18 @@ spec:
To update to version 1.9.1, you can use [`kubectl rolling-update --image`](https://git.k8s.io/community/contributors/design-proposals/cli/simple-rolling-update.md) to specify the new image:
```shell
$ kubectl rolling-update my-nginx --image=nginx:1.9.1
kubectl rolling-update my-nginx --image=nginx:1.9.1
```
```
Created my-nginx-ccba8fbd8cc8160970f63f9a2696fc46
```
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:
```shell
$ kubectl get pods -l app=nginx -L deployment
kubectl get pods -l app=nginx -L deployment
```
```
NAME READY STATUS RESTARTS AGE DEPLOYMENT
my-nginx-ccba8fbd8cc8160970f63f9a2696fc46-k156z 1/1 Running 0 1m ccba8fbd8cc8160970f63f9a2696fc46
my-nginx-ccba8fbd8cc8160970f63f9a2696fc46-v95yh 1/1 Running 0 35s ccba8fbd8cc8160970f63f9a2696fc46
@@ -199,7 +203,9 @@ replicationcontroller "my-nginx" rolling updated
If you encounter a problem, you can stop the rolling update midway and revert to the previous version using `--rollback`:
```shell
$ kubectl rolling-update my-nginx --rollback
kubectl rolling-update my-nginx --rollback
```
```
Setting "my-nginx" replicas to 1
Continuing update with existing controller my-nginx.
Scaling up nginx from 1 to 1, scaling down my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 from 1 to 0 (keep 1 pods available, don't exceed 2 pods)
@@ -239,7 +245,9 @@ spec:
and roll it out:
```shell
$ kubectl rolling-update my-nginx -f ./nginx-rc.yaml
kubectl rolling-update my-nginx -f ./nginx-rc.yaml
```
```
Created my-nginx-v4
Scaling up my-nginx-v4 from 0 to 5, scaling down my-nginx from 4 to 0 (keep 4 pods available, don't exceed 5 pods)
Scaling my-nginx-v4 up to 1