Merge branch 'master' of https://github.com/kubernetes/kubernetes.github.io into release-1.7

* 'master' of https://github.com/kubernetes/kubernetes.github.io: Fix a couple of typos in tasks/debug-application-cluster/audit.md Add an explanation of how the kubeadm kubelet dropin file works and a note about cAdvisor All files for both new case study pages (#4235) Add empty layout template
Merge pull request #4244 from mattmoyer/patch-1
2017-06-30 17:58:32 -07:00 · 2017-06-30 17:57:49 -07:00 · 2017-06-30 17:57:19 -07:00 · 2017-06-30 17:55:02 -07:00 · 2017-06-30 09:27:05 -05:00 · 2017-06-30 01:19:35 -07:00
4607 changed files with 755326 additions and 135698 deletions
@@ -1,3 +1,6 @@
-> NOTE: Please check the “Allow edits from maintainers” box below to allow 
-> reviewers fix problems on your patch and speed up the review process.
+> 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)
@@ -24,4 +24,3 @@ Session.vim
 tags

 kubernetes.github.io.iml
-_redirects
@@ -1,6 +1,6 @@
 language: go
 go:
-  - 1.7.3
+  - 1.8.1

 # Don't want default ./... here:
 install:
@@ -11,23 +11,9 @@ install:
 # (1) Fetch dependencies for us to run the tests in test/examples_test.go
 - go get -t -v k8s.io/kubernetes.github.io/test

-# The dependencies are complicated for test/examples_test.go
-# k8s.io/kubernetes/pkg is a dependency, which in turn depends on apimachinery
-# but we also have apimachinery directly as one of our dependencies, which causes a conflict.
-# Additionally, we get symlinks when we clone the directory. The below steps do the following:
-
-# (a) Replace the symlink with the actual dependencies from kubernetes/staging/src/
-# (b) copy all the vendored files to $GOPATH/src
- 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
- rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/sample-apiserver
- rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/kube-aggregator
- 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/
- cp -r $GOPATH/src/k8s.io/apimachinery/vendor/* $GOPATH/src/
- rm -rf $GOPATH/src/k8s.io/apimachinery/vendor/*
+# 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
@@ -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/).
@@ -1,4 +1,4 @@
-.PHONY: all build build-preview generate-redirects help serve
+.PHONY: all build build-preview help serve

 help: ## Show this help.
 	@awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z_-]+:.*?## / {sub("\\\\n",sprintf("\n%22c"," "), $$2);printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}' $(MAKEFILE_LIST)
@@ -11,8 +11,5 @@ build: ## Build site with production settings and put deliverables in _site.
 build-preview: ## Build site with drafts and future posts enabled.
 	jekyll build --drafts --future

-generate-redirects: ## Generate a redirects file and copy it into the _site directory.
-	mkdir -p _site && REDIRECTS_PATH=_site/_redirects ruby redirects.rb
-
 serve: ## Boot the development server.
 	jekyll serve
@@ -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!

@@ -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
@@ -10,13 +10,26 @@ toc:
  - 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 Architecture
+  section:
+  - 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
@@ -24,51 +37,62 @@ toc:
  - 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/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
-  - title: Jobs
-    section:
-    - docs/concepts/jobs/run-to-completion-finite-workloads.md
-
- title: Cluster Administration
-  section:
-  - 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/audit.md
-  - docs/concepts/cluster-administration/resource-usage-monitoring.md
-  - docs/concepts/cluster-administration/out-of-resource.md
-  - docs/concepts/cluster-administration/multiple-clusters.md
-  - docs/concepts/cluster-administration/federation.md
-  - docs/concepts/cluster-administration/federation-service-discovery.md
-  - docs/concepts/cluster-administration/guaranteed-scheduling-critical-addon-pods.md
-  - docs/concepts/cluster-administration/static-pod.md
-  - docs/concepts/cluster-administration/sysctl-cluster.md
-  - docs/concepts/cluster-administration/access-cluster.md
-  - docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig.md
-
- title: Storage
-  section:
-  - docs/concepts/storage/volumes.md
-
- title: Services, Load Balancing, and Networking
-  section:
-  - docs/concepts/services-networking/dns-pod-service.md
-  - docs/concepts/services-networking/connect-applications-service.md
+    - docs/concepts/workloads/controllers/jobs-run-to-completion.md
+    - docs/concepts/workloads/controllers/cron-jobs.md

 - title: Configuration
  section:
  - docs/concepts/configuration/overview.md
-  - docs/concepts/configuration/container-command-args.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/policy/resource-quotas.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
+
+
@@ -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
@@ -1,10 +1,10 @@
 tocs:
 - docs-home
 - guides
- tutorials
+- setup
 - tasks
+- tutorials
 - concepts
 - reference
- tools
 - samples
 - support
@@ -1,219 +0,0 @@
-bigheader: "Guides"
-abstract: "How to get started, and accomplish tasks, using Kubernetes."
-toc:
- docs/user-guide/index.md
-
- docs/whatisk8s.md
-
- docs/user-guide/index.md
-
- 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/ui.md
-
- title: Workload Deployment and Management
-  section:
-  - 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/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/pod-templates.md
-  - docs/user-guide/environment-guide/index.md
-  - docs/user-guide/compute-resources.md
-  - docs/user-guide/liveness/index.md
-  - docs/user-guide/container-environment.md
-  - docs/user-guide/node-selection/index.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/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
-    - docs/getting-started-guides/kubeadm.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
-      - docs/getting-started-guides/kops.md
-      - docs/getting-started-guides/kargo.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/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/getting-started-guides/docker-multinode.md
-  - docs/admin/cluster-large.md
-  - docs/admin/multiple-zones.md
-  - docs/admin/high-availability/index.md
-  - docs/getting-started-guides/binary_release.md
-
- title: Administering Clusters
-  section:
-  - docs/admin/index.md
-  - docs/admin/cluster-management.md
-  - docs/admin/upgrade-1-6.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-manager
-      path: /docs/admin/federation-controller-manager
@@ -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
-
@@ -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
+
+
@@ -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/
@@ -0,0 +1,4 @@
+bigheader: ""
+abstract: ""
+toc:
+- docs/search.md
@@ -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
@@ -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
@@ -3,72 +3,153 @@ abstract: "Step-by-step instructions for performing operations with Kubernetes."
 toc:
 - docs/tasks/index.md

- title: Using the kubectl Command-Line
+- title: Install Tools
  section:
-  - docs/tasks/kubectl/install.md
-  - docs/tasks/kubectl/list-all-running-container-images.md
-  - docs/tasks/kubectl/get-shell-running-container.md
+  - docs/tasks/tools/install-kubectl.md
+  - docs/tasks/tools/install-minikube.md
+  - docs/setup/independent/install-kubeadm.md

- title: Configuring Pods and Containers
+- 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/limit-range.md
-  - docs/tasks/configure-pod-container/apply-resource-quota-limit.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/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/downward-api-volume-expose-pod-information.md
-  - docs/tasks/configure-pod-container/distribute-credentials-secure.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/configure-pod-disruption-budget.md
+  - docs/tasks/configure-pod-container/configmap.md
+  - docs/tasks/configure-pod-container/configure-pod-configmap.md
+  - docs/tools/kompose/user-guide.md

- title: Running Applications
+- title: Inject Data Into Applications
  section:
-  - docs/tasks/run-application/rolling-update-replication-controller.md
+  - 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: Running Jobs
+- 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: Accessing Applications in a Cluster
+- 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: Monitoring, Logging, and Debugging
+- 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/logging-stackdriver.md
-  - docs/tasks/debug-application-cluster/monitor-node-health.md
-  - docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.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/overview.md
-  - 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: Administering Federation
+- title: Federation - Run an App on Multiple Clusters
  section:
+  - 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
@@ -78,10 +159,13 @@ toc:
  - docs/tasks/administer-federation/replicaset.md
  - docs/tasks/administer-federation/secret.md

- title: Managing Stateful Applications
+- title: Manage Cluster Daemons
  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/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
+
+
@@ -32,6 +32,9 @@ toc:
 - 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
@@ -40,25 +43,22 @@ toc:
  - docs/tutorials/object-management-kubectl/declarative-object-management-configuration.md
 - title: Stateless Applications
  section:
-  - 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
-  - docs/tutorials/stateless-application/run-stateless-ap-replication-controller.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
-  section:
-  - docs/tutorials/connecting-apps/connecting-frontend-backend.md
 - title: Clusters
  section:
  - docs/tutorials/clusters/apparmor.md
 - title: Services
  section:
  - docs/tutorials/services/source-ip.md
- title: Federated Cluster Administration
-  section:
-  - docs/tutorials/federation/set-up-cluster-federation-kubefed.md
+
@@ -1 +0,0 @@
-***NOTE: This feature is beta in Kubernetes 1.5.***
@@ -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:
@@ -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 %}
@@ -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 %}
@@ -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 %}
@@ -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 %}
@@ -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 %}
@@ -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.
@@ -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:
@@ -1,8 +1,8 @@
 <footer>
    <main class="light-text">
        <nav>
-            <a href="/docs/hellonode/">Get Started</a>
-            <a href="/docs/">Documentation</a>
+            <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>
@@ -20,12 +20,12 @@
                <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>
+                <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://github.com/kubernetes/kubernetes.github.io/blob/master/LICENSE" class="light-text">CC BY 4.0</a>
+            &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>
@@ -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>
@@ -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">
@@ -391,6 +391,132 @@
 			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'
  		}
 		
 	]
@@ -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>
@@ -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>
@@ -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 %}
@@ -4,8 +4,8 @@
 <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://github.com/kubernetes/community/tree/master/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 the table of contents (ToC) outlined in the <a href="https://docs.google.com/a/google.com/document/d/18hRCIorVarExB2eBVHTUR6eEJ2VVk5xq1iBmkQv8O6I/edit?usp=sharing">kubernetes-docs-toc</a> document and should improve the documentation's findability and readability for a wider range of audiences.</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>
@@ -1,4 +1,4 @@
-
+<!DOCTYPE html>
 <html lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
@@ -1,4 +1,4 @@
-
+<!DOCTYPE html>
 <html lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
@@ -1,4 +1,4 @@
-
+<!DOCTYPE html>
 <html lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
@@ -1,4 +1,4 @@
-
+<!DOCTYPE html>
 <html lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
@@ -1,4 +1,4 @@
-
+<!DOCTYPE html>
 <html lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
@@ -1,4 +1,4 @@
-
+<!DOCTYPE html>
 <html lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
@@ -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>
@@ -1,4 +1,4 @@
-
+<!DOCTYPE html>
 <html lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
@@ -1,4 +1,4 @@
-
+<!DOCTYPE html>
 <html lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
@@ -1,4 +1,4 @@
-
+<!DOCTYPE html>
 <html lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
@@ -22,15 +22,12 @@
  <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)" autofocus="autofocus">
@@ -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 -->
@@ -69,7 +64,7 @@
            (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>
+        '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>
@@ -0,0 +1 @@
+{{ content }}
@@ -864,6 +864,9 @@ dd
 		font-size: inherit
 		background-color: transparent

+	.includecode
+		table-layout: fixed
+
 	.includecode, .includecode th, .includecode td
 		padding: 0 !important

@@ -965,8 +968,8 @@ dd
 		//font-weight: 700
 		text-decoration: underline

-	a:visited
-		color: blueviolet
+//	a:visited
+//		color: blueviolet

 	a.button
 		border-radius: 2px
@@ -1302,6 +1305,270 @@ $feature-box-div-margin-bottom: 40px
 			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
@@ -1313,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
@@ -0,0 +1,127 @@
+---
+title: Box Case Study
+layout: none
+class: gridPage
+cid: caseStudies
+---
+<!DOCTYPE html>
+<html>
+  <head>
+    <meta charset="utf-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+      <link href="https://fonts.googleapis.com/css?family=Roboto:300,400" rel="stylesheet">
+      <link rel="stylesheet" type="text/css" href="/css/style_box.css">
+    <title>Box Case Study</title>
+  </head>
+<body>
+
+
+<div class="banner1">
+  <h1>CASE STUDY: <img src="/images/box_logo.png" class="logo" width="10%" style="margin-bottom:-6px"><br>
+    <div class="subhead">An Early Adopter Envisions
+      a New Cloud Platform</div>
+  </h1>
+</div>
+
+
+<div class="details">
+    Company &nbsp;<b>Box</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Redwood City, California</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Technology</b>
+</div>
+
+<hr>
+
+<section class="section1">
+
+<div class="cols">
+  <div class="col1">
+
+      <h2>Challenge</h2>
+        Founded in 2005, the enterprise content management company allows its more than 50 million users to manage content in the cloud. <a href="https://www.box.com/home">Box</a> was built primarily with bare metal inside the company’s own data centers, with a monolithic PHP code base. As the company was expanding globally, it needed to focus on "how we run our workload across many different cloud infrastructures from bare metal to public cloud," says Sam Ghods, Cofounder and Services Architect of Box. "It’s been a huge challenge because different clouds, especially bare metal, have very different interfaces."
+        <br>
+  </div>
+
+
+  <div class="col2">
+    <h2>Solution</h2>
+      Over the past couple of years, Box has been decomposing its infrastructure into microservices, and became an early adopter of, as well as contributor to, <a href="http://kubernetes.io/">Kubernetes</a> container orchestration. Kubernetes, Ghods says, has allowed Box’s developers to "target a universal set of concepts that are portable across all clouds."<br><br>
+
+    <h2>Impact</h2>
+      "Before Kubernetes," Ghods says, "our infrastructure was so antiquated it was taking us more than six months to deploy a new microservice. Today, a new microservice takes less than five days to deploy. And we’re working on getting it to an hour."
+  </div>
+</div>
+
+</section>
+
+
+<div class="banner2">
+  <div class="banner2text">
+      "We looked at a lot of different options, but Kubernetes really stood out....the fact that on day one it was designed to run on bare metal just as well as Google Cloud meant that we could actually migrate to it inside of our data centers, and then use those same tools and concepts to run across public cloud providers as&nbsp;well."<br><br><span style="font-size:15px;letter-spacing:0.08em">- SAM GHOUDS, CO-FOUNDER AND SERVICES ARCHITECT OF BOX</span>
+  </div>
+</div>
+
+
+<section class="section2">
+
+  <div class="fullcol">
+      <h2>In the summer of 2014, Box was feeling the pain of a decade’s worth of hardware and software infrastructure that wasn’t keeping up with the company’s needs.</h2>
+
+      A platform that allows its more than 50 million users (including governments and big businesses like <a href="https://www.ge.com/">General Electric</a>) to manage and share content in the cloud, Box was originally a <a href="http://php.net/">PHP</a> monolith of millions of lines of code built exclusively with bare metal inside of its own data centers. It had already begun to slowly chip away at the monolith, decomposing it into microservices. And "as we’ve been expanding into regions around the globe, and as the public cloud wars have been heating up, we’ve been focusing a lot more on figuring out how we run our workload across many different environments and many different cloud infrastructure providers," says Box Cofounder and Services Architect Sam Ghods. "It’s been a huge challenge thus far because all these different providers, especially bare metal, have very different interfaces and ways in which you work with them."<br><br>
+      Box’s cloud native journey accelerated that June, when Ghods attended <a href="https://www.docker.com/events/dockercon">DockerCon</a>. The company had come to the realization that it could no longer run its applications only off bare metal, and was researching containerizing with Docker, virtualizing with OpenStack, and supporting public cloud.<br><br>
+      At that conference, Google announced the release of its Kubernetes container management system, and Ghods was won over. "We looked at a lot of different options, but Kubernetes really stood out, especially because of the incredibly strong team of <a href="https://research.google.com/pubs/pub43438.html">Borg</a> veterans and the vision of having a completely infrastructure-agnostic way of being able to run cloud software," he says, referencing Google’s internal container orchestrator Borg. "The fact that on day one it was designed to run on bare metal just as well as <a href="https://cloud.google.com/">Google Cloud</a> meant that we could actually migrate to it inside of our data centers, and then use those same tools and concepts to run across public cloud providers as well."<br><br>
+      Another plus: Ghods liked that <a href="kubernetes.io">Kubernetes</a> has a universal set of API objects like pod, service, replica set and deployment object, which created a consistent surface to build tooling against. "Even PaaS layers like <a href="https://www.openshift.com/">OpenShift</a> or <a href="http://deis.io/">Deis</a> that build on top of Kubernetes still treat those objects as first-class principles," he says. "We were excited about having these abstractions shared across the entire ecosystem, which would result in a lot more momentum than we saw in other potential solutions."<br><br>
+      Box deployed Kubernetes in a cluster in a production data center just six months later. Kubernetes was then still pre-beta, on version 0.11. They started small: The very first thing Ghods’s team ran on Kubernetes was a Box API checker that confirms Box is up. "That was just to write and deploy some software to get the whole pipeline functioning," he says. Next came some daemons that process jobs, which was "nice and safe because if they experienced any interruptions, we wouldn’t fail synchronous incoming requests from customers."
+
+  </div>
+</section>
+
+<div class="banner3">
+  <div class="banner3text">
+    "As we’ve been expanding into regions around the globe, and as the public cloud wars have been heating up, we’ve been focusing a lot more on figuring out how we [can have Kubernetes help] run our workload across many different environments and many different cloud infrastructure providers."
+  </div>
+</div>
+
+<section class="section3">
+  <div class="fullcol">
+    The first live service, which the team could route to and ask for information, was launched a few months later. At that point, Ghods says, "We were comfortable with the stability of the Kubernetes cluster. We started to port some services over, then we would increase the cluster size and port a few more, and that’s ended up to about 100 servers in each data center that are dedicated purely to Kubernetes. And that’s going to be expanding a lot over the next 12 months, probably to many hundreds if not thousands."<br><br>
+    While observing teams who began to use Kubernetes for their microservices, "we immediately saw an uptick in the number of microservices being released," Ghods&nbsp;notes. "There was clearly a pent-up demand for a better way of building software through microservices, and the increase in agility helped our developers be more productive and make better architectural choices."
+    <br><br><div class="quote">"There was clearly a pent-up demand for a better way of building software through microservices, and the increase in agility helped our developers be more productive and make better architectural choices."</div><br>
+    Ghods reflects that as early adopters, Box had a different journey from what companies experience now. "We were definitely lock step with waiting for certain things to stabilize or features to get released," he says. "In the early days we were doing a lot of contributions [to components such as kubectl apply] and waiting for Kubernetes to release each of them, and then we’d upgrade, contribute more, and go back and forth several times. The entire project took about 18 months from our first real deployment on Kubernetes to having general availability. If we did that exact same thing today, it would probably be no more than six."<br><br>
+    In any case, Box didn’t have to make too many modifications to Kubernetes for it to work for the company. "The vast majority of the work our team has done to implement Kubernetes at Box has been making it work inside of our existing (and often legacy) infrastructure," says Ghods, "such as upgrading our base operating system from RHEL6 to RHEL7 or integrating it into <a href="https://www.nagios.org/">Nagios</a>, our monitoring infrastructure. But overall Kubernetes has been remarkably flexible with fitting into many of our constraints, and we’ve been running it very successfully on our bare metal infrastructure."<br><br>
+    Perhaps the bigger challenge for Box was a cultural one. "Kubernetes, and cloud native in general, represents a pretty big paradigm shift, and it’s not very incremental," Ghods says. "We’re essentially making this pitch that Kubernetes is going to solve everything because it does things the right way and everything is just suddenly better. But it’s important to keep in mind that it’s not nearly as proven as many other solutions out there. You can’t say how long this or that company took to do it because there just aren’t that many yet. Our team had to really fight for resources because our project was a bit of a moonshot."
+  </div>
+</section>
+
+  <div class="banner4">
+    <div class="banner4text">
+    "The vast majority of the work our team has done to implement Kubernetes at Box has been making it work inside of our existing [and often legacy] infrastructure....overall Kubernetes has been remarkably flexible with fitting into many of our constraints, and we’ve been running it very successfully on our bare metal infrastructure."
+    </div>
+  </div>
+
+<section class="section4">
+  <div class="fullcol">
+    Having learned from experience, Ghods offers these two pieces of advice for companies going through similar challenges:
+    <h2>1. Deliver early and often.</h2> Service discovery was a huge problem for Box, and the team had to decide whether to build an interim solution or wait for Kubernetes to natively satisfy Box’s unique requirements. After much debate, "we just started focusing on delivering something that works, and then dealing with potentially migrating to a more native solution later," Ghods says. "The above-all-else target for the team should always be to serve real production use cases on the infrastructure, no matter how trivial. This helps keep the momentum going both for the team itself and for the organizational perception of the project." </br></br>
+    <h2>2. Keep an open mind about what your company has to abstract away from developers and what it&nbsp;doesn’t.</h2> Early on, the team built an abstraction on top of Docker files to help ensure that images had the right security updates.
+    This turned out to be superfluous work, since container images are considered immutable and you can easily scan them post-build to ensure they do not contain vulnerabilities. Because managing infrastructure through containerization is such a discontinuous leap, it’s better to start by interacting directly with the native tools and learning their unique advantages and caveats. An abstraction should be built only after a practical need for it arises.</br></br>
+    In the end, the impact has been powerful. "Before Kubernetes," Ghods says, "our infrastructure was so antiquated it was taking us more than six months to deploy a new microservice. Now a new microservice takes less than five days to deploy. And we’re working on getting it to an hour. Granted, much of that six months was due to how broken our systems were, but bare metal is intrinsically a difficult platform to support unless you have a system like Kubernetes to help manage&nbsp;it."</br></br>
+    By Ghods’s estimate, Box is still several years away from his goal of being a 90-plus percent Kubernetes shop. "We’re very far along on having a mission-critical, stable Kubernetes deployment that provides a lot of value," he says. "Right now about five percent of all of our compute runs on Kubernetes, and I think in the next six months we’ll likely be between 20 to 50 percent. We’re working hard on enabling all stateless service use cases, and shift our focus to stateful services after&nbsp;that."
+  </div>
+</section>
+
+  <div class="banner5">
+    <div class="banner5text">
+    "Ghods predicts that Kubernetes has the opportunity to be the new cloud platform. '...because it’s a never-before-seen level of automation and intelligence surrounding infrastructure that is portable and agnostic to every way you can run your infrastructure.'"
+    </div>
+  </div>
+
+<section class="section5">
+  <div class="fullcol">
+    In fact, that’s what he envisions across the industry: Ghods predicts that Kubernetes has the opportunity to be the new cloud platform. Kubernetes provides an API consistent across different cloud platforms including bare metal, and "I don’t think people have seen the full potential of what’s possible when you can program against one single interface," he says. "The same way <a href="https://aws.amazon.com/">AWS</a> changed infrastructure so that you don’t have to think about servers or cabinets or networking equipment anymore, Kubernetes enables you to focus exclusively on the containers that you’re running, which is pretty exciting. That’s the vision."</br></br>
+    Ghods points to projects that are already in development or recently released for Kubernetes as a cloud platform: cluster federation, the Dashboard UI, and <a href="https://coreos.com/">CoreOS</a>’s etcd operator. "I honestly believe it’s the most exciting thing I’ve seen in cloud infrastructure," he says, "because it’s a never-before-seen level of automation and intelligence surrounding infrastructure that is portable and agnostic to every way you can run your infrastructure."</br></br>
+    Box, with its early decision to use bare metal, embarked on its Kubernetes journey out of necessity. But Ghods says that even if companies don’t have to be agnostic about cloud providers today, Kubernetes may soon become the industry standard, as more and more tooling and extensions are built around the API.</br></br>
+    "The same way it doesn’t make sense to deviate from Linux because it’s such a standard," Ghods says, "I think Kubernetes is going down the same path. It is still early days—the documentation still needs work and the user experience for writing and publishing specs to the Kubernetes clusters is still rough. When you’re on the cutting edge you can expect to bleed a little. But the bottom line is, this is where the industry is going. Three to five years from now it’s really going to be shocking if you run your infrastructure any other way."
+  </div>
+</section>
+
+</body>
+</html>
@@ -0,0 +1,138 @@
+---
+title: GolfNow Case Study
+layout: none
+class: gridPage
+cid: caseStudies
+---
+<!DOCTYPE html>
+<html>
+  <head>
+    <meta charset="utf-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+      <link href="https://fonts.googleapis.com/css?family=Roboto:300,400" rel="stylesheet">
+      <link rel="stylesheet" type="text/css" href="/css/style_golfnow.css">
+    <title>GolfNow Case Study</title>
+  </head>
+<body>
+
+  <div class="banner1">
+    <h1>CASE STUDY: <img src="/images/golfnow_logo.png" class="logo" width="20%" style="margin-bottom:-6px"><br>
+    <div class="subhead">Saving Time and Money with Cloud Native Infrastructure</div>
+  </h1>
+</div>
+
+
+<div class="details">
+    Company&nbsp;<b>GolfNow</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location&nbsp;<b>Orlando, Florida</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry&nbsp;<b>Golf Industry Technology and Services Provider</b>
+</div>
+
+<hr>
+
+<section class="section1">
+  <div class="cols">
+    <div class="col1">
+
+    <h2>Challenge</h2>
+      A member of the <a href="http://www.nbcunicareers.com/our-businesses/nbc-sports-group">NBC Sports Group</a>, <a href="https://www.golfnow.com/">GolfNow</a> is the golf industry’s technology and services leader, managing 10 different products, as well as the largest e-commerce tee time marketplace in the world. As its business began expanding rapidly and globally, GolfNow’s monolithic application became problematic. "We kept growing our infrastructure vertically rather than horizontally, and the cost of doing business became problematic," says Sheriff Mohamed, GolfNow’s Director, Architecture. "We wanted the ability to more easily expand globally."
+      <br>
+  </div>
+
+  <div class="col2">
+    <h2>Solution</h2>
+      Turning to microservices and containerization, GolfNow began moving its applications and databases from third-party services to its own clusters running on <a href="https://www.docker.com/">Docker</a> and <a href="http://kubernetes.io/">Kubernetes.</a><br><br>
+
+    <h2>Impact</h2>
+      The results were immediate. While maintaining the same capacity—and beyond, during peak periods—GolfNow saw its infrastructure costs for the first application virtually cut in half.
+    </div>
+  </div>
+</section>
+
+
+<div class="banner2">
+  <div class="banner2text">
+      "With our growth we obviously needed to expand our infrastructure, and we kept growing vertically rather than horizontally. We were basically wasting money and doubling the cost of our infrastructure."<br><br><span style="font-size:15px;letter-spacing:0.08em">- SHERIFF MOHAMED, DIRECTOR, ARCHITECTURE AT GOLFNOW</span>
+  </div>
+</div>
+
+<section class="section2">
+  <div class="fullcol">
+      <h2>It’s not every day that you can say you’ve slashed an operating expense by half.</h2>
+
+      But Sheriff Mohamed and Josh Chandler did just that when they helped lead their company, <a href="https://www.golfnow.com/">GolfNow</a>, on a journey from a monolithic to a containerized, cloud native infrastructure managed by Kubernetes.
+      <br> <br>
+      A top-performing business within the NBC Sports Group, GolfNow is a technology and services company with the largest tee time marketplace in the world. GolfNow serves 5 million active golfers across 10 different products. In recent years, the business had grown so fast that the infrastructure supporting their giant monolithic application (written in C#.NET and backed by SQL Server database management system) could not keep up. "With our growth we obviously needed to expand our infrastructure, and we kept growing vertically rather than horizontally," says Sheriff, GolfNow’s Director, Architecture. "Our costs were growing exponentially. And on top of that, we had to build a Disaster Recovery (DR) environment, which then meant we’d have to copy exactly what we had in our original data center to another data center that was just the standby. We were basically wasting money and doubling the cost of our infrastructure."
+      <br> <br>
+      In moving just the first of GolfNow’s important applications—a booking engine for golf courses and B2B marketing platform—from third-party services to their own Kubernetes environment, "our bill went down drastically," says Sheriff.
+      <br> <br>
+      The path to those stellar results began in late 2014. In order to support GolfNow’s global growth, the team decided that the company needed to have multiple data centers and the ability to quickly and easily re-route traffic as needed. "From there we knew that we needed to go in a direction of breaking things apart, microservices, and containerization," says Sheriff. "At the time we were trying to get away from <a href="https://www.microsoft.com/net">C#.NET</a> and <a href="https://www.microsoft.com/en-cy/sql-server/sql-server-2016">SQL Server</a> since it didn’t run very well on Linux, where everything container was running smoothly."
+      <br> <br>
+      To that end, the team shifted to working with <a href="https://nodejs.org/">Node.js</a>, the open-source, cross-platform JavaScript runtime environment for developing tools and applications, and <a href="https://www.mongodb.com/">MongoDB</a>, the open-source database program. At the time, <ahref="https://www.docker.com/">Docker</a>, the platform for deploying applications in containers, was still new. But once the team began experimenting with it, Sheriff says, "we realized that was the way we wanted to go, especially since that’s the way the industry is heading."
+  </div>
+</section>
+
+<div class="banner3">
+  <div class="banner3text">
+    "The team migrated the rest of the application into their Kubernetes cluster. And the impact was immediate: On top of cutting monthly costs by a large percentage, says Sheriff, 'Running at the same capacity and during our peak time, we were able to horizontally grow. Since we were using our VMs more efficiently with containers, we didn’t have to pay extra money at all.'"
+  </div>
+</div>
+
+<section class="section3">
+  <div class="fullcol">
+    GolfNow’s dev team ran an "internal, low-key" proof of concept and were won over. "We really liked how easy it was to be able to pass containers around to each other and have them up and running in no time, exactly the way it was running on my machine," says Sheriff. "Because that is always the biggest gripe that Ops has with developers, right? ‘It worked on my machine!’ But then we started getting to the point of, ‘How do we make sure that these things stay up and running?’" <br><br>
+    That led the team on a quest to find the right orchestration system for the company’s needs. Sheriff says the first few options they tried were either too heavy or "didn’t feel quite right." In late summer 2015, they discovered the just-released <a href="http://kubernetes.io/">Kubernetes</a>, which Sheriff immediately liked for its ease of use. "We did another proof of concept," he says, "and Kubernetes won because of the fact that the community backing was there, built on top of what Google had already done."
+    <br><br>
+    But before they could go with Kubernetes, <a href="http://www.nbc.com/">NBC</a>, GolfNow’s parent company, also asked them to comparison shop with another company. Sheriff and his team liked the competing company’s platform user interface, but didn’t like that its platform would not allow containers to run natively on Docker. With no clear decision in sight, Sheriff’s VP at GolfNow, Steve McElwee, set up a three-month trial during which a GolfNow team (consisting of Sheriff and Josh, who’s now Lead Architect, Open Platforms) would build out a Kubernetes environment, and a large NBC team would build out one with the other company’s platform.
+    <br><br>
+    "We spun up the cluster and we tried to get everything to run the way we wanted it to run," Sheriff says. "The biggest thing that we took away from it is that not only did we want our applications to run within Kubernetes and Docker, we also wanted our databases to run there. We literally wanted our entire infrastructure to run within Kubernetes."
+    <br><br>
+    At the time there was nothing in the community to help them get Kafka and MongoDB clusters running within a Kubernetes and Docker environment, so Sheriff and Josh figured it out on their own, taking a full month to get it right. "Everything started rolling from there," Sheriff says. "We were able to get all our applications connected, and we finished our side of the proof of concept a month in advance. My VP was like, ‘Alright, it’s over. Kubernetes wins.’"
+    <br><br>
+    The next step, beginning in January 2016, was getting everything working in production. The team focused first on one application that was already written in Node.js and MongoDB. A booking engine for golf courses and B2B marketing platform, the application was already going in the microservice direction but wasn’t quite finished yet. At the time, it was running in <a href="https://devcenter.heroku.com/articles/mongohq">Heroku Compose</a> and other third-party services—resulting in a large monthly bill.
+
+  </div>
+</section>
+
+  <div class="banner4">
+    <div class="banner4text">
+    "'The time I spent actually moving the applications was under 30 seconds! We can move data centers in just incredible amounts of time. If you haven’t come from the Kubernetes world you wouldn’t believe me.' Sheriff puts it in these terms: 'Before Kubernetes I wasn’t sleeping at night, literally. I was woken up all the time, because things were down. After Kubernetes, I’ve been sleeping at night.'"
+    </div>
+  </div>
+
+<section class="section4">
+  <div class="fullcol">
+    "The goal was to take all of that out and put it within this new platform we’ve created with Kubernetes on <a href="https://cloud.google.com/compute/">Google Compute Engine (GCE)</a>," says Sheriff. "So we ended up building piece by piece, in parallel, what was out in Heroku and Compose, in our Kubernetes cluster. Then, literally, just switched configs in the background. So in Heroku we had the app running hitting a Compose database. We’d take the config, change it and make it hit the database that was running in our cluster."
+    <br><br>
+    Using this procedure, they were able to migrate piecemeal, without any downtime. The first migration was done during off hours, but to test the limits, the team migrated the second database in the middle of the day, when lots of users were running the application. "We did it," Sheriff says, "and again it was successful. Nobody noticed."
+    <br><br>
+    After three weeks of monitoring to make sure everything was running stable, the team migrated the rest of the application into their Kubernetes cluster. And the impact was immediate: On top of cutting monthly costs by a large percentage, says Sheriff, "Running at the same capacity and during our peak time, we were able to horizontally grow. Since we were using our VMs more efficiently with containers, we didn’t have to pay extra money at all."
+    <br><br>
+    Not only were they saving money, but they were also saving time. "I had a meeting this morning about migrating some applications from one cluster to another," says Josh. "I spent about 2 hours explaining the process. The time I spent actually moving the applications was under 30 seconds! We can move data centers in just incredible amounts of time. If you haven’t come from the Kubernetes world you wouldn’t believe me." Sheriff puts it in these terms: "Before Kubernetes I wasn’t sleeping at night, literally. I was woken up all the time, because things were down. After Kubernetes, I’ve been sleeping at night."
+    <br><br>
+    A small percentage of the applications on GolfNow have been migrated over to the Kubernetes environment. "Our Core Team is rewriting a lot of the .NET applications into <a href="https://www.microsoft.com/net/core">.NET Core</a> [which is compatible with Linux and Docker] so that we can run them within containers," says Sheriff.
+    <br><br>
+    Looking ahead, Sheriff and his team want to spend 2017 continuing to build a whole platform around Kubernetes with <a href="https://github.com/drone/drone">Drone</a>, an open-source continuous delivery platform, to make it more developer-centric. "Now they’re able to manage configuration, they’re able to manage their deployments and things like that, making all these subteams that are now creating all these microservices, be self sufficient," he says. "So it can pull us away from applications and allow us to just make sure the cluster is running and healthy, and then actually migrate that over to our Ops team."
+
+  </div>
+</section>
+
+  <div class="banner5">
+    <div class="banner5text">
+    "Having gone from complete newbies to production-ready in three months, the GolfNow team is eager to encourage other companies to follow their lead. 'This is The Six Million Dollar Man of the cloud right now,' adds Josh. 'Just try it out, watch it happen. I feel like the proof is in the pudding when you look at these kinds of application stacks. They’re faster, they’re more resilient.'"
+    </div>
+  </div>
+
+<section class="section5">
+  <div class="fullcol">
+    And long-term, Sheriff has an even bigger goal for getting more people into the Kubernetes fold. "We’re actually trying to make this platform generic enough so that any of our sister companies can use it if they wish," he says. "Most definitely I think it can be used as a model. I think the way we migrated into it, the way we built it out, are all ways that I think other companies can learn from, and should not be afraid of."
+    <br><br>
+    The GolfNow team is also giving back to the Kubernetes community by open-sourcing a bot framework that Josh built. "We noticed that the dashboard user interface is actually moving a lot faster than when we started," says Sheriff. "However we realized what we needed was something that’s more of a bot that really helps us administer Kubernetes as a whole through Slack." Josh explains: "With the Kubernetes-Slack integration, you can essentially hook into a cluster and the issue commands and edit configurations. We’ve tried to simplify the security configuration as much as possible. We hope this will be our major thank you to Kubernetes, for everything you’ve given us."
+    <br><br>
+    Having gone from complete newbies to production-ready in three months, the GolfNow team is eager to encourage other companies to follow their lead. The lessons they’ve learned: "You’ve got to have buy-in from your boss," says Sheriff. "Another big deal is having two to three people dedicated to this type of endeavor. You can’t have people who are half in, half out." And if you don’t have buy-in from the get go, proving it out will get you there.
+    <br><br>
+    "This is The Six Million Dollar Man of the cloud right now," adds Josh. "Just try it out, watch it happen. I feel like the proof is in the pudding when you look at these kinds of application stacks. They’re faster, they’re more resilient."
+
+  </div>
+</section>
+
+</body>
+</html>
@@ -14,17 +14,23 @@ cid: caseStudies
    <main>
        <div class="content">
            <div class="case-studies">
+              <div class="case-study">
+                  <img src="/images/case_studies/golfnow.png" alt="GolfNow">
+                  <p class="quote">"We can move data centers in incredible amounts of time. If you haven’t come from the Kubernetes world and I tell you this is what I’ve been doing, you wouldn’t believe me."</p>
+                  <!--<p class="attrib">— Josh Chandler, Lead Architect, Open Platforms at GolfNow</p>-->
+                  <a href="/case-studies/golfnow/">Read about GolfNow</a>
+              </div>
                <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>
+                    <a href="/case-studies/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>
+                    <a href="/case-studies/wikimedia/">Read about Wikimedia</a>
                </div>
                <div class="case-study">
                    <img src="/images/case_studies/ebay.png" alt="eBay">
@@ -33,8 +39,8 @@ cid: caseStudies
                </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>
+                    <p class="quote">"Kubernetes has the opportunity to be the new cloud platform. Because it’s a never-before-seen level of automation and intelligence surrounding infrastructure that is portable and agnostic to every way you can run your infrastructure."</p>
+                    <a href="/case-studies/box/">Read about Box</a>
                </div>
            </div>
        </div>
@@ -82,8 +88,8 @@ cid: caseStudies
            <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 href="/case-studies/wikimedia/"><img src="/images/case_studies/wikimedia_logo.png" alt="Wikimedia"></a>
+            <a href="/case-studies/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>
@@ -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 在社区参与中茁壮成长，我们非常感谢您对我们的网站和文档的贡献！
@@ -0,0 +1,2 @@
+Kubernetes 文档的 [用户指南](/docs/user-guide/) 部分中的主题将被移动到 [任务](/docs/tasks/)、[教程](/docs/tutorials/)和
+[概念](/docs/concepts) 部分。 本主题的内容已转移到:
@@ -0,0 +1,118 @@
+---
+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 控制面 (Controll Plane)](/docs/admin/cluster-components) 是构建在相同的 [APIs](/docs/api/) 上面，开发人员和用户都可以用。用户可以编写自己的控制器， [调度器](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/scheduler.md)等等，如果这么做，根据新加的[自定义 API](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/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 的发音比较接近。
@@ -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>
@@ -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>节点 是 Kubernetes 集群中的工作机器，可以是物理机或虚拟机。</b> 每个工作节点都有一个 Kubelet，它是管理 节点 并与 Kubernetes Master 节点进行通信的代理。节点 上还应具有处理容器操作的工作，例如 <a href="https://www.docker.com/">Docker</a> 或 <a href="https://coreos.com/rkt/">rkt</a>。一个 Kubernetes 工作集群至少有三个节点。</p>
+
+			</div>
+			<div class="col-md-4">
+				<div class="content__box content__box_fill">
+					<p><i> Master 管理集群，而 节点 用于托管正在运行的应用程序。  </i></p>
+				</div>
+			</div>
+		</div>
+
+		<div class="row">
+			<div class="col-md-8">
+				<p>当您在 Kubernetes 上部署应用程序时，您可以告诉 master 启动应用程序容器。Master 调度容器在集群的 节点 上运行。<b> 节点 使用 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>
@@ -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>
@@ -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 部署控制器会持续监视这些实例。如果托管它的节点不可用或删除，则部署控制器将替换实例。 <b>这提供了一种解决机器故障或维护的自愈机制。</b></p>
+
+				<p>在编排诞生前的世界中，通常会使用安装脚本启动应用程序，但是它们并不能从机器故障中恢复。通过创建应用程序实例并使其运行在跨节点的机器之间，Kubernetes 部署提供了截然不同的应用管理方法。 </p>
+
+			</div>
+
+			<div class="col-md-4">
+				<div class="content__box content__box_lined">
+					<h3>概要:</h3>
+					<ul>
+						<li>部署</li>
+						<li>Kubectl</li>
+					</ul>
+				</div>
+				<div class="content__box content__box_fill">
+					<p><i>
+						部署负责创建和更新应用程序的实例
+					</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>创建和管理部署。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>
@@ -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>
@@ -0,0 +1,142 @@
+---
+title: 查看 Pods 和节点
+---
+
+<!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>节点</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>节点</h2>
+				<p>Pod 总是运行在 <b>Node</b>上。Node 是 Kubernetes 的工作机器，可以是虚拟机或物理机，这取决于在集群的安装情况。每个节点由 Master 管理。一个节点上可以有多个 Pod, Kubernetes master 会自动处理调度集群各个节点上的 Pod。 Master 在自动调度时，会考虑每个 Node 上的可用资源。</p>
+
+				<p>每个 Kubernetes 节点至少运行以下组件:</p>
+				<ul>
+					<li>Kubelet 是负责 Kubernetes Master 和 所有节点之间通信的进程，它管理机器上运行的 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;">节点概述</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> 节点是 Kubernetes 中的工作机器，可能是物理机或虚拟机，具体取决于集群的安装配置。多个 Pod 可以在一个节点上运行。 </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>
@@ -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>
@@ -0,0 +1,111 @@
+---
+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>了解标签和标签选择器对象如何与服务相关联</li>
+					<li>通过 Service 在 Kubernetes 集群外发布应用程序</li>
+				</ul>
+			</div>
+
+			<div class="col-md-8">
+			<h3>Kubernetes 服务概述</h3>
+
+			<p>Kubernetes <a href="/docs/concepts/workloads/pods/pod-overview/">Pods</a> 终有一死. Pods 实际上有一个 <a href="/docs/concepts/workloads/pods/pod-lifecycle/">生命周期</a>. 当工作节点死机时, 节点上运行的Pod也将丢失。 一个 <a href="/docs/user-guide/replication-controller/#what-is-a-replicationcontroller">ReplicationController</a> 可能会通过创建新的Pod以动态地将集群恢复到所需的状态，以保持您的应用程序运行。还有一种方法就是：决定是否使用具有3个副本的图像处理后端。这些副本是可替代的前端系统不应关心后端副本，即使Pod丢失并重建也不会更改。 也就是说，Kubernetes 集群中的每个 Pod 都有一个唯一的IP地址，即使在同一个节点上的 Pods 也是如此，所以此时就需要一种自动调整更改 Pod 的方法, 以便您的应用程序继续运行。输入 <i>服务</i>. Kubernetes 中的服务是一个抽象对象，它定义了一组逻辑的 Pods 和一个访问它们的策略。 服务让互相依赖的 Pod 之间的耦合松动。 服务由 YAML <a href="/docs/concepts/configuration/overview/#general-config-tips">(首选)</a> 或 JSON 定义。像所有 Kubernetes 对象一样。 针对服务的一组 Pod 通常由<i>Label选择器</i>确定（参见下文，为什么您可能希望不将 <code>选择器</code> 包含在规范中。</p>
+
+			<p>虽然每个 Pod 都有一个唯一的 IP 地址，但是这些 IP 不会在没有服务的情况下公开在群集之外。服务允许您的应用程序接收流量。 可以通过在 ServiceSpec 中指定<code>类型</code> 以不同方式显示服务：</p>
+			<ul>
+				<li><i>ClusterIP</i>(默认) - 在集群中的内部IP上公开服务。此类型使服务只能从集群中访问。</li>
+				<li><i>NodePort</i> —— 使用NAT在群集中每个选定的节点的同一端口上显示该服务。使用 <code><NodeIP>:<NodePort></code>可以从群集外部访问服务。建立 ClusterIP 的超集.</li>
+				<li><i>LoadBalancer</i> —— 在当前云中创建外部负载平衡器(如果支持)，并为服务分配固定的外部IP。建立 NodePort 的超集。</li>
+				<li><i>ExternalName</i> —— 使用任意名称显示该服务(由规范中的<code>externalName</code> 指定)，本过程通过使用该名称返回 CNAME 记录达成。无须使用代理。这种类型需要 v1.7 或更高版本的 <code>kube-dns</code>.</li>
+			</ul>
+			<p>有关不同类型服务的详细信息，请参见 <a href="/docs/tutorials/services/source-ip/">使用源IP</a> 教程。另请参阅 <a href="/docs/concepts/services-networking/connect-applications-service">使用服务连接应用程序</a>.</p>
+			<p>另外，请注意，服务中有一些使用案例涉及在规范中不定义<code>选择器</code> 。不使用 <code>选择器</code> 创建的服务也不会创建相应的端点对象。 这允许用户手动将服务映射到特定端点。没有选择器还有可能是因为您严格地使用了 <code>type: ExternalName</code>.</p>
+			</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 服务是一个抽象层，它定义了一组逻辑的Pods，并为这些Pods启用了外部流量曝光、负载平衡和服务发现。</i></p>
+				</div>
+			</div>
+		</div>
+		<br>
+
+		<div class="row">
+			<div class="col-md-8">
+				<h3>服务和标签</h3>
+			</div>
+		</div>
+
+		<div class="row">
+			<div class="col-md-8">
+				<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_04_services.svg" width="150%" height="150%"></p>
+			</div>
+		</div>
+
+		<div class="row">
+			<div class="col-md-8">
+				<p> A服务可以跨一组 Pod 路由流量。服务是允许 Pod 在 Kubernetes 中死亡和复制而不影响应用程序的抽象层。相关 Pod 之间的发现和路由(如应用程序中的前端和后端组件)是由 Kubernetes Services 处理的。</p>
+				<p> 服务使用 <a href="/docs/concepts/overview/working-with-objects/labels">标签和选择器</a>, 匹配一组 Pod，成为分组原语，此原语允许在 Kubernetes 中的对象进行逻辑运算。标签是一对附加到对象的关键/重要组，可以以多种方式使用，方式如下: </p>
+				<ul>
+					<li>指定用于开发、测试和生产的对象</li>
+					<li>嵌入版本标签</li>
+					<li>使用标签分类对象</li>
+				</ul>
+
+			</div>
+			<div class="col-md-4">
+				<div class="content__box content__box_fill">
+					<p><i>您可以在使用<br><code>--expose</code> 在 kubectl 中创建部署的同时创建服务.</i></p>
+				</div>
+			</div>
+		</div>
+
+		<br>
+
+		<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>标签可以在创建时或之后附加到对象后，并支持随时修改。让我们现在开始使用服务公开我们的应用程序并应用一些标签吧。</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>
@@ -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>
@@ -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>
@@ -0,0 +1,121 @@
+---
+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>
@@ -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>
@@ -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 上这通过滚动更新(Rolling updates)达成。 <b>Rolling updates</b> 允许通过使用新的 Pods 实例逐个更新来实现零停机的部署更新。新的 Pods 会被调度到可用资源的 Node 节点上。</p>
+
+			<p>在上一个模块中，我们将应用程序扩展为运行多个实例。这也是执行更新但不影响应用可用性所需的条件。默认情况下，更新期间最大数量的不可用 Pod 以及最大数量的新 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 外部可见，则服务将在更新期间将流量负载均衡到可用的 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>
@@ -0,0 +1,145 @@
+---
+title: 使用命令式的方式管理 Kubernetes 对象
+redirect_from:
+- "/docs/concepts/tools/kubectl/object-management-using-imperative-commands/"
+- "/docs/concepts/tools/kubectl/object-management-using-imperative-commands.html"
+---
+
+{% capture overview %}
+直接使用内置的 `kubectl` 命令行工具，以命令式方式可以快速创建，更新和删除 Kubernetes 对象。本文档介绍了这些命令是如何组织的，以及如何使用它们来管理活动对象。
+{% endcapture %}
+
+{% capture body %}
+
+## 权衡
+
+`kubectl` 工具支持三种对象的管理:
+
+* 命令式的方式
+* 命令式的对象配置
+* 声明式的对象配置
+
+参见[Kubernetes对象管理](/docs/concepts/tools/kubectl/object-management-overview/)
+讨论各种对象管理的优缺点.
+
+## 如何创建对象
+
+`kubectl` 工具支持用于创建一些最常用的对象类型的动词驱动命令，这些命令被命名为对于不熟悉的用户也是一目了然。
+
+- `run`: 创建一个新的 Deployment 对象以在一个或多个 Pod 中运行 Containers。
+- `expose`: 创建一个新的 Service 对象用于负载均衡 Pods 上的的网络流量。
+- `autoscale`: 创建一个新的 Autoscaler 对象，即自动水平扩展控制器，提供 Deployment 自动水平伸缩支持。
+
+`kubectl` 工具也支持由对象类型驱动的创建命令。 这些命令支持更多的对象类型，并且对其意图更为明确，但要求用户知道他们打算创建的对象的类型。
+
+ - `create <objecttype> [<subtype>] <instancename>`
+
+某些对象类型具有您可以在“create"命令中指定的子类型.
+例如，Service对象有几种子类型，包括ClusterIP，
+LoadBalancer和NodePort. 以下是创建一个服务的示例
+子类型NodePort:
+
+一些对象类型允许你在 `create` 命令中指定子命令。例如，Service 对象拥有几个子命令，包括 ClusterIP、LoadBalancer 和 NodePort。以下是使用子命令 NodePort 创建服务的示例:
+
+
+```shell
+kubectl create service nodeport <myservicename>
+```
+
+在前面的例子中，调用 `create service nodeport`命令是 `create service`命令的子命令.
+
+您可以使用 `-h` 标志来查找子命令支持的参数和标志:
+
+```shell
+kubectl create service nodeport -h
+```
+
+## 如何更新对象
+
+`kubectl` 命令支持一些常见更新操作的动词驱动命令。这样命名可以让不熟悉 Kubernetes 对象的用户，在不知道必须设置的特定字段的情况下也可以执行更新操作:
+
+ - `scale`: 通过更新控制器的副本数量，水平扩展控制器以添加或删除 Pod。
+ - `annotate`: 从对象添加或删除注释。
+ - `label`: 为对象添加或删除标签。
+
+`kubectl`命令还支持由对象的一个切面驱动的更新命令.设置此切面可能会为不同的对象类型设置不同的字段:
+
+ - `set` <field>: 设置对象的一个切面.
+
+**注**: 在 Kubernetes 版本 1.5 中，并不是每个动词驱动的命令都有一个相关的切面驱动的命令.
+
+`kubectl` 工具支持直接更新活动对象的其他方法，然而，它们需要更好的了解 Kubernetes 对象模式。
+
+- `edit`: 通过在编辑器中打开其配置，直接编辑活动对象的原始配置。
+- `patch`: 通过使用补丁字符串直接修改活动对象的特定字段。
+
+有关补丁字符串的更多详细信息，请参阅补丁部分
+[API 公约](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#patch-operations).
+
+## 如何删除对象
+
+您可以使用 `delete` 命令从集群中删除一个对象:
+
+ - `delete <type>/<name>`
+
+ **注意**: 您可以对命令式命令和命令式对象配置都使用 `kubectl delete` 方法。两者的差异在于传递的命令参数不同。要将
+ `kubectl delete` 作为命令式命令使用，将要删除的对象作为参数传递。以下是传递名为 nginx 的 Deployment 对象的示例:
+
+```shell
+kubectl delete deployment/nginx
+```
+
+## 如何查看对象
+
+{% comment %}
+TODO(pwittrock): 实现时取消注释.
+
+您可以使用 `kubectl view` 打印指定对象的字段。
+
+- `view`: 打印对象的特定字段的值。
+
+{% endcomment %}
+
+
+
+有几个命令用于打印有关对象的信息:
+
+- `get`: 打印有关匹配对象的基本信息。使用 `get -h` 来查看选项列表。
+- `describe`: 打印有关匹配对象的聚合详细信息。
+- `logs`: 打印 Pod 运行容器的 stdout 和 stderr 信息。
+
+##  使用 `set` 命令在创建之前修改对象
+
+有一些对象字段没有可以使用的标志，在 `create` 命令中。在某些情况下，您可以使用组合 `set` 和 `create` 为对象之前的字段指定一个值创建。这是通过将 `create` 命令的输出管道连接到 `set` 命令，然后回到 `create` 命令。以下是一个例子:
+
+```sh
+kubectl create service clusterip <myservicename> -o yaml --dry-run | kubectl set selector --local -f - 'environment=qa' -o yaml | kubectl create -f -
+```
+
+1.  使用 `create service -o yaml --dry-run` 创建服务配置，并将其作为 YAML 打印到 stdout，而不是将其发送到 Kubernetes API 服务器。
+1.  使用 `set --local -f - -o yaml` 从 stdin 读取配置，并将更新后的配置作为 YAML 写入 stdout。
+1.  使用 `kubectl create -f -` 从 stdin 提供的配置创建对象。
+
+## 使用 `--edit` 在创建之前修改对象
+
+您可以使用 `kubectl create --edit` 命令在对象创建之前，对对象进行任意更改。以下是一个例子:
+
+```sh
+kubectl create service clusterip my-svc -o yaml --dry-run > /tmp/srv.yaml
+kubectl create --edit -f /tmp/srv.yaml
+```
+
+1. 使用`create service` 创建服务的配置并将其保存到 `/tmp/srv.yaml`。
+1. 使用`create --edit` 在创建对象之前打开配置文件进行编辑。
+
+
+{% endcapture %}
+
+{% capture whatsnext %}
+ -  [使用对象配置管理 Kubernetes 对象(必要)](/docs/tutorials/object-management-kubectl/imperative-object-management-configuration/)
+ -  [使用对象配置(声明式)管理 Kubernetes 对象](/docs/tutorials/object-management-kubectl/declarative-object-management-configuration/)
+ -  [Kubectl 命令参考](/docs/user-guide/kubectl/v1.6/)
+ -  [Kubernetes 对象模式参考](/docs/resources-reference/v1.6/)
+ {% endcapture %}
+
+ {% include templates/concept.md %}
@@ -0,0 +1,157 @@
+---
+title: Kubernetes 对象管理
+redirect_from:
+- "/docs/concepts/tools/kubectl/object-management-overview/"
+- "/docs/concepts/tools/kubectl/object-management-overview.html"
+- "/docs/user-guide/working-with-resources/"
+- "/docs/user-guide/working-with-resources.html"
+---
+
+{% capture overview %}
+`kubectl` 命令行工具支持 Kubernetes 对象几种不同的创建和管理方法。本文档简要介绍了这些方法.
+{% endcapture %}
+
+{% capture body %}
+
+## 管理技巧
+
+**警告:** Kubernetes 对象应该只使用一种技术进行管理。混合使用不同的技术，会导致相同对象出现未定义的行为。
+
+| 管理技术             | 操作         |推荐环境 | 支持撰写  | 学习曲线 |
+|----------------------------------|----------------------|------------------------|--------------------|----------------|
+| 命令式的方式              | 活动对象         | 开发项目   | 1+                 | 最低         |
+| 命令式对象配置  | 单文件     | 生产项目    | 1                  | 中等       |
+| 声明式对象配置 | 文件目录 | 生产项目    | 1+                 | 最高        |
+
+## 命令式的方式
+
+当使用命令式的命令时，用户直接对集群中的活动对象进行操作。用户提供 `kubectl` 命令的参数或标记进行操作。
+
+这是在集群中启动或运行一次性任务的最简单的方法。因为这种技术直接在活动对象上运行，所以它没有提供以前配置的历史记录。
+
+### 例子
+
+通过创建 Deployment 对象来运行 nginx 容器的实例:
+
+```sh
+kubectl run nginx --image nginx
+```
+
+使用不同的语法做同样的事情:
+
+```sh
+kubectl create deployment nginx --image nginx
+```
+
+### 权衡
+
+与对象配置相比的优点:
+
+ - 命令简单易学，易于记忆。
+ - 命令只需要一个步骤即可对群集进行更改。
+
+与对象配置相比的缺点:
+
+ - 命令不与变更审核流程整合。
+ - 命令不提供与更改相关联的审计跟踪。
+ - 除了活动对象之外，命令不提供记录来源。
+ - 命令不提供用于创建新对象的模板。
+
+## 命令式对象配置
+
+在命令式对象配置中，`kubectl` 命令指定操作(创建，替换等)，可选标志和至少一个文件名称。指定的文件必须包含对象的完整定义以 YAML 或 JSON 格式。
+
+请参阅[参考资源](https://kubernetes.io/docs/resources-reference/v1.6/)
+查看有关对象定义的更多细节。
+
+**警告:** 命令式 `replace` 命令用新提供的命令替换现有资源规格，将对配置文件中缺少的对象的所有更改都丢弃。这种方法不应更新与配置文件无关的资源类型。例如，`LoadBalancer` 类型的服务使其 `externalIPs` 字段与集群的配置无关。
+
+### 例子
+
+创建对象定义配置文件:
+
+```sh
+kubectl create -f nginx.yaml
+```
+
+删除两个配置文件中定义的对象:
+
+```sh
+kubectl delete -f nginx.yaml -f redis.yaml
+```
+
+通过覆写实时配置更新配置文件中定义的对象:
+
+```sh
+kubectl replace -f nginx.yaml
+```
+
+### 权衡
+
+与命令式的命令相比的优点:
+
+ - 对象配置可以存储在源码控制系统中，如Git。
+ - 对象配置可以与进程集成，例如在推送和审计跟踪之前查看更改。
+ - 对象配置提供了一个用于创建新对象的模板。
+
+与命令式的命令相比的缺点:
+
+ - 对象配置需要对对象模式有基本的了解。
+ - 对象配置需要编写 YAML 文件的附加步骤。
+
+与声明式对象配置相比的优势:
+
+ - 命令对象配置行为更简单易懂。
+ - 至于 Kubernetes 1.5 版本，命令式对象配置更为成熟。
+
+与声明式对象配置相比的缺点:
+
+ - 命令对象配置最适合于文件，而不是目录。
+ - 活动对象的更新必须反映在配置文件中，否则在下次更替时将丢失。
+
+## 声明式对象配置
+
+当使用声明式对象配置时，用户对本地存储的对象配置文件进行操作，但是用户没有定义要对文件执行的操作。通过 `kubectl` 自动检测每个对象进行创建、更新和删除操作。这样可以在目录层级上工作，因为不同的对象可能需要不同的操作。
+
+**注意:** 声明式对象配置保留由其他对象进行的更改，即使更改未合并到对象配置文件中。这可以通过使用 `patch` API 操作来写入观察到的差异，而不是使用`replace` API 操作来替换整个对象的配置。
+
+### 例子
+
+处理`configs` 目录中的所有对象配置文件，创建或修补(patch)活动对象:
+
+```sh
+kubectl apply -f configs/
+```
+
+递归处理目录:
+
+```sh
+kubectl apply -R -f configs/
+```
+
+### 权衡
+
+与命令式对象配置相比的优点:
+
+ - 直接对活动对象进行的更改将被保留，即使它们未被并入到配置文件中。
+ - 声明式对象配置更好地支持目录操作，并自动检测每个对象的操作类型 (创建、修补，删除)。
+
+与命令式对象配置相比的缺点:
+
+- 声明式对象配置在意外情况下难以调试和了解结果。
+- 使用差异的部分更新会创建复杂的合并和补丁操作。
+
+ {% endcapture %}
+
+ {% capture whatsnext %}
+ -  [使用命令式的命令管理 Kubernetes 对象](/docs/tutorials/object-management-kubectl/imperative-object-management-command/)
+ -  [使用对象配置管理 Kubernetes 对象(必要)](/docs/tutorials/object-management-kubectl/imperative-object-management-configuration/)
+ -  [使用对象配置(声明式)管理 Kubernetes 对象](/docs/tutorials/object-management-kubectl/declarative-object-management-configuration/)
+ -  [Kubectl 命令参考](/docs/user-guide/kubectl/v1.6/)
+ -  [Kubernetes 对象模式参考](/docs/resources-reference/v1.6/)
+
+ {% comment %}
+ {% endcomment %}
+ {% endcapture %}
+
+ {% include templates/concept.md %}
@@ -0,0 +1,10 @@
+---
+assignees:
+- k8s-merge-robot
+
+title: 认识 Kubernetes?
+---
+
+{% include user-guide-content-moved.md %}
+
+[认识 Kubernetes?](/docs/concepts/overview/what-is-kubernetes/)
@@ -0,0 +1,453 @@
+#caseStudyTitle {
+    margin-top: 1em !important;
+    font-family:"Roboto", sans-serif;
+}
+
+body {
+
+  background-color:#ffffff;
+}
+
+p {
+  font-family:"Roboto", sans-serif;
+  padding:5%;
+}
+
+a {
+  text-decoration:none;
+  color:#3366ff;
+}
+
+body {
+  margin:0;
+
+}
+
+h1 {
+  font-family:"Roboto", sans-serif;
+  font-weight:bold;
+  letter-spacing:0.025em;
+  font-size:42px;
+  padding-bottom:0px;
+}
+
+.subhead {
+  font-size:26px;
+  font-weight:100;
+  line-height:40px;
+  padding-bottom:1%;
+
+}
+
+.banner1 {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  padding-top:12%;
+  padding-bottom:0.5%;
+  padding-left:9.9%;
+  font-size:32px;
+  background: url('/images/CaseStudy_box_banner1.jpg');
+  background-size:100% auto;
+  background-repeat:no-repeat;
+
+}
+
+.banner2 {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  padding-top:3%;
+  padding-bottom:3%;
+  font-size:21px;
+  letter-spacing:0.03em;
+  line-height:32px;
+  float:left;
+  background-size:100% auto;
+  background-color:#666666;
+  background-repeat:no-repeat;
+
+}
+
+.banner3 {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  padding-top:5%;
+  padding-bottom:5%;
+  font-size:21px;
+  letter-spacing:0.03em;
+  line-height:32px;
+  float:left;
+  background: url('/images/CaseStudy_box_banner3.jpg');
+  background-size:100% auto;
+}
+
+.banner4 {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  padding-top:5%;
+  padding-bottom:5%;
+  font-size:21px;
+  letter-spacing:0.03em;
+  line-height:32px;
+  float:left;
+  background: url('/images/CaseStudy_box_banner4.jpg');
+  background-size:100% auto;
+}
+
+.banner5 {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  padding-top:3%;
+  padding-bottom:3%;
+  font-size:21px;
+  letter-spacing:0.03em;
+  line-height:32px;
+  float:left;
+  background-size:100% auto;
+  background-color:#666666;
+  background-repeat:no-repeat;
+}
+
+.banner2text {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  width:60%;
+  padding-left:19%;
+  float:left;
+  text-align:center;
+}
+
+.banner3text {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  width:55%;
+  padding-left:21%;
+  text-align:center;
+}
+
+.banner4text {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  width:55%;
+  padding-left:21%;
+  text-align:center;
+}
+
+.banner5text {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  width:60%;
+  padding-left:19%;
+  float:left;
+  text-align:center;
+}
+
+
+h2 {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  font-size:24px;
+  line-height:34px;
+  color:#3366ff;
+}
+
+.quote {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  font-size:22px;
+  line-height:32px;
+  color:#3366ff;
+}
+
+.details {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  font-size:18px;
+  color:#3366ff;
+  letter-spacing:0.03em;
+  padding-bottom:1.5%;
+  padding-top:2%;
+  padding-left:10%;
+}
+
+
+
+hr {
+  border-bottom:0px solid;
+  width:100%;
+  opacity:0.5;
+  color:#aaaaaa;
+  height:1px;
+}
+
+.col1 {
+
+width: 38%;
+padding-left:5%;
+padding-right:8%;
+float:left;
+font-family:"Roboto", sans-serif;
+font-weight:100;
+color:#606060;
+line-height:20px;
+  letter-spacing:0.03em;
+font-size:14px;
+
+}
+
+.col2 {
+
+width: 44%;
+font-family:"Roboto", sans-serif;
+font-weight:300;
+float:left;
+line-height:20px;
+color:#606060;
+  letter-spacing:0.03em;
+font-size:14px;
+
+}
+
+
+
+.fullcol {
+  width:77%;
+  margin-left:11%;
+  margin-right:10%;
+  margin-top:4%;
+  margin-bottom:6%;
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  float:left;
+  line-height:22px;
+  color:#606060;
+  letter-spacing:0.03em;
+  font-size:14px;
+}
+
+.cols {
+  width:77%;
+  margin-left:6%;
+  margin-top:1%;
+  margin-bottom:4%;
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  float:left;
+
+}
+
+h4 {
+  font-family:"Roboto", sans-serif;
+  font-weight:400;
+  letter-spacing:0.9;
+  font-size:20px;
+  padding-bottom:0px;
+}
+
+
+@media screen and (max-width: 910px){
+
+h1 {
+  font-family:"Roboto", sans-serif;
+  font-weight:bold;
+  line-height:36px;
+  letter-spacing:0.03em;
+  font-size:30px !important;
+  padding-bottom:0px;
+  width:80%;
+}
+
+.subhead {
+  font-size:18px;
+  font-weight:100;
+  line-height:27px;
+}
+
+.details {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  font-size:16px;
+  color:#3366ff;
+  letter-spacing:0.03em;
+  padding-bottom:2%;
+  line-height:28px;
+  padding-top:4%;
+  padding-left:10%;
+}
+
+.logo {
+    width:8%;
+}
+
+.col1 {
+  width: 100%;
+  padding-left:5%;
+  padding-right:8%;
+  float:left;
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#606060;
+  line-height:20px;
+  letter-spacing:0.03em;
+  font-size:14px;
+}
+
+.col2 {
+  width: 100%;
+  padding-left:5%;
+  padding-top:5%;
+  padding-bottom:5%;
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  float:left;
+  line-height:20px;
+  color:#606060;
+  letter-spacing:0.03em;
+  font-size:14px;
+}
+
+.banner1 {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  padding-top:15%;
+  padding-bottom:2%;
+  padding-left:10%;
+  font-size:18px;
+  background: url('/images/CaseStudy_box_banner1.jpg');
+  background-size:100% auto;
+}
+
+.banner2 {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  padding-top:4%;
+  padding-bottom:4%;
+  padding-left:0%;
+  font-size:18px;
+  letter-spacing:0.03em;
+  line-height:24px;
+  width:100%;
+  float:left;
+  background:none;
+  background-color:#666666;
+}
+
+.banner3 {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  padding-top:5%;
+  padding-bottom:5%;
+  font-size:18px;
+  letter-spacing:0.03em;
+  line-height:24px;
+  width:100%;
+  float:left;
+  background: url('/images/CaseStudy_box_banner3.jpg');
+}
+
+.banner4 {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  padding-top:5%;
+  padding-bottom:5%;
+  font-size:18px;
+  letter-spacing:0.03em;
+  line-height:24px;
+  width:100%;
+  float:left;
+  background: url('/images/CaseStudy_box_banner4.jpg');
+}
+
+.banner5 {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  padding-top:4%;
+  padding-bottom:4%;
+  padding-left:0%;
+  font-size:18px;
+  letter-spacing:0.03em;
+  line-height:24px;
+  width:100%;
+  float:left;
+  background:none;
+  background-color:#666666;
+}
+
+.banner2text {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  width:80%;
+  padding-left:10%;
+  float:left;
+  text-align:center;
+  color:#ffffff;
+}
+
+.banner4text {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  width:80%;
+  padding-left:10%;
+  text-align:center;
+}
+
+.banner3text {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  width:80%;
+  padding-left:10%;
+  text-align:center;
+}
+
+.banner5text {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  width:80%;
+  padding-left:10%;
+  float:left;
+  text-align:center;
+  color:#ffffff;
+}
+
+.fullcol {
+  margin-top:6%;
+}
+
+h2 {
+  line-height:26px;
+  font-size:18px;
+}
+
+.quote {
+  font-size:18px;
+  line-height:24px;
+}
+
+.logo {
+  width:15%;
+}
+
+@media screen and (max-width: 480px){
+
+  .logo {
+    width:22%;
+    padding-bottom:2%;
+  }
+}
@@ -0,0 +1,454 @@
+#caseStudyTitle {
+    margin-top: 1em !important;
+    font-family:"Roboto", sans-serif;
+}
+
+p {
+  font-family:"Roboto", sans-serif;
+  padding:5%;
+}
+
+a {
+  text-decoration:none;
+  color:#3366ff;
+}
+
+body {
+  margin:0;
+
+}
+
+h1 {
+  font-family:"Roboto", sans-serif;
+  font-weight:bold;
+  letter-spacing:0.025em;
+  font-size:42px;
+  padding-bottom:0px;
+}
+
+.subhead {
+  font-size:26px;
+  font-weight:100;
+  line-height:40px;
+  padding-bottom:1%;
+
+}
+
+.banner1 {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  padding-top:12%;
+  padding-bottom:0.5%;
+  padding-left:9.9%;
+  font-size:32px;
+  background: url('/images/CaseStudy_golfnow_banner1.jpg');
+  background-size:100% auto;
+  background-repeat:no-repeat;
+}
+
+.banner2 {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  padding-top:3%;
+  padding-bottom:3%;
+  font-size:21px;
+  letter-spacing:0.03em;
+  line-height:32px;
+  float:left;
+  background-size:100% auto;
+  background-color:#666666;
+  background-repeat:no-repeat;
+
+}
+
+.banner3 {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  padding-left:5%;
+  padding-right:5%;
+  padding-top:6%;
+  padding-bottom:6%;
+  font-size:21px;
+  letter-spacing:0.03em;
+  line-height:32px;
+  float:left;
+  background: url('/images/CaseStudy_golfnow_banner3.jpg');
+  background-size:100% auto;
+}
+
+.banner4 {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  padding-top:5%;
+  padding-bottom:5%;
+  font-size:21px;
+  letter-spacing:0.03em;
+  line-height:32px;
+  float:left;
+  background: url('/images/CaseStudy_golfnow_banner4.jpg');
+  background-size:100% auto;
+}
+
+.banner5 {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  padding-top:3%;
+  padding-bottom:3%;
+  font-size:21px;
+  letter-spacing:0.03em;
+  line-height:32px;
+  float:left;
+  background-size:100% auto;
+  background-color:#666666;
+  background-repeat:no-repeat;
+}
+
+.banner2text {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  width:60%;
+  padding-left:19%;
+  float:left;
+  text-align:center;
+}
+
+.banner3text {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  width:70%;
+  padding-left:15%;
+  text-align:center;
+}
+
+.banner4text {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  width:55%;
+  padding-left:21%;
+  text-align:center;
+}
+
+.banner5text {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  width:60%;
+  padding-left:19%;
+  float:left;
+  text-align:center;
+}
+
+
+h2 {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  font-size:24px;
+  line-height:34px;
+  color:#3366ff;
+}
+
+.quote {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  font-size:22px;
+  line-height:32px;
+  color:#3366ff;
+}
+
+.details {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  font-size:18px;
+  color:#3366ff;
+  letter-spacing:0.03em;
+  padding-bottom:1.5%;
+  padding-top:2%;
+  padding-left:10%;
+}
+
+
+
+hr {
+  border-bottom:0px solid;
+  width:100%;
+  opacity:0.5;
+  color:#aaaaaa;
+  height:1px;
+}
+
+.col1 {
+
+width: 38%;
+padding-left:5%;
+padding-right:8%;
+float:left;
+font-family:"Roboto", sans-serif;
+font-weight:100;
+color:#606060;
+line-height:20px;
+  letter-spacing:0.03em;
+font-size:14px;
+
+}
+
+.col2 {
+
+width: 44%;
+font-family:"Roboto", sans-serif;
+font-weight:300;
+float:left;
+line-height:20px;
+color:#606060;
+  letter-spacing:0.03em;
+font-size:14px;
+
+}
+
+
+
+.fullcol {
+  width:77%;
+  margin-left:11%;
+  margin-right:10%;
+  margin-top:4%;
+  margin-bottom:6%;
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  float:left;
+  line-height:22px;
+  color:#606060;
+  letter-spacing:0.03em;
+  font-size:14px;
+}
+
+.cols {
+  width:77%;
+  margin-left:6%;
+  margin-top:1%;
+  margin-bottom:4%;
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  float:left;
+
+}
+
+h4 {
+  font-family:"Roboto", sans-serif;
+  font-weight:400;
+  letter-spacing:0.9;
+  font-size:20px;
+  padding-bottom:0px;
+}
+
+
+@media screen and (max-width: 910px){
+
+h1 {
+  font-family:"Roboto", sans-serif;
+  font-weight:bold;
+  line-height:36px;
+  letter-spacing:0.03em;
+  font-size:30px !important;
+  padding-bottom:0px;
+  width:80%;
+}
+
+.subhead {
+  font-size:18px;
+  font-weight:100;
+  line-height:27px;
+}
+
+.details {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  font-size:16px;
+  color:#3366ff;
+  letter-spacing:0.03em;
+  padding-bottom:2%;
+  line-height:28px;
+  padding-top:4%;
+  padding-left:10%;
+}
+
+.logo {
+    width:8%;
+}
+
+.col1 {
+  width: 100%;
+  padding-left:5%;
+  padding-right:8%;
+  float:left;
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#606060;
+  line-height:20px;
+  letter-spacing:0.03em;
+  font-size:14px;
+}
+
+.col2 {
+  width: 100%;
+  padding-left:5%;
+  padding-top:5%;
+  padding-bottom:5%;
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  float:left;
+  line-height:20px;
+  color:#606060;
+  letter-spacing:0.03em;
+  font-size:14px;
+}
+
+.banner1 {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  padding-top:15%;
+  padding-bottom:2%;
+  padding-left:10%;
+  font-size:18px;
+  background: url('/images/CaseStudy_golfnow_banner1.jpg');
+  background-size:100% auto;
+}
+
+.banner2 {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  padding-top:4%;
+  padding-bottom:4%;
+  padding-left:0%;
+  font-size:18px;
+  letter-spacing:0.03em;
+  line-height:24px;
+  width:100%;
+  float:left;
+  background:none;
+  background-color:#666666;
+}
+
+.banner3 {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  padding-top:5%;
+  padding-bottom:5%;
+  font-size:18px;
+  letter-spacing:0.03em;
+  line-height:24px;
+  width:80%;
+  padding-left:15%;
+  padding-right:10%;
+  float:left;
+  background: url('/images/CaseStudy_golfnow_banner3.jpg');
+}
+
+.banner4 {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  padding-top:5%;
+  padding-bottom:5%;
+  font-size:18px;
+  letter-spacing:0.03em;
+  line-height:24px;
+  width:100%;
+  float:left;
+  background: url('/images/CaseStudy_golfnow_banner4.jpg');
+}
+
+.banner5 {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  padding-top:4%;
+  padding-bottom:4%;
+  padding-left:0%;
+  font-size:18px;
+  letter-spacing:0.03em;
+  line-height:24px;
+  width:100%;
+  float:left;
+  background:none;
+  background-color:#666666;
+}
+
+.banner2text {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  width:80%;
+  padding-left:10%;
+  float:left;
+  text-align:center;
+  color:#ffffff;
+}
+
+.banner3text {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  width:80%;
+  padding-left:2%;
+  padding-right:10%;
+  padding-top:5%;
+  padding-bottom:5%;
+  text-align:center;
+}
+
+.banner4text {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  width:80%;
+  padding-left:10%;
+  text-align:center;
+}
+
+.banner5text {
+  font-family:"Roboto", sans-serif;
+  font-weight:300;
+  color:#ffffff;
+  width:80%;
+  padding-left:10%;
+  float:left;
+  text-align:center;
+  color:#ffffff;
+}
+
+.fullcol {
+  margin-top:6%;
+}
+
+h2 {
+  line-height:26px;
+  font-size:18px;
+}
+
+.quote {
+  font-size:18px;
+  line-height:24px;
+}
+
+.logo {
+  width:35%;
+}
+
+@media screen and (max-width: 480px){
+
+  .logo {
+    width:50%;
+    padding-bottom:5%;
+  }
+}
@@ -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

@@ -142,7 +143,7 @@ By default the Kubernetes API server serves HTTP on 2 ports:

  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.
@@ -1,31 +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.
-* [Contiv](http://contiv.github.io) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](http://github.com/contiv). The [installer](http://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options.
-* [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 &amp; 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!
@@ -87,7 +87,7 @@ The ImagePolicyWebhook plug-in allows a backend webhook to make admission decisi
 ```

 #### Configuration File Format
-ImagePolicyWebhook uses the admission 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
 {
@@ -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

@@ -257,9 +257,62 @@ storage classes and how to mark a storage class as default.
 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):

@@ -1,9 +0,0 @@
---
-assignees:
- stclair
-title: AppArmor
---
-
-{% include user-guide-content-moved.md %}
-
-[AppArmor](/docs/tutorials/clusters/apparmor/)
@@ -1,10 +0,0 @@
---
-assignees:
- soltysh
- sttts
-title: Audit in Kubernetes
---
-
-{% include user-guide-content-moved.md %}
-
-[Auditing](/docs/concepts/cluster-administration/audit/)
@@ -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.

@@ -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 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
@@ -459,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.

@@ -493,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`.
@@ -504,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

@@ -525,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>`.
@@ -586,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).
@@ -1,674 +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-mode=RBAC` is an experimental implementation which allows
-for authorization to be driven by the Kubernetes API.
-RBAC stands for Role-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.
-    - 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 `/foo/` and all of its subpaths.
-    - `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.
-
-## 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.
-
-When bootstrapping, superuser credentials should include the `system:masters`
-group, for example by creating a client cert with `/O=system:masters`. This
-gives those credentials full access to the API and allows an admin to then set
-up bindings for other users.
-
-In Kubernetes versions 1.4 and 1.5, there was a similar flag that gave a user
-full access:
-
-```
--authorization-rbac-super-user=admin
-```
-
-__This flag will be removed in 1.6__. Admins should prefer the `system:masters`
-group when setting up clusters.
-
-### 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/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
-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.
@@ -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 %}
@@ -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 %}
@@ -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.
@@ -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
+```
@@ -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 %}
@@ -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.
@@ -1,9 +0,0 @@
---
-assignees:
- lavalamp
-title: Kubernetes Components
---
-
-{% include user-guide-content-moved.md %}
-
-[Kubernetes Components](/docs/concepts/overview/components/)
@@ -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.
@@ -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.
@@ -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 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/concepts/jobs/run-to-completion-finite-workloads/) 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.
@@ -1,9 +0,0 @@
---
-assignees:
- davidopp
-title: Pod Disruption Budget
---
-
-{% include user-guide-content-moved.md %}
-
-[Configuring a Pod Disruption Budget](/docs/tasks/configure-pod-container/configure-pod-disruption-budget/)
@@ -1,10 +0,0 @@
---
-assignees:
- davidopp
- thockin
-title: Using DNS Pods and Services
---
-
-{% include user-guide-content-moved.md %}
-
-[DNS Pods and Services](/docs/concepts/services-networking/dns-pod-service/)
@@ -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/latest/op-guide/recovery.html),
-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"
-```
@@ -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.
@@ -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
@@ -2,7 +2,6 @@
 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
@@ -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
@@ -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.
@@ -1,9 +0,0 @@
---
-assignees:
- madhusudancs
-title: Setting up Cluster Federation with Kubefed
---
-
-{% include user-guide-content-moved.md %}
-
-[Setting up Cluster Federation with kubefed](/docs/tutorials/federation/set-up-cluster-federation-kubefed/)
@@ -1,75 +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 every 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 0 minute, which means every finished container will be garbaged collected.
-2. `maximum-dead-containers-per-container`, maximum number of old instances to be retained
-per container. Default is 1.
-3. `maximum-dead-containers`, maximum number of old instances of containers to retain globally.
-Default is -1, which means there is no global limit.
-
-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 1 dead container to be
-retained per expected container. A larger 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.
-
-
-### Deprecation
-
-Some kubelet Garbage Collection features in this doc will be replaced by kubelet eviction in the future.
-
-Including:
-
-| Existing Flag | New Flag | Rationale |
-| ------------- | -------- | --------- |
-| `--image-gc-high-threshold` | `--eviction-hard` or `--eviction-soft` | existing eviction signals can trigger image garbage collection |
-| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaims achieve the same behavior |
-| `--maximum-dead-containers` | | deprecated once old logs are stored outside of container's context |
-| `--maximum-dead-containers-per-container` | | deprecated once old logs are stored outside of container's context |
-| `--minimum-container-ttl-duration` | | deprecated once old logs are stored outside of container's context |
-| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | eviction generalizes disk thresholds to other resources |
-| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | eviction generalizes disk pressure transition to other resources |
-
-See [Configuring Out Of Resource Handling](/docs/admin/out-of-resource/) for more details.
@@ -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](/images/docs/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)
-
--- a/Show More
+++ b/Show More
				`@@ -1 +0,0 @@`
				`*NOTE: This feature is beta in Kubernetes 1.5.*`