diff --git a/.dockerignore b/.dockerignore
new file mode 100644
index 0000000000..1d085cacc9
--- /dev/null
+++ b/.dockerignore
@@ -0,0 +1 @@
+**
diff --git a/Makefile b/Makefile
index 9318b4ee4f..747dfd091f 100644
--- a/Makefile
+++ b/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
diff --git a/README.md b/README.md
index ade55e6807..20de961d16 100644
--- a/README.md
+++ b/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!
diff --git a/content/en/_index.html b/content/en/_index.html
index b96ce43678..9920fae9d8 100644
--- a/content/en/_index.html
+++ b/content/en/_index.html
@@ -48,7 +48,7 @@ cid: home
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
index d28a628c31..2e546d291e 100644
--- 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
@@ -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
diff --git a/content/en/blog/_posts/2018-07-10-coredns-ga.md b/content/en/blog/_posts/2018-07-10-coredns-ga.md
index 302b592b1a..4745665e40 100644
--- a/content/en/blog/_posts/2018-07-10-coredns-ga.md
+++ b/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.
diff --git a/content/en/blog/_posts/2018-08-10-introducing-kubebuilder.md b/content/en/blog/_posts/2018-08-10-introducing-kubebuilder.md
index d5c6a3bbab..08fc08fa7e 100644
--- a/content/en/blog/_posts/2018-08-10-introducing-kubebuilder.md
+++ b/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.
diff --git a/content/en/blog/_posts/2018-08-29-kubernetes-testing-ci-automating-contributor-experience.md b/content/en/blog/_posts/2018-08-29-kubernetes-testing-ci-automating-contributor-experience.md
new file mode 100644
index 0000000000..d9a6c42c0e
--- /dev/null
+++ b/content/en/blog/_posts/2018-08-29-kubernetes-testing-ci-automating-contributor-experience.md
@@ -0,0 +1,91 @@
+---
+layout: blog
+title: 'The Machines Can Do the Work, a Story of Kubernetes Testing, CI, and Automating the Contributor Experience'
+date: 2018-08-29
+---
+
+**Author**: Aaron Crickenberger (Google) and Benjamin Elder (Google)
+
+_“Large projects have a lot of less exciting, yet, hard work. We value time spent automating repetitive work more highly than toil. Where that work cannot be automated, it is our culture to recognize and reward all types of contributions. However, heroism is not sustainable.”_ - [Kubernetes Community Values](https://github.com/kubernetes/steering/blob/master/values.md#automation-over-process)
+
+Like many open source projects, Kubernetes is hosted on GitHub. We felt the barrier to participation would be lowest if the project lived where developers already worked, using tools and processes developers already knew. Thus the project embraced the service fully: it was the basis of our workflow, our issue tracker, our documentation, our blog platform, our team structure, and more.
+
+This strategy worked. It worked so well that the project quickly scaled past its contributors’ capacity as humans. What followed was an incredible journey of automation and innovation. We didn’t just need to rebuild our airplane mid-flight without crashing, we needed to convert it into a rocketship and launch into orbit. We needed machines to do the work.
+
+## The Work
+
+Initially, we focused on the fact that we needed to support the sheer volume of tests mandated by a complex distributed system such as Kubernetes. Real world failure scenarios had to be exercised via end-to-end (e2e) tests to ensure proper functionality. Unfortunately, e2e tests were susceptible to flakes (random failures) and took anywhere from an hour to a day to complete.
+
+Further experience revealed other areas where machines could do the work for us:
+
+* PR Workflow
+ * Did the contributor sign our CLA?
+ * Did the PR pass tests?
+ * Is the PR mergeable?
+ * Did the merge commit pass tests?
+* Triage
+ * Who should be reviewing PRs?
+ * Is there enough information to route an issue to the right people?
+ * Is an issue still relevant?
+* Project Health
+ * What is happening in the project?
+ * What should we be paying attention to?
+
+As we developed automation to improve our situation, we followed a few guiding principles:
+
+* Follow the push/poll control loop patterns that worked well for Kubernetes
+* Prefer stateless loosely coupled services that do one thing well
+* Prefer empowering the entire community over empowering a few core contributors
+* Eat our own dogfood and avoid reinventing wheels
+
+## Enter Prow
+
+This led us to create [Prow](https://git.k8s.io/test-infra/prow) as the central component for our automation. Prow is sort of like an [If This, Then That](https://ifttt.com/) for GitHub events, with a built-in library of [commands](https://prow.k8s.io/command-help), [plugins](https://prow.k8s.io/plugins), and utilities. We built Prow on top of Kubernetes to free ourselves from worrying about resource management and scheduling, and ensure a more pleasant operational experience.
+
+Prow lets us do things like:
+
+* Allow our community to triage issues/PRs by commenting commands such as “/priority critical-urgent”, “/assign mary” or “/close”
+* Auto-label PRs based on how much code they change, or which files they touch
+* Age out issues/PRs that have remained inactive for too long
+* Auto-merge PRs that meet our PR workflow requirements
+* Run CI jobs defined as [Knative Builds](https://github.com/knative/build), Kubernetes Pods, or Jenkins jobs
+* Enforce org-wide and per-repo GitHub policies like [branch protection](https://github.com/kubernetes/test-infra/tree/master/prow/cmd/branchprotector) and [GitHub labels](https://github.com/kubernetes/test-infra/tree/master/label_sync)
+
+Prow was initially developed by the engineering productivity team building Google Kubernetes Engine, and is actively contributed to by multiple members of Kubernetes SIG Testing. Prow has been adopted by several other open source projects, including Istio, JetStack, Knative and OpenShift. [Getting started with Prow](https://github.com/kubernetes/test-infra/blob/master/prow/getting_started.md) takes a Kubernetes cluster and `kubectl apply starter.yaml` (running pods on a Kubernetes cluster).
+
+Once we had Prow in place, we began to hit other scaling bottlenecks, and so produced additional tooling to support testing at the scale required by Kubernetes, including:
+
+- [Boskos](https://github.com/kubernetes/test-infra/tree/master/boskos): manages job resources (such as GCP projects) in pools, checking them out for jobs and cleaning them up automatically ([with monitoring](http://velodrome.k8s.io/dashboard/db/boskos-dashboard?orgId=1))
+- [ghProxy](https://github.com/kubernetes/test-infra/tree/master/ghproxy): a reverse proxy HTTP cache optimized for use with the GitHub API, to ensure our token usage doesn’t hit API limits ([with monitoring](http://velodrome.k8s.io/dashboard/db/github-cache?refresh=1m&orgId=1))
+- [Greenhouse](https://github.com/kubernetes/test-infra/tree/master/greenhouse): allows us to use a remote bazel cache to provide faster build and test results for PRs ([with monitoring](http://velodrome.k8s.io/dashboard/db/bazel-cache?orgId=1))
+- [Splice](https://github.com/kubernetes/test-infra/tree/master/prow/cmd/splice): allows us to test and merge PRs in a batch, ensuring our merge velocity is not limited to our test velocity
+- [Tide](https://github.com/kubernetes/test-infra/tree/master/prow/cmd/tide): allows us to merge PRs selected via GitHub queries rather than ordered in a queue, allowing for significantly higher merge velocity in tandem with splice
+
+## Scaling Project Health
+
+With workflow automation addressed, we turned our attention to project health. We chose to use Google Cloud Storage (GCS) as our source of truth for all test data, allowing us to lean on established infrastructure, and allowed the community to contribute results. We then built a variety of tools to help individuals and the project as a whole make sense of this data, including:
+
+* [Gubernator](https://github.com/kubernetes/test-infra/tree/master/gubernator): display the results and test history for a given PR
+* [Kettle](https://github.com/kubernetes/test-infra/tree/master/kettle): transfer data from GCS to a publicly accessible bigquery dataset
+* [PR dashboard](https://k8s-gubernator.appspot.com/pr): a workflow-aware dashboard that allows contributors to understand which PRs require attention and why
+* [Triage](https://storage.googleapis.com/k8s-gubernator/triage/index.html): identify common failures that happen across all jobs and tests
+* [Testgrid](https://k8s-testgrid.appspot.com/): display test results for a given job across all runs, summarize test results across groups of jobs
+
+We approached the Cloud Native Computing Foundation (CNCF) to develop DevStats to glean insights from our GitHub events such as:
+
+* [Which prow commands are people most actively using](https://k8s.devstats.cncf.io/d/5/bot-commands-repository-groups?orgId=1)
+* [PR reviews by contributor over time](https://k8s.devstats.cncf.io/d/46/pr-reviews-by-contributor?orgId=1&var-period=d7&var-repo_name=All&var-reviewers=All)
+* [Time spent in each phase of our PR workflow](https://k8s.devstats.cncf.io/d/44/pr-time-to-approve-and-merge?orgId=1)
+
+## Into the Beyond
+
+Today, the Kubernetes project spans over 125 repos across five orgs. There are 31 Special Interests Groups and 10 Working Groups coordinating development within the project. In the last year the project has had [participation from over 13,800 unique developers](https://k8s.devstats.cncf.io/d/13/developer-activity-counts-by-repository-group?orgId=1&var-period_name=Last%20year&var-metric=contributions&var-repogroup_name=All) on GitHub.
+
+On any given weekday our Prow instance [runs over 10,000 CI jobs](http://velodrome.k8s.io/dashboard/db/bigquery-metrics?panelId=10&fullscreen&orgId=1&from=now-6M&to=now); from March 2017 to March 2018 it ran 4.3 million jobs. Most of these jobs involve standing up an entire Kubernetes cluster, and exercising it using real world scenarios. They allow us to ensure all supported releases of Kubernetes work across cloud providers, container engines, and networking plugins. They make sure the latest releases of Kubernetes work with various optional features enabled, upgrade safely, meet performance requirements, and work across architectures.
+
+With today’s [announcement from CNCF](https://www.cncf.io/announcement/2018/08/29/cncf-receives-9-million-cloud-credit-grant-from-google) – noting that Google Cloud has begun transferring ownership and management of the Kubernetes project’s cloud resources to CNCF community contributors, we are excited to embark on another journey. One that allows the project infrastructure to be owned and operated by the community of contributors, following the same open governance model that has worked for the rest of the project. Sound exciting to you? Come talk to us at #sig-testing on kubernetes.slack.com.
+
+Want to find out more? Come check out these resources:
+
+* [Prow: Testing the way to Kubernetes Next](https://bentheelder.io/posts/prow)
+* [Automation and the Kubernetes Contributor Experience](https://www.youtube.com/watch?v=BsIC7gPkH5M)
diff --git a/content/en/case-studies/_index.html b/content/en/case-studies/_index.html
index ff6696ac21..2047697592 100644
--- a/content/en/case-studies/_index.html
+++ b/content/en/case-studies/_index.html
@@ -7,155 +7,3 @@ class: gridPage
cid: caseStudies
---
-
-
-
-
-
-
-
-
"I would almost be so bold as to say that most of these applications that we are building now would not have been possible without the cloud native patterns and the flexibility that Kubernetes enables."
"The big cloud native promise to our business is the ability to go from idea to production within 48 hours. We are some years away from this, but that’s quite feasible to us."
"We are in the position to run things at scale, in a public cloud environment, and test things out in way that a lot of people might not be able to do."
"We’re already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure. But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online."
"Kubernetes has the opportunity to be the new cloud platform. The amount of innovation that's going to come from being able to standardize on Kubernetes as a platform is incredibly exciting - more exciting than anything I've seen in the last 10 years of working on the cloud."
diff --git a/content/en/case-studies/adform/adform_featured_logo.png b/content/en/case-studies/adform/adform_featured_logo.png
new file mode 100644
index 0000000000..7e3be727e3
Binary files /dev/null and b/content/en/case-studies/adform/adform_featured_logo.png differ
diff --git a/content/en/case-studies/adform/index.html b/content/en/case-studies/adform/index.html
new file mode 100644
index 0000000000..5a5339d7f1
--- /dev/null
+++ b/content/en/case-studies/adform/index.html
@@ -0,0 +1,118 @@
+---
+title: Adform Case Study
+linkTitle: Adform
+case_study_styles: true
+cid: caseStudies
+css: /css/style_case_studies.css
+logo: adform_featured_logo.png
+draft: true
+featured: true
+weight: 1
+quote: >
+ Kubernetes enabled the self-healing and immutable infrastructure. We can do faster releases, so our developers are really happy. They can ship our features faster than before, and that makes our clients happier.
+---
+
+
+
CASE STUDY:
Improving Performance and Morale with Cloud Native
+
+
+
+
+
+
+ Company AdForm Location Copenhagen, Denmark Industry Adtech
+
+
+
+
+
+
+
Challenge
+ Adform’s mission is to provide a secure and transparent full stack of advertising technology to enable digital ads across devices. The company has a large infrastructure: OpenStack-based private clouds running on 1,100 physical servers in 7 data centers around the world, 3 of which were opened in the past year. With the company’s growth, the infrastructure team felt that "our private cloud was not really flexible enough," says IT System Engineer Edgaras Apšega. "The biggest pain point is that our developers need to maintain their virtual machines, so rolling out technology and new software takes time. We were really struggling with our releases, and we didn’t have self-healing infrastructure."
+
+
+
+
+
Solution
+ The team, which had already been using Prometheus for monitoring, embraced Kubernetes and cloud native practices in 2017. "To start our Kubernetes journey, we had to adapt all our software, so we had to choose newer frameworks," says Apšega. "We also adopted the microservices way, so observability is much better because you can inspect the bug or the services separately."
+
+
+
+
+
+
+
Impact
+ "Kubernetes helps our business a lot because our features are coming to market faster," says Apšega. The release process went from several hours to several minutes. Autoscaling has been at least 6 times faster than the semi-manual VM bootstrapping and application deployment required before. The team estimates that the company has experienced cost savings of 4-5x due to less hardware and fewer man hours needed to set up the hardware and virtual machines, metrics, and logging. Utilization of the hardware resources has been reduced as well, with containers notching 2-3 times more efficiency over virtual machines. "The deployments are very easy because developers just push the code and it automatically appears on Kubernetes," says Apšega. Prometheus has also had a positive impact: "It provides high availability for metrics and alerting. We monitor everything starting from hardware to applications. Having all the metrics in Grafana dashboards provides great insight on your systems."
+
+
+
+
+
+
+
+
+"Kubernetes enabled the self-healing and immutable infrastructure. We can do faster releases, so our developers are really happy. They can ship our features faster than before, and that makes our clients happier."
— Edgaras Apšega, IT Systems Engineer, Adform
+
+
+
+
+
+
+
+
Adform made headlines last year when it detected the HyphBot ad fraud network that was costing some businesses hundreds of thousands of dollars a day.
With its mission to provide a secure and transparent full stack of advertising technology to enable an open internet, Adform published a white paper revealing what it did—and others could too—to limit customers’ exposure to the scam.
+In that same spirit, Adform is sharing its cloud native journey. "When you see that everyone shares their best practices, it inspires you to contribute back to the project," says IT Systems Engineer Edgaras Apšega.
+The company has a large infrastructure: OpenStack-based private clouds running on 1,100 physical servers in their own seven data centers around the world, three of which were opened in the past year. With the company’s growth, the infrastructure team felt that "our private cloud was not really flexible enough," says Apšega. "The biggest pain point is that our developers need to maintain their virtual machines, so rolling out technology and new software really takes time. We were really struggling with our releases, and we didn’t have self-healing infrastructure."
+
+
+
+
+
+
+ "The fact that Cloud Native Computing Foundation incubated Kubernetes was a really big point for us because it was vendor neutral. And we can see that a community really gathers around it. Everyone shares their experiences, their knowledge, and the fact that it’s open source, you can contribute."
— Edgaras Apšega, IT Systems Engineer, Adform
+
+
+
+
+
+The team, which had already been using Prometheus for monitoring, embraced Kubernetes, microservices, and cloud native practices. "The fact that Cloud Native Computing Foundation incubated Kubernetes was a really big point for us because it was vendor neutral," says Apšega. "And we can see that a community really gathers around it."
+A proof of concept project was started, with a Kubernetes cluster running on bare metal in the data center. When developers saw how quickly containers could be spun up compared to the virtual machine process, "they wanted to ship their containers in production right away, and we were still doing proof of concept," says IT Systems Engineer Andrius Cibulskis.
+Of course, a lot of work still had to be done. "First of all, we had to learn Kubernetes, see all of the moving parts, how they glue together," says Apšega. "Second of all, the whole CI/CD part had to be redone, and our DevOps team had to invest more man hours to implement it. And third is that developers had to rewrite the code, and they’re still doing it."
+
+The first production cluster was launched in the spring of 2018, and is now up to 20 physical machines dedicated for pods throughout three data centers, with plans for separate clusters in the other four data centers. The user-facing Adform application platform, data distribution platform, and back ends are now all running on Kubernetes. "Many APIs for critical applications are being developed for Kubernetes," says Apšega. "Teams are rewriting their applications to .NET core, because it supports containers, and preparing to move to Kubernetes. And new applications, by default, go in containers."
+
+
+
+
+
+
+"Releases are really nice for them, because they just push their code to Git and that’s it. They don’t have to worry about their virtual machines anymore."
— Andrius Cibulskis, IT Systems Engineer, Adform
+
+
+
+
+
+This big push has been driven by the real impact that these new practices have had. "Kubernetes helps our business a lot because our features are coming to market faster," says Apšega. "The deployments are very easy because developers just push the code and it automatically appears on Kubernetes." The release process went from several hours to several minutes. Autoscaling is at least six times faster than the semi-manual VM bootstrapping and application deployment required before.
+The team estimates that the company has experienced cost savings of 4-5x due to less hardware and fewer man hours needed to set up the hardware and virtual machines, metrics, and logging. Utilization of the hardware resources has been reduced as well, with containers notching two to three times more efficiency over virtual machines.
+Prometheus has also had a positive impact: "It provides high availability for metrics and alerting," says Apšega. "We monitor everything starting from hardware to applications. Having all the metrics in Grafana dashboards provides great insight on our systems."
+
+
+
+
+
+
+
+ "I think that our company just started our cloud native journey. It seems like a huge road ahead, but we’re really happy that we joined it."
— Edgaras Apšega, IT Systems Engineer, Adform
+
+
+
+
+All of these benefits have trickled down to individual team members, whose working lives have been changed for the better. "They used to have to get up at night to re-start some services, and now Kubernetes handles all of that," says Apšega. Adds Cibulskis: "Releases are really nice for them, because they just push their code to Git and that’s it. They don’t have to worry about their virtual machines anymore." Even the security teams have been impacted. "Security teams are always not happy," says Apšega, "and now they’re happy because they can easily inspect the containers."
+The company plans to remain in the data centers for now, "mostly because we want to keep all the data, to not share it in any way," says Cibulskis, "and it’s cheaper at our scale." But, Apšega says, the possibility of using a hybrid cloud for computing is intriguing: "One of the projects we’re interested in is the Virtual Kubelet that lets you spin up the working nodes on different clouds to do some computing."
+
+Apšega, Cibulskis and their colleagues are keeping tabs on how the cloud native ecosystem develops, and are excited to contribute where they can. "I think that our company just started our cloud native journey," says Apšega. "It seems like a huge road ahead, but we’re really happy that we joined it."
+
+
+
+
+
+
diff --git a/static/images/case_studies/amadeus_feature.png b/content/en/case-studies/amadeus/amadeus_featured.png
similarity index 100%
rename from static/images/case_studies/amadeus_feature.png
rename to content/en/case-studies/amadeus/amadeus_featured.png
diff --git a/static/images/case_studies/amadeus.png b/content/en/case-studies/amadeus/amadeus_logo.png
similarity index 100%
rename from static/images/case_studies/amadeus.png
rename to content/en/case-studies/amadeus/amadeus_logo.png
diff --git a/content/en/case-studies/amadeus.html b/content/en/case-studies/amadeus/index.html
similarity index 100%
rename from content/en/case-studies/amadeus.html
rename to content/en/case-studies/amadeus/index.html
diff --git a/static/images/case_studies/ancestry-logo.png b/content/en/case-studies/ancestry/ancestry_featured.png
similarity index 100%
rename from static/images/case_studies/ancestry-logo.png
rename to content/en/case-studies/ancestry/ancestry_featured.png
diff --git a/static/images/case_studies/ancestry.png b/content/en/case-studies/ancestry/ancestry_logo.png
similarity index 100%
rename from static/images/case_studies/ancestry.png
rename to content/en/case-studies/ancestry/ancestry_logo.png
diff --git a/content/en/case-studies/ancestry.html b/content/en/case-studies/ancestry/index.html
similarity index 100%
rename from content/en/case-studies/ancestry.html
rename to content/en/case-studies/ancestry/index.html
diff --git a/static/images/case_studies/blablacar-logo.png b/content/en/case-studies/blablacar/blablacar_featured.png
similarity index 100%
rename from static/images/case_studies/blablacar-logo.png
rename to content/en/case-studies/blablacar/blablacar_featured.png
diff --git a/static/images/case_studies/blablacar.png b/content/en/case-studies/blablacar/blablacar_logo.png
similarity index 100%
rename from static/images/case_studies/blablacar.png
rename to content/en/case-studies/blablacar/blablacar_logo.png
diff --git a/content/en/case-studies/blablacar.html b/content/en/case-studies/blablacar/index.html
similarity index 100%
rename from content/en/case-studies/blablacar.html
rename to content/en/case-studies/blablacar/index.html
diff --git a/static/images/case_studies/blackrock.png b/content/en/case-studies/blackrock/blackrock_featured.png
similarity index 100%
rename from static/images/case_studies/blackrock.png
rename to content/en/case-studies/blackrock/blackrock_featured.png
diff --git a/static/images/case_studies/blackrock2.png b/content/en/case-studies/blackrock/blackrock_logo.png
similarity index 100%
rename from static/images/case_studies/blackrock2.png
rename to content/en/case-studies/blackrock/blackrock_logo.png
diff --git a/content/en/case-studies/blackrock.html b/content/en/case-studies/blackrock/index.html
similarity index 100%
rename from content/en/case-studies/blackrock.html
rename to content/en/case-studies/blackrock/index.html
diff --git a/static/images/case_studies/box.png b/content/en/case-studies/box/box_featured.png
similarity index 100%
rename from static/images/case_studies/box.png
rename to content/en/case-studies/box/box_featured.png
diff --git a/static/images/case_studies/box_logo.png b/content/en/case-studies/box/box_logo.png
similarity index 100%
rename from static/images/case_studies/box_logo.png
rename to content/en/case-studies/box/box_logo.png
diff --git a/static/images/case_studies/box-small.png b/content/en/case-studies/box/box_small.png
similarity index 100%
rename from static/images/case_studies/box-small.png
rename to content/en/case-studies/box/box_small.png
diff --git a/content/en/case-studies/box.html b/content/en/case-studies/box/index.html
similarity index 97%
rename from content/en/case-studies/box.html
rename to content/en/case-studies/box/index.html
index 7392557462..bead8eb01a 100644
--- a/content/en/case-studies/box.html
+++ b/content/en/case-studies/box/index.html
@@ -1,9 +1,12 @@
---
title: Box Case Study
-
case_study_styles: true
cid: caseStudies
css: /css/style_box.css
+video: https://www.youtube.com/embed/of45hYbkIZs?autoplay=1
+quote: >
+ Kubernetes has the opportunity to be the new cloud platform. The amount of innovation that's going to come from being able to standardize on Kubernetes as a platform is incredibly exciting - more exciting than anything I've seen in the last 10 years of working on the cloud.
+
---
diff --git a/static/images/case_studies/Video-Clip-Box.png b/content/en/case-studies/box/video.png
similarity index 100%
rename from static/images/case_studies/Video-Clip-Box.png
rename to content/en/case-studies/box/video.png
diff --git a/static/images/case_studies/buffer.png b/content/en/case-studies/buffer/buffer_featured.png
similarity index 100%
rename from static/images/case_studies/buffer.png
rename to content/en/case-studies/buffer/buffer_featured.png
diff --git a/static/images/case_studies/buffer_logo.png b/content/en/case-studies/buffer/buffer_logo.png
similarity index 100%
rename from static/images/case_studies/buffer_logo.png
rename to content/en/case-studies/buffer/buffer_logo.png
diff --git a/content/en/case-studies/buffer.html b/content/en/case-studies/buffer/index.html
similarity index 100%
rename from content/en/case-studies/buffer.html
rename to content/en/case-studies/buffer/index.html
diff --git a/static/images/case_studies/capitalone_feature.png b/content/en/case-studies/capital-one/capitalone_featured_logo.png
similarity index 100%
rename from static/images/case_studies/capitalone_feature.png
rename to content/en/case-studies/capital-one/capitalone_featured_logo.png
diff --git a/content/en/case-studies/capital-one.html b/content/en/case-studies/capital-one/index.html
similarity index 100%
rename from content/en/case-studies/capital-one.html
rename to content/en/case-studies/capital-one/index.html
diff --git a/static/images/case_studies/ccp.png b/content/en/case-studies/ccp-games/ccp_logo.png
similarity index 100%
rename from static/images/case_studies/ccp.png
rename to content/en/case-studies/ccp-games/ccp_logo.png
diff --git a/content/en/case-studies/ccp-games/index.html b/content/en/case-studies/ccp-games/index.html
new file mode 100644
index 0000000000..8867cbb323
--- /dev/null
+++ b/content/en/case-studies/ccp-games/index.html
@@ -0,0 +1,4 @@
+---
+title: CCP Games
+content_url: https://cloud.google.com/customers/ccp-games/
+---
\ No newline at end of file
diff --git a/static/images/case_studies/comcast_logo.png b/content/en/case-studies/comcast/comcast_logo.png
similarity index 100%
rename from static/images/case_studies/comcast_logo.png
rename to content/en/case-studies/comcast/comcast_logo.png
diff --git a/content/en/case-studies/comcast/index.html b/content/en/case-studies/comcast/index.html
new file mode 100644
index 0000000000..7ace6a246d
--- /dev/null
+++ b/content/en/case-studies/comcast/index.html
@@ -0,0 +1,4 @@
+---
+title: Comcast
+content_url: https://youtu.be/lmeFkH-rHII
+---
\ No newline at end of file
diff --git a/static/images/case_studies/concur.png b/content/en/case-studies/concur/concur_featured_logo.png
similarity index 100%
rename from static/images/case_studies/concur.png
rename to content/en/case-studies/concur/concur_featured_logo.png
diff --git a/content/en/case-studies/concur/index.html b/content/en/case-studies/concur/index.html
new file mode 100644
index 0000000000..0bb619f527
--- /dev/null
+++ b/content/en/case-studies/concur/index.html
@@ -0,0 +1,4 @@
+---
+title: Concur
+content_url: http://searchitoperations.techtarget.com/news/450297178/Tech-firms-roll-out-Kubernetes-in-production
+---
\ No newline at end of file
diff --git a/static/images/case_studies/crowdfire_feature.png b/content/en/case-studies/crowdfire/crowdfire_featured_logo.png
similarity index 100%
rename from static/images/case_studies/crowdfire_feature.png
rename to content/en/case-studies/crowdfire/crowdfire_featured_logo.png
diff --git a/content/en/case-studies/crowdfire.html b/content/en/case-studies/crowdfire/index.html
similarity index 100%
rename from content/en/case-studies/crowdfire.html
rename to content/en/case-studies/crowdfire/index.html
diff --git a/static/images/case_studies/ebay.png b/content/en/case-studies/ebay/ebay_featured.png
similarity index 100%
rename from static/images/case_studies/ebay.png
rename to content/en/case-studies/ebay/ebay_featured.png
diff --git a/static/images/case_studies/ebay_logo.png b/content/en/case-studies/ebay/ebay_logo.png
similarity index 100%
rename from static/images/case_studies/ebay_logo.png
rename to content/en/case-studies/ebay/ebay_logo.png
diff --git a/content/en/case-studies/ebay/index.html b/content/en/case-studies/ebay/index.html
new file mode 100644
index 0000000000..e0bf4f6e97
--- /dev/null
+++ b/content/en/case-studies/ebay/index.html
@@ -0,0 +1,4 @@
+---
+title: Ebay
+content_url: http://www.nextplatform.com/2015/11/12/inside-ebays-shift-to-kubernetes-and-containers-atop-openstack/
+---
\ No newline at end of file
diff --git a/static/images/case_studies/gs.png b/content/en/case-studies/goldman-sachs/gs_logo.png
similarity index 100%
rename from static/images/case_studies/gs.png
rename to content/en/case-studies/goldman-sachs/gs_logo.png
diff --git a/content/en/case-studies/goldman-sachs/index.html b/content/en/case-studies/goldman-sachs/index.html
new file mode 100644
index 0000000000..93d3022d12
--- /dev/null
+++ b/content/en/case-studies/goldman-sachs/index.html
@@ -0,0 +1,4 @@
+---
+title: Goldman Sachs
+content_url: http://blogs.wsj.com/cio/2016/02/24/big-changes-in-goldmans-software-emerge-from-small-containers/
+---
\ No newline at end of file
diff --git a/static/images/case_studies/golfnow.png b/content/en/case-studies/golfnow/golfnow_featured.png
similarity index 100%
rename from static/images/case_studies/golfnow.png
rename to content/en/case-studies/golfnow/golfnow_featured.png
diff --git a/static/images/case_studies/golfnow_logo.png b/content/en/case-studies/golfnow/golfnow_logo.png
similarity index 100%
rename from static/images/case_studies/golfnow_logo.png
rename to content/en/case-studies/golfnow/golfnow_logo.png
diff --git a/content/en/case-studies/golfnow.html b/content/en/case-studies/golfnow/index.html
similarity index 100%
rename from content/en/case-studies/golfnow.html
rename to content/en/case-studies/golfnow/index.html
diff --git a/static/images/case_studies/haufegroup_logo_feature.png b/content/en/case-studies/haufegroup/haufegroup_featured.png
similarity index 100%
rename from static/images/case_studies/haufegroup_logo_feature.png
rename to content/en/case-studies/haufegroup/haufegroup_featured.png
diff --git a/static/images/case_studies/haufegroup_logo.png b/content/en/case-studies/haufegroup/haufegroup_logo.png
similarity index 100%
rename from static/images/case_studies/haufegroup_logo.png
rename to content/en/case-studies/haufegroup/haufegroup_logo.png
diff --git a/content/en/case-studies/haufegroup.html b/content/en/case-studies/haufegroup/index.html
similarity index 100%
rename from content/en/case-studies/haufegroup.html
rename to content/en/case-studies/haufegroup/index.html
diff --git a/static/images/case_studies/homeoffice.png b/content/en/case-studies/homeoffice/homeoffice_logo.png
similarity index 100%
rename from static/images/case_studies/homeoffice.png
rename to content/en/case-studies/homeoffice/homeoffice_logo.png
diff --git a/content/en/case-studies/homeoffice/index.html b/content/en/case-studies/homeoffice/index.html
new file mode 100644
index 0000000000..a768a6dd04
--- /dev/null
+++ b/content/en/case-studies/homeoffice/index.html
@@ -0,0 +1,4 @@
+---
+title: UK Home Office
+content_url: https://www.youtube.com/watch?v=F3iMkz_NSvU
+---
\ No newline at end of file
diff --git a/static/images/case_studies/huawei_feature.png b/content/en/case-studies/huawei/huawei_featured.png
similarity index 100%
rename from static/images/case_studies/huawei_feature.png
rename to content/en/case-studies/huawei/huawei_featured.png
diff --git a/static/images/case_studies/huawei.png b/content/en/case-studies/huawei/huawei_logo.png
similarity index 100%
rename from static/images/case_studies/huawei.png
rename to content/en/case-studies/huawei/huawei_logo.png
diff --git a/content/en/case-studies/huawei.html b/content/en/case-studies/huawei/index.html
similarity index 100%
rename from content/en/case-studies/huawei.html
rename to content/en/case-studies/huawei/index.html
diff --git a/content/en/case-studies/ing.html b/content/en/case-studies/ing/index.html
similarity index 97%
rename from content/en/case-studies/ing.html
rename to content/en/case-studies/ing/index.html
index 78efb71056..6f3c38dd48 100644
--- a/content/en/case-studies/ing.html
+++ b/content/en/case-studies/ing/index.html
@@ -1,8 +1,13 @@
---
title: ING Case Study
+linkTitle: ING
case_study_styles: true
cid: caseStudies
+weight: 20
+featured: true
css: /css/style_case_studies.css
+quote: >
+ The big cloud native promise to our business is the ability to go from idea to production within 48 hours. We are some years away from this, but that’s quite feasible to us.
---
diff --git a/static/images/case_studies/ing_feature.png b/content/en/case-studies/ing/ing_featured_logo.png
similarity index 100%
rename from static/images/case_studies/ing_feature.png
rename to content/en/case-studies/ing/ing_featured_logo.png
diff --git a/content/en/case-studies/jd/index.html b/content/en/case-studies/jd/index.html
new file mode 100644
index 0000000000..ee61da9d14
--- /dev/null
+++ b/content/en/case-studies/jd/index.html
@@ -0,0 +1,4 @@
+---
+title: JD.COM
+content_url: https://kubernetes.io/blog/2017/02/inside-jd-com-shift-to-kubernetes-from-openstack
+---
\ No newline at end of file
diff --git a/static/images/case_studies/jd.png b/content/en/case-studies/jd/jd_logo.png
similarity index 100%
rename from static/images/case_studies/jd.png
rename to content/en/case-studies/jd/jd_logo.png
diff --git a/content/en/case-studies/liveperson/index.html b/content/en/case-studies/liveperson/index.html
new file mode 100644
index 0000000000..0cadb0f274
--- /dev/null
+++ b/content/en/case-studies/liveperson/index.html
@@ -0,0 +1,4 @@
+---
+title: LivePerson
+content_url: https://www.openstack.org/videos/video/running-kubernetes-on-openstack-at-liveperson
+---
\ No newline at end of file
diff --git a/static/images/case_studies/liveperson.png b/content/en/case-studies/liveperson/liveperson_logo.png
similarity index 100%
rename from static/images/case_studies/liveperson.png
rename to content/en/case-studies/liveperson/liveperson_logo.png
diff --git a/content/en/case-studies/monzo/index.html b/content/en/case-studies/monzo/index.html
new file mode 100644
index 0000000000..99d4f35934
--- /dev/null
+++ b/content/en/case-studies/monzo/index.html
@@ -0,0 +1,4 @@
+---
+title: Monzo
+content_url: https://youtu.be/YkOY7DgXKyw
+---
\ No newline at end of file
diff --git a/static/images/case_studies/monzo_logo.png b/content/en/case-studies/monzo/monzo_logo.png
similarity index 100%
rename from static/images/case_studies/monzo_logo.png
rename to content/en/case-studies/monzo/monzo_logo.png
diff --git a/content/en/case-studies/newyorktimes.html b/content/en/case-studies/newyorktimes/index.html
similarity index 100%
rename from content/en/case-studies/newyorktimes.html
rename to content/en/case-studies/newyorktimes/index.html
diff --git a/static/images/case_studies/nyt.png b/content/en/case-studies/newyorktimes/newyorktimes_featured.png
similarity index 100%
rename from static/images/case_studies/nyt.png
rename to content/en/case-studies/newyorktimes/newyorktimes_featured.png
diff --git a/static/images/case_studies/newyorktimes_feature.png b/content/en/case-studies/newyorktimes/newyorktimes_logo.png
similarity index 100%
rename from static/images/case_studies/newyorktimes_feature.png
rename to content/en/case-studies/newyorktimes/newyorktimes_logo.png
diff --git a/content/en/case-studies/nordstrom.html b/content/en/case-studies/nordstrom/index.html
similarity index 100%
rename from content/en/case-studies/nordstrom.html
rename to content/en/case-studies/nordstrom/index.html
diff --git a/static/images/case_studies/nordstrom_feature.png b/content/en/case-studies/nordstrom/nordstrom_featured_logo.png
similarity index 100%
rename from static/images/case_studies/nordstrom_feature.png
rename to content/en/case-studies/nordstrom/nordstrom_featured_logo.png
diff --git a/content/en/case-studies/northwestern-mutual.html b/content/en/case-studies/northwestern-mutual/index.html
similarity index 100%
rename from content/en/case-studies/northwestern-mutual.html
rename to content/en/case-studies/northwestern-mutual/index.html
diff --git a/static/images/case_studies/northwestern_feature.png b/content/en/case-studies/northwestern-mutual/northwestern_featured_logo.png
similarity index 100%
rename from static/images/case_studies/northwestern_feature.png
rename to content/en/case-studies/northwestern-mutual/northwestern_featured_logo.png
diff --git a/content/en/case-studies/openAI.html b/content/en/case-studies/openAI/index.html
similarity index 100%
rename from content/en/case-studies/openAI.html
rename to content/en/case-studies/openAI/index.html
diff --git a/static/images/case_studies/openai_feature.png b/content/en/case-studies/openAI/openai_featured.png
similarity index 100%
rename from static/images/case_studies/openai_feature.png
rename to content/en/case-studies/openAI/openai_featured.png
diff --git a/static/images/case_studies/openai.png b/content/en/case-studies/openAI/openai_logo.png
similarity index 100%
rename from static/images/case_studies/openai.png
rename to content/en/case-studies/openAI/openai_logo.png
diff --git a/content/en/case-studies/peardeck.html b/content/en/case-studies/peardeck/index.html
similarity index 100%
rename from content/en/case-studies/peardeck.html
rename to content/en/case-studies/peardeck/index.html
diff --git a/static/images/case_studies/peardeck.png b/content/en/case-studies/peardeck/peardeck_featured.png
similarity index 100%
rename from static/images/case_studies/peardeck.png
rename to content/en/case-studies/peardeck/peardeck_featured.png
diff --git a/static/images/case_studies/peardeck_logo.png b/content/en/case-studies/peardeck/peardeck_logo.png
similarity index 100%
rename from static/images/case_studies/peardeck_logo.png
rename to content/en/case-studies/peardeck/peardeck_logo.png
diff --git a/content/en/case-studies/pearson.html b/content/en/case-studies/pearson.html
deleted file mode 100644
index c56c1778ed..0000000000
--- a/content/en/case-studies/pearson.html
+++ /dev/null
@@ -1,104 +0,0 @@
----
-title: Pearson Case Study
-case_study_styles: true
-cid: caseStudies
-css: /css/style_case_studies.css
----
-
-
-
-
CASE STUDY:
Reinventing the World’s Largest Education Company With Kubernetes
-
-
-
-
-
-
-
- Company Pearson Location Global
- Industry Education
-
-
-
-
-
-
-
Challenge
- A global education company serving 75 million learners, Pearson set a goal to more than double that number, to 200 million, by 2025. A key part of this growth is in digital learning experiences, and Pearson was having difficulty in scaling and adapting to its growing online audience. They needed an infrastructure platform that would be able to scale quickly and deliver products to market faster.
-
-
-
Solution
- "To transform our infrastructure, we had to think beyond simply enabling automated provisioning," says Chris Jackson, Director for Cloud Platforms & SRE at Pearson. "We realized we had to build a platform that would allow Pearson developers to build, manage and deploy applications in a completely different way." The team chose Docker container technology and Kubernetes orchestration "because of its flexibility, ease of management and the way it would improve our engineers’ productivity."
-
-
-
-
-
-
Impact
- With the platform, there has been substantial improvements in productivity and speed of delivery. "In some cases, we’ve gone from nine months to provision physical assets in a data center to just a few minutes to provision and get a new idea in front of a customer," says John Shirley, Lead Site Reliability Engineer for the Cloud Platform Team. Jackson estimates they’ve achieved 15-20% developer productivity savings. Before, outages were an issue during their busiest time of year, the back-to-school period. Now, there’s high confidence in their ability to meet aggressive customer SLAs.
-
-
-
-
-
-
-
-
-
- "We’re already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure. But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online."
— Chris Jackson, Director for Cloud Platforms & SRE at Pearson
-
-
-
-
- In 2015, Pearson was already serving 75 million learners as the world’s largest education company, offering curriculum and assessment tools for Pre-K through college and beyond. Understanding that innovating the digital education experience was the key to the future of all forms of education, the company set out to increase its reach to 200 million people by 2025.
-That goal would require a transformation of its existing infrastructure, which was in data centers. In some cases, it took nine months to provision physical assets. In order to adapt to the demands of its growing online audience, Pearson needed an infrastructure platform that would be able to scale quickly and deliver business-critical products to market faster. "We had to think beyond simply enabling automated provisioning," says Chris Jackson, Director for Cloud Platforms & SRE at Pearson. "We realized we had to build a platform that would allow Pearson developers to build, manage and deploy applications in a completely different way."
-With 400 development groups and diverse brands with varying business and technical needs, Pearson embraced Docker container technology so that each brand could experiment with building new types of content using their preferred technologies, and then deliver it using containers. Jackson chose Kubernetes orchestration "because of its flexibility, ease of management and the way it would improve our engineers’ productivity," he says.
-The team adopted Kubernetes when it was still version 1.2 and are still going strong now on 1.7; they use Terraform and Ansible to deploy it on to basic AWS primitives. "We were trying to understand how we can create value for Pearson from this technology," says Ben Somogyi, Principal Architect for the Cloud Platforms. "It turned out that Kubernetes’ benefits are huge. We’re trying to help our applications development teams that use our platform go faster, so we filled that gap with a CI/CD pipeline that builds their images for them, standardizes them, patches everything up, allows them to deploy their different environments onto the cluster, and obfuscating the details of how difficult the work underneath the covers is."
-
-
-
-
-
- "Your internal customers need to feel like they are choosing the very best option for them. We are experiencing this first hand in the growth of adoption. We are seeing triple-digit, year-on-year growth of the service."
— Chris Jackson, Director for Cloud Platforms & SRE at Pearson
-
-
-
-
- That work resulted in two tools for building and deploying applications in the cluster that Pearson has open sourced. "We’re an education company, so we want to share what we can," says Somogyi.
-Now that development teams no longer have to worry about infrastructure, there have been substantial improvements in productivity and speed of delivery. "In some cases, we’ve gone from nine months to provision physical assets in a data center to just a few minutes to provision and to get a new idea in front of a customer," says John Shirley, Lead Site Reliability Engineer for the Cloud Platform Team.
-According to Jackson, the Cloud Platforms team can "provision a new proof-of-concept environment for a development team in minutes, and then they can take that to production as quickly as they are able to. This is the value proposition of all major technology services, and we had to compete like one to become our developers’ preferred choice. Just because you work for the same company, you do not have the right to force people into a mediocre service. Your internal customers need to feel like they are choosing the very best option for them. We are experiencing this first hand in the growth of adoption. We are seeing triple-digit, year-on-year growth of the service."
-Jackson estimates they’ve achieved a 15-20% boost in productivity for developer teams who adopt the platform. They also see a reduction in the number of customer-impacting incidents. Plus, says Jackson, "Teams who were previously limited to 1-2 releases per academic year can now ship code multiple times per day!"
-
-
-
-
-
- "Teams who were previously limited to 1-2 releases per academic year can now ship code multiple times per day!"
— Chris Jackson, Director for Cloud Platforms & SRE at Pearson
-
-
-
-
-
- Availability has also been positively impacted. The back-to-school period is the company’s busiest time of year, and "you have to keep applications up," says Somogyi. Before, this was a pain point for the legacy infrastructure. Now, for the applications that have been migrated to the Kubernetes platform, "We have 100% uptime. We’re not worried about 9s. There aren’t any. It’s 100%, which is pretty astonishing for us, compared to some of the existing platforms that have legacy challenges," says Shirley.
-
-"You can’t even begin to put a price on how much that saves the company," Jackson explains. "A reduction in the number of support cases takes load out of our operations. The customer sentiment of having a reliable product drives customer retention and growth. It frees us to think about investing more into our digital transformation and taking a better quality of education to a global scale."
-
-The platform itself is also being broken down, "so we can quickly release smaller pieces of the platform, like upgrading our Kubernetes or all the different modules that make up our platform," says Somogyi. "One of the big focuses in 2018 is this scheme of delivery to update the platform itself."
-
-Guided by Pearson’s overarching goal of getting to 200 million users, the team has run internal tests of the platform’s scalability. "We had a challenge: 28 million requests within a 10 minute period," says Shirley. "And we demonstrated that we can hit that, with an acceptable latency. We saw that we could actually get that pretty readily, and we scaled up in just a few seconds, using open source tools entirely. Shout out to Locustfor that one. So that’s amazing."
-
-
-
-
-
- "We have 100% uptime. We’re not worried about 9s. There aren’t any. It’s 100%, which is pretty astonishing for us, compared to some of the existing platforms that have legacy challenges. You can’t even begin to put a price on how much that saves the company."
— Benjamin Somogyi, Principal Systems Architect at Pearson
-
-
-
- In just two years, "We’re already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure," says Jackson. "But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online."
-So far, about 15 production products are running on the new platform, including Pearson’s new flagship digital education service, the Global Learning Platform. The Cloud Platform team continues to prepare, onboard and support customers that are a good fit for the platform. Some existing products will be refactored into 12-factor apps, while others are being developed so that they can live on the platform from the get-go. "There are challenges with bringing in new customers of course, because we have to help them to see a different way of developing, a different way of building," says Shirley.
-But, he adds, "It is our corporate motto: Always Learning. We encourage those teams that haven’t started a cloud native journey, to see the future of technology, to learn, to explore. It will pique your interest. Keep learning."
-
-
-
-
diff --git a/content/en/case-studies/pearson/index.html b/content/en/case-studies/pearson/index.html
new file mode 100644
index 0000000000..b644c1b676
--- /dev/null
+++ b/content/en/case-studies/pearson/index.html
@@ -0,0 +1,87 @@
+---
+title: Pearson Case Study
+linkTitle: Pearson
+case_study_styles: true
+cid: caseStudies
+css: /css/style_case_studies.css
+featured: true
+quote: >
+ We’re already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure. But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online.
+---
+
+
CASE STUDY:
Reinventing the World’s Largest Education Company With Kubernetes
+
+
+
+ Company Pearson Location Global
+ Industry Education
+
+
+
+
+
+
Challenge
+ A global education company serving 75 million learners, Pearson set a goal to more than double that number, to 200 million, by 2025. A key part of this growth is in digital learning experiences, and Pearson was having difficulty in scaling and adapting to its growing online audience. They needed an infrastructure platform that would be able to scale quickly and deliver products to market faster.
+
+
Solution
+ "To transform our infrastructure, we had to think beyond simply enabling automated provisioning," says Chris Jackson, Director for Cloud Platforms & SRE at Pearson. "We realized we had to build a platform that would allow Pearson developers to build, manage and deploy applications in a completely different way." The team chose Docker container technology and Kubernetes orchestration "because of its flexibility, ease of management and the way it would improve our engineers’ productivity."
+
+
+
+
Impact
+ With the platform, there has been substantial improvements in productivity and speed of delivery. "In some cases, we’ve gone from nine months to provision physical assets in a data center to just a few minutes to provision and get a new idea in front of a customer," says John Shirley, Lead Site Reliability Engineer for the Cloud Platform Team. Jackson estimates they’ve achieved 15-20% developer productivity savings. Before, outages were an issue during their busiest time of year, the back-to-school period. Now, there’s high confidence in their ability to meet aggressive customer SLAs.
+
+
+
+
+
+
+ "We’re already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure. But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online."
— Chris Jackson, Director for Cloud Platforms & SRE at Pearson
+
+
+
+
+ In 2015, Pearson was already serving 75 million learners as the world’s largest education company, offering curriculum and assessment tools for Pre-K through college and beyond. Understanding that innovating the digital education experience was the key to the future of all forms of education, the company set out to increase its reach to 200 million people by 2025.
+ That goal would require a transformation of its existing infrastructure, which was in data centers. In some cases, it took nine months to provision physical assets. In order to adapt to the demands of its growing online audience, Pearson needed an infrastructure platform that would be able to scale quickly and deliver business-critical products to market faster. "We had to think beyond simply enabling automated provisioning," says Chris Jackson, Director for Cloud Platforms & SRE at Pearson. "We realized we had to build a platform that would allow Pearson developers to build, manage and deploy applications in a completely different way."
+ With 400 development groups and diverse brands with varying business and technical needs, Pearson embraced Docker container technology so that each brand could experiment with building new types of content using their preferred technologies, and then deliver it using containers. Jackson chose Kubernetes orchestration "because of its flexibility, ease of management and the way it would improve our engineers’ productivity," he says.
+ The team adopted Kubernetes when it was still version 1.2 and are still going strong now on 1.7; they use Terraform and Ansible to deploy it on to basic AWS primitives. "We were trying to understand how we can create value for Pearson from this technology," says Ben Somogyi, Principal Architect for the Cloud Platforms. "It turned out that Kubernetes’ benefits are huge. We’re trying to help our applications development teams that use our platform go faster, so we filled that gap with a CI/CD pipeline that builds their images for them, standardizes them, patches everything up, allows them to deploy their different environments onto the cluster, and obfuscating the details of how difficult the work underneath the covers is."
+
+
+
+
+ "Your internal customers need to feel like they are choosing the very best option for them. We are experiencing this first hand in the growth of adoption. We are seeing triple-digit, year-on-year growth of the service."
— Chris Jackson, Director for Cloud Platforms & SRE at Pearson
+
+
+
+
+ That work resulted in two tools for building and deploying applications in the cluster that Pearson has open sourced. "We’re an education company, so we want to share what we can," says Somogyi.
+ Now that development teams no longer have to worry about infrastructure, there have been substantial improvements in productivity and speed of delivery. "In some cases, we’ve gone from nine months to provision physical assets in a data center to just a few minutes to provision and to get a new idea in front of a customer," says John Shirley, Lead Site Reliability Engineer for the Cloud Platform Team.
+ According to Jackson, the Cloud Platforms team can "provision a new proof-of-concept environment for a development team in minutes, and then they can take that to production as quickly as they are able to. This is the value proposition of all major technology services, and we had to compete like one to become our developers’ preferred choice. Just because you work for the same company, you do not have the right to force people into a mediocre service. Your internal customers need to feel like they are choosing the very best option for them. We are experiencing this first hand in the growth of adoption. We are seeing triple-digit, year-on-year growth of the service."
+ Jackson estimates they’ve achieved a 15-20% boost in productivity for developer teams who adopt the platform. They also see a reduction in the number of customer-impacting incidents. Plus, says Jackson, "Teams who were previously limited to 1-2 releases per academic year can now ship code multiple times per day!"
+
+
+
+
+ "Teams who were previously limited to 1-2 releases per academic year can now ship code multiple times per day!"
— Chris Jackson, Director for Cloud Platforms & SRE at Pearson
+
+
+
+
+ Availability has also been positively impacted. The back-to-school period is the company’s busiest time of year, and "you have to keep applications up," says Somogyi. Before, this was a pain point for the legacy infrastructure. Now, for the applications that have been migrated to the Kubernetes platform, "We have 100% uptime. We’re not worried about 9s. There aren’t any. It’s 100%, which is pretty astonishing for us, compared to some of the existing platforms that have legacy challenges," says Shirley.
+
+ "You can’t even begin to put a price on how much that saves the company," Jackson explains. "A reduction in the number of support cases takes load out of our operations. The customer sentiment of having a reliable product drives customer retention and growth. It frees us to think about investing more into our digital transformation and taking a better quality of education to a global scale."
+
+ The platform itself is also being broken down, "so we can quickly release smaller pieces of the platform, like upgrading our Kubernetes or all the different modules that make up our platform," says Somogyi. "One of the big focuses in 2018 is this scheme of delivery to update the platform itself."
+
+ Guided by Pearson’s overarching goal of getting to 200 million users, the team has run internal tests of the platform’s scalability. "We had a challenge: 28 million requests within a 10 minute period," says Shirley. "And we demonstrated that we can hit that, with an acceptable latency. We saw that we could actually get that pretty readily, and we scaled up in just a few seconds, using open source tools entirely. Shout out to Locustfor that one. So that’s amazing."
+
+
+
+ "We have 100% uptime. We’re not worried about 9s. There aren’t any. It’s 100%, which is pretty astonishing for us, compared to some of the existing platforms that have legacy challenges. You can’t even begin to put a price on how much that saves the company."
— Benjamin Somogyi, Principal Systems Architect at Pearson
+
+
+ In just two years, "We’re already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure," says Jackson. "But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online."
+ So far, about 15 production products are running on the new platform, including Pearson’s new flagship digital education service, the Global Learning Platform. The Cloud Platform team continues to prepare, onboard and support customers that are a good fit for the platform. Some existing products will be refactored into 12-factor apps, while others are being developed so that they can live on the platform from the get-go. "There are challenges with bringing in new customers of course, because we have to help them to see a different way of developing, a different way of building," says Shirley.
+ But, he adds, "It is our corporate motto: Always Learning. We encourage those teams that haven’t started a cloud native journey, to see the future of technology, to learn, to explore. It will pique your interest. Keep learning."
+
+
\ No newline at end of file
diff --git a/static/images/case_studies/pearson_feature.png b/content/en/case-studies/pearson/pearson_featured.png
similarity index 100%
rename from static/images/case_studies/pearson_feature.png
rename to content/en/case-studies/pearson/pearson_featured.png
diff --git a/static/images/case_studies/pearson_logo.png b/content/en/case-studies/pearson/pearson_logo.png
similarity index 100%
rename from static/images/case_studies/pearson_logo.png
rename to content/en/case-studies/pearson/pearson_logo.png
diff --git a/content/en/case-studies/philips/index.html b/content/en/case-studies/philips/index.html
new file mode 100644
index 0000000000..e45d41a776
--- /dev/null
+++ b/content/en/case-studies/philips/index.html
@@ -0,0 +1,4 @@
+---
+title: Philips
+content_url: https://cloud.google.com/customers/philips/
+---
\ No newline at end of file
diff --git a/static/images/case_studies/philips_logo.png b/content/en/case-studies/philips/philips_logo.png
similarity index 100%
rename from static/images/case_studies/philips_logo.png
rename to content/en/case-studies/philips/philips_logo.png
diff --git a/content/en/case-studies/pinterest.html b/content/en/case-studies/pinterest/index.html
similarity index 98%
rename from content/en/case-studies/pinterest.html
rename to content/en/case-studies/pinterest/index.html
index 1455a44ef2..aacc4300a5 100644
--- a/content/en/case-studies/pinterest.html
+++ b/content/en/case-studies/pinterest/index.html
@@ -1,8 +1,13 @@
---
title: Pinterest Case Study
+linkTitle: Pinterest
case_study_styles: true
cid: caseStudies
css: /css/style_case_studies.css
+featured: true
+weight: 30
+quote: >
+ We are in the position to run things at scale, in a public cloud environment, and test things out in way that a lot of people might not be able to do.
---
diff --git a/static/images/case_studies/pinterest_feature.png b/content/en/case-studies/pinterest/pinterest_feature.png
similarity index 100%
rename from static/images/case_studies/pinterest_feature.png
rename to content/en/case-studies/pinterest/pinterest_feature.png
diff --git a/static/images/case_studies/pinterest.png b/content/en/case-studies/pinterest/pinterest_logo.png
similarity index 100%
rename from static/images/case_studies/pinterest.png
rename to content/en/case-studies/pinterest/pinterest_logo.png
diff --git a/content/en/case-studies/pokemon-go/index.html b/content/en/case-studies/pokemon-go/index.html
new file mode 100644
index 0000000000..ed4e168019
--- /dev/null
+++ b/content/en/case-studies/pokemon-go/index.html
@@ -0,0 +1,4 @@
+---
+title: Pokemon GO
+content_url: https://cloudplatform.googleblog.com/2016/09/bringing-Pokemon-GO-to-life-on-Google-Cloud.html
+---
\ No newline at end of file
diff --git a/static/images/case_studies/pokemon_go_logo.png b/content/en/case-studies/pokemon-go/pokemon_go_logo.png
similarity index 100%
rename from static/images/case_studies/pokemon_go_logo.png
rename to content/en/case-studies/pokemon-go/pokemon_go_logo.png
diff --git a/content/en/case-studies/samsung-sds/index.html b/content/en/case-studies/samsung-sds/index.html
new file mode 100644
index 0000000000..db4aa479ab
--- /dev/null
+++ b/content/en/case-studies/samsung-sds/index.html
@@ -0,0 +1,4 @@
+---
+title: Samsung SDS
+content_url: http://www.nextplatform.com/2016/05/24/samsung-experts-put-kubernetes-paces/
+---
\ No newline at end of file
diff --git a/static/images/case_studies/sds.png b/content/en/case-studies/samsung-sds/sds_logo.png
similarity index 100%
rename from static/images/case_studies/sds.png
rename to content/en/case-studies/samsung-sds/sds_logo.png
diff --git a/content/en/case-studies/sap/index.html b/content/en/case-studies/sap/index.html
new file mode 100644
index 0000000000..856dc8be9d
--- /dev/null
+++ b/content/en/case-studies/sap/index.html
@@ -0,0 +1,4 @@
+---
+title: SAP
+content_url: https://youtu.be/4gyeixJLabo
+---
\ No newline at end of file
diff --git a/static/images/case_studies/sap.png b/content/en/case-studies/sap/sap_logo.png
similarity index 100%
rename from static/images/case_studies/sap.png
rename to content/en/case-studies/sap/sap_logo.png
diff --git a/static/images/case_studies/sap_small.png b/content/en/case-studies/sap/sap_small.png
similarity index 100%
rename from static/images/case_studies/sap_small.png
rename to content/en/case-studies/sap/sap_small.png
diff --git a/content/en/case-studies/slingtv.html b/content/en/case-studies/slingtv/index.html
similarity index 97%
rename from content/en/case-studies/slingtv.html
rename to content/en/case-studies/slingtv/index.html
index 6cef810b4b..d60b71974d 100644
--- a/content/en/case-studies/slingtv.html
+++ b/content/en/case-studies/slingtv/index.html
@@ -1,8 +1,13 @@
---
title: SlingTV Case Study
+linkTitle: Sling TV
case_study_styles: true
cid: caseStudies
css: /css/style_case_studies.css
+featured: true
+weight: 10
+quote: >
+ I would almost be so bold as to say that most of these applications that we are building now would not have been possible without the cloud native patterns and the flexibility that Kubernetes enables.
---
diff --git a/static/images/case_studies/slingtv_feature.png b/content/en/case-studies/slingtv/slingtv_featured_logo.png
similarity index 100%
rename from static/images/case_studies/slingtv_feature.png
rename to content/en/case-studies/slingtv/slingtv_featured_logo.png
diff --git a/content/en/case-studies/soundcloud/index.html b/content/en/case-studies/soundcloud/index.html
new file mode 100644
index 0000000000..50611ffd85
--- /dev/null
+++ b/content/en/case-studies/soundcloud/index.html
@@ -0,0 +1,4 @@
+---
+title: Soundcloud
+content_url: https://www.youtube.com/watch?v=5378N5iLb2Q
+---
\ No newline at end of file
diff --git a/static/images/case_studies/soundcloud.png b/content/en/case-studies/soundcloud/soundcloud_logo.png
similarity index 100%
rename from static/images/case_studies/soundcloud.png
rename to content/en/case-studies/soundcloud/soundcloud_logo.png
diff --git a/content/en/case-studies/squarespace.html b/content/en/case-studies/squarespace/index.html
similarity index 100%
rename from content/en/case-studies/squarespace.html
rename to content/en/case-studies/squarespace/index.html
diff --git a/static/images/case_studies/squarespace_feature.png b/content/en/case-studies/squarespace/squarespace_featured_logo.png
similarity index 100%
rename from static/images/case_studies/squarespace_feature.png
rename to content/en/case-studies/squarespace/squarespace_featured_logo.png
diff --git a/content/en/case-studies/wepay/index.html b/content/en/case-studies/wepay/index.html
new file mode 100644
index 0000000000..b8ce8201d5
--- /dev/null
+++ b/content/en/case-studies/wepay/index.html
@@ -0,0 +1,4 @@
+---
+title: WePay
+content_url: http://thenewstack.io/wepay-kubernetes-changed-business/
+---
\ No newline at end of file
diff --git a/static/images/case_studies/wepay.png b/content/en/case-studies/wepay/wepay_logo.png
similarity index 100%
rename from static/images/case_studies/wepay.png
rename to content/en/case-studies/wepay/wepay_logo.png
diff --git a/content/en/case-studies/wikimedia.html b/content/en/case-studies/wikimedia/index.html
similarity index 98%
rename from content/en/case-studies/wikimedia.html
rename to content/en/case-studies/wikimedia/index.html
index c58cb94104..abc74e3ee3 100644
--- a/content/en/case-studies/wikimedia.html
+++ b/content/en/case-studies/wikimedia/index.html
@@ -17,7 +17,7 @@ cid: caseStudies
The non-profit Wikimedia Foundation operates some of the largest collaboratively edited reference projects in the world, including Wikipedia. To help users maintain and use wikis, it runs Wikimedia Tool Labs, a hosting environment for community developers working on tools and bots to help editors and other volunteers do their work, including reducing vandalism. The community around Wikimedia Tool Labs began forming nearly 10 years ago.
-
+
"Wikimedia Tool Labs is vital for making sure wikis all around the world work as well as they possibly can. Because it's grown organically for almost 10 years, it has become an extremely challenging environment and difficult to maintain. It's like a big ball of mud — you really can't see through it. With Kubernetes, we're simplifying the environment and making it easier for developers to build the tools that make wikis run better."
diff --git a/static/images/case_studies/wikimedia.png b/content/en/case-studies/wikimedia/wikimedia_featured.png
similarity index 100%
rename from static/images/case_studies/wikimedia.png
rename to content/en/case-studies/wikimedia/wikimedia_featured.png
diff --git a/static/images/case_studies/wikimedia_logo.png b/content/en/case-studies/wikimedia/wikimedia_logo.png
similarity index 100%
rename from static/images/case_studies/wikimedia_logo.png
rename to content/en/case-studies/wikimedia/wikimedia_logo.png
diff --git a/content/en/case-studies/wink.html b/content/en/case-studies/wink/index.html
similarity index 100%
rename from content/en/case-studies/wink.html
rename to content/en/case-studies/wink/index.html
diff --git a/static/images/case_studies/wink_logo.png b/content/en/case-studies/wink/wink_featured.png
similarity index 100%
rename from static/images/case_studies/wink_logo.png
rename to content/en/case-studies/wink/wink_featured.png
diff --git a/static/images/case_studies/wink.png b/content/en/case-studies/wink/wink_logo.png
similarity index 100%
rename from static/images/case_studies/wink.png
rename to content/en/case-studies/wink/wink_logo.png
diff --git a/content/en/case-studies/workiva.html b/content/en/case-studies/workiva/index.html
similarity index 98%
rename from content/en/case-studies/workiva.html
rename to content/en/case-studies/workiva/index.html
index 6db4c3ecf5..95f323d5ae 100644
--- a/content/en/case-studies/workiva.html
+++ b/content/en/case-studies/workiva/index.html
@@ -1,8 +1,14 @@
---
title: Workiva Case Study
+linkTitle: Workiva
case_study_styles: true
cid: caseStudies
css: /css/style_case_studies.css
+draft: true
+featured: true
+weight: 20
+quote: >
+ With OpenTracing, my team was able to look at a trace and make optimization suggestions to another team without ever looking at their code.
---
diff --git a/static/images/case_studies/workiva_feature.png b/content/en/case-studies/workiva/workiva_featured_logo.png
similarity index 100%
rename from static/images/case_studies/workiva_feature.png
rename to content/en/case-studies/workiva/workiva_featured_logo.png
diff --git a/content/en/case-studies/yahoo-japan/index.html b/content/en/case-studies/yahoo-japan/index.html
new file mode 100644
index 0000000000..724a41ae01
--- /dev/null
+++ b/content/en/case-studies/yahoo-japan/index.html
@@ -0,0 +1,4 @@
+---
+title: Yahoo! Japan
+content_url: https://kubernetes.io/blog/2016/10/kubernetes-and-openstack-at-yahoo-japan
+---
\ No newline at end of file
diff --git a/static/images/case_studies/yahooJapan_logo.png b/content/en/case-studies/yahoo-japan/yahooJapan_logo.png
similarity index 100%
rename from static/images/case_studies/yahooJapan_logo.png
rename to content/en/case-studies/yahoo-japan/yahooJapan_logo.png
diff --git a/content/en/case-studies/ygrene/index.html b/content/en/case-studies/ygrene/index.html
new file mode 100644
index 0000000000..a2365026c1
--- /dev/null
+++ b/content/en/case-studies/ygrene/index.html
@@ -0,0 +1,111 @@
+---
+title: Ygrene Case Study
+
+linkTitle: Ygrene
+case_study_styles: true
+cid: caseStudies
+css: /css/style_case_studies.css
+logo: ygrene_featured_logo.png
+featured: true
+weight: 2
+quote: >
+ We had to change some practices and code, and the way things were built, but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That’s very fast for a finance company.
+---
+
+
+
CASE STUDY:
Ygrene: Using Cloud Native to Bring Security and Scalability to the Finance Industry
+
+
+
+
+
+
+ Company Ygrene Location Petaluma, Calif. Industry Clean energy financing
+
+
+
+
+
+
+
Challenge
+ A PACE (Property Assessed Clean Energy) financing company, Ygrene has funded more than $1 billion in loans since 2010. In order to approve and process those loans, "We have lots of data sources that are being aggregated, and we also have lots of systems that need to churn on that data," says Ygrene Development Manager Austin Adams. The company was utilizing massive servers, and "we just reached the limit of being able to scale them vertically. We had a really unstable system that became overwhelmed with requests just for doing background data processing in real time. The performance the users saw was very poor. We needed a solution that wouldn’t require us to make huge refactors to the code base." As a finance company, Ygrene also needed to ensure that they were shipping their applications securely.
+
+
+
+
Solution
+ Moving from an Engine Yard platform and Amazon Elastic Beanstalk, the Ygrene team embraced cloud native technologies and practices: Kubernetes to help scale out vertically and distribute workloads, Notary to put in build-time controls and get trust on the Docker images being used with third-party dependencies, and Fluentd for "observing every part of our stack," all running on Amazon EC2 Spot.
+
+
+
+
+
+
Impact
+ Before, deployments typically took three to four hours, and two or three months’ worth of work would be deployed at low-traffic times every week or two weeks. Now, they take five minutes for Kubernetes, and an hour for the overall deploy with smoke testing. And "we’re able to deploy three or four times a week, with just one week’s or two days’ worth of work," Adams says. "We’re deploying during the work week, in the daytime and without any downtime. We had to ask for business approval to take the systems down, even in the middle of the night, because people could be doing loans. Now we can deploy, ship code, and migrate databases, all without taking the system down. The company gets new features without worrying that some business will be lost or delayed." Additionally, by using the kops project, Ygrene can now run its Kubernetes clusters with AWS EC2 Spot, at a tenth of the previous cost. These cloud native technologies have "changed the game for scalability, observability, and security—we’re adding new data sources that are very secure," says Adams. "Without Kubernetes, Notary, and Fluentd, we couldn’t tell our investors and team members that we knew what was going on."
+
+
+
+
+
+
+
+
+"CNCF projects are helping Ygrene determine the security and observability standards for the entire PACE industry. We’re an emerging finance industry, and without these projects, especially Kubernetes, we couldn’t be the industry leader that we are today."
— Austin Adams, Development Manager, Ygrene Energy Fund
+
+
+
+
+
+
In less than a decade, Ygrene has funded more than $1 billion in loans for renewable energy projects.
A PACE (Property Assessed Clean Energy) financing company, "We take the equity in a home or a commercial building, and use it to finance property improvements for anything that saves electricity, produces electricity, saves water, or reduces carbon emissions," says Development Manager Austin Adams.
+In order to approve those loans, the company processes an enormous amount of underwriting data. "We have tons of different points that we have to validate about the property, about the company, or about the person," Adams says. "So we have lots of data sources that are being aggregated, and we also have lots of systems that need to churn on that data in real time."
+By 2017, deployments and scalability had become pain points. The company was utilizing massive servers, and "we just reached the limit of being able to scale them vertically," he says. Migrating to AWS Elastic Beanstalk didn’t solve the problem: "The Scala services needed a lot of data from the main Ruby on Rails services and from different vendors, so they were asking for information from our Ruby services at a rate that those services couldn’t handle. We had lots of configuration misses with Elastic Beanstalk as well. It just came to a head, and we realized we had a really unstable system."
+
+
+
+
+
+ "CNCF has been an amazing incubator for so many projects. Now we look at its webpage regularly to find out if there are any new, awesome, high-quality projects we can implement into our stack. It’s actually become a hub for us for knowing what software we need to be looking at to make our systems more secure or more scalable."
— Austin Adams, Development Manager, Ygrene Energy Fund
+
+
+
+
+
+Adams along with the rest of the team set out to find a solution that would be transformational, but "wouldn’t require us to make huge refactors to the code base," he says. And as a finance company, Ygrene needed security as much as scalability. They found the answer by embracing cloud native technologies: Kubernetes to help scale out vertically and distribute workloads, Notary to achieve reliable security at every level, and Fluentd for observability. "Kubernetes was where the community was going, and we wanted to be future proof," says Adams.
+With Kubernetes, the team was able to quickly containerize the Ygrene application with Docker. "We had to change some practices and code, and the way things were built," Adams says, "but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That’s very fast for a finance company."
+How? Cloud native has "changed the game for scalability, observability, and security—we’re adding new data sources that are very secure," says Adams. "Without Kubernetes, Notary, and Fluentd, we couldn’t tell our investors and team members that we knew what was going on."
+Notary, in particular, "has been a godsend," says Adams. "We need to know that our attack surface on third-party dependencies is low, or at least managed. We use it as a trust system and we also use it as a separation, so production images are signed by Notary, but some development images we don’t sign. That is to ensure that they can’t get into the production cluster. We’ve been using it in the test cluster to feel more secure about our builds."
+
+
+
+
+
+
+
+"We had to change some practices and code, and the way things were built," Adams says, "but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That’s very fast for a finance company."
+
+
+
+
+
+ By using the kops project, Ygrene was able to move from Elastic Beanstalk to running its Kubernetes clusters on AWS EC2 Spot, at a tenth of the previous cost. "In order to scale before, we would need to up our instance sizes, incurring high cost for low value," says Adams. "Now with Kubernetes and kops, we are able to scale horizontally on Spot with multiple instance groups."
+That also helped them mitigate the risk that comes with running in the public cloud. "We figured out, essentially, that if we’re able to select instance classes using EC2 Spot that had an extremely low likelihood of interruption and zero history of interruption, and we’re willing to pay a price high enough, that we could virtually get the same guarantee using Kubernetes because we have enough nodes," says Software Engineer Zach Arnold, who led the migration to Kubernetes. "Now that we’ve re-architected these pieces of the application to not live on the same server, we can push out to many different servers and have a more stable deployment."
+As a result, the team can now ship code any time of day. "That was risky because it could bring down your whole loan management software with it," says Arnold. "But we now can deploy safely and securely during the day."
+
+
+
+
+
+
+ "In order to scale before, we would need to up our instance sizes, incurring high cost for low value," says Adams. "Now with Kubernetes and kops, we are able to scale horizontally on Spot with multiple instance groups."
+
+
+
+
+ Before, deployments typically took three to four hours, and two or three months’ worth of work would be deployed at low-traffic times every week or two weeks. Now, they take five minutes for Kubernetes, and an hour for an overall deploy with smoke testing. And "we’re able to deploy three or four times a week, with just one week’s or two days’ worth of work," Adams says. "We’re deploying during the work week, in the daytime and without any downtime. We had to ask for business approval to take the systems down for 30 minutes to an hour, even in the middle of the night, because people could be doing loans. Now we can deploy, ship code, and migrate databases, all without taking the system down. The company gets new features without worrying that some business will be lost or delayed."
+Cloud native also affected how Ygrene’s 50+ developers and contractors work. Adams and Arnold spent considerable time "teaching people to think distributed out of the box," says Arnold. "We ended up picking what we call the Four S’s of Shipping: safely, securely, stably, and speedily." (For more on the security piece of it, see their article on their "continuous hacking" strategy.) As for the engineers, says Adams, "they have been able to advance as their software has advanced. I think that at the end of the day, the developers feel better about what they’re doing, and they also feel more connected to the modern software development community."
+Looking ahead, Adams is excited to explore more CNCF projects, including SPIFFE and SPIRE. "CNCF has been an amazing incubator for so many projects," he says. "Now we look at its webpage regularly to find out if there are any new, awesome, high-quality projects we can implement into our stack. It’s actually become a hub for us for knowing what software we need to be looking at to make our systems more secure or more scalable."
+
+
+
+
+
+
diff --git a/content/en/case-studies/ygrene/ygrene_featured_logo.png b/content/en/case-studies/ygrene/ygrene_featured_logo.png
new file mode 100644
index 0000000000..d0d6911478
Binary files /dev/null and b/content/en/case-studies/ygrene/ygrene_featured_logo.png differ
diff --git a/content/en/case-studies/zalando.html b/content/en/case-studies/zalando/index.html
similarity index 100%
rename from content/en/case-studies/zalando.html
rename to content/en/case-studies/zalando/index.html
diff --git a/static/images/case_studies/zalando_feature.png b/content/en/case-studies/zalando/zalando_feature_logo.png
similarity index 100%
rename from static/images/case_studies/zalando_feature.png
rename to content/en/case-studies/zalando/zalando_feature_logo.png
diff --git a/content/en/case-studies/zulily/index.html b/content/en/case-studies/zulily/index.html
new file mode 100644
index 0000000000..a9e480ea97
--- /dev/null
+++ b/content/en/case-studies/zulily/index.html
@@ -0,0 +1,4 @@
+---
+title: Zulily
+content_url: https://www.youtube.com/embed/of45hYbkIZs
+---
\ No newline at end of file
diff --git a/static/images/case_studies/zulily.png b/content/en/case-studies/zulily/zulily_featured.png
similarity index 100%
rename from static/images/case_studies/zulily.png
rename to content/en/case-studies/zulily/zulily_featured.png
diff --git a/static/images/case_studies/zulily_logo.png b/content/en/case-studies/zulily/zulily_logo.png
similarity index 100%
rename from static/images/case_studies/zulily_logo.png
rename to content/en/case-studies/zulily/zulily_logo.png
diff --git a/content/en/docs/_index.md b/content/en/docs/_index.md
index e144d39935..05e96e2901 100644
--- a/content/en/docs/_index.md
+++ b/content/en/docs/_index.md
@@ -1,3 +1,3 @@
---
-title: Home
+title: Documentation
---
diff --git a/content/en/docs/community/_index.md b/content/en/docs/community/_index.md
new file mode 100644
index 0000000000..f3bad1fbe4
--- /dev/null
+++ b/content/en/docs/community/_index.md
@@ -0,0 +1,6 @@
+---
+title: "Community"
+weight: 80
+---
+
+This section of the Kubernetes documentation surfaces key topics imported from the [kubernetes/community](https://github.com/kubernetes/community) repo. It is the starting point for becoming a contributor -- improving docs, improving code, giving talks etc.
diff --git a/content/en/docs/imported/community/devel.md b/content/en/docs/community/devel.md
similarity index 100%
rename from content/en/docs/imported/community/devel.md
rename to content/en/docs/community/devel.md
diff --git a/content/en/docs/imported/community/guide.md b/content/en/docs/community/guide.md
similarity index 100%
rename from content/en/docs/imported/community/guide.md
rename to content/en/docs/community/guide.md
diff --git a/content/en/docs/imported/community/keps.md b/content/en/docs/community/keps.md
similarity index 100%
rename from content/en/docs/imported/community/keps.md
rename to content/en/docs/community/keps.md
diff --git a/content/en/docs/imported/community/mentoring.md b/content/en/docs/community/mentoring.md
similarity index 100%
rename from content/en/docs/imported/community/mentoring.md
rename to content/en/docs/community/mentoring.md
diff --git a/content/en/docs/concepts/architecture/master-node-communication.md b/content/en/docs/concepts/architecture/master-node-communication.md
index 652b0ac240..9c1064cfcc 100644
--- a/content/en/docs/concepts/architecture/master-node-communication.md
+++ b/content/en/docs/concepts/architecture/master-node-communication.md
@@ -22,7 +22,7 @@ cloud provider).
{{% capture body %}}
-## Cluster -> Master
+## Cluster to Master
All communication paths from the cluster to the master terminate at the
apiserver (none of the other master components are designed to expose remote
@@ -54,14 +54,14 @@ As a result, the default operating mode for connections from the cluster
(nodes and pods running on the nodes) to the master is secured by default
and can run over untrusted and/or public networks.
-## Master -> Cluster
+## Master to Cluster
There are two primary communication paths from the master (apiserver) to the
cluster. The first is from the apiserver to the kubelet process which runs on
each node in the cluster. The second is from the apiserver to any node, pod,
or service through the apiserver's proxy functionality.
-### apiserver -> kubelet
+### apiserver to kubelet
The connections from the apiserver to the kubelet are used for:
@@ -85,7 +85,7 @@ untrusted or public network.
Finally, [Kubelet authentication and/or authorization](/docs/admin/kubelet-authentication-authorization/)
should be enabled to secure the kubelet API.
-### apiserver -> nodes, pods, and services
+### apiserver to nodes, pods, and services
The connections from the apiserver to a node, pod, or service default to plain
HTTP connections and are therefore neither authenticated nor encrypted. They
diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md
index 004fca8dcb..f5868cc2bf 100644
--- a/content/en/docs/concepts/architecture/nodes.md
+++ b/content/en/docs/concepts/architecture/nodes.md
@@ -9,8 +9,8 @@ weight: 10
{{% capture overview %}}
-A `node` is a worker machine in Kubernetes, previously known as a `minion`. A node
-may be a VM or physical machine, depending on the cluster. Each node has
+A node is a worker machine in Kubernetes, previously known as a `minion`. A node
+may be a VM or physical machine, depending on the cluster. Each node contains
the services necessary to run [pods](/docs/concepts/workloads/pods/pod/) and is managed by the master
components. The services on a node include the [container runtime](/docs/concepts/overview/components/#node-components), kubelet and kube-proxy. See
[The Kubernetes Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) section in the
@@ -67,14 +67,14 @@ The node condition is represented as a JSON object. For example, the following r
]
```
-If the Status of the Ready condition is "Unknown" or "False" for longer than the `pod-eviction-timeout`, an argument is passed to the [kube-controller-manager](/docs/admin/kube-controller-manager/) and all of the Pods on the node are scheduled for deletion by the Node Controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the apiserver is unable to communicate with the kubelet on it. The decision to delete the pods cannot be communicated to the kubelet until it re-establishes communication with the apiserver. In the meantime, the pods which are scheduled for deletion may continue to run on the partitioned node.
+If the Status of the Ready condition remains `Unknown` or `False` for longer than the `pod-eviction-timeout`, an argument is passed to the [kube-controller-manager](/docs/admin/kube-controller-manager/) and all the Pods on the node are scheduled for deletion by the Node Controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the apiserver is unable to communicate with the kubelet on the node. The decision to delete the pods cannot be communicated to the kubelet until communication with the apiserver is re-established. In the meantime, the pods that are scheduled for deletion may continue to run on the partitioned node.
In versions of Kubernetes prior to 1.5, the node controller would [force delete](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)
these unreachable pods from the apiserver. However, in 1.5 and higher, the node controller does not force delete pods until it is
-confirmed that they have stopped running in the cluster. One can see these pods which may be running on an unreachable node as being in
-the "Terminating" or "Unknown" states. In cases where Kubernetes cannot deduce from the underlying infrastructure if a node has
+confirmed that they have stopped running in the cluster. You can see the pods that might be running on an unreachable node as being in
+the `Terminating` or `Unknown` state. In cases where Kubernetes cannot deduce from the underlying infrastructure if a node has
permanently left a cluster, the cluster administrator may need to delete the node object by hand. Deleting the node object from
-Kubernetes causes all the Pod objects running on it to be deleted from the apiserver, freeing up their names.
+Kubernetes causes all the Pod objects running on the node to be deleted from the apiserver, and frees up their names.
Version 1.8 introduced an alpha feature that automatically creates
[taints](/docs/concepts/configuration/taint-and-toleration/) that represent conditions.
@@ -87,9 +87,10 @@ Now users can choose between the old scheduling model and a new, more flexible s
A Pod that does not have any tolerations gets scheduled according to the old model. But a Pod that
tolerates the taints of a particular Node can be scheduled on that Node.
-Note that because of small delay, usually less than one second, between time when condition is observed and a taint
-is created, it's possible that enabling this feature will slightly increase number of Pods that are successfully
-scheduled but rejected by the kubelet.
+{{< caution >}}
+**Caution:** Enabling this feature creates a small delay between the
+time when a condition is observed and when a taint is created. This delay is usually less than one second, but it can increase the number of Pods that are successfully scheduled but rejected by the kubelet.
+{{< /caution >}}
### Capacity
@@ -106,10 +107,10 @@ The information is gathered by Kubelet from the node.
Unlike [pods](/docs/concepts/workloads/pods/pod/) and [services](/docs/concepts/services-networking/service/),
a node is not inherently created by Kubernetes: it is created externally by cloud
-providers like Google Compute Engine, or exists in your pool of physical or virtual
-machines. What this means is that when Kubernetes creates a node, it is really
-just creating an object that represents the node. After creation, Kubernetes
-will check whether the node is valid or not. For example, if you try to create
+providers like Google Compute Engine, or it exists in your pool of physical or virtual
+machines. So when Kubernetes creates a node, it creates
+an object that represents the node. After creation, Kubernetes
+checks whether the node is valid or not. For example, if you try to create
a node from the following content:
```json
@@ -125,13 +126,15 @@ a node from the following content:
}
```
-Kubernetes will create a node object internally (the representation), and
-validate the node by health checking based on the `metadata.name` field (we
-assume `metadata.name` can be resolved). If the node is valid, i.e. all necessary
-services are running, it is eligible to run a pod; otherwise, it will be
-ignored for any cluster activity until it becomes valid. Note that Kubernetes
-will keep the object for the invalid node unless it is explicitly deleted by
-the client, and it will keep checking to see if it becomes valid.
+Kubernetes creates a node object internally (the representation), and
+validates the node by health checking based on the `metadata.name` field. If the node is valid -- that is, if all necessary
+services are running -- it is eligible to run a pod. Otherwise, it is
+ignored for any cluster activity until it becomes valid.
+
+{{< note >}}
+**Note:** 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 >}}
Currently, there are three components that interact with the Kubernetes node
interface: node controller, kubelet, and kubectl.
@@ -162,7 +165,7 @@ checks the state of each node every `--node-monitor-period` seconds.
In Kubernetes 1.4, we updated the logic of the node controller to better handle
cases when a large number of nodes have problems with reaching the master
(e.g. because the master has networking problem). Starting with 1.4, the node
-controller will look at the state of all nodes in the cluster when making a
+controller looks at the state of all nodes in the cluster when making a
decision about pod eviction.
In most cases, node controller limits the eviction rate to
@@ -232,8 +235,8 @@ Modifications include setting labels on the node and marking it unschedulable.
Labels on nodes can be used in conjunction with node selectors on pods to control scheduling,
e.g. to constrain a pod to only be eligible to run on a subset of the nodes.
-Marking a node as unschedulable will prevent new pods from being scheduled to that
-node, but will not affect any existing pods on the node. This is useful as a
+Marking a node as unschedulable prevents new pods from being scheduled to that
+node, but does not affect any existing pods on the node. This is useful as a
preparatory step before a node reboot, etc. For example, to mark a node
unschedulable, run this command:
@@ -241,9 +244,11 @@ unschedulable, run this command:
kubectl cordon $NODENAME
```
-Note that pods which are created by a DaemonSet controller bypass the Kubernetes scheduler,
-and do not respect the unschedulable attribute on a node. The assumption is that daemons belong on
-the machine even if it is being drained of applications in preparation for a reboot.
+{{< note >}}
+**Note:** 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 >}}
### Node capacity
diff --git a/content/en/docs/concepts/cluster-administration/logging.md b/content/en/docs/concepts/cluster-administration/logging.md
index 58004b2a4b..731efcf9e9 100644
--- a/content/en/docs/concepts/cluster-administration/logging.md
+++ b/content/en/docs/concepts/cluster-administration/logging.md
@@ -37,7 +37,7 @@ To run this pod, use the following command:
```shell
$ kubectl create -f https://k8s.io/examples/debug/counter-pod.yaml
-pod "counter" created
+pod/counter created
```
To fetch the logs, use the `kubectl logs` command, as follows:
diff --git a/content/en/docs/concepts/cluster-administration/manage-deployment.md b/content/en/docs/concepts/cluster-administration/manage-deployment.md
index 499675139e..eb01056679 100644
--- a/content/en/docs/concepts/cluster-administration/manage-deployment.md
+++ b/content/en/docs/concepts/cluster-administration/manage-deployment.md
@@ -28,8 +28,8 @@ Multiple resources can be created the same way as a single resource:
```shell
$ kubectl create -f https://k8s.io/examples/application/nginx-app.yaml
-service "my-nginx-svc" created
-deployment "my-nginx" created
+service/my-nginx-svc created
+deployment.apps/my-nginx created
```
The resources will be created in the order they appear in the file. Therefore, it's best to specify the service first, since that will ensure the scheduler can spread the pods associated with the service as they are created by the controller(s), such as Deployment.
@@ -54,7 +54,7 @@ A URL can also be specified as a configuration source, which is handy for deploy
```shell
$ kubectl create -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/application/nginx/nginx-deployment.yaml
-deployment "my-nginx" created
+deployment.apps/my-nginx created
```
## Bulk operations in kubectl
@@ -77,7 +77,7 @@ For larger numbers of resources, you'll find it easier to specify the selector (
```shell
$ kubectl delete deployment,services -l app=nginx
-deployment "my-nginx" deleted
+deployment.apps "my-nginx" deleted
service "my-nginx-svc" deleted
```
@@ -85,8 +85,8 @@ Because `kubectl` outputs resource names in the same syntax it accepts, it's eas
```shell
$ kubectl get $(kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service)
-NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
-my-nginx-svc 10.0.0.208 80/TCP 0s
+NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+my-nginx-svc LoadBalancer 10.0.0.208 80/TCP 0s
```
With the above commands, we first create resources under `examples/application/nginx/` and print the resources created with `-o name` output format
@@ -242,9 +242,9 @@ For example, if you want to label all your nginx pods as frontend tier, simply r
```shell
$ kubectl label pods -l app=nginx tier=fe
-pod "my-nginx-2035384211-j5fhi" labeled
-pod "my-nginx-2035384211-u2c7e" labeled
-pod "my-nginx-2035384211-u3t6x" labeled
+pod/my-nginx-2035384211-j5fhi labeled
+pod/my-nginx-2035384211-u2c7e labeled
+pod/my-nginx-2035384211-u3t6x labeled
```
This first filters all pods with the label "app=nginx", and then labels them with the "tier=fe".
@@ -285,7 +285,7 @@ When load on your application grows or shrinks, it's easy to scale with `kubectl
```shell
$ kubectl scale deployment/my-nginx --replicas=1
-deployment "my-nginx" scaled
+deployment.extensions/my-nginx scaled
```
Now you only have one pod managed by the deployment.
@@ -300,7 +300,7 @@ To have the system automatically choose the number of nginx replicas as needed,
```shell
$ kubectl autoscale deployment/my-nginx --min=1 --max=3
-deployment "my-nginx" autoscaled
+horizontalpodautoscaler.autoscaling/my-nginx autoscaled
```
Now your nginx replicas will be scaled up and down as needed, automatically.
@@ -322,7 +322,7 @@ This command will compare the version of the configuration that you're pushing w
```shell
$ kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml
-deployment "my-nginx" configured
+deployment.apps/my-nginx configured
```
Note that `kubectl apply` attaches an annotation to the resource in order to determine the changes to the configuration since the previous invocation. When it's invoked, `kubectl apply` does a three-way diff between the previous configuration, the provided input and the current configuration of the resource, in order to determine how to modify the resource.
@@ -350,7 +350,7 @@ $ kubectl get deployment my-nginx -o yaml > /tmp/nginx.yaml
$ vi /tmp/nginx.yaml
# do some edit, and then save the file
$ kubectl apply -f /tmp/nginx.yaml
-deployment "my-nginx" configured
+deployment.apps/my-nginx configured
$ rm /tmp/nginx.yaml
```
@@ -372,8 +372,8 @@ In some cases, you may need to update resource fields that cannot be updated onc
```shell
$ kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force
-deployment "my-nginx" deleted
-deployment "my-nginx" replaced
+deployment.apps/my-nginx deleted
+deployment.apps/my-nginx replaced
```
## Updating your application without a service outage
@@ -387,7 +387,7 @@ Let's say you were running version 1.7.9 of nginx:
```shell
$ kubectl run my-nginx --image=nginx:1.7.9 --replicas=3
-deployment "my-nginx" created
+deployment.apps/my-nginx created
```
To update to version 1.9.1, simply change `.spec.template.spec.containers[0].image` from `nginx:1.7.9` to `nginx:1.9.1`, with the kubectl commands we learned above.
diff --git a/content/en/docs/concepts/configuration/assign-pod-node.md b/content/en/docs/concepts/configuration/assign-pod-node.md
index ce6be282eb..b7f88ffbb4 100644
--- a/content/en/docs/concepts/configuration/assign-pod-node.md
+++ b/content/en/docs/concepts/configuration/assign-pod-node.md
@@ -167,7 +167,7 @@ Inter-pod affinity and anti-affinity were introduced in Kubernetes 1.4.
Inter-pod affinity and anti-affinity allow you to constrain which nodes your pod is eligible to be scheduled *based on
labels on pods that are already running on the node* rather than based on labels on nodes. The rules are of the form "this pod should (or, in the case of
anti-affinity, should not) run in an X if that X is already running one or more pods that meet rule Y". Y is expressed
-as a LabelSelector with an associated list of namespaces (or "all" namespaces); unlike nodes, because pods are namespaced
+as a LabelSelector with an associated list of namespaces; unlike nodes, because pods are namespaced
(and therefore the labels on pods are implicitly namespaced),
a label selector over pod labels must specify which namespaces the selector should apply to. Conceptually X is a topology domain
like node, rack, cloud provider zone, cloud provider region, etc. You express it using a `topologyKey` which is the
@@ -224,8 +224,7 @@ empty `topologyKey` is not allowed.
In addition to `labelSelector` and `topologyKey`, you can optionally specify a list `namespaces`
of namespaces which the `labelSelector` should match against (this goes at the same level of the definition as `labelSelector` and `topologyKey`).
-If omitted, it defaults to the namespace of the pod where the affinity/anti-affinity definition appears.
-If defined but empty, it means "all namespaces".
+If omitted or empty, it defaults to the namespace of the pod where the affinity/anti-affinity definition appears.
All `matchExpressions` associated with `requiredDuringSchedulingIgnoredDuringExecution` affinity and anti-affinity
must be satisfied for the pod to be scheduled onto a node.
diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md
index e2469c1c83..722d0217e1 100644
--- a/content/en/docs/concepts/configuration/secret.md
+++ b/content/en/docs/concepts/configuration/secret.md
@@ -482,7 +482,9 @@ Create a secret containing some ssh keys:
$ kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub
```
-**Security Note:** 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 >}}
+**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.
+{{< /caution >}}
Now we can create a pod which references the secret with the ssh key and
diff --git a/content/en/docs/concepts/configuration/taint-and-toleration.md b/content/en/docs/concepts/configuration/taint-and-toleration.md
index c989e7e230..9292ebcaae 100644
--- a/content/en/docs/concepts/configuration/taint-and-toleration.md
+++ b/content/en/docs/concepts/configuration/taint-and-toleration.md
@@ -69,7 +69,8 @@ A toleration "matches" a taint if the keys are the same and the effects are the
`Operator` defaults to `Equal` if not specified.
-**NOTE:** There are two special cases:
+{{< note >}}
+**Note:** There are two special cases:
* An empty `key` with operator `Exists` matches all keys, values and effects which means this
will tolerate everything.
@@ -86,6 +87,7 @@ tolerations:
- key: "key"
operator: "Exists"
```
+{{< /note >}}
The above example used `effect` of `NoSchedule`. Alternatively, you can use `effect` of `PreferNoSchedule`.
This is a "preference" or "soft" version of `NoSchedule` -- the system will *try* to avoid placing a
@@ -227,10 +229,14 @@ including `TaintBasedEvictions=true` in `--feature-gates` for Kubernetes control
such as `--feature-gates=FooBar=true,TaintBasedEvictions=true`), the taints are automatically
added by the NodeController (or kubelet) and the normal logic for evicting pods from nodes
based on the Ready NodeCondition is disabled.
-(Note: To maintain the existing [rate limiting](/docs/concepts/architecture/nodes/)
+
+{{< note >}}
+**Note:** 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.)
+as the master becoming partitioned from the nodes.
+{{< /note >}}
+
This alpha feature, in combination with `tolerationSeconds`, allows a pod
to specify how long it should stay bound to a node that has one or both of these problems.
diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md
index 5f0c40b9c0..71d98c6739 100644
--- a/content/en/docs/concepts/containers/images.md
+++ b/content/en/docs/concepts/containers/images.md
@@ -128,7 +128,7 @@ Once you have those variables filled in you can
[configure a Kubernetes Secret and use it to deploy a Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
-### Configuring Nodes to Authenticate to a Private Repository
+### 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.
@@ -187,7 +187,7 @@ spec:
imagePullPolicy: Always
command: [ "echo", "SUCCESS" ]
EOF
-pod "private-image-test-1" created
+pod/private-image-test-1 created
```
If everything is working, then, after a few moments, you should see:
@@ -250,7 +250,7 @@ Run the following command, substituting the appropriate uppercase values:
```shell
kubectl create secret docker-registry myregistrykey --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
-secret "myregistrykey" created.
+secret/myregistrykey created.
```
If you need access to multiple registries, you can create one secret for each registry.
diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
index 422a51b6ad..22886908c7 100644
--- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
+++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
@@ -45,7 +45,92 @@ If there are multiple CNI configuration files in the directory, the first one in
In addition to the CNI plugin specified by the configuration file, Kubernetes requires the standard CNI [`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) plugin, at minimum version 0.2.0
-Limitation: Due to [#31307](https://github.com/kubernetes/kubernetes/issues/31307), `HostPort` won't work with CNI networking plugin at the moment. That means all `hostPort` attribute in pod would be simply ignored.
+#### Support hostPort
+
+The CNI networking plugin supports `hostPort`. You can use the official [portmap](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap)
+plugin offered by the CNI plugin team or use your own plugin with portMapping functionality.
+
+If you want to enable `hostPort` support, you must specify `portMappings capability` in your `cni-conf-dir`.
+For example:
+
+```json
+{
+ "name": "k8s-pod-network",
+ "cniVersion": "0.3.0",
+ "plugins": [
+ {
+ "type": "calico",
+ "log_level": "info",
+ "datastore_type": "kubernetes",
+ "nodename": "127.0.0.1",
+ "ipam": {
+ "type": "host-local",
+ "subnet": "usePodCidr"
+ },
+ "policy": {
+ "type": "k8s"
+ },
+ "kubernetes": {
+ "kubeconfig": "/etc/cni/net.d/calico-kubeconfig"
+ }
+ },
+ {
+ "type": "portmap",
+ "capabilities": {"portMappings": true}
+ }
+ ]
+}
+```
+
+#### Support traffic shaping
+
+The CNI networking plugin also supports pod ingress and egress traffic shaping. You can use the officical [bandwidth](https://github.com/containernetworking/plugins/tree/master/plugins/meta/bandwidth)
+plugin offered by the CNI plugin team or use your own plugin with bandwidth contol functionality.
+
+If you want to enable traffic shaping support, you must add a `bandwidth` plugin to your CNI configuration file
+(default `/etc/cni/net.d`).
+
+```json
+{
+ "name": "k8s-pod-network",
+ "cniVersion": "0.3.0",
+ "plugins": [
+ {
+ "type": "calico",
+ "log_level": "info",
+ "datastore_type": "kubernetes",
+ "nodename": "127.0.0.1",
+ "ipam": {
+ "type": "host-local",
+ "subnet": "usePodCidr"
+ },
+ "policy": {
+ "type": "k8s"
+ },
+ "kubernetes": {
+ "kubeconfig": "/etc/cni/net.d/calico-kubeconfig"
+ }
+ },
+ {
+ "type": "bandwidth",
+ "capabilities": {"bandwidth": true}
+ }
+ ]
+}
+```
+
+Now you can add the `kubernetes.io/ingress-bandwidth` and `kubernetes.io/egress-bandwidth` annotations to your pod.
+For example:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ annotations:
+ kubernetes.io/ingress-bandwidth: 1M
+ kubernetes.io/egress-bandwidth: 1M
+...
+```
### kubenet
diff --git a/content/en/docs/concepts/overview/kubernetes-api.md b/content/en/docs/concepts/overview/kubernetes-api.md
index 3144df289d..464799628b 100644
--- a/content/en/docs/concepts/overview/kubernetes-api.md
+++ b/content/en/docs/concepts/overview/kubernetes-api.md
@@ -109,8 +109,8 @@ There are two supported paths to extending the API with [custom resources](/docs
1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)
is for users with very basic CRUD needs.
-1. Coming soon: users needing the full set of Kubernetes API semantics can implement their own apiserver
- and use the [aggregator](https://git.k8s.io/community/contributors/design-proposals/api-machinery/aggregated-api-servers.md)
+1. Users needing the full set of Kubernetes API semantics can implement their own apiserver
+ and use the [aggregator](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)
to make it seamless for clients.
@@ -131,4 +131,4 @@ Other extensions resources can be enabled by setting `--runtime-config` on
apiserver. `--runtime-config` accepts comma separated values. For example: to disable deployments and ingress, set
`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingress=false`
-{{% /capture %}}
\ No newline at end of file
+{{% /capture %}}
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 fa7aa28125..f0c63b64bd 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
@@ -594,7 +594,7 @@ retained in the live configuration.
```yaml
# last-applied-configuration value
- args: ["a, b"]
+ args: ["a", "b"]
# configuration file value
args: ["a", "c"]
diff --git a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
index 55bd3675ca..ae529e39bc 100644
--- a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+++ b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
@@ -49,7 +49,7 @@ $ kubectl create -f https://k8s.io/examples/application/deployment.yaml --record
The output is similar to this:
```shell
-deployment "nginx-deployment" created
+deployment.apps/nginx-deployment created
```
### Required Fields
diff --git a/content/en/docs/concepts/policy/pod-security-policy.md b/content/en/docs/concepts/policy/pod-security-policy.md
index 43f7d62895..432d7c1662 100644
--- a/content/en/docs/concepts/policy/pod-security-policy.md
+++ b/content/en/docs/concepts/policy/pod-security-policy.md
@@ -35,7 +35,7 @@ administrator to control the following:
| Usage of host networking and ports | [`hostNetwork`, `hostPorts`](#host-namespaces) |
| Usage of volume types | [`volumes`](#volumes-and-file-systems) |
| Usage of the host filesystem | [`allowedHostPaths`](#volumes-and-file-systems) |
-| White list of FlexVolume drivers | [`allowedFlexVolumes`](#flexvolume-drivers) |
+| 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) |
@@ -452,12 +452,12 @@ to effectively limit access to the specified `pathPrefix`.
**ReadOnlyRootFilesystem** - Requires that containers must run with a read-only
root filesystem (i.e. no writable layer).
-### FlexVolume drivers
+### Flexvolume drivers
-This specifies a whiltelist of flex volume drivers that are allowed to be used
-by flexVolume. An empty list or nil means there is no restriction on the drivers.
+This specifies a whiltelist of Flexvolume drivers that are allowed to be used
+by flexvolume. An empty list or nil means there is no restriction on the drivers.
Please make sure [`volumes`](#volumes-and-file-systems) field contains the
-`flexVolume` volume type, no FlexVolume driver is allowed otherwise.
+`flexVolume` volume type; no Flexvolume driver is allowed otherwise.
For example:
diff --git a/content/en/docs/concepts/policy/resource-quotas.md b/content/en/docs/concepts/policy/resource-quotas.md
index e4c5ab4ec6..e4ad1274b0 100644
--- a/content/en/docs/concepts/policy/resource-quotas.md
+++ b/content/en/docs/concepts/policy/resource-quotas.md
@@ -213,159 +213,166 @@ works as follows:
- Pods in the cluster have one of the three priority classes, "low", "medium", "high".
- One quota object is created for each priority.
-1. Save the following YAML to a file `quota.yml`.
+Save the following YAML to a file `quota.yml`.
- ```yaml
- apiVersion: v1
- kind: List
- items:
- - apiVersion: v1
- kind: ResourceQuota
- metadata:
- name: pods-high
- spec:
- hard:
- cpu: "1000"
- memory: 200Gi
- pods: "10"
- scopeSelector:
- matchExpressions:
- - operator : In
- scopeName: PriorityClass
- values: ["high"]
- - apiVersion: v1
- kind: ResourceQuota
- metadata:
- name: pods-medium
- spec:
- hard:
- cpu: "10"
- memory: 20Gi
- pods: "10"
- scopeSelector:
- matchExpressions:
- - operator : In
- scopeName: PriorityClass
- values: ["medium"]
- - apiVersion: v1
- kind: ResourceQuota
- metadata:
- name: pods-low
- spec:
- hard:
- cpu: "5"
- memory: 10Gi
- pods: "10"
- scopeSelector:
- matchExpressions:
- - operator : In
- scopeName: PriorityClass
- values: ["low"]
- ```
+```yaml
+apiVersion: v1
+kind: List
+items:
+- apiVersion: v1
+ kind: ResourceQuota
+ metadata:
+ name: pods-high
+ spec:
+ hard:
+ cpu: "1000"
+ memory: 200Gi
+ pods: "10"
+ scopeSelector:
+ matchExpressions:
+ - operator : In
+ scopeName: PriorityClass
+ values: ["high"]
+- apiVersion: v1
+ kind: ResourceQuota
+ metadata:
+ name: pods-medium
+ spec:
+ hard:
+ cpu: "10"
+ memory: 20Gi
+ pods: "10"
+ scopeSelector:
+ matchExpressions:
+ - operator : In
+ scopeName: PriorityClass
+ values: ["medium"]
+- apiVersion: v1
+ kind: ResourceQuota
+ metadata:
+ name: pods-low
+ spec:
+ hard:
+ cpu: "5"
+ memory: 10Gi
+ pods: "10"
+ scopeSelector:
+ matchExpressions:
+ - operator : In
+ scopeName: PriorityClass
+ values: ["low"]
+```
-2. Apply it using `kubectl create`.
+Apply the YAML using `kubectl create`.
- ```shell
- kubectl create -f ./quota.yml
+```shell
+kubectl create -f ./quota.yml
+```
- resourcequota/pods-high created
- resourcequota/pods-medium created
- resourcequota/pods-low created
- ```
+```shell
+resourcequota/pods-high created
+resourcequota/pods-medium created
+resourcequota/pods-low created
+```
-3. Verify that `Used` quota is `0` using `kubectl describe quota`.
+Verify that `Used` quota is `0` using `kubectl describe quota`.
- ```shell
- kubectl describe quota
+```shell
+kubectl describe quota
+```
- Name: pods-high
- Namespace: default
- Resource Used Hard
- -------- ---- ----
- cpu 0 1k
- memory 0 200Gi
- pods 0 10
+```shell
+Name: pods-high
+Namespace: default
+Resource Used Hard
+-------- ---- ----
+cpu 0 1k
+memory 0 200Gi
+pods 0 10
- Name: pods-low
- Namespace: default
- Resource Used Hard
- -------- ---- ----
- cpu 0 5
- memory 0 10Gi
- pods 0 10
+Name: pods-low
+Namespace: default
+Resource Used Hard
+-------- ---- ----
+cpu 0 5
+memory 0 10Gi
+pods 0 10
- Name: pods-medium
- Namespace: default
- Resource Used Hard
- -------- ---- ----
- cpu 0 10
- memory 0 20Gi
- pods 0 10
- ```
-4. Create a pod with priority "high". Save the following YAML to a
- file `high-priority-pod.yml`.
+Name: pods-medium
+Namespace: default
+Resource Used Hard
+-------- ---- ----
+cpu 0 10
+memory 0 20Gi
+pods 0 10
+```
- ```yaml
- apiVersion: v1
- kind: Pod
- metadata:
- name: high-priority
- spec:
- containers:
- - name: high-priority
- image: ubuntu
- command: ["/bin/sh"]
- args: ["-c", "while true; do echo hello; sleep 10;done"]
- resources:
- requests:
- memory: "10Gi"
- cpu: "500m"
- limits:
- memory: "10Gi"
- cpu: "500m"
- priorityClassName: high
- ```
+Create a pod with priority "high". Save the following YAML to a
+file `high-priority-pod.yml`.
- Apply it with `kubectl create`.
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ name: high-priority
+spec:
+ containers:
+ - name: high-priority
+ image: ubuntu
+ command: ["/bin/sh"]
+ args: ["-c", "while true; do echo hello; sleep 10;done"]
+ resources:
+ requests:
+ memory: "10Gi"
+ cpu: "500m"
+ limits:
+ memory: "10Gi"
+ cpu: "500m"
+ priorityClassName: high
+```
- ```shell
- kubectl create -f ./high-priority-pod.yml
- ```
+Apply it with `kubectl create`.
-5. Verify that "Used" stats for "high" priority quota, `pods-high`, has changed and that
- the other two quotas are unchanged.
+```shell
+kubectl create -f ./high-priority-pod.yml
+```
- ```shell
- kubectl describe quota
+Verify that "Used" stats for "high" priority quota, `pods-high`, has changed and that
+the other two quotas are unchanged.
- Name: pods-high
- Namespace: default
- Resource Used Hard
- -------- ---- ----
- cpu 500m 1k
- memory 10Gi 200Gi
- pods 1 10
+```shell
+kubectl describe quota
+```
+
+```shell
+Name: pods-high
+Namespace: default
+Resource Used Hard
+-------- ---- ----
+cpu 500m 1k
+memory 10Gi 200Gi
+pods 1 10
- Name: pods-low
- Namespace: default
- Resource Used Hard
- -------- ---- ----
- cpu 0 5
- memory 0 10Gi
- pods 0 10
+Name: pods-low
+Namespace: default
+Resource Used Hard
+-------- ---- ----
+cpu 0 5
+memory 0 10Gi
+pods 0 10
- Name: pods-medium
- Namespace: default
- Resource Used Hard
- -------- ---- ----
- cpu 0 10
- memory 0 20Gi
- pods 0 10
- ```
+Name: pods-medium
+Namespace: default
+Resource Used Hard
+-------- ---- ----
+cpu 0 10
+memory 0 20Gi
+pods 0 10
+```
`scopeSelector` supports the following values in the `operator` field:
@@ -389,7 +396,9 @@ Kubectl supports creating, updating, and viewing quotas:
```shell
kubectl create namespace myspace
+```
+```shell
cat < compute-resources.yaml
apiVersion: v1
kind: ResourceQuota
@@ -404,8 +413,13 @@ spec:
limits.memory: 2Gi
requests.nvidia.com/gpu: 4
EOF
-kubectl create -f ./compute-resources.yaml --namespace=myspace
+```
+```shell
+kubectl create -f ./compute-resources.yaml --namespace=myspace
+```
+
+```shell
cat < object-counts.yaml
apiVersion: v1
kind: ResourceQuota
@@ -420,14 +434,27 @@ spec:
services: "10"
services.loadbalancers: "2"
EOF
-kubectl create -f ./object-counts.yaml --namespace=myspace
+```
+```shell
+kubectl create -f ./object-counts.yaml --namespace=myspace
+```
+
+```shell
kubectl get quota --namespace=myspace
+```
+
+```shell
NAME AGE
compute-resources 30s
object-counts 32s
+```
+```shell
kubectl describe quota compute-resources --namespace=myspace
+```
+
+```shell
Name: compute-resources
Namespace: myspace
Resource Used Hard
@@ -438,9 +465,13 @@ pods 0 4
requests.cpu 0 1
requests.memory 0 1Gi
requests.nvidia.com/gpu 0 4
+```
-
+```shell
kubectl describe quota object-counts --namespace=myspace
+```
+
+```shell
Name: object-counts
Namespace: myspace
Resource Used Hard
@@ -458,12 +489,21 @@ using the syntax `count/.`:
```shell
kubectl create namespace myspace
+```
+```shell
kubectl create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=myspace
+```
+```shell
kubectl run nginx --image=nginx --replicas=2 --namespace=myspace
+```
+```shell
kubectl describe quota --namespace=myspace
+```
+
+```shell
Name: test
Namespace: myspace
Resource Used Hard
@@ -502,8 +542,7 @@ With this mechanism, operators will be able to restrict usage of certain high pr
To enforce this, kube-apiserver flag `--admission-control-config-file` should be used to pass path to the following configuration file:
-```shell
-$ cat admission_config_file.yml
+```yaml
apiVersion: apiserver.k8s.io/v1alpha1
kind: AdmissionConfiguration
plugins:
@@ -521,7 +560,7 @@ plugins:
Now, "cluster-services" pods will be allowed in only those namespaces where a quota object with a matching `scopeSelector` is present.
For example:
-```shell
+```yaml
scopeSelector:
matchExpressions:
- operator : In
@@ -529,7 +568,9 @@ For example:
values: ["cluster-services"]
```
-**NOTE:** `scopeSelector` is an alpha field and feature gate `ResourceQuotaScopeSelectors` must be enabled before using it.
+{{< note >}}
+**Note:** `scopeSelector` is an alpha field and feature gate `ResourceQuotaScopeSelectors` must be enabled before using it.
+{{< /note >}}
See [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765) and [Quota supoport for priority class design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md) for more information.
diff --git a/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
index d874e3dffb..d472665b07 100644
--- a/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
+++ b/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
@@ -22,10 +22,20 @@ Modification not using HostAliases is not suggested because the file is managed
Lets start an Nginx Pod which is assigned a Pod IP:
```shell
-$ kubectl run nginx --image nginx --generator=run-pod/v1
-pod "nginx" created
+kubectl run nginx --image nginx --generator=run-pod/v1
+```
-$ kubectl get pods --output=wide
+```shell
+pod/nginx created
+```
+
+Examine a Pod IP:
+
+```shell
+kubectl get pods --output=wide
+```
+
+```shell
NAME READY STATUS RESTARTS AGE IP NODE
nginx 1/1 Running 0 13s 10.200.0.4 worker0
```
@@ -33,7 +43,10 @@ nginx 1/1 Running 0 13s 10.200.0.4 worker0
The hosts file content would look like this:
```shell
-$ kubectl exec nginx -- cat /etc/hosts
+kubectl exec nginx -- cat /etc/hosts
+```
+
+```none
# Kubernetes-managed hosts file.
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
@@ -59,18 +72,31 @@ In addition to the default boilerplate, we can add additional entries to the
This Pod can be started with the following commands:
```shell
-$ kubectl apply -f hostaliases-pod.yaml
-pod "hostaliases-pod" created
+kubectl apply -f hostaliases-pod.yaml
+```
-$ kubectl get pod -o=wide
+```shell
+pod/hostaliases-pod created
+```
+
+Examine a Pod IP and status:
+
+```shell
+kubectl get pod -o=wide
+```
+
+```shell
NAME READY STATUS RESTARTS AGE IP NODE
-hostaliases-pod 0/1 Completed 0 6s 10.244.135.10 node3
+hostaliases-pod 0/1 Completed 0 6s 10.200.0.5 worker0
```
The `hosts` file content would look like this:
```shell
-$ kubectl logs hostaliases-pod
+kubectl logs hostaliases-pod
+```
+
+```none
# Kubernetes-managed hosts file.
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
@@ -78,7 +104,9 @@ fe00::0 ip6-localnet
fe00::0 ip6-mcastprefix
fe00::1 ip6-allnodes
fe00::2 ip6-allrouters
-10.244.135.10 hostaliases-pod
+10.200.0.5 hostaliases-pod
+
+# Entries added by HostAliases.
127.0.0.1 foo.local
127.0.0.1 bar.local
10.1.2.3 foo.remote
diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md
index 5a2477b23b..d01d2e92cd 100644
--- a/content/en/docs/concepts/services-networking/ingress.md
+++ b/content/en/docs/concepts/services-networking/ingress.md
@@ -97,7 +97,7 @@ In order for the Ingress resource to work, the cluster must have an Ingress cont
* [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)
{{< note >}}
-Review the documentation for your controller to find its specific support policy.
+**Note:** Review the documentation for your controller to find its specific support policy.
{{< /note >}}
## Before you begin
@@ -105,7 +105,7 @@ Review the documentation for your controller to find its specific support policy
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 >}}
-Make sure you review your controller's specific docs so you understand the caveats.
+**Note:** Make sure you review your controller's specific docs so you understand the caveats.
{{< /note >}}
## Types of Ingress
@@ -121,14 +121,16 @@ as well, by specifying a *default backend* with no rules.
If you create it using `kubectl create -f` you should see:
```shell
-$ kubectl get ing
-NAME RULE BACKEND ADDRESS
-test-ingress - testsvc:80 107.178.254.228
+kubectl get ingress test-ingress
+```
+
+```shell
+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. The `RULE` column shows that all traffic sent to the IP are
-directed to the Kubernetes Service listed under `BACKEND`.
+this Ingress.
### Simple fanout
@@ -170,17 +172,36 @@ spec:
When you create the Ingress with `kubectl create -f`:
```shell
-$ kubectl get ing
-NAME RULE BACKEND ADDRESS
-test -
- foo.bar.com
- /foo s1:80
- /bar s2:80
+kubectl describe ingress test
```
+
+```shell
+Name: test
+Namespace: default
+Address: 178.91.123.132
+Default backend: default-http-backend:80 (10.8.2.3:8080)
+Rules:
+ Host Path Backends
+ ---- ---- --------
+ foo.bar.com
+ /foo s1:80 (10.8.0.90:80)
+ /bar s2:80 (10.8.0.91:80)
+Annotations:
+ nginx.ingress.kubernetes.io/rewrite-target: /
+Events:
+ Type Reason Age From Message
+ ---- ------ ---- ---- -------
+ 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.
-When it has done so, you will see the address of the loadbalancer under the
-last column of the Ingress.
+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.
+{{< /note >}}
### Name based virtual hosting
@@ -292,12 +313,29 @@ specific docs to see how they handle health checks (
Say you'd like to add a new Host to an existing Ingress, you can update it by editing the resource:
```shell
-$ kubectl get ing
-NAME RULE BACKEND ADDRESS
-test - 178.91.123.132
- foo.bar.com
- /foo s1:80
-$ kubectl edit ing test
+kubectl describe ingress test
+```
+
+```shell
+Name: test
+Namespace: default
+Address: 178.91.123.132
+Default backend: default-http-backend:80 (10.8.2.3:8080)
+Rules:
+ Host Path Backends
+ ---- ---- --------
+ foo.bar.com
+ /foo s1:80 (10.8.0.90:80)
+Annotations:
+ nginx.ingress.kubernetes.io/rewrite-target: /
+Events:
+ Type Reason Age From Message
+ ---- ------ ---- ---- -------
+ Normal ADD 35s loadbalancer-controller default/test
+```
+
+```shell
+kubectl edit ingress test
```
This should pop up an editor with the existing yaml, modify it to include the new Host:
@@ -325,13 +363,27 @@ spec:
Saving the yaml will update the resource in the API server, which should tell the Ingress controller to reconfigure the loadbalancer.
```shell
-$ kubectl get ing
-NAME RULE BACKEND ADDRESS
-test - 178.91.123.132
- foo.bar.com
- /foo s1:80
- bar.baz.com
- /foo s2:80
+kubectl describe ingress test
+```
+
+```shell
+Name: test
+Namespace: default
+Address: 178.91.123.132
+Default backend: default-http-backend:80 (10.8.2.3:8080)
+Rules:
+ Host Path Backends
+ ---- ---- --------
+ foo.bar.com
+ /foo s1:80 (10.8.0.90:80)
+ bar.baz.com
+ /foo s2:80 (10.8.0.91:80)
+Annotations:
+ nginx.ingress.kubernetes.io/rewrite-target: /
+Events:
+ Type Reason Age From Message
+ ---- ------ ---- ---- -------
+ Normal ADD 45s loadbalancer-controller default/test
```
You can achieve the same by invoking `kubectl replace -f` on a modified Ingress yaml file.
diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md
index 88a8fb9b44..67201bf120 100644
--- a/content/en/docs/concepts/services-networking/service.md
+++ b/content/en/docs/concepts/services-networking/service.md
@@ -124,7 +124,7 @@ subsets:
```
{{< note >}}
-**NOTE** The endpoint IPs may not be loopback (127.0.0.0/8), link-local
+**Note:** 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.
diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md
index f81950f7c2..b3dfb3d3a0 100644
--- a/content/en/docs/concepts/storage/persistent-volumes.md
+++ b/content/en/docs/concepts/storage/persistent-volumes.md
@@ -247,7 +247,7 @@ uses the PVC before the expansion can complete.
* AzureFile
* AzureDisk
* FC (Fibre Channel)
-* FlexVolume
+* Flexvolume
* Flocker
* NFS
* iSCSI
@@ -331,7 +331,7 @@ In the CLI, the access modes are abbreviated to:
| CephFS | ✓ | ✓ | ✓ |
| Cinder | ✓ | - | - |
| FC | ✓ | ✓ | - |
-| FlexVolume | ✓ | ✓ | - |
+| Flexvolume | ✓ | ✓ | - |
| Flocker | ✓ | - | - |
| GCEPersistentDisk | ✓ | ✓ | - |
| Glusterfs | ✓ | ✓ | ✓ |
diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md
index 639de22ed0..ce189c3c51 100644
--- a/content/en/docs/concepts/storage/storage-classes.md
+++ b/content/en/docs/concepts/storage/storage-classes.md
@@ -11,14 +11,12 @@ weight: 30
{{% capture overview %}}
-This document describes the concept of `StorageClass` in Kubernetes. Familiarity
+This document describes the concept of a StorageClass in Kubernetes. Familiarity
with [volumes](/docs/concepts/storage/volumes/) and
[persistent volumes](/docs/concepts/storage/persistent-volumes) is suggested.
{{% /capture %}}
-{{< toc >}}
-
{{% capture body %}}
## Introduction
@@ -72,7 +70,7 @@ for provisioning PVs. This field must be specified.
| CephFS | - | - |
| Cinder | ✓ | [OpenStack Cinder](#openstack-cinder)|
| FC | - | - |
-| FlexVolume | - | - |
+| Flexvolume | - | - |
| Flocker | ✓ | - |
| GCEPersistentDisk | ✓ | [GCE](#gce) |
| Glusterfs | ✓ | [Glusterfs](#glusterfs) |
@@ -140,6 +138,7 @@ parameters:
type: io1
zones: us-east-1d, us-east-1c
iopsPerGB: "10"
+ fsType: ext4
```
* `type`: `io1`, `gp2`, `sc1`, `st1`. See
@@ -157,6 +156,7 @@ parameters:
of the volume and caps it at 20 000 IOPS (maximum supported by AWS, see
[AWS docs](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html).
A string is expected here, i.e. `"10"`, not `10`.
+* `fsType`: fsType that is supported by kubernetes. Default: `"ext4"`.
* `encrypted`: denotes whether the EBS volume should be encrypted or not.
Valid values are `"true"` or `"false"`. A string is expected here,
i.e. `"true"`, not `true`.
@@ -240,13 +240,16 @@ parameters:
parameters are optional, empty password will be used when both
`secretNamespace` and `secretName` are omitted. The provided secret must have
type `"kubernetes.io/glusterfs"`, e.g. created in this way:
- ```
- kubectl create secret generic heketi-secret \
- --type="kubernetes.io/glusterfs" --from-literal=key='opensesame' \
- --namespace=default
- ```
- Example of a secret can be found in
- [glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml).
+
+ ```
+ kubectl create secret generic heketi-secret \
+ --type="kubernetes.io/glusterfs" --from-literal=key='opensesame' \
+ --namespace=default
+ ```
+
+ Example of a secret can be found in
+ [glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml).
+
* `clusterid`: `630372ccdc720a92c681fb928f27b53f` is the ID of the cluster
which will be used by Heketi when provisioning the volume. It can also be a
list of clusterids, for example:
@@ -260,24 +263,22 @@ parameters:
* `volumetype` : The volume type and its parameters can be configured with this
optional value. If the volume type is not mentioned, it's up to the provisioner
to decide the volume type.
- For example:
- 'Replica volume':
- `volumetype: replicate:3` where '3' is replica count.
- 'Disperse/EC volume':
- `volumetype: disperse:4:2` where '4' is data and '2' is the redundancy count.
- 'Distribute volume':
- `volumetype: none`
- For available volume types and administration options, refer to the
-[Administration Guide](https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/part-Overview.html).
+ For example:
+ * Replica volume: `volumetype: replicate:3` where '3' is replica count.
+ * Disperse/EC volume: `volumetype: disperse:4:2` where '4' is data and '2' is the redundancy count.
+ * Distribute volume: `volumetype: none`
- For further reference information, see
-[How to configure Heketi](https://github.com/heketi/heketi/wiki/Setting-up-the-topology).
+ For available volume types and administration options, refer to the
+ [Administration Guide](https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/part-Overview.html).
- When persistent volumes are dynamically provisioned, the Gluster plugin
-automatically creates an endpoint and a headless service in the name
-`gluster-dynamic-`. The dynamic endpoint and service are automatically
-deleted when the persistent volume claim is deleted.
+ For further reference information, see
+ [How to configure Heketi](https://github.com/heketi/heketi/wiki/Setting-up-the-topology).
+
+ When persistent volumes are dynamically provisioned, the Gluster plugin
+ automatically creates an endpoint and a headless service in the name
+ `gluster-dynamic-`. The dynamic endpoint and service are automatically
+ deleted when the persistent volume claim is deleted.
### OpenStack Cinder
@@ -288,39 +289,45 @@ metadata:
name: gold
provisioner: kubernetes.io/cinder
parameters:
- type: fast
availability: nova
```
-* `type`: [VolumeType](https://docs.openstack.org/user-guide/dashboard-manage-volumes.html)
- created in Cinder. Default is empty.
* `availability`: Availability Zone. If not specified, volumes are generally
round-robin-ed across all active zones where Kubernetes cluster has a node.
+{{< note >}}
+{{< feature-state state="deprecated" for_k8s_version="1.11" >}}
+This internal provisioner of OpenStack is deprecated. Please use [the external cloud provider for OpenStack](https://github.com/kubernetes/cloud-provider-openstack).
+{{< /note >}}
+
### vSphere
1. Create a StorageClass with a user specified disk format.
- kind: StorageClass
- apiVersion: storage.k8s.io/v1
- metadata:
- name: fast
- provisioner: kubernetes.io/vsphere-volume
- parameters:
- diskformat: zeroedthick
+ ```yaml
+ kind: StorageClass
+ apiVersion: storage.k8s.io/v1
+ metadata:
+ name: fast
+ provisioner: kubernetes.io/vsphere-volume
+ parameters:
+ diskformat: zeroedthick
+ ```
`diskformat`: `thin`, `zeroedthick` and `eagerzeroedthick`. Default: `"thin"`.
2. Create a StorageClass with a disk format on a user specified datastore.
- kind: StorageClass
- apiVersion: storage.k8s.io/v1
- metadata:
- name: fast
- provisioner: kubernetes.io/vsphere-volume
- parameters:
- diskformat: zeroedthick
- datastore: VSANDatastore
+ ```yaml
+ kind: StorageClass
+ apiVersion: storage.k8s.io/v1
+ metadata:
+ name: fast
+ provisioner: kubernetes.io/vsphere-volume
+ parameters:
+ diskformat: zeroedthick
+ datastore: VSANDatastore
+ ```
`datastore`: The user can also specify the datastore in the StorageClass.
The volume will be created on the datastore specified in the storage class,
@@ -333,31 +340,31 @@ parameters:
* Using existing vCenter SPBM policy
- One of the most important features of vSphere for Storage Management is
- policy based Management. Storage Policy Based Management (SPBM) is a
- storage policy framework that provides a single unified control plane
- across a broad range of data services and storage solutions. SPBM enables
- vSphere administrators to overcome upfront storage provisioning challenges,
- such as capacity planning, differentiated service levels and managing
- capacity headroom.
+ One of the most important features of vSphere for Storage Management is
+ policy based Management. Storage Policy Based Management (SPBM) is a
+ storage policy framework that provides a single unified control plane
+ across a broad range of data services and storage solutions. SPBM enables
+ vSphere administrators to overcome upfront storage provisioning challenges,
+ such as capacity planning, differentiated service levels and managing
+ capacity headroom.
- The SPBM policies can be specified in the StorageClass using the
- `storagePolicyName` parameter.
+ The SPBM policies can be specified in the StorageClass using the
+ `storagePolicyName` parameter.
* Virtual SAN policy support inside Kubernetes
- Vsphere Infrastructure (VI) Admins will have the ability to specify custom
- Virtual SAN Storage Capabilities during dynamic volume provisioning. You
- can now define storage requirements, such as performance and availability,
- in the form of storage capabilities during dynamic volume provisioning.
- The storage capability requirements are converted into a Virtual SAN
- policy which are then pushed down to the Virtual SAN layer when a
- persistent volume (virtual disk) is being created. The virtual disk is
- distributed across the Virtual SAN datastore to meet the requirements.
+ Vsphere Infrastructure (VI) Admins will have the ability to specify custom
+ Virtual SAN Storage Capabilities during dynamic volume provisioning. You
+ can now define storage requirements, such as performance and availability,
+ in the form of storage capabilities during dynamic volume provisioning.
+ The storage capability requirements are converted into a Virtual SAN
+ policy which are then pushed down to the Virtual SAN layer when a
+ persistent volume (virtual disk) is being created. The virtual disk is
+ distributed across the Virtual SAN datastore to meet the requirements.
- You can see [Storage Policy Based Management for dynamic provisioning of volumes](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/policy-based-mgmt.html)
- for more details on how to use storage policies for persistent volumes
- management.
+ You can see [Storage Policy Based Management for dynamic provisioning of volumes](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/policy-based-mgmt.html)
+ for more details on how to use storage policies for persistent volumes
+ management.
There are few
[vSphere examples](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)
@@ -379,6 +386,7 @@ parameters:
pool: kube
userId: kube
userSecretName: ceph-secret-user
+ userSecretNamespace: default
fsType: ext4
imageFormat: "2"
imageFeatures: "layering"
@@ -387,9 +395,9 @@ parameters:
* `monitors`: Ceph monitors, comma delimited. This parameter is required.
* `adminId`: Ceph client ID that is capable of creating images in the pool.
Default is "admin".
-* `adminSecretNamespace`: The namespace for `adminSecret`. Default is "default".
-* `adminSecret`: Secret Name for `adminId`. This parameter is required.
+* `adminSecretName`: Secret Name for `adminId`. This parameter is required.
The provided secret must have type "kubernetes.io/rbd".
+* `adminSecretNamespace`: The namespace for `adminSecretName`. Default is "default".
* `pool`: Ceph RBD pool. Default is "rbd".
* `userId`: Ceph client ID that is used to map the RBD image. Default is the
same as `adminId`.
@@ -397,13 +405,15 @@ parameters:
must exist in the same namespace as PVCs. This parameter is required.
The provided secret must have type "kubernetes.io/rbd", e.g. created in this
way:
- ```
- kubectl create secret generic ceph-secret --type="kubernetes.io/rbd" \
- --from-literal=key='QVFEQ1pMdFhPUnQrSmhBQUFYaERWNHJsZ3BsMmNjcDR6RFZST0E9PQ==' \
- --namespace=kube-system
- ```
+
+ ```shell
+ kubectl create secret generic ceph-secret --type="kubernetes.io/rbd" \
+ --from-literal=key='QVFEQ1pMdFhPUnQrSmhBQUFYaERWNHJsZ3BsMmNjcDR6RFZST0E9PQ==' \
+ --namespace=kube-system
+ ```
+* `userSecretNamespace`: The namespace for `userSecretName`.
* `fsType`: fsType that is supported by kubernetes. Default: `"ext4"`.
-* `imageFormat`: Ceph RBD image format, "1" or "2". Default is "1".
+* `imageFormat`: Ceph RBD image format, "1" or "2". Default is "2".
* `imageFeatures`: This parameter is optional and should only be used if you
set `imageFormat` to "2". Currently supported features are `layering` only.
Default is "", and no features are turned on.
@@ -440,11 +450,13 @@ parameters:
* `adminSecretName`: secret that holds information about the Quobyte user and
the password to authenticate against the API server. The provided secret
must have type "kubernetes.io/quobyte", e.g. created in this way:
- ```
- kubectl create secret generic quobyte-admin-secret \
- --type="kubernetes.io/quobyte" --from-literal=key='opensesame' \
- --namespace=kube-system
- ```
+
+ ```shell
+ kubectl create secret generic quobyte-admin-secret \
+ --type="kubernetes.io/quobyte" --from-literal=key='opensesame' \
+ --namespace=kube-system
+ ```
+
* `user`: maps all access to this user. Default is "root".
* `group`: maps all access to this group. Default is "nfsnobody".
* `quobyteConfig`: use the specified configuration to create the volume. You
@@ -678,4 +690,4 @@ Delaying volume binding allows the scheduler to consider all of a pod's
scheduling constraints when choosing an appropriate PersistentVolume for a
PersistentVolumeClaim.
-{{% /capture %}}
\ No newline at end of file
+{{% /capture %}}
diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md
index 78770a0411..1555e2d6e6 100644
--- a/content/en/docs/concepts/storage/volumes.md
+++ b/content/en/docs/concepts/storage/volumes.md
@@ -756,7 +756,7 @@ spec:
image: busybox
volumeMounts:
- name: token-vol
- mountPath: "/sevice-account"
+ mountPath: "/service-account"
readOnly: true
volumes:
- name: token-vol
@@ -1075,7 +1075,7 @@ spec:
`subPath` directory names can also be constructed from Downward API environment variables.
-Before you use this feature, you must enable the `VolumeSubpathEnvExpansion`feature gate.
+Before you use this feature, you must enable the `VolumeSubpathEnvExpansion` feature gate.
In this example, a Pod uses `subPath` to create a directory `pod1` within the hostPath volume `/var/log/pods`, using the pod name from the Downward API. The host directory `/var/log/pods/pod1` is mounted at `/logs` in the container.
@@ -1120,17 +1120,17 @@ specification, and to select the type of media to use, for clusters that have
several media types.
## Out-of-Tree Volume Plugins
-The Out-of-tree volume plugins include the Container Storage Interface (`CSI`)
-and `FlexVolume`. They enable storage vendors to create custom storage plugins
+The Out-of-tree volume plugins include the Container Storage Interface (CSI)
+and Flexvolume. They enable storage vendors to create custom storage plugins
without adding them to the Kubernetes repository.
-Before the introduction of `CSI` and `FlexVolume`, all volume plugins (like
+Before the introduction of CSI and Flexvolume, all volume plugins (like
volume types listed above) were "in-tree" meaning they were built, linked,
compiled, and shipped with the core Kubernetes binaries and extend the core
Kubernetes API. This meant that adding a new storage system to Kubernetes (a
volume plugin) required checking code into the core Kubernetes code repository.
-Both `CSI` and `FlexVolume` allow volume plugins to be developed independent of
+Both CSI and Flexvolume allow volume plugins to be developed independent of
the Kubernetes code base, and deployed (installed) on Kubernetes clusters as
extensions.
@@ -1177,7 +1177,7 @@ persistent volume:
- `fsType`: If the PV's `VolumeMode` is `Filesystem` then this field may be used
to specify the filesystem that should be used to mount the volume. If the
volume has not been formatted and formatting is supported, this value will be
- used to format the volume. If a value is not specified, `ext4` is assumed.
+ used to format the volume.
This value is passed to the CSI driver via the `VolumeCapability` field of
`ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, and
`NodePublishVolumeRequest`.
@@ -1224,14 +1224,14 @@ Kubernetes component using the following feature gate flags:
Learn how to
[setup your PV/PVC with raw block volume support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support).
-### FlexVolume
+### Flexvolume
-`FlexVolume` is an out-of-tree plugin interface that has existed in Kubernetes
+Flexvolume is an out-of-tree plugin interface that has existed in Kubernetes
since version 1.2 (before CSI). It uses an exec-based model to interface with
-drivers. FlexVolume driver binaries must be installed in a pre-defined volume
+drivers. Flexvolume driver binaries must be installed in a pre-defined volume
plugin path on each node (and in some cases master).
-Pods interact with FlexVolume drivers through the `flexVolume` in-tree plugin.
+Pods interact with Flexvolume drivers through the `flexvolume` in-tree plugin.
More details can be found [here](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md).
## Mount propagation
@@ -1274,7 +1274,7 @@ Its values are:
In addition, all volume mounts created by the Container will be propagated
back to the host and to all Containers of all Pods that use the same volume.
- A typical use case for this mode is a Pod with a `FlexVolume` or `CSI` driver or
+ A typical use case for this mode is a Pod with a Flexvolume or CSI driver or
a Pod that needs to mount something on the host using a `hostPath` volume.
This mode is equal to `rshared` mount propagation as described in the
diff --git a/content/en/docs/concepts/workloads/controllers/cron-jobs.md b/content/en/docs/concepts/workloads/controllers/cron-jobs.md
index abf9096ce2..1c4e53ff95 100644
--- a/content/en/docs/concepts/workloads/controllers/cron-jobs.md
+++ b/content/en/docs/concepts/workloads/controllers/cron-jobs.md
@@ -14,6 +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.
+{{< /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 6a616a1fab..b670d45e06 100644
--- a/content/en/docs/concepts/workloads/controllers/deployment.md
+++ b/content/en/docs/concepts/workloads/controllers/deployment.md
@@ -47,26 +47,24 @@ In this example:
* A Deployment named `nginx-deployment` is created, indicated by the `.metadata.name` field.
* The Deployment creates three replicated Pods, indicated by the `replicas` field.
* The `selector` field defines how the Deployment finds which Pods to manage.
- In this case, we simply select on one label defined in the Pod template (`app: nginx`).
+ In this case, you simply select a label that is defined in the Pod template (`app: nginx`).
However, more sophisticated selection rules are possible,
as long as the Pod template itself satisfies the rule.
-* The Pod template's specification, or `.template.spec` field, indicates that
+
+ {{< note >}}
+ **Note:** `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 >}}
+
+* The `template` field contains the following sub-fields:
+ * The Pods are labeled `app: nginx`using the `labels` field.
+ * The Pod template's specification, or `.template.spec` field, indicates that
the Pods run one container, `nginx`, which runs the `nginx`
[Docker Hub](https://hub.docker.com/) image at version 1.7.9.
-* The Deployment opens port 80 for use by the Pods.
-
-{{< note >}}
-**Note:** `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 >}}
-
-The `template` field contains the following instructions:
-
-* The Pods are labeled `app: nginx`
-* Create one container and name it `nginx`.
-* Run the `nginx` image at version `1.7.9`.
-* Open port `80` so that the container can send and accept traffic.
+ * Create one container and name it `nginx` using the `name` field.
+ * Run the `nginx` image at version `1.7.9`.
+ * Open port `80` so that the container can send and accept traffic.
To create this Deployment, run the following command:
@@ -110,7 +108,7 @@ To see the Deployment rollout status, run `kubectl rollout status deployment/ngi
```shell
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
-deployment "nginx-deployment" successfully rolled out
+deployment.apps/nginx-deployment successfully rolled out
```
Run the `kubectl get deployments` again a few seconds later:
@@ -166,19 +164,19 @@ and in any existing Pods that the ReplicaSet might have.
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 >}}
-Suppose that we now want to update the nginx Pods to use the `nginx:1.9.1` image
+Suppose that you now want to update the nginx Pods to use the `nginx:1.9.1` image
instead of the `nginx:1.7.9` image.
```shell
$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
-deployment "nginx-deployment" image updated
+deployment.extensions/nginx-deployment image updated
```
-Alternatively, we can `edit` the Deployment and change `.spec.template.spec.containers[0].image` from `nginx:1.7.9` to `nginx:1.9.1`:
+Alternatively, you can `edit` the Deployment and change `.spec.template.spec.containers[0].image` from `nginx:1.7.9` to `nginx:1.9.1`:
```shell
$ kubectl edit deployment/nginx-deployment
-deployment "nginx-deployment" edited
+deployment.extensions/nginx-deployment edited
```
To see the rollout status, run:
@@ -186,7 +184,7 @@ To see the rollout status, run:
```shell
$ kubectl rollout status deployment/nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
-deployment "nginx-deployment" successfully rolled out
+deployment.extensions/nginx-deployment successfully rolled out
```
After the rollout succeeds, you may want to `get` the Deployment:
@@ -201,7 +199,7 @@ The number of up-to-date replicas indicates that the Deployment has updated the
The current replicas indicates the total replicas this Deployment manages, and the available replicas indicates the
number of current replicas that are available.
-We can run `kubectl get rs` to see that the Deployment updated the Pods by creating a new ReplicaSet and scaling it
+You can run `kubectl get rs` to see that the Deployment updated the Pods by creating a new ReplicaSet and scaling it
up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
```shell
@@ -221,7 +219,7 @@ nginx-deployment-1564180365-nacti 1/1 Running 0 14s
nginx-deployment-1564180365-z9gth 1/1 Running 0 14s
```
-Next time we want to update these Pods, we only need to update the Deployment's pod template again.
+Next time you want to update these Pods, you only need to update the Deployment's pod template again.
Deployment can ensure that only a certain number of Pods may be down while they are being updated. By
default, it ensures that at least 25% less than the desired number of Pods are up (25% max unavailable).
@@ -274,11 +272,11 @@ Events:
Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0
```
-Here we see that when we first created the Deployment, it created a ReplicaSet (nginx-deployment-2035384211)
-and scaled it up to 3 replicas directly. When we updated the Deployment, it created a new ReplicaSet
+Here you see that when you first created the Deployment, it created a ReplicaSet (nginx-deployment-2035384211)
+and scaled it up to 3 replicas directly. When you updated the Deployment, it created a new ReplicaSet
(nginx-deployment-1564180365) and scaled it up to 1 and then scaled down the old ReplicaSet to 2, so that at
least 2 Pods were available and at most 4 Pods were created at all times. It then continued scaling up and down
-the new and the old ReplicaSet, with the same rolling update strategy. Finally, we'll have 3 available replicas
+the new and the old ReplicaSet, with the same rolling update strategy. Finally, you'll have 3 available replicas
in the new ReplicaSet, and the old ReplicaSet is scaled down to 0.
### Rollover (aka multiple updates in-flight)
@@ -328,16 +326,16 @@ By default, all of the Deployment's rollout history is kept in the system so tha
**Note:** 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 we can facilitate simultaneous manual- or auto-scaling.
+do not create a Deployment revision, so that you can facilitate simultaneous manual- or auto-scaling.
This means that when you roll back to an earlier revision, only the Deployment's pod template part is
rolled back.
{{< /note >}}
-Suppose that we made a typo while updating the Deployment, by putting the image name as `nginx:1.91` instead of `nginx:1.9.1`:
+Suppose that you made a typo while updating the Deployment, by putting the image name as `nginx:1.91` instead of `nginx:1.9.1`:
```shell
$ kubectl set image deployment/nginx-deployment nginx=nginx:1.91
-deployment "nginx-deployment" image updated
+deployment.extensions/nginx-deployment image updated
```
The rollout will be stuck.
@@ -407,7 +405,7 @@ Events:
13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 2
```
-To fix this, we need to rollback to a previous revision of Deployment that is stable.
+To fix this, you need to rollback to a previous revision of Deployment that is stable.
### Checking Rollout History of a Deployment
@@ -422,8 +420,8 @@ REVISION CHANGE-CAUSE
3 kubectl set image deployment/nginx-deployment nginx=nginx:1.91
```
-Because we recorded the command while creating this Deployment using `--record`, we can easily see
-the changes we made in each revision.
+Because you recorded the command while creating this Deployment using `--record`, you can easily see
+the changes you made in each revision.
To further see the details of each revision, run:
@@ -446,18 +444,18 @@ deployments "nginx-deployment" revision 2
### Rolling Back to a Previous Revision
-Now we've decided to undo the current rollout and rollback to the previous revision:
+Now you've decided to undo the current rollout and rollback to the previous revision:
```shell
$ kubectl rollout undo deployment/nginx-deployment
-deployment "nginx-deployment" rolled back
+deployment.extensions/nginx-deployment
```
Alternatively, you can rollback to a specific revision by specify that in `--to-revision`:
```shell
$ kubectl rollout undo deployment/nginx-deployment --to-revision=2
-deployment "nginx-deployment" rolled back
+deployment.extensions/nginx-deployment
```
For more details about rollout related commands, read [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout).
@@ -504,7 +502,7 @@ You can scale a Deployment by using the following command:
```shell
$ kubectl scale deployment nginx-deployment --replicas=10
-deployment "nginx-deployment" scaled
+deployment.apps/nginx-deployment scaled
```
Assuming [horizontal pod autoscaling](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) is enabled
@@ -513,7 +511,7 @@ Pods you want to run based on the CPU utilization of your existing Pods.
```shell
$ kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80
-deployment "nginx-deployment" autoscaled
+deployment.extensions/nginx-deployment scaled
```
### Proportional scaling
@@ -535,11 +533,11 @@ You update to a new image which happens to be unresolvable from inside the clust
```shell
$ kubectl set image deploy/nginx-deployment nginx=nginx:sometag
-deployment "nginx-deployment" image updated
+deployment.extensions/nginx-deployment image updated
```
The image update starts a new rollout with ReplicaSet nginx-deployment-1989198191, but it's blocked due to the
-`maxUnavailable` requirement that we mentioned above.
+`maxUnavailable` requirement that you mentioned above.
```shell
$ kubectl get rs
@@ -549,8 +547,8 @@ nginx-deployment-618515232 8 8 8 1m
```
Then a new scaling request for the Deployment comes along. The autoscaler increments the Deployment replicas
-to 15. The Deployment controller needs to decide where to add these new 5 replicas. If we weren't using
-proportional scaling, all 5 of them would be added in the new ReplicaSet. With proportional scaling, we
+to 15. The Deployment controller needs to decide where to add these new 5 replicas. If you weren't using
+proportional scaling, all 5 of them would be added in the new ReplicaSet. With proportional scaling, you
spread the additional replicas across all ReplicaSets. Bigger proportions go to the ReplicaSets with the
most replicas and lower proportions go to ReplicaSets with less replicas. Any leftovers are added to the
ReplicaSet with the most replicas. ReplicaSets with zero replicas are not scaled up.
@@ -589,14 +587,14 @@ Pause by running the following command:
```shell
$ kubectl rollout pause deployment/nginx-deployment
-deployment "nginx-deployment" paused
+deployment.extensions/nginx-deployment paused
```
Then update the image of the Deployment:
```shell
$ kubectl set image deploy/nginx-deployment nginx=nginx:1.9.1
-deployment "nginx-deployment" image updated
+deployment.extensions/nginx-deployment image updated
```
Notice that no new rollout started:
@@ -616,7 +614,7 @@ You can make as many updates as you wish, for example, update the resources that
```shell
$ kubectl set resources deployment nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
-deployment "nginx-deployment" resource requirements updated
+deployment.extensions/nginx-deployment resource requirements updated
```
The initial state of the Deployment prior to pausing it will continue its function, but new updates to
@@ -626,7 +624,7 @@ Eventually, resume the Deployment and observe a new ReplicaSet coming up with al
```shell
$ kubectl rollout resume deploy/nginx-deployment
-deployment "nginx" resumed
+deployment.extensions/nginx-deployment resumed
$ kubectl get rs -w
NAME DESIRED CURRENT READY AGE
nginx-2142116321 2 2 2 2m
@@ -685,7 +683,7 @@ successfully, `kubectl rollout status` returns a zero exit code.
```shell
$ kubectl rollout status deploy/nginx-deployment
Waiting for rollout to finish: 2 of 3 updated replicas are available...
-deployment "nginx" successfully rolled out
+deployment.extensions/nginx-deployment successfully rolled out
$ echo $?
0
```
@@ -712,7 +710,7 @@ lack of progress for a Deployment after 10 minutes:
```shell
$ kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
-deployment "nginx-deployment" patched
+deployment.extensions/nginx-deployment patched
```
Once the deadline has been exceeded, the Deployment controller adds a DeploymentCondition with the following
attributes to the Deployment's `.status.conditions`:
diff --git a/content/en/docs/concepts/workloads/controllers/garbage-collection.md b/content/en/docs/concepts/workloads/controllers/garbage-collection.md
index 20a28f977b..66ac4a5c58 100644
--- a/content/en/docs/concepts/workloads/controllers/garbage-collection.md
+++ b/content/en/docs/concepts/workloads/controllers/garbage-collection.md
@@ -151,7 +151,7 @@ kubectl delete replicaset my-repset --cascade=false
### Additional note on Deployments
-When using cascading deletes with Deployments you *must* use `propagationPolicy: Foreground`
+Prior to 1.7, When using cascading deletes with Deployments you *must* use `propagationPolicy: Foreground`
to delete not only the ReplicaSets created, but also their Pods. If this type of _propagationPolicy_
is not used, only the ReplicaSets will be deleted, and the Pods will be orphaned.
See [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613) for more information.
diff --git a/content/en/docs/concepts/workloads/controllers/replicaset.md b/content/en/docs/concepts/workloads/controllers/replicaset.md
index ddf97a0e2a..fd72b58149 100644
--- a/content/en/docs/concepts/workloads/controllers/replicaset.md
+++ b/content/en/docs/concepts/workloads/controllers/replicaset.md
@@ -58,7 +58,7 @@ create the defined ReplicaSet and the pods that it manages.
```shell
$ kubectl create -f http://k8s.io/examples/controllers/frontend.yaml
-replicaset "frontend" created
+replicaset.apps/frontend created
$ kubectl describe rs/frontend
Name: frontend
Namespace: default
@@ -155,19 +155,26 @@ If you do not specify `.spec.replicas`, then it defaults to 1.
### Deleting a ReplicaSet and its Pods
-To delete a ReplicaSet and all its pods, use [`kubectl
-delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). Kubectl will scale the ReplicaSet to zero and wait
-for it to delete each pod before deleting the ReplicaSet itself. If this kubectl command is interrupted, it can
-be restarted.
+To delete a ReplicaSet and all of its Pods, use [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). The [Garbage collector](/docs/concepts/workloads/controllers/garbage-collection/) automatically deletes all of the dependent Pods by default.
-When using the REST API or go client library, you need to do the steps explicitly (scale replicas to
-0, wait for pod deletions, then delete the ReplicaSet).
+When using the REST API or the `client-go` library, you must set `propagationPolicy` to `Background` or `Foreground` in delete option. e.g. :
+```shell
+kubectl proxy --port=8080
+curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \
+> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
+> -H "Content-Type: application/json"
+```
### Deleting just a ReplicaSet
-You can delete a ReplicaSet without affecting any of its pods, using [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) with the `--cascade=false` option.
-
-When using the REST API or go client library, simply delete the ReplicaSet object.
+You can delete a ReplicaSet without affecting any of its pods using [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) with the `--cascade=false` option.
+When using the REST API or the `client-go` library, you must set `propagationPolicy` to `Orphan`, e.g. :
+```shell
+kubectl proxy --port=8080
+curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \
+> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
+> -H "Content-Type: application/json"
+```
Once the original is deleted, you can create a new ReplicaSet to replace it. As long
as the old and new `.spec.selector` are the same, then the new one will adopt the old pods.
diff --git a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
index c9e23e5bec..5789b6c3a6 100644
--- a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
@@ -50,7 +50,7 @@ Run the example job by downloading the example file and then running this comman
```shell
$ kubectl create -f https://k8s.io/examples/controllers/replication.yaml
-replicationcontroller "nginx" created
+replicationcontroller/nginx created
```
Check on the status of the ReplicationController using this command:
diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md
index a1fae093ce..3655625bc8 100644
--- a/content/en/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/en/docs/concepts/workloads/controllers/statefulset.md
@@ -143,8 +143,10 @@ Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain
cluster.local | foo/nginx | foo/web | nginx.foo.svc.cluster.local | web-{0..N-1}.nginx.foo.svc.cluster.local | web-{0..N-1} |
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 that Cluster Domain will be set to `cluster.local` unless
+{{< note >}}
+**Note:** Cluster Domain will be set to `cluster.local` unless
[otherwise configured](/docs/concepts/services-networking/dns-pod-service/#how-it-works).
+{{< /note >}}
### Stable Storage
diff --git a/content/en/docs/concepts/workloads/pods/init-containers.md b/content/en/docs/concepts/workloads/pods/init-containers.md
index 267c19d000..4fb114f66c 100644
--- a/content/en/docs/concepts/workloads/pods/init-containers.md
+++ b/content/en/docs/concepts/workloads/pods/init-containers.md
@@ -182,7 +182,7 @@ This Pod can be started and debugged with the following commands:
```shell
$ kubectl create -f myapp.yaml
-pod "myapp-pod" created
+pod/myapp-pod created
$ kubectl get -f myapp.yaml
NAME READY STATUS RESTARTS AGE
myapp-pod 0/1 Init:0/2 0 6m
@@ -228,8 +228,8 @@ complete and the `myapp-pod` is created:
```shell
$ kubectl create -f services.yaml
-service "myservice" created
-service "mydb" created
+service/myservice created
+service/mydb created
$ kubectl get -f myapp.yaml
NAME READY STATUS RESTARTS AGE
myapp-pod 1/1 Running 0 9m
diff --git a/content/en/docs/contribute/advanced.md b/content/en/docs/contribute/advanced.md
index 75ec3b6d5d..1a430d6a7d 100644
--- a/content/en/docs/contribute/advanced.md
+++ b/content/en/docs/contribute/advanced.md
@@ -55,7 +55,7 @@ changes. The quickest way to get answers to questions about how the documentatio
currently works is to ask in the `#sig-docs` Slack channel on
[kubernetes.slack.com](https://kubernetes.slack.com)
-After discussion has taken place and the sig is in agreement about the desired
+After the discussion has taken place and the SIG is in agreement about the desired
outcome, you can work on the proposed changes in the way that is the most
appropriate. For instance, an update to the style guide or the website's
functionality might involve opening a pull request, while a change related to
@@ -67,7 +67,7 @@ SIG Docs [approvers](/docs/contribute/participating/#approvers) can coordinate
docs for a Kubernetes release.
Each Kubernetes release is coordinated by a team of people participating in the
-sig-release special interest group (SIG). Others on the release team for a given
+sig-release Special Interest Group (SIG). Others on the release team for a given
release include an overall release lead, as well as representatives from sig-pm,
sig-testing, and others. To find out more about Kubernetes release processes,
refer to
@@ -80,7 +80,7 @@ The SIG Docs representative for a given release coordinates the following tasks:
for the release, the feature may not be allowed to go into the release.
- Attend sig-release meetings regularly and give updates on the status of the
docs for the release.
-- Review and copyedit feature documentation drafted by the sig responsible for
+- Review and copyedit feature documentation drafted by the SIG responsible for
implementing the feature.
- Merge release-related pull requests and maintain the Git feature branch for
the release.
diff --git a/content/en/docs/contribute/generate-ref-docs/federation-api.md b/content/en/docs/contribute/generate-ref-docs/federation-api.md
index 949948e97b..34365bea76 100644
--- a/content/en/docs/contribute/generate-ref-docs/federation-api.md
+++ b/content/en/docs/contribute/generate-ref-docs/federation-api.md
@@ -47,7 +47,7 @@ go get github.com/kubernetes/federation
Determine the base directory of your local
[kubernetes/federation](https://github.com/kubernetes/federation) repository.
For example, if you followed the preceding step to get the federation source
-code, you base directory is `$GOPATH/src/github.com/kubernetes/federation.`
+code, your base directory is `$GOPATH/src/github.com/kubernetes/federation.`
The remaining steps refer to your base directory as ``.
Run the doc generation script:
diff --git a/content/en/docs/contribute/intermediate.md b/content/en/docs/contribute/intermediate.md
index 3166dcca53..48e986bbfd 100644
--- a/content/en/docs/contribute/intermediate.md
+++ b/content/en/docs/contribute/intermediate.md
@@ -95,10 +95,10 @@ code repositories when it comes to the roles of reviewers and approvers. For
more information about the responsibilities of reviewers and approvers, see
[Participating](/docs/contribute/participating/). Here's an overview.
-- A reviewer reviews pull request content for technical accuracy. A reviewer
+- A reviewer reviews pull request content for technical accuracy. A reviewer
indicates that a PR is technically accurate by leaving a `/lgtm` comment on
- the PR.
-
+ the PR.
+
{{< note >}}Don't add an `/lgtm` unless you are confident in the technical
accuracy of the documentation modified or introduced in the PR.{{< /note >}}
@@ -149,7 +149,7 @@ has signed the CLA.
the main purpose of the PR, such as a typo or whitespace error, you can
call it out, prefixing your comment with `nit:` so that the author knows
you consider it trivial. They should still address it.
- - When you're reviewed everything, or if you didn't have any comments, go
+ - When you've reviewed everything, or if you didn't have any comments, go
back to the top of the page and click **Review changes**. Choose either
**Comment** or **Request Changes**. Add a summary of your review, and
add appropriate
@@ -236,7 +236,7 @@ need to use the command line. You can always use this method, if you prefer it
to the Github UI.
1. Get the URL for the author's fork. You can find it near the bottom of the
- **Conversation** tab. Look for the text "Add more commits by pushing to".
+ **Conversation** tab. Look for the text **Add more commits by pushing to**.
The first link after this phrase is to the branch, and the second link is
to the fork. Copy the second link. Note the name of the branch for later.
@@ -387,7 +387,7 @@ most up-to-date version of that branch.
```
{{< note >}}
-Do not reference a Github issue or pull request by ID or URL in the
+**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.
@@ -427,7 +427,7 @@ link issues and pull requests together later, in the Github UI.
Click **Create pull request**.
8. Several automated tests will run against the state of the website with your
- changes applied. If any of the tests fails, click the **Details** link for
+ changes applied. If any of the tests fail, click the **Details** link for
more information. If the Netlify test completes successfully, its
**Details** link goes to a staged version of the Kubernetes website with
your changes applied. This is how reviewers will check your changes.
@@ -504,6 +504,22 @@ changes look like, you can use the `hugo` command to stage the changes locally.
4. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`
or just close the terminal window.
+Alternatively, you can build the Kubernetes docs using Docker.
+
+1. Build the image locally:
+
+ ```bash
+ make docker-image
+ ```
+
+2. Once the `kubernetes-hugo` image has been built locally, you can build and serve the site:
+
+ ```bash
+ make docker-serve
+ ```
+
+3. In your browser's address bar, enter `localhost:1313`. Hugo will watch the
+filesystem for changes and rebuild the site as needed.
## Triage and categorize issues
@@ -544,7 +560,7 @@ These guidelines are not set in stone and are subject to change.
information in the issue text.
- Some labels are manually added by the person triaging the issue (or the person
reporting the issue, if they are a SIG Docs approvers).
- - `Actionable`: there seems to be enough information for the issue to be fixed
+ - `Actionable`: There seems to be enough information for the issue to be fixed
or acted upon.
- `good first issue`: Someone with limited Kubernetes or SIG Docs experience
might be able to tackle this issue.
diff --git a/content/en/docs/contribute/participating.md b/content/en/docs/contribute/participating.md
index a5fc0bb665..1783bd9aac 100644
--- a/content/en/docs/contribute/participating.md
+++ b/content/en/docs/contribute/participating.md
@@ -93,33 +93,17 @@ in the Kubernetes organization. Follow these steps:
SIG Docs member.
{{< /note >}}
-2. Send an email to the [Kubernetes membership request list](mailto:kubernetes-membership@googlegroups.com)
- and add your two sponsors and any other relevant people to the CC of the
- email. Use the following template.
-
- ```plaintext
- I have joined kubernetes-dev@googlegroups.com and fulfilled all the
- prerequisites outlined at
- https://github.com/kubernetes/community/blob/master/community-membership.md.
+2. Open a Github issue in the `kubernetes/org` repository to request membership.
+ Fill out the template using the guidelines at
+ [Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md).
- Sponsors:
- - Github username / email address
- - Github username / email address
+3. Let your sponsors know about the Github issue, either by at-mentioning them
+ in the Github issue (adding a comment with `@`) or by sending them the link directly,
+ so that they can add a `+1` vote.
- List of contributions:
- - PR URL or other link - description or summary
- - PR URL or other link - description or summary
- - PR URL or other link - description or summary
- - PR URL or other link - description or summary
- - PR URL or other link - description or summary
-
- Thanks for your consideration,
- Your Name
- ```
-
-3. Wait for your sponsors to reply, and be available to answer any questions
- that your sponsors or other Kubernetes leadership has, and for the final
- result of your application.
+4. When your membership is approved, the github admin team member assigned to your request updates the
+ Github issue to show approval and then closes the Github issue.
+ Congratulations, you are now a member!
If for some reason your membership request is not accepted right away, the
membership committee provides information or steps to take before applying
diff --git a/content/en/docs/contribute/start.md b/content/en/docs/contribute/start.md
index 0a18d01644..22dcdae194 100644
--- a/content/en/docs/contribute/start.md
+++ b/content/en/docs/contribute/start.md
@@ -29,7 +29,7 @@ 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, mostly in the
-`/content/en/docs/imported/` subdirectory.
+`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.
@@ -40,8 +40,8 @@ Not all tasks can be done in the Github UI, but these are discussed in the
### Participating in SIG Docs
-The Kubernetes documentation is maintained by a special interest group (SIG)
-called Sig Docs. We communicate using a Slack channel, a mailing list, and
+The Kubernetes documentation is maintained by a Special Interest Group (SIG)
+called SIG Docs. We communicate using a Slack channel, a mailing list, and
weekly video meetings. New participants are welcome. For more information, see
[Participating in SIG Docs](/docs/contribute/participating/).
@@ -145,7 +145,7 @@ because you can do everything using your web browser. When you continue to the
need more background in Git terminology.
{{< note >}}
-**Kubnetes code developers**: If you are documenting a new feature for an
+**Kubernetes code developers**: If you are documenting a new feature for an
upcoming Kubernetes release, your process is a bit different. See
[Document a feature](/docs/contribute/intermediate/#sig-members-documenting-new-features) for
process guidelines and information about deadlines.
@@ -154,8 +154,8 @@ process guidelines and information about deadlines.
### Sign the CLA
Before you can contribute code or documentation to Kubernetes, you **must** read
-the [Contributor guide](/docs/imported/community/guide/) and
-[sign the Contributor License Agreement (CLA)](/docs/imported/community/guide/#sign-the-cla).
+the [Contributor guide](/docs/community/guide/) and
+[sign the Contributor License Agreement (CLA)](/docs/community/guide/#sign-the-cla).
Don't worry -- this doesn't take long!
### Find something to work on
@@ -195,7 +195,7 @@ documentation.
1. On the page where you see the issue, click the pencil icon at the top left.
A new page appears, with some help text.
-2. Click the first blue button, which has the text **Edit **.
+2. Click the first blue button, which has the text **Edit <page name>**.
If you have never created a fork of the Kubernetes documentation
repository, you are prompted to do so. Create the fork under your Github
diff --git a/content/en/docs/contribute/style/content-organization.md b/content/en/docs/contribute/style/content-organization.md
index 526f755f1b..f14a6432ab 100644
--- a/content/en/docs/contribute/style/content-organization.md
+++ b/content/en/docs/contribute/style/content-organization.md
@@ -22,7 +22,7 @@ This site uses Hugo. In Hugo, [content organization](https://gohugo.io/content-m
### Page Order
-The documentation side menu, the documentation page browser etc. are listed using Hugo's default sort order, which sorts by weight (from 1), date (newest first) and finally by the link title.
+The documentation side menu, the documentation page browser etc. are listed using Hugo's default sort order, which sorts by weight (from 1), date (newest first), and finally by the link title.
Given that, if you want to move a page or a section up, set a weight in the page's front matter:
@@ -33,7 +33,7 @@ weight: 10
{{% 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.
+**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.
{{% /note %}}
@@ -57,7 +57,7 @@ linkTitle: Title used in links
{{% 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.
+**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.
{{% /note %}}
### Documentation Side Menu
@@ -66,20 +66,19 @@ The documentation side-bar menu is built from the _current section tree_ startin
It will show all sections and their pages.
-If you want a section or page to not be listed, set the `toc_hide` flag in front matter:
-
+If you don't want to list a section or page, set the `toc_hide` flag to `true` in front matter:
```yaml
toc_hide: true
```
-When you navigate to a section, the page shown is the section page (e.g. `_index.md`) if it has content, else the first page inside that section.
+When you navigate to a section that has content, the specific section or page (e.g. `_index.md`) is shown. Else, the first page inside that section is shown.
### Documentation Browser
-The page browser on the documentation home page is built from all sections and pages directly below the `docs section`.
+The page browser on the documentation home page is built using all the sections and pages that are directly below the `docs section`.
-If you want a section or page to not be listed, set the `toc_hide` flag in front matter:
+If you don't want to list a section or page, set the `toc_hide` flag to `true` in front matter:
```yaml
toc_hide: true
@@ -94,7 +93,7 @@ The site links in the top-right menu -- and also in the footer -- are built by p
In addition to standalone content pages (Markdown files), Hugo supports [Page Bundles](https://gohugo.io/content-management/page-bundles/).
-One example is [Custom Hugo Shortcodes](/docs/contribute/style/hugo-shortcodes/). It is a socalled `leaf bundle`. Everything below the directory with the `index.md` will be part of the bundle, with page-relative links, images can be processed etc.:
+One example is [Custom Hugo Shortcodes](/docs/contribute/style/hugo-shortcodes/). It is considered a `leaf bundle`. Everything below the directory, including the `index.md`, will be part of the bundle. This also includes page-relative links, images that can be processed etc.:
```bash
en/docs/home/contribute/includes
@@ -104,7 +103,7 @@ en/docs/home/contribute/includes
└── podtemplate.json
```
-Another example used widely is the `includes` bundle. It has `headless: true` set in front matter, which means that it does not get its own URL. It is only used in other pages.
+Another widely used example is the `includes` bundle. It sets `headless: true` in front matter, which means that it does not get its own URL. It is only used in other pages.
```bash
en/includes
@@ -123,7 +122,7 @@ Some important notes to the files in the bundles:
* For translated bundles, any missing non-content files will be inherited from languages above. This avoids duplication.
* All the files in a bundle are what Hugo calls `Resources` and you can provide metadata per language, such as parameters and title, even if it does not supports front matter (YAML files etc.). See [Page Resources Metadata](https://gohugo.io/content-management/page-resources/#page-resources-metadata).
-* The value you get from `.RelPermalink` from a `Resource` is page-relative.
+* The value you get from `.RelPermalink` of a `Resource` is page-relative. See [Permalinks](https://gohugo.io/content-management/urls/#permalinks).
## Styles
diff --git a/content/en/docs/contribute/style/hugo-shortcodes/index.md b/content/en/docs/contribute/style/hugo-shortcodes/index.md
index dce517e44e..8d826a4c69 100644
--- a/content/en/docs/contribute/style/hugo-shortcodes/index.md
+++ b/content/en/docs/contribute/style/hugo-shortcodes/index.md
@@ -6,7 +6,7 @@ content_template: templates/concept
---
{{% capture overview %}}
-This page explains the custom Hugo shortcodes that can be used in Kubernetes documentation markdown.
+This page explains the custom Hugo shortcodes that can be used in Kubernetes markdown documentation.
Read more about shortcodes in the [Hugo documentation](https://gohugo.io/content-management/shortcodes).
{{% /capture %}}
@@ -18,7 +18,7 @@ In a markdown page (.md file) on this site, you can add a shortcode to display v
### Feature state demo
-Below is a demo of the feature state snippet. Here it is used to display the feature as stable in Kubernetes version 1.10.
+Below is a demo of the feature state snippet, which displays the feature as stable in Kubernetes version 1.10.
```
{{}}
diff --git a/content/en/docs/contribute/style/page-templates.md b/content/en/docs/contribute/style/page-templates.md
index 97d6398362..db8122a0f9 100644
--- a/content/en/docs/contribute/style/page-templates.md
+++ b/content/en/docs/contribute/style/page-templates.md
@@ -31,7 +31,7 @@ template to use for a new topic, start with the
A concept page explains some aspect of Kubernetes. For example, a concept
page might describe the Kubernetes Deployment object and explain the role it
-plays as an application is deployed, scaled, and updated. Typically, concept
+plays as an application once it is deployed, scaled, and updated. Typically, concept
pages don't include sequences of steps, but instead provide links to tasks or
tutorials.
@@ -59,8 +59,6 @@ To write a new concept page, create a Markdown file in a subdirectory of the
{{%/* /capture */%}}
- {{}}
-
{{%/* capture body */%}}
{{%/* /capture */%}}
@@ -76,7 +74,6 @@ To write a new concept page, create a Markdown file in a subdirectory of the
- Use a minimum of H2 headings (with two leading `#` characters). The sections
themselves are titled automatically by the template.
- For `overview`, use a paragraph to set context for the entire topic.
- - Add the `{{< toc >}}` shortcode to show an in-page table of contents.
- For `body`, explain the concept using free-form Markdown.
- For `whatsnext`, give a bullet list of up to 5 topics the reader might be
interested in reading next.
@@ -116,8 +113,6 @@ To write a new task page, create a Markdown file in a subdirectory of the
{{%/* /capture */%}}
- {{}}
-
{{%/* capture prerequisites */%}}
{{}} {{}}
@@ -143,10 +138,8 @@ To write a new task page, create a Markdown file in a subdirectory of the
- Use a minimum of H2 headings (with two leading `#` characters). The sections
themselves are titled automatically by the template.
- For `overview`, use a paragraph to set context for the entire topic.
- - Add the `{{< toc >}}` shortcode to show an in-page table of contents.
- - For `prerequisites`, use bullet lists when possible. Add additional
- prerequisites below the ones included by the `include` in the example
- above. The default prerequisites include a running Kubernetes cluster.
+ - For `prerequisites`, use bullet lists when possible. Start adding additional
+ prerequisites below the `include`. The default prerequisites include a running Kubernetes cluster.
- For `steps`, use numbered lists.
- For discussion, use normal content to expand upon the information covered
in `steps`.
@@ -190,8 +183,6 @@ To write a new tutorial page, create a Markdown file in a subdirectory of the
{{%/* /capture */%}}
- {{}}
-
{{%/* capture prerequisites */%}}
{{}} {{}}
@@ -220,7 +211,6 @@ To write a new tutorial page, create a Markdown file in a subdirectory of the
- Use a minimum of H2 headings (with two leading `#` characters). The sections
themselves are titled automatically by the template.
- For `overview`, use a paragraph to set context for the entire topic.
- - Add the `{{< toc >}}` shortcode to show an in-page table of contents.
- For `prerequisites`, use bullet lists when possible. Add additional
prerequisites below the ones included by default.
- For `objectives`, use bullet lists.
diff --git a/content/en/docs/contribute/style/style-guide.md b/content/en/docs/contribute/style/style-guide.md
index 402ee0fa98..cd228c0748 100644
--- a/content/en/docs/contribute/style/style-guide.md
+++ b/content/en/docs/contribute/style/style-guide.md
@@ -149,7 +149,9 @@ The output is similar to this:
### Versioning Kubernetes examples
-Code examples and configuration examples that include version information should be consistent with the accompanying text. Identify the Kubernetes version in the **Before you begin** section.
+Code examples and configuration examples that include version information should be consistent with the accompanying text.
+
+If the information is version specific, the Kubernetes version needs to be defined in the `prerequisites` section of the [Task template](/docs/contribute/style/page-templates/#task-template) or the [Tutorial template] (/docs/contribute/style/page-templates/#tutorial-template). Once the page is saved, the `prerequisites` section is shown as **Before you begin**.
To specify the Kubernetes version for a task or tutorial page, include `min-kubernetes-server-version` in the front matter of the page.
@@ -285,6 +287,16 @@ The output is:
1. Bake for 20-25 minutes or until set.
+### Include Statements
+
+Shortcodes inside include statements will break the build. You must insert them in the parent document, before and after you call the include. For example:
+
+```
+{{}}
+{{}}
+{{}}
+```
+
## Content best practices
This section contains suggested best practices for clear, concise, and consistent content.
diff --git a/content/en/docs/contribute/style/write-new-topic.md b/content/en/docs/contribute/style/write-new-topic.md
index 34b3b42b5f..5980b0d24e 100644
--- a/content/en/docs/contribute/style/write-new-topic.md
+++ b/content/en/docs/contribute/style/write-new-topic.md
@@ -17,14 +17,13 @@ Create a fork of the Kubernetes documentation repository as described in
## Choosing a page type
-As you prepare to write a new topic, think about which of these page types
-is the best fit for your content:
+As you prepare to write a new topic, think about the page type that would fit your content the best:
Concept
-
A concept page explains some aspect of Kubernetes. For example, a concept page might describe the Kubernetes Deployment object and explain the role it plays as an application is deployed, scaled, and updated. Typically, concept pages don't include sequences of steps, but instead provide links to tasks or tutorials. For an example of a concept topic, see Nodes.
+
A concept page explains some aspect of Kubernetes. For example, a concept page might describe the Kubernetes Deployment object and explain the role it plays as an application while it is deployed, scaled, and updated. Typically, concept pages don't include sequences of steps, but instead provide links to tasks or tutorials. For an example of a concept topic, see Nodes.
@@ -80,7 +79,7 @@ subdirectory.
## Placing your topic in the table of contents
-The table of contents is built dynamicaly using the directory structure of the
+The table of contents is built dynamically using the directory structure of the
documentation source. The top-level directories under `/content/en/docs/` create
top-level navigation, and subdirectories each have entries in the table of
contents.
@@ -106,7 +105,7 @@ following cases (not an exhaustive list):
- The code is not generic enough for users to try out. As an example, you can
embed the YAML
file for creating a Pod which depends on a specific
- [FlexVolume](/docs/concepts/storage/volumes#flexvolume) implementation.
+ [Flexvolume](/docs/concepts/storage/volumes#flexvolume) implementation.
- The code is an incomplete example because its purpose is to highlight a
portion of a larger file. For example, when describing ways to
customize the [PodSecurityPolicy](/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)
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 7a13f101ca..12a032bbbc 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
@@ -95,7 +95,7 @@ systemctl start docker
```
-## **Test the cluster and flannel configuration**
+## Test the cluster and flannel configuration
Now check the interfaces on the nodes. Notice there is now a flannel.1 interface, and the ip addresses of docker0 and flannel.1 interfaces are in the same network. You will notice that docker0 is assigned a subnet (18.16.29.0/24 as shown below) on each Kubernetes node out of the IP range configured above. A working output should look like this:
diff --git a/content/en/docs/home/_index.md b/content/en/docs/home/_index.md
index c309f2fdb6..504b687f2c 100644
--- a/content/en/docs/home/_index.md
+++ b/content/en/docs/home/_index.md
@@ -8,7 +8,7 @@ cid: userJourneys
css: /css/style_user_journeys.css
js: /js/user-journeys/home.js, https://use.fontawesome.com/4bcc658a89.js
display_browse_numbers: true
-linkTitle: "Documentation"
+linkTitle: "Home"
main_menu: true
-weight: 5
+weight: 10
---
diff --git a/content/en/docs/imported/_index.md b/content/en/docs/imported/_index.md
deleted file mode 100644
index 2c9888d98b..0000000000
--- a/content/en/docs/imported/_index.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title: Imported Docs
----
-
-This section of the Kubernetes documentation surfaces key topics imported from various repos in the broader Kubernetes community for better findability.
-
-## Community
-
-[kubernetes/community](https://github.com/kubernetes/community) is the starting point for becoming a contributor -- improving docs, improving code, giving talks etc.
diff --git a/content/en/docs/imported/community/_index.md b/content/en/docs/imported/community/_index.md
deleted file mode 100755
index 6180924f0b..0000000000
--- a/content/en/docs/imported/community/_index.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: "Community"
-weight: 20
----
-
diff --git a/content/en/docs/reference/_index.md b/content/en/docs/reference/_index.md
index 1821d1ced9..654ab4356c 100644
--- a/content/en/docs/reference/_index.md
+++ b/content/en/docs/reference/_index.md
@@ -1,5 +1,5 @@
---
-title: Reference Documentation
+title: Reference
approvers:
- chenopis
linkTitle: "Reference"
diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md
index 120a309bb4..861f6cd579 100644
--- a/content/en/docs/reference/access-authn-authz/authentication.md
+++ b/content/en/docs/reference/access-authn-authz/authentication.md
@@ -619,8 +619,8 @@ $ kubectl drain mynode
Error from server (Forbidden): User "clark" cannot get nodes at the cluster scope. (get nodes mynode)
$ kubectl drain mynode --as=superman --as-group=system:masters
-node "mynode" cordoned
-node "mynode" drained
+node/mynode cordoned
+node/mynode drained
```
To impersonate a user, group, or set extra fields, the impersonating user must
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 e31299d693..c1399842cc 100644
--- a/content/en/docs/reference/command-line-tools-reference/kubelet.md
+++ b/content/en/docs/reference/command-line-tools-reference/kubelet.md
@@ -552,7 +552,7 @@ kubelet [flags]
diff --git a/content/en/docs/reference/glossary/code-contributor.md b/content/en/docs/reference/glossary/code-contributor.md
index 56d67a946f..982de60304 100755
--- a/content/en/docs/reference/glossary/code-contributor.md
+++ b/content/en/docs/reference/glossary/code-contributor.md
@@ -2,7 +2,7 @@
title: Code Contributor
id: code-contributor
date: 2018-04-12
-full_link: /docs/imported/community/devel/
+full_link: /docs/community/devel/
short_description: >
A person who develops and contributes code to the Kubernetes open source codebase.
diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md
index 28eff23d6b..33300cc84c 100644
--- a/content/en/docs/reference/kubectl/cheatsheet.md
+++ b/content/en/docs/reference/kubectl/cheatsheet.md
@@ -233,7 +233,9 @@ kubectl -n my-ns delete po,svc --all # Dele
```bash
kubectl logs my-pod # dump pod logs (stdout)
+kubectl logs my-pod --previous # dump pod logs (stdout) for a previous instantiation of a container
kubectl logs my-pod -c my-container # dump pod container logs (stdout, multi-container case)
+kubectl logs my-pod -c my-container --previous # dump pod container logs (stdout, multi-container case) for a previous instantiation of a container
kubectl logs -f my-pod # stream pod logs (stdout)
kubectl logs -f my-pod -c my-container # stream pod container logs (stdout, multi-container case)
kubectl run -i --tty busybox --image=busybox -- sh # Run pod as interactive shell
diff --git a/content/en/docs/reference/kubectl/conventions.md b/content/en/docs/reference/kubectl/conventions.md
index 70125b743a..05ae60a048 100644
--- a/content/en/docs/reference/kubectl/conventions.md
+++ b/content/en/docs/reference/kubectl/conventions.md
@@ -12,7 +12,7 @@ reviewers:
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`
-* Specify `--output-version`, because the output forms use a particular API version to output the resource with the exception of `-o name` output form
+* 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`
* Don't rely on context, preferences, or other implicit states.
diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_create.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_create.md
index 15116185ac..d2ea7b1413 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_create.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_create.md
@@ -62,7 +62,7 @@ kubeadm token create [token]
-
--token-ttl duration Default: 24h0m0s
+
--ttl duration Default: 24h0m0s
The duration before the token is automatically deleted (e.g. 1s, 2m, 3h). If set to '0', the token will never expire
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 0c8979b53a..84f0ea3a8c 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
@@ -22,7 +22,7 @@ following steps:
1. Runs a series of pre-flight checks to validate the system state
before making changes. Some checks only trigger warnings, others are
considered errors and will exit kubeadm until the problem is corrected or the
- user specifies `--skip-preflight-checks`.
+ user specifies `--ignore-preflight-errors=`.
1. Generates a self-signed CA (or using an existing one if provided) to set up
identities for each component in the cluster. If the user has provided their
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md
index 2fb25761c6..55f61028f5 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md
@@ -25,6 +25,7 @@ For more version-specific upgrade guidance, see the following resources:
* [1.8.x to 1.9.x upgrades](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-9/)
* [1.9.x to 1.9.y upgrades](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-9/)
* [1.9.x to 1.9.y HA cluster upgrades](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha/)
+ * [1.10 to 1.11 upgrades](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-11/)
In Kubernetes v1.11.0 and later, you can use `kubeadm upgrade diff` to see the changes that would be
applied to static pod manifests.
diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md
index fa86b6fd0c..aac69ea32f 100644
--- a/content/en/docs/reference/using-api/api-concepts.md
+++ b/content/en/docs/reference/using-api/api-concepts.md
@@ -155,7 +155,7 @@ Note that the `resourceVersion` of the list remains constant across each request
## Receiving resources as Tables
`kubectl get` is a simple tabular representation of one or more instances of a particular resource type. In the past, clients were required to reproduce the tabular and describe output implemented in `kubectl` to perform simple lists of objects.
-A few limitations of that approach include non-trivial logic when dealing with certain objects. Additionally, types provided by API aggregation or third party rersources are not known at compile time. This means that generic implementations had to be in place for types unrecognized by a client.
+A few limitations of that approach include non-trivial logic when dealing with certain objects. Additionally, types provided by API aggregation or third party resources are not known at compile time. This means that generic implementations had to be in place for types unrecognized by a client.
In order to avoid potential limitations as described above, clients may request the Table representation of objects, delegating specific details of printing to the server. The Kubernetes API implements standard HTTP content type negotiation: passing an `Accept` header containing a value of `application/json;as=Table;g=meta.k8s.io;v=v1beta1` with a `GET` call will request that the server return objects in the Table content type.
diff --git a/content/en/docs/setup/_index.md b/content/en/docs/setup/_index.md
index 344d013f53..f2cced9b6e 100644
--- a/content/en/docs/setup/_index.md
+++ b/content/en/docs/setup/_index.md
@@ -4,9 +4,9 @@ reviewers:
- erictune
- mikedanese
no_issue: true
+weight: 30
title: Setup
main_menu: true
-weight: 30
---
This section provides instructions for installing Kubernetes and setting
diff --git a/content/en/docs/setup/building-from-source.md b/content/en/docs/setup/building-from-source.md
index 57b7aa2dfd..866d3d7b23 100644
--- a/content/en/docs/setup/building-from-source.md
+++ b/content/en/docs/setup/building-from-source.md
@@ -5,7 +5,7 @@ reviewers:
title: Building from Source
---
-You can either build a release from source or download a pre-built release. If you do not plan on developing Kubernetes itself, we suggest using a pre-built version of the current release, which can be found in the [Release Notes](/docs/imported/release/notes/).
+You can either build a release from source or download a pre-built release. If you do not plan on developing Kubernetes itself, we suggest using a pre-built version of the current release, which can be found in the [Release Notes](/docs/setup/release/notes/).
The Kubernetes source code can be downloaded from the [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) repo.
diff --git a/content/en/docs/setup/certificates.md b/content/en/docs/setup/certificates.md
index 39db59c3e3..3fffec6fcc 100644
--- a/content/en/docs/setup/certificates.md
+++ b/content/en/docs/setup/certificates.md
@@ -45,7 +45,7 @@ If you don't want kubeadm to generate the required certificates, you can create
### Single root CA
-You can create a single root CA, controlled by an adminstrator. This root CA can then create multiple intermediate CAs, and delegate all further creation to Kubernetes itself.
+You can create a single root CA, controlled by an administrator. This root CA can then create multiple intermediate CAs, and delegate all further creation to Kubernetes itself.
Required CAs:
@@ -136,4 +136,4 @@ These files are used as follows:
[kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/
[proxy]: /docs/tasks/access-kubernetes-api/configure-aggregation-layer/
-{{% /capture %}}
\ No newline at end of file
+{{% /capture %}}
diff --git a/content/en/docs/setup/cluster-large.md b/content/en/docs/setup/cluster-large.md
index 1428b105e0..54ca167d92 100644
--- a/content/en/docs/setup/cluster-large.md
+++ b/content/en/docs/setup/cluster-large.md
@@ -3,6 +3,7 @@ reviewers:
- davidopp
- lavalamp
title: Building Large Clusters
+weight: 80
---
## Support
diff --git a/content/en/docs/setup/custom-cloud/_index.md b/content/en/docs/setup/custom-cloud/_index.md
index b31ce1aca8..e675c1a339 100644
--- a/content/en/docs/setup/custom-cloud/_index.md
+++ b/content/en/docs/setup/custom-cloud/_index.md
@@ -1,3 +1,4 @@
---
title: Custom Cloud Solutions
+weight: 50
---
diff --git a/content/en/docs/setup/custom-cloud/coreos.md b/content/en/docs/setup/custom-cloud/coreos.md
index cbd2e5e576..002de6b686 100644
--- a/content/en/docs/setup/custom-cloud/coreos.md
+++ b/content/en/docs/setup/custom-cloud/coreos.md
@@ -2,85 +2,80 @@
title: CoreOS on AWS or GCE
reviewers:
- errordeveloper
+content_template: templates/concept
---
-{{< toc >}}
+{{% capture overview %}}
-There are multiple guides on running Kubernetes with [CoreOS](https://coreos.com/kubernetes/docs/latest/):
+There are multiple guides on running Kubernetes with [CoreOS](https://coreos.com/kubernetes/docs/latest/).
-### Official CoreOS Guides
+{{% /capture %}}
+
+{{% capture body %}}
+
+## Official CoreOS Guides
These guides are maintained by CoreOS and deploy Kubernetes the "CoreOS Way" with full TLS, the DNS add-on, and more. These guides pass Kubernetes conformance testing and we encourage you to [test this yourself](https://coreos.com/kubernetes/docs/latest/conformance-tests.html).
-[**AWS Multi-Node**](https://coreos.com/kubernetes/docs/latest/kubernetes-on-aws.html)
+* [**AWS Multi-Node**](https://coreos.com/kubernetes/docs/latest/kubernetes-on-aws.html)
-Guide and CLI tool for setting up a multi-node cluster on AWS. CloudFormation is used to set up a master and multiple workers in auto-scaling groups.
+ Guide and CLI tool for setting up a multi-node cluster on AWS.
+ CloudFormation is used to set up a master and multiple workers in auto-scaling groups.
-
+* [**Bare Metal Multi-Node**](https://coreos.com/kubernetes/docs/latest/kubernetes-on-baremetal.html#automated-provisioning)
-[**Bare Metal Multi-Node**](https://coreos.com/kubernetes/docs/latest/kubernetes-on-baremetal.html#automated-provisioning)
+ Guide and HTTP/API service for PXE booting and provisioning a multi-node cluster on bare metal.
+ [Ignition](https://coreos.com/ignition/docs/latest/) is used to provision a master and multiple workers on the first boot from disk.
-Guide and HTTP/API service for PXE booting and provisioning a multi-node cluster on bare metal. [Ignition](https://coreos.com/ignition/docs/latest/) is used to provision a master and multiple workers on the first boot from disk.
+* [**Vagrant Multi-Node**](https://coreos.com/kubernetes/docs/latest/kubernetes-on-vagrant.html)
-[**Vagrant Multi-Node**](https://coreos.com/kubernetes/docs/latest/kubernetes-on-vagrant.html)
+ Guide to setting up a multi-node cluster on Vagrant.
+ The deployer can independently configure the number of etcd nodes, master nodes, and worker nodes to bring up a fully HA control plane.
-Guide to setting up a multi-node cluster on Vagrant. The deployer can independently configure the number of etcd nodes, master nodes, and worker nodes to bring up a fully HA control plane.
+* [**Vagrant Single-Node**](https://coreos.com/kubernetes/docs/latest/kubernetes-on-vagrant-single.html)
-
+ The quickest way to set up a Kubernetes development environment locally.
+ As easy as `git clone`, `vagrant up` and configuring `kubectl`.
-[**Vagrant Single-Node**](https://coreos.com/kubernetes/docs/latest/kubernetes-on-vagrant-single.html)
+* [**Full Step by Step Guide**](https://coreos.com/kubernetes/docs/latest/getting-started.html)
-The quickest way to set up a Kubernetes development environment locally. As easy as `git clone`, `vagrant up` and configuring `kubectl`.
+ A generic guide to setting up an HA cluster on any cloud or bare metal, with full TLS.
+ Repeat the master or worker steps to configure more machines of that role.
-
-
-[**Full Step by Step Guide**](https://coreos.com/kubernetes/docs/latest/getting-started.html)
-
-A generic guide to setting up an HA cluster on any cloud or bare metal, with full TLS. Repeat the master or worker steps to configure more machines of that role.
-
-### Community Guides
+## Community Guides
These guides are maintained by community members, cover specific platforms and use cases, and experiment with different ways of configuring Kubernetes on CoreOS.
-[**Easy Multi-node Cluster on Google Compute Engine**](https://github.com/rimusz/coreos-multi-node-k8s-gce/blob/master/README.md)
+* [**Easy Multi-node Cluster on Google Compute Engine**](https://github.com/rimusz/coreos-multi-node-k8s-gce/blob/master/README.md)
-Scripted installation of a single master, multi-worker cluster on GCE. Kubernetes components are managed by [fleet](https://github.com/coreos/fleet).
+ Scripted installation of a single master, multi-worker cluster on GCE.
+ Kubernetes components are managed by [fleet](https://github.com/coreos/fleet).
-
+* [**Multi-node cluster using cloud-config and Weave on Vagrant**](https://github.com/errordeveloper/weave-demos/blob/master/poseidon/README.md)
-[**Multi-node cluster using cloud-config and Weave on Vagrant**](https://github.com/errordeveloper/weave-demos/blob/master/poseidon/README.md)
+ Configure a Vagrant-based cluster of 3 machines with networking provided by Weave.
-Configure a Vagrant-based cluster of 3 machines with networking provided by Weave.
+* [**Multi-node cluster using cloud-config and Vagrant**](https://github.com/pires/kubernetes-vagrant-coreos-cluster/blob/master/README.md)
-
+ Configure a single master, multi-worker cluster locally, running on your choice of hypervisor: VirtualBox, Parallels, or VMware
-[**Multi-node cluster using cloud-config and Vagrant**](https://github.com/pires/kubernetes-vagrant-coreos-cluster/blob/master/README.md)
+* [**Single-node cluster using a small macOS App**](https://github.com/rimusz/kube-solo-osx/blob/master/README.md)
-Configure a single master, multi-worker cluster locally, running on your choice of hypervisor: VirtualBox, Parallels, or VMware
+ Guide to running a solo cluster (master + worker) controlled by an macOS menubar application.
+ Uses xhyve + CoreOS under the hood.
-
+* [**Multi-node cluster with Vagrant and fleet units using a small macOS App**](https://github.com/rimusz/coreos-osx-gui-kubernetes-cluster/blob/master/README.md)
-[**Single-node cluster using a small macOS App**](https://github.com/rimusz/kube-solo-osx/blob/master/README.md)
+ Guide to running a single master, multi-worker cluster controlled by an macOS menubar application.
+ Uses Vagrant under the hood.
-Guide to running a solo cluster (master + worker) controlled by an macOS menubar application. Uses xhyve + CoreOS under the hood.
+* [**Multi-node cluster using cloud-config, CoreOS and VMware ESXi**](https://github.com/xavierbaude/VMware-coreos-multi-nodes-Kubernetes)
-
+ Configure a single master, single worker cluster on VMware ESXi.
-[**Multi-node cluster with Vagrant and fleet units using a small macOS App**](https://github.com/rimusz/coreos-osx-gui-kubernetes-cluster/blob/master/README.md)
+* [**Single/Multi-node cluster using cloud-config, CoreOS and Foreman**](https://github.com/johscheuer/theforeman-coreos-kubernetes)
-Guide to running a single master, multi-worker cluster controlled by an macOS menubar application. Uses Vagrant under the hood.
-
-
-
-[**Multi-node cluster using cloud-config, CoreOS and VMware ESXi**](https://github.com/xavierbaude/VMware-coreos-multi-nodes-Kubernetes)
-
-Configure a single master, single worker cluster on VMware ESXi.
-
-
-
-[**Single/Multi-node cluster using cloud-config, CoreOS and Foreman**](https://github.com/johscheuer/theforeman-coreos-kubernetes)
-
-Configure a standalone Kubernetes or a Kubernetes cluster with [Foreman](https://theforeman.org).
+ Configure a standalone Kubernetes or a Kubernetes cluster with [Foreman](https://theforeman.org).
## Support Level
@@ -91,3 +86,5 @@ GCE | CoreOS | CoreOS | flannel | [docs](/docs/gettin
Vagrant | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/coreos) | | Community ([@pires](https://github.com/pires), [@AntonioMeireles](https://github.com/AntonioMeireles))
For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart.
+
+{{% /capture %}}
diff --git a/content/en/docs/setup/custom-cloud/kops.md b/content/en/docs/setup/custom-cloud/kops.md
index 0ce7f547fc..f10985682f 100644
--- a/content/en/docs/setup/custom-cloud/kops.md
+++ b/content/en/docs/setup/custom-cloud/kops.md
@@ -1,8 +1,9 @@
---
title: Installing Kubernetes on AWS with kops
+content_template: templates/concept
---
-## Overview
+{{% capture overview %}}
This quickstart shows you how to easily install a Kubernetes cluster on AWS.
It uses a tool called [`kops`](https://github.com/kubernetes/kops).
@@ -19,6 +20,10 @@ kops is an opinionated provisioning system:
If your opinions differ from these you may prefer to build your own cluster using [kubeadm](/docs/admin/kubeadm/) as
a building block. kops builds on the kubeadm work.
+{{% /capture %}}
+
+{{% capture body %}}
+
## Creating a cluster
### (1/5) Install kops
@@ -33,7 +38,7 @@ Download kops from the [releases page](https://github.com/kubernetes/kops/releas
On macOS:
-```
+```shell
curl -OL https://github.com/kubernetes/kops/releases/download/1.10.0/kops-darwin-amd64
chmod +x kops-darwin-amd64
mv kops-darwin-amd64 /usr/local/bin/kops
@@ -43,7 +48,7 @@ brew update && brew install kops
On Linux:
-```
+```shell
wget https://github.com/kubernetes/kops/releases/download/1.10.0/kops-linux-amd64
chmod +x kops-linux-amd64
mv kops-linux-amd64 /usr/local/bin/kops
@@ -149,12 +154,6 @@ for production clusters!
See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to explore other add-ons, including tools for logging, monitoring, network policy, visualization & control of your Kubernetes cluster.
-## What's next
-
-* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/).
-* Learn about `kops` [advanced usage](https://github.com/kubernetes/kops)
-* See the `kops` [docs](https://github.com/kubernetes/kops) section for tutorials, best practices and advanced configuration options.
-
## Cleanup
* To delete your cluster: `kops delete cluster useast1.dev.example.com --yes`
@@ -164,3 +163,12 @@ See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to expl
* Slack Channel: [#kops-users](https://kubernetes.slack.com/messages/kops-users/)
* [GitHub Issues](https://github.com/kubernetes/kops/issues)
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/user-guide/kubectl-overview/).
+* Learn about `kops` [advanced usage](https://github.com/kubernetes/kops)
+* See the `kops` [docs](https://github.com/kubernetes/kops) section for tutorials, best practices and advanced configuration options.
+
+{{% /capture %}}
diff --git a/content/en/docs/setup/custom-cloud/kubespray.md b/content/en/docs/setup/custom-cloud/kubespray.md
index 2558708220..bdb12744e2 100644
--- a/content/en/docs/setup/custom-cloud/kubespray.md
+++ b/content/en/docs/setup/custom-cloud/kubespray.md
@@ -1,11 +1,12 @@
---
title: Installing Kubernetes On-premises/Cloud Providers with Kubespray
+content_template: templates/concept
---
-## Overview
+{{% capture overview %}}
This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, 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
@@ -15,22 +16,23 @@ Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [in
To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](../kops).
+{{% /capture %}}
+
+{{% capture body %}}
+
## Creating a cluster
-### (1/5) Meet the underlay [requirements](https://github.com/kubernetes-incubator/kubespray#requirements)
+### (1/5) Meet the underlay requirements
-Provision servers with the following requirements:
+Provision servers with the following [requirements](https://github.com/kubernetes-incubator/kubespray#requirements):
-* `Ansible v2.4` (or newer)
-* `Jinja 2.9` (or newer)
-* `python-netaddr` installed on the machine that running Ansible commands
-* Target servers must have access to the Internet in order to pull docker images
-* Target servers are configured to allow IPv4 forwarding
-* Target servers have SSH connectivity ( tcp/22 ) directly to your nodes or through a bastion host/ssh jump box
-* Target servers have a privileged user
-* Your SSH key must be copied to all the servers that are part of your inventory
-* Firewall rules configured properly to allow Ansible and Kubernetes components to communicate
-* If using a cloud provider, you must have the appropriate credentials available and exported as environment variables
+* **Ansible v2.4 (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**
+* **Your ssh key must be copied** to all the servers part of your inventory
+* The **firewalls are not managed**, you'll need to implement your own rules the way you used to. in order to avoid any issue during deployment you should disable your firewall
+* If kubespray is ran from non-root user account, correct privilege escalation method should be configured in the target servers. Then the `ansible_become` flag or command parameters `--become` or `-b` should be specified
Kubespray provides the following utilities to help provision your environment:
@@ -61,12 +63,12 @@ Kubespray customizations can be made to a [variable file](http://docs.ansible.co
Next, deploy your cluster:
Cluster deployment using [ansible-playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment).
-```console
+
+```shell
ansible-playbook -i your/inventory/hosts.ini cluster.yml -b -v \
--private-key=~/.ssh/private_key
```
-
Large deployments (100+ nodes) may require [specific adjustments](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/large-deployments.md) for best results.
### (5/5) Verify the deployment
@@ -86,10 +88,6 @@ You can remove worker nodes from your cluster by running the remove-node playboo
You can upgrade your cluster by running the upgrade-cluster playbook. For more information, see "[Upgrades](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/upgrades.md)".
-## What's next
-
-Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/roadmap.md).
-
## Cleanup
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).
@@ -102,3 +100,11 @@ You can reset your nodes and wipe out all components installed with Kubespray vi
* Slack Channel: [#kubespray](https://kubernetes.slack.com/messages/kubespray/)
* [GitHub Issues](https://github.com/kubernetes-incubator/kubespray/issues)
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/roadmap.md).
+
+{{% /capture %}}
diff --git a/content/en/docs/setup/independent/_index.md b/content/en/docs/setup/independent/_index.md
index d5332e7516..f5698df388 100755
--- a/content/en/docs/setup/independent/_index.md
+++ b/content/en/docs/setup/independent/_index.md
@@ -1,5 +1,5 @@
---
title: "Bootstrapping Clusters with kubeadm"
-weight: 20
+weight: 30
---
diff --git a/content/en/docs/setup/independent/create-cluster-kubeadm.md b/content/en/docs/setup/independent/create-cluster-kubeadm.md
index 846f2944dd..bf64e8c688 100644
--- a/content/en/docs/setup/independent/create-cluster-kubeadm.md
+++ b/content/en/docs/setup/independent/create-cluster-kubeadm.md
@@ -281,8 +281,7 @@ kubectl apply -f https://docs.projectcalico.org/v3.1/getting-started/kubernetes/
{{% /tab %}}
{{% tab name="Flannel" %}}
-For `flannel` to work correctly, `--pod-network-cidr=10.244.0.0/16` has to be passed to `kubeadm init`. Note that `flannel` works on `amd64`, `arm`, `arm64` and `ppc64le`. For it to work on a platform other than
-`amd64`, you must manually download the manifest and replace `amd64` occurrences with your chosen platform.
+For `flannel` to work correctly, you must pass `--pod-network-cidr=10.244.0.0/16` to `kubeadm init`.
Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net.bridge.bridge-nf-call-iptables=1`
to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
@@ -291,6 +290,12 @@ please see [here](https://kubernetes.io/docs/concepts/cluster-administration/net
```shell
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.10.0/Documentation/kube-flannel.yml
```
+Note that `flannel` works on `amd64`, `arm`, `arm64` and `ppc64le`, but until `flannel v0.11.0` is released
+you need to use the following manifest that supports all the architectures:
+
+```shell
+kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/c5d10c8/Documentation/kube-flannel.yml
+```
For more information about `flannel`, see [the CoreOS flannel repository on GitHub
](https://github.com/coreos/flannel).
diff --git a/content/en/docs/setup/independent/high-availability.md b/content/en/docs/setup/independent/high-availability.md
index 1643801b99..28aed06166 100644
--- a/content/en/docs/setup/independent/high-availability.md
+++ b/content/en/docs/setup/independent/high-availability.md
@@ -143,7 +143,7 @@ different configuration.
apiVersion: kubeadm.k8s.io/v1alpha2
kind: MasterConfiguration
- kubernetesVersion: v1.11.0
+ kubernetesVersion: v1.11.x
apiServerCertSANs:
- "LOAD_BALANCER_DNS"
api:
@@ -166,6 +166,8 @@ different configuration.
# This CIDR is a Calico default. Substitute or remove for your CNI provider.
podSubnet: "192.168.0.0/16"
+1. Replace `x` in `kubernetesVersion: v1.11.x` with the latest available version.
+ For example: `kubernetesVersion: v1.11.1`
1. Replace the following variables in the template with the appropriate
values for your cluster:
@@ -224,7 +226,7 @@ done
apiVersion: kubeadm.k8s.io/v1alpha2
kind: MasterConfiguration
- kubernetesVersion: v1.11.0
+ kubernetesVersion: v1.11.x
apiServerCertSANs:
- "LOAD_BALANCER_DNS"
api:
@@ -248,6 +250,9 @@ done
# This CIDR is a calico default. Substitute or remove for your CNI provider.
podSubnet: "192.168.0.0/16"
+1. Replace `x` in `kubernetesVersion: v1.11.x` with the latest available version.
+ For example: `kubernetesVersion: v1.11.1`
+
1. Replace the following variables in the template with the appropriate values for your cluster:
- `LOAD_BALANCER_DNS`
@@ -314,7 +319,7 @@ done
apiVersion: kubeadm.k8s.io/v1alpha2
kind: MasterConfiguration
- kubernetesVersion: v1.11.0
+ kubernetesVersion: v1.11.x
apiServerCertSANs:
- "LOAD_BALANCER_DNS"
api:
@@ -338,6 +343,9 @@ done
# This CIDR is a calico default. Substitute or remove for your CNI provider.
podSubnet: "192.168.0.0/16"
+1. Replace `x` in `kubernetesVersion: v1.11.x` with the latest available version.
+ For example: `kubernetesVersion: v1.11.1`
+
1. Replace the following variables in the template with the appropriate values for your cluster:
- `LOAD_BALANCER_DNS`
@@ -431,7 +439,7 @@ done
apiVersion: kubeadm.k8s.io/v1alpha2
kind: MasterConfiguration
- kubernetesVersion: v1.11.0
+ kubernetesVersion: v1.11.x
apiServerCertSANs:
- "LOAD_BALANCER_DNS"
api:
@@ -449,6 +457,9 @@ done
# This CIDR is a calico default. Substitute or remove for your CNI provider.
podSubnet: "192.168.0.0/16"
+1. Replace `x` in `kubernetesVersion: v1.11.x` with the latest available version.
+ For example: `kubernetesVersion: v1.11.1`
+
1. Replace the following variables in the template with the appropriate values for your cluster:
- `LOAD_BALANCER_DNS`
diff --git a/content/en/docs/setup/independent/install-kubeadm.md b/content/en/docs/setup/independent/install-kubeadm.md
index 2ecc270b32..c80c5aaba2 100644
--- a/content/en/docs/setup/independent/install-kubeadm.md
+++ b/content/en/docs/setup/independent/install-kubeadm.md
@@ -21,7 +21,7 @@ see the [Using kubeadm to Create a Cluster](/docs/setup/independent/create-clust
- RHEL 7
- Fedora 25/26 (best-effort)
- HypriotOS v1.0.1+
- - Container Linux (tested with 1576.4.0)
+ - Container Linux (tested with 1800.6.0)
* 2 GB or more of RAM per machine (any less will leave little room for your apps)
* 2 CPUs or more
* Full network connectivity between all machines in the cluster (public or private network is fine)
@@ -213,6 +213,14 @@ mkdir -p /opt/cni/bin
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-amd64-${CNI_VERSION}.tgz" | tar -C /opt/cni/bin -xz
```
+Install crictl (required for kubeadm / Kubelet Container Runtime Interface (CRI))
+
+```bash
+CRICTL_VERSION="v1.11.1"
+mkdir -p /opt/bin
+curl -L "https://github.com/kubernetes-incubator/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | tar -C /opt/bin -xz
+```
+
Install `kubeadm`, `kubelet`, `kubectl` and add a `kubelet` systemd service:
```bash
diff --git a/content/en/docs/setup/independent/kubelet-integration.md b/content/en/docs/setup/independent/kubelet-integration.md
index 80836bdd0e..3a7a8e2595 100644
--- a/content/en/docs/setup/independent/kubelet-integration.md
+++ b/content/en/docs/setup/independent/kubelet-integration.md
@@ -35,9 +35,9 @@ kubelet configurations centrally](#configure-kubelets-using-kubeadm).
The following sections describe patterns to kubelet configuration that are simplified by
using kubeadm, rather than managing the kubelet configuration for each Node manually.
-### Propogating cluster-level configuration to each kubelet
+### Propagating cluster-level configuration to each kubelet
-You can provide the kubelet with default values to be used by `kubelet init` and `kubelet join`
+You can provide the kubelet with default values to be used by `kubeadm init` and `kubeadm join`
commands. Interesting examples include using a different CRI runtime or setting the default subnet
used by services.
@@ -110,7 +110,7 @@ initializing. A kubelet configuration file is also written to `/etc/kubernetes/k
baseline cluster-wide configuration for all kubelets in the cluster. This configuration file
points to the client certificates that allow the kubelet to communicate with the API server. This
addresses the need to
-[propogate cluster-level configuration to each kubelet](#propagating-cluster-level-configuration-to-each-kubelet).
+[propagate cluster-level configuration to each kubelet](#propagating-cluster-level-configuration-to-each-kubelet).
To address the second pattern of
[providing instance-specific configuration details](#providing-instance-specific-configuration-details),
diff --git a/content/en/docs/setup/independent/troubleshooting-kubeadm.md b/content/en/docs/setup/independent/troubleshooting-kubeadm.md
index 4ba8688e6c..481b429e02 100644
--- a/content/en/docs/setup/independent/troubleshooting-kubeadm.md
+++ b/content/en/docs/setup/independent/troubleshooting-kubeadm.md
@@ -15,7 +15,7 @@ If your problem is not listed below, please follow the following steps:
- Go to [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues) and search for existing issues.
- If no issue exists, please [open one](https://github.com/kubernetes/kubeadm/issues/new) and follow the issue template.
-- If you are unsure about how kubeadm works, you can ask on Slack in #kubeadm, or open a question on StackOverflow. Please include
+- If you are unsure about how kubeadm works, you can ask on [Slack](http://slack.k8s.io/) in #kubeadm, or open a question on [StackOverflow](https://stackoverflow.com/questions/tagged/kubernetes). Please include
relevant tags like `#kubernetes` and `#kubeadm` so folks can help you.
{{% /capture %}}
@@ -238,4 +238,25 @@ EOF
)"
```
-{{% /capture %}}
\ No newline at end of file
+
+## `coredns` pods have `CrashLoopBackOff` or `Error` state
+
+If you have nodes that are running SELinux with an older version of Docker you might experience a scenario
+where the `coredns` pods are not starting. To solve that you can try one of the following options:
+
+- Upgrade to a [newer version of Docker](/docs/setup/independent/install-kubeadm/#installing-docker).
+- [Disable SELinux](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-enabling_and_disabling_selinux-disabling_selinux).
+- Modify the `coredns` deployment to set `allowPrivilegeEscalation` to `true`:
+
+```bash
+kubectl -n kube-system get deployment coredns -o yaml | \
+ sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
+ kubectl apply -f -
+```
+
+{{< warning >}}
+**Warning**: Disabling SELinux or setting `allowPrivilegeEscalation` to `true` can compromise
+the security of your cluster.
+{{< /warning >}}
+
+{{% /capture %}}
diff --git a/content/en/docs/setup/minikube.md b/content/en/docs/setup/minikube.md
index 7835ed8b1a..9ae0b34c24 100644
--- a/content/en/docs/setup/minikube.md
+++ b/content/en/docs/setup/minikube.md
@@ -17,7 +17,7 @@ Minikube is a tool that makes it easy to run Kubernetes locally. Minikube runs a
* NodePorts
* ConfigMaps and Secrets
* Dashboards
- * Container Runtime: Docker, [rkt](https://github.com/rkt/rkt) and [CRI-O](https://github.com/kubernetes-incubator/cri-o)
+ * Container Runtime: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://github.com/kubernetes-incubator/cri-o) and [containerd](https://github.com/containerd/containerd)
* Enabling CNI (Container Network Interface)
* Ingress
@@ -80,6 +80,28 @@ Stopping "minikube"...
### Alternative Container Runtimes
+#### containerd
+
+To use [containerd](https://github.com/containerd/containerd) as the container runtime, run:
+
+```bash
+$ minikube start \
+ --network-plugin=cni \
+ --container-runtime=containerd \
+ --bootstrapper=kubeadm
+```
+
+Or you can use the extended version:
+
+```bash
+$ minikube start \
+ --network-plugin=cni \
+ --extra-config=kubelet.container-runtime=remote \
+ --extra-config=kubelet.container-runtime-endpoint=unix:///run/containerd/containerd.sock \
+ --extra-config=kubelet.image-service-endpoint=unix:///run/containerd/containerd.sock \
+ --bootstrapper=kubeadm
+```
+
#### CRI-O
To use [CRI-O](https://github.com/kubernetes-incubator/cri-o) as the container runtime, run:
@@ -225,7 +247,7 @@ Starting the cluster again will restore it to it's previous state.
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.
-## Interacting With your Cluster
+## Interacting with Your Cluster
### Kubectl
@@ -347,7 +369,7 @@ $ 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://redspread.com/)) for running the cluster.
+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.
For more information about minikube, see the [proposal](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md).
diff --git a/content/en/docs/setup/multiple-zones.md b/content/en/docs/setup/multiple-zones.md
index fb6c313fca..2a9c097cb1 100644
--- a/content/en/docs/setup/multiple-zones.md
+++ b/content/en/docs/setup/multiple-zones.md
@@ -4,6 +4,7 @@ reviewers:
- justinsb
- quinton-hoole
title: Running in Multiple Zones
+weight: 90
---
## Introduction
diff --git a/content/en/docs/setup/on-premises-vm/_index.md b/content/en/docs/setup/on-premises-vm/_index.md
index d824259ab6..96054a37cd 100644
--- a/content/en/docs/setup/on-premises-vm/_index.md
+++ b/content/en/docs/setup/on-premises-vm/_index.md
@@ -1,3 +1,4 @@
---
title: On-Premises VMs
+weight: 60
---
diff --git a/content/en/docs/setup/pick-right-solution.md b/content/en/docs/setup/pick-right-solution.md
index 331202dbfa..7e23fade56 100644
--- a/content/en/docs/setup/pick-right-solution.md
+++ b/content/en/docs/setup/pick-right-solution.md
@@ -4,6 +4,7 @@ reviewers:
- erictune
- mikedanese
title: Picking the Right Solution
+weight: 10
content_template: templates/concept
---
@@ -47,7 +48,7 @@ a Kubernetes cluster from scratch.
* [Amazon Elastic Container Service for Kubernetes](https://aws.amazon.com/eks/) offers managed Kubernetes service.
-* [Azure Container Service](https://azure.microsoft.com/services/container-service/) offers managed Kubernetes clusters.
+* [Azure Kubernetes Service](https://azure.microsoft.com/services/container-service/) offers managed Kubernetes clusters.
* [Stackpoint.io](https://stackpoint.io) provides Kubernetes infrastructure automation and management for multiple public clouds.
@@ -61,14 +62,12 @@ a Kubernetes cluster from scratch.
* [OpenShift Online](https://www.openshift.com/features/) provides free hosted access for Kubernetes applications.
-* [IBM Cloud Container Service](https://console.bluemix.net/docs/containers/container_index.html) offers managed Kubernetes clusters with isolation choice, operational tools, integrated security insight into images and containers, and integration with Watson, IoT, and data.
+* [IBM Cloud Kubernetes Service](https://console.bluemix.net/docs/containers/container_index.html) offers managed Kubernetes clusters with isolation choice, operational tools, integrated security insight into images and containers, and integration with Watson, IoT, and data.
* [Giant Swarm](https://giantswarm.io/product/) offers managed Kubernetes clusters in their own datacenter, on-premises, or on public clouds.
* [Kubermatic](https://www.loodse.com) provides managed Kubernetes clusters for various public clouds, including AWS and Digital Ocean, as well as on-premises with OpenStack integration.
-* [Pivotal Container Service](https://pivotal.io/platform/pivotal-container-service) provides enterprise-grade Kubernetes for both on-premises and public clouds. PKS enables on-demand provisioning of Kubernetes clusters, multi-tenancy and fully automated day-2 operations.
-
* [Oracle Container Engine for Kubernetes](https://docs.us-phoenix-1.oraclecloud.com/Content/ContEng/Concepts/contengoverview.htm) is a fully-managed, scalable, and highly available service that you can use to deploy your containerized applications to the cloud.
* [Kublr](https://kublr.com) offers enterprise-grade secure, scalable, highly reliable Kubernetes clusters on AWS, Azure, GCP, and on-premise. It includes out-of-the-box backup and disaster recovery, multi-cluster centralized logging and monitoring, and built-in alerting.
@@ -98,6 +97,7 @@ few commands. These solutions are actively developed and have active community s
* [Agile Stacks](https://www.agilestacks.com/products/kubernetes)
* [Alibaba Cloud](/docs/setup/turnkey/alibaba-cloud/)
* [APPUiO](https://appuio.ch)
+* [Pivotal Container Service](https://pivotal.io/platform/pivotal-container-service)
## On-Premises turnkey cloud solutions
These solutions allow you to create Kubernetes clusters on your internal, secure, cloud network with only a
@@ -112,6 +112,7 @@ few commands.
* [Kublr](https://kublr.com/)
* [Agile Stacks](https://www.agilestacks.com/products/kubernetes)
* [APPUiO](https://appuio.ch)
+* [Pivotal Container Service](https://pivotal.io/platform/pivotal-container-service)
## Custom Solutions
@@ -184,7 +185,7 @@ Kublr | custom | multi-support | multi-support | [docs](http://docs.
Kubermatic | | multi-support | multi-support | [docs](http://docs.kubermatic.io/) | Commercial
Giant Swarm | | CoreOS | flannel and/or Calico | [docs](https://docs.giantswarm.io/) | Commercial
GCE | Saltstack | Debian | GCE | [docs](/docs/setup/turnkey/gce/) | Project
-Azure Container Service | | Ubuntu | Azure | [docs](https://azure.microsoft.com/en-us/services/container-service/) | Commercial
+Azure Kubernetes Service | | Ubuntu | Azure | [docs](https://docs.microsoft.com/en-us/azure/aks/) | Commercial
Azure (IaaS) | | Ubuntu | Azure | [docs](/docs/setup/turnkey/azure/) | [Community (Microsoft)](https://github.com/Azure/acs-engine)
Bare-metal | custom | Fedora | _none_ | [docs](/docs/getting-started-guides/fedora/fedora_manual_config/) | Project
Bare-metal | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal))
diff --git a/content/en/docs/imported/release/_index.md b/content/en/docs/setup/release/_index.md
similarity index 78%
rename from content/en/docs/imported/release/_index.md
rename to content/en/docs/setup/release/_index.md
index 5d2ebd4bc2..7187379fee 100755
--- a/content/en/docs/imported/release/_index.md
+++ b/content/en/docs/setup/release/_index.md
@@ -1,5 +1,5 @@
---
title: "Downloading Kubernetes"
-weight: 30
+weight: 20
---
diff --git a/content/en/docs/imported/release/notes.md b/content/en/docs/setup/release/notes.md
similarity index 100%
rename from content/en/docs/imported/release/notes.md
rename to content/en/docs/setup/release/notes.md
diff --git a/content/en/docs/setup/salt.md b/content/en/docs/setup/salt.md
index 1fbedacba3..998504c200 100644
--- a/content/en/docs/setup/salt.md
+++ b/content/en/docs/setup/salt.md
@@ -2,12 +2,20 @@
reviewers:
- davidopp
title: Configuring Kubernetes with Salt
+weight: 70
+content_template: templates/concept
---
+{{% capture overview %}}
+
The Kubernetes cluster can be configured using Salt.
The Salt scripts are shared across multiple hosting providers and depending on where you host your Kubernetes cluster, you may be using different operating systems and different networking configurations. As a result, it's important to understand some background information before making Salt changes in order to minimize introducing failures for other hosting providers.
+{{% /capture %}}
+
+{{% capture body %}}
+
## Salt cluster setup
The **salt-master** service runs on the kubernetes-master [(except on the default GCE and OpenStack-Heat setup)](#standalone-salt-configuration-on-gce-and-others).
@@ -17,7 +25,10 @@ The **salt-minion** service runs on the kubernetes-master and each kubernetes-no
Each salt-minion service is configured to interact with the **salt-master** service hosted on the kubernetes-master via the **master.conf** file [(except on GCE and OpenStack-Heat)](#standalone-salt-configuration-on-gce-and-others).
```shell
-[root@kubernetes-master] $ cat /etc/salt/minion.d/master.conf
+cat /etc/salt/minion.d/master.conf
+```
+
+```none
master: kubernetes-master
```
@@ -38,7 +49,10 @@ All remaining sections that refer to master/minion setups should be ignored for
Security is not enabled on the salt-master, and the salt-master is configured to auto-accept incoming requests from minions. It is not recommended to use this security configuration in production environments without deeper study. (In some environments this isn't as bad as it might sound if the salt master port isn't externally accessible and you trust everyone on your network.)
```shell
-[root@kubernetes-master] $ cat /etc/salt/master.d/auto-accept.conf
+cat /etc/salt/master.d/auto-accept.conf
+```
+
+```shell
open_mode: True
auto_accept: True
```
@@ -50,7 +64,10 @@ Each minion in the salt cluster has an associated configuration that instructs t
An example file is presented below using the Vagrant based environment.
```shell
-[root@kubernetes-master] $ cat /etc/salt/minion.d/grains.conf
+cat /etc/salt/minion.d/grains.conf
+```
+
+```yaml
grains:
etcd_servers: $MASTER_IP
cloud: vagrant
@@ -99,3 +116,5 @@ When configuring default arguments for processes, it's best to avoid the use of
Per pod IP configuration is provider-specific, so when making networking changes, it's important to sandbox these as all providers may not use the same mechanisms (iptables, openvswitch, etc.)
We should define a grains.conf key that captures more specifically what network configuration environment is being used to avoid future confusion across providers.
+
+{{% /capture %}}
diff --git a/content/en/docs/setup/turnkey/_index.md b/content/en/docs/setup/turnkey/_index.md
index da6af45f1f..a5781ada14 100644
--- a/content/en/docs/setup/turnkey/_index.md
+++ b/content/en/docs/setup/turnkey/_index.md
@@ -1,3 +1,4 @@
---
title: Turnkey Cloud Solutions
+weight: 40
---
diff --git a/content/en/docs/setup/turnkey/aws.md b/content/en/docs/setup/turnkey/aws.md
index 128209fb78..9b0b4503ce 100644
--- a/content/en/docs/setup/turnkey/aws.md
+++ b/content/en/docs/setup/turnkey/aws.md
@@ -3,12 +3,20 @@ reviewers:
- justinsb
- clove
title: Running Kubernetes on AWS EC2
+content_template: templates/task
---
-{{< toc >}}
+{{% capture overview %}}
+This page describes how to install a Kubernetes cluster on AWS.
-## Supported Production Grade Tools
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+To create a Kubernetes cluster on AWS, you will need an Access Key ID and a Secret Access Key from AWS.
+
+### Supported Production Grade Tools
* [conjure-up](/docs/getting-started-guides/ubuntu/) is an open-source installer for Kubernetes that creates Kubernetes clusters with native AWS integrations on Ubuntu.
@@ -16,13 +24,15 @@ title: Running Kubernetes on AWS EC2
* [CoreOS Tectonic](https://coreos.com/tectonic/) includes the open-source [Tectonic Installer](https://github.com/coreos/tectonic-installer) that creates Kubernetes clusters with Container Linux nodes on AWS.
-* CoreOS originated and the Kubernetes Incubator maintains [a CLI tool, `kube-aws`](https://github.com/kubernetes-incubator/kube-aws), that creates and manages Kubernetes clusters with [Container Linux](https://coreos.com/why/) nodes, using AWS tools: EC2, CloudFormation and Autoscaling.
+* CoreOS originated and the Kubernetes Incubator maintains [a CLI tool, kube-aws](https://github.com/kubernetes-incubator/kube-aws), that creates and manages Kubernetes clusters with [Container Linux](https://coreos.com/why/) nodes, using AWS tools: EC2, CloudFormation and Autoscaling.
----
+{{% /capture %}}
+
+{{% capture steps %}}
## Getting started with your cluster
-### Command line administration tool: `kubectl`
+### Command line administration tool: kubectl
The cluster startup script will leave you with a `kubernetes` directory on your workstation.
Alternately, you can download the latest Kubernetes release from [this page](https://github.com/kubernetes/kubernetes/releases).
@@ -78,3 +88,5 @@ For support level information on all solutions, see the [Table of solutions](/do
Please see the [Kubernetes docs](/docs/) for more details on administering
and using a Kubernetes cluster.
+
+{{% /capture %}}
diff --git a/content/en/docs/setup/turnkey/clc.md b/content/en/docs/setup/turnkey/clc.md
index e21e5dc052..463787e4c3 100644
--- a/content/en/docs/setup/turnkey/clc.md
+++ b/content/en/docs/setup/turnkey/clc.md
@@ -302,6 +302,7 @@ List existing nodes, pods, services and more, in all namespaces, or in just one:
```shell
kubectl get nodes
+kubectl get --all-namespaces pods
kubectl get --all-namespaces services
kubectl get --namespace=kube-system replicationcontrollers
```
diff --git a/content/en/docs/setup/turnkey/gce.md b/content/en/docs/setup/turnkey/gce.md
index 6c88cad87c..0b9e942b4b 100644
--- a/content/en/docs/setup/turnkey/gce.md
+++ b/content/en/docs/setup/turnkey/gce.md
@@ -5,13 +5,16 @@ reviewers:
- mikedanese
- thockin
title: Running Kubernetes on Google Compute Engine
+content_template: templates/task
---
+{{% capture overview %}}
+
The example below creates a Kubernetes cluster with 4 worker node Virtual Machines and a master Virtual Machine (i.e. 5 VMs in your cluster). This cluster is set up and controlled from your workstation (or wherever you find convenient).
-{{< toc >}}
+{{% /capture %}}
-### Before you start
+{{% capture prerequisites %}}
If you want a simplified getting started experience and GUI for managing clusters, please consider trying [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) for hosted cluster installation and management.
@@ -33,7 +36,11 @@ If you want to use custom binaries or pure open source Kubernetes, please contin
1. Make sure you can start up a GCE VM from the command line. At least make sure you can do the [Create an instance](https://cloud.google.com/compute/docs/instances/#startinstancegcloud) part of the GCE Quickstart.
1. Make sure you can SSH into the VM without interactive prompts. See the [Log in to the instance](https://cloud.google.com/compute/docs/instances/#sshing) part of the GCE Quickstart.
-### Starting a cluster
+{{% /capture %}}
+
+{{% capture steps %}}
+
+## Starting a cluster
You can install a client and start a cluster with either one of these commands (we list both in case only one is installed on your machine):
@@ -73,7 +80,7 @@ The next few steps will show you:
1. How to delete the cluster
1. How to start clusters with non-default options (like larger clusters)
-### Installing the Kubernetes command line tools on your workstation
+## Installing the Kubernetes command line tools on your workstation
The cluster startup script will leave you with a running cluster and a `kubernetes` directory on your workstation.
@@ -84,20 +91,24 @@ up example apps.
You can use `gcloud` to install the `kubectl` command-line tool on your workstation:
- gcloud components install kubectl
+```shell
+gcloud components install kubectl
+```
+{{< note >}}
**Note:** 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 >}}
-### Getting started with your cluster
+## Getting started with your cluster
-#### Inspect your cluster
+### Inspect your cluster
Once `kubectl` is in your path, you can use it to look at your cluster. E.g., running:
```shell
-$ kubectl get --all-namespaces services
+kubectl get --all-namespaces services
```
should show a set of [services](/docs/user-guide/services) that look something like this:
@@ -114,7 +125,7 @@ Similarly, you can take a look at the set of [pods](/docs/user-guide/pods) that
You can do this via the
```shell
-$ kubectl get --all-namespaces pods
+kubectl get --all-namespaces pods
```
command.
@@ -135,13 +146,13 @@ kube-system monitoring-influx-grafana-v1-piled 2/2 Running
Some of the pods may take a few seconds to start up (during this time they'll show `Pending`), but check that they all show as `Running` after a short period.
-#### Run some examples
+### Run some examples
Then, see [a simple nginx example](/docs/user-guide/simple-nginx) to try out your new cluster.
For more complete applications, please look in the [examples directory](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/). The [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) is a good "getting started" walkthrough.
-### Tearing down the cluster
+## Tearing down the cluster
To remove/delete/teardown the cluster, use the `kube-down.sh` script.
@@ -152,7 +163,7 @@ cluster/kube-down.sh
Likewise, the `kube-up.sh` in the same directory will bring it back up. You do not need to rerun the `curl` or `wget` command: everything needed to setup the Kubernetes cluster is now on your workstation.
-### Customizing
+## Customizing
The script above relies on Google Storage to stage the Kubernetes release. It
then will start (by default) a single master VM along with 4 worker VMs. You
@@ -160,9 +171,9 @@ can tweak some of these parameters by editing `kubernetes/cluster/gce/config-def
You can view a transcript of a successful cluster creation
[here](https://gist.github.com/satnam6502/fc689d1b46db9772adea).
-### Troubleshooting
+## Troubleshooting
-#### Project settings
+### Project settings
You need to have the Google Cloud Storage API, and the Google Cloud Storage
JSON API enabled. It is activated by default for new projects. Otherwise, it
@@ -172,13 +183,13 @@ details.
Also ensure that-- as listed in the [Prerequisites section](#prerequisites)-- you've enabled the `Compute Engine Instance Group Manager API`, and can start up a GCE VM from the command line as in the [GCE Quickstart](https://cloud.google.com/compute/docs/quickstart) instructions.
-#### Cluster initialization hang
+### Cluster initialization hang
If the Kubernetes startup script hangs waiting for the API to be reachable, you can troubleshoot by SSHing into the master and node VMs and looking at logs such as `/var/log/startupscript.log`.
**Once you fix the issue, you should run `kube-down.sh` to cleanup** after the partial cluster creation, before running `kube-up.sh` to try again.
-#### SSH
+### SSH
If you're having trouble SSHing into your instances, ensure the GCE firewall
isn't blocking port 22 to your VMs. By default, this should work but if you
@@ -189,7 +200,7 @@ expose it: `gcloud compute firewall-rules create default-ssh --network=}}**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.
+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 ae747d0716..b79dcb02ed 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
@@ -180,7 +180,9 @@ compared to the `service.spec.externalTrafficPolicy` field. The values match as
* "OnlyLocal" for annotation <-> "Local" for field
* "Global" for annotation <-> "Cluster" for field
-**Note that this feature is not currently implemented for all cloudproviders/environments.**
+{{< note >}}
+**Note:** This feature is not currently implemented for all cloudproviders/environments.
+{{< /note >}}
Known issues:
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 59bcc29ac3..36d798fd64 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
@@ -1,5 +1,5 @@
---
-title: Configure the aggregation layer
+title: Configure the Aggregation Layer
reviewers:
- lavalamp
- cheftako
diff --git a/content/en/docs/tasks/access-kubernetes-api/setup-extension-api-server.md b/content/en/docs/tasks/access-kubernetes-api/setup-extension-api-server.md
index b96cd02e0a..f1fdc298d6 100644
--- a/content/en/docs/tasks/access-kubernetes-api/setup-extension-api-server.md
+++ b/content/en/docs/tasks/access-kubernetes-api/setup-extension-api-server.md
@@ -1,5 +1,5 @@
---
-title: Setup an extension API server
+title: Setup an Extension API Server
reviewers:
- lavalamp
- cheftako
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 47423857b8..fbefd3cfcd 100644
--- a/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md
+++ b/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md
@@ -48,7 +48,9 @@ Use a single-node etcd cluster only for testing purpose.
1. Run the following:
- ./etcd --listen-client-urls=http://$PRIVATE_IP:2379 --advertise-client-urls=http://$PRIVATE_IP:2379
+ ```sh
+ ./etcd --listen-client-urls=http://$PRIVATE_IP:2379 --advertise-client-urls=http://$PRIVATE_IP:2379
+ ```
2. Start Kubernetes API server with the flag `--etcd-servers=$PRIVATE_IP:2379`.
@@ -64,8 +66,9 @@ For an example, consider a five-member etcd cluster running with the following c
1. Run the following:
- ./etcd --listen-client-urls=http://$IP1:2379, http://$IP2:2379, http://$IP3:2379, http://$IP4:2379, http://$IP5:2379 --advertise-client-urls=http://$IP1:2379, http://$IP2:2379, http://$IP3:2379, http://$IP4:2379, http://$IP5:2379
-
+ ```sh
+ ./etcd --listen-client-urls=http://$IP1:2379, http://$IP2:2379, http://$IP3:2379, http://$IP4:2379, http://$IP5:2379 --advertise-client-urls=http://$IP1:2379, http://$IP2:2379, http://$IP3:2379, http://$IP4:2379, http://$IP5:2379
+ ```
2. Start Kubernetes API servers with the flag `--etcd-servers=$IP1:2379, $IP2:2379, $IP3:2379, $IP4:2379, $IP5:2379`.
@@ -209,7 +212,7 @@ The upgrade procedure described in this document assumes that either:
{{< warning >}}
**Warning**: 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).
+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 >}}
### Background
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 ddfa22e8dd..d97ad6ebab 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
@@ -22,7 +22,7 @@ Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/getting
## Installing Romana with kubeadm
-Follow the [containerized installation guide](https://github.com/romana/romana/tree/master/containerize) for kubeadmin.
+Follow the [containerized installation guide](https://github.com/romana/romana/tree/master/containerize) for kubeadm.
## Applying network policies
diff --git a/content/en/docs/tasks/administer-federation/cluster.md b/content/en/docs/tasks/administer-federation/cluster.md
index d45aa76f1f..6e350f4b25 100644
--- a/content/en/docs/tasks/administer-federation/cluster.md
+++ b/content/en/docs/tasks/administer-federation/cluster.md
@@ -5,7 +5,9 @@ content_template: templates/task
{{% capture overview %}}
+{{< note >}}
{{< include "federation-current-state.md" >}}
+{{< /note >}}
This guide explains how to use Clusters API resource in a Federation control plane.
diff --git a/content/en/docs/tasks/administer-federation/configmap.md b/content/en/docs/tasks/administer-federation/configmap.md
index 0b597d3fdd..cae4847081 100644
--- a/content/en/docs/tasks/administer-federation/configmap.md
+++ b/content/en/docs/tasks/administer-federation/configmap.md
@@ -5,7 +5,9 @@ content_template: templates/task
{{% capture overview %}}
+{{< note >}}
{{< include "federation-current-state.md" >}}
+{{< /note >}}
This guide explains how to use ConfigMaps in a Federation control plane.
@@ -78,10 +80,9 @@ For example, you can do that using kubectl by running:
kubectl --context=federation-cluster delete configmap
```
-Note that at this point, deleting a Federated ConfigMap will not delete the
-corresponding ConfigMaps from underlying clusters.
-You must delete the underlying ConfigMaps manually.
-We intend to fix this in the future.
+{{< note >}}
+**Note:** 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/daemonset.md b/content/en/docs/tasks/administer-federation/daemonset.md
index 4ff1a24b07..54a04493f6 100644
--- a/content/en/docs/tasks/administer-federation/daemonset.md
+++ b/content/en/docs/tasks/administer-federation/daemonset.md
@@ -5,7 +5,9 @@ content_template: templates/task
{{% capture overview %}}
+{{< note >}}
{{< include "federation-current-state.md" >}}
+{{< /note >}}
This guide explains how to use DaemonSets in a federation control plane.
diff --git a/content/en/docs/tasks/administer-federation/deployment.md b/content/en/docs/tasks/administer-federation/deployment.md
index 4c73ae39aa..829c4290ec 100644
--- a/content/en/docs/tasks/administer-federation/deployment.md
+++ b/content/en/docs/tasks/administer-federation/deployment.md
@@ -5,7 +5,9 @@ content_template: templates/task
{{% capture overview %}}
+{{< note >}}
{{< include "federation-current-state.md" >}}
+{{< /note >}}
This guide explains how to use Deployments in the Federation control plane.
diff --git a/content/en/docs/tasks/administer-federation/events.md b/content/en/docs/tasks/administer-federation/events.md
index 299d36215a..3fd06ce194 100644
--- a/content/en/docs/tasks/administer-federation/events.md
+++ b/content/en/docs/tasks/administer-federation/events.md
@@ -5,7 +5,9 @@ content_template: templates/concept
{{% capture overview %}}
+{{< note >}}
{{< include "federation-current-state.md" >}}
+{{< /note >}}
This guide explains how to use events in federation control plane to help in debugging.
diff --git a/content/en/docs/tasks/administer-federation/hpa.md b/content/en/docs/tasks/administer-federation/hpa.md
index 839b4d04d3..a7862643c3 100644
--- a/content/en/docs/tasks/administer-federation/hpa.md
+++ b/content/en/docs/tasks/administer-federation/hpa.md
@@ -7,7 +7,9 @@ content_template: templates/task
{{< feature-state state="alpha" >}}
+{{< note >}}
{{< include "federation-current-state.md" >}}
+{{< /note >}}
This guide explains how to use federated horizontal pod autoscalers (HPAs) in the federation control plane.
@@ -122,10 +124,10 @@ 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 sending it to a specific Kubernetes cluster.
-It should also be noted that for the federated resource to be deleted from
-all underlying clusters, [cascading deletion](/docs/concepts/cluster-administration/federation/#cascading-deletion)
-should be used.
+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.
+{{< /note >}}
For example, you can do that using `kubectl` by running:
diff --git a/content/en/docs/tasks/administer-federation/ingress.md b/content/en/docs/tasks/administer-federation/ingress.md
index e89ed92dc1..a748a5316e 100644
--- a/content/en/docs/tasks/administer-federation/ingress.md
+++ b/content/en/docs/tasks/administer-federation/ingress.md
@@ -5,7 +5,9 @@ content_template: templates/task
{{% capture overview %}}
+{{< note >}}
{{< include "federation-current-state.md" >}}
+{{< /note >}}
This page explains how to use Kubernetes Federated Ingress to deploy
a common HTTP(S) virtual IP load balancer across a federated service running in
diff --git a/content/en/docs/tasks/administer-federation/job.md b/content/en/docs/tasks/administer-federation/job.md
index 84a234ecd6..4543d756c8 100644
--- a/content/en/docs/tasks/administer-federation/job.md
+++ b/content/en/docs/tasks/administer-federation/job.md
@@ -5,7 +5,9 @@ content_template: templates/task
{{% capture overview %}}
+{{< note >}}
{{< include "federation-current-state.md" >}}
+{{< /note >}}
This guide explains how to use jobs in the federation control plane.
diff --git a/content/en/docs/tasks/administer-federation/namespaces.md b/content/en/docs/tasks/administer-federation/namespaces.md
index 99d3db5d63..2d6a91e926 100644
--- a/content/en/docs/tasks/administer-federation/namespaces.md
+++ b/content/en/docs/tasks/administer-federation/namespaces.md
@@ -5,7 +5,9 @@ content_template: templates/task
{{% capture overview %}}
+{{< note >}}
{{< include "federation-current-state.md" >}}
+{{< /note >}}
This guide explains how to use Namespaces in Federation control plane.
@@ -81,10 +83,9 @@ kubectl --context=federation-cluster delete ns myns
As in Kubernetes, deleting a federated Namespace will delete all resources in that
Namespace from the federation control plane.
-Note that at this point, deleting a federated Namespace will not delete the
-corresponding Namespace and resources in those Namespaces from underlying clusters.
-Users are expected to delete them manually.
-We intend to fix this in the future.
+{{< 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.
+{{< /note >}}
{{% /capture %}}
diff --git a/content/en/docs/tasks/administer-federation/replicaset.md b/content/en/docs/tasks/administer-federation/replicaset.md
index 4e5528c991..7741f8a85c 100644
--- a/content/en/docs/tasks/administer-federation/replicaset.md
+++ b/content/en/docs/tasks/administer-federation/replicaset.md
@@ -5,7 +5,9 @@ content_template: templates/task
{{% capture overview %}}
+{{< note >}}
{{< include "federation-current-state.md" >}}
+{{< /note >}}
This guide explains how to use ReplicaSets in the Federation control plane.
@@ -121,10 +123,9 @@ For example, you can do that using kubectl by running:
kubectl --context=federation-cluster delete rs myrs
```
-Note that 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 >}}
+**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.
+{{< /note >}}
{{% /capture %}}
diff --git a/content/en/docs/tasks/administer-federation/secret.md b/content/en/docs/tasks/administer-federation/secret.md
index 028a1f1624..40feb9a70f 100644
--- a/content/en/docs/tasks/administer-federation/secret.md
+++ b/content/en/docs/tasks/administer-federation/secret.md
@@ -5,7 +5,9 @@ content_template: templates/concept
{{% capture overview %}}
+{{< note >}}
{{< include "federation-current-state.md" >}}
+{{< /note >}}
This guide explains how to use secrets in Federation control plane.
@@ -85,9 +87,8 @@ For example, you can do that using kubectl by running:
kubectl --context=federation-cluster delete secret mysecret
```
-Note that 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 >}}
+**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.
+{{< /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 d6e5d8f896..869df4a098 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
@@ -18,11 +18,11 @@ but is not allowed to use more CPU than its limit.
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-Each node in your cluster must have at least 1 cpu.
+Each node in your cluster must have at least 1 CPU.
A few of the steps on this page require you to run the
[metrics-server](https://github.com/kubernetes-incubator/metrics-server)
-service in your cluster. If you don't have metrics-server
+service in your cluster. If you do not have the metrics-server
running, you can skip those steps.
If you are running minikube, run the following command to enable
@@ -33,7 +33,7 @@ minikube addons enable metrics-server
```
To see whether metrics-server (or another provider of the resource metrics
-API, `metrics.k8s.io`) is running, enter this command:
+API, `metrics.k8s.io`) is running, type the following command:
```shell
kubectl get apiservices
@@ -65,16 +65,14 @@ kubectl create namespace cpu-example
## Specify a CPU request and a CPU limit
To specify a CPU request for a Container, include the `resources:requests` field
-in the Container's resource manifest. To specify a CPU limit, include `resources:limits`.
+in the Container resource manifest. To specify a CPU limit, include `resources:limits`.
-In this exercise, you create a Pod that has one Container. The Container has a CPU
-request of 0.5 cpu and a CPU limit of 1 cpu. Here's the configuration file
-for the Pod:
+In this exercise, you create a Pod that has one Container. The Container has a request of 0.5 CPU and a limit of 1 CPU. Here is the configuration file for the Pod:
{{< codenew file="pods/resource/cpu-request-limit.yaml" >}}
-In the configuration file, the `args` section provides arguments for the Container when it starts.
-The `-cpus "2"` argument tells the Container to attempt to use 2 cpus.
+The `args` section of the configuration file provides arguments for the Container when it starts.
+The `-cpus "2"` argument tells the Container to attempt to use 2 CPUs.
Create the Pod:
@@ -82,7 +80,7 @@ Create the Pod:
kubectl create -f https://k8s.io/examples/pods/resource/cpu-request-limit.yaml --namespace=cpu-example
```
-Verify that the Pod's Container is running:
+Verify that the Pod Container is running:
```shell
kubectl get pod cpu-demo --namespace=cpu-example
@@ -94,8 +92,8 @@ View detailed information about the Pod:
kubectl get pod cpu-demo --output=yaml --namespace=cpu-example
```
-The output shows that the one Container in the Pod has a CPU request of 500 millicpu
-and a CPU limit of 1 cpu.
+The output shows that the one Container in the Pod has a CPU request of 500 milliCPU
+and a CPU limit of 1 CPU.
```yaml
resources:
@@ -111,37 +109,35 @@ Use `kubectl top` to fetch the metrics for the pod:
kubectl top pod cpu-demo --namespace=cpu-example
```
-The output shows that the Pod is using 974 millicpu, which is just a bit less than
-the limit of 1 cpu specified in the Pod's configuration file.
+The output shows that the Pod is using 974 milliCPU, which is just a bit less than
+the limit of 1 CPU specified in the Pod configuration file.
```
NAME CPU(cores) MEMORY(bytes)
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's CPU use is being
-throttled, because the Container is attempting to use more CPU resources than its limit.
+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:** There's another possible explanation for the CPU throttling. The Node might not have
-enough CPU resources available. Recall that the prerequisites for this exercise require that each of
-your Nodes has at least 1 cpu. If your Container is running 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.
+**Note:** 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 ot 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.
{{< /note >}}
## CPU units
-The CPU resource is measured in *cpu* units. One cpu, in Kubernetes, is equivalent to:
+The CPU resource is measured in *CPU* units. One CPU, in Kubernetes, is equivalent to:
* 1 AWS vCPU
* 1 GCP Core
* 1 Azure vCore
* 1 Hyperthread on a bare-metal Intel processor with Hyperthreading
-Fractional values are allowed. A Container that requests 0.5 cpu is guaranteed half as much
-CPU as a Container that requests 1 cpu. You can use the suffix m to mean milli. For example
-100m cpu, 100 millicpu, and 0.1 cpu are all the same. Precision finer than 1m is not allowed.
+Fractional values are allowed. A Container that requests 0.5 CPU is guaranteed half as much
+CPU as a Container that requests 1 CPU. You can use the suffix m to mean milli. For example
+100m CPU, 100 milliCPU, and 0.1 CPU are all the same. Precision finer than 1m is not allowed.
CPU is always requested as an absolute quantity, never as a relative quantity; 0.1 is the same
amount of CPU on a single-core, dual-core, or 48-core machine.
@@ -160,11 +156,11 @@ of the CPU requests for all the Containers in the Pod. Likewise, the CPU limit f
a Pod is the sum of the CPU limits for all the Containers in the Pod.
Pod scheduling is based on requests. A Pod is scheduled to run on a Node only if
-the Node has enough CPU resources available to satisfy the Pod’s CPU request.
+the Node has enough CPU resources available to satisfy the Pod CPU request.
In this exercise, you create a Pod that has a CPU request so big that it exceeds
the capacity of any Node in your cluster. Here is the configuration file for a Pod
-that has one Container. The Container requests 100 cpu, which is likely to exceed the
+that has one Container. The Container requests 100 CPU, which is likely to exceed the
capacity of any Node in your cluster.
{{< codenew file="pods/resource/cpu-request-limit-2.yaml" >}}
@@ -175,13 +171,13 @@ Create the Pod:
kubectl create -f https://k8s.io/examples/pods/resource/cpu-request-limit-2.yaml --namespace=cpu-example
```
-View the Pod's status:
+View the Pod status:
```shell
kubectl get pod cpu-demo-2 --namespace=cpu-example
```
-The output shows that the Pod's status is Pending. That is, the Pod has not been
+The output shows that the Pod status is Pending. That is, the Pod has not been
scheduled to run on any Node, and it will remain in the Pending state indefinitely:
@@ -215,9 +211,9 @@ Delete your Pod:
kubectl delete pod cpu-demo-2 --namespace=cpu-example
```
-## If you don’t specify a CPU limit
+## If you do not specify a CPU limit
-If you don’t specify a CPU limit for a Container, then one of these situations applies:
+If you do not specify a CPU limit for a Container, then one of these situations applies:
* The Container has no upper bound on the CPU resources it can use. The Container
could use all of the CPU resources available on the Node where it is running.
@@ -230,8 +226,8 @@ to specify a default value for the CPU limit.
## Motivation for CPU requests and limits
By configuring the CPU requests and limits of the Containers that run in your
-cluster, you can make efficient use of the CPU resources available on your cluster's
-Nodes. By keeping a Pod's CPU request low, you give the Pod a good chance of being
+cluster, you can make efficient use of the CPU resources available on your cluster
+Nodes. By keeping a Pod CPU request low, you give the Pod a good chance of being
scheduled. By having a CPU limit that is greater than the CPU request, you accomplish two things:
* The Pod can have bursts of activity where it makes use of CPU resources that happen to be available.
diff --git a/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md
index cf14d03915..b8a1c7eb28 100644
--- a/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md
+++ b/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md
@@ -21,28 +21,26 @@ Each node in your cluster must have at least 300 MiB of memory.
A few of the steps on this page require you to run the
[metrics-server](https://github.com/kubernetes-incubator/metrics-server)
-service in your cluster. If you don't have metrics-server
-+running, you can skip those steps.
+service in your cluster. If you do not have the metrics-server
+running, you can skip those steps.
-If you are running minikube, run the following command to enable
+If you are running Minikube, run the following command to enable the
metrics-server:
```shell
minikube addons enable metrics-server
```
-To see whether metrics-server (or another provider of the resource metrics
-API, `metrics.k8s.io`) is running, enter this command:
+To see whether the metrics-server is running, or another provider of the resource metrics
+API (`metrics.k8s.io`), run the following command:
```shell
kubectl get apiservices
```
-If the resource metrics API is available, the output will include a
+If the resource metrics API is available, the output includes a
reference to `metrics.k8s.io`.
-
-
```shell
NAME
v1beta1.metrics.k8s.io
@@ -50,7 +48,6 @@ v1beta1.metrics.k8s.io
{{% /capture %}}
-
{{% capture steps %}}
## Create a namespace
@@ -73,7 +70,7 @@ for the Pod:
{{< codenew file="pods/resource/memory-request-limit.yaml" >}}
-In the configuration file, the `args` section provides arguments for the Container when it starts.
+The `args` section in the configuration file provides arguments for the Container when it starts.
The `"--vm-bytes", "150M"` arguments tell the Container to attempt to allocate 150 MiB of memory.
Create the Pod:
@@ -82,7 +79,7 @@ Create the Pod:
kubectl create -f https://k8s.io/examples/pods/resource/memory-request-limit.yaml --namespace=mem-example
```
-Verify that the Pod's Container is running:
+Verify that the Pod Container is running:
```shell
kubectl get pod memory-demo --namespace=mem-example
@@ -108,7 +105,7 @@ resources:
...
```
-Use `kubectl top` to fetch the metrics for the pod:
+Run `kubectl top` to fetch the metrics for the pod:
```shell
kubectl top pod memory-demo --namespace=mem-example
@@ -129,22 +126,21 @@ Delete your Pod:
kubectl delete pod memory-demo --namespace=mem-example
```
-
## Exceed a Container's memory limit
A Container can exceed its memory request if the Node has memory available. But a Container
is not allowed to use more than its memory limit. If a Container allocates more memory than
its limit, the Container becomes a candidate for termination. If the Container continues to
-consume memory beyond its limit, the Container is terminated. If a terminated Container is
-restartable, the kubelet will restart it, as with any other type of runtime failure.
+consume memory beyond its limit, the Container is terminated. If a terminated Container can be
+restarted, the kubelet restarts it, as with any other type of runtime failure.
In this exercise, you create a Pod that attempts to allocate more memory than its limit.
-Here is the configuration file for a Pod that has one Container. The Container has a
-memory request of 50 MiB and a memory limit of 100 MiB.
+Here is the configuration file for a Pod that has one Container with a
+memory request of 50 MiB and a memory limit of 100 MiB:
{{< codenew file="pods/resource/memory-request-limit-2.yaml" >}}
-In the configuration file, in the `args` section, you can see that the Container
+In the `args` section of the configuration file, you can see that the Container
will attempt to allocate 250 MiB of memory, which is well above the 100 MiB limit.
Create the Pod:
@@ -159,22 +155,20 @@ View detailed information about the Pod:
kubectl get pod memory-demo-2 --namespace=mem-example
```
-At this point, the Container might be running, or it might have been killed. If the
-Container has not yet been killed, repeat the preceding command until you see that
-the Container has been killed:
+At this point, the Container might be running or killed. Repeat the preceding command until the Container is killed:
```shell
NAME READY STATUS RESTARTS AGE
memory-demo-2 0/1 OOMKilled 1 24s
```
-Get a more detailed view of the Container's status:
+Get a more detailed view of the Container status:
```shell
kubectl get pod memory-demo-2 --output=yaml --namespace=mem-example
```
-The output shows that the Container has been killed because it is out of memory (OOM).
+The output shows that the Container was killed because it is out of memory (OOM):
```shell
lastState:
@@ -186,14 +180,14 @@ lastState:
startedAt: null
```
-The Container in this exercise is restartable, so the kubelet will restart it. Enter
-this command several times to see that the Container gets repeatedly killed and restarted:
+The Container in this exercise can be restarted, so the kubelet restarts it. Repeat
+this command several times to see that the Container is repeatedly killed and restarted:
```shell
kubectl get pod memory-demo-2 --namespace=mem-example
```
-The output shows that the Container gets killed, restarted, killed again, restarted again, and so on:
+The output shows that the Container is killed, restarted, killed again, restarted again, and so on:
```
stevepe@sperry-1:~/steveperry-53.github.io$ kubectl get pod memory-demo-2 --namespace=mem-example
@@ -204,8 +198,7 @@ NAME READY STATUS RESTARTS AGE
memory-demo-2 1/1 Running 2 40s
```
-View detailed information about the Pod's history:
-
+View detailed information about the Pod history:
```
kubectl describe pod memory-demo-2 --namespace=mem-example
@@ -213,7 +206,6 @@ kubectl describe pod memory-demo-2 --namespace=mem-example
The output shows that the Container starts and fails repeatedly:
-
```
... Normal Created Created container with id 66a3a20aa7980e61be4922780bf9d24d1a1d8b7395c09861225b0eba1b1f8511
... Warning BackOff Back-off restarting failed container
@@ -221,7 +213,6 @@ The output shows that the Container starts and fails repeatedly:
View detailed information about your cluster's Nodes:
-
```
kubectl describe nodes
```
@@ -250,7 +241,7 @@ has enough available memory to satisfy the Pod's memory request.
In this exercise, you create a Pod that has a memory request so big that it exceeds the
capacity of any Node in your cluster. Here is the configuration file for a Pod that has one
-Container. The Container requests 1000 GiB of memory, which is likely to exceed the capacity
+Container with a request for 1000 GiB of memory, which likely exceeds the capacity
of any Node in your cluster.
{{< codenew file="pods/resource/memory-request-limit-3.yaml" >}}
@@ -261,15 +252,13 @@ Create the Pod:
kubectl create -f https://k8s.io/examples/pods/resource/memory-request-limit-3.yaml --namespace=mem-example
```
-View the Pod's status:
+View the Pod status:
```shell
kubectl get pod memory-demo-3 --namespace=mem-example
```
-The output shows that the Pod's status is PENDING. That is, the Pod has not been
-scheduled to run on any Node, and it will remain in the PENDING state indefinitely:
-
+The output shows that the Pod status is PENDING. That is, the Pod is not scheduled to run on any Node, and it will remain in the PENDING state indefinitely:
```
kubectl get pod memory-demo-3 --namespace=mem-example
@@ -279,14 +268,12 @@ memory-demo-3 0/1 Pending 0 25s
View detailed information about the Pod, including events:
-
```shell
kubectl describe pod memory-demo-3 --namespace=mem-example
```
The output shows that the Container cannot be scheduled because of insufficient memory on the Nodes:
-
```shell
Events:
... Reason Message
@@ -310,9 +297,9 @@ Delete your Pod:
kubectl delete pod memory-demo-3 --namespace=mem-example
```
-## If you don’t specify a memory limit
+## If you do not specify a memory limit
-If you don’t specify a memory limit for a Container, then one of these situations applies:
+If you do not specify a memory limit for a Container, one of the following situations applies:
* The Container has no upper bound on the amount of memory it uses. The Container
could use all of the memory available on the Node where it is running.
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 da9f205286..bb11bc2baa 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
@@ -293,9 +293,9 @@ metadata:
```
-## Define Pod environment variables using ConfigMap data
+## Define container environment variables using ConfigMap data
-### Define a Pod environment variable with data from a single ConfigMap
+### Define a container environment variable with data from a single ConfigMap
1. Define an environment variable as a key-value pair in a ConfigMap:
@@ -333,7 +333,7 @@ metadata:
1. Save the changes to the Pod specification. Now, the Pod's output includes `SPECIAL_LEVEL_KEY=very`.
-### Define Pod environment variables with data from multiple ConfigMaps
+### Define container environment variables with data from multiple ConfigMaps
1. As with the previous example, create the ConfigMaps first.
@@ -385,7 +385,7 @@ metadata:
1. Save the changes to the Pod specification. Now, the Pod's output includes `SPECIAL_LEVEL_KEY=very` and `LOG_LEVEL=info`.
-## Configure all key-value pairs in a ConfigMap as Pod environment variables
+## Configure all key-value pairs in a ConfigMap as container environment variables
{{< note >}}
**Note:** This functionality is available to users running Kubernetes v1.6 and later.
@@ -404,7 +404,7 @@ metadata:
SPECIAL_TYPE: charm
```
-1. Use `envFrom` to define all of the ConfigMap's data as Pod environment variables. The key from the ConfigMap becomes the environment variable name in the Pod.
+1. Use `envFrom` to define all of the ConfigMap's data as container environment variables. The key from the ConfigMap becomes the environment variable name in the Pod.
```yaml
apiVersion: v1
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 bb0f547be7..4065738187 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
@@ -99,7 +99,7 @@ kind: ServiceAccount
metadata:
name: build-robot
EOF
-serviceaccount "build-robot" created
+serviceaccount/build-robot created
```
If you get a complete dump of the service account object, like this:
@@ -151,7 +151,7 @@ metadata:
kubernetes.io/service-account.name: build-robot
type: kubernetes.io/service-account-token
EOF
-secret "build-robot-secret" created
+secret/build-robot-secret created
```
Now you can confirm that the newly built secret is populated with an API token for the "build-robot" service account.
diff --git a/content/en/docs/tasks/configure-pod-container/configure-volume-storage.md b/content/en/docs/tasks/configure-pod-container/configure-volume-storage.md
index b55f0b7eb3..c5c65fa949 100644
--- a/content/en/docs/tasks/configure-pod-container/configure-volume-storage.md
+++ b/content/en/docs/tasks/configure-pod-container/configure-volume-storage.md
@@ -8,12 +8,11 @@ weight: 50
This page shows how to configure a Pod to use a Volume for storage.
-A Container's file system lives only as long as the Container does, so when a
-Container terminates and restarts, changes to the filesystem are lost. For more
+A Container's file system lives only as long as the Container does. So when a
+Container terminates and restarts, filesystem changes are lost. For more
consistent storage that is independent of the Container, you can use a
[Volume](/docs/concepts/storage/volumes/). This is especially important for stateful
-applications, such as key-value stores and databases. For example, Redis is a
-key-value cache and store.
+applications, such as key-value stores (such as Redis) and databases.
{{% /capture %}}
@@ -61,7 +60,7 @@ the Pod:
kubectl exec -it redis -- /bin/bash
```
-1. In your shell, go to `/data/redis`, and create a file:
+1. In your shell, go to `/data/redis`, and then create a file:
```shell
root@redis:/data# cd /data/redis/
@@ -85,15 +84,15 @@ the Pod:
root 15 0.0 0.0 17500 2072 ? R+ 00:48 0:00 ps aux
```
-1. In your shell, kill the redis process:
+1. In your shell, kill the Redis process:
```shell
root@redis:/data/redis# kill
```
- where `` is the redis process ID (PID).
+ where `` is the Redis process ID (PID).
-1. In your original terminal, watch for changes to the redis Pod. Eventually,
+1. In your original terminal, watch for changes to the Redis Pod. Eventually,
you will see something like this:
```shell
@@ -104,7 +103,7 @@ you will see something like this:
```
At this point, the Container has terminated and restarted. This is because the
-redis Pod has a
+Redis Pod has a
[restartPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
of `Always`.
@@ -137,7 +136,7 @@ of `Always`.
* In addition to the local disk storage provided by `emptyDir`, Kubernetes
supports many different network-attached storage solutions, including PD on
-GCE and EBS on EC2, which are preferred for critical data, and will handle
+GCE and EBS on EC2, which are preferred for critical data and will handle
details such as mounting and unmounting the devices on the nodes. See
[Volumes](/docs/concepts/storage/volumes/) for more details.
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 14d44096bc..9062515fa2 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
@@ -45,10 +45,10 @@ kubectl create namespace qos-example
For a Pod to be given a QoS class of Guaranteed:
* Every Container in the Pod must have a memory limit and a memory request, and they must be the same.
-* Every Container in the Pod must have a cpu limit and a cpu request, and they must be the same.
+* Every Container in the Pod must have a CPU limit and a CPU request, and they must be the same.
Here is the configuration file for a Pod that has one Container. The Container has a memory limit and a
-memory request, both equal to 200 MiB. The Container has a cpu limit and a cpu request, both equal to 700 millicpu:
+memory request, both equal to 200 MiB. The Container has a CPU limit and a CPU request, both equal to 700 milliCPU:
{{< codenew file="pods/qos/qos-pod.yaml" >}}
@@ -65,8 +65,8 @@ kubectl get pod qos-demo --namespace=qos-example --output=yaml
```
The output shows that Kubernetes gave the Pod a QoS class of Guaranteed. The output also
-verifies that the Pod's Container has a memory request that matches its memory limit, and it has
-a cpu request that matches its cpu limit.
+verifies that the Pod Container has a memory request that matches its memory limit, and it has
+a CPU request that matches its CPU limit.
```yaml
spec:
@@ -86,7 +86,7 @@ spec:
{{< note >}}
**Note:** 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
+CPU limit, but does not specify a CPU request, Kubernetes automatically assigns a CPU request that matches
the limit.
{{< /note >}}
@@ -101,7 +101,7 @@ kubectl delete pod qos-demo --namespace=qos-example
A Pod is given a QoS class of Burstable if:
* The Pod does not meet the criteria for QoS class Guaranteed.
-* At least one Container in the Pod has a memory or cpu request.
+* At least one Container in the Pod has a memory or CPU request.
Here is the configuration file for a Pod that has one Container. The Container has a memory limit of 200 MiB
and a memory request of 100 MiB.
@@ -146,9 +146,9 @@ kubectl delete pod qos-demo-2 --namespace=qos-example
## Create a Pod that gets assigned a QoS class of BestEffort
For a Pod to be given a QoS class of BestEffort, the Containers in the Pod must not
-have any memory or cpu limits or requests.
+have any memory or CPU limits or requests.
-Here is the configuration file for a Pod that has one Container. The Container has no memory or cpu
+Here is the configuration file for a Pod that has one Container. The Container has no memory or CPU
limits or requests:
{{< codenew file="pods/qos/qos-pod-3.yaml" >}}
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 a31e6c42c4..918a366c1d 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
@@ -150,12 +150,12 @@ you need is an existing `docker-compose.yml` file.
```bash
$ kubectl create -f frontend-service.yaml,redis-master-service.yaml,redis-slave-service.yaml,frontend-deployment.yaml,redis-master-deployment.yaml,redis-slave-deployment.yaml
- service "frontend" created
- service "redis-master" created
- service "redis-slave" created
- deployment "frontend" created
- deployment "redis-master" created
- deployment "redis-slave" created
+ service/frontend created
+ service/redis-master created
+ service/redis-slave created
+ deployment.apps/frontend created
+ deployment.apps/redis-master created
+ deployment.apps/redis-slave created
```
Your deployments are running in Kubernetes.
@@ -320,21 +320,21 @@ INFO Successfully created deployment: frontend
Your application has been deployed to Kubernetes. You can run 'kubectl get deployment,svc,pods' for details.
$ kubectl get deployment,svc,pods
-NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
-deploy/frontend 1 1 1 1 4m
-deploy/redis-master 1 1 1 1 4m
-deploy/redis-slave 1 1 1 1 4m
+NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
+deployment.extensions/frontend 1 1 1 1 4m
+deployment.extensions/redis-master 1 1 1 1 4m
+deployment.extensions/redis-slave 1 1 1 1 4m
-NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
-svc/frontend 10.0.174.12 80/TCP 4m
-svc/kubernetes 10.0.0.1 443/TCP 13d
-svc/redis-master 10.0.202.43 6379/TCP 4m
-svc/redis-slave 10.0.1.85 6379/TCP 4m
+NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+service/frontend ClusterIP 10.0.174.12 80/TCP 4m
+service/kubernetes ClusterIP 10.0.0.1 443/TCP 13d
+service/redis-master ClusterIP 10.0.202.43 6379/TCP 4m
+service/redis-slave ClusterIP 10.0.1.85 6379/TCP 4m
-NAME READY STATUS RESTARTS AGE
-po/frontend-2768218532-cs5t5 1/1 Running 0 4m
-po/redis-master-1432129712-63jn8 1/1 Running 0 4m
-po/redis-slave-2504961300-nve7b 1/1 Running 0 4m
+NAME READY STATUS RESTARTS AGE
+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**:
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 969be001bd..0d9dd609b5 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,9 @@ Alternately, you can run commands inside that container with `exec`:
$ kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
```
-Note that `-c ${CONTAINER_NAME}` is optional and can be omitted 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-pod-replication-controller.md b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
index d59f3a918c..3bbf3eb670 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,8 @@ Alternately, you can run commands inside that container with `exec`:
kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
```
-Note that `-c ${CONTAINER_NAME}` is optional and can be omitted 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 42f52513c6..4b868bbd9a 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-service.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-service.md
@@ -79,8 +79,8 @@ 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 that this is the same as if you had started the `Deployment` with
-the following YAML:
+{{< note >}}
+**Note:** This is the same as if you started the `Deployment` with the following YAML:
```yaml
apiVersion: apps/v1
@@ -104,6 +104,7 @@ spec:
- containerPort: 9376
protocol: TCP
```
+{{< /note >}}
Confirm your `Pods` are running:
@@ -213,8 +214,8 @@ Note the suffix here: "default.svc.cluster.local". The "default" is the
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: 10.0.0.10 is my DNS
-`Service`, yours might be different):
+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 >}}
```shell
u@node$ nslookup hostnames.default.svc.cluster.local 10.0.0.10
@@ -383,8 +384,8 @@ 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 that these commands use the `Pod`
-port (9376), rather than the `Service` port (80).
+mechanism and go straight to the `Pods`.
+{{< note >}}**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/logging-elasticsearch-kibana.md b/content/en/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
index 78ef4bfe8f..ebd03d84d2 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
@@ -15,9 +15,11 @@ in the [Logging With Stackdriver Logging](/docs/user-guide/logging/stackdriver).
This article describes how to set up a cluster to ingest logs into
[Elasticsearch](https://www.elastic.co/products/elasticsearch) and view
them using [Kibana](https://www.elastic.co/products/kibana), as an alternative to
-Stackdriver Logging when running on GCE. Note that Elasticsearch and Kibana
-cannot be setup automatically in the Kubernetes cluster hosted on
-Google Kubernetes Engine, you have to deploy it manually.
+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.
+{{< /note >}}
{{% /capture %}}
@@ -115,4 +117,4 @@ Here is a typical view of ingested logs from the Kibana viewer:
Kibana opens up all sorts of powerful options for exploring your logs! For some
ideas on how to dig into it, check out [Kibana's documentation](https://www.elastic.co/guide/en/kibana/current/discover.html).
-{{% /capture %}}
\ No newline at end of file
+{{% /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 fd6b0bff7d..b9251fc989 100644
--- a/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md
+++ b/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md
@@ -89,9 +89,9 @@ than Google Kubernetes Engine. Proceed at your own risk.
kubectl label node $NODE_NAME beta.kubernetes.io/fluentd-ds-ready=true
```
- **Note:** If a node fails and has to be recreated, you must re-apply the label to
+ {{< note >}}**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.
+ 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,9 +263,9 @@ 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,
-that you will have to support and maintain a newly deployed configuration
-yourself: update the image and configuration, adjust the resources and so on.
+However, you can disable the default integration and deploy your own.
+{{< note >}}**Note:** You will have to support and maintain a newly deployed configuration
+yourself: update the image and configuration, adjust the resources and so on.{{< /note >}}
To disable the default logging integration, use the following command:
```
@@ -325,7 +325,8 @@ 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:** Order is important.
+the `source` section.
+{{< 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/debug-application-cluster/monitor-node-health.md b/content/en/docs/tasks/debug-application-cluster/monitor-node-health.md
index c01307216e..c4309b1588 100644
--- a/content/en/docs/tasks/debug-application-cluster/monitor-node-health.md
+++ b/content/en/docs/tasks/debug-application-cluster/monitor-node-health.md
@@ -44,7 +44,7 @@ it to [support other log format](/docs/tasks/debug-application-cluster/monitor-n
## Enable/Disable in GCE cluster
-Node problem detector is [running as a cluster addon](/docs/admin/cluster-large/#addon-resources) enabled by default in the
+Node problem detector is [running as a cluster addon](/docs/setup/cluster-large/#addon-resources) enabled by default in the
gce cluster.
You can enable/disable it by setting the environment variable
diff --git a/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
index a4855d8ddf..3b7a6c6547 100644
--- a/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
+++ b/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
@@ -2,7 +2,7 @@
reviewers:
- mikedanese
content_template: templates/concept
-title: Tools for Monitoring Compute, Storage, and Network Resources
+title: Tools for Monitoring Resources
---
{{% capture overview %}}
@@ -26,7 +26,7 @@ In Kubernetes, application monitoring does not depend on a single monitoring
solution. On new clusters, you can use two separate pipelines to collect
monitoring statistics by default:
-- The **resource metrics pipeline** provides a limited set of metrics related
+- The [**resource metrics pipeline**](#resource-metrics-pipeline) provides a limited set of metrics related
to cluster components such as the HorizontalPodAutoscaler controller, as well
as the `kubectl top` utility. These metrics are collected by
[metrics-server](https://github.com/kubernetes-incubator/metrics-server)
@@ -36,17 +36,19 @@ monitoring statistics by default:
[cAdvisor](https://github.com/google/cadvisor). `metrics-server` is a
lightweight short-term in-memory store.
-- A **full monitoring pipeline**, such as Prometheus, gives you access to richer
+- A [**full metrics pipeline**](#full-metrics-pipelines), such as Prometheus, gives you access to richer
metrics. In addition, Kubernetes can respond to these metrics by automatically
scaling or adapting the cluster based on its current state, using mechanisms
such as the Horizontal Pod Autoscaler. The monitoring pipeline fetches
metrics from the Kubelet, and then exposes them to Kubernetes via an adapter
by implementing either the `custom.metrics.k8s.io` or
- `external.metrics.k8s.io` API. See
- [Full metrics pipeline](#full-metrics-pipelines) for more information about
- some popular pipelines that implement these APIs and enable these
- capabilities.
+ `external.metrics.k8s.io` API.
+## Resource metrics pipeline
+
+### Kubelet
+
+The Kubelet acts as a bridge between the Kubernetes master and the nodes. It manages the pods and containers running on a machine. Kubelet translates each pod into its constituent containers and fetches individual container usage statistics from cAdvisor. It then exposes the aggregated pod resource usage statistics via a REST API.
### cAdvisor
@@ -56,14 +58,9 @@ On most Kubernetes clusters, cAdvisor exposes a simple UI for on-machine contain
-### Kubelet
+## Full metrics pipelines
-The Kubelet acts as a bridge between the Kubernetes master and the nodes. It manages the pods and containers running on a machine. Kubelet translates each pod into its constituent containers and fetches individual container usage statistics from cAdvisor. It then exposes the aggregated pod resource usage statistics via a REST API.
-
-## Full Metrics Pipelines
-
-Many full metrics solutions exist for Kubernetes. Prometheus and Google Cloud
-Monitoring are two of the most popular.
+Many full metrics solutions exist for Kubernetes.
### Prometheus
@@ -92,4 +89,10 @@ This video shows how to configure and run a Google Cloud Monitoring backed Heaps
{{< figure src="/images/docs/gcm.png" alt="Google Cloud Monitoring dashboard example" title="Google Cloud Monitoring dashboard example" caption="This dashboard shows cluster-wide resource usage." >}}
+### Dynatrace Kubernetes monitoring
+
+With [Dynatrace Kubernetes monitoring](https://www.dynatrace.com/technologies/cloud-and-microservices/kubernetes-monitoring/), you can monitor application and cluster health in highly-dynamic Kubernetes environments.
+
+Dynatrace automatically discovers all containers running on Kubernetes and presents you with a real-time view of all the connections between your containerized processes, hosts, and cloud instances. Dynatrace includes root cause analysis and the ability to replay problems to see how they evolved over time.
+
{{% /capture %}}
diff --git a/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md b/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md
index b647b7e3c7..983a10f22e 100644
--- a/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md
+++ b/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md
@@ -16,7 +16,10 @@ This guide shows you how to install and write extensions for [kubectl](/docs/use
{{% capture prerequisites %}}
-You need to have a working `kubectl` binary installed. Note that plugins were officially introduced as an alpha feature in the v1.8.0 release. So, while some parts of the plugins feature were already available in previous versions, a `kubectl` version of 1.8.0 or later is recommended.
+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. So, while some parts of the plugins feature were already available in previous versions, a `kubectl` version of 1.8.0 or later is recommended.
+{{< /note >}}
Until a GA version is released, plugins will only be available under the `kubectl plugin` subcommand.
@@ -28,7 +31,9 @@ Until a GA version is released, plugins will only be available under the `kubect
A plugin is nothing more than a set of files: at least a **plugin.yaml** descriptor, and likely one or more binary, script, or assets files. To install a plugin, copy those files to one of the locations in the filesystem where `kubectl` searches for plugins.
-Note that Kubernetes does not provide a package manager or something similar to install or update plugins, so it's your responsibility to place the plugin files in the correct location. We recommend that each plugin is located on its own directory, so installing a plugin that is distributed as a compressed file is as simple as extracting it to one of the locations specified in the [Plugin loader](#plugin-loader) section.
+{{< note >}}
+**Note:** Kubernetes does not provide a package manager or anything similar to install or update plugins. It is your responsibility to place the plugin files in the correct location. We recommend that each plugin be stored in its own directory so that installing a plugin distributed as a compressed file is as simple as extracting it to one of the locations specified in the [Plugin loader](#plugin-loader) section.
+{{< /note >}}
### Plugin loader
diff --git a/content/en/docs/tasks/federation/federation-service-discovery.md b/content/en/docs/tasks/federation/federation-service-discovery.md
index 6992a54bd4..6a8138193b 100644
--- a/content/en/docs/tasks/federation/federation-service-discovery.md
+++ b/content/en/docs/tasks/federation/federation-service-discovery.md
@@ -8,7 +8,9 @@ title: Cross-cluster Service Discovery using Federated Services
{{% capture overview %}}
+{{< note >}}
{{< include "federation-current-state.md" >}}
+{{< /note >}}
This guide explains how to use Kubernetes Federated Services to deploy
a common Service across multiple Kubernetes clusters. This makes it
@@ -32,7 +34,7 @@ Once created, the Federated Service automatically:
of your federated service can seamlessly locate an appropriate healthy service endpoint at all times, even in the event of cluster,
availability zone or regional outages.
-Clients inside your federated Kubernetes clusters (i.e. Pods) will
+Clients inside your federated Kubernetes clusters (that is Pods) will
automatically find the local shard of the Federated Service in their
cluster if it exists and is healthy, or the closest healthy shard in a
different cluster if it does not.
@@ -66,8 +68,8 @@ general, and [Services](/docs/concepts/services-networking/service/) in particul
## Hybrid cloud capabilities
Federations of Kubernetes Clusters can include clusters running in
-different cloud providers (e.g. Google Cloud, AWS), and on-premises
-(e.g. on OpenStack). Simply create all of the clusters that you
+different cloud providers (such as Google Cloud or AWS), and on-premises
+(such as on OpenStack). Simply create all of the clusters that you
require, in the appropriate cloud providers and/or locations, and
register each cluster's API endpoint and credentials with your
Federation API Server (See the
@@ -132,7 +134,8 @@ Session Affinity: None
Events:
```
-Note the 'LoadBalancer Ingress' addresses of your Federated Service
+{{< note >}}
+**Note:** 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
@@ -140,10 +143,11 @@ networking between service shards to work correctly, your services
need to have an externally visible IP address. [Service Type:
Loadbalancer](/docs/concepts/services-networking/service/#loadbalancer)
is typically used for this, although other options
-(e.g. [External IP's](/docs/concepts/services-networking/service/#external-ips)) exist.
+(for example [External IPs](/docs/concepts/services-networking/service/#external-ips)) exist.
+{{< /note >}}
Note also that we have not yet provisioned any backend Pods to receive
-the network traffic directed to these addresses (i.e. 'Service
+the network traffic directed to these addresses (that is 'Service
Endpoints'), so the Federated Service does not yet consider these to
be healthy service shards, and has accordingly not yet added their
addresses to the DNS records for this Federated Service (more on this
@@ -174,7 +178,7 @@ Note that `kubectl run` automatically adds the `run=nginx` labels required to as
Once the above Pods have successfully started and have begun listening
for connections, Kubernetes will report them as healthy endpoints of
-the service in that cluster (via automatic health checks). The Cluster
+the service in that cluster (through automatic health checks). The Cluster
Federation will in turn consider each of these
service 'shards' to be healthy, and place them in serving by
automatically configuring corresponding public DNS records. You can
@@ -217,7 +221,8 @@ nginx.mynamespace.myfederation.svc.europe-west1-d.example.com. CNAME 180
... etc.
```
-Note: If your Federation is configured to use AWS Route53, you can use one of the equivalent AWS tools, for example:
+{{< note >}}
+**Note:** 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
@@ -227,11 +232,12 @@ and
``` shell
$ aws route53 list-resource-record-sets --hosted-zone-id Z3ECL0L9QLOVBX
```
+{{< /note >}}
Whatever DNS provider you use, any DNS query tool (for example 'dig'
or 'nslookup') will of course also allow you to see the records
created by the Federation for you. Note that you should either point
-these tools directly at your DNS provider (e.g. `dig
+these tools directly at your DNS provider (such as `dig
@ns-cloud-e1.googledomains.com...`) or expect delays in the order of
your configured TTL (180 seconds, by default) before seeing updates,
due to caching by intermediate DNS servers.
@@ -240,7 +246,7 @@ due to caching by intermediate DNS servers.
1. Notice that there is a normal ('A') record for each service shard that has at least one healthy backend endpoint. For example, in us-central1-a, 104.197.247.191 is the external IP address of the service shard in that zone, and in asia-east1-a the address is 130.211.56.221.
2. Similarly, there are regional 'A' records which include all healthy shards in that region. For example, 'us-central1'. These regional records are useful for clients which do not have a particular zone preference, and as a building block for the automated locality and failover mechanism described below.
-3. For zones where there are currently no healthy backend endpoints, a CNAME ('Canonical Name') record is used to alias (automatically redirect) those queries to the next closest healthy zone. In the example, the service shard in us-central1-f currently has no healthy backend endpoints (i.e. Pods), so a CNAME record has been created to automatically redirect queries to other shards in that region (us-central1 in this case).
+3. For zones where there are currently no healthy backend endpoints, a CNAME ('Canonical Name') record is used to alias (automatically redirect) those queries to the next closest healthy zone. In the example, the service shard in us-central1-f currently has no healthy backend endpoints (that is Pods), so a CNAME record has been created to automatically redirect queries to other shards in that region (us-central1 in this case).
4. Similarly, if no healthy shards exist in the enclosing region, the search progresses further afield. In the europe-west1-d availability zone, there are no healthy backends, so queries are redirected to the broader europe-west1 region (which also has no healthy backends), and onward to the global set of healthy addresses (' nginx.mynamespace.myfederation.svc.example.com.').
The above set of DNS records is automatically kept in sync with the
@@ -296,12 +302,12 @@ to this minor technical difference).
But if the service does not exist in the local cluster (or it exists
but has no healthy backend pods), the DNS query is automatically
expanded to ```"nginx.mynamespace.myfederation.svc.us-central1-f.example.com"```
-(i.e. logically "find the external IP of one of the shards closest to
+(that is, logically "find the external IP of one of the shards closest to
my availability zone"). This expansion is performed automatically by
KubeDNS, which returns the associated CNAME record. This results in
automatic traversal of the hierarchy of DNS records in the above
-example, and ends up at one of the external IP's of the Federated
-Service in the local us-central1 region (i.e. 104.197.247.191,
+example, and ends up at one of the external IPs of the Federated
+Service in the local us-central1 region (that is 104.197.247.191,
104.197.244.180 or 104.197.245.170).
It is of course possible to explicitly target service shards in
@@ -343,7 +349,7 @@ service with low latency (a few seconds). In addition, as alluded
above, the Kubernetes Cluster Federation system automatically monitors
the health of clusters and the endpoints behind all of the shards of
your Federated Service, taking shards in and out of service as
-required (e.g. when all of the endpoints behind a service, or perhaps
+required (for example, when all of the endpoints behind a service, or perhaps
the entire cluster or availability zone go down, or conversely recover
from an outage). Due to the latency inherent in DNS caching (the cache
timeout, or TTL for Federated Service DNS records is configured to 3
@@ -351,7 +357,7 @@ minutes, by default, but can be adjusted), it may take up to that long
for all clients to completely fail over to an alternative cluster in
the case of catastrophic failure. However, given the number of
discrete IP addresses which can be returned for each regional service
-endpoint (see e.g. us-central1 above, which has three alternatives)
+endpoint (such as us-central1 above, which has three alternatives)
many clients will fail over automatically to one of the alternative
IP's in less time than that given appropriate configuration.
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 abf9388aed..4791e18f70 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
@@ -6,7 +6,9 @@ title: Set up Cluster Federation with Kubefed
---
{{% capture overview %}}
+{{< note >}}
{{< include "federation-current-state.md" >}}
+{{< /note >}}
Kubernetes version 1.5 and above includes a new command line tool called
[`kubefed`](/docs/admin/kubefed/) to help you administrate your federated
@@ -42,12 +44,14 @@ for installation instructions for your platform.
Download the client tarball corresponding to the particular release and
extract the binaries in the tarball:
-> Note that until kubernetes versions `1.8.x` the federation project was
-maintained as part of [core kubernetes repo](https://github.com/kubernetes/kubernetes).
-At some point between kubernetes releases `1.8.0` and `1.9.0`, it moved into
-a separate [federation repo](https://github.com/kubernetes/federation) and is
-now maintained there. After this move, the federation release information is
-available at the release page [here](https://github.com/kubernetes/federation/releases).
+{{< note >}}
+**Note:** Until Kubernetes version `1.8.x` the federation project was
+maintained as part of the [core kubernetes repo](https://github.com/kubernetes/kubernetes).
+Between Kubernetes releases `1.8` and `1.9`, the federation project moved into
+a separate [federation repo](https://github.com/kubernetes/federation), where it is
+now maintained. Consequently, the federation release information is available on the
+[release page](https://github.com/kubernetes/federation/releases).
+{{< /note >}}
### For k8s versions 1.8.x and earlier:
@@ -55,8 +59,9 @@ available at the release page [here](https://github.com/kubernetes/federation/re
curl -LO https://storage.googleapis.com/kubernetes-release/release/${RELEASE-VERSION}/kubernetes-client-linux-amd64.tar.gz
tar -xzvf kubernetes-client-linux-amd64.tar.gz
```
-> Note that the variable `RELEASE-VERSION` should be either appropriately
-set to or replaced with the actual version needed.
+{{< note >}}
+**Note:** The `RELEASE-VERSION` variable should either be set to or replaced with the actual version needed.
+{{< /note >}}
Copy the extracted binary to one of the directories in your `$PATH`
and set the executable permission on the binary.
@@ -73,8 +78,9 @@ curl -LO https://storage.cloud.google.com/kubernetes-federation-release/release/
tar -xzvf federation-client-linux-amd64.tar.gz
```
-> Note that the variable `RELEASE-VERSION` should be replaced with one of the
-release versions available at [federation release page](https://github.com/kubernetes/federation/releases).
+{{< note >}}
+**Note:** The `RELEASE-VERSION` variable should be replaced with one of the release versions available at [federation release page](https://github.com/kubernetes/federation/releases).
+{{< /note >}}
Copy the extracted binary to one of the directories in your `$PATH`
and set the executable permission on the binary.
@@ -171,8 +177,11 @@ without the Google Cloud DNS API scope by default. If you want to use a
Google Kubernetes Engine cluster as a Federation host, you must create it using the `gcloud`
command with the appropriate value in the `--scopes` field. You cannot
modify a Google Kubernetes Engine cluster directly to add this scope, but you can create a
-new node pool for your cluster and delete the old one. *Note that this
-will cause pods in the cluster to be rescheduled.*
+new node pool for your cluster and delete the old one.
+
+{{< note >}}
+**Note:** This will cause pods in the cluster to be rescheduled.
+{{< /note >}}
To add the new node pool, run:
@@ -191,16 +200,17 @@ 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 that in the beta release in 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:
+local kubeconfig.
+{{< note >}}
+**Note:** In the beta release of Kubernetes 1.6, `kubefed init` does not automatically set the current context to the
+newly deployed federation. You can set the current context manually by running:
```shell
kubectl config use-context fellowship
```
where `fellowship` is the name of your federation.
+{{< /note >}}
### Basic and token authentication support
@@ -456,9 +466,10 @@ To join clusters into the federation:
A new context has now been added to your kubeconfig named `fellowship` (after the name of your federation).
-> Note: The name that you provide to the `join` command is used as the joining cluster's identity in federation. If this name adheres 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 then you can use the same name in the join command. Otherwise, you will have to choose a different name for your cluster's identity.
-
+{{< 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
+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 >}}
### Naming rules and customization
@@ -504,10 +515,9 @@ running:
kubefed join noldor --host-cluster-context=rivendell --secret-name=11kingdom
```
-Note: If your cluster name does not conform to the DNS subdomain name
-specification, all you need to do is supply the secret name via the
-`--secret-name` flag. `kubefed join` automatically creates the secret
-for you.
+{{< 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.
+{{< /note >}}
### `kube-dns` configuration
@@ -545,7 +555,8 @@ namespace by running the following command:
kubectl delete ns federation-system --context=rivendell
```
-Note that `rivendell` is the host cluster name, replace that with the
-appropriate name in your configuration.
+{{< note >}}
+**Note:** `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 0101bf32e7..acfb9bf58b 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
@@ -5,7 +5,9 @@ content_template: templates/tutorial
{{% capture overview %}}
+{{< note >}}
{{< include "federation-current-state.md" >}}
+{{< /note >}}
This page shows how to configure and deploy CoreDNS to be used as the
DNS provider for Cluster Federation.
diff --git a/content/en/docs/tasks/federation/set-up-placement-policies-federation.md b/content/en/docs/tasks/federation/set-up-placement-policies-federation.md
index 84c8a9f9b9..cb1e02d8cf 100644
--- a/content/en/docs/tasks/federation/set-up-placement-policies-federation.md
+++ b/content/en/docs/tasks/federation/set-up-placement-policies-federation.md
@@ -5,7 +5,9 @@ content_template: templates/task
{{% capture overview %}}
+{{< note >}}
{{< include "federation-current-state.md" >}}
+{{< /note >}}
This page shows how to enforce policy-based placement decisions over Federated
resources using an external policy engine.
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 58380b735d..8e4f45d87c 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
@@ -39,8 +39,15 @@ username and password:
1. Create the Secret
- kubectl create -f https://k8s.io/examples/pods/inject/secret.yaml
-
+ ```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'
+ ```
1. View information about the Secret:
@@ -88,44 +95,52 @@ Here is a configuration file you can use to create a Pod:
1. Create the Pod:
- kubectl create -f https://k8s.io/examples/pods/inject/secret-pod.yaml
+ ```shell
+ kubectl create -f https://k8s.io/docs/tasks/inject-data-application/secret-pod.yaml
+ ```
1. Verify that your Pod is running:
- kubectl get pod secret-test-pod
+ ```shell
+ kubectl get pod secret-test-pod
+ ```
Output:
-
- NAME READY STATUS RESTARTS AGE
- secret-test-pod 1/1 Running 0 42m
-
+ ```shell
+ NAME READY STATUS RESTARTS AGE
+ secret-test-pod 1/1 Running 0 42m
+ ```
1. Get a shell into the Container that is running in your Pod:
-
- kubectl exec -it secret-test-pod -- /bin/bash
+ ```shell
+ kubectl exec -it secret-test-pod -- /bin/bash
+ ```
1. The secret data is exposed to the Container through a Volume mounted under
`/etc/secret-volume`. In your shell, go to the directory where the secret data
is exposed:
-
- root@secret-test-pod:/# cd /etc/secret-volume
+ ```shell
+ root@secret-test-pod:/# cd /etc/secret-volume
+ ```
1. In your shell, list the files in the `/etc/secret-volume` directory:
-
- root@secret-test-pod:/etc/secret-volume# ls
-
+ ```shell
+ root@secret-test-pod:/etc/secret-volume# ls
+ ```
The output shows two files, one for each piece of secret data:
-
- password username
+ ```shell
+ password username
+ ```
1. In your shell, display the contents of the `username` and `password` files:
-
- root@secret-test-pod:/etc/secret-volume# cat username; echo; cat password; echo
-
+ ```shell
+ root@secret-test-pod:/etc/secret-volume# cat username; echo; cat password; echo
+ ```
The output is your username and password:
-
- my-app
- 39528$vdg7Jb
+ ```shell
+ my-app
+ 39528$vdg7Jb
+ ```
## Create a Pod that has access to the secret data through environment variables
@@ -135,32 +150,39 @@ Here is a configuration file you can use to create a Pod:
1. Create the Pod:
- kubectl create -f https://k8s.io/examples/pods/inject/secret-envars-pod.yaml
+ ```shell
+ kubectl create -f https://k8s.io/docs/tasks/inject-data-application/secret-envars-pod.yaml
+ ```
1. Verify that your Pod is running:
-
- kubectl get pod secret-envars-test-pod
+ ```shell
+ kubectl get pod secret-envars-test-pod
+ ```
Output:
-
- NAME READY STATUS RESTARTS AGE
- secret-envars-test-pod 1/1 Running 0 4m
+ ```shell
+ NAME READY STATUS RESTARTS AGE
+ secret-envars-test-pod 1/1 Running 0 4m
+ ```
1. Get a shell into the Container that is running in your Pod:
-
- kubectl exec -it secret-envars-test-pod -- /bin/bash
+ ```shell
+ kubectl exec -it secret-envars-test-pod -- /bin/bash
+ ```
1. In your shell, display the environment variables:
-
- root@secret-envars-test-pod:/# printenv
+ ```shell
+ root@secret-envars-test-pod:/# printenv
+ ```
The output includes your username and password:
-
- ...
- SECRET_USERNAME=my-app
- ...
- SECRET_PASSWORD=39528$vdg7Jb
-
+ ```shell
+ ...
+ SECRET_USERNAME=my-app
+ ...
+ SECRET_PASSWORD=39528$vdg7Jb
+ ```
+
{{% /capture %}}
{{% capture whatsnext %}}
diff --git a/content/en/docs/tasks/inject-data-application/podpreset.md b/content/en/docs/tasks/inject-data-application/podpreset.md
index d64512751b..10fff8cec4 100644
--- a/content/en/docs/tasks/inject-data-application/podpreset.md
+++ b/content/en/docs/tasks/inject-data-application/podpreset.md
@@ -8,14 +8,12 @@ weight: 60
{{% capture overview %}}
-You can use a `podpreset` object to inject information like secrets, volume
+You can use a `PodPreset` object to inject information like secrets, volume
mounts, and environment variables etc into pods at creation time.
This task shows some examples on using the `PodPreset` resource.
{{% /capture %}}
-{{< toc >}}
-
{{% capture prerequisites %}}
Get an overview of PodPresets at
@@ -27,9 +25,8 @@ Get an overview of PodPresets at
{{% capture steps %}}
-## Create a Pod Preset
-### Simple Pod Spec Example
+## Simple Pod Spec Example
This is a simple example to show how a Pod spec is modified by the Pod
Preset.
@@ -78,7 +75,7 @@ To see above output, run the following command:
$ kubectl get pod website -o yaml
```
-### Pod Spec with `ConfigMap` Example
+## Pod Spec with ConfigMap Example
This is an example to show how a Pod spec is modified by the Pod Preset
that defines a `ConfigMap` for Environment Variables.
@@ -99,7 +96,7 @@ that defines a `ConfigMap` for Environment Variables.
{{< codenew file="podpreset/allow-db-merged.yaml" >}}
-### ReplicaSet with Pod Spec Example
+## ReplicaSet with Pod Spec Example
The following example shows that only the pod spec is modified by the Pod
Preset.
@@ -119,7 +116,7 @@ to validate that the PodPreset has been applied.
{{< codenew file="podpreset/replicaset-merged.yaml" >}}
-### Multiple PodPreset Example
+## Multiple PodPreset Example
This is an example to show how a Pod spec is modified by multiple Pod
Injection Policies.
@@ -140,7 +137,7 @@ Injection Policies.
{{< codenew file="podpreset/multi-merged.yaml" >}}
-### Conflict Example
+## Conflict Example
This is an example to show how a Pod spec is not modified by the Pod Preset
when there is a conflict.
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 b73ab24440..f961bbf34c 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
@@ -1,5 +1,5 @@
---
-title: Running automated tasks with cron jobs
+title: Running Automated Tasks with a CronJob
reviewers:
- chenopis
content_template: templates/task
@@ -93,7 +93,7 @@ Note that the job name and pod name are different.
```shell
# Replace "hello-4111706356" with the job name in your system
-$ pods=$(kubectl get pods --show-all --selector=job-name=hello-4111706356 --output=jsonpath={.items..metadata.name})
+$ pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items..metadata.name})
$ echo $pods
hello-4111706356-o9qcm
@@ -168,6 +168,11 @@ If it is set to `true`, all subsequent executions are suspended.
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.
+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 >}}
+
### Jobs History Limits
The `.spec.successfulJobsHistoryLimit` and `.spec.failedJobsHistoryLimit` fields are optional.
diff --git a/content/en/docs/tasks/job/parallel-processing-expansion.md b/content/en/docs/tasks/job/parallel-processing-expansion.md
index 25078d0b86..102844e7aa 100644
--- a/content/en/docs/tasks/job/parallel-processing-expansion.md
+++ b/content/en/docs/tasks/job/parallel-processing-expansion.md
@@ -8,7 +8,7 @@ weight: 20
In this example, we will run multiple Kubernetes Jobs created from
a common template. You may want to be familiar with the basic,
-non-parallel, use of [Jobs](/docs/concepts/jobs/run-to-completion-finite-workloads/) first.
+non-parallel, use of [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) first.
{{% /capture %}}
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 fe220c1a6b..fbd57b98c0 100644
--- a/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md
+++ b/content/en/docs/tasks/manage-daemon/rollback-daemon-set.md
@@ -1,7 +1,7 @@
---
reviewers:
- janetkuo
-title: Performing a Rollback on a DaemonSet
+title: Perform a Rollback on a DaemonSet
content_template: templates/task
---
@@ -139,11 +139,13 @@ DaemonSet template with the template stored in the `ControllerRevision`.
previous revision through other commands, such as `kubectl edit` or `kubectl
apply`.
-Note that DaemonSet revisions only roll forward. That is to say, after a
-rollback is complete, the revision number (`.revision` field) of the
+{{< note >}}
+**Note:** 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
1, the `ControllerRevision` with `.revision: 1` will become `.revision: 3`.
+{{< /note >}}
## Troubleshooting
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 564f8a8fbb..a8a256c482 100644
--- a/content/en/docs/tasks/manage-daemon/update-daemon-set.md
+++ b/content/en/docs/tasks/manage-daemon/update-daemon-set.md
@@ -159,11 +159,12 @@ 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. Note that this will cause service disruption
-if the deleted pods are not controlled by any controllers, or if the pods aren't
-replicated. This doesn't respect
-[PodDisruptionBudget](/docs/tasks/configure-pod-container/configure-pod-disruption-budget/)
+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
+replicated. This does not respect [PodDisruptionBudget](/docs/tasks/configure-pod-container/configure-pod-disruption-budget/)
either.
+{{< /note >}}
#### Broken rollout
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 343582acb4..3ccf9dadc5 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,7 +25,7 @@ This document walks you through an example of enabling Horizontal Pod Autoscaler
{{% capture prerequisites %}}
This example requires a running Kubernetes cluster and kubectl, version 1.2 or later.
-[metrics-server](https://github.com/kubernetes/heapster) monitoring needs to be deployed in the cluster
+[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).
diff --git a/content/en/docs/tasks/run-application/run-stateless-application-deployment.md b/content/en/docs/tasks/run-application/run-stateless-application-deployment.md
index 043c4a089f..5da19f0c25 100644
--- a/content/en/docs/tasks/run-application/run-stateless-application-deployment.md
+++ b/content/en/docs/tasks/run-application/run-stateless-application-deployment.md
@@ -143,7 +143,7 @@ Delete the deployment by name:
The preferred way to create a replicated application is to use a Deployment,
which in turn uses a ReplicaSet. Before the Deployment and ReplicaSet were
-added to Kubernetes, replicated applications were configured by using a
+added to Kubernetes, replicated applications were configured using a
[ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/).
{{% /capture %}}
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 95249edd0a..1c3d98e989 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
@@ -64,8 +64,8 @@ The cfssl tools used in this example can be downloaded at
Generate a private key and certificate signing request (or CSR) by running
the following command:
-```console
-$ cat <
Annotations:
@@ -160,8 +163,11 @@ information on what this involves is covered below.
Once the CSR is signed and approved you should see the following:
-```console
-$ kubectl get csr
+```shell
+kubectl get csr
+```
+
+```none
NAME AGE REQUESTOR CONDITION
my-svc.my-namespace 10m yourname@example.com Approved,Issued
```
@@ -169,8 +175,8 @@ my-svc.my-namespace 10m yourname@example.com Approved,Issued
You can download the issued certificate and save it to a `server.crt` file
by running the following:
-```console
-$ kubectl get csr my-svc.my-namespace -o jsonpath='{.status.certificate}' \
+```shell
+kubectl get csr my-svc.my-namespace -o jsonpath='{.status.certificate}' \
| base64 --decode > server.crt
```
@@ -200,7 +206,7 @@ to verify that the CSR satisfies two requirements:
If and only if these two requirements are met, the approver should approve
the CSR and otherwise should deny the CSR.
-## A Word of **Warning** on the Approval Permission
+## A Word of Warning on the Approval Permission
The ability to approve CSRs decides who trusts who within the cluster. This
includes who the Kubernetes API trusts. The ability to approve CSRs should
diff --git a/content/en/docs/tasks/tools/install-kubectl.md b/content/en/docs/tasks/tools/install-kubectl.md
index 309e91c98a..53d0d53119 100644
--- a/content/en/docs/tasks/tools/install-kubectl.md
+++ b/content/en/docs/tasks/tools/install-kubectl.md
@@ -8,11 +8,11 @@ weight: 10
---
{{% capture overview %}}
-Use the Kubernetes command-line tool, [kubectl](/docs/user-guide/kubectl/), to deploy and manage applications on Kubernetes. Using kubectl, you can inspect cluster resources; create, delete, and update components; and look at your new cluster and bring up example apps.
+Use the Kubernetes command-line tool, [kubectl](/docs/user-guide/kubectl/), to deploy and manage applications on Kubernetes. Using kubectl, you can inspect cluster resources; create, delete, and update components; look at your new cluster; and bring up example apps.
{{% /capture %}}
{{% capture prerequisites %}}
-You must use a kubectl version that is within one minor version difference with your cluster. For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master. Using the latest version of kubectl helps avoid unforeseen issues.
+You must use a kubectl version that is within one minor version difference of your cluster. For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master. Using the latest version of kubectl helps avoid unforeseen issues.
{{% /capture %}}
@@ -22,7 +22,7 @@ You must use a kubectl version that is within one minor version difference with
Here are a few methods to install kubectl.
-## Install kubectl binary via native package management
+## Install kubectl binary using native package management
{{< tabs name="kubectl_install" >}}
{{< tab name="Ubuntu, Debian or HypriotOS" codelang="bash" >}}
@@ -49,75 +49,135 @@ yum install -y kubectl
## Install with snap on Ubuntu
-kubectl is available as a [snap](https://snapcraft.io/) application.
+If you are on Ubuntu or one of other Linux distributions that support [snap](https://snapcraft.io/docs/core/install) package manager, kubectl is available as a [snap](https://snapcraft.io/) application.
-1. If you are on Ubuntu or one of other Linux distributions that support [snap](https://snapcraft.io/docs/core/install) package manager, you can install with:
+1. Switch to the snap user and run the installation command:
- sudo snap install kubectl --classic
+ ```
+ sudo snap install kubectl --classic
+ ```
-2. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.
+2. Test to ensure the version you installed is sufficiently up-to-date:
+
+ ```
+ kubectl version
+ ```
## Install with Homebrew on macOS
-1. If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you can install with:
+If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you can install kubectl with Homebrew.
- brew install kubernetes-cli
+1. Run the installation command:
-2. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.
+ ```
+ brew install kubernetes-cli
+ ```
+
+2. Test to ensure the version you installed is sufficiently up-to-date:
+
+ ```
+ kubectl version
+ ```
## Install with Macports on macOS
-1. If you are on macOS and using [Macports](https://macports.org/) package manager, you can install with:
+If you are on macOS and using [Macports](https://macports.org/) package manager, you can install kubectl with Macports.
- port install kubectl
+1. Run the installation command:
-2. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.
+ ```
+ port install kubectl
+ ```
+
+2. Test to ensure the version you installed is sufficiently up-to-date:
+
+ ```
+ kubectl version
+ ```
## Install with Powershell from PSGallery
-1. If you are on Windows and using [Powershell Gallery](https://www.powershellgallery.com/) package manager, you can install and update with:
+If you are on Windows and using [Powershell Gallery](https://www.powershellgallery.com/) package manager, you can install and update kubectl with Powershell.
- Install-Script -Name install-kubectl -Scope CurrentUser -Force
- install-kubectl.ps1 [-DownloadLocation ]
+To install:
+* Run the installation commands (making sure to specify a DownloadLocation):
-If no Downloadlocation is specified, kubectl will be installed in users temp Directory
-2. The installer creates $HOME/.kube and instructs it to create a config file
-3. Updating
-re-run Install-Script to update the installer
-re-run install-kubectl.ps1 to install latest binaries
+ ```
+ Install-Script -Name install-kubectl -Scope CurrentUser -Force
+ install-kubectl.ps1 [-DownloadLocation ]
+ ```
+
+ {{< note >}}
+ **Note:** 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
+To update:
+* Run the update commands:
+
+ ```
+ re-run Install-Script to update the installer
+ re-run install-kubectl.ps1 to install latest binaries
+ ```
## Install with Chocolatey on Windows
-1. If you are on Windows and using [Chocolatey](https://chocolatey.org) package manager, you can install with:
+If you are on Windows and using [Chocolatey](https://chocolatey.org) package manager, you can install kubectl with Chocolatey.
- choco install kubernetes-cli
+1. Run the installation command:
-2. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.
-3. Configure kubectl to use a remote Kubernetes cluster:
+ ```
+ choco install kubernetes-cli
+ ```
+
+2. Test to ensure the version you installed is sufficiently up-to-date:
- cd C:\users\yourusername (Or wherever your %HOME% directory is)
- mkdir .kube
- cd .kube
+ ```
+ kubectl version
+ ```
+3. Change to your %HOME% directory:
+
+ For example: `cd C:\users\yourusername`
+
+4. Create the .kube directory:
+
+ ```
+ mkdir .kube
+ ```
+
+5. Change to the .kube directory you just created:
+
+ ```
+ cd .kube
+ ```
+
+6. Configure kubectl to use a remote Kubernetes cluster:
New-Item config -type file
-
-Edit the config file with a text editor of your choice, such as Notepad for example.
+ {{< note >}}
+ **Note:** Edit the config file with a text editor of your choice, such as Notepad.
+ {{< /note >}}
## Download as part of the Google Cloud SDK
-kubectl can be installed as part of the Google Cloud SDK.
+You can install kubectl as part of the Google Cloud SDK.
1. Install the [Google Cloud SDK](https://cloud.google.com/sdk/).
-2. Run the following command to install `kubectl`:
+2. Run the `kubectl` installation command:
- gcloud components install kubectl
+ ```
+ gcloud components install kubectl
+ ```
+
+3. Test to ensure the version you installed is sufficiently up-to-date:
-3. Run `kubectl version` to verify that the version you've installed is sufficiently up-to-date.
+ ```
+ kubectl version
+ ```
-## Install kubectl binary via curl
+## Install kubectl binary using curl
{{< tabs name="kubectl_install_curl" >}}
{{% tab name="macOS" %}}
-1. Download the latest release with the command:
+1. Download the latest release:
```
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl
@@ -250,7 +310,7 @@ brew install bash-completion@2
Follow the "caveats" section of brew's output to add the appropriate bash completion path to your local .bashrc.
-If you've installed kubectl using the [Homebrew instructions](#install-with-homebrew-on-macos) then kubectl completion should start working immediately.
+If you installed kubectl using the [Homebrew instructions](#install-with-homebrew-on-macos) then kubectl completion should start working immediately.
If you have installed kubectl manually, you need to add kubectl autocompletion to the bash-completion:
diff --git a/content/en/docs/tasks/tools/install-minikube.md b/content/en/docs/tasks/tools/install-minikube.md
index 5a0393517b..e6ad64c72b 100644
--- a/content/en/docs/tasks/tools/install-minikube.md
+++ b/content/en/docs/tasks/tools/install-minikube.md
@@ -20,33 +20,29 @@ VT-x or AMD-v virtualization must be enabled in your computer's BIOS.
## Install a Hypervisor
-If you do not already have a hypervisor installed, install one now.
+If you do not already have a hypervisor installed, install the appropriate one for your OS now:
-* For macOS, install
-[VirtualBox](https://www.virtualbox.org/wiki/Downloads) or
+* macOS: [VirtualBox](https://www.virtualbox.org/wiki/Downloads) or
[VMware Fusion](https://www.vmware.com/products/fusion), or
[HyperKit](https://github.com/moby/hyperkit).
-* For Linux, install
-[VirtualBox](https://www.virtualbox.org/wiki/Downloads) or
+* Linux: [VirtualBox](https://www.virtualbox.org/wiki/Downloads) or
[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. Docker is required to use this driver but a hypervisor is not required.
+ **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.
{{< /note >}}
-* For Windows, install
-[VirtualBox](https://www.virtualbox.org/wiki/Downloads) or
+* Windows: [VirtualBox](https://www.virtualbox.org/wiki/Downloads) or
[Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install).
## Install kubectl
-* [Install kubectl](/docs/tasks/tools/install-kubectl/).
+* Install kubectl according to the instructions in [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/).
## Install Minikube
-* Install Minikube according to the instructions for the
-[latest release](https://github.com/kubernetes/minikube/releases).
+* Install Minikube according to the instructions for the [latest release](https://github.com/kubernetes/minikube/releases).
{{% /capture %}}
diff --git a/content/en/docs/test.md b/content/en/docs/test.md
index ec00b0fef7..6492426441 100644
--- a/content/en/docs/test.md
+++ b/content/en/docs/test.md
@@ -337,3 +337,12 @@ You can have multiple paragraphs and block-level elements inside an admonition.
**Warning:** Warnings point out something that could cause harm if ignored.
{{< /warning >}}
+
+
+## Includes
+
+To add shortcodes to includes.
+
+{{< note >}}
+{{< include "federation-current-state.md" >}}
+{{< /note >}}
diff --git a/content/en/docs/tutorials/clusters/apparmor.md b/content/en/docs/tutorials/clusters/apparmor.md
index c8bd96c379..9102185c38 100644
--- a/content/en/docs/tutorials/clusters/apparmor.md
+++ b/content/en/docs/tutorials/clusters/apparmor.md
@@ -240,7 +240,7 @@ spec:
image: busybox
command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
EOF
-pod "hello-apparmor-2" created
+pod/hello-apparmor-2 created
$ kubectl describe pod hello-apparmor-2
Name: hello-apparmor-2
diff --git a/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md
index 2de69abe74..47c426813d 100644
--- a/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md
+++ b/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md
@@ -35,10 +35,22 @@ This page provides a real world example of how to configure Redis using a Config
You can follow the steps below to configure a Redis cache using data stored in a ConfigMap.
-First create a ConfigMap from the `examples/pods/config/redis-config` file:
+First create a ConfigMap from the `redis-config` file:
+
+{{< codenew file="pods/config/redis-config" >}}
+
+```shell
+curl -OL https://k8s.io/examples/pods/config/redis-config
+kubectl create configmap example-redis-config --from-file=redis-config
+```
+
+```shell
+configmap/example-redis-config created
+```
+
+Examine the created ConfigMap:
```shell
-kubectl create configmap example-redis-config --from-file=https://k8s.io/examples/pods/config/redis-config
kubectl get configmap example-redis-config -o yaml
```
diff --git a/content/en/docs/tutorials/k8s201.md b/content/en/docs/tutorials/k8s201.md
index 7c41d8864b..3c8b3aa8f9 100644
--- a/content/en/docs/tutorials/k8s201.md
+++ b/content/en/docs/tutorials/k8s201.md
@@ -175,7 +175,7 @@ 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 (`$SERVCE_PORT`). We can also access the service from a host running Kubernetes using that port:
+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
diff --git a/content/en/docs/tutorials/kubernetes-basics/index.html b/content/en/docs/tutorials/kubernetes-basics/_index.html
similarity index 98%
rename from content/en/docs/tutorials/kubernetes-basics/index.html
rename to content/en/docs/tutorials/kubernetes-basics/_index.html
index a9b32a3dda..9ce2ef980f 100644
--- a/content/en/docs/tutorials/kubernetes-basics/index.html
+++ b/content/en/docs/tutorials/kubernetes-basics/_index.html
@@ -1,6 +1,7 @@
---
-title: Overview
-weight: 5
+title: Learn Kubernetes Basics
+linkTitle: Learn Kubernetes Basics
+weight: 10
---
diff --git a/content/en/docs/tutorials/kubernetes-basics/_index.md b/content/en/docs/tutorials/kubernetes-basics/_index.md
deleted file mode 100644
index da5e3cb31a..0000000000
--- a/content/en/docs/tutorials/kubernetes-basics/_index.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: Kubernetes Basics
-weight: 10
----
-
diff --git a/content/en/docs/tutorials/services/source-ip.md b/content/en/docs/tutorials/services/source-ip.md
index b436fd617d..e41e16ed51 100644
--- a/content/en/docs/tutorials/services/source-ip.md
+++ b/content/en/docs/tutorials/services/source-ip.md
@@ -35,7 +35,7 @@ IP of requests it receives through an HTTP header. You can create it as follows:
```console
$ kubectl run source-ip-app --image=k8s.gcr.io/echoserver:1.4
-deployment "source-ip-app" created
+deployment.apps/source-ip-app created
```
{{% /capture %}}
@@ -60,10 +60,10 @@ a `proxyMode` endpoint:
```console
$ kubectl get nodes
-NAME STATUS AGE VERSION
-kubernetes-minion-group-6jst Ready 2h v1.6.0+fff5156
-kubernetes-minion-group-cx31 Ready 2h v1.6.0+fff5156
-kubernetes-minion-group-jj1t Ready 2h v1.6.0+fff5156
+NAME STATUS ROLES AGE VERSION
+kubernetes-minion-group-6jst Ready 2h v1.11.1
+kubernetes-minion-group-cx31 Ready 2h v1.11.1
+kubernetes-minion-group-jj1t Ready 2h v1.11.1
kubernetes-minion-group-6jst $ curl localhost:10249/proxyMode
iptables
@@ -73,11 +73,11 @@ You can test source IP preservation by creating a Service over the source IP app
```console
$ kubectl expose deployment source-ip-app --name=clusterip --port=80 --target-port=8080
-service "clusterip" exposed
+service/clusterip exposed
$ kubectl get svc clusterip
-NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
-clusterip 10.0.170.92 80/TCP 51s
+NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+clusterip ClusterIP 10.0.170.92 80/TCP 51s
```
And hitting the `ClusterIP` from a pod in the same cluster:
@@ -116,7 +116,7 @@ are source NAT'd by default. You can test this by creating a `NodePort` Service:
```console
$ kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort
-service "nodeport" exposed
+service/nodeport exposed
$ NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport)
$ NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="ExternalIP")].address }')
@@ -171,7 +171,7 @@ Set the `service.spec.externalTrafficPolicy` field as follows:
```console
$ kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}'
-service "nodeport" patched
+service/nodeport patched
```
Now, re-run the test:
@@ -220,11 +220,11 @@ You can test this by exposing the source-ip-app through a loadbalancer
```console
$ kubectl expose deployment source-ip-app --name=loadbalancer --port=80 --target-port=8080 --type=LoadBalancer
-service "loadbalancer" exposed
+service/loadbalancer exposed
$ kubectl get svc loadbalancer
-NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
-loadbalancer 10.0.65.118 104.198.149.140 80/TCP 5m
+NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+loadbalancer LoadBalancer 10.0.65.118 104.198.149.140 80/TCP 5m
$ curl 104.198.149.140
CLIENT VALUES:
diff --git a/content/en/docs/tutorials/stateful-application/cassandra.md b/content/en/docs/tutorials/stateful-application/cassandra.md
index c4d580da95..9c3436f6e1 100644
--- a/content/en/docs/tutorials/stateful-application/cassandra.md
+++ b/content/en/docs/tutorials/stateful-application/cassandra.md
@@ -7,13 +7,13 @@ weight: 30
---
{{% capture overview %}}
-This tutorial shows you how to develop a native cloud [Cassandra](http://cassandra.apache.org/) deployment on Kubernetes. In this example, a custom Cassandra `SeedProvider` enables Cassandra to discover new Cassandra nodes as they join the cluster.
+This tutorial shows you how to develop a native cloud [Cassandra](http://cassandra.apache.org/) deployment on Kubernetes. In this example, a custom Cassandra *SeedProvider* enables Cassandra to discover new Cassandra nodes as they join the cluster.
-`StatefulSet`s make it easier to deploy stateful applications within a clustered environment. For more information on the features used in this tutorial, see the [`StatefulSet`](/docs/concepts/workloads/controllers/statefulset/) documentation.
+*StatefulSets* make it easier to deploy stateful applications within a clustered environment. For more information on the features used in this tutorial, see the [*StatefulSet*](/docs/concepts/workloads/controllers/statefulset/) documentation.
**Cassandra on Docker**
-The `Pod`s in this tutorial use the [`gcr.io/google-samples/cassandra:v13`](https://github.com/kubernetes/examples/blob/master/cassandra/image/Dockerfile)
+The *Pods* in this tutorial use the [`gcr.io/google-samples/cassandra:v13`](https://github.com/kubernetes/examples/blob/master/cassandra/image/Dockerfile)
image from Google's [container registry](https://cloud.google.com/container-registry/docs/).
The Docker image above is based on [debian-base](https://github.com/kubernetes/kubernetes/tree/master/build/debian-base)
and includes OpenJDK 8.
@@ -30,17 +30,17 @@ By using environment variables you can change values that are inserted into `cas
{{% /capture %}}
{{% capture objectives %}}
-* Create and validate a Cassandra headless [`Service`](/docs/concepts/services-networking/service/).
-* Use a [`StatefulSet`](/docs/concepts/workloads/controllers/statefulset/) to create a Cassandra ring.
-* Validate the [`StatefulSet`](/docs/concepts/workloads/controllers/statefulset/).
-* Modify the [`StatefulSet`](/docs/concepts/workloads/controllers/statefulset/).
-* Delete the [`StatefulSet`](/docs/concepts/workloads/controllers/statefulset/) and its [`Pod`s](/docs/concepts/workloads/pods/pod/).
+* Create and validate a Cassandra headless [*Service*](/docs/concepts/services-networking/service/).
+* Use a [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) to create a Cassandra ring.
+* Validate the [StatefulSet](/docs/concepts/workloads/controllers/statefulset/).
+* Modify the [StatefulSet](/docs/concepts/workloads/controllers/statefulset/).
+* Delete the [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) and its [Pods](/docs/concepts/workloads/pods/pod/).
{{% /capture %}}
{{% capture prerequisites %}}
-To complete this tutorial, you should already have a basic familiarity with [`Pod`s](/docs/concepts/workloads/pods/pod/), [`Service`s](/docs/concepts/services-networking/service/), and [`StatefulSet`s](/docs/concepts/workloads/controllers/statefulset/). In addition, you should:
+To complete this tutorial, you should already have a basic familiarity with [Pods](/docs/concepts/workloads/pods/pod/), [Services](/docs/concepts/services-networking/service/), and [StatefulSets](/docs/concepts/workloads/controllers/statefulset/). In addition, you should:
-* [Install and Configure](/docs/tasks/tools/install-kubectl/) the `kubectl` command-line tool
+* [Install and Configure](/docs/tasks/tools/install-kubectl/) the *kubectl* command-line tool
* Download [`cassandra-service.yaml`](/examples/application/cassandra/cassandra-service.yaml)
and [`cassandra-statefulset.yaml`](/examples/application/cassandra/cassandra-statefulset.yaml)
@@ -54,7 +54,7 @@ To complete this tutorial, you should already have a basic familiarity with [`Po
### Additional Minikube Setup Instructions
{{< caution >}}
-**Caution:** [Minikube](/docs/getting-started-guides/minikube/) defaults to 1024MB of memory and 1 CPU. Running Minikube with the default resource configuration may result in insufficient resource errors during this tutorial. To avoid these errors, we recommend running Minikube with 5 GB of memory and 4 CPUs:
+**Caution:** [Minikube](/docs/getting-started-guides/minikube/) defaults to 1024MB of memory and 1 CPU. Running Minikube with the default resource configuration results in insufficient resource errors during this tutorial. To avoid these errors, start Minikube with the folllowing settings:
```shell
minikube start --memory 5120 --cpus=4
@@ -66,14 +66,14 @@ minikube start --memory 5120 --cpus=4
{{% capture lessoncontent %}}
## Creating a Cassandra Headless Service
-A Kubernetes [`Service`](/docs/concepts/services-networking/service/) describes a set of [`Pod`s](/docs/concepts/workloads/pods/pod/) that perform the same task.
+A Kubernetes [Service](/docs/concepts/services-networking/service/) describes a set of [Pods](/docs/concepts/workloads/pods/pod/) that perform the same task.
-The following `Service` is used for DNS lookups between Cassandra `Pod`s and clients within the Kubernetes cluster.
+The following `Service` is used for DNS lookups between Cassandra Pods and clients within the Kubernetes cluster.
{{< codenew file="application/cassandra/cassandra-service.yaml" >}}
1. Launch a terminal window in the directory you downloaded the manifest files.
-1. Create a `Service` to track all Cassandra `StatefulSet` nodes from the `cassandra-service.yaml` file:
+1. Create a Service to track all Cassandra StatefulSet nodes from the `cassandra-service.yaml` file:
```shell
kubectl create -f https://k8s.io/examples/application/cassandra/cassandra-service.yaml
@@ -81,7 +81,7 @@ The following `Service` is used for DNS lookups between Cassandra `Pod`s and cli
### Validating (optional)
-Get the Cassandra `Service`.
+Get the Cassandra Service.
```shell
kubectl get svc cassandra
@@ -90,24 +90,24 @@ kubectl get svc cassandra
The response is
```
-NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
-cassandra None 9042/TCP 45s
+NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+cassandra ClusterIP None 9042/TCP 45s
```
Service creation failed if anything else is returned. Read [Debug Services](/docs/tasks/debug-application-cluster/debug-service/) for common issues.
## Using a StatefulSet to Create a Cassandra Ring
-The `StatefulSet` manifest, included below, creates a Cassandra ring that consists of three `Pod`s.
+The StatefulSet manifest, included below, creates a Cassandra ring that consists of three Pods.
{{< note >}}
-**Note:** This example uses the default provisioner for Minikube. Please update the following `StatefulSet` for the cloud you are working with.
+**Note:** This example uses the default provisioner for Minikube. Please update the following StatefulSet for the cloud you are working with.
{{< /note >}}
{{< codenew file="application/cassandra/cassandra-statefulset.yaml" >}}
-1. Update the `StatefulSet` if necessary.
-1. Create the Cassandra `StatefulSet` from the `cassandra-statefulset.yaml` file:
+1. Update the StatefulSet if necessary.
+1. Create the Cassandra StatefulSet from the `cassandra-statefulset.yaml` file:
```shell
kubectl create -f https://k8s.io/examples/application/cassandra/cassandra-statefulset.yaml
@@ -115,7 +115,7 @@ The `StatefulSet` manifest, included below, creates a Cassandra ring that consis
## Validating The Cassandra StatefulSet
-1. Get the Cassandra `StatefulSet`:
+1. Get the Cassandra StatefulSet:
```shell
kubectl get statefulset cassandra
@@ -128,9 +128,9 @@ The `StatefulSet` manifest, included below, creates a Cassandra ring that consis
cassandra 3 0 13s
```
- The `StatefulSet` resource deploys `Pod`s sequentially.
+ The `StatefulSet` resource deploys Pods sequentially.
-1. Get the `Pod`s to see the ordered creation status:
+1. Get the Pods to see the ordered creation status:
```shell
kubectl get pods -l="app=cassandra"
@@ -143,9 +143,9 @@ The `StatefulSet` manifest, included below, creates a Cassandra ring that consis
cassandra-0 1/1 Running 0 1m
cassandra-1 0/1 ContainerCreating 0 8s
```
-
- Please note that it may take several minutes for all three `Pod`s to deploy. Once they are deployed, the same command returns:
-
+
+ It can take several minutes for all three Pods to deploy. Once they are deployed, the same command returns:
+
```
NAME READY STATUS RESTARTS AGE
cassandra-0 1/1 Running 0 10m
@@ -174,7 +174,7 @@ The `StatefulSet` manifest, included below, creates a Cassandra ring that consis
## Modifying the Cassandra StatefulSet
-Use `kubectl edit` to modify the size of a Cassandra `StatefulSet`.
+Use `kubectl edit` to modify the size of a Cassandra StatefulSet.
1. Run the following command:
@@ -205,11 +205,11 @@ Use `kubectl edit` to modify the size of a Cassandra `StatefulSet`.
replicas: 3
```
-2. Change the number of replicas to 4, and then save the manifest.
+1. Change the number of replicas to 4, and then save the manifest.
- The `StatefulSet` now contains 4 `Pod`s.
+ The `StatefulSet` now contains 4 Pods.
-1. Get the Cassandra `StatefulSet` to verify:
+1. Get the Cassandra StatefulSet to verify:
```shell
kubectl get statefulset cassandra
@@ -225,10 +225,10 @@ Use `kubectl edit` to modify the size of a Cassandra `StatefulSet`.
{{% /capture %}}
{{% capture cleanup %}}
-Deleting or scaling a `StatefulSet` down does not delete the volumes associated with the `StatefulSet`. This ensures safety first: your data is more valuable than an auto purge of all related StatefulSet resources.
+Deleting or scaling a StatefulSet down does not delete the volumes associated with the StatefulSet. This setting is for your safety because your data is more valuable than automatically purging all related StatefulSet resources.
{{< warning >}}
-**Warning:** Depending on the storage class and reclaim policy, deleting the `PersistentVolumeClaim`s may cause the associated volumes to also be deleted. Never assume you’ll be able to access data if its volume claims are deleted.
+**Warning:** Depending on the storage class and reclaim policy, deleting the *PersistentVolumeClaims* may cause the associated volumes to also be deleted. Never assume you’ll be able to access data if its volume claims are deleted.
{{< /warning >}}
1. Run the following commands (chained together into a single command) to delete everything in the Cassandra `StatefulSet`:
@@ -241,7 +241,7 @@ Deleting or scaling a `StatefulSet` down does not delete the volumes associated
&& kubectl delete pvc -l app=cassandra
```
-1. Run the following command to delete the Cassandra `Service`.
+1. Run the following command to delete the Cassandra Service.
```shell
kubectl delete service -l app=cassandra
@@ -251,8 +251,8 @@ Deleting or scaling a `StatefulSet` down does not delete the volumes associated
{{% capture whatsnext %}}
-* Learn how to [Scale a `StatefulSet`](/docs/tasks/run-application/scale-stateful-set/).
-* Learn more about the [`KubernetesSeedProvider`](https://github.com/kubernetes/examples/blob/master/cassandra/java/src/main/java/io/k8s/cassandra/KubernetesSeedProvider.java)
+* Learn how to [Scale a StatefulSet](/docs/tasks/run-application/scale-stateful-set/).
+* Learn more about the [*KubernetesSeedProvider*](https://github.com/kubernetes/examples/blob/master/cassandra/java/src/main/java/io/k8s/cassandra/KubernetesSeedProvider.java)
* See more custom [Seed Provider Configurations](https://git.k8s.io/examples/cassandra/java/README.md)
{{% /capture %}}
diff --git a/content/en/docs/tutorials/stateful-application/zookeeper.md b/content/en/docs/tutorials/stateful-application/zookeeper.md
index 5eacf93740..98429e694f 100644
--- a/content/en/docs/tutorials/stateful-application/zookeeper.md
+++ b/content/en/docs/tutorials/stateful-application/zookeeper.md
@@ -90,10 +90,10 @@ This creates the `zk-hs` Headless Service, the `zk-cs` Service,
the `zk-pdb` PodDisruptionBudget, and the `zk` StatefulSet.
```shell
-service "zk-hs" created
-service "zk-cs" created
-poddisruptionbudget "zk-pdb" created
-statefulset "zk" created
+service/zk-hs created
+service/zk-cs created
+poddisruptionbudget.policy/zk-pdb created
+statefulset.apps/zk created
```
Use [`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get) to watch the
@@ -314,7 +314,7 @@ Use the [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#d
```shell
kubectl delete statefulset zk
-statefulset "zk" deleted
+statefulset.apps "zk" deleted
```
Watch the termination of the Pods in the StatefulSet.
@@ -620,7 +620,7 @@ You can use `kubectl patch` to update the number of `cpus` allocated to the serv
```shell
kubectl patch sts zk --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/resources/requests/cpu", "value":"0.3"}]'
-statefulset "zk" patched
+statefulset.apps/zk patched
```
Use `kubectl rollout status` to watch the status of the update.
@@ -658,7 +658,7 @@ Use the `kubectl rollout undo` command to roll back the modification.
```shell
kubectl rollout undo sts/zk
-statefulset "zk" rolled back
+statefulset.apps/zk rolled back
```
### Handling Process Failure
diff --git a/content/en/examples/admin/dns/busybox.yaml b/content/en/examples/admin/dns/busybox.yaml
index c2db4b3d74..31f009d307 100644
--- a/content/en/examples/admin/dns/busybox.yaml
+++ b/content/en/examples/admin/dns/busybox.yaml
@@ -6,7 +6,7 @@ metadata:
spec:
containers:
- name: busybox
- image: busybox
+ image: busybox:1.28
command:
- sleep
- "3600"
diff --git a/content/en/includes/federation-current-state.md b/content/en/includes/federation-current-state.md
index a1c59f2a1d..97d26cf075 100644
--- a/content/en/includes/federation-current-state.md
+++ b/content/en/includes/federation-current-state.md
@@ -1 +1 @@
-**Note:** `Federation V1`, the current Kubernetes federation API which reuses the Kubernetes API resources 'as is', is currently considered alpha for many of its features, and there is no clear path to evolve the API to GA. However, there is a `Federation V2` effort in progress to implement a dedicated federation API apart from the Kubernetes API. The details can be found at [sig-multicluster community page](https://github.com/kubernetes/community/tree/master/sig-multicluster).
+**Note:** `Federation V1`, the current Kubernetes federation API which reuses the Kubernetes API resources 'as is', is currently considered alpha for many of its features. There is no clear path to evolve the API to GA; however, there is a `Federation V2` effort in progress to implement a dedicated federation API apart from the Kubernetes API. The details are available at [sig-multicluster community page](https://github.com/kubernetes/community/tree/master/sig-multicluster).
diff --git a/data/user-personas/contributors/code-contributor.yaml b/data/user-personas/contributors/code-contributor.yaml
index b21b8841a1..a578d7fac4 100644
--- a/data/user-personas/contributors/code-contributor.yaml
+++ b/data/user-personas/contributors/code-contributor.yaml
@@ -5,11 +5,11 @@ index: 0
foundational:
- label: "Read the Developer Guide"
icon: fa-book
- url: "/docs/imported/community/devel/"
+ url: "/docs/community/devel/"
intermediate:
- label: "Learn about the Kubernetes Enhancement Proposal (KEP) process"
icon: fa-upload
- url: "/docs/imported/community/keps/"
+ url: "/docs/community/keps/"
- label: "Understand the API conventions"
icon: fa-map-o
url: "https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md"
diff --git a/data/user-personas/contributors/community-contributor.yaml b/data/user-personas/contributors/community-contributor.yaml
index 30194dc553..217162d9af 100644
--- a/data/user-personas/contributors/community-contributor.yaml
+++ b/data/user-personas/contributors/community-contributor.yaml
@@ -5,10 +5,10 @@ index: 1
foundational:
- label: "Contribute to the Kubernetes OSS project"
icon: fa-users
- url: "/docs/imported/community/guide/"
+ url: "/docs/community/guide/"
- label: "Find out about mentoring initiatives"
icon: fa-graduation-cap
- url: "/docs/imported/community/mentoring/"
+ url: "/docs/community/mentoring/"
intermediate:
- label: "Apply for community membership as a member, reviewer, approver, owner, or maintainer"
icon: fa-user-plus
diff --git a/data/user-personas/contributors/docs-contributor.yaml b/data/user-personas/contributors/docs-contributor.yaml
index a48ce4d76f..0d5e878ed2 100644
--- a/data/user-personas/contributors/docs-contributor.yaml
+++ b/data/user-personas/contributors/docs-contributor.yaml
@@ -14,7 +14,7 @@ foundational:
url: "/docs/home/contribute/review-issues/"
- label: "Create a documentation pull request (PR)"
icon: fa-pencil-square-o
- url: "/docs/home/contribute/create-pull-request/"
+ url: "/docs/contribute/start/"
- label: "Stage documentation changes"
icon: fa-eye
url: "/docs/home/contribute/stage-documentation-changes/#staging-a-pull-request"
diff --git a/layouts/case-studies/list.html b/layouts/case-studies/list.html
new file mode 100644
index 0000000000..d19df3bbd5
--- /dev/null
+++ b/layouts/case-studies/list.html
@@ -0,0 +1,58 @@
+{{ define "main" }}
+{{ $featured := where .Pages "Params.featured" true }}
+
+
+
The last error encountered during detach operation, if any. This field must only be set by the entity completing the detach operation, i.e. the external-attacher.
-
VolumeAttachmentList v1beta1 storage
+
VolumeAttachmentList v1beta1 storage
Field
Description
@@ -14593,8 +14593,8 @@ $ curl -X GET 'http://127.0.0.1:8001/api/v1/watch/namespaces/default/services/de
Versions is the list of all supported versions for this resource. If Version field is provided, this field is optional. Validation: All versions must use the same validation schema for now. i.e., top level Validation field is applied to all of these versions. Order: The version name will be used to compute the order. If the version string is "kube-like", it will sort above non "kube-like" version strings, which are ordered lexicographically. "Kube-like" versions start with a "v", then are followed by a number (the major version), then optionally the string "alpha" or "beta" and another number (the minor version). These are sorted first by GA > beta > alpha (where GA is a version with no suffix such as beta or alpha), and then by comparing major version, then minor version. An example sorted list of versions: v10, v2, v1, v11beta2, v10beta3, v3beta1, v12alpha1, v11alpha2, foo1, foo10.
@@ -15304,7 +15304,7 @@ $ curl -X GET 'http://127.0.0.1:8001/api/v1/watch/namespaces/default/services/de
storedVersions string array
StoredVersions are all versions of CustomResources that were ever persisted. Tracking these versions allows a migration path for stored versions in etcd. The field is mutable so the migration controller can first finish a migration to another version (i.e. that no old objects are left in the storage), and then remove the rest of the versions from this list. None of the versions in this list can be removed from the spec.Versions field.
@@ -19868,10 +19868,10 @@ $ curl -X GET 'http://127.0.0.1:8001/api/v1/watch/namespaces/default/services/de
versionPriority integer
VersionPriority controls the ordering of this API version inside of its group. Must be greater than zero. The primary sort is based on VersionPriority, ordered highest to lowest (20 before 10). Since it's inside of a group, the number can be small, probably in the 10s. In case of equal version priorities, the version string will be used to compute the order inside a group. If the version string is "kube-like", it will sort above non "kube-like" version strings, which are ordered lexicographically. "Kube-like" versions start with a "v", then are followed by a number (the major version), then optionally the string "alpha" or "beta" and another number (the minor version). These are sorted first by GA > beta > alpha (where GA is a version with no suffix such as beta or alpha), and then by comparing major version, then minor version. An example sorted list of versions: v10, v2, v1, v11beta2, v10beta3, v3beta1, v12alpha1, v11alpha2, foo1, foo10.
@@ -24956,7 +24956,7 @@ $ curl -X GET 'http://127.0.0.1:8001/api/v1/watch/namespaces/default/services/de
policyTypes string array
List of rule types that the NetworkPolicy relates to. Valid options are Ingress, Egress, or Ingress,Egress. If this field is not specified, it will default based on the existence of Ingress or Egress rules; policies that contain an Egress section are assumed to affect Egress, and all policies (whether or not they contain an Ingress section) are assumed to affect Ingress. If you want to write an egress-only policy, you must explicitly specify policyTypes [ "Egress" ]. Likewise, if you want to write a policy that specifies that no egress is allowed, you must specify a policyTypes value that include "Egress" (since such a policy would not include an Egress section and would otherwise default to just [ "Ingress" ]). This field is beta-level in 1.8
-
NetworkPolicyList v1 networking
+
NetworkPolicyList v1 networking
Field
Description
@@ -24966,8 +24966,8 @@ $ curl -X GET 'http://127.0.0.1:8001/api/v1/watch/namespaces/default/services/de
watch individual changes to a list of NetworkPolicy
HTTP Request
GET /apis/networking.k8s.io/v1/watch/networkpolicies
@@ -25372,7 +25372,7 @@ $ curl -X GET 'http://127.0.0.1:8001/api/v1/watch/namespaces/default/services/de
version string
version is the preferred version of the resource. Empty implies the version of the containing resource list For subresources, this may have a different value, for example: v1 (while inside a v1beta1 version of the core resource's group)".
-
APIServiceCondition v1 apiregistration
+
APIServiceCondition v1 apiregistration.k8s.io
Group
Version
Kind
@@ -25385,7 +25385,7 @@ $ curl -X GET 'http://127.0.0.1:8001/api/v1/watch/namespaces/default/services/de
@@ -26191,7 +26191,7 @@ The contents of the target ConfigMap's Data field will be presented in a vol
statusReplicasPath string
StatusReplicasPath defines the JSON path inside of a CustomResource that corresponds to Scale.Status.Replicas. Only JSON paths without the array notation are allowed. Must be a JSON Path under .status. If there is no value under the given path in the CustomResource, the status replica value in the /scale subresource will default to 0.
@@ -26201,7 +26201,7 @@ The contents of the target ConfigMap's Data field will be presented in a vol
CustomResourceSubresourceStatus defines how to serve the status subresource for CustomResources. Status is represented by the `.status` JSON path inside of a CustomResource. When set, * exposes a /status subresource for the custom resource * PUT requests to the /status subresource take a custom resource object, and ignore changes to anything except the status stanza * PUT/POST/PATCH requests to the custom resource ignore changes to the status stanza
@@ -26672,7 +26672,7 @@ The resulting set of endpoints can be viewed as:
command string array
Command is the command line to execute inside the container, the working directory for the command is root ('/') in the container's filesystem. The command is simply exec'd, it is not run inside a shell, so traditional shell instructions ('|', etc) won't work. To use a shell, you need to explicitly call out to that shell. Exit status of 0 is treated as live/healthy and non-zero is unhealthy.
If result is set with the Failure field, the object will be persisted to storage and then deleted, ensuring that other clients can observe the deletion.
-
JSON v1beta1 apiextensions
+
JSON v1beta1 apiextensions.k8s.io
Group
Version
Kind
@@ -27341,7 +27341,7 @@ DEPRECATED: GitRepo is deprecated. To provision a container with a git repo, mou
JSON represents any valid JSON value. These types are supported: bool, int64, float64, string, []interface{}, map[string]interface{} and nil.
@@ -27521,9 +27521,9 @@ DEPRECATED: GitRepo is deprecated. To provision a container with a git repo, mou
A label selector is a label query over a set of resources. The result of matchLabels and matchExpressions are ANDed. An empty label selector matches all objects. A null label selector matches no objects.
@@ -27633,15 +27633,15 @@ DEPRECATED: GitRepo is deprecated. To provision a container with a git repo, mou
ListMeta describes metadata that synthetic resources must have, including lists and various status objects. A resource may have only one of {ObjectMeta, ListMeta}.
List of destinations for outgoing traffic of pods selected for this rule. Items in this list are combined using a logical OR operation. If this field is empty or missing, this rule matches all destinations (traffic not restricted by destination). If this field is present and contains at least one item, this rule allows traffic only if the traffic matches at least one item in the to list.
-
NetworkPolicyIngressRule v1 networking
+
NetworkPolicyIngressRule v1 networking.k8s.io
Group
Version
Kind
@@ -27925,7 +27925,7 @@ DEPRECATED: GitRepo is deprecated. To provision a container with a git repo, mou
List of ports which should be made accessible on the pods selected for this rule. Each item in this list is combined using a logical OR. If this field is empty or missing, this rule matches all ports (traffic not restricted by port). If this field is present and contains at least one item, then this rule allows traffic only if the traffic matches at least one port in the list.
-
NetworkPolicyPeer v1 networking
+
NetworkPolicyPeer v1 networking.k8s.io
Group
Version
Kind
@@ -27948,8 +27948,8 @@ DEPRECATED: GitRepo is deprecated. To provision a container with a git repo, mou
This is a label selector which selects Pods. This field follows standard label selector semantics; if present but empty, it selects all pods. If NamespaceSelector is also set, then the NetworkPolicyPeer as a whole selects the Pods matching PodSelector in the Namespaces selected by NamespaceSelector. Otherwise it selects the Pods matching PodSelector in the policy's own Namespace.
-
NetworkPolicyPort v1 networking
+
NetworkPolicyPort v1 networking.k8s.io
Group
Version
Kind
@@ -27973,8 +27973,8 @@ DEPRECATED: GitRepo is deprecated. To provision a container with a git repo, mou
@@ -28199,7 +28199,7 @@ DEPRECATED: GitRepo is deprecated. To provision a container with a git repo, mou
systemUUID string
SystemUUID reported by the node. For unique machine identification MachineID is preferred. This field is specific to Red Hat hosts https://access.redhat.com/documentation/en-US/Red_Hat_Subscription_Management/1/html/RHSM/getting-system-uuid.html
-
NonResourceAttributes v1 authorization
+
NonResourceAttributes v1 authorization.k8s.io
Group
Version
Kind
@@ -28212,8 +28212,8 @@ DEPRECATED: GitRepo is deprecated. To provision a container with a git repo, mou
@@ -29214,7 +29214,7 @@ This format is intended to make it difficult to use these numbers without writin
requests object
Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/
-
ResourceRule v1 authorization
+
ResourceRule v1 authorization.k8s.io
Group
Version
Kind
@@ -29227,7 +29227,7 @@ This format is intended to make it difficult to use these numbers without writin
@@ -29329,7 +29329,7 @@ This format is intended to make it difficult to use these numbers without writin
resources string array
Resources is a list of resources this rule applies to. For example: 'pods' means pods. 'pods/log' means the log subresource of pods. '\*' means all resources, but not subresources. 'pods/\*' means all subresources of pods. '\*/scale' means all scale subresources. '\*/\*' means all resources and their subresources. If wildcard is present, the validation rule will ensure resources do not overlap with each other. Depending on the enclosing object, subresources might not be allowed. Required.
@@ -29742,7 +29742,7 @@ The contents of the target Secret's Data field will be presented in a volume
targetPort
Number or name of the port to access on the pods targeted by the service. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. If this is a string, it will be looked up as a named port in the target Pod's container ports. If this is not specified, the value of the 'port' field is used (an identity map). This field is ignored for services with clusterIP=None, and should be omitted or set equal to the 'port' field. More info: https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service
-
ServiceReference v1 apiregistration
+
ServiceReference v1 apiregistration.k8s.io
Group
Version
Kind
@@ -29756,7 +29756,7 @@ The contents of the target Secret's Data field will be presented in a volume
@@ -29953,7 +29953,7 @@ The contents of the target Secret's Data field will be presented in a volume
volumeNamespace string
VolumeNamespace specifies the scope of the volume within StorageOS. If no namespace is specified then the Pod's namespace will be used. This allows the Kubernetes name scoping to be mirrored within StorageOS for tighter integration. Set VolumeName to any name to override the default behaviour. Set to "default" if you are not using namespaces within StorageOS. Namespaces that do not pre-exist within StorageOS will be created.
-
Subject v1 rbac
+
Subject v1 rbac.authorization.k8s.io
Group
Version
Kind
@@ -29967,8 +29967,8 @@ The contents of the target Secret's Data field will be presented in a volume
@@ -29980,7 +29980,7 @@ The contents of the target Secret's Data field will be presented in a volume
namespace string
Namespace of the referenced object. If the object kind is non-namespace, such as "User" or "Group", and this value is not empty the Authorizer should report an error.
-
SubjectRulesReviewStatus v1 authorization
+
SubjectRulesReviewStatus v1 authorization.k8s.io
Group
Version
Kind
@@ -29993,7 +29993,7 @@ The contents of the target Secret's Data field will be presented in a volume
@@ -30098,14 +30098,14 @@ The contents of the target Secret's Data field will be presented in a volume
Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.
@@ -30195,8 +30195,8 @@ The contents of the target Secret's Data field will be presented in a volume
A topology selector term represents the result of label queries. A null or empty topology selector term matches no objects. The requirements of them are ANDed. It provides a subset of functionality as NodeSelectorTerm. This is an alpha feature and may change in the future.
Rules describes what operations on what resources/subresources the webhook cares about. The webhook cares about an operation if it matches _any_ Rule. However, in order to prevent ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks from putting the cluster in a state which cannot be recovered from without completely disabling the plugin, ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks are never called on admission requests for ValidatingWebhookConfiguration and MutatingWebhookConfiguration objects.
@@ -30510,10 +30510,10 @@ The contents of the target Secret's Data field will be presented in a volume
versionPriority integer
VersionPriority controls the ordering of this API version inside of its group. Must be greater than zero. The primary sort is based on VersionPriority, ordered highest to lowest (20 before 10). Since it's inside of a group, the number can be small, probably in the 10s. In case of equal version priorities, the version string will be used to compute the order inside a group. If the version string is "kube-like", it will sort above non "kube-like" version strings, which are ordered lexicographically. "Kube-like" versions start with a "v", then are followed by a number (the major version), then optionally the string "alpha" or "beta" and another number (the minor version). These are sorted first by GA > beta > alpha (where GA is a version with no suffix such as beta or alpha), and then by comparing major version, then minor version. An example sorted list of versions: v10, v2, v1, v11beta2, v10beta3, v3beta1, v12alpha1, v11alpha2, foo1, foo10.
POST /apis/apiregistration.k8s.io/v1beta1/apiservices
@@ -30555,12 +30555,12 @@ The contents of the target Secret's Data field will be presented in a volume
PATCH /apis/apiregistration.k8s.io/v1beta1/apiservices/{name}
@@ -30592,7 +30592,7 @@ The contents of the target Secret's Data field will be presented in a volume
PUT /apis/apiregistration.k8s.io/v1beta1/apiservices/{name}
@@ -30621,11 +30621,11 @@ The contents of the target Secret's Data field will be presented in a volume
DELETE /apis/apiregistration.k8s.io/v1beta1/apiservices/{name}
@@ -30660,7 +30660,7 @@ The contents of the target Secret's Data field will be presented in a volume
DELETE /apis/apiregistration.k8s.io/v1beta1/apiservices
@@ -30686,8 +30686,8 @@ The contents of the target Secret's Data field will be presented in a volume
GET /apis/apiregistration.k8s.io/v1beta1/apiservices/{name}
@@ -30714,7 +30714,7 @@ The contents of the target Secret's Data field will be presented in a volume
GET /apis/apiregistration.k8s.io/v1beta1/apiservices
@@ -30740,7 +30740,7 @@ The contents of the target Secret's Data field will be presented in a volume
GET /apis/apiregistration.k8s.io/v1beta1/watch/apiservices/{name}
@@ -30773,7 +30773,7 @@ The contents of the target Secret's Data field will be presented in a volume
GET /apis/apiregistration.k8s.io/v1beta1/watch/apiservices
@@ -30799,8 +30799,8 @@ The contents of the target Secret's Data field will be presented in a volume
partially update status of the specified APIService
HTTP Request
PATCH /apis/apiregistration.k8s.io/v1beta1/apiservices/{name}/status
@@ -30832,7 +30832,7 @@ The contents of the target Secret's Data field will be presented in a volume
GET /apis/apiregistration.k8s.io/v1beta1/apiservices/{name}/status
@@ -30857,7 +30857,7 @@ The contents of the target Secret's Data field will be presented in a volume
PUT /apis/apiregistration.k8s.io/v1beta1/apiservices/{name}/status
@@ -30902,7 +30902,7 @@ The contents of the target Secret's Data field will be presented in a volume
POST /apis/rbac.authorization.k8s.io/v1beta1/clusterroles
@@ -31055,12 +31055,12 @@ The contents of the target Secret's Data field will be presented in a volume
PATCH /apis/rbac.authorization.k8s.io/v1beta1/clusterroles/{name}
@@ -31092,7 +31092,7 @@ The contents of the target Secret's Data field will be presented in a volume
PUT /apis/rbac.authorization.k8s.io/v1beta1/clusterroles/{name}
@@ -31121,11 +31121,11 @@ The contents of the target Secret's Data field will be presented in a volume
DELETE /apis/rbac.authorization.k8s.io/v1beta1/clusterroles/{name}
@@ -31160,7 +31160,7 @@ The contents of the target Secret's Data field will be presented in a volume
DELETE /apis/rbac.authorization.k8s.io/v1beta1/clusterroles
@@ -31186,8 +31186,8 @@ The contents of the target Secret's Data field will be presented in a volume
GET /apis/rbac.authorization.k8s.io/v1beta1/clusterroles/{name}
@@ -31212,7 +31212,7 @@ The contents of the target Secret's Data field will be presented in a volume
GET /apis/rbac.authorization.k8s.io/v1beta1/clusterroles
@@ -31238,7 +31238,7 @@ The contents of the target Secret's Data field will be presented in a volume
GET /apis/rbac.authorization.k8s.io/v1beta1/watch/clusterroles/{name}
@@ -31271,7 +31271,7 @@ The contents of the target Secret's Data field will be presented in a volume
GET /apis/rbac.authorization.k8s.io/v1beta1/watch/clusterroles
@@ -31310,7 +31310,7 @@ The contents of the target Secret's Data field will be presented in a volume
POST /apis/rbac.authorization.k8s.io/v1alpha1/clusterroles
@@ -31356,12 +31356,12 @@ The contents of the target Secret's Data field will be presented in a volume
PATCH /apis/rbac.authorization.k8s.io/v1alpha1/clusterroles/{name}
@@ -31393,7 +31393,7 @@ The contents of the target Secret's Data field will be presented in a volume
PUT /apis/rbac.authorization.k8s.io/v1alpha1/clusterroles/{name}
@@ -31422,11 +31422,11 @@ The contents of the target Secret's Data field will be presented in a volume
DELETE /apis/rbac.authorization.k8s.io/v1alpha1/clusterroles/{name}
@@ -31461,7 +31461,7 @@ The contents of the target Secret's Data field will be presented in a volume
DELETE /apis/rbac.authorization.k8s.io/v1alpha1/clusterroles
@@ -31487,8 +31487,8 @@ The contents of the target Secret's Data field will be presented in a volume
GET /apis/rbac.authorization.k8s.io/v1alpha1/clusterroles/{name}
@@ -31513,7 +31513,7 @@ The contents of the target Secret's Data field will be presented in a volume
GET /apis/rbac.authorization.k8s.io/v1alpha1/clusterroles
@@ -31539,7 +31539,7 @@ The contents of the target Secret's Data field will be presented in a volume
GET /apis/rbac.authorization.k8s.io/v1alpha1/watch/clusterroles/{name}
@@ -31572,7 +31572,7 @@ The contents of the target Secret's Data field will be presented in a volume
GET /apis/rbac.authorization.k8s.io/v1alpha1/watch/clusterroles
@@ -31611,7 +31611,7 @@ The contents of the target Secret's Data field will be presented in a volume
POST /apis/rbac.authorization.k8s.io/v1beta1/clusterrolebindings
@@ -31657,12 +31657,12 @@ The contents of the target Secret's Data field will be presented in a volume
PATCH /apis/rbac.authorization.k8s.io/v1beta1/clusterrolebindings/{name}
@@ -31694,7 +31694,7 @@ The contents of the target Secret's Data field will be presented in a volume
PUT /apis/rbac.authorization.k8s.io/v1beta1/clusterrolebindings/{name}
@@ -31723,11 +31723,11 @@ The contents of the target Secret's Data field will be presented in a volume
DELETE /apis/rbac.authorization.k8s.io/v1beta1/clusterrolebindings/{name}
@@ -31762,7 +31762,7 @@ The contents of the target Secret's Data field will be presented in a volume
DELETE /apis/rbac.authorization.k8s.io/v1beta1/clusterrolebindings
@@ -31788,8 +31788,8 @@ The contents of the target Secret's Data field will be presented in a volume
GET /apis/rbac.authorization.k8s.io/v1beta1/clusterrolebindings/{name}
@@ -31814,7 +31814,7 @@ The contents of the target Secret's Data field will be presented in a volume
GET /apis/rbac.authorization.k8s.io/v1beta1/clusterrolebindings
@@ -31840,7 +31840,7 @@ The contents of the target Secret's Data field will be presented in a volume
watch changes to an object of kind ClusterRoleBinding
HTTP Request
GET /apis/rbac.authorization.k8s.io/v1beta1/watch/clusterrolebindings/{name}
@@ -31873,7 +31873,7 @@ The contents of the target Secret's Data field will be presented in a volume
watch individual changes to a list of ClusterRoleBinding
HTTP Request
GET /apis/rbac.authorization.k8s.io/v1beta1/watch/clusterrolebindings
@@ -31912,7 +31912,7 @@ The contents of the target Secret's Data field will be presented in a volume
POST /apis/rbac.authorization.k8s.io/v1alpha1/clusterrolebindings
@@ -31958,12 +31958,12 @@ The contents of the target Secret's Data field will be presented in a volume
PATCH /apis/rbac.authorization.k8s.io/v1alpha1/clusterrolebindings/{name}
@@ -31995,7 +31995,7 @@ The contents of the target Secret's Data field will be presented in a volume
PUT /apis/rbac.authorization.k8s.io/v1alpha1/clusterrolebindings/{name}
@@ -32024,11 +32024,11 @@ The contents of the target Secret's Data field will be presented in a volume
DELETE /apis/rbac.authorization.k8s.io/v1alpha1/clusterrolebindings/{name}
@@ -32063,7 +32063,7 @@ The contents of the target Secret's Data field will be presented in a volume
DELETE /apis/rbac.authorization.k8s.io/v1alpha1/clusterrolebindings
@@ -32089,8 +32089,8 @@ The contents of the target Secret's Data field will be presented in a volume
GET /apis/rbac.authorization.k8s.io/v1alpha1/clusterrolebindings/{name}
@@ -32115,7 +32115,7 @@ The contents of the target Secret's Data field will be presented in a volume
GET /apis/rbac.authorization.k8s.io/v1alpha1/clusterrolebindings
@@ -32141,7 +32141,7 @@ The contents of the target Secret's Data field will be presented in a volume
watch changes to an object of kind ClusterRoleBinding
HTTP Request
GET /apis/rbac.authorization.k8s.io/v1alpha1/watch/clusterrolebindings/{name}
@@ -32174,7 +32174,7 @@ The contents of the target Secret's Data field will be presented in a volume
watch individual changes to a list of ClusterRoleBinding
HTTP Request
GET /apis/rbac.authorization.k8s.io/v1alpha1/watch/clusterrolebindings
@@ -32266,9 +32266,9 @@ The contents of the target Secret's Data field will be presented in a volume
@@ -47620,7 +47620,7 @@ $ curl -X GET 'http://127.0.0.1:8001/apis/extensions/v1beta1/watch/namespaces/de
volumeBindingMode string
VolumeBindingMode indicates how PersistentVolumeClaims should be provisioned and bound. When unset, VolumeBindingImmediate is used. This field is alpha-level and is only honored by servers that enable the VolumeScheduling feature.
-
StorageClassList v1beta1 storage
+
StorageClassList v1beta1 storage
Field
Description
@@ -47630,8 +47630,8 @@ $ curl -X GET 'http://127.0.0.1:8001/apis/extensions/v1beta1/watch/namespaces/de
The last error encountered during detach operation, if any. This field must only be set by the entity completing the detach operation, i.e. the external-attacher.
-
VolumeAttachmentList v1alpha1 storage
+
VolumeAttachmentList v1alpha1 storage
Field
Description
@@ -48237,8 +48237,8 @@ $ curl -X GET 'http://127.0.0.1:8001/apis/extensions/v1beta1/watch/namespaces/de
- 
- 
- 
- 
- 
+ 
