github/kubernetes
4
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge pull request #11350 from thockin/munge-check-kubectl-dash-f

Browse Source 
Add munger to verify kubectl -f targets
This commit is contained in:
Brian Grant
2015-07-16 22:46:37 -07:00
parent 5978d50a3e f7512d007b
commit cb58e8e43b
47 changed files with 377 additions and 122 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/user-guide/configuring-containers.md
View File

@@ -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:

10
docs/user-guide/connecting-applications.md
View File

@@ -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": [
{

2
docs/user-guide/deploying-applications.md
View File

@@ -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
```

2
docs/user-guide/getting-into-containers.md
View File

@@ -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,
```

8
docs/user-guide/images.md
View File

@@ -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
$
```

2
docs/user-guide/introspection-and-debugging.md
View File

@@ -64,7 +64,7 @@ spec:
```
```bash
$ kubectl create -f <file with contents listed above>
$ kubectl create -f ./my-nginx-rc.yaml
replicationcontrollers/my-nginx
```

4
docs/user-guide/kubectl/kubectl_create.md
View File

@@ -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 -->

4
docs/user-guide/kubectl/kubectl_delete.md
View File

@@ -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 -->

6
docs/user-guide/kubectl/kubectl_replace.md
View File

@@ -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 -->

8
docs/user-guide/limitrange/README.md
View File

@@ -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:

4
docs/user-guide/liveness/README.md
View File

@@ -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:

2
docs/user-guide/logging.md
View File

@@ -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:

23
docs/user-guide/managing-deployments.md
View File

@@ -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
```

2
docs/user-guide/namespaces.md
View File

@@ -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

8
docs/user-guide/production-pods.md
View File

@@ -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}}"

6
docs/user-guide/resourcequota/README.md
View File

@@ -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

4
docs/user-guide/service-accounts.md
View File

@@ -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
```

4
docs/user-guide/simple-yaml.md
View File

@@ -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:

14
docs/user-guide/working-with-resources.md
View File

@@ -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)).