Consolidate YAML files [part-8] (#9347)

* Consolidate YAML files [part-8] This PR exacts the YAML files referenced from the following subdirs: - docs/concepts/workloads - docs/concepts/configuration - docs/concepts/policy The following problems are fixed: - docs/concepts/workloads/controllers/ doesnt have a 'cronjob.yaml for test - the exactly same `pod.yaml` was used in both the task/config-pod-container topic and the concepts/configuration topics. * Update examples_test.go * Add missing yaml file.
2018-07-03 08:35:20 +08:00
parent 1b914f4ac7
commit b5f6df9926
26 changed files with 58 additions and 58 deletions
@@ -39,11 +39,11 @@ different flags and/or different memory and cpu requests for different hardware

 You can describe a DaemonSet in a YAML file. For example, the `daemonset.yaml` file below describes a DaemonSet that runs the fluentd-elasticsearch Docker image:

-{{< code file="daemonset.yaml" >}}
+{{< codenew file="controllers/daemonset.yaml" >}}

 * Create a DaemonSet based on the YAML file:
 ```
-kubectl create -f daemonset.yaml
+kubectl create -f https://k8s.io/examples/controllers/daemonset.yaml
 ```

 ### Required Fields
@@ -252,4 +252,4 @@ number of replicas and rolling out updates are more important than controlling e
 the Pod runs on.  Use a DaemonSet when it is important that a copy of a Pod always run on
 all or certain hosts, and when it needs to start before other Pods.

-{{% /capture %}}
+{{% /capture %}}
@@ -1,42 +0,0 @@
-apiVersion: apps/v1
-kind: DaemonSet
-metadata:
-  name: fluentd-elasticsearch
-  namespace: kube-system
-  labels:
-    k8s-app: fluentd-logging
-spec:
-  selector:
-    matchLabels:
-      name: fluentd-elasticsearch
-  template:
-    metadata:
-      labels:
-        name: fluentd-elasticsearch
-    spec:
-      tolerations:
-      - key: node-role.kubernetes.io/master
-        effect: NoSchedule
-      containers:
-      - name: fluentd-elasticsearch
-        image: k8s.gcr.io/fluentd-elasticsearch:1.20
-        resources:
-          limits:
-            memory: 200Mi
-          requests:
-            cpu: 100m
-            memory: 200Mi
-        volumeMounts:
-        - name: varlog
-          mountPath: /var/log
-        - name: varlibdockercontainers
-          mountPath: /var/lib/docker/containers
-          readOnly: true
-      terminationGracePeriodSeconds: 30
-      volumes:
-      - name: varlog
-        hostPath:
-          path: /var/log
-      - name: varlibdockercontainers
-        hostPath:
-          path: /var/lib/docker/containers
@@ -40,7 +40,7 @@ The following are typical use cases for Deployments:

 The following is an example of a Deployment. It creates a ReplicaSet to bring up three `nginx` Pods:

-{{< code file="nginx-deployment.yaml" >}}
+{{< codenew file="controllers/nginx-deployment.yaml" >}}

 In this example:

@@ -71,7 +71,7 @@ The `template` field contains the following instructions:
 To create this Deployment, run the following command:

 ```shell
-kubectl create -f  https://raw.githubusercontent.com/kubernetes/website/master/content/en/docs/concepts/workloads/controllers/nginx-deployment.yaml
+kubectl create -f  https://k8s.io/examples/controllers/nginx-deployment.yaml
 ```

 {{< note >}}
@@ -417,7 +417,7 @@ First, check the revisions of this deployment:
 $ kubectl rollout history deployment/nginx-deployment
 deployments "nginx-deployment"
 REVISION    CHANGE-CAUSE
-1           kubectl create -f docs/user-guide/nginx-deployment.yaml --record
+1           kubectl create -f https://k8s.io/examples/controllers/nginx-deployment.yaml --record
 2           kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
 3           kubectl set image deployment/nginx-deployment nginx=nginx:1.91
 ```
@@ -1,39 +0,0 @@
-apiVersion: apps/v1
-kind: ReplicaSet
-metadata:
-  name: frontend
-  labels:
-    app: guestbook
-    tier: frontend
-spec:
-  # this replicas value is default
-  # modify it according to your case
-  replicas: 3
-  selector:
-    matchLabels:
-      tier: frontend
-    matchExpressions:
-      - {key: tier, operator: In, values: [frontend]}
-  template:
-    metadata:
-      labels:
-        app: guestbook
-        tier: frontend
-    spec:
-      containers:
-      - name: php-redis
-        image: gcr.io/google_samples/gb-frontend:v3
-        resources:
-          requests:
-            cpu: 100m
-            memory: 100Mi
-        env:
-        - name: GET_HOSTS_FROM
-          value: dns
-          # If your cluster config does not include a dns service, then to
-          # instead access environment variables to find service host
-          # info, comment out the 'value: dns' line above, and uncomment the
-          # line below.
-          # value: env
-        ports:
-        - containerPort: 80
@@ -36,17 +36,17 @@ setting the `ownerReference` field.

 Here's a configuration file for a ReplicaSet that has three Pods:

-{{< code file="my-repset.yaml" >}}
+{{< codenew file="controllers/replicaset.yaml" >}}

 If you create the ReplicaSet and then view the Pod metadata, you can see
 OwnerReferences field:

 ```shell
-kubectl create -f https://k8s.io/docs/concepts/controllers/my-repset.yaml
+kubectl create -f https://k8s.io/examples/controllers/replicaset.yaml
 kubectl get pods --output=yaml
 ```

-The output shows that the Pod owner is a ReplicaSet named my-repset:
+The output shows that the Pod owner is a ReplicaSet named `my-repset`:

 ```shell
 apiVersion: v1
@@ -110,15 +110,15 @@ field on the `deleteOptions` argument when deleting an Object. Possible values i

 Prior to Kubernetes 1.9, the default garbage collection policy for many controller resources was `orphan`.
 This included ReplicationController, ReplicaSet, StatefulSet, DaemonSet, and
-Deployment. For kinds in the extensions/v1beta1, apps/v1beta1, and apps/v1beta2 group versions, unless you 
-specify otherwise, dependent objects are orphaned by default. In Kubernetes 1.9, for all kinds in the apps/v1 
+Deployment. For kinds in the `extensions/v1beta1`, `apps/v1beta1`, and `apps/v1beta2` group versions, unless you 
+specify otherwise, dependent objects are orphaned by default. In Kubernetes 1.9, for all kinds in the `apps/v1` 
 group version, dependent objects are deleted by default.

 Here's an example that deletes dependents in background:

 ```shell
 kubectl proxy --port=8080
-curl -X DELETE localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/my-repset \
+curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
 -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
 -H "Content-Type: application/json"
 ```
@@ -127,7 +127,7 @@ Here's an example that deletes dependents in foreground:

 ```shell
 kubectl proxy --port=8080
-curl -X DELETE localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/my-repset \
+curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
 -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
 -H "Content-Type: application/json"
 ```
@@ -136,7 +136,7 @@ Here's an example that orphans dependents:

 ```shell
 kubectl proxy --port=8080
-curl -X DELETE localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/my-repset \
+curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
 -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
 -H "Content-Type: application/json"
 ```
@@ -1,11 +0,0 @@
-apiVersion: autoscaling/v1
-kind: HorizontalPodAutoscaler
-metadata:
-  name: frontend-scaler
-spec:
-  scaleTargetRef:
-    kind: ReplicaSet
-    name: frontend
-  minReplicas: 3
-  maxReplicas: 10
-  targetCPUUtilizationPercentage: 50
@@ -1,14 +0,0 @@
-apiVersion: batch/v1
-kind: Job
-metadata:
-  name: pi
-spec:
-  template:
-    spec:
-      containers:
-      - name: pi
-        image: perl
-        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
-      restartPolicy: Never
-  backoffLimit: 4
-
@@ -31,12 +31,12 @@ A Job can also be used to run multiple pods in parallel.
 Here is an example Job config.  It computes π to 2000 places and prints it out.
 It takes around 10s to complete.

-{{< code file="job.yaml" >}}
+{{< codenew file="controllers/job.yaml" >}}

 Run the example job by downloading the example file and then running this command:

 ```shell
-$ kubectl create -f ./job.yaml
+$ kubectl create -f https://k8s.io/examples/controllers/job.yaml
 job "pi" created
 ```

@@ -401,4 +401,4 @@ object, but complete control over what pods are created and how work is assigned

 Support for creating Jobs at specified times/dates (i.e. cron) is available in Kubernetes [1.4](https://github.com/kubernetes/kubernetes/pull/11980). More information is available in the [cron job documents](/docs/concepts/workloads/controllers/cron-jobs/)

-{{% /capture %}}
+{{% /capture %}}
@@ -1,17 +0,0 @@
-apiVersion: apps/v1
-kind: ReplicaSet
-metadata:
-  name: my-repset
-spec:
-  replicas: 3
-  selector:
-    matchLabels:
-      pod-is-for: garbage-collection-example
-  template:
-    metadata:
-      labels:
-        pod-is-for: garbage-collection-example
-    spec:
-      containers:
-      - name: nginx
-        image: nginx
@@ -1,21 +0,0 @@
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: nginx-deployment
-  labels:
-    app: nginx
-spec:
-  replicas: 3
-  selector:
-    matchLabels:
-      app: nginx
-  template:
-    metadata:
-      labels:
-        app: nginx
-    spec:
-      containers:
-      - name: nginx
-        image: nginx:1.7.9
-        ports:
-        - containerPort: 80
@@ -51,13 +51,13 @@ use a Deployment instead, and define your application in the spec section.

 ## Example

-{{< code file="frontend.yaml" >}}
+{{< codenew file="controllers/frontend.yaml" >}}

 Saving this manifest into `frontend.yaml` and submitting it to a Kubernetes cluster should
 create the defined ReplicaSet and the pods that it manages.

 ```shell
-$ kubectl create -f frontend.yaml
+$ kubectl create -f http://k8s.io/examples/controllers/frontend.yaml
 replicaset "frontend" created
 $ kubectl describe rs/frontend
 Name:		frontend
@@ -192,14 +192,14 @@ A ReplicaSet can also be a target for
 a ReplicaSet can be auto-scaled by an HPA. Here is an example HPA targeting
 the ReplicaSet we created in the previous example.

-{{< code file="hpa-rs.yaml" >}}
+{{< codenew file="controllers/hpa-rs.yaml" >}}

 Saving this manifest into `hpa-rs.yaml` and submitting it to a Kubernetes cluster should
 create the defined HPA that autoscales the target ReplicaSet depending on the CPU usage
 of the replicated pods.

 ```shell
-kubectl create -f hpa-rs.yaml
+kubectl create -f https://k8s.io/examples/controllers/hpa-rs.yaml
 ```

 Alternatively, you can use the `kubectl autoscale` command to accomplish the same
@@ -1,19 +0,0 @@
-apiVersion: v1
-kind: ReplicationController
-metadata:
-  name: nginx
-spec:
-  replicas: 3
-  selector:
-    app: nginx
-  template:
-    metadata:
-      name: nginx
-      labels:
-        app: nginx
-    spec:
-      containers:
-      - name: nginx
-        image: nginx
-        ports:
-        - containerPort: 80
@@ -44,12 +44,12 @@ service, such as web servers.

 This example ReplicationController config runs three copies of the nginx web server.

-{{< code file="replication.yaml" >}}
+{{< codenew file="controllers/replication.yaml" >}}

 Run the example job by downloading the example file and then running this command:

 ```shell
-$ kubectl create -f ./replication.yaml
+$ kubectl create -f https://k8s.io/examples/controllers/replication.yaml
 replicationcontroller "nginx" created
 ```