From b716a92b5e40e1c2ecaf67f186c1df61d4710574 Mon Sep 17 00:00:00 2001 From: Jason Murray Date: Tue, 15 Nov 2016 07:37:30 +0100 Subject: [PATCH 01/68] Improve Grammar for Authentication strategies --- docs/admin/authentication.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/admin/authentication.md b/docs/admin/authentication.md index 6819677107..4015610e52 100644 --- a/docs/admin/authentication.md +++ b/docs/admin/authentication.md @@ -35,7 +35,7 @@ or be treated as an anonymous user. Kubernetes uses client certificates, bearer tokens, or HTTP basic auth to authenticate API requests through authentication plugins. As HTTP request are -made to the API server plugins attempts to associate the following attributes +made to the API server, plugins attempt to associate the following attributes with the request: * Username: a string which identifies the end user. Common values might be `kube-admin` or `jane@example.com`. From 4a32cb82da3be836358f3e1a9cc55860a80f6eb9 Mon Sep 17 00:00:00 2001 From: Zihong Zheng Date: Mon, 21 Nov 2016 19:38:20 -0800 Subject: [PATCH 02/68] Updates addons section for cluster-components --- docs/admin/cluster-components.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/admin/cluster-components.md b/docs/admin/cluster-components.md index c1bcae8577..823ebd64d6 100644 --- a/docs/admin/cluster-components.md +++ b/docs/admin/cluster-components.md @@ -61,12 +61,12 @@ selects a node for them to run on. ### addons -Addons are pods and services that implement cluster features. They don't run on -the master VM, but currently the default setup scripts that make the API calls -to create these pods and services does run on the master VM. See: -[kube-master-addons](http://releases.k8s.io/HEAD/cluster/saltbase/salt/kube-master-addons/kube-master-addons.sh) +Addons are pods and services that implement cluster features. The pods may be managed +by Deployments, ReplicationContollers, etc. Namespaced addon objects are created in +the "kube-system" namespace. -Addon objects are created in the "kube-system" namespace. +Addon manager takes the responsibility for creating and maintaining addon resources. +See [here](http://releases.k8s.io/HEAD/cluster/addons) for more details. #### DNS From 5dbabed7a96c61937267a434e0f150c6213faed6 Mon Sep 17 00:00:00 2001 From: Brandon Philips Date: Tue, 29 Nov 2016 12:27:56 -0800 Subject: [PATCH 03/68] docs: create /security endpoint Create an easy to remember and locate URL for security disclosure process. This URL will need to be placed in lots of templates and tools so make it easy. --- docs/reporting-security-issues.md | 22 +--------------------- security.md | 28 ++++++++++++++++++++++++++++ 2 files changed, 29 insertions(+), 21 deletions(-) create mode 100644 security.md diff --git a/docs/reporting-security-issues.md b/docs/reporting-security-issues.md index da4da20b3c..28e40cea9c 100644 --- a/docs/reporting-security-issues.md +++ b/docs/reporting-security-issues.md @@ -5,24 +5,4 @@ assignees: --- -If you believe you have discovered a vulnerability or a have a security incident to report, please follow the steps below. This applies to Kubernetes releases v1.0 or later. - -To watch for security and major API announcements, please join our [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernetes-announce) group. - -## Reporting a security issue - -To report an issue, please: - -- Submit a bug report [here](http://goo.gl/vulnz). - - Select 'I want to report a technical security bug in a Google product (SQLi, XSS, etc.).'? - - Select 'Other'? as the Application Type. -- Under reproduction steps, please additionally include - - the words "Kubernetes Security issue" - - Description of the issue - - Kubernetes release (e.g. output of `kubectl version` command, which includes server version.) - - Environment setup (e.g. which "Getting Started Guide" you followed, if any; what node operating system used; what service or software creates your virtual machines, if any) - -An online submission will have the fastest response; however, if you prefer email, please send mail to security@google.com. If you feel the need, please use the [PGP public key](https://services.google.com/corporate/publickey.txt) to encrypt communications. - - - +This document has moved to [http://kubernetes.io/security](http://kubernetes.io/security). diff --git a/security.md b/security.md new file mode 100644 index 0000000000..da4da20b3c --- /dev/null +++ b/security.md @@ -0,0 +1,28 @@ +--- +assignees: +- eparis +- erictune + +--- + +If you believe you have discovered a vulnerability or a have a security incident to report, please follow the steps below. This applies to Kubernetes releases v1.0 or later. + +To watch for security and major API announcements, please join our [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernetes-announce) group. + +## Reporting a security issue + +To report an issue, please: + +- Submit a bug report [here](http://goo.gl/vulnz). + - Select 'I want to report a technical security bug in a Google product (SQLi, XSS, etc.).'? + - Select 'Other'? as the Application Type. +- Under reproduction steps, please additionally include + - the words "Kubernetes Security issue" + - Description of the issue + - Kubernetes release (e.g. output of `kubectl version` command, which includes server version.) + - Environment setup (e.g. which "Getting Started Guide" you followed, if any; what node operating system used; what service or software creates your virtual machines, if any) + +An online submission will have the fastest response; however, if you prefer email, please send mail to security@google.com. If you feel the need, please use the [PGP public key](https://services.google.com/corporate/publickey.txt) to encrypt communications. + + + From 6fb18ed5ddabe4aa1c9fd00a0096a58d3544cfe4 Mon Sep 17 00:00:00 2001 From: Brandon Philips Date: Tue, 29 Nov 2016 13:35:54 -0800 Subject: [PATCH 04/68] security: add the new disclosure process This is the new disclosure process as discussed here: https://github.com/kubernetes/kubernetes/issues/35462 This relies on a doc to be merged into docs/devel/security-release-process.md but this doc can be reviewed in parallel. You can find a draft of the content of that doc on #35462 --- security.md | 28 ---------------------------- security/index.md | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 46 insertions(+), 28 deletions(-) delete mode 100644 security.md create mode 100644 security/index.md diff --git a/security.md b/security.md deleted file mode 100644 index da4da20b3c..0000000000 --- a/security.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -assignees: -- eparis -- erictune - ---- - -If you believe you have discovered a vulnerability or a have a security incident to report, please follow the steps below. This applies to Kubernetes releases v1.0 or later. - -To watch for security and major API announcements, please join our [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernetes-announce) group. - -## Reporting a security issue - -To report an issue, please: - -- Submit a bug report [here](http://goo.gl/vulnz). - - Select 'I want to report a technical security bug in a Google product (SQLi, XSS, etc.).'? - - Select 'Other'? as the Application Type. -- Under reproduction steps, please additionally include - - the words "Kubernetes Security issue" - - Description of the issue - - Kubernetes release (e.g. output of `kubectl version` command, which includes server version.) - - Environment setup (e.g. which "Getting Started Guide" you followed, if any; what node operating system used; what service or software creates your virtual machines, if any) - -An online submission will have the fastest response; however, if you prefer email, please send mail to security@google.com. If you feel the need, please use the [PGP public key](https://services.google.com/corporate/publickey.txt) to encrypt communications. - - - diff --git a/security/index.md b/security/index.md new file mode 100644 index 0000000000..5fe3b5b13c --- /dev/null +++ b/security/index.md @@ -0,0 +1,46 @@ +--- +layout: docwithnav +title: Kubernetes Security and Disclosure Information +permalink: /security/ +assignees: +- eparis +- erictune +- philips +- jessfraz +--- + +## Security Announcements + +Join the [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernetes-announce) group for emails about security and major API announcements. + +## Report a Vulnerability + +We’re extremely grateful for security researchers and users that report vulnerabilities to the Kubernetes Open Source Community. All reports are thoroughly investigated by a set of community volunteers. + +To make a report, please email the private [kubernetes-security@googlegroups.com](mailto:kubernetes-security@googlegroups.com) list with the security details and the details expected for [all Kubernetes bug reports](https://github.com/kubernetes/kubernetes/blob/master/.github/ISSUE_TEMPLATE.md). + +You may encrypt your email to this list using the GPG keys of the [Product Security Team members](https://github.com/kubernetes/community/blob/master/contributors/devel/security-release-process.md#product-security-team-pst). Encryption using GPG is NOT required to make a disclosure. + +### When Should I Report a Vulnerability? + +- You think you discovered a potential security vulnerability in Kubernetes +- You are unsure how a vulnerability affects Kubernetes +- You think you discovered a vulnerability in another project that Kubernetes depends on (e.g. docker, rkt, etcd) + +### When Should I NOT Report a Vulnerability? + +- You need help tuning Kubernetes components for security +- You need help applying security related updates +- Your issue is not security related + +## Security Vulnerability Response + +Each report is acknowledged and analyzed by Product Security Team members within 3 working days. This will set off the [Security Release Process](https://github.com/kubernetes/community/blob/master/contributors/devel/security-release-process.md#product-security-team-pst). + +Any vulnerability information shared with Product Security Team stays within Kubernetes project and will not be disseminated to other projects unless it is necessary to get the issue fixed. + +As the security issue moves from triage, to identified fix, to release planning we will keep the reporter updated. + +## Public Disclosure Timing + +A public disclosure date is negotiated by the Kubernetes product security team and the bug submitter. We prefer to fully disclose the bug as soon as possible once a user mitigation is available. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested, or for vendor coordination. The timeframe for disclosure is from immediate (especially if it's already publicly known) to a few weeks. As a basic default, we expect report date to disclosure date to be on the order of 7 days. The Kubernetes product security team holds the final say when setting a disclosure date. From cf65f25ca974dc1da2298cd3a5c93650251ee9c5 Mon Sep 17 00:00:00 2001 From: Jess Frazelle Date: Fri, 2 Dec 2016 14:13:32 -0800 Subject: [PATCH 05/68] dockerfile: change to alpine base and cleanup This makes the image a lot smaller and it's using an official image as the base to make sure we get security updates etc. The image size went from: ``` REPOSITORY SIZE gcr.io/google-samples/k8sdocs 837 MB ``` To: ``` REPOSITORY SIZE gcr.io/google-samples/k8sdocs 227 MB ``` Signed-off-by: Jess Frazelle --- staging-container/Dockerfile | 21 +++++++++++++++++---- staging-container/start.sh | 7 +++++++ 2 files changed, 24 insertions(+), 4 deletions(-) create mode 100755 staging-container/start.sh diff --git a/staging-container/Dockerfile b/staging-container/Dockerfile index a5b41625b5..cb0d6a0f70 100644 --- a/staging-container/Dockerfile +++ b/staging-container/Dockerfile @@ -1,13 +1,26 @@ -FROM starefossen/ruby-node:2-4 +FROM alpine:3.3 -RUN gem install github-pages +RUN apk add --no-cache \ + build-base \ + ca-certificates \ + libffi-dev \ + nodejs \ + ruby-dev \ + ruby-nokogiri \ + zlib-dev + +RUN gem install \ + bundler \ + github-pages \ + io-console \ + --no-rdoc --no-ri VOLUME /k8sdocs EXPOSE 4000 +COPY start.sh /start.sh WORKDIR /k8sdocs -CMD bundle && jekyll clean && jekyll serve -H 0.0.0.0 -P 4000 - +CMD [ "/start.sh" ] # For instructions, see http://kubernetes.io/editdocs/ diff --git a/staging-container/start.sh b/staging-container/start.sh new file mode 100755 index 0000000000..890e4bb385 --- /dev/null +++ b/staging-container/start.sh @@ -0,0 +1,7 @@ +#!/bin/sh +set -e +set -x + +bundle +bundle exec jekyll clean +bundle exec jekyll serve -H 0.0.0.0 -P 4000 From 01043efa7e40b0432f92db434c5dde57fb7f9c5b Mon Sep 17 00:00:00 2001 From: Bryan Boreham Date: Tue, 18 Oct 2016 11:01:46 +0100 Subject: [PATCH 06/68] Update out-of-date text about creating a client --- docs/user-guide/accessing-the-cluster.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/user-guide/accessing-the-cluster.md b/docs/user-guide/accessing-the-cluster.md index 63134b4909..b08dfa8eb6 100644 --- a/docs/user-guide/accessing-the-cluster.md +++ b/docs/user-guide/accessing-the-cluster.md @@ -182,9 +182,8 @@ From within a pod the recommended ways to connect to API are: Kubernetes API to the localhost interface of the pod, so that other processes in any container of the pod can access it. See this [example of using kubectl proxy in a pod](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/kubectl-container/). - - use the Go client library, and create a client using the `client.NewInCluster()` factory. - This handles locating and authenticating to the apiserver. See this [example of using Go client - library in a pod](https://github.com/kubernetes/client-go/blob/master/examples/in-cluster/main.go). + - use the Go client library, and create a client using the `rest.InClusterConfig()` and `kubernetes.NewForConfig()` functions. + They handle locating and authenticating to the apiserver. [example](https://github.com/kubernetes/client-go/blob/master/examples/in-cluster/main.go) In each case, the credentials of the pod are used to communicate securely with the apiserver. From 53d55320e778c1346c8b7654b21f2e9d0abaa41b Mon Sep 17 00:00:00 2001 From: Junaid Ali Date: Mon, 12 Dec 2016 22:03:46 +0500 Subject: [PATCH 07/68] Improving expose-intro.html - Fixed a typo Signed-off-by: Junaid Ali --- docs/tutorials/kubernetes-basics/expose-intro.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tutorials/kubernetes-basics/expose-intro.html b/docs/tutorials/kubernetes-basics/expose-intro.html index 524e051c68..4e65a16988 100644 --- a/docs/tutorials/kubernetes-basics/expose-intro.html +++ b/docs/tutorials/kubernetes-basics/expose-intro.html @@ -31,7 +31,7 @@

This abstraction will allow us to expose Pods to traffic originating from outside the cluster. Services have their own unique cluster-private IP address and expose a port to receive traffic. If you choose to expose the service outside the cluster, the options are:

    -
  • LoadBalancer - provides a public IP address (what you would typically use when you run Kubernetes on GKE or AWS)
    • +
  • LoadBalancer - provides a public IP address (what you would typically use when you run Kubernetes on GCE or AWS)
  • NodePort - exposes the Service on the same port on each Node of the cluster using NAT (available on all Kubernetes clusters, and in Minikube)
From 61a60eec847124a5905d045e32f90c9ffe08af67 Mon Sep 17 00:00:00 2001 From: unisisdev Date: Fri, 16 Dec 2016 15:16:36 -0300 Subject: [PATCH 08/68] Described how deploy the Dashboard UI --- docs/user-guide/ui.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/docs/user-guide/ui.md b/docs/user-guide/ui.md index 32e3143b52..9316455d95 100644 --- a/docs/user-guide/ui.md +++ b/docs/user-guide/ui.md @@ -16,6 +16,14 @@ Dashboard also provides information on the state of Kubernetes resources in your * TOC {:toc} +## Deploying the Dashboard UI + +The Dashboard UI is not deployed by default. To deploy it please execute: + +``` +kubectl create -f https://rawgit.com/kubernetes/dashboard/master/src/deploy/kubernetes-dashboard.yaml +``` + ## Accessing the Dashboard UI There are multiple ways you can access the Dashboard UI; either by using the kubectl command-line interface, or by accessing the Kubernetes master apiserver using your web browser. From 938bb6843062fa14cd73335c975911ec83f77f50 Mon Sep 17 00:00:00 2001 From: devin-donnelly Date: Wed, 21 Dec 2016 16:34:35 -0800 Subject: [PATCH 09/68] Update ui.md --- docs/user-guide/ui.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/ui.md b/docs/user-guide/ui.md index 9316455d95..1158108416 100644 --- a/docs/user-guide/ui.md +++ b/docs/user-guide/ui.md @@ -18,7 +18,7 @@ Dashboard also provides information on the state of Kubernetes resources in your ## Deploying the Dashboard UI -The Dashboard UI is not deployed by default. To deploy it please execute: +The Dashboard UI is not deployed by default. To deploy it, run the following command: ``` kubectl create -f https://rawgit.com/kubernetes/dashboard/master/src/deploy/kubernetes-dashboard.yaml From bdf6d77a18aebff26a28da9251665321733c82c4 Mon Sep 17 00:00:00 2001 From: Kyle Ibrahim Date: Wed, 21 Dec 2016 18:50:01 -0800 Subject: [PATCH 10/68] Fix typos in thirdpartyresources.md --- docs/user-guide/thirdpartyresources.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/user-guide/thirdpartyresources.md b/docs/user-guide/thirdpartyresources.md index e76c64e295..b6e608b3b9 100644 --- a/docs/user-guide/thirdpartyresources.md +++ b/docs/user-guide/thirdpartyresources.md @@ -34,9 +34,9 @@ $ kubectl explain thirdpartyresource ## Creating a ThirdPartyResource -When you user create a new `ThirdPartyResource`, the Kubernetes API Server reacts by creating a new, namespaced RESTful resource path. For now, non-namespaced objects are not supported. As with existing built-in objects, deleting a namespace deletes all custom objects in that namespace. `ThirdPartyResources` themselves are non-namespaced and are available to all namespaces. +When you create a new `ThirdPartyResource`, the Kubernetes API Server reacts by creating a new, namespaced RESTful resource path. For now, non-namespaced objects are not supported. As with existing built-in objects, deleting a namespace deletes all custom objects in that namespace. `ThirdPartyResources` themselves are non-namespaced and are available to all namespaces. -For example, if a save the following `ThirdPartyResource` to `resource.yaml`: +For example, if you save the following `ThirdPartyResource` to `resource.yaml`: ```yaml apiVersion: extensions/v1beta1 From 383e40f978334792e7ca30399845c9bf38ea813c Mon Sep 17 00:00:00 2001 From: SRaddict Date: Thu, 22 Dec 2016 11:24:05 +0800 Subject: [PATCH 11/68] fix a series punctuation errors --- LICENSE | 2 +- case-studies/index.html | 4 ++-- case-studies/pearson.html | 10 +++++----- case-studies/wikimedia.html | 8 ++++---- docs/admin/admission-controllers.md | 4 ++-- docs/admin/rescheduler.md | 2 +- docs/getting-started-guides/windows/index.md | 6 +++--- docs/tutorials/kubernetes-basics/explore-intro.html | 2 +- docs/user-guide/replicasets.md | 2 +- 9 files changed, 20 insertions(+), 20 deletions(-) diff --git a/LICENSE b/LICENSE index 06c608dcf4..b6988e7edc 100644 --- a/LICENSE +++ b/LICENSE @@ -378,7 +378,7 @@ Section 8 -- Interpretation. Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances -will be considered the “Licensor.” The text of the Creative Commons +will be considered the "Licensor." The text of the Creative Commons public licenses is dedicated to the public domain under the CC0 Public Domain Dedication. Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as diff --git a/case-studies/index.html b/case-studies/index.html index ce14542424..6d288a8bb2 100644 --- a/case-studies/index.html +++ b/case-studies/index.html @@ -17,13 +17,13 @@ title: Case Studies
Pearson -

“We chose Kubernetes because of its flexibility, ease of management and the way it improves our engineers’ productivity.”

+

"We chose Kubernetes because of its flexibility, ease of management and the way it improves our engineers’ productivity."

Read about Pearson
Wikimedia -

“With Kubernetes, we’re simplifying our environment and making it easier for developers to build the tools that make wikis run better.”

+

"With Kubernetes, we’re simplifying our environment and making it easier for developers to build the tools that make wikis run better."

Read about Wikimedia
diff --git a/case-studies/pearson.html b/case-studies/pearson.html index bf871789b9..5eecc6f349 100644 --- a/case-studies/pearson.html +++ b/case-studies/pearson.html @@ -19,7 +19,7 @@ title: Pearson Case Study
Pearson

- “To transform our infrastructure, we had to think beyond simply enabling automated provisioning, we realized we had to build a platform that would allow Pearson developers to build manage and deploy applications in a completely different way. We chose Kubernetes because of its flexibility, ease of management and the way it would improve our engineers’ productivity.”

+ "To transform our infrastructure, we had to think beyond simply enabling automated provisioning, we realized we had to build a platform that would allow Pearson developers to build manage and deploy applications in a completely different way. We chose Kubernetes because of its flexibility, ease of management and the way it would improve our engineers’ productivity."

— Chris Jackson, Director for Cloud Product Engineering, Pearson

@@ -63,9 +63,9 @@ title: Pearson Case Study

Kubernetes powers a comprehensive developer experience

-

Pearson wanted to use as much open source technology as possible for the platform given that it provides both technical and commercial benefits over the duration of the project. Jackson says, “Building an infrastructure platform based on open source technology in Pearson was a no-brainer, the sharing of technical challenges and advanced use cases in a community of people with talent far beyond what we could hire independently allows us to innovate at a level we could not reach on our own. Our engineers enjoy returning code to the community and participating in talks, blogs and meetings, it’s a great way for us to allow our team to express themselves and share the pride they have in their work.”

-

It also wanted to use a container-focused platform. Pearson has 400 development groups and diverse brands with varying business and technical needs. With containers, each brand could experiment with building new types of content using their preferred technologies, and then deliver it using containers. Pearson chose Kubernetes because it believes that is the best technology for managing containers, has the widest community support and offers the most flexible and powerful tools.“

-

Kubernetes is at the core of the platform we’ve built for developers. After we get our big spike in back-to-school in traffic, much of Pearson’s traffic will interact with Kubernetes. It is proving to be as effective as we had hoped,” Jackson says.

+

Pearson wanted to use as much open source technology as possible for the platform given that it provides both technical and commercial benefits over the duration of the project. Jackson says, "Building an infrastructure platform based on open source technology in Pearson was a no-brainer, the sharing of technical challenges and advanced use cases in a community of people with talent far beyond what we could hire independently allows us to innovate at a level we could not reach on our own. Our engineers enjoy returning code to the community and participating in talks, blogs and meetings, it’s a great way for us to allow our team to express themselves and share the pride they have in their work."

+

It also wanted to use a container-focused platform. Pearson has 400 development groups and diverse brands with varying business and technical needs. With containers, each brand could experiment with building new types of content using their preferred technologies, and then deliver it using containers. Pearson chose Kubernetes because it believes that is the best technology for managing containers, has the widest community support and offers the most flexible and powerful tools."

+

Kubernetes is at the core of the platform we’ve built for developers. After we get our big spike in back-to-school in traffic, much of Pearson’s traffic will interact with Kubernetes. It is proving to be as effective as we had hoped," Jackson says.

@@ -76,7 +76,7 @@ title: Pearson Case Study

Encouraging experimentation, saving engineers time

With the new platform, Pearson will increase stability and performance, and to bring products to market more quickly. The company says its engineers will also get a productivity boost because they won’t spend time managing infrastructure. Jackson estimates 15 to 20 percent in productivity savings.

Beyond that, Pearson says the platform will encourage innovation because of the ease with which new applications can be developed, and because applications will be deployed far more quickly than in the past. It expects that will help the company meet its goal of reaching 200 million learners within the next 10 years.

-

“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,” says Jackson.

+

"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," says Jackson.

diff --git a/case-studies/wikimedia.html b/case-studies/wikimedia.html index 00eb47e3e0..0dc910fbe4 100644 --- a/case-studies/wikimedia.html +++ b/case-studies/wikimedia.html @@ -20,7 +20,7 @@ title: Wikimedia Case Study
Wikimedia

- “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.” + "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."

— Yuvi Panda, operations engineer at Wikimedia Foundation and Wikimedia Tool Labs

@@ -67,13 +67,13 @@ title: Wikimedia Case Study

Using Kubernetes to provide tools for maintaining wikis

- Wikimedia Tool Labs is run by a staff of four-and-a-half paid employees and two volunteers. The infrastructure didn't make it easy or intuitive for developers to build bots and other tools to make wikis work more easily. Yuvi says, “It’s incredibly chaotic. We have lots of Perl and Bash duct tape on top of it. Everything is super fragile.” + Wikimedia Tool Labs is run by a staff of four-and-a-half paid employees and two volunteers. The infrastructure didn't make it easy or intuitive for developers to build bots and other tools to make wikis work more easily. Yuvi says, "It’s incredibly chaotic. We have lots of Perl and Bash duct tape on top of it. Everything is super fragile."

To solve the problem, Wikimedia Tool Labs migrated parts of its infrastructure to Kubernetes, in preparation for eventually moving its entire system. Yuvi said Kubernetes greatly simplifies maintenance. The goal is to allow developers creating bots and other tools to use whatever development methods they want, but make it easier for the Wikimedia Tool Labs to maintain the required infrastructure for hosting and sharing them.

- “With Kubernetes, I’ve been able to remove a lot of our custom-made code, which makes everything easier to maintain. Our users’ code also runs in a more stable way than previously,” says Yuvi. + "With Kubernetes, I’ve been able to remove a lot of our custom-made code, which makes everything easier to maintain. Our users’ code also runs in a more stable way than previously," says Yuvi.

@@ -90,7 +90,7 @@ title: Wikimedia Case Study In the future, with a more complete migration to Kubernetes, Wikimedia Tool Labs expects to make it even easier to host and maintain the bots and tools that help run wikis across the world. The tool labs already host approximately 1,300 tools and bots from 800 volunteers, with many more being submitted every day. Twenty percent of the tool labs’ web tools that account for more than 60 percent of web traffic now run on Kubernetes. The tool labs has a 25-node cluster that keeps up with each new Kubernetes release. Many existing web tools are migrating to Kubernetes.

- “Our goal is to make sure that people all over the world can share knowledge as easily as possible. Kubernetes helps with that, by making it easier for wikis everywhere to have the tools they need to thrive,” says Yuvi. + "Our goal is to make sure that people all over the world can share knowledge as easily as possible. Kubernetes helps with that, by making it easier for wikis everywhere to have the tools they need to thrive," says Yuvi.

diff --git a/docs/admin/admission-controllers.md b/docs/admin/admission-controllers.md index 475f2e4be9..de544e3d8b 100644 --- a/docs/admin/admission-controllers.md +++ b/docs/admin/admission-controllers.md @@ -126,7 +126,7 @@ For additional HTTP configuration, refer to the [kubeconfig](/docs/user-guide/ku When faced with an admission decision, the API Server POSTs a JSON serialized api.imagepolicy.v1alpha1.ImageReview object describing the action. This object contains fields describing the containers being admitted, as well as any pod annotations that match `*.image-policy.k8s.io/*`. -Note that webhook API objects are subject to the same versioning compatibility rules as other Kubernetes API objects. Implementers should be aware of looser compatibility promises for alpha objects and check the “apiVersion” field of the request to ensure correct deserialization. Additionally, the API Server must enable the imagepolicy.k8s.io/v1alpha1 API extensions group (`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`). +Note that webhook API objects are subject to the same versioning compatibility rules as other Kubernetes API objects. Implementers should be aware of looser compatibility promises for alpha objects and check the "apiVersion" field of the request to ensure correct deserialization. Additionally, the API Server must enable the imagepolicy.k8s.io/v1alpha1 API extensions group (`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`). An example request body: @@ -151,7 +151,7 @@ An example request body: } ``` -The remote service is expected to fill the ImageReviewStatus field of the request and respond to either allow or disallow access. The response body’s “spec” field is ignored and may be omitted. A permissive response would return: +The remote service is expected to fill the ImageReviewStatus field of the request and respond to either allow or disallow access. The response body’s "spec" field is ignored and may be omitted. A permissive response would return: ``` { diff --git a/docs/admin/rescheduler.md b/docs/admin/rescheduler.md index c9a3bd074c..651fdf15b5 100644 --- a/docs/admin/rescheduler.md +++ b/docs/admin/rescheduler.md @@ -30,7 +30,7 @@ given the pods that are already running in the cluster the rescheduler tries to free up space for the add-on by evicting some pods; then the scheduler will schedule the add-on pod. To avoid situation when another pod is scheduled into the space prepared for the critical add-on, -the chosen node gets a temporary taint “CriticalAddonsOnly” before the eviction(s) +the chosen node gets a temporary taint "CriticalAddonsOnly" before the eviction(s) (see [more details](https://github.com/kubernetes/kubernetes/blob/master/docs/design/taint-toleration-dedicated.md)). Each critical add-on has to tolerate it, the other pods shouldn't tolerate the taint. The tain is removed once the add-on is successfully scheduled. diff --git a/docs/getting-started-guides/windows/index.md b/docs/getting-started-guides/windows/index.md index 3096bed7eb..b5926744ae 100644 --- a/docs/getting-started-guides/windows/index.md +++ b/docs/getting-started-guides/windows/index.md @@ -18,15 +18,15 @@ In Kubernetes version 1.5, Windows Server Containers for Kubernetes is supported Network is achieved using L3 routing. Because third-party networking plugins (e.g. flannel, calico, etc) don’t natively work on Windows Server, existing technology that is built into the Windows and Linux operating systems is relied on. In this L3 networking approach, a /16 subnet is chosen for the cluster nodes, and a /24 subnet is assigned to each worker node. All pods on a given worker node will be connected to the /24 subnet. This allows pods on the same node to communicate with each other. In order to enable networking between pods running on different nodes, routing features that are built into Windows Server 2016 and Linux are used. ### Linux -The above networking approach is already supported on Linux using a bridge interface, which essentially creates a private network local to the node. Similar to the Windows side, routes to all other pod CIDRs must be created in order to send packets via the “public” NIC. +The above networking approach is already supported on Linux using a bridge interface, which essentially creates a private network local to the node. Similar to the Windows side, routes to all other pod CIDRs must be created in order to send packets via the "public" NIC. ### Windows Each Window Server node should have the following configuration: 1. Two NICs (virtual networking adapters) are required on each Windows Server node - The two Windows container networking modes of interest (transparent and L2 bridge) use an external Hyper-V virtual switch. This means that one of the NICs is entirely allocated to the bridge, creating the need for the second NIC. 2. Transparent container network created - This is a manual configuration step and is shown in **_Route Setup_** section below -3. RRAS (Routing) Windows feature enabled - Allows routing between NICs on the box, and also “captures” packets that have the destination IP of a POD running on the node. To enable, open “Server Manager”. Click on “Roles”, “Add Roles”. Click “Next”. Select “Network Policy and Access Services”. Click on “Routing and Remote Access Service” and the underlying checkboxes -4. Routes defined pointing to the other pod CIDRs via the “public” NIC - These routes are added to the built-in routing table as shown in **_Route Setup_** section below +3. RRAS (Routing) Windows feature enabled - Allows routing between NICs on the box, and also "captures" packets that have the destination IP of a POD running on the node. To enable, open "Server Manager". Click on "Roles", "Add Roles". Click "Next". Select "Network Policy and Access Services". Click on "Routing and Remote Access Service" and the underlying checkboxes +4. Routes defined pointing to the other pod CIDRs via the "public" NIC - These routes are added to the built-in routing table as shown in **_Route Setup_** section below The following diagram illustrates the Windows Server networking setup for Kubernetes Setup ![Windows Setup](windows-setup.png) diff --git a/docs/tutorials/kubernetes-basics/explore-intro.html b/docs/tutorials/kubernetes-basics/explore-intro.html index edc813d3d4..56bde41cfd 100644 --- a/docs/tutorials/kubernetes-basics/explore-intro.html +++ b/docs/tutorials/kubernetes-basics/explore-intro.html @@ -34,7 +34,7 @@ title: Viewing Pods and Nodes
  • Networking, as a unique cluster IP address
  • Information about how to run each container, such as the container image version or specific ports to use
    • -

    A Pod models an application-specific “logical host” and can contain different application containers which are relatively tightly coupled. For example, a Pod might include both the container with your Node.js app as well as a different container that feeds the data to be published by the Node.js webserver. The containers in a Pod share an IP Address and port space, are always co-located and co-scheduled, and run in a shared context on the same Node.

    +

    A Pod models an application-specific "logical host" and can contain different application containers which are relatively tightly coupled. For example, a Pod might include both the container with your Node.js app as well as a different container that feeds the data to be published by the Node.js webserver. The containers in a Pod share an IP Address and port space, are always co-located and co-scheduled, and run in a shared context on the same Node.

    Pods are the atomic unit on the Kubernetes platform. When we create a Deployment on Kubernetes, that Deployment creates Pods with containers inside them (as opposed to creating containers directly). Each Pod is tied to the Node where it is scheduled, and remains there until termination (according to restart policy) or deletion. In case of a Node failure, identical Pods are scheduled on other available Nodes in the cluster.

    diff --git a/docs/user-guide/replicasets.md b/docs/user-guide/replicasets.md index f0aa08bf04..86e60cffda 100644 --- a/docs/user-guide/replicasets.md +++ b/docs/user-guide/replicasets.md @@ -35,7 +35,7 @@ their Replica Sets. ## When to use a Replica Set? -A Replica Set ensures that a specified number of pod “replicas” are running at any given +A Replica Set ensures that a specified number of pod "replicas" are running at any given time. However, a Deployment is a higher-level concept that manages Replica Sets and provides declarative updates to pods along with a lot of other useful features. Therefore, we recommend using Deployments instead of directly using Replica Sets, unless From b27310d81a1d9404781de7dea669f71805d0c20a Mon Sep 17 00:00:00 2001 From: tim-zju <21651152@zju.edu.cn> Date: Thu, 22 Dec 2016 14:37:10 +0800 Subject: [PATCH 12/68] symbol errors Signed-off-by: tim-zju <21651152@zju.edu.cn> --- CONTRIBUTING.md | 2 +- LICENSE | 2 +- _includes/partner-script.js | 6 +- case-studies/index.html | 8 +- case-studies/pearson.html | 20 +- case-studies/wikimedia.html | 12 +- community.html | 4 +- docs/admin/admission-controllers.md | 4 +- docs/admin/networking.md | 2 +- docs/admin/rescheduler.md | 3 +- docs/getting-started-guides/logging.md | 2 +- docs/getting-started-guides/meanstack.md | 26 +- docs/getting-started-guides/windows/index.md | 14 +- docs/hellonode.md | 22 +- .../kubernetes-basics/cluster-intro.html | 2 +- .../kubernetes-basics/deploy-intro.html | 4 +- .../kubernetes-basics/explore-intro.html | 4 +- .../kubernetes-basics/expose-intro.html | 6 +- .../kubernetes-basics/scale-intro.html | 2 +- .../kubernetes-basics/update-intro.html | 2 +- .../stateful-application/zookeeper.md | 352 +++++++++--------- docs/user-guide/configuring-containers.md | 2 +- docs/user-guide/managing-deployments.md | 40 +- docs/user-guide/pod-security-policy/index.md | 38 +- docs/user-guide/prereqs.md | 2 +- docs/user-guide/replicasets.md | 2 +- .../replication-controller/index.md | 8 +- docs/user-guide/security-context.md | 7 +- index.html | 16 +- 29 files changed, 306 insertions(+), 308 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 9dd8149a15..934d7947ae 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -33,4 +33,4 @@ Note that code issues should be filed against the main kubernetes repository, wh ### Submitting Documentation Pull Requests -If you’re fixing an issue in the existing documentation, you should submit a PR against the master branch. Follow [these instructions to create a documentation pull request against the kubernetes.io repository](http://kubernetes.io/docs/contribute/create-pull-request/). +If you're fixing an issue in the existing documentation, you should submit a PR against the master branch. Follow [these instructions to create a documentation pull request against the kubernetes.io repository](http://kubernetes.io/docs/contribute/create-pull-request/). diff --git a/LICENSE b/LICENSE index 06c608dcf4..b6988e7edc 100644 --- a/LICENSE +++ b/LICENSE @@ -378,7 +378,7 @@ Section 8 -- Interpretation. Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances -will be considered the “Licensor.” The text of the Creative Commons +will be considered the "Licensor." The text of the Creative Commons public licenses is dedicated to the public domain under the CC0 Public Domain Dedication. Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as diff --git a/_includes/partner-script.js b/_includes/partner-script.js index 4d0a117620..c291521a01 100644 --- a/_includes/partner-script.js +++ b/_includes/partner-script.js @@ -54,7 +54,7 @@ name: 'Skippbox', logo: 'skippbox', link: 'http://www.skippbox.com/tag/products/', - blurb: 'Creator of Cabin the first mobile application for Kubernetes, and kompose. Skippbox’s solutions distill all the power of k8s in simple easy to use interfaces.' + blurb: 'Creator of Cabin the first mobile application for Kubernetes, and kompose. Skippbox's solutions distill all the power of k8s in simple easy to use interfaces.' }, { type: 0, @@ -89,7 +89,7 @@ name: 'Intel', logo: 'intel', link: 'https://tectonic.com/press/intel-coreos-collaborate-on-openstack-with-kubernetes.html', - blurb: 'Powering the GIFEE (Google’s Infrastructure for Everyone Else), to run OpenStack deployments on Kubernetes.' + blurb: 'Powering the GIFEE (Google's Infrastructure for Everyone Else), to run OpenStack deployments on Kubernetes.' }, { type: 0, @@ -243,7 +243,7 @@ name: 'Samsung SDS', logo: 'samsung_sds', link: 'http://www.samsungsdsa.com/cloud-infrastructure_kubernetes', - blurb: 'Samsung SDS’s Cloud Native Computing Team offers expert consulting across the range of technical aspects involved in building services targeted at a Kubernetes cluster.' + blurb: 'Samsung SDS's Cloud Native Computing Team offers expert consulting across the range of technical aspects involved in building services targeted at a Kubernetes cluster.' }, { type: 1, diff --git a/case-studies/index.html b/case-studies/index.html index ce14542424..f593d73fb9 100644 --- a/case-studies/index.html +++ b/case-studies/index.html @@ -17,19 +17,19 @@ title: Case Studies
    Pearson -

    “We chose Kubernetes because of its flexibility, ease of management and the way it improves our engineers’ productivity.”

    +

    "We chose Kubernetes because of its flexibility, ease of management and the way it improves our engineers' productivity."

    Read about Pearson
    Wikimedia -

    “With Kubernetes, we’re simplifying our environment and making it easier for developers to build the tools that make wikis run better.”

    +

    "With Kubernetes, we're simplifying our environment and making it easier for developers to build the tools that make wikis run better."

    Read about Wikimedia
    eBay -

    Inside eBay’s shift to Kubernetes and containers atop OpenStack

    +

    Inside eBay's shift to Kubernetes and containers atop OpenStack

    Read about eBay
    @@ -45,7 +45,7 @@ title: Case Studies
    - + diff --git a/case-studies/pearson.html b/case-studies/pearson.html index bf871789b9..50f16ce7ae 100644 --- a/case-studies/pearson.html +++ b/case-studies/pearson.html @@ -13,13 +13,13 @@ title: Pearson Case Study
    -

    Using Kubernetes to reinvent the world’s largest educational company

    +

    Using Kubernetes to reinvent the world's largest educational company

    - Pearson, the world’s education company, serving 75 million learners worldwide, 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 that requires an infrastructure platform that is able to scale quickly and deliver products to market faster. So Pearson’s Cloud Technology team chose Kubernetes to help build a platform to meet the business requirements.

    + Pearson, the world's education company, serving 75 million learners worldwide, 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 that requires an infrastructure platform that is able to scale quickly and deliver products to market faster. So Pearson's Cloud Technology team chose Kubernetes to help build a platform to meet the business requirements.

    Pearson

    - “To transform our infrastructure, we had to think beyond simply enabling automated provisioning, we realized we had to build a platform that would allow Pearson developers to build manage and deploy applications in a completely different way. We chose Kubernetes because of its flexibility, ease of management and the way it would improve our engineers’ productivity.”

    + "To transform our infrastructure, we had to think beyond simply enabling automated provisioning, we realized we had to build a platform that would allow Pearson developers to build manage and deploy applications in a completely different way. We chose Kubernetes because of its flexibility, ease of management and the way it would improve our engineers' productivity."

    — Chris Jackson, Director for Cloud Product Engineering, Pearson

    @@ -38,7 +38,7 @@ title: Pearson Case Study

    Why Kubernetes:

      -
    • Kubernetes will allow Pearson’s teams to develop their apps in a consistent manner, saving time and minimizing complexity.
      • +
    • Kubernetes will allow Pearson's teams to develop their apps in a consistent manner, saving time and minimizing complexity.
    @@ -52,7 +52,7 @@ title: Pearson Case Study

    Results:

      -
    • Pearson is building an enterprise-wide platform for delivering innovative, web-based educational content. They expect engineers’ productivity to increase by up to 20 percent.
      • +
    • Pearson is building an enterprise-wide platform for delivering innovative, web-based educational content. They expect engineers' productivity to increase by up to 20 percent.
    @@ -63,9 +63,9 @@ title: Pearson Case Study

    Kubernetes powers a comprehensive developer experience

    -

    Pearson wanted to use as much open source technology as possible for the platform given that it provides both technical and commercial benefits over the duration of the project. Jackson says, “Building an infrastructure platform based on open source technology in Pearson was a no-brainer, the sharing of technical challenges and advanced use cases in a community of people with talent far beyond what we could hire independently allows us to innovate at a level we could not reach on our own. Our engineers enjoy returning code to the community and participating in talks, blogs and meetings, it’s a great way for us to allow our team to express themselves and share the pride they have in their work.”

    -

    It also wanted to use a container-focused platform. Pearson has 400 development groups and diverse brands with varying business and technical needs. With containers, each brand could experiment with building new types of content using their preferred technologies, and then deliver it using containers. Pearson chose Kubernetes because it believes that is the best technology for managing containers, has the widest community support and offers the most flexible and powerful tools.“

    -

    Kubernetes is at the core of the platform we’ve built for developers. After we get our big spike in back-to-school in traffic, much of Pearson’s traffic will interact with Kubernetes. It is proving to be as effective as we had hoped,” Jackson says.

    +

    Pearson wanted to use as much open source technology as possible for the platform given that it provides both technical and commercial benefits over the duration of the project. Jackson says, "Building an infrastructure platform based on open source technology in Pearson was a no-brainer, the sharing of technical challenges and advanced use cases in a community of people with talent far beyond what we could hire independently allows us to innovate at a level we could not reach on our own. Our engineers enjoy returning code to the community and participating in talks, blogs and meetings, it's a great way for us to allow our team to express themselves and share the pride they have in their work."

    +

    It also wanted to use a container-focused platform. Pearson has 400 development groups and diverse brands with varying business and technical needs. With containers, each brand could experiment with building new types of content using their preferred technologies, and then deliver it using containers. Pearson chose Kubernetes because it believes that is the best technology for managing containers, has the widest community support and offers the most flexible and powerful tools."

    +

    Kubernetes is at the core of the platform we've built for developers. After we get our big spike in back-to-school in traffic, much of Pearson's traffic will interact with Kubernetes. It is proving to be as effective as we had hoped," Jackson says.

    @@ -74,9 +74,9 @@ title: Pearson Case Study

    Encouraging experimentation, saving engineers time

    -

    With the new platform, Pearson will increase stability and performance, and to bring products to market more quickly. The company says its engineers will also get a productivity boost because they won’t spend time managing infrastructure. Jackson estimates 15 to 20 percent in productivity savings.

    +

    With the new platform, Pearson will increase stability and performance, and to bring products to market more quickly. The company says its engineers will also get a productivity boost because they won't spend time managing infrastructure. Jackson estimates 15 to 20 percent in productivity savings.

    Beyond that, Pearson says the platform will encourage innovation because of the ease with which new applications can be developed, and because applications will be deployed far more quickly than in the past. It expects that will help the company meet its goal of reaching 200 million learners within the next 10 years.

    -

    “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,” says Jackson.

    +

    "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," says Jackson.

    diff --git a/case-studies/wikimedia.html b/case-studies/wikimedia.html index 00eb47e3e0..2d3b686128 100644 --- a/case-studies/wikimedia.html +++ b/case-studies/wikimedia.html @@ -20,7 +20,7 @@ title: Wikimedia Case Study
    Wikimedia

    - “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.” + "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."

    — Yuvi Panda, operations engineer at Wikimedia Foundation and Wikimedia Tool Labs

    @@ -67,13 +67,13 @@ title: Wikimedia Case Study

    Using Kubernetes to provide tools for maintaining wikis

    - Wikimedia Tool Labs is run by a staff of four-and-a-half paid employees and two volunteers. The infrastructure didn't make it easy or intuitive for developers to build bots and other tools to make wikis work more easily. Yuvi says, “It’s incredibly chaotic. We have lots of Perl and Bash duct tape on top of it. Everything is super fragile.” + Wikimedia Tool Labs is run by a staff of four-and-a-half paid employees and two volunteers. The infrastructure didn't make it easy or intuitive for developers to build bots and other tools to make wikis work more easily. Yuvi says, "It's incredibly chaotic. We have lots of Perl and Bash duct tape on top of it. Everything is super fragile."

    To solve the problem, Wikimedia Tool Labs migrated parts of its infrastructure to Kubernetes, in preparation for eventually moving its entire system. Yuvi said Kubernetes greatly simplifies maintenance. The goal is to allow developers creating bots and other tools to use whatever development methods they want, but make it easier for the Wikimedia Tool Labs to maintain the required infrastructure for hosting and sharing them.

    - “With Kubernetes, I’ve been able to remove a lot of our custom-made code, which makes everything easier to maintain. Our users’ code also runs in a more stable way than previously,” says Yuvi. + "With Kubernetes, I've been able to remove a lot of our custom-made code, which makes everything easier to maintain. Our users' code also runs in a more stable way than previously," says Yuvi.

    @@ -84,13 +84,13 @@ title: Wikimedia Case Study

    Simplifying infrastructure and keeping wikis running better

    - Wikimedia Tool Labs has seen great success with the initial Kubernetes deployment. Old code is being simplified and eliminated, contributing developers don’t have to change the way they write their tools and bots, and those tools and bots run in a more stable fashion than they have in the past. The paid staff and volunteers are able to better keep up with fixing issues. + Wikimedia Tool Labs has seen great success with the initial Kubernetes deployment. Old code is being simplified and eliminated, contributing developers don't have to change the way they write their tools and bots, and those tools and bots run in a more stable fashion than they have in the past. The paid staff and volunteers are able to better keep up with fixing issues.

    - In the future, with a more complete migration to Kubernetes, Wikimedia Tool Labs expects to make it even easier to host and maintain the bots and tools that help run wikis across the world. The tool labs already host approximately 1,300 tools and bots from 800 volunteers, with many more being submitted every day. Twenty percent of the tool labs’ web tools that account for more than 60 percent of web traffic now run on Kubernetes. The tool labs has a 25-node cluster that keeps up with each new Kubernetes release. Many existing web tools are migrating to Kubernetes. + In the future, with a more complete migration to Kubernetes, Wikimedia Tool Labs expects to make it even easier to host and maintain the bots and tools that help run wikis across the world. The tool labs already host approximately 1,300 tools and bots from 800 volunteers, with many more being submitted every day. Twenty percent of the tool labs' web tools that account for more than 60 percent of web traffic now run on Kubernetes. The tool labs has a 25-node cluster that keeps up with each new Kubernetes release. Many existing web tools are migrating to Kubernetes.

    - “Our goal is to make sure that people all over the world can share knowledge as easily as possible. Kubernetes helps with that, by making it easier for wikis everywhere to have the tools they need to thrive,” says Yuvi. + "Our goal is to make sure that people all over the world can share knowledge as easily as possible. Kubernetes helps with that, by making it easier for wikis everywhere to have the tools they need to thrive," says Yuvi.

    diff --git a/community.html b/community.html index 9ef63c1b66..a10a100375 100644 --- a/community.html +++ b/community.html @@ -24,8 +24,8 @@ title: Community

    SIGs

    Have a special interest in how Kubernetes works with another technology? See our ever growing lists of SIGs, - from AWS and Openstack to Big Data and Scalability, there’s a place for you to contribute and instructions - for forming a new SIG if your special interest isn’t covered (yet).

    + from AWS and Openstack to Big Data and Scalability, there's a place for you to contribute and instructions + for forming a new SIG if your special interest isn't covered (yet).

    Events

    diff --git a/docs/admin/admission-controllers.md b/docs/admin/admission-controllers.md index 475f2e4be9..089dce2605 100644 --- a/docs/admin/admission-controllers.md +++ b/docs/admin/admission-controllers.md @@ -126,7 +126,7 @@ For additional HTTP configuration, refer to the [kubeconfig](/docs/user-guide/ku When faced with an admission decision, the API Server POSTs a JSON serialized api.imagepolicy.v1alpha1.ImageReview object describing the action. This object contains fields describing the containers being admitted, as well as any pod annotations that match `*.image-policy.k8s.io/*`. -Note that webhook API objects are subject to the same versioning compatibility rules as other Kubernetes API objects. Implementers should be aware of looser compatibility promises for alpha objects and check the “apiVersion” field of the request to ensure correct deserialization. Additionally, the API Server must enable the imagepolicy.k8s.io/v1alpha1 API extensions group (`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`). +Note that webhook API objects are subject to the same versioning compatibility rules as other Kubernetes API objects. Implementers should be aware of looser compatibility promises for alpha objects and check the "apiVersion" field of the request to ensure correct deserialization. Additionally, the API Server must enable the imagepolicy.k8s.io/v1alpha1 API extensions group (`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`). An example request body: @@ -151,7 +151,7 @@ An example request body: } ``` -The remote service is expected to fill the ImageReviewStatus field of the request and respond to either allow or disallow access. The response body’s “spec” field is ignored and may be omitted. A permissive response would return: +The remote service is expected to fill the ImageReviewStatus field of the request and respond to either allow or disallow access. The response body's "spec" field is ignored and may be omitted. A permissive response would return: ``` { diff --git a/docs/admin/networking.md b/docs/admin/networking.md index 0b73e855bb..565005a991 100644 --- a/docs/admin/networking.md +++ b/docs/admin/networking.md @@ -173,7 +173,7 @@ Lars Kellogg-Stedman. [Nuage](http://www.nuagenetworks.net) provides a highly scalable policy-based Software-Defined Networking (SDN) platform. Nuage uses the open source Open vSwitch for the data plane along with a feature rich SDN Controller built on open standards. -The Nuage platform uses overlays to provide seamless policy-based networking between Kubernetes Pods and non-Kubernetes environments (VMs and bare metal servers). Nuage’s policy abstraction model is designed with applications in mind and makes it easy to declare fine-grained policies for applications.The platform’s real-time analytics engine enables visibility and security monitoring for Kubernetes applications. +The Nuage platform uses overlays to provide seamless policy-based networking between Kubernetes Pods and non-Kubernetes environments (VMs and bare metal servers). Nuage's policy abstraction model is designed with applications in mind and makes it easy to declare fine-grained policies for applications.The platform's real-time analytics engine enables visibility and security monitoring for Kubernetes applications. ### OpenVSwitch diff --git a/docs/admin/rescheduler.md b/docs/admin/rescheduler.md index e1a2cca5de..11d15c10dd 100644 --- a/docs/admin/rescheduler.md +++ b/docs/admin/rescheduler.md @@ -30,7 +30,7 @@ given the pods that are already running in the cluster the rescheduler tries to free up space for the add-on by evicting some pods; then the scheduler will schedule the add-on pod. To avoid situation when another pod is scheduled into the space prepared for the critical add-on, -the chosen node gets a temporary taint “CriticalAddonsOnly” before the eviction(s) +the chosen node gets a temporary taint "CriticalAddonsOnly" before the eviction(s) (see [more details](https://github.com/kubernetes/kubernetes/blob/master/docs/design/taint-toleration-dedicated.md)). Each critical add-on has to tolerate it, the other pods shouldn't tolerate the taint. The tain is removed once the add-on is successfully scheduled. @@ -57,4 +57,3 @@ and have the following annotations specified: * `scheduler.alpha.kubernetes.io/tolerations` set to `[{"key":"CriticalAddonsOnly", "operator":"Exists"}]` The first one marks a pod a critical. The second one is required by Rescheduler algorithm. - diff --git a/docs/getting-started-guides/logging.md b/docs/getting-started-guides/logging.md index ff874e119d..05c41cd3c6 100644 --- a/docs/getting-started-guides/logging.md +++ b/docs/getting-started-guides/logging.md @@ -79,7 +79,7 @@ root 479 0.0 0.0 4348 812 ? S 00:05 0:00 sleep 1 root 480 0.0 0.0 15572 2212 ? R 00:05 0:00 ps aux ``` -What happens if for any reason the image in this pod is killed off and then restarted by Kubernetes? Will we still see the log lines from the previous invocation of the container followed by the log lines for the started container? Or will we lose the log lines from the original container's execution and only see the log lines for the new container? Let’s find out. First let's delete the currently running counter. +What happens if for any reason the image in this pod is killed off and then restarted by Kubernetes? Will we still see the log lines from the previous invocation of the container followed by the log lines for the started container? Or will we lose the log lines from the original container's execution and only see the log lines for the new container? Let's find out. First let's delete the currently running counter. ```shell $ kubectl delete pod counter diff --git a/docs/getting-started-guides/meanstack.md b/docs/getting-started-guides/meanstack.md index 37df0513f7..e1e7bd7696 100644 --- a/docs/getting-started-guides/meanstack.md +++ b/docs/getting-started-guides/meanstack.md @@ -17,12 +17,12 @@ Thankfully, there is a system we can use to manage our containers in a cluster e ## The Basics of Using Kubernetes -Before we jump in and start kube’ing it up, it’s important to understand some of the fundamentals of Kubernetes. +Before we jump in and start kube'ing it up, it's important to understand some of the fundamentals of Kubernetes. * Containers: These are the Docker, rtk, AppC, or whatever Container you are running. You can think of these like subatomic particles; everything is made up of them, but you rarely (if ever) interact with them directly. -* Pods: Pods are the basic component of Kubernetes. They are a group of Containers that are scheduled, live, and die together. Why would you want to have a group of containers instead of just a single container? Let’s say you had a log processor, a web server, and a database. If you couldn't use Pods, you would have to bundle the log processor in the web server and database containers, and each time you updated one you would have to update the other. With Pods, you can just reuse the same log processor for both the web server and database. +* Pods: Pods are the basic component of Kubernetes. They are a group of Containers that are scheduled, live, and die together. Why would you want to have a group of containers instead of just a single container? Let's say you had a log processor, a web server, and a database. If you couldn't use Pods, you would have to bundle the log processor in the web server and database containers, and each time you updated one you would have to update the other. With Pods, you can just reuse the same log processor for both the web server and database. * Deployments: A Deployment provides declarative updates for Pods. You can define Deployments to create new Pods, or replace existing Pods. You only need to describe the desired state in a Deployment object, and the deployment controller will change the actual state to the desired state at a controlled rate for you. You can define Deployments to create new resources, or replace existing ones by new ones. -* Services: A service is the single point of contact for a group of Pods. For example, let’s say you have a Deployment that creates four copies of a web server pod. A Service will split the traffic to each of the four copies. Services are "permanent" while the pods behind them can come and go, so it’s a good idea to use Services. +* Services: A service is the single point of contact for a group of Pods. For example, let's say you have a Deployment that creates four copies of a web server pod. A Service will split the traffic to each of the four copies. Services are "permanent" while the pods behind them can come and go, so it's a good idea to use Services. ## Step 1: Creating the Container @@ -37,7 +37,7 @@ To do this, you need to use more Docker. Make sure you have the latest version i Getting the code: -Before starting, let’s get some code to run. You can follow along on your personal machine or a Linux VM in the cloud. I recommend using Linux or a Linux VM; running Docker on Mac and Windows is outside the scope of this tutorial. +Before starting, let's get some code to run. You can follow along on your personal machine or a Linux VM in the cloud. I recommend using Linux or a Linux VM; running Docker on Mac and Windows is outside the scope of this tutorial. ```shell $ git clone https://github.com/ijason/NodeJS-Sample-App.git app @@ -45,7 +45,7 @@ $ mv app/EmployeeDB/* app/ $ sed -i -- 's/localhost/mongo/g' ./app/app.js ``` -This is the same sample app we ran before. The second line just moves everything from the `EmployeeDB` subfolder up into the app folder so it’s easier to access. The third line, once again, replaces the hardcoded `localhost` with the `mongo` proxy. +This is the same sample app we ran before. The second line just moves everything from the `EmployeeDB` subfolder up into the app folder so it's easier to access. The third line, once again, replaces the hardcoded `localhost` with the `mongo` proxy. Building the Docker image: @@ -83,7 +83,7 @@ $ ls Dockerfile app ``` -Let’s build. +Le's build. ```shell $ docker build -t myapp . @@ -139,7 +139,7 @@ After some time, it will finish. You can check the console to see the container ## **Step 4: Creating the Cluster** -So now you have the custom container, let’s create a cluster to run it. +So now you have the custom container, let's create a cluster to run it. Currently, a cluster can be as small as one machine to as big as 100 machines. You can pick any machine type you want, so you can have a cluster of a single `f1-micro` instance, 100 `n1-standard-32` instances (3,200 cores!), and anything in between. @@ -193,7 +193,7 @@ $ gcloud compute disks create \ Pick the same zone as your cluster and an appropriate disk size for your application. -Now, we need to create a Deployment that will run the database. I’m using a Deployment and not a Pod, because if a standalone Pod dies, it won't restart automatically. +Now, we need to create a Deployment that will run the database. I'm using a Deployment and not a Pod, because if a standalone Pod dies, it won't restart automatically. ### `db-deployment.yml` @@ -231,7 +231,7 @@ We call the deployment `mongo-deployment`, specify one replica, and open the app The `volumes` section creates the volume for Kubernetes to use. There is a Google Container Engine-specific `gcePersistentDisk` section that maps the disk we made into a Kubernetes volume, and we mount the volume into the `/data/db` directory (as described in the MongoDB Docker documentation) -Now we have the Deployment, let’s create the Service: +Now we have the Deployment, let's create the Service: ### `db-service.yml` @@ -267,7 +267,7 @@ db-service.yml ## Step 6: Running the Database -First, let’s "log in" to the cluster +First, let's "log in" to the cluster ```shell $ gcloud container clusters get-credentials mean-cluster @@ -305,14 +305,14 @@ mongo-deployment-xxxx 1/1 Running 0 3m ## Step 7: Creating the Web Server -Now the database is running, let’s start the web server. +Now the database is running, let's start the web server. We need two things: 1. Deployment to spin up and down web server pods 2. Service to expose our website to the interwebs -Let’s look at the Deployment configuration: +Let's look at the Deployment configuration: ### `web-deployment.yml` @@ -371,7 +371,7 @@ At this point, the local directory looks like this ```shell $ ls -Dockerfile +Dockerfile app db-deployment.yml db-service.yml diff --git a/docs/getting-started-guides/windows/index.md b/docs/getting-started-guides/windows/index.md index 511d125dcd..6349bc52ce 100644 --- a/docs/getting-started-guides/windows/index.md +++ b/docs/getting-started-guides/windows/index.md @@ -15,18 +15,18 @@ In Kubernetes version 1.5, Windows Server Containers for Kubernetes is supported 4. Docker Version 1.12.2-cs2-ws-beta or later ## Networking -Network is achieved using L3 routing. Because third-party networking plugins (e.g. flannel, calico, etc) don’t natively work on Windows Server, existing technology that is built into the Windows and Linux operating systems is relied on. In this L3 networking approach, a /16 subnet is chosen for the cluster nodes, and a /24 subnet is assigned to each worker node. All pods on a given worker node will be connected to the /24 subnet. This allows pods on the same node to communicate with each other. In order to enable networking between pods running on different nodes, routing features that are built into Windows Server 2016 and Linux are used. +Network is achieved using L3 routing. Because third-party networking plugins (e.g. flannel, calico, etc) don't natively work on Windows Server, existing technology that is built into the Windows and Linux operating systems is relied on. In this L3 networking approach, a /16 subnet is chosen for the cluster nodes, and a /24 subnet is assigned to each worker node. All pods on a given worker node will be connected to the /24 subnet. This allows pods on the same node to communicate with each other. In order to enable networking between pods running on different nodes, routing features that are built into Windows Server 2016 and Linux are used. ### Linux -The above networking approach is already supported on Linux using a bridge interface, which essentially creates a private network local to the node. Similar to the Windows side, routes to all other pod CIDRs must be created in order to send packets via the “public” NIC. +The above networking approach is already supported on Linux using a bridge interface, which essentially creates a private network local to the node. Similar to the Windows side, routes to all other pod CIDRs must be created in order to send packets via the "public" NIC. ### Windows Each Window Server node should have the following configuration: 1. Two NICs (virtual networking adapters) are required on each Windows Server node - The two Windows container networking modes of interest (transparent and L2 bridge) use an external Hyper-V virtual switch. This means that one of the NICs is entirely allocated to the bridge, creating the need for the second NIC. 2. Transparent container network created - This is a manual configuration step and is shown in **_Route Setup_** section below -3. RRAS (Routing) Windows feature enabled - Allows routing between NICs on the box, and also “captures” packets that have the destination IP of a POD running on the node. To enable, open “Server Manager”. Click on “Roles”, “Add Roles”. Click “Next”. Select “Network Policy and Access Services”. Click on “Routing and Remote Access Service” and the underlying checkboxes -4. Routes defined pointing to the other pod CIDRs via the “public” NIC - These routes are added to the built-in routing table as shown in **_Route Setup_** section below +3. RRAS (Routing) Windows feature enabled - Allows routing between NICs on the box, and also "captures" packets that have the destination IP of a POD running on the node. To enable, open "Server Manager". Click on "Roles", "Add Roles". Click "Next". Select "Network Policy and Access Services". Click on "Routing and Remote Access Service" and the underlying checkboxes +4. Routes defined pointing to the other pod CIDRs via the "public" NIC - These routes are added to the built-in routing table as shown in **_Route Setup_** section below The following diagram illustrates the Windows Server networking setup for Kubernetes Setup ![Windows Setup](windows-setup.png) @@ -38,12 +38,12 @@ To run Windows Server Containers on Kubernetes, you'll need to set up both your 1. Windows Server container host running Windows Server 2016 and Docker v1.12. Follow the setup instructions outlined by this blog post: https://msdn.microsoft.com/en-us/virtualization/windowscontainers/quick_start/quick_start_windows_server 2. DNS support for Windows recently got merged to docker master and is currently not supported in a stable docker release. To use DNS build docker from master or download the binary from [Docker master](https://master.dockerproject.org/) -3. Pull the `apprenda/pause` image from `https://hub.docker.com/r/apprenda/pause` +3. Pull the `apprenda/pause` image from `https://hub.docker.com/r/apprenda/pause` 4. RRAS (Routing) Windows feature enabled **Linux Host Setup** -1. Linux hosts should be setup according to their respective distro documentation and the requirements of the Kubernetes version you will be using. +1. Linux hosts should be setup according to their respective distro documentation and the requirements of the Kubernetes version you will be using. 2. CNI network plugin installed. ### Component Setup @@ -110,7 +110,7 @@ route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 if A Kubernetes cluster can be deployed on either physical or virtual machines. To get started with Kubernetes development, you can use Minikube. Minikube is a lightweight Kubernetes implementation that creates a VM on your local machine and deploys a simple cluster containing only one node. Minikube is available for Linux, Mac OS and Windows systems. The Minikube CLI provides basic bootstrapping operations for working with your cluster, including start, stop, status, and delete. For this bootcamp, however, you'll use a provided online terminal with Minikube pre-installed.

    -

    Now that you know what Kubernetes is, let’s go to the online tutorial and start our first cluster!

    +

    Now that you know what Kubernetes is, let's go to the online tutorial and start our first cluster!

    diff --git a/docs/tutorials/kubernetes-basics/deploy-intro.html b/docs/tutorials/kubernetes-basics/deploy-intro.html index 5352e0ea38..b8ca582f1d 100644 --- a/docs/tutorials/kubernetes-basics/deploy-intro.html +++ b/docs/tutorials/kubernetes-basics/deploy-intro.html @@ -86,9 +86,9 @@ title: Using kubectl to Create a Deployment
    -

    For our first Deployment, we’ll use a Node.js application packaged in a Docker container. The source code and the Dockerfile are available in the GitHub repository for the Kubernetes Bootcamp.

    +

    For our first Deployment, we'll use a Node.js application packaged in a Docker container. The source code and the Dockerfile are available in the GitHub repository for the Kubernetes Bootcamp.

    -

    Now that you know what Deployments are, let’s go to the online tutorial and deploy our first app!

    +

    Now that you know what Deployments are, let's go to the online tutorial and deploy our first app!

    diff --git a/docs/tutorials/kubernetes-basics/explore-intro.html b/docs/tutorials/kubernetes-basics/explore-intro.html index edc813d3d4..e16d2a0755 100644 --- a/docs/tutorials/kubernetes-basics/explore-intro.html +++ b/docs/tutorials/kubernetes-basics/explore-intro.html @@ -34,7 +34,7 @@ title: Viewing Pods and Nodes
  • Networking, as a unique cluster IP address
  • Information about how to run each container, such as the container image version or specific ports to use
    • -

    A Pod models an application-specific “logical host” and can contain different application containers which are relatively tightly coupled. For example, a Pod might include both the container with your Node.js app as well as a different container that feeds the data to be published by the Node.js webserver. The containers in a Pod share an IP Address and port space, are always co-located and co-scheduled, and run in a shared context on the same Node.

    +

    A Pod models an application-specific "logical host" and can contain different application containers which are relatively tightly coupled. For example, a Pod might include both the container with your Node.js app as well as a different container that feeds the data to be published by the Node.js webserver. The containers in a Pod share an IP Address and port space, are always co-located and co-scheduled, and run in a shared context on the same Node.

    Pods are the atomic unit on the Kubernetes platform. When we create a Deployment on Kubernetes, that Deployment creates Pods with containers inside them (as opposed to creating containers directly). Each Pod is tied to the Node where it is scheduled, and remains there until termination (according to restart policy) or deletion. In case of a Node failure, identical Pods are scheduled on other available Nodes in the cluster.

    @@ -117,7 +117,7 @@ title: Viewing Pods and Nodes

    You can use these commands to see when applications were deployed, what their current statuses are, where they are running and what their configurations are.

    -

    Now that we know more about our cluster components and the command line, let’s explore our application.

    +

    Now that we know more about our cluster components and the command line, let's explore our application.

    diff --git a/docs/tutorials/kubernetes-basics/expose-intro.html b/docs/tutorials/kubernetes-basics/expose-intro.html index 2d3c4d7bb4..d914fdf9a2 100644 --- a/docs/tutorials/kubernetes-basics/expose-intro.html +++ b/docs/tutorials/kubernetes-basics/expose-intro.html @@ -28,7 +28,7 @@ title: Using a Service to Expose Your App

    Kubernetes Services

    -

    While Pods do have their own unique IP across the cluster, those IP’s are not exposed outside Kubernetes. Taking into account that over time Pods may be terminated, deleted or replaced by other Pods, we need a way to let other Pods and applications automatically discover each other. Kubernetes addresses this by grouping Pods in Services. A Kubernetes Service is an abstraction layer which defines a logical set of Pods and enables external traffic exposure, load balancing and service discovery for those Pods.

    +

    While Pods do have their own unique IP across the cluster, those IP's are not exposed outside Kubernetes. Taking into account that over time Pods may be terminated, deleted or replaced by other Pods, we need a way to let other Pods and applications automatically discover each other. Kubernetes addresses this by grouping Pods in Services. A Kubernetes Service is an abstraction layer which defines a logical set of Pods and enables external traffic exposure, load balancing and service discovery for those Pods.

    This abstraction will allow us to expose Pods to traffic originating from outside the cluster. Services have their own unique cluster-private IP address and expose a port to receive traffic. If you choose to expose the service outside the cluster, the options are:

      @@ -70,7 +70,7 @@ title: Using a Service to Expose Your App
      -

      A Service provides load balancing of traffic across the contained set of Pods. This is useful when a service is created to group all Pods from a specific Deployment (our application will make use of this in the next module, when we’ll have multiple instances running).

      +

      A Service provides load balancing of traffic across the contained set of Pods. This is useful when a service is created to group all Pods from a specific Deployment (our application will make use of this in the next module, when we'll have multiple instances running).

      Services are also responsible for service-discovery within the cluster (covered in Accessing the Service). This will for example allow a frontend service (like a web server) to receive traffic from a backend service (like a database) without worrying about Pods.

      @@ -120,7 +120,7 @@ title: Using a Service to Expose Your App

      Labels can be attached to objects at the creation time or later and can be modified at any time. The kubectl run command sets some default Labels/Label Selectors on the new Pods/ Deployment. The link between Labels and Label Selectors defines the relationship between the Deployment and the Pods it creates.

      -

      Now let’s expose our application with the help of a Service, and apply some new Labels.

      +

      Now let's expose our application with the help of a Service, and apply some new Labels.


      diff --git a/docs/tutorials/kubernetes-basics/scale-intro.html b/docs/tutorials/kubernetes-basics/scale-intro.html index 49b9e49dec..cf3635eba1 100644 --- a/docs/tutorials/kubernetes-basics/scale-intro.html +++ b/docs/tutorials/kubernetes-basics/scale-intro.html @@ -101,7 +101,7 @@ title: Running Multiple Instances of Your App
      -

      Once you have multiple instances of an Application running, you would be able to do Rolling updates without downtime. We’ll cover that in the next module. Now, let’s go to the online terminal and scale our application.

      +

      Once you have multiple instances of an Application running, you would be able to do Rolling updates without downtime. We'll cover that in the next module. Now, let's go to the online terminal and scale our application.


      diff --git a/docs/tutorials/kubernetes-basics/update-intro.html b/docs/tutorials/kubernetes-basics/update-intro.html index 9ed498ce35..d331e3f58c 100644 --- a/docs/tutorials/kubernetes-basics/update-intro.html +++ b/docs/tutorials/kubernetes-basics/update-intro.html @@ -116,7 +116,7 @@ title: Performing a Rolling Update
      -

      In the following interactive tutorial we’ll update our application to a new version, and also perform a rollback.

      +

      In the following interactive tutorial we'll update our application to a new version, and also perform a rollback.


      diff --git a/docs/tutorials/stateful-application/zookeeper.md b/docs/tutorials/stateful-application/zookeeper.md index 90a78fdc31..b36ed0835b 100644 --- a/docs/tutorials/stateful-application/zookeeper.md +++ b/docs/tutorials/stateful-application/zookeeper.md @@ -11,15 +11,15 @@ title: Running ZooKeeper, A CP Distributed System --- {% capture overview %} -This tutorial demonstrates [Apache Zookeeper](https://zookeeper.apache.org) on -Kubernetes using [StatefulSets](/docs/concepts/abstractions/controllers/statefulsets/), -[PodDisruptionBudgets](/docs/admin/disruptions/#specifying-a-poddisruptionbudget), +This tutorial demonstrates [Apache Zookeeper](https://zookeeper.apache.org) on +Kubernetes using [StatefulSets](/docs/concepts/abstractions/controllers/statefulsets/), +[PodDisruptionBudgets](/docs/admin/disruptions/#specifying-a-poddisruptionbudget), and [PodAntiAffinity](/docs/user-guide/node-selection/). {% endcapture %} {% capture prerequisites %} -Before starting this tutorial, you should be familiar with the following +Before starting this tutorial, you should be familiar with the following Kubernetes concepts. * [Pods](/docs/user-guide/pods/single-container/) @@ -34,16 +34,16 @@ Kubernetes concepts. * [kubectl CLI](/docs/user-guide/kubectl) You will require a cluster with at least four nodes, and each node will require -at least 2 CPUs and 4 GiB of memory. In this tutorial you will cordon and -drain the cluster's nodes. **This means that all Pods on the cluster's nodes -will be terminated and evicted, and the nodes will, temporarily, become -unschedulable.** You should use a dedicated cluster for this tutorial, or you -should ensure that the disruption you cause will not interfere with other +at least 2 CPUs and 4 GiB of memory. In this tutorial you will cordon and +drain the cluster's nodes. **This means that all Pods on the cluster's nodes +will be terminated and evicted, and the nodes will, temporarily, become +unschedulable.** You should use a dedicated cluster for this tutorial, or you +should ensure that the disruption you cause will not interfere with other tenants. -This tutorial assumes that your cluster is configured to dynamically provision +This tutorial assumes that your cluster is configured to dynamically provision PersistentVolumes. If your cluster is not configured to do so, you -will have to manually provision three 20 GiB volumes prior to starting this +will have to manually provision three 20 GiB volumes prior to starting this tutorial. {% endcapture %} @@ -60,51 +60,51 @@ After this tutorial, you will know the following. #### ZooKeeper Basics -[Apache ZooKeeper](https://zookeeper.apache.org/doc/current/) is a +[Apache ZooKeeper](https://zookeeper.apache.org/doc/current/) is a distributed, open-source coordination service for distributed applications. -ZooKeeper allows you to read, write, and observe updates to data. Data are -organized in a file system like hierarchy and replicated to all ZooKeeper -servers in the ensemble (a set of ZooKeeper servers). All operations on data -are atomic and sequentially consistent. ZooKeeper ensures this by using the -[Zab](https://pdfs.semanticscholar.org/b02c/6b00bd5dbdbd951fddb00b906c82fa80f0b3.pdf) +ZooKeeper allows you to read, write, and observe updates to data. Data are +organized in a file system like hierarchy and replicated to all ZooKeeper +servers in the ensemble (a set of ZooKeeper servers). All operations on data +are atomic and sequentially consistent. ZooKeeper ensures this by using the +[Zab](https://pdfs.semanticscholar.org/b02c/6b00bd5dbdbd951fddb00b906c82fa80f0b3.pdf) consensus protocol to replicate a state machine across all servers in the ensemble. The ensemble uses the Zab protocol to elect a leader, and -data can not be written until a leader is elected. Once a leader is -elected, the ensemble uses Zab to ensure that all writes are replicated to a +data can not be written until a leader is elected. Once a leader is +elected, the ensemble uses Zab to ensure that all writes are replicated to a quorum before they are acknowledged and made visible to clients. Without respect -to weighted quorums, a quorum is a majority component of the ensemble containing -the current leader. For instance, if the ensemble has three servers, a component -that contains the leader and one other server constitutes a quorum. If the +to weighted quorums, a quorum is a majority component of the ensemble containing +the current leader. For instance, if the ensemble has three servers, a component +that contains the leader and one other server constitutes a quorum. If the ensemble can not achieve a quorum, data can not be written. -ZooKeeper servers keep their entire state machine in memory, but every mutation -is written to a durable WAL (Write Ahead Log) on storage media. When a server -crashes, it can recover its previous state by replaying the WAL. In order to -prevent the WAL from growing without bound, ZooKeeper servers will periodically -snapshot their in memory state to storage media. These snapshots can be loaded -directly into memory, and all WAL entries that preceded the snapshot may be +ZooKeeper servers keep their entire state machine in memory, but every mutation +is written to a durable WAL (Write Ahead Log) on storage media. When a server +crashes, it can recover its previous state by replaying the WAL. In order to +prevent the WAL from growing without bound, ZooKeeper servers will periodically +snapshot their in memory state to storage media. These snapshots can be loaded +directly into memory, and all WAL entries that preceded the snapshot may be safely discarded. ### Creating a ZooKeeper Ensemble -The manifest below contains a -[Headless Service](/docs/user-guide/services/#headless-services), -a [ConfigMap](/docs/user-guide/configmap/), -a [PodDisruptionBudget](/docs/admin/disruptions/#specifying-a-poddisruptionbudget), -and a [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/). +The manifest below contains a +[Headless Service](/docs/user-guide/services/#headless-services), +a [ConfigMap](/docs/user-guide/configmap/), +a [PodDisruptionBudget](/docs/admin/disruptions/#specifying-a-poddisruptionbudget), +and a [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/). {% include code.html language="yaml" file="zookeeper.yaml" ghlink="/docs/tutorials/stateful-application/zookeeper.yaml" %} -Open a command terminal, and use -[`kubectl create`](/docs/user-guide/kubectl/kubectl_create/) to create the +Open a command terminal, and use +[`kubectl create`](/docs/user-guide/kubectl/kubectl_create/) to create the manifest. ```shell kubectl create -f http://k8s.io/docs/tutorials/stateful-application/zookeeper.yaml ``` -This creates the `zk-headless` Headless Service, the `zk-config` ConfigMap, +This creates the `zk-headless` Headless Service, the `zk-config` ConfigMap, the `zk-budget` PodDisruptionBudget, and the `zk` StatefulSet. ```shell @@ -142,29 +142,29 @@ zk-2 0/1 Running 0 19s zk-2 1/1 Running 0 40s ``` -The StatefulSet controller creates three Pods, and each Pod has a container with +The StatefulSet controller creates three Pods, and each Pod has a container with a [ZooKeeper 3.4.9](http://www-us.apache.org/dist/zookeeper/zookeeper-3.4.9/) server. #### Facilitating Leader Election -As there is no terminating algorithm for electing a leader in an anonymous -network, Zab requires explicit membership configuration in order to perform -leader election. Each server in the ensemble needs to have a unique +As there is no terminating algorithm for electing a leader in an anonymous +network, Zab requires explicit membership configuration in order to perform +leader election. Each server in the ensemble needs to have a unique identifier, all servers need to know the global set of identifiers, and each identifier needs to be associated with a network address. -Use [`kubectl exec`](/docs/user-guide/kubectl/kubectl_exec/) to get the hostnames +Use [`kubectl exec`](/docs/user-guide/kubectl/kubectl_exec/) to get the hostnames of the Pods in the `zk` StatefulSet. ```shell for i in 0 1 2; do kubectl exec zk-$i -- hostname; done ``` -The StatefulSet controller provides each Pod with a unique hostname based on its -ordinal index. The hostnames take the form `-`. -As the `replicas` field of the `zk` StatefulSet is set to `3`, the Set's -controller creates three Pods with their hostnames set to `zk-0`, `zk-1`, and -`zk-2`. +The StatefulSet controller provides each Pod with a unique hostname based on its +ordinal index. The hostnames take the form `-`. +As the `replicas` field of the `zk` StatefulSet is set to `3`, the Set's +controller creates three Pods with their hostnames set to `zk-0`, `zk-1`, and +`zk-2`. ```shell zk-0 @@ -172,9 +172,9 @@ zk-1 zk-2 ``` -The servers in a ZooKeeper ensemble use natural numbers as unique identifiers, and -each server's identifier is stored in a file called `myid` in the server’s -data directory. +The servers in a ZooKeeper ensemble use natural numbers as unique identifiers, and +each server's identifier is stored in a file called `myid` in the server's +data directory. Examine the contents of the `myid` file for each server. @@ -182,7 +182,7 @@ Examine the contents of the `myid` file for each server. for i in 0 1 2; do echo "myid zk-$i";kubectl exec zk-$i -- cat /var/lib/zookeeper/data/myid; done ``` -As the identifiers are natural numbers and the ordinal indices are non-negative +As the identifiers are natural numbers and the ordinal indices are non-negative integers, you can generate an identifier by adding one to the ordinal. ```shell @@ -200,7 +200,7 @@ Get the FQDN (Fully Qualified Domain Name) of each Pod in the `zk` StatefulSet. for i in 0 1 2; do kubectl exec zk-$i -- hostname -f; done ``` -The `zk-headless` Service creates a domain for all of the Pods, +The `zk-headless` Service creates a domain for all of the Pods, `zk-headless.default.svc.cluster.local`. ```shell @@ -209,11 +209,11 @@ zk-1.zk-headless.default.svc.cluster.local zk-2.zk-headless.default.svc.cluster.local ``` -The A records in [Kubernetes DNS](/docs/admin/dns/) resolve the FQDNs to the Pods' IP addresses. -If the Pods are rescheduled, the A records will be updated with the Pods' new IP +The A records in [Kubernetes DNS](/docs/admin/dns/) resolve the FQDNs to the Pods' IP addresses. +If the Pods are rescheduled, the A records will be updated with the Pods' new IP addresses, but the A record's names will not change. -ZooKeeper stores its application configuration in a file named `zoo.cfg`. Use +ZooKeeper stores its application configuration in a file named `zoo.cfg`. Use `kubectl exec` to view the contents of the `zoo.cfg` file in the `zk-0` Pod. ``` @@ -222,8 +222,8 @@ kubectl exec zk-0 -- cat /opt/zookeeper/conf/zoo.cfg For the `server.1`, `server.2`, and `server.3` properties at the bottom of the file, the `1`, `2`, and `3` correspond to the identifiers in the -ZooKeeper servers' `myid` files. They are set to the FQDNs for the Pods in -the `zk` StatefulSet. +ZooKeeper servers' `myid` files. They are set to the FQDNs for the Pods in +the `zk` StatefulSet. ```shell clientPort=2181 @@ -244,16 +244,16 @@ server.3=zk-2.zk-headless.default.svc.cluster.local:2888:3888 #### Achieving Consensus -Consensus protocols require that the identifiers of each participant be -unique. No two participants in the Zab protocol should claim the same unique -identifier. This is necessary to allow the processes in the system to agree on -which processes have committed which data. If two Pods were launched with the +Consensus protocols require that the identifiers of each participant be +unique. No two participants in the Zab protocol should claim the same unique +identifier. This is necessary to allow the processes in the system to agree on +which processes have committed which data. If two Pods were launched with the same ordinal, two ZooKeeper servers would both identify themselves as the same server. -When you created the `zk` StatefulSet, the StatefulSet's controller created -each Pod sequentially, in the order defined by the Pods' ordinal indices, and it -waited for each Pod to be Running and Ready before creating the next Pod. +When you created the `zk` StatefulSet, the StatefulSet's controller created +each Pod sequentially, in the order defined by the Pods' ordinal indices, and it +waited for each Pod to be Running and Ready before creating the next Pod. ```shell kubectl get pods -w -l app=zk @@ -277,7 +277,7 @@ zk-2 1/1 Running 0 40s The A records for each Pod are only entered when the Pod becomes Ready. Therefore, the FQDNs of the ZooKeeper servers will only resolve to a single endpoint, and that -endpoint will be the unique ZooKeeper server claiming the identity configured +endpoint will be the unique ZooKeeper server claiming the identity configured in its `myid` file. ```shell @@ -286,7 +286,7 @@ zk-1.zk-headless.default.svc.cluster.local zk-2.zk-headless.default.svc.cluster.local ``` -This ensures that the `servers` properties in the ZooKeepers' `zoo.cfg` files +This ensures that the `servers` properties in the ZooKeepers' `zoo.cfg` files represents a correctly configured ensemble. ```shell @@ -295,16 +295,16 @@ server.2=zk-1.zk-headless.default.svc.cluster.local:2888:3888 server.3=zk-2.zk-headless.default.svc.cluster.local:2888:3888 ``` -When the servers use the Zab protocol to attempt to commit a value, they will -either achieve consensus and commit the value (if leader election has succeeded -and at least two of the Pods are Running and Ready), or they will fail to do so -(if either of the aforementioned conditions are not met). No state will arise +When the servers use the Zab protocol to attempt to commit a value, they will +either achieve consensus and commit the value (if leader election has succeeded +and at least two of the Pods are Running and Ready), or they will fail to do so +(if either of the aforementioned conditions are not met). No state will arise where one server acknowledges a write on behalf of another. #### Sanity Testing the Ensemble -The most basic sanity test is to write some data to one ZooKeeper server and -to read the data from another. +The most basic sanity test is to write some data to one ZooKeeper server and +to read the data from another. Use the `zkCli.sh` script to write `world` to the path `/hello` on the `zk-0` Pod. @@ -327,7 +327,7 @@ Get the data from the `zk-1` Pod. kubectl exec zk-1 zkCli.sh get /hello ``` -The data that you created on `zk-0` is available on all of the servers in the +The data that you created on `zk-0` is available on all of the servers in the ensemble. ```shell @@ -351,12 +351,12 @@ numChildren = 0 #### Providing Durable Storage As mentioned in the [ZooKeeper Basics](#zookeeper-basics) section, -ZooKeeper commits all entries to a durable WAL, and periodically writes snapshots -in memory state, to storage media. Using WALs to provide durability is a common +ZooKeeper commits all entries to a durable WAL, and periodically writes snapshots +in memory state, to storage media. Using WALs to provide durability is a common technique for applications that use consensus protocols to achieve a replicated state machine and for storage applications in general. -Use [`kubectl delete`](/docs/user-guide/kubectl/kubectl_delete/) to delete the +Use [`kubectl delete`](/docs/user-guide/kubectl/kubectl_delete/) to delete the `zk` StatefulSet. ```shell @@ -392,7 +392,7 @@ Reapply the manifest in `zookeeper.yaml`. kubectl apply -f http://k8s.io/docs/tutorials/stateful-application/zookeeper.yaml ``` -The `zk` StatefulSet will be created, but, as they already exist, the other API +The `zk` StatefulSet will be created, but, as they already exist, the other API Objects in the manifest will not be modified. ```shell @@ -429,14 +429,14 @@ zk-2 0/1 Running 0 19s zk-2 1/1 Running 0 40s ``` -Get the value you entered during the [sanity test](#sanity-testing-the-ensemble), +Get the value you entered during the [sanity test](#sanity-testing-the-ensemble), from the `zk-2` Pod. ```shell kubectl exec zk-2 zkCli.sh get /hello ``` -Even though all of the Pods in the `zk` StatefulSet have been terminated and +Even though all of the Pods in the `zk` StatefulSet have been terminated and recreated, the ensemble still serves the original value. ```shell @@ -457,8 +457,8 @@ dataLength = 5 numChildren = 0 ``` -The `volumeClaimTemplates` field, of the `zk` StatefulSet's `spec`, specifies a -PersistentVolume that will be provisioned for each Pod. +The `volumeClaimTemplates` field, of the `zk` StatefulSet's `spec`, specifies a +PersistentVolume that will be provisioned for each Pod. ```yaml volumeClaimTemplates: @@ -474,8 +474,8 @@ volumeClaimTemplates: ``` -The StatefulSet controller generates a PersistentVolumeClaim for each Pod in -the StatefulSet. +The StatefulSet controller generates a PersistentVolumeClaim for each Pod in +the StatefulSet. Get the StatefulSet's PersistentVolumeClaims. @@ -483,7 +483,7 @@ Get the StatefulSet's PersistentVolumeClaims. kubectl get pvc -l app=zk ``` -When the StatefulSet recreated its Pods, the Pods' PersistentVolumes were +When the StatefulSet recreated its Pods, the Pods' PersistentVolumes were remounted. ```shell @@ -502,19 +502,19 @@ volumeMounts: mountPath: /var/lib/zookeeper ``` -When a Pod in the `zk` StatefulSet is (re)scheduled, it will always have the -same PersistentVolume mounted to the ZooKeeper server's data directory. -Even when the Pods are rescheduled, all of the writes made to the ZooKeeper +When a Pod in the `zk` StatefulSet is (re)scheduled, it will always have the +same PersistentVolume mounted to the ZooKeeper server's data directory. +Even when the Pods are rescheduled, all of the writes made to the ZooKeeper servers' WALs, and all of their snapshots, remain durable. ### Ensuring Consistent Configuration As noted in the [Facilitating Leader Election](#facilitating-leader-election) and -[Achieving Consensus](#achieving-consensus) sections, the servers in a -ZooKeeper ensemble require consistent configuration in order to elect a leader +[Achieving Consensus](#achieving-consensus) sections, the servers in a +ZooKeeper ensemble require consistent configuration in order to elect a leader and form a quorum. They also require consistent configuration of the Zab protocol -in order for the protocol to work correctly over a network. You can use -ConfigMaps to achieve this. +in order for the protocol to work correctly over a network. You can use +ConfigMaps to achieve this. Get the `zk-config` ConfigMap. @@ -532,8 +532,8 @@ data: tick: "2000" ``` -The `env` field of the `zk` StatefulSet's Pod `template` reads the ConfigMap -into environment variables. These variables are injected into the containers +The `env` field of the `zk` StatefulSet's Pod `template` reads the ConfigMap +into environment variables. These variables are injected into the containers environment. ```yaml @@ -581,7 +581,7 @@ env: ``` The entry point of the container invokes a bash script, `zkConfig.sh`, prior to -launching the ZooKeeper server process. This bash script generates the +launching the ZooKeeper server process. This bash script generates the ZooKeeper configuration files from the supplied environment variables. ```yaml @@ -597,8 +597,8 @@ Examine the environment of all of the Pods in the `zk` StatefulSet. for i in 0 1 2; do kubectl exec zk-$i env | grep ZK_*;echo""; done ``` -All of the variables populated from `zk-config` contain identical values. This -allows the `zkGenConfig.sh` script to create consistent configurations for all +All of the variables populated from `zk-config` contain identical values. This +allows the `zkGenConfig.sh` script to create consistent configurations for all of the ZooKeeper servers in the ensemble. ```shell @@ -653,16 +653,16 @@ ZK_LOG_DIR=/var/log/zookeeper #### Configuring Logging -One of the files generated by the `zkConfigGen.sh` script controls ZooKeeper's logging. -ZooKeeper uses [Log4j](http://logging.apache.org/log4j/2.x/), and, by default, -it uses a time and size based rolling file appender for its logging configuration. +One of the files generated by the `zkConfigGen.sh` script controls ZooKeeper's logging. +ZooKeeper uses [Log4j](http://logging.apache.org/log4j/2.x/), and, by default, +it uses a time and size based rolling file appender for its logging configuration. Get the logging configuration from one of Pods in the `zk` StatefulSet. ```shell kubectl exec zk-0 cat /usr/etc/zookeeper/log4j.properties ``` -The logging configuration below will cause the ZooKeeper process to write all +The logging configuration below will cause the ZooKeeper process to write all of its logs to the standard output file stream. ```shell @@ -675,20 +675,20 @@ log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n ``` -This is the simplest possible way to safely log inside the container. As the -application's logs are being written to standard out, Kubernetes will handle -log rotation for you. Kubernetes also implements a sane retention policy that -ensures application logs written to standard out and standard error do not +This is the simplest possible way to safely log inside the container. As the +application's logs are being written to standard out, Kubernetes will handle +log rotation for you. Kubernetes also implements a sane retention policy that +ensures application logs written to standard out and standard error do not exhaust local storage media. -Use [`kubectl logs`](/docs/user-guide/kubectl/kubectl_logs/) to retrieve the last +Use [`kubectl logs`](/docs/user-guide/kubectl/kubectl_logs/) to retrieve the last few log lines from one of the Pods. ```shell kubectl logs zk-0 --tail 20 ``` -Application logs that are written to standard out or standard error are viewable +Application logs that are written to standard out or standard error are viewable using `kubectl logs` and from the Kubernetes Dashboard. ```shell @@ -714,19 +714,19 @@ using `kubectl logs` and from the Kubernetes Dashboard. 2016-12-06 19:34:46,230 [myid:1] - INFO [Thread-1142:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52768 (no session established for client) ``` -Kubernetes also supports more powerful, but more complex, logging integrations -with [Google Cloud Logging](https://github.com/kubernetes/contrib/blob/master/logging/fluentd-sidecar-gcp/README.md) +Kubernetes also supports more powerful, but more complex, logging integrations +with [Google Cloud Logging](https://github.com/kubernetes/contrib/blob/master/logging/fluentd-sidecar-gcp/README.md) and [ELK](https://github.com/kubernetes/contrib/blob/master/logging/fluentd-sidecar-es/README.md). For cluster level log shipping and aggregation, you should consider deploying a -[sidecar](http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html) +[sidecar](http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html) container to rotate and ship your logs. #### Configuring a Non-Privileged User -The best practices with respect to allowing an application to run as a privileged -user inside of a container are a matter of debate. If your organization requires -that applications be run as a non-privileged user you can use a -[SecurityContext](/docs/user-guide/security-context/) to control the user that +The best practices with respect to allowing an application to run as a privileged +user inside of a container are a matter of debate. If your organization requires +that applications be run as a non-privileged user you can use a +[SecurityContext](/docs/user-guide/security-context/) to control the user that the entry point runs as. The `zk` StatefulSet's Pod `template` contains a SecurityContext. @@ -737,7 +737,7 @@ securityContext: fsGroup: 1000 ``` -In the Pods' containers, UID 1000 corresponds to the zookeeper user and GID 1000 +In the Pods' containers, UID 1000 corresponds to the zookeeper user and GID 1000 corresponds to the zookeeper group. Get the ZooKeeper process information from the `zk-0` Pod. @@ -746,7 +746,7 @@ Get the ZooKeeper process information from the `zk-0` Pod. kubectl exec zk-0 -- ps -elf ``` -As the `runAsUser` field of the `securityContext` object is set to 1000, +As the `runAsUser` field of the `securityContext` object is set to 1000, instead of running as root, the ZooKeeper process runs as the zookeeper user. ```shell @@ -755,8 +755,8 @@ F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 0 S zookeep+ 27 1 0 80 0 - 1155556 - 20:46 ? 00:00:19 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,CONSOLE -cp /usr/bin/../build/classes:/usr/bin/../build/lib/*.jar:/usr/bin/../share/zookeeper/zookeeper-3.4.9.jar:/usr/bin/../share/zookeeper/slf4j-log4j12-1.6.1.jar:/usr/bin/../share/zookeeper/slf4j-api-1.6.1.jar:/usr/bin/../share/zookeeper/netty-3.10.5.Final.jar:/usr/bin/../share/zookeeper/log4j-1.2.16.jar:/usr/bin/../share/zookeeper/jline-0.9.94.jar:/usr/bin/../src/java/lib/*.jar:/usr/bin/../etc/zookeeper: -Xmx2G -Xms2G -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /usr/bin/../etc/zookeeper/zoo.cfg ``` -By default, when the Pod's PersistentVolume is mounted to the ZooKeeper server's -data directory, it is only accessible by the root user. This configuration +By default, when the Pod's PersistentVolume is mounted to the ZooKeeper server's +data directory, it is only accessible by the root user. This configuration prevents the ZooKeeper process from writing to its WAL and storing its snapshots. Get the file permissions of the ZooKeeper data directory on the `zk-0` Pod. @@ -765,8 +765,8 @@ Get the file permissions of the ZooKeeper data directory on the `zk-0` Pod. kubectl exec -ti zk-0 -- ls -ld /var/lib/zookeeper/data ``` -As the `fsGroup` field of the `securityContext` object is set to 1000, -the ownership of the Pods' PersistentVolumes is set to the zookeeper group, +As the `fsGroup` field of the `securityContext` object is set to 1000, +the ownership of the Pods' PersistentVolumes is set to the zookeeper group, and the ZooKeeper process is able to successfully read and write its data. ```shell @@ -775,21 +775,21 @@ drwxr-sr-x 3 zookeeper zookeeper 4096 Dec 5 20:45 /var/lib/zookeeper/data ### Managing the ZooKeeper Process -The [ZooKeeper documentation](https://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_supervision) -documentation indicates that "You will want to have a supervisory process that -manages each of your ZooKeeper server processes (JVM)." Utilizing a watchdog -(supervisory process) to restart failed processes in a distributed system is a -common pattern. When deploying an application in Kubernetes, rather than using -an external utility as a supervisory process, you should use Kubernetes as the +The [ZooKeeper documentation](https://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_supervision) +documentation indicates that "You will want to have a supervisory process that +manages each of your ZooKeeper server processes (JVM)." Utilizing a watchdog +(supervisory process) to restart failed processes in a distributed system is a +common pattern. When deploying an application in Kubernetes, rather than using +an external utility as a supervisory process, you should use Kubernetes as the watchdog for your application. -#### Handling Process Failure +#### Handling Process Failure -[Restart Policies](/docs/user-guide/pod-states/#restartpolicy) control how +[Restart Policies](/docs/user-guide/pod-states/#restartpolicy) control how Kubernetes handles process failures for the entry point of the container in a Pod. For Pods in a StatefulSet, the only appropriate RestartPolicy is Always, and this -is the default value. For stateful applications you should **never** override +is the default value. For stateful applications you should **never** override the default policy. @@ -799,7 +799,7 @@ Examine the process tree for the ZooKeeper server running in the `zk-0` Pod. kubectl exec zk-0 -- ps -ef ``` -The command used as the container's entry point has PID 1, and the +The command used as the container's entry point has PID 1, and the the ZooKeeper process, a child of the entry point, has PID 23. @@ -824,8 +824,8 @@ In another terminal, kill the ZooKeeper process in Pod `zk-0`. ``` -The death of the ZooKeeper process caused its parent process to terminate. As -the RestartPolicy of the container is Always, the parent process was relaunched. +The death of the ZooKeeper process caused its parent process to terminate. As +the RestartPolicy of the container is Always, the parent process was relaunched. ```shell @@ -840,19 +840,19 @@ zk-0 1/1 Running 1 29m ``` -If your application uses a script (such as zkServer.sh) to launch the process +If your application uses a script (such as zkServer.sh) to launch the process that implements the application's business logic, the script must terminate with the child process. This ensures that Kubernetes will restart the application's -container when the process implementing the application's business logic fails. +container when the process implementing the application's business logic fails. #### Testing for Liveness -Configuring your application to restart failed processes is not sufficient to -keep a distributed system healthy. There are many scenarios where -a system's processes can be both alive and unresponsive, or otherwise -unhealthy. You should use liveness probes in order to notify Kubernetes +Configuring your application to restart failed processes is not sufficient to +keep a distributed system healthy. There are many scenarios where +a system's processes can be both alive and unresponsive, or otherwise +unhealthy. You should use liveness probes in order to notify Kubernetes that your application's processes are unhealthy and should be restarted. @@ -869,7 +869,7 @@ The Pod `template` for the `zk` StatefulSet specifies a liveness probe. ``` -The probe calls a simple bash script that uses the ZooKeeper `ruok` four letter +The probe calls a simple bash script that uses the ZooKeeper `ruok` four letter word to test the server's health. @@ -900,7 +900,7 @@ kubectl exec zk-0 -- rm /opt/zookeeper/bin/zkOk.sh ``` -When the liveness probe for the ZooKeeper process fails, Kubernetes will +When the liveness probe for the ZooKeeper process fails, Kubernetes will automatically restart the process for you, ensuring that unhealthy processes in the ensemble are restarted. @@ -921,10 +921,10 @@ zk-0 1/1 Running 1 1h #### Testing for Readiness -Readiness is not the same as liveness. If a process is alive, it is scheduled -and healthy. If a process is ready, it is able to process input. Liveness is +Readiness is not the same as liveness. If a process is alive, it is scheduled +and healthy. If a process is ready, it is able to process input. Liveness is a necessary, but not sufficient, condition for readiness. There are many cases, -particularly during initialization and termination, when a process can be +particularly during initialization and termination, when a process can be alive but not ready. @@ -932,8 +932,8 @@ If you specify a readiness probe, Kubernetes will ensure that your application's processes will not receive network traffic until their readiness checks pass. -For a ZooKeeper server, liveness implies readiness. Therefore, the readiness -probe from the `zookeeper.yaml` manifest is identical to the liveness probe. +For a ZooKeeper server, liveness implies readiness. Therefore, the readiness +probe from the `zookeeper.yaml` manifest is identical to the liveness probe. ```yaml @@ -946,28 +946,28 @@ probe from the `zookeeper.yaml` manifest is identical to the liveness probe. ``` -Even though the liveness and readiness probes are identical, it is important -to specify both. This ensures that only healthy servers in the ZooKeeper +Even though the liveness and readiness probes are identical, it is important +to specify both. This ensures that only healthy servers in the ZooKeeper ensemble receive network traffic. ### Tolerating Node Failure -ZooKeeper needs a quorum of servers in order to successfully commit mutations -to data. For a three server ensemble, two servers must be healthy in order for -writes to succeed. In quorum based systems, members are deployed across failure -domains to ensure availability. In order to avoid an outage, due to the loss of an -individual machine, best practices preclude co-locating multiple instances of the +ZooKeeper needs a quorum of servers in order to successfully commit mutations +to data. For a three server ensemble, two servers must be healthy in order for +writes to succeed. In quorum based systems, members are deployed across failure +domains to ensure availability. In order to avoid an outage, due to the loss of an +individual machine, best practices preclude co-locating multiple instances of the application on the same machine. -By default, Kubernetes may co-locate Pods in a StatefulSet on the same node. +By default, Kubernetes may co-locate Pods in a StatefulSet on the same node. For the three server ensemble you created, if two servers reside on the same node, and that node fails, the clients of your ZooKeeper service will experience -an outage until at least one of the Pods can be rescheduled. +an outage until at least one of the Pods can be rescheduled. You should always provision additional capacity to allow the processes of critical -systems to be rescheduled in the event of node failures. If you do so, then the -outage will only last until the Kubernetes scheduler reschedules one of the ZooKeeper +systems to be rescheduled in the event of node failures. If you do so, then the +outage will only last until the Kubernetes scheduler reschedules one of the ZooKeeper servers. However, if you want your service to tolerate node failures with no downtime, you should use a `PodAntiAffinity` annotation. @@ -985,7 +985,7 @@ kubernetes-minion-group-a5aq kubernetes-minion-group-2g2d ``` -This is because the Pods in the `zk` StatefulSet contain a +This is because the Pods in the `zk` StatefulSet contain a [PodAntiAffinity](/docs/user-guide/node-selection/) annotation. ```yaml @@ -1006,11 +1006,11 @@ scheduler.alpha.kubernetes.io/affinity: > } ``` -The `requiredDuringSchedulingRequiredDuringExecution` field tells the +The `requiredDuringSchedulingRequiredDuringExecution` field tells the Kubernetes Scheduler that it should never co-locate two Pods from the `zk-headless` Service in the domain defined by the `topologyKey`. The `topologyKey` -`kubernetes.io/hostname` indicates that the domain is an individual node. Using -different rules, labels, and selectors, you can extend this technique to spread +`kubernetes.io/hostname` indicates that the domain is an individual node. Using +different rules, labels, and selectors, you can extend this technique to spread your ensemble across physical, network, and power failure domains. ### Surviving Maintenance @@ -1018,8 +1018,8 @@ your ensemble across physical, network, and power failure domains. **In this section you will cordon and drain nodes. If you are using this tutorial on a shared cluster, be sure that this will not adversely affect other tenants.** -The previous section showed you how to spread your Pods across nodes to survive -unplanned node failures, but you also need to plan for temporary node failures +The previous section showed you how to spread your Pods across nodes to survive +unplanned node failures, but you also need to plan for temporary node failures that occur due to planned maintenance. Get the nodes in your cluster. @@ -1028,7 +1028,7 @@ Get the nodes in your cluster. kubectl get nodes ``` -Use [`kubectl cordon`](/docs/user-guide/kubectl/kubectl_cordon/) to +Use [`kubectl cordon`](/docs/user-guide/kubectl/kubectl_cordon/) to cordon all but four of the nodes in your cluster. ```shell{% raw %} @@ -1041,8 +1041,8 @@ Get the `zk-budget` PodDisruptionBudget. kubectl get poddisruptionbudget zk-budget ``` -The `min-available` field indicates to Kubernetes that at least two Pods from -`zk` StatefulSet must be available at any time. +The `min-available` field indicates to Kubernetes that at least two Pods from +`zk` StatefulSet must be available at any time. ```yaml NAME MIN-AVAILABLE ALLOWED-DISRUPTIONS AGE @@ -1065,7 +1065,7 @@ kubernetes-minion-group-ixsl kubernetes-minion-group-i4c4 {% endraw %}``` -Use [`kubectl drain`](/docs/user-guide/kubectl/kubectl_drain/) to cordon and +Use [`kubectl drain`](/docs/user-guide/kubectl/kubectl_drain/) to cordon and drain the node on which the `zk-0` Pod is scheduled. ```shell {% raw %} @@ -1075,7 +1075,7 @@ pod "zk-0" deleted node "kubernetes-minion-group-pb41" drained {% endraw %}``` -As there are four nodes in your cluster, `kubectl drain`, succeeds and the +As there are four nodes in your cluster, `kubectl drain`, succeeds and the `zk-0` is rescheduled to another node. ``` @@ -1095,7 +1095,7 @@ zk-0 0/1 Running 0 51s zk-0 1/1 Running 0 1m ``` -Keep watching the StatefulSet's Pods in the first terminal and drain the node on which +Keep watching the StatefulSet's Pods in the first terminal and drain the node on which `zk-1` is scheduled. ```shell{% raw %} @@ -1105,8 +1105,8 @@ pod "zk-1" deleted node "kubernetes-minion-group-ixsl" drained {% endraw %}``` -The `zk-1` Pod can not be scheduled. As the `zk` StatefulSet contains a -`PodAntiAffinity` annotation preventing co-location of the Pods, and as only +The `zk-1` Pod can not be scheduled. As the `zk` StatefulSet contains a +`PodAntiAffinity` annotation preventing co-location of the Pods, and as only two nodes are schedulable, the Pod will remain in a Pending state. ```shell @@ -1133,7 +1133,7 @@ zk-1 0/1 Pending 0 0s zk-1 0/1 Pending 0 0s ``` -Continue to watch the Pods of the stateful set, and drain the node on which +Continue to watch the Pods of the stateful set, and drain the node on which `zk-2` is scheduled. ```shell{% raw %} @@ -1145,9 +1145,9 @@ There are pending pods when an error occurred: Cannot evict pod as it would viol pod/zk-2 {% endraw %}``` -Use `CRTL-C` to terminate to kubectl. +Use `CRTL-C` to terminate to kubectl. -You can not drain the third node because evicting `zk-2` would violate `zk-budget`. However, +You can not drain the third node because evicting `zk-2` would violate `zk-budget`. However, the node will remain cordoned. Use `zkCli.sh` to retrieve the value you entered during the sanity test from `zk-0`. @@ -1232,9 +1232,9 @@ node "kubernetes-minion-group-ixsl" uncordoned ``` You can use `kubectl drain` in conjunction with PodDisruptionBudgets to ensure that your service -remains available during maintenance. If drain is used to cordon nodes and evict pods prior to -taking the node offline for maintenance, services that express a disruption budget will have that -budget respected. You should always allocate additional capacity for critical services so that +remains available during maintenance. If drain is used to cordon nodes and evict pods prior to +taking the node offline for maintenance, services that express a disruption budget will have that +budget respected. You should always allocate additional capacity for critical services so that their Pods can be immediately rescheduled. {% endcapture %} @@ -1242,8 +1242,8 @@ their Pods can be immediately rescheduled. {% capture cleanup %} * Use `kubectl uncordon` to uncordon all the nodes in your cluster. * You will need to delete the persistent storage media for the PersistentVolumes -used in this tutorial. Follow the necessary steps, based on your environment, -storage configuration, and provisioning method, to ensure that all storage is +used in this tutorial. Follow the necessary steps, based on your environment, +storage configuration, and provisioning method, to ensure that all storage is reclaimed. {% endcapture %} {% include templates/tutorial.md %} diff --git a/docs/user-guide/configuring-containers.md b/docs/user-guide/configuring-containers.md index 1fa82f52e9..51ac150f07 100644 --- a/docs/user-guide/configuring-containers.md +++ b/docs/user-guide/configuring-containers.md @@ -75,7 +75,7 @@ apiVersion: v1 kind: Pod metadata: name: hello-world -spec: # specification of the pod’s contents +spec: # specification of the pod's contents restartPolicy: Never containers: - name: hello diff --git a/docs/user-guide/managing-deployments.md b/docs/user-guide/managing-deployments.md index 2555e5601c..43e283b4a8 100644 --- a/docs/user-guide/managing-deployments.md +++ b/docs/user-guide/managing-deployments.md @@ -85,8 +85,8 @@ NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-nginx-svc 10.0.0.208 80/TCP 0s ``` -With the above commands, we first create resources under docs/user-guide/nginx/ and print the resources created with `-o name` output format -(print each resource as resource/name). Then we `grep` only the "service", and then print it with `kubectl get`. +With the above commands, we first create resources under docs/user-guide/nginx/ and print the resources created with `-o name` output format +(print each resource as resource/name). Then we `grep` only the "service", and then print it with `kubectl get`. If you happen to organize your resources across several subdirectories within a particular directory, you can recursively perform the operations on the subdirectories also, by specifying `--recursive` or `-R` alongside the `--filename,-f` flag. @@ -102,7 +102,7 @@ project/k8s/development └── my-pvc.yaml ``` -By default, performing a bulk operation on `project/k8s/development` will stop at the first level of the directory, not processing any subdirectories. If we tried to create the resources in this directory using the following command, we'd encounter an error: +By default, performing a bulk operation on `project/k8s/development` will stop at the first level of the directory, not processing any subdirectories. If we tried to create the resources in this directory using the following command, we'd encounter an error: ```shell $ kubectl create -f project/k8s/development @@ -131,7 +131,7 @@ deployment "my-deployment" created persistentvolumeclaim "my-pvc" created ``` -If you're interested in learning more about `kubectl`, go ahead and read [kubectl Overview](/docs/user-guide/kubectl-overview). +If you're interested in learning more about `kubectl`, go ahead and read [kubectl Overview](/docs/user-guide/kubectl-overview). ## Using labels effectively @@ -185,9 +185,9 @@ guestbook-redis-slave-qgazl 1/1 Running 0 3m ## Canary deployments -Another scenario where multiple labels are needed is to distinguish deployments of different releases or configurations of the same component. It is common practice to deploy a *canary* of a new application release (specified via image tag in the pod template) side by side with the previous release so that the new release can receive live production traffic before fully rolling it out. +Another scenario where multiple labels are needed is to distinguish deployments of different releases or configurations of the same component. It is common practice to deploy a *canary* of a new application release (specified via image tag in the pod template) side by side with the previous release so that the new release can receive live production traffic before fully rolling it out. -For instance, you can use a `track` label to differentiate different releases. +For instance, you can use a `track` label to differentiate different releases. The primary, stable release would have a `track` label with value as `stable`: @@ -227,13 +227,13 @@ The frontend service would span both sets of replicas by selecting the common su ``` You can tweak the number of replicas of the stable and canary releases to determine the ratio of each release that will receive live production traffic (in this case, 3:1). -Once you're confident, you can update the stable track to the new application release and remove the canary one. +Once you're confident, you can update the stable track to the new application release and remove the canary one. For a more concrete example, check the [tutorial of deploying Ghost](https://github.com/kelseyhightower/talks/tree/master/kubecon-eu-2016/demo#deploy-a-canary). ## Updating labels -Sometimes existing pods and other resources need to be relabeled before creating new resources. This can be done with `kubectl label`. +Sometimes existing pods and other resources need to be relabeled before creating new resources. This can be done with `kubectl label`. For example, if you want to label all your nginx pods as frontend tier, simply run: ```shell @@ -243,8 +243,8 @@ 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". -To see the pods you just labeled, run: +This first filters all pods with the label "app=nginx", and then labels them with the "tier=fe". +To see the pods you just labeled, run: ```shell $ kubectl get pods -l app=nginx -L tier @@ -284,7 +284,7 @@ $ kubectl scale deployment/my-nginx --replicas=1 deployment "my-nginx" scaled ``` -Now you only have one pod managed by the deployment. +Now you only have one pod managed by the deployment. ```shell $ kubectl get pods -l app=nginx @@ -294,25 +294,25 @@ my-nginx-2035384211-j5fhi 1/1 Running 0 30m To have the system automatically choose the number of nginx replicas as needed, ranging from 1 to 3, do: -```shell +```shell $ kubectl autoscale deployment/my-nginx --min=1 --max=3 deployment "my-nginx" autoscaled ``` -Now your nginx replicas will be scaled up and down as needed, automatically. +Now your nginx replicas will be scaled up and down as needed, automatically. For more information, please see [kubectl scale](/docs/user-guide/kubectl/kubectl_scale/), [kubectl autoscale](/docs/user-guide/kubectl/kubectl_autoscale/) and [horizontal pod autoscaler](/docs/user-guide/horizontal-pod-autoscaler/) document. ## In-place updates of resources -Sometimes it's necessary to make narrow, non-disruptive updates to resources you've created. +Sometimes it's necessary to make narrow, non-disruptive updates to resources you've created. ### kubectl apply It is suggested to maintain a set of configuration files in source control (see [configuration as code](http://martinfowler.com/bliki/InfrastructureAsCode.html)), so that they can be maintained and versioned along with the code for the resources they configure. -Then, you can use [`kubectl apply`](/docs/user-guide/kubectl/kubectl_apply/) to push your configuration changes to the cluster. +Then, you can use [`kubectl apply`](/docs/user-guide/kubectl/kubectl_apply/) to push your configuration changes to the cluster. This command will compare the version of the configuration that you're pushing with the previous version and apply the changes you've made, without overwriting any automated changes to properties you haven't specified. @@ -357,7 +357,7 @@ For more information, please see [kubectl edit](/docs/user-guide/kubectl/kubectl Suppose you want to fix a typo of the container's image of a Deployment. One way to do that is with `kubectl patch`: ```shell -# Suppose you have a Deployment with a container named "nginx" and its image "nignx" (typo), +# Suppose you have a Deployment with a container named "nginx" and its image "nignx" (typo), # use container name "nginx" as a key to update the image from "nignx" (typo) to "nginx" $ kubectl get deployment my-nginx -o yaml ``` @@ -396,7 +396,7 @@ spec: The patch is specified using json. -The system ensures that you don’t clobber changes made by other users or components by confirming that the `resourceVersion` doesn’t differ from the version you edited. If you want to update regardless of other changes, remove the `resourceVersion` field when you edit the resource. However, if you do this, don’t use your original configuration file as the source since additional fields most likely were set in the live state. +The system ensures that you don't clobber changes made by other users or components by confirming that the `resourceVersion` doesn't differ from the version you edited. If you want to update regardless of other changes, remove the `resourceVersion` field when you edit the resource. However, if you do this, don't use your original configuration file as the source since additional fields most likely were set in the live state. For more information, please see [kubectl patch](/docs/user-guide/kubectl/kubectl_patch/) document. @@ -414,8 +414,8 @@ deployment "my-nginx" replaced At some point, you'll eventually need to update your deployed application, typically by specifying a new image or image tag, as in the canary deployment scenario above. `kubectl` supports several update operations, each of which is applicable to different scenarios. -We'll guide you through how to create and update applications with Deployments. If your deployed application is managed by Replication Controllers, -you should read [how to use `kubectl rolling-update`](/docs/user-guide/rolling-updates/) instead. +We'll guide you through how to create and update applications with Deployments. If your deployed application is managed by Replication Controllers, +you should read [how to use `kubectl rolling-update`](/docs/user-guide/rolling-updates/) instead. Let's say you were running version 1.7.9 of nginx: @@ -424,7 +424,7 @@ $ kubectl run my-nginx --image=nginx:1.7.9 --replicas=3 deployment "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. +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. ```shell $ kubectl edit deployment/my-nginx diff --git a/docs/user-guide/pod-security-policy/index.md b/docs/user-guide/pod-security-policy/index.md index c2de42162c..c7c58b8ec6 100644 --- a/docs/user-guide/pod-security-policy/index.md +++ b/docs/user-guide/pod-security-policy/index.md @@ -4,8 +4,8 @@ assignees: title: Pod Security Policies --- -Objects of type `podsecuritypolicy` govern the ability -to make requests on a pod that affect the `SecurityContext` that will be +Objects of type `podsecuritypolicy` govern the ability +to make requests on a pod that affect the `SecurityContext` that will be applied to a pod and container. See [PodSecurityPolicy proposal](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/proposals/security-context-constraints.md) for more information. @@ -15,10 +15,10 @@ See [PodSecurityPolicy proposal](https://github.com/kubernetes/kubernetes/blob/{ ## What is a Pod Security Policy? -A _Pod Security Policy_ is a cluster-level resource that controls the +A _Pod Security Policy_ is a cluster-level resource that controls the actions that a pod can perform and what it has the ability to access. The -`PodSecurityPolicy` objects define a set of conditions that a pod must -run with in order to be accepted into the system. They allow an +`PodSecurityPolicy` objects define a set of conditions that a pod must +run with in order to be accepted into the system. They allow an administrator to control the following: 1. Running of privileged containers. @@ -26,21 +26,21 @@ administrator to control the following: 1. The SELinux context of the container. 1. The user ID. 1. The use of host namespaces and networking. -1. Allocating an FSGroup that owns the pod’s volumes +1. Allocating an FSGroup that owns the pod's volumes 1. Configuring allowable supplemental groups 1. Requiring the use of a read only root file system 1. Controlling the usage of volume types -_Pod Security Policies_ are comprised of settings and strategies that -control the security features a pod has access to. These settings fall +_Pod Security Policies_ are comprised of settings and strategies that +control the security features a pod has access to. These settings fall into three categories: -- *Controlled by a boolean*: Fields of this type default to the most -restrictive value. -- *Controlled by an allowable set*: Fields of this type are checked +- *Controlled by a boolean*: Fields of this type default to the most +restrictive value. +- *Controlled by an allowable set*: Fields of this type are checked against the set to ensure their value is allowed. - *Controlled by a strategy*: Items that have a strategy to generate a value provide -a mechanism to generate the value and a mechanism to ensure that a +a mechanism to generate the value and a mechanism to ensure that a specified value falls into the set of allowable values. @@ -65,22 +65,22 @@ specified. ### SupplementalGroups -- *MustRunAs* - Requires at least one range to be specified. Uses the +- *MustRunAs* - Requires at least one range to be specified. Uses the minimum value of the first range as the default. Validates against all ranges. - *RunAsAny* - No default provided. Allows any `*supplementalGroups*` to be specified. ### FSGroup -- *MustRunAs* - Requires at least one range to be specified. Uses the -minimum value of the first range as the default. Validates against the +- *MustRunAs* - Requires at least one range to be specified. Uses the +minimum value of the first range as the default. Validates against the first ID in the first range. - *RunAsAny* - No default provided. Allows any `*fsGroup*` ID to be specified. ### Controlling Volumes -The usage of specific volume types can be controlled by setting the -volumes field of the PSP. The allowable values of this field correspond +The usage of specific volume types can be controlled by setting the +volumes field of the PSP. The allowable values of this field correspond to the volume sources that are defined when creating a volume: 1. azureFile @@ -104,7 +104,7 @@ to the volume sources that are defined when creating a volume: 1. configMap 1. \* (allow all volumes) -The recommended minimum set of allowed volumes for new PSPs are +The recommended minimum set of allowed volumes for new PSPs are configMap, downwardAPI, emptyDir, persistentVolumeClaim, and secret. ## Admission @@ -150,7 +150,7 @@ podsecuritypolicy "permissive" deleted ## Enabling Pod Security Policies -In order to use Pod Security Policies in your cluster you must ensure the +In order to use Pod Security Policies in your cluster you must ensure the following 1. You have enabled the api type `extensions/v1beta1/podsecuritypolicy` diff --git a/docs/user-guide/prereqs.md b/docs/user-guide/prereqs.md index 4be0d6a188..3b9688f1b8 100644 --- a/docs/user-guide/prereqs.md +++ b/docs/user-guide/prereqs.md @@ -5,7 +5,7 @@ assignees: title: Installing and Setting up kubectl --- -To deploy and manage applications on Kubernetes, you’ll use the Kubernetes command-line tool, [kubectl](/docs/user-guide/kubectl/). It lets you inspect your cluster resources, create, delete, and update components, and much more. You will use it to look at your new cluster and bring up example apps. +To deploy and manage applications on Kubernetes, you'll use the Kubernetes command-line tool, [kubectl](/docs/user-guide/kubectl/). It lets you inspect your cluster resources, create, delete, and update components, and much more. You will use it to look at your new cluster and bring up example apps. ## Install kubectl Binary Via curl diff --git a/docs/user-guide/replicasets.md b/docs/user-guide/replicasets.md index f0aa08bf04..86e60cffda 100644 --- a/docs/user-guide/replicasets.md +++ b/docs/user-guide/replicasets.md @@ -35,7 +35,7 @@ their Replica Sets. ## When to use a Replica Set? -A Replica Set ensures that a specified number of pod “replicas” are running at any given +A Replica Set ensures that a specified number of pod "replicas" are running at any given time. However, a Deployment is a higher-level concept that manages Replica Sets and provides declarative updates to pods along with a lot of other useful features. Therefore, we recommend using Deployments instead of directly using Replica Sets, unless diff --git a/docs/user-guide/replication-controller/index.md b/docs/user-guide/replication-controller/index.md index e69c55231b..95917b8f10 100644 --- a/docs/user-guide/replication-controller/index.md +++ b/docs/user-guide/replication-controller/index.md @@ -194,7 +194,7 @@ Ideally, the rolling update controller would take application readiness into acc The two replication controllers would need to create pods with at least one differentiating label, such as the image tag of the primary container of the pod, since it is typically image updates that motivate rolling updates. Rolling update is implemented in the client tool -[`kubectl rolling-update`](/docs/user-guide/kubectl/kubectl_rolling-update). Visit [`kubectl rolling-update` tutorial](/docs/user-guide/rolling-updates/) for more concrete examples. +[`kubectl rolling-update`](/docs/user-guide/kubectl/kubectl_rolling-update). Visit [`kubectl rolling-update` tutorial](/docs/user-guide/rolling-updates/) for more concrete examples. ### Multiple release tracks @@ -233,13 +233,13 @@ object](/docs/api-reference/v1/definitions/#_v1_replicationcontroller). ### ReplicaSet [`ReplicaSet`](/docs/user-guide/replicasets/) is the next-generation Replication Controller that supports the new [set-based label selector](/docs/user-guide/labels/#set-based-requirement). -It’s mainly used by [`Deployment`](/docs/user-guide/deployments/) as a mechanism to orchestrate pod creation, deletion and updates. -Note that we recommend using Deployments instead of directly using Replica Sets, unless you require custom update orchestration or don’t require updates at all. +It's mainly used by [`Deployment`](/docs/user-guide/deployments/) as a mechanism to orchestrate pod creation, deletion and updates. +Note that we recommend using Deployments instead of directly using Replica Sets, unless you require custom update orchestration or don't require updates at all. ### Deployment (Recommended) [`Deployment`](/docs/user-guide/deployments/) is a higher-level API object that updates its underlying Replica Sets and their Pods -in a similar fashion as `kubectl rolling-update`. Deployments are recommended if you want this rolling update functionality, +in a similar fashion as `kubectl rolling-update`. Deployments are recommended if you want this rolling update functionality, because unlike `kubectl rolling-update`, they are declarative, server-side, and have additional features. ### Bare Pods diff --git a/docs/user-guide/security-context.md b/docs/user-guide/security-context.md index 3d216447ca..52fe9f97eb 100644 --- a/docs/user-guide/security-context.md +++ b/docs/user-guide/security-context.md @@ -11,7 +11,7 @@ A security context defines the operating system security settings (uid, gid, cap There are two levels of security context: pod level security context, and container level security context. ## Pod Level Security Context -Setting security context at the pod applies those settings to all containers in the pod +Setting security context at the pod applies those settings to all containers in the pod ```yaml apiVersion: v1 @@ -20,7 +20,7 @@ metadata: name: hello-world spec: containers: - # specification of the pod’s containers + # specification of the pod's containers # ... securityContext: fsGroup: 1234 @@ -82,7 +82,6 @@ spec: ``` Please refer to the -[API documentation](/docs/api-reference/v1/definitions/#_v1_securitycontext) +[API documentation](/docs/api-reference/v1/definitions/#_v1_securitycontext) for a detailed listing and description of all the fields available within the container security context. - diff --git a/index.html b/index.html index 728100db84..78b964ce39 100644 --- a/index.html +++ b/index.html @@ -80,7 +80,7 @@

      Self-healing

      Restarts containers that fail, replaces and reschedules containers when nodes die, kills containers - that don’t respond to your user-defined health check, and doesn’t advertise them to clients until they are ready to serve.

      + that don't respond to your user-defined health check, and doesn't advertise them to clients until they are ready to serve.

    @@ -100,7 +100,7 @@

    Automated rollouts and rollbacks

    Kubernetes progressively rolls out changes to your application or its configuration, while monitoring - application health to ensure it doesn’t kill all your instances at the same time. If something goes + application health to ensure it doesn't kill all your instances at the same time. If something goes wrong, Kubernetes will rollback the change for you. Take advantage of a growing ecosystem of deployment solutions.

    @@ -131,7 +131,7 @@

    Case Studies

    -

    Using Kubernetes to reinvent the world’s largest educational company

    +

    Using Kubernetes to reinvent the world's largest educational company

    Read more
    @@ -139,11 +139,11 @@ Read more
    -

    Inside eBay’s shift to Kubernetes and containers atop OpenStack

    +

    Inside eBay's shift to Kubernetes and containers atop OpenStack

    Read more
    -

    Migrating from a homegrown ‘cluster’ to Kubernetes

    +

    Migrating from a homegrown 'cluster' to Kubernetes

    Watch the video
    @@ -154,7 +154,7 @@ - + @@ -162,11 +162,11 @@ - + - + From efdc69bdad55d57eadf76c70bc70933f1a1eae01 Mon Sep 17 00:00:00 2001 From: Ritesh Shukla Date: Wed, 21 Dec 2016 23:31:56 -0800 Subject: [PATCH 13/68] Deprecate kube-up Add information for kubernetes-anywhere --- docs/getting-started-guides/vsphere.md | 112 +++++++++++++++++++++---- 1 file changed, 94 insertions(+), 18 deletions(-) diff --git a/docs/getting-started-guides/vsphere.md b/docs/getting-started-guides/vsphere.md index f605fe6dc2..343b74dfe3 100644 --- a/docs/getting-started-guides/vsphere.md +++ b/docs/getting-started-guides/vsphere.md @@ -5,19 +5,95 @@ assignees: title: VMware vSphere --- -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). +This page covers how to get started with deploying Kubernetes on vSphere and details for how to configure the vSphere Cloud Provider. * TOC {:toc} -### Prerequisites +### Getting started with vSphere -1. You need administrator credentials to an ESXi machine or vCenter instance with write mode api access enabled (not available on the free ESXi license). -2. You must have Go (see [here](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/development.md#go-versions) for supported versions) installed: [www.golang.org](http://www.golang.org). -3. You must have your `GOPATH` set up and include `$GOPATH/bin` in your `PATH`. +Kubernetes comes with a cloud provider for vSphere. A quick and easy way to try out the cloud provider is to deploy Kubernetes using [Kubernetes-Anywhere](https://github.com/kubernetes/kubernetes-anywhere). + +This page also describes how to configure and get started with the cloud provider if deploying using custom install scripts. + +### Deploy Kubernetes on vSphere + +To start using Kubernetes on top of vSphere and use the vSphere Cloud Provider use Kubernetes-Anywhere. Kubernetes-Anywhere will deploy and configure a cluster from scratch. + +Detailed steps can be found at the [getting started with Kubernetes-Anywhere on vSphere page](https://github.com/kubernetes/kubernetes-anywhere/blob/master/phase1/vsphere/README.md) + +### vSphere Cloud Provider + +vSphere Cloud Provider allows using vSphere managed storage within Kubernetes. It supports: + +1. Volumes +2. Persistent Volumes +3. Storage Classes and provisioning of volumes. + +Documentation for how to use vSphere managed storage can be found in the +[persistent volumes user +guide](http://kubernetes.io/docs/user-guide/persistent-volumes/#vsphere) and the +[volumes user +guide](http://kubernetes.io/docs/user-guide/volumes/#vspherevolume) + +Examples can be found +[here](https://github.com/kubernetes/kubernetes/tree/master/examples/volumes/vsphere) + +#### Configuring vSphere Cloud Provider + +If a Kubernetes cluster has not been deployed using Kubernetes-Anywhere, follow the instructions below to use the vSphere Cloud Provider. These steps are not needed when using Kubernetes-Anywhere, they will be done as part of the deployment. + +* Enable UUID for a VM + +This can be done via [govc tool](https://github.com/vmware/govmomi/tree/master/govc) + +``` +export GOVC_URL= +export GOVC_USERNAME= +export GOVC_PASSWORD= +export GOVC_INSECURE=1 +govc vm.change -e="disk.enableUUID=1" -vm= +``` + +* Provide the cloud config file to each instance of kubelet, apiserver and controller manager via ```--cloud-config=``` flag. Cloud config [template can be found at Kubernetes-Anywhere] (https://github.com/kubernetes/kubernetes-anywhere/blob/master/phase1/vsphere/vsphere.conf) + +Sample Config: +``` +[Global] + user = + password = + server = + port = + insecure-flag = + datacenter = + datastore = + working-dir = +[Disk] + scsicontrollertype = pvscsi +``` + +* Set the cloud provider via ```--cloud-provider=vsphere``` flag for each instance of kubelet, apiserver and controller manager. + + +#### Known issues + +* [Volumes are not removed from a VM configuration if the VM is down](https://github.com/kubernetes/kubernetes/issues/33061). The workaround is to manually remove the disk from VM settings before powering it up. +* [FS groups are not supported in 1.4.7](https://github.com/kubernetes/kubernetes/issues/34039) + +### Kube-up (Deprecated) + +Kube-up.sh is no longer supported and is deprecated. The steps for kube-up are included but going forward [kube-anywhere](https://github.com/kubernetes/kubernetes-anywhere) is preferred. + +The recommended version for kube-up is [v1.4.7](https://github.com/kubernetes/kubernetes/releases/tag/v1.4.7) + +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). + +#### Prerequisites + +* You need administrator credentials to an ESXi machine or vCenter instance with write mode api access enabled (not available on the free ESXi license). +* You must have Go (see [here](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/development.md#go-versions) for supported versions) installed: [www.golang.org](http://www.golang.org). +* You must have your `GOPATH` set up and include `$GOPATH/bin` in your `PATH`. ```shell export GOPATH=$HOME/src/go @@ -25,7 +101,7 @@ mkdir -p $GOPATH export PATH=$PATH:$GOPATH/bin ``` -4. Install the govc tool to interact with ESXi/vCenter. Head to [govc Releases](https://github.com/vmware/govmomi/releases) to download the latest. +* Install the govc tool to interact with ESXi/vCenter. Head to [govc Releases](https://github.com/vmware/govmomi/releases) to download the latest. ```shell # Sample commands for v0.8.0 for 64 bit Linux. @@ -35,9 +111,9 @@ chmod +x govc_linux_amd64 mv govc_linux_amd64 /usr/local/bin/govc ``` -5. Get or build a [binary release](/docs/getting-started-guides/binary_release) +* Get or build a [binary release](/docs/getting-started-guides/binary_release) -### Setup +#### Setup Download a prebuilt Debian 8.2 VMDK that we'll use as a base image: @@ -91,8 +167,8 @@ Verify that the VMDK was correctly uploaded and expanded to ~3GiB: govc datastore.ls ./kube/ ``` -If you need to debug any part of the deployment, the guest login for -the image that you imported is `kube:kube`. It is normally specified +If you need to debug any part of the deployment, the guest login for +the image that you imported is `kube:kube`. It is normally specified in the GOVC_GUEST_LOGIN parameter above. Also take a look at the file `cluster/vsphere/config-default.sh` and @@ -100,19 +176,19 @@ make any needed changes. You can configure the number of nodes as well as the IP subnets you have made available to Kubernetes, pods, and services. -### Starting a cluster +#### Starting a cluster Now, let's continue with deploying Kubernetes. This process takes about ~20-30 minutes depending on your network. -#### From extracted binary release +##### From extracted binary release ```shell cd kubernetes KUBERNETES_PROVIDER=vsphere cluster/kube-up.sh ``` -#### Build from source +##### Build from source ```shell cd kubernetes @@ -126,7 +202,7 @@ deployment works just as any other one! **Enjoy!** -### Extra: debugging deployment failure +#### Extra: debugging deployment failure The output of `kube-up.sh` displays the IP addresses of the VMs it deploys. You can log into any VM as the `kube` user to poke around and figure out what is @@ -138,7 +214,7 @@ going on (find yourself authorized with your SSH key, or use the password IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level -------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- -Vmware vSphere | Saltstack | Debian | OVS | [docs](/docs/getting-started-guides/vsphere) | | Community ([@imkin](https://github.com/imkin)), ([@abrarshivani](https://github.com/abrarshivani)), ([@kerneltime](https://github.com/kerneltime)), ([@kerneltime](https://github.com/luomiao)) +Vmware vSphere | Kube-anywhere | Photon OS | Flannel | [docs](/docs/getting-started-guides/vsphere) | | Community ([@abrarshivani](https://github.com/abrarshivani)), ([@kerneltime](https://github.com/kerneltime)), ([@BaluDontu](https://github.com/BaluDontu))([@luomiao](https://github.com/luomiao)) For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart. From 59759f5526837a649416cc4bcacc8c1ee10fd528 Mon Sep 17 00:00:00 2001 From: Xing Zhou Date: Tue, 13 Dec 2016 13:21:58 +0800 Subject: [PATCH 14/68] Update API server --apiserver-count description. A validation check is added for option --apiserver-count in kubernetes ticket #38143. As a result, update related description in doc. --- docs/admin/federation-apiserver.md | 2 +- docs/admin/kube-apiserver.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/admin/federation-apiserver.md b/docs/admin/federation-apiserver.md index 72d71547c7..9eb760d087 100644 --- a/docs/admin/federation-apiserver.md +++ b/docs/admin/federation-apiserver.md @@ -26,7 +26,7 @@ federation-apiserver --admission-control-config-file string File with admission control configuration. --advertise-address ip The IP address on which to advertise the apiserver to members of the cluster. This address must be reachable by the rest of the cluster. If blank, the --bind-address will be used. If --bind-address is unspecified, the host's default interface will be used. --anonymous-auth Enables anonymous requests to the secure port of the API server. Requests that are not rejected by another authentication method are treated as anonymous requests. Anonymous requests have a username of system:anonymous, and a group name of system:unauthenticated. (default true) - --apiserver-count int The number of apiservers running in the cluster. (default 1) + --apiserver-count int The number of apiservers running in the cluster. Must be a positive number. (default 1) --audit-log-maxage int The maximum number of days to retain old audit log files based on the timestamp encoded in their filename. --audit-log-maxbackup int The maximum number of old audit log files to retain. --audit-log-maxsize int The maximum size in megabytes of the audit log file before it gets rotated. Defaults to 100MB. diff --git a/docs/admin/kube-apiserver.md b/docs/admin/kube-apiserver.md index bc08ef1f0a..1e2c8a602e 100644 --- a/docs/admin/kube-apiserver.md +++ b/docs/admin/kube-apiserver.md @@ -27,7 +27,7 @@ kube-apiserver --advertise-address ip The IP address on which to advertise the apiserver to members of the cluster. This address must be reachable by the rest of the cluster. If blank, the --bind-address will be used. If --bind-address is unspecified, the host's default interface will be used. --allow-privileged If true, allow privileged containers. --anonymous-auth Enables anonymous requests to the secure port of the API server. Requests that are not rejected by another authentication method are treated as anonymous requests. Anonymous requests have a username of system:anonymous, and a group name of system:unauthenticated. (default true) - --apiserver-count int The number of apiservers running in the cluster. (default 1) + --apiserver-count int The number of apiservers running in the cluster. Must be a positive number. (default 1) --audit-log-maxage int The maximum number of days to retain old audit log files based on the timestamp encoded in their filename. --audit-log-maxbackup int The maximum number of old audit log files to retain. --audit-log-maxsize int The maximum size in megabytes of the audit log file before it gets rotated. Defaults to 100MB. From 521ae621eb869b97d209f35f23ffe37801a92130 Mon Sep 17 00:00:00 2001 From: SRaddict Date: Thu, 22 Dec 2016 16:21:49 +0800 Subject: [PATCH 15/68] duplicated 'the' --- docs/admin/cluster-large.md | 16 ++++++++-------- docs/admin/ha-master-gce.md | 2 +- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/admin/cluster-large.md b/docs/admin/cluster-large.md index f41df12689..41393bc01d 100644 --- a/docs/admin/cluster-large.md +++ b/docs/admin/cluster-large.md @@ -1,10 +1,10 @@ ---- -assignees: -- davidopp -- lavalamp -title: Building Large Clusters ---- - +--- +assignees: +- davidopp +- lavalamp +title: Building Large Clusters +--- + ## Support At {{page.version}}, Kubernetes supports clusters with up to 1000 nodes. More specifically, we support configurations that meet *all* of the following criteria: @@ -21,7 +21,7 @@ At {{page.version}}, Kubernetes supports clusters with up to 1000 nodes. More sp A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by a "master" (the cluster-level control plane). -Normally the number of nodes in a cluster is controlled by the the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](http://releases.k8s.io/{{page.githubbranch}}/cluster/gce/config-default.sh)). +Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](http://releases.k8s.io/{{page.githubbranch}}/cluster/gce/config-default.sh)). Simply changing that value to something very large, however, may cause the setup script to fail for many cloud providers. A GCE deployment, for example, will run in to quota issues and fail to bring the cluster up. diff --git a/docs/admin/ha-master-gce.md b/docs/admin/ha-master-gce.md index 262dafbe0a..871ce56606 100644 --- a/docs/admin/ha-master-gce.md +++ b/docs/admin/ha-master-gce.md @@ -24,7 +24,7 @@ If true, reads will be directed to leader etcd replica. Setting this value to true is optional: reads will be more reliable but will also be slower. Optionally, you can specify a GCE zone where the first master replica is to be created. -Set the the following flag: +Set the following flag: * `KUBE_GCE_ZONE=zone` - zone where the first master replica will run. From 5d6a3aaa53486021aea2e1fe5446a5a5081cf12d Mon Sep 17 00:00:00 2001 From: SRaddict Date: Thu, 22 Dec 2016 16:56:12 +0800 Subject: [PATCH 16/68] fix a series errors of using "a" and "an" --- _includes/v1.3/extensions-v1beta1-definitions.html | 6 +++--- _includes/v1.3/extensions-v1beta1-operations.html | 4 ++-- _includes/v1.3/v1-definitions.html | 6 +++--- _includes/v1.3/v1-operations.html | 8 ++++---- _includes/v1.4/extensions-v1beta1-operations.html | 4 ++-- _includes/v1.4/v1-operations.html | 10 +++++----- docs/admin/addons.md | 2 +- docs/admin/kubelet.md | 2 +- docs/getting-started-guides/libvirt-coreos.md | 2 +- docs/getting-started-guides/mesos/index.md | 2 +- docs/getting-started-guides/rackspace.md | 2 +- docs/tutorials/services/source-ip.md | 2 +- docs/user-guide/connecting-applications.md | 2 +- docs/user-guide/jobs/work-queue-2/rediswq.py | 2 +- docs/user-guide/load-balancer.md | 2 +- docs/user-guide/petset.md | 2 +- docs/user-guide/pods/init-container.md | 2 +- 17 files changed, 30 insertions(+), 30 deletions(-) diff --git a/_includes/v1.3/extensions-v1beta1-definitions.html b/_includes/v1.3/extensions-v1beta1-definitions.html index 7ecddc8d7b..92ce832083 100755 --- a/_includes/v1.3/extensions-v1beta1-definitions.html +++ b/_includes/v1.3/extensions-v1beta1-definitions.html @@ -2079,7 +2079,7 @@ Populated by the system when a graceful deletion is requested. Read-only. More i

    v1.FlexVolumeSource

    -

    FlexVolume represents a generic volume resource that is provisioned/attached using a exec based plugin. This is an alpha feature and may change in future.

    +

    FlexVolume represents a generic volume resource that is provisioned/attached using an exec based plugin. This is an alpha feature and may change in future.

    @@ -2535,7 +2535,7 @@ Populated by the system when a graceful deletion is requested. Read-only. More i - + @@ -5867,7 +5867,7 @@ Both these may change in the future. Incoming requests are matched against the h - + diff --git a/_includes/v1.3/extensions-v1beta1-operations.html b/_includes/v1.3/extensions-v1beta1-operations.html index be39609140..21f12fcf7a 100755 --- a/_includes/v1.3/extensions-v1beta1-operations.html +++ b/_includes/v1.3/extensions-v1beta1-operations.html @@ -5578,7 +5578,7 @@
    -

    create a Ingress

    +

    create an Ingress

    POST /apis/extensions/v1beta1/namespaces/{namespace}/ingresses
    @@ -5959,7 +5959,7 @@
    -

    delete a Ingress

    +

    delete an Ingress

    DELETE /apis/extensions/v1beta1/namespaces/{namespace}/ingresses/{name}
    diff --git a/_includes/v1.3/v1-definitions.html b/_includes/v1.3/v1-definitions.html index e833b003ea..693f3ce4c7 100755 --- a/_includes/v1.3/v1-definitions.html +++ b/_includes/v1.3/v1-definitions.html @@ -2560,7 +2560,7 @@ The resulting set of endpoints can be viewed as:

    v1.FlexVolumeSource

    -

    FlexVolume represents a generic volume resource that is provisioned/attached using a exec based plugin. This is an alpha feature and may change in future.

    +

    FlexVolume represents a generic volume resource that is provisioned/attached using an exec based plugin. This is an alpha feature and may change in future.

    flexVolume

    FlexVolume represents a generic volume resource that is provisioned/attached using a exec based plugin. This is an alpha feature and may change in future.

    FlexVolume represents a generic volume resource that is provisioned/attached using an exec based plugin. This is an alpha feature and may change in future.

    false

    v1.FlexVolumeSource

    path

    Path is a extended POSIX regex as defined by IEEE Std 1003.1, (i.e this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a /. If unspecified, the path defaults to a catch all sending traffic to the backend.

    Path is an extended POSIX regex as defined by IEEE Std 1003.1, (i.e this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a /. If unspecified, the path defaults to a catch all sending traffic to the backend.

    false

    string
    @@ -3268,7 +3268,7 @@ The resulting set of endpoints can be viewed as:
    - + @@ -5555,7 +5555,7 @@ The resulting set of endpoints can be viewed as:
    - + diff --git a/_includes/v1.3/v1-operations.html b/_includes/v1.3/v1-operations.html index 24e21c4f53..de6b5117e6 100755 --- a/_includes/v1.3/v1-operations.html +++ b/_includes/v1.3/v1-operations.html @@ -2676,7 +2676,7 @@
    -

    create a Endpoints

    +

    create an Endpoints

    POST /api/v1/namespaces/{namespace}/endpoints
    @@ -3057,7 +3057,7 @@
    -

    delete a Endpoints

    +

    delete an Endpoints

    DELETE /api/v1/namespaces/{namespace}/endpoints/{name}
    @@ -3619,7 +3619,7 @@
    -

    create a Event

    +

    create an Event

    POST /api/v1/namespaces/{namespace}/events
    @@ -4000,7 +4000,7 @@
    -

    delete a Event

    +

    delete an Event

    DELETE /api/v1/namespaces/{namespace}/events/{name}
    diff --git a/_includes/v1.4/extensions-v1beta1-operations.html b/_includes/v1.4/extensions-v1beta1-operations.html index a18a2f6030..ce55af43d9 100755 --- a/_includes/v1.4/extensions-v1beta1-operations.html +++ b/_includes/v1.4/extensions-v1beta1-operations.html @@ -5578,7 +5578,7 @@
    -

    create a Ingress

    +

    create an Ingress

    POST /apis/extensions/v1beta1/namespaces/{namespace}/ingresses
    @@ -5959,7 +5959,7 @@
    -

    delete a Ingress

    +

    delete an Ingress

    DELETE /apis/extensions/v1beta1/namespaces/{namespace}/ingresses/{name}
    diff --git a/_includes/v1.4/v1-operations.html b/_includes/v1.4/v1-operations.html index 875b464420..f866fc12fc 100755 --- a/_includes/v1.4/v1-operations.html +++ b/_includes/v1.4/v1-operations.html @@ -2676,7 +2676,7 @@
    -

    create a Endpoints

    +

    create an Endpoints

    POST /api/v1/namespaces/{namespace}/endpoints
    @@ -3057,7 +3057,7 @@
    -

    delete a Endpoints

    +

    delete an Endpoints

    DELETE /api/v1/namespaces/{namespace}/endpoints/{name}
    @@ -3619,7 +3619,7 @@
    -

    create a Event

    +

    create an Event

    POST /api/v1/namespaces/{namespace}/events
    @@ -4000,7 +4000,7 @@
    -

    delete a Event

    +

    delete an Event

    DELETE /api/v1/namespaces/{namespace}/events/{name}
    @@ -7885,7 +7885,7 @@
    -

    create eviction of a Eviction

    +

    create eviction of an Eviction

    POST /api/v1/namespaces/{namespace}/pods/{name}/eviction
    diff --git a/docs/admin/addons.md b/docs/admin/addons.md index f45aebeb09..aeee68cc30 100644 --- a/docs/admin/addons.md +++ b/docs/admin/addons.md @@ -14,7 +14,7 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply * [Calico](http://docs.projectcalico.org/v2.0/getting-started/kubernetes/installation/hosted/) is a secure L3 networking and network policy provider. * [Canal](https://github.com/tigera/canal/tree/master/k8s-install/kubeadm) unites Flannel and Calico, providing networking and network policy. -* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) is a overlay network provider that can be used with Kubernetes. +* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) is an overlay network provider that can be used with Kubernetes. * [Romana](http://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/user-guide/networkpolicies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize). * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database. diff --git a/docs/admin/kubelet.md b/docs/admin/kubelet.md index 342189ba94..e593cda77b 100644 --- a/docs/admin/kubelet.md +++ b/docs/admin/kubelet.md @@ -79,7 +79,7 @@ kubelet --experimental-bootstrap-kubeconfig string Path to a kubeconfig file that will be used to get client certificate for kubelet. If the file specified by --kubeconfig does not exist, the bootstrap kubeconfig is used to request a client certificate from the API server. On success, a kubeconfig file referencing the generated key and obtained certificate is written to the path specified by --kubeconfig. The certificate and key file will be stored in the directory pointed by --cert-dir. --experimental-cgroups-per-qos Enable creation of QoS cgroup hierarchy, if true top level QoS and pod cgroups are created. --experimental-check-node-capabilities-before-mount [Experimental] if set true, the kubelet will check the underlying node for required componenets (binaries, etc.) before performing the mount - --experimental-cri [Experimental] Enable the Container Runtime Interface (CRI) integration. If --container-runtime is set to "remote", Kubelet will communicate with the runtime/image CRI server listening on the endpoint specified by --remote-runtime-endpoint/--remote-image-endpoint. If --container-runtime is set to "docker", Kubelet will launch a in-process CRI server on behalf of docker, and communicate over a default endpoint. + --experimental-cri [Experimental] Enable the Container Runtime Interface (CRI) integration. If --container-runtime is set to "remote", Kubelet will communicate with the runtime/image CRI server listening on the endpoint specified by --remote-runtime-endpoint/--remote-image-endpoint. If --container-runtime is set to "docker", Kubelet will launch an in-process CRI server on behalf of docker, and communicate over a default endpoint. --experimental-fail-swap-on Makes the Kubelet fail to start if swap is enabled on the node. This is a temporary opton to maintain legacy behavior, failing due to swap enabled will happen by default in v1.6. --experimental-kernel-memcg-notification If enabled, the kubelet will integrate with the kernel memcg notification to determine if memory eviction thresholds are crossed rather than polling. --experimental-mounter-path string [Experimental] Path of mounter binary. Leave empty to use the default mount. diff --git a/docs/getting-started-guides/libvirt-coreos.md b/docs/getting-started-guides/libvirt-coreos.md index 73be7e4261..e5668dbf53 100644 --- a/docs/getting-started-guides/libvirt-coreos.md +++ b/docs/getting-started-guides/libvirt-coreos.md @@ -30,7 +30,7 @@ Another difference is that no security is enforced on `libvirt-coreos` at all. F * Kubernetes secrets are not protected as securely as they are on production environments; * etc. -So, an k8s application developer should not validate its interaction with Kubernetes on `libvirt-coreos` because he might technically succeed in doing things that are prohibited on a production environment like: +So, a k8s application developer should not validate its interaction with Kubernetes on `libvirt-coreos` because he might technically succeed in doing things that are prohibited on a production environment like: * un-authenticated access to Kube API server; * Access to Kubernetes private data structures inside etcd; diff --git a/docs/getting-started-guides/mesos/index.md b/docs/getting-started-guides/mesos/index.md index 948eae1a41..499ff0ba51 100644 --- a/docs/getting-started-guides/mesos/index.md +++ b/docs/getting-started-guides/mesos/index.md @@ -229,7 +229,7 @@ We assume that kube-dns will use Note that we have passed these two values already as parameter to the apiserver above. -A template for an replication controller spinning up the pod with the 3 containers can be found at [cluster/addons/dns/skydns-rc.yaml.in][11] in the repository. The following steps are necessary in order to get a valid replication controller yaml file: +A template for a replication controller spinning up the pod with the 3 containers can be found at [cluster/addons/dns/skydns-rc.yaml.in][11] in the repository. The following steps are necessary in order to get a valid replication controller yaml file: - replace `{% raw %}{{ pillar['dns_replicas'] }}{% endraw %}` with `1` - replace `{% raw %}{{ pillar['dns_domain'] }}{% endraw %}` with `cluster.local.` diff --git a/docs/getting-started-guides/rackspace.md b/docs/getting-started-guides/rackspace.md index 00c73a8e59..ff59f4d31b 100644 --- a/docs/getting-started-guides/rackspace.md +++ b/docs/getting-started-guides/rackspace.md @@ -45,7 +45,7 @@ There is a specific `cluster/rackspace` directory with the scripts for the follo 1. A cloud network will be created and all instances will be attached to this network. - flanneld uses this network for next hop routing. These routes allow the containers running on each node to communicate with one another on this private network. -2. A SSH key will be created and uploaded if needed. This key must be used to ssh into the machines (we do not capture the password). +2. An SSH key will be created and uploaded if needed. This key must be used to ssh into the machines (we do not capture the password). 3. The master server and additional nodes will be created via the `nova` CLI. A `cloud-config.yaml` is generated and provided as user-data with the entire configuration for the systems. 4. We then boot as many nodes as defined via `$NUM_NODES`. diff --git a/docs/tutorials/services/source-ip.md b/docs/tutorials/services/source-ip.md index 6657e42720..76548e68ad 100644 --- a/docs/tutorials/services/source-ip.md +++ b/docs/tutorials/services/source-ip.md @@ -29,7 +29,7 @@ This document makes use of the following terms: You must have a working Kubernetes 1.5 cluster to run the examples in this document. The examples use a small nginx webserver that echoes back the source -IP of requests it receives through a HTTP header. You can create it as follows: +IP of requests it receives through an HTTP header. You can create it as follows: ```console $ kubectl run source-ip-app --image=gcr.io/google_containers/echoserver:1.4 diff --git a/docs/user-guide/connecting-applications.md b/docs/user-guide/connecting-applications.md index 95d365bdb1..c4ca8d20f0 100644 --- a/docs/user-guide/connecting-applications.md +++ b/docs/user-guide/connecting-applications.md @@ -181,7 +181,7 @@ default-token-il9rc kubernetes.io/service-account-token 1 nginxsecret Opaque 2 ``` -Now modify your nginx replicas to start a https server using the certificate in the secret, and the Service, to expose both ports (80 and 443): +Now modify your nginx replicas to start an https server using the certificate in the secret, and the Service, to expose both ports (80 and 443): {% include code.html language="yaml" file="nginx-secure-app.yaml" ghlink="/docs/user-guide/nginx-secure-app" %} diff --git a/docs/user-guide/jobs/work-queue-2/rediswq.py b/docs/user-guide/jobs/work-queue-2/rediswq.py index ebefa64311..ceda8bd1e3 100644 --- a/docs/user-guide/jobs/work-queue-2/rediswq.py +++ b/docs/user-guide/jobs/work-queue-2/rediswq.py @@ -95,7 +95,7 @@ class RedisWQ(object): # Record that we (this session id) are working on a key. Expire that # note after the lease timeout. # Note: if we crash at this line of the program, then GC will see no lease - # for this item an later return it to the main queue. + # for this item a later return it to the main queue. itemkey = self._itemkey(item) self._db.setex(self._lease_key_prefix + itemkey, lease_secs, self._session) return item diff --git a/docs/user-guide/load-balancer.md b/docs/user-guide/load-balancer.md index d8540d98e5..fadeb38d5f 100644 --- a/docs/user-guide/load-balancer.md +++ b/docs/user-guide/load-balancer.md @@ -93,7 +93,7 @@ Due to the implementation of this feature, the source IP for sessions as seen in that will preserve the client Source IP for GCE/GKE environments. This feature will be phased in for other cloud providers in subsequent releases. ## Annotation to modify the LoadBalancer behavior for preservation of Source IP -In 1.5, an Beta feature has been added that changes the behavior of the external LoadBalancer feature. +In 1.5, a Beta feature has been added that changes the behavior of the external LoadBalancer feature. This feature can be activated by adding the beta annotation below to the metadata section of the Service Configuration file. diff --git a/docs/user-guide/petset.md b/docs/user-guide/petset.md index 3cba1fb31e..07934774b4 100644 --- a/docs/user-guide/petset.md +++ b/docs/user-guide/petset.md @@ -88,7 +88,7 @@ Only use PetSet if your application requires some or all of these properties. Ma Example workloads for PetSet: -* Databases like MySQL or PostgreSQL that require a single instance attached to a NFS persistent volume at any time +* Databases like MySQL or PostgreSQL that require a single instance attached to an NFS persistent volume at any time * Clustered software like Zookeeper, Etcd, or Elasticsearch that require stable membership. ## Alpha limitations diff --git a/docs/user-guide/pods/init-container.md b/docs/user-guide/pods/init-container.md index 75b6efcac3..c9266baf67 100644 --- a/docs/user-guide/pods/init-container.md +++ b/docs/user-guide/pods/init-container.md @@ -105,7 +105,7 @@ If the pod is [restarted](#pod-restart-reasons) all init containers must execute again. Changes to the init container spec are limited to the container image field. -Altering a init container image field is equivalent to restarting the pod. +Altering an init container image field is equivalent to restarting the pod. Because init containers can be restarted, retried, or reexecuted, init container code should be idempotent. In particular, code that writes to files on EmptyDirs From e0a6a2c835c54c3a5508d43158d3c0d21e97f1e5 Mon Sep 17 00:00:00 2001 From: SRaddict Date: Thu, 22 Dec 2016 17:57:06 +0800 Subject: [PATCH 17/68] revert --- docs/admin/cluster-large.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/admin/cluster-large.md b/docs/admin/cluster-large.md index 41393bc01d..f41df12689 100644 --- a/docs/admin/cluster-large.md +++ b/docs/admin/cluster-large.md @@ -1,10 +1,10 @@ ---- -assignees: -- davidopp -- lavalamp -title: Building Large Clusters ---- - +--- +assignees: +- davidopp +- lavalamp +title: Building Large Clusters +--- + ## Support At {{page.version}}, Kubernetes supports clusters with up to 1000 nodes. More specifically, we support configurations that meet *all* of the following criteria: @@ -21,7 +21,7 @@ At {{page.version}}, Kubernetes supports clusters with up to 1000 nodes. More sp A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by a "master" (the cluster-level control plane). -Normally the number of nodes in a cluster is controlled by the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](http://releases.k8s.io/{{page.githubbranch}}/cluster/gce/config-default.sh)). +Normally the number of nodes in a cluster is controlled by the the value `NUM_NODES` in the platform-specific `config-default.sh` file (for example, see [GCE's `config-default.sh`](http://releases.k8s.io/{{page.githubbranch}}/cluster/gce/config-default.sh)). Simply changing that value to something very large, however, may cause the setup script to fail for many cloud providers. A GCE deployment, for example, will run in to quota issues and fail to bring the cluster up. From 8edcfc05b80b5c7fa14b8f8280d6a7cb997a5c71 Mon Sep 17 00:00:00 2001 From: tim-zju <21651152@zju.edu.cn> Date: Thu, 22 Dec 2016 18:17:35 +0800 Subject: [PATCH 18/68] revert Signed-off-by: tim-zju <21651152@zju.edu.cn> --- _includes/partner-script.js | 6 +++--- docs/getting-started-guides/meanstack.md | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/_includes/partner-script.js b/_includes/partner-script.js index c291521a01..4d0a117620 100644 --- a/_includes/partner-script.js +++ b/_includes/partner-script.js @@ -54,7 +54,7 @@ name: 'Skippbox', logo: 'skippbox', link: 'http://www.skippbox.com/tag/products/', - blurb: 'Creator of Cabin the first mobile application for Kubernetes, and kompose. Skippbox's solutions distill all the power of k8s in simple easy to use interfaces.' + blurb: 'Creator of Cabin the first mobile application for Kubernetes, and kompose. Skippbox’s solutions distill all the power of k8s in simple easy to use interfaces.' }, { type: 0, @@ -89,7 +89,7 @@ name: 'Intel', logo: 'intel', link: 'https://tectonic.com/press/intel-coreos-collaborate-on-openstack-with-kubernetes.html', - blurb: 'Powering the GIFEE (Google's Infrastructure for Everyone Else), to run OpenStack deployments on Kubernetes.' + blurb: 'Powering the GIFEE (Google’s Infrastructure for Everyone Else), to run OpenStack deployments on Kubernetes.' }, { type: 0, @@ -243,7 +243,7 @@ name: 'Samsung SDS', logo: 'samsung_sds', link: 'http://www.samsungsdsa.com/cloud-infrastructure_kubernetes', - blurb: 'Samsung SDS's Cloud Native Computing Team offers expert consulting across the range of technical aspects involved in building services targeted at a Kubernetes cluster.' + blurb: 'Samsung SDS’s Cloud Native Computing Team offers expert consulting across the range of technical aspects involved in building services targeted at a Kubernetes cluster.' }, { type: 1, diff --git a/docs/getting-started-guides/meanstack.md b/docs/getting-started-guides/meanstack.md index e1e7bd7696..ee9afc1483 100644 --- a/docs/getting-started-guides/meanstack.md +++ b/docs/getting-started-guides/meanstack.md @@ -83,7 +83,7 @@ $ ls Dockerfile app ``` -Le's build. +Let's build. ```shell $ docker build -t myapp . From c6d6c1e6f9478f2e891b047933de4fa8ef9ee6cd Mon Sep 17 00:00:00 2001 From: Andrey Date: Thu, 22 Dec 2016 12:15:34 +0100 Subject: [PATCH 19/68] Target _blank was removed Serious guys! It is so much annoying - each link in new tab! If I would need it I would hold Ctrl pressed. --- _includes/tree.html | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/_includes/tree.html b/_includes/tree.html index 6387c171e7..4aeaeb0176 100644 --- a/_includes/tree.html +++ b/_includes/tree.html @@ -11,7 +11,6 @@ {% if item.path %} {% assign path = item.path %} {% assign title = item.title %} - {% assign target = " target='_blank'" %} {% else %} {% assign page = site.pages | where: "path", item | first %} {% assign title = page.title %} @@ -20,7 +19,7 @@ {% endcapture %} {% if path %} - + {% endif %} {% endif %} {% endfor %} From 1f7b3148f2a22c511a82e5613afdf43a9be4ba5a Mon Sep 17 00:00:00 2001 From: tim-zju <21651152@zju.edu.cn> Date: Thu, 22 Dec 2016 19:47:40 +0800 Subject: [PATCH 20/68] fix space problems which ide results in Signed-off-by: tim-zju <21651152@zju.edu.cn> --- docs/getting-started-guides/meanstack.md | 6 +- docs/getting-started-guides/windows/index.md | 2 +- .../stateful-application/zookeeper.md | 352 +++++++++--------- docs/user-guide/managing-deployments.md | 4 +- 4 files changed, 182 insertions(+), 182 deletions(-) diff --git a/docs/getting-started-guides/meanstack.md b/docs/getting-started-guides/meanstack.md index ee9afc1483..e5ae6a297e 100644 --- a/docs/getting-started-guides/meanstack.md +++ b/docs/getting-started-guides/meanstack.md @@ -20,9 +20,9 @@ Thankfully, there is a system we can use to manage our containers in a cluster e Before we jump in and start kube'ing it up, it's important to understand some of the fundamentals of Kubernetes. * Containers: These are the Docker, rtk, AppC, or whatever Container you are running. You can think of these like subatomic particles; everything is made up of them, but you rarely (if ever) interact with them directly. -* Pods: Pods are the basic component of Kubernetes. They are a group of Containers that are scheduled, live, and die together. Why would you want to have a group of containers instead of just a single container? Let's say you had a log processor, a web server, and a database. If you couldn't use Pods, you would have to bundle the log processor in the web server and database containers, and each time you updated one you would have to update the other. With Pods, you can just reuse the same log processor for both the web server and database. +* Pods: Pods are the basic component of Kubernetes. They are a group of Containers that are scheduled, live, and die together. Why would you want to have a group of containers instead of just a single container? Let’s say you had a log processor, a web server, and a database. If you couldn't use Pods, you would have to bundle the log processor in the web server and database containers, and each time you updated one you would have to update the other. With Pods, you can just reuse the same log processor for both the web server and database. * Deployments: A Deployment provides declarative updates for Pods. You can define Deployments to create new Pods, or replace existing Pods. You only need to describe the desired state in a Deployment object, and the deployment controller will change the actual state to the desired state at a controlled rate for you. You can define Deployments to create new resources, or replace existing ones by new ones. -* Services: A service is the single point of contact for a group of Pods. For example, let's say you have a Deployment that creates four copies of a web server pod. A Service will split the traffic to each of the four copies. Services are "permanent" while the pods behind them can come and go, so it's a good idea to use Services. +* Services: A service is the single point of contact for a group of Pods. For example, let’s say you have a Deployment that creates four copies of a web server pod. A Service will split the traffic to each of the four copies. Services are "permanent" while the pods behind them can come and go, so it’s a good idea to use Services. ## Step 1: Creating the Container @@ -371,7 +371,7 @@ At this point, the local directory looks like this ```shell $ ls -Dockerfile +Dockerfile app db-deployment.yml db-service.yml diff --git a/docs/getting-started-guides/windows/index.md b/docs/getting-started-guides/windows/index.md index af990c445b..e2c6748330 100644 --- a/docs/getting-started-guides/windows/index.md +++ b/docs/getting-started-guides/windows/index.md @@ -15,7 +15,7 @@ In Kubernetes version 1.5, Windows Server Containers for Kubernetes is supported 4. Docker Version 1.12.2-cs2-ws-beta or later for Windows Server nodes (Linux nodes and Kubernetes control plane can run any Kubernetes supported Docker Version) ## Networking -Network is achieved using L3 routing. Because third-party networking plugins (e.g. flannel, calico, etc) don't natively work on Windows Server, existing technology that is built into the Windows and Linux operating systems is relied on. In this L3 networking approach, a /16 subnet is chosen for the cluster nodes, and a /24 subnet is assigned to each worker node. All pods on a given worker node will be connected to the /24 subnet. This allows pods on the same node to communicate with each other. In order to enable networking between pods running on different nodes, routing features that are built into Windows Server 2016 and Linux are used. +Network is achieved using L3 routing. Because third-party networking plugins (e.g. flannel, calico, etc) don’t natively work on Windows Server, existing technology that is built into the Windows and Linux operating systems is relied on. In this L3 networking approach, a /16 subnet is chosen for the cluster nodes, and a /24 subnet is assigned to each worker node. All pods on a given worker node will be connected to the /24 subnet. This allows pods on the same node to communicate with each other. In order to enable networking between pods running on different nodes, routing features that are built into Windows Server 2016 and Linux are used. ### Linux The above networking approach is already supported on Linux using a bridge interface, which essentially creates a private network local to the node. Similar to the Windows side, routes to all other pod CIDRs must be created in order to send packets via the "public" NIC. diff --git a/docs/tutorials/stateful-application/zookeeper.md b/docs/tutorials/stateful-application/zookeeper.md index b36ed0835b..90a78fdc31 100644 --- a/docs/tutorials/stateful-application/zookeeper.md +++ b/docs/tutorials/stateful-application/zookeeper.md @@ -11,15 +11,15 @@ title: Running ZooKeeper, A CP Distributed System --- {% capture overview %} -This tutorial demonstrates [Apache Zookeeper](https://zookeeper.apache.org) on -Kubernetes using [StatefulSets](/docs/concepts/abstractions/controllers/statefulsets/), -[PodDisruptionBudgets](/docs/admin/disruptions/#specifying-a-poddisruptionbudget), +This tutorial demonstrates [Apache Zookeeper](https://zookeeper.apache.org) on +Kubernetes using [StatefulSets](/docs/concepts/abstractions/controllers/statefulsets/), +[PodDisruptionBudgets](/docs/admin/disruptions/#specifying-a-poddisruptionbudget), and [PodAntiAffinity](/docs/user-guide/node-selection/). {% endcapture %} {% capture prerequisites %} -Before starting this tutorial, you should be familiar with the following +Before starting this tutorial, you should be familiar with the following Kubernetes concepts. * [Pods](/docs/user-guide/pods/single-container/) @@ -34,16 +34,16 @@ Kubernetes concepts. * [kubectl CLI](/docs/user-guide/kubectl) You will require a cluster with at least four nodes, and each node will require -at least 2 CPUs and 4 GiB of memory. In this tutorial you will cordon and -drain the cluster's nodes. **This means that all Pods on the cluster's nodes -will be terminated and evicted, and the nodes will, temporarily, become -unschedulable.** You should use a dedicated cluster for this tutorial, or you -should ensure that the disruption you cause will not interfere with other +at least 2 CPUs and 4 GiB of memory. In this tutorial you will cordon and +drain the cluster's nodes. **This means that all Pods on the cluster's nodes +will be terminated and evicted, and the nodes will, temporarily, become +unschedulable.** You should use a dedicated cluster for this tutorial, or you +should ensure that the disruption you cause will not interfere with other tenants. -This tutorial assumes that your cluster is configured to dynamically provision +This tutorial assumes that your cluster is configured to dynamically provision PersistentVolumes. If your cluster is not configured to do so, you -will have to manually provision three 20 GiB volumes prior to starting this +will have to manually provision three 20 GiB volumes prior to starting this tutorial. {% endcapture %} @@ -60,51 +60,51 @@ After this tutorial, you will know the following. #### ZooKeeper Basics -[Apache ZooKeeper](https://zookeeper.apache.org/doc/current/) is a +[Apache ZooKeeper](https://zookeeper.apache.org/doc/current/) is a distributed, open-source coordination service for distributed applications. -ZooKeeper allows you to read, write, and observe updates to data. Data are -organized in a file system like hierarchy and replicated to all ZooKeeper -servers in the ensemble (a set of ZooKeeper servers). All operations on data -are atomic and sequentially consistent. ZooKeeper ensures this by using the -[Zab](https://pdfs.semanticscholar.org/b02c/6b00bd5dbdbd951fddb00b906c82fa80f0b3.pdf) +ZooKeeper allows you to read, write, and observe updates to data. Data are +organized in a file system like hierarchy and replicated to all ZooKeeper +servers in the ensemble (a set of ZooKeeper servers). All operations on data +are atomic and sequentially consistent. ZooKeeper ensures this by using the +[Zab](https://pdfs.semanticscholar.org/b02c/6b00bd5dbdbd951fddb00b906c82fa80f0b3.pdf) consensus protocol to replicate a state machine across all servers in the ensemble. The ensemble uses the Zab protocol to elect a leader, and -data can not be written until a leader is elected. Once a leader is -elected, the ensemble uses Zab to ensure that all writes are replicated to a +data can not be written until a leader is elected. Once a leader is +elected, the ensemble uses Zab to ensure that all writes are replicated to a quorum before they are acknowledged and made visible to clients. Without respect -to weighted quorums, a quorum is a majority component of the ensemble containing -the current leader. For instance, if the ensemble has three servers, a component -that contains the leader and one other server constitutes a quorum. If the +to weighted quorums, a quorum is a majority component of the ensemble containing +the current leader. For instance, if the ensemble has three servers, a component +that contains the leader and one other server constitutes a quorum. If the ensemble can not achieve a quorum, data can not be written. -ZooKeeper servers keep their entire state machine in memory, but every mutation -is written to a durable WAL (Write Ahead Log) on storage media. When a server -crashes, it can recover its previous state by replaying the WAL. In order to -prevent the WAL from growing without bound, ZooKeeper servers will periodically -snapshot their in memory state to storage media. These snapshots can be loaded -directly into memory, and all WAL entries that preceded the snapshot may be +ZooKeeper servers keep their entire state machine in memory, but every mutation +is written to a durable WAL (Write Ahead Log) on storage media. When a server +crashes, it can recover its previous state by replaying the WAL. In order to +prevent the WAL from growing without bound, ZooKeeper servers will periodically +snapshot their in memory state to storage media. These snapshots can be loaded +directly into memory, and all WAL entries that preceded the snapshot may be safely discarded. ### Creating a ZooKeeper Ensemble -The manifest below contains a -[Headless Service](/docs/user-guide/services/#headless-services), -a [ConfigMap](/docs/user-guide/configmap/), -a [PodDisruptionBudget](/docs/admin/disruptions/#specifying-a-poddisruptionbudget), -and a [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/). +The manifest below contains a +[Headless Service](/docs/user-guide/services/#headless-services), +a [ConfigMap](/docs/user-guide/configmap/), +a [PodDisruptionBudget](/docs/admin/disruptions/#specifying-a-poddisruptionbudget), +and a [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/). {% include code.html language="yaml" file="zookeeper.yaml" ghlink="/docs/tutorials/stateful-application/zookeeper.yaml" %} -Open a command terminal, and use -[`kubectl create`](/docs/user-guide/kubectl/kubectl_create/) to create the +Open a command terminal, and use +[`kubectl create`](/docs/user-guide/kubectl/kubectl_create/) to create the manifest. ```shell kubectl create -f http://k8s.io/docs/tutorials/stateful-application/zookeeper.yaml ``` -This creates the `zk-headless` Headless Service, the `zk-config` ConfigMap, +This creates the `zk-headless` Headless Service, the `zk-config` ConfigMap, the `zk-budget` PodDisruptionBudget, and the `zk` StatefulSet. ```shell @@ -142,29 +142,29 @@ zk-2 0/1 Running 0 19s zk-2 1/1 Running 0 40s ``` -The StatefulSet controller creates three Pods, and each Pod has a container with +The StatefulSet controller creates three Pods, and each Pod has a container with a [ZooKeeper 3.4.9](http://www-us.apache.org/dist/zookeeper/zookeeper-3.4.9/) server. #### Facilitating Leader Election -As there is no terminating algorithm for electing a leader in an anonymous -network, Zab requires explicit membership configuration in order to perform -leader election. Each server in the ensemble needs to have a unique +As there is no terminating algorithm for electing a leader in an anonymous +network, Zab requires explicit membership configuration in order to perform +leader election. Each server in the ensemble needs to have a unique identifier, all servers need to know the global set of identifiers, and each identifier needs to be associated with a network address. -Use [`kubectl exec`](/docs/user-guide/kubectl/kubectl_exec/) to get the hostnames +Use [`kubectl exec`](/docs/user-guide/kubectl/kubectl_exec/) to get the hostnames of the Pods in the `zk` StatefulSet. ```shell for i in 0 1 2; do kubectl exec zk-$i -- hostname; done ``` -The StatefulSet controller provides each Pod with a unique hostname based on its -ordinal index. The hostnames take the form `-`. -As the `replicas` field of the `zk` StatefulSet is set to `3`, the Set's -controller creates three Pods with their hostnames set to `zk-0`, `zk-1`, and -`zk-2`. +The StatefulSet controller provides each Pod with a unique hostname based on its +ordinal index. The hostnames take the form `-`. +As the `replicas` field of the `zk` StatefulSet is set to `3`, the Set's +controller creates three Pods with their hostnames set to `zk-0`, `zk-1`, and +`zk-2`. ```shell zk-0 @@ -172,9 +172,9 @@ zk-1 zk-2 ``` -The servers in a ZooKeeper ensemble use natural numbers as unique identifiers, and -each server's identifier is stored in a file called `myid` in the server's -data directory. +The servers in a ZooKeeper ensemble use natural numbers as unique identifiers, and +each server's identifier is stored in a file called `myid` in the server’s +data directory. Examine the contents of the `myid` file for each server. @@ -182,7 +182,7 @@ Examine the contents of the `myid` file for each server. for i in 0 1 2; do echo "myid zk-$i";kubectl exec zk-$i -- cat /var/lib/zookeeper/data/myid; done ``` -As the identifiers are natural numbers and the ordinal indices are non-negative +As the identifiers are natural numbers and the ordinal indices are non-negative integers, you can generate an identifier by adding one to the ordinal. ```shell @@ -200,7 +200,7 @@ Get the FQDN (Fully Qualified Domain Name) of each Pod in the `zk` StatefulSet. for i in 0 1 2; do kubectl exec zk-$i -- hostname -f; done ``` -The `zk-headless` Service creates a domain for all of the Pods, +The `zk-headless` Service creates a domain for all of the Pods, `zk-headless.default.svc.cluster.local`. ```shell @@ -209,11 +209,11 @@ zk-1.zk-headless.default.svc.cluster.local zk-2.zk-headless.default.svc.cluster.local ``` -The A records in [Kubernetes DNS](/docs/admin/dns/) resolve the FQDNs to the Pods' IP addresses. -If the Pods are rescheduled, the A records will be updated with the Pods' new IP +The A records in [Kubernetes DNS](/docs/admin/dns/) resolve the FQDNs to the Pods' IP addresses. +If the Pods are rescheduled, the A records will be updated with the Pods' new IP addresses, but the A record's names will not change. -ZooKeeper stores its application configuration in a file named `zoo.cfg`. Use +ZooKeeper stores its application configuration in a file named `zoo.cfg`. Use `kubectl exec` to view the contents of the `zoo.cfg` file in the `zk-0` Pod. ``` @@ -222,8 +222,8 @@ kubectl exec zk-0 -- cat /opt/zookeeper/conf/zoo.cfg For the `server.1`, `server.2`, and `server.3` properties at the bottom of the file, the `1`, `2`, and `3` correspond to the identifiers in the -ZooKeeper servers' `myid` files. They are set to the FQDNs for the Pods in -the `zk` StatefulSet. +ZooKeeper servers' `myid` files. They are set to the FQDNs for the Pods in +the `zk` StatefulSet. ```shell clientPort=2181 @@ -244,16 +244,16 @@ server.3=zk-2.zk-headless.default.svc.cluster.local:2888:3888 #### Achieving Consensus -Consensus protocols require that the identifiers of each participant be -unique. No two participants in the Zab protocol should claim the same unique -identifier. This is necessary to allow the processes in the system to agree on -which processes have committed which data. If two Pods were launched with the +Consensus protocols require that the identifiers of each participant be +unique. No two participants in the Zab protocol should claim the same unique +identifier. This is necessary to allow the processes in the system to agree on +which processes have committed which data. If two Pods were launched with the same ordinal, two ZooKeeper servers would both identify themselves as the same server. -When you created the `zk` StatefulSet, the StatefulSet's controller created -each Pod sequentially, in the order defined by the Pods' ordinal indices, and it -waited for each Pod to be Running and Ready before creating the next Pod. +When you created the `zk` StatefulSet, the StatefulSet's controller created +each Pod sequentially, in the order defined by the Pods' ordinal indices, and it +waited for each Pod to be Running and Ready before creating the next Pod. ```shell kubectl get pods -w -l app=zk @@ -277,7 +277,7 @@ zk-2 1/1 Running 0 40s The A records for each Pod are only entered when the Pod becomes Ready. Therefore, the FQDNs of the ZooKeeper servers will only resolve to a single endpoint, and that -endpoint will be the unique ZooKeeper server claiming the identity configured +endpoint will be the unique ZooKeeper server claiming the identity configured in its `myid` file. ```shell @@ -286,7 +286,7 @@ zk-1.zk-headless.default.svc.cluster.local zk-2.zk-headless.default.svc.cluster.local ``` -This ensures that the `servers` properties in the ZooKeepers' `zoo.cfg` files +This ensures that the `servers` properties in the ZooKeepers' `zoo.cfg` files represents a correctly configured ensemble. ```shell @@ -295,16 +295,16 @@ server.2=zk-1.zk-headless.default.svc.cluster.local:2888:3888 server.3=zk-2.zk-headless.default.svc.cluster.local:2888:3888 ``` -When the servers use the Zab protocol to attempt to commit a value, they will -either achieve consensus and commit the value (if leader election has succeeded -and at least two of the Pods are Running and Ready), or they will fail to do so -(if either of the aforementioned conditions are not met). No state will arise +When the servers use the Zab protocol to attempt to commit a value, they will +either achieve consensus and commit the value (if leader election has succeeded +and at least two of the Pods are Running and Ready), or they will fail to do so +(if either of the aforementioned conditions are not met). No state will arise where one server acknowledges a write on behalf of another. #### Sanity Testing the Ensemble -The most basic sanity test is to write some data to one ZooKeeper server and -to read the data from another. +The most basic sanity test is to write some data to one ZooKeeper server and +to read the data from another. Use the `zkCli.sh` script to write `world` to the path `/hello` on the `zk-0` Pod. @@ -327,7 +327,7 @@ Get the data from the `zk-1` Pod. kubectl exec zk-1 zkCli.sh get /hello ``` -The data that you created on `zk-0` is available on all of the servers in the +The data that you created on `zk-0` is available on all of the servers in the ensemble. ```shell @@ -351,12 +351,12 @@ numChildren = 0 #### Providing Durable Storage As mentioned in the [ZooKeeper Basics](#zookeeper-basics) section, -ZooKeeper commits all entries to a durable WAL, and periodically writes snapshots -in memory state, to storage media. Using WALs to provide durability is a common +ZooKeeper commits all entries to a durable WAL, and periodically writes snapshots +in memory state, to storage media. Using WALs to provide durability is a common technique for applications that use consensus protocols to achieve a replicated state machine and for storage applications in general. -Use [`kubectl delete`](/docs/user-guide/kubectl/kubectl_delete/) to delete the +Use [`kubectl delete`](/docs/user-guide/kubectl/kubectl_delete/) to delete the `zk` StatefulSet. ```shell @@ -392,7 +392,7 @@ Reapply the manifest in `zookeeper.yaml`. kubectl apply -f http://k8s.io/docs/tutorials/stateful-application/zookeeper.yaml ``` -The `zk` StatefulSet will be created, but, as they already exist, the other API +The `zk` StatefulSet will be created, but, as they already exist, the other API Objects in the manifest will not be modified. ```shell @@ -429,14 +429,14 @@ zk-2 0/1 Running 0 19s zk-2 1/1 Running 0 40s ``` -Get the value you entered during the [sanity test](#sanity-testing-the-ensemble), +Get the value you entered during the [sanity test](#sanity-testing-the-ensemble), from the `zk-2` Pod. ```shell kubectl exec zk-2 zkCli.sh get /hello ``` -Even though all of the Pods in the `zk` StatefulSet have been terminated and +Even though all of the Pods in the `zk` StatefulSet have been terminated and recreated, the ensemble still serves the original value. ```shell @@ -457,8 +457,8 @@ dataLength = 5 numChildren = 0 ``` -The `volumeClaimTemplates` field, of the `zk` StatefulSet's `spec`, specifies a -PersistentVolume that will be provisioned for each Pod. +The `volumeClaimTemplates` field, of the `zk` StatefulSet's `spec`, specifies a +PersistentVolume that will be provisioned for each Pod. ```yaml volumeClaimTemplates: @@ -474,8 +474,8 @@ volumeClaimTemplates: ``` -The StatefulSet controller generates a PersistentVolumeClaim for each Pod in -the StatefulSet. +The StatefulSet controller generates a PersistentVolumeClaim for each Pod in +the StatefulSet. Get the StatefulSet's PersistentVolumeClaims. @@ -483,7 +483,7 @@ Get the StatefulSet's PersistentVolumeClaims. kubectl get pvc -l app=zk ``` -When the StatefulSet recreated its Pods, the Pods' PersistentVolumes were +When the StatefulSet recreated its Pods, the Pods' PersistentVolumes were remounted. ```shell @@ -502,19 +502,19 @@ volumeMounts: mountPath: /var/lib/zookeeper ``` -When a Pod in the `zk` StatefulSet is (re)scheduled, it will always have the -same PersistentVolume mounted to the ZooKeeper server's data directory. -Even when the Pods are rescheduled, all of the writes made to the ZooKeeper +When a Pod in the `zk` StatefulSet is (re)scheduled, it will always have the +same PersistentVolume mounted to the ZooKeeper server's data directory. +Even when the Pods are rescheduled, all of the writes made to the ZooKeeper servers' WALs, and all of their snapshots, remain durable. ### Ensuring Consistent Configuration As noted in the [Facilitating Leader Election](#facilitating-leader-election) and -[Achieving Consensus](#achieving-consensus) sections, the servers in a -ZooKeeper ensemble require consistent configuration in order to elect a leader +[Achieving Consensus](#achieving-consensus) sections, the servers in a +ZooKeeper ensemble require consistent configuration in order to elect a leader and form a quorum. They also require consistent configuration of the Zab protocol -in order for the protocol to work correctly over a network. You can use -ConfigMaps to achieve this. +in order for the protocol to work correctly over a network. You can use +ConfigMaps to achieve this. Get the `zk-config` ConfigMap. @@ -532,8 +532,8 @@ data: tick: "2000" ``` -The `env` field of the `zk` StatefulSet's Pod `template` reads the ConfigMap -into environment variables. These variables are injected into the containers +The `env` field of the `zk` StatefulSet's Pod `template` reads the ConfigMap +into environment variables. These variables are injected into the containers environment. ```yaml @@ -581,7 +581,7 @@ env: ``` The entry point of the container invokes a bash script, `zkConfig.sh`, prior to -launching the ZooKeeper server process. This bash script generates the +launching the ZooKeeper server process. This bash script generates the ZooKeeper configuration files from the supplied environment variables. ```yaml @@ -597,8 +597,8 @@ Examine the environment of all of the Pods in the `zk` StatefulSet. for i in 0 1 2; do kubectl exec zk-$i env | grep ZK_*;echo""; done ``` -All of the variables populated from `zk-config` contain identical values. This -allows the `zkGenConfig.sh` script to create consistent configurations for all +All of the variables populated from `zk-config` contain identical values. This +allows the `zkGenConfig.sh` script to create consistent configurations for all of the ZooKeeper servers in the ensemble. ```shell @@ -653,16 +653,16 @@ ZK_LOG_DIR=/var/log/zookeeper #### Configuring Logging -One of the files generated by the `zkConfigGen.sh` script controls ZooKeeper's logging. -ZooKeeper uses [Log4j](http://logging.apache.org/log4j/2.x/), and, by default, -it uses a time and size based rolling file appender for its logging configuration. +One of the files generated by the `zkConfigGen.sh` script controls ZooKeeper's logging. +ZooKeeper uses [Log4j](http://logging.apache.org/log4j/2.x/), and, by default, +it uses a time and size based rolling file appender for its logging configuration. Get the logging configuration from one of Pods in the `zk` StatefulSet. ```shell kubectl exec zk-0 cat /usr/etc/zookeeper/log4j.properties ``` -The logging configuration below will cause the ZooKeeper process to write all +The logging configuration below will cause the ZooKeeper process to write all of its logs to the standard output file stream. ```shell @@ -675,20 +675,20 @@ log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n ``` -This is the simplest possible way to safely log inside the container. As the -application's logs are being written to standard out, Kubernetes will handle -log rotation for you. Kubernetes also implements a sane retention policy that -ensures application logs written to standard out and standard error do not +This is the simplest possible way to safely log inside the container. As the +application's logs are being written to standard out, Kubernetes will handle +log rotation for you. Kubernetes also implements a sane retention policy that +ensures application logs written to standard out and standard error do not exhaust local storage media. -Use [`kubectl logs`](/docs/user-guide/kubectl/kubectl_logs/) to retrieve the last +Use [`kubectl logs`](/docs/user-guide/kubectl/kubectl_logs/) to retrieve the last few log lines from one of the Pods. ```shell kubectl logs zk-0 --tail 20 ``` -Application logs that are written to standard out or standard error are viewable +Application logs that are written to standard out or standard error are viewable using `kubectl logs` and from the Kubernetes Dashboard. ```shell @@ -714,19 +714,19 @@ using `kubectl logs` and from the Kubernetes Dashboard. 2016-12-06 19:34:46,230 [myid:1] - INFO [Thread-1142:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52768 (no session established for client) ``` -Kubernetes also supports more powerful, but more complex, logging integrations -with [Google Cloud Logging](https://github.com/kubernetes/contrib/blob/master/logging/fluentd-sidecar-gcp/README.md) +Kubernetes also supports more powerful, but more complex, logging integrations +with [Google Cloud Logging](https://github.com/kubernetes/contrib/blob/master/logging/fluentd-sidecar-gcp/README.md) and [ELK](https://github.com/kubernetes/contrib/blob/master/logging/fluentd-sidecar-es/README.md). For cluster level log shipping and aggregation, you should consider deploying a -[sidecar](http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html) +[sidecar](http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html) container to rotate and ship your logs. #### Configuring a Non-Privileged User -The best practices with respect to allowing an application to run as a privileged -user inside of a container are a matter of debate. If your organization requires -that applications be run as a non-privileged user you can use a -[SecurityContext](/docs/user-guide/security-context/) to control the user that +The best practices with respect to allowing an application to run as a privileged +user inside of a container are a matter of debate. If your organization requires +that applications be run as a non-privileged user you can use a +[SecurityContext](/docs/user-guide/security-context/) to control the user that the entry point runs as. The `zk` StatefulSet's Pod `template` contains a SecurityContext. @@ -737,7 +737,7 @@ securityContext: fsGroup: 1000 ``` -In the Pods' containers, UID 1000 corresponds to the zookeeper user and GID 1000 +In the Pods' containers, UID 1000 corresponds to the zookeeper user and GID 1000 corresponds to the zookeeper group. Get the ZooKeeper process information from the `zk-0` Pod. @@ -746,7 +746,7 @@ Get the ZooKeeper process information from the `zk-0` Pod. kubectl exec zk-0 -- ps -elf ``` -As the `runAsUser` field of the `securityContext` object is set to 1000, +As the `runAsUser` field of the `securityContext` object is set to 1000, instead of running as root, the ZooKeeper process runs as the zookeeper user. ```shell @@ -755,8 +755,8 @@ F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 0 S zookeep+ 27 1 0 80 0 - 1155556 - 20:46 ? 00:00:19 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,CONSOLE -cp /usr/bin/../build/classes:/usr/bin/../build/lib/*.jar:/usr/bin/../share/zookeeper/zookeeper-3.4.9.jar:/usr/bin/../share/zookeeper/slf4j-log4j12-1.6.1.jar:/usr/bin/../share/zookeeper/slf4j-api-1.6.1.jar:/usr/bin/../share/zookeeper/netty-3.10.5.Final.jar:/usr/bin/../share/zookeeper/log4j-1.2.16.jar:/usr/bin/../share/zookeeper/jline-0.9.94.jar:/usr/bin/../src/java/lib/*.jar:/usr/bin/../etc/zookeeper: -Xmx2G -Xms2G -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /usr/bin/../etc/zookeeper/zoo.cfg ``` -By default, when the Pod's PersistentVolume is mounted to the ZooKeeper server's -data directory, it is only accessible by the root user. This configuration +By default, when the Pod's PersistentVolume is mounted to the ZooKeeper server's +data directory, it is only accessible by the root user. This configuration prevents the ZooKeeper process from writing to its WAL and storing its snapshots. Get the file permissions of the ZooKeeper data directory on the `zk-0` Pod. @@ -765,8 +765,8 @@ Get the file permissions of the ZooKeeper data directory on the `zk-0` Pod. kubectl exec -ti zk-0 -- ls -ld /var/lib/zookeeper/data ``` -As the `fsGroup` field of the `securityContext` object is set to 1000, -the ownership of the Pods' PersistentVolumes is set to the zookeeper group, +As the `fsGroup` field of the `securityContext` object is set to 1000, +the ownership of the Pods' PersistentVolumes is set to the zookeeper group, and the ZooKeeper process is able to successfully read and write its data. ```shell @@ -775,21 +775,21 @@ drwxr-sr-x 3 zookeeper zookeeper 4096 Dec 5 20:45 /var/lib/zookeeper/data ### Managing the ZooKeeper Process -The [ZooKeeper documentation](https://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_supervision) -documentation indicates that "You will want to have a supervisory process that -manages each of your ZooKeeper server processes (JVM)." Utilizing a watchdog -(supervisory process) to restart failed processes in a distributed system is a -common pattern. When deploying an application in Kubernetes, rather than using -an external utility as a supervisory process, you should use Kubernetes as the +The [ZooKeeper documentation](https://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_supervision) +documentation indicates that "You will want to have a supervisory process that +manages each of your ZooKeeper server processes (JVM)." Utilizing a watchdog +(supervisory process) to restart failed processes in a distributed system is a +common pattern. When deploying an application in Kubernetes, rather than using +an external utility as a supervisory process, you should use Kubernetes as the watchdog for your application. -#### Handling Process Failure +#### Handling Process Failure -[Restart Policies](/docs/user-guide/pod-states/#restartpolicy) control how +[Restart Policies](/docs/user-guide/pod-states/#restartpolicy) control how Kubernetes handles process failures for the entry point of the container in a Pod. For Pods in a StatefulSet, the only appropriate RestartPolicy is Always, and this -is the default value. For stateful applications you should **never** override +is the default value. For stateful applications you should **never** override the default policy. @@ -799,7 +799,7 @@ Examine the process tree for the ZooKeeper server running in the `zk-0` Pod. kubectl exec zk-0 -- ps -ef ``` -The command used as the container's entry point has PID 1, and the +The command used as the container's entry point has PID 1, and the the ZooKeeper process, a child of the entry point, has PID 23. @@ -824,8 +824,8 @@ In another terminal, kill the ZooKeeper process in Pod `zk-0`. ``` -The death of the ZooKeeper process caused its parent process to terminate. As -the RestartPolicy of the container is Always, the parent process was relaunched. +The death of the ZooKeeper process caused its parent process to terminate. As +the RestartPolicy of the container is Always, the parent process was relaunched. ```shell @@ -840,19 +840,19 @@ zk-0 1/1 Running 1 29m ``` -If your application uses a script (such as zkServer.sh) to launch the process +If your application uses a script (such as zkServer.sh) to launch the process that implements the application's business logic, the script must terminate with the child process. This ensures that Kubernetes will restart the application's -container when the process implementing the application's business logic fails. +container when the process implementing the application's business logic fails. #### Testing for Liveness -Configuring your application to restart failed processes is not sufficient to -keep a distributed system healthy. There are many scenarios where -a system's processes can be both alive and unresponsive, or otherwise -unhealthy. You should use liveness probes in order to notify Kubernetes +Configuring your application to restart failed processes is not sufficient to +keep a distributed system healthy. There are many scenarios where +a system's processes can be both alive and unresponsive, or otherwise +unhealthy. You should use liveness probes in order to notify Kubernetes that your application's processes are unhealthy and should be restarted. @@ -869,7 +869,7 @@ The Pod `template` for the `zk` StatefulSet specifies a liveness probe. ``` -The probe calls a simple bash script that uses the ZooKeeper `ruok` four letter +The probe calls a simple bash script that uses the ZooKeeper `ruok` four letter word to test the server's health. @@ -900,7 +900,7 @@ kubectl exec zk-0 -- rm /opt/zookeeper/bin/zkOk.sh ``` -When the liveness probe for the ZooKeeper process fails, Kubernetes will +When the liveness probe for the ZooKeeper process fails, Kubernetes will automatically restart the process for you, ensuring that unhealthy processes in the ensemble are restarted. @@ -921,10 +921,10 @@ zk-0 1/1 Running 1 1h #### Testing for Readiness -Readiness is not the same as liveness. If a process is alive, it is scheduled -and healthy. If a process is ready, it is able to process input. Liveness is +Readiness is not the same as liveness. If a process is alive, it is scheduled +and healthy. If a process is ready, it is able to process input. Liveness is a necessary, but not sufficient, condition for readiness. There are many cases, -particularly during initialization and termination, when a process can be +particularly during initialization and termination, when a process can be alive but not ready. @@ -932,8 +932,8 @@ If you specify a readiness probe, Kubernetes will ensure that your application's processes will not receive network traffic until their readiness checks pass. -For a ZooKeeper server, liveness implies readiness. Therefore, the readiness -probe from the `zookeeper.yaml` manifest is identical to the liveness probe. +For a ZooKeeper server, liveness implies readiness. Therefore, the readiness +probe from the `zookeeper.yaml` manifest is identical to the liveness probe. ```yaml @@ -946,28 +946,28 @@ probe from the `zookeeper.yaml` manifest is identical to the liveness probe. ``` -Even though the liveness and readiness probes are identical, it is important -to specify both. This ensures that only healthy servers in the ZooKeeper +Even though the liveness and readiness probes are identical, it is important +to specify both. This ensures that only healthy servers in the ZooKeeper ensemble receive network traffic. ### Tolerating Node Failure -ZooKeeper needs a quorum of servers in order to successfully commit mutations -to data. For a three server ensemble, two servers must be healthy in order for -writes to succeed. In quorum based systems, members are deployed across failure -domains to ensure availability. In order to avoid an outage, due to the loss of an -individual machine, best practices preclude co-locating multiple instances of the +ZooKeeper needs a quorum of servers in order to successfully commit mutations +to data. For a three server ensemble, two servers must be healthy in order for +writes to succeed. In quorum based systems, members are deployed across failure +domains to ensure availability. In order to avoid an outage, due to the loss of an +individual machine, best practices preclude co-locating multiple instances of the application on the same machine. -By default, Kubernetes may co-locate Pods in a StatefulSet on the same node. +By default, Kubernetes may co-locate Pods in a StatefulSet on the same node. For the three server ensemble you created, if two servers reside on the same node, and that node fails, the clients of your ZooKeeper service will experience -an outage until at least one of the Pods can be rescheduled. +an outage until at least one of the Pods can be rescheduled. You should always provision additional capacity to allow the processes of critical -systems to be rescheduled in the event of node failures. If you do so, then the -outage will only last until the Kubernetes scheduler reschedules one of the ZooKeeper +systems to be rescheduled in the event of node failures. If you do so, then the +outage will only last until the Kubernetes scheduler reschedules one of the ZooKeeper servers. However, if you want your service to tolerate node failures with no downtime, you should use a `PodAntiAffinity` annotation. @@ -985,7 +985,7 @@ kubernetes-minion-group-a5aq kubernetes-minion-group-2g2d ``` -This is because the Pods in the `zk` StatefulSet contain a +This is because the Pods in the `zk` StatefulSet contain a [PodAntiAffinity](/docs/user-guide/node-selection/) annotation. ```yaml @@ -1006,11 +1006,11 @@ scheduler.alpha.kubernetes.io/affinity: > } ``` -The `requiredDuringSchedulingRequiredDuringExecution` field tells the +The `requiredDuringSchedulingRequiredDuringExecution` field tells the Kubernetes Scheduler that it should never co-locate two Pods from the `zk-headless` Service in the domain defined by the `topologyKey`. The `topologyKey` -`kubernetes.io/hostname` indicates that the domain is an individual node. Using -different rules, labels, and selectors, you can extend this technique to spread +`kubernetes.io/hostname` indicates that the domain is an individual node. Using +different rules, labels, and selectors, you can extend this technique to spread your ensemble across physical, network, and power failure domains. ### Surviving Maintenance @@ -1018,8 +1018,8 @@ your ensemble across physical, network, and power failure domains. **In this section you will cordon and drain nodes. If you are using this tutorial on a shared cluster, be sure that this will not adversely affect other tenants.** -The previous section showed you how to spread your Pods across nodes to survive -unplanned node failures, but you also need to plan for temporary node failures +The previous section showed you how to spread your Pods across nodes to survive +unplanned node failures, but you also need to plan for temporary node failures that occur due to planned maintenance. Get the nodes in your cluster. @@ -1028,7 +1028,7 @@ Get the nodes in your cluster. kubectl get nodes ``` -Use [`kubectl cordon`](/docs/user-guide/kubectl/kubectl_cordon/) to +Use [`kubectl cordon`](/docs/user-guide/kubectl/kubectl_cordon/) to cordon all but four of the nodes in your cluster. ```shell{% raw %} @@ -1041,8 +1041,8 @@ Get the `zk-budget` PodDisruptionBudget. kubectl get poddisruptionbudget zk-budget ``` -The `min-available` field indicates to Kubernetes that at least two Pods from -`zk` StatefulSet must be available at any time. +The `min-available` field indicates to Kubernetes that at least two Pods from +`zk` StatefulSet must be available at any time. ```yaml NAME MIN-AVAILABLE ALLOWED-DISRUPTIONS AGE @@ -1065,7 +1065,7 @@ kubernetes-minion-group-ixsl kubernetes-minion-group-i4c4 {% endraw %}``` -Use [`kubectl drain`](/docs/user-guide/kubectl/kubectl_drain/) to cordon and +Use [`kubectl drain`](/docs/user-guide/kubectl/kubectl_drain/) to cordon and drain the node on which the `zk-0` Pod is scheduled. ```shell {% raw %} @@ -1075,7 +1075,7 @@ pod "zk-0" deleted node "kubernetes-minion-group-pb41" drained {% endraw %}``` -As there are four nodes in your cluster, `kubectl drain`, succeeds and the +As there are four nodes in your cluster, `kubectl drain`, succeeds and the `zk-0` is rescheduled to another node. ``` @@ -1095,7 +1095,7 @@ zk-0 0/1 Running 0 51s zk-0 1/1 Running 0 1m ``` -Keep watching the StatefulSet's Pods in the first terminal and drain the node on which +Keep watching the StatefulSet's Pods in the first terminal and drain the node on which `zk-1` is scheduled. ```shell{% raw %} @@ -1105,8 +1105,8 @@ pod "zk-1" deleted node "kubernetes-minion-group-ixsl" drained {% endraw %}``` -The `zk-1` Pod can not be scheduled. As the `zk` StatefulSet contains a -`PodAntiAffinity` annotation preventing co-location of the Pods, and as only +The `zk-1` Pod can not be scheduled. As the `zk` StatefulSet contains a +`PodAntiAffinity` annotation preventing co-location of the Pods, and as only two nodes are schedulable, the Pod will remain in a Pending state. ```shell @@ -1133,7 +1133,7 @@ zk-1 0/1 Pending 0 0s zk-1 0/1 Pending 0 0s ``` -Continue to watch the Pods of the stateful set, and drain the node on which +Continue to watch the Pods of the stateful set, and drain the node on which `zk-2` is scheduled. ```shell{% raw %} @@ -1145,9 +1145,9 @@ There are pending pods when an error occurred: Cannot evict pod as it would viol pod/zk-2 {% endraw %}``` -Use `CRTL-C` to terminate to kubectl. +Use `CRTL-C` to terminate to kubectl. -You can not drain the third node because evicting `zk-2` would violate `zk-budget`. However, +You can not drain the third node because evicting `zk-2` would violate `zk-budget`. However, the node will remain cordoned. Use `zkCli.sh` to retrieve the value you entered during the sanity test from `zk-0`. @@ -1232,9 +1232,9 @@ node "kubernetes-minion-group-ixsl" uncordoned ``` You can use `kubectl drain` in conjunction with PodDisruptionBudgets to ensure that your service -remains available during maintenance. If drain is used to cordon nodes and evict pods prior to -taking the node offline for maintenance, services that express a disruption budget will have that -budget respected. You should always allocate additional capacity for critical services so that +remains available during maintenance. If drain is used to cordon nodes and evict pods prior to +taking the node offline for maintenance, services that express a disruption budget will have that +budget respected. You should always allocate additional capacity for critical services so that their Pods can be immediately rescheduled. {% endcapture %} @@ -1242,8 +1242,8 @@ their Pods can be immediately rescheduled. {% capture cleanup %} * Use `kubectl uncordon` to uncordon all the nodes in your cluster. * You will need to delete the persistent storage media for the PersistentVolumes -used in this tutorial. Follow the necessary steps, based on your environment, -storage configuration, and provisioning method, to ensure that all storage is +used in this tutorial. Follow the necessary steps, based on your environment, +storage configuration, and provisioning method, to ensure that all storage is reclaimed. {% endcapture %} {% include templates/tutorial.md %} diff --git a/docs/user-guide/managing-deployments.md b/docs/user-guide/managing-deployments.md index 43e283b4a8..c20a9ceeb5 100644 --- a/docs/user-guide/managing-deployments.md +++ b/docs/user-guide/managing-deployments.md @@ -85,8 +85,8 @@ NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-nginx-svc 10.0.0.208 80/TCP 0s ``` -With the above commands, we first create resources under docs/user-guide/nginx/ and print the resources created with `-o name` output format -(print each resource as resource/name). Then we `grep` only the "service", and then print it with `kubectl get`. +With the above commands, we first create resources under docs/user-guide/nginx/ and print the resources created with `-o name` output format +(print each resource as resource/name). Then we `grep` only the "service", and then print it with `kubectl get`. If you happen to organize your resources across several subdirectories within a particular directory, you can recursively perform the operations on the subdirectories also, by specifying `--recursive` or `-R` alongside the `--filename,-f` flag. From df7eb8128d2b6e64dbe100b1578ad5c1d77b93d3 Mon Sep 17 00:00:00 2001 From: tim-zju <21651152@zju.edu.cn> Date: Thu, 22 Dec 2016 20:01:22 +0800 Subject: [PATCH 21/68] fix space problems which ide results in Signed-off-by: tim-zju <21651152@zju.edu.cn> --- docs/getting-started-guides/windows/index.md | 6 ++-- docs/user-guide/managing-deployments.md | 34 +++++++++--------- docs/user-guide/pod-security-policy/index.md | 36 +++++++++---------- .../replication-controller/index.md | 4 +-- docs/user-guide/security-context.md | 4 +-- 5 files changed, 42 insertions(+), 42 deletions(-) diff --git a/docs/getting-started-guides/windows/index.md b/docs/getting-started-guides/windows/index.md index e2c6748330..b5926744ae 100644 --- a/docs/getting-started-guides/windows/index.md +++ b/docs/getting-started-guides/windows/index.md @@ -38,13 +38,13 @@ To run Windows Server Containers on Kubernetes, you'll need to set up both your 1. Windows Server container host running Windows Server 2016 and Docker v1.12. Follow the setup instructions outlined by this blog post: https://msdn.microsoft.com/en-us/virtualization/windowscontainers/quick_start/quick_start_windows_server 2. DNS support for Windows recently got merged to docker master and is currently not supported in a stable docker release. To use DNS build docker from master or download the binary from [Docker master](https://master.dockerproject.org/) -3. Pull the `apprenda/pause` image from `https://hub.docker.com/r/apprenda/pause` +3. Pull the `apprenda/pause` image from `https://hub.docker.com/r/apprenda/pause` 4. RRAS (Routing) Windows feature enabled 5. Install a VMSwitch of type `Internal`, by running `New-VMSwitch -Name KubeProxySwitch -SwitchType Internal` command in *PowerShell* window. This will create a new Network Interface with name `vEthernet (KubeProxySwitch)`. This interface will be used by kube-proxy to add Service IPs. **Linux Host Setup** -1. Linux hosts should be setup according to their respective distro documentation and the requirements of the Kubernetes version you will be using. +1. Linux hosts should be setup according to their respective distro documentation and the requirements of the Kubernetes version you will be using. 2. CNI network plugin installed. ### Component Setup @@ -111,7 +111,7 @@ route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 if Date: Thu, 22 Dec 2016 20:28:51 +0800 Subject: [PATCH 22/68] fix space problems which ide results in Signed-off-by: tim-zju <21651152@zju.edu.cn> --- docs/getting-started-guides/meanstack.md | 4 ++-- docs/getting-started-guides/windows/index.md | 2 +- docs/tutorials/stateful-application/zookeeper.md | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/getting-started-guides/meanstack.md b/docs/getting-started-guides/meanstack.md index e5ae6a297e..ca34d32753 100644 --- a/docs/getting-started-guides/meanstack.md +++ b/docs/getting-started-guides/meanstack.md @@ -20,9 +20,9 @@ Thankfully, there is a system we can use to manage our containers in a cluster e Before we jump in and start kube'ing it up, it's important to understand some of the fundamentals of Kubernetes. * Containers: These are the Docker, rtk, AppC, or whatever Container you are running. You can think of these like subatomic particles; everything is made up of them, but you rarely (if ever) interact with them directly. -* Pods: Pods are the basic component of Kubernetes. They are a group of Containers that are scheduled, live, and die together. Why would you want to have a group of containers instead of just a single container? Let’s say you had a log processor, a web server, and a database. If you couldn't use Pods, you would have to bundle the log processor in the web server and database containers, and each time you updated one you would have to update the other. With Pods, you can just reuse the same log processor for both the web server and database. +* Pods: Pods are the basic component of Kubernetes. They are a group of Containers that are scheduled, live, and die together. Why would you want to have a group of containers instead of just a single container? Let's say you had a log processor, a web server, and a database. If you couldn't use Pods, you would have to bundle the log processor in the web server and database containers, and each time you updated one you would have to update the other. With Pods, you can just reuse the same log processor for both the web server and database. * Deployments: A Deployment provides declarative updates for Pods. You can define Deployments to create new Pods, or replace existing Pods. You only need to describe the desired state in a Deployment object, and the deployment controller will change the actual state to the desired state at a controlled rate for you. You can define Deployments to create new resources, or replace existing ones by new ones. -* Services: A service is the single point of contact for a group of Pods. For example, let’s say you have a Deployment that creates four copies of a web server pod. A Service will split the traffic to each of the four copies. Services are "permanent" while the pods behind them can come and go, so it’s a good idea to use Services. +* Services: A service is the single point of contact for a group of Pods. For example, let's say you have a Deployment that creates four copies of a web server pod. A Service will split the traffic to each of the four copies. Services are "permanent" while the pods behind them can come and go, so it's a good idea to use Services. ## Step 1: Creating the Container diff --git a/docs/getting-started-guides/windows/index.md b/docs/getting-started-guides/windows/index.md index b5926744ae..dd775b81af 100644 --- a/docs/getting-started-guides/windows/index.md +++ b/docs/getting-started-guides/windows/index.md @@ -15,7 +15,7 @@ In Kubernetes version 1.5, Windows Server Containers for Kubernetes is supported 4. Docker Version 1.12.2-cs2-ws-beta or later for Windows Server nodes (Linux nodes and Kubernetes control plane can run any Kubernetes supported Docker Version) ## Networking -Network is achieved using L3 routing. Because third-party networking plugins (e.g. flannel, calico, etc) don’t natively work on Windows Server, existing technology that is built into the Windows and Linux operating systems is relied on. In this L3 networking approach, a /16 subnet is chosen for the cluster nodes, and a /24 subnet is assigned to each worker node. All pods on a given worker node will be connected to the /24 subnet. This allows pods on the same node to communicate with each other. In order to enable networking between pods running on different nodes, routing features that are built into Windows Server 2016 and Linux are used. +Network is achieved using L3 routing. Because third-party networking plugins (e.g. flannel, calico, etc) don't natively work on Windows Server, existing technology that is built into the Windows and Linux operating systems is relied on. In this L3 networking approach, a /16 subnet is chosen for the cluster nodes, and a /24 subnet is assigned to each worker node. All pods on a given worker node will be connected to the /24 subnet. This allows pods on the same node to communicate with each other. In order to enable networking between pods running on different nodes, routing features that are built into Windows Server 2016 and Linux are used. ### Linux The above networking approach is already supported on Linux using a bridge interface, which essentially creates a private network local to the node. Similar to the Windows side, routes to all other pod CIDRs must be created in order to send packets via the "public" NIC. diff --git a/docs/tutorials/stateful-application/zookeeper.md b/docs/tutorials/stateful-application/zookeeper.md index 90a78fdc31..c6dcf705be 100644 --- a/docs/tutorials/stateful-application/zookeeper.md +++ b/docs/tutorials/stateful-application/zookeeper.md @@ -173,7 +173,7 @@ zk-2 ``` The servers in a ZooKeeper ensemble use natural numbers as unique identifiers, and -each server's identifier is stored in a file called `myid` in the server’s +each server's identifier is stored in a file called `myid` in the server's data directory. Examine the contents of the `myid` file for each server. From bbc441504211624359034cdd4fcc9b42ed02edc9 Mon Sep 17 00:00:00 2001 From: Michail Kargakis Date: Fri, 9 Dec 2016 19:42:15 +0100 Subject: [PATCH 23/68] Link sections that talk about deployment status --- docs/user-guide/deployments.md | 66 +++++++++++++++++++++++++--------- 1 file changed, 49 insertions(+), 17 deletions(-) diff --git a/docs/user-guide/deployments.md b/docs/user-guide/deployments.md index c53c1e19ae..6f222dbc40 100644 --- a/docs/user-guide/deployments.md +++ b/docs/user-guide/deployments.md @@ -86,24 +86,56 @@ After creating or updating a Deployment, you would want to confirm whether it su ```shell $ kubectl rollout status deployment/nginx-deployment -deployment nginx-deployment successfully rolled out +deployment "nginx-deployment" successfully rolled out ``` This verifies the Deployment's `.status.observedGeneration` >= `.metadata.generation`, and its up-to-date replicas -(`.status.updatedReplicas`) matches the desired replicas (`.spec.replicas`) to determine if the rollout succeeded. -If the rollout is still in progress, it watches for Deployment status changes and prints related messages. - -Note that it's impossible to know whether a Deployment will ever succeed, so if the above command doesn't return success, -you'll need to timeout and give up at some point. - -Additionally, if you set `.spec.minReadySeconds`, you would also want to check if the available replicas (`.status.availableReplicas`) matches the desired replicas too. +(`.status.updatedReplicas`) matches the desired replicas (`.spec.replicas`) to determine if the rollout succeeded. +It also expects that the available replicas running (`.spec.availableReplicas`) will be at least the minimum required +based on the Deployment strategy. If the rollout is still in progress, it watches for Deployment status changes and +prints related messages. ```shell -$ kubectl get deployments -NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE -nginx-deployment 3 3 3 3 20s +$ kubectl rollout status deployment/nginx-deployment +Waiting for rollout to finish: 2 out of 10 new replicas have been updated... +Waiting for rollout to finish: 2 out of 10 new replicas have been updated... +Waiting for rollout to finish: 2 out of 10 new replicas have been updated... +Waiting for rollout to finish: 3 out of 10 new replicas have been updated... +Waiting for rollout to finish: 3 out of 10 new replicas have been updated... +Waiting for rollout to finish: 4 out of 10 new replicas have been updated... +Waiting for rollout to finish: 4 out of 10 new replicas have been updated... +Waiting for rollout to finish: 4 out of 10 new replicas have been updated... +Waiting for rollout to finish: 4 out of 10 new replicas have been updated... +Waiting for rollout to finish: 4 out of 10 new replicas have been updated... +Waiting for rollout to finish: 5 out of 10 new replicas have been updated... +Waiting for rollout to finish: 5 out of 10 new replicas have been updated... +Waiting for rollout to finish: 5 out of 10 new replicas have been updated... +Waiting for rollout to finish: 5 out of 10 new replicas have been updated... +Waiting for rollout to finish: 6 out of 10 new replicas have been updated... +Waiting for rollout to finish: 6 out of 10 new replicas have been updated... +Waiting for rollout to finish: 6 out of 10 new replicas have been updated... +Waiting for rollout to finish: 6 out of 10 new replicas have been updated... +Waiting for rollout to finish: 6 out of 10 new replicas have been updated... +Waiting for rollout to finish: 7 out of 10 new replicas have been updated... +Waiting for rollout to finish: 7 out of 10 new replicas have been updated... +Waiting for rollout to finish: 7 out of 10 new replicas have been updated... +Waiting for rollout to finish: 7 out of 10 new replicas have been updated... +Waiting for rollout to finish: 8 out of 10 new replicas have been updated... +Waiting for rollout to finish: 8 out of 10 new replicas have been updated... +Waiting for rollout to finish: 8 out of 10 new replicas have been updated... +Waiting for rollout to finish: 9 out of 10 new replicas have been updated... +Waiting for rollout to finish: 9 out of 10 new replicas have been updated... +Waiting for rollout to finish: 9 out of 10 new replicas have been updated... +Waiting for rollout to finish: 1 old replicas are pending termination... +Waiting for rollout to finish: 1 old replicas are pending termination... +Waiting for rollout to finish: 1 old replicas are pending termination... +Waiting for rollout to finish: 9 of 10 updated replicas are available... +deployment "nginx-deployment" successfully rolled out ``` +For more information about the status of a Deployment [read more here](#deployment-status). + + ## Updating a Deployment **Note:** a Deployment's rollout is triggered if and only if the Deployment's pod template (i.e. `.spec.template`) is changed, @@ -129,7 +161,7 @@ To see its rollout status, simply 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 "nginx-deployment" successfully rolled out ``` After the rollout succeeds, you may want to `get` the Deployment: @@ -244,12 +276,12 @@ deployment "nginx-deployment" image updated The rollout will be stuck. -``` +```shell $ kubectl rollout status deployments nginx-deployment Waiting for rollout to finish: 2 out of 3 new replicas have been updated... ``` -Press Ctrl-C to stop the above rollout status watch. +Press Ctrl-C to stop the above rollout status watch. For more information on stuck rollouts, [read more here](#deployment-status). You will also see that both the number of old replicas (nginx-deployment-1564180365 and nginx-deployment-2035384211) and new replicas (nginx-deployment-3066724191) are 2. @@ -549,7 +581,7 @@ updates you've requested have been completed. You can check if a Deployment has completed by using `kubectl rollout status`. If the rollout completed successfully, `kubectl rollout status` returns a zero exit code. -``` +```shell $ kubectl rollout status deploy/nginx Waiting for rollout to finish: 2 of 3 updated replicas are available... deployment "nginx" successfully rolled out @@ -594,7 +626,7 @@ You may experience transient errors with your Deployments, either due to a low t of error that can be treated as transient. For example, let's suppose you have insufficient quota. If you describe the Deployment you will notice the following section: -``` +```shell $ kubectl describe deployment nginx-deployment <...> Conditions: @@ -667,7 +699,7 @@ required new replicas are available (see the Reason of the condition for the par You can check if a Deployment has failed to progress by using `kubectl rollout status`. `kubectl rollout status` returns a non-zero exit code if the Deployment has exceeded the progression deadline. -``` +```shell $ kubectl rollout status deploy/nginx Waiting for rollout to finish: 2 out of 3 new replicas have been updated... error: deployment "nginx" exceeded its progress deadline From 4c4959e63123fc9653529f6d8df21f8ef56606d5 Mon Sep 17 00:00:00 2001 From: Alejandro Escobar Date: Mon, 12 Dec 2016 08:57:29 -0800 Subject: [PATCH 24/68] changes to node.md for clarity since sections and subsections visually are that different in sizes and single line comment was not clear enough and looked incomplete, specially at first read. Added .idea/ directory in gitignore. removed change to .gitignore and pushing to a separate pr. suggested changes made. --- docs/admin/node.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/docs/admin/node.md b/docs/admin/node.md index a18aaf5ca7..d9d498ba0d 100644 --- a/docs/admin/node.md +++ b/docs/admin/node.md @@ -20,7 +20,15 @@ architecture design doc for more details. ## Node Status -A node's status is comprised of the following information. +A node's status contains the following information: + +* [Addresses](#Addresses) +* ~~[Phase](#Phase)~~ **deprecated** +* [Condition](#Condition) +* [Capacity](#Capacity) +* [Info](#Info) + +Each section is described in detail below. ### Addresses From 547a6d7b2ad839e8fe833ee5fef2e60fb4184154 Mon Sep 17 00:00:00 2001 From: Taylor Thomas Date: Tue, 29 Nov 2016 14:29:44 -0800 Subject: [PATCH 25/68] Clarifies lifecycle hook documentation --- docs/user-guide/container-environment.md | 25 ++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/docs/user-guide/container-environment.md b/docs/user-guide/container-environment.md index f3996b2eb5..cf8cb037f7 100644 --- a/docs/user-guide/container-environment.md +++ b/docs/user-guide/container-environment.md @@ -60,7 +60,9 @@ This hook is called immediately before a container is terminated. No parameters ### Hook Handler Execution -When a management hook occurs, the management system calls into any registered hook handlers in the container for that hook.  These hook handler calls are synchronous in the context of the pod containing the container. Typically we expect that users will make their hook handlers as lightweight as possible, but there are cases where long running commands make sense (e.g. saving state prior to container stop). +When a management hook occurs, the management system calls into any registered hook handlers in the container for that hook.  These hook handler calls are synchronous in the context of the pod containing the container. This means that for a `PostStart` hook, the container entrypoint and hook will fire asynchronously. However, if the hook takes a while to run or hangs, the container will never reach a "running" state. The behavior is similar for a `PreStop` hook. If the hook hangs during execution, the Pod phase will stay in a "running" state and never reach "failed." If a `PostStart` or `PreStop` hook fails, it will kill the container. + +Typically we expect that users will make their hook handlers as lightweight as possible, but there are cases where long running commands make sense (e.g. saving state prior to container stop). ### Hook delivery guarantees @@ -81,4 +83,23 @@ Hook handlers are the way that hooks are surfaced to containers.  Containers ca * HTTP - Executes an HTTP request against a specific endpoint on the container. -[1]: http://man7.org/linux/man-pages/man2/gethostname.2.html \ No newline at end of file +[1]: http://man7.org/linux/man-pages/man2/gethostname.2.html + +### Debugging Hook Handlers + +Currently, the logs for a hook handler are not exposed in the pod events. If your handler fails for some reason, it will emit an event. For `PostStart`, this is the `FailedPostStartHook` event. For `PreStop` this is the `FailedPreStopHook` event. You can see these events by running `kubectl describe pod `. An example output of events from runing this command is below: + +``` +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0" + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined] + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0" + 1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567 + 38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1 + 37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1 + 38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1" + 1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook +``` \ No newline at end of file From 0f96b1ed77d27a875b61b026edadfad0bc94ce8a Mon Sep 17 00:00:00 2001 From: Alejandro Escobar Date: Thu, 22 Dec 2016 10:05:00 -0800 Subject: [PATCH 26/68] fixed server.cert text to server.crt which is consistent with the rest of the document. --- docs/admin/authentication.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/admin/authentication.md b/docs/admin/authentication.md index 3ada61a5fd..4bbd0a4fee 100644 --- a/docs/admin/authentication.md +++ b/docs/admin/authentication.md @@ -444,7 +444,7 @@ The script will generate three files: `ca.crt`, `server.crt`, and `server.key`. Finally, add the following parameters into API server start parameters: - `--client-ca-file=/srv/kubernetes/ca.crt` -- `--tls-cert-file=/srv/kubernetes/server.cert` +- `--tls-cert-file=/srv/kubernetes/server.crt` - `--tls-private-key-file=/srv/kubernetes/server.key` #### easyrsa @@ -468,7 +468,7 @@ Finally, add the following parameters into API server start parameters: 1. Fill in and add the following parameters into the API server start parameters: --client-ca-file=/yourdirectory/ca.crt - --tls-cert-file=/yourdirectory/server.cert + --tls-cert-file=/yourdirectory/server.crt --tls-private-key-file=/yourdirectory/server.key #### openssl From f9d1cbc8fa00b01fbc35e843d3e5d89e402a96fa Mon Sep 17 00:00:00 2001 From: "Elijah C. Voigt" Date: Fri, 16 Dec 2016 15:51:48 -0800 Subject: [PATCH 27/68] Remove italics, correct CamelCase typos in titles --- docs/admin/daemons.md | 29 +++-- docs/admin/sysctls.md | 2 +- docs/user-guide/cron-jobs.md | 2 +- docs/user-guide/jobs.md | 2 +- docs/user-guide/pod-security-policy/index.md | 2 +- docs/user-guide/pods/index.md | 2 +- docs/user-guide/replicasets.md | 38 +++--- .../replication-controller/index.md | 108 +++++++++--------- 8 files changed, 92 insertions(+), 93 deletions(-) diff --git a/docs/admin/daemons.md b/docs/admin/daemons.md index 90637239b3..819636ba99 100644 --- a/docs/admin/daemons.md +++ b/docs/admin/daemons.md @@ -7,20 +7,20 @@ title: Daemon Sets * TOC {:toc} -## What is a Daemon Set? +## What is a DaemonSet? -A _Daemon Set_ ensures that all (or some) nodes run a copy of a pod. As nodes are added to the +A _DaemonSet_ ensures that all (or some) nodes run a copy of a pod. As nodes are added to the cluster, pods are added to them. As nodes are removed from the cluster, those pods are garbage -collected. Deleting a Daemon Set will clean up the pods it created. +collected. Deleting a DaemonSet will clean up the pods it created. -Some typical uses of a Daemon Set are: +Some typical uses of a DaemonSet are: - running a cluster storage daemon, such as `glusterd`, `ceph`, on each node. - running a logs collection daemon on every node, such as `fluentd` or `logstash`. - running a node monitoring daemon on every node, such as [Prometheus Node Exporter]( https://github.com/prometheus/node_exporter), `collectd`, New Relic agent, or Ganglia `gmond`. -In a simple case, one Daemon Set, covering all nodes, would be used for each type of daemon. +In a simple case, one DaemonSet, covering all nodes, would be used for each type of daemon. A more complex setup might use multiple DaemonSets would be used for a single type of daemon, but with different flags and/or different memory and cpu requests for different hardware types. @@ -74,7 +74,7 @@ a node for testing. If you specify a `.spec.template.spec.nodeSelector`, then the DaemonSet controller will create pods on nodes which match that [node -selector](/docs/user-guide/node-selection/). +selector](/docs/user-guide/node-selection/). If you specify a `scheduler.alpha.kubernetes.io/affinity` annotation in `.spec.template.metadata.annotations`, then DaemonSet controller will create pods on nodes which match that [node affinity](../../user-guide/node-selection/#alpha-feature-in-kubernetes-v12-node-affinity). @@ -88,18 +88,17 @@ created by the Daemon controller have the machine already selected (`.spec.nodeN when the pod is created, so it is ignored by the scheduler). Therefore: - the [`unschedulable`](/docs/admin/node/#manual-node-administration) field of a node is not respected - by the daemon set controller. - - daemon set controller can make pods even when the scheduler has not been started, which can help cluster + by the DaemonSet controller. + - DaemonSet controller can make pods even when the scheduler has not been started, which can help cluster bootstrap. ## Communicating with DaemonSet Pods Some possible patterns for communicating with pods in a DaemonSet are: -- **Push**: Pods in the Daemon Set are configured to send updates to another service, such +- **Push**: Pods in the DaemonSet are configured to send updates to another service, such as a stats database. They do not have clients. -- **NodeIP and Known Port**: Pods in the Daemon Set use a `hostPort`, so that the pods are reachable - via the node IPs. Clients knows the list of nodes ips somehow, and know the port by convention. +- **NodeIP and Known Port**: Pods in the DaemonSet use a `hostPort`, so that the pods are reachable via the node IPs. Clients know the list of nodes ips somehow, and know the port by convention. - **DNS**: Create a [headless service](/docs/user-guide/services/#headless-services) with the same pod selector, and then discover DaemonSets using the `endpoints` resource or retrieve multiple A records from DNS. @@ -126,7 +125,7 @@ You cannot update a DaemonSet. Support for updating DaemonSets and controlled updating of nodes is planned. -## Alternatives to Daemon Set +## Alternatives to DaemonSet ### Init Scripts @@ -145,9 +144,9 @@ running such processes via a DaemonSet: ### Bare Pods It is possible to create pods directly which specify a particular node to run on. However, -a Daemon Set replaces pods that are deleted or terminated for any reason, such as in the case of +a DaemonSet replaces pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, you should -use a Daemon Set rather than creating individual pods. +use a DaemonSet rather than creating individual pods. ### Static Pods @@ -159,7 +158,7 @@ in cluster bootstrapping cases. Also, static pods may be deprecated in the futu ### Replication Controller -Daemon Set are similar to [Replication Controllers](/docs/user-guide/replication-controller) in that +DaemonSet are similar to [Replication Controllers](/docs/user-guide/replication-controller) in that they both create pods, and those pods have processes which are not expected to terminate (e.g. web servers, storage servers). diff --git a/docs/admin/sysctls.md b/docs/admin/sysctls.md index dc62b8c3d1..ff6829850e 100644 --- a/docs/admin/sysctls.md +++ b/docs/admin/sysctls.md @@ -9,7 +9,7 @@ assignees: This document describes how sysctls are used within a Kubernetes cluster. -## What is a _Sysctl_? +## What is a Sysctl? In Linux, the sysctl interface allows an administrator to modify kernel parameters at runtime. Parameters are available via the `/proc/sys/` virtual diff --git a/docs/user-guide/cron-jobs.md b/docs/user-guide/cron-jobs.md index 9124852a80..55b85adf46 100644 --- a/docs/user-guide/cron-jobs.md +++ b/docs/user-guide/cron-jobs.md @@ -9,7 +9,7 @@ title: Cron Jobs * TOC {:toc} -## What is a Cron Job? +## What is a cron job? A _Cron Job_ manages time based [Jobs](/docs/user-guide/jobs/), namely: diff --git a/docs/user-guide/jobs.md b/docs/user-guide/jobs.md index 0d71bc5e56..f5b7362039 100644 --- a/docs/user-guide/jobs.md +++ b/docs/user-guide/jobs.md @@ -8,7 +8,7 @@ title: Jobs * TOC {:toc} -## What is a job? +## What is a Job? A _job_ creates one or more pods and ensures that a specified number of them successfully terminate. As pods successfully complete, the _job_ tracks the successful completions. When a specified number diff --git a/docs/user-guide/pod-security-policy/index.md b/docs/user-guide/pod-security-policy/index.md index c2de42162c..46db299311 100644 --- a/docs/user-guide/pod-security-policy/index.md +++ b/docs/user-guide/pod-security-policy/index.md @@ -6,7 +6,7 @@ title: Pod Security Policies Objects of type `podsecuritypolicy` govern the ability to make requests on a pod that affect the `SecurityContext` that will be -applied to a pod and container. +applied to a pod and container. See [PodSecurityPolicy proposal](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/proposals/security-context-constraints.md) for more information. diff --git a/docs/user-guide/pods/index.md b/docs/user-guide/pods/index.md index b18ae485e3..6bea334dec 100644 --- a/docs/user-guide/pods/index.md +++ b/docs/user-guide/pods/index.md @@ -10,7 +10,7 @@ title: Pods _pods_ are the smallest deployable units of computing that can be created and managed in Kubernetes. -## What is a pod? +## What is a Pod? A _pod_ (as in a pod of whales or pea pod) is a group of one or more containers (such as Docker containers), the shared storage for those containers, and diff --git a/docs/user-guide/replicasets.md b/docs/user-guide/replicasets.md index f0aa08bf04..ea3e7bde14 100644 --- a/docs/user-guide/replicasets.md +++ b/docs/user-guide/replicasets.md @@ -9,17 +9,17 @@ title: Replica Sets * TOC {:toc} -## What is a Replica Set? +## What is a ReplicaSet? -Replica Set is the next-generation Replication Controller. The only difference -between a _Replica Set_ and a +ReplicaSet is the next-generation Replication Controller. The only difference +between a _ReplicaSet_ and a [_Replication Controller_](/docs/user-guide/replication-controller/) right now is -the selector support. Replica Set supports the new set-based selector requirements +the selector support. ReplicaSet supports the new set-based selector requirements as described in the [labels user guide](/docs/user-guide/labels/#label-selectors) whereas a Replication Controller only supports equality-based selector requirements. Most [`kubectl`](/docs/user-guide/kubectl/) commands that support -Replication Controllers also support Replica Sets. One exception is the +Replication Controllers also support ReplicaSets. One exception is the [`rolling-update`](/docs/user-guide/kubectl/kubectl_rolling-update/) command. If you want the rolling update functionality please consider using Deployments instead. Also, the @@ -27,21 +27,21 @@ instead. Also, the imperative whereas Deployments are declarative, so we recommend using Deployments through the [`rollout`](/docs/user-guide/kubectl/kubectl_rollout/) command. -While Replica Sets can be used independently, today it's mainly used by +While ReplicaSets can be used independently, today it's mainly used by [Deployments](/docs/user-guide/deployments/) as a mechanism to orchestrate pod creation, deletion and updates. When you use Deployments you don't have to worry -about managing the Replica Sets that they create. Deployments own and manage -their Replica Sets. +about managing the ReplicaSets that they create. Deployments own and manage +their ReplicaSets. -## When to use a Replica Set? +## When to use a ReplicaSet? -A Replica Set ensures that a specified number of pod “replicas” are running at any given -time. However, a Deployment is a higher-level concept that manages Replica Sets and +A ReplicaSet ensures that a specified number of pod “replicas” are running at any given +time. However, a Deployment is a higher-level concept that manages ReplicaSets and provides declarative updates to pods along with a lot of other useful features. -Therefore, we recommend using Deployments instead of directly using Replica Sets, unless +Therefore, we recommend using Deployments instead of directly using ReplicaSets, unless you require custom update orchestration or don't require updates at all. -This actually means that you may never need to manipulate Replica Set objects: +This actually means that you may never need to manipulate ReplicaSet objects: use directly a Deployment and define your application in the spec section. ## Example @@ -49,7 +49,7 @@ use directly a Deployment and define your application in the spec section. {% include code.html language="yaml" file="replicasets/frontend.yaml" ghlink="/docs/user-guide/replicasets/frontend.yaml" %} Saving this config into `frontend.yaml` and submitting it to a Kubernetes cluster should -create the defined Replica Set and the pods that it manages. +create the defined ReplicaSet and the pods that it manages. ```shell $ kubectl create -f frontend.yaml @@ -76,18 +76,18 @@ frontend-dnjpy 1/1 Running 0 1m frontend-qhloh 1/1 Running 0 1m ``` -## Replica Set as an Horizontal Pod Autoscaler target +## ReplicaSet as an Horizontal Pod Autoscaler target -A Replica Set can also be a target for +A ReplicaSet can also be a target for [Horizontal Pod Autoscalers (HPA)](/docs/user-guide/horizontal-pod-autoscaling/), -i.e. a Replica Set can be auto-scaled by an HPA. Here is an example HPA targeting -the Replica Set we created in the previous example. +i.e. a ReplicaSet can be auto-scaled by an HPA. Here is an example HPA targeting +the ReplicaSet we created in the previous example. {% include code.html language="yaml" file="replicasets/hpa-rs.yaml" ghlink="/docs/user-guide/replicasets/hpa-rs.yaml" %} Saving this config into `hpa-rs.yaml` and submitting it to a Kubernetes cluster should -create the defined HPA that autoscales the target Replica Set depending on the CPU usage +create the defined HPA that autoscales the target ReplicaSet depending on the CPU usage of the replicated pods. ```shell diff --git a/docs/user-guide/replication-controller/index.md b/docs/user-guide/replication-controller/index.md index e69c55231b..3b91828535 100644 --- a/docs/user-guide/replication-controller/index.md +++ b/docs/user-guide/replication-controller/index.md @@ -8,30 +8,30 @@ title: Replication Controller * TOC {:toc} -## What is a replication controller? +## What is a ReplicationController? -A _replication controller_ ensures that a specified number of pod "replicas" are running at any one -time. In other words, a replication controller makes sure that a pod or homogeneous set of pods are +A _ReplicationController_ ensures that a specified number of pod "replicas" are running at any one +time. In other words, a ReplicationController makes sure that a pod or homogeneous set of pods are always up and available. If there are too many pods, it will kill some. If there are too few, the -replication controller will start more. Unlike manually created pods, the pods maintained by a -replication controller are automatically replaced if they fail, get deleted, or are terminated. +ReplicationController will start more. Unlike manually created pods, the pods maintained by a +ReplicationController are automatically replaced if they fail, get deleted, or are terminated. For example, your pods get re-created on a node after disruptive maintenance such as a kernel upgrade. -For this reason, we recommend that you use a replication controller even if your application requires -only a single pod. You can think of a replication controller as something similar to a process supervisor, -but rather than individual processes on a single node, the replication controller supervises multiple pods +For this reason, we recommend that you use a ReplicationController even if your application requires +only a single pod. You can think of a ReplicationController as something similar to a process supervisor, +but rather than individual processes on a single node, the ReplicationController supervises multiple pods across multiple nodes. -Replication Controller is often abbreviated to "rc" or "rcs" in discussion, and as a shortcut in +ReplicationController is often abbreviated to "rc" or "rcs" in discussion, and as a shortcut in kubectl commands. -A simple case is to create 1 Replication Controller object in order to reliably run one instance of +A simple case is to create 1 ReplicationController object in order to reliably run one instance of a Pod indefinitely. A more complex use case is to run several identical replicas of a replicated service, such as web servers. -## Running an example Replication Controller +## Running an example ReplicationController -Here is an example Replication Controller config. It runs 3 copies of the nginx web server. +Here is an example ReplicationController config. It runs 3 copies of the nginx web server. {% include code.html language="yaml" file="replication.yaml" ghlink="/docs/user-guide/replication.yaml" %} @@ -42,7 +42,7 @@ $ kubectl create -f ./replication.yaml replicationcontrollers/nginx ``` -Check on the status of the replication controller using this command: +Check on the status of the ReplicationController using this command: ```shell $ kubectl describe replicationcontrollers/nginx @@ -79,18 +79,18 @@ echo $pods nginx-3ntk0 nginx-4ok8v nginx-qrm3m ``` -Here, the selector is the same as the selector for the replication controller (seen in the +Here, the selector is the same as the selector for the ReplicationController (seen in the `kubectl describe` output, and in a different form in `replication.yaml`. The `--output=jsonpath` option specifies an expression that just gets the name from each pod in the returned list. -## Writing a Replication Controller Spec +## Writing a ReplicationController Spec As with all other Kubernetes config, a Job needs `apiVersion`, `kind`, and `metadata` fields. For general information about working with config files, see [here](/docs/user-guide/simple-yaml/), [here](/docs/user-guide/configuring-containers/), and [here](/docs/user-guide/working-with-resources/). -A Replication Controller also needs a [`.spec` section](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status). +A ReplicationController also needs a [`.spec` section](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status). ### Pod Template @@ -100,28 +100,28 @@ The `.spec.template` is a [pod template](#pod-template). It has exactly the same schema as a [pod](/docs/user-guide/pods/), except it is nested and does not have an `apiVersion` or `kind`. -In addition to required fields for a Pod, a pod template in a Replication Controller must specify appropriate +In addition to required fields for a Pod, a pod template in a ReplicationController must specify appropriate labels (i.e. don't overlap with other controllers, see [pod selector](#pod-selector)) and an appropriate restart policy. Only a [`.spec.template.spec.restartPolicy`](/docs/user-guide/pod-states/) equal to `Always` is allowed, which is the default if not specified. -For local container restarts, replication controllers delegate to an agent on the node, +For local container restarts, ReplicationControllers delegate to an agent on the node, for example the [Kubelet](/docs/admin/kubelet/) or Docker. -### Labels on the Replication Controller +### Labels on the ReplicationController -The replication controller can itself have labels (`.metadata.labels`). Typically, you +The ReplicationController can itself have labels (`.metadata.labels`). Typically, you would set these the same as the `.spec.template.metadata.labels`; if `.metadata.labels` is not specified then it is defaulted to `.spec.template.metadata.labels`. However, they are allowed to be -different, and the `.metadata.labels` do not affect the behavior of the replication controller. +different, and the `.metadata.labels` do not affect the behavior of the ReplicationController. ### Pod Selector The `.spec.selector` field is a [label selector](/docs/user-guide/labels/#label-selectors). A replication controller manages all the pods with labels which match the selector. It does not distinguish between pods which it created or deleted versus pods which some other person or process created or -deleted. This allows the replication controller to be replaced without affecting the running pods. +deleted. This allows the ReplicationController to be replaced without affecting the running pods. If specified, the `.spec.template.metadata.labels` must be equal to the `.spec.selector`, or it will be rejected by the API. If `.spec.selector` is unspecified, it will be defaulted to @@ -144,54 +144,54 @@ shutdown, and a replacement starts early. If you do not specify `.spec.replicas`, then it defaults to 1. -## Working with Replication Controllers +## Working with ReplicationControllers -### Deleting a Replication Controller and its Pods +### Deleting a ReplicationController and its Pods -To delete a replication controller and all its pods, use [`kubectl -delete`](/docs/user-guide/kubectl/kubectl_delete/). Kubectl will scale the replication controller to zero and wait -for it to delete each pod before deleting the replication controller itself. If this kubectl +To delete a ReplicationController and all its pods, use [`kubectl +delete`](/docs/user-guide/kubectl/kubectl_delete/). Kubectl will scale the ReplicationController to zero and wait +for it to delete each pod before deleting the ReplicationController itself. If this kubectl command is interrupted, it can be restarted. 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 replication controller). +0, wait for pod deletions, then delete the ReplicationController). -### Deleting just a Replication Controller +### Deleting just a ReplicationController -You can delete a replication controller without affecting any of its pods. +You can delete a ReplicationController without affecting any of its pods. Using kubectl, specify the `--cascade=false` option to [`kubectl delete`](/docs/user-guide/kubectl/kubectl_delete/). -When using the REST API or go client library, simply delete the replication controller object. +When using the REST API or go client library, simply delete the ReplicationController object. -Once the original is deleted, you can create a new replication controller to replace it. As long +Once the original is deleted, you can create a new ReplicationController to replace it. As long as the old and new `.spec.selector` are the same, then the new one will adopt the old pods. However, it will not make any effort to make existing pods match a new, different pod template. To update pods to a new spec in a controlled way, use a [rolling update](#rolling-updates). -### Isolating pods from a Replication Controller +### Isolating pods from a ReplicationController -Pods may be removed from a replication controller's target set by changing their labels. This technique may be used to remove pods from service for debugging, data recovery, etc. Pods that are removed in this way will be replaced automatically (assuming that the number of replicas is not also changed). +Pods may be removed from a ReplicationController's target set by changing their labels. This technique may be used to remove pods from service for debugging, data recovery, etc. Pods that are removed in this way will be replaced automatically (assuming that the number of replicas is not also changed). ## Common usage patterns ### Rescheduling -As mentioned above, whether you have 1 pod you want to keep running, or 1000, a replication controller will ensure that the specified number of pods exists, even in the event of node failure or pod termination (e.g., due to an action by another control agent). +As mentioned above, whether you have 1 pod you want to keep running, or 1000, a ReplicationController will ensure that the specified number of pods exists, even in the event of node failure or pod termination (e.g., due to an action by another control agent). ### Scaling -The replication controller makes it easy to scale the number of replicas up or down, either manually or by an auto-scaling control agent, by simply updating the `replicas` field. +The ReplicationController makes it easy to scale the number of replicas up or down, either manually or by an auto-scaling control agent, by simply updating the `replicas` field. ### Rolling updates -The replication controller is designed to facilitate rolling updates to a service by replacing pods one-by-one. +The ReplicationController is designed to facilitate rolling updates to a service by replacing pods one-by-one. -As explained in [#1353](http://issue.k8s.io/1353), the recommended approach is to create a new replication controller with 1 replica, scale the new (+1) and old (-1) controllers one by one, and then delete the old controller after it reaches 0 replicas. This predictably updates the set of pods regardless of unexpected failures. +As explained in [#1353](http://issue.k8s.io/1353), the recommended approach is to create a new ReplicationController with 1 replica, scale the new (+1) and old (-1) controllers one by one, and then delete the old controller after it reaches 0 replicas. This predictably updates the set of pods regardless of unexpected failures. Ideally, the rolling update controller would take application readiness into account, and would ensure that a sufficient number of pods were productively serving at any given time. -The two replication controllers would need to create pods with at least one differentiating label, such as the image tag of the primary container of the pod, since it is typically image updates that motivate rolling updates. +The two ReplicationControllers would need to create pods with at least one differentiating label, such as the image tag of the primary container of the pod, since it is typically image updates that motivate rolling updates. Rolling update is implemented in the client tool [`kubectl rolling-update`](/docs/user-guide/kubectl/kubectl_rolling-update). Visit [`kubectl rolling-update` tutorial](/docs/user-guide/rolling-updates/) for more concrete examples. @@ -200,26 +200,26 @@ Rolling update is implemented in the client tool In addition to running multiple releases of an application while a rolling update is in progress, it's common to run multiple releases for an extended period of time, or even continuously, using multiple release tracks. The tracks would be differentiated by labels. -For instance, a service might target all pods with `tier in (frontend), environment in (prod)`. Now say you have 10 replicated pods that make up this tier. But you want to be able to 'canary' a new version of this component. You could set up a replication controller with `replicas` set to 9 for the bulk of the replicas, with labels `tier=frontend, environment=prod, track=stable`, and another replication controller with `replicas` set to 1 for the canary, with labels `tier=frontend, environment=prod, track=canary`. Now the service is covering both the canary and non-canary pods. But you can mess with the replication controllers separately to test things out, monitor the results, etc. +For instance, a service might target all pods with `tier in (frontend), environment in (prod)`. Now say you have 10 replicated pods that make up this tier. But you want to be able to 'canary' a new version of this component. You could set up a ReplicationController with `replicas` set to 9 for the bulk of the replicas, with labels `tier=frontend, environment=prod, track=stable`, and another ReplicationController with `replicas` set to 1 for the canary, with labels `tier=frontend, environment=prod, track=canary`. Now the service is covering both the canary and non-canary pods. But you can mess with the ReplicationControllers separately to test things out, monitor the results, etc. -### Using Replication Controllers with Services +### Using ReplicationControllers with Services -Multiple replication controllers can sit behind a single service, so that, for example, some traffic +Multiple ReplicationControllers can sit behind a single service, so that, for example, some traffic goes to the old version, and some goes to the new version. -A replication controller will never terminate on its own, but it isn't expected to be as long-lived as services. Services may be composed of pods controlled by multiple replication controllers, and it is expected that many replication controllers may be created and destroyed over the lifetime of a service (for instance, to perform an update of pods that run the service). Both services themselves and their clients should remain oblivious to the replication controllers that maintain the pods of the services. +A ReplicationController will never terminate on its own, but it isn't expected to be as long-lived as services. Services may be composed of pods controlled by multiple ReplicationControllers, and it is expected that many ReplicationControllers may be created and destroyed over the lifetime of a service (for instance, to perform an update of pods that run the service). Both services themselves and their clients should remain oblivious to the ReplicationControllers that maintain the pods of the services. ## Writing programs for Replication -Pods created by a replication controller are intended to be fungible and semantically identical, though their configurations may become heterogeneous over time. This is an obvious fit for replicated stateless servers, but replication controllers can also be used to maintain availability of master-elected, sharded, and worker-pool applications. Such applications should use dynamic work assignment mechanisms, such as the [etcd lock module](https://coreos.com/docs/distributed-configuration/etcd-modules/) or [RabbitMQ work queues](https://www.rabbitmq.com/tutorials/tutorial-two-python.html), as opposed to static/one-time customization of the configuration of each pod, which is considered an anti-pattern. Any pod customization performed, such as vertical auto-sizing of resources (e.g., cpu or memory), should be performed by another online controller process, not unlike the replication controller itself. +Pods created by a ReplicationController are intended to be fungible and semantically identical, though their configurations may become heterogeneous over time. This is an obvious fit for replicated stateless servers, but ReplicationControllers can also be used to maintain availability of master-elected, sharded, and worker-pool applications. Such applications should use dynamic work assignment mechanisms, such as the [etcd lock module](https://coreos.com/docs/distributed-configuration/etcd-modules/) or [RabbitMQ work queues](https://www.rabbitmq.com/tutorials/tutorial-two-python.html), as opposed to static/one-time customization of the configuration of each pod, which is considered an anti-pattern. Any pod customization performed, such as vertical auto-sizing of resources (e.g., cpu or memory), should be performed by another online controller process, not unlike the ReplicationController itself. -## Responsibilities of the replication controller +## Responsibilities of the ReplicationController -The replication controller simply ensures that the desired number of pods matches its label selector and are operational. Currently, only terminated pods are excluded from its count. In the future, [readiness](http://issue.k8s.io/620) and other information available from the system may be taken into account, we may add more controls over the replacement policy, and we plan to emit events that could be used by external clients to implement arbitrarily sophisticated replacement and/or scale-down policies. +The ReplicationController simply ensures that the desired number of pods matches its label selector and are operational. Currently, only terminated pods are excluded from its count. In the future, [readiness](http://issue.k8s.io/620) and other information available from the system may be taken into account, we may add more controls over the replacement policy, and we plan to emit events that could be used by external clients to implement arbitrarily sophisticated replacement and/or scale-down policies. -The replication controller is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in [#492](http://issue.k8s.io/492)), which would change its `replicas` field. We will not add scheduling policies (e.g., [spreading](http://issue.k8s.io/367#issuecomment-48428019)) to the replication controller. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsewhere. We even plan to factor out the mechanism for bulk pod creation ([#170](http://issue.k8s.io/170)). +The ReplicationController is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in [#492](http://issue.k8s.io/492)), which would change its `replicas` field. We will not add scheduling policies (e.g., [spreading](http://issue.k8s.io/367#issuecomment-48428019)) to the ReplicationController. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsewhere. We even plan to factor out the mechanism for bulk pod creation ([#170](http://issue.k8s.io/170)). -The replication controller is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, stop, scale, rolling-update) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing replication controllers, auto-scalers, services, scheduling policies, canaries, etc. +The ReplicationController is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, stop, scale, rolling-update) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing ReplicationControllers, auto-scalers, services, scheduling policies, canaries, etc. ## API Object @@ -228,11 +228,11 @@ Replication controller is a top-level resource in the kubernetes REST API. More API object can be found at: [ReplicationController API object](/docs/api-reference/v1/definitions/#_v1_replicationcontroller). -## Alternatives to Replication Controller +## Alternatives to ReplicationController ### ReplicaSet -[`ReplicaSet`](/docs/user-guide/replicasets/) is the next-generation Replication Controller that supports the new [set-based label selector](/docs/user-guide/labels/#set-based-requirement). +[`ReplicaSet`](/docs/user-guide/replicasets/) is the next-generation ReplicationController that supports the new [set-based label selector](/docs/user-guide/labels/#set-based-requirement). It’s mainly used by [`Deployment`](/docs/user-guide/deployments/) as a mechanism to orchestrate pod creation, deletion and updates. Note that we recommend using Deployments instead of directly using Replica Sets, unless you require custom update orchestration or don’t require updates at all. @@ -244,20 +244,20 @@ because unlike `kubectl rolling-update`, they are declarative, server-side, and ### Bare Pods -Unlike in the case where a user directly created pods, a replication controller replaces pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a replication controller even if your application requires only a single pod. Think of it similarly to a process supervisor, only it supervises multiple pods across multiple nodes instead of individual processes on a single node. A replication controller delegates local container restarts to some agent on the node (e.g., Kubelet or Docker). +Unlike in the case where a user directly created pods, a ReplicationController replaces pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a ReplicationController even if your application requires only a single pod. Think of it similarly to a process supervisor, only it supervises multiple pods across multiple nodes instead of individual processes on a single node. A ReplicationController delegates local container restarts to some agent on the node (e.g., Kubelet or Docker). ### Job -Use a [`Job`](/docs/user-guide/jobs/) instead of a replication controller for pods that are expected to terminate on their own +Use a [`Job`](/docs/user-guide/jobs/) instead of a ReplicationController for pods that are expected to terminate on their own (i.e. batch jobs). ### DaemonSet -Use a [`DaemonSet`](/docs/admin/daemons/) instead of a replication controller for pods that provide a +Use a [`DaemonSet`](/docs/admin/daemons/) instead of a ReplicationController for pods that provide a machine-level function, such as machine monitoring or machine logging. These pods have a lifetime that is tied to a machine lifetime: the pod needs to be running on the machine before other pods start, and are safe to terminate when the machine is otherwise ready to be rebooted/shutdown. ## For more information -Read [Replication Controller Operations](/docs/user-guide/replication-controller/operations/). +Read [ReplicationController Operations](/docs/user-guide/replication-controller/operations/). From fbf57b224f9ba36cd9daeb22577aa65894596cbb Mon Sep 17 00:00:00 2001 From: yanan Lee Date: Thu, 22 Dec 2016 17:14:39 +0800 Subject: [PATCH 28/68] spelling error Signed-off-by: yanan Lee Incorrect spelling Signed-off-by: yanan Lee spelling error Signed-off-by: yanan Lee Incorrect spelling Signed-off-by: yanan Lee Revert "Incorrect spelling" fix some typos Signed-off-by: Jie Luo fix a typo Signed-off-by: Jie Luo fix a typo Signed-off-by: Jie Luo --- docs/admin/accessing-the-api.md | 2 +- docs/admin/authorization.md | 2 +- docs/admin/cluster-management.md | 2 +- docs/admin/dns.md | 2 +- docs/admin/kubeadm.md | 2 +- docs/admin/kubelet-tls-bootstrapping.md | 4 ++-- docs/admin/kubelet.md | 4 ++-- docs/admin/limitrange/index.md | 2 +- docs/admin/out-of-resource.md | 2 +- docs/admin/rescheduler.md | 2 +- docs/getting-started-guides/clc.md | 2 +- docs/getting-started-guides/network-policy/calico.md | 2 +- docs/getting-started-guides/network-policy/weave.md | 2 +- docs/getting-started-guides/ubuntu/automated.md | 2 +- docs/getting-started-guides/ubuntu/manual.md | 2 +- .../load-balance-access-application-cluster.md | 2 +- .../stateless-application/expose-external-ip-address.md | 2 +- docs/user-guide/connecting-applications.md | 2 +- docs/user-guide/deployments.md | 4 ++-- docs/user-guide/jobs.md | 2 +- docs/user-guide/kubectl/kubectl_drain.md | 2 +- docs/user-guide/persistent-volumes/index.md | 2 +- 22 files changed, 25 insertions(+), 25 deletions(-) diff --git a/docs/admin/accessing-the-api.md b/docs/admin/accessing-the-api.md index c8f239969f..5a57db23ce 100644 --- a/docs/admin/accessing-the-api.md +++ b/docs/admin/accessing-the-api.md @@ -24,7 +24,7 @@ following diagram: In a typical Kubernetes cluster, the API served on port 443. A TLS connection is established. The API server presents a certificate. This certificate is often self-signed, so `$USER/.kube/config` on the user's machine typically -contains the root certficate for the API server's certificate, which when specified +contains the root certificate for the API server's certificate, which when specified is used in place of the system default root certificates. This certificate is typically automatically written into your `$USER/.kube/config` when you create a cluster yourself using `kube-up.sh`. If the cluster has multiple users, then the creator needs to share diff --git a/docs/admin/authorization.md b/docs/admin/authorization.md index 523dd256d9..caae123f14 100644 --- a/docs/admin/authorization.md +++ b/docs/admin/authorization.md @@ -330,7 +330,7 @@ roleRef: Finally a `ClusterRoleBinding` may be used to grant permissions in all namespaces. The following `ClusterRoleBinding` allows any user in the group -"manager" to read secrets in any namepsace. +"manager" to read secrets in any namespace. ```yaml # This cluster role binding allows anyone in the "manager" group to read secrets in any namespace. diff --git a/docs/admin/cluster-management.md b/docs/admin/cluster-management.md index b1c4c340a3..eea8b3f228 100644 --- a/docs/admin/cluster-management.md +++ b/docs/admin/cluster-management.md @@ -92,7 +92,7 @@ an extended period of time (10min but it may change in the future). Cluster autoscaler is configured per instance group (GCE) or node pool (GKE). If you are using GCE then you can either enable it while creating a cluster with kube-up.sh script. -To configure cluser autoscaler you have to set 3 environment variables: +To configure cluster autoscaler you have to set 3 environment variables: * `KUBE_ENABLE_CLUSTER_AUTOSCALER` - it enables cluster autoscaler if set to true. * `KUBE_AUTOSCALER_MIN_NODES` - minimum number of nodes in the cluster. diff --git a/docs/admin/dns.md b/docs/admin/dns.md index f9514a50bf..f7536249f4 100644 --- a/docs/admin/dns.md +++ b/docs/admin/dns.md @@ -77,7 +77,7 @@ For example, a pod with ip `1.2.3.4` in the namespace `default` with a DNS name Currently when a pod is created, its hostname is the Pod's `metadata.name` value. With v1.2, users can specify a Pod annotation, `pod.beta.kubernetes.io/hostname`, to specify what the Pod's hostname should be. -The Pod annotation, if specified, takes precendence over the Pod's name, to be the hostname of the pod. +The Pod annotation, if specified, takes precedence over the Pod's name, to be the hostname of the pod. For example, given a Pod with annotation `pod.beta.kubernetes.io/hostname: my-pod-name`, the Pod will have its hostname set to "my-pod-name". With v1.3, the PodSpec has a `hostname` field, which can be used to specify the Pod's hostname. This field value takes precedence over the diff --git a/docs/admin/kubeadm.md b/docs/admin/kubeadm.md index 9ecabe8b7a..71095d0577 100644 --- a/docs/admin/kubeadm.md +++ b/docs/admin/kubeadm.md @@ -242,7 +242,7 @@ Once the cluster is up, you can grab the admin credentials from the master node ## Environment variables There are some environment variables that modify the way that `kubeadm` works. Most users will have no need to set these. -These enviroment variables are a short-term solution, eventually they will be integrated in the kubeadm configuration file. +These environment variables are a short-term solution, eventually they will be integrated in the kubeadm configuration file. | Variable | Default | Description | | --- | --- | --- | diff --git a/docs/admin/kubelet-tls-bootstrapping.md b/docs/admin/kubelet-tls-bootstrapping.md index f8d56923ee..0dfc4bbf55 100644 --- a/docs/admin/kubelet-tls-bootstrapping.md +++ b/docs/admin/kubelet-tls-bootstrapping.md @@ -9,7 +9,7 @@ title: TLS bootstrapping ## Overview -This document describes how to set up TLS client certificate boostrapping for kubelets. +This document describes how to set up TLS client certificate bootstrapping for kubelets. Kubernetes 1.4 introduces an experimental API for requesting certificates from a cluster-level Certificate Authority (CA). The first supported use of this API is the provisioning of TLS client certificates for kubelets. The proposal can be found [here](https://github.com/kubernetes/kubernetes/pull/20439) @@ -17,7 +17,7 @@ and progress on the feature is being tracked as [feature #43](https://github.com ## apiserver configuration -You must provide a token file which specifies at least one "bootstrap token" assigned to a kubelet boostrap-specific group. +You must provide a token file which specifies at least one "bootstrap token" assigned to a kubelet bootstrap-specific group. This group will later be used in the controller-manager configuration to scope approvals in the default approval controller. As this feature matures, you should ensure tokens are bound to an RBAC policy which limits requests using the bootstrap token to only be able to make requests related to certificate provisioning. When RBAC policy diff --git a/docs/admin/kubelet.md b/docs/admin/kubelet.md index 342189ba94..28365fbf97 100644 --- a/docs/admin/kubelet.md +++ b/docs/admin/kubelet.md @@ -78,9 +78,9 @@ kubelet --experimental-allowed-unsafe-sysctls stringSlice Comma-separated whitelist of unsafe sysctls or unsafe sysctl patterns (ending in *). Use these at your own risk. --experimental-bootstrap-kubeconfig string Path to a kubeconfig file that will be used to get client certificate for kubelet. If the file specified by --kubeconfig does not exist, the bootstrap kubeconfig is used to request a client certificate from the API server. On success, a kubeconfig file referencing the generated key and obtained certificate is written to the path specified by --kubeconfig. The certificate and key file will be stored in the directory pointed by --cert-dir. --experimental-cgroups-per-qos Enable creation of QoS cgroup hierarchy, if true top level QoS and pod cgroups are created. - --experimental-check-node-capabilities-before-mount [Experimental] if set true, the kubelet will check the underlying node for required componenets (binaries, etc.) before performing the mount + --experimental-check-node-capabilities-before-mount [Experimental] if set true, the kubelet will check the underlying node for required components (binaries, etc.) before performing the mount --experimental-cri [Experimental] Enable the Container Runtime Interface (CRI) integration. If --container-runtime is set to "remote", Kubelet will communicate with the runtime/image CRI server listening on the endpoint specified by --remote-runtime-endpoint/--remote-image-endpoint. If --container-runtime is set to "docker", Kubelet will launch a in-process CRI server on behalf of docker, and communicate over a default endpoint. - --experimental-fail-swap-on Makes the Kubelet fail to start if swap is enabled on the node. This is a temporary opton to maintain legacy behavior, failing due to swap enabled will happen by default in v1.6. + --experimental-fail-swap-on Makes the Kubelet fail to start if swap is enabled on the node. This is a temporary option to maintain legacy behavior, failing due to swap enabled will happen by default in v1.6. --experimental-kernel-memcg-notification If enabled, the kubelet will integrate with the kernel memcg notification to determine if memory eviction thresholds are crossed rather than polling. --experimental-mounter-path string [Experimental] Path of mounter binary. Leave empty to use the default mount. --experimental-nvidia-gpus int32 Number of NVIDIA GPU devices on this node. Only 0 (default) and 1 are currently supported. diff --git a/docs/admin/limitrange/index.md b/docs/admin/limitrange/index.md index 767513a1a3..2241cbb140 100644 --- a/docs/admin/limitrange/index.md +++ b/docs/admin/limitrange/index.md @@ -184,7 +184,7 @@ Note that this pod specifies explicit resource *limits* and *requests* so it did default values. Note: The *limits* for CPU resource are enforced in the default Kubernetes setup on the physical node -that runs the container unless the administrator deploys the kubelet with the folllowing flag: +that runs the container unless the administrator deploys the kubelet with the following flag: ```shell $ kubelet --help diff --git a/docs/admin/out-of-resource.md b/docs/admin/out-of-resource.md index 0fa6f3942c..30b8744624 100644 --- a/docs/admin/out-of-resource.md +++ b/docs/admin/out-of-resource.md @@ -330,7 +330,7 @@ for eviction. Instead `DaemonSet` should ideally launch `Guaranteed` pods. `kubelet` has been freeing up disk space on demand to keep the node stable. As disk based eviction matures, the following `kubelet` flags will be marked for deprecation -in favor of the simpler configuation supported around eviction. +in favor of the simpler configuration supported around eviction. | Existing Flag | New Flag | | ------------- | -------- | diff --git a/docs/admin/rescheduler.md b/docs/admin/rescheduler.md index c9a3bd074c..27c512bff9 100644 --- a/docs/admin/rescheduler.md +++ b/docs/admin/rescheduler.md @@ -50,7 +50,7 @@ It's enabled by default. It can be disabled: ### Marking add-on as critical -To be critical an add-on has to run in `kube-system` namespace (cofigurable via flag) +To be critical an add-on has to run in `kube-system` namespace (configurable via flag) and have the following annotations specified: * `scheduler.alpha.kubernetes.io/critical-pod` set to empty string diff --git a/docs/getting-started-guides/clc.md b/docs/getting-started-guides/clc.md index ab45ffbf8f..121b6c1030 100644 --- a/docs/getting-started-guides/clc.md +++ b/docs/getting-started-guides/clc.md @@ -207,7 +207,7 @@ Create a cluster with name of k8s_3, 1 master node, and 10 worker minions (on VM ## Cluster Features and Architecture -We configue the Kubernetes cluster with the following features: +We configure the Kubernetes cluster with the following features: * KubeDNS: DNS resolution and service discovery * Heapster/InfluxDB: For metric collection. Needed for Grafana and auto-scaling. diff --git a/docs/getting-started-guides/network-policy/calico.md b/docs/getting-started-guides/network-policy/calico.md index a411fba163..47516756e5 100644 --- a/docs/getting-started-guides/network-policy/calico.md +++ b/docs/getting-started-guides/network-policy/calico.md @@ -31,4 +31,4 @@ There are two main components to be aware of: - One `calico-node` Pod runs on each node in your cluster, and enforces network policy on the traffic to/from Pods on that machine by configuring iptables. - The `calico-policy-controller` Pod reads policy and label information from the Kubernetes API and configures Calico appropriately. -Once your cluster is running, you can follow the [NetworkPolicy gettting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy. +Once your cluster is running, you can follow the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy. diff --git a/docs/getting-started-guides/network-policy/weave.md b/docs/getting-started-guides/network-policy/weave.md index 8d5896861d..8fd1a072d7 100644 --- a/docs/getting-started-guides/network-policy/weave.md +++ b/docs/getting-started-guides/network-policy/weave.md @@ -8,4 +8,4 @@ The [Weave Net Addon](https://www.weave.works/docs/net/latest/kube-addon/) for K This component automatically monitors Kubernetes for any NetworkPolicy annotations on all namespaces, and configures `iptables` rules to allow or block traffic as directed by the policies. -Once you have installed the Weave Net Addon you can follow the [NetworkPolicy gettting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy. +Once you have installed the Weave Net Addon you can follow the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy. diff --git a/docs/getting-started-guides/ubuntu/automated.md b/docs/getting-started-guides/ubuntu/automated.md index 21c25e1c3c..6a1e905bf8 100644 --- a/docs/getting-started-guides/ubuntu/automated.md +++ b/docs/getting-started-guides/ubuntu/automated.md @@ -93,7 +93,7 @@ Note that each controller can host multiple Kubernetes clusters in a given cloud ## Launch a Kubernetes cluster -The following command will deploy the intial 12-node starter cluster. The speed of execution is very dependent of the performance of the cloud you're deploying to, but +The following command will deploy the initial 12-node starter cluster. The speed of execution is very dependent of the performance of the cloud you're deploying to, but ```shell juju deploy canonical-kubernetes diff --git a/docs/getting-started-guides/ubuntu/manual.md b/docs/getting-started-guides/ubuntu/manual.md index e5a849d909..c2566aaf33 100644 --- a/docs/getting-started-guides/ubuntu/manual.md +++ b/docs/getting-started-guides/ubuntu/manual.md @@ -122,7 +122,7 @@ through `FLANNEL_BACKEND` and `FLANNEL_OTHER_NET_CONFIG`, as explained in `clust The default setting for `ADMISSION_CONTROL` is right for the latest release of Kubernetes, but if you choose an earlier release then you might want a different setting. See -[the admisson control doc](http://kubernetes.io/docs/admin/admission-controllers/#is-there-a-recommended-set-of-plug-ins-to-use) +[the admission control doc](http://kubernetes.io/docs/admin/admission-controllers/#is-there-a-recommended-set-of-plug-ins-to-use) for the recommended settings for various releases. **Note:** When deploying, master needs to be connected to the Internet to download the necessary files. diff --git a/docs/tasks/access-application-cluster/load-balance-access-application-cluster.md b/docs/tasks/access-application-cluster/load-balance-access-application-cluster.md index 259988aa15..3fc08562d0 100644 --- a/docs/tasks/access-application-cluster/load-balance-access-application-cluster.md +++ b/docs/tasks/access-application-cluster/load-balance-access-application-cluster.md @@ -52,7 +52,7 @@ load-balanced access to an application running in a cluster. NAME DESIRED CURRENT AGE hello-world-2189936611 2 2 12m -1. Create a Serivice object that exposes the replica set: +1. Create a Service object that exposes the replica set: kubectl expose rs --type="LoadBalancer" --name="example-service" diff --git a/docs/tutorials/stateless-application/expose-external-ip-address.md b/docs/tutorials/stateless-application/expose-external-ip-address.md index 2d2e28d594..f21abf7e61 100644 --- a/docs/tutorials/stateless-application/expose-external-ip-address.md +++ b/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -4,7 +4,7 @@ title: Exposing an External IP Address to Access an Application in a Cluster {% capture overview %} -This page shows how to create a Kubernetes Service object that exposees an +This page shows how to create a Kubernetes Service object that exposes an external IP address. {% endcapture %} diff --git a/docs/user-guide/connecting-applications.md b/docs/user-guide/connecting-applications.md index 95d365bdb1..c0cb825a3b 100644 --- a/docs/user-guide/connecting-applications.md +++ b/docs/user-guide/connecting-applications.md @@ -295,7 +295,7 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el Kubernetes also supports Federated Services, which can span multiple clusters and cloud providers, to provide increased availability, -bettern fault tolerance and greater scalability for your services. See +better fault tolerance and greater scalability for your services. See the [Federated Services User Guide](/docs/user-guide/federation/federated-services/) for further information. diff --git a/docs/user-guide/deployments.md b/docs/user-guide/deployments.md index c53c1e19ae..1de58c8fda 100644 --- a/docs/user-guide/deployments.md +++ b/docs/user-guide/deployments.md @@ -413,7 +413,7 @@ $ kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent= deployment "nginx-deployment" autoscaled ``` -RollingUpdate Deployments support running multitple versions of an application at the same time. When you +RollingUpdate Deployments support running multiple versions of an application at the same time. When you or an autoscaler scales a RollingUpdate Deployment that is in the middle of a rollout (either in progress or paused), then the Deployment controller will balance the additional replicas in the existing active ReplicaSets (ReplicaSets with Pods) in order to mitigate risk. This is called *proportional scaling*. @@ -568,7 +568,7 @@ Your Deployment may get stuck trying to deploy its newest ReplicaSet without eve * Limit ranges * Application runtime misconfiguration -One way you can detect this condition is to specify specify a deadline parameter in your Deployment spec: ([`spec.progressDeadlineSeconds`](#progress-deadline-seconds)). `spec.progressDeadlineSeconds` denotes the number of seconds the Deployment controller waits before indicating (via the Deployment status) that the Deployment progress has stalled. +One way you can detect this condition is to specify a deadline parameter in your Deployment spec: ([`spec.progressDeadlineSeconds`](#progress-deadline-seconds)). `spec.progressDeadlineSeconds` denotes the number of seconds the Deployment controller waits before indicating (via the Deployment status) that the Deployment progress has stalled. The following `kubectl` command sets the spec with `progressDeadlineSeconds` to make the controller report lack of progress for a Deployment after 10 minutes: diff --git a/docs/user-guide/jobs.md b/docs/user-guide/jobs.md index 0d71bc5e56..3d665eaa7f 100644 --- a/docs/user-guide/jobs.md +++ b/docs/user-guide/jobs.md @@ -166,7 +166,7 @@ parallelism, for a variety or reasons: - If the controller failed to create pods for any reason (lack of ResourceQuota, lack of permission, etc.), then there may be fewer pods than requested. - The controller may throttle new pod creation due to excessive previous pod failures in the same Job. -- When a pod is gracefully shutdown, it make take time to stop. +- When a pod is gracefully shutdown, it takes time to stop. ## Handling Pod and Container Failures diff --git a/docs/user-guide/kubectl/kubectl_drain.md b/docs/user-guide/kubectl/kubectl_drain.md index 712af40af7..b6eba48f59 100644 --- a/docs/user-guide/kubectl/kubectl_drain.md +++ b/docs/user-guide/kubectl/kubectl_drain.md @@ -11,7 +11,7 @@ Drain node in preparation for maintenance Drain node in preparation for maintenance. -The given node will be marked unschedulable to prevent new pods from arriving. 'drain' evicts the pods if the APIServer supports eviciton (http://kubernetes.io/docs/admin/disruptions/). Otherwise, it will use normal DELETE to delete the pods. The 'drain' evicts or deletes all pods except mirror pods (which cannot be deleted through the API server). If there are DaemonSet-managed pods, drain will not proceed without --ignore-daemonsets, and regardless it will not delete any DaemonSet-managed pods, because those pods would be immediately replaced by the DaemonSet controller, which ignores unschedulable markings. If there are any pods that are neither mirror pods nor managed by ReplicationController, ReplicaSet, DaemonSet, StatefulSet or Job, then drain will not delete any pods unless you use --force. +The given node will be marked unschedulable to prevent new pods from arriving. 'drain' evicts the pods if the APIServer supports eviction (http://kubernetes.io/docs/admin/disruptions/). Otherwise, it will use normal DELETE to delete the pods. The 'drain' evicts or deletes all pods except mirror pods (which cannot be deleted through the API server). If there are DaemonSet-managed pods, drain will not proceed without --ignore-daemonsets, and regardless it will not delete any DaemonSet-managed pods, because those pods would be immediately replaced by the DaemonSet controller, which ignores unschedulable markings. If there are any pods that are neither mirror pods nor managed by ReplicationController, ReplicaSet, DaemonSet, StatefulSet or Job, then drain will not delete any pods unless you use --force. 'drain' waits for graceful termination. You should not operate on the machine until the command completes. diff --git a/docs/user-guide/persistent-volumes/index.md b/docs/user-guide/persistent-volumes/index.md index 8f9703000c..d16cecd208 100644 --- a/docs/user-guide/persistent-volumes/index.md +++ b/docs/user-guide/persistent-volumes/index.md @@ -497,7 +497,7 @@ parameters: ``` * `quobyteAPIServer`: API Server of Quobyte in the format `http(s)://api-server:7860` -* `registry`: Quobyte registry to use to mount the volume. You can specifiy the registry as ``:`` pair or if you want to specify multiple registries you just have to put a comma between them e.q. ``:,:,:``. The host can be an IP address or if you have a working DNS you can also provide the DNS names. +* `registry`: Quobyte registry to use to mount the volume. You can specify the registry as ``:`` pair or if you want to specify multiple registries you just have to put a comma between them e.q. ``:,:,:``. The host can be an IP address or if you have a working DNS you can also provide the DNS names. * `adminSecretNamespace`: The namespace for `adminSecretName`. Default is "default". * `adminSecretName`: secret that holds information about the Quobyte user and the password to authenticate agains the API server. The provided secret must have type "kubernetes.io/quobyte", e.g. created in this way: ``` From 5c65b700ac8ee74dd796591c199a86dc27db28dc Mon Sep 17 00:00:00 2001 From: Drinky Pool Date: Fri, 23 Dec 2016 10:22:37 +0800 Subject: [PATCH 29/68] add "-l app=nginx" after "kubectl get pods" the original sentence is "kubectl get pods", but maybe "kubectl get pods -l app=nginx" is more accurat in the context. Please check for this. --- .../run-stateless-application-deployment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tutorials/stateless-application/run-stateless-application-deployment.md b/docs/tutorials/stateless-application/run-stateless-application-deployment.md index ce1a713a1c..06ccc74579 100644 --- a/docs/tutorials/stateless-application/run-stateless-application-deployment.md +++ b/docs/tutorials/stateless-application/run-stateless-application-deployment.md @@ -101,7 +101,7 @@ should have four pods: 1. Verify that the Deployment has four pods: - kubectl get pods + kubectl get pods -l app=nginx The output is similar to this: From 5bcc66a16a81078766e1ef94dcd4b1321630a71c Mon Sep 17 00:00:00 2001 From: devin-donnelly Date: Thu, 22 Dec 2016 18:39:52 -0800 Subject: [PATCH 30/68] Update expose-intro.html --- docs/tutorials/kubernetes-basics/expose-intro.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tutorials/kubernetes-basics/expose-intro.html b/docs/tutorials/kubernetes-basics/expose-intro.html index 4e65a16988..cd40b22f8b 100644 --- a/docs/tutorials/kubernetes-basics/expose-intro.html +++ b/docs/tutorials/kubernetes-basics/expose-intro.html @@ -31,7 +31,7 @@

    This abstraction will allow us to expose Pods to traffic originating from outside the cluster. Services have their own unique cluster-private IP address and expose a port to receive traffic. If you choose to expose the service outside the cluster, the options are:

      -
    • LoadBalancer - provides a public IP address (what you would typically use when you run Kubernetes on GCE or AWS)
      • +
    • LoadBalancer - provides a public IP address (what you would typically use when you run Kubernetes on GCP or AWS)
    • NodePort - exposes the Service on the same port on each Node of the cluster using NAT (available on all Kubernetes clusters, and in Minikube)
    From 0ecc4d600b8afcdad8832b1cfd7a2f3f9346518c Mon Sep 17 00:00:00 2001 From: devin-donnelly Date: Thu, 22 Dec 2016 18:54:20 -0800 Subject: [PATCH 31/68] Update authentication.md --- docs/admin/authentication.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/admin/authentication.md b/docs/admin/authentication.md index 064b7cd50f..a3726cbf2d 100644 --- a/docs/admin/authentication.md +++ b/docs/admin/authentication.md @@ -35,7 +35,7 @@ or be treated as an anonymous user. ## Authentication strategies Kubernetes uses client certificates, bearer tokens, an authenticating proxy, or HTTP basic auth to -authenticate API requests through authentication plugins. As HTTP request are +authenticate API requests through authentication plugins. As HTTP requests are made to the API server, plugins attempt to associate the following attributes with the request: From 2374e3d1bb4a175a2b0021b593e3171bb89a4c71 Mon Sep 17 00:00:00 2001 From: dongziming Date: Fri, 23 Dec 2016 13:44:14 +0800 Subject: [PATCH 32/68] Fixed some e.g. problems and some spelling errors. --- docs/admin/cluster-troubleshooting.md | 2 +- docs/admin/daemons.md | 2 +- docs/admin/multi-cluster.md | 2 +- docs/admin/node-problem.md | 4 ++-- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/admin/cluster-troubleshooting.md b/docs/admin/cluster-troubleshooting.md index 89cd99926b..ff8358a7a9 100644 --- a/docs/admin/cluster-troubleshooting.md +++ b/docs/admin/cluster-troubleshooting.md @@ -89,7 +89,7 @@ Mitigations: - Mitigates: Apiserver VM shutdown or apiserver crashing - Mitigates: Supporting services VM shutdown or crashes -- Action use IaaS providers reliable storage (e.g GCE PD or AWS EBS volume) for VMs with apiserver+etcd +- Action use IaaS providers reliable storage (e.g. GCE PD or AWS EBS volume) for VMs with apiserver+etcd - Mitigates: Apiserver backing storage lost - Action: Use (experimental) [high-availability](/docs/admin/high-availability) configuration diff --git a/docs/admin/daemons.md b/docs/admin/daemons.md index 819636ba99..4682a62b71 100644 --- a/docs/admin/daemons.md +++ b/docs/admin/daemons.md @@ -129,7 +129,7 @@ Support for updating DaemonSets and controlled updating of nodes is planned. ### Init Scripts -It is certainly possible to run daemon processes by directly starting them on a node (e.g using +It is certainly possible to run daemon processes by directly starting them on a node (e.g. using `init`, `upstartd`, or `systemd`). This is perfectly fine. However, there are several advantages to running such processes via a DaemonSet: diff --git a/docs/admin/multi-cluster.md b/docs/admin/multi-cluster.md index 1d238d8e13..4473bb381d 100644 --- a/docs/admin/multi-cluster.md +++ b/docs/admin/multi-cluster.md @@ -52,7 +52,7 @@ Second, decide how many clusters should be able to be unavailable at the same ti the number that can be unavailable `U`. If you are not sure, then 1 is a fine choice. If it is allowable for load-balancing to direct traffic to any region in the event of a cluster failure, then -you need at least the larger of `R` or `U + 1` clusters. If it is not (e.g you want to ensure low latency for all +you need at least the larger of `R` or `U + 1` clusters. If it is not (e.g. you want to ensure low latency for all users in the event of a cluster failure), then you need to have `R * (U + 1)` clusters (`U + 1` in each of `R` regions). In any case, try to put each cluster in a different zone. diff --git a/docs/admin/node-problem.md b/docs/admin/node-problem.md index 0d7b57005e..b4f3e6ee31 100644 --- a/docs/admin/node-problem.md +++ b/docs/admin/node-problem.md @@ -49,7 +49,7 @@ either `kubectl` or addon pod. ### Kubectl -This is the recommanded way to start node problem detector outside of GCE. It +This is the recommended way to start node problem detector outside of GCE. It provides more flexible management, such as overwriting the default configuration to fit it into your environment or detect customized node problems. @@ -238,7 +238,7 @@ implement a new translator for a new log format. ## Caveats -It is recommanded to run the node problem detector in your cluster to monitor +It is recommended to run the node problem detector in your cluster to monitor the node health. However, you should be aware that this will introduce extra resource overhead on each node. Usually this is fine, because: From 0328b6d591bc698050dd4935771ba1775e68063e Mon Sep 17 00:00:00 2001 From: Martially <21651061@zju.edu.cn> Date: Fri, 23 Dec 2016 14:06:54 +0800 Subject: [PATCH 33/68] fix typo Signed-off-by: Martially <21651061@zju.edu.cn> --- docs/whatisk8s.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/whatisk8s.md b/docs/whatisk8s.md index 7c1e637b6d..2e53554863 100644 --- a/docs/whatisk8s.md +++ b/docs/whatisk8s.md @@ -52,7 +52,7 @@ Summary of container benefits: * **Cloud and OS distribution portability**: Runs on Ubuntu, RHEL, CoreOS, on-prem, Google Container Engine, and anywhere else. * **Application-centric management**: - Raises the level of abstraction from running an OS on virtual hardware to running an application on an OS using logical resources. + Raises the level of abstraction from running an OS on virtual hardware to run an application on an OS using logical resources. * **Loosely coupled, distributed, elastic, liberated [micro-services](http://martinfowler.com/articles/microservices.html)**: Applications are broken into smaller, independent pieces and can be deployed and managed dynamically -- not a fat monolithic stack running on one big single-purpose machine. * **Resource isolation**: From 996b4343dcd6a563dbdf876a3d06f1894cc3a532 Mon Sep 17 00:00:00 2001 From: Martially <21651061@zju.edu.cn> Date: Fri, 23 Dec 2016 14:17:29 +0800 Subject: [PATCH 34/68] link error Signed-off-by: Martially <21651061@zju.edu.cn> --- docs/whatisk8s.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/whatisk8s.md b/docs/whatisk8s.md index 2e53554863..dde25433de 100644 --- a/docs/whatisk8s.md +++ b/docs/whatisk8s.md @@ -106,7 +106,7 @@ Kubernetes is not a traditional, all-inclusive PaaS (Platform as a Service) syst * Kubernetes does not provide nor mandate a comprehensive application configuration language/system (e.g., [jsonnet](https://github.com/google/jsonnet)). * Kubernetes does not provide nor adopt any comprehensive machine configuration, maintenance, management, or self-healing systems. -On the other hand, a number of PaaS systems run *on* Kubernetes, such as [Openshift](https://github.com/openshift/origin), [Deis](http://deis.io/), and [Gondor](https://gondor.io/). You could also roll your own custom PaaS, integrate with a CI system of your choice, or get along just fine with just Kubernetes: bring your container images and deploy them on Kubernetes. +On the other hand, a number of PaaS systems run *on* Kubernetes, such as [Openshift](https://github.com/openshift/origin), [Deis](http://deis.io/), and [Eldarion Cloud](http://eldarion.cloud/). You could also roll your own custom PaaS, integrate with a CI system of your choice, or get along just fine with just Kubernetes: bring your container images and deploy them on Kubernetes. Since Kubernetes operates at the application level rather than at just the hardware level, it provides some generally applicable features common to PaaS offerings, such as deployment, scaling, load balancing, logging, monitoring, etc. However, Kubernetes is not monolithic, and these default solutions are optional and pluggable. From 990bc41aac05df748eee6d9a4fe99db41e58e4e1 Mon Sep 17 00:00:00 2001 From: CandiceGuo Date: Fri, 23 Dec 2016 14:39:27 +0800 Subject: [PATCH 35/68] modify some grammar mistakes in /doc/ --- docs/admin/accessing-the-api.md | 2 +- docs/admin/apparmor/index.md | 2 +- docs/admin/federation/index.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/admin/accessing-the-api.md b/docs/admin/accessing-the-api.md index 5a57db23ce..a70f1c0920 100644 --- a/docs/admin/accessing-the-api.md +++ b/docs/admin/accessing-the-api.md @@ -86,7 +86,7 @@ For version 1.2, clusters created by `kube-up.sh` are configured so that no auth required for any request. As of version 1.3, clusters created by `kube-up.sh` are configured so that the ABAC authorization -modules is enabled. However, its input file is initially set to allow all users to do all +modules are enabled. However, its input file is initially set to allow all users to do all operations. The cluster administrator needs to edit that file, or configure a different authorizer to restrict what users can do. diff --git a/docs/admin/apparmor/index.md b/docs/admin/apparmor/index.md index 4c2d02d989..224f0bbdeb 100644 --- a/docs/admin/apparmor/index.md +++ b/docs/admin/apparmor/index.md @@ -384,7 +384,7 @@ Specifying the default profile to apply to containers when none is provided: - **key**: `apparmor.security.beta.kubernetes.io/defaultProfileName` - **value**: a profile reference, described above -Specifying the list of profiles Pod containers are allowed to specify: +Specifying the list of profiles Pod containers is allowed to specify: - **key**: `apparmor.security.beta.kubernetes.io/allowedProfileNames` - **value**: a comma-separated list of profile references (described above) diff --git a/docs/admin/federation/index.md b/docs/admin/federation/index.md index 478f7563de..f8fb5b6c4f 100644 --- a/docs/admin/federation/index.md +++ b/docs/admin/federation/index.md @@ -110,7 +110,7 @@ $ KUBE_REGISTRY="gcr.io/myrepository" federation/develop/develop.sh build_image $ KUBE_REGISTRY="gcr.io/myrepository" federation/develop/develop.sh push ``` -Note: This is going to overwite the values you might have set for +Note: This is going to overwrite the values you might have set for `apiserverRegistry`, `apiserverVersion`, `controllerManagerRegistry` and `controllerManagerVersion` in your `${FEDERATION_OUTPUT_ROOT}/values.yaml` file. Hence, it is not recommend to customize these values in From 41a9b7c55d302096c9f0d62119722299cdecfb58 Mon Sep 17 00:00:00 2001 From: Martially <21651061@zju.edu.cn> Date: Fri, 23 Dec 2016 15:26:12 +0800 Subject: [PATCH 36/68] fix typo Signed-off-by: Martially <21651061@zju.edu.cn> --- .../stateful-application/run-replicated-stateful-application.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tutorials/stateful-application/run-replicated-stateful-application.md b/docs/tutorials/stateful-application/run-replicated-stateful-application.md index 29f0d68242..30d22e1cce 100644 --- a/docs/tutorials/stateful-application/run-replicated-stateful-application.md +++ b/docs/tutorials/stateful-application/run-replicated-stateful-application.md @@ -180,7 +180,7 @@ replicating. In general, when a new Pod joins the set as a slave, it must assume the MySQL master might already have data on it. It also must assume that the replication logs might not go all the way back to the beginning of time. -These conservative assumptions are the key to allowing a running StatefulSet +These conservative assumptions are the key to allow a running StatefulSet to scale up and down over time, rather than being fixed at its initial size. The second Init Container, named `clone-mysql`, performs a clone operation on From c67b76a2f0607943ffc0685f210edbc47646d1c3 Mon Sep 17 00:00:00 2001 From: guohaifang Date: Fri, 23 Dec 2016 15:29:44 +0800 Subject: [PATCH 37/68] problems of grammer --- docs/tutorials/stateful-application/basic-stateful-set.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tutorials/stateful-application/basic-stateful-set.md b/docs/tutorials/stateful-application/basic-stateful-set.md index 07e41cd56d..60a8a30652 100644 --- a/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/docs/tutorials/stateful-application/basic-stateful-set.md @@ -11,7 +11,7 @@ title: StatefulSet Basics --- {% capture overview %} -This tutorial provides an introduction to managing applications with +This tutorial provides an introduction to manage applications with [StatefulSets](/docs/concepts/abstractions/controllers/statefulsets/). It demonstrates how to create, delete, scale, and update the container image of a StatefulSet. From a129e1c4c1d6569b1e9abb79cb2908fcd1a4601e Mon Sep 17 00:00:00 2001 From: dongziming Date: Fri, 23 Dec 2016 15:59:02 +0800 Subject: [PATCH 38/68] Spelling errors in /docs/ --- docs/getting-started-guides/ubuntu/automated.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/getting-started-guides/ubuntu/automated.md b/docs/getting-started-guides/ubuntu/automated.md index 6a1e905bf8..d82c4ca545 100644 --- a/docs/getting-started-guides/ubuntu/automated.md +++ b/docs/getting-started-guides/ubuntu/automated.md @@ -206,7 +206,7 @@ Congratulations, you've now set up a Kubernetes cluster! Want larger Kubernetes nodes? It is easy to request different sizes of cloud resources from Juju by using **constraints**. You can increase the amount of CPU or memory (RAM) in any of the systems requested by Juju. This allows you -to fine tune th Kubernetes cluster to fit your workload. Use flags on the +to fine tune the Kubernetes cluster to fit your workload. Use flags on the bootstrap command or as a separate `juju constraints` command. Look to the [Juju documentation for machine](https://jujucharms.com/docs/2.0/charms-constraints) details. From 5c5ebf0bf159b45e69e5e28c8450c3af6f46b97e Mon Sep 17 00:00:00 2001 From: dongziming Date: Fri, 23 Dec 2016 16:45:56 +0800 Subject: [PATCH 39/68] Some spelling errors in /docs/ --- docs/getting-started-guides/clc.md | 2 +- docs/getting-started-guides/kops.md | 2 +- docs/getting-started-guides/photon-controller.md | 2 +- docs/getting-started-guides/scratch.md | 4 ++-- docs/tutorials/stateful-application/basic-stateful-set.md | 4 ++-- 5 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/getting-started-guides/clc.md b/docs/getting-started-guides/clc.md index 121b6c1030..bd0804eb9b 100644 --- a/docs/getting-started-guides/clc.md +++ b/docs/getting-started-guides/clc.md @@ -218,7 +218,7 @@ We configure the Kubernetes cluster with the following features: We use the following to create the kubernetes cluster: * Kubernetes 1.1.7 -* Unbuntu 14.04 +* Ubuntu 14.04 * Flannel 0.5.4 * Docker 1.9.1-0~trusty * Etcd 2.2.2 diff --git a/docs/getting-started-guides/kops.md b/docs/getting-started-guides/kops.md index 90ea6546a2..0b2381dd18 100644 --- a/docs/getting-started-guides/kops.md +++ b/docs/getting-started-guides/kops.md @@ -57,7 +57,7 @@ kops uses DNS for discovery, both inside the cluster and so that you can reach t from clients. kops has a strong opinion on the cluster name: it should be a valid DNS name. By doing so you will -no longer get your clusters confused, you can share clusters with your colleagues unambigiously, +no longer get your clusters confused, you can share clusters with your colleagues unambiguously, and you can reach them without relying on remembering an IP address. You can, and probably should, use subdomains to divide your clusters. As our example we will use diff --git a/docs/getting-started-guides/photon-controller.md b/docs/getting-started-guides/photon-controller.md index ec9d9511fa..df9d14326a 100644 --- a/docs/getting-started-guides/photon-controller.md +++ b/docs/getting-started-guides/photon-controller.md @@ -163,7 +163,7 @@ balancer. Specifically: Configure your service with the NodePort option. For example, this service uses the NodePort option. All Kubernetes nodes will listen on a port and forward network traffic to any pods in the service. In this -case, Kubernets will choose a random port, but it will be the same +case, Kubernetes will choose a random port, but it will be the same port on all nodes. ```yaml diff --git a/docs/getting-started-guides/scratch.md b/docs/getting-started-guides/scratch.md index dd554c5715..2ef0f75dc3 100644 --- a/docs/getting-started-guides/scratch.md +++ b/docs/getting-started-guides/scratch.md @@ -69,7 +69,7 @@ accomplished in two ways: - **Using an overlay network** - An overlay network obscures the underlying network architecture from the - pod network through traffic encapsulation (e.g vxlan). + pod network through traffic encapsulation (e.g. vxlan). - Encapsulation reduces performance, though exactly how much depends on your solution. - **Without an overlay network** - Configure the underlying network fabric (switches, routers, etc.) to be aware of pod IP addresses. @@ -180,7 +180,7 @@ we recommend that you run these as containers, so you need an image to be built. You have several choices for Kubernetes images: - Use images hosted on Google Container Registry (GCR): - - e.g `gcr.io/google_containers/hyperkube:$TAG`, where `TAG` is the latest + - e.g. `gcr.io/google_containers/hyperkube:$TAG`, where `TAG` is the latest release tag, which can be found on the [latest releases page](https://github.com/kubernetes/kubernetes/releases/latest). - Ensure $TAG is the same tag as the release tag you are using for kubelet and kube-proxy. - The [hyperkube](https://releases.k8s.io/{{page.githubbranch}}/cmd/hyperkube) binary is an all in one binary diff --git a/docs/tutorials/stateful-application/basic-stateful-set.md b/docs/tutorials/stateful-application/basic-stateful-set.md index 07e41cd56d..0edf9f9d38 100644 --- a/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/docs/tutorials/stateful-application/basic-stateful-set.md @@ -122,7 +122,7 @@ launching `web-1`. In fact, `web-1` is not launched until `web-0` is [Running and Ready](/docs/user-guide/pod-states). ### Pods in a StatefulSet -Unlike Pods in other controllers, the Pods in a StatefulSet have a unqiue +Unlike Pods in other controllers, the Pods in a StatefulSet have a unique ordinal index and a stable network identity. #### Examining the Pod's Ordinal Index @@ -177,7 +177,7 @@ Name: web-1.nginx Address 1: 10.244.2.6 ``` -The CNAME of the headless serivce points to SRV records (one for each Pod that +The CNAME of the headless service points to SRV records (one for each Pod that is Running and Ready). The SRV records point to A record entries that contain the Pods' IP addresses. From 83a6c52ddc9c425df24a6dbed2545601aea46cdb Mon Sep 17 00:00:00 2001 From: dongziming Date: Fri, 23 Dec 2016 17:25:27 +0800 Subject: [PATCH 40/68] Spelling errors in /docs/ --- docs/user-guide/federation/events.md | 2 +- docs/user-guide/federation/federated-services.md | 6 +++--- docs/user-guide/pods/init-container.md | 2 +- docs/user-guide/secrets/index.md | 2 +- docs/user-guide/services/index.md | 2 +- 5 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/user-guide/federation/events.md b/docs/user-guide/federation/events.md index f1f8868466..60c78ad9c5 100644 --- a/docs/user-guide/federation/events.md +++ b/docs/user-guide/federation/events.md @@ -24,7 +24,7 @@ general. ## Overview -Events in federation control plane (refered to as "federation events" in +Events in federation control plane (referred to as "federation events" in this guide) are very similar to the traditional Kubernetes Events providing the same functionality. Federation Events are stored only in federation control plane and are not passed on to the underlying kubernetes clusters. diff --git a/docs/user-guide/federation/federated-services.md b/docs/user-guide/federation/federated-services.md index 354fbeca01..b163ad18e8 100644 --- a/docs/user-guide/federation/federated-services.md +++ b/docs/user-guide/federation/federated-services.md @@ -232,7 +232,7 @@ due to caching by intermediate DNS servers. The above set of DNS records is automatically kept in sync with the current state of health of all service shards globally by the Federated Service system. DNS resolver libraries (which are invoked by -all clients) automatically traverse the hiearchy of 'CNAME' and 'A' +all clients) automatically traverse the hierarchy of 'CNAME' and 'A' records to return the correct set of healthy IP addresses. Clients can then select any one of the returned addresses to initiate a network connection (and fail over automatically to one of the other equivalent @@ -295,7 +295,7 @@ availability zones and regions other than the ones local to a Pod by specifying the appropriate DNS names explicitly, and not relying on automatic DNS expansion. For example, "nginx.mynamespace.myfederation.svc.europe-west1.example.com" will -resolve to all of the currently healthy service shards in europe, even +resolve to all of the currently healthy service shards in Europe, even if the Pod issuing the lookup is located in the U.S., and irrespective of whether or not there are healthy shards of the service in the U.S. This is useful for remote monitoring and other similar applications. @@ -316,7 +316,7 @@ us.nginx.acme.com CNAME nginx.mynamespace.myfederation.svc.us-central1.ex nginx.acme.com CNAME nginx.mynamespace.myfederation.svc.example.com. ``` That way your clients can always use the short form on the left, and -always be automatcally routed to the closest healthy shard on their +always be automatically routed to the closest healthy shard on their home continent. All of the required failover is handled for you automatically by Kubernetes Cluster Federation. Future releases will improve upon this even further. diff --git a/docs/user-guide/pods/init-container.md b/docs/user-guide/pods/init-container.md index 75b6efcac3..2f4748f9cf 100644 --- a/docs/user-guide/pods/init-container.md +++ b/docs/user-guide/pods/init-container.md @@ -159,7 +159,7 @@ reasons: * This is uncommon and would have to be done by someone with root access to nodes. * All containers in a pod are terminated, requiring a restart (RestartPolicyAlways) AND the record of init container completion has been lost due to garbage collection. -## Support and compatibilty +## Support and compatibility A cluster with Kubelet and Apiserver version 1.4.0 or greater supports init containers with the beta annotations. Support varies for other combinations of diff --git a/docs/user-guide/secrets/index.md b/docs/user-guide/secrets/index.md index 79b6d93a7d..6f6728db42 100644 --- a/docs/user-guide/secrets/index.md +++ b/docs/user-guide/secrets/index.md @@ -666,7 +666,7 @@ one called, say, `prod-user` with the `prod-db-secret`, and one called, say, ### Use-case: Dotfiles in secret volume -In order to make piece of data 'hidden' (ie, in a file whose name begins with a dot character), simply +In order to make piece of data 'hidden' (i.e., in a file whose name begins with a dot character), simply make that key begin with a dot. For example, when the following secret is mounted into a volume: ```json diff --git a/docs/user-guide/services/index.md b/docs/user-guide/services/index.md index 8151eebab9..60fa80e2e7 100644 --- a/docs/user-guide/services/index.md +++ b/docs/user-guide/services/index.md @@ -500,7 +500,7 @@ within AWS Certificate Manager. }, ``` -The second annotation specificies which protocol a pod speaks. For HTTPS and +The second annotation specifies which protocol a pod speaks. For HTTPS and SSL, the ELB will expect the pod to authenticate itself over the encrypted connection. From 19fda131727fda0fe72b9fc41f16af384f8edc1f Mon Sep 17 00:00:00 2001 From: dongziming Date: Fri, 23 Dec 2016 20:53:16 +0800 Subject: [PATCH 41/68] Fix typos --- _includes/v1.3/extensions-v1beta1-definitions.html | 2 +- _includes/v1.4/extensions-v1beta1-definitions.html | 2 +- _includes/v1.5/extensions-v1beta1-definitions.html | 2 +- docs/admin/network-plugins.md | 2 +- docs/api-reference/extensions/v1beta1/definitions.html | 2 +- .../api-reference/extensions/v1beta1/definitions.html | 2 +- docs/getting-started-guides/cloudstack.md | 2 +- docs/getting-started-guides/libvirt-coreos.md | 2 +- docs/getting-started-guides/ubuntu/calico.md | 2 +- docs/user-guide/images.md | 2 +- docs/user-guide/ingress.md | 8 ++++---- docs/user-guide/persistent-volumes/index.md | 2 +- docs/user-guide/petset.md | 6 +++--- 13 files changed, 18 insertions(+), 18 deletions(-) diff --git a/_includes/v1.3/extensions-v1beta1-definitions.html b/_includes/v1.3/extensions-v1beta1-definitions.html index 7ecddc8d7b..0c4ab489a5 100755 --- a/_includes/v1.3/extensions-v1beta1-definitions.html +++ b/_includes/v1.3/extensions-v1beta1-definitions.html @@ -5867,7 +5867,7 @@ Both these may change in the future. Incoming requests are matched against the h
    - + diff --git a/_includes/v1.4/extensions-v1beta1-definitions.html b/_includes/v1.4/extensions-v1beta1-definitions.html index 62b899b9fd..18bc35fc59 100755 --- a/_includes/v1.4/extensions-v1beta1-definitions.html +++ b/_includes/v1.4/extensions-v1beta1-definitions.html @@ -6054,7 +6054,7 @@ Both these may change in the future. Incoming requests are matched against the h - + diff --git a/_includes/v1.5/extensions-v1beta1-definitions.html b/_includes/v1.5/extensions-v1beta1-definitions.html index 1a275085f7..bd86db7daa 100755 --- a/_includes/v1.5/extensions-v1beta1-definitions.html +++ b/_includes/v1.5/extensions-v1beta1-definitions.html @@ -6316,7 +6316,7 @@ Both these may change in the future. Incoming requests are matched against the h - + diff --git a/docs/admin/network-plugins.md b/docs/admin/network-plugins.md index 6f4ef262ff..27219bc5de 100644 --- a/docs/admin/network-plugins.md +++ b/docs/admin/network-plugins.md @@ -32,7 +32,7 @@ By default if no kubelet network plugin is specified, the `noop` plugin is used, ### Exec -Place plugins in `network-plugin-dir/plugin-name/plugin-name`, i.e if you have a bridge plugin and `network-plugin-dir` is `/usr/lib/kubernetes`, you'd place the bridge plugin executable at `/usr/lib/kubernetes/bridge/bridge`. See [this comment](https://github.com/kubernetes/kubernetes/tree/{{page.version}}/pkg/kubelet/network/exec/exec.go) for more details. +Place plugins in `network-plugin-dir/plugin-name/plugin-name`, i.e. if you have a bridge plugin and `network-plugin-dir` is `/usr/lib/kubernetes`, you'd place the bridge plugin executable at `/usr/lib/kubernetes/bridge/bridge`. See [this comment](https://github.com/kubernetes/kubernetes/tree/{{page.version}}/pkg/kubelet/network/exec/exec.go) for more details. ### CNI diff --git a/docs/api-reference/extensions/v1beta1/definitions.html b/docs/api-reference/extensions/v1beta1/definitions.html index b92378524f..3f1129b1b6 100755 --- a/docs/api-reference/extensions/v1beta1/definitions.html +++ b/docs/api-reference/extensions/v1beta1/definitions.html @@ -6320,7 +6320,7 @@ Both these may change in the future. Incoming requests are matched against the h - + diff --git a/docs/federation/api-reference/extensions/v1beta1/definitions.html b/docs/federation/api-reference/extensions/v1beta1/definitions.html index e3c029af86..897ab5aca8 100755 --- a/docs/federation/api-reference/extensions/v1beta1/definitions.html +++ b/docs/federation/api-reference/extensions/v1beta1/definitions.html @@ -5240,7 +5240,7 @@ Both these may change in the future. Incoming requests are matched against the h - + diff --git a/docs/getting-started-guides/cloudstack.md b/docs/getting-started-guides/cloudstack.md index e19aa55413..4dd542f127 100644 --- a/docs/getting-started-guides/cloudstack.md +++ b/docs/getting-started-guides/cloudstack.md @@ -66,7 +66,7 @@ Some variables can be edited in the `k8s.yml` file. k8s_instance_type: Tiny This will start a Kubernetes master node and a number of compute nodes (by default 2). -The `instance_type` and `template` by default are specific to [exoscale](http://exoscale.ch), edit them to specify your CloudStack cloud specific template and instance type (i.e service offering). +The `instance_type` and `template` by default are specific to [exoscale](http://exoscale.ch), edit them to specify your CloudStack cloud specific template and instance type (i.e. service offering). Check the tasks and templates in `roles/k8s` if you want to modify anything. diff --git a/docs/getting-started-guides/libvirt-coreos.md b/docs/getting-started-guides/libvirt-coreos.md index 73be7e4261..33c6c6be67 100644 --- a/docs/getting-started-guides/libvirt-coreos.md +++ b/docs/getting-started-guides/libvirt-coreos.md @@ -45,7 +45,7 @@ On the other hand, `libvirt-coreos` might be useful for people investigating low 3. Install [qemu](http://wiki.qemu.org/Main_Page) 4. Install [libvirt](http://libvirt.org/) 5. Install [openssl](http://openssl.org/) -6. Enable and start the libvirt daemon, e.g: +6. Enable and start the libvirt daemon, e.g.: * ``systemctl enable libvirtd && systemctl start libvirtd`` # for systemd-based systems * ``/etc/init.d/libvirt-bin start`` # for init.d-based systems 7. [Grant libvirt access to your user¹](https://libvirt.org/aclpolkit.html) diff --git a/docs/getting-started-guides/ubuntu/calico.md b/docs/getting-started-guides/ubuntu/calico.md index 2eaf7a7aea..88028d14bd 100644 --- a/docs/getting-started-guides/ubuntu/calico.md +++ b/docs/getting-started-guides/ubuntu/calico.md @@ -385,7 +385,7 @@ On your compute nodes, it is important that you install Calico before Kubernetes ## Configure kubectl remote access -To administer your cluster from a separate host (e.g your laptop), you will need the root CA generated earlier, as well as an admin public/private keypair (`ca.pem`, `admin.pem`, `admin-key.pem`). Run the following steps on the machine which you will use to control your cluster. +To administer your cluster from a separate host (e.g. your laptop), you will need the root CA generated earlier, as well as an admin public/private keypair (`ca.pem`, `admin.pem`, `admin-key.pem`). Run the following steps on the machine which you will use to control your cluster. 1. Download the kubectl binary. diff --git a/docs/user-guide/images.md b/docs/user-guide/images.md index 44e7363b89..37cfd53b9d 100644 --- a/docs/user-guide/images.md +++ b/docs/user-guide/images.md @@ -296,7 +296,7 @@ will be merged. This approach will work on Google Container Engine (GKE). There are a number of solutions for configuring private registries. Here are some common use cases and suggested solutions. -1. Cluster running only non-proprietary (e.g open-source) images. No need to hide images. +1. Cluster running only non-proprietary (e.g. open-source) images. No need to hide images. - Use public images on the Docker hub. - no configuration required - on GCE/GKE, a local mirror is automatically used for improved speed and availability diff --git a/docs/user-guide/ingress.md b/docs/user-guide/ingress.md index c510de1d62..e0bebc4795 100644 --- a/docs/user-guide/ingress.md +++ b/docs/user-guide/ingress.md @@ -73,7 +73,7 @@ __Lines 1-4__: As with all other Kubernetes config, an Ingress needs `apiVersion __Lines 5-7__: Ingress [spec](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status) has all the information needed to configure a loadbalancer or proxy server. Most importantly, it contains a list of rules matched against all incoming requests. Currently the Ingress resource only supports http rules. -__Lines 8-9__: Each http rule contains the following information: A host (eg: foo.bar.com, defaults to * in this example), a list of paths (eg: /testpath) each of which has an associated backend (test:80). Both the host and path must match the content of an incoming request before the loadbalancer directs traffic to the backend. +__Lines 8-9__: Each http rule contains the following information: A host (e.g.: foo.bar.com, defaults to * in this example), a list of paths (e.g.: /testpath) each of which has an associated backend (test:80). Both the host and path must match the content of an incoming request before the loadbalancer directs traffic to the backend. __Lines 10-12__: A backend is a service:port combination as described in the [services doc](/docs/user-guide/services). Ingress traffic is typically sent directly to the endpoints matching a backend. @@ -185,7 +185,7 @@ __Default Backends__: An Ingress with no rules, like the one shown in the previo ### TLS -You can secure an Ingress by specifying a [secret](/docs/user-guide/secrets) that contains a TLS private key and certificate. Currently the Ingress only supports a single TLS port, 443, and assumes TLS termination. If the TLS configuration section in an Ingress specifies different hosts, they will be multiplexed on the same port according to the hostname specified through the SNI TLS extension (provided the Ingress controller supports SNI). The TLS secret must contain keys named `tls.crt` and `tls.key` that contain the certificate and private key to use for TLS, eg: +You can secure an Ingress by specifying a [secret](/docs/user-guide/secrets) that contains a TLS private key and certificate. Currently the Ingress only supports a single TLS port, 443, and assumes TLS termination. If the TLS configuration section in an Ingress specifies different hosts, they will be multiplexed on the same port according to the hostname specified through the SNI TLS extension (provided the Ingress controller supports SNI). The TLS secret must contain keys named `tls.crt` and `tls.key` that contain the certificate and private key to use for TLS, e.g.: ```yaml apiVersion: v1 @@ -218,7 +218,7 @@ Note that there is a gap between TLS features supported by various Ingress contr ### Loadbalancing -An Ingress controller is bootstrapped with some loadbalancing policy settings that it applies to all Ingress, such as the loadbalancing algorithm, backend weight scheme etc. More advanced loadbalancing concepts (eg: persistent sessions, dynamic weights) are not yet exposed through the Ingress. You can still get these features through the [service loadbalancer](https://github.com/kubernetes/contrib/tree/master/service-loadbalancer). With time, we plan to distill loadbalancing patterns that are applicable cross platform into the Ingress resource. +An Ingress controller is bootstrapped with some loadbalancing policy settings that it applies to all Ingress, such as the loadbalancing algorithm, backend weight scheme etc. More advanced loadbalancing concepts (e.g.: persistent sessions, dynamic weights) are not yet exposed through the Ingress. You can still get these features through the [service loadbalancer](https://github.com/kubernetes/contrib/tree/master/service-loadbalancer). With time, we plan to distill loadbalancing patterns that are applicable cross platform into the Ingress resource. It's also worth noting that even though health checks are not exposed directly through the Ingress, there exist parallel concepts in Kubernetes such as [readiness probes](https://github.com/kubernetes/kubernetes/blob/release-1.0/docs/user-guide/production-pods.md#liveness-and-readiness-probes-aka-health-checks) which allow you to achieve the same end result. Please review the controller specific docs to see how they handle health checks ([nginx](https://github.com/kubernetes/contrib/blob/master/ingress/controllers/nginx/README.md), [GCE](https://github.com/kubernetes/contrib/blob/master/ingress/controllers/gce/README.md#health-checks)). @@ -277,7 +277,7 @@ Techniques for spreading traffic across failure domains differs between cloud pr ## Future Work -* Various modes of HTTPS/TLS support (eg: SNI, re-encryption) +* Various modes of HTTPS/TLS support (e.g.: SNI, re-encryption) * Requesting an IP or Hostname via claims * Combining L4 and L7 Ingress * More Ingress controllers diff --git a/docs/user-guide/persistent-volumes/index.md b/docs/user-guide/persistent-volumes/index.md index d16cecd208..d578e215d6 100644 --- a/docs/user-guide/persistent-volumes/index.md +++ b/docs/user-guide/persistent-volumes/index.md @@ -18,7 +18,7 @@ Managing storage is a distinct problem from managing compute. The `PersistentVol A `PersistentVolume` (PV) is a piece of networked storage in the cluster that has been provisioned by an administrator. It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system. -A `PersistentVolumeClaim` (PVC) is a request for storage by a user. It is similar to a pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g, can be mounted once read/write or many times read-only). +A `PersistentVolumeClaim` (PVC) is a request for storage by a user. It is similar to a pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., can be mounted once read/write or many times read-only). While `PersistentVolumeClaims` allow a user to consume abstract storage resources, it is common that users need `PersistentVolumes` with varying diff --git a/docs/user-guide/petset.md b/docs/user-guide/petset.md index 3cba1fb31e..0f6abcde1a 100644 --- a/docs/user-guide/petset.md +++ b/docs/user-guide/petset.md @@ -28,8 +28,8 @@ Throughout this doc you will see a few terms that are sometimes used interchange * Node: A single virtual or physical machine in a Kubernetes cluster. * Cluster: A group of nodes in a single failure domain, unless mentioned otherwise. * Persistent Volume Claim (PVC): A request for storage, typically a [persistent volume](/docs/user-guide/persistent-volumes/walkthrough/). -* Host name: The hostname attached to the UTS namespace of the pod, i.e the output of `hostname` in the pod. -* DNS/Domain name: A *cluster local* domain name resolvable using standard methods (eg: [gethostbyname](http://linux.die.net/man/3/gethostbyname)). +* Host name: The hostname attached to the UTS namespace of the pod, i.e. the output of `hostname` in the pod. +* DNS/Domain name: A *cluster local* domain name resolvable using standard methods (e.g.: [gethostbyname](http://linux.die.net/man/3/gethostbyname)). * Ordinality: the property of being "ordinal", or occupying a position in a sequence. * Pet: a single member of a PetSet; more generally, a stateful application. * Peer: a process running a server, capable of communicating with other such processes. @@ -303,7 +303,7 @@ NAME DESIRED CURRENT AGE web 5 5 30m ``` -Note however, that scaling up to N and back down to M *will not* delete the volumes of the M-N pets, as described in the section on [deletion](#deleting-a-petset), i.e scaling back up to M creates new pets that use the same volumes. To see this in action, scale the PetSet back down to 3: +Note however, that scaling up to N and back down to M *will not* delete the volumes of the M-N pets, as described in the section on [deletion](#deleting-a-petset), i.e. scaling back up to M creates new pets that use the same volumes. To see this in action, scale the PetSet back down to 3: ```shell $ kubectl get po --watch-only From a9e1f2d276ee13872eb992947f1ac800962bcecb Mon Sep 17 00:00:00 2001 From: Huamin Chen Date: Fri, 23 Dec 2016 13:39:59 +0000 Subject: [PATCH 42/68] add azure disk storage class doc Signed-off-by: Huamin Chen --- docs/user-guide/persistent-volumes/index.md | 26 ++++++++++++++++++--- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/docs/user-guide/persistent-volumes/index.md b/docs/user-guide/persistent-volumes/index.md index d16cecd208..71ac6762cf 100644 --- a/docs/user-guide/persistent-volumes/index.md +++ b/docs/user-guide/persistent-volumes/index.md @@ -70,7 +70,7 @@ When a user is done with their volume, they can delete the PVC objects from the ### Reclaiming -The reclaim policy for a `PersistentVolume` tells the cluster what to do with the volume after it has been released of its claim. Currently, volumes can either be Retained, Recycled or Deleted. Retention allows for manual reclamation of the resource. For those volume plugins that support it, deletion removes both the `PersistentVolume` object from Kubernetes as well as deletes associated storage asset in external infrastructure such as AWS EBS, GCE PD or Cinder volume. Volumes that were dynamically provisioned are always deleted. +The reclaim policy for a `PersistentVolume` tells the cluster what to do with the volume after it has been released of its claim. Currently, volumes can either be Retained, Recycled or Deleted. Retention allows for manual reclamation of the resource. For those volume plugins that support it, deletion removes both the `PersistentVolume` object from Kubernetes as well as deletes associated storage asset in external infrastructure such as AWS EBS, GCE PD, Azure Disk, or Cinder volume. Volumes that were dynamically provisioned are always deleted. #### Recycling @@ -108,6 +108,7 @@ However, the particular path specified in the custom recycler pod template in th * GCEPersistentDisk * AWSElasticBlockStore * AzureFile +* AzureDisk * FC (Fibre Channel) * NFS * iSCSI @@ -170,6 +171,7 @@ In the CLI, the access modes are abbreviated to: | :--- | :---: | :---: | :---: | | AWSElasticBlockStore | x | - | - | | AzureFile | x | x | x | +| AzureDisk | x | - | - | | CephFS | x | x | x | | Cinder | x | - | - | | FC | x | x | - | @@ -199,9 +201,9 @@ Current recycling policies are: * Retain -- manual reclamation * Recycle -- basic scrub ("rm -rf /thevolume/*") -* Delete -- associated storage asset such as AWS EBS, GCE PD or OpenStack Cinder volume is deleted +* Delete -- associated storage asset such as AWS EBS, GCE PD, Azure Disk, or OpenStack Cinder volume is deleted -Currently, only NFS and HostPath support recycling. AWS EBS, GCE PD and Cinder volumes support deletion. +Currently, only NFS and HostPath support recycling. AWS EBS, GCE PD, Azure Disk, and Cinder volumes support deletion. ### Phase @@ -508,6 +510,24 @@ parameters: * `quobyteConfig`: use the specified configuration to create the volume. You can create a new configuration or modify an existing one with the Web console or the quobyte CLI. Default is "BASE". * `quobyteTenant`: use the specified tenant ID to create/delete the volume. This Quobyte tenant has to be already present in Quobyte. Default is "DEFAULT". +#### Azure Disk + +```yaml +kind: StorageClass +apiVersion: storage.k8s.io/v1beta1 +metadata: + name: slow +provisioner: kubernetes.io/azure-disk +parameters: + skuName: Standard_LRS + location: eastus + storageAccount: azure_storage_account_name +``` + +* `skuName`: Azure storage account Sku tier. Default is empty. +* `location`: Azure storage account location. Default is empty. +* `storageAccount`: Azure storage account name. If storage account is not provided, all storage accounts associated with the resource group are searched to find one that matches `skuName` and `location`. If storage account is provided, `skuName` and `location` are ignored. + ## Writing Portable Configuration From 942dbfcee11220775042e2eb67a2096c7729d781 Mon Sep 17 00:00:00 2001 From: Vladimir Rutsky Date: Sat, 24 Dec 2016 20:32:56 +0400 Subject: [PATCH 43/68] Fix markdown formatting Broken in 28899d6ec6 according to blame. --- docs/user-guide/kubectl/kubectl_drain.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/user-guide/kubectl/kubectl_drain.md b/docs/user-guide/kubectl/kubectl_drain.md index b6eba48f59..69acd19ead 100644 --- a/docs/user-guide/kubectl/kubectl_drain.md +++ b/docs/user-guide/kubectl/kubectl_drain.md @@ -11,13 +11,13 @@ Drain node in preparation for maintenance Drain node in preparation for maintenance. -The given node will be marked unschedulable to prevent new pods from arriving. 'drain' evicts the pods if the APIServer supports eviction (http://kubernetes.io/docs/admin/disruptions/). Otherwise, it will use normal DELETE to delete the pods. The 'drain' evicts or deletes all pods except mirror pods (which cannot be deleted through the API server). If there are DaemonSet-managed pods, drain will not proceed without --ignore-daemonsets, and regardless it will not delete any DaemonSet-managed pods, because those pods would be immediately replaced by the DaemonSet controller, which ignores unschedulable markings. If there are any pods that are neither mirror pods nor managed by ReplicationController, ReplicaSet, DaemonSet, StatefulSet or Job, then drain will not delete any pods unless you use --force. +The given node will be marked unschedulable to prevent new pods from arriving. 'drain' evicts the pods if the APIServer supports [eviction](http://kubernetes.io/docs/admin/disruptions/). Otherwise, it will use normal DELETE to delete the pods. The 'drain' evicts or deletes all pods except mirror pods (which cannot be deleted through the API server). If there are DaemonSet-managed pods, drain will not proceed without --ignore-daemonsets, and regardless it will not delete any DaemonSet-managed pods, because those pods would be immediately replaced by the DaemonSet controller, which ignores unschedulable markings. If there are any pods that are neither mirror pods nor managed by ReplicationController, ReplicaSet, DaemonSet, StatefulSet or Job, then drain will not delete any pods unless you use --force. 'drain' waits for graceful termination. You should not operate on the machine until the command completes. When you are ready to put the node back into service, use kubectl uncordon, which will make the node schedulable again. -! http://kubernetes.io/images/docs/kubectl_drain.svg +![Workflow](http://kubernetes.io/images/docs/kubectl_drain.svg) ``` kubectl drain NODE From 5ef4c4f1b6e4495975a43964bff6b0432e98fe0e Mon Sep 17 00:00:00 2001 From: Vladimir Rutsky Date: Sat, 24 Dec 2016 21:13:40 +0400 Subject: [PATCH 44/68] fix codeblock formatting --- docs/tasks/administer-cluster/safely-drain-node.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/tasks/administer-cluster/safely-drain-node.md b/docs/tasks/administer-cluster/safely-drain-node.md index 87fbd85d8a..902d9b1db3 100644 --- a/docs/tasks/administer-cluster/safely-drain-node.md +++ b/docs/tasks/administer-cluster/safely-drain-node.md @@ -44,11 +44,13 @@ down its physical machine or, if running on a cloud platform, deleting its virtual machine. First, identify the name of the node you wish to drain. You can list all of the nodes in your cluster with + ```shell kubectl get nodes ``` Next, tell Kubernetes to drain the node: + ```shell kubectl drain ``` @@ -56,6 +58,7 @@ kubectl drain Once it returns (without giving an error), you can power down the node (or equivalently, if on a cloud platform, delete the virtual machine backing the node). If you leave the node in the cluster during the maintenance operation, you need to run + ```shell kubectl uncordon ``` From 6e8c728e91c2439dc14e5d2c8a99aa2374391b7d Mon Sep 17 00:00:00 2001 From: foliage Date: Sun, 25 Dec 2016 17:39:40 +0800 Subject: [PATCH 45/68] update managing-deployments.md change k to kubectl --- docs/user-guide/managing-deployments.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/managing-deployments.md b/docs/user-guide/managing-deployments.md index 2555e5601c..4888c16f65 100644 --- a/docs/user-guide/managing-deployments.md +++ b/docs/user-guide/managing-deployments.md @@ -80,7 +80,7 @@ service "my-nginx-svc" deleted Because `kubectl` outputs resource names in the same syntax it accepts, it's easy to chain operations using `$()` or `xargs`: ```shell -$ kubectl get $(k create -f docs/user-guide/nginx/ -o name | grep service) +$ kubectl get $(kubectl create -f docs/user-guide/nginx/ -o name | grep service) NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-nginx-svc 10.0.0.208 80/TCP 0s ``` From eaa119652a400c8cc89870535a40cd4e4be798a0 Mon Sep 17 00:00:00 2001 From: caiyixiang Date: Mon, 26 Dec 2016 09:07:35 +0800 Subject: [PATCH 46/68] Update connecting-applications.md --- docs/user-guide/connecting-applications.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/connecting-applications.md b/docs/user-guide/connecting-applications.md index c0cb825a3b..9f38cb45f7 100644 --- a/docs/user-guide/connecting-applications.md +++ b/docs/user-guide/connecting-applications.md @@ -43,7 +43,7 @@ $ kubectl get pods -l run=my-nginx -o yaml | grep podIP podIP: 10.244.2.5 ``` -You should be able to ssh into any node in your cluster and curl both IPs. Note that the containers are *not* using port 80 on the node, nor are there any special NAT rules to route traffic to the pod. This means you can run multiple nginx pods on the same node all using the same containerPort and access them from any other pod or node in your cluster using IP. Like Docker, ports can still be published to the host node's interface(s), but the need for this is radically diminished because of the networking model. +You should be able to ssh into any node in your cluster and curl both IPs. Note that the containers are *not* using port 80 on the node, nor are there any special NAT rules to route traffic to the pod. This means you can run multiple nginx pods on the same node all using the same containerPort and access them from any other pod or node in your cluster using IP. Like Docker, ports can still be published to the host node's interfaces, but the need for this is radically diminished because of the networking model. You can read more about [how we achieve this](/docs/admin/networking/#how-to-achieve-this) if you're curious. From 18b3f20ec305670592fcf3d79949d0207ac6857e Mon Sep 17 00:00:00 2001 From: Drinky Pool Date: Mon, 26 Dec 2016 17:03:05 +0800 Subject: [PATCH 47/68] correct "pod" to "pods" correct "pod" to "pods" --- docs/user-guide/simple-nginx.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/simple-nginx.md b/docs/user-guide/simple-nginx.md index eba8702857..83011310a5 100644 --- a/docs/user-guide/simple-nginx.md +++ b/docs/user-guide/simple-nginx.md @@ -14,7 +14,7 @@ From this point onwards, it is assumed that `kubectl` is on your path from one o The [`kubectl run`](/docs/user-guide/kubectl/kubectl_run) line below will create a [`Deployment`](/docs/user-guide/deployments) named `my-nginx`, and two [nginx](https://registry.hub.docker.com/_/nginx/) [pods](/docs/user-guide/pods) listening on port 80. The `Deployment` will ensure that there are -always exactly two pod running as specified in its spec. +always exactly two pods running as specified in its spec. ```shell kubectl run my-nginx --image=nginx --replicas=2 --port=80 From 42e015d8f871eb377d848a89ef310468b0d47ed0 Mon Sep 17 00:00:00 2001 From: Peter Lee Date: Tue, 27 Dec 2016 10:46:48 +0800 Subject: [PATCH 48/68] fix style and grammar 1. Make plural nouns into same style. See it is `Services` in first sentence and `Pods` in the line 286 , but others are `Service`s and `Pod`s .So change style for these plural nouns for consistency and beauty. 2. Fix minor grammar. --- docs/user-guide/debugging-services.md | 46 +++++++++++++-------------- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/docs/user-guide/debugging-services.md b/docs/user-guide/debugging-services.md index 35d63bb941..a99c60e53a 100644 --- a/docs/user-guide/debugging-services.md +++ b/docs/user-guide/debugging-services.md @@ -7,8 +7,8 @@ title: Debugging Services --- An issue that comes up rather frequently for new installations of Kubernetes is -that `Services` are not working properly. You've run all your `Pod`s and -`Deployment`s, but you get no response when you try to access them. +that `Services` are not working properly. You've run all your `Pods` and +`Deployments`, but you get no response when you try to access them. This document will hopefully help you to figure out what's going wrong. * TOC @@ -17,7 +17,7 @@ This document will hopefully help you to figure out what's going wrong. ## Conventions Throughout this doc you will see various commands that you can run. Some -commands need to be run within `Pod`, others on a Kubernetes `Node`, and others +commands need to be run within a `Pod`, others on a Kubernetes `Node`, and others can run anywhere you have `kubectl` and credentials for the cluster. To make it clear what is expected, this document will use the following conventions. @@ -71,7 +71,7 @@ $ kubectl exec -ti -c sh ## Setup -For the purposes of this walk-through, let's run some `Pod`s. Since you're +For the purposes of this walk-through, let's run some `Pods`. Since you're probably debugging your own `Service` you can substitute your own details, or you can follow along and get a second data point. @@ -109,7 +109,7 @@ spec: protocol: TCP ``` -Confirm your `Pod`s are running: +Confirm your `Pods` are running: ```shell $ kubectl get pods -l app=hostnames @@ -196,7 +196,7 @@ Address: 10.0.1.175 ``` If this fails, perhaps your `Pod` and `Service` are in different -`Namespace`s, try a namespace-qualified name: +`Namespaces`, try a namespace-qualified name: ```shell u@pod$ nslookup hostnames.default @@ -207,7 +207,7 @@ Name: hostnames.default Address: 10.0.1.175 ``` -If this works, you'll need to ensure that `Pod`s and `Service`s run in the same +If this works, you'll need to ensure that `Pods` and `Services` run in the same `Namespace`. If this still fails, try a fully-qualified name: ```shell @@ -326,18 +326,18 @@ $ kubectl get service hostnames -o json ``` Is the port you are trying to access in `spec.ports[]`? Is the `targetPort` -correct for your `Pod`s? If you meant it to be a numeric port, is it a number -(9376) or a string "9376"? If you meant it to be a named port, do your `Pod`s +correct for your `Pods`? If you meant it to be a numeric port, is it a number +(9376) or a string "9376"? If you meant it to be a named port, do your `Pods` expose a port with the same name? Is the port's `protocol` the same as the `Pod`'s? ## Does the Service have any Endpoints? If you got this far, we assume that you have confirmed that your `Service` -exists and resolves by DNS. Now let's check that the `Pod`s you ran are +exists and is resolved by DNS. Now let's check that the `Pods` you ran are actually being selected by the `Service`. -Earlier we saw that the `Pod`s were running. We can re-check that: +Earlier we saw that the `Pods` were running. We can re-check that: ```shell $ kubectl get pods -l app=hostnames @@ -347,7 +347,7 @@ hostnames-bvc05 1/1 Running 0 1h hostnames-yp2kp 1/1 Running 0 1h ``` -The "AGE" column says that these `Pod`s are about an hour old, which implies that +The "AGE" column says that these `Pods` are about an hour old, which implies that they are running fine and not crashing. The `-l app=hostnames` argument is a label selector - just like our `Service` @@ -360,16 +360,16 @@ NAME ENDPOINTS hostnames 10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376 ``` -This confirms that the control loop has found the correct `Pod`s for your +This confirms that the control loop has found the correct `Pods` for your `Service`. If the `hostnames` row is blank, you should check that the `spec.selector` field of your `Service` actually selects for `metadata.labels` -values on your `Pod`s. +values on your `Pods`. ## Are the Pods working? -At this point, we know that your `Service` exists and has selected your `Pod`s. -Let's check that the `Pod`s are actually working - we can bypass the `Service` -mechanism and go straight to the `Pod`s. +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`. ```shell u@pod$ wget -qO- 10.244.0.5:9376 @@ -384,19 +384,19 @@ hostnames-yp2kp We expect each `Pod` in the `Endpoints` list to return its own hostname. If this is not what happens (or whatever the correct behavior is for your own -`Pod`s), you should investigate what's happening there. You might find -`kubectl logs` to be useful or `kubectl exec` directly to your `Pod`s and check +`Pods`), you should investigate what's happening there. You might find +`kubectl logs` to be useful or `kubectl exec` directly to your `Pods` and check service from there. ## Is the kube-proxy working? -If you get here, your `Service` is running, has `Endpoints`, and your `Pod`s +If you get here, your `Service` is running, has `Endpoints`, and your `Pods` are actually serving. At this point, the whole `Service` proxy mechanism is suspect. Let's confirm it, piece by piece. ### Is kube-proxy running? -Confirm that `kube-proxy` is running on your `Node`s. You should get something +Confirm that `kube-proxy` is running on your `Nodes`. You should get something like the below: ```shell @@ -429,7 +429,7 @@ should double-check your `Node` configuration and installation steps. ### Is kube-proxy writing iptables rules? One of the main responsibilities of `kube-proxy` is to write the `iptables` -rules which implement `Service`s. Let's check that those rules are getting +rules which implement `Services`. Let's check that those rules are getting written. The kube-proxy can run in either "userspace" mode or "iptables" mode. @@ -620,7 +620,7 @@ UP BROADCAST RUNNING PROMISC MULTICAST MTU:1460 Metric:1 ## Seek help If you get this far, something very strange is happening. Your `Service` is -running, has `Endpoints`, and your `Pod`s are actually serving. You have DNS +running, has `Endpoints`, and your `Pods` are actually serving. You have DNS working, `iptables` rules installed, and `kube-proxy` does not seem to be misbehaving. And yet your `Service` is not working. You should probably let us know, so we can help investigate! From a7830ae27faf470da8b3fe13edd9b183a9e47971 Mon Sep 17 00:00:00 2001 From: stkevintan Date: Tue, 27 Dec 2016 14:57:48 +0800 Subject: [PATCH 49/68] fix some irregular coding && uniform indent to space --- js/redirects.js | 16 +- js/script.js | 788 ++++++++++++++++++++++++------------------------ 2 files changed, 402 insertions(+), 402 deletions(-) diff --git a/js/redirects.js b/js/redirects.js index 32b45c2c68..3a371ca5d4 100644 --- a/js/redirects.js +++ b/js/redirects.js @@ -1,9 +1,9 @@ $( document ).ready(function() { - var oldURLs=["/README.md","/README.html",".html",".md","/v1.1/","/v1.0/"]; - var fwdDirs=["examples/","cluster/","docs/devel","docs/design"]; + var oldURLs = ["/README.md","/README.html",".html",".md","/v1.1/","/v1.0/"]; + var fwdDirs = ["examples/","cluster/","docs/devel","docs/design"]; var doRedirect = false; var notHere = false; - var forwardingURL=window.location.href; + var forwardingURL = window.location.href; var redirects = [{ "from": "resource-quota", @@ -26,14 +26,14 @@ $( document ).ready(function() { "to": "http://kubernetes.io/docs/whatisk8s/" }]; - for (i=0;i -1){ notHere = true; window.location.replace(redirects[i].to); } } - for (i=0;i -1){ var urlPieces = forwardingURL.split(fwdDirs[i]); var newURL = "https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/" + fwdDirs[i] + urlPieces[1]; @@ -42,11 +42,11 @@ $( document ).ready(function() { } } if (!notHere) { - for (i=0;i -1 && forwardingURL.indexOf("404.html") < 0){ - doRedirect=true; - forwardingURL=forwardingURL.replace(oldURLs[i],"/"); + doRedirect = true; + forwardingURL = forwardingURL.replace(oldURLs[i],"/"); } } if (doRedirect){ diff --git a/js/script.js b/js/script.js index b944d91175..d6ff1dacf8 100755 --- a/js/script.js +++ b/js/script.js @@ -1,523 +1,523 @@ //modal close button (function(){ - //π.modalCloseButton = function(closingFunction){ - // return π.button('pi-modal-close-button', null, null, closingFunction); - //}; + //π.modalCloseButton = function(closingFunction){ + // return π.button('pi-modal-close-button', null, null, closingFunction); + //}; })(); // globals var body; //helper functions -function copyCode(elem){ - if (document.getElementById(elem)) { - // create hidden text element, if it doesn't already exist - var targetId = "_hiddenCopyText_"; - // must use a temporary form element for the selection and copy - target = document.getElementById(targetId); - if (!target) { - var target = document.createElement("textarea"); - target.style.position = "absolute"; - target.style.left = "-9999px"; - target.style.top = "0"; - target.id = targetId; - document.body.appendChild(target); - } - target.value = document.getElementById(elem).innerText; - // select the content - target.setSelectionRange(0, target.value.length); - - // copy the selection - var succeed; - try { - succeed = document.execCommand("copy"); - } catch(e) { - sweetAlert("Oh, no...","Sorry, your browser doesn't support document.execCommand('copy'), so we can't copy this code to your clipboard."); - succeed = false; - } - if (succeed) sweetAlert("Copied to clipboard:",target.value); - return succeed; - } else { - sweetAlert("Oops!",elem + " not found when trying to copy code"); - return false; - } - } - -function booleanAttributeValue(element, attribute, defaultValue){ - // returns true if an attribute is present with no value - // e.g. booleanAttributeValue(element, 'data-modal', false); - if (element.hasAttribute(attribute)) { - var value = element.getAttribute(attribute); - if (value === '' || value === 'true') { - return true; - } else if (value === 'false') { - return false; - } - } +function copyCode(elem){ + if (document.getElementById(elem)) { + // create hidden text element, if it doesn't already exist + var targetId = "_hiddenCopyText_"; + // must use a temporary form element for the selection and copy + target = document.getElementById(targetId); + if (!target) { + var target = document.createElement("textarea"); + target.style.position = "absolute"; + target.style.left = "-9999px"; + target.style.top = "0"; + target.id = targetId; + document.body.appendChild(target); + } + target.value = document.getElementById(elem).innerText; + // select the content + target.setSelectionRange(0, target.value.length); - return defaultValue; + // copy the selection + var succeed; + try { + succeed = document.execCommand("copy"); + } catch(e) { + sweetAlert("Oh, no...","Sorry, your browser doesn't support document.execCommand('copy'), so we can't copy this code to your clipboard."); + succeed = false; + } + if (succeed) sweetAlert("Copied to clipboard:",target.value); + return succeed; + } else { + sweetAlert("Oops!",elem + " not found when trying to copy code"); + return false; + } + } + +function booleanAttributeValue(element, attribute, defaultValue){ + // returns true if an attribute is present with no value + // e.g. booleanAttributeValue(element, 'data-modal', false); + if (element.hasAttribute(attribute)) { + var value = element.getAttribute(attribute); + if (value === '' || value === 'true') { + return true; + } else if (value === 'false') { + return false; + } + } + + return defaultValue; } function classOnCondition(element, className, condition) { - if (condition) - $(element).addClass(className); - else - $(element).removeClass(className); + if (condition) + $(element).addClass(className); + else + $(element).removeClass(className); } function highestZ() { - var Z = 1000; + var Z = 1000; - $("*").each(function(){ - var thisZ = $(this).css('z-index'); + $("*").each(function(){ + var thisZ = $(this).css('z-index'); - if (thisZ != "auto" && thisZ > Z) Z = ++thisZ; - }); + if (thisZ != "auto" && thisZ > Z) Z = ++thisZ; + }); - return Z; + return Z; } function newDOMElement(tag, className, id){ - var el = document.createElement(tag); + var el = document.createElement(tag); - if (className) el.className = className; - if (id) el.id = id; + if (className) el.className = className; + if (id) el.id = id; - return el; + return el; } function px(n){ - return n + 'px'; + return n + 'px'; } var kub = (function () { - var HEADER_HEIGHT; - var html, header, mainNav, quickstartButton, hero, encyclopedia, footer, headlineWrapper; + var HEADER_HEIGHT; + var html, header, mainNav, quickstartButton, hero, encyclopedia, footer, headlineWrapper; - $(document).ready(function () { - html = $('html'); - body = $('body'); - header = $('header'); - mainNav = $('#mainNav'); - quickstartButton = $('#quickstartButton'); - hero = $('#hero'); - encyclopedia = $('#encyclopedia'); - footer = $('footer'); - headlineWrapper = $('#headlineWrapper'); - HEADER_HEIGHT = header.outerHeight(); + $(document).ready(function () { + html = $('html'); + body = $('body'); + header = $('header'); + mainNav = $('#mainNav'); + quickstartButton = $('#quickstartButton'); + hero = $('#hero'); + encyclopedia = $('#encyclopedia'); + footer = $('footer'); + headlineWrapper = $('#headlineWrapper'); + HEADER_HEIGHT = header.outerHeight(); - resetTheView(); + resetTheView(); - window.addEventListener('resize', resetTheView); - window.addEventListener('scroll', resetTheView); - window.addEventListener('keydown', handleKeystrokes); + window.addEventListener('resize', resetTheView); + window.addEventListener('scroll', resetTheView); + window.addEventListener('keydown', handleKeystrokes); - document.onunload = function(){ - window.removeEventListener('resize', resetTheView); - window.removeEventListener('scroll', resetTheView); - window.removeEventListener('keydown', handleKeystrokes); - }; + document.onunload = function(){ + window.removeEventListener('resize', resetTheView); + window.removeEventListener('scroll', resetTheView); + window.removeEventListener('keydown', handleKeystrokes); + }; - setInterval(setFooterType, 10); - }); + setInterval(setFooterType, 10); + }); - function setFooterType() { - var windowHeight = window.innerHeight; - var bodyHeight; + function setFooterType() { + var windowHeight = window.innerHeight; + var bodyHeight; - switch (html[0].id) { - case 'docs': { - bodyHeight = hero.outerHeight() + encyclopedia.outerHeight(); - break; - } + switch (html[0].id) { + case 'docs': { + bodyHeight = hero.outerHeight() + encyclopedia.outerHeight(); + break; + } - case 'home': - // case 'caseStudies': - bodyHeight = windowHeight; - break; + case 'home': + // case 'caseStudies': + bodyHeight = windowHeight; + break; - case 'caseStudies': - case 'partners': - bodyHeight = windowHeight * 2; - break; + case 'caseStudies': + case 'partners': + bodyHeight = windowHeight * 2; + break; - default: { - bodyHeight = hero.outerHeight() + $('#mainContent').outerHeight(); - } - } + default: { + bodyHeight = hero.outerHeight() + $('#mainContent').outerHeight(); + } + } - var footerHeight = footer.outerHeight(); - classOnCondition(body, 'fixed', windowHeight - footerHeight > bodyHeight); - } + var footerHeight = footer.outerHeight(); + classOnCondition(body, 'fixed', windowHeight - footerHeight > bodyHeight); + } - function resetTheView() { - if (html.hasClass('open-nav')) { - toggleMenu(); - } else { - HEADER_HEIGHT = header.outerHeight(); - } + function resetTheView() { + if (html.hasClass('open-nav')) { + toggleMenu(); + } else { + HEADER_HEIGHT = header.outerHeight(); + } - if (html.hasClass('open-toc')) { - toggleToc(); - } + if (html.hasClass('open-toc')) { + toggleToc(); + } - classOnCondition(html, 'flip-nav', window.pageYOffset > 0); + classOnCondition(html, 'flip-nav', window.pageYOffset > 0); - if (html[0].id == 'home') { - setHomeHeaderStyles(); - } - } + if (html[0].id == 'home') { + setHomeHeaderStyles(); + } + } - function setHomeHeaderStyles() { - var Y = window.pageYOffset; - var quickstartBottom = quickstartButton[0].getBoundingClientRect().bottom; + function setHomeHeaderStyles() { + var Y = window.pageYOffset; + var quickstartBottom = quickstartButton[0].getBoundingClientRect().bottom; - classOnCondition(html[0], 'y-enough', Y > quickstartBottom); - } + classOnCondition(html[0], 'y-enough', Y > quickstartBottom); + } - function toggleMenu() { - if (window.innerWidth < 800) { - pushmenu.show('primary'); - } + function toggleMenu() { + if (window.innerWidth < 800) { + pushmenu.show('primary'); + } - else { - var newHeight = HEADER_HEIGHT; + else { + var newHeight = HEADER_HEIGHT; - if (!html.hasClass('open-nav')) { - newHeight = mainNav.outerHeight(); - } + if (!html.hasClass('open-nav')) { + newHeight = mainNav.outerHeight(); + } - header.css({height: px(newHeight)}); - html.toggleClass('open-nav'); - } - } + header.css({height: px(newHeight)}); + html.toggleClass('open-nav'); + } + } - function handleKeystrokes(e) { - switch (e.which) { - case 27: { - if (html.hasClass('open-nav')) { - toggleMenu(); - } - break; - } - } - } + function handleKeystrokes(e) { + switch (e.which) { + case 27: { + if (html.hasClass('open-nav')) { + toggleMenu(); + } + break; + } + } + } - function showVideo() { - $('body').css({overflow: 'hidden'}); + function showVideo() { + $('body').css({overflow: 'hidden'}); - var videoPlayer = $("#videoPlayer"); - var videoIframe = videoPlayer.find("iframe")[0]; - videoIframe.src = videoIframe.getAttribute("data-url"); - videoPlayer.css({zIndex: highestZ()}); - videoPlayer.fadeIn(300); - videoPlayer.click(function(){ - $('body').css({overflow: 'auto'}); + var videoPlayer = $("#videoPlayer"); + var videoIframe = videoPlayer.find("iframe")[0]; + videoIframe.src = videoIframe.getAttribute("data-url"); + videoPlayer.css({zIndex: highestZ()}); + videoPlayer.fadeIn(300); + videoPlayer.click(function(){ + $('body').css({overflow: 'auto'}); - videoPlayer.fadeOut(300, function(){ - videoIframe.src = ''; - }); - }); - } + videoPlayer.fadeOut(300, function(){ + videoIframe.src = ''; + }); + }); + } - function tocWasClicked(e) { - var target = $(e.target); - var docsToc = $("#docsToc"); - return (target[0] === docsToc[0] || target.parents("#docsToc").length > 0); - } + function tocWasClicked(e) { + var target = $(e.target); + var docsToc = $("#docsToc"); + return (target[0] === docsToc[0] || target.parents("#docsToc").length > 0); + } - function listenForTocClick(e) { - if (!tocWasClicked(e)) toggleToc(); - } + function listenForTocClick(e) { + if (!tocWasClicked(e)) toggleToc(); + } - function toggleToc() { - html.toggleClass('open-toc'); + function toggleToc() { + html.toggleClass('open-toc'); - setTimeout(function () { - if (html.hasClass('open-toc')) { - window.addEventListener('click', listenForTocClick); - } else { - window.removeEventListener('click', listenForTocClick); - } - }, 100); - } + setTimeout(function () { + if (html.hasClass('open-toc')) { + window.addEventListener('click', listenForTocClick); + } else { + window.removeEventListener('click', listenForTocClick); + } + }, 100); + } - return { - toggleToc: toggleToc, - toggleMenu: toggleMenu, - showVideo: showVideo - }; + return { + toggleToc: toggleToc, + toggleMenu: toggleMenu, + showVideo: showVideo + }; })(); // accordion (function(){ - var yah = true; - var moving = false; - var CSS_BROWSER_HACK_DELAY = 25; + var yah = true; + var moving = false; + var CSS_BROWSER_HACK_DELAY = 25; - $(document).ready(function(){ - // Safari chokes on the animation here, so... - if (navigator.userAgent.indexOf('Chrome') == -1 && navigator.userAgent.indexOf('Safari') != -1){ - var hackStyle = newDOMElement('style'); - hackStyle.innerHTML = '.pi-accordion .wrapper{transition: none}'; - body.append(hackStyle); - } - // Gross. + $(document).ready(function(){ + // Safari chokes on the animation here, so... + if (navigator.userAgent.indexOf('Chrome') == -1 && navigator.userAgent.indexOf('Safari') != -1){ + var hackStyle = newDOMElement('style'); + hackStyle.innerHTML = '.pi-accordion .wrapper{transition: none}'; + body.append(hackStyle); + } + // Gross. - $('.pi-accordion').each(function () { - var accordion = this; - var content = this.innerHTML; - var container = newDOMElement('div', 'container'); - container.innerHTML = content; - $(accordion).empty(); - accordion.appendChild(container); - CollapseBox($(container)); - }); + $('.pi-accordion').each(function () { + var accordion = this; + var content = this.innerHTML; + var container = newDOMElement('div', 'container'); + container.innerHTML = content; + $(accordion).empty(); + accordion.appendChild(container); + CollapseBox($(container)); + }); - setYAH(); + setYAH(); - setTimeout(function () { - yah = false; - }, 500); - }); + setTimeout(function () { + yah = false; + }, 500); + }); - function CollapseBox(container){ - container.children('.item').each(function(){ - // build the TOC DOM - // the animated open/close is enabled by having each item's content exist in the flow, at its natural height, - // enclosed in a wrapper with height = 0 when closed, and height = contentHeight when open. - var item = this; + function CollapseBox(container){ + container.children('.item').each(function(){ + // build the TOC DOM + // the animated open/close is enabled by having each item's content exist in the flow, at its natural height, + // enclosed in a wrapper with height = 0 when closed, and height = contentHeight when open. + var item = this; - // only add content wrappers to containers, not to links - var isContainer = item.tagName === 'DIV'; + // only add content wrappers to containers, not to links + var isContainer = item.tagName === 'DIV'; - var titleText = item.getAttribute('data-title'); - var title = newDOMElement('div', 'title'); - title.innerHTML = titleText; + var titleText = item.getAttribute('data-title'); + var title = newDOMElement('div', 'title'); + title.innerHTML = titleText; - var wrapper, content; + var wrapper, content; - if (isContainer) { - wrapper = newDOMElement('div', 'wrapper'); - content = newDOMElement('div', 'content'); - content.innerHTML = item.innerHTML; - wrapper.appendChild(content); - } + if (isContainer) { + wrapper = newDOMElement('div', 'wrapper'); + content = newDOMElement('div', 'content'); + content.innerHTML = item.innerHTML; + wrapper.appendChild(content); + } - item.innerHTML = ''; - item.appendChild(title); + item.innerHTML = ''; + item.appendChild(title); - if (wrapper) { - item.appendChild(wrapper); - $(wrapper).css({height: 0}); - } + if (wrapper) { + item.appendChild(wrapper); + $(wrapper).css({height: 0}); + } - $(title).click(function(){ - if (!yah) { - if (moving) return; - moving = true; - } + $(title).click(function(){ + if (!yah) { + if (moving) return; + moving = true; + } - if (container[0].getAttribute('data-single')) { - var openSiblings = item.siblings().filter(function(sib){return sib.hasClass('on');}); - openSiblings.forEach(function(sibling){ - toggleItem(sibling); - }); - } + if (container[0].getAttribute('data-single')) { + var openSiblings = item.siblings().filter(function(sib){return sib.hasClass('on');}); + openSiblings.forEach(function(sibling){ + toggleItem(sibling); + }); + } - setTimeout(function(){ - if (!isContainer) { - moving = false; - return; - } - toggleItem(item); - }, CSS_BROWSER_HACK_DELAY); - }); + setTimeout(function(){ + if (!isContainer) { + moving = false; + return; + } + toggleItem(item); + }, CSS_BROWSER_HACK_DELAY); + }); - function toggleItem(thisItem){ - var thisWrapper = $(thisItem).find('.wrapper').eq(0); + function toggleItem(thisItem){ + var thisWrapper = $(thisItem).find('.wrapper').eq(0); - if (!thisWrapper) return; + if (!thisWrapper) return; - var contentHeight = thisWrapper.find('.content').eq(0).innerHeight() + 'px'; + var contentHeight = thisWrapper.find('.content').eq(0).innerHeight() + 'px'; - if ($(thisItem).hasClass('on')) { - thisWrapper.css({height: contentHeight}); - $(thisItem).removeClass('on'); + if ($(thisItem).hasClass('on')) { + thisWrapper.css({height: contentHeight}); + $(thisItem).removeClass('on'); - setTimeout(function(){ - thisWrapper.css({height: 0}); - moving = false; - }, CSS_BROWSER_HACK_DELAY); - } else { - $(item).addClass('on'); - thisWrapper.css({height: contentHeight}); + setTimeout(function(){ + thisWrapper.css({height: 0}); + moving = false; + }, CSS_BROWSER_HACK_DELAY); + } else { + $(item).addClass('on'); + thisWrapper.css({height: contentHeight}); - var duration = parseFloat(getComputedStyle(thisWrapper[0]).transitionDuration) * 1000; + var duration = parseFloat(getComputedStyle(thisWrapper[0]).transitionDuration) * 1000; - setTimeout(function(){ - thisWrapper.css({height: ''}); - moving = false; - }, duration); - } - } + setTimeout(function(){ + thisWrapper.css({height: ''}); + moving = false; + }, duration); + } + } - if (content) { - var innerContainers = $(content).children('.container'); - if (innerContainers.length > 0) { - innerContainers.each(function(){ - CollapseBox($(this)); - }); - } - } - }); - } + if (content) { + var innerContainers = $(content).children('.container'); + if (innerContainers.length > 0) { + innerContainers.each(function(){ + CollapseBox($(this)); + }); + } + } + }); + } - function setYAH() { - var pathname = location.href.split('#')[0]; // on page load, make sure the page is YAH even if there's a hash - var currentLinks = []; + function setYAH() { + var pathname = location.href.split('#')[0]; // on page load, make sure the page is YAH even if there's a hash + var currentLinks = []; - $('.pi-accordion a').each(function () { - if (pathname === this.href) currentLinks.push(this); - }); + $('.pi-accordion a').each(function () { + if (pathname === this.href) currentLinks.push(this); + }); - currentLinks.forEach(function (yahLink) { - $(yahLink).parents('.item').each(function(){ - $(this).addClass('on'); - $(this).find('.wrapper').eq(0).css({height: 'auto'}); - $(this).find('.content').eq(0).css({opacity: 1}); - }); + currentLinks.forEach(function (yahLink) { + $(yahLink).parents('.item').each(function(){ + $(this).addClass('on'); + $(this).find('.wrapper').eq(0).css({height: 'auto'}); + $(this).find('.content').eq(0).css({opacity: 1}); + }); - $(yahLink).addClass('yah'); - yahLink.onclick = function(e){e.preventDefault();}; - }); - } + $(yahLink).addClass('yah'); + yahLink.onclick = function(e){e.preventDefault();}; + }); + } })(); var pushmenu = (function(){ - var allPushMenus = {}; + var allPushMenus = {}; - $(document).ready(function(){ - $('[data-auto-burger]').each(function(){ - var container = this; - var id = container.getAttribute('data-auto-burger'); + $(document).ready(function(){ + $('[data-auto-burger]').each(function(){ + var container = this; + var id = container.getAttribute('data-auto-burger'); - var autoBurger = document.getElementById(id) || newDOMElement('div', 'pi-pushmenu', id); - var ul = autoBurger.querySelector('ul') || newDOMElement('ul'); + var autoBurger = document.getElementById(id) || newDOMElement('div', 'pi-pushmenu', id); + var ul = autoBurger.querySelector('ul') || newDOMElement('ul'); - $(container).find('a[href], button').each(function () { - if (!booleanAttributeValue(this, 'data-auto-burger-exclude', false)) { - var clone = this.cloneNode(true); - clone.id = ''; + $(container).find('a[href], button').each(function () { + if (!booleanAttributeValue(this, 'data-auto-burger-exclude', false)) { + var clone = this.cloneNode(true); + clone.id = ''; - if (clone.tagName == "BUTTON") { - var aTag = newDOMElement('a'); - aTag.href = ''; - aTag.innerHTML = clone.innerHTML; - aTag.onclick = clone.onclick; - clone = aTag; - } - var li = newDOMElement('li'); - li.appendChild(clone); - ul.appendChild(li); - } - }); + if (clone.tagName == "BUTTON") { + var aTag = newDOMElement('a'); + aTag.href = ''; + aTag.innerHTML = clone.innerHTML; + aTag.onclick = clone.onclick; + clone = aTag; + } + var li = newDOMElement('li'); + li.appendChild(clone); + ul.appendChild(li); + } + }); - autoBurger.appendChild(ul); - body.append(autoBurger); - }); + autoBurger.appendChild(ul); + body.append(autoBurger); + }); - $(".pi-pushmenu").each(function(){ - allPushMenus[this.id] = PushMenu(this); - }); - }); + $(".pi-pushmenu").each(function(){ + allPushMenus[this.id] = PushMenu(this); + }); + }); - function show(objId) { - allPushMenus[objId].expose(); - } + function show(objId) { + allPushMenus[objId].expose(); + } - function PushMenu(el) { - var html = document.querySelector('html'); + function PushMenu(el) { + var html = document.querySelector('html'); - var overlay = newDOMElement('div', 'overlay'); - var content = newDOMElement('div', 'content'); - content.appendChild(el.querySelector('*')); + var overlay = newDOMElement('div', 'overlay'); + var content = newDOMElement('div', 'content'); + content.appendChild(el.querySelector('*')); - var side = el.getAttribute("data-side") || "right"; + var side = el.getAttribute("data-side") || "right"; - var sled = newDOMElement('div', 'sled'); - $(sled).css(side, 0); + var sled = newDOMElement('div', 'sled'); + $(sled).css(side, 0); - sled.appendChild(content); + sled.appendChild(content); - var closeButton = newDOMElement('button', 'push-menu-close-button'); - closeButton.onclick = closeMe; + var closeButton = newDOMElement('button', 'push-menu-close-button'); + closeButton.onclick = closeMe; - sled.appendChild(closeButton); + sled.appendChild(closeButton); - overlay.appendChild(sled); - el.innerHTML = ''; - el.appendChild(overlay); + overlay.appendChild(sled); + el.innerHTML = ''; + el.appendChild(overlay); - sled.onclick = function(e){ - e.stopPropagation(); - }; + sled.onclick = function(e){ + e.stopPropagation(); + }; - overlay.onclick = closeMe; + overlay.onclick = closeMe; - window.addEventListener('resize', closeMe); + window.addEventListener('resize', closeMe); - function closeMe(e) { - if (e.target == sled) return; + function closeMe(e) { + if (e.target == sled) return; - $(el).removeClass('on'); - setTimeout(function(){ - $(el).css({display: 'none'}); + $(el).removeClass('on'); + setTimeout(function(){ + $(el).css({display: 'none'}); - $(body).removeClass('overlay-on'); - }, 300); - } + $(body).removeClass('overlay-on'); + }, 300); + } - function exposeMe(){ - $(body).addClass('overlay-on'); // in the default config, kills body scrolling + function exposeMe(){ + $(body).addClass('overlay-on'); // in the default config, kills body scrolling - $(el).css({ - display: 'block', - zIndex: highestZ() - }); + $(el).css({ + display: 'block', + zIndex: highestZ() + }); - setTimeout(function(){ - $(el).addClass('on'); - }, 10); - } + setTimeout(function(){ + $(el).addClass('on'); + }, 10); + } - return { - expose: exposeMe - }; - } + return { + expose: exposeMe + }; + } - return { - show: show - }; + return { + show: show + }; })(); $(function() { - - // Make global nav be active based on pathname - if ((location.pathname.split("/")[1]) !== ""){ + + // Make global nav be active based on pathname + if ((location.pathname.split("/")[1]) !== ""){ $('.global-nav li a[href^="/' + location.pathname.split("/")[1] + '"]').addClass('active'); } - // If vendor strip doesn't exist add className - if ( !$('#vendorStrip').length > 0 ) { - $('#hero').addClass('bot-bar'); - } + // If vendor strip doesn't exist add className + if ( !$('#vendorStrip').length > 0 ) { + $('#hero').addClass('bot-bar'); + } - // If is not homepage add class to hero section - if (!$('#home').length > 0 ) { - $('#hero').addClass('no-sub'); - } + // If is not homepage add class to hero section + if (!$('#home').length > 0 ) { + $('#hero').addClass('no-sub'); + } }); \ No newline at end of file From 78e7b40600c292c7d2d3e44634db991506153d38 Mon Sep 17 00:00:00 2001 From: foliage Date: Tue, 27 Dec 2016 22:34:14 +0800 Subject: [PATCH 50/68] update jobs-expansions-index.md change the wrong url change the wrong template --- docs/user-guide/jobs/expansions/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/user-guide/jobs/expansions/index.md b/docs/user-guide/jobs/expansions/index.md index 70eb90a623..c7a7a8b76f 100644 --- a/docs/user-guide/jobs/expansions/index.md +++ b/docs/user-guide/jobs/expansions/index.md @@ -109,7 +109,7 @@ Processing item cherry In the first example, each instance of the template had one parameter, and that parameter was also used as a label. However label keys are limited in [what characters they can -contain](docs/user-guide/labels/#syntax-and-character-set). +contain](/docs/user-guide/labels/#syntax-and-character-set). This slightly more complex example uses a the jinja2 template language to generate our objects. We will use a one-line python script to convert the template to a file. @@ -128,7 +128,7 @@ First, copy and paste the following template of a Job object, into a file called apiVersion: batch/v1 kind: Job metadata: - name: jobexample-{{ {{ name }} }} + name: jobexample-{{ name }} labels: jobgroup: jobexample spec: From a168c92e30d6c565f6cecd219523b3d1b3a50e59 Mon Sep 17 00:00:00 2001 From: Janet Kuo Date: Tue, 27 Dec 2016 11:22:52 -0800 Subject: [PATCH 51/68] Add TOC entries for all kubectl docs Kubectl docs: add TOC entries, and remove obsolete docs --- _data/reference.yml | 25 +++++++++++++++++++++ docs/user-guide/kubectl/kubectl_top-node.md | 9 -------- docs/user-guide/kubectl/kubectl_top-pod.md | 9 -------- 3 files changed, 25 insertions(+), 18 deletions(-) delete mode 100644 docs/user-guide/kubectl/kubectl_top-node.md delete mode 100644 docs/user-guide/kubectl/kubectl_top-pod.md diff --git a/_data/reference.yml b/_data/reference.yml index dd095d623e..475d87d10c 100644 --- a/_data/reference.yml +++ b/_data/reference.yml @@ -54,9 +54,18 @@ toc: - docs/user-guide/kubectl/kubectl_apply.md - docs/user-guide/kubectl/kubectl_attach.md - docs/user-guide/kubectl/kubectl_autoscale.md + - docs/user-guide/kubectl/kubectl_certificate.md + - docs/user-guide/kubectl/kubectl_certificate_approve.md + - docs/user-guide/kubectl/kubectl_certificate_deny.md - docs/user-guide/kubectl/kubectl_cluster-info.md + - docs/user-guide/kubectl/kubectl_cluster-info_dump.md + - docs/user-guide/kubectl/kubectl_completion.md - docs/user-guide/kubectl/kubectl_config.md - docs/user-guide/kubectl/kubectl_config_current-context.md + - docs/user-guide/kubectl/kubectl_config_delete-cluster.md + - docs/user-guide/kubectl/kubectl_config_delete-context.md + - docs/user-guide/kubectl/kubectl_config_get-clusters.md + - docs/user-guide/kubectl/kubectl_config_get-contexts.md - docs/user-guide/kubectl/kubectl_config_set-cluster.md - docs/user-guide/kubectl/kubectl_config_set-context.md - docs/user-guide/kubectl/kubectl_config_set-credentials.md @@ -66,13 +75,20 @@ toc: - docs/user-guide/kubectl/kubectl_config_view.md - docs/user-guide/kubectl/kubectl_convert.md - docs/user-guide/kubectl/kubectl_cordon.md + - docs/user-guide/kubectl/kubectl_cp.md - docs/user-guide/kubectl/kubectl_create.md - docs/user-guide/kubectl/kubectl_create_configmap.md + - docs/user-guide/kubectl/kubectl_create_deployment.md - docs/user-guide/kubectl/kubectl_create_namespace.md + - docs/user-guide/kubectl/kubectl_create_quota.md - docs/user-guide/kubectl/kubectl_create_secret_docker-registry.md - docs/user-guide/kubectl/kubectl_create_secret.md - docs/user-guide/kubectl/kubectl_create_secret_generic.md + - docs/user-guide/kubectl/kubectl_create_secret_tls.md - docs/user-guide/kubectl/kubectl_create_serviceaccount.md + - docs/user-guide/kubectl/kubectl_create_service_clusterip.md + - docs/user-guide/kubectl/kubectl_create_service_loadbalancer.md + - docs/user-guide/kubectl/kubectl_create_service_nodeport.md - docs/user-guide/kubectl/kubectl_delete.md - docs/user-guide/kubectl/kubectl_describe.md - docs/user-guide/kubectl/kubectl_drain.md @@ -83,6 +99,7 @@ toc: - docs/user-guide/kubectl/kubectl_get.md - docs/user-guide/kubectl/kubectl_label.md - docs/user-guide/kubectl/kubectl_logs.md + - docs/user-guide/kubectl/kubectl_options.md - docs/user-guide/kubectl/kubectl_patch.md - docs/user-guide/kubectl/kubectl_port-forward.md - docs/user-guide/kubectl/kubectl_proxy.md @@ -92,9 +109,17 @@ toc: - docs/user-guide/kubectl/kubectl_rollout_history.md - docs/user-guide/kubectl/kubectl_rollout_pause.md - docs/user-guide/kubectl/kubectl_rollout_resume.md + - docs/user-guide/kubectl/kubectl_rollout_status.md - docs/user-guide/kubectl/kubectl_rollout_undo.md - docs/user-guide/kubectl/kubectl_run.md - docs/user-guide/kubectl/kubectl_scale.md + - docs/user-guide/kubectl/kubectl_set.md + - docs/user-guide/kubectl/kubectl_set_image.md + - docs/user-guide/kubectl/kubectl_set_resources.md + - docs/user-guide/kubectl/kubectl_taint.md + - docs/user-guide/kubectl/kubectl_top.md + - docs/user-guide/kubectl/kubectl_top_node.md + - docs/user-guide/kubectl/kubectl_top_pod.md - docs/user-guide/kubectl/kubectl_uncordon.md - docs/user-guide/kubectl/kubectl_version.md - title: Superseded and Deprecated Commands diff --git a/docs/user-guide/kubectl/kubectl_top-node.md b/docs/user-guide/kubectl/kubectl_top-node.md deleted file mode 100644 index 72e6b47239..0000000000 --- a/docs/user-guide/kubectl/kubectl_top-node.md +++ /dev/null @@ -1,9 +0,0 @@ ---- ---- -This file is autogenerated, but we've stopped checking such files into the -repository to reduce the need for rebases. Please run hack/generate-docs.sh to -populate this file. - - -[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/user-guide/kubectl/kubectl_top-node.md?pixel)]() - diff --git a/docs/user-guide/kubectl/kubectl_top-pod.md b/docs/user-guide/kubectl/kubectl_top-pod.md deleted file mode 100644 index 344b1c2b44..0000000000 --- a/docs/user-guide/kubectl/kubectl_top-pod.md +++ /dev/null @@ -1,9 +0,0 @@ ---- ---- -This file is autogenerated, but we've stopped checking such files into the -repository to reduce the need for rebases. Please run hack/generate-docs.sh to -populate this file. - - -[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/user-guide/kubectl/kubectl_top-pod.md?pixel)]() - From 193fdfa4e9d1e1a07f742d8f5fea9ae5dc608bba Mon Sep 17 00:00:00 2001 From: Anirudh Date: Tue, 27 Dec 2016 11:43:31 -0800 Subject: [PATCH 52/68] Added poddisruptionbudget and abbreviation to list --- docs/user-guide/kubectl-overview.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/user-guide/kubectl-overview.md b/docs/user-guide/kubectl-overview.md index 99c1575e84..f9a88f7450 100644 --- a/docs/user-guide/kubectl-overview.md +++ b/docs/user-guide/kubectl-overview.md @@ -99,6 +99,7 @@ Resource type | Abbreviated alias `nodes` |`no` `persistentvolumeclaims` |`pvc` `persistentvolumes` |`pv` +`poddisruptionbudget` |`pdb` `pods` |`po` `podsecuritypolicies` |`psp` `podtemplates` | From 93bbce56aed68aca2f7730dd74784e87cd88d8bc Mon Sep 17 00:00:00 2001 From: Anirudh Date: Tue, 27 Dec 2016 11:56:00 -0800 Subject: [PATCH 53/68] Add statefulsets also to list --- docs/user-guide/kubectl-overview.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/user-guide/kubectl-overview.md b/docs/user-guide/kubectl-overview.md index f9a88f7450..2fa249c5f6 100644 --- a/docs/user-guide/kubectl-overview.md +++ b/docs/user-guide/kubectl-overview.md @@ -109,6 +109,7 @@ Resource type | Abbreviated alias `secrets` | `serviceaccounts` |`sa` `services` |`svc` +`statefulsets` | `storageclasses` | `thirdpartyresources` | From 7bde7d9cfc9efbbbd4a275d5d286c7442026791b Mon Sep 17 00:00:00 2001 From: Yuri Khrustalev Date: Tue, 27 Dec 2016 23:03:02 +0300 Subject: [PATCH 54/68] Gondor renamed itself to Eldarion http://eldarion.cloud/blog/2016/04/21/goodbye-gondor-hello-kel-and-eldarion-cloud/ --- docs/whatisk8s.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/whatisk8s.md b/docs/whatisk8s.md index 7c1e637b6d..11ab91f87f 100644 --- a/docs/whatisk8s.md +++ b/docs/whatisk8s.md @@ -106,7 +106,7 @@ Kubernetes is not a traditional, all-inclusive PaaS (Platform as a Service) syst * Kubernetes does not provide nor mandate a comprehensive application configuration language/system (e.g., [jsonnet](https://github.com/google/jsonnet)). * Kubernetes does not provide nor adopt any comprehensive machine configuration, maintenance, management, or self-healing systems. -On the other hand, a number of PaaS systems run *on* Kubernetes, such as [Openshift](https://github.com/openshift/origin), [Deis](http://deis.io/), and [Gondor](https://gondor.io/). You could also roll your own custom PaaS, integrate with a CI system of your choice, or get along just fine with just Kubernetes: bring your container images and deploy them on Kubernetes. +On the other hand, a number of PaaS systems run *on* Kubernetes, such as [Openshift](https://github.com/openshift/origin), [Deis](http://deis.io/), and [Eldarion](http://eldarion.cloud/). You could also roll your own custom PaaS, integrate with a CI system of your choice, or get along just fine with just Kubernetes: bring your container images and deploy them on Kubernetes. Since Kubernetes operates at the application level rather than at just the hardware level, it provides some generally applicable features common to PaaS offerings, such as deployment, scaling, load balancing, logging, monitoring, etc. However, Kubernetes is not monolithic, and these default solutions are optional and pluggable. From 007510edc1c9fc00e1ca429ff8b3c2fe93d45e05 Mon Sep 17 00:00:00 2001 From: devin-donnelly Date: Tue, 27 Dec 2016 13:25:29 -0800 Subject: [PATCH 55/68] Update index.md --- docs/user-guide/persistent-volumes/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/persistent-volumes/index.md b/docs/user-guide/persistent-volumes/index.md index 71ac6762cf..eefb188f28 100644 --- a/docs/user-guide/persistent-volumes/index.md +++ b/docs/user-guide/persistent-volumes/index.md @@ -70,7 +70,7 @@ When a user is done with their volume, they can delete the PVC objects from the ### Reclaiming -The reclaim policy for a `PersistentVolume` tells the cluster what to do with the volume after it has been released of its claim. Currently, volumes can either be Retained, Recycled or Deleted. Retention allows for manual reclamation of the resource. For those volume plugins that support it, deletion removes both the `PersistentVolume` object from Kubernetes as well as deletes associated storage asset in external infrastructure such as AWS EBS, GCE PD, Azure Disk, or Cinder volume. Volumes that were dynamically provisioned are always deleted. +The reclaim policy for a `PersistentVolume` tells the cluster what to do with the volume after it has been released of its claim. Currently, volumes can either be Retained, Recycled or Deleted. Retention allows for manual reclamation of the resource. For those volume plugins that support it, deletion removes both the `PersistentVolume` object from Kubernetes, as well as deleting the associated storage asset in external infrastructure (such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume). Volumes that were dynamically provisioned are always deleted. #### Recycling From f342733ff5bfcef9b1153fad01eb5becb1ca9b15 Mon Sep 17 00:00:00 2001 From: timcrall Date: Tue, 27 Dec 2016 13:34:54 -0800 Subject: [PATCH 56/68] Update basic-stateful-set.md (#2060) yaml, not yml --- docs/tutorials/stateful-application/basic-stateful-set.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/tutorials/stateful-application/basic-stateful-set.md b/docs/tutorials/stateful-application/basic-stateful-set.md index 07e41cd56d..c0b0199216 100644 --- a/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/docs/tutorials/stateful-application/basic-stateful-set.md @@ -77,7 +77,7 @@ In the second terminal, use Headless Service and StatefulSet defined in `web.yaml`. ```shell -kubectl create -f web.yml +kubectl create -f web.yaml service "nginx" created statefulset "web" created ``` @@ -733,4 +733,4 @@ storage configuration, and provisioning method, to ensure that all storage is reclaimed. {% endcapture %} -{% include templates/tutorial.md %} \ No newline at end of file +{% include templates/tutorial.md %} From 322486bc4f357a725bb987c420901b388e5b6e61 Mon Sep 17 00:00:00 2001 From: chenopis Date: Tue, 27 Dec 2016 14:17:16 -0800 Subject: [PATCH 57/68] fix typo: remove "the the" in zookeeper.md In Managing the ZooKeeper Process : Handling Process Failure : paragraph 4 : "The command used as the container's entry point has PID 1, and the the ZooKeeper process, a child of the entry point, has PID 23." => "The command used as the container's entry point has PID 1, and the ZooKeeper process, a child of the entry point, has PID 23." --- docs/tutorials/stateful-application/zookeeper.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tutorials/stateful-application/zookeeper.md b/docs/tutorials/stateful-application/zookeeper.md index c6dcf705be..44ae82e668 100644 --- a/docs/tutorials/stateful-application/zookeeper.md +++ b/docs/tutorials/stateful-application/zookeeper.md @@ -799,7 +799,7 @@ Examine the process tree for the ZooKeeper server running in the `zk-0` Pod. kubectl exec zk-0 -- ps -ef ``` -The command used as the container's entry point has PID 1, and the +The command used as the container's entry point has PID 1, and the ZooKeeper process, a child of the entry point, has PID 23. From 86b76fffba2bb41570acb783a0e6141373de0220 Mon Sep 17 00:00:00 2001 From: Bill Prin Date: Mon, 12 Dec 2016 22:36:19 -0800 Subject: [PATCH 58/68] Minikube Quickstart --- _data/tutorials.yml | 1 + .../stateless-application/Dockerfile | 4 + .../stateless-application/hello-minikube.md | 305 ++++++++++++++++++ .../tutorials/stateless-application/server.js | 7 + 4 files changed, 317 insertions(+) create mode 100644 docs/tutorials/stateless-application/Dockerfile create mode 100644 docs/tutorials/stateless-application/hello-minikube.md create mode 100644 docs/tutorials/stateless-application/server.js diff --git a/_data/tutorials.yml b/_data/tutorials.yml index a4ff243bfb..08e8b0b46a 100644 --- a/_data/tutorials.yml +++ b/_data/tutorials.yml @@ -31,6 +31,7 @@ toc: - docs/tutorials/kubernetes-basics/update-interactive.html - title: Stateless Applications section: + - docs/tutorials/stateless-application/hello-minikube.md - docs/tutorials/stateless-application/run-stateless-application-deployment.md - docs/tutorials/stateless-application/expose-external-ip-address-service.md - docs/tutorials/stateless-application/expose-external-ip-address.md diff --git a/docs/tutorials/stateless-application/Dockerfile b/docs/tutorials/stateless-application/Dockerfile new file mode 100644 index 0000000000..34b1f40f52 --- /dev/null +++ b/docs/tutorials/stateless-application/Dockerfile @@ -0,0 +1,4 @@ +FROM node:6.9.2 +EXPOSE 8080 +COPY server.js . +CMD node server.js diff --git a/docs/tutorials/stateless-application/hello-minikube.md b/docs/tutorials/stateless-application/hello-minikube.md new file mode 100644 index 0000000000..dad7158ac3 --- /dev/null +++ b/docs/tutorials/stateless-application/hello-minikube.md @@ -0,0 +1,305 @@ +{% capture overview %} + +The goal of this tutorial is for you to turn a simple Hello World Node.js app +into an application running on Kubernetes. The tutorial shows you how to +take code that you have developed on your machine, turn it into a Docker +container image and then run that image on [Minikube](/docs/getting-started-guides/minikube). +Minikube provides a simple way of running Kubernetes on your local machine for free. + +{% endcapture %} + +{% capture objectives %} + +* Run a hello world Node.js application. +* Deploy the application to Minikube. +* View application logs. +* Update the application image. + + +{% endcapture %} + +{% capture prerequisites %} + +* For OS X, you need [Homebrew](https://brew.sh) to install the `xhyve` +driver. + +* [NodeJS](https://nodejs.org/en/) is required to run the sample application. + +* Install Docker. On OS X, we recommend +[Docker for Mac](https://docs.docker.com/engine/installation/mac/). + + +{% endcapture %} + +{% capture lessoncontent %} + +### Create a Minikube cluster + +This tutorial uses [Minikube](https://github.com/kubernetes/minikube) to +create a local cluster. This tutorial also assumes you are using +[Docker for Mac](https://docs.docker.com/engine/installation/mac/) +on OS X. If you are on a different platform like Linux, or using VirtualBox +instead of Docker for Mac, the instructions to install Minikube may be +slightly different. For general Minikube installation instructions, see +the [Minikube installation guide](docs/getting-started-guides/minikube/). + +Use `curl` to download and install the latest Minikube release: + +```shell +curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/ +``` + +Use Homebrew to install the xhyve driver and set its permissions: + +```shell +brew install docker-machine-driver-xhyve +sudo chown root:wheel $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve +sudo chmod u+s $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve +``` + +Download the latest version of the `kubectl` command-line tool, which you can +use to interact with Kubernetes clusters: + +```shell +curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl +chmod +x ./kubectl +sudo mv ./kubectl /usr/local/bin/kubectl +``` + +Start the Minikube cluster: + +```shell +minikube start --vm-driver=xhyve +``` + +The `--vm-driver=xyhve` flag specifies that you are using Docker for Mac. The +default VM driver is VirtualBox. + +Now set the Minikube context. The context is what determines which cluster +`kubectl` is interacting with. You can see all your available contexts in the +`~/.kube/config` file. + +```shell +kubectl config use-context minikube +``` + +Verify that `kubectl` is configured to communicate with your cluster: + +```shell +kubectl cluster-info +``` + +### Create your Node.js application + +The next step is to write the application. Save this code in a folder named `hellonode` +with the filename `server.js`: + +{% include code.html language="js" file="server.js" ghlink="docs/tutorials/stateless-application/server.js" %} + +Run your application: + +```shell +node server.js +``` + +You should be able to see your "Hello World!" message at http://localhost:8080/. + +Stop the running Node.js server by pressing **Ctrl-C**. + +The next step is to package your application in a Docker container. + +### Create a Docker container image + +Create a file, also in the `hellonode` folder, named `Dockerfile`. A Dockerfile describes +the image that you want to build. You can build a Docker container image by extending an +existing image. The image in this tutorial extends an existing Node.js image. + +{% include code.html language="conf" file="Dockerfile" ghlink="/docs/tutorials/stateless-application/Dockerfile" %} + +This recipe for the Docker image starts from the official Node.js LTS image +found in the Docker registry, exposes port 8080, copies your `server.js` file +to the image and start the Node.js server. + +Because this tutorial uses Minikube, instead of pushing your Docker image to a +registry, you can simply build the image using the same Docker host as +the Minikube VM, so that the images are automatically present. To do so, make +sure you are using the Minikube Docker daemon: + +```shell +eval $(minikube docker-env) +``` + +**Note:** Later, when you no longer wish to use the Minikube host, you can undo +this change by running `eval $(minikube docker-env) -u`. + +Build your Docker image, using the Minikube Docker daemon: + +```shell +docker build -t hello-node:v1 . +``` + +Now the Minikube VM can run the image you built. + +### Create a Deployment + +A Kubernetes [*Pod*](/docs/user-guide/pods/) is a group of one or more Containers, +tied together for the purposes of administration and networking. The Pod in this +tutorial has only one Container. A Kubernetes +[*Deployment*](/docs/user-guide/deployments) checks on the health of your +Pod and restarts the Pod's Container if it terminates. Deployments are the +recommended way to manage the creation and scaling of Pods. + +Use the `kubectl run` command to create a Deployment that manages a Pod. The +Pod runs a Container based on your `hello-node:v1` Docker image: + +```shell +kubectl run hello-node --image=hello-node:v1 --port=8080 +``` + +View the Deployment: + + +```shell +kubectl get deployments +``` + +Output: + + +```shell +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +hello-node 1 1 1 1 3m +``` + +View the Pod: + + +```shell +kubectl get pods +``` + +Output: + + +```shell +NAME READY STATUS RESTARTS AGE +hello-node-714049816-ztzrb 1/1 Running 0 6m +``` + +View cluster events: + +```shell +kubectl get events +``` + +View the `kubectl` configuration: + +```shell +kubectl config view +``` + +For more information about `kubectl`commands, see the +[kubectl overview](/docs/user-guide/kubectl-overview/). + +### Create a Service + +By default, the Pod is only accessible by its internal IP address within the +Kubernetes cluster. To make the `hello-node` Container accessible from outside the +Kubernetes virtual network, you have to expose the Pod as a +Kubernetes [*Service*](/docs/user-guide/services/). + +From your development machine, you can expose the Pod to the public internet +using the `kubectl expose` command: + +```shell +kubectl expose deployment hello-node --type=LoadBalancer +``` + +View the Service you just created: + +```shell +kubectl get services +``` + +Output: + +```shell +NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE +hello-node 10.0.0.71 8080/TCP 6m +kubernetes 10.0.0.1 443/TCP 14d +``` + +The `--type=LoadBalancer` flag indicates that you want to expose your Service +outside of the cluster. On cloud providers that support load balancers, +an external IP address would be provisioned to access the Service. On Minikube, +the `LoadBalancer` type makes the Service accessible through the `minikube service` +command. + +```shell +minikube service hello-node +``` + +This automatically opens up a browser window using a local IP address that +serves your app and shows the "Hello World" message. + +Assuming you've sent requests to your new web service using the browser or curl, +you should now be able to see some logs: + +```shell +kubectl logs +``` + +### Update your app + +Edit your `server.js` file to return a new message: + +```javascript +response.end('Hello World Again!'); + +``` + +Build a new version of your image: + +```shell +docker build -t hello-node:v2 . +``` + +Update the image of your Deployment: + +```shell +kubectl set image deployment/hello-node hello-node=hello-node:v2 +``` + +Run your app again to view the new message: + +```shell +minikube service hello-node +``` + +### Clean up + +Now you can clean up the resources you created in your cluster: + +```shell +kubectl delete service hello-node +kubectl delete deployment hello-node +``` + +Optionally, stop Minikube: + +```shell +minikube stop +``` + +{% endcapture %} + + +{% capture whatsnext %} + +* Learn more about [Deployment objects](/docs/user-guide/deployments/). +* Learn more about [Deploying applications](http://localhost:4000/docs/user-guide/deploying-applications/). +* Learn more about [Service objects](/docs/user-guide/services/). + +{% endcapture %} + +{% include templates/tutorial.md %} diff --git a/docs/tutorials/stateless-application/server.js b/docs/tutorials/stateless-application/server.js new file mode 100644 index 0000000000..4a31299886 --- /dev/null +++ b/docs/tutorials/stateless-application/server.js @@ -0,0 +1,7 @@ +var handleRequest = function(request, response) { + console.log('Received request for URL: ' + request.url); + response.writeHead(200); + response.end('Hello World!'); +}; +var www = http.createServer(handleRequest); +www.listen(8080); From 2cc0485a7093c3d0e0fe6c77c62169234f66f826 Mon Sep 17 00:00:00 2001 From: gbzhu Date: Wed, 28 Dec 2016 17:48:46 +0800 Subject: [PATCH 59/68] fix typos --- README.md | 2 +- docs/admin/cluster-management.md | 2 +- docs/admin/federation/index.md | 4 ++-- docs/admin/garbage-collection.md | 2 +- docs/admin/index.md | 6 ++--- docs/admin/kube-controller-manager.md | 4 ++-- docs/admin/kube-proxy.md | 4 ++-- docs/admin/kube-scheduler.md | 4 ++-- docs/admin/kubelet.md | 6 ++--- docs/admin/multi-cluster.md | 2 +- docs/admin/namespaces/walkthrough.md | 2 +- docs/admin/node.md | 2 +- docs/api-reference/README.md | 2 +- .../labels-annotations-taints.md | 4 ++-- docs/getting-started-guides/clc.md | 10 ++++----- .../fedora/fedora_ansible_config.md | 8 +++---- .../fedora/fedora_manual_config.md | 2 +- docs/getting-started-guides/kubectl.md | 2 +- docs/getting-started-guides/minikube.md | 6 ++--- docs/getting-started-guides/scratch.md | 2 +- docs/getting-started-guides/ubuntu/manual.md | 14 ++++++------ .../deleting-a-statefulset.md | 2 +- docs/troubleshooting.md | 2 +- docs/user-guide/configmap/index.md | 2 +- docs/user-guide/federation/configmap.md | 4 ++-- docs/user-guide/federation/daemonsets.md | 4 ++-- docs/user-guide/federation/deployment.md | 4 ++-- docs/user-guide/federation/events.md | 2 +- .../federation/federated-ingress.md | 2 +- docs/user-guide/federation/index.md | 2 +- docs/user-guide/federation/namespaces.md | 8 +++---- docs/user-guide/federation/replicasets.md | 4 ++-- docs/user-guide/federation/secrets.md | 4 ++-- docs/user-guide/jobs.md | 2 +- docs/user-guide/jobs/expansions/index.md | 2 +- docs/user-guide/kubeconfig-file.md | 22 +++++++++---------- docs/user-guide/kubectl/kubectl_autoscale.md | 2 +- .../kubectl/kubectl_cluster-info_dump.md | 2 +- docs/user-guide/kubectl/kubectl_proxy.md | 6 ++--- docs/user-guide/namespaces.md | 2 +- docs/user-guide/pods/index.md | 6 ++--- docs/user-guide/pods/single-container.md | 2 +- docs/user-guide/prereqs.md | 2 +- .../replication-controller/index.md | 2 +- docs/user-guide/secrets/index.md | 2 +- docs/user-guide/services/index.md | 2 +- 46 files changed, 92 insertions(+), 92 deletions(-) diff --git a/README.md b/README.md index 845b56b29e..264822b1df 100644 --- a/README.md +++ b/README.md @@ -6,7 +6,7 @@ You can click the **Fork** button in the upper-right area of the screen to creat For more information about contributing to the Kubernetes documentation, see: -* [Contributing to the kubernetes Documentation](http://kubernetes.io/editdocs/) +* [Contributing to the Kubernetes Documentation](http://kubernetes.io/editdocs/) * [Creating a Documentation Pull Request](http://kubernetes.io/docs/contribute/create-pull-request/) * [Writing a New Topic](http://kubernetes.io/docs/contribute/write-new-topic/) * [Staging Your Documentation Changes](http://kubernetes.io/docs/contribute/stage-documentation-changes/) diff --git a/docs/admin/cluster-management.md b/docs/admin/cluster-management.md index eea8b3f228..5bcdb8b8f3 100644 --- a/docs/admin/cluster-management.md +++ b/docs/admin/cluster-management.md @@ -180,7 +180,7 @@ For the purposes of these flags, _legacy_ APIs are those APIs which have been ex The objects that are stored to disk for a cluster's internal representation of the Kubernetes resources active in the cluster are written using a particular version of the API. When the supported API changes, these objects may need to be rewritten in the newer API. Failure to do this will eventually result in resources that are no longer decodable or usable -by the kubernetes API server. +by the Kubernetes API server. `KUBE_API_VERSIONS` environment variable for the `kube-apiserver` binary which controls the API versions that are supported in the cluster. The first version in the list is used as the cluster's storage version. Hence, to set a specific version as the storage version, bring it to the front of list of versions in the value of `KUBE_API_VERSIONS`. You need to restart the `kube-apiserver` binary for changes to this variable to take effect. diff --git a/docs/admin/federation/index.md b/docs/admin/federation/index.md index f8fb5b6c4f..59a0199d7b 100644 --- a/docs/admin/federation/index.md +++ b/docs/admin/federation/index.md @@ -218,7 +218,7 @@ Once you've registered your cluster with the federation, you'll need to update K ### Kubernetes 1.5+: Passing federations flag via config map to kube-dns -For kubernetes clusters of version 1.5+, you can pass the +For Kubernetes clusters of version 1.5+, you can pass the `--federations` flag to kube-dns via the kube-dns config map. The flag uses the following format: @@ -352,7 +352,7 @@ $ KUBERNETES_PROVIDER=gce FEDERATION_DNS_PROVIDER=google-clouddns FEDERATION_NAM set appropriately if it is missing and `KUBERNETES_PROVIDER` is one of `gce`, `gke` and `aws`. This is used to resolve DNS requests for federation services. The service controller keeps DNS records with the provider updated as services/pods are -updated in underlying kubernetes clusters. +updated in underlying Kubernetes clusters. `FEDERATION_NAME` is a name you can choose for your federation. This is the name that will appear in DNS routes. diff --git a/docs/admin/garbage-collection.md b/docs/admin/garbage-collection.md index 0492f9f277..3a8ecda475 100644 --- a/docs/admin/garbage-collection.md +++ b/docs/admin/garbage-collection.md @@ -13,7 +13,7 @@ External garbage collection tools are not recommended as these tools can potenti ### Image Collection -kubernetes manages lifecycle of all images through imageManager, with the cooperation +Kubernetes manages lifecycle of all images through imageManager, with the cooperation of cadvisor. The policy for garbage collecting images takes two factors into consideration: diff --git a/docs/admin/index.md b/docs/admin/index.md index 98f38b428a..68b669cc10 100644 --- a/docs/admin/index.md +++ b/docs/admin/index.md @@ -13,7 +13,7 @@ It assumes some familiarity with concepts in the [User Guide](/docs/user-guide/) ## Planning a cluster -There are many different examples of how to setup a kubernetes cluster. Many of them are listed in this +There are many different examples of how to setup a Kubernetes cluster. Many of them are listed in this [matrix](/docs/getting-started-guides/). We call each of the combinations in this matrix a *distro*. Before choosing a particular guide, here are some things to consider: @@ -25,12 +25,12 @@ Before choosing a particular guide, here are some things to consider: - Will your cluster be on-premises, or in the cloud (IaaS)? Kubernetes does not directly support hybrid clusters. We recommend setting up multiple clusters rather than spanning distant locations. - Will you be running Kubernetes on "bare metal" or virtual machines? Kubernetes supports both, via different distros. - - Do you just want to run a cluster, or do you expect to do active development of kubernetes project code? If the + - Do you just want to run a cluster, or do you expect to do active development of Kubernetes project code? If the latter, it is better to pick a distro actively used by other developers. Some distros only use binary releases, but offer is a greater variety of choices. - Not all distros are maintained as actively. Prefer ones which are listed as tested on a more recent version of Kubernetes. - - If you are configuring kubernetes on-premises, you will need to consider what [networking + - If you are configuring Kubernetes on-premises, you will need to consider what [networking model](/docs/admin/networking) fits best. - If you are designing for very high-availability, you may want [clusters in multiple zones](/docs/admin/multi-cluster). - You may want to familiarize yourself with the various diff --git a/docs/admin/kube-controller-manager.md b/docs/admin/kube-controller-manager.md index 4b158fe4e4..82dd43cbcd 100644 --- a/docs/admin/kube-controller-manager.md +++ b/docs/admin/kube-controller-manager.md @@ -62,9 +62,9 @@ StreamingProxyRedirects=true|false (ALPHA - default=false) --google-json-key string The Google Cloud Platform Service Account JSON Key to use for authentication. --horizontal-pod-autoscaler-sync-period duration The period for syncing the number of pods in horizontal pod autoscaler. (default 30s) --insecure-experimental-approve-all-kubelet-csrs-for-group string The group for which the controller-manager will auto approve all CSRs for kubelet client certificates. - --kube-api-burst int32 Burst to use while talking with kubernetes apiserver (default 30) + --kube-api-burst int32 Burst to use while talking with Kubernetes apiserver (default 30) --kube-api-content-type string Content type of requests sent to apiserver. (default "application/vnd.kubernetes.protobuf") - --kube-api-qps float32 QPS to use while talking with kubernetes apiserver (default 20) + --kube-api-qps float32 QPS to use while talking with Kubernetes apiserver (default 20) --kubeconfig string Path to kubeconfig file with authorization and master location information. --large-cluster-size-threshold int32 Number of nodes from which NodeController treats the cluster as large for the eviction logic purposes. --secondary-node-eviction-rate is implicitly overridden to 0 for clusters this size or smaller. (default 50) --leader-elect Start a leader election client and gain leadership before executing the main loop. Enable this when running replicated components for high availability. (default true) diff --git a/docs/admin/kube-proxy.md b/docs/admin/kube-proxy.md index 31d3263b5d..ea13d528e3 100644 --- a/docs/admin/kube-proxy.md +++ b/docs/admin/kube-proxy.md @@ -48,9 +48,9 @@ StreamingProxyRedirects=true|false (ALPHA - default=false) --iptables-masquerade-bit int32 If using the pure iptables proxy, the bit of the fwmark space to mark packets requiring SNAT with. Must be within the range [0, 31]. (default 14) --iptables-min-sync-period duration The minimum interval of how often the iptables rules can be refreshed as endpoints and services change (e.g. '5s', '1m', '2h22m'). --iptables-sync-period duration The maximum interval of how often iptables rules are refreshed (e.g. '5s', '1m', '2h22m'). Must be greater than 0. (default 30s) - --kube-api-burst int32 Burst to use while talking with kubernetes apiserver (default 10) + --kube-api-burst int32 Burst to use while talking with Kubernetes apiserver (default 10) --kube-api-content-type string Content type of requests sent to apiserver. (default "application/vnd.kubernetes.protobuf") - --kube-api-qps float32 QPS to use while talking with kubernetes apiserver (default 5) + --kube-api-qps float32 QPS to use while talking with Kubernetes apiserver (default 5) --kubeconfig string Path to kubeconfig file with authorization information (the master location is set by the master flag). --masquerade-all If using the pure iptables proxy, SNAT everything --master string The address of the Kubernetes API server (overrides any value in kubeconfig) diff --git a/docs/admin/kube-scheduler.md b/docs/admin/kube-scheduler.md index 6d3b8c9f64..15e47d2f46 100644 --- a/docs/admin/kube-scheduler.md +++ b/docs/admin/kube-scheduler.md @@ -38,9 +38,9 @@ ExperimentalHostUserNamespaceDefaulting=true|false (ALPHA - default=false) StreamingProxyRedirects=true|false (ALPHA - default=false) --google-json-key string The Google Cloud Platform Service Account JSON Key to use for authentication. --hard-pod-affinity-symmetric-weight int RequiredDuringScheduling affinity is not symmetric, but there is an implicit PreferredDuringScheduling affinity rule corresponding to every RequiredDuringScheduling affinity rule. --hard-pod-affinity-symmetric-weight represents the weight of implicit PreferredDuringScheduling affinity rule. (default 1) - --kube-api-burst int32 Burst to use while talking with kubernetes apiserver (default 100) + --kube-api-burst int32 Burst to use while talking with Kubernetes apiserver (default 100) --kube-api-content-type string Content type of requests sent to apiserver. (default "application/vnd.kubernetes.protobuf") - --kube-api-qps float32 QPS to use while talking with kubernetes apiserver (default 50) + --kube-api-qps float32 QPS to use while talking with Kubernetes apiserver (default 50) --kubeconfig string Path to kubeconfig file with authorization and master location information. --leader-elect Start a leader election client and gain leadership before executing the main loop. Enable this when running replicated components for high availability. (default true) --leader-elect-lease-duration duration The duration that non-leader candidates will wait after observing a leadership renewal until attempting to acquire leadership of a led but unrenewed leader slot. This is effectively the maximum duration that a leader can be stopped before it is replaced by another candidate. This is only applicable if leader election is enabled. (default 15s) diff --git a/docs/admin/kubelet.md b/docs/admin/kubelet.md index 28365fbf97..258db1e3aa 100644 --- a/docs/admin/kubelet.md +++ b/docs/admin/kubelet.md @@ -107,9 +107,9 @@ StreamingProxyRedirects=true|false (ALPHA - default=false) --image-service-endpoint string [Experimental] The unix socket endpoint of remote image service. If not specified, it will be the same with container-runtime-endpoint by default. The endpoint is used only when CRI integration is enabled (--experimental-cri) --iptables-drop-bit int32 The bit of the fwmark space to mark packets for dropping. Must be within the range [0, 31]. (default 15) --iptables-masquerade-bit int32 The bit of the fwmark space to mark packets for SNAT. Must be within the range [0, 31]. Please match this parameter with corresponding parameter in kube-proxy. (default 14) - --kube-api-burst int32 Burst to use while talking with kubernetes apiserver (default 10) + --kube-api-burst int32 Burst to use while talking with Kubernetes apiserver (default 10) --kube-api-content-type string Content type of requests sent to apiserver. (default "application/vnd.kubernetes.protobuf") - --kube-api-qps int32 QPS to use while talking with kubernetes apiserver (default 5) + --kube-api-qps int32 QPS to use while talking with Kubernetes apiserver (default 5) --kube-reserved mapStringString A set of ResourceName=ResourceQuantity (e.g. cpu=200m,memory=150G) pairs that describe resources reserved for kubernetes system components. Currently only cpu and memory are supported. See http://kubernetes.io/docs/user-guide/compute-resources for more detail. [default=none] --kubeconfig string Path to a kubeconfig file, specifying how to connect to the API server. --api-servers will be used for the location unless --require-kubeconfig is set. (default "/var/lib/kubelet/kubeconfig") --kubelet-cgroups string Optional absolute name of cgroups to create and run the Kubelet in. @@ -118,7 +118,7 @@ StreamingProxyRedirects=true|false (ALPHA - default=false) --make-iptables-util-chains If true, kubelet will ensure iptables utility rules are present on host. (default true) --manifest-url string URL for accessing the container manifest --manifest-url-header string HTTP header to use when accessing the manifest URL, with the key separated from the value with a ':', as in 'key:value' - --master-service-namespace string The namespace from which the kubernetes master services should be injected into pods (default "default") + --master-service-namespace string The namespace from which the Kubernetes master services should be injected into pods (default "default") --max-open-files int Number of files that can be opened by Kubelet process. [default=1000000] (default 1000000) --max-pods int32 Number of Pods that can run on this Kubelet. (default 110) --minimum-image-ttl-duration duration Minimum age for an unused image before it is garbage collected. Examples: '300ms', '10s' or '2h45m'. Default: '2m' (default 2m0s) diff --git a/docs/admin/multi-cluster.md b/docs/admin/multi-cluster.md index 4473bb381d..67a2589d40 100644 --- a/docs/admin/multi-cluster.md +++ b/docs/admin/multi-cluster.md @@ -8,7 +8,7 @@ You may want to set up multiple Kubernetes clusters, both to have clusters in different regions to be nearer to your users, and to tolerate failures and/or invasive maintenance. This document describes some of the issues to consider when making a decision about doing so. -If you decide to have multiple clusters, kubernetes provides a way to [federate them](/docs/admin/federation/) +If you decide to have multiple clusters, Kubernetes provides a way to [federate them](/docs/admin/federation/) ## Scope of a single cluster diff --git a/docs/admin/namespaces/walkthrough.md b/docs/admin/namespaces/walkthrough.md index 9faecf89e9..b9c509697c 100644 --- a/docs/admin/namespaces/walkthrough.md +++ b/docs/admin/namespaces/walkthrough.md @@ -151,7 +151,7 @@ Let's create some content. $ kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2 ``` We have just created a deployment whose replica size is 2 that is running the pod called snowflake with a basic container that just serves the hostname. -Note that `kubectl run` creates deployments only on kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead. +Note that `kubectl run` creates deployments only on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead. If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/user-guide/kubectl/kubectl_run/) for more details. ```shell diff --git a/docs/admin/node.md b/docs/admin/node.md index d9d498ba0d..cbb70229e7 100644 --- a/docs/admin/node.md +++ b/docs/admin/node.md @@ -244,6 +244,6 @@ on each kubelet where you want to reserve resources. ## API Object -Node is a top-level resource in the kubernetes REST API. More details about the +Node is a top-level resource in the Kubernetes REST API. More details about the API object can be found at: [Node API object](/docs/api-reference/v1/definitions/#_v1_node). diff --git a/docs/api-reference/README.md b/docs/api-reference/README.md index a2fae5b001..d0040388c8 100644 --- a/docs/api-reference/README.md +++ b/docs/api-reference/README.md @@ -2,7 +2,7 @@ --- # API Reference -Use the following reference docs to understand the kubernetes REST API for various API group versions: +Use the following reference docs to understand the Kubernetes REST API for various API group versions: * v1: [operations](/docs/api-reference/v1/operations.html), [model definitions](/docs/api-reference/v1/definitions.html) * extensions/v1beta1: [operations](/docs/api-reference/extensions/v1beta1/operations.html), [model definitions](/docs/api-reference/extensions/v1beta1/definitions.html) diff --git a/docs/api-reference/labels-annotations-taints.md b/docs/api-reference/labels-annotations-taints.md index 7d02eb509a..8ed53d763e 100644 --- a/docs/api-reference/labels-annotations-taints.md +++ b/docs/api-reference/labels-annotations-taints.md @@ -37,7 +37,7 @@ Example: `beta.kubernetes.io/os=linux` Used on: Node Kubelet populates this with `runtime.GOOS` as defined by Go. This can be handy if you are mixing operating systems -in your cluster (although currently Linux is the only OS supported by kubernetes). +in your cluster (although currently Linux is the only OS supported by Kubernetes). ## kubernetes.io/hostname @@ -56,7 +56,7 @@ Used on: Node Kubelet populates this with the instance type as defined by the `cloudprovider`. It will not be set if not using a cloudprovider. This can be handy if you want to target certain workloads to certain instance -types, but typically you want to rely on the kubernetes scheduler to perform resource-based scheduling, +types, but typically you want to rely on the Kubernetes scheduler to perform resource-based scheduling, and you should aim to schedule based on properties rather than on instance types (e.g. require a GPU, instead of requiring a `g2.2xlarge`) diff --git a/docs/getting-started-guides/clc.md b/docs/getting-started-guides/clc.md index bd0804eb9b..726fe71ac4 100644 --- a/docs/getting-started-guides/clc.md +++ b/docs/getting-started-guides/clc.md @@ -5,7 +5,7 @@ title: Running Kubernetes on CenturyLink Cloud * TOC {: toc} -These scripts handle the creation, deletion and expansion of kubernetes clusters on CenturyLink Cloud. +These scripts handle the creation, deletion and expansion of Kubernetes clusters on CenturyLink Cloud. You can accomplish all these tasks with a single command. We have made the Ansible playbooks used to perform these tasks available [here](https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc/blob/master/ansible/README.md). @@ -13,7 +13,7 @@ You can accomplish all these tasks with a single command. We have made the Ansib If you run into any problems or want help with anything, we are here to help. Reach out to use via any of the following ways: - Submit a github issue -- Send an email to kubernetes AT ctl DOT io +- Send an email to Kubernetes AT ctl DOT io - Visit http://info.ctl.io/kubernetes ## Clusters of VMs or Physical Servers, your choice. @@ -212,10 +212,10 @@ We configure the Kubernetes cluster with the following features: * KubeDNS: DNS resolution and service discovery * Heapster/InfluxDB: For metric collection. Needed for Grafana and auto-scaling. * Grafana: Kubernetes/Docker metric dashboard -* KubeUI: Simple web interface to view kubernetes state +* KubeUI: Simple web interface to view Kubernetes state * Kube Dashboard: New web interface to interact with your cluster -We use the following to create the kubernetes cluster: +We use the following to create the Kubernetes cluster: * Kubernetes 1.1.7 * Ubuntu 14.04 @@ -233,7 +233,7 @@ We use the following to create the kubernetes cluster: ## Cluster management -The most widely used tool for managing a kubernetes cluster is the command-line +The most widely used tool for managing a Kubernetes cluster is the command-line utility ```kubectl```. If you do not already have a copy of this binary on your administrative machine, you may run the script ```install_kubectl.sh``` which will download it and install it in ```/usr/bin/local```. diff --git a/docs/getting-started-guides/fedora/fedora_ansible_config.md b/docs/getting-started-guides/fedora/fedora_ansible_config.md index 0be2625c69..c3615f2aed 100644 --- a/docs/getting-started-guides/fedora/fedora_ansible_config.md +++ b/docs/getting-started-guides/fedora/fedora_ansible_config.md @@ -12,7 +12,7 @@ Configuring Kubernetes on Fedora via Ansible offers a simple way to quickly crea ## Prerequisites -1. Host able to run ansible and able to clone the following repo: [kubernetes](https://github.com/kubernetes/kubernetes.git) +1. Host able to run ansible and able to clone the following repo: [Kubernetes](https://github.com/kubernetes/kubernetes.git) 2. A Fedora 21+ host to act as cluster master 3. As many Fedora 21+ hosts as you would like, that act as cluster nodes @@ -101,9 +101,9 @@ Although the default value of variables in `~/contrib/ansible/group_vars/all.yml edit: ~/contrib/ansible/group_vars/all.yml ``` -**Configure access to kubernetes packages** +**Configure access to Kubernetes packages** -Modify `source_type` as below to access kubernetes packages through the package manager. +Modify `source_type` as below to access Kubernetes packages through the package manager. ```yaml source_type: packageManager @@ -156,7 +156,7 @@ cd ~/contrib/ansible/ That's all there is to it. It's really that easy. At this point you should have a functioning Kubernetes cluster. -**Show kubernetes nodes** +**Show Kubernetes nodes** Run the following on the kube-master: diff --git a/docs/getting-started-guides/fedora/fedora_manual_config.md b/docs/getting-started-guides/fedora/fedora_manual_config.md index c05780ed44..114ded9b76 100644 --- a/docs/getting-started-guides/fedora/fedora_manual_config.md +++ b/docs/getting-started-guides/fedora/fedora_manual_config.md @@ -32,7 +32,7 @@ fed-node = 192.168.121.65 **Prepare the hosts:** -* Install Kubernetes on all hosts - fed-{master,node}. This will also pull in docker. Also install etcd on fed-master. This guide has been tested with kubernetes-0.18 and beyond. +* Install Kubernetes on all hosts - fed-{master,node}. This will also pull in docker. Also install etcd on fed-master. This guide has been tested with Kubernetes-0.18 and beyond. * Running on AWS EC2 with RHEL 7.2, you need to enable "extras" repository for yum by editing `/etc/yum.repos.d/redhat-rhui.repo` and changing the changing the `enable=0` to `enable=1` for extras. ```shell diff --git a/docs/getting-started-guides/kubectl.md b/docs/getting-started-guides/kubectl.md index 8dc6fc10f7..508e1516da 100644 --- a/docs/getting-started-guides/kubectl.md +++ b/docs/getting-started-guides/kubectl.md @@ -63,7 +63,7 @@ If you are on MacOS and using brew, you can install with: brew install kubectl ``` -The homebrew project is independent from kubernetes, so do check that the version is +The homebrew project is independent from Kubernetes, so do check that the version is sufficiently up-to-date using `kubectl version`. diff --git a/docs/getting-started-guides/minikube.md b/docs/getting-started-guides/minikube.md index 46ffedf0ed..65b7893be5 100644 --- a/docs/getting-started-guides/minikube.md +++ b/docs/getting-started-guides/minikube.md @@ -116,7 +116,7 @@ plugins, if required. ### Reusing the Docker daemon -When using a single VM of kubernetes, it's really handy to reuse the minikube's built-in Docker daemon; as this means you don't have to build a docker registry on your host machine and push the image into it - you can just build inside the same docker daemon as minikube which speeds up local experiments. Just make sure you tag your Docker image with something other than 'latest' and use that tag while you pull the image. Otherwise, if you do not specify version of your image, it will be assumed as `:latest`, with pull image policy of `Always` correspondingly, which may eventually result in `ErrImagePull` as you may not have any versions of your Docker image out there in the default docker registry (usually DockerHub) yet. +When using a single VM of Kubernetes, it's really handy to reuse the minikube's built-in Docker daemon; as this means you don't have to build a docker registry on your host machine and push the image into it - you can just build inside the same docker daemon as minikube which speeds up local experiments. Just make sure you tag your Docker image with something other than 'latest' and use that tag while you pull the image. Otherwise, if you do not specify version of your image, it will be assumed as `:latest`, with pull image policy of `Always` correspondingly, which may eventually result in `ErrImagePull` as you may not have any versions of your Docker image out there in the default docker registry (usually DockerHub) yet. To be able to work with the docker daemon on your mac/linux host use the [docker-env command](./docs/minikube_docker-env.md) in your shell: @@ -144,7 +144,7 @@ The fix is to update /etc/sysconfig/docker to ensure that minikube's environment > fi ``` -Remember to turn off the imagePullPolicy:Always, as otherwise kubernetes won't use images you built locally. +Remember to turn off the imagePullPolicy:Always, as otherwise Kubernetes won't use images you built locally. ## Managing your Cluster @@ -312,7 +312,7 @@ For more information about minikube, see the [proposal](https://github.com/kuber * **Development Guide**: See [CONTRIBUTING.md](https://github.com/kubernetes/minikube/blob/master/CONTRIBUTING.md) for an overview of how to send pull requests. * **Building Minikube**: For instructions on how to build/test minikube from source, see the [build guide](https://github.com/kubernetes/minikube/blob/master/BUILD_GUIDE.md) * **Adding a New Dependency**: For instructions on how to add a new dependency to minikube see the [adding dependencies guide](https://github.com/kubernetes/minikube/blob/master/ADD_DEPENDENCY.md) -* **Updating Kubernetes**: For instructions on how to add a new dependency to minikube see the [updating kubernetes guide](https://github.com/kubernetes/minikube/blob/master/UPDATE_KUBERNETES.md) +* **Updating Kubernetes**: For instructions on how to add a new dependency to minikube see the [updating Kubernetes guide](https://github.com/kubernetes/minikube/blob/master/UPDATE_KUBERNETES.md) ## Community diff --git a/docs/getting-started-guides/scratch.md b/docs/getting-started-guides/scratch.md index 2ef0f75dc3..44ff8112c6 100644 --- a/docs/getting-started-guides/scratch.md +++ b/docs/getting-started-guides/scratch.md @@ -822,7 +822,7 @@ of their purpose is in the admin guide](/docs/admin/cluster-components/#addons). Notes for setting up each cluster service are given below: * Cluster DNS: - * required for many kubernetes examples + * required for many Kubernetes examples * [Setup instructions](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/) * [Admin Guide](/docs/admin/dns/) * Cluster-level Logging diff --git a/docs/getting-started-guides/ubuntu/manual.md b/docs/getting-started-guides/ubuntu/manual.md index c2566aaf33..29f6986e25 100644 --- a/docs/getting-started-guides/ubuntu/manual.md +++ b/docs/getting-started-guides/ubuntu/manual.md @@ -4,7 +4,7 @@ assignees: --- -This document describes how to deploy kubernetes on ubuntu nodes, 1 master and 3 nodes involved +This document describes how to deploy Kubernetes on ubuntu nodes, 1 master and 3 nodes involved in the given examples. You can scale to **any number of nodes** by changing some settings with ease. The original idea was heavily inspired by @jainvipin 's ubuntu single node work, which has been merge into this document. @@ -36,7 +36,7 @@ Ubuntu 15 which uses systemd instead of upstart. ### Set up working directory -Clone the kubernetes github repo locally +Clone the Kubernetes github repo locally ```shell $ git clone --depth 1 https://github.com/kubernetes/kubernetes.git @@ -101,7 +101,7 @@ acts as both master and node, "a" stands for master, "i" stands for node. The `NUM_NODES` variable defines the total number of nodes. -The `SERVICE_CLUSTER_IP_RANGE` variable defines the kubernetes service IP range. Please make sure +The `SERVICE_CLUSTER_IP_RANGE` variable defines the Kubernetes service IP range. Please make sure that you do have a valid private ip range defined here, because some IaaS provider may reserve private ips. You can use below three private network range according to rfc1918. Besides you'd better not choose the one that conflicts with your own private network range. @@ -138,7 +138,7 @@ bring up the whole cluster. $ KUBERNETES_PROVIDER=ubuntu ./kube-up.sh ``` -The scripts automatically copy binaries and config files to all the machines via `scp` and start kubernetes +The scripts automatically copy binaries and config files to all the machines via `scp` and start Kubernetes service on them. The only thing you need to do is to type the sudo password when promoted. ```shell @@ -211,7 +211,7 @@ After some time, you can use `$ kubectl get pods --namespace=kube-system` to see We are working on these features which we'd like to let everybody know: -1. Run kubernetes binaries in Docker using [kube-in-docker](https://github.com/ZJU-SEL/kube-in-docker/tree/baremetal-kube), +1. Run Kubernetes binaries in Docker using [kube-in-docker](https://github.com/ZJU-SEL/kube-in-docker/tree/baremetal-kube), to eliminate OS-distro differences. 2. Tearing Down scripts: clear and re-create the whole stack by one click. @@ -239,7 +239,7 @@ $ KUBERNETES_PROVIDER=ubuntu ./kube-up.sh ## Upgrading a Cluster -If you already have a kubernetes cluster, and want to upgrade to a new version, +If you already have a Kubernetes cluster, and want to upgrade to a new version, you can use following command in `cluster/` directory to update the whole cluster or a specified node to a new version. @@ -285,7 +285,7 @@ The script will not delete any resources of your cluster, it just replaces the b ### Test it out -You can use the `kubectl` command to check if the newly upgraded kubernetes cluster is working correctly. +You can use the `kubectl` command to check if the newly upgraded Kubernetes cluster is working correctly. To make sure the version of the upgraded cluster is what you expect, you will find these commands helpful. diff --git a/docs/tasks/manage-stateful-set/deleting-a-statefulset.md b/docs/tasks/manage-stateful-set/deleting-a-statefulset.md index d95d28a2d8..5ea82aef04 100644 --- a/docs/tasks/manage-stateful-set/deleting-a-statefulset.md +++ b/docs/tasks/manage-stateful-set/deleting-a-statefulset.md @@ -24,7 +24,7 @@ This task shows you how to delete a StatefulSet. ### Deleting a StatefulSet -You can delete a StatefulSet in the same way you delete other resources in kubernetes: use the `kubectl delete` command, and specify the StatefulSet either by file or by name. +You can delete a StatefulSet in the same way you delete other resources in Kubernetes: use the `kubectl delete` command, and specify the StatefulSet either by file or by name. ```shell kubectl delete -f diff --git a/docs/troubleshooting.md b/docs/troubleshooting.md index 7a8e11d2d5..30bb0cf38c 100644 --- a/docs/troubleshooting.md +++ b/docs/troubleshooting.md @@ -43,7 +43,7 @@ You may also find the Stack Overflow topics relevant: Someone else from the community may have already asked a similar question or may be able to help with your problem. The Kubernetes team will also monitor -[posts tagged kubernetes](http://stackoverflow.com/questions/tagged/kubernetes). +[posts tagged Kubernetes](http://stackoverflow.com/questions/tagged/kubernetes). If there aren't any existing questions that help, please [ask a new one](http://stackoverflow.com/questions/ask?tags=kubernetes)! ### Slack diff --git a/docs/user-guide/configmap/index.md b/docs/user-guide/configmap/index.md index fd1972ac4d..d630ed2aa8 100644 --- a/docs/user-guide/configmap/index.md +++ b/docs/user-guide/configmap/index.md @@ -294,7 +294,7 @@ SPECIAL_TYPE_KEY=charm ### Use-Case: Set command-line arguments with ConfigMap ConfigMaps can also be used to set the value of the command or arguments in a container. This is -accomplished using the kubernetes substitution syntax `$(VAR_NAME)`. Consider the ConfigMap: +accomplished using the Kubernetes substitution syntax `$(VAR_NAME)`. Consider the ConfigMap: ```yaml apiVersion: v1 diff --git a/docs/user-guide/federation/configmap.md b/docs/user-guide/federation/configmap.md index 93c9e75f55..9d8aa18cac 100644 --- a/docs/user-guide/federation/configmap.md +++ b/docs/user-guide/federation/configmap.md @@ -43,11 +43,11 @@ kubectl --context=federation-cluster create -f myconfigmap.yaml ``` The `--context=federation-cluster` flag tells kubectl to submit the -request to the Federation apiserver instead of sending it to a kubernetes +request to the Federation apiserver instead of sending it to a Kubernetes cluster. Once a Federated ConfigMap is created, the federation control plane will create -a matching ConfigMap in all underlying kubernetes clusters. +a matching ConfigMap in all underlying Kubernetes clusters. You can verify this by checking each of the underlying clusters, for example: ``` shell diff --git a/docs/user-guide/federation/daemonsets.md b/docs/user-guide/federation/daemonsets.md index 069afd7ac8..7699ead4e3 100644 --- a/docs/user-guide/federation/daemonsets.md +++ b/docs/user-guide/federation/daemonsets.md @@ -44,11 +44,11 @@ kubectl --context=federation-cluster create -f mydaemonset.yaml ``` The `--context=federation-cluster` flag tells kubectl to submit the -request to the Federation apiserver instead of sending it to a kubernetes +request to the Federation apiserver instead of sending it to a Kubernetes cluster. Once a Federated Daemonset is created, the federation control plane will create -a matching DaemonSet in all underlying kubernetes clusters. +a matching DaemonSet in all underlying Kubernetes clusters. You can verify this by checking each of the underlying clusters, for example: ``` shell diff --git a/docs/user-guide/federation/deployment.md b/docs/user-guide/federation/deployment.md index b8a47f0a63..3e8e196736 100644 --- a/docs/user-guide/federation/deployment.md +++ b/docs/user-guide/federation/deployment.md @@ -47,11 +47,11 @@ kubectl --context=federation-cluster create -f mydeployment.yaml ``` The '--context=federation-cluster' flag tells kubectl to submit the -request to the Federation apiserver instead of sending it to a kubernetes +request to the Federation apiserver instead of sending it to a Kubernetes cluster. Once a Federated Deployment is created, the federation control plane will create -a Deployment in all underlying kubernetes clusters. +a Deployment in all underlying Kubernetes clusters. You can verify this by checking each of the underlying clusters, for example: ``` shell diff --git a/docs/user-guide/federation/events.md b/docs/user-guide/federation/events.md index 60c78ad9c5..1d9f72ea0e 100644 --- a/docs/user-guide/federation/events.md +++ b/docs/user-guide/federation/events.md @@ -27,7 +27,7 @@ general. Events in federation control plane (referred to as "federation events" in this guide) are very similar to the traditional Kubernetes Events providing the same functionality. -Federation Events are stored only in federation control plane and are not passed on to the underlying kubernetes clusters. +Federation Events are stored only in federation control plane and are not passed on to the underlying Kubernetes clusters. Federation controllers create events as they process API resources to surface to the user, the state that they are in. diff --git a/docs/user-guide/federation/federated-ingress.md b/docs/user-guide/federation/federated-ingress.md index ff7638481e..a137ace1f2 100644 --- a/docs/user-guide/federation/federated-ingress.md +++ b/docs/user-guide/federation/federated-ingress.md @@ -277,7 +277,7 @@ where: 1. `firewall-rule-name` can be any name. 2. `[]` is the comma separated list of node ports corresponding to the services that back the Federated Ingress. -3. [] is the comma separated list of the target tags assigned to the nodes in a kubernetes cluster. +3. [] is the comma separated list of the target tags assigned to the nodes in a Kubernetes cluster. 4. is the name of the network where the firewall rule must be installed. Example: diff --git a/docs/user-guide/federation/index.md b/docs/user-guide/federation/index.md index 0c54a2c922..2954984313 100644 --- a/docs/user-guide/federation/index.md +++ b/docs/user-guide/federation/index.md @@ -2,7 +2,7 @@ title: Federation User Guide --- -This guide explains how we can manage multiple kubernetes clusters using +This guide explains how we can manage multiple Kubernetes clusters using federation. [Federation proposal](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/proposals/federation.md) details the use cases motivating cluster federation. diff --git a/docs/user-guide/federation/namespaces.md b/docs/user-guide/federation/namespaces.md index 9090f2a4ec..5ed3ffafec 100644 --- a/docs/user-guide/federation/namespaces.md +++ b/docs/user-guide/federation/namespaces.md @@ -43,11 +43,11 @@ kubectl --context=federation-cluster create -f myns.yaml ``` The '--context=federation-cluster' flag tells kubectl to submit the -request to the Federation apiserver instead of sending it to a kubernetes +request to the Federation apiserver instead of sending it to a Kubernetes cluster. Once a federated namespace is created, the federation control plane will create -a matching namespace in all underlying kubernetes clusters. +a matching namespace in all underlying Kubernetes clusters. You can verify this by checking each of the underlying clusters, for example: ``` shell @@ -64,7 +64,7 @@ the Federated Namespace that you created above. You can update a federated namespace as you would update a Kubernetes namespace, just send the request to federation apiserver instead of sending it -to a specific kubernetes cluster. +to a specific Kubernetes cluster. Federation control plan will ensure that whenever the federated namespace is updated, it updates the corresponding namespaces in all underlying clusters to match it. @@ -73,7 +73,7 @@ match it. You can delete a federated namespace as you would delete a Kubernetes namespace, just send the request to federation apiserver instead of sending it -to a specific kubernetes cluster. +to a specific Kubernetes cluster. For example, you can do that using kubectl by running: diff --git a/docs/user-guide/federation/replicasets.md b/docs/user-guide/federation/replicasets.md index c1213e9f32..c173a38996 100644 --- a/docs/user-guide/federation/replicasets.md +++ b/docs/user-guide/federation/replicasets.md @@ -43,11 +43,11 @@ kubectl --context=federation-cluster create -f myrs.yaml ``` The '--context=federation-cluster' flag tells kubectl to submit the -request to the Federation apiserver instead of sending it to a kubernetes +request to the Federation apiserver instead of sending it to a Kubernetes cluster. Once a federated replica set is created, the federation control plane will create -a replica set in all underlying kubernetes clusters. +a replica set in all underlying Kubernetes clusters. You can verify this by checking each of the underlying clusters, for example: ``` shell diff --git a/docs/user-guide/federation/secrets.md b/docs/user-guide/federation/secrets.md index 372ed30bfd..2c5eac6dba 100644 --- a/docs/user-guide/federation/secrets.md +++ b/docs/user-guide/federation/secrets.md @@ -43,11 +43,11 @@ kubectl --context=federation-cluster create -f mysecret.yaml ``` The '--context=federation-cluster' flag tells kubectl to submit the -request to the Federation apiserver instead of sending it to a kubernetes +request to the Federation apiserver instead of sending it to a Kubernetes cluster. Once a federated secret is created, the federation control plane will create -a matching secret in all underlying kubernetes clusters. +a matching secret in all underlying Kubernetes clusters. You can verify this by checking each of the underlying clusters, for example: ``` shell diff --git a/docs/user-guide/jobs.md b/docs/user-guide/jobs.md index 4feae7a1c4..d8476d73d5 100644 --- a/docs/user-guide/jobs.md +++ b/docs/user-guide/jobs.md @@ -24,7 +24,7 @@ A Job can also be used to run multiple pods in parallel. ### extensions/v1beta1.Job is deprecated Starting from version 1.5 `extensions/v1beta1.Job` is being deprecated, with a plan to be removed in -version 1.6 of kubernetes (see this [issue](https://github.com/kubernetes/kubernetes/issues/32763)). +version 1.6 of Kubernetes (see this [issue](https://github.com/kubernetes/kubernetes/issues/32763)). Please use `batch/v1.Job` instead. ## Running an example Job diff --git a/docs/user-guide/jobs/expansions/index.md b/docs/user-guide/jobs/expansions/index.md index c7a7a8b76f..767ac65215 100644 --- a/docs/user-guide/jobs/expansions/index.md +++ b/docs/user-guide/jobs/expansions/index.md @@ -188,7 +188,7 @@ If you have a large number of job objects, you may find that: concurrent requests to a shared resource, such as a database, used by all the pods in the job. - very large numbers of jobs created at once overload the - kubernetes apiserver, controller, or scheduler. + Kubernetes apiserver, controller, or scheduler. In this case, you can consider one of the other [job patterns](/docs/user-guide/jobs/#job-patterns). diff --git a/docs/user-guide/kubeconfig-file.md b/docs/user-guide/kubeconfig-file.md index 3f861ef2d2..581bc9ccfb 100644 --- a/docs/user-guide/kubeconfig-file.md +++ b/docs/user-guide/kubeconfig-file.md @@ -1,11 +1,11 @@ ---- -assignees: -- mikedanese -- thockin -title: Authenticating Across Clusters with kubeconfig ---- - -Authentication in kubernetes can differ for different individuals. +--- +assignees: +- mikedanese +- thockin +title: Authenticating Across Clusters with kubeconfig +--- + +Authentication in Kubernetes can differ for different individuals. - A running kubelet might have one way of authenticating (i.e. certificates). - Users might have a different way of authenticating (i.e. tokens). @@ -82,8 +82,8 @@ clusters: name: pig-cluster ``` -A `cluster` contains endpoint data for a kubernetes cluster. This includes the fully -qualified url for the kubernetes apiserver, as well as the cluster's certificate +A `cluster` contains endpoint data for a Kubernetes cluster. This includes the fully +qualified url for the Kubernetes apiserver, as well as the cluster's certificate authority or `insecure-skip-tls-verify: true`, if the cluster's serving certificate is not signed by a system trusted certificate authority. A `cluster` has a name (nickname) which acts as a dictionary key for the cluster @@ -103,7 +103,7 @@ users: client-key: path/to/my/client/key ``` -A `user` defines client credentials for authenticating to a kubernetes cluster. A +A `user` defines client credentials for authenticating to a Kubernetes cluster. A `user` has a name (nickname) which acts as its key within the list of user entries after kubeconfig is loaded/merged. Available credentials are `client-certificate`, `client-key`, `token`, and `username/password`. `username/password` and `token` diff --git a/docs/user-guide/kubectl/kubectl_autoscale.md b/docs/user-guide/kubectl/kubectl_autoscale.md index d996c94d72..b863fc6b66 100644 --- a/docs/user-guide/kubectl/kubectl_autoscale.md +++ b/docs/user-guide/kubectl/kubectl_autoscale.md @@ -9,7 +9,7 @@ Auto-scale a Deployment, ReplicaSet, or ReplicationController ### Synopsis -Creates an autoscaler that automatically chooses and sets the number of pods that run in a kubernetes cluster. +Creates an autoscaler that automatically chooses and sets the number of pods that run in a Kubernetes cluster. Looks up a Deployment, ReplicaSet, or ReplicationController by name and creates an autoscaler that uses the given resource as a reference. An autoscaler can automatically increase or decrease number of pods deployed within the system as needed. diff --git a/docs/user-guide/kubectl/kubectl_cluster-info_dump.md b/docs/user-guide/kubectl/kubectl_cluster-info_dump.md index b6675452f5..5c744e0e27 100644 --- a/docs/user-guide/kubectl/kubectl_cluster-info_dump.md +++ b/docs/user-guide/kubectl/kubectl_cluster-info_dump.md @@ -7,7 +7,7 @@ Dump lots of relevant info for debugging and diagnosis ### Synopsis -Dumps cluster info out suitable for debugging and diagnosing cluster problems. By default, dumps everything to stdout. You can optionally specify a directory with --output-directory. If you specify a directory, kubernetes will build a set of files in that directory. By default only dumps things in the 'kube-system' namespace, but you can switch to a different namespace with the --namespaces flag, or specify --all-namespaces to dump all namespaces. +Dumps cluster info out suitable for debugging and diagnosing cluster problems. By default, dumps everything to stdout. You can optionally specify a directory with --output-directory. If you specify a directory, Kubernetes will build a set of files in that directory. By default only dumps things in the 'kube-system' namespace, but you can switch to a different namespace with the --namespaces flag, or specify --all-namespaces to dump all namespaces. The command also dumps the logs of all of the pods in the cluster, these logs are dumped into different directories based on namespace and pod name. diff --git a/docs/user-guide/kubectl/kubectl_proxy.md b/docs/user-guide/kubectl/kubectl_proxy.md index d3713ae52f..9616d6add6 100644 --- a/docs/user-guide/kubectl/kubectl_proxy.md +++ b/docs/user-guide/kubectl/kubectl_proxy.md @@ -9,17 +9,17 @@ Run a proxy to the Kubernetes API server ### Synopsis -To proxy all of the kubernetes api and nothing else, use: +To proxy all of the Kubernetes api and nothing else, use: $ kubectl proxy --api-prefix=/ -To proxy only part of the kubernetes api and also some static files: +To proxy only part of the Kubernetes api and also some static files: $ kubectl proxy --www=/my/files --www-prefix=/static/ --api-prefix=/api/ The above lets you 'curl localhost:8001/api/v1/pods'. -To proxy the entire kubernetes api at a different root, use: +To proxy the entire Kubernetes api at a different root, use: $ kubectl proxy --api-prefix=/custom/ diff --git a/docs/user-guide/namespaces.md b/docs/user-guide/namespaces.md index 11c4c1a95d..d162139358 100644 --- a/docs/user-guide/namespaces.md +++ b/docs/user-guide/namespaces.md @@ -89,7 +89,7 @@ across namespaces, you need to use the fully qualified domain name (FQDN). ## Not All Objects are in a Namespace -Most kubernetes resources (e.g. pods, services, replication controllers, and others) are +Most Kubernetes resources (e.g. pods, services, replication controllers, and others) are in some namespace. However namespace resources are not themselves in a namespace. And low-level resources, such as [nodes](/docs/admin/node) and persistentVolumes, are not in any namespace. Events are an exception: they may or may not diff --git a/docs/user-guide/pods/index.md b/docs/user-guide/pods/index.md index 6bea334dec..321900c948 100644 --- a/docs/user-guide/pods/index.md +++ b/docs/user-guide/pods/index.md @@ -178,9 +178,9 @@ Force deletions can be potentially dangerous for some pods and should be perform ## Privileged mode for pod containers -From kubernetes v1.1, any container in a pod can enable privileged mode, using the `privileged` flag on the `SecurityContext` of the container spec. This is useful for containers that want to use linux capabilities like manipulating the network stack and accessing devices. Processes within the container get almost the same privileges that are available to processes outside a container. With privileged mode, it should be easier to write network and volume plugins as separate pods that don't need to be compiled into the kubelet. +From Kubernetes v1.1, any container in a pod can enable privileged mode, using the `privileged` flag on the `SecurityContext` of the container spec. This is useful for containers that want to use linux capabilities like manipulating the network stack and accessing devices. Processes within the container get almost the same privileges that are available to processes outside a container. With privileged mode, it should be easier to write network and volume plugins as separate pods that don't need to be compiled into the kubelet. -If the master is running kubernetes v1.1 or higher, and the nodes are running a version lower than v1.1, then new privileged pods will be accepted by api-server, but will not be launched. They will be pending state. +If the master is running Kubernetes v1.1 or higher, and the nodes are running a version lower than v1.1, then new privileged pods will be accepted by api-server, but will not be launched. They will be pending state. If user calls `kubectl describe pod FooPodName`, user can see the reason why the pod is in pending state. The events table in the describe command output will say: `Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'` @@ -191,6 +191,6 @@ spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true' ## API Object -Pod is a top-level resource in the kubernetes REST API. More details about the +Pod is a top-level resource in the Kubernetes REST API. More details about the API object can be found at: [Pod API object](/docs/api-reference/v1/definitions/#_v1_pod). diff --git a/docs/user-guide/pods/single-container.md b/docs/user-guide/pods/single-container.md index 1b238be826..4fef42a2f9 100644 --- a/docs/user-guide/pods/single-container.md +++ b/docs/user-guide/pods/single-container.md @@ -73,7 +73,7 @@ There are additional flags that can be specified. For a complete list, run: ## Deleting a pod -If your pod was created using the `run` command, kubernetes creates a +If your pod was created using the `run` command, Kubernetes creates a [Deployment](/docs/user-guide/deployments/) to manage the pod. Pods managed by a Deployment are rescheduled if they go away, including being deleted by `kubectl delete pod`. To permanently diff --git a/docs/user-guide/prereqs.md b/docs/user-guide/prereqs.md index 3b9688f1b8..19e6d8612b 100644 --- a/docs/user-guide/prereqs.md +++ b/docs/user-guide/prereqs.md @@ -32,7 +32,7 @@ sudo mv ./kubectl /usr/local/bin/kubectl If you downloaded a pre-compiled [release](https://github.com/kubernetes/kubernetes/releases), kubectl will be under `platforms//` from the tar bundle. -If you compiled kubernetes from source, kubectl should be either under `_output/local/bin//` or `_output/dockerized/bin//`. +If you compiled Kubernetes from source, kubectl should be either under `_output/local/bin//` or `_output/dockerized/bin//`. Copy or move kubectl into a directory already in your PATH (e.g. `/usr/local/bin`). For example: diff --git a/docs/user-guide/replication-controller/index.md b/docs/user-guide/replication-controller/index.md index 32e1cea9dd..0fee281cdb 100644 --- a/docs/user-guide/replication-controller/index.md +++ b/docs/user-guide/replication-controller/index.md @@ -224,7 +224,7 @@ The ReplicationController is intended to be a composable building-block primitiv ## API Object -Replication controller is a top-level resource in the kubernetes REST API. More details about the +Replication controller is a top-level resource in the Kubernetes REST API. More details about the API object can be found at: [ReplicationController API object](/docs/api-reference/v1/definitions/#_v1_replicationcontroller). diff --git a/docs/user-guide/secrets/index.md b/docs/user-guide/secrets/index.md index 6f6728db42..63a2a052ea 100644 --- a/docs/user-guide/secrets/index.md +++ b/docs/user-guide/secrets/index.md @@ -486,7 +486,7 @@ 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 have accessible to all the users with whom you share the kubernetes cluster, and can revoke if they are compromised. +**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 have accessible to all the users with whom you share the Kubernetes cluster, and can revoke if they are compromised. Now we can create a pod which references the secret with the ssh key and diff --git a/docs/user-guide/services/index.md b/docs/user-guide/services/index.md index 60fa80e2e7..cd9303bd33 100644 --- a/docs/user-guide/services/index.md +++ b/docs/user-guide/services/index.md @@ -655,7 +655,7 @@ through a load-balancer, though in those cases the client IP does get altered. ## API Object -Service is a top-level resource in the kubernetes REST API. More details about the +Service is a top-level resource in the Kubernetes REST API. More details about the API object can be found at: [Service API object](/docs/api-reference/v1/definitions/#_v1_service). From 34bbec31f553cccff0aa7bd28991e5db13ce96c1 Mon Sep 17 00:00:00 2001 From: gbzhu Date: Wed, 28 Dec 2016 18:22:20 +0800 Subject: [PATCH 60/68] fix typo --- docs/user-guide/kubeconfig-file.md | 314 ----------------------------- 1 file changed, 314 deletions(-) diff --git a/docs/user-guide/kubeconfig-file.md b/docs/user-guide/kubeconfig-file.md index 581bc9ccfb..e69de29bb2 100644 --- a/docs/user-guide/kubeconfig-file.md +++ b/docs/user-guide/kubeconfig-file.md @@ -1,314 +0,0 @@ ---- -assignees: -- mikedanese -- thockin -title: Authenticating Across Clusters with kubeconfig ---- - -Authentication in Kubernetes can differ for different individuals. - -- A running kubelet might have one way of authenticating (i.e. certificates). -- Users might have a different way of authenticating (i.e. tokens). -- Administrators might have a list of certificates which they provide individual users. -- There may be multiple clusters, and we may want to define them all in one place - giving users the ability to use their own certificates and reusing the same global configuration. - -So in order to easily switch between multiple clusters, for multiple users, a kubeconfig file was defined. - -This file contains a series of authentication mechanisms and cluster connection information associated with nicknames. It also introduces the concept of a tuple of authentication information (user) and cluster connection information called a context that is also associated with a nickname. - -Multiple kubeconfig files are allowed, if specified explicitly. At runtime they are loaded and merged along with override options specified from the command line (see [rules](#loading-and-merging) below). - -## Related discussion - -http://issue.k8s.io/1755 - -## Components of a kubeconfig file - -### Example kubeconfig file - -```yaml -current-context: federal-context -apiVersion: v1 -clusters: -- cluster: - api-version: v1 - server: http://cow.org:8080 - name: cow-cluster -- cluster: - certificate-authority: path/to/my/cafile - server: https://horse.org:4443 - name: horse-cluster -- cluster: - insecure-skip-tls-verify: true - server: https://pig.org:443 - name: pig-cluster -contexts: -- context: - cluster: horse-cluster - namespace: chisel-ns - user: green-user - name: federal-context -- context: - cluster: pig-cluster - namespace: saw-ns - user: black-user - name: queen-anne-context -kind: Config -preferences: - colors: true -users: -- name: blue-user - user: - token: blue-token -- name: green-user - user: - client-certificate: path/to/my/client/cert - client-key: path/to/my/client/key -``` - -### Breakdown/explanation of components - -#### cluster - -```yaml -clusters: -- cluster: - certificate-authority: path/to/my/cafile - server: https://horse.org:4443 - name: horse-cluster -- cluster: - insecure-skip-tls-verify: true - server: https://pig.org:443 - name: pig-cluster -``` - -A `cluster` contains endpoint data for a Kubernetes cluster. This includes the fully -qualified url for the Kubernetes apiserver, as well as the cluster's certificate -authority or `insecure-skip-tls-verify: true`, if the cluster's serving -certificate is not signed by a system trusted certificate authority. -A `cluster` has a name (nickname) which acts as a dictionary key for the cluster -within this kubeconfig file. You can add or modify `cluster` entries using -[`kubectl config set-cluster`](/docs/user-guide/kubectl/kubectl_config_set-cluster/). - -#### user - -```yaml -users: -- name: blue-user - user: - token: blue-token -- name: green-user - user: - client-certificate: path/to/my/client/cert - client-key: path/to/my/client/key -``` - -A `user` defines client credentials for authenticating to a Kubernetes cluster. A -`user` has a name (nickname) which acts as its key within the list of user entries -after kubeconfig is loaded/merged. Available credentials are `client-certificate`, -`client-key`, `token`, and `username/password`. `username/password` and `token` -are mutually exclusive, but client certs and keys can be combined with them. -You can add or modify `user` entries using -[`kubectl config set-credentials`](/docs/user-guide/kubectl/kubectl_config_set-credentials). - -#### context - -```yaml -contexts: -- context: - cluster: horse-cluster - namespace: chisel-ns - user: green-user - name: federal-context -``` - -A `context` defines a named [`cluster`](#cluster),[`user`](#user),[`namespace`](/docs/user-guide/namespaces) tuple -which is used to send requests to the specified cluster using the provided authentication info and -namespace. Each of the three is optional; it is valid to specify a context with only one of `cluster`, -`user`,`namespace`, or to specify none. Unspecified values, or named values that don't have corresponding -entries in the loaded kubeconfig (e.g. if the context specified a `pink-user` for the above kubeconfig file) -will be replaced with the default. See [Loading and merging rules](#loading-and-merging) below for override/merge behavior. -You can add or modify `context` entries with [`kubectl config set-context`](/docs/user-guide/kubectl/kubectl_config_set-context). - -#### current-context - -```yaml -current-context: federal-context -``` - -`current-context` is the nickname or 'key' for the cluster,user,namespace tuple that kubectl -will use by default when loading config from this file. You can override any of the values in kubectl -from the commandline, by passing `--context=CONTEXT`, `--cluster=CLUSTER`, `--user=USER`, and/or `--namespace=NAMESPACE` respectively. -You can change the `current-context` with [`kubectl config use-context`](/docs/user-guide/kubectl/kubectl_config_use-context). - -#### miscellaneous - -```yaml -apiVersion: v1 -kind: Config -preferences: - colors: true -``` - -`apiVersion` and `kind` identify the version and schema for the client parser and should not -be edited manually. - -`preferences` specify optional (and currently unused) kubectl preferences. - -## Viewing kubeconfig files - -`kubectl config view` will display the current kubeconfig settings. By default -it will show you all loaded kubeconfig settings; you can filter the view to just -the settings relevant to the `current-context` by passing `--minify`. See -[`kubectl config view`](/docs/user-guide/kubectl/kubectl_config_view) for other options. - -## Building your own kubeconfig file - -NOTE, that if you are deploying k8s via kube-up.sh, you do not need to create your own kubeconfig files, the script will do it for you. - -In any case, you can easily use this file as a template to create your own kubeconfig files. - -So, lets do a quick walk through the basics of the above file so you can easily modify it as needed... - -The above file would likely correspond to an api-server which was launched using the `--token-auth-file=tokens.csv` option, where the tokens.csv file looked something like this: - -```conf -blue-user,blue-user,1 -mister-red,mister-red,2 -``` - -Also, since we have other users who validate using **other** mechanisms, the api-server would have probably been launched with other authentication options (there are many such options, make sure you understand which ones YOU care about before crafting a kubeconfig file, as nobody needs to implement all the different permutations of possible authentication schemes). - -- Since the user for the current context is "green-user", any client of the api-server using this kubeconfig file would naturally be able to log in successfully, because we are providing the green-user's client credentials. -- Similarly, we can operate as the "blue-user" if we choose to change the value of current-context. - -In the above scenario, green-user would have to log in by providing certificates, whereas blue-user would just provide the token. All this information would be handled for us by the - -## Loading and merging rules - -The rules for loading and merging the kubeconfig files are straightforward, but there are a lot of them. The final config is built in this order: - - 1. Get the kubeconfig from disk. This is done with the following hierarchy and merge rules: - - - If the `CommandLineLocation` (the value of the `kubeconfig` command line option) is set, use this file only. No merging. Only one instance of this flag is allowed. - - - Else, if `EnvVarLocation` (the value of `$KUBECONFIG`) is available, use it as a list of files that should be merged. - Merge files together based on the following rules. - Empty filenames are ignored. Files with non-deserializable content produced errors. - The first file to set a particular value or map key wins and the value or map key is never changed. - This means that the first file to set `CurrentContext` will have its context preserved. It also means that if two files specify a "red-user", only values from the first file's red-user are used. Even non-conflicting entries from the second file's "red-user" are discarded. - - - Otherwise, use HomeDirectoryLocation (`~/.kube/config`) with no merging. - 1. Determine the context to use based on the first hit in this chain - 1. command line argument - the value of the `context` command line option - 1. `current-context` from the merged kubeconfig file - 1. Empty is allowed at this stage - 1. Determine the cluster info and user to use. At this point, we may or may not have a context. They are built based on the first hit in this chain. (run it twice, once for user, once for cluster) - 1. command line argument - `user` for user name and `cluster` for cluster name - 1. If context is present, then use the context's value - 1. Empty is allowed - 1. Determine the actual cluster info to use. At this point, we may or may not have a cluster info. Build each piece of the cluster info based on the chain (first hit wins): - 1. command line arguments - `server`, `api-version`, `certificate-authority`, and `insecure-skip-tls-verify` - 1. If cluster info is present and a value for the attribute is present, use it. - 1. If you don't have a server location, error. - 1. Determine the actual user info to use. User is built using the same rules as cluster info, EXCEPT that you can only have one authentication technique per user. - 1. Load precedence is 1) command line flag, 2) user fields from kubeconfig - 1. The command line flags are: `client-certificate`, `client-key`, `username`, `password`, and `token`. - 1. If there are two conflicting techniques, fail. - 1. For any information still missing, use default values and potentially prompt for authentication information - 1. All file references inside of a kubeconfig file are resolved relative to the location of the kubeconfig file itself. When file references are presented on the command line - they are resolved relative to the current working directory. When paths are saved in the ~/.kube/config, relative paths are stored relatively while absolute paths are stored absolutely. - -Any path in a kubeconfig file is resolved relative to the location of the kubeconfig file itself. - - -## Manipulation of kubeconfig via `kubectl config ` - -In order to more easily manipulate kubeconfig files, there are a series of subcommands to `kubectl config` to help. -See [kubectl/kubectl_config.md](/docs/user-guide/kubectl/kubectl_config) for help. - -### Example - -```shell -$ kubectl config set-credentials myself --username=admin --password=secret -$ kubectl config set-cluster local-server --server=http://localhost:8080 -$ kubectl config set-context default-context --cluster=local-server --user=myself -$ kubectl config use-context default-context -$ kubectl config set contexts.default-context.namespace the-right-prefix -$ kubectl config view -``` - -produces this output - -```yaml -apiVersion: v1 -clusters: -- cluster: - server: http://localhost:8080 - name: local-server -contexts: -- context: - cluster: local-server - namespace: the-right-prefix - user: myself - name: default-context -current-context: default-context -kind: Config -preferences: {} -users: -- name: myself - user: - password: secret - username: admin -``` - -and a kubeconfig file that looks like this - -```yaml -apiVersion: v1 -clusters: -- cluster: - server: http://localhost:8080 - name: local-server -contexts: -- context: - cluster: local-server - namespace: the-right-prefix - user: myself - name: default-context -current-context: default-context -kind: Config -preferences: {} -users: -- name: myself - user: - password: secret - username: admin -``` - -#### Commands for the example file - -```shell -$ kubectl config set preferences.colors true -$ kubectl config set-cluster cow-cluster --server=http://cow.org:8080 --api-version=v1 -$ kubectl config set-cluster horse-cluster --server=https://horse.org:4443 --certificate-authority=path/to/my/cafile -$ kubectl config set-cluster pig-cluster --server=https://pig.org:443 --insecure-skip-tls-verify=true -$ kubectl config set-credentials blue-user --token=blue-token -$ kubectl config set-credentials green-user --client-certificate=path/to/my/client/cert --client-key=path/to/my/client/key -$ kubectl config set-context queen-anne-context --cluster=pig-cluster --user=black-user --namespace=saw-ns -$ kubectl config set-context federal-context --cluster=horse-cluster --user=green-user --namespace=chisel-ns -$ kubectl config use-context federal-context -``` - -### Final notes for tying it all together - -So, tying this all together, a quick start to creating your own kubeconfig file: - -- Take a good look and understand how your api-server is being launched: You need to know YOUR security requirements and policies before you can design a kubeconfig file for convenient authentication. - -- Replace the snippet above with information for your cluster's api-server endpoint. - -- Make sure your api-server is launched in such a way that at least one user (i.e. green-user) credentials are provided to it. You will of course have to look at api-server documentation in order to determine the current state-of-the-art in terms of providing authentication details. From 0f14d69778421f5382159d0588dc8d33e0686db4 Mon Sep 17 00:00:00 2001 From: gbzhu Date: Wed, 28 Dec 2016 18:29:12 +0800 Subject: [PATCH 61/68] revert --- docs/user-guide/kubeconfig-file.md | 314 +++++++++++++++++++++++++++++ 1 file changed, 314 insertions(+) diff --git a/docs/user-guide/kubeconfig-file.md b/docs/user-guide/kubeconfig-file.md index e69de29bb2..fd44eaf999 100644 --- a/docs/user-guide/kubeconfig-file.md +++ b/docs/user-guide/kubeconfig-file.md @@ -0,0 +1,314 @@ +--- +assignees: +- mikedanese +- thockin +title: Authenticating Across Clusters with kubeconfig +--- + +Authentication in kubernetes can differ for different individuals. + +- A running kubelet might have one way of authenticating (i.e. certificates). +- Users might have a different way of authenticating (i.e. tokens). +- Administrators might have a list of certificates which they provide individual users. +- There may be multiple clusters, and we may want to define them all in one place - giving users the ability to use their own certificates and reusing the same global configuration. + +So in order to easily switch between multiple clusters, for multiple users, a kubeconfig file was defined. + +This file contains a series of authentication mechanisms and cluster connection information associated with nicknames. It also introduces the concept of a tuple of authentication information (user) and cluster connection information called a context that is also associated with a nickname. + +Multiple kubeconfig files are allowed, if specified explicitly. At runtime they are loaded and merged along with override options specified from the command line (see [rules](#loading-and-merging) below). + +## Related discussion + +http://issue.k8s.io/1755 + +## Components of a kubeconfig file + +### Example kubeconfig file + +```yaml +current-context: federal-context +apiVersion: v1 +clusters: +- cluster: + api-version: v1 + server: http://cow.org:8080 + name: cow-cluster +- cluster: + certificate-authority: path/to/my/cafile + server: https://horse.org:4443 + name: horse-cluster +- cluster: + insecure-skip-tls-verify: true + server: https://pig.org:443 + name: pig-cluster +contexts: +- context: + cluster: horse-cluster + namespace: chisel-ns + user: green-user + name: federal-context +- context: + cluster: pig-cluster + namespace: saw-ns + user: black-user + name: queen-anne-context +kind: Config +preferences: + colors: true +users: +- name: blue-user + user: + token: blue-token +- name: green-user + user: + client-certificate: path/to/my/client/cert + client-key: path/to/my/client/key +``` + +### Breakdown/explanation of components + +#### cluster + +```yaml +clusters: +- cluster: + certificate-authority: path/to/my/cafile + server: https://horse.org:4443 + name: horse-cluster +- cluster: + insecure-skip-tls-verify: true + server: https://pig.org:443 + name: pig-cluster +``` + +A `cluster` contains endpoint data for a kubernetes cluster. This includes the fully +qualified url for the kubernetes apiserver, as well as the cluster's certificate +authority or `insecure-skip-tls-verify: true`, if the cluster's serving +certificate is not signed by a system trusted certificate authority. +A `cluster` has a name (nickname) which acts as a dictionary key for the cluster +within this kubeconfig file. You can add or modify `cluster` entries using +[`kubectl config set-cluster`](/docs/user-guide/kubectl/kubectl_config_set-cluster/). + +#### user + +```yaml +users: +- name: blue-user + user: + token: blue-token +- name: green-user + user: + client-certificate: path/to/my/client/cert + client-key: path/to/my/client/key +``` + +A `user` defines client credentials for authenticating to a kubernetes cluster. A +`user` has a name (nickname) which acts as its key within the list of user entries +after kubeconfig is loaded/merged. Available credentials are `client-certificate`, +`client-key`, `token`, and `username/password`. `username/password` and `token` +are mutually exclusive, but client certs and keys can be combined with them. +You can add or modify `user` entries using +[`kubectl config set-credentials`](/docs/user-guide/kubectl/kubectl_config_set-credentials). + +#### context + +```yaml +contexts: +- context: + cluster: horse-cluster + namespace: chisel-ns + user: green-user + name: federal-context +``` + +A `context` defines a named [`cluster`](#cluster),[`user`](#user),[`namespace`](/docs/user-guide/namespaces) tuple +which is used to send requests to the specified cluster using the provided authentication info and +namespace. Each of the three is optional; it is valid to specify a context with only one of `cluster`, +`user`,`namespace`, or to specify none. Unspecified values, or named values that don't have corresponding +entries in the loaded kubeconfig (e.g. if the context specified a `pink-user` for the above kubeconfig file) +will be replaced with the default. See [Loading and merging rules](#loading-and-merging) below for override/merge behavior. +You can add or modify `context` entries with [`kubectl config set-context`](/docs/user-guide/kubectl/kubectl_config_set-context). + +#### current-context + +```yaml +current-context: federal-context +``` + +`current-context` is the nickname or 'key' for the cluster,user,namespace tuple that kubectl +will use by default when loading config from this file. You can override any of the values in kubectl +from the commandline, by passing `--context=CONTEXT`, `--cluster=CLUSTER`, `--user=USER`, and/or `--namespace=NAMESPACE` respectively. +You can change the `current-context` with [`kubectl config use-context`](/docs/user-guide/kubectl/kubectl_config_use-context). + +#### miscellaneous + +```yaml +apiVersion: v1 +kind: Config +preferences: + colors: true +``` + +`apiVersion` and `kind` identify the version and schema for the client parser and should not +be edited manually. + +`preferences` specify optional (and currently unused) kubectl preferences. + +## Viewing kubeconfig files + +`kubectl config view` will display the current kubeconfig settings. By default +it will show you all loaded kubeconfig settings; you can filter the view to just +the settings relevant to the `current-context` by passing `--minify`. See +[`kubectl config view`](/docs/user-guide/kubectl/kubectl_config_view) for other options. + +## Building your own kubeconfig file + +NOTE, that if you are deploying k8s via kube-up.sh, you do not need to create your own kubeconfig files, the script will do it for you. + +In any case, you can easily use this file as a template to create your own kubeconfig files. + +So, lets do a quick walk through the basics of the above file so you can easily modify it as needed... + +The above file would likely correspond to an api-server which was launched using the `--token-auth-file=tokens.csv` option, where the tokens.csv file looked something like this: + +```conf +blue-user,blue-user,1 +mister-red,mister-red,2 +``` + +Also, since we have other users who validate using **other** mechanisms, the api-server would have probably been launched with other authentication options (there are many such options, make sure you understand which ones YOU care about before crafting a kubeconfig file, as nobody needs to implement all the different permutations of possible authentication schemes). + +- Since the user for the current context is "green-user", any client of the api-server using this kubeconfig file would naturally be able to log in successfully, because we are providing the green-user's client credentials. +- Similarly, we can operate as the "blue-user" if we choose to change the value of current-context. + +In the above scenario, green-user would have to log in by providing certificates, whereas blue-user would just provide the token. All this information would be handled for us by the + +## Loading and merging rules + +The rules for loading and merging the kubeconfig files are straightforward, but there are a lot of them. The final config is built in this order: + + 1. Get the kubeconfig from disk. This is done with the following hierarchy and merge rules: + + + If the `CommandLineLocation` (the value of the `kubeconfig` command line option) is set, use this file only. No merging. Only one instance of this flag is allowed. + + + Else, if `EnvVarLocation` (the value of `$KUBECONFIG`) is available, use it as a list of files that should be merged. + Merge files together based on the following rules. + Empty filenames are ignored. Files with non-deserializable content produced errors. + The first file to set a particular value or map key wins and the value or map key is never changed. + This means that the first file to set `CurrentContext` will have its context preserved. It also means that if two files specify a "red-user", only values from the first file's red-user are used. Even non-conflicting entries from the second file's "red-user" are discarded. + + + Otherwise, use HomeDirectoryLocation (`~/.kube/config`) with no merging. + 1. Determine the context to use based on the first hit in this chain + 1. command line argument - the value of the `context` command line option + 1. `current-context` from the merged kubeconfig file + 1. Empty is allowed at this stage + 1. Determine the cluster info and user to use. At this point, we may or may not have a context. They are built based on the first hit in this chain. (run it twice, once for user, once for cluster) + 1. command line argument - `user` for user name and `cluster` for cluster name + 1. If context is present, then use the context's value + 1. Empty is allowed + 1. Determine the actual cluster info to use. At this point, we may or may not have a cluster info. Build each piece of the cluster info based on the chain (first hit wins): + 1. command line arguments - `server`, `api-version`, `certificate-authority`, and `insecure-skip-tls-verify` + 1. If cluster info is present and a value for the attribute is present, use it. + 1. If you don't have a server location, error. + 1. Determine the actual user info to use. User is built using the same rules as cluster info, EXCEPT that you can only have one authentication technique per user. + 1. Load precedence is 1) command line flag, 2) user fields from kubeconfig + 1. The command line flags are: `client-certificate`, `client-key`, `username`, `password`, and `token`. + 1. If there are two conflicting techniques, fail. + 1. For any information still missing, use default values and potentially prompt for authentication information + 1. All file references inside of a kubeconfig file are resolved relative to the location of the kubeconfig file itself. When file references are presented on the command line + they are resolved relative to the current working directory. When paths are saved in the ~/.kube/config, relative paths are stored relatively while absolute paths are stored absolutely. + +Any path in a kubeconfig file is resolved relative to the location of the kubeconfig file itself. + + +## Manipulation of kubeconfig via `kubectl config ` + +In order to more easily manipulate kubeconfig files, there are a series of subcommands to `kubectl config` to help. +See [kubectl/kubectl_config.md](/docs/user-guide/kubectl/kubectl_config) for help. + +### Example + +```shell +$ kubectl config set-credentials myself --username=admin --password=secret +$ kubectl config set-cluster local-server --server=http://localhost:8080 +$ kubectl config set-context default-context --cluster=local-server --user=myself +$ kubectl config use-context default-context +$ kubectl config set contexts.default-context.namespace the-right-prefix +$ kubectl config view +``` + +produces this output + +```yaml +apiVersion: v1 +clusters: +- cluster: + server: http://localhost:8080 + name: local-server +contexts: +- context: + cluster: local-server + namespace: the-right-prefix + user: myself + name: default-context +current-context: default-context +kind: Config +preferences: {} +users: +- name: myself + user: + password: secret + username: admin +``` + +and a kubeconfig file that looks like this + +```yaml +apiVersion: v1 +clusters: +- cluster: + server: http://localhost:8080 + name: local-server +contexts: +- context: + cluster: local-server + namespace: the-right-prefix + user: myself + name: default-context +current-context: default-context +kind: Config +preferences: {} +users: +- name: myself + user: + password: secret + username: admin +``` + +#### Commands for the example file + +```shell +$ kubectl config set preferences.colors true +$ kubectl config set-cluster cow-cluster --server=http://cow.org:8080 --api-version=v1 +$ kubectl config set-cluster horse-cluster --server=https://horse.org:4443 --certificate-authority=path/to/my/cafile +$ kubectl config set-cluster pig-cluster --server=https://pig.org:443 --insecure-skip-tls-verify=true +$ kubectl config set-credentials blue-user --token=blue-token +$ kubectl config set-credentials green-user --client-certificate=path/to/my/client/cert --client-key=path/to/my/client/key +$ kubectl config set-context queen-anne-context --cluster=pig-cluster --user=black-user --namespace=saw-ns +$ kubectl config set-context federal-context --cluster=horse-cluster --user=green-user --namespace=chisel-ns +$ kubectl config use-context federal-context +``` + +### Final notes for tying it all together + +So, tying this all together, a quick start to creating your own kubeconfig file: + +- Take a good look and understand how your api-server is being launched: You need to know YOUR security requirements and policies before you can design a kubeconfig file for convenient authentication. + +- Replace the snippet above with information for your cluster's api-server endpoint. + +- Make sure your api-server is launched in such a way that at least one user (i.e. green-user) credentials are provided to it. You will of course have to look at api-server documentation in order to determine the current state-of-the-art in terms of providing authentication details. From 188885469b7bf83e31642467b5639410f2bb967c Mon Sep 17 00:00:00 2001 From: Gigi Sayfan Date: Wed, 28 Dec 2016 10:13:48 -0800 Subject: [PATCH 62/68] Recycling policy --> Reclaiming policy Persistent volumes have a reclaim policy ("persistentVolumeReclaimPolicy"). "Recycle" is just one of the possible reclaim policies. --- docs/user-guide/persistent-volumes/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/user-guide/persistent-volumes/index.md b/docs/user-guide/persistent-volumes/index.md index 35c68cb165..f48919cc05 100644 --- a/docs/user-guide/persistent-volumes/index.md +++ b/docs/user-guide/persistent-volumes/index.md @@ -195,9 +195,9 @@ class and can only be bound to PVCs that request no particular class. In the future after beta, the `volume.beta.kubernetes.io/storage-class` annotation will become an attribute. -### Recycling Policy +### Reclaiming Policy -Current recycling policies are: +Current reclaiming policies are: * Retain -- manual reclamation * Recycle -- basic scrub ("rm -rf /thevolume/*") From 797e030c0378b36ce2841e48cd85c4d095e305c5 Mon Sep 17 00:00:00 2001 From: Gigi Sayfan Date: Wed, 28 Dec 2016 14:21:54 -0800 Subject: [PATCH 63/68] Reclaiming policy -> Reclaim policy To match the API per @saad-ali's comment --- docs/user-guide/persistent-volumes/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/user-guide/persistent-volumes/index.md b/docs/user-guide/persistent-volumes/index.md index f48919cc05..e5091d1b9c 100644 --- a/docs/user-guide/persistent-volumes/index.md +++ b/docs/user-guide/persistent-volumes/index.md @@ -195,9 +195,9 @@ class and can only be bound to PVCs that request no particular class. In the future after beta, the `volume.beta.kubernetes.io/storage-class` annotation will become an attribute. -### Reclaiming Policy +### Reclaim Policy -Current reclaiming policies are: +Current reclaim policies are: * Retain -- manual reclamation * Recycle -- basic scrub ("rm -rf /thevolume/*") From bfca1137f3ca6cb810fc65b32a51073bebfc9995 Mon Sep 17 00:00:00 2001 From: devin-donnelly Date: Wed, 28 Dec 2016 14:56:47 -0800 Subject: [PATCH 64/68] Update tools.yml --- _data/tools.yml | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/_data/tools.yml b/_data/tools.yml index 6b743c2e95..f057cc7842 100644 --- a/_data/tools.yml +++ b/_data/tools.yml @@ -2,3 +2,17 @@ bigheader: "Tools" abstract: "Tools to help you use and enhance Kubernetes." toc: - docs/tools/index.md + +- title: Native Tools + section: + - docs/user-guide/kubectl/ + - docs/admin/federation/kubefed/ + - docs/user-guide/ui/ + +- title: Third-Party Tools + section: + - title: Helm + path: https://github.com/kubernetes/helm + - title: Kompose + path: https://github.com/kubernetes-incubator/kompose + From 7e54f57d455c31e348f6d102a97a205b15583e65 Mon Sep 17 00:00:00 2001 From: devin-donnelly Date: Wed, 28 Dec 2016 15:02:04 -0800 Subject: [PATCH 65/68] Update tools.yml --- _data/tools.yml | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/_data/tools.yml b/_data/tools.yml index f057cc7842..3f7b5047dc 100644 --- a/_data/tools.yml +++ b/_data/tools.yml @@ -5,9 +5,12 @@ toc: - title: Native Tools section: - - docs/user-guide/kubectl/ - - docs/admin/federation/kubefed/ - - docs/user-guide/ui/ + - title: Kubectl + path: docs/user-guide/kubectl/ + - title: Kubefed + path: docs/admin/federation/kubefed/ + - title: Kubernetes Dashboard + path: docs/user-guide/ui/ - title: Third-Party Tools section: From b3a6da7a90b91cb7b25656973fee37dbfea9e769 Mon Sep 17 00:00:00 2001 From: devin-donnelly Date: Wed, 28 Dec 2016 15:05:18 -0800 Subject: [PATCH 66/68] Update tools.yml --- _data/tools.yml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/_data/tools.yml b/_data/tools.yml index 3f7b5047dc..31c355e9b0 100644 --- a/_data/tools.yml +++ b/_data/tools.yml @@ -6,11 +6,11 @@ toc: - title: Native Tools section: - title: Kubectl - path: docs/user-guide/kubectl/ + path: /docs/user-guide/kubectl/ - title: Kubefed - path: docs/admin/federation/kubefed/ + path: /docs/admin/federation/kubefed/ - title: Kubernetes Dashboard - path: docs/user-guide/ui/ + path: /docs/user-guide/ui/ - title: Third-Party Tools section: From 92ee7b2e7e722d8cdb98c896d7e53bb07ddeaa97 Mon Sep 17 00:00:00 2001 From: devin-donnelly Date: Wed, 28 Dec 2016 15:06:03 -0800 Subject: [PATCH 67/68] Remove in-page TOC from Tools --- docs/tools/index.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/docs/tools/index.md b/docs/tools/index.md index a3bb48d34d..6bd370d9ee 100644 --- a/docs/tools/index.md +++ b/docs/tools/index.md @@ -3,10 +3,6 @@ assignees: - janetkuo title: Tools --- - -* TOC -{:toc} - ## Native Tools ### Kubectl From 6d8fc84c907e373f79252cd485ac3f8d120ba301 Mon Sep 17 00:00:00 2001 From: devin-donnelly Date: Wed, 28 Dec 2016 15:14:23 -0800 Subject: [PATCH 68/68] Update index.md --- docs/tools/index.md | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/docs/tools/index.md b/docs/tools/index.md index 6bd370d9ee..351b5968c1 100644 --- a/docs/tools/index.md +++ b/docs/tools/index.md @@ -3,26 +3,32 @@ assignees: - janetkuo title: Tools --- -## Native Tools -### Kubectl +Kubernetes contains several built-in tools to help you work with the Kubernetes system, and also supports third-party tooling. + +#### Native Tools + +Kubernetes contains the following built-in tools: + +##### Kubectl [`kubectl`](/docs/user-guide/kubectl/) is the command line tool for Kubernetes. It controls the Kubernetes cluster manager. -### Kubefed +##### Kubefed [`kubefed`](/docs/admin/federation/kubefed/) is the command line tool to help you administrate your federated clusters. - -### Dashboard +##### Dashboard [Dashboard](/docs/user-guide/ui/), the web-based user interface of Kubernetes, allows you to deploy containerized applications to a Kubernetes cluster, troubleshoot them, and manage the cluster and its resources itself. -## Third-Party Tools +#### Third-Party Tools -### Helm +Kubernetes supports various third-party tools. These include, but are not limited to: + +##### Helm [Kubernetes Helm](https://github.com/kubernetes/helm) is a tool for managing packages of pre-configured Kubernetes resources, aka Kubernetes charts. @@ -35,7 +41,7 @@ Use Helm to: * Intelligently manage your Kubernetes manifest files * Manage releases of Helm packages -### Kompose +##### Kompose [Kompose](https://github.com/kubernetes-incubator/kompose) is a tool to help users familiar with Docker Compose move to Kubernetes.

    flexVolume

    FlexVolume represents a generic volume resource that is provisioned/attached using a exec based plugin. This is an alpha feature and may change in future.

    FlexVolume represents a generic volume resource that is provisioned/attached using an exec based plugin. This is an alpha feature and may change in future.

    false

    v1.FlexVolumeSource

    flexVolume

    FlexVolume represents a generic volume resource that is provisioned/attached using a exec based plugin. This is an alpha feature and may change in future.

    FlexVolume represents a generic volume resource that is provisioned/attached using an exec based plugin. This is an alpha feature and may change in future.

    false

    v1.FlexVolumeSource

    path

    Path is a extended POSIX regex as defined by IEEE Std 1003.1, (i.e this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a /. If unspecified, the path defaults to a catch all sending traffic to the backend.

    Path is a extended POSIX regex as defined by IEEE Std 1003.1, (i.e. this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a /. If unspecified, the path defaults to a catch all sending traffic to the backend.

    false

    string

    path

    Path is an extended POSIX regex as defined by IEEE Std 1003.1, (i.e this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a /. If unspecified, the path defaults to a catch all sending traffic to the backend.

    Path is an extended POSIX regex as defined by IEEE Std 1003.1, (i.e. this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a /. If unspecified, the path defaults to a catch all sending traffic to the backend.

    false

    string

    path

    Path is an extended POSIX regex as defined by IEEE Std 1003.1, (i.e this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a /. If unspecified, the path defaults to a catch all sending traffic to the backend.

    Path is an extended POSIX regex as defined by IEEE Std 1003.1, (i.e. this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a /. If unspecified, the path defaults to a catch all sending traffic to the backend.

    false

    string

    path

    Path is an extended POSIX regex as defined by IEEE Std 1003.1, (i.e this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a /. If unspecified, the path defaults to a catch all sending traffic to the backend.

    Path is an extended POSIX regex as defined by IEEE Std 1003.1, (i.e. this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a /. If unspecified, the path defaults to a catch all sending traffic to the backend.

    false

    string

    path

    Path is an extended POSIX regex as defined by IEEE Std 1003.1, (i.e this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a /. If unspecified, the path defaults to a catch all sending traffic to the backend.

    Path is an extended POSIX regex as defined by IEEE Std 1003.1, (i.e. this follows the egrep/unix syntax, not the perl syntax) matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a /. If unspecified, the path defaults to a catch all sending traffic to the backend.

    false

    string