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
@@ -101,6 +101,7 @@ aliases:
    - bradamant3
    - bradtopol
    - chenopis
+    - cody-clark
    - jaredbhatti
    - kbarnard10
    - mistyhacks
@@ -116,6 +117,7 @@ aliases:
    - bradamant3
    - bradtopol
    - chenopis
+    - cody-clark
    - jaredbhatti
    - kbarnard10
    - mistyhacks
@@ -14,6 +14,7 @@ For more information about contributing to the Kubernetes documentation, see:
 * [Staging Your Documentation Changes](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
 * [Using Page Templates](http://kubernetes.io/docs/contribute/style/page-templates/)
 * [Documentation Style Guide](http://kubernetes.io/docs/contribute/style/style-guide/)
+* [Localizing Kubernetes Documentation](https://kubernetes.io/docs/contribute/localization/)

 ## Running the site locally using Docker

@@ -1,11 +1,9 @@
 # Owned by Kubernetes Blog reviewers.
 options:
-  no_parent_owners: true
+  no_parent_owners: false
 reviewers:
  - kbarnard10
 approvers:
  - bobsky
-  - kbarnard10
  - natekartchner
  - sarahkconway
-  - zacharysarah
@@ -23,7 +23,7 @@ Based on where the Kubernetes community is focusing their development efforts, g

 **Basic Concepts**  

-The are a few basic ideas behind RBAC that are foundational in understanding it. At its core, RBAC is a way of granting users granular access to [Kubernetes API resources](https://kubernetes.io/docs/api-reference/v1.6/).  
+There are a few basic ideas behind RBAC that are foundational in understanding it. At its core, RBAC is a way of granting users granular access to [Kubernetes API resources](https://kubernetes.io/docs/api-reference/v1.6/).  


 [![](https://1.bp.blogspot.com/-v6KLs1tT_xI/WOa0anGP4sI/AAAAAAAABBo/KIgYfp8PjusuykUVTfgu9-2uKj_wXo4lwCLcB/s400/rbac1.png)](https://1.bp.blogspot.com/-v6KLs1tT_xI/WOa0anGP4sI/AAAAAAAABBo/KIgYfp8PjusuykUVTfgu9-2uKj_wXo4lwCLcB/s1600/rbac1.png)
@@ -94,7 +94,7 @@ If you’d like to try out Kubeflow, we have a number of options for you:

 1. You can use sample walkthroughs hosted on [Katacoda](https://www.katacoda.com/kubeflow)
 2. You can follow a guided tutorial with existing models from the [examples repository](https://github.com/kubeflow/examples). These include the [Github Issue Summarization](https://github.com/kubeflow/examples/tree/master/github_issue_summarization), [MNIST](https://github.com/kubeflow/examples/tree/master/mnist) and [Reinforcement Learning with Agents](https://github.com/kubeflow/examples/tree/master/agents).
-3. You can start a cluster on your own and try your own model. Any Kubernetes conformant cluster will support Kubeflow  including those from contributors [Caicloud](https://www.prnewswire.com/news-releases/caicloud-releases-its-kubernetes-based-cluster-as-a-service-product-claas-20-and-the-first-tensorflow-as-a-service-taas-11-while-closing-6m-series-a-funding-300418071.html), [Canonical](https://jujucharms.com/canonical-kubernetes/), [Google](https://cloud.google.com/kubernetes-engine/docs/how-to/creating-a-container-cluster), [Heptio](https://heptio.com/products/kubernetes-subscription/), [Mesosphere](https://github.com/mesosphere/dcos-kubernetes-quickstart), [Microsoft](https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough), [IBM](https://console.bluemix.net/docs/containers/cs_tutorials.html#cs_cluster_tutorial), [Red Hat/Openshift ](https://docs.openshift.com/container-platform/3.3/install_config/install/quick_install.html#install-config-install-quick-install)and [Weaveworks](https://www.weave.works/product/cloud/).
+3. You can start a cluster on your own and try your own model. Any Kubernetes conformant cluster will support Kubeflow including those from contributors [Caicloud](https://www.prnewswire.com/news-releases/caicloud-releases-its-kubernetes-based-cluster-as-a-service-product-claas-20-and-the-first-tensorflow-as-a-service-taas-11-while-closing-6m-series-a-funding-300418071.html), [Canonical](https://jujucharms.com/canonical-kubernetes/), [Google](https://cloud.google.com/kubernetes-engine/docs/how-to/creating-a-container-cluster), [Heptio](https://heptio.com/products/kubernetes-subscription/), [Mesosphere](https://github.com/mesosphere/dcos-kubernetes-quickstart), [Microsoft](https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough), [IBM](https://console.bluemix.net/docs/containers/cs_tutorials.html#cs_cluster_tutorial), [Red Hat/Openshift ](https://docs.openshift.com/container-platform/3.3/install_config/install/quick_install.html#install-config-install-quick-install)and [Weaveworks](https://www.weave.works/product/cloud/).

 There were also a number of sessions at KubeCon + CloudNativeCon  EU 2018 covering Kubeflow. The links to the talks are here; the associated videos will be posted in the coming days. 

@@ -20,7 +20,7 @@ If you encounter any site weirdness or broken formatting, please [open an issue]

 ### Multilingual support is coming

-Our initial search focused on finding a language selector that would play well with Jekyll. The  projects we found weren't well-supported, and a prototype of one plugin made it clear that a Jekyll implementation would create technical debt that drained resources away from the quality of the docs.
+Our initial search focused on finding a language selector that would play well with Jekyll. The projects we found weren't well-supported, and a prototype of one plugin made it clear that a Jekyll implementation would create technical debt that drained resources away from the quality of the docs.

 We chose Hugo after months of research and conversations with other open source translation projects. (Special thanks to [Andreas Jaeger](https://twitter.com/jaegerandi?lang=da) and his experience at OpenStack). Hugo's [multilingual support](https://gohugo.io/content-management/multilingual/) is built in and easy.

@@ -17,7 +17,7 @@ date: 2018-05-29

 If you run a Kubernetes environment, chances are you’ve
 customized a Kubernetes configuration — you've copied
-some API object YAML files and editted them to suit
+some API object YAML files and edited them to suit
 your needs.

 But there are drawbacks to this approach — it can be
@@ -23,6 +23,6 @@ The version of Kubernetes at that point was really just a shadow of what it was
 <center><iframe width="560" height="315" src="https://www.youtube.com/embed/YrxnVKZeqK8" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe></center>


-But, however raw, that modest start was enough to pique the interest of a community that started strong and has only gotten stronger.  Over the past four years Kubernetes has exceeded the expectations of all of us that were there early on. We owe the Kubernetes community a huge debt.  The success the project has seen  is based not just on code and technology but also the way that an amazing group of people have come together to create something special.  The best expression of this is the [set of Kubernetes values](https://github.com/kubernetes/steering/blob/master/values.md) that Sarah Novotny helped curate.
+But, however raw, that modest start was enough to pique the interest of a community that started strong and has only gotten stronger.  Over the past four years Kubernetes has exceeded the expectations of all of us that were there early on. We owe the Kubernetes community a huge debt.  The success the project has seen is based not just on code and technology but also the way that an amazing group of people have come together to create something special.  The best expression of this is the [set of Kubernetes values](https://github.com/kubernetes/steering/blob/master/values.md) that Sarah Novotny helped curate.

 Here is to another 4 years and beyond! 🎉🎉🎉
@@ -64,7 +64,7 @@ In this example, the “test” service uses Ambassador annotations to dynamical

 ![kubeflow-ambassador](/images/blog/2018-06-01-dynamic-ingress-kubernetes/kubeflow-ambassador.png)

-With Ambassador, Kubeflow manages routing easily with Kubernetes annotations. Kubeflow configures a single ingress object that directs traffic to Ambassador, then creates services with Ambassador annotations as needed to direct traffic  to specific backends. For example, when deploying TensorFlow services,  Kubeflow creates and and annotates a K8s service so that the model will be served at https://<ingress host>/models/<model name>/. Kubeflow can also use the Envoy Proxy to do the actual L7 routing. Using Ambassador, Kubeflow takes advantage of additional routing configuration like URL rewriting and method-based routing.
+With Ambassador, Kubeflow manages routing easily with Kubernetes annotations. Kubeflow configures a single ingress object that directs traffic to Ambassador, then creates services with Ambassador annotations as needed to direct traffic to specific backends. For example, when deploying TensorFlow services,  Kubeflow creates and annotates a K8s service so that the model will be served at https://<ingress host>/models/<model name>/. Kubeflow can also use the Envoy Proxy to do the actual L7 routing. Using Ambassador, Kubeflow takes advantage of additional routing configuration like URL rewriting and method-based routing.

 If you’re interested in using Ambassador with Kubeflow, the standard Kubeflow install automatically installs and configures Ambassador.

@@ -135,7 +135,7 @@ production_task = KubernetesPodOperator(namespace='default',

 # Launching a test deployment

-Since the Kubernetes Operator is not yet released, we haven't released an official [helm](https://helm.sh/) chart or operator (however both are currently in progress). However, we are including instructions for a basic deployment below  and are actively looking for foolhardy beta testers to try this new feature. To try this system out please follow these steps:
+Since the Kubernetes Operator is not yet released, we haven't released an official [helm](https://helm.sh/) chart or operator (however both are currently in progress). However, we are including instructions for a basic deployment below and are actively looking for foolhardy beta testers to try this new feature. To try this system out please follow these steps:

 ## Step 1: Set your kubeconfig to point to a kubernetes cluster

@@ -157,7 +157,7 @@ Before we move on, let's discuss what these commands are doing:

 ### sed -ie "s/KubernetesExecutor/LocalExecutor/g" scripts/ci/kubernetes/kube/configmaps.yaml

-The Kubernetes Executor is another Airflow feature that allows for dynamic allocation  of tasks as idempotent pods. The reason we are switching this to the LocalExecutor is simply to introduce one feature at a time. You are more then welcome to skip this step if you would like to try the Kubernetes Executor, however we will go into more detail in a future article.
+The Kubernetes Executor is another Airflow feature that allows for dynamic allocation of tasks as idempotent pods. The reason we are switching this to the LocalExecutor is simply to introduce one feature at a time. You are more then welcome to skip this step if you would like to try the Kubernetes Executor, however we will go into more detail in a future article.

 ### ./scripts/ci/kubernetes/Docker/build.sh

@@ -18,13 +18,6 @@ CoreDNS is a general-purpose, authoritative DNS server that provides a backwards

 In this article, you will learn about the differences in the implementations of kube-dns and CoreDNS, and some of the helpful extensions offered by CoreDNS.

-## We appreciate your feedback
-
-We are conducting a survey to evaluate the adoption of CoreDNS as the DNS for Kubernetes's cluster. 
-If you are currently using CoreDNS inside a Kubernetes cluster, please, [take 5 minutes to provide us some feedback by filling this survey](https://www.surveymonkey.com/r/SKZQSLK).
-
-Thank you, we appreciate your collaboration here.
-
 ## Implementation differences

 In kube-dns, several containers are used within a single pod: `kubedns`, `dnsmasq`, and `sidecar`. The `kubedns`
@@ -19,6 +19,8 @@ Intrigued? Let me walk you through how it works.

 # Summary

+_**Please note:** this is a cool hack, but is not officially supported in Kubernetes._
+
 First, we need to understand how exactly it works. 

 In short, for all nodes we have prepared the image with the OS, Docker, Kubelet and everything else that you need there. This image with the kernel is building automatically by CI using Dockerfile. End nodes are booting the kernel and OS from this image via the network.
@@ -365,7 +367,7 @@ Ok, now we have docker image which includes:
 OK, now when our docker-image with LTSP-server, kernel, initramfs and squashed rootfs fully prepared we can run the deployment with it.

 We can do that as usual, but one more thing is networking.
-Unfortunately, we can't use the standard Kubernetes service abstraction for our deployment, because during the boot, our nodes are not part of Kubernetes cluster and they requires ExternalIP, but Kubernetes always enables NAT for ExternalIPs, and there is no way to disable this behavior.
+Unfortunately, we can't use the standard Kubernetes service abstraction for our deployment, because TFTP can't work behind the NAT. During the boot, our nodes are not part of Kubernetes cluster and they requires ExternalIP, but Kubernetes always enables NAT for ExternalIPs, and there is no way to override this behavior.

 For now I have two ways for avoid this: use `hostNetwork: true` or use [pipework](https://github.com/dreamcat4/docker-images/blob/master/pipework/3.%20Examples.md#kubernetes). The second option will also provide you redundancy because, in case of failure, the IP will be moved with the Pod to another node. Unfortunately, pipework is not native and a less secure method.
 If you have some better option for that please let me know.
@@ -489,8 +491,6 @@ Now you can try to make your own changes.
 If you need something more, note that LTSP can be easily changed to meet your needs.
 Feel free to look into the source code and you can find many answers there.

-**UPD:** Many people asking me: Why not simple use CoreOS and Ignition?
+_**UPD:** Many people asking me: Why not simple use CoreOS and Ignition?_

-I can answer. The main feature here is image preparation process not configuration.
-In case with LTSP you have classic Ubuntu system, and everything that can be installed on Ubuntu it can also be written here in the Dockerfile.
-In case CoreOS you have no so many freedom and you can’t easily add custom kernel modules and packages at the build stage of the boot image.
+_I can answer. The main feature here is image preparation process, not configuration. In case with LTSP you have classic Ubuntu system, and everything that can be installed on Ubuntu it can also be written here in the Dockerfile. In case CoreOS you have no so many freedom and you can’t easily add custom kernel modules and packages at the build stage of the boot image._
@@ -89,7 +89,7 @@ acs-engine deploy --subscription-id <subscription id> \

 API model file provides various configurations which acs-engine uses to create a cluster. The API model here [[5]](https://github.com/Azure/acs-engine/blob/master/examples/kubernetes-vmss/kubernetes.json) gives a good starting configuration to setup the VMSS cluster.

-Once a VMSS cluster is created, here are some of the steps you can run to understand more about the cluster setup. Here is the output of  kubectl get nodes from a cluster created using the above command:
+Once a VMSS cluster is created, here are some of the steps you can run to understand more about the cluster setup. Here is the output of kubectl get nodes from a cluster created using the above command:

 ```
 $ kubectl get nodes
@@ -170,7 +170,7 @@ The decision to make a scale up is based on pods which remain unscheduled and a

 Cluster Autoscaler is available as an add-on with acs-engine. The following link [[15]](https://github.com/Azure/acs-engine/tree/master/examples/addons/cluster-autoscaler) has an example configuration file used to deploy autoscaler with acs-engine.  The following link [[8]](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/azure/README.md) provides details on manual step by step way to do the same.

-In acs-engine case we use the the regular command line to deploy:
+In acs-engine case we use the regular command line to deploy:

 ```
 acs-engine deploy --subscription-id <subscription id> \
@@ -0,0 +1,75 @@
+---
+layout: blog
+title: 'Tips for Your First Kubecon Presentation - Part 1'
+date: 2018-10-18
+---
+
+**Author**: Michael Gasch (VMware)
+
+First of all, let me congratulate you to this outstanding achievement. Speaking at KubeCon, especially if it's your first time, is a tremendous honor and experience. Well done!
+
+<center>{{< tweet 1044345018490662912 >}}</center>
+
+When I was informed that my [KubeCon talk about Kubernetes Resource Management](https://www.youtube.com/watch?v=8-apJyr2gi0) was accepted for KubeCon EU in Denmark (2018), I really could not believe it. By then, the chances to get your talk accepted were around 10% (or less, don't really remember the exact number). There were over a 1,000 submissions just for that KubeCon (recall that we now have **three KubeCon events during the year** - US, EU and Asia region). The popularity of Kubernetes is ever increasing and so is the number of people trying to get a talk accepted. Once again, **outstanding achievement to get your talk in**!
+
+But now comes the tough part - research, write, practice, repeat, go on stage, perform :) Let me tell you that I went through several sleepless nights preparing for my first KubeCon talk. The day of the presentation, until I got on stage, was a mixture of every emotion I could have possibly gone through. Even though I had presented uncountable times before, including large industry conferences, KubeCon was very different. Different because it was the first time everything was recorded (including the presenter on stage) and I did not really know the audience, or more precisely: I was assuming everyone in the room is a Kubernetes expert and that my presentation not only had to be entertaining but also technically deep and 100% accurate. It's not seldom that maintainers and SIG (Special Interest Group) leads are in the room as well. 
+
+Another challenge for me was squeezing a topic, that can easily fill a full-day workshop, into a 35min presentation (including Q&A). Before KubeCon, I was used to giving breakouts which were typically 60 minutes long. This doesn't say anything about the quality of the presentation but I knew how many slides I can squeeze into 60 minutes, covering important details but not killing people with "Death by PowerPoint".
+
+So I learned a lot going through this endless cycle of preparation, practicing, these doubts of failing and time pressure finishing your deck, and of course giving the talk. When I left Copenhagen, I took some notes based on my speaker experience during the flight, which my friend [Bjoern](https://twitter.com/bbrundert) encouraged me to share. Not all of them might apply to you, but I still hope some of them are useful for your first KubeCon talk.
+
+## Submitting a Good Talk
+
+Some of you might read these lines even though you did not submit a talk or it wasn't accepted. I found these resources (not specifically targeted at KubeCon) for writing a good proposal very useful:
+
+- [How to write with Style](http://www.novelr.com/2008/08/16/vonnegut-how-to-write-with-style)
+- [Talk Framework](https://docs.google.com/document/d/16llwMgq38wIt19Oj-TrunrPsfczrCNgvIqioslcdb6Q/edit) by the incredible [goinggodotnet](https://twitter.com/goinggodotnet)
+- [Lachie’s 7 step guide to writing a winning tech conference CFP](https://medium.com/@LachlanEvenson/lachies-7-step-guide-to-writing-a-winning-tech-conference-cfp-4fa36a0d2672)
+
+Believe it or not, mine went through several reviews by Justin Garrison, Liz Rice, Bill Kennedy, Emad Benjamin and Kelsey Hightower (yes, THE Kelsey Hightower)! Some of them didn't know me before, they just live by our community values to grow newcomers and thus drive this great community forward every day. 
+
+I think, without their feedback my proposal wouldn't have been on point to be selected. Their feedback was often direct and required me to completely change the first revisions. But they were right and their feedback was useful to stay within the character limit while still standing out with the proposal. 
+
+Feel free to reach out for professional and/or experienced speakers. They know this stuff. And I was surprised by the support and help offered. Many had their DMs in Twitter open, so ask for help and you will be helped :) Besides Twitter, related forums to ask for assistance might be [Discuss](https://discuss.kubernetes.io/) and [Reddit](https://www.reddit.com/r/kubernetes/).
+
+## Preparing for your Presentation
+
+**Tip #1 - Appreciate that you were selected** and don't be upset about the slot your presentation was scheduled in. For example, my talk was put as second last presentation of final KubeCon day (Friday). I was like, who's going to stay there and not catch his/her flight or hang out and relax after this crazy week? The session stats, where speakers can see who signed up, were slowly increasing until the week of KubeCon. I think at the beginning of the week it showed ~80 people interested in my session (there is no mandatory sign-up). I was so happy, especially since there were some interesting talks running at the same time as my presentation.
+
+Without spoiling (see below), the KubeCon community and attendees fully leverage the time and effort they've put into traveling to KubeCon. Rest assured that even if you have the last presentation at KubeCon, people will show up!
+
+**Tip #2 - Study the Masters on [Youtube](https://www.youtube.com/channel/UCvqbFHwN-nwalWPjPUKpvTA/playlists)**. Get some inspirations from great speakers (some of them already mentioned above) and top rated sessions of previous KubeCons. Observe how they present and interact with the audience, while still keeping the tough timing throughout the presentation.
+
+**Tip #3 - Find reviewers**. Having experienced or professional speakers review your slides is super critical. Not only to check for language/translation (see below) but also to improve the flow of your presentation and get feedback on whether the content is logically structured and not too dense (too many slides, timing). They will help you to leave out less important information while also making the presentation fit for your audience (not everyone has the level of knowledge as you in your specific area).
+
+**Tip #4 - Language barriers**. Nobody is perfect and the community encourages diversity. This makes us all better and is what I probably like the most about the Kubernetes community. However, make sure that the audience understands the message of your talk. For non-native speakers, it can be really hard to present in English (e.g. at the US/EU conferences), especially if you're not used to it. Add to that the tension during the talk and it can become really hard for the audience to follow. 
+
+I am not saying that everyone has to present in perfect business English. Nobody expects that, let me be very clear. But if you feel that this could be an issue for you, reach out for help. Reviewers can help fix grammar and wording in your slide deck. Practicing and recording yourself (see below) are helpful to reflect yourself. The slides should reflect your message so people can read along if they lost you. Simple, less busy slides are definitely recommended. Make sure to add speaker notes to your presentation. Not only does this help with getting better every time you run through your presentation (memory effect and the flow). It also serves as a safety net when you think language will definitely be an issue, or when you're suddenly completely lost during the presentation on stage. 
+
+**Tip #5 - Study the Speaker Guidelines**. Nothing to add here, take them seriously and reach out to the (fantastic) speaker support if you have questions. Also submit your presentation in time (plan ahead accordingly) to not risk any trouble with the committee.
+
+**Tip #6 - Practice like never before**. Practicing is probably the most important tip I can give you. I don't know how many times I practiced my talk, e.g. at home but also at some local Meetups to get some early feedback. First I was shocked with timing. Even though I had my deck down to 40min in my dry runs at home, at the Meetup I completely run out of time (50min). I was shocked, as I didn't know what to leave out. 
+
+The feedback from these sessions helped me to trim down content as it helped me to understand what to leave out/shorten. Keep in mind to also leave room for questions as a best practice (requirement?) by the speaker guidelines.
+
+**Tip #7 - The Demo Gods are not always with you**. Demos can and will go wrong. Not just because of the typical suspect like slow WiFi, etc. I heard horror stories about expired certificates, daylight saving times (for those traveling through time zones on their way to KubeCon) affecting deployments, the content of a variable in your BASH script changing (e.g. when curling stuff from the web), keyboards breaking (Mac lovers, can you believe that?), hard disks crashing (even the backup disk not working), and so on. 
+
+Never ever rely on the demo gods, especially when you're not Kelsey Hightower :) Take [video recordings](https://asciinema.org/) of your demos so you not only have a backup when the live demo breaks. But also in case you're afraid of running out of time. In order to avoid the primary and backup disks crashing (yes, it happened at that KubeCon I was told), store a copy at your trusted cloud provider.
+
+**Tip #8 - The right Tools for the job**. Sometimes you want to highlight something on your slide. This has two potentially issues. First, you have to constantly turn away from the audience which does not necessarily look good (if you can avoid it). Second, it might not always work depending on the (laser) pointer and room equipment (light, background). 
+
+[This presenter](https://www.logitech.com/en-us/product/spotlight-presentation-remote) from Logitech has really served me well. It has several useful features, the "Spotlight" (that's why the name) being my favorite feature. You'll never want to go back.
+
+**Tip #9 - Being recorded**. I am not sure if you can opt-out from being recorded (please check with speaker support on the latest guidelines here) if you don't want to appear on Youtube for the rest of your life. But audio definitely will be recorded so chose your words (jokes) wisely. Again, practicing and reviewing helps. If you're ok with being recorded, at least think about which shirt (logos and "art") you want to be remembered by the internet ;)
+
+**Tip #10 - Social media**. Social media is great for promoting your session and you should definitely send out reminders on various channels for your presentation. Something that is missing almost every time in the presentation templates (if you want to use them) is placeholders for your social media account and, more importantly, for your session ID. Even if the conference does not use session IDs externally (in the schedule builder), you might still want to add a handle to every slide so people can refer to your presentation (or particular slide) on social media with a hashtag that you then can search for feedback, questions, etc.
+
+**Tip #11 - Be yourself**. Be authentic and don't try to sound super smart or funny (unless you are ;)). Seriously. Just be yourself and people will love you. Authenticity is key for a great presentation and the audience will smell when you try to fool them. It also makes practicing and the live performance easier as you don't have to pay attention on acting like somebody else. 
+
+From a content perspective make sure that **you** own and develop the content and you did not copy and paste like crazy from the Kubernetes docs or other presentations. It's absolutely ok to reference other sources, but please give them credit. Again, the audience will smell if you make things up. You should know what you're speaking about (not saying that you have to be an expert, but experience is what makes your talk unique). The final proof is during Q&A and KubeCon is a sharp audience ;)
+
+**Tip #12 - Changes to the proposal**. The committee, based on your proposal description and details, might change the audience level. For example, I put my talk in as intermediate, but it was changed to all skill levels. This is not bad per se. Just watch out for changes and adapt your presentation accordingly or reach out to speaker support. If you were not expecting beginners or architects in your talk (because you had chosen another skill level and target group), you might lose parts of your audience. This could also negatively affect your session feedback/scores. 
+
+## Wrapping up
+
+I hope some of these tips are already useful and will help you getting started to work on your presentation. In the next post we are going to cover speaker tips when you are finally at the KubeCon event.
@@ -0,0 +1,55 @@
+---
+layout: blog
+title: 'Tips for Your First Kubecon Presentation - Part 2'
+date: 2018-10-26
+---
+
+**Author**: Michael Gasch (VMware)
+
+Hello and welcome back to the second and final part about tips for KubeCon first-time speakers. If you missed the last post, please give it a read [here](https://kubernetes.io/blog/2018/10/18/tips-for-your-first-kubecon-presentation---part-1/).
+
+## The Day before the Show
+
+**Tip #13 - Get enough sleep**. I don't know about you, but when I don't get enough sleep (especially when beer is in the game), the next day my brain power is around 80% at best. It's very easy to get distracted at KubeCon (in a positive sense). "Let's have dinner tonight and chat about XYZ". Get some food, beer or wine because you're so excited and all the good resolutions you had set for the day before your presentation are forgotten :) 
+
+OK, I'm slightly exaggerating here. But don't underestimate the dynamics of this conference, the amazing people you meet, the inspiring talks and of course the conference party. Be disciplined, at least that one day. There's enough time to party after your great presentation!
+
+**Tip #14 - A final dry-run**. Usually, I do a final dry-run of my presentation the day before the talk. This helps me to recall the first few sentences I want to say so I keep the flow no matter what happens when the red recording light goes on. Especially when your talk is later during the conference, there's so much new stuff your brain has to digest which could "overwrite" the very important parts of your presentation. I think you know what I mean. So, if you're like me, a final dry-run is never a bad idea (also to check equipment, demos, etc.).
+
+**Tip #15 - Promote your session, again**. Send out a final reminder on your social media channels so your followers (and KubeCon attendees) will recall to attend your session (again, KubeCon is busy and it's hard to keep up with all the talks you wanted to attend). I was surprised to see my attendee list jumping from ~80 at the beginning of the week to >300 the day before the talk. The number kept rising even an hour before going on stage. So don't worry about the stats too early.
+
+**Tip #16 - Ask your idols to attend**. [Steve Wong](https://twitter.com/cantbewong), a colleague of mine who I really admire for his knowledge and passion, gave me a great advise. Reach out to the people you always wanted to attend your talk and kindly ask them to come along. 
+
+So I texted the one and only [Tim Hockin](https://twitter.com/thockin?lang=de). Even though these well-respected community leaders are super busy and thus usually cannot attend many talks during the conference, the worst thing that can happen is that they cannot show up and will let you know. (see the end of this post to find out whether or not I was lucky :))
+
+## The show is on!
+
+Your day has come and it doesn't make **any** sense to make big changes to your presentation now! Actually, that's a very bad idea unless you're an expert and your heartbeat at rest is around 40 BPM. (But even then many things can go horribly wrong). 
+
+So, without further ado, here are my final tips for you. 
+
+**Tip #17 - Arrive ahead of time**. Set an alert (or two) to not miss your presentation, e.g. because somebody caught you on the way to the room or you got a call/have been pulled in a meeting. It's a good idea to find out were your room is at least some hours before your talk. These conference buildings can be very large. Also look for last minute schedule (time/room) changes, just because you never know...
+
+**Tip #18 - Ask a friend to take photos**. My dear colleague [Bjoern](https://twitter.com/bbrundert), without me asking for it, took a lot of pictures and watched the audience during the talk. This was really helpful, not just because I now have some nice shots that will always remind me of this great day. He also gave me honest feedback, e.g. what people said, whether they liked it or what I could have done better. 
+
+**Tip #19 - Restroom**. If you're like me, when I'm nervous I could run every 15 minutes. The last thing you want is that you are fully cabled (microphone), everything is set up and two minutes before your presentation you feel like "oh oh"...nothing more to say here ;)
+
+**Tip #20 - The audience**. I had many examples and references from other Kubernetes users (and their postmortem stories) in my talk. So I tried to give them credit and actually some of them were in the room and really liked that I did so. It gave them (and hopefully the rest of the audience as well) the feeling that I did not invent the wheel and we are all in the same boat. Also feel free to ask some questions in the beginning, e.g. to get a better feeling about who is attending your talk, or who would consider himself an expert in the area of what you are talking about, etc.
+
+**Tip #21 - Repeat questions. Always**. Because of the time constraints, questions should be asked at the end of your presentation (unless you are giving a community meeting or panel of course). Always (always!) repeat the questions at the end. Sometimes people will not use the microphone. This is not only hard for the people in the back, but also it won't be captured on the recording. I am sure you also had that moment watching a recording and not getting what is being asked/discussed because the question was not captured.
+
+**Tip #22 - Feedback**. Don't forget to ask the audience to fill out the survey. They're not always enforced/mandatory during conferences (especially not at KubeCon), so it's easy to forget to give the speaker feedback. Feedback is super critical (also for the committee) as sometimes people won't directly tell you but rather write their thoughts. Also, you might want to block your calendar to leave some time after the presentation for follow-up questions, so you are not in the hurry to catch your next meeting/session.
+
+**Tip #23 - Invite your audience**. No, I don't mean to throw a round of beer for everyone attending your talk (I mean, you could). But you might let them know, at the end of your presentation, that you would like to hang out, have dinner, etc. A great opportunity to reflect and geek out with like-minded friends.
+
+**Final Tip - Your Voice matters**. Don't underestimate the power of giving a talk at a conference. In my case I was lucky that the Zalando crew was in the room and took this talk as an opportunity for an ad hoc meeting after the conference. This drove an important performance fix forward, which eventually was [merged](https://github.com/kubernetes/kubernetes/pull/63437) (kudos to the Zalando team again!). 
+
+Embrace the opportunity to give a talk at a conference, take it serious, be professional and make the best use of your time. But I'm sure I don't have to tell you that ;)
+
+## Now it's on you :)
+
+I hope some of these tips are useful for you as well. And I wish you all the best for your upcoming talk!!! Believing in and being yourself is key to success. And perhaps your Kubernetes idol is in the room and has some nice words for you after your presentation!
+
+Besides my fantastic reviewers and the speaker support team already mentioned above, I also would like to thank the people who supported me along this KubeCon journey: Bjoern, Timo, Emad and Steve!
+
+{{< tweet 992409364467200000 >}}
@@ -1,10 +1,8 @@
 # Owned by Kubernetes Blog reviewers.
 options:
-  no_parent_owners: true
+  no_parent_owners: false
 reviewers:
  - alexcontini
 approvers:
  - alexcontini
-  - kbarnard10
  - sarahkconway
-  - zacharysarah
@@ -0,0 +1 @@
+<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 215.9892 128.40633"><defs><style>.cls-1{fill:#f9f9f9;}.cls-2{fill:#4c81c2;}</style></defs><title>ibm_featured_logo</title><rect class="cls-1" x="-5.9997" y="-8.99955" width="229.48853" height="143.9928"/><polygon class="cls-2" points="190.441 33.693 162.454 33.693 164.178 28.868 190.441 28.868 190.441 33.693"/><path class="cls-2" d="M115.83346,28.867l25.98433-.003,1.7014,4.83715c.01251-.00687-27.677.00593-27.677,0C115.84224,33.69422,115.82554,28.867,115.83346,28.867Z"/><path class="cls-2" d="M95.19668,28.86593A18.6894,18.6894,0,0,1,106.37358,33.7s-47.10052.00489-47.10052,0V28.86488Z"/><rect class="cls-2" x="22.31176" y="28.86593" width="32.72063" height="4.82558"/><path class="cls-2" d="M190.44115,42.74673h-31.194s1.70142-4.79994,1.691-4.80193h29.50305Z"/><polygon class="cls-2" points="146.734 42.753 115.832 42.753 115.832 37.944 145.041 37.944 146.734 42.753"/><path class="cls-2" d="M110.04127,37.94271a12.47,12.47,0,0,1,1.35553,4.80214H59.28193V37.94271Z"/><rect class="cls-2" x="22.31176" y="37.94271" width="32.72063" height="4.80214"/><polygon class="cls-2" points="156.056 51.823 157.768 46.998 181.191 47.005 181.191 51.812 156.056 51.823"/><polygon class="cls-2" points="148.237 46.997 149.944 51.823 125.046 51.823 125.046 46.997 148.237 46.997"/><path class="cls-2" d="M111.81,46.99627a15.748,15.748,0,0,1-.68923,4.82641H96.85137V46.99627Z"/><rect class="cls-2" x="31.43162" y="47.01973" width="14.06406" height="4.8019"/><rect class="cls-2" x="68.7486" y="46.99627" width="14.03976" height="4.82537"/><path class="cls-2" d="M138.87572,57.03292s.004,3.65225.001,3.65913H125.04558V55.89h26.35583l1.637,4.4773c.00773.00292,1.57841-4.48815,1.58153-4.47835h26.56223V60.692h-13.763c-.00124-.00687-.00771-3.65819-.00771-3.65819l-1.273,3.65819-25.99183-.00687Z"/><path class="cls-2" d="M68.7486,55.889h40.30365v-.00188a18.13723,18.13723,0,0,1-3.99812,4.80494s-36.30647.00668-36.30647,0Z"/><rect class="cls-2" x="31.43162" y="55.88794" width="14.06406" height="4.80316"/><rect class="cls-2" x="167.41912" y="64.94348" width="13.76302" height="4.80212"/><path class="cls-2" d="M138.87572,64.94348H125.04558V69.7456c-.00688-.0025,13.83411.00167,13.83411,0C138.87969,69.7431,138.89532,64.94348,138.87572,64.94348Z"/><path class="cls-2" d="M164.63927,64.94348c-.06255-.007-1.61218,4.79962-1.67723,4.80212l-19.60378.00835c-.01543-.00751-1.72371-4.81745-1.725-4.81047Z"/><path class="cls-2" d="M68.74672,64.94233H104.985a23.7047,23.7047,0,0,1,4.32076,4.80327c.06609-.0025-40.5581.00167-40.5581,0Z"/><path class="cls-2" d="M45.49359,69.74436v-4.802H31.45487V69.7431Z"/><rect class="cls-2" x="167.41912" y="73.99693" width="13.76198" height="4.80295"/><rect class="cls-2" x="125.04474" y="73.99693" width="13.83097" height="4.80212"/><path class="cls-2" d="M159.74351,78.8224c.00376-.02169,1.69745-4.82964,1.72373-4.82547H144.80219c-.029-.00209,1.70848,4.80378,1.70848,4.80378S159.7404,78.84241,159.74351,78.8224Z"/><path class="cls-2" d="M68.74766,78.79905c0,.01919-.00094-4.80212,0-4.803H82.9958s.01272,4.80462,0,4.80462C82.98224,78.80072,68.74766,78.79489,68.74766,78.79905Z"/><path class="cls-2" d="M111.30529,73.9961a13.94783,13.94783,0,0,1,.89542,4.825H97.10364v-4.825Z"/><rect class="cls-2" x="31.45487" y="73.9961" width="14.03872" height="4.80171"/><rect class="cls-2" x="167.41912" y="82.86525" width="23.0212" height="4.80421"/><rect class="cls-2" x="115.83139" y="82.86525" width="23.04432" height="4.80421"/><polygon class="cls-2" points="156.647 87.669 149.618 87.669 147.931 82.865 158.272 82.865 156.647 87.669"/><path class="cls-2" d="M22.3099,82.86525v4.80212H55.008c.01366.00751-.01469-4.79919,0-4.79919Z"/><path class="cls-2" d="M111.60237,82.86525c-.3442,1.58445-.65962,3.5158-1.81732,4.80421l-.43175-.00209H59.28005V82.86525Z"/><polygon class="cls-2" points="153.461 96.733 152.814 96.733 151.171 91.92 155.147 91.92 153.461 96.733"/><rect class="cls-2" x="167.41788" y="91.91953" width="23.02244" height="4.82547"/><path class="cls-2" d="M59.27307,96.73333V91.92745s47.24073.00585,47.37623.00585A17.945,17.945,0,0,1,94.43864,96.745l-35.15859-.00959"/><rect class="cls-2" x="115.83139" y="91.91953" width="23.04432" height="4.82547"/><path class="cls-2" d="M55.008,91.94079s-.01469,4.79253,0,4.79253c.01366,0-32.6885.0196-32.69809.00961-.00888-.00961.00875-4.81548,0-4.81548S54.9933,91.95664,55.008,91.94079Z"/></svg>
@@ -5,7 +5,7 @@ linkTitle: IBM
 case_study_styles: true
 cid: caseStudies
 css: /css/style_case_studies.css
-logo: ibm_featured_logo.png
+logo: ibm_featured_logo.svg
 featured: true
 weight: 2
 quote: >
@@ -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 %}}
-
-
@@ -257,7 +257,7 @@ to the Github UI.
      ```

 4.  Check out the remote branch. This command will fail if you already have a
-    local branch with the sane name.
+    local branch with the same name.

      ```bash
      git checkout <branch-from-PR>
@@ -643,7 +643,7 @@ your question to the `#kubernetes-users` channel in
 [Kubernetes slack](http://slack.k8s.io/). You can also search
 resources like
 [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
-for answers  to similar questions.
+for answers to similar questions.

 You can also open issues for Kubernetes functionality in
 https://github.com/kubernetes/kubernetes.
@@ -20,7 +20,6 @@ We encourage you to add new  [localizations](https://blog.mozilla.org/l10n/2011/

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -100,7 +99,7 @@ Provide guidance to localization contributors in the localized `README-**.md` fi
 - A point of contact for the localization project
 - Any information specific to the localization

-After you create the localized README, add a link to the file from the main English file, [`README.md`] and include contact information in English. You can provide a GitHub ID, email address, [Slack channel](https://slack.com/), or other method of contact.
+After you create the localized README, add a link to the file from the main English file, [`README.md`'s Localizing Kubernetes Documentation] and include contact information in English. You can provide a GitHub ID, email address, [Slack channel](https://slack.com/), or other method of contact.

 ## Translating documents

@@ -154,8 +154,8 @@ process guidelines and information about deadlines.
 ### Sign the CLA

 Before you can contribute code or documentation to Kubernetes, you **must** read
-the [Contributor guide](/docs/community/guide/) and
-[sign the Contributor License Agreement (CLA)](/docs/community/guide/#sign-the-cla).
+the [Contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) and
+[sign the Contributor License Agreement (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md).
 Don't worry -- this doesn't take long!

 ### Find something to work on
@@ -4,7 +4,6 @@ content_template: templates/concept
 weight: 40
 ---

-{{< toc >}}

 {{% capture overview %}}

@@ -62,7 +61,7 @@ linkTitle: Title used in links

 ### Documentation Side Menu

-The documentation side-bar menu is built from the _current section tree_ starting below `docs/`. 
+The documentation side-bar menu is built from the _current section tree_ starting below `docs/`.

 It will show all sections and their pages.

@@ -86,7 +85,7 @@ toc_hide: true

 ### The Main Menu

-The site links in the top-right menu -- and also in the footer -- are built by page-lookups. This is to make sure that the page actually exists. So, if the `case-studies` section does not exist in a site (language), it will not be linked to. 
+The site links in the top-right menu -- and also in the footer -- are built by page-lookups. This is to make sure that the page actually exists. So, if the `case-studies` section does not exist in a site (language), it will not be linked to.


 ## Page Bundles
@@ -137,4 +136,3 @@ The `SASS` source of the stylesheets for this site is stored below `src/sass` an
 * [Style guide](/docs/contribute/style/style-guide)

 {{% /capture %}}
-
@@ -23,7 +23,6 @@ template to use for a new topic, start with the

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -51,18 +50,18 @@ To write a new concept page, create a Markdown file in a subdirectory of the

    The page's body will look like this (remove any optional captures you don't
    need):
-    
+
    ```
    {{%/* capture overview */%}}
-    
+
    {{%/* /capture */%}}
-    
+
    {{%/* capture body */%}}
-    
+
    {{%/* /capture */%}}
-    
+
    {{%/* capture whatsnext */%}}
-    
+
    {{%/* /capture */%}}
    ```

@@ -101,28 +100,28 @@ To write a new task page, create a Markdown file in a subdirectory of the

    The page's body will look like this (remove any optional captures you don't
    need):
-    
+
    ```
    {{%/* capture overview */%}}
-  
+
    {{%/* /capture */%}}
-    
+
    {{%/* capture prerequisites */%}}
-    
+
    {{</* include "task-tutorial-prereqs.md" */>}} {{</* version-check */>}}
-    
+
    {{%/* /capture */%}}
-    
+
    {{%/* capture steps */%}}
-    
+
    {{%/* /capture */%}}
-    
+
    {{%/* capture discussion */%}}
-    
+
    {{%/* /capture */%}}
-    
+
    {{%/* capture whatsnext */%}}
-    
+
    {{%/* /capture */%}}
    ```

@@ -167,32 +166,32 @@ To write a new tutorial page, create a Markdown file in a subdirectory of the

    The page's body will look like this (remove any optional captures you don't
    need):
-    
+
    ```
    {{%/* capture overview */%}}
-    
+
    {{%/* /capture */%}}
-    
+
    {{%/* capture prerequisites */%}}
-    
+
    {{</* include "task-tutorial-prereqs.md" */>}} {{</* version-check */>}}
-    
+
    {{%/* /capture */%}}
-    
+
    {{%/* capture objectives */%}}
-    
+
    {{%/* /capture */%}}
-    
+
    {{%/* capture lessoncontent */%}}
-    
+
    {{%/* /capture */%}}
-    
+
    {{%/* capture cleanup */%}}
-    
+
    {{%/* /capture */%}}
-    
+
    {{%/* capture whatsnext */%}}
-    
+
    {{%/* /capture */%}}
    ```

@@ -221,4 +220,3 @@ An example of a published topic that uses the tutorial template is
 - Learn about [content organization](/docs/contribute/style/content-organization/)

 {{% /capture %}}
-
@@ -8,7 +8,7 @@ cid: userJourneys
 css: /css/style_user_journeys.css
 js: /js/user-journeys/home.js, https://use.fontawesome.com/4bcc658a89.js
 display_browse_numbers: true
-linkTitle: Documentation
+linkTitle: "Home"
 main_menu: true
 weight: 10
 menu:
@@ -33,9 +33,9 @@ This page describes how to use Admission Webhooks and Initializers.

 Admission webhooks are HTTP callbacks that receive admission requests and do
 something with them. You can define two types of admission webhooks,
-[validating admission Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)
+[validating admission Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook)
 and
-[mutating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook-beta-in-1-9).
+[mutating admission webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook).
 With validating admission Webhooks, you may reject requests to enforce custom
 admission policies. With mutating admission Webhooks, you may change requests to
 enforce custom defaults.
@@ -898,7 +898,8 @@ The RBAC authorizer will attempt to authorize requests first. If it denies an AP
 the ABAC authorizer is then run. This means that any request allowed by *either* the RBAC
 or ABAC policies is allowed.

-When run with a log level of 2 or higher (`--v=2`), you can see RBAC denials in the apiserver log (prefixed with `RBAC DENY:`).
+When the apiserver is run with a log level of 5 or higher for the RBAC component (`--vmodule=rbac*=5` or `--v=5`),
+you can see RBAC denials in the apiserver log (prefixed with `RBAC DENY:`).
 You can use that information to determine which roles need to be granted to which users, groups, or service accounts.
 Once you have [granted roles to service accounts](#service-account-permissions) and workloads are running with no RBAC denial messages
 in the server logs, you can remove the ABAC authorizer.
@@ -38,7 +38,7 @@ different Kubernetes components.
 | `APIListChunking` | `true` | Beta | 1.9 | |
 | `APIResponseCompression` | `false` | Alpha | 1.7 | |
 | `AppArmor` | `true` | Beta | 1.4 | |
-| `AttachVolumeLimit` | `false` | Alpha | 1.11 | |
+| `AttachVolumeLimit` | `true` | Alpha | 1.11 | |
 | `BlockVolume` | `false` | Alpha | 1.9 | |
 | `CPUManager` | `false` | Alpha | 1.8 | 1.9 |
 | `CPUManager` | `true` | Beta | 1.10 | |
@@ -213,7 +213,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
  When the `Initializers` admission controller is enabled, this feature is automatically enabled.
 - `KubeletConfigFile`: Enable loading kubelet configuration from a file specified using a config file.
  See [setting kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file/) for more details.
- `KubletPluginsWatcher`: Enable probe-based plugin watcher utility to enable kubelet
+- `KubeletPluginsWatcher`: Enable probe-based plugin watcher utility to enable kubelet
  to discover plugins such as [CSI volume drivers](/docs/concepts/storage/volumes/#csi).
 - `LocalStorageCapacityIsolation`: Enable the consumption of [local ephemeral storage](/docs/concepts/configuration/manage-compute-resources-container/) and also the `sizeLimit` property of an [emptyDir volume](/docs/concepts/storage/volumes/#emptydir).
 - `MountContainers`: Enable using utility containers on host as the volume mounter.
@@ -0,0 +1,20 @@
+---
+title: Aggregation Layer
+id: aggregation-layer
+date: 2018-10-08
+full_link: /docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
+short_description: >
+  The aggregation layer lets you install additional Kubernetes-style APIs in your cluster.
+
+aka: 
+tags:
+- architecture
+- extension
+- operation
+---
+ The aggregation layer lets you install additional Kubernetes-style APIs in your cluster.
+
+<!--more--> 
+
+When you've configured the {{< glossary_tooltip text="Kubernetes API Server" term_id="kube-apiserver" >}} to [support additional APIs](https://kubernetes.io/docs/tasks/access-kubernetes-api/configure-aggregation-layer/), you can add `APIService` objects to "claim" a URL path in the Kubernetes API.
+
@@ -23,7 +23,7 @@ Join the [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernete

 We’re extremely grateful for security researchers and users that report vulnerabilities to the Kubernetes Open Source Community. All reports are thoroughly investigated by a set of community volunteers.

-To make a report, please email the private [security@kubernetes.io](mailto:security@kubernetes.io) list with the security details and the details expected for [all Kubernetes bug reports](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE.md).
+To make a report, please email the private [security@kubernetes.io](mailto:security@kubernetes.io) list with the security details and the details expected for [all Kubernetes bug reports](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md).

 You may encrypt your email to this list using the GPG keys of the [Product Security Team members](https://git.k8s.io/sig-release/security-release-process-documentation/security-release-process.md#product-security-team-pst). Encryption using GPG is NOT required to make a disclosure.

@@ -282,7 +282,7 @@ kubectl api-resources --api-group=extensions # All resources in the "extensions"

 ### Formatting output

-To output details to your terminal window in a specific format, you can add either the `-o` or `-output` flags to a supported `kubectl` command.
+To output details to your terminal window in a specific format, you can add either the `-o` or `--output` flags to a supported `kubectl` command.

 Output format | Description
 --------------| -----------
@@ -1,16 +1,18 @@
 ---
 title: kubectl for Docker Users
+content_template: templates/concept
 reviewers:
 - bgrant0607
 - brendandburns
 - thockin
 ---

-You can use the Kubernetes command line tool kubectl to interact with the api. You can use kubectl if you are familiar with docker-cli. However, there are a few differences in the docker-cli commands and the kubectl commands. Each of the following section details a docker subcommand and explains the kubectl equivalent.
+{{% capture overview %}}
+You can use the Kubernetes command line tool kubectl to interact with the API Server. Using kubectl is straightforward if you are familiar with the Docker command line tool. However, there are a few differences between the docker commands and the kubectl commands. The following sections show a docker sub-command and describe the equivalent kubectl command.
+{{% /capture %}}

-{{< toc >}}
-
-#### docker run
+{{% capture body %}}
+## docker run

 To run an nginx Deployment and expose the Deployment, see [kubectl run](/docs/reference/generated/kubectl/kubectl-commands/#run).

@@ -57,7 +59,7 @@ To detach from the container, you can type the escape sequence Ctrl+P followed b
 Because the kubectl run command starts a Deployment for the container, the Deployment restarts if you terminate the attached process by using Ctrl+C, unlike `docker run -it`.
 To destroy the Deployment and its pods you need to run `kubectl delete deployment <name>`.

-#### docker ps
+## docker ps

 To list what is currently running, see [kubectl get](/docs/reference/generated/kubectl/kubectl-commands/#get).

@@ -79,7 +81,7 @@ nginx-app-8df569cb7-4gd89   1/1       Running     0          3m
 ubuntu                      0/1       Completed   0          20s
 ```

-#### docker attach
+## docker attach

 To attach a process that is already running in a container, see [kubectl attach](/docs/reference/generated/kubectl/kubectl-commands/#attach).

@@ -107,7 +109,7 @@ $ kubectl attach -it nginx-app-5jyvm

 To detach from the container, you can type the escape sequence Ctrl+P followed by Ctrl+Q.

-#### docker exec
+## docker exec

 To execute a command in a container, see [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec).

@@ -152,7 +154,7 @@ $ kubectl exec -ti nginx-app-5jyvm -- /bin/sh

 For more information, see [Get a Shell to a Running Container](/docs/tasks/debug-application-cluster/get-shell-running-container/).

-#### docker logs
+## docker logs

 To follow stdout/stderr of a process that is running, see [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands/#logs).

@@ -183,7 +185,7 @@ $ kubectl logs --previous nginx-app-zibvs

 For more information, see [Logging Architecture](/docs/concepts/cluster-administration/logging/).

-#### docker stop and docker rm
+## docker stop and docker rm

 To stop and delete a running process, see [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands/#delete).

@@ -223,11 +225,11 @@ $ kubectl get po -l run=nginx-app
 **Note:** When you use kubectl, you don't delete the pod directly.You have to first delete the Deployment that owns the pod. If you delete the pod directly, the Deployment recreates the pod.
 {{< /note >}}

-#### docker login
+## docker login

 There is no direct analog of `docker login` in kubectl. If you are interested in using Kubernetes with a private registry, see [Using a Private Registry](/docs/concepts/containers/images/#using-a-private-registry).

-#### docker version
+## docker version

 To get the version of client and server, see [kubectl version](/docs/reference/generated/kubectl/kubectl-commands/#version).

@@ -255,7 +257,7 @@ Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4
 Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
 ```

-#### docker info
+## docker info

 To get miscellaneous information about the environment and configuration, see [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands/#cluster-info).

@@ -292,3 +294,4 @@ Grafana is running at https://108.59.85.141/api/v1/namespaces/kube-system/servic
 Heapster is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
 InfluxDB is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy
 ```
+{{% /capture %}}
@@ -68,7 +68,7 @@ Operation       | Syntax    |       Description
 `edit`        | `kubectl edit (-f FILENAME \| TYPE NAME \| TYPE/NAME) [flags]` | Edit and update the definition of one or more resources on the server by using the default editor.
 `exec`        | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | Execute a command against a container in a pod,
 `explain`    | `kubectl explain [--include-extended-apis=true] [--recursive=false] [flags]` | Get documentation of various resources. For instance pods, nodes, services, etc.
-`expose`        | `kubectl expose (-f FILENAME \| TYPE NAME \| TYPE/NAME) [--port=port] [--protocol=TCP\|UDP] [--target-port=number-or-name] [--name=name] [----external-ip=external-ip-of-service] [--type=type] [flags]` | Expose a replication controller, service, or pod as a new Kubernetes service.
+`expose`        | `kubectl expose (-f FILENAME \| TYPE NAME \| TYPE/NAME) [--port=port] [--protocol=TCP\|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags]` | Expose a replication controller, service, or pod as a new Kubernetes service.
 `get`        | `kubectl get (-f FILENAME \| TYPE [NAME \| /NAME \| -l label]) [--watch] [--sort-by=FIELD] [[-o \| --output]=OUTPUT_FORMAT] [flags]` | List one or more resources.
 `label`        | `kubectl label (-f FILENAME \| TYPE NAME \| TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]` | Add or update the labels of one or more resources.
 `logs`        | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | Print the logs for a container in a pod.
@@ -84,6 +84,9 @@ yum-config-manager \
 ## Install docker.
 yum update && yum install docker-ce-18.06.1.ce

+## Create /etc/docker directory.
+mkdir /etc/docker
+
 # Setup daemon.
 cat > /etc/docker/daemon.json <<EOF
 {
@@ -70,7 +70,7 @@ For more details on the ComponentConfig have a look at [this section](#configure
 Some hosts require specific kubelet configurations, due to differences in hardware, operating system,
 networking, or other host-specific parameters. The following list provides a few examples.

- The path to the DNS resolution file, as specified by the `--resolve-conf` kubelet
+- The path to the DNS resolution file, as specified by the `--resolv-conf` kubelet
  configuration flag, may differ among operating systems, or depending on whether you are using
  `systemd-resolved`. If this path is wrong, DNS resolution will fail on the Node whose kubelet
  is configured incorrectly.
@@ -57,7 +57,7 @@ This may be caused by a number of problems. The most common are:

  There are two common ways to fix the cgroup driver problem:
  
- 1. Install docker again following instructions
+ 1. Install Docker again following instructions
  [here](/docs/setup/independent/install-kubeadm/#installing-docker).
 1. Change the kubelet config to match the Docker cgroup driver manually, you can refer to
    [Configure cgroup driver used by kubelet on Master Node](/docs/setup/independent/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)
@@ -104,6 +104,10 @@ Right after `kubeadm init` there should not be any pods in these states.
  likely that the Pod Network solution that you installed is somehow broken. You
  might have to grant it more RBAC privileges or use a newer version. Please file
  an issue in the Pod Network providers' issue tracker and get the issue triaged there.
+- If you install a version of Docker older than 1.12.1, remove the `MountFlags=slave` option
+  when booting `dockerd` with `systemd` and restart `docker`. You can see the MountFlags in `/usr/lib/systemd/system/docker.service`.
+  MountFlags can interfere with volumes mounted by Kubernetes, and put the Pods in `CrashLoopBackOff` state.
+  The error happens when Kubernetes does not find `var/run/secrets/kubernetes.io/serviceaccount` files.

 ## `coredns` (or `kube-dns`) is stuck in the `Pending` state

@@ -58,7 +58,7 @@ There are some important limitations of the multizone support:

 * We assume that the different zones are located close to each other in the
 network, so we don't perform any zone-aware routing.  In particular, traffic
-that goes via services might cross zones (even if pods in some pods backing that service
+that goes via services might cross zones (even if some pods backing that service
 exist in the same zone as the client), and this may incur additional latency and cost.

 * Volume zone-affinity will only work with a `PersistentVolume`, and will not
@@ -83,7 +83,7 @@ You can add servers into your cluster by adding the cluster Profile to the serve

 ### Cleanup your cluster (for developers)

-You can reset your cluster and wipe out all configuration and TLS certificates using the the `krib-reset-cluster` Workflow on any of the servers in the cluster.
+You can reset your cluster and wipe out all configuration and TLS certificates using the `krib-reset-cluster` Workflow on any of the servers in the cluster.

 {{< caution >}}
 **Caution:** When running the reset Workflow, be sure not to accidentally target your production cluster!
@@ -32,7 +32,7 @@ a Kubernetes cluster from scratch.

 ## Local-machine Solutions

-* [Minikube](/docs/setup/minikube/) is the recommended method for creating a local, single-node Kubernetes cluster for development and testing. Setup is completely automated and doesn't require a cloud provider account.
+* [Minikube](/docs/setup/minikube/) is a method for creating a local, single-node Kubernetes cluster for development and testing. Setup is completely automated and doesn't require a cloud provider account.

 * [microk8s](https://microk8s.io/) provides a single command installation of the latest Kubernetes release on a local machine for development and testing. Setup is quick, fast (~30 sec) and supports many plugins including Istio with a single command.

@@ -10,7 +10,6 @@ This topic discusses multiple ways to interact with clusters.

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -285,16 +284,16 @@ The redirect capabilities have been deprecated and removed.  Please use a proxy
 There are several different proxies you may encounter when using Kubernetes:

 1.  The [kubectl proxy](#directly-accessing-the-rest-api):
-  
+
    - runs on a user's desktop or in a pod
    - proxies from a localhost address to the Kubernetes apiserver
    - client to proxy uses HTTP
    - proxy to apiserver uses HTTPS
    - locates apiserver
    - adds authentication headers
-    
+
 1.  The [apiserver proxy](#discovering-builtin-services):
-  
+
    - is a bastion built into the apiserver
    - connects a user outside of the cluster to cluster IPs which otherwise might not be reachable
    - runs in the apiserver processes
@@ -302,23 +301,23 @@ There are several different proxies you may encounter when using Kubernetes:
    - proxy to target may use HTTP or HTTPS as chosen by proxy using available information
    - can be used to reach a Node, Pod, or Service
    - does load balancing when used to reach a Service
-    
+
 1.  The [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips):
-  
+
    - runs on each node
    - proxies UDP and TCP
    - does not understand HTTP
    - provides load balancing
    - is just used to reach services
-    
+
 1.  A Proxy/Load-balancer in front of apiserver(s):
-  
+
    - existence and implementation varies from cluster to cluster (e.g. nginx)
    - sits between all clients and one or more apiservers
    - acts as load balancer if there are several apiservers.
-    
+
 1.  Cloud Load Balancers on external services:
-  
+
    - are provided by some cloud providers (e.g. AWS ELB, Google Cloud Load Balancer)
    - are created automatically when the Kubernetes service has type `LoadBalancer`
    - use UDP/TCP only
@@ -16,7 +16,6 @@ well as any provider specific details that may be necessary.

 {{% /capture %}}

-{{< toc >}}

 {{% capture prerequisites %}}

@@ -18,7 +18,6 @@ Dashboard also provides information on the state of Kubernetes resources in your

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -3,6 +3,7 @@ title: Extend the Kubernetes API with CustomResourceDefinitions
 reviewers:
 - deads2k
 - enisoc
+- sttts
 content_template: templates/task
 weight: 20
 ---
@@ -1,174 +0,0 @@
---
-title: Migrate a ThirdPartyResource to CustomResourceDefinition
-reviewers:
- enisoc
- deads2k
-content_template: templates/task
-weight: 50
---
-
-{{% capture overview %}}
-This page shows how to migrate data stored in a ThirdPartyResource (TPR) to a
-[CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions) (CRD).
-
-Kubernetes does not automatically migrate existing TPRs.
-This is due to API changes introduced as part of
-[graduating to beta](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/thirdpartyresources.md)
-under a new name and API group.
-Instead, both TPR and CRD are available and operate independently in Kubernetes 1.7.
-Users must migrate each TPR one by one to preserve their data before upgrading to Kubernetes 1.8.
-
-The simplest way to migrate is to stop all clients that use a given TPR, then delete the TPR and
-start from scratch with a CRD.
-This page describes an optional process that eases the transition by migrating existing TPR data for
-you **on a best-effort basis**.
-{{% /capture %}}
-
-{{% capture prerequisites %}}
-{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-* Make sure your Kubernetes cluster has a **master version of exactly 1.7.x** (any patch release),
-  as this is the only version that supports both TPR and CRD.
-* If you use a TPR-based custom controller, check with the author of the controller first.
-  Some or all of these steps may be unnecessary if the custom controller handles the migration for
-  you.
-* Be familiar with the concept of [custom resources](/docs/concepts/api-extension/custom-resources/),
-  which were known as *third-party resources* until Kubernetes 1.7.
-* Be familiar with [CustomResourceDefinitions](/docs/concepts/api-extension/custom-resources/#customresourcedefinitions),
-  which are a simple way to implement custom resources.
-* **Before performing a migration on real data, conduct a dry run by going through these steps in a test cluster.**
-{{% /capture %}}
-
-{{% capture steps %}}
-## Migrate TPR data
-
-1.  **Rewrite the TPR definition**
-
-    Clients that access the REST API for your custom resource should not need any changes.
-    However, you will need to rewrite your TPR definition as a CRD.
-
-    Make sure you specify values for the CRD fields that match what the server used to fill in for
-    you with TPR.
-
-    For example, if your ThirdPartyResource looks like this:
-
-    
-        apiVersion: extensions/v1beta1
-        kind: ThirdPartyResource
-        metadata:
-          name: cron-tab.stable.example.com
-        description: "A specification of a Pod to run on a cron style schedule"
-        versions:
-        - name: v1
-    
-
-    A matching CustomResourceDefinition could look like this:
-
-    ```yaml
-    apiVersion: apiextensions.k8s.io/v1beta1
-    kind: CustomResourceDefinition
-    metadata:
-      name: crontabs.stable.example.com
-    spec:
-      scope: Namespaced
-      group: stable.example.com
-      versions:
-        - name: v1
-          served: true
-          storage: true
-      names:
-        kind: CronTab
-        plural: crontabs
-        singular: crontab
-    ```
-
-1.  **Install the CustomResourceDefinition**
-
-    While the source TPR is still active, install the matching CRD with `kubectl create`.
-    Existing TPR data remains accessible because TPRs take precedence over CRDs when both try
-    to serve the same resource.
-
-    After you create the CRD, make sure the *Established* condition goes to True.
-    You can check it with a command like this:
-
-    ```shell
-    kubectl get crd -o 'custom-columns=NAME:{.metadata.name},ESTABLISHED:{.status.conditions[?(@.type=="Established")].status}'
-    ```
-
-    The output should look like this:
-
-    ```console
-    NAME                          ESTABLISHED
-    crontabs.stable.example.com   True
-    ```
-
-1.  **Stop all clients that use the TPR**
-
-    The API server attempts to prevent TPR data for the resource from changing while it
-    copies objects to the CRD, but it can't guarantee consistency in all cases, such as with
-    [multiple masters](/docs/admin/high-availability/).
-    Stopping clients, such as TPR-based custom controllers, helps to avoid inconsistencies in
-    the copied data.
-
-    In addition, clients that watch TPR data do not receive any more events once the migration
-    begins.
-    You must restart them after the migration completes so they start watching CRD data instead.
-
-1.  **Back up TPR data**
-
-    In case the data migration fails, save a copy of existing data for the resource:
-
-    ```shell
-    kubectl get crontabs --all-namespaces -o yaml > crontabs.yaml
-    ```
-
-    You should also save a copy of the TPR definition if you don't have one already:
-
-    ```shell
-    kubectl get thirdpartyresource cron-tab.stable.example.com -o yaml --export > tpr.yaml
-    ```
-
-1.  **Delete the TPR definition**
-
-    Normally, when you delete a TPR definition, the API server tries to clean up any objects stored
-    in that resource.
-    Because a matching CRD exists, the server copies objects to the CRD instead of deleting them.
-
-    ```shell
-    kubectl delete thirdpartyresource cron-tab.stable.example.com
-    ```
-
-1.  **Verify the new CRD data**
-
-    It can take up to 10 seconds for the TPR controller to notice when you delete the TPR definition
-    and to initiate the migration. The TPR data remains accessible during this time.
-
-    Once the migration completes, the resource begins serving through the CRD.
-    Check that all your objects were correctly copied:
-
-    ```shell
-    kubectl get crontabs --all-namespaces -o yaml
-    ```
-
-    If the copy failed, you can quickly revert to the set of objects that existed just before the
-    migration by recreating the TPR definition:
-
-    ```shell
-    kubectl create -f tpr.yaml
-    ```
-
-1.  **Restart clients**
-
-    After verifying the CRD data, restart any clients you stopped before the migration, such as
-    custom controllers and other watchers.
-    These clients now access CRD data when they make requests on the same API endpoints
-    that the TPR previously served.
-{{% /capture %}}
-
-{{% capture whatsnext %}}
-* Learn more about [custom resources](/docs/concepts/api-extension/custom-resources/).
-* Learn more about [using CustomResourceDefinitions](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/).
-* See [CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions).
-{{% /capture %}}
-
-
@@ -32,7 +32,9 @@ the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to

 1. List the PersistentVolumes in your cluster:

-       kubectl get pv
+    ```shell
+    kubectl get pv
+    ```

    The output is similar to this:

@@ -46,13 +48,17 @@ the corresponding `PersistentVolume` is not be deleted. Instead, it is moved to

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

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

    where `<your-pv-name>` is the name of your chosen PersistentVolume.

 1. Verify that your chosen PersistentVolume has the right policy:

-       kubectl get pv
+    ```shell
+    kubectl get pv
+    ```

    The output is similar to this:

@@ -15,7 +15,6 @@ running cluster.

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -21,7 +21,6 @@ in the Kubernetes source directory for a canonical example.

 {{% /capture %}}

-{{< toc >}}

 {{% capture prerequisites %}}

@@ -12,7 +12,6 @@ content_template: templates/task

 {{% /capture %}}

-{{< toc >}}

 {{% capture prerequisites %}}

@@ -20,7 +20,6 @@ directives.

 {{% /capture %}}

-{{< toc >}}

 {{% capture prerequisites %}}

@@ -178,7 +177,7 @@ spec:
 ```

 This pod runs in the `Guaranteed` QoS class because `requests` are equal to `limits`.
-And the container's resource limit for the CPU resource is an integer greater than 
+And the container's resource limit for the CPU resource is an integer greater than
 or equal to one. The `nginx` container is granted 2 exclusive CPUs.


@@ -213,8 +212,8 @@ spec:
 ```

 This pod runs in the `Guaranteed` QoS class because only `limits` are specified
-and `requests` are set equal to `limits` when not explicitly specified. And the 
-container's resource limit for the CPU resource is an integer greater than or 
+and `requests` are set equal to `limits` when not explicitly specified. And the
+container's resource limit for the CPU resource is an integer greater than or
 equal to one. The `nginx` container is granted 2 exclusive CPUs.

 {{% /capture %}}
@@ -22,7 +22,6 @@ To dive a little deeper into implementation details, all cloud controller manage

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -18,54 +18,15 @@ vacated by the evicted critical add-on pod or the amount of resources available

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

-## Rescheduler: guaranteed scheduling of critical add-ons
-**Rescheduler is deprecated as of Kubernetes 1.10 and will be removed in version 1.12 in
-accordance with the [deprecation policy](/docs/reference/deprecation-policy) for beta features.**

-**To avoid eviction of critical pods, you must
-[enable priorities in scheduler](/docs/concepts/configuration/pod-priority-preemption/)
-before upgrading to Kubernetes 1.10 or higher.**
-
-Rescheduler ensures that critical pods created by DaemonSet controller are always scheduled
-(assuming the cluster has enough resources to run the critical add-on pods in the absence of regular pods).
-If the scheduler determines that no node has enough free resources to run the critical add-on pod
-given the pods that are already running in the cluster
-(indicated by critical add-on pod's pod condition PodScheduled set to false, the reason set to Unschedulable)
-the rescheduler tries to free up space for the DaemonSet critical pod by evicting some pods; then the scheduler will schedule the add-on pod.
-
-To avoid situation when another pod is scheduled into the space prepared for the critical add-on,
-the chosen node gets a temporary taint "CriticalAddonsOnly" before the eviction(s)
-(see [more details](https://git.k8s.io/community/contributors/design-proposals/scheduling/taint-toleration-dedicated.md)).
-Each critical add-on has to tolerate it,
-while the other pods shouldn't tolerate the taint. The taint is removed once the add-on is successfully scheduled.
-
-*Warning:* currently there is no guarantee which node is chosen and which pods are being killed
-in order to schedule critical pods, so if rescheduler is enabled your pods might be occasionally
-killed for this purpose. Please ensure that rescheduler is not enabled along with priorities & preemptions in default-scheduler as rescheduler is oblivious to priorities and it may evict high priority pods, instead of low priority ones.
-
-## Config
-
-Rescheduler doesn't have any user facing configuration (component config) or API.
-
-### Marking pod as critical when using Rescheduler. 
+### Marking pod as critical

 To be considered critical, the pod has to run in the `kube-system` namespace (configurable via flag) and

-* have the `scheduler.alpha.kubernetes.io/critical-pod` annotation set to empty string, and
-* have the PodSpec's `tolerations` field set to `[{"key":"CriticalAddonsOnly", "operator":"Exists"}]`.
+* Have the priorityClassName set as "system-cluster-critical" or "system-node-critical", the latter being the highest for entire cluster. Alternatively, you could add an annotation `scheduler.alpha.kubernetes.io/critical-pod` as key and empty string as value to your pod, but this annotation is deprecated as of version 1.13 and will be removed in 1.14.

-The first one marks a pod a critical. The second one is required by Rescheduler algorithm.
-
-A pod could also be considered critical, if its priority is greater than or equal to system-critical-priority.
-
-### Marking pod as critical when priorites are enabled.
-
-To be considered critical, the pod has to run in the `kube-system` namespace (configurable via flag) and
-
-* Have the priorityClass set as "system-cluster-critical" or "system-node-critical", the latter being the highest for entire cluster and `scheduler.alpha.kubernetes.io/critical-pod` annotation set to empty string(This will be deprecated too).

 {{% /capture %}}
@@ -14,7 +14,6 @@ This document describes how to use kube-up/down scripts to manage highly availab

 {{% /capture %}}

-{{< toc >}}

 {{% capture prerequisites %}}

@@ -21,7 +21,7 @@ Before proceeding:
 - You need to have a `kubeadm` HA cluster running version 1.11 or higher.
 - Make sure you read the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.12.md) carefully.
 - Make sure to back up any important components, such as app-level state stored in a database. `kubeadm upgrade` does not touch your workloads, only components internal to Kubernetes, but backups are always a best practice.
- Check the prerequisites for [Upgrading/downgrading kubeadm clusters between v1.11 to v1.12](/docs/tasks/administer-cluster/kubeadm-upgrade-1-12/).
+- Check the prerequisites for [Upgrading/downgrading kubeadm clusters between v1.11 to v1.12](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-12/).

 {{< note >}}
 **Note**: All commands on any control plane or etcd node should be
@@ -68,7 +68,7 @@ kubectl get pod default-cpu-demo --output=yaml --namespace=default-cpu-example
 The output shows that the Pod's Container has a CPU request of 500 millicpus and
 a CPU limit of 1 cpu. These are the default values specified by the LimitRange.

-```shel
+```shell
 containers:
 - image: nginx
  imagePullPolicy: Always
@@ -70,7 +70,7 @@ kubectl get pod default-mem-demo --output=yaml --namespace=default-mem-example
 The output shows that the Pod's Container has a memory request of 256 MiB and
 a memory limit of 512 MiB. These are the default values specified by the LimitRange.

-```shel
+```shell
 containers:
 - image: nginx
  imagePullPolicy: Always
@@ -20,7 +20,6 @@ This example demonstrates how to use Kubernetes namespaces to subdivide your clu

 {{% /capture %}}

-{{< toc >}}

 {{% capture prerequisites %}}

@@ -18,7 +18,6 @@ nodes become unstable.

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

@@ -205,7 +204,7 @@ If `nodefs` filesystem has met eviction thresholds, `kubelet` frees up disk spac

 If the `kubelet` is unable to reclaim sufficient resource on the node, `kubelet` begins evicting Pods.

-The `kubelet` ranks Pods for eviction first by whether or not their usage  of the starved resource exceeds requests, 
+The `kubelet` ranks Pods for eviction first by whether or not their usage of the starved resource exceeds requests,
 then by [Priority](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/), and then by the consumption of the starved compute resource relative to the Pods' scheduling requests.

 As a result, `kubelet` ranks and evicts Pods in the following order:
@@ -213,15 +212,15 @@ As a result, `kubelet` ranks and evicts Pods in the following order:
 * `BestEffort` or `Burstable` Pods whose usage of a starved resource exceeds its request.
 Such pods are ranked by Priority, and then usage above request.
 * `Guaranteed` pods and `Burstable` pods whose usage is beneath requests are evicted last.
-`Guaranteed` Pods are guaranteed only when requests and limits are specified for all 
-the containers and they are equal. Such pods are guaranteed to never be evicted because 
+`Guaranteed` Pods are guaranteed only when requests and limits are specified for all
+the containers and they are equal. Such pods are guaranteed to never be evicted because
 of another Pod's resource consumption. If a system daemon (such as `kubelet`, `docker`,
 and `journald`) is consuming more resources than were reserved via `system-reserved` or
-`kube-reserved` allocations, and the node only has `Guaranteed` or `Burstable` Pods using 
-less than requests remaining, then the node must choose to evict such a Pod in order to 
+`kube-reserved` allocations, and the node only has `Guaranteed` or `Burstable` Pods using
+less than requests remaining, then the node must choose to evict such a Pod in order to
 preserve node stability and to limit the impact of the unexpected consumption to other Pods.
 In this case, it will choose to evict pods of Lowest Priority first.
- 
+
 If necessary, `kubelet` evicts Pods one at a time to reclaim disk when `DiskPressure`
 is encountered. If the `kubelet` is responding to `inode` starvation, it reclaims
 `inodes` by evicting Pods with the lowest quality of service first. If the `kubelet`
@@ -23,7 +23,6 @@ on each node.

 {{% /capture %}}

-{{< toc >}}

 {{% capture prerequisites %}}

@@ -17,7 +17,6 @@ The `cloud-controller-manager` can be linked to any cloud provider that satisfie

 {{% /capture %}}

-{{< toc >}}

 {{% capture body %}}

--- a/Show More
+++ b/Show More
				`@@ -0,0 +1 @@`
				<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 215.9892 128.40633"><defs><style>.cls-1{fill:#f9f9f9;}.cls-2{fill:#4c81c2;}</style></defs><title>ibm_featured_logo</title><rect class="cls-1" x="-5.9997" y="-8.99955" width="229.48853" height="143.9928"/><polygon class="cls-2" points="190.441 33.693 162.454 33.693 164.178 28.868 190.441 28.868 190.441 33.693"/><path class="cls-2" d="M115.83346,28.867l25.98433-.003,1.7014,4.83715c.01251-.00687-27.677.00593-27.677,0C115.84224,33.69422,115.82554,28.867,115.83346,28.867Z"/><path class="cls-2" d="M95.19668,28.86593A18.6894,18.6894,0,0,1,106.37358,33.7s-47.10052.00489-47.10052,0V28.86488Z"/><rect class="cls-2" x="22.31176" y="28.86593" width="32.72063" height="4.82558"/><path class="cls-2" d="M190.44115,42.74673h-31.194s1.70142-4.79994,1.691-4.80193h29.50305Z"/><polygon class="cls-2" points="146.734 42.753 115.832 42.753 115.832 37.944 145.041 37.944 146.734 42.753"/><path class="cls-2" d="M110.04127,37.94271a12.47,12.47,0,0,1,1.35553,4.80214H59.28193V37.94271Z"/><rect class="cls-2" x="22.31176" y="37.94271" width="32.72063" height="4.80214"/><polygon class="cls-2" points="156.056 51.823 157.768 46.998 181.191 47.005 181.191 51.812 156.056 51.823"/><polygon class="cls-2" points="148.237 46.997 149.944 51.823 125.046 51.823 125.046 46.997 148.237 46.997"/><path class="cls-2" d="M111.81,46.99627a15.748,15.748,0,0,1-.68923,4.82641H96.85137V46.99627Z"/><rect class="cls-2" x="31.43162" y="47.01973" width="14.06406" height="4.8019"/><rect class="cls-2" x="68.7486" y="46.99627" width="14.03976" height="4.82537"/><path class="cls-2" d="M138.87572,57.03292s.004,3.65225.001,3.65913H125.04558V55.89h26.35583l1.637,4.4773c.00773.00292,1.57841-4.48815,1.58153-4.47835h26.56223V60.692h-13.763c-.00124-.00687-.00771-3.65819-.00771-3.65819l-1.273,3.65819-25.99183-.00687Z"/><path class="cls-2" d="M68.7486,55.889h40.30365v-.00188a18.13723,18.13723,0,0,1-3.99812,4.80494s-36.30647.00668-36.30647,0Z"/><rect class="cls-2" x="31.43162" y="55.88794" width="14.06406" height="4.80316"/><rect class="cls-2" x="167.41912" y="64.94348" width="13.76302" height="4.80212"/><path class="cls-2" d="M138.87572,64.94348H125.04558V69.7456c-.00688-.0025,13.83411.00167,13.83411,0C138.87969,69.7431,138.89532,64.94348,138.87572,64.94348Z"/><path class="cls-2" d="M164.63927,64.94348c-.06255-.007-1.61218,4.79962-1.67723,4.80212l-19.60378.00835c-.01543-.00751-1.72371-4.81745-1.725-4.81047Z"/><path class="cls-2" d="M68.74672,64.94233H104.985a23.7047,23.7047,0,0,1,4.32076,4.80327c.06609-.0025-40.5581.00167-40.5581,0Z"/><path class="cls-2" d="M45.49359,69.74436v-4.802H31.45487V69.7431Z"/><rect class="cls-2" x="167.41912" y="73.99693" width="13.76198" height="4.80295"/><rect class="cls-2" x="125.04474" y="73.99693" width="13.83097" height="4.80212"/><path class="cls-2" d="M159.74351,78.8224c.00376-.02169,1.69745-4.82964,1.72373-4.82547H144.80219c-.029-.00209,1.70848,4.80378,1.70848,4.80378S159.7404,78.84241,159.74351,78.8224Z"/><path class="cls-2" d="M68.74766,78.79905c0,.01919-.00094-4.80212,0-4.803H82.9958s.01272,4.80462,0,4.80462C82.98224,78.80072,68.74766,78.79489,68.74766,78.79905Z"/><path class="cls-2" d="M111.30529,73.9961a13.94783,13.94783,0,0,1,.89542,4.825H97.10364v-4.825Z"/><rect class="cls-2" x="31.45487" y="73.9961" width="14.03872" height="4.80171"/><rect class="cls-2" x="167.41912" y="82.86525" width="23.0212" height="4.80421"/><rect class="cls-2" x="115.83139" y="82.86525" width="23.04432" height="4.80421"/><polygon class="cls-2" points="156.647 87.669 149.618 87.669 147.931 82.865 158.272 82.865 156.647 87.669"/><path class="cls-2" d="M22.3099,82.86525v4.80212H55.008c.01366.00751-.01469-4.79919,0-4.79919Z"/><path class="cls-2" d="M111.60237,82.86525c-.3442,1.58445-.65962,3.5158-1.81732,4.80421l-.43175-.00209H59.28005V82.86525Z"/><polygon class="cls-2" points="153.461 96.733 152.814 96.733 151.171 91.92 155.147 91.92 153.461 96.733"/><rect class="cls-2" x="167.41788" y="91.91953" width="23.02244" height="4.82547"/><path class="cls-2" d="M59.27307,96.73333V91.92745s47.24073.00585,47.37623.00585A17.945,17.945,0,0,1,94.43864,96.745l-35.15859-.00959"/><rect class="cls-2" x="115.83139" y="91.91953" width="23.04432" height="4.82547"/><path class="cls-2" d="M55.008,91.94079s-.01469,4.79253,0,4.79253c.01366,0-32.6885.0196-32.69809.00961-.00888-.00961.00875-4.81548,0-4.81548S54.9933,91.95664,55.008,91.94079Z"/></svg>