Merge branch 'release-1.12' into token-feature-beta

.dockerignore

@@ -0,0 +1 @@
+**

Makefile

@@ -1,5 +1,5 @@
 DOCKER       = docker
-HUGO_VERSION = 0.44
+HUGO_VERSION = 0.47.1
 DOCKER_IMAGE = kubernetes-hugo
 DOCKER_RUN   = $(DOCKER) run --rm --interactive --tty --volume $(PWD):/src
 
@@ -8,14 +8,22 @@ DOCKER_RUN   = $(DOCKER) run --rm --interactive --tty --volume $(PWD):/src
 help: ## Show this help.
 	@awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z_-]+:.*?## / {sub("\\\\n",sprintf("\n%22c"," "), $$2);printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}' $(MAKEFILE_LIST)
 
-all: build ## Build site with production settings and put deliverables in _site.
+all: build ## Build site with production settings and put deliverables in ./public
 
-build: ## Build site with production settings and put deliverables in _site.
+build: ## Build site with production settings and put deliverables in ./public
 	hugo
 
-build-preview: ## Build site with drafts and future posts enabled.
+build-preview: ## Build site with drafts and future posts enabled
 	hugo -D -F
 
+check-headers-file:
+	scripts/check-headers-file.sh
+
+production-build: build check-headers-file ## Build the production site and ensure that noindex headers aren't added
+
+non-production-build: ## Build the non-production site, which adds noindex headers to prevent indexing
+	hugo --enableGitInfo
+
 serve: ## Boot the development server.
 	hugo server --ignoreCache --disableFastRender
 

README.md

@@ -1,8 +1,10 @@
-## Instructions for Contributing to the Kubernetes Documentation
+# The Kubernetes documentation
 
-Welcome! We are very pleased you want to contribute to the Kubernetes documentation.
+Welcome! This repository houses all of the assets required to build the Kubernetes website and documentation. We're very pleased that you want to contribute!
 
-You can click the **Fork** button in the upper-right area of the screen to create a copy of this repository in your GitHub account called a *fork*. Make any changes you want in your fork, and when you are ready to send those changes to us, go to your fork and create a new pull request to let us know about it.
+## Contributing to the docs
+
+You can click the **Fork** button in the upper-right area of the screen to create a copy of this repository in your GitHub account. This copy is called a *fork*. Make any changes you want in your fork, and when you are ready to send those changes to us, go to your fork and create a new pull request to let us know about it.
 
 Once your pull request is created, a Kubernetes reviewer will take responsibility for providing clear, actionable feedback.  As the owner of the pull request, **it is your responsibility to modify your pull request to address the feedback that has been provided to you by the Kubernetes reviewer.**  Also note that you may end up having more than one Kubernetes reviewer provide you feedback or you may end up getting feedback from a Kubernetes reviewer that is different than the one originally assigned to provide you feedback. Furthermore, in some cases, one of your reviewers might ask for a technical review from a [Kubernetes tech reviewer](https://github.com/kubernetes/website/wiki/Tech-reviewers) when needed.  Reviewers will do their best to provide feedback in a timely fashion but response time can vary based on circumstances.
 
@@ -13,41 +15,36 @@ For more information about contributing to the Kubernetes documentation, see:
 * [Using Page Templates](http://kubernetes.io/docs/contribute/style/page-templates/)
 * [Documentation Style Guide](http://kubernetes.io/docs/contribute/style/style-guide/)
 
+## Running the site locally using Hugo
+
+The Kubernetes documentation is built using the [Hugo](https://gohugo.io) static site generator. See the [official Hugo documentation](https://gohugo.io/getting-started/installing/) for Hugo installation instructions.
+
+> Building and running the site requires the Hugo version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L9) file.
+
+To run the site locally when you have Hugo installed:
+
+```bash
+make serve
+```
+
+This will start the local Hugo server on port 1313. Open up your browser to http://localhost:1313 to view the site. As you make changes to the source files, Hugo updates immediately and forces a browser refresh.
+
 ## Building the site using Docker
 
-If you'd like, you can build the Kubernetes docs using Docker. To get started, build the image locally:
+You can build the Kubernetes docs using [Docker](https://docker.com). To get started, make sure that you have Docker running and build the image locally:
 
 ```bash
 make docker-image
-
-# The underlying command:
-docker build . \
-  --tag kubernetes-hugo \
-  --build-arg HUGO_VERSION=0.40.3
 ```
 
-You can create an image for a different version of Hugo by changing the value of the `HUGO_VERSION` argument for the build. You *must* specify a version or the image will not build.
-Once the `kubernetes-hugo` image has been built locally, you can build the site:
+Once the `kubernetes-hugo` image has been built locally, you can run the site locally:
 
 ```bash
 make docker-serve
-
-# The underlying command:
-docker run \
-  --rm \
-  --interactive \
-  --tty \
-  --volume $(PWD):/src \
-  -p 1313:1313 \
-  kubernetes-hugo \
-  hugo server \
-  --watch \
-  --bind 0.0.0.0
 ```
 
-As when building without using a Docker container, the results of the build will be published to the `public` directory (the default output directory for [Hugo](https://gohugo.io), the static site generator used to build this site).
+Open up your browser to http://localhost:1313 to view the site.
 
 ## Thank you!
 
-Kubernetes thrives on community participation, and we really appreciate your
-contributions to our site and our documentation!
+Kubernetes thrives on community participation, and we really appreciate your contributions to our site and our documentation!

content/en/_index.html

@@ -48,7 +48,7 @@ <h2>The Challenges of Migrating 150+ Microservices to Kubernetes</h2>
         <br>
         <br>
         <br>
-        <a href="https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2018/" button id= "desktopKCButton">Attend KubeCon in Shanghai on Nov. 13-15, 2018</a>
+        <a href="https://events.linuxfoundation.cn/events/kubecon-cloudnativecon-china-2018/" button id= "desktopKCButton">Attend KubeCon in Shanghai on Nov. 13-15, 2018</a>
         <br>
         <br>
         <br>

content/en/blog/_posts/2018-06-26-kubernetes-1.11-release-announcement.md

@@ -92,7 +92,7 @@ Is Kubernetes helping your team? Share your story with the community.
 
 ## KubeCon
 
-The world’s largest Kubernetes gathering, KubeCon + CloudNativeCon is coming to [Shanghai](https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2018/) from November 14-15, 2018 and [Seattle](https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/) from December 11-13, 2018. This conference will feature technical sessions, case studies, developer deep dives, salons and more! The CFP for both event is currently open. [Submit your talk](https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/program/call-for-proposals-cfp/) and [register](https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2018/attend/register/) today!
+The world’s largest Kubernetes gathering, KubeCon + CloudNativeCon is coming to [Shanghai](https://events.linuxfoundation.cn/events/kubecon-cloudnativecon-china-2018/ from November 14-15, 2018 and [Seattle](https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/) from December 11-13, 2018. This conference will feature technical sessions, case studies, developer deep dives, salons and more! The CFP for both event is currently open. [Submit your talk](https://events.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2018/program/call-for-proposals-cfp/) and [register](https://www.regonline.com/registration/Checkin.aspx?EventID=2246960) today!
 
 ## Webinar
 

content/en/blog/_posts/2018-07-10-coredns-ga.md

@@ -18,7 +18,14 @@ CoreDNS is a general-purpose, authoritative DNS server that provides a backwards
 
 In this article, you will learn about the differences in the implementations of kube-dns and CoreDNS, and some of the helpful extensions offered by CoreDNS.
 
-## Implemenation differences
+## We appreciate your feedback
+
+We are conducting a survey to evaluate the adoption of CoreDNS as the DNS for Kubernetes's cluster. 
+If you are currently using CoreDNS inside a Kubernetes cluster, please, [take 5 minutes to provide us some feedback by filling this survey](https://www.surveymonkey.com/r/SKZQSLK).
+
+Thank you, we appreciate your collaboration here.
+
+## Implementation differences
 
 In kube-dns, several containers are used within a single pod: `kubedns`, `dnsmasq`, and `sidecar`. The `kubedns`
 container watches the Kubernetes API and serves DNS records based on the [Kubernetes DNS specification](https://github.com/kubernetes/dns/blob/master/docs/specification.md), `dnsmasq` provides caching and stub domain support, and `sidecar` provides metrics and health checks.

content/en/blog/_posts/2018-08-10-introducing-kubebuilder.md

@@ -24,7 +24,7 @@ Applications and cluster resources typically require some operational work - whe
 
 With the Kubernetes API model, management logic is embedded directly into an application specific Kubernetes API, e.g. a “MySQL” API. Users then declaratively manage the application through YAML configuration using tools such as kubectl, just like they do for Kubernetes objects. This approach is referred to as an Application Controller, also known as an Operator. Controllers are a powerful technique backing the core Kubernetes APIs that may be used to build many kinds of solutions in addition to Applications; such as Autoscalers, Workload APIs, Configuration APIs, CI/CD systems, and more.
 
-However, while it has been possible for trailblazers to build new Controllers on top of the raw API machinery, doing so has been a DIY “from scratch” experience, requiring developers to learn low level details about how Kubernetes libraries are implemented, handwrite boilerplate code, and warp their own solutions for integration testing, RBAC configuration, documentation, etc. Kubebuilder makes this experience simple and easy by applying the lessons learned from building the core Kubernetes APIs.
+However, while it has been possible for trailblazers to build new Controllers on top of the raw API machinery, doing so has been a DIY “from scratch” experience, requiring developers to learn low level details about how Kubernetes libraries are implemented, handwrite boilerplate code, and wrap their own solutions for integration testing, RBAC configuration, documentation, etc. Kubebuilder makes this experience simple and easy by applying the lessons learned from building the core Kubernetes APIs.
 
 ### Getting Started Building Application Controllers and Kubernetes APIs
 
@@ -37,7 +37,7 @@ By providing an opinionated and structured solution for creating Controllers and
 This will scaffold the API and Controller for users to modify, as well as scaffold integration tests, RBAC rules, Dockerfiles, Makefiles, etc.
 After adding their implementation to the project, users create the artifacts to publish their API through:
 
- 1. Build and push the container image from the provided Dockerfile using `make docker-build`` and `make docker-push` commands
+ 1. Build and push the container image from the provided Dockerfile using `make docker-build` and `make docker-push` commands
  2. Deploy the API using `make deploy` command
 
 Whether you are already a Controller aficionado or just want to learn what the buzz is about, check out the [kubebuilder repo][kubebuilder-repo] or take a look at an example in the [kubebuilder book][kubebuilder-book] to learn about how simple and easy it is to build Controllers.