diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index c27bb0210c..f35c0ea831 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -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 diff --git a/README.md b/README.md index b92d82f7aa..9824646028 100644 --- a/README.md +++ b/README.md @@ -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 diff --git a/content/en/blog/OWNERS b/content/en/blog/OWNERS index 688065f9a7..73d6d59c1a 100644 --- a/content/en/blog/OWNERS +++ b/content/en/blog/OWNERS @@ -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 diff --git a/content/en/blog/_posts/2017-04-00-Rbac-Support-In-Kubernetes.md b/content/en/blog/_posts/2017-04-00-Rbac-Support-In-Kubernetes.md index 0641951b25..26d8b40186 100644 --- a/content/en/blog/_posts/2017-04-00-Rbac-Support-In-Kubernetes.md +++ b/content/en/blog/_posts/2017-04-00-Rbac-Support-In-Kubernetes.md @@ -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) diff --git a/content/en/blog/_posts/2018-05-04-Announcing-Kubeflow-0.1.md b/content/en/blog/_posts/2018-05-04-Announcing-Kubeflow-0.1.md index d7483c2318..2b23ac523b 100644 --- a/content/en/blog/_posts/2018-05-04-Announcing-Kubeflow-0.1.md +++ b/content/en/blog/_posts/2018-05-04-Announcing-Kubeflow-0.1.md @@ -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. diff --git a/content/en/blog/_posts/2018-05-05-hugo-migration.md b/content/en/blog/_posts/2018-05-05-hugo-migration.md index 2ac271684b..194cf7b519 100644 --- a/content/en/blog/_posts/2018-05-05-hugo-migration.md +++ b/content/en/blog/_posts/2018-05-05-hugo-migration.md @@ -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. diff --git a/content/en/blog/_posts/2018-05-29-announcing-kustomize.md b/content/en/blog/_posts/2018-05-29-announcing-kustomize.md index 3ca0b54401..908ce72363 100644 --- a/content/en/blog/_posts/2018-05-29-announcing-kustomize.md +++ b/content/en/blog/_posts/2018-05-29-announcing-kustomize.md @@ -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 diff --git a/content/en/blog/_posts/2018-06-06-4-years-of-k8s.md b/content/en/blog/_posts/2018-06-06-4-years-of-k8s.md index dc71dd0d39..7e6f60383a 100644 --- a/content/en/blog/_posts/2018-06-06-4-years-of-k8s.md +++ b/content/en/blog/_posts/2018-06-06-4-years-of-k8s.md @@ -23,6 +23,6 @@ The version of Kubernetes at that point was really just a shadow of what it was
-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! 🎉🎉🎉 diff --git a/content/en/blog/_posts/2018-06-07-dynamic-ingress-kubernetes.md b/content/en/blog/_posts/2018-06-07-dynamic-ingress-kubernetes.md index 43f771257a..ccddbdfb77 100644 --- a/content/en/blog/_posts/2018-06-07-dynamic-ingress-kubernetes.md +++ b/content/en/blog/_posts/2018-06-07-dynamic-ingress-kubernetes.md @@ -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:///models//. 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:///models//. 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. diff --git a/content/en/blog/_posts/2018-06-28-Airflow-Kubernetes-Operator.md b/content/en/blog/_posts/2018-06-28-Airflow-Kubernetes-Operator.md index 48add086c1..bb77bd1e5a 100644 --- a/content/en/blog/_posts/2018-06-28-Airflow-Kubernetes-Operator.md +++ b/content/en/blog/_posts/2018-06-28-Airflow-Kubernetes-Operator.md @@ -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 diff --git a/content/en/blog/_posts/2018-07-10-coredns-ga.md b/content/en/blog/_posts/2018-07-10-coredns-ga.md index 4745665e40..01c438f131 100644 --- a/content/en/blog/_posts/2018-07-10-coredns-ga.md +++ b/content/en/blog/_posts/2018-07-10-coredns-ga.md @@ -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` diff --git a/content/en/blog/_posts/2018-10-02-network-bootable-farm-with-ltsp.md b/content/en/blog/_posts/2018-10-02-network-bootable-farm-with-ltsp.md index 0a45f18b02..2039a4d5b6 100644 --- a/content/en/blog/_posts/2018-10-02-network-bootable-farm-with-ltsp.md +++ b/content/en/blog/_posts/2018-10-02-network-bootable-farm-with-ltsp.md @@ -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._ diff --git a/content/en/blog/_posts/2018-10-08-support-for-azure-vmss.md b/content/en/blog/_posts/2018-10-08-support-for-azure-vmss.md index 79875cc21d..64bae6d87b 100644 --- a/content/en/blog/_posts/2018-10-08-support-for-azure-vmss.md +++ b/content/en/blog/_posts/2018-10-08-support-for-azure-vmss.md @@ -89,7 +89,7 @@ acs-engine deploy --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 \ diff --git a/content/en/blog/_posts/2018-10-18-tips-for-first-kubecon-presentation-part-1.md b/content/en/blog/_posts/2018-10-18-tips-for-first-kubecon-presentation-part-1.md new file mode 100644 index 0000000000..3c612e384e --- /dev/null +++ b/content/en/blog/_posts/2018-10-18-tips-for-first-kubecon-presentation-part-1.md @@ -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! + +
{{< tweet 1044345018490662912 >}}
+ +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. diff --git a/content/en/blog/_posts/2018-10-26-tips-for-first-kubecon-presentation-part-2.md b/content/en/blog/_posts/2018-10-26-tips-for-first-kubecon-presentation-part-2.md new file mode 100644 index 0000000000..fc61f60c84 --- /dev/null +++ b/content/en/blog/_posts/2018-10-26-tips-for-first-kubecon-presentation-part-2.md @@ -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 >}} diff --git a/content/en/case-studies/OWNERS b/content/en/case-studies/OWNERS index c8326fe242..dd978fcd5a 100644 --- a/content/en/case-studies/OWNERS +++ b/content/en/case-studies/OWNERS @@ -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 diff --git a/content/en/case-studies/ibm/ibm_featured_logo.svg b/content/en/case-studies/ibm/ibm_featured_logo.svg new file mode 100644 index 0000000000..577d8e97d9 --- /dev/null +++ b/content/en/case-studies/ibm/ibm_featured_logo.svg @@ -0,0 +1 @@ +ibm_featured_logo \ No newline at end of file diff --git a/content/en/case-studies/ibm/index.html b/content/en/case-studies/ibm/index.html index 69f4ea31f2..4f6927416c 100644 --- a/content/en/case-studies/ibm/index.html +++ b/content/en/case-studies/ibm/index.html @@ -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: > diff --git a/content/en/docs/concepts/architecture/cloud-controller.md b/content/en/docs/concepts/architecture/cloud-controller.md index c2eb94f6cf..191b954645 100644 --- a/content/en/docs/concepts/architecture/cloud-controller.md +++ b/content/en/docs/concepts/architecture/cloud-controller.md @@ -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) diff --git a/content/en/docs/concepts/architecture/master-node-communication.md b/content/en/docs/concepts/architecture/master-node-communication.md index 9c1064cfcc..0314197bc4 100644 --- a/content/en/docs/concepts/architecture/master-node-communication.md +++ b/content/en/docs/concepts/architecture/master-node-communication.md @@ -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. diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md index 222a21c020..f5bb11bf37 100644 --- a/content/en/docs/concepts/architecture/nodes.md +++ b/content/en/docs/concepts/architecture/nodes.md @@ -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. diff --git a/content/en/docs/concepts/cluster-administration/addons.md b/content/en/docs/concepts/cluster-administration/addons.md index fc6bf0b6c5..dd12e76074 100644 --- a/content/en/docs/concepts/cluster-administration/addons.md +++ b/content/en/docs/concepts/cluster-administration/addons.md @@ -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. diff --git a/content/en/docs/concepts/cluster-administration/certificates.md b/content/en/docs/concepts/cluster-administration/certificates.md index 129470ddf0..48592dc7c3 100644 --- a/content/en/docs/concepts/cluster-administration/certificates.md +++ b/content/en/docs/concepts/cluster-administration/certificates.md @@ -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 = ST = @@ -89,10 +88,10 @@ manually through `easyrsa`, `openssl` or `cfssl`. O = OU = CN = - + [ 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 = IP.2 = - + [ 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": "", "OU": "" }] - } + } 1. Generate the key and certificate for the API server, which are by default saved into file `server-key.pem` and `server.pem` respectively: diff --git a/content/en/docs/concepts/cluster-administration/cloud-providers.md b/content/en/docs/concepts/cluster-administration/cloud-providers.md index f87b567ca3..e3c7f153af 100644 --- a/content/en/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/en/docs/concepts/cluster-administration/cloud-providers.md @@ -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). diff --git a/content/en/docs/concepts/cluster-administration/federation.md b/content/en/docs/concepts/cluster-administration/federation.md index eaa33d4c60..16fc92d1f7 100644 --- a/content/en/docs/concepts/cluster-administration/federation.md +++ b/content/en/docs/concepts/cluster-administration/federation.md @@ -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: diff --git a/content/en/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/en/docs/concepts/cluster-administration/kubelet-garbage-collection.md index 99364fc56e..6d12aa176d 100644 --- a/content/en/docs/concepts/cluster-administration/kubelet-garbage-collection.md +++ b/content/en/docs/concepts/cluster-administration/kubelet-garbage-collection.md @@ -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%. diff --git a/content/en/docs/concepts/cluster-administration/logging.md b/content/en/docs/concepts/cluster-administration/logging.md index 731efcf9e9..f64e0e0aa3 100644 --- a/content/en/docs/concepts/cluster-administration/logging.md +++ b/content/en/docs/concepts/cluster-administration/logging.md @@ -15,7 +15,6 @@ However, the native functionality provided by a container engine or runtime is u {{% /capture %}} -{{< toc >}} {{% capture body %}} diff --git a/content/en/docs/concepts/cluster-administration/manage-deployment.md b/content/en/docs/concepts/cluster-administration/manage-deployment.md index c50f54ce23..e32fe5b8fb 100644 --- a/content/en/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/en/docs/concepts/cluster-administration/manage-deployment.md @@ -14,7 +14,6 @@ You've deployed your application and exposed it via a service. Now what? Kuberne {{% /capture %}} -{{< toc >}} {{% capture body %}} diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md index 924b72fd76..e0d7281d26 100644 --- a/content/en/docs/concepts/cluster-administration/networking.md +++ b/content/en/docs/concepts/cluster-administration/networking.md @@ -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 %}} diff --git a/content/en/docs/concepts/configuration/assign-pod-node.md b/content/en/docs/concepts/configuration/assign-pod-node.md index 1bb887fa52..d1d9cffc53 100644 --- a/content/en/docs/concepts/configuration/assign-pod-node.md +++ b/content/en/docs/concepts/configuration/assign-pod-node.md @@ -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/) diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md index 13a319fc71..b98137b871 100644 --- a/content/en/docs/concepts/configuration/secret.md +++ b/content/en/docs/concepts/configuration/secret.md @@ -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 >}} diff --git a/content/en/docs/concepts/configuration/taint-and-toleration.md b/content/en/docs/concepts/configuration/taint-and-toleration.md index ceab0e271a..bb41dca5f0 100644 --- a/content/en/docs/concepts/configuration/taint-and-toleration.md +++ b/content/en/docs/concepts/configuration/taint-and-toleration.md @@ -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), diff --git a/content/en/docs/concepts/containers/container-environment-variables.md b/content/en/docs/concepts/containers/container-environment-variables.md index cefa41c50a..b8b3c28a6b 100644 --- a/content/en/docs/concepts/containers/container-environment-variables.md +++ b/content/en/docs/concepts/containers/container-environment-variables.md @@ -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 %}} - - diff --git a/content/en/docs/concepts/containers/container-lifecycle-hooks.md b/content/en/docs/concepts/containers/container-lifecycle-hooks.md index 633170db63..f85569032b 100644 --- a/content/en/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/en/docs/concepts/containers/container-lifecycle-hooks.md @@ -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 %}} - - diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md index 045529d5b8..c35aad845b 100644 --- a/content/en/docs/concepts/containers/images.md +++ b/content/en/docs/concepts/containers/images.md @@ -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 diff --git a/content/en/docs/concepts/containers/runtime-class.md b/content/en/docs/concepts/containers/runtime-class.md index dfb75ab724..c953cc9f4a 100644 --- a/content/en/docs/concepts/containers/runtime-class.md +++ b/content/en/docs/concepts/containers/runtime-class.md @@ -140,7 +140,6 @@ This page describes the RuntimeClass resource and runtime selection mechanism. {{% /capture %}} -{{< toc >}} {{% capture body %}} diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md index e2f521a806..64954f2dfe 100644 --- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md +++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md @@ -8,7 +8,6 @@ content_template: templates/concept weight: 10 --- -{{< toc >}} {{% capture overview %}} diff --git a/content/en/docs/concepts/overview/kubernetes-api.md b/content/en/docs/concepts/overview/kubernetes-api.md index 464799628b..8bf6b92bfa 100644 --- a/content/en/docs/concepts/overview/kubernetes-api.md +++ b/content/en/docs/concepts/overview/kubernetes-api.md @@ -22,7 +22,6 @@ Kubernetes itself is decomposed into multiple components, which interact through {{% /capture %}} -{{< toc >}} {{% capture body %}} diff --git a/content/en/docs/concepts/overview/working-with-objects/labels.md b/content/en/docs/concepts/overview/working-with-objects/labels.md index b4fb6959cc..65b6430ed2 100644 --- a/content/en/docs/concepts/overview/working-with-objects/labels.md +++ b/content/en/docs/concepts/overview/working-with-objects/labels.md @@ -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 %}} \ No newline at end of file +{{% /capture %}} diff --git a/content/en/docs/concepts/overview/working-with-objects/names.md b/content/en/docs/concepts/overview/working-with-objects/names.md index 2c3cbec15d..7499a96a66 100644 --- a/content/en/docs/concepts/overview/working-with-objects/names.md +++ b/content/en/docs/concepts/overview/working-with-objects/names.md @@ -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 %}} \ No newline at end of file +{{% /capture %}} diff --git a/content/en/docs/concepts/overview/working-with-objects/namespaces.md b/content/en/docs/concepts/overview/working-with-objects/namespaces.md index 86ac5c3573..eb10f1067b 100644 --- a/content/en/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/en/docs/concepts/overview/working-with-objects/namespaces.md @@ -15,7 +15,6 @@ These virtual clusters are called namespaces. {{% /capture %}} -{{< toc >}} {{% capture body %}} diff --git a/content/en/docs/concepts/policy/pod-security-policy.md b/content/en/docs/concepts/policy/pod-security-policy.md index 93d959144a..89723642e3 100644 --- a/content/en/docs/concepts/policy/pod-security-policy.md +++ b/content/en/docs/concepts/policy/pod-security-policy.md @@ -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`. diff --git a/content/en/docs/concepts/policy/resource-quotas.md b/content/en/docs/concepts/policy/resource-quotas.md index 5fbc36c45e..d2469b9f9b 100644 --- a/content/en/docs/concepts/policy/resource-quotas.md +++ b/content/en/docs/concepts/policy/resource-quotas.md @@ -15,7 +15,6 @@ Resource quotas are a tool for administrators to address this concern. {{% /capture %}} -{{< toc >}} {{% capture body %}} diff --git a/content/en/docs/concepts/services-networking/connect-applications-service.md b/content/en/docs/concepts/services-networking/connect-applications-service.md index 730ec739c5..c01eb8c68f 100644 --- a/content/en/docs/concepts/services-networking/connect-applications-service.md +++ b/content/en/docs/concepts/services-networking/connect-applications-service.md @@ -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 %}} - diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index 9423fc26f9..9fc2bb79b4 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -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 %}} - diff --git a/content/en/docs/concepts/storage/dynamic-provisioning.md b/content/en/docs/concepts/storage/dynamic-provisioning.md index cb180fb706..0a30dc447b 100644 --- a/content/en/docs/concepts/storage/dynamic-provisioning.md +++ b/content/en/docs/concepts/storage/dynamic-provisioning.md @@ -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 %}} - - diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index 688a142f66..28fc8b4f1a 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -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 GCP or AWS, 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 GCP or AWS, 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 diff --git a/content/en/docs/concepts/storage/volume-snapshot-classes.md b/content/en/docs/concepts/storage/volume-snapshot-classes.md index 5ad05107eb..fcc16d4ef3 100644 --- a/content/en/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/en/docs/concepts/storage/volume-snapshot-classes.md @@ -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 %}} diff --git a/content/en/docs/concepts/storage/volume-snapshots.md b/content/en/docs/concepts/storage/volume-snapshots.md index 73647b7825..6b57db96aa 100644 --- a/content/en/docs/concepts/storage/volume-snapshots.md +++ b/content/en/docs/concepts/storage/volume-snapshots.md @@ -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: diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index 5ad6ec22c2..5f16c2b464 100644 --- a/content/en/docs/concepts/storage/volumes.md +++ b/content/en/docs/concepts/storage/volumes.md @@ -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 %}} - - diff --git a/content/en/docs/concepts/workloads/controllers/cron-jobs.md b/content/en/docs/concepts/workloads/controllers/cron-jobs.md index 1c4e53ff95..3169cb13bf 100644 --- a/content/en/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/en/docs/concepts/workloads/controllers/cron-jobs.md @@ -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. diff --git a/content/en/docs/concepts/workloads/controllers/daemonset.md b/content/en/docs/concepts/workloads/controllers/daemonset.md index 92a995b042..5fd9fd4396 100644 --- a/content/en/docs/concepts/workloads/controllers/daemonset.md +++ b/content/en/docs/concepts/workloads/controllers/daemonset.md @@ -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 diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md index 8bc7f2f73b..be407b6ce1 100644 --- a/content/en/docs/concepts/workloads/controllers/deployment.md +++ b/content/en/docs/concepts/workloads/controllers/deployment.md @@ -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: + Mounts: + Volumes: +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 @@ -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 $? diff --git a/content/en/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/content/en/docs/concepts/workloads/controllers/jobs-run-to-completion.md index d66543b763..d443c3bee8 100644 --- a/content/en/docs/concepts/workloads/controllers/jobs-run-to-completion.md +++ b/content/en/docs/concepts/workloads/controllers/jobs-run-to-completion.md @@ -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 diff --git a/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md index 1f8e355ff8..3ee76015f6 100644 --- a/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -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 diff --git a/content/en/docs/concepts/workloads/pods/disruptions.md b/content/en/docs/concepts/workloads/pods/disruptions.md index 1a620c9b75..79b0ac00d9 100644 --- a/content/en/docs/concepts/workloads/pods/disruptions.md +++ b/content/en/docs/concepts/workloads/pods/disruptions.md @@ -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 %}} - - - diff --git a/content/en/docs/concepts/workloads/pods/init-containers.md b/content/en/docs/concepts/workloads/pods/init-containers.md index 4fb114f66c..6ee6dd45ce 100644 --- a/content/en/docs/concepts/workloads/pods/init-containers.md +++ b/content/en/docs/concepts/workloads/pods/init-containers.md @@ -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 %}} - - - diff --git a/content/en/docs/concepts/workloads/pods/pod-overview.md b/content/en/docs/concepts/workloads/pods/pod-overview.md index 3a467b6674..d08433ef39 100644 --- a/content/en/docs/concepts/workloads/pods/pod-overview.md +++ b/content/en/docs/concepts/workloads/pods/pod-overview.md @@ -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 %}} - - diff --git a/content/en/docs/concepts/workloads/pods/pod.md b/content/en/docs/concepts/workloads/pods/pod.md index 7b000b4768..d468102304 100644 --- a/content/en/docs/concepts/workloads/pods/pod.md +++ b/content/en/docs/concepts/workloads/pods/pod.md @@ -12,7 +12,6 @@ managed in Kubernetes. {{% /capture %}} -{{< toc >}} {{% capture body %}} diff --git a/content/en/docs/concepts/workloads/pods/podpreset.md b/content/en/docs/concepts/workloads/pods/podpreset.md index f6e2ec494c..6711ba2ffe 100644 --- a/content/en/docs/concepts/workloads/pods/podpreset.md +++ b/content/en/docs/concepts/workloads/pods/podpreset.md @@ -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 %}} - - diff --git a/content/en/docs/contribute/intermediate.md b/content/en/docs/contribute/intermediate.md index 499e699d56..3fed21a05b 100644 --- a/content/en/docs/contribute/intermediate.md +++ b/content/en/docs/contribute/intermediate.md @@ -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 @@ -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. diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md index 90d3c51ccf..7120607d2e 100644 --- a/content/en/docs/contribute/localization.md +++ b/content/en/docs/contribute/localization.md @@ -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 diff --git a/content/en/docs/contribute/start.md b/content/en/docs/contribute/start.md index 02e0ce0bc0..2ebf585efa 100644 --- a/content/en/docs/contribute/start.md +++ b/content/en/docs/contribute/start.md @@ -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 diff --git a/content/en/docs/contribute/style/content-organization.md b/content/en/docs/contribute/style/content-organization.md index f14a6432ab..61ee7d9a3b 100644 --- a/content/en/docs/contribute/style/content-organization.md +++ b/content/en/docs/contribute/style/content-organization.md @@ -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 %}} - diff --git a/content/en/docs/contribute/style/page-templates.md b/content/en/docs/contribute/style/page-templates.md index d1a21b83db..147e8f5ec7 100644 --- a/content/en/docs/contribute/style/page-templates.md +++ b/content/en/docs/contribute/style/page-templates.md @@ -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 */%}} - + {{}} {{}} - + {{%/* /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 */%}} - + {{}} {{}} - + {{%/* /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 %}} - diff --git a/content/en/docs/home/_index.md b/content/en/docs/home/_index.md index 2a7477baf4..7f6b94a122 100644 --- a/content/en/docs/home/_index.md +++ b/content/en/docs/home/_index.md @@ -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: diff --git a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md index bdee25dc86..518e57ef89 100644 --- a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md @@ -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. diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md index bf009af587..ca674e9343 100644 --- a/content/en/docs/reference/access-authn-authz/rbac.md +++ b/content/en/docs/reference/access-authn-authz/rbac.md @@ -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. diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index ec632df097..e001488653 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -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. diff --git a/content/en/docs/reference/glossary/aggregation-layer.md b/content/en/docs/reference/glossary/aggregation-layer.md new file mode 100644 index 0000000000..d97b34d16d --- /dev/null +++ b/content/en/docs/reference/glossary/aggregation-layer.md @@ -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. + + + +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. + diff --git a/content/en/docs/reference/issues-security/security.md b/content/en/docs/reference/issues-security/security.md index a2795d3b93..26d04ab0f3 100644 --- a/content/en/docs/reference/issues-security/security.md +++ b/content/en/docs/reference/issues-security/security.md @@ -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. diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md index 8ded895e73..3d2a703f0a 100644 --- a/content/en/docs/reference/kubectl/cheatsheet.md +++ b/content/en/docs/reference/kubectl/cheatsheet.md @@ -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 --------------| ----------- diff --git a/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md b/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md index 03720f8338..6373155102 100644 --- a/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md +++ b/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md @@ -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 `. -#### 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 %}} \ No newline at end of file diff --git a/content/en/docs/reference/kubectl/overview.md b/content/en/docs/reference/kubectl/overview.md index c51c24af3f..ca50170576 100644 --- a/content/en/docs/reference/kubectl/overview.md +++ b/content/en/docs/reference/kubectl/overview.md @@ -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. diff --git a/content/en/docs/setup/cri.md b/content/en/docs/setup/cri.md index 5ff203d776..017e6925cb 100644 --- a/content/en/docs/setup/cri.md +++ b/content/en/docs/setup/cri.md @@ -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 <}} **Caution:** When running the reset Workflow, be sure not to accidentally target your production cluster! diff --git a/content/en/docs/setup/pick-right-solution.md b/content/en/docs/setup/pick-right-solution.md index 882563a57c..1686f43f4c 100644 --- a/content/en/docs/setup/pick-right-solution.md +++ b/content/en/docs/setup/pick-right-solution.md @@ -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. diff --git a/content/en/docs/tasks/access-application-cluster/access-cluster.md b/content/en/docs/tasks/access-application-cluster/access-cluster.md index 5d424af279..1fcd18c10c 100644 --- a/content/en/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/en/docs/tasks/access-application-cluster/access-cluster.md @@ -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 diff --git a/content/en/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md b/content/en/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md index 25f4efc98d..4684387872 100644 --- a/content/en/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md +++ b/content/en/docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md @@ -16,7 +16,6 @@ well as any provider specific details that may be necessary. {{% /capture %}} -{{< toc >}} {{% capture prerequisites %}} diff --git a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md index 0e851f85fd..6a4fb2fc18 100644 --- a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -18,7 +18,6 @@ Dashboard also provides information on the state of Kubernetes resources in your {{% /capture %}} -{{< toc >}} {{% capture body %}} diff --git a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md index 892f9f55e6..887bc30552 100644 --- a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md +++ b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md @@ -3,6 +3,7 @@ title: Extend the Kubernetes API with CustomResourceDefinitions reviewers: - deads2k - enisoc +- sttts content_template: templates/task weight: 20 --- diff --git a/content/en/docs/tasks/access-kubernetes-api/custom-resources/migrate-third-party-resource.md b/content/en/docs/tasks/access-kubernetes-api/custom-resources/migrate-third-party-resource.md deleted file mode 100644 index 853add8c39..0000000000 --- a/content/en/docs/tasks/access-kubernetes-api/custom-resources/migrate-third-party-resource.md +++ /dev/null @@ -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 %}} - - diff --git a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md index d46e0ad9d6..97aef1769d 100644 --- a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md +++ b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md @@ -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 -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}' + ```shell + kubectl patch pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}' + ``` where `` 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: diff --git a/content/en/docs/tasks/administer-cluster/cluster-management.md b/content/en/docs/tasks/administer-cluster/cluster-management.md index 2871b52d03..2908666dcb 100644 --- a/content/en/docs/tasks/administer-cluster/cluster-management.md +++ b/content/en/docs/tasks/administer-cluster/cluster-management.md @@ -15,7 +15,6 @@ running cluster. {{% /capture %}} -{{< toc >}} {{% capture body %}} diff --git a/content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md b/content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md index 95c2150684..b6edeb4bc2 100644 --- a/content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md +++ b/content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md @@ -21,7 +21,6 @@ in the Kubernetes source directory for a canonical example. {{% /capture %}} -{{< toc >}} {{% capture prerequisites %}} diff --git a/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md b/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md index 8101cff681..bd0f59d948 100644 --- a/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md +++ b/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md @@ -12,7 +12,6 @@ content_template: templates/task {{% /capture %}} -{{< toc >}} {{% capture prerequisites %}} diff --git a/content/en/docs/tasks/administer-cluster/cpu-management-policies.md b/content/en/docs/tasks/administer-cluster/cpu-management-policies.md index 18ba1f3700..c5b2a029d8 100644 --- a/content/en/docs/tasks/administer-cluster/cpu-management-policies.md +++ b/content/en/docs/tasks/administer-cluster/cpu-management-policies.md @@ -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 %}} diff --git a/content/en/docs/tasks/administer-cluster/developing-cloud-controller-manager.md b/content/en/docs/tasks/administer-cluster/developing-cloud-controller-manager.md index 9769340ced..6f0eaf9662 100644 --- a/content/en/docs/tasks/administer-cluster/developing-cloud-controller-manager.md +++ b/content/en/docs/tasks/administer-cluster/developing-cloud-controller-manager.md @@ -22,7 +22,6 @@ To dive a little deeper into implementation details, all cloud controller manage {{% /capture %}} -{{< toc >}} {{% capture body %}} diff --git a/content/en/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md b/content/en/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md index 93d0808721..20202361e4 100644 --- a/content/en/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md +++ b/content/en/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md @@ -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 %}} diff --git a/content/en/docs/tasks/administer-cluster/highly-available-master.md b/content/en/docs/tasks/administer-cluster/highly-available-master.md index c3a86e1675..598339a3b1 100644 --- a/content/en/docs/tasks/administer-cluster/highly-available-master.md +++ b/content/en/docs/tasks/administer-cluster/highly-available-master.md @@ -14,7 +14,6 @@ This document describes how to use kube-up/down scripts to manage highly availab {{% /capture %}} -{{< toc >}} {{% capture prerequisites %}} diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha.md index fb7f476f0c..9ca2fd503c 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha.md @@ -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 diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md index 725083d688..53edcd7f25 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md @@ -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 diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md index ab43f8a34c..94f07c040c 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md @@ -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 diff --git a/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md b/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md index 9d3de79c39..4cd6eba746 100644 --- a/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md +++ b/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md @@ -20,7 +20,6 @@ This example demonstrates how to use Kubernetes namespaces to subdivide your clu {{% /capture %}} -{{< toc >}} {{% capture prerequisites %}} diff --git a/content/en/docs/tasks/administer-cluster/out-of-resource.md b/content/en/docs/tasks/administer-cluster/out-of-resource.md index 62c9f8344d..9d74dc289b 100644 --- a/content/en/docs/tasks/administer-cluster/out-of-resource.md +++ b/content/en/docs/tasks/administer-cluster/out-of-resource.md @@ -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` diff --git a/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md b/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md index c852413a05..923db9a03c 100644 --- a/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md +++ b/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md @@ -23,7 +23,6 @@ on each node. {{% /capture %}} -{{< toc >}} {{% capture prerequisites %}} diff --git a/content/en/docs/tasks/administer-cluster/running-cloud-controller.md b/content/en/docs/tasks/administer-cluster/running-cloud-controller.md index 3169531a24..3abad0465b 100644 --- a/content/en/docs/tasks/administer-cluster/running-cloud-controller.md +++ b/content/en/docs/tasks/administer-cluster/running-cloud-controller.md @@ -17,7 +17,6 @@ The `cloud-controller-manager` can be linked to any cloud provider that satisfie {{% /capture %}} -{{< toc >}} {{% capture body %}} diff --git a/content/en/docs/tasks/administer-cluster/static-pod.md b/content/en/docs/tasks/administer-cluster/static-pod.md index 958489779c..87dad377cd 100644 --- a/content/en/docs/tasks/administer-cluster/static-pod.md +++ b/content/en/docs/tasks/administer-cluster/static-pod.md @@ -16,7 +16,6 @@ This means that the pods are visible on the API server but cannot be controlled {{% /capture %}} -{{< toc >}} {{% capture body %}} @@ -103,7 +102,7 @@ Notice we cannot delete the pod with the API server (e.g. via [`kubectl`](/docs/ {{}} **Note**: Make sure the kubelet has permission to create the mirror pod in the API server. -If not, the creation request is rejected by the API server. See +If not, the creation request is rejected by the API server. See [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/). {{}} diff --git a/content/en/docs/tasks/administer-cluster/storage-object-in-use-protection.md b/content/en/docs/tasks/administer-cluster/storage-object-in-use-protection.md index 3065c42cf6..d83510cfc9 100644 --- a/content/en/docs/tasks/administer-cluster/storage-object-in-use-protection.md +++ b/content/en/docs/tasks/administer-cluster/storage-object-in-use-protection.md @@ -216,7 +216,7 @@ spec: - Verify that the scheduling of the second pod fails with the below warning: ```shell -Warning FailedScheduling 18s (x4 over 21s) default-scheduler persistentvolumeclaim "slzc" is being deleted +Warning FailedScheduling 18s (x4 over 21s) default-scheduler persistentvolumeclaim "slzc" is being deleted ``` - Wait until the pod status of both pods is `Terminated` or `Completed` (either delete the pods or wait until they finish). Afterwards, check that the PVC is removed. diff --git a/content/en/docs/tasks/administer-federation/deployment.md b/content/en/docs/tasks/administer-federation/deployment.md index 829c4290ec..624a527cfc 100644 --- a/content/en/docs/tasks/administer-federation/deployment.md +++ b/content/en/docs/tasks/administer-federation/deployment.md @@ -45,7 +45,7 @@ You can do that using [kubectl](/docs/user-guide/kubectl/) by running: kubectl --context=federation-cluster create -f mydeployment.yaml ``` -The '--context=federation-cluster' flag tells kubectl to submit the +The `--context=federation-cluster` flag tells kubectl to submit the request to the Federation apiserver instead of sending it to a Kubernetes cluster. diff --git a/content/en/docs/tasks/administer-federation/events.md b/content/en/docs/tasks/administer-federation/events.md index 3fd06ce194..e855afb3d1 100644 --- a/content/en/docs/tasks/administer-federation/events.md +++ b/content/en/docs/tasks/administer-federation/events.md @@ -13,7 +13,6 @@ This guide explains how to use events in federation control plane to help in deb {{% /capture %}} -{{< toc >}} {{% capture body %}} diff --git a/content/en/docs/tasks/administer-federation/hpa.md b/content/en/docs/tasks/administer-federation/hpa.md index a7862643c3..5ca0363e1c 100644 --- a/content/en/docs/tasks/administer-federation/hpa.md +++ b/content/en/docs/tasks/administer-federation/hpa.md @@ -106,7 +106,7 @@ Currently the default distribution is only available on the federated HPA, but i future, users preferences could also be specified to control and/or restrict this distribution. -## Updating a federated ReplicaSet +## Updating a federated HPA You can update a federated HPA as you would update a Kubernetes HPA; however, for a federated HPA, you must send the request to diff --git a/content/en/docs/tasks/administer-federation/ingress.md b/content/en/docs/tasks/administer-federation/ingress.md index 85cd17520f..51bfce65d5 100644 --- a/content/en/docs/tasks/administer-federation/ingress.md +++ b/content/en/docs/tasks/administer-federation/ingress.md @@ -55,7 +55,7 @@ rather a globally reachable via a single, static IP address. Clients inside your federated Kubernetes clusters (Pods) will be -automatically routed to the cluster-local shard of the Federated Service +automatically routed to the cluster-local shard of the Federated Service backing the Ingress in their cluster if it exists and is healthy, or the closest healthy shard in a different cluster if it does not. Note that this involves a network trip to the HTTP(s) load balancer, which resides outside your local @@ -85,7 +85,7 @@ You can create a federated ingress in any of the usual ways, for example, using kubectl --context=federation-cluster create -f myingress.yaml ``` For example ingress YAML configurations, see the [Ingress User Guide](/docs/concepts/services-networking/ingress/). -The '--context=federation-cluster' flag tells kubectl to submit the +The `--context=federation-cluster` flag tells kubectl to submit the request to the Federation API endpoint, with the appropriate credentials. If you have not yet configured such a context, see the [federation admin guide](/docs/admin/federation/) or one of the diff --git a/content/en/docs/tasks/administer-federation/job.md b/content/en/docs/tasks/administer-federation/job.md index 4543d756c8..cf631f5154 100644 --- a/content/en/docs/tasks/administer-federation/job.md +++ b/content/en/docs/tasks/administer-federation/job.md @@ -40,7 +40,7 @@ You can do that using [kubectl](/docs/user-guide/kubectl/) by running: kubectl --context=federation-cluster create -f myjob.yaml ``` -The '--context=federation-cluster' flag tells kubectl to submit the +The `--context=federation-cluster` flag tells kubectl to submit the request to the federation API server instead of sending it to a Kubernetes cluster. diff --git a/content/en/docs/tasks/administer-federation/namespaces.md b/content/en/docs/tasks/administer-federation/namespaces.md index 2d6a91e926..df60610814 100644 --- a/content/en/docs/tasks/administer-federation/namespaces.md +++ b/content/en/docs/tasks/administer-federation/namespaces.md @@ -41,7 +41,7 @@ You can do that using kubectl by running: kubectl --context=federation-cluster create -f myns.yaml ``` -The '--context=federation-cluster' flag tells kubectl to submit the +The `--context=federation-cluster` flag tells kubectl to submit the request to the Federation apiserver instead of sending it to a Kubernetes cluster. diff --git a/content/en/docs/tasks/administer-federation/secret.md b/content/en/docs/tasks/administer-federation/secret.md index 40feb9a70f..dc5b0e3d6c 100644 --- a/content/en/docs/tasks/administer-federation/secret.md +++ b/content/en/docs/tasks/administer-federation/secret.md @@ -18,7 +18,6 @@ Creating them in the federation control plane ensures that they are synchronized across all the clusters in federation. {{% /capture %}} -{{< toc >}} {{% capture body %}} diff --git a/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md index bb11bc2baa..651b72e65d 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -297,130 +297,130 @@ metadata: ### Define a container environment variable with data from a single ConfigMap -1. Define an environment variable as a key-value pair in a ConfigMap: +1. Define an environment variable as a key-value pair in a ConfigMap: - ```shell - kubectl create configmap special-config --from-literal=special.how=very - ``` + ```shell + kubectl create configmap special-config --from-literal=special.how=very + ``` -1. Assign the `special.how` value defined in the ConfigMap to the `SPECIAL_LEVEL_KEY` environment variable in the Pod specification. +1. Assign the `special.how` value defined in the ConfigMap to the `SPECIAL_LEVEL_KEY` environment variable in the Pod specification. - ```shell - kubectl edit pod dapi-test-pod - ``` + ```shell + kubectl edit pod dapi-test-pod + ``` - ```yaml - apiVersion: v1 - kind: Pod - metadata: - name: dapi-test-pod - spec: - containers: - - name: test-container - image: k8s.gcr.io/busybox - command: [ "/bin/sh", "-c", "env" ] - env: - # Define the environment variable - - name: SPECIAL_LEVEL_KEY - valueFrom: - configMapKeyRef: - # The ConfigMap containing the value you want to assign to SPECIAL_LEVEL_KEY - name: special-config - # Specify the key associated with the value - key: special.how - restartPolicy: Never - ``` + ```yaml + apiVersion: v1 + kind: Pod + metadata: + name: dapi-test-pod + spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "/bin/sh", "-c", "env" ] + env: + # Define the environment variable + - name: SPECIAL_LEVEL_KEY + valueFrom: + configMapKeyRef: + # The ConfigMap containing the value you want to assign to SPECIAL_LEVEL_KEY + name: special-config + # Specify the key associated with the value + key: special.how + restartPolicy: Never + ``` -1. Save the changes to the Pod specification. Now, the Pod's output includes `SPECIAL_LEVEL_KEY=very`. +1. Save the changes to the Pod specification. Now, the Pod's output includes `SPECIAL_LEVEL_KEY=very`. ### Define container environment variables with data from multiple ConfigMaps -1. As with the previous example, create the ConfigMaps first. +1. As with the previous example, create the ConfigMaps first. - ```yaml - apiVersion: v1 - kind: ConfigMap - metadata: - name: special-config - namespace: default - data: - special.how: very - ``` + ```yaml + apiVersion: v1 + kind: ConfigMap + metadata: + name: special-config + namespace: default + data: + special.how: very + ``` - ```yaml - apiVersion: v1 - kind: ConfigMap - metadata: - name: env-config - namespace: default - data: - log_level: INFO - ``` + ```yaml + apiVersion: v1 + kind: ConfigMap + metadata: + name: env-config + namespace: default + data: + log_level: INFO + ``` -1. Define the environment variables in the Pod specification. +1. Define the environment variables in the Pod specification. - ```yaml - apiVersion: v1 - kind: Pod - metadata: - name: dapi-test-pod - spec: - containers: - - name: test-container - image: k8s.gcr.io/busybox - command: [ "/bin/sh", "-c", "env" ] - env: - - name: SPECIAL_LEVEL_KEY - valueFrom: - configMapKeyRef: - name: special-config - key: special.how - - name: LOG_LEVEL - valueFrom: - configMapKeyRef: - name: env-config - key: log_level - restartPolicy: Never - ``` + ```yaml + apiVersion: v1 + kind: Pod + metadata: + name: dapi-test-pod + spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "/bin/sh", "-c", "env" ] + env: + - name: SPECIAL_LEVEL_KEY + valueFrom: + configMapKeyRef: + name: special-config + key: special.how + - name: LOG_LEVEL + valueFrom: + configMapKeyRef: + name: env-config + key: log_level + restartPolicy: Never + ``` -1. Save the changes to the Pod specification. Now, the Pod's output includes `SPECIAL_LEVEL_KEY=very` and `LOG_LEVEL=info`. +1. Save the changes to the Pod specification. Now, the Pod's output includes `SPECIAL_LEVEL_KEY=very` and `LOG_LEVEL=INFO`. ## Configure all key-value pairs in a ConfigMap as container environment variables {{< note >}} - **Note:** This functionality is available to users running Kubernetes v1.6 and later. + **Note:** This functionality is available in Kubernetes v1.6 and later. {{< /note >}} -1. Create a ConfigMap containing multiple key-value pairs. +1. Create a ConfigMap containing multiple key-value pairs. - ```yaml - apiVersion: v1 - kind: ConfigMap - metadata: - name: special-config - namespace: default - data: - SPECIAL_LEVEL: very - SPECIAL_TYPE: charm - ``` + ```yaml + apiVersion: v1 + kind: ConfigMap + metadata: + name: special-config + namespace: default + data: + SPECIAL_LEVEL: very + SPECIAL_TYPE: charm + ``` -1. Use `envFrom` to define all of the ConfigMap's data as container environment variables. The key from the ConfigMap becomes the environment variable name in the Pod. +1. Use `envFrom` to define all of the ConfigMap's data as container environment variables. The key from the ConfigMap becomes the environment variable name in the Pod. - ```yaml - apiVersion: v1 - kind: Pod - metadata: - name: dapi-test-pod - spec: - containers: - - name: test-container - image: k8s.gcr.io/busybox - command: [ "/bin/sh", "-c", "env" ] - envFrom: - - configMapRef: - name: special-config - restartPolicy: Never - ``` + ```yaml + apiVersion: v1 + kind: Pod + metadata: + name: dapi-test-pod + spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "/bin/sh", "-c", "env" ] + envFrom: + - configMapRef: + name: special-config + restartPolicy: Never + ``` 1. Save the changes to the Pod specification. Now, the Pod's output includes `SPECIAL_LEVEL=very` and `SPECIAL_TYPE=charm`. @@ -602,9 +602,9 @@ data: ### Restrictions -1. You must create a ConfigMap before referencing it in a Pod specification (unless you mark the ConfigMap as "optional"). If you reference a ConfigMap that doesn't exist, the Pod won't start. Likewise, references to keys that don't exist in the ConfigMap will prevent the pod from starting. +- You must create a ConfigMap before referencing it in a Pod specification (unless you mark the ConfigMap as "optional"). If you reference a ConfigMap that doesn't exist, the Pod won't start. Likewise, references to keys that don't exist in the ConfigMap will prevent the pod from starting. -1. If you use `envFrom` to define environment variables from ConfigMaps, keys that are considered invalid will be skipped. The pod will be allowed to start, but the invalid names will be recorded in the event log (`InvalidVariableNames`). The log message lists each skipped key. For example: +- If you use `envFrom` to define environment variables from ConfigMaps, keys that are considered invalid will be skipped. The pod will be allowed to start, but the invalid names will be recorded in the event log (`InvalidVariableNames`). The log message lists each skipped key. For example: ```shell kubectl get events @@ -612,9 +612,9 @@ data: 0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames {kubelet, 127.0.0.1} Keys [1badkey, 2alsobad] from the EnvFrom configMap default/myconfig were skipped since they are considered invalid environment variable names. ``` -1. ConfigMaps reside in a specific [namespace](/docs/concepts/overview/working-with-objects/namespaces/). A ConfigMap can only be referenced by pods residing in the same namespace. +- ConfigMaps reside in a specific [namespace](/docs/concepts/overview/working-with-objects/namespaces/). A ConfigMap can only be referenced by pods residing in the same namespace. -1. Kubelet doesn't support the use of ConfigMaps for pods not found on the API server. +- Kubelet doesn't support the use of ConfigMaps for pods not found on the API server. This includes pods created via the Kubelet's --manifest-url flag, --config flag, or the Kubelet REST API. {{< note >}} diff --git a/content/en/docs/tasks/configure-pod-container/configure-service-account.md b/content/en/docs/tasks/configure-pod-container/configure-service-account.md index f8eab60ebd..62992829cd 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/en/docs/tasks/configure-pod-container/configure-service-account.md @@ -30,7 +30,6 @@ When they do, they are authenticated as a particular Service Account (for exampl {{% /capture %}} -{{< toc >}} {{% capture prerequisites %}} @@ -181,7 +180,7 @@ token: ... ## Add ImagePullSecrets to a service account -First, create an imagePullSecret, as described [here](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). +First, create an imagePullSecret, as described [here](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). Next, verify it has been created. For example: ```shell @@ -296,7 +295,7 @@ spec: ``` The kubelet will request and store the token on behalf of the pod, make the -token avaialble to the pod at a configurable file path, and refresh the token as +token available to the pod at a configurable file path, and refresh the token as it approaches expiration. Kubelet proactively rotates the token if it is older than 80% of its total TTL, or if the token is older than 24 hours. @@ -304,5 +303,3 @@ The application is responsible for reloading the token when it rotates. Periodic reloading (e.g. once every 5 minutes) is sufficient for most usecases. {{% /capture %}} - - diff --git a/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md b/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md index 918a366c1d..316854b476 100644 --- a/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md +++ b/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md @@ -14,7 +14,6 @@ More information can be found on the Kompose website at [http://kompose.io](http {{% /capture %}} -{{< toc >}} {{% capture prerequisites %}} @@ -33,7 +32,7 @@ We have multiple ways to install Kompose. Our preferred method is downloading th Kompose is released via GitHub on a three-week cycle, you can see all current releases on the [GitHub release page](https://github.com/kubernetes/kompose/releases). ```sh -# Linux +# Linux curl -L https://github.com/kubernetes/kompose/releases/download/v1.1.0/kompose-linux-amd64 -o kompose # macOS @@ -98,7 +97,7 @@ you need is an existing `docker-compose.yml` file. services: redis-master: - image: k8s.gcr.io/redis:e2e + image: k8s.gcr.io/redis:e2e ports: - "6379" @@ -124,8 +123,8 @@ you need is an existing `docker-compose.yml` file. ```bash $ kompose up - We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application. - If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead. + We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application. + If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead. INFO Successfully created Service: redis INFO Successfully created Service: web @@ -157,7 +156,7 @@ you need is an existing `docker-compose.yml` file. deployment.apps/redis-master created deployment.apps/redis-slave created ``` - + Your deployments are running in Kubernetes. 4. Access your application. @@ -252,7 +251,7 @@ INFO Kubernetes file "redis-slave-service.yaml" created INFO Kubernetes file "frontend-deployment.yaml" created INFO Kubernetes file "mlbparks-deployment.yaml" created INFO Kubernetes file "mongodb-deployment.yaml" created -INFO Kubernetes file "mongodb-claim0-persistentvolumeclaim.yaml" created +INFO Kubernetes file "mongodb-claim0-persistentvolumeclaim.yaml" created INFO Kubernetes file "redis-master-deployment.yaml" created INFO Kubernetes file "redis-slave-deployment.yaml" created @@ -261,10 +260,10 @@ mlbparks-deployment.yaml mongodb-service.yaml redis-slave frontend-deployment.yaml mongodb-claim0-persistentvolumeclaim.yaml redis-master-service.yaml frontend-service.yaml mongodb-deployment.yaml redis-slave-deployment.yaml redis-master-deployment.yaml -``` +``` When multiple docker-compose files are provided the configuration is merged. Any configuration that is common will be over ridden by subsequent file. - + ### OpenShift ```sh @@ -290,11 +289,11 @@ It also supports creating buildconfig for build directive in a service. By defau ```sh $ kompose --provider openshift --file buildconfig/docker-compose.yml convert -WARN [foo] Service cannot be created because of missing port. -INFO OpenShift Buildconfig using git@github.com:rtnpro/kompose.git::master as source. +WARN [foo] Service cannot be created because of missing port. +INFO OpenShift Buildconfig using git@github.com:rtnpro/kompose.git::master as source. INFO OpenShift file "foo-deploymentconfig.yaml" created INFO OpenShift file "foo-imagestream.yaml" created -INFO OpenShift file "foo-buildconfig.yaml" created +INFO OpenShift file "foo-buildconfig.yaml" created ``` **Note**: If you are manually pushing the Openshift artifacts using ``oc create -f``, you need to ensure that you push the imagestream artifact before the buildconfig artifact, to workaround this Openshift issue: https://github.com/openshift/origin/issues/4518 . @@ -418,15 +417,15 @@ Using `kompose up` with a `build` key: ```none $ kompose up -INFO Build key detected. Attempting to build and push image 'docker.io/foo/bar' -INFO Building image 'docker.io/foo/bar' from directory 'build' -INFO Image 'docker.io/foo/bar' from directory 'build' built successfully -INFO Pushing image 'foo/bar:latest' to registry 'docker.io' -INFO Attempting authentication credentials 'https://index.docker.io/v1/ -INFO Successfully pushed image 'foo/bar:latest' to registry 'docker.io' -INFO We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application. If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead. - -INFO Deploying application in "default" namespace +INFO Build key detected. Attempting to build and push image 'docker.io/foo/bar' +INFO Building image 'docker.io/foo/bar' from directory 'build' +INFO Image 'docker.io/foo/bar' from directory 'build' built successfully +INFO Pushing image 'foo/bar:latest' to registry 'docker.io' +INFO Attempting authentication credentials 'https://index.docker.io/v1/ +INFO Successfully pushed image 'foo/bar:latest' to registry 'docker.io' +INFO We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application. If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead. + +INFO Deploying application in "default" namespace INFO Successfully created Service: foo INFO Successfully created Deployment: foo @@ -479,7 +478,7 @@ The `*-daemonset.yaml` files contain the Daemon Set objects If you want to generate a Chart to be used with [Helm](https://github.com/kubernetes/helm) simply do: ```sh -$ kompose convert -c +$ kompose convert -c INFO Kubernetes file "web-svc.yaml" created INFO Kubernetes file "redis-svc.yaml" created INFO Kubernetes file "web-deployment.yaml" created @@ -509,7 +508,7 @@ For example: ```yaml version: "2" -services: +services: nginx: image: nginx dockerfile: foobar @@ -517,7 +516,7 @@ services: cap_add: - ALL container_name: foobar - labels: + labels: kompose.service.type: nodeport ``` diff --git a/content/en/docs/tasks/debug-application-cluster/audit.md b/content/en/docs/tasks/debug-application-cluster/audit.md index c4440d247c..10f8161f26 100644 --- a/content/en/docs/tasks/debug-application-cluster/audit.md +++ b/content/en/docs/tasks/debug-application-cluster/audit.md @@ -24,7 +24,6 @@ answer the following questions: {{% /capture %}} -{{< toc >}} {{% capture body %}} @@ -191,7 +190,7 @@ and in the logs to monitor the state of the auditing subsystem. ### Truncate -Both log and webhook backends support batching. As an example, the following is the list of flags +Both log and webhook backends support truncating. As an example, the following is the list of flags available for the log backend: - `audit-log-truncate-enabled` whether event and batch truncating is enabled. diff --git a/content/en/docs/tasks/debug-application-cluster/core-metrics-pipeline.md b/content/en/docs/tasks/debug-application-cluster/core-metrics-pipeline.md index 53185780f3..e44f98c90d 100644 --- a/content/en/docs/tasks/debug-application-cluster/core-metrics-pipeline.md +++ b/content/en/docs/tasks/debug-application-cluster/core-metrics-pipeline.md @@ -15,7 +15,6 @@ Horizontal Pod Autoscaler, to make decisions. {{% /capture %}} -{{< toc >}} {{% capture body %}} diff --git a/content/en/docs/tasks/debug-application-cluster/crictl.md b/content/en/docs/tasks/debug-application-cluster/crictl.md index 71ccab81aa..7c8afeee5a 100644 --- a/content/en/docs/tasks/debug-application-cluster/crictl.md +++ b/content/en/docs/tasks/debug-application-cluster/crictl.md @@ -7,7 +7,6 @@ title: Debugging Kubernetes nodes with crictl content_template: templates/task --- -{{< toc >}} {{% capture overview %}} @@ -230,7 +229,7 @@ deleted by the Kubelet. ```bash crictl runp pod-config.json ``` - + The ID of the sandbox is returned. ### Create a container diff --git a/content/en/docs/tasks/debug-application-cluster/debug-application-introspection.md b/content/en/docs/tasks/debug-application-cluster/debug-application-introspection.md index 955164e24a..e64ba4db1d 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-application-introspection.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-application-introspection.md @@ -14,7 +14,6 @@ your pods. But there are a number of ways to get even more information about you {{% /capture %}} -{{< toc >}} {{% capture body %}} diff --git a/content/en/docs/tasks/debug-application-cluster/debug-application.md b/content/en/docs/tasks/debug-application-cluster/debug-application.md index 0d9dd609b5..cedfa0384c 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-application.md @@ -14,7 +14,6 @@ This is *not* a guide for people who want to debug their cluster. For that you {{% /capture %}} -{{< toc >}} {{% capture body %}} @@ -109,7 +108,7 @@ will not use the command line you intended it to use. The first thing to do is to delete your pod and try creating it again with the `--validate` option. For example, run `kubectl create --validate -f mypod.yaml`. -If you misspelled `command` as `commnd` then will give an error like this: +If you misspelled `command` as `commnd` then will give an error like this: ```shell I0805 10:43:25.129850 46757 schema.go:126] unknown field: commnd diff --git a/content/en/docs/tasks/debug-application-cluster/debug-cluster.md b/content/en/docs/tasks/debug-application-cluster/debug-cluster.md index 01c4b86a44..620bfa4e2b 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-cluster.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-cluster.md @@ -14,7 +14,6 @@ You may also visit [troubleshooting document](/docs/troubleshooting/) for more i {{% /capture %}} -{{< toc >}} {{% capture body %}} diff --git a/content/en/docs/tasks/debug-application-cluster/debug-service.md b/content/en/docs/tasks/debug-application-cluster/debug-service.md index 9c6f25c221..3e470a11e3 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-service.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-service.md @@ -14,7 +14,6 @@ This document will hopefully help you to figure out what's going wrong. {{% /capture %}} -{{< toc >}} {{% capture body %}} diff --git a/content/en/docs/tasks/debug-application-cluster/events-stackdriver.md b/content/en/docs/tasks/debug-application-cluster/events-stackdriver.md index cc82d0b834..1c612bf526 100644 --- a/content/en/docs/tasks/debug-application-cluster/events-stackdriver.md +++ b/content/en/docs/tasks/debug-application-cluster/events-stackdriver.md @@ -38,7 +38,6 @@ of the potential inaccuracy. {{% /capture %}} -{{< toc >}} {{% capture body %}} diff --git a/content/en/docs/tasks/debug-application-cluster/get-shell-running-container.md b/content/en/docs/tasks/debug-application-cluster/get-shell-running-container.md index 776df8bd40..8b97c679f1 100644 --- a/content/en/docs/tasks/debug-application-cluster/get-shell-running-container.md +++ b/content/en/docs/tasks/debug-application-cluster/get-shell-running-container.md @@ -47,6 +47,11 @@ Get a shell to the running Container: ```shell kubectl exec -it shell-demo -- /bin/bash ``` +{{< note >}} + +The double dash symbol "--" is used to separate the arguments you want to pass to the command from the kubectl arguments. + +{{< /note >}} In your shell, list the root directory: diff --git a/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md b/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md index b9251fc989..378d5c6b33 100644 --- a/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md +++ b/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md @@ -20,7 +20,6 @@ in the Kubernetes logging overview. {{% /capture %}} -{{< toc >}} {{% capture body %}} @@ -263,7 +262,7 @@ In this case you need to be able to change the parameters of `DaemonSet` and `Co If you're using GKE and Stackdriver Logging is enabled in your cluster, you cannot change its configuration, because it's managed and supported by GKE. -However, you can disable the default integration and deploy your own. +However, you can disable the default integration and deploy your own. {{< note >}}**Note:** You will have to support and maintain a newly deployed configuration yourself: update the image and configuration, adjust the resources and so on.{{< /note >}} To disable the default logging integration, use the following command: @@ -325,7 +324,7 @@ kubectl get cm fluentd-gcp-config --namespace kube-system -o yaml > fluentd-gcp- ``` Then in the value for the key `containers.input.conf` insert a new filter right after -the `source` section. +the `source` section. {{< note >}}**Note:** Order is important.{{< /note >}} Updating `ConfigMap` in the apiserver is more complicated than updating `DaemonSet`. It's better diff --git a/content/en/docs/tasks/debug-application-cluster/monitor-node-health.md b/content/en/docs/tasks/debug-application-cluster/monitor-node-health.md index c4309b1588..223cf63a7d 100644 --- a/content/en/docs/tasks/debug-application-cluster/monitor-node-health.md +++ b/content/en/docs/tasks/debug-application-cluster/monitor-node-health.md @@ -94,7 +94,7 @@ However, you can use [ConfigMap](/docs/tasks/configure-pod-container/configure-p following the steps: * **Step 1:** Change the config files in `config/`. -* **Step 2:** Create the ConfigMap `node-problem-detector-config` with `kubectl create configmap +* **Step 2:** Create the ConfigMap `node-problem-detector-config` with `kubectl create configmap node-problem-detector-config --from-file=config/`. * **Step 3:** Change the `node-problem-detector.yaml` to use the ConfigMap: diff --git a/content/en/docs/tasks/debug-application-cluster/troubleshooting.md b/content/en/docs/tasks/debug-application-cluster/troubleshooting.md index f1c169ea99..4f42e56fcb 100644 --- a/content/en/docs/tasks/debug-application-cluster/troubleshooting.md +++ b/content/en/docs/tasks/debug-application-cluster/troubleshooting.md @@ -19,7 +19,6 @@ you're using. {{% /capture %}} -{{< toc >}} {{% capture body %}} @@ -103,4 +102,4 @@ problem, such as: * Cloud provider, OS distro, network configuration, and Docker version * Steps to reproduce the problem -{{% /capture %}} \ No newline at end of file +{{% /capture %}} diff --git a/content/en/docs/tasks/federation/set-up-cluster-federation-kubefed.md b/content/en/docs/tasks/federation/set-up-cluster-federation-kubefed.md index 4791e18f70..e6db7c3c31 100644 --- a/content/en/docs/tasks/federation/set-up-cluster-federation-kubefed.md +++ b/content/en/docs/tasks/federation/set-up-cluster-federation-kubefed.md @@ -23,7 +23,6 @@ using `kubefed`. {{% /capture %}} -{{< toc >}} {{% capture prerequisites %}} @@ -41,14 +40,14 @@ for installation instructions for your platform. ## Getting `kubefed` -Download the client tarball corresponding to the particular release and +Download the client tarball corresponding to the particular release and extract the binaries in the tarball: {{< note >}} -**Note:** Until Kubernetes version `1.8.x` the federation project was +**Note:** Until Kubernetes version `1.8.x` the federation project was maintained as part of the [core kubernetes repo](https://github.com/kubernetes/kubernetes). -Between Kubernetes releases `1.8` and `1.9`, the federation project moved into -a separate [federation repo](https://github.com/kubernetes/federation), where it is +Between Kubernetes releases `1.8` and `1.9`, the federation project moved into +a separate [federation repo](https://github.com/kubernetes/federation), where it is now maintained. Consequently, the federation release information is available on the [release page](https://github.com/kubernetes/federation/releases). {{< /note >}} @@ -60,7 +59,7 @@ curl -LO https://storage.googleapis.com/kubernetes-release/release/${RELEASE-VER tar -xzvf kubernetes-client-linux-amd64.tar.gz ``` {{< note >}} -**Note:** The `RELEASE-VERSION` variable should either be set to or replaced with the actual version needed. +**Note:** The `RELEASE-VERSION` variable should either be set to or replaced with the actual version needed. {{< /note >}} Copy the extracted binary to one of the directories in your `$PATH` @@ -79,7 +78,7 @@ tar -xzvf federation-client-linux-amd64.tar.gz ``` {{< note >}} -**Note:** The `RELEASE-VERSION` variable should be replaced with one of the release versions available at [federation release page](https://github.com/kubernetes/federation/releases). +**Note:** The `RELEASE-VERSION` variable should be replaced with one of the release versions available at [federation release page](https://github.com/kubernetes/federation/releases). {{< /note >}} Copy the extracted binary to one of the directories in your `$PATH` @@ -92,7 +91,7 @@ sudo chmod +x /usr/local/bin/kubefed ### Install kubectl -You can install a matching version of kubectl using the instructions on +You can install a matching version of kubectl using the instructions on the [kubectl install page](https://kubernetes.io/docs/tasks/tools/install-kubectl/). ## Choosing a host cluster. @@ -177,7 +176,7 @@ without the Google Cloud DNS API scope by default. If you want to use a Google Kubernetes Engine cluster as a Federation host, you must create it using the `gcloud` command with the appropriate value in the `--scopes` field. You cannot modify a Google Kubernetes Engine cluster directly to add this scope, but you can create a -new node pool for your cluster and delete the old one. +new node pool for your cluster and delete the old one. {{< note >}} **Note:** This will cause pods in the cluster to be rescheduled. @@ -200,7 +199,7 @@ gcloud container node-pools delete default-pool --cluster gke-cluster `kubefed init` sets up the federation control plane in the host cluster and also adds an entry for the federation API server in your -local kubeconfig. +local kubeconfig. {{< note >}} **Note:** In the beta release of Kubernetes 1.6, `kubefed init` does not automatically set the current context to the newly deployed federation. You can set the current context manually by running: @@ -436,7 +435,7 @@ Where `` is the name of the file you created above. ## Adding a cluster to a federation -After you've deployed a federation control plane, you'll need to make that control plane aware of the clusters it should manage. +After you've deployed a federation control plane, you'll need to make that control plane aware of the clusters it should manage. To join clusters into the federation: @@ -463,7 +462,7 @@ To join clusters into the federation: kubefed join gondor --host-cluster-context=rivendell ``` -A new context has now been added to your kubeconfig named `fellowship` (after the name of your federation). +A new context has now been added to your kubeconfig named `fellowship` (after the name of your federation). {{< note >}} diff --git a/content/en/docs/tasks/job/coarse-parallel-processing-work-queue.md b/content/en/docs/tasks/job/coarse-parallel-processing-work-queue.md index 9381e26c2d..c24790b2f4 100644 --- a/content/en/docs/tasks/job/coarse-parallel-processing-work-queue.md +++ b/content/en/docs/tasks/job/coarse-parallel-processing-work-queue.md @@ -4,12 +4,11 @@ content_template: templates/task weight: 30 --- -{{< toc >}} {{% capture overview %}} In this example, we will run a Kubernetes Job with multiple parallel -worker processes. +worker processes. In this example, as each pod is created, it picks up one unit of work from a task queue, completes it, deletes it from the queue, and exits. @@ -25,7 +24,6 @@ Here is an overview of the steps in this example: {{% /capture %}} -{{< toc >}} {{% capture prerequisites %}} diff --git a/content/en/docs/tasks/job/fine-parallel-processing-work-queue.md b/content/en/docs/tasks/job/fine-parallel-processing-work-queue.md index bf65daa13d..d96f5ed986 100644 --- a/content/en/docs/tasks/job/fine-parallel-processing-work-queue.md +++ b/content/en/docs/tasks/job/fine-parallel-processing-work-queue.md @@ -26,7 +26,6 @@ Here is an overview of the steps in this example: {{% /capture %}} -{{< toc >}} {{% capture prerequisites %}} diff --git a/content/en/docs/tasks/job/parallel-processing-expansion.md b/content/en/docs/tasks/job/parallel-processing-expansion.md index 102844e7aa..b71f1c7c2e 100644 --- a/content/en/docs/tasks/job/parallel-processing-expansion.md +++ b/content/en/docs/tasks/job/parallel-processing-expansion.md @@ -12,7 +12,6 @@ non-parallel, use of [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-com {{% /capture %}} -{{< toc >}} {{% capture body %}} diff --git a/content/en/docs/tasks/manage-gpus/scheduling-gpus.md b/content/en/docs/tasks/manage-gpus/scheduling-gpus.md index a191b4ec92..51f94a255d 100644 --- a/content/en/docs/tasks/manage-gpus/scheduling-gpus.md +++ b/content/en/docs/tasks/manage-gpus/scheduling-gpus.md @@ -17,7 +17,6 @@ and the current limitations. {{% /capture %}} -{{< toc >}} {{% capture body %}} @@ -33,7 +32,7 @@ from 1.10. Then you have to install GPU drivers from the corresponding vendor on the nodes and run the corresponding device plugin from the GPU vendor -([AMD](#deploying-amd-gpu-device-plugin), [NVIDIA](#deploying-nvidia-gpu-device-plugin)). +([AMD](#deploying-amd-gpu-device-plugin), [NVIDIA](#deploying-nvidia-gpu-device-plugin)). When the above conditions are true, Kubernetes will expose `nvidia.com/gpu` or `amd.com/gpu` as a schedulable resource. diff --git a/content/en/docs/tasks/run-application/configure-pdb.md b/content/en/docs/tasks/run-application/configure-pdb.md index 42e7e86fbf..7c291da37d 100644 --- a/content/en/docs/tasks/run-application/configure-pdb.md +++ b/content/en/docs/tasks/run-application/configure-pdb.md @@ -191,7 +191,7 @@ zk-pdb 2 1 7s ``` The non-zero value for `ALLOWED-DISRUPTIONS` means that the disruption controller has seen the pods, -counted the matching pods, and update the status of the PDB. +counted the matching pods, and updated the status of the PDB. You can get more information about the status of a PDB with this command: diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index ccb4285b8f..45bac9d25b 100644 --- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -19,7 +19,6 @@ This document walks you through an example of enabling Horizontal Pod Autoscaler {{% /capture %}} -{{< toc >}} {{% capture prerequisites %}} @@ -386,7 +385,7 @@ section to your HorizontalPodAutoscaler manifest to specify that you need one wo averageValue: 30 ``` -When possible, it's preferrable to use the custom metric target types instead of external metrics, since it's +When possible, it's preferable to use the custom metric target types instead of external metrics, since it's easier for cluster administrators to secure the custom metrics API. The external metrics API potentially allows access to any metric, so cluster administrators should take care when exposing it. diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md index 45782730be..c4938cb260 100644 --- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -28,7 +28,6 @@ to match the observed average CPU utilization to the target specified by user. {{% /capture %}} -{{< toc >}} {{% capture body %}} @@ -161,8 +160,8 @@ into a desired replica count (e.g. due to an error fetching the metrics from the metrics APIs), scaling is skipped. Finally, just before HPA scales the target, the scale reccomendation is recorded. The -controller considers all recommendations within a configurable window choosing the -highest recommendation from within that window. This value can be configured using the `--horizontal-pod-autoscaler-downscale-stabilization-window` flag, which defaults to 5 minutes. +controller considers all recommendations within a configurable window choosing the +highest recommendation from within that window. This value can be configured using the `--horizontal-pod-autoscaler-downscale-stabilization-window` flag, which defaults to 5 minutes. This means that scaledowns will occur gradually, smoothing out the impact of rapidly fluctuating metric values. diff --git a/content/en/docs/tasks/run-application/rolling-update-replication-controller.md b/content/en/docs/tasks/run-application/rolling-update-replication-controller.md index 5e2e2c0b97..63db0a2ac0 100644 --- a/content/en/docs/tasks/run-application/rolling-update-replication-controller.md +++ b/content/en/docs/tasks/run-application/rolling-update-replication-controller.md @@ -42,7 +42,6 @@ Rolling updates are initiated with the `kubectl rolling-update` command: {{% /capture %}} -{{< toc >}} {{% capture body %}} diff --git a/content/en/docs/tasks/run-application/scale-stateful-set.md b/content/en/docs/tasks/run-application/scale-stateful-set.md index 22ba15927b..c47fd8f47d 100644 --- a/content/en/docs/tasks/run-application/scale-stateful-set.md +++ b/content/en/docs/tasks/run-application/scale-stateful-set.md @@ -21,7 +21,7 @@ This task shows how to scale a StatefulSet. Scaling a StatefulSet refers to incr * StatefulSets are only available in Kubernetes version 1.5 or later. To check your version of Kubernetes, run `kubectl version`. -* Not all stateful applications scale nicely. If you are unsure about whether to scale your StatefulSets, see [StatefulSet concepts](/docs/concepts/workloads/controllers/statefulset/) or [StatefulSet tutorial](/docs/tutorials/stateful-application/basic-stateful-set/) for futher information. +* Not all stateful applications scale nicely. If you are unsure about whether to scale your StatefulSets, see [StatefulSet concepts](/docs/concepts/workloads/controllers/statefulset/) or [StatefulSet tutorial](/docs/tutorials/stateful-application/basic-stateful-set/) for further information. * You should perform scaling only when you are confident that your stateful application cluster is completely healthy. diff --git a/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md b/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md index 1c3d98e989..dba3f0e142 100644 --- a/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md +++ b/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md @@ -21,7 +21,6 @@ protocol that is similar to the {{% /capture %}} -{{< toc >}} {{% capture prerequisites %}} diff --git a/content/en/docs/tasks/tools/install-kubectl.md b/content/en/docs/tasks/tools/install-kubectl.md index 4f94e6335b..e7f78b98cd 100644 --- a/content/en/docs/tasks/tools/install-kubectl.md +++ b/content/en/docs/tasks/tools/install-kubectl.md @@ -233,7 +233,7 @@ You can install kubectl as part of the Google Cloud SDK. sudo mv ./kubectl /usr/local/bin/kubectl ``` {{% /tab %}} -{{% tab name="Windows" %}} +{{% tab name="Windows" %}} 1. Download the latest release {{< param "fullversion" >}} from [this link](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe). Or if you have `curl` installed, use this command: diff --git a/content/zh/docs/concepts/policy/pod-security-policy.md b/content/zh/docs/concepts/policy/pod-security-policy.md index 23e8680b5d..8932a23c8a 100644 --- a/content/zh/docs/concepts/policy/pod-security-policy.md +++ b/content/zh/docs/concepts/policy/pod-security-policy.md @@ -216,4 +216,4 @@ podsecuritypolicy "permissive" deleted 在 Kubernetes 1.5 或更新版本,可以使用 PodSecurityPolicy 来控制,对基于用户角色和组的已授权容器的访问。访问不同的 PodSecurityPolicy 对象,可以基于认证来控制。基于 Deployment、ReplicaSet 等创建的 Pod,限制访问 PodSecurityPolicy 对象,[Controller Manager](/docs/admin/kube-controller-manager/) 必须基于安全 API 端口运行,并且不能够具有超级用户权限。 -PodSecurityPolicy 认证使用所有可用的策略,包括创建 Pod 的用户,Pod 上指定的服务账户(Service Acount)。当 Pod 基于 Deployment、ReplicaSet 创建时,它是创建 Pod 的 Controller Manager,所以如果基于非安全 API 端口运行,允许所有的 PodSecurityPolicy 对象,并且不能够有效地实现细分权限。用户访问给定的 PSP 策略有效,仅当是直接部署 Pod 的情况。更多详情,查看 [PodSecurityPolicy RBAC 示例](https://git.k8s.io/kubernetes/examples/podsecuritypolicy/rbac/README.md),当直接部署 Pod 时,应用 PodSecurityPolicy 控制基于角色和组的已授权容器的访问 。 +PodSecurityPolicy 认证使用所有可用的策略,包括创建 Pod 的用户,Pod 上指定的服务账户(Service Account)。当 Pod 基于 Deployment、ReplicaSet 创建时,它是创建 Pod 的 Controller Manager,所以如果基于非安全 API 端口运行,允许所有的 PodSecurityPolicy 对象,并且不能够有效地实现细分权限。用户访问给定的 PSP 策略有效,仅当是直接部署 Pod 的情况。更多详情,查看 [PodSecurityPolicy RBAC 示例](https://git.k8s.io/kubernetes/examples/podsecuritypolicy/rbac/README.md),当直接部署 Pod 时,应用 PodSecurityPolicy 控制基于角色和组的已授权容器的访问 。 diff --git a/content/zh/docs/concepts/services-networking/service.md b/content/zh/docs/concepts/services-networking/service.md index ab5d744905..8e873a2ff9 100644 --- a/content/zh/docs/concepts/services-networking/service.md +++ b/content/zh/docs/concepts/services-networking/service.md @@ -20,7 +20,7 @@ Kubernetes [`Pod`](/docs/user-guide/pods) 是有生命周期的,它们可以 -Kubernetes `Service` 定义了这样一种抽象:一个 `Pod` 的逻辑分组,一种可以访问它们的策略 —— 通常称为微服务。 +Kubernetes `Service` 定义了这样一种抽象:逻辑上的一组 `Pod`,一种可以访问它们的策略 —— 通常称为微服务。 这一组 `Pod` 能够被 `Service` 访问到,通常是通过 [`Label Selector`](/docs/concepts/overview/working-with-objects/labels/#label-selectors)(查看下面了解,为什么可能需要没有 selector 的 `Service`)实现的。 diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md index 5867bfec5c..ade3edd3af 100644 --- a/content/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md +++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md @@ -24,7 +24,7 @@ weight: 40 ## 使用 kubeadm 安装 Romana -按照[容器化安装指南](https://github.com/romana/romana/tree/master/containerize)获取 kubeadmin。 +按照[容器化安装指南](https://github.com/romana/romana/tree/master/containerize)获取 kubeadm。 ## 运用网络策略 diff --git a/layouts/blog/baseof.html b/layouts/blog/baseof.html index 618c3e3eba..6ed37875c7 100644 --- a/layouts/blog/baseof.html +++ b/layouts/blog/baseof.html @@ -25,7 +25,7 @@ @Kubernetesio View on Github #kubernetes-users - Stack Overflow + Stack Overflow Forum Download Kubernetes diff --git a/layouts/partials/header.html b/layouts/partials/header.html index 907fb6a187..7a977cad7d 100644 --- a/layouts/partials/header.html +++ b/layouts/partials/header.html @@ -5,7 +5,7 @@