--type="LoadBalancer" --name="example-service"
diff --git a/docs/tutorials/kubernetes-basics/expose-intro.html b/docs/tutorials/kubernetes-basics/expose-intro.html
index 2d3c4d7bb4..f426009b23 100644
--- a/docs/tutorials/kubernetes-basics/expose-intro.html
+++ b/docs/tutorials/kubernetes-basics/expose-intro.html
@@ -32,7 +32,7 @@ title: Using a Service to Expose Your App
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)
diff --git a/docs/tutorials/stateful-application/basic-stateful-set.md b/docs/tutorials/stateful-application/basic-stateful-set.md
index 60a8a30652..ff16a5c62b 100644
--- a/docs/tutorials/stateful-application/basic-stateful-set.md
+++ b/docs/tutorials/stateful-application/basic-stateful-set.md
@@ -122,7 +122,7 @@ launching `web-1`. In fact, `web-1` is not launched until `web-0` is
[Running and Ready](/docs/user-guide/pod-states).
### Pods in a StatefulSet
-Unlike Pods in other controllers, the Pods in a StatefulSet have a unqiue
+Unlike Pods in other controllers, the Pods in a StatefulSet have a unique
ordinal index and a stable network identity.
#### Examining the Pod's Ordinal Index
@@ -177,7 +177,7 @@ Name: web-1.nginx
Address 1: 10.244.2.6
```
-The CNAME of the headless serivce points to SRV records (one for each Pod that
+The CNAME of the headless service points to SRV records (one for each Pod that
is Running and Ready). The SRV records point to A record entries that
contain the Pods' IP addresses.
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/stateless-application/expose-external-ip-address.md b/docs/tutorials/stateless-application/expose-external-ip-address.md
index 2d2e28d594..f21abf7e61 100644
--- a/docs/tutorials/stateless-application/expose-external-ip-address.md
+++ b/docs/tutorials/stateless-application/expose-external-ip-address.md
@@ -4,7 +4,7 @@ title: Exposing an External IP Address to Access an Application in a Cluster
{% capture overview %}
-This page shows how to create a Kubernetes Service object that exposees an
+This page shows how to create a Kubernetes Service object that exposes an
external IP address.
{% endcapture %}
diff --git a/docs/user-guide/connecting-applications.md b/docs/user-guide/connecting-applications.md
index c4ca8d20f0..89a711ee6d 100644
--- a/docs/user-guide/connecting-applications.md
+++ b/docs/user-guide/connecting-applications.md
@@ -295,7 +295,7 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
Kubernetes also supports Federated Services, which can span multiple
clusters and cloud providers, to provide increased availability,
-bettern fault tolerance and greater scalability for your services. See
+better fault tolerance and greater scalability for your services. See
the [Federated Services User Guide](/docs/user-guide/federation/federated-services/)
for further information.
diff --git a/docs/user-guide/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/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/events.md b/docs/user-guide/federation/events.md
index f1f8868466..60c78ad9c5 100644
--- a/docs/user-guide/federation/events.md
+++ b/docs/user-guide/federation/events.md
@@ -24,7 +24,7 @@ general.
## Overview
-Events in federation control plane (refered to as "federation events" in
+Events in federation control plane (referred to as "federation events" in
this guide) are very similar to the traditional Kubernetes
Events providing the same functionality.
Federation Events are stored only in federation control plane and are not passed on to the underlying kubernetes clusters.
diff --git a/docs/user-guide/federation/federated-services.md b/docs/user-guide/federation/federated-services.md
index 354fbeca01..b163ad18e8 100644
--- a/docs/user-guide/federation/federated-services.md
+++ b/docs/user-guide/federation/federated-services.md
@@ -232,7 +232,7 @@ due to caching by intermediate DNS servers.
The above set of DNS records is automatically kept in sync with the
current state of health of all service shards globally by the
Federated Service system. DNS resolver libraries (which are invoked by
-all clients) automatically traverse the hiearchy of 'CNAME' and 'A'
+all clients) automatically traverse the hierarchy of 'CNAME' and 'A'
records to return the correct set of healthy IP addresses. Clients can
then select any one of the returned addresses to initiate a network
connection (and fail over automatically to one of the other equivalent
@@ -295,7 +295,7 @@ availability zones and regions other than the ones local to a Pod by
specifying the appropriate DNS names explicitly, and not relying on
automatic DNS expansion. For example,
"nginx.mynamespace.myfederation.svc.europe-west1.example.com" will
-resolve to all of the currently healthy service shards in europe, even
+resolve to all of the currently healthy service shards in Europe, even
if the Pod issuing the lookup is located in the U.S., and irrespective
of whether or not there are healthy shards of the service in the U.S.
This is useful for remote monitoring and other similar applications.
@@ -316,7 +316,7 @@ us.nginx.acme.com CNAME nginx.mynamespace.myfederation.svc.us-central1.ex
nginx.acme.com CNAME nginx.mynamespace.myfederation.svc.example.com.
```
That way your clients can always use the short form on the left, and
-always be automatcally routed to the closest healthy shard on their
+always be automatically routed to the closest healthy shard on their
home continent. All of the required failover is handled for you
automatically by Kubernetes Cluster Federation. Future releases will
improve upon this even further.
diff --git a/docs/user-guide/jobs.md b/docs/user-guide/jobs.md
index 0d71bc5e56..4feae7a1c4 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
@@ -166,7 +166,7 @@ parallelism, for a variety or reasons:
- If the controller failed to create pods for any reason (lack of ResourceQuota, lack of permission, etc.),
then there may be fewer pods than requested.
- The controller may throttle new pod creation due to excessive previous pod failures in the same Job.
-- When a pod is gracefully shutdown, it make take time to stop.
+- When a pod is gracefully shutdown, it takes time to stop.
## Handling Pod and Container Failures
diff --git a/docs/user-guide/kubectl/kubectl_drain.md b/docs/user-guide/kubectl/kubectl_drain.md
index 712af40af7..b6eba48f59 100644
--- a/docs/user-guide/kubectl/kubectl_drain.md
+++ b/docs/user-guide/kubectl/kubectl_drain.md
@@ -11,7 +11,7 @@ Drain node in preparation for maintenance
Drain node in preparation for maintenance.
-The given node will be marked unschedulable to prevent new pods from arriving. 'drain' evicts the pods if the APIServer supports eviciton (http://kubernetes.io/docs/admin/disruptions/). Otherwise, it will use normal DELETE to delete the pods. The 'drain' evicts or deletes all pods except mirror pods (which cannot be deleted through the API server). If there are DaemonSet-managed pods, drain will not proceed without --ignore-daemonsets, and regardless it will not delete any DaemonSet-managed pods, because those pods would be immediately replaced by the DaemonSet controller, which ignores unschedulable markings. If there are any pods that are neither mirror pods nor managed by ReplicationController, ReplicaSet, DaemonSet, StatefulSet or Job, then drain will not delete any pods unless you use --force.
+The given node will be marked unschedulable to prevent new pods from arriving. 'drain' evicts the pods if the APIServer supports eviction (http://kubernetes.io/docs/admin/disruptions/). Otherwise, it will use normal DELETE to delete the pods. The 'drain' evicts or deletes all pods except mirror pods (which cannot be deleted through the API server). If there are DaemonSet-managed pods, drain will not proceed without --ignore-daemonsets, and regardless it will not delete any DaemonSet-managed pods, because those pods would be immediately replaced by the DaemonSet controller, which ignores unschedulable markings. If there are any pods that are neither mirror pods nor managed by ReplicationController, ReplicaSet, DaemonSet, StatefulSet or Job, then drain will not delete any pods unless you use --force.
'drain' waits for graceful termination. You should not operate on the machine until the command completes.
diff --git a/docs/user-guide/persistent-volumes/index.md b/docs/user-guide/persistent-volumes/index.md
index 8f9703000c..d16cecd208 100644
--- a/docs/user-guide/persistent-volumes/index.md
+++ b/docs/user-guide/persistent-volumes/index.md
@@ -497,7 +497,7 @@ parameters:
```
* `quobyteAPIServer`: API Server of Quobyte in the format `http(s)://api-server:7860`
-* `registry`: Quobyte registry to use to mount the volume. You can specifiy the registry as ``:`` pair or if you want to specify multiple registries you just have to put a comma between them e.q. ``:,:,:``. The host can be an IP address or if you have a working DNS you can also provide the DNS names.
+* `registry`: Quobyte registry to use to mount the volume. You can specify the registry as ``:`` pair or if you want to specify multiple registries you just have to put a comma between them e.q. ``:,:,:``. The host can be an IP address or if you have a working DNS you can also provide the DNS names.
* `adminSecretNamespace`: The namespace for `adminSecretName`. Default is "default".
* `adminSecretName`: secret that holds information about the Quobyte user and the password to authenticate agains the API server. The provided secret must have type "kubernetes.io/quobyte", e.g. created in this way:
```
diff --git a/docs/user-guide/pod-security-policy/index.md b/docs/user-guide/pod-security-policy/index.md
index c2de42162c..46db299311 100644
--- a/docs/user-guide/pod-security-policy/index.md
+++ b/docs/user-guide/pod-security-policy/index.md
@@ -6,7 +6,7 @@ title: Pod Security Policies
Objects of type `podsecuritypolicy` govern the ability
to make requests on a pod that affect the `SecurityContext` that will be
-applied to a pod and container.
+applied to a pod and container.
See [PodSecurityPolicy proposal](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/proposals/security-context-constraints.md) for more information.
diff --git a/docs/user-guide/pods/index.md b/docs/user-guide/pods/index.md
index b18ae485e3..6bea334dec 100644
--- a/docs/user-guide/pods/index.md
+++ b/docs/user-guide/pods/index.md
@@ -10,7 +10,7 @@ title: Pods
_pods_ are the smallest deployable units of computing that can be created and
managed in Kubernetes.
-## What is a pod?
+## What is a Pod?
A _pod_ (as in a pod of whales or pea pod) is a group of one or more containers
(such as Docker containers), the shared storage for those containers, and
diff --git a/docs/user-guide/pods/init-container.md b/docs/user-guide/pods/init-container.md
index c9266baf67..e5319b7018 100644
--- a/docs/user-guide/pods/init-container.md
+++ b/docs/user-guide/pods/init-container.md
@@ -159,7 +159,7 @@ reasons:
* This is uncommon and would have to be done by someone with root access to nodes.
* All containers in a pod are terminated, requiring a restart (RestartPolicyAlways) AND the record of init container completion has been lost due to garbage collection.
-## Support and compatibilty
+## Support and compatibility
A cluster with Kubelet and Apiserver version 1.4.0 or greater supports init
containers with the beta annotations. Support varies for other combinations of
diff --git a/docs/user-guide/replicasets.md b/docs/user-guide/replicasets.md
index 86e60cffda..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..3b91828535 100644
--- a/docs/user-guide/replication-controller/index.md
+++ b/docs/user-guide/replication-controller/index.md
@@ -8,30 +8,30 @@ title: Replication Controller
* TOC
{:toc}
-## What is a replication controller?
+## What is a ReplicationController?
-A _replication controller_ ensures that a specified number of pod "replicas" are running at any one
-time. In other words, a replication controller makes sure that a pod or homogeneous set of pods are
+A _ReplicationController_ ensures that a specified number of pod "replicas" are running at any one
+time. In other words, a ReplicationController makes sure that a pod or homogeneous set of pods are
always up and available.
If there are too many pods, it will kill some. If there are too few, the
-replication controller will start more. Unlike manually created pods, the pods maintained by a
-replication controller are automatically replaced if they fail, get deleted, or are terminated.
+ReplicationController will start more. Unlike manually created pods, the pods maintained by a
+ReplicationController are automatically replaced if they fail, get deleted, or are terminated.
For example, your pods get re-created on a node after disruptive maintenance such as a kernel upgrade.
-For this reason, we recommend that you use a replication controller even if your application requires
-only a single pod. You can think of a replication controller as something similar to a process supervisor,
-but rather than individual processes on a single node, the replication controller supervises multiple pods
+For this reason, we recommend that you use a ReplicationController even if your application requires
+only a single pod. You can think of a ReplicationController as something similar to a process supervisor,
+but rather than individual processes on a single node, the ReplicationController supervises multiple pods
across multiple nodes.
-Replication Controller is often abbreviated to "rc" or "rcs" in discussion, and as a shortcut in
+ReplicationController is often abbreviated to "rc" or "rcs" in discussion, and as a shortcut in
kubectl commands.
-A simple case is to create 1 Replication Controller object in order to reliably run one instance of
+A simple case is to create 1 ReplicationController object in order to reliably run one instance of
a Pod indefinitely. A more complex use case is to run several identical replicas of a replicated
service, such as web servers.
-## Running an example Replication Controller
+## Running an example ReplicationController
-Here is an example Replication Controller config. It runs 3 copies of the nginx web server.
+Here is an example ReplicationController config. It runs 3 copies of the nginx web server.
{% include code.html language="yaml" file="replication.yaml" ghlink="/docs/user-guide/replication.yaml" %}
@@ -42,7 +42,7 @@ $ kubectl create -f ./replication.yaml
replicationcontrollers/nginx
```
-Check on the status of the replication controller using this command:
+Check on the status of the ReplicationController using this command:
```shell
$ kubectl describe replicationcontrollers/nginx
@@ -79,18 +79,18 @@ echo $pods
nginx-3ntk0 nginx-4ok8v nginx-qrm3m
```
-Here, the selector is the same as the selector for the replication controller (seen in the
+Here, the selector is the same as the selector for the ReplicationController (seen in the
`kubectl describe` output, and in a different form in `replication.yaml`. The `--output=jsonpath` option
specifies an expression that just gets the name from each pod in the returned list.
-## Writing a Replication Controller Spec
+## Writing a ReplicationController Spec
As with all other Kubernetes config, a Job needs `apiVersion`, `kind`, and `metadata` fields. For
general information about working with config files, see [here](/docs/user-guide/simple-yaml/),
[here](/docs/user-guide/configuring-containers/), and [here](/docs/user-guide/working-with-resources/).
-A Replication Controller also needs a [`.spec` section](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status).
+A ReplicationController also needs a [`.spec` section](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status).
### Pod Template
@@ -100,28 +100,28 @@ The `.spec.template` is a [pod template](#pod-template). It has exactly
the same schema as a [pod](/docs/user-guide/pods/), except it is nested and does not have an `apiVersion` or
`kind`.
-In addition to required fields for a Pod, a pod template in a Replication Controller must specify appropriate
+In addition to required fields for a Pod, a pod template in a ReplicationController must specify appropriate
labels (i.e. don't overlap with other controllers, see [pod selector](#pod-selector)) and an appropriate restart policy.
Only a [`.spec.template.spec.restartPolicy`](/docs/user-guide/pod-states/) equal to `Always` is allowed, which is the default
if not specified.
-For local container restarts, replication controllers delegate to an agent on the node,
+For local container restarts, ReplicationControllers delegate to an agent on the node,
for example the [Kubelet](/docs/admin/kubelet/) or Docker.
-### Labels on the Replication Controller
+### Labels on the ReplicationController
-The replication controller can itself have labels (`.metadata.labels`). Typically, you
+The ReplicationController can itself have labels (`.metadata.labels`). Typically, you
would set these the same as the `.spec.template.metadata.labels`; if `.metadata.labels` is not specified
then it is defaulted to `.spec.template.metadata.labels`. However, they are allowed to be
-different, and the `.metadata.labels` do not affect the behavior of the replication controller.
+different, and the `.metadata.labels` do not affect the behavior of the ReplicationController.
### Pod Selector
The `.spec.selector` field is a [label selector](/docs/user-guide/labels/#label-selectors). A replication
controller manages all the pods with labels which match the selector. It does not distinguish
between pods which it created or deleted versus pods which some other person or process created or
-deleted. This allows the replication controller to be replaced without affecting the running pods.
+deleted. This allows the ReplicationController to be replaced without affecting the running pods.
If specified, the `.spec.template.metadata.labels` must be equal to the `.spec.selector`, or it will
be rejected by the API. If `.spec.selector` is unspecified, it will be defaulted to
@@ -144,54 +144,54 @@ shutdown, and a replacement starts early.
If you do not specify `.spec.replicas`, then it defaults to 1.
-## Working with Replication Controllers
+## Working with ReplicationControllers
-### Deleting a Replication Controller and its Pods
+### Deleting a ReplicationController and its Pods
-To delete a replication controller and all its pods, use [`kubectl
-delete`](/docs/user-guide/kubectl/kubectl_delete/). Kubectl will scale the replication controller to zero and wait
-for it to delete each pod before deleting the replication controller itself. If this kubectl
+To delete a ReplicationController and all its pods, use [`kubectl
+delete`](/docs/user-guide/kubectl/kubectl_delete/). Kubectl will scale the ReplicationController to zero and wait
+for it to delete each pod before deleting the ReplicationController itself. If this kubectl
command is interrupted, it can be restarted.
When using the REST API or go client library, you need to do the steps explicitly (scale replicas to
-0, wait for pod deletions, then delete the replication controller).
+0, wait for pod deletions, then delete the ReplicationController).
-### Deleting just a Replication Controller
+### Deleting just a ReplicationController
-You can delete a replication controller without affecting any of its pods.
+You can delete a ReplicationController without affecting any of its pods.
Using kubectl, specify the `--cascade=false` option to [`kubectl delete`](/docs/user-guide/kubectl/kubectl_delete/).
-When using the REST API or go client library, simply delete the replication controller object.
+When using the REST API or go client library, simply delete the ReplicationController object.
-Once the original is deleted, you can create a new replication controller to replace it. As long
+Once the original is deleted, you can create a new ReplicationController to replace it. As long
as the old and new `.spec.selector` are the same, then the new one will adopt the old pods.
However, it will not make any effort to make existing pods match a new, different pod template.
To update pods to a new spec in a controlled way, use a [rolling update](#rolling-updates).
-### Isolating pods from a Replication Controller
+### Isolating pods from a ReplicationController
-Pods may be removed from a replication controller's target set by changing their labels. This technique may be used to remove pods from service for debugging, data recovery, etc. Pods that are removed in this way will be replaced automatically (assuming that the number of replicas is not also changed).
+Pods may be removed from a ReplicationController's target set by changing their labels. This technique may be used to remove pods from service for debugging, data recovery, etc. Pods that are removed in this way will be replaced automatically (assuming that the number of replicas is not also changed).
## Common usage patterns
### Rescheduling
-As mentioned above, whether you have 1 pod you want to keep running, or 1000, a replication controller will ensure that the specified number of pods exists, even in the event of node failure or pod termination (e.g., due to an action by another control agent).
+As mentioned above, whether you have 1 pod you want to keep running, or 1000, a ReplicationController will ensure that the specified number of pods exists, even in the event of node failure or pod termination (e.g., due to an action by another control agent).
### Scaling
-The replication controller makes it easy to scale the number of replicas up or down, either manually or by an auto-scaling control agent, by simply updating the `replicas` field.
+The ReplicationController makes it easy to scale the number of replicas up or down, either manually or by an auto-scaling control agent, by simply updating the `replicas` field.
### Rolling updates
-The replication controller is designed to facilitate rolling updates to a service by replacing pods one-by-one.
+The ReplicationController is designed to facilitate rolling updates to a service by replacing pods one-by-one.
-As explained in [#1353](http://issue.k8s.io/1353), the recommended approach is to create a new replication controller with 1 replica, scale the new (+1) and old (-1) controllers one by one, and then delete the old controller after it reaches 0 replicas. This predictably updates the set of pods regardless of unexpected failures.
+As explained in [#1353](http://issue.k8s.io/1353), the recommended approach is to create a new ReplicationController with 1 replica, scale the new (+1) and old (-1) controllers one by one, and then delete the old controller after it reaches 0 replicas. This predictably updates the set of pods regardless of unexpected failures.
Ideally, the rolling update controller would take application readiness into account, and would ensure that a sufficient number of pods were productively serving at any given time.
-The two replication controllers would need to create pods with at least one differentiating label, such as the image tag of the primary container of the pod, since it is typically image updates that motivate rolling updates.
+The two ReplicationControllers would need to create pods with at least one differentiating label, such as the image tag of the primary container of the pod, since it is typically image updates that motivate rolling updates.
Rolling update is implemented in the client tool
[`kubectl rolling-update`](/docs/user-guide/kubectl/kubectl_rolling-update). Visit [`kubectl rolling-update` tutorial](/docs/user-guide/rolling-updates/) for more concrete examples.
@@ -200,26 +200,26 @@ Rolling update is implemented in the client tool
In addition to running multiple releases of an application while a rolling update is in progress, it's common to run multiple releases for an extended period of time, or even continuously, using multiple release tracks. The tracks would be differentiated by labels.
-For instance, a service might target all pods with `tier in (frontend), environment in (prod)`. Now say you have 10 replicated pods that make up this tier. But you want to be able to 'canary' a new version of this component. You could set up a replication controller with `replicas` set to 9 for the bulk of the replicas, with labels `tier=frontend, environment=prod, track=stable`, and another replication controller with `replicas` set to 1 for the canary, with labels `tier=frontend, environment=prod, track=canary`. Now the service is covering both the canary and non-canary pods. But you can mess with the replication controllers separately to test things out, monitor the results, etc.
+For instance, a service might target all pods with `tier in (frontend), environment in (prod)`. Now say you have 10 replicated pods that make up this tier. But you want to be able to 'canary' a new version of this component. You could set up a ReplicationController with `replicas` set to 9 for the bulk of the replicas, with labels `tier=frontend, environment=prod, track=stable`, and another ReplicationController with `replicas` set to 1 for the canary, with labels `tier=frontend, environment=prod, track=canary`. Now the service is covering both the canary and non-canary pods. But you can mess with the ReplicationControllers separately to test things out, monitor the results, etc.
-### Using Replication Controllers with Services
+### Using ReplicationControllers with Services
-Multiple replication controllers can sit behind a single service, so that, for example, some traffic
+Multiple ReplicationControllers can sit behind a single service, so that, for example, some traffic
goes to the old version, and some goes to the new version.
-A replication controller will never terminate on its own, but it isn't expected to be as long-lived as services. Services may be composed of pods controlled by multiple replication controllers, and it is expected that many replication controllers may be created and destroyed over the lifetime of a service (for instance, to perform an update of pods that run the service). Both services themselves and their clients should remain oblivious to the replication controllers that maintain the pods of the services.
+A ReplicationController will never terminate on its own, but it isn't expected to be as long-lived as services. Services may be composed of pods controlled by multiple ReplicationControllers, and it is expected that many ReplicationControllers may be created and destroyed over the lifetime of a service (for instance, to perform an update of pods that run the service). Both services themselves and their clients should remain oblivious to the ReplicationControllers that maintain the pods of the services.
## Writing programs for Replication
-Pods created by a replication controller are intended to be fungible and semantically identical, though their configurations may become heterogeneous over time. This is an obvious fit for replicated stateless servers, but replication controllers can also be used to maintain availability of master-elected, sharded, and worker-pool applications. Such applications should use dynamic work assignment mechanisms, such as the [etcd lock module](https://coreos.com/docs/distributed-configuration/etcd-modules/) or [RabbitMQ work queues](https://www.rabbitmq.com/tutorials/tutorial-two-python.html), as opposed to static/one-time customization of the configuration of each pod, which is considered an anti-pattern. Any pod customization performed, such as vertical auto-sizing of resources (e.g., cpu or memory), should be performed by another online controller process, not unlike the replication controller itself.
+Pods created by a ReplicationController are intended to be fungible and semantically identical, though their configurations may become heterogeneous over time. This is an obvious fit for replicated stateless servers, but ReplicationControllers can also be used to maintain availability of master-elected, sharded, and worker-pool applications. Such applications should use dynamic work assignment mechanisms, such as the [etcd lock module](https://coreos.com/docs/distributed-configuration/etcd-modules/) or [RabbitMQ work queues](https://www.rabbitmq.com/tutorials/tutorial-two-python.html), as opposed to static/one-time customization of the configuration of each pod, which is considered an anti-pattern. Any pod customization performed, such as vertical auto-sizing of resources (e.g., cpu or memory), should be performed by another online controller process, not unlike the ReplicationController itself.
-## Responsibilities of the replication controller
+## Responsibilities of the ReplicationController
-The replication controller simply ensures that the desired number of pods matches its label selector and are operational. Currently, only terminated pods are excluded from its count. In the future, [readiness](http://issue.k8s.io/620) and other information available from the system may be taken into account, we may add more controls over the replacement policy, and we plan to emit events that could be used by external clients to implement arbitrarily sophisticated replacement and/or scale-down policies.
+The ReplicationController simply ensures that the desired number of pods matches its label selector and are operational. Currently, only terminated pods are excluded from its count. In the future, [readiness](http://issue.k8s.io/620) and other information available from the system may be taken into account, we may add more controls over the replacement policy, and we plan to emit events that could be used by external clients to implement arbitrarily sophisticated replacement and/or scale-down policies.
-The replication controller is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in [#492](http://issue.k8s.io/492)), which would change its `replicas` field. We will not add scheduling policies (e.g., [spreading](http://issue.k8s.io/367#issuecomment-48428019)) to the replication controller. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsewhere. We even plan to factor out the mechanism for bulk pod creation ([#170](http://issue.k8s.io/170)).
+The ReplicationController is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in [#492](http://issue.k8s.io/492)), which would change its `replicas` field. We will not add scheduling policies (e.g., [spreading](http://issue.k8s.io/367#issuecomment-48428019)) to the ReplicationController. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsewhere. We even plan to factor out the mechanism for bulk pod creation ([#170](http://issue.k8s.io/170)).
-The replication controller is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, stop, scale, rolling-update) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing replication controllers, auto-scalers, services, scheduling policies, canaries, etc.
+The ReplicationController is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, stop, scale, rolling-update) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing ReplicationControllers, auto-scalers, services, scheduling policies, canaries, etc.
## API Object
@@ -228,11 +228,11 @@ Replication controller is a top-level resource in the kubernetes REST API. More
API object can be found at: [ReplicationController API
object](/docs/api-reference/v1/definitions/#_v1_replicationcontroller).
-## Alternatives to Replication Controller
+## Alternatives to ReplicationController
### ReplicaSet
-[`ReplicaSet`](/docs/user-guide/replicasets/) is the next-generation Replication Controller that supports the new [set-based label selector](/docs/user-guide/labels/#set-based-requirement).
+[`ReplicaSet`](/docs/user-guide/replicasets/) is the next-generation ReplicationController that supports the new [set-based label selector](/docs/user-guide/labels/#set-based-requirement).
It’s mainly used by [`Deployment`](/docs/user-guide/deployments/) as a mechanism to orchestrate pod creation, deletion and updates.
Note that we recommend using Deployments instead of directly using Replica Sets, unless you require custom update orchestration or don’t require updates at all.
@@ -244,20 +244,20 @@ because unlike `kubectl rolling-update`, they are declarative, server-side, and
### Bare Pods
-Unlike in the case where a user directly created pods, a replication controller replaces pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a replication controller even if your application requires only a single pod. Think of it similarly to a process supervisor, only it supervises multiple pods across multiple nodes instead of individual processes on a single node. A replication controller delegates local container restarts to some agent on the node (e.g., Kubelet or Docker).
+Unlike in the case where a user directly created pods, a ReplicationController replaces pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a ReplicationController even if your application requires only a single pod. Think of it similarly to a process supervisor, only it supervises multiple pods across multiple nodes instead of individual processes on a single node. A ReplicationController delegates local container restarts to some agent on the node (e.g., Kubelet or Docker).
### Job
-Use a [`Job`](/docs/user-guide/jobs/) instead of a replication controller for pods that are expected to terminate on their own
+Use a [`Job`](/docs/user-guide/jobs/) instead of a ReplicationController for pods that are expected to terminate on their own
(i.e. batch jobs).
### DaemonSet
-Use a [`DaemonSet`](/docs/admin/daemons/) instead of a replication controller for pods that provide a
+Use a [`DaemonSet`](/docs/admin/daemons/) instead of a ReplicationController for pods that provide a
machine-level function, such as machine monitoring or machine logging. These pods have a lifetime that is tied
to a machine lifetime: the pod needs to be running on the machine before other pods start, and are
safe to terminate when the machine is otherwise ready to be rebooted/shutdown.
## For more information
-Read [Replication Controller Operations](/docs/user-guide/replication-controller/operations/).
+Read [ReplicationController Operations](/docs/user-guide/replication-controller/operations/).
diff --git a/docs/user-guide/secrets/index.md b/docs/user-guide/secrets/index.md
index 79b6d93a7d..6f6728db42 100644
--- a/docs/user-guide/secrets/index.md
+++ b/docs/user-guide/secrets/index.md
@@ -666,7 +666,7 @@ one called, say, `prod-user` with the `prod-db-secret`, and one called, say,
### Use-case: Dotfiles in secret volume
-In order to make piece of data 'hidden' (ie, in a file whose name begins with a dot character), simply
+In order to make piece of data 'hidden' (i.e., in a file whose name begins with a dot character), simply
make that key begin with a dot. For example, when the following secret is mounted into a volume:
```json
diff --git a/docs/user-guide/services/index.md b/docs/user-guide/services/index.md
index 8151eebab9..60fa80e2e7 100644
--- a/docs/user-guide/services/index.md
+++ b/docs/user-guide/services/index.md
@@ -500,7 +500,7 @@ within AWS Certificate Manager.
},
```
-The second annotation specificies which protocol a pod speaks. For HTTPS and
+The second annotation specifies which protocol a pod speaks. For HTTPS and
SSL, the ELB will expect the pod to authenticate itself over the encrypted
connection.
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..dde25433de 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 Cloud](http://eldarion.cloud/). You could also roll your own custom PaaS, integrate with a CI system of your choice, or get along just fine with just Kubernetes: bring your container images and deploy them on Kubernetes.
Since Kubernetes operates at the application level rather than at just the hardware level, it provides some generally applicable features common to PaaS offerings, such as deployment, scaling, load balancing, logging, monitoring, etc. However, Kubernetes is not monolithic, and these default solutions are optional and pluggable.
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.