Release 1.7 (#4094)

* Minor fixes in the Deployment doc

Signed-off-by: Michail Kargakis <mkargaki@redhat.com>

* add NodeRestriction to admission-controllers (#3842)

* Admins Can Configure Zones in Storage Class

The PR #38505 (https://github.com/kubernetes/kubernetes/pull/38505) added zones optional parameter to Storage Class for AWS and GCE provisioners.

That's why documentation needs to be updated accordingly.

* document custom resource definitions

* add host paths to psp (#3971)

* add host paths to psp

* add italics

* Update ConfigMap doc to explain TTL-based cache updates (#3989)

* Update ConfigMap doc to explain TTL-based cache updates

* swap word order

Change "When a ConfigMap being already consumed..." to "When a ConfigMap already being consumed..."

* Update NetworkPolicy docs for v1

* StorageOS Volume plugin

* Update GPU docs

* docs: HPA autoscaling/v2alpha1 status conditions

This commit documents the new status conditions feature for HPA
autoscaling/v2alpha1.  It demonstrates how to get the status conditions
using `kubectl describe`, and how to interpret them.

* Update description about NodeRestriction

kubelet node can alse create mirror pods for their own static pods.

* adding storage as a supported resource to node allocatable

Signed-off-by: Vishnu kannan <vishnuk@google.com>

* Add documentation for podpreset opt-out annotation

This adds the annotation for having the podpreset admission controller
to skip (opt-out) manipulating the pod spec.

Also, the annotation format for what presets have acted on a pod has
been modified to add a prefix of "podpreset-". The new naming makes it such
that there is no chance of collision with the newly introduced opt-out
annotation (or future ones yet to be added).

Opt-out annotation PR:
kubernetes/kubernetes#44965

* Update PDB documentation to explain new field (#3885)

* update-docs-pdb

* Addressed erictune@'s comments

* Fix title and add a TOC to the logging concept page

* Patch #4118 for typos

* Describe setting coredns server in nameserver resolv chain

* Address comments in PR #3997.

Comment is in
https://github.com/kubernetes/kubernetes.github.io/pull/3997/files/f6eb59c67e28efc298c87b1ef49a96bc6adacd1e#diff-7a14981f3dd8eb203f897ce6c11d9828

* Update task for DaemonSet history and rollback (#4098)

* Update task for DaemonSet history and rollback

Also remove mentions of templateGeneration field because it's deprecated

* Address comments

* removed lt and gt as operators (#4152)

* removed lt and gt as operators

* replace lt and gt for node-affinfity

* updated based on bsalamat review

* Initial draft of upgrade guide for kubeadm clusters.

In-place upgrades are supported between 1.6 and 1.7 releases. Rollback
instructions to come in a separate commit.

Fixes https://github.com/kubernetes/kubeadm/issues/278

* Add local volume documentation (#4050)

* Add local volume documentation

* Add PV local volume example

* Patch PR #3999

* Add documentation for Stackdriver event exporter

* Add documentation about controller metrics

* Federation: Add task for setting up placement policies (#4075)

* Add task for setting up placement policies

* Update version of management sidecar in policy engine deployment

* Address @nikhiljindal's comments

- Lower case filenames
- Comments in policy
- Typo fixes
- Removed type LoadBalancer from OPA Service

* Add example that sets cluster selector

Per-@nikhiljindal's suggestion

* Fix wording and templating per @chenopis

* PodDisruptionBudget documentation Improvements (#4140)

* Changes from #3885

Title: Update PDB documentation to explain new field
Author: foxish

* Added Placeholder Disruptions Concept Guide

New file: docs/concepts/workloads/pods/disruptions.md
Intented contents: concept for Pod Disruption Budget,
 cross reference to Eviction and Preemption docs.
Linked from: concepts > workloads > pods

* Added placeholder Configuring PDB Task

New file: docs/tasks/run-application/configure-pdb.md
Intented contents: task for writing a Pod Disruption Budget.
Linked from: tasks > configuring-applications > configure pdb.

* Add refs to the "drain a node" task.

* Refactor PDB docs.

Move the "Requesting an eviction" section from:
docs/tasks/administer-cluster/configure-pod-disruption-budget.md
-- which is going away -- to:
docs/tasks/administer-cluster/safely-drain-node.md

The move is verbatim, except for an introductory sentence.

Also added assignees.

* Refactor of PDB docs

Moved the section:
Specifying a PodDisruptionBudget
from:
docs/tasks/administer-cluster/configure-pod-disruption-budget.md
to:
docs/tasks/run-application/configure-pdb.md
because that former file is going away.
Move is verbatim.

* Explain how Eviction tools should handle failures

* Refactor PDB docs

Move text from:
docs/tasks/administer-cluster/configure-pod-disruption-budget.md
to:
docs/concepts/workloads/pods/disruptions.md

Delete the now empty:
docs/tasks/administer-cluster/configure-pod-disruption-budget.md

Added a redirects_from section to the new doc, containing the path
of the now-deleted doc, plus all the redirects from the deleted
doc.

* Expand PDB Concept guide

Building on a little content from the old task,
greatly expanded the Disruptions concept
guide, including an abstract example.

* Update creating a pdb Task.

* Address review comments.

* Fixed for all cody-clark's review comments

* Address review comments from mml

* Address review comments from maisem

* Fix missing backtick

* Api and Kubectl reference docs updates for 1.7 (#4193)

* Fix includes groups

* Generated kubectl docs for 1.7

* Generated references docs for 1.7 api

* Document node authorization mode

* API Aggregator (#4173)

* API Aggregator

* Additional bullet points

* incorporated feedback for apiserver-aggregation.md

* split setup-api-aggregator.md into two docs and address feedback

* fix link

* addressed docs feedback

* incorporate feedback

* integrate feedback

* Add documentation for DNS stub domains (#4063)

* Add documentation for DNS stub domains

* add additional prereq

* fix image path

* review feedback

* minor grammar and style nits

* documentation for using hostAliases to manage hosts file (#4080)

* documentation for using hostAliases to manage hosts file

* add to table of contents

* review comments

* update the right command to see hosts file

* reformat doc based on suggestion and change some wording

* Fix typo for #4080

* Patch PR #4063

* Fix wording in placement policy task introduction

* Add update to statefulset concepts and basic tutorial (#4174)

* Add update to statefulset concpets and basic tutorial

* Address tech comments.

* Update ESIPP docs for new added API fields

* Custom resource docs

* update audit document with advanced audit features added in 1.7

* kubeadm v1.7 documentation updates (#4018)

* v1.7 updates for kubeadm

* Address review comments

* Address Luke's comments

* Encrypting secrets at rest and cluster security guide

* Edits for Custom DNS Documentation (#4207)

* reorganize custom dns doc

* format fixes

* Update version numbers to 1.7

* Patch PR #4140 (#4215)

* Patch PR #4140

* fix link and typos

* Update PR template

* Update TLS bootstrapping with 1.7 features

This includes documenting the new CSR approver built into the
controller manager and the kubelet alpha features for certificate
rotation.

Since the CSR approver changed over the 1.7 release cycle we need
to call out the migration steps for those using the alpha feature.
This document as a whole could probably use some updates, but the
main focus of this PR is just to get these features minimally
documented before the release.

* Federated ClusterSelector

formatting updates from review

* complete PR #4181 (#4223)

* complete PR #4181

* fix security link

* Extensible admission controller (#4092)

* extensible-admission-controllers

* Update extensible-admission-controllers.md

* more on initializers

* fixes

* Expand external admission webhooks documentation

* wrap at 80 chars

* more

* add reference

* Use correct apigroup for network policy

* Docs changes to PR #4092 (#4224)

* Docs changes to PR #4092

* address feedback

* add doc for --as-group in cli

Add doc for this pr:
https://github.com/kubernetes/kubernetes/pull/43696

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,6 @@
+> NOTE: Please check the “Allow edits from maintainers” box (see image below) to  
+> [allow reviewers to fix problems](https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/) on your patch and speed up the review process.
+>
+> Please delete this note before submitting the pull request.
+
+![Allow edits from maintainers checkbox](https://help.github.com/assets/images/help/pull_requests/allow-maintainers-to-make-edits-sidebar-checkbox.png)

.travis.yml

@@ -1,21 +1,25 @@
 language: go
 go:
-  - 1.7.3
+  - 1.8.1
 
 # Don't want default ./... here:
 install:
 - export PATH=$GOPATH/bin:$PATH
 - mkdir -p $HOME/gopath/src/k8s.io
 - mv $TRAVIS_BUILD_DIR $HOME/gopath/src/k8s.io/kubernetes.github.io
+
+# (1) Fetch dependencies for us to run the tests in test/examples_test.go
 - go get -t -v k8s.io/kubernetes.github.io/test
+
+# Simplified deduplication of dependencies.
+- cp -L -R $GOPATH/src/k8s.io/kubernetes/vendor/ $GOPATH/src/
+- rm -r $GOPATH/src/k8s.io/kubernetes/vendor/
+
+# (2) Fetch md-check along with all its dependencies.
 - git clone --depth=50 --branch=master https://github.com/kubernetes/md-check $HOME/gopath/src/k8s.io/md-check
 - go get -t -v k8s.io/md-check
-- rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/apimachinery
-- rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/apiserver
-- rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/client-go
-- cp -r $GOPATH/src/k8s.io/kubernetes/vendor/* $GOPATH/src/
-- rm -rf $GOPATH/src/k8s.io/kubernetes/vendor/*
-- cp -r $GOPATH/src/k8s.io/kubernetes/staging/src/* $GOPATH/src/
+
+# (3) Fetch mungedocs
 - go get -v k8s.io/kubernetes/cmd/mungedocs
 
 script:

CONTRIBUTING.md

@@ -17,7 +17,7 @@ The [Kubernetes SIG Docs Discussion Group](https://groups.google.com/forum/#!for
 
 ### Style Guides and Templates
 
-Before submitting a pull request to create new content, please review the [Kubernetes.io style guide](http://kubernetes.io/docs/contribute/style-guide/) and follow the [instructions for using page templates](http://kubernetes.io/docs/contribute/page-templates/). 
+Before submitting a pull request to create new content, please review the [Kubernetes.io style guide](http://kubernetes.io/docs/home/contribute/style-guide/) and follow the [instructions for using page templates](http://kubernetes.io/docs/home/contribute/page-templates/). 
 
 
 ## Contributing to Documentation
@@ -33,4 +33,4 @@ Note that code issues should be filed against the main kubernetes repository, wh
 
 ### Submitting Documentation Pull Requests
 
-If you're fixing an issue in the existing documentation, you should submit a PR against the master branch.  Follow [these instructions to create a documentation pull request against the kubernetes.io repository](http://kubernetes.io/docs/contribute/create-pull-request/).
+If you're fixing an issue in the existing documentation, you should submit a PR against the master branch.  Follow [these instructions to create a documentation pull request against the kubernetes.io repository](http://kubernetes.io/docs/home/contribute/create-pull-request/).

README.md

@@ -7,11 +7,11 @@ You can click the **Fork** button in the upper-right area of the screen to creat
 For more information about contributing to the Kubernetes documentation, see:
 
 * [Contributing to the Kubernetes Documentation](http://kubernetes.io/editdocs/)
-* [Creating a Documentation Pull Request](http://kubernetes.io/docs/contribute/create-pull-request/)
-* [Writing a New Topic](http://kubernetes.io/docs/contribute/write-new-topic/)
-* [Staging Your Documentation Changes](http://kubernetes.io/docs/contribute/stage-documentation-changes/)
-* [Using Page Templates](http://kubernetes.io/docs/contribute/page-templates/)
-* [Documentation Style Guide](http://kubernetes.io/docs/contribute/style-guide/)
+* [Creating a Documentation Pull Request](http://kubernetes.io/docs/home/contribute/create-pull-request/)
+* [Writing a New Topic](http://kubernetes.io/docs/home/contribute/write-new-topic/)
+* [Staging Your Documentation Changes](http://kubernetes.io/docs/home/contribute/stage-documentation-changes/)
+* [Using Page Templates](http://kubernetes.io/docs/home/contribute/page-templates/)
+* [Documentation Style Guide](http://kubernetes.io/docs/home/contribute/style-guide/)
 
 ## Thank you!
 

_config.yml

@@ -1,5 +1,6 @@
 name: Kubernetes
 title: Kubernetes
+url: https://kubernetes.io
 description: Production-Grade Container Orchestration
 markdown: kramdown
 kramdown:
@@ -17,7 +18,8 @@ defaults:
     scope:
       path: ""
     values:
-      version: "v1.5.1"
+      fullversion: "v1.7.0"
+      version: "v1.7"
       githubbranch: "master"
       docsbranch: "master"
   -
@@ -41,14 +43,16 @@ logo: /images/favicon.png
 twitter:
   username: kubernetesio
 
+# empty array for tabs
+emptyArray: []
+
 # Tables of contents, stored in the _data folder, that control the sidebar nav
 tocs:
   - docs-home
-  - guides
-  - tutorials
+  - setup
   - tasks
+  - tutorials
   - concepts
   - reference
-  - tools
   - samples
-  - support
+  - search

_data/concepts.yml

@@ -3,27 +3,96 @@ abstract: "Detailed explanations of Kubernetes system concepts and abstractions.
 toc:
 - docs/concepts/index.md
 
-- title: Kubectl Command Line
+- title: Overview
   section:
-  - docs/concepts/tools/kubectl/object-management-overview.md
+  - docs/concepts/overview/what-is-kubernetes.md
+  - docs/concepts/overview/components.md
+  - title: Working with Kubernetes Objects
+    section:
+    - docs/concepts/overview/working-with-objects/kubernetes-objects.md
+    - docs/concepts/overview/working-with-objects/names.md
+    - docs/concepts/overview/working-with-objects/namespaces.md
+    - docs/concepts/overview/working-with-objects/labels.md
+    - docs/concepts/overview/working-with-objects/annotations.md
+  - docs/concepts/overview/kubernetes-api.md
 
-- title: Kubernetes Objects
+- title: Kubernetes Architecture
   section:
-  - docs/concepts/abstractions/overview.md
-  - docs/concepts/abstractions/pod.md
+  - docs/concepts/architecture/nodes.md
+  - docs/concepts/architecture/master-node-communication.md
 
+- title: Extending the Kubernetes API
+  section:
+  - docs/concepts/api-extension/custom-resources.md
+  - docs/concepts/api-extension/apiserver-aggregation.md  
+
+- title: Containers
+  section:
+  - docs/concepts/containers/images.md
+  - docs/concepts/containers/container-environment-variables.md
+  - docs/concepts/containers/container-lifecycle-hooks.md
+
+- title: Workloads
+  section:
+  - title: Pods
+    section:
+    - docs/concepts/workloads/pods/pod-overview.md
+    - docs/concepts/workloads/pods/pod.md
+    - docs/concepts/workloads/pods/pod-lifecycle.md
+    - docs/concepts/workloads/pods/init-containers.md
+    - docs/concepts/workloads/pods/disruptions.md
   - title: Controllers
     section:
-    - docs/concepts/abstractions/controllers/statefulsets.md
-
-- title: Object Metadata
-  section:
-  - docs/concepts/object-metadata/annotations.md
+    - docs/concepts/workloads/controllers/replicaset.md
+    - docs/concepts/workloads/controllers/replicationcontroller.md
+    - docs/concepts/workloads/controllers/deployment.md
+    - docs/concepts/workloads/controllers/statefulset.md
+    - docs/concepts/workloads/controllers/petset.md
+    - docs/concepts/workloads/controllers/daemonset.md
+    - docs/concepts/workloads/controllers/garbage-collection.md
+    - docs/concepts/workloads/controllers/jobs-run-to-completion.md
+    - docs/concepts/workloads/controllers/cron-jobs.md
 
 - title: Configuration
   section:
-  - docs/concepts/configuration/container-command-args.md
+  - docs/concepts/configuration/overview.md
+  - docs/concepts/configuration/manage-compute-resources-container.md
+  - docs/concepts/configuration/assign-pod-node.md
+  - docs/concepts/configuration/secret.md
 
-- title: Policies
+- title: Services, Load Balancing, and Networking
   section:
-  - docs/concepts/policy/container-capabilities.md
+  - docs/concepts/services-networking/service.md
+  - docs/concepts/services-networking/dns-pod-service.md
+  - docs/concepts/services-networking/connect-applications-service.md
+  - docs/concepts/services-networking/ingress.md
+  - docs/concepts/services-networking/network-policies.md
+  - docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
+
+- title: Storage
+  section:
+  - docs/concepts/storage/volumes.md
+  - docs/concepts/storage/persistent-volumes.md
+  - title: Dynamic Provisioning
+    path: http://blog.kubernetes.io/2016/10/dynamic-provisioning-and-storage-in-kubernetes.html
+
+- title: Cluster Administration
+  section:
+  - docs/concepts/cluster-administration/cluster-administration-overview.md
+  - docs/concepts/cluster-administration/manage-deployment.md
+  - docs/concepts/cluster-administration/networking.md
+  - docs/concepts/cluster-administration/network-plugins.md
+  - docs/concepts/cluster-administration/logging.md
+  - docs/concepts/cluster-administration/kubelet-garbage-collection.md
+  - docs/concepts/cluster-administration/federation.md
+  - docs/concepts/cluster-administration/sysctl-cluster.md
+  - docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig.md
+  - docs/concepts/cluster-administration/master-node-communication.md
+  - docs/concepts/cluster-administration/proxies.md
+  - docs/concepts/cluster-administration/controller-metrics.md
+  - title: Policies
+    section:
+    - docs/concepts/policy/resource-quotas.md
+    - docs/concepts/policy/pod-security-policy.md
+
+

_data/docs-home.yml

@@ -1,4 +1,23 @@
-bigheader: "Kubernetes Documentation"
+bigheader: "Documentation Home"
 abstract: "Documentation for using and learning about Kubernetes."
 toc:
-- docs/index.md
+- docs/home/index.md
+
+- docs/home/index.md
+
+- title: Release Notes
+  path: https://git.k8s.io/kubernetes/CHANGELOG.md
+- title: Release Roadmap
+  path: https://github.com/kubernetes/kubernetes/milestones/
+
+- docs/tasks/debug-application-cluster/troubleshooting.md
+
+- title: Contributing to the Kubernetes Docs
+  section:
+  - editdocs.md
+  - docs/home/contribute/create-pull-request.md
+  - docs/home/contribute/write-new-topic.md
+  - docs/home/contribute/stage-documentation-changes.md
+  - docs/home/contribute/page-templates.md
+  - docs/home/contribute/review-issues.md
+  - docs/home/contribute/style-guide.md

_data/globals.yml

@@ -1,10 +1,10 @@
 tocs:
 - docs-home
 - guides
-- tutorials
+- setup
 - tasks
+- tutorials
 - concepts
 - reference
-- tools
 - samples
 - support

_data/guides.yml

@@ -1,233 +0,0 @@
-bigheader: "Guides"
-abstract: "How to get started, and accomplish tasks, using Kubernetes."
-toc:
-- docs/user-guide/index.md
-
-- title: Getting Started
-  section:
-  - docs/whatisk8s.md
-  - docs/getting-started-guides/kubeadm.md
-  - docs/getting-started-guides/kops.md
-  - docs/getting-started-guides/kargo.md
-  - docs/hellonode.md
-  - docs/getting-started-guides/kubectl.md
-  - docs/getting-started-guides/binary_release.md
-  - title: Online Training Course
-    path: https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615
-
-- title: Accessing the Cluster
-  section:
-  - docs/user-guide/prereqs.md
-  - docs/user-guide/accessing-the-cluster.md
-  - docs/user-guide/sharing-clusters.md
-  - docs/user-guide/kubeconfig-file.md
-
-- docs/user-guide/index.md
-
-- docs/user-guide/ui.md
-
-- title: Workload Deployment and Management
-  section:
-  - docs/user-guide/quick-start.md
-  - docs/user-guide/deploying-applications.md
-  - docs/user-guide/managing-deployments.md
-  - docs/user-guide/replication-controller/operations.md
-  - docs/user-guide/resizing-a-replication-controller.md
-  - docs/user-guide/rolling-updates.md
-  - docs/user-guide/update-demo/index.md
-  - docs/user-guide/secrets/walkthrough.md
-  - docs/user-guide/configmap/index.md
-  - docs/user-guide/horizontal-pod-autoscaling/walkthrough.md
-  - docs/user-guide/config-best-practices.md
-  - docs/user-guide/working-with-resources.md
-  - docs/user-guide/garbage-collection.md
-  - title: Using NetworkPolicy
-    section:
-    - docs/getting-started-guides/network-policy/walkthrough.md
-    - docs/getting-started-guides/network-policy/calico.md
-    - docs/getting-started-guides/network-policy/romana.md
-    - docs/getting-started-guides/network-policy/weave.md
-
-- title: Batch Jobs
-  section:
-  - docs/user-guide/jobs.md
-  - docs/user-guide/jobs/expansions/index.md
-  - docs/user-guide/jobs/work-queue-1/index.md
-  - docs/user-guide/jobs/work-queue-2/index.md
-  - docs/user-guide/cron-jobs.md
-
-- title: Service Discovery and Load Balancing
-  section:
-  - docs/user-guide/connecting-applications.md
-  - docs/user-guide/services/operations.md
-  - docs/user-guide/load-balancer.md
-  - docs/user-guide/services-firewalls.md
-  - docs/user-guide/federation/federated-services.md
-
-- title: Containers and Pods
-  section:
-  - docs/user-guide/pods/multi-container.md
-  - docs/user-guide/pods/init-container.md
-  - docs/user-guide/pod-templates.md
-  - docs/user-guide/containers.md
-  - docs/user-guide/environment-guide/index.md
-  - docs/user-guide/compute-resources.md
-  - docs/user-guide/pod-states.md
-  - docs/user-guide/liveness/index.md
-  - docs/user-guide/container-environment.md
-  - docs/user-guide/node-selection/index.md
-  - docs/user-guide/downward-api/index.md
-  - docs/user-guide/downward-api/volume/index.md
-  - docs/user-guide/persistent-volumes/walkthrough.md
-  - docs/user-guide/petset/bootstrapping/index.md
-
-- title: Monitoring, Logging, and Debugging Containers
-  section:
-  - docs/user-guide/monitoring.md
-  - title: Logging
-    section:
-    - docs/user-guide/logging/overview.md
-    - docs/user-guide/logging/stackdriver.md
-    - docs/user-guide/logging/elasticsearch.md
-  - docs/user-guide/getting-into-containers.md
-  - docs/user-guide/connecting-to-applications-proxy.md
-  - docs/user-guide/connecting-to-applications-port-forward.md
-  - title: Using Explorer to Examine the Runtime Environment
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/explorer
-
-- title: Creating a Cluster
-  section:
-  - docs/getting-started-guides/index.md
-  - title: Running Kubernetes on Your Local Machine
-    section:
-    - docs/getting-started-guides/minikube.md
-    - docs/getting-started-guides/alternatives.md
-  - title: Running Kubernetes on Turn-key Cloud Solutions
-    section:
-    - title: Running Kubernetes on Google Container Engine
-      path: https://cloud.google.com/container-engine/docs/before-you-begin/
-    - docs/getting-started-guides/gce.md
-    - docs/getting-started-guides/aws.md
-    - title: Running Kubernetes on Azure Container Service
-      path: https://docs.microsoft.com/en-us/azure/container-service/container-service-kubernetes-walkthrough
-    - docs/getting-started-guides/azure.md
-    - docs/getting-started-guides/clc.md
-    - title: Running Kubernetes on IBM SoftLayer
-      path: https://github.com/patrocinio/kubernetes-softlayer
-    - title: Running Kubernetes on Multiple Clouds with Stackpoint.io
-      path: /docs/getting-started-guides/stackpoint/
-  - title: Running Kubernetes on Custom Solutions
-    section:
-    - docs/getting-started-guides/scratch.md
-    - title: Custom Cloud Solutions
-      section:
-      - docs/getting-started-guides/coreos/index.md
-      - docs/getting-started-guides/ubuntu/index.md
-      - docs/getting-started-guides/rackspace.md
-    - title: On-Premise VMs
-      section:
-      - docs/getting-started-guides/coreos/index.md
-      - docs/getting-started-guides/cloudstack.md
-      - docs/getting-started-guides/vsphere.md
-      - docs/getting-started-guides/photon-controller.md
-      - docs/getting-started-guides/dcos.md
-      - docs/getting-started-guides/libvirt-coreos.md
-      - docs/getting-started-guides/ovirt.md
-      - docs/getting-started-guides/openstack-heat.md
-      - title: rkt
-        section:
-        - docs/getting-started-guides/rkt/index.md
-        - docs/getting-started-guides/rkt/notes.md
-      - docs/getting-started-guides/mesos/index.md
-      - docs/getting-started-guides/mesos-docker.md
-    - title: Bare Metal
-      section:
-      - docs/getting-started-guides/coreos/bare_metal_offline.md
-      - docs/getting-started-guides/fedora/fedora_ansible_config.md
-      - docs/getting-started-guides/fedora/fedora_manual_config.md
-      - docs/getting-started-guides/fedora/flannel_multi_node_cluster.md
-      - docs/getting-started-guides/centos/centos_manual_config.md
-      - docs/getting-started-guides/coreos/index.md
-      - docs/getting-started-guides/ubuntu/index.md
-      - title: Ubuntu
-        section:
-        - docs/getting-started-guides/ubuntu/index.md
-        - docs/getting-started-guides/ubuntu/validation.md
-        - docs/getting-started-guides/ubuntu/backups.md
-        - docs/getting-started-guides/ubuntu/upgrades.md
-        - docs/getting-started-guides/ubuntu/scaling.md
-        - docs/getting-started-guides/ubuntu/installation.md
-        - docs/getting-started-guides/ubuntu/monitoring.md
-        - docs/getting-started-guides/ubuntu/networking.md
-        - docs/getting-started-guides/ubuntu/security.md
-        - docs/getting-started-guides/ubuntu/storage.md
-        - docs/getting-started-guides/ubuntu/troubleshooting.md
-        - docs/getting-started-guides/ubuntu/decommissioning.md
-        - docs/getting-started-guides/ubuntu/calico.md
-        - docs/getting-started-guides/ubuntu/glossary.md
-        - docs/getting-started-guides/ubuntu/local.md
-        - docs/getting-started-guides/ubuntu/logging.md
-        - docs/getting-started-guides/ubuntu/manual.md
-      - docs/getting-started-guides/windows/index.md
-    - docs/admin/node-conformance.md
-  - docs/getting-started-guides/docker-multinode.md
-  - docs/admin/cluster-large.md
-  - docs/admin/multiple-zones.md
-  - docs/admin/high-availability/index.md
-
-- title: Administering Clusters
-  section:
-  - docs/admin/index.md
-  - docs/admin/cluster-management.md
-  - docs/admin/kubeadm.md
-  - docs/admin/addons.md
-  - docs/admin/audit.md
-  - docs/admin/ha-master-gce.md
-  - docs/admin/namespaces/index.md
-  - docs/admin/namespaces/walkthrough.md
-  - docs/admin/limitrange/index.md
-  - docs/admin/disruptions.md
-  - docs/admin/resourcequota/index.md
-  - docs/admin/resourcequota/walkthrough.md
-  - docs/admin/resourcequota/limitstorageconsumption.md
-  - docs/admin/rescheduler.md
-  - docs/admin/sysctls.md
-  - docs/admin/cluster-components.md
-  - docs/admin/etcd.md
-  - docs/admin/multi-cluster.md
-  - title: Changing Cluster Size
-    path: https://github.com/kubernetes/kubernetes/wiki/User-FAQ#how-do-i-change-the-size-of-my-cluster/
-  - docs/admin/multiple-schedulers.md
-  - docs/admin/networking.md
-  - docs/admin/dns.md
-  - title: Setting Up and Configuring DNS
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/cluster-dns
-  - docs/admin/master-node-communication.md
-  - docs/admin/network-plugins.md
-  - docs/admin/static-pods.md
-  - docs/admin/garbage-collection.md
-  - docs/admin/out-of-resource.md
-  - docs/admin/salt.md
-  - docs/admin/node-problem.md
-  - docs/admin/apparmor/index.md
-
-- title: Administering Federation
-  section:
-  - docs/admin/federation/kubefed.md
-  - title: Federated Kubernetes Objects
-    section:
-    - docs/user-guide/federation/index.md
-    - docs/user-guide/federation/configmap.md
-    - docs/user-guide/federation/daemonsets.md
-    - docs/user-guide/federation/deployment.md
-    - docs/user-guide/federation/events.md
-    - docs/user-guide/federation/federated-ingress.md
-    - docs/user-guide/federation/namespaces.md
-    - docs/user-guide/federation/replicasets.md
-    - docs/user-guide/federation/secrets.md
-    - docs/federation/api-reference/index.md
-  - title: Federation Components
-    section:
-    - docs/admin/federation-apiserver.md
-    - title : federation-controller-mananger
-      path: /docs/admin/federation-controller-manager

_data/overrides.yml

@@ -1,6 +1,4 @@
 overrides:
-- path: docs/api-reference
-- path: docs/user-guide/kubectl
 - path: docs/admin/federation-apiserver.md
 - path: docs/admin/federation-controller-manager.md
 - path: docs/admin/kube-apiserver.md
@@ -8,10 +6,5 @@ overrides:
 - path: docs/admin/kube-proxy.md
 - path: docs/admin/kube-scheduler.md
 - path: docs/admin/kubelet.md
-- changedpath: docs/api-reference/extensions/v1beta1/definitions.html _includes/v1.5/extensions-v1beta1-definitions.html
-- changedpath: docs/api-reference/extensions/v1beta1/operations.html _includes/v1.5/extensions-v1beta1-operations.html
-- changedpath: docs/api-reference/v1/definitions.html _includes/v1.5/v1-definitions.html
-- changedpath: docs/api-reference/v1/operations.html _includes/v1.5/v1-operations.html
 - copypath: k8s/federation/docs/api-reference/ docs/federation/
 - copypath: k8s/cluster/saltbase/salt/fluentd-gcp/fluentd-gcp.yaml docs/getting-started-guides/fluentd-gcp.yaml
-

_data/reference.yml

@@ -1,200 +1,97 @@
 bigheader: "Reference Documentation"
 abstract: "Design docs, concept definitions, and references for APIs and CLIs."
 toc:
-- docs/reference.md
+- docs/reference/index.md
 
-- title: "Kubernetes Resource Types (New Docs Style)"
+- title: Using the API
   section:
-  - title: Version 1.5
-    path: /docs/resources-reference/v1.5/
-
-- title: "Kubernetes API (New Docs Style)"
-  section:
-  - title: Version 1.5
-    path: /docs/api-reference/v1.5/
-
-- title: "Kubectl Commands (New Docs Style)"
-  section:
-  - title: Version 1.5
-    path: /docs/user-guide/kubectl/v1.5/
-
-- title: Kubernetes API
-  section:
-  - docs/api.md
+  - docs/reference/api-overview.md
   - title: Accessing the API
     section:
     - docs/admin/accessing-the-api.md
     - docs/admin/authentication.md
-    - docs/admin/authorization.md
+    - docs/admin/bootstrap-tokens.md
     - docs/admin/admission-controllers.md
+    - docs/admin/extensible-admission-controllers.md
     - docs/admin/service-accounts-admin.md
-  - docs/api-reference/v1/operations.html
-  - docs/api-reference/v1/definitions.html
-  - docs/api-reference/labels-annotations-taints.md
-  - kubernetes/third_party/swagger-ui/index.md
+  - title: Authorization
+    section:
+    - docs/admin/authorization/index.md
+    - docs/admin/authorization/abac.md
+    - docs/admin/authorization/rbac.md
+    - docs/admin/authorization/node.md
+    - docs/admin/authorization/webhook.md
+  - docs/reference/deprecation-policy.md
 
-- title: Autoscaling API
+- title: API Reference
   section:
-  - docs/api-reference/autoscaling/v1/operations.html
-  - docs/api-reference/autoscaling/v1/definitions.html
+  - title: v1.7
+    path: /docs/api-reference/v1.7/
+  - title: v1.6
+    path: /docs/api-reference/v1.6/
+  - title: v1.5
+    path: /docs/api-reference/v1.5/
+  - docs/reference/labels-annotations-taints.md
+  - title: OpenAPI and Swagger
+    section:
+    - title: OpenAPI Spec
+      path: https://git.k8s.io/kubernetes/api/openapi-spec/
+    - title: Swagger Spec
+      path: https://git.k8s.io/kubernetes/api/swagger-spec/
 
-- title: Batch API
+- title: Federation API
   section:
-  - docs/api-reference/batch/v1/operations.html
-  - docs/api-reference/batch/v1/definitions.html
-
-- title: Apps API
-  section:
-  - title: Apps API Operations
-    path: /docs/api-reference/apps/v1beta1/operations/
-  - title: Apps API Definitions
-    path: /docs/api-reference/apps/v1beta1/definitions/
-
-- title: Extensions API
-  section:
-  - docs/api-reference/extensions/v1beta1/operations.html
-  - docs/api-reference/extensions/v1beta1/definitions.html
+    - docs/reference/federation/v1/operations.html
+    - docs/reference/federation/v1/definitions.html
+    - docs/reference/federation/v1beta1/operations.html
+    - docs/reference/federation/v1beta1/definitions.html
+    - docs/reference/federation/extensions/v1beta1/operations.html
+    - docs/reference/federation/extensions/v1beta1/definitions.html
 
 - title: kubectl CLI
   section:
   - docs/user-guide/kubectl-overview.md
+  - title: v1.7 Commands
+    path: /docs/user-guide/kubectl/v1.7/
+  - title: v1.6 Commands
+    path: /docs/user-guide/kubectl/v1.6/
+  - title: v1.5 Commands
+    path: /docs/user-guide/kubectl/v1.5/
   - docs/user-guide/docker-cli-to-kubectl.md
   - docs/user-guide/kubectl-conventions.md
   - docs/user-guide/jsonpath.md
   - docs/user-guide/kubectl-cheatsheet.md
-  - title: kubectl Commands
-    section:
-    - docs/user-guide/kubectl/index.md
-    - docs/user-guide/kubectl/kubectl_annotate.md
-    - docs/user-guide/kubectl/kubectl_api-versions.md
-    - docs/user-guide/kubectl/kubectl_apply.md
-    - docs/user-guide/kubectl/kubectl_attach.md
-    - docs/user-guide/kubectl/kubectl_autoscale.md
-    - docs/user-guide/kubectl/kubectl_certificate.md
-    - docs/user-guide/kubectl/kubectl_certificate_approve.md
-    - docs/user-guide/kubectl/kubectl_certificate_deny.md
-    - docs/user-guide/kubectl/kubectl_cluster-info.md
-    - docs/user-guide/kubectl/kubectl_cluster-info_dump.md
-    - docs/user-guide/kubectl/kubectl_completion.md
-    - docs/user-guide/kubectl/kubectl_config.md
-    - docs/user-guide/kubectl/kubectl_config_current-context.md
-    - docs/user-guide/kubectl/kubectl_config_delete-cluster.md
-    - docs/user-guide/kubectl/kubectl_config_delete-context.md
-    - docs/user-guide/kubectl/kubectl_config_get-clusters.md
-    - docs/user-guide/kubectl/kubectl_config_get-contexts.md
-    - docs/user-guide/kubectl/kubectl_config_set-cluster.md
-    - docs/user-guide/kubectl/kubectl_config_set-context.md
-    - docs/user-guide/kubectl/kubectl_config_set-credentials.md
-    - docs/user-guide/kubectl/kubectl_config_set.md
-    - docs/user-guide/kubectl/kubectl_config_unset.md
-    - docs/user-guide/kubectl/kubectl_config_use-context.md
-    - docs/user-guide/kubectl/kubectl_config_view.md
-    - docs/user-guide/kubectl/kubectl_convert.md
-    - docs/user-guide/kubectl/kubectl_cordon.md
-    - docs/user-guide/kubectl/kubectl_cp.md
-    - docs/user-guide/kubectl/kubectl_create.md
-    - docs/user-guide/kubectl/kubectl_create_configmap.md
-    - docs/user-guide/kubectl/kubectl_create_deployment.md
-    - docs/user-guide/kubectl/kubectl_create_namespace.md
-    - docs/user-guide/kubectl/kubectl_create_quota.md
-    - docs/user-guide/kubectl/kubectl_create_secret_docker-registry.md
-    - docs/user-guide/kubectl/kubectl_create_secret.md
-    - docs/user-guide/kubectl/kubectl_create_secret_generic.md
-    - docs/user-guide/kubectl/kubectl_create_secret_tls.md
-    - docs/user-guide/kubectl/kubectl_create_serviceaccount.md
-    - docs/user-guide/kubectl/kubectl_create_service_clusterip.md
-    - docs/user-guide/kubectl/kubectl_create_service_loadbalancer.md
-    - docs/user-guide/kubectl/kubectl_create_service_nodeport.md
-    - docs/user-guide/kubectl/kubectl_delete.md
-    - docs/user-guide/kubectl/kubectl_describe.md
-    - docs/user-guide/kubectl/kubectl_drain.md
-    - docs/user-guide/kubectl/kubectl_edit.md
-    - docs/user-guide/kubectl/kubectl_exec.md
-    - docs/user-guide/kubectl/kubectl_explain.md
-    - docs/user-guide/kubectl/kubectl_expose.md
-    - docs/user-guide/kubectl/kubectl_get.md
-    - docs/user-guide/kubectl/kubectl_label.md
-    - docs/user-guide/kubectl/kubectl_logs.md
-    - docs/user-guide/kubectl/kubectl_options.md
-    - docs/user-guide/kubectl/kubectl_patch.md
-    - docs/user-guide/kubectl/kubectl_port-forward.md
-    - docs/user-guide/kubectl/kubectl_proxy.md
-    - docs/user-guide/kubectl/kubectl_replace.md
-    - docs/user-guide/kubectl/kubectl_rolling-update.md
-    - docs/user-guide/kubectl/kubectl_rollout.md
-    - docs/user-guide/kubectl/kubectl_rollout_history.md
-    - docs/user-guide/kubectl/kubectl_rollout_pause.md
-    - docs/user-guide/kubectl/kubectl_rollout_resume.md
-    - docs/user-guide/kubectl/kubectl_rollout_status.md
-    - docs/user-guide/kubectl/kubectl_rollout_undo.md
-    - docs/user-guide/kubectl/kubectl_run.md
-    - docs/user-guide/kubectl/kubectl_scale.md
-    - docs/user-guide/kubectl/kubectl_set.md
-    - docs/user-guide/kubectl/kubectl_set_image.md
-    - docs/user-guide/kubectl/kubectl_set_resources.md
-    - docs/user-guide/kubectl/kubectl_taint.md
-    - docs/user-guide/kubectl/kubectl_top.md
-    - docs/user-guide/kubectl/kubectl_top_node.md
-    - docs/user-guide/kubectl/kubectl_top_pod.md
-    - docs/user-guide/kubectl/kubectl_uncordon.md
-    - docs/user-guide/kubectl/kubectl_version.md
-    - title: Superseded and Deprecated Commands
-      section:
-      - /docs/user-guide/kubectl/kubectl_namespace/
-      - docs/user-guide/kubectl/kubectl_stop.md
 
-- title: Kubernetes Components
+- docs/admin/kubeadm.md
+
+- title: Config Reference
   section:
+  - docs/admin/kubelet.md
   - docs/admin/kube-apiserver.md
   - docs/admin/kube-controller-manager.md
   - docs/admin/kube-proxy.md
   - docs/admin/kube-scheduler.md
-  - title: kubelet
-    section:
-    - docs/admin/kubelet.md
-    - docs/admin/master-node-communication.md
-    - docs/admin/kubelet-tls-bootstrapping.md
-    - docs/admin/kubelet-authentication-authorization.md
-
-- title: Glossary
-  section:
-  - docs/user-guide/annotations.md
-  - docs/admin/daemons.md
-  - docs/user-guide/deployments.md
-  - docs/user-guide/horizontal-pod-autoscaling/index.md
-  - docs/user-guide/images.md
-  - docs/user-guide/ingress.md
-  - docs/user-guide/jobs.md
-  - docs/user-guide/labels.md
-  - docs/user-guide/identifiers.md
-  - docs/user-guide/namespaces.md
-  - docs/user-guide/networkpolicies.md
-  - docs/admin/node.md
-  - docs/user-guide/persistent-volumes/index.md
-  - docs/user-guide/petset.md
-  - docs/user-guide/pods/index.md
-  - docs/user-guide/pod-security-policy/index.md
-  - docs/user-guide/replicasets.md
-  - docs/user-guide/replication-controller/index.md
-  - docs/admin/resourcequota/index.md
-  - docs/user-guide/cron-jobs.md
-  - docs/user-guide/secrets/index.md
-  - docs/user-guide/security-context.md
-  - docs/user-guide/services/index.md
-  - docs/user-guide/service-accounts.md
-  - docs/user-guide/thirdpartyresources.md
-  - docs/user-guide/volumes.md
+  - docs/admin/federation-apiserver.md
+  - docs/admin/federation-controller-manager.md
 
 - title: Kubernetes Design Docs
   section:
   - title: Kubernetes Architecture
-    path: https://github.com/kubernetes/kubernetes/blob/release-1.5/docs/design/architecture.md
+    path: https://git.k8s.io/community/contributors/design-proposals/architecture.md
   - title: Kubernetes Design Overview
-    path: https://github.com/kubernetes/kubernetes/blob/release-1.5/docs/design/
+    path: https://github.com/kubernetes/kubernetes/tree/release-1.6/docs/design
   - title: Kubernetes Identity and Access Management
-    path: https://github.com/kubernetes/kubernetes/blob/release-1.5/docs/design/access.md
+    path: https://git.k8s.io/community/contributors/design-proposals/access.md
   - docs/admin/ovs-networking.md
   - title: Security Contexts
-    path: https://github.com/kubernetes/kubernetes/blob/release-1.5/docs/design/security_context.md
+    path: https://git.k8s.io/community/contributors/design-proposals/security_context.md
   - title: Security in Kubernetes
-    path: https://github.com/kubernetes/kubernetes/blob/release-1.5/docs/design/security.md
+    path: https://git.k8s.io/community/contributors/design-proposals/security.md
+
+- title: Kubernetes Issues and Security
+  section:
+  - title: Kubernetes Issue Tracker on GitHub
+    path: https://github.com/kubernetes/kubernetes/issues/
+  - docs/reference/security.md
+
+

_data/samples.yml

@@ -1,75 +0,0 @@
-bigheader: "Samples"
-abstract: "A collection of example applications that show how to use Kubernetes."
-toc:
-- docs/samples.md
-
-- title: Storage / Database / KV
-  section:
-  - title: Apache Cassandra Database
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/storage/cassandra
-  - title: Ceph
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/volumes/rbd/
-  - title: CephFS
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/volumes/cephfs/
-  - title: CockroachDB
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.4/examples/cockroachdb/
-  - title: GlusterFS
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/volumes/glusterfs/
-  - title: Hazelcast
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/storage/hazelcast
-  - title: iSCSI
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/volumes/iscsi/
-  - title: MySQL Galera
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/storage/mysql-galera
-  - title: NFS
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/volumes/nfs/
-  - title: Redis
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/storage/redis/
-  - title: RethinkDB
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/storage/rethinkdb/
-  - title: Vitess
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/storage/vitess/
-
-- title: Big Data
-  section:
-  - title: Apache Spark
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/spark
-  - title: Apache Storm
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/storm
-
-- title: Messaging / Queueing
-  section:
-  - title: Hazelcast
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/storage/hazelcast
-
-- title: Miscellaneous
-  section:
-  - title: Meteor Applications
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/meteor/
-  - title: OpenShift Origin
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/openshift-origin/
-  - title: Selenium
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/selenium/
-
-- title: Monitoring and Logging
-  section:
-  - title: Elasticsearch
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/elasticsearch/
-  - title: NewRelic
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/newrelic
-
-- title: Multi-tier Applications
-  section:
-  - title: Guestbook - Go Server
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/guestbook-go/
-  - title: GuestBook - PHP Server
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/guestbook/
-  - docs/getting-started-guides/meanstack.md
-  - title: MySQL + Wordpress
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/mysql-wordpress-pd/
-  - title: MySQL + Phabricator Server
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/phabricator/
-  - title: Nodejs + Mongo
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/nodesjs-mongodb
-  - title: Petstore
-    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/k8petstore/

_data/search.yml

@@ -0,0 +1,4 @@
+bigheader: ""
+abstract: ""
+toc:
+- docs/search.md

_data/setup.yml

@@ -0,0 +1,107 @@
+bigheader: "Setup"
+abstract: "Instructions for setting up a Kubernetes cluster."
+toc:
+- docs/setup/index.md
+- docs/setup/pick-right-solution.md
+
+- title: Independent Solutions
+  section:
+  - docs/getting-started-guides/minikube.md
+
+  - title: Bootstrapping Clusters with kubeadm
+    section:
+    - docs/setup/independent/install-kubeadm.md
+    - docs/setup/independent/create-cluster-kubeadm.md
+
+  - docs/getting-started-guides/scratch.md
+  - docs/getting-started-guides/alternatives.md
+
+- title: Hosted Solutions
+  section:
+  - title: Running Kubernetes on Google Container Engine
+    path: https://cloud.google.com/container-engine/docs/before-you-begin/
+  - title: Running Kubernetes on Azure Container Service
+    path: https://docs.microsoft.com/en-us/azure/container-service/container-service-kubernetes-walkthrough
+  - title: Running Kubernetes on IBM Bluemix Container Service
+    path: https://console.ng.bluemix.net/docs/containers/container_index.html
+
+- title: Turn-key Cloud Solutions
+  section:
+  - docs/getting-started-guides/gce.md
+  - docs/getting-started-guides/aws.md
+  - docs/getting-started-guides/azure.md
+  - docs/getting-started-guides/clc.md
+  - title: Running Kubernetes on IBM Bluemix
+    path: https://github.com/patrocinio/kubernetes-softlayer
+  - docs/getting-started-guides/stackpoint.md
+
+- title: Custom Solutions
+
+  section:
+  - title: Custom Cloud Solutions
+    section:
+    - docs/getting-started-guides/coreos/index.md
+    - docs/getting-started-guides/ubuntu/index.md
+    - docs/getting-started-guides/kops.md
+    - docs/getting-started-guides/kubespray.md
+    - docs/getting-started-guides/running-cloud-controller.md
+
+  - title: On-Premise VMs
+    section:
+    - docs/getting-started-guides/coreos/index.md
+    - docs/getting-started-guides/cloudstack.md
+    - docs/getting-started-guides/vsphere.md
+    - docs/getting-started-guides/photon-controller.md
+    - docs/getting-started-guides/dcos.md
+    - docs/getting-started-guides/libvirt-coreos.md
+    - docs/getting-started-guides/ovirt.md
+    - docs/getting-started-guides/openstack-heat.md
+
+    - title: rkt
+      section:
+      - docs/getting-started-guides/rkt/index.md
+      - docs/getting-started-guides/rkt/notes.md
+
+    - docs/getting-started-guides/mesos/index.md
+    - docs/getting-started-guides/mesos-docker.md
+
+    - title: Bare Metal
+      section:
+      - docs/getting-started-guides/coreos/bare_metal_offline.md
+      - docs/getting-started-guides/fedora/fedora_ansible_config.md
+      - docs/getting-started-guides/fedora/fedora_manual_config.md
+      - docs/getting-started-guides/fedora/flannel_multi_node_cluster.md
+      - docs/getting-started-guides/centos/centos_manual_config.md
+      - docs/getting-started-guides/coreos/index.md
+      - docs/getting-started-guides/ubuntu/index.md
+
+      - title: Ubuntu
+        section:
+        - docs/getting-started-guides/ubuntu/index.md
+        - docs/getting-started-guides/ubuntu/validation.md
+        - docs/getting-started-guides/ubuntu/backups.md
+        - docs/getting-started-guides/ubuntu/upgrades.md
+        - docs/getting-started-guides/ubuntu/scaling.md
+        - docs/getting-started-guides/ubuntu/installation.md
+        - docs/getting-started-guides/ubuntu/monitoring.md
+        - docs/getting-started-guides/ubuntu/networking.md
+        - docs/getting-started-guides/ubuntu/security.md
+        - docs/getting-started-guides/ubuntu/storage.md
+        - docs/getting-started-guides/ubuntu/troubleshooting.md
+        - docs/getting-started-guides/ubuntu/decommissioning.md
+        - docs/getting-started-guides/ubuntu/operational-considerations.md
+        - docs/getting-started-guides/ubuntu/glossary.md
+        - docs/getting-started-guides/ubuntu/local.md
+        - docs/getting-started-guides/ubuntu/logging.md
+        - docs/getting-started-guides/ubuntu/manual.md
+
+    - docs/getting-started-guides/windows/index.md
+
+  - docs/admin/node-conformance.md
+
+- docs/concepts/cluster-administration/addons.md
+- docs/admin/salt.md
+- docs/admin/cluster-large.md
+- docs/admin/multiple-zones.md
+- docs/admin/high-availability/index.md
+- docs/getting-started-guides/binary_release.md

_data/support.yml

@@ -1,44 +0,0 @@
-bigheader: "Support"
-abstract: "Troubleshooting resources, frequently asked questions, and community support channels."
-toc:
-- docs/troubleshooting.md
-
-- title: Troubleshooting
-  section:
-  - docs/user-guide/debugging-pods-and-replication-controllers.md
-  - docs/user-guide/introspection-and-debugging.md
-  - docs/user-guide/application-troubleshooting.md
-  - docs/admin/cluster-troubleshooting.md
-  - docs/user-guide/debugging-services.md
-
-- title: Frequently Asked Questions
-  section:
-  - title: User FAQ
-    path: https://github.com/kubernetes/kubernetes/wiki/User-FAQ/
-  - title: Debugging FAQ
-    path: https://github.com/kubernetes/kubernetes/wiki/Debugging-FAQ/
-  - title: Services FAQ
-    path: https://github.com/kubernetes/kubernetes/wiki/Services-FAQ/
-
-- title: Contributing to the Kubernetes Docs
-  section:
-  - editdocs.md
-  - docs/contribute/create-pull-request.md
-  - docs/contribute/write-new-topic.md
-  - docs/contribute/stage-documentation-changes.md
-  - docs/contribute/page-templates.md
-  - docs/contribute/review-issues.md
-  - docs/contribute/style-guide.md
-
-- title: Other Resources
-  section:
-  - title: Kubernetes Issue Tracker on GitHub
-    path: https://github.com/kubernetes/kubernetes/issues/
-  - docs/reporting-security-issues.md
-  - title: Release Notes
-    path: https://github.com/kubernetes/kubernetes/releases/
-  - title: Release Roadmap
-    path: https://github.com/kubernetes/kubernetes/milestones/
-
-- title: Deprecation Policy
-  path: /docs/deprecation-policy.md

_data/tasks.yml

@@ -3,49 +3,169 @@ abstract: "Step-by-step instructions for performing operations with Kubernetes."
 toc:
 - docs/tasks/index.md
 
-- title: Configuring Pods and Containers
+- title: Install Tools
+  section:
+  - docs/tasks/tools/install-kubectl.md
+  - docs/tasks/tools/install-minikube.md
+  - docs/setup/independent/install-kubeadm.md
+
+- title: Configure Pods and Containers
   section:
-  - docs/tasks/configure-pod-container/define-environment-variable-container.md
-  - docs/tasks/configure-pod-container/define-command-argument-container.md
   - docs/tasks/configure-pod-container/assign-cpu-ram-container.md
   - docs/tasks/configure-pod-container/configure-volume-storage.md
   - docs/tasks/configure-pod-container/configure-persistent-volume-storage.md
-  - docs/tasks/configure-pod-container/distribute-credentials-secure.md
+  - docs/tasks/configure-pod-container/configure-projected-volume-storage.md
+  - docs/tasks/configure-pod-container/projected-volume.md
+  - docs/tasks/configure-pod-container/security-context.md
+  - docs/tasks/configure-pod-container/environment-variable-expose-pod-information.md
+  - docs/tasks/configure-pod-container/configure-service-account.md
   - docs/tasks/configure-pod-container/pull-image-private-registry.md
   - docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md
-  - docs/tasks/configure-pod-container/communicate-containers-same-pod.md
+  - docs/tasks/configure-pod-container/assign-pods-nodes.md
   - docs/tasks/configure-pod-container/configure-pod-initialization.md
   - docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
+  - docs/tasks/configure-pod-container/configmap.md
+  - docs/tasks/configure-pod-container/configure-pod-configmap.md
+  - docs/tools/kompose/user-guide.md
 
-- title: Accessing Applications in a Cluster
+- title: Inject Data Into Applications
   section:
+  - docs/tasks/inject-data-application/define-command-argument-container.md
+  - docs/tasks/inject-data-application/define-environment-variable-container.md
+  - docs/tasks/inject-data-application/environment-variable-expose-pod-information.md
+  - docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
+  - docs/tasks/inject-data-application/distribute-credentials-secure.md
+  - docs/tasks/inject-data-application/podpreset.md
+
+- title: Run Applications
+  section:
+  - docs/tasks/run-application/run-stateless-application-deployment.md
+  - docs/tasks/run-application/run-single-instance-stateful-application.md
+  - docs/tasks/run-application/run-replicated-stateful-application.md
+  - docs/tasks/run-application/upgrade-pet-set-to-stateful-set.md
+  - docs/tasks/run-application/scale-stateful-set.md
+  - docs/tasks/run-application/delete-stateful-set.md
+  - docs/tasks/run-application/force-delete-stateful-set-pod.md
+  - docs/tasks/run-application/rolling-update-replication-controller.md
+  - docs/tasks/run-application/horizontal-pod-autoscale.md
+  - docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+  - docs/tasks/run-application/configure-pdb.md
+
+- title: Run Jobs
+  section:
+  - docs/tasks/job/parallel-processing-expansion.md
+  - docs/tasks/job/coarse-parallel-processing-work-queue/index.md
+  - docs/tasks/job/fine-parallel-processing-work-queue/index.md
+
+- title: Access Applications in a Cluster
+  section:
+  - docs/tasks/access-application-cluster/web-ui-dashboard.md
+  - docs/tasks/access-application-cluster/access-cluster.md
+  - docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig.md
   - docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
   - docs/tasks/access-application-cluster/load-balance-access-application-cluster.md
+  - docs/tasks/access-application-cluster/service-access-application-cluster.md
+  - docs/tasks/access-application-cluster/connecting-frontend-backend.md
+  - docs/tasks/access-application-cluster/create-external-load-balancer.md
+  - docs/tasks/access-application-cluster/configure-cloud-provider-firewall.md
+  - docs/tasks/access-application-cluster/list-all-running-container-images.md
+  - docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
+  - title: Configuring DNS for a Cluster
+    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/cluster-dns
 
-- title: Debugging Applications in a Cluster
+- title: Monitor, Log, and Debug
   section:
+  - docs/tasks/debug-application-cluster/resource-usage-monitoring.md
+  - docs/tasks/debug-application-cluster/get-shell-running-container.md
+  - docs/tasks/debug-application-cluster/monitor-node-health.md
+  - docs/tasks/debug-application-cluster/logging-stackdriver.md
+  - docs/tasks/debug-application-cluster/events-stackdriver.md
+  - docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
   - docs/tasks/debug-application-cluster/determine-reason-pod-failure.md
+  - docs/tasks/debug-application-cluster/debug-init-containers.md
+  - docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
+  - docs/tasks/debug-application-cluster/debug-service.md
+  - docs/tasks/debug-application-cluster/debug-cluster.md
+  - docs/tasks/debug-application-cluster/debug-application.md
+  - docs/tasks/debug-application-cluster/debug-stateful-set.md
+  - docs/tasks/debug-application-cluster/debug-application-introspection.md
+  - docs/tasks/debug-application-cluster/audit.md
+  - title: Use Explorer to Examine the Runtime Environment
+    path: https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/explorer
 
-- title: Accessing the Kubernetes API
+- title: Access and Extend the Kubernetes API
   section:
   - docs/tasks/access-kubernetes-api/http-proxy-access-api.md
+  - docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions.md
+  - docs/tasks/access-kubernetes-api/extend-api-third-party-resource.md
+  - docs/tasks/access-kubernetes-api/migrate-third-party-resource.md
+  - docs/tasks/access-kubernetes-api/configure-aggregation-layer.md
+  - docs/tasks/access-kubernetes-api/setup-extension-api-server.md
 
-- title: Administering a Cluster
+- title: TLS
   section:
-  - docs/tasks/administer-cluster/assign-pods-nodes.md
+  - docs/tasks/tls/managing-tls-in-a-cluster.md
+
+- title: Administer a Cluster
+  section:
+  - docs/tasks/administer-cluster/access-cluster-api.md
+  - docs/tasks/administer-cluster/access-cluster-services.md
+  - docs/tasks/administer-cluster/securing-a-cluster.md
+  - docs/tasks/administer-cluster/encrypt-data.md
+  - docs/tasks/administer-cluster/configure-upgrade-etcd.md
+  - docs/tasks/administer-cluster/apply-resource-quota-limit.md
+  - docs/tasks/administer-cluster/out-of-resource.md
+  - docs/tasks/administer-cluster/cpu-memory-limit.md
+  - docs/tasks/administer-cluster/reserve-compute-resources.md
+  - docs/tasks/administer-cluster/static-pod.md
+  - docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md
+  - docs/tasks/administer-cluster/cluster-management.md
+  - docs/tasks/administer-cluster/upgrade-1-6.md
+  - docs/tasks/administer-cluster/kubeadm-upgrade-1-7.md
+  - docs/tasks/administer-cluster/namespaces.md
+  - docs/tasks/administer-cluster/namespaces-walkthrough.md
   - docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
   - docs/tasks/administer-cluster/safely-drain-node.md
+  - docs/tasks/administer-cluster/declare-network-policy.md
+  - docs/tasks/administer-cluster/calico-network-policy.md
+  - docs/tasks/administer-cluster/romana-network-policy.md
+  - docs/tasks/administer-cluster/weave-network-policy.md
   - docs/tasks/administer-cluster/change-pv-reclaim-policy.md
+  - docs/tasks/administer-cluster/configure-pod-disruption-budget.md
+  - docs/tasks/administer-cluster/limit-storage-consumption.md
+  - docs/tasks/administer-cluster/change-default-storage-class.md
+  - docs/tasks/administer-cluster/share-configuration.md
+  - docs/tasks/administer-cluster/running-cloud-controller.md
+  - docs/tasks/administer-cluster/highly-available-master.md
+  - docs/tasks/administer-cluster/configure-multiple-schedulers.md
+  - docs/tasks/administer-cluster/ip-masq-agent.md
+  - docs/tasks/administer-cluster/dns-custom-nameservers.md
+  - title: Change Cluster Size
+    path: https://github.com/kubernetes/kubernetes/wiki/User-FAQ#how-do-i-change-the-size-of-my-cluster/
 
-- title: Managing Stateful Applications
+- title: Federation - Run an App on Multiple Clusters
   section:
-  - docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set.md
-  - docs/tasks/manage-stateful-set/scale-stateful-set.md
-  - docs/tasks/manage-stateful-set/deleting-a-statefulset.md
-  - docs/tasks/manage-stateful-set/debugging-a-statefulset.md
-  - docs/tasks/manage-stateful-set/delete-pods.md
+  - docs/tasks/federation/federation-service-discovery.md
+  - docs/tasks/federation/set-up-cluster-federation-kubefed.md
+  - docs/tasks/federation/set-up-coredns-provider-federation.md
+  - docs/tasks/federation/set-up-placement-policies-federation.md
+  - docs/tasks/administer-federation/cluster.md
+  - docs/tasks/administer-federation/configmap.md
+  - docs/tasks/administer-federation/daemonset.md
+  - docs/tasks/administer-federation/deployment.md
+  - docs/tasks/administer-federation/events.md
+  - docs/tasks/administer-federation/ingress.md
+  - docs/tasks/administer-federation/namespaces.md
+  - docs/tasks/administer-federation/replicaset.md
+  - docs/tasks/administer-federation/secret.md
 
-- title: Troubleshooting
+- title: Manage Cluster Daemons
   section:
-  - docs/tasks/troubleshoot/debug-init-containers.md
-  - docs/tasks/administer-cluster/access-control-identity-management/
+  - docs/tasks/manage-daemon/update-daemon-set.md
+  - docs/tasks/manage-daemon/rollback-daemon-set.md
+
+- title: Manage GPUs
+  section:
+  - docs/tasks/manage-gpus/scheduling-gpus.md
+
+

_data/tutorials.yml

@@ -29,21 +29,36 @@ toc:
     section:
     - docs/tutorials/kubernetes-basics/update-intro.html
     - docs/tutorials/kubernetes-basics/update-interactive.html
+- title: Online Training Course
+  path: https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615
+- docs/tutorials/stateless-application/hello-minikube.md
+- title: Configuration
+  section:
+  - docs/tutorials/configuration/configure-redis-using-configmap.md
+- title: Object Management Using kubectl
+  section:
+  - docs/tutorials/object-management-kubectl/object-management.md
+  - docs/tutorials/object-management-kubectl/imperative-object-management-command.md
+  - docs/tutorials/object-management-kubectl/imperative-object-management-configuration.md
+  - docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md
 - title: Stateless Applications
   section:
-  - docs/tutorials/stateless-application/hello-minikube.md
-  - docs/tutorials/stateless-application/run-stateless-application-deployment.md
-  - docs/tutorials/stateless-application/expose-external-ip-address-service.md
+  - docs/tasks/run-application/run-stateless-application-deployment.md
+  - docs/tutorials/stateless-application/guestbook.md
+  - docs/tasks/access-application-cluster/service-access-application-cluster.md
   - docs/tutorials/stateless-application/expose-external-ip-address.md
 - title: Stateful Applications
   section:
   - docs/tutorials/stateful-application/basic-stateful-set.md
-  - docs/tutorials/stateful-application/run-stateful-application.md
-  - docs/tutorials/stateful-application/run-replicated-stateful-application.md
+  - docs/tasks/run-application/run-single-instance-stateful-application.md
+  - docs/tasks/run-application/run-replicated-stateful-application.md
+  - docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
+  - docs/tutorials/stateful-application/cassandra.md
   - docs/tutorials/stateful-application/zookeeper.md
-- title: Connecting Applications
+- title: Clusters
   section:
-  - docs/tutorials/connecting-apps/connecting-frontend-backend.md
+  - docs/tutorials/clusters/apparmor.md
 - title: Services
   section:
   - docs/tutorials/services/source-ip.md
+

_includes/api-reference-content-moved.md

@@ -0,0 +1,2 @@
+The topics in the `/docs/api-reference/` section of the Kubernetes docs
+are being moved to the [Reference](/docs/reference/) section. The content in this topic has moved to:

_includes/code.html

@@ -14,7 +14,7 @@
                 {% if ghlink %}<a href="{{ghlink}}" download="{{include.file}}">{% endif %}
                     <code>{{include.file}}</code>
                 {% if ghlink %}</a>{% endif %}
-                <img src="/images/copycode.svg" style="max-height:24px" onClick="copyCode('{{include.file | handleize}}')" title="Copy {{include.file}} to clipboard">
+                <img src="/images/copycode.svg" style="max-height:24px" onclick="copyCode('{{include.file | handleize}}')" title="Copy {{include.file}} to clipboard">
             </th>
         </tr>
     </thead>

_includes/feature-dialog.md

@@ -0,0 +1,28 @@
+<a href="#" id="feature-state-dialog-link" class="ui-state-default ui-corner-all"><span class="ui-icon ui-icon-newwin"></span>{{ dialog_title }}</a>
+<div id="feature-state-dialog" class="ui-dialog-content" title="{{ dialog_title }}">
+{{ dialog_content | markdownify }}
+</div>
+{% raw %}<script>
+$(function(){
+    
+    $( "#feature-state-dialog" ).dialog({
+        autoOpen: false,
+        width: {% endraw %}{{ dialog_width | default: "600" }}{% raw %},
+        buttons: [
+            {
+                text: "Ok",
+                click: function() {
+                    $( this ).dialog( "close" );
+                }
+            }
+        ]
+    });
+
+    // Link to open the dialog
+    $( "#feature-state-dialog-link" ).click(function( event ) {
+        $( "#feature-state-dialog" ).dialog( "open" );
+        event.preventDefault();
+    });
+
+});
+</script>{% endraw %}

_includes/feature-state-alpha.md

@@ -0,0 +1,13 @@
+{% assign dialog_title = "alpha" %}
+{% capture dialog_content %}
+This feature is currently in a *alpha* state, meaning:
+
+* The version names contain alpha (e.g. v1alpha1).
+* Might be buggy. Enabling the feature may expose bugs. Disabled by default.
+* Support for feature may be dropped at any time without notice.
+* The API may change in incompatible ways in a later software release without notice.
+* Recommended for use only in short-lived testing clusters, due to increased risk of bugs and lack of long-term support.
+
+{% endcapture %}
+
+**FEATURE STATE:** `Kubernetes {{ for_k8s_version | default: page.version }}` {% include feature-dialog.md %}

_includes/feature-state-beta.md

@@ -0,0 +1,14 @@
+{% assign dialog_title = "beta" %}
+{% capture dialog_content %}
+This feature is currently in a *beta* state, meaning:
+
+* The version names contain beta (e.g. v2beta3).
+* Code is well tested. Enabling the feature is considered safe. Enabled by default.
+* Support for the overall feature will not be dropped, though details may change.
+* The schema and/or semantics of objects may change in incompatible ways in a subsequent beta or stable release. When this happens, we will provide instructions for migrating to the next version. This may require deleting, editing, and re-creating API objects. The editing process may require some thought. This may require downtime for applications that rely on the feature.
+* Recommended for only non-business-critical uses because of potential for incompatible changes in subsequent releases. If you have multiple clusters that can be upgraded independently, you may be able to relax this restriction.
+* **Please do try our beta features and give feedback on them! After they exit beta, it may not be practical for us to make more changes.**
+
+{% endcapture %}
+
+**FEATURE STATE:** `Kubernetes {{ for_k8s_version | default: page.version }}` {% include feature-dialog.md %}

_includes/feature-state-deprecated.md

@@ -0,0 +1,6 @@
+{% assign dialog_title = "deprecated" %}
+{% capture dialog_content %}
+This feature is *deprecated*. For more information on this state, see the [Kubernetes Deprecation Policy](/docs/reference/deprecation-policy/).
+{% endcapture %}
+
+**DEPRECATION NOTICE:** As of `Kubernetes {{ for_k8s_version | default: page.version }}`, this has been {% include feature-dialog.md %}

_includes/feature-state-stable.md

@@ -0,0 +1,10 @@
+{% assign dialog_title = "stable" %}
+{% capture dialog_content %}
+This feature is *stable*, meaning:
+
+* The version name is vX where X is an integer.
+* Stable versions of features will appear in released software for many subsequent versions.
+
+{% endcapture %}
+
+**FEATURE STATE:** `Kubernetes {{ for_k8s_version | default: page.version }}` {% include feature-dialog.md %}

_includes/federated-task-tutorial-prereqs.md

@@ -0,0 +1,8 @@
+This guide assumes that you have a running Kubernetes Cluster
+Federation installation. If not, then head over to the
+[federation admin guide](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) to learn how to
+bring up a cluster federation (or have your cluster administrator do
+this for you).
+Other tutorials, such as Kelsey Hightower's 
+[Federated Kubernetes Tutorial](https://github.com/kelseyhightower/kubernetes-cluster-federation),
+might also help you create a Federated Kubernetes cluster.

_includes/federation-content-moved.md

@@ -0,0 +1,2 @@
+The topics in the [Federation API](/docs/federation/api-reference/) section of the Kubernetes docs
+are being moved to the [Reference](/docs/reference/) section. The content in this topic has moved to:

_includes/footer.html

@@ -1,34 +1,34 @@
 <footer>
-	<main class="light-text">
-		<nav>
-			<a href="/docs/hellonode/">Get Started</a>
-			<a href="/docs/">Documentation</a>
-			<a href="http://blog.kubernetes.io/">Blog</a>
-			<a href="/partners/">Partners</a>
-			<a href="/community/">Community</a>
-			<a href="/case-studies/">Case Studies</a>
-		</nav>
-		<div class="social">
-			<div>
-				<a href="https://twitter.com/kubernetesio" class="twitter"><span>twitter</span></a>
-				<a href="https://github.com/kubernetes/kubernetes" class="github"><span>Github</span></a>
-				<a href="http://slack.k8s.io/" class="slack"><span>Slack</span></a>
-			</div>
-			<div>
-				<a href="http://stackoverflow.com/questions/tagged/kubernetes" class="stack-overflow"><span>Stack Overflow</span></a>
-				<a href="https://groups.google.com/forum/#!forum/kubernetes-users" class="mailing-list"><span>Mailing List</span></a>
-				<a href="https://calendar.google.com/calendar/embed?src=nt2tcnbtbied3l6gi2h29slvc0%40group.calendar.google.com" class="calendar"><span>Events Calendar</span></a>
-			</div>
-			<div>
-				<a href="//get.k8s.io" class="button">Download K8s</a>
-				<a href="https://github.com/kubernetes/kubernetes" class="button">Contribute to the K8s codebase</a>
-			</div>
-		</div>
-		<div id="miceType" class="center">
-			&copy; {{ 'now' | date: "%Y" }} The Kubernetes Authors | Documentation Distributed under <a href="https://github.com/kubernetes/kubernetes.github.io/blob/master/LICENSE" class="light-text">CC BY 4.0</a>
-		</div>
-		<div id="miceType" class="center">
-			Copyright &copy; {{ 'now' | date: "%Y" }} The Linux Foundation&reg;. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our Trademark Usage page: <a href="https://www.linuxfoundation.org/trademark-usage" class="light-text">https://www.linuxfoundation.org/trademark-usage</a>
-		</div>
-	</main>
+    <main class="light-text">
+        <nav>
+            <a href="/docs/tutorials/stateless-application/hello-minikube/">Get Started</a>
+            <a href="/docs/home/">Documentation</a>
+            <a href="http://blog.kubernetes.io/">Blog</a>
+            <a href="/partners/">Partners</a>
+            <a href="/community/">Community</a>
+            <a href="/case-studies/">Case Studies</a>
+        </nav>
+        <div class="social">
+            <div>
+                <a href="https://twitter.com/kubernetesio" class="twitter"><span>twitter</span></a>
+                <a href="https://github.com/kubernetes/kubernetes" class="github"><span>Github</span></a>
+                <a href="http://slack.k8s.io/" class="slack"><span>Slack</span></a>
+            </div>
+            <div>
+                <a href="http://stackoverflow.com/questions/tagged/kubernetes" class="stack-overflow"><span>Stack Overflow</span></a>
+                <a href="https://groups.google.com/forum/#!forum/kubernetes-users" class="mailing-list"><span>Mailing List</span></a>
+                <a href="https://calendar.google.com/calendar/embed?src=nt2tcnbtbied3l6gi2h29slvc0%40group.calendar.google.com" class="calendar"><span>Events Calendar</span></a>
+            </div>
+            <div>
+                <a href="/docs/setup/pick-right-solution/" class="button">Get Kubernetes</a>
+                <a href="https://github.com/kubernetes/kubernetes" class="button">Contribute</a>
+            </div>
+        </div>
+        <div id="miceType" class="center">
+            &copy; {{ 'now' | date: "%Y" }} The Kubernetes Authors | Documentation Distributed under <a href="https://git.k8s.io/kubernetes.github.io/LICENSE" class="light-text">CC BY 4.0</a>
+        </div>
+        <div id="miceType" class="center">
+            Copyright &copy; {{ 'now' | date: "%Y" }} The Linux Foundation&reg;. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our Trademark Usage page: <a href="https://www.linuxfoundation.org/trademark-usage" class="light-text">https://www.linuxfoundation.org/trademark-usage</a>
+        </div>
+    </main>
 </footer>

_includes/head.html

@@ -2,12 +2,19 @@
     <meta charset="utf-8">
     <meta name="viewport" content="width=device-width, initial-scale=1">
     <link rel="shortcut icon" type="image/png" href="/images/favicon.png">
-    <link href='https://fonts.googleapis.com/css?family=Roboto:400,100,100italic,300,300italic,400italic,500,500italic,700,700italic,900,900italic' rel='stylesheet' type='text/css'>
-    <link rel="stylesheet" href='https://fonts.googleapis.com/css?family=Roboto+Mono' type='text/css'>
-    <link rel="stylesheet" href="/css/styles.css"/>
-    <link rel="stylesheet" href="/css/jquery-ui.min.css">
-    <link rel="stylesheet" href="/css/sweetalert.css">
-    {% if page.class == "gridPage" %}<link rel="stylesheet" href="/css/gridpage.css">{% endif %}
+    <link rel="stylesheet" type="text/css" href="https://fonts.googleapis.com/css?family=Roboto:400,100,100italic,300,300italic,400italic,500,500italic,700,700italic,900,900italic">
+    <link rel="stylesheet" type="text/css" href="https://fonts.googleapis.com/css?family=Roboto+Mono">
+    <link rel="stylesheet" type="text/css" href="/css/styles.css">
+    <link rel="stylesheet" type="text/css" href="/css/jquery-ui.min.css">
+    <link rel="stylesheet" type="text/css" href="/css/sweetalert.css">
+    {% if page.class == "gridPage" %}<link rel="stylesheet" type="text/css" href="/css/gridpage.css">{% endif %}
+
+    {% if page.description %}
+    <meta name="description" content="{{ page.description }}" />
+    {% else %}
+    <meta name="description" content="{{ page.title }}" />
+    {% endif %}
+
     <script src="/js/jquery-2.2.0.min.js"></script>
     <script src="/js/jquery-ui.min.js"></script>
     <script src="/js/script.js"></script>

_includes/header.html

@@ -5,13 +5,13 @@
 
     <div class="nav-buttons" data-auto-burger="primary">
         <ul class="global-nav">
-            <li><a href="/docs/">Documentation</a></li>
+            <li><a href="/docs/home/">Documentation</a></li>
             <li><a href="http://blog.kubernetes.io/">Blog</a></li>
             <li><a href="/partners/">Partners</a></li>
             <li><a href="/community/">Community</a></li>
             <li><a href="/case-studies/">Case Studies</a></li>
         </ul>
-        <!-- <a href="/docs/" class="button" id="viewDocs" data-auto-burger-exclude>View Documentation</a> -->
+        <!-- <a href="/docs/home" class="button" id="viewDocs" data-auto-burger-exclude>View Documentation</a> -->
         <a href="/docs/tutorials/kubernetes-basics/" class="button" id="tryKubernetes" data-auto-burger-exclude>Try Kubernetes</a>
         <button id="hamburger" onclick="kub.toggleMenu()" data-auto-burger-exclude><div></div></button>
     </div>
@@ -19,11 +19,11 @@
     <nav id="mainNav">
         <main data-auto-burger="primary">
         <div class="nav-box">
-            <h3><a href="/docs/hellonode/">Get Started</a></h3>
+            <h3><a href="/docs/tutorials/stateless-application/hello-minikube/">Get Started</a></h3>
             <p>Ready to get your hands dirty? Build a simple Kubernetes cluster that runs "Hello World" for Node.js.</p>
         </div>
         <div class="nav-box">
-            <h3><a href="/docs/">Documentation</a></h3>
+            <h3><a href="/docs/home/">Documentation</a></h3>
             <p>Learn how to use Kubernetes with the use of walkthroughs, samples, and reference documentation. You can even <a href="/editdocs/" data-auto-burger-exclude>help contribute to the docs</a>!</p>
         </div>
         <div class="nav-box">

_includes/partner-script.js

@@ -279,14 +279,246 @@
  			logo: 'harbur',
  			link: 'https://harbur.io/',
  			blurb: 'Based in Barcelona, Harbur is a consulting firm that helps companies deploy self-healing solutions empowered by Container technologies'
-  	},
+  		},
 		{
  			type: 1,
  			name: 'Endocode',
  			logo: 'endocode',
  			link: 'https://endocode.com/kubernetes/',
  			blurb: 'Endocode practices and teaches the open source way. Kernel to cluster - Dev to Ops. We offer Kubernetes trainings, services and support.'
-  	}
+  		},
+		{
+ 			type: 0,
+ 			name: 'Spotinst',
+ 			logo: 'spotinst',
+ 			link: 'http://blog.spotinst.com/2016/08/04/elastigroup-kubernetes-minions-steroids/',
+ 			blurb: 'Spotinst uses a prediction algorithm in the Amazon EC2 Spot allowing k8s clusters to increase performance and lower the infrastructure costs'
+  		},
+		{
+ 			type: 1,
+ 			name: 'inwinSTACK',
+ 			logo: 'inwinstack',
+ 			link: 'http://www.inwinstack.com/index.php/en/solutions-en/',
+ 			blurb: 'Our container service leverages OpenStack-based infrastructure and its container orchestration engine Magnum to manage Kubernetes clusters.'
+  		},
+		{
+ 			type: 1,
+ 			name: 'Semantix',
+ 			logo: 'semantix',
+ 			link: 'http://www.semantix.com.br/',
+ 			blurb: 'Semantix is a company that works with data analytics and distributed systems. Kubernetes is used to orchestrate services for our customers.'
+  		},
+		{
+ 			type: 0,
+ 			name: 'ASM Technologies Limited',
+ 			logo: 'asm',
+ 			link: 'http://www.asmtech.com/',
+ 			blurb: 'Our technology supply chain portfolio enables your software products to be accessible, viable and available more effectively.'
+  		},
+		{
+ 			type: 1,
+ 			name: 'InfraCloud Technologies',
+ 			logo: 'infracloud',
+ 			link: 'http://blog.infracloud.io/state-of-kubernetes/',
+ 			blurb: 'InfraCloud Technologies is software consultancy which provides services in Containers, Cloud and DevOps.'
+  		},
+		{
+ 			type: 0,
+ 			name: 'SignalFx',
+ 			logo: 'signalfx',
+ 			link: 'https://github.com/signalfx/integrations/tree/master/kubernetes',
+ 			blurb: 'Gain real-time visibility across metrics & the most intelligent alerts for todays architectures, including deep integration with Kubernetes'
+  		},
+		{
+ 			type: 0,
+ 			name: 'NATS',
+ 			logo: 'nats',
+ 			link: 'https://github.com/pires/kubernetes-nats-cluster',
+ 			blurb: 'NATS is a simple, secure, and scalable cloud native messaging system.'
+  		},
+		{
+ 			type: 1,
+ 			name: 'RX-M',
+ 			logo: 'rxm',
+ 			link: 'http://rx-m.com/training/kubernetes-training/',
+ 			blurb: 'Market neutral Kubernetes Dev, DevOps and Production training and consulting services'
+  		},
+		{
+ 			type: 1,
+ 			name: 'Emerging Technology Advisors',
+ 			logo: 'eta',
+ 			link: 'https://www.emergingtechnologyadvisors.com/services/kubernetes.html',
+ 			blurb: 'ETA helps companies architect, implement, and manage scalable applications using Kubernetes on on public or private cloud.'
+  		},
+		{
+ 			type: 0,
+ 			name: 'CloudPlex.io',
+ 			logo: 'cloudplex',
+ 			link: 'http://www.cloudplex.io',
+ 			blurb: 'CloudPlex enables operations teams to visually deploy, orchestrate, manage, and monitor infrastructure, applications, and services in public or private cloud.'
+  		},
+		{
+ 			type: 1,
+ 			name: 'Kumina',
+ 			logo: 'kumina',
+ 			link: 'https://www.kumina.nl/managed_kubernetes',
+ 			blurb: 'Kumina creates Kubernetes solutions on your choice of infrastructure with around-the-clock management and unlimited support.'
+  		},
+		{
+ 			type: 0,
+ 			name: 'CA Technologies',
+ 			logo: 'ca',
+ 			link: 'https://www.ca.com/us/products/application-deployment.html',
+ 			blurb: 'The RA CDE Kubernetes plugin enables an automated process for pushing changes to production by applying standard Kubernetes YAML files'
+  		},
+		{
+ 			type: 0,
+ 			name: 'CoScale',
+ 			logo: 'coscale',
+ 			link: 'http://www.coscale.com/blog/how-to-monitor-your-kubernetes-cluster',
+ 			blurb: 'Full stack monitoring of containers and microservices orchestrated by Kubernetes. Powered by anomaly detection to find problems faster.'
+  		},
+		{
+ 			type: 0,
+ 			name: 'Supergiant.io',
+ 			logo: 'supergiant',
+ 			link: 'https://supergiant.io/blog/supergiant-packing-algorithm-unique-save-money',
+ 			blurb: 'Supergiant autoscales hardware for Kubernetes. Open-source, it makes HA, distributed, stateful apps easy to deploy, manage, and scale.'
+  		},
+		{
+ 			type: 0,
+ 			name: 'Avi Networks',
+ 			logo: 'avinetworks',
+ 			link: 'https://kb.avinetworks.com/avi-vantage-openshift-installation-guide/',
+ 			blurb: 'Avis elastic application services fabric provides scalable, feature rich & integrated L4-7 networking for K8S environments.'
+  		},
+		{
+ 			type: 1,
+ 			name: 'codecrux web technologies pvt ltd',
+ 			logo: 'codecrux',
+ 			link: 'http://codecrux.com/kubernetes/',
+ 			blurb: 'At CodeCrux we help your organization get the most out of Containers and Kubernetes, regardless of where you are in your journey'
+  		},
+		{
+ 			type: 0,
+ 			name: 'Greenqloud',
+ 			logo: 'qstack',
+ 			link: 'https://www.qstack.com/application-orchestration/',
+ 			blurb: 'Qstack provides self-serviceable on-site Kubernetes clusters with an intuitive User Interface for Infrastructure and Kubernetes management.'
+  		},
+		{
+ 			type: 1,
+ 			name: 'StackOVerdrive.io',
+ 			logo: 'stackoverdrive',
+ 			link: 'http://www.stackoverdrive.net/kubernetes-consulting/',
+ 			blurb: 'We are a devops consulting firm and we do alot of work with containers and Kunbernetes is one of our go to tools.'
+  		},
+		{
+ 			type: 0,
+ 			name: 'F5 Networks',
+ 			logo: 'f5networks',
+ 			link: 'https://f5.com/about-us/news/press-kit',
+ 			blurb: 'Integration of our ADC services with Kubernetes'
+  		},
+		{
+ 			type: 0,
+ 			name: 'StackIQ, Inc.',
+ 			logo: 'stackiq',
+ 			link: 'https://www.stackiq.com/kubernetes/',
+ 			blurb: 'With Stacki and the Stacki Pallet for Kubernetes, you can go from bare metal to containers in one step very quickly and easily.'
+  		},
+		{
+ 			type: 0,
+ 			name: 'Cobe',
+ 			logo: 'cobe',
+ 			link: 'https://cobe.io/blog/posts/problems-within-your-kubernetes-cluster/',
+ 			blurb: 'Manage Kubernetes clusters with a live, searchable model that captures all relationships and performance data in full visualised context.'
+  		},
+		{
+ 			type: 0,
+ 			name: 'Datawire',
+ 			logo: 'datawire',
+ 			link: 'http://www.datawire.io',
+ 			blurb: 'Datawires open source tools let your microservices developers be awesomely productive on Kubernetes, while letting ops sleep at night.'
+  		},
+		{
+ 			type: 0,
+ 			name: 'Mashape, Inc.',
+ 			logo: 'mashape',
+ 			link: 'https://getkong.org/install/kubernetes/',
+ 			blurb: 'Kong is a scalable open source API layer that runs in front of any RESTful API and can be provisioned to a Kubernetes cluster.'
+  		},
+		{
+ 			type: 0,
+ 			name: 'F5 Networks',
+ 			logo: 'f5networks',
+ 			link: 'http://github.com/f5networks',
+ 			blurb: 'We have a LB integration into Kubernetes.'
+  		},
+		{
+ 			type: 1,
+ 			name: 'Lovable Tech',
+ 			logo: 'lovable',
+ 			link: 'https://drive.google.com/file/d/0BxCnAyMK1pgBTUFOdEZsUndLa01xMGJYZWtUVmVOdldadk80/view?usp=sharing',
+ 			blurb: ''
+  		},
+		{
+ 			type: 0,
+ 			name: 'StackState',
+ 			logo: 'stackstate',
+ 			link: 'http://stackstate.com/platform/container-monitoring',
+ 			blurb: 'Operational Analytics across teams and tools. Includes topology visualization, root cause analysis and anomaly detection for Kubernetes.'
+  		},
+		{
+ 			type: 1,
+ 			name: 'INEXCCO INC',
+ 			logo: 'inexcco',
+ 			link: 'https://www.inexcco.com/',
+ 			blurb: 'Strong DevOps and Cloud talent working with couple clients on kubernetes and helm implementations. '
+  		},
+		{
+ 			type: 0,
+ 			name: 'Bitnami',
+ 			logo: 'bitnami',
+ 			link: 'http://bitnami.com/kubernetes',
+ 			blurb: 'Bitnami brings a catalog of trusted, up to date, and easy to use applications and application building blocks to Kubernetes.'
+  		},
+		{
+ 			type: 1,
+ 			name: 'Nebulaworks',
+ 			logo: 'nebulaworks',
+ 			link: 'http://www.nebulaworks.com/container-platforms',
+ 			blurb: 'Nebulaworks provides services to help the enterprise adopt modern container platforms and optimized processes to enable innovation at scale.'
+  		},
+		{
+ 			type: 1,
+ 			name: 'EASYNUBE LTD',
+ 			logo: 'easynube',
+ 			link: 'https://www.carrefour.es/supermercado/?ic_source=portal-home&ic_medium=menu-links&ic_content=section-home',
+ 			blurb: 'Provide consultancy, architecture and implementation'
+  		},
+		{
+ 			type: 1,
+ 			name: 'Opcito Technologies',
+ 			logo: 'opcito',
+ 			link: 'http://www.opcito.com/kubernetes/',
+ 			blurb: 'Opcito is a software consultancy that uses Kubernetes to help organisations build, architect & deploy highly scalable applications.'
+  		},
+		{
+ 			type: 0,
+ 			name: 'Huawei Technologies Co., Ltd.',
+ 			logo: 'huawei',
+ 			link: 'http://developer.huawei.com/ict/en/site-paas',
+ 			blurb: 'FusionStage is an enterprise-grade PaaS, the core of which is based on open source container technology including Kubernetes and Docker.'
+  		},
+		{
+ 			type: 0,
+ 			name: '{code} by Dell EMC',
+ 			logo: 'codedellemc',
+ 			link: 'https://blog.codedellemc.com',
+ 			blurb: 'Respected as a thought leader in storage persistence for containerized applications. Contributed significant work to K8 and Ecosystem'
+  		}
+		
 	]
 
 	var isvContainer = document.getElementById('isvContainer')

_includes/tabs.html

@@ -1,17 +0,0 @@
-{% assign tabsraw = tabspec | newline_to_br | split: '<br />' %}
-{% assign tabsetname = tabsraw[0] %}
-<script>$(function(){$("#{{tabsetname}}").tabs();});</script>
-<div id="{{tabsetname}}">
-  <ul>{% for tab in tabsraw offset:1 %}{% assign thisTab = tab | split: ',' %}
-    <li><a href="#{{ thisTab[0] | strip | handleize }}">{{ thisTab[0] | strip}}</a></li>{% endfor %}
-  </ul>
-  {% for tab in tabsraw offset:1 %}
-  {% assign thisTab = tab | split: ',' %}
-  {% assign tabLang=thisTab[1] %}
-  {% assign tabFile=thisTab[2] %}
-  {% assign tabGHLink=thisTab[3] %}
-  <div id="{{ thisTab[0] | strip | handleize }}">
-  {% include code.html language=tabLang file=tabFile ghlink=tabGHLink %}
-  </div>
-  {% endfor %}
-</div>

_includes/tabs.md

@@ -0,0 +1,15 @@
+{% comment %} See /docs/tabs-example.md for usage example. {% endcomment %}
+{% assign tab_set_id = tab_set_name | default: "tabset" | slugify %}
+<div id="{{tab_set_id}}">
+    <ul>
+{% for name in tab_names %}
+        <li><a href="#{{tab_set_id}}-{{forloop.index0}}">{{ name | strip }}</a></li>
+{% endfor %}
+    </ul>
+{% for content in tab_contents %}
+    <div id="{{tab_set_id}}-{{forloop.index0}}">
+    {{ content | markdownify }}
+    </div>
+{% endfor %}
+</div>
+<script>$(function(){$("#{{tab_set_id}}").tabs();});</script>

_includes/templates/landing-page.md

@@ -1,121 +0,0 @@
-{% if page.cards %}<!-- check for this before going any further; if not present, skip to else at bottom -->
-<style>
-h2, h3, h4 {
-  border-bottom: 0px !important;
-  font-size: 22px !important;
-  padding-bottom: 20px !important;
-}
-.colContainer {
-  padding-top:2px;
-  padding-left: 2px;
-  overflow: auto;
-}
-#samples a {
-  color: #000;
-}
-.col3rd {
-  display: block;
-  float: left;
-  margin-right: 30px;
-  margin-bottom: 30px;
-  overflow: hidden;
-}
-.col3rd h3, .col2nd h3 {
-  margin-bottom: 0px !important;
-}
-.col3rd .button, .col2nd .button {
-  margin-top: 20px;
-  border-radius: 2px;
-}
-.col3rd p, .col2nd p {
-  margin-left: 2px;
-}
-.col2nd {
-  display: block;
-  width: 400px;
-  float: left;
-  margin-right: 30px;
-  margin-bottom: 30px;
-  overflow: hidden;
-}
-.shadowbox {
-  width: 250px;
-  display: inline;
-  float: left;
-  text-transform: none;
-  font-weight: bold;
-  text-overflow: ellipsis;
-  overflow: hidden;
-  line-height: 24px;
-  position: relative;
-  display: block;
-  cursor: pointer;
-  box-shadow: 0 2px 2px rgba(0,0,0,.24),0 0 2px rgba(0,0,0,.12);
-  border-radius: 5px;
-  background: #fff;
-  transition: all .3s;
-  padding: 16px;
-  margin: 0 16px 16px 0;
-  text-decoration: none;
-  letter-spacing: .01em;
-  height: 220px;
-}
-.shadowbox img {
-    min-width: 100px;
-    max-width: 100px;
-    max-height: 50px;
-    margin-right: 5px;
-    margin-bottom: 5px;
-    float: left;
-}
-</style>
-
-<div class="colContainer">
-{% for card in page.cards %}{% if card.title %}
-  <div class="col3rd shadowbox">
-    <h3>{{card.title}}</h3>
-    <p>{% if card.image %}<img src="{{card.image}}">{% endif %}{{card.description}}</p>
-  </div>
-{% endif %}{% endfor %}
-</div>
-
-{% else %}
-
-### ERROR: You must define "cards" front-matter YAML
-{: style="color:red" }
-
-This template requires that you insert YAML at the top of your document
-that defines the "cards" you'd like to display on the page. The cards will
-render in clickable boxes. 
-
-To get rid of this message and take advantage of this template, define `cards`:
-
-```yaml
----
-cards:
-- progression: no
-- card:
-  title: Mean Stack
-  image: /docs/meanstack/image_0.png
-  description: Lorem ipsum dolor it verberum.
-- card:
-  title: Guestbook + Redis
-  image: /images/docs/redis.svg
-  description: Lorem ipsum dolor it verberum.
-- card:
-  title: Cloud Native Cassandra
-  image: /images/docs/cassandra.svg
-  description: Lorem ipsum dolor it verberum.
-- card:
-  title: WordPress + MySQL
-  image: /images/docs/wordpress.svg
-  description: Lorem ipsum dolor it verberum. 
----
-```
-
-**Note:** If `progression` is set to `yes` then a "Start Here!" icon will be
-placed on the first card and arrows suggesting linear reading will be overlayed
-between the other cards, telling the reader that they should explore the content
-in a certain order. 
-
-{% endif %}

_includes/user-guide-migration-notice.md

@@ -0,0 +1,12 @@
+
+
+<table style="background-color:#eeeeee">
+<tr>
+  <td>
+  <p><b>NOTICE</b></p>
+  <p>As of March 14, 2017, the Kubernetes SIG-Docs-Maintainers group have begun migration of the User Guide content as announced previously to the <a href="https://git.k8s.io/community/sig-docs">SIG Docs community</a> through the <a href="https://groups.google.com/forum/#!forum/kubernetes-sig-docs">kubernetes-sig-docs</a> group and <a href="https://kubernetes.slack.com/messages/sig-docs/">kubernetes.slack.com #sig-docs</a> channel.</p>
+  <p>The user guides within this section are being refactored into topics within Tutorials, Tasks, and Concepts. Anything that has been moved will have a notice placed in its previous location as well as a link to its new location. The reorganization implements a new table of contents and should improve the documentation's findability and readability for a wider range of audiences.</p>
+  <p>For any questions, please contact: <a href="mailto:kubernetes-sig-docs@googlegroups.com">kubernetes-sig-docs@googlegroups.com</a></p>
+  </td>
+</tr>
+</table>

_includes/v1.3/extensions-v1beta1-definitions.html

@@ -4275,10 +4275,10 @@ Populated by the system when a graceful deletion is requested. Read-only. More i
 <tr>
 <td class="tableblock halign-left valign-top"><p class="tableblock">host</p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock">Host is the fully qualified domain name of a network host, as defined by RFC 3986. Note the following deviations from the "host" part of the URI as defined in the RFC: 1. IPs are not allowed. Currently an IngressRuleValue can only apply to the<br>
-	  IP in the Spec of the parent Ingress.<br>
+      IP in the Spec of the parent Ingress.<br>
 2. The <code>:</code> delimiter is not respected because ports are not allowed.<br>
-	  Currently the port of an Ingress is implicitly :80 for http and<br>
-	  :443 for https.<br>
+      Currently the port of an Ingress is implicitly :80 for http and<br>
+      :443 for https.<br>
 Both these may change in the future. Incoming requests are matched against the host before the IngressRuleValue. If the host is unspecified, the Ingress routes all traffic based on the specified IngressRuleValue.</p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock">string</p></td>

_includes/v1.3/extensions-v1beta1-operations.html

@@ -1,4 +1,4 @@
-
+<!DOCTYPE html>
 <html lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

_includes/v1.3/v1-definitions.html

@@ -1,4 +1,4 @@
-
+<!DOCTYPE html>
 <html lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

_includes/v1.3/v1-operations.html

@@ -1,4 +1,4 @@
-
+<!DOCTYPE html>
 <html lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

_includes/v1.4/extensions-v1beta1-definitions.html

@@ -4393,10 +4393,10 @@ Populated by the system when a graceful deletion is requested. Read-only. More i
 <tr>
 <td class="tableblock halign-left valign-top"><p class="tableblock">host</p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock">Host is the fully qualified domain name of a network host, as defined by RFC 3986. Note the following deviations from the "host" part of the URI as defined in the RFC: 1. IPs are not allowed. Currently an IngressRuleValue can only apply to the<br>
-	  IP in the Spec of the parent Ingress.<br>
+      IP in the Spec of the parent Ingress.<br>
 2. The <code>:</code> delimiter is not respected because ports are not allowed.<br>
-	  Currently the port of an Ingress is implicitly :80 for http and<br>
-	  :443 for https.<br>
+      Currently the port of an Ingress is implicitly :80 for http and<br>
+      :443 for https.<br>
 Both these may change in the future. Incoming requests are matched against the host before the IngressRuleValue. If the host is unspecified, the Ingress routes all traffic based on the specified IngressRuleValue.</p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock">string</p></td>

_includes/v1.4/extensions-v1beta1-operations.html

@@ -1,4 +1,4 @@
-
+<!DOCTYPE html>
 <html lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

_includes/v1.4/v1-definitions.html

@@ -1,4 +1,4 @@
-
+<!DOCTYPE html>
 <html lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

_includes/v1.4/v1-operations.html

@@ -1,4 +1,4 @@
-
+<!DOCTYPE html>
 <html lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

_includes/v1.5/extensions-v1beta1-definitions.html

@@ -3453,7 +3453,7 @@ Populated by the system when a graceful deletion is requested. Read-only. More i
 </tr>
 <tr>
 <td class="tableblock halign-left valign-top"><p class="tableblock">nodeSelector</p></td>
-<td class="tableblock halign-left valign-top"><p class="tableblock">NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node&#8217;s labels for the pod to be scheduled on that node. More info: <a href="http://kubernetes.io/docs/user-guide/node-selection/README">http://kubernetes.io/docs/user-guide/node-selection/README</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node&#8217;s labels for the pod to be scheduled on that node. More info: <a href="http://kubernetes.io/docs/user-guide/node-selection">http://kubernetes.io/docs/user-guide/node-selection</a></p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock">object</p></td>
 <td class="tableblock halign-left valign-top"></td>
@@ -3557,14 +3557,14 @@ Populated by the system when a graceful deletion is requested. Read-only. More i
 <tbody>
 <tr>
 <td class="tableblock halign-left valign-top"><p class="tableblock">postStart</p></td>
-<td class="tableblock halign-left valign-top"><p class="tableblock">PostStart is called immediately after a container is created. If the handler fails, the container is terminated and restarted according to its restart policy. Other management of the container blocks until the hook completes. More info: <a href="http://kubernetes.io/docs/user-guide/container-environment#hook-details">http://kubernetes.io/docs/user-guide/container-environment#hook-details</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">PostStart is called immediately after a container is created. If the handler fails, the container is terminated and restarted according to its restart policy. Other management of the container blocks until the hook completes. More info: <a href="http://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks#hook-details">http://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks#hook-details</a></p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#_v1_handler">v1.Handler</a></p></td>
 <td class="tableblock halign-left valign-top"></td>
 </tr>
 <tr>
 <td class="tableblock halign-left valign-top"><p class="tableblock">preStop</p></td>
-<td class="tableblock halign-left valign-top"><p class="tableblock">PreStop is called immediately before a container is terminated. The container is terminated after the handler completes. The reason for termination is passed to the handler. Regardless of the outcome of the handler, the container is eventually terminated. Other management of the container blocks until the hook completes. More info: <a href="http://kubernetes.io/docs/user-guide/container-environment#hook-details">http://kubernetes.io/docs/user-guide/container-environment#hook-details</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">PreStop is called immediately before a container is terminated. The container is terminated after the handler completes. The reason for termination is passed to the handler. Regardless of the outcome of the handler, the container is eventually terminated. Other management of the container blocks until the hook completes. More info: <a href="http://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks#hook-details">http://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks#hook-details</a></p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#_v1_handler">v1.Handler</a></p></td>
 <td class="tableblock halign-left valign-top"></td>
@@ -4613,10 +4613,10 @@ Populated by the system when a graceful deletion is requested. Read-only. More i
 <tr>
 <td class="tableblock halign-left valign-top"><p class="tableblock">host</p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock">Host is the fully qualified domain name of a network host, as defined by RFC 3986. Note the following deviations from the "host" part of the URI as defined in the RFC: 1. IPs are not allowed. Currently an IngressRuleValue can only apply to the<br>
-	  IP in the Spec of the parent Ingress.<br>
+      IP in the Spec of the parent Ingress.<br>
 2. The <code>:</code> delimiter is not respected because ports are not allowed.<br>
-	  Currently the port of an Ingress is implicitly :80 for http and<br>
-	  :443 for https.<br>
+      Currently the port of an Ingress is implicitly :80 for http and<br>
+      :443 for https.<br>
 Both these may change in the future. Incoming requests are matched against the host before the IngressRuleValue. If the host is unspecified, the Ingress routes all traffic based on the specified IngressRuleValue.</p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock">string</p></td>

_includes/v1.5/extensions-v1beta1-operations.html

@@ -1,4 +1,4 @@
-
+<!DOCTYPE html>
 <html lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

_includes/v1.5/v1-definitions.html

@@ -1,4 +1,4 @@
-
+<!DOCTYPE html>
 <html lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
@@ -4172,7 +4172,7 @@ The resulting set of endpoints can be viewed as:<br>
 </tr>
 <tr>
 <td class="tableblock halign-left valign-top"><p class="tableblock">nodeSelector</p></td>
-<td class="tableblock halign-left valign-top"><p class="tableblock">NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node&#8217;s labels for the pod to be scheduled on that node. More info: <a href="http://kubernetes.io/docs/user-guide/node-selection/README">http://kubernetes.io/docs/user-guide/node-selection/README</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node&#8217;s labels for the pod to be scheduled on that node. More info: <a href="http://kubernetes.io/docs/user-guide/node-selection">http://kubernetes.io/docs/user-guide/node-selection</a></p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock">object</p></td>
 <td class="tableblock halign-left valign-top"></td>
@@ -8146,7 +8146,7 @@ The resulting set of endpoints can be viewed as:<br>
 </tr>
 <tr>
 <td class="tableblock halign-left valign-top"><p class="tableblock">unschedulable</p></td>
-<td class="tableblock halign-left valign-top"><p class="tableblock">Unschedulable controls node schedulability of new pods. By default, node is schedulable. More info: <a href="http://releases.k8s.io/HEAD/docs/admin/node.md#manual-node-administration"">http://releases.k8s.io/HEAD/docs/admin/node.md#manual-node-administration"</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Unschedulable controls node schedulability of new pods. By default, node is schedulable. More info: <a href="http://releases.k8s.io/HEAD/docs/admin/node.md#manual-node-administration">http://releases.k8s.io/HEAD/docs/admin/node.md#manual-node-administration</a></p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock">boolean</p></td>
 <td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td>
@@ -8263,4 +8263,4 @@ Last updated 2016-11-17 06:26:10 UTC
 </div>
 </div>
 </body>
-</html>
+</html>

_includes/v1.5/v1-operations.html

@@ -1,4 +1,4 @@
-
+<!DOCTYPE html>
 <html lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

_layouts/docwithnav.html

@@ -22,18 +22,15 @@
   <h5>{{ toc.abstract }}</h5>
   <div id="vendorStrip" class="light-text">
     <ul>
-      <li><a href="/docs/" {% if toc.bigheader == "Kubernetes Documentation" %}class="YAH"{% endif %}>DOCS HOME</a></li>
-      <li><a href="/docs/user-guide/" {% if toc.bigheader == "Guides" %}class="YAH"{% endif %}>GUIDES</a></li>
-      <li><a href="/docs/tutorials/" {% if toc.bigheader == "Tutorials" %}class="YAH"{% endif %}>TUTORIALS</a></li>
-      <li><a href="/docs/tasks/" {% if toc.bigheader == "Tasks" %}class="YAH"{% endif %}>TASKS</a></li>
+      <li><a href="/docs/home/" {% if toc.bigheader == "Kubernetes Documentation" %}class="YAH"{% endif %}>HOME</a></li>
+      <li><a href="/docs/setup/" {% if toc.bigheader == "Setup" %}class="YAH"{% endif %}>SETUP</a></li>
       <li><a href="/docs/concepts/" {% if toc.bigheader == "Concepts" %}class="YAH"{% endif %}>CONCEPTS</a></li>
+      <li><a href="/docs/tasks/" {% if toc.bigheader == "Tasks" %}class="YAH"{% endif %}>TASKS</a></li>
+      <li><a href="/docs/tutorials/" {% if toc.bigheader == "Tutorials" %}class="YAH"{% endif %}>TUTORIALS</a></li>
       <li><a href="/docs/reference/" {% if toc.bigheader == "Reference Documentation" %}class="YAH"{% endif %}>REFERENCE</a></li>
-      <li><a href="/docs/tools/" {% if toc.bigheader == "Tools" %}class="YAH"{% endif %}>TOOLS</a></li>
-      <li><a href="/docs/samples/" {% if toc.bigheader == "Samples" %}class="YAH"{% endif %}>SAMPLES</a></li>
-      <li><a href="/docs/troubleshooting/" {% if toc.bigheader == "Support" %}class="YAH"{% endif %}>SUPPORT</a></li>
     </ul>
     <div id="searchBox">
-      <input type="text" id="search" placeholder="Search" onkeydown="if (event.keyCode==13) window.location.replace('/docs/search/?q=' + this.value)">
+      <input type="text" id="search" placeholder="Search" onkeydown="if (event.keyCode==13) window.location.replace('/docs/search/?q=' + this.value)" autofocus="autofocus">
     </div>
   </div>
 </section>
@@ -41,9 +38,7 @@
 <section id="encyclopedia">
   <div id="docsToc">
         <div class="pi-accordion">
-        {% if toc.bigheader != "Kubernetes Documentation" %}
           {% include_cached tree.html tree=toc.toc %}
-        {% endif %}
         </div> <!-- /pi-accordion -->
     <button class="push-menu-close-button" onclick="kub.toggleToc()"></button>
   </div> <!-- /docsToc -->
@@ -57,22 +52,22 @@
 
         {{ content }}
 
-        <p><a href=""><img src="https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/{{ page.path }}?pixel" alt="Analytics" /></a>
+        <p><a href=""><img src="https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/{{ page.path }}?pixel" alt="Analytics" /></a></p>
         {% if page.url != "/404.html" and page.url != "/docs/search/" %}
-		<script type="text/javascript">
-	        PDRTJS_settings_8345992 = {
-		        "id" : "8345992",
-		        "unique_id" : "{{ page.url }}",
-		        "title" : "{{ page.title }}",
-		        "permalink" : "http://kubernetes.github.io{{ page.url }}"
-	        };
-	        (function(d,c,j){if(!document.getElementById(j)){var pd=d.createElement(c),s;pd.id=j;pd.src=('https:'==document.location.protocol)?'https://polldaddy.com/js/rating/rating.js':'http://i0.poll.fm/js/rating/rating.js';s=document.getElementsByTagName(c)[0];s.parentNode.insertBefore(pd,s);}}(document,'script','pd-rating-js'));
-		</script>
-		<a href="" onclick="window.open('https://github.com/kubernetes/kubernetes.github.io/issues/new?title=Issue%20with%20' +
-		window.location.pathname)" class="button issue">Create an Issue</a>
-		<a href="/editdocs#{{ page.path }}" class="button issue">Edit this Page</a>
-	{% endif %}
-	</div>
+        <script type="text/javascript">
+            PDRTJS_settings_8345992 = {
+                "id" : "8345992",
+                "unique_id" : "{{ page.url }}",
+                "title" : "{{ page.title }}",
+                "permalink" : "http://kubernetes.github.io{{ page.url }}"
+            };
+            (function(d,c,j){if(!document.getElementById(j)){var pd=d.createElement(c),s;pd.id=j;pd.src=('https:'==document.location.protocol)?'https://polldaddy.com/js/rating/rating.js':'http://i0.poll.fm/js/rating/rating.js';s=document.getElementsByTagName(c)[0];s.parentNode.insertBefore(pd,s);}}(document,'script','pd-rating-js'));
+        </script>
+        <a href="" onclick="window.open('https://github.com/kubernetes/kubernetes.github.io/issues/new?title=Issue%20with%20' +
+        'k8s.io'+window.location.pathname)" class="button issue">Create an Issue</a>
+        <a href="/editdocs#{{ page.path }}" class="button issue">Edit this Page</a>
+    {% endif %}
+    </div>
 </section>
 
 {% include_cached footer.html %}

_sass/_base.sass

@@ -816,9 +816,9 @@ dd
 		font-weight: 500
 
 	p
-		font-size: 14px
+		font-size: 16px
 		font-weight: 300
-		line-height: 1.25em
+		line-height: 1.75em
 
 	p + p
 		margin-top: 10px
@@ -856,6 +856,7 @@ dd
 		display: block
 		margin: 20px 0
 		padding: 15px
+		position: relative
 		overflow-x: auto
 
 	h1 code, h2 code, h3 code, h4 code, h5 code, h6 code
@@ -863,6 +864,9 @@ dd
 		font-size: inherit
 		background-color: transparent
 
+	.includecode
+		table-layout: fixed
+
 	.includecode, .includecode th, .includecode td
 		padding: 0 !important
 
@@ -893,6 +897,8 @@ dd
 
 	li
 		margin-bottom: 0.75em
+		font-size: 16px
+		line-height: 1.75em
 
 	table
 		width: 100%
@@ -962,8 +968,8 @@ dd
 		//font-weight: 700
 		text-decoration: underline
 
-	a:visited
-		color: blueviolet
+//	a:visited
+//		color: blueviolet
 
 	a.button
 		border-radius: 2px
@@ -1277,7 +1283,7 @@ $feature-box-div-margin-bottom: 40px
 				background-color: $white
 				box-shadow: 0 5px 5px rgba(0,0,0,.24),0 0 5px rgba(0,0,0,.12)
 
-		#calendarWrapper
+		#calendarMeetings
 			position: relative
 			width: 80vw
 			height: 60vw
@@ -1285,12 +1291,284 @@ $feature-box-div-margin-bottom: 40px
 			max-height: 900px
 			margin: 20px auto
 
+		#calendarEvents
+			position: relative
+			width: 80vw
+			height: 30vw
+			max-width: 1200px
+			max-height: 450px
+			margin: 20px auto			
+
 		iframe
 			position: absolute
 			border: 0
 			width: 100%
 			height: 100%
 
+// Dialog
+.ui-icon
+	display: inline-block !important
+
+#feature-state-dialog-link
+	text-decoration: none !important
+	padding: 5px !important
+	a:visited
+		color: #454545 !important
+	a code
+		display: inline-block !important
+		box-sizing: border-box !important
+		background-color: #f7f7f7 !important
+		color: #303030 !important
+		font-family: "Roboto Mono", monospace !important
+		vertical-align: baseline !important
+		font-size: 14px !important
+		font-weight: bold !important
+		padding: 0px 4px !important
+
+#feature-state-dialog
+	background: #fff !important
+	border: 1px solid #ddd !important
+	padding: 0.5em 1em !important
+
+	ul, li
+		list-style: disc !important
+		margin: 4px 12px !important
+
+	p
+		margin: 8px 0px !important
+
+	code
+		display: inline-block !important
+		box-sizing: border-box !important
+		background-color: #f7f7f7 !important
+		color: #303030 !important
+		font-family: "Roboto Mono", monospace !important
+		vertical-align: baseline !important
+		font-size: 14px !important
+		font-weight: bold !important
+		padding: 0px 4px !important
+
+.ui-dialog
+	background: #f7f7f7 !important
+	padding: 0.5em
+
+.ui-dialog-content
+	position: relative
+	float: right
+	width: 100%
+
+	$toc-margin: 15px
+	$header-clearance: $header-height + 20px
+
+	* + h2, * + h3, * + h4, * + h5, * + h6
+		margin-top: 30px
+
+	h1, h2, h3, h4, h5, h6
+		line-height: normal
+		font-weight: 500
+		margin-bottom: 30px
+		padding-bottom: 10px
+
+		// Make sure anchor links aren't hidden by the header
+		&:before
+			display: block
+			content: " "
+			margin-top: -$header-clearance
+			height: $header-clearance
+			visibility: hidden
+
+	h1,h2
+		border-bottom: 1px solid #cccccc
+		
+	h1
+		font-size: 32px
+		padding-right: 60px
+
+	h2
+		font-size: 28px
+
+	h3
+		font-size: 24px
+		font-weight: 300
+		margin-bottom: 5px
+
+	h4
+		font-size: 20px
+		margin-bottom: 0px
+
+	h5, h6
+		font-size: 16px
+		font-weight: 500
+
+	p
+		font-size: 16px
+		font-weight: 300
+		line-height: 1.75em
+
+	p + p
+		margin-top: 10px
+
+	code
+		display: inline-block
+		box-sizing: border-box
+		background-color: $light-grey
+		color: $dark-grey
+		font-family: $mono-font
+		vertical-align: baseline
+		font-size: 14px
+		font-weight: bold
+		padding: 2px 4px
+
+	a code
+		color: $blue
+		text-decoration: underline
+
+	pre .pi, pre .s
+		margin: 0
+		padding: 0
+
+	.highlight code span, code, pre code
+		font-family: "Roboto Mono", monospace
+
+	code, pre code
+		color: #303030
+
+	pre code
+		padding: 0
+
+	pre
+		background-color: #f7f7f7
+		display: block
+		margin: 20px 0
+		padding: 15px
+		position: relative
+		overflow-x: auto
+
+	h1 code, h2 code, h3 code, h4 code, h5 code, h6 code
+		font-family: inherit
+		font-size: inherit
+		background-color: transparent
+
+	.includecode
+		table-layout: fixed
+
+	.includecode, .includecode th, .includecode td
+		padding: 0 !important
+
+	.includecode th
+		text-align: right !important
+		padding: 10px !important
+
+	.includecode th a, .includecode th a code
+		color: white !important
+		background-color: transparent !important
+
+	.includecode pre
+		margin: 0 !important
+
+	ul li
+		list-style: disc
+
+	ol li
+		list-style: decimal
+
+	ul, ol
+		margin: 20px 0
+		padding-left: 30px
+		font-weight: 300
+
+	ul ul, ol ol, ul ol, ol ul
+		margin: 0.75em 0
+
+	li
+		margin-bottom: 0.75em
+		font-size: 16px
+		line-height: 1.75em
+
+	table
+		width: 100%
+		border: 1px solid #ccc
+		border-spacing: 0
+		margin-top: 30px
+		margin-bottom: 30px
+
+	thead, tr:nth-child(even)
+		background-color: $light-grey
+
+	thead
+		background-color: #555
+		color: white
+
+	th, td
+		padding: 8px
+		text-align: left
+		margin: 0
+
+	th
+		font-weight: normal
+
+	td
+		font-size: 0.85em
+
+	#editPageButton
+		position: absolute
+		top: -25px
+		right: 5px
+		width: 50px
+		height: 50px
+		line-height: 50px
+		border-radius: 50%
+		white-space: nowrap
+		text-indent: 50px
+		overflow: hidden
+		background: $blue url(/images/icon-pencil.svg) no-repeat
+		background-position: 12px 10px
+		background-size: 29px 29px
+
+	#markdown-toc
+		margin-bottom: 20px
+
+		ul, li
+			list-style: disc
+			color: $blue
+
+		ul
+			padding: 0 15px
+			margin: 0
+
+		li
+			padding: 0
+			line-height: 1.5em
+			margin-bottom: 0
+
+		a
+			position: relative
+			color: $blue
+			font-weight: 700
+
+	img
+		max-width: 100%
+
+	a
+		//font-weight: 700
+		text-decoration: underline
+
+//	a:visited
+//		color: blueviolet
+
+	a.button
+		border-radius: 2px
+		text-decoration: none
+		
+		&:visited
+			color: white
+
+	a.issue
+		margin-left: 0px
+
+.ui-dialog-buttonpane
+	background: #f7f7f7 !important
+
 // Tabs
 .ui-widget-header
 	background: transparent !important
@@ -1302,19 +1580,27 @@ $feature-box-div-margin-bottom: 40px
 		padding: 0px !important
 		list-style: none !important
 		margin-bottom: 0px !important
-		margin-left: 1px !important
+		margin-left: 4px !important
+
+.ui-tabs-panel
+	ul li
+		list-style: disc !important
+
+	ol li
+		list-style: decimal !important
 
 .ui-widget-content
 	border: 0px !important
 
-.ui-widget-content
 	table
 		margin: 0px !important
 
 .ui-tabs .ui-tabs-panel
-	padding: 0px !important
 	border: 1px solid #ccc !important
 
+.ui-tabs-anchor
+	text-decoration: none !important
+
 // Talk to us
 #talkToUs
 	h3, h4

case-studies/index.html

@@ -6,94 +6,94 @@ cid: caseStudies
 ---
 
 <section id="hero" class="light-text">
-	<h1>Kubernetes User Case Studies</h1>
-	<h5>A collection of users running Kubernetes in production.</h5>
+    <h1>Kubernetes User Case Studies</h1>
+    <h5>A collection of users running Kubernetes in production.</h5>
 </section>
 
 <section id="mainContent">
-	<main>
-		<div class="content">
-			<div class="case-studies">
-				<div class="case-study">
-					<img src="/images/case_studies/pearson.png" alt="Pearson">
-					<p class="quote">"We chose Kubernetes because of its flexibility, ease of management and the way it improves our engineers' productivity."</p>
-					<!--<p class="attrib">— Chris Jackson, Director for Cloud Product Engineering, Pearson</p>-->
-					<a href="./pearson/">Read about Pearson</a>
-				</div>
-				<div class="case-study">
-					<img src="/images/case_studies/wikimedia.png" alt="Wikimedia">
-					<p class="quote">"With Kubernetes, we're simplifying our environment and making it easier for developers to build the tools that make wikis run better."</p>
-					<!--<p class="attrib">— Yuvi Panda, Operations Engineer, Wikimedia Foundation</p>-->
-					<a href="./wikimedia/">Read about Wikimedia</a>
-				</div>
-				<div class="case-study">
-					<img src="/images/case_studies/ebay.png" alt="eBay">
-					<p class="quote">Inside eBay's shift to Kubernetes and containers atop OpenStack</p>
-					<a href="http://www.nextplatform.com/2015/11/12/inside-ebays-shift-to-kubernetes-and-containers-atop-openstack/">Read about eBay</a>
-				</div>
-				<div class="case-study">
-					<img src="/images/case_studies/box.png" alt="box">
-					<p class="quote">Kubernetes at Box: Microservices at Maximum Velocity</p>
-					<a href="https://blog.box.com/blog/kubernetes-box-microservices-maximum-velocity/">Read about Box</a>
-				</div>
-			</div>
-		</div>
-	</main>
+    <main>
+        <div class="content">
+            <div class="case-studies">
+                <div class="case-study">
+                    <img src="/images/case_studies/pearson.png" alt="Pearson">
+                    <p class="quote">"We chose Kubernetes because of its flexibility, ease of management and the way it improves our engineers' productivity."</p>
+                    <!--<p class="attrib">— Chris Jackson, Director for Cloud Product Engineering, Pearson</p>-->
+                    <a href="./pearson/">Read about Pearson</a>
+                </div>
+                <div class="case-study">
+                    <img src="/images/case_studies/wikimedia.png" alt="Wikimedia">
+                    <p class="quote">"With Kubernetes, we're simplifying our environment and making it easier for developers to build the tools that make wikis run better."</p>
+                    <!--<p class="attrib">— Yuvi Panda, Operations Engineer, Wikimedia Foundation</p>-->
+                    <a href="./wikimedia/">Read about Wikimedia</a>
+                </div>
+                <div class="case-study">
+                    <img src="/images/case_studies/ebay.png" alt="eBay">
+                    <p class="quote">Inside eBay's shift to Kubernetes and containers atop OpenStack</p>
+                    <a href="http://www.nextplatform.com/2015/11/12/inside-ebays-shift-to-kubernetes-and-containers-atop-openstack/">Read about eBay</a>
+                </div>
+                <div class="case-study">
+                    <img src="/images/case_studies/box.png" alt="box">
+                    <p class="quote">Kubernetes at Box: Microservices at Maximum Velocity</p>
+                    <a href="https://blog.box.com/blog/kubernetes-box-microservices-maximum-velocity/">Read about Box</a>
+                </div>
+            </div>
+        </div>
+    </main>
 </section>
 
 <section id="video">
-	<main>
-		<!--<div>-->
-			<!--<h3>"I don't want to deploy software the old way ever again"</h3>-->
-			<!--<p class="attrib">— Dylan Carney, Lead Software Engineer, Zulily</p>-->
-			<!--<img src="/images/case_studies/zulily.png" id="zulilyLogo" alt="zulily">-->
-		<!--</div>-->
-		<!--<div><button onclick="kub.showVideo()"><img src="/images/case_studies/video_thumb.jpg" alt="Zulily video"><h6>Kubernetes at zulily</h6></button></div>-->
-		<div>
-			<!--<h3>SAP</h3>-->
-			<h3>SAP's OpenStack, running on Kubernetes in production</h3>
-			<img src="/images/case_studies/sap_small.png" id="zulilyLogo" alt="SAP">
-		</div>
-		<div><button onclick="kub.showVideo()"><img src="/images/case_studies/video_thumb1.png" alt="SAP video"><h6>Kubernetes at SAP</h6></button></div>
-	</main>
+    <main>
+        <!--<div>-->
+            <!--<h3>"I don't want to deploy software the old way ever again"</h3>-->
+            <!--<p class="attrib">— Dylan Carney, Lead Software Engineer, Zulily</p>-->
+            <!--<img src="/images/case_studies/zulily.png" id="zulilyLogo" alt="zulily">-->
+        <!--</div>-->
+        <!--<div><button onclick="kub.showVideo()"><img src="/images/case_studies/video_thumb.jpg" alt="Zulily video"><h6>Kubernetes at zulily</h6></button></div>-->
+        <div>
+            <!--<h3>SAP</h3>-->
+            <h3>SAP's OpenStack, running on Kubernetes in production</h3>
+            <img src="/images/case_studies/sap_small.png" id="zulilyLogo" alt="SAP">
+        </div>
+        <div><button onclick="kub.showVideo()"><img src="/images/case_studies/video_thumb1.png" alt="SAP video"><h6>Kubernetes at SAP</h6></button></div>
+    </main>
 </section>
 
 <section id="users">
-	<main>
-		<h3>Kubernetes Users</h3>
-		<div id="usersGrid">
-			<a target="_blank" href="https://www.youtube.com/watch?v=P5qfyv_zGcU"><img src="/images/case_studies/nyt.png" alt="New York Times"></a>
-			<a target="_blank" href="https://openai.com/blog/infrastructure-for-deep-learning"><img src="/images/case_studies/openai.png" alt="OpenAI"></a>
-			<a target="_blank" href="http://blogs.wsj.com/cio/2016/02/24/big-changes-in-goldmans-software-emerge-from-small-containers/"><img src="/images/case_studies/gs.png" alt="Goldman Sachs"></a>
-			<a target="_blank" href="https://youtu.be/4gyeixJLabo"><img src="/images/case_studies/sap.png" alt="SAP"></a>
-			<a target="_blank" href="http://www.nextplatform.com/2016/05/24/samsung-experts-put-kubernetes-paces/"><img src="/images/case_studies/sds.png" alt="Samsung SDS"></a>
-			<a target="_blank" href="http://thenewstack.io/wepay-kubernetes-changed-business/"><img src="/images/case_studies/wepay.png" alt="WePay"></a>
-			<a target="_blank" href="https://www.youtube.com/watch?v=5378N5iLb2Q"><img src="/images/case_studies/soundcloud.png" alt="SoundCloud"></a>
-			<a target="_blank" href="https://www.youtube.com/watch?v=F3iMkz_NSvU"><img src="/images/case_studies/homeoffice.png" alt="UK Home Office"></a>
-			<a target="_blank" href="http://searchitoperations.techtarget.com/news/450297178/Tech-firms-roll-out-Kubernetes-in-production"><img src="/images/case_studies/concur.png" alt="Concur"></a>
-			<a target="_blank" href="http://www.nextplatform.com/2015/08/04/amadeus-takes-off-with-containers-and-clouds/"><img src="/images/case_studies/amadeus.png" alt="Amadeus"></a>
-			<a target="_blank" href="http://superuser.openstack.org/articles/how-ancestry-com-s-open-source-strategy-combines-kubernetes-and-openstack"><img src="/images/case_studies/ancestry.png" alt="Ancestry.com"></a>
-			<a target="_blank" href="https://cloud.google.com/customers/ccp-games/"><img src="/images/case_studies/ccp.png" alt="CCP Games"></a>
-			<a target="_blank" href="https://www.openstack.org/videos/video/running-kubernetes-on-openstack-at-liveperson"><img src="/images/case_studies/liveperson.png" alt="LivePerson"></a>
-			<a target="_blank" href="https://youtu.be/YkOY7DgXKyw"><img src="/images/case_studies/monzo_logo.png" alt="monzo"></a>
-			<a target="_blank" href="https://blog.box.com/blog/kubernetes-box-microservices-maximum-velocity/"><img src="/images/case_studies/box_logo.png" alt="Box"></a>
-			<a target="_blank" href="https://cloudplatform.googleblog.com/2016/09/bringing-Pokemon-GO-to-life-on-Google-Cloud.html"><img src="/images/case_studies/pokemon_go_logo.png" alt="Pokemon GO"></a>
-			<a target="_blank" href="http://blog.kubernetes.io/2016/10/kubernetes-and-openstack-at-yahoo-japan.html"><img src="/images/case_studies/yahooJapan_logo.png" alt="Yahoo! Japan"></a>
-			<a target="_blank" href="https://cloud.google.com/customers/philips/"><img src="/images/case_studies/philips_logo.png" alt="Philips"></a>
-			<a target="_blank" href="https://youtu.be/EC_ZRLsw58M"><img src="/images/case_studies/buffer_logo.png" alt="buffer"></a>
-			<a target="_blank" href="https://youtu.be/lmeFkH-rHII"><img src="/images/case_studies/comcast_logo.png" alt="Comcast"></a>
-			<a href="./wikimedia/"><img src="/images/case_studies/wikimedia_logo.png" alt="Wikimedia"></a>
-			<a href="./pearson/"><img src="/images/case_studies/pearson_logo.png" alt="Pearson"></a>
-			<a target="_blank" href="#" onclick="event.preventDefault(); kub.showVideo()"><img src="/images/case_studies/zulily_logo.png" alt="zulily"></a>
-			<a target="_blank" href="http://www.nextplatform.com/2015/11/12/inside-ebays-shift-to-kubernetes-and-containers-atop-openstack/"><img src="/images/case_studies/ebay_logo.png" alt="Ebay"></a>
-			<a target="_blank" href="https://docs.google.com/a/google.com/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform" class="tell-your-story"><img src="/images/case_studies/story.png" alt="Tell your story"></a>
-		</div>
-	</main>
+    <main>
+        <h3>Kubernetes Users</h3>
+        <div id="usersGrid">
+            <a target="_blank" href="https://www.youtube.com/watch?v=P5qfyv_zGcU"><img src="/images/case_studies/nyt.png" alt="New York Times"></a>
+            <a target="_blank" href="https://openai.com/blog/infrastructure-for-deep-learning"><img src="/images/case_studies/openai.png" alt="OpenAI"></a>
+            <a target="_blank" href="http://blogs.wsj.com/cio/2016/02/24/big-changes-in-goldmans-software-emerge-from-small-containers/"><img src="/images/case_studies/gs.png" alt="Goldman Sachs"></a>
+            <a target="_blank" href="https://youtu.be/4gyeixJLabo"><img src="/images/case_studies/sap.png" alt="SAP"></a>
+            <a target="_blank" href="http://www.nextplatform.com/2016/05/24/samsung-experts-put-kubernetes-paces/"><img src="/images/case_studies/sds.png" alt="Samsung SDS"></a>
+            <a target="_blank" href="http://thenewstack.io/wepay-kubernetes-changed-business/"><img src="/images/case_studies/wepay.png" alt="WePay"></a>
+            <a target="_blank" href="https://www.youtube.com/watch?v=5378N5iLb2Q"><img src="/images/case_studies/soundcloud.png" alt="SoundCloud"></a>
+            <a target="_blank" href="https://www.youtube.com/watch?v=F3iMkz_NSvU"><img src="/images/case_studies/homeoffice.png" alt="UK Home Office"></a>
+            <a target="_blank" href="http://searchitoperations.techtarget.com/news/450297178/Tech-firms-roll-out-Kubernetes-in-production"><img src="/images/case_studies/concur.png" alt="Concur"></a>
+            <a target="_blank" href="http://www.nextplatform.com/2015/08/04/amadeus-takes-off-with-containers-and-clouds/"><img src="/images/case_studies/amadeus.png" alt="Amadeus"></a>
+            <a target="_blank" href="http://superuser.openstack.org/articles/how-ancestry-com-s-open-source-strategy-combines-kubernetes-and-openstack"><img src="/images/case_studies/ancestry.png" alt="Ancestry.com"></a>
+            <a target="_blank" href="https://cloud.google.com/customers/ccp-games/"><img src="/images/case_studies/ccp.png" alt="CCP Games"></a>
+            <a target="_blank" href="https://www.openstack.org/videos/video/running-kubernetes-on-openstack-at-liveperson"><img src="/images/case_studies/liveperson.png" alt="LivePerson"></a>
+            <a target="_blank" href="https://youtu.be/YkOY7DgXKyw"><img src="/images/case_studies/monzo_logo.png" alt="monzo"></a>
+            <a target="_blank" href="https://blog.box.com/blog/kubernetes-box-microservices-maximum-velocity/"><img src="/images/case_studies/box_logo.png" alt="Box"></a>
+            <a target="_blank" href="https://cloudplatform.googleblog.com/2016/09/bringing-Pokemon-GO-to-life-on-Google-Cloud.html"><img src="/images/case_studies/pokemon_go_logo.png" alt="Pokemon GO"></a>
+            <a target="_blank" href="http://blog.kubernetes.io/2016/10/kubernetes-and-openstack-at-yahoo-japan.html"><img src="/images/case_studies/yahooJapan_logo.png" alt="Yahoo! Japan"></a>
+            <a target="_blank" href="https://cloud.google.com/customers/philips/"><img src="/images/case_studies/philips_logo.png" alt="Philips"></a>
+            <a target="_blank" href="https://youtu.be/EC_ZRLsw58M"><img src="/images/case_studies/buffer_logo.png" alt="buffer"></a>
+            <a target="_blank" href="https://youtu.be/lmeFkH-rHII"><img src="/images/case_studies/comcast_logo.png" alt="Comcast"></a>
+            <a href="./wikimedia/"><img src="/images/case_studies/wikimedia_logo.png" alt="Wikimedia"></a>
+            <a href="./pearson/"><img src="/images/case_studies/pearson_logo.png" alt="Pearson"></a>
+            <a target="_blank" href="#" onclick="event.preventDefault(); kub.showVideo()"><img src="/images/case_studies/zulily_logo.png" alt="zulily"></a>
+            <a target="_blank" href="http://www.nextplatform.com/2015/11/12/inside-ebays-shift-to-kubernetes-and-containers-atop-openstack/"><img src="/images/case_studies/ebay_logo.png" alt="Ebay"></a>
+            <a target="_blank" href="https://docs.google.com/a/google.com/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform" class="tell-your-story"><img src="/images/case_studies/story.png" alt="Tell your story"></a>
+        </div>
+    </main>
 </section>
 
 
 <div id="videoPlayer">
-	<!--<iframe data-url="https://www.youtube.com/watch?v=B0_5Nms8sD0" frameborder="0" allowfullscreen></iframe>-->
-	<iframe data-url="https://www.youtube.com/embed/4gyeixJLabo?autoplay=1" frameborder="0" allowfullscreen></iframe>
-	<button id="closeButton"></button>
+    <!--<iframe data-url="https://www.youtube.com/watch?v=B0_5Nms8sD0" frameborder="0" allowfullscreen></iframe>-->
+    <iframe data-url="https://www.youtube.com/embed/4gyeixJLabo?autoplay=1" frameborder="0" allowfullscreen="true"></iframe>
+    <button id="closeButton"></button>
 </div>

case-studies/pearson.html

@@ -6,76 +6,76 @@ cid: caseStudies
 ---
 
 <section id="hero" class="light-text">
-	<h1> Pearson Case Study</h1>
+    <h1> Pearson Case Study</h1>
 </section>
 
 <section id="mainContent">
-	<main>
-		<div class="content">
-			<h3 id="caseStudyTitle">Using Kubernetes to reinvent the world's largest educational company</h3>
-			<p>
-				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.			</p>
-			<div class="feature">
-				<img src="/images/case_studies/pearson.png" alt="Pearson">
-				<p class="quote">
-					"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."				</p>
-				<p class="attrib">— Chris Jackson, Director for Cloud Product Engineering, Pearson</p>
-			</div>
-		</div>
-	</main>
+    <main>
+        <div class="content">
+            <h3 id="caseStudyTitle">Using Kubernetes to reinvent the world's largest educational company</h3>
+            <p>
+                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.            </p>
+            <div class="feature">
+                <img src="/images/case_studies/pearson.png" alt="Pearson">
+                <p class="quote">
+                    "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."                </p>
+                <p class="attrib">— Chris Jackson, Director for Cloud Product Engineering, Pearson</p>
+            </div>
+        </div>
+    </main>
 </section>
 
 <section class="bullets">
-	<main>
-		<div class="content">
-			<div class="bullet">
-				<h4>Challenges:</h4>
-				<ul>
-					<li>Pearson had difficulty in scaling and adapting to the growing online audience. They wanted to build and deliver content primarily over the web.</li>
-				</ul>
-			</div>
-			<div class="bullet">
-				<h4>Why Kubernetes:</h4>
-				<ul>
-					<li>Kubernetes will allow Pearson's teams to develop their apps in a consistent manner, saving time and minimizing complexity.</li>
-				</ul>
-			</div>
-			<div class="bullet">
-				<h4>Approach:</h4>
-				<ul>
-					<li>Build a centralized platform for use across the entire enterprise</li>
-					<li>Use container technology as the core of the platform</li>
-					<li>Deploy Kubernetes to manage the platform</li>
-				</ul>
-			</div>
-			<div class="bullet">
-				<h4>Results:</h4>
-				<ul>
-					<li>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.</li>
-				</ul>
-			</div>
-		</div>
-	</main>
+    <main>
+        <div class="content">
+            <div class="bullet">
+                <h4>Challenges:</h4>
+                <ul>
+                    <li>Pearson had difficulty in scaling and adapting to the growing online audience. They wanted to build and deliver content primarily over the web.</li>
+                </ul>
+            </div>
+            <div class="bullet">
+                <h4>Why Kubernetes:</h4>
+                <ul>
+                    <li>Kubernetes will allow Pearson's teams to develop their apps in a consistent manner, saving time and minimizing complexity.</li>
+                </ul>
+            </div>
+            <div class="bullet">
+                <h4>Approach:</h4>
+                <ul>
+                    <li>Build a centralized platform for use across the entire enterprise</li>
+                    <li>Use container technology as the core of the platform</li>
+                    <li>Deploy Kubernetes to manage the platform</li>
+                </ul>
+            </div>
+            <div class="bullet">
+                <h4>Results:</h4>
+                <ul>
+                    <li>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.</li>
+                </ul>
+            </div>
+        </div>
+    </main>
 </section>
 
 <section class="details">
-	<main>
-		<div class="content">
-			<h4>Kubernetes powers a comprehensive developer experience</h4>
-			<p>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."</p>
-			<p>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."</p>
-			<p>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.</p>
-		</div>
-	</main>
+    <main>
+        <div class="content">
+            <h4>Kubernetes powers a comprehensive developer experience</h4>
+            <p>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."</p>
+            <p>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."</p>
+            <p>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.</p>
+        </div>
+    </main>
 </section>
 
 <section class="details">
-	<main>
-		<div class="content">
-			<h4>Encouraging experimentation, saving engineers time</h4>
-			<p>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.</p>
-			<p>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.</p>
-			<p>"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.</p>
-		</div>
-	</main>
+    <main>
+        <div class="content">
+            <h4>Encouraging experimentation, saving engineers time</h4>
+            <p>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.</p>
+            <p>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.</p>
+            <p>"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.</p>
+        </div>
+    </main>
 </section>

case-studies/wikimedia.html

@@ -6,91 +6,91 @@ cid: caseStudies
 ---
 
 <section id="hero" class="light-text">
-	<h1> Wikimedia Case Study</h1>
+    <h1> Wikimedia Case Study</h1>
 </section>
 
 <section id="mainContent">
-	<main>
-		<div class="content">
-			<h3 id="caseStudyTitle">Using Kubernetes to Build Tools to Improve the World's Wikis</h3>
-			<p>
-				The non-profit Wikimedia Foundation operates some of the largest collaboratively edited reference projects in the world, including Wikipedia. To help users maintain and use wikis, it runs Wikimedia Tool Labs, a hosting environment for community developers working on tools and bots to help editors and other volunteers do their work, including reducing vandalism. The community around Wikimedia Tool Labs began forming nearly 10 years ago.
-			</p>
-			<div class="feature">
-				<img src="/images/case_studies/wikimedia.png" alt="Wikimedia">
-				<p class="quote">
-					"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."
-				</p>
-				<p class="attrib">— Yuvi Panda, operations engineer at Wikimedia Foundation and Wikimedia Tool Labs</p>
-			</div>
-		</div>
-	</main>
+    <main>
+        <div class="content">
+            <h3 id="caseStudyTitle">Using Kubernetes to Build Tools to Improve the World's Wikis</h3>
+            <p>
+                The non-profit Wikimedia Foundation operates some of the largest collaboratively edited reference projects in the world, including Wikipedia. To help users maintain and use wikis, it runs Wikimedia Tool Labs, a hosting environment for community developers working on tools and bots to help editors and other volunteers do their work, including reducing vandalism. The community around Wikimedia Tool Labs began forming nearly 10 years ago.
+            </p>
+            <div class="feature">
+                <img src="/images/case_studies/wikimedia.png" alt="Wikimedia">
+                <p class="quote">
+                    "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."
+                </p>
+                <p class="attrib">— Yuvi Panda, operations engineer at Wikimedia Foundation and Wikimedia Tool Labs</p>
+            </div>
+        </div>
+    </main>
 </section>
 
 <section class="bullets">
-	<main>
-		<div class="content">
-			<div class="bullet">
-				<h4>Challenges:</h4>
-				<ul>
-					<li>Simplify a complex, difficult-to-manage infrastructure</li>
-					<li>Allow developers to continue writing tools and bots using existing techniques</li>
-				</ul>
-			</div>
-			<div class="bullet">
-				<h4>Why Kubernetes:</h4>
-				<ul>
-					<li>Wikimedia Tool Labs chose Kubernetes because it can mimic existing workflows, while reducing complexity</li>
-				</ul>
-			</div>
-			<div class="bullet">
-				<h4>Approach:</h4>
-				<ul>
-					<li>Migrate old systems and a complex infrastructure to Kubernetes</li>
-				</ul>
-			</div>
-			<div class="bullet">
-				<h4>Results:</h4>
-				<ul>
-					<li>20 percent of web tools that account for more than 40 percent of web traffic now run on Kubernetes</li>
-					<li>A 25-node cluster that keeps up with each new Kubernetes release</li>
-					<li>Thousands of lines of old code have been deleted, thanks to Kubernetes</li>
-				</ul>
-			</div>
-		</div>
-	</main>
+    <main>
+        <div class="content">
+            <div class="bullet">
+                <h4>Challenges:</h4>
+                <ul>
+                    <li>Simplify a complex, difficult-to-manage infrastructure</li>
+                    <li>Allow developers to continue writing tools and bots using existing techniques</li>
+                </ul>
+            </div>
+            <div class="bullet">
+                <h4>Why Kubernetes:</h4>
+                <ul>
+                    <li>Wikimedia Tool Labs chose Kubernetes because it can mimic existing workflows, while reducing complexity</li>
+                </ul>
+            </div>
+            <div class="bullet">
+                <h4>Approach:</h4>
+                <ul>
+                    <li>Migrate old systems and a complex infrastructure to Kubernetes</li>
+                </ul>
+            </div>
+            <div class="bullet">
+                <h4>Results:</h4>
+                <ul>
+                    <li>20 percent of web tools that account for more than 40 percent of web traffic now run on Kubernetes</li>
+                    <li>A 25-node cluster that keeps up with each new Kubernetes release</li>
+                    <li>Thousands of lines of old code have been deleted, thanks to Kubernetes</li>
+                </ul>
+            </div>
+        </div>
+    </main>
 </section>
 
 <section class="details">
-	<main>
-		<div class="content">
-			<h4>Using Kubernetes to provide tools for maintaining wikis</h4>
-			<p>
-				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."
-			</p>
-			<p>
-				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.
-			</p>
-			<p>
-				"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.
-			</p>
-		</div>
-	</main>
+    <main>
+        <div class="content">
+            <h4>Using Kubernetes to provide tools for maintaining wikis</h4>
+            <p>
+                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."
+            </p>
+            <p>
+                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.
+            </p>
+            <p>
+                "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.
+            </p>
+        </div>
+    </main>
 </section>
 
 <section class="details">
-	<main>
-		<div class="content">
-			<h4>Simplifying infrastructure and keeping wikis running better</h4>
-			<p>
-				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.
-			</p>
-			<p>
-				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.
-			</p>
-			<p>
-				"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.
-			</p>
-		</div>
-	</main>
+    <main>
+        <div class="content">
+            <h4>Simplifying infrastructure and keeping wikis running better</h4>
+            <p>
+                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.
+            </p>
+            <p>
+                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.
+            </p>
+            <p>
+                "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.
+            </p>
+        </div>
+    </main>
 </section>

cn/README.md

@@ -0,0 +1,18 @@
+## 如何参与 Kubernetes 文档汉化工作
+
+我们非常欢迎，非常希望您参与 Kubernetes 文档汉化做出贡献。
+
+您可以单击屏幕右上角的 **Fork** 按钮，在您的 Github 账户中创建一外名为 *fork* 的存储库副本。在您的分支中进行更改，当您准备好将这些更改发送给我们时，请转到您的仓库创建新的 pull 请求，让我们知道这一点。
+
+关于更多的贡献信息，请参阅:
+
+* [贡献于 Kubernetes 文档](http://kubernetes.io/editdocs/)
+* [创建文档拉取请求](http://kubernetes.io/docs/contribute/create-pull-request/)
+* [写一个新的话题](http://kubernetes.io/docs/contribute/write-new-topic/)
+* [暂停您的文档更改](http://kubernetes.io/docs/contribute/stage-documentation-changes/)
+* [更用页面模板](http://kubernetes.io/docs/contribute/page-templates/)
+* [文档样式指南](http://kubernetes.io/docs/contribute/style-guide/)
+
+## 谢谢您!
+
+Kubernetes 在社区参与中茁壮成长，我们非常感谢您对我们的网站和文档的贡献！

cn/_includes/user-guide-content-moved.md

@@ -0,0 +1,2 @@
+Kubernetes 文档的 [用户指南](/docs/user-guide/) 部分中的主题将被移动到 [任务](/docs/tasks/)、[教程](/docs/tutorials/)和
+[概念](/docs/concepts) 部分。 本主题的内容已转移到:

cn/docs/concepts/overview/what-is-kubernetes.md

@@ -0,0 +1,119 @@
+---
+assignees:
+- k8s-merge-robot
+
+title: 认识 Kubernetes?
+---
+
+Kubernetes 是一个 [开源的容器调度平台，它可以自动化应用容器的部署、扩展和操作](http://www.slideshare.net/BrianGrant11/wso2con-us-2015-kubernetes-a-platform-for-automating-deployment-scaling-and-operations) 可以跨主机集群, 提供以容器为中心的基础架构。
+
+使用 Kubernetes, 您可以快速高效地响应客户需求:
+
+ - 快速、可预测地部署您的应用程序
+ - 拥有即时扩展应用程序的能力
+ - 不影响现有业务的情况下，无缝地发布新功能。
+ - 优化您的硬件资源，降低您的拥有成本
+
+我们的目标是构建一个软件和工具的生态系统，以减轻您在公共云或私有云运行应用程序的负担。
+
+#### Kubernetes 具有如下特点:
+
+* **便携性**: 无论公有云、私有云、混合云还是多云架构都全面支持
+* **可扩展**: 它是模块化、可插拔、可挂载、可组合的，支持各种形式的扩展
+* **自修复**: 它可以自保持应用状态、可自重启、自复制、自缩放的，通过声明式语法提供了强大的自修复能力
+
+Kubernetes 项目由 Google 公司在 2014 年启动。Kubernetes 建立在 [Google 公司超过十余年的运维经验基础之上，Google 所有的应用都运行在容器上](https://research.google.com/pubs/pub43438.html), 再与社区中最好的想法和实践相结合，也许它是最受欢迎的容器平台。
+
+##### 准备好 [开始](/docs/getting-started-guides/)?
+
+## 为什么是容器?
+
+查看此文，可以了解为什么您要使用容器 [容器](http://aucouranton.com/2014/06/13/linux-containers-parallels-lxc-openvz-docker-and-more/)?
+
+![为什么是容器?](/images/docs/why_containers.svg)
+
+*传统* 部署应用程序的方式，一般是使用操作系统自带的包管理器在主机上安装应用依赖，之后再安装应用程序。这无疑将应用程序的可执行文件、应用的配置、应用依赖库和应用的生命周期与宿主机操作系统进行了紧耦合。在此情境下，可以通过构建不可改变的虚拟机镜像版本，通过镜像版本实现可预测的发布和回滚，但是虚拟机实在是太重量级了，且镜像体积太庞大，便捷性差。
+
+*新方式* 是基于操作系统级虚拟化而不是硬件级虚拟化方法来部署容器。容器之间彼此隔离并与主机隔离：它们具有自己的文件系统，不能看到彼此的进程，并且它们所使用的计算资源是可以被限制的。它们比虚拟机更容易构建，并且因为它们与底层基础架构和主机文件系统隔离，所以它们可以跨云和操作系统快速分发。
+
+由于容器体积小且启动快，因此可以在每个容器镜像中打包一个应用程序。这种一对一的应用镜像关系拥有很多好处。使用容器，不需要与外部的基础架构环境绑定, 因为每一个应用程序不需要外部依赖，更不需要与外部的基础架构环境依赖。完美解决了从开发到生产环境的一致性问题。
+
+类似地，容器比虚拟机更加透明，这有助于监测和管理。真实的情况是，容器进程的生命周期由基础设施管理，而容器内的进程对外是隐藏的。最后，每个应用程序用容器封装，管理容器部署就等同于管理应用程序部署。
+
+容器好处摘要:
+
+* **敏捷的应用程序创建和部署**:
+    与虚拟机镜像相比，容器镜像更容易创建，提升了硬件的使用效率。
+* **持续开发、集成和部署**:
+    提供可靠与频繁的容器镜像构建和部署，可以很方便及快速的回滚 (由于镜像不可变性).
+* **关注开发与运维的分离**:
+    在构建/发布时创建应用程序容器镜像，从而将应用程序与基础架构分离。
+* **开发、测试和生产环境的一致性**:
+    在笔记本电脑上运行与云中一样。
+* **云和操作系统的可移植性**:
+    可运行在 Ubuntu, RHEL, CoreOS, 内部部署, Google 容器引擎和其他任何地方。
+* **以应用为中心的管理**:
+    提升了操作系统的抽象级别，以便在使用逻辑资源的操作系统上运行应用程序。
+* **松耦合、分布式、弹性伸缩 [微服务](http://martinfowler.com/articles/microservices.html)**:
+    应用程序被分成更小，更独立的部分，可以动态部署和管理 - 而不是巨型单体应用运行在专用的大型机。
+* **资源隔离**:
+    通过对应用进行资源隔离，可以很容易的预测应用程序性能。
+* **资源利用**:
+    高效率和高密度。
+
+#### 为什么我们需要 Kubernetes，它能做什么?
+
+最基础的，Kubernetes 可以在物理或虚拟机集群上调度和运行应用程序容器。然而，Kubernetes 还允许开发人员从物理和虚拟机'脱离'，从以**主机为中心**的基础架构转移到以**容器为中心**的基础架构，这样可以提供容器固有的全部优点和益处。Kubernetes 提供了基础设施来构建一个真正以**容器为中心**的开发环境。
+
+Kubernetes 满足了生产中运行应用程序的许多常见的需求，例如：
+
+* [Pod](/docs/user-guide/pods/) 提供复合应用并保留一个应用一个容器的容器模型,
+* [挂载外部存储](/docs/user-guide/volumes/),
+* [Secret管理](/docs/user-guide/secrets/),
+* [应用健康检查](/docs/user-guide/production-pods/#liveness-and-readiness-probes-aka-health-checks),
+* [副本应用实例](/docs/user-guide/replication-controller/),
+* [横向自动扩缩容](/docs/user-guide/horizontal-pod-autoscaling/),
+* [服务发现](/docs/user-guide/connecting-applications/),
+* [负载均衡](/docs/user-guide/services/),
+* [滚动更新](/docs/user-guide/update-demo/),
+* [资源监测](/docs/user-guide/monitoring/),
+* [日志采集和存储](/docs/user-guide/logging/overview/),
+* [支持自检和调试](/docs/user-guide/introspection-and-debugging/),
+* [认证和鉴权](/docs/admin/authorization/).
+
+这提供了平台即服务 (PAAS) 的简单性以及基础架构即服务 (IAAS) 的灵活性，并促进跨基础设施供应商的可移植性。
+
+有关详细信息，请参阅 [用户指南](/docs/user-guide/).
+
+#### 为什么 Kubernetes 是一个平台?
+
+Kubernetes 提供了很多的功能，总会有新的场景会受益于新特性。它可以简化应用程序的工作流，加快开发速度。被大家认可的应用编排通常需要有较强的自动化能力。这就是为什么 Kubernetes 被设计作为构建组件和工具的生态系统平台，以便更轻松地部署、扩展和管理应用程序。
+
+[Label](/docs/user-guide/labels/) 允许用户按照自己的方式组织管理对应的资源。 [注解](/docs/user-guide/annotations/) 使用户能够以自定义的描述信息来修饰资源，以适用于自己的工作流，并为管理工具提供检查点状态的简单方法。
+
+此外，[Kubernetes 控制面](/docs/admin/cluster-components) 是构建在相同的 [APIs](/docs/api/) 上面，开发员人和用户都可以用。用户可以编写自己的控制器， [调度器](https://git.k8s.io/community/contributors/devel/scheduler.md)等等，如果这么做，根据新加的[自定义 API](https://git.k8s.io/community/contributors/design-proposals/extending-api.md) ，可以扩展当前的通用 [CLI 命令行工具](/docs/user-guide/kubectl-overview/)。
+
+这种 [设计](https://git.k8s.io/community/contributors/design-proposals/principles.md) 使得许多其他系统可以构建在 Kubernetes 之上。
+
+#### Kubernetes 不是什么:
+
+Kubernetes 不是一个传统意义上，包罗万象的 PaaS (平台即服务) 系统。我们保留用户选择的自由，这非常重要。
+
+* Kubernetes 不限制支持的应用程序类型。 它不插手应用程序框架 (例如 [Wildfly](http://wildfly.org/)), 不限制支持的语言运行时 (例如 Java, Python, Ruby)，只迎合符合 [12种因素的应用程序](http://12factor.net/)，也不区分"应用程序"与"服务"。Kubernetes 旨在支持极其多样化的工作负载，包括无状态、有状态和数据处理工作负载。如果应用可以在容器中运行，它就可以在 Kubernetes 上运行。
+* Kubernetes 不提供作为内置服务的中间件 (例如 消息中间件)、数据处理框架 (例如 Spark)、数据库 (例如 mysql)或集群存储系统 (例如 Ceph)。这些应用可以运行在 Kubernetes 上。
+* Kubernetes 没有提供点击即部署的服务市场
+* Kubernetes 从源代码到镜像都是非垄断的。 它不部署源代码且不构建您的应用程序。 持续集成 (CI) 工作流是一个不同用户和项目都有自己需求和偏好的领域。 所以我们支持在 Kubernetes 分层的 CI 工作流，但不指定它应该如何工作。
+* Kubernetes 允许用户选择其他的日志记录，监控和告警系统 (虽然我们提供一些集成作为概念验证)
+* Kubernetes 不提供或授权一个全面的应用程序配置语言/系统 (例如 [jsonnet](https://github.com/google/jsonnet)).
+* Kubernetes 不提供也不采用任何全面机器配置、保养、管理或自我修复系统
+
+另一方面，许多 PaaS 系统*运行*在 Kubernetes 上面，例如  [Openshift](https://github.com/openshift/origin), [Deis](http://deis.io/), and [Eldarion](http://eldarion.cloud/)。 您也可以自定义您自己的 PaaS, 与您选择的 CI 系统集成，或与 Kubernetes 一起使用: 将您的容器镜像部署到 Kubernetes。
+
+由于 Kubernetes 在应用级别而不仅仅在硬件级别上运行，因此它提供 PaaS 产品通用的一些功能，例如部署、扩展、负载均衡、日志记录、监控等。但是，Kubernetes 不是单一的，默认解决方案是可选和可插拔的。
+
+此处，Kubernetes 不仅仅是一个 "编排系统"；它消除了编排的需要。 "编排"技术定义的是工作流的执行: 从 A 到 B，然后到 C。相反，Kubernetes 是包括一套独立、可组合的控制过程，通过声明式语法使其连续地朝着期望状态驱动当前状态。 不需要告诉它具体从 A 到 C 的过程，只要告诉到 C 的状态即可。 也不需要集中控制；该方法更类似于"编舞"。这使得系统更容易使用并且更强大、更可靠、更具弹性和可扩展性。
+
+#### *Kubernetes* 是什么意思? K8s?
+
+名称 **Kubernetes** 源于希腊语，意为 "舵手" 或 "飞行员"， 且是英文 "governor" 和 ["cybernetic"](http://www.etymonline.com/index.php?term=cybernetics)的词根。 **K8s** 是通过将 8 个字母 "ubernete" 替换为 8 而导出的缩写。另外，在中文里，k8s 的发音与 Kubernetes 的发音比较接近。
+

cn/docs/tutorials/kubernetes-basics/cluster-interactive.html

@@ -0,0 +1,35 @@
+---
+title: 交互式教程 - 创建集群
+---
+
+<!DOCTYPE html>
+
+<html lang="en">
+
+<body>
+
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+<script src="https://katacoda.com/embed.js"></script>
+
+<div class="layout" id="top">
+
+    <main class="content katacoda-content">
+
+        <div class="katacoda">
+            <div class="katacoda__alert">
+                To interact with the Terminal, please use the desktop/tablet version
+            </div>
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
+        </div>
+        <div class="row">
+            <div class="col-md-12">
+                <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/deploy-intro/" role="button">Continue to Module 2<span class="btn__next">›</span></a>
+            </div>
+        </div>
+
+    </main>
+
+</div>
+
+</body>
+</html>

cn/docs/tutorials/kubernetes-basics/cluster-intro.html

@@ -0,0 +1,110 @@
+---
+redirect_from:
+- "/docs/tutorials/getting-started/create-cluster/"
+- "/docs/tutorials/getting-started/create-cluster.html"
+title: 使用 Minikube 创建一个集群
+---
+
+<!DOCTYPE html>
+
+<html lang="en">
+
+<body>
+
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+
+<div class="layout" id="top">
+
+	<main class="content">
+
+		<div class="row">
+
+      <div class="col-md-8">
+      	<h3>目标</h3>
+				<ul>
+					<li>了解什么是 Kubernetes 集群</li>
+					<li>了解什么是 Minikube</li>
+					<li>使用在线终端启动 Kubernetes 集群</li>
+				</ul>
+			</div>
+
+			<div class="col-md-8">
+				<h3>Kubernetes 集群</h3>
+				<p>
+				<b>Kubernetes 用于协调高度可用的计算机集群，这些计算机群集被连接作为单个单元工作。</b> Kubernetes 中的抽象允许您将容器化的应用程序部署到集群，而不必专门将其绑定到单个计算机。为了利用这种新的部署模型，应用程序需要以将它们与各个主机分离的方式打包: 它们需要被容器化。容器化应用程序比过去的部署模型更灵活和可用，其中应用程序直接安装到特定机器上，作为深入集成到主机中的软件包。 <b>Kubernetes 以更有效的方式自动化、跨集群的容器应用程序的分发和调度。</b> Kubernetes 是一个 <a href="https://github.com/kubernetes/kubernetes">开源</a> 平台，为生产环境准备的。
+				</p>
+				<p>Kubernetes 集群由两种类型的资源组成:
+					<ul>
+			            <li>一个 <b>Master</b> 调度节点</li>
+			            <li><b>Nodes</b> 应用程序实际运行的地方</li>
+			        </ul>
+			    </p>
+			</div>
+
+			<div class="col-md-4">
+				<div class="content__box content__box_lined">
+					<h3>概要:</h3>
+					<ul>
+						<li>Kubernetes 集群</li>
+						<li>Minikube</li>
+					</ul>
+				</div>
+				<div class="content__box content__box_fill">
+					<p><i>
+						Kubernetes 是一个生产级的开源平台，用于协调计算机集群内部和跨计算机集群的应用程序容器的分发(调度)和运行。
+					</i></p>
+				</div>
+			</div>
+		</div>
+		<br>
+
+		<div class="row">
+			<div class="col-md-8">
+				<h2 style="color: #3771e3;">集群图</h2>
+			</div>
+		</div>
+
+		<div class="row">
+			<div class="col-md-8">
+				<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_01_cluster.svg"></p>
+			</div>
+		</div>
+		<br>
+
+		<div class="row">
+			<div class="col-md-8">
+				<p><b>Master 负责管理集群。</b> master 协调集群中的所有活动，例如调度应用程序、维护应用程序的所需状态、扩展应用程序和滚动更新。</p>
+				<p><b>node 是 Kubernetes 集群中的工作机器，可以是物理机或虚拟机。</b> 每个工作节点都有一个 Kubelet，它是管理 node 并与 Kubernetes Master 节点进行通信的代理。node 上还应具有处理容器操作的工作，例如 <a href="https://www.docker.com/">Docker</a> 或 <a href="https://coreos.com/rkt/">rkt</a>。一个 Kubernetes 工作集群至少有三个 node 节点。</p>
+
+			</div>
+			<div class="col-md-4">
+				<div class="content__box content__box_fill">
+					<p><i> Master 管理集群和 Nodes 用于托管正在运行的应用程序。  </i></p>
+				</div>
+			</div>
+		</div>
+
+		<div class="row">
+			<div class="col-md-8">
+				<p>当您在 Kubernetes 上部署应用程序时，您可以告诉 master 启动应用程序容器。Master 调度容器在集群的 Node 上运行。<b> Nodes 使用 Master 公开的 Kubernetes API 与 Master 通信</b>。最终用户还可以直接使用 Kubernetes 的 API 与集群交互。</p>
+
+				<p>Kubernetes 集群可以部署在物理机或虚拟机上。要开始使用 Kubernetes 开发，您可以使用 <a href="https://github.com/kubernetes/minikube">Minikube</a>。Minikube 是一个轻量级的 Kubernetes 实现，在本机创建一台虚拟机，并部署一个只包含一个节点的简单集群。 Minikube 适用于 Linux, Mac OS 和 Windows 系统。Minikube CLI 提供了集群的基本引导操作，包括启动、停止、状态和删除。但是，对于此基础训练，您将使用预先安装了 Minikube 的在线终端。</p>
+
+				<p>现在您已经知道 Kubernetes 是什么，让我们使用在线教程，开始我们的第一个集群!</p>
+
+			</div>
+		</div>
+		<br>
+
+		<div class="row">
+			<div class="col-md-12">
+				<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/cluster-interactive/" role="button">启动交互教程 <span class="btn__next">›</span></a>
+			</div>
+		</div>
+
+	</main>
+
+</div>
+
+</body>
+</html>

cn/docs/tutorials/kubernetes-basics/deploy-interactive.html

@@ -0,0 +1,39 @@
+---
+title: 交互式教程 - 部署应用程序
+---
+
+<!DOCTYPE html>
+
+<html lang="en">
+
+<body>
+
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+<script src="https://katacoda.com/embed.js"></script>
+
+<div class="layout" id="top">
+
+    <main class="content katacoda-content">
+
+        <br>
+        <div class="katacoda">
+            <div class="katacoda__alert">
+                To interact with the Terminal, please use the desktop/tablet version
+            </div>
+
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            </div>
+
+        </div>
+        <div class="row">
+            <div class="col-md-12">
+                <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/explore-intro/" role="button">Continue to Module 3<span class="btn__next">›</span></a>
+            </div>
+        </div>
+
+    </main>
+
+</div>
+
+</body>
+</html>

cn/docs/tutorials/kubernetes-basics/deploy-intro.html

@@ -0,0 +1,108 @@
+---
+title: 使用 kubectl 创建部署
+---
+
+<!DOCTYPE html>
+
+<html lang="en">
+
+<body>
+
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+
+<div class="layout" id="top">
+
+	<main class="content">
+
+		<div class="row">
+
+		 <div class="col-md-8">
+      	<h3>目标</h3>
+				<ul>
+					<li>了解应用程序部署</li>
+					<li>使用 kubectl 在 Kubernetes 上部署您的第一个应用程序</li>
+				</ul>
+			</div>
+
+			<div class="col-md-8">
+				<h3>Kubernetes 部署</h3>
+				<p>
+				一旦运行了 Kubernetes 集群，您可以在其上部署容器化应用程序。为此，您可以创建一个 Kubernetes <b>Deployment</b>。Deployment 负责创建和更新应用程序实例。创建 Deployment 后， Kubernetes master 会将 Deployment 创建的应用程序实例调度到集群中的各个节点。
+				</p>
+
+				<p>创建应用程序实例后，Kubernetes Deployment 控制器会持续监视这些实例。如果托管它的节点不可用或删除，则 Deployment 控制器将替换实例。 <b>这提供了一种解决机器故障或维护的自愈机制。</b></p>
+
+				<p>在编排前的世界中，通常会使用安装脚本启动应用程序，但是它们并不能从机器故障中恢复。通过创建应用程序实例并使其运行在跨节点的机器之间，Kubernetes Deployments 提供了截然不同的应用管理方法。 </p>
+
+			</div>
+
+			<div class="col-md-4">
+				<div class="content__box content__box_lined">
+					<h3>概要:</h3>
+					<ul>
+						<li>Deployments</li>
+						<li>Kubectl</li>
+					</ul>
+				</div>
+				<div class="content__box content__box_fill">
+					<p><i>
+						Deployment 负责创建和更新应用程序的实例
+					</i></p>
+				</div>
+			</div>
+		</div>
+		<br>
+
+		<div class="row">
+			<div class="col-md-8">
+				<h2 style="color: #3771e3;">在 Kubernetes 上部署您的第一个应用程序</h2>
+			</div>
+		</div>
+
+		<div class="row">
+			<div class="col-md-8">
+				<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_02_first_app.svg"></p>
+			</div>
+		</div>
+		<br>
+
+		<div class="row">
+			<div class="col-md-8">
+
+                <p>您可以使用 Kubernetes 命令行工具 <b>Kubectl</b>创建和管理 Deployment。Kubectl 使用 Kubernetes API 与集群进行交互。在本模块中，您将学习在 Kubernetes 集群上运行应用程序部署所需的最常见 Kubectl 命令。</p>
+
+				<p>创建部署时，您需要为应用程序指定容器镜像以及要运行的副本数。您可以稍后通过更新部署来更改该信息；模块 <a href="/docs/tutorials/kubernetes-basics/scale-intro/">5</a> 和 <a href="/docs/tutorials/kubernetes-basics/update-intro/">6</a> 是一个基础训练讨论如何扩展和更新您的部署。</p>
+
+
+
+
+			</div>
+			<div class="col-md-4">
+				<div class="content__box content__box_fill">
+					<p><i> 应用程序需要打包成支持的容器格式之一，以便部署在 Kubernetes 上。</i></p>
+				</div>
+			</div>
+		</div>
+
+		<div class="row">
+			<div class="col-md-8">
+				<p>对于我们的第一个部署，我们将使用 <a href="https://nodejs.org">Node.js</a> 应用程序打包到 Docker 容器。源代码和 Dockerfile 可在 Kubernetes Bootcamp <a href="https://github.com/kubernetes/kubernetes-bootcamp">GitHub 存储库</a> 中找到。</p>
+
+				<p>现在您已经知道部署是什么，我来再来看看在线教程，并部署我们的第一个应用程序!</p>
+
+			</div>
+		</div>
+		<br>
+
+		<div class="row">
+			<div class="col-md-12">
+				<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/deploy-interactive/" role="button">启动交互式教程 <span class="btn__next">›</span></a>
+			</div>
+		</div>
+
+	</main>
+
+</div>
+
+</body>
+</html>

cn/docs/tutorials/kubernetes-basics/explore-interactive.html

@@ -0,0 +1,39 @@
+---
+title: 交互式教程 - 应用程序探索
+---
+
+<!DOCTYPE html>
+
+<html lang="en">
+
+<body>
+
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+<script src="https://katacoda.com/embed.js"></script>
+
+<div class="layout" id="top">
+
+    <main class="content katacoda-content">
+
+        <br>
+        <div class="katacoda">
+
+            <div class="katacoda__alert">
+                To interact with the Terminal, please use the desktop/tablet version
+            </div>
+
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/4" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            </div>
+        </div>
+        <div class="row">
+            <div class="col-md-12">
+                <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose-intro/" role="button">Continue to Module 4<span class="btn__next">›</span></a>
+            </div>
+        </div>
+
+    </main>
+
+</div>
+
+</body>
+</html>

cn/docs/tutorials/kubernetes-basics/explore-intro.html

@@ -0,0 +1,142 @@
+---
+title: 查看 Pods 和 Nodes
+---
+
+<!DOCTYPE html>
+
+<html lang="en">
+
+<body>
+
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+
+
+<div class="layout" id="top">
+
+	<main class="content">
+
+		<div class="row">
+
+     <div class="col-md-8">
+      	<h3>目标</h3>
+				<ul>
+					<li>了解 Kubernetes Pods</li>
+					<li>了解 Kubernetes Nodes</li>
+					<li>已部署应用故障排除</li>
+				</ul>
+			</div>
+
+			<div class="col-md-8">
+				<h2>Kubernetes Pods</h2>
+				<p>当您在模块 <a href="/docs/tutorials/kubernetes-basics/deploy-intro/">2</a>中创建部署时，Kubernetes 创建了一个 <b>Pod</b> 来托管您的应用程序实例。Pod 是一个 Kubernetes 的资源抽象，表示一个或多个应用容器 (例如 Docker 或 rkt) 组，以及一些用于这些容器的共享资源。这些资源包括:</p>
+				<ul>
+					<li>共享存储，如卷</li>
+					<li>网络，作为唯一的集群 IP 地址</li>
+					<li>每个容器如何运行的信息，例如容器镜像版本或要使用的特定端口</li>
+				</ul>
+				<p>Pod 模型可以理解为应用程序特定的 "逻辑主机"，并且可以包含相对紧密耦合的不同应用程序容器。例如，Pod 可能包含带有 Node.js 应用程序的容器以及用于提供要由 Node.js Web 服务器发布数据的不同容器。Pod 中的容器共享 IP 地址和端口空间，始终位于同一位置并且统一调度，并在相同的节点上运行，共享上下文环境。</p>
+
+			<p>Pods 是 Kubernetes 平台上的原子单元。当我们在 Kubernetes 上创建一个部署时，该部署将在其中创建包含容器的 Pod (而不是直接创建容器)。每个 Pod 绑定到它被调度的节点，并且保持在那里，直到终止 (根据重启策略) 或删除。在节点故障的情况下，在集群中的其他可用节点上调度相同的 Pod。</p>
+
+			</div>
+			<div class="col-md-4">
+				<div class="content__box content__box_lined">
+					<h3>概要:</h3>
+					<ul>
+						<li>Pods</li>
+						<li>Nodes</li>
+						<li>Kubectl 主要命令</li>
+					</ul>
+				</div>
+				<div class="content__box content__box_fill">
+						<p><i>
+							Pod 是一组或多个应用程序容器 (例如 Docker 或 rkt)，包含共享存储 (卷)，IP 地址以及有关如何运行它们的信息。
+						</i></p>
+				</div>
+			</div>
+		</div>
+		<br>
+
+		<div class="row">
+			<div class="col-md-8">
+				<h2 style="color: #3771e3;">Pods 概览</h2>
+			</div>
+		</div>
+
+		<div class="row">
+			<div class="col-md-8">
+				<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_03_pods.svg"></p>
+			</div>
+		</div>
+		<br>
+
+		<div class="row">
+			<div class="col-md-8">
+				<h2>Nodes</h2>
+				<p>Pod 总是运行在 <b>Node</b>上。Node 是 Kubernetes 的工作机器，可以是一个虚拟机或物理，这取决于在集群的安装情况。每个 Node 由 Master 管理。一个 Node 上可以有多个 Pod, Kubernetes master 会自动处理调度集群各个 Node 上的 Pod。 Master 在自动调度时，会考虑每个 Node 上的可用资源。</p>
+
+				<p>每个 Kubernetes Node 节点至少运行以下组件:</p>
+				<ul>
+					<li>Kubelet 是负责 Kubernetes Master 和 所有 Node 节点之间通信的进程，它管理机器上运行的 Pod 和容器。</li>
+					<li>容器运行时(例如 Docker, rkt) 负责从镜像仓库中拉取容器镜像，解包容器并运行应用程序。</li>
+				</ul>
+
+			</div>
+			<div class="col-md-4">
+				<div class="content__box content__box_fill">
+					<p><i> 如果一些容器强耦合并且需要共享资源(例如 磁盘)，那么这些容器应该放到单个 Pod 中一起调度。 </i></p>
+				</div>
+			</div>
+		</div>
+
+		<br>
+
+		<div class="row">
+			<div class="col-md-8">
+				<h2 style="color: #3771e3;">Node 概述</h2>
+			</div>
+		</div>
+
+		<div class="row">
+			<div class="col-md-8">
+				<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_03_nodes.svg"></p>
+			</div>
+		</div>
+		<br>
+
+		<div class="row">
+			<div class="col-md-8">
+				<h2>使用 kubectl 进行故障排除</h2>
+				<p>在模块 <a href="/docs/tutorials/kubernetes-basics/deploy-intro/">2</a>中，您使用了 Kubectl 命令行接口。您将在模块 3 中继续使用它来获取有关已部署应用程序及其环境信息。最常见的操作可以通过以下 kubectl 命令完成:</p>
+				<ul>
+					<li><b>kubectl get</b> - 列出可用资源</li>
+					<li><b>kubectl describe</b> - 显示有关资源的详细信息</li>
+					<li><b>kubectl logs</b> - 从 Pod 中的容器打印日志</li>
+					<li><b>kubectl exec</b> - 在 Pod 中的容器执行命令</li>
+				</ul>
+
+				<p>您可以使用这些命令来查看应用程序部署的时间，它们当前的状态，运行的位置及其配置。</p>
+
+				<p>现在我们更多地了解了集群组件和命令行交互，接下来，一起来探索分析我们的应用程序。</p>
+
+			</div>
+			<div class="col-md-4">
+				<div class="content__box content__box_fill">
+					<p><i> Node 是 Kubernetes 中的工作机器，可能是物理机或虚拟机，具体取决于集群的安装配置。多个 Pod 可以在一个 Node 上运行。 </i></p>
+				</div>
+			</div>
+		</div>
+		<br>
+
+		<div class="row">
+			<div class="col-md-12">
+				<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/explore-interactive/" role="button">启动交互式教程<span class="btn__next">›</span></a>
+			</div>
+		</div>
+
+	</main>
+
+</div>
+
+</body>
+</html>

cn/docs/tutorials/kubernetes-basics/expose-interactive.html

@@ -0,0 +1,36 @@
+---
+title: 交互性教程 - 应用外部可见
+---
+
+<!DOCTYPE html>
+
+<html lang="en">
+
+<body>
+
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+<script src="https://katacoda.com/embed.js"></script>
+
+<div class="layout" id="top">
+
+    <main class="content katacoda-content">
+
+        <div class="katacoda">
+            <div class="katacoda__alert">
+                To interact with the Terminal, please use the desktop/tablet version
+            </div>
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/8" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            </div>
+        </div>
+        <div class="row">
+            <div class="col-md-12">
+                <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/scale-intro/" role="button">Continue to Module 5<span class="btn__next">›</span></a>
+            </div>
+        </div>
+
+    </main>
+
+</div>
+
+</body>
+</html>

cn/docs/tutorials/kubernetes-basics/expose-intro.html

@@ -0,0 +1,138 @@
+---
+title: 使用服务让您的应用程序外部可见
+---
+
+<!DOCTYPE html>
+
+<html lang="en">
+
+<body>
+
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+
+<div class="layout" id="top">
+
+	<main class="content">
+
+		<div class="row">
+
+     <div class="col-md-8">
+      	<h3>目标</h3>
+				<ul>
+					<li>了解 Kubernetes 服务</li>
+					<li>了解 Kubernetes 标签</li>
+					<li>应用程序在 Kubernetes 外部可见</li>
+				</ul>
+			</div>
+
+			<div class="col-md-8">
+			<h3>Kubernetes Services</h3>
+
+			<p>虽然每个 Pod 在所在的集群中拥有自己独立的 IP 地址，但这些 IP 地址不会暴露在 Kubernetes 集群外部。考虑到 Pod 可能随时会被终止、删除或被其他 Pod 替换，我们需要一种方法让其他 Pod 和应用程序自动发现彼此。Kubernetes 通过 Service 对 Pods 进行分组来解决此问题。一个 Kubernetes <b>Service</b> 是一个抽象层，它定义了一组逻辑的 Pods，并让这些 Pods 对外部流量可见，可以被负载均衡和服务发现。 </p>
+
+			<p>此抽象允许我们将 Pods 暴露给集群外部的流量访问。Services 具有自己的唯一集群专用 IP 地址，并显示一个端口以接收流量。如果选择在集群外公开 Service，则有如下选项:</p>
+			<ul>
+				<li>LoadBalancer - 提供公有 IP 地址 (在 GCP 或 AWS 上运行 Kubernetes 通常使用此方式)</li>
+				<li>NodePort - 使用 NAT 在集群的每个 Node 节点的同一端口让服务可见。(所有 Kubernetes 集群和 Minikube 中都可用此方式)</li>
+			</ul>
+			</div>
+			<div class="col-md-4">
+				<div class="content__box content__box_lined">
+					<h3>摘要:</h3>
+					<ul>
+						<li>Pod 流量外部可见</li>
+						<li>Pods 流量负载均衡</li>
+						<li>使用标签</li>
+					</ul>
+				</div>
+				<div class="content__box content__box_fill">
+						<p><i>
+							Kubernetes Service 是一个抽象层，它定义了一组逻辑的 Pods，并为这些 Pods 启用了外部流量访问、负载均衡和服务发现。
+						</i></p>
+				</div>
+			</div>
+		</div>
+		<br>
+
+		<div class="row">
+			<div class="col-md-8">
+				<h2 style="color: #3771e3;">Services 概述</h2>
+			</div>
+		</div>
+
+		<div class="row">
+			<div class="col-md-8">
+				<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_04_services.svg"></p>
+			</div>
+		</div>
+		<br>
+
+		<div class="row">
+			<div class="col-md-8">
+
+				<p>一个 Service 提供了一组 Pods 的流量负载均衡。通过创建服务以对来自特定部署的所有 Pods 进行分组时，这是有用的(当我们有多个实例运行时，我们的应用程序将在下一个模块中使用这一点)。</p>
+
+				<p>Services 还负责集群内部的服务发现 (包含在 <a href="/docs/user-guide/connecting-applications/#accessing-the-service">访问服务</a>中)。 例如，这将允许前端服务 (如 web 服务器) 从后端服务 (如 数据库) 接收流量，而不必考虑 Pod。 </p>
+
+				<p>Services 使用标签选择器匹配一组 Pods，标签选择器支持在标签上进行原始逻辑分组的能力。</p>
+
+			</div>
+			<div class="col-md-4">
+				<div class="content__box content__box_fill">
+					<p><i> 您可以通过添加 --expose 作为 kubectl 运行命令的参数，在创建 Deployment 的同时创建 Service。 </i></p>
+				</div>
+			</div>
+		</div>
+
+		<br>
+
+		<div class="row">
+			<div class="col-md-8">
+				<p><b>Labels</b> 是附加到对象的 键/值对，例如 Pods，您可以将它们视为社交媒体的标签符号。它们用于以对用户有意义的方式组织相关对象，如:</p>
+				<ul>
+					<li>生产环境 (生产、测试、开发)</li>
+					<li>应用程序版本 (beta、v1.3)</li>
+					<li>服务类型 (前端、后端、数据库)</li>
+				</ul>
+			</div>
+			<div class="col-md-4">
+				<div class="content__box content__box_fill">
+					<p><i> Labels 是附加到对象的键/值对。</i></p>
+				</div>
+			</div>
+		</div>
+		<br>
+		<div class="row">
+			<div class="col-md-8">
+				<h2 style="color: #3771e3;">Labels</h2>
+			</div>
+		</div>
+
+		<div class="row">
+			<div class="col-md-8">
+				<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_04_labels.svg"></p>
+			</div>
+		</div>
+		<br>
+		<div class="row">
+			<div class="col-md-8">
+
+				<p>Labels 可以在创建时或以后附加到对象，并可以随时修改。
+				在使用 kubectl run 命令新建 Pods/Deployment 时，会设置一些默认的 Labels/Label。标签和标签选择器之间的链接定义了 Deployment 及其创建 Pod 之间的关系。</p>
+
+				<p>现在，让我们在 Service 的帮助下公开我们的应用程序，并应用一些新的标签。</p>
+			</div>
+		</div>
+		<br>
+		<div class="row">
+			<div class="col-md-12">
+				<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose-interactive/" role="button">启动交互式教程<span class="btn__next">›</span></a>
+			</div>
+		</div>
+
+	</main>
+
+</div>
+
+</body>
+</html>

cn/docs/tutorials/kubernetes-basics/index.html

@@ -0,0 +1,106 @@
+---
+title: 概述
+---
+
+<!DOCTYPE html>
+
+<html lang="en">
+
+<body>
+
+<link href="./public/css/styles.css" rel="stylesheet">
+
+<div class="layout" id="top">
+
+  <main class="content">
+
+    <div class="row">
+      <div class="col-md-9">
+        <h2>Kubernetes 基础</h2>
+        <p>本教程介绍了 Kubernetes 集群编排系统的基础知识。每个模块包含关于 Kubernetes 主要特性和概念的一些背景信息，并包括一个交互式在线教程。这些交互式教程让您可以自己管理一个简单的集群及其容器化应用程序。</p>
+        <p>使用交互式教程，您可以学习:</p>
+        <ul>
+        <li>在集群上部署容器化应用程序</li>
+        <li>弹性部署</li>
+        <li>使用新的软件版本，更新容器化应用程序</li>
+        <li>调试容器化应用程序</li>
+        </ul>
+        <p>教程 Katacoda 在您的浏览器中运行一个虚拟终端，在浏览器中运行 Minikube，这是一个可在任何地方小规模本地部署的 Kubernetes 集群。没有安装任何软件或进行任何配置; 每个交互性教程都直接从您的网页浏览器上运行。</p>
+      </div>
+    </div>
+
+    <br>
+
+    <div class="row">
+      <div class="col-md-9">
+        <h2>Kubernetes 可以为您做些什么?</h2>
+        <p>现代的 Web 服务，用户希望应用程序能够 24/7 全天候使用，开发人员希望每天可以多次发布部署新版本的应用程序。 容器化可以帮助软件包服务于这些目标，使应用程序能够以简单快速的方式发布和更新，而无需停机。Kubernetes 帮助您确保这些容器化的应用程序在您想要的地方和时间运行，并帮助应用程序找到它们需要的资源的工具。 <a href="http://kubernetes.io/docs/whatisk8s/">Kubernetes</a>  是一个生产可用的开源平台，具有 Google 容器集群方面的设计与经验积累，拥有来自社区的最佳实践。</p>
+      </div>
+    </div>
+
+    <div class="content__modules">
+      <h2>Kubernetes 基础模块</h2>
+      <div class="row">
+        <div class="col-md-4">
+          <div class="thumbnail">
+            <a href="/docs/tutorials/kubernetes-basics/cluster-intro/"><img src="./public/images/module_01.svg?v=1469803628347" alt=""></a>
+            <div class="caption">
+              <a href="cluster-intro/"><h5>1. 创建一个 Kubernetes 集群</h5></a>
+            </div>
+          </div>
+        </div>
+        <div class="col-md-4">
+          <div class="thumbnail">
+            <a href="/docs/tutorials/kubernetes-basics/deploy-intro/"><img src="./public/images/module_02.svg?v=1469803628347" alt=""></a>
+            <div class="caption">
+              <a href="deploy-intro/"><h5>2. 部署应用程序</h5></a>
+            </div>
+          </div>
+        </div>
+        <div class="col-md-4">
+          <div class="thumbnail">
+            <a href="/docs/tutorials/kubernetes-basics/explore-intro/"><img src="./public/images/module_03.svg?v=1469803628347" alt=""></a>
+            <div class="caption">
+              <a href="explore-intro/"><h5>3. 应用程序探索</h5></a>
+            </div>
+          </div>
+        </div>
+        <div class="col-md-4">
+          <div class="thumbnail">
+            <a href="/docs/tutorials/kubernetes-basics/expose-intro/"><img src="./public/images/module_04.svg?v=1469803628347" alt=""></a>
+            <div class="caption">
+              <a href="expose-intro/"><h5>4. 应用外部可见</h5></a>
+            </div>
+          </div>
+        </div>
+        <div class="col-md-4">
+          <div class="thumbnail">
+            <a href="/docs/tutorials/kubernetes-basics/scale-intro/"><img src="./public/images/module_05.svg?v=1469803628347" alt=""></a>
+            <div class="caption">
+              <a href="scale-intro/"><h5>5. 应用可伸缩</h5></a>
+            </div>
+          </div>
+        </div>
+        <div class="col-md-4">
+          <div class="thumbnail">
+            <a href="/docs/tutorials/kubernetes-basics/update-intro/"><img src="./public/images/module_06.svg?v=1469803628347" alt=""></a>
+            <div class="caption">
+              <a href="update-intro/"><h5>6. 应用更新</h5></a>
+            </div>
+          </div>
+        </div>
+      </div>
+    </div>
+
+    <div class="row">
+      <div class="col-md-12">
+        <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/cluster-intro/" role="button">开始教程<span class="btn__next">›</span></a>
+      </div>
+    </div>
+
+  </main>
+
+</div>
+
+</body>
+</html>

cn/docs/tutorials/kubernetes-basics/scale-interactive.html

@@ -0,0 +1,38 @@
+---
+title: 交互式教程 - 扩展您的应用程序
+---
+
+<!DOCTYPE html>
+
+<html lang="en">
+
+<body>
+
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+<script src="https://katacoda.com/embed.js"></script>
+
+<div class="layout" id="top">
+
+    <main class="content katacoda-content">
+
+        <div class="katacoda">
+            <div class="katacoda__alert">
+                To interact with the Terminal, please use the desktop/tablet version
+            </div>
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/5" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            </div>
+        </div>
+        <div class="row">
+            <div class="col-md-12">
+                <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/update-intro/" role="button">Continue to Module 6<span class="btn__next">›</span></a>
+            </div>
+        </div>
+
+    </main>
+
+<a class="scrolltop" href="#top"></a>
+
+</div>
+
+</body>
+</html>

cn/docs/tutorials/kubernetes-basics/scale-intro.html

@@ -0,0 +1,120 @@
+---
+title: 运行应用程序的多个实例
+---
+
+<!DOCTYPE html>
+
+<html lang="en">
+
+<body>
+
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+
+<div class="layout" id="top">
+
+	<main class="content">
+
+		<div class="row">
+
+     <div class="col-md-8">
+      	<h3>目标</h3>
+				<ul>
+					<li>使用 kubectl 缩放应用程序</li>
+				</ul>
+			</div>
+
+			<div class="col-md-8">
+       <h3>缩放应用程序</h3>
+
+			<p>在之前的模块中，我们创建了一个 <a href="http://kubernetes.io/docs/user-guide/deployments/"> Deployment</a>，然后通过 <a href="http://kubernetes.io/docs/user-guide/services/">Service</a>让应用程序外部可见。Deployment 仅为我们的应用程序创建了一个 Pod。 当流量增加时，我们将需要扩展应用程序以跟上用户需求。</p>
+
+			<p><b>Scaling</b> 是通过更改 Deployment 中的副本数量实现的。</p>
+
+			</div>
+			<div class="col-md-4">
+				<div class="content__box content__box_lined">
+					<h3>摘要:</h3>
+					<ul>
+						<li>Deployment 的缩放</li>
+					</ul>
+				</div>
+				<div class="content__box content__box_fill">
+					<p><i> 您可以使用 kubectl run 命令的 --replicas 参数，在创建 Deployment 时指定多个实例。 </i></p>
+				</div>
+			</div>
+		</div>
+		<br>
+
+		<div class="row">
+			<div class="col-md-8">
+				<h2 style="color: #3771e3;">Scaling 概述</h2>
+			</div>
+		</div>
+
+		<div class="row">
+			<div class="col-md-1"></div>
+			<div class="col-md-8">
+				<div id="myCarousel" class="carousel" data-ride="carousel" data-interval="3000">
+					<ol class="carousel-indicators">
+					    <li data-target="#myCarousel" data-slide-to="0" class="active"></li>
+					    <li data-target="#myCarousel" data-slide-to="1"></li>
+					</ol>
+					  <div class="carousel-inner" role="listbox">
+					    <div class="item active">
+					      <img src="/docs/tutorials/kubernetes-basics/public/images/module_05_scaling1.svg">
+					    </div>
+
+					    <div class="item">
+					      <img src="/docs/tutorials/kubernetes-basics/public/images/module_05_scaling2.svg">
+					    </div>
+					  </div>
+
+					  <a class="left carousel-control" href="#myCarousel" role="button" data-slide="prev">
+						<span class="sr-only ">Previous</span>
+					  </a>
+					  <a class="right carousel-control" href="#myCarousel" role="button" data-slide="next">
+						<span class="sr-only">Next</span>
+					  </a>
+
+					</div>
+			</div>
+		</div>
+
+		<br>
+
+		<div class="row">
+			<div class="col-md-8">
+
+				<p>扩展 Deployment 将确保新创建的 Pods 会调度到可用资源的 Node 节点上，收缩会保证 Pods 数量减少至新的所需状态。  Kubernetes 还支持 Pods 的 <a href="http://kubernetes.io/docs/user-guide/horizontal-pod-autoscaling/"> 自动缩放版 </a> ，但不在本教程范围之内。收缩到零也是可以的，此时它将终止指定 Deployment 的所有 Pod。 </p>
+
+				<p>运行应用程序的多个实例需要一种将流量分发给所有实例的方法。服务有内置的负载均衡器，可将网络流量分配给 Deployment 暴露的所有 Pods。服务通过使用 endpoints 持续监控运行的 Pods，以确保流量仅发送到可用的 Pods。</p>
+
+			</div>
+			<div class="col-md-4">
+				<div class="content__box content__box_fill">
+					<p><i>通过更改 Deployment 中的副本数可以实现伸缩应用程序。</i></p>
+				</div>
+			</div>
+		</div>
+
+		<br>
+
+		<div class="row">
+			<div class="col-md-8">
+				<p> 一旦您有应用程序的多个实例，您将能够滚动更新而不会停止服务。我们将在下一个模块中介绍。现在，我们去在线终端扩展我们的应用程序。</p>
+			</div>
+		</div>
+		<br>
+
+		<div class="row">
+			<div class="col-md-12">
+				<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/scale-interactive/" role="button">启动交互式教程 <span class="btn__next">›</span></a>
+			</div>
+		</div>
+
+	</main>
+
+</div>
+
+</body>
+</html>

cn/docs/tutorials/kubernetes-basics/update-interactive.html

@@ -0,0 +1,31 @@
+---
+title: 交互式教程 - 更新您的应用程序
+---
+
+<!DOCTYPE html>
+
+<html lang="en">
+
+<body>
+
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+<script src="https://katacoda.com/embed.js"></script>
+
+<div class="layout" id="top">
+
+    <main class="content katacoda-content">
+
+        <div class="katacoda">
+            <div class="katacoda__alert">
+                To interact with the Terminal, please use the desktop/tablet version
+            </div>
+            <div class="katacoda__box" id="inline-terminal-1"  data-katacoda-id="kubernetes-bootcamp/6" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
+            </div>
+        </div>
+
+    </main>
+
+</div>
+
+</body>
+</html>

cn/docs/tutorials/kubernetes-basics/update-intro.html

@@ -0,0 +1,135 @@
+---
+title: 执行滚动更新
+---
+
+<!DOCTYPE html>
+
+<html lang="en">
+
+<body>
+
+<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
+
+<div class="layout" id="top">
+
+	<main class="content">
+
+		<div class="row">
+
+     <div class="col-md-8">
+      	<h3>目标</h3>
+				<ul>
+					<li>使用 kubectl 执行滚动更新</li>
+				</ul>
+			</div>
+
+			<div class="col-md-8">
+			<h3>更新应用程序</h3>
+
+			<p>用户期望应用程序始终可用，并且开发人员有望每天部署新版本。这就是 Kubernetes 的滚动更新。 <b>Rolling updates</b> 允许通过使用新的 Pods 实例逐个更新来实现零停机的更新部署。新的 Pods 会被调度到可用资源的 Node 节点上。</p>
+
+			<p>在上一个模块中，我们将应用程序扩展为运行多个实例。这是执行更新但不影响应用可用性的要求。默认情况下，更新期间最大数量的 Pods 可能不可用，此时创建和更新 Pod 的最大数量是一。 这两个选项可以配置为数字或百分比(Pods)。
+			在 Kubernetes 中，更新已版本化，任何部署更新都可以恢复到以前的 (稳定) 版本。</p>
+
+			</div>
+			<div class="col-md-4">
+				<div class="content__box content__box_lined">
+					<h3>摘要:</h3>
+					<ul>
+						<li>更新应用程序</li>
+					</ul>
+				</div>
+				<div class="content__box content__box_fill">
+					<p><i>滚动更新允许通过使用新的 Pods 实例逐个更新来实现零停机的部署更新。 </i></p>
+				</div>
+			</div>
+		</div>
+		<br>
+
+		<div class="row">
+			<div class="col-md-8">
+				<h2 style="color: #3771e3;">滚动更新概述</h2>
+			</div>
+		</div>
+		<div class="row">
+			<div class="col-md-1"></div>
+			<div class="col-md-8">
+				<div id="myCarousel" class="carousel" data-ride="carousel" data-interval="3000">
+					<ol class="carousel-indicators">
+					    <li data-target="#myCarousel" data-slide-to="0" class="active"></li>
+					    <li data-target="#myCarousel" data-slide-to="1"></li>
+					    <li data-target="#myCarousel" data-slide-to="2"></li>
+					    <li data-target="#myCarousel" data-slide-to="3"></li>
+					</ol>
+					  <div class="carousel-inner" role="listbox">
+					    <div class="item active">
+					      <img src="/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates1.svg" >
+					    </div>
+
+					    <div class="item">
+					      <img src="/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates2.svg">
+					    </div>
+
+					    <div class="item">
+					      <img src="/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates3.svg">
+					    </div>
+
+					    <div class="item">
+					      <img src="/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates4.svg">
+					    </div>
+					  </div>
+
+					  <a class="left carousel-control" href="#myCarousel" role="button" data-slide="prev">
+						<span class="sr-only ">Previous</span>
+					  </a>
+					  <a class="right carousel-control" href="#myCarousel" role="button" data-slide="next">
+						<span class="sr-only">Next</span>
+					  </a>
+
+					</div>
+			</div>
+		</div>
+		<br>
+
+		<div class="row">
+			<div class="col-md-8">
+
+				<p>与应用程序缩放类似，如果 Deployment 外部可见，则 Service 将在更新期间将流量负载均衡到可用的 Pod。可用的 Pod 指的是应用程序用户可用的实例。</p>
+
+				<p>滚动更新允许以下操作:</p>
+				<ul>
+					<li>将应用程序从一个环境升级到另一个环境 (通过容器镜像更新)</li>
+					<li>回滚到以前的版本</li>
+					<li>持续集成和持续交付，实现应用程序零故障</li>
+
+				</ul>
+
+			</div>
+			<div class="col-md-4">
+				<div class="content__box content__box_fill">
+					<p><i>如果部署外部可见，则服务将在更新期间将流量负载均衡到可用的 Pod。 </i></p>
+				</div>
+			</div>
+		</div>
+
+		<br>
+
+		<div class="row">
+			<div class="col-md-8">
+				<p> 在下面的交互式教程中，我们将把应用程序更新到一个新版本，并执行回滚。</p>
+			</div>
+		</div>
+		<br>
+
+		<div class="row">
+			<div class="col-md-12">
+				<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/update-interactive/" role="button">启动交互式教程<span class="btn__next">›</span></a>
+			</div>
+		</div>
+
+	</main>
+
+</div>
+
+</body>
+</html>

cn/docs/whatisk8s.md

@@ -0,0 +1,9 @@
+---
+assignees:
+- k8s-merge-robot
+title: 认识 Kubernetes?
+---
+
+{% include user-guide-content-moved.md %}
+
+[认识 Kubernetes?](/docs/concepts/overview/what-is-kubernetes/)

community/index.html

@@ -9,56 +9,63 @@ cid: community
 </section>
 
 <section id="mainContent">
-	<main>
-		<div class="content">
-			<h3>Ensuring Kubernetes works well everywhere and for everyone.</h3>
-			<p>Connect with the Kubernetes community on our <a href="http://slack.k8s.io/">Slack channel</a> or join the
-				<a href="https://groups.google.com/forum/#!forum/kubernetes-dev">Kubernetes-dev Google group</a>. A weekly
-				community meeting takes place via video conference to discuss the state of affairs,
-				<a href="https://groups.google.com/forum/#!forum/kubernetes-community-video-chat">get a calendar invite</a>
-				to participate.</p>
-			<p>You can also join Kubernauts all around the world through our
-				<a href="https://www.meetup.com/topics/kubernetes/">Kubernetes Meetup Community</a> and the
-				<a href="https://www.meetup.com/Kubernetes-Cloud-Native-Online-Meetup/">Kubernetes Cloud Native Meetup Community</a>.</p>
-		</div>
-		<div class="content">
-			<h3>Special Interest Groups (SIGs)</h3>
-			<p>Have a special interest in how Kubernetes works with another technology?  See our ever growing
-				<a href="https://github.com/kubernetes/kubernetes/wiki/Special-Interest-Groups-(SIGs)">lists of SIGs</a>,
-				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).</p>
-		</div>
-		<div class="content">
-			<h3>Events</h3>
-			<div id="calendarWrapper">
-				<iframe src="https://calendar.google.com/calendar/embed?src=nt2tcnbtbied3l6gi2h29slvc0%40group.calendar.google.com&ctz=America/Los_Angeles"
-				        frameborder="0" scrolling="no"></iframe>
-			</div>
-		</div>
-	</main>
+    <main>
+        <div class="content">
+            <h3>Ensuring Kubernetes works well everywhere and for everyone.</h3>
+            <p>Connect with the Kubernetes community on our <a href="http://slack.k8s.io/">Slack channel</a> or join the
+                <a href="https://groups.google.com/forum/#!forum/kubernetes-dev">Kubernetes-dev Google group</a>. A weekly
+                community meeting takes place via video conference to discuss the state of affairs,
+                <a href="https://groups.google.com/forum/#!forum/kubernetes-community-video-chat">get a calendar invite</a>
+                to participate.</p>
+            <p>You can also join Kubernauts all around the world through our
+                <a href="https://www.meetup.com/topics/kubernetes/">Kubernetes Meetup Community</a> and the
+                <a href="https://www.meetup.com/Kubernetes-Cloud-Native-Online-Meetup/">Kubernetes Cloud Native Meetup Community</a>.</p>
+        </div>
+        <div class="content">
+            <h3>Special Interest Groups (SIGs)</h3>
+            <p>Have a special interest in how Kubernetes works with another technology?  See our ever growing
+                <a href="https://github.com/kubernetes/kubernetes/wiki/Special-Interest-Groups-(SIGs)">lists of SIGs</a>,
+                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).</p>
+
+            <p>As a member of the Kubernetes community, you are welcome to join any of the SIG meetings
+                you are interested in. No registration required.</p>
+            <div id="calendarMeetings">
+                <iframe src="https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles"
+                        frameborder="0" scrolling="no"></iframe>
+            </div>
+        </div>
+        <div class="content">
+            <h3>Events</h3>
+            <div id="calendarEvents">
+                <iframe src="https://calendar.google.com/calendar/embed?src=nt2tcnbtbied3l6gi2h29slvc0%40group.calendar.google.com&ctz=America/Los_Angeles"
+                        frameborder="0" scrolling="no"></iframe>
+            </div>
+        </div>
+    </main>
 </section>
 
 <section id="talkToUs">
-	<main>
-		<h3>Talk to Us!</h3>
-		<h4>We would love to hear from you, how you are using Kubernetes,<br> and what we can do to make it better.</h4>
-		<div id="bigSocial">
-			<div>
-				<a href="https://twitter.com/kubernetesio">@kubernetesio</a>
-				<p>Get the latest news and updates.</p>
-			</div>
-			<div>
-				<a href="https://github.com/kubernetes/kubernetes">Github Project</a>
-				<p>Check out the project and consider contributing.</p>
-			</div>
-			<div>
-				<a href="http://slack.k8s.io/">#kubernetes-users</a>
-				<p>Our Slack channel is the best way to contact our engineers and share your ideas with them.</p>
-			</div>
-			<div>
-				<a href="http://stackoverflow.com/questions/tagged/kubernetes">Stack Overflow</a>
-				<p>Our user forum is a great place to go for community support.</p>
-			</div>
-		</div>
-	</main>
+    <main>
+        <h3>Talk to Us!</h3>
+        <h4>We would love to hear from you, how you are using Kubernetes,<br> and what we can do to make it better.</h4>
+        <div id="bigSocial">
+            <div>
+                <a href="https://twitter.com/kubernetesio">@kubernetesio</a>
+                <p>Get the latest news and updates.</p>
+            </div>
+            <div>
+                <a href="https://github.com/kubernetes/kubernetes">Github Project</a>
+                <p>Check out the project and consider contributing.</p>
+            </div>
+            <div>
+                <a href="http://slack.k8s.io/">#kubernetes-users</a>
+                <p>Our Slack channel is the best way to contact our engineers and share your ideas with them.</p>
+            </div>
+            <div>
+                <a href="http://stackoverflow.com/questions/tagged/kubernetes">Stack Overflow</a>
+                <p>Our user forum is a great place to go for community support.</p>
+            </div>
+        </div>
+    </main>
 </section>

docs/admin/accessing-the-api.md

@@ -3,16 +3,12 @@ assignees:
 - bgrant0607
 - erictune
 - lavalamp
-title: Overview
+title: Controlling Access to the Kubernetes API
 ---
 
-This document describes how access to the Kubernetes API is controlled.
-
-## Overview
-
 Users [access the API](/docs/user-guide/accessing-the-cluster) using `kubectl`,
 client libraries, or by making REST requests.  Both human users and
-[Kubernetes service accounts](/docs/user-guide/service-accounts/) can be
+[Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/) can be
 authorized for API access.
 When a request reaches the API, it goes through several stages, illustrated in the
 following diagram:
@@ -42,7 +38,7 @@ The input to the authentication step is the entire HTTP request, however, it typ
 just examines the headers and/or client certificate.
 
 Authentication modules include Client Certificates, Password, and Plain Tokens,
-and JWT Tokens (used for service accounts).
+Bootstrap Tokens, and JWT Tokens (used for service accounts).
 
 Multiple authentication modules can be specified, in which case each one is tried in sequence,
 until one of them succeeds.
@@ -61,43 +57,48 @@ users in its object store.
 
 ## Authorization
 
-Once the request is authenticated as coming from a specific user,
-it moves to a generic authorization step.  This is shown as step **2** in the
-diagram. 
+After the request is authenticated as coming from a specific user, the request must be authorized. This is shown as step **2** in the diagram. 
 
-The input to the Authorization step are attributes of the REST request, including:
-  - the username determined by the Authentication step.
-  - a `verb` associated with the API request.  Most object support these common operations: `list, watch, create, update, patch, delete`.  Some objects have "special verbs"; for example pods and services can be `proxy`-ed.
-  - any subresource associated with the API request (e.g. `status`).
-  - the Group, Version, and Kind of the API resource (e.g. `v1 pod`, or `batch/v1 job`) being
-    operated on.
-  - the name and namespace of the object.
+A request must include the username of the requester, the requested action, and the object affected by the action. The request is authorized if an existing policy declares that the user has permissions to complete the requested action. 
 
-There are multiple supported Authorization Modules.  The cluster creator configures the API
-server with which Authorization Modules should be used.  When multiple Authorization Modules
-are configured, each is checked in sequence, and if any Module authorizes the request, 
-then the request can proceed.  If all deny the request, then the request is denied (HTTP status
-code 403).
+For example, if Bob has the policy below, then he can read pods only in the namespace `projectCaribou`:
 
-The [Authorization Modules](/docs/admin/authorization) page describes what authorization modules
-are available and how to configure them.    
+```json
+{
+    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
+    "kind": "Policy",
+    "spec": {
+        "user": "bob",
+        "namespace": "projectCaribou",
+        "resource": "pods",
+        "readonly": true
+    }
+}
+```
+If Bob makes the following request, the request is authorized because he is allowed to read objects in the `projectCaribou` namespace:
 
-For version 1.2, clusters created by `kube-up.sh` are configured so that no authorization is
-required for any request.
+```json
+{
+  "apiVersion": "authorization.k8s.io/v1beta1",
+  "kind": "SubjectAccessReview",
+  "spec": {
+    "resourceAttributes": {
+      "namespace": "projectCaribou",
+      "verb": "get",
+      "group": "unicorn.example.org",
+      "resource": "pods"
+    }
+  }
+}
+```
+If Bob makes a request to write (`create` or `update`) to the objects in the `projectCaribou` namespace, his authorization is denied. If Bob makes a request to read (`get`) objects in a different namespace such as `projectFish`, then his authorization is denied. 
 
-As of version 1.3, clusters created by `kube-up.sh` are configured so that the ABAC authorization
-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.
+Kubernetes authorization requires that you use common REST attributes to interact with existing organization-wide or cloud-provider-wide access control systems. It is important to use REST formatting because these control systems might interact with other APIs besides the Kubernetes API.
 
+Kubernetes supports multiple authorization modules, such as ABAC mode, RBAC Mode, and Webhook mode. When an administrator creates a cluster, they configured the authorization modules that should be used in the API server. If more than one authorization modules are configured, Kubernetes checks each module, and if any module authorizes the request, then the request can proceed. If all of the modules deny the request, then the request is denied (HTTP status code 403).
 
-The Authorization step is designed to operate on attributes that are likely to be common to most
-REST requests, such as object name, kind, etc.  This is intended to facilitate interation with
-existing organization-wide or cloud-provider-wide access control systems (which may handle
-other APIs besides the Kubernetes API).
+To learn more about Kubernetes authorization, including details about creating policies using the supported authorization modules, see [Authorization Overview](/docs/admin/authorization). 
 
-Access controls and policies that depend on specific fields of specific Kinds of objects
-are handled by Admission Controllers.
 
 ## Admission Control
 
@@ -108,7 +109,7 @@ They act on objects being created, deleted, updated or connected (proxy), but no
 
 Multiple admission controllers can be configured.  Each is called in order.
 
-This is shown as step **3** in the diagram. 
+This is shown as step **3** in the diagram.
 
 Unlike Authentication and Authorization Modules, if any admission controller module
 rejects, then the request is immediately rejected.
@@ -122,7 +123,7 @@ Once a request passes all admission controllers, it is validated using the valid
 for the corresponding API object, and then written to the object store (shown as step **4**).
 
 
-## API Server Ports and IPs 
+## API Server Ports and IPs
 
 The previous discussion applies to requests sent to the secure port of the API server
 (the typical case).  The API server can actually serve on 2 ports:
@@ -132,7 +133,7 @@ By default the Kubernetes API server serves HTTP on 2 ports:
   1. `Localhost Port`:
 
           - is intended for testing and bootstrap, and for other components of the master node
-	    (scheduler, controller-manager) to talk to the API
+            (scheduler, controller-manager) to talk to the API
           - no TLS
           - default is port 8080, change with `--insecure-port` flag.
           - defaults IP is localhost, change with `--insecure-bind-address` flag.
@@ -141,8 +142,8 @@ By default the Kubernetes API server serves HTTP on 2 ports:
           - protected by need to have host access
 
   2. `Secure Port`:
- 
-          - use whenever possible 
+
+          - use whenever possible
           - uses TLS.  Set cert with `--tls-cert-file` and key with `--tls-private-key-file` flag.
           - default is port 6443, change with `--secure-port` flag.
           - default IP is first non-localhost network interface, change with `--bind-address` flag.

docs/admin/addons.md

@@ -1,30 +0,0 @@
----
-title: Installing Addons
----
-
-## Overview
-
-Add-ons extend the functionality of Kubernetes.
-
-This page lists some of the available add-ons and links to their respective installation instructions.
-
-Add-ons in each section are sorted alphabetically - the ordering does not imply any preferential status.
-
-## Networking and Network Policy
-
-* [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 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.
-
-## Visualization & Control
-
-* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) is a dashboard web interface for Kubernetes.
-* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) is a tool for graphically visualizing your containers, pods, services etc. Use it in conjunction with a [Weave Cloud account](https://cloud.weave.works/) or host the UI yourself.
-
-## Legacy Add-ons
-
-There are several other add-ons documented in the deprecated [cluster/addons](https://github.com/kubernetes/kubernetes/tree/master/cluster/addons) directory.
-
-Well-maintained ones should be linked to here. PRs welcome!

docs/admin/admission-controllers.md

@@ -87,7 +87,7 @@ The ImagePolicyWebhook plug-in allows a backend webhook to make admission decisi
 ```
 
 #### Configuration File Format
-ImagePolicyWebhook uses the admission controller config file (`--admission-controller-config-file`) to set configuration options for the behavior of the backend. This file may be json or yaml and has the following format:
+ImagePolicyWebhook uses the admission config file `--admission-control-config-file` to set configuration options for the behavior of the backend. This file may be json or yaml and has the following format:
 
 ```javascript
 {
@@ -101,7 +101,7 @@ ImagePolicyWebhook uses the admission controller config file (`--admission-contr
 }
 ```
 
-The config file must reference a [kubeconfig](/docs/user-guide/kubeconfig-file/) formatted file which sets up the connection to the backend. It is required that the backend communicate over TLS.
+The config file must reference a [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) formatted file which sets up the connection to the backend. It is required that the backend communicate over TLS.
 
 The kubeconfig file's cluster field must point to the remote service, and the user field must contain the returned authorizer.
 
@@ -120,7 +120,7 @@ users:
     client-certificate: /path/to/cert.pem # cert for the webhook plugin to use
     client-key: /path/to/key.pem          # key matching the cert
 ```
-For additional HTTP configuration, refer to the [kubeconfig](/docs/user-guide/kubeconfig-file/) documentation.
+For additional HTTP configuration, refer to the [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) documentation.
 
 #### Request Payloads
 
@@ -197,7 +197,7 @@ We strongly recommend using this plug-in if you intend to make use of Kubernetes
 
 ### SecurityContextDeny
 
-This plug-in will deny any pod with a [SecurityContext](/docs/user-guide/security-context) that defines options that were not available on the `Container`.
+This plug-in will deny any pod that attempts to set certain escalating [SecurityContext](/docs/user-guide/security-context) fields. This should be enabled if a cluster doesn't utilize [pod security policies](/docs/user-guide/pod-security-policy) to restrict the set of values a security context can take.
 
 ### ResourceQuota
 
@@ -205,7 +205,7 @@ This plug-in will observe the incoming request and ensure that it does not viola
 enumerated in the `ResourceQuota` object in a `Namespace`.  If you are using `ResourceQuota`
 objects in your Kubernetes deployment, you MUST use this plug-in to enforce quota constraints.
 
-See the [resourceQuota design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/admission_control_resource_quota.md) and the [example of Resource Quota](/docs/admin/resourcequota/) for more details.
+See the [resourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/admission_control_resource_quota.md) and the [example of Resource Quota](/docs/concepts/policy/resource-quotas/) for more details.
 
 It is strongly encouraged that this plug-in is configured last in the sequence of admission control plug-ins.  This is
 so that quota is not prematurely incremented only for the request to be rejected later in admission control.
@@ -218,7 +218,7 @@ your Kubernetes deployment, you MUST use this plug-in to enforce those constrain
 be used to apply default resource requests to Pods that don't specify any; currently, the default LimitRanger
 applies a 0.1 CPU requirement to all Pods in the `default` namespace.
 
-See the [limitRange design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/admission_control_limit_range.md) and the [example of Limit Range](/docs/admin/limitrange/) for more details.
+See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/admission_control_limit_range.md) and the [example of Limit Range](/docs/tasks/configure-pod-container/limit-range/) for more details.
 
 ### InitialResources (experimental)
 
@@ -227,7 +227,7 @@ then the plug-in auto-populates a compute resource request based on historical u
 If there is not enough data to make a decision the Request is left unchanged.
 When the plug-in sets a compute resource request, it annotates the pod with information on what compute resources it auto-populated.
 
-See the [InitialResouces proposal](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/proposals/initial-resources.md) for more details.
+See the [InitialResouces proposal](https://git.k8s.io/community/contributors/design-proposals/initial-resources.md) for more details.
 
 ### NamespaceLifecycle
 
@@ -252,9 +252,67 @@ This plugin ignores any `PersistentVolumeClaim` updates, it acts only on creatio
 See [persistent volume](/docs/user-guide/persistent-volumes) documentation about persistent volume claims and
 storage classes and how to mark a storage class as default.
 
+### DefaultTolerationSeconds
+
+This plug-in sets the default forgiveness toleration for pods, which have no forgiveness tolerations, to tolerate
+the taints `notready:NoExecute` and `unreachable:NoExecute` for 5 minutes.
+
+### PodNodeSelector
+
+This plug-in defaults and limits what node selectors may be used within a namespace by reading a namespace annotation and a global configuration.
+
+#### Configuration File Format
+PodNodeSelector uses the admission config file `--admission-control-config-file` to set configuration options for the behavior of the backend.
+
+Note that the configuration file format will move to a versioned file in a future release.
+
+This file may be json or yaml and has the following format:
+
+```yaml
+podNodeSelectorPluginConfig:
+ clusterDefaultNodeSelector: <node-selectors-labels>
+ namespace1: <node-selectors-labels>
+ namespace2: <node-selectors-labels>
+```
+
+#### Configuration Annotation Format
+PodNodeSelector uses the annotation key `scheduler.alpha.kubernetes.io/node-selector` to assign node selectors to namespaces.
+
+```yaml
+apiVersion: v1
+kind: Namespace
+metadata:
+  annotations:
+    scheduler.alpha.kubernetes.io/node-selector: <node-selectors-labels>
+  name: namespace3
+```
+
+### PodSecurityPolicy
+
+This plug-in acts on creation and modification of the pod and determines if it should be admitted
+based on the requested security context and the available Pod Security Policies.
+
+For Kubernetes < 1.6.0, the API Server must enable the extensions/v1beta1/podsecuritypolicy API
+extensions group (`--runtime-config=extensions/v1beta1/podsecuritypolicy=true`).
+
+See also [Pod Security Policy documentation](/docs/concepts/policy/pod-security-policy/)
+for more information.
+
+### NodeRestriction
+
+This plug-in limits the `Node` and `Pod` objects a kubelet can modify. In order to be limited by this admission plugin,
+kubelets must use credentials in the `system:nodes` group, with a username in the form `system:node:<nodeName>`. 
+Such kubelets will only be allowed to modify their own `Node` API object, and only modify `Pod` API objects that are bound to their node.
+Future versions may add additional restrictions to ensure kubelets have the minimal set of permissions required to operate correctly.
+
 ## Is there a recommended set of plug-ins to use?
 
 Yes.
+For Kubernetes >= 1.6.0, we strongly recommend running the following set of admission control plug-ins (order matters):
+
+```shell
+--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds
+```
 
 For Kubernetes >= 1.4.0, we strongly recommend running the following set of admission control plug-ins (order matters):
 

docs/admin/apparmor/index.md

@@ -1,392 +0,0 @@
----
-assignees:
-- stclair
-title: AppArmor
----
-
-AppArmor is a Linux kernel enhancement that can reduce the potential attack surface of an
-application and provide greater defense in depth for Applications. Beta support for AppArmor was
-added in Kubernetes v1.4.
-
-* TOC
-{:toc}
-
-## What is AppArmor
-
-AppArmor is a Linux kernel security module that supplements the standard Linux user and group based
-permissions to confine programs to a limited set of resources. AppArmor can be configured for any
-application to reduce its potential attack surface and provide greater defense in depth. It is
-configured through profiles tuned to whitelist the access needed by a specific program or container,
-such as Linux capabilities, network access, file permissions, etc. Each profile can be run in either
-enforcing mode, which blocks access to disallowed resources, or complain mode, which only reports
-violations.
-
-AppArmor can help you to run a more secure deployment by restricting what containers are allowed to
-do, and /or providing better auditing through system logs. However, it is important to keep in mind
-that AppArmor is not a silver bullet, and can only do so much to protect against exploits in your
-application code. It is important to provide good, restrictive profiles, and harden your
-applications and cluster from other angles as well.
-
-AppArmor support in Kubernetes is currently in beta.
-
-## Prerequisites
-
-1. **Kubernetes version is at least v1.4**. Kubernetes support for AppArmor was added in
-   v1.4. Kubernetes components older than v1.4 are not aware of the new AppArmor annotations, and
-   will **silently ignore** any AppArmor settings that are provided. To ensure that your Pods are
-   receiving the expected protections, it is important to verify the Kubelet version of your nodes:
-
-        $ kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {@.status.nodeInfo.kubeletVersion}\n{end}'
-        gke-test-default-pool-239f5d02-gyn2: v1.4.0
-        gke-test-default-pool-239f5d02-x1kf: v1.4.0
-        gke-test-default-pool-239f5d02-xwux: v1.4.0
-
-2. **AppArmor kernel module is enabled**. For the Linux kernel to enforce an AppArmor profile, the
-   AppArmor kernel module must be installed and enabled. Several distributions enable the module by
-   default, such as Ubuntu and SUSE, and many others provide optional support. To check whether the
-   module is enabled, check the `/sys/module/apparmor/parameters/enabled` file:
-
-        $ cat /sys/module/apparmor/parameters/enabled
-        Y
-
-    If the Kubelet contains AppArmor support (>= v1.4), it will refuse to run a Pod with AppArmor
-    options if the kernel module is not enabled.
-
-    *Note: Ubuntu carries many AppArmor patches that have not been merged into the upstream Linux
-     kernel, including patches that add additional hooks and features. Kubernetes has only been
-     tested with the upstream version, and does not promise support for other features.*
-
-3. **Container runtime is Docker**. Currently the only Kubernetes-supported container runtime that
-   also supports AppArmor is Docker. As more runtimes add AppArmor support, the options will be
-   expanded. You can verify that your nodes are running docker with:
-
-        $ kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {@.status.nodeInfo.containerRuntimeVersion}\n{end}'
-        gke-test-default-pool-239f5d02-gyn2: docker://1.11.2
-        gke-test-default-pool-239f5d02-x1kf: docker://1.11.2
-        gke-test-default-pool-239f5d02-xwux: docker://1.11.2
-
-    If the Kubelet contains AppArmor support (>= v1.4), it will refuse to run a Pod with AppArmor
-    options if the runtime is not Docker.
-
-4. **Profile is loaded**. AppArmor is applied to a Pod by specifying an AppArmor profile that each
-   container should be run with. If any of the specified profiles is not already loaded in the
-   kernel, the Kubelet (>= v1.4) will reject the Pod. You can view which profiles are loaded on a
-   node by checking the `/sys/kernel/security/apparmor/profiles` file. For example:
-
-        $ ssh gke-test-default-pool-239f5d02-gyn2 "sudo cat /sys/kernel/security/apparmor/profiles | sort"
-        apparmor-test-deny-write (enforce)
-        apparmor-test-audit-write (enforce)
-        docker-default (enforce)
-        k8s-nginx (enforce)
-
-    For more details on loading profiles on nodes, see
-    [Setting up nodes with profiles](#setting-up-nodes-with-profiles).
-
-As long as the Kubelet version includes AppArmor support (>= v1.4), the Kubelet will reject a Pod
-with AppArmor options if any of the prerequisites are not met. You can also verify AppArmor support
-on nodes by checking the node ready condition message (though this is likely to be removed in a
-later release):
-
-    $ kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {.status.conditions[?(@.reason=="KubeletReady")].message}\n{end}'
-    gke-test-default-pool-239f5d02-gyn2: kubelet is posting ready status. AppArmor enabled
-    gke-test-default-pool-239f5d02-x1kf: kubelet is posting ready status. AppArmor enabled
-    gke-test-default-pool-239f5d02-xwux: kubelet is posting ready status. AppArmor enabled
-
-## Securing a Pod
-
-*Note: AppArmor is currently in beta, so options are specified as annotations. Once support graduates to
-general availability, the annotations will be replaced with first-class fields (more details in
-[Upgrade path to GA](#upgrade-path-to-general-availability)).*
-
-AppArmor profiles are specified *per-container*. To specify the AppArmor profile to run a Pod
-container with, add an annotation to the Pod's metadata:
-
-    container.apparmor.security.beta.kubernetes.io/<container_name>: <profile_ref>
-
-Where `<container_name>` is the name of the container to apply the profile to, and `<profile_ref>`
-specifies the profile to apply. The `profile_ref` can be one of:
-
-- `runtime/default` to apply the runtime's default profile.
-- `localhost/<profile_name>` to apply the profile loaded on the host with the name `<profile_name>`
-
-See the [API Reference](#api-reference) for the full details on the annotation and profile name formats.
-
-The Kubernetes AppArmor enforcement works by first checking that all the prerequisites have been
-met, and then forwarding the profile selection to the container runtime for enforcement. If the
-prerequisites have not been met, the Pod will be rejected, and will not run.
-
-To verify that the profile was applied, you can expect to see the AppArmor security option listed in the container created event:
-
-    $ kubectl get events | grep Created
-    22s        22s         1         hello-apparmor     Pod       spec.containers{hello}   Normal    Created     {kubelet e2e-test-stclair-minion-group-31nt}   Created container with docker id 269a53b202d3; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write]
-
-You can also verify directly that the container's root process is running with the correct profile by checking its proc attr:
-
-    $ kubectl exec <pod_name> cat /proc/1/attr/current
-    k8s-apparmor-example-deny-write (enforce)
-
-## Example
-
-In this example you'll see:
-
-- One way to load a profile on a node
-- How to enforce the profile on a Pod
-- How to check that the profile is loaded
-- What happens when a profile is violated
-- What happens when a profile cannot be loaded
-
-*This example assumes you have already set up a cluster with AppArmor support.*
-
-First, we need to load the profile we want to use onto our nodes. The profile we'll use simply
-denies all file writes:
-
-{% include code.html language="text" file="deny-write.profile" ghlink="/docs/admin/apparmor/deny-write.profile" %}
-
-Since we don't know where the Pod will be scheduled, we'll need to load the profile on all our
-nodes. For this example we'll just use SSH to install the profiles, but other approaches are
-discussed in [Setting up nodes with profiles](#setting-up-nodes-with-profiles).
-
-    $ NODES=(
-        # The SSH-accessible domain names of your nodes
-        gke-test-default-pool-239f5d02-gyn2.us-central1-a.my-k8s
-        gke-test-default-pool-239f5d02-x1kf.us-central1-a.my-k8s
-        gke-test-default-pool-239f5d02-xwux.us-central1-a.my-k8s)
-    $ for NODE in ${NODES[*]}; do ssh $NODE 'sudo apparmor_parser -q <<EOF
-    #include <tunables/global>
-
-    profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
-      #include <abstractions/base>
-
-      file,
-
-      # Deny all file writes.
-      deny /** w,
-    }
-    EOF'
-    done
-
-Next, we'll run a simple "Hello AppArmor" pod with the deny-write profile:
-
-{% include code.html language="yaml" file="hello-apparmor-pod.yaml" ghlink="/docs/admin/apparmor/hello-apparmor-pod.yaml" %}
-
-    $ kubectl create -f /dev/stdin <<EOF
-    apiVersion: v1
-    kind: Pod
-    metadata:
-      name: hello-apparmor
-      annotations:
-        container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write
-    spec:
-      containers:
-      - name: hello
-        image: busybox
-        command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
-    EOF
-    pod "hello-apparmor" created
-
-If we look at the pod events, we can see that the Pod container was created with the AppArmor
-profile "k8s-apparmor-example-deny-write":
-
-    $ kubectl get events | grep hello-apparmor
-    14s        14s         1         hello-apparmor   Pod                                Normal    Scheduled   {default-scheduler }                           Successfully assigned hello-apparmor to gke-test-default-pool-239f5d02-gyn2
-    14s        14s         1         hello-apparmor   Pod       spec.containers{hello}   Normal    Pulling     {kubelet gke-test-default-pool-239f5d02-gyn2}   pulling image "busybox"
-    13s        13s         1         hello-apparmor   Pod       spec.containers{hello}   Normal    Pulled      {kubelet gke-test-default-pool-239f5d02-gyn2}   Successfully pulled image "busybox"
-    13s        13s         1         hello-apparmor   Pod       spec.containers{hello}   Normal    Created     {kubelet gke-test-default-pool-239f5d02-gyn2}   Created container with docker id 06b6cd1c0989; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write]
-    13s        13s         1         hello-apparmor   Pod       spec.containers{hello}   Normal    Started     {kubelet gke-test-default-pool-239f5d02-gyn2}   Started container with docker id 06b6cd1c0989
-
-We can verify that the container is actually running with that profile by checking its proc attr:
-
-    $ kubectl exec hello-apparmor cat /proc/1/attr/current
-    k8s-apparmor-example-deny-write (enforce)
-
-Finally, we can see what happens if we try to violate the profile by writing to a file:
-
-    $ kubectl exec hello-apparmor touch /tmp/test
-    touch: /tmp/test: Permission denied
-    error: error executing remote command: command terminated with non-zero exit code: Error executing in Docker Container: 1
-
-To wrap up, let's look at what happens if we try to specify a profile that hasn't been loaded:
-
-    $ kubectl create -f /dev/stdin <<EOF
-    apiVersion: v1
-    kind: Pod
-    metadata:
-      name: hello-apparmor-2
-      annotations:
-        container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-allow-write
-    spec:
-      containers:
-      - name: hello
-        image: busybox
-        command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
-    EOF
-    pod "hello-apparmor-2" created
-    
-    $ kubectl describe pod hello-apparmor-2
-    Name:		hello-apparmor-2
-    Namespace:	default
-    Node:		gke-test-default-pool-239f5d02-x1kf/
-    Start Time:	Tue, 30 Aug 2016 17:58:56 -0700
-    Labels:		<none>
-    Status:		Failed
-    Reason:		AppArmor
-    Message:	Pod Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded
-    IP:		
-    Controllers:	<none>
-    Containers:
-      hello:
-        Image:	busybox
-        Port:	
-        Command:
-          sh
-          -c
-          echo 'Hello AppArmor!' && sleep 1h
-        Requests:
-          cpu:			100m
-        Environment Variables:	<none>
-    Volumes:
-      default-token-dnz7v:
-        Type:	Secret (a volume populated by a Secret)
-        SecretName:	default-token-dnz7v
-    QoS Tier:	Burstable
-    Events:
-      FirstSeen	LastSeen	Count	From						SubobjectPath	Type		Reason		Message
-      ---------	--------	-----	----						-------------	--------	------		-------
-      23s		23s		1	{default-scheduler }						Normal		Scheduled	Successfully assigned hello-apparmor-2 to e2e-test-stclair-minion-group-t1f5
-      23s		23s		1	{kubelet e2e-test-stclair-minion-group-t1f5}			Warning		AppArmor	Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded
-
-Note the pod status is Failed, with a helpful error message: `Pod Cannot enforce AppArmor: profile
-"k8s-apparmor-example-allow-write" is not loaded`. An event was also recorded with the same message.
-
-## Administration
-
-### Setting up nodes with profiles
-
-Kubernetes does not currently provide any native mechanisms for loading AppArmor profiles onto
-nodes. There are lots of ways to setup the profiles though, such as:
-
-- Through a [DaemonSet](../daemons/) that runs a Pod on each node to
-  ensure the correct profiles are loaded. An example implementation can be found
-  [here](https://github.com/kubernetes/contrib/tree/master/apparmor/loader).
-- At node initialization time, using your node initialization scripts (e.g. Salt, Ansible, etc.) or
-  image.
-- By copying the profiles to each node and loading them through SSH, as demonstrated in the
-  [Example](#example).
-
-The scheduler is not aware of which profiles are loaded onto which node, so the full set of profiles
-must be loaded onto every node.  An alternative approach is to add a node label for each profile (or
-class of profiles) on the node, and use a
-[node selector](../../user-guide/node-selection/) to ensure the Pod is run on a
-node with the required profile.
-
-### Restricting profiles with the PodSecurityPolicy
-
-If the PodSecurityPolicy extension is enabled, cluster-wide AppArmor restrictions can be applied. To
-enable the PodSecurityPolicy, two flags must be set on the `apiserver`:
-
-    --admission-control=PodSecurityPolicy[,others...]
-    --runtime-config=extensions/v1beta1/podsecuritypolicy[,others...]
-
-With the extension enabled, the AppArmor options can be specified as annotations on the PodSecurityPolicy:
-
-    apparmor.security.beta.kubernetes.io/defaultProfileName: <profile_ref>
-    apparmor.security.beta.kubernetes.io/allowedProfileNames: <profile_ref>[,others...]
-
-The default profile name option specifies the profile to apply to containers by default when none is
-specified. The allowed profile names option specifies a list of profiles that Pod containers are
-allowed to be run with. If both options are provided, the default must be allowed. The profiles are
-specified in the same format as on containers. See the [API Reference](#api-reference) for the full
-specification.
-
-### Disabling AppArmor
-
-If you do not want AppArmor to be available on your cluster, it can be disabled by a command-line flag:
-
-    --feature-gates=AppArmor=false
-
-When disabled, any Pod that includes an AppArmor profile will fail validation with a "Forbidden"
-error. Note that by default docker always enables the "docker-default" profile on non-privileged
-pods (if the AppArmor kernel module is enabled), and will continue to do so even if the feature-gate
-is disabled. The option to disable AppArmor will be removed when AppArmor graduates to general
-availability (GA).
-
-### Upgrading to Kubernetes v1.4 with AppArmor
-
-No action is required with respect to AppArmor to upgrade your cluster to v1.4. However, if any
-existing pods had an AppArmor annotation, they will not go through validation (or PodSecurityPolicy
-admission). If permissive profiles are loaded on the nodes, a malicious user could pre-apply a
-permissive profile to escalate the pod privileges above the docker-default. If this is a concern, it
-is recommended to scrub the cluster of any pods containing an annotation with
-`apparmor.security.beta.kubernetes.io`.
-
-### Upgrade path to General Availability
-
-When AppArmor is ready to be graduated to general availability (GA), the options currently specified
-through annotations will be converted to fields. Supporting all the upgrade and downgrade paths
-through the transition is very nuanced, and will be explained in detail when the transition
-occurs. We will commit to supporting both fields and annotations for at least 2 releases, and will
-explicitly reject the annotations for at least 2 releases after that.
-
-## Authoring Profiles
-
-Getting AppArmor profiles specified correctly can be a tricky business. Fortunately there are some
-tools to help with that:
-
-- `aa-genprof` and `aa-logprof` generate profile rules by monitoring an application's activity and
-  logs, and admitting the actions it takes. Further instructions are provided by the
-  [AppArmor documentation](http://wiki.apparmor.net/index.php/Profiling_with_tools).
-- [bane](https://github.com/jfrazelle/bane) is an AppArmor profile generator for Docker that uses a
-  simplified profile language.
-
-It is recommended to run your application through Docker on a development workstation to generate
-the profiles, but there is nothing preventing running the tools on the Kubernetes node where your
-Pod is running.
-
-To debug problems with AppArmor, you can check the system logs to see what, specifically, was
-denied. AppArmor logs verbose messages to `dmesg`, and errors can usually be found in the system
-logs or through `journalctl`. More information is provided in
-[AppArmor failures](http://wiki.apparmor.net/index.php/AppArmor_Failures).
-
-Additional resources:
-
-- [Quick guide to the AppArmor profile language](http://wiki.apparmor.net/index.php/QuickProfileLanguage)
-- [AppArmor core policy reference](http://wiki.apparmor.net/index.php/ProfileLanguage)
-
-## API Reference
-
-**Pod Annotation**:
-
-Specifying the profile a container will run with:
-
-- **key**: `container.apparmor.security.beta.kubernetes.io/<container_name>`
-  Where `<container_name>` matches the name of a container in the Pod.
-  A separate profile can be specified for each container in the Pod.
-- **value**: a profile reference, described below
-
-**Profile Reference**:
-
-- `runtime/default`: Refers to the default runtime profile.
-  - Equivalent to not specifying a profile (without a PodSecurityPolicy default), except it still
-    requires AppArmor to be enabled.
-  - For Docker, this resolves to the
-    [`docker-default`](https://docs.docker.com/engine/security/apparmor/) profile for non-privileged
-    containers, and unconfined (no profile) for privileged containers.
-- `localhost/<profile_name>`: Refers to a profile loaded on the node (localhost) by name.
-  - The possible profile names are detailed in the
-    [core policy reference](http://wiki.apparmor.net/index.php/AppArmor_Core_Policy_Reference#Profile_names_and_attachment_specifications)
-
-Any other profile reference format is invalid.
-
-**PodSecurityPolicy Annotations**
-
-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 is allowed to specify:
-
-- **key**: `apparmor.security.beta.kubernetes.io/allowedProfileNames`
-- **value**: a comma-separated list of profile references (described above)
-  - Although an escaped comma is a legal character in a profile name, it cannot be explicitly
-    allowed here

docs/admin/audit.md

@@ -1,67 +0,0 @@
----
-assignees:
-- soltysh
-- sttts
-title: Audit in Kubernetes
----
-
-* TOC
-{:toc}
-
-Kubernetes Audit provides a security-relevant chronological set of records documenting
-the sequence of activities that have affected system by individual users, administrators
-or other components of the system. It allows cluster administrator to
-answer the following questions:
-    - what happened?
-    - when did it happen?
-    - who initiated it?
-    - on what did it happen?
-    - where was it observed?
-    - from where was it initiated?
-    - to where was it going?
-
-NOTE: Currently, Kubernetes provides only basic audit capabilities, there is still a lot
-of work going on to provide fully featured auditing capabilities (see [this issue](https://github.com/kubernetes/features/issues/22)).
-
-Kubernetes audit is part of [kube-apiserver](/docs/admin/kube-apiserver) logging all requests
-coming to the server. Each audit log contains two entries:
-
-1. The request line containing:
-    - unique id allowing to match the response line (see 2)
-    - source ip of the request
-    - HTTP method being invoked
-    - original user invoking the operation
-    - impersonated user for the operation
-    - namespace of the request or <none>
-    - URI as requested
-2. The response line containing:
-    - the unique id from 1
-    - response code
-
-Example output for user `admin` asking for a list of pods:
-
-```
-2016-09-07T13:03:57.400333046Z AUDIT: id="5c3b8227-4af9-4322-8a71-542231c3887b" ip="127.0.0.1" method="GET" user="admin" as="<self>" namespace="default" uri="/api/v1/namespaces/default/pods"
-2016-09-07T13:03:57.400710987Z AUDIT: id="5c3b8227-4af9-4322-8a71-542231c3887b" response="200"
-```
-
-NOTE: The audit capabilities are available *only* for the secured endpoint of the API server.
-
-## Configuration
-
-[Kube-apiserver](/docs/admin/kube-apiserver) provides following options which are responsible
-for configuring where and how audit logs are handled:
-
-- `audit-log-path` - enables the audit log pointing to a file where the requests are being logged to.
-- `audit-log-maxage` - specifies maximum number of days to retain old audit log files based on the timestamp encoded in their filename.
-- `audit-log-maxbackup` - specifies maximum number of old audit log files to retain.
-- `audit-log-maxsize` - specifies maximum size in megabytes of the audit log file before it gets rotated. Defaults to 100MB
-
-If an audit log file already exists, Kubernetes appends new audit logs to that file.
-Otherwise, Kubernetes creates an audit log file at the location you specified in
-`audit-log-path`. If the audit log file exceeds the size you specify in `audit-log-maxsize`,
-Kubernetes will rename the current log file by appending the current timestamp on
-the file name (before the file extension) and create a new audit log file.
-Kubernetes may delete old log files when creating a new log file; you can configure
-how many files are retained and how old they can be by specifying the `audit-log-maxbackup`
-and `audit-log-maxage` options.

docs/admin/authentication.md

@@ -54,7 +54,7 @@ You can enable multiple authentication methods at once. You should usually use a
  - service account tokens for service accounts
  - at least one other method for user authentication.
 
-When multiple are enabled, the first authenticator module
+When multiple authenticator modules are enabled, the first module
 to successfully authenticate the request short-circuits evaluation.
 The API server does not guarantee the order authenticators run in.
 
@@ -85,9 +85,9 @@ See [APPENDIX](#appendix) for how to generate a client cert.
 The API server reads bearer tokens from a file when given the `--token-auth-file=SOMEFILE` option on the command line.  Currently, tokens last indefinitely, and the token list cannot be
 changed without restarting API server.
 
-The token file format is implemented in `plugin/pkg/auth/authenticator/token/tokenfile/...`
-and is a csv file with a minimum of 3 columns: token, user name, user uid, followed by
-optional group names. Note, if you have more than one group the column must be double quoted e.g.
+The token file is a csv file with a minimum of 3 columns: token, user name, user uid,
+followed by optional group names. Note, if you have more than one group the column must be
+double quoted e.g.
 
 ```conf
 token,user,uid,"group1,group2,group3"
@@ -107,6 +107,41 @@ header as shown below.
 Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269
 ```
 
+### Bootstrap Tokens
+
+This feature is currently in **alpha**.
+
+To allow for streamlined bootstrapping for new clusters, Kubernetes includes a
+dynamically-managed Bearer token type called a *Bootstrap Token*. These tokens
+are stored as Secrets in the `kube-system` namespace, where they can be
+dynamically managed and created. Controller Manager contains a TokenCleaner
+controller that deletes bootstrap tokens as they expire.
+
+The tokens are of the form `[a-z0-9]{6}.[a-z0-9]{16}`.  The first component is a
+Token ID and the second component is the Token Secret.  You specify the token
+in an HTTP header as follows:
+
+```http
+Authorization: Bearer 781292.db7bc3a58fc5f07e
+```
+
+You must enable the Bootstrap Token Authenticator with the
+`--experimental-bootstrap-token-auth` flag on the API Server.  You must enable
+the TokenCleaner controller via the `--controllers` flag on the Controller
+Manager.  This is done with something like `--controllers=*,tokencleaner`.
+`kubeadm` will do this for you if you are using it to bootstrapping a cluster.
+
+The authenticator authenticates as `system:bootstrap:<Token ID>`.  It is
+included in the `system:bootstrappers` group.  The naming and groups are
+intentionally limited to discourage users from using these tokens past
+bootstrapping.  The user names and group can be used (and are used by `kubeadm`)
+to craft the appropriate authorization policies to support bootstrapping a
+cluster.
+
+Please see [Bootstrap Tokens](/docs/admin/bootstrap-tokens/) for in depth
+documentation on the Bootstrap Token authenticator and controllers along with
+how to manage these tokens with `kubeadm`.
+
 ### Static Password File
 
 Basic authentication is enabled by passing the `--basic-auth-file=SOMEFILE`
@@ -115,9 +150,10 @@ and the password cannot be changed without restarting API server. Note that basi
 authentication is currently supported for convenience while we finish making the
 more secure modes described above easier to use.
 
-The basic auth file format is implemented in `plugin/pkg/auth/authenticator/password/passwordfile/...`
-and is a csv file with a minimum of 3 columns: password, user name, user id, followed by
-optional group names. Note, if you have more than one group the column must be double quoted e.g.
+The basic auth file is a csv file with a minimum of 3 columns: password, user name, user id.
+In Kubernetes version 1.6 and later, you can specify an optional fourth column containing
+comma-separated group names. If you have more than one group, you must enclose the fourth
+column value in double quotes ("). See the following example:
 
 ```conf
 password,user,uid,"group1,group2,group3"
@@ -145,7 +181,7 @@ talk to the API server. Accounts may be explicitly associated with pods using th
 NOTE: `serviceAccountName` is usually omitted because this is done automatically.
 
 ```
-apiVersion: extensions/v1beta1
+apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
   name: nginx-deployment
@@ -250,11 +286,21 @@ To enable the plugin, configure the following flags on the API server:
 
 | Parameter | Description | Example | Required |
 | --------- | ----------- | ------- | ------- |
-| --oidc-issuer-url | URL of the provider which allows the API server to discover public signing keys. Only URLs which use the `https://` scheme are accepted.  This is typically the provider's discovery URL without a path, for example "https://accounts.google.com" or "https://login.salesforce.com".  This URL should point to the level below .well-known/openid-configuration | If the discovery URL is https://accounts.google.com/.well-known/openid-configuration the value should be https://accounts.google.com | Yes |
-| --oidc-client-id |  A client id that all tokens must be issued for. | kubernetes | Yes |
-| --oidc-username-claim | JWT claim to use as the user name. By default `sub`, which is expected to be a unique identifier of the end user. Admins can choose other claims, such as `email`, depending on their provider. | sub | No |
-| --oidc-groups-claim | JWT claim to use as the user's group. If the claim is present it must be an array of strings. | groups | No |
-| --oidc-ca-file | The path to the certificate for the CA that signed your identity provider's web certificate.  Defaults to the host's root CAs. | `/etc/kubernetes/ssl/kc-ca.pem` | No |
+| `--oidc-issuer-url` | URL of the provider which allows the API server to discover public signing keys. Only URLs which use the `https://` scheme are accepted.  This is typically the provider's discovery URL without a path, for example "https://accounts.google.com" or "https://login.salesforce.com".  This URL should point to the level below .well-known/openid-configuration | If the discovery URL is https://accounts.google.com/.well-known/openid-configuration the value should be https://accounts.google.com | Yes |
+| `--oidc-client-id` |  A client id that all tokens must be issued for. | kubernetes | Yes |
+| `--oidc-username-claim` | JWT claim to use as the user name. By default `sub`, which is expected to be a unique identifier of the end user. Admins can choose other claims, such as `email` or `name`, depending on their provider. However, claims other than `email` will be prefixed with the issuer URL to prevent naming clashes with other plugins. | sub | No |
+| `--oidc-groups-claim` | JWT claim to use as the user's group. If the claim is present it must be an array of strings. | groups | No |
+| `--oidc-ca-file` | The path to the certificate for the CA that signed your identity provider's web certificate.  Defaults to the host's root CAs. | `/etc/kubernetes/ssl/kc-ca.pem` | No |
+
+If a claim other than `email` is chosen for `--oidc-username-claim`, the value
+will be prefixed with the `--oidc-issuer-url` to prevent clashes with existing
+Kubernetes names (such as the `system:` users). For example, if the provider
+URL is `https://accounts.google.com` and the username claim maps to `jane`, the
+plugin will authenticate the user as:
+
+```
+https://accounts.google.com#jane
+```
 
 Importantly, the API server is not an OAuth2 client, rather it can only be
 configured to trust a single issuer. This allows the use of public providers,
@@ -289,13 +335,14 @@ The first option is to use the `oidc` authenticator.  This authenticator takes y
 
 ```bash
 kubectl config set-credentials USER_NAME \
-   --auth-provider=oidc
+   --auth-provider=oidc \
    --auth-provider-arg=idp-issuer-url=( issuer url ) \
    --auth-provider-arg=client-id=( your client id ) \
    --auth-provider-arg=client-secret=( your client secret ) \
    --auth-provider-arg=refresh-token=( your refresh token ) \
    --auth-provider-arg=idp-certificate-authority=( path to your ca certificate ) \
-   --auth-provider-arg=id-token=( your id_token )
+   --auth-provider-arg=id-token=( your id_token ) \
+   --auth-provider-arg=extra-scopes=( comma separated list of scopes to add to "openid email profile", optional )
 ```
 
 As an example, running the below command after authenticating to your identity provider:
@@ -308,6 +355,7 @@ kubectl config set-credentials mmosley  \
         --auth-provider-arg=client-secret=1db158f6-177d-4d9c-8a8b-d36869918ec5  \
         --auth-provider-arg=refresh-token=q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMm0zEiPKTUwME6BkEo6Sql5yUWVBSWpKUGphaWpxSVAfekBOZbBhaEW+VlFUeVRGcluyVF5JT4+haZmPsluFoFu5XkpXk5BXqHega4GAXlF+ma+vmYpFcHe5eZR+slBFpZKtQA= \
         --auth-provider-arg=idp-certificate-authority=/root/ca.pem \
+        --auth-provider-arg=extra-scopes=groups \
         --auth-provider-arg=id-token=eyJraWQiOiJDTj1vaWRjaWRwLnRyZW1vbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2VjdXJpdHksIEw9QXJsaW5ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DTj1rdWJlLWNhLTEyMDIxNDc5MjEwMzYwNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJlbW9sby5sYW46ODQ0My9hdXRoL2lkcC9PaWRjSWRQIiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ4MzU0OTUxMSwianRpIjoiMm96US15TXdFcHV4WDlHZUhQdy1hZyIsImlhdCI6MTQ4MzU0OTQ1MSwibmJmIjoxNDgzNTQ5MzMxLCJzdWIiOiI0YWViMzdiYS1iNjQ1LTQ4ZmQtYWIzMC0xYTAxZWU0MWUyMTgifQ.w6p4J_6qQ1HzTG9nrEOrubxIMb9K5hzcMPxc9IxPx2K4xO9l-oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeA0tW_p-mnkFc3VcfyXuhe5R3G7aa5d8uHv70yJ9Y3-UhjiN9EhpMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkT4DfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbObJ9af71EwmuE21fO5KzMW20KtAeget1gnldOosPtz1G5EwvaQ401-RPQzPGMVBld0_zMCAwZttJ4knw
 ```
 
@@ -321,6 +369,7 @@ users:
       config:
         client-id: kubernetes
         client-secret: 1db158f6-177d-4d9c-8a8b-d36869918ec5
+        extra-scopes: groups
         id-token: eyJraWQiOiJDTj1vaWRjaWRwLnRyZW1vbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2VjdXJpdHksIEw9QXJsaW5ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DTj1rdWJlLWNhLTEyMDIxNDc5MjEwMzYwNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJlbW9sby5sYW46ODQ0My9hdXRoL2lkcC9PaWRjSWRQIiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ4MzU0OTUxMSwianRpIjoiMm96US15TXdFcHV4WDlHZUhQdy1hZyIsImlhdCI6MTQ4MzU0OTQ1MSwibmJmIjoxNDgzNTQ5MzMxLCJzdWIiOiI0YWViMzdiYS1iNjQ1LTQ4ZmQtYWIzMC0xYTAxZWU0MWUyMTgifQ.w6p4J_6qQ1HzTG9nrEOrubxIMb9K5hzcMPxc9IxPx2K4xO9l-oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeA0tW_p-mnkFc3VcfyXuhe5R3G7aa5d8uHv70yJ9Y3-UhjiN9EhpMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkT4DfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbObJ9af71EwmuE21fO5KzMW20KtAeget1gnldOosPtz1G5EwvaQ401-RPQzPGMVBld0_zMCAwZttJ4knw
         idp-certificate-authority: /root/ca.pem
         idp-issuer-url: https://oidcidp.tremolo.lan:8443/auth/idp/OidcIdP
@@ -346,7 +395,7 @@ Webhook authentication is a hook for verifying bearer tokens.
 * `--authentication-token-webhook-config-file` a kubeconfig file describing how to access the remote webhook service.
 * `--authentication-token-webhook-cache-ttl` how long to cache authentication decisions. Defaults to two minutes.
 
-The configuration file uses the [kubeconfig](/docs/user-guide/kubeconfig-file/)
+The configuration file uses the [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
 file format. Within the file "users" refers to the API server webhook and
 "clusters" refers to the remote service. An example would be:
 
@@ -446,11 +495,45 @@ HTTP status codes can be used to supply additional error context.
 
 The API server can be configured to identify users from request header values, such as `X-Remote-User`.
 It is designed for use in combination with an authenticating proxy, which sets the request header value.
+
+* `--requestheader-username-headers` Required, case-insensitive. Header names to check, in order, for the user identity. The first header containing a value is used as the username.
+* `--requestheader-group-headers` 1.6+. Optional, case-insensitive. "X-Remote-Group" is suggested. Header names to check, in order, for the user's groups. All values in all specified headers are used as group names.
+* `--requestheader-extra-headers-prefix` 1.6+. Optional, case-insensitive. "X-Remote-Extra-" is suggested. Header prefixes to look for to determine extra information about the user (typically used by the configured authorization plugin). Any headers beginning with any of the specified prefixes have the prefix removed, the remainder of the header name becomes the extra key, and the header value is the extra value.
+
+For example, with this configuration:
+```
+--requestheader-username-headers=X-Remote-User
+--requestheader-group-headers=X-Remote-Group
+--requestheader-extra-headers-prefix=X-Remote-Extra-
+```
+
+this request:
+```
+GET / HTTP/1.1
+X-Remote-User: fido
+X-Remote-Group: dogs
+X-Remote-Group: dachshunds
+X-Remote-Extra-Scopes: openid
+X-Remote-Extra-Scopes: profile
+```
+
+would result in this user info:
+```yaml
+name: fido
+groups:
+- dogs
+- dachshunds
+extra:
+  scopes:
+  - openid
+  - profile
+```
+
+
 In order to prevent header spoofing, the authenticating proxy is required to present a valid client
 certificate to the API server for validation against the specified CA before the request headers are
 checked.
 
-* `--requestheader-username-headers` Required, case-insensitive. Header names to check, in order, for the user identity. The first header containing a value is used as the identity.
 * `--requestheader-client-ca-file` Required. PEM-encoded certificate bundle. A valid client certificate must be presented and validated against the certificate authorities in the specified file before the request headers are checked for user names.
 * `--requestheader-allowed-names` Optional.  List of common names (cn). If set, a valid client certificate with a Common Name (cn) in the specified list must be presented before the request headers are checked for user names. If empty, any Common Name is allowed.
 
@@ -480,9 +563,6 @@ changes](https://github.com/kubernetes/kubernetes/pull/25536) for more details.
 
 ## Anonymous requests
 
-Anonymous access is enabled by default, and can be disabled by passing `--anonymous-auth=false`
-option to the API server during startup.
-
 When enabled, requests that are not rejected by other configured authentication methods are
 treated as anonymous requests, and given a username of `system:anonymous` and a group of
 `system:unauthenticated`.
@@ -491,8 +571,119 @@ For example, on a server with token authentication configured, and anonymous acc
 a request providing an invalid bearer token would receive a `401 Unauthorized` error.
 A request providing no bearer token would be treated as an anonymous request.
 
-If you rely on authentication alone to authorize access, either change to use an
-authorization mode other than `AlwaysAllow`, or set `--anonymous-auth=false`.
+In 1.5.1-1.5.x, anonymous access is disabled by default, and can be enabled by
+passing the `--anonymous-auth=false` option to the API server.
+
+In 1.6+, anonymous access is enabled by default if an authorization mode other than `AlwaysAllow`
+is used, and can be disabled by passing the `--anonymous-auth=false` option to the API server.
+Starting in 1.6, the ABAC and RBAC authorizers require explicit authorization of the
+`system:anonymous` user or the `system:unauthenticated` group, so legacy policy rules
+that grant access to the `*` user or `*` group do not include anonymous users.
+
+## User impersonation
+
+A user can act as another user through impersonation headers. These let requests
+manually override the user info a request authenticates as. For example, an admin
+could use this feature to debug an authorization policy by temporarily
+impersonating another user and seeing if a request was denied.
+
+Impersonation requests first authenticate as the requesting user, then switch
+to the impersonated user info.
+
+* A user makes an API call with their credentials _and_ impersonation headers.
+* API server authenticates the user.
+* API server ensures the authenticated users has impersonation privileges.
+* Request user info is replaced with impersonation values.
+* Request is evaluated, authorization acts on impersonated user info.
+
+The following HTTP headers can be used to performing an impersonation request:
+
+* `Impersonate-User`: The username to act as.
+* `Impersonate-Group`: A group name to act as. Can be provided multiple times to set multiple groups. Optional. Requires "Impersonate-User"
+* `Impersonate-Extra-( extra name )`: A dynamic header used to associate extra fields with the user. Optional. Requires "Impersonate-User"
+
+An example set of headers:
+
+```http
+Impersonate-User: jane.doe@example.com
+Impersonate-Group: developers
+Impersonate-Group: admins
+Impersonate-Extra-dn: cn=jane,ou=engineers,dc=example,dc=com
+Impersonate-Extra-scopes: view
+Impersonate-Extra-scopes: development
+```
+
+When using `kubectl` set the `--as` flag to configure the `Impersonate-User`
+header, set the `--as-group` flag to configure the `Impersonate-Group` header.
+
+```shell
+$ kubectl drain mynode
+Error from server (Forbidden): User "clark" cannot get nodes at the cluster scope. (get nodes mynode)
+
+$ kubectl drain mynode --as=superman --as-group=system:masters
+node "mynode" cordoned
+node "mynode" drained
+```
+
+To impersonate a user, group, or set extra fields, the impersonating user must
+have the ability to perform the "impersonate" verb on the kind of attribute
+being impersonated ("user", "group", etc.). For clusters that enable the RBAC
+authorization plugin, the following ClusterRole encompasses the rules needed to
+set user and group impersonation headers:
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1beta1
+kind: ClusterRole
+metadata:
+  name: impersonator
+rules:
+- apiGroups: [""]
+  resources: ["users", "groups", "serviceaccounts"]
+  verbs: ["impersonate"]
+```
+
+Extra fields are evaluated as sub-resources of the resource "userextras". To
+allow a user to use impersonation headers for the extra field "scopes," a user
+should be granted the following role:
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1beta1
+kind: ClusterRole
+metadata:
+  name: scopes-impersonator
+# Can set "Impersonate-Extra-scopes" header.
+- apiGroups: ["authentication.k8s.io"]
+  resources: ["userextras/scopes"]
+  verbs: ["impersonate"]
+```
+
+The values of impersonation headers can also be restricted by limiting the set
+of `resourceNames` a resource can take.
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1beta1
+kind: ClusterRole
+metadata:
+  name: limited-impersonator
+rules:
+# Can impersonate the user "jane.doe@example.com"
+- apiGroups: [""]
+  resources: ["users"]
+  verbs: ["impersonate"]
+  resourceNames: ["jane.doe@example.com"]
+
+# Can impersonate the groups "developers" and "admins"
+- apiGroups: [""]
+  resources: ["groups"]
+- verbs: ["impersonate"]
+  resourceNames: ["developers","admins"]
+
+# Can impersonate the extras field "scopes" with the values "view" and "development"
+- apiGroups: ["authentication.k8s.io"]
+  resources: ["userextras/scopes"]
+  verbs: ["impersonate"]
+  resourceNames: ["view", "development"]
+```
 
 ## Plugin Development
 
@@ -512,7 +703,7 @@ using an existing deployment script or manually through `easyrsa` or `openssl.`
 #### Using an Existing Deployment Script
 
 **Using an existing deployment script** is implemented at
-`cluster/saltbase/salt/generate-cert/make-ca-cert.sh`.  
+`cluster/saltbase/salt/generate-cert/make-ca-cert.sh`.
 
 Execute this script with two parameters. The first is the IP address
 of API server. The second is a list of subject alternate names in the form `IP:<ip-address> or DNS:<dns-name>`.
@@ -541,8 +732,8 @@ Finally, add the following parameters into API server start parameters:
 1.  Generate server certificate and key.
     (build-server-full [filename]: Generate a keypair and sign locally for a client or server)
 
-          ./easyrsa --subject-alt-name="IP:${MASTER_IP}" build-server-full kubernetes-master nopass
-1.  Copy `pki/ca.crt`, `pki/issued/kubernetes-master.crt`, and `pki/private/kubernetes-master.key` to your directory.
+          ./easyrsa --subject-alt-name="IP:${MASTER_IP}" build-server-full server nopass
+1.  Copy `pki/ca.crt`, `pki/issued/server.crt`, and `pki/private/server.key` to your directory.
 1.  Fill in and add the following parameters into the API server start parameters:
 
           --client-ca-file=/yourdirectory/ca.crt
@@ -573,3 +764,9 @@ Finally, add the following parameters into API server start parameters:
           openssl x509  -noout -text -in ./server.crt
 
 Finally, do not forget to fill out and add the same parameters into the API server start parameters.
+
+#### Certificates API
+
+You can use the `certificates.k8s.io` API to provision
+x509 certificates to use for authentication as documented
+[here](/docs/tasks/tls/managing-tls-in-a-cluster).

docs/admin/authorization.md

@@ -1,662 +0,0 @@
----
-assignees:
-- erictune
-- lavalamp
-- deads2k
-- liggitt
-title: Using Authorization Plugins
----
-
-In Kubernetes, authorization happens as a separate step from authentication.
-See the [Accessing Control Overview](/docs/admin/accessing-the-api/) for an
-overview of how authentication and authorization are applied to requests.
-
-Authorization applies to all HTTP accesses on the main (secure) apiserver port.
-
-The authorization check for any request compares attributes of the context of
-the request, (such as user, resource, and namespace) with access
-policies.  An API call must be allowed by some policy in order to proceed.
-
-The following implementations are available, and are selected by flag:
-
-  - `--authorization-mode=AlwaysDeny` blocks all requests (used in tests).
-  - `--authorization-mode=AlwaysAllow` allows all requests; use if you don't
-need authorization.
-  - `--authorization-mode=ABAC` allows for a simple local-file-based user-configured
-authorization policy.  ABAC stands for Attribute-Based Access Control.
-authorization policy.
-  - `--authorization-mode=RBAC` is an experimental implementation which allows
-for authorization to be driven by the Kubernetes API.
-RBAC stands for Roles-Based Access Control.
-  - `--authorization-mode=Webhook` allows for authorization to be driven by a
-remote service using REST.
-
-If multiple modes are provided the set is unioned, and only a single authorizer is required to admit the action.  This means the flag:
-
-```
---authorization-mode=AlwaysDeny,AlwaysAllow
-```
-
-will always allow.
-
-## Request Attributes
-
-A request has the following attributes that can be considered for authorization:
-
-  - user (the user-string which a user was authenticated as).
-  - group (the list of group names the authenticated user is a member of).
-  - "extra" (a map of arbitrary string keys to string values, provided by the authentication layer)
-  - whether the request is for an API resource.
-  - the request path.
-    - allows authorizing access to miscellaneous non-resource endpoints like `/api` or `/healthz` (see [kubectl](#kubectl)).
-  - the request verb.
-    - API verbs `get`, `list`, `create`, `update`, `patch`, `watch`, `proxy`, `redirect`, `delete`, and `deletecollection` are used for resource requests
-    - HTTP verbs `get`, `post`, `put`, and `delete` are used for non-resource requests
-  - what resource is being accessed (for resource requests only)
-  - what subresource is being accessed (for resource requests only)
-  - the namespace of the object being accessed (for namespaced resource requests only)
-  - the API group being accessed (for resource requests only); an empty string designates the [core API group](/docs/api/)
-
-The request verb for a resource API endpoint can be determined by the HTTP verb used and whether or not the request acts on an individual resource or a collection of resources:
-
-HTTP verb | request verb
-----------|---------------
-POST      | create
-GET, HEAD | get (for individual resources), list (for collections)
-PUT       | update
-PATCH     | patch
-DELETE    | delete (for individual resources), deletecollection (for collections)
-
-
-## ABAC Mode
-
-### Policy File Format
-
-For mode `ABAC`, also specify `--authorization-policy-file=SOME_FILENAME`.
-
-The file format is [one JSON object per line](http://jsonlines.org/).  There
-should be no enclosing list or map, just one map per line.
-
-Each line is a "policy object".  A policy object is a map with the following
-properties:
-
-  - Versioning properties:
-    - `apiVersion`, type string; valid values are "abac.authorization.kubernetes.io/v1beta1". Allows versioning and conversion of the policy format.
-    - `kind`, type string: valid values are "Policy". Allows versioning and conversion of the policy format.
-  - `spec` property set to a map with the following properties:
-    - Subject-matching properties:
-      - `user`, type string; the user-string from `--token-auth-file`. If you specify `user`, it must match the username of the authenticated user.
-      - `group`, type string; if you specify `group`, it must match one of the groups of the authenticated user. `system:authenticated` matches all authenticated requests. `system:unauthenticated` matches all unauthenticated requests.
-    - `readonly`, type boolean, when true, means that the policy only applies to get, list, and watch operations.
-    - Resource-matching properties:
-      - `apiGroup`, type string; an API group, such as `extensions`. `*` matches all API groups.
-      - `namespace`, type string; a namespace string. `*` matches all resource requests.
-      - `resource`, type string; a resource, such as `pods`. `*` matches all resource requests.
-    - Non-resource-matching properties:
-    - `nonResourcePath`, type string; matches the non-resource request paths (like `/version` and `/apis`). `*` matches all non-resource requests. `/foo/*` matches `/foo/` and all of its subpaths.
-
-An unset property is the same as a property set to the zero value for its type
-(e.g. empty string, 0, false). However, unset should be preferred for
-readability.
-
-In the future, policies may be expressed in a JSON format, and managed via a
-REST interface.
-
-### Authorization Algorithm
-
-A request has attributes which correspond to the properties of a policy object.
-
-When a request is received, the attributes are determined.  Unknown attributes
-are set to the zero value of its type (e.g. empty string, 0, false).
-
-A property set to `"*"` will match any value of the corresponding attribute.
-
-The tuple of attributes is checked for a match against every policy in the
-policy file. If at least one line matches the request attributes, then the
-request is authorized (but may fail later validation).
-
-To permit any authenticated user to do something, write a policy with the
-group property set to `"system:authenticated"`.
-
-To permit any unauthenticated user to do something, write a policy with the
-group property set to `"system:unauthenticated"`.
-
-To permit a user to do anything, write a policy with the apiGroup, namespace,
-resource, and nonResourcePath properties set to `"*"`.
-
-### Kubectl
-
-Kubectl uses the `/api` and `/apis` endpoints of api-server to negotiate
-client/server versions. To validate objects sent to the API by create/update
-operations, kubectl queries certain swagger resources. For API version `v1`
-those would be `/swaggerapi/api/v1` & `/swaggerapi/experimental/v1`.
-
-When using ABAC authorization, those special resources have to be explicitly
-exposed via the `nonResourcePath` property in a policy (see [examples](#examples) below):
-
-* `/api`, `/api/*`, `/apis`, and `/apis/*` for API version negotiation.
-* `/version` for retrieving the server version via `kubectl version`.
-* `/swaggerapi/*` for create/update operations.
-
-To inspect the HTTP calls involved in a specific kubectl operation you can turn
-up the verbosity:
-
-    kubectl --v=8 version
-
-### Examples
-
- 1. Alice can do anything to all resources:
-
-    ```json
-    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "alice", "namespace": "*", "resource": "*", "apiGroup": "*"}}
-    ```
- 2. Kubelet can read any pods:
-
-    ```json
-    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "pods", "readonly": true}}
-    ```
- 3. Kubelet can read and write events:
-
-    ```json
-    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "events"}}
-    ```
- 4. Bob can just read pods in namespace "projectCaribou":
-
-    ```json
-    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "bob", "namespace": "projectCaribou", "resource": "pods", "readonly": true}}
-    ```
- 5. Anyone can make read-only requests to all non-resource paths:
-
-    ```json
-    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:authenticated", "readonly": true, "nonResourcePath": "*"}}
-    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:unauthenticated", "readonly": true, "nonResourcePath": "*"}}
-    ```
-
-[Complete file example](http://releases.k8s.io/{{page.githubbranch}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
-
-### A quick note on service accounts
-
-A service account automatically generates a user. The user's name is generated
-according to the naming convention:
-
-```shell
-system:serviceaccount:<namespace>:<serviceaccountname>
-```
-Creating a new namespace also causes a new service account to be created, of
-this form:
-
-```shell
-system:serviceaccount:<namespace>:default
-```
-
-For example, if you wanted to grant the default service account in the
-kube-system full privilege to the API, you would add this line to your policy
-file:
-
-```json
-{"apiVersion":"abac.authorization.kubernetes.io/v1beta1","kind":"Policy","spec":{"user":"system:serviceaccount:kube-system:default","namespace":"*","resource":"*","apiGroup":"*"}}
-```
-
-The apiserver will need to be restarted to pickup the new policy lines.
-
-## RBAC Mode
-
-When specified "RBAC" (Role-Based Access Control) uses the
-"rbac.authorization.k8s.io" API group to drive authorization decisions,
-allowing admins to dynamically configure permission policies through the
-Kubernetes API.
-
-As of 1.3 RBAC mode is in alpha and considered experimental.
-
-To use RBAC, you must both enable the authorization module with `--authorization-mode=RBAC`,
-and [enable the API version](
-/docs/admin/cluster-management/#turn-on-or-off-an-api-version-for-your-cluster),
-with a `--runtime-config=` that includes `rbac.authorization.k8s.io/v1alpha1`.
-
-### Privilege Escalation Prevention and Bootstrapping
-
-The `rbac.authorization.k8s.io` API group inherently attempts to prevent users
-from escalating privileges. Simply put, __a user can't grant permissions they
-don't already have even when the RBAC authorizer it disabled__. If "user-1"
-does not have the ability to read secrets in "namespace-a", they cannot create
-a binding that would grant that permission to themselves or any other user.
-
-For bootstrapping the first roles, it becomes necessary for someone to get
-around these limitations. For the alpha release of RBAC, an API Server flag was
-added to allow one user to step around all RBAC authorization and privilege
-escalation checks. NOTE: _This is subject to change with future releases._
-
-```
---authorization-rbac-super-user=admin
-```
-
-Once set the specified super user, in this case "admin", can be used to create
-the roles and role bindings to initialize the system.
-
-This flag is optional and once the initial bootstrapping is performed can be
-unset.
-
-### Roles, RolesBindings, ClusterRoles, and ClusterRoleBindings
-
-The RBAC API Group declares four top level types which will be covered in this
-section. Users can interact with these resources as they would with any other
-API resource. Through `kubectl`, direct calls to the API, etc. For instance,
-`kubectl create -f (resource).yml` can be used with any of these examples,
-though readers who wish to follow along should review the following section on
-bootstrapping first.
-
-In the RBAC API Group, roles hold a logical grouping of permissions. These
-permissions map very closely to ABAC policies, but only contain information
-about requests being made. Permission are purely additive, rules may only omit
-permissions they do not wish to grant.
-
-Here's an example of a role which grants read access to pods within the
-"default" namespace.
-
-```yaml
-kind: Role
-apiVersion: rbac.authorization.k8s.io/v1alpha1
-metadata:
-  namespace: default
-  name: pod-reader
-rules:
-  - apiGroups: [""] # The API group "" indicates the core API Group.
-    resources: ["pods"]
-    verbs: ["get", "watch", "list"]
-```
-
-`ClusterRoles` hold the same information as a `Role` but can apply to any
-namespace as well as non-namespaced resources (such as `Nodes`,
-`PersistentVolume`, etc.). The following `ClusterRole` can grant permissions to
-read secrets in any namespace.
-
-```yaml
-kind: ClusterRole
-apiVersion: rbac.authorization.k8s.io/v1alpha1
-metadata:
-  # "namespace" omitted since ClusterRoles are not namespaced.
-  name: secret-reader
-rules:
-  - apiGroups: [""]
-    resources: ["secrets"]
-    verbs: ["get", "watch", "list"]
-    nonResourceURLs: []
-```
-
-`RoleBindings` perform the task of granting the permission to a user or set of
-users. They hold a list of subjects which they apply to, and a reference to the
-`Role` being assigned.
-
-The following `RoleBinding` assigns the "pod-reader" role to the user "jane"
-within the "default" namespace, and allows jane to read pods.
-
-```yaml
-# This role binding allows "jane" to read pods in the namespace "default"
-kind: RoleBinding
-apiVersion: rbac.authorization.k8s.io/v1alpha1
-metadata:
-  name: read-pods
-  namespace: default
-subjects:
-  - kind: User # May be "User", "Group" or "ServiceAccount"
-    name: jane
-roleRef:
-  kind: Role
-  name: pod-reader
-  apiGroup: rbac.authorization.k8s.io
-```
-
-`RoleBindings` may also refer to a `ClusterRole`. However, a `RoleBinding` that
-refers to a `ClusterRole` only applies in the `RoleBinding`'s namespace, not at
-the cluster level. This allows admins to define a set of common roles for the
-entire cluster, then reuse them in multiple namespaces.
-
-For instance, even though the following `RoleBinding` refers to a `ClusterRole`,
-"dave" (the subject) will only be able read secrets in the "development"
-namespace, the namespace of the `RoleBinding`.
-
-```yaml
-# This role binding allows "dave" to read secrets in the namespace "development"
-kind: RoleBinding
-apiVersion: rbac.authorization.k8s.io/v1alpha1
-metadata:
-  name: read-secrets
-  namespace: development # This binding only applies in the "development" namespace
-subjects:
-  - kind: User # May be "User", "Group" or "ServiceAccount"
-    name: dave
-roleRef:
-  kind: ClusterRole
-  name: secret-reader
-  apiGroup: rbac.authorization.k8s.io
-```
-
-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 namespace.
-
-```yaml
-# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
-kind: ClusterRoleBinding
-apiVersion: rbac.authorization.k8s.io/v1alpha1
-metadata:
-  name: read-secrets-global
-subjects:
-  - kind: Group # May be "User", "Group" or "ServiceAccount"
-    name: manager
-roleRef:
-  kind: ClusterRole
-  name: secret-reader
-  apiGroup: rbac.authorization.k8s.io
-```
-
-### Referring to Resources
-
-Most resources are represented by a string representation of their name, such as "pods", just as it
-appears in the URL for the relevant API endpoint. However, some Kubernetes APIs involve a
-"subresource" such as the logs for a pod. The URL for the pods logs endpoint is:
-
-```
-GET /api/v1/namespaces/{namespace}/pods/{name}/log
-```
-
-In this case, "pods" is the namespaced resource, and "log" is a subresource of pods. To represent
-this in an RBAC role, use a slash to delimit the resource and subresource names. To allow a subject
-to read both pods and pod logs, you would write:
-
-```yaml
-kind: Role
-apiVersion: rbac.authorization.k8s.io/v1alpha1
-metadata:
-  namespace: default
-  name: pod-and-pod-logs-reader
-rules:
-  - apiGroups: [""]
-    resources: ["pods", "pods/log"]
-    verbs: ["get", "list"]
-```
-
-### Referring to Subjects
-
-RoleBindings and ClusterRoleBindings bind "subjects" to "roles".
-Subjects can be groups, users or service accounts.
-
-Users are represented by strings.  These can be plain usernames, like
-"alice", or email style names, like "bob@example.com", or numeric ids
-as string.  It is up to the Kubernetes admin to configure
-the [authentication modules](/docs/admin/authentication/) to produce
-usernames in the desired format.  The RBAC authorization system does
-not require any particular format.  However, the prefix `system:` is
-reserved for Kubernetes system use, and so the admin should ensure
-usernames should not contain this prefix by accident.
-
-Groups information in Kubernetes is currently provided by the Authenticator
-modules.  (In the future we may add a separate way for the RBAC Authorizer
-to query groups information for users.)  Groups, like users, are represented
-by a string, and that string has no format requirements, other than that the
-prefix `system:` is reserved.
-
-Service Accounts have usernames with the `system:` prefix and belong
-to groups with the `system:` prefix.
-
-#### Role Binding Examples
-
-Only the `subjects` section of a RoleBinding object shown in the following examples.
-
-For a user called `alice@example.com`, specify
-
-```yaml
-subjects:
-  - kind: User
-    name: "alice@example.com"
-```
-
-For a group called `frontend-admins`, specify:
-
-```yaml
-subjects:
-  - kind: Group
-    name: "frontend-admins"
-```
-
-For the default service account in the kube-system namespace:
-
-```yaml
-subjects:
- - kind: ServiceAccount
-   name: default
-   namespace: kube-system
-```
-
-For all service accounts in the `qa` namespace:
-
-```yaml
-subjects:
-- kind: Group
-  name: system:serviceaccounts:qa
-```
-
-For all service accounts everywhere:
-
-```yaml
-subjects:
-- kind: Group
-  name: system:serviceaccounts
-```
-
-For all authenticated users:
-```yaml
-subjects:
-- kind: Group
-  name: system:authenticated
-```
-
-For all unauthenticated users:
-```yaml
-subjects:
-- kind: Group
-  name: system:unauthenticated
-```
-
-For all users:
-```yaml
-subjects:
-- kind: Group
-  name: system:authenticated
-- kind: Group
-  name: system:unauthenticated
-```
-
-## Webhook Mode
-
-When specified, mode `Webhook` causes Kubernetes to query an outside REST
-service when determining user privileges.
-
-### Configuration File Format
-
-Mode `Webhook` requires a file for HTTP configuration, specify by the
-`--authorization-webhook-config-file=SOME_FILENAME` flag.
-
-The configuration file uses the [kubeconfig](/docs/user-guide/kubeconfig-file/)
-file format. Within the file "users" refers to the API Server webhook and
-"clusters" refers to the remote service.
-
-A configuration example which uses HTTPS client auth:
-
-```yaml
-# clusters refers to the remote service.
-clusters:
-  - name: name-of-remote-authz-service
-    cluster:
-      certificate-authority: /path/to/ca.pem      # CA for verifying the remote service.
-      server: https://authz.example.com/authorize # URL of remote service to query. Must use 'https'.
-
-# users refers to the API Server's webhook configuration.
-users:
-  - name: name-of-api-server
-    user:
-      client-certificate: /path/to/cert.pem # cert for the webhook plugin to use
-      client-key: /path/to/key.pem          # key matching the cert
-
-# kubeconfig files require a context. Provide one for the API Server.
-current-context: webhook
-contexts:
-- context:
-    cluster: name-of-remote-authz-service
-    user: name-of-api-sever
-  name: webhook
-```
-
-### Request Payloads
-
-When faced with an authorization decision, the API Server POSTs a JSON
-serialized api.authorization.v1beta1.SubjectAccessReview object describing the
-action. This object contains fields describing the user attempting to make the
-request, and either details about the resource being accessed or requests
-attributes.
-
-Note that webhook API objects are subject to the same [versioning compatibility rules](/docs/api/)
-as other Kubernetes API objects. Implementers should be aware of looser
-compatibility promises for beta objects and check the "apiVersion" field of the
-request to ensure correct deserialization. Additionally, the API Server must
-enable the `authorization.k8s.io/v1beta1` API extensions group (`--runtime-config=authorization.k8s.io/v1beta1=true`).
-
-An example request body:
-
-```json
-{
-  "apiVersion": "authorization.k8s.io/v1beta1",
-  "kind": "SubjectAccessReview",
-  "spec": {
-    "resourceAttributes": {
-      "namespace": "kittensandponies",
-      "verb": "GET",
-      "group": "unicorn.example.org",
-      "resource": "pods"
-    },
-    "user": "jane",
-    "group": [
-      "group1",
-      "group2"
-    ]
-  }
-}
-```
-
-The remote service is expected to fill the SubjectAccessReviewStatus 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:
-
-```json
-{
-  "apiVersion": "authorization.k8s.io/v1beta1",
-  "kind": "SubjectAccessReview",
-  "status": {
-    "allowed": true
-  }
-}
-```
-
-To disallow access, the remote service would return:
-
-```json
-{
-  "apiVersion": "authorization.k8s.io/v1beta1",
-  "kind": "SubjectAccessReview",
-  "status": {
-    "allowed": false,
-    "reason": "user does not have read access to the namespace"
-  }
-}
-```
-
-Access to non-resource paths are sent as:
-
-```json
-{
-  "apiVersion": "authorization.k8s.io/v1beta1",
-  "kind": "SubjectAccessReview",
-  "spec": {
-    "nonResourceAttributes": {
-      "path": "/debug",
-      "verb": "GET"
-    },
-    "user": "jane",
-    "group": [
-      "group1",
-      "group2"
-    ]
-  }
-}
-```
-
-Non-resource paths include: `/api`, `/apis`, `/metrics`, `/resetMetrics`,
-`/logs`, `/debug`, `/healthz`, `/swagger-ui/`, `/swaggerapi/`, `/ui`, and
-`/version.` Clients require access to `/api`, `/api/*`, `/apis`, `/apis/*`,
-and `/version` to discover what resources and versions are present on the server.
-Access to other non-resource paths can be disallowed without restricting access
-to the REST api.
-
-For further documentation refer to the authorization.v1beta1 API objects and
-plugin/pkg/auth/authorizer/webhook/webhook.go.
-
-## Module Development
-
-Other implementations can be developed fairly easily.
-The APIserver calls the Authorizer interface:
-
-```go
-type Authorizer interface {
-  Authorize(a Attributes) error
-}
-```
-
-to determine whether or not to allow each API action.
-
-An authorization plugin is a module that implements this interface.
-Authorization plugin code goes in `pkg/auth/authorizer/$MODULENAME`.
-
-An authorization module can be completely implemented in go, or can call out
-to a remote authorization service.  Authorization modules can implement
-their own caching to reduce the cost of repeated authorization calls with the
-same or similar arguments.  Developers should then consider the interaction
-between caching and revocation of permissions.
-
-
-### Checking API Access
-
-Kubernetes exposes the `subjectaccessreviews.v1beta1.authorization.k8s.io` resource as a
-normal resource that allows external access to API authorizer decisions.  No matter which authorizer
-you choose to use, you can issue a `POST` with a `SubjectAccessReview` just like the webhook
-authorizer to the `apis/authorization.k8s.io/v1beta1/subjectaccessreviews` endpoint and
-get back a response.  For instance:
-
-```bash
-kubectl create --v=8 -f -  << __EOF__
-{
-  "apiVersion": "authorization.k8s.io/v1beta1",
-  "kind": "SubjectAccessReview",
-  "spec": {
-    "resourceAttributes": {
-      "namespace": "kittensandponies",
-      "verb": "GET",
-      "group": "unicorn.example.org",
-      "resource": "pods"
-    },
-    "user": "jane",
-    "group": [
-      "group1",
-      "group2"
-    ]
-  }
-}
-__EOF__
-
---- snip lots of output ---
-
-I0913 08:12:31.362873   27425 request.go:908] Response Body: {"kind":"SubjectAccessReview","apiVersion":"authorization.k8s.io/v1beta1","metadata":{"creationTimestamp":null},"spec":{"resourceAttributes":{"namespace":"kittensandponies","verb":"GET","group":"unicorn.example.org","resource":"pods"},"user":"jane","group":["group1","group2"]},"status":{"allowed":true}}
-subjectaccessreview "" created
-```
-
-This is useful for debugging access problems, in that you can use this resource
-to determine what access an authorizer is granting.

docs/admin/authorization/abac.md

@@ -0,0 +1,155 @@
+---
+assignees:
+- erictune
+- lavalamp
+- deads2k
+- liggitt
+title: ABAC Mode
+---
+
+{% capture overview %}
+Attribute-based access control (ABAC) defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together.
+{% endcapture %}
+
+{% capture body %}
+## Policy File Format
+
+For mode `ABAC`, also specify `--authorization-policy-file=SOME_FILENAME`.
+
+The file format is [one JSON object per line](http://jsonlines.org/).  There
+should be no enclosing list or map, just one map per line.
+
+Each line is a "policy object".  A policy object is a map with the following
+properties:
+
+  - Versioning properties:
+    - `apiVersion`, type string; valid values are "abac.authorization.kubernetes.io/v1beta1". Allows versioning and conversion of the policy format.
+    - `kind`, type string: valid values are "Policy". Allows versioning and conversion of the policy format.
+  - `spec` property set to a map with the following properties:
+    - Subject-matching properties:
+      - `user`, type string; the user-string from `--token-auth-file`. If you specify `user`, it must match the username of the authenticated user.
+      - `group`, type string; if you specify `group`, it must match one of the groups of the authenticated user. `system:authenticated` matches all authenticated requests. `system:unauthenticated` matches all unauthenticated requests.
+    - Resource-matching properties:
+      - `apiGroup`, type string; an API group.
+        - Ex: `extensions`
+        - Wildcard: `*` matches all API groups.
+      - `namespace`, type string; a namespace.
+        - Ex: `kube-system`
+        - Wildcard: `*` matches all resource requests.
+      - `resource`, type string; a resource type
+        - Ex: `pods`
+        - Wildcard: `*` matches all resource requests.
+    - Non-resource-matching properties:
+      - `nonResourcePath`, type string; non-resource request paths.
+        - Ex: `/version` or `/apis`
+        - Wildcard: 
+          - `*` matches all non-resource requests.
+          - `/foo/*` matches all subpaths of `/foo/`.
+    - `readonly`, type boolean, when true, means that the policy only applies to get, list, and watch operations.
+
+**NOTES:** An unset property is the same as a property set to the zero value for its type
+(e.g. empty string, 0, false). However, unset should be preferred for
+readability.
+
+In the future, policies may be expressed in a JSON format, and managed via a
+REST interface.
+
+## Authorization Algorithm
+
+A request has attributes which correspond to the properties of a policy object.
+
+When a request is received, the attributes are determined.  Unknown attributes
+are set to the zero value of its type (e.g. empty string, 0, false).
+
+A property set to `"*"` will match any value of the corresponding attribute.
+
+The tuple of attributes is checked for a match against every policy in the
+policy file. If at least one line matches the request attributes, then the
+request is authorized (but may fail later validation).
+
+To permit any authenticated user to do something, write a policy with the
+group property set to `"system:authenticated"`.
+
+To permit any unauthenticated user to do something, write a policy with the
+group property set to `"system:unauthenticated"`.
+
+To permit a user to do anything, write a policy with the apiGroup, namespace,
+resource, and nonResourcePath properties set to `"*"`.
+
+## Kubectl
+
+Kubectl uses the `/api` and `/apis` endpoints of api-server to negotiate
+client/server versions. To validate objects sent to the API by create/update
+operations, kubectl queries certain swagger resources. For API version `v1`
+those would be `/swaggerapi/api/v1` & `/swaggerapi/experimental/v1`.
+
+When using ABAC authorization, those special resources have to be explicitly
+exposed via the `nonResourcePath` property in a policy (see [examples](#examples) below):
+
+* `/api`, `/api/*`, `/apis`, and `/apis/*` for API version negotiation.
+* `/version` for retrieving the server version via `kubectl version`.
+* `/swaggerapi/*` for create/update operations.
+
+To inspect the HTTP calls involved in a specific kubectl operation you can turn
+up the verbosity:
+
+    kubectl --v=8 version
+
+## Examples
+
+ 1. Alice can do anything to all resources:
+
+    ```json
+    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "alice", "namespace": "*", "resource": "*", "apiGroup": "*"}}
+    ```
+ 2. Kubelet can read any pods:
+
+    ```json
+    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "pods", "readonly": true}}
+    ```
+ 3. Kubelet can read and write events:
+
+    ```json
+    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "events"}}
+    ```
+ 4. Bob can just read pods in namespace "projectCaribou":
+
+    ```json
+    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "bob", "namespace": "projectCaribou", "resource": "pods", "readonly": true}}
+    ```
+ 5. Anyone can make read-only requests to all non-resource paths:
+
+    ```json
+    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:authenticated", "readonly": true, "nonResourcePath": "*"}}
+    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"group": "system:unauthenticated", "readonly": true, "nonResourcePath": "*"}}
+    ```
+
+[Complete file example](http://releases.k8s.io/{{page.githubbranch}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
+
+## A quick note on service accounts
+
+A service account automatically generates a user. The user's name is generated
+according to the naming convention:
+
+```shell
+system:serviceaccount:<namespace>:<serviceaccountname>
+```
+Creating a new namespace also causes a new service account to be created, of
+this form:
+
+```shell
+system:serviceaccount:<namespace>:default
+```
+
+For example, if you wanted to grant the default service account in the
+kube-system full privilege to the API, you would add this line to your policy
+file:
+
+```json
+{"apiVersion":"abac.authorization.kubernetes.io/v1beta1","kind":"Policy","spec":{"user":"system:serviceaccount:kube-system:default","namespace":"*","resource":"*","apiGroup":"*"}}
+```
+
+The apiserver will need to be restarted to pickup the new policy lines.
+
+{% endcapture %}
+{% include templates/concept.md %}

docs/admin/authorization/index.md

@@ -0,0 +1,158 @@
+---
+assignees:
+- erictune
+- lavalamp
+- deads2k
+- liggitt
+title: Overview
+---
+
+{% capture overview %}
+Learn more about Kubernetes authorization, including details about creating policies using the supported authorization modules.
+{% endcapture %}
+
+{% capture body %}
+In Kubernetes, you must be authenticated (logged in) before your request can be authorized (granted permission to access). For information about authentication, see [Accessing Control Overview](/docs/admin/accessing-the-api/).
+
+Kubernetes expects attributes that are common to REST API requests. This means that Kubernetes authorization works with existing organization-wide or cloud-provider-wide access control systems which may handle other APIs besides the Kubernetes API.
+
+## Determine Whether a Request is Allowed or Denied
+Kubernetes authorizes API requests using the API server. It evaluates all of the request attributes against all policies and allows or denies the request. All parts of an API request must be allowed by some policy in order to proceed. This means that permissions are denied by default.
+
+(Although Kubernetes uses the API server, access controls and policies that depend on specific fields of specific kinds of objects are handled by Admission Controllers.)
+
+When multiple authorization modules are configured, each is checked in sequence, and if any module authorizes the request, then the request can proceed. If all modules deny the request, then the request is denied (HTTP status code 403).
+
+## Review Your Request Attributes
+Kubernetes reviews only the following API request attributes:
+
+ * **user** - The `user` string provided during authentication
+ * **group** - The list of group names to which the authenticated user belongs
+ * **"extra"** - A map of arbitrary string keys to string values, provided by the authentication layer
+ * **API** - Indicates whether the request is for an API resource
+ * **Request path** - Path to miscellaneous non-resource endpoints like `/api` or `/healthz` (see [kubectl](#kubectl)).
+ * **API request verb** - API verbs `get`, `list`, `create`, `update`, `patch`, `watch`, `proxy`, `redirect`, `delete`, and `deletecollection` are used for resource requests. To determine the request verb for a resource API endpoint, see **Determine the request verb** below.
+ * **HTTP request verb** - HTTP verbs `get`, `post`, `put`, and `delete` are used for non-resource requests
+ * **Resource** - The ID or name of the resource that is being accessed (for resource requests only)
+--* For resource requests using `get`, `update`, `patch`, and `delete` verbs, you must provide the resource name.
+ * **Subresource** - The subresource that is being accessed (for resource requests only)
+ * **Namespace** - The namespace of the object that is being accessed (for namespaced resource requests only)
+ * **API group** - The API group being accessed (for resource requests only). An empty string designates the [core API group](/docs/api/).
+
+## Determine the Request Verb
+To determine the request verb for a resource API endpoint, review the HTTP verb used and whether or not the request acts on an individual resource or a collection of resources:
+
+HTTP verb | request verb
+----------|---------------
+POST      | create
+GET, HEAD | get (for individual resources), list (for collections)
+PUT       | update
+PATCH     | patch
+DELETE    | delete (for individual resources), deletecollection (for collections)
+
+Kubernetes sometimes checks authorization for additional permissions using specialized verbs. For example:
+
+* [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) checks for authorization of the `use` verb on `podsecuritypolicies` resources in the `extensions` API group.
+* [RBAC](/docs/admin/authorization/rbac/#privilege-escalation-prevention-and-bootstrapping) checks for authorization 
+of the `bind` verb on `roles` and `clusterroles` resources in the `rbac.authorization.k8s.io` API group.
+* [Authentication](/docs/admin/authentication/) layer checks for authorization of the `impersonate` verb on `users`, `groups`, and `serviceaccounts` in the core API group, and the `userextras` in the `authentication.k8s.io` API group.
+
+## Authorization Modules
+ * **Node** - A special-purpose authorizer that grants permissions to kubelets based on the pods they are scheduled to run. To learn more about using the Node authorization mode, see [Node Authorization](/docs/admin/authorization/node/)
+ * **ABAC** - Attribute-based access control (ABAC) defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together. The policies can use any type of attributes (user attributes, resource attributes, object, environment attributes etc). To learn more about using the ABAC mode, see [ABAC Mode](/docs/admin/authorization/abac/)
+ * **RBAC** - Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise. In this context, access is the ability of an individual user to perform a specific task, such as view, create, or modify a file. To learn more about using the RBAC mode, see [RBAC Mode](/docs/admin/authorization/rbac/)
+ ..* When specified "RBAC" (Role-Based Access Control) uses the "rbac.authorization.k8s.io" API group to drive authorization decisions, allowing admins to dynamically configure permission policies through the Kubernetes API.
+ ..* As of 1.6 RBAC mode is in beta.
+ ..* To enable RBAC, start the apiserver with `--authorization-mode=RBAC`.
+ * **Webhook** - A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST. A web application implementing WebHooks will POST a message to a URL when certain things happen. To learn more about using the Webhook mode, see [Webhook Mode](/docs/admin/authorization/webhook/)
+ * **Custom Modules** - You can create custom modules for using with Kubernetes. To learn more, see **Custom Modules** below.
+ 
+### Custom Modules
+Other implementations can be developed fairly easily. The APIserver calls the Authorizer interface:
+
+```go
+type Authorizer interface {
+  Authorize(a Attributes) error
+}
+```
+
+to determine whether or not to allow each API action.
+
+An authorization plugin is a module that implements this interface.
+Authorization plugin code goes in `pkg/auth/authorizer/$MODULENAME`.
+
+An authorization module can be completely implemented in go, or can call out
+to a remote authorization service.  Authorization modules can implement
+their own caching to reduce the cost of repeated authorization calls with the
+same or similar arguments.  Developers should then consider the interaction
+between caching and revocation of permissions.
+
+#### Checking API Access
+
+Kubernetes exposes the `subjectaccessreviews.v1.authorization.k8s.io` resource as a
+normal resource that allows external access to API authorizer decisions.  No matter which authorizer
+you choose to use, you can issue a `POST` with a `SubjectAccessReview` just like the webhook
+authorizer to the `apis/authorization.k8s.io/v1/subjectaccessreviews` endpoint and
+get back a response.  For instance:
+
+```bash
+kubectl create --v=8 -f -  << __EOF__
+{
+  "apiVersion": "authorization.k8s.io/v1",
+  "kind": "SubjectAccessReview",
+  "spec": {
+    "resourceAttributes": {
+      "namespace": "kittensandponies",
+      "verb": "get",
+      "group": "unicorn.example.org",
+      "resource": "pods"
+    },
+    "user": "jane",
+    "group": [
+      "group1",
+      "group2"
+    ],
+    "extra": {
+      "scopes": [
+        "openid",
+        "profile"
+      ]
+    }
+  }
+}
+__EOF__
+
+--- snip lots of output ---
+
+I0913 08:12:31.362873   27425 request.go:908] Response Body: {"kind":"SubjectAccessReview","apiVersion":"authorization.k8s.io/v1","metadata":{"creationTimestamp":null},"spec":{"resourceAttributes":{"namespace":"kittensandponies","verb":"GET","group":"unicorn.example.org","resource":"pods"},"user":"jane","group":["group1","group2"],"extra":{"scopes":["openid","profile"]}},"status":{"allowed":true}}
+subjectaccessreview "" created
+```
+
+This is useful for debugging access problems, in that you can use this resource
+to determine what access an authorizer is granting.
+
+## Using Flags for Your Authorization Module
+
+You must include a flag in your policy to indicate which authorization module your policies include:
+
+The following flags can be used:
+  - `--authorization-mode=ABAC` Attribute-Based Access Control (ABAC) mode allows you to configure policies using local files.
+  - `--authorization-mode=RBAC` Role-based access control (RBAC) mode allows you to create and store policies using the Kubernetes API.
+  - `--authorization-mode=Webhook` WebHook is an HTTP callback mode that allows you to manage authorization using a remote REST.
+  - `--authorization-mode=AlwaysDeny` This flag blocks all requests. Use this flag only for testing.
+  - `--authorization-mode=AlwaysAllow` This flag allows all requests. Use this flag only if you do not require authorization for your API requests.
+
+You can choose more than one authorization module. If one of the modes is `AlwaysAllow`, then it overrides the other modes and all API requests are allowed. 
+
+## Versioning
+For version 1.2, clusters created by kube-up.sh are configured so that no authorization is required for any request.
+
+As of version 1.3, clusters created by kube-up.sh are configured so that the ABAC authorization 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.
+
+{% endcapture %}
+{% capture whatsnext %}
+* To learn more about Authentication, see **Authentication** in [Controlling Access to the Kubernetes API](/docs/admin/accessing-the-api/).
+* To learn more about Admission Control, see [Using Admission Controllers](/docs/admin/admission-controllers/).
+{% endcapture %}
+
+{% include templates/concept.md %}

docs/admin/authorization/node.md

@@ -0,0 +1,93 @@
+---
+assignees:
+- timstclair
+- deads2k
+- liggitt
+- ericchiang
+title: Using Node Authorization
+---
+
+* TOC
+{:toc}
+
+Node authorization is a special-purpose authorization mode that specifically authorizes API requests made by kubelets.
+
+## Overview
+
+The Node authorizer allows a kubelet to perform API operations. This includes:
+
+Read operations:
+
+* services
+* endpoints
+* nodes
+* pods
+* secrets, configmaps, persistent volume claims and persistent volumes related to pods bound to the kubelet's node
+
+Write operations:
+
+* nodes and node status (enable the `NodeRestriction` admission plugin to limit a kubelet to modify its own node)
+* pods and pod status (enable the `NodeRestriction` admission plugin to limit a kubelet to modify pods bound to itself)
+* events
+
+Auth-related operations:
+
+* read/write access to the certificationsigningrequests API for TLS bootstrapping
+* the ability to create tokenreviews and subjectaccessreviews for delegated authentication/authorization checks
+
+In future releases, the node authorizer may add or remove permissions to ensure kubelets
+have the minimal set of permissions required to operate correctly.
+
+In order to be authorized by the Node authorizer, kubelets must use a credential that identifies them as 
+being in the `system:nodes` group, with a username of `system:node:<nodeName>`.
+This group and user name format match the identity created for each kubelet as part of 
+[kubelet TLS bootstrapping](/docs/admin/kubelet-tls-bootstrapping/).
+
+To enable the Node authorizer, start the apiserver with `--authorization-mode=Node`.
+
+To limit the API objects kubelets are able to write, enable the [NodeRestriction](/docs/admin/admission-controllers#NodeRestriction) admission plugin by starting the apiserver with `--admission-control=...,NodeRestriction,...`
+
+## Migration considerations
+
+### Kubelets outside the `system:nodes` group
+
+Kubelets outside the `system:nodes` group would not be authorized by the `Node` authorization mode,
+and would need to continue to be authorized via whatever mechanism currently authorizes them.
+The node admission plugin would not restrict requests from these kubelets.
+
+### Kubelets with undifferentiated usernames
+
+In some deployments, kubelets have credentials that place them in the `system:nodes` group,
+but do not identify the particular node they are associated with,
+because they do not have a username in the `system:node:...` format.
+These kubelets would not be authorized by the `Node` authorization mode,
+and would need to continue to be authorized via whatever mechanism currently authorizes them.
+
+The `NodeRestriction` admission plugin would ignore requests from these kubelets,
+since the default node identifier implementation would not consider that a node identity.
+
+### Upgrades from previous versions using RBAC
+
+Upgraded pre-1.7 clusters using [RBAC](/docs/admin/authorization/rbac/) will continue functioning as-is because the `system:nodes` group binding will already exist.
+
+If a cluster admin wishes to start using the `Node` authorizer and `NodeRestriction` admission plugin
+to limit node access to the API, that can be done non-disruptively:
+
+1. Enable the `Node` authorization mode (`--authorization-mode=Node,RBAC`) and the `NodeRestriction` admission plugin
+2. Ensure all kubelets' credentials conform to the group/username requirements
+3. Audit apiserver logs to ensure the `Node` authorizer is not rejecting requests from kubelets (no persistent `NODE DENY` messages logged)
+4. Delete the `system:node` cluster role binding
+
+### RBAC Node Permissions
+
+In 1.6, the `system:node` cluster role was automatically bound to the `system:nodes` group when using the [RBAC Authorization mode](/docs/admin/authorization/rbac/).
+
+In 1.7, the automatic binding of the `system:nodes` group to the `system:node` role is deprecated
+because the node authorizer accomplishes the same purpose with the benefit of additional restrictions
+on secret and configmap access. If the `Node` and `RBAC` authorization modes are both enabled,
+the automatic binding of the `system:nodes` group to the `system:node` role is not created in 1.7.
+
+In 1.8, the binding will not be created at all.
+
+When using RBAC, the `system:node` cluster role will continue to be created,
+for compatibility with deployment methods that bind other users or groups to that role.

docs/admin/authorization/rbac.md

@@ -0,0 +1,784 @@
+---
+assignees:
+- erictune
+- deads2k
+- liggitt
+title: Using RBAC Authorization
+---
+
+* TOC
+{:toc}
+
+Role-Based Access Control ("RBAC") uses the "rbac.authorization.k8s.io" API group 
+to drive authorization decisions, allowing admins to dynamically configure policies
+through the Kubernetes API.
+
+As of 1.6 RBAC mode is in beta.
+
+To enable RBAC, start the apiserver with `--authorization-mode=RBAC`.
+
+## API Overview
+
+The RBAC API declares four top-level types which will be covered in this
+section. Users can interact with these resources as they would with any other
+API resource (via `kubectl`, API calls, etc.). For instance,
+`kubectl create -f (resource).yml` can be used with any of these examples,
+though readers who wish to follow along should review the section on
+bootstrapping first.
+
+### Role and ClusterRole
+
+In the RBAC API, a role contains rules that represent a set of permissions.
+Permissions are purely additive (there are no "deny" rules).
+A role can be defined within a namespace with a `Role`, or cluster-wide with a `ClusterRole`.
+
+A `Role` can only be used to grant access to resources within a single namespace.
+Here's an example `Role` in the "default" namespace that can be used to grant read access to pods:
+
+```yaml
+kind: Role
+apiVersion: rbac.authorization.k8s.io/v1beta1
+metadata:
+  namespace: default
+  name: pod-reader
+rules:
+- apiGroups: [""] # "" indicates the core API group
+  resources: ["pods"]
+  verbs: ["get", "watch", "list"]
+```
+
+A `ClusterRole` can be used to grant the same permissions as a `Role`,
+but because they are cluster-scoped, they can also be used to grant access to:
+
+* cluster-scoped resources (like nodes)
+* non-resource endpoints (like "/healthz")
+* namespaced resources (like pods) across all namespaces (needed to run `kubectl get pods --all-namespaces`, for example)
+
+The following `ClusterRole` can be used to grant read access to secrets in any particular namespace,
+or across all namespaces (depending on how it is [bound](#rolebinding-and-clusterrolebinding)):
+
+```yaml
+kind: ClusterRole
+apiVersion: rbac.authorization.k8s.io/v1beta1
+metadata:
+  # "namespace" omitted since ClusterRoles are not namespaced
+  name: secret-reader
+rules:
+- apiGroups: [""]
+  resources: ["secrets"]
+  verbs: ["get", "watch", "list"]
+```
+
+### RoleBinding and ClusterRoleBinding
+
+A role binding grants the permissions defined in a role to a user or set of users.
+It holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted.
+Permissions can be granted within a namespace with a `RoleBinding`, or cluster-wide with a `ClusterRoleBinding`.
+
+A `RoleBinding` may reference a `Role` in the same namespace.
+The following `RoleBinding` grants the "pod-reader" role to the user "jane" within the "default" namespace.
+This allows "jane" to read pods in the "default" namespace.
+
+```yaml
+# This role binding allows "jane" to read pods in the "default" namespace.
+kind: RoleBinding
+apiVersion: rbac.authorization.k8s.io/v1beta1
+metadata:
+  name: read-pods
+  namespace: default
+subjects:
+- kind: User
+  name: jane
+  apiGroup: rbac.authorization.k8s.io
+roleRef:
+  kind: Role
+  name: pod-reader
+  apiGroup: rbac.authorization.k8s.io
+```
+
+A `RoleBinding` may also reference a `ClusterRole` to grant the permissions to namespaced
+resources defined in the `ClusterRole` within the `RoleBinding`'s namespace.
+This allows administrators to define a set of common roles for the entire cluster,
+then reuse them within multiple namespaces.
+
+For instance, even though the following `RoleBinding` refers to a `ClusterRole`,
+"dave" (the subject) will only be able read secrets in the "development"
+namespace (the namespace of the `RoleBinding`).
+
+```yaml
+# This role binding allows "dave" to read secrets in the "development" namespace.
+kind: RoleBinding
+apiVersion: rbac.authorization.k8s.io/v1beta1
+metadata:
+  name: read-secrets
+  namespace: development # This only grants permissions within the "development" namespace.
+subjects:
+- kind: User
+  name: dave
+  apiGroup: rbac.authorization.k8s.io
+roleRef:
+  kind: ClusterRole
+  name: secret-reader
+  apiGroup: rbac.authorization.k8s.io
+```
+
+Finally, a `ClusterRoleBinding` may be used to grant permission at the cluster level and in all
+namespaces. The following `ClusterRoleBinding` allows any user in the group "manager" to read 
+secrets in any namespace.
+
+```yaml
+# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
+kind: ClusterRoleBinding
+apiVersion: rbac.authorization.k8s.io/v1beta1
+metadata:
+  name: read-secrets-global
+subjects:
+- kind: Group
+  name: manager
+  apiGroup: rbac.authorization.k8s.io
+roleRef:
+  kind: ClusterRole
+  name: secret-reader
+  apiGroup: rbac.authorization.k8s.io
+```
+
+### Referring to Resources
+
+Most resources are represented by a string representation of their name, such as "pods", just as it
+appears in the URL for the relevant API endpoint. However, some Kubernetes APIs involve a
+"subresource", such as the logs for a pod. The URL for the pods logs endpoint is:
+
+```
+GET /api/v1/namespaces/{namespace}/pods/{name}/log
+```
+
+In this case, "pods" is the namespaced resource, and "log" is a subresource of pods. To represent
+this in an RBAC role, use a slash to delimit the resource and subresource. To allow a subject
+to read both pods and pod logs, you would write:
+
+```yaml
+kind: Role
+apiVersion: rbac.authorization.k8s.io/v1beta1
+metadata:
+  namespace: default
+  name: pod-and-pod-logs-reader
+rules:
+- apiGroups: [""]
+  resources: ["pods", "pods/log"]
+  verbs: ["get", "list"]
+```
+
+Resources can also be referred to by name for certain requests through the `resourceNames` list.
+When specified, requests using the "get", "delete", "update", and "patch" verbs can be restricted
+to individual instances of a resource. To restrict a subject to only "get" and "update" a single
+configmap, you would write:
+
+```yaml
+kind: Role
+apiVersion: rbac.authorization.k8s.io/v1beta1
+metadata:
+  namespace: default
+  name: configmap-updater
+rules:
+- apiGroups: [""]
+  resources: ["configmap"]
+  resourceNames: ["my-configmap"]
+  verbs: ["update", "get"]
+```
+
+Notably, if `resourceNames` are set, then the verb must not be list, watch, create, or deletecollection.
+Because resource names are not present in the URL for create, list, watch, and deletecollection API requests,
+those verbs would not be allowed by a rule with resourceNames set, since the resourceNames portion of the
+rule would not match the request.
+
+#### Role Examples
+
+Only the `rules` section is shown in the following examples.
+
+Allow reading the resource "pods" in the core API group:
+
+```yaml
+rules:
+- apiGroups: [""]
+  resources: ["pods"]
+  verbs: ["get", "list", "watch"]
+```
+
+Allow reading/writing "deployments" in both the "extensions" and "apps" API groups:
+
+```yaml
+rules:
+- apiGroups: ["extensions", "apps"]
+  resources: ["deployments"]
+  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
+```
+
+Allow reading "pods" and reading/writing "jobs":
+
+```yaml
+rules:
+- apiGroups: [""]
+  resources: ["pods"]
+  verbs: ["get", "list", "watch"]
+- apiGroups: ["batch", "extensions"]
+  resources: ["jobs"]
+  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
+```
+
+Allow reading a `ConfigMap` named "my-config" (must be bound with a `RoleBinding` to limit to a single `ConfigMap` in a single namespace):
+
+```yaml
+rules:
+- apiGroups: [""]
+  resources: ["configmaps"]
+  resourceNames: ["my-config"]
+  verbs: ["get"]
+```
+
+Allow reading the resource "nodes" in the core group (because a `Node` is cluster-scoped, this must be in a `ClusterRole` bound with a `ClusterRoleBinding` to be effective):
+
+```yaml
+rules:
+- apiGroups: [""]
+  resources: ["nodes"]
+  verbs: ["get", "list", "watch"]
+```
+
+Allow "GET" and "POST" requests to the non-resource endpoint "/healthz" and all subpaths (must be in a `ClusterRole` bound with a `ClusterRoleBinding` to be effective):
+
+```yaml
+rules:
+- nonResourceURLs: ["/healthz", "/healthz/*"] # '*' in a nonResourceURL is a suffix glob match
+  verbs: ["get", "post"]
+```
+
+### Referring to Subjects
+
+A `RoleBinding` or `ClusterRoleBinding` binds a role to *subjects*.
+Subjects can be groups, users or service accounts.
+
+Users are represented by strings.  These can be plain usernames, like
+"alice", email-style names, like "bob@example.com", or numeric ids
+represented as a string.  It is up to the Kubernetes admin to configure
+the [authentication modules](/docs/admin/authentication/) to produce
+usernames in the desired format.  The RBAC authorization system does
+not require any particular format.  However, the prefix `system:` is
+reserved for Kubernetes system use, and so the admin should ensure
+usernames do not contain this prefix by accident.
+
+Group information in Kubernetes is currently provided by the Authenticator
+modules. Groups, like users, are represented as strings, and that string 
+has no format requirements, other than that the prefix `system:` is reserved.
+
+[Service Accounts](/docs/tasks/configure-pod-container/configure-service-account/) have usernames with the `system:serviceaccount:` prefix and belong
+to groups with the `system:serviceaccounts:` prefix.
+
+#### Role Binding Examples
+
+Only the `subjects` section of a `RoleBinding` is shown in the following examples.
+
+For a user named "alice@example.com":
+
+```yaml
+subjects:
+- kind: User
+  name: "alice@example.com"
+  apiGroup: rbac.authorization.k8s.io
+```
+
+For a group named "frontend-admins":
+
+```yaml
+subjects:
+- kind: Group
+  name: "frontend-admins"
+  apiGroup: rbac.authorization.k8s.io
+```
+
+For the default service account in the kube-system namespace:
+
+```yaml
+subjects:
+- kind: ServiceAccount
+  name: default
+  namespace: kube-system
+```
+
+For all service accounts in the "qa" namespace:
+
+```yaml
+subjects:
+- kind: Group
+  name: system:serviceaccounts:qa
+  apiGroup: rbac.authorization.k8s.io
+```
+
+For all service accounts everywhere:
+
+```yaml
+subjects:
+- kind: Group
+  name: system:serviceaccounts
+  apiGroup: rbac.authorization.k8s.io
+```
+
+For all authenticated users (version 1.5+):
+
+```yaml
+subjects:
+- kind: Group
+  name: system:authenticated
+  apiGroup: rbac.authorization.k8s.io
+```
+
+For all unauthenticated users (version 1.5+):
+
+```yaml
+subjects:
+- kind: Group
+  name: system:unauthenticated
+  apiGroup: rbac.authorization.k8s.io
+```
+
+For all users (version 1.5+):
+
+```yaml
+subjects:
+- kind: Group
+  name: system:authenticated
+  apiGroup: rbac.authorization.k8s.io
+- kind: Group
+  name: system:unauthenticated
+  apiGroup: rbac.authorization.k8s.io
+```
+
+## Default Roles and Role Bindings
+
+API servers create a set of default `ClusterRole` and `ClusterRoleBinding` objects.
+Many of these are `system:` prefixed, which indicates that the resource is "owned" by the infrastructure.
+Modifications to these resources can result in non-functional clusters. One example is the `system:node` ClusterRole.
+This role defines permissions for kubelets. If the role is modified, it can prevent kubelets from working.
+
+All of the default cluster roles and rolebindings are labeled with `kubernetes.io/bootstrapping=rbac-defaults`.
+
+### Auto-reconciliation
+
+At each start-up, the API server updates default cluster roles with any missing permissions,
+and updates default cluster role bindings with any missing subjects.
+This allows the cluster to repair accidental modifications,
+and to keep roles and rolebindings up-to-date as permissions and subjects change in new releases.
+
+To opt out of this reconciliation, set the `rbac.authorization.kubernetes.io/autoupdate` 
+annotation on a default cluster role or rolebinding to `false`.
+Be aware that missing default permissions and subjects can result in non-functional clusters.
+
+Auto-reconciliation is enabled in Kubernetes version 1.6+ when the RBAC authorizer is active.
+
+### Discovery Roles
+
+<table>
+<colgroup><col width="25%"><col width="25%"><col></colgroup>
+<tr>
+<th>Default ClusterRole</th>
+<th>Default ClusterRoleBinding</th>
+<th>Description</th>
+</tr>
+<tr>
+<td><b>system:basic-user</b></td>
+<td><b>system:authenticated</b> and <b>system:unauthenticated</b> groups</td>
+<td>Allows a user read-only access to basic information about themselves.</td>
+</tr>
+<tr>
+<td><b>system:discovery</b></td>
+<td><b>system:authenticated</b> and <b>system:unauthenticated</b> groups</td>
+<td>Allows read-only access to API discovery endpoints needed to discover and negotiate an API level.</td>
+</tr>
+</table>
+
+### User-facing Roles
+
+Some of the default roles are not `system:` prefixed. These are intended to be user-facing roles.
+They include super-user roles (`cluster-admin`),
+roles intended to be granted cluster-wide using ClusterRoleBindings (`cluster-status`),
+and roles intended to be granted within particular namespaces using RoleBindings (`admin`, `edit`, `view`).
+
+<table>
+<colgroup><col width="25%"><col width="25%"><col></colgroup>
+<tr>
+<th>Default ClusterRole</th>
+<th>Default ClusterRoleBinding</th>
+<th>Description</th>
+</tr>
+<tr>
+<td><b>cluster-admin</b></td>
+<td><b>system:masters</b> group</td>
+<td>Allows super-user access to perform any action on any resource.
+When used in a <b>ClusterRoleBinding</b>, it gives full control over every resource in the cluster and in all namespaces.
+When used in a <b>RoleBinding</b>, it gives full control over every resource in the rolebinding's namespace, including the namespace itself.</td>
+</tr>
+<tr>
+<td><b>admin</b></td>
+<td>None</td>
+<td>Allows admin access, intended to be granted within a namespace using a <b>RoleBinding</b>.
+If used in a <b>RoleBinding</b>, allows read/write access to most resources in a namespace,
+including the ability to create roles and rolebindings within the namespace.
+It does not allow write access to resource quota or to the namespace itself.</td>
+</tr>
+<tr>
+<td><b>edit</b></td>
+<td>None</td>
+<td>Allows read/write access to most objects in a namespace.
+It does not allow viewing or modifying roles or rolebindings.</td>
+</tr>
+<tr>
+<td><b>view</b></td>
+<td>None</td>
+<td>Allows read-only access to see most objects in a namespace.
+It does not allow viewing roles or rolebindings.
+It does not allow viewing secrets, since those are escalating.</td>
+</tr>
+</table>
+
+### Core Component Roles
+
+<table>
+<colgroup><col width="25%"><col width="25%"><col></colgroup>
+<tr>
+<th>Default ClusterRole</th>
+<th>Default ClusterRoleBinding</th>
+<th>Description</th>
+</tr>
+<tr>
+<td><b>system:kube-scheduler</b></td>
+<td><b>system:kube-scheduler</b> user</td>
+<td>Allows access to the resources required by the kube-scheduler component.</td>
+</tr>
+<tr>
+<td><b>system:kube-controller-manager</b></td>
+<td><b>system:kube-controller-manager</b> user</td>
+<td>Allows access to the resources required by the kube-controller-manager component.
+The permissions required by individual control loops are contained in the <a href="#controller-roles">controller roles</a>.</td>
+</tr>
+<tr>
+<td><b>system:node</b></td>
+<td><b>system:nodes</b> group (deprecated in 1.7)</td>
+<td>Allows access to resources required by the kubelet component, <b>including read access to all secrets, and write access to all pods</b>.
+As of 1.7, use of the [Node authorizer](/docs/admin/authorization/node/) 
+and [NodeRestriction admission plugin](/docs/admin/admission-controllers#NodeRestriction) 
+is recommended instead of this role, and allow granting API access to kubelets based on the pods scheduled to run on them.
+As of 1.7, when the `Node` authorization mode is enabled, the automatic binding to the `system:nodes` group is not created.
+</td>
+</tr>
+<tr>
+<td><b>system:node-proxier</b></td>
+<td><b>system:kube-proxy</b> user</td>
+<td>Allows access to the resources required by the kube-proxy component.</td>
+</tr>
+</table>
+
+### Other Component Roles
+
+<table>
+<colgroup><col width="25%"><col width="25%"><col></colgroup>
+<tr>
+<th>Default ClusterRole</th>
+<th>Default ClusterRoleBinding</th>
+<th>Description</th>
+</tr>
+<tr>
+<td><b>system:auth-delegator</b></td>
+<td>None</td>
+<td>Allows delegated authentication and authorization checks.
+This is commonly used by add-on API servers for unified authentication and authorization.</td>
+</tr>
+<tr>
+<td><b>system:heapster</b></td>
+<td>None</td>
+<td>Role for the <a href="https://github.com/kubernetes/heapster">Heapster</a> component.</td>
+</tr>
+<tr>
+<td><b>system:kube-aggregator</b></td>
+<td>None</td>
+<td>Role for the <a href="https://github.com/kubernetes/kube-aggregator">kube-aggregator</a> component.</td>
+</tr>
+<tr>
+<td><b>system:kube-dns</b></td>
+<td><b>kube-dns</b> service account in the <b>kube-system</b> namespace</td>
+<td>Role for the <a href="/docs/admin/dns/">kube-dns</a> component.</td>
+</tr>
+<tr>
+<td><b>system:node-bootstrapper</b></td>
+<td>None</td>
+<td>Allows access to the resources required to perform <a href="/docs/admin/kubelet-tls-bootstrapping/">Kubelet TLS bootstrapping</a>.</td>
+</tr>
+<tr>
+<td><b>system:node-problem-detector</b></td>
+<td>None</td>
+<td>Role for the <a href="https://github.com/kubernetes/node-problem-detector">node-problem-detector</a> component.</td>
+</tr>
+<tr>
+<td><b>system:persistent-volume-provisioner</b></td>
+<td>None</td>
+<td>Allows access to the resources required by most <a href="/docs/user-guide/persistent-volumes/#provisioner">dynamic volume provisioners</a>.</td>
+</tr>
+</table>
+
+### Controller Roles
+
+The [Kubernetes controller manager](/docs/admin/kube-controller-manager/) runs core control loops.
+When invoked with `--use-service-account-credentials`, each control loop is started using a separate service account.
+Corresponding roles exist for each control loop, prefixed with `system:controller:`.
+If the controller manager is not started with `--use-service-account-credentials`, 
+it runs all control loops using its own credential, which must be granted all the relevant roles.
+These roles include:
+
+* system:controller:attachdetach-controller
+* system:controller:certificate-controller
+* system:controller:cronjob-controller
+* system:controller:daemon-set-controller
+* system:controller:deployment-controller
+* system:controller:disruption-controller
+* system:controller:endpoint-controller
+* system:controller:generic-garbage-collector
+* system:controller:horizontal-pod-autoscaler
+* system:controller:job-controller
+* system:controller:namespace-controller
+* system:controller:node-controller
+* system:controller:persistent-volume-binder
+* system:controller:pod-garbage-collector
+* system:controller:replicaset-controller
+* system:controller:replication-controller
+* system:controller:resourcequota-controller
+* system:controller:route-controller
+* system:controller:service-account-controller
+* system:controller:service-controller
+* system:controller:statefulset-controller
+* system:controller:ttl-controller
+
+## Privilege Escalation Prevention and Bootstrapping
+
+The RBAC API prevents users from escalating privileges by editing roles or role bindings.
+Because this is enforced at the API level, it applies even when the RBAC authorizer is not in use.
+
+A user can only create/update a role if they already have all the permissions contained in the role,
+at the same scope as the role (cluster-wide for a `ClusterRole`, within the same namespace or cluster-wide for a `Role`).
+For example, if "user-1" does not have the ability to list secrets cluster-wide, they cannot create a `ClusterRole`
+containing that permission. To allow a user to create/update roles:
+
+1. Grant them a role that allows them to create/update `Role` or `ClusterRole` objects, as desired.
+2. Grant them roles containing the permissions you would want them to be able to set in a `Role` or `ClusterRole`. If they attempt to create or modify a `Role` or `ClusterRole` with permissions they themselves have not been granted, the API request will be forbidden.
+
+A user can only create/update a role binding if they already have all the permissions contained in the referenced role 
+(at the same scope as the role binding) *or* if they've been given explicit permission to perform the `bind` verb on the referenced role.
+For example, if "user-1" does not have the ability to list secrets cluster-wide, they cannot create a `ClusterRoleBinding`
+to a role that grants that permission. To allow a user to create/update role bindings:
+
+1. Grant them a role that allows them to create/update `RoleBinding` or `ClusterRoleBinding` objects, as desired.
+2. Grant them permissions needed to bind a particular role:
+    * implicitly, by giving them the permissions contained in the role.
+    * explicitly, by giving them permission to perform the `bind` verb on the particular role (or cluster role).
+
+For example, this cluster role and role binding would allow "user-1" to grant other users the `admin`, `edit`, and `view` roles in the "user-1-namespace" namespace:
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1beta1
+kind: ClusterRole
+metadata:
+  name: role-grantor
+rules:
+- apiGroups: ["rbac.authorization.k8s.io"]
+  resources: ["rolebindings"]
+  verbs: ["create"]
+- apiGroups: ["rbac.authorization.k8s.io"]
+  resources: ["clusterroles"]
+  verbs: ["bind"]
+  resourceNames: ["admin","edit","view"]
+---
+apiVersion: rbac.authorization.k8s.io/v1beta1
+kind: RoleBinding
+metadata:
+  name: role-grantor-binding
+  namespace: user-1-namespace
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: role-grantor
+subjects:
+- apiGroup: rbac.authorization.k8s.io
+  kind: User
+  name: user-1
+```
+
+When bootstrapping the first roles and role bindings, it is necessary for the initial user to grant permissions they do not yet have.
+To bootstrap initial roles and role bindings:
+
+* Use a credential with the `system:masters` group, which is bound to the `cluster-admin` super-user role by the default bindings.
+* If your API server runs with the insecure port enabled (`--insecure-port`), you can also make API calls via that port, which does not enforce authentication or authorization.
+
+## Command-line Utilities
+
+Two `kubectl` commands exist to grant roles within a namespace or across the entire cluster.
+
+### `kubectl create rolebinding`
+
+Grants a `Role` or `ClusterRole` within a specific namespace. Examples:
+
+* Grant the `admin` `ClusterRole` to a user named "bob" in the namespace "acme":
+
+    `kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme`
+
+* Grant the `view` `ClusterRole` to a service account named "myapp" in the namespace "acme":
+
+    `kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme`
+
+### `kubectl create clusterrolebinding`
+
+Grants a `ClusterRole` across the entire cluster, including all namespaces. Examples:
+
+* Grant the `cluster-admin` `ClusterRole` to a user named "root" across the entire cluster:
+
+    `kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root`
+
+* Grant the `system:node` `ClusterRole` to a user named "kubelet" across the entire cluster:
+
+    `kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubelet`
+
+* Grant the `view` `ClusterRole` to a service account named "myapp" in the namespace "acme" across the entire cluster:
+
+    `kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp`
+
+See the CLI help for detailed usage
+
+## Service Account Permissions
+
+Default RBAC policies grant scoped permissions to control-plane components, nodes,
+and controllers, but grant *no permissions* to service accounts outside the "kube-system" namespace
+(beyond discovery permissions given to all authenticated users).
+
+This allows you to grant particular roles to particular service accounts as needed.
+Fine-grained role bindings provide greater security, but require more effort to administrate.
+Broader grants can give unnecessary (and potentially escalating) API access to service accounts, but are easier to administrate.
+
+In order from most secure to least secure, the approaches are:
+
+1. Grant a role to an application-specific service account (best practice)
+
+   This requires the application to specify a `serviceAccountName` in its pod spec,
+   and for the service account to be created (via the API, application manifest, `kubectl create serviceaccount`, etc.).
+
+   For example, grant read-only permission within "my-namespace" to the "my-sa" service account:
+   
+   ```shell
+   kubectl create rolebinding my-sa-view \
+     --clusterrole=view \
+     --serviceaccount=my-namespace:my-sa \
+     --namespace=my-namespace
+   ```
+
+2. Grant a role to the "default" service account in a namespace
+
+   If an application does not specify a `serviceAccountName`, it uses the "default" service account.
+
+   NOTE: Permissions given to the "default" service account are available to any pod in the namespace that does not specify a `serviceAccountName`.
+
+   For example, grant read-only permission within "my-namespace" to the "default" service account:
+   ```shell
+   kubectl create rolebinding default-view \
+     --clusterrole=view \
+     --serviceaccount=my-namespace:default \
+     --namespace=my-namespace
+   ```
+
+   Many [add-ons](/docs/concepts/cluster-administration/addons/) currently run as the "default" service account in the "kube-system" namespace.
+   To allow those add-ons to run with super-user access, grant cluster-admin permissions to the "default" service account in the "kube-system" namespace.
+   NOTE: Enabling this means the "kube-system" namespace contains secrets that grant super-user access to the API.
+   
+   ```shell
+   kubectl create clusterrolebinding add-on-cluster-admin \
+     --clusterrole=cluster-admin \
+     --serviceaccount=kube-system:default
+   ```
+
+3. Grant a role to all service accounts in a namespace
+
+   If you want all applications in a namespace to have a role, no matter what service account they use,
+   you can grant a role to the service account group for that namespace.
+
+   For example, grant read-only permission within "my-namespace" to to all service accounts in that namespace:
+   
+   ```shell
+   kubectl create rolebinding serviceaccounts-view \
+     --clusterrole=view \
+     --group=system:serviceaccounts:my-namespace \
+     --namespace=my-namespace
+   ```
+
+4. Grant a limited role to all service accounts cluster-wide (discouraged)
+
+   If you don't want to manage permissions per-namespace, you can grant a cluster-wide role to all service accounts.
+
+   For example, grant read-only permission across all namespaces to all service accounts in the cluster:
+   
+   ```shell
+   kubectl create clusterrolebinding serviceaccounts-view \
+     --clusterrole=view \
+     --group=system:serviceaccounts
+   ```
+
+5. Grant super-user access to all service accounts cluster-wide (strongly discouraged)
+
+   If you don't care about partitioning permissions at all, you can grant super-user access to all service accounts.
+
+   WARNING: This allows any user with read access to secrets or the ability to create a pod to access super-user credentials.
+
+   ```shell
+   kubectl create clusterrolebinding serviceaccounts-cluster-admin \
+     --clusterrole=cluster-admin \
+     --group=system:serviceaccounts
+   ```
+
+## Upgrading from 1.5
+
+Prior to Kubernetes 1.6, many deployments used very permissive ABAC policies,
+including granting full API access to all service accounts.
+
+Default RBAC policies grant scoped permissions to control-plane components, nodes,
+and controllers, but grant *no permissions* to service accounts outside the "kube-system" namespace
+(beyond discovery permissions given to all authenticated users).
+
+While far more secure, this can be disruptive to existing workloads expecting to automatically receive API permissions.
+Here are two approaches for managing this transition:
+
+### Parallel Authorizers
+
+Run both the RBAC and ABAC authorizers, and include the legacy ABAC policy:
+
+```
+--authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.jsonl
+```
+
+The RBAC authorizer will attempt to authorize requests first. If it denies an API request,
+the ABAC authorizer is then run. This means that any request allowed by *either* the RBAC
+or ABAC policies is allowed.
+
+When run with a log level of 2 or higher (`--v=2`), you can see RBAC denials in the apiserver log (prefixed with `RBAC DENY:`).
+You can use that information to determine which roles need to be granted to which users, groups, or service accounts.
+Once you have [granted roles to service accounts](#service-account-permissions) and workloads are running with no RBAC denial messages
+in the server logs, you can remove the ABAC authorizer.
+
+### Permissive RBAC Permissions
+
+You can replicate a permissive policy using RBAC role bindings.
+
+**WARNING: The following policy allows ALL service accounts to act as cluster administrators.
+Any application running in a container receives service account credentials automatically,
+and could perform any action against the API, including viewing secrets and modifying permissions.
+This is not a recommended policy.**
+
+```
+kubectl create clusterrolebinding permissive-binding \
+  --clusterrole=cluster-admin \
+  --user=admin \
+  --user=kubelet \
+  --group=system:serviceaccounts
+```

docs/admin/authorization/webhook.md

@@ -0,0 +1,148 @@
+---
+assignees:
+- erictune
+- lavalamp
+- deads2k
+- liggitt
+title: Webhook Mode
+---
+
+{% capture overview %}
+A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST. A web application implementing WebHooks will POST a message to a URL when certain things happen.
+{% endcapture %}
+
+{% capture body %}
+When specified, mode `Webhook` causes Kubernetes to query an outside REST
+service when determining user privileges.
+
+## Configuration File Format
+
+Mode `Webhook` requires a file for HTTP configuration, specify by the
+`--authorization-webhook-config-file=SOME_FILENAME` flag.
+
+The configuration file uses the [kubeconfig](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
+file format. Within the file "users" refers to the API Server webhook and
+"clusters" refers to the remote service.
+
+A configuration example which uses HTTPS client auth:
+
+```yaml
+# clusters refers to the remote service.
+clusters:
+  - name: name-of-remote-authz-service
+    cluster:
+      certificate-authority: /path/to/ca.pem      # CA for verifying the remote service.
+      server: https://authz.example.com/authorize # URL of remote service to query. Must use 'https'.
+
+# users refers to the API Server's webhook configuration.
+users:
+  - name: name-of-api-server
+    user:
+      client-certificate: /path/to/cert.pem # cert for the webhook plugin to use
+      client-key: /path/to/key.pem          # key matching the cert
+
+# kubeconfig files require a context. Provide one for the API Server.
+current-context: webhook
+contexts:
+- context:
+    cluster: name-of-remote-authz-service
+    user: name-of-api-server
+  name: webhook
+```
+
+## Request Payloads
+
+When faced with an authorization decision, the API Server POSTs a JSON
+serialized api.authorization.v1beta1.SubjectAccessReview object describing the
+action. This object contains fields describing the user attempting to make the
+request, and either details about the resource being accessed or requests
+attributes.
+
+Note that webhook API objects are subject to the same [versioning compatibility rules](/docs/api/)
+as other Kubernetes API objects. Implementers should be aware of looser
+compatibility promises for beta objects and check the "apiVersion" field of the
+request to ensure correct deserialization. Additionally, the API Server must
+enable the `authorization.k8s.io/v1beta1` API extensions group (`--runtime-config=authorization.k8s.io/v1beta1=true`).
+
+An example request body:
+
+```json
+{
+  "apiVersion": "authorization.k8s.io/v1beta1",
+  "kind": "SubjectAccessReview",
+  "spec": {
+    "resourceAttributes": {
+      "namespace": "kittensandponies",
+      "verb": "get",
+      "group": "unicorn.example.org",
+      "resource": "pods"
+    },
+    "user": "jane",
+    "group": [
+      "group1",
+      "group2"
+    ]
+  }
+}
+```
+
+The remote service is expected to fill the SubjectAccessReviewStatus 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:
+
+```json
+{
+  "apiVersion": "authorization.k8s.io/v1beta1",
+  "kind": "SubjectAccessReview",
+  "status": {
+    "allowed": true
+  }
+}
+```
+
+To disallow access, the remote service would return:
+
+```json
+{
+  "apiVersion": "authorization.k8s.io/v1beta1",
+  "kind": "SubjectAccessReview",
+  "status": {
+    "allowed": false,
+    "reason": "user does not have read access to the namespace"
+  }
+}
+```
+
+Access to non-resource paths are sent as:
+
+```json
+{
+  "apiVersion": "authorization.k8s.io/v1beta1",
+  "kind": "SubjectAccessReview",
+  "spec": {
+    "nonResourceAttributes": {
+      "path": "/debug",
+      "verb": "get"
+    },
+    "user": "jane",
+    "group": [
+      "group1",
+      "group2"
+    ]
+  }
+}
+```
+
+Non-resource paths include: `/api`, `/apis`, `/metrics`, `/resetMetrics`,
+`/logs`, `/debug`, `/healthz`, `/swagger-ui/`, `/swaggerapi/`, `/ui`, and
+`/version.` Clients require access to `/api`, `/api/*`, `/apis`, `/apis/*`,
+and `/version` to discover what resources and versions are present on the server.
+Access to other non-resource paths can be disallowed without restricting access
+to the REST api.
+
+For further documentation refer to the authorization.v1beta1 API objects and
+[webhook.go](https://git.k8s.io/kubernetes/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go).
+
+{% endcapture %}
+
+{% include templates/concept.md %}

docs/admin/bootstrap-tokens.md

@@ -0,0 +1,171 @@
+---
+assignees:
+- jbeda
+title: Authenticating with Bootstrap Tokens
+---
+
+* TOC
+{:toc}
+
+## Overview
+
+Bootstrap tokens are a simple bearer token that is meant to be used when
+creating new clusters or joining new nodes to an existing cluster.  It was built
+to support [`kubeadm`](/docs/admin/kubeadm/), but can be used in other contexts
+for users that wish to start clusters without `kubeadm`. It is also built to
+work, via RBAC policy, with the [Kubelet TLS
+Bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) system.
+
+Bootstrap Tokens are defined with a specific type
+(`bootstrap.kubernetes.io/token`) of secrets that lives in the `kube-system`
+namespace.  These Secrets are then read by the Bootstrap Authenticator in the
+API Server.  Expired tokens are removed with the TokenCleaner controller in the
+Controller Manager.  The tokens are also used to create a signature for a
+specific ConfigMap used in a "discovery" process through a BootstrapSigner
+controller.
+
+Currently, Bootstrap Tokens are **alpha** but there are no large breaking
+changes expected.
+
+## Token Format
+
+Bootstrap Tokens take the form of `abcdef.0123456789abcdef`.  More formally,
+they must match the regular expression `[a-z0-9]{6}\.[a-z0-9]{16}`.
+
+The first part of the token is the "Token ID" and is considered public
+information.  It is used when referring to a token without leaking the secret
+part used for authentication. The second part is the "Token Secret" and should
+only be shared with trusted parties.
+
+## Enabling Bootstrap Tokens
+
+All features for Bootstrap Tokens are disabled by default in Kubernetes v1.6.
+
+You can enable the Bootstrap Token authenticator with the
+`--experimental-bootstrap-token-auth` flag on the API server.  You can enable
+the Bootstrap controllers by specifying them withthe `--controllers` flag on the
+controller manager with something like
+`--controllers=*,tokencleaner,bootstrapsigner`.  This is done automatically when
+using `kubeadm`.
+
+Tokens are used in an HTTPS call as follows:
+
+```http
+Authorization: Bearer 07401b.f395accd246ae52d
+```
+
+## Bootstrap Token Secret Format
+
+Each valid token is backed by a secret in the `kube-system` namespace.  You can
+find the full design doc
+[here](https://git.k8s.io/community/contributors/design-proposals/bootstrap-discovery.md).
+
+Here is what the secret looks like.  Note that `base64(string)` indicates the
+value should be base64 encoded.  The undecoded version is provided here for
+readability.
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: bootstrap-token-07401b
+  namespace: kube-system
+type: bootstrap.kubernetes.io/token
+data:
+  description: base64(The default bootstrap token generated by 'kubeadm init'.)
+  token-id: base64(07401b)
+  token-secret: base64(f395accd246ae52d)
+  expiration: base64(2017-03-10T03:22:11Z)
+  usage-bootstrap-authentication: base64(true)
+  usage-bootstrap-signing: base64(true)
+```
+
+The type of the secret must be `bootstrap.kubernetes.io/token` and the name must
+be `bootstrap-token-<token id>`.  It must also exist in the `kube-system`
+namespace.  `description` is a human readable discription that should not be
+used for machine readable information.  The Token ID and Secret are included in
+the data dictionary.
+
+The `usage-bootstrap-*` members indicate what this secret is intended to be used
+for.  A value must be set to `true` to be enabled.
+
+`usage-bootstrap-authentication` indicates that the token can be used to
+authenticate to the API server.  The authenticator authenticates as
+`system:bootstrap:<Token ID>`.  It is included in the `system:bootstrappers`
+group.  The naming and groups are intentionally limited to discourage users from
+using these tokens past bootstrapping.
+
+`usage-bootstrap-signing` indicates that the token should be used to sign the
+`cluster-info` ConfigMap as described below.
+
+The `expiration` data member lists a time after which the token is no longer
+valid.  This is encoded as an absolute UTC time using RFC3339.  The TokenCleaner
+controller will delete expired tokens.
+
+## Token Management with `kubeadm`
+
+You can use the `kubeadm` tool to manage tokens on a running cluster.  It will
+automatically grab the default admin credentials on a master from a `kubeadm`
+created cluster (`/etc/kubernetes/admin.conf`).  You can specify an alternate
+kubeconfig file for credentials with the `--kubeconfig` to the following
+commands.
+
+* `kubeadm token list` Lists the tokens along with when they expire and what the
+  approved usages are.
+* `kubeadm token create` Creates a new token.
+    * `--description` Set the description on the new token.
+    * `--ttl duration` Set expiration time of the token as a delta from "now".
+      Default is 0 for no expiration.
+    * `--usages` Set the ways that the token can be used.  The default is
+      `signing,authentication`.  These are the usages as described above.
+* `kubeadm token delete <token id>|<token id>.<token secret>` Delete a token.
+  The token can either be identified with just an ID or with the entire token
+  value.  Only the ID is used; the token is still deleted if the secret does not
+  match.
+
+## ConfigMap Signing
+
+In addition to authentication, the tokens can be used to sign a ConfigMap.  This
+is used early in a cluster bootstrap process before the client trusts the API
+server.  The signed ConfigMap can be authenicated by the shared token.
+
+The ConfigMap that is signed is `cluster-info` in the `kube-public` namespace.
+The typical flow is that a client reads this ConfigMap while unauthenticated and
+ignoring TLS errors.  It then validates the payload of the ConfigMap by looking
+at a signature embedded in the ConfigMap.
+
+The ConfigMap may look like this:
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: cluster-info
+  namespace: kube-public
+data:
+  jws-kubeconfig-07401b: eyJhbGciOiJIUzI1NiIsImtpZCI6IjA3NDAxYiJ9..tYEfbo6zDNo40MQE07aZcQX2m3EB2rO3NuXtxVMYm9U
+  kubeconfig: |
+    apiVersion: v1
+    clusters:
+    - cluster:
+        certificate-authority-data: <really long certificate data>
+        server: https://10.138.0.2:6443
+      name: ""
+    contexts: []
+    current-context: ""
+    kind: Config
+    preferences: {}
+    users: []
+```
+
+The `kubeconfig` member of the ConfigMap is a config file with just the cluster
+information filled out.  The key thing being communicated here is the
+`certificate-authority-data`.  This may be expanded in the future.
+
+The signature is a JWS signature using the "detached" mode.  To validate the
+signature, the user should encode the `kubeconfig` payload according to JWS
+rules (base64 encoded while discarding any trailing `=`).  That encoded payload
+is then used to form a whole JWS by inserting it between the 2 dots.  You can
+verify the JWS using the `HS256` scheme (HMAC-SHA256) with the full token (e.g.
+`07401b.f395accd246ae52d`) as the shared secret.  Users _must_ verify that HS256
+is used.

docs/admin/cluster-components.md

@@ -1,136 +0,0 @@
----
-assignees:
-- lavalamp
-title: Kubernetes Components
----
-
-This document outlines the various binary components that need to run to
-deliver a functioning Kubernetes cluster.
-
-## Master Components
-
-Master components are those that provide the cluster's control plane. For
-example, master components are responsible for making global decisions about the
-cluster (e.g., scheduling), and detecting and responding to cluster events
-(e.g., starting up a new pod when a replication controller's 'replicas' field is
-unsatisfied).
-
-Master components could in theory be run on any node in the cluster. However,
-for simplicity, current set up scripts typically start all master components on
-the same VM, and does not run user containers on this VM. See
-[high-availability.md](/docs/admin/high-availability) for an example multi-master-VM setup.
-
-Even in the future, when Kubernetes is fully self-hosting, it will probably be
-wise to only allow master components to schedule on a subset of nodes, to limit
-co-running with user-run pods, reducing the possible scope of a
-node-compromising security exploit.
-
-### kube-apiserver
-
-[kube-apiserver](/docs/admin/kube-apiserver) exposes the Kubernetes API; it is the front-end for the
-Kubernetes control plane. It is designed to scale horizontally (i.e., one scales
-it by running more of them-- [high-availability.md](/docs/admin/high-availability)).
-
-### etcd
-
-[etcd](/docs/admin/etcd) is used as Kubernetes' backing store. All cluster data is stored here.
-Proper administration of a Kubernetes cluster includes a backup plan for etcd's
-data.
-
-### kube-controller-manager
-
-[kube-controller-manager](/docs/admin/kube-controller-manager) is a binary that runs controllers, which are the
-background threads that handle routine tasks in the cluster. Logically, each
-controller is a separate process, but to reduce the number of moving pieces in
-the system, they are all compiled into a single binary and run in a single
-process.
-
-These controllers include:
-
-* Node Controller: Responsible for noticing & responding when nodes go down.
-* Replication Controller: Responsible for maintaining the correct number of pods for every replication
-  controller object in the system.
-* Endpoints Controller: Populates the Endpoints object (i.e., join Services & Pods).
-* Service Account & Token Controllers: Create default accounts and API access tokens for new namespaces.
-* ... and others.
-
-### kube-scheduler
-
-[kube-scheduler](/docs/admin/kube-scheduler) watches newly created pods that have no node assigned, and
-selects a node for them to run on.
-
-### addons
-
-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 manager takes the responsibility for creating and maintaining addon resources.
-See [here](http://releases.k8s.io/HEAD/cluster/addons) for more details.
-
-#### DNS
-
-While the other addons are not strictly required, all Kubernetes
-clusters should have [cluster DNS](/docs/admin/dns/), as many examples rely on it.
-
-Cluster DNS is a DNS server, in addition to the other DNS server(s) in your
-environment, which serves DNS records for Kubernetes services.
-
-Containers started by Kubernetes automatically include this DNS server
-in their DNS searches.
-
-#### User interface
-
-The kube-ui provides a read-only overview of the cluster state.  Access
-[the UI using kubectl proxy](/docs/user-guide/connecting-to-applications-proxy/#connecting-to-the-kube-ui-service-from-your-local-workstation)
-
-#### Container Resource Monitoring
-
-[Container Resource Monitoring](/docs/user-guide/monitoring) records generic time-series metrics
-about containers in a central database, and provides a UI for browsing that data.
-
-#### Cluster-level Logging
-
-A [Cluster-level logging](/docs/user-guide/logging/overview) mechanism is responsible for
-saving container logs to a central log store with search/browsing interface.
-
-## Node components
-
-Node components run on every node, maintaining running pods and providing them
-the Kubernetes runtime environment.
-
-### kubelet
-
-[kubelet](/docs/admin/kubelet) is the primary node agent. It:
-
-* Watches for pods that have been assigned to its node (either by apiserver
-  or via local configuration file) and:
-* Mounts the pod's required volumes
-* Downloads the pod's secrets
-* Runs the pod's containers via docker (or, experimentally, rkt).
-* Periodically executes any requested container liveness probes.
-* Reports the status of the pod back to the rest of the system, by creating a
-  "mirror pod" if necessary.
-* Reports the status of the node back to the rest of the system.
-
-### kube-proxy
-
-[kube-proxy](/docs/admin/kube-proxy) enables the Kubernetes service abstraction by maintaining
-network rules on the host and performing connection forwarding.
-
-### docker
-
-`docker` is of course used for actually running containers.
-
-### rkt
-
-`rkt` is supported experimentally as an alternative to docker.
-
-### supervisord
-
-`supervisord` is a lightweight process babysitting system for keeping kubelet and docker
-running.
-
-### fluentd
-
-`fluentd` is a daemon which helps provide [cluster-level logging](#cluster-level-logging).

docs/admin/cluster-large.md

@@ -111,7 +111,7 @@ Heapster's resource limits are set dynamically based on the initial size of your
 and [#22940](http://issue.k8s.io/22940)). If you find that Heapster is running
 out of resources, you should adjust the formulas that compute heapster memory request (see those PRs for details).
 
-For directions on how to detect if addon containers are hitting resource limits, see the [Troubleshooting section of Compute Resources](/docs/user-guide/compute-resources/#troubleshooting).
+For directions on how to detect if addon containers are hitting resource limits, see the [Troubleshooting section of Compute Resources](/docs/concepts/configuration/manage-compute-resources-container/#troubleshooting).
 
 In the [future](http://issue.k8s.io/13048), we anticipate to set all cluster addon resource limits based on cluster size, and to dynamically adjust them if you grow or shrink your cluster.
 We welcome PRs that implement those features.

docs/admin/cluster-troubleshooting.md

@@ -1,115 +0,0 @@
----
-assignees:
-- davidopp
-title: Troubleshooting Clusters
----
-
-This doc is about cluster troubleshooting; we assume you have already ruled out your application as the root cause of the
-problem you are experiencing. See
-the [application troubleshooting guide](/docs/user-guide/application-troubleshooting) for tips on application debugging.
-You may also visit [troubleshooting document](/docs/troubleshooting/) for more information.
-
-## Listing your cluster
-
-The first thing to debug in your cluster is if your nodes are all registered correctly.
-
-Run
-
-```shell
-kubectl get nodes
-```
-
-And verify that all of the nodes you expect to see are present and that they are all in the `Ready` state.
-
-## Looking at logs
-
-For now, digging deeper into the cluster requires logging into the relevant machines.  Here are the locations
-of the relevant log files.  (note that on systemd-based systems, you may need to use `journalctl` instead)
-
-### Master
-
-   * /var/log/kube-apiserver.log - API Server, responsible for serving the API
-   * /var/log/kube-scheduler.log - Scheduler, responsible for making scheduling decisions
-   * /var/log/kube-controller-manager.log - Controller that manages replication controllers
-
-### Worker Nodes
-
-   * /var/log/kubelet.log - Kubelet, responsible for running containers on the node
-   * /var/log/kube-proxy.log - Kube Proxy, responsible for service load balancing
-
-## A general overview of cluster failure modes
-
-This is an incomplete list of things that could go wrong, and how to adjust your cluster setup to mitigate the problems.
-
-Root causes:
-
-  - VM(s) shutdown
-  - Network partition within cluster, or between cluster and users
-  - Crashes in Kubernetes software
-  - Data loss or unavailability of persistent storage (e.g. GCE PD or AWS EBS volume)
-  - Operator error, e.g. misconfigured Kubernetes software or application software
-
-Specific scenarios:
-
-  - Apiserver VM shutdown or apiserver crashing
-    - Results
-      - unable to stop, update, or start new pods, services, replication controller
-      - existing pods and services should continue to work normally, unless they depend on the Kubernetes API
-  - Apiserver backing storage lost
-    - Results
-      - apiserver should fail to come up
-      - kubelets will not be able to reach it but will continue to run the same pods and provide the same service proxying
-      - manual recovery or recreation of apiserver state necessary before apiserver is restarted
-  - Supporting services (node controller, replication controller manager, scheduler, etc) VM shutdown or crashes
-    - currently those are colocated with the apiserver, and their unavailability has similar consequences as apiserver
-    - in future, these will be replicated as well and may not be co-located
-    - they do not have their own persistent state
-  - Individual node (VM or physical machine) shuts down
-    - Results
-      - pods on that Node stop running
-  - Network partition
-    - Results
-      - partition A thinks the nodes in partition B are down; partition B thinks the apiserver is down. (Assuming the master VM ends up in partition A.)
-  - Kubelet software fault
-    - Results
-      - crashing kubelet cannot start new pods on the node
-      - kubelet might delete the pods or not
-      - node marked unhealthy
-      - replication controllers start new pods elsewhere
-  - Cluster operator error
-    - Results
-      - loss of pods, services, etc
-      - lost of apiserver backing store
-      - users unable to read API
-      - etc.
-
-Mitigations:
-
-- Action: Use IaaS provider's automatic VM restarting feature for IaaS VMs
-  - 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
-  - Mitigates: Apiserver backing storage lost
-
-- Action: Use (experimental) [high-availability](/docs/admin/high-availability) configuration
-  - Mitigates: Master VM shutdown or master components (scheduler, API server, controller-managing) crashing
-    - Will tolerate one or more simultaneous node or component failures
-  - Mitigates: Apiserver backing storage (i.e., etcd's data directory) lost
-    - Assuming you used clustered etcd.
-
-- Action: Snapshot apiserver PDs/EBS-volumes periodically
-  - Mitigates: Apiserver backing storage lost
-  - Mitigates: Some cases of operator error
-  - Mitigates: Some cases of Kubernetes software fault
-
-- Action: use replication controller and services in front of pods
-  - Mitigates: Node shutdown
-  - Mitigates: Kubelet software fault
-
-- Action: applications (containers) designed to tolerate unexpected restarts
-  - Mitigates: Node shutdown
-  - Mitigates: Kubelet software fault
-
-- Action: [Multiple independent clusters](/docs/admin/multi-cluster) (and avoid making risky changes to all clusters at once)
-  - Mitigates: Everything listed above.

docs/admin/daemons.md

@@ -1,168 +0,0 @@
----
-assignees:
-- erictune
-title: Daemon Sets
----
-
-* TOC
-{:toc}
-
-## What is a DaemonSet?
-
-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 DaemonSet will clean up the pods it created.
-
-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 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.
-
-## Writing a DaemonSet Spec
-
-### Required Fields
-
-As with all other Kubernetes config, a DaemonSet needs `apiVersion`, `kind`, and `metadata` fields.  For
-general information about working with config files, see [deploying applications](/docs/user-guide/deploying-applications/),
-[configuring containers](/docs/user-guide/configuring-containers/), and [working with resources](/docs/user-guide/working-with-resources/) documents.
-
-A DaemonSet also needs a [`.spec`](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status) section.
-
-### Pod Template
-
-The `.spec.template` is the only required field of the `.spec`.
-
-The `.spec.template` is a [pod template](/docs/user-guide/replication-controller/#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 DaemonSet has to specify appropriate
-labels (see [pod selector](#pod-selector)).
-
-A pod template in a DaemonSet must have a [`RestartPolicy`](/docs/user-guide/pod-states)
- equal to `Always`, or be unspecified, which defaults to `Always`.
-
-### Pod Selector
-
-The `.spec.selector` field is a pod selector.  It works the same as the `.spec.selector` of
-a [Job](/docs/user-guide/jobs/) or other new resources.
-
-The `spec.selector` is an object consisting of two fields:
-
-* `matchLabels` - works the same as the `.spec.selector` of a [ReplicationController](/docs/user-guide/replication-controller/)
-* `matchExpressions` - allows to build more sophisticated selectors by specifying key,
-  list of values and an operator that relates the key and values.
-
-When the two are specified the result is ANDed.
-
-If the `.spec.selector` is specified, it must match the `.spec.template.metadata.labels`.  If not
-specified, they are defaulted to be equal.  Config with these not matching will be rejected by the API.
-
-Also you should not normally create any pods whose labels match this selector, either directly, via
-another DaemonSet, or via other controller such as ReplicationController.  Otherwise, the DaemonSet
-controller will think that those pods were created by it.  Kubernetes will not stop you from doing
-this.  One case where you might want to do this is manually create a pod with a different value on
-a node for testing.
-
-### Running Pods on Only Some Nodes
-
-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/).
-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).
-
-If you do not specify a `.spec.template.spec.nodeSelector` nor `node affinity`, then the DaemonSet controller will
-create pods on all nodes.
-
-## How Daemon Pods are Scheduled
-
-Normally, the machine that a pod runs on is selected by the Kubernetes scheduler.  However, pods
-created by the Daemon controller have the machine already selected (`.spec.nodeName` is specified
-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 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 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 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.
-- **Service**: Create a service with the same pod selector, and use the service to reach a
-  daemon on a random node. (No way to reach specific node.)
-
-## Updating a DaemonSet
-
-If node labels are changed, the DaemonSet will promptly add pods to newly matching nodes and delete
-pods from newly not-matching nodes.
-
-You can modify the pods that a DaemonSet creates.  However, pods do not allow all
-fields to be updated.  Also, the DaemonSet controller will use the original template the next
-time a node (even with the same name) is created.
-
-
-You can delete a DaemonSet.  If you specify `--cascade=false` with `kubectl`, then the pods
-will be left on the nodes.  You can then create a new DaemonSet with a different template.
-the new DaemonSet with the different template will recognize all the existing pods as having
-matching labels.  It will not modify or delete them despite a mismatch in the pod template.
-You will need to force new pod creation by deleting the pod or deleting the node.
-
-You cannot update a DaemonSet.
-
-Support for updating DaemonSets and controlled updating of nodes is planned.
-
-## Alternatives to DaemonSet
-
-### Init Scripts
-
-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:
-
-- Ability to monitor and manage logs for daemons in the same way as applications.
-- Same config language and tools (e.g. pod templates, `kubectl`) for daemons and applications.
-- Future versions of Kubernetes will likely support integration between DaemonSet-created
-  pods and node upgrade workflows.
-- Running daemons in containers with resource limits increases isolation between daemons from app
-  containers.  However, this can also be accomplished by running the daemons in a container but not in a pod
-  (e.g. start directly via Docker).
-
-### Bare Pods
-
-It is possible to create pods directly which specify a particular node to run on.  However,
-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 DaemonSet rather than creating individual pods.
-
-### Static Pods
-
-It is possible to create pods by writing a file to a certain directory watched by Kubelet.  These
-are called [static pods](/docs/admin/static-pods/).
-Unlike DaemonSet, static pods cannot be managed with kubectl
-or other Kubernetes API clients.  Static pods do not depend on the apiserver, making them useful
-in cluster bootstrapping cases.  Also, static pods may be deprecated in the future.
-
-### Replication Controller
-
-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).
-
-Use a replication controller for stateless services, like frontends, where scaling up and down the
-number of replicas and rolling out updates are more important than controlling exactly which host
-the pod runs on.  Use a Daemon Controller when it is important that a copy of a pod always run on
-all or certain hosts, and when it needs to start before other pods.

docs/admin/disruptions.md

@@ -1,95 +0,0 @@
----
-assignees:
-- davidopp
-title: Pod Disruption Budget
----
-This guide is for anyone wishing to specify safety constraints on pods or anyone
-wishing to write software (typically automation software) that respects those
-constraints.
-
-* TOC
-{:toc}
-
-## Rationale
-
-Various cluster management operations may voluntarily evict pods.  "Voluntary"
-means an eviction can be safely delayed for a reasonable period of time. The
-principal examples today are draining a node for maintenance or upgrade
-(`kubectl drain`), and cluster autoscaling down. In the future the
-[rescheduler](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/rescheduling.md)
-may also perform voluntary evictions.  By contrast, something like evicting pods
-because a node has become unreachable or reports `NotReady`, is not "voluntary."
-
-For voluntary evictions, it can be useful for applications to be able to limit
-the number of pods that are down simultaneously.  For example, a quorum-based application would
-like to ensure that the number of replicas running is never brought below the
-number needed for a quorum, even temporarily. Or a web front end might want to
-ensure that the number of replicas serving load never falls below a certain
-percentage of the total, even briefly.  `PodDisruptionBudget` is an API object
-that specifies the minimum number or percentage of replicas of a collection that
-must be up at a time.  Components that wish to evict a pod subject to disruption
-budget use the `/eviction` subresource; unlike a regular pod deletion, this
-operation may be rejected by the API server if the eviction would cause a
-disruption budget to be violated.
-
-## Specifying a PodDisruptionBudget
-
-A `PodDisruptionBudget` has two components: a label selector `selector` to specify the set of
-pods to which it applies, and `minAvailable` which is a description of the number of pods from that
-set that must still be available after the eviction, i.e. even in the absence
-of the evicted pod. `minAvailable` can be either an absolute number or a percentage.
-So for example, 100% means no voluntary evictions from the set are permitted. In
-typical usage, a single budget would be used for a collection of pods managed by
-a controller—for example, the pods in a single ReplicaSet.
-
-Note that a disruption budget does not truly guarantee that the specified
-number/percentage of pods will always be up.  For example, a node that hosts a
-pod from the collection may fail when the collection is at the minimum size
-specified in the budget, thus bringing the number of available pods from the
-collection below the specified size. The budget can only protect against
-voluntary evictions, not all causes of unavailability.
-
-## Requesting an eviction
-
-If you are writing infrastructure software that wants to produce these voluntary
-evictions, you will need to use the eviction API.  The eviction subresource of a
-pod can be thought of as a kind of policy-controlled DELETE operation on the pod
-itself.  To attempt an eviction (perhaps more REST-precisely, to attempt to
-*create* an eviction), you POST an attempted operation.  Here's an example:
-
-```json
-{
-  "apiVersion": "policy/v1beta1",
-  "kind": "Eviction",
-  "metadata": {
-    "name": "quux",
-    "namespace": "default"
-  }
-}
-```
-
-You can attempt an eviction using `curl`:
-
-```bash
-$ curl -v -H 'Content-type: application/json' http://127.0.0.1:8080/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json
-```
-
-The API can respond in one of three ways.
-
- 1. If the eviction is granted, then the pod is deleted just as if you had sent
-    a `DELETE` request to the pod's URL and you get back `200 OK`.
- 2. If the current state of affairs wouldn't allow an eviction by the rules set
-    forth in the budget, you get back `429 Too Many Requests`.  This is
-    typically used for generic rate limiting of *any* requests, but here we mean
-    that this request isn't allowed *right now* but it may be allowed later.
-    Currently, callers do not get any `Retry-After` advice, but they may in
-    future versions.
- 3. If there is some kind of misconfiguration, like multiple budgets pointing at
-    the same pod, you will get `500 Internal Server Error`.
-
-For a given eviction request, there are two cases.
-
- 1. There is no budget that matches this pod.  In this case, the server always
-    returns `200 OK`.
- 2. There is at least one budget.  In this case, any of the three above responses may
-    apply.

docs/admin/dns.md

@@ -1,389 +0,0 @@
----
-assignees:
-- davidopp
-- thockin
-title: Using DNS Pods and Services
----
-
-## Introduction
-
-As of Kubernetes 1.3, DNS is a built-in service launched automatically using the addon manager [cluster add-on](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/README.md).
-
-Kubernetes DNS schedules a DNS Pod and Service on the cluster, and configures
-the kubelets to tell individual containers to use the DNS Service's IP to
-resolve DNS names.
-
-## What things get DNS names?
-
-Every Service defined in the cluster (including the DNS server itself) is
-assigned a DNS name.  By default, a client Pod's DNS search list will
-include the Pod's own namespace and the cluster's default domain.  This is best
-illustrated by example:
-
-Assume a Service named `foo` in the Kubernetes namespace `bar`.  A Pod running
-in namespace `bar` can look up this service by simply doing a DNS query for
-`foo`.  A Pod running in namespace `quux` can look up this service by doing a
-DNS query for `foo.bar`.
-
-## Supported DNS schema
-
-The following sections detail the supported record types and layout that is
-supported.  Any other layout or names or queries that happen to work are
-considered implementation details and are subject to change without warning.
-
-### Services
-
-#### A records
-
-"Normal" (not headless) Services are assigned a DNS A record for a name of the
-form `my-svc.my-namespace.svc.cluster.local`.  This resolves to the cluster IP
-of the Service.
-
-"Headless" (without a cluster IP) Services are also assigned a DNS A record for
-a name of the form `my-svc.my-namespace.svc.cluster.local`.  Unlike normal
-Services, this resolves to the set of IPs of the pods selected by the Service.
-Clients are expected to consume the set or else use standard round-robin
-selection from the set.
-
-### SRV records
-
-SRV Records are created for named ports that are part of normal or [Headless
-Services](http://releases.k8s.io/docs/user-guide/services/#headless-services).
-For each named port, the SRV record would have the form
-`_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster.local`.
-For a regular service, this resolves to the port number and the CNAME:
-`my-svc.my-namespace.svc.cluster.local`.
-For a headless service, this resolves to multiple answers, one for each pod
-that is backing the service, and contains the port number and a CNAME of the pod
-of the form `auto-generated-name.my-svc.my-namespace.svc.cluster.local`.
-
-### Backwards compatibility
-
-Previous versions of kube-dns made names of the form
-`my-svc.my-namespace.cluster.local` (the 'svc' level was added later).  This
-is no longer supported.
-
-### Pods
-
-#### A Records
-
-When enabled, pods are assigned a DNS A record in the form of `pod-ip-address.my-namespace.pod.cluster.local`.
-
-For example, a pod with IP `1.2.3.4` in the namespace `default` with a DNS name of `cluster.local` would have an entry: `1-2-3-4.default.pod.cluster.local`.
-
-#### A Records and hostname based on Pod's hostname and subdomain fields
-
-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 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
-`pod.beta.kubernetes.io/hostname` annotation value.
-
-v1.2 introduces a beta feature where the user can specify a Pod annotation, `pod.beta.kubernetes.io/subdomain`, to specify the Pod's subdomain.
-The final domain will be "<hostname>.<subdomain>.<pod namespace>.svc.<cluster domain>".
-For example, a Pod with the hostname annotation set to "foo", and the subdomain annotation set to "bar", in namespace "my-namespace", will have the FQDN "foo.bar.my-namespace.svc.cluster.local"
-
-With v1.3, the PodSpec has a `subdomain` field, which can be used to specify the Pod's subdomain. This field value takes precedence over the
-`pod.beta.kubernetes.io/subdomain` annotation value.
-
-Example:
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
-  name: default-subdomain
-spec:
-  selector:
-    name: busybox
-  clusterIP: None
-  ports:
-    - name: foo # Actually, no port is needed.
-      port: 1234 
-      targetPort: 1234
----
-apiVersion: v1
-kind: Pod
-metadata:
-  name: busybox1
-  labels:
-    name: busybox
-spec:
-  hostname: busybox-1
-  subdomain: default-subdomain
-  containers:
-  - image: busybox
-    command:
-      - sleep
-      - "3600"
-    name: busybox
----
-apiVersion: v1
-kind: Pod
-metadata:
-  name: busybox2
-  labels:
-    name: busybox
-spec:
-  hostname: busybox-2
-  subdomain: default-subdomain
-  containers:
-  - image: busybox
-    command:
-      - sleep
-      - "3600"
-    name: busybox
-```
-
-If there exists a headless service in the same namespace as the pod and with the same name as the subdomain, the cluster's KubeDNS Server also returns an A record for the Pod's fully qualified hostname.
-Given a Pod with the hostname set to "busybox-1" and the subdomain set to "default-subdomain", and a headless Service named "default-subdomain" in the same namespace, the pod will see it's own FQDN as "busybox-1.default-subdomain.my-namespace.svc.cluster.local". DNS serves an A record at that name, pointing to the Pod's IP. Both pods "busybox1" and "busybox2" can have their distinct A records. 
-
-As of Kubernetes v1.2, the Endpoints object also has the annotation `endpoints.beta.kubernetes.io/hostnames-map`. Its value is the json representation of map[string(IP)][endpoints.HostRecord], for example: '{"10.245.1.6":{HostName: "my-webserver"}}'.
-If the Endpoints are for a headless service, an A record is created with the format <hostname>.<service name>.<pod namespace>.svc.<cluster domain>
-For the example json, if endpoints are for a headless service named "bar", and one of the endpoints has IP "10.245.1.6", an A record is created with the name "my-webserver.bar.my-namespace.svc.cluster.local" and the A record lookup would return "10.245.1.6".
-This endpoints annotation generally does not need to be specified by end-users, but can used by the internal service controller to deliver the aforementioned feature.
-
-With v1.3, The Endpoints object can specify the `hostname` for any endpoint, along with its IP. The hostname field takes precedence over the hostname value
-that might have been specified via the  `endpoints.beta.kubernetes.io/hostnames-map` annotation.
-
-With v1.3, the following annotations are deprecated: `pod.beta.kubernetes.io/hostname`, `pod.beta.kubernetes.io/subdomain`, `endpoints.beta.kubernetes.io/hostnames-map`
-
-## How do I test if it is working?
-
-### Create a simple Pod to use as a test environment
-
-Create a file named busybox.yaml with the
-following contents:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: busybox
-  namespace: default
-spec:
-  containers:
-  - image: busybox
-    command:
-      - sleep
-      - "3600"
-    imagePullPolicy: IfNotPresent
-    name: busybox
-  restartPolicy: Always
-```
-
-Then create a pod using this file:
-
-```
-kubectl create -f busybox.yaml
-```
-
-### Wait for this pod to go into the running state
-
-You can get its status with:
-```
-kubectl get pods busybox
-```
-
-You should see:
-
-```
-NAME      READY     STATUS    RESTARTS   AGE
-busybox   1/1       Running   0          <some-time>
-```
-
-### Validate that DNS is working
-
-Once that pod is running, you can exec nslookup in that environment:
-
-```
-kubectl exec -ti busybox -- nslookup kubernetes.default
-```
-
-You should see something like:
-
-```
-Server:    10.0.0.10
-Address 1: 10.0.0.10
-
-Name:      kubernetes.default
-Address 1: 10.0.0.1
-```
-
-If you see that, DNS is working correctly.
-
-### Troubleshooting Tips
-
-If the nslookup command fails, check the following:
-
-#### Check the local DNS configuration first
-Take a look inside the resolv.conf file. (See "Inheriting DNS from the node" and "Known issues" below for more information)
-
-```
-kubectl exec busybox cat /etc/resolv.conf
-```
-
-Verify that the search path and name server are set up like the following (note that search path may vary for different cloud providers):
-
-```
-search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internal
-nameserver 10.0.0.10
-options ndots:5
-```
-
-#### Quick diagnosis
-
-Errors such as the following indicate a problem with the kube-dns add-on or associated Services:
-
-```
-$ kubectl exec -ti busybox -- nslookup kubernetes.default
-Server:    10.0.0.10
-Address 1: 10.0.0.10
-
-nslookup: can't resolve 'kubernetes.default'
-```
-
-or
-
-```
-$ kubectl exec -ti busybox -- nslookup kubernetes.default
-Server:    10.0.0.10
-Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
-
-nslookup: can't resolve 'kubernetes.default'
-```
-
-#### Check if the DNS pod is running
-
-Use the kubectl get pods command to verify that the DNS pod is running.
-
-```
-kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
-```
-
-You should see something like:
-
-```
-NAME                                                       READY     STATUS    RESTARTS   AGE
-...
-kube-dns-v19-ezo1y                                         3/3       Running   0           1h
-...
-```
-
-If you see that no pod is running or that the pod has failed/completed, the DNS add-on may not be deployed by default in your current environment and you will have to deploy it manually.
-
-#### Check for Errors in the DNS pod
-
-Use `kubectl logs` command to see logs for the DNS daemons.
-
-```
-kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c kubedns
-kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c dnsmasq
-kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c healthz
-```
-
-See if there is any suspicious log. W, E, F letter at the beginning represent Warning, Error and Failure. Please search for entries that have these as the logging level and use [kubernetes issues](https://github.com/kubernetes/kubernetes/issues) to report unexpected errors.
-
-#### Is DNS service up?
-
-Verify that the DNS service is up by using the `kubectl get service` command.
-
-```
-kubectl get svc --namespace=kube-system
-```
-
-You should see:
-
-```
-NAME                    CLUSTER-IP     EXTERNAL-IP   PORT(S)             AGE
-...
-kube-dns                10.0.0.10      <none>        53/UDP,53/TCP        1h
-...
-```
-
-If you have created the service or in the case it should be created by default but it does not appear, see this [debugging services page](http://kubernetes.io/docs/user-guide/debugging-services/) for more information.
-
-#### Are DNS endpoints exposed?
-
-You can verify that DNS endpoints are exposed by using the `kubectl get endpoints` command.
-
-```
-kubectl get ep kube-dns --namespace=kube-system
-```
-
-You should see something like:
-```
-NAME       ENDPOINTS                       AGE
-kube-dns   10.180.3.17:53,10.180.3.17:53    1h
-```
-
-If you do not see the endpoints, see endpoints section in the [debugging services documentation](http://kubernetes.io/docs/user-guide/debugging-services/).
-
-For additional Kubernetes DNS examples, see the [cluster-dns examples](https://github.com/kubernetes/kubernetes/tree/master/examples/cluster-dns) in the Kubernetes GitHub repository.
-
-## Kubernetes Federation (Multiple Zone support)
-
-Release 1.3 introduced Cluster Federation support for multi-site
-Kubernetes installations. This required some minor
-(backward-compatible) changes to the way
-the Kubernetes cluster DNS server processes DNS queries, to facilitate
-the lookup of federated services (which span multiple Kubernetes clusters).
-See the [Cluster Federation Administrators' Guide](/docs/admin/federation) for more
-details on Cluster Federation and multi-site support.
-
-## How it Works
-
-The running Kubernetes DNS pod holds 3 containers - kubedns, dnsmasq and a health check called healthz.
-The kubedns process watches the Kubernetes master for changes in Services and Endpoints, and maintains
-in-memory lookup structures to service DNS requests. The dnsmasq container adds DNS caching to improve
-performance. The healthz container provides a single health check endpoint while performing dual healthchecks
-(for dnsmasq and kubedns).
-
-The DNS pod is exposed as a Kubernetes Service with a static IP. Once assigned the
-kubelet passes DNS configured using the `--cluster-dns=10.0.0.10` flag to each
-container.
-
-DNS names also need domains. The local domain is configurable, in the kubelet using
-the flag `--cluster-domain=<default local domain>`
-
-The Kubernetes cluster DNS server (based off the [SkyDNS](https://github.com/skynetservices/skydns) library)
-supports forward lookups (A records), service lookups (SRV records) and reverse IP address lookups (PTR records).
-
-## Inheriting DNS from the node
-When running a pod, kubelet will prepend the cluster DNS server and search
-paths to the node's own DNS settings.  If the node is able to resolve DNS names
-specific to the larger environment, pods should be able to, also.  See "Known
-issues" below for a caveat.
-
-If you don't want this, or if you want a different DNS config for pods, you can
-use the kubelet's `--resolv-conf` flag.  Setting it to "" means that pods will
-not inherit DNS.  Setting it to a valid file path means that kubelet will use
-this file instead of `/etc/resolv.conf` for DNS inheritance.
-
-## Known issues
-Kubernetes installs do not configure the nodes' resolv.conf files to use the
-cluster DNS by default, because that process is inherently distro-specific.
-This should probably be implemented eventually.
-
-Linux's libc is impossibly stuck ([see this bug from
-2005](https://bugzilla.redhat.com/show_bug.cgi?id=168253)) with limits of just
-3 DNS `nameserver` records and 6 DNS `search` records.  Kubernetes needs to
-consume 1 `nameserver` record and 3 `search` records.  This means that if a
-local installation already uses 3 `nameserver`s or uses more than 3 `search`es,
-some of those settings will be lost.  As a partial workaround, the node can run
-`dnsmasq` which will provide more `nameserver` entries, but not more `search`
-entries.  You can also use kubelet's `--resolv-conf` flag.
-
-If you are using Alpine version 3.3 or earlier as your base image, DNS may not
-work properly owing to a known issue with Alpine. Check [here](https://github.com/kubernetes/kubernetes/issues/30215)
-for more information.
-
-## References
-
-- [Docs for the DNS cluster addon](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/README.md)
-
-## What's next
-- [Autoscaling the DNS Service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/).

docs/admin/etcd.md

@@ -1,49 +0,0 @@
----
-assignees:
-- lavalamp
-title: Configuring Kubernetes Use of etcd
----
-
-[etcd](https://coreos.com/etcd/docs/latest/) is a highly-available key value
-store which Kubernetes uses for persistent storage of all of its REST API
-objects.
-
-## Configuration: high-level goals
-
-Access Control: give *only* kube-apiserver read/write access to etcd. You do not
-want apiserver's etcd exposed to every node in your cluster (or worse, to the
-internet at large), because access to etcd is equivalent to root in your
-cluster.
-
-Data Reliability: for reasonable safety, either etcd needs to be run as a
-[cluster](/docs/admin/high-availability/#clustering-etcd) (multiple machines each running
-etcd) or etcd's data directory should be located on durable storage (e.g., GCE's
-persistent disk). In either case, if high availability is required--as it might
-be in a production cluster--the data directory ought to be [backed up
-periodically](https://coreos.com/etcd/docs/2.2.1/admin_guide.html#disaster-recovery),
-to reduce downtime in case of corruption.
-
-## Default configuration
-
-The default setup scripts use kubelet's file-based static pods feature to run etcd in a
-[pod](http://releases.k8s.io/{{page.githubbranch}}/cluster/saltbase/salt/etcd/etcd.manifest). This manifest should only
-be run on master VMs. The default location that kubelet scans for manifests is
-`/etc/kubernetes/manifests/`.
-
-## Kubernetes's usage of etcd
-
-By default, Kubernetes objects are stored under the `/registry` key in etcd.
-This path can be prefixed by using the [kube-apiserver](/docs/admin/kube-apiserver) flag
-`--etcd-prefix="/foo"`.
-
-`etcd` is the only place that Kubernetes keeps state.
-
-## Troubleshooting
-
-To test whether `etcd` is running correctly, you can try writing a value to a
-test key. On your master VM (or somewhere with firewalls configured such that
-you can talk to your cluster's etcd), try:
-
-```shell
-curl -fs -X PUT "http://${host}:${port}/v2/keys/_test"
-```

docs/admin/extensible-admission-controllers.md

@@ -0,0 +1,284 @@
+---
+assignees:
+- smarterclayton
+- lavalamp
+- whitlockjc
+- caesrxuchao
+title: Dynamic Admission Control
+---
+
+* TOC
+{:toc}
+
+## Overview
+
+The [admission controllers documentation](/docs/admin/admission-controllers/)
+introduces how to use standard, plugin-style admission controllers. However,
+plugin admission controllers are not flexible enough for all use cases, due to
+the following:
+
+* They need to be compiled into kube-apiserver.
+* They are only configurable when the apiserver starts up.
+
+1.7 introduces two alpha features, *Initializers* and *External Admission
+Webhooks*, that address these limitations. These features allow admission
+controllers to be developed out-of-tree and configured at runtime.
+
+This page describes how to use Initializers and External Admission Webhooks.
+
+## Initializers
+
+### What are initializers?
+
+*Initializer* has two meanings:
+
+* A list of pending pre-initialization tasks, stored in every object's metadata
+  (e.g., "AddMyCorporatePolicySidecar").
+
+* A user customized controller, which actually perform those tasks. The name of the task
+  corresponds to the controller which performs the task. For clarity, we call
+  them *initializer controllers* in this page.
+
+Once the controller has performed its assigned task, it removes its name from
+the list. For example, it may send a PATCH that inserts a container in a pod and
+also removes its name from `metadata.initializers`. Initializers may make
+mutations to objects.
+
+Objects which have a non-empty initializer list are considered uninitialized,
+and are not visible in the API unless specifically requested by using the query parameter,
+`?includeUninitialized=true`.
+
+### When to use initializers?
+
+Initializers are useful for admins to force policies (e.g., the
+[AlwaysPullImages](/docs/admin/admission-controllers/#alwayspullimages)
+admission controller), or to inject defaults (e.g., the
+[DefaultStorageClass](/docs/admin/admission-controllers/#defaultstorageclass)
+admission controller), etc.
+
+**Note:** If your use case does not involve mutating objects, consider using
+external admission webhooks, as they have better performance.
+
+### How are initializers triggered?
+
+When an object is POSTed, it is checked against all existing
+`initializerConfiguration` objects (explained below). For all that it matches,
+all `spec.initializers[].name`s are appended to the new object's
+`metadata.initializers` field.
+
+An initializer controller should list and watch for uninitialized objects, by
+using the query parameter `?includeUninitialized=true`. If using client-go, just
+set 
+[listOptions.includeUninitialized](https://github.com/kubernetes/kubernetes/blob/v1.7.0-rc.1/staging/src/k8s.io/apimachinery/pkg/apis/meta/v1/types.go#L315)
+to true.
+
+For the observed uninitialized objects, an initializer controller should first
+check if its name matches `metadata.initializers[0]`. If so, it should then
+perform its assigned task and remove its name from the list.
+
+### Enable initializers alpha feature
+
+*Initializers* is an alpha feature, so it is disabled by default. To turn it on,
+you need to:
+
+* Include "Initializer" in the `--admission-control` flag when starting
+  `kube-apiserver`. If you have multiple `kube-apiserver` replicas, all should
+  have the same flag setting.
+
+* Enable the dynamic admission controller registration API by adding
+  `admissionregistration.k8s.io/v1alpha1` to the `--runtime-config` flag passed
+  to `kube-apiserver`, e.g.
+  `--runtime-config=admissionregistration.k8s.io/v1alpha1`. Again, all replicas
+  should have the same flag setting.
+
+### Deploy an initializer controller
+
+You should deploy an initializer controller via the [deployment
+API](/docs/api-reference/v1.6/#deployment-v1beta1-apps).
+
+### Configure initializers on the fly
+
+You can configure what initializers are enabled and what resources are subject
+to the initializers by creating `initializerconfigurations`.
+
+You should first deploy the initializer controller and make sure that it is
+working properly before creating the `initializerconfigurations`. Otherwise, any
+newly created resources will be stuck in an uninitialized state.
+
+The following is an example `initiallizerConfiguration`.
+
+```yaml
+apiVersion: admissionregistration.k8s.io/v1alpha1
+kind: InitializerConfiguration
+metadata:
+  name: example-config
+spec:
+  initializers:
+    # the name needs to be fully qualified, i.e., containing at least two "."
+    - name: podimage.example.com
+      rules:
+        # apiGroups, apiVersion, resources all support wildcard "*".
+        # "*" cannot be mixed with non-wildcard.
+        - apiGroups:
+            - ""
+          apiVersions:
+            - v1
+          resources:
+            - pods
+```
+
+Make sure that all expansions of the `<apiGroup, apiVersions, resources>` tuple
+in a `rule` are valid. If they are not, separate them in different `rules`.
+
+After you create the `initializerConfiguration`, the system will take a few
+seconds to honor the new configuration.
+
+## External Admission Webhooks
+
+### What are external admission webhooks?
+
+External admission webhooks are HTTP callbacks that are intended to receive
+admission requests and do something with them. What an external admission
+webhook does is up to you, but there is an
+[interface](https://github.com/kubernetes/kubernetes/blob/v1.7.0-rc.1/pkg/apis/admission/v1alpha1/types.go)
+that it must adhere to so that it responds with whether or not the
+admission request should be allowed. 
+
+Unlike initializers or the plugin-style admission controllers, external
+admission webhooks are not allowed to mutate the admission request in any way.
+
+Because admission is a high security operation, the external admission webhooks
+must support TLS.
+
+### When to use admission webhooks?
+
+A simple example use case for an external admission webhook is to do semantic validation
+of Kubernetes resources. Suppose that your infrastructure requires that all `Pod`
+resources have a common set of labels, and you do not want any `Pod` to be
+persisted to Kubernetes if those needs are not met. You could write your
+external admission webhook to do this validation and respond accordingly.
+
+### How are external admission webhooks triggered?
+
+Whenever a request comes in, the `GenericAdmissionWebhook` admission plugin will
+get the list of interested external admission webhooks from
+`externalAdmissionHookConfiguration` objects (explained below) and call them in
+parallel. If **all** of the external admission webhooks approve the admission
+request, the admission chain continues. If **any** of the external admission
+webhooks deny the admission request, the admission request will be denied, and
+the reason for doing so will be based on the _first_ external admission webhook
+denial reason. _This means if there is more than one external admission webhook
+that denied the admission request, only the first will be returned to the
+user._ If there is an error encountered when calling an external admission
+webhook, that request is ignored and will not be used to approve/deny the
+admission request.
+
+**Note:** The admission chain depends solely on the order of the
+`--admission-control` option passed to `kube-apiserver`.
+
+### Enable external admission webhooks
+
+*External Admission Webhooks* is an alpha feature, so it is disabled by default.
+To turn it on, you need to
+
+* Include "GenericAdmissionWebhook" in the `--admission-control` flag when
+  starting the apiserver. If you have multiple `kube-apiserver` replicas, all
+  should have the same flag setting.
+
+* Enable the dynamic admission controller registration API by adding
+  `admissionregistration.k8s.io/v1alpha1` to the `--runtime-config` flag passed
+  to `kube-apiserver`, e.g.
+  `--runtime-config=admissionregistration.k8s.io/v1alpha1`. Again, all replicas
+  should have the same flag setting.
+
+### Write a webhook admission controller
+
+See [caesarxuchao/example-webhook-admission-controller](https://github.com/caesarxuchao/example-webhook-admission-controller)
+for an example webhook admission controller.
+
+The communication between the webhook admission controller and the apiserver, or
+more precisely, the GenericAdmissionWebhook admission controller, needs to be
+TLS secured. You need to generate a CA cert and use it to sign the server cert
+used by your webhook admission controller. The pem formatted CA cert is supplied
+to the apiserver via the dynamic registration API
+`externaladmissionhookconfigurations.clientConfig.caBundle`.
+
+For each request received by the apiserver, the GenericAdmissionWebhook
+admission controller sends an
+[admissionReview](https://github.com/kubernetes/kubernetes/blob/v1.7.0-rc.1/pkg/apis/admission/v1alpha1/types.go#L27)
+to the relevant webhook admission controller. The webhook admission controller
+gathers information like `object`, `oldobject`, and `userInfo`, from
+`admissionReview.spec`, sends back a response with the body also being the
+`admissionReview`, whose `status` field is filled with the admission decision.
+
+### Deploy the webhook admission controller
+
+See [caesarxuchao/example-webhook-admission-controller deployment](https://github.com/caesarxuchao/example-webhook-admission-controller/tree/master/deployment)
+for an example deployment.
+
+The webhook admission controller should be deployed via the
+[deployment API](/docs/api-reference/v1.6/#deployment-v1beta1-apps).
+You also need to create a
+[service](/docs/api-reference/v1.6/#service-v1-core) as the
+front-end of the deployment.
+
+### Configure webhook admission controller on the fly
+
+You can configure what webhook admission controllers are enabled and what
+resources are subject to the admission controller via creating
+externaladmissionhookconfigurations.
+
+We suggest that you first deploy the webhook admission controller and make sure
+it is working properly before creating the externaladmissionhookconfigurations.
+Otherwise, depending whether the webhook is configured as fail open or fail
+closed, operations will be unconditionally accepted or rejected. 
+
+The following is an example externaladmissionhookconfiguration.
+
+```yaml
+apiVersion: admissionregistration.k8s.io/v1alpha1
+kind: ExternalAdmissionHookConfiguration
+metadata:
+  name: example-config
+externalAdmissionHooks:
+- name: pod-image.k8s.io
+  rules:
+  - apiGroups:
+    - ""
+    apiVersions:
+    - v1
+    operations:
+    - CREATE
+    resources:
+    - pods
+  failurePolicy: Ignore
+  clientConfig:
+    caBundle: <pem encoded ca cert that signs the server cert used by the webhook>
+    service:
+      name: <name of the front-end service>
+      namespace: <namespace of the front-end service>
+```
+
+For a request received by the apiserver, if the request matches any of the
+`rules` of an `externalAdmissionHook`, the `GenericAdmissionWebhook` admission
+controller will send an `admissionReview` request to the `externalAdmissionHook`
+to ask for admission decision.
+
+The `rule` is similar to the `rule` in `initializerConfiguration`, with two
+differences:
+
+* The addition of the `operations` field, specifying what operations the webhook
+  is interested in;
+
+* The `resources` field accepts subresources in the form or resource/subresource.
+
+Make sure that all expansions of the `<apiGroup, apiVersions,resources>` tuple
+in a `rule` are valid. If they are not, separate them to different `rules`.
+
+You can also specify the `failurePolicy`. In 1.7, the system supports `Ignore`
+and `Fail` policies, meaning that upon a communication error with the webhook
+admission controller, the `GenericAdmissionWebhook` can admit or reject the
+operation based on the configured policy.
+
+After you create the `initializerConfiguration`, the system will take a few
+seconds to honor the new configuration.

docs/admin/federation-apiserver.md

@@ -2,7 +2,6 @@
 title: federation-apiserver
 notitle: true
 ---
-
 ## federation-apiserver
 
 
@@ -26,14 +25,14 @@ 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. 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.
       --audit-log-path string                                   If set, all requests coming to the apiserver will be logged to this file.
+      --authentication-token-webhook-cache-ttl duration         The duration to cache responses from the webhook token authenticator. Default is 2m. (default 2m0s)
+      --authentication-token-webhook-config-file string         File with webhook configuration for token authentication in kubeconfig format. The API server will query the remote service to determine authentication for bearer tokens.
       --authorization-mode string                               Ordered list of plug-ins to do authorization on secure port. Comma-delimited list of: AlwaysAllow,AlwaysDeny,ABAC,Webhook,RBAC. (default "AlwaysAllow")
       --authorization-policy-file string                        File with authorization policy in csv format, used with --authorization-mode=ABAC, on the secure port.
-      --authorization-rbac-super-user string                    If specified, a username which avoids RBAC authorization checks and role binding privilege escalation checks, to be used with --authorization-mode=RBAC.
       --authorization-webhook-cache-authorized-ttl duration     The duration to cache 'authorized' responses from the webhook authorizer. Default is 5m. (default 5m0s)
       --authorization-webhook-cache-unauthorized-ttl duration   The duration to cache 'unauthorized' responses from the webhook authorizer. Default is 30s. (default 30s)
       --authorization-webhook-config-file string                File with webhook configuration in kubeconfig format, used with --authorization-mode=Webhook. The API server will query the remote service to determine access on the API server's secure port.
@@ -43,7 +42,7 @@ federation-apiserver
       --client-ca-file string                                   If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate.
       --cloud-config string                                     The path to the cloud provider configuration file. Empty string for no configuration file.
       --cloud-provider string                                   The provider for cloud services. Empty string for no provider.
-      --contention-profiling                                    Enable contention profiling. Requires --profiling to be set to work.
+      --contention-profiling                                    Enable lock contention profiling, if profiling is enabled
       --cors-allowed-origins stringSlice                        List of allowed origins for CORS, comma separated.  An allowed origin can be a regular expression to support subdomain matching. If this list is empty CORS will not be enabled.
       --delete-collection-workers int                           Number of workers spawned for DeleteCollection call. These are used to speed up namespace cleanup. (default 1)
       --deserialization-cache-size int                          Number of deserialized json objects to cache in memory.
@@ -52,29 +51,33 @@ federation-apiserver
       --etcd-cafile string                                      SSL Certificate Authority file used to secure etcd communication.
       --etcd-certfile string                                    SSL certification file used to secure etcd communication.
       --etcd-keyfile string                                     SSL key file used to secure etcd communication.
-      --etcd-prefix string                                      The prefix for all resource paths in etcd. (default "/registry")
+      --etcd-prefix string                                      The prefix to prepend to all resource paths in etcd. (default "/registry")
       --etcd-quorum-read                                        If true, enable quorum read.
       --etcd-servers stringSlice                                List of etcd servers to connect with (scheme://ip:port), comma separated.
       --etcd-servers-overrides stringSlice                      Per-resource etcd servers overrides, comma separated. The individual override format: group/resource#servers, where servers are http://ip:port, semicolon separated.
       --event-ttl duration                                      Amount of time to retain events. Default is 1h. (default 1h0m0s)
+      --experimental-bootstrap-token-auth                       Enable to allow secrets of type 'bootstrap.kubernetes.io/token' in the 'kube-system' namespace to be used for TLS bootstrapping authentication.
       --experimental-keystone-ca-file string                    If set, the Keystone server's certificate will be verified by one of the authorities in the experimental-keystone-ca-file, otherwise the host's root CA set will be used.
       --experimental-keystone-url string                        If passed, activates the keystone authentication plugin.
       --external-hostname string                                The hostname to use when generating externalized URLs for this master (e.g. Swagger API Docs).
       --feature-gates mapStringBool                             A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
+Accelerators=true|false (ALPHA - default=false)
+AffinityInAnnotations=true|false (ALPHA - default=false)
 AllAlpha=true|false (ALPHA - default=false)
 AllowExtTrafficLocalEndpoints=true|false (BETA - default=true)
 AppArmor=true|false (BETA - default=true)
 DynamicKubeletConfig=true|false (ALPHA - default=false)
 DynamicVolumeProvisioning=true|false (ALPHA - default=true)
-ExperimentalHostUserNamespaceDefaulting=true|false (ALPHA - default=false)
-StreamingProxyRedirects=true|false (ALPHA - default=false)
+ExperimentalCriticalPodAnnotation=true|false (ALPHA - default=false)
+ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
+StreamingProxyRedirects=true|false (BETA - default=true)
+TaintBasedEvictions=true|false (ALPHA - default=false)
       --insecure-allow-any-token username/group1,group2         If set, your server will be INSECURE.  Any token will be allowed and user information will be parsed from the token as username/group1,group2
       --insecure-bind-address ip                                The IP address on which to serve the --insecure-port (set to 0.0.0.0 for all interfaces). Defaults to localhost. (default 127.0.0.1)
       --insecure-port int                                       The port on which to serve unsecured, unauthenticated access. Default 8080. It is assumed that firewall rules are set up such that this port is not reachable from outside of the cluster and that port 443 on the cluster's public address is proxied to this port. This is performed by nginx in the default setup. (default 8080)
-      --kubernetes-service-node-port int                        If non-zero, the Kubernetes master service (which apiserver creates/maintains) will be of type NodePort, using this as the value of the port. If zero, the Kubernetes master service will be of type ClusterIP.
-      --long-running-request-regexp string                      A regular expression matching long running requests which should be excluded from maximum inflight request handling. (default "(/|^)((watch|proxy)(/|$)|(logs?|portforward|exec|attach)/?$)")
       --master-service-namespace string                         DEPRECATED: the namespace from which the kubernetes master services should be injected into pods. (default "default")
-      --max-requests-inflight int                               The maximum number of requests in flight at a given time. When the server exceeds this, it rejects requests. Zero for no limit. (default 400)
+      --max-mutating-requests-inflight int                      The maximum number of mutating requests in flight at a given time. When the server exceeds this, it rejects requests. Zero for no limit. (default 200)
+      --max-requests-inflight int                               The maximum number of non-mutating requests in flight at a given time. When the server exceeds this, it rejects requests. Zero for no limit. (default 400)
       --min-request-timeout int                                 An optional field indicating the minimum number of seconds a handler must keep a request open before timing it out. Currently only honored by the watch request handler, which picks a randomized value above this number as the connection timeout, to spread out load. (default 1800)
       --oidc-ca-file string                                     If set, the OpenID server's certificate will be verified by one of the authorities in the oidc-ca-file, otherwise the host's root CA set will be used.
       --oidc-client-id string                                   The client ID for the OpenID Connect client, must be set if oidc-issuer-url is set.
@@ -84,16 +87,18 @@ StreamingProxyRedirects=true|false (ALPHA - default=false)
       --profiling                                               Enable profiling via web interface host:port/debug/pprof/ (default true)
       --requestheader-allowed-names stringSlice                 List of client certificate common names to allow to provide usernames in headers specified by --requestheader-username-headers. If empty, any client certificate validated by the authorities in --requestheader-client-ca-file is allowed.
       --requestheader-client-ca-file string                     Root certificate bundle to use to verify client certificates on incoming requests before trusting usernames in headers specified by --requestheader-username-headers
+      --requestheader-extra-headers-prefix stringSlice          List of request header prefixes to inspect. X-Remote-Extra- is suggested.
+      --requestheader-group-headers stringSlice                 List of request headers to inspect for groups. X-Remote-Group is suggested.
       --requestheader-username-headers stringSlice              List of request headers to inspect for usernames. X-Remote-User is common.
       --runtime-config mapStringString                          A set of key=value pairs that describe runtime configuration that may be passed to apiserver. apis/<groupVersion> key can be used to turn on/off specific api versions. apis/<groupVersion>/<resource> can be used to turn on/off specific resources. api/all and api/legacy are special keys to control all and legacy api versions respectively.
       --secure-port int                                         The port on which to serve HTTPS with authentication and authorization. If 0, don't serve HTTPS at all. (default 6443)
-      --service-cluster-ip-range ipNet                          A CIDR notation IP range from which to assign service cluster IPs. This must not overlap with any IP ranges assigned to nodes for pods.
-      --service-node-port-range portRange                       A port range to reserve for services with NodePort visibility. Example: '30000-32767'. Inclusive at both ends of the range. (default 30000-32767)
-      --storage-backend string                                  The storage backend for persistence. Options: 'etcd2' (default), 'etcd3'.
-      --storage-media-type string                               The media type to use to store objects in storage. Defaults to application/json. Some resources may only support a specific media type and will ignore this setting. (default "application/json")
-      --storage-versions string                                 The per-group version to store resources in. Specified in the format "group1/version1,group2/version2,...". In the case where objects are moved from one group to the other, you may specify the format "group1=group2/v1beta1,group3/v1beta1,...". You only need to pass the groups you wish to change from the defaults. It defaults to a list of preferred versions of all registered groups, which is derived from the KUBE_API_VERSIONS environment variable. (default "apps/v1beta1,authentication.k8s.io/v1beta1,authorization.k8s.io/v1beta1,autoscaling/v1,batch/v1,certificates.k8s.io/v1alpha1,componentconfig/v1alpha1,extensions/v1beta1,federation/v1beta1,policy/v1beta1,rbac.authorization.k8s.io/v1alpha1,storage.k8s.io/v1beta1,v1")
+      --service-account-key-file stringArray                    File containing PEM-encoded x509 RSA or ECDSA private or public keys, used to verify ServiceAccount tokens. If unspecified, --tls-private-key-file is used. The specified file can contain multiple keys, and the flag can be specified multiple times with different files.
+      --service-account-lookup                                  If true, validate ServiceAccount tokens exist in etcd as part of authentication.
+      --storage-backend string                                  The storage backend for persistence. Options: 'etcd3' (default), 'etcd2'.
+      --storage-media-type string                               The media type to use to store objects in storage. Some resources or storage backends may only support a specific media type and will ignore this setting. (default "application/vnd.kubernetes.protobuf")
+      --storage-versions string                                 The per-group version to store resources in. Specified in the format "group1/version1,group2/version2,...". In the case where objects are moved from one group to the other, you may specify the format "group1=group2/v1beta1,group3/v1beta1,...". You only need to pass the groups you wish to change from the defaults. It defaults to a list of preferred versions of all registered groups, which is derived from the KUBE_API_VERSIONS environment variable. (default "apps/v1beta1,authentication.k8s.io/v1,authorization.k8s.io/v1,autoscaling/v1,batch/v1,certificates.k8s.io/v1beta1,componentconfig/v1alpha1,extensions/v1beta1,federation/v1beta1,policy/v1beta1,rbac.authorization.k8s.io/v1beta1,settings.k8s.io/v1alpha1,storage.k8s.io/v1beta1,v1")
       --target-ram-mb int                                       Memory limit for apiserver in MB (used to configure sizes of caches, etc.)
-      --tls-ca-file string                                      If set, this certificate authority will used for secure access from Admission Controllers. This must be a valid PEM-encoded CA bundle.
+      --tls-ca-file string                                      If set, this certificate authority will used for secure access from Admission Controllers. This must be a valid PEM-encoded CA bundle. Altneratively, the certificate authority can be appended to the certificate provided by --tls-cert-file.
       --tls-cert-file string                                    File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to /var/run/kubernetes.
       --tls-private-key-file string                             File containing the default x509 private key matching --tls-cert-file.
       --tls-sni-cert-key namedCertKey                           A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.key,example.crt" or "*.foo.com,foo.com:foo.key,foo.crt". (default [])
@@ -102,9 +107,4 @@ StreamingProxyRedirects=true|false (ALPHA - default=false)
       --watch-cache-sizes stringSlice                           List of watch cache sizes for every resource (pods, nodes, etc.), comma separated. The individual override format: resource#size, where size is a number. It takes effect when watch-cache is enabled.
 ```
 
-###### Auto generated by spf13/cobra on 13-Dec-2016
-
-
-<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
-[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/admin/federation-apiserver.md?pixel)]()
-<!-- END MUNGE: GENERATED_ANALYTICS -->
+###### Auto generated by spf13/cobra on 21-Mar-2017

docs/admin/federation-controller-manager.md

@@ -1,8 +1,7 @@
 ---
-title: federation-controller-mananger
+title: federation-controller-manager
 notitle: true
 ---
-
 ## federation-controller-manager
 
 
@@ -29,7 +28,9 @@ federation-controller-manager
       --cluster-monitor-period duration        The period for syncing ClusterStatus in ClusterController. (default 40s)
       --concurrent-replicaset-syncs int        The number of ReplicaSets syncing operations that will be done concurrently. Larger number = faster endpoint updating, but more CPU (and network) load (default 10)
       --concurrent-service-syncs int           The number of service syncing operations that will be done concurrently. Larger number = faster endpoint updating, but more CPU (and network) load (default 10)
-      --dns-provider string                    DNS provider. Valid values are: ["google-clouddns" "aws-route53"]
+      --contention-profiling                   Enable lock contention profiling, if profiling is enabled
+      --controllers mapStringString            A set of key=value pairs that describe controller configuration to enable/disable specific controllers. Key should be the resource name (like services) and value should be true or false. For example: services=false,ingresses=false
+      --dns-provider string                    DNS provider. Valid values are: ["aws-route53" "coredns" "google-clouddns"]
       --dns-provider-config string             Path to config file for configuring DNS provider.
       --federated-api-burst int                Burst to use while talking with federation apiserver (default 30)
       --federated-api-qps float32              QPS to use while talking with federation apiserver (default 20)
@@ -48,9 +49,4 @@ federation-controller-manager
       --zone-name string                       Zone name, like example.com.
 ```
 
-###### Auto generated by spf13/cobra on 13-Dec-2016
-
-
-<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
-[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/admin/federation-controller-manager.md?pixel)]()
-<!-- END MUNGE: GENERATED_ANALYTICS -->
+###### Auto generated by spf13/cobra on 21-Mar-2017

docs/admin/federation/index.md

@@ -3,9 +3,11 @@ assignees:
 - madhusudancs
 - mml
 - nikhiljindal
-title: Using `federation-up` and `deploy.sh`
+title: (Deprecated) Using `federation-up` and `deploy.sh`
 ---
 
+## The mechanisms explained in this doc to setup federation are deprecated. [`kubefed`](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) is now the recommended way to deploy federation.
+
 This guide explains how to set up cluster federation that lets us control multiple Kubernetes clusters.
 
 
@@ -127,7 +129,7 @@ $ federation/deploy/deploy.sh deploy_federation
 ```
 
 This spins up the federation control components as pods managed by
-[`Deployments`](http://kubernetes.io/docs/user-guide/deployments/) on your
+[`Deployments`](/docs/concepts/workloads/controllers/deployment/) on your
 existing Kubernetes cluster. It also starts a
 [`type: LoadBalancer`](http://kubernetes.io/docs/user-guide/services/#type-loadbalancer)
 [`Service`](http://kubernetes.io/docs/user-guide/services/) for the
@@ -245,7 +247,7 @@ federation, and
 in your federation DNS.
 
 You can find more details about config maps in general at
-http://kubernetes.io/docs/user-guide/configmap/.
+[config map](http://kubernetes.io/docs/user-guide/configmap/).
 
 ### Kubernetes 1.4 and earlier: Setting federations flag on kube-dns-rc
 
@@ -383,4 +385,4 @@ if required.
 
 ## For more information
 
- * [Federation proposal](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/proposals/federation.md) details use cases that motivated this work.
+ * [Federation proposal](https://git.k8s.io/community/contributors/design-proposals/federation.md) details use cases that motivated this work.

docs/admin/federation/kubefed.md

@@ -1,208 +0,0 @@
----
-assignees:
-- madhusudancs
-title: Setting up Cluster Federation with Kubefed
----
-
-* TOC
-{:toc}
-
-Kubernetes version 1.5 includes a new command line tool called
-`kubefed` to help you administrate your federated clusters.
-`kubefed` helps you to deploy a new Kubernetes cluster federation
-control plane, and to add clusters to or remove clusters from an
-existing federation control plane.
-
-This guide explains how to administer a Kubernetes Cluster Federation
-using `kubefed`.
-
-> Note: `kubefed` is an alpha feature in Kubernetes 1.5.
-
-## Prerequisites
-
-This guide assumes that you have a running Kubernetes cluster. Please
-see one of the [getting started](/docs/getting-started-guides/) guides
-for installation instructions for your platform.
-
-
-## Getting `kubefed`
-
-Download the client tarball corresponding to Kubernetes version 1.5
-or later
-[from the release page](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md),
-extract the binaries in the tarball to one of the directories
-in your `$PATH` and set the executable permission on those binaries.
-
-Note: The URL in the curl command below downloads the binaries for
-Linux amd64. If you are on a different platform, please use the URL
-for the binaries appropriate for your platform. You can find the list
-of available binaries on the [release page](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#client-binaries-3)
-
-
-```shell
-curl -O https://storage.googleapis.com/kubernetes-release/release/v1.5.0/kubernetes-client-linux-amd64.tar.gz
-tar -xzvf kubernetes-client-linux-amd64.tar.gz
-sudo cp kubernetes/client/bin/kubefed /usr/local/bin
-sudo chmod +x /usr/local/bin/kubefed
-sudo cp kubernetes/client/bin/kubectl /usr/local/bin
-sudo chmod +x /usr/local/bin/kubectl
-```
-
-
-## Choosing a host cluster.
-
-You'll need to choose one of your Kubernetes clusters to be the
-*host cluster*. The host cluster hosts the components that make up
-your federation control plane. Ensure that you have a `kubeconfig`
-entry in your local `kubeconfig` that corresponds to the host cluster.
-You can verify that you have the required `kubeconfig` entry by
-running:
-
-```shell
-kubectl config get-contexts
-```
-
-The output should contain an entry corresponding to your host cluster,
-similar to the following:
-
-```
-CURRENT   NAME                                          CLUSTER                                       AUTHINFO                                      NAMESPACE
-          gke_myproject_asia-east1-b_gce-asia-east1     gke_myproject_asia-east1-b_gce-asia-east1     gke_myproject_asia-east1-b_gce-asia-east1
-```
-
-
-You'll need to provide the `kubeconfig` context (called name in the
-entry above) for your host cluster when you deploy your federation
-control plane.
-
-
-## Deploying a federation control plane.
-
-"To deploy a federation control plane on your host cluster, run
-`kubefed init` command. When you use `kubefed init`, you must provide
-the following:
-
-* Federation name
-* `--host-cluster-context`, the `kubeconfig` context for the host cluster
-* `--dns-zone-name`, a domain name suffix for your federated services
-
-The following example command deploys a federation control plane with
-the name `fellowship`, a host cluster context `rivendell`, and the
-domain suffix `example.com`:
-
-```shell
-kubefed init fellowship --host-cluster-context=rivendell  --dns-zone-name="example.com"
-```
-
-The domain suffix you specify in `--dns-zone-name` must be an existing
-domain that you control, and that is programmable by your DNS provider.
-
-`kubefed init` sets up the federation control plane in the host
-cluster and also adds an entry for the federation API server in your
-local kubeconfig. Note that in the alpha release in Kubernetes 1.5,
-`kubefed init` does not automatically set the current context to the
-newly deployed federation. You can set the current context manually by
-running:
-
-```shell
-kubectl config use-context fellowship
-```
-
-where `fellowship` is the name of your federation.
-
-
-## Adding a cluster to a federation
-
-Once you've deployed a federation control plane, you'll need to make
-that control plane aware of the clusters it should manage. You can add
-a cluster to your federation by using the `kubefed join` command.
-
-To use `kubefed join`, you'll need to provide the name of the cluster
-you want to add to the federation, and the `--host-cluster-context`
-for the federation control plane's host cluster.
-
-The following example command adds the cluster `gondor` to the
-federation with host cluster `rivendell`:
-
-```
-kubefed join gondor --host-cluster-context=rivendell
-```
-
-> Note: Kubernetes requires that you manually join clusters to a
-federation because the federation control plane manages only those
-clusters that it is responsible for managing. Adding a cluster tells
-the federation control plane that it is responsible for managing that
-cluster.
-
-### Naming rules and customization
-
-The cluster name you supply to `kubefed join` must be a valid RFC 1035
-label.
-
-Furthermore, federation control plane requires credentials of the
-joined clusters to operate on them. These credentials are obtained
-from the local kubeconfig. `kubefed join` uses the cluster name
-specified as the argument to look for the cluster's context in the
-local kubeconfig. If it fails to find a matching context, it exits
-with an error.
-
-This might cause issues in cases where context names for each cluster
-in the federation don't follow
-[RFC 1035](https://www.ietf.org/rfc/rfc1035.txt) label naming rules.
-In such cases, you can specify a cluster name that conforms to the
-[RFC 1035](https://www.ietf.org/rfc/rfc1035.txt) label naming rules
-and specify the cluster context using the `--cluster-context` flag.
-For example, if context of the cluster your are joining is
-`gondor_needs-no_king`, then you can join the cluster by running:
-
-```shell
-kubefed join gondor --host-cluster-context=rivendell --cluster-context=gondor_needs-no_king
-```
-
-#### Secret name
-
-Cluster credentials required by the federation control plane as
-described above are stored as a secret in the host cluster. The name
-of the secret is also derived from the cluster name.
-
-However, the name of a secret object in Kubernetes should conform
-to the DNS subdomain name specification described in
-[RFC 1123](https://tools.ietf.org/html/rfc1123). If this isn't the
-case, you can pass the secret name to `kubefed join` using the
-`--secret-name` flag. For example, if the cluster name is `noldor` and
-the secret name is `11kingdom`, you can join the cluster by
-running:
-
-```shell
-kubefed join noldor --host-cluster-context=rivendell --secret-name=11kingdom
-```
-
-Note: If your cluster name does not conform to the DNS subdomain name
-specification, all you need to do is supply the secret name via the
-`--secret-name` flag. `kubefed join` automatically creates the secret
-for you.
-
-
-## Removing a cluster from a federation
-
-To remove a cluster from a federation, run the `kubefed unjoin`
-command with the cluster name and the federation's
-`--host-cluster-context`:
-
-```
-kubefed unjoin gondor --host-cluster-context=rivendell
-```
-
-
-## Turning down the federation control plane:
-
-Proper cleanup of federation control plane is not fully implemented in
-this alpha release of `kubefed`. However, for the time being, deleting
-the federation system namespace should remove all the resources except
-the persistent storage volume dynamically provisioned for the
-federation control plane's etcd. You can delete the federation
-namespace by running the following command:
-
-```
-$ kubectl delete ns federation-system
-```

docs/admin/garbage-collection.md

@@ -1,56 +0,0 @@
----
-assignees:
-- mikedanese
-title: Configuring kubelet Garbage Collection
----
-
-* TOC
-{:toc}
-
-Garbage collection is a helpful function of kubelet that will clean up unused images and unused containers. Kubelet will perform garbage collection for containers every minute and garbage collection for images every five minutes.
-
-External garbage collection tools are not recommended as these tools can potentially break the behavior of kubelet by removing containers expected to exist.
-
-### Image Collection
-
-Kubernetes manages lifecycle of all images through imageManager, with the cooperation
-of cadvisor.
-
-The policy for garbage collecting images takes two factors into consideration:
-`HighThresholdPercent` and `LowThresholdPercent`. Disk usage above the high threshold
-will trigger garbage collection. The garbage collection will delete least recently used images until the low
-threshold has been met.
-
-### Container Collection
-
-The policy for garbage collecting containers considers three user-defined variables. `MinAge` is the minimum age at which a container can be garbage collected. `MaxPerPodContainer` is the maximum number of dead containers any single
-pod (UID, container name) pair is allowed to have. `MaxContainers` is the maximum number of total dead containers. These variables can be individually disabled by setting 'MinAge' to zero and setting 'MaxPerPodContainer' and 'MaxContainers' respectively to less than zero.
-
-Kubelet will act on containers that are unidentified, deleted, or outside of the boundaries set by the previously mentioned flags. The oldest containers will generally be removed first. 'MaxPerPodContainer' and 'MaxContainer' may potentially conflict with each other in situations where retaining the maximum number of containers per pod ('MaxPerPodContainer') would go outside the allowable range of global dead containers ('MaxContainers'). 'MaxPerPodContainer' would be adjusted in this situation: A worst case scenario would be to downgrade 'MaxPerPodContainer' to 1 and evict the oldest containers. Additionally, containers owned by pods that have been deleted are removed once they are older than `MinAge`.
-
-Containers that are not managed by kubelet are not subject to container garbage collection.
-
-### User Configuration
-
-Users can adjust the following thresholds to tune image garbage collection with the following kubelet flags :
-
-1. `image-gc-high-threshold`, the percent of disk usage which triggers image garbage collection.
-Default is 90%.
-2. `image-gc-low-threshold`, the percent of disk usage to which image garbage collection attempts
-to free. Default is 80%.
-
-We also allow users to customize garbage collection policy through the following kubelet flags:
-
-1. `minimum-container-ttl-duration`, minimum age for a finished container before it is
-garbage collected. Default is 1 minute.
-2. `maximum-dead-containers-per-container`, maximum number of old instances to retain
-per container. Default is 2.
-3. `maximum-dead-containers`, maximum number of old instances of containers to retain globally.
-Default is 100.
-
-Containers can potentially be garbage collected before their usefulness has expired. These containers
-can contain logs and other data that can be useful for troubleshooting. A sufficiently large value for
-`maximum-dead-containers-per-container` is highly recommended to allow at least 2 dead containers to be
-retained per expected container. A higher value for `maximum-dead-containers` is also recommended for a
-similar reason.
-See [this issue](https://github.com/kubernetes/kubernetes/issues/13287) for more details.

docs/admin/ha-master-gce.md

@@ -1,158 +0,0 @@
----
-assignees:
-- jszczepkowski
-title: Setting up High-Availability Kubernetes Masters
----
-
-* TOC
-{:toc}
-
-Kubernetes version 1.5 adds alpha support for replicating Kubernetes masters in `kube-up` or `kube-down` scripts for Google Compute Engine.
-This document describes how to use kube-up/down scripts to manage highly available (HA) masters and how HA masters are implemented for use with GCE.
-
-## Starting an HA-compatible cluster
-
-To create a new HA-compatible cluster, you must set the following flags in your `kube-up` script:
-
-* `MULTIZONE=true` - to prevent removal of master replicas kubelets from zones different than server's default zone.
-Required if you want to run master replicas in different zones, which is recommended.
-
-* `ENABLE_ETCD_QUORUM_READS=true` - to ensure that reads from all API servers will return most up-to-date data.
-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 following flag:
-
-* `KUBE_GCE_ZONE=zone` - zone where the first master replica will run.
-
-The following sample command sets up a HA-compatible cluster in the GCE zone europe-west1-b:
-
-```shell
-$ MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b  ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh
-```
-
-Note that the commands above create a cluster with one master;
-however, you can add new master replicas to the cluster with subsequent commands.
-
-## Adding a new master replica
-
-After you have created an HA-compatible cluster, you can add master replicas to it.
-You add master replicas by using a `kube-up` script with the following flags:
-
-* `KUBE_REPLICATE_EXISTING_MASTER=true` - to create a replica of an existing
-master.
-
-* `KUBE_GCE_ZONE=zone` - zone where the master replica will run.
-Must be in the same region as other replicas' zones.
-
-You don't need to set the `MULTIZONE` or `ENABLE_ETCD_QUORUM_READS` flags,
-as those are inherited from when you started your HA-compatible cluster.
-
-The following sample command replicates the master on an existing HA-compatible cluster:
-
-```shell
-$ KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
-```
-
-## Removing a master replica
-
-You can remove a master replica from an HA cluster by using a `kube-down` script with the following flags:
-
-* `KUBE_DELETE_NODES=false` - to restrain deletion of kubelets.
-
-* `KUBE_GCE_ZONE=zone` - the zone from where master replica will be removed.
- 
-* `KUBE_REPLICA_NAME=replica_name` - (optional) the name of master replica to remove.
-If empty: any replica from the given zone will be removed.
-
-The following sample command removes a master replica from an existing HA cluster:
-
-```shell
-$ KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh
-```
-
-## Handling master replica failures
-
-If one of the master replicas in your HA cluster fails,
-the best practice is to remove the replica from your cluster and add a new replica in the same zone.
-The following sample commands demonstrate this process:
-
-1. Remove the broken replica:
-
-```shell
-$ KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh
-```
-
-<ol start="2"><li>Add a new replica in place of the old one:</li></ol>
-
-```shell
-$ KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
-```
-
-## Best practices for replicating masters for HA clusters
-
-* Try to place masters replicas in different zones. During a zone failure, all master placed inside the zone will fail.
-To survive zone failure, also place nodes in multiple zones
-(see [multiple-zones](http://kubernetes.io/docs/admin/multiple-zones/) for details).
-
-* Do not use a cluster with two master replicas. Consensus on a two replica cluster requires both replicas running when changing persistent state.
-As a result, both replicas are needed and a failure of any replica turns cluster into majority failure state.
-A two-replica cluster is thus inferior, in terms of HA, to a single replica cluster.
-
-* When you add a master replica, cluster state (etcd) is copied to a new instance.
-If the cluster is large, it may take a long time to duplicate its state.
-This operation may be sped up by migrating etcd data directory, as described [here](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration) 
-(we are considering adding support for etcd data dir migration in future).
-
-## Implementation notes
-
-![](ha-master-gce.png)
-
-### Overview
-
-Each of master replicas will run the following components in the following mode:
-
-* etcd instance: all instances will be clustered together using consensus;
-
-* API server: each server will talk to local etcd - all API servers in the cluster will be available;
-
-* controllers, scheduler, and cluster auto-scaler: will use lease mechanism - only one instance of each of them will be active in the cluster;
-
-* add-on manager: each manager will work independently trying to keep add-ons in sync.
-
-In addition, there will be a load balancer in front of API servers that will route external and internal traffic to them.
-
-### Load balancing
-
-When starting the second master replica, a load balancer containing the two replicas will be created
-and the IP address of the first replica will be promoted to IP address of load balancer.
-Similarly, after removal of the penultimate master replica, the load balancer will be removed and its IP address will be assigned to the last remaining replica.
-Please note that creation and removal of load balancer are complex operations and it may take some time (~20 minutes) for them to propagate.
-
-### Master service & kubelets
-
-Instead of trying to keep an up-to-date list of Kubernetes apiserver in the Kubernetes service,
-the system directs all traffic to the external IP:
-
-* in one master cluster the IP points to the single master,
-
-* in multi-master cluster the IP points to the load balancer in-front of the masters.
-
-Similarly, the external IP will be used by kubelets to communicate with master.
-
-### Master certificates
-
-Kubernetes generates Master TLS certificates for the external public IP and local IP for each replica.
-There are no certificates for the ephemeral public IP for replicas;
-to access a replica via its ephemeral public IP, you must skip TLS verification.
-
-### Clustering etcd
-
-To allow etcd clustering, ports needed to communicate between etcd instances will be opened (for inside cluster communication).
-To make such deployment secure, communication between etcd instances is authorized using SSL.
-
-## Additional reading
-
-[Automated HA master deployment - design doc](https://github.com/kubernetes/kubernetes/blob/master/docs/design/ha_master.md)
-

docs/admin/high-availability/default-kubelet

@@ -4,5 +4,5 @@ MASTER_IP=<insert-ip-here>
 DNS_IP=<insert-dns-ip-here>
 
 DAEMON_ARGS="$DAEMON_ARGS --api-servers=https://${MASTER_IP} --enable-debugging-handlers=true  --cloud-provider=
-gce --config=/etc/kubernetes/manifests --allow-privileged=False --v=2 --cluster-dns=${DNS_IP} --cluster-domain=c
+gce --pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=False --v=2 --cluster-dns=${DNS_IP} --cluster-domain=c
 luster.local   --configure-cbr0=true --cgroup-root=/ --system-container=/system "