@@ -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.
- “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
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.
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 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/accessing-the-api.md b/docs/admin/accessing-the-api.md
index c8f239969f..a70f1c0920 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
@@ -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/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/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/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/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
diff --git a/docs/admin/authorization.md b/docs/admin/authorization.md
index 0387a101ed..34ae301437 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-components.md b/docs/admin/cluster-components.md
index 0b913d8956..aa79489bbb 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
diff --git a/docs/admin/cluster-management.md b/docs/admin/cluster-management.md
index b1c4c340a3..5bcdb8b8f3 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.
@@ -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/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 90637239b3..4682a62b71 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,11 +125,11 @@ 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
-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:
@@ -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/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/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/federation/index.md b/docs/admin/federation/index.md
index 478f7563de..59a0199d7b 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
@@ -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/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.
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-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.
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/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..258db1e3aa 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.
@@ -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/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/multi-cluster.md b/docs/admin/multi-cluster.md
index 1d238d8e13..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
@@ -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/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/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/admin/networking.md b/docs/admin/networking.md
index c8a8c53d9c..e1de39fdbd 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/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:
diff --git a/docs/admin/node.md b/docs/admin/node.md
index a18aaf5ca7..cbb70229e7 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
@@ -236,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/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..ba3633e83b 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.
@@ -50,11 +50,10 @@ 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
* `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/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/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/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
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 |
|
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/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
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 |
|
diff --git a/docs/getting-started-guides/clc.md b/docs/getting-started-guides/clc.md
index ab45ffbf8f..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.
@@ -207,18 +207,18 @@ 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.
* 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
-* Unbuntu 14.04
+* Ubuntu 14.04
* Flannel 0.5.4
* Docker 1.9.1-0~trusty
* Etcd 2.2.2
@@ -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/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/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/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/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/libvirt-coreos.md b/docs/getting-started-guides/libvirt-coreos.md
index 73be7e4261..ca2e9e7d75 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;
@@ -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/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..ca34d32753 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.
+Let'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`
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/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/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/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/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/getting-started-guides/scratch.md b/docs/getting-started-guides/scratch.md
index dd554c5715..44ff8112c6 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
@@ -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/automated.md b/docs/getting-started-guides/ubuntu/automated.md
index 21c25e1c3c..d82c4ca545 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
@@ -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.
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/getting-started-guides/ubuntu/manual.md b/docs/getting-started-guides/ubuntu/manual.md
index e5a849d909..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.
@@ -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.
@@ -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/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.
diff --git a/docs/getting-started-guides/windows/index.md b/docs/getting-started-guides/windows/index.md
index 3096bed7eb..dd775b81af 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 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.
+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
diff --git a/docs/hellonode.md b/docs/hellonode.md
index 412e495c11..fcb8eec480 100755
--- a/docs/hellonode.md
+++ b/docs/hellonode.md
@@ -12,7 +12,7 @@ title: Hello World on Google Container Engine
The goal of this codelab is for you to turn a simple Hello World node.js app into a replicated application running on Kubernetes. We will show 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 [Google Container Engine](https://cloud.google.com/container-engine/).
-Here’s a diagram of the various parts in play in this codelab to help you understand how pieces fit with one another. Use this as a reference as we progress through the codelab; it should all make sense by the time we get to the end.
+Here's a diagram of the various parts in play in this codelab to help you understand how pieces fit with one another. Use this as a reference as we progress through the codelab; it should all make sense by the time we get to the end.
@@ -38,7 +38,7 @@ export PROJECT_ID="your-project-id"
Next, [enable billing](https://console.cloud.google.com/billing) in the Cloud Console in order to use Google Cloud resources and [enable the Container Engine API](https://console.cloud.google.com/project/_/kubernetes/list).
-New users of Google Cloud Platform receive a [$300 free trial](https://console.cloud.google.com/billing/freetrial?hl=en). Running through this codelab shouldn’t cost you more than a few dollars of that trial. Google Container Engine pricing is documented [here](https://cloud.google.com/container-engine/pricing).
+New users of Google Cloud Platform receive a [$300 free trial](https://console.cloud.google.com/billing/freetrial?hl=en). Running through this codelab shouldn't cost you more than a few dollars of that trial. Google Container Engine pricing is documented [here](https://cloud.google.com/container-engine/pricing).
Next, make sure you [download Node.js](https://nodejs.org/en/download/). You can skip this and the steps for installing Docker and Cloud SDK if you're using Cloud Shell.
@@ -79,7 +79,7 @@ You should be able to see your "Hello World!" message at http://localhost:8080/.
Stop the running node server by pressing Ctrl-C.
-Now let’s package this application in a Docker container.
+Now let's package this application in a Docker container.
## Create a Docker container image
@@ -109,7 +109,7 @@ Let's try your image out with Docker:
docker run -d -p 8080:8080 --name hello_tutorial gcr.io/$PROJECT_ID/hello-node:v1
```
-Visit your app in the browser, or use `curl` or `wget` if you’d like :
+Visit your app in the browser, or use `curl` or `wget` if you'd like :
```shell
curl http://localhost:8080
@@ -123,7 +123,7 @@ You should see `Hello World!`
curl "http://$(docker-machine ip YOUR-VM-MACHINE-NAME):8080"
```
-Let’s now stop the container. You can list the docker containers with:
+Let's now stop the container. You can list the docker containers with:
```shell
docker ps
@@ -180,7 +180,7 @@ You should get a Kubernetes cluster with three nodes, ready to receive your cont
-It’s now time to deploy your own containerized application to the Kubernetes cluster!
+It's now time to deploy your own containerized application to the Kubernetes cluster!
```shell
gcloud container clusters get-credentials hello-world
@@ -258,7 +258,7 @@ kubectl expose deployment hello-node --type="LoadBalancer"
**If this fails, make sure your client and server are both version 1.3. See the [Create your cluster](#create-your-cluster) section for details.**
-The flag used in this command specifies that we’ll be using the load-balancer provided by the underlying infrastructure (in this case the [Compute Engine load balancer](https://cloud.google.com/compute/docs/load-balancing/)). Note that we expose the deployment, and not the pod directly. This will cause the resulting service to load balance traffic across all pods managed by the deployment (in this case only 1 pod, but we will add more replicas later).
+The flag used in this command specifies that we'll be using the load-balancer provided by the underlying infrastructure (in this case the [Compute Engine load balancer](https://cloud.google.com/compute/docs/load-balancing/)). Note that we expose the deployment, and not the pod directly. This will cause the resulting service to load balance traffic across all pods managed by the deployment (in this case only 1 pod, but we will add more replicas later).
The Kubernetes master creates the load balancer and related Compute Engine forwarding rules, target pools, and firewall rules to make the service fully accessible from outside of Google Cloud Platform.
@@ -322,7 +322,7 @@ hello-node-714049816-ztzrb 1/1 Running 0 41m
Note the **declarative approach** here - rather than starting or stopping new instances you declare how many instances you want to be running. Kubernetes reconciliation loops simply make sure the reality matches what you requested and take action if needed.
-Here’s a diagram summarizing the state of our Kubernetes cluster:
+Here's a diagram summarizing the state of our Kubernetes cluster:
@@ -330,7 +330,7 @@ Here’s a diagram summarizing the state of our Kubernetes cluster:
As always, the application you deployed to production requires bug fixes or additional features. Kubernetes is here to help you deploy a new version to production without impacting your users.
-First, let’s modify the application. On the development machine, edit server.js and update the response message:
+First, let's modify the application. On the development machine, edit server.js and update the response message:
```javascript
response.end('Hello Kubernetes World!');
@@ -345,7 +345,7 @@ gcloud docker -- push gcr.io/$PROJECT_ID/hello-node:v2
Building and pushing this updated image should be much quicker as we take full advantage of the Docker cache.
-We’re now ready for Kubernetes to smoothly update our deployment to the new version of the application. In order to change
+We're now ready for Kubernetes to smoothly update our deployment to the new version of the application. In order to change
the image label for our running container, we will need to edit the existing *hello-node deployment* and change the image from
`gcr.io/$PROJECT_ID/hello-node:v1` to `gcr.io/$PROJECT_ID/hello-node:v2`. To do this, we will use the `kubectl set image` command.
@@ -364,7 +364,7 @@ hello-node 4 5 4 3 1h
While this is happening, the users of the services should not see any interruption. After a little while they will start accessing the new version of your application. You can find more details in the [deployment documentation](/docs/user-guide/deployments/).
-Hopefully with these deployment, scaling and update features you’ll agree that once you’ve setup your environment (your GKE/Kubernetes cluster here), Kubernetes is here to help you focus on the application rather than the infrastructure.
+Hopefully with these deployment, scaling and update features you'll agree that once you've setup your environment (your GKE/Kubernetes cluster here), Kubernetes is here to help you focus on the application rather than the infrastructure.
## Observe the Kubernetes Web UI (optional)
diff --git a/docs/reporting-security-issues.md b/docs/reporting-security-issues.md
index f9742534af..52a0abd43f 100644
--- a/docs/reporting-security-issues.md
+++ b/docs/reporting-security-issues.md
@@ -5,24 +5,4 @@ assignees:
title: Report a Security Vulnerability
---
-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/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/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
```
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/tools/index.md b/docs/tools/index.md
index a3bb48d34d..351b5968c1 100644
--- a/docs/tools/index.md
+++ b/docs/tools/index.md
@@ -4,29 +4,31 @@ assignees:
title: Tools
---
-* TOC
-{:toc}
+Kubernetes contains several built-in tools to help you work with the Kubernetes system, and also supports third-party tooling.
-## Native Tools
+#### Native Tools
-### Kubectl
+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.
@@ -39,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.
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/tutorials/kubernetes-basics/cluster-intro.html b/docs/tutorials/kubernetes-basics/cluster-intro.html
index 6009a55aeb..830b651594 100644
--- a/docs/tutorials/kubernetes-basics/cluster-intro.html
+++ b/docs/tutorials/kubernetes-basics/cluster-intro.html
@@ -90,7 +90,7 @@ title: Using Minikube to Create a Cluster
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..9ee7a4117a 100644
--- a/docs/tutorials/kubernetes-basics/expose-intro.html
+++ b/docs/tutorials/kubernetes-basics/expose-intro.html
@@ -28,11 +28,11 @@ 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:
- - 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 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)
@@ -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/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/tutorials/stateful-application/basic-stateful-set.md b/docs/tutorials/stateful-application/basic-stateful-set.md
index 07e41cd56d..e17f67e3fb 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.
@@ -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
```
@@ -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.
@@ -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 %}
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
diff --git a/docs/tutorials/stateful-application/zookeeper.md b/docs/tutorials/stateful-application/zookeeper.md
index 90a78fdc31..44ae82e668 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.
@@ -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.
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/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/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/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:
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);
diff --git a/docs/user-guide/accessing-the-cluster.md b/docs/user-guide/accessing-the-cluster.md
index 8206ee8f85..8fb9e6b0b4 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.
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/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/connecting-applications.md b/docs/user-guide/connecting-applications.md
index 95d365bdb1..adc47a64b4 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.
@@ -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" %}
@@ -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/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
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/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!
diff --git a/docs/user-guide/deployments.md b/docs/user-guide/deployments.md
index c53c1e19ae..0b4ae0d85a 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.
@@ -413,7 +445,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*.
@@ -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
@@ -568,7 +600,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:
@@ -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
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 f1f8868466..1d9f72ea0e 100644
--- a/docs/user-guide/federation/events.md
+++ b/docs/user-guide/federation/events.md
@@ -24,10 +24,10 @@ 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.
+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/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/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/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/jobs.md b/docs/user-guide/jobs.md
index 0d71bc5e56..d8476d73d5 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
@@ -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
@@ -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/jobs/expansions/index.md b/docs/user-guide/jobs/expansions/index.md
index 70eb90a623..767ac65215 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:
@@ -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/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/kubeconfig-file.md b/docs/user-guide/kubeconfig-file.md
index 3f861ef2d2..fd44eaf999 100644
--- a/docs/user-guide/kubeconfig-file.md
+++ b/docs/user-guide/kubeconfig-file.md
@@ -5,310 +5,310 @@ assignees:
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.
+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.
diff --git a/docs/user-guide/kubectl-overview.md b/docs/user-guide/kubectl-overview.md
index 99c1575e84..2fa249c5f6 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` |
@@ -108,6 +109,7 @@ Resource type | Abbreviated alias
`secrets` |
`serviceaccounts` |`sa`
`services` |`svc`
+`statefulsets` |
`storageclasses` |
`thirdpartyresources` |
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_drain.md b/docs/user-guide/kubectl/kubectl_drain.md
index 712af40af7..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 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.
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
+
```
kubectl drain NODE
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/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.
-
-
-[]()
-
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.
-
-
-[]()
-
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/managing-deployments.md b/docs/user-guide/managing-deployments.md
index 2555e5601c..fc32a5bb46 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
```
@@ -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.
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/persistent-volumes/index.md b/docs/user-guide/persistent-volumes/index.md
index 8f9703000c..e5091d1b9c 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
@@ -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 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
@@ -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 | - |
@@ -193,15 +195,15 @@ 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
+### Reclaim Policy
-Current recycling policies are:
+Current reclaim 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
@@ -497,7 +499,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:
```
@@ -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
diff --git a/docs/user-guide/petset.md b/docs/user-guide/petset.md
index 3cba1fb31e..3247cf5a42 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.
@@ -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
@@ -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
diff --git a/docs/user-guide/pod-security-policy/index.md b/docs/user-guide/pod-security-policy/index.md
index c2de42162c..6a756c4766 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.
@@ -26,7 +26,7 @@ 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
diff --git a/docs/user-guide/pods/index.md b/docs/user-guide/pods/index.md
index b18ae485e3..321900c948 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
@@ -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/init-container.md b/docs/user-guide/pods/init-container.md
index 75b6efcac3..e5319b7018 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
@@ -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/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 4be0d6a188..19e6d8612b 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
@@ -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/replicasets.md b/docs/user-guide/replicasets.md
index f0aa08bf04..769ea58c02 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,22 @@ 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 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
-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
+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 +50,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 +77,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..0fee281cdb 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,42 +200,43 @@ 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
-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).
-## 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.
+
### Deployment (Recommended)
[`Deployment`](/docs/user-guide/deployments/) is a higher-level API object that updates its underlying Replica Sets and their Pods
@@ -244,20 +245,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/).
diff --git a/docs/user-guide/secrets/index.md b/docs/user-guide/secrets/index.md
index 79b6d93a7d..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
@@ -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/security-context.md b/docs/user-guide/security-context.md
index 3d216447ca..c95a14b9b0 100644
--- a/docs/user-guide/security-context.md
+++ b/docs/user-guide/security-context.md
@@ -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
@@ -85,4 +85,3 @@ Please refer to the
[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/docs/user-guide/services/index.md b/docs/user-guide/services/index.md
index 8151eebab9..cd9303bd33 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.
@@ -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).
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
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
diff --git a/docs/user-guide/ui.md b/docs/user-guide/ui.md
index 20a0e7b3bc..de50ccde00 100644
--- a/docs/user-guide/ui.md
+++ b/docs/user-guide/ui.md
@@ -15,6 +15,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, run the following command:
+
+```
+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.
diff --git a/docs/whatisk8s.md b/docs/whatisk8s.md
index 7c1e637b6d..d84be65f74 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**:
@@ -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.
diff --git a/index.html b/index.html
index 728100db84..78b964ce39 100644
--- a/index.html
+++ b/index.html
@@ -80,7 +80,7 @@
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.
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
-
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 @@
-
+
-
+
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
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.
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
-