+
+ “I would almost be so bold as to say that most of these applications that we are building now would not have been possible without the cloud native patterns and the flexibility that Kubernetes enables.”
— Brad Linder, Cloud Native & Big Data Evangelist for Sling TV
+
+
+
+
The beauty of streaming television, like the service offered by Sling TV, is that you can watch it from any device you want, wherever you want.
Of course, from the provider side of things, that creates a particular set of challenges
+“We take live TV and distribute it over the internet out to a user’s device that we do not control,” says Brad Linder, Sling TV’s Cloud Native & Big Data Evangelist. “In a lot of ways, we are working in the Wild West: The internet is what it is going to be, and if a customer’s service does not work for whatever reason, they do not care why. They just want things to work. Those are the variables of the equation that we have to try to solve. We really have to try to enable optionality and we have to do it at web scale.”
+Indeed, Sling TV experienced great customer growth from the beginning of its launch by
DISH Network in 2015. After just a year, “we were going through some growing pains of some of the legacy systems and trying to find the right architecture to enable our future,” says Linder. Tasked with building a next-generation web scale platform for the “personalized customer experience,” Linder has spent the past year bringing Kubernetes to Sling TV.
+Led by the belief that “the cloud native architectures and patterns really give us a lot of flexibility in meeting the needs of our customers,” Linder partnered with
Rancher Labs to build the platform around Kubernetes. “They have really helped us get our head around how to use Kubernetes,” he says. “We needed the flexibility to enable our use case versus just a simple orchestrater. Enabling our future in a way that did not give us vendor lock-in was also a key part of our strategy. I think that is part of the Rancher value proposition.”
+
+
+
+
+ “We needed the flexibility to enable our use case versus just a simple orchestrater. Enabling our future in a way that did not give us vendor lock-in was also a key part of our strategy. I think that is part of the Rancher value proposition.”
— Brad Linder, Cloud Native & Big Data Evangelist for Sling TV
+
+
+
+One big reason he chose Kubernetes was getting a level of abstraction that would enable the company to “enable a hybrid cloud strategy including multiple public clouds and an on-premise VMWare multi data center environment to meet the needs of the business,” he says. Another factor was how much the Kubernetes ecosystem has matured over the past couple of years. “We have spent a lot of time and energy around making logging, monitoring and alerting production ready to give us insights into applications’ well-being,” says Linder. The team has added
Prometheus for monitoring and
Jaeger for tracing, to work alongside the company’s existing tool sets: Zenoss, New Relic and ELK.
+With the emphasis on common tooling, “We are getting to the place where we can one-click deploy an entire data center – the compute, network, Kubernetes, logging, monitoring and all the apps,” says Linder. “We have really enabled a platform thinking based approach to allowing applications to consume common tools and services. A new application can be onboarded in about an hour using common tooling and CI/CD processes. The gains on that side have been huge. Before, it took at least a few days to get things sorted for a new application to deploy. That does not consider the training of our operations staff to manage this new application. It is two or three orders of magnitude of savings in time and cost, and operationally it has given us the opportunity to let a core team of talented operations engineers manage common infrastructure and tooling to make our applications available at web scale.”
+
+
+ The team launched its first applications on Kubernetes in Sling TV’s two internal data centers in the early part of Q1 2018 and began to enable AWS as a data center option. The company plans to expand into other public clouds in the future.
+The first application that went into production is a web socket-based back-end notification service. “It allows back-end changes to trigger messages to our clients in the field without the polling,” says Linder. “We are talking about very high volumes of messages with this application. Without something like Kubernetes to be able to scale up and down, as well as just support that overall workload, that is pretty hard to do. I would almost be so bold as to say that most of these applications that we are building now would not have been possible without the cloud native patterns and the flexibility that Kubernetes enables.”
+ Linder oversees three teams working together on building the next-generation platform: a platform engineering team; an enterprise middleware services team; and a big data and analytics team. “We have really tried to bring everything together to be able to have a client application interact with a cloud native middleware layer. That middleware layer must run on a platform, consume platform services and then have logs and events monitored by an artificial agent to keep things running smoothly,” says Linder.
+
+
+
+
+
+
+ This undertaking is about “trying to marry Kubernetes with AI to enable web scale that just works".
— BRAD LINDER, CLOUD NATIVE & BIG DATA EVANGELIST FOR SLING TV
+
+
+ Ultimately, this undertaking is about “trying to marry Kubernetes with AI to enable web scale that just works,” he adds. “We want the artificial agents and the big data platform using the actual logs and events coming out of the applications, Kubernetes, the infrastructure, backing services and changes to the environment to make decisions like, ‘Hey we need more capacity for this service so please add more nodes.’ From a platform perspective, if you are truly doing web scale stuff and you are not using AI and big data, in my opinion, you are going to implode under your own weight. It is not a question of if, it is when. If you are in a ‘millions of users’ sort of environment, that implosion is going to be catastrophic. We are on our way to this goal and have learned a lot along the way.”
+For Sling TV, moving to cloud native has been exactly what they needed. “We have to be able to react to changes and hiccups in the matrix,” says Linder. “It is the foundation for our ability to deliver a high-quality service for our customers. Building intelligent platforms, tools and clients in the field consuming those services has got to be part of all of this. In my eyes that is a big part of what cloud native is all about. It is taking these distributed, potentially unreliable entities and enabling a robust customer experience they expect.”
+
+
+
+
+
+
+
+
diff --git a/content/en/case-studies/workiva.html b/content/en/case-studies/workiva.html
new file mode 100644
index 000000000..6db4c3ecf
--- /dev/null
+++ b/content/en/case-studies/workiva.html
@@ -0,0 +1,107 @@
+---
+title: Workiva Case Study
+case_study_styles: true
+cid: caseStudies
+css: /css/style_case_studies.css
+---
+
+
+
+"With OpenTracing, my team was able to look at a trace and make optimization suggestions to another team without ever looking at their code."
— MacLeod Broad, Senior Software Architect at Workiva
+
+
+
+
Last fall, MacLeod Broad’s platform team at Workiva was prepping one of the company’s first products utilizing Amazon Web Services when they ran into a roadblock.
+ Early on, Workiva’s backend had run mostly on
Google App Engine. But things changed along the way as Workiva’s SaaS offering,
Wdesk, a cloud-based platform for managing and reporting business data, grew its customer base to more than 70 percent of the Fortune 500 companies. "As customer needs grew and the product offering expanded, we started to leverage a wider offering of services such as Amazon Web Services as well as other Google Cloud Platform services, creating a multi-vendor environment."
+With this new product, there was a "sync and link" feature by which data "went through a whole host of services starting with the new spreadsheet system [
Amazon Aurora] into what we called our linking system, and then pushed through http to our existing system, and then a number of calculations would go on, and the results would be transmitted back into the new system," says Broad. "We were trying to optimize that for speed. We thought we had made this great optimization and then it would turn out to be a micro optimization, which didn’t really affect the overall speed of things."
+The challenges faced by Broad’s team may sound familiar to other companies that have also made the shift from monoliths to more distributed, microservice-based systems. "We had a number of people working on this, all on different teams, so it was difficult to get our head around what the issues were and where the bottlenecks were," says Broad.
+ "Each service team was going through different iterations of their architecture and it was very hard to follow what was actually going on in each teams’ system," he adds. "We had circular dependencies where we’d have three or four different service teams unsure of where the issues really were, requiring a lot of back and forth communication. So we wasted a lot of time saying, ‘What part of this is slow? Which part of this is sometimes slow depending on the use case? Which part is degrading over time? Which part of this process is asynchronous so it doesn’t really matter if it’s long-running or not? What are we doing that’s redundant, and which part of this is buggy?’"
+
+
+
+
+ "A tracing system can at a glance explain an architecture, narrow down a performance bottleneck and zero in on it, and generally just help direct an investigation at a high level. Being able to do that at a glance is much faster than at a meeting or with three days of debugging, and it’s a lot faster than never figuring out the problem and just moving on."
— MACLEOD BROAD, SENIOR SOFTWARE ARCHITECT AT WORKIVA
+
+
+
+Simply put, it was an ideal use case for tracing. "A tracing system can at a glance explain an architecture, narrow down a performance bottleneck and zero in on it, and generally just help direct an investigation at a high level," says Broad. "Being able to do that at a glance is much faster than at a meeting or with three days of debugging, and it’s a lot faster than never figuring out the problem and just moving on."
+With Workiva’s back-end code running on
Google Compute Engine as well as App Engine and AWS, Broad knew that he needed a tracing system that was platform agnostic. "We were looking at different tracing solutions," he says, "and we decided that because it seemed to be a very evolving market, we didn’t want to get stuck with one vendor. So OpenTracing seemed like the cleanest way to avoid vendor lock-in on what backend we actually had to use."
+Once they introduced OpenTracing into this first use case, Broad says, "The trace made it super obvious where the bottlenecks were." Even though everyone had assumed it was Workiva’s existing code that was slowing things down, that wasn’t exactly the case. "It looked like the existing code was slow only because it was reaching out to our next-generation services, and they were taking a very long time to service all those requests," says Broad. "On the waterfall graph you can see the exact same work being done on every request when it was calling back in. So every service request would look the exact same for every response being paged out. And then it was just a no-brainer of, ‘Why is it doing all this work again?’"
+Using the insight OpenTracing gave them, "My team was able to look at a trace and make optimization suggestions to another team without ever looking at their code," says Broad. "The way we named our traces gave us insight whether it’s doing a SQL call or it’s making an RPC. And so it was really easy to say, ‘OK, we know that it’s going to page through all these requests. Do the work once and stuff it in cache.’ And we were done basically. All those calls became sub-second calls immediately."
+
+
+
+
+
+"We were looking at different tracing solutions and we decided that because it seemed to be a very evolving market, we didn’t want to get stuck with one vendor. So OpenTracing seemed like the cleanest way to avoid vendor lock-in on what backend we actually had to use."
— MACLEOD BROAD, SENIOR SOFTWARE ARCHITECT AT WORKIVA
+
+
+ After the success of the first use case, everyone involved in the trial went back and fully instrumented their products. Tracing was added to a few more use cases. "We wanted to get through the initial implementation pains early without bringing the whole department along for the ride," says Broad. "Now, a lot of teams add it when they’re starting up a new service. We’re really pushing adoption now more than we were before."
+Some teams were won over quickly. "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service," says Software Engineer Michael Davis. "Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix."
+Most of Workiva’s major products are now traced using OpenTracing, with data pushed into
Google StackDriver. Even the products that aren’t fully traced have some components and libraries that are.
+Broad points out that because some of the engineers were working on App Engine and already had experience with the platform’s Appstats library for profiling performance, it didn’t take much to get them used to using OpenTracing. But others were a little more reluctant. "The biggest hindrance to adoption I think has been the concern about how much latency is introducing tracing [and StackDriver] going to cost," he says. "People are also very concerned about adding middleware to whatever they’re working on. Questions about passing the context around and how that’s done were common. A lot of our Go developers were fine with it, because they were already doing that in one form or another. Our Java developers were not super keen on doing that because they’d used other systems that didn’t require that."
+But the benefits clearly outweighed the concerns, and today, Workiva’s official policy is to use tracing."
+In fact, Broad believes that tracing naturally fits in with Workiva’s existing logging and metrics systems. "This was the way we presented it internally, and also the way we designed our use," he says. "Our traces are logged in the exact same mechanism as our app metric and logging data, and they get pushed the exact same way. So we treat all that data exactly the same when it’s being created and when it’s being recorded. We have one internal library that we use for logging, telemetry, analytics and tracing."
+
+
+
+
+ "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix."
— Michael Davis, Software Engineer, Workiva
+
+
+ For Workiva, OpenTracing has become an essential tool for zeroing in on optimizations and determining what’s actually a micro-optimization by observing usage patterns. "On some projects we often assume what the customer is doing, and we optimize for these crazy scale cases that we hit 1 percent of the time," says Broad. "It’s been really helpful to be able to say, ‘OK, we’re adding 100 milliseconds on every request that does X, and we only need to add that 100 milliseconds if it’s the worst of the worst case, which only happens one out of a thousand requests or one out of a million requests."
+Unlike many other companies, Workiva also traces the client side. "For us, the user experience is important—it doesn’t matter if the RPC takes 100 milliseconds if it still takes 5 seconds to do the rendering to show it in the browser," says Broad. "So for us, those client times are important. We trace it to see what parts of loading take a long time. We’re in the middle of working on a definition of what is ‘loaded.’ Is it when you have it, or when it’s rendered, or when you can interact with it? Those are things we’re planning to use tracing for to keep an eye on and to better understand."
+That also requires adjusting for differences in external and internal clocks. "Before time correcting, it was horrible; our traces were more misleading than anything," says Broad. "So we decided that we would return a timestamp on the response headers, and then have the client reorient its time based on that—not change its internal clock but just calculate the offset on the response time to when the client got it. And if you end up in an impossible situation where a client RPC spans 210 milliseconds but the time on the response time is outside of that window, then we have to reorient that."
+Broad is excited about the impact OpenTracing has already had on the company, and is also looking ahead to what else the technology can enable. One possibility is using tracing to update documentation in real time. "Keeping documentation up to date with reality is a big challenge," he says. "Say, we just ran a trace simulation or we just ran a smoke test on this new deploy, and the architecture doesn’t match the documentation. We can find whose responsibility it is and let them know and have them update it. That’s one of the places I’d like to get in the future with tracing."
+
+
+
+
diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md
index f672eb38d..004fca8dc 100644
--- a/content/en/docs/concepts/architecture/nodes.md
+++ b/content/en/docs/concepts/architecture/nodes.md
@@ -12,7 +12,7 @@ weight: 10
A `node` is a worker machine in Kubernetes, previously known as a `minion`. A node
may be a VM or physical machine, depending on the cluster. Each node has
the services necessary to run [pods](/docs/concepts/workloads/pods/pod/) and is managed by the master
-components. The services on a node include Docker, kubelet and kube-proxy. See
+components. The services on a node include the [container runtime](/docs/concepts/overview/components/#node-components), kubelet and kube-proxy. See
[The Kubernetes Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) section in the
architecture design doc for more details.
@@ -254,8 +254,7 @@ capacity when adding a node.
The Kubernetes scheduler ensures that there are enough resources for all the pods on a node. It
checks that the sum of the requests of containers on the node is no greater than the node capacity. It
-includes all containers started by the kubelet, but not containers started directly by Docker nor
-processes not in containers.
+includes all containers started by the kubelet, but not containers started directly by the [container runtime](/docs/concepts/overview/components/#node-components) nor any process running outside of the containers.
If you want to explicitly reserve resources for non-pod processes, you can create a placeholder
pod. Use the following template:
diff --git a/content/en/docs/concepts/cluster-administration/addons.md b/content/en/docs/concepts/cluster-administration/addons.md
index b8a70ecc0..fc6bf0b6c 100644
--- a/content/en/docs/concepts/cluster-administration/addons.md
+++ b/content/en/docs/concepts/cluster-administration/addons.md
@@ -28,6 +28,7 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Calico, Canal, Flannel, Romana, or Weave.
* [Contiv](http://contiv.github.io) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](http://github.com/contiv). The [installer](http://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options.
* [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.
* [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.
diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md
index 6d0dfc6af..7ee386175 100644
--- a/content/en/docs/concepts/cluster-administration/networking.md
+++ b/content/en/docs/concepts/cluster-administration/networking.md
@@ -201,6 +201,10 @@ sysctl net.ipv4.ip_forward=1
The result of all this is that all `Pods` can reach each other and can egress
traffic to the internet.
+### Knitter
+
+[Knitter](https://github.com/ZTE/Knitter/) is a network solution which supports multiple networking in Kubernetes. It provides the ability of tenant management and network management. Knitter includes a set of end-to-end NFV container networking solutions besides multiple network planes, such as keeping IP address for applications, IP address migration, etc.
+
### Kube-router
[Kube-router](https://github.com/cloudnativelabs/kube-router) is a purpose-built networking solution for Kubernetes that aims to provide high performance and operational simplicity. Kube-router provides a Linux [LVS/IPVS](http://www.linuxvirtualserver.org/software/ipvs.html)-based service proxy, a Linux kernel forwarding-based pod-to-pod networking solution with no overlays, and iptables/ipset-based network policy enforcer.
diff --git a/content/en/docs/concepts/configuration/manage-compute-resources-container.md b/content/en/docs/concepts/configuration/manage-compute-resources-container.md
index 45d098b5e..fb091fa20 100644
--- a/content/en/docs/concepts/configuration/manage-compute-resources-container.md
+++ b/content/en/docs/concepts/configuration/manage-compute-resources-container.md
@@ -308,7 +308,7 @@ You can see that the Container was terminated because of `reason:OOM Killed`, wh
## Local ephemeral storage
{{< feature-state state="beta" >}}
-Kubernetes version 1.8 introduces a new resource, _ephemeral-storage_ for managing local ephemeral storage. In each Kubernetes node, kubelet's root directory (/var/lib/kubelet by default) and log directory (/var/log) are stored on the root partition of the node. This partition is also shared and consumed by pods via EmptyDir volumes, container logs, image layers and container writable layers.
+Kubernetes version 1.8 introduces a new resource, _ephemeral-storage_ for managing local ephemeral storage. In each Kubernetes node, kubelet's root directory (/var/lib/kubelet by default) and log directory (/var/log) are stored on the root partition of the node. This partition is also shared and consumed by Pods via emptyDir volumes, container logs, image layers and container writable layers.
This partition is “ephemeral” and applications cannot expect any performance SLAs (Disk IOPS for example) from this partition. Local ephemeral storage management only applies for the root partition; the optional partition for image layer and writable layer is out of scope.
@@ -366,11 +366,11 @@ run on. Each node has a maximum amount of local ephemeral storage it can provide
### How Pods with ephemeral-storage limits run
-For container-level isolation, if a Container's writable layer and logs usage exceeds its storage limit, the pod will be evicted. For pod-level isolation, if the sum of the local ephemeral storage usage from all containers and also the pod's EmptyDir volumes exceeds the limit, the pod will be evicted.
+For container-level isolation, if a Container's writable layer and logs usage exceeds its storage limit, the Pod will be evicted. For pod-level isolation, if the sum of the local ephemeral storage usage from all containers and also the Pod's emptyDir volumes exceeds the limit, the Pod will be evicted.
-## Extended Resources
+## Extended resources
-Extended Resources are fully-qualified resource names outside the
+Extended resources are fully-qualified resource names outside the
`kubernetes.io` domain. They allow cluster operators to advertise and users to
consume the non-Kubernetes-built-in resources.
@@ -397,7 +397,7 @@ operation, the node's `status.capacity` will include a new resource. The
`status.allocatable` field is updated automatically with the new resource
asynchronously by the kubelet. Note that because the scheduler uses the node
`status.allocatable` value when evaluating Pod fitness, there may be a short
-delay between patching the node capacity with a new resource and the first pod
+delay between patching the node capacity with a new resource and the first Pod
that requests the resource to be scheduled on that node.
**Example:**
@@ -423,7 +423,7 @@ JSON-Pointer. For more details, see
#### Cluster-level extended resources
Cluster-level extended resources are not tied to nodes. They are usually managed
-by scheduler extenders, which handle the resource comsumption, quota and so on.
+by scheduler extenders, which handle the resource consumption and resource quota.
You can specify the extended resources that are handled by scheduler extenders
in [scheduler policy
@@ -432,12 +432,13 @@ configuration](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/sc
**Example:**
The following configuration for a scheduler policy indicates that the
-cluster-level extended resource "example.com/foo" is handled by scheduler
+cluster-level extended resource "example.com/foo" is handled by the scheduler
extender.
- - The scheduler sends a pod to the scheduler extender only if the pod requests
- "example.com/foo".
- - The `ignoredByScheduler` field specifies that the scheduler does not check
- the "example.com/foo" resource in its `PodFitsResources` predicate.
+
+- The scheduler sends a Pod to the scheduler extender only if the Pod requests
+ "example.com/foo".
+- The `ignoredByScheduler` field specifies that the scheduler does not check
+ the "example.com/foo" resource in its `PodFitsResources` predicate.
```json
{
@@ -460,20 +461,20 @@ extender.
### Consuming extended resources
-Users can consume Extended Resources in Pod specs just like CPU and memory.
+Users can consume extended resources in Pod specs just like CPU and memory.
The scheduler takes care of the resource accounting so that no more than the
available amount is simultaneously allocated to Pods.
-The API server restricts quantities of Extended Resources to whole numbers.
+The API server restricts quantities of extended resources to whole numbers.
Examples of _valid_ quantities are `3`, `3000m` and `3Ki`. Examples of
_invalid_ quantities are `0.5` and `1500m`.
{{< note >}}
-**Note:** Extended Resources replace Opaque Integer Resources.
-Users can use any domain name prefix other than "`kubernetes.io`" which is reserved.
+**Note:** Extended resources replace Opaque Integer Resources.
+Users can use any domain name prefix other than `kubernetes.io` which is reserved.
{{< /note >}}
-To consume an Extended Resource in a Pod, include the resource name as a key
+To consume an extended resource in a Pod, include the resource name as a key
in the `spec.containers[].resources.limits` map in the container spec.
{{< note >}}
@@ -482,7 +483,7 @@ must be equal if both are present in a container spec.
{{< /note >}}
A Pod is scheduled only if all of the resource requests are satisfied, including
-CPU, memory and any Extended Resources. The Pod remains in the `PENDING` state
+CPU, memory and any extended resources. The Pod remains in the `PENDING` state
as long as the resource request cannot be satisfied.
**Example:**
@@ -533,11 +534,11 @@ consistency across providers and platforms.
{{% capture whatsnext %}}
-* Get hands-on experience [assigning Memory resources to containers and pods](/docs/tasks/configure-pod-container/assign-memory-resource/).
+* Get hands-on experience [assigning Memory resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/).
-* Get hands-on experience [assigning CPU resources to containers and pods](/docs/tasks/configure-pod-container/assign-cpu-resource/).
+* Get hands-on experience [assigning CPU resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/).
-* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
+* [Container API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
* [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core)
diff --git a/content/en/docs/concepts/configuration/overview.md b/content/en/docs/concepts/configuration/overview.md
index bf8269dc5..17926fa5f 100644
--- a/content/en/docs/concepts/configuration/overview.md
+++ b/content/en/docs/concepts/configuration/overview.md
@@ -52,7 +52,7 @@ This is a living document. If you think of something that is not on this list bu
If you only need access to the port for debugging purposes, you can use the [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) or [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
- If you explicitly need to expose a Pod's port on the node, consider using a [NodePort](/docs/concepts/services-networking/service/#type-nodeport) Service before resorting to `hostPort`.
+ If you explicitly need to expose a Pod's port on the node, consider using a [NodePort](/docs/concepts/services-networking/service/#nodeport) Service before resorting to `hostPort`.
- Avoid using `hostNetwork`, for the same reasons as `hostPort`.
diff --git a/content/en/docs/concepts/configuration/pod-priority-preemption.md b/content/en/docs/concepts/configuration/pod-priority-preemption.md
index 68572920a..e1f19c658 100644
--- a/content/en/docs/concepts/configuration/pod-priority-preemption.md
+++ b/content/en/docs/concepts/configuration/pod-priority-preemption.md
@@ -368,4 +368,29 @@ When multiple nodes exist for preemption and none of the above scenarios apply,
we expect the scheduler to choose a node with the lowest priority. If that is
not the case, it may indicate a bug in the scheduler.
+## Interactions of Pod priority and QoS
+
+Pod priority and
+[QoS](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/resource-qos.md)
+are two orthogonal features with few interactions and no default restrictions on
+setting the priority of a Pod based on its QoS classes. The scheduler's
+preemption logic does consider QoS when choosing preemption targets. Preemption
+considers Pod priority and attempts to choose a set of targets with the lowest
+priority. Higher-priority Pods are considered for preemption only if the removal
+of the lowest priority Pods is not sufficient to allow the scheduler to schedule
+the preemptor Pod, or if the lowest priority Pods are protected by
+`PodDisruptionBudget`.
+
+The only component that considers both QoS and Pod priority is
+[Kubelet out-of-resource eviction](/docs/tasks/administer-cluster/out-of-resource/).
+The kubelet ranks Pods for eviction first by whether or not their usage of the
+starved resource exceeds requests, then by Priority, and then by the consumption
+of the starved compute resource relative to the Pods’ scheduling requests.
+See
+[Evicting end-user pods](/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods)
+for more details. Kubelet out-of-resource eviction does not evict Pods whose
+usage does not exceed their requests. If a Pod with lower priority is not
+exceeding its requests, it won't be evicted. Another Pod with higher priority
+that exceeds its requests may be evicted.
+
{{% /capture %}}
diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md
index 0300f8ec6..5a2477b23 100644
--- a/content/en/docs/concepts/services-networking/ingress.md
+++ b/content/en/docs/concepts/services-networking/ingress.md
@@ -275,7 +275,7 @@ that it applies to all Ingress, such as the load balancing algorithm, backend
weight scheme, and others. More advanced load balancing concepts
(e.g. persistent sessions, dynamic weights) are not yet exposed through the
Ingress. You can still get these features through the
-[service loadbalancer](https://github.com/kubernetes/ingress-nginx/blob/master/docs/ingress-controller-catalog.md).
+[service loadbalancer](https://github.com/kubernetes/ingress-nginx).
With time, we plan to distill load balancing patterns that are applicable
cross platform into the Ingress resource.
@@ -353,8 +353,8 @@ Please track the [L7 and Ingress proposal](https://github.com/kubernetes/kuberne
You can expose a Service in multiple ways that don't directly involve the Ingress resource:
-* Use [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#type-loadbalancer)
-* Use [Service.Type=NodePort](/docs/concepts/services-networking/service/#type-nodeport)
+* Use [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)
+* Use [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)
* Use a [Port Proxy](https://git.k8s.io/contrib/for-demos/proxy-to-service)
{{% /capture %}}
diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md
index 5f82137d3..88a8fb9b4 100644
--- a/content/en/docs/concepts/services-networking/service.md
+++ b/content/en/docs/concepts/services-networking/service.md
@@ -147,7 +147,7 @@ than [`ExternalName`](#externalname).
In Kubernetes v1.0, `Services` are a "layer 4" (TCP/UDP over IP) construct, the
proxy was purely in userspace. In Kubernetes v1.1, the `Ingress` API was added
(beta) to represent "layer 7"(HTTP) services, iptables proxy was added too,
-and become the default operating mode since Kubernetes v1.2. In Kubernetes v1.8.0-beta.0,
+and became the default operating mode since Kubernetes v1.2. In Kubernetes v1.8.0-beta.0,
ipvs proxy was added.
### Proxy-mode: userspace
diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
index ed9af77d0..85c052466 100644
--- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -192,7 +192,7 @@ status:
The new Pod conditions must comply with Kubernetes [label key format](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set).
Since the `kubectl patch` command still doesn't support patching object status,
the new Pod conditions have to be injected through the `PATCH` action using
-one of the [KubeClient libraries](/docs/reference/using-api/client-librarie/).
+one of the [KubeClient libraries](/docs/reference/using-api/client-libraries/).
With the introduction of new Pod conditions, a Pod is evaluated to be ready **only**
when both the following statements are true:
diff --git a/content/en/docs/concepts/workloads/pods/pod.md b/content/en/docs/concepts/workloads/pods/pod.md
index c0451d5b7..147eb1f83 100644
--- a/content/en/docs/concepts/workloads/pods/pod.md
+++ b/content/en/docs/concepts/workloads/pods/pod.md
@@ -165,7 +165,7 @@ Pod is exposed as a primitive in order to facilitate:
## Termination of Pods
-Because pods represent running processes on nodes in the cluster, it is important to allow those processes to gracefully terminate when they are no longer needed (vs being violently killed with a KILL signal and having no chance to clean up). Users should be able to request deletion and know when processes terminate, but also be able to ensure that deletes eventually complete. When a user requests deletion of a pod the system records the intended grace period before the pod is allowed to be forcefully killed, and a TERM signal is sent to the main process in each container. Once the grace period has expired the KILL signal is sent to those processes and the pod is then deleted from the API server. If the Kubelet or the container manager is restarted while waiting for processes to terminate, the termination will be retried with the full grace period.
+Because pods represent running processes on nodes in the cluster, it is important to allow those processes to gracefully terminate when they are no longer needed (vs being violently killed with a KILL signal and having no chance to clean up). Users should be able to request deletion and know when processes terminate, but also be able to ensure that deletes eventually complete. When a user requests deletion of a pod, the system records the intended grace period before the pod is allowed to be forcefully killed, and a TERM signal is sent to the main process in each container. Once the grace period has expired, the KILL signal is sent to those processes, and the pod is then deleted from the API server. If the Kubelet or the container manager is restarted while waiting for processes to terminate, the termination will be retried with the full grace period.
An example flow:
diff --git a/content/en/docs/contribute/_index.md b/content/en/docs/contribute/_index.md
new file mode 100644
index 000000000..7171eac6f
--- /dev/null
+++ b/content/en/docs/contribute/_index.md
@@ -0,0 +1,73 @@
+---
+content_template: templates/concept
+title: Contribute to Kubernetes docs
+linktitle: Contribute
+main_menu: true
+weight: 80
+---
+
+{{% capture overview %}}
+
+If you would like to help contribute to the Kubernetes documentation or website,
+we're happy to have your help! Anyone can contribute, whether you're new to the
+project or you've been around a long time, and whether you self-identify as a
+developer, an end user, or someone who just can't stand seeing typos.
+
+Looking for the [style guide](/docs/contribute/style/style-guide/)?
+{{% /capture %}}
+
+{{% capture body %}}
+
+## Types of contributor
+
+- A _member_ of the Kubernetes organization has [signed the CLA](/contribute/start#sign-the-cla)
+ and contributed some time and effort to the project. See
+ [Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md)
+ for specific criteria for membership.
+- A SIG Docs _reviewer_ is a member of the Kubernetes organization who has
+ expressed interest in reviewing documentation pull requests and who has been
+ added to the appropriate Github group and `OWNERS` files in the Github
+ repository, by a SIG Docs Approver.
+- A SIG Docs _approver_ is a member in good standing who has shown a continued
+ commitment to the project and is granted the ability to merge pull requests
+ and thus to publish content on behalf of the Kubernetes organization.
+ Approvers can also represent SIG Docs in the larger Kubernetes community.
+ Some of the duties of a SIG Docs approver, such as coordinating a release,
+ require a significant time commitment.
+
+## Ways to contribute
+
+This list is divided into things anyone can do, things Kubernetes organization
+members can do, and things that require a higher level of access and familiarity
+with SIG Docs processes. Contributing consistently over time can help you
+understand some of the tooling and organizational decisions that have already
+been made.
+
+This is not an exhaustive list of ways you can contribute to the Kubernetes
+documentation, but it should help you get started.
+
+- [Anyone](/docs/contribute/start/)
+ - File actionable bugs
+- [Member](/docs/contribute/start/)
+ - Improve existing docs
+ - Bring up ideas for improvement on Slack or SIG docs mailing list
+ - Improve docs accessibility
+ - Provide non-binding feedback on PRs
+ - Write a blog post or case study
+- [Reviewer](/docs/contribute/intermediate/)
+ - Document new features
+ - Triage and categorize issues
+ - Review PRs
+ - Create diagrams, graphics assets, and embeddable screencasts / videos
+ - Localization
+ - Contribute to other repos as a docs representative
+ - Edit user-facing strings in code
+ - Improve code comments, Godoc
+- [Approver](/docs/contribute/advanced/)
+ - Publish contributor content by approving and merging PRs
+ - Participate in a Kubernetes release team as a docs representative
+ - Propose improvements to the style guide
+ - Propose improvements to docs tests
+ - Propose improvements to the Kubernetes website or other tooling
+
+{{% /capture %}}
diff --git a/content/en/docs/contribute/advanced.md b/content/en/docs/contribute/advanced.md
new file mode 100644
index 000000000..75ec3b6d5
--- /dev/null
+++ b/content/en/docs/contribute/advanced.md
@@ -0,0 +1,115 @@
+---
+title: Advanced contributing
+slug: advanced
+content_template: templates/concept
+weight: 30
+---
+
+{{% capture overview %}}
+
+This page assumes that you've read and mastered the
+[Start contributing](/docs/contribute/start/) and
+[Intermediate contributing](/docs/contribute/intermediate/) topics and are ready
+to learn about more ways to contribute. You need to use the Git command line
+client and other tools for some of these tasks.
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## Be the PR Wrangler for a week
+
+SIG Docs [approvers](/docs/contribute/participating/#approvers) can be PR
+wranglers.
+
+SIG Docs approvers are added to the
+[PR Wrangler rotation scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers)
+for weekly rotations. The PR wrangler's duties include:
+
+- Review incoming pull requests daily.
+ - Help new contributors sign the CLA, and close any PR where the CLA hasn't
+ been signed for two weeks. PR authors can reopen the PR after signing the
+ CLA, so this is a low-risk way to make sure nothing gets merged without a
+ signed CLA.
+ - Provide feedback on proposed changes, including helping facilitate technical
+ review from members of other SIGs.
+ - Merge PRs when they are ready, or close PRs that shouldn't be accepted.
+- Triage and tag incoming issues daily. See
+ [Intermediate contributing](/docs/contribute/intermediate/) for guidelines
+ about how SIG Docs uses metadata.
+
+## Propose improvements
+
+SIG Docs
+[members](/docs/contribute/participating/#members) can propose improvements.
+
+After you've been contributing to the Kubernetes documentation for a while, you
+may have ideas for improvement to the style guide, the toolchain used to build
+the documentation, the website style, the processes for reviewing and merging
+pull requests, or other aspects of the documentation. For maximum transparency,
+these types of proposals need to be discussed in a SIG Docs meeting or on the
+[kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
+In addition, it can really help to have some context about the way things
+currently work and why past decisions have been made before proposing sweeping
+changes. The quickest way to get answers to questions about how the documentation
+currently works is to ask in the `#sig-docs` Slack channel on
+[kubernetes.slack.com](https://kubernetes.slack.com)
+
+After discussion has taken place and the sig is in agreement about the desired
+outcome, you can work on the proposed changes in the way that is the most
+appropriate. For instance, an update to the style guide or the website's
+functionality might involve opening a pull request, while a change related to
+documentation testing might involve working with sig-testing.
+
+## Coordinate docs for a Kubernetes release
+
+SIG Docs [approvers](/docs/contribute/participating/#approvers) can coordinate
+docs for a Kubernetes release.
+
+Each Kubernetes release is coordinated by a team of people participating in the
+sig-release special interest group (SIG). Others on the release team for a given
+release include an overall release lead, as well as representatives from sig-pm,
+sig-testing, and others. To find out more about Kubernetes release processes,
+refer to
+[https://github.com/kubernetes/sig-release](https://github.com/kubernetes/sig-release).
+
+The SIG Docs representative for a given release coordinates the following tasks:
+
+- Monitor the feature-tracking spreadsheet for new or changed features with an
+ impact on documentation. If documentation for a given feature won't be ready
+ for the release, the feature may not be allowed to go into the release.
+- Attend sig-release meetings regularly and give updates on the status of the
+ docs for the release.
+- Review and copyedit feature documentation drafted by the sig responsible for
+ implementing the feature.
+- Merge release-related pull requests and maintain the Git feature branch for
+ the release.
+- Mentor other SIG Docs contributors who want to learn how to do this role in
+ the future. This is known as "shadowing".
+- Publish the documentation changes related to the release when the release
+ artifacts are published.
+
+Coordinating a release is typically a 3-4 month commitment, and the duty is
+rotated among SIG Docs approvers.
+
+## Sponsor a new contributor
+
+SIG Docs [reviewers](/docs/contribute/participating/#reviewers) can sponsor
+new contributors.
+
+After a new contributor has successfully submitted 5 substantive pull requests
+to one or more Kubernetes repositiries, they are eligible to apply for
+[membership](/docs/contribute/participating#members) in the Kubernetes
+organization. The contributor's membership needs to be backed by two sponsors
+who are already reviewers.
+
+New docs contributors can request sponsors by asking in the #sig-docs channel
+on the [Kubernetes Slack instance](https://kubernetes.slack.com) or on the
+[SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
+If you feel confident about the applicant's work, you volunteer to sponsor them.
+When they submit their membership application, reply to the application with a
+"+1" and include details about why you think the applicant is a good fit for
+membership in the Kubernetes organization.
+
+{{% /capture %}}
+
diff --git a/content/en/docs/contribute/generate-ref-docs/_index.md b/content/en/docs/contribute/generate-ref-docs/_index.md
new file mode 100644
index 000000000..cf058d98f
--- /dev/null
+++ b/content/en/docs/contribute/generate-ref-docs/_index.md
@@ -0,0 +1,9 @@
+---
+title: Reference docs overview
+main_menu: true
+weight: 80
+---
+
+Much of the Kubernetes reference documentation is generated from Kubernetes
+source code, using scripts. The topics in this section document how to generate
+this type of content.
diff --git a/content/en/docs/home/contribute/generated-reference/federation-api.md b/content/en/docs/contribute/generate-ref-docs/federation-api.md
similarity index 100%
rename from content/en/docs/home/contribute/generated-reference/federation-api.md
rename to content/en/docs/contribute/generate-ref-docs/federation-api.md
diff --git a/content/en/docs/home/contribute/generated-reference/kubectl.md b/content/en/docs/contribute/generate-ref-docs/kubectl.md
similarity index 100%
rename from content/en/docs/home/contribute/generated-reference/kubectl.md
rename to content/en/docs/contribute/generate-ref-docs/kubectl.md
diff --git a/content/en/docs/home/contribute/generated-reference/kubernetes-api.md b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
similarity index 100%
rename from content/en/docs/home/contribute/generated-reference/kubernetes-api.md
rename to content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
diff --git a/content/en/docs/home/contribute/generated-reference/kubernetes-components.md b/content/en/docs/contribute/generate-ref-docs/kubernetes-components.md
similarity index 100%
rename from content/en/docs/home/contribute/generated-reference/kubernetes-components.md
rename to content/en/docs/contribute/generate-ref-docs/kubernetes-components.md
diff --git a/content/en/docs/contribute/intermediate.md b/content/en/docs/contribute/intermediate.md
new file mode 100644
index 000000000..3166dcca5
--- /dev/null
+++ b/content/en/docs/contribute/intermediate.md
@@ -0,0 +1,789 @@
+---
+title: Intermediate contributing
+slug: intermediate
+content_template: templates/concept
+weight: 20
+---
+
+{{% capture overview %}}
+
+This page assumes that you've read and mastered the tasks in the
+[start contributing](/docs/contribute/start/) topic and are ready to
+learn about more ways to contribute.
+
+{{< note >}}
+**Note:** Some tasks require you to use the Git command line client and other
+tools.
+{{< /note >}}
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+Now that you've gotten your feet wet and helped out with the Kubernetes docs in
+the ways outlined in the [start contributing](/docs/contribute/start/) topic,
+you may feel ready to do more. These tasks assume that you have, or are willing
+to gain, deeper knowledge of the following topic areas:
+
+- Kubernetes concepts
+- Kubernetes documentation workflows
+- Where and how to find information about upcoming Kubernetes features
+- Strong research skills in general
+
+These tasks are not as sequential as the beginner tasks. There is no expectation
+that one person does all of them all of the time.
+
+## Review pull requests
+
+In any given week, a specific docs approver volunteers to do initial triage
+and review of [pull requests and issues](#triage-and-categorize-issues). This
+person is the "PR Wrangler" for the week. The schedule is maintained using the
+[PR Wrangler scheduler(https://github.com/kubernetes/website/wiki/PR-Wranglers).
+To be added to this list, attend the weekly SIG Docs meeting and volunteer. Even
+if you are not on the schedule for the current week, you can still review pull
+requests (PRs) that are not already under active review.
+
+In addition to the rotation, an automated system comments on each new PR and
+suggests reviewers and approvers for the PR, based on the list of approvers and
+reviewers in the affected files. The PR author is expected to follow the
+guidance of the bot, and this also helps PRs to get reviewed quickly.
+
+We want to get pull requests (PRs) merged and published as quickly as possible.
+To ensure the docs are accurate and up to date, each PR needs to be reviewed by
+people who understand the content, as well as people with experience writing
+great documentation.
+
+Reviewers and approvers need to provide actionable and constructive feedback to
+keep contributors engaged and help them to improve. Sometimes helping a new
+contributor get their PR ready to merge takes more time than just rewriting it
+yourself, but the project is better in the long term when we have a diversity of
+active participants.
+
+Before you start reviewing PRs, make sure you are familiar with the
+[Documentation Style Guide](/docs/contribute/style/style-guide/)
+and the [code of conduct](/community/code-of-conduct/)
+
+### Find a PR to review
+
+To see all open PRs, go to the **Pull Requests** tab in the Github repository.
+A PR is eligible for review when it meets all of the following criteria:
+
+- Has the `cnf-cla:yes` tag
+- Does not have WIP in the description
+- Does not a have tag including the phrase `do-not-merge`
+- Has no merge conflicts
+- Is based against the correct branch (usually `master` unless the PR relates to
+ a feature that has not yet been released)
+- Is not being actively reviewed by another docs person (other technical
+ reviewers are fine), unless that person has explicitly asked for your help. In
+ particular, leaving lots of new comments after other review cycles have
+ already been completed on a PR can be discouraging and counter-productive.
+
+If a PR is not eligible to merge, leave a comment to let the author know about
+the problem and offer to help them fix it. If they've been informed and have not
+fixed the problem in several weeks or months, eventually their PR will be closed
+without merging.
+
+If you're new to reviewing, or you don't have a lot of bandwidth, look for PRs
+with the `size/XS` or `size/S` tag set. The size is automatically determined by
+the number of lines the PR changes.
+
+#### Reviewers and approvers
+
+The Kubernetes website repo operates differently than some of the Kubernetes
+code repositories when it comes to the roles of reviewers and approvers. For
+more information about the responsibilities of reviewers and approvers, see
+[Participating](/docs/contribute/participating/). Here's an overview.
+
+- A reviewer reviews pull request content for technical accuracy. A reviewer
+ indicates that a PR is technically accurate by leaving a `/lgtm` comment on
+ the PR.
+
+ {{< note >}}Don't add an `/lgtm` unless you are confident in the technical
+ accuracy of the documentation modified or introduced in the PR.{{< /note >}}
+
+- An approver reviews pull request content for docs quality and adherence to
+ SIG Docs guidelines, such as the
+ [style guide](/docs/contribute/style/style-guide). Only people listed as
+ approvers in the
+ [`OWNERS`](https://github.com/kubernetes/website/blob/master/OWNERS) file can
+ approve a PR. To approve a PR, leave an `/approved` comment on the PR.
+
+A PR is merged when it has both a `/lgtm` comment from anyone in the Kubernetes
+organization and an `/approved` comment from an approver in the
+`sig-docs-maintainers` group, as long as it is not on hold and the PR author
+has signed the CLA.
+
+### Review a PR
+
+1. Read the PR description and read any attached issues or links, if
+ applicable. "Drive-by reviewing" is sometimes more harmful than helpful, so
+ make sure you have the right knowledge to provide a meaningful review.
+
+2. If someone else is the best person to review this particular PR, let them
+ know by adding a comment with `/assign @
+ 
+ 
- 
