Code snippents shouldn't include the command prompt (#12779)
This commit is contained in:
Neha Yadav
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
99e4d3bac6
commit
d3cca48e3f
@@ -96,7 +96,9 @@ kubectl create -f my-scheduler.yaml
|
||||
Verify that the scheduler pod is running:
|
||||
|
||||
```shell
|
||||
$ kubectl get pods --namespace=kube-system
|
||||
kubectl get pods --namespace=kube-system
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
....
|
||||
my-scheduler-lnf4s-4744f 1/1 Running 0 2m
|
||||
@@ -116,7 +118,9 @@ First, update the following fields in your YAML file:
|
||||
|
||||
If RBAC is enabled on your cluster, you must update the `system:kube-scheduler` cluster role. Add your scheduler name to the resourceNames of the rule applied for endpoints resources, as in the following example:
|
||||
```
|
||||
$ kubectl edit clusterrole system:kube-scheduler
|
||||
kubectl edit clusterrole system:kube-scheduler
|
||||
```
|
||||
```yaml
|
||||
- apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
|
||||
@@ -42,7 +42,7 @@ Set the following flag:
|
||||
The following sample command sets up a HA-compatible cluster in the GCE zone europe-west1-b:
|
||||
|
||||
```shell
|
||||
$ MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh
|
||||
MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh
|
||||
```
|
||||
|
||||
Note that the commands above create a cluster with one master;
|
||||
@@ -65,7 +65,7 @@ as those are inherited from when you started your HA-compatible cluster.
|
||||
The following sample command replicates the master on an existing HA-compatible cluster:
|
||||
|
||||
```shell
|
||||
$ KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
|
||||
KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
|
||||
```
|
||||
|
||||
## Removing a master replica
|
||||
@@ -82,7 +82,7 @@ If empty: any replica from the given zone will be removed.
|
||||
The following sample command removes a master replica from an existing HA cluster:
|
||||
|
||||
```shell
|
||||
$ KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh
|
||||
KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh
|
||||
```
|
||||
|
||||
## Handling master replica failures
|
||||
@@ -94,13 +94,13 @@ The following sample commands demonstrate this process:
|
||||
1. Remove the broken replica:
|
||||
|
||||
```shell
|
||||
$ KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh
|
||||
KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh
|
||||
```
|
||||
|
||||
<ol start="2"><li>Add a new replica in place of the old one:</li></ol>
|
||||
|
||||
```shell
|
||||
$ KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
|
||||
KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
|
||||
```
|
||||
|
||||
## Best practices for replicating masters for HA clusters
|
||||
|
||||
@@ -71,10 +71,14 @@ Otherwise, you must manually approve certificates with the [`kubectl certificate
|
||||
The following kubeadm command outputs the name of the certificate to approve, then blocks and waits for approval to occur:
|
||||
|
||||
```shell
|
||||
$ sudo kubeadm alpha certs renew apiserver --use-api &
|
||||
sudo kubeadm alpha certs renew apiserver --use-api &
|
||||
```
|
||||
```
|
||||
[1] 2890
|
||||
[certs] certificate request "kubeadm-cert-kube-apiserver-ld526" created
|
||||
$ kubectl certificate approve kubeadm-cert-kube-apiserver-ld526
|
||||
```
|
||||
```shell
|
||||
kubectl certificate approve kubeadm-cert-kube-apiserver-ld526
|
||||
certificatesigningrequest.certificates.k8s.io/kubeadm-cert-kube-apiserver-ld526 approved
|
||||
[1]+ Done sudo kubeadm alpha certs renew apiserver --use-api
|
||||
```
|
||||
|
||||
@@ -45,7 +45,9 @@ Services, and Deployments used by the cluster.
|
||||
Assuming you have a fresh cluster, you can inspect the available namespaces by doing the following:
|
||||
|
||||
```shell
|
||||
$ kubectl get namespaces
|
||||
kubectl get namespaces
|
||||
```
|
||||
```
|
||||
NAME STATUS AGE
|
||||
default Active 13m
|
||||
```
|
||||
@@ -74,7 +76,7 @@ Use the file [`namespace-dev.json`](/examples/admin/namespace-dev.json) which de
|
||||
Create the `development` namespace using kubectl.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://k8s.io/examples/admin/namespace-dev.json
|
||||
kubectl create -f https://k8s.io/examples/admin/namespace-dev.json
|
||||
```
|
||||
|
||||
Save the following contents into file [`namespace-prod.json`](/examples/admin/namespace-prod.json) which describes a `production` namespace:
|
||||
@@ -84,13 +86,15 @@ Save the following contents into file [`namespace-prod.json`](/examples/admin/na
|
||||
And then let's create the `production` namespace using kubectl.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://k8s.io/examples/admin/namespace-prod.json
|
||||
kubectl create -f https://k8s.io/examples/admin/namespace-prod.json
|
||||
```
|
||||
|
||||
To be sure things are right, let's list all of the namespaces in our cluster.
|
||||
|
||||
```shell
|
||||
$ kubectl get namespaces --show-labels
|
||||
kubectl get namespaces --show-labels
|
||||
```
|
||||
```
|
||||
NAME STATUS AGE LABELS
|
||||
default Active 32m <none>
|
||||
development Active 29s name=development
|
||||
@@ -108,7 +112,9 @@ To demonstrate this, let's spin up a simple Deployment and Pods in the `developm
|
||||
We first check what is the current context:
|
||||
|
||||
```shell
|
||||
$ kubectl config view
|
||||
kubectl config view
|
||||
```
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
@@ -133,18 +139,22 @@ users:
|
||||
user:
|
||||
password: h5M0FtUUIflBSdI7
|
||||
username: admin
|
||||
|
||||
$ kubectl config current-context
|
||||
```
|
||||
```shell
|
||||
kubectl config current-context
|
||||
```
|
||||
```
|
||||
lithe-cocoa-92103_kubernetes
|
||||
```
|
||||
|
||||
The next step is to define a context for the kubectl client to work in each namespace. The value of "cluster" and "user" fields are copied from the current context.
|
||||
|
||||
```shell
|
||||
$ kubectl config set-context dev --namespace=development \
|
||||
kubectl config set-context dev --namespace=development \
|
||||
--cluster=lithe-cocoa-92103_kubernetes \
|
||||
--user=lithe-cocoa-92103_kubernetes
|
||||
$ kubectl config set-context prod --namespace=production \
|
||||
|
||||
kubectl config set-context prod --namespace=production \
|
||||
--cluster=lithe-cocoa-92103_kubernetes \
|
||||
--user=lithe-cocoa-92103_kubernetes
|
||||
```
|
||||
@@ -156,7 +166,9 @@ new request contexts depending on which namespace you wish to work against.
|
||||
To view the new contexts:
|
||||
|
||||
```shell
|
||||
$ kubectl config view
|
||||
kubectl config view
|
||||
```
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
@@ -196,13 +208,15 @@ users:
|
||||
Let's switch to operate in the `development` namespace.
|
||||
|
||||
```shell
|
||||
$ kubectl config use-context dev
|
||||
kubectl config use-context dev
|
||||
```
|
||||
|
||||
You can verify your current context by doing the following:
|
||||
|
||||
```shell
|
||||
$ kubectl config current-context
|
||||
kubectl config current-context
|
||||
```
|
||||
```
|
||||
dev
|
||||
```
|
||||
|
||||
@@ -211,18 +225,24 @@ At this point, all requests we make to the Kubernetes cluster from the command l
|
||||
Let's create some contents.
|
||||
|
||||
```shell
|
||||
$ kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2
|
||||
kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2
|
||||
```
|
||||
We have just created a deployment whose replica size is 2 that is running the pod called `snowflake` with a basic container that just serves the hostname.
|
||||
Note that `kubectl run` creates deployments only on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead.
|
||||
If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) for more details.
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
kubectl get deployment
|
||||
```
|
||||
```
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
snowflake 2 2 2 2 2m
|
||||
```
|
||||
|
||||
$ kubectl get pods -l run=snowflake
|
||||
```shell
|
||||
kubectl get pods -l run=snowflake
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
snowflake-3968820950-9dgr8 1/1 Running 0 2m
|
||||
snowflake-3968820950-vgc4n 1/1 Running 0 2m
|
||||
@@ -233,22 +253,24 @@ And this is great, developers are able to do what they want, and they do not hav
|
||||
Let's switch to the `production` namespace and show how resources in one namespace are hidden from the other.
|
||||
|
||||
```shell
|
||||
$ kubectl config use-context prod
|
||||
kubectl config use-context prod
|
||||
```
|
||||
|
||||
The `production` namespace should be empty, and the following commands should return nothing.
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
$ kubectl get pods
|
||||
kubectl get deployment
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
Production likes to run cattle, so let's create some cattle pods.
|
||||
|
||||
```shell
|
||||
$ kubectl run cattle --image=kubernetes/serve_hostname --replicas=5
|
||||
kubectl run cattle --image=kubernetes/serve_hostname --replicas=5
|
||||
|
||||
$ kubectl get deployment
|
||||
kubectl get deployment
|
||||
```
|
||||
```
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
cattle 5 5 5 5 10s
|
||||
|
||||
|
||||
@@ -22,7 +22,9 @@ This page shows how to view, work in, and delete {{< glossary_tooltip text="name
|
||||
1. List the current namespaces in a cluster using:
|
||||
|
||||
```shell
|
||||
$ kubectl get namespaces
|
||||
kubectl get namespaces
|
||||
```
|
||||
```
|
||||
NAME STATUS AGE
|
||||
default Active 11d
|
||||
kube-system Active 11d
|
||||
@@ -38,13 +40,15 @@ Kubernetes starts with three initial namespaces:
|
||||
You can also get the summary of a specific namespace using:
|
||||
|
||||
```shell
|
||||
$ kubectl get namespaces <name>
|
||||
kubectl get namespaces <name>
|
||||
```
|
||||
|
||||
Or you can get detailed information with:
|
||||
|
||||
```shell
|
||||
$ kubectl describe namespaces <name>
|
||||
kubectl describe namespaces <name>
|
||||
```
|
||||
```
|
||||
Name: default
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
@@ -89,7 +93,7 @@ metadata:
|
||||
Then run:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f ./my-namespace.yaml
|
||||
kubectl create -f ./my-namespace.yaml
|
||||
```
|
||||
|
||||
Note that the name of your namespace must be a DNS compatible label.
|
||||
@@ -103,7 +107,7 @@ More information on `finalizers` can be found in the namespace [design doc](http
|
||||
1. Delete a namespace with
|
||||
|
||||
```shell
|
||||
$ kubectl delete namespaces <insert-some-namespace-name>
|
||||
kubectl delete namespaces <insert-some-namespace-name>
|
||||
```
|
||||
|
||||
{{< warning >}}
|
||||
@@ -122,7 +126,9 @@ Services, and Deployments used by the cluster.
|
||||
Assuming you have a fresh cluster, you can introspect the available namespace's by doing the following:
|
||||
|
||||
```shell
|
||||
$ kubectl get namespaces
|
||||
kubectl get namespaces
|
||||
```
|
||||
```
|
||||
NAME STATUS AGE
|
||||
default Active 13m
|
||||
```
|
||||
@@ -151,19 +157,21 @@ Use the file [`namespace-dev.json`](/examples/admin/namespace-dev.json) which de
|
||||
Create the `development` namespace using kubectl.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://k8s.io/examples/admin/namespace-dev.json
|
||||
kubectl create -f https://k8s.io/examples/admin/namespace-dev.json
|
||||
```
|
||||
|
||||
And then let's create the `production` namespace using kubectl.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://k8s.io/examples/admin/namespace-prod.json
|
||||
kubectl create -f https://k8s.io/examples/admin/namespace-prod.json
|
||||
```
|
||||
|
||||
To be sure things are right, list all of the namespaces in our cluster.
|
||||
|
||||
```shell
|
||||
$ kubectl get namespaces --show-labels
|
||||
kubectl get namespaces --show-labels
|
||||
```
|
||||
```
|
||||
NAME STATUS AGE LABELS
|
||||
default Active 32m <none>
|
||||
development Active 29s name=development
|
||||
@@ -181,7 +189,9 @@ To demonstrate this, let's spin up a simple Deployment and Pods in the `developm
|
||||
We first check what is the current context:
|
||||
|
||||
```shell
|
||||
$ kubectl config view
|
||||
kubectl config view
|
||||
```
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
@@ -206,16 +216,20 @@ users:
|
||||
user:
|
||||
password: h5M0FtUUIflBSdI7
|
||||
username: admin
|
||||
```
|
||||
|
||||
$ kubectl config current-context
|
||||
```shell
|
||||
kubectl config current-context
|
||||
```
|
||||
```
|
||||
lithe-cocoa-92103_kubernetes
|
||||
```
|
||||
|
||||
The next step is to define a context for the kubectl client to work in each namespace. The values of "cluster" and "user" fields are copied from the current context.
|
||||
|
||||
```shell
|
||||
$ kubectl config set-context dev --namespace=development --cluster=lithe-cocoa-92103_kubernetes --user=lithe-cocoa-92103_kubernetes
|
||||
$ kubectl config set-context prod --namespace=production --cluster=lithe-cocoa-92103_kubernetes --user=lithe-cocoa-92103_kubernetes
|
||||
kubectl config set-context dev --namespace=development --cluster=lithe-cocoa-92103_kubernetes --user=lithe-cocoa-92103_kubernetes
|
||||
kubectl config set-context prod --namespace=production --cluster=lithe-cocoa-92103_kubernetes --user=lithe-cocoa-92103_kubernetes
|
||||
```
|
||||
|
||||
The above commands provided two request contexts you can alternate against depending on what namespace you
|
||||
@@ -224,13 +238,13 @@ wish to work against.
|
||||
Let's switch to operate in the `development` namespace.
|
||||
|
||||
```shell
|
||||
$ kubectl config use-context dev
|
||||
kubectl config use-context dev
|
||||
```
|
||||
|
||||
You can verify your current context by doing the following:
|
||||
|
||||
```shell
|
||||
$ kubectl config current-context
|
||||
kubectl config current-context
|
||||
dev
|
||||
```
|
||||
|
||||
@@ -239,18 +253,23 @@ At this point, all requests we make to the Kubernetes cluster from the command l
|
||||
Let's create some contents.
|
||||
|
||||
```shell
|
||||
$ kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2
|
||||
kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2
|
||||
```
|
||||
We have just created a deployment whose replica size is 2 that is running the pod called `snowflake` with a basic container that just serves the hostname.
|
||||
Note that `kubectl run` creates deployments only on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead.
|
||||
If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) for more details.
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
kubectl get deployment
|
||||
```
|
||||
```
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
snowflake 2 2 2 2 2m
|
||||
|
||||
$ kubectl get pods -l run=snowflake
|
||||
```
|
||||
```shell
|
||||
kubectl get pods -l run=snowflake
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
snowflake-3968820950-9dgr8 1/1 Running 0 2m
|
||||
snowflake-3968820950-vgc4n 1/1 Running 0 2m
|
||||
@@ -261,26 +280,32 @@ And this is great, developers are able to do what they want, and they do not hav
|
||||
Let's switch to the `production` namespace and show how resources in one namespace are hidden from the other.
|
||||
|
||||
```shell
|
||||
$ kubectl config use-context prod
|
||||
kubectl config use-context prod
|
||||
```
|
||||
|
||||
The `production` namespace should be empty, and the following commands should return nothing.
|
||||
|
||||
```shell
|
||||
$ kubectl get deployment
|
||||
$ kubectl get pods
|
||||
kubectl get deployment
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
Production likes to run cattle, so let's create some cattle pods.
|
||||
|
||||
```shell
|
||||
$ kubectl run cattle --image=kubernetes/serve_hostname --replicas=5
|
||||
kubectl run cattle --image=kubernetes/serve_hostname --replicas=5
|
||||
|
||||
$ kubectl get deployment
|
||||
kubectl get deployment
|
||||
```
|
||||
```
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
|
||||
cattle 5 5 5 5 10s
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl get pods -l run=cattle
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
cattle-2263376956-41xy6 1/1 Running 0 34s
|
||||
cattle-2263376956-kw466 1/1 Running 0 34s
|
||||
|
||||
+10
-4
@@ -30,10 +30,14 @@ To start minikube, minimal version required is >= v0.33.1, run the with the
|
||||
following arguments:
|
||||
|
||||
```shell
|
||||
$ minikube version
|
||||
minikube version
|
||||
```
|
||||
```
|
||||
minikube version: v0.33.1
|
||||
$
|
||||
$ minikube start --network-plugin=cni --memory=4096
|
||||
```
|
||||
|
||||
```shell
|
||||
minikube start --network-plugin=cni --memory=4096
|
||||
```
|
||||
|
||||
For minikube you can deploy this simple ''all-in-one'' YAML file that includes
|
||||
@@ -41,7 +45,9 @@ DaemonSet configurations for Cilium, and the necessary configurations to connect
|
||||
to the etcd instance deployed in minikube as well as appropriate RBAC settings:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.4/examples/kubernetes/1.13/cilium-minikube.yaml
|
||||
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.4/examples/kubernetes/1.13/cilium-minikube.yaml
|
||||
```
|
||||
```
|
||||
configmap/cilium-config created
|
||||
daemonset.apps/cilium created
|
||||
clusterrolebinding.rbac.authorization.k8s.io/cilium created
|
||||
|
||||
@@ -117,7 +117,7 @@ itself. To attempt an eviction (perhaps more REST-precisely, to attempt to
|
||||
You can attempt an eviction using `curl`:
|
||||
|
||||
```bash
|
||||
$ curl -v -H 'Content-type: application/json' http://127.0.0.1:8080/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json
|
||||
curl -v -H 'Content-type: application/json' http://127.0.0.1:8080/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json
|
||||
```
|
||||
|
||||
The API can respond in one of three ways:
|
||||
|
||||
@@ -36,7 +36,7 @@ process file system. The parameters cover various subsystems such as:
|
||||
To get a list of all parameters, you can run
|
||||
|
||||
```shell
|
||||
$ sudo sysctl -a
|
||||
sudo sysctl -a
|
||||
```
|
||||
|
||||
## Enabling Unsafe Sysctls
|
||||
@@ -76,14 +76,14 @@ application tuning. _Unsafe_ sysctls are enabled on a node-by-node basis with a
|
||||
flag of the kubelet, e.g.:
|
||||
|
||||
```shell
|
||||
$ kubelet --allowed-unsafe-sysctls \
|
||||
kubelet --allowed-unsafe-sysctls \
|
||||
'kernel.msg*,net.ipv4.route.min_pmtu' ...
|
||||
```
|
||||
|
||||
For minikube, this can be done via the `extra-config` flag:
|
||||
|
||||
```shell
|
||||
$ minikube start --extra-config="kubelet.AllowedUnsafeSysctls=kernel.msg*,net.ipv4.route.min_pmtu"...
|
||||
minikube start --extra-config="kubelet.AllowedUnsafeSysctls=kernel.msg*,net.ipv4.route.min_pmtu"...
|
||||
```
|
||||
|
||||
Only _namespaced_ sysctls can be enabled this way.
|
||||
|
||||
@@ -31,7 +31,7 @@ your Service?
|
||||
The first step in debugging a Pod is taking a look at it. Check the current state of the Pod and recent events with the following command:
|
||||
|
||||
```shell
|
||||
$ kubectl describe pods ${POD_NAME}
|
||||
kubectl describe pods ${POD_NAME}
|
||||
```
|
||||
|
||||
Look at the state of the containers in the pod. Are they all `Running`? Have there been recent restarts?
|
||||
@@ -68,19 +68,19 @@ First, take a look at the logs of
|
||||
the current container:
|
||||
|
||||
```shell
|
||||
$ kubectl logs ${POD_NAME} ${CONTAINER_NAME}
|
||||
kubectl logs ${POD_NAME} ${CONTAINER_NAME}
|
||||
```
|
||||
|
||||
If your container has previously crashed, you can access the previous container's crash log with:
|
||||
|
||||
```shell
|
||||
$ kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}
|
||||
kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}
|
||||
```
|
||||
|
||||
Alternately, you can run commands inside that container with `exec`:
|
||||
|
||||
```shell
|
||||
$ kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
|
||||
kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
@@ -90,7 +90,7 @@ $ kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${
|
||||
As an example, to look at the logs from a running Cassandra pod, you might run
|
||||
|
||||
```shell
|
||||
$ kubectl exec cassandra -- cat /var/log/cassandra/system.log
|
||||
kubectl exec cassandra -- cat /var/log/cassandra/system.log
|
||||
```
|
||||
|
||||
If none of these approaches work, you can find the host machine that the pod is running on and SSH into that host,
|
||||
@@ -145,7 +145,7 @@ First, verify that there are endpoints for the service. For every Service object
|
||||
You can view this resource with:
|
||||
|
||||
```shell
|
||||
$ kubectl get endpoints ${SERVICE_NAME}
|
||||
kubectl get endpoints ${SERVICE_NAME}
|
||||
```
|
||||
|
||||
Make sure that the endpoints match up with the number of containers that you expect to be a member of your service.
|
||||
@@ -168,7 +168,7 @@ spec:
|
||||
You can use:
|
||||
|
||||
```shell
|
||||
$ kubectl get pods --selector=name=nginx,type=frontend
|
||||
kubectl get pods --selector=name=nginx,type=frontend
|
||||
```
|
||||
|
||||
to list pods that match this selector. Verify that the list matches the Pods that you expect to provide your Service.
|
||||
|
||||
@@ -39,7 +39,9 @@ Now, when you create a cluster, a message will indicate that the Fluentd log
|
||||
collection daemons that run on each node will target Elasticsearch:
|
||||
|
||||
```shell
|
||||
$ cluster/kube-up.sh
|
||||
cluster/kube-up.sh
|
||||
```
|
||||
```
|
||||
...
|
||||
Project: kubernetes-satnam
|
||||
Zone: us-central1-b
|
||||
@@ -63,7 +65,9 @@ all be running in the kube-system namespace soon after the cluster comes to
|
||||
life.
|
||||
|
||||
```shell
|
||||
$ kubectl get pods --namespace=kube-system
|
||||
kubectl get pods --namespace=kube-system
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
elasticsearch-logging-v1-78nog 1/1 Running 0 2h
|
||||
elasticsearch-logging-v1-nj2nb 1/1 Running 0 2h
|
||||
|
||||
@@ -145,7 +145,9 @@ kubectl create -f https://k8s.io/examples/debug/counter-pod.yaml
|
||||
You can observe the running pod:
|
||||
|
||||
```shell
|
||||
$ kubectl get pods
|
||||
kubectl get pods
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
counter 1/1 Running 0 5m
|
||||
```
|
||||
@@ -155,7 +157,9 @@ has to download the container image first. When the pod status changes to `Runni
|
||||
you can use the `kubectl logs` command to view the output of this counter pod.
|
||||
|
||||
```shell
|
||||
$ kubectl logs counter
|
||||
kubectl logs counter
|
||||
```
|
||||
```
|
||||
0: Mon Jan 1 00:00:00 UTC 2001
|
||||
1: Mon Jan 1 00:00:01 UTC 2001
|
||||
2: Mon Jan 1 00:00:02 UTC 2001
|
||||
@@ -169,21 +173,27 @@ if the pod is evicted from the node, log files are lost. Let's demonstrate this
|
||||
by deleting the currently running counter container:
|
||||
|
||||
```shell
|
||||
$ kubectl delete pod counter
|
||||
kubectl delete pod counter
|
||||
```
|
||||
```
|
||||
pod "counter" deleted
|
||||
```
|
||||
|
||||
and then recreating it:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://k8s.io/examples/debug/counter-pod.yaml
|
||||
kubectl create -f https://k8s.io/examples/debug/counter-pod.yaml
|
||||
```
|
||||
```
|
||||
pod/counter created
|
||||
```
|
||||
|
||||
After some time, you can access logs from the counter pod again:
|
||||
|
||||
```shell
|
||||
$ kubectl logs counter
|
||||
kubectl logs counter
|
||||
```
|
||||
```
|
||||
0: Mon Jan 1 00:01:00 UTC 2001
|
||||
1: Mon Jan 1 00:01:01 UTC 2001
|
||||
2: Mon Jan 1 00:01:02 UTC 2001
|
||||
@@ -226,7 +236,9 @@ It uses Stackdriver Logging [filtering syntax](https://cloud.google.com/logging/
|
||||
to query specific logs. For example, you can run the following command:
|
||||
|
||||
```none
|
||||
$ gcloud beta logging read 'logName="projects/$YOUR_PROJECT_ID/logs/count"' --format json | jq '.[].textPayload'
|
||||
gcloud beta logging read 'logName="projects/$YOUR_PROJECT_ID/logs/count"' --format json | jq '.[].textPayload'
|
||||
```
|
||||
```
|
||||
...
|
||||
"2: Mon Jan 1 00:01:02 UTC 2001\n"
|
||||
"1: Mon Jan 1 00:01:01 UTC 2001\n"
|
||||
|
||||
@@ -96,25 +96,35 @@ sudo mv ./kubectl-foo /usr/local/bin
|
||||
You may now invoke your plugin as a `kubectl` command:
|
||||
|
||||
```
|
||||
$ kubectl foo
|
||||
kubectl foo
|
||||
```
|
||||
```
|
||||
I am a plugin named kubectl-foo
|
||||
```
|
||||
|
||||
All args and flags are passed as-is to the executable:
|
||||
|
||||
```
|
||||
$ kubectl foo version
|
||||
kubectl foo version
|
||||
```
|
||||
```
|
||||
1.0.0
|
||||
```
|
||||
|
||||
All environment variables are also passed as-is to the executable:
|
||||
|
||||
```bash
|
||||
$ export KUBECONFIG=~/.kube/config
|
||||
$ kubectl foo config
|
||||
export KUBECONFIG=~/.kube/config
|
||||
kubectl foo config
|
||||
```
|
||||
```
|
||||
/home/<user>/.kube/config
|
||||
```
|
||||
|
||||
$ KUBECONFIG=/etc/kube/config kubectl foo config
|
||||
```shell
|
||||
KUBECONFIG=/etc/kube/config kubectl foo config
|
||||
```
|
||||
```
|
||||
/etc/kube/config
|
||||
```
|
||||
|
||||
@@ -142,22 +152,27 @@ Example:
|
||||
|
||||
```bash
|
||||
# create a plugin
|
||||
$ echo '#!/bin/bash\n\necho "My first command-line argument was $1"' > kubectl-foo-bar-baz
|
||||
$ sudo chmod +x ./kubectl-foo-bar-baz
|
||||
echo '#!/bin/bash\n\necho "My first command-line argument was $1"' > kubectl-foo-bar-baz
|
||||
sudo chmod +x ./kubectl-foo-bar-baz
|
||||
|
||||
# "install" our plugin by placing it on our PATH
|
||||
$ sudo mv ./kubectl-foo-bar-baz /usr/local/bin
|
||||
sudo mv ./kubectl-foo-bar-baz /usr/local/bin
|
||||
|
||||
# ensure our plugin is recognized by kubectl
|
||||
$ kubectl plugin list
|
||||
kubectl plugin list
|
||||
```
|
||||
```
|
||||
The following kubectl-compatible plugins are available:
|
||||
|
||||
/usr/local/bin/kubectl-foo-bar-baz
|
||||
|
||||
```
|
||||
```
|
||||
# test that calling our plugin via a "kubectl" command works
|
||||
# even when additional arguments and flags are passed to our
|
||||
# plugin executable by the user.
|
||||
$ kubectl foo bar baz arg1 --meaningless-flag=true
|
||||
kubectl foo bar baz arg1 --meaningless-flag=true
|
||||
```
|
||||
```
|
||||
My first command-line argument was arg1
|
||||
```
|
||||
|
||||
@@ -172,14 +187,16 @@ Example:
|
||||
|
||||
```bash
|
||||
# create a plugin containing an underscore in its filename
|
||||
$ echo '#!/bin/bash\n\necho "I am a plugin with a dash in my name"' > ./kubectl-foo_bar
|
||||
$ sudo chmod +x ./kubectl-foo_bar
|
||||
echo '#!/bin/bash\n\necho "I am a plugin with a dash in my name"' > ./kubectl-foo_bar
|
||||
sudo chmod +x ./kubectl-foo_bar
|
||||
|
||||
# move the plugin into your PATH
|
||||
$ sudo mv ./kubectl-foo_bar /usr/local/bin
|
||||
sudo mv ./kubectl-foo_bar /usr/local/bin
|
||||
|
||||
# our plugin can now be invoked from `kubectl` like so:
|
||||
$ kubectl foo-bar
|
||||
kubectl foo-bar
|
||||
```
|
||||
```
|
||||
I am a plugin with a dash in my name
|
||||
```
|
||||
|
||||
@@ -188,11 +205,17 @@ The command from the above example, can be invoked using either a dash (`-`) or
|
||||
|
||||
```bash
|
||||
# our plugin can be invoked with a dash
|
||||
$ kubectl foo-bar
|
||||
kubectl foo-bar
|
||||
```
|
||||
```
|
||||
I am a plugin with a dash in my name
|
||||
```
|
||||
|
||||
```bash
|
||||
# it can also be invoked using an underscore
|
||||
$ kubectl foo_bar
|
||||
kubectl foo_bar
|
||||
```
|
||||
```
|
||||
I am a plugin with a dash in my name
|
||||
```
|
||||
|
||||
@@ -203,7 +226,9 @@ For example, given a PATH with the following value: `PATH=/usr/local/bin/plugins
|
||||
such that the output of the `kubectl plugin list` command is:
|
||||
|
||||
```bash
|
||||
$ PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins kubectl plugin list
|
||||
PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins kubectl plugin list
|
||||
```
|
||||
```bash
|
||||
The following kubectl-compatible plugins are available:
|
||||
|
||||
/usr/local/bin/plugins/kubectl-foo
|
||||
@@ -223,23 +248,39 @@ There is another kind of overshadowing that can occur with plugin filenames. Giv
|
||||
|
||||
```bash
|
||||
# for a given kubectl command, the plugin with the longest possible filename will always be preferred
|
||||
$ kubectl foo bar baz
|
||||
kubectl foo bar baz
|
||||
```
|
||||
```
|
||||
Plugin kubectl-foo-bar-baz is executed
|
||||
```
|
||||
|
||||
$ kubectl foo bar
|
||||
```bash
|
||||
kubectl foo bar
|
||||
```
|
||||
```
|
||||
Plugin kubectl-foo-bar is executed
|
||||
```
|
||||
|
||||
$ kubectl foo bar baz buz
|
||||
```bash
|
||||
kubectl foo bar baz buz
|
||||
```
|
||||
```
|
||||
Plugin kubectl-foo-bar-baz is executed, with "buz" as its first argument
|
||||
```
|
||||
|
||||
$ kubectl foo bar buz
|
||||
```bash
|
||||
kubectl foo bar buz
|
||||
```
|
||||
```
|
||||
Plugin kubectl-foo-bar is executed, with "buz" as its first argument
|
||||
```
|
||||
|
||||
This design choice ensures that plugin sub-commands can be implemented across multiple files, if needed, and that these sub-commands can be nested under a "parent" plugin command:
|
||||
|
||||
```bash
|
||||
$ ls ./plugin_command_tree
|
||||
ls ./plugin_command_tree
|
||||
```
|
||||
```
|
||||
kubectl-parent
|
||||
kubectl-parent-subcommand
|
||||
kubectl-parent-subcommand-subsubcommand
|
||||
@@ -250,7 +291,9 @@ kubectl-parent-subcommand-subsubcommand
|
||||
You can use the aforementioned `kubectl plugin list` command to ensure that your plugin is visible by `kubectl`, and verify that there are no warnings preventing it from being called as a `kubectl` command.
|
||||
|
||||
```bash
|
||||
$ kubectl plugin list
|
||||
kubectl plugin list
|
||||
```
|
||||
```
|
||||
The following kubectl-compatible plugins are available:
|
||||
|
||||
test/fixtures/pkg/kubectl/plugins/kubectl-foo
|
||||
|
||||
@@ -118,8 +118,9 @@ The status of your Federated Service will automatically reflect the
|
||||
real-time status of the underlying Kubernetes services, for example:
|
||||
|
||||
``` shell
|
||||
$kubectl --context=federation-cluster describe services nginx
|
||||
|
||||
kubectl --context=federation-cluster describe services nginx
|
||||
```
|
||||
```
|
||||
Name: nginx
|
||||
Namespace: default
|
||||
Labels: run=nginx
|
||||
@@ -187,7 +188,9 @@ this. For example, if your Federation is configured to use Google
|
||||
Cloud DNS, and a managed DNS domain 'example.com':
|
||||
|
||||
``` shell
|
||||
$ gcloud dns managed-zones describe example-dot-com
|
||||
gcloud dns managed-zones describe example-dot-com
|
||||
```
|
||||
```
|
||||
creationTime: '2016-06-26T18:18:39.229Z'
|
||||
description: Example domain for Kubernetes Cluster Federation
|
||||
dnsName: example.com.
|
||||
@@ -202,7 +205,9 @@ nameServers:
|
||||
```
|
||||
|
||||
```shell
|
||||
$ gcloud dns record-sets list --zone example-dot-com
|
||||
gcloud dns record-sets list --zone example-dot-com
|
||||
```
|
||||
```
|
||||
NAME TYPE TTL DATA
|
||||
example.com. NS 21600 ns-cloud-e1.googledomains.com., ns-cloud-e2.googledomains.com.
|
||||
example.com. OA 21600 ns-cloud-e1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 1209600 300
|
||||
@@ -225,12 +230,12 @@ nginx.mynamespace.myfederation.svc.europe-west1-d.example.com. CNAME 180
|
||||
If your Federation is configured to use AWS Route53, you can use one of the equivalent AWS tools, for example:
|
||||
|
||||
``` shell
|
||||
$ aws route53 list-hosted-zones
|
||||
aws route53 list-hosted-zones
|
||||
```
|
||||
and
|
||||
|
||||
``` shell
|
||||
$ aws route53 list-resource-record-sets --hosted-zone-id Z3ECL0L9QLOVBX
|
||||
aws route53 list-resource-record-sets --hosted-zone-id Z3ECL0L9QLOVBX
|
||||
```
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -42,7 +42,9 @@ kubectl create -f https://k8s.io/examples/podpreset/preset.yaml
|
||||
Examine the created PodPreset:
|
||||
|
||||
```shell
|
||||
$ kubectl get podpreset
|
||||
kubectl get podpreset
|
||||
```
|
||||
```
|
||||
NAME AGE
|
||||
allow-database 1m
|
||||
```
|
||||
@@ -54,13 +56,15 @@ The new PodPreset will act upon any pod that has label `role: frontend`.
|
||||
Create a pod:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f https://k8s.io/examples/podpreset/pod.yaml
|
||||
kubectl create -f https://k8s.io/examples/podpreset/pod.yaml
|
||||
```
|
||||
|
||||
List the running Pods:
|
||||
|
||||
```shell
|
||||
$ kubectl get pods
|
||||
kubectl get pods
|
||||
```
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
website 1/1 Running 0 4m
|
||||
```
|
||||
@@ -72,7 +76,7 @@ website 1/1 Running 0 4m
|
||||
To see above output, run the following command:
|
||||
|
||||
```shell
|
||||
$ kubectl get pod website -o yaml
|
||||
kubectl get pod website -o yaml
|
||||
```
|
||||
|
||||
## Pod Spec with ConfigMap Example
|
||||
@@ -157,7 +161,9 @@ when there is a conflict.
|
||||
**If we run `kubectl describe...` we can see the event:**
|
||||
|
||||
```shell
|
||||
$ kubectl describe ...
|
||||
kubectl describe ...
|
||||
```
|
||||
```
|
||||
....
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Reason Message
|
||||
@@ -169,7 +175,9 @@ Events:
|
||||
Once you don't need a pod preset anymore, you can delete it with `kubectl`:
|
||||
|
||||
```shell
|
||||
$ kubectl delete podpreset allow-database
|
||||
kubectl delete podpreset allow-database
|
||||
```
|
||||
```
|
||||
podpreset "allow-database" deleted
|
||||
```
|
||||
|
||||
|
||||
@@ -50,21 +50,27 @@ This example cron job config `.spec` file prints the current time and a hello me
|
||||
Run the example cron job by downloading the example file and then running this command:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f ./cronjob.yaml
|
||||
kubectl create -f ./cronjob.yaml
|
||||
```
|
||||
```
|
||||
cronjob "hello" created
|
||||
```
|
||||
|
||||
Alternatively, you can use `kubectl run` to create a cron job without writing a full config:
|
||||
|
||||
```shell
|
||||
$ kubectl run hello --schedule="*/1 * * * *" --restart=OnFailure --image=busybox -- /bin/sh -c "date; echo Hello from the Kubernetes cluster"
|
||||
kubectl run hello --schedule="*/1 * * * *" --restart=OnFailure --image=busybox -- /bin/sh -c "date; echo Hello from the Kubernetes cluster"
|
||||
```
|
||||
```
|
||||
cronjob "hello" created
|
||||
```
|
||||
|
||||
After creating the cron job, get its status using this command:
|
||||
|
||||
```shell
|
||||
$ kubectl get cronjob hello
|
||||
kubectl get cronjob hello
|
||||
```
|
||||
```
|
||||
NAME SCHEDULE SUSPEND ACTIVE LAST-SCHEDULE
|
||||
hello */1 * * * * False 0 <none>
|
||||
```
|
||||
@@ -73,7 +79,9 @@ As you can see from the results of the command, the cron job has not scheduled o
|
||||
Watch for the job to be created in around one minute:
|
||||
|
||||
```shell
|
||||
$ kubectl get jobs --watch
|
||||
kubectl get jobs --watch
|
||||
```
|
||||
```
|
||||
NAME DESIRED SUCCESSFUL AGE
|
||||
hello-4111706356 1 1 2s
|
||||
```
|
||||
@@ -82,7 +90,9 @@ Now you've seen one running job scheduled by the "hello" cron job.
|
||||
You can stop watching the job and view the cron job again to see that it scheduled the job:
|
||||
|
||||
```shell
|
||||
$ kubectl get cronjob hello
|
||||
kubectl get cronjob hello
|
||||
```
|
||||
```
|
||||
NAME SCHEDULE SUSPEND ACTIVE LAST-SCHEDULE
|
||||
hello */1 * * * * False 0 Mon, 29 Aug 2016 14:34:00 -0700
|
||||
```
|
||||
@@ -95,12 +105,18 @@ Note that the job name and pod name are different.
|
||||
|
||||
```shell
|
||||
# Replace "hello-4111706356" with the job name in your system
|
||||
$ pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items..metadata.name})
|
||||
pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items..metadata.name})
|
||||
|
||||
$ echo $pods
|
||||
echo $pods
|
||||
```
|
||||
```
|
||||
hello-4111706356-o9qcm
|
||||
```
|
||||
|
||||
$ kubectl logs $pods
|
||||
```shell
|
||||
kubectl logs $pods
|
||||
```
|
||||
```
|
||||
Mon Aug 29 21:34:09 UTC 2016
|
||||
Hello from the Kubernetes cluster
|
||||
```
|
||||
@@ -110,7 +126,9 @@ Hello from the Kubernetes cluster
|
||||
When you don't need a cron job any more, delete it with `kubectl delete cronjob`:
|
||||
|
||||
```shell
|
||||
$ kubectl delete cronjob hello
|
||||
kubectl delete cronjob hello
|
||||
```
|
||||
```
|
||||
cronjob "hello" deleted
|
||||
```
|
||||
|
||||
|
||||
@@ -46,9 +46,16 @@ cluster and reuse it for many jobs, as well as for long-running services.
|
||||
Start RabbitMQ as follows:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f examples/celery-rabbitmq/rabbitmq-service.yaml
|
||||
kubectl create -f examples/celery-rabbitmq/rabbitmq-service.yaml
|
||||
```
|
||||
```
|
||||
service "rabbitmq-service" created
|
||||
$ kubectl create -f examples/celery-rabbitmq/rabbitmq-controller.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl create -f examples/celery-rabbitmq/rabbitmq-controller.yaml
|
||||
```
|
||||
```
|
||||
replicationcontroller "rabbitmq-controller" created
|
||||
```
|
||||
|
||||
@@ -64,7 +71,9 @@ First create a temporary interactive Pod.
|
||||
|
||||
```shell
|
||||
# Create a temporary interactive container
|
||||
$ kubectl run -i --tty temp --image ubuntu:18.04
|
||||
kubectl run -i --tty temp --image ubuntu:18.04
|
||||
```
|
||||
```
|
||||
Waiting for pod default/temp-loe07 to be running, status is Pending, pod ready: false
|
||||
... [ previous line repeats several times .. hit return when it stops ] ...
|
||||
```
|
||||
@@ -161,9 +170,11 @@ For our example, we will create the queue and fill it using the amqp command lin
|
||||
In practice, you might write a program to fill the queue using an amqp client library.
|
||||
|
||||
```shell
|
||||
$ /usr/bin/amqp-declare-queue --url=$BROKER_URL -q job1 -d
|
||||
/usr/bin/amqp-declare-queue --url=$BROKER_URL -q job1 -d
|
||||
job1
|
||||
$ for f in apple banana cherry date fig grape lemon melon
|
||||
```
|
||||
```shell
|
||||
for f in apple banana cherry date fig grape lemon melon
|
||||
do
|
||||
/usr/bin/amqp-publish --url=$BROKER_URL -r job1 -p -b $f
|
||||
done
|
||||
@@ -184,7 +195,7 @@ example program:
|
||||
Give the script execution permission:
|
||||
|
||||
```shell
|
||||
$ chmod +x worker.py
|
||||
chmod +x worker.py
|
||||
```
|
||||
|
||||
Now, build an image. If you are working in the source
|
||||
@@ -195,7 +206,7 @@ and [worker.py](/examples/application/job/rabbitmq/worker.py). In either case,
|
||||
build the image with this command:
|
||||
|
||||
```shell
|
||||
$ docker build -t job-wq-1 .
|
||||
docker build -t job-wq-1 .
|
||||
```
|
||||
|
||||
For the [Docker Hub](https://hub.docker.com/), tag your app image with
|
||||
@@ -240,7 +251,9 @@ kubectl create -f ./job.yaml
|
||||
Now wait a bit, then check on the job.
|
||||
|
||||
```shell
|
||||
$ kubectl describe jobs/job-wq-1
|
||||
kubectl describe jobs/job-wq-1
|
||||
```
|
||||
```
|
||||
Name: job-wq-1
|
||||
Namespace: default
|
||||
Selector: controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f
|
||||
|
||||
@@ -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:
|
||||
|
||||
@@ -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
|
||||
```
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user