Merge branch 'master' into release-1.12

2018-11-01 14:10:31 -07:00
parent 9a2e390e59 a9c6b4dba0
commit f002059889
146 changed files with 4631 additions and 773 deletions
@@ -18,7 +18,6 @@ Here's the architecture of a Kubernetes cluster without the cloud controller man

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -46,16 +45,16 @@ The CCM breaks away some of the functionality of Kubernetes controller manager (
 In version 1.9, the CCM runs the following controllers from the preceding list:

 * Node controller
-* Route controller 
+* Route controller
 * Service controller

-Additionally, it runs another controller called the PersistentVolumeLabels controller. This controller is responsible for setting the zone and region labels on PersistentVolumes created in GCP and AWS clouds. 
+Additionally, it runs another controller called the PersistentVolumeLabels controller. This controller is responsible for setting the zone and region labels on PersistentVolumes created in GCP and AWS clouds.

 {{< note >}}
-**Note:** Volume controller was deliberately chosen to not be a part of CCM. Due to the complexity involved and due to the existing efforts to abstract away vendor specific volume logic, it was decided that volume controller will not be moved to CCM. 
+**Note:** Volume controller was deliberately chosen to not be a part of CCM. Due to the complexity involved and due to the existing efforts to abstract away vendor specific volume logic, it was decided that volume controller will not be moved to CCM.
 {{< /note >}}

-The original plan to support volumes using CCM was to use Flex volumes to support pluggable volumes. However, a competing effort known as CSI is being planned to replace Flex. 
+The original plan to support volumes using CCM was to use Flex volumes to support pluggable volumes. However, a competing effort known as CSI is being planned to replace Flex.

 Considering these dynamics, we decided to have an intermediate stop gap measure until CSI becomes ready.

@@ -68,7 +67,7 @@ The CCM inherits its functions from components of Kubernetes that are dependent
 The majority of the CCM's functions are derived from the KCM. As mentioned in the previous section, the CCM runs the following control loops:

 * Node controller
-* Route controller 
+* Route controller
 * Service controller
 * PersistentVolumeLabels controller

@@ -92,7 +91,7 @@ The Service controller is responsible for listening to service create, update, a

 #### PersistentVolumeLabels controller

-The PersistentVolumeLabels controller applies labels on AWS EBS/GCE PD volumes when they are created. This removes the need for users to manually set the labels on these volumes. 
+The PersistentVolumeLabels controller applies labels on AWS EBS/GCE PD volumes when they are created. This removes the need for users to manually set the labels on these volumes.

 These labels are essential for the scheduling of pods as these volumes are constrained to work only within the region/zone that they are in. Any Pod using these volumes needs to be scheduled in the same region/zone.

@@ -100,7 +99,7 @@ The PersistentVolumeLabels controller was created specifically for the CCM; that

 ### 2. Kubelet

-The Node controller contains the cloud-dependent functionality of the kubelet. Prior to the introduction of the CCM, the kubelet was responsible for initializing a node with cloud-specific details such as IP addresses, region/zone labels and instance type information. The introduction of the CCM has moved this initialization operation from the kubelet into the CCM. 
+The Node controller contains the cloud-dependent functionality of the kubelet. Prior to the introduction of the CCM, the kubelet was responsible for initializing a node with cloud-specific details such as IP addresses, region/zone labels and instance type information. The introduction of the CCM has moved this initialization operation from the kubelet into the CCM.

 In this new model, the kubelet initializes a node without cloud-specific information. However, it adds a taint to the newly created node that makes the node unschedulable until the CCM initializes the node with cloud-specific information. It then removes this taint.

@@ -118,13 +117,13 @@ For more information about developing plugins, see [Developing Cloud Controller

 ## Authorization

-This section breaks down the access required on various API objects by the CCM to perform its operations. 
+This section breaks down the access required on various API objects by the CCM to perform its operations.

 ### Node Controller

 The Node controller only works with Node objects. It requires full access to get, list, create, update, patch, watch, and delete Node objects.

-v1/Node: 
+v1/Node:

 - Get
 - List
@@ -136,17 +135,17 @@ v1/Node:

 ### Route controller

-The route controller listens to Node object creation and configures routes appropriately. It requires get access to Node objects. 
+The route controller listens to Node object creation and configures routes appropriately. It requires get access to Node objects.

-v1/Node: 
+v1/Node:

 - Get

 ### Service controller

-The service controller listens to Service object create, update and delete events and then configures endpoints for those Services appropriately. 
+The service controller listens to Service object create, update and delete events and then configures endpoints for those Services appropriately.

-To access Services, it requires list, and watch access. To update Services, it requires patch and update access. 
+To access Services, it requires list, and watch access. To update Services, it requires patch and update access.

 To set up endpoints for the Services, it requires access to create, list, get, watch, and update.

@@ -249,7 +248,7 @@ rules:

 ## Vendor Implementations

-The following cloud providers have implemented CCMs: 
+The following cloud providers have implemented CCMs:

 * [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
 * [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
@@ -18,7 +18,6 @@ cloud provider).

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -67,9 +66,9 @@ The connections from the apiserver to the kubelet are used for:

  * Fetching logs for pods.
  * Attaching (through kubectl) to running pods.
-  * Providing the kubelet's port-forwarding functionality. 
+  * Providing the kubelet's port-forwarding functionality.

-These connections terminate at the kubelet's HTTPS endpoint. By default, 
+These connections terminate at the kubelet's HTTPS endpoint. By default,
 the apiserver does not verify the kubelet's serving certificate,
 which makes the connection subject to man-in-the-middle attacks, and
 **unsafe** to run over untrusted and/or public networks.
@@ -18,7 +18,6 @@ architecture design doc for more details.

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -76,18 +75,18 @@ the `Terminating` or `Unknown` state. In cases where Kubernetes cannot deduce fr
 permanently left a cluster, the cluster administrator may need to delete the node object by hand.  Deleting the node object from
 Kubernetes causes all the Pod objects running on the node to be deleted from the apiserver, and frees up their names.

-In version 1.12, `TaintNodesByCondition` feature is promoted to beta，so node lifecycle controller automatically creates 
+In version 1.12, `TaintNodesByCondition` feature is promoted to beta，so node lifecycle controller automatically creates
 [taints](/docs/concepts/configuration/taint-and-toleration/) that represent conditions.
 Similarly the scheduler ignores conditions when considering a Node; instead
 it looks at the Node's taints and a Pod's tolerations.

 Now users can choose between the old scheduling model and a new, more flexible scheduling model.
-A Pod that does not have any tolerations gets scheduled according to the old model. But a Pod that 
+A Pod that does not have any tolerations gets scheduled according to the old model. But a Pod that
 tolerates the taints of a particular Node can be scheduled on that Node.

 {{< caution >}}
-**Caution:** Enabling this feature creates a small delay between the 
-time when a condition is observed and when a taint is created. This delay is usually less than one second, but it can increase the number of Pods that are successfully scheduled but rejected by the kubelet. 
+**Caution:** Enabling this feature creates a small delay between the
+time when a condition is observed and when a taint is created. This delay is usually less than one second, but it can increase the number of Pods that are successfully scheduled but rejected by the kubelet.
 {{< /caution >}}

 ### Capacity
@@ -127,7 +126,7 @@ a node from the following content:
 Kubernetes creates a node object internally (the representation), and
 validates the node by health checking based on the `metadata.name` field. If the node is valid -- that is, if all necessary
 services are running -- it is eligible to run a pod. Otherwise, it is
-ignored for any cluster activity until it becomes valid. 
+ignored for any cluster activity until it becomes valid.

 {{< note >}}
 **Note:** Kubernetes keeps the object for the invalid node and keeps checking to see whether it becomes valid.
@@ -14,7 +14,6 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -30,7 +29,7 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply
 * [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) is an overlay network provider that can be used with Kubernetes.
 * [Knitter](https://github.com/ZTE/Knitter/) is a network solution supporting multiple networking in Kubernetes.
 * [Multus](https://github.com/Intel-Corp/multus-cni) is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes.
-* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and Openshift. 
+* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and Openshift.
 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) is an SDN platform that provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring.
 * [Romana](http://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize).
 * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database.
@@ -12,7 +12,6 @@ manually through `easyrsa`, `openssl` or `cfssl`.

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -81,7 +80,7 @@ manually through `easyrsa`, `openssl` or `cfssl`.
        default_md = sha256
        req_extensions = req_ext
        distinguished_name = dn
-        
+
        [ dn ]
        C = <country>
        ST = <state>
@@ -89,10 +88,10 @@ manually through `easyrsa`, `openssl` or `cfssl`.
        O = <organization>
        OU = <organization unit>
        CN = <MASTER_IP>
-        
+
        [ req_ext ]
        subjectAltName = @alt_names
-        
+
        [ alt_names ]
        DNS.1 = kubernetes
        DNS.2 = kubernetes.default
@@ -101,7 +100,7 @@ manually through `easyrsa`, `openssl` or `cfssl`.
        DNS.5 = kubernetes.default.svc.cluster.local
        IP.1 = <MASTER_IP>
        IP.2 = <MASTER_CLUSTER_IP>
-        
+
        [ v3_ext ]
        authorityKeyIdentifier=keyid,issuer:always
        basicConstraints=CA:FALSE
@@ -213,7 +212,7 @@ Finally, add the same parameters into the API server start parameters.
            "O": "<organization>",
            "OU": "<organization unit>"
          }]
-        } 
+        }
 1.  Generate the key and certificate for the API server, which are by default
    saved into file `server-key.pem` and `server.pem` respectively:

@@ -9,12 +9,11 @@ This page explains how to manage Kubernetes running on a specific
 cloud provider.
 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}
 ### kubeadm
-[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) is a popular option for creating kubernetes clusters. 
-kubeadm has configuration options to specify configuration information for cloud providers. For example a typical 
+[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) is a popular option for creating kubernetes clusters.
+kubeadm has configuration options to specify configuration information for cloud providers. For example a typical
 in-tree cloud provider can be configured using kubeadm as shown below:

 ```yaml
@@ -214,7 +213,7 @@ file:
  connotation, a deployment can use a geographical name for a region identifier
  such as `us-east`. Available regions are found under the `/v3/regions`
  endpoint of the Keystone API.
-* `ca-file` (Optional): Used to specify the path to your custom CA file. 
+* `ca-file` (Optional): Used to specify the path to your custom CA file.


 When using Keystone V3 - which changes tenant to project - the `tenant-id` value
@@ -361,12 +360,12 @@ Note that the Kubernetes Node name must match the Photon VM name (or if `overrid

 The VSphere cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.

-## IBM Cloud Kubernetes Service 
+## IBM Cloud Kubernetes Service

 ### Compute nodes
 By using the IBM Cloud Kubernetes Service provider, you can create clusters with a mixture of virtual and physical (bare metal) nodes in a single zone or across multiple zones in a region. For more information, see [Planning your cluster and worker node setup](https://console.bluemix.net/docs/containers/cs_clusters_planning.html#plan_clusters).

-The name of the Kubernetes Node object is the private IP address of the IBM Cloud Kubernetes Service worker node instance. 
+The name of the Kubernetes Node object is the private IP address of the IBM Cloud Kubernetes Service worker node instance.

 ### Networking
 The IBM Cloud Kubernetes Service provider provides VLANs for quality network performance and network isolation for nodes. You can set up custom firewalls and Calico network policies to add an extra layer of security for your cluster, or connect your cluster to your on-prem data center via VPN. For more information, see [Planning in-cluster and private networking](https://console.bluemix.net/docs/containers/cs_network_cluster.html#planning).
@@ -37,7 +37,7 @@ why you might want multiple clusters are:
 * Low latency: Having clusters in multiple regions minimises latency by serving
  users from the cluster that is closest to them.
 * Fault isolation: It might be better to have multiple small clusters rather
-  than a single large  cluster for fault isolation (for example: multiple
+  than a single large cluster for fault isolation (for example: multiple
  clusters in different availability zones of a cloud provider).
 * Scalability: There are scalability limits to a single kubernetes cluster (this
  should not be the case for most users. For more details:
@@ -14,7 +14,6 @@ External garbage collection tools are not recommended as these tools can potenti

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -42,7 +41,7 @@ Containers that are not managed by kubelet are not subject to container garbage
 Users can adjust the following thresholds to tune image garbage collection with the following kubelet flags :

 1. `image-gc-high-threshold`, the percent of disk usage which triggers image garbage collection.
-Default is 90%.
+Default is 85%.
 2. `image-gc-low-threshold`, the percent of disk usage to which image garbage collection attempts
 to free. Default is 80%.

@@ -15,7 +15,6 @@ However, the native functionality provided by a container engine or runtime is u

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -14,7 +14,6 @@ You've deployed your application and exposed it via a service. Now what? Kuberne

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -18,12 +18,11 @@ default.  There are 4 distinct networking problems to solve:

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

 Kubernetes assumes that pods can communicate with other pods, regardless of
-which host they land on.  Every pod gets its own IP address so you do not
+which host they land on. Every pod gets its own IP address so you do not
 need to explicitly create links between pods and you almost never need to deal
 with mapping container ports to host ports.  This creates a clean,
 backwards-compatible model where pods can be treated much like VMs or physical
@@ -123,10 +122,10 @@ AOS supports the use of common vendor equipment from manufacturers including Cis
 Details on how the AOS system works can be accessed here: http://www.apstra.com/products/how-it-works/

 ### Big Cloud Fabric from Big Switch Networks
- 
-[Big Cloud Fabric](https://www.bigswitch.com/container-network-automation) is a cloud native networking architecture, designed to run Kubernetes in private cloud/on-premises environments. Using unified physical & virtual SDN, Big Cloud Fabric tackles inherent container networking problems such as load balancing, visibility, troubleshooting, security policies & container traffic monitoring. 

-With the help of the Big Cloud Fabric's virtual pod multi-tenant architecture, container orchestration systems such as Kubernetes, RedHat Openshift, Mesosphere DC/OS & Docker Swarm will be natively integrated along side with VM orchestration systems such as VMware, OpenStack & Nutanix. Customers will be able to securely inter-connect any number of these clusters and enable inter-tenant communication between them if needed. 
+[Big Cloud Fabric](https://www.bigswitch.com/container-network-automation) is a cloud native networking architecture, designed to run Kubernetes in private cloud/on-premises environments. Using unified physical & virtual SDN, Big Cloud Fabric tackles inherent container networking problems such as load balancing, visibility, troubleshooting, security policies & container traffic monitoring.
+
+With the help of the Big Cloud Fabric's virtual pod multi-tenant architecture, container orchestration systems such as Kubernetes, RedHat Openshift, Mesosphere DC/OS & Docker Swarm will be natively integrated along side with VM orchestration systems such as VMware, OpenStack & Nutanix. Customers will be able to securely inter-connect any number of these clusters and enable inter-tenant communication between them if needed.

 BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](http://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on-premises deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/).

@@ -152,6 +151,18 @@ CNI-Genie also supports [assigning multiple IP addresses to a pod](https://githu

 [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [OpenContrail](http://www.opencontrail.org), is a truly open, multi-cloud network virtualization and policy management platform. Contrail / OpenContrail is integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provides different isolation modes for virtual machines, containers/pods and bare metal workloads.

+### DANM
+
+[DANM](https://github.com/nokia/danm) is a networking solution for telco workloads running in a Kubernetes cluster. It's built up from the following components:
+
+   * A CNI plugin capable of provisioning IPVLAN interfaces with advanced features
+   * An in-built IPAM module with the capability of managing multiple, cluster-wide, discontinuous L3 networks and provide a dynamic, static, or no IP allocation scheme on-demand
+   * A CNI metaplugin capable of attaching multiple network interfaces to a container, either through its own CNI, or through delegating the job to any of the popular CNI solution like SRI-OV, or Flannel in parallel
+   * A Kubernetes controller capable of centrally managing both VxLAN and VLAN interfaces of all Kubernetes hosts
+   * Another Kubernetes controller extending Kubernetes' Service-based service discovery concept to work over all network interfaces of a Pod
+
+With this toolset DANM is able to provide multiple separated network interfaces, the possibility to use different networking back ends and advanced IPAM features for the pods.
+
 ### Flannel

 [Flannel](https://github.com/coreos/flannel#flannel) is a very simple overlay
@@ -182,7 +193,7 @@ each other and `Nodes` over the `cbr0` bridge.  Those IPs are all routable
 within the GCE project network.

 GCE itself does not know anything about these IPs, though, so it will not NAT
-them for outbound internet traffic.  To achieve that an iptables rule is used 
+them for outbound internet traffic.  To achieve that an iptables rule is used
 to masquerade (aka SNAT - to make it seem as if packets came from the `Node`
 itself) traffic that is bound for IPs outside the GCE project network
 (10.0.0.0/8).
@@ -203,7 +214,7 @@ traffic to the internet.

 ### Jaguar

-[Jaguar](https://gitlab.com/sdnlab/jaguar) is an open source solution for Kubernetes's network based on OpenDaylight. Jaguar provides overlay network using vxlan and Jaguar CNIPlugin provides one IP address per pod. 
+[Jaguar](https://gitlab.com/sdnlab/jaguar) is an open source solution for Kubernetes's network based on OpenDaylight. Jaguar provides overlay network using vxlan and Jaguar CNIPlugin provides one IP address per pod.

 ### Knitter

@@ -232,10 +243,10 @@ Lars Kellogg-Stedman.
 Multus supports all [reference plugins](https://github.com/containernetworking/plugins) (eg. [Flannel](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) that implement the CNI specification and 3rd party plugins (eg. [Calico](https://github.com/projectcalico/cni-plugin), [Weave](https://github.com/weaveworks/weave), [Cilium](https://github.com/cilium/cilium), [Contiv](https://github.com/contiv/netplugin)). In addition to it, Multus supports [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK & VPP](https://github.com/intel/vhost-user-net-plugin) workloads in Kubernetes with both cloud native and NFV based applications in Kubernetes.

 ### NSX-T
- 
+
 [VMware NSX-T](https://docs.vmware.com/en/VMware-NSX-T/index.html) is a network virtualization and security platform. NSX-T can provide network virtualization for a multi-cloud and multi-hypervisor environment and is focused on emerging application frameworks and architectures that have heterogeneous endpoints and technology stacks. In addition to vSphere hypervisors, these environments include other hypervisors such as KVM, containers, and bare metal.
- 
-[NSX-T Container Plug-in (NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) provides integration between NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and Openshift. 
+
+[NSX-T Container Plug-in (NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) provides integration between NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and Openshift.

 ### Nuage Networks VCS (Virtualized Cloud Services)

@@ -277,11 +288,6 @@ Weave Net runs as a [CNI plug-in](https://www.weave.works/docs/net/latest/cni-pl
 or stand-alone.  In either version, it doesn't require any configuration or extra code
 to run, and in both cases, the network provides one IP address per pod - as is standard for Kubernetes.

-### Jaguar
-
-[Jaguar](https://gitlab.com/sdnlab/jaguar) is an open source solution for Kubernetes's network based on OpenDaylight.
-Jaguar provides overlay network using vxlan and Jaguar CNIPlugin provides one IP address per pod.
-
 {{% /capture %}}

 {{% capture whatsnext %}}
@@ -8,7 +8,6 @@ content_template: templates/concept
 weight: 30
 ---

-{{< toc >}}

 {{% capture overview %}}

@@ -144,7 +143,7 @@ among nodes that meet that criteria, nodes with a label whose key is `another-no
 value is `another-node-label-value` should be preferred.

 You can see the operator `In` being used in the example. The new node affinity syntax supports the following operators: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`.
-You can use `NotIn` and `DoesNotExist` to achieve node anti-affinity behavior, or use 
+You can use `NotIn` and `DoesNotExist` to achieve node anti-affinity behavior, or use
 [node taints](/docs/concepts/configuration/taint-and-toleration/) to repel pods from specific nodes.

 If you specify both `nodeSelector` and `nodeAffinity`, *both* must be satisfied for the pod
@@ -158,7 +157,7 @@ If you remove or change the label of the node where the pod is scheduled, the po

 The `weight` field in `preferredDuringSchedulingIgnoredDuringExecution` is in the range 1-100. For each node that meets all of the scheduling requirements (resource request, RequiredDuringScheduling affinity expressions, etc.), the scheduler will compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node matches the corresponding MatchExpressions. This score is then combined with the scores of other priority functions for the node. The node(s) with the highest total score are the most preferred.

-For more information on node affinity, see the 
+For more information on node affinity, see the
 [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md).

 ### Inter-pod affinity and anti-affinity (beta feature)
@@ -174,7 +173,7 @@ like node, rack, cloud provider zone, cloud provider region, etc. You express it
 key for the node label that the system uses to denote such a topology domain, e.g. see the label keys listed above
 in the section [Interlude: built-in node labels](#interlude-built-in-node-labels).

-**Note:** Inter-pod affinity and anti-affinity require substantial amount of 
+**Note:** Inter-pod affinity and anti-affinity require substantial amount of
 processing which can slow down scheduling in large clusters significantly. We do
 not recommend using them in clusters larger than several hundred nodes.

@@ -206,7 +205,7 @@ value V that is running a pod that has a label with key "security" and value "S1
 rule says that the pod prefers not to be scheduled onto a node if that node is already running a pod with label
 having key "security" and value "S2". (If the `topologyKey` were `failure-domain.beta.kubernetes.io/zone` then
 it would mean that the pod cannot be scheduled onto a node if that node is in the same zone as a pod with
-label having key "security" and value "S2".) See the 
+label having key "security" and value "S2".) See the
 [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
 for many more examples of pod affinity and anti-affinity, both the `requiredDuringSchedulingIgnoredDuringExecution`
 flavor and the `preferredDuringSchedulingIgnoredDuringExecution` flavor.
@@ -333,12 +332,12 @@ web-server-1287567482-s330j    1/1       Running   0          7m        10.192.3

 ##### Never co-located in the same node

-The above example uses `PodAntiAffinity` rule with `topologyKey: "kubernetes.io/hostname"` to deploy the redis cluster so that 
-no two instances are located on the same host. 
-See [ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure) 
+The above example uses `PodAntiAffinity` rule with `topologyKey: "kubernetes.io/hostname"` to deploy the redis cluster so that
+no two instances are located on the same host.
+See [ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)
 for an example of a StatefulSet configured with anti-affinity for high availability, using the same technique.

-For more information on inter-pod affinity/anti-affinity, see the 
+For more information on inter-pod affinity/anti-affinity, see the
 [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md).

 You may want to check [Taints](/docs/concepts/configuration/taint-and-toleration/)
@@ -10,7 +10,6 @@ feature:
 weight: 50
 ---

-{{< toc >}}

 {{% capture overview %}}

@@ -546,10 +545,10 @@ secret "test-db-secret" created
 ```
 {{< note >}}
 **Note:** Special characters such as `$`, `\*`, and `!` require escaping.
-If the password you are using has special characters, you need to escape them using the `\\` character. For example, if your actual password is `S!B\*d$zDsb`, you should execute the command this way: 
+If the password you are using has special characters, you need to escape them using the `\\` character. For example, if your actual password is `S!B\*d$zDsb`, you should execute the command this way:

    kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password=S\\!B\\\*d\\$zDsb
-    
+
 You do not need to escape special characters in passwords from files (`--from-file`).
 {{< /note >}}

@@ -773,7 +772,7 @@ Pod level](#use-case-secret-visible-to-one-container-in-a-pod).
   by impersonating the kubelet.  It is a planned feature to only send secrets to
   nodes that actually require them, to restrict the impact of a root exploit on a
   single node.
-  
+
 {{< note >}}
 **Note:** As of 1.7 [encryption of secret data at rest is supported](/docs/tasks/administer-cluster/encrypt-data/).
 {{< /note >}}
@@ -8,7 +8,6 @@ content_template: templates/concept
 weight: 40
 ---

-{{< toc >}}

 {{% capture overview %}}
 Node affinity, described [here](/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature),
@@ -13,7 +13,6 @@ This page describes the resources available to Containers in the Container envir

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -63,5 +62,3 @@ if [DNS addon](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addon
  [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).

 {{% /capture %}}
-
-
@@ -14,7 +14,6 @@ to run code triggered by events during their management lifecycle.

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -122,5 +121,3 @@ Events:
  [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).

 {{% /capture %}}
-
-
@@ -15,7 +15,6 @@ The `image` property of a container supports the same syntax as the `docker` com

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -50,7 +49,7 @@ These commands rely on and are implemented purely on the Docker CLI. You will ne

 If you run into trouble with uploading stale manifests, just clean up the older manifests in `$HOME/.docker/manifests` to start fresh.

-For Kubernetes, we have typically used images with suffix `-$(ARCH)`. For backward compatability, please generate the older images with suffixes. The idea is to generate say `pause` image which has the manifest for all the arch(es) and say `pause-amd64` which is backwards compatible for older configurations or YAML files which may have hard coded the images with suffixes.
+For Kubernetes, we have typically used images with suffix `-$(ARCH)`. For backward compatibility, please generate the older images with suffixes. The idea is to generate say `pause` image which has the manifest for all the arch(es) and say `pause-amd64` which is backwards compatible for older configurations or YAML files which may have hard coded the images with suffixes.

 ## Using a Private Registry

@@ -140,7 +140,6 @@ This page describes the RuntimeClass resource and runtime selection mechanism.

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -8,7 +8,6 @@ content_template: templates/concept
 weight: 10
 ---

-{{< toc >}}

 {{% capture overview %}}

@@ -22,7 +22,6 @@ Kubernetes itself is decomposed into multiple components, which interact through

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -26,7 +26,6 @@ We'll eventually index and reverse-index labels for efficient queries and watche

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -202,4 +201,4 @@ selector:
 One use case for selecting over labels is to constrain the set of nodes onto which a pod can schedule.
 See the documentation on [node selection](/docs/concepts/configuration/assign-pod-node/) for more information.

-{{% /capture %}}
+{{% /capture %}}
@@ -17,7 +17,6 @@ See the [identifiers design doc](https://git.k8s.io/community/contributors/desig

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -31,4 +30,4 @@ By convention, the names of Kubernetes resources should be up to maximum length

 {{< glossary_definition term_id="uid" length="all" >}}

-{{% /capture %}}
+{{% /capture %}}
@@ -15,7 +15,6 @@ These virtual clusters are called namespaces.

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -16,7 +16,6 @@ updates.

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -145,7 +144,7 @@ For a complete example of authorizing a PodSecurityPolicy, see
 ### Troubleshooting

 - The [Controller Manager](/docs/admin/kube-controller-manager/) must be run
-against [the secured API port](/docs/reference/access-authn-authz/controlling-access/), 
+against [the secured API port](/docs/reference/access-authn-authz/controlling-access/),
 and must not have superuser permissions. Otherwise requests would bypass
 authentication and authorization modules, all PodSecurityPolicy objects would be
 allowed, and users would be able to create privileged containers. For more details
@@ -375,7 +374,7 @@ several security mechanisms.
 ### Privileged

 **Privileged** - determines if any container in a pod can enable privileged mode.
-By default a container is not allowed to access any devices on the host, but a 
+By default a container is not allowed to access any devices on the host, but a
 "privileged" container is given access to all devices on the host. This allows
 the container nearly all the same access as processes running on the host.
 This is useful for containers that want to use linux capabilities like
@@ -443,11 +442,11 @@ allowedHostPaths:
    readOnly: true # only allow read-only mounts
 ```

-{{< warning >}}**Warning:** There are many ways a container with unrestricted access to the host 
+{{< warning >}}**Warning:** There are many ways a container with unrestricted access to the host
 filesystem can escalate privileges, including reading data from other
 containers, and abusing the credentials of system services, such as Kubelet.

-Writeable hostPath directory volumes allow containers to write 
+Writeable hostPath directory volumes allow containers to write
 to the filesystem in ways that let them traverse the host filesystem outside the `pathPrefix`.
 `readOnly: true`, available in Kubernetes 1.11+, must be used on **all** `allowedHostPaths`
 to effectively limit access to the specified `pathPrefix`.
@@ -460,7 +459,7 @@ root filesystem (i.e. no writable layer).

 This specifies a whiltelist of Flexvolume drivers that are allowed to be used
 by flexvolume. An empty list or nil means there is no restriction on the drivers.
-Please make sure [`volumes`](#volumes-and-file-systems) field  contains the
+Please make sure [`volumes`](#volumes-and-file-systems) field contains the
 `flexVolume` volume type; no Flexvolume driver is allowed otherwise.

 For example:
@@ -474,7 +473,7 @@ spec:
  # ... other spec fields
  volumes:
    - flexVolume
-  allowedFlexVolumes: 
+  allowedFlexVolumes:
    - driver: example/lvm
    - driver: example/cifs
 ```
@@ -569,15 +568,15 @@ specified.
 ### AllowedProcMountTypes

 `allowedProcMountTypes` is a whitelist of allowed ProcMountTypes.
-Empty or nil indicates that only the `DefaultProcMountType` may be used. 
+Empty or nil indicates that only the `DefaultProcMountType` may be used.

 `DefaultProcMount` uses the container runtime defaults for readonly and masked
 paths for /proc.  Most container runtimes mask certain paths in /proc to avoid
 accidental security exposure of special devices or information. This is denoted
 as the string `Default`.

-The only other ProcMountType is `UnmaskedProcMount`, which bypasses the 
-default masking behavior of the container runtime and ensures the newly 
+The only other ProcMountType is `UnmaskedProcMount`, which bypasses the
+default masking behavior of the container runtime and ensures the newly
 created /proc the container stays in tact with no modifications. This is
 denoted as the string `Unmasked`.

@@ -15,7 +15,6 @@ Resource quotas are a tool for administrators to address this concern.

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -8,7 +8,6 @@ content_template: templates/concept
 weight: 30
 ---

-{{< toc >}}

 {{% capture overview %}}

@@ -208,7 +207,7 @@ Till now we have only accessed the nginx server from within the cluster. Before
 * An nginx server configured to use the certificates
 * A [secret](/docs/concepts/configuration/secret/) that makes the certificates accessible to pods

-You can acquire all these from the [nginx https example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/). This requires having go and make tools installed. If you don't want to install those, then follow the  manual steps later. In short:
+You can acquire all these from the [nginx https example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/). This requires having go and make tools installed. If you don't want to install those, then follow the manual steps later. In short:

 ```shell
 $ make keys secret KEY=/tmp/nginx.key CERT=/tmp/nginx.crt SECRET=/tmp/secret.json
@@ -375,4 +374,3 @@ the [Federated Services User Guide](/docs/concepts/cluster-administration/federa
 for further information.

 {{% /capture %}}
-
@@ -11,7 +11,6 @@ content_template: templates/concept
 weight: 10
 ---

-{{< toc >}}

 {{% capture overview %}}

@@ -88,7 +87,7 @@ Kubernetes `Services` support `TCP`, `UDP` and `SCTP` for protocols.  The defaul
 is `TCP`.

 {{< note >}}
-**Note:** SCTP support is an alpha feature since Kubernetes 1.12 
+**Note:** SCTP support is an alpha feature since Kubernetes 1.12
 {{< /note >}}

 ### Services without selectors
@@ -196,7 +195,7 @@ having working [readiness probes](/docs/tasks/configure-pod-container/configure-

 In this mode, kube-proxy watches Kubernetes Services and Endpoints,
 calls `netlink` interface to create ipvs rules accordingly and syncs ipvs rules with Kubernetes
-Services and Endpoints  periodically, to make sure ipvs status is
+Services and Endpoints periodically, to make sure ipvs status is
 consistent with the expectation. When Service is accessed, traffic will
 be redirected to one of the backend Pods.

@@ -461,7 +460,7 @@ group of the other automatically created resources of the cluster. For example,

 {{< note >}}
 **Note:** The support of SCTP in the cloud provider's load balancer is up to the cloud provider's
-load balancer implementation. If SCTP is not supported by the cloud provider's load balancer the 
+load balancer implementation. If SCTP is not supported by the cloud provider's load balancer the
 Service creation request is accepted but the creation of the load balancer fails.
 {{< /note >}}

@@ -938,9 +937,9 @@ Kubernetes supports SCTP as a `protocol` value in `Service`, `Endpoint`, `Networ

 #### The support of multihomed SCTP associations

-The support of multihomed SCTP associations requires that the CNI plugin can support the assignment of multiple interfaces and IP addresses to a `Pod`. 
+The support of multihomed SCTP associations requires that the CNI plugin can support the assignment of multiple interfaces and IP addresses to a `Pod`.

-NAT for multihomed SCTP assoications requires special logic in the corresponding kernel modules.
+NAT for multihomed SCTP associations requires special logic in the corresponding kernel modules.

 #### Service with type=LoadBalancer

@@ -961,4 +960,3 @@ The kube-proxy does not support the management of SCTP associations when it is i
 Read [Connecting a Front End to a Back End Using a Service](/docs/tasks/access-application-cluster/connecting-frontend-backend/).

 {{% /capture %}}
-
@@ -21,7 +21,6 @@ automatically provisions storage when it is requested by users.

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -132,5 +131,3 @@ Pods are scheduled. This can be accomplished by setting the [Volume Binding
 Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode).

 {{% /capture %}}
-
-
@@ -8,7 +8,7 @@ title: Persistent Volumes
 feature:
  title: Storage orchestration
  description: >
-    Automatically mount the storage system of your choice, whether from local storage, a public cloud provider  such as <a href="https://cloud.google.com/storage/">GCP</a> or <a href="https://aws.amazon.com/products/storage/">AWS</a>, or a network storage system such as NFS, iSCSI, Gluster, Ceph, Cinder, or Flocker.
+    Automatically mount the storage system of your choice, whether from local storage, a public cloud provider such as <a href="https://cloud.google.com/storage/">GCP</a> or <a href="https://aws.amazon.com/products/storage/">AWS</a>, or a network storage system such as NFS, iSCSI, Gluster, Ceph, Cinder, or Flocker.

 content_template: templates/concept
 weight: 20
@@ -20,7 +20,6 @@ This document describes the current state of `PersistentVolumes` in Kubernetes.

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -674,7 +673,7 @@ and need persistent storage, we recommend that you use the following pattern:
    `persistentVolumeClaim.storageClassName` field.
    This will cause the PVC to match the right storage
    class if the cluster has StorageClasses enabled by the admin.
-  - If the user does not provide a storage class name, leave the 
+  - If the user does not provide a storage class name, leave the
    `persistentVolumeClaim.storageClassName` field as nil.
    - This will cause a PV to be automatically provisioned for the user with
      the default StorageClass in the cluster.  Many cluster environments have
@@ -4,7 +4,7 @@ reviewers:
 - saad-ali
 - thockin
 - msau42
-title: Volume Snapshot Classes 
+title: Volume Snapshot Classes
 content_template: templates/concept
 weight: 30
 ---
@@ -17,7 +17,6 @@ with [volume snapshots](/docs/concepts/storage/volume-snapshots/) and

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -15,7 +15,6 @@ This document describes the current state of `VolumeSnapshots` in Kubernetes. Fa

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -23,7 +22,7 @@ This document describes the current state of `VolumeSnapshots` in Kubernetes. Fa

 Similar to how API resources `PersistentVolume` and `PersistentVolumeClaim` are used to provision volumes for users and administrators, `VolumeSnapshotContent` and `VolumeSnapshot` API resources are provided to create volume snapshots for users and administrators.

-A `VolumeSnapshotContent` is a snapshot taken from a volume in the cluster that has been provisioned by an administrator. It is a resource in the cluster just like a PersistentVolume is a cluster resource. 
+A `VolumeSnapshotContent` is a snapshot taken from a volume in the cluster that has been provisioned by an administrator. It is a resource in the cluster just like a PersistentVolume is a cluster resource.

 A `VolumeSnapshot` is a request for snapshot of a volume by a user. It is similar to a PersistentVolumeClaim.

@@ -81,7 +80,7 @@ metadata:
 spec:
  snapshotClassName: csi-hostpath-snapclass
  source:
-    name: pvc-test 
+    name: pvc-test
    kind: PersistentVolumeClaim
  volumeSnapshotSource:
    csiVolumeSnapshotSource:
@@ -22,7 +22,6 @@ Familiarity with [Pods](/docs/user-guide/pods) is suggested.

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -925,7 +924,7 @@ A `storageos` volume allows an existing [StorageOS](https://www.storageos.com)
 volume to be mounted into your Pod.

 StorageOS runs as a Container within your Kubernetes environment, making local
-or attached storage accessible from any node within the Kubernetes cluster. 
+or attached storage accessible from any node within the Kubernetes cluster.
 Data can be replicated to protect against node failure. Thin provisioning and
 compression can improve utilization and reduce cost.

@@ -1053,7 +1052,7 @@ spec:
      image: mysql
      env:
      - name: MYSQL_ROOT_PASSWORD
-        value: "rootpasswd" 
+        value: "rootpasswd"
      volumeMounts:
      - mountPath: /var/lib/mysql
        name: site-data
@@ -1103,7 +1102,7 @@ spec:
  restartPolicy: Never
  volumes:
  - name: workdir1
-    hostPath: 
+    hostPath:
      path: /var/log/pods
 ```

@@ -1123,7 +1122,7 @@ several media types.
 ## Out-of-Tree Volume Plugins
 The Out-of-tree volume plugins include the Container Storage Interface (CSI)
 and Flexvolume. They enable storage vendors to create custom storage plugins
-without adding them to the Kubernetes repository. 
+without adding them to the Kubernetes repository.

 Before the introduction of CSI and Flexvolume, all volume plugins (like
 volume types listed above) were "in-tree" meaning they were built, linked,
@@ -1210,8 +1209,8 @@ persistent volume:
 {{< feature-state for_k8s_version="v1.11" state="alpha" >}}

 Starting with version 1.11, CSI introduced support for raw block volumes, which
-relies on the raw block volume feature that was introduced in a previous version of 
-Kubernetes.  This feature will make it possible for vendors with external CSI drivers to 
+relies on the raw block volume feature that was introduced in a previous version of
+Kubernetes.  This feature will make it possible for vendors with external CSI drivers to
 implement raw block volumes support in Kubernetes workloads.

 CSI block volume support is feature-gated and turned off by default.  To run CSI with
@@ -1222,7 +1221,7 @@ Kubernetes component using the following feature gate flags:
 --feature-gates=BlockVolume=true,CSIBlockVolume=true
 ```

-Learn how to 
+Learn how to
 [setup your PV/PVC with raw block volume support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support).

 ### Flexvolume
@@ -1283,7 +1282,7 @@ In addition, any volume mounts created by Containers in Pods must be destroyed
 {{< /caution >}}

 ### Configuration
-Before mount propagation can work properly on some deployments (CoreOS, 
+Before mount propagation can work properly on some deployments (CoreOS,
 RedHat/Centos, Ubuntu) mount share must be configured correctly in
 Docker as shown below.

@@ -1302,5 +1301,3 @@ $ sudo systemctl restart docker
 {{% capture whatsnext %}}
 * Follow an example of [deploying WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/).
 {{% /capture %}}
-
-
@@ -16,13 +16,12 @@ One CronJob object is like one line of a _crontab_ (cron table) file. It runs a
 on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format.
 {{< note >}}
 **Note:** All **CronJob** `schedule:` times are denoted in UTC.
-{{< /note >}} 
+{{< /note >}}

 For instructions on creating and working with cron jobs, and for an example of a spec file for a cron job, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs).

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -42,7 +41,7 @@ For every CronJob, the CronJob controller checks how many schedules it missed in
 Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew.
 ````

-It is important to note that if the `startingDeadlineSeconds` field is set (not `nil`), the controller counts how many missed jobs occurred from the value of `startingDeadlineSeconds` until now rather than from the last scheduled time until now. For example, if `startingDeadlineSeconds` is `200`, the controller counts how many missed jobs occurred in the last 200 seconds. 
+It is important to note that if the `startingDeadlineSeconds` field is set (not `nil`), the controller counts how many missed jobs occurred from the value of `startingDeadlineSeconds` until now rather than from the last scheduled time until now. For example, if `startingDeadlineSeconds` is `200`, the controller counts how many missed jobs occurred in the last 200 seconds.

 A CronJob is counted as missed if it has failed to be created at its scheduled time. For example, If `concurrencyPolicy` is set to `Forbid` and a CronJob was attempted to be scheduled when there was a previous schedule still running, then it would count as missed.

@@ -21,7 +21,7 @@ Some typical uses of a DaemonSet are:
 - running a cluster storage daemon, such as `glusterd`, `ceph`, on each node.
 - running a logs collection daemon on every node, such as `fluentd` or `logstash`.
 - running a node monitoring daemon on every node, such as [Prometheus Node Exporter](
-  https://github.com/prometheus/node_exporter), `collectd`, Dynatrace OneAgent, Datadog agent, New Relic agent, Ganglia `gmond` or Instana agent.
+  https://github.com/prometheus/node_exporter), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), Datadog agent, New Relic agent, Ganglia `gmond` or Instana agent.

 In a simple case, one DaemonSet, covering all nodes, would be used for each type of daemon.
 A more complex setup might use multiple DaemonSets for a single type of daemon, but with
@@ -29,7 +29,6 @@ different flags and/or different memory and cpu requests for different hardware

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -130,7 +129,7 @@ That introduces the following issues:
 * [Pod preemption](/docs/concepts/configuration/pod-priority-preemption/)
   is handled by default scheduler. When preemption is enabled, the DaemonSet controller
   will make scheduling decisions without considering pod priority and preemption.
- 
+
 `ScheduleDaemonSetPods` allows you to schedule DaemonSets using the default
 scheduler instead of the DaemonSet controller, by adding the `NodeAffinity` term
 to the DaemonSet pods, instead of the `.spec.nodeName` term. The default
@@ -107,7 +107,7 @@ Notice how the values in each field correspond to the values in the Deployment s
 * The number of up-to-date replicas is 0 according to the `.status.updatedReplicas` field.
 * The number of available replicas is 0 according to the `.status.availableReplicas` field.

-To see the Deployment rollout status, run `kubectl rollout status deployment/nginx-deployment`. This command returns the following output:
+To see the Deployment rollout status, run `kubectl rollout status deployment.v1.apps/nginx-deployment`. This command returns the following output:

 ```shell
 Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
@@ -171,21 +171,21 @@ Suppose that you now want to update the nginx Pods to use the `nginx:1.9.1` imag
 instead of the `nginx:1.7.9` image.

 ```shell
-$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 --record
+$ kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record
 deployment.apps/nginx-deployment image updated
 ```

 Alternatively, you can `edit` the Deployment and change `.spec.template.spec.containers[0].image` from `nginx:1.7.9` to `nginx:1.9.1`:

 ```shell
-$ kubectl edit deployment/nginx-deployment
+$ kubectl edit deployment.v1.apps/nginx-deployment
 deployment.apps/nginx-deployment edited
 ```

 To see the rollout status, run:

 ```shell
-$ kubectl rollout status deployment/nginx-deployment
+$ kubectl rollout status deployment.v1.apps/nginx-deployment
 Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
 deployment.apps/nginx-deployment successfully rolled out
 ```
@@ -337,48 +337,45 @@ rolled back.
 Suppose that you made a typo while updating the Deployment, by putting the image name as `nginx:1.91` instead of `nginx:1.9.1`:

 ```shell
-$ kubectl set image deployment/nginx-deployment nginx=nginx:1.91
+$ kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true
 deployment.apps/nginx-deployment image updated
 ```

 The rollout will be stuck.

 ```shell
-$ kubectl rollout status deployments nginx-deployment
-Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
+$ kubectl rollout status deployment.v1.apps/nginx-deployment
+Waiting for rollout to finish: 1 out of 3 new replicas have been updated...
 ```

 Press Ctrl-C to stop the above rollout status watch. For more information on stuck rollouts,
 [read more here](#deployment-status).

-You will also see that both the number of old replicas (nginx-deployment-1564180365 and
-nginx-deployment-2035384211) and new replicas (nginx-deployment-3066724191) are 2.
+You will see that the number of old replicas (nginx-deployment-1564180365 and nginx-deployment-2035384211) is 2, and new replicas (nginx-deployment-3066724191) is 1.

 ```shell
 $ kubectl get rs
 NAME                          DESIRED   CURRENT   READY   AGE
-nginx-deployment-1564180365   2         2         2       25s
+nginx-deployment-1564180365   3         3         3       25s
 nginx-deployment-2035384211   0         0         0       36s
-nginx-deployment-3066724191   2         2         0       6s
+nginx-deployment-3066724191   1         1         0       6s
 ```

-Looking at the Pods created, you will see that the 2 Pods created by new ReplicaSet are stuck in an image pull loop.
+Looking at the Pods created, you will see that 1 Pod created by new ReplicaSet is stuck in an image pull loop.

 ```shell
 $ kubectl get pods
 NAME                                READY     STATUS             RESTARTS   AGE
 nginx-deployment-1564180365-70iae   1/1       Running            0          25s
 nginx-deployment-1564180365-jbqqo   1/1       Running            0          25s
+nginx-deployment-1564180365-hysrc   1/1       Running            0          25s
 nginx-deployment-3066724191-08mng   0/1       ImagePullBackOff   0          6s
-nginx-deployment-3066724191-eocby   0/1       ImagePullBackOff   0          6s
 ```

 {{< note >}}
 **Note:** The Deployment controller will stop the bad rollout automatically, and will stop scaling up the new
 ReplicaSet. This depends on the rollingUpdate parameters (`maxUnavailable` specifically) that you have specified.
-Kubernetes by default sets the value to 1 and `.spec.replicas` to 1 so if you haven't cared about setting those
-parameters, your Deployment can have 100% unavailability by default! This will be fixed in Kubernetes in a future
-version.
+Kubernetes by default sets the value to 25%.
 {{< /note >}}

 ```shell
@@ -388,12 +385,27 @@ Namespace:      default
 CreationTimestamp:  Tue, 15 Mar 2016 14:48:04 -0700
 Labels:         app=nginx
 Selector:       app=nginx
-Replicas:       2 updated | 3 total | 2 available | 2 unavailable
+Replicas:       3 desired | 1 updated | 4 total | 3 available | 1 unavailable
 StrategyType:       RollingUpdate
 MinReadySeconds:    0
-RollingUpdateStrategy:  1 max unavailable, 1 max surge
-OldReplicaSets:     nginx-deployment-1564180365 (2/2 replicas created)
-NewReplicaSet:      nginx-deployment-3066724191 (2/2 replicas created)
+RollingUpdateStrategy:  25% max unavailable, 25% max surge
+Pod Template:
+  Labels:  app=nginx
+  Containers:
+   nginx:
+    Image:        nginx:1.91
+    Port:         80/TCP
+    Host Port:    0/TCP
+    Environment:  <none>
+    Mounts:       <none>
+  Volumes:        <none>
+Conditions:
+  Type           Status  Reason
+  ----           ------  ------
+  Available      True    MinimumReplicasAvailable
+  Progressing    True    ReplicaSetUpdated
+OldReplicaSets:     nginx-deployment-1564180365 (3/3 replicas created)
+NewReplicaSet:      nginx-deployment-3066724191 (1/1 replicas created)
 Events:
  FirstSeen LastSeen    Count   From                    SubobjectPath   Type        Reason              Message
  --------- --------    -----   ----                    -------------   --------    ------              -------
@@ -401,11 +413,10 @@ Events:
  22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 1
  22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 2
  22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 2
-  21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 0
+  21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 1
  21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 3
+  13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 0
  13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 1
-  13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-1564180365 to 2
-  13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 2
 ```

 To fix this, you need to rollback to a previous revision of Deployment that is stable.
@@ -415,27 +426,27 @@ To fix this, you need to rollback to a previous revision of Deployment that is s
 First, check the revisions of this deployment:

 ```shell
-$ kubectl rollout history deployment/nginx-deployment
+$ kubectl rollout history deployment.v1.apps/nginx-deployment
 deployments "nginx-deployment"
 REVISION    CHANGE-CAUSE
 1           kubectl create --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true
-2           kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 --record=true
-3           kubectl set image deployment/nginx-deployment nginx=nginx:1.91 --record=true
+2           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
+3           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true
 ```
 `CHANGE-CAUSE` is copied from the Deployment annotation `kubernetes.io/change-cause` to its revisions upon creation. You could specify the`CHANGE-CAUSE` message by:

-* Annotating the Deployment with `kubectl annotate deploy nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"`
+* Annotating the Deployment with `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"`
 * Append the `--record` flag to save the `kubectl` command that is making changes to the resource.
 * Manually editing the manifest of the resource.

 To further see the details of each revision, run:

 ```shell
-$ kubectl rollout history deployment/nginx-deployment --revision=2
+$ kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2
 deployments "nginx-deployment" revision 2
  Labels:       app=nginx
          pod-template-hash=1159050644
-  Annotations:  kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 --record=true
+  Annotations:  kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
  Containers:
   nginx:
    Image:      nginx:1.9.1
@@ -452,14 +463,14 @@ deployments "nginx-deployment" revision 2
 Now you've decided to undo the current rollout and rollback to the previous revision:

 ```shell
-$ kubectl rollout undo deployment/nginx-deployment
+$ kubectl rollout undo deployment.v1.apps/nginx-deployment
 deployment.apps/nginx-deployment
 ```

 Alternatively, you can rollback to a specific revision by specify that in `--to-revision`:

 ```shell
-$ kubectl rollout undo deployment/nginx-deployment --to-revision=2
+$ kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2
 deployment.apps/nginx-deployment
 ```

@@ -479,7 +490,7 @@ Namespace:              default
 CreationTimestamp:      Sun, 02 Sep 2018 18:17:55 -0500
 Labels:                 app=nginx
 Annotations:            deployment.kubernetes.io/revision=4
-                        kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 --record=true
+                        kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
 Selector:               app=nginx
 Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
 StrategyType:           RollingUpdate
@@ -522,7 +533,7 @@ Events:
 You can scale a Deployment by using the following command:

 ```shell
-$ kubectl scale deployment nginx-deployment --replicas=10
+$ kubectl scale deployment.v1.apps/nginx-deployment --replicas=10
 deployment.apps/nginx-deployment scaled
 ```

@@ -531,7 +542,7 @@ in your cluster, you can setup an autoscaler for your Deployment and choose the
 Pods you want to run based on the CPU utilization of your existing Pods.

 ```shell
-$ kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80
+$ kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80
 deployment.apps/nginx-deployment scaled
 ```

@@ -553,7 +564,7 @@ nginx-deployment     10        10        10           10          50s
 You update to a new image which happens to be unresolvable from inside the cluster.

 ```shell
-$ kubectl set image deploy/nginx-deployment nginx=nginx:sometag
+$ kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag
 deployment.apps/nginx-deployment image updated
 ```

@@ -607,21 +618,21 @@ nginx-2142116321   3         3         3         1m
 Pause by running the following command:

 ```shell
-$ kubectl rollout pause deployment/nginx-deployment
+$ kubectl rollout pause deployment.v1.apps/nginx-deployment
 deployment.apps/nginx-deployment paused
 ```

 Then update the image of the Deployment:

 ```shell
-$ kubectl set image deploy/nginx-deployment nginx=nginx:1.9.1
+$ kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
 deployment.apps/nginx-deployment image updated
 ```

 Notice that no new rollout started:

 ```shell
-$ kubectl rollout history deploy/nginx-deployment
+$ kubectl rollout history deployment.v1.apps/nginx-deployment
 deployments "nginx"
 REVISION  CHANGE-CAUSE
 1   <none>
@@ -634,7 +645,7 @@ nginx-2142116321   3         3         3         2m
 You can make as many updates as you wish, for example, update the resources that will be used:

 ```shell
-$ kubectl set resources deployment nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
+$ kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
 deployment.apps/nginx-deployment resource requirements updated
 ```

@@ -644,7 +655,7 @@ the Deployment will not have any effect as long as the Deployment is paused.
 Eventually, resume the Deployment and observe a new ReplicaSet coming up with all the new updates:

 ```shell
-$ kubectl rollout resume deploy/nginx-deployment
+$ kubectl rollout resume deployment.v1.apps/nginx-deployment
 deployment.apps/nginx-deployment resumed
 $ kubectl get rs -w
 NAME               DESIRED   CURRENT   READY     AGE
@@ -702,7 +713,7 @@ You can check if a Deployment has completed by using `kubectl rollout status`. I
 successfully, `kubectl rollout status` returns a zero exit code.

 ```shell
-$ kubectl rollout status deploy/nginx-deployment
+$ kubectl rollout status deployment.v1.apps/nginx-deployment
 Waiting for rollout to finish: 2 of 3 updated replicas are available...
 deployment.apps/nginx-deployment successfully rolled out
 $ echo $?
@@ -730,7 +741,7 @@ The following `kubectl` command sets the spec with `progressDeadlineSeconds` to
 lack of progress for a Deployment after 10 minutes:

 ```shell
-$ kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
+$ kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
 deployment.apps/nginx-deployment patched
 ```
 Once the deadline has been exceeded, the Deployment controller adds a DeploymentCondition with the following
@@ -835,7 +846,7 @@ You can check if a Deployment has failed to progress by using `kubectl rollout s
 returns a non-zero exit code if the Deployment has exceeded the progression deadline.

 ```shell
-$ kubectl rollout status deploy/nginx-deployment
+$ kubectl rollout status deployment.v1.apps/nginx-deployment
 Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
 error: deployment "nginx" exceeded its progress deadline
 $ echo $?
@@ -26,7 +26,6 @@ A Job can also be used to run multiple pods in parallel.

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -223,7 +222,7 @@ Do this by setting the `.spec.activeDeadlineSeconds` field of the Job to a numbe

 The `activeDeadlineSeconds` applies to the duration of the job, no matter how many Pods are created.
 Once a Job reaches `activeDeadlineSeconds`, the Job and all of its Pods are terminated.
-The result is that the job has a status with `reason: DeadlineExceeded`. 
+The result is that the job has a status with `reason: DeadlineExceeded`.

 Note that a Job's `.spec.activeDeadlineSeconds` takes precedence over its `.spec.backoffLimit`. Therefore, a Job that is retrying one or more failed Pods will not deploy additional Pods once it reaches the time limit specified by `activeDeadlineSeconds`, even if the `backoffLimit` is not yet reached.

@@ -252,7 +251,7 @@ Note that both the Job Spec and the [Pod Template Spec](https://kubernetes.io/do

 Finished Jobs are usually no longer needed in the system. Keeping them around in
 the system will put pressure on the API server. If the Jobs are managed directly
-by a higher level controller, such as 
+by a higher level controller, such as
 [CronJobs](/docs/concepts/workloads/controllers/cron-jobs/), the Jobs can be
 cleaned up by CronJobs based on the specified capacity-based cleanup policy.

@@ -261,7 +260,7 @@ cleaned up by CronJobs based on the specified capacity-based cleanup policy.
 {{< feature-state for_k8s_version="v1.12" state="alpha" >}}

 Another way to clean up finished Jobs (either `Complete` or `Failed`)
-automatically is to use a TTL mechanism provided by a 
+automatically is to use a TTL mechanism provided by a
 [TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) for
 finished resources, by specifying the `.spec.ttlSecondsAfterFinished` field of
 the Job.
@@ -290,16 +289,16 @@ spec:
 ```

 The Job `pi-with-ttl` will be eligible to be automatically deleted, `100`
-seconds after it finishes. 
+seconds after it finishes.

 If the field is set to `0`, the Job will be eligible to be automatically deleted
 immediately after it finishes. If the field is unset, this Job won't be cleaned
 up by the TTL controller after it finishes.

 Note that this TTL mechanism is alpha, with feature gate `TTLAfterFinished`. For
-more information, see the documentation for 
+more information, see the documentation for
 [TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) for
-finished resources. 
+finished resources.

 ## Job Patterns

@@ -24,7 +24,6 @@ Alpha Disclaimer: this feature is currently alpha, and can be enabled with
 {{% /capture %}}


-{{< toc >}}


 {{% capture body %}}
@@ -34,7 +33,7 @@ Alpha Disclaimer: this feature is currently alpha, and can be enabled with
 The TTL controller only supports Jobs for now. A cluster operator can use this feature to clean
 up finished Jobs (either `Complete` or `Failed`) automatically by specifying the
 `.spec.ttlSecondsAfterFinished` field of a Job, as in this
-[example](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically). 
+[example](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically).
 The TTL controller will assume that a resource is eligible to be cleaned up
 TTL seconds after the resource has finished, in other words, when the TTL has expired. When the
 TTL controller cleans up a resource, it will delete it cascadingly, i.e. delete
@@ -18,7 +18,6 @@ cluster actions, like upgrading and autoscaling clusters.

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -266,6 +265,3 @@ the nodes in your cluster, such as a node or system software upgrade, here are s
 * Learn more about [draining nodes](/docs/tasks/administer-cluster/safely-drain-node/)

 {{% /capture %}}
-
-
-
@@ -12,7 +12,6 @@ Containers that run before app Containers and can contain utilities or setup
 scripts not present in an app image.
 {{% /capture %}}

-{{< toc >}}

 This feature has exited beta in 1.6. Init Containers can be specified in the PodSpec
 alongside the app `containers` array. The beta annotation value will still be respected
@@ -329,6 +328,3 @@ is removed, requiring a conversion from the deprecated annotations to the
 * [Creating a Pod that has an Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)

 {{% /capture %}}
-
-
-
@@ -10,7 +10,6 @@ weight: 10
 This page provides an overview of `Pod`, the smallest deployable object in the Kubernetes object model.
 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}
 ## Understanding Pods
@@ -104,5 +103,3 @@ Rather than specifying the current desired state of all replicas, pod templates
  * [Pod Termination](/docs/concepts/workloads/pods/pod/#termination-of-pods)
  * Other Pod Topics
 {{% /capture %}}
-
-
@@ -12,7 +12,6 @@ managed in Kubernetes.

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -12,7 +12,6 @@ certain information into pods at creation time. The information can include
 secrets, volumes, volume mounts, and environment variables.
 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}
 ## Understanding Pod Presets
@@ -22,7 +21,7 @@ into a Pod at creation time.
 You use [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors)
 to specify the Pods to which a given Pod Preset applies.

-Using a Pod Preset allows pod template authors to not have to explicitly provide 
+Using a Pod Preset allows pod template authors to not have to explicitly provide
 all information for every pod. This way, authors of pod templates consuming a
 specific service do not need to know all the details about that service.

@@ -53,7 +52,7 @@ the Pod; for changes to `Volume`, Kubernetes modifies the Pod Spec.

 {{< note >}}
 **Note:** A Pod Preset is capable of modifying the `.spec.containers` field in a
-Pod spec when appropriate. *No* resource definition from the Pod Preset will be 
+Pod spec when appropriate. *No* resource definition from the Pod Preset will be
 applied to the `initContainers` field.
 {{< /note >}}

@@ -69,7 +68,7 @@ In order to use Pod Presets in your cluster you must ensure the following:

 1.  You have enabled the API type `settings.k8s.io/v1alpha1/podpreset`. For
    example, this can be done by including `settings.k8s.io/v1alpha1=true` in
-    the `--runtime-config` option for the API server. 
+    the `--runtime-config` option for the API server.
 1.  You have enabled the admission controller `PodPreset`. One way to doing this
    is to include `PodPreset` in the `--enable-admission-plugins` option value specified
    for the API server.
@@ -83,5 +82,3 @@ In order to use Pod Presets in your cluster you must ensure the following:
 * [Injecting data into a Pod using PodPreset](/docs/tasks/inject-data-application/podpreset/)

 {{% /capture %}}
-
-