Merge branch 'master' into release-1.9

2017-11-27 12:44:07 -06:00
parent f581e9c79b 40e80baede
commit 7dec42eba6
50 changed files with 483 additions and 255 deletions
@@ -38,7 +38,7 @@ Alternatively, you can use an existing 3rd party solution, such as [apiserver-bu
 1. Create a Kubernetes service account in your namespace.
 1. Create a Kubernetes cluster role for the operations you want to allow on your resources.
 1. Create a Kubernetes cluster role binding from the default service account in your namespace to the cluster role you just created.
-1. Create a Kubernetes apiservice. The CA cert above should be base 64 encoded, stripped of new lines and used as the spec.caBundle in the apiservce.  This should not be namespaced.
+1. Create a Kubernetes apiservice. The CA cert above should be base 64 encoded, stripped of new lines and used as the spec.caBundle in the apiservice.  This should not be namespaced.
 1. Use kubectl to get your resource. It should return "No resources found." Which means that everything worked but you currently have no objects of that resource type created yet.

 {% endcapture %}
@@ -17,7 +17,7 @@ can develop their features independantly from the core Kubernetes release cycles

 Before going into how to build your own cloud controller manager, some background on how it works under the hood is helpful. The cloud controller manager is code from `kube-controller-manager` utilizing Go interfaces to allow implementations from any cloud to be plugged in. Most of the scaffolding and generic controller implementations will be in core, but it will always exec out to the cloud interfaces it is provided, so long as the [cloud provider interface](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go#L29-L50) is satisifed.

-To dive a little deeper into implementation details, all cloud controller managers will import packages from Kubernetes core, the only difference being each project will register their own cloud providers by calling [cloudprovider.RegisterCloudProvier](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/plugins.go#L42-L52) where a global variable of available cloud providers is updated.
+To dive a little deeper into implementation details, all cloud controller managers will import packages from Kubernetes core, the only difference being each project will register their own cloud providers by calling [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/plugins.go#L42-L52) where a global variable of available cloud providers is updated.

 ## Developing

@@ -67,7 +67,7 @@ status:
    services.nodeports: "0"
 ```

-## Create a PersistentVolumeClaim:
+## Create a PersistentVolumeClaim

 Here is the configuration file for a PersistentVolumeClaim object:

@@ -92,7 +92,7 @@ NAME             STATUS
 pvc-quota-demo   Pending
 ```

-## Attempt to create a second PersistentVolumeClaim:
+## Attempt to create a second PersistentVolumeClaim

 Here is the configuration file for a second PersistentVolumeClaim:

@@ -36,7 +36,9 @@ The data source corresponds to a key-value pair in the ConfigMap, where
 * key = the file name or the key you provided on the command line, and
 * value = the file contents or the literal value you provided on the command line.

-You can use [`kubectl describe`](/docs/user-guide/kubectl/{{page.version}}/#describe) or [`kubectl get`](/docs/user-guide/kubectl/{{page.version}}/#get) to retrieve information about a ConfigMap. The former shows a summary of the ConfigMap, while the latter returns the full contents of the ConfigMap.
+You can use [`kubectl describe`](/docs/user-guide/kubectl/{{page.version}}/#describe) or
+[`kubectl get`](/docs/user-guide/kubectl/{{page.version}}/#get) to retrieve information
+about a ConfigMap.

 ### Create ConfigMaps from directories

@@ -16,33 +16,12 @@ your pods. But there are a number of ways to get even more information about you

 For this example we'll use a Deployment to create two pods, similar to the earlier example.

-```yaml
-apiVersion: extensions/v1beta1
-kind: Deployment
-metadata:
-  name: nginx-deployment
-spec:
-  replicas: 2
-  template:
-    metadata:
-      labels:
-        app: nginx
-    spec:
-      containers:
-      - name: nginx
-        image: nginx
-        resources:
-          limits:
-            memory: "128Mi"
-            cpu: "500m"
-        ports:
-        - containerPort: 80
-```
+{% include code.html language="yaml" file="nginx-dep.yaml" ghlink="/docs/tasks/debug-application-cluster/nginx-dep.yaml" %}

-Copy this to a file *./my-nginx-dep.yaml*
+Create deployment by running following command:

 ```shell
-$ kubectl create -f ./my-nginx-dep.yaml
+$ kubectl create -f https://k8s.io/docs/tasks/debug-application-cluster/nginx-dep.yaml
 deployment "nginx-deployment" created
 ```

@@ -0,0 +1,20 @@
+apiVersion: extensions/v1beta1
+kind: Deployment
+metadata:
+  name: nginx-deployment
+spec:
+  replicas: 2
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx
+        resources:
+          limits:
+            memory: "128Mi"
+            cpu: "500m"
+        ports:
+        - containerPort: 80
@@ -371,44 +371,35 @@ For more information see

 ## Adding a cluster to a federation

-Once you've deployed a federation control plane, you'll need to make
-that control plane aware of the clusters it should manage. You can add
-a cluster to your federation by using the [`kubefed join`](/docs/admin/kubefed_join/)
-command. A new context will have been added to your kubeconfig named `fellowship`
-(after the name of your federation). To join clusters into the federation, you will
-need to change the context.
+After you've deployed a federation control plane, you'll need to make that control plane aware of the clusters it should manage. 

-```
-kubectl config use-context fellowship
-```
+To join clusters into the federation:

-To use `kubefed join`, you'll need to provide the name of the cluster
-you want to add to the federation, and the `--host-cluster-context`
-for the federation control plane's host cluster.
+1. Change the context:

-> Note: The name that you provide to the `join` command is used as the
-joining cluster's identity in federation. This name should adhere to
-the rules described in the
-[identifiers doc](/docs/concepts/overview/working-with-objects/names/). If the context
-corresponding to your joining cluster conforms to these rules then you
-can use the same name in the join command. Otherwise, you will have to
-choose a different name for your cluster's identity. For more
-information, please see the
-[naming rules and customization](#naming-rules-and-customization)
-section below.
+       kubectl config use-context fellowship

-The following example command adds the cluster `gondor` to the
-federation running on host cluster `rivendell`:
+1. If you are using a managed cluster service, allow the service to access the cluster. To do this, create a `clusterrolebinding` for the account associated with your cluster service:

-```
-kubefed join gondor --host-cluster-context=rivendell
-```
+       kubectl create clusterrolebinding <your_user>-cluster-admin-binding --clusterrole=cluster-admin --user=<your_user>@example.org --context=<joining_cluster_context
+
+1. Join the cluster to the federation, using `kubefed join`, and make sure you provide the following:
+
+    * The name of the cluster that you are joining to the federation
+    * `--host-cluster-context`, the kubeconfig context for the host cluster
+
+    For example, this command adds the cluster `gondor` to the federation running on host cluster `rivendell`:
+
+    ```
+    kubefed join gondor --host-cluster-context=rivendell
+    ```
+
+A new context has now been added to your kubeconfig named `fellowship` (after the name of your federation). 
+
+
+> Note: The name that you provide to the `join` command is used as the joining cluster's identity in federation. If this name adheres to the rules described in the [identifiers doc](/docs/concepts/overview/working-with-objects/names/). If the context
+corresponding to your joining cluster conforms to these rules then you can use the same name in the join command. Otherwise, you will have to choose a different name for your cluster's identity.

-> Note: Kubernetes requires that you manually join clusters to a
-federation because the federation control plane manages only those
-clusters that it is responsible for managing. Adding a cluster tells
-the federation control plane that it is responsible for managing that
-cluster.

 ### Naming rules and customization

@@ -37,7 +37,7 @@ username and password:

 1. Create the Secret

-       kubectl create -f secret.yaml
+       kubectl create -f https://k8s.io/docs/tasks/inject-data-application/secret.yaml

    **Note:** If you want to skip the Base64 encoding step, you can create a Secret
    by using the `kubectl create secret` command:
@@ -81,7 +81,7 @@ Here is a configuration file you can use to create a Pod:

 1. Create the Pod:

-       kubectl create -f secret-pod.yaml
+       kubectl create -f https://k8s.io/docs/tasks/inject-data-application/secret-pod.yaml

 1. Verify that your Pod is running:

@@ -128,7 +128,7 @@ Here is a configuration file you can use to create a Pod:

 1. Create the Pod:

-       kubectl create -f secret-envars-pod.yaml
+       kubectl create -f https://k8s.io/docs/tasks/inject-data-application/secret-envars-pod.yaml

 1. Verify that your Pod is running:

@@ -10,7 +10,7 @@ metadata:
 spec:
  containers:
    - name: website
-      image: ecorp/website
+      image: nginx
      volumeMounts:
        - mountPath: /cache
          name: cache-volume
@@ -2,7 +2,6 @@ apiVersion: settings.k8s.io/v1alpha1
 kind: PodPreset
 metadata:
  name: allow-database
-  namespace: myns
 spec:
  selector:
    matchLabels:
@@ -8,7 +8,7 @@ metadata:
 spec:
  containers:
    - name: website
-      image: ecorp/website
+      image: nginx
      volumeMounts:
        - mountPath: /cache
          name: cache-volume
@@ -2,7 +2,6 @@ apiVersion: settings.k8s.io/v1alpha1
 kind: PodPreset
 metadata:
  name: allow-database
-  namespace: myns
 spec:
  selector:
    matchLabels:
@@ -10,7 +10,7 @@ metadata:
 spec:
  containers:
    - name: website
-      image: ecorp/website
+      image: nginx
      volumeMounts:
        - mountPath: /cache
          name: cache-volume
@@ -11,7 +11,7 @@ metadata:
 spec:
  containers:
    - name: website
-      image: ecorp/website
+      image: nginx
      volumeMounts:
        - mountPath: /cache
          name: cache-volume
@@ -8,7 +8,7 @@ metadata:
 spec:
  containers:
    - name: website
-      image: ecorp/website
+      image: nginx
      ports:
        - containerPort: 80

@@ -2,7 +2,6 @@ apiVersion: settings.k8s.io/v1alpha1
 kind: PodPreset
 metadata:
  name: allow-database
-  namespace: myns
 spec:
  selector:
    matchLabels:
@@ -2,7 +2,6 @@ apiVersion: settings.k8s.io/v1alpha1
 kind: PodPreset
 metadata:
  name: proxy
-  namespace: myns
 spec:
  selector:
    matchLabels:
@@ -20,18 +20,50 @@ You can get an overview of PodPresets at
 This is a simple example to show how a Pod spec is modified by the Pod
 Preset.

-**User submitted pod spec:**
+{% include code.html language="yaml" file="podpreset-preset.yaml" ghlink="/docs/tasks/inject-data-application/podpreset-preset.yaml" %}
+
+Create the PodPreset:
+
+```shell
+kubectl create -f https://k8s.io/docs/tasks/inject-data-application/podpreset-preset.yaml
+```
+
+Examine the created PodPreset:
+
+```shell
+$ kubectl get podpreset
+NAME             AGE
+allow-database   1m
+```
+
+The new PodPreset will act upon any pod that has label `role: frontend`.

 {% include code.html language="yaml" file="podpreset-pod.yaml" ghlink="/docs/tasks/inject-data-application/podpreset-pod.yaml" %}

-**Example Pod Preset:**
+Create a pod:

-{% include code.html language="yaml" file="podpreset-preset.yaml" ghlink="/docs/tasks/inject-data-application/podpreset-preset.yaml" %}
+```shell
+$ kubectl create -f https://k8s.io/docs/tasks/inject-data-application/podpreset-pod.yaml
+```
+
+List the running Pods:
+
+```shell
+$ kubectl get pods
+NAME      READY     STATUS    RESTARTS   AGE
+website   1/1       Running   0          4m
+```

 **Pod spec after admission controller:**

 {% include code.html language="yaml" file="podpreset-merged.yaml" ghlink="/docs/tasks/inject-data-application/podpreset-merged.yaml" %}

+To see above output, run the following command:
+
+```shell
+$ kubectl get pod website -o yaml
+```
+
 ### Pod Spec with `ConfigMap` Example

 This is an example to show how a Pod spec is modified by the Pod Preset
@@ -113,7 +145,7 @@ when there is a conflict.

 **If we run `kubectl describe...` we can see the event:**

-```
+```shell
 $ kubectl describe ...
 ....
 Events: