Merge master into release-1.10

docs/concepts/cluster-administration/device-plugins.md

@@ -139,7 +139,7 @@ For examples of device plugin implementations, see:
     * it requires using [nvidia-docker 2.0](https://github.com/NVIDIA/nvidia-docker) which allows you to run GPU enabled docker containers
 * The [NVIDIA GPU device plugin for COS base OS](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu).
 * The [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin)
-
+* The [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin)
 {% endcapture %}
 
 {% include templates/concept.md %}

docs/concepts/cluster-administration/networking.md

@@ -216,7 +216,7 @@ The Nuage platform uses overlays to provide seamless policy-based networking bet
 
 ### OpenVSwitch
 
-[OpenVSwitch](/docs/admin/ovs-networking) is a somewhat more mature but also
+[OpenVSwitch](https://www.openvswitch.org/) is a somewhat more mature but also
 complicated way to build an overlay network.  This is endorsed by several of the
 "Big Shops" for networking.
 

docs/concepts/configuration/assign-pod-node.md

@@ -88,7 +88,7 @@ feature, currently in beta, greatly expands the types of constraints you can exp
 3. you can constrain against labels on other pods running on the node (or other topological domain),
    rather than against labels on the node itself, which allows rules about which pods can and cannot be co-located
 
-The affinity feature consists of two types of affinity, "node affinity" and "inter-pod affinity/anti-affinity."
+The affinity feature consists of two types of affinity, "node affinity" and "inter-pod affinity/anti-affinity".
 Node affinity is like the existing `nodeSelector` (but with the first two benefits listed above),
 while inter-pod affinity/anti-affinity constrains against pod labels rather than node labels, as
 described in the third item listed above, in addition to having the first and second properties listed above.
@@ -147,7 +147,7 @@ For more information on node affinity, see the design doc
 Inter-pod affinity and anti-affinity were introduced in Kubernetes 1.4.
 Inter-pod affinity and anti-affinity allow you to constrain which nodes your pod is eligible to be scheduled *based on
 labels on pods that are already running on the node* rather than based on labels on nodes. The rules are of the form "this pod should (or, in the case of
-anti-affinity, should not) run in an X if that X is already running one or more pods that meet rule Y." Y is expressed
+anti-affinity, should not) run in an X if that X is already running one or more pods that meet rule Y". Y is expressed
 as a LabelSelector with an associated list of namespaces (or "all" namespaces); unlike nodes, because pods are namespaced
 (and therefore the labels on pods are implicitly namespaced),
 a label selector over pod labels must specify which namespaces the selector should apply to. Conceptually X is a topology domain
@@ -203,7 +203,7 @@ empty `topologyKey` is not allowed.
 In addition to `labelSelector` and `topologyKey`, you can optionally specify a list `namespaces`
 of namespaces which the `labelSelector` should match against (this goes at the same level of the definition as `labelSelector` and `topologyKey`).
 If omitted, it defaults to the namespace of the pod where the affinity/anti-affinity definition appears.
-If defined but empty, it means "all namespaces."
+If defined but empty, it means "all namespaces".
 
 All `matchExpressions` associated with `requiredDuringSchedulingIgnoredDuringExecution` affinity and anti-affinity
 must be satisfied for the pod to be scheduled onto a node.

docs/concepts/policy/resource-quotas.md

@@ -25,7 +25,7 @@ Resource quotas work like this:
   status code `403 FORBIDDEN` with a message explaining the constraint that would have been violated.
 - If quota is enabled in a namespace for compute resources like `cpu` and `memory`, users must specify
   requests or limits for those values; otherwise, the quota system may reject pod creation.  Hint: Use
-  the LimitRange admission controller to force defaults for pods that make no compute resource requirements.
+  the `LimitRanger` admission controller to force defaults for pods that make no compute resource requirements.
   See the [walkthrough](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) for an example of how to avoid this problem.
 
 Examples of policies that could be created using namespaces and quotas are:

docs/concepts/services-networking/connect-applications-service.md

@@ -185,10 +185,10 @@ Following are the manual steps to follow in case you run into problems running m
 
 ```shell
 #create a public private key pair
-openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /d/tmp/nginx.key -out /d/tmp/nginx.crt -subj "/CN=nginxsvc/O=nginxsvc"
+openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /d/tmp/nginx.key -out /d/tmp/nginx.crt -subj "/CN=my-nginx/O=my-nginx"
 #convert the keys to base64 encoding
-cat /d/tmp/nginx.crt | base 64
-cat /d/tmp/nginx.key | base 64
+cat /d/tmp/nginx.crt | base64
+cat /d/tmp/nginx.key | base64
 ```
 Use the output from the previous commands to create a yaml file as follows. The base64 encoded value should all be on a single line.
 

docs/concepts/services-networking/ingress.md

@@ -16,7 +16,7 @@ Throughout this doc you will see a few terms that are sometimes used interchange
 * Node: A single virtual or physical machine in a Kubernetes cluster.
 * Cluster: A group of nodes firewalled from the internet, that are the primary compute resources managed by Kubernetes.
 * Edge router: A router that enforces the firewall policy for your cluster. This could be a gateway managed by a cloud provider or a physical piece of hardware.
-* Cluster network: A set of links, logical or physical, that facilitate communication within a cluster according to the [Kubernetes networking model](/docs/concepts/cluster-administration/networking/). Examples of a Cluster network include Overlays such as [flannel](https://github.com/coreos/flannel#flannel) or SDNs such as [OVS](/docs/admin/ovs-networking/).
+* Cluster network: A set of links, logical or physical, that facilitate communication within a cluster according to the [Kubernetes networking model](/docs/concepts/cluster-administration/networking/). Examples of a Cluster network include Overlays such as [flannel](https://github.com/coreos/flannel#flannel) or SDNs such as [OVS](https://www.openvswitch.org/).
 * Service: A Kubernetes [Service](/docs/concepts/services-networking/service/) that identifies a set of pods using label selectors. Unless mentioned otherwise, Services are assumed to have virtual IPs only routable within the cluster network.
 
 ## What is Ingress?

docs/concepts/services-networking/network-policies.md

@@ -186,3 +186,4 @@ This ensures that even pods that aren't selected by any other NetworkPolicy will
 
 - See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/)
   walkthrough for further examples.
+- See more [Recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource.