Consolidate YAML files [part-12] (#9364)

* Consolidate YAML files [part-12] Relocate YAML files referenced by the accessing application topic and the rest of cluster administration. * Adjust json shortcodes.
2018-07-04 14:19:23 +08:00
parent aed6732b4e
commit ea6004bd4f
29 changed files with 118 additions and 251 deletions
@@ -1,14 +0,0 @@
-apiVersion: v1
-kind: Pod
-metadata:
-  name: busybox
-  namespace: default
-spec:
-  containers:
-  - name: busybox
-    image: busybox
-    command:
-      - sleep
-      - "3600"
-    imagePullPolicy: IfNotPresent
-  restartPolicy: Always
@@ -1,69 +0,0 @@
-# This is an example of how to setup cloud-controller-manger as a Daemonset in your cluster.
-# It assumes that your masters can run pods and has the role node-role.kubernetes.io/master
-# Note that this Daemonset will not work straight out of the box for your cloud, this is
-# meant to be a guideline.
-
---
-apiVersion: v1
-kind: ServiceAccount
-metadata:
-  name: cloud-controller-manager
-  namespace: kube-system
---
-kind: ClusterRoleBinding
-apiVersion: rbac.authorization.k8s.io/v1
-metadata:
-  name: system:cloud-controller-manager
-roleRef:
-  apiGroup: rbac.authorization.k8s.io
-  kind: ClusterRole
-  name: cluster-admin
-subjects:
- kind: ServiceAccount
-  name: cloud-controller-manager
-  namespace: kube-system
---
-apiVersion: apps/v1
-kind: DaemonSet
-metadata:
-  labels:
-    k8s-app: cloud-controller-manager
-  name: cloud-controller-manager
-  namespace: kube-system
-spec:
-  selector:
-    matchLabels:
-      k8s-app: cloud-controller-manager
-  template:
-    metadata:
-      labels:
-        k8s-app: cloud-controller-manager
-    spec:
-      serviceAccountName: cloud-controller-manager
-      containers:
-      - name: cloud-controller-manager
-        # for in-tree providers we use k8s.gcr.io/cloud-controller-manager
-        # this can be replaced with any other image for out-of-tree providers
-        image: k8s.gcr.io/cloud-controller-manager:v1.8.0
-        command:
-        - /usr/local/bin/cloud-controller-manager
-        - --cloud-provider=<YOUR_CLOUD_PROVIDER>   # Add your own cloud provider here!
-        - --leader-elect=true
-        - --use-service-account-credentials
-        # these flags will vary for every cloud provider
-        - --allocate-node-cidrs=true
-        - --configure-cloud-routes=true
-        - --cluster-cidr=172.17.0.0/16
-      tolerations:
-      # this is required so CCM can bootstrap itself
-      - key: node.cloudprovider.kubernetes.io/uninitialized
-        value: "true"
-        effect: NoSchedule
-      # this is to have the daemonset runnable on master nodes
-      # the taint may vary depending on your cluster setup
-      - key: node-role.kubernetes.io/master
-        effect: NoSchedule
-      # this is to restrict CCM to only run on master nodes
-      # the node selector may vary depending on your cluster setup
-      nodeSelector:
-        node-role.kubernetes.io/master: ""
@@ -73,7 +73,7 @@ for this example. A [Deployment](/docs/concepts/workloads/controllers/deployment
 thereby making the scheduler resilient to failures. Here is the deployment
 config. Save it as `my-scheduler.yaml`:

-{{< code file="my-scheduler.yaml" >}}
+{{< codenew file="admin/sched/my-scheduler.yaml" >}}

 An important thing to note here is that the name of the scheduler specified as an
 argument to the scheduler command in the container spec should be unique. This is the name that is matched against the value of the optional `spec.schedulerName` on pods, to determine whether this scheduler is responsible for scheduling a particular pod.
@@ -149,7 +149,7 @@ scheduler in that pod spec. Let's look at three examples.

 - Pod spec without any scheduler name

-  {{< code file="pod1.yaml" >}}
+  {{< codenew file="admin/sched/pod1.yaml" >}}

  When no scheduler name is supplied, the pod is automatically scheduled using the
  default-scheduler.
@@ -162,7 +162,7 @@ kubectl create -f pod1.yaml

 - Pod spec with `default-scheduler`

-  {{< code file="pod2.yaml" >}}
+  {{< codenew file="admin/sched/pod2.yaml" >}}

  A scheduler is specified by supplying the scheduler name as a value to `spec.schedulerName`. In this case, we supply the name of the
  default scheduler which is `default-scheduler`.
@@ -175,7 +175,7 @@ kubectl create -f pod2.yaml

 - Pod spec with `my-scheduler`

-  {{< code file="pod3.yaml" >}}
+  {{< codenew file="admin/sched/pod3.yaml" >}}

  In this case, we specify that this pod should be scheduled using the scheduler that we
  deployed - `my-scheduler`. Note that the value of `spec.schedulerName` should match the name supplied to the scheduler
@@ -215,4 +215,4 @@ verify that the pods were scheduled by the desired schedulers.
 kubectl get events
 ```

-{{% /capture %}}
+{{% /capture %}}
@@ -22,12 +22,12 @@ This page provides hints on diagnosing DNS problems.

 Create a file named busybox.yaml with the following contents:

-{{< code file="busybox.yaml" >}}
+{{< codenew file="admin/dns/busybox.yaml" >}}

 Then create a pod using this file and verify its status:

 ```shell
-$ kubectl create -f busybox.yaml
+$ kubectl create -f https://k8s.io/examples/admin/dns/busybox.yaml
 pod "busybox" created

 $ kubectl get pods busybox
@@ -1,33 +0,0 @@
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: kube-dns-autoscaler
-  namespace: kube-system
-  labels:
-    k8s-app: kube-dns-autoscaler
-spec:
-  selector:
-    matchLabels:
-       k8s-app: kube-dns-autoscaler
-  template:
-    metadata:
-      labels:
-        k8s-app: kube-dns-autoscaler
-    spec:
-      containers:
-      - name: autoscaler
-        image: k8s.gcr.io/cluster-proportional-autoscaler-amd64:1.1.1
-        resources:
-            requests:
-                cpu: "20m"
-                memory: "10Mi"
-        command:
-          - /cluster-proportional-autoscaler
-          - --namespace=kube-system
-          - --configmap=kube-dns-autoscaler
-          - --target=<SCALE_TARGET>
-          # When cluster is using large nodes(with more cores), "coresPerReplica" should dominate.
-          # If using small nodes, "nodesPerReplica" should dominate.
-          - --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"min":1}}
-          - --logtostderr=true
-          - --v=2
@@ -94,7 +94,7 @@ container based on the `cluster-proportional-autoscaler-amd64` image.

 Create a file named `dns-horizontal-autoscaler.yaml` with this content:

-{{< code file="dns-horizontal-autoscaler.yaml" >}}
+{{< codenew file="admin/dns/dns-horizontal-autoscaler.yaml" >}}

 In the file, replace `<SCALE_TARGET>` with your scale target.

@@ -1,67 +0,0 @@
-apiVersion: v1
-kind: ServiceAccount
-metadata:
-  name: my-scheduler
-  namespace: kube-system
---
-kind: ClusterRoleBinding
-apiVersion: rbac.authorization.k8s.io/v1
-metadata:
-  name: my-scheduler-as-kube-scheduler
-subjects:
- kind: ServiceAccount
-  name: my-scheduler
-  namespace: kube-system
-roleRef:
-  kind: ClusterRole
-  name: kube-scheduler
-  apiGroup: rbac.authorization.k8s.io
---
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  labels:
-    component: scheduler
-    tier: control-plane
-  name: my-scheduler
-  namespace: kube-system
-spec:
-  selector:
-    matchLabels:
-      component: scheduler
-      tier: control-plane
-  replicas: 1
-  template:
-    metadata:
-      labels:
-        component: scheduler
-        tier: control-plane
-        version: second
-    spec:
-      serviceAccountName: my-scheduler
-      containers:
-      - command:
-        - /usr/local/bin/kube-scheduler
-        - --address=0.0.0.0
-        - --leader-elect=false
-        - --scheduler-name=my-scheduler
-        image: gcr.io/my-gcp-project/my-kube-scheduler:1.0
-        livenessProbe:
-          httpGet:
-            path: /healthz
-            port: 10251
-          initialDelaySeconds: 15
-        name: kube-second-scheduler
-        readinessProbe:
-          httpGet:
-            path: /healthz
-            port: 10251
-        resources:
-          requests:
-            cpu: '0.1'
-        securityContext:
-          privileged: false
-        volumeMounts: []
-      hostNetwork: false
-      hostPID: false
-      volumes: []
@@ -1,10 +0,0 @@
-{
-  "kind": "Namespace",
-  "apiVersion": "v1",
-  "metadata": {
-    "name": "development",
-    "labels": {
-      "name": "development"
-    }
-  }
-}
@@ -1,10 +0,0 @@
-{
-  "kind": "Namespace",
-  "apiVersion": "v1",
-  "metadata": {
-    "name": "production",
-    "labels": {
-      "name": "production"
-    }
-  }
-}
@@ -67,24 +67,24 @@ One pattern this organization could follow is to partition the Kubernetes cluste

 Let's create two new namespaces to hold our work.

-Use the file [`namespace-dev.json`](/docs/tasks/administer-cluster/namespace-dev.json) which describes a development namespace:
+Use the file [`namespace-dev.json`](/examples/admin/namespace-dev.json) which describes a development namespace:

-{{< code language="json" file="namespace-dev.json" >}}
+{{< codenew language="json" file="admin/namespace-dev.json" >}}

 Create the development namespace using kubectl.

 ```shell
-$ kubectl create -f https://k8s.io/docs/tasks/administer-cluster/namespace-dev.json
+$ kubectl create -f https://k8s.io/examples/admin/namespace-dev.json
 ```

-Save the following contents into file [`namespace-prod.json`](/docs/tasks/administer-cluster/namespace-prod.json) which describes a production namespace:
+Save the following contents into file [`namespace-prod.json`](/examples/admin/namespace-prod.json) which describes a production namespace:

-{{< code language="json" file="namespace-prod.json" >}}
+{{< codenew language="json" file="admin/namespace-prod.json" >}}

 And then let's create the production namespace using kubectl.

 ```shell
-$ kubectl create -f https://k8s.io/docs/tasks/administer-cluster/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.
@@ -140,20 +140,20 @@ One pattern this organization could follow is to partition the Kubernetes cluste

 Let's create two new namespaces to hold our work.

-Use the file [`namespace-dev.json`](/docs/tasks/administer-cluster/namespace-dev.json) which describes a development namespace:
+Use the file [`namespace-dev.json`](/examples/admin/namespace-dev.json) which describes a development namespace:

-{{< code language="json" file="namespace-dev.json" >}}
+{{< codenew language="json" file="admin/namespace-dev.json" >}}

 Create the development namespace using kubectl.

 ```shell
-$ kubectl create -f docs/tasks/administer-cluster/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 docs/tasks/administer-cluster/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.
@@ -1,13 +0,0 @@
-kind: InitializerConfiguration
-apiVersion: admissionregistration.k8s.io/v1alpha1
-metadata:
-  name: pvlabel.kubernetes.io
-initializers:
-  - name: pvlabel.kubernetes.io
-    rules:
-    - apiGroups:
-      - ""
-      apiVersions:
-      - "*"
-      resources:
-      - persistentvolumes
@@ -1,10 +0,0 @@
-apiVersion: v1
-kind: Pod
-metadata:
-  name: no-annotation
-  labels:
-    name: multischeduler-example
-spec:
-  containers:
-  - name: pod-with-no-annotation-container
-    image: k8s.gcr.io/pause:2.0
@@ -1,11 +0,0 @@
-apiVersion: v1
-kind: Pod
-metadata:
-  name: annotation-default-scheduler
-  labels:
-    name: multischeduler-example
-spec:
-  schedulerName: default-scheduler
-  containers:
-  - name: pod-with-default-annotation-container
-    image: k8s.gcr.io/pause:2.0
@@ -1,11 +0,0 @@
-apiVersion: v1
-kind: Pod
-metadata:
-  name: annotation-second-scheduler
-  labels:
-    name: multischeduler-example
-spec:
-  schedulerName: my-scheduler
-  containers:
-  - name: pod-with-second-annotation-container
-    image: k8s.gcr.io/pause:2.0
@@ -41,7 +41,7 @@ Successfully running cloud-controller-manager requires some changes to your clus
  since the cloud controller manager takes over labeling persistent volumes.
 * For the `cloud-controller-manager` to label persistent volumes, initializers will need to be enabled and an InitializerConifguration needs to be added to the system.  Follow [these instructions](/docs/admin/extensible-admission-controllers.md#enable-initializers-alpha-feature) to enable initializers.  Use the following YAML to create the InitializerConfiguration:

-{{< code file="persistent-volume-label-initializer-config.yaml" >}}
+{{< codenew file="admin/cloud/pvl-initializer-config.yaml" >}}

 Keep in mind that setting up your cluster to use cloud controller manager will change your cluster behaviour in a few ways:

@@ -71,7 +71,7 @@ For cloud controller managers not in Kubernetes core, you can find the respectiv

 For providers already in Kubernetes core, you can run the in-tree cloud controller manager as a Daemonset in your cluster, use the following as a guideline:

-{{< code file="cloud-controller-manager-daemonset-example.yaml" >}}
+{{< codenew file="admin/cloud/ccm-example.yaml" >}}


 ## Limitations