Merge pull request #11350 from thockin/munge-check-kubectl-dash-f
Add munger to verify kubectl -f targets
This commit is contained in:
@@ -93,7 +93,7 @@ $ cat <<EOF > quota.json
|
||||
}
|
||||
}
|
||||
EOF
|
||||
$ kubectl create -f quota.json
|
||||
$ kubectl create -f ./quota.json
|
||||
$ kubectl get quota
|
||||
NAME
|
||||
quota
|
||||
|
@@ -94,7 +94,7 @@ secret.json:
|
||||
"type": "kubernetes.io/service-account-token"
|
||||
}
|
||||
|
||||
$ kubectl create -f secret.json
|
||||
$ kubectl create -f ./secret.json
|
||||
$ kubectl describe secret mysecretname
|
||||
```
|
||||
|
||||
|
@@ -56,7 +56,7 @@ spec:
|
||||
Note that we omit the labels and the selector fields of the replication controller, because they will be populated from the labels field of the pod template by default.
|
||||
|
||||
```
|
||||
kubectl create -f controller.yaml
|
||||
kubectl create -f ./controller.yaml
|
||||
```
|
||||
|
||||
This will spin up 24 instances of the test. They will run to completion, then exit, and the kubelet will restart them, accumulating more and more runs of the test.
|
||||
|
@@ -194,7 +194,7 @@ Create a pod manifest: `pod.json`
|
||||
### Create the pod using the kubectl command line tool
|
||||
|
||||
```bash
|
||||
kubectl create -f pod.json
|
||||
kubectl create -f ./pod.json
|
||||
```
|
||||
|
||||
### Testing
|
||||
|
@@ -97,12 +97,12 @@ kube-02 environment=production Ready
|
||||
Let's follow the Guestbook example now:
|
||||
```
|
||||
cd guestbook-example
|
||||
kubectl create -f redis-master-controller.json
|
||||
kubectl create -f redis-master-service.json
|
||||
kubectl create -f redis-slave-controller.json
|
||||
kubectl create -f redis-slave-service.json
|
||||
kubectl create -f frontend-controller.json
|
||||
kubectl create -f frontend-service.json
|
||||
kubectl create -f examples/guestbook/redis-master-controller.yaml
|
||||
kubectl create -f examples/guestbook/redis-master-service.yaml
|
||||
kubectl create -f examples/guestbook/redis-slave-controller.yaml
|
||||
kubectl create -f examples/guestbook/redis-slave-service.yaml
|
||||
kubectl create -f examples/guestbook/frontend-controller.yaml
|
||||
kubectl create -f examples/guestbook/frontend-service.yaml
|
||||
```
|
||||
|
||||
You need to wait for the pods to get deployed, run the following and wait for `STATUS` to change from `Unknown`, through `Pending` to `Running`.
|
||||
|
@@ -146,7 +146,7 @@ done
|
||||
Now create a node object internally in your kubernetes cluster by running:
|
||||
|
||||
```
|
||||
$ kubectl create -f node.json
|
||||
$ kubectl create -f ./node.json
|
||||
|
||||
$ kubectl get nodes
|
||||
NAME LABELS STATUS
|
||||
@@ -205,7 +205,7 @@ fed-node name=fed-node-label Ready
|
||||
To delete _fed-node_ from your kubernetes cluster, one should run the following on fed-master (Please do not do it, it is just for information):
|
||||
|
||||
```
|
||||
$ kubectl delete -f node.json
|
||||
$ kubectl delete -f ./node.json
|
||||
```
|
||||
|
||||
*You should be finished!*
|
||||
|
@@ -63,7 +63,7 @@ This pod specification has one container which runs a bash script when the conta
|
||||
namespace.
|
||||
|
||||
```
|
||||
$ kubectl create -f counter-pod.yaml
|
||||
$ kubectl create -f examples/blog-logging/counter-pod.yaml
|
||||
pods/counter
|
||||
```
|
||||
|
||||
@@ -114,7 +114,7 @@ pods/counter
|
||||
Now let’s restart the counter.
|
||||
|
||||
```
|
||||
$ kubectl create -f counter-pod.yaml
|
||||
$ kubectl create -f examples/blog-logging/counter-pod.yaml
|
||||
pods/counter
|
||||
```
|
||||
Let’s wait for the container to restart and get the log lines again.
|
||||
|
@@ -204,7 +204,7 @@ EOPOD
|
||||
Send the pod description to Kubernetes using the `kubectl` CLI:
|
||||
|
||||
```bash
|
||||
$ kubectl create -f nginx.yaml
|
||||
$ kubectl create -f ./nginx.yaml
|
||||
pods/nginx
|
||||
```
|
||||
|
||||
@@ -262,8 +262,8 @@ sed -e "s/{{ pillar\['dns_server'\] }}/10.10.10.10/g" \
|
||||
Now the kube-dns pod and service are ready to be launched:
|
||||
|
||||
```bash
|
||||
kubectl create -f skydns-rc.yaml
|
||||
kubectl create -f skydns-svc.yaml
|
||||
kubectl create -f ./skydns-rc.yaml
|
||||
kubectl create -f ./skydns-svc.yaml
|
||||
```
|
||||
|
||||
Check with `kubectl get pods --namespace=kube-system` that 3/3 containers of the pods are eventually up and running. Note that the kube-dns pods run in the `kube-system` namespace, not in `default`.
|
||||
@@ -292,7 +292,7 @@ EOF
|
||||
Then start the pod:
|
||||
|
||||
```bash
|
||||
kubectl create -f busybox.yaml
|
||||
kubectl create -f ./busybox.yaml
|
||||
```
|
||||
|
||||
When the pod is up and running, start a lookup for the Kubernetes master service, made available on 10.10.10.1 by default:
|
||||
|
@@ -133,7 +133,7 @@ JSON and YAML formats are accepted.
|
||||
|
||||
.nf
|
||||
// Create a pod using the data in pod.json.
|
||||
$ kubectl create \-f pod.json
|
||||
$ kubectl create \-f ./pod.json
|
||||
|
||||
// Create a pod based on the JSON passed into stdin.
|
||||
$ cat pod.json | kubectl create \-f \-
|
||||
|
@@ -166,7 +166,7 @@ will be lost along with the rest of the resource.
|
||||
|
||||
.nf
|
||||
// Delete a pod using the type and name specified in pod.json.
|
||||
$ kubectl delete \-f pod.json
|
||||
$ kubectl delete \-f ./pod.json
|
||||
|
||||
// Delete a pod based on the type and name in the JSON passed into stdin.
|
||||
$ cat pod.json | kubectl delete \-f \-
|
||||
|
@@ -149,13 +149,13 @@ JSON and YAML formats are accepted.
|
||||
|
||||
.nf
|
||||
// Replace a pod using the data in pod.json.
|
||||
$ kubectl replace \-f pod.json
|
||||
$ kubectl replace \-f ./pod.json
|
||||
|
||||
// Replace a pod based on the JSON passed into stdin.
|
||||
$ cat pod.json | kubectl replace \-f \-
|
||||
|
||||
// Force replace, delete and then re\-create the resource
|
||||
kubectl replace \-\-force \-f pod.json
|
||||
kubectl replace \-\-force \-f ./pod.json
|
||||
|
||||
.fi
|
||||
.RE
|
||||
|
@@ -71,7 +71,7 @@ The [`command`](containers.md#containers-and-commands) overrides the Docker cont
|
||||
|
||||
This pod can be created using the `create` command:
|
||||
```bash
|
||||
$ kubectl create -f hello-world.yaml
|
||||
$ kubectl create -f ./hello-world.yaml
|
||||
pods/hello-world
|
||||
```
|
||||
`kubectl` prints the resource type and name of the resource created when successful.
|
||||
@@ -80,7 +80,7 @@ pods/hello-world
|
||||
|
||||
If you’re not sure you specified the resource correctly, you can ask `kubectl` to validate it for you:
|
||||
```bash
|
||||
$ kubectl create -f hello-world.yaml --validate
|
||||
$ kubectl create -f ./hello-world.yaml --validate
|
||||
```
|
||||
|
||||
Let’s say you specified `entrypoint` instead of `command`. You’d see output as follows:
|
||||
|
@@ -72,7 +72,7 @@ spec:
|
||||
|
||||
This makes it accessible from any node in your cluster. Check the nodes the pod is running on:
|
||||
```shell
|
||||
$ kubectl create -f nginxrc.yaml
|
||||
$ kubectl create -f ./nginxrc.yaml
|
||||
$ kubectl get pods -l app=nginx -o wide
|
||||
my-nginx-6isf4 1/1 Running 0 2h e2e-test-beeps-minion-93ly
|
||||
my-nginx-t26zt 1/1 Running 0 2h e2e-test-beeps-minion-93ly
|
||||
@@ -191,7 +191,7 @@ spec:
|
||||
```
|
||||
And perform a lookup of the nginx Service
|
||||
```shell
|
||||
$ kubectl create -f curlpod.yaml
|
||||
$ kubectl create -f ./curlpod.yaml
|
||||
default/curlpod
|
||||
$ kubectl get pods curlpod
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
@@ -275,7 +275,7 @@ Noteworthy points about the nginx-app manifest:
|
||||
- Each container has access to the keys through a volume mounted at /etc/nginx/ssl. This is setup *before* the nginx server is started.
|
||||
|
||||
```shell
|
||||
$ kubectl delete rc,svc -l app=nginx; kubectl create -f nginx-app.yaml
|
||||
$ kubectl delete rc,svc -l app=nginx; kubectl create -f ./nginx-app.yaml
|
||||
replicationcontrollers/my-nginx
|
||||
services/nginxsvc
|
||||
services/nginxsvc
|
||||
@@ -323,7 +323,7 @@ spec:
|
||||
- mountPath: /etc/nginx/ssl
|
||||
name: secret-volume
|
||||
|
||||
$ kubectl create -f curlpod.yaml
|
||||
$ kubectl create -f ./curlpod.yaml
|
||||
$ kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
curlpod 1/1 Running 0 2m
|
||||
@@ -375,7 +375,7 @@ $ curl https://104.197.63.17:30645 -k
|
||||
Lets now recreate the Service to use a cloud load balancer, just change the `Type` of Service in the nginx-app.yaml from `NodePort` to `LoadBalancer`:
|
||||
```shell
|
||||
$ kubectl delete rc, svc -l app=nginx
|
||||
$ kubectl create -f nginx-app.yaml
|
||||
$ kubectl create -f ./nginx-app.yaml
|
||||
$ kubectl get svc -o json | grep -i ingress -A 5
|
||||
"ingress": [
|
||||
{
|
||||
|
@@ -64,7 +64,7 @@ Some differences compared to specifying just a pod are that the `kind` is `Repli
|
||||
|
||||
This replication controller can be created using `create`, just as with pods:
|
||||
```bash
|
||||
$ kubectl create -f nginx-rc.yaml
|
||||
$ kubectl create -f ./nginx-rc.yaml
|
||||
replicationcontrollers/my-nginx
|
||||
```
|
||||
|
||||
|
@@ -53,7 +53,7 @@ We can use these environment variables in applications to find the service.
|
||||
It is convenient to use `kubectl exec` to check if the volumes are mounted as expected.
|
||||
We first create a Pod with a volume mounted at /data/redis,
|
||||
```
|
||||
kubectl create -f docs/user-guide/walkthrough/pod2.yaml
|
||||
kubectl create -f docs/user-guide/walkthrough/pod-redis.yaml
|
||||
```
|
||||
wait until the pod is Running and Ready,
|
||||
```
|
||||
|
@@ -104,7 +104,7 @@ example, run these on your desktop/laptop:
|
||||
|
||||
Verify by creating a pod that uses a private image, e.g.:
|
||||
```
|
||||
$ cat <<EOF > private-image-test-1.yaml
|
||||
$ cat <<EOF > /tmp/private-image-test-1.yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
@@ -116,7 +116,7 @@ spec:
|
||||
command: [ "echo", "SUCCESS" ]
|
||||
imagePullPolicy: Always
|
||||
EOF
|
||||
$ kubectl create -f private-image-test-1.yaml
|
||||
$ kubectl create -f /tmp/private-image-test-1.yaml
|
||||
pods/private-image-test-1
|
||||
$
|
||||
```
|
||||
@@ -186,7 +186,7 @@ $ echo $(cat ~/.dockercfg)
|
||||
$ cat ~/.dockercfg | base64
|
||||
eyAiaHR0cHM6Ly9pbmRleC5kb2NrZXIuaW8vdjEvIjogeyAiYXV0aCI6ICJabUZyWlhCaGMzTjNiM0prTVRJSyIsICJlbWFpbCI6ICJqZG9lQGV4YW1wbGUuY29tIiB9IH0K
|
||||
|
||||
$ cat > image-pull-secret.yaml <<EOF
|
||||
$ cat > /tmp/image-pull-secret.yaml <<EOF
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
@@ -196,7 +196,7 @@ data:
|
||||
type: kubernetes.io/dockercfg
|
||||
EOF
|
||||
|
||||
$ kubectl create -f image-pull-secret.yaml
|
||||
$ kubectl create -f /tmp/image-pull-secret.yaml
|
||||
secrets/myregistrykey
|
||||
$
|
||||
```
|
||||
|
@@ -64,7 +64,7 @@ spec:
|
||||
```
|
||||
|
||||
```bash
|
||||
$ kubectl create -f <file with contents listed above>
|
||||
$ kubectl create -f ./my-nginx-rc.yaml
|
||||
replicationcontrollers/my-nginx
|
||||
```
|
||||
|
||||
|
@@ -39,7 +39,7 @@ kubectl create -f FILENAME
|
||||
|
||||
```
|
||||
// Create a pod using the data in pod.json.
|
||||
$ kubectl create -f pod.json
|
||||
$ kubectl create -f ./pod.json
|
||||
|
||||
// Create a pod based on the JSON passed into stdin.
|
||||
$ cat pod.json | kubectl create -f -
|
||||
@@ -84,7 +84,7 @@ $ cat pod.json | kubectl create -f -
|
||||
### SEE ALSO
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.955765309 +0000 UTC
|
||||
###### Auto generated by spf13/cobra at 2015-07-16 22:39:16.132575015 +0000 UTC
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
|
@@ -46,7 +46,7 @@ kubectl delete ([-f FILENAME] | (RESOURCE [(NAME | -l label | --all)]
|
||||
|
||||
```
|
||||
// Delete a pod using the type and name specified in pod.json.
|
||||
$ kubectl delete -f pod.json
|
||||
$ kubectl delete -f ./pod.json
|
||||
|
||||
// Delete a pod based on the type and name in the JSON passed into stdin.
|
||||
$ cat pod.json | kubectl delete -f -
|
||||
@@ -106,7 +106,7 @@ $ kubectl delete pods --all
|
||||
### SEE ALSO
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.95616314 +0000 UTC
|
||||
###### Auto generated by spf13/cobra at 2015-07-16 05:13:00.190175769 +0000 UTC
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
|
@@ -39,13 +39,13 @@ kubectl replace -f FILENAME
|
||||
|
||||
```
|
||||
// Replace a pod using the data in pod.json.
|
||||
$ kubectl replace -f pod.json
|
||||
$ kubectl replace -f ./pod.json
|
||||
|
||||
// Replace a pod based on the JSON passed into stdin.
|
||||
$ cat pod.json | kubectl replace -f -
|
||||
|
||||
// Force replace, delete and then re-create the resource
|
||||
kubectl replace --force -f pod.json
|
||||
kubectl replace --force -f ./pod.json
|
||||
```
|
||||
|
||||
### Options
|
||||
@@ -91,7 +91,7 @@ kubectl replace --force -f pod.json
|
||||
### SEE ALSO
|
||||
* [kubectl](kubectl.md) - kubectl controls the Kubernetes cluster manager
|
||||
|
||||
###### Auto generated by spf13/cobra at 2015-07-14 00:11:42.955895303 +0000 UTC
|
||||
###### Auto generated by spf13/cobra at 2015-07-16 22:39:16.132838722 +0000 UTC
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
|
@@ -62,7 +62,7 @@ This example will work in a custom namespace to demonstrate the concepts involve
|
||||
Let's create a new namespace called limit-example:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f namespace.yaml
|
||||
$ kubectl create -f docs/user-guide/limitrange/namespace.yaml
|
||||
namespaces/limit-example
|
||||
$ kubectl get namespaces
|
||||
NAME LABELS STATUS
|
||||
@@ -75,7 +75,7 @@ Step 2: Apply a limit to the namespace
|
||||
Let's create a simple limit in our namespace.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f limits.yaml --namespace=limit-example
|
||||
$ kubectl create -f docs/user-guide/limitrange/limits.yaml --namespace=limit-example
|
||||
limitranges/mylimits
|
||||
```
|
||||
|
||||
@@ -140,14 +140,14 @@ Note that our nginx container has picked up the namespace default cpu and memory
|
||||
Let's create a pod that exceeds our allowed limits by having it have a container that requests 3 cpu cores.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f invalid-pod.yaml --namespace=limit-example
|
||||
$ kubectl create -f docs/user-guide/limitrange/invalid-pod.yaml --namespace=limit-example
|
||||
Error from server: Pod "invalid-pod" is forbidden: Maximum CPU usage per pod is 2, but requested 3
|
||||
```
|
||||
|
||||
Let's create a pod that falls within the allowed limit boundaries.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f valid-pod.yaml --namespace=limit-example
|
||||
$ kubectl create -f docs/user-guide/limitrange/valid-pod.yaml --namespace=limit-example
|
||||
pods/valid-pod
|
||||
$ kubectl get pods valid-pod --namespace=limit-example -o yaml | grep -C 5 resources
|
||||
containers:
|
||||
|
@@ -58,8 +58,8 @@ This [guide](../walkthrough/k8s201.md#health-checking) has more information on h
|
||||
## Get your hands dirty
|
||||
To show the health check is actually working, first create the pods:
|
||||
```
|
||||
# kubectl create -f exec-liveness.yaml
|
||||
# kubectl create -f http-liveness.yaml
|
||||
# kubectl create -f docs/user-guide/liveness/exec-liveness.yaml
|
||||
# kubectl create -f docs/user-guide/liveness/http-liveness.yaml
|
||||
```
|
||||
|
||||
Check the status of the pods once they are created:
|
||||
|
@@ -43,7 +43,7 @@ output every second [counter-pod.yaml](../../examples/blog-logging/counter-pod.y
|
||||
```
|
||||
we can run the pod:
|
||||
```
|
||||
$ kubectl create -f counter-pod.yaml
|
||||
$ kubectl create -f ./counter-pod.yaml
|
||||
pods/counter
|
||||
```
|
||||
and then fetch the logs:
|
||||
|
@@ -78,7 +78,7 @@ spec:
|
||||
|
||||
Multiple resources can be created the same way as a single resource:
|
||||
```bash
|
||||
$ kubectl create -f nginx-app.yaml
|
||||
$ kubectl create -f ./nginx-app.yaml
|
||||
services/my-nginx-svc
|
||||
replicationcontrollers/my-nginx
|
||||
```
|
||||
@@ -87,12 +87,12 @@ The resources will be created in the order they appear in the file. Therefore, i
|
||||
|
||||
`kubectl create` also accepts multiple `-f` arguments:
|
||||
```bash
|
||||
$ kubectl create -f nginx-svc.yaml -f nginx-rc.yaml
|
||||
$ kubectl create -f ./nginx-svc.yaml -f ./nginx-rc.yaml
|
||||
```
|
||||
|
||||
And a directory can be specified rather than or in addition to individual files:
|
||||
```bash
|
||||
$ kubectl create -f nginx/
|
||||
$ kubectl create -f ./nginx/
|
||||
```
|
||||
`kubectl` will read any files with suffixes `.yaml`, `.yml`, or `.json`.
|
||||
|
||||
@@ -107,7 +107,7 @@ replicationcontrollers/nginx
|
||||
|
||||
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:
|
||||
```bash
|
||||
$ kubectl delete -f nginx/
|
||||
$ kubectl delete -f ./nginx/
|
||||
replicationcontrollers/my-nginx
|
||||
services/my-nginx-svc
|
||||
```
|
||||
@@ -126,7 +126,7 @@ services/my-nginx-svc
|
||||
|
||||
Because `kubectl` outputs resource names in the same syntax it accepts, it’s easy to chain operations using `$()` or `xargs`:
|
||||
```bash
|
||||
$ kubectl get $(kubectl create -f nginx/ | grep my-nginx)
|
||||
$ kubectl get $(kubectl create -f ./nginx/ | grep my-nginx)
|
||||
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS
|
||||
my-nginx nginx nginx app=nginx 2
|
||||
NAME LABELS SELECTOR IP(S) PORT(S)
|
||||
@@ -158,7 +158,7 @@ and
|
||||
```
|
||||
The labels allow us to slice and dice our resources along any dimension specified by a label:
|
||||
```bash
|
||||
$ kubectl create -f guestbook-fe.yaml -f redis-master.yaml -f redis-slave.yaml
|
||||
$ kubectl create -f ./guestbook-fe.yaml -f ./redis-master.yaml -f ./redis-slave.yaml
|
||||
replicationcontrollers/guestbook-fe
|
||||
replicationcontrollers/guestbook-redis-master
|
||||
replicationcontrollers/guestbook-redis-slave
|
||||
@@ -339,7 +339,7 @@ spec:
|
||||
```
|
||||
and roll it out:
|
||||
```bash
|
||||
$ kubectl rolling-update my-nginx -f nginx-rc.yaml
|
||||
$ kubectl rolling-update my-nginx -f ./nginx-rc.yaml
|
||||
Creating my-nginx-v4
|
||||
At beginning of loop: my-nginx replicas: 4, my-nginx-v4 replicas: 1
|
||||
Updating my-nginx replicas: 4, my-nginx-v4 replicas: 1
|
||||
@@ -380,10 +380,9 @@ The patch is specified using json.
|
||||
|
||||
For more significant changes, you can `get` the resource, edit it, and then `replace` the resource with the updated version:
|
||||
```bash
|
||||
$ export TMP=/tmp/nginx.yaml
|
||||
$ kubectl get rc my-nginx-v4 -o yaml > $TMP
|
||||
$ emacs $TMP
|
||||
$ kubectl replace -f $TMP
|
||||
$ kubectl get rc my-nginx-v4 -o yaml > /tmp/nginx.yaml
|
||||
$ vi /tmp/nginx.yaml
|
||||
$ kubectl replace -f /tmp/nginx.yaml
|
||||
replicationcontrollers/my-nginx-v4
|
||||
$ rm $TMP
|
||||
```
|
||||
@@ -392,7 +391,7 @@ The system ensures that you don’t clobber changes made by other users or compo
|
||||
|
||||
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:
|
||||
```bash
|
||||
$ kubectl replace -f nginx-rc.yaml --force
|
||||
$ kubectl replace -f ./nginx-rc.yaml --force
|
||||
replicationcontrollers/my-nginx-v4
|
||||
replicationcontrollers/my-nginx-v4
|
||||
```
|
||||
|
@@ -129,7 +129,7 @@ More information on the ```finalizers``` field can be found in the namespace [de
|
||||
|
||||
Then run:
|
||||
```
|
||||
kubectl create -f my-namespace.yaml
|
||||
kubectl create -f ./my-namespace.yaml
|
||||
```
|
||||
|
||||
### Setting the namespace for a request
|
||||
|
@@ -91,7 +91,7 @@ data:
|
||||
```
|
||||
As with other resources, this secret can be instantiated using `create` and can be viewed with `get`:
|
||||
```bash
|
||||
$ kubectl create -f secret.yaml
|
||||
$ kubectl create -f ./secret.yaml
|
||||
secrets/mysecret
|
||||
$ kubectl get secrets
|
||||
NAME TYPE DATA
|
||||
@@ -154,7 +154,7 @@ $ echo $(cat ~/.dockercfg)
|
||||
$ cat ~/.dockercfg | base64
|
||||
eyAiaHR0cHM6Ly9pbmRleC5kb2NrZXIuaW8vdjEvIjogeyAiYXV0aCI6ICJabUZyWlhCaGMzTjNiM0prTVRJSyIsICJlbWFpbCI6ICJqZG9lQGV4YW1wbGUuY29tIiB9IH0K
|
||||
|
||||
$ cat > image-pull-secret.yaml <<EOF
|
||||
$ cat > /tmp/image-pull-secret.yaml <<EOF
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
@@ -164,7 +164,7 @@ data:
|
||||
type: kubernetes.io/dockercfg
|
||||
EOF
|
||||
|
||||
$ kubectl create -f image-pull-secret.yaml
|
||||
$ kubectl create -f ./image-pull-secret.yaml
|
||||
secrets/myregistrykey
|
||||
```
|
||||
|
||||
@@ -342,7 +342,7 @@ spec:
|
||||
|
||||
The message is recorded along with the other state of the last (i.e., most recent) termination:
|
||||
```bash
|
||||
$ kubectl create -f pod.yaml
|
||||
$ kubectl create -f ./pod.yaml
|
||||
pods/pod-w-message
|
||||
$ sleep 70
|
||||
$ kubectl get pods/pod-w-message -o template -t "{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}"
|
||||
|
@@ -33,7 +33,7 @@ This example will work in a custom namespace to demonstrate the concepts involve
|
||||
Let's create a new namespace called quota-example:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f namespace.yaml
|
||||
$ kubectl create -f docs/user-guide/resourcequota/namespace.yaml
|
||||
$ kubectl get namespaces
|
||||
NAME LABELS STATUS
|
||||
default <none> Active
|
||||
@@ -53,7 +53,7 @@ and API resources (pods, services, etc.) that a namespace may consume.
|
||||
Let's create a simple quota in our namespace:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f quota.yaml --namespace=quota-example
|
||||
$ kubectl create -f docs/user-guide/resourcequota/quota.yaml --namespace=quota-example
|
||||
```
|
||||
|
||||
Once your quota is applied to a namespace, the system will restrict any creation of content
|
||||
@@ -121,7 +121,7 @@ do not specify any memory usage.
|
||||
So let's set some default limits for the amount of cpu and memory a pod can consume:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f limits.yaml --namespace=quota-example
|
||||
$ kubectl create -f docs/user-guide/resourcequota/limits.yaml --namespace=quota-example
|
||||
limitranges/limits
|
||||
$ kubectl describe limits limits --namespace=quota-example
|
||||
Name: limits
|
||||
|
@@ -62,13 +62,13 @@ default 1
|
||||
|
||||
You can create additional serviceAccounts like this:
|
||||
```
|
||||
$ cat > serviceaccount.yaml <<EOF
|
||||
$ cat > /tmp/serviceaccount.yaml <<EOF
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: build-robot
|
||||
EOF
|
||||
$ kubectl create -f serviceaccount.json
|
||||
$ kubectl create -f /tmp/serviceaccount.json
|
||||
serviceacccounts/build-robot
|
||||
```
|
||||
|
||||
|
@@ -31,7 +31,7 @@ can be code reviewed, producing a more robust, reliable and archival system.
|
||||
|
||||
```bash
|
||||
cd kubernetes
|
||||
kubectl create -f pod.yaml
|
||||
kubectl create -f ./pod.yaml
|
||||
```
|
||||
|
||||
Where pod.yaml contains something like:
|
||||
@@ -70,7 +70,7 @@ cluster.
|
||||
|
||||
```bash
|
||||
cd kubernetes
|
||||
kubectl create -f replication.yaml
|
||||
kubectl create -f ./replication.yaml
|
||||
```
|
||||
|
||||
Where ```replication.yaml``` contains:
|
||||
|
@@ -34,7 +34,7 @@ When you create a resource such as pod, and then retrieve the created
|
||||
resource, a number of the fields of the resource are added.
|
||||
You can see this at work in the following example:
|
||||
```
|
||||
$ cat > original.yaml <<EOF
|
||||
$ cat > /tmp/original.yaml <<EOF
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
@@ -45,17 +45,17 @@ spec:
|
||||
image: busybox
|
||||
restartPolicy: Never
|
||||
EOF
|
||||
$ kubectl create -f original.yaml
|
||||
$ kubectl create -f /tmp/original.yaml
|
||||
pods/original
|
||||
$ kubectl get pods/original -o yaml > current.yaml
|
||||
$ kubectl get pods/original -o yaml > /tmp/current.yaml
|
||||
pods/original
|
||||
$ wc -l original.yaml current.yaml
|
||||
51 current.yaml
|
||||
9 original.yaml
|
||||
$ wc -l /tmp/original.yaml /tmp/current.yaml
|
||||
51 /tmp/current.yaml
|
||||
9 /tmp/original.yaml
|
||||
60 total
|
||||
```
|
||||
The resource we posted had only 9 lines, but the one we got back had 51 lines.
|
||||
If you `diff original.yaml current.yaml`, you can see the fields added to the pod.
|
||||
If you `diff -u /tmp/original.yaml /tmp/current.yaml`, you can see the fields added to the pod.
|
||||
The system adds fields in several ways:
|
||||
- Some fields are added synchronously with creation of the resource and some are set asynchronously.
|
||||
- For example: `metadata.uid` is set synchronously. (Read more about [metadata](../devel/api-conventions.md#metadata)).
|
||||
|
Reference in New Issue
Block a user