diff --git a/.gitignore b/.gitignore
index e78fa72d9a..ebf3b38926 100644
--- a/.gitignore
+++ b/.gitignore
@@ -29,6 +29,7 @@ nohup.out
# Hugo output
public/
+resources/
# User-specific editorconfig files
.editorconfig
diff --git a/.travis.yml b/.travis.yml
index d55f55fd40..750acaefd2 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -2,20 +2,33 @@ language: go
go:
- 1.10.2
-# Don't want default ./... here:
-install:
-- export PATH=$GOPATH/bin:$PATH
-- mkdir -p $HOME/gopath/src/k8s.io
-- mv $TRAVIS_BUILD_DIR $HOME/gopath/src/k8s.io/website && cd $HOME/gopath/src/k8s.io/website
+env:
+ - HUGO_VERSION=0.49
-# Make sure we are testing against the correct branch
-- pushd $GOPATH/src/k8s.io && git clone https://github.com/kubernetes/kubernetes && popd
-- pushd $GOPATH/src/k8s.io/kubernetes && git checkout release-1.11 && popd
-- cp -L -R $GOPATH/src/k8s.io/kubernetes/vendor/ $GOPATH/src/
-- rm -r $GOPATH/src/k8s.io/kubernetes/vendor/
+jobs:
+ include:
+ - name: "Testing examples"
+ # Don't want default ./... here:
+ install:
+ - export PATH=$GOPATH/bin:$PATH
+ - mkdir -p $HOME/gopath/src/k8s.io
+ - mv $TRAVIS_BUILD_DIR $HOME/gopath/src/k8s.io/website && cd $HOME/gopath/src/k8s.io/website
-# Fetch additional dependencies to run the tests in examples/examples_test.go
-- go get -t -v k8s.io/website/content/en/examples
+ # Make sure we are testing against the correct branch
+ - pushd $GOPATH/src/k8s.io && git clone https://github.com/kubernetes/kubernetes && popd
+ - pushd $GOPATH/src/k8s.io/kubernetes && git checkout release-1.11 && popd
+ - cp -L -R $GOPATH/src/k8s.io/kubernetes/vendor/ $GOPATH/src/
+ - rm -r $GOPATH/src/k8s.io/kubernetes/vendor/
-script:
-- go test -v k8s.io/website/content/en/examples
+ # Fetch additional dependencies to run the tests in examples/examples_test.go
+ - go get -t -v k8s.io/website/content/en/examples
+ script:
+ - go test -v k8s.io/website/content/en/examples
+ - name: "Hugo build"
+ install:
+ - curl -L https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_linux-64bit.tar.gz | tar -xz
+ - mkdir -p ${TRAVIS_HOME}/bin
+ - mv hugo ${TRAVIS_HOME}/bin
+ - export PATH=${TRAVIS_HOME}/bin:$PATH
+ script:
+ - hugo
diff --git a/Makefile b/Makefile
index 366671f09f..aaa092ba10 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
DOCKER = docker
HUGO_VERSION = 0.49
DOCKER_IMAGE = kubernetes-hugo
-DOCKER_RUN = $(DOCKER) run --rm --interactive --tty --volume $(PWD):/src
+DOCKER_RUN = $(DOCKER) run --rm --interactive --tty --volume $(CURDIR):/src
NODE_BIN = node_modules/.bin
NETLIFY_FUNC = $(NODE_BIN)/netlify-lambda
diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES
index b64cc3f0c5..7aee5b8a70 100644
--- a/OWNERS_ALIASES
+++ b/OWNERS_ALIASES
@@ -138,6 +138,7 @@ aliases:
- cstoku
- nasa9084
- tnir
+ - zacharysarah
sig-docs-ja-reviews: #Team: Japanese docs PR reviews; GH:sig-docs-ja-reviews
- cstoku
- makocchi-git
@@ -147,25 +148,39 @@ aliases:
sig-docs-ko-owners: #Team Korean docs localization; GH: sig-docs-ko-owners
- ClaudiaJKang
- gochist
+ - bradamant3 # Temporary for 1.13 release
+ - jimangel # Temporary for 1.13 release
+ - tfogo # Temporary for 1.13 release
+ - zacharysarah
sig-docs-ko-reviews: #Team Korean docs reviews; GH: sig-docs-ko-reviews
- ClaudiaJKang
- gochist
- ianychoi
sig-docs-zh-owners: #Team Chinese docs localization; GH: sig-docs-zh-owners
+ - bradtopol
+ - chenopis
- chenrui333
- dchen1107
- haibinxie
- hanjiayao
- lichuqiang
+ - lucperkins
+ - markthink
- tengqm
- xiangpengzhao
+ - zacharysarah
- zhangxiaoyu-zidif
+ - bradamant3 # Temporary for 1.13 release
+ - jimangel # Temporary for 1.13 release
+ - tfogo # Temporary for 1.13 release
sig-docs-zh-reviews: #Team Chinese docs reviews; GH: sig-docs-zh-reviews
- chenrui333
- idealhack
+ - markthink
- tengqm
- xiangpengzhao
- zhangxiaoyu-zidif
+ - pigletfly
sig-federation: #Team: Federation; e.g. Federated Clusters
- csbell
sig-gcp: #Google Cloud Platform; GH: sig-gcp-pr-reviews
diff --git a/README.md b/README.md
index 9824646028..e27e13a492 100644
--- a/README.md
+++ b/README.md
@@ -20,6 +20,8 @@ For more information about contributing to the Kubernetes documentation, see:
The recommended way to run the Kubernetes website locally is to run a specialized [Docker](https://docker.com) image that includes the [Hugo](https://gohugo.io) static site generator.
+> If you are running on Windows, you'll need a few more tools which you can install with [Chocolatey](https://chocolatey.org). `choco install make`
+
> If you'd prefer to run the website locally without Docker, see [Running the site locally using Hugo](#running-the-site-locally-using-hugo) below.
If you have Docker [up and running](https://www.docker.com/get-started), build the `kubernetes-hugo` Docker image locally:
diff --git a/config.toml b/config.toml
index 92f1eee421..5b6f888bc7 100644
--- a/config.toml
+++ b/config.toml
@@ -139,6 +139,10 @@ languageName = "中文 Chinese"
weight = 2
contentDir = "content/zh"
+[languages.zh.params]
+time_format_blog = "2006.01.02"
+language_alternatives = ["en"]
+
[languages.ko]
title = "Kubernetes"
description = "Production-Grade Container Orchestration"
@@ -146,6 +150,10 @@ languageName = "한국어 Korean"
weight = 3
contentDir = "content/ko"
+[languages.ko.params]
+time_format_blog = "2006.01.02"
+language_alternatives = ["en"]
+
[languages.no]
title = "Kubernetes"
description = "Production-Grade Container Orchestration"
@@ -157,3 +165,4 @@ contentDir = "content/no"
time_format_blog = "02.01.2006"
# A list of language codes to look for untranslated content, ordered from left to right.
language_alternatives = ["en"]
+
diff --git a/content/en/blog/_posts/2015-03-00-Paricipate-In-Kubernetes-User.md b/content/en/blog/_posts/2015-03-00-Participate-In-Kubernetes-User.md
similarity index 87%
rename from content/en/blog/_posts/2015-03-00-Paricipate-In-Kubernetes-User.md
rename to content/en/blog/_posts/2015-03-00-Participate-In-Kubernetes-User.md
index a6ebc9d572..49055c6c90 100644
--- a/content/en/blog/_posts/2015-03-00-Paricipate-In-Kubernetes-User.md
+++ b/content/en/blog/_posts/2015-03-00-Participate-In-Kubernetes-User.md
@@ -1,8 +1,8 @@
---
-title: " Paricipate in a Kubernetes User Experience Study "
+title: " Participate in a Kubernetes User Experience Study "
date: 2015-03-31
-slug: paricipate-in-kubernetes-user
-url: /blog/2015/03/Paricipate-In-Kubernetes-User
+slug: participate-in-kubernetes-user
+url: /blog/2015/03/Participate-In-Kubernetes-User
---
We need your help in shaping the future of Kubernetes and Google Container Engine, and we'd love to have you participate in a remote UX research study to help us learn about your experiences! If you're interested in participating, we invite you to take [this brief survey](http://goo.gl/AXFFMs) to see if you qualify. If you’re selected to participate, we’ll follow up with you directly.
diff --git a/content/en/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_11.md b/content/en/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_11.md
index 12b880dc61..3228a3bf5a 100644
--- a/content/en/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_11.md
+++ b/content/en/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_11.md
@@ -8,95 +8,95 @@ Every week the Kubernetes contributing community meet virtually over Google Hang
Agenda:
-* kubectl tooling, rolling update, deployments, imperative commands
-* Downward API / env. substitution, and maybe preconditions/dependencies
+* kubectl tooling, rolling update, deployments, imperative commands.
+* Downward API / env. substitution, and maybe preconditions/dependencies.
**Notes from meeting:**
1\. kubectl improvements
-* make it simpler to use, finish rolling update, higher-level deployment concepts
+* make it simpler to use, finish rolling update, higher-level deployment concepts.
* rolling update
* today
- * can replace one rc by another rc specified by a file
+ * can replace one rc by another rc specified by a file.
- * no explicit support for rollback, can sort of do it by doing rolling update to old version
+ * no explicit support for rollback, can sort of do it by doing rolling update to old version.
- * we keep annotations on rcs to keep track of desired # instances; won't work for rollback case b/c not symmetric
+ * we keep annotations on rcs to keep track of desired # instances; won't work for rollback case b/c not symmetric.
- * need immutable image ids; currently no uuid that corresponds to image,version so if someone pushes on top you'll re-pull that; in API server we should translate images into uuids (as close to edge as possible)
+ * need immutable image ids; currently no uuid that corresponds to image,version so if someone pushes on top you'll re-pull that; in API server we should translate images into uuids (as close to edge as possible).
- * would be nice to auto-gen new rc instead of having user update it (e.g. when change image tag for container, etc.; currently need to change rc name and label value; could automate generating new rc)
+ * would be nice to auto-gen new rc instead of having user update it (e.g. when change image tag for container, etc.; currently need to change rc name and label value; could automate generating new rc).
- * treating rcs as pets vs. cattle
+ * treating rcs as pets vs. cattle.
* "roll me from v1 to v2" (or v2 to v1) - good enough for most people. don't care about record of what happened in the past.
* we're providing the module ansible can call to make something happen.
- * how do you keep track of multiple templates; today we use multiple RCs
+ * how do you keep track of multiple templates; today we use multiple RCs.
- * if we had a deployment controller ; deployment config spawns pos that runs rolling update; trigger is level-based update of image repository
+ * if we had a deployment controller; deployment config spawns pos that runs rolling update; trigger is level-based update of image repository.
- * alternative short-term proposal: create new rc as clone of old one, futz with counts so new one is old one and vv, bring prev-named one (pet) down to zero and bring it back up with new template (this is very similar to how Borg does job updates)
- * is it worthwhile if we want to have the deployments anyway? yes b/c we have lots of concepts already; need to simplify
+ * alternative short-term proposal: create new rc as clone of old one, futz with counts so new one is old one and vv, bring prev-named one (pet) down to zero and bring it back up with new template (this is very similar to how Borg does job updates).
+ * is it worthwhile if we want to have the deployments anyway? Yes b/c we have lots of concepts already; need to simplify.
- * deployment controller keeps track of multiple templates which is what you need for rolling updates and canaries
+ * deployment controller keeps track of multiple templates which is what you need for rolling updates and canaries.
* only reason for new thing is to move the process into the server instead of the client?
- * may not need to make it an API object; should provide experience where it's not an API object and is just something client side
+ * may not need to make it an API object; should provide experience where it's not an API object and is just something client side.
- * need an experience now so need to do it in client because object won't land before 1.0
+ * need an experience now so need to do it in client because object won't land before 1.0.
- * having simplified experience for people who only want to enageg w/ RCs
+ * having simplified experience for people who only want to enageg w/ RCs.
* how does rollback work: ctrl-c, rollout v2 v1. rollback pattern can be in person's head. 2 kinds of rollback: i'm at steady state and want to go back, and i've got canary deployment and hit ctrl-c how do i get rid of the canary deployment (e.g. new is failing). ctrl-c might not work. delete canary controller and its pods. wish there was a command to also delete pods (there is -- kbectl stop). argument for not reusing name: when you move fwd you can stop the new thing and you're ok, vs. if you replace the old one and you've created a copy if you hit ctrl-c you don't have anything you can stop. but you could wait to flip the name until the end, use naming convention so can figure out what is going on, etc.
- * two different experiences: (1) i'm using version control, have version history of last week rollout this week, rolling update with two files -> create v2, ??? v1, don't have a pet - moved into world of version control where have cumulative history and; (1) imperative kubectl v1 v2 where sys takes care of details, that's where we use the snapshot pattern
+ * two different experiences: (1) i'm using version control, have version history of last week rollout this week, rolling update with two files -> create v2, ??? v1, don't have a pet - moved into world of version control where have cumulative history and; (1) imperative kubectl v1 v2 where sys takes care of details, that's where we use the snapshot pattern.
* other imperative commands
* run-container (or just run): spec command on command line which makes it more similar to docker run; but not multi-container pods.
- * \--forever vs. not (one shot exec via simple commad)
+ * \--forever vs. not (one shot exec via simple command).
* would like it go interactive - run -it and runs in cluster but you have interactive terminal to your process.
* how do command line args work. could say --image multiple times. will cobra support? in openshift we have clever syntax for grouping arguments together. doesn't work for real structured parameters.
- * alternative: create pod; add container add container ...; run pod -- build and don't run object until 'run pod'
+ * alternative: create pod; add container add container ...; run pod -- build and don't run object until 'run pod'.
- * \-- to separate container args
+ * \-- to separate container args.
- * create a pod, mutate it before you run it - like initializer pattern
+ * create a pod, mutate it before you run it - like initializer pattern.
* kind discovery
- * if we have run and sometimes it creates an rc and sometimes it doesn't, how does user know what to delete if they want to delete whatever they created with run
+ * if we have run and sometimes it creates an rc and sometimes it doesn't, how does user know what to delete if they want to delete whatever they created with run.
- * bburns has proposal for don't specify kind if you do command like stop, delete; let kubectl figure it out
+ * bburns has proposal for don't specify kind if you do command like stop, delete; let kubectl figure it out.
- * alternative: allow you to define alias from name to set of resource types, eg. delete all which would follow that alias (all could mean everything in some namespace, or unscoped, etc.) - someone explicitly added something to a set vs. accidentally showed up like nodes
+ * alternative: allow you to define alias from name to set of resource types, eg. delete all which would follow that alias (all could mean everything in some namespace, or unscoped, etc.) - someone explicitly added something to a set vs. accidentally showed up like nodes.
* would like to see extended to allow tools to specify their own aliases (not just users); e.g. resize can say i can handle RCs, delete can say I can handle everything, et.c so we can automatically do these things w/o users have to specify stuff. but right mechanism.
- * resourcebuilder has conept of doing that kind of expansion depending on how we fit in targeted commands. for instance if you want to add a volume to pods and rcs, you need something to go find the pod template and change it. there's the search part of it (delete nginx -> you have to figure out what object they are referring to) and then command can say i got a pod i know what to do with a pod.
+ * resourcebuilder has concept of doing that kind of expansion depending on how we fit in targeted commands. for instance if you want to add a volume to pods and rcs, you need something to go find the pod template and change it. there's the search part of it (delete nginx -> you have to figure out what object they are referring to) and then command can say i got a pod i know what to do with a pod.
* alternative heuristic: what if default target of all commands was deployments. kubectl run -> deployment. too much work, easier to clean up existing CLI. leave door open for that. macro objects OK but a lot more work to make that work. eventually will want index to make these efficient. could rely more on swagger to tell us types.
2\. paul/downward api: env substitution
- * create ad-hoc env var like strings, e.g. k8s_pod_name that would get sub'd by system in objects
- * allow people to create env vars that refer to fields of k8s objects w/o query api from inside their container; in some caes enables query api from their container (e.g. pass obj names, namespaces); e.g. sidecar containers need this for pulling things from api server
+ * create ad-hoc env var like strings, e.g. k8s_pod_name that would get sub'd by system in objects.
+ * allow people to create env vars that refer to fields of k8s objects w/o query api from inside their container; in some cases enables query api from their container (e.g. pass obj names, namespaces); e.g. sidecar containers need this for pulling things from api server.
* another proposal similar: instead of env var like names, have JSON-path-like syntax for referring to object field names; e.g. $.[metadata.name][1] to refer to name of current object, maybe have some syntax for referring to related objects like node that a pod is on. advantage of JSON path-like syntax is that it's less ad hoc. disadvantage is that you can only refer to things that are fields of objects.
* for both, if you populate env vars then you have drawback that fields only set when container is created. but least degree of coupling -- off the shelf containers, containers don't need to know how to talk to k8s API. keeps the k8s concepts in the control plane.
* we were converging on JSON path like approach. but need prototype or at least deeper proposal to demo.
* paul: one variant is for env vars in addition to value field have different sources which is where you would plug in e.g. syntax you use to describe a field of an object; another source would be a source that described info about the host. have partial prototype. clean separation between what's in image vs. control plane. could use source idea for volume plugin.
- * use case: provide info for sidecar container to contact API server
- * use case: pass down unique identifiers or things like using UID as nique identifier
- * clayton: for rocket or gce metadata service being available for every pod for more sophisticated things; most containers want to find endpoint of service,
+ * use case: provide info for sidecar container to contact API server.
+ * use case: pass down unique identifiers or things like using UID as unique identifier.
+ * clayton: for rocket or gce metadata service being available for every pod for more sophisticated things; most containers want to find endpoint of service.
3\. preconditions/dependencies
@@ -104,8 +104,8 @@ Agenda:
* infer automatically if we ask people to declare which env vars they wanted, or have dep mech at pod or rc or obj level to say this obj doesn't become active until this other thing exists.
* can use event hook? only app owner knows their dependency or when service is ready to serve.
* one proposal is to use pre-start hook. another is precondition probe - pre-start hook could do a probe. does anything respond when i hit this svc address or ip, then probe fails. could be implemented in pre-start hook. more useful than post-start. is part of rkt spec. has stages 0, 1, 2. hard to do in docker today, easy in rocket.
-* pre-start hook in container: how will affect readiness probe since the container might have a lock until some arbitrary condition is met if you implement with prestart hook. there has to be some compensation on when kubelet runs readiness/liveness probes if you have a hook. systemd has timeouts around the stages of process lifecycle.
-* if we go to black box model of container pre-start makes sense; if container spec becomes more descriptive of process model like systemd, then does kubelet need to know more about process model to do the right thing
+* pre-start hook in container: how will affect readiness probe since the container might have a lock until some arbitrary condition is met if you implement with prestart hook. there has to be some compensation on when kubelet runs readiness/liveness probes if you have a hook. Systemd has timeouts around the stages of process lifecycle.
+* if we go to black box model of container pre-start makes sense; if container spec becomes more descriptive of process model like systemd, then does kubelet need to know more about process model to do the right thing.
* ideally msg from inside the container to say i've done all of my pre-start actions. sdnotify for systemd does this. you tell systemd that you're done, it will communicate to other deps that you're alive.
* but... someone could just implement preconds inside their container. makes it easier to adapt an app w/o having to change their image. alternative is just have a pattern how they do it themselves but we don't do it for them.
diff --git a/content/en/blog/_posts/2015-12-00-Creating-Raspberry-Pi-Cluster-Running.md b/content/en/blog/_posts/2015-12-00-Creating-Raspberry-Pi-Cluster-Running.md
index 4589efaa51..cabd719e49 100644
--- a/content/en/blog/_posts/2015-12-00-Creating-Raspberry-Pi-Cluster-Running.md
+++ b/content/en/blog/_posts/2015-12-00-Creating-Raspberry-Pi-Cluster-Running.md
@@ -69,7 +69,7 @@ $ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
-a17784253dd2 gcr.io/google\_containers/hyperkube-arm:v1.1.2 "/hyperkube controlle" 2 hours ago Up 2 hours k8s\_controller-manager.7042038a\_k8s-master-127.0.0.1\_default\_43160049df5e3b1c5ec7bcf23d4b97d0\_2174a7c3
+a17784253dd2 gcr.io/google\_containers/hyperkube-arm:v1.1.2 "/hyperkube controller" 2 hours ago Up 2 hours k8s\_controller-manager.7042038a\_k8s-master-127.0.0.1\_default\_43160049df5e3b1c5ec7bcf23d4b97d0\_2174a7c3
a0fb6a169094 gcr.io/google\_containers/hyperkube-arm:v1.1.2 "/hyperkube scheduler" 2 hours ago Up 2 hours k8s\_scheduler.d905fc61\_k8s-master-127.0.0.1\_default\_43160049df5e3b1c5ec7bcf23d4b97d0\_511945f8
diff --git a/content/en/blog/_posts/2016-03-00-Building-Highly-Available-Applications-Using-Kubernetes-New-Multi-Zone-Clusters-A.K.A-Ubernetes-Lite.md b/content/en/blog/_posts/2016-03-00-Building-Highly-Available-Applications-Using-Kubernetes-New-Multi-Zone-Clusters-aka-Ubernetes-Lite.md
similarity index 100%
rename from content/en/blog/_posts/2016-03-00-Building-Highly-Available-Applications-Using-Kubernetes-New-Multi-Zone-Clusters-A.K.A-Ubernetes-Lite.md
rename to content/en/blog/_posts/2016-03-00-Building-Highly-Available-Applications-Using-Kubernetes-New-Multi-Zone-Clusters-aka-Ubernetes-Lite.md
diff --git a/content/en/blog/_posts/2016-03-00-Kubernetes-1.2-And-Simplifying-Advanced-Networking-With-Ingress.md b/content/en/blog/_posts/2016-03-00-Kubernetes-1-2-And-Simplifying-Advanced-Networking-With-Ingress.md
similarity index 100%
rename from content/en/blog/_posts/2016-03-00-Kubernetes-1.2-And-Simplifying-Advanced-Networking-With-Ingress.md
rename to content/en/blog/_posts/2016-03-00-Kubernetes-1-2-And-Simplifying-Advanced-Networking-With-Ingress.md
diff --git a/content/en/blog/_posts/2016-03-00-Kubernetes-1.2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management-.md b/content/en/blog/_posts/2016-03-00-Kubernetes-1-2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management-.md
similarity index 100%
rename from content/en/blog/_posts/2016-03-00-Kubernetes-1.2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management-.md
rename to content/en/blog/_posts/2016-03-00-Kubernetes-1-2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management-.md
diff --git a/content/en/blog/_posts/2016-03-00-Using-Spark-And-Zeppelin-To-Process-Big-Data-On-Kubernetes.md b/content/en/blog/_posts/2016-03-00-Using-Spark-And-Zeppelin-To-Process-Big-Data-On-Kubernetes.md
index f730cab425..dcc9215c28 100644
--- a/content/en/blog/_posts/2016-03-00-Using-Spark-And-Zeppelin-To-Process-Big-Data-On-Kubernetes.md
+++ b/content/en/blog/_posts/2016-03-00-Using-Spark-And-Zeppelin-To-Process-Big-Data-On-Kubernetes.md
@@ -105,7 +105,9 @@ $ gsutil mb gs://my-spark-models
```
You’ll need to change this URI to something that is unique for you. This will create a bucket that you can use in the example above.
-**Note** : Computing the model and saving it is much slower than computing the model and throwing it away. This is expected. However, if you plan to reuse a model, it’s faster to compute the model and save it and then restore it each time you want to use it, rather than throw away and recompute the model each time.
+{{< note >}}
+Computing the model and saving it is much slower than computing the model and throwing it away. This is expected. However, if you plan to reuse a model, it’s faster to compute the model and save it and then restore it each time you want to use it, rather than throw away and recompute the model each time.
+{{< /note >}}
### Using Horizontal Pod Autoscaling with Spark (Optional)
Spark is somewhat elastic to workers coming and going, which means we have an opportunity: we can use use [Kubernetes Horizontal Pod Autoscaling](http://kubernetes.io/docs/user-guide/horizontal-pod-autoscaling/) to scale-out the Spark worker pool automatically, setting a target CPU threshold for the workers and a minimum/maximum pool size. This obviates the need for having to configure the number of worker replicas manually.
diff --git a/content/en/blog/_posts/2016-07-00-Cross-Cluster-Services.md b/content/en/blog/_posts/2016-07-00-Cross-Cluster-Services.md
index 58b9e67573..c5b0356d21 100644
--- a/content/en/blog/_posts/2016-07-00-Cross-Cluster-Services.md
+++ b/content/en/blog/_posts/2016-07-00-Cross-Cluster-Services.md
@@ -328,7 +328,7 @@ Standard Kubernetes service cluster-IP's already ensure that non-responsive indi
We'd love to hear feedback on Kubernetes Cross Cluster Services. To join the community:
-- Post issues or feature requests on [GitHub](https://github.com/kubernetes/kubernetes/tree/master/federation)
+- Post issues or feature requests on [GitHub](https://github.com/kubernetes/kubernetes/tree/release-1.8/federation)
- Join us in the #federation channel on [Slack](https://kubernetes.slack.com/messages/sig-federation)
- Participate in the [Cluster Federation SIG](https://groups.google.com/forum/#!forum/kubernetes-sig-federation)
diff --git a/content/en/blog/_posts/2016-07-00-Five-Days-Of-Kubernetes-1.3.md b/content/en/blog/_posts/2016-07-00-Five-Days-Of-Kubernetes-1-3.md
similarity index 100%
rename from content/en/blog/_posts/2016-07-00-Five-Days-Of-Kubernetes-1.3.md
rename to content/en/blog/_posts/2016-07-00-Five-Days-Of-Kubernetes-1-3.md
diff --git a/content/en/blog/_posts/2016-07-00-Kubernetes-1.3-Bridging-Cloud-Native-And-Enterprise-Workloads.md b/content/en/blog/_posts/2016-07-00-Kubernetes-1-3-Bridging-Cloud-Native-And-Enterprise-Workloads.md
similarity index 100%
rename from content/en/blog/_posts/2016-07-00-Kubernetes-1.3-Bridging-Cloud-Native-And-Enterprise-Workloads.md
rename to content/en/blog/_posts/2016-07-00-Kubernetes-1-3-Bridging-Cloud-Native-And-Enterprise-Workloads.md
diff --git a/content/en/blog/_posts/2016-09-00-Kubernetes-1.4-Making-It-Easy-To-Run-On-Kuberentes-Anywhere.md b/content/en/blog/_posts/2016-09-00-Kubernetes-1-4-Making-It-Easy-To-Run-On-Kuberentes-Anywhere.md
similarity index 100%
rename from content/en/blog/_posts/2016-09-00-Kubernetes-1.4-Making-It-Easy-To-Run-On-Kuberentes-Anywhere.md
rename to content/en/blog/_posts/2016-09-00-Kubernetes-1-4-Making-It-Easy-To-Run-On-Kuberentes-Anywhere.md
diff --git a/content/en/blog/_posts/2016-10-00-Production-Kubernetes-Dashboard-UI-1.4-improvements_3.md b/content/en/blog/_posts/2016-10-00-Production-Kubernetes-Dashboard-UI-1-4-improvements_3.md
similarity index 100%
rename from content/en/blog/_posts/2016-10-00-Production-Kubernetes-Dashboard-UI-1.4-improvements_3.md
rename to content/en/blog/_posts/2016-10-00-Production-Kubernetes-Dashboard-UI-1-4-improvements_3.md
diff --git a/content/en/blog/_posts/2016-11-00-Bringing-Kubernetes-Support-To-Azure.md b/content/en/blog/_posts/2016-11-00-Bringing-Kubernetes-Support-To-Azure.md
index d2a2c935de..a02144b95d 100644
--- a/content/en/blog/_posts/2016-11-00-Bringing-Kubernetes-Support-To-Azure.md
+++ b/content/en/blog/_posts/2016-11-00-Bringing-Kubernetes-Support-To-Azure.md
@@ -10,7 +10,7 @@ With more than a thousand people coming to [KubeCon](http://events.linuxfoundati
Today, Microsoft [announced](https://azure.microsoft.com/en-us/blog/azure-container-service-the-cloud-s-most-open-option-for-containers/) the next step in Kubernetes on Azure: the introduction of Kubernetes as a supported orchestrator in Azure Container Service (ACS). It’s been really exciting for me to join the ACS team and help build this new addition. The integration of Kubernetes into ACS means that with a few clicks in the Azure portal, or by running a single command in the new python-based Azure command line tool, you will be able to create a fully functional Kubernetes cluster that is integrated with the rest of your Azure resources.
-Kubernetes is availabe in public preview in Azure Container Service today. Community participation has always been an important part of the Kubernetes experience. Over the next few months, I hope you’ll join us and provide your feedback on the experience as we bring it to general availability.
+Kubernetes is available in public preview in Azure Container Service today. Community participation has always been an important part of the Kubernetes experience. Over the next few months, I hope you’ll join us and provide your feedback on the experience as we bring it to general availability.
In the spirit of community, we are also excited to announce a new open source project: [ACS Engine](https://github.com/azure/acs-engine). The goal of ACS Engine is to provide an open, community driven location to develop and share best practices for orchestrating containers on Azure. All of our knowledge of running containers in Azure has been captured in that repository, and we look forward to improving and extending it as we move forward with the community. Going forward, the templates in ACS Engine will be the basis for clusters deployed via the ACS API, and thus community driven improvements, features and more will have a natural path into the Azure Container Service. We’re excited to invite you to join us in improving ACS. Prior to the creation of ACS Engine, customers with unique requirements not supported by the ACS API needed to maintain variations on our templates. While these differences start small, they grew larger over time as the mainline template was improved and users also iterated their templates. These differences and drift really impact the ability for users to collaborate, since their templates are all different. Without the ability to share and collaborate, it’s difficult to form a community since every user is siloed in their own variant.
diff --git a/content/en/blog/_posts/2016-12-00-Cluster-Federation-In-Kubernetes-1.5.md b/content/en/blog/_posts/2016-12-00-Cluster-Federation-In-Kubernetes-1-5.md
similarity index 100%
rename from content/en/blog/_posts/2016-12-00-Cluster-Federation-In-Kubernetes-1.5.md
rename to content/en/blog/_posts/2016-12-00-Cluster-Federation-In-Kubernetes-1-5.md
diff --git a/content/en/blog/_posts/2016-12-00-Five-Days-Of-Kubernetes-1.5.md b/content/en/blog/_posts/2016-12-00-Five-Days-Of-Kubernetes-1-5.md
similarity index 100%
rename from content/en/blog/_posts/2016-12-00-Five-Days-Of-Kubernetes-1.5.md
rename to content/en/blog/_posts/2016-12-00-Five-Days-Of-Kubernetes-1-5.md
diff --git a/content/en/blog/_posts/2016-12-00-Kubernetes-1.5-Supporting-Production-Workloads.md b/content/en/blog/_posts/2016-12-00-Kubernetes-1-5-Supporting-Production-Workloads.md
similarity index 100%
rename from content/en/blog/_posts/2016-12-00-Kubernetes-1.5-Supporting-Production-Workloads.md
rename to content/en/blog/_posts/2016-12-00-Kubernetes-1-5-Supporting-Production-Workloads.md
diff --git a/content/en/blog/_posts/2017-03-00-Five-Days-Of-Kubernetes-1.6.md b/content/en/blog/_posts/2017-03-00-Five-Days-Of-Kubernetes-1-6.md
similarity index 100%
rename from content/en/blog/_posts/2017-03-00-Five-Days-Of-Kubernetes-1.6.md
rename to content/en/blog/_posts/2017-03-00-Five-Days-Of-Kubernetes-1-6.md
diff --git a/content/en/blog/_posts/2017-03-00-Kubernetes-1.6-Multi-User-Multi-Workloads-At-Scale.md b/content/en/blog/_posts/2017-03-00-Kubernetes-1-6-Multi-User-Multi-Workloads-At-Scale.md
similarity index 100%
rename from content/en/blog/_posts/2017-03-00-Kubernetes-1.6-Multi-User-Multi-Workloads-At-Scale.md
rename to content/en/blog/_posts/2017-03-00-Kubernetes-1-6-Multi-User-Multi-Workloads-At-Scale.md
diff --git a/content/en/blog/_posts/2017-03-00-Scalability-Updates-In-Kubernetes-1.6.md b/content/en/blog/_posts/2017-03-00-Scalability-Updates-In-Kubernetes-1-6.md
similarity index 100%
rename from content/en/blog/_posts/2017-03-00-Scalability-Updates-In-Kubernetes-1.6.md
rename to content/en/blog/_posts/2017-03-00-Scalability-Updates-In-Kubernetes-1-6.md
diff --git a/content/en/blog/_posts/2017-06-00-Kubernetes-1.7-Security-Hardening-Stateful-Application-Extensibility-Updates.md b/content/en/blog/_posts/2017-06-00-Kubernetes-1-7-Security-Hardening-Stateful-Application-Extensibility-Updates.md
similarity index 100%
rename from content/en/blog/_posts/2017-06-00-Kubernetes-1.7-Security-Hardening-Stateful-Application-Extensibility-Updates.md
rename to content/en/blog/_posts/2017-06-00-Kubernetes-1-7-Security-Hardening-Stateful-Application-Extensibility-Updates.md
diff --git a/content/en/blog/_posts/2017-08-00-Kubernetes-Meets-High-Performance.md b/content/en/blog/_posts/2017-08-00-Kubernetes-Meets-High-Performance.md
index a8bbac6f73..6db792a6e3 100644
--- a/content/en/blog/_posts/2017-08-00-Kubernetes-Meets-High-Performance.md
+++ b/content/en/blog/_posts/2017-08-00-Kubernetes-Meets-High-Performance.md
@@ -16,12 +16,10 @@ In Kubernetes, the base unit of scheduling is a Pod: one or more Docker containe
Traditional HPC applications often exhibit different characteristics:
--
-In financial or engineering simulations, a job may be comprised of tens of thousands of short-running tasks, demanding low-latency and high-throughput scheduling to complete a simulation in an acceptable amount of time.
--
-A computational fluid dynamics (CFD) problem may execute in parallel across many hundred or even thousands of nodes using a message passing library to synchronize state. This requires specialized scheduling and job management features to allocate and launch such jobs and then to checkpoint, suspend/resume or backfill them.
--
-Other HPC workloads may require specialized resources like GPUs or require access to limited software licenses. Organizations may enforce policies around what types of resources can be used by whom to ensure projects are adequately resourced and deadlines are met.
+- In financial or engineering simulations, a job may be comprised of tens of thousands of short-running tasks, demanding low-latency and high-throughput scheduling to complete a simulation in an acceptable amount of time.
+- A computational fluid dynamics (CFD) problem may execute in parallel across many hundred or even thousands of nodes using a message passing library to synchronize state. This requires specialized scheduling and job management features to allocate and launch such jobs and then to checkpoint, suspend/resume or backfill them.
+- Other HPC workloads may require specialized resources like GPUs or require access to limited software licenses. Organizations may enforce policies around what types of resources can be used by whom to ensure projects are adequately resourced and deadlines are met.
+
HPC workload schedulers have evolved to support exactly these kinds of workloads. Examples include [Univa Grid Engine](http://www.univa.com/products/), [IBM Spectrum LSF](https://www-03.ibm.com/systems/spectrum-computing/products/lsf/) and Altair’s [PBS Professional](http://www.pbsworks.com/PBSProduct.aspx?n=PBS-Professional&c=Overview-and-Capabilities). Sites managing HPC workloads have come to rely on capabilities like array jobs, configurable pre-emption, user, group or project based quotas and a variety of other features.
## Blurring the lines between containers and HPC
@@ -36,18 +34,15 @@ While the notion of packaging a workload into a Docker container, publishing it
To deal with the challenges of migrating to containers, organizations running container and HPC workloads have several options:
--
-Maintain separate infrastructures
+- Maintain separate infrastructures
For sites with sunk investments in HPC, this may be a preferred approach. Rather than disrupt existing environments, it may be easier to deploy new containerized applications on a separate cluster and leave the HPC environment alone. The challenge is that this comes at the cost of siloed clusters, increasing infrastructure and management cost.
--
-Run containerized workloads under an existing HPC workload manager
+- Run containerized workloads under an existing HPC workload manager
For sites running traditional HPC workloads, another approach is to use existing job submission mechanisms to launch jobs that in turn instantiate Docker containers on one or more target hosts. Sites using this approach can introduce containerized workloads with minimal disruption to their environment. Leading HPC workload managers such as [Univa Grid Engine Container Edition](http://blogs.univa.com/2016/05/new-version-of-univa-grid-engine-now-supports-docker-containers/) and [IBM Spectrum LSF](http://blogs.univa.com/2016/05/new-version-of-univa-grid-engine-now-supports-docker-containers/) are adding native support for Docker containers. [Shifter](https://github.com/NERSC/shifter) and [Singularity](http://singularity.lbl.gov/) are important open source tools supporting this type of deployment also. While this is a good solution for sites with simple requirements that want to stick with their HPC scheduler, they will not have access to native Kubernetes features, and this may constrain flexibility in managing long-running services where Kubernetes excels.
--
-Use native job scheduling features in Kubernetes
+- Use native job scheduling features in Kubernetes
Sites less invested in existing HPC applications can use existing scheduling facilities in Kubernetes for [jobs that run to completion](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/). While this is an option, it may be impractical for many HPC users. HPC applications are often either optimized towards massive throughput or large scale parallelism. In both cases startup and teardown latencies have a discriminating impact. Latencies that appear to be acceptable for containerized microservices today would render such applications unable to scale to the required levels.
@@ -75,7 +70,4 @@ One client having success with mixed workloads is the Institute for Health Metri

-
-
-
For sites deploying new clusters that want access to the rich capabilities in Kubernetes but need the flexibility to run non-containerized workloads, this approach is worth a look. It offers the opportunity for sites to share infrastructure between Kubernetes and HPC workloads without disrupting existing applications and businesses processes. It also allows them to migrate their HPC workloads to use Docker containers at their own pace.
diff --git a/content/en/blog/_posts/2017-10-00-Five-Days-Of-Kubernetes-18.md b/content/en/blog/_posts/2017-10-00-Five-Days-Of-Kubernetes-18.md
index 2e7375c861..d7011e4052 100644
--- a/content/en/blog/_posts/2017-10-00-Five-Days-Of-Kubernetes-18.md
+++ b/content/en/blog/_posts/2017-10-00-Five-Days-Of-Kubernetes-18.md
@@ -14,7 +14,7 @@ While many improvements have been contributed, we highlight key features in this
**Day 1:** [5 Days of Kubernetes 1.8](https://kubernetes.io/blog/2017/10/five-days-of-kubernetes-18)
**Day 2:** [kubeadm v1.8 Introduces Easy Upgrades for Kubernetes Clusters](https://kubernetes.io/blog/2017/10/kubeadm-v18-released)
-**Day 3:** [Kuberentes v.1.8 Retrospective: It Takes a Village to Raise a Kubernetes](https://kubernetes.io/blog/2017/10/it-takes-village-to-raise-kubernetes)
+**Day 3:** [Kubernetes v.1.8 Retrospective: It Takes a Village to Raise a Kubernetes](https://kubernetes.io/blog/2017/10/it-takes-village-to-raise-kubernetes)
**Day 4:** [Using RBAC, Generally Available in Kubernetes v1.8](https://kubernetes.io/blog/2017/10/using-rbac-generally-available-18)
**Day 5:** [Enforcing Network Policies in Kubernetes](https://kubernetes.io/blog/2017/10/enforcing-network-policies-in-kubernetes)
diff --git a/content/en/blog/_posts/2018-01-00-Extensible-Admission-Is-Beta.md b/content/en/blog/_posts/2018-01-00-Extensible-Admission-Is-Beta.md
index fe94dbf1b0..cc258be758 100644
--- a/content/en/blog/_posts/2018-01-00-Extensible-Admission-Is-Beta.md
+++ b/content/en/blog/_posts/2018-01-00-Extensible-Admission-Is-Beta.md
@@ -111,7 +111,7 @@ For the self-hosted category, a cleverly built webhook admission server and topo
### Simple, secure, portable, zero-config topology
If you build your webhook admission server to also be an extension API server, it becomes possible to aggregate it as a normal API server. This has a number of advantages:
-- Your webhook becomes available like any other API under default kube-apiserver service `kubernetes.default.svc` (e.g. [https://kubernetes.default.svc/apis/admission.example.com/v1/mymutatingadmissionreviews](https://kuberentes.default.svc/apis/admission.example.com/v1/mymutatingadmissionreviews)). Among other benefits, you can test using `kubectl`.
+- Your webhook becomes available like any other API under default kube-apiserver service `kubernetes.default.svc` (e.g. [https://kubernetes.default.svc/apis/admission.example.com/v1/mymutatingadmissionreviews](https://kubernetes.default.svc/apis/admission.example.com/v1/mymutatingadmissionreviews)). Among other benefits, you can test using `kubectl`.
- Your webhook automatically (without any config) makes use of the in-cluster authentication and authorization provided by kube-apiserver. You can restrict access to your webhook with normal RBAC rules.
- Your extension API servers and kube-apiserver automatically (without any config) make use of their in-cluster credentials to communicate with the webhook.
- Extension API servers do not leak their service account token to your webhook because they go through kube-apiserver, which is a secure front proxy.
diff --git a/content/en/blog/_posts/2018-03-26-kubernetes-1.10-stabilizing-storage-security-networking.md b/content/en/blog/_posts/2018-03-26-kubernetes-1-10-stabilizing-storage-security-networking.md
similarity index 100%
rename from content/en/blog/_posts/2018-03-26-kubernetes-1.10-stabilizing-storage-security-networking.md
rename to content/en/blog/_posts/2018-03-26-kubernetes-1-10-stabilizing-storage-security-networking.md
diff --git a/content/en/blog/_posts/2018-04-04-fixing-subpath-volume-vulnerability.md b/content/en/blog/_posts/2018-04-04-fixing-subpath-volume-vulnerability.md
index 9dd1a4759c..b7a25e7473 100644
--- a/content/en/blog/_posts/2018-04-04-fixing-subpath-volume-vulnerability.md
+++ b/content/en/blog/_posts/2018-04-04-fixing-subpath-volume-vulnerability.md
@@ -137,7 +137,7 @@ However, this design is prone to the classic time-of-check-to-time-of-use ([TOCT
We went a bit wild with this idea:
-* Create a working directory under the kubelet’s pod directory. Let’s call it `dir1`.
+* Create a working directory under the kubelet’s pod directory. Let’s call it `dir1`.
* Bind mount the base volume to under the working directory, `dir1/volume`.
* Chroot to the working directory `dir1`.
* Inside the chroot, bind mount `volume/subpath` to `subpath`. This ensures that any symlinks get resolved to inside the chroot environment.
diff --git a/content/en/blog/_posts/2018-04-11-migrating-the-kubernetes-blog.md b/content/en/blog/_posts/2018-04-11-migrating-the-kubernetes-blog.md
index a6f8dd46eb..00cc541d25 100644
--- a/content/en/blog/_posts/2018-04-11-migrating-the-kubernetes-blog.md
+++ b/content/en/blog/_posts/2018-04-11-migrating-the-kubernetes-blog.md
@@ -30,7 +30,7 @@ You can submit a blog post for consideration one of two ways:
If you have a post that you want to remain confidential until your publish date, please submit your post via the Google form. Otherwise, you can choose your submission process based on your comfort level and preferred workflow.
{{< note >}}
-**Note:** Our workflow hasn't changed for confidential advance drafts. Additionally, we'll coordinate publishing for time sensitive posts to ensure that information isn't released prematurely through an open pull request.
+Our workflow hasn't changed for confidential advance drafts. Additionally, we'll coordinate publishing for time sensitive posts to ensure that information isn't released prematurely through an open pull request.
{{< /note >}}
### Call for reviewers
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
similarity index 100%
rename from content/en/blog/_posts/2018-05-04-Announcing-Kubeflow-0.1.md
rename to content/en/blog/_posts/2018-05-04-Announcing-Kubeflow-0-1.md
diff --git a/content/en/blog/_posts/2018-06-26-kubernetes-1.11-release-announcement.md b/content/en/blog/_posts/2018-06-26-kubernetes-1-11-release-announcement.md
similarity index 100%
rename from content/en/blog/_posts/2018-06-26-kubernetes-1.11-release-announcement.md
rename to content/en/blog/_posts/2018-06-26-kubernetes-1-11-release-announcement.md
diff --git a/content/en/blog/_posts/2018-07-16-kubernetes-1.11-release-interview.md b/content/en/blog/_posts/2018-07-16-kubernetes-1-11-release-interview.md
similarity index 100%
rename from content/en/blog/_posts/2018-07-16-kubernetes-1.11-release-interview.md
rename to content/en/blog/_posts/2018-07-16-kubernetes-1-11-release-interview.md
diff --git a/content/en/blog/_posts/2018-07-18-11-ways-not-to-get-hacked.md b/content/en/blog/_posts/2018-07-18-11-ways-not-to-get-hacked.md
index b88fcc0c18..36e12c87fe 100644
--- a/content/en/blog/_posts/2018-07-18-11-ways-not-to-get-hacked.md
+++ b/content/en/blog/_posts/2018-07-18-11-ways-not-to-get-hacked.md
@@ -50,7 +50,7 @@ Autoscaling Kubernetes nodes was historically difficult, as each node requires a
-Kubernetes' ABAC (Attribute Based Access Control) has been [superseded by RBAC](http://blog.kubernetes.io/2017/04/rbac-support-in-kubernetes.html) since release 1.6, and should not be enabled on the API server. Use RBAC instead:
+Kubernetes' ABAC (Attribute Based Access Control) has been [superseded by RBAC](http://kubernetes.io/blog/2017/04/rbac-support-in-kubernetes.html) since release 1.6, and should not be enabled on the API server. Use RBAC instead:
```
--authorization-mode=RBAC
diff --git a/content/en/blog/_posts/2018-09-18-2018-linkerd-2.0.md b/content/en/blog/_posts/2018-09-18-2018-linkerd-2-0.md
similarity index 100%
rename from content/en/blog/_posts/2018-09-18-2018-linkerd-2.0.md
rename to content/en/blog/_posts/2018-09-18-2018-linkerd-2-0.md
diff --git a/content/en/blog/_posts/2018-09-27-kubernetes-1.12-release-announcement.md b/content/en/blog/_posts/2018-09-27-kubernetes-1-12-release-announcement.md
similarity index 100%
rename from content/en/blog/_posts/2018-09-27-kubernetes-1.12-release-announcement.md
rename to content/en/blog/_posts/2018-09-27-kubernetes-1-12-release-announcement.md
diff --git a/content/en/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md b/content/en/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md
new file mode 100644
index 0000000000..1cf40bd820
--- /dev/null
+++ b/content/en/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md
@@ -0,0 +1,58 @@
+---
+layout: blog
+title: 'Kubernetes Docs Updates, International Edition'
+date: 2018-11-08
+---
+
+**Author**: Zach Corleissen (Linux Foundation)
+
+As a co-chair of SIG Docs, I'm excited to share that Kubernetes docs have a fully mature workflow for localization (l10n).
+
+## Abbreviations galore
+
+L10n is an abbreviation for _localization_.
+
+I18n is an abbreviation for _internationalization_.
+
+I18n is [what you do](https://www.w3.org/International/questions/qa-i18n) to make l10n easier. L10n is a fuller, more comprehensive process than translation (_t9n_).
+
+## Why localization matters
+
+The goal of SIG Docs is to make Kubernetes easier to use for as many people as possible.
+
+One year ago, we looked at whether it was possible to host the output of a Chinese team working independently to translate the Kubernetes docs. After many conversations (including experts on OpenStack l10n), [much transformation](https://kubernetes.io/blog/2018/05/05/hugo-migration/), and [renewed commitment to easier localization](https://github.com/kubernetes/website/pull/10485), we realized that open source documentation is, like open source software, an ongoing exercise at the edges of what's possible.
+
+Consolidating workflows, language labels, and team-level ownership may seem like simple improvements, but these features make l10n scalable for increasing numbers of l10n teams. While SIG Docs continues to iterate improvements, we've paid off a significant amount of technical debt and streamlined l10n in a single workflow. That's great for the future as well as the present.
+
+## Consolidated workflow
+
+Localization is now consolidated in the [kubernetes/website](https://github.com/kubernetes/website) repository. We've configured the Kubernetes CI/CD system, [Prow](https://github.com/kubernetes/test-infra/tree/master/prow), to handle automatic language label assignment as well as team-level PR review and approval.
+
+### Language labels
+
+Prow automatically applies language labels based on file path. Thanks to SIG Docs contributor [June Yi](https://github.com/kubernetes/test-infra/pull/9835), folks can also manually assign language labels in pull request (PR) comments. For example, when left as a comment on an issue or PR, this command assigns the label `language/ko` (Korean).
+
+
+```
+/language ko
+```
+
+These repo labels let reviewers filter for PRs and issues by language. For example, you can now filter the k/website dashboard for [PRs with Chinese content](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+label%3Alanguage%2Fzh).
+
+### Team review
+
+L10n teams can now review and approve their own PRs. For example, review and approval permissions for English are [assigned in an OWNERS file](https://github.com/kubernetes/website/blob/master/content/en/OWNERS) in the top subfolder for English content.
+
+Adding `OWNERS` files to subdirectories lets localization teams review and approve changes without requiring a rubber stamp approval from reviewers who may lack fluency.
+
+## What's next
+
+We're looking forward to the [doc sprint in Shanghai](https://kccncchina2018english.sched.com/event/HVb2/contributor-summit-doc-sprint-additional-registration-required) to serve as a resource for the Chinese l10n team.
+
+We're excited to continue supporting the Japanese and Korean l10n teams, who are making excellent progress.
+
+If you're interested in localizing Kubernetes for your own language or region, check out our [guide to localizing Kubernetes docs](https://kubernetes.io/docs/contribute/localization/) and reach out to a [SIG Docs chair](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) for support.
+
+### Get involved with SIG Docs
+
+If you're interested in Kubernetes documentation, come to a SIG Docs [weekly meeting](https://github.com/kubernetes/community/tree/master/sig-docs#meetings), or join [#sig-docs in Kubernetes Slack](https://kubernetes.slack.com/messages/C1J0BPD2M/details/).
diff --git a/content/en/blog/_posts/grpc-load-balancing-with-linkerd.md b/content/en/blog/_posts/grpc-load-balancing-with-linkerd.md
new file mode 100644
index 0000000000..25739268c9
--- /dev/null
+++ b/content/en/blog/_posts/grpc-load-balancing-with-linkerd.md
@@ -0,0 +1,172 @@
+---
+layout: blog
+title: 'gRPC Load Balancing on Kubernetes without Tears'
+date: 2018-11-07
+---
+
+**Author**: William Morgan (Buoyant)
+
+Many new gRPC users are surprised to find that Kubernetes's default load
+balancing often doesn't work out of the box with gRPC. For example, here's what
+happens when you take a [simple gRPC Node.js microservices
+app](https://github.com/sourishkrout/nodevoto) and deploy it on Kubernetes:
+
+
+
+While the `voting` service displayed here has several pods, it's clear from
+Kubernetes's CPU graphs that only one of the pods is actually doing any
+work—because only one of the pods is receiving any traffic. Why?
+
+In this blog post, we describe why this happens, and how you can easily fix it
+by adding gRPC load balancing to any Kubernetes app with
+[Linkerd](https://linkerd.io), a [CNCF](https://cncf.io) service mesh and service sidecar.
+
+# Why does gRPC need special load balancing?
+
+First, let's understand why we need to do something special for gRPC.
+
+gRPC is an increasingly common choice for application developers. Compared to
+alternative protocols such as JSON-over-HTTP, gRPC can provide some significant
+benefits, including dramatically lower (de)serialization costs, automatic type
+checking, formalized APIs, and less TCP management overhead.
+
+However, gRPC also breaks the standard connection-level load balancing,
+including what's provided by Kubernetes. This is because gRPC is built on
+HTTP/2, and HTTP/2 is designed to have a single long-lived TCP connection,
+across which all requests are *multiplexed*—meaning multiple requests can be
+active on the same connection at any point in time. Normally, this is great, as
+it reduces the overhead of connection management. However, it also means that
+(as you might imagine) connection-level balancing isn't very useful. Once the
+connection is established, there's no more balancing to be done. All requests
+will get pinned to a single destination pod, as shown below:
+
+
+
+# Why doesn't this affect HTTP/1.1?
+
+The reason why this problem doesn't occur in HTTP/1.1, which also has the
+concept of long-lived connections, is because HTTP/1.1 has several features
+that naturally result in cycling of TCP connections. Because of this,
+connection-level balancing is "good enough", and for most HTTP/1.1 apps we
+don't need to do anything more.
+
+To understand why, let's take a deeper look at HTTP/1.1. In contrast to HTTP/2,
+HTTP/1.1 cannot multiplex requests. Only one HTTP request can be active at a
+time per TCP connection. The client makes a request, e.g. `GET /foo`, and then
+waits until the server responds. While that request-response cycle is
+happening, no other requests can be issued on that connection.
+
+Usually, we want lots of requests happening in parallel. Therefore, to have
+concurrent HTTP/1.1 requests, we need to make multiple HTTP/1.1 connections,
+and issue our requests across all of them. Additionally, long-lived HTTP/1.1
+connections typically expire after some time, and are torn down by the client
+(or server). These two factors combined mean that HTTP/1.1 requests typically
+cycle across multiple TCP connections, and so connection-level balancing works.
+
+# So how do we load balance gRPC?
+
+Now back to gRPC. Since we can't balance at the connection level, in order to
+do gRPC load balancing, we need to shift from connection balancing to *request*
+balancing. In other words, we need to open an HTTP/2 connection to each
+destination, and balance *requests* across these connections, as shown below:
+
+
+
+In network terms, this means we need to make decisions at L5/L7 rather than
+L3/L4, i.e. we need to understand the protocol sent over the TCP connections.
+
+How do we accomplish this? There are a couple options. First, our application
+code could manually maintain its own load balancing pool of destinations, and
+we could configure our gRPC client to [use this load balancing
+pool](https://godoc.org/google.golang.org/grpc/balancer). This approach gives
+us the most control, but it can be very complex in environments like Kubernetes
+where the pool changes over time as Kubernetes reschedules pods. Our
+application would have to watch the Kubernetes API and keep itself up to date
+with the pods.
+
+Alternatively, in Kubernetes, we could deploy our app as [headless
+services](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services).
+In this case, Kubernetes [will create multiple A
+records](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services)
+in the DNS entry for the service. If our gRPC client is sufficiently advanced,
+it can automatically maintain the load balancing pool from those DNS entries.
+But this approach restricts us to certain gRPC clients, and it's rarely
+possible to only use headless services.
+
+Finally, we can take a third approach: use a lightweight proxy.
+
+# gRPC load balancing on Kubernetes with Linkerd
+
+[Linkerd](https://linkerd.io) is a [CNCF](https://cncf.io)-hosted *service
+mesh* for Kubernetes. Most relevant to our purposes, Linkerd also functions as
+a *service sidecar*, where it can be applied to a single service—even without
+cluster-wide permissions. What this means is that when we add Linkerd to our
+service, it adds a tiny, ultra-fast proxy to each pod, and these proxies watch
+the Kubernetes API and do gRPC load balancing automatically. Our deployment
+then looks like this:
+
+
+
+Using Linkerd has a couple advantages. First, it works with services written in
+any language, with any gRPC client, and any deployment model (headless or not).
+Because Linkerd's proxies are completely transparent, they auto-detect HTTP/2
+and HTTP/1.x and do L7 load balancing, and they pass through all other traffic
+as pure TCP. This means that everything will *just work.*
+
+Second, Linkerd's load balancing is very sophisticated. Not only does Linkerd
+maintain a watch on the Kubernetes API and automatically update the load
+balancing pool as pods get rescheduled, Linkerd uses an *exponentially-weighted
+moving average* of response latencies to automatically send requests to the
+fastest pods. If one pod is slowing down, even momentarily, Linkerd will shift
+traffic away from it. This can reduce end-to-end tail latencies.
+
+Finally, Linkerd's Rust-based proxies are incredibly fast and small. They
+introduce <1ms of p99 latency and require <10mb of RSS per pod, meaning that
+the impact on system performance will be negligible.
+
+# gRPC Load Balancing in 60 seconds
+
+Linkerd is very easy to try. Just follow the steps in the [Linkerd Getting
+Started Instructions](https://linkerd.io/2/getting-started/)—install the
+CLI on your laptop, install the control plane on your cluster, and "mesh" your
+service (inject the proxies into each pod). You'll have Linkerd running on your
+service in no time, and should see proper gRPC balancing immediately.
+
+Let's take a look at our sample `voting` service again, this time after
+installing Linkerd:
+
+
+
+As we can see, the CPU graphs for all pods are active, indicating that all pods
+are now taking traffic—without having to change a line of code. Voila,
+gRPC load balancing as if by magic!
+
+Linkerd also gives us built-in traffic-level dashboards, so we don't even need
+to guess what's happening from CPU charts any more. Here's a Linkerd graph
+that's showing the success rate, request volume, and latency percentiles of
+each pod:
+
+
+
+We can see that each pod is getting around 5 RPS. We can also see that, while
+we've solved our load balancing problem, we still have some work to do on our
+success rate for this service. (The demo app is built with an intentional
+failure—as an exercise to the reader, see if you can figure it out by
+using the Linkerd dashboard!)
+
+# Wrapping it up
+
+If you're interested in a dead simple way to add gRPC load balancing to your
+Kubernetes services, regardless of what language it's written in, what gRPC
+client you're using, or how it's deployed, you can use Linkerd to add gRPC load
+balancing in a few commands.
+
+There's a lot more to Linkerd, including security, reliability, and debugging
+and diagnostics features, but those are topics for future blog posts.
+
+Want to learn more? We’d love to have you join our rapidly-growing community!
+Linkerd is a [CNCF](https://cncf.io) project, [hosted on
+GitHub](https://github.com/linkerd/linkerd2), and has a thriving community
+on [Slack](https://slack.linkerd.io), [Twitter](https://twitter.com/linkerd),
+and the [mailing lists](https://lists.cncf.io/g/cncf-linkerd-users). Come and
+join the fun!
diff --git a/content/en/community/_index.html b/content/en/community/_index.html
index 88cf6b07d5..16b0d0e371 100644
--- a/content/en/community/_index.html
+++ b/content/en/community/_index.html
@@ -10,7 +10,7 @@ cid: community
Ensuring Kubernetes works well everywhere and for everyone.
Connect with the Kubernetes community on our Slack channel, discussion board, or join the
Kubernetes-dev Google group. A weekly
- community meeting takes place via video conference to discuss the state of affairs, see
+ community meeting takes place via video conference to discuss the state of affairs, see
these instructions for information
on how to participate.
You can also join Kubernetes all around the world through our
@@ -26,18 +26,9 @@ cid: community
As a member of the Kubernetes community, you are welcome to join any of the SIG meetings
you are interested in. No registration required.
-
+
-
+
Code of Conduct
The Kubernetes community values respect and inclusiveness, and
@@ -46,8 +37,8 @@ cid: community
an event or meeting, in Slack, or in another communication
mechanism, reach out to the Kubernetes Code of Conduct Committeeconduct@kubernetes.io.
- Your anonymity will be protected.
-
+ Your anonymity will be protected.
+
diff --git a/content/en/docs/concepts/architecture/cloud-controller.md b/content/en/docs/concepts/architecture/cloud-controller.md
index 191b954645..82f791ff1f 100644
--- a/content/en/docs/concepts/architecture/cloud-controller.md
+++ b/content/en/docs/concepts/architecture/cloud-controller.md
@@ -51,7 +51,7 @@ In version 1.9, the CCM runs the following controllers from the preceding list:
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.
+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.
@@ -109,7 +109,7 @@ The PersistentVolumeLabels controller moves the cloud-dependent functionality of
## Plugin mechanism
-The cloud controller manager uses Go interfaces to allow implementations from any cloud to be plugged in. Specifically, it uses the CloudProvider Interface defined [here](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go).
+The cloud controller manager uses Go interfaces to allow implementations from any cloud to be plugged in. Specifically, it uses the CloudProvider Interface defined [here](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62).
The implementation of the four shared controllers highlighted above, and some scaffolding along with the shared cloudprovider interface, will stay in the Kubernetes core. Implementations specific to cloud providers will be built outside of the core and implement interfaces defined in the core.
diff --git a/content/en/docs/concepts/architecture/master-node-communication.md b/content/en/docs/concepts/architecture/master-node-communication.md
index 0314197bc4..7c6b3a9f1c 100644
--- a/content/en/docs/concepts/architecture/master-node-communication.md
+++ b/content/en/docs/concepts/architecture/master-node-communication.md
@@ -77,7 +77,7 @@ To verify this connection, use the `--kubelet-certificate-authority` flag to
provide the apiserver with a root certificate bundle to use to verify the
kubelet's serving certificate.
-If that is not possible, use [SSH tunneling](/docs/concepts/architecture/master-node-communication/#ssh-tunnels)
+If that is not possible, use [SSH tunneling](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
between the apiserver and kubelet if required to avoid connecting over an
untrusted or public network.
diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md
index f5bb11bf37..5a4d84dc17 100644
--- a/content/en/docs/concepts/architecture/nodes.md
+++ b/content/en/docs/concepts/architecture/nodes.md
@@ -53,7 +53,6 @@ The `conditions` field describes the status of all `Running` nodes.
| `PIDPressure` | `True` if pressure exists on the processes -- that is, if there are too many processes on the node; otherwise `False` |
| `DiskPressure` | `True` if pressure exists on the disk size -- that is, if the disk capacity is low; otherwise `False` |
| `NetworkUnavailable` | `True` if the network for the node is not correctly configured, otherwise `False` |
-| `ConfigOK` | `True` if the kubelet is correctly configured, otherwise `False` |
The node condition is represented as a JSON object. For example, the following response describes a healthy node.
@@ -85,7 +84,7 @@ A Pod that does not have any tolerations gets scheduled according to the old mod
tolerates the taints of a particular Node can be scheduled on that Node.
{{< caution >}}
-**Caution:** Enabling this feature creates a small delay between the
+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 >}}
@@ -129,7 +128,7 @@ services are running -- it is eligible to run a pod. Otherwise, it is
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.
+Kubernetes keeps the object for the invalid node and keeps checking to see whether it becomes valid.
You must explicitly delete the Node object to stop this process.
{{< /note >}}
@@ -242,7 +241,7 @@ kubectl cordon $NODENAME
```
{{< note >}}
-**Note:** Pods created by a DaemonSet controller bypass the Kubernetes scheduler
+Pods created by a DaemonSet controller bypass the Kubernetes scheduler
and do not respect the unschedulable attribute on a node. This assumes that daemons belong on
the machine even if it is being drained of applications while it prepares for a reboot.
{{< /note >}}
diff --git a/content/en/docs/concepts/cluster-administration/_index.md b/content/en/docs/concepts/cluster-administration/_index.md
index cdef77a4dd..72af40feec 100755
--- a/content/en/docs/concepts/cluster-administration/_index.md
+++ b/content/en/docs/concepts/cluster-administration/_index.md
@@ -1,5 +1,5 @@
---
-title: "Compute, Storage, and Networking Extensions"
-weight: 30
+title: "Cluster Administration"
+weight: 100
---
diff --git a/content/en/docs/concepts/cluster-administration/certificates.md b/content/en/docs/concepts/cluster-administration/certificates.md
index 48592dc7c3..40e4fb922c 100644
--- a/content/en/docs/concepts/cluster-administration/certificates.md
+++ b/content/en/docs/concepts/cluster-administration/certificates.md
@@ -34,7 +34,7 @@ manually through `easyrsa`, `openssl` or `cfssl`.
that is specified as the `--service-cluster-ip-range` argument for both the API server and
the controller manager component. The argument `--days` is used to set the number of days
after which the certificate expires.
- The sample below also assume that you are using `cluster.local` as the default
+ The sample below also assumes that you are using `cluster.local` as the default
DNS domain name.
./easyrsa --subject-alt-name="IP:${MASTER_IP},"\
@@ -71,7 +71,7 @@ manually through `easyrsa`, `openssl` or `cfssl`.
with real values before saving this to a file (e.g. `csr.conf`).
Note that the value for `MASTER_CLUSTER_IP` is the service cluster IP for the
API server as described in previous subsection.
- The sample below also assume that you are using `cluster.local` as the default
+ The sample below also assumes that you are using `cluster.local` as the default
DNS domain name.
[ req ]
@@ -186,7 +186,7 @@ Finally, add the same parameters into the API server start parameters.
server as shown below. Be sure to replace the values in angle brackets with
real values you want to use. The `MASTER_CLUSTER_IP` is the service cluster
IP for the API server as described in previous subsection.
- The sample below also assume that you are using `cluster.local` as the default
+ The sample below also assumes that you are using `cluster.local` as the default
DNS domain name.
{
diff --git a/content/en/docs/concepts/cluster-administration/cloud-providers.md b/content/en/docs/concepts/cluster-administration/cloud-providers.md
index e3c7f153af..7fba2d0fb0 100644
--- a/content/en/docs/concepts/cluster-administration/cloud-providers.md
+++ b/content/en/docs/concepts/cluster-administration/cloud-providers.md
@@ -96,7 +96,7 @@ Different settings can be applied to a load balancer service in AWS using _annot
* `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`: Used on the service to enable or disable cross-zone load balancing.
* `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`: Used on the service to specify additional security groups to be added to ELB created
* `service.beta.kubernetes.io/aws-load-balancer-internal`: Used on the service to indicate that we want an internal ELB.
-* `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: Used on the service to enable the proxy protocol on an ELB. Right now we only accept the value `*` which means enable the proxy protocol on all ELB backends. In the future we could adjust this to allow setting the proxy protocol only on certain backends.
+* `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: Used on the service to enable the proxy protocol on an ELB. Right now we only accept the value `*` which means enabling the proxy protocol on all ELB backends. In the future we could adjust this to allow setting the proxy protocol only on certain backends.
* `service.beta.kubernetes.io/aws-load-balancer-ssl-ports`: Used on the service to specify a comma-separated list of ports that will use SSL/HTTPS listeners. Defaults to `*` (all)
The information for the annotations for AWS is taken from the comments on [aws.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/aws/aws.go)
@@ -358,7 +358,9 @@ Note that the Kubernetes Node name must match the Photon VM name (or if `overrid
### Node Name
-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.
+The VSphere cloud provider uses the detected hostname of the node (as determined by the kubelet) as the name of the Kubernetes Node object.
+
+The `--hostname-override` parameter is ignored by the VSphere cloud provider.
## IBM Cloud Kubernetes Service
diff --git a/content/en/docs/concepts/cluster-administration/logging.md b/content/en/docs/concepts/cluster-administration/logging.md
index f64e0e0aa3..d6aa8c45de 100644
--- a/content/en/docs/concepts/cluster-administration/logging.md
+++ b/content/en/docs/concepts/cluster-administration/logging.md
@@ -57,7 +57,9 @@ You can use `kubectl logs` to retrieve logs from a previous instantiation of a c
Everything a containerized application writes to `stdout` and `stderr` is handled and redirected somewhere by a container engine. For example, the Docker container engine redirects those two streams to [a logging driver](https://docs.docker.com/engine/admin/logging/overview), which is configured in Kubernetes to write to a file in json format.
-**Note:** The Docker json logging driver treats each line as a separate message. When using the Docker logging driver, there is no direct support for multi-line messages. You need to handle multi-line messages at the logging agent level or higher.
+{{< note >}}
+The Docker json logging driver treats each line as a separate message. When using the Docker logging driver, there is no direct support for multi-line messages. You need to handle multi-line messages at the logging agent level or higher.
+{{< /note >}}
By default, if a container restarts, the kubelet keeps one terminated container with its logs. If a pod is evicted from the node, all corresponding containers are also evicted, along with their logs.
@@ -81,13 +83,15 @@ When you run [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands
the basic logging example, the kubelet on the node handles the request and
reads directly from the log file, returning the contents in the response.
-**Note:** Currently, if some external system has performed the rotation,
+{{< note >}}
+Currently, if some external system has performed the rotation,
only the contents of the latest log file will be available through
`kubectl logs`. E.g. if there's a 10MB file, `logrotate` performs
the rotation and there are two files, one 10MB in size and one empty,
`kubectl logs` will return an empty response.
[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh
+{{< /note >}}
### System component logs
@@ -215,10 +219,12 @@ If the node-level logging agent is not flexible enough for your situation, you
can create a sidecar container with a separate logging agent that you have
configured specifically to run with your application.
-**Note**: Using a logging agent in a sidecar container can lead
+{{< note >}}
+Using a logging agent in a sidecar container can lead
to significant resource consumption. Moreover, you won't be able to access
those logs using `kubectl logs` command, because they are not controlled
by the kubelet.
+{{< /note >}}
As an example, you could use [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/),
which uses fluentd as a logging agent. Here are two configuration files that
@@ -227,9 +233,11 @@ a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to c
{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
-**Note**: The configuration of fluentd is beyond the scope of this article. For
+{{< note >}}
+The configuration of fluentd is beyond the scope of this article. For
information about configuring fluentd, see the
[official fluentd documentation](http://docs.fluentd.org/).
+{{< /note >}}
The second file describes a pod that has a sidecar container running fluentd.
The pod mounts a volume where fluentd can pick up its configuration data.
diff --git a/content/en/docs/concepts/cluster-administration/manage-deployment.md b/content/en/docs/concepts/cluster-administration/manage-deployment.md
index e32fe5b8fb..0288c73efa 100644
--- a/content/en/docs/concepts/cluster-administration/manage-deployment.md
+++ b/content/en/docs/concepts/cluster-administration/manage-deployment.md
@@ -331,7 +331,7 @@ Currently, resources are created without this annotation, so the first invocatio
All subsequent calls to `kubectl apply`, and other commands that modify the configuration, such as `kubectl replace` and `kubectl edit`, will update the annotation, allowing subsequent calls to `kubectl apply` to detect and perform deletions using a three-way diff.
{{< note >}}
-**Note:** To use apply, always create resource initially with either `kubectl apply` or `kubectl create --save-config`.
+To use apply, always create resource initially with either `kubectl apply` or `kubectl create --save-config`.
{{< /note >}}
### kubectl edit
diff --git a/content/en/docs/concepts/configuration/_index.md b/content/en/docs/concepts/configuration/_index.md
index 00cf8e8c0f..1635c2a5bf 100755
--- a/content/en/docs/concepts/configuration/_index.md
+++ b/content/en/docs/concepts/configuration/_index.md
@@ -1,5 +1,5 @@
---
title: "Configuration"
-weight: 70
+weight: 80
---
diff --git a/content/en/docs/concepts/configuration/assign-pod-node.md b/content/en/docs/concepts/configuration/assign-pod-node.md
index d1d9cffc53..5a0f861654 100644
--- a/content/en/docs/concepts/configuration/assign-pod-node.md
+++ b/content/en/docs/concepts/configuration/assign-pod-node.md
@@ -87,7 +87,7 @@ with a standard set of labels. As of Kubernetes v1.4 these labels are
* `beta.kubernetes.io/arch`
{{< note >}}
-**Note:** The value of these labels is cloud provider specific and is not guaranteed to be reliable.
+The value of these labels is cloud provider specific and is not guaranteed to be reliable.
For example, the value of `kubernetes.io/hostname` may be the same as the Node name in some environments
and a different value in other environments.
{{< /note >}}
@@ -173,11 +173,15 @@ 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.
+{{< /note >}}
-**Note:** Pod anti-affinity requires nodes to be consistently labelled, i.e. every node in the cluster must have an appropriate label matching `topologyKey`. If some or all nodes are missing the specified `topologyKey` label, it can lead to unintended behavior.
+{{< note >}}
+Pod anti-affinity requires nodes to be consistently labelled, i.e. every node in the cluster must have an appropriate label matching `topologyKey`. If some or all nodes are missing the specified `topologyKey` label, it can lead to unintended behavior.
+{{< /note >}}
As with node affinity, there are currently two types of pod affinity and anti-affinity, called `requiredDuringSchedulingIgnoredDuringExecution` and
`preferredDuringSchedulingIgnoredDuringExecution` which denote "hard" vs. "soft" requirements.
diff --git a/content/en/docs/concepts/configuration/manage-compute-resources-container.md b/content/en/docs/concepts/configuration/manage-compute-resources-container.md
index 86c2faa1fe..b05b2e508d 100644
--- a/content/en/docs/concepts/configuration/manage-compute-resources-container.md
+++ b/content/en/docs/concepts/configuration/manage-compute-resources-container.md
@@ -149,7 +149,9 @@ When using Docker:
multiplied by 100. The resulting value is the total amount of CPU time that a container can use
every 100ms. A container cannot use more than its share of CPU time during this interval.
- {{< note >}}**Note**: The default quota period is 100ms. The minimum resolution of CPU quota is 1ms.{{ note >}}
+ {{< note >}}
+ The default quota period is 100ms. The minimum resolution of CPU quota is 1ms.
+ {{ note >}}
- The `spec.containers[].resources.limits.memory` is converted to an integer, and
used as the value of the
@@ -317,7 +319,7 @@ Kubernetes version 1.8 introduces a new resource, _ephemeral-storage_ for managi
This partition is “ephemeral” and applications cannot expect any performance SLAs (Disk IOPS for example) from this partition. Local ephemeral storage management only applies for the root partition; the optional partition for image layer and writable layer is out of scope.
{{< note >}}
-**Note:** If an optional runtime partition is used, root partition will not hold any image layer or writable layers.
+If an optional runtime partition is used, root partition will not hold any image layer or writable layers.
{{< /note >}}
### Requests and limits setting for local ephemeral storage
@@ -420,7 +422,7 @@ http://k8s-master:8080/api/v1/nodes/k8s-node-1/status
```
{{< note >}}
-**Note**: In the preceding request, `~1` is the encoding for the character `/`
+In the preceding request, `~1` is the encoding for the character `/`
in the patch path. The operation path value in JSON-Patch is interpreted as a
JSON-Pointer. For more details, see
[IETF RFC 6901, section 3](https://tools.ietf.org/html/rfc6901#section-3).
@@ -476,7 +478,7 @@ Examples of _valid_ quantities are `3`, `3000m` and `3Ki`. Examples of
_invalid_ quantities are `0.5` and `1500m`.
{{< note >}}
-**Note:** Extended resources replace Opaque Integer Resources.
+Extended resources replace Opaque Integer Resources.
Users can use any domain name prefix other than `kubernetes.io` which is reserved.
{{< /note >}}
@@ -484,7 +486,7 @@ To consume an extended resource in a Pod, include the resource name as a key
in the `spec.containers[].resources.limits` map in the container spec.
{{< note >}}
-**Note:** Extended resources cannot be overcommitted, so request and limit
+Extended resources cannot be overcommitted, so request and limit
must be equal if both are present in a container spec.
{{< /note >}}
diff --git a/content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
index d48b600bef..8a77e153df 100644
--- a/content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
+++ b/content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
@@ -12,7 +12,7 @@ find the information it needs to choose a cluster and communicate with the API s
of a cluster.
{{< note >}}
-**Note:** A file that is used to configure access to clusters is called
+A file that is used to configure access to clusters is called
a *kubeconfig file*. This is a generic way of referring to configuration files.
It does not mean that there is a file named `kubeconfig`.
{{< /note >}}
diff --git a/content/en/docs/concepts/configuration/overview.md b/content/en/docs/concepts/configuration/overview.md
index 932e0a93eb..b7d74b4abe 100644
--- a/content/en/docs/concepts/configuration/overview.md
+++ b/content/en/docs/concepts/configuration/overview.md
@@ -84,15 +84,15 @@ The [imagePullPolicy](/docs/concepts/containers/images/#updating-images) and the
- `imagePullPolicy: Never`: the image is assumed to exist locally. No attempt is made to pull the image.
{{< note >}}
- **Note:** To make sure the container always uses the same version of the image, you can specify its [digest](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier), for example `sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`. The digest uniquely identifies a specific version of the image, so it is never updated by Kubernetes unless you change the digest value.
+To make sure the container always uses the same version of the image, you can specify its [digest](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier), for example `sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`. The digest uniquely identifies a specific version of the image, so it is never updated by Kubernetes unless you change the digest value.
{{< /note >}}
{{< note >}}
- **Note:** You should avoid using the `:latest` tag when deploying containers in production as it is harder to track which version of the image is running and more difficult to roll back properly.
+You should avoid using the `:latest` tag when deploying containers in production as it is harder to track which version of the image is running and more difficult to roll back properly.
{{< /note >}}
{{< note >}}
- **Note:** The caching semantics of the underlying image provider make even `imagePullPolicy: Always` efficient. With Docker, for example, if the image already exists, the pull attempt is fast because all image layers are cached and no image download is needed.
+The caching semantics of the underlying image provider make even `imagePullPolicy: Always` efficient. With Docker, for example, if the image already exists, the pull attempt is fast because all image layers are cached and no image download is needed.
{{< /note >}}
## Using kubectl
diff --git a/content/en/docs/concepts/configuration/pod-priority-preemption.md b/content/en/docs/concepts/configuration/pod-priority-preemption.md
index 6349a0b56a..909b5c01ab 100644
--- a/content/en/docs/concepts/configuration/pod-priority-preemption.md
+++ b/content/en/docs/concepts/configuration/pod-priority-preemption.md
@@ -9,7 +9,6 @@ weight: 70
{{% capture overview %}}
-{{< feature-state for_k8s_version="1.8" state="alpha" >}}
{{< feature-state for_k8s_version="1.11" state="beta" >}}
[Pods](/docs/user-guide/pods) can have _priority_. Priority indicates the
@@ -36,7 +35,7 @@ Kubernetes Version | Priority and Preemption State | Enabled by default
1.10 | alpha | no
1.11 | beta | yes
-{{< warning >}} **Warning**: In a cluster where not all users are trusted, a
+{{< warning >}}In a cluster where not all users are trusted, a
malicious user could create pods at the highest possible priorities, causing
other pods to be evicted/not get scheduled. To resolve this issue,
[ResourceQuota](https://kubernetes.io/docs/concepts/policy/resource-quotas/) is
@@ -71,24 +70,13 @@ Pods.
## How to disable preemption
-{{< note >}} **Note**: In Kubernetes 1.11, critical pods (except DaemonSet pods,
-which are still scheduled by the DaemonSet controller) rely on scheduler
-preemption to be scheduled when a cluster is under resource pressure. For this
-reason, you will need to run an older version of Rescheduler if you decide to
-disable preemption. More on this is provided below. {{< /note >}}
-
-#### Option 1: Disable both Pod priority and preemption
-
-Disabling Pod priority disables preemption as well. In order to disable Pod
-Priority, set the feature to false for API server, Scheduler, and Kubelet.
-Disabling the feature on Kubelets is not vital. You can leave the feature on for
-Kubelets if rolling out is hard.
-
-```
---feature-gates=PodPriority=false
-```
-
-#### Option 2: Disable Preemption only
+{{< note >}}
+In Kubernetes 1.11, critical pods (except DaemonSet pods, which are
+still scheduled by the DaemonSet controller) rely on scheduler preemption to be
+scheduled when a cluster is under resource pressure. For this reason, you will
+need to run an older version of Rescheduler if you decide to disable preemption.
+More on this is provided below.
+{{< /note >}}
In Kubernetes 1.11 and later, preemption is controlled by a kube-scheduler flag
`disablePreemption`, which is set to `false` by default.
@@ -253,7 +241,7 @@ priority Pods to zero or a small number.
#### PodDisruptionBudget is supported, but not guaranteed!
A [Pod Disruption Budget (PDB)](/docs/concepts/workloads/pods/disruptions/)
-allows application owners to limit the number Pods of a replicated application
+allows application owners to limit the number of Pods of a replicated application
that are down simultaneously from voluntary disruptions. Kubernetes 1.9 supports
PDB when preempting Pods, but respecting PDB is best effort. The Scheduler tries
to find victims whose PDB are not violated by preemption, but if no such victims
@@ -266,11 +254,13 @@ A Node is considered for preemption only when the answer to this question is
yes: "If all the Pods with lower priority than the pending Pod are removed from
the Node, can the pending Pod be scheduled on the Node?"
-{{< note >}} **Note:** Preemption does not necessarily remove all lower-priority
+{{< note >}}
+Preemption does not necessarily remove all lower-priority
Pods. If the pending Pod can be scheduled by removing fewer than all
lower-priority Pods, then only a portion of the lower-priority Pods are removed.
Even so, the answer to the preceding question must be yes. If the answer is no,
-the Node is not considered for preemption. {{< /note >}}
+the Node is not considered for preemption.
+{{< /note >}}
If a pending Pod has inter-pod affinity to one or more of the lower-priority
Pods on the Node, the inter-Pod affinity rule cannot be satisfied in the absence
@@ -339,7 +329,7 @@ than the victims. If preemption happens in such scenarios, please file an issue.
When pods are preempted, they receive their requested graceful termination
period, which is by default 30 seconds, but it can be any different value as
-specified in the PodSpec. If the victim Pods do not terminate within this period
+specified in the PodSpec. If the victim Pods do not terminate within this period,
they are force-terminated. Once all the victims go away, the preemptor Pod can
be scheduled.
diff --git a/content/en/docs/concepts/configuration/scheduler-perf-tuning.md b/content/en/docs/concepts/configuration/scheduler-perf-tuning.md
index f0dcfa47ed..41ce9dfb1a 100644
--- a/content/en/docs/concepts/configuration/scheduler-perf-tuning.md
+++ b/content/en/docs/concepts/configuration/scheduler-perf-tuning.md
@@ -45,9 +45,11 @@ algorithmSource:
percentageOfNodesToScore: 50
```
-{{< note >}} **Note**: In clusters with zero or less than 50 feasible nodes, the
+{{< note >}}
+In clusters with zero or less than 50 feasible nodes, the
scheduler still checks all the nodes, simply because there are not enough
-feasible nodes to stop the scheduler's search early. {{< /note >}}
+feasible nodes to stop the scheduler's search early.
+{{< /note >}}
**To disable this feature**, you can set `percentageOfNodesToScore` to 100.
diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md
index b98137b871..cac58727d7 100644
--- a/content/en/docs/concepts/configuration/secret.md
+++ b/content/en/docs/concepts/configuration/secret.md
@@ -102,19 +102,24 @@ See [decoding a secret](#decoding-a-secret) for how to see the contents.
#### Creating a Secret Manually
-You can also create a secret object in a file first,
-in json or yaml format, and then create that object.
+You can also create a Secret in a file first, in json or yaml format,
+and then create that object. The
+[Secret](/docs/reference/generated/kubernetes-api/v1.12/#secret-v1-core) contains two maps:
+data and stringData. The data field is used to store arbitrary data, encoded using
+base64. The stringData field is provided for convenience, and allows you to provide
+secret data as unencoded strings.
-Each item must be base64 encoded:
+For example, to store two strings in a Secret using the data field, convert
+them to base64 as follows:
```shell
-$ echo -n 'admin' | base64
+echo -n 'admin' | base64
YWRtaW4=
-$ echo -n '1f2d1e2e67df' | base64
+echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm
```
-Now write a secret object that looks like this:
+Write a Secret that looks like this:
```yaml
apiVersion: v1
@@ -127,15 +132,108 @@ data:
password: MWYyZDFlMmU2N2Rm
```
-The data field is a map. Its keys must consist of alphanumeric characters, '-', '_' or '.'. The values are arbitrary data, encoded using base64.
-
-Create the secret using [`kubectl create`](/docs/reference/generated/kubectl/kubectl-commands#create):
+Now create the Secret using [`kubectl create`](/docs/reference/generated/kubectl/kubectl-commands#create):
```shell
$ kubectl create -f ./secret.yaml
secret "mysecret" created
```
+For certain scenarios, you may wish to use the stringData field instead. This
+field allows you to put a non-base64 encoded string directly into the Secret,
+and the string will be encoded for you when the Secret is created or updated.
+
+A practical example of this might be where you are deploying an application
+that uses a Secret to store a configuration file, and you want to populate
+parts of that configuration file during your deployment process.
+
+If your application uses the following configuration file:
+
+```yaml
+apiUrl: "https://my.api.com/api/v1"
+username: "user"
+password: "password"
+```
+
+You could store this in a Secret using the following:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+ name: mysecret
+type: Opaque
+stringData:
+ config.yaml: |-
+ apiUrl: "https://my.api.com/api/v1"
+ username: {{username}}
+ password: {{password}}
+```
+
+Your deployment tool could then replace the `{{username}}` and `{{password}}`
+template variables before running `kubectl create`.
+
+stringData is a write-only convenience field. It is never output when
+retrieving Secrets. For example, if you run the following command:
+
+```shell
+kubectl get secret mysecret -o yaml
+```
+
+The output will be similar to:
+
+```yaml
+apiVersion: v1
+data:
+ config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
+kind: Secret
+metadata:
+ creationTimestamp: 2018-11-15T20:40:59Z
+ name: mysecret
+ namespace: default
+ resourceVersion: "7225"
+ selfLink: /api/v1/namespaces/default/secrets/mysecret
+ uid: c280ad2e-e916-11e8-98f2-025000000001
+type: Opaque
+```
+
+If a field is specified in both data and stringData, the value from stringData
+is used. For example, the following Secret definition:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+ name: mysecret
+type: Opaque
+data:
+ username: YWRtaW4=
+stringData:
+ username: administrator
+```
+
+Results in the following secret:
+
+```yaml
+apiVersion: v1
+data:
+ username: YWRtaW5pc3RyYXRvcg==
+kind: Secret
+metadata:
+ creationTimestamp: 2018-11-15T20:46:46Z
+ name: mysecret
+ namespace: default
+ resourceVersion: "7579"
+ selfLink: /api/v1/namespaces/default/secrets/mysecret
+ uid: 91460ecb-e917-11e8-98f2-025000000001
+type: Opaque
+```
+
+Where `YWRtaW5pc3RyYXRvcg==` decodes to `administrator`.
+
+The keys of data and stringData must consist of alphanumeric characters,
+'-', '_' or '.'.
+
**Encoding Note:** The serialized JSON and YAML values of secret data are
encoded as base64 strings. Newlines are not valid within these strings and must
be omitted. When using the `base64` utility on Darwin/macOS users should avoid
@@ -344,7 +442,7 @@ When a secret being already consumed in a volume is updated, projected keys are
Kubelet is checking whether the mounted secret is fresh on every periodic sync.
However, it is using its local cache for getting the current value of the Secret.
The type of the cache is configurable using the (`ConfigMapAndSecretChangeDetectionStrategy` field in
-[KubeletConfiguration struct](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/pkg/kubelet/apis/kubeletconfig/v1beta1/types.go)).
+[KubeletConfiguration struct](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)).
It can be either propagated via watch (default), ttl-based, or simply redirecting
all requests to directly kube-apiserver.
As a result, the total delay from the moment when the Secret is updated to the moment
@@ -353,7 +451,7 @@ propagation delay, where cache propagation delay depends on the chosen cache typ
(it equals to watch propagation delay, ttl of cache, or zero corespondingly).
{{< note >}}
-**Note:** A container using a Secret as a
+A container using a Secret as a
[subPath](/docs/concepts/storage/volumes#using-subpath) volume mount will not receive
Secret updates.
{{< /note >}}
@@ -492,7 +590,7 @@ $ kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/
```
{{< caution >}}
-**Caution:** Think carefully before sending your own ssh keys: other users of the cluster may have access to the secret. Use a service account which you want to be accessible to all the users with whom you share the Kubernetes cluster, and can revoke if they are compromised.
+Think carefully before sending your own ssh keys: other users of the cluster may have access to the secret. Use a service account which you want to be accessible to all the users with whom you share the Kubernetes cluster, and can revoke if they are compromised.
{{< /caution >}}
@@ -544,7 +642,7 @@ $ kubectl create secret generic test-db-secret --from-literal=username=testuser
secret "test-db-secret" created
```
{{< note >}}
-**Note:** Special characters such as `$`, `\*`, and `!` require escaping.
+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:
kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password=S\\!B\\\*d\\$zDsb
@@ -665,7 +763,7 @@ the `dotfile-test-container` will have this file present at the path
`/etc/secret-volume/.secret-file`.
{{< note >}}
-**Note**: Files beginning with dot characters are hidden from the output of `ls -l`;
+Files beginning with dot characters are hidden from the output of `ls -l`;
you must use `ls -la` to see them when listing directory contents.
{{< /note >}}
@@ -774,7 +872,7 @@ Pod level](#use-case-secret-visible-to-one-container-in-a-pod).
single node.
{{< note >}}
-**Note:** As of 1.7 [encryption of secret data at rest is supported](/docs/tasks/administer-cluster/encrypt-data/).
+As of 1.7 [encryption of secret data at rest is supported](/docs/tasks/administer-cluster/encrypt-data/).
{{< /note >}}
{{% capture whatsnext %}}
diff --git a/content/en/docs/concepts/configuration/taint-and-toleration.md b/content/en/docs/concepts/configuration/taint-and-toleration.md
index bb41dca5f0..074cd82c02 100644
--- a/content/en/docs/concepts/configuration/taint-and-toleration.md
+++ b/content/en/docs/concepts/configuration/taint-and-toleration.md
@@ -69,7 +69,7 @@ A toleration "matches" a taint if the keys are the same and the effects are the
`Operator` defaults to `Equal` if not specified.
{{< note >}}
-**Note:** There are two special cases:
+There are two special cases:
* An empty `key` with operator `Exists` matches all keys, values and effects which means this
will tolerate everything.
@@ -230,7 +230,7 @@ added by the NodeController (or kubelet) and the normal logic for evicting pods
based on the Ready NodeCondition is disabled.
{{< note >}}
-**Note:** To maintain the existing [rate limiting](/docs/concepts/architecture/nodes/)
+To maintain the existing [rate limiting](/docs/concepts/architecture/nodes/)
behavior of pod evictions due to node problems, the system actually adds the taints
in a rate-limited way. This prevents massive pod evictions in scenarios such
as the master becoming partitioned from the nodes.
diff --git a/content/en/docs/concepts/containers/_index.md b/content/en/docs/concepts/containers/_index.md
index 5800f8a310..ad442f3ab3 100755
--- a/content/en/docs/concepts/containers/_index.md
+++ b/content/en/docs/concepts/containers/_index.md
@@ -1,5 +1,5 @@
---
title: "Containers"
-weight: 50
+weight: 40
---
diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md
index c35aad845b..ed590b50d3 100644
--- a/content/en/docs/concepts/containers/images.md
+++ b/content/en/docs/concepts/containers/images.md
@@ -44,7 +44,7 @@ https://cs.k8s.io/?q=docker%20manifest%20(create%7Cpush%7Cannotate)&i=nope&files
These commands rely on and are implemented purely on the Docker CLI. You will need to either edit the `$HOME/.docker/config.json` and set `experimental` key to `enabled` or you can just set `DOCKER_CLI_EXPERIMENTAL` environment variable to `enabled` when you call the CLI commands.
{{< note >}}
-**Note:** Please use Docker *18.06 or above*, versions below that either have bugs or do not support the experimental command line option. Example https://github.com/docker/cli/issues/1135 causes problems under containerd.
+Please use Docker *18.06 or above*, versions below that either have bugs or do not support the experimental command line option. Example https://github.com/docker/cli/issues/1135 causes problems under containerd.
{{< /note >}}
If you run into trouble with uploading stale manifests, just clean up the older manifests in `$HOME/.docker/manifests` to start fresh.
@@ -156,16 +156,16 @@ You can use the IBM Cloud Container Registry to deploy containers from [IBM Clou
### Configuring Nodes to Authenticate to a Private Registry
{{< note >}}
-**Note:** If you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach.
+If you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach.
{{< /note >}}
{{< note >}}
-**Note:** If you are running on AWS EC2 and are using the EC2 Container Registry (ECR), the kubelet on each node will
+If you are running on AWS EC2 and are using the EC2 Container Registry (ECR), the kubelet on each node will
manage and update the ECR login credentials. You cannot use this approach.
{{< /note >}}
{{< note >}}
-**Note:** This approach is suitable if you can control node configuration. It
+This approach is suitable if you can control node configuration. It
will not work reliably on GCE, and any other cloud provider that does automatic
node replacement.
{{< /note >}}
@@ -183,7 +183,7 @@ in the search paths list below, kubelet uses it as the credential provider when
* `/.dockercfg`
{{< note >}}
-**Note**: You may have to set `HOME=/root` explicitly in your environment file for kubelet.
+You may have to set `HOME=/root` explicitly in your environment file for kubelet.
{{< /note >}}
Here are the recommended steps to configuring your nodes to use a private registry. In this
@@ -240,11 +240,11 @@ registry keys are added to the `.docker/config.json`.
### Pre-pulling Images
{{< note >}}
-**Note:** If you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach.
+If you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach.
{{< /note >}}
{{< note >}}
-**Note:** This approach is suitable if you can control node configuration. It
+This approach is suitable if you can control node configuration. It
will not work reliably on GCE, and any other cloud provider that does automatic
node replacement.
{{< /note >}}
@@ -263,7 +263,7 @@ All pods will have read access to any pre-pulled images.
### Specifying ImagePullSecrets on a Pod
{{< note >}}
-**Note:** This approach is currently the recommended approach for Google Kubernetes Engine, GCE, and any cloud-providers
+This approach is currently the recommended approach for Google Kubernetes Engine, GCE, and any cloud-providers
where node creation is automated.
{{< /note >}}
diff --git a/content/en/docs/concepts/containers/runtime-class.md b/content/en/docs/concepts/containers/runtime-class.md
index e43468ee38..39d0d749f1 100644
--- a/content/en/docs/concepts/containers/runtime-class.md
+++ b/content/en/docs/concepts/containers/runtime-class.md
@@ -57,7 +57,7 @@ corresponding documentation for your CRI implementation for how to configure. As
feature, not all CRIs support multiple RuntimeClasses yet.
{{< note >}}
-**Note:** RuntimeClass currently assumes a homogeneous node configuration across the cluster
+RuntimeClass currently assumes a homogeneous node configuration across the cluster
(which means that all nodes are configured the same way with respect to container runtimes). Any heterogeneity (varying configurations) must be
managed independently of RuntimeClass through scheduling features
(see [Assigning Pods to Nodes](/docs/concepts/configuration/assign-pod-node/)).
@@ -87,11 +87,9 @@ spec:
{{< note >}}
-
-**Note:** It is recommended that RuntimeClass write operations (create/update/patch/delete) be
-restricted to the cluster administrator. This is typically the default.
-See [Authorization Overview](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) for more details.
-
+It is recommended that RuntimeClass write operations (create/update/patch/delete) be
+restricted to the cluster administrator. This is typically the default. See [Authorization
+Overview](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) for more details.
{{< /note >}}
### Usage
diff --git a/content/en/docs/concepts/example-concept-template.md b/content/en/docs/concepts/example-concept-template.md
index 6bbd6a080b..26ce263ef4 100644
--- a/content/en/docs/concepts/example-concept-template.md
+++ b/content/en/docs/concepts/example-concept-template.md
@@ -8,7 +8,9 @@ toc_hide: true
{{% capture overview %}}
-**NOTE:** Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document.
+{{< note >}}
+Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document.
+{{< /note >}}
This page explains ...
diff --git a/content/en/docs/concepts/extend-kubernetes/_index.md b/content/en/docs/concepts/extend-kubernetes/_index.md
index db04ba3e77..93d955441d 100644
--- a/content/en/docs/concepts/extend-kubernetes/_index.md
+++ b/content/en/docs/concepts/extend-kubernetes/_index.md
@@ -1,4 +1,4 @@
---
title: Extending Kubernetes
-weight: 40
+weight: 110
---
diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
index 64a7bc5416..0c1fe13a37 100644
--- a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+++ b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
@@ -91,7 +91,7 @@ Use a ConfigMap if any of the following apply:
* You want to perform rolling updates via Deployment, etc, when the file is updated.
{{< note >}}
-**Note:** Use a [secret](/docs/concepts/configuration/secret/) for sensitive data, which is similar to a configMap but more secure.
+Use a [secret](/docs/concepts/configuration/secret/) for sensitive data, which is similar to a configMap but more secure.
{{< /note >}}
Use a custom resource (CRD or Aggregated API) if most of the following apply:
@@ -108,11 +108,11 @@ Use a custom resource (CRD or Aggregated API) if most of the following apply:
Kubernetes provides two ways to add custom resources to your cluster:
- CRDs are simple and can be created without any programming.
-- [API Aggregation](/docs/concepts/api-extension/apiserver-aggregation/) requires programming, but allows more control over API behaviors like how data is stored and conversion between API versions.
+- [API Aggregation](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) requires programming, but allows more control over API behaviors like how data is stored and conversion between API versions.
-Kubernetes provides these two options to meet the needs of different users, so that neither ease of use nor flexibility are compromised.
+Kubernetes provides these two options to meet the needs of different users, so that neither ease of use nor flexibility is compromised.
-Aggregated APIs are subordinate APIServers that sit behind the primary API server, which acts as a proxy. This arrangement is called [API Aggregation](/docs/concepts/api-extension/apiserver-aggregation/) (AA). To users, it simply appears that the Kubernetes API is extended.
+Aggregated APIs are subordinate APIServers that sit behind the primary API server, which acts as a proxy. This arrangement is called [API Aggregation](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) (AA). To users, it simply appears that the Kubernetes API is extended.
CRDs allow users to create new types of resources without adding another APIserver. You do not need to understand API Aggregation to use CRDs.
@@ -131,14 +131,14 @@ for a demonstration of how to register a new custom resource, work with instance
and setup a controller to handle events.
{{< note >}}
-**Note:** CRD is the successor to the deprecated *ThirdPartyResource* (TPR) API, and is available as of Kubernetes 1.7.
+CRD is the successor to the deprecated *ThirdPartyResource* (TPR) API, and is available as of Kubernetes 1.7.
{{< /note >}}
## API server aggregation
Usually, each resource in the Kubernetes API requires code that handles REST requests and manages persistent storage of objects. The main Kubernetes API server handles built-in resources like *pods* and *services*, and can also handle custom resources in a generic way through [CRDs](#customresourcedefinitions).
-The [aggregation layer](/docs/concepts/api-extension/apiserver-aggregation/) allows you to provide specialized
+The [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) allows you to provide specialized
implementations for your custom resources by writing and deploying your own standalone API server.
The main API server delegates requests to you for the custom resources that you handle,
making them available to all of its clients.
@@ -171,13 +171,13 @@ Aggregated APIs offer more advanced API features and customization of other feat
| ------- | ----------- | ---- | -------------- |
| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes. Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation). Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks |
| Defaulting | See above | Yes, via a [Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook-beta-in-1-9); Planned, via CRD OpenAPI schema. | Yes |
-| Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | No, but planned | Yes |
+| Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | [Yes](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | Yes |
| Custom Storage | If you need storage with a different performance mode (for example, time-series database instead of key-value store) or isolation for security (for example, encryption secrets or different | No | Yes |
| Custom Business Logic | Perform arbitrary checks or actions when creating, reading, updating or deleting an object | Yes, using [Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks). | Yes |
| Scale Subresource | Allows systems like HorizontalPodAutoscaler and PodDisruptionBudget interact with your new resource | [Yes](https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource) | Yes |
| Status Subresource |
Finer-grained access control: user writes spec section, controller writes status section.
Allows incrementing object Generation on custom resource data mutation (requires separate spec and status sections in the resource)
| [Yes](https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | Yes |
| Other Subresources | Add operations other than CRUD, such as "logs" or "exec". | No | Yes |
-| strategic-merge-patch | The new endpoints support PATCH with `Content-Type: application/strategic-merge-patch+json`. Useful for updating objects that may be modified both locally, and by the server. For more information, see ["Update API Objects in Place Using kubectl patch"](/docs/tasks/run-application/update-api-object-kubectl-patch/) | No, but similar functionality planned | Yes |
+| strategic-merge-patch | The new endpoints support PATCH with `Content-Type: application/strategic-merge-patch+json`. Useful for updating objects that may be modified both locally, and by the server. For more information, see ["Update API Objects in Place Using kubectl patch"](/docs/tasks/run-application/update-api-object-kubectl-patch/) | No | Yes |
| Protocol Buffers | The new resource supports clients that want to use Protocol Buffers | No | Yes |
| OpenAPI Schema | Is there an OpenAPI (swagger) schema for the types that can be dynamically fetched from the server? Is the user protected from misspelling field names by ensuring only allowed fields are set? Are types enforced (in other words, don't put an `int` in a `string` field?) | No, but planned | Yes |
@@ -240,9 +240,9 @@ When you add a custom resource, you can access it using:
{{% /capture %}}
{{% capture whatsnext %}}
-* Learn how to [Extend the Kubernetes API with the aggregation layer](/docs/concepts/api-extension/apiserver-aggregation/).
-* Learn how to [Extend the Kubernetes API with CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/).
-* Learn how to [Migrate a ThirdPartyResource to CustomResourceDefinition](/docs/tasks/access-kubernetes-api/migrate-third-party-resource/).
+
+* Learn how to [Extend the Kubernetes API with the aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
+
+* Learn how to [Extend the Kubernetes API with CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/).
+
{{% /capture %}}
-
-
diff --git a/content/en/docs/concepts/extend-kubernetes/service-catalog.md b/content/en/docs/concepts/extend-kubernetes/service-catalog.md
index f1b0bbeb56..35d181d998 100644
--- a/content/en/docs/concepts/extend-kubernetes/service-catalog.md
+++ b/content/en/docs/concepts/extend-kubernetes/service-catalog.md
@@ -32,7 +32,7 @@ The application can simply use it as a service.
Service Catalog uses the [Open service broker API](https://github.com/openservicebrokerapi/servicebroker) to communicate with service brokers, acting as an intermediary for the Kubernetes API Server to negotiate the initial provisioning and retrieve the credentials necessary for the application to use a managed service.
-It is implemented as an extension API server and a controller, using etcd for storage. It also uses the [aggregation layer](/docs/concepts/api-extension/apiserver-aggregation/) available in Kubernetes 1.7+ to present its API.
+It is implemented as an extension API server and a controller, using etcd for storage. It also uses the [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) available in Kubernetes 1.7+ to present its API.
diff --git a/content/en/docs/concepts/overview/object-management-kubectl/declarative-config.md b/content/en/docs/concepts/overview/object-management-kubectl/declarative-config.md
index f0c63b64bd..48025a12e1 100644
--- a/content/en/docs/concepts/overview/object-management-kubectl/declarative-config.md
+++ b/content/en/docs/concepts/overview/object-management-kubectl/declarative-config.md
@@ -60,7 +60,7 @@ annotation on each object. The annotation contains the contents of the object
configuration file that was used to create the object.
{{< note >}}
-**Note:** Add the `-R` flag to recursively process directories.
+Add the `-R` flag to recursively process directories.
{{< /note >}}
Here's an example of an object configuration file:
@@ -134,7 +134,7 @@ kubectl apply -f /
```
{{< note >}}
-**Note:** Add the `-R` flag to recursively process directories.
+Add the `-R` flag to recursively process directories.
{{< /note >}}
Here's an example configuration file:
@@ -148,7 +148,7 @@ kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml
```
{{< note >}}
-**Note:** For purposes of illustration, the preceding command refers to a single
+For purposes of illustration, the preceding command refers to a single
configuration file instead of a directory.
{{< /note >}}
@@ -322,7 +322,7 @@ spec:
```
{{< warning >}}
-**Warning:** Mixing `kubectl apply` with the imperative object configuration commands
+Mixing `kubectl apply` with the imperative object configuration commands
`create` and `replace` is not supported. This is because `create`
and `replace` do not retain the `kubectl.kubernetes.io/last-applied-configuration`
that `kubectl apply` uses to compute updates.
@@ -347,12 +347,12 @@ kubectl delete -f
Only use this if you know what you are doing.
{{< warning >}}
-**Warning:** `kubectl apply --prune` is in alpha, and backwards incompatible
+`kubectl apply --prune` is in alpha, and backwards incompatible
changes might be introduced in subsequent releases.
{{< /warning >}}
{{< warning >}}
-**Warning:** You must be careful when using this command, so that you
+You must be careful when using this command, so that you
do not delete objects unintentionally.
{{< /warning >}}
@@ -373,7 +373,7 @@ kubectl apply -f --prune -l
```
{{< warning >}}
-**Warning:** Apply with prune should only be run against the root directory
+Apply with prune should only be run against the root directory
containing the object configuration files. Running against sub-directories
can cause objects to be unintentionally deleted if they are returned
by the label selector query specified with `-l ` and
@@ -391,10 +391,9 @@ kubectl get -f -o yaml
## How apply calculates differences and merges changes
{{< caution >}}
-**Caution:** A *patch* is an update operation that is scoped to specific
-fields of an object instead of the entire object.
-This enables updating only a specific set of fields on an object without
-reading the object first.
+A *patch* is an update operation that is scoped to specific fields of an object
+instead of the entire object. This enables updating only a specific set of fields
+on an object without reading the object first.
{{< /caution >}}
When `kubectl apply` updates the live configuration for an object,
@@ -546,7 +545,7 @@ and merged.
Primitive fields are replaced or cleared.
{{< note >}}
-**Note:** '-' is used for "not applicable" because the value is not used.
+`-` is used for "not applicable" because the value is not used.
{{< /note >}}
| Field in object configuration file | Field in live object configuration | Field in last-applied-configuration | Action |
@@ -561,7 +560,7 @@ Primitive fields are replaced or cleared.
Fields that represent maps are merged by comparing each of the subfields or elements of the map:
{{< note >}}
-**Note:** '-' is used for "not applicable" because the value is not used.
+`-` is used for "not applicable" because the value is not used.
{{< /note >}}
| Key in object configuration file | Key in live object configuration | Field in last-applied-configuration | Action |
@@ -689,7 +688,7 @@ by `name`.
As of Kubernetes 1.5, merging lists of primitive elements is not supported.
{{< note >}}
-**Note:** Which of the above strategies is chosen for a given field is controlled by
+Which of the above strategies is chosen for a given field is controlled by
the `patchStrategy` tag in [types.go](https://git.k8s.io/api/core/v1/types.go#L2565)
If no `patchStrategy` is specified for a field of type list, then
the list is replaced.
@@ -900,7 +899,7 @@ Kubernetes objects should be managed using only one method at a time.
Switching from one method to another is possible, but is a manual process.
{{< note >}}
-**Note:** It is OK to use imperative deletion with declarative management.
+It is OK to use imperative deletion with declarative management.
{{< /note >}}
{{< comment >}}
@@ -924,8 +923,10 @@ configuration involves several manual steps:
1. Manually remove the `status` field from the configuration file.
- {{< note >}}**Note:** This step is optional, as `kubectl apply` does not update the status field
- even if it is present in the configuration file.{{< /note >}}
+ {{< note >}}
+ This step is optional, as `kubectl apply` does not update the status field
+ even if it is present in the configuration file.
+ {{< /note >}}
1. Set the `kubectl.kubernetes.io/last-applied-configuration` annotation on the object:
@@ -952,7 +953,7 @@ TODO(pwittrock): Why doesn't export remove the status field? Seems like it shou
## Defining controller selectors and PodTemplate labels
{{< warning >}}
-**Warning:** Updating selectors on controllers is strongly discouraged.
+Updating selectors on controllers is strongly discouraged.
{{< /warning >}}
The recommended approach is to define a single, immutable PodTemplate label
diff --git a/content/en/docs/concepts/overview/object-management-kubectl/imperative-command.md b/content/en/docs/concepts/overview/object-management-kubectl/imperative-command.md
index 583bb03f52..38b194d2a4 100644
--- a/content/en/docs/concepts/overview/object-management-kubectl/imperative-command.md
+++ b/content/en/docs/concepts/overview/object-management-kubectl/imperative-command.md
@@ -76,8 +76,7 @@ Setting this aspect may set different fields for different object types:
- `set` : Set an aspect of an object.
{{< note >}}
-**Note**: In Kubernetes version 1.5, not every verb-driven command has an
-associated aspect-driven command.
+In Kubernetes version 1.5, not every verb-driven command has an associated aspect-driven command.
{{< /note >}}
The `kubectl` tool supports these additional ways to update a live object directly,
@@ -95,7 +94,7 @@ You can use the `delete` command to delete an object from a cluster:
- `delete /`
{{< note >}}
-**Note**: You can use `kubectl delete` for both imperative commands and imperative object
+You can use `kubectl delete` for both imperative commands and imperative object
configuration. The difference is in the arguments passed to the command. To use
`kubectl delete` as an imperative command, pass the object to be deleted as
an argument. Here's an example that passes a Deployment object named nginx:
@@ -137,7 +136,7 @@ kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run | k
```
1. The `kubectl create service -o yaml --dry-run` command creates the configuration for the Service, but prints it to stdout as YAML instead of sending it to the Kubernetes API server.
-1. The `kubectl set --local -f - -o yaml` command reads the configuration from stdin, and writes the updated configuration to stdout as YAML.
+1. The `kubectl set selector --local -f - -o yaml` command reads the configuration from stdin, and writes the updated configuration to stdout as YAML.
1. The `kubectl create -f -` command creates the object using the configuration provided via stdin.
## Using `--edit` to modify objects before creation
diff --git a/content/en/docs/concepts/overview/object-management-kubectl/imperative-config.md b/content/en/docs/concepts/overview/object-management-kubectl/imperative-config.md
index f0681fd9b6..45dca86b50 100644
--- a/content/en/docs/concepts/overview/object-management-kubectl/imperative-config.md
+++ b/content/en/docs/concepts/overview/object-management-kubectl/imperative-config.md
@@ -34,7 +34,7 @@ for details.
## How to update objects
{{< warning >}}
-**Warning:** Updating objects with the `replace` command drops all
+Updating objects with the `replace` command drops all
parts of the spec not specified in the configuration file. This
should not be used with objects whose specs are partially managed
by the cluster, such as Services of type `LoadBalancer`, where
@@ -115,7 +115,7 @@ kubectl replace -f _.yaml
## Defining controller selectors and PodTemplate labels
{{< warning >}}
-**Warning:** Updating selectors on controllers is strongly discouraged.
+Updating selectors on controllers is strongly discouraged.
{{< /warning >}}
The recommended approach is to define a single, immutable PodTemplate label
diff --git a/content/en/docs/concepts/overview/object-management-kubectl/overview.md b/content/en/docs/concepts/overview/object-management-kubectl/overview.md
index fe2baf4a5d..19c8a885f2 100644
--- a/content/en/docs/concepts/overview/object-management-kubectl/overview.md
+++ b/content/en/docs/concepts/overview/object-management-kubectl/overview.md
@@ -15,7 +15,7 @@ approaches.
## Management techniques
{{< warning >}}
-**Warning:** A Kubernetes object should be managed using only one technique. Mixing
+A Kubernetes object should be managed using only one technique. Mixing
and matching techniques for the same object results in undefined behavior.
{{< /warning >}}
@@ -74,7 +74,7 @@ See the [API reference](/docs/reference/generated/kubernetes-api/{{< param "vers
for more details on object definitions.
{{< warning >}}
-**Warning:** The imperative `replace` command replaces the existing
+The imperative `replace` command replaces the existing
spec with the newly provided one, dropping all changes to the object missing from
the configuration file. This approach should not be used with resource
types whose specs are updated independently of the configuration file.
@@ -135,7 +135,7 @@ are automatically detected per-object by `kubectl`. This enables working on
directories, where different operations might be needed for different objects.
{{< note >}}
-**Note:** Declarative object configuration retains changes made by other
+Declarative object configuration retains changes made by other
writers, even if the changes are not merged back to the object configuration file.
This is possible by using the `patch` API operation to write only
observed differences, instead of using the `replace`
diff --git a/content/en/docs/concepts/overview/what-is-kubernetes.md b/content/en/docs/concepts/overview/what-is-kubernetes.md
index f086ab21f5..014d4945c0 100644
--- a/content/en/docs/concepts/overview/what-is-kubernetes.md
+++ b/content/en/docs/concepts/overview/what-is-kubernetes.md
@@ -182,7 +182,7 @@ Summary of container benefits:
hardware to running an application on an OS using logical resources.
* **Loosely coupled, distributed, elastic, liberated [micro-services](https://martinfowler.com/articles/microservices.html)**:
Applications are broken into smaller, independent pieces and can
- be deployed and managed dynamically -- not a fat monolithic stack
+ be deployed and managed dynamically -- not a monolithic stack
running on one big single-purpose machine.
* **Resource isolation**:
Predictable application performance.
diff --git a/content/en/docs/concepts/overview/working-with-objects/common-labels.md b/content/en/docs/concepts/overview/working-with-objects/common-labels.md
index 314bbc7bb0..d0132d92b9 100644
--- a/content/en/docs/concepts/overview/working-with-objects/common-labels.md
+++ b/content/en/docs/concepts/overview/working-with-objects/common-labels.md
@@ -19,7 +19,7 @@ Instead, applications are informal and described with metadata. The definition o
what an application contains is loose.
{{< note >}}
-**Note:** These are recommended labels. They make it easier to manage applications
+These are recommended labels. They make it easier to manage applications
but aren't required for any core tooling.
{{< /note >}}
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 65b6430ed2..46535ab44e 100644
--- a/content/en/docs/concepts/overview/working-with-objects/labels.md
+++ b/content/en/docs/concepts/overview/working-with-objects/labels.md
@@ -66,7 +66,7 @@ An empty label selector (that is, one with zero requirements) selects every obje
A null label selector (which is only possible for optional selector fields) selects no objects.
{{< note >}}
-**Note**: the label selectors of two controllers must not overlap within a namespace, otherwise they will fight with each other.
+The label selectors of two controllers must not overlap within a namespace, otherwise they will fight with each other.
{{< /note >}}
### _Equality-based_ requirement
diff --git a/content/en/docs/concepts/policy/_index.md b/content/en/docs/concepts/policy/_index.md
index 4305fa559d..41d91de546 100755
--- a/content/en/docs/concepts/policy/_index.md
+++ b/content/en/docs/concepts/policy/_index.md
@@ -1,5 +1,5 @@
---
title: "Policies"
-weight: 160
+weight: 90
---
diff --git a/content/en/docs/concepts/policy/pod-security-policy.md b/content/en/docs/concepts/policy/pod-security-policy.md
index 89723642e3..2c320874a9 100644
--- a/content/en/docs/concepts/policy/pod-security-policy.md
+++ b/content/en/docs/concepts/policy/pod-security-policy.md
@@ -37,7 +37,7 @@ administrator to control the following:
| White list of Flexvolume drivers | [`allowedFlexVolumes`](#flexvolume-drivers) |
| Allocating an FSGroup that owns the pod's volumes | [`fsGroup`](#volumes-and-file-systems) |
| Requiring the use of a read only root file system | [`readOnlyRootFilesystem`](#volumes-and-file-systems) |
-| The user and group IDs of the container | [`runAsUser`, `supplementalGroups`](#users-and-groups) |
+| The user and group IDs of the container | [`runAsUser`, `runAsGroup`, `supplementalGroups`](#users-and-groups) |
| Restricting escalation to root privileges | [`allowPrivilegeEscalation`, `defaultAllowPrivilegeEscalation`](#privilege-escalation) |
| Linux capabilities | [`defaultAddCapabilities`, `requiredDropCapabilities`, `allowedCapabilities`](#capabilities) |
| The SELinux context of the container | [`seLinux`](#selinux) |
@@ -230,8 +230,8 @@ Create the rolebinding to grant `fake-user` the `use` verb on the example
policy:
{{< note >}}
-**Note:** _This is not the recommended way! See the [next section](#run-another-pod)
-for the preferred approach._
+This is not the recommended way! See the [next section](#run-another-pod)
+for the preferred approach.
{{< /note >}}
```shell
@@ -442,7 +442,7 @@ allowedHostPaths:
readOnly: true # only allow read-only mounts
```
-{{< warning >}}**Warning:** There are many ways a container with unrestricted access to the host
+{{< 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.
@@ -457,7 +457,7 @@ root filesystem (i.e. no writable layer).
### Flexvolume drivers
-This specifies a whiltelist of Flexvolume drivers that are allowed to be used
+This specifies a whitelist 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
`flexVolume` volume type; no Flexvolume driver is allowed otherwise.
diff --git a/content/en/docs/concepts/policy/resource-quotas.md b/content/en/docs/concepts/policy/resource-quotas.md
index d2469b9f9b..2d630b54cf 100644
--- a/content/en/docs/concepts/policy/resource-quotas.md
+++ b/content/en/docs/concepts/policy/resource-quotas.md
@@ -27,7 +27,7 @@ Resource quotas work like this:
- Different teams work in different namespaces. Currently this is voluntary, but
support for making this mandatory via ACLs is planned.
-- The administrator creates one or more `ResourceQuotas` for each namespace.
+- The administrator creates one `ResourceQuota` for each namespace.
- Users create resources (pods, services, etc.) in the namespace, and the quota system
tracks usage to ensure it does not exceed hard resource limits defined in a `ResourceQuota`.
- If creating or updating a resource violates a quota constraint, the request will fail with HTTP
@@ -202,7 +202,7 @@ field in the quota spec.
A quota is matched and consumed only if `scopeSelector` in the quota spec selects the pod.
{{< note >}}
-**Note:** You need to enable the feature gate `ResourceQuotaScopeSelectors`before using resource quotas
+You need to enable the feature gate `ResourceQuotaScopeSelectors`before using resource quotas
per PriorityClass.
{{< /note >}}
diff --git a/content/en/docs/concepts/services-networking/_index.md b/content/en/docs/concepts/services-networking/_index.md
index f4c379d88c..eea2c65b33 100755
--- a/content/en/docs/concepts/services-networking/_index.md
+++ b/content/en/docs/concepts/services-networking/_index.md
@@ -1,5 +1,5 @@
---
title: "Services, Load Balancing, and Networking"
-weight: 80
+weight: 60
---
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 c01eb8c68f..ae0160ad9f 100644
--- a/content/en/docs/concepts/services-networking/connect-applications-service.md
+++ b/content/en/docs/concepts/services-networking/connect-applications-service.md
@@ -122,7 +122,7 @@ about the [service proxy](/docs/concepts/services-networking/service/#virtual-ip
Kubernetes supports 2 primary modes of finding a Service - environment variables
and DNS. The former works out of the box while the latter requires the
-[kube-dns cluster addon](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/README.md).
+[CoreDNS cluster addon](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns).
### Environment Variables
@@ -178,7 +178,7 @@ kube-dns ClusterIP 10.0.0.10 53/UDP,53/TCP 8m
If it isn't running, you can [enable it](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/README.md#how-do-i-configure-it).
The rest of this section will assume you have a Service with a long lived IP
-(my-nginx), and a DNS server that has assigned a name to that IP (the kube-dns
+(my-nginx), and a DNS server that has assigned a name to that IP (the CoreDNS
cluster addon), so you can talk to the Service from any pod in your cluster using
standard methods (e.g. gethostbyname). Let's run another curl application to test this:
diff --git a/content/en/docs/concepts/services-networking/dns-pod-service.md b/content/en/docs/concepts/services-networking/dns-pod-service.md
index 96a62abd48..268519e833 100644
--- a/content/en/docs/concepts/services-networking/dns-pod-service.md
+++ b/content/en/docs/concepts/services-networking/dns-pod-service.md
@@ -149,7 +149,7 @@ The Endpoints object can specify the `hostname` for any endpoint addresses,
along with its IP.
{{< note >}}
-**Note:** Because A records are not created for Pod names, `hostname` is required for the Pod's A record to be created. A Pod with no `hostname` but with `subdomain` only will only create the A record for the headless service (`default-subdomain.my-namespace.svc.cluster.local`), pointing to the Pod's IP address.
+Because A records are not created for Pod names, `hostname` is required for the Pod's A record to be created. A Pod with no `hostname` but with `subdomain` only will only create the A record for the headless service (`default-subdomain.my-namespace.svc.cluster.local`), pointing to the Pod's IP address.
{{< /note >}}
### Pod's DNS Policy
@@ -176,7 +176,7 @@ following pod-specific DNS policies. These policies are specified in the
See [DNS config](#dns-config) subsection below.
{{< note >}}
-**NOTE:** "Default" is not the default DNS policy. If `dnsPolicy` is not
+"Default" is not the default DNS policy. If `dnsPolicy` is not
explicitly specified, then “ClusterFirst” is used.
{{< /note >}}
diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md
index b61141909c..8b5638939c 100644
--- a/content/en/docs/concepts/services-networking/ingress.md
+++ b/content/en/docs/concepts/services-networking/ingress.md
@@ -13,48 +13,95 @@ weight: 40
{{% capture body %}}
## Terminology
-Throughout this doc you will see a few terms that are sometimes used interchangeably elsewhere, that might cause confusion. This section attempts to clarify them.
+For the sake of clarity, this guide defines the following terms:
* Node: A single virtual or physical machine in a Kubernetes cluster.
* Cluster: A group of nodes firewalled from the internet, that are the primary compute resources managed by Kubernetes.
* Edge router: A router that enforces the firewall policy for your cluster. This could be a gateway managed by a cloud provider or a physical piece of hardware.
-* Cluster network: A set of links, logical or physical, that facilitate communication within a cluster according to the [Kubernetes networking model](/docs/concepts/cluster-administration/networking/). Examples of a Cluster network include Overlays such as [flannel](https://github.com/coreos/flannel#flannel) or SDNs such as [OVS](https://www.openvswitch.org/).
+* Cluster network: A set of links, logical or physical, that facilitate communication within a cluster according to the [Kubernetes networking model](/docs/concepts/cluster-administration/networking/).
* Service: A Kubernetes [Service](/docs/concepts/services-networking/service/) that identifies a set of pods using label selectors. Unless mentioned otherwise, Services are assumed to have virtual IPs only routable within the cluster network.
## What is Ingress?
-Typically, services and pods have IPs only routable by the cluster network. All traffic that ends up at an edge router is either dropped or forwarded elsewhere. Conceptually, this might look like:
+Ingress, added in Kubernetes v1.1, exposes HTTP and HTTPS routes from outside the cluster to
+{{< link text="services" url="/docs/concepts/services-networking/service/" >}} within the cluster.
+Traffic routing is controlled by rules defined on the ingress resource.
```none
internet
|
- ------------
- [ Services ]
-```
-
-An Ingress is a collection of rules that allow inbound connections to reach the cluster services.
-
-```
- internet
- |
[ Ingress ]
--|-----|--
[ Services ]
```
-It can be configured to give services externally-reachable URLs, load balance traffic, terminate SSL, offer name based virtual hosting, and more. Users request ingress by POSTing the Ingress resource to the API server. An [Ingress controller](#ingress-controllers) is responsible for fulfilling the Ingress, usually with a loadbalancer, though it may also configure your edge router or additional frontends to help handle the traffic in an HA manner.
+An ingress can be configured to give services externally-reachable URLs, load balance traffic, terminate SSL, and offer name based virtual hosting. An [ingress controller](#ingress-controllers) is responsible for fulfilling the ingress, usually with a loadbalancer, though it may also configure your edge router or additional frontends to help handle the traffic.
+
+An ingress does not expose arbitrary ports or protocols. Exposing services other than HTTP and HTTPS to the internet typically
+uses a service of type [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) or
+[Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer).
## Prerequisites
-Before you start using the Ingress resource, there are a few things you should understand. The Ingress is a beta resource, not available in any Kubernetes release prior to 1.1. You need an Ingress controller to satisfy an Ingress, simply creating the resource will have no effect.
+{{< feature-state for_k8s_version="v1.1" state="beta" >}}
-GCE/Google Kubernetes Engine deploys an ingress controller on the master. You can deploy any number of custom ingress controllers in a pod. You must annotate each ingress with the appropriate class, as indicated [here](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers) and [here](https://git.k8s.io/ingress-gce/examples/PREREQUISITES.md#ingress-class).
+Before you start using an ingress, there are a few things you should understand. The ingress is a beta resource. You will need an ingress controller to satisfy an ingress, simply creating the resource will have no effect.
-Make sure you review the [beta limitations](https://github.com/kubernetes/ingress-gce/blob/master/BETA_LIMITATIONS.md#glbc-beta-limitations) of this controller. In environments other than GCE/Google Kubernetes Engine, you need to [deploy a controller](https://git.k8s.io/ingress-nginx/README.md) as a pod.
+GCE/Google Kubernetes Engine deploys an [ingress controller](#ingress-controllers) on the master. Review the
+[beta limitations](https://github.com/kubernetes/ingress-gce/blob/master/BETA_LIMITATIONS.md#glbc-beta-limitations)
+of this controller if you are using GCE/GKE.
+
+In environments other than GCE/Google Kubernetes Engine, you may need to
+[deploy an ingress controller](https://kubernetes.github.io/ingress-nginx/deploy/). There are a number of
+[ingress controller](#ingress-controllers) you may choose from.
+
+## Ingress controllers
+
+In order for the ingress resource to work, the cluster must have an ingress controller running. This is unlike other types of controllers, which run as part of the `kube-controller-manager` binary, and are typically started automatically with a cluster. Choose the ingress controller implementation that best fits your cluster.
+
+* Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.io/ingress-gce/README.md) and
+ [nginx](https://git.k8s.io/ingress-nginx/README.md) controllers.
+
+Additional controllers include:
+
+* [Contour](https://github.com/heptio/contour) is an [Envoy](https://www.envoyproxy.io) based ingress controller
+ provided and supported by Heptio.
+* F5 Networks provides [support and maintenance](https://support.f5.com/csp/article/K86859508)
+ for the [F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest).
+* [HAProxy](http://www.haproxy.org/) based ingress controller
+ [jcmoraisjr/haproxy-ingress](https://github.com/jcmoraisjr/haproxy-ingress) which is mentioned on the blog post
+ [HAProxy Ingress Controller for Kubernetes](https://www.haproxy.com/blog/haproxy_ingress_controller_for_kubernetes/).
+ [HAProxy Technologies](https://www.haproxy.com/) offers support and maintenance for HAProxy Enterprise and
+ the ingress controller [jcmoraisjr/haproxy-ingress](https://github.com/jcmoraisjr/haproxy-ingress).
+* [Istio](https://istio.io/) based ingress controller
+ [Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/).
+* [Kong](https://konghq.com/) offers [community](https://discuss.konghq.com/c/kubernetes) or
+ [commercial](https://konghq.com/api-customer-success/) support and maintenance for the
+ [Kong Ingress Controllerfor Kubernetes](https://konghq.com/blog/kubernetes-ingress-controller-for-kong/).
+* [NGINX, Inc.](https://www.nginx.com/) offers support and maintenance for the
+ [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller).
+* [Traefik](https://github.com/containous/traefik) is a fully featured ingress controller
+ ([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket), and it also comes with commercial
+ support by [Containous](https://containo.us/services).
+
+You may deploy [any number of ingress controllers](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers) within a cluster.
+When you create an ingress, you should annotate each ingress with the appropriate
+[`ingress-class`](https://git.k8s.io/ingress-gce/examples/PREREQUISITES.md#ingress-class) to indicate which ingress
+controller should be used if more than one exists within your cluster.
+If you do not define a class, your cloud provider may use a default ingress provider.
+
+### Before you begin
+
+Ideally, all ingress controllers should fulfill this specification, but the various ingress
+controllers operate slightly differently.
+
+{{< note >}}
+Make sure you review your ingress controller's documentation to understand the caveats of choosing it.
+{{< /note >}}
## The Ingress Resource
-A minimal Ingress might look like:
+A minimal ingress resource example:
```yaml
apiVersion: extensions/v1beta1
@@ -73,50 +120,51 @@ spec:
servicePort: 80
```
-*POSTing this to the API server will have no effect if you have not configured an [Ingress controller](#ingress-controllers).*
+ As with all other Kubernetes resources, an ingress needs `apiVersion`, `kind`, and `metadata` fields.
+ For general information about working with config files, see [deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/), [configuring containers](/docs/tasks/configure-pod-container/configure-pod-configmap/), [managing resources](/docs/concepts/cluster-administration/manage-deployment/).
+ Ingress frequently uses annotations to configure some options depending on the ingress controller, an example of which
+ is the [rewrite-target annotation](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md).
+ Different [ingress controller](#ingress-controllers) support different annotations. Review the documentation for
+ your choice of ingress controller to learn which annotations are supported.
-__Lines 1-6__: As with all other Kubernetes config, an Ingress needs `apiVersion`, `kind`, and `metadata` fields. For general information about working with config files, see [deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/), [configuring containers](/docs/tasks/configure-pod-container/configure-pod-configmap/), [managing resources](/docs/concepts/cluster-administration/manage-deployment/) and [ingress configuration rewrite](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md).
+The ingress [spec](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status)
+has all the information needed to configure a loadbalancer or proxy server. Most importantly, it
+contains a list of rules matched against all incoming requests. Ingress resource only supports rules
+for directing HTTP traffic.
-__Lines 7-9__: Ingress [spec](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) has all the information needed to configure a loadbalancer or proxy server. Most importantly, it contains a list of rules matched against all incoming requests. Currently the Ingress resource only supports http rules.
+### Ingress rules
-__Lines 10-11__: Each http rule contains the following information: A host (e.g.: foo.bar.com, defaults to * in this example), a list of paths (e.g.: /testpath) each of which has an associated backend (test:80). Both the host and path must match the content of an incoming request before the loadbalancer directs traffic to the backend.
+Each http rule contains the following information:
-__Lines 12-14__: A backend is a service:port combination as described in the [services doc](/docs/concepts/services-networking/service/). Ingress traffic is typically sent directly to the endpoints matching a backend.
+* An optional host. In this example, no host is specified, so the rule applies to all inbound
+ HTTP traffic through the IP address is specified. If a host is provided (for example,
+ foo.bar.com), the rules apply to that host.
+* a list of paths (for example, /testpath), each of which has an associated backend defined with a `serviceName`
+ and `servicePort`. Both the host and path must match the content of an incoming request before the
+ loadbalancer will direct traffic to the referenced service.
+* A backend is a combination of service and port names as described in the
+ [services doc](/docs/concepts/services-networking/service/). HTTP (and HTTPS) requests to the
+ ingress matching the host and path of the rule will be sent to the listed backend.
-__Global Parameters__: For the sake of simplicity the example Ingress has no global parameters, see the [API reference](https://releases.k8s.io/{{< param "githubbranch" >}}/staging/src/k8s.io/api/extensions/v1beta1/types.go) for a full definition of the resource. One can specify a global default backend in the absence of which requests that don't match a path in the spec are sent to the default backend of the Ingress controller.
+A default backend is often configured in an ingress controller that will service any requests that do not
+match a path in the spec.
-## Ingress controllers
+### Default Backend
-In order for the Ingress resource to work, the cluster must have an Ingress controller running. This is unlike other types of controllers, which typically run as part of the `kube-controller-manager` binary, and which are typically started automatically as part of cluster creation. Choose the ingress controller implementation that best fits your cluster, or implement a new ingress controller.
+An ingress with no rules sends all traffic to a single default backend. The default
+backend is typically a configuration option of the [ingress controller](#ingress-controllers)
+and is not specified in your ingress resources.
-* Kubernetes currently supports and maintains [GCE](https://git.k8s.io/ingress-gce/README.md) and [nginx](https://git.k8s.io/ingress-nginx/README.md) controllers.
-* F5 Networks provides [support and maintenance](https://support.f5.com/csp/article/K86859508) for the [F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest).
-* [Kong](https://konghq.com/) offers [community](https://discuss.konghq.com/c/kubernetes) or [commercial](https://konghq.com/api-customer-success/) support and maintenance for the [Kong Ingress Controller for Kubernetes](https://konghq.com/blog/kubernetes-ingress-controller-for-kong/)
-* [Traefik](https://github.com/containous/traefik) is a fully featured ingress controller
-([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket...), and it also comes with commercial support by [Containous](https://containo.us/services)
-* [NGINX, Inc.](https://www.nginx.com/) offers support and maintenance for the [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)
-* [HAProxy](http://www.haproxy.org/) based ingress controller [jcmoraisjr/haproxy-ingress](https://github.com/jcmoraisjr/haproxy-ingress) which is mentioned on this blog post [HAProxy Ingress Controller for Kubernetes](https://www.haproxy.com/blog/haproxy_ingress_controller_for_kubernetes/)
-* [Istio](https://istio.io/) based ingress controller [Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/)
-
-{{< note >}}
-**Note:** Review the documentation for your controller to find its specific support policy.
-{{< /note >}}
-
-## Before you begin
-
-The following document describes a set of cross-platform features exposed through the Ingress resource. Ideally, all Ingress controllers should fulfill this specification, but we're not there yet. We currently support and maintain [GCE](https://git.k8s.io/ingress-gce/README.md) and [nginx](https://git.k8s.io/ingress-nginx/README.md) controllers. If you use the F5 BIG-IP Controller, see [Use the BIG-IP Controller as a Kubernetes Ingress Controller](http://clouddocs.f5.com/containers/latest/kubernetes/kctlr-k8s-ingress-ctlr.html).
-
-{{< note >}}
-**Note:** Make sure you review your controller's specific docs so you understand the caveats.
-{{< /note >}}
+If none of the hosts or paths match the HTTP request in the ingress objects, the traffic is
+routed to your default backend.
## Types of Ingress
### Single Service Ingress
There are existing Kubernetes concepts that allow you to expose a single Service
-(see [alternatives](#alternatives)), however you can do so through an Ingress
-as well, by specifying a *default backend* with no rules.
+(see [alternatives](#alternatives)). You can also do this with an ingress by specifying a
+*default backend* with no rules.
{{< codenew file="service/networking/ingress.yaml" >}}
@@ -131,29 +179,32 @@ NAME HOSTS ADDRESS PORTS AGE
test-ingress * 107.178.254.228 80 59s
```
-Where `107.178.254.228` is the IP allocated by the Ingress controller to satisfy
-this Ingress.
+Where `107.178.254.228` is the IP allocated by the ingress controller to satisfy
+this ingress.
+
+{{< note >}}
+Ingress controllers and load balancers may take a minute or two to allocate an IP address.
+Until that time you will often see the address listed as ``.
+{{< /note >}}
### Simple fanout
-As described previously, Pods within kubernetes have IPs only visible on the
-cluster network, so we need something at the edge accepting ingress traffic and
-proxying it to the right endpoints. This component is usually a highly available
-loadbalancer. An Ingress allows you to keep the number of loadbalancers down
-to a minimum. For example, a setup like:
+A fanout configuration routes traffic from a single IP address to more than one service,
+based on the HTTP URI being requested. An ingress allows you to keep the number of loadbalancers
+down to a minimum. For example, a setup like:
```shell
-foo.bar.com -> 178.91.123.132 -> / foo s1:80
- / bar s2:80
+foo.bar.com -> 178.91.123.132 -> / foo service1:4200
+ / bar service2:8080
```
-would require an Ingress such as:
+would require an ingress such as:
```yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
- name: test
+ name: simple-fanout-example
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
@@ -163,22 +214,22 @@ spec:
paths:
- path: /foo
backend:
- serviceName: s1
- servicePort: 80
+ serviceName: service1
+ servicePort: 4200
- path: /bar
backend:
- serviceName: s2
- servicePort: 80
+ serviceName: service2
+ servicePort: 8080
```
-When you create the Ingress with `kubectl create -f`:
+When you create the ingress with `kubectl create -f`:
```shell
-kubectl describe ingress test
+kubectl describe ingress simple-fanout-example
```
```shell
-Name: test
+Name: simple-fanout-example
Namespace: default
Address: 178.91.123.132
Default backend: default-http-backend:80 (10.8.2.3:8080)
@@ -186,8 +237,8 @@ Rules:
Host Path Backends
---- ---- --------
foo.bar.com
- /foo s1:80 (10.8.0.90:80)
- /bar s2:80 (10.8.0.91:80)
+ /foo service1:4200 (10.8.0.90:4200)
+ /bar service2:8080 (10.8.0.91:8080)
Annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
Events:
@@ -196,18 +247,19 @@ Events:
Normal ADD 22s loadbalancer-controller default/test
```
-The Ingress controller will provision an implementation specific loadbalancer
-that satisfies the Ingress, as long as the services (`s1`, `s2`) exist.
+The ingress controller will provision an implementation specific loadbalancer
+that satisfies the ingress, as long as the services (`s1`, `s2`) exist.
When it has done so, you will see the address of the loadbalancer at the
Address field.
{{< note >}}
-**Note:** You need to create a default-http-backend [Service](/docs/concepts/services-networking/service/) if necessary.
+Depending on the [ingress controller](#ingress-controllers) you are using, you may need to
+create a default-http-backend [Service](/docs/concepts/services-networking/service/).
{{< /note >}}
### Name based virtual hosting
-Name-based virtual hosts use multiple host names for the same IP address.
+Name-based virtual hosts support routing HTTP traffic to multiple host names at the same IP address.
```none
foo.bar.com --| |-> foo.bar.com s1:80
@@ -215,45 +267,71 @@ foo.bar.com --| |-> foo.bar.com s1:80
bar.foo.com --| |-> bar.foo.com s2:80
```
-The following Ingress tells the backing loadbalancer to route requests based on
+The following ingress tells the backing loadbalancer to route requests based on
the [Host header](https://tools.ietf.org/html/rfc7230#section-5.4).
```yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
- name: test
+ name: name-virtual-host-ingress
spec:
rules:
- host: foo.bar.com
http:
paths:
- backend:
- serviceName: s1
+ serviceName: service1
servicePort: 80
- host: bar.foo.com
http:
paths:
- backend:
- serviceName: s2
+ serviceName: service2
servicePort: 80
```
-__Default Backends__: An Ingress with no rules, like the one shown in the previous
-section, sends all traffic to a single default backend. You can use the same
-technique to tell a loadbalancer where to find your website's 404 page, by
-specifying a set of rules *and* a default backend. Traffic is routed to your
-default backend if none of the Hosts in your Ingress match the Host in the
-request header, and/or none of the paths match the URL of the request.
+If you create an ingress resource without any hosts defined in the rules, then any
+web traffic to the IP address of your ingress controller can be matched without a name based
+virtual host being required. For example, the following ingress resource will route traffic
+requested for `first.bar.com` to `service1`, `second.bar.com` to `service2`, and any traffic
+to the IP address without a hostname defined in request (that is, without a request header being
+presented) to `service3`.
+
+```yaml
+apiVersion: extensions/v1beta1
+kind: Ingress
+metadata:
+ name: name-virtual-host-ingress
+spec:
+ rules:
+ - host: first.bar.com
+ http:
+ paths:
+ - backend:
+ serviceName: service1
+ servicePort: 80
+ - host: second.foo.com
+ http:
+ paths:
+ - backend:
+ serviceName: service2
+ servicePort: 80
+ - http:
+ paths:
+ - backend:
+ serviceName: service3
+ servicePort: 80
+```
### TLS
-You can secure an Ingress by specifying a [secret](/docs/concepts/configuration/secret)
-that contains a TLS private key and certificate. Currently the Ingress only
+You can secure an ingress by specifying a [secret](/docs/concepts/configuration/secret)
+that contains a TLS private key and certificate. Currently the ingress only
supports a single TLS port, 443, and assumes TLS termination. If the TLS
-configuration section in an Ingress specifies different hosts, they will be
+configuration section in an ingress specifies different hosts, they will be
multiplexed on the same port according to the hostname specified through the
-SNI TLS extension (provided the Ingress controller supports SNI). The TLS secret
+SNI TLS extension (provided the ingress controller supports SNI). The TLS secret
must contain keys named `tls.crt` and `tls.key` that contain the certificate
and private key to use for TLS, e.g.:
@@ -264,46 +342,55 @@ data:
tls.key: base64 encoded key
kind: Secret
metadata:
- name: testsecret
+ name: testsecret-tls
namespace: default
type: Opaque
```
-Referencing this secret in an Ingress will tell the Ingress controller to
-secure the channel from the client to the loadbalancer using TLS:
+Referencing this secret in an ingress will tell the ingress controller to
+secure the channel from the client to the loadbalancer using TLS. You need to make
+sure the TLS secret you created came from a certificate that contains a CN
+for `sslexample.foo.com`.
```yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
- name: no-rules-map
+ name: tls-example-ingress
spec:
tls:
- - secretName: testsecret
- backend:
- serviceName: s1
- servicePort: 80
+ - hosts:
+ - sslexample.foo.com
+ secretName: testsecret-tls
+ rules:
+ - host: sslexample.foo.com
+ http:
+ paths:
+ - path: /
+ backend:
+ serviceName: service1
+ servicePort: 80
```
-Note that there is a gap between TLS features supported by various Ingress
+{{< note >}}
+There is a gap between TLS features supported by various ingress
controllers. Please refer to documentation on
[nginx](https://git.k8s.io/ingress-nginx/README.md#https),
[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https), or any other
-platform specific Ingress controller to understand how TLS works in your environment.
+platform specific ingress controller to understand how TLS works in your environment.
+{{< /note >}}
### Loadbalancing
-An Ingress controller is bootstrapped with some load balancing policy settings
-that it applies to all Ingress, such as the load balancing algorithm, backend
+An ingress controller is bootstrapped with some load balancing policy settings
+that it applies to all ingress, such as the load balancing algorithm, backend
weight scheme, and others. More advanced load balancing concepts
(e.g. persistent sessions, dynamic weights) are not yet exposed through the
-Ingress. You can still get these features through the
+ingress. You can still get these features through the
[service loadbalancer](https://github.com/kubernetes/ingress-nginx).
- With time, we plan to distill load balancing patterns that are applicable
-cross platform into the Ingress resource.
It's also worth noting that even though health checks are not exposed directly
-through the Ingress, there exist parallel concepts in Kubernetes such as
+through the ingress, there exist parallel concepts in Kubernetes such as
[readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)
which allow you to achieve the same end result. Please review the controller
specific docs to see how they handle health checks (
@@ -312,7 +399,7 @@ specific docs to see how they handle health checks (
## Updating an Ingress
-Say you'd like to add a new Host to an existing Ingress, you can update it by editing the resource:
+To update an existing ingress to add a new Host, you can update it by editing the resource:
```shell
kubectl describe ingress test
@@ -362,7 +449,8 @@ spec:
..
```
-Saving the yaml will update the resource in the API server, which should tell the Ingress controller to reconfigure the loadbalancer.
+Saving the yaml will update the resource in the API server, which should tell the
+ingress controller to reconfigure the loadbalancer.
```shell
kubectl describe ingress test
@@ -388,28 +476,30 @@ Events:
Normal ADD 45s loadbalancer-controller default/test
```
-You can achieve the same by invoking `kubectl replace -f` on a modified Ingress yaml file.
+You can achieve the same by invoking `kubectl replace -f` on a modified ingress yaml file.
## Failing across availability zones
-Techniques for spreading traffic across failure domains differs between cloud providers. Please check the documentation of the relevant Ingress controller for details. Please refer to the federation [doc](/docs/concepts/cluster-administration/federation/) for details on deploying Ingress in a federated cluster.
+Techniques for spreading traffic across failure domains differs between cloud providers.
+Please check the documentation of the relevant [ingress controller](#ingress-controllers) for
+details. You can also refer to the [federation documentation](/docs/concepts/cluster-administration/federation/)
+for details on deploying ingress in a federated cluster.
## Future Work
-* Various modes of HTTPS/TLS support (e.g.: SNI, re-encryption)
-* Requesting an IP or Hostname via claims
-* Combining L4 and L7 Ingress
-* More Ingress controllers
-
-Please track the [L7 and Ingress proposal](https://github.com/kubernetes/kubernetes/pull/12827) for more details on the evolution of the resource, and the [Ingress repository](https://github.com/kubernetes/ingress/tree/master) for more details on the evolution of various Ingress controllers.
+Track [SIG Network](https://github.com/kubernetes/community/tree/master/sig-network)
+for more details on the evolution of the ingress and related resources. You may also track the
+[ingress repository](https://github.com/kubernetes/ingress/tree/master) for more details on the
+evolution of various ingress controllers.
## Alternatives
-You can expose a Service in multiple ways that don't directly involve the Ingress resource:
+You can expose a Service in multiple ways that don't directly involve the ingress resource:
* Use [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)
* Use [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)
* Use a [Port Proxy](https://git.k8s.io/contrib/for-demos/proxy-to-service)
+
{{% /capture %}}
{{% capture whatsnext %}}
diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md
index 9fc2bb79b4..37cc723539 100644
--- a/content/en/docs/concepts/services-networking/service.md
+++ b/content/en/docs/concepts/services-networking/service.md
@@ -16,7 +16,7 @@ weight: 10
Kubernetes [`Pods`](/docs/concepts/workloads/pods/pod/) are mortal. They are born and when they die, they
are not resurrected. [`ReplicaSets`](/docs/concepts/workloads/controllers/replicaset/) in
-particular create and destroy `Pods` dynamically (e.g. when scaling up or down). While each `Pod` gets its own IP address, even
+particular create and destroy `Pods` dynamically (e.g. when scaling out or in). While each `Pod` gets its own IP address, even
those IP addresses cannot be relied upon to be stable over time. This leads to
a problem: if some set of `Pods` (let's call them backends) provides
functionality to other `Pods` (let's call them frontends) inside the Kubernetes
@@ -87,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
+SCTP support is an alpha feature since Kubernetes 1.12
{{< /note >}}
### Services without selectors
@@ -132,7 +132,7 @@ subsets:
```
{{< note >}}
-**Note:** The endpoint IPs may not be loopback (127.0.0.0/8), link-local
+The endpoint IPs may not be loopback (127.0.0.0/8), link-local
(169.254.0.0/16), or link-local multicast (224.0.0.0/24). They cannot be the
cluster IPs of other Kubernetes services either because the `kube-proxy`
component doesn't support virtual IPs as destination yet.
@@ -212,10 +212,12 @@ options for load balancing algorithm, such as:
- `sed`: shortest expected delay
- `nq`: never queue
-**Note:** ipvs mode assumes IPVS kernel modules are installed on the node
+{{< note >}}
+ipvs mode assumes IPVS kernel modules are installed on the node
before running kube-proxy. When kube-proxy starts with ipvs proxy mode,
kube-proxy would validate if IPVS modules are installed on the node, if
it's not installed kube-proxy will fall back to iptables proxy mode.
+{{< /note >}}

@@ -322,8 +324,8 @@ DNS server watches the Kubernetes API for new `Services` and creates a set of
DNS records for each. If DNS has been enabled throughout the cluster then all
`Pods` should be able to do name resolution of `Services` automatically.
-For example, if you have a `Service` called `"my-service"` in Kubernetes
-`Namespace` `"my-ns"` a DNS record for `"my-service.my-ns"` is created. `Pods`
+For example, if you have a `Service` called `"my-service"` in a Kubernetes
+`Namespace` called `"my-ns"`, a DNS record for `"my-service.my-ns"` is created. `Pods`
which exist in the `"my-ns"` `Namespace` should be able to find it by simply doing
a name lookup for `"my-service"`. `Pods` which exist in other `Namespaces` must
qualify the name as `"my-service.my-ns"`. The result of these name lookups is the
@@ -459,7 +461,7 @@ public IP address resource needs to be created first, and it should be in the sa
group of the other automatically created resources of the cluster. For example, `MC_myResourceGroup_myAKSCluster_eastus`. Specify the assigned IP address as loadBalancerIP. Ensure that you have updated the securityGroupName in the cloud provider configuration file. For information about troubleshooting `CreatingLoadBalancerFailed` permission issues see, [Use a static IP address with the Azure Kubernetes Service (AKS) load balancer](https://docs.microsoft.com/en-us/azure/aks/static-ip) or [CreatingLoadBalancerFailed on AKS cluster with advanced networking](https://github.com/Azure/AKS/issues/357).
{{< note >}}
-**Note:** The support of SCTP in the cloud provider's load balancer is up to the cloud provider's
+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
Service creation request is accepted but the creation of the load balancer fails.
{{< /note >}}
@@ -693,7 +695,9 @@ There are other annotations to manage Classic Elastic Load Balancers that are de
#### Network Load Balancer support on AWS [alpha]
-**Warning:** This is an alpha feature and not recommended for production clusters yet.
+{{< warning >}}
+This is an alpha feature and not recommended for production clusters yet.
+{{< /warning >}}
Starting in version 1.9.0, Kubernetes supports Network Load Balancer (NLB). To
use a Network Load Balancer on AWS, use the annotation `service.beta.kubernetes.io/aws-load-balancer-type`
@@ -747,13 +751,15 @@ spec:
- "143.231.0.0/16"
```
-**Note:** NLB only works with certain instance classes, see the [AWS documentation](http://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets)
+{{< note >}}
+NLB only works with certain instance classes, see the [AWS documentation](http://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets)
for supported instance types.
+{{< /note >}}
### Type ExternalName {#externalname}
{{< note >}}
-**NOTE:** ExternalName Services are available only with `kube-dns` version 1.7 and later.
+ExternalName Services are available only with `kube-dns` version 1.7 and later.
{{< /note >}}
Services of type ExternalName map a service to a DNS name (specified using
@@ -772,7 +778,7 @@ spec:
externalName: my.database.example.com
```
-When looking up the host `my-service.prod.svc.CLUSTER`, the cluster DNS service
+When looking up the host `my-service.prod.svc.cluster.local`, the cluster DNS service
will return a `CNAME` record with the value `my.database.example.com`. Accessing
`my-service` works in the same way as other Services but with the crucial
difference that redirection happens at the DNS level rather than via proxying or
diff --git a/content/en/docs/concepts/storage/_index.md b/content/en/docs/concepts/storage/_index.md
index 8d38e78dd6..7e0dd19b12 100755
--- a/content/en/docs/concepts/storage/_index.md
+++ b/content/en/docs/concepts/storage/_index.md
@@ -1,5 +1,5 @@
---
title: "Storage"
-weight: 90
+weight: 70
---
diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md
index 28fc8b4f1a..995881711b 100644
--- a/content/en/docs/concepts/storage/persistent-volumes.md
+++ b/content/en/docs/concepts/storage/persistent-volumes.md
@@ -85,7 +85,7 @@ Once a user has a claim and that claim is bound, the bound PV belongs to the use
The purpose of the Storage Object in Use Protection feature is to ensure that Persistent Volume Claims (PVCs) in active use by a pod and Persistent Volume (PVs) that are bound to PVCs are not removed from the system as this may result in data loss.
{{< note >}}
-**Note:** PVC is in active use by a pod when the pod status is `Pending` and the pod is assigned to a node or the pod status is `Running`.
+PVC is in active use by a pod when the pod status is `Pending` and the pod is assigned to a node or the pod status is `Running`.
{{< /note >}}
When the [Storage Object in Use Protection feature](/docs/tasks/administer-cluster/storage-object-in-use-protection/) is enabled, if a user deletes a PVC in active use by a pod, the PVC is not removed immediately. PVC removal is postponed until the PVC is no longer actively used by any pods, and also if admin deletes a PV that is bound to a PVC, the PV is not removed immediately. PV removal is postponed until the PV is not bound to a PVC any more.
@@ -147,7 +147,7 @@ For volume plugins that support the `Delete` reclaim policy, deletion removes bo
#### Recycle
{{< warning >}}
-**Warning:** The `Recycle` reclaim policy is deprecated. Instead, the recommended approach is to use dynamic provisioning.
+The `Recycle` reclaim policy is deprecated. Instead, the recommended approach is to use dynamic provisioning.
{{< /warning >}}
If supported by the underlying volume plugin, the `Recycle` reclaim policy performs a basic scrub (`rm -rf /thevolume/*`) on the volume and makes it available again for a new claim.
@@ -238,7 +238,7 @@ This feature has no effect on PVCs that are not in use by a Pod or deployment. Y
uses the PVC before the expansion can complete.
{{< note >}}
-**Note:** Expanding EBS volumes is a time consuming operation. Also, there is a per-volume quota of one modification every 6 hours.
+Expanding EBS volumes is a time consuming operation. Also, there is a per-volume quota of one modification every 6 hours.
{{< /note >}}
@@ -335,7 +335,7 @@ In the CLI, the access modes are abbreviated to:
| CephFS | ✓ | ✓ | ✓ |
| Cinder | ✓ | - | - |
| FC | ✓ | ✓ | - |
-| Flexvolume | ✓ | ✓ | - |
+| Flexvolume | ✓ | ✓ | depends on the driver |
| Flocker | ✓ | - | - |
| GCEPersistentDisk | ✓ | ✓ | - |
| Glusterfs | ✓ | ✓ | ✓ |
@@ -377,7 +377,7 @@ Currently, only NFS and HostPath support recycling. AWS EBS, GCE PD, Azure Disk,
A Kubernetes administrator can specify additional mount options for when a Persistent Volume is mounted on a node.
{{< note >}}
-**Note:** Not all Persistent volume types support mount options.
+Not all Persistent volume types support mount options.
{{< /note >}}
The following volume types support mount options:
@@ -402,6 +402,14 @@ In the past, the annotation `volume.beta.kubernetes.io/mount-options` was used i
of the `mountOptions` attribute. This annotation is still working, however
it will become fully deprecated in a future Kubernetes release.
+### Node Affinity
+
+{{< note >}}
+For most volume types, you do not need to set this field. It is automatically populated for [AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk) and [Azure Disk](/docs/concepts/storage/volumes/#azuredisk) volume block types. You need to explicitly set this for [local](/docs/concepts/storage/volumes/#local) volumes.
+{{< /note >}}
+
+A PV can specify [node affinity](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core) to define constraints that limit what nodes this volume can be accessed from. Pods that use a PV will only be scheduled to nodes that are selected by the node affinity.
+
### Phase
A volume will be in one of the following phases:
@@ -495,7 +503,7 @@ the requirements are ANDed together: only a PV of the requested class and with
the requested labels may be bound to the PVC.
{{< note >}}
-**Note:** Currently, a PVC with a non-empty `selector` can't have a PV dynamically provisioned for it.
+Currently, a PVC with a non-empty `selector` can't have a PV dynamically provisioned for it.
{{< /note >}}
In the past, the annotation `volume.beta.kubernetes.io/storage-class` was used instead
@@ -547,7 +555,7 @@ applicable.
* RBD (Ceph Block Device)
{{< note >}}
-**Note**: Only FC and iSCSI volumes supported raw block volumes in Kubernetes 1.9.
+Only FC and iSCSI volumes supported raw block volumes in Kubernetes 1.9.
Support for the additional plugins was added in 1.10.
{{< /note >}}
@@ -605,7 +613,7 @@ spec:
```
{{< note >}}
-**Note:** When adding a raw block device for a Pod, we specify the device path in the container instead of a mount path.
+When adding a raw block device for a Pod, we specify the device path in the container instead of a mount path.
{{< /note >}}
### Binding Block Volumes
@@ -627,7 +635,7 @@ Volume binding matrix for statically provisioned volumes:
| Filesystem | unspecified | BIND |
{{< note >}}
-**Note:** Only statically provisioned volumes are supported for alpha release. Administrators should take care to consider these values when working with raw block devices.
+Only statically provisioned volumes are supported for alpha release. Administrators should take care to consider these values when working with raw block devices.
{{< /note >}}
## Volume Snapshot and Restore Volume from Snapshot Support
diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md
index 0cd7d0afbc..3aba1eee67 100644
--- a/content/en/docs/concepts/storage/storage-classes.md
+++ b/content/en/docs/concepts/storage/storage-classes.md
@@ -123,8 +123,10 @@ the class or PV, so mount of the PV will simply fail if one is invalid.
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
-**Note:** This feature requires the `VolumeScheduling` feature gate to be
+{{< note >}}
+This feature requires the `VolumeScheduling` feature gate to be
enabled.
+{{< /note >}}
The `volumeBindingMode` field controls when [volume binding and dynamic
provisioning](/docs/concepts/storage/persistent-volumes/#provisioning) should occur.
@@ -159,8 +161,10 @@ The following plugins support `WaitForFirstConsumer` with pre-created Persistent
### Allowed Topologies
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
-**Note:** This feature requires the `VolumeScheduling` feature gate to be
+{{< note >}}
+This feature requires the `VolumeScheduling` feature gate to be
enabled.
+{{< /note >}}
When a cluster operactor specifies the `WaitForFirstConsumer` volume binding mode, it is no longer necessary
to restrict provisioning to specific topologies in most situations. However,
@@ -232,8 +236,10 @@ parameters:
encrypting the volume. If none is supplied but `encrypted` is true, a key is
generated by AWS. See AWS docs for valid ARN value.
-**Note:** `zone` and `zones` parameters are deprecated and replaced with
+{{< note >}}
+`zone` and `zones` parameters are deprecated and replaced with
[allowedTopologies](#allowed-topologies)
+{{< /note >}}
### GCE PD
@@ -269,8 +275,10 @@ specified, Kubernetes will arbitrarily choose among the specified zones. If the
`zones` parameter is omitted, Kubernetes will arbitrarily choose among zones
managed by the cluster.
-**Note:** `zone` and `zones` parameters are deprecated and replaced with
+{{< note >}}
+`zone` and `zones` parameters are deprecated and replaced with
[allowedTopologies](#allowed-topologies)
+{{< /note >}}
### Glusterfs
diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md
index 5f16c2b464..3820394deb 100644
--- a/content/en/docs/concepts/storage/volumes.md
+++ b/content/en/docs/concepts/storage/volumes.md
@@ -105,7 +105,7 @@ EBS volume can be pre-populated with data, and that data can be "handed off"
between Pods.
{{< caution >}}
-**Important:** You must create an EBS volume using `aws ec2 create-volume` or the AWS API before you can use it.
+You must create an EBS volume using `aws ec2 create-volume` or the AWS API before you can use it.
{{< /caution >}}
There are some restrictions when using an `awsElasticBlockStore` volume:
@@ -170,7 +170,7 @@ that data can be "handed off" between Pods. CephFS can be mounted by multiple
writers simultaneously.
{{< caution >}}
-**Important:** You must have your own Ceph server running with the share exported before you can use it.
+You must have your own Ceph server running with the share exported before you can use it.
{{< /caution >}}
See the [CephFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/cephfs/) for more details.
@@ -215,11 +215,11 @@ Note that this path is derived from the volume's `mountPath` and the `path`
keyed with `log_level`.
{{< caution >}}
-**Important:** You must create a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) before you can use it.
+You must create a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) before you can use it.
{{< /caution >}}
{{< note >}}
-**Note:** A Container using a ConfigMap as a [subPath](#using-subpath) volume mount will not
+A Container using a ConfigMap as a [subPath](#using-subpath) volume mount will not
receive ConfigMap updates.
{{< /note >}}
@@ -229,7 +229,7 @@ A `downwardAPI` volume is used to make downward API data available to applicatio
It mounts a directory and writes the requested data in plain text files.
{{< note >}}
-**Note:** A Container using Downward API as a [subPath](#using-subpath) volume mount will not
+A Container using Downward API as a [subPath](#using-subpath) volume mount will not
receive Downward API updates.
{{< /note >}}
@@ -245,7 +245,7 @@ or different paths in each Container. When a Pod is removed from a node for
any reason, the data in the `emptyDir` is deleted forever.
{{< note >}}
-**Note:** A Container crashing does *NOT* remove a Pod from a node, so the data in an `emptyDir` volume is safe across Container crashes.
+A Container crashing does *NOT* remove a Pod from a node, so the data in an `emptyDir` volume is safe across Container crashes.
{{< /note >}}
Some uses for an `emptyDir` are:
@@ -290,7 +290,7 @@ You can specify single or multiple target World Wide Names using the parameter
targetWWNs expect that those WWNs are from multi-path connections.
{{< caution >}}
-**Important:** You must configure FC SAN Zoning to allocate and mask those LUNs (volumes) to the target WWNs beforehand so that Kubernetes hosts can access them.
+You must configure FC SAN Zoning to allocate and mask those LUNs (volumes) to the target WWNs beforehand so that Kubernetes hosts can access them.
{{< /caution >}}
See the [FC example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel) for more details.
@@ -307,7 +307,7 @@ reattached by Flocker to the node that the Pod is scheduled. This means data
can be "handed off" between Pods as required.
{{< caution >}}
-**Important:** You must have your own Flocker installation running before you can use it.
+You must have your own Flocker installation running before you can use it.
{{< /caution >}}
See the [Flocker example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/flocker) for more details.
@@ -321,7 +321,7 @@ preserved and the volume is merely unmounted. This means that a PD can be
pre-populated with data, and that data can be "handed off" between Pods.
{{< caution >}}
-**Important:** You must create a PD using `gcloud` or the GCE API or UI before you can use it.
+You must create a PD using `gcloud` or the GCE API or UI before you can use it.
{{< /caution >}}
There are some restrictions when using a `gcePersistentDisk`:
@@ -403,7 +403,7 @@ spec:
### gitRepo (deprecated) {#gitrepo}
{{< warning >}}
-**Warning:** The gitRepo volume type is deprecated. To provision a container with a git repo, mount an [EmptyDir](#emptydir) into an InitContainer that clones the repo using git, then mount the [EmptyDir](#emptydir) into the Pod's container.
+The gitRepo volume type is deprecated. To provision a container with a git repo, mount an [EmptyDir](#emptydir) into an InitContainer that clones the repo using git, then mount the [EmptyDir](#emptydir) into the Pod's container.
{{< /warning >}}
A `gitRepo` volume is an example of what can be done as a volume plugin. It
@@ -443,7 +443,7 @@ be "handed off" between Pods. GlusterFS can be mounted by multiple writers
simultaneously.
{{< caution >}}
-**Important:** You must have your own GlusterFS installation running before you can use it.
+You must have your own GlusterFS installation running before you can use it.
{{< /caution >}}
See the [GlusterFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/glusterfs) for more details.
@@ -521,7 +521,7 @@ unmounted. This means that an iscsi volume can be pre-populated with data, and
that data can be "handed off" between Pods.
{{< caution >}}
-**Important:** You must have your own iSCSI server running with the volume created before you can use it.
+You must have your own iSCSI server running with the volume created before you can use it.
{{< /caution >}}
A feature of iSCSI is that it can be mounted as read-only by multiple consumers
@@ -537,7 +537,7 @@ See the [iSCSI example](https://github.com/kubernetes/examples/tree/{{< param "g
{{< feature-state for_k8s_version="v1.10" state="beta" >}}
{{< note >}}
-**Note:** The alpha PersistentVolume NodeAffinity annotation has been deprecated
+The alpha PersistentVolume NodeAffinity annotation has been deprecated
and will be removed in a future release. Existing PersistentVolumes using this
annotation must be updated by the user to use the new PersistentVolume
`NodeAffinity` field.
@@ -610,7 +610,7 @@ provisioning yet. For an example on how to run an external local provisioner,
see the [local volume provisioner user guide](https://github.com/kubernetes-incubator/external-storage/tree/master/local-volume).
{{< note >}}
-**Note:** The local PersistentVolume requires manual cleanup and deletion by the
+The local PersistentVolume requires manual cleanup and deletion by the
user if the external static provisioner is not used to manage the volume
lifecycle.
{{< /note >}}
@@ -625,7 +625,7 @@ that data can be "handed off" between Pods. NFS can be mounted by multiple
writers simultaneously.
{{< caution >}}
-**Important:** You must have your own NFS server running with the share exported before you can use it.
+You must have your own NFS server running with the share exported before you can use it.
{{< /caution >}}
See the [NFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs) for more details.
@@ -782,7 +782,7 @@ option for the API server. The `path` field specifies a relative path to the mou
of the projected volume.
{{< note >}}
-**Note:** A Container using a projected volume source as a [subPath](#using-subpath) volume mount will not
+A Container using a projected volume source as a [subPath](#using-subpath) volume mount will not
receive updates for those volume sources.
{{< /note >}}
@@ -818,7 +818,7 @@ spec:
```
{{< caution >}}
-**Important:** Make sure you have an existing PortworxVolume with name `pxvol`
+Make sure you have an existing PortworxVolume with name `pxvol`
before using it in the Pod.
{{< /caution >}}
@@ -830,7 +830,7 @@ A `quobyte` volume allows an existing [Quobyte](http://www.quobyte.com) volume t
be mounted into your Pod.
{{< caution >}}
-**Important:** You must have your own Quobyte setup running with the volumes
+You must have your own Quobyte setup running with the volumes
created before you can use it.
{{< /caution >}}
@@ -846,7 +846,7 @@ means that a RBD volume can be pre-populated with data, and that data can
be "handed off" between Pods.
{{< caution >}}
-**Important:** You must have your own Ceph installation running before you can use RBD.
+You must have your own Ceph installation running before you can use RBD.
{{< /caution >}}
A feature of RBD is that it can be mounted as read-only by multiple consumers
@@ -866,7 +866,7 @@ volumes (or it can dynamically provision new volumes for persistent volume claim
[ScaleIO Persistent Volumes](/docs/concepts/storage/persistent-volumes/#scaleio)).
{{< caution >}}
-**Important:** You must have an existing ScaleIO cluster already setup and
+You must have an existing ScaleIO cluster already setup and
running with the volumes created before you can use them.
{{< /caution >}}
@@ -908,11 +908,11 @@ backed by tmpfs (a RAM-backed filesystem) so they are never written to
non-volatile storage.
{{< caution >}}
-**Important:** You must create a secret in the Kubernetes API before you can use it.
+You must create a secret in the Kubernetes API before you can use it.
{{< /caution >}}
{{< note >}}
-**Note:** A Container using a Secret as a [subPath](#using-subpath) volume mount will not
+A Container using a Secret as a [subPath](#using-subpath) volume mount will not
receive Secret updates.
{{< /note >}}
@@ -934,7 +934,7 @@ The StorageOS Container requires 64-bit Linux and has no additional dependencies
A free developer license is available.
{{< caution >}}
-**Important:** You must run the StorageOS Container on each node that wants to
+You must run the StorageOS Container on each node that wants to
access StorageOS volumes or that will contribute storage capacity to the pool.
For installation instructions, consult the
[StorageOS documentation](https://docs.storageos.com).
@@ -974,7 +974,7 @@ For more information including Dynamic Provisioning and Persistent Volume Claims
### vsphereVolume {#vspherevolume}
{{< note >}}
-**Prerequisite:** Kubernetes with vSphere Cloud Provider configured. For cloudprovider
+Prerequisite: Kubernetes with vSphere Cloud Provider configured. For cloudprovider
configuration please refer [vSphere getting started guide](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/).
{{< /note >}}
@@ -982,7 +982,7 @@ A `vsphereVolume` is used to mount a vSphere VMDK Volume into your Pod. The con
of a volume are preserved when it is unmounted. It supports both VMFS and VSAN datastore.
{{< caution >}}
-**Important:** You must create VMDK using one of the following method before using with Pod.
+You must create VMDK using one of the following method before using with Pod.
{{< /caution >}}
#### Creating a VMDK volume
@@ -1191,16 +1191,16 @@ persistent volume:
- `controllerPublishSecretRef`: A reference to the secret object containing
sensitive information to pass to the CSI driver to complete the CSI
`ControllerPublishVolume` and `ControllerUnpublishVolume` calls. This field is
- optional, and may be empty if no secret is required. If the secret object
+ optional, and may be empty if no secret is required. If the secret object
contains more than one secret, all secrets are passed.
- `nodeStageSecretRef`: A reference to the secret object containing
sensitive information to pass to the CSI driver to complete the CSI
- `NodeStageVolume` call. This field is optional, and may be empty if no secret
+ `NodeStageVolume` call. This field is optional, and may be empty if no secret
is required. If the secret object contains more than one secret, all secrets
are passed.
- `nodePublishSecretRef`: A reference to the secret object containing
sensitive information to pass to the CSI driver to complete the CSI
- `NodePublishVolume` call. This field is optional, and may be empty if no
+ `NodePublishVolume` call. This field is optional, and may be empty if no
secret is required. If the secret object contains more than one secret, all
secrets are passed.
@@ -1274,7 +1274,7 @@ Its values are:
[Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)
{{< caution >}}
-**Caution:** `Bidirectional` mount propagation can be dangerous. It can damage
+`Bidirectional` mount propagation can be dangerous. It can damage
the host operating system and therefore it is allowed only in privileged
Containers. Familiarity with Linux kernel behavior is strongly recommended.
In addition, any volume mounts created by Containers in Pods must be destroyed
diff --git a/content/en/docs/concepts/workloads/_index.md b/content/en/docs/concepts/workloads/_index.md
index 702bdc6ee9..ca394ebd00 100644
--- a/content/en/docs/concepts/workloads/_index.md
+++ b/content/en/docs/concepts/workloads/_index.md
@@ -1,5 +1,5 @@
---
title: "Workloads"
-weight: 60
+weight: 50
---
diff --git a/content/en/docs/concepts/workloads/controllers/cron-jobs.md b/content/en/docs/concepts/workloads/controllers/cron-jobs.md
index 3169cb13bf..602bf0d581 100644
--- a/content/en/docs/concepts/workloads/controllers/cron-jobs.md
+++ b/content/en/docs/concepts/workloads/controllers/cron-jobs.md
@@ -14,8 +14,9 @@ A _Cron Job_ creates [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-com
One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically
on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format.
+
{{< note >}}
-**Note:** All **CronJob** `schedule:` times are denoted in UTC.
+All **CronJob** `schedule:` times are denoted in UTC.
{{< /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).
diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md
index be407b6ce1..80c81863c4 100644
--- a/content/en/docs/concepts/workloads/controllers/deployment.md
+++ b/content/en/docs/concepts/workloads/controllers/deployment.md
@@ -20,7 +20,7 @@ A _Deployment_ controller provides declarative updates for [Pods](/docs/concepts
You describe a _desired state_ in a Deployment object, and the Deployment controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.
{{< note >}}
-**Note:** You should not manage ReplicaSets owned by a Deployment. All the use cases should be covered by manipulating the Deployment object. Consider opening an issue in the main Kubernetes repository if your use case is not covered below.
+You should not manage ReplicaSets owned by a Deployment. All the use cases should be covered by manipulating the Deployment object. Consider opening an issue in the main Kubernetes repository if your use case is not covered below.
{{< /note >}}
{{% /capture %}}
@@ -57,7 +57,7 @@ In this example:
as long as the Pod template itself satisfies the rule.
{{< note >}}
- **Note:** `matchLabels` is a map of {key,value} pairs. A single {key,value} in the `matchLabels` map
+ `matchLabels` is a map of {key,value} pairs. A single {key,value} in the `matchLabels` map
is equivalent to an element of `matchExpressions`, whose key field is "key", the operator is "In",
and the values array contains only "value". The requirements are ANDed.
{{< /note >}}
@@ -74,11 +74,11 @@ In this example:
To create this Deployment, run the following command:
```shell
-kubectl create -f https://k8s.io/examples/controllers/nginx-deployment.yaml
+kubectl create -f https://k8s.io/examples/controllers/nginx-deployment.yaml
```
{{< note >}}
-**Note:** You may specify the `--record` flag to write the command executed in the resource annotation `kubernetes.io/change-cause`. It is useful for future instrospection, for example to see the commands executed in each Deployment revision.
+You may specify the `--record` flag to write the command executed in the resource annotation `kubernetes.io/change-cause`. It is useful for future introspection, for example to see the commands executed in each Deployment revision.
{{< /note >}}
Next, run `kubectl get deployments`. The output is similar to the following:
@@ -145,14 +145,14 @@ nginx-deployment-2035384211-qqcnn 1/1 Running 0 18s app
The created ReplicaSet ensures that there are three `nginx` Pods running at all times.
{{< note >}}
-**Note:** You must specify an appropriate selector and Pod template labels in a Deployment (in this case,
+You must specify an appropriate selector and Pod template labels in a Deployment (in this case,
`app: nginx`). Do not overlap labels or selectors with other controllers (including other Deployments and StatefulSets). Kubernetes doesn't stop you from overlapping, and if multiple controllers have overlapping selectors those controllers might conflict and behave unexpectedly.
{{< /note >}}
### Pod-template-hash label
{{< note >}}
-**Note:** Do not change this label.
+Do not change this label.
{{< /note >}}
The `pod-template-hash` label is added by the Deployment controller to every ReplicaSet that a Deployment creates or adopts.
@@ -163,7 +163,7 @@ and in any existing Pods that the ReplicaSet might have.
## Updating a Deployment
{{< note >}}
-**Note:** A Deployment's rollout is triggered if and only if the Deployment's pod template (that is, `.spec.template`)
+A Deployment's rollout is triggered if and only if the Deployment's pod template (that is, `.spec.template`)
is changed, for example if the labels or container images of the template are updated. Other updates, such as scaling the Deployment, do not trigger a rollout.
{{< /note >}}
@@ -307,7 +307,7 @@ In any case, if you need to perform a label selector update, exercise great caut
all of the implications.
{{< note >}}
-**Note:** In API version `apps/v1`, a Deployment's label selector is immutable after it gets created.
+In API version `apps/v1`, a Deployment's label selector is immutable after it gets created.
{{< /note >}}
* Selector additions require the pod template labels in the Deployment spec to be updated with the new label too,
@@ -326,7 +326,7 @@ By default, all of the Deployment's rollout history is kept in the system so tha
(you can change that by modifying revision history limit).
{{< note >}}
-**Note:** A Deployment's revision is created when a Deployment's rollout is triggered. This means that the
+A Deployment's revision is created when a Deployment's rollout is triggered. This means that the
new revision is created if and only if the Deployment's pod template (`.spec.template`) is changed,
for example if you update the labels or container images of the template. Other updates, such as scaling the Deployment,
do not create a Deployment revision, so that you can facilitate simultaneous manual- or auto-scaling.
@@ -373,7 +373,7 @@ nginx-deployment-3066724191-08mng 0/1 ImagePullBackOff 0 6s
```
{{< note >}}
-**Note:** The Deployment controller will stop the bad rollout automatically, and will stop scaling up the new
+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 25%.
{{< /note >}}
@@ -681,7 +681,7 @@ nginx-3926361531 3 3 3 28s
```
{{< note >}}
-**Note:** You cannot rollback a paused Deployment until you resume it.
+You cannot rollback a paused Deployment until you resume it.
{{< /note >}}
## Deployment status
@@ -754,13 +754,13 @@ attributes to the Deployment's `.status.conditions`:
See the [Kubernetes API conventions](https://git.k8s.io/community/contributors/devel/api-conventions.md#typical-status-properties) for more information on status conditions.
{{< note >}}
-**Note:** Kubernetes will take no action on a stalled Deployment other than to report a status condition with
+Kubernetes will take no action on a stalled Deployment other than to report a status condition with
`Reason=ProgressDeadlineExceeded`. Higher level orchestrators can take advantage of it and act accordingly, for
example, rollback the Deployment to its previous version.
{{< /note >}}
{{< note >}}
-**Note:** If you pause a Deployment, Kubernetes does not check progress against your specified deadline. You can
+If you pause a Deployment, Kubernetes does not check progress against your specified deadline. You can
safely pause a Deployment in the middle of a rollout and resume without triggering the condition for exceeding the
deadline.
{{< /note >}}
@@ -865,7 +865,7 @@ this Deployment you want to retain. The rest will be garbage-collected in the ba
it is 10.
{{< note >}}
-**Note:** Explicitly setting this field to 0, will result in cleaning up all the history of your Deployment
+Explicitly setting this field to 0, will result in cleaning up all the history of your Deployment
thus that Deployment will not be able to roll back.
{{< /note >}}
@@ -916,7 +916,7 @@ from `.spec.template` or if the total number of such Pods exceeds `.spec.replica
Pods with `.spec.template` if the number of Pods is less than the desired number.
{{< note >}}
-**Note:** You should not create other pods whose labels match this selector, either directly, by creating
+You should not create other pods whose labels match this selector, either directly, by creating
another Deployment, or by creating another controller such as a ReplicaSet or a ReplicationController. If you
do so, the first Deployment thinks that it created these other pods. Kubernetes does not stop you from doing this.
{{< /note >}}
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 d443c3bee8..666d8551e9 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
@@ -206,7 +206,7 @@ back-off count is reset if no new failed Pods appear before the Job's next
status check.
{{< note >}}
-**Note:** Issue [#54870](https://github.com/kubernetes/kubernetes/issues/54870) still exists for versions of Kubernetes prior to version 1.12
+Issue [#54870](https://github.com/kubernetes/kubernetes/issues/54870) still exists for versions of Kubernetes prior to version 1.12
{{< /note >}}
## Job Termination and Cleanup
diff --git a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
index d6dcb84249..daf0dfd59a 100644
--- a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
@@ -16,7 +16,7 @@ weight: 20
{{% capture overview %}}
{{< note >}}
-**NOTE:** A [`Deployment`](/docs/concepts/workloads/controllers/deployment/) that configures a [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) is now the recommended way to set up replication.
+A [`Deployment`](/docs/concepts/workloads/controllers/deployment/) that configures a [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) is now the recommended way to set up replication.
{{< /note >}}
A _ReplicationController_ ensures that a specified number of pod replicas are running at any one
diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md
index 480988cb09..0e3a4e8569 100644
--- a/content/en/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/en/docs/concepts/workloads/controllers/statefulset.md
@@ -16,7 +16,7 @@ weight: 40
StatefulSet is the workload API object used to manage stateful applications.
{{< note >}}
-**Note:** StatefulSets are stable (GA) in 1.9.
+StatefulSets are stable (GA) in 1.9.
{{< /note >}}
{{< glossary_definition term_id="statefulset" length="all" >}}
@@ -144,7 +144,7 @@ Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain
kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} |
{{< note >}}
-**Note:** Cluster Domain will be set to `cluster.local` unless
+Cluster Domain will be set to `cluster.local` unless
[otherwise configured](/docs/concepts/services-networking/dns-pod-service/#how-it-works).
{{< /note >}}
diff --git a/content/en/docs/concepts/workloads/pods/disruptions.md b/content/en/docs/concepts/workloads/pods/disruptions.md
index 79b0ac00d9..3a3ecb36cf 100644
--- a/content/en/docs/concepts/workloads/pods/disruptions.md
+++ b/content/en/docs/concepts/workloads/pods/disruptions.md
@@ -93,7 +93,7 @@ time as frequent voluntary disruptions. We call this set of features
## How Disruption Budgets Work
An Application Owner can create a `PodDisruptionBudget` object (PDB) for each application.
-A PDB limits the number pods of a replicated application that are down simultaneously from
+A PDB limits the number of pods of a replicated application that are down simultaneously from
voluntary disruptions. For example, a quorum-based application would
like to ensure that the number of replicas running is never brought below the
number needed for a quorum. A web front end might want to
diff --git a/content/en/docs/concepts/workloads/pods/pod-overview.md b/content/en/docs/concepts/workloads/pods/pod-overview.md
index d08433ef39..8bb3f68504 100644
--- a/content/en/docs/concepts/workloads/pods/pod-overview.md
+++ b/content/en/docs/concepts/workloads/pods/pod-overview.md
@@ -25,7 +25,7 @@ Pods in a Kubernetes cluster can be used in two main ways:
* **Pods that run a single container**. The "one-container-per-Pod" model is the most common Kubernetes use case; in this case, you can think of a Pod as a wrapper around a single container, and Kubernetes manages the Pods rather than the containers directly.
* **Pods that run multiple containers that need to work together**. A Pod might encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers might form a single cohesive unit of service--one container serving files from a shared volume to the public, while a separate "sidecar" container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single manageable entity.
-The [Kubernetes Blog](http://blog.kubernetes.io) has some additional information on Pod use cases. For more information, see:
+The [Kubernetes Blog](http://kubernetes.io/blog) has some additional information on Pod use cases. For more information, see:
* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
* [Container Design Patterns](https://kubernetes.io/blog/2016/06/container-design-patterns)
@@ -55,7 +55,7 @@ A Pod can specify a set of shared storage *volumes*. All containers in the Pod c
You'll rarely create individual Pods directly in Kubernetes--even singleton Pods. This is because Pods are designed as relatively ephemeral, disposable entities. When a Pod gets created (directly by you, or indirectly by a Controller), it is scheduled to run on a Node in your cluster. The Pod remains on that Node until the process is terminated, the pod object is deleted, the pod is *evicted* for lack of resources, or the Node fails.
{{< note >}}
-**Note:** Restarting a container in a Pod should not be confused with restarting the Pod. The Pod itself does not run, but is an environment the containers run in and persists until it is deleted.
+Restarting a container in a Pod should not be confused with restarting the Pod. The Pod itself does not run, but is an environment the containers run in and persists until it is deleted.
{{< /note >}}
Pods do not, by themselves, self-heal. If a Pod is scheduled to a Node that fails, or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a higher-level abstraction, called a *Controller*, that handles the work of managing the relatively disposable Pod instances. Thus, while it is possible to use Pod directly, it's far more common in Kubernetes to manage your pods using a Controller. See [Pods and Controllers](#pods-and-controllers) for more information on how Kubernetes uses Controllers to implement Pod scaling and healing.
diff --git a/content/en/docs/concepts/workloads/pods/podpreset.md b/content/en/docs/concepts/workloads/pods/podpreset.md
index 6711ba2ffe..dfae21fd4f 100644
--- a/content/en/docs/concepts/workloads/pods/podpreset.md
+++ b/content/en/docs/concepts/workloads/pods/podpreset.md
@@ -51,7 +51,7 @@ Pods, Kubernetes modifies the Pod Spec. For changes to `Env`, `EnvFrom`, and
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
+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
applied to the `initContainers` field.
{{< /note >}}
diff --git a/content/en/docs/contribute/_index.md b/content/en/docs/contribute/_index.md
index 688a2c6160..c7f191e5c1 100644
--- a/content/en/docs/contribute/_index.md
+++ b/content/en/docs/contribute/_index.md
@@ -13,18 +13,14 @@ we're happy to have your help! Anyone can contribute, whether you're new to the
project or you've been around a long time, and whether you self-identify as a
developer, an end user, or someone who just can't stand seeing typos.
-For more ways to get involved in the Kubernetes community or to learn about us,
-also visit the [Kubernetes community site](/community/).
-
-Looking for the [style guide](/docs/contribute/style/style-guide/) or the
-[Kubernetes Community site](/community/)?
-{{% /capture %}}
+For more ways to get involved in the Kubernetes community or to learn about us, visit the [Kubernetes community site](/community/).
+For information on the Kubernetes documentation style guide, see the [style guide](/docs/contribute/style/style-guide/).
{{% capture body %}}
-## Types of contributor
+## Types of contributors
-- A _member_ of the Kubernetes organization has [signed the CLA](/docs/contribute/start#sign-the-cla)
+- A _member_ of the Kubernetes organization who has [signed the CLA](/docs/contribute/start#sign-the-cla)
and contributed some time and effort to the project. See
[Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md)
for specific criteria for membership.
@@ -33,8 +29,8 @@ Looking for the [style guide](/docs/contribute/style/style-guide/) or the
added to the appropriate Github group and `OWNERS` files in the Github
repository, by a SIG Docs Approver.
- A SIG Docs _approver_ is a member in good standing who has shown a continued
- commitment to the project and is granted the ability to merge pull requests
- and thus to publish content on behalf of the Kubernetes organization.
+ commitment to the project. An approver can merge pull requests
+ and publish content on behalf of the Kubernetes organization.
Approvers can also represent SIG Docs in the larger Kubernetes community.
Some of the duties of a SIG Docs approver, such as coordinating a release,
require a significant time commitment.
@@ -54,7 +50,7 @@ documentation, but it should help you get started.
- File actionable bugs
- [Member](/docs/contribute/start/)
- Improve existing docs
- - Bring up ideas for improvement on Slack or SIG docs mailing list
+ - Bring up ideas for improvement on [Slack](http://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
- Improve docs accessibility
- Provide non-binding feedback on PRs
- Write a blog post or case study
diff --git a/content/en/docs/contribute/advanced.md b/content/en/docs/contribute/advanced.md
index 1a430d6a7d..3b55e78a61 100644
--- a/content/en/docs/contribute/advanced.md
+++ b/content/en/docs/contribute/advanced.md
@@ -98,7 +98,7 @@ SIG Docs [reviewers](/docs/contribute/participating/#reviewers) can sponsor
new contributors.
After a new contributor has successfully submitted 5 substantive pull requests
-to one or more Kubernetes repositiries, they are eligible to apply for
+to one or more Kubernetes repositories, they are eligible to apply for
[membership](/docs/contribute/participating#members) in the Kubernetes
organization. The contributor's membership needs to be backed by two sponsors
who are already reviewers.
diff --git a/content/en/docs/contribute/generate-ref-docs/kubectl.md b/content/en/docs/contribute/generate-ref-docs/kubectl.md
index 6793c6e6b9..39fc14cf08 100644
--- a/content/en/docs/contribute/generate-ref-docs/kubectl.md
+++ b/content/en/docs/contribute/generate-ref-docs/kubectl.md
@@ -9,7 +9,6 @@ This page shows how to automatically generate reference pages for the
commands provided by the `kubectl` tool.
{{< note >}}
-**Note:**
This topic shows how to generate reference documentation for
[kubectl commands](/docs/reference/generated/kubectl/kubectl-commands)
like
@@ -132,7 +131,6 @@ on how to do this, see
Monitor your cherry-pick pull request until it is merged into the release branch.
{{< note >}}
-**Note:**
Proposing a cherry pick requires that you have permission to set a label and a
milestone in your pull request. If you don’t have those permissions, you will
need to work with someone who can set the label and milestone for you.
diff --git a/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
index f61e62f5cb..7dc9e813bd 100644
--- a/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
+++ b/content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
@@ -98,7 +98,7 @@ or more comments in the Kubernetes source code.
### Making changes to comments in the source code
{{< note >}}
-**Note**: The following steps are an example, not a general procedure. Details
+The following steps are an example, not a general procedure. Details
will be different in your situation.
{{< /note >}}
@@ -184,7 +184,7 @@ to monitor your pull request until it has been merged.
is an example of a pull request that fixes a typo in the Kubernetes source code.
{{< note >}}
-**Note**: It can be tricky to determine the correct source file to be changed. In the
+It can be tricky to determine the correct source file to be changed. In the
preceding example, the authoritative source file is under the `staging` directory
in the `kubernetes/kubernetes` repository. But in your situation,the `staging` directory
might not be the place to find the authoritative source. For guidance, check the
@@ -208,9 +208,11 @@ commit into the release-1.9 branch. The idea is to cherry pick the commit that e
the commit that has the results of running the scripts. For instructions, see
[Propose a Cherry Pick](https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md).
-**Note:** Proposing a cherry pick requires that you have permission to set a label and a milestone in your
+{{< note >}}
+Proposing a cherry pick requires that you have permission to set a label and a milestone in your
pull request. If you don't have those permissions, you will need to work with someone who can set the label
and milestone for you.
+{{< /note >}}
When you have a pull request in place for cherry picking your one commit into the release-1.9 branch,
the next step is to run these scripts in the release-1.9 branch of your local environment.
diff --git a/content/en/docs/contribute/generate-ref-docs/kubernetes-components.md b/content/en/docs/contribute/generate-ref-docs/kubernetes-components.md
index b4f03c1e33..b19f060714 100644
--- a/content/en/docs/contribute/generate-ref-docs/kubernetes-components.md
+++ b/content/en/docs/contribute/generate-ref-docs/kubernetes-components.md
@@ -12,7 +12,6 @@ reference documentation for tools and components in the
{{% /capture %}}
-
{{% capture prerequisites %}}
* You need a machine that is running Linux or macOS.
@@ -36,7 +35,6 @@ information, see
{{% /capture %}}
-
{{% capture steps %}}
## Getting two repositories
@@ -71,7 +69,6 @@ your base directory is `$GOPATH/src/github.com/kubernetes/kubernetes.`
The remaining steps refer to your base directory as ``.
{{< note >}}
-**Note:**
If you only need to generate, but not change, the reference docs, you don't need to
manually get the `kubernetes/kubernetes` repository. When you run the `update-imported-docs`
tool, it automatically clones the `kubernetes/kubernetes` repository.
@@ -109,16 +106,15 @@ to do this, see
Monitor your cherry-pick pull request until it is merged into the release branch.
{{< note >}}
-**Note:** Proposing a cherry pick requires that you have permission to set a label
+Proposing a cherry pick requires that you have permission to set a label
and a milestone in your pull request. If you don’t have those permissions, you will
need to work with someone who can set the label and milestone for you.
{{< /note >}}
## Overview of update-imported-docs
-The website repository contains a `update-imported-docs` tool under the
-`kubernetes/website/update-imported-docs/` directory that performs the
-following steps:
+The `update-imported-docs` tool is located in the `kubernetes/website/update-imported-docs/`
+directory. The tool performs the following steps:
1. Clones the related repositories specified in a configuration file. For the
purpose of generating reference docs, the repositories that are cloned by
@@ -135,8 +131,8 @@ to `kubernetes/website`.
## Customizing the config file
-Open `/update-imported-docs/reference.yaml` for editing.
-Do not change the content for the `generate-command` entry unless you undertand
+Open `/update-imported-docs/reference.yml` for editing.
+Do not change the content for the `generate-command` entry unless you understand
what it is doing and need to change the specified release branch.
```shell
@@ -160,8 +156,9 @@ repos:
make comp
```
-The `update-imported-docs` tool uses `src` and `dst` fields in a configuration
-to decide the source and target location for doc files to be copied.
+In reference.yml, the `files` field is a list of `src` and `dst` fields. The `src` field
+specifies the location of a generated Markdown file, and the `dst` field specifies
+where to copy this file in the cloned `kubernetes/website` repository.
For example:
```yaml
@@ -241,6 +238,4 @@ topics will be visible in the
* [Generating Reference Documentation for the Kubernetes API](/docs/home/contribute/generated-reference/kubernetes-api/)
* [Generating Reference Documentation for the Kubernetes Federation API](/docs/home/contribute/generated-reference/federation-api/)
-{{% /capture %}}
-
-
+{{% /capture %}}
\ No newline at end of file
diff --git a/content/en/docs/contribute/intermediate.md b/content/en/docs/contribute/intermediate.md
index 3fed21a05b..0a21ae1ddc 100644
--- a/content/en/docs/contribute/intermediate.md
+++ b/content/en/docs/contribute/intermediate.md
@@ -12,8 +12,7 @@ This page assumes that you've read and mastered the tasks in the
learn about more ways to contribute.
{{< note >}}
-**Note:** Some tasks require you to use the Git command line client and other
-tools.
+Some tasks require you to use the Git command line client and other tools.
{{< /note >}}
{{% /capture %}}
@@ -38,7 +37,7 @@ that one person does all of them all of the time.
In any given week, a specific docs approver volunteers to do initial triage
and review of [pull requests and issues](#triage-and-categorize-issues). This
person is the "PR Wrangler" for the week. The schedule is maintained using the
-[PR Wrangler scheduler(https://github.com/kubernetes/website/wiki/PR-Wranglers).
+[PR Wrangler scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers).
To be added to this list, attend the weekly SIG Docs meeting and volunteer. Even
if you are not on the schedule for the current week, you can still review pull
requests (PRs) that are not already under active review.
@@ -387,11 +386,11 @@ most up-to-date version of that branch.
```
{{< note >}}
-**Note:** Do not reference a Github issue or pull request by ID or URL in the
-commit message. If you do, it will cause that issue or pull request to get
-a notification every time the commit shows up in a new Git branch. You can
-link issues and pull requests together later, in the Github UI.
-{{< /note >}}
+ Do not reference a Github issue or pull request by ID or URL in the
+ commit message. If you do, it will cause that issue or pull request to get
+ a notification every time the commit shows up in a new Git branch. You can
+ link issues and pull requests together later, in the Github UI.
+ {{< /note >}}
5. Optionally, you can test your change by staging the site locally using the
`hugo` command. See [View your changes locally](#view-your-changes-locally).
@@ -528,7 +527,7 @@ In any given week, a specific docs approver volunteers to do initial
on this list, attend the weekly SIG Docs meeting and volunteer. Even if you are
not on the schedule for the current week, you can still review PRs.
-People in SIG Docs are only responsible for triaging and categorizing
+People in SIG Docs are responsible only for triaging and categorizing
documentation issues. General website issues are also filed in the
`kubernetes/website` repository.
@@ -626,6 +625,13 @@ resolve the issue. Dead links in the API and Kubectl docs are automation issues
and should be assigned a P1 until the problem can be fully understood. All other
dead links are issues that need to be manually fixed and can be assigned a P3.
+#### Blog issues
+
+[Kubernetes Blog](https://kubernetes.io/blog/) entries are expected to become
+outdated over time, so we maintain only blog entries that are less than one year old.
+If an issue is related to a blog entry that is more than one year old, it should be closed
+without fixing.
+
#### Support requests or code bug reports
Some issues opened for docs are instead issues with the underlying code, or
@@ -800,6 +806,18 @@ content. See [Localization](/docs/contribute/localization/) and ask on the
[kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
or in `#sig-docs` on Slack if you are interested in helping out.
+### Working with localized content
+
+Follow these guidelines for working with localized content:
+
+- Limit PRs to a single language.
+
+ Each language has its own reviewers and approvers.
+
+- Reviewers, verify that PRs contain changes to only one language.
+
+ If a PR contains changes to source in more than one language, ask the PR contributor to open separate PRs for each language.
+
{{% /capture %}}
{{% capture whatsnext %}}
diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md
index 7120607d2e..6e73492a14 100644
--- a/content/en/docs/contribute/localization.md
+++ b/content/en/docs/contribute/localization.md
@@ -29,6 +29,10 @@ Localizations must meet some requirements for workflow (*how* to localize) and o
To add a new localization of the Kubernetes documentation, you'll need to update the website by modifying the [site configuration](#modify-the-site-configuration) and [directory structure](#add-a-new-localization-directory). Then you can start [translating documents](#translating-documents)!
+{{< note >}}
+For an example localization-related [pull request](../create-pull-request), see [this pull request](https://github.com/kubernetes/website/pull/8636) to the [Kubernetes website repo](https://github.com/kubernetes/website) adding Korean localization to the Kubernetes docs.
+{{< /note >}}
+
Let Kubernetes SIG Docs know you're interested in creating a localization! Join the [SIG Docs Slack channel](https://kubernetes.slack.com/messages/C1J0BPD2M/). We're happy to help you get started and answer any questions you have.
All localization teams must be self-sustaining with their own resources. We're happy to host your work, but we can't translate it for you.
@@ -199,7 +203,7 @@ For more information about working from forks or directly from the repository, s
### Upstream contributions
-SIG Docs welcomes upstream contributions and corrections to the English source! Open a [pull request](https://kubernetes.io/docs/contribute/start/#improve-existing-content) (from a fork) with any updates.
+SIG Docs welcomes [upstream contributions and corrections](/docs/contribute/intermediate#localize-content) to the English source.
{{% /capture %}}
diff --git a/content/en/docs/contribute/participating.md b/content/en/docs/contribute/participating.md
index 1783bd9aac..029f3bf746 100644
--- a/content/en/docs/contribute/participating.md
+++ b/content/en/docs/contribute/participating.md
@@ -84,7 +84,7 @@ in the Kubernetes organization. Follow these steps:
1. Find two reviewers or approvers to [sponsor](/docs/contribute/advanced#sponsor-a-new-contributor)
your membership.
- Ask for sponsorship in the #sig-docs channel on the
+ Ask for sponsorship in the [#sig-docs channel on the
Kubernetes Slack instance](https://kubernetes.slack.com) or on the
[SIG Docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
diff --git a/content/en/docs/contribute/start.md b/content/en/docs/contribute/start.md
index 2ebf585efa..ee49c00022 100644
--- a/content/en/docs/contribute/start.md
+++ b/content/en/docs/contribute/start.md
@@ -24,12 +24,7 @@ code repositories, refer to
## The basics about our docs
-The Kubernetes documentation is written in Markdown and processed and deployed
-using Hugo. The source is in Github at
-[https://github.com/kubernetes/website](https://github.com/kubernetes/website).
-Most of the documentation source is stored in `/content/en/docs/`. Some of the
-reference documentation is automatically generated from scripts in the
-`update-imported-docs/` directory.
+The Kubernetes documentation is written in Markdown and processed and deployed using Hugo. The source is in Github at [https://github.com/kubernetes/website](https://github.com/kubernetes/website). Most of the documentation source is stored in `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory.
You can file issues, edit content, and review changes from others, all from the
Github website. You can also use Github's embedded history and search tools.
@@ -70,6 +65,14 @@ We make use of the standard Hugo shortcodes, as well as a few that are custom to
the Kubernetes documentation. See [Custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) for
information about how to use them.
+### Multiple languages
+
+Documentation source is available in multiple languages in `/content/`. Each language has its own folder with a two-letter code determined by the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For example, English documentation source is stored in `/content/en/docs/`.
+
+For more information about contributing to documentation in multiple languages, see ["Localize content"](/docs/contribute/intermediate#localize-content) in the intermediate contributing guide.
+
+If you're interested in starting a new localization, see ["Localization"](/docs/contribute/localization/).
+
## File actionable issues
Anyone with a Github account can file an issue (bug report) against the
@@ -213,7 +216,7 @@ documentation.
include more detail if appropriate.
{{< note >}}
-**Note**: Do not include references to other Github issues or pull
+Do not include references to other Github issues or pull
requests in your commit message. You can add those to the pull request
description later.
{{< /note >}}
@@ -231,7 +234,7 @@ description later.
**Create pull request**.
{{< note >}}
-**Note**: If you don't want to create the pull request now, you can do it
+If you don't want to create the pull request now, you can do it
later, by browsing to the main URL of the Kubernetes website repository or
your fork's repository. The Github website will prompt you to create the
pull request if it detects that you pushed a new branch to your fork.
diff --git a/content/en/docs/contribute/style/content-organization.md b/content/en/docs/contribute/style/content-organization.md
index 61ee7d9a3b..a89e686ac9 100644
--- a/content/en/docs/contribute/style/content-organization.md
+++ b/content/en/docs/contribute/style/content-organization.md
@@ -32,7 +32,7 @@ weight: 10
{{% note %}}
-**Note:** For page weights, it can be smart not to use 1, 2, 3 ..., but some other interval, say 10, 20, 30... This allows you to insert pages where you want later.
+For page weights, it can be smart not to use 1, 2, 3 ..., but some other interval, say 10, 20, 30... This allows you to insert pages where you want later.
{{% /note %}}
@@ -56,7 +56,7 @@ linkTitle: Title used in links
{{% note %}}
-**Note:** The above needs to be done per language. If you don't see your section in the menu, it is probably because it is not identified as a section by Hugo. Create a `_index.md` content file in the section folder.
+The above needs to be done per language. If you don't see your section in the menu, it is probably because it is not identified as a section by Hugo. Create a `_index.md` content file in the section folder.
{{% /note %}}
### Documentation Side Menu
diff --git a/content/en/docs/contribute/style/hugo-shortcodes/example1.md b/content/en/docs/contribute/style/hugo-shortcodes/example1.md
index 9ee1a0b313..fbe21a1457 100644
--- a/content/en/docs/contribute/style/hugo-shortcodes/example1.md
+++ b/content/en/docs/contribute/style/hugo-shortcodes/example1.md
@@ -5,5 +5,5 @@ title: Example #1
This is an **example** content file inside the **includes** leaf bundle.
{{< note >}}
-**Note:** Included content files can also contain shortcodes.
+Included content files can also contain shortcodes.
{{< /note >}}
\ No newline at end of file
diff --git a/content/en/docs/contribute/style/hugo-shortcodes/index.md b/content/en/docs/contribute/style/hugo-shortcodes/index.md
index 8d826a4c69..3161588996 100644
--- a/content/en/docs/contribute/style/hugo-shortcodes/index.md
+++ b/content/en/docs/contribute/style/hugo-shortcodes/index.md
@@ -14,7 +14,7 @@ Read more about shortcodes in the [Hugo documentation](https://gohugo.io/content
{{% capture body %}}
## Feature state
-In a markdown page (.md file) on this site, you can add a shortcode to display version and state of the documented feature.
+In a markdown page (`.md` file) on this site, you can add a shortcode to display version and state of the documented feature.
### Feature state demo
@@ -24,7 +24,7 @@ Below is a demo of the feature state snippet, which displays the feature as stab
{{* feature-state for_k8s_version="v1.10" state="stable" */>}}
```
-Will render to:
+Renders to:
{{< feature-state for_k8s_version="v1.10" state="stable" >}}
@@ -37,8 +37,6 @@ The valid values for `state` are:
### Feature state code
-Below is the template code for each available feature state.
-
The displayed Kubernetes version defaults to that of the page or the site. This can be changed by passing the for_k8s_version shortcode parameter.
````
@@ -92,14 +90,14 @@ Renders to:
## Glossary
-You can reference glossary terms with an inclusion that will automatically update and replace content with the relevant links from [our glossary](/docs/reference/glossary/). When the term is moused-over by someone
-using the online documentation, the glossary entry will display a tooltip.
+You can reference glossary terms with an inclusion that automatically updates and replaces content with the relevant links from [our glossary](/docs/reference/glossary/). When the term is moused-over by someone
+using the online documentation, the glossary entry displays a tooltip.
The raw data for glossary terms is stored at [https://github.com/kubernetes/website/tree/master/content/en/docs/reference/glossary](https://github.com/kubernetes/website/tree/master/content/en/docs/reference/glossary), with a content file for each glossary term.
### Glossary Demo
-For example, the following include within the markdown will render to {{< glossary_tooltip text="cluster" term_id="cluster" >}} with a tooltip:
+For example, the following include within the markdown renders to {{< glossary_tooltip text="cluster" term_id="cluster" >}} with a tooltip:
````liquid
{{* glossary_tooltip text="cluster" term_id="cluster" */>}}
@@ -113,9 +111,8 @@ The `tabs` shortcode takes these parameters:
* `name`: The name as shown on the tab.
* `codelang`: If you provide inner content to the `tab` shortcode, you can tell Hugo what code language to use for highlighting.
-* `include`: The file to include in the tab. If the tab lives in a Hugo [leaf bundle](https://gohugo.io/content-management/page-bundles/#leaf-bundles), the file -- which can be any MIME type supported by Hugo -- will be looked up in the bundle itself. If not, the content page to include will be looked up relative to the current. Note that with the `include` you will not have any shortcode inner content and must use the self-closing syntax, e.g. {{* tab name="Content File #1" include="example1" /*/>}}. Non-content files will be code-highlighted. The language to use will be taken from the filename if not provided in `codelang`.
-
-* If your inner content is markdown, you must use `%`-delimiter to surorund the tab, e.g. `{{%/* tab name="Tab 1" %}}This is **markdown**{{% /tab */%}}`
+* `include`: The file to include in the tab. If the tab lives in a Hugo [leaf bundle](https://gohugo.io/content-management/page-bundles/#leaf-bundles), the file -- which can be any MIME type supported by Hugo -- is looked up in the bundle itself. If not, the content page that needs to be included is looked up relative to the current page. Note that with the `include`, you do not have any shortcode inner content and must use the self-closing syntax. For example, {{* tab name="Content File #1" include="example1" /*/>}}. The language needs to be specified under `codelang` or the language is taken based on the file name. Non-content files are code-highlighted by default.
+* If your inner content is markdown, you must use the `%`-delimiter to surround the tab. For example, `{{%/* tab name="Tab 1" %}}This is **markdown**{{% /tab */%}}`
* You can combine the variations mentioned above inside a tab set.
Below is a demo of the tabs shortcode.
@@ -137,7 +134,7 @@ println "This is tab 2."
{{< /tabs */>}}
```
-Will be rendered as:
+Renders to:
{{< tabs name="tab_with_code" >}}
{{< tab name="Tab 1" codelang="bash" >}}
@@ -154,7 +151,9 @@ println "This is tab 2."
{{* tabs name="tab_with_md" >}}
{{% tab name="Markdown" %}}
This is **some markdown.**
-{{< note >}}**Note:** It can even contain shortcodes.{{< /note >}}
+{{< note >}}
+It can even contain shortcodes.
+{{< /note >}}
{{% /tab %}}
{{< tab name="HTML" >}}
@@ -165,12 +164,16 @@ This is **some markdown.**
{{< /tabs */>}}
```
-Will be rendered as:
+Renders to:
{{< tabs name="tab_with_md" >}}
{{% tab name="Markdown" %}}
This is **some markdown.**
-{{< note >}}**Note:** It can even contain shortcodes.{{< /note >}}
+
+{{< note >}}
+It can even contain shortcodes.
+{{< /note >}}
+
{{% /tab %}}
{{< tab name="HTML" >}}
@@ -190,7 +193,7 @@ This is **some markdown.**
{{< /tabs */>}}
```
-Will be rendered as:
+Renders to:
{{< tabs name="tab_with_file_include" >}}
{{< tab name="Content File #1" include="example1" />}}
diff --git a/content/en/docs/contribute/style/page-templates.md b/content/en/docs/contribute/style/page-templates.md
index 147e8f5ec7..7c2229ad99 100644
--- a/content/en/docs/contribute/style/page-templates.md
+++ b/content/en/docs/contribute/style/page-templates.md
@@ -15,7 +15,7 @@ directory of the [`kubernetes/website`](https://github.com/kubernetes/website)
repository.
{{< note >}}
-**Note**: Every new topic needs to use a template. If you are unsure which
+Every new topic needs to use a template. If you are unsure which
template to use for a new topic, start with the
[concept template](#concept-template).
{{< /note >}}
@@ -75,7 +75,7 @@ To write a new concept page, create a Markdown file in a subdirectory of the
An example of a published topic that uses the concept template is
[Annotations](/docs/concepts/overview/working-with-objects/annotations/). The
-page you are currently reading also uses the content template.
+page you are currently reading also uses the concept template.
## Task template
diff --git a/content/en/docs/contribute/style/style-guide.md b/content/en/docs/contribute/style/style-guide.md
index 516b57a208..8cd5e14337 100644
--- a/content/en/docs/contribute/style/style-guide.md
+++ b/content/en/docs/contribute/style/style-guide.md
@@ -19,7 +19,7 @@ docs, follow the instructions on
{{% capture body %}}
{{< note >}}
-**Note:** Kubernetes documentation uses [Blackfriday Markdown Renderer](https://github.com/russross/blackfriday) along with a few [Hugo Shortcodes](/docs/home/contribute/includes/) to support glossary entries, tabs,
+Kubernetes documentation uses [Blackfriday Markdown Renderer](https://github.com/russross/blackfriday) along with a few [Hugo Shortcodes](/docs/home/contribute/includes/) to support glossary entries, tabs,
and representing feature state.
{{< /note >}}
@@ -189,7 +189,8 @@ A list of Kubernetes-specific terms and words to be used consistently across the
## Shortcodes
-Hugo [Shortcodes](https://gohugo.io/content-management/shortcodes) help create different rhetorical appeal levels. Our documentation supports three different shortcodes in this category: **Note:** {{* note */>}}, **Caution:** {{* caution */>}}, and **Warning:** {{* warning */>}}.
+
+Hugo [Shortcodes](https://gohugo.io/content-management/shortcodes) help create different rhetorical appeal levels. Our documentation supports three different shortcodes in this category: **Note** {{* note */>}}, **Caution** {{* caution */>}}, and **Warning** {{* warning */>}}.
1. Surround the text with an opening and closing shortcode.
@@ -197,7 +198,7 @@ Hugo [Shortcodes](https://gohugo.io/content-management/shortcodes) help create d
```
{{* note */>}}
- **Note:** The prefix you use is the same text you use in the tag.
+ No need to include a prefix; the shortcode automatically provides on (Note:, Caution:, etc.).
{{* /note */>}}
```
@@ -205,7 +206,7 @@ Hugo [Shortcodes](https://gohugo.io/content-management/shortcodes) help create d
The output is:
{{< note >}}
-**Note:** The prefix you choose is the same text for the tag.
+The prefix you choose is the same text for the tag.
{{< /note >}}
### Note
@@ -216,14 +217,14 @@ For example:
```
{{* note */>}}
-**Note:** You can _still_ use Markdown inside these callouts.
+You can _still_ use Markdown inside these callouts.
{{* /note */>}}
```
The output is:
{{< note >}}
-**Note:** You can _still_ use Markdown inside these callouts.
+You can _still_ use Markdown inside these callouts.
{{< /note >}}
### Caution
@@ -234,14 +235,14 @@ For example:
```
{{* caution */>}}
-**Caution:** The callout style only applies to the line directly above the tag.
+The callout style only applies to the line directly above the tag.
{{* /caution */>}}
```
The output is:
{{< caution >}}
-**Caution:** The callout style only applies to the line directly above the tag.
+The callout style only applies to the line directly above the tag.
{{< /caution >}}
### Warning
@@ -252,7 +253,7 @@ For example:
```
{{* warning */>}}
-**Warning:** Beware.
+Beware.
{{* /warning */>}}
```
@@ -260,7 +261,7 @@ For example:
The output is:
{{< warning >}}
-**Warning:** Beware.
+Beware.
{{< /warning >}}
### Katacoda Embedded Live Environment
@@ -273,7 +274,7 @@ The Embedded Live Environment is configured to run `minikube start` and lets use
as the documentation.
{{< caution >}}
-**Caution:** The session is limited to 15 minutes.
+The session is limited to 15 minutes.
{{< /caution >}}
For example:
@@ -306,7 +307,8 @@ The output is:
1. Preheat oven to 350˚F
1. Prepare the batter, and pour into springform pan.
- {{< note >}}**Note:** Grease the pan for best results.{{< /note >}}
+
+ {{< note >}}Grease the pan for best results.{{< /note >}}
1. Bake for 20-25 minutes or until set.
diff --git a/content/en/docs/contribute/style/write-new-topic.md b/content/en/docs/contribute/style/write-new-topic.md
index 5980b0d24e..4c92eb25f3 100644
--- a/content/en/docs/contribute/style/write-new-topic.md
+++ b/content/en/docs/contribute/style/write-new-topic.md
@@ -137,7 +137,7 @@ file located at `/content/en/examples/pods/storage/gce-volume.yaml`.
```
{{< note >}}
-**Note**: To show raw Hugo shortcodes as in the above example and prevent Hugo
+To show raw Hugo shortcodes as in the above example and prevent Hugo
from interpreting them, use C-style comments directly after the `<` and before
the `>` characters. View the code for this page for an example.
{{< /note >}}
@@ -155,7 +155,7 @@ kubectl create -f https://k8s.io/examples/pods/storage/gce-volume.yaml
```
{{< note >}}
-**Note**: When adding new YAML files to the `/examples` directory, make
+When adding new YAML files to the `/examples` directory, make
sure the file is also included into the `/examples_test.go` file. The
Travis CI for the Website automatically runs this test case when PRs are
submitted to ensure all examples pass the tests.
diff --git a/content/en/docs/doc-contributor-tools/snippets/atom-snippets.cson b/content/en/docs/doc-contributor-tools/snippets/atom-snippets.cson
index 0f7b78f030..5d4573938b 100644
--- a/content/en/docs/doc-contributor-tools/snippets/atom-snippets.cson
+++ b/content/en/docs/doc-contributor-tools/snippets/atom-snippets.cson
@@ -90,7 +90,7 @@
'prefix': 'anote'
'body': """
{{< note >}}
- **Note**: $1
+ $1
{{< /note >}}
"""
@@ -99,14 +99,14 @@
'prefix': 'acaution'
'body': """
{{< caution >}}
- **Caution**: $1
+ $1
{{< /caution >}}
"""
'Insert warning':
'prefix': 'awarning'
'body': """
{{< warning >}}
- **Warning**: $1
+ $1
{{< /warning >}}
"""
diff --git a/content/en/docs/getting-started-guides/fedora/fedora_manual_config.md b/content/en/docs/getting-started-guides/fedora/fedora_manual_config.md
index cbe029dfa2..7a338b1abc 100644
--- a/content/en/docs/getting-started-guides/fedora/fedora_manual_config.md
+++ b/content/en/docs/getting-started-guides/fedora/fedora_manual_config.md
@@ -124,6 +124,8 @@ KUBELET_ARGS="--cgroup-driver=systemd --kubeconfig=/etc/kubernetes/master-kubeco
```
+* Edit `/etc/kubernetes/master-kubeconfig.yaml` to contain the following information:
+
```yaml
kind: Config
clusters:
diff --git a/content/en/docs/getting-started-guides/fedora/flannel_multi_node_cluster.md b/content/en/docs/getting-started-guides/fedora/flannel_multi_node_cluster.md
index 12a032bbbc..88ef0615fd 100644
--- a/content/en/docs/getting-started-guides/fedora/flannel_multi_node_cluster.md
+++ b/content/en/docs/getting-started-guides/fedora/flannel_multi_node_cluster.md
@@ -31,7 +31,9 @@ You need 2 or more machines with Fedora installed.
}
```
-**NOTE:** Choose an IP range that is *NOT* part of the public IP address range.
+{{< note >}}
+Choose an IP range that is *NOT* part of the public IP address range.
+{{< /note >}}
Add the configuration to the etcd server on fed-master.
@@ -71,7 +73,9 @@ FLANNEL_ETCD_KEY="/coreos.com/network"
FLANNEL_OPTIONS=""
```
-**Note:** By default, flannel uses the interface for the default route. If you have multiple interfaces and would like to use an interface other than the default route one, you could add "-iface=" to FLANNEL_OPTIONS. For additional options, run `flanneld --help` on command line.
+{{< note >}}
+By default, flannel uses the interface for the default route. If you have multiple interfaces and would like to use an interface other than the default route one, you could add "-iface=" to FLANNEL_OPTIONS. For additional options, run `flanneld --help` on command line.
+{{< /note >}}
Enable the flannel service.
diff --git a/content/en/docs/getting-started-guides/ubuntu/backups.md b/content/en/docs/getting-started-guides/ubuntu/backups.md
index 226072ceb3..164949d24b 100644
--- a/content/en/docs/getting-started-guides/ubuntu/backups.md
+++ b/content/en/docs/getting-started-guides/ubuntu/backups.md
@@ -117,6 +117,7 @@ juju run-action new-etcd/0 restore
{{% /capture %}}
{{% capture discussion %}}
+
## Known Limitations
#### Loss of PKI warning
@@ -126,10 +127,9 @@ all TLS pki will be lost. No PKI migration occurs outside
of the units requesting and registering the certificates.
{{< caution >}}
-**Caution:** Mismanaging this configuration will result in locking yourself
-out of the cluster, and can potentially break existing deployments in very
-strange ways relating to x509 validation of certificates, which affects both
-servers and clients.
+Mismanaging this configuration will result in locking yourself out of the cluster,
+and can potentially break existing deployments in very strange ways relating to x509
+validation of certificates, which affects both servers and clients.
{{< /caution >}}
#### Restoring from snapshot on a scaled cluster
diff --git a/content/en/docs/getting-started-guides/ubuntu/decommissioning.md b/content/en/docs/getting-started-guides/ubuntu/decommissioning.md
index 6eaa3c3391..04f5210251 100644
--- a/content/en/docs/getting-started-guides/ubuntu/decommissioning.md
+++ b/content/en/docs/getting-started-guides/ubuntu/decommissioning.md
@@ -12,7 +12,7 @@ This page shows you how to properly decommission a cluster.
This page assumes you have a working Juju deployed cluster.
{{< warning >}}
-**Warning:** By the time you've reached this step you should have backed up your workloads and pertinent data; this section is for the complete destruction of a cluster.
+By the time you've reached this step you should have backed up your workloads and pertinent data; this section is for the complete destruction of a cluster.
{{< /warning >}}
{{% /capture %}}
diff --git a/content/en/docs/getting-started-guides/ubuntu/networking.md b/content/en/docs/getting-started-guides/ubuntu/networking.md
index 843dd5f6e9..e3afca9e87 100644
--- a/content/en/docs/getting-started-guides/ubuntu/networking.md
+++ b/content/en/docs/getting-started-guides/ubuntu/networking.md
@@ -14,7 +14,7 @@ This page shows how the various network portions of a cluster work and how to co
This page assumes you have a working Juju deployed cluster.
{{< note >}}
-**Note:** Note that if you deploy a cluster via conjure-up or the CDK bundles, manually deploying CNI plugins is unnecessary.
+Note that if you deploy a cluster via conjure-up or the CDK bundles, manually deploying CNI plugins is unnecessary.
{{< /note >}}
{{% /capture %}}
diff --git a/content/en/docs/getting-started-guides/ubuntu/storage.md b/content/en/docs/getting-started-guides/ubuntu/storage.md
index 008df52219..8a93e53a45 100644
--- a/content/en/docs/getting-started-guides/ubuntu/storage.md
+++ b/content/en/docs/getting-started-guides/ubuntu/storage.md
@@ -43,8 +43,11 @@ loop loop
rootfs rootfs
tmpfs tmpfs
```
-> **Note**: This listing is for the Amazon Web Services public cloud.
-> Different clouds may have different pool names.
+
+{{< note >}}
+This listing is for the Amazon Web Services public cloud. Different clouds may have
+different pool names.
+{{< /note >}}
Add a storage pool to the ceph-osd charm by NAME,SIZE,COUNT:
diff --git a/content/en/docs/getting-started-guides/ubuntu/upgrades.md b/content/en/docs/getting-started-guides/ubuntu/upgrades.md
index 0af5398ba2..b34108c2c0 100644
--- a/content/en/docs/getting-started-guides/ubuntu/upgrades.md
+++ b/content/en/docs/getting-started-guides/ubuntu/upgrades.md
@@ -11,7 +11,7 @@ This page will outline how to manage and execute a Kubernetes upgrade.
This page assumes you have a working deployed cluster.
{{< warning >}}
-**Warning:** You should always back up all your data before attempting an upgrade.
+You should always back up all your data before attempting an upgrade.
Don't forget to include the workload inside your cluster!
Refer to the [backup documentation](/docs/getting-started-guides/ubuntu/backups).
{{< /warning >}}
@@ -83,7 +83,7 @@ First you need to upgrade the masters:
juju upgrade-charm kubernetes-master
{{< note >}}
-**Note:** Always upgrade the masters before the workers.
+Always upgrade the masters before the workers.
{{< /note >}}
Once the latest charm is deployed, the channel for Kubernetes can be selected by issuing the following:
diff --git a/content/en/docs/getting-started-guides/ubuntu/validation.md b/content/en/docs/getting-started-guides/ubuntu/validation.md
index 611eed8222..c61c1ec4be 100644
--- a/content/en/docs/getting-started-guides/ubuntu/validation.md
+++ b/content/en/docs/getting-started-guides/ubuntu/validation.md
@@ -90,7 +90,7 @@ a deployed cluster. The following example will skip the `Flaky`, `Slow`, and
juju run-action kubernetes-e2e/0 test skip='\[(Flaky|Slow|Feature:.*)\]'
{{< note >}}
-**Note:** The escaping of the regex due to how bash handles brackets.
+The escaping of the regex due to how bash handles brackets.
{{< /note >}}
To see the different types of tests the Kubernetes end-to-end charm has access
@@ -112,7 +112,7 @@ command, as well as a flat file on disk on the `kubernetes-e2e` unit that
executed the test.
{{< note >}}
-**Note:** The results will only be available once the action has
+The results will only be available once the action has
completed the test run. End-to-end testing can be quite time consuming, often
taking more than 1 hour, depending on configuration.
{{< /note >}}
diff --git a/content/en/docs/getting-started-guides/windows/_index.md b/content/en/docs/getting-started-guides/windows/_index.md
index 5efb00af98..5243a6ccfb 100644
--- a/content/en/docs/getting-started-guides/windows/_index.md
+++ b/content/en/docs/getting-started-guides/windows/_index.md
@@ -3,7 +3,7 @@ title: Using Windows Server Containers in Kubernetes
toc_hide: true
---
{{< note >}}
-**Note:** These instructions were recently updated based on Windows Server platform enhancements and the Kubernetes v1.9 release
+These instructions were recently updated based on Windows Server platform enhancements and the Kubernetes v1.9 release
{{< /note >}}
Kubernetes version 1.5 introduced Alpha support for Windows Server
@@ -23,7 +23,7 @@ Containers on Kubernetes include:
The Kubernetes control plane (API Server, Scheduler, Controller Manager, etc) continue to run on Linux, while the kubelet and kube-proxy can be run on Windows Server 2016 or later
{{< note >}}
-**Note:** Windows Server Containers on Kubernetes is a Beta feature in Kubernetes v1.9
+Windows Server Containers on Kubernetes is a Beta feature in Kubernetes v1.9
{{< /note >}}
## Get Windows Binaries
@@ -159,7 +159,7 @@ Note: this file assumes that a user previous created 'l2bridge' host networks on
#### For 3. Open vSwitch (OVS) & Open Virtual Network (OVN) with Overlay
{{< note >}}
-**Note:** Fully automated setup via Ansible playbooks is [available](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib).
+Fully automated setup via Ansible playbooks is [available](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib).
{{< /note >}}
For manual setup, continue the following steps.
@@ -264,7 +264,7 @@ Because your cluster has both Linux and Windows nodes, you must explicitly set t
{{< codenew file="windows/simple-pod.yaml" >}}
{{< note >}}
-**Note:** This example assumes you are running on Windows Server 1709, so uses the image tag to support that. If you are on a different version, you will need to update the tag. For example, if on Windows Server 2016, update to use `"image": "microsoft/iis"` which will default to that OS version.
+This example assumes you are running on Windows Server 1709, so uses the image tag to support that. If you are on a different version, you will need to update the tag. For example, if on Windows Server 2016, update to use `"image": "microsoft/iis"` which will default to that OS version.
{{< /note >}}
### Secrets and ConfigMaps
@@ -365,7 +365,7 @@ Some of these limitations will be addressed by the community in future releases
- Under the networking models of L3 or Host GW, Kubernetes Services are inaccessible to Windows nodes due to a Windows issue. This is not an issue if using OVN/OVS for networking.
- Windows kubelet.exe may fail to start when running on Windows Server under VMware Fusion [issue 57110](https://github.com/kubernetes/kubernetes/pull/57124)
- Flannel and Weavenet are not yet supported
-- Some .Net Core applications expect environment variables with a colon (`:`) in the name. Kubernetes currently does not allow this. Replace colon (`:`) with double underscore (`__`) as documented [here](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?tabs=basicconfiguration#configuration-by-environment).
+- Some .Net Core applications expect environment variables with a colon (`:`) in the name. Kubernetes currently does not allow this. Replace colon (`:`) with double underscore (`__`) as documented [here](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?tabs=basicconfiguration#configuration-by-environment).
- As cgroups are not supported on windows, kubelet.exe should be started with the following additional arguments `--cgroups-per-qos=false --enforce-node-allocatable=""` [issue 61716](https://github.com/kubernetes/kubernetes/issues/61716)
## Next steps and resources
diff --git a/content/en/docs/home/_index.md b/content/en/docs/home/_index.md
index 7f6b94a122..c385c17780 100644
--- a/content/en/docs/home/_index.md
+++ b/content/en/docs/home/_index.md
@@ -11,6 +11,7 @@ display_browse_numbers: true
linkTitle: "Home"
main_menu: true
weight: 10
+hide_feedback: true
menu:
main:
title: "Documentation"
diff --git a/content/en/docs/reference/_index.md b/content/en/docs/reference/_index.md
index 56dfb08920..b5e825bc7f 100644
--- a/content/en/docs/reference/_index.md
+++ b/content/en/docs/reference/_index.md
@@ -35,6 +35,8 @@ client libraries:
- [Kubernetes Go client library](https://github.com/kubernetes/client-go/)
- [Kubernetes Python client library](https://github.com/kubernetes-client/python)
+- [Kubernetes Java client library](https://github.com/kubernetes-client/java)
+- [Kubernetes JavaScript client library](https://github.com/kubernetes-client/javascript)
## CLI Reference
diff --git a/content/en/docs/reference/access-authn-authz/abac.md b/content/en/docs/reference/access-authn-authz/abac.md
index 67ab051408..9174027776 100644
--- a/content/en/docs/reference/access-authn-authz/abac.md
+++ b/content/en/docs/reference/access-authn-authz/abac.md
@@ -49,12 +49,14 @@ properties:
- `/foo/*` matches all subpaths of `/foo/`.
- `readonly`, type boolean, when true, means that the Resource-matching policy only applies to get, list, and watch operations, Non-resource-matching policy only applies to get operation.
-**NOTES:** An unset property is the same as a property set to the zero value for its type
+{{< note >}}
+An unset property is the same as a property set to the zero value for its type
(e.g. empty string, 0, false). However, unset should be preferred for
readability.
In the future, policies may be expressed in a JSON format, and managed via a
REST interface.
+{{< /note >}}
## Authorization Algorithm
diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md
index 9eee5a89e8..95a29497eb 100644
--- a/content/en/docs/reference/access-authn-authz/admission-controllers.md
+++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md
@@ -66,11 +66,11 @@ kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger ...
```
{{< note >}}
-**Note**: Depending on the way your Kubernetes cluster is deployed and how the
-API server is started, you may need to apply the settings in different ways.
-For example, you may have to modify the systemd unit file if the API server is
-deployed as a systemd service, you may modify the manifest file for the API
-server if Kubernetes is deployed in a self-hosted way.
+Depending on the way your Kubernetes cluster is deployed and how the API server is
+started, you may need to apply the settings in different ways. For example, you may
+have to modify the systemd unit file if the API server is deployed as a systemd
+service, you may modify the manifest file for the API server if Kubernetes is deployed
+in a self-hosted way.
{{< /note >}}
## How do I turn off an admission controller?
@@ -489,7 +489,7 @@ plugin configuration file as the node selector.
Conflicts result in rejection.
{{< note >}}
-**Note:** PodNodeSelector allows forcing pods to run on specifically labeled nodes. Also see the PodTolerationRestriction
+PodNodeSelector allows forcing pods to run on specifically labeled nodes. Also see the PodTolerationRestriction
admission plugin, which allows preventing pods from running on specifically tainted nodes.
{{< /note >}}
@@ -498,7 +498,7 @@ admission plugin, which allows preventing pods from running on specifically tain
This admission controller implements additional validations for checking incoming `PersistentVolumeClaim` resize requests.
{{< note >}}
-**Note:** Support for volume resizing is available as an alpha feature. Admins must set the feature gate `ExpandPersistentVolumes`
+Support for volume resizing is available as an alpha feature. Admins must set the feature gate `ExpandPersistentVolumes`
to `true` to enable resizing.
{{< /note >}}
@@ -610,7 +610,7 @@ Yes.
For Kubernetes version 1.10 and later, we recommend running the following set of admission controllers using the `--enable-admission-plugins` flag (**order doesn't matter**).
{{< note >}}
-**Note:** `--admission-control` was deprecated in 1.10 and replaced with `--enable-admission-plugins`.
+`--admission-control` was deprecated in 1.10 and replaced with `--enable-admission-plugins`.
{{< /note >}}
```shell
diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md
index 9159b7c68d..1828be30b2 100644
--- a/content/en/docs/reference/access-authn-authz/authentication.md
+++ b/content/en/docs/reference/access-authn-authz/authentication.md
@@ -97,7 +97,7 @@ The token file is a csv file with a minimum of 3 columns: token, user name, user
followed by optional group names.
{{< note >}}
-**Note:** If you have more than one group the column must be double quoted e.g.
+If you have more than one group the column must be double quoted e.g.
```conf
token,user,uid,"group1,group2,group3"
@@ -137,7 +137,7 @@ Authorization: Bearer 781292.db7bc3a58fc5f07e
```
You must enable the Bootstrap Token Authenticator with the
-`--experimental-bootstrap-token-auth` flag on the API Server. You must enable
+`--enable-bootstrap-token-auth` flag on the API Server. You must enable
the TokenCleaner controller via the `--controllers` flag on the Controller
Manager. This is done with something like `--controllers=*,tokencleaner`.
`kubeadm` will do this for you if you are using it to bootstrap a cluster.
@@ -190,7 +190,7 @@ talk to the API server. Accounts may be explicitly associated with pods using th
`serviceAccountName` field of a `PodSpec`.
{{< note >}}
-**Note:** `serviceAccountName` is usually omitted because this is done automatically.
+`serviceAccountName` is usually omitted because this is done automatically.
{{< /note >}}
```yaml
@@ -246,7 +246,7 @@ type: kubernetes.io/service-account-token
```
{{< note >}}
-**Note:** Values are base64 encoded because secrets are always base64 encoded.
+Values are base64 encoded because secrets are always base64 encoded.
{{< /note >}}
The signed JWT can be used as a bearer token to authenticate as the given service
@@ -510,8 +510,9 @@ It is designed for use in combination with an authenticating proxy, which sets t
* `--requestheader-username-headers` Required, case-insensitive. Header names to check, in order, for the user identity. The first header containing a value is used as the username.
* `--requestheader-group-headers` 1.6+. Optional, case-insensitive. "X-Remote-Group" is suggested. Header names to check, in order, for the user's groups. All values in all specified headers are used as group names.
* `--requestheader-extra-headers-prefix` 1.6+. Optional, case-insensitive. "X-Remote-Extra-" is suggested. Header prefixes to look for to determine extra information about the user (typically used by the configured authorization plugin). Any headers beginning with any of the specified prefixes have the prefix removed. The remainder of the header name is lowercased and [percent-decoded](https://tools.ietf.org/html/rfc3986#section-2.1) and becomes the extra key, and the header value is the extra value.
+
{{< note >}}
-**Note:** Prior to 1.11.3 (and 1.10.7, 1.9.11), the extra key could only contain characters which were [legal in HTTP header labels](https://tools.ietf.org/html/rfc7230#section-3.2.6).
+Prior to 1.11.3 (and 1.10.7, 1.9.11), the extra key could only contain characters which were [legal in HTTP header labels](https://tools.ietf.org/html/rfc7230#section-3.2.6).
{{< /note >}}
For example, with this configuration:
@@ -601,7 +602,7 @@ The following HTTP headers can be used to performing an impersonation request:
* `Impersonate-Extra-( extra name )`: A dynamic header used to associate extra fields with the user. Optional. Requires "Impersonate-User". In order to be preserved consistently, `( extra name )` should be lower-case, and any characters which aren't [legal in HTTP header labels](https://tools.ietf.org/html/rfc7230#section-3.2.6) MUST be utf8 and [percent-encoded](https://tools.ietf.org/html/rfc3986#section-2.1).
{{< note >}}
-**Note:** Prior to 1.11.3 (and 1.10.7, 1.9.11), `( extra name )` could only contain characters which were [legal in HTTP header labels](https://tools.ietf.org/html/rfc7230#section-3.2.6).
+Prior to 1.11.3 (and 1.10.7, 1.9.11), `( extra name )` could only contain characters which were [legal in HTTP header labels](https://tools.ietf.org/html/rfc7230#section-3.2.6).
{{< /note >}}
An example set of headers:
diff --git a/content/en/docs/reference/access-authn-authz/authorization.md b/content/en/docs/reference/access-authn-authz/authorization.md
index 09212d0a63..366fbefe21 100644
--- a/content/en/docs/reference/access-authn-authz/authorization.md
+++ b/content/en/docs/reference/access-authn-authz/authorization.md
@@ -168,12 +168,11 @@ secrets the user cannot themselves read, or that run under a service account
with different/greater permissions.
{{< caution >}}
-**Caution:** System administrators, use care when granting access to pod
-creation. A user granted permission to create pods (or controllers that create
-pods) in the namespace can: read all secrets in the namespace; read all config
-maps in the namespace; and impersonate any service account in the namespace and
-take any action the account could take. This applies regardless of authorization
-mode.
+System administrators, use care when granting access to pod creation. A user
+granted permission to create pods (or controllers that create pods) in the
+namespace can: read all secrets in the namespace; read all config maps in the
+namespace; and impersonate any service account in the namespace and take any
+action the account could take. This applies regardless of authorization mode.
{{< /caution >}}
{{% /capture %}}
diff --git a/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md b/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md
index 736461481d..a4b0e5073d 100644
--- a/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md
+++ b/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md
@@ -179,7 +179,7 @@ verify the JWS using the `HS256` scheme (HMAC-SHA256) with the full token (e.g.
is used.
{{< warning >}}
-**Warning:** Any party with a bootstrapping token can create a valid signature for that
+Any party with a bootstrapping token can create a valid signature for that
token. When using ConfigMap signing it's discouraged to share the same token with
many clients, since a compromised client can potentially man-in-the middle another
client relying on the signature to bootstrap TLS trust.
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 518e57ef89..4d6fde6a00 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
@@ -120,7 +120,7 @@ webhooks:
```
{{< note >}}
-**Note:** When using `clientConfig.service`, the server cert must be valid for
+When using `clientConfig.service`, the server cert must be valid for
`..svc`.
{{< /note >}}
@@ -132,7 +132,7 @@ After you create the webhook configuration, the system will take a few seconds
to honor the new configuration.
{{< note >}}
-**Note:** When the webhook plugin is deployed into the Kubernetes cluster as a
+When the webhook plugin is deployed into the Kubernetes cluster as a
service, it has to expose its service on the 443 port. The communication
between the API server and the webhook service may fail if a different port
is used.
@@ -228,7 +228,7 @@ admission controller), or to inject defaults (e.g., the
admission controller), etc.
{{< note >}}
-**Note:** If your use case does not involve mutating objects, consider using
+If your use case does not involve mutating objects, consider using
external admission webhooks, as they have better performance.
{{< /note >}}
diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md
index ca674e9343..719164c5ec 100644
--- a/content/en/docs/reference/access-authn-authz/rbac.md
+++ b/content/en/docs/reference/access-authn-authz/rbac.md
@@ -807,7 +807,7 @@ In order from most secure to least secure, the approaches are:
If an application does not specify a `serviceAccountName`, it uses the "default" service account.
- {{< note >}}**Note:** Permissions given to the "default" service
+ {{< note >}}Permissions given to the "default" service
account are available to any pod in the namespace that does not
specify a `serviceAccountName`.{{< /note >}}
@@ -823,7 +823,7 @@ In order from most secure to least secure, the approaches are:
Many [add-ons](/docs/concepts/cluster-administration/addons/) currently run as the "default" service account in the `kube-system` namespace.
To allow those add-ons to run with super-user access, grant cluster-admin permissions to the "default" service account in the `kube-system` namespace.
- {{< note >}}**Note:** Enabling this means the `kube-system`
+ {{< note >}}Enabling this means the `kube-system`
namespace contains secrets that grant super-user access to the
API.{{< /note >}}
@@ -863,9 +863,11 @@ In order from most secure to least secure, the approaches are:
If you don't care about partitioning permissions at all, you can grant super-user access to all service accounts.
- {{< warning >}}**Warning:** This allows any user with read access
+ {{< warning >}}
+ This allows any user with read access
to secrets or the ability to create a pod to access super-user
- credentials.{{< /warning >}}
+ credentials.
+ {{< /warning >}}
```shell
kubectl create clusterrolebinding serviceaccounts-cluster-admin \
@@ -909,7 +911,7 @@ in the server logs, you can remove the ABAC authorizer.
You can replicate a permissive policy using RBAC role bindings.
{{< warning >}}
-**Warning:** The following policy allows **ALL** service accounts to act as cluster administrators.
+The following policy allows **ALL** service accounts to act as cluster administrators.
Any application running in a container receives service account credentials automatically,
and could perform any action against the API, including viewing secrets and modifying permissions.
This is not a recommended policy.
diff --git a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md b/content/en/docs/reference/access-authn-authz/service-accounts-admin.md
index 932f9fb225..7e030903bc 100644
--- a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md
+++ b/content/en/docs/reference/access-authn-authz/service-accounts-admin.md
@@ -23,14 +23,14 @@ incomplete features are referred to in order to better describe service accounts
Kubernetes distinguishes between the concept of a user account and a service account
for a number of reasons:
- - User accounts are for humans. Service accounts are for processes, which
+ - User accounts are for humans. Service accounts are for processes, which
run in pods.
- User accounts are intended to be global. Names must be unique across all
namespaces of a cluster, future user resource will not be namespaced.
Service accounts are namespaced.
- Typically, a cluster's User accounts might be synced from a corporate
database, where new user account creation requires special privileges and
- is tied to complex business processes. Service account creation is intended
+ is tied to complex business processes. Service account creation is intended
to be more lightweight, allowing cluster users to create service accounts for
specific tasks (i.e. principle of least privilege).
- Auditing considerations for humans and service accounts may differ.
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 e001488653..9726848ee2 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,13 +38,17 @@ different Kubernetes components.
| `APIListChunking` | `true` | Beta | 1.9 | |
| `APIResponseCompression` | `false` | Alpha | 1.7 | |
| `AppArmor` | `true` | Beta | 1.4 | |
-| `AttachVolumeLimit` | `true` | Alpha | 1.11 | |
+| `AttachVolumeLimit` | `true` | Alpha | 1.11 | 1.11 |
+| `AttachVolumeLimit` | `true` | Beta | 1.12 | |
| `BlockVolume` | `false` | Alpha | 1.9 | |
+| `CPUCFSQuotaPeriod` | `false` | Alpha | 1.12 | |
| `CPUManager` | `false` | Alpha | 1.8 | 1.9 |
| `CPUManager` | `true` | Beta | 1.10 | |
| `CRIContainerLogRotation` | `false` | Alpha | 1.10 | 1.10 |
| `CRIContainerLogRotation` | `true` | Beta| 1.11 | |
-| `CSIBlockVolume` | `false` | Alpha | 1.11 | 1.11 |
+| `CSIBlockVolume` | `false` | Alpha | 1.11 | |
+| `CSIDriverRegistry` | `false` | Alpha | 1.12 | |
+| `CSINodeInfo` | `false` | Alpha | 1.12 | |
| `CSIPersistentVolume` | `false` | Alpha | 1.9 | 1.9 |
| `CSIPersistentVolume` | `true` | Beta | 1.10 | |
| `CustomPodDNS` | `false` | Alpha | 1.9 | 1.9 |
@@ -55,6 +59,7 @@ different Kubernetes components.
| `DebugContainers` | `false` | Alpha | 1.10 | |
| `DevicePlugins` | `false` | Alpha | 1.8 | 1.9 |
| `DevicePlugins` | `true` | Beta | 1.10 | |
+| `DynamicAuditing` | `false` | Alpha | 1.13 | |
| `DynamicKubeletConfig` | `false` | Alpha | 1.4 | 1.10 |
| `DynamicKubeletConfig` | `true` | Beta | 1.11 | |
| `DynamicProvisioningScheduling` | `false` | Alpha | 1.11 | 1.11 |
@@ -80,6 +85,7 @@ different Kubernetes components.
| `MountPropagation` | `false` | Alpha | 1.8 | 1.9 |
| `MountPropagation` | `true` | Beta | 1.10 | 1.11 |
| `MountPropagation` | `true` | GA | 1.12 | |
+| `NodeLease` | `false` | Alpha | 1.12 | |
| `PersistentLocalVolumes` | `false` | Alpha | 1.7 | 1.9 |
| `PersistentLocalVolumes` | `true` | Beta | 1.10 | |
| `PodPriority` | `false` | Alpha | 1.8 | |
@@ -87,11 +93,14 @@ different Kubernetes components.
| `PodReadinessGates` | `true` | Beta | 1.12 | |
| `PodShareProcessNamespace` | `false` | Alpha | 1.10 | |
| `PodShareProcessNamespace` | `true` | Beta | 1.12 | |
+| `ProcMountType` | `false` | Alpha | 1.12 | |
| `PVCProtection` | `false` | Alpha | 1.9 | 1.9 |
-| `ReadOnlyAPIDataVolumes` | `true` | Deprecated | 1.10 | |
| `ResourceLimitsPriorityFunction` | `false` | Alpha | 1.9 | |
+| `ResourceQuotaScopeSelectors` | `false` | Alpha | 1.11 | 1.11 |
+| `ResourceQuotaScopeSelectors` | `true` | Beta | 1.12 | |
| `RotateKubeletClientCertificate` | `true` | Beta | 1.7 | |
-| `RotateKubeletServerCertificate` | `false` | Alpha | 1.7 | |
+| `RotateKubeletServerCertificate` | `false` | Alpha | 1.7 | 1.11 |
+| `RotateKubeletServerCertificate` | `true` | Beta | 1.12 | |
| `RunAsGroup` | `false` | Alpha | 1.10 | |
| `RuntimeClass` | `false` | Alpha | 1.12 | |
| `SCTPSupport` | `false` | Alpha | 1.12 | |
@@ -116,6 +125,7 @@ different Kubernetes components.
| `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 |
| `VolumeScheduling` | `true` | Beta | 1.10 | |
| `VolumeSubpathEnvExpansion` | `false` | Alpha | 1.11 | |
+| `VolumeSnapshotDataSource` | `false` | Alpha | 1.12 | |
| `ScheduleDaemonSetPods` | `true` | Beta | 1.12 | |
## Using a Feature
@@ -147,7 +157,7 @@ A *Beta* feature means:
that can be upgraded independently, you may be able to relax this restriction.
{{< note >}}
-**Note:** Please do try *Beta* features and give feedback on them!
+Please do try *Beta* features and give feedback on them!
After they exit beta, it may not be practical for us to make more changes.
{{< /note >}}
@@ -174,9 +184,12 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `BlockVolume`: Enable the definition and consumption of raw block devices in Pods.
See [Raw Block Volume Support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)
for more details.
+- `CPUCFSQuotaPeriod`: Enable nodes to change CPUCFSQuotaPeriod.
- `CPUManager`: Enable container level CPU affinity support, see [CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/).
- `CRIContainerLogRotation`: Enable container log rotation for cri container runtime.
- `CSIBlockVolume`: Enable external CSI volume drivers to support block storage. See the [`csi` raw block volume support](/docs/concepts/storage/volumes/#csi-raw-block-volume-support) documentation for more details.
+- `CSIDriverRegistry`: Enable all logic related to the CSIDriver API object in csi.storage.k8s.io.
+- `CSINodeInfo`: Enable all logic related to the CSINodeInfo API object in csi.storage.k8s.io.
- `CSIPersistentVolume`: Enable discovering and mounting volumes provisioned through a
[CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)
compatible volume plugin.
@@ -192,6 +205,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
troubleshoot a running Pod.
- `DevicePlugins`: Enable the [device-plugins](/docs/concepts/cluster-administration/device-plugins/)
based resource provisioning on nodes.
+- `DynamicAuditing`: Enable [dynamic auditing](/docs/tasks/debug-application-cluster/audit/#dynamic-backend)
- `DynamicKubeletConfig`: Enable the dynamic configuration of kubelet. See [Reconfigure kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet/).
- `DynamicProvisioningScheduling`: Extend the default scheduler to be aware of volume topology and handle PV provisioning.
This feature is superceded by the `VolumeScheduling` feature completely in v1.12.
@@ -219,21 +233,22 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `MountContainers`: Enable using utility containers on host as the volume mounter.
- `MountPropagation`: Enable sharing volume mounted by one container to other containers or pods.
For more details, please see [mount propagation](/docs/concepts/storage/volumes/#mount-propagation).
+- `NodeLease`: Enable the new Lease API to report node heartbeats, which could be used as a node health signal.
- `PersistentLocalVolumes`: Enable the usage of `local` volume type in Pods.
Pod affinity has to be specified if requesting a `local` volume.
- `PodPriority`: Enable the descheduling and preemption of Pods based on their [priorities](/docs/concepts/configuration/pod-priority-preemption/).
- `PodReadinessGates`: Enable the setting of `PodReadinessGate` field for extending
Pod readiness evaluation.
For more details, please see [Pod readiness gate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate).
+- `ProcMountType`: Enables control over ProcMountType for containers.
- `PVCProtection`: Enable the prevention of a PersistentVolumeClaim (PVC) from
being deleted when it is still used by any Pod.
More details can be found [here](/docs/tasks/administer-cluster/storage-object-in-use-protection/).
-- `ReadOnlyAPIDataVolumes`: Set Secret, ConfigMap, DownwardAPI and projected volumes to be mounted in read-only mode.
- This gate exists only for backward compatibility. It will be removed in 1.11 release.
- `ResourceLimitsPriorityFunction`: Enable a scheduler priority function that
assigns a lowest possible score of 1 to a node that satisfies at least one of
the input Pod's cpu and memory limits. The intent is to break ties between
nodes with same scores.
+- `ResourceQuotaScopeSelectors`: Enable resource quota scope selectors.
- `RotateKubeletClientCertificate`: Enable the rotation of the client TLS certificate on the kubelet.
See [kubelet configuration](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration) for more details.
- `RotateKubeletServerCertificate`: Enable the rotation of the server TLS certificate on the kubelet.
@@ -265,4 +280,6 @@ Each feature gate is designed for enabling/disabling a specific feature:
PersistentVolumeClaim (PVC) binding aware of scheduling decisions. It also
enables the usage of [`local`](/docs/concepts/storage/volumes/#local) volume
type when used together with the `PersistentLocalVolumes` feature gate.
+- `VolumeSnapshotDataSource`: Enable volume snapshot data source support.
+
{{% /capture %}}
diff --git a/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md b/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md
index fc52d55775..0b6b79f413 100644
--- a/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md
+++ b/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md
@@ -36,6 +36,12 @@ kube-scheduler [flags]
DEPRECATED: the IP address on which to listen for the --port port (set to 0.0.0.0 for all IPv4 interfaces and :: for all IPv6 interfaces). See --bind-address instead.
+
+
--bind-address string Default: "0.0.0.0"
+
+
+
The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank, all interfaces will be used (0.0.0.0 for all IPv4 interfaces and :: for all IPv6 interfaces).
+
--algorithm-provider string
@@ -198,6 +204,13 @@ kube-scheduler [flags]
DEPRECATED: the port on which to serve HTTP insecurely without authentication and authorization. If 0, don't serve HTTPS at all. See --secure-port instead.
+
+
--secure-port int Default: 10259
+
+
+
The port on which to serve HTTPS with authentication and authorization. If 0, don't serve HTTPS at all.
+
+
--profiling
diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md b/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md
index 192cf963d2..d5f479ff44 100644
--- a/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md
+++ b/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md
@@ -10,45 +10,160 @@ content_template: templates/concept
{{% capture overview %}}
-This document describes how to set up TLS client certificate bootstrapping for
-kubelets. Kubernetes 1.4 introduced an API for requesting certificates from a
-cluster-level Certificate Authority (CA). The original intent of this API is to
-enable provisioning of TLS client certificates for kubelets. The proposal can be
+In a Kubernetes cluster, the components on the worker nodes - kubelet and kube-proxy - need to communicate with Kubernetes master components, specifically kube-apiserver.
+In order to ensure that communication is kept private, not interfered with, and ensure that each component of the cluster is talking to another trusted component, we strongly
+recommend using client TLS certificates on nodes.
+
+The normal process of bootstrapping these components, especially worker nodes that need certificates so they can communicate safely with kube-apiserver,
+can be a challenging process as it is often outside of the scope of Kubernetes and requires significant additional work.
+This in turn, can make it challenging to initialize or scale a cluster.
+
+In order to simplify the process, beginning in version 1.4, Kubernetes introduced a certificate request and signing API to simplify the process. The proposal can be
found [here](https://github.com/kubernetes/kubernetes/pull/20439).
+This document describes the process of node initialization, how to set up TLS client certificate bootstrapping for
+kubelets, and how it works.
+
{{% /capture %}}
{{% capture body %}}
+## Initialization Process
+When a worker node starts up, the kubelet does the following:
+
+1. Look for its `kubeconfig` file
+2. Retrieve the URL of the API server and credentials, normally a TLS key and signed certificate from the `kubeconfig` file
+3. Attempt to communicate with the API server using the credentials.
+
+Assuming that the kube-apiserver successfully validates the kubelet's credentials, it will treat the kubelet as a valid node, and begin to assign pods to it.
+
+Note that the above process depends upon:
+
+* Existence of a key and certificate on the local host in the `kubeconfig`
+* The certificate having been signed by a Certificate Authority (CA) trusted by the kube-apiserver
+
+All of the following are responsibilities of whoever sets up and manages the cluster:
+
+1. Creating the CA key and certificate
+2. Distributing the CA certificate to the master nodes, where kube-apiserver is running
+3. Creating a key and certificate for each kubelet; strongly recommended to have a unique one, with a unique CN, for each kubelet
+4. Signing the kubelet certificate using the CA key
+5. Distributing the kubelet key and signed certificate to the specific node on which the kubelet is running
+
+The TLS Bootstrapping described in this document is intended to simplify, and partially or even completely automate, steps 3 onwards, as these are the most common when initializing or scaling
+a cluster.
+
+### Bootstrap Initialization
+In the bootstrap initialization process, the following occurs:
+
+1. kubelet begins
+2. kubelet sees that it does _not_ have a `kubeconfig` file
+3. kubelet searches for and finds a `bootstrap-kubeconfig` file
+4. kubelet reads its bootstrap file, retrieving the URL of the API server and a limited usage "token"
+5. kubelet connects to the API server, authenticates using the token
+6. kubelet now has limited credentials to create and retrieve a certificate signing request (CSR)
+7. kubelet creates a CSR for itself
+8. CSR is approved in one of two ways:
+ * If configured, kube-controller-manager automatically approves the CSR
+ * If configured, an outside process, possibly a person, approves the CSR using the Kubernetes API or via `kubectl`
+9. Certificate is created for the kubelet
+10. Certificate is issued to the kubelet
+11. kubelet retrieves the certificate
+12. kubelet creates a proper `kubeconfig` with the key and signed certificate
+13. kubelet begins normal operation
+14. Optional: if configured, kubelet automatically requests renewal of the certificate when it is close to expiry
+15. The renewed certificate is approved and issued, either automatically or manually, depending on configuration.
+
+The rest of this document describes the necessary steps to configure TLS Bootstrapping, and its limitations.
+
+## Configuration
+To configure for TLS bootstrapping and optional automatic approval, you must configure options on the following components:
+
+* kube-apiserver
+* kube-controller-manager
+* kubelet
+* in-cluster resources: `ClusterRoleBinding` and potentially `ClusterRole`
+
+In addition, you need your Kubernetes Certificate Authority (CA).
+
+## Certificate Authority
+As without bootstrapping, you will need a Certificate Authority (CA) key and certificate. As without bootstrapping, these will be used
+to sign the kubelet certificate. As before, it is your responsibility to distribute them to master nodes.
+
+For the purposes of this document, we will assume these have been distributed to master nodes at `/var/lib/kubernetes/ca.pem` (certificate) and `/var/lib/kubernetes/ca-key.pem` (key).
+We will refer to these as "Kubernetes CA certificate and key".
+
+All Kubernetes components that use these certificates - kubelet, kube-apiserver, kube-controller-manager - assume the key and certificate to be PEM-encoded.
+
## kube-apiserver configuration
+The kube-apiserver has several requirements to enable TLS bootstrapping:
-The API server should be configured with an
-[authenticator](/docs/reference/access-authn-authz/authentication/) that can
-authenticate tokens as a user in the `system:bootstrappers` group.
+* Recognizing CA that signs the client certificate
+* Authenticating the bootstrapping kubelet to the `system:bootstrappers` group
+* Authorize the bootstrapping kubelet to create a certificate signing request (CSR)
-This group will later be used in the controller-manager configuration to scope
-approvals in the default approval controller. As this feature matures, you
-should ensure tokens are bound to a Role Based Access Control (RBAC) policy
-which limits requests (using the [bootstrap
-token](/docs/reference/access-authn-authz/bootstrap-tokens/)) strictly to client
-requests related to certificate provisioning. With RBAC in place, scoping the
-tokens to a group allows for great flexibility (e.g. you could disable a
-particular bootstrap group's access when you are done provisioning the nodes).
+### Recognizing client certificates
+This is normal for all client certificate authentication.
+If not already set, add the `--client-ca-file=FILENAME` flag to the kube-apiserver command to enable
+client certificate authentication, referencing a certificate authority bundle
+containing the signing certificate, for example
+`--client-ca-file=/var/lib/kubernetes/ca.pem`.
+
+### Initial bootstrap authentication
+In order for the bootstrapping kubelet to connect to kube-apiserver and request a certificate, it must first authenticate to the server.
+You can use any [authenticator](https://kubernetes.io/docs/reference/access-authn-authz/authentication/) that can authenticate the kubelet.
While any authentication strategy can be used for the kubelet's initial
bootstrap credentials, the following two authenticators are recommended for ease
of provisioning.
-1. [Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) - __beta__
+1. [Bootstrap Tokens](#bootstrap-tokens) - __beta__
2. [Token authentication file](#token-authentication-file)
-Using bootstrap tokens is currently __beta__ and will simplify the management of
-bootstrap token management especially in a HA scenario.
+Bootstrap tokens are a simpler and more easily managed method to authenticate kubelets, and do not require any additional flags when starting kube-apiserver.
+Using bootstrap tokens is currently __beta__ as of Kubernetes version 1.12.
-### Token authentication file
+Whichever method you choose, the requirement is that the kubelet be able to authenticate as a user with the rights to:
-Tokens are arbitrary but should represent at least 128 bits of entropy derived
-from a secure random number generator (such as /dev/urandom on most modern Linux
+1. create and retrieve CSRs
+2. be automatically approved to request node client certificates, if automatic approval is enabled.
+
+A kubelet authenticating using bootstrap tokens is authenticated as a user in the group `system:bootstrappers`, which is the standard method to use.
+
+As this feature matures, you
+should ensure tokens are bound to a Role Based Access Control (RBAC) policy
+which limits requests (using the [bootstrap
+token](/docs/reference/access-authn-authz/bootstrap-tokens/)) strictly to client
+requests related to certificate provisioning. With RBAC in place, scoping the
+tokens to a group allows for great flexibility. For example, you could disable a
+particular bootstrap group's access when you are done provisioning the nodes.
+
+#### Bootstrap tokens
+Bootstrap tokens are described in detail [here](/docs/reference/access-authn-authz/bootstrap-tokens/). These are tokens that are stored as secrets in the Kubernetes cluster,
+and then issued to the individual kubelet. You can use a single token for an entire cluster, or issue one per worker node.
+
+The process is two-fold:
+
+1. Create a Kubernetes secret with the token ID, secret and scope(s).
+2. Issue the token to the kubelet
+
+From the kubelet's perspective, one token is like another and has no special meaning.
+From the kube-apiserver's perspective, however, the bootstrap token is special. Due to its `Type`, `namespace` and `name`, kube-apiserver recognizes it as a special token,
+and grants anyone authenticating with that token special bootstrap rights, notably treating them as a member of the `system:bootstrappers` group. This fulfills a basic requirement
+for TLS bootstrapping.
+
+The details for creating the secret are available [here](/docs/reference/access-authn-authz/bootstrap-tokens/).
+
+If you want to use bootstrap tokens, you must enable it on kube-apiserver with the flag:
+
+```
+--enable-bootstrap-token-auth=true
+```
+
+#### Token authentication file
+kube-apiserver has an ability to accept tokens as authentication.
+These tokens are arbitrary but should represent at least 128 bits of entropy derived
+from a secure random number generator (such as `/dev/urandom` on most modern Linux
systems). There are multiple ways you can generate a token. For example:
```
@@ -69,99 +184,78 @@ systemd unit file perhaps) to enable the token file. See docs
[here](/docs/reference/access-authn-authz/authentication/#static-token-file) for
further details.
-### Client certificate CA bundle
+### Authorize kubelet to create CSR
+Now that the bootstrapping node is _authenticated_ as part of the `system:bootstrappers` group, it needs to be _authorized_ to create a certificate signing request (CSR) as well as retrieve it when done. Fortunately, Kubernetes ships with a `ClusterRole` with precisely these (and just these) permissions, `system:node-bootstrapper`.
-Add the `--client-ca-file=FILENAME` flag to the kube-apiserver command to enable
-client certificate authentication, referencing a certificate authority bundle
-containing the signing certificate (e.g.
-`--client-ca-file=/var/lib/kubernetes/ca.pem`).
+To do this, you just need to create a `ClusterRoleBinding` that binds the `system:bootstrappers` group to the cluster role `system:node-bootstrapper`.
+
+```
+# enable bootstrapping nodes to create CSR
+kind: ClusterRoleBinding
+apiVersion: rbac.authorization.k8s.io/v1
+metadata:
+ name: create-csrs-for-bootstrapping
+subjects:
+- kind: Group
+ name: system:bootstrappers
+ apiGroup: rbac.authorization.k8s.io
+roleRef:
+ kind: ClusterRole
+ name: system:node-bootstrapper
+ apiGroup: rbac.authorization.k8s.io
+```
## kube-controller-manager configuration
+While the apiserver receives the requests for certificates from the kubelet and authenticates those requests,
+the controller-manager is responsible for issuing actual signed certificates.
-The API for requesting certificates adds a certificate-issuing control loop to
-the Kubernetes Controller Manager. This takes the form of a
+The controller-manager performs this function via a certificate-issuing control loop.
+This takes the form of a
[cfssl](https://blog.cloudflare.com/introducing-cfssl/) local signer using
assets on disk. Currently, all certificates issued have one year validity and a
default set of key usages.
-### Signing assets
+In order for the controller-manager to sign certificates, it needs the following:
-You must provide a Certificate Authority in order to provide the cryptographic
-materials necessary to issue certificates. This CA should be trusted by
-kube-apiserver for authentication with the `--client-ca-file=FILENAME` flag. The
-management of the CA is beyond the scope of this document but it is recommended
-that you generate a dedicated CA for Kubernetes. Both certificate and key are
-assumed to be PEM-encoded.
+* access to the "kuberetes CA key and certificate" that you created and distributed
+* enabling CSR signing
-The kube-controller-manager flags are:
+### Access to key and certificate
+As described earlier, you need to create a Kubernetes CA key and certificate, and distribute it to the master nodes.
+These will be used by the controller-manager to sign the kubelet certificates.
+
+Since these signed certificates will, in turn, be used by the kubelet to authenticate as a regular kubelet to kube-apiserver, it is important that the CA
+provided to the controller-manager at this stage also be trusted by kube-apiserver for authentication. This is provided to kube-apiserver
+with the flag `--client-ca-file=FILENAME` (for example, `--client-ca-file=/var/lib/kubernetes/ca.pem`), as described in the kube-apiserver configuration section.
+
+To provide the Kubernetes CA key and certificate to kube-controller-manager, use the following flags:
```
--cluster-signing-cert-file="/etc/path/to/kubernetes/ca/ca.crt" --cluster-signing-key-file="/etc/path/to/kubernetes/ca/ca.key"
```
+for example:
+
+```
+--cluster-signing-cert-file="/var/lib/kubernetes/ca.pem" --cluster-signing-key-file="/var/lib/kubernetes/ca-key.pem"
+```
+
The validity duration of signed certificates can be configured with flag:
```
--experimental-cluster-signing-duration
```
-### SubjectAccessReview Approval Controller
+### Approval
+In order to approve CSRs, you need to tell the controller-manager that it is acceptable to approve them. This is done by granting
+RBAC permissions to the correct group.
-The `csrapproving` controller that ships as part of
-[kube-controller-manager](/docs/admin/kube-controller-manager/) and is enabled
-by default. The controller uses the [`SubjectAccessReview`
-API](/docs/reference/access-authn-authz/authorization/#checking-api-access) to
-determine if a given user is authorized to request a CSR, then approves based on
-the authorization outcome. To prevent conflicts with other approvers, the
-builtin approver doesn't explicitly deny CSRs. It only ignores unauthorized
-requests. The controller also prunes expired certificates as part of garbage
-collection.
+There are two distinct sets of permissions:
-The controller categorizes CSRs into three subresources:
+* `nodeclient`: If a node is creating a new certificate for a node, then it does not have a certificate yet. It is authenticating using one of the tokens listed above, and thus is part of the group `system:bootstrappers`.
+* `selfnodeclient`: If a node is renewing its certificate, then it already has a certificate (by definition), which it uses continuously to authenticate as part of the group `system:nodes`.
-1. `nodeclient` - a request by a user for a client certificate with `O=system:nodes` and `CN=system:node:(node name)`.
-2. `selfnodeclient` - a node renewing a client certificate with the same `O` and `CN`. A node can use its existing client certificate to authenticate this request.
-
-The following RBAC `ClusterRoles` represent the `nodeclient` and
-`selfnodeclient`, capabilities.
-
-```yml
-# A ClusterRole which instructs the CSR approver to approve a user requesting
-# node client credentials.
-kind: ClusterRole
-apiVersion: rbac.authorization.k8s.io/v1
-metadata:
- name: approve-node-client-csr
-rules:
-- apiGroups: ["certificates.k8s.io"]
- resources: ["certificatesigningrequests/nodeclient"]
- verbs: ["create"]
----
-# A ClusterRole which instructs the CSR approver to approve a node renewing its
-# own client credentials.
-kind: ClusterRole
-apiVersion: rbac.authorization.k8s.io/v1
-metadata:
- name: approve-node-client-renewal-csr
-rules:
-- apiGroups: ["certificates.k8s.io"]
- resources: ["certificatesigningrequests/selfnodeclient"]
- verbs: ["create"]
-```
-
-As of 1.8, equivalent roles to the ones listed above are automatically created
-as part of the default RBAC roles. For 1.8 clusters admins are recommended to
-bind node bootstrap identities to the following roles instead of creating their
-own:
-
-* `system:certificates.k8s.io:certificatesigningrequests:nodeclient`
- - Automatically approve CSRs for client certs bound to this role.
-* `system:certificates.k8s.io:certificatesigningrequests:selfnodeclient`
- - Automatically approve CSRs when a client bound to its role renews its own certificate.
-
-For example, to grant these permissions to identities attached to bootstrap
-tokens, an admin would create a `ClusterRoleBinding` targeting the
-`system:bootstrappers` group:
+To enable the kubelet to request and receive a new certificate, create a `ClusterRoleBinding` that binds the group in which the bootstrapping node is a member `system:bootstrappers` to the `ClusterRole` that grants it permission, `system:certificates.k8s.io:certificatesigningrequests:nodeclient`:
```yml
# Approve all CSRs for the group "system:bootstrappers"
@@ -175,41 +269,126 @@ subjects:
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
- name: approve-node-client-csr
+ name: system:certificates.k8s.io:certificatesigningrequests:nodeclient
apiGroup: rbac.authorization.k8s.io
```
-To let all nodes renew their own credentials, an admin can create a
-`ClusterRoleBinding` targeting node identities:
+To enable the kubelet to renew its own client certificate, create a `ClusterRoleBinding` that binds the group in which the fully functioning node is a member `system:nodes` to the `ClusterRole` that
+grants it permission, `system:certificates.k8s.io:certificatesigningrequests:selfnodeclient`:
```yml
+# Approve renewal CSRs for the group "system:nodes"
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
- name: node1-client-cert-renewal
+ name: auto-approve-renewals-for-nodes
subjects:
- kind: Group
name: system:nodes
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
- name: approve-node-client-renewal-csr
+ name: system:certificates.k8s.io:certificatesigningrequests:selfnodeclient
apiGroup: rbac.authorization.k8s.io
```
+**Note: Kubernetes Below 1.8**: If you are running an earlier version of Kubernetes, notably a version below 1.8, then the cluster roles referenced above do not ship by default. You will have to create them yourself _in addition to_ the `ClusterRoleBindings` listed.
+
+To create the `ClusterRole`s:
+
+```yml
+# A ClusterRole which instructs the CSR approver to approve a user requesting
+# node client credentials.
+kind: ClusterRole
+apiVersion: rbac.authorization.k8s.io/v1
+metadata:
+ name: system:certificates.k8s.io:certificatesigningrequests:nodeclient
+rules:
+- apiGroups: ["certificates.k8s.io"]
+ resources: ["certificatesigningrequests/nodeclient"]
+ verbs: ["create"]
+---
+# A ClusterRole which instructs the CSR approver to approve a node renewing its
+# own client credentials.
+kind: ClusterRole
+apiVersion: rbac.authorization.k8s.io/v1
+metadata:
+ name: system:certificates.k8s.io:certificatesigningrequests:selfnodeclient
+rules:
+- apiGroups: ["certificates.k8s.io"]
+ resources: ["certificatesigningrequests/selfnodeclient"]
+ verbs: ["create"]
+```
+
+
+The `csrapproving` controller that ships as part of
+[kube-controller-manager](/docs/admin/kube-controller-manager/) and is enabled
+by default. The controller uses the [`SubjectAccessReview`
+API](/docs/reference/access-authn-authz/authorization/#checking-api-access) to
+determine if a given user is authorized to request a CSR, then approves based on
+the authorization outcome. To prevent conflicts with other approvers, the
+builtin approver doesn't explicitly deny CSRs. It only ignores unauthorized
+requests. The controller also prunes expired certificates as part of garbage
+collection.
+
+
## kubelet configuration
+Finally, with the master nodes properly set up and all of the necessary authentication and authorization in place, we can configure the kubelet.
-To request a client certificate from kube-apiserver, the kubelet first needs a
-path to a kubeconfig file that contains the credentials for the identity that it
-will use to bootstrap its individual node identity.
+The kubelet requires the following configuration to bootstrap:
-If you are using a bootstrap token, you can use `kubectl config set-cluster`,
-`set-credentials`, and `set-context` to build this kubeconfig. Provide the name
-`kubelet-bootstrap` to `kubectl config set-credentials` and include
-`--token=` as follows:
+* A path to store the key and certificate it generates (optional, can use default)
+* A path to a `kubeconfig` file that does not yet exist; it will place the bootstrapped config file here
+* A path to a bootstrap `kubeconfig` file to provide the URL for the server and bootstrap credentials, e.g. a bootstrap token
+* Optional: instructions to rotate certificates
+
+The bootstrap `kubeconfig` should be in a path available to the kubelet, for example `/var/lib/kubelet/bootstrap-kubeconfig`.
+
+Its format is identical to a normal `kubeconfig` file. A sample file might look as follows:
+
+```yml
+apiVersion: v1
+clusters:
+- cluster:
+ certificate-authority: /var/lib/kubernetes/ca.pem
+ server: https://my.server.example.com:6443
+ name: bootstrap
+contexts:
+- context:
+ cluster: bootstrap
+ user: kubelet-bootstrap
+ name: bootstrap
+current-context: bootstrap
+kind: Config
+preferences: {}
+users:
+- name: kubelet-bootstrap
+ user:
+ token: 07401b.f395accd246ae52d
+```
+
+The important elements to note are:
+
+* `certificate-authority`: path to a CA file, used to validate the server certificate presented by kube-apiserver
+* `server`: URL to kube-apiserver
+* `token`: the token to use
+
+The format of the token does not matter, as long as it matches what kube-apiserver expects. In the above example, we used a bootstrap token.
+As stated earlier, _any_ valid authentication method can be used, not just tokens.
+
+Because the bootstrap `kubeconfig` _is_ a standard `kubeconfig`, you can use `kubectl` to generate it. To create the above example file:
```
-kubectl config set-credentials kubelet-bootstrap --token=${BOOTSTRAP_TOKEN} --kubeconfig=bootstrap.kubeconfig
+kubectl config -kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-cluster bootstrap --server='https://my.server.example.com:6443' --certificate-authority=/var/lib/kubernetes/ca.pem
+kubectl config -kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-credentials kubelet-bootstrap --token=07401b.f395accd246ae52d
+kubectl config -kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-context bootstrap --user=kubelet-bootstrap --cluster=bootstrap
+kubectl config -kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig use-context bootstrap
+```
+
+To indicate to the kubelet to use the bootstrap `kubeconfig`, use the following kubelet flag:
+
+```
+--bootstrap-kubeconfig="/var/lib/kubelet/bootstrap-kubeconfig" --kubeconfig="/var/lib/kubelet/kubeconfig"
```
When starting the kubelet, if the file specified via `--kubeconfig` does not
@@ -220,16 +399,25 @@ referencing the generated key and obtained certificate is written to the path
specified by `--kubeconfig`. The certificate and key file will be placed in the
directory specified by `--cert-dir`.
-{{< note >}}
-**Note:** The following flags are required to enable this bootstrapping when starting the kubelet:
+### Client and Serving Certificates
+All of the above relate to kubelet _client_ certificates, specifically, the certificates a kubelet
+uses to authenticate to kube-apiserver.
-```
---bootstrap-kubeconfig="/path/to/bootstrap/kubeconfig"
-```
-{{< /note >}}
+A kubelet also can use _serving_ certificates. The kubelet itself exposes an https endpoint for certain features.
+To secure these, the kubelet can do one of:
-Additionally, in 1.7 the kubelet implements __beta__ features for enabling
-rotation of both its client and/or serving certs. These can be enabled through
+* use provided key and certificate, via the `--tls-private-key-file` and `--tls-cert-file` flags
+* create self-signed key and certificate, if a key and certificate are not provided
+* request serving certificates from the cluster server, via the CSR API
+
+The client certificate provided by TLS bootstrapping is signed, by default, for `client auth` only, and thus cannot
+be used as serving certificates, or `server auth`.
+
+However, you _can_ enable its server certificate, at least partially, via certificate rotation.
+
+### Certificate Rotation
+Kubernetes v1.7 and higher kubelet implements __beta__ features for enabling
+rotation of its client and/or serving certficates. These can be enabled through
the respective `RotateKubeletClientCertificate` and
`RotateKubeletServerCertificate` feature flags on the kubelet and are enabled by
default.
@@ -242,8 +430,8 @@ this feature pass the following flag to the kubelet:
--rotate-certificates
```
-`RotateKubeletServerCertificate` causes the kubelet to both request a serving
-certificate after bootstrapping its client credentials and to rotate that
+`RotateKubeletServerCertificate` causes the kubelet **both** to request a serving
+certificate after bootstrapping its client credentials **and** to rotate that
certificate. To enable this feature pass the following flag to the kubelet:
```
@@ -251,13 +439,25 @@ certificate. To enable this feature pass the following flag to the kubelet:
```
{{< note >}}
-**Note:** The CSR approving controllers implemented in core Kubernetes do not
-approve node serving certificates for [security
+The CSR approving controllers implemented in core Kubernetes do not
+approve node _serving_ certificates for [security
reasons](https://github.com/kubernetes/community/pull/1982). To use
`RotateKubeletServerCertificate` operators need to run a custom approving
controller, or manually approve the serving certificate requests.
{{< /note >}}
+## Other authenticating components
+All of TLS bootstrapping described in this document relates to the kubelet. However,
+other components may need to communicate directly with kube-apiserver. Notable is kube-proxy, which
+is part of the Kubernetes control plane and runs on every node, but may also include other components such as monitoring or networking.
+
+Like the kubelet, these other components also require a method of authenticating to kube-apiserver.
+You have several options for generating these credentials:
+
+* The old way: Create and distribute certificates the same way you did for kubelet before TLS bootstrapping
+* DaemonSet: Since the kubelet itself is loaded on each node, and is sufficient to start base services, you can run kube-proxy and other node-specific services not as a standalone process, but rather as a daemonset in the `kube-system` namespace. Since it will be in-cluster, you can give it a proper service account with appropriate permissions to perform its activities. This may be the simplest way to configure such services.
+
+
## kubectl approval
CSRs can be approved outside of the approval flows builtin to the controller
@@ -273,4 +473,14 @@ list CSRs with `kubectl get csr` and describe one in detail with `kubectl
describe csr `. An administrator can approve or deny a CSR with `kubectl
certificate approve ` and `kubectl certificate deny `.
+
+## Limits
+Although Kubernetes supports running control plane master components like kube-apiserver and kube-controller-manager in containers, and even as `Pod`s in a kubelet, as of this writing, you cannot both TLS Bootstrap a kubelet and run master plane components on it.
+
+The reason for this limitation is that the kubelet attempts to bootstrap communication with kube-apiserver _before_ starting any pods, even static ones define on disk and referenced via the kubelet option `--pod-manifest-path=`. Trying to do both TLS Bootstrapping and master components in kubelet leads to a race condition: kubelet needs to communicate to kube-apiserver to request certificates, yet requires those certificates to be available to start kube-apiserver.
+
+An issue is open referencing this [here](https://github.com/kubernetes/kubernetes/issues/68686).
+
+
+
{{% /capture %}}
diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet.md b/content/en/docs/reference/command-line-tools-reference/kubelet.md
index de1111982f..29a3ff6eea 100644
--- a/content/en/docs/reference/command-line-tools-reference/kubelet.md
+++ b/content/en/docs/reference/command-line-tools-reference/kubelet.md
@@ -244,7 +244,7 @@ kubelet [flags]
--container-runtime string
-
The container runtime to use. Possible values: 'docker', 'rkt'. (default "docker")
+
The container runtime to use. Possible values: 'docker', 'remote', 'rkt(deprecated)'. (default "docker")
@@ -286,7 +286,7 @@ kubelet [flags]
--cpu-manager-policy string
-
CPU Manager policy to use. Possible values: 'none', 'static'. Default: 'none' (default "none")
+
CPU Manager policy to use. Possible values: 'none', 'static'. (default "none")
@@ -945,7 +945,7 @@ kubelet [flags]
--registry-burst int32
-
Maximum size of a bursty pulls, temporarily allows pulls to burst to this number, while still not exceeding registry-qps. Only used if --registry-qps > 0 (default 10)
+
Maximum size of bursty pulls, temporarily allows pulls to burst to this number, while still not exceeding registry-qps. Only used if --registry-qps > 0 (default 10)
@@ -1113,7 +1113,7 @@ kubelet [flags]
--tls-cipher-suites stringSlice
-
Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be use. Possible values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA
+
Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be used. Possible values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA
diff --git a/content/en/docs/reference/glossary/cloud-controller-manager.md b/content/en/docs/reference/glossary/cloud-controller-manager.md
index 0962c0c359..9a818ff93e 100755
--- a/content/en/docs/reference/glossary/cloud-controller-manager.md
+++ b/content/en/docs/reference/glossary/cloud-controller-manager.md
@@ -16,5 +16,5 @@ tags:
-Kubernetes v1.6 contains a new binary called cloud-controller-manager. cloud-controller-manager is a daemon that embeds cloud-specific control loops. These cloud-specific control loops were originally in the kube-controller-manager. Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the cloud-controller-manager binary allows cloud vendors to evolve independently from the core Kubernetes code.
+Kubernetes v1.6 contains a new binary called cloud-controller-manager. cloud-controller-manager is a daemon that embeds cloud-specific control loops. These cloud-specific control loops were originally in the kube-controller-manager. Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the cloud-controller-manager binary allows cloud vendors to evolve independently from the core Kubernetes code.
diff --git a/content/en/docs/reference/glossary/cluster-operator.md b/content/en/docs/reference/glossary/cluster-operator.md
index f006ebe319..c897343830 100755
--- a/content/en/docs/reference/glossary/cluster-operator.md
+++ b/content/en/docs/reference/glossary/cluster-operator.md
@@ -16,5 +16,7 @@ tags:
Their primary responsibility is keeping a cluster up and running, which may involve periodic maintenance activities or upgrades.
-**NOTE:** Cluster operators are different from the [Operator pattern](https://coreos.com/operators) that extends the Kubernetes API.
+{{< note >}}
+Cluster operators are different from the [Operator pattern](https://coreos.com/operators) that extends the Kubernetes API.
+{{< /note >}}
diff --git a/content/en/docs/reference/glossary/container-lifecycle-hooks.md b/content/en/docs/reference/glossary/container-lifecycle-hooks.md
new file mode 100644
index 0000000000..527e2f3e6e
--- /dev/null
+++ b/content/en/docs/reference/glossary/container-lifecycle-hooks.md
@@ -0,0 +1,18 @@
+---
+title: Container Lifecycle Hooks
+id: container-lifecycle-hooks
+date: 2018-10-08
+full_link: /docs/concepts/containers/container-lifecycle-hooks/
+short_description: >
+ The lifecycle hooks expose events in the container management lifecycle and let the user run code when the events occur.
+
+aka:
+tags:
+- extension
+---
+ The lifecycle hooks expose events in the {{< glossary_tooltip text="Container" term_id="container" >}}container management lifecycle and let the user run code when the events occur.
+
+
+
+Two hooks are exposed to Containers: PostStart which executes immediately after a container is created and PreStop which is blocking and is called immediately before a container is terminated.
+
diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md
index 3d2a703f0a..0f42751f7c 100644
--- a/content/en/docs/reference/kubectl/cheatsheet.md
+++ b/content/en/docs/reference/kubectl/cheatsheet.md
@@ -110,8 +110,8 @@ metadata:
name: mysecret
type: Opaque
data:
- password: $(echo -n "s33msi4" | base64)
- username: $(echo -n "jane" | base64)
+ password: $(echo -n "s33msi4" | base64 -w0)
+ username: $(echo -n "jane" | base64 -w0)
EOF
```
@@ -163,12 +163,20 @@ kubectl get events --sort-by=.metadata.creationTimestamp
## Updating Resources
+As of version 1.11 `rolling-update` have been deprecated (see [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md)), use `rollout` instead.
+
```bash
-kubectl rolling-update frontend-v1 -f frontend-v2.json # Rolling update pods of frontend-v1
-kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2 # Change the name of the resource and update the image
-kubectl rolling-update frontend --image=image:v2 # Update the pods image of frontend
-kubectl rolling-update frontend-v1 frontend-v2 --rollback # Abort existing rollout in progress
-cat pod.json | kubectl replace -f - # Replace a pod based on the JSON passed into stdin
+kubectl set image deployment/frontend www=image:v2 # Rolling update "www" containers of "frontend" deployment, updating the image
+kubectl rollout undo deployment/frontend # Rollback to the previous deployment
+kubectl rollout status -w deployment/frontend # Watch rolling update status of "frontend" deployment until completion
+
+# deprecated starting version 1.11
+kubectl rolling-update frontend-v1 -f frontend-v2.json # (deprecated) Rolling update pods of frontend-v1
+kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2 # (deprecated) Change the name of the resource and update the image
+kubectl rolling-update frontend --image=image:v2 # (deprecated) Update the pods image of frontend
+kubectl rolling-update frontend-v1 frontend-v2 --rollback # (deprecated) Abort existing rollout in progress
+
+cat pod.json | kubectl replace -f - # Replace a pod based on the JSON passed into std
# Force replace, delete and then re-create the resource. Will cause a service outage.
kubectl replace --force -f ./pod.json
diff --git a/content/en/docs/reference/kubectl/conventions.md b/content/en/docs/reference/kubectl/conventions.md
index 05ae60a048..3e6f2d4c99 100644
--- a/content/en/docs/reference/kubectl/conventions.md
+++ b/content/en/docs/reference/kubectl/conventions.md
@@ -3,17 +3,22 @@ title: kubectl Usage Conventions
reviewers:
- bgrant0607
- janetkuo
+content_template: templates/concept
---
-{{< toc >}}
+{{% capture overview %}}
+Recommended usage conventions for `kubectl`.
+{{% /capture %}}
+
+{{% capture body %}}
## Using `kubectl` in Reusable Scripts
For a stable output in a script:
-* Request one of the machine-oriented output forms, such as `-o name`, `-o json`, `-o yaml`, `-o go-template`, or `-o jsonpath`
+* Request one of the machine-oriented output forms, such as `-o name`, `-o json`, `-o yaml`, `-o go-template`, or `-o jsonpath`.
* Fully-qualify the version. For example, `jobs.v1.batch/myjob`. This will ensure that kubectl does not use its default version that can change over time.
-* Specify `--generator` to pin to a specific behavior forever when you use generator-based commands such as `kubectl run` or `kubectl expose`
+* Specify the `--generator` flag to pin to a specific behavior when you use generator-based commands such as `kubectl run` or `kubectl expose`.
* Don't rely on context, preferences, or other implicit states.
## Best Practices
@@ -30,15 +35,21 @@ For `kubectl run` to satisfy infrastructure as code:
#### Generators
-You can generate the following resources in `kubectl run`using `--generator` flag:
+You can create the following resources using `kubectl run` with the `--generator` flag:
-* Pod - use `run-pod/v1`.
-* Replication controller - use `run/v1`.
-* Deployment - use `extensions/v1beta1` and for an endpoint - use `deployment/v1beta1` (default).
-* Deployment - use `apps/v1beta1` and for an endpoint - use `deployment/apps.v1beta1` (recommended).
-* Job - use `job/v1`.
-* CronJob - use `batch/v1beta1`and for an endpoint - use `cronjob/v1beta1`(default).
-* CronJob - use`batch/v2alpha1` and for an endpoint - use `cronjob/v2alpha1` (deprecated).
+| Resource | kubectl command |
+|---------------------------------|---------------------------------------------------|
+| Pod | `kubectl run --generator=run-pod/v1` |
+| Replication controller | `kubectl run --generator=run/v1` |
+| Deployment | `kubectl run --generator=extensions/v1beta1` |
+| -for an endpoint (default) | `kubectl run --generator=deployment/v1beta1` |
+| Deployment | `kubectl run --generator=apps/v1beta1` |
+| -for an endpoint (recommended) | `kubectl run --generator=deployment/apps.v1beta1` |
+| Job | `kubectl run --generator=job/v1` |
+| CronJob | `kubectl run --generator=batch/v1beta1` |
+| -for an endpoint (default) | `kubectl run --generator=cronjob/v1beta1` |
+| CronJob | `kubectl run --generator=batch/v2alpha1` |
+| -for an endpoint (deprecated) | `kubectl run --generator=cronjob/v2alpha1` |
If you do not specify a generator flag, other flags prompt you to use a specific generator. The following table lists the flags that force you to use specific generators, depending on the version of the cluster:
@@ -50,19 +61,22 @@ If you do not specify a generator flag, other flags prompt you to use a specific
| Job | `--restart=OnFailure` | `--restart=OnFailure` | `--restart=OnFailure` OR `--restart=Never` | N/A |
| Cron Job | `--schedule=` | N/A | N/A | N/A |
-**Note:** These flags use a default generator only when you have not specified
-any flag. This means that when you combine `--generator` with other flags the generator that you specified later does not change. For example, in a cluster v1.4, if you initially specify
+{{< note >}}
+These flags use a default generator only when you have not specified any flag.
+This means that when you combine `--generator` with other flags the generator that you specified later does not change. For example, in a cluster v1.4, if you initially specify
`--restart=Always`, a Deployment is created; if you later specify `--restart=Always`
and `--generator=run/v1`, a Replication Controller is created.
This enables you to pin to a specific behavior with the generator,
even when the default generator is changed later.
+{{< /note >}}
-The flags set the generator in the following order: first the schedule flag then restart policy and finally the generator.
+The flags set the generator in the following order: first the `--schedule` flag, then the `--restart` policy flag, and finally the `--generator` flag.
-To check the final resource that was created, use `--dry-run`
+To check the final resource that was created, use the `--dry-run`
flag, which provides the object to be submitted to the cluster.
-
### `kubectl apply`
* You can use `kubectl apply` to create or update resources. However, to update a resource you should have created the resource by using `kubectl apply` or `kubectl create --save-config`. For more information about using kubectl apply to update resources, see [Managing Resources](/docs/concepts/cluster-administration/manage-deployment/#kubectl-apply).
+
+{{% /capture %}}
\ No newline at end of file
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 6373155102..0925992ef8 100644
--- a/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md
+++ b/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md
@@ -36,7 +36,7 @@ deployment "nginx-app" created
```
{{< note >}}
-**Note:** `kubectl` commands print the type and name of the resource created or mutated, which can then be used in subsequent commands. You can expose a new Service after a Deployment is created.
+`kubectl` commands print the type and name of the resource created or mutated, which can then be used in subsequent commands. You can expose a new Service after a Deployment is created.
{{< /note >}}
```shell
@@ -75,7 +75,7 @@ CONTAINER ID IMAGE COMMAND CREATED
kubectl:
```shell
-$ kubectl get po -a
+$ kubectl get po
NAME READY STATUS RESTARTS AGE
nginx-app-8df569cb7-4gd89 1/1 Running 0 3m
ubuntu 0/1 Completed 0 20s
@@ -222,7 +222,7 @@ $ kubectl get po -l run=nginx-app
```
{{< note >}}
-**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.
+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
@@ -294,4 +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
+{{% /capture %}}
diff --git a/content/en/docs/reference/kubectl/jsonpath.md b/content/en/docs/reference/kubectl/jsonpath.md
index 8f111f2875..74fcea92fb 100644
--- a/content/en/docs/reference/kubectl/jsonpath.md
+++ b/content/en/docs/reference/kubectl/jsonpath.md
@@ -1,18 +1,32 @@
---
title: JSONPath Support
+content_template: templates/concept
+weight: 25
---
-JSONPath template is composed of JSONPath expressions enclosed by {}.
-And we add three functions in addition to the original JSONPath syntax:
+{{% capture overview %}}
+Kubectl supports JSONPath template.
+{{% /capture %}}
-1. The `$` operator is optional since the expression always starts from the root object by default.
-2. We can use `""` to quote text inside JSONPath expressions.
-3. We can use `range` operator to iterate lists.
-4. We can use negative slice indices to step backwards through a list. Negative indices do not "wrap around" a list. They are valid as long as `-index + listLength >= 0`.
+{{% capture body %}}
-The result object is printed as its String() function.
+JSONPath template is composed of JSONPath expressions enclosed by curly braces {}.
+Kubectl uses JSONPath expressions to filter on specific fields in the JSON object and format the output.
+In addition to the original JSONPath template syntax, the following functions and syntax are valid:
-Given the input:
+1. Use double quotes to quote text inside JSONPath expressions.
+2. Use the `range`, `end` operators to iterate lists.
+3. Use negative slice indices to step backwards through a list. Negative indices do not "wrap around" a list and are valid as long as `-index + listLength >= 0`.
+
+{{< note >}}
+
+- The `$` operator is optional since the expression always starts from the root object by default.
+
+- The result object is printed as its String() function.
+
+{{< /note >}}
+
+Given the JSON input:
```json
{
@@ -51,20 +65,20 @@ Given the input:
}
```
-Function | Description | Example | Result
----------|--------------------|--------------------|------------------
-text | the plain text | kind is {.kind} | kind is List
-@ | the current object | {@} | the same as input
-. or [] | child operator | {.kind} or {['kind']}| List
-.. | recursive descent | {..name} | 127.0.0.1 127.0.0.2 myself e2e
-\* | wildcard. Get all objects| {.items[*].metadata.name} | [127.0.0.1 127.0.0.2]
-[start:end :step] | subscript operator | {.users[0].name}| myself
-[,] | union operator | {.items[*]['metadata.name', 'status.capacity']} | 127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8]
-?() | filter | {.users[?(@.name=="e2e")].user.password} | secret
-range, end | iterate list | {range .items[*]}[{.metadata.name}, {.status.capacity}] {end} | [127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]]
-'' | quote interpreted string | {range .items[*]}{.metadata.name}{'\t'}{end} | 127.0.0.1 127.0.0.2
+Function | Description | Example | Result
+------------------|---------------------------|---------------------------------------------------------------|------------------
+text | the plain text | kind is {.kind} | kind is List
+@ | the current object | {@} | the same as input
+. or [] | child operator | {.kind} or {['kind']} | List
+.. | recursive descent | {..name} | 127.0.0.1 127.0.0.2 myself e2e
+\* | wildcard. Get all objects | {.items[*].metadata.name} | [127.0.0.1 127.0.0.2]
+[start:end :step] | subscript operator | {.users[0].name} | myself
+[,] | union operator | {.items[*]['metadata.name', 'status.capacity']} | 127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8]
+?() | filter | {.users[?(@.name=="e2e")].user.password} | secret
+range, end | iterate list | {range .items[*]}[{.metadata.name}, {.status.capacity}] {end} | [127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]]
+'' | quote interpreted string | {range .items[*]}{.metadata.name}{'\t'}{end} | 127.0.0.1 127.0.0.2
-Below are some examples using jsonpath:
+Examples using `kubectl` and JSONPath expressions:
```shell
$ kubectl get pods -o json
@@ -80,3 +94,5 @@ On Windows, you must _double_ quote any JSONPath template that contains spaces (
C:\> kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.startTime}{'\n'}{end}"
C:\> kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.startTime}{\"\n\"}{end}"
```
+
+{{% /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 ca50170576..25388fdf80 100644
--- a/content/en/docs/reference/kubectl/overview.md
+++ b/content/en/docs/reference/kubectl/overview.md
@@ -3,9 +3,17 @@ reviewers:
- bgrant0607
- hw-qiaolei
title: Overview of kubectl
+content_template: templates/concept
+weight: 20
---
-`kubectl` is a command line interface for running commands against Kubernetes clusters. This overview covers `kubectl` syntax, describes the command operations, and provides common examples. For details about each command, including all the supported flags and subcommands, see the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) reference documentation. For installation instructions see [installing kubectl](/docs/tasks/kubectl/install/).
+{{% capture overview %}}
+Kubectl is a command line interface for running commands against Kubernetes clusters.
+This overview covers `kubectl` syntax, describes the command operations, and provides common examples. For details about each command, including all the supported flags and subcommands, see the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) reference documentation. For installation instructions see [installing kubectl](/docs/tasks/kubectl/install/).
+
+{{% /capture %}}
+
+{{% capture body %}}
## Syntax
@@ -45,7 +53,10 @@ where `command`, `TYPE`, `NAME`, and `flags` are:
Example: `$ kubectl get pod -f ./pod.yaml`
* `flags`: Specifies optional flags. For example, you can use the `-s` or `--server` flags to specify the address and port of the Kubernetes API server.
-**Important**: Flags that you specify from the command line override default values and any corresponding environment variables.
+
+{{< caution >}}
+Flags that you specify from the command line override default values and any corresponding environment variables.
+{{< /caution >}}
If you need help, just run `kubectl help` from the terminal window.
@@ -66,7 +77,7 @@ Operation | Syntax | Description
`delete` | `kubectl delete (-f FILENAME \| TYPE [NAME \| /NAME \| -l label \| --all]) [flags]` | Delete resources either from a file, stdin, or specifying label selectors, names, resource selectors, or resources.
`describe` | `kubectl describe (-f FILENAME \| TYPE [NAME_PREFIX \| /NAME \| -l label]) [flags]` | Display the detailed state of one or more resources.
`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,
+`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.
`get` | `kubectl get (-f FILENAME \| TYPE [NAME \| /NAME \| -l label]) [--watch] [--sort-by=FIELD] [[-o \| --output]=OUTPUT_FORMAT] [flags]` | List one or more resources.
@@ -135,7 +146,7 @@ Use the following sections for information about how you can format or sort the
### Formatting output
-The default output format for all `kubectl` commands is the human readable plain-text format. 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.
+The default output format for all `kubectl` commands is the human readable plain-text format. 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.
#### Syntax
@@ -262,7 +273,7 @@ $ kubectl create -f
// List all pods in plain-text output format.
$ kubectl get pods
-// List all pods in plain-text output format and includes additional information (such as node name).
+// List all pods in plain-text output format and include additional information (such as node name).
$ kubectl get pods -o wide
// List the replication controller with the specified name in plain-text output format. Tip: You can shorten and replace the 'replicationcontroller' resource type with the alias 'rc'.
@@ -299,7 +310,7 @@ $ kubectl describe pods --include-uninitialized=false
```
{{< note >}}
-**Note:** The `kubectl get` command is usually used for retrieving one or more
+The `kubectl get` command is usually used for retrieving one or more
resources of the same resource type. It features a rich set of flags that allows
you to customize the output format using the `-o` or `--output` flag, for example.
You can specify the `-w` or `--watch` flag to start watching updates to a particular
@@ -431,6 +442,10 @@ Current user: plugins-user
To find out more about plugins, take a look at the [example cli plugin](https://github.com/kubernetes/sample-cli-plugin).
-## Next steps
+{{% /capture %}}
+
+{{% capture whatsnext %}}
Start using the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) commands.
+
+{{% /capture %}}
diff --git a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md
index 09cc412595..36cb28b8e2 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md
@@ -86,7 +86,7 @@ In any case the user can skip specific preflight checks (or eventually all prefl
- [error] if not Kernel 3.10+ or 4+ with specific KernelSpec
- [error] if required cgroups subsystem aren't in set up
- if using docker:
- - [warning/error] if Docker service does not exist, if it is disabled, if it is not active.
+ - [warning/error] if Docker service does not exist, if it is disabled, if it is not active.
- [error] if Docker endpoint does not exist or does not work
- [warning] if docker version >17.03
- If using other cri engine:
@@ -106,9 +106,9 @@ In any case the user can skip specific preflight checks (or eventually all prefl
- [Error] if `ip`, `iptables`, `mount`, `nsenter` commands are not present in the command path
- [warning] if `ebtables`, `ethtool`, `socat`, `tc`, `touch`, `crictl` commands are not present in the command path
- [warning] if extra arg flags for API server, controller manager, scheduler contains some invalid options
-- [warning] if connection to https://API.AdvertiseAddress:API.BindPort goes thought proxy
-- [warning] if connection to services subnet goes thought proxy (only first address checked)
-- [warning] if connection to Pods subnet goes thought proxy (only first address checked)
+- [warning] if connection to https://API.AdvertiseAddress:API.BindPort goes through proxy
+- [warning] if connection to services subnet goes through proxy (only first address checked)
+- [warning] if connection to Pods subnet goes through proxy (only first address checked)
- If external etcd is provided:
- [Error] if etcd version less than 3.0.14
- [Error] if etcd certificates or keys are specified, but not provided
@@ -200,7 +200,7 @@ Static Pod manifest share a set of common properties:
of using Pod Priority and Preemption when ready)
- `hostNetwork: true` is set on all static Pods to allow control plane startup before a network is configured; as a consequence:
* The `address` that the controller-manager and the scheduler use to refer the API server is `127.0.0.1`
- * If using a local etcd server, `etcd-servers` address will be set to `127.0.0.1:2379`
+ * If using a local etcd server, `etcd-servers` address will be set to `127.0.0.1:2379`
- Leader election is enabled for both the controller-manager and the scheduler
- Controller-manager and the scheduler will reference kubeconfig files with their respective, unique identities
- All static Pods gets any extra flags specified by the user as described in [passing custom arguments to control plane components](/docs/reference/setup-tools/kubeadm/kubeadm-init/#custom-args)
@@ -224,7 +224,7 @@ The static Pod manifest for the API server is affected by following parameters p
- The `service-cluster-ip-range` to use for services
- If an external etcd server is specified, the `etcd-servers` address and related TLS settings (`etcd-cafile`, `etcd-certfile`, `etcd-keyfile`);
if an external etcd server is not be provided, a local etcd will be used (via host network)
- - If a cloud provider is specified, the corresponding `--cloud-provider` is configured, together with the `--cloud-config` path
+ - If a cloud provider is specified, the corresponding `--cloud-provider` is configured, together with the `--cloud-config` path
if such file exists (this is experimental, alpha and will be removed in a future version)
- If kubeadm is invoked with `--feature-gates=HighAvailability`, the flag `--endpoint-reconciler-type=lease` is set, thus enabling
automatic reconciliation of endpoints for the internal API server VIP
@@ -277,7 +277,7 @@ The static Pod manifest for the API server is affected by following parameters p
setting:
- `--allocate-node-cidrs=true`
- `--cluster-cidr` and `--node-cidr-mask-size` flags according to the given CIDR
- - If a cloud provider is specified, the corresponding `--cloud-provider` is specified, together with the `--cloud-config` path
+ - If a cloud provider is specified, the corresponding `--cloud-provider` is specified, together with the `--cloud-config` path
if such configuration file exists (this is experimental, alpha and will be removed in a future version)
Other flags that are set unconditionally are:
@@ -318,7 +318,7 @@ into `/var/lib/kubelet/config/init/kubelet` file.
The init configuration is used for starting the kubelet on this specific node, providing an alternative for the kubelet drop-in file;
such configuration will be replaced by the kubelet base configuration as described in following steps.
-See [set Kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file.md) for additional info.
+See [set Kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file) for additional info.
Please note that:
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md
index ba29459a2a..68c14d99d4 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md
@@ -145,7 +145,7 @@ You can install all the available addons with the `all` subcommand, or
install them selectively.
{{< note >}}
-**Note:** If `kubeadm` is invoked with `--feature-gates=CoreDNS=false`, kube-dns is installed.
+If `kubeadm` is invoked with `--feature-gates=CoreDNS=false`, kube-dns is installed.
{{< /note >}}
{{< tabs name="tab-addon" >}}
@@ -158,7 +158,7 @@ install them selectively.
## kubeadm alpha phase self-hosting {#cmd-phase-self-hosting}
{{< caution >}}
-**Caution:** Self-hosting is an alpha feature. See [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) documentation for self-hosting limitations.
+Self-hosting is an alpha feature. See [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) documentation for self-hosting limitations.
{{< /caution >}}
{{< tabs name="tab-self-hosting" >}}
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
index 4a26f55110..59aa6ef767 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
@@ -92,8 +92,7 @@ following steps:
### Using kubeadm init with a configuration file {#config-file}
{{< caution >}}
-**Caution:** The config file is
-still considered alpha and may change in future versions.
+The config file is still considered alpha and may change in future versions.
{{< /caution >}}
It's possible to configure `kubeadm init` with a configuration file instead of command
@@ -284,14 +283,10 @@ configured in the kubelet via static files.
To create a self-hosted cluster, pass the flag `--feature-gates=SelfHosting=true` to `kubeadm init`.
{{< caution >}}
-**Caution:** `SelfHosting` is an alpha feature. It is deprecated in 1.12
+`SelfHosting` is an alpha feature. It is deprecated in 1.12
and will be removed in 1.13.
{{< /caution >}}
-{{< warning >}}
-**Warning:** See self-hosted caveats and limitations.
-{{< /warning >}}
-
#### Caveats
Self-hosting in 1.8 has some important limitations. In particular, a
@@ -309,7 +304,7 @@ authorization configuration for your cluster, and may not be appropriate for
your environment.
{{< caution >}}
-**Caution:** `StoreCertsInSecrets` is an alpha feature. It is deprecated in 1.12
+`StoreCertsInSecrets` is an alpha feature. It is deprecated in 1.12
and will be removed in 1.13.
{{< /caution >}}
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
index c0882d0b01..2fb074626b 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
@@ -204,8 +204,7 @@ These commands should be run after `kubeadm init` but before `kubeadm join`.
### Using kubeadm join with a configuration file {#config-file}
{{< caution >}}
-**Caution:** The config file is
-still considered alpha and may change in future versions.
+The config file is still considered alpha and may change in future versions.
{{< /caution >}}
It's possible to configure `kubeadm join` with a configuration file instead of command
diff --git a/content/en/docs/reference/using-api/api-overview.md b/content/en/docs/reference/using-api/api-overview.md
index 2d38030e3f..38baa5aa92 100644
--- a/content/en/docs/reference/using-api/api-overview.md
+++ b/content/en/docs/reference/using-api/api-overview.md
@@ -40,7 +40,7 @@ The version is set at the API level rather than at the resource or field level t
The JSON and Protobuf serialization schemas follow the same guidelines for schema changes. The following descriptions cover both formats.
{{< note >}}
-**Note:** The API versioning and software versioning are indirectly related. The [API and release
+The API versioning and software versioning are indirectly related. The [API and release
versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) describes the relationship between API versioning and software versioning.
{{< /note >}}
@@ -64,7 +64,7 @@ Here's a summary of each level:
- The software is recommended for only non-business-critical uses because of potential for incompatible changes in subsequent releases. If you have multiple clusters which can be upgraded independently, you may be able to relax this restriction.
{{< note >}}
-**Note:** Try the beta features and provide feedback. After the features exit beta, it may not be practical to make more changes.
+Try the beta features and provide feedback. After the features exit beta, it may not be practical to make more changes.
{{< /note >}}
- Stable:
@@ -97,7 +97,7 @@ on the apiserver. `--runtime-config` accepts comma separated values. For example
The flag accepts comma separated set of key=value pairs describing runtime configuration of the apiserver.
{{< note >}}
-**Note:** When you enable or disable groups or resources, you need to restart the apiserver and controller-manager
+When you enable or disable groups or resources, you need to restart the apiserver and controller-manager
to pick up the `--runtime-config` changes.
{{< /note >}}
diff --git a/content/en/docs/reference/using-api/deprecation-policy.md b/content/en/docs/reference/using-api/deprecation-policy.md
index 565eb038ea..a6a8f190cd 100644
--- a/content/en/docs/reference/using-api/deprecation-policy.md
+++ b/content/en/docs/reference/using-api/deprecation-policy.md
@@ -57,7 +57,7 @@ can not be removed from that version or have its behavior significantly
changed, regardless of track.
{{< note >}}
-**Note:** For historical reasons, there are 2 "monolithic" API groups - "core" (no
+For historical reasons, there are 2 "monolithic" API groups - "core" (no
group name) and "extensions". Resources will incrementally be moved from these
legacy API groups into more domain-specific API groups.
{{< /note >}}
@@ -90,7 +90,7 @@ no less than:**
This covers the maximum supported version skew of 2 releases.
{{< note >}}
-**Note:** Until [#52185](https://github.com/kubernetes/kubernetes/issues/52185) is
+Until [#52185](https://github.com/kubernetes/kubernetes/issues/52185) is
resolved, no API versions that have been persisted to storage may be removed.
Serving REST endpoints for those versions may be disabled (subject to the
deprecation timelines in this document), but the API server must remain capable
@@ -365,6 +365,56 @@ This applies only to significant, user-visible behaviors which impact the
correctness of applications running on Kubernetes or that impact the
administration of Kubernetes clusters, and which are being removed entirely.
+An exception to the above rule is _feature gates_. Feature gates are key=value
+pairs that allow for users to enable/disable experimental features.
+
+Feature gates are intended to cover the development life cycle of a feature - they
+are not intended to be long-term APIs. As such, they are expected to be deprecated
+and removed after a feature becomes GA or is dropped.
+
+As a feature moves through the stages, the associated feature gate evolves.
+The feature life cycle matched to its corresponding feature gate is:
+
+ * Alpha: the feature gate is disabled by default and can be enabled by the user.
+ * Beta: the feature gate is enabled by default and can be disabled by the user.
+ * GA: the feature gate is deprecated (see ["Deprecation"](#deprecation)) and becomes
+ non-operational.
+ * GA, deprecation window complete: the feature gate is removed and calls to it are
+ no longer accepted.
+
+### Deprecation
+
+Features can be removed at any point in the life cycle prior to GA. When features are
+removed prior to GA, their associated feature gates are also deprecated.
+
+When an invocation tries to disable a non-operational feature gate, the call fails in order
+to avoid unsupported scenarios that might otherwise run silently.
+
+In some cases, removing pre-GA features requires considerable time. Feature gates can remain
+operational until their associated feature is fully removed, at which point the feature gate
+itself can be deprecated.
+
+When removing a feature gate for a GA feature also requires considerable time, calls to
+feature gates may remain operational if the feature gate has no effect on the feature,
+and if the feature gate causes no errors.
+
+Features intended to be disabled by users should include a mechanism for disabling the
+feature in the associated feature gate.
+
+Versioning for feature gates is different from the previously discussed components,
+therefore the rules for deprecation are as follows:
+
+**Rule #8: Feature gates must be deprecated when the corresponding feature they control
+transitions a lifecycle stage as follows. Feature gates must function for no less than:**
+
+ * **Beta feature to GA: 6 months or 2 releases (whichever is longer)**
+ * **Beta feature to EOL: 3 months or 1 release (whichever is longer)**
+ * **Alpha feature to EOL: 0 releases**
+
+**Rule #9: Deprecated feature gates must respond with a warning when used. When a feature gate
+is deprecated it must be documented in both in the release notes and the corresponding CLI help.
+Both warnings and documentation must indicate whether a feature gate is non-operational.**
+
## Exceptions
No policy can cover every possible situation. This policy is a living
diff --git a/content/en/docs/setup/certificates.md b/content/en/docs/setup/certificates.md
index 3fffec6fcc..dc93af997f 100644
--- a/content/en/docs/setup/certificates.md
+++ b/content/en/docs/setup/certificates.md
@@ -30,7 +30,7 @@ Kubernetes requires PKI for the following operations:
* Client and server certificates for the [front-proxy][proxy]
{{< note >}}
-**Note:** `front-proxy` certificates are required only if you run kube-proxy to support [an extension API server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/).
+`front-proxy` certificates are required only if you run kube-proxy to support [an extension API server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/).
{{< /note >}}
etcd also implements mutual TLS to authenticate clients and peers.
diff --git a/content/en/docs/setup/custom-cloud/kubespray.md b/content/en/docs/setup/custom-cloud/kubespray.md
index 11671b501c..7e993ee8c5 100644
--- a/content/en/docs/setup/custom-cloud/kubespray.md
+++ b/content/en/docs/setup/custom-cloud/kubespray.md
@@ -6,7 +6,7 @@ content_template: templates/concept
{{% capture overview %}}
This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-incubator/kubespray).
-
+
Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
* a highly available cluster
@@ -32,7 +32,7 @@ To choose a tool which best fits your use case, read [this comparison](https://g
Provision servers with the following [requirements](https://github.com/kubernetes-incubator/kubespray#requirements):
-* **Ansible v2.4 (or newer) and python-netaddr is installed on the machine that will run Ansible commands**
+* **Ansible v2.5 (or newer) and python-netaddr is installed on the machine that will run Ansible commands**
* **Jinja 2.9 (or newer) is required to run the Ansible Playbooks**
* The target servers must have **access to the Internet** in order to pull docker images
* The target servers are configured to allow **IPv4 forwarding**
@@ -64,7 +64,7 @@ Kubespray provides the ability to customize many aspects of the deployment:
* docker
* rkt
* cri-o
-* Certificate generation methods
+* Certificate generation methods (**Vault being discontinued**)
Kubespray customizations can be made to a [variable file](http://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
@@ -103,7 +103,7 @@ You can upgrade your cluster by running the upgrade-cluster playbook. For more i
You can reset your nodes and wipe out all components installed with Kubespray via the [reset playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/reset.yml).
{{< caution >}}
-**Caution:** When running the reset playbook, be sure not to accidentally target your production cluster!
+When running the reset playbook, be sure not to accidentally target your production cluster!
{{< /caution >}}
## Feedback
diff --git a/content/en/docs/setup/independent/control-plane-flags.md b/content/en/docs/setup/independent/control-plane-flags.md
index ba01d29b4c..eb40dcfa58 100644
--- a/content/en/docs/setup/independent/control-plane-flags.md
+++ b/content/en/docs/setup/independent/control-plane-flags.md
@@ -28,7 +28,7 @@ For more details on each field in the configuration you can navigate to our
## APIServer flags
-For details, see the [reference documentation for kube-apiserver](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/).
+For details, see the [reference documentation for kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/).
Example usage:
```yaml
@@ -46,7 +46,7 @@ apiServerExtraArgs:
## ControllerManager flags
-For details, see the [reference documentation for kube-controller-manager](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/).
+For details, see the [reference documentation for kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/).
Example usage:
```yaml
@@ -63,7 +63,7 @@ controllerManagerExtraArgs:
## Scheduler flags
-For details, see the [reference documentation for kube-scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/).
+For details, see the [reference documentation for kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/).
Example usage:
```yaml
diff --git a/content/en/docs/setup/independent/create-cluster-kubeadm.md b/content/en/docs/setup/independent/create-cluster-kubeadm.md
index e37bea2a1c..8db68b4f83 100644
--- a/content/en/docs/setup/independent/create-cluster-kubeadm.md
+++ b/content/en/docs/setup/independent/create-cluster-kubeadm.md
@@ -99,7 +99,7 @@ timeframe; which also applies to `kubeadm`.
See ["Installing kubeadm"](/docs/setup/independent/install-kubeadm/).
{{< note >}}
-**Note:** If you have already installed kubeadm, run `apt-get update &&
+If you have already installed kubeadm, run `apt-get update &&
apt-get upgrade` or `yum update` to get the latest version of kubeadm.
When you upgrade, the kubelet restarts every few seconds as it waits in a crashloop for
@@ -228,7 +228,7 @@ created, and deleted with the `kubeadm token` command. See the
### Installing a pod network add-on {#pod-network}
{{< caution >}}
-**Caution:** This section contains important information about installation and deployment order. Read it carefully before proceeding.
+This section contains important information about installation and deployment order. Read it carefully before proceeding.
{{< /caution >}}
You must install a pod network add-on so that your pods can communicate with
@@ -245,6 +245,9 @@ support [Network Policy](/docs/concepts/services-networking/networkpolicies/). S
Note that kubeadm sets up a more secure cluster by default and enforces use of [RBAC](/docs/reference/access-authn-authz/rbac/).
Make sure that your network manifest supports RBAC.
+Also, beware, that your Pod network must not overlap with any of the host networks as this can cause issues.
+If you find a collision between your network plugin’s preferred Pod network and some of your host networks, you should think of a suitable CIDR replacement and use that during `kubeadm init` with `--pod-network-cidr` and as a replacement in your network plugin’s YAML.
+
You can install a pod network add-on with the following command:
```bash
@@ -264,8 +267,8 @@ For more information about using Calico, see [Quickstart for Calico on Kubernete
For Calico to work correctly, you need to pass `--pod-network-cidr=192.168.0.0/16` to `kubeadm init` or update the `calico.yml` file to match your Pod network. Note that Calico works on `amd64` only.
```shell
-kubectl apply -f https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/rbac-kdd.yaml
-kubectl apply -f https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/kubernetes-datastore/calico-networking/1.7/calico.yaml
+kubectl apply -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/installation/hosted/rbac-kdd.yaml
+kubectl apply -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/installation/hosted/kubernetes-datastore/calico-networking/1.7/calico.yaml
```
{{% /tab %}}
@@ -275,8 +278,8 @@ Canal uses Calico for policy and Flannel for networking. Refer to the Calico doc
For Canal to work correctly, `--pod-network-cidr=10.244.0.0/16` has to be passed to `kubeadm init`. Note that Canal works on `amd64` only.
```shell
-kubectl apply -f https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/canal/rbac.yaml
-kubectl apply -f https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/canal/canal.yaml
+kubectl apply -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/installation/hosted/canal/rbac.yaml
+kubectl apply -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/installation/hosted/canal/canal.yaml
```
{{% /tab %}}
@@ -465,7 +468,7 @@ The output is similar to this:
```
{{< note >}}
-**Note:** To specify an IPv6 tuple for `:`, IPv6 address must be enclosed in square brackets, for example: `[fd00::101]:2073`.
+To specify an IPv6 tuple for `:`, IPv6 address must be enclosed in square brackets, for example: `[fd00::101]:2073`.
{{< /note >}}
The output should look something like:
@@ -498,7 +501,7 @@ kubectl --kubeconfig ./admin.conf get nodes
```
{{< note >}}
-**Note:** The example above assumes SSH access is enabled for root. If that is not the
+The example above assumes SSH access is enabled for root. If that is not the
case, you can copy the `admin.conf` file to be accessible by some other user
and `scp` using that other user instead.
diff --git a/content/en/docs/setup/independent/high-availability.md b/content/en/docs/setup/independent/high-availability.md
index 226409b48f..e2b6f7b5dc 100644
--- a/content/en/docs/setup/independent/high-availability.md
+++ b/content/en/docs/setup/independent/high-availability.md
@@ -22,9 +22,9 @@ with upgrading your clusters, for example. We encourage you to try either approa
and provide feedback.
{{< caution >}}
-**Caution**: This page does not address running your cluster on a cloud provider.
-In a cloud environment, neither approach documented here works with Service objects
-of type LoadBalancer, or with dynamic PersistentVolumes.
+This page does not address running your cluster on a cloud provider. In a cloud
+environment, neither approach documented here works with Service objects of type
+LoadBalancer, or with dynamic PersistentVolumes.
{{< /caution >}}
{{% /capture %}}
@@ -49,9 +49,8 @@ For the external etcd cluster only, you also need:
- Three additional machines for etcd members
{{< note >}}
-**Note**: The following examples run Calico as the Pod networking provider. If
-you run another networking provider, make sure to replace any default values as
-needed.
+The following examples run Calico as the Pod networking provider. If you run another
+networking provider, make sure to replace any default values as needed.
{{< /note >}}
{{% /capture %}}
@@ -61,8 +60,7 @@ needed.
## First steps for both methods
{{< note >}}
-**Note**: All commands in this guide on any control plane or etcd node should be
-run as root.
+All commands in this guide on any control plane or etcd node should be run as root.
{{< /note >}}
- Find your pod CIDR. For details, see [the CNI network
@@ -102,9 +100,8 @@ run as root.
### Create load balancer for kube-apiserver
{{< note >}}
-**Note**: There are many configurations for load balancers. The following
-example is only one option. Your cluster requirements may need a
-different configuration.
+There are many configurations for load balancers. The following example is only one
+option. Your cluster requirements may need a different configuration.
{{< /note >}}
1. Create a kube-apiserver load balancer with a name that resolves to DNS.
@@ -140,7 +137,7 @@ different configuration.
### Bootstrap the first stacked control plane node
{{< note >}}
-**Note**: Optionally replace `stable` with a different version of Kubernetes, for example `v1.12.0`.
+Optionally replace the string `stable` with a different version of Kubernetes, for example `v1.12.0`.
{{< /note >}}
1. Create a `kubeadm-config.yaml` template file:
@@ -154,6 +151,7 @@ different configuration.
etcd:
local:
extraArgs:
+ name: "CP0_HOSTNAME"
listen-client-urls: "https://127.0.0.1:2379,https://CP0_IP:2379"
advertise-client-urls: "https://CP0_IP:2379"
listen-peer-urls: "https://CP0_IP:2380"
@@ -217,7 +215,7 @@ done
```
{{< note >}}
-**Note**: Remember that your config may differ from this example.
+Remember that your config may differ from this example.
{{< /note >}}
### Add the second stacked control plane node
@@ -233,6 +231,7 @@ done
etcd:
local:
extraArgs:
+ name: "CP1_HOSTNAME"
listen-client-urls: "https://127.0.0.1:2379,https://CP1_IP:2379"
advertise-client-urls: "https://CP1_IP:2379"
listen-peer-urls: "https://CP1_IP:2380"
@@ -292,9 +291,9 @@ done
export CP1_IP=10.0.0.8
export CP1_HOSTNAME=cp1
+ kubeadm alpha phase etcd local --config kubeadm-config.yaml
export KUBECONFIG=/etc/kubernetes/admin.conf
kubectl exec -n kube-system etcd-${CP0_HOSTNAME} -- etcdctl --ca-file /etc/kubernetes/pki/etcd/ca.crt --cert-file /etc/kubernetes/pki/etcd/peer.crt --key-file /etc/kubernetes/pki/etcd/peer.key --endpoints=https://${CP0_IP}:2379 member add ${CP1_HOSTNAME} https://${CP1_IP}:2380
- kubeadm alpha phase etcd local --config kubeadm-config.yaml
```
- This command causes the etcd cluster to become unavailable for a
@@ -323,6 +322,7 @@ done
etcd:
local:
extraArgs:
+ name: "CP2_HOSTNAME"
listen-client-urls: "https://127.0.0.1:2379,https://CP2_IP:2379"
advertise-client-urls: "https://CP2_IP:2379"
listen-peer-urls: "https://CP2_IP:2380"
@@ -431,6 +431,10 @@ done
### Set up the first control plane node
+{{< note >}}
+Optionally replace the string `stable` with a different version of Kubernetes, for example `v1.11.3`.
+{{< /note >}}
+
1. Extract the etcd certificates
mkdir -p /etc/kubernetes/pki
@@ -438,10 +442,6 @@ done
1. Create a `kubeadm-config.yaml`:
-{{< note >}}
-**Note**: Optionally replace `stable` with a different version of Kubernetes, for example `v1.11.3`.
-{{< /note >}}
-
apiVersion: kubeadm.k8s.io/v1alpha3
kind: ClusterConfiguration
kubernetesVersion: stable
@@ -470,7 +470,7 @@ done
- `ETCD_2_IP`
1. Run `kubeadm init --config kubeadm-config.yaml`
-1. Copy the output join commamnd.
+1. Copy the output from the join command
### Copy required files to the correct locations
diff --git a/content/en/docs/setup/independent/install-kubeadm.md b/content/en/docs/setup/independent/install-kubeadm.md
index e79a1635a7..23cc949dc9 100644
--- a/content/en/docs/setup/independent/install-kubeadm.md
+++ b/content/en/docs/setup/independent/install-kubeadm.md
@@ -226,7 +226,7 @@ If you are using a different CRI, you have to modify the file
`/etc/default/kubelet` with your `cgroup-driver` value, like so:
```bash
-KUBELET_KUBEADM_EXTRA_ARGS=--cgroup-driver=
+KUBELET_EXTRA_ARGS=--cgroup-driver=
```
This file will be used by `kubeadm init` and `kubeadm join` to source extra
diff --git a/content/en/docs/setup/independent/kubelet-integration.md b/content/en/docs/setup/independent/kubelet-integration.md
index cd56d6c4b4..9b55041733 100644
--- a/content/en/docs/setup/independent/kubelet-integration.md
+++ b/content/en/docs/setup/independent/kubelet-integration.md
@@ -11,8 +11,8 @@ weight: 40
{{< feature-state for_k8s_version="1.11" state="stable" >}}
The lifecycle of the kubeadm CLI tool is decoupled from the
-[Kubernetes Node Agent](/docs/reference/command-line-tools-reference/kubelet), which is a daemon that runs
-on each Kubernetes master or Node. The kubeadm CLI tool is executed by the user when Kubernetes is
+[kubelet](/docs/reference/command-line-tools-reference/kubelet), which is a daemon that runs
+on each node within the Kubernetes cluster. The kubeadm CLI tool is executed by the user when Kubernetes is
initialized or upgraded, whereas the kubelet is always running in the background.
Since the kubelet is a daemon, it needs to be maintained by some kind of a init
@@ -52,7 +52,7 @@ Virtual IPs for services are now allocated from this subnet. You also need to se
by the kubelet, using the `--cluster-dns` flag. This setting needs to be the same for every kubelet
on every manager and Node in the cluster. The kubelet provides a versioned, structured API object
that can configure most parameters in the kubelet and push out this configuration to each running
-kubelet in the cluster. This object is called **the kubelet's ComponentConfig**.
+kubelet in the cluster. This object is called **the kubelet's ComponentConfig**.
The ComponentConfig allows the user to specify flags such as the cluster DNS IP addresses expressed as
a list of values to a camelCased key, illustrated by the following example:
@@ -82,7 +82,7 @@ networking, or other host-specific parameters. The following list provides a few
- Currently, the kubelet cannot automatically detects the cgroup driver used by the CRI runtime,
but the value of `--cgroup-driver` must match the cgroup driver used by the CRI runtime to ensure
the health of the kubelet.
-
+
- Depending on the CRI runtime your cluster uses, you may need to specify different flags to the kubelet.
For instance, when using Docker, you need to specify flags such as `--network-plugin=cni`, but if you
are using an external runtime, you need to specify `--container-runtime=remote` and specify the CRI
diff --git a/content/en/docs/setup/independent/setup-ha-etcd-with-kubeadm.md b/content/en/docs/setup/independent/setup-ha-etcd-with-kubeadm.md
index 9e312d5464..2d5ea7c059 100644
--- a/content/en/docs/setup/independent/setup-ha-etcd-with-kubeadm.md
+++ b/content/en/docs/setup/independent/setup-ha-etcd-with-kubeadm.md
@@ -38,7 +38,7 @@ The general approach is to generate all certs on one node and only distribute
the *necessary* files to the other nodes.
{{< note >}}
-**Note:** kubeadm contains all the necessary crytographic machinery to generate
+kubeadm contains all the necessary crytographic machinery to generate
the certificates described below; no other cryptographic tooling is required for
this example.
{{< /note >}}
diff --git a/content/en/docs/setup/independent/troubleshooting-kubeadm.md b/content/en/docs/setup/independent/troubleshooting-kubeadm.md
index 1f5878efac..a5ab81a62c 100644
--- a/content/en/docs/setup/independent/troubleshooting-kubeadm.md
+++ b/content/en/docs/setup/independent/troubleshooting-kubeadm.md
@@ -258,8 +258,11 @@ kubectl -n kube-system get deployment coredns -o yaml | \
kubectl apply -f -
```
+Another cause for CoreDNS to have `CrashLoopBackOff` is when a CoreDNS Pod deployed in Kubernetes detects a loop. [A number of workarounds](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters)
+are available to avoid Kubernetes trying to restart the CoreDNS Pod every time CoreDNS detects the loop and exits.
+
{{< warning >}}
-**Warning**: Disabling SELinux or setting `allowPrivilegeEscalation` to `true` can compromise
+Disabling SELinux or setting `allowPrivilegeEscalation` to `true` can compromise
the security of your cluster.
{{< /warning >}}
diff --git a/content/en/docs/setup/minikube.md b/content/en/docs/setup/minikube.md
index 09ecfc62cc..7f1cc4e4b8 100644
--- a/content/en/docs/setup/minikube.md
+++ b/content/en/docs/setup/minikube.md
@@ -4,13 +4,18 @@ reviewers:
- balopat
- aaron-prindle
title: Running Kubernetes Locally via Minikube
+content_template: templates/concept
---
+{{% capture overview %}}
+
Minikube is a tool that makes it easy to run Kubernetes locally. Minikube runs a single-node Kubernetes cluster inside a VM on your laptop for users looking to try out Kubernetes or develop with it day-to-day.
-{{< toc >}}
+{{% /capture %}}
-### Minikube Features
+{{% capture body %}}
+
+## Minikube Features
* Minikube supports Kubernetes features such as:
* DNS
@@ -27,7 +32,7 @@ See [Installing Minikube](/docs/tasks/tools/install-minikube/).
## Quickstart
-Here's a brief demo of minikube usage.
+Here's a brief demo of Minikube usage.
If you want to change the VM driver add the appropriate `--vm-driver=xxx` flag to `minikube start`. Minikube supports
the following drivers:
@@ -164,30 +169,31 @@ This will use an alternative minikube ISO image containing both rkt, and Docker,
See [DRIVERS](https://git.k8s.io/minikube/docs/drivers.md) for details on supported drivers and how to install
plugins, if required.
-### Reusing the Docker daemon
+### Use local images by re-using the Docker daemon
-When using a single VM of Kubernetes, it's really handy to reuse the minikube's built-in Docker daemon; as this means you don't have to build a docker registry on your host machine and push the image into it - you can just build inside the same docker daemon as minikube which speeds up local experiments. Just make sure you tag your Docker image with something other than 'latest' and use that tag while you pull the image. Otherwise, if you do not specify version of your image, it will be assumed as `:latest`, with pull image policy of `Always` correspondingly, which may eventually result in `ErrImagePull` as you may not have any versions of your Docker image out there in the default docker registry (usually DockerHub) yet.
+When using a single VM of Kubernetes, it's really handy to reuse the Minikube's built-in Docker daemon; as this means you don't have to build a docker registry on your host machine and push the image into it - you can just build inside the same docker daemon as minikube which speeds up local experiments. Just make sure you tag your Docker image with something other than 'latest' and use that tag while you pull the image. Otherwise, if you do not specify version of your image, it will be assumed as `:latest`, with pull image policy of `Always` correspondingly, which may eventually result in `ErrImagePull` as you may not have any versions of your Docker image out there in the default docker registry (usually DockerHub) yet.
To be able to work with the docker daemon on your mac/linux host use the `docker-env command` in your shell:
-```
+```shell
eval $(minikube docker-env)
```
+
You should now be able to use docker on the command line on your host mac/linux machine talking to the docker daemon inside the minikube VM:
-```
+```shell
docker ps
```
On Centos 7, docker may report the following error:
-```
+```shell
Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory
```
-The fix is to update /etc/sysconfig/docker to ensure that minikube's environment changes are respected:
+The fix is to update /etc/sysconfig/docker to ensure that Minikube's environment changes are respected:
-```
+```shell
< DOCKER_CERT_PATH=/etc/docker
---
> if [ -z "${DOCKER_CERT_PATH}" ]; then
@@ -195,19 +201,19 @@ The fix is to update /etc/sysconfig/docker to ensure that minikube's environment
> fi
```
-Remember to turn off the imagePullPolicy:Always, as otherwise Kubernetes won't use images you built locally.
+Remember to turn off the imagePullPolicy:Always, otherwise Kubernetes won't use images you built locally.
## Managing your Cluster
### Starting a Cluster
The `minikube start` command can be used to start your cluster.
-This command creates and configures a virtual machine that runs a single-node Kubernetes cluster.
+This command creates and configures a Virtual Machine that runs a single-node Kubernetes cluster.
This command also configures your [kubectl](/docs/user-guide/kubectl-overview/) installation to communicate with this cluster.
-If you are behind a web proxy, you will need to pass this information in e.g. via
+If you are behind a web proxy, you will need to pass this information to the `minikube start` command:
-```
+```shell
https_proxy= minikube start --docker-env http_proxy= --docker-env https_proxy= --docker-env no_proxy=192.168.99.0/24
```
@@ -252,23 +258,23 @@ To change the `MaxPods` setting to 5 on the Kubelet, pass this flag: `--extra-co
This feature also supports nested structs. To change the `LeaderElection.LeaderElect` setting to `true` on the scheduler, pass this flag: `--extra-config=scheduler.LeaderElection.LeaderElect=true`.
-To set the `AuthorizationMode` on the `apiserver` to `RBAC`, you can use: `--extra-config=apiserver.Authorization.Mode=RBAC`.
+To set the `AuthorizationMode` on the `apiserver` to `RBAC`, you can use: `--extra-config=apiserver.authorization-mode=RBAC`.
### Stopping a Cluster
The `minikube stop` command can be used to stop your cluster.
-This command shuts down the minikube virtual machine, but preserves all cluster state and data.
+This command shuts down the Minikube Virtual Machine, but preserves all cluster state and data.
Starting the cluster again will restore it to it's previous state.
### Deleting a Cluster
The `minikube delete` command can be used to delete your cluster.
-This command shuts down and deletes the minikube virtual machine. No data or state is preserved.
+This command shuts down and deletes the Minikube Virtual Machine. No data or state is preserved.
## Interacting with Your Cluster
### Kubectl
-The `minikube start` command creates a "[kubectl context](/docs/reference/generated/kubectl/kubectl-commands/#-em-set-context-em-)" called "minikube".
-This context contains the configuration to communicate with your minikube cluster.
+The `minikube start` command creates a [kubectl context](/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-) called "minikube".
+This context contains the configuration to communicate with your Minikube cluster.
Minikube sets this context to default automatically, but if you need to switch back to it in the future, run:
@@ -278,7 +284,7 @@ Or pass the context on each command like this: `kubectl get pods --context=minik
### Dashboard
-To access the [Kubernetes Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/), run this command in a shell after starting minikube to get the address:
+To access the [Kubernetes Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/), run this command in a shell after starting Minikube to get the address:
```shell
minikube dashboard
@@ -286,7 +292,7 @@ minikube dashboard
### Services
-To access a service exposed via a node port, run this command in a shell after starting minikube to get the address:
+To access a service exposed via a node port, run this command in a shell after starting Minikube to get the address:
```shell
minikube service [-n NAMESPACE] [--url] NAME
@@ -294,7 +300,7 @@ minikube service [-n NAMESPACE] [--url] NAME
## Networking
-The minikube VM is exposed to the host system via a host-only IP address, that can be obtained with the `minikube ip` command.
+The Minikube VM is exposed to the host system via a host-only IP address, that can be obtained with the `minikube ip` command.
Any services of type `NodePort` can be accessed over that IP address, on the NodePort.
To determine the NodePort for your service, you can use a `kubectl` command like this:
@@ -303,13 +309,13 @@ To determine the NodePort for your service, you can use a `kubectl` command like
## Persistent Volumes
Minikube supports [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) of type `hostPath`.
-These PersistentVolumes are mapped to a directory inside the minikube VM.
+These PersistentVolumes are mapped to a directory inside the Minikube VM.
The Minikube VM boots into a tmpfs, so most directories will not be persisted across reboots (`minikube stop`).
However, Minikube is configured to persist files stored under the following host directories:
* `/data`
-* `/var/lib/localkube`
+* `/var/lib/minikube`
* `/var/lib/docker`
Here is an example PersistentVolume config to persist data in the `/data` directory:
@@ -331,7 +337,9 @@ spec:
## Mounted Host Folders
Some drivers will mount a host folder within the VM so that you can easily share files between the VM and host. These are not configurable at the moment and different for the driver and OS you are using.
-**Note:** Host folder sharing is not implemented in the KVM driver yet.
+{{< note >}}
+Host folder sharing is not implemented in the KVM driver yet.
+{{< /note >}}
| Driver | OS | HostFolder | VM |
| --- | --- | --- | --- |
@@ -341,19 +349,18 @@ Some drivers will mount a host folder within the VM so that you can easily share
| VMware Fusion | macOS | /Users | /Users |
| Xhyve | macOS | /Users | /Users |
-
## Private Container Registries
To access a private container registry, follow the steps on [this page](/docs/concepts/containers/images/).
-We recommend you use `ImagePullSecrets`, but if you would like to configure access on the minikube VM you can place the `.dockercfg` in the `/home/docker` directory or the `config.json` in the `/home/docker/.docker` directory.
+We recommend you use `ImagePullSecrets`, but if you would like to configure access on the Minikube VM you can place the `.dockercfg` in the `/home/docker` directory or the `config.json` in the `/home/docker/.docker` directory.
## Add-ons
-In order to have minikube properly start or restart custom addons,
-place the addons you wish to be launched with minikube in the `~/.minikube/addons`
-directory. Addons in this folder will be moved to the minikube VM and
-launched each time minikube is started or restarted.
+In order to have Minikube properly start or restart custom addons,
+place the addons you wish to be launched with Minikube in the `~/.minikube/addons`
+directory. Addons in this folder will be moved to the Minikube VM and
+launched each time Minikube is started or restarted.
## Using Minikube with an HTTP Proxy
@@ -370,7 +377,7 @@ $ minikube start --docker-env http_proxy=http://$YOURPROXY:PORT \
--docker-env https_proxy=https://$YOURPROXY:PORT
```
-If your Virtual Machine address is 192.168.99.100, then chances are your proxy settings will prevent kubectl from directly reaching it.
+If your Virtual Machine address is 192.168.99.100, then chances are your proxy settings will prevent `kubectl` from directly reaching it.
To by-pass proxy configuration for this IP address, you should modify your no_proxy settings. You can do so with:
```shell
@@ -385,18 +392,21 @@ $ export no_proxy=$no_proxy,$(minikube ip)
## Design
-Minikube uses [libmachine](https://github.com/docker/machine/tree/master/libmachine) for provisioning VMs, and [localkube](https://git.k8s.io/minikube/pkg/localkube) (originally written and donated to this project by [RedSpread](https://github.com/redspread)) for running the cluster.
+Minikube uses [libmachine](https://github.com/docker/machine/tree/master/libmachine) for provisioning VMs, and [kubeadm](https://github.com/kubernetes/kubeadm) to provision a Kubernetes cluster.
-For more information about minikube, see the [proposal](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md).
+For more information about Minikube, see the [proposal](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md).
-## Additional Links:
-* **Goals and Non-Goals**: For the goals and non-goals of the minikube project, please see our [roadmap](https://git.k8s.io/minikube/docs/contributors/roadmap.md).
+## Additional Links
+
+* **Goals and Non-Goals**: For the goals and non-goals of the Minikube project, please see our [roadmap](https://git.k8s.io/minikube/docs/contributors/roadmap.md).
* **Development Guide**: See [CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md) for an overview of how to send pull requests.
-* **Building Minikube**: For instructions on how to build/test minikube from source, see the [build guide](https://git.k8s.io/minikube/docs/contributors/build_guide.md)
-* **Adding a New Dependency**: For instructions on how to add a new dependency to minikube see the [adding dependencies guide](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md)
-* **Adding a New Addon**: For instruction on how to add a new addon for minikube see the [adding an addon guide](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md)
-* **Updating Kubernetes**: For instructions on how to update kubernetes see the [updating Kubernetes guide](https://git.k8s.io/minikube/docs/contributors/updating_kubernetes.md)
+* **Building Minikube**: For instructions on how to build/test Minikube from source, see the [build guide](https://git.k8s.io/minikube/docs/contributors/build_guide.md).
+* **Adding a New Dependency**: For instructions on how to add a new dependency to Minikube see the [adding dependencies guide](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md).
+* **Adding a New Addon**: For instruction on how to add a new addon for Minikube see the [adding an addon guide](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md).
+* **Updating Kubernetes**: For instructions on how to update Kubernetes see the [updating Kubernetes guide](https://git.k8s.io/minikube/docs/contributors/updating_kubernetes.md).
## Community
-Contributions, questions, and comments are all welcomed and encouraged! minikube developers hang out on [Slack](https://kubernetes.slack.com) in the #minikube channel (get an invitation [here](http://slack.kubernetes.io/)). We also have the [kubernetes-dev Google Groups mailing list](https://groups.google.com/forum/#!forum/kubernetes-dev). If you are posting to the list please prefix your subject with "minikube: ".
+Contributions, questions, and comments are all welcomed and encouraged! Minikube developers hang out on [Slack](https://kubernetes.slack.com) in the #minikube channel (get an invitation [here](http://slack.kubernetes.io/)). We also have the [kubernetes-dev Google Groups mailing list](https://groups.google.com/forum/#!forum/kubernetes-dev). If you are posting to the list please prefix your subject with "minikube: ".
+
+{{% /capture %}}
\ No newline at end of file
diff --git a/content/en/docs/setup/multiple-zones.md b/content/en/docs/setup/multiple-zones.md
index 5256d703b0..81d4a32ded 100644
--- a/content/en/docs/setup/multiple-zones.md
+++ b/content/en/docs/setup/multiple-zones.md
@@ -199,12 +199,14 @@ kubectl create -f - <}}
+For version 1.3+ Kubernetes will distribute dynamic PV claims across
the configured zones. For version 1.2, dynamic persistent volumes were
always created in the zone of the cluster master
(here us-central1-a / us-west-2a); that issue
([#23330](https://github.com/kubernetes/kubernetes/issues/23330))
was addressed in 1.3+.
+{{< /note >}}
Now lets validate that Kubernetes automatically labeled the zone & region the PV was created in.
diff --git a/content/en/docs/setup/on-premises-metal/krib.md b/content/en/docs/setup/on-premises-metal/krib.md
index e37376e464..4438b6a7e0 100644
--- a/content/en/docs/setup/on-premises-metal/krib.md
+++ b/content/en/docs/setup/on-premises-metal/krib.md
@@ -11,7 +11,7 @@ This guide helps to install a Kubernetes cluster hosted on bare metal with [Digi
Digital Rebar Provision (DRP) is an integrated Golang DHCP, bare metal provisioning (PXE/iPXE) and workflow automation platform. While [DRP can be used to invoke](https://provision.readthedocs.io/en/tip/doc/integrations/ansible.html) [kubespray](../kubespray), it also offers a self-contained Kubernetes installation known as [KRIB (Kubernetes Rebar Integrated Bootstrap)](https://github.com/digitalrebar/provision-content/tree/master/krib).
{{< note >}}
-**Note:** KRIB is not a _stand-alone_ installer: Digital Rebar templates drive a standard *[kubeadm](/docs/admin/kubeadm/)* configuration that manages the Kubernetes installation with the [Digital Rebar cluster pattern](https://provision.readthedocs.io/en/tip/doc/arch/cluster.html#rs-cluster-pattern) to elect leaders _without external supervision_.
+KRIB is not a _stand-alone_ installer: Digital Rebar templates drive a standard *[kubeadm](/docs/admin/kubeadm/)* configuration that manages the Kubernetes installation with the [Digital Rebar cluster pattern](https://provision.readthedocs.io/en/tip/doc/arch/cluster.html#rs-cluster-pattern) to elect leaders _without external supervision_.
{{< /note >}}
@@ -43,7 +43,7 @@ Upload the KRIB Content bundle (or build from [source](https://github.com/digita
### (3/5) Start your cluster deployment
{{< note >}}
-**Note:** KRIB documentation is dynamically generated from the source and will be more up to date than this guide.
+KRIB documentation is dynamically generated from the source and will be more up to date than this guide.
{{< /note >}}
Following the [KRIB documentation](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html), create a Profile for your cluster and assign your target servers into the cluster Profile. The Profile must set `krib\cluster-name` and `etcd\cluster-name` Params to be the name of the Profile. Cluster configuration choices can be made by adding additional Params to the Profile; however, safe defaults are provided for all Params.
@@ -86,7 +86,7 @@ You can add servers into your cluster by adding the cluster Profile to the serve
You can reset your cluster and wipe out all configuration and TLS certificates using the `krib-reset-cluster` Workflow on any of the servers in the cluster.
{{< caution >}}
-**Caution:** When running the reset Workflow, be sure not to accidentally target your production cluster!
+When running the reset Workflow, be sure not to accidentally target your production cluster!
{{< /caution >}}
## Feedback
diff --git a/content/en/docs/setup/pick-right-solution.md b/content/en/docs/setup/pick-right-solution.md
index 1686f43f4c..a043c749a9 100644
--- a/content/en/docs/setup/pick-right-solution.md
+++ b/content/en/docs/setup/pick-right-solution.md
@@ -76,6 +76,10 @@ a Kubernetes cluster from scratch.
* [Stackpoint.io](https://stackpoint.io) provides Kubernetes infrastructure automation and management for multiple public clouds.
+* [SysEleven MetaKube](https://www.syseleven.io/products-services/managed-kubernetes/) offers managed Kubernetes as a service powered on our OpenStack public cloud. It includes lifecycle management, administration dashboards, monitoring, autoscaling and much more.
+
+* [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) is an enterprise Kubernetes-as-a-Service offering in the VMware Cloud Services portfolio that provides easy to use, secure by default, cost effective, SaaS-based Kubernetes clusters.
+
## Turnkey Cloud Solutions
These solutions allow you to create Kubernetes clusters on a range of Cloud IaaS providers with only a
@@ -210,7 +214,7 @@ AWS | Juju | Ubuntu | flannel/calico/canal | [docs]
Azure | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
GCE | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
Oracle Cloud | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
-Rackspace | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
+Rackspace | custom | CoreOS | flannel/calico/canal | [docs](https://developer.rackspace.com/docs/rkaas/latest/) | [Commercial](https://www.rackspace.com/managed-kubernetes)
VMware vSphere | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
Bare Metal | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes)
AWS | Saltstack | Debian | AWS | [docs](/docs/setup/turnkey/aws/) | Community ([@justinsb](https://github.com/justinsb))
@@ -225,10 +229,10 @@ Alibaba Cloud Container Service For Kubernetes | ROS | CentOS | flannel/T
Agile Stacks | Terraform | CoreOS | multi-support | [docs](https://www.agilestacks.com/products/kubernetes) | Commercial
IBM Cloud Kubernetes Service | | Ubuntu | calico | [docs](https://console.bluemix.net/docs/containers/container_index.html) | Commercial
Digital Rebar | kubeadm | any | metal | [docs](/docs/setup/on-premises-metal/krib/) | Community ([@digitalrebar](https://github.com/digitalrebar))
-
+VMware Cloud PKS | | Photon OS | Canal | [docs](https://docs.vmware.com/en/VMware-Kubernetes-Engine/index.html) | Commercial
{{< note >}}
-**Note:** The above table is ordered by version test/used in nodes, followed by support level.
+The above table is ordered by version test/used in nodes, followed by support level.
{{< /note >}}
### Definition of columns
@@ -249,7 +253,6 @@ Digital Rebar | kubeadm | any | metal | [docs](/docs/setup/
* **Inactive**: Not actively maintained. Not recommended for first-time Kubernetes users, and may be removed.
* **Notes** has other relevant information, such as the version of Kubernetes used.
-
[1]: https://gist.github.com/erictune/4cabc010906afbcc5061
diff --git a/content/en/docs/setup/building-from-source.md b/content/en/docs/setup/release/building-from-source.md
similarity index 100%
rename from content/en/docs/setup/building-from-source.md
rename to content/en/docs/setup/release/building-from-source.md
diff --git a/content/en/docs/setup/release/notes.md b/content/en/docs/setup/release/notes.md
index 45f6f83ae1..c79d745f1b 100644
--- a/content/en/docs/setup/release/notes.md
+++ b/content/en/docs/setup/release/notes.md
@@ -1,3 +1,6 @@
+---
+title: v1.12 Release Notes
+---
- [v1.12.0-rc.2](#v1120-rc2)
- [Downloads for v1.12.0-rc.2](#downloads-for-v1120-rc2)
@@ -164,76 +167,83 @@ filename | sha256 hash
### Action Required
* Service events are now added in azure-cloud-provider for easily identify the underground errors of Azure API. ([#68212](https://github.com/kubernetes/kubernetes/pull/68212), [@feiskyer](https://github.com/feiskyer))
- * Action required: The following clusterrole and clusterrolebinding should be applied:
- * kind: List
- * apiVersion: v1
- * items:
- * - apiVersion: rbac.authorization.k8s.io/v1
- * kind: ClusterRole
- * metadata:
- * labels:
- * kubernetes.io/cluster-service: "true"
- * name: system:azure-cloud-provider
- * rules:
- * - apiGroups: [""]
- * resources: ["events"]
- * verbs:
- * - create
- * - patch
- * - update
- * - apiVersion: rbac.authorization.k8s.io/v1
- * kind: ClusterRoleBinding
- * metadata:
- * labels:
- * kubernetes.io/cluster-service: "true"
- * name: system:azure-cloud-provider
- * roleRef:
- * apiGroup: rbac.authorization.k8s.io
- * kind: ClusterRole
- * name: system:azure-cloud-provider
- * subjects:
- * - kind: ServiceAccount
- * name: azure-cloud-provider
- * namespace: kube-system
- * If the clusterrole with same has already been provisioned (e.g. for accessing azurefile secrets), then the above yaml should be merged togather, e.g.
- * kind: List
- * apiVersion: v1
- * items:
- * - apiVersion: rbac.authorization.k8s.io/v1
- * kind: ClusterRole
- * metadata:
- * labels:
- * kubernetes.io/cluster-service: "true"
- * name: system:azure-cloud-provider
- * rules:
- * - apiGroups: [""]
- * resources: ["events"]
- * verbs:
- * - create
- * - patch
- * - update
- * - apiGroups: [""]
- * resources: ["secrets"]
- * verbs:
- * - get
- * - create
- * - apiVersion: rbac.authorization.k8s.io/v1
- * kind: ClusterRoleBinding
- * metadata:
- * labels:
- * kubernetes.io/cluster-service: "true"
- * name: system:azure-cloud-provider
- * roleRef:
- * apiGroup: rbac.authorization.k8s.io
- * kind: ClusterRole
- * name: system:azure-cloud-provider
- * subjects:
- * - kind: ServiceAccount
- * name: azure-cloud-provider
- * namespace: kube-system
- * - kind: ServiceAccount
- * name: persistent-volume-binder
- * namespace: kube-system
+ * Action required: The following clusterrole and clusterrolebinding should be applied:
+
+ ```yaml
+ kind: List
+ apiVersion: v1
+ items:
+ - apiVersion: rbac.authorization.k8s.io/v1
+ kind: ClusterRole
+ metadata:
+ labels:
+ kubernetes.io/cluster-service: "true"
+ name: system:azure-cloud-provider
+ rules:
+ - apiGroups: [""]
+ resources: ["events"]
+ verbs:
+ - create
+ - patch
+ - update
+ - apiVersion: rbac.authorization.k8s.io/v1
+ kind: ClusterRoleBinding
+ metadata:
+ labels:
+ kubernetes.io/cluster-service: "true"
+ name: system:azure-cloud-provider
+ roleRef:
+ apiGroup: rbac.authorization.k8s.io
+ kind: ClusterRole
+ name: system:azure-cloud-provider
+ subjects:
+ - kind: ServiceAccount
+ name: azure-cloud-provider
+ namespace: kube-system
+ ```
+
+ * If the clusterrole with same has already been provisioned (e.g. for accessing azurefile secrets), then the above yaml should be merged together, e.g.
+
+ ```yaml
+ kind: List
+ apiVersion: v1
+ items:
+ - apiVersion: rbac.authorization.k8s.io/v1
+ kind: ClusterRole
+ metadata:
+ labels:
+ kubernetes.io/cluster-service: "true"
+ name: system:azure-cloud-provider
+ rules:
+ - apiGroups: [""]
+ resources: ["events"]
+ verbs:
+ - create
+ - patch
+ - update
+ - apiGroups: [""]
+ resources: ["secrets"]
+ verbs:
+ - get
+ - create
+ - apiVersion: rbac.authorization.k8s.io/v1
+ kind: ClusterRoleBinding
+ metadata:
+ labels:
+ kubernetes.io/cluster-service: "true"
+ name: system:azure-cloud-provider
+ roleRef:
+ apiGroup: rbac.authorization.k8s.io
+ kind: ClusterRole
+ name: system:azure-cloud-provider
+ subjects:
+ - kind: ServiceAccount
+ name: azure-cloud-provider
+ namespace: kube-system
+ - kind: ServiceAccount
+ name: persistent-volume-binder
+ namespace: kube-system
+ ```
### Other notable changes
@@ -556,7 +566,7 @@ filename | sha256 hash
* The PodShareProcessNamespace feature to configure PID namespace sharing within a pod has been promoted to beta. ([#66507](https://github.com/kubernetes/kubernetes/pull/66507), [@verb](https://github.com/verb))
* `kubectl create {clusterrole,role}`'s `--resources` flag supports asterisk to specify all resources. ([#62945](https://github.com/kubernetes/kubernetes/pull/62945), [@nak3](https://github.com/nak3))
* Bump up version number of debian-base, debian-hyperkube-base and debian-iptables. ([#67026](https://github.com/kubernetes/kubernetes/pull/67026), [@satyasm](https://github.com/satyasm))
- * Also updates dependencies of users of debian-base.
+ * Also updates dependencies of users of debian-base.
* debian-base version 0.3.1 is already available.
* DynamicProvisioningScheduling and VolumeScheduling is now supported for Azure managed disks. Feature gates DynamicProvisioningScheduling and VolumeScheduling should be enabled before using this feature. ([#67121](https://github.com/kubernetes/kubernetes/pull/67121), [@feiskyer](https://github.com/feiskyer))
* kube-apiserver now includes all registered API groups in discovery, including registered extension API group/versions for unavailable extension API servers. ([#66932](https://github.com/kubernetes/kubernetes/pull/66932), [@nilebox](https://github.com/nilebox))
diff --git a/content/en/docs/setup/scratch.md b/content/en/docs/setup/scratch.md
index 8645a487ab..80b0dbf6ac 100644
--- a/content/en/docs/setup/scratch.md
+++ b/content/en/docs/setup/scratch.md
@@ -167,10 +167,8 @@ You can use a Kubernetes binary release (recommended) or build your Kubernetes b
Download the [latest binary release](https://github.com/kubernetes/kubernetes/releases/latest) and unzip it.
Server binary tarballs are no longer included in the Kubernetes final tarball, so you will need to locate and run
-`./kubernetes/cluster/get-kube-binaries.sh` to download the client and server binaries.
-Then locate `./kubernetes/server/kubernetes-server-linux-amd64.tar.gz` and unzip *that*.
-Then, within the second set of unzipped files, locate `./kubernetes/server/bin`, which contains
-all the necessary binaries.
+`./kubernetes/cluster/get-kube-binaries.sh` to download and extract the client and server binaries.
+Then locate `./kubernetes/server/bin`, which contains all the necessary binaries.
#### Selecting Images
@@ -487,11 +485,11 @@ You will need to run one or more instances of etcd.
- Not highly available, but easy to restore - Run one etcd instance, with its log written to a directory backed
by durable storage (RAID, GCE PD).
- {{< note >}}**Note:** May result in operations outages in case of
+ {{< note >}}May result in operations outages in case of
instance outage. {{< /note >}}
- Highly available - Run 3 or 5 etcd instances with non durable storage.
- {{< note >}}**Note:** Log can be written to non-durable storage
+ {{< note >}}Log can be written to non-durable storage
because storage is replicated.{{< /note >}}
See [cluster-troubleshooting](/docs/admin/cluster-troubleshooting/) for more discussion on factors affecting cluster
diff --git a/content/en/docs/setup/turnkey/azure.md b/content/en/docs/setup/turnkey/azure.md
index 534f1a5536..028bab47b7 100644
--- a/content/en/docs/setup/turnkey/azure.md
+++ b/content/en/docs/setup/turnkey/azure.md
@@ -5,25 +5,25 @@ reviewers:
title: Running Kubernetes on Azure
---
-## Azure Container Service
+## Azure Kubernetes Service (AKS)
-The [Azure Container Service](https://azure.microsoft.com/en-us/services/container-service/) offers simple
-deployments of one of three open source orchestrators: DC/OS, Swarm, and Kubernetes clusters.
+The [Azure Kubernetes Service](https://azure.microsoft.com/en-us/services/kubernetes-service/) offers simple
+deployments for Kubernetes clusters.
-For an example of deploying a Kubernetes cluster onto Azure via the Azure Container Service:
+For an example of deploying a Kubernetes cluster onto Azure via the Azure Kubernetes Service:
-**[Microsoft Azure Container Service - Kubernetes Walkthrough](https://docs.microsoft.com/en-us/azure/aks/intro-kubernetes)**
+**[Microsoft Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/intro-kubernetes)**
## Custom Deployments: ACS-Engine
-The core of the Azure Container Service is **open source** and available on GitHub for the community
+The core of the Azure Kubernetes Service is **open source** and available on GitHub for the community
to use and contribute to: **[ACS-Engine](https://github.com/Azure/acs-engine)**.
-ACS-Engine is a good choice if you need to make customizations to the deployment beyond what the Azure Container
+ACS-Engine is a good choice if you need to make customizations to the deployment beyond what the Azure Kubernetes
Service officially supports. These customizations include deploying into existing virtual networks, utilizing multiple
-agent pools, and more. Some community contributions to ACS-Engine may even become features of the Azure Container Service.
+agent pools, and more. Some community contributions to ACS-Engine may even become features of the Azure Kubernetes Service.
-The input to ACS-Engine is similar to the ARM template syntax used to deploy a cluster directly with the Azure Container Service.
+The input to ACS-Engine is similar to the ARM template syntax used to deploy a cluster directly with the Azure Kubernetes Service.
The resulting output is an Azure Resource Manager Template that can then be checked into source control and can then be used
to deploy Kubernetes clusters into Azure.
@@ -36,4 +36,3 @@ The CoreOS Tectonic Installer for Azure is **open source** and available on GitH
Tectonic Installer is a good choice when you need to make cluster customizations as it is built on [Hashicorp's Terraform](https://www.terraform.io/docs/providers/azurerm/) Azure Resource Manager (ARM) provider. This enables users to customize or integrate using familiar Terraform tooling.
You can get started using the [Tectonic Installer for Azure Guide](https://coreos.com/tectonic/docs/latest/install/azure/azure-terraform.html).
-
diff --git a/content/en/docs/setup/turnkey/gce.md b/content/en/docs/setup/turnkey/gce.md
index 85d659c47e..752a8785c0 100644
--- a/content/en/docs/setup/turnkey/gce.md
+++ b/content/en/docs/setup/turnkey/gce.md
@@ -96,7 +96,7 @@ gcloud components install kubectl
```
{{< note >}}
-**Note:** The kubectl version bundled with `gcloud` may be older than the one
+The kubectl version bundled with `gcloud` may be older than the one
downloaded by the get.k8s.io install script. See [Installing kubectl](/docs/tasks/kubectl/install/)
document to see how you can set up the latest `kubectl` on your workstation.
{{< /note >}}
@@ -134,11 +134,11 @@ You'll see a list of pods that looks something like this (the name specifics wil
```shell
NAMESPACE NAME READY STATUS RESTARTS AGE
+kube-system coredns-5f4fbb68df-mc8z8 1/1 Running 0 15m
kube-system fluentd-cloud-logging-kubernetes-minion-63uo 1/1 Running 0 14m
kube-system fluentd-cloud-logging-kubernetes-minion-c1n9 1/1 Running 0 14m
kube-system fluentd-cloud-logging-kubernetes-minion-c4og 1/1 Running 0 14m
kube-system fluentd-cloud-logging-kubernetes-minion-ngua 1/1 Running 0 14m
-kube-system kube-dns-v5-7ztia 3/3 Running 0 15m
kube-system kube-ui-v1-curt1 1/1 Running 0 15m
kube-system monitoring-heapster-v5-ex4u3 1/1 Running 1 15m
kube-system monitoring-influx-grafana-v1-piled 2/2 Running 0 15m
diff --git a/content/en/docs/sitemap.md b/content/en/docs/sitemap.md
index a65bd4f01b..133f426a6b 100644
--- a/content/en/docs/sitemap.md
+++ b/content/en/docs/sitemap.md
@@ -38,7 +38,7 @@ function mainLogic()
}
function populateDropdowns()
{
- // Keeping mainLogic() brief by functionizing the initialization of the
+ // Keeping mainLogic() brief by functionalizing the initialization of the
// drop-down filter boxes
for(i=0;i}}
-**Note:** A file that is used to configure access to a cluster is sometimes called
+A file that is used to configure access to a cluster is sometimes called
a *kubeconfig file*. This is a generic way of referring to configuration files.
It does not mean that there is a file named `kubeconfig`.
{{< /note >}}
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 4684387872..1c9e130aee 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
@@ -84,12 +84,11 @@ gcloud compute firewall-rules create my-rule --allow=tcp:
```
{{< note >}}
-**Note**: GCE firewalls are defined per-vm, rather than per-ip
-address. This means that when you open a firewall for a service's ports,
-anything that serves on that port on that VM's host IP address may potentially
-serve traffic. Note that this is not a problem for other Kubernetes services,
-as they listen on IP addresses that are different than the host node's external
-IP address.
+GCE firewalls are defined per-vm, rather than per-ip address. This means that
+when you open a firewall for a service's ports, anything that serves on that
+port on that VM's host IP address may potentially serve traffic. Note that this
+is not a problem for other Kubernetes services, as they listen on IP addresses
+that are different than the host node's external IP address.
Consider:
diff --git a/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md
index c1e7b4a2ba..a447e85d16 100644
--- a/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md
+++ b/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md
@@ -148,11 +148,13 @@ deployment.apps/frontend created
service/frontend created
```
-{{< note >}}**Note:** The nginx configuration is baked into the
-[container image](/examples/service/access/Dockerfile).
-A better way to do this would be to use a
-[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/), so
-you can change the configuration more easily.{{< /note >}}
+{{< note >}}
+The nginx configuration is baked into the [container
+image](/examples/service/access/Dockerfile). A better way to do this would
+be to use a
+[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/),
+so that you can change the configuration more easily.
+{{< /note >}}
### Interact with the frontend Service
diff --git a/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md b/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md
index b79dcb02ed..22c601d3d1 100644
--- a/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md
+++ b/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md
@@ -108,8 +108,9 @@ which should produce output like this:
The IP address is listed next to `LoadBalancer Ingress`.
{{< note >}}
-**Note**: If you are running your service on Minikube, you can find the assigned IP address and port with:
+If you are running your service on Minikube, you can find the assigned IP address and port with:
{{< /note >}}
+
```bash
minikube service example-service --url
```
@@ -181,7 +182,7 @@ compared to the `service.spec.externalTrafficPolicy` field. The values match as
* "Global" for annotation <-> "Cluster" for field
{{< note >}}
-**Note:** This feature is not currently implemented for all cloudproviders/environments.
+This feature is not currently implemented for all cloudproviders/environments.
{{< /note >}}
Known issues:
diff --git a/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md
index 0b6c1fb8e4..caf20d7f2e 100644
--- a/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md
+++ b/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md
@@ -63,7 +63,7 @@ The jsonpath is interpreted as follows:
- `.image`: get the image
{{< note >}}
-**Note:** When fetching a single Pod by name, e.g. `kubectl get pod nginx`,
+When fetching a single Pod by name, e.g. `kubectl get pod nginx`,
the `.items[*]` portion of the path should be omitted because a single
Pod is returned instead of a list of items.
{{< /note >}}
diff --git a/content/en/docs/tasks/access-application-cluster/load-balance-access-application-cluster.md b/content/en/docs/tasks/access-application-cluster/load-balance-access-application-cluster.md
index d45cf2493d..29058660b8 100644
--- a/content/en/docs/tasks/access-application-cluster/load-balance-access-application-cluster.md
+++ b/content/en/docs/tasks/access-application-cluster/load-balance-access-application-cluster.md
@@ -71,7 +71,7 @@ load-balanced access to an application running in a cluster.
command.
{{< note >}}
- **Note:** If you are using Minikube, you don't get an external IP address. The
+ If you are using Minikube, you don't get an external IP address. The
external IP address remains in the pending state.
{{< /note >}}
@@ -90,7 +90,7 @@ load-balanced access to an application running in a cluster.
Hello Kubernetes!
{{< note >}}
- **Note:** If you are using Minikube, enter these commands:
+ If you are using Minikube, enter these commands:
{{< /note >}}
kubectl cluster-info
diff --git a/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md b/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
index 8c3fda3cea..a303b9a878 100644
--- a/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
+++ b/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
@@ -137,7 +137,7 @@ is running the Redis server. With this connection in place you can use your
local workstation to debug the database that is running in the pod.
{{< warning >}}
-**Warning**: Due to known limitations, port forward today only works for TCP protocol.
+Due to known limitations, port forward today only works for TCP protocol.
The support to UDP protocol is being tracked in
[issue 47862](https://github.com/kubernetes/kubernetes/issues/47862).
{{< /warning >}}
diff --git a/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md b/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md
index 2781881e1b..223dfb67e4 100644
--- a/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md
+++ b/content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md
@@ -10,7 +10,7 @@ weight: 10
{{% capture overview %}}
-Configuring the [aggregation layer](/docs/concepts/api-extension/apiserver-aggregation/) allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs.
+Configuring the [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs.
{{% /capture %}}
@@ -19,7 +19,7 @@ Configuring the [aggregation layer](/docs/concepts/api-extension/apiserver-aggre
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{< note >}}
-**Note:** There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA.
+There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA.
{{< /note >}}
{{% /capture %}}
diff --git a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md
index 11d22745c7..ecf3ec0038 100644
--- a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md
+++ b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md
@@ -15,8 +15,8 @@ level of your CustomResourceDefinitions. It also describes how to upgrade an
object from one version to another.
{{< note >}}
-**Note**: All specified versions must use the same schema. The is no schema
-conversion between versions.
+All specified versions must use the same schema. There is no schema conversion
+between versions.
{{< /note >}}
{{% /capture %}}
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 887bc30552..93478fb7d8 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
@@ -686,8 +686,10 @@ crontabs/my-new-cron-object 3s
{{% /capture %}}
{{% capture whatsnext %}}
-* Learn how to [Migrate a ThirdPartyResource to CustomResourceDefinition](/docs/tasks/access-kubernetes-api/migrate-third-party-resource/).
+
* See [CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions-k8s-io).
+
* Serve [multiple versions](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/) of a
- CustomResourceDefinition
+ CustomResourceDefinition.
+
{{% /capture %}}
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 bd0f59d948..0e5a553571 100644
--- a/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md
+++ b/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md
@@ -105,7 +105,7 @@ For example, consider key pairs `k8sclient.key` and `k8sclient.cert` that are tr
Once etcd is configured correctly, only clients with valid certificates can access it. To give Kubernetes API server the access, configure it with the flags `--etcd-certfile=k8sclient.cert`,`--etcd-keyfile=k8sclient.key` and `--etcd-cafile=ca.cert`.
{{< note >}}
-**Note**: etcd authentication is not currently supported by Kubernetes. For more information, see the related issue [Support Basic Auth for Etcd v2](https://github.com/kubernetes/kubernetes/issues/23398).
+etcd authentication is not currently supported by Kubernetes. For more information, see the related issue [Support Basic Auth for Etcd v2](https://github.com/kubernetes/kubernetes/issues/23398).
{{< /note >}}
## Replacing a failed etcd member
@@ -212,7 +212,7 @@ The upgrade procedure described in this document assumes that either:
etcd cluster. During the time the etcd cluster is shut down, the Kubernetes API Server will be read only.
{{< warning >}}
-**Warning**: Deviations from the assumptions are untested by continuous
+Deviations from the assumptions are untested by continuous
integration, and deviations might create undesirable consequences. Additional information about operating an etcd cluster is available [from the etcd maintainers](https://github.com/coreos/etcd/tree/master/Documentation).
{{< /warning >}}
@@ -264,7 +264,7 @@ but the rollback tool has these limitations:
* Rollback doesn’t preserve resource versions of objects stored in etcd.
{{< warning >}}
-**Warning**: If the data is not kept in `application/json` format (see [Upgrade
+If the data is not kept in `application/json` format (see [Upgrade
Procedure](#upgrade-procedure)), you will lose the option to roll back to etcd
2.2.
{{< /warning >}}
@@ -276,7 +276,7 @@ resource versions. Since both the kubelet and kube-proxy use the watch API, a
rollback might require restarting all Kubernetes components on all nodes.
{{< note >}}
-**Note**: At the time of writing, both Kubelet and KubeProxy are using “resource
+At the time of writing, both Kubelet and KubeProxy are using “resource
version” only for watching (i.e. are not using resource versions for anything
else). And both are using reflector and/or informer frameworks for watching
(i.e. they don’t send watch requests themselves). Both those frameworks if they
@@ -390,7 +390,7 @@ STORAGE_MEDIA_TYPE=application/json
```
{{< note >}}
-**Note:** This procedure upgrades from 2.x to 3.x. Version `3.0.17` is not recommended for running in production (see [prerequisites](#prerequisites) for minimum recommended etcd versions).
+This procedure upgrades from 2.x to 3.x. Version `3.0.17` is not recommended for running in production (see [prerequisites](#prerequisites) for minimum recommended etcd versions).
{{< /note >}}
## Notes for etcd Version 2.2.1
diff --git a/content/en/docs/tasks/administer-cluster/coredns.md b/content/en/docs/tasks/administer-cluster/coredns.md
index e0d6c30e3b..db6d1881f6 100644
--- a/content/en/docs/tasks/administer-cluster/coredns.md
+++ b/content/en/docs/tasks/administer-cluster/coredns.md
@@ -52,7 +52,7 @@ your existing Corefile will be retained.
## Installing kube-dns instead of CoreDNS with kubeadm
{{< note >}}
-**Note:** In Kubernetes 1.11, CoreDNS has graduated to General Availability (GA)
+In Kubernetes 1.11, CoreDNS has graduated to General Availability (GA)
and is installed by default.
{{< /note >}}
@@ -63,6 +63,11 @@ value to `false`:
kubeadm init --feature-gates=CoreDNS=false
```
+## Tuning CoreDNS
+
+When resource utilisation is a concern, it may be useful to tune the configuration of CoreDNS. For more details, check out the
+[documentation on scaling CoreDNS]((https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md)).
+
{{% /capture %}}
{{% capture whatsnext %}}
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 c5b2a029d8..313e468636 100644
--- a/content/en/docs/tasks/administer-cluster/cpu-management-policies.md
+++ b/content/en/docs/tasks/administer-cluster/cpu-management-policies.md
@@ -75,16 +75,16 @@ The `static` policy allows containers in `Guaranteed` pods with integer CPU
using the [cpuset cgroup controller](https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt).
{{< note >}}
-**Note:** System services such as the container runtime and the kubelet itself can continue to run on these exclusive CPUs. The exclusivity only extends to other pods.
+System services such as the container runtime and the kubelet itself can continue to run on these exclusive CPUs. The exclusivity only extends to other pods.
{{< /note >}}
{{< note >}}
-**Note:** The alpha version of this policy does not guarantee static
+The alpha version of this policy does not guarantee static
exclusive allocations across Kubelet restarts.
{{< /note >}}
{{< note >}}
-**Note:** CPU Manager doesn't support offlining and onlining of
+CPU Manager doesn't support offlining and onlining of
CPUs at runtime. Also, if the set of online CPUs changes on the node,
the node must be drained and CPU manager manually reset by deleting the
state file `cpu_manager_state` in the kubelet root directory.
@@ -102,7 +102,7 @@ both part of a `Guaranteed` pod and have integer CPU `requests` are assigned
exclusive CPUs.
{{< note >}}
-**Note:** The kubelet requires a CPU reservation greater than zero be made
+The kubelet requires a CPU reservation greater than zero be made
using either `--kube-reserved` and/or `--system-reserved` when the static
policy is enabled. This is because zero CPU reservation would allow the shared
pool to become empty.
diff --git a/content/en/docs/tasks/administer-cluster/declare-network-policy.md b/content/en/docs/tasks/administer-cluster/declare-network-policy.md
index db27d97ce5..3ea02e0ed4 100644
--- a/content/en/docs/tasks/administer-cluster/declare-network-policy.md
+++ b/content/en/docs/tasks/administer-cluster/declare-network-policy.md
@@ -21,7 +21,9 @@ Make sure you've configured a network provider with network policy support. Ther
* [Romana](/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy/)
* [Weave Net](/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy/)
-**Note**: The above list is sorted alphabetically by product name, not by recommendation or preference. This example is valid for a Kubernetes cluster using any of these providers.
+{{< note >}}
+The above list is sorted alphabetically by product name, not by recommendation or preference. This example is valid for a Kubernetes cluster using any of these providers.
+{{< /note >}}
{{% /capture %}}
{{% capture steps %}}
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 6f0eaf9662..f533c80869 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
@@ -16,9 +16,9 @@ can develop their features independently from the core Kubernetes release cycles
{{< feature-state for_k8s_version="1.8" state="alpha" >}}
-Before going into how to build your own cloud controller manager, some background on how it works under the hood is helpful. The cloud controller manager is code from `kube-controller-manager` utilizing Go interfaces to allow implementations from any cloud to be plugged in. Most of the scaffolding and generic controller implementations will be in core, but it will always exec out to the cloud interfaces it is provided, so long as the [cloud provider interface](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go#L29-L50) is satisfied.
+Before going into how to build your own cloud controller manager, some background on how it works under the hood is helpful. The cloud controller manager is code from `kube-controller-manager` utilizing Go interfaces to allow implementations from any cloud to be plugged in. Most of the scaffolding and generic controller implementations will be in core, but it will always exec out to the cloud interfaces it is provided, so long as the [cloud provider interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go#L42-L62) is satisfied.
-To dive a little deeper into implementation details, all cloud controller managers will import packages from Kubernetes core, the only difference being each project will register their own cloud providers by calling [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/plugins.go#L42-L52) where a global variable of available cloud providers is updated.
+To dive a little deeper into implementation details, all cloud controller managers will import packages from Kubernetes core, the only difference being each project will register their own cloud providers by calling [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go#L56-L66) where a global variable of available cloud providers is updated.
{{% /capture %}}
diff --git a/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md
index 07fc8f10c4..944ef51498 100644
--- a/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md
+++ b/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md
@@ -103,10 +103,10 @@ The Corefile configuration includes the following [plugins](https://coredns.io/p
* [proxy](https://coredns.io/plugins/proxy/): Any queries that are not within the cluster domain of Kubernetes will be forwarded to predefined resolvers (/etc/resolv.conf).
* [cache](https://coredns.io/plugins/cache/): This enables a frontend cache.
* [loop](https://coredns.io/plugins/loop/): Detects simple forwarding loops and halts the CoreDNS process if a loop is found.
-* [reload](https://coredns.io/plugins/reload): Allows automatic reload of a changed Corefile.
-* [loadbalance](https://coredns.io/plugins/loadbalance): This is a round-robin DNS loadbalancer by randomizing the order of A, AAAA, and MX records in the answer.
+* [reload](https://coredns.io/plugins/reload): Allows automatic reload of a changed Corefile. After you edit the ConfigMap configuration, allow two minutes for your changes to take effect.
+* [loadbalance](https://coredns.io/plugins/loadbalance): This is a round-robin DNS loadbalancer that randomizes the order of A, AAAA, and MX records in the answer.
-We can modify the default behavior by modifying this configmap.
+You can modify the default CoreDNS behavior by modifying the ConfigMap.
### Configuration of Stub-domain and upstream nameserver using CoreDNS
@@ -132,7 +132,7 @@ proxy . 172.16.0.1
upstream 172.16.0.1
```
-So, the final ConfigMap along with the default `Corefile` configuration will look like:
+The final ConfigMap along with the default `Corefile` configuration looks like:
```yaml
apiVersion: v1
@@ -307,9 +307,9 @@ data:
## CoreDNS configuration equivalent to kube-dns
-CoreDNS supports all the functionalities and more that is provided by kube-dns.
+CoreDNS supports the features of kube-dns and more.
A ConfigMap created for kube-dns to support `StubDomains`and `upstreamNameservers` translates to the `proxy` plugin in CoreDNS.
-Similarly, the `Federation` plugin translates to the `federation` plugin in CoreDNS.
+Similarly, the `Federations` plugin in kube-dns translates to the `federation` plugin in CoreDNS.
### Example
@@ -356,7 +356,7 @@ The complete Corefile with the default plugins:
.:53 {
errors
health
- kubernetes cluster.local in-addr.arpa ip6.arpa {
+ kubernetes cluster.local in-addr.arpa ip6.arpa {
upstream 8.8.8.8 8.8.4.4
pods insecure
fallthrough in-addr.arpa ip6.arpa
@@ -380,12 +380,10 @@ The complete Corefile with the default plugins:
}
```
-In Kubernetes version 1.10 and later, kubeadm supports automatic translation of the CoreDNS ConfigMap from the kube-dns ConfigMap.
-
## Migration to CoreDNS
To migrate from kube-dns to CoreDNS, [a detailed blog](https://coredns.io/2018/05/21/migration-from-kube-dns-to-coredns/) is available to help users adapt CoreDNS in place of kube-dns.
-A cluster administrator can also migrate using [the deploy script](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh), which will also help you translate the kube-dns configmap to the equivalent CoreDNS one.
+A cluster administrator can also migrate using [the deploy script](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh).
## What's next
- [Debugging DNS Resolution](/docs/tasks/administer-cluster/dns-debugging-resolution/).
\ No newline at end of file
diff --git a/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md b/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md
index 1a9b7bf7e2..dd569aa774 100644
--- a/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md
+++ b/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md
@@ -252,7 +252,7 @@ Some Linux distributions (e.g. Ubuntu), use a local DNS resolver by default (sys
Systemd-resolved moves and replaces `/etc/resolv.conf` with a stub file that can cause a fatal forwarding
loop when resolving names in upstream servers. This can be fixed manually by using kubelet's `--resolv-conf` flag
to point to the correct `resolv.conf` (With `systemd-resolved`, this is `/run/systemd/resolve/resolv.conf`).
-kubeadm 1.11 automatically detects `systemd-resolved`, and adjusts the kubelet flags accordingly.
+kubeadm (>= 1.11) automatically detects `systemd-resolved`, and adjusts the kubelet flags accordingly.
Kubernetes installs do not configure the nodes' `resolv.conf` files to use the
cluster DNS by default, because that process is inherently distribution-specific.
diff --git a/content/en/docs/tasks/administer-cluster/encrypt-data.md b/content/en/docs/tasks/administer-cluster/encrypt-data.md
index b7b5eec380..405b1aa96f 100644
--- a/content/en/docs/tasks/administer-cluster/encrypt-data.md
+++ b/content/en/docs/tasks/administer-cluster/encrypt-data.md
@@ -66,9 +66,11 @@ resources from storage each provider that matches the stored data attempts to de
order. If no provider can read the stored data due to a mismatch in format or secret key, an error
is returned which prevents clients from accessing that resource.
-**IMPORTANT:** If any resource is not readable via the encryption config (because keys were changed),
+{{< caution >}}
+If any resource is not readable via the encryption config (because keys were changed),
the only recourse is to delete that key from the underlying etcd directly. Calls that attempt to
read that resource will fail until it is deleted or a valid decryption key is provided.
+{{< /caution >}}
### Providers:
@@ -113,7 +115,9 @@ To create a new secret perform the following steps:
3. Set the `--experimental-encryption-provider-config` flag on the `kube-apiserver` to point to the location of the config file.
4. Restart your API server.
-**IMPORTANT:** Your config file contains keys that can decrypt content in etcd, so you must properly restrict permissions on your masters so only the user who runs the kube-apiserver can read it.
+{{< caution >}}
+Your config file contains keys that can decrypt content in etcd, so you must properly restrict permissions on your masters so only the user who runs the kube-apiserver can read it.
+{{< /caution >}}
## Verifying that data is encrypted
@@ -142,7 +146,8 @@ program to retrieve the contents of your secret.
kubectl describe secret secret1 -n default
```
- should match `mykey: mydata`
+ should match `mykey: bXlkYXRh`, mydata is encoded, check [decoding a secret](/docs/concepts/configuration/secret#decoding-a-secret) to
+ completely decode the secret.
## Ensure all secrets are encrypted
diff --git a/content/en/docs/tasks/administer-cluster/extended-resource-node.md b/content/en/docs/tasks/administer-cluster/extended-resource-node.md
index 7eb65c3251..1cddabf8e8 100644
--- a/content/en/docs/tasks/administer-cluster/extended-resource-node.md
+++ b/content/en/docs/tasks/administer-cluster/extended-resource-node.md
@@ -74,10 +74,12 @@ curl --header "Content-Type: application/json-patch+json" \
http://localhost:8001/api/v1/nodes//status
```
-**Note**: In the preceding request, `~1` is the encoding for the character / in
+{{< note >}}
+In the preceding request, `~1` is the encoding for the character / in
the patch path. The operation path value in JSON-Patch is interpreted as a
JSON-Pointer. For more details, see
[IETF RFC 6901](https://tools.ietf.org/html/rfc6901), section 3.
+{{< /note >}}
The output shows that the Node has a capacity of 4 dongles:
@@ -110,7 +112,7 @@ number of dongles. See
## Discussion
Extended resources are similar to memory and CPU resources. For example,
-just as a Node has a certain amount of memory and CPU to be shared by all components
+just as a Node has a certain amount of memory and CPU to be shared by all components
running on the Node, it can have a certain number of dongles to be shared
by all components running on the Node. And just as application developers
can create Pods that request a certain amount of memory and CPU, they can
diff --git a/content/en/docs/tasks/administer-cluster/ip-masq-agent.md b/content/en/docs/tasks/administer-cluster/ip-masq-agent.md
index 25d114d139..cd7c90ac75 100644
--- a/content/en/docs/tasks/administer-cluster/ip-masq-agent.md
+++ b/content/en/docs/tasks/administer-cluster/ip-masq-agent.md
@@ -4,7 +4,7 @@ content_template: templates/task
---
{{% capture overview %}}
-This page shows how to configure and enable the ip-masq-agent.
+This page shows how to configure and enable the ip-masq-agent.
{{% /capture %}}
{{% capture prerequisites %}}
@@ -23,7 +23,7 @@ The ip-masq-agent configures iptables rules to hide a pod's IP address behind th
* **NAT (Network Address Translation)**
Is a method of remapping one IP address to another by modifying either the source and/or destination address information in the IP header. Typically performed by a device doing IP routing.
* **Masquerading**
- A form of NAT that is typically used to perform a many to one address translation, where multiple source IP addresses are masked behind a single address, which is typically the device doing the IP routing. In Kubernetes this is the Node's IP address.
+ A form of NAT that is typically used to perform a many to one address translation, where multiple source IP addresses are masked behind a single address, which is typically the device doing the IP routing. In Kubernetes this is the Node's IP address.
* **CIDR (Classless Inter-Domain Routing)**
Based on the variable-length subnet masking, allows specifying arbitrary-length prefixes. CIDR introduced a new method of representation for IP addresses, now commonly known as **CIDR notation**, in which an address or routing prefix is written with a suffix indicating the number of bits of the prefix, such as 192.168.2.0/24.
* **Link Local**
@@ -73,14 +73,16 @@ kubectl label nodes my-node beta.kubernetes.io/masq-agent-ds-ready=true
More information can be found in the ip-masq-agent documentation [here](https://github.com/kubernetes-incubator/ip-masq-agent)
In most cases, the default set of rules should be sufficient; however, if this is not the case for your cluster, you can create and apply a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to customize the IP ranges that are affected. For example, to allow only 10.0.0.0/8 to be considered by the ip-masq-agent, you can create the following [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) in a file called "config".
-**Note:** It is important that the file is called config since, by default, that will be used as the key for lookup by the ip-masq-agent:
+
+{{< note >}}
+It is important that the file is called config since, by default, that will be used as the key for lookup by the ip-masq-agent:
```
nonMasqueradeCIDRs:
- 10.0.0.0/8
resyncInterval: 60s
-
```
+{{< /note >}}
Run the following command to add the config map to your cluster:
@@ -88,13 +90,13 @@ Run the following command to add the config map to your cluster:
kubectl create configmap ip-masq-agent --from-file=config --namespace=kube-system
```
-This will update a file located at */etc/config/ip-masq-agent* which is periodically checked every *resyscInterval* and applied to the cluster node.
+This will update a file located at */etc/config/ip-masq-agent* which is periodically checked every *resyncInterval* and applied to the cluster node.
After the resync interval has expired, you should see the iptables rules reflect your changes:
```
iptables -t nat -L IP-MASQ-AGENT
Chain IP-MASQ-AGENT (1 references)
-target prot opt source destination
+target prot opt source destination
RETURN all -- anywhere 169.254.0.0/16 /* ip-masq-agent: cluster-local traffic should not be subject to MASQUERADE */ ADDRTYPE match dst-type !LOCAL
RETURN all -- anywhere 10.0.0.0/8 /* ip-masq-agent: cluster-local
MASQUERADE all -- anywhere anywhere /* ip-masq-agent: outbound traffic should be subject to MASQUERADE (this match must come after cluster-local CIDR matches) */ ADDRTYPE match dst-type !LOCAL
diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-12.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-12.md
index 6be3b687bf..934717cd91 100644
--- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-12.md
+++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-12.md
@@ -40,13 +40,13 @@ This page explains how to upgrade a Kubernetes cluster created with `kubeadm` fr
{{< tabs name="k8s_install" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
apt-get update
- apt-get upgrade -y kubelet kubeadm
+ apt-get upgrade -y kubeadm
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
yum upgrade -y kubeadm --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
-
+
1. Verify that the download works and has the expected version:
```shell
@@ -227,7 +227,7 @@ This page explains how to upgrade a Kubernetes cluster created with `kubeadm` fr
1. Upgrade the Kubernetes package version on each `$NODE` node by running the Linux package manager for your distribution:
- {{< tabs name="k8s_install" >}}
+ {{< tabs name="k8s_upgrade" >}}
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
apt-get update
apt-get upgrade -y kubelet kubeadm
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-1-12.md
similarity index 98%
rename from content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha.md
rename to content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha-1-12.md
index 9ca2fd503c..be50937b46 100644
--- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha.md
+++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha-1-12.md
@@ -24,8 +24,7 @@ Before proceeding:
- 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
-run as root.
+All commands on any control plane or etcd node should be run as root.
{{< /note >}}
{{% /capture %}}
@@ -177,6 +176,8 @@ Get a copy of the kubeadm config used to create this cluster. The config should
kubectl get configmap -n kube-system kubeadm-config -o jsonpath={.data.MasterConfiguration} > kubeadm-config.yaml
```
+Open the file in an editor and set `api.advertiseAddress` to the local node's IP address.
+
Now run the upgrade on each control plane node one at a time.
```
diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md
index d840b61371..249265300f 100644
--- a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md
+++ b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md
@@ -82,7 +82,7 @@ CPU request and limit to the Container.
* Verify that the Container specifies a CPU limit that is less than or equal to 800 millicpu.
{{< note >}}
-**Note:** When creating a `LimitRange` object, you can specify limits on huge-pages
+When creating a `LimitRange` object, you can specify limits on huge-pages
or GPUs as well. However, when both `default` and `defaultRequest` are specified
on these resources, the two values must be the same.
{{< /note >}}
diff --git a/content/en/docs/tasks/administer-cluster/namespaces.md b/content/en/docs/tasks/administer-cluster/namespaces.md
index 0e24a21dc9..ce1ebbce3d 100644
--- a/content/en/docs/tasks/administer-cluster/namespaces.md
+++ b/content/en/docs/tasks/administer-cluster/namespaces.md
@@ -106,7 +106,9 @@ More information on `finalizers` can be found in the namespace [design doc](http
$ kubectl delete namespaces
```
-**WARNING, this deletes _everything_ under the namespace!**
+{{< warning >}}
+This deletes _everything_ under the namespace!
+{{< /warning >}}
This delete is asynchronous, so for a time you will see the namespace in the `Terminating` state.
diff --git a/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md b/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
index 87bfffe583..ed3fd0f715 100644
--- a/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
+++ b/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
@@ -1,6 +1,7 @@
---
reviewers:
- danwent
+- aanm
title: Use Cilium for NetworkPolicy
content_template: templates/task
weight: 20
@@ -9,7 +10,7 @@ weight: 20
{{% capture overview %}}
This page shows how to use Cilium for NetworkPolicy.
-For background on Cilium, read the [Introduction to Cilium](https://cilium.readthedocs.io/en/latest/intro).
+For background on Cilium, read the [Introduction to Cilium](https://cilium.readthedocs.io/en/stable/intro).
{{% /capture %}}
{{% capture prerequisites %}}
@@ -22,21 +23,28 @@ For background on Cilium, read the [Introduction to Cilium](https://cilium.readt
## Deploying Cilium on Minikube for Basic Testing
To get familiar with Cilium easily you can follow the
-[Cilium Kubernetes Getting Started Guide](https://docs.cilium.io/en/latest/gettingstarted/minikube/)
+[Cilium Kubernetes Getting Started Guide](https://cilium.readthedocs.io/en/stable/gettingstarted/minikube/)
to perform a basic DaemonSet installation of Cilium in minikube.
-Installation in a minikube setup uses a simple ''all-in-one'' YAML
-file that includes DaemonSet configurations for Cilium, to connect
-to the minikube's etcd instance as well as appropriate RBAC settings:
+As Cilium requires a standalone etcd instance, for minikube you can deploy it
+by running:
```shell
-$ kubectl create -f https://raw.githubusercontent.com/cilium/cilium/master/examples/kubernetes/cilium.yaml
-configmap "cilium-config" created
-secret "cilium-etcd-secrets" created
-serviceaccount "cilium" created
-clusterrolebinding "cilium" created
-daemonset "cilium" created
-clusterrole "cilium" created
+kubectl create -n kube-system -f https://raw.githubusercontent.com/cilium/cilium/v1.3/examples/kubernetes/addons/etcd/standalone-etcd.yaml
+```
+
+After etcd is up and running you can deploy Cilium Kubernetes descriptor which
+is a simple ''all-in-one'' YAML file that includes DaemonSet configurations for
+Cilium, to connect to the etcd instance previously deployed as well as
+appropriate RBAC settings:
+
+```shell
+$ kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.3/examples/kubernetes/1.12/cilium.yaml
+configmap/cilium-config created
+daemonset.apps/cilium created
+clusterrolebinding.rbac.authorization.k8s.io/cilium created
+clusterrole.rbac.authorization.k8s.io/cilium created
+serviceaccount/cilium created
```
The remainder of the Getting Started Guide explains how to enforce both L3/L4
@@ -65,8 +73,8 @@ kubectl get pods --namespace=kube-system
You'll see a list of Pods similar to this:
```console
-NAME DESIRED CURRENT READY NODE-SELECTOR AGE
-cilium 1 1 1 2m
+NAME READY STATUS RESTARTS AGE
+cilium-6rxbd 1/1 Running 0 1m
...
```
@@ -74,12 +82,10 @@ There are two main components to be aware of:
- One `cilium` Pod runs on each node in your cluster and enforces network policy
on the traffic to/from Pods on that node using Linux BPF.
-- For production deployments, Cilium should leverage the key-value store cluster
-(e.g., etcd) used by Kubernetes, which typically runs on the Kubernetes master nodes.
-The [Cilium Kubernetes Installation Guide](https://cilium.readthedocs.io/en/latest/kubernetes/install/)
-includes an example DaemonSet which can be customized to point to this key-value
-store cluster. The simple ''all-in-one'' DaemonSet for minikube requires no such
-configuration because it automatically connects to the minikube's etcd instance.
+- For production deployments, Cilium should leverage a key-value store
+(e.g., etcd). The [Cilium Kubernetes Installation Guide](https://cilium.readthedocs.io/en/latest/kubernetes/install/)
+will provide the necessary steps on how to install this required key-value
+store as well how to configure it in Cilium.
{{% /capture %}}
diff --git a/content/en/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md b/content/en/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
index d97ad6ebab..0a363a22c5 100644
--- a/content/en/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
+++ b/content/en/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
@@ -14,7 +14,7 @@ This page shows how to use Romana for NetworkPolicy.
{{% capture prerequisites %}}
-Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/).
+Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/).
{{% /capture %}}
diff --git a/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md b/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md
index 5d2a1f615d..f984c4c5fd 100644
--- a/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md
+++ b/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md
@@ -14,7 +14,7 @@ allows you to change the configuration of each Kubelet in a live Kubernetes
cluster by deploying a ConfigMap and configuring each Node to use it.
{{< warning >}}
-**Warning:** All Kubelet configuration parameters can be changed dynamically,
+All Kubelet configuration parameters can be changed dynamically,
but this is unsafe for some parameters. Before deciding to change a parameter
dynamically, you need a strong understanding of how that change will affect your
cluster's behavior. Always carefully test configuration changes on a small set
@@ -69,7 +69,7 @@ This document only describes a single Node consuming each ConfigMap. Keep in
mind that it is also valid for multiple Nodes to consume the same ConfigMap.
{{< warning >}}
-**Warning:** While it is *possible* to change the configuration by
+While it is *possible* to change the configuration by
updating the ConfigMap in-place, this causes all Kubelets configured with
that ConfigMap to update simultaneously. It is much safer to treat ConfigMaps
as immutable by convention, aided by `kubectl`'s `--append-hash` option,
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 3abad0465b..e84a5a2813 100644
--- a/content/en/docs/tasks/administer-cluster/running-cloud-controller.md
+++ b/content/en/docs/tasks/administer-cluster/running-cloud-controller.md
@@ -13,7 +13,7 @@ content_template: templates/concept
Kubernetes v1.6 introduced a new binary called `cloud-controller-manager`. `cloud-controller-manager` is a daemon that embeds cloud-specific control loops. These cloud-specific control loops were originally in the `kube-controller-manager`. Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the `cloud-controller-manager` binary allows cloud vendors to evolve independently from the core Kubernetes code.
-The `cloud-controller-manager` can be linked to any cloud provider that satisfies [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go). For backwards compatibility, the [cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager) provided in the core Kubernetes project uses the same cloud libraries as `kube-controller-manager`. Cloud providers already supported in Kubernetes core are expected to use the in-tree cloud-controller-manager to transition out of Kubernetes core. In future Kubernetes releases, all cloud controller managers will be developed outside of the core Kubernetes project managed by sig leads or cloud vendors.
+The `cloud-controller-manager` can be linked to any cloud provider that satisfies [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go). For backwards compatibility, the [cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager) provided in the core Kubernetes project uses the same cloud libraries as `kube-controller-manager`. Cloud providers already supported in Kubernetes core are expected to use the in-tree cloud-controller-manager to transition out of Kubernetes core. In future Kubernetes releases, all cloud controller managers will be developed outside of the core Kubernetes project managed by sig leads or cloud vendors.
{{% /capture %}}
diff --git a/content/en/docs/tasks/administer-cluster/safely-drain-node.md b/content/en/docs/tasks/administer-cluster/safely-drain-node.md
index cea4c00af0..2cb77e3149 100644
--- a/content/en/docs/tasks/administer-cluster/safely-drain-node.md
+++ b/content/en/docs/tasks/administer-cluster/safely-drain-node.md
@@ -37,10 +37,12 @@ hardware maintenance, etc.). Safe evictions allow the pod's containers
to [gracefully terminate](/docs/concepts/workloads/pods/pod/#termination-of-pods)
and will respect the `PodDisruptionBudgets` you have specified.
-**Note:** By default `kubectl drain` will ignore certain system pods on the node
+{{< note >}}
+By default `kubectl drain` will ignore certain system pods on the node
that cannot be killed; see
the [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain)
documentation for more details.
+{{< /note >}}
When `kubectl drain` returns successfully, that indicates that all of
the pods (except the ones excluded as described in the previous paragraph)
diff --git a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md
index 0512f8b09a..36de25de82 100644
--- a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md
+++ b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md
@@ -165,10 +165,12 @@ credentials from the API servers to their etcd server, such as mutual auth via T
and it is often recommended to isolate the etcd servers behind a firewall that only the API servers
may access.
-**CAUTION:** Allowing other components within the cluster to access the master etcd instance with
+{{< caution >}}
+Allowing other components within the cluster to access the master etcd instance with
read or write access to the full keyspace is equivalent to granting cluster-admin access. Using
separate etcd instances for non-master components or using etcd ACLs to restrict read and write
access to a subset of the keyspace is strongly recommended.
+{{< /caution >}}
### Enable audit logging
diff --git a/content/en/docs/tasks/administer-cluster/static-pod.md b/content/en/docs/tasks/administer-cluster/static-pod.md
index 87dad377cd..1499c6b14a 100644
--- a/content/en/docs/tasks/administer-cluster/static-pod.md
+++ b/content/en/docs/tasks/administer-cluster/static-pod.md
@@ -100,11 +100,10 @@ Labels from the static pod are propagated into the mirror-pod and can be used as
Notice we cannot delete the pod with the API server (e.g. via [`kubectl`](/docs/user-guide/kubectl/) command), kubelet simply won't remove it.
-{{}}
-**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
+{{< 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
[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/).
-{{}}
+{{< /note >}}
```shell
[joe@my-master ~] $ kubectl delete pod static-web-my-node1
diff --git a/content/en/docs/tasks/administer-cluster/sysctl-cluster.md b/content/en/docs/tasks/administer-cluster/sysctl-cluster.md
index 46dc23cdf1..3fadc04540 100644
--- a/content/en/docs/tasks/administer-cluster/sysctl-cluster.md
+++ b/content/en/docs/tasks/administer-cluster/sysctl-cluster.md
@@ -58,7 +58,7 @@ The following sysctls are supported in the _safe_ set:
- `net.ipv4.tcp_syncookies`.
{{< note >}}
-**Note**: The example `net.ipv4.tcp_syncookies` is not namespaced on Linux kernel version 4.4 or lower.
+The example `net.ipv4.tcp_syncookies` is not namespaced on Linux kernel version 4.4 or lower.
{{< /note >}}
This list will be extended in future Kubernetes versions when the kubelet
@@ -141,7 +141,7 @@ spec:
{{% capture discussion %}}
{{< warning >}}
-**Warning**: Due to their nature of being _unsafe_, the use of _unsafe_ sysctls
+Due to their nature of being _unsafe_, the use of _unsafe_ sysctls
is at-your-own-risk and can lead to severe problems like wrong behavior of
containers, resource shortage or complete breakage of a node.
{{< /warning >}}
@@ -184,7 +184,7 @@ Do not configure these two fields such that there is overlap, meaning that a
given sysctl is both allowed and forbidden.
{{< warning >}}
-**Warning**: If you whitelist unsafe sysctls via the `allowedUnsafeSysctls` field
+If you whitelist unsafe sysctls via the `allowedUnsafeSysctls` field
in a PodSecurityPolicy, any pod using such a sysctl will fail to start
if the sysctl is not whitelisted via the `--allowed-unsafe-sysctls` kubelet
flag as well on that node.
diff --git a/content/en/docs/tasks/administer-federation/configmap.md b/content/en/docs/tasks/administer-federation/configmap.md
index cae4847081..4123b4ab22 100644
--- a/content/en/docs/tasks/administer-federation/configmap.md
+++ b/content/en/docs/tasks/administer-federation/configmap.md
@@ -81,7 +81,7 @@ kubectl --context=federation-cluster delete configmap
```
{{< note >}}
-**Note:** Deleting a Federated ConfigMap does not delete the corresponding ConfigMaps from underlying clusters. You must delete the underlying ConfigMaps manually.
+Deleting a Federated ConfigMap does not delete the corresponding ConfigMaps from underlying clusters. You must delete the underlying ConfigMaps manually.
{{< /note >}}
{{% /capture %}}
diff --git a/content/en/docs/tasks/administer-federation/hpa.md b/content/en/docs/tasks/administer-federation/hpa.md
index 5ca0363e1c..496a7032a6 100644
--- a/content/en/docs/tasks/administer-federation/hpa.md
+++ b/content/en/docs/tasks/administer-federation/hpa.md
@@ -87,7 +87,7 @@ max replicas on the federated HPA object, and the sum of minimum replicas will b
than or equal to the minimum specified on the federated HPA object.
{{< note >}}
-**Note:** A particular cluster cannot have a minimum replica sum of 0.
+A particular cluster cannot have a minimum replica sum of 0.
{{< /note >}}
### Spreading HPA min and max replicas in underlying clusters
@@ -125,8 +125,9 @@ in the previous section.
You can delete a federated HPA as you would delete a Kubernetes
HPA; however, for a federated HPA, you must send the request to
the federation API server instead of to a specific Kubernetes cluster.
+
{{< note >}}
-**Note:** For the federated resource to be deleted from all underlying clusters, [cascading deletion](/docs/concepts/cluster-administration/federation/#cascading-deletion) should be used.
+For the federated resource to be deleted from all underlying clusters, [cascading deletion](/docs/concepts/cluster-administration/federation/#cascading-deletion) should be used.
{{< /note >}}
For example, you can do that using `kubectl` by running:
diff --git a/content/en/docs/tasks/administer-federation/job.md b/content/en/docs/tasks/administer-federation/job.md
index cf631f5154..d495d1e42e 100644
--- a/content/en/docs/tasks/administer-federation/job.md
+++ b/content/en/docs/tasks/administer-federation/job.md
@@ -99,7 +99,7 @@ kubectl --context=federation-cluster delete job myjob
```
{{< note >}}
-**Note:** Deleting a federated job will not delete the
+Deleting a federated job will not delete the
corresponding jobs from underlying clusters.
You must delete the underlying jobs manually.
{{< /note >}}
diff --git a/content/en/docs/tasks/administer-federation/namespaces.md b/content/en/docs/tasks/administer-federation/namespaces.md
index df60610814..bf8cd84c35 100644
--- a/content/en/docs/tasks/administer-federation/namespaces.md
+++ b/content/en/docs/tasks/administer-federation/namespaces.md
@@ -84,7 +84,7 @@ As in Kubernetes, deleting a federated Namespace will delete all resources in th
Namespace from the federation control plane.
{{< note >}}
-**Note:** At this point, deleting a federated Namespace will not delete the corresponding Namespace, or resources in those Namespaces, from underlying clusters. Users must delete them manually. We intend to fix this in the future.
+At this point, deleting a federated Namespace will not delete the corresponding Namespace, or resources in those Namespaces, from underlying clusters. Users must delete them manually. We intend to fix this in the future.
{{< /note >}}
{{% /capture %}}
diff --git a/content/en/docs/tasks/administer-federation/replicaset.md b/content/en/docs/tasks/administer-federation/replicaset.md
index 7741f8a85c..932abd7095 100644
--- a/content/en/docs/tasks/administer-federation/replicaset.md
+++ b/content/en/docs/tasks/administer-federation/replicaset.md
@@ -124,7 +124,7 @@ kubectl --context=federation-cluster delete rs myrs
```
{{< note >}}
-**Note:** At this point, deleting a federated ReplicaSet will not delete the corresponding ReplicaSets from underlying clusters. You must delete the underlying ReplicaSets manually. We intend to fix this in the future.
+At this point, deleting a federated ReplicaSet will not delete the corresponding ReplicaSets from underlying clusters. You must delete the underlying ReplicaSets manually. We intend to fix this in the future.
{{< /note >}}
{{% /capture %}}
diff --git a/content/en/docs/tasks/administer-federation/secret.md b/content/en/docs/tasks/administer-federation/secret.md
index dc5b0e3d6c..a553e0562e 100644
--- a/content/en/docs/tasks/administer-federation/secret.md
+++ b/content/en/docs/tasks/administer-federation/secret.md
@@ -87,7 +87,7 @@ kubectl --context=federation-cluster delete secret mysecret
```
{{< note >}}
-**Note:** At this point, deleting a federated secret will not delete the corresponding secrets from underlying clusters. You must delete the underlying secrets manually. We intend to fix this in the future.
+At this point, deleting a federated secret will not delete the corresponding secrets from underlying clusters. You must delete the underlying secrets manually. We intend to fix this in the future.
{{< /note >}}
{{% /capture %}}
diff --git a/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md
index 3fac646141..516e33d1ed 100644
--- a/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md
+++ b/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md
@@ -120,7 +120,7 @@ cpu-demo 974m
Recall that by setting `-cpu "2"`, you configured the Container to attempt to use 2 CPUs, but the Container is only being allowed to use about 1 CPU. The Container CPU use is being throttled, because the Container is attempting to use more CPU resources than its limit.
{{< note >}}
-**Note:** Another possible explanation for the CPU throttling is that the Node might not have
+Another possible explanation for the CPU throttling is that the Node might not have
enough CPU resources available. Recall that the prerequisites for this exercise require each of
your Nodes to have at least 1 CPU. If your Container runs on a Node that has only 1 CPU, the Container
cannot use more than 1 CPU regardless of the CPU limit specified for the Container.
diff --git a/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md b/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
index 85dc63d6ab..3c461a2ecb 100644
--- a/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
+++ b/content/en/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
@@ -77,7 +77,7 @@ unless the Pod's grace period expires. For more details, see
[Termination of Pods](/docs/user-guide/pods/#termination-of-pods).
{{< note >}}
-**Note**: Kubernetes only sends the preStop event when a Pod is *terminated*.
+Kubernetes only sends the preStop event when a Pod is *terminated*.
This means that the preStop hook is not invoked when the Pod is *completed*.
This limitation is tracked in [issue #55087](https://github.com/kubernetes/kubernetes/issues/55807).
{{< /note >}}
diff --git a/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
index f770eacfbc..cc3f7a3fde 100644
--- a/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
+++ b/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
@@ -189,7 +189,7 @@ annotation or the Pod’s specification, is applied to the first process run in
each Container.
{{< note >}}
-**Note**: When a Pod consumes a PersistentVolume, the GIDs associated with the
+When a Pod consumes a PersistentVolume, the GIDs associated with the
PersistentVolume are not present on the Pod resource itself.
{{< /note >}}
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 651b72e65d..a34de6eb45 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
@@ -388,7 +388,7 @@ metadata:
## Configure all key-value pairs in a ConfigMap as container environment variables
{{< note >}}
- **Note:** This functionality is available in Kubernetes v1.6 and later.
+ This functionality is available in Kubernetes v1.6 and later.
{{< /note >}}
1. Create a ConfigMap containing multiple key-value pairs.
@@ -516,7 +516,7 @@ special.type
```
{{< caution >}}
-**Caution:** If there are some files in the `/etc/config/` directory, they will be deleted.
+If there are some files in the `/etc/config/` directory, they will be deleted.
{{< /caution >}}
### Add ConfigMap data to a specific path in the Volume
@@ -563,7 +563,7 @@ basis. The [Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files
When a ConfigMap already being consumed in a volume is updated, projected keys are eventually updated as well. Kubelet is checking whether the mounted ConfigMap is fresh on every periodic sync. However, it is using its local ttl-based cache for getting the current value of the ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as kubelet sync period + ttl of ConfigMaps cache in kubelet.
{{< note >}}
-**Note:** A container using a ConfigMap as a
+A container using a ConfigMap as a
[subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive
ConfigMap updates.
{{< /note >}}
@@ -577,7 +577,7 @@ ConfigMap updates.
The ConfigMap API resource stores configuration data as key-value pairs. The data can be consumed in pods or provide the configurations for system components such as controllers. ConfigMap is similar to [Secrets](/docs/concepts/configuration/secret/), but provides a means of working with strings that don't contain sensitive information. Users and system components alike can store configuration data in ConfigMap.
{{< note >}}
-**Note:** ConfigMaps should reference properties files, not replace them. Think of the ConfigMap as representing something similar to the Linux `/etc` directory and its contents. For example, if you create a [Kubernetes Volume](/docs/concepts/storage/volumes/) from a ConfigMap, each data item in the ConfigMap is represented by an individual file in the volume.
+ConfigMaps should reference properties files, not replace them. Think of the ConfigMap as representing something similar to the Linux `/etc` directory and its contents. For example, if you create a [Kubernetes Volume](/docs/concepts/storage/volumes/) from a ConfigMap, each data item in the ConfigMap is represented by an individual file in the volume.
{{< /note >}}
The ConfigMap's `data` field contains the configuration data. As shown in the example below, this can be simple -- like individual properties defined using `--from-literal` -- or complex -- like configuration files or JSON blobs defined using `--from-file`.
@@ -618,7 +618,7 @@ data:
This includes pods created via the Kubelet's --manifest-url flag, --config flag, or the Kubelet REST API.
{{< note >}}
- **Note:** These are not commonly-used ways to create pods.
+ These are not commonly-used ways to create pods.
{{< /note >}}
{{% /capture %}}
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 62992829cd..1777b5e41a 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
@@ -15,7 +15,7 @@ A service account provides an identity for processes that run in a Pod.
[Cluster Admin Guide to Service Accounts](/docs/reference/access-authn-authz/service-accounts-admin/).*
{{< note >}}
-**Note:** This document describes how service accounts behave in a cluster set up
+This document describes how service accounts behave in a cluster set up
as recommended by the Kubernetes project. Your cluster administrator may have
customized the behavior in your cluster, in which case this documentation may
not apply.
@@ -175,7 +175,7 @@ token: ...
```
{{< note >}}
-**Note:** The content of `token` is elided here.
+The content of `token` is elided here.
{{< /note >}}
## Add ImagePullSecrets to a service account
@@ -254,7 +254,7 @@ TODO: Test and explain how to use additional non-K8s secrets with an existing se
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
{{< note >}}
-**Note:** This ServiceAccountTokenVolumeProjection is __beta__ in 1.12 and
+This ServiceAccountTokenVolumeProjection is __beta__ in 1.12 and
enabled by passing all of the following flags to the API server:
* `--service-account-issuer`
diff --git a/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md
index e998baa6a1..836d89c0c4 100644
--- a/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md
+++ b/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md
@@ -53,7 +53,7 @@ The output contains a section similar to this:
```
{{< note >}}
-**Note:** If you use a Docker credentials store, you won't see that `auth` entry but a `credsStore` entry with the name of the store as value.
+If you use a Docker credentials store, you won't see that `auth` entry but a `credsStore` entry with the name of the store as value.
{{< /note >}}
## Create a Secret in the cluster that holds your authorization token
diff --git a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md
index 9062515fa2..8b344a9c6b 100644
--- a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md
+++ b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md
@@ -84,7 +84,7 @@ spec:
```
{{< note >}}
-**Note:** If a Container specifies its own memory limit, but does not specify a memory request, Kubernetes
+If a Container specifies its own memory limit, but does not specify a memory request, Kubernetes
automatically assigns a memory request that matches the limit. Similarly, if a Container specifies its own
CPU limit, but does not specify a CPU request, Kubernetes automatically assigns a CPU request that matches
the limit.
diff --git a/content/en/docs/tasks/configure-pod-container/security-context.md b/content/en/docs/tasks/configure-pod-container/security-context.md
index a89e0dfa53..e7a3f6dd99 100644
--- a/content/en/docs/tasks/configure-pod-container/security-context.md
+++ b/content/en/docs/tasks/configure-pod-container/security-context.md
@@ -299,7 +299,7 @@ See [capability.h](https://github.com/torvalds/linux/blob/master/include/uapi/li
for definitions of the capability constants.
{{< note >}}
-**Note:** Linux capability constants have the form `CAP_XXX`. But when you list capabilities in your Container manifest, you must omit the `CAP_` portion of the constant. For example, to add `CAP_SYS_TIME`, include `SYS_TIME` in your list of capabilities.
+Linux capability constants have the form `CAP_XXX`. But when you list capabilities in your Container manifest, you must omit the `CAP_` portion of the constant. For example, to add `CAP_SYS_TIME`, include `SYS_TIME` in your list of capabilities.
{{< /note >}}
## Assign SELinux labels to a Container
@@ -318,7 +318,7 @@ securityContext:
```
{{< note >}}
-**Note:** To assign SELinux labels, the SELinux security module must be loaded on the host operating system.
+To assign SELinux labels, the SELinux security module must be loaded on the host operating system.
{{< /note >}}
## Discussion
@@ -339,7 +339,7 @@ need to set the `level` section. This sets the
label given to all Containers in the Pod as well as the Volumes.
{{< warning >}}
-**Warning:** After you specify an MCS label for a Pod, all Pods with the same label can access the Volume. If you need inter-Pod protection, you must assign a unique MCS label to each Pod.
+After you specify an MCS label for a Pod, all Pods with the same label can access the Volume. If you need inter-Pod protection, you must assign a unique MCS label to each Pod.
{{< /warning >}}
{{% /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 316854b476..87cf2ef2f0 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
@@ -33,13 +33,13 @@ Kompose is released via GitHub on a three-week cycle, you can see all current re
```sh
# Linux
-curl -L https://github.com/kubernetes/kompose/releases/download/v1.1.0/kompose-linux-amd64 -o kompose
+curl -L https://github.com/kubernetes/kompose/releases/download/v1.16.0/kompose-linux-amd64 -o kompose
# macOS
-curl -L https://github.com/kubernetes/kompose/releases/download/v1.1.0/kompose-darwin-amd64 -o kompose
+curl -L https://github.com/kubernetes/kompose/releases/download/v1.16.0/kompose-darwin-amd64 -o kompose
# Windows
-curl -L https://github.com/kubernetes/kompose/releases/download/v1.1.0/kompose-windows-amd64.exe -o kompose.exe
+curl -L https://github.com/kubernetes/kompose/releases/download/v1.16.0/kompose-windows-amd64.exe -o kompose.exe
chmod +x kompose
sudo mv ./kompose /usr/local/bin/kompose
@@ -296,7 +296,9 @@ INFO OpenShift file "foo-imagestream.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 .
+{{< 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 .
+{{< /note >}}
## `kompose up`
@@ -335,6 +337,7 @@ pod/frontend-2768218532-cs5t5 1/1 Running 0 4m
pod/redis-master-1432129712-63jn8 1/1 Running 0 4m
pod/redis-slave-2504961300-nve7b 1/1 Running 0 4m
```
+
**Note**:
- You must have a running Kubernetes cluster with a pre-configured kubectl context.
@@ -550,7 +553,9 @@ The currently supported options are:
| kompose.service.type | nodeport / clusterip / loadbalancer |
| kompose.service.expose| true / hostname |
-**Note**: `kompose.service.type` label should be defined with `ports` only, otherwise `kompose` will fail.
+{{< note >}}
+The `kompose.service.type` label should be defined with `ports` only, otherwise `kompose` will fail.
+{{< /note >}}
## Restart
@@ -563,7 +568,9 @@ If you want to create normal pods without controllers you can use `restart` cons
| `on-failure` | Pod | `OnFailure` |
| `no` | Pod | `Never` |
-**Note**: controller object could be `deployment` or `replicationcontroller`, etc.
+{{< note >}}
+The controller object could be `deployment` or `replicationcontroller`, etc.
+{{< /note >}}
For e.g. `pival` service will become pod down here. This container calculated value of `pi`.
diff --git a/content/en/docs/tasks/debug-application-cluster/audit.md b/content/en/docs/tasks/debug-application-cluster/audit.md
index 10f8161f26..8e0b43e66c 100644
--- a/content/en/docs/tasks/debug-application-cluster/audit.md
+++ b/content/en/docs/tasks/debug-application-cluster/audit.md
@@ -46,8 +46,8 @@ Each request can be recorded with an associated "stage". The known stages are:
- `Panic` - Events generated when a panic occurred.
{{< note >}}
-**Note** The audit logging feature increases the memory consumption of the API
-server because some context required for auditing is stored for each request.
+The audit logging feature increases the memory consumption of the API server
+because some context required for auditing is stored for each request.
Additionally, memory consumption depends on the audit logging configuration.
{{< /note >}}
@@ -102,7 +102,7 @@ In both cases, audit events structure is defined by the API in the
[`v1`][auditing-api].
{{< note >}}
-**Note:** In case of patches, request body is a JSON array with patch operations, not a JSON object
+In case of patches, request body is a JSON array with patch operations, not a JSON object
with an appropriate Kubernetes API object. For example, the following request body is a valid patch
request to `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`.
@@ -216,7 +216,7 @@ In this example, we will use fluentd to split audit events by different namespac
1. install [fluentd][fluentd_install_doc], fluent-plugin-forest and fluent-plugin-rewrite-tag-filter in the kube-apiserver node
{{< note >}}
-**Note:** Fluent-plugin-forest and fluent-plugin-rewrite-tag-filter are plugins for fluentd. You can get details about plugin installation from [fluentd plugin-management][fluentd_plugin_management_doc].
+Fluent-plugin-forest and fluent-plugin-rewrite-tag-filter are plugins for fluentd. You can get details about plugin installation from [fluentd plugin-management][fluentd_plugin_management_doc].
{{< /note >}}
1. create a config file for fluentd
@@ -329,24 +329,22 @@ different users into different files.
1. create a [kubeconfig file](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) for kube-apiserver webhook audit backend
- ```none
- $ cat < /etc/kubernetes/audit-webhook-kubeconfig
- apiVersion: v1
- clusters:
- - cluster:
- server: http://:8888
- name: logstash
- contexts:
- - context:
- cluster: logstash
- user: ""
- name: default-context
- current-context: default-context
- kind: Config
- preferences: {}
- users: []
- EOF
- ```
+ $ cat < /etc/kubernetes/audit-webhook-kubeconfig
+ apiVersion: v1
+ clusters:
+ - cluster:
+ server: http://:8888
+ name: logstash
+ contexts:
+ - context:
+ cluster: logstash
+ user: ""
+ name: default-context
+ current-context: default-context
+ kind: Config
+ preferences: {}
+ users: []
+ EOF
1. start kube-apiserver with the following options:
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 e44f98c90d..18033665e9 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
@@ -34,7 +34,7 @@ The API is defined in [k8s.io/metrics](https://github.com/kubernetes/metrics/blo
repository. You can find more information about the API there.
{{< note >}}
-**Note:** The API requires metrics server to be deployed in the cluster. Otherwise it will be not available.
+The API requires metrics server to be deployed in the cluster. Otherwise it will be not available.
{{< /note >}}
## Metrics Server
diff --git a/content/en/docs/tasks/debug-application-cluster/crictl.md b/content/en/docs/tasks/debug-application-cluster/crictl.md
index 7c8afeee5a..4f91efb8a4 100644
--- a/content/en/docs/tasks/debug-application-cluster/crictl.md
+++ b/content/en/docs/tasks/debug-application-cluster/crictl.md
@@ -67,7 +67,7 @@ debug: true
The following examples show some `crictl` commands and example output.
{{< warning >}}
-**Warning:** If you use `crictl` to create pod sandboxes or containers on a running
+If you use `crictl` to create pod sandboxes or containers on a running
Kubernetes cluster, the Kubelet will eventually delete them. `crictl` is not a
general purpose workflow tool, but a tool that is useful for debugging.
{{< /warning >}}
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 cedfa0384c..94adc0578c 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-application.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-application.md
@@ -84,7 +84,7 @@ $ kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${
```
{{< note >}}
-**Note:** `-c ${CONTAINER_NAME}` is optional. You can omit it for Pods that only contain a single container.
+`-c ${CONTAINER_NAME}` is optional. You can omit it for Pods that only contain a single container.
{{< /note >}}
As an example, to look at the logs from a running Cassandra pod, you might run
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
index 3bbf3eb670..806347eff0 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
@@ -112,8 +112,10 @@ Alternately, you can run commands inside that container with `exec`:
kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
```
-{{< note >}}**Note:** `-c ${CONTAINER_NAME}` is optional. You can omit it for pods that
-only contain a single container.{{< /note >}}
+{{< note >}}
+`-c ${CONTAINER_NAME}` is optional. You can omit it for pods that
+only contain a single container.
+{{< /note >}}
As an example, to look at the logs from a running Cassandra pod, you might run:
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 3e470a11e3..29a3cb047b 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-service.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-service.md
@@ -79,7 +79,7 @@ deployment.apps/hostnames created
`kubectl` commands will print the type and name of the resource created or mutated, which can then be used in subsequent commands.
{{< note >}}
-**Note:** This is the same as if you started the `Deployment` with the following YAML:
+This is the same as if you started the `Deployment` with the following YAML:
```yaml
apiVersion: apps/v1
@@ -126,8 +126,9 @@ have another `Pod` that consumes this `Service` by name you would get something
like:
```shell
-u@pod$ wget -qO- hostnames
-wget: bad address 'hostname'
+u@pod$ wget -O- hostnames
+Resolving hostnames (hostnames)... failed: Name or service not known.
+wget: unable to resolve host address 'hostnames'
```
So the first thing to check is whether that `Service` actually exists:
@@ -214,7 +215,10 @@ The "cluster.local" is your cluster domain, which COULD be different in your
own cluster.
You can also try this from a `Node` in the cluster:
-{{< note >}}**Note:** 10.0.0.10 is my DNS `Service`, yours might be different){{< /note >}}
+
+{{< note >}}
+10.0.0.10 is my DNS `Service`, yours might be different).
+{{< /note >}}
```shell
u@node$ nslookup hostnames.default.svc.cluster.local 10.0.0.10
@@ -383,8 +387,11 @@ as the `Service` selecting for `run=hostnames`, but the `Deployment` specifying
At this point, we know that your `Service` exists and has selected your `Pods`.
Let's check that the `Pods` are actually working - we can bypass the `Service`
-mechanism and go straight to the `Pods`.
-{{< note >}}**Note:** These commands use the `Pod` port (9376), rather than the `Service` port (80).{{< /note >}}
+mechanism and go straight to the `Pods`.
+
+{{< note >}}
+These commands use the `Pod` port (9376), rather than the `Service` port (80).
+{{< /note >}}
```shell
u@pod$ wget -qO- 10.244.0.5:9376
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 1c612bf526..9f81b3ee90 100644
--- a/content/en/docs/tasks/debug-application-cluster/events-stackdriver.md
+++ b/content/en/docs/tasks/debug-application-cluster/events-stackdriver.md
@@ -25,7 +25,7 @@ This article describes a solution that exports Kubernetes events to
Stackdriver Logging, where they can be processed and analyzed.
{{< note >}}
-**Note:** It is not guaranteed that all events happening in a cluster will be
+It is not guaranteed that all events happening in a cluster will be
exported to Stackdriver. One possible scenario when events will not be
exported is when event exporter is not running (e.g. during restart or
upgrade). In most cases it's fine to use events for purposes like setting up
diff --git a/content/en/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md b/content/en/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
index ebd03d84d2..93ae3c38dd 100644
--- a/content/en/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
+++ b/content/en/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
@@ -18,7 +18,7 @@ them using [Kibana](https://www.elastic.co/products/kibana), as an alternative t
Stackdriver Logging when running on GCE.
{{< note >}}
-**Note:** You cannot automatically deploy Elasticsearch and Kibana in the Kubernetes cluster hosted on Google Kubernetes Engine. You have to deploy them manually.
+You cannot automatically deploy Elasticsearch and Kibana in the Kubernetes cluster hosted on Google Kubernetes Engine. You have to deploy them manually.
{{< /note >}}
{{% /capture %}}
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 378d5c6b33..1a5bc4e8e6 100644
--- a/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md
+++ b/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md
@@ -12,7 +12,7 @@ Before reading this page, it's highly recommended to familiarize yourself
with the [overview of logging in Kubernetes](/docs/concepts/cluster-administration/logging).
{{< note >}}
-**Note:** By default, Stackdriver logging collects only your container's standard output and
+By default, Stackdriver logging collects only your container's standard output and
standard error streams. To collect any logs your application writes to a file (for example),
see the [sidecar approach](/docs/concepts/cluster-administration/logging#sidecar-container-with-a-logging-agent)
in the Kubernetes logging overview.
@@ -52,7 +52,7 @@ consider starting a cluster without a pre-configured logging solution and then d
Stackdriver Logging agents to the running cluster.
{{< warning >}}
-**Warning:** The Stackdriver logging daemon has known issues on platforms other
+The Stackdriver logging daemon has known issues on platforms other
than Google Kubernetes Engine. Proceed at your own risk.
{{< /warning >}}
@@ -88,9 +88,11 @@ than Google Kubernetes Engine. Proceed at your own risk.
kubectl label node $NODE_NAME beta.kubernetes.io/fluentd-ds-ready=true
```
- {{< note >}}**Note:** If a node fails and has to be recreated, you must re-apply the label to
+ {{< note >}}
+ If a node fails and has to be recreated, you must re-apply the label to
the recreated node. To make this easier, you can use Kubelet's command-line parameter
- for applying node labels in your node startup script.{{< /note >}}
+ for applying node labels in your node startup script.
+ {{< /note >}}
1. Deploy a `ConfigMap` with the logging agent configuration by running the following command:
@@ -263,8 +265,12 @@ 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.
-{{< 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 >}}
+
+{{< 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 +331,10 @@ 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.
-{{< note >}}**Note:** Order is important.{{< /note >}}
+
+{{< note >}}
+Order is important.
+{{< /note >}}
Updating `ConfigMap` in the apiserver is more complicated than updating `DaemonSet`. It's better
to consider `ConfigMap` to be immutable. Then, in order to update the configuration, you should
diff --git a/content/en/docs/tasks/example-task-template.md b/content/en/docs/tasks/example-task-template.md
index 285a832500..256a5638e1 100644
--- a/content/en/docs/tasks/example-task-template.md
+++ b/content/en/docs/tasks/example-task-template.md
@@ -8,7 +8,9 @@ toc_hide: true
{{% capture overview %}}
-**NOTE:** Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document.
+{{< note >}}
+Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document.
+{{< /note >}}
This page shows how to ...
diff --git a/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md b/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md
index bf30124a82..1ef6dcbe59 100644
--- a/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md
+++ b/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md
@@ -18,9 +18,10 @@ of plugins as a means of utilizing these building blocks to create more complex
{{% capture prerequisites %}}
-You need to have a working `kubectl` binary installed.
+You need to have a working `kubectl` binary installed.
+
{{< note >}}
-**Note:** Plugins were officially introduced as an alpha feature in the v1.8.0 release. They have been re-worked in the v1.12.0 release to support a wider range of use-cases. So, while some parts of the plugins feature were already available in previous versions, a `kubectl` version of 1.12.0 or later is recommended if you are following these docs.
+Plugins were officially introduced as an alpha feature in the v1.8.0 release. They have been re-worked in the v1.12.0 release to support a wider range of use-cases. So, while some parts of the plugins feature were already available in previous versions, a `kubectl` version of 1.12.0 or later is recommended if you are following these docs.
{{< /note >}}
Until a GA version is released, plugins should be considered unstable, and their underlying mechanism is prone to change.
@@ -34,7 +35,7 @@ Until a GA version is released, plugins should be considered unstable, and their
A plugin is nothing more than a standalone executable file, whose name begins with `kubectl-`. To install a plugin, simply move this executable file to anywhere on your PATH.
{{< note >}}
-**Note:** Kubernetes does not provide a package manager or anything similar to install or update plugins. It is your responsibility to ensure that plugin executables have a filename that begins with `kubectl-`, and that they are placed somewhere on your PATH.
+Kubernetes does not provide a package manager or anything similar to install or update plugins. It is your responsibility to ensure that plugin executables have a filename that begins with `kubectl-`, and that they are placed somewhere on your PATH.
{{< /note >}}
### Discovering plugins
@@ -126,9 +127,15 @@ For example, a plugin that wishes to be invoked whenever the command `kubectl fo
#### Flags and argument handling
+{{< note >}}
+Unlike previous versions of `kubectl`, the plugin mechanism will _not_ create any custom, plugin-specific values or environment variables to a plugin process.
+This means that environment variables such as `KUBECTL_PLUGINS_CURRENT_NAMESPACE` are no longer provided to a plugin. Plugins must parse all of the arguments passed to them by a user,
+and handle flag validation as part of their own implementation. For plugins written in Go, a set of utilities has been provided under [k8s.io/cli-runtime](https://github.com/kubernetes/cli-runtime) to assist with this.
+{{< /note >}}
+
Taking our `kubectl-foo-bar-baz` plugin from the above scenario, we further explore additional cases where users invoke our plugin while providing additional flags and arguments.
For example, in a situation where a user invokes the command `kubectl foo bar baz arg1 --flag=value arg2`, the plugin mechanism will first try to find the plugin with the longest possible name, which in this case
-would be `kubectk-foo-bar-baz-arg1`. Upon not finding that plugin, it then treats the last dash-separated value as an argument (`arg1` in this case), and attempts to find the next longest possible name, `kubectl-foo-bar-baz`.
+would be `kubectl-foo-bar-baz-arg1`. Upon not finding that plugin, it then treats the last dash-separated value as an argument (`arg1` in this case), and attempts to find the next longest possible name, `kubectl-foo-bar-baz`.
Upon finding a plugin with this name, it then invokes that plugin, passing all args and flags after its name to the plugin executable.
Example:
@@ -184,7 +191,7 @@ The command from the above example, can be invoked using either a dash (`-`) or
$ kubectl foo-bar
I am a plugin with a dash in my name
-# it can also be inovked using an underscore
+# it can also be invoked using an underscore
$ kubectl foo_bar
I am a plugin with a dash in my name
```
diff --git a/content/en/docs/tasks/federation/federation-service-discovery.md b/content/en/docs/tasks/federation/federation-service-discovery.md
index 6a8138193b..b80a6d8d22 100644
--- a/content/en/docs/tasks/federation/federation-service-discovery.md
+++ b/content/en/docs/tasks/federation/federation-service-discovery.md
@@ -135,7 +135,7 @@ Events:
```
{{< note >}}
-**Note:** The 'LoadBalancer Ingress' addresses of your Federated Service
+The 'LoadBalancer Ingress' addresses of your Federated Service
correspond with the 'LoadBalancer Ingress' addresses of all of the
underlying Kubernetes services (once these have been allocated - this
may take a few seconds). For inter-cluster and inter-cloud-provider
@@ -222,7 +222,7 @@ nginx.mynamespace.myfederation.svc.europe-west1-d.example.com. CNAME 180
```
{{< note >}}
-**Note:** If your Federation is configured to use AWS Route53, you can use one of the equivalent AWS tools, for example:
+If your Federation is configured to use AWS Route53, you can use one of the equivalent AWS tools, for example:
``` shell
$ aws route53 list-hosted-zones
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 e6db7c3c31..739d143931 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
@@ -44,7 +44,7 @@ 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
+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
@@ -59,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.
+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`
@@ -78,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).
+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`
@@ -179,7 +179,7 @@ modify a Google Kubernetes Engine cluster directly to add this scope, but you ca
new node pool for your cluster and delete the old one.
{{< note >}}
-**Note:** This will cause pods in the cluster to be rescheduled.
+This will cause pods in the cluster to be rescheduled.
{{< /note >}}
To add the new node pool, run:
@@ -200,8 +200,9 @@ 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.
+
{{< note >}}
-**Note:** In the beta release of Kubernetes 1.6, `kubefed init` does not automatically set the current context to the
+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:
```shell
@@ -466,7 +467,7 @@ A new context has now been added to your kubeconfig named `fellowship` (after th
{{< note >}}
-**Note:** The name that you provide to the `join` command is used as the joining cluster's identity in federation. This name should adhere to the rules described in the [identifiers doc](/docs/concepts/overview/working-with-objects/names/). If the context
+The name that you provide to the `join` command is used as the joining cluster's identity in federation. This name should adhere to the rules described in the [identifiers doc](/docs/concepts/overview/working-with-objects/names/). If the context
corresponding to your joining cluster conforms to these rules, you can use the same name in the join command. Otherwise, you must choose a different name for your cluster's identity.
{{< /note >}}
@@ -515,7 +516,7 @@ kubefed join noldor --host-cluster-context=rivendell --secret-name=11kingdom
```
{{< note >}}
-**Note:** If your cluster name does not conform to the DNS subdomain name specification, all you need to do is supply the secret name using the `--secret-name` flag. `kubefed join` automatically creates the secret for you.
+If your cluster name does not conform to the DNS subdomain name specification, all you need to do is supply the secret name using the `--secret-name` flag. `kubefed join` automatically creates the secret for you.
{{< /note >}}
### `kube-dns` configuration
@@ -555,7 +556,7 @@ kubectl delete ns federation-system --context=rivendell
```
{{< note >}}
-**Note:** `rivendell` is the host cluster name. Replace that name with the appropriate name in your configuration.
+`rivendell` is the host cluster name. Replace that name with the appropriate name in your configuration.
{{< /note >}}
{{% /capture %}}
diff --git a/content/en/docs/tasks/federation/set-up-coredns-provider-federation.md b/content/en/docs/tasks/federation/set-up-coredns-provider-federation.md
index acfb9bf58b..b2379f79b9 100644
--- a/content/en/docs/tasks/federation/set-up-coredns-provider-federation.md
+++ b/content/en/docs/tasks/federation/set-up-coredns-provider-federation.md
@@ -118,15 +118,19 @@ coredns-provider.conf has below format:
- `zones` is the federation domain for which CoreDNS is authoritative and is same as --dns-zone-name flag of `kubefed init`.
- `coredns-endpoints` is the endpoint to access CoreDNS server. This is an optional parameter introduced from v1.7 onwards.
-{{< note >}}**Note**: *plugins.etcd.zones in CoreDNS configuration and --dns-zone-name flag to kubefed init should match.*{{< /note >}}
+{{< note >}}
+`plugins.etcd.zones` in the CoreDNS configuration and the `--dns-zone-name` flag to `kubefed init` should match.
+{{< /note >}}
## Setup CoreDNS server in nameserver resolv.conf chain
-*Note: The following section applies only to versions prior to v1.7
+{{< note >}}
+The following section applies only to versions prior to v1.7
and will be automatically taken care of if the `coredns-endpoints`
parameter is configured in `coredns-provider.conf` as described in
-section above.*
+section above.
+{{< /note >}}
Once the federation control plane is deployed and federated clusters
are joined to the federation, you need to add the CoreDNS server to the
diff --git a/content/en/docs/tasks/inject-data-application/define-command-argument-container.md b/content/en/docs/tasks/inject-data-application/define-command-argument-container.md
index d920dacdfb..64fc918206 100644
--- a/content/en/docs/tasks/inject-data-application/define-command-argument-container.md
+++ b/content/en/docs/tasks/inject-data-application/define-command-argument-container.md
@@ -35,7 +35,7 @@ If you define args, but do not define a command, the default command is used
with your new arguments.
{{< note >}}
-**Note:** the `command` field corresponds to `entrypoint` in some container
+The `command` field corresponds to `entrypoint` in some container
runtimes. Refer to the [Notes](#notes) below.
{{< /note >}}
@@ -85,7 +85,7 @@ and
[Secrets](/docs/concepts/configuration/secret/).
{{< note >}}
-**Note:** The environment variable appears in parentheses, `"$(VAR)"`. This is
+The environment variable appears in parentheses, `"$(VAR)"`. This is
required for the variable to be expanded in the `command` or `args` field.
{{< /note >}}
diff --git a/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md
index 89263d8661..f43c4cdc22 100644
--- a/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md
+++ b/content/en/docs/tasks/inject-data-application/define-environment-variable-container.md
@@ -79,7 +79,7 @@ Pod:
1. To exit the shell, enter `exit`.
{{< note >}}
-**Note:** The environment variables set using the `env` or `envFrom` field
+The environment variables set using the `env` or `envFrom` field
will override any environment variables specified in the container image.
{{< /note >}}
diff --git a/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md
index 8e4f45d87c..7b17ba4368 100644
--- a/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md
+++ b/content/en/docs/tasks/inject-data-application/distribute-credentials-secure.md
@@ -42,12 +42,13 @@ username and password:
```shell
kubectl create -f https://k8s.io/docs/tasks/inject-data-application/secret.yaml
```
-{{< note >}}
-**Note:** If you want to skip the Base64 encoding step, you can create a Secret by using the `kubectl create secret` command:
-{{< /note >}}
- ```shell
- kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb'
- ```
+
+ {{< note >}}
+ If you want to skip the Base64 encoding step, you can create a Secret by using the `kubectl create secret` command:
+ ```shell
+ kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb'
+ ```
+ {{< /note >}}
1. View information about the Secret:
@@ -79,7 +80,7 @@ username and password:
{{< note >}}
-**Note:** If you want to skip the Base64 encoding step, you can create a Secret
+If you want to skip the Base64 encoding step, you can create a Secret
by using the `kubectl create secret` command:
{{< /note >}}
diff --git a/content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md b/content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
index b3a3cca0f7..643237887f 100644
--- a/content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
+++ b/content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
@@ -49,7 +49,7 @@ The second element specifies that the value of the Pod's `annotations`
field should be stored in a file named `annotations`.
{{< note >}}
-**Note:** The fields in this example are Pod fields. They are not
+The fields in this example are Pod fields. They are not
fields of the Container in the Pod.
{{< /note >}}
@@ -118,7 +118,7 @@ View the files in the `/etc/podinfo` directory:
In the output, you can see that the `labels` and `annotations` files
are in a temporary subdirectory: in this example,
`..2982_06_02_21_47_53.299460680`. In the `/etc/podinfo` directory, `..data` is
-a symbolic link to the temporary subdirectory. Also in the `/etc/podinfo` directory,
+a symbolic link to the temporary subdirectory. Also in the `/etc/podinfo` directory,
`labels` and `annotations` are symbolic links.
```
@@ -139,7 +139,7 @@ atomically using
[rename(2)](http://man7.org/linux/man-pages/man2/rename.2.html).
{{< note >}}
-**Note:** A container using Downward API as a
+A container using Downward API as a
[subPath](/docs/concepts/storage/volumes/#using-subpath) volume mount will not
receive Downward API updates.
{{< /note >}}
@@ -221,7 +221,7 @@ In addition, the following information is available through
* `metadata.annotations` - all of the pod’s annotations, formatted as `annotation-key="escaped-annotation-value"` with one annotation per line
{{< note >}}
-**Note:** If CPU and memory limits are not specified for a Container, the
+If CPU and memory limits are not specified for a Container, the
Downward API defaults to the node allocatable value for CPU and memory.
{{< /note >}}
diff --git a/content/en/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md b/content/en/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md
index cb82dd3758..2c543b1d6f 100644
--- a/content/en/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md
+++ b/content/en/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md
@@ -48,7 +48,7 @@ variable gets its value from the Pod's `spec.nodeName` field. Similarly, the
other environment variables get their names from Pod fields.
{{< note >}}
-**Note:** The fields in this example are Pod fields. They are not fields of the
+The fields in this example are Pod fields. They are not fields of the
Container in the Pod.
{{< /note >}}
diff --git a/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md b/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md
index 4834e7ee91..364908f01a 100644
--- a/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md
+++ b/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md
@@ -14,9 +14,11 @@ These automated jobs run like [Cron](https://en.wikipedia.org/wiki/Cron) tasks o
Cron jobs are useful for creating periodic and recurring tasks, like running backups or sending emails.
Cron jobs can also schedule individual tasks for a specific time, such as if you want to schedule a job for a low activity period.
-**Note:** CronJob resource in `batch/v2alpha1` API group has been deprecated starting from cluster version 1.8.
+{{< note >}}
+CronJob resource in `batch/v2alpha1` API group has been deprecated starting from cluster version 1.8.
You should switch to using `batch/v1beta1`, instead, which is enabled by default in the API server.
Examples in this document use `batch/v1beta1` in all examples.
+{{< /note >}}
Cron jobs have limitations and idiosyncrasies.
For example, in certain circumstances, a single cron job can create multiple jobs.
@@ -123,7 +125,9 @@ and [using kubectl to manage resources](/docs/user-guide/working-with-resources)
A cron job config also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status).
-**Note:** All modifications to a cron job, especially its `.spec`, are applied only to the following runs.
+{{< note >}}
+All modifications to a cron job, especially its `.spec`, are applied only to the following runs.
+{{< /note >}}
### Schedule
@@ -139,8 +143,9 @@ The format also includes extended `vixie cron` step values. As explained in the
> ``0,2,4,6,8,10,12,14,16,18,20,22''). Steps are also permitted after an
> asterisk, so if you want to say ``every two hours'', just use ``*/2''.
-
-**Note:** The question mark (`?`) in the schedule has the same meaning as an asterisk `*`, that is, it stands for any of available value for a given field.
+{{< note >}}
+A question mark (`?`) in the schedule has the same meaning as an asterisk `*`, that is, it stands for any of available value for a given field.
+{{< /note >}}
### Job Template
@@ -187,7 +192,7 @@ This setting does not apply to already started executions.
Defaults to false.
{{< caution >}}
-**Caution:** Executions that are suspended during their scheduled time count as missed jobs.
+Executions that are suspended during their scheduled time count as missed jobs.
When `.spec.suspend` changes from `true` to `false` on an existing cron job without a [starting deadline](#starting-deadline), the missed jobs are scheduled immediately.
{{< /caution >}}
diff --git a/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md b/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md
index fbd57b98c0..b522ecc8ed 100644
--- a/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md
+++ b/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md
@@ -140,7 +140,7 @@ previous revision through other commands, such as `kubectl edit` or `kubectl
apply`.
{{< note >}}
-**Note:** DaemonSet revisions only roll forward. That is to say, after a
+DaemonSet revisions only roll forward. That is to say, after a
rollback completes, the revision number (`.revision` field) of the
`ControllerRevision` being rolled back to will advance. For example, if you
have revision 1 and 2 in the system, and roll back from revision 2 to revision
diff --git a/content/en/docs/tasks/manage-daemon/update-daemon-set.md b/content/en/docs/tasks/manage-daemon/update-daemon-set.md
index d2cd15cdcd..4b380f772d 100644
--- a/content/en/docs/tasks/manage-daemon/update-daemon-set.md
+++ b/content/en/docs/tasks/manage-daemon/update-daemon-set.md
@@ -159,9 +159,10 @@ kubectl get pods -l = -o wide
```
Once you've found those nodes, delete some non-DaemonSet pods from the node to
-make room for new DaemonSet pods.
+make room for new DaemonSet pods.
+
{{< note >}}
-**Note:** This will cause service disruption when deleted pods are not controlled by any controllers or pods are not
+This will cause service disruption when deleted pods are not controlled by any controllers or pods are not
replicated. This does not respect [PodDisruptionBudget](/docs/tasks/configure-pod-container/configure-pod-disruption-budget/)
either.
{{< /note >}}
diff --git a/content/en/docs/tasks/manage-gpus/scheduling-gpus.md b/content/en/docs/tasks/manage-gpus/scheduling-gpus.md
index 51f94a255d..91ae88bb8e 100644
--- a/content/en/docs/tasks/manage-gpus/scheduling-gpus.md
+++ b/content/en/docs/tasks/manage-gpus/scheduling-gpus.md
@@ -116,29 +116,32 @@ kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v1.
Report issues with this device plugin to [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin).
-#### NVIDIA GPU device plugin used by GKE/GCE
+#### NVIDIA GPU device plugin used by GCE
-The [NVIDIA GPU device plugin used by GKE/GCE](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu)
+The [NVIDIA GPU device plugin used by GCE](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu)
doesn't require using nvidia-docker and should work with any container runtime
that is compatible with the Kubernetes Container Runtime Interface (CRI). It's tested
on [Container-Optimized OS](https://cloud.google.com/container-optimized-os/)
and has experimental code for Ubuntu from 1.9 onwards.
-On your 1.9 cluster, you can use the following commands to install the NVIDIA drivers and device plugin:
+On your 1.12 cluster, you can use the following commands to install the NVIDIA drivers and device plugin:
```
# Install NVIDIA drivers on Container-Optimized OS:
-kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/k8s-1.9/daemonset.yaml
+kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/stable/daemonset.yaml
# Install NVIDIA drivers on Ubuntu (experimental):
-kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/k8s-1.9/nvidia-driver-installer/ubuntu/daemonset.yaml
+kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/stable/nvidia-driver-installer/ubuntu/daemonset.yaml
# Install the device plugin:
-kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.9/cluster/addons/device-plugins/nvidia-gpu/daemonset.yaml
+kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.12/cluster/addons/device-plugins/nvidia-gpu/daemonset.yaml
```
Report issues with this device plugin and installation method to [GoogleCloudPlatform/container-engine-accelerators](https://github.com/GoogleCloudPlatform/container-engine-accelerators).
+Instructions for using NVIDIA GPUs on GKE are
+[here](https://cloud.google.com/kubernetes-engine/docs/how-to/gpus)
+
## Clusters containing different types of NVIDIA GPUs
If different nodes in your cluster have different types of NVIDIA GPUs, then you
diff --git a/content/en/docs/tasks/manage-hugepages/scheduling-hugepages.md b/content/en/docs/tasks/manage-hugepages/scheduling-hugepages.md
index e8bb5ef319..82b3c34d27 100644
--- a/content/en/docs/tasks/manage-hugepages/scheduling-hugepages.md
+++ b/content/en/docs/tasks/manage-hugepages/scheduling-hugepages.md
@@ -33,7 +33,9 @@ Huge pages can be consumed via container level resource requirements using the
resource name `hugepages-`, where size is the most compact binary notation
using integer values supported on a particular node. For example, if a node
supports 2048KiB page sizes, it will expose a schedulable resource
-`hugepages-2Mi`. Unlike CPU or memory, huge pages do not support overcommit.
+`hugepages-2Mi`. Unlike CPU or memory, huge pages do not support overcommit. Note
+that when requesting hugepage resources, either memory or CPU resources must
+be requested as well.
```yaml
apiVersion: v1
@@ -53,6 +55,9 @@ spec:
resources:
limits:
hugepages-2Mi: 100Mi
+ memory: 100Mi
+ requests:
+ memory: 100Mi
volumes:
- name: hugepage
emptyDir:
diff --git a/content/en/docs/tasks/run-application/configure-pdb.md b/content/en/docs/tasks/run-application/configure-pdb.md
index 7c291da37d..36a06dedda 100644
--- a/content/en/docs/tasks/run-application/configure-pdb.md
+++ b/content/en/docs/tasks/run-application/configure-pdb.md
@@ -91,7 +91,7 @@ of the number of pods from that set that can be unavailable after the eviction.
It can be either an absolute number or a percentage.
{{< note >}}
-**Note:** For versions 1.8 and earlier: When creating a `PodDisruptionBudget`
+For versions 1.8 and earlier: When creating a `PodDisruptionBudget`
object using the `kubectl` command line tool, the `minAvailable` field has a
default value of 1 if neither `minAvailable` nor `maxUnavailable` is specified.
{{< /note >}}
@@ -117,12 +117,14 @@ of the desired replicas are unhealthy.
In typical usage, a single budget would be used for a collection of pods managed by
a controller—for example, the pods in a single ReplicaSet or StatefulSet.
-**Note:** A disruption budget does not truly guarantee that the specified
+{{< note >}}
+A disruption budget does not truly guarantee that the specified
number/percentage of pods will always be up. For example, a node that hosts a
pod from the collection may fail when the collection is at the minimum size
specified in the budget, thus bringing the number of available pods from the
collection below the specified size. The budget can only protect against
voluntary evictions, not all causes of unavailability.
+{{< /note >}}
A `maxUnavailable` of 0% (or 0) or a `minAvailable` of 100% (or equal to the
number of replicas) may block node drains entirely. This is permitted as per the
diff --git a/content/en/docs/tasks/run-application/delete-stateful-set.md b/content/en/docs/tasks/run-application/delete-stateful-set.md
index 564d18114e..7c2db63971 100644
--- a/content/en/docs/tasks/run-application/delete-stateful-set.md
+++ b/content/en/docs/tasks/run-application/delete-stateful-set.md
@@ -59,7 +59,9 @@ kubectl delete pods -l app=myapp
Deleting the Pods in a StatefulSet will not delete the associated volumes. This is to ensure that you have the chance to copy data off the volume before deleting it. Deleting the PVC after the pods have left the [terminating state](/docs/concepts/workloads/pods/pod/#termination-of-pods) might trigger deletion of the backing Persistent Volumes depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion.
-**Note: Use caution when deleting a PVC, as it may lead to data loss.**
+{{< note >}}
+Use caution when deleting a PVC, as it may lead to data loss.
+{{< /note >}}
### Complete deletion of a StatefulSet
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 45bac9d25b..bb1fefc413 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
@@ -25,9 +25,8 @@ This document walks you through an example of enabling Horizontal Pod Autoscaler
This example requires a running Kubernetes cluster and kubectl, version 1.2 or later.
[metrics-server](https://github.com/kubernetes-incubator/metrics-server/) monitoring needs to be deployed in the cluster
-to provide metrics via the resource metrics API, as Horizontal Pod Autoscaler uses this API to collect metrics
-(if you followed [getting started on GCE guide](/docs/setup/turnkey/gce/),
-metrics-server monitoring will be turned-on by default).
+to provide metrics via the resource metrics API, as Horizontal Pod Autoscaler uses this API to collect metrics. The instructions for deploying this are on the GitHub repository of [metrics-server](https://github.com/kubernetes-incubator/metrics-server/), if you followed [getting started on GCE guide](/docs/setup/turnkey/gce/),
+metrics-server monitoring will be turned-on by default.
To specify multiple resource metrics for a Horizontal Pod Autoscaler, you must have a Kubernetes cluster
and kubectl at version 1.6 or later. Furthermore, in order to make use of custom metrics, your cluster
@@ -130,9 +129,11 @@ NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
php-apache 7 7 7 7 19m
```
-**Note** Sometimes it may take a few minutes to stabilize the number of replicas.
-Since the amount of load is not controlled in any way it may happen that the final number of replicas will
-differ from this example.
+{{< note >}}
+It may take a few minutes to stabilize the number of replicas. Since the amount
+of load is not controlled in any way it may happen that the final number of replicas
+will differ from this example.
+{{< /note >}}
## Stop load
@@ -156,7 +157,7 @@ php-apache 1 1 1 1 27m
Here CPU utilization dropped to 0, and so HPA autoscaled the number of replicas back down to 1.
{{< note >}}
-**Note** autoscaling the replicas may take a few minutes.
+Autoscaling the replicas may take a few minutes.
{{< /note >}}
{{% /capture %}}
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 c4938cb260..d033d77d33 100644
--- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
+++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
@@ -159,7 +159,7 @@ replica counts is chosen. If any of those metrics cannot be converted
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
+Finally, just before HPA scales the target, the scale recommendation 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.
This means that scaledowns will occur gradually, smoothing out the impact of rapidly
@@ -222,11 +222,11 @@ upscale delay.
The default value is 5 minutes (`5m0s`).
{{< note >}}
-**Note**: When tuning these parameter values, a cluster operator should be aware of
-the possible consequences. If the delay (cooldown) value is set too long, there
-could be complaints that the Horizontal Pod Autoscaler is not responsive to workload
-changes. However, if the delay value is set too short, the scale of the replicas set
-may keep thrashing as usual.
+When tuning these parameter values, a cluster operator should be aware of the possible
+consequences. If the delay (cooldown) value is set too long, there could be complaints
+that the Horizontal Pod Autoscaler is not responsive to workload changes. However, if
+the delay value is set too short, the scale of the replicas set may keep thrashing as
+usual.
{{< /note >}}
## Support for multiple metrics
@@ -238,10 +238,12 @@ proposed scales will be used as the new scale.
## Support for custom metrics
-**Note**: Kubernetes 1.2 added alpha support for scaling based on application-specific metrics using special annotations.
+{{< note >}}
+Kubernetes 1.2 added alpha support for scaling based on application-specific metrics using special annotations.
Support for these annotations was removed in Kubernetes 1.6 in favor of the new autoscaling API. While the old method for collecting
custom metrics is still available, these metrics will not be available for use by the Horizontal Pod Autoscaler, and the former
annotations for specifying which custom metrics to scale on are no longer honored by the Horizontal Pod Autoscaler controller.
+{{< /note >}}
Kubernetes 1.6 adds support for making use of custom metrics in the Horizontal Pod Autoscaler.
You can add custom metrics for the Horizontal Pod Autoscaler to use in the `autoscaling/v2beta2` API.
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 63db0a2ac0..e0ace5c4c9 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
@@ -9,7 +9,7 @@ weight: 80
{{% capture overview %}}
{{< note >}}
-**Note**: The preferred way to create a replicated application is to use a
+The preferred way to create a replicated application is to use a
[Deployment](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deployment-v1-apps),
which in turn uses a
[ReplicaSet](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replicaset-v1-apps).
diff --git a/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md b/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md
index 5b5c7e562d..728d7a8950 100644
--- a/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md
+++ b/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md
@@ -68,7 +68,7 @@ AUTHORIZATION_MODE=Node,RBAC hack/local-up-cluster.sh -O
By default, `helm init` installs the Tiller Pod into the `kube-system` namespace, with Tiller configured to use the `default` service account.
{{< note >}}
-**NOTE:** If you used the `--tiller-namespace` or `--service-account` flags when running `helm init`, the `--serviceaccount` flag in the following command needs to be adjusted to reference the appropriate namespace and ServiceAccount name.
+If you used the `--tiller-namespace` or `--service-account` flags when running `helm init`, the `--serviceaccount` flag in the following command needs to be adjusted to reference the appropriate namespace and ServiceAccount name.
{{< /note >}}
Configure Tiller to have `cluster-admin` access:
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 dba3f0e142..2180f05d36 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
@@ -50,7 +50,7 @@ The following section demonstrates how to create a TLS certificate for a
Kubernetes service accessed through DNS.
{{< note >}}
-**Note:** This tutorial uses CFSSL: Cloudflare's PKI and TLS toolkit [click here](https://blog.cloudflare.com/introducing-cfssl/) to know more.
+This tutorial uses CFSSL: Cloudflare's PKI and TLS toolkit [click here](https://blog.cloudflare.com/introducing-cfssl/) to know more.
{{< /note >}}
## Download and install CFSSL
diff --git a/content/en/docs/tasks/tools/install-kubectl.md b/content/en/docs/tasks/tools/install-kubectl.md
index e7f78b98cd..b5151a4d2e 100644
--- a/content/en/docs/tasks/tools/install-kubectl.md
+++ b/content/en/docs/tasks/tools/install-kubectl.md
@@ -28,7 +28,7 @@ Here are a few methods to install kubectl.
{{< tab name="Ubuntu, Debian or HypriotOS" codelang="bash" >}}
sudo apt-get update && sudo apt-get install -y apt-transport-https
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
-echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
+echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubectl
{{< /tab >}}
@@ -106,7 +106,7 @@ If you are on Windows and using [Powershell Gallery](https://www.powershellgalle
```
{{< note >}}
-**Note:** If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's temp Directory.
+ If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's temp Directory.
{{< /note >}}
The installer creates `$HOME/.kube` and instructs it to create a config file
@@ -118,7 +118,7 @@ If you are on Windows and using [Powershell Gallery](https://www.powershellgalle
```
{{< note >}}
-**Note:** Updating the installation is performed by rerunning the two commands listed in step 1.
+ Updating the installation is performed by rerunning the two commands listed in step 1.
{{< /note >}}
## Install with Chocolatey on Windows
@@ -153,9 +153,13 @@ If you are on Windows and using [Chocolatey](https://chocolatey.org) package man
```
6. Configure kubectl to use a remote Kubernetes cluster:
- New-Item config -type file
+
+ ```
+ New-Item config -type file
+ ```
+
{{< note >}}
- **Note:** Edit the config file with a text editor of your choice, such as Notepad.
+ Edit the config file with a text editor of your choice, such as Notepad.
{{< /note >}}
## Download as part of the Google Cloud SDK
diff --git a/content/en/docs/tasks/tools/install-minikube.md b/content/en/docs/tasks/tools/install-minikube.md
index e6ad64c72b..ca56e7ef26 100644
--- a/content/en/docs/tasks/tools/install-minikube.md
+++ b/content/en/docs/tasks/tools/install-minikube.md
@@ -30,7 +30,7 @@ If you do not already have a hypervisor installed, install the appropriate one f
[KVM](http://www.linux-kvm.org/).
{{< note >}}
- **Note:** Minikube also supports a `-\-vm-driver=none` option that runs the Kubernetes components on the host and not in a VM. Using this driver requires Docker, but not a hypervisor.
+ Minikube also supports a `-\-vm-driver=none` option that runs the Kubernetes components on the host and not in a VM. Using this driver requires Docker and a linux environment, but not a hypervisor.
{{< /note >}}
* Windows: [VirtualBox](https://www.virtualbox.org/wiki/Downloads) or
diff --git a/content/en/docs/test.md b/content/en/docs/test.md
index 3866154477..e7faf57d12 100644
--- a/content/en/docs/test.md
+++ b/content/en/docs/test.md
@@ -157,7 +157,7 @@ $ echo 'Tab lists may contain code blocks!'
Nested header tags may also be included.
{{< warning >}}
-**Note**: Headers within tab lists will not appear in the Table of Contents.
+Headers within tab lists will not appear in the Table of Contents.
{{< /warning >}}
{{% /tab %}}
@@ -321,7 +321,7 @@ A sidebar offsets text visually, but without the visual prominence of
Admonitions (notes, warnings, etc) use Hugo shortcodes.
{{< note >}}
-**Note:** Notes catch the reader's attention without a sense of urgency.
+Notes catch the reader's attention without a sense of urgency.
You can have multiple paragraphs and block-level elements inside an admonition.
@@ -329,12 +329,12 @@ You can have multiple paragraphs and block-level elements inside an admonition.
{{< /note >}}
{{< caution >}}
-**Caution:** The reader should proceed with caution.
+The reader should proceed with caution.
{{< /caution >}}
{{< warning >}}
-**Warning:** Warnings point out something that could cause harm if ignored.
+Warnings point out something that could cause harm if ignored.
{{< /warning >}}
diff --git a/content/en/docs/tutorials/clusters/apparmor.md b/content/en/docs/tutorials/clusters/apparmor.md
index 9102185c38..1f6658fe2b 100644
--- a/content/en/docs/tutorials/clusters/apparmor.md
+++ b/content/en/docs/tutorials/clusters/apparmor.md
@@ -65,9 +65,11 @@ Make sure:
If the Kubelet contains AppArmor support (>= v1.4), it will refuse to run a Pod with AppArmor
options if the kernel module is not enabled.
- **Note:** Ubuntu carries many AppArmor patches that have not been merged into the upstream Linux
- kernel, including patches that add additional hooks and features. Kubernetes has only been
- tested with the upstream version, and does not promise support for other features.
+ {{< note >}}
+ Ubuntu carries many AppArmor patches that have not been merged into the upstream Linux
+ kernel, including patches that add additional hooks and features. Kubernetes has only been
+ tested with the upstream version, and does not promise support for other features.
+ {{< /note >}}
3. Container runtime is Docker -- Currently the only Kubernetes-supported container runtime that
also supports AppArmor is Docker. As more runtimes add AppArmor support, the options will be
@@ -117,9 +119,11 @@ gke-test-default-pool-239f5d02-xwux: kubelet is posting ready status. AppArmor e
## Securing a Pod
-**Note:** AppArmor is currently in beta, so options are specified as annotations. Once support graduates to
+{{< note >}}
+AppArmor is currently in beta, so options are specified as annotations. Once support graduates to
general availability, the annotations will be replaced with first-class fields (more details in
[Upgrade path to GA](#upgrade-path-to-general-availability)).
+{{< /note >}}
AppArmor profiles are specified *per-container*. To specify the AppArmor profile to run a Pod
container with, add an annotation to the Pod's metadata:
@@ -303,7 +307,7 @@ nodes. There are lots of ways to setup the profiles though, such as:
* Through a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) that runs a Pod on each node to
ensure the correct profiles are loaded. An example implementation can be found
- [here](https://git.k8s.io/contrib/apparmor/loader).
+ [here](https://git.k8s.io/kubernetes/test/images/apparmor-loader).
* At node initialization time, using your node initialization scripts (e.g. Salt, Ansible, etc.) or
image.
* By copying the profiles to each node and loading them through SSH, as demonstrated in the
diff --git a/content/en/docs/tutorials/hello-minikube.md b/content/en/docs/tutorials/hello-minikube.md
index f9f8867413..11e04c12fc 100644
--- a/content/en/docs/tutorials/hello-minikube.md
+++ b/content/en/docs/tutorials/hello-minikube.md
@@ -12,47 +12,33 @@ menu:
{{% capture overview %}}
-The goal of this tutorial is for you to turn a simple Hello World Node.js app
-into an application running on Kubernetes. The tutorial shows you how to
-take code that you have developed on your machine, turn it into a Docker
-container image and then run that image on [Minikube](/docs/getting-started-guides/minikube).
-Minikube provides a simple way of running Kubernetes on your local machine for free.
+This tutorial shows you how to run a simple Hello World Node.js app
+on Kubernetes using [Minikube](/docs/getting-started-guides/minikube) and Katacoda.
+Katacoda provides a free, in-browser Kubernetes environment.
+
+{{< note >}}
+You can also follow this tutorial if you've installed [Minikube locally](/docs/tasks/tools/install-minikube/).
+{{< /note >}}
{{% /capture %}}
{{% capture objectives %}}
-* Run a hello world Node.js application.
-* Deploy the application to Minikube.
+* Deploy a hello world application to Minikube.
+* Run the app.
* View application logs.
-* Update the application image.
-
{{% /capture %}}
{{% capture prerequisites %}}
-* For macOS, you can use [Homebrew](https://brew.sh) to install Minikube.
+This tutorial provides a container image built from the following files:
- {{< note >}}
- **Note:** If you see the following Homebrew error when you run `brew update` after you update your computer to macOS 10.13:
-
- ```shell
- Error: /usr/local is not writable. You should change the ownership
- and permissions of /usr/local back to your user account:
- sudo chown -R $(whoami) /usr/local
- ```
- You can resolve the issue by reinstalling Homebrew:
- ```shell
- /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
- ```
- {{< /note >}}
+{{< codenew language="js" file="minikube/server.js" >}}
-* [NodeJS](https://nodejs.org/en/) is required to run the sample application.
-
-* Install Docker. On macOS, we recommend
-[Docker for Mac](https://docs.docker.com/engine/installation/mac/).
+{{< codenew language="conf" file="minikube/Dockerfile" >}}
+For more information on the `docker build` command, read the [Docker documentation](https://docs.docker.com/engine/reference/commandline/build/).
{{% /capture %}}
@@ -60,150 +46,21 @@ Minikube provides a simple way of running Kubernetes on your local machine for f
## Create a Minikube cluster
-This tutorial uses [Minikube](https://github.com/kubernetes/minikube) to
-create a local cluster. This tutorial also assumes you are using
-[Docker for Mac](https://docs.docker.com/engine/installation/mac/)
-on macOS. If you are on a different platform like Linux, or using VirtualBox
-instead of Docker for Mac, the instructions to install Minikube may be
-slightly different. For general Minikube installation instructions, see
-the [Minikube installation guide](/docs/getting-started-guides/minikube/).
+1. Click **Launch Terminal**
-Use Homebrew to install the latest Minikube release:
-```shell
-brew cask install minikube
-```
+ {{< kat-button >}}
-Install the HyperKit driver, as described by the
-[Minikube driver installation guide](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperkit-driver).
+ {{< note >}}If you installed Minikube locally, run `minikube start`.{{< /note >}}
-Use Homebrew to download the `kubectl` command-line tool, which you can
-use to interact with Kubernetes clusters:
+2. Open the Kubernetes dashboard in a browser:
-```shell
-brew install kubernetes-cli
-```
+ ```shell
+ minikube dashboard
+ ```
-Determine whether you can access sites like [https://cloud.google.com/container-registry/](https://cloud.google.com/container-registry/) directly without a proxy, by opening a new terminal and using
+3. Katacoda environment only: At the top of the terminal pane, click the plus sign, and then click **Select port to view on Host 1**.
-```shell
-curl --proxy "" https://cloud.google.com/container-registry/
-```
-
-Make sure that the Docker daemon is started. You can determine if docker is running by using a command such as:
-
-```shell
-docker images
-```
-
-If NO proxy is required, start the Minikube cluster:
-
-```shell
-minikube start --vm-driver=hyperkit
-```
-If a proxy server is required, use the following method to start Minikube cluster with proxy setting:
-
-```shell
-minikube start --vm-driver=hyperkit --docker-env HTTP_PROXY=http://your-http-proxy-host:your-http-proxy-port --docker-env HTTPS_PROXY=http(s)://your-https-proxy-host:your-https-proxy-port
-```
-
-The `--vm-driver=hyperkit` flag specifies that you are using Docker for Mac. The
-default VM driver is VirtualBox.
-
-Now set the Minikube context. The context is what determines which cluster
-`kubectl` is interacting with. You can see all your available contexts in the
-`~/.kube/config` file.
-
-```shell
-kubectl config use-context minikube
-```
-
-Verify that `kubectl` is configured to communicate with your cluster:
-
-```shell
-kubectl cluster-info
-```
-
-Open the Kubernetes dashboard in a browser:
-
-```shell
-minikube dashboard
-```
-
-## Create your Node.js application
-
-The next step is to write the application. Save this code in a folder named `hellonode`
-with the filename `server.js`:
-
-{{< codenew language="js" file="minikube/server.js" >}}
-
-Run your application:
-
-```shell
-node server.js
-```
-
-You should be able to see your "Hello World!" message at http://localhost:8080/.
-
-Stop the running Node.js server by pressing **Ctrl-C**.
-
-The next step is to package your application in a Docker container.
-
-## Create a Docker container image
-
-Create a file, also in the `hellonode` folder, named `Dockerfile`. A Dockerfile describes
-the image that you want to build. You can build a Docker container image by extending an
-existing image. The image in this tutorial extends an existing Node.js image.
-
-{{< codenew language="conf" file="minikube/Dockerfile" >}}
-
-This recipe for the Docker image starts from the official Node.js LTS image
-found in the Docker registry, exposes port 8080, copies your `server.js` file
-to the image and starts the Node.js server.
-
-By default, Docker will create images and store them in your local machine's Docker registry.
-In this tutorial, we will not use your local machine's Docker registry; we will use the
-Docker registry of the Docker daemon running _inside_ Minikube's vm instance. To point the
-'docker' command to your Minikube's Docker daemon, type (unix shells):
-
-```shell
-eval $(minikube docker-env)
-```
-
-or in powershell:
-```shell
-minikube docker-env | Invoke-Expression
-```
-
-
-
-{{< note >}}
-**Note:** Later, when you no longer wish to use the Minikube host, you can undo
-this change by running `eval $(minikube docker-env -u)`.
-{{< /note >}}
-
-Build your Docker image, using the Minikube Docker daemon (mind the trailing dot):
-
-```shell
-docker build -t hello-node:v1 .
-```
-
-check that the image is in Minikube's Docker registry:
-
-```shell
-minikube ssh docker images
-```
-
-Output:
-
-```shell
-REPOSITORY TAG IMAGE ID CREATED SIZE
-hello-node v1 f82485ca953c 3 minutes ago 655MB
-...
-node 6.9.2 faaadb4aaf9b 20 months ago 655MB
-```
-
-
-Now the Minikube VM can run the image you built.
+4. Katacoda environment only: Type 30000, and then click **Display Port**.
## Create a Deployment
@@ -214,59 +71,51 @@ tutorial has only one Container. A Kubernetes
Pod and restarts the Pod's Container if it terminates. Deployments are the
recommended way to manage the creation and scaling of Pods.
-Use the `kubectl run` command to create a Deployment that manages a Pod. The
-Pod runs a Container based on your `hello-node:v1` Docker image. Set the
-`--image-pull-policy` flag to `Never` to always use the local image, rather than
-pulling it from your Docker registry (since you haven't pushed it there):
+1. Use the `kubectl create` command to create a Deployment that manages a Pod. The
+Pod runs a Container based on the provided Docker image.
-```shell
-kubectl run hello-node --image=hello-node:v1 --port=8080 --image-pull-policy=Never
-```
+ ```shell
+ kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node --port=8080
+ ```
-View the Deployment:
+2. View the Deployment:
+ ```shell
+ kubectl get deployments
+ ```
-```shell
-kubectl get deployments
-```
+ Output:
-Output:
+ ```shell
+ NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
+ hello-node 1 1 1 1 1m
+ ```
+3. View the Pod:
-```shell
-NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
-hello-node 1 1 1 1 3m
-```
+ ```shell
+ kubectl get pods
+ ```
+ Output:
-View the Pod:
+ ```shell
+ NAME READY STATUS RESTARTS AGE
+ hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m
+ ```
+4. View cluster events:
-```shell
-kubectl get pods
-```
+ ```shell
+ kubectl get events
+ ```
-Output:
+5. View the `kubectl` configuration:
-
-```shell
-NAME READY STATUS RESTARTS AGE
-hello-node-714049816-ztzrb 1/1 Running 0 6m
-```
-
-View cluster events:
-
-```shell
-kubectl get events
-```
-
-View the `kubectl` configuration:
-
-```shell
-kubectl config view
-```
-
-For more information about `kubectl`commands, see the
-[kubectl overview](/docs/user-guide/kubectl-overview/).
+ ```shell
+ kubectl config view
+ ```
+
+ {{< note >}}For more information about `kubectl`commands, see the [kubectl overview](/docs/user-guide/kubectl-overview/).{{< /note >}}
## Create a Service
@@ -275,142 +124,124 @@ Kubernetes cluster. To make the `hello-node` Container accessible from outside t
Kubernetes virtual network, you have to expose the Pod as a
Kubernetes [*Service*](/docs/concepts/services-networking/service/).
-From your development machine, you can expose the Pod to the public internet
-using the `kubectl expose` command:
+1. Expose the Pod to the public internet using the `kubectl expose` command:
-```shell
-kubectl expose deployment hello-node --type=LoadBalancer
-```
+ ```shell
+ kubectl expose deployment hello-node --type=LoadBalancer
+ ```
+
+ The `--type=LoadBalancer` flag indicates that you want to expose your Service
+ outside of the cluster.
-View the Service you just created:
+2. View the Service you just created:
-```shell
-kubectl get services
-```
+ ```shell
+ kubectl get services
+ ```
-Output:
+ Output:
-```shell
-NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
-hello-node ClusterIP 10.0.0.71 8080/TCP 6m
-kubernetes ClusterIP 10.0.0.1 443/TCP 14d
-```
+ ```shell
+ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+ hello-node LoadBalancer 10.108.144.78 8080:30369/TCP 21s
+ kubernetes ClusterIP 10.96.0.1 443/TCP 23m
+ ```
-The `--type=LoadBalancer` flag indicates that you want to expose your Service
-outside of the cluster. On cloud providers that support load balancers,
-an external IP address would be provisioned to access the Service. On Minikube,
-the `LoadBalancer` type makes the Service accessible through the `minikube service`
-command.
+ On cloud providers that support load balancers,
+ an external IP address would be provisioned to access the Service. On Minikube,
+ the `LoadBalancer` type makes the Service accessible through the `minikube service`
+ command.
-```shell
-minikube service hello-node
-```
+3. Run the following command:
-This automatically opens up a browser window using a local IP address that
-serves your app and shows the "Hello World" message.
+ ```shell
+ minikube service hello-node
+ ```
-Assuming you've sent requests to your new web service using the browser or curl,
-you should now be able to see some logs:
+4. Katacoda environment only: Click the plus sign, and then click **Select port to view on Host 1**.
-```shell
-kubectl logs
-```
+5. Katacoda environment only: Type in the Port number following `8080:`, and then click **Display Port**.
-## Update your app
-
-Edit your `server.js` file to return a new message:
-
-```javascript
-response.end('Hello World Again!');
-
-```
-
-Build a new version of your image (mind the trailing dot):
-
-```shell
-docker build -t hello-node:v2 .
-```
-
-Update the image of your Deployment:
-
-```shell
-kubectl set image deployment/hello-node hello-node=hello-node:v2
-```
-
-Run your app again to view the new message:
-
-```shell
-minikube service hello-node
-```
+ This opens up a browser window that serves your app and shows the "Hello World" message.
## Enable addons
Minikube has a set of built-in addons that can be enabled, disabled and opened in the local Kubernetes environment.
-First list the currently supported addons:
+1. List the currently supported addons:
-```shell
-minikube addons list
-```
+ ```shell
+ minikube addons list
+ ```
-Output:
+ Output:
-```shell
-- storage-provisioner: enabled
-- kube-dns: enabled
-- registry: disabled
-- registry-creds: disabled
-- addon-manager: enabled
-- dashboard: disabled
-- default-storageclass: enabled
-- coredns: disabled
-- heapster: disabled
-- efk: disabled
-- ingress: disabled
-```
+ ```shell
+ addon-manager: enabled
+ coredns: disabled
+ dashboard: enabled
+ default-storageclass: enabled
+ efk: disabled
+ freshpod: disabled
+ heapster: disabled
+ ingress: disabled
+ kube-dns: enabled
+ metrics-server: disabled
+ nvidia-driver-installer: disabled
+ nvidia-gpu-device-plugin: disabled
+ registry: disabled
+ registry-creds: disabled
+ storage-provisioner: enabled
+ ```
+
+2. Enable an addon, for example, `heapster`:
-Minikube must be running for these commands to take effect. To enable `heapster` addon, for example:
+ ```shell
+ minikube addons enable heapster
+ ```
+
+ Output:
-```shell
-minikube addons enable heapster
-```
+ ```shell
+ heapster was successfully enabled
+ ```
-Output:
+3. View the Pod and Service you just created:
-```shell
-heapster was successfully enabled
-```
+ ```shell
+ kubectl get pod,svc -n kube-system
+ ```
-View the Pod and Service you just created:
+ Output:
-```shell
-kubectl get po,svc -n kube-system
-```
+ ```shell
+ NAME READY STATUS RESTARTS AGE
+ pod/heapster-9jttx 1/1 Running 0 26s
+ pod/influxdb-grafana-b29w8 2/2 Running 0 26s
+ pod/kube-addon-manager-minikube 1/1 Running 0 34m
+ pod/kube-dns-6dcb57bcc8-gv7mw 3/3 Running 0 34m
+ pod/kubernetes-dashboard-5498ccf677-cgspw 1/1 Running 0 34m
+ pod/storage-provisioner 1/1 Running 0 34m
-Output:
+ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+ service/heapster ClusterIP 10.96.241.45 80/TCP 26s
+ service/kube-dns ClusterIP 10.96.0.10 53/UDP,53/TCP 34m
+ service/kubernetes-dashboard NodePort 10.109.29.1 80:30000/TCP 34m
+ service/monitoring-grafana NodePort 10.99.24.54 80:30002/TCP 26s
+ service/monitoring-influxdb ClusterIP 10.111.169.94 8083/TCP,8086/TCP 26s
+ ```
-```shell
-NAME READY STATUS RESTARTS AGE
-pod/heapster-zbwzv 1/1 Running 0 2m
-pod/influxdb-grafana-gtht9 2/2 Running 0 2m
+4. Disable `heapster`:
-NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
-service/heapster NodePort 10.0.0.52 80:31655/TCP 2m
-service/monitoring-grafana NodePort 10.0.0.33 80:30002/TCP 2m
-service/monitoring-influxdb ClusterIP 10.0.0.43 8083/TCP,8086/TCP 2m
-```
+ ```shell
+ minikube addons disable heapster
+ ```
+
+ Output:
-Open the endpoint to interacting with heapster in a browser:
-
-```shell
-minikube addons open heapster
-```
-
-Output:
-
-```shell
-Opening kubernetes service kube-system/monitoring-grafana in default browser...
-```
+ ```shell
+ heapster was successfully disabled
+ ```
## Clean up
@@ -421,17 +252,10 @@ kubectl delete service hello-node
kubectl delete deployment hello-node
```
-Optionally, force removal of the Docker images created:
-
-```shell
-docker rmi hello-node:v1 hello-node:v2 -f
-```
-
-Optionally, stop the Minikube VM:
+Optionally, stop the Minikube virtual machine (VM):
```shell
minikube stop
-eval $(minikube docker-env -u)
```
Optionally, delete the Minikube VM:
@@ -442,7 +266,6 @@ minikube delete
{{% /capture %}}
-
{{% capture whatsnext %}}
* Learn more about [Deployment objects](/docs/concepts/workloads/controllers/deployment/).
@@ -450,5 +273,3 @@ minikube delete
* Learn more about [Service objects](/docs/concepts/services-networking/service/).
{{% /capture %}}
-
-
diff --git a/content/en/docs/tutorials/k8s101.md b/content/en/docs/tutorials/k8s101.md
deleted file mode 100644
index 0dedd9f3d2..0000000000
--- a/content/en/docs/tutorials/k8s101.md
+++ /dev/null
@@ -1,183 +0,0 @@
----
-reviewers:
-- eparis
-- mikedanese
-title: Kubernetes 101
-content_template: templates/tutorial
----
-
-{{% capture overview %}}
-
-For Kubernetes 101, we will cover kubectl, Pods, Volumes, and multiple containers.
-
-{{% /capture %}}
-
-{{% capture objectives %}}
-
-* What is `kubectl`.
-* Manage a Pod.
-* Create and mount a volume.
-* Create multiple containers in a Pod.
-
-{{% /capture %}}
-
-{{% capture prerequisites %}}
-
-* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-* In order for the kubectl usage examples to work, make sure you have an example directory locally, either from [a release](https://github.com/kubernetes/kubernetes/releases) or the latest `.yaml` files located [here](https://github.com/kubernetes/website/tree/master/content/en/docs/tutorials).
-
-{{% /capture %}}
-
-{{% capture lessoncontent %}}
-
-## Kubectl CLI
-
-The easiest way to interact with Kubernetes is through the kubectl command-line interface.
-
-For more info about kubectl, including its usage, commands, and parameters, see [Overview of kubectl](/docs/reference/kubectl/overview/).
-
-For more information about installing and configuring kubectl, see [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/).
-
-## Pods
-
-In Kubernetes, a group of one or more containers is called a _Pod_. Containers in a Pod are deployed together, and are started, stopped, and replicated as a group.
-
-For more information, see [Pods](/docs/concepts/workloads/pods/pod/).
-
-
-#### Pod Definition
-
-The simplest Pod definition describes the deployment of a single container. For example, an nginx web server Pod might be defined as:
-
-{{< codenew file="pods/simple-pod.yaml" >}}
-
-A Pod definition is a declaration of a _desired state_. Desired state is a very important concept in the Kubernetes model. Many things present a desired state to the system, and Kubernetes' ensures that the current state matches the desired state. For example, when you create a Pod and declare that the containers in it to be running. If the containers happen not to be running because of a program failure, Kubernetes continues to (re-)create the Pod in order to drive the pod to the desired state. This process continues until you delete the Pod.
-
-For more information, see [Kubernetes Design Documents and Proposals](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/README.md).
-
-
-#### Pod Management
-
-Create a Pod containing an nginx server ([simple-pod.yaml](/examples/pods/simple-pod.yaml)):
-
-```shell
-kubectl create -f https://k8s.io/examples/pods/simple-pod.yaml
-```
-
-List all Pods:
-
-```shell
-kubectl get pods
-```
-
-On most providers, the Pod IPs are not externally accessible. The easiest way to test that the pod is working is to create a busybox Pod and exec commands on it remotely. For more information, see [Get a Shell to a Running Container](/docs/tasks/debug-application-cluster/get-shell-running-container/).
-
-If the IP of the Pod is accessible, you can access its http endpoint with wget on port 80:
-
-```shell
-kubectl run busybox --image=busybox --restart=Never --tty -i --generator=run-pod/v1 --env "POD_IP=$(kubectl get pod nginx -o go-template='{{.status.podIP}}')"
-u@busybox$ wget -qO- http://$POD_IP # Run in the busybox container
-u@busybox$ exit # Exit the busybox container
-```
-
-```shell
-kubectl delete pod busybox # Clean up the pod we created with "kubectl run"
-```
-
-To delete a Pod named nginx:
-
-```shell
-kubectl delete pod nginx
-```
-
-
-#### Volumes
-
-That's great for a simple static web server, but what about persistent storage?
-
-The container file system only lives as long as the container does. So if your app's state needs to survive relocation, reboots, and crashes, you'll need to configure some persistent storage.
-
-In this example you can create a Redis Pod with a named volume, and a volume mount that defines the path to mount the Volume.
-
-1. Define a Volume:
-
- ```yaml
- volumes:
- - name: redis-storage
- emptyDir: {}
- ```
-
-1. Define a Volume mount within a container definition:
-
- ```yaml
- volumeMounts:
- # name must match the volume name defined in volumes
- - name: redis-storage
- # mount path within the container
- mountPath: /data/redis
- ```
-
-Here is an example of Redis Pod definition with a persistent storage volume ([redis.yaml](/examples/pods/storage/redis.yaml)):
-
-{{< codenew file="pods/storage/redis.yaml" >}}
-
-Where:
-
-- The `volumeMounts` `name` is a reference to a specific `volumes` `name`.
-- The `volumeMounts` `mountPath` is the path to mount the volume within the container.
-
-##### Volume Types
-
-- **EmptyDir**: Creates a new directory that exists as long as the Pod is running on the node, but it can persist across container failures and restarts.
-- **HostPath**: Mounts an existing directory on the node's file system. For example (`/var/logs`).
-
-For more information, see [Volumes](/docs/concepts/storage/volumes/).
-
-
-#### Multiple Containers
-
-{{< note >}}
-**Note:** The examples below are syntactically correct, but some of the images (e.g. kubernetes/git-monitor) don't exist yet. We're working on turning these into working examples.
-{{< /note >}}
-
-
-However, often you want to have two different containers that work together. An example of this would be a web server, and a helper job that polls a git repository for new updates:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
- name: www
-spec:
- containers:
- - name: nginx
- image: nginx
- volumeMounts:
- - mountPath: /srv/www
- name: www-data
- readOnly: true
- - name: git-monitor
- image: kubernetes/git-monitor
- env:
- - name: GIT_REPO
- value: http://github.com/some/repo.git
- volumeMounts:
- - mountPath: /data
- name: www-data
- volumes:
- - name: www-data
- emptyDir: {}
-```
-
-Note that we have also added a Volume here. In this case, the Volume is mounted into both containers. It is marked `readOnly` in the web server's case, since it doesn't need to write to the directory.
-
-Finally, we have also introduced an environment variable to the `git-monitor` container, which allows us to parameterize that container with the particular git repository that we want to track.
-
-{{% /capture %}}
-
-{{% capture whatsnext %}}
-
-Continue on to [Kubernetes 201](/docs/tutorials/k8s201/) or
-for a complete application see the [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)
-
-{{% /capture %}}
diff --git a/content/en/docs/tutorials/k8s201.md b/content/en/docs/tutorials/k8s201.md
deleted file mode 100644
index 3c8b3aa8f9..0000000000
--- a/content/en/docs/tutorials/k8s201.md
+++ /dev/null
@@ -1,266 +0,0 @@
----
-reviewers:
-- janetkuo
-- mikedanese
-title: Kubernetes 201
-content_template: templates/tutorial
----
-
-
-{{% capture overview %}}
-
-For Kubernetes 201, we will pick up where 101 left off and cover some slightly more advanced topics in Kubernetes, related to application productionization, Deployment and scaling.
-
-If you went through [Kubernetes 101](/docs/tutorials/k8s101/), you learned about kubectl, Pods, Volumes, and multiple containers.
-
-{{% /capture %}}
-
-{{% capture objectives %}}
-
-* Add labels to the Pod.
-* Manage a Deployment.
-* Manage a Service.
-* What is the health checking.
-
-{{% /capture %}}
-
-{{% capture prerequisites %}}
-
-* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-* In order for the kubectl usage examples to work, make sure you have an examples directory locally, either from [a release](https://github.com/kubernetes/kubernetes/releases) or [the source](https://github.com/kubernetes/kubernetes).
-
-{{% /capture %}}
-
-{{% capture lessoncontent %}}
-
-## Labels
-
-Having already learned about Pods and how to create them, you may be struck by an urge to create many, many Pods. Please do! But eventually you will need a system to organize these Pods into groups. The system for achieving this in Kubernetes is Labels. Labels are key-value pairs that are attached to each object in Kubernetes. Label selectors can be passed along with a RESTful `list` request to the apiserver to retrieve a list of objects which match that label selector.
-
-To add a label, add a labels section under metadata in the Pod definition:
-
-```yaml
- labels:
- env: test
-```
-
-For example, here is the nginx Pod definition with labels ([pod-nginx.yaml](/examples/pods/pod-nginx.yaml)):
-
-{{< codenew file="pods/pod-nginx.yaml" >}}
-
-Create the labeled Pod:
-
-```shell
-kubectl create -f https://k8s.io/examples/pods/pod-nginx.yaml
-```
-
-List all Pods with the label `env=test`:
-
-```shell
-kubectl get pods -l env=test
-```
-
-Delete the Pod by label:
-
-```shell
-kubectl delete pod -l env=test
-```
-
-For more information, see [Labels](/docs/concepts/overview/working-with-objects/labels/).
-They are a core concept used by two additional Kubernetes building blocks: Deployments and Services.
-
-
-## Deployments
-
-Now that you know how to make awesome, multi-container, labeled Pods and you want to use them to build an application, you might be tempted to just start building a whole bunch of individual Pods, but if you do that, a whole host of operational concerns pop up. For example: how will you scale the number of Pods up or down? How will you roll out a new release?
-
-The answer to those questions and more is to use a [Deployment](/docs/concepts/workloads/controllers/deployment/) to manage maintaining and updating your running _Pods_.
-
-A Deployment object defines a Pod creation template (a "cookie-cutter" if you will) and desired replica count. The Deployment uses a label selector to identify the Pods it manages, and will create or delete Pods as needed to meet the replica count. Deployments are also used to manage safely rolling out changes to your running Pods.
-
-Here is a Deployment that instantiates two nginx Pods:
-
-{{< codenew file="application/deployment.yaml" >}}
-
-
-### Deployment Management
-
-Create an nginx Deployment:
-
-```shell
-kubectl create -f https://k8s.io/examples/application/deployment.yaml
-```
-
-List all Deployments:
-
-```shell
-kubectl get deployment
-```
-
-List the Pods created by the Deployment:
-
-```shell
-kubectl get pods -l app=nginx
-```
-
-Upgrade the nginx container from 1.7.9 to 1.8 by changing the Deployment and calling `apply`. The following config
-contains the desired changes:
-
-{{< codenew file="application/deployment-update.yaml" >}}
-
-```shell
-kubectl apply -f https://k8s.io/examples/application/deployment-update.yaml
-```
-
-Watch the Deployment create Pods with new names and delete the old Pods:
-
-```shell
-kubectl get pods -l app=nginx
-```
-
-Delete the Deployment by name:
-
-```shell
-kubectl delete deployment nginx-deployment
-```
-
-For more information, such as how to rollback Deployment changes to a previous version, see [_Deployments_](/docs/concepts/workloads/controllers/deployment/).
-
-
-## Services
-
-Once you have a replicated set of Pods, you need an abstraction that enables connectivity between the layers of your application. For example, if you have a Deployment managing your backend jobs, you don't want to have to reconfigure your front-ends whenever you re-scale your backends. Likewise, if the Pods in your backends are scheduled (or rescheduled) onto different machines, you can't be required to re-configure your front-ends. In Kubernetes, the service abstraction achieves these goals. A service provides a way to refer to a set of Pods (selected by labels) with a single static IP address. It may also provide load balancing, if supported by the provider.
-
-For example, here is a service that balances across the Pods created in the previous nginx Deployment example ([service.yaml](/examples/service/nginx-service.yaml)):
-
-{{< codenew file="service/nginx-service.yaml" >}}
-
-
-### Service Management
-
-Create an nginx Service:
-
-```shell
-kubectl create -f https://k8s.io/examples/service/nginx-service.yaml
-```
-
-List all services:
-
-```shell
-kubectl get services
-```
-
-On most providers, the service IPs are not externally accessible. The easiest way to test that the service is working is to create a busybox Pod and exec commands on it remotely. See the [command execution documentation](/docs/user-guide/kubectl-overview/) for details.
-
-Provided the service IP is accessible, you should be able to access its http endpoint with wget on the exposed port:
-
-```shell
-export SERVICE_IP=$(kubectl get service nginx-service -o go-template='{{.spec.clusterIP}}')
-export SERVICE_PORT=$(kubectl get service nginx-service -o go-template='{{(index .spec.ports 0).port}}')
-```
-
-Check `$SERVICE_IP` and `$SERVICE_PORT`:
-
-```shell
-echo "$SERVICE_IP:$SERVICE_PORT"
-```
-
-Then, create a busybox Pod:
-```shell
-kubectl run busybox --generator=run-pod/v1 --image=busybox --restart=Never --tty -i --env "SERVICE_IP=$SERVICE_IP" --env "SERVICE_PORT=$SERVICE_PORT"
-u@busybox$ wget -qO- http://$SERVICE_IP:$SERVICE_PORT # Run in the busybox container
-u@busybox$ exit # Exit the busybox container
-
-kubectl delete pod busybox # Clean up the pod we created with "kubectl run"
-
-```
-
-The service definition [exposed the Nginx Service](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) as port 8000 (`$SERVICE_PORT`). We can also access the service from a host running Kubernetes using that port:
-
-```shell
-wget -qO- http://$SERVICE_IP:$SERVICE_PORT # Run on a Kubernetes host
-```
-
-(This works on AWS with Weave.)
-
-To delete the service by name:
-
-```shell
-kubectl delete service nginx-service
-```
-
-When created, each service is assigned a unique IP address. This address is tied to the lifespan of the Service, and will not change while the Service is alive. Pods can be configured to talk to the service, and know that communication to the service will be automatically load-balanced out to some Pod that is a member of the set identified by the label selector in the Service.
-
-For more information, see [Services](/docs/concepts/services-networking/service/).
-
-
-## Health Checking
-
-When I write code it never crashes, right? Sadly the [Kubernetes issues list](https://github.com/kubernetes/kubernetes/issues) indicates otherwise...
-
-Rather than trying to write bug-free code, a better approach is to use a management system to perform periodic health checking
-and repair of your application. That way a system outside of your application itself is responsible for monitoring the
-application and taking action to fix it. It's important that the system be outside of the application, since if
-your application fails and the health checking agent is part of your application, it may fail as well and you'll never know.
-In Kubernetes, the health check monitor is the Kubelet agent.
-
-### Process Health Checking
-
-The simplest form of health-checking is just process level health checking. The Kubelet constantly asks the Docker daemon
-if the container process is still running, and if not, the container process is restarted. In all of the Kubernetes examples
-you have run so far, this health checking was actually already enabled. It's on for every single container that runs in
-Kubernetes.
-
-### Application Health Checking
-
-However, in many cases this low-level health checking is insufficient. Consider, for example, the following code:
-
-```go
-lockOne := sync.Mutex{}
-lockTwo := sync.Mutex{}
-
-go func() {
- lockOne.Lock();
- lockTwo.Lock();
- ...
-}()
-
-lockTwo.Lock();
-lockOne.Lock();
-```
-
-This is a classic example of a problem in computer science known as ["Deadlock"](https://en.wikipedia.org/wiki/Deadlock). From Docker's perspective your application is
-still operating and the process is still running, but from your application's perspective your code is locked up and will never respond correctly.
-
-To address this problem, Kubernetes supports user implemented application health-checks. These checks are performed by the
-Kubelet to ensure that your application is operating correctly for a definition of "correctly" that _you_ provide.
-
-Currently, there are three types of application health checks that you can choose from:
-
- * HTTP Health Checks - The Kubelet will call a web hook. If it returns between 200 and 399, it is considered success, failure otherwise. See health check examples [here](/docs/user-guide/liveness/).
- * Container Exec - The Kubelet will execute a command inside your container. If it exits with status 0 it will be considered a success. See health check examples [here](/docs/user-guide/liveness/).
- * TCP Socket - The Kubelet will attempt to open a socket to your container. If it can establish a connection, the container is considered healthy, if it can't it is considered a failure.
-
-In all cases, if the Kubelet discovers a failure the container is restarted.
-
-The container health checks are configured in the `livenessProbe` section of your container config. There you can also specify an `initialDelaySeconds` that is a grace period from when the container is started to when health checks are performed, to enable your container to perform any necessary initialization.
-
-Here is an example config for a Pod with an HTTP health check
-([pod-with-http-healthcheck.yaml](/examples/pods/probe/pod-with-http-healthcheck.yaml)):
-
-{{< codenew file="pods/probe/pod-with-http-healthcheck.yaml" >}}
-
-And here is an example config for a Pod with a TCP Socket health check
-([pod-with-tcp-socket-healthcheck.yaml](/examples/pods/probe/pod-with-tcp-socket-healthcheck.yaml)):
-
-{{< codenew file="pods/probe/pod-with-tcp-socket-healthcheck.yaml" >}}
-
-For more information about health checking, see [Container Probes](/docs/user-guide/pod-states/#container-probes).
-
-{{% /capture %}}
-
-{{% capture whatsnext %}}
-
-For a complete application see the [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/).
-
-{{% /capture %}}
diff --git a/content/en/docs/tutorials/kubernetes-basics/_index.html b/content/en/docs/tutorials/kubernetes-basics/_index.html
index a609220ff8..39a7f9a56f 100644
--- a/content/en/docs/tutorials/kubernetes-basics/_index.html
+++ b/content/en/docs/tutorials/kubernetes-basics/_index.html
@@ -45,25 +45,25 @@ weight: 10