Merge branch 'master' into patch-56

2017-08-22 13:23:39 -04:00
parent edb999f227 74825e3cf7
commit 5d8dbf6b04
53 changed files with 306 additions and 182 deletions
@@ -200,7 +200,7 @@ You have several options for connecting to nodes, pods and services from outside
      or it may expose it to the internet.  Think about whether the service being exposed is secure.
      Does it do its own authentication?
    - Place pods behind services.  To access one specific pod from a set of replicas, such as for debugging,
-      place a unique label on the pod it and create a new service which selects this label.
+      place a unique label on the pod and create a new service which selects this label.
    - In most cases, it should not be necessary for application developer to directly access
      nodes via their nodeIPs.
  - Access services, nodes, or pods using the Proxy Verb.
@@ -138,7 +138,7 @@ current-context: federal-context

 `current-context` is the nickname or 'key' for the cluster,user,namespace tuple that kubectl
 will use by default when loading config from this file. You can override any of the values in kubectl
-from the commandline, by passing `--context=CONTEXT`, `--cluster=CLUSTER`, `--user=USER`, and/or `--namespace=NAMESPACE` respectively.
+from the command line, by passing `--context=CONTEXT`, `--cluster=CLUSTER`, `--user=USER`, and/or `--namespace=NAMESPACE` respectively.
 You can change the `current-context` with [`kubectl config use-context`](/docs/user-guide/kubectl/{{page.version}}/#-em-use-context-em-).

 #### miscellaneous
@@ -315,7 +315,7 @@ So, tying this all together, a quick start to create your own kubeconfig file:
 - Make sure your api-server provides at least one set of credentials (for example, `green-user`) when launched.  You will of course have to look at api-server documentation in order to determine the current state-of-the-art in terms of providing authentication details.

 ## Related discussion
-[http://issue.k8s.io/1755](http://issue.k8s.io/1755)
+[https://github.com/kubernetes/kubernetes/issues/1755](https://github.com/kubernetes/kubernetes/issues/1755)
 {% endcapture %}

 {% include templates/task.md %}
@@ -26,8 +26,8 @@ metadata:
  name: myapp
 spec:
  ports:
-    - port: 8765
-      targetPort: 9376
+  - port: 8765
+    targetPort: 9376
  selector:
    app: example
  type: LoadBalancer
@@ -44,8 +44,8 @@ metadata:
  name: myapp
 spec:
  ports:
-    - port: 8765
-      targetPort: 9376
+  - port: 8765
+    targetPort: 9376
  selector:
    app: example
  type: LoadBalancer
@@ -7,9 +7,9 @@ spec:
    app: hello
    tier: frontend
  ports:
-    - protocol: "TCP"
-      port: 80
-      targetPort: 80
+  - protocol: "TCP"
+    port: 80
+    targetPort: 80
  type: LoadBalancer
 ---
 apiVersion: apps/v1beta1
@@ -26,9 +26,9 @@ spec:
        track: stable
    spec:
      containers:
-        - name: nginx
-          image: "gcr.io/google-samples/hello-frontend:1.0"
-          lifecycle:
-            preStop:
-              exec:
-                command: ["/usr/sbin/nginx","-s","quit"]
+      - name: nginx
+        image: "gcr.io/google-samples/hello-frontend:1.0"
+        lifecycle:
+          preStop:
+            exec:
+              command: ["/usr/sbin/nginx","-s","quit"]
@@ -7,6 +7,6 @@ spec:
    app: hello
    tier: backend
  ports:
-    - protocol: TCP
-      port: 80
-      targetPort: http
+  - protocol: TCP
+    port: 80
+    targetPort: http
@@ -46,7 +46,7 @@ for all items returned.

 As an alternative, it is possible to use the absolute path to the image
 field within the Pod.  This ensures the correct field is retrieved
-in the even the field name is repeated,
+even when the field name is repeated,
 e.g. many fields are called `name` within a given item:

 ```sh
@@ -43,7 +43,7 @@ the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to
   This list also includes the name of the claims that are bound to each volume
   for easier identification of dynamically provisioned volumes.

-1. Chose one of your PersistentVolumes and change its reclaim policy:
+1. Choose one of your PersistentVolumes and change its reclaim policy:

       kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'

@@ -0,0 +1,78 @@
+---
+assignees:
+- danwent
+title: Use Cilium for NetworkPolicy
+---
+
+{% capture overview %}
+This page shows how to use Cilium for NetworkPolicy.
+
+For background on Cilium, read the [Introduction to Cilium](http://cilium.readthedocs.io/en/latest/intro/).
+{% endcapture %}
+
+{% capture prerequisites %}
+
+{% include task-tutorial-prereqs.md %}
+
+{% endcapture %}
+
+{% capture steps %}
+## Deploying Cilium on Minikube for Basic Testing
+
+To get familiar with Cilium easily you can follow the
+[Cilium Kubernetes Getting Started Guide](http://www.cilium.io/try)
+to perform a basic DaemonSet installation of Cilium in minikube.
+
+Installation in a minikube setup uses a simple ''all-in-one'' YAML
+file that includes DaemonSet configurations for Cilium and a key-value store
+(consul) as well as appropriate RBAC settings:
+
+```shell
+$ kubectl create -f https://raw.githubusercontent.com/cilium/cilium/master/examples/minikube/cilium-ds.yaml
+clusterrole "cilium" created
+serviceaccount "cilium" created
+clusterrolebinding "cilium" created
+daemonset "cilium-consul" created
+daemonset "cilium" created
+```
+
+The remainder of the Getting Started Guide explains how to enforce both L3/L4 (i.e., IP address + port) security
+policies, as well as L7 (e.g., HTTP) security policies using an example application.
+
+## Deploying Cilium for Production Use
+
+For detailed instructions around deploying Cilium for production, see:
+[Cilium Administrator Guide](http://cilium.readthedocs.io/en/latest/admin/) This
+documentation includes detailed requirements, instructions and example production DaemonSet files.
+
+{% endcapture %}
+
+{% capture discussion %}
+##  Understanding Cilium components
+
+Deploying a cluster with Cilium adds Pods to the `kube-system` namespace.  To see this list of Pods run:
+
+```shell
+kubectl get pods --namespace=kube-system
+```
+
+You'll see a list of Pods similar to this:
+
+```console
+NAME            DESIRED   CURRENT   READY     NODE-SELECTOR   AGE
+cilium          1         1         1         <none>          2m
+...
+```
+
+There are two main components to be aware of:
+
+- One `cilium` Pod runs on each node in your cluster and enforces network policy on the traffic to/from Pods on that node using Linux BPF.
+- For production deployments, Cilium should leverage the key-value store cluster (e.g., etcd) used by Kubernetes, which typically runs on the Kubernetes master nodes.   The [Cilium Administrator Guide](http://cilium.readthedocs.io/en/latest/admin/) includes an example DaemonSet which can be customized to point to this key-value store cluster.   The simple ''all-in-one'' DaemonSet for minikube requires no such configuration because it automatically deploys a `cilium-consul` Pod to provide a key-value store.
+
+{% endcapture %}
+
+{% capture whatsnext %}
+Once your cluster is running, you can follow the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy with Cilium.  Have fun, and if you have questions, contact us using the [Cilium Slack Channel](https://cilium.herokuapp.com/).
+{% endcapture %}
+
+{% include templates/task.md %}
@@ -12,6 +12,7 @@ This document helps you get started using the Kubernetes [NetworkPolicy API](/do
 You'll need to have a Kubernetes cluster in place, with network policy support. There are a number of network providers that support NetworkPolicy, including:

 * [Calico](/docs/tasks/configure-pod-container/calico-network-policy/)
+* [Cilium](/docs/tasks/configure-pod-container/cilium-network-policy/)
 * [Romana](/docs/tasks/configure-pod-container/romana-network-policy/)
 * [Weave Net](/docs/tasks/configure-pod-container/weave-network-policy/)

@@ -137,7 +137,7 @@ program to retrieve the contents of your secret.
 4. Verify the secret is correctly decrypted when retrieved via the API:

    ```
-    kubectl describe secret generic -n default
+    kubectl describe secret secret1 -n default
    ```

    should match `mykey: mydata`
@@ -211,7 +211,6 @@ The output shows that the Container starts and fails repeatedly:
 ```
 ... Normal  Created   Created container with id 66a3a20aa7980e61be4922780bf9d24d1a1d8b7395c09861225b0eba1b1f8511
 ... Warning BackOff   Back-off restarting failed container
-
 ```

 View detailed information about your cluster's Nodes:
@@ -332,7 +332,7 @@ need to set the `level` section. This sets the
 [Multi-Category Security (MCS)](https://selinuxproject.org/page/NB_MLS)
 label given to all Containers in the Pod as well as the Volumes.

-**Warning:** After you specify an MCS label for a Pod, all Pods with the same label will able to access the Volume. So if you need inter-Pod protection, you must ensure each Pod is assigned a unique MCS label.
+**Warning:** After you specify an MCS label for a Pod, all Pods with the same label can access the Volume. If you need inter-Pod protection, you must assign a unique MCS label to each Pod.
 {: .warning}

 {% endcapture %}
@@ -227,8 +227,8 @@ due to caching by intermediate DNS servers.

 1. Notice that there is a normal ('A') record for each service shard that has at least one healthy backend endpoint. For example, in us-central1-a, 104.197.247.191 is the external IP address of the service shard in that zone, and in asia-east1-a the address is 130.211.56.221.
 2. Similarly, there are regional 'A' records which include all healthy shards in that region. For example, 'us-central1'.  These regional records are useful for clients which do not have a particular zone preference, and as a building block for the automated locality and failover mechanism described below.
-2. For zones where there are currently no healthy backend endpoints, a CNAME ('Canonical Name') record is used to alias (automatically redirect) those queries to the next closest healthy zone.  In the example, the service shard in us-central1-f currently has no healthy backend endpoints (i.e. Pods), so a CNAME record has been created to automatically redirect queries to other shards in that region (us-central1 in this case).
-3. Similarly, if no healthy shards exist in the enclosing region, the search progresses further afield. In the europe-west1-d availability zone, there are no healthy backends, so queries are redirected to the broader europe-west1 region (which also has no healthy backends), and onward to the global set of healthy addresses (' nginx.mynamespace.myfederation.svc.example.com.')
+3. For zones where there are currently no healthy backend endpoints, a CNAME ('Canonical Name') record is used to alias (automatically redirect) those queries to the next closest healthy zone.  In the example, the service shard in us-central1-f currently has no healthy backend endpoints (i.e. Pods), so a CNAME record has been created to automatically redirect queries to other shards in that region (us-central1 in this case).
+4. Similarly, if no healthy shards exist in the enclosing region, the search progresses further afield. In the europe-west1-d availability zone, there are no healthy backends, so queries are redirected to the broader europe-west1 region (which also has no healthy backends), and onward to the global set of healthy addresses (' nginx.mynamespace.myfederation.svc.example.com.').

 The above set of DNS records is automatically kept in sync with the
 current state of health of all service shards globally by the
@@ -355,7 +355,7 @@ how to bring up a cluster federation correctly (or have your cluster administrat
 #### I can create a federated service successfully against the cluster federation API, but no matching services are created in my underlying clusters
 Check that:

-1. Your clusters are correctly registered in the Cluster Federation API (`kubectl describe clusters`)
+1. Your clusters are correctly registered in the Cluster Federation API (`kubectl describe clusters`).
 2. Your clusters are all 'Active'.  This means that the cluster Federation system was able to connect and authenticate against the clusters' endpoints.  If not, consult the logs of the federation-controller-manager pod to ascertain what the failure might be. (`kubectl --namespace=federation logs $(kubectl get pods --namespace=federation -l module=federation-controller-manager -o name`)
 3. That the login credentials provided to the Cluster Federation API for the clusters have the correct authorization and quota to create services in the relevant namespace in the clusters.  Again you should see associated error messages providing more detail in the above log file if this is not the case.
 4. Whether any other error is preventing the service creation operation from succeeding (look for `service-controller` errors in the output of `kubectl logs federation-controller-manager --namespace federation`).
@@ -365,7 +365,7 @@ Check that:

 1. Your federation name, DNS provider, DNS domain name are configured correctly.  Consult the [federation admin guide](/docs/admin/federation/) or  [tutorial](https://github.com/kelseyhightower/kubernetes-cluster-federation) to learn
 how to configure your Cluster Federation system's DNS provider (or have your cluster administrator do this for you).
-2. Confirm that the Cluster Federation's service-controller is successfully connecting to and authenticating against your selected DNS provider (look for `service-controller` errors or successes in the output of `kubectl logs federation-controller-manager --namespace federation`)
+2. Confirm that the Cluster Federation's service-controller is successfully connecting to and authenticating against your selected DNS provider (look for `service-controller` errors or successes in the output of `kubectl logs federation-controller-manager --namespace federation`).
 3. Confirm that the Cluster Federation's service-controller is successfully creating DNS records in your DNS provider (or outputting errors in its logs explaining in more detail what's failing).

 #### Matching DNS records are created in my DNS provider, but clients are unable to resolve against those names
@@ -367,7 +367,7 @@ kubefed init fellowship \
 ```

 For more information see
-[Setting up CoreDNS as DNS provider for Cluster Federation](/docs/tutorials/federation/set-up-coredns-provider-federation/)
+[Setting up CoreDNS as DNS provider for Cluster Federation](/docs/tutorials/federation/set-up-coredns-provider-federation/).

 ## Adding a cluster to a federation

@@ -464,7 +464,7 @@ commands.

 In all other cases, you must update `kube-dns` configuration manually
 as described in the
-[Updating KubeDNS section of the admin guide](/docs/admin/federation/)
+[Updating KubeDNS section of the admin guide](/docs/admin/federation/).

 ## Removing a cluster from a federation

@@ -16,7 +16,7 @@ This page shows how to perform a rollback on a DaemonSet.
 * The DaemonSet rollout history and DaemonSet rollback features are only
  supported in `kubectl` in Kubernetes version 1.7 or later.
 * Make sure you know how to [perform a rolling update on a
-  DaemonSet](/docs/tasks/manage-daemon/update-daemon-set/)
+  DaemonSet](/docs/tasks/manage-daemon/update-daemon-set/).

 {% endcapture %}

@@ -99,7 +99,7 @@ kubectl rollout status ds/<daemonset-name>
 When the rollback is complete, the output is similar to this:

 ```shell
-daemon set "<daemonset-name>" successfully rolled out
+daemonset "<daemonset-name>" successfully rolled out
 ```

 {% endcapture %}
@@ -147,7 +147,7 @@ have revision 1 and 2 in the system, and roll back from revision 2 to revision
 ## Troubleshooting

 * See [troubleshooting DaemonSet rolling
-  update](/docs/tasks/manage-daemon/update-daemon-set/#troubleshooting)
+  update](/docs/tasks/manage-daemon/update-daemon-set/#troubleshooting).

 {% endcapture %}

@@ -4,7 +4,7 @@ metadata:
  name: mysql
 spec:
  ports:
-    - port: 3306
+  - port: 3306
  selector:
    app: mysql
  clusterIP: None