Backport OWNERS from master to 1.7 (#9490)

fix version navigation in release v1.7

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,4 +1,8 @@
-> NOTE: Please check the “Allow edits from maintainers” box (see image below) to  
+> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+> For 1.8 Features: set Milestone to `1.8` and Base Branch to `release-1.8`
+> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+>
+> 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.

.travis.yml

@@ -1,29 +1,21 @@
 language: go
 go:
-  - 1.8.1
+  - 1.8.3
 
 # Don't want default ./... here:
 install:
 - export PATH=$GOPATH/bin:$PATH
 - mkdir -p $HOME/gopath/src/k8s.io
-- mv $TRAVIS_BUILD_DIR $HOME/gopath/src/k8s.io/kubernetes.github.io
+- mv $TRAVIS_BUILD_DIR $HOME/gopath/src/k8s.io/website
+- cd $HOME/gopath/src/k8s.io/website
 
 # (1) Fetch dependencies for us to run the tests in test/examples_test.go
-- go get -t -v k8s.io/kubernetes.github.io/test
-
-# Simplified deduplication of dependencies.
+- pushd $GOPATH/src/k8s.io && git clone https://github.com/kubernetes/kubernetes && popd
+- pushd $GOPATH/src/k8s.io/kubernetes && git checkout release-1.7 && popd
 - cp -L -R $GOPATH/src/k8s.io/kubernetes/vendor/ $GOPATH/src/
 - rm -r $GOPATH/src/k8s.io/kubernetes/vendor/
-
-# (2) Fetch md-check along with all its dependencies.
-- git clone --depth=50 --branch=master https://github.com/kubernetes/md-check $HOME/gopath/src/k8s.io/md-check
-- go get -t -v k8s.io/md-check
-
-# (3) Fetch mungedocs
-- go get -v k8s.io/kubernetes/cmd/mungedocs
+- go get -t -v k8s.io/website/test
 
 script:
-- go test -v k8s.io/kubernetes.github.io/test
-- $GOPATH/bin/md-check --root-dir=$HOME/gopath/src/k8s.io/kubernetes.github.io
+- go test -v k8s.io/website/test
 - ./verify-docs-format.sh
-- $GOPATH/bin/mungedocs --verbose --verify --upstream=origin --root-dir=$HOME/gopath/src/k8s.io/kubernetes.github.io/docs/ --repo-root=$HOME/gopath/src/k8s.io/kubernetes.github.io --skip-munges=remove-whitespace,blank-lines-surround-preformatted,header-lines,sync-examples,analytics,analytics,kubectl-dash-f,table-of-contents,md-links,kubectl-dash-f

CNAME

@@ -1 +0,0 @@
-kubernetes.io

Gemfile.lock

@@ -155,7 +155,7 @@ GEM
       gemoji (~> 2.0)
       html-pipeline (~> 2.2)
       jekyll (>= 3.0)
-    json (1.8.3)
+    json (1.8.6)
     kramdown (1.11.1)
     liquid (3.0.6)
     listen (3.0.6)
@@ -200,4 +200,4 @@ DEPENDENCIES
   jekyll-include-cache (~> 0.1)
 
 BUNDLED WITH
-   1.13.6
+   1.15.2

Makefile

@@ -6,10 +6,13 @@ help: ## Show this help.
 all: build ## Build site with production settings and put deliverables in _site.
 
 build: ## Build site with production settings and put deliverables in _site.
-	jekyll build
+	bundle exec jekyll build
 
 build-preview: ## Build site with drafts and future posts enabled.
-	jekyll build --drafts --future
+	bundle exec jekyll build --drafts --future
 
 serve: ## Boot the development server.
-	jekyll serve
+	bundle exec jekyll serve
+
+stage: ## Run the Jekyll staging container.
+	docker run -ti --rm -v "${PWD}":/k8sdocs -p 4000:4000 gcr.io/google-samples/k8sdocs:1.1

OWNERS

@@ -1,6 +1,21 @@
-assignees:
-- smarterclayton
-- janetkuo
-- pwittrock
-- kelseyhightower
-- jaredbhatti
+# Reviewers can /lgtm /approve but not sufficient for auto-merge without an
+# approver
+reviewers:
+- rajakavitha1
+- stewart-yu
+- xiangpengzhao
+- zhangxiaoyu-zidif
+
+# Approvers have all the ability of reviewers but their /approve makes
+# auto-merge happen if a /lgtm exists, or vice versa, or they can do both
+# No need for approvers to also be listed as reviewers
+approvers:
+- bradamant3
+- bradtopol
+- chenopis
+- kbarnard10
+- mistyhacks
+- steveperry-53
+- tengqm
+- zacharysarah
+- zparnold

README.md

@@ -9,6 +9,7 @@ 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/home/contribute/create-pull-request/)
 * [Writing a New Topic](http://kubernetes.io/docs/home/contribute/write-new-topic/)
+* [Review Issues](http://kubernetes.io/docs/home/contribute/review-issues/)
 * [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/)

_config.yml

@@ -18,10 +18,39 @@ defaults:
     scope:
       path: ""
     values:
-      fullversion: "v1.7.0"
+      fullversion: "v1.7.3"
       version: "v1.7"
-      githubbranch: "master"
-      docsbranch: "master"
+      githubbranch: "v1.7.3"
+      docsbranch: "release-1.7"
+      versions:
+      - fullversion: "v1.11.0"
+          version: "v1.11"
+          githubbranch: "v1.11.0"
+          docsbranch: "release-1.11"
+          url:  https://kubernetes.io/docs/
+      - fullversion: "v1.10.0"
+          version: "v1.10"
+          githubbranch: "v1.10.0"
+          docsbranch: "release-1.10"
+          url:  https://v1-10.docs.kubernetes.io/
+        - fullversion: "v1.9.0"
+          version: "v1.9"
+          githubbranch: "v1.9.0"
+          docsbranch: "release-1.9"
+          url: https://v1-9.docs.kubernetes.io/docs/home/
+        - fullversion: "v1.8.4"
+          version: "v1.8"
+          githubbranch: "v1.8.4"
+          docsbranch: "release-1.8"
+          url: https://v1-8.docs.kubernetes.io/docs/home/
+        - fullversion: "v1.7.3"
+          version: "v1.7"
+          githubbranch: "v1.7.3"
+          docsbranch: "release-1.7"
+          url: https://v1-7.docs.kubernetes.io/docs/home/
+      deprecated: true
+      currentUrl: https://kubernetes.io/docs/home/
+      nextUrl: http://kubernetes-io-vnext-staging.netlify.com/
   -
     scope:
       path: "docs"
@@ -39,7 +68,7 @@ gems:
 # disabled gems
 #  - jekyll-redirect-from
 
-include: [_redirects]
+include: [_redirects,_headers]
 
 # SEO
 logo: /images/favicon.png

_data/canonical-tags.yml

@@ -0,0 +1,12 @@
+- Fundamental
+- API Object
+- Metadata
+- Configuration
+- Security
+- Networking
+- Storage
+- Operation
+- Workload
+- Component
+- API
+- Extension

_data/concepts.yml

@@ -24,7 +24,7 @@ toc:
 - title: Extending the Kubernetes API
   section:
   - docs/concepts/api-extension/custom-resources.md
-  - docs/concepts/api-extension/apiserver-aggregation.md  
+  - docs/concepts/api-extension/apiserver-aggregation.md
 
 - title: Containers
   section:
@@ -58,7 +58,9 @@ toc:
   - docs/concepts/configuration/overview.md
   - docs/concepts/configuration/manage-compute-resources-container.md
   - docs/concepts/configuration/assign-pod-node.md
+  - docs/concepts/configuration/taint-and-toleration.md
   - docs/concepts/configuration/secret.md
+  - docs/concepts/configuration/organize-cluster-access-kubeconfig.md
 
 - title: Services, Load Balancing, and Networking
   section:
@@ -79,6 +81,7 @@ toc:
 - title: Cluster Administration
   section:
   - docs/concepts/cluster-administration/cluster-administration-overview.md
+  - docs/concepts/cluster-administration/cloud-providers.md
   - docs/concepts/cluster-administration/manage-deployment.md
   - docs/concepts/cluster-administration/networking.md
   - docs/concepts/cluster-administration/network-plugins.md

_data/glossary/_example.yml

@@ -0,0 +1,17 @@
+id: _example
+name: Example K8s Term
+formerly:
+- Slang K8s Term
+- Misnomer
+- Formerly Known as Prince
+related:
+- Less Fancy K8s Term
+- Tangential Term
+- Commonly Used With
+tags:
+- Some Tag
+short-description: |
+  Required. One or two lines that provide a minimum definition. Do not repeat the term. Write about the plural of the term. Prefer fragments. Model after tooltips. End with a period.
+long-description: |
+  Optional. Longer additional text to appear after (in conjunction with) short description. Provide where the short description is not sufficient as the intro paragraph to a topic. Write complete but concise sentences.
+  **See /_includes/templates/glossary/README.md for the official style guide.**

_data/glossary/statefulset.yml

@@ -0,0 +1,18 @@
+id: statefulset
+name: StatefulSet
+formerly:
+- PetSet
+related:
+- Deployment
+- Pod
+tags:
+- Storage
+- Workload
+- API Object
+short-description: |
+  Manage the deployment and scaling of a set of Pods, *and provide guarantees about ordering*. They do so by maintaining a *unique*, sticky identity for each of their Pods.
+
+long-description: |
+  Like Deployments, StatefulSets manage Pods that are based on an identical container spec. However, although their specs are the same, the Pods in a StatefulSet are not interchangeable. Each Pod has a persistent identifier that it maintains across any rescheduling.
+
+  StatefulSets also operate according to the Controller pattern. You define your desired state in a StatefulSet *object*, and the StatefulSet *controller* makes any necessary updates to the get there from the current state.

_data/reference.yml

@@ -28,10 +28,6 @@ toc:
   section:
   - 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:
@@ -90,16 +86,16 @@ toc:
 - title: Kubernetes Design Docs
   section:
   - title: Kubernetes Architecture
-    path: https://git.k8s.io/community/contributors/design-proposals/architecture.md
+    path: https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md
   - title: Kubernetes Design Overview
     path: https://github.com/kubernetes/kubernetes/tree/release-1.6/docs/design
   - title: Kubernetes Identity and Access Management
-    path: https://git.k8s.io/community/contributors/design-proposals/access.md
+    path: https://git.k8s.io/community/contributors/design-proposals/auth/access.md
   - docs/admin/ovs-networking.md
   - title: Security Contexts
-    path: https://git.k8s.io/community/contributors/design-proposals/security_context.md
+    path: https://git.k8s.io/community/contributors/design-proposals/auth/security_context.md
   - title: Security in Kubernetes
-    path: https://git.k8s.io/community/contributors/design-proposals/security.md
+    path: https://git.k8s.io/community/contributors/design-proposals/auth/security.md
 
 - title: Kubernetes Issues and Security
   section:

_data/setup.yml

@@ -30,6 +30,7 @@ toc:
   - docs/getting-started-guides/gce.md
   - docs/getting-started-guides/aws.md
   - docs/getting-started-guides/azure.md
+  - docs/getting-started-guides/alibaba-cloud.md
   - docs/getting-started-guides/clc.md
   - title: Running Kubernetes on IBM Bluemix
     path: https://github.com/patrocinio/kubernetes-softlayer
@@ -93,7 +94,6 @@ toc:
         - 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
 

_data/tasks.yml

@@ -11,7 +11,11 @@ toc:
 
 - title: Configure Pods and Containers
   section:
+  - docs/tasks/configure-pod-container/assign-memory-resource.md
+  - docs/tasks/configure-pod-container/assign-cpu-resource.md
+  - docs/tasks/configure-pod-container/quality-service-pod.md
   - docs/tasks/configure-pod-container/assign-cpu-ram-container.md
+  - docs/tasks/configure-pod-container/opaque-integer-resource.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
@@ -42,6 +46,7 @@ toc:
   - 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/update-api-object-kubectl-patch.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
@@ -61,7 +66,7 @@ toc:
   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/configure-access-multiple-clusters.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
@@ -108,17 +113,23 @@ toc:
 
 - title: Administer a Cluster
   section:
+  - title: Manage Memory, CPU, and API Resources
+    section:
+    - docs/tasks/administer-cluster/memory-default-namespace.md
+    - docs/tasks/administer-cluster/cpu-default-namespace.md
+    - docs/tasks/administer-cluster/memory-constraint-namespace.md
+    - docs/tasks/administer-cluster/cpu-constraint-namespace.md
+    - docs/tasks/administer-cluster/apply-resource-quota-limit.md
+    - docs/tasks/administer-cluster/quota-memory-cpu-namespace.md
+    - docs/tasks/administer-cluster/quota-pod-namespace.md
+    - docs/tasks/administer-cluster/quota-api-object.md
+    - docs/tasks/administer-cluster/opaque-integer-resource-node.md
   - 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
@@ -126,24 +137,27 @@ toc:
   - 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/cpu-memory-limit.md
+  - docs/tasks/administer-cluster/out-of-resource.md
+  - docs/tasks/administer-cluster/reserve-compute-resources.md
+  - docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md
   - docs/tasks/administer-cluster/declare-network-policy.md
   - title: Install Network Policy Provider
     section:
     - docs/tasks/administer-cluster/calico-network-policy.md
+    - docs/tasks/administer-cluster/cilium-network-policy.md
+    - docs/tasks/administer-cluster/kube-router-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: Federation - Run an App on Multiple Clusters
   section:
@@ -169,5 +183,3 @@ toc:
 - title: Manage GPUs
   section:
   - docs/tasks/manage-gpus/scheduling-gpus.md
-
-

_data/tutorials.yml

@@ -29,8 +29,12 @@ toc:
     section:
     - docs/tutorials/kubernetes-basics/update-intro.html
     - docs/tutorials/kubernetes-basics/update-interactive.html
-- title: Online Training Course
-  path: https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615
+- title: Online Training Courses
+  section:
+  - title: Scalable Microservices with Kubernetes (Udacity)
+    path: https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615
+  - title: Introduction to Kubernetes (edX)
+    path: https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#
 - docs/tutorials/stateless-application/hello-minikube.md
 - title: Configuration
   section:
@@ -61,4 +65,3 @@ toc:
 - title: Services
   section:
   - docs/tutorials/services/source-ip.md
-

_includes/deprecation-warning.html

@@ -0,0 +1,12 @@
+{% if page.deprecated %}
+<section id="deprecationWarning">
+  <main>
+    <div class="content deprecation-warning">
+      <h3>
+        Documentation for Kubernetes {{ page.version}} is no longer actively maintained. The version you are currently viewing is a static snapshot.
+        For up-to-date documentation, see the <a href="{{ page.currentUrl }}">latest</a> version.
+      </h3>
+    </div>
+  </main>
+</section>
+{% endif %}

_includes/head.html

@@ -8,6 +8,7 @@
     <link rel="stylesheet" type="text/css" href="/css/jquery-ui.min.css">
     <link rel="stylesheet" type="text/css" href="/css/sweetalert.css">
     <link rel="stylesheet" type="text/css" href="/css/callouts.css">
+    {% if page.deprecated %}<link rel="stylesheet" type="text/css" href="/css/deprecation-warning.css">{% endif %}
     {% if page.class == "gridPage" %}<link rel="stylesheet" type="text/css" href="/css/gridpage.css">{% endif %}
     {% if page.css %}<link rel="stylesheet" type="text/css" href="{{ page.css }}"><!-- custom css added -->{% else %}<!-- no custom css detected -->{% endif %}
 

_includes/header.html

@@ -10,6 +10,17 @@
             <li><a href="/partners/">Partners</a></li>
             <li><a href="/community/">Community</a></li>
             <li><a href="/case-studies/">Case Studies</a></li>
+            <li>
+                <a href="#">
+                    {{page.version}} <span class="ui-icon ui-icon-carat-1-s"></span>
+                </a>
+                <ul>
+                {% for version in page.versions %}
+                  <li><a href="{{ version.url }}">{{ version.version }}</a></li>
+                {% endfor %}
+                </ul>
+              </li>
+            </li>
         </ul>
         <!-- <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>

_includes/partner-script.js

@@ -1,21 +1,14 @@
 ;(function () {
 	var partners = [
 		{
-			type: 0,
+			type: 2,
 			name: 'CoreOS',
 			logo: 'core_os',
 			link: 'https://tectonic.com/',
 			blurb: 'Tectonic is the enterprise-ready Kubernetes product, by CoreOS. It adds key features to allow you to manage, update, and control clusters in production.'
 		},
 		{
-			type: 0,
-			name: 'Deis',
-			logo: 'deis',
-			link: 'https://deis.com',
-			blurb: 'Deis the creators of Helm, Workflow, and Steward, helps developers and operators build, deploy, manage and scale their applications on top of Kubernetes.'
-		},
-		{
-			type: 0,
+			type: 2,
 			name: 'StackPointCloud',
 			logo: 'stackpoint',
 			link: 'https://stackpoint.io',
@@ -49,13 +42,6 @@
 			link: 'https://www.cockroachlabs.com/blog/running-cockroachdb-on-kubernetes/',
 			blurb: 'CockroachDB is a distributed SQL database whose built-in replication and survivability model pair with Kubernetes to truly make data easy.'
 		},
-		{
-			type: 0,
-			name: 'Skippbox',
-			logo: 'skippbox',
-			link: 'http://www.skippbox.com/tag/products/',
-			blurb: 'Creator of Cabin the first mobile application for Kubernetes, and kompose. Skippbox’s solutions distill all the power of k8s in simple easy to use interfaces.'
-		},
 		{
 			type: 0,
 			name: 'Weave Works',
@@ -72,10 +58,10 @@
 		},
 		{
 			type: 0,
-			name: 'Rancher',
-			logo: 'rancher',
+			name: 'Rancher Labs',
+			logo: 'rancher-labs',
 			link: 'http://rancher.com/kubernetes/',
-			blurb: 'Rancher is an open-source, production-ready container management platform that makes it easy to deploy and leverage Kubernetes in the enterprise.'
+			blurb: 'Rancher is an open-source, production-ready container management platform that makes it easy to deploy and manage Kubernetes.'
 		},
 		{
 			type: 0,
@@ -134,7 +120,7 @@
 			blurb: 'Deep, automated security for your containers running on Kubernetes.'
 		},
 		{
-			type: 0,
+			type: 2,
 			name: 'Canonical',
 			logo: 'canonical',
 			link: 'https://jujucharms.com/canonical-kubernetes/',
@@ -183,14 +169,14 @@
 			blurb: 'Aporeto makes cloud-native applications secure by default without impacting developer velocity and works at any scale, on any cloud.'
 		},
 		{
-  			type: 0,
+  		type: 2,
  			name: 'Giant Swarm',
  			logo: 'giant_swarm',
  			link: 'https://giantswarm.io',
  			blurb: 'Giant Swarm provides fully-managed Kubernetes Clusters in your location of choice, so you can focus on your product.'
  		},
 		{
- 			type: 0,
+ 			type: 2,
  			name: 'Mirantis',
  			logo: 'mirantis',
  			link: 'https://content.mirantis.com/Containerizing-OpenStack-on-Kubernetes-Video-Landing-Page.html',
@@ -218,42 +204,28 @@
 			blurb: 'ReactiveOps has written automation on best practices for infrastructure as code on GCP & AWS using Kubernetes, helping you build and maintain a world-class infrastructure at a fraction of the price of an internal hire.'
 		},
 		{
-			type: 1,
+			type: 2,
 			name: 'Livewyer',
 			logo: 'livewyer',
 			link: 'https://livewyer.io/services/kubernetes-experts/',
 			blurb: 'Kubernetes experts that on-board applications and empower IT teams to get the most out of containerised technology.'
 		},
 		{
-			type: 1,
-			name: 'Deis',
-			logo: 'deis',
-			link: 'https://deis.com/services/',
-			blurb: 'Deis provides professional services and 24x7 operational support for any Kubernetes cluster managed by our global cluster operations team.'
-		},
-		{
-			type: 1,
-			name: 'StackPointCloud',
-			logo: 'stackpoint',
-			link: 'https://stackpoint.io',
-			blurb: 'StackPointCloud offers a wide range of support plans for managed Kubernetes clusters built through its universal control plane for Kubernetes Anywhere.'
-		},
-		{
-			type: 1,
+			type: 2,
 			name: 'Samsung SDS',
 			logo: 'samsung_sds',
 			link: 'http://www.samsungsdsa.com/cloud-infrastructure_kubernetes',
 			blurb: 'Samsung SDS’s Cloud Native Computing Team offers expert consulting across the range of technical aspects involved in building services targeted at a Kubernetes cluster.'
 		},
 		{
-			type: 1,
+			type: 2,
 			name: 'Container Solutions',
 			logo: 'container_solutions',
 			link: 'http://container-solutions.com/resources/kubernetes/',
 			blurb: 'Container Solutions is a premium software consultancy that focuses on programmable infrastructure, offering our expertise in software development, strategy and operations to help you innovate at speed and scale.'
 		},
 		{
-			type: 1,
+			type: 2,
 			name: 'Jetstack',
 			logo: 'jetstack',
 			link: 'https://www.jetstack.io/',
@@ -263,7 +235,7 @@
 			type: 0,
 			name: 'Tigera',
 			logo: 'tigera',
-			link: 'http://docs.projectcalico.org/v1.5/getting-started/kubernetes/',
+			link: 'http://docs.projectcalico.org/latest/getting-started/kubernetes/',
 			blurb: 'Tigera builds high performance, policy driven, cloud native networking solutions for Kubernetes.'
 		},
 		{
@@ -280,13 +252,6 @@
  			link: 'https://harbur.io/',
  			blurb: 'Based in Barcelona, Harbur is a consulting firm that helps companies deploy self-healing solutions empowered by Container technologies'
   		},
-		{
- 			type: 1,
- 			name: 'Endocode',
- 			logo: 'endocode',
- 			link: 'https://endocode.com/kubernetes/',
- 			blurb: 'Endocode practices and teaches the open source way. Kernel to cluster - Dev to Ops. We offer Kubernetes trainings, services and support.'
-  		},
 		{
  			type: 0,
  			name: 'Spotinst',
@@ -295,8 +260,8 @@
  			blurb: 'Spotinst uses a prediction algorithm in the Amazon EC2 Spot allowing k8s clusters to increase performance and lower the infrastructure costs'
   		},
 		{
- 			type: 1,
- 			name: 'inwinSTACK',
+ 			type: 2,
+ 			name: 'InwinSTACK',
  			logo: 'inwinstack',
  			link: 'http://www.inwinstack.com/index.php/en/solutions-en/',
  			blurb: 'Our container service leverages OpenStack-based infrastructure and its container orchestration engine Magnum to manage Kubernetes clusters.'
@@ -337,7 +302,7 @@
  			blurb: 'NATS is a simple, secure, and scalable cloud native messaging system.'
   		},
 		{
- 			type: 1,
+ 			type: 2,
  			name: 'RX-M',
  			logo: 'rxm',
  			link: 'http://rx-m.com/training/kubernetes-training/',
@@ -379,7 +344,7 @@
  			blurb: 'Full stack monitoring of containers and microservices orchestrated by Kubernetes. Powered by anomaly detection to find problems faster.'
   		},
 		{
- 			type: 0,
+ 			type: 2,
  			name: 'Supergiant.io',
  			logo: 'supergiant',
  			link: 'https://supergiant.io/blog/supergiant-packing-algorithm-unique-save-money',
@@ -424,8 +389,8 @@
  			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.'
+ 			link: 'https://cobe.io/product-page/',
+ 			blurb: 'Manage Kubernetes clusters with a live, searchable model that captures all relationships and performance data in full visualised context.'
   		},
 		{
  			type: 0,
@@ -470,7 +435,7 @@
  			blurb: 'Strong DevOps and Cloud talent working with couple clients on kubernetes and helm implementations. '
   		},
 		{
- 			type: 0,
+ 			type: 2,
  			name: 'Bitnami',
  			logo: 'bitnami',
  			link: 'http://bitnami.com/kubernetes',
@@ -498,7 +463,7 @@
  			blurb: 'Opcito is a software consultancy that uses Kubernetes to help organisations build, architect & deploy highly scalable applications.'
   		},
 		{
- 			type: 0,
+ 			type: 2,
  			name: 'Huawei Technologies Co., Ltd.',
  			logo: 'huawei',
  			link: 'http://developer.huawei.com/ict/en/site-paas',
@@ -510,10 +475,136 @@
  			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'
-  		}
-		
+			},
+		{
+ 			type: 0,
+	 		name: 'SUSE Llc.',
+	 		logo: 'suse',
+	 		link: 'https://www.suse.com/products/caas-platform/',
+	 		blurb: 'SUSE delivers Kubernetes as part of SUSE CaaS Platform and SUSE OpenStack Cloud, for enterprises that want truly open, open source solutions for cloud-native applications.'
+			},
+		{
+	 		type: 0,
+		 	name: 'Instana',
+		 	logo: 'instana',
+		 	link: 'https://www.instana.com/supported-technologies/',
+		 	blurb: 'Instana monitors the infrastructure, containers and services deployed on a Kubernetes cluster.'
+			},
+		{
+		 	type: 0,
+			name: 'Netsil',
+			logo: 'netsil',
+			link: 'https://netsil.com/kubernetes/',
+			blurb: 'Generate a real-time, auto-discovered application topology map! Monitor Kubernetes pods and namespaces without any code instrumentation.'
+			},
+		{
+			type: 2,
+			name: 'Treasure Data',
+			logo: 'treasure-data',
+			link: 'https://fluentd.treasuredata.com/kubernetes-logging/',
+			blurb: 'Fluentd Enterprise brings smart, secure logging to Kubernetes, and brings integrations with backends such as Splunk, Kafka, or AWS S3.'
+			},
+		{
+			type: 2,
+			name: 'IBM',
+			logo: 'IBM',
+			link: 'https://www.ibm.com/cloud-computing/bluemix/containers',
+			blurb: 'IBM Container Service is a managed k8s environment with built-in cluster security and isolation while leveraging services including Watson, IoT, Weather, etc.'
+			},
+		{
+			type: 1,
+			name: 'Kenzan',
+			logo: 'Kenzan',
+			link: 'http://kenzan.com/?ref=kubernetes',
+			blurb: 'Kenzan is a software engineering and full-service consulting firm that provides customized, end-to-end solutions that drive change through digital transformation.'
+			},
+		{
+			type: 0,
+			name: 'Kublr',
+			logo: 'kublr',
+			link: 'http://kublr.com',
+			blurb: 'Simplify your Kubernetes experience with a fully production-ready, enterprise-grade cluster management platform.'
+			},
+		{
+			type: 0,
+			name: 'Endocode AG',
+			logo: 'endocode',
+			link: 'https://endocode.com/kubernetes/',
+ 			blurb: 'Endocode practices and teaches the open source way. Kernel to cluster - Dev to Ops. We offer Kubernetes trainings, services and support.'
+			},
+		{
+			type: 2,
+			name: 'Accenture',
+			logo: 'accenture',
+			link: 'https://www.accenture.com/us-en/service-application-containers',
+	 		blurb: 'Architecture, implementation and operation of world-class Kubernetes solutions for cloud-native clients.'
+			},
+		{
+			type: 1,
+			name: 'Biarca',
+			logo: 'biarca',
+			link: 'http://biarca.io/',
+		 	blurb: 'Biarca is a cloud services provider and key focus areas Key areas of focus for Biarca include Cloud Adoption Services, Infrastructure Services, DevOps Services and Application Services. Biarca leverages Kubernetes to deliver containerized solutions.'
+			},
+		{
+			type: 2,
+			name: 'Claranet',
+			logo: 'claranet',
+			link: 'http://www.claranet.co.uk/hosting/google-cloud-platform-consulting-managed-services',
+			blurb: 'Claranet helps people migrate to the cloud and take full advantage of the new world it offers. We consult, design, build and proactively manage the right infrastructure and automation tooling for clients to achieve this.'
+			},
+		{
+			type: 1,
+			name: 'CloudKite',
+			logo: 'cloudkite',
+			link: 'https://cloudkite.io/',
+			blurb: 'CloudKite.io helps companies build and maintain highly automated, resilient, and impressively performing software on Kubernetes.'
+			},
+		{
+			type: 1,
+			name: 'CloudOps',
+			logo: 'CloudOps',
+			link: 'https://www.cloudops.com/services/docker-and-kubernetes-workshops/',
+			blurb: 'CloudOps gets you hands-on with the K8s ecosystem via workshop/lab. Get prod ready K8s in cloud(s) of your choice with our managed services.'
+			},
+		{
+			type: 2,
+			name: 'Ghostcloud',
+			logo: 'ghostcloud',
+			link: 'https://www.ghostcloud.cn/ecos-kubernetes',
+			blurb: 'EcOS is an enterprise-grade PaaS / CaaS based on Docker and Kubernetes, which makes it easier to configure, deploy and manage containerized applications.'
+			},
+		{
+			type: 2,
+			name: 'Contino',
+			logo: 'contino',
+			link: 'https://www.contino.io/',
+			blurb: 'We help enterprise organizations adopt DevOps, containers and cloud computing. Contino is a global consultancy that enables regulated organizations to accelerate innovation through the adoption of modern approaches to software delivery.'
+			},
+		{
+			type: 2,
+			name: 'Heptio',
+			logo: 'heptio',
+			link: 'http://heptio.com',
+			blurb: 'Heptio helps businesses of all sizes get closer to the vibrant Kubernetes community.'
+			},
+		{
+			type: 2,
+			name: 'Booz Allen Hamilton',
+			logo: 'boozallenhamilton',
+			link: 'https://www.boozallen.com/',
+			blurb: 'Booz Allen partners with public and private sector clients to solve their most difficult challenges through a combination of consulting, analytics, mission operations, technology, systems delivery, cybersecurity, engineering, and innovation expertise.'
+			},
+		{
+			type: 0,
+			name: 'Applatix',
+			logo: 'applatix',
+			link: 'https://applatix.com/applatix-product/',
+ 			blurb: 'Applatix helps build and run containerized apps on public cloud using Docker and Kubernetes.'
+	  	}
 	]
 
+	var kcspContainer = document.getElementById('kcspContainer')
 	var isvContainer = document.getElementById('isvContainer')
 	var servContainer = document.getElementById('servContainer')
 
@@ -546,7 +637,15 @@
 		box.appendChild(img)
 		box.appendChild(div)
 
-		var container = obj.type ? servContainer : isvContainer
+		var container;
+    if (obj.type === 0) {
+      container = isvContainer;
+    } else if (obj.type === 1) {
+      container = servContainer;
+    } else if (obj.type === 2) {
+      container = kcspContainer;
+    }
+
 		container.appendChild(box)
 	})
 })();

_includes/partner-style.css

@@ -1,5 +1,65 @@
+/*  SECTIONS  */
+.section {
+	clear: both;
+	padding: 0px;
+	margin-bottom: 2em;
+}
+
+/*  COLUMN SETUP  */
+.col {
+	display: block;
+	float:left;
+	margin: 1% 0 1% 1.6%;
+	background-color: #f9f9f9;
+}
+.col:first-child { margin-left: 0; }
+
+
+/*  GROUPING  */
+.group:before,
+.group:after {
+	content:"";
+	display:table;
+}
+.group:after {
+	clear:both;
+}
+.group {
+    zoom:1; /* For IE 6/7 */
+}
+
+/*  GRID OF THREE  */
+.span_3_of_3 {
+	width: 32.2%;
+	background-color: #f9f9f9;
+	padding: 20px;
+}
+.span_2_of_3 {
+	width: 32.2%;
+	background-color: #f9f9f9;
+	padding: 20px;
+}
+.span_1_of_3 {
+	width: 32.2%;
+	background-color: #f9f9f9;
+	padding: 20px;
+}
+
+/*  GO FULL WIDTH AT LESS THAN 480 PIXELS */
+
+@media only screen and (max-width: 480px) {
+	.col { margin: 1% 0 1% 0%;}
+	.span_3_of_3, .span_2_of_3, .span_1_of_3 { width: 100%; }
+}
+
+.button{
+  max-width: 100%;
+	line-height: 14px;
+	padding: 15px;
+ }
+
 h5 {
-	font-size: 18px;
+	font-size: 16px;
 	line-height: 1.5em;
 	margin-bottom: 2em;
 }
@@ -9,7 +69,7 @@ h5 {
 	background-color: #f9f9f9;
 }
 
-#isvContainer, #servContainer {
+#kcspContainer, #isvContainer, #servContainer {
 	position: relative;
 	width: 100%;
 	display: flex;
@@ -21,6 +81,10 @@ h5 {
 	margin-bottom: 80px;
 }
 
+#kcspContainer {
+	margin-bottom: 80px;
+}
+
 .partner-box {
 	position: relative;
 	width: 47%;
@@ -58,7 +122,7 @@ h5 {
 }
 
 @media screen and (max-width: 568px) {
-	#isvContainer, #servContainer {
+	#kcspContainer, #isvContainer, #servContainer {
 		justify-content: center;
 	}
 
@@ -76,7 +140,7 @@ h5 {
 }
 
 @media screen and (max-width: 568px) {
-	#isvContainer, #servContainer {
+	#kcspContainer, #isvContainer, #servContainer {
 		justify-content: center;
 	}
 

_includes/tag-map.md

@@ -0,0 +1,15 @@
+<!-- Use include_cached when incorporating this file, in order to reduce computation/build time -->
+
+{% assign glossary_terms = site.data.glossary | where_exp: "term", "term.id != '_example'" %}
+
+{% assign tag_map = "" | split: " " %}
+
+{% for tag in site.data.canonical-tags %}
+
+{% assign term_list = glossary_terms | where_exp:"term", "term.tags contains tag" | map: "id" %}
+
+{% assign tag_obj = "" | split: " " | push: tag | push: term_list %}
+
+{% assign tag_map = tag_map | push: tag_obj %}
+
+{% endfor %}

_includes/templates/glossary/README.md

@@ -0,0 +1,62 @@
+# Kubernetes Glossary
+
+To write a glossary snippet, start with a copy of the template, [`/_data/glossary/_example.yml`](/_data/glossary/_example.yml). Make sure to provide (or omit) values for the following fields:
+
+* (Required) `id`.
+  * This field must match the name of the glossary file itself (without the `*.yml` extension). It is *not* intended to be displayed to users, and is only used programmatically.
+* (Required) `name`.
+  * The name of the term.
+* (Required) `tags`.
+  * Must be one of the tags listed in kubernetes.github.io/_data/canonical-terms-tags.yml.
+* (Required) `short description`.
+  * Make sure to replace the instructional text in the template with your content.
+* (Optional) `formerly` and `related`.
+  * If you do not provide these values, remove the fields.
+* (Optional) `long description`.
+  * If you do not provide a long description, remove the field -- that is, the complete key-value pair.
+
+The `_example.yml` template also contains basic information about how to write your snippet. For additional guidance, continue reading this readme.
+
+## Glossary snippet style guide
+
+This style guide supplements the guidance provided in the glossary template. It's intended to help you think about what and how to write glossary definitions. For more general guidance on style, consult [the core docs style guide](https://kubernetes.io/docs/home/contribute/style-guide/).
+
+### Minimum viable snippet:
+
+Every snippet must include at least the short description. The long description is optional, but should be provided for terms that need additional clarification. For consistency with existing *Concept* definitions, *write your definitions as if the term is plural*.
+
+**short-description** (Required): One line (or two short lines) that provides a minimum definition. Do not repeat the term. Prefer fragments. Model after tooltips. End with a period.
+
+**long-description** (Optional): Longer additional text to appear after (in conjunction with) short description. Provide in cases where the short description is not sufficient for the intro paragraph to a topic. Write complete but concise sentences.
+
+### Examples
+
+```yaml
+- name: Pod
+- tags:
+  - Fundamental
+  - Workload
+  - API Object
+- short-description: The smallest and simplest Kubernetes objects. Represent a set of running processes on your cluster.
+- long-description: Pods most often run only a single container, and are managed by a Deployment.
+```
+
+```yaml
+- name: Deployment
+- tags:
+  - Fundamental
+  - Workload
+  - API Object
+- short-description: Controllers that provide declarative updates for Pods and ReplicaSets.
+- long-description: Deployments are responsible for creating and updating instances of an application.
+```
+
+### Thinking about definitions
+
+* **Think of the short description as it would appear in a tooltip.** Is it sufficient to get the reader started? Is it short enough to be read inside a small UI element?
+
+  *Tip*: look at the API reference doc content (for example, https://kubernetes.io/docs/api-reference/v1.7/). Note, however, that this content should be used with care. The concept docs for Pod, for example, are clearer than the reference docs.
+
+* **The long description should follow the short description to make a complete introduction to a topic.** (This is the content that appears at the top of the content, before any generated TOC.) Does it provide information that's not already clear from the short description? Does it provide information that readers should have a general sense of before they dive into the details of the topic it helps introduce?
+
+  *Tip:* the long description does not need to be long; it's intended to extend but not replace the short description. Look through current related docs for ideas. (The Deployment long description is taken from a tutorial, for example.)

_includes/templates/glossary/_error.md

@@ -0,0 +1,10 @@
+### ERROR: You must define a <span style="font-family: monospace">`{{ include.missing_block }}`</span> field
+{: style="color:red" }
+
+The glossary template requires that you provide text that {{ include.purpose }}.
+
+To get rid of this message and take advantage of this template, define the `{{ include.missing_block }}`
+field for the `{{ include.term }}` glossary term and populate it with content.
+
+See `_data/glossary/_example.yml` for reference.
+<!-- TEMPLATE_ERROR -->

_includes/templates/glossary/snippet.md

@@ -0,0 +1,25 @@
+{% assign term_data = site.data.glossary.[include.term] %}
+
+{% if term_data.short-description %}
+
+{{ term_data.short-description | markdownify }}
+
+{% else %}
+
+{% include templates/glossary/_error.md term=term_data.name missing_block='short-description' purpose='concisely describes the key term in 1-2 lines' %}
+
+{% endif %}
+
+{% if include.length == "long" %}
+
+{% if term_data.long-description %}
+
+{{ term_data.long-description | markdownify }}
+
+{% else %}
+
+{% include templates/glossary/_error.md term=term_data.name missing_block='long-description' purpose='describes the key term in greater depth, supplementing the short-description' %}
+
+{% endif %}
+
+{% endif %}

_layouts/docwithnav.html

@@ -35,6 +35,8 @@
   </div>
 </section>
 
+{% include deprecation-warning.html %}
+
 <section id="encyclopedia">
   <div id="docsToc">
         <div class="pi-accordion">

_redirects

@@ -1,242 +1,450 @@
-#
-# set server-side redirects in this file
-# see https://www.netlify.com/docs/redirects/
+###############################################
+# set server-side redirects in this file      #
+# see https://www.netlify.com/docs/redirects/ #
+# test at https://play.netlify.com/redirects  #
+###############################################
+
+############################
+# pattern matching redirects
 #
 
-/docs/admin/addons												/docs/concepts/cluster-administration/addons		301
-/docs/admin/apparmor/											/docs/tutorials/clusters/apparmor		301
-/docs/admin/audit												/docs/tasks/debug-application-cluster/audit		301
-/docs/admin/cluster-components									/docs/concepts/overview/components		301
-/docs/admin/cluster-management									/docs/tasks/administer-cluster/cluster-management		301
-/docs/admin/cluster-troubleshooting								/docs/tasks/debug-application-cluster/debug-cluster		301
-/docs/admin/daemons												/docs/concepts/workloads/controllers/daemonset		301
-/docs/admin/disruptions											/docs/concepts/workloads/pods/disruptions		301
-/docs/admin/dns													/docs/concepts/services-networking/dns-pod-service		301
-/docs/admin/etcd												/docs/tasks/administer-cluster/configure-upgrade-etcd		301
-/docs/admin/etcd_upgrade										/docs/tasks/administer-cluster/configure-upgrade-etcd		301
-/docs/admin/federation/kubefed									/docs/tasks/federation/set-up-cluster-federation-kubefed		301
-/docs/admin/garbage-collection									/docs/concepts/cluster-administration/kubelet-garbage-collection		301
-/docs/admin/ha-master-gce										/docs/tasks/administer-cluster/highly-available-master		301
-/docs/admin/													/docs/concepts/cluster-administration/cluster-administration-overview		301
-/docs/admin/kubeadm-upgrade-1-7									/docs/tasks/administer-cluster/kubeadm-upgrade-1-7		301
-/docs/admin/limitrange/											/docs/tasks/administer-cluster/cpu-memory-limit		301
-/docs/admin/master-node-communication							/docs/concepts/architecture/master-node-communication		301
-/docs/admin/multi-cluster										/docs/concepts/cluster-administration/federation		301
-/docs/admin/multiple-schedulers									/docs/tasks/administer-cluster/configure-multiple-schedulers		301
-/docs/admin/namespaces/											/docs/tasks/administer-cluster/namespaces		301
-/docs/admin/namespaces/walkthrough								/docs/tasks/administer-cluster/namespaces-walkthrough		301
-/docs/admin/network-plugins										/docs/concepts/cluster-administration/network-plugins		301
-/docs/admin/networking											/docs/concepts/cluster-administration/networking		301
-/docs/admin/node												/docs/concepts/architecture/nodes		301
-/docs/admin/node-allocatable									/docs/tasks/administer-cluster/reserve-compute-resources		301
-/docs/admin/node-problem										/docs/tasks/debug-application-cluster/monitor-node-health		301
-/docs/admin/out-of-resource										/docs/tasks/administer-cluster/out-of-resource		301
-/docs/admin/rescheduler											/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods		301
-/docs/admin/resourcequota/										/docs/concepts/policy/resource-quotas		301
-/docs/admin/resourcequota/limitstorageconsumption				/docs/tasks/administer-cluster/limit-storage-consumption		301
-/docs/admin/resourcequota/walkthrough							/docs/tasks/administer-cluster/apply-resource-quota-limit		301
-/docs/admin/static-pods											/docs/tasks/administer-cluster/static-pod		301
-/docs/admin/sysctls												/docs/concepts/cluster-administration/sysctl-cluster		301
-/docs/admin/upgrade-1-6											/docs/tasks/administer-cluster/upgrade-1-6		301
-
-/docs/api														/docs/concepts/overview/kubernetes-api		301
-
-/docs/concepts/abstractions/controllers/garbage-collection		/docs/concepts/workloads/controllers/garbage-collection		301
-/docs/concepts/abstractions/controllers/petsets					/docs/concepts/workloads/controllers/petset		301
-/docs/concepts/abstractions/controllers/statefulsets			/docs/concepts/workloads/controllers/statefulset		301
-/docs/concepts/abstractions/init-containers						/docs/concepts/workloads/pods/init-containers		301
-/docs/concepts/abstractions/overview							/docs/concepts/overview/working-with-objects/kubernetes-objects		301
-/docs/concepts/abstractions/pod									/docs/concepts/workloads/pods/pod-overview		301
-
-/docs/concepts/cluster-administration/access-cluster			/docs/tasks/access-application-cluster/access-cluster		301
-/docs/concepts/cluster-administration/audit						/docs/tasks/debug-application-cluster/audit		301
-/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig	/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig		301
-/docs/concepts/cluster-administration/cluster-management		/docs/tasks/administer-cluster/cluster-management		301
-/docs/concepts/cluster-administration/configure-etcd			/docs/tasks/administer-cluster/configure-upgrade-etcd		301
-/docs/concepts/cluster-administration/etcd-upgrade				/docs/tasks/administer-cluster/configure-upgrade-etcd		301
-/docs/concepts/cluster-administration/federation-service-discovery	/docs/tasks/federation/federation-service-discovery		301
-/docs/concepts/cluster-administration/guaranteed-scheduling-critical-addon-pods	/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods		301
-/docs/concepts/cluster-administration/master-node-communication	/docs/concepts/architecture/master-node-communication		301
-/docs/concepts/cluster-administration/multiple-clusters			/docs/concepts/cluster-administration/federation		301
-/docs/concepts/cluster-administration/out-of-resource			/docs/tasks/administer-cluster/out-of-resource		301
-/docs/concepts/cluster-administration/resource-usage-monitoring	/docs/tasks/debug-application-cluster/resource-usage-monitoring		301
-/docs/concepts/cluster-administration/static-pod				/docs/tasks/administer-cluster/static-pod		301
-
-/docs/concepts/clusters/logging									/docs/concepts/cluster-administration/logging		301
-/docs/concepts/configuration/container-command-arg				/docs/tasks/inject-data-application/define-command-argument-container/docs/concepts/ecosystem/thirdpartyresource		301						/docs/tasks/access-kubernetes-api/extend-api-third-party-resource
-/docs/concepts/jobs/cron-jobs									/docs/concepts/workloads/controllers/cron-jobs		301
-/docs/concepts/jobs/run-to-completion-finite-workloads			/docs/concepts/workloads/controllers/jobs-run-to-completion		301
-/docs/concepts/nodes/node										/docs/concepts/architecture/nodes		301
-/docs/concepts/storage/etcd-store-api-object					/docs/tasks/administer-cluster/configure-upgrade-etcd		301
-
-/docs/concepts/tools/kubectl/object-management-overview			/docs/tutorials/object-management-kubectl/object-management		301
-/docs/concepts/tools/kubectl/object-management-using-declarative-config	/docs/tutorials/object-management-kubectl/declarative-object-management-configuration		301
-/docs/concepts/tools/kubectl/object-management-using-imperative-commands	/docs/tutorials/object-management-kubectl/imperative-object-management-command		301
-/docs/concepts/tools/kubectl/object-management-using-imperative-config	/docs/tutorials/object-management-kubectl/imperative-object-management-configuration		301
-
-/docs/getting-started-guides/									/docs/setup/pick-right-solution		301
-/docs/getting-started-guides/kubeadm							/docs/setup/independent/create-cluster-kubeadm		301
-/docs/getting-started-guides/network-policy/calico				/docs/tasks/administer-cluster/calico-network-policy		301
-/docs/getting-started-guides/network-policy/romana				/docs/tasks/administer-cluster/romana-network-policy		301
-/docs/getting-started-guides/network-policy/walkthrough			/docs/tasks/administer-cluster/declare-network-policy		301
-/docs/getting-started-guides/network-policy/weave				/docs/tasks/administer-cluster/weave-network-policy		301
-/docs/getting-started-guides/running-cloud-controller			/docs/tasks/administer-cluster/running-cloud-controller		301
-/docs/getting-started-guides/ubuntu/calico						/docs/getting-started-guides/ubuntu/		301
-
-/docs/hellonode													/docs/tutorials/stateless-application/hello-minikube		301
-/docs/															/docs/home/		301
-/docs/samples													/docs/tutorials/		301
-/docs/tasks/administer-cluster/assign-pods-nodes				/docs/tasks/configure-pod-container/assign-pods-nodes		301
-/docs/tasks/administer-cluster/overview							/docs/concepts/cluster-administration/cluster-administration-overview		301
-
-/docs/tasks/configure-pod-container/apply-resource-quota-limit	/docs/tasks/administer-cluster/apply-resource-quota-limit		301
-/docs/tasks/configure-pod-container/calico-network-policy		/docs/tasks/administer-cluster/calico-network-policy		301
-/docs/tasks/configure-pod-container/communicate-containers-same-pod	/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume		301
-/docs/tasks/configure-pod-container/declare-network-policy		/docs/tasks/administer-cluster/declare-network-policy		301
-/docs/tasks/configure-pod-container/define-environment-variable-container	/docs/tasks/inject-data-application/define-environment-variable-container		301
-/docs/tasks/configure-pod-container/distribute-credentials-secure	/docs/tasks/inject-data-application/distribute-credentials-secure		301
-/docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information	/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information		301
-/docs/tasks/configure-pod-container/environment-variable-expose-pod-information	/docs/tasks/inject-data-application/environment-variable-expose-pod-information		301
-/docs/tasks/configure-pod-container/limit-range					/docs/tasks/administer-cluster/cpu-memory-limit		301
-/docs/tasks/configure-pod-container/romana-network-policy		/docs/tasks/administer-cluster/romana-network-policy		301
-/docs/tasks/configure-pod-container/weave-network-policy		/docs/tasks/administer-cluster/weave-network-policy		301
-
-/docs/tasks/kubectl/get-shell-running-container					/docs/tasks/debug-application-cluster/get-shell-running-container		301
-/docs/tasks/kubectl/install										/docs/tasks/tools/install-kubectl		301
-/docs/tasks/kubectl/list-all-running-container-images			/docs/tasks/access-application-cluster/list-all-running-container-images		301
-
-/docs/tasks/manage-stateful-set/debugging-a-statefulset			/docs/tasks/debug-application-cluster/debug-stateful-set		301
-/docs/tasks/manage-stateful-set/deleting-a-statefulset			/docs/tasks/run-application/delete-stateful-set		301
-/docs/tasks/manage-stateful-set/scale-stateful-set				/docs/tasks/run-application/scale-stateful-set		301
-/docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set	/docs/tasks/run-application/upgrade-pet-set-to-stateful-set		301
-
-/docs/tasks/run-application/podpreset							/docs/tasks/inject-data-application/podpreset		301
-/docs/tasks/troubleshoot/debug-init-containers					/docs/tasks/debug-application-cluster/debug-init-containers		301
-/docs/tasks/web-ui-dashboard									/docs/tasks/access-application-cluster/web-ui-dashboard		301
-/docs/templatedemos												/docs/home/contribute/page-templates		301
-/docs/tools/kompose/											/docs/tools/kompose/user-guide		301
-
-/docs/tutorials/clusters/multiple-schedulers					/docs/tasks/administer-cluster/configure-multiple-schedulers		301
-/docs/tutorials/connecting-apps/connecting-frontend-backend		/docs/tasks/access-application-cluster/connecting-frontend-backend		301
-/docs/tutorials/federation/set-up-cluster-federation-kubefed	/docs/tasks/federation/set-up-cluster-federation-kubefed		301
-/docs/tutorials/federation/set-up-coredns-provider-federation	/docs/tasks/federation/set-up-coredns-provider-federation		301
-/docs/tutorials/federation/set-up-placement-policies-federation	/docs/tasks/federation/set-up-placement-policies-federation		301
-/docs/tutorials/getting-started/create-cluster					/docs/tutorials/kubernetes-basics/cluster-intro		301
-/docs/tutorials/stateful-application/run-replicated-stateful-application	/docs/tasks/run-application/run-replicated-stateful-application		301
-/docs/tutorials/stateful-application/run-stateful-application	/docs/tasks/run-application/run-single-instance-stateful-application		301
-/docs/tutorials/stateless-application/expose-external-ip-address-service	/docs/tasks/access-application-cluster/service-access-application-cluster		301
-/docs/tutorials/stateless-application/run-stateless-ap-replication-controller	/docs/tasks/run-application/run-stateless-application-deployment		301
-/docs/tutorials/stateless-application/run-stateless-application-deployment	/docs/tasks/run-application/run-stateless-application-deployment		301
-
-/docs/user-guide/accessing-the-cluster							/docs/tasks/access-application-cluster/access-cluster		301
-/docs/user-guide/add-entries-to-pod-etc-hosts-with-host-aliases/	/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases		301
-/docs/user-guide/annotations									/docs/concepts/overview/working-with-objects/annotations		301
-/docs/user-guide/application-troubleshooting					/docs/tasks/debug-application-cluster/debug-application		301
-/docs/user-guide/compute-resources								/docs/concepts/configuration/manage-compute-resources-container		301
-/docs/user-guide/config-best-practices							/docs/concepts/configuration/overview		301
-/docs/user-guide/configmap/										/docs/tasks/configure-pod-container/configmap		301
-/docs/user-guide/configuring-containers							/docs/tasks/		301
-/docs/user-guide/connecting-applications						/docs/concepts/services-networking/connect-applications-service		301
-/docs/user-guide/connecting-to-applications-port-forward		/docs/tasks/access-application-cluster/port-forward-access-application-cluster		301
-/docs/user-guide/connecting-to-applications-proxy				/docs/tasks/access-kubernetes-api/http-proxy-access-api		301
-/docs/user-guide/container-environment							/docs/concepts/containers/container-lifecycle-hooks		301
-/docs/user-guide/cron-jobs										/docs/concepts/workloads/controllers/cron-jobs		301
-/docs/user-guide/debugging-pods-and-replication-controllers		/docs/tasks/debug-application-cluster/debug-pod-replication-controller		301
-/docs/user-guide/debugging-services								/docs/tasks/debug-application-cluster/debug-service		301
-/docs/user-guide/deploying-applications							/docs/tasks/run-application/run-stateless-application-deployment		301
-/docs/user-guide/deployments									/docs/concepts/workloads/controllers/deployment		301
-/docs/user-guide/downward-api/									/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information		301
-/docs/user-guide/downward-api/volume/							/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information		301
-/docs/user-guide/environment-guide/								/docs/tasks/inject-data-application/environment-variable-expose-pod-information		301
-/docs/user-guide/federation/cluster								/docs/tasks/administer-federation/cluster		301
-/docs/user-guide/federation/configmap							/docs/tasks/administer-federation/configmap		301
-/docs/user-guide/federation/daemonsets							/docs/tasks/administer-federation/daemonset		301
-/docs/user-guide/federation/deployment							/docs/tasks/administer-federation/deployment		301
-/docs/user-guide/federation/events								/docs/tasks/administer-federation/events		301
-/docs/user-guide/federation/federated-ingress					/docs/tasks/administer-federation/ingress		301
-/docs/user-guide/federation/federated-services					/docs/tasks/federation/federation-service-discovery		301
-/docs/user-guide/federation/									/docs/concepts/cluster-administration/federation		301
-/docs/user-guide/federation/namespaces							/docs/tasks/administer-federation/namespaces		301
-/docs/user-guide/federation/replicasets							/docs/tasks/administer-federation/replicaset		301
-/docs/user-guide/federation/secrets								/docs/tasks/administer-federation/secret		301
-/docs/user-guide/garbage-collection								/docs/concepts/workloads/controllers/garbage-collection		301
-/docs/user-guide/getting-into-containers						/docs/tasks/debug-application-cluster/get-shell-running-container		301
-/docs/user-guide/gpus											/docs/tasks/manage-gpus/scheduling-gpus		301
-/docs/user-guide/horizontal-pod-autoscaling/					/docs/tasks/run-application/horizontal-pod-autoscale		301
-/docs/user-guide/horizontal-pod-autoscaling/walkthrough			/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough		301
-/docs/user-guide/identifiers									/docs/concepts/overview/working-with-objects/names		301
-/docs/user-guide/images											/docs/concepts/containers/images		301
-/docs/user-guide/												/docs/home/		301
-/docs/user-guide/ingress										/docs/concepts/services-networking/ingress		301
-/docs/user-guide/introspection-and-debugging					/docs/tasks/debug-application-cluster/debug-application-introspection		301
-/docs/user-guide/jobs											/docs/concepts/workloads/controllers/jobs-run-to-completion		301
-/docs/user-guide/jobs/expansions/								/docs/tasks/job/parallel-processing-expansion		301
-/docs/user-guide/jobs/work-queue-1/								/docs/tasks/job/coarse-parallel-processing-work-queue/		301
-/docs/user-guide/jobs/work-queue-2/								/docs/tasks/job/fine-parallel-processing-work-queue/		301
-/docs/user-guide/kubeconfig-file								/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig		301
-/docs/user-guide/labels											/docs/concepts/overview/working-with-objects/labels		301
-/docs/user-guide/liveness										/docs/tasks/configure-pod-container/configure-liveness-readiness-probes		301
-/docs/user-guide/load-balancer									/docs/tasks/access-application-cluster/create-external-load-balancer		301
-/docs/user-guide/logging/elasticsearch							/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana		301
-/docs/user-guide/logging/overview								/docs/concepts/cluster-administration/logging		301
-/docs/user-guide/logging/stackdriver							/docs/tasks/debug-application-cluster/logging-stackdriver		301
-/docs/user-guide/managing-deployments							/docs/concepts/cluster-administration/manage-deployment		301
-/docs/user-guide/monitoring										/docs/tasks/debug-application-cluster/resource-usage-monitoring		301
-/docs/user-guide/namespaces										/docs/concepts/overview/working-with-objects/namespaces		301
-/docs/user-guide/networkpolicies								/docs/concepts/services-networking/network-policies		301
-/docs/user-guide/node-selection/								/docs/concepts/configuration/assign-pod-node		301
-/docs/user-guide/persistent-volumes/							/docs/concepts/storage/persistent-volumes		301
-/docs/user-guide/persistent-volumes/walkthrough					/docs/tasks/configure-pod-container/configure-persistent-volume-storage		301
-/docs/user-guide/petset											/docs/concepts/workloads/controllers/petset		301
-/docs/user-guide/petset/bootstrapping/							/docs/concepts/workloads/controllers/petset		301
-/docs/user-guide/pod-preset/									/docs/tasks/inject-data-application/podpreset		301
-/docs/user-guide/pod-security-policy/							/docs/concepts/policy/pod-security-policy		301
-/docs/user-guide/pod-states										/docs/concepts/workloads/pods/pod-lifecycle		301
-/docs/user-guide/pod-templates									/docs/concepts/workloads/pods/pod-overview		301
-/docs/user-guide/pods/											/docs/concepts/workloads/pods/pod		301
-/docs/user-guide/pods/init-container							/docs/concepts/workloads/pods/init-containers		301
-/docs/user-guide/pods/multi-container							/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume		301
-/docs/user-guide/pods/single-container							/docs/tasks/run-application/run-stateless-application-deployment		301
-/docs/user-guide/prereqs										/docs/tasks/tools/install-kubectl		301
-/docs/user-guide/production-pods								/docs/tasks/		301
-/docs/user-guide/projected-volume/								/docs/tasks/configure-pod-container/configure-projected-volume-storage		301
-/docs/user-guide/quick-start									/docs/tasks/access-application-cluster/service-access-application-cluster		301
-/docs/user-guide/replicasets									/docs/concepts/workloads/controllers/replicaset		301
-/docs/user-guide/replication-controller/						/docs/concepts/workloads/controllers/replicationcontroller		301
-/docs/user-guide/rolling-updates								/docs/tasks/run-application/rolling-update-replication-controller		301
-/docs/user-guide/secrets/										/docs/concepts/configuration/secret		301
-/docs/user-guide/secrets/walkthrough							/docs/tasks/inject-data-application/distribute-credentials-secure		301
-/docs/user-guide/service-accounts								/docs/tasks/configure-pod-container/configure-service-account		301
-/docs/user-guide/services-firewalls								/docs/tasks/access-application-cluster/configure-cloud-provider-firewall		301
-/docs/user-guide/services/										/docs/concepts/services-networking/service		301
-/docs/user-guide/services/operations							/docs/tasks/access-application-cluster/connecting-frontend-backend		301
-/docs/user-guide/sharing-clusters								/docs/tasks/administer-cluster/share-configuration		301
-/docs/user-guide/simple-nginx									/docs/tasks/run-application/run-stateless-application-deployment		301
-/docs/user-guide/thirdpartyresources							/docs/tasks/access-kubernetes-api/extend-api-third-party-resource		301
-/docs/user-guide/ui												/docs/tasks/access-application-cluster/web-ui-dashboard		301
-/docs/user-guide/update-demo/									/docs/tasks/run-application/rolling-update-replication-controller		301
-/docs/user-guide/volumes										/docs/concepts/storage/volumes		301
-/docs/user-guide/working-with-resources							/docs/tutorials/object-management-kubectl/object-management		301
-
-/docs/whatisk8s													/docs/concepts/overview/what-is-kubernetes		301
+/docs/user-guide/kubectl/kubectl_*/     /docs/user-guide/kubectl/v1.7/#:splat 200
+/v1.1/docs/*     /docs/ 301
+/docs/user-guide/kubectl/1_5/*     https://v1-5.docs.kubernetes.io/docs/user-guide/kubectl/v1.5/ 301
+/docs/user-guide/kubectl/v1.5/node_modules/*     https://v1-5.docs.kubernetes.io/docs/user-guide/kubectl/v1.5/ 301
+/docs/resources-reference/1_5/*     https://v1-5.docs.kubernetes.io/docs/resources-reference/v1.5/ 301
+/docs/resources-reference/v1.5/node_modules/*     https://v1-5.docs.kubernetes.io/docs/resources-reference/v1.5/ 301
+/docs/user-guide/kubectl/v1.6/node_modules/*     https://v1-6.docs.kubernetes.io/docs/user-guide/kubectl/v1.6/ 301
+/docs/api-reference/v1.7/node_modules/*     /docs/api-reference/v1.7/ 301
+/docs/getting-started-guides/docker-multinode/*     /docs/setup/independent/create-cluster-kubeadm/ 301
+/docs/admin/resourcequota/*     /docs/concepts/policy/resource-quotas/ 301
+/docs/getting-started-guide/*     /docs/setup/ 301
+/docs/api-reference/v1.4/*     https://v1-4.docs.kubernetes.io/docs/reference/ 301
+/docs/api-reference/1_5/*     https://v1-5.docs.kubernetes.io/docs/reference/ 301
+/docs/api-reference/v1.5/*     https://v1-5.docs.kubernetes.io/docs/reference/ 301
+/docs/api-reference/v1.6/*     https://v1-6.docs.kubernetes.io/docs/reference/ 301
+/docs/resources-reference/1_5/*     /docs/resources-reference/v1.5/ 301
+/docs/resources-reference/1_6/*     /docs/resources-reference/v1.6/ 301
+/docs/resources-reference/1_7/*     /docs/resources-reference/v1.7/ 301
+/docs/templatedemos/*     /docs/home/contribute/page-templates/ 301
+/docs/tutorials/getting-started/*     /docs/tutorials/kubernetes-basics/ 301
+/docs/user-guide/federation/*     /docs/concepts/cluster-administration/federation/ 301
+/docs/user-guide/garbage-collector/*     /docs/concepts/workloads/controllers/garbage-collection/ 301
+/docs/user-guide/horizontal-pod-autoscaler/*     /docs/tasks/run-application/horizontal-pod-autoscale/ 301
+/kubernetes-bootcamp/*     /docs/tutorials/kubernetes-basics/ 301
+/swagger-spec/*     https://github.com/kubernetes/kubernetes/tree/master/api/swagger-spec/ 301
+/third_party/swagger-ui/*     /docs/reference/ 301
 
+############################
+# individual redirects
 #
+
+/gettingstarted/     /docs/home/ 301
+
+/docs/admin/addons/     /docs/concepts/cluster-administration/addons/ 301
+/docs/admin/apparmor/     /docs/tutorials/clusters/apparmor/ 301
+/docs/admin/audit/     /docs/tasks/debug-application-cluster/audit/ 301
+//docs/admin/authorization/rbac.md     /docs/admin/authorization/rbac/ 301
+/docs/admin/cluster-components/     /docs/concepts/overview/components/ 301
+/docs/admin/cluster-management/     /docs/tasks/administer-cluster/cluster-management/ 301
+/docs/admin/cluster-troubleshooting/     /docs/tasks/debug-application-cluster/debug-cluster/ 301
+/docs/admin/daemons/     /docs/concepts/workloads/controllers/daemonset/ 301
+/docs/admin/disruptions/     /docs/concepts/workloads/pods/disruptions/ 301
+/docs/admin/dns/     /docs/concepts/services-networking/dns-pod-service/ 301
+/docs/admin/etcd/     /docs/tasks/administer-cluster/configure-upgrade-etcd/ 301
+/docs/admin/etcd_upgrade/     /docs/tasks/administer-cluster/configure-upgrade-etcd/ 301
+/docs/admin/federation/kubefed/     /docs/tasks/federation/set-up-cluster-federation-kubefed/ 301
+/docs/admin/federation/kubefed.md     /docs/tasks/federation/set-up-cluster-federation-kubefed/ 301
+/docs/tasks/federation/set-up-cluster-federation-kubefed.md     /docs/tasks/federation/set-up-cluster-federation-kubefed/ 301
+/docs/admin/garbage-collection/     /docs/concepts/cluster-administration/kubelet-garbage-collection/ 301
+/docs/admin/ha-master-gce/     /docs/tasks/administer-cluster/highly-available-master/ 301
+/docs/admin/ha-master-gce.md     /docs/tasks/administer-cluster/highly-available-master/ 301
+/docs/admin/     /docs/concepts/cluster-administration/cluster-administration-overview/ 301
+/docs/admin/kubeadm-upgrade-1-7/     /docs/tasks/administer-cluster/kubeadm-upgrade-1-7/ 301
+/docs/admin/limitrange/docs/tasks/administer-cluster/cpu-memory-limit/ 301
+/docs/admin/master-node-communication/     /docs/concepts/architecture/master-node-communication/ 301
+/docs/admin/multi-cluster/     /docs/concepts/cluster-administration/federation/ 301
+/docs/admin/multiple-schedulers/     /docs/tasks/administer-cluster/configure-multiple-schedulers/ 301
+/docs/admin/namespaces/     /docs/tasks/administer-cluster/namespaces/ 301
+/docs/admin/namespaces/walkthrough/     /docs/tasks/administer-cluster/namespaces-walkthrough/ 301
+/docs/admin/network-plugins/     /docs/concepts/cluster-administration/network-plugins/ 301
+/docs/admin/networking/     /docs/concepts/cluster-administration/networking/ 301
+/docs/admin/node/     /docs/concepts/architecture/nodes/ 301
+/docs/admin/node-allocatable/     /docs/tasks/administer-cluster/reserve-compute-resources/ 301
+//docs/admin/node-allocatable.md     /docs/tasks/administer-cluster/reserve-compute-resources/ 301
+/docs/admin/node-conformance.md     /docs/admin/node-conformance/ 301
+/docs/admin/node-problem/     /docs/tasks/debug-application-cluster/monitor-node-health/ 301
+/docs/admin/out-of-resource/     /docs/tasks/administer-cluster/out-of-resource/ 301
+/docs/admin/rescheduler/     /docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/ 301
+/docs/admin/resourcequota/limitstorageconsumption/     /docs/tasks/administer-cluster/limit-storage-consumption/ 301
+/docs/admin/resourcequota/walkthrough/     /docs/tasks/administer-cluster/quota-api-object/ 301
+/docs/admin/static-pods/     /docs/tasks/administer-cluster/static-pod/ 301
+/docs/admin/sysctls/     /docs/concepts/cluster-administration/sysctl-cluster/ 301
+/docs/admin/upgrade-1-6/     /docs/tasks/administer-cluster/upgrade-1-6/ 301
+
+/docs/api/     /docs/concepts/overview/kubernetes-api/ 301
+
+/docs/concepts/abstractions/controllers/garbage-collection/     /docs/concepts/workloads/controllers/garbage-collection/ 301
+/docs/concepts/abstractions/controllers/petsets/     /docs/concepts/workloads/controllers/petset/ 301
+/docs/concepts/abstractions/controllers/statefulsets/     /docs/concepts/workloads/controllers/statefulset/ 301
+/docs/concepts/abstractions/init-containers/     /docs/concepts/workloads/pods/init-containers/ 301
+/docs/concepts/abstractions/overview/     /docs/concepts/overview/working-with-objects/kubernetes-objects/ 301
+/docs/concepts/abstractions/pod/     /docs/concepts/workloads/pods/pod-overview/ 301
+
+/docs/concepts/cluster-administration/access-cluster/     /docs/tasks/access-application-cluster/access-cluster/ 301
+/docs/concepts/cluster-administration/audit/     /docs/tasks/debug-application-cluster/audit/ 301
+/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/     /docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/ 301
+/docs/concepts/cluster-administration/cluster-management/     /docs/tasks/administer-cluster/cluster-management/ 301
+/docs/concepts/cluster-administration/configure-etcd/     /docs/tasks/administer-cluster/configure-upgrade-etcd/ 301
+/docs/concepts/cluster-administration/etcd-upgrade/     /docs/tasks/administer-cluster/configure-upgrade-etcd/ 301
+/docs/concepts/cluster-administration/federation-service-discovery/     /docs/tasks/federation/federation-service-discovery/ 301
+/docs/concepts/cluster-administration/guaranteed-scheduling-critical-addon-pods/     /docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/ 301
+/docs/concepts/cluster-administration/master-node-communication/     /docs/concepts/architecture/master-node-communication/ 301
+/docs/concepts/cluster-administration/multiple-clusters/     /docs/concepts/cluster-administration/federation/ 301
+/docs/concepts/cluster-administration/out-of-resource/     /docs/tasks/administer-cluster/out-of-resource/ 301
+/docs/concepts/cluster-administration/resource-usage-monitoring/     /docs/tasks/debug-application-cluster/resource-usage-monitoring/ 301
+/docs/concepts/cluster-administration/static-pod/     /docs/tasks/administer-cluster/static-pod/ 301
+/docs/concepts/clusters/logging/     /docs/concepts/cluster-administration/logging/ 301
+/docs/concepts/configuration/container-command-arg/     /docs/tasks/inject-data-application/define-command-argument-container/ 301
+/docs/concepts/ecosystem/thirdpartyresource/     /docs/tasks/access-kubernetes-api/extend-api-third-party-resource/ 301
+/docs/concepts/jobs/cron-jobs/     /docs/concepts/workloads/controllers/cron-jobs/ 301
+/docs/concepts/jobs/run-to-completion-finite-workloads/     /docs/concepts/workloads/controllers/jobs-run-to-completion/ 301
+/docs/concepts/nodes/node/     /docs/concepts/architecture/nodes/ 301
+/docs/concepts/storage/etcd-store-api-object/     /docs/tasks/administer-cluster/configure-upgrade-etcd/ 301
+/docs/concepts/tools/kubectl/object-management-overview/     /docs/tutorials/object-management-kubectl/object-management/ 301
+/docs/concepts/tools/kubectl/object-management-using-declarative-config/     /docs/tutorials/object-management-kubectl/declarative-object-management-configuration/ 301
+/docs/concepts/tools/kubectl/object-management-using-imperative-commands/     /docs/tutorials/object-management-kubectl/imperative-object-management-command/ 301
+/docs/concepts/tools/kubectl/object-management-using-imperative-config/     /docs/tutorials/object-management-kubectl/imperative-object-management-configuration/ 301
+
+/docs/getting-started-guides/     /docs/setup/pick-right-solution/ 301
+/docs/getting-started-guides/kubeadm/     /docs/setup/independent/create-cluster-kubeadm/ 301
+/docs/getting-started-guides/network-policy/calico/     /docs/tasks/administer-cluster/calico-network-policy/ 301
+/docs/getting-started-guides/network-policy/romana/     /docs/tasks/administer-cluster/romana-network-policy/ 301
+/docs/getting-started-guides/network-policy/walkthrough/     /docs/tasks/administer-cluster/declare-network-policy/ 301
+/docs/getting-started-guides/network-policy/weave/     /docs/tasks/administer-cluster/weave-network-policy/ 301
+/docs/getting-started-guides/running-cloud-controller/     /docs/tasks/administer-cluster/running-cloud-controller/ 301
+/docs/getting-started-guides/ubuntu/calico/     /docs/getting-started-guides/ubuntu/ 301
+
+/docs/hellonode/     /docs/tutorials/stateless-application/hello-minikube/ 301
+/docs/     /docs/home/ 301
+/docs/home/coreos/     /docs/getting-started-guides/coreos/ 301
+/docs/samples/     /docs/tutorials/ 301
+
+/docs/tasks/administer-cluster/apply-resource-quota-limit/     /docs/tasks/administer-cluster/quota-api-object/ 301
+/docs/tasks/administer-cluster/assign-pods-nodes/     /docs/tasks/configure-pod-container/assign-pods-nodes/ 301
+/docs/tasks/administer-cluster/overview/     /docs/concepts/cluster-administration/cluster-administration-overview/ 301
+/docs/tasks/administer-cluster/cpu-memory-limit/     /docs/tasks/administer-cluster/memory-default-namespace/ 301
+/docs/tasks/administer-cluster/share-configuration/     /docs/tasks/access-application-cluster/configure-access-multiple-clusters/ 301
+
+/docs/tasks/configure-pod-container/apply-resource-quota-limit/     /docs/tasks/administer-cluster/apply-resource-quota-limit/ 301
+/docs/tasks/configure-pod-container/calico-network-policy/     /docs/tasks/administer-cluster/calico-network-policy/ 301
+/docs/tasks/configure-pod-container/communicate-containers-same-pod/     /docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/ 301
+/docs/tasks/configure-pod-container/declare-network-policy/     /docs/tasks/administer-cluster/declare-network-policy/ 301
+/docs/tasks/configure-pod-container/define-environment-variable-container/     /docs/tasks/inject-data-application/define-environment-variable-container/ 301
+/docs/tasks/configure-pod-container/distribute-credentials-secure/     /docs/tasks/inject-data-application/distribute-credentials-secure/ 301
+/docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information/     /docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/ 301
+/docs/tasks/configure-pod-container/environment-variable-expose-pod-information/     /docs/tasks/inject-data-application/environment-variable-expose-pod-information/ 301
+/docs/tasks/configure-pod-container/limit-range/     /docs/tasks/administer-cluster/cpu-memory-limit/ 301
+/docs/tasks/configure-pod-container/romana-network-policy/     /docs/tasks/administer-cluster/romana-network-policy/ 301
+/docs/tasks/configure-pod-container/weave-network-policy/     /docs/tasks/administer-cluster/weave-network-policy/ 301
+/docs/tasks/configure-pod-container/assign-cpu-ram-container/     /docs/tasks/configure-pod-container/assign-memory-resource/ 301
+
+/docs/tasks/kubectl/get-shell-running-container/     /docs/tasks/debug-application-cluster/get-shell-running-container/ 301
+/docs/tasks/kubectl/install/     /docs/tasks/tools/install-kubectl/ 301
+/docs/tasks/kubectl/list-all-running-container-images/     /docs/tasks/access-application-cluster/list-all-running-container-images/ 301
+
+/docs/tasks/manage-stateful-set/debugging-a-statefulset/     /docs/tasks/debug-application-cluster/debug-stateful-set/ 301
+/docs/tasks/manage-stateful-set/delete-pods/     /docs/tasks/run-application/force-delete-stateful-set-pod/ 301
+/docs/tasks/manage-stateful-set/deleting-a-statefulset/     /docs/tasks/run-application/delete-stateful-set/ 301
+/docs/tasks/manage-stateful-set/scale-stateful-set/     /docs/tasks/run-application/scale-stateful-set/ 301
+/docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set/     /docs/tasks/run-application/upgrade-pet-set-to-stateful-set/ 301
+
+/docs/tasks/run-application/podpreset/     /docs/tasks/inject-data-application/podpreset/ 301
+/docs/tasks/troubleshoot/debug-init-containers/     /docs/tasks/debug-application-cluster/debug-init-containers/ 301
+/docs/tasks/web-ui-dashboard/     /docs/tasks/access-application-cluster/web-ui-dashboard/ 301
+/docs/templatedemos/     /docs/home/contribute/page-templates/ 301
+/docs/tools/kompose/     /docs/tools/kompose/user-guide/ 301
+
+/docs/tutorials/clusters/multiple-schedulers/     /docs/tasks/administer-cluster/configure-multiple-schedulers/ 301
+/docs/tutorials/connecting-apps/connecting-frontend-backend/     /docs/tasks/access-application-cluster/connecting-frontend-backend/ 301
+/docs/tutorials/federation/set-up-cluster-federation-kubefed/     /docs/tasks/federation/set-up-cluster-federation-kubefed/ 301
+//docs/tutorials/federation/set-up-cluster-federation-kubefed.md     /docs/tasks/federation/set-up-cluster-federation-kubefed/ 301
+/docs/tutorials/federation/set-up-coredns-provider-federation/     /docs/tasks/federation/set-up-coredns-provider-federation/ 301
+/docs/tutorials/federation/set-up-placement-policies-federation/     /docs/tasks/federation/set-up-placement-policies-federation/ 301
+/docs/tutorials/getting-started/create-cluster/     /docs/tutorials/kubernetes-basics/cluster-intro/ 301
+/docs/tutorials/stateful-application/run-replicated-stateful-application/     /docs/tasks/run-application/run-replicated-stateful-application/ 301
+/docs/tutorials/stateful-application/run-stateful-application/     /docs/tasks/run-application/run-single-instance-stateful-application/ 301
+/docs/tutorials/stateless-application/expose-external-ip-address-service/     /docs/tasks/access-application-cluster/service-access-application-cluster/ 301
+/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/     /docs/tasks/run-application/run-stateless-application-deployment/ 301
+/docs/tutorials/stateless-application/run-stateless-application-deployment/     /docs/tasks/run-application/run-stateless-application-deployment/ 301
+
+/docs/user-guide/accessing-the-cluster/     /docs/tasks/access-application-cluster/access-cluster/ 301
+/docs/user-guide/add-entries-to-pod-etc-hosts-with-host-aliases/     /docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases/ 301
+/docs/user-guide/annotations/     /docs/concepts/overview/working-with-objects/annotations/ 301
+/docs/user-guide/application-troubleshooting/     /docs/tasks/debug-application-cluster/debug-application/ 301
+/docs/user-guide/compute-resources/     /docs/concepts/configuration/manage-compute-resources-container/ 301
+/docs/user-guide/config-best-practices/     /docs/concepts/configuration/overview/ 301
+/docs/user-guide/configmap/     /docs/tasks/configure-pod-container/configmap/ 301
+/docs/user-guide/configuring-containers/     /docs/tasks/ 301
+/docs/user-guide/connecting-applications/     /docs/concepts/services-networking/connect-applications-service/ 301
+/docs/user-guide/connecting-to-applications-port-forward/     /docs/tasks/access-application-cluster/port-forward-access-application-cluster/ 301
+/docs/user-guide/connecting-to-applications-proxy/     /docs/tasks/access-kubernetes-api/http-proxy-access-api/ 301
+/docs/user-guide/container-environment/     /docs/concepts/containers/container-lifecycle-hooks/ 301
+/docs/user-guide/cron-jobs/     /docs/concepts/workloads/controllers/cron-jobs/ 301
+/docs/user-guide/debugging-pods-and-replication-controllers/     /docs/tasks/debug-application-cluster/debug-pod-replication-controller/ 301
+/docs/user-guide/debugging-services/     /docs/tasks/debug-application-cluster/debug-service/ 301
+/docs/user-guide/deploying-applications/     /docs/tasks/run-application/run-stateless-application-deployment/ 301
+/docs/user-guide/deployments/     /docs/concepts/workloads/controllers/deployment/ 301
+/docs/user-guide/downward-api/     /docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/ 301
+/docs/user-guide/downward-api/volume/     /docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/ 301
+/docs/user-guide/environment-guide/     /docs/tasks/inject-data-application/environment-variable-expose-pod-information/ 301
+/docs/user-guide/federation/cluster/     /docs/tasks/administer-federation/cluster/ 301
+/docs/user-guide/federation/configmap/     /docs/tasks/administer-federation/configmap/ 301
+/docs/user-guide/federation/daemonsets/     /docs/tasks/administer-federation/daemonset/ 301
+/docs/user-guide/federation/deployment/     /docs/tasks/administer-federation/deployment/ 301
+/docs/user-guide/federation/events/     /docs/tasks/administer-federation/events/ 301
+/docs/user-guide/federation/federated-ingress/     /docs/tasks/administer-federation/ingress/ 301
+/docs/user-guide/federation/federated-services/     /docs/tasks/federation/federation-service-discovery/ 301
+/docs/user-guide/federation/     /docs/concepts/cluster-administration/federation/ 301
+/docs/user-guide/federation/namespaces/     /docs/tasks/administer-federation/namespaces/ 301
+/docs/user-guide/federation/replicasets/     /docs/tasks/administer-federation/replicaset/ 301
+/docs/user-guide/federation/secrets/     /docs/tasks/administer-federation/secret/ 301
+/docs/user-guide/garbage-collection/     /docs/concepts/workloads/controllers/garbage-collection/ 301
+/docs/user-guide/getting-into-containers/     /docs/tasks/debug-application-cluster/get-shell-running-container/ 301
+/docs/user-guide/gpus/     /docs/tasks/manage-gpus/scheduling-gpus/ 301
+/docs/user-guide/horizontal-pod-autoscaling/     /docs/tasks/run-application/horizontal-pod-autoscale/ 301
+/docs/user-guide/horizontal-pod-autoscaling/walkthrough/     /docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/ 301
+/docs/user-guide/identifiers/     /docs/concepts/overview/working-with-objects/names/ 301
+/docs/user-guide/images/     /docs/concepts/containers/images/ 301
+/docs/user-guide/     /docs/home/ 301
+/docs/user-guide/ingress/     /docs/concepts/services-networking/ingress/ 301
+/docs/user-guide/introspection-and-debugging/     /docs/tasks/debug-application-cluster/debug-application-introspection/ 301
+/docs/user-guide/jobs/     /docs/concepts/workloads/controllers/jobs-run-to-completion/ 301
+/docs/user-guide/jobs/expansions/     /docs/tasks/job/parallel-processing-expansion/ 301
+/docs/user-guide/jobs/work-queue-1/     /docs/tasks/job/coarse-parallel-processing-work-queue/ 301
+/docs/user-guide/jobs/work-queue-2/     /docs/tasks/job/fine-parallel-processing-work-queue/ 301
+/docs/user-guide/kubeconfig-file/     /docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/ 301
+/docs/user-guide/labels/     /docs/concepts/overview/working-with-objects/labels/ 301
+/docs/user-guide/liveness/     /docs/tasks/configure-pod-container/configure-liveness-readiness-probes/ 301
+/docs/user-guide/load-balancer/     /docs/tasks/access-application-cluster/create-external-load-balancer/ 301
+/docs/user-guide/logging/elasticsearch/     /docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/ 301
+/docs/user-guide/logging/overview/     /docs/concepts/cluster-administration/logging/ 301
+/docs/user-guide/logging/stackdriver/     /docs/tasks/debug-application-cluster/logging-stackdriver/ 301
+/docs/user-guide/managing-deployments/     /docs/concepts/cluster-administration/manage-deployment/ 301
+/docs/user-guide/monitoring/     /docs/tasks/debug-application-cluster/resource-usage-monitoring/ 301
+/docs/user-guide/namespaces/     /docs/concepts/overview/working-with-objects/namespaces/ 301
+/docs/user-guide/networkpolicies/     /docs/concepts/services-networking/network-policies/ 301
+/docs/user-guide/node-selection/     /docs/concepts/configuration/assign-pod-node/ 301
+/docs/user-guide/persistent-volumes/     /docs/concepts/storage/persistent-volumes/ 301
+/docs/user-guide/persistent-volumes/index     /docs/concepts/storage/persistent-volumes/ 301
+/docs/user-guide/persistent-volumes/index.md     /docs/concepts/storage/persistent-volumes/ 301
+/docs/user-guide/persistent-volumes/walkthrough/     /docs/tasks/configure-pod-container/configure-persistent-volume-storage/ 301
+/docs/user-guide/petset/     /docs/concepts/workloads/controllers/petset/ 301
+/docs/user-guide/petset/bootstrapping/     /docs/concepts/workloads/controllers/petset/ 301
+/docs/user-guide/pod-preset/     /docs/tasks/inject-data-application/podpreset/ 301
+/docs/user-guide/pod-security-policy/     /docs/concepts/policy/pod-security-policy/ 301
+/docs/user-guide/pod-states/     /docs/concepts/workloads/pods/pod-lifecycle/ 301
+/docs/user-guide/pod-templates/     /docs/concepts/workloads/pods/pod-overview/ 301
+/docs/user-guide/pods/     /docs/concepts/workloads/pods/pod/ 301
+/docs/user-guide/pods/init-container/     /docs/concepts/workloads/pods/init-containers/ 301
+/docs/user-guide/pods/multi-container/     /docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/ 301
+/docs/user-guide/pods/single-container/     /docs/tasks/run-application/run-stateless-application-deployment/ 301
+/docs/user-guide/prereqs/     /docs/tasks/tools/install-kubectl/ 301
+/docs/user-guide/production-pods/     /docs/tasks/ 301
+/docs/user-guide/projected-volume/     /docs/tasks/configure-pod-container/configure-projected-volume-storage/ 301
+/docs/user-guide/quick-start/     /docs/tasks/access-application-cluster/service-access-application-cluster/ 301
+/docs/user-guide/replicasets/     /docs/concepts/workloads/controllers/replicaset/ 301
+/docs/user-guide/replication-controller/     /docs/concepts/workloads/controllers/replicationcontroller/ 301
+/docs/user-guide/rolling-updates/     /docs/tasks/run-application/rolling-update-replication-controller/ 301
+/docs/user-guide/secrets/     /docs/concepts/configuration/secret/ 301
+/docs/user-guide/secrets/walkthrough/     /docs/tasks/inject-data-application/distribute-credentials-secure/ 301
+/docs/user-guide/service-accounts/     /docs/tasks/configure-pod-container/configure-service-account/ 301
+/docs/user-guide/services-firewalls/     /docs/tasks/access-application-cluster/configure-cloud-provider-firewall/ 301
+/docs/user-guide/services/     /docs/concepts/services-networking/service/ 301
+/docs/user-guide/services/operations/     /docs/tasks/access-application-cluster/connecting-frontend-backend/ 301
+/docs/user-guide/sharing-clusters/     /docs/tasks/administer-cluster/share-configuration/ 301
+/docs/user-guide/simple-nginx/     /docs/tasks/run-application/run-stateless-application-deployment/ 301
+/docs/user-guide/thirdpartyresources/     /docs/tasks/access-kubernetes-api/extend-api-third-party-resource/ 301
+/docs/user-guide/ui/     /docs/tasks/access-application-cluster/web-ui-dashboard/ 301
+/docs/user-guide/update-dem/     /docs/tasks/run-application/rolling-update-replication-controller/ 301
+/docs/user-guide/volumes/     /docs/concepts/storage/volumes/ 301
+/docs/user-guide/working-with-resources/     /docs/tutorials/object-management-kubectl/object-management/ 301
+
+/docs/whatisk8s/     /docs/concepts/overview/what-is-kubernetes/ 301
+
+
+##############
+# address 404s
+#
+/concepts/containers/container-lifecycle-hooks/     /docs/concepts/containers/container-lifecycle-hooks/ 301
+
+/docs/api-reference/apps/v1alpha1/definitions     https://v1-4.docs.kubernetes.io/docs/api-reference/apps/v1alpha1/definitions/ 301
+/docs/api-reference/apps/v1beta1/operations     https://v1-4.docs.kubernetes.io/docs/api-reference/apps/v1beta1/operations/ 301
+/docs/api-reference/authorization.k8s.io/v1beta1/definitions     https://v1-4.docs.kubernetes.io/docs/api-reference/authorization.k8s.io/v1beta1/definitions/ 301
+/docs/api-reference/authorization.k8s.io/v1beta1/operations     https://v1-4.docs.kubernetes.io/docs/api-reference/authorization.k8s.io/v1beta1/operations/ 301
+/docs/api-reference/autoscaling/v1/operations     https://v1-4.docs.kubernetes.io/docs/api-reference/autoscaling/v1/operations/ 301
+/docs/api-reference/batch/v1/operations     https://v1-4.docs.kubernetes.io/docs/api-reference/batch/v1/operations/ 301
+/docs/api-reference/batch/v2alpha1/definitions     https://v1-4.docs.kubernetes.io/docs/api-reference/batch/v2alpha1/definitions/ 301
+/docs/api-reference/certificates.k8s.io/v1alpha1/definitions     https://v1-4.docs.kubernetes.io/docs/api-reference/certificates.k8s.io/v1alpha1/definitions/ 301
+/docs/api-reference/certificates/v1alpha1/operations     https://v1-4.docs.kubernetes.io/docs/api-reference/certificates/v1alpha1/operations/ 301
+/docs/api-reference/extensions/v1beta1/operations     https://v1-4.docs.kubernetes.io/docs/api-reference/extensions/v1beta1/operations/ 301
+/docs/api-reference/policy/v1alpha1/definitions     https://v1-4.docs.kubernetes.io/docs/api-reference/policy/v1alpha1/definitions/ 301
+/docs/api-reference/policy/v1beta1/definitions     https://v1-4.docs.kubernetes.io/docs/api-reference/policy/v1beta1/definitions/ 301
+/docs/api-reference/README     https://v1-4.docs.kubernetes.io/docs/api-reference/README/ 301
+/docs/api-reference/storage.k8s.io/v1beta1/operations     https://v1-4.docs.kubernetes.io/docs/api-reference/storage.k8s.io/v1beta1/operations/ 301
+
+/docs/api-reference/v1/definitions/     /docs/api-reference/v1.7/ 301
+/docs/api-reference/v1/operations/     /docs/api-reference/v1.7/ 301
+
+/docs/concepts/cluster/     /docs/concepts/cluster-administration/cluster-administration-overview/ 301
+/docs/concepts/object-metadata/annotations/     /docs/concepts/overview/working-with-objects/annotations/ 301
+
+/docs/contribute/write-new-topic/     /docs/home/contribute/write-new-topic/ 301
+
+/docs/getting-started-guides/coreos/azure/     /docs/getting-started-guides/coreos/ 301
+/docs/getting-started-guides/coreos/bare_metal_calico/     /docs/getting-started-guides/coreos/ 301
+/docs/getting-started-guides/juju/     /docs/getting-started-guides/ubuntu/installation/ 301
+/docs/getting-started-guides/kargo/     /docs/getting-started-guides/kubespray/ 301
+/docs/getting-started-guides/logging-elasticsearch/     /docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/ 301
+/docs/getting-started-guides/logging/     /docs/concepts/cluster-administration/logging/ 301
+/docs/getting-started-guides/rackspace/     /docs/setup/pick-right-solution/ 301
+/docs/getting-started-guides/ubuntu-calico/     /docs/getting-started-guides/ubuntu/ 301
+/docs/getting-started-guides/ubuntu/automated/     /docs/getting-started-guides/ubuntu/ 301
+/docs/getting-started-guides/vagrant/     /docs/getting-started-guides/alternatives/ 301
+/docs/getting-started-guides/windows/While/     /docs/getting-started-guides/windows/ 301
+
+/docs/federation/api-reference/extensions/v1beta1/definitions/     /docs/reference/federation/extensions/v1beta1/definitions/ 301
+/docs/federation/api-reference/federation/v1beta1/definitions/     /docs/reference/federation/extensions/v1beta1/definitions/ 301
+/docs/federation/api-reference/README/     /docs/reference/federation/ 301
+/docs/federation/api-reference/v1/definitions/     /docs/reference/federation/v1/definitions/ 301
+/docs/reference/federation/v1beta1/definitions/     /docs/reference/federation/extensions/v1beta1/definitions/ 301
+/docs/reference/federation/v1beta1/operations/     /docs/reference/federation/extensions/v1beta1/operations/ 301
+
+/docs/reporting-security-issues/     /security/ 301
+
+/docs/stable/user-guide/labels/     /docs/concepts/overview/working-with-objects/labels/ 301
+/docs/tasks/access-application-cluster/access-cluster.md      /docs/tasks/access-application-cluster/access-cluster/ 301
+/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/     /docs/tasks/access-application-cluster/configure-access-multiple-clusters/ 301
+/docs/tasks/access-kubernetes-api/access-kubernetes-api/http-proxy-access-api/     /docs/tasks/access-kubernetes-api/http-proxy-access-api/ 301
+/docs/tasks/administer-cluster/reserve-compute-resources/out-of-resource.md     /docs/tasks/administer-cluster/out-of-resource/ 301
+/docs/tasks/configure-pod-container/configure-pod-disruption-budget/     /docs/tasks/run-application/configure-pdb/ 301
+/docs/tasks/configure-pod-container/define-command-argument-container/     /docs/tasks/inject-data-application/define-command-argument-container/ 301
+
+/docs/tasks/debug-application-cluster/sematext-logging-monitoring/     https://sematext.com/kubernetes/ 301
+
+/docs/tasks/job/work-queue-1/     /docs/concepts/workloads/controllers/jobs-run-to-completion/ 301
+/docs/tasks/manage-stateful-set/delete-pods/     /docs/tasks/run-application/delete-stateful-set/ 301
+
+/docs/tutorials/getting-started/cluster-intro/     /docs/tutorials/kubernetes-basics/cluster-intro/ 301
+/docs/tutorials/getting-started/expose-intro/     /docs/tutorials/kubernetes-basics/expose-intro/ 301
+/docs/tutorials/getting-started/scale-app/     /docs/tutorials/kubernetes-basics/scale-interactive/ 301
+/docs/tutorials/getting-started/scale-intro/     /docs/tutorials/kubernetes-basics/scale-intro/ 301
+/docs/tutorials/getting-started/update-interactive/     /docs/tutorials/kubernetes-basics/update-interactive/ 301
+/docs/tutorials/getting-started/update-intro/     /docs/tutorials/kubernetes-basics/ 301
+
+/docs/user-guide/containers/     /docs/tasks/inject-data-application/define-command-argument-container/ 301
+/docs/user-guide/horizontal-pod-autoscaling/walkthrough.md     /docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/ 301
+/docs/user-guide/ingress.md     /docs/concepts/services-networking/ingress/ 301
+/docs/user-guide/replication-controller/operations/     /docs/concepts/workloads/controllers/replicationcontroller/ 301
+/docs/user-guide/resizing-a-replication-controller/     /docs/concepts/workloads/controllers/replicationcontroller/ 301
+/docs/user-guide/scheduled-jobs/     /docs/concepts/workloads/controllers/cron-jobs/ 301
+/docs/user-guide/security-context/     /docs/tasks/configure-pod-container/security-context/ 301
+
+/kubernetes-bootcamp/2-1.html     /docs/tutorials/kubernetes-basics/ 301
+/kubernetes-bootcamp/2-3-2.html     /docs/tutorials/kubernetes-basics/ 301
+/kubernetes     /docs/ 301
+/kubernetes/swagger-spec     https://github.com/kubernetes/kubernetes/tree/master/api/swagger-spec/ 301
+/serviceaccount/token/     /docs/tasks/configure-pod-container/configure-service-account/ 301
+
+/v1.1/docs/admin/networking.html/     /docs/concepts/cluster-administration/networking/ 301
+/v1.1/docs/getting-started-guides/     /docs/tutorials/kubernetes-basics/ 301
+
+#################################
 # redirects from /js/redirects.js
 #
-/resource-quota													/docs/concepts/policy/resource-quotas		301
-/horizontal-pod-autoscaler										/docs/tasks/run-application/horizontal-pod-autoscale		301
-/docs/roadmap													https://github.com/kubernetes/kubernetes/milestones/		301
-/api-ref														https://github.com/kubernetes/kubernetes/milestones/		301
-/kubernetes/third_party/swagger-ui								/docs/reference		301
-/docs/user-guide/overview										/docs/concepts/overview/what-is-kubernetes		301
-/docs/troubleshooting											/docs/tasks/debug-application-cluster/troubleshooting		301
-/docs/concepts/services-networking/networkpolicies				/docs/concepts/services-networking/network-policies		301
-/docs/getting-started-guides/meanstack							https://medium.com/google-cloud/running-a-mean-stack-on-google-cloud-platform-with-kubernetes-149ca81c2b5d		301
-/docs/samples													/docs/tutorials		301
-/v1.1															/		301
-/v1.0															/		301
 
-#
+/resource-quota/     /docs/concepts/policy/resource-quotas/ 301
+/horizontal-pod-autoscaler/     /docs/tasks/run-application/horizontal-pod-autoscale/ 301
+/docs/roadmap/     https://github.com/kubernetes/kubernetes/milestones/ 301
+/api-ref/     https://github.com/kubernetes/kubernetes/milestones/ 301
+/kubernetes/third_party/swagger-ui/     /docs/reference/ 301
+/docs/user-guide/overview/     /docs/concepts/overview/what-is-kubernetes/ 301
+/docs/troubleshooting/     /docs/tasks/debug-application-cluster/troubleshooting/ 301
+/docs/concepts/services-networking/networkpolicies/     /docs/concepts/services-networking/network-policies/ 301
+/docs/getting-started-guides/meanstack/     https://medium.com/google-cloud/running-a-mean-stack-on-google-cloud-platform-with-kubernetes-149ca81c2b5d/ 301
+/docs/samples/     /docs/tutorials/ 301
+
+/v1.1 301
+/v1.0 301
+
+########################################################
 # Redirect users with chinese language preference to /cn
 #
-#/  /cn  302  Language=zh
+#/     /cn  302  Language=zh
+
+###########################
+# Fixed 404s from analytics
+#
+
+/concepts/containers/container-lifecycle-hooks/     /docs/concepts/containers/container-lifecycle-hooks/ 301
+/docs/abstractions/controllers/petset/     /docs/concepts/workloads/controllers/petset/ 301
+
+/docs/admin/add-ons/     /docs/concepts/cluster-administration/addons/ 301
+/docs/admin/limitrange/Limits/     /docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage/ 301
+
+/docs/concepts/cluster-administration/device-plugins/     /docs/concepts/cluster-administration/network-plugins/ 301
+/docs/concepts/configuration/container-command-args/     /docs/tasks/inject-data-application/define-command-argument-container/ 301
+/docs/concepts/ecosystem/thirdpartyresource/     /docs/tasks/access-kubernetes-api/extend-api-third-party-resource/ 301
+/docs/concepts/overview/     /docs/concepts/overview/what-is-kubernetes/ 301
+/docs/concepts/policy/container-capabilities/     /docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container/ 301
+/docs/concepts/policy/security-context/     /docs/tasks/configure-pod-container/security-context/ 301
+/docs/concepts/storage/volumes/emptyDirapiVersion/     /docs/concepts/storage/volumes/#emptydir/ 301
+/docs/concepts/tools/kubectl/object-management-using-commands/     /docs/tutorials/object-management-kubectl/imperative-object-management-command/ 301
+/docs/concepts/workload/pods/pod-overview/     /docs/concepts/workloads/pods/pod-overview 301
+/docs/concepts/workloads/controllers/cron-jobs/deployment/     /docs/concepts/workloads/controllers/cron-jobs/ 301
+/docs/concepts/workloads/controllers/statefulsets/     /docs/concepts/workloads/controllers/statefulset/ 301
+/docs/concepts/workloads/pods/init-containers/Kubernetes     /docs/concepts/workloads/pods/init-containers/ 301
+
+/docs/consumer-guideline/pod-security-coverage/     /docs/concepts/policy/pod-security-policy/ 301
+
+/docs/contribute/create-pull-request/     /docs/home/contribute/create-pull-request 301
+/docs/contribute/page-templates/     /docs/home/contribute/page-templates 301
+/docs/contribute/review-issues/     /docs/home/contribute/review-issues 301
+/docs/contribute/stage-documentation-changes/     /docs/home/contribute/stage-documentation-changes/ 301
+/docs/contribute/style-guide/     /docs/home/contribute/style-guide 301
+
+/docs/deprecate/     /ddocs/reference/deprecation-policy/ 301
+/docs/deprecation-policy/     /docs/reference/deprecation-policy/ 301
+
+/docs/federation/api-reference/     /docs/reference/federation/v1/operations/ 301
+/docs/federation/api-reference/extensions/v1beta1/operations/     /docs/reference/federation/extensions/v1beta1/operations/ 301
+/docs/federation/api-reference/federation/v1beta1/operations/     /docs/reference/federation/extensions/v1beta1/operations/ 301
+/docs/federation/api-reference/v1/operations/     /docs/reference/federation/v1/operations/ 301
+
+/docs/home/deprecation-policy/     /docs/reference/deprecation-policy/ 301
+
+/docs/stable/user-guide/labels/     /docs/concepts/overview/working-with-objects/labels/ 301
+
+/docs/tasks/administer-cluster/apply-resource-quota-limit/     /docs/tasks/administer-cluster/quota-api-object/ 301
+/docs/tasks/administer-cluster/configure-namespace-isolation/     /docs/concepts/services-networking/network-policies/ 301
+/docs/tasks/administer-cluster/configure-pod-disruption-budget/     /docs/tasks/run-application/configure-pdb/ 301
+/docs/tasks/administer-cluster/cpu-management-policies/     /docs/concepts/configuration/manage-compute-resources-container/ 301
+/docs/tasks/administer-cluster/default-cpu-request-limit/     /docs/tasks/configure-pod-container/assign-cpu-resource/#specify-a-cpu-request-and-a-cpu-limit/ 301
+/docs/tasks/administer-cluster/default-memory-request-limit/     /docs/tasks/configure-pod-container/assign-memory-resource/#specify-a-memory-request-and-a-memory-limit/ 301
+
+/docs/tasks/configure-pod-container/cilium-network-policy/     /docs/tasks/administer-cluster/cilium-network-policy/ 301
+/docs/tasks/configure-pod-container/define-command-argument-container/     /docs/tasks/inject-data-application/define-command-argument-container/ 301
+/docs/tasks/configure-pod-container/projected-volume/     /docs/tasks/configure-pod-container/configure-projected-volume-storage/ 301
+
+/docs/tasks/stateful-sets/deleting-pods/     /docs/tasks/run-application/force-delete-stateful-set-pod/ 301
+
+/docs/user-guide/liveness/     /docs/tasks/configure-pod-container/configure-liveness-readiness-probes/ 301
+/docs/user-guide/logging/     /docs/concepts/cluster-administration/logging/ 301
+/docs/user-guide/replication-controller/operations/     /docs/concepts/workloads/controllers/replicationcontroller/ 301
+/docs/user-guide/service-accounts/working-with-resources/     /docs/tutorials/object-management-kubectl/object-management/ 301
+/docs/user-guide/StatefulSet/     /docs/concepts/workloads/controllers/statefulset/ 301
+/docs/user-guide/ui-access/     /docs/tasks/access-application-cluster/web-ui-dashboard/ 301
+
+/latest/docs/     /docs/home/ 301
+
+/kubernetes/swagger-spec     https://github.com/kubernetes/kubernetes/tree/master/api/swagger-spec/ 301

_sass/_base.sass

@@ -258,12 +258,47 @@ ul.global-nav
 				left: 0
 				background: #fff
 
+			.ui-icon
+				filter: brightness(0) invert(1)
+
+		ul
+			display: none
+			position: fixed
+			top: 40px
+			text-align: left
+
+			li
+				display: block
+				height: 28px
+
+				a
+					background: $dark-grey
+					color: #fff
+					padding: 7px
+
+			li:last-child
+				a
+					border-radius: 7px
+
+	li:hover
+		ul
+			display: block
+
 
 .flip-nav ul.global-nav li a,
 .open-nav ul.global-nav li a,
-	color: #333
+	color: $dark-grey
+
+.flip-nav ul.global-nav li a .ui-icon
+	filter: brightness(0)
+
+
+.flip-nav ul.global-nav li ul li a,
+	background: #fff
+	color: $dark-grey
 
 .flip-nav ul.global-nav li a.active:after,
+.flip-nav ul.global-nav li ul li a.active:after,
 .open-nav ul.global-nav li a.active:after,
 
 	background: $blue

case-studies/ancestry.html

@@ -34,7 +34,7 @@ Ancestry, the global leader in family history and consumer genomics, uses sophis
   The company is transitioning to cloud native infrastructure, using <a href="https://www.docker.com">Docker</a> containerization, <a href="https://kubernetes.io">Kubernetes</a> orchestration and <a href="https://prometheus.io">Prometheus</a> for cluster monitoring.<br>
 <br>
 <h2>Impact</h2>
-  "Every single product, every decision we make at Ancestry, focuses on delighting our customers with intimate, sometimes life-changing discoveries about themselves and their families," says MacKay. "As the company continues to grow, the increased productivity gains from using Kubernetes has helped Ancestry make customer discoveries faster. With the move to Dockerization for example, instead of taking between 20 to 50 minutes to deploy a new piece of code, we can now deploy in under a minute for much of our code. We’ve truly experienced a significant time savings in addition to the various features and benefits from cloud native and Kubernetes-type technologies."
+  "Every single product, every decision we make at Ancestry, focuses on delighting our customers with intimate, sometimes life-changing discoveries about themselves and their families," says MacKay. "As the company continues to grow, the increased productivity gains from using Kubernetes has helped Ancestry make customer discoveries faster. With the move to Dockerization for example, instead of taking between 20 to 50 minutes to deploy a new piece of code, we can now deploy in under a minute for much of our code. We’ve truly experienced significant time savings in addition to the various features and benefits from cloud native and Kubernetes-type technologies."
 </div>
 </div>
 </section>

case-studies/box.html

@@ -26,7 +26,7 @@ css: /css/style_box.css
   <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."
+        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 of different clouds, especially bare metal, have very different interfaces."
         <br>
   </div>
 
@@ -52,10 +52,10 @@ css: /css/style_box.css
   <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>
+      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 of 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>
+      Another plus: Ghods liked that <a href="https://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>
@@ -69,7 +69,7 @@ css: /css/style_box.css
 
 <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>
+    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 too 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>

case-studies/buffer.html

@@ -85,7 +85,7 @@ css: /css/style_buffer.css
     <br><br>
     Plus, unlike with their old system, they could scale things horizontally with one command. "As we rolled it out," Farrelly says, "we could anticipate and just click a button. This allowed us to deal with the demand that our users were placing on the system and easily scale it to handle it."
     <br><br>
-    Another thing they weren’t able to do before was a canary deploy. This new capability "made us so much more confident in deploying big changes," says Farrelly. "Before, it took a lot of testing, which is still good, but it was also a lot of ‘fingers crossed.’ And this is something that gets run 800,000 times a day, the core of our business. If it doesn’t work, our business doesn’t work. In a Kubernetes world, I can do a canary deploy to test it for 1 percent and I can shut it down very quickly if it isn’t working. This has leveled up our ability to deploy and roll out new changes quickly while reduce&nbsp;risk."
+    Another thing they weren’t able to do before was a canary deploy. This new capability "made us so much more confident in deploying big changes," says Farrelly. "Before, it took a lot of testing, which is still good, but it was also a lot of ‘fingers crossed.’ And this is something that gets run 800,000 times a day, the core of our business. If it doesn’t work, our business doesn’t work. In a Kubernetes world, I can do a canary deploy to test it for 1 percent and I can shut it down very quickly if it isn’t working. This has leveled up our ability to deploy and roll out new changes quickly while reducing&nbsp;risk."
 
 </div>
 </section>

case-studies/index.html

@@ -14,6 +14,12 @@ cid: caseStudies
     <main>
         <div class="content">
             <div class="case-studies">
+              <div class="case-study">
+                  <img src="/images/case_studies/peardeck.png" alt="peardeck">
+                  <p class="quote">"In terms of the cloud, Kubernetes and Prometheus have so much to offer."</p>
+                  <!--<p class="attrib">—  Riley Eynon-Lynch, CEO of Pear Deck</p>-->
+                  <a href="/case-studies/peardeck/">Read about Pear Deck</a>
+              </div>
               <div class="case-study">
                   <img src="/images/case_studies/buffer.png" alt="Buffer">
                   <p class="quote">"It’s amazing that we can use the Kubernetes solution off the shelf with our team. And it just keeps getting better."</p>
@@ -32,36 +38,6 @@ cid: caseStudies
                   <!--<p class="attrib">— Paul MacKay, Software Engineer and Architect at Ancestry</p>-->
                   <a href="/case-studies/ancestry/">Read about Ancestry.com</a>
               </div>
-              <div class="case-study">
-                  <img src="/images/case_studies/golfnow.png" alt="GolfNow">
-                  <p class="quote">"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="/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="/case-studies/wikimedia/">Read about Wikimedia</a>
-                </div>
-                <div class="case-study">
-                    <img src="/images/case_studies/ebay.png" alt="eBay">
-                    <p class="quote">Inside eBay's shift to Kubernetes and containers atop OpenStack</p>
-                    <!--<p class="attrib">— None</p>-->
-                    <a href="http://www.nextplatform.com/2015/11/12/inside-ebays-shift-to-kubernetes-and-containers-atop-openstack/">Read about eBay</a>
-                </div>
-                <div class="case-study">
-                    <img src="/images/case_studies/box.png" alt="box">
-                    <p class="quote">"Kubernetes has the opportunity to be the new cloud platform. Because it’s a never-before-seen level of automation and intelligence surrounding infrastructure."</p>
-                    <!--<p class="attrib">— Sam Ghouds, Co-Founder and Services Architect of Box/p>-->
-                    <a href="/case-studies/box/">Read about Box</a>
-                </div>
             </div>
         </div>
     </main>
@@ -69,18 +45,13 @@ cid: caseStudies
 
 <section id="video">
     <main>
-        <!--<div>-->
-            <!--<h3>"I don't want to deploy software the old way ever again"</h3>-->
-            <!--<p class="attrib">— Dylan Carney, Lead Software Engineer, Zulily</p>-->
-            <!--<img src="/images/case_studies/zulily.png" id="zulilyLogo" alt="zulily">-->
-        <!--</div>-->
         <!--<div><button onclick="kub.showVideo()"><img src="/images/case_studies/video_thumb.jpg" alt="Zulily video"><h6>Kubernetes at zulily</h6></button></div>-->
         <div>
-            <!--<h3>SAP</h3>-->
-            <h3>SAP's OpenStack, running on Kubernetes in production</h3>
-            <img src="/images/case_studies/sap_small.png" id="zulilyLogo" alt="SAP">
+            <!--<h3>Box</h3>-->
+            <h4><i>"Kubernetes has the opportunity to be the new cloud platform. The amount of innovation that's going to come from being able to standardize on Kubernetes as a platform is incredibly exciting - more exciting than anything I've seen in the last 10 years of working on the cloud."</i></h4>
+            <img src="/images/case_studies/box-small.png" id="boxlogo" alt="Box">
         </div>
-        <div><button onclick="kub.showVideo()"><img src="/images/case_studies/video_thumb1.png" alt="SAP video"><h6>Kubernetes at SAP</h6></button></div>
+        <div style= "padding-left: 40px;"><button onclick="kub.showVideo()"><img src="/images/case_studies/Video-Clip-Box.png" alt="Box video"><h6>Kubernetes at Box</h6></button></div>
     </main>
 </section>
 
@@ -88,39 +59,42 @@ cid: caseStudies
     <main>
         <h3>Kubernetes Users</h3>
         <div id="usersGrid">
-            <a target="_blank" href="https://www.youtube.com/watch?v=P5qfyv_zGcU"><img src="/images/case_studies/nyt.png" alt="New York Times"></a>
-            <a target="_blank" href="https://openai.com/blog/infrastructure-for-deep-learning"><img src="/images/case_studies/openai.png" alt="OpenAI"></a>
-            <a target="_blank" href="http://blogs.wsj.com/cio/2016/02/24/big-changes-in-goldmans-software-emerge-from-small-containers/"><img src="/images/case_studies/gs.png" alt="Goldman Sachs"></a>
-            <a target="_blank" href="https://youtu.be/4gyeixJLabo"><img src="/images/case_studies/sap.png" alt="SAP"></a>
-            <a target="_blank" href="http://www.nextplatform.com/2016/05/24/samsung-experts-put-kubernetes-paces/"><img src="/images/case_studies/sds.png" alt="Samsung SDS"></a>
-            <a target="_blank" href="http://thenewstack.io/wepay-kubernetes-changed-business/"><img src="/images/case_studies/wepay.png" alt="WePay"></a>
-            <a target="_blank" href="https://www.youtube.com/watch?v=5378N5iLb2Q"><img src="/images/case_studies/soundcloud.png" alt="SoundCloud"></a>
-            <a target="_blank" href="https://www.youtube.com/watch?v=F3iMkz_NSvU"><img src="/images/case_studies/homeoffice.png" alt="UK Home Office"></a>
-            <a target="_blank" href="http://searchitoperations.techtarget.com/news/450297178/Tech-firms-roll-out-Kubernetes-in-production"><img src="/images/case_studies/concur.png" alt="Concur"></a>
-            <a target="_blank" href="http://www.nextplatform.com/2015/08/04/amadeus-takes-off-with-containers-and-clouds/"><img src="/images/case_studies/amadeus.png" alt="Amadeus"></a>
-            <a target="_blank" href="http://superuser.openstack.org/articles/how-ancestry-com-s-open-source-strategy-combines-kubernetes-and-openstack"><img src="/images/case_studies/ancestry.png" alt="Ancestry.com"></a>
-            <a target="_blank" href="https://cloud.google.com/customers/ccp-games/"><img src="/images/case_studies/ccp.png" alt="CCP Games"></a>
-            <a target="_blank" href="https://www.openstack.org/videos/video/running-kubernetes-on-openstack-at-liveperson"><img src="/images/case_studies/liveperson.png" alt="LivePerson"></a>
-            <a target="_blank" href="https://youtu.be/YkOY7DgXKyw"><img src="/images/case_studies/monzo_logo.png" alt="monzo"></a>
-            <a target="_blank" href="https://blog.box.com/blog/kubernetes-box-microservices-maximum-velocity/"><img src="/images/case_studies/box_logo.png" alt="Box"></a>
-            <a target="_blank" href="https://cloudplatform.googleblog.com/2016/09/bringing-Pokemon-GO-to-life-on-Google-Cloud.html"><img src="/images/case_studies/pokemon_go_logo.png" alt="Pokemon GO"></a>
-            <a target="_blank" href="http://blog.kubernetes.io/2016/10/kubernetes-and-openstack-at-yahoo-japan.html"><img src="/images/case_studies/yahooJapan_logo.png" alt="Yahoo! Japan"></a>
-            <a target="_blank" href="https://cloud.google.com/customers/philips/"><img src="/images/case_studies/philips_logo.png" alt="Philips"></a>
-            <a target="_blank" href="https://youtu.be/EC_ZRLsw58M"><img src="/images/case_studies/buffer_logo.png" alt="buffer"></a>
-            <a target="_blank" href="https://youtu.be/lmeFkH-rHII"><img src="/images/case_studies/comcast_logo.png" alt="Comcast"></a>
-            <a href="/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="http://blog.kubernetes.io/2017/02/inside-jd-com-shift-to-kubernetes-from-openstack.html"><img src="/images/case_studies/jd.png" alt="JD.COM"></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>
+          <a target="_blank" href="http://www.nextplatform.com/2015/08/04/amadeus-takes-off-with-containers-and-clouds/"><img src="/images/case_studies/amadeus.png" alt="Amadeus"></a>
+          <a target="_blank" href="/case-studies/ancestry/"><img src="/images/case_studies/ancestry.png" alt="Ancestry.com"></a>
+          <a target="_blank" href="/case-studies/box/"><img src="/images/case_studies/box_logo.png" alt="box"></a>
+          <a target="_blank" href="/case-studies/buffer/"><img src="/images/case_studies/buffer_logo.png" alt="Buffer"></a>
+          <a target="_blank" href="https://cloud.google.com/customers/ccp-games/"><img src="/images/case_studies/ccp.png" alt="CCP Games"></a>
+          <a target="_blank" href="https://youtu.be/lmeFkH-rHII"><img src="/images/case_studies/comcast_logo.png" alt="Comcast"></a>
+          <a target="_blank" href="http://searchitoperations.techtarget.com/news/450297178/Tech-firms-roll-out-Kubernetes-in-production"><img src="/images/case_studies/concur.png" alt="Concur"></a>
+          <a target="_blank" href="http://www.nextplatform.com/2015/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="http://blogs.wsj.com/cio/2016/02/24/big-changes-in-goldmans-software-emerge-from-small-containers/"><img src="/images/case_studies/gs.png" alt="Goldman Sachs"></a>
+          <a target="_blank" href="/case-studies/golfnow/"><img src="/images/case_studies/golfnow_logo.png" alt="GolfNow"></a>
+          <a target="_blank" href="http://blog.kubernetes.io/2017/02/inside-jd-com-shift-to-kubernetes-from-openstack.html"><img src="/images/case_studies/jd.png" alt="JD.COM"></a>
+          <a target="_blank" href="https://www.openstack.org/videos/video/running-kubernetes-on-openstack-at-liveperson"><img src="/images/case_studies/liveperson.png" alt="LivePerson"></a>
+          <a target="_blank" href="https://youtu.be/YkOY7DgXKyw"><img src="/images/case_studies/monzo_logo.png" alt="monzo"></a>
+          <a target="_blank" href="https://www.youtube.com/watch?v=P5qfyv_zGcU"><img src="/images/case_studies/nyt.png" alt="New York Times"></a>
+          <a target="_blank" href="https://openai.com/blog/infrastructure-for-deep-learning"><img src="/images/case_studies/openai.png" alt="OpenAI"></a>
+          <a target="_blank" href="/case-studies/peardeck/"><img src="/images/case_studies/peardeck_logo.png" alt="peardeck"></a>
+          <a href="/case-studies/pearson/"><img src="/images/case_studies/pearson_logo.png" alt="Pearson"></a>
+          <a target="_blank" href="https://cloud.google.com/customers/philips/"><img src="/images/case_studies/philips_logo.png" alt="Philips"></a>
+          <a target="_blank" href="https://cloudplatform.googleblog.com/2016/09/bringing-Pokemon-GO-to-life-on-Google-Cloud.html"><img src="/images/case_studies/pokemon_go_logo.png" alt="Pokemon GO"></a>
+          <a target="_blank" href="http://www.nextplatform.com/2016/05/24/samsung-experts-put-kubernetes-paces/"><img src="/images/case_studies/sds.png" alt="Samsung SDS"></a>
+          <a target="_blank" href="https://youtu.be/4gyeixJLabo"><img src="/images/case_studies/sap.png" alt="SAP"></a>
+          <a target="_blank" href="https://www.youtube.com/watch?v=5378N5iLb2Q"><img src="/images/case_studies/soundcloud.png" alt="SoundCloud"></a>
+          <a target="_blank" href="https://www.youtube.com/watch?v=F3iMkz_NSvU"><img src="/images/case_studies/homeoffice.png" alt="UK Home Office"></a>
+          <a target="_blank" href="http://thenewstack.io/wepay-kubernetes-changed-business/"><img src="/images/case_studies/wepay.png" alt="WePay"></a>
+          <a target="_blank" href="/case-studies/wink/"><img src="/images/case_studies/wink.png" alt="Wink"></a>
+          <a href="/case-studies/wikimedia/"><img src="/images/case_studies/wikimedia_logo.png" alt="Wikimedia"></a>
+          <a target="_blank" href="http://blog.kubernetes.io/2016/10/kubernetes-and-openstack-at-yahoo-japan.html"><img src="/images/case_studies/yahooJapan_logo.png" alt="Yahoo! Japan"></a>
+          <a target="_blank" href="#" onclick="event.preventDefault(); kub.showVideo()"><img src="/images/case_studies/zulily_logo.png" alt="zulily"></a>
+          <a target="_blank" href="https://docs.google.com/a/google.com/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform" class="tell-your-story"><img src="/images/case_studies/story.png" alt="Tell your story"></a>
         </div>
     </main>
 </section>
 
 
 <div id="videoPlayer">
-    <!--<iframe data-url="https://www.youtube.com/watch?v=B0_5Nms8sD0" frameborder="0" allowfullscreen></iframe>-->
-    <iframe data-url="https://www.youtube.com/embed/4gyeixJLabo?autoplay=1" frameborder="0" allowfullscreen="true"></iframe>
+    <!--<iframe data-url="https://www.youtube.com/watch?v=of45hYbkIZs" frameborder="0" allowfullscreen></iframe>-->
+    <iframe data-url="https://www.youtube.com/embed/of45hYbkIZs?autoplay=1" frameborder="0" allowfullscreen="true"></iframe>
     <button id="closeButton"></button>
 </div>

case-studies/peardeck.html

@@ -0,0 +1,111 @@
+---
+title: Pear Deck Case Study
+layout: basic
+case_study_styles: true
+cid: caseStudies
+css: /css/style_peardeck.css
+---
+
+<div class="banner1">
+  <h1> CASE STUDY:<img src="/images/peardeck_logo.png"  width="22%" style="margin-bottom:-0px"><br> <div class="subhead">Infrastructure for a Growing EdTech Startup</div></h1>
+
+</div>
+
+<div class="details">
+    Company &nbsp;<b>Pear Deck</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location &nbsp;<b>Iowa City, Iowa</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Industry &nbsp;<b>Educational Software</b>
+</div>
+
+<hr>
+
+<section class="section1">
+<div class="cols">
+  <div class="col1">
+    <h2>Challenge</h2>
+      The three-year-old startup provides a web app for teachers to interact with their students in the classroom. The JavaScript  app was built on Google’s web app development platform <a href="https://firebase.google.com/">Firebase</a>, using <a href="https://www.heroku.com/">Heroku</a>. As the user base steadily grew, so did the development team. "We outgrew Heroku when we started wanting to have multiple services, and the deploying story got pretty horrendous. We were frustrated that we couldn’t have the developers quickly stage a version," says CEO Riley Eynon-Lynch. "Tracing and monitoring became basically impossible." On top of that, many of Pear Deck’s customers are behind government firewalls and connect through Firebase, not Pear Deck’s servers, making troubleshooting even more difficult.
+</div>
+
+<div class="col2">
+  <h2>Solution</h2>
+    In 2016, the company began moving their code from Heroku to <a href="https://www.docker.com/">Docker</a> containers running on <a href="https://cloud.google.com/container-engine/">Google Container Engine</a>, orchestrated by <a href="http://kubernetes.io/">Kubernetes</a> and monitored with <a href="https://prometheus.io/">Prometheus</a>.
+    <br>
+    <br>
+<h2>Impact</h2>
+      The new cloud native stack immediately improved the development workflow, speeding up deployments. Prometheus gave Pear Deck "a lot of confidence, knowing that people are still logging into the app and using it all the time," says Eynon-Lynch. "The biggest impact is being able to work as a team on the configuration in git in a pull request, and the biggest confidence comes from the solidity of the abstractions and the trust that we have in Kubernetes actually making our yaml files a reality."
+</div>
+</div>
+</section>
+
+<div class="banner2">
+  <div class="banner2text">
+    "We didn’t even realize how stressed out we were about our lack of insight into what was happening with the app. I’m really excited and have more and more confidence in the actual state of our application for our actual users, and not just what the CPU graphs are saying, because of Prometheus and Kubernetes."<br><br><span style="font-size:16px;letter-spacing:2px;">– RILEY EYNON-LYNCH, CEO OF PEAR DECK</span>
+  </div>
+</div>
+
+<section class="section2">
+<div class="fullcol">
+<h2>With the speed befitting a startup, Pear Deck delivered its first prototype to customers within three months of incorporating.</h2>
+As a former high school math teacher, CEO Riley Eynon-Lynch felt an urgency to provide a tech solution to classes where instructors struggle to interact with every student in a short amount of time. "Pear Deck is an app that students can use to interact with the teacher all at once," he says. "When the teacher asks a question, instead of just the kid at the front of the room answering again, everybody can answer every single question. It’s a huge fundamental shift in the messaging to the students about how much we care about them and how much they are a part of the classroom."<br><br>
+Eynon-Lynch and his partners quickly built a JavaScript web app on Google’s web app development platform <a href="https://firebase.google.com/">Firebase</a>, and launched the minimum viable product [MVP] on <a href="https://www.heroku.com/">Heroku</a> "because it was fast and easy," he says. "We made everything as easy as we could."
+<br><br>
+But once it launched, the user base began growing steadily at a rate of 30 percent a month. "Our Heroku bill was getting totally insane," Eynon-Lynch says. But even more crucially, as the company hired more developers to keep pace, "we outgrew Heroku. We wanted to have multiple services and the deploying story got pretty horrendous. We were frustrated that we couldn’t have the developers quickly stage a version. Tracing and monitoring became basically impossible."
+<br><br>
+On top of that, many of Pear Deck’s customers are behind government firewalls and connect through Firebase, not Pear Deck’s servers, making troubleshooting even more difficult.
+<br><br>
+The team began looking around for another solution, and finally decided in early 2016 to start moving the app from Heroku to <a href="https://www.docker.com/">Docker</a> containers running on <a href="https://cloud.google.com/container-engine/">Google Container Engine</a>, orchestrated by <a href="http://kubernetes.io/">Kubernetes</a> and monitored with <a href="https://prometheus.io/">Prometheus</a>.
+</div>
+</section>
+
+<div class="banner3">
+  <div class="banner3text">
+    "When it became clear that Google Container Engine was going to have a lot of support from Google and be a fully-managed Kubernetes platform, it seemed very obvious to us that was the way to go," says Eynon-Lynch.
+  </div>
+</div>
+
+<section class="section3">
+<div class="fullcol">
+  They had considered other options like Google’s App Engine (which they were already using for one service) and Amazon’s <a href="https://aws.amazon.com/ec2/">Elastic Compute Cloud</a> (EC2), while experimenting with running one small service that wasn’t accessible to the Internet in Kubernetes. "When it became clear that Google Container Engine was going to have a lot of support from Google and be a fully-managed Kubernetes platform, it seemed very obvious to us that was the way to go," says Eynon-Lynch. "We didn’t really consider Terraform and the other competitors because the abstractions offered by Kubernetes just jumped off the page to us."<br><br>
+  Once the team started porting its Heroku apps into Kubernetes, which was "super easy," he says, the impact was immediate. "Before, to make a new version of the app meant going to Heroku and reconfiguring 10 new services, so basically no one was willing to do it, and we never   staged things," he says. "Now we can deploy our exact same configuration in lots of different clusters in 30 seconds. We have a full set up that’s always running, and then any of our developers or designers can stage new versions with one command, including their recent changes. We stage all the time now, and everyone stopped talking about how cool it is because it’s become invisible how great it is."
+  <br><br>
+  Along with Kubernetes came Prometheus. "Until pretty recently we didn’t have any kind of visibility into aggregate server metrics or performance," says Eynon-Lynch. The team had tried to use GKE’s <a href="https://cloud.google.com/stackdriver/">Stackdriver</a> monitoring, but had problems making it work, and considered <a href="https://newrelic.com/">New Relic</a>. When they started looking at Prometheus in the fall of 2016, "the fit between the abstractions in Prometheus and the way we think about how our system works, was so clear and obvious," he says.<br><br>
+  The integration with Kubernetes made set-up easy. Once Helm installed Prometheus, "We started getting a graph of the health of all our Kubernetes nodes and pods immediately. I think we were pretty hooked at that point," Eynon-Lynch says. "Then we got our own custom instrumentation working in 15 minutes, and had an actively updated count of requests that we could do, rate on and get a sense of how many users are connected at a given point. And then it was another hour before we had alarms automatically showing up in our Slack channel. All that was in one afternoon. And it was an afternoon of gasping with delight, basically!"
+</div>
+</section>
+
+<div class="banner4">
+  <div class="banner4text">
+    "We started getting a graph of the health of all our Kubernetes nodes and pods immediately. I think we were pretty hooked at that point," Eynon-Lynch says. "Then we got our own custom instrumentation working in 15 minutes, and had an actively updated count of requests that we could do, rate on and get a sense of how many users are connected at a given point. And then it was another hour before we had alarms automatically showing up in our Slack channel. All that was in one afternoon. And it was an afternoon of gasping with delight, basically!"
+  </div>
+</div>
+
+<section class="section4">
+<div class="fullcol">
+  With Pear Deck’s specific challenges—traffic through Firebase as well as government firewalls—Prometheus was a game-changer. "We didn’t even realize how stressed out we were about our lack of insight into what was happening with the app," Eynon-Lynch says. Before, when a customer would report that the app wasn’t working, the team had to manually investigate the problem without knowing whether customers were affected all over the world, or whether Firebase was down, and where.<br><br>
+  To help solve that problem, the team wrote a script that pings Firebase from several different geographical locations, and then reports the responses to Prometheus in a histogram. "A huge impact that Prometheus had on us was just an amazing sigh of relief, of feeling like we knew what was happening," he says. "It took 45 minutes to implement [the Firebase alarm] because we knew that we had this trustworthy metrics platform in Prometheus. We weren’t going to have to figure out, ‘Where do we send these metrics? How do we aggregate the metrics? How do we understand them?’"<br><br>
+  Plus, Prometheus has allowed Pear Deck to build alarms for business goals. One measures the rate of successful app loads and goes off if the day’s loads are less than 90 percent of the loads from seven days before. "We run a JavaScript app behind ridiculous firewalls and all kinds of crazy browser extensions messing with it—Chrome will push a feature that breaks some CSS that we’re using," Eynon-Lynch says. "So that gives us a lot of confidence, and we at least know that people are still logging into the app and using it all the time."<br><br>
+  Now, when a customer complains, and none of the alarms have gone off, the team can feel confident that it’s not a widespread problem. "Just to be sure, we can go and double check the graphs and say, ‘Yep, there’s currently 10,000 people connected to that Firebase node. It’s definitely working. Let’s investigate your network settings, customer,’" he says. "And we can pass that back off to our support reps instead of the whole development team freaking out that Firebase is down."<br><br>
+  Pear Deck is also giving back to the community, building and open-sourcing a <a href="https://github.com/peardeck/prometheus-user-metrics">metrics aggregator</a> that enables end-user monitoring in Prometheus. "We can measure, for example, the time to interactive-dom on the web clients," he says. "The users all report that to our aggregator, then the aggregator reports to Prometheus. So we can set an alarm for some client side errors."<br><br>
+  Most of Pear Deck’s services have now been moved onto Kubernetes. And all of the team’s new code is going on Kubernetes. "Kubernetes lets us experiment with service configurations and stage them on a staging cluster all at once, and test different scenarios and talk about them as a development team looking at code, not just talking about the steps we would eventually take as humans," says Eynon-Lynch.
+</div>
+</section>
+
+<div class="banner5">
+  <div class="banner5text">
+    "A huge impact that Prometheus had on us was just an amazing sigh of relief, of feeling like we knew what was happening. It took 45 minutes to implement [the Firebase alarm] because we knew that we had this trustworthy metrics platform in Prometheus...in terms of the cloud, Kubernetes and Prometheus have so much to offer," he says.
+  </div>
+</div>
+
+<section class="section5">
+<div class="fullcol">
+  Looking ahead, the team is planning to explore autoscaling on Kubernetes. With users all over the world but mostly in the United States, there are peaks and valleys in the traffic. One service that’s still on App Engine can get as many as 10,000 requests a second during the day but far less at night. "We pay for the same servers at night, so I understand there’s autoscaling that we can be taking advantage of," he says. "Implementing it is a big worry, exposing the rest of our Kubernetes cluster to us and maybe messing that up. But it’s definitely our intention to move everything over, because now none of the developers want to work on that app anymore because it’s such a pain to deploy it."
+<br><br>
+They’re also eager to explore the work that Kubernetes is doing with stateful sets. "Right now all of the services we run in Kubernetes are stateless, and Google basically runs our databases for us and manages backups," Eynon-Lynch says. "But we’re interested in building our own web-socket solution that doesn’t have to be super stateful but will have maybe an hour’s worth of state on it."
+<br><br>
+That project will also involve Prometheus, for a dark launch of web socket connections. "We don’t know how reliable web socket connections behind all these horrible firewalls will be to our servers," he says. "We don’t know what work Firebase has done to make them more reliable. So I’m really looking forward to trying to get persistent connections with web sockets to our clients and have optional tools to understand if it’s working. That’s our next new adventure, into stateful servers."
+<br><br>
+As for Prometheus, Eynon-Lynch thinks the company has only gotten started. "We haven’t instrumented all our important features, especially those that depend on third parties," he says. "We have to wait for those third parties to tell us they’re down, which sometimes they don’t do for a long time. So I’m really excited and have more and more confidence in the actual state of our application for our actual users, and not just what the CPU graphs are saying, because of Prometheus and Kubernetes."
+<br><br>
+For a spry startup that’s continuing to grow rapidly—and yes, they’re <a href="https://www.peardeck.com/careers/">hiring</a>!—Pear Deck is notably satisfied with how its infrastructure has evolved in the cloud native ecosystem. "Usually I have some angsty thing where I want to get to the new, better technology," says Eynon-Lynch, "but in terms of the cloud, Kubernetes and Prometheus have so much to offer."
+
+  <br><br>
+</div>
+</section>

case-studies/wink.html

@@ -41,7 +41,7 @@ css: /css/style_wink.css
 
 <div class="banner2">
   <div class="banner2text">
-      "It’s not proprietary, it’s totally open, it’s really portable. You can run all the workloads across different cloud providers. You can easily run a hybrid AWS or even bring in your own data center. That’s the benefit of having everything unified on one  open source Kubernetes-Docker-CoreOS Container Linux stack. There’s massive security benefits if you only have one Linux distro/machine image to validate. The benefits are enormous because you save money, and you save time.”<br><br><span style="font-size:15px;letter-spacing:0.08em">- KIT KLEIN, HEAD OF ENGINEERING, WINK</span>
+      "It’s not proprietary, it’s totally open, it’s really portable. You can run all the workloads across different cloud providers. You can easily run a hybrid AWS or even bring in your own data center. That’s the benefit of having everything unified on one  open source Kubernetes-Docker-CoreOS Container Linux stack. There are massive security benefits if you only have one Linux distro/machine image to validate. The benefits are enormous because you save money, and you save time.”<br><br><span style="font-size:15px;letter-spacing:0.08em">- KIT KLEIN, HEAD OF ENGINEERING, WINK</span>
   </div>
 </div>
 
@@ -102,7 +102,7 @@ css: /css/style_wink.css
 
 <section class="section5">
   <div class="fullcol">
-    Wink’s reasons for going all in are clear: "It’s not proprietary, it’s totally open, it’s really portable,” Klein says. "You can run all the workloads across different cloud providers. You can easily run a hybrid AWS or even bring in your own data center. That’s the benefit of having everything unified on one Kubernetes-Docker-CoreOS Container Linux stack. There’s massive security benefits if you only have one Linux distro to try to validate. The benefits are enormous because you save money, you save time.”<br><br>
+    Wink’s reasons for going all in are clear: "It’s not proprietary, it’s totally open, it’s really portable,” Klein says. "You can run all the workloads across different cloud providers. You can easily run a hybrid AWS or even bring in your own data center. That’s the benefit of having everything unified on one Kubernetes-Docker-CoreOS Container Linux stack. There are massive security benefits if you only have one Linux distro to try to validate. The benefits are enormous because you save money, you save time.”<br><br>
     Klein concedes that there are tradeoffs in every technology decision. "Cutting-edge technology is going to be scary for some people,” he says. "In order to take advantage of this, you really have to keep up with the technology. You can’t treat it like it’s a black box. Stay close to the development. Understand why decisions are being made. If you understand the intent behind the project, from the technological intent to a certain philosophical intent, then it helps you understand how to build your system in harmony with those systems as opposed to trying to work against it.”<br><br>
     Wink, which was acquired by Flex in 2015, now controls 2.3 million connected devices in households all over the country. What’s next for the company? A new version of the hub - Wink Hub 2 - hit shelves last November – and is being offered for the first time at Walmart stores in addition to Home Depot. "Two of the biggest American retailers are carrying and promoting the brand and the hardware,” Klein says proudly – though he adds that "it really comes with a lot of pressure. It’s not a retail situation where you have a lot of tech enthusiasts. These are everyday people who want something that works and have no tolerance for technical excuses.” And that’s further testament to how much faith Klein has in the infrastructure that the Wink team has have built.<br><br>
     Wink’s engineering team has grown exponentially since its early days, and behind the scenes, Klein is most excited about the machine learning Wink is using. "We built [a system of] containerized small sections of the data pipeline that feed each other and can have multiple outputs,” he says. "It’s like data pipelines as microservices.” Again, Klein points to having a unified stack running on CoreOS Container Linux and Kubernetes as the primary driver for the innovations to come. "You’re not reinventing the wheel every time,” he says. "You can just get down to work.”  </div>

cn/README.md

@@ -7,11 +7,11 @@
 关于更多的贡献信息，请参阅:
 
 * [贡献于 Kubernetes 文档](http://kubernetes.io/editdocs/)
-* [创建文档拉取请求](http://kubernetes.io/docs/contribute/create-pull-request/)
+* [创建文档拉取请求](http://kubernetes.io/docs/home/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/)
+* [暂停您的文档更改](http://kubernetes.io/docs/home/contribute/stage-documentation-changes/)
+* [更用页面模板](http://kubernetes.io/docs/home/contribute/page-templates/)
+* [文档样式指南](http://kubernetes.io/docs/home/contribute/style-guide/)
 
 ## 谢谢您!
 

cn/_includes/templates/concept.md

@@ -0,0 +1,32 @@
+{% if overview %}
+
+{{ overview }}
+
+{% else %}
+
+{% include templates/_errorthrower.md missing_block='overview' purpose='provides an overview of this concept.' %}
+
+{% endif %}
+
+* TOC
+{:toc}
+
+{% if body %}
+
+{{ body }}
+
+{% else %}
+
+{% include templates/_errorthrower.md missing_block='body' purpose='supplies the body of the page content.' %}
+
+{% endif %}
+
+
+{% if whatsnext %}
+
+## 开始下一步
+
+{{ whatsnext }}
+
+{% endif %}
+

cn/docs/admin/accessing-the-api.md

@@ -0,0 +1,135 @@
+---
+approvers:
+- bgrant0607
+- erictune
+- lavalamp
+title: Kubernetes API访问控制
+---
+
+用户通过 `kubectl`、客户端库或者通过发送REST请求[访问API](/docs/user-guide/accessing-the-cluster)。 用户（自然人）和[Kubernetes服务账户](/docs/tasks/configure-pod-container/configure-service-account/) 都可以被授权进行API访问。
+请求到达API服务器后会经过几个阶段，具体说明如图：
+
+![Diagram of request handling steps for Kubernetes API request](/images/docs/admin/access-control-overview.svg)
+
+## 传输层安全
+
+在典型的Kubernetes集群中，API通过443端口提供服务。
+API服务器会提供一份证书。 该证书一般是自签名的， 所以用户机器上的 `$USER/.kube/config` 目录通常
+包含该API服务器证书的根证书，用来代替系统默认根证书。 当用户使用 `kube-up.sh` 创建集群时，该证书通常会被自动写入用户的`$USER/.kube/config`。  如果集群中存在多个用户，则创建者需要与其他用户共享证书。
+
+## 认证
+
+一旦 TLS 连接建立，HTTP请求就进入到了认证的步骤。即图中的步骤 **1** 。
+集群创建脚本或集群管理员会为API服务器配置一个或多个认证模块。
+更具体的认证相关的描述详见 [这里](/docs/admin/authentication/)。
+
+认证步骤的输入是整个HTTP请求，但这里通常只是检查请求头和/或客户端证书。
+
+认证模块支持客户端证书，密码和Plain Tokens，
+Bootstrap Tokens，以及JWT Tokens (用于服务账户)。
+
+（管理员）可以同时设置多种认证模块，在设置了多个认证模块的情况下，每个模块会依次尝试认证，
+直到其中一个认证成功。
+
+在 GCE 平台中，客户端证书，密码和Plain Tokens，Bootstrap Tokens，以及JWT Tokens同时被启用。
+
+如果请求认证失败，则请求被拒绝，返回401状态码。
+如果认证成功，则被认证为具体的 `username`，该用户名可供随后的步骤中使用。一些认证模块还提供了用户的组成员关系，另一些则没有。
+
+尽管Kubernetes使用 "用户名" 来进行访问控制和请求记录，但它实际上并没有 `user` 对象，也不存储用户名称或其他相关信息。
+
+## 授权
+
+当请求被认证为来自某个特定的用户后，该请求需要被授权。 即图中的步骤 **2** 。
+
+请求须包含请求者的用户名，请求动作，以及该动作影响的对象。 如果存在相应策略，声明该用户具有进行相应操作的权限，则该请求会被授权。
+
+例如，如果Bob有如下策略，那么他只能够读取`projectCaribou`命名空间下的pod资源：
+
+```json
+{
+    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
+    "kind": "Policy",
+    "spec": {
+        "user": "bob",
+        "namespace": "projectCaribou",
+        "resource": "pods",
+        "readonly": true
+    }
+}
+```
+如果Bob发起以下请求，那么请求能够通过授权，因为Bob被允许访问 `projectCaribou` 命名空间下的对象：
+
+```json
+{
+  "apiVersion": "authorization.k8s.io/v1beta1",
+  "kind": "SubjectAccessReview",
+  "spec": {
+    "resourceAttributes": {
+      "namespace": "projectCaribou",
+      "verb": "get",
+      "group": "unicorn.example.org",
+      "resource": "pods"
+    }
+  }
+}
+```
+如果Bob对 `projectCaribou` 命名空间下的对象发起一个写（`create` 或者 `update`）请求，那么它的授权会被拒绝。 如果Bob请求读取(`get`) 其他命名空间，例如 `projectFish`下的对象，其授权也会被拒绝。 
+
+Kubernetes的授权要求使用通用的REST属性与现有的组织或云服务提供商的访问控制系统进行交互。 采用REST格式是必要的，因为除Kubernetes外，这些访问控制系统还可能与其他的API进行交互。
+
+Kubernetes 支持多种授权模块，例如ABAC模式，RBAC模式和 Webhook模式。 管理员创建集群时，会配置API服务器应用的授权模块。 如果多种授权模式同时被启用，Kubernetes将检查所有模块，如果其中一种通过授权，则请求授权通过。 如果所有的模块全部拒绝，则请求被拒绝(HTTP状态码403)。
+
+要了解更多的Kubernetes授权相关信息，包括使用授权模块创建策略的具体说明等，可参考[授权概述](/docs/admin/authorization)。
+
+
+## 准入控制
+
+准入控制模块是能够修改或拒绝请求的软件模块。
+作为授权模块的补充，准入控制模块会访问被创建或更新的对象的内容。
+它们作用于对象的创建，删除，更新和连接 (proxy)阶段，但不包括对象的读取。
+
+可以同时配置多个准入控制器，它们会按顺序依次被调用。
+
+即图中的步骤 **3** 。
+
+与认证和授权模块不同的是，如果任一个准入控制器拒绝请求，那么整个请求会立即被拒绝。
+
+除了拒绝请求外，准入控制器还可以为对象设置复杂的默认值。
+
+可用的准入控制模块描述 [如下](/docs/admin/admission-controllers/)。
+
+一旦请求通过所有准入控制器，将使用对应API对象的验证流程对其进行验证，然后写入对象存储 (如步骤 **4**)。
+
+
+## API的端口和IP
+
+上述讨论适用于发送请求到API服务器的安全端口(典型情况)。  
+实际上API服务器可以通过两个端口提供服务：
+
+默认情况下，API服务器在2个端口上提供HTTP服务：
+
+  1. `Localhost Port`:
+
+          - 用于测试和启动，以及管理节点的其他组件
+            (scheduler, controller-manager)与API的交互
+          - 没有TLS
+          - 默认值为8080，可以通过 `--insecure-port` 标记来修改。
+          - 默认的IP地址为localhost， 可以通过 `--insecure-bind-address`标记来修改。
+          - 请求会 **绕过** 认证和鉴权模块。
+          - 请求会被准入控制模块处理。
+          - 其访问需要主机访问的权限。
+
+  2. `Secure Port`:
+
+          - 尽可能使用该端口访问
+          - 应用 TLS。 可以通过 `--tls-cert-file` 设置证书， 通过 `--tls-private-key-file` 设置私钥。
+          - 默认值为6443，可以通过 `--secure-port` 标记来修改。
+          - 默认IP是首个非本地的网络接口地址，可以通过 `--bind-address` 标记来修改。
+          - 请求会经过认证和鉴权模块处理。
+          - 请求会被准入控制模块处理。
+          - 要求认证和授权模块正常运行。
+
+通过 `kube-up.sh`创建集群时， 对 Google Compute Engine (GCE)
+和一些其他的云供应商来说， API通过443端口提供服务。 对
+GCE而言，项目上配置了防火墙规则，允许外部的HTTPS请求访问API，其他（厂商的）集群设置方法各不相同。

cn/docs/admin/authorization/abac.md

@@ -0,0 +1,141 @@
+---
+assignees:
+- erictune
+- lavalamp
+- deads2k
+- liggitt
+title: ABAC 模式
+---
+
+{% capture overview %}
+
+基于属性的访问控制（Attribute-based access control - ABAC）定义了访问控制范例，其中通过使用将属性组合在一起的策略来向用户授予访问权限。
+
+{% endcapture %}
+
+{% capture body %}
+
+## 策略文件格式
+
+基于 `ABAC` 模式，可以这样指定策略文件 `--authorization-policy-file=SOME_FILENAME`。
+
+此文件是 JSON 格式[每行都是一个JSON对象](http://jsonlines.org/)，不应存在封闭的列表或映射，每行只有一个映射。
+
+每一行都是一个 "策略对象"，策略对象是具有以下映射的属性:
+
+  - 版本控制属性:
+    - `apiVersion`，字符串类型: 有效值为"abac.authorization.kubernetes.io/v1beta1"，允许版本控制和转换策略格式。
+    - `kind`，字符串类型: 有效值为 "Policy"，允许版本控制和转换策略格式。
+  - `spec` 配置为具有以下映射的属性:
+    - 匹配属性:
+      - `user`，字符串类型; 来自 `--token-auth-file` 的用户字符串，如果你指定`user`，它必须与验证用户的用户名匹配。
+      - `group`，字符串类型; 如果指定`group`，它必须与经过身份验证的用户的一个组匹配，`system:authenticated`匹配所有经过身份验证的请求。`system:unauthenticated`匹配所有未经过身份验证的请求。
+  - 资源匹配属性:
+    - `apiGroup`，字符串类型; 一个 API 组。
+      - 例: `extensions`
+      - 通配符: `*`匹配所有 API 组。
+    - `namespace`，字符串类型; 一个命名空间。
+      - 例如: `kube-system`
+      - 通配符: `*` 匹配所有资源请求。
+    - `resource`，字符串类型; 资源类型。
+      - 例:`pods`
+      - 通配符: `*`匹配所有资源请求。
+  - 非资源匹配属性:
+    - `nonResourcePath`，字符串类型; 非资源请求路径。
+      - 例如:`/version`或`/apis`
+      - 通配符:
+        - `*` 匹配所有非资源请求。
+        - `/foo/*` 匹配`/foo/`的所有子路径。
+  - `readonly`，键入 boolean，如果为 true，则表示该策略仅适用于 get，list 和 watch 操作。
+
+**注意:** 未设置的属性与类型设置为零值的属性相同(例如空字符串，0、false)，然而未知的应该可读性优先。
+
+在将来，策略可能以 JSON 格式表示，并通过 REST 界面进行管理。
+
+## 授权算法
+
+请求具有与策略对象的属性对应的属性。
+
+当接收到请求时，确定属性。 未知属性设置为其类型的零值（例如: 空字符串，0，false）。
+
+设置为`“*"`的属性将匹配相应属性的任何值。
+
+检查属性的元组，以匹配策略文件中的每个策略。 如果至少有一行匹配请求属性，则请求被授权（但可能会在稍后验证失败）。
+
+要允许任何经过身份验证的用户执行某些操作，请将策略组属性设置为 `"system:authenticated“`。
+
+要允许任何未经身份验证的用户执行某些操作，请将策略组属性设置为`"system:authentication“`。
+
+要允许用户执行任何操作，请使用 apiGroup，命名空间，
+资源和 nonResourcePath 属性设置为 `“*"`的策略.
+
+要允许用户执行任何操作，请使用设置为`“*”` 的 apiGroup，namespace，resource 和 nonResourcePath 属性编写策略。
+
+## Kubectl
+
+Kubectl 使用 api-server 的 `/api` 和 `/apis` 端点进行协商客户端/服务器版本。 通过创建/更新来验证发送到API的对象操作，kubectl 查询某些 swagger 资源。 对于API版本"v1", 那就是`/swaggerapi/api/v1` ＆ `/swaggerapi/ experimental/v1`。
+
+当使用 ABAC 授权时，这些特殊资源必须明确通过策略中的 `nonResourcePath` 属性暴露出来(参见下面的[例子](#examples)):
+
+* `/api`，`/api/*`，`/apis`和`/apis/*` 用于 API 版本协商.
+* `/version` 通过 `kubectl version` 检索服务器版本.
+* `/swaggerapi/*` 用于创建/更新操作.
+
+要检查涉及到特定kubectl操作的HTTP调用，您可以调整详细程度：
+
+    kubectl --v=8 version
+
+## 例子
+
+1. Alice 可以对所有资源做任何事情:
+
+    ```json
+    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "alice", "namespace": "*", "resource": "*", "apiGroup": "*"}}
+    ```
+2. Kubelet 可以读取任何pod:
+
+    ```json
+    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "pods", "readonly": true}}
+    ```
+3. Kubelet 可以读写事件:
+
+    ```json
+    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "events"}}
+    ```
+4. Bob 可以在命名空间“projectCaribou"中读取 pod:
+
+    ```json
+    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "bob", "namespace": "projectCaribou", "resource": "pods", "readonly": true}}
+    ```
+5. 任何人都可以对所有非资源路径进行只读请求:
+
+    ```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": "*"}}
+    ```
+
+[完整文件示例](http://releases.k8s.io/{{page.githubbranch}}/pkg/auth/authorizer/abac/example_policy_file.jsonl)
+
+## 服务帐户的快速说明
+
+服务帐户自动生成用户。 用户名是根据命名约定生成的:
+
+```shell
+system:serviceaccount:<namespace>:<serviceaccountname>
+```
+创建新的命名空间也会导致创建一个新的服务帐户：
+
+```shell
+system:serviceaccount:<namespace>:default
+```
+
+例如，如果要将 API 的 kube-system 完整权限中的默认服务帐户授予，则可以将此行添加到策略文件中:
+
+```json
+{"apiVersion":"abac.authorization.kubernetes.io/v1beta1","kind":"Policy","spec":{"user":"system:serviceaccount:kube-system:default","namespace":"*","resource":"*","apiGroup":"*"}}
+```
+
+需要重新启动 apitorver 以获取新的策略行.
+
+{% endcapture %}
+{% include templates/concept.md %}

cn/docs/admin/authorization/index.md

@@ -0,0 +1,155 @@
+---
+assignees:
+- erictune
+- lavalamp
+- deads2k
+- liggitt
+title: 概述
+---
+
+{% capture overview %}
+
+学习有关 Kubernetes 授权的更多信息，包括有关使用支持的授权模块创建策略的详细信息。
+
+{% endcapture %}
+
+{% capture body %}
+
+在 Kubernetes 里，您必须经过身份验证(登录)，才能授权您的请求(授予访问权限).。有关认证的信息，请参阅[访问控制概述](/docs/admin/access-the-api/)。
+
+Kubernetes 提供通用的 REST API 请求。这意味着 Kubernetes 授权可以与现有的组织或云提供商的访问控制系统一起使用，该系统可以处理除 Kubernetes API 之外的其他 API。
+
+## 确定请求是允许还是被拒绝
+Kubernetes 使用 API​​ 服务器授权 API 请求。它根据所有策略评估所有请求属性，并允许或拒绝请求。某些策略必须允许 API 请求的所有部分继续进行，这意味着默认情况下是拒绝权限。
+
+(虽然 Kubernetes 使用 API ​​服务器，访问控制和依赖特定类型对象的特定领域策略由 Admission 控制器处理。)
+
+当配置多个授权模块时，按顺序检查每个模块，如果有任何模块授权请求，则可以继续执行该请求。如果所有模块拒绝请求，则拒绝该请求(HTTP状态代码403)。
+
+## 查看您的请求属性
+
+Kubernetes 仅查看以下API请求属性:
+
+* **user**  - 验证期间提供的 `user` 字符串
+* **group**  - 认证用户所属的组名列表
+* **“extra"**  - 由认证层提供的任意字符串键到字符串值的映射
+* **API**  - 指示请求是否用于API资源
+* **Request path**  - 诸如`/api`或`/healthz`的其他非资源端点的路径(请参阅[kubectl](#kubectl)).
+* **API request verb**  -  API 动词 `get`，`list`，`create`，`update`，`patch`，`watch`，`proxy`，`redirect`，`delete`和`deletecollection`用于资源请求。要确定资源 API 端点的请求动词，请参阅**确定下面的请求动词**.
+* **HTTP request verb**  -  HTTP动词`get`，`post`，`put`和`delete`用于非资源请求
+* **Resource**  - 正在访问的资源的ID或名称(仅适用于资源请求)
+ --* 对于使用`get`, `update`, `patch`, 和 `delete`动词的资源请求，您必须提供资源名称。
+* **Subresource**  - 正在访问的子资源(仅用于资源请求)
+* **Namespace**  - 正在被访问的对象的命名空间(仅针对命名空间的资源请求)
+* **API group**  - 正在访问的API组(仅用于资源请求). 一个空字符串指定[核心 API 组](/docs/api/).
+
+## 确定请求动词
+
+要确定资源 API 端点的请求动词，请查看所使用的HTTP动词以及请求是否对单个资源或资源集合进行操作:
+
+HTTP动词| 请求动词
+---------- | ---------------
+POST | 创建
+GET，HEAD | 获取(个人资源)，列表(集合)
+PUT | 更新
+PATCH | 补丁
+DELETE| 删除(个人资源)，删除(收藏)
+
+Kubernetes 有时会使用专门的动词检查授权以获得额外的权限。例如:
+
+* [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)在`extensions` API组中的`podsecuritypolicies`资源上检查`use`动词的授权。
+* [RBAC](/docs/admin/authorization/rbac/#privilege-escalation-prevention-and-bootstrapping) 在`rbac.authorization.k8s.io` API组中的`roles`和`clusterroles`资源上检查`bind`动词的授权。
+* [认证](/docs/admin/authentication/) 在核心API组中的`users`，`groups`和`serviceaccounts`上的`impersonate`动词的授权以及`authentication.k8s.io` API组中的`userextras`进行层次检查。
+
+## 授权模块
+* **ABAC模式**  - 基于属性的访问控制(ABAC)定义了访问控制范例，通过使用将属性组合在一起的策略来授予用户访问权限。策略可以使用任何类型的属性(用户属性，资源属性，对象，环境属性等)。要了解有关使用ABAC模式的更多信息，请参阅[ABAC模式](/docs/admin/authorization/abac/)
+* **RBAC模式**  - 基于角色的访问控制(RBAC)是一种根据企业内个人用户的角色来调整对计算机或网络资源的访问的方法。在这种情况下，访问是单个用户执行特定任务(例如查看，创建或修改文件)的能力。要了解有关使用RBAC模式的更多信息，请参阅[RBAC模式](/docs/admin/authorization/rbac/)
+*当指定 "RBAC"(基于角色的访问控制)使用 "rbac.authorization.k8s.io" API组来驱动授权决定时，允许管理员通过Kubernetes API动态配置权限策略.
+.. *截至1.6 RBAC模式是测试版.
+.. *要启用RBAC，请使用 `--authorization-mode=RBAC` 启动 apiserver.
+* **Webhook模式**  -  WebHook 是HTTP回调:发生事件时发生的HTTP POST; 通过HTTP POST简单的事件通知. 实施 WebHooks 的 Web 应用程序将在某些事情发生时向URL发送消息. 要了解有关使用Webhook模式的更多信息，请参阅[Webhook模式](/docs/admin/authorization/webhook/)
+* **自定义模块**  - 您可以创建使用Kubernetes的自定义模块. 要了解更多信息，请参阅下面的**自定义模块**。
+
+### 自定义模块
+可以相当容易地开发其他实现,APIserver 调用 Authorizer 接口：
+
+```go
+type Authorizer interface {
+  Authorize(a Attributes) error
+}
+```
+
+以确定是否允许每个API操作.
+
+授权插件是实现此接口的模块.授权插件代码位于 `pkg/auth/authorizer/$MODULENAME` 中。
+
+授权模块可以完全实现，也可以拨出远程授权服务。 授权模块可以实现自己的缓存，以减少具有相同或相似参数的重复授权调用的成本。 开发人员应该考虑缓存和撤销权限之间的交互。
+
+#### 检查API访问
+
+Kubernetes 将 `subjectaccessreviews.v1.authorization.k8s.io`  资源公开为允许外部访问API授权者决策的普通资源。 无论您选择使用哪个授权器，您都可以使用`SubjectAccessReview`发出一个`POST`，就像webhook授权器的`apis/authorization.k8s.io/v1/subjectaccessreviews` 端点一样，并回复一个响应。 例如：
+
+
+```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
+```
+
+这对于调试访问问题非常有用，因为您可以使用此资源来确定授权者授予哪些访问权限。
+
+## 为您的授权模块使用标志
+
+您的策略中必须包含一个标志，以指出您的策略包含哪个授权模块:
+
+可以使用以下标志:
+ - `--authorization-mode=ABAC` 基于属性的访问控制(ABAC)模式允许您使用本地文件配置策略。
+ - `--authorization-mode=RBAC` 基于角色的访问控制(RBAC)模式允许您使用Kubernetes API创建和存储策略.
+ - `--authorization-mode=Webhook` WebHook是一种HTTP回调模式，允许您使用远程REST管理授权。
+ - `--authorization-mode=AlwaysDeny` 此标志阻止所有请求. 仅使用此标志进行测试。
+ - `--authorization-mode=AlwaysAllow` 此标志允许所有请求. 只有在您不需要API请求授权的情况下才能使用此标志。
+
+您可以选择多个授权模块. 如果其中一种模式为 `AlwaysAllow`，则覆盖其他模式，并允许所有API请求。
+
+## 版本控制
+
+对于版本 1.2，配置了 kube-up.sh 创建的集群，以便任何请求都不需要授权。
+
+从版本 1.3 开始，配置由 kube-up.sh 创建的集群，使得 ABAC 授权模块处于启用状态。但是，其输入文件最初设置为允许所有用户执行所有操作，集群管理员需要编辑该文件，或者配置不同的授权器来限制用户可以执行的操作。
+
+{% endcapture %}
+{% capture whatsnext %}
+
+* 要学习有关身份验证的更多信息，请参阅**身份验证**[控制访问 Kubernetes API](docs/admin/access-the-api/)。
+* 要了解有关入学管理的更多信息，请参阅[使用 Admission 控制器](docs/admin/admission-controllers/)。
+*
+{% endcapture %}
+
+{% include templates/concept.md %}

cn/docs/admin/daemon.yaml

@@ -0,0 +1,18 @@
+apiVersion: extensions/v1beta1 
+kind: DaemonSet
+metadata:
+  name: prometheus-node-exporter
+spec:
+  template:
+    metadata:
+      name: prometheus-node-exporter
+      labels:
+        daemon: prom-node-exp
+    spec:
+      containers:
+      - name: c
+        image: prom/prometheus
+        ports:
+        - containerPort: 9090
+          hostPort: 9090
+          name: serverport

cn/docs/admin/high-availability/index.md

@@ -0,0 +1,215 @@
+---
+title: 构建高可用集群
+---
+
+
+## 简介
+
+
+本文描述了如何构建一个高可用（high-availability, HA）的Kubernetes集群。这是一个非常高级的主题。
+
+对于仅希望使用Kubernetes进行试验的用户，推荐使用更简单的配置工具进行搭建，例如：
+[Minikube](/docs/getting-started-guides/minikube/)，或者尝试使用[Google Container Engine](https://cloud.google.com/container-engine/) 来运行Kubernetes。
+
+此外，当前在我们的端到端（e2e）测试环境中，没有对Kubernetes高可用的支持进行连续测试。我们将会增加这个连续测试项，但当前对单节点master的安装测试得更加严格。
+
+* TOC
+{:toc}
+
+## 概览
+
+
+搭建一个正真可靠，高度可用的分布式系统需要若干步骤。这类似于穿上内衣，裤子，皮带，背带，另一套内衣和另一套裤子。我们会详细介绍每一个步骤，但先在这里给出一个总结来帮助指导用户。
+
+
+相关步骤如下：
+
+   * [创建可靠的组成节点，共同形成我们的高可用主节点实现。](#可靠的节点)
+   * [使用etcd集群，搭建一个冗余的，可靠的存储层。](#建立一个冗余的，可靠的存储层)
+   * [启动具有备份和负载均衡能力的Kubernetes API 服务](#复制的API服务)
+   * [搭建运行master选举的Kubernetes scheduler和controller-manager守护程序](#进行master选举的组件)
+  
+系统完成时看起来应该像这样：
+
+![High availability Kubernetes diagram](/images/docs/ha.svg)
+
+
+## 初始配置
+
+
+本文假设你正在搭建一个3节点的主节点集群，每个节点上都运行者某种Linux系统。
+
+指南中的示例使用Debian发行版，但它们应该可以被轻松移植到其他发行版上。
+
+同样的，不管在公有云还是私有云亦或是裸机上，这个配置都应该可以运行。
+
+
+从一个现成的单主节点集群开始是实现一个高可用Kubernetes集群的最简单的方法。这篇指导 [https://get.k8s.io](https://get.k8s.io) 描述了在多种平台上方便的安装一个单主节点集群的方法。
+
+## 可靠的节点
+
+
+我们在每个主节点上都将运行数个实现Kubernetes API的进程。使他们可靠的第一步是保证在发生故障时，每一个进程都可以自动重启。为了实现这个目标，我们需要安装一个进程监视器。我们选择了在每个工作者节点上都会运行的`kubelet`进程。这会带来便利性，因为我们使用了容器来分发我们的二进制文件，所以我们能够为每一个守护程序建立资源限制并省查它们的资源消耗。当然，我们也需要一些手段来监控kubelete本身（在此监测监控者本身是一个有趣的话题）。对于Debian系统我们选择了monit，但也有许多可替代的工具。例如在基于systemd的系统上（如RHEL, CentOS），你可以运行 'systemctl enable kubelet'。
+
+
+如果你是从标准的Kubernetes安装扩展而来，那么`kubelet`二进制文件应该已经存在于你的系统中。你可以运行`which kubelet`来判断是否确实安装了这个二进制文件。如果没有安装的话，你应该手动安装 [kubelet binary](https://storage.googleapis.com/kubernetes-release/release/v0.19.3/bin/linux/amd64/kubelet), 
+[kubelet init file](http://releases.k8s.io/{{page.githubbranch}}/cluster/saltbase/salt/kubelet/initd) 和 [default-kubelet](/docs/admin/high-availability/default-kubelet)脚本。
+
+如果使用monit，你还需要安装monit守护程序（`apt-get install monit`）以及[monit-kubelet](/docs/admin/high-availability/monit-kubelet) 和
+[monit-docker](/docs/admin/high-availability/monit-docker) 配置。
+
+在使用systemd的系统上，你可以执行 `systemctl enable kubelet` 和 `systemctl enable docker`。
+
+
+## 建立一个冗余的，可靠的存储层
+
+
+高可用方案的中心基础是一个冗余的，可靠的存储层。高可用的头条规则是保护数据。不管发生了什么，不管什么着了火，只要还有数据，你就可以重建。如果丢掉了数据，你就完了。
+
+
+集群化的etcd已经把你存储的数据复制到了你集群中的所有主节点实例上。这意味着如果要想丢失数据，三个节点的物理（或虚拟）硬盘需要全部同时故障。这种情况发生的概率是比较低的，所以对于许多人来说，运行一个复制的etcd集群可能已经足够的可靠了。你可以将集群数量从3个增大到5个来增加集群的可靠性。如果那样还不够，你可以添加[更多的可靠性到你的存储层](#更加可靠的存储)。
+
+
+### 集群化etcd
+
+
+集群化etcd的完整细节超出了本文范围，你可以在[etcd clustering page](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/clustering.md)找到许多详细内容。这个例子仅走查一个简单的集群建立过程，使用etcd内置的发现功能来构建我们的集群。
+
+
+首先，调用etcd发现服务来创建一个新令牌:
+
+```shell
+curl https://discovery.etcd.io/new?size=3
+```
+
+
+在每个节点上，拷贝 [etcd.yaml](/docs/admin/high-availability/etcd.yaml) 文件到`/etc/kubernetes/manifests/etcd.yaml`。
+
+
+每个节点上的kubelet会动态的监控这个文件夹的内容，并且会按照`etcd.yaml`里对pod的定义创建一个`etcd`服务的实例。
+
+
+请注意，你应该使用上文中获取的令牌URL替换全部三个节点上`etcd.yaml`中的`${DISCOVERY_TOKEN}`项。同时还应该将每个节点上的 `${NODE_NAME}`替换为一个不同的名字（例如：`node-1`），并将 `${NODE_IP}`替换为正确的IP地址。
+
+
+#### 验证你的集群
+
+
+如果已经将这个文件拷贝到所有三个节点，你应该已经搭建起了一个集群化的etcd。你可以在主节点上进行验证：
+```shell
+kubectl exec < pod_name > etcdctl member list
+```
+
+和
+
+```shell
+kubectl exec < pod_name > etcdctl cluster-health
+```
+
+
+你也可以在一个节点上运行 `etcdctl set foo bar`，在另一个节点上运行`etcdctl get foo`来验证集群是否工作正常。
+
+
+### 更加可靠的存储
+
+
+当然，如果你对增加数据的可靠性感兴趣，这里还有一些更深入的选项可以使etcd把它的数据存放在比常规硬盘更可靠的地方（裤带和背带，ftw!）。
+
+
+如果你使用云服务，那么你的提供商通常会为你提供这个特性，例如Google Cloud Platform上的 [Persistent Disk](https://cloud.google.com/compute/docs/disks/persistent-disks) 。它们是可以挂载到你的虚拟机中的块设备持久化存储。其他的云服务提供商提供了类似的解决方案。
+
+
+如果运行于物理机之上，你仍然可以使用iSCSI或者NFS接口通过网络来连接冗余存储。
+此外，你还可以运行一个集群文件系统，比如Gluster或者Ceph。最后，你还可以在你的每个物理机器上运行RAID矩阵。
+
+
+不管你选择如何实现，如果已经选择了使用其中的一个选项，那么你应该保证你的存储被挂载到了每一台机器上。如果你的存储在集群中的三个主节点之间共享，那么你应该在存储上为每一个节点创建一个不同的文件夹。对于所有的这些指导，我们都假设这个存储被挂载到你机器上的`/var/etcd/data`路径。
+
+
+## 复制的API服务
+
+
+在正确搭建复制的etcd之后，我们还需要使用kubelet安装apiserver。
+
+
+
+
+首先，你需要创建初始的日志文件，这样Docker才会挂载一个文件而不是一个文件夹：
+```shell
+touch /var/log/kube-apiserver.log
+```
+
+接下来，你需要在每个节点上创建一个`/srv/kubernetes/`文件夹。这个文件夹包含：
+
+   * basic_auth.csv  - 基本认证的用户名和密码
+   * ca.crt - CA证书
+   * known_tokens.csv - 实体（例如kubelet）用来和apiserver通信的令牌
+   * kubecfg.crt - 客户端证书，公钥
+   * kubecfg.key - 客户端证书，私钥
+   * server.cert - 服务端证书，公钥
+   * server.key - 服务端证书，私钥
+
+
+创建这个文件夹最简单的方法可以是从一个工作正常的集群的主节点拷贝，或者你也可以手动生成它们。
+
+
+### 启动API服务
+
+
+一旦这些文件已经存在了，拷贝 [kube-apiserver.yaml](/docs/admin/high-availability/kube-apiserver.yaml) 到每个主节点的 `/etc/kubernetes/manifests/`文件夹。
+
+
+kubelet会监控这个文件夹，并且会按照文件里对pod的定义创建一个`kube-apiserver`容器。
+
+
+### 负载均衡
+
+
+现在，你应该有3个全部正常工作的apiserver了。如果搭建了网络负载均衡器，你应该能够通过那个负载均衡器访问你的集群，并且看到负载在apiserver实例间分发。设置负载均衡器依赖于你的平台的实际情况，例如对于Google Cloud Platform的指导可以在[这里](https://cloud.google.com/compute/docs/load-balancing/)找到。
+
+
+请注意，如果使用了身份认证，你可能需要重新生成你的证书，除每个节点的IP地址外额外包含负载均衡器的IP地址。
+
+
+对于部署在集群中的pods， `kubernetes`服务/dns名称应该自动的为主节点提供了负载均衡的endpoint。
+
+
+对于使用API的外部用户（如命令行运行的`kubectl`，持续集成管道或其他客户端）你会希望将他们配置成为访问外部负载均衡器的地址。
+
+
+## 进行Master选举的组件
+
+
+到目前为止，我们已经搭建了状态存储，也搭建好了API服务，但我们还没有运行任何真正改变集群状态的服务，比如controller manager和scheduler。为了可靠的实现这个目标，我们希望在同一时间只有一个参与者在修改集群状态。但是我们希望复制这些参与者的实例以防某个机器宕机。要做到这一点，我们打算在API中使用一个lease-lock来执行master选举。我们会对每一个scheduler和controller-manager使用`--leader-elect`标志，从而在API中使用一个租约来保证同一时间只有一个scheduler和controller-manager的实例正在运行。
+
+
+scheduler和controller-manager可以配置为只和位于它们相同节点（即127.0.0.1）上的API服务通信，也可以配置为使用API服务的负载均衡器的IP地址。不管它们如何配置，当使用`--leader-elect` 时scheduler和controller-manager都将完成上文提到的leader选举过程。
+
+
+为了防止访问API服务失败，选举出的leader不能通过更新租约来选举一个新的leader。当scheduler和controller-manager通过127.0.0.1访问API服务，而相同节点上的API服务不可用时，这一点相当重要。
+
+
+### 安装配置文件
+
+
+首先，在每个节点上创建空白日志文件，这样Docker就会挂载这些文件而不是创建一个新文件夹：
+
+```shell
+touch /var/log/kube-scheduler.log
+touch /var/log/kube-controller-manager.log
+```
+
+
+接下来，在每个节点上配置scheduler和controller manager pods的描述文件。拷贝 [kube-scheduler.yaml](/docs/admin/high-availability/kube-scheduler.yaml) 和 [kube-controller-manager.yaml](/docs/admin/high-availability/kube-controller-manager.yaml) 到`/etc/kubernetes/manifests/` 文件夹。
+
+
+## 结尾
+
+
+此时，你已经完成了master组件的配置（耶！），但你还需要添加工作者节点（噗！）。
+
+
+如果你有一个现成的集群，你只需要在每个节点上简单的重新配置你的kubeletes连接到负载均衡的endpoint并重启它们。
+
+
+如果你搭建的是一个全新的集群，你将需要在每个工作节点上安装kubelet和kube-proxy，并设置 `--apiserver`指向复制的endpoint。

cn/docs/admin/kube-apiserver.md

@@ -0,0 +1,233 @@
+---
+title: kube-apiserver
+notitle: true
+---
+## kube-apiserver
+
+
+
+### 概要
+
+
+Kubernetes API server 为 api 对象验证并配置数据，包括 pods、 services、 replicationcontrollers和其它 api 对象。API Server 提供 REST 操作和到集群共享状态的前端，所有其他组件通过它进行交互。
+
+```
+kube-apiserver
+```
+
+### 选项
+```
+
+      --admission-control stringSlice                           控制资源进入集群的准入控制插件的顺序列表。逗号分隔的NamespaceLifecycle列表。(默认值[AlwaysAdmit])
+
+      --admission-control-config-file string                    包含准入控制配置的文件。
+
+      --advertise-address ip                                    向集群成员通知apiserver消息的IP地址。这个地址必须能够被集群中其他成员访问。如果IP地址为空，将会使用--bind-address，如果未指定--bind-address，将会使用主机的默认接口地址。
+
+      --allow-privileged                                        如果为true, 将允许特权容器.
+
+      --anonymous-auth                                          启用到API server的安全端口的匿名请求。未被其他认证方法拒绝的请求被当做匿名请求。匿名请求的用户名为system:anonymous，用户组名为system:unauthenticated。（默认值true）
+
+      --apiserver-count int                                     集群中运行的apiserver数量，必须为正数。（默认值1）
+
+      --audit-log-maxage int                                    基于文件名中的时间戳，旧审计日志文件的最长保留天数。
+
+      --audit-log-maxbackup int                                 旧审计日志文件的最大保留个数.
+
+      --audit-log-maxsize int                                   审计日志被轮转前的最大兆字节数。
+
+      --audit-log-path string                                   如果设置该值，所有到apiserver的请求都将会被记录到这个文件。'-'表示记录到标准输出。
+
+      --audit-policy-file string                                定义审计策略配置的文件的路径。需要打开'AdvancedAuditing'特性开关。AdvancedAuditing需要一个配置来启用审计功能。
+
+      --audit-webhook-config-file string                        一个具有kubeconfig格式文件的路径，该文件定义了审计的webhook配置。需要打开'AdvancedAuditing'特性开关。
+
+      --audit-webhook-mode string                               发送审计事件的策略。 Blocking模式表示正在发送事件时应该阻塞服务器的响应。 Batch模式使webhook异步缓存和发送事件。 Known模式为batch,blocking。 （默认值"batch")
+
+      --authentication-token-webhook-cache-ttl duration         从webhook令牌认证者获取的响应的缓存时长。(默认值2m0s)
+
+      --authentication-token-webhook-config-file string         包含webhook配置的文件，用于令牌认证，具有kubeconfig格式。API server将查询远程服务来决定对bearer令牌的认证。
+
+      --authorization-mode string                               在安全端口上进行权限验证的插件的顺序列表。以逗号分隔的列表，包括：AlwaysAllow,AlwaysDeny,ABAC,Webhook,RBAC,Node.（默认值"AlwaysAllow"）
+ 
+      --authorization-policy-file string                        包含权限验证策略的csv文件，和--authorization-mode=ABAC一起使用，作用在安全端口上。
+ 
+      --authorization-webhook-cache-authorized-ttl duration     从webhook授权者获得的'authorized'响应的缓存时长。（默认值5m0s） 
+ 
+      --authorization-webhook-cache-unauthorized-ttl duration   从webhook授权者获得的'unauthorized'响应的缓存时长。（默认值30s）
+ 
+      --authorization-webhook-config-file string                包含webhook配置的kubeconfig格式文件，和--authorization-mode=Webhook一起使用。API server将查询远程服务来决定对API server安全端口的访问。
+ 
+      --azure-container-registry-config string                  包含Azure容器注册表配置信息的文件的路径。
+
+      --basic-auth-file string                                  如果设置该值，这个文件将会被用于准许通过http基本认证到API server安全端口的请求。
+
+      --bind-address ip                                         监听--seure-port的IP地址。被关联的接口必须能够被集群其它节点和CLI/web客户端访问。如果为空，则将使用所有接口（0.0.0.0）。（默认值0.0.0.0）
+
+      --cert-dir string                                         存放TLS证书的目录。如果提供了--tls-cert-file和--tls-private-key-file选项，该标志将被忽略。（默认值 "/var/run/kubernetes"）
+
+      --client-ca-file string                                   如果设置此标志，对于任何请求，如果存包含client-ca-file中的authorities签名的客户端证书，将会使用客户端证书中的CommonName对应的身份进行认证。
+ 
+      --cloud-config string                                     云服务提供商配置文件路径。空字符串表示无配置文件.
+ 
+      --cloud-provider string                                   云服务提供商，空字符串表示无提供商。
+ 
+      --contention-profiling                                    如果已经启用profiling，则启用锁竞争profiling。
+
+      --cors-allowed-origins stringSlice                        CORS的域列表，以逗号分隔。合法的域可以是一个匹配子域名的正则表达式。如果这个列表为空则不会启用CORS.
+
+      --delete-collection-workers int                           用于DeleteCollection调用的工作者数量。这被用于加速namespace的清理。(默认值1)
+
+      --deserialization-cache-size int                          在内存中缓存的反序列化json对象的数量。
+
+      --enable-aggregator-routing                               打开到endpoints IP的aggregator路由请求，替换cluster IP。
+
+      --enable-garbage-collector                                启用通用垃圾回收器. 必须与kube-controller-manager对应的标志保持同步。 （默认值true）
+
+      --enable-logs-handler                                     如果为true，则为apiserver日志功能安装一个/logs处理器。（默认值true）
+
+      --enable-swagger-ui                                       在apiserver的/swagger-ui路径启用swagger ui。
+
+      --etcd-cafile string                                      用于保护etcd通信的SSL CA文件。
+
+      --etcd-certfile string                                    用于保护etcd通信的的SSL证书文件。
+
+      --etcd-keyfile string                                     用于保护etcd通信的SSL密钥文件.
+
+      --etcd-prefix string                                      附加到所有etcd中资源路径的前缀。 （默认值"/registry"）
+
+      --etcd-quorum-read                                        如果为true, 启用quorum读。
+
+      --etcd-servers stringSlice                                连接的etcd服务器列表,形式为（scheme://ip:port)，使用逗号分隔。
+
+      --etcd-servers-overrides stringSlice                      针对单个资源的etcd服务器覆盖配置, 以逗号分隔。 单个配置覆盖格式为: group/resource#servers, 其中servers形式为http://ip:port, 以分号分隔。
+
+      --event-ttl duration                                      事件驻留时间。（默认值1h0m0s)
+
+      --experimental-bootstrap-token-auth                       启用此选项以允许'kube-system'命名空间中的'bootstrap.kubernetes.io/token'类型密钥可以被用于TLS的启动认证。
+
+      --experimental-encryption-provider-config string          包含加密提供程序的配置的文件，该加密提供程序被用于在etcd中保存密钥。
+
+      --experimental-keystone-ca-file string                    如果设置该值，将会使用experimental-keystone-ca-file中的一个authority对Keystone服务的证书进行验证，否则将会使用主机的根CA进行验证。
+
+      --experimental-keystone-url string                        如果设置了该值，将启用keystone认证插件。
+
+      --external-hostname string                                为此master生成外部URL时使用的主机名(例如Swagger API文档)。
+
+      --feature-gates mapStringBool                             一个描述alpha/experimental特性开关的键值对列表。 选项包括:
+Accelerators=true|false (ALPHA - default=false)
+AdvancedAuditing=true|false (ALPHA - default=false)
+AffinityInAnnotations=true|false (ALPHA - default=false)
+AllAlpha=true|false (ALPHA - default=false)
+AllowExtTrafficLocalEndpoints=true|false (default=true)
+AppArmor=true|false (BETA - default=true)
+DynamicKubeletConfig=true|false (ALPHA - default=false)
+DynamicVolumeProvisioning=true|false (ALPHA - default=true)
+ExperimentalCriticalPodAnnotation=true|false (ALPHA - default=false)
+ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
+LocalStorageCapacityIsolation=true|false (ALPHA - default=false)
+PersistentLocalVolumes=true|false (ALPHA - default=false)
+RotateKubeletClientCertificate=true|false (ALPHA - default=false)
+RotateKubeletServerCertificate=true|false (ALPHA - default=false)
+StreamingProxyRedirects=true|false (BETA - default=true)
+TaintBasedEvictions=true|false (ALPHA - default=false)
+
+      --google-json-key string                                  用于认证的Google Cloud Platform服务账号的JSON密钥。
+
+      --insecure-allow-any-token username/group1,group2         如果设置该值, 你的服务将处于非安全状态。任何令牌都将会被允许，并将从令牌中把用户信息解析成为username/group1,group2。
+
+      --insecure-bind-address ip                                用于监听--insecure-port的IP地址 (设置成0.0.0.0表示监听所有接口)。（默认值127.0.0.1)
+
+      --insecure-port int                                       用于监听不安全和为认证访问的端口。这个配置假设你已经设置了防火墙规则，使得这个端口不能从集群外访问。对集群的公共地址的443端口的访问将被代理到这个端口。默认设置中使用nginx实现。（默认值8080）
+
+      --kubelet-certificate-authority string                    证书authority的文件路径。
+
+      --kubelet-client-certificate string                       用于TLS的客户端证书文件路径。
+
+      --kubelet-client-key string                               用于TLS的客户端证书密钥文件路径.
+
+      --kubelet-https                                           为kubelet启用https。 （默认值true）
+
+      --kubelet-preferred-address-types stringSlice             用于kubelet连接的首选NodeAddressTypes列表。 (默认值[Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP])
+
+      --kubelet-read-only-port uint                             已废弃: kubelet端口. （默认值10255）
+
+      --kubelet-timeout duration                                kubelet操作超时时间。（默认值 
+      5s）
+
+      --kubernetes-service-node-port int                        如果不为0，Kubernetes master服务（用于创建/管理apiserver）将会使用NodePort类型，并将这个值作为端口号。如果为0，Kubernetes master服务将会使用ClusterIP类型。
+
+      --master-service-namespace string                         已废弃: 注入到pod中的kubernetes master服务的命名空间。（默认值"default"） 
+
+      --max-connection-bytes-per-sec int                        如果不为0，每个用户连接将会被限速为该值（bytes/sec）。当前只应用于长时间运行的请求。
+
+      --max-mutating-requests-inflight int                      在给定时间内进行中可变请求的最大数量。当超过该值时，服务将拒绝所有请求。0值表示没有限制。（默认值200）
+
+      --max-requests-inflight int                               在给定时间内进行中不可变请求的最大数量。当超过该值时，服务将拒绝所有请求。0值表示没有限制。（默认值400）
+
+      --min-request-timeout int                                 一个可选字段，表示一个handler在一个请求超时前，必须保持它处于打开状态的最小秒数。当前只对监听请求handler有效，它基于这个值选择一个随机数作为连接超时值，以达到分散负载的目的（默认值1800）。
+      
+      --oidc-ca-file string                                    如果设置该值，将会使用oidc-ca-file中的任意一个authority对OpenID服务的证书进行验证，否则将会使用主机的根CA对其进行验证。
+      
+      --oidc-client-id string                                   使用OpenID连接的客户端的ID，如果设置了oidc-issuer-url，则必须设置这个值。
+       
+      --oidc-groups-claim string                                如果提供该值，这个自定义OpenID连接名将指定给特定的用户组。该声明值需要是一个字符串或字符串数组。此标志为实验性的，请查阅验证相关文档进一步了解详细信息。
+
+      --oidc-issuer-url string                                  OpenID颁发者URL，只接受HTTPS方案。如果设置该值，它将被用于验证OIDC JSON Web Token(JWT)。
+      
+      --oidc-username-claim string                              用作用户名的OpenID声明值。注意，不保证除默认 ('sub')外的其他声明值的唯一性和不变性。此标志为实验性的，请查阅验证相关文档进一步了解详细信息。
+       
+      --profiling                                               在web接口host:port/debug/pprof/上启用profiling。（默认值true）
+       
+      --proxy-client-cert-file string                           当必须调用外部程序时，用于证明aggregator或者kube-apiserver的身份的客户端证书。包括代理到用户api-server的请求和调用webhook准入控制插件的请求。它期望这个证书包含一个来自于CA中的--requestheader-client-ca-file标记的签名。该CA在kube-system命名空间的'extension-apiserver-authentication' configmap中发布。从Kube-aggregator收到调用的组件应该使用该CA进行他们部分的双向TLS验证。
+ 
+      --proxy-client-key-file string                            当必须调用外部程序时，用于证明aggregator或者kube-apiserver的身份的客户端证书密钥。包括代理到用户api-server的请求和调用webhook准入控制插件的请求。
+      
+      --repair-malformed-updates                                如果为true，服务将会尽力修复更新请求以通过验证，例如：将更新请求UID的当前值设置为空。在我们修复了所有发送错误格式请求的客户端后，可以关闭这个标志。
+
+      --requestheader-allowed-names stringSlice                 使用--requestheader-username-headers指定的，允许在头部提供用户名的客户端证书通用名称列表。如果为空，任何通过--requestheader-client-ca-file中authorities验证的客户端证书都是被允许的。
+      
+      --requestheader-client-ca-file string                     在信任请求头中以--requestheader-username-headers指示的用户名之前，用于验证接入请求中客户端证书的根证书捆绑。
+      
+      --requestheader-extra-headers-prefix stringSlice          用于检查的请求头的前缀列表。建议使用X-Remote-Extra-。
+
+      --requestheader-group-headers stringSlice                 用于检查群组的请求头列表。建议使用X-Remote-Group.
+       
+      --requestheader-username-headers stringSlice              用于检查用户名的请求头列表。建议使用X-Remote-User。
+       
+      --runtime-config mapStringString                          传递给apiserver用于描述运行时配置的键值对集合。 apis/<groupVersion>键可以被用来打开/关闭特定的api版本。apis/<groupVersion>/<resource>键被用来打开/关闭特定的资源. api/all和api/legacy键分别用于控制所有的和遗留的api版本.
+        
+      --secure-port int                                         用于监听具有认证授权功能的HTTPS协议的端口。如果为0，则不会监听HTTPS协议。 （默认值6443)
+       
+      --service-account-key-file stringArray                    包含PEM加密的x509 RSA或ECDSA私钥或公钥的文件，用于验证ServiceAccount令牌。如果设置该值，--tls-private-key-file将会被使用。指定的文件可以包含多个密钥，并且这个标志可以和不同的文件一起多次使用。
+      
+      --service-cluster-ip-range ipNet                          CIDR表示的IP范围，服务的cluster ip将从中分配。 一定不要和分配给nodes和pods的IP范围产生重叠。
+      
+      --ssh-keyfile string                                      如果不为空，在使用安全的SSH代理访问节点时，将这个文件作为用户密钥文件。
+      
+      --storage-backend string                                  持久化存储后端。 选项为: 'etcd3' (默认), 'etcd2'.
+     
+      --storage-media-type string                               在存储中保存对象的媒体类型。某些资源或者存储后端可能仅支持特定的媒体类型，并且忽略该配置项。（默认值 "application/vnd.kubernetes.protobuf")
+      
+      --storage-versions string                                 按组划分资源存储的版本。 以"group1/version1,group2/version2,..."的格式指定。当对象从一组移动到另一组时, 你可以指定"group1=group2/v1beta1,group3/v1beta1,..."的格式。你只需要传入你希望从结果中改变的组的列表。默认为从KUBE_API_VERSIONS环境变量集成而来，所有注册组的首选版本列表。 （默认值"admission.k8s.io/v1alpha1,admissionregistration.k8s.io/v1alpha1,apps/v1beta1,authentication.k8s.io/v1,authorization.k8s.io/v1,autoscaling/v1,batch/v1,certificates.k8s.io/v1beta1,componentconfig/v1alpha1,extensions/v1beta1,federation/v1beta1,imagepolicy.k8s.io/v1alpha1,networking.k8s.io/v1,policy/v1beta1,rbac.authorization.k8s.io/v1beta1,settings.k8s.io/v1alpha1,storage.k8s.io/v1,v1")
+      
+      --target-ram-mb int                                       apiserver内存限制，单位为MB(用于配置缓存大小等)。
+      
+      --tls-ca-file string                                      如果设置该值，这个证书authority将会被用于从Admission Controllers过来的安全访问。它必须是一个PEM加密的合法CA捆绑包。此外, 该证书authority可以被添加到以--tls-cert-file提供的证书文件中.
+      
+      --tls-cert-file string                                    包含用于HTTPS的默认x509证书的文件。（如果有CA证书，则附加于server证书之后）。如果启用了HTTPS服务，并且没有提供--tls-cert-file和--tls-private-key-file，则将为公共地址生成一个自签名的证书和密钥并保存于/var/run/kubernetes目录。
+      
+      --tls-private-key-file string                             包含匹配--tls-cert-file的x509证书私钥的文件。
+      
+      --tls-sni-cert-key namedCertKey                           一对x509证书和私钥的文件路径, 可以使用符合正式域名的域形式作为后缀。 如果没有提供域形式后缀, 则将提取证书名。 非通配符版本优先于通配符版本, 显示的域形式优先于证书中提取的名字。 对于多个密钥/证书对, 请多次使用--tls-sni-cert-key。例如: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com". （默认值[])
+      
+      --token-auth-file string                                  如果设置该值，这个文件将被用于通过令牌认证来保护API服务的安全端口。
+      
+      --version version[=true]                                  打印版本信息并退出。
+      
+      --watch-cache                                             启用apiserver的监视缓存。（默认值true）
+      
+      --watch-cache-sizes stringSlice                           每种资源（pods, nodes等）的监视缓存大小列表，以逗号分隔。每个缓存配置的形式为：resource#size，size是一个数字。在watch-cache启用时生效。
+```
+
+###### Auto generated by spf13/cobra on 11-Jul-2017

cn/docs/admin/kubelet-authentication-authorization.md

@@ -0,0 +1,87 @@
+---
+approvers:
+- liggitt
+title: Kubelet authentication/authorization
+---
+
+* TOC
+{:toc}
+
+## Overview
+
+A kubelet's HTTPS endpoint exposes APIs which give access to data of varying sensitivity,
+and allow you to perform operations with varying levels of power on the node and within containers.
+
+This document describes how to authenticate and authorize access to the kubelet's HTTPS endpoint.
+
+## Kubelet authentication
+
+By default, requests to the kubelet's HTTPS endpoint 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`.
+
+To disable anonymous access and send `401 Unauthorized` responses to unauthenticated requests:
+
+* start the kubelet with the `--anonymous-auth=false` flag
+
+To enable X509 client certificate authentication to the kubelet's HTTPS endpoint:
+
+* start the kubelet with the `--client-ca-file` flag, providing a CA bundle to verify client certificates with
+* start the apiserver with `--kubelet-client-certificate` and `--kubelet-client-key` flags
+* see the [apiserver authentication documentation](/docs/admin/authentication/#x509-client-certs) for more details
+
+To enable API bearer tokens (including service account tokens) to be used to authenticate to the kubelet's HTTPS endpoint:
+
+* ensure the `authentication.k8s.io/v1beta1` API group is enabled in the API server
+* start the kubelet with the `--authentication-token-webhook`, `--kubeconfig`, and `--require-kubeconfig` flags
+* the kubelet calls the `TokenReview` API on the configured API server to determine user information from bearer tokens
+
+## Kubelet authorization
+
+Any request that is successfully authenticated (including an anonymous request) is then authorized. The default authorization mode is `AlwaysAllow`, which allows all requests.
+
+There are many possible reasons to subdivide access to the kubelet API:
+
+* anonymous auth is enabled, but anonymous users' ability to call the kubelet API should be limited
+* bearer token auth is enabled, but arbitrary API users' (like service accounts) ability to call the kubelet API should be limited
+* client certificate auth is enabled, but only some of the client certificates signed by the configured CA should be allowed to use the kubelet API
+
+To subdivide access to the kubelet API, delegate authorization to the API server:
+
+* ensure the `authorization.k8s.io/v1beta1` API group is enabled in the API server
+* start the kubelet with the `--authorization-mode=Webhook`, `--kubeconfig`, and `--require-kubeconfig` flags
+* the kubelet calls the `SubjectAccessReview` API on the configured API server to determine whether each request is authorized
+
+The kubelet authorizes API requests using the same [request attributes](/docs/admin/authorization/#request-attributes) approach as the apiserver.
+
+The verb is determined from the incoming request's HTTP verb:
+
+HTTP verb | request verb
+----------|---------------
+POST      | create
+GET, HEAD | get
+PUT       | update
+PATCH     | patch
+DELETE    | delete
+
+The resource and subresource is determined from the incoming request's path:
+
+Kubelet API  | resource | subresource
+-------------|----------|------------
+/stats/\*     | nodes    | stats
+/metrics/\*   | nodes    | metrics
+/logs/\*      | nodes    | log
+/spec/\*      | nodes    | spec
+*all others* | nodes    | proxy
+
+The namespace and API group attributes are always an empty string, and
+the resource name is always the name of the kubelet's `Node` API object.
+
+When running in this mode, ensure the user identified by the `--kubelet-client-certificate` and `--kubelet-client-key`
+flags passed to the apiserver is authorized for the following attributes:
+
+* verb=\*, resource=nodes, subresource=proxy
+* verb=\*, resource=nodes, subresource=stats
+* verb=\*, resource=nodes, subresource=log
+* verb=\*, resource=nodes, subresource=spec
+* verb=\*, resource=nodes, subresource=metrics

cn/docs/admin/kubelet-tls-bootstrapping.md

@@ -0,0 +1,216 @@
+---
+approvers:
+- ericchiang
+- mikedanese
+- jcbsmpsn
+title: TLS bootstrapping
+---
+
+* TOC
+{:toc}
+
+## Overview
+
+This document describes how to set up TLS client certificate bootstrapping for kubelets.
+Kubernetes 1.4 introduced an API for requesting certificates from a cluster-level Certificate Authority (CA). The original intent of this API is to enable provisioning of TLS client certificates for kubelets. The proposal can be found [here](https://github.com/kubernetes/kubernetes/pull/20439)
+and progress on the feature is being tracked as [feature #43](https://github.com/kubernetes/features/issues/43).
+
+## kube-apiserver configuration
+
+The API server should be configured with an [authenticator](/docs/admin/authentication/) that can authenticate tokens as a user in the `system:bootstrappers` group.
+
+This group will later be used in the controller-manager configuration to scope approvals in the default approval
+controller. As this feature matures, you should ensure tokens are bound to a Role-Based Access Control (RBAC) policy which limits requests
+(using the bootstrap token) strictly to client requests related to certificate provisioning. With RBAC in place, scoping the tokens to a group allows for great flexibility (e.g. you could disable a particular bootstrap group's access when you are done provisioning the nodes).
+
+While any authentication strategy can be used for the kubelet's initial bootstrap credentials, the following two authenticators are recommended for ease of provisioning.
+
+1. [Bootstrap Tokens](/docs/admin/bootstrap-tokens/) - __alpha__
+2. [Token authentication file](###token-authentication-file)
+
+Using bootstrap tokens is currently __alpha__ and will simplify the management of bootstrap token management especially in a HA scenario. 
+
+### Token authentication file
+Tokens are arbitrary but should represent at least 128 bits of entropy derived from a secure random number
+generator (such as /dev/urandom on most modern systems). There are multiple ways you can generate a token. For example:
+
+`head -c 16 /dev/urandom | od -An -t x | tr -d ' '`
+
+will generate tokens that look like `02b50b05283e98dd0fd71db496ef01e8`
+
+The token file should look like the following example, where the first three values can be anything and the quoted group
+name should be as depicted:
+
+```
+02b50b05283e98dd0fd71db496ef01e8,kubelet-bootstrap,10001,"system:bootstrappers"
+```
+
+Add the `--token-auth-file=FILENAME` flag to the kube-apiserver command (in your systemd unit file perhaps) to enable the token file.
+See docs [here](/docs/admin/authentication/#static-token-file) for further details.
+
+### Client certificate CA bundle
+
+Add the `--client-ca-file=FILENAME` flag to the kube-apiserver command to enable client certificate authentication,
+referencing a certificate authority bundle containing the signing certificate (e.g. `--client-ca-file=/var/lib/kubernetes/ca.pem`).
+
+## kube-controller-manager configuration
+The API for requesting certificates adds a certificate-issuing control loop to the Kubernetes Controller Manager. This takes the form of a
+[cfssl](https://blog.cloudflare.com/introducing-cfssl/) local signer using assets on disk. Currently, all certificates issued have one year validity and a default set of key usages.
+
+### Signing assets
+You must provide a Certificate Authority in order to provide the cryptographic materials necessary to issue certificates.
+This CA should be trusted by kube-apiserver for authentication with the `--client-ca-file=FILENAME` flag. The management
+of the CA is beyond the scope of this document but it is recommended that you generate a dedicated CA for Kubernetes.
+Both certificate and key are assumed to be PEM-encoded.
+
+The kube-controller-manager flags are:
+
+```
+--cluster-signing-cert-file="/etc/path/to/kubernetes/ca/ca.crt" --cluster-signing-key-file="/etc/path/to/kubernetes/ca/ca.key"
+```
+
+### Approval controller
+
+In 1.7 the experimental "group auto approver" controller is dropped in favor of the new `csrapproving` controller
+that ships as part of [kube-controller-manager](/docs/admin/kube-controller-manager/) and is enabled by default.
+The controller uses the [`SubjectAccessReview` API](/docs/admin/authorization/#checking-api-access) to determine
+if a given user is authorized to request a CSR, then approves based on the authorization outcome. To prevent
+conflicts with other approvers, the builtin approver doesn't explicitly deny CSRs, only ignoring unauthorized requests.
+
+The controller categorizes CSRs into three subresources:
+
+1. `nodeclient` - a request by a user for a client certificate with `O=system:nodes` and `CN=system:node:(node name)`.
+2. `selfnodeclient` - a node renewing a client certificate with the same `O` and `CN`.
+3. `selfnodeserver` - a node renewing a serving certificate. (ALPHA, requires feature gate)
+
+The checks to determine if a CSR is a `selfnodeserver` request is currently tied to the kubelet's credential rotation
+implementation, an __alpha__ feature. As such, the definition of `selfnodeserver` will likely change in a future and
+requires the `RotateKubeletServerCertificate` feature gate on the controller manager. The feature progress can be
+tracked at [kubernetes/features#267](https://github.com/kubernetes/features/issues/267).
+
+```
+--feature-gates=RotateKubeletServerCertificate=true
+```
+
+The following RBAC `ClusterRoles` represent the `nodeclient`, `selfnodeclient`, and `selfnodeserver` capabilities. Similar roles
+may be automatically created in future releases.
+
+```yml
+# A ClusterRole which instructs the CSR approver to approve a user requesting
+# node client credentials.
+kind: ClusterRole
+apiVersion: rbac.authorization.k8s.io/v1beta1
+metadata:
+  name: approve-node-client-csr
+rules:
+- apiGroups: ["certificates.k8s.io"]
+  resources: ["certificatesigningrequests/nodeclient"]
+  verbs: ["create"]
+---
+# A ClusterRole which instructs the CSR approver to approve a node renewing its
+# own client credentials.
+kind: ClusterRole
+apiVersion: rbac.authorization.k8s.io/v1beta1
+metadata:
+  name: approve-node-client-renewal-csr
+rules:
+- apiGroups: ["certificates.k8s.io"]
+  resources: ["certificatesigningrequests/selfnodeclient"]
+  verbs: ["create"]
+---
+# A ClusterRole which instructs the CSR approver to approve a node requesting a
+# serving cert matching its client cert.
+kind: ClusterRole
+apiVersion: rbac.authorization.k8s.io/v1beta1
+metadata:
+  name: approve-node-server-renewal-csr
+rules:
+- apiGroups: ["certificates.k8s.io"]
+  resources: ["certificatesigningrequests/selfnodeserver"]
+  verbs: ["create"]
+```
+
+These powers can be granted to credentials, such as bootstrapping tokens. For example, to replicate the behavior
+provided by the removed auto-approval flag, of approving all CSRs by a single group:
+
+```
+# REMOVED: This flag no longer works as of 1.7.
+--insecure-experimental-approve-all-kubelet-csrs-for-group="system:bootstrappers"
+```
+
+An admin would create a `ClusterRoleBinding` targeting that group.
+
+```yml
+# Approve all CSRs for the group "system:bootstrappers"
+kind: ClusterRoleBinding
+apiVersion: rbac.authorization.k8s.io/v1beta1
+metadata:
+  name: auto-approve-csrs-for-group
+subjects:
+- kind: Group
+  name: system:bootstrappers
+  apiGroup: rbac.authorization.k8s.io
+roleRef:
+  kind: ClusterRole
+  name: approve-node-client-csr
+  apiGroup: rbac.authorization.k8s.io
+```
+
+To let a node renew its own credentials, an admin can construct a `ClusterRoleBinding` targeting
+that node's credentials:
+
+```yml
+kind: ClusterRoleBinding
+apiVersion: rbac.authorization.k8s.io/v1beta1
+metadata:
+  name: node1-client-cert-renewal
+subjects:
+- kind: User
+  name: system:node:node-1 # Let "node-1" renew its client certificate.
+  apiGroup: rbac.authorization.k8s.io
+roleRef:
+  kind: ClusterRole
+  name: approve-node-client-renewal-csr
+  apiGroup: rbac.authorization.k8s.io
+```
+
+Deleting the binding will prevent the node from renewing its client credentials, effectively
+removing it from the cluster once its certificate expires.
+
+## kubelet configuration
+To request a client certificate from kube-apiserver, the kubelet first needs a path to a kubeconfig file that contains the
+bootstrap authentication token. You can use `kubectl config set-cluster`, `set-credentials`, and `set-context` to build this kubeconfig. Provide the name `kubelet-bootstrap` to `kubectl config set-credentials` and include `--token=<token-value>` as follows:
+
+```
+kubectl config set-credentials kubelet-bootstrap --token=${BOOTSTRAP_TOKEN} --kubeconfig=bootstrap.kubeconfig
+```
+
+When starting the kubelet, if the file specified by `--kubeconfig` does not exist, the bootstrap kubeconfig is used to request a client certificate from the API server. On approval of the certificate request and receipt back by the kubelet, a kubeconfig file referencing the generated key and obtained certificate is written to the path specified by `--kubeconfig`. The certificate and key file will be placed in the directory specified by `--cert-dir`.
+
+**Note:** The following flags are required to enable this bootstrapping when starting the kubelet:
+
+```
+--require-kubeconfig
+--bootstrap-kubeconfig="/path/to/bootstrap/kubeconfig"
+```
+
+Additionally, in 1.7 the kubelet implements __alpha__ features for enabling rotation of both its client and/or serving certs.
+These can be enabled through the respective `RotateKubeletClientCertificate` and `RotateKubeletServerCertificate` feature
+flags on the kubelet, but may change in backward incompatible ways in future releases.
+
+```
+--feature-gates=RotateKubeletClientCertificate=true,RotateKubeletServerCertificate=true
+```
+
+`RotateKubeletClientCertificate` causes the kubelet to rotate its client certificates by creating new CSRs as its existing
+credentials expire. `RotateKubeletServerCertificate` causes the kubelet to both request a serving certificate after
+bootstrapping its client credentials and rotate the certificate. The serving cert currently does not request DNS or IP
+SANs.
+
+## kubectl approval
+The signing controller does not immediately sign all certificate requests. Instead, it waits until they have been flagged with an
+"Approved" status by an appropriately-privileged user. This is intended to eventually be an automated process handled by an external
+approval controller, but for the alpha version of the API it can be done manually by a cluster administrator using kubectl.
+An administrator can list CSRs with `kubectl get csr` and describe one in detail with `kubectl describe csr <name>`. Before the 1.6 release there were
+[no direct approve/deny commands](https://github.com/kubernetes/kubernetes/issues/30163) so an approver had to update
+the Status field directly ([rough how-to](https://github.com/gtank/csrctl)). Later versions of Kubernetes offer `kubectl certificate approve <name>` and `kubectl certificate deny <name>` commands.

cn/docs/admin/multiple-zones.md

@@ -0,0 +1,292 @@
+---
+approvers:
+- jlowdermilk
+- justinsb
+- quinton-hoole
+title: 多区域运行
+---
+
+## 介绍
+
+Kubernetes 从v1.2开始支持将集群运行在多个故障域中。
+(GCE 中称其为 "区（Zones）"， AWS 中称其为 "可用区（Availability Zones）"，这里我们也称其为 "区")。
+它是广泛意义上的集群联邦特性的轻量级版本 (之前被称为 ["Ubernetes"](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/federation/federation.md))。
+完整的集群联邦能够将多个分别运行在不同区或云供应商（或本地数据中心）的集群集中管理。
+然而，很多用户只是希望通过将单一云供应商上的Kubernetes集群运行在多个区域，来提高集群的可用性，
+这就是1.2版本中提供的对多区域的支持。
+(之前被称为 "Ubernetes Lite")。
+
+多区域的支持是有明确限制的： Kubernetes集群能够运行在多个区，但必须在同一个地域内 (云供应商也须一致)。  
+目前只有GCE和AWS自动支持 (尽管在其他云甚至裸机上，也很容易通过为节点和卷添加合适的标签来实现类似的支持)。
+
+
+* TOC
+{:toc}
+
+## 功能
+
+节点启动时，Kubelet自动为其添加区信息的标签。
+
+在单一区域的集群中，Kubernetes 会自动将副本管理器或服务的pod分布到各节点上 (以减轻单实例故障的影响)。
+在多区域的集群中，这种分布的行为扩展到了区域级别
+(以减少区域故障对整体的影响)。  (通过 `SelectorSpreadPriority` 来实现)。
+这种分发是尽力而为（best-effort）的，所以如果集群在各个区之间是异构的
+(比如，各区间的节点数量不同、节点类型不同、pod的资源需求不同等)可能导致pod无法完全均匀地分布。
+如果需要的话，用户可以使用同质的区(节点数量和节点类型相同)来减少区域之间分配不均匀的可能。
+
+当卷被创建时， `PersistentVolumeLabel`准入控制器会自动为其添加区域的标签。
+调度器 (通过 `VolumeZonePredicate` 断言) 会确申领该卷的pod被调度到该卷对应的区域，
+因为卷是不支持跨区挂载的。
+
+## 限制
+
+对多区的支持有一些重要的限制：
+
+* 我们假设不同的区域间在网络上离得很近，所以我们不做任何的区域感知路由。 特别是，通过服务的网络访问可能跨区域 (即使该服务后端pod的其中一些运行在与客户端相同的区域中)，这可能导致额外的延迟和损耗。
+
+* 卷的区域亲和性只对 `PersistentVolume`有效。 例如，如果你在pod的spec中直接指定一个EBS的卷，则不会生效。
+
+* 集群不支持跨云平台或地域 (这些功能需要完整的集群联邦特性支持)。
+
+* 尽管节点位于多区域，目前默认情况下 kube-up 创建的管理节点是单实例的。 所以尽管服务是高可用的，并且能够容忍跨区域的性能损耗，管理平面还是单区域的。 需要高可用的管理平面的用户可以按照 [高可用](/docs/admin/high-availability) 指导来操作。
+
+* 目前StatefulSet的卷动态创建时的跨区域分配，与pod的亲和性/反亲和性不兼容。
+
+* StatefulSet的名称包含破折号 ("-")时，可能影响到卷在区域间的均匀分布。
+
+* 为deployment或pod指定多个PVC时，要求其StorageClass处于同一区域内，否则，相应的PV卷需要在一个区域中静态配置。 另一种方式是使用StatefulSet，这可以确保同一副本所挂载的卷位于同一区内。
+
+
+## 演练
+
+接下来我们将介绍如何同时在 GCE 和 AWS 上创建和使用多区域的集群。 为此，你需要创建一个完整的集群 
+(指定 `MULTIZONE=true`)，然后再次执行 `kube-up`（指定 `KUBE_USE_EXISTING_MASTER=true`）来添加其他区域的节点。
+
+### 创建集群
+
+按正常方式创建集群，但是传入 MULTIZONE 来通知集群对多区域进行管理。 在 us-central1-a 区域创建节点。
+
+GCE:
+
+```shell
+curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a NUM_NODES=3 bash
+```
+
+AWS:
+
+```shell
+curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash
+```
+
+该步骤按正常方式创建了集群，仍然运行在单个区域中。
+但 `MULTIZONE=true` 已经开启了多区域的能力。
+
+### 标记节点
+
+查看节点，你可以发现节点上打了区域信息的标签。
+节点位于 `us-central1-a` (GCE) 或者 `us-west-2a` (AWS)。 标签 `failure-domain.beta.kubernetes.io/region` 用于区分地域，
+标签 `failure-domain.beta.kubernetes.io/zone` 用于区分区域。
+
+```shell
+> kubectl get nodes --show-labels
+
+
+NAME                     STATUS                     AGE   VERSION          LABELS
+kubernetes-master        Ready,SchedulingDisabled   6m    v1.6.0+fff5156   beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
+kubernetes-minion-87j9   Ready                      6m    v1.6.0+fff5156   beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
+kubernetes-minion-9vlv   Ready                      6m    v1.6.0+fff5156   beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+kubernetes-minion-a12q   Ready                      6m    v1.6.0+fff5156   beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
+```
+
+### 添加其它区中的节点
+
+接下来我们复用已有的管理节点，添加运行于其它区域 （us-central1-b或us-west-2b）中的节点。
+再次执行 kube-up， 通过指定 `KUBE_USE_EXISTING_MASTER=true`，
+kube-up 不会创建新的管理节点，而是会复用之前创建的。
+
+GCE:
+
+```shell
+KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh
+```
+
+在 AWS 中我们还需要为新增的子网指定网络CIDR，还有管理节点的内部IP地址。
+
+```shell
+KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2b NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.1.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
+```
+
+
+再次查看节点，3个新增的节点已经启动，并被标记为us-central1-b：
+
+```shell
+> kubectl get nodes --show-labels
+
+NAME                     STATUS                     AGE   VERSION           LABELS
+kubernetes-master        Ready,SchedulingDisabled   16m   v1.6.0+fff5156    beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
+kubernetes-minion-281d   Ready                      2m    v1.6.0+fff5156    beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
+kubernetes-minion-87j9   Ready                      16m   v1.6.0+fff5156    beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
+kubernetes-minion-9vlv   Ready                      16m   v1.6.0+fff5156    beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+kubernetes-minion-a12q   Ready                      17m   v1.6.0+fff5156    beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
+kubernetes-minion-pp2f   Ready                      2m    v1.6.0+fff5156    beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f
+kubernetes-minion-wf8i   Ready                      2m    v1.6.0+fff5156    beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i
+```
+
+### 卷的亲和性
+
+使用动态创建卷的功能创建一个卷 (只有PV持久卷才支持区域亲和性)：
+
+```json
+kubectl create -f - <<EOF
+{
+  "kind": "PersistentVolumeClaim",
+  "apiVersion": "v1",
+  "metadata": {
+    "name": "claim1",
+    "annotations": {
+        "volume.alpha.kubernetes.io/storage-class": "foo"
+    }
+  },
+  "spec": {
+    "accessModes": [
+      "ReadWriteOnce"
+    ],
+    "resources": {
+      "requests": {
+        "storage": "5Gi"
+      }
+    }
+  }
+}
+EOF
+```
+
+**注意：** Kubernetes 1.3以上的版本中可以将PVC分发到多个已配置的区域中，在1.2版本中， 动态卷只能创建在管理节点所在的区域内(即这里的 us-central1-a / us-west-2a)；相关issue
+([#23330](https://github.com/kubernetes/kubernetes/issues/23330))
+在1.3后续的版本中已解决。
+
+现在我们验证一下 Kubernetes 自动为创建的PV打上了所在地域和区域的标签。
+
+```shell
+> kubectl get pv --show-labels
+NAME           CAPACITY   ACCESSMODES   STATUS    CLAIM            REASON    AGE       LABELS
+pv-gce-mj4gm   5Gi        RWO           Bound     default/claim1             46s       failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a
+```
+
+现在我们将创建使用这些PVC的pod。
+因为 GCE 的PD存储 / AWS 的EBS 卷 不支持跨区域挂载，
+这意味着相应的pod只能创建在卷所在的区域中。
+
+```yaml
+kubectl create -f - <<EOF
+kind: Pod
+apiVersion: v1
+metadata:
+  name: mypod
+spec:
+  containers:
+    - name: myfrontend
+      image: nginx
+      volumeMounts:
+      - mountPath: "/var/www/html"
+        name: mypd
+  volumes:
+    - name: mypd
+      persistentVolumeClaim:
+        claimName: claim1
+EOF
+```
+
+注意pod被自动创建在了卷所在的区域中，因为云供应商通常不支持卷的跨区域挂载（attach）。
+
+```shell
+> kubectl describe pod mypod | grep Node
+Node:        kubernetes-minion-9vlv/10.240.0.5
+> kubectl get node kubernetes-minion-9vlv --show-labels
+NAME                     STATUS    AGE    VERSION          LABELS
+kubernetes-minion-9vlv   Ready     22m    v1.6.0+fff5156   beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+```
+
+### Pod的跨区域分布
+
+副本管理器或服务的pod被自动创建在了不同的区域。  首先，在第三个区域内启动节点：
+
+GCE:
+
+```shell
+KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-f NUM_NODES=3 kubernetes/cluster/kube-up.sh
+```
+
+AWS:
+
+```shell
+KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2c NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.2.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh
+```
+
+验证你现在在3个区域内拥有节点:
+
+```shell
+kubectl get nodes --show-labels
+```
+
+创建 guestbook-go 示例应用， 它包含一个副本数为3的RC，运行一个简单的网络应用：
+
+```shell
+find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl create -f {}
+```
+
+Pod应该分布在全部3个区域上：
+
+```shell
+>  kubectl describe pod -l app=guestbook | grep Node
+Node:        kubernetes-minion-9vlv/10.240.0.5
+Node:        kubernetes-minion-281d/10.240.0.8
+Node:        kubernetes-minion-olsh/10.240.0.11
+
+ > kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion-olsh --show-labels
+NAME                     STATUS    AGE    VERSION          LABELS
+kubernetes-minion-9vlv   Ready     34m    v1.6.0+fff5156   beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
+kubernetes-minion-281d   Ready     20m    v1.6.0+fff5156   beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
+kubernetes-minion-olsh   Ready     3m     v1.6.0+fff5156   beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh
+```
+
+
+负载平衡器覆盖集群中的所有区域； guestbook-go 示例包含一个
+负载均衡服务的例子：
+
+```shell
+> kubectl describe service guestbook | grep LoadBalancer.Ingress
+LoadBalancer Ingress:   130.211.126.21
+
+> ip=130.211.126.21
+
+> curl -s http://${ip}:3000/env | grep HOSTNAME
+  "HOSTNAME": "guestbook-44sep",
+
+> (for i in `seq 20`; do curl -s http://${ip}:3000/env | grep HOSTNAME; done)  | sort | uniq
+  "HOSTNAME": "guestbook-44sep",
+  "HOSTNAME": "guestbook-hum5n",
+  "HOSTNAME": "guestbook-ppm40",
+```
+
+负载平衡器正确指向了所有的pod，即使它们位于不同的区域内。
+
+### 停止集群
+
+使用完成后，进行清理：
+
+GCE:
+
+```shell
+KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-f kubernetes/cluster/kube-down.sh
+KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-b kubernetes/cluster/kube-down.sh
+KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a kubernetes/cluster/kube-down.sh
+```
+
+AWS:
+
+```shell
+KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2c kubernetes/cluster/kube-down.sh
+KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b kubernetes/cluster/kube-down.sh
+KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh
+```

cn/docs/admin/ovs-networking.md

@@ -0,0 +1,22 @@
+---
+assignees:
+- thockin
+title: Kubernetes OpenVSwitch GRE/VxLAN 网络
+---
+
+本文档介绍了如何使用OpenVSwitch，在跨nodes的pods之间设置网络。
+隧道类型可以是GRE或者是VxLAN。如需在网络内执行大规模隔离时，最好使用VxLAN。
+
+![OVS Networking](/images/docs/ovs-networking.png)
+
+Kubernetes中Vagrant的设置如下：
+
+docker网桥被brctl生成的Linux网桥(kbr0)所代替，kbr0是具有256个地址空间的子网。总的来说，node会得到10.244.x.0/24的子网，docker上配置使用的网桥会代替默认docker0的网桥。
+
+另外，OVS网桥创建(obr0)，并将其作为端口添加到kbr0的网桥中。所有OVS网桥通过GRE隧道连接所有的nodes。因此，每个node都有一个到其他nodes的出站GRE隧道。这个隧道没有必要是一个完整的网状物，但是越像网状结构越好。在网桥上开启STP(生成树)模式以防止环路的发生。
+
+路由规则允许任何10.244.0.0/16通过与隧道相连的OVS网桥到达目标。
+
+
+
+

cn/docs/concepts/architecture/master-node-communication.md

@@ -0,0 +1,71 @@
+---
+approvers:
+- dchen1107
+- roberthbailey
+- liggitt
+
+title: Master 节点通信
+---
+
+* TOC
+{:toc}
+
+
+## 概览
+
+
+本文对 Master 节点（确切说是 apiserver）和 Kubernetes 集群之间的通信路径进行了分类。目的是为了让用户能够自定义他们的安装，对网络配置进行加固，使得集群能够在不可信的网络上（或者在一个云服务商完全公共的 IP 上）运行。
+
+
+## Cluster -> Master
+
+
+所有从集群到 master 的通信路径都终止于 apiserver（其它 master 组件没有被设计为可暴露远程服务）。在一个典型的部署中，apiserver 被配置为在一个安全的 HTTPS 端口（443）上监听远程连接并启用一种或多种形式的客户端[身份认证](/docs/admin/authentication/)机制。一种或多种客户端[身份认证](/docs/admin/authentication/)机制应该被启用，特别是在允许使用 [匿名请求](/docs/admin/authentication/#anonymous-requests) 或 [service account tokens](/docs/admin/authentication/#service-account-tokens) 的时候。
+
+
+应该使用集群的公共根证书开通节点，如此它们就能够基于有效的客户端凭据安全的连接 apiserver。例如：在一个默认的 GCE 部署中，客户端凭据以客户端证书的形式提供给 kubelet。请查看 [kubelet TLS bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) 获取如何自动提供 kubelet 客户端证书。
+
+
+想要连接到 apiserver 的 Pods 可以使用一个 service account 安全的进行连接。这种情况下，当 Pods 被实例化时 Kubernetes 将自动的把公共根证书和一个有效的不记名令牌注入到 pod 里。`kubernetes` service （所有 namespaces 中）都配置了一个虚拟 IP 地址，用于转发（通过 kube-proxy）请求到 apiserver 的 HTTPS endpoint。
+
+
+Master 组件通过非安全（没有加密或认证）端口和集群的 apiserver 通信。这个端口通常只在 master 节点的 localhost 接口暴露，这样，所有在相同机器上运行的 master 组件就能和集群的 apiserver 通信。一段时间以后，master 组件将变为使用带身份认证和权限验证的安全端口（查看[#13598](https://github.com/kubernetes/kubernetes/issues/13598)）。
+
+
+这样的结果使得从集群（在节点上运行的 nodes 和 pods）到 master 的缺省连接操作模式默认被保护，能够在不可信或公网中运行。
+
+
+## Master -> Cluster
+
+
+从 master（apiserver）到集群有两种主要的通信路径。第一种是从 apiserver 到集群中每个节点上运行的 kubelet 进程。第二种是从 apiserver 通过它的代理功能到任何 node、pod 或者 service。
+
+
+### apiserver -> kubelet
+
+
+从 apiserver 到 kubelet 的连接用于获取 pods 日志、连接（通过 kubectl）运行中的 pods，以及使用 kubele 的端口转发功能。这些连接终止于 kubelet 的 HTTPS endpoint。
+
+
+默认的，apiserver 不会验证 kubelet 的服务证书，这会导致连接遭到中间人攻击，因而在不可信或公共网络上是不安全的。  
+
+
+为了对这个连接进行认证，请使用 `--kubelet-certificate-authority` 标记给 apiserver 提供一个根证书捆绑，用于 kubelet 的服务证书。
+
+
+如果这样不可能，又要求避免在不可信的或公共的网络上进行连接，请在 apiserver 和 kubelet 之间使用 [SSH 隧道](/docs/concepts/architecture/master-node-communication/#ssh-tunnels)。
+
+
+最后，应该启用[Kubelet 用户认证和/或权限认证](/docs/admin/kubelet-authentication-authorization/)来保护 kubelet API。
+
+
+### apiserver -> nodes, pods, and services
+
+
+从 apiserver 到 node、pod或者service 的连接默认为纯 HTTP 方式，因此既没有认证，也没有加密。他们能够通过给API URL 中的 node、pod 或 service 名称添加前缀 `https:` 来运行在安全的 HTTPS 连接上。但他们即不会认证 HTTPS endpoint 提供的证书，也不会提供客户端证书。这样虽然连接是加密的，但它不会提供任何完整性保证。这些连接**目前还不能安全的**在不可信的或公共的网络上运行。
+
+
+### SSH 隧道
+
+
+[Google Container Engine](https://cloud.google.com/container-engine/docs/) 使用 SSH 隧道保护 Master -> Cluster 通信路径。在这种配置下，apiserver 发起一个到集群中每个节点的 SSH 隧道（连接到在 22 端口监听的 ssh 服务）并通过这个隧道传输所有到 kubelet、node、pod 或者 service 的流量。这个隧道保证流量不会在集群运行的私有 GCE 网络之外暴露。

cn/docs/concepts/architecture/nodes.md

@@ -0,0 +1,234 @@
+---
+assignees:
+- caesarxuchao
+- dchen1107
+
+title: Nodes
+redirect_from:
+- "/docs/admin/node/"
+- "/docs/admin/node.html"
+- "/docs/concepts/nodes/node/"
+- "/docs/concepts/nodes/node.html"
+---
+
+* TOC
+{:toc}
+
+
+## Node 是什么？
+
+
+`Node` 是 Kubernetes 的工作节点，以前叫做 `minion`。取决于你的集群，Node 可以是一个虚拟机或者物理机器。每个 node 都有用于运行 [pods](/docs/user-guide/pods) 的必要服务，并由 master 组件管理。Node 上的服务包括 Docker、kubelet 和 kube-proxy。请查阅架构设计文档中 [The Kubernetes Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) 一节获取更多细节。
+
+
+## Node 状态
+
+
+  一个 node 的状态包含以下信息:
+
+* [地址](#地址)
+* ~~[阶段](#阶段)~~ **已废弃**
+* [条件](#条件)
+* [容量](#容量)
+* [信息](#信息)
+
+
+下面对每个章节进行详细描述。
+
+
+### 地址
+
+
+这些字段组合的用法取决于你的云服务商或者裸金属配置。
+
+* HostName：HostName 和 node 内核报告的相同。可以通过 kubelet 的 `--hostname-override` 参数覆盖。
+* ExternalIP：通常是可以外部路由的 node IP 地址（从集群外可访问）。
+* InternalIP：通常是仅可在集群内部路由的 node IP 地址。
+
+
+### 阶段
+
+
+一废弃：node 阶段已经不再使用。
+
+
+### 条件
+
+
+`conditions` 字段描述了所有 `Running` nodes 的状态。
+
+
+| Node 条件          | 描述                                       |
+| ---------------- | ---------------------------------------- |
+| `OutOfDisk`      | `True` 表示 node 的空闲空间不足以用于添加新 pods, 否则为 `False` |
+| `Ready`          | `True` 表示 node 是健康的并已经准备好接受 pods；`False` 表示 node 不健康而且不能接受 pods；`Unknown` 表示 node 控制器在最近 40 秒内没有收到 node 的消息 |
+| `MemoryPressure` | `True` 表示 node 不存在内存压力 -- 即 node 内存用量低, 否则为 `False`       |
+| `DiskPressure`   | `True` 表示 node 不存在磁盘压力 -- 即磁盘用量低, 否则为 `False`       |
+
+
+Node 条件使用一个 JSON 对象表示。例如，下面的响应描述了一个健康的 node。
+
+```json
+"conditions": [
+  {
+    "kind": "Ready",
+    "status": "True"
+  }
+]
+```
+
+
+如果 Ready 条件处于状态 "Unknown" 或者 "False" 的时间超过了 `pod-eviction-timeout`(一个传递给 [kube-controller-manager](/docs/admin/kube-controller-manager/) 的参数)，node 上的所有 Pods 都会被 Node 控制器计划删除。默认的删除超时时长为**5分钟**。某些情况下，当 node 不可访问时，apiserver 不能和其上的 kubelet 通信。删除 pods 的决定不能传达给 kubelet，直到它重新建立和 apiserver 的连接为止。与此同时，被计划删除的 pods 可能会继续在分区 node 上运行。
+
+
+在 1.5 版本之前的 Kubernetes 里，node 控制器会将不能访问的 pods 从 apiserver 中[强制删除](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)。但在 1.5 或更高的版本里，在node 控制器确认这些 pods 已经在集群里停运行前不会强制删除它们。你可以看到这些处于 "Terminating" 或者 "Unknown" 状态的 pods 可能在无法访问的 node 上运行。为了防止 kubernetes 不能从底层基础设施中推断出一个 node 是否已经永久的离开了集群，集群管理员可能需要手动删除这个 node 对象。从 Kubernetes 删除 node 对象将导致 apiserver 删除 node 上所有运行的 Pod 对象并释放它们的名字。
+
+
+### 容量
+
+
+描述 node 上的可用资源：CPU、内存和可以调度到 node 上的 pods 的最大数量。
+
+
+### 信息
+
+
+关于 node 的通用信息，例如内核版本、Kubernetes 版本（kubelet 和 kube-proxy 版本）、Docker 版本 （如果使用了）和 OS 名。这些信息由 Kubelet 从 node 搜集而来。
+
+
+## 管理
+
+
+与 [pods](/docs/user-guide/pods) 和 [services](/docs/user-guide/services) 不同，node 并不是在 Kubernetes 内部创建的：它是被外部的云服务商创建，例如 Google Compute Engine 或者你的集群中的物理或者虚拟机。这意味着当 Kubernetes 创建一个 node 时，它其实仅仅创建了一个对象来代表这个 node。创建以后，Kubernetes 将检查这个 node 是否可用。例如，如果你尝试使用如下内容创建一个 node：
+
+```json
+{
+  "kind": "Node",
+  "apiVersion": "v1",
+  "metadata": {
+    "name": "10.240.79.157",
+    "labels": {
+      "name": "my-first-k8s-node"
+    }
+  }
+}
+```
+
+
+Kubernetes 会在内部创一个 node 对象（象征 node），并基于  `metadata.name` 字段（我们假设 `metadata.name` 能够被解析）通过健康检查来验证 node。如果 node 可用，意即所有必要服务都已运行，它就符合了运行一个 pod 的条件；否则它将被所有的集群动作忽略指导变为可用。请注意，Kubernetes 将保存不可用 node 的对象，除非它被客户端显式的删除。Kubernetes 将持续检查 node 是否变的可用。
+
+
+当前，有3个组件同 Kubernetes node 接口交互：node 控制器、kubelet 和 kubectl。
+
+
+### Node 控制器
+
+
+Node 控制器是一个 Kubernetes master 组件，管理 nodes 的方方面面。
+
+
+Node 控制器在 node 的生命周期中扮演了多个角色。第一个是当 node 注册时为它分配一个 CIDR block（如果打开了 CIDR 分配）。
+
+
+第二个是使用云服务商提供了可用节点列表保持 node 控制器内部的 nodes 列表更新。如果在云环境下运行，任何时候当一个 node 不健康时 node 控制器将询问云服务 node 的虚拟机是否可用。如果不可用，node 控制器会将这个 node 从它的 nodes 列表删除。
+
+
+第三个是监控 nodes 的健康情况。Node 控制器负责在 node 不能访问时（也即是 node 控制器因为某些原因没有收到心跳，例如 node 宕机）将它的 NodeStatus 的 NodeReady 状态更新为 ConditionUnknown。后续如果 node 持续不可访问，Node 控制器将删除 node 上的所有 pods（使用优雅终止）。（默认情况下 40s 开始报告 ConditionUnknown，在那之后 5m 开始删除 pods。）Node 控制器每隔 `--node-monitor-period` 秒检查每个 node 的状态。
+
+
+在 Kubernetes 1.4 中我们更新了 node 控制器逻辑以更好的处理大批量 nodes 访问 master 出问题的情况（例如 master 的网络出了问题）。从 1.4 开始，node 控制器在决定删除 pod 之前会检查集群中所有 nodes 的状态。
+
+
+大部分情况下， node 控制器把删除频率限制在每秒 `--node-eviction-rate` 个（默认为 0.1）。这表示它在 10 秒钟内不会从超过一个 node 上删除 pods。
+
+
+当一个 availability zone 中的 node 变为不健康时，它的删除行为将发生改变。Node 控制器会同时检查 zone 中不健康（NodeReady  状态为 ConditionUnknown 或 ConditionFalse）的 nodes 的百分比。如果不健康 nodes 的部分超过 `--unhealthy-zone-threshold` （默认为 0.55），删除速率将会减小：如果集群较小（意即小于等于 `--large-cluster-size-threshold` 个 nodes - 默认为50），删除将会停止，否则删除速率将降为每秒 `--secondary-node-eviction-rate` 个（默认为 0.01）。在单个 availability zone 实施这些策略的原因是当一个 availability zone 可能从 master 分区时其它的仍然保持连接。如果你的集群没有跨越云服务商的多个 availability zones，那就只有一个 availability zone（整个集群）。
+
+
+在多个 availability zones 分布你的 nodes 的一个关键原因是当整个 zone 故障时，工作负载可以转移到健康的 zones。因此，如果一个 zone 中的所有 nodes 都不健康时，node 控制器会以正常的速率 `--node-eviction-rate` 删除。在所有的 zones 都不健康（也即集群中没有健康 node）的极端情况下，node 控制器将假设 master 的连接出了某些问题，它将停止所有删除动作直到一些连接恢复。
+
+
+从 Kubernetes 1.6 开始，NodeController 还负责删除运行在拥有 `NoExecute` taints 的 nodes 上的 pods，如果这些 pods 没有 tolerate 这些 taints。此外，作为一个默认禁用的 alpha 特性，NodeController 还负责根据 node 故障（例如 node 不可访问或没有 ready）添加 taints。请查看 [这个文档](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature)了解关于 `NoExecute` taints 和这个 alpha 特性。
+
+
+### Nodes 自注册
+
+
+当 kubelet 标志 `--register-node` 为 true （默认）时，它会尝试向 API 服务注册自己。这是首选模式，被绝大多数发行版选用。
+
+
+  对于自注册模式，kubelet 使用下列参数启动：
+
+  - `--api-servers` - apiservers 地址。
+  - `--kubeconfig` - 用于向 apiserver 验证自己的凭据路径。
+  - `--cloud-provider` - 如何从云服务商读取关于自己的元数据。
+  - `--register-node` - 自动向  API 服务注册。
+  - `--register-with-taints` - 使用 taints 列表（逗号分隔的 `<key>=<value>:<effect>`）注册 node。当 `register-node` 为 false 时无效。
+  - `--node-ip` - node IP 地址。
+  - `--node-labels` - 向集群注册时给 node 添加的 labels。
+  - `--node-status-update-frequency` - 指定 kubelet 向 master 发送状态的频率。
+
+
+目前，任何 kubelet 都被授权可以创建/修改任意 node 资源，但通常只对自己的进行创建/修改。（未来我们计划只允许一个 kubelet 修改它自己 node 的资源。）
+
+
+#### 手动 Node 管理
+
+
+集群管理员可以创建及修改 node 对象。
+
+
+如果管理员希望手动创建 node 对象，请设置 kubelet 标记 `--register-node=false`。
+
+
+管理员可以修改 node 资源（忽略 `--register-node` 设置）。修改包括在 node 上设置 labels及标记它为不可调度。
+
+
+Nodes 上的 labels 可以和 pods 的 node selectors 一起使用来控制调度，例如限制一个 pod 只能在一个符合要求的 nodes 子集上运行。
+
+
+标记一个 node 为不可调度的将防止新建 pods 调度到那个 node 之上，但不会影响任何已经在它之上的 pods。这是重启 node 等操作之前的一个有用的准备步骤。例如，标记一个 node 为不可调度的，执行以下命令：
+
+```shell
+kubectl cordon $NODENAME
+```
+
+
+请注意，被 daemonSet 控制器创建的 pods 将忽略 Kubernetes 调度器，且不会遵照 node 上不可调度的属性。这个假设基于守护程序属于节点机器，即使在准备重启而隔离应用的时候。
+
+
+### Node 容量
+
+
+Node 的容量（cpu 数量和内存容量）是 node 对象的一部分。通常情况下，在创建 node 对象时，它们会注册自己并报告自己的容量。如果你正在执行[手动 node 管理](#manual-node-administration)，那么你需要在添加 node 时手动设置 node 容量。
+
+
+Kubernetes 调度器保证一个 node 上有足够的资源供其上的所有 pods 使用。它会检查 node 上所有容器要求的总和不会超过 node 的容量。这包括所有 kubelet 启动的容器，但不包含 Docker 启动的容器和不在容器中的进程。
+
+
+如果希望显式的为非 pod 进程预留资源，你可以创建一个占位 pod。使用如下模板：
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: resource-reserver
+spec:
+  containers:
+  - name: sleep-forever
+    image: gcr.io/google_containers/pause:0.8.0
+    resources:
+      requests:
+        cpu: 100m
+        memory: 100Mi
+```
+
+
+设置 `cpu` 和 `memory` 值为你希望预留的资源量。将文件放在清单文件夹中（kubelet 的 `--config=DIR` 标志）。当你希望预留资源时，在每个 kubelet 上都这样执行。
+
+
+## API 对象
+
+
+Node 是 Kubernetes REST API 的顶级资源。更多关于 API 对象的细节可以在这里找到： [Node API
+object](/docs/api-reference/{{page.version}}/#node-v1-core).``

cn/docs/concepts/cluster-administration/addons.md

@@ -0,0 +1,45 @@
+---
+
+title: 安装扩展（Addons）
+---
+
+
+## 概览
+
+
+Add-ons 扩展了 Kubernetes 的功能。
+
+
+本文列举了一些可用的 add-ons 以及到它们各自安装说明的链接。
+
+
+每个 add-ons 按字母顺序排序 - 顺序不代表任何优先地位。
+
+
+## 网络和网络策略
+
+
+* [Calico](http://docs.projectcalico.org/latest/getting-started/kubernetes/installation/hosted/)  是一个安全的 L3 网络和网络策略提供者。
+* [Canal](https://github.com/tigera/canal/tree/master/k8s-install)  结合 Flannel 和 Calico， 提供网络和网络策略。
+* [Cilium](https://github.com/cilium/cilium) 是一个 L3 网络和网络策略插件， 能够透明的实施  HTTP/API/L7 策略。 同时支持路由（routing）和叠加/封装（ overlay/encapsulation）模式。
+* [Contiv](http://contiv.github.io) 为多种用例提供可配置网络（使用 BGP 的原生 L3，使用 vxlan 的 overlay，经典 L2 和  Cisco-SDN/ACI）和丰富的策略框架。Contiv 项目完全[开源](http://github.com/contiv)。[安装工具](http://github.com/contiv/install)同时提供基于和不基于 kubeadm 的安装选项。
+* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) 是一个可以用于 Kubernetes 的 overlay 网络提供者。
+* [Romana](http://romana.io) 是一个 pod 网络的层 3 解决方案，并且支持  [NetworkPolicy API](/docs/concepts/services-networking/network-policies/)。Kubeadm add-on 安装细节可以在[这里](https://github.com/romana/romana/tree/master/containerize)找到。
+* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/)  提供了在网络分组两端参与工作的网络和网络策略，并且不需要额外的数据库。
+* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)  使 Kubernetes 无缝连接到一种 CNI 插件，例如：Flannel、Calico、Canal、Romana 或者 Weave。
+
+
+## 可视化管理
+
+
+* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) 是一个 Kubernetes 的 web 控制台界面。
+* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) 是一个图形化工具，用于查看你的 containers、 pods、services等。 请和一个  [Weave Cloud account](https://cloud.weave.works/) 一起使用，或者自己运行 UI。
+
+
+## 遗留 Add-ons
+
+
+还有一些其它 add-ons 归档在已废弃的  [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) 路径中。
+
+
+维护完善的 add-ons 应该被链接到这里。欢迎提出 PRs！

cn/docs/concepts/cluster-administration/cluster-administration-overview.md

@@ -0,0 +1,86 @@
+---
+approvers:
+- davidopp
+- lavalamp
+
+title: 集群管理概述
+---
+
+{% capture overview %}
+
+集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。我们假设你对 [用户指南](/docs/user-guide/)中的概念有一些熟悉。
+{% endcapture %}
+
+{% capture body %}
+
+## 规划集群
+
+
+查阅 [选择正确解决方案](/docs/setup/pick-right-solution/) 中的指导，获取如何规划、建立以及配置 Kubernetes 集群的示例。本文所列的文章称为*发行版*。
+
+
+在选择一个指南前，有一些因素需要考虑：
+
+ - 你是打算在你的电脑上尝试 Kubernetes，还是要构建一个高可用的多节点集群？请选择最适合你需求的发行版。
+ - **如果你正在设计一个高可用集群**，请了解[在多个 zones 中配置集群](/docs/admin/multi-cluster)。
+ - 你的集群是在**本地**还是**云（IaaS）**上？Kubernetes 不能直接支持混合集群。作为代替，你可以建立多个集群。
+ - **如果你在本地配置 Kubernetes**，需要考虑哪种[网络模型](/docs/admin/networking)最适合。一种自定义网络的选项是 [*OpenVSwitch GRE/VxLAN 网络*](/docs/admin/ovs-networking/)，它使用 OpenVSwitch 在跨 Kubernetes 节点的 pods 之间建立起网络。
+ - 你的 Kubernetes 在 **裸金属硬件** 还是 **虚拟机（VMs）**上运行？
+ - 你**只想运行一个集群**，还是打算**活动开发 Kubernetes 项目代码**？如果是后者，请选择一个活动开发的发行版。某些发行版只提供二进制发布版，但提供更多的选择。
+ - 让你自己熟悉运行一个集群所需的[组件](/docs/admin/cluster-components) 。
+
+
+请注意：不是所有的发行版都被积极维护着。请选择测试过最近版本的 Kubernetes 的发行版。
+
+
+如果你正在使用和 Salt 有关的指南，请查阅  [使用 Salt 配置 Kubernetes](/docs/admin/salt)。
+
+
+## 管理集群
+
+
+[管理集群](/docs/concepts/cluster-administration/cluster-management/)叙述了和集群生命周期相关的几个主题：创建一个新集群、升级集群的 master 和 worker 节点、执行节点维护（例如内核升级）以及升级活动集群的 Kubernetes API 版本。
+
+
+## 保护集群
+
+
+* [Kubernetes 容器环境](/docs/concepts/containers/container-environment-variables/) 描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。
+
+
+* [控制到 Kubernetes API 的访问](/docs/admin/accessing-the-api) 描述了如何为用户和 service accounts 建立权限许可.
+
+
+*  [用户认证](/docs/admin/authentication) 阐述了 Kubernetes 中的认证功能，包括许多认证选项。
+
+
+*  [授权](/docs/admin/authorization)从认证中分离出来，用于控制如何处理 HTTP 请求。
+
+
+*  [使用 Admission Controllers](/docs/admin/admission-controllers) 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。
+
+
+* [在 Kubernetes Cluster 中使用 Sysctls](/docs/concepts/cluster-administration/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。
+
+
+* [审计](/docs/tasks/debug-application-cluster/audit/) 描述了如何与 Kubernetes 的审计日志交互。
+
+
+### 保护 kubelet
+
+  * [Master 节点通信](/docs/concepts/cluster-administration/master-node-communication/)
+  * [TLS 引导](/docs/admin/kubelet-tls-bootstrapping/)
+  * [Kubelet 认证/授权](/docs/admin/kubelet-authentication-authorization/)
+
+
+## 可选集群服务
+
+
+*  [DNS 与 SkyDNS 集成](/docs/concepts/services-networking/dns-pod-service/)描述了如何将一个 DNS 名解析到一个Kubernetes service。
+
+
+* [记录和监控集群活动](/docs/concepts/cluster-administration/logging/) 阐述了Kubernetes 的日志如何工作以及怎样实现。
+
+{% endcapture %}
+
+{% include templates/concept.md %}

cn/docs/concepts/cluster-administration/federation.md

@@ -0,0 +1,116 @@
+---
+title: 联邦
+---
+
+{% capture overview %}
+本页面阐明了为何以及如何使用联邦创建Kubernetes集群。
+{% endcapture %}
+
+{% capture body %}
+## 为何使用联邦
+
+联邦可以使多个集群的管理简单化。它提供了两个主要构件模块：
+
+  * 跨集群同步资源：联邦能够让资源在多个集群中同步。例如，你可以确保在多个集群中存在同样的部署。
+  * 跨集群发现：联邦能够在所有集群的后端自动配置DNS服务和负载均衡。例如，通过多个集群的后端，你可以确保全局的VIP或DNS记录可用。
+
+联邦技术的其他应用场景：
+
+* 高可用性：通过跨集群分摊负载，自动配置DNS服务和负载均衡，联邦将集群失败所带来的影响降到最低。
+* 避免供应商锁定：跨集群使迁移应用程序变得更容易，联邦服务避免了供应商锁定。
+
+
+只有在多个集群的场景下联邦服务才是有帮助的。这里列出了一些你会使用多个集群的原因：
+
+* 降低延迟：在多个区域含有集群，可使用离用户最近的集群来服务用户，从而最大限度降低延迟。
+* 故障隔离：对于故障隔离，也许有多个小的集群比有一个大的集群要更好一些（例如：一个云供应商的不同可用域里有多个集群）。详细信息请参阅[多集群指南](/docs/admin/multi-cluster)。
+* 可伸缩性：对于单个kubernetes集群是有伸缩性限制的（但对于大多数用户来说并非如此。更多细节参考[Kubernetes扩展和性能目标](https://git.k8s.io/community/sig-scalability/goals.md)）。
+* [混合云](#混合云的能力)：可以有多个集群，它们分别拥有不同的云供应商或者本地数据中心。
+
+### 注意事项
+
+虽然联邦有很多吸引人的场景，但这里还是有一些需要关注的事项：
+
+* 增加网络的带宽和损耗：联邦控制面会监控所有的集群，来确保集群的当前状态与预期一致。那么当这些集群运行在一个或者多个云提供者的不同区域中，则会带来重大的网络损耗。
+* 降低集群的隔离：当联邦控制面中存在一个故障时，会影响所有的集群。把联邦控制面的逻辑降到最小可以缓解这个问题。 无论何时，它都是kubernetes集群里控制面的代表。设计和实现也使其变得更安全,避免多集群运行中断。
+* 完整性：联邦项目相对较新，还不是很成熟。不是所有资源都可用，且很多资源才刚刚开始。[Issue 38893](https://github.com/kubernetes/kubernetes/issues/38893) 列举了一些团队正忙于解决的系统已知问题。
+
+### 混合云的能力
+
+Kubernetes集群里的联邦包括运行在不同云供应商上的集群（例如，谷歌云、亚马逊），和本地部署的集群（例如，OpenStack）。只需在适当的云供应商和/或位置创建所需的所有集群，并将每个集群的API endpoint和凭据注册到您的联邦API服务中（详情参考[联邦管理指南](/docs/admin/federation/)）。
+
+在此之后，您的[API资源](#api资源)就可以跨越不同的集群和云供应商。
+
+## 建立联邦
+
+若要能联合多个集群，首先需要建立一个联邦控制面。参照[安装指南](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) 建立联邦控制面。
+
+## API资源
+
+控制面建立完成后，就可以开始创建联邦API资源了。
+以下指南详细介绍了一些资源：
+
+* [Cluster](/docs/tasks/administer-federation/cluster/)
+* [ConfigMap](/docs/tasks/administer-federation/configmap/)
+* [DaemonSets](/docs/tasks/administer-federation/daemonset/)
+* [Deployment](/docs/tasks/administer-federation/deployment/)
+* [Events](/docs/tasks/administer-federation/events/)
+* [Ingress](/docs/tasks/administer-federation/ingress/)
+* [Namespaces](/docs/tasks/administer-federation/namespaces/)
+* [ReplicaSets](/docs/tasks/administer-federation/replicaset/)
+* [Secrets](/docs/tasks/administer-federation/secret/)
+* [Services](/docs/concepts/cluster-administration/federation-service-discovery/)
+
+[API参考文档](/docs/reference/federation/)列举了联邦API服务支持的所有资源。
+
+## 级联删除
+
+Kubernetes1.6版本支持联邦资源级联删除。使用级联删除，即当删除联邦控制面的一个资源时，也删除了所有底层集群中的相应资源。
+
+当使用REST API时，级联删除功能不是默认开启的。若使用REST API从联邦控制面删除一个资源时，要开启级联删除功能，即需配置选项 `DeleteOptions.orphanDependents=false`。使用`kubectl delete`使级联删除功能默认开启。使用`kubectl delete --cascade=false`禁用级联删除功能。
+
+注意：Kubernetes1.5版本开始支持联邦资源子集的级联删除。
+
+## 单个集群的范围
+
+对于IaaS供应商如谷歌计算引擎或亚马逊网络服务，一个虚拟机存在于一个[域](https://cloud.google.com/compute/docs/zones)或[可用域](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)中。
+我们建议一个Kubernetes集群里的所有虚机应该在相同的可用域里，因为：
+
+  - 与单一的全局Kubernetes集群对比，该方式有较少的单点故障。
+  - 与跨可用域的集群对比，该方式更容易推断单区域集群的可用性属性。
+  - 当Kubernetes开发者设计一个系统(例如，对延迟、带宽或相关故障进行假设)，他们也会假设所有的机器都在一个单一的数据中心，或者以其他方式紧密相连。
+
+每个可用区域里包含多个集群当然是可以的，但是总的来说我们认为集群数越少越好。
+偏爱较少集群数的原因是：
+
+  - 在某些情况下，在一个集群里有更多的节点，可以改进Pods的装箱问题（更少的资源碎片）。
+  - 减少操作开销（尽管随着OPS工具和流程的成熟而降低了这块的优势）。
+  - 为每个集群的固定资源花费降低开销，例如，使用apiserver的虚拟机（但是在全体集群开销中，中小型集群的开销占比要小的多）。
+
+多集群的原因包括：
+
+  - 严格的安全性策略要求隔离一类工作与另一类工作（但是，请参见下面的集群分割）。
+  - 测试集群或其他集群软件直至最优的新Kubernetes版本发布。
+
+## 选择合适的集群数
+
+Kubernetes集群数量选择也许是一个相对静止的选择，因为对其重新审核的情况很少。相比之下，一个集群中的节点数和一个服务中的pods数可能会根据负载和增长频繁变化。
+
+选择集群的数量，首先，需要决定哪些区域对于将要运行在Kubernetes上的服务，可以有足够的时间到达所有的终端用户（如果使用内容分发网络，则不需要考虑CDN-hosted内容的延迟需求）。法律问题也可能影响这一点。例如，拥有全球客户群的公司可能会对于在美国、欧盟、亚太和南非地区拥有集群起到决定权。使用`R`代表区域的数量。
+
+其次，决定有多少集群在同一时间不可用，而一些仍然可用。使用`U`代表不可用的数量。如果不确定，最好选择1。
+
+如果允许负载均衡在集群故障发生时将通信引导到任何区域，那么至少需要较大的`R`或`U + 1`集群。若非如此（例如，若要在集群故障发生时确保所有用户的低延迟），则需要`R * (U + 1)`集群(在每一个`R`区域里都有`U + 1`)。在任何情况下，尝试将每个集群放在不同的区域中。
+
+最后，如果你的集群需求超过一个Kubernetes集群推荐的最大节点数，那么你可能需要更多的集群。Kubernetes1.3版本支持多达1000个节点的集群规模。
+
+{% endcapture %}
+
+{% capture whatsnext %}
+* 进一步学习[联邦提案](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/federation.md)。
+* 集群联邦参考该[配置指导](/docs/tutorials/federation/set-up-cluster-federation-kubefed/)。
+* 查看[Kubecon2016浅谈联邦](https://www.youtube.com/watch?v=pq9lbkmxpS8)
+{% endcapture %}
+
+{% include templates/concept.md %}
+

cn/docs/concepts/cluster-administration/sysctl-cluster.md

@@ -0,0 +1,101 @@
+---
+approvers:
+- sttts
+title: Kubernetes集群中使用Sysctls
+---
+
+* TOC
+{:toc}
+
+这篇文章描述了如何在Kubernetes集群中使用Sysctls。
+
+## 什么是Sysctl？
+
+在Linux中，Sysctl接口允许管理员在内核运行时修改内核参数。这些可用参数都存在于虚拟进程文件系统中的`/proc/sys/`目录。这些内核参数作用于各种子系统中，例如：
+
+- 内核 (通用前缀：`kernel.`)
+- 网络 (通用前缀：`net.`)
+- 虚拟内存 (通用前缀：`vm.`)
+- 设备专用 (通用前缀：`dev.`)
+- 更多子系统描述见 [Kernel docs](https://www.kernel.org/doc/Documentation/sysctl/README).
+
+获取所有参数列表，可运行
+
+```
+$ sudo sysctl -a
+```
+
+## 命名空间级vs.节点级Sysctls
+
+在今天的Linux内核系统中有一些Sysctls是 _命名空间级_ 的。这意味着他们在同节点的不同pod间是可配置成独立的。在kubernetes里，命名空间级是Sysctls的一个必要条件，以使其在一个pod语境里易于理解。
+
+以下列出了Sysctls中已知的 _命名空间级_ ：
+
+- `kernel.shm*`（内核中共享内存相关参数），
+- `kernel.msg*`（内核中SystemV消息队列相关参数），
+- `kernel.sem`（内核中信号量参数），
+- `fs.mqueue.*`（内核中POSIX消息队列相关参数），
+- `net.*`（内核中网络配置项相关参数）。
+
+Sysctls中非命名空间级的被称为 _节点级_ ，其必须由集群管理员手动设置，要么通过节点的底层Linux分布方式(例如，通过 `/etc/sysctls.conf`)，亦或在特权容器中使用Daemonset。
+
+**注意**: 这是很好的做法，考虑在一个集群里给有特殊sysctl的节点设置为 _污点_ ，并且给他们安排仅需要这些sysctl设置的pods。 建议采用Kubernetes [_污点和容点_
+特征](/docs/user-guide/kubectl/{{page.version}}/#taint) 来实现。
+
+## 安全的 vs. 不安全的 Sysctls
+
+Sysctls被分为 _安全的_ 和 _不安全的_ sysctls。同一节点上的pods间除了适当命名空间命名一个 _安全的_ sysctl，还必须适当的 _隔离_ 。 这意味着给一个pod设置一个 _安全的_ sysctl
+
+- 不能对相同节点上其他pod产生任何影响
+- 不能对节点的健康造成损害
+- 不能在pod资源限制以外获取更多的CPU和内存资源
+
+目前看来，大多数的 _命名空间级_ sysctls 不一定被认为是 _安全的_ 。
+
+在Kubernetes 1.4版本中，以下sysctls提供了 _安全的_ 配置：
+
+- `kernel.shm_rmid_forced`,
+- `net.ipv4.ip_local_port_range`,
+- `net.ipv4.tcp_syncookies`.
+
+该列表在未来的Kubernetes版本里还会继续扩充，当kubelet提供更好的隔离机制时。
+
+所有 _安全的_ sysctls 都是默认启用的。
+
+所有 _不安全的_ sysctls 默认是关闭的，且必须通过每个节点基础上的集群管理手动开启。禁用不安全的sysctls的Pods将会被计划，但不会启动。
+
+**警告**: 由于他们的本质是 _不安全的_ ，使用 _不安全的_ sysctls是自担风险的，并且会导致严重的问题，例如容器的错误行为，资源短缺或者是一个节点的完全破损。
+
+## 使能不安全的Sysctls
+
+牢记上面的警告， 在非常特殊的情况下，例如高性能指标或是实时应用程序优化，集群管理员可以允许 _不安全的_
+sysctls。 _不安全的_ sysctls 会打上kubelet标识，在逐节点的基础上被启用，例如：
+
+```shell
+$ kubelet --experimental-allowed-unsafe-sysctls 'kernel.msg*,net.ipv4.route.min_pmtu' ...
+```
+
+只有 _命名空间级_ sysctls 可以使用该方法启用。
+
+## 给Pod配置Sysctls
+
+在Kubernetes 1.4版本中，sysctl特性是一个alpha API。因此，sysctls被设置为在pods上使用注释。它们适用于同一个pod上的所有容器。
+
+这里列举了一个例子， _安全的_ 和 _不安全的_ sysctls使用不同的注释:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: sysctl-example
+  annotations:
+    security.alpha.kubernetes.io/sysctls: kernel.shm_rmid_forced=1
+    security.alpha.kubernetes.io/unsafe-sysctls: net.ipv4.route.min_pmtu=1000,kernel.msgmax=1 2 3
+spec:
+  ...
+```
+
+**注意**: 包含以上规定的 _不安全的_ sysctls的一个Pod， 将无法启动任何不能使这两个 _不安全的_ sysctls明确的节点。 推荐
+_节点级_ sysctls使用 [_容点和污点_
+特征](/docs/user-guide/kubectl/v1.6/#taint) or [taints on nodes](/docs/concepts/configuration/taint-and-toleration/)
+来将这些pods分配到正确的nodes上。

cn/docs/concepts/configuration/commands.yaml

@@ -0,0 +1,12 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: command-demo
+  labels:
+    purpose: demonstrate-command
+spec:
+  containers:
+  - name: command-demo-container
+    image: debian
+    command: ["printenv"]
+    args: ["HOSTNAME", "KUBERNETES_PORT"]

cn/docs/concepts/configuration/overview.md

@@ -0,0 +1,93 @@
+---
+approvers:
+- mikedanese
+title: Configuration Best Practices
+---
+
+{% capture overview %}
+This document highlights and consolidates configuration best practices that are introduced throughout the user-guide, getting-started documentation, and examples.
+
+This is a living document. If you think of something that is not on this list but might be useful to others, please don't hesitate to file an issue or submit a PR.
+{% endcapture %}
+
+{% capture body %}
+## General Config Tips
+
+- When defining configurations, specify the latest stable API version (currently v1).
+
+- Configuration files should be stored in version control before being pushed to the cluster. This allows quick roll-back of a configuration if needed. It also aids with cluster re-creation and restoration if necessary.
+
+- Write your configuration files using YAML rather than JSON. Though these formats can be used interchangeably in almost all scenarios, YAML tends to be more user-friendly.
+
+- Group related objects into a single file whenever it makes sense. One file is often easier to manage than several. See the [guestbook-all-in-one.yaml](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/guestbook/all-in-one/guestbook-all-in-one.yaml) file as an example of this syntax.
+
+  Note also that many `kubectl` commands can be called on a directory, so you can also call `kubectl create` on a directory of config files. See below for more details.
+
+- Don't specify default values unnecessarily, in order to simplify and minimize configs, and to reduce error. For example, omit the selector and labels in a `ReplicationController` if you want them to be the same as the labels in its `podTemplate`, since those fields are populated from the `podTemplate` labels by default. See the [guestbook app's](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/guestbook/) .yaml files for some [examples](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/guestbook/frontend-deployment.yaml) of this.
+
+- Put an object description in an annotation to allow better introspection.
+
+
+## "Naked" Pods vs Replication Controllers and Jobs
+
+- If there is a viable alternative to naked pods (in other words: pods not bound to a [replication controller](/docs/user-guide/replication-controller)), go with the alternative. Naked pods will not be rescheduled in the event of node failure.
+
+  Replication controllers are almost always preferable to creating pods, except for some explicit [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) scenarios. A [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) object (currently in Beta) may also be appropriate.
+
+
+## Services
+
+- It's typically best to create a [service](/docs/concepts/services-networking/service/) before corresponding [replication controllers](/docs/concepts/workloads/controllers/replicationcontroller/). This lets the scheduler spread the pods that comprise the service.
+
+  You can also use this process to ensure that at least one replica works before creating lots of them:
+
+    1. Create a replication controller without specifying replicas (this will set replicas=1);
+    2. Create a service;
+    3. Then scale up the replication controller.
+
+- Don't use `hostPort` unless it is absolutely necessary (for example: for a node daemon). It specifies the port number to expose on the host. When you bind a Pod to a `hostPort`, there are a limited number of places to schedule a pod due to port conflicts— you can only schedule as many such Pods as there are nodes in your Kubernetes cluster.
+
+  If you only need access to the port for debugging purposes, you can use the [kubectl proxy and apiserver proxy](/docs/tasks/access-kubernetes-api/http-proxy-access-api/) or [kubectl port-forward](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
+  You can use a [Service](/docs/concepts/services-networking/service/) object for external service access.
+
+  If you explicitly need to expose a pod's port on the host machine, consider using a [NodePort](/docs/user-guide/services/#type-nodeport) service before resorting to `hostPort`.
+
+- Avoid using `hostNetwork`, for the same reasons as `hostPort`.
+
+- Use _headless services_ for easy service discovery when you don't need kube-proxy load balancing. See [headless services](/docs/user-guide/services/#headless-services).
+
+## Using Labels
+
+- Define and use [labels](/docs/user-guide/labels/) that identify __semantic attributes__ of your application or deployment. For example, instead of attaching a label to a set of pods to explicitly represent some service (For example, `service: myservice`), or explicitly representing the replication controller managing the pods  (for example, `controller: mycontroller`), attach labels that identify semantic attributes, such as `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. This will let you select the object groups appropriate to the context— for example, a service for all "tier: frontend" pods, or all "test" phase components of app "myapp". See the [guestbook](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/guestbook/) app for an example of this approach.
+
+  A service can be made to span multiple deployments, such as is done across [rolling updates](/docs/tasks/run-application/rolling-update-replication-controller/), by simply omitting release-specific labels from its selector, rather than updating a service's selector to match the replication controller's selector fully.
+
+- To facilitate rolling updates, include version info in replication controller names, for example as a suffix to the name. It is useful to set a 'version' label as well. The rolling update creates a new controller as opposed to modifying the existing controller. So, there will be issues with version-agnostic controller names. See the [documentation](/docs/tasks/run-application/rolling-update-replication-controller/) on the rolling-update command for more detail.
+
+  Note that the [Deployment](/docs/concepts/workloads/controllers/deployment/) object obviates the need to manage replication controller 'version names'. A desired state of an object is described by a Deployment, and if changes to that spec are _applied_, the deployment controller changes the actual state to the desired state at a controlled rate. (Deployment objects are currently part of the [`extensions` API Group](/docs/concepts/overview/kubernetes-api/#api-groups).)
+
+- You can manipulate labels for debugging. Because Kubernetes replication controllers and services match to pods using labels, this allows you to remove a pod from being considered by a controller, or served traffic by a service, by removing the relevant selector labels. If you remove the labels of an existing pod, its controller will create a new pod to take its place. This is a useful way to debug a previously "live" pod in a quarantine environment. See the [`kubectl label`](/docs/concepts/overview/working-with-objects/labels/) command.
+
+## Container Images
+
+- The [default container image pull policy](/docs/concepts/containers/images/) is `IfNotPresent`, which causes the [Kubelet](/docs/admin/kubelet/) to not pull an image if it already exists. If you would like to always force a pull, you must specify a pull image policy of `Always` in your .yaml file (`imagePullPolicy: Always`) or specify a `:latest` tag on your image.
+
+  That is, if you're specifying an image with other than the `:latest` tag, for example `myimage:v1`, and there is an image update to that same tag, the Kubelet won't pull the updated image. You can address this by ensuring that any updates to an image bump the image tag as well (for example, `myimage:v2`), and ensuring that your configs point to the correct version.
+
+  **Note:** You should avoid using `:latest` tag when deploying containers in production, because this makes it hard to track which version of the image is running and hard to roll back.
+
+- To work only with a specific version of an image, you can specify an image with its digest (SHA256). This approach guarantees that the image will never update. For detailed information about working with image digests, see [the Docker documentation](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier).
+
+## Using kubectl
+
+- Use `kubectl create -f <directory>` where possible. This looks for config objects in all `.yaml`, `.yml`, and `.json` files in `<directory>` and passes them to `create`.
+
+- Use `kubectl delete` rather than `stop`. `Delete` has a superset of the functionality of `stop`, and `stop` is deprecated.
+
+- Use kubectl bulk operations (via files and/or labels) for get and delete. See [label selectors](/docs/user-guide/labels/#label-selectors) and [using labels effectively](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
+
+- Use `kubectl run` and `expose` to quickly create and expose single container Deployments. See the [quick start guide](/docs/user-guide/quick-start/) for an example.
+
+{% endcapture %}
+
+{% include templates/concept.md %}

cn/docs/concepts/configuration/pod-with-node-affinity.yaml

@@ -0,0 +1,26 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: with-node-affinity
+spec:
+  affinity:
+    nodeAffinity:
+      requiredDuringSchedulingIgnoredDuringExecution:
+        nodeSelectorTerms:
+        - matchExpressions:
+          - key: kubernetes.io/e2e-az-name
+            operator: In
+            values:
+            - e2e-az1
+            - e2e-az2
+      preferredDuringSchedulingIgnoredDuringExecution:
+      - weight: 1
+        preference:
+          matchExpressions:
+          - key: another-node-label-key
+            operator: In
+            values:
+            - another-node-label-value
+  containers:
+  - name: with-node-affinity
+    image: gcr.io/google_containers/pause:2.0

cn/docs/concepts/configuration/pod-with-pod-affinity.yaml

@@ -0,0 +1,29 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: with-pod-affinity
+spec:
+  affinity:
+    podAffinity:
+      requiredDuringSchedulingIgnoredDuringExecution:
+      - labelSelector:
+          matchExpressions:
+          - key: security
+            operator: In
+            values:
+            - S1
+        topologyKey: failure-domain.beta.kubernetes.io/zone
+    podAntiAffinity:
+      preferredDuringSchedulingIgnoredDuringExecution:
+      - weight: 100
+        podAffinityTerm:
+          labelSelector:
+            matchExpressions:
+            - key: security
+              operator: In
+              values:
+              - S2
+          topologyKey: kubernetes.io/hostname
+  containers:
+  - name: with-pod-affinity
+    image: gcr.io/google_containers/pause:2.0

cn/docs/concepts/configuration/pod.yaml

@@ -0,0 +1,13 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+  labels:
+    env: test
+spec:
+  containers:
+  - name: nginx
+    image: nginx
+    imagePullPolicy: IfNotPresent
+  nodeSelector:
+    disktype: ssd

cn/docs/concepts/containers/images.md

@@ -0,0 +1,296 @@
+---
+approvers:
+- erictune
+- thockin
+title: 镜像
+---
+
+{% capture overview %}
+
+在Kubernetes pod中引用镜像前，请创建Docker镜像，并将之推送到镜像仓库中。
+容器的“image”属性支持和Docker命令行相同的语法，包括私有仓库和标签。
+
+{% endcapture %}
+
+{:toc}
+
+{% capture body %}
+
+## 升级镜像
+默认的镜像拉取策略是“IfNotPresent”，在镜像已经存在的情况下，kubelet将不在去拉取镜像。
+如果总是想要拉取镜像，必须设置拉取策略为“Always”或者设置镜像标签为“:latest”。
+
+如果没有指定镜像的标签，它会被假定为“:latest”,同时拉取策略为“Always”。
+
+注意应避免使用“:latest”标签，参见 [Best Practices for Configuration](/docs/concepts/configuration/overview/#container-images) 获取更多信息。
+
+## 使用私有仓库
+
+从私有仓库读取镜像时可能需要密钥。
+凭证可以用以下方式提供:
+
+  - 使用Google Container Registry
+    - 每个集群分别配置
+	- 在Google Compute Engine 或者 Google Container Engine上自动配置
+	- 所有的pod都能读取项目的私有仓库
+  - 使用 AWS EC2 Container Registry (ECR)
+    - 使用IAM角色和策略来控制对ECR仓库的访问
+	- 自动刷新ECR的登录凭证
+  - 使用 Azure Container Registry (ACR)
+  - 配置节点对私有仓库认证
+    - 所有的pod都可以读取已配置的私有仓库
+	- 需要集群管理员提供node的配置
+  - 提前拉取镜像
+	- 所有的pod都可以使用node上缓存的镜像
+	- 需要以root进入node操作
+  - pod上指定 ImagePullSecrets
+    - 只有提供了密钥的pod才能接入私有仓库
+下面将详细描述每一项
+
+
+### 使用 Google Container Registry
+Kuberetes运行在Google Compute Engine (GCE)时原生支持[Google ContainerRegistry (GCR)]
+(https://cloud.google.com/tools/container-registry/)。如果kubernetes集群运行在GCE
+或者Google Container Engine (GKE)上，使用镜像全名(e.g. gcr.io/my_project/image:tag)即可。
+
+集群中的所有pod都会有读取这个仓库中镜像的权限。
+
+Kubelet将使用实例的Google service account向GCR认证。实例的service account拥有
+`https://www.googleapis.com/auth/devstorage.read_only`，所以它可以从项目的GCR拉取，但不能推送。
+	
+### 使用 AWS EC2 Container Registry
+
+当Node是AWS EC2实例时，Kubernetes原生支持[AWS EC2 ContainerRegistry](https://aws.amazon.com/ecr/)。
+
+在pod定义中，使用镜像全名即可 (例如 `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`)
+
+集群中可以创建pod的用户都可以使用ECR中的任意镜像运行pod。
+
+Kubelet会获取并且定期刷新ECR的凭证。它需要以下权限
+
+- `ecr:GetAuthorizationToken`
+- `ecr:BatchCheckLayerAvailability`
+- `ecr:GetDownloadUrlForLayer`
+- `ecr:GetRepositoryPolicy`
+- `ecr:DescribeRepositories`
+- `ecr:ListImages`
+- `ecr:BatchGetImage`
+
+要求：
+
+- 必须使用kubelet 1.2.0及以上版本
+- 如果node在区域A，而镜像仓库在另一个区域B，需要1.3.0及以上版本
+- 区域中必须提供ECR
+
+诊断
+
+- 验证是否满足以上要求
+- 获取工作站的$REGION (例如 `us-west-2`)凭证，使用凭证SSH到主机手动运行docker，检查是否运行
+- 验证kublet是否使用参数`--cloud-provider=aws`运行
+- 检查kubelet日志(例如 `journalctl -u kubelet`)，是否有类似的行
+  - `plugins.go:56] Registering credential provider: aws-ecr-key`
+  - `provider.go:91] Refreshing cache for provider: *aws_credentials.ecrProvider`
+
+### 使用 Azure Container Registry (ACR)
+当使用[Azure Container Registry](https://azure.microsoft.com/en-us/services/container-registry/)时，可以使用admin user或者service principal认证。
+任何一种情况，认证都通过标准的Dokcer authentication完成。本指南假设使用[azure-cli](https://github.com/azure/azure-cli)
+命令行工具。
+
+首先，需要创建仓库并获取凭证，完整的文档请参考
+[Azure container registry documentation](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-azure-cli)。
+
+创建好容器仓库后，可以使用以下凭证登录：
+
+   * `DOCKER_USER` : service principal, or admin username
+   * `DOCKER_PASSWORD`: service principal password, or admin user password
+   * `DOCKER_REGISTRY_SERVER`: `${some-registry-name}.azurecr.io`
+   * `DOCKER_EMAIL`: `${some-email-address}`
+
+填写以上变量后，就可以
+[configure a Kubernetes Secret and use it to deploy a Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)。
+
+
+### 配置Nodes对私有仓库认证
+
+**注意：** 如果在Google Container Engine (GKE)上运行集群，每个节点上都会有`.dockercfg`文件，它包含对Google Container Registry的凭证。
+不需要使用以下方法。
+
+**注意：** 如果在AWS EC2上运行集群且准备使用EC2 Container Registry (ECR)，每个node上的kubelet会管理和更新ECR的登录凭证。不需要使用以下方法。
+
+**注意：** 该方法适用于能够对节点进行配置的情况。该方法在GCE及在其它能自动配置节点的云平台上并不适合。
+
+Docker将私有仓库的密钥存放在`$HOME/.dockercfg`或`$HOME/.docker/config.json`文件中。Kubelet上，docker会使用root用户`$HOME`路径下的密钥。
+
+推荐如下步骤来为node配置私有仓库。以下示例在PC或笔记本电脑中操作
+
+   1.对于想要使用的每一种凭证，运行 `docker login [server]`，它会更新`$HOME/.docker/config.json`。
+   1.使用编辑器查看`$HOME/.docker/config.json`，保证文件中包含了想要使用的凭证
+   1.获取node列表，例如
+     - 如果使用node名称，`nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')`
+	 - 如果使用node IP ，`nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')`
+   1.将本地的`.docker/config.json`拷贝到每个节点root用户目录下
+     - 例如： `for n in $nodes; do scp ~/.docker/config.json root@$n:/root/.docker/config.json; done`
+	 
+创建使用私有仓库的pod来验证，例如：
+
+```yaml
+$ cat <<EOF > /tmp/private-image-test-1.yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: private-image-test-1
+spec:
+  containers:
+    - name: uses-private-image
+      image: $PRIVATE_IMAGE_NAME
+      imagePullPolicy: Always
+      command: [ "echo", "SUCCESS" ]
+EOF
+$ kubectl create -f /tmp/private-image-test-1.yaml
+pod "private-image-test-1" created
+$
+```
+
+如果一切正常，一段时间后，可以看到:
+
+```shell
+$ kubectl logs private-image-test-1
+SUCCESS
+```
+
+如果失败，则可以看到：
+
+```shell
+$ kubectl describe pods/private-image-test-1 | grep "Failed"
+  Fri, 26 Jun 2015 15:36:13 -0700    Fri, 26 Jun 2015 15:39:13 -0700    19    {kubelet node-i2hq}    spec.containers{uses-private-image}    failed        Failed to pull image "user/privaterepo:v1": Error: image user/privaterepo:v1 not found
+```
+
+
+必须保证集群中所有的节点都有相同的`.docker/config.json`文件。否则,pod会在一些节点上正常运行而在另一些节点上无法启动
+例如，如果使用node自动弹缩，那么每个实例模板都需要包含`.docker/config.json`，或者挂载一个包含这个文件的驱动器。
+
+在`.docker/config.json`中配置了私有仓库密钥后，所有pod都会能读取私有仓库中的镜像。
+
+**该方法已在6月26日的docker私有仓库和kubernetes v0.19.3上测试通过，其他私有仓库，如quay.io应该也可以运行，但未测试过。**
+
+### 提前拉取镜像
+
+**注意：** 如果在Google Container Engine (GKE)上运行集群，每个节点上都会有`.dockercfg`文件，它包含对Google Container Registry的凭证。
+不需要使用以下方法。
+
+**注意：** 该方法适用于能够对节点进行配置的情况。该方法在GCE及在其它能自动配置节点的云平台上并不适合。
+
+默认情况下，kubelet会尝试从指定的仓库拉取每一个镜像
+但是，如果容器属性`imagePullPolicy`设置为`IfNotPresent`或者`Never`，
+则会使用本地镜像（优先、唯一、分别）。
+
+如果依赖提前拉取镜像代替仓库认证，
+必须保证集群所有的节点提前拉取的镜像是相同的。
+
+可以用于提前载入指定的镜像以提高速度，或者作为私有仓库认证的一种替代方案
+
+所有的pod都可以使用node上缓存的镜像
+
+### 在pod上指定ImagePullSecrets
+
+**注意:** GKE,GCE及其他自动创建node的云平台上，推荐使用本方法。
+
+Kuberentes支持在pod中指定仓库密钥。
+
+#### 使用Docker Config创建Secret
+
+运行以下命令，将大写字母代替为合适的值
+
+```shell
+$ kubectl create secret docker-registry myregistrykey --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
+secret "myregistrykey" created.
+```
+
+如果需要接入多个仓库，可以为每个仓库创建一个secret。
+当为pod拉取镜像时，kubelet会将`imagePullSecrets`合入一个独立虚拟的`.docker/config.json`。
+
+Pod只能引用和它相同namespace的ImagePullSecrets，
+所以需要为每一个namespace做配置
+
+#### 通过kubectl创建secret
+
+由于某种原因在一个`.docker/config.json`中需要多个项或者需要非上述命令给出的secret，可以[create a secret using
+json or yaml](/docs/user-guide/secrets/#creating-a-secret-manually)。
+
+请保证：
+
+- 设置data项的名称为`.dockerconfigjson`
+- 使用base64对docker文件编码，并将字符准确黏贴到`data[".dockerconfigjson"]`里
+- 设置`type`为`kubernetes.io/dockerconfigjson`
+
+示例：
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: myregistrykey
+  namespace: awesomeapps
+data:
+  .dockerconfigjson: UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx5eXl5eXl5eXl5eXl5eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==
+type: kubernetes.io/dockerconfigjson
+```
+
+如果收到错误消息`error: no objects passed to create`，可能是 base64 编码后的字符串非法。
+如果收到错误消息类似`Secret "myregistrykey" is invalid: data[.dockerconfigjson]: invalid value ...`,
+说明数据已经解码成功，但是不满足`.docker/config.json`文件的语法。
+
+#### 在pod中引用imagePullSecrets
+
+现在，在创建pod时，可以在pod定义中增加`imagePullSecrets`小节来引用secret
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: foo
+  namespace: awesomeapps
+spec:
+  containers:
+    - name: foo
+      image: janedoe/awesomeapp:v1
+  imagePullSecrets:
+    - name: myregistrykey
+```
+
+对每一个使用私有仓库的pod，都需要做以上操作。
+
+也可以在[serviceAccount](/docs/user-guide/service-accounts) 资源中设置imagePullSecrets自动设置`imagePullSecrets`
+
+`imagePullSecrets`可以和每个node上的`.docker/config.json`一起使用，他们将共同生效。本方法在Google Container Engine (GKE)
+也能正常工作。
+
+### 使用场景
+
+配置私有仓库有多种方案，以下是一些常用场景和建议的解决方案。
+
+1. 集群运行非专有（例如 开源镜像）镜像。镜像不需要隐藏。
+   - 使用Docker hub上的公有镜像
+    - 无需配置
+    - 在GCE/GKE上会自动使用高稳定性和高速的Docker hub的本地mirror
+1. 集群运行一些专有镜像，这些镜像对外部公司需要隐藏，对集群用户可见
+   - 使用自主的私有[Docker registry](https://docs.docker.com/registry/).
+     - 可以放置在[Docker Hub](https://hub.docker.com/account/signup/),或者其他地方。
+	 - 按照上面的描述，在每个节点手动配置.docker/config.json
+   - 或者，在防火墙内运行一个内置的私有仓库，并开放读取权限
+     - 不需要配置Kubenretes
+   - 或者，在GCE/GKE上时，使用项目的Google Container Registry
+     - 使用集群自动伸缩比手动配置node工作的更好
+   - 或者，在更改集群node配置不方便时，使用`imagePullSecrets`
+1. 使用专有镜像的集群，有更严格的访问控制
+   - 保证[AlwaysPullImages admission controller](/docs/admin/admission-controllers/#alwayspullimages)开启。否则，所有的pod都可以使用镜像
+   - 将敏感数据存储在"Secret"资源中，而不是打包在镜像里
+1. 多租户集群下，每个租户需要自己的私有仓库
+   - 保证[AlwaysPullImages admission controller](/docs/admin/admission-controllers/#alwayspullimages)开启。否则，所有租户的所有的pod都可以使用镜像
+   - 私有仓库开启认证
+   - 为每个租户获取仓库凭证，放置在secret中，并发布到每个租户的namespace下
+   - 租户将secret增加到每个namespace下的imagePullSecrets中
+
+{% endcapture %}
+
+{% include templates/concept.md %}

cn/docs/concepts/example-concept-template.md

@@ -0,0 +1,36 @@
+---
+title: 概念模板示例
+approvers:
+- chenopis
+---
+
+{% capture overview %}
+
+**注意:** 注意为新文档 [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) 。
+
+本页解释了 ...
+
+{% endcapture %}
+
+{% capture body %}
+
+## 了解 ...
+
+Kubernetes 提供 ...
+
+## 使用 ...
+
+使用 ...
+
+{% endcapture %}
+
+{% capture whatsnext %}
+
+**[可选章节]**
+
+* 了解更多 [Writing a New Topic](/docs/home/contribute/write-new-topic/)。
+* 查看 [Using Page Templates - Concept template](/docs/home/contribute/page-templates/#concept_template) 了解如何使用本模板。
+
+{% endcapture %}
+
+{% include templates/concept.md %}

cn/docs/concepts/overview/components.md

@@ -0,0 +1,124 @@
+---
+assignees:
+- lavalamp
+title: Kubernetes 组件
+redirect_from:
+- "/docs/admin/cluster-components/"
+- "/docs/admin/cluster-components.html"
+---
+{% capture overview %}
+本文档概述了 Kubernetes 所需的各种二进制组件, 用于提供齐全的功能。
+{% endcapture %}
+
+{% capture body %}
+
+## Master 组件
+
+Master 组件提供的集群控制。Master 组件对集群做出全局性决策(例如：调度)，以及检测和响应集群事件(副本控制器的`replicas`字段不满足时,启动新的副本)。
+
+Master 组件可以在集群中的任何节点上运行。然而，为了简单起见，设置脚本通常会启动同一个虚拟机上所有 Master 组件，并且不会在此虚拟机上运行用户容器。请参阅[构建高可用性群集](/docs/admin/high-availability)示例对于多主机 VM 的设置。
+
+### API服务器
+
+[kube-apiserver](/docs/admin/kube-apiserver)对外暴露了Kubernetes API。它是的 Kubernetes 前端控制层。它被设计为水平扩展，即通过部署更多实例来缩放。请参阅[构建高可用性群集](/docs/admin/high-availability).
+
+### etcd
+
+[etcd](/docs/admin/etcd) 用于 Kubernetes 的后端存储。所有集群数据都存储在此处，始终为您的 Kubernetes 集群的 etcd 数据提供备份计划。
+
+### kube-controller-manager
+
+[kube-controller-manager](/docs/admin/kube-controller-manager)运行控制器，它们是处理集群中常规任务的后台线程。逻辑上，每个控制器是一个单独的进程，但为了降低复杂性，它们都被编译成独立的可执行文件，并在单个进程中运行。
+
+这些控制器包括:
+
+* 节点控制器: 当节点移除时，负责注意和响应。
+* 副本控制器: 负责维护系统中每个副本控制器对象正确数量的 Pod。
+* 端点控制器: 填充 端点(Endpoints) 对象(即连接 Services & Pods)。
+* 服务帐户和令牌控制器: 为新的命名空间创建默认帐户和 API 访问令牌.
+
+### 云控制器管理器-(cloud-controller-manager)
+
+cloud-controller-manager 是用于与底层云提供商交互的控制器。云控制器管理器二进制是 Kubernetes v1.6 版本中引入的 Alpha 功能。
+
+cloud-controller-manager 仅运行云提供商特定的控制器循环。您必须在 kube-controller-manager 中禁用这些控制器循环，您可以通过在启动 kube-controller-manager 时将 `--cloud-provider` 标志设置为`external`来禁用控制器循环。
+
+cloud-controller-manager 允许云供应商代码和 Kubernetes 核心彼此独立发展，在以前的版本中，Kubernetes 核心代码依赖于云提供商特定的功能代码。在未来的版本中，云供应商的特定代码应由云供应商自己维护，并与运行 Kubernetes 的云控制器管理器相关联。
+
+以下控制器具有云提供商依赖关系:
+
+* 节点控制器: 用于检查云提供商以确定节点是否在云中停止响应后被删除
+* 路由控制器: 用于在底层云基础架构中设置路由
+* 服务控制器: 用于创建，更新和删除云提供商负载平衡器
+* 数据卷控制器: 用于创建，附加和装载卷，并与云提供商进行交互以协调卷
+
+### 调度器 - (kube-scheduler)
+
+[kube-scheduler](/docs/admin/kube-scheduler)监视没有分配节点的新创建的 Pod，选择一个节点供他们运行。
+
+### 插件(addons)
+
+插件是实现集群功能的 Pod 和 Service。 Pods 可以通过 Deployments，ReplicationControllers 管理。插件对象本身是受命名空间限制的，被创建于 `kube-system` 命名空间。
+
+Addon 管理器用于创建和维护附加资源. 有关详细信息，请参阅[here](http://releases.k8s.io/HEAD/cluster/addons).
+
+#### DNS
+
+虽然其他插件并不是必需的，但所有 Kubernetes 集群都应该具有[Cluster DNS](/docs/concepts/services-networking/dns-pod-service/)，许多示例依赖于它。
+
+Cluster DNS 是一个 DNS 服务器，和您部署环境中的其他 DNS 服务器一起工作，为 Kubernetes 服务提供DNS记录。
+
+Kubernetes 启动的容器自动将 DNS 服务器包含在 DNS 搜索中。
+
+#### 用户界面
+
+dashboard 提供了集群状态的只读概述。有关更多信息，请参阅[使用HTTP代理访问 Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api/)
+
+
+#### 容器资源监控
+
+[容器资源监控](/docs/user-guide/monitoring)将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面。
+
+#### 集群层面日志
+
+[集群层面日志](/docs/user-guide/logging/overview) 机制负责将容器的日志数据保存到一个集中的日志存储中，该存储能够提供搜索和浏览接口。
+
+## 节点组件
+
+节点组件在每个节点上运行，维护运行的 Pod 并提供 Kubernetes 运行时环境。
+
+### kubelet
+
+[kubelet](/docs/admin/kubelet)是主要的节点代理,它监测已分配给其节点的 Pod(通过 apiserver 或通过本地配置文件)，提供如下功能:
+
+* 挂载 Pod 所需要的数据卷(Volume)。
+* 下载 Pod 的 secrets。
+* 通过 Docker 运行(或通过 rkt)运行 Pod 的容器。
+* 周期性的对容器生命周期进行探测。
+* 如果需要，通过创建 *镜像 Pod（Mirror Pod）* 将 Pod 的状态报告回系统的其余部分。
+* 将节点的状态报告回系统的其余部分。
+
+### kube-proxy
+
+[kube-proxy](/docs/admin/kube-proxy)通过维护主机上的网络规则并执行连接转发，实现了Kubernetes服务抽象。
+
+
+### docker
+
+Docker 用于运行容器。
+
+### rkt
+
+支持 rkt 运行容器作为 Docker 的试验性替代方案。
+
+### supervisord
+
+supervisord 是一个轻量级的进程监控系统，可以用来保证 kubelet 和 docker 运行。
+
+### fluentd
+
+fluentd 是一个守护进程，它有助于提供[集群层面日志](#cluster-level-logging) 集群层面的日志。
+
+{% endcapture %}
+
+{% include templates/concept.md %}

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

@@ -1,5 +1,5 @@
 ---
-assignees:
+approvers:
 - k8s-merge-robot
 
 title: 认识 Kubernetes?
@@ -93,7 +93,7 @@ Kubernetes 提供了很多的功能，总会有新的场景受益于新特性。
 
 此外，[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 之上。
+这种 [设计](https://git.k8s.io/community/contributors/design-proposals/architecture/principles.md) 使得许多其他系统可以构建在 Kubernetes 之上。
 
 #### Kubernetes 不是什么:
 

cn/docs/concepts/overview/working-with-objects/kubernetes-objects.md

@@ -0,0 +1,98 @@
+---
+title: 理解 Kubernetes 对象
+
+redirect_from:
+- "/docs/concepts/abstractions/overview/"
+- "/docs/concepts/abstractions/overview.html"
+---
+
+{% capture overview %}
+
+本页说明了 Kubernetes 对象在 Kubernetes API 中是如何表示的，以及如何在 `.yaml` 格式的文件中表示。
+{% endcapture %}
+
+{% capture body %}
+
+
+
+
+## 理解 Kubernetes 对象
+
+在 Kubernetes 系统中，*Kubernetes 对象* 是持久化的实体。Kubernetes 使用这些实体去表示整个集群的状态。特别地，它们描述了如下信息：
+
+* 哪些容器化应用在运行（以及在哪个 Node 上）
+* 可以被应用使用的资源
+* 关于应用运行时表现的策略，比如重启策略、升级策略，以及容错策略
+
+
+
+Kubernetes 对象是 “目标性记录” —— 一旦创建对象，Kubernetes 系统将持续工作以确保对象存在。通过创建对象，本质上是在告知 Kubernetes 系统，所需要的集群工作负载看起来是什么样子的，这就是 Kubernetes 集群的 **期望状态（Desired State）**。
+
+操作 Kubernetes 对象 —— 是否创建、修改，或者删除 —— 需要使用 [Kubernetes API](https://git.k8s.io/community/contributors/devel/api-conventions.md)。比如，当使用 `kubectl` 命令行接口时，CLI 会执行必要的 Kubernetes API 调用，也可以在程序中直接调用 Kubernetes API。为了实现该目标，Kubernetes 当前提供了一个 `golang` [客户端库](https://github.com/kubernetes/client-go) 
+，其它语言库（例如[Python](https://github.com/kubernetes-incubator/client-python)）也正在开发中。
+
+
+
+### 对象规约（Spec）与状态（Status）
+
+每个 Kubernetes 对象包含两个嵌套的对象字段，它们负责管理对象的配置：对象 *spec* 和 对象 *status*。
+*spec* 是必需的，它描述了对象的 *期望状态（Desired State）* —— 希望对象所具有的特征。
+*status* 描述了对象的 *实际状态（Actual State）*，它是由 Kubernetes 系统提供和更新的。在任何时刻，Kubernetes 控制面一直努力地管理着对象的实际状态以与期望状态相匹配。
+
+
+
+例如，Kubernetes Deployment 对象能够表示运行在集群中的应用。
+当创建 Deployment 时，可能需要设置 Deployment 的规约，以指定该应用需要有 3 个副本在运行。
+Kubernetes 系统读取 Deployment 规约，并启动我们所期望的该应用的 3 个实例 —— 更新状态以与规约相匹配。
+如果那些实例中有失败的（一种状态变更），Kubernetes 系统通过修正来响应规约和状态之间的不一致 —— 这种情况，会启动一个新的实例来替换。
+
+关于对象 spec、status 和 metadata 的更多信息，查看 [Kubernetes API 约定](https://git.k8s.io/community/contributors/devel/api-conventions.md)。
+
+
+
+### 描述 Kubernetes 对象
+
+当创建 KUbernetes 对象时，必须提供对象的规约，用来描述该对象的期望状态，以及关于对象的一些基本信息（例如名称）。
+当使用 KUbernetes API 创建对象时（或者直接创建，或者基于`kubectl`），API 请求必须在请求体中包含 JSON 格式的信息。
+**大多数情况下，需要在 .yaml 文件中为 `kubectl` 提供这些信息**。 
+`kubectl` 在发起 API 请求时，将这些信息转换成 JSON 格式。
+
+这里有一个 `.yaml` 示例文件，展示了 KUbernetes Deployment 的必需字段和对象规约：
+
+{% include code.html language="yaml" file="nginx-deployment.yaml" ghlink="/docs/concepts/overview/working-with-objects/nginx-deployment.yaml" %}
+
+使用类似于上面的 `.yaml` 文件来创建 Deployment，一种方式是使用 `kubectl` 命令行接口（CLI）中的 [`kubectl create`](/docs/user-guide/kubectl/v1.7/#create) 命令，将 `.yaml` 文件作为参数。下面是一个示例：
+
+```shell
+$ kubectl create -f docs/user-guide/nginx-deployment.yaml --record
+```
+
+
+输出类似如下这样：
+
+```shell
+deployment "nginx-deployment" created
+```
+
+
+
+### 必需字段
+
+在想要创建的 KUbernetes 对象对应的 `.yaml` 文件中，需要配置如下的字段：
+
+* `apiVersion` - 创建该对象所使用的 Kubernetes API 的版本
+* `kind` - 想要创建的对象的类型
+* `metadata` - 帮助识别对象唯一性的数据，包括一个 `name` 字符串、UID 和可选的 `namespace`
+
+
+
+也需要提供对象的 `spec` 字段。对象 `spec` 的精确格式对每个 Kubernetes 对象来说是不同的，包含了特定于该对象的嵌套字段。[Kubernetes API 参考](/docs/api/)能够帮助我们找到任何我们想创建的对象的 spec 格式。
+
+{% endcapture %}
+
+{% capture whatsnext %}
+
+* 了解最重要的基本 Kubernetes 对象，例如 [Pod](/docs/concepts/abstractions/pod/)。
+{% endcapture %}
+
+{% include templates/concept.md %}

cn/docs/concepts/overview/working-with-objects/nginx-deployment.yaml

@@ -0,0 +1,16 @@
+apiVersion: apps/v1beta1
+kind: Deployment
+metadata:
+  name: nginx-deployment
+spec:
+  replicas: 3
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.7.9
+        ports:
+        - containerPort: 80

cn/docs/concepts/policy/pod-security-policy.md

@@ -0,0 +1,221 @@
+---
+assignees:
+- pweil-
+title: Pod 安全策略
+redirect_from:
+- "/docs/user-guide/pod-security-policy/"
+- "/docs/user-guide/pod-security-policy/index.html"
+---
+
+
+
+`PodSecurityPolicy` 类型的对象能够控制，是否可以向 Pod 发送请求，该 Pod 能够影响被应用到 Pod 和容器的 `SecurityContext`。
+查看 [Pod 安全策略建议](https://git.k8s.io/community/contributors/design-proposals/security-context-constraints.md) 获取更多信息。
+
+* TOC
+{:toc}
+
+
+
+## 什么是 Pod 安全策略？
+
+_Pod 安全策略_ 是集群级别的资源，它能够控制 Pod 运行的行为，以及它具有访问什么的能力。
+`PodSecurityPolicy` 对象定义了一组条件，指示 Pod 必须按系统所能接受的顺序运行。
+它们允许管理员控制如下方面：
+
+
+
+| 控制面                                                        | 字段名称                          |
+| ------------------------------------------------------------- | --------------------------------- |
+| 已授权容器的运行                                              | `privileged`                      |
+| 为容器添加默认的一组能力                                      | `defaultAddCapabilities`          |
+| 为容器去掉某些能力                                            | `requiredDropCapabilities`        |
+| 容器能够请求添加某些能力                                      | `allowedCapabilities`             |
+| 控制卷类型的使用                                              | [`volumes`](#controlling-volumes) |
+| 主机网络的使用                                                | [`hostNetwork`](#host-network)    |
+| 主机端口的使用                                                | `hostPorts`                       |
+| 主机 PID namespace 的使用                                     | `hostPID`                         |
+| 主机 IPC namespace 的使用                                     | `hostIPC`                         |
+| 主机路径的使用                                                | [`allowedHostPaths`](#allowed-host-paths)    |
+| 容器的 SELinux 上下文                                         | [`seLinux`](#selinux)             |
+| 用户 ID                                                       | [`runAsUser`](#runasuser)         |
+| 配置允许的补充组                                              | [`supplementalGroups`](#supplementalgroups) |
+| 分配拥有 Pod 数据卷的 FSGroup                                 | [`fsGroup`](#fsgroup)             |
+| 必须使用一个只读的 root 文件系统                              | `readOnlyRootFilesystem`          |
+
+
+
+_Pod 安全策略_ 由设置和策略组成，它们能够控制 Pod 访问的安全特征。这些设置分为如下三类：
+
+- *基于布尔值控制*：这种类型的字段默认为最严格限制的值。
+- *基于被允许的值集合控制*：这种类型的字段会与这组值进行对比，以确认值被允许。
+- *基于策略控制*：设置项通过一种策略提供的机制来生成该值，这种机制能够确保指定的值落在被允许的这组值中。
+
+
+
+### RunAsUser
+
+
+
+- *MustRunAs* - 必须配置一个 `range`。使用该范围内的第一个值作为默认值。验证是否不在配置的该范围内。
+- *MustRunAsNonRoot* - 要求提交的 Pod 具有非零 `runAsUser` 值，或在镜像中定义了 `USER` 环境变量。不提供默认值。
+- *RunAsAny* - 没有提供默认值。允许指定任何 `runAsUser` 。
+
+
+
+### SELinux
+
+- *MustRunAs* - 如果没有使用预分配的值，必须配置 `seLinuxOptions`。默认使用 `seLinuxOptions`。验证 `seLinuxOptions`。
+- *RunAsAny* - 没有提供默认值。允许任意指定的 `seLinuxOptions` ID。
+
+
+
+### SupplementalGroups
+
+- *MustRunAs* - 至少需要指定一个范围。默认使用第一个范围的最小值。验证所有范围的值。
+- *RunAsAny* - 没有提供默认值。允许任意指定的 `supplementalGroups` ID。
+
+
+
+### FSGroup
+
+- *MustRunAs* - 至少需要指定一个范围。默认使用第一个范围的最小值。验证在第一个范围内的第一个 ID。
+- *RunAsAny* - 没有提供默认值。允许任意指定的 `fsGroup` ID。
+
+
+
+### 控制卷
+
+通过设置 PSP 卷字段，能够控制具体卷类型的使用。当创建一个卷的时候，与该字段相关的已定义卷可以允许设置如下值：
+
+1. azureFile
+1. azureDisk
+1. flocker
+1. flexVolume
+1. hostPath
+1. emptyDir
+1. gcePersistentDisk
+1. awsElasticBlockStore
+1. gitRepo
+1. secret
+1. nfs
+1. iscsi
+1. glusterfs
+1. persistentVolumeClaim
+1. rbd
+1. cinder
+1. cephFS
+1. downwardAPI
+1. fc
+1. configMap
+1. vsphereVolume
+1. quobyte
+1. photonPersistentDisk
+1. projected
+1. portworxVolume
+1. scaleIO
+1. storageos
+1. \* (allow all volumes)
+
+
+
+对新的 PSP，推荐允许的卷的最小集合包括：configMap、downwardAPI、emptyDir、persistentVolumeClaim、secret 和 projected。
+
+
+
+### 主机网络
+ - *HostPorts*， 默认为 `empty`。`HostPortRange` 列表通过 `min`(包含) and `max`(包含) 来定义，指定了被允许的主机端口。
+
+### 允许的主机路径
+ - *AllowedHostPaths* 是一个被允许的主机路径前缀的白名单。空值表示所有的主机路径都可以使用。
+
+
+
+## 许可
+
+包含 `PodSecurityPolicy` 的 _许可控制_，允许控制集群资源的创建和修改，基于这些资源在集群范围内被许可的能力。
+
+许可使用如下的方式为 Pod 创建最终的安全上下文：
+1. 检索所有可用的 PSP。
+1. 生成在请求中没有指定的安全上下文设置的字段值。
+1. 基于可用的策略，验证最终的设置。
+
+如果某个策略能够匹配上，该 Pod 就被接受。如果请求与 PSP 不匹配，则 Pod 被拒绝。
+
+Pod 必须基于 PSP 验证每个字段。
+
+
+
+## 创建 Pod 安全策略
+
+下面是一个 Pod 安全策略的例子，所有字段的设置都被允许：
+
+{% include code.html language="yaml" file="psp.yaml" ghlink="/docs/concepts/policy/psp.yaml" %}
+
+
+
+下载示例文件可以创建该策略，然后执行如下命令：
+
+```shell
+$ kubectl create -f ./psp.yaml
+podsecuritypolicy "permissive" created
+```
+
+
+
+## 获取 Pod 安全策略列表
+
+获取已存在策略列表，使用 `kubectl get`：
+
+```shell
+$ kubectl get psp
+NAME        PRIV   CAPS  SELINUX   RUNASUSER         FSGROUP   SUPGROUP  READONLYROOTFS  VOLUMES
+permissive  false  []    RunAsAny  RunAsAny          RunAsAny  RunAsAny  false           [*]
+privileged  true   []    RunAsAny  RunAsAny          RunAsAny  RunAsAny  false           [*]
+restricted  false  []    RunAsAny  MustRunAsNonRoot  RunAsAny  RunAsAny  false           [emptyDir secret downwardAPI configMap persistentVolumeClaim projected]
+```
+
+
+
+## 修改 Pod 安全策略
+
+通过交互方式修改策略，使用 `kubectl edit`：
+
+```shell
+$ kubectl edit psp permissive
+```
+
+
+
+该命令将打开一个默认文本编辑器，在这里能够修改策略。
+
+
+
+## 删除 Pod 安全策略
+
+一旦不再需要一个策略，很容易通过 `kubectl` 删除它：
+
+```shell
+$ kubectl delete psp permissive
+podsecuritypolicy "permissive" deleted
+```
+
+
+
+## 启用 Pod 安全策略
+
+为了能够在集群中使用 Pod 安全策略，必须确保满足如下条件：
+
+
+
+1. 已经启用 API 类型 `extensions/v1beta1/podsecuritypolicy`（仅对 1.6 之前的版本）
+1. 已经启用许可控制器 `PodSecurityPolicy`
+1. 已经定义了自己的策略
+
+
+
+## 使用 RBAC
+
+在 Kubernetes 1.5 或更新版本，可以使用 PodSecurityPolicy 来控制，对基于用户角色和组的已授权容器的访问。访问不同的 PodSecurityPolicy 对象，可以基于认证来控制。基于 Deployment、ReplicaSet 等创建的 Pod，限制访问 PodSecurityPolicy 对象，[Controller Manager](/docs/admin/kube-controller-manager/) 必须基于安全 API 端口运行，并且不能够具有超级用户权限。
+
+PodSecurityPolicy 认证使用所有可用的策略，包括创建 Pod 的用户，Pod 上指定的服务账户（Service Acount）。当 Pod 基于 Deployment、ReplicaSet 创建时，它是创建 Pod 的 Controller Manager，所以如果基于非安全 API 端口运行，允许所有的 PodSecurityPolicy 对象，并且不能够有效地实现细分权限。用户访问给定的 PSP 策略有效，仅当是直接部署 Pod 的情况。更多详情，查看 [PodSecurityPolicy RBAC 示例](https://git.k8s.io/kubernetes/examples/podsecuritypolicy/rbac/README.md)，当直接部署 Pod 时，应用 PodSecurityPolicy 控制基于角色和组的已授权容器的访问 。

cn/docs/concepts/policy/resource-quotas.md

@@ -0,0 +1,220 @@
+---
+approvers:
+- derekwaynecarr
+title: 资源配额
+---
+
+当多个用户或团队共享具有固定数目节点的集群时，人们会担心有人使用的资源超出应有的份额。
+
+资源配额是帮助管理员解决这一问题的工具。
+
+资源配额， 通过 `ResourceQuota` 对象来定义， 对每个namespace的资源消耗总量提供限制。 它可以按类型限制namespace下可以创建的对象的数量，也可以限制可被该项目以资源形式消耗的计算资源的总量。
+
+资源配额的工作方式如下：
+
+- 不同的团队在不同的namespace下工作。 目前这是自愿的， 但计划通过ACL (Access Control List 访问控制列表) 
+  使其变为强制性的。
+- 管理员为每个namespace创建一个或多个资源配额对象。
+- 用户在namespace下创建资源 (pods、 services等)，同时配额系统会跟踪使用情况，来确保其不超过
+  资源配额中定义的硬性资源限额。
+- 如果资源的创建或更新违反了配额约束，则请求会失败，并返回 HTTP状态码 `403 FORBIDDEN` ，以及说明违反配额
+  约束的信息。
+- 如果namespace下的计算资源 （如 `cpu` 和 `memory`）的配额被启用，则用户必须为这些资源设定请求值（request）
+  和约束值（limit），否则配额系统将拒绝Pod的创建。  
+  提示: 可使用 LimitRange 准入控制器来为没有设置计算资源需求的Pod设置默认值。
+  作为示例，请参考 [演练](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) 来避免这个问题。
+
+下面是使用namespace和配额构建策略的示例：
+
+- 在具有 32 GiB 内存 和 16 核CPU资源的集群中， 允许A团队使用 20 GiB 内存 和 10 核的CPU资源，
+  允许B团队使用 10GiB 内存和 4 核的CPU资源， 并且预留 2GiB 内存和 2 核的CPU资源供将来分配。
+- 限制 "testing" namespace使用 1 核CPU资源和 1GiB 内存。  允许 "production" namespace使用任意数量。
+
+在集群容量小于各namespace配额总和的情况下，可能存在资源竞争。 Kubernetes采用先到先服务的方式处理这类问题。
+
+无论是资源竞争还是配额的变更都不会影响已经创建的资源。
+
+## 启用资源配额
+
+资源配额的支持在很多Kubernetes版本中是默认开启的。 当 apiserver 的 
+`--admission-control=` 参数中包含 `ResourceQuota` 时，资源配额会被启用。
+
+当namespace中存在一个 `ResourceQuota` 对象时，该namespace即开始实施资源配额管理。 
+一个namespace中最多只应存在一个 `ResourceQuota` 对象
+
+## 计算资源配额
+
+用户可以对给定namespace下的 [计算资源](/docs/user-guide/compute-resources) 总量进行限制。
+
+配额机制所支持的资源类型：
+
+| 资源名称 | 描述 |
+| --------------------- | ----------------------------------------------------------- |
+| `cpu` | 所有非终止状态的Pod中，其CPU需求总量不能超过该值。 |
+| `limits.cpu` | 所有非终止状态的Pod中，其CPU限额总量不能超过该值。 |
+| `limits.memory` | 所有非终止状态的Pod中，其内存限额总量不能超过该值。 |
+| `memory` | 所有非终止状态的Pod中，其内存需求总量不能超过该值。 |
+| `requests.cpu` | 所有非终止状态的Pod中，其CPU需求总量不能超过该值。 |
+| `requests.memory` | 所有非终止状态的Pod中，其内存需求总量不能超过该值。 |
+
+## 存储资源配额
+
+用户可以对给定namespace下的 [存储资源](/docs/user-guide/persistent-volumes) 总量进行限制。
+
+此外，还可以根据相关的存储类（Storage Class）来限制存储资源的消耗。
+
+| 资源名称 | 描述 |
+| --------------------- | ----------------------------------------------------------- |
+| `requests.storage` | 所有的PVC中，存储资源的需求不能超过该值。 |
+| `persistentvolumeclaims` | namespace中所允许的 [PVC](/docs/user-guide/persistent-volumes/#persistentvolumeclaims) 总量。 |
+| `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | 所有该storage-class-name相关的PVC中， 存储资源的需求不能超过该值。 |
+| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` |  namespace中所允许的该storage-class-name相关的[PVC](/docs/user-guide/persistent-volumes/#persistentvolumeclaims)的总量。 |
+
+例如，如果一个操作人员针对 "黄金" 存储类型与 "铜" 存储类型设置配额，操作员可以
+定义配额如下：
+
+* `gold.storageclass.storage.k8s.io/requests.storage: 500Gi`
+* `bronze.storageclass.storage.k8s.io/requests.storage: 100Gi`
+
+## 对象数量配额
+
+给定类型的对象数量可以被限制。 支持以下类型：
+
+| 资源名称 | 描述 |
+| ------------------------------- | ------------------------------------------------- |
+| `configmaps` | namespace下允许存在的configmap的数量。 |
+| `persistentvolumeclaims` | namespace下允许存在的[PVC](/docs/user-guide/persistent-volumes/#persistentvolumeclaims)的数量。 |
+| `pods` | namespace下允许存在的非终止状态的pod数量。 如果pod 的 `status.phase 为 Failed 或 Succeeded` ， 那么其处于终止状态。  |
+| `replicationcontrollers` | namespace下允许存在的replication controllers的数量。 |
+| `resourcequotas` | namespace下允许存在的 [resource quotas](/docs/admin/admission-controllers/#resourcequota) 的数量。 |
+| `services` | namespace下允许存在的service的数量。 |
+| `services.loadbalancers` | namespace下允许存在的load balancer类型的service的数量。 |
+| `services.nodeports` | namespace下允许存在的node port类型的service的数量。 |
+| `secrets` | namespace下允许存在的secret的数量。 |
+
+例如 `pods` 配额统计并保证单个namespace下创建 `pods` 的最大数量。
+
+用户可能希望在namespace中为pod设置配额，来避免有用户创建很多小的pod，从而耗尽集群提供的pod IP地址。
+
+## 配额作用域
+
+每个配额都有一组相关的作用域（scope），配额只会对作用域内的资源生效。
+
+当一个作用域被添加到配额中后，它会对作用域相关的资源数量作限制。
+如配额中指定了允许（作用域）集合之外的资源，会导致验证错误。
+
+| 范围 | 描述 |
+| ----- | ----------- |
+| `Terminating` | 匹配 `spec.activeDeadlineSeconds >= 0` 的pod。 |
+| `NotTerminating` | 匹配 `spec.activeDeadlineSeconds is nil` 的pod。 |
+| `BestEffort` | 匹配"尽力而为（best effort)"服务类型的pod。 |
+| `NotBestEffort` | 匹配非"尽力而为（best effort)"服务类型的pod。 |
+
+`BestEffort` 作用域限制配额跟踪以下资源： `pods`
+
+`Terminating`、 `NotTerminating` 和 `NotBestEffort` 限制配额跟踪以下资源：
+
+* `cpu`
+* `limits.cpu`
+* `limits.memory`
+* `memory`
+* `pods`
+* `requests.cpu`
+* `requests.memory`
+
+## 请求／约束
+
+分配计算资源时，每个容器可以为CPU或内存指定请求和约束。
+也可以设置两者中的任何一个。
+
+如果配额中指定了 `requests.cpu` 或 `requests.memory` 的值，那么它要求每个进来的容器针对这些资源有明确的请求。  如果配额中指定了 `limits.cpu` 或 `limits.memory`的值，那么它要求每个进来的容器针对这些资源指定明确的约束。
+
+## 查看和设置配额
+
+Kubectl 支持创建、更新和查看配额：
+
+```shell
+$ kubectl create namespace myspace
+
+$ cat <<EOF > compute-resources.yaml
+apiVersion: v1
+kind: ResourceQuota
+metadata:
+  name: compute-resources
+spec:
+  hard:
+    pods: "4"
+    requests.cpu: "1"
+    requests.memory: 1Gi
+    limits.cpu: "2"
+    limits.memory: 2Gi
+EOF
+$ kubectl create -f ./compute-resources.yaml --namespace=myspace
+
+$ cat <<EOF > object-counts.yaml
+apiVersion: v1
+kind: ResourceQuota
+metadata:
+  name: object-counts
+spec:
+  hard:
+    configmaps: "10"
+    persistentvolumeclaims: "4"
+    replicationcontrollers: "20"
+    secrets: "10"
+    services: "10"
+    services.loadbalancers: "2"
+EOF
+$ kubectl create -f ./object-counts.yaml --namespace=myspace
+
+$ kubectl get quota --namespace=myspace
+NAME                    AGE
+compute-resources       30s
+object-counts           32s
+
+$ kubectl describe quota compute-resources --namespace=myspace
+Name:                  compute-resources
+Namespace:             myspace
+Resource               Used Hard
+--------               ---- ----
+limits.cpu             0    2
+limits.memory          0    2Gi
+pods                   0    4
+requests.cpu           0    1
+requests.memory        0    1Gi
+
+$ kubectl describe quota object-counts --namespace=myspace
+Name:                   object-counts
+Namespace:              myspace
+Resource                Used    Hard
+--------                ----    ----
+configmaps              0       10
+persistentvolumeclaims  0       4
+replicationcontrollers  0       20
+secrets                 1       10
+services                0       10
+services.loadbalancers  0       2
+```
+
+## 配额和集群容量
+
+配额对象是独立于集群容量的。它们通过绝对的单位来表示。 所以，为集群添加节点， *不会*
+自动赋予每个namespace消耗更多资源的能力。
+
+有时可能需要更复杂的策略，比如：
+
+  - 在几个团队中按比例划分总的集群资源。
+  - 允许每个租户根据需要增加资源使用量，但要有足够的限制以防止意外资源耗尽。
+  - 在namespace中添加节点、提高配额的额外需求。
+
+这些策略可以基于 ResourceQuota，通过编写一个检测配额使用，并根据其他信号调整各namespace下的配额硬性限制的 "控制器" 来实现。
+
+注意：资源配额对集群资源总体进行划分，但它对节点没有限制：来自多个namespace的Pod可能在同一节点上运行。
+
+## 示例
+
+查看 [如何使用资源配额的详细示例](/docs/tasks/administer-cluster/quota-api-object/)。
+
+## 更多信息
+
+查看 [资源配额设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) 了解更多信息。

cn/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md

@@ -0,0 +1,76 @@
+---
+assignees:
+- rickypai
+- thockin
+title: 使用 HostAliases 向 Pod /etc/hosts 文件添加条目
+redirect_from:
+- "/docs/user-guide/add-entries-to-pod-etc-hosts-with-host-aliases/"
+- "/docs/user-guide/add-entries-to-pod-etc-hosts-with-host-aliases.md"
+---
+
+* TOC
+{:toc}
+
+
+
+当 DNS 配置以及其它选项不合理的时候，通过向 Pod 的 /etc/hosts 文件中添加条目，可以在 Pod 级别覆盖对主机名的解析。在 1.7 版本，用户可以通过 PodSpec 的 HostAliases 字段来添加这些自定义的条目。
+
+建议通过使用 HostAliases 来进行修改，因为该文件由 Kubelet 管理，并且可以在 Pod 创建/重启过程中被重写。 
+
+
+
+## 默认 hosts 文件内容
+
+让我们从一个 Nginx Pod 开始，给该 Pod 分配一个 IP：
+
+```
+$ kubectl get pods --output=wide
+NAME     READY     STATUS    RESTARTS   AGE    IP           NODE
+nginx    1/1       Running   0          13s    10.200.0.4   worker0
+```
+
+
+
+默认，hosts 文件只包含 ipv4 和 ipv6 的样板内容，像 `localhost` 和主机名称。
+
+## 通过 HostAliases 增加额外的条目
+
+
+
+除了默认的样板内容，我们可以向 hosts 文件添加额外的条目，将 `foo.local`、 `bar.local` 解析为`127.0.0.1`，将 `foo.remote`、 `bar.remote` 解析为 `10.1.2.3`，我们可以在 `.spec.hostAliases` 下为 Pod 添加 HostAliases。
+
+{% include code.html language="yaml" file="hostaliases-pod.yaml" ghlink="/docs/concepts/services-networking/hostaliases-pod.yaml" %}
+
+hosts 文件的内容看起来类似如下这样：
+
+```
+$ kubectl logs hostaliases-pod
+# Kubernetes-managed hosts file.
+127.0.0.1	localhost
+::1	localhost ip6-localhost ip6-loopback
+fe00::0	ip6-localnet
+fe00::0	ip6-mcastprefix
+fe00::1	ip6-allnodes
+fe00::2	ip6-allrouters
+10.200.0.4	hostaliases-pod
+127.0.0.1	foo.local
+127.0.0.1	bar.local
+10.1.2.3	foo.remote
+10.1.2.3	bar.remote
+```
+
+
+
+在最下面额外添加了一些条目。
+
+## 限制
+
+在 1.7 版本，如果 Pod 启用 hostNetwork，那么将不能使用这个特性，因为 kubelet 只管理非 hostNetwork 类型 Pod 的 hosts 文件。目前正在讨论要改变这个情况。
+
+
+
+## 为什么 Kubelet 管理 hosts文件？
+
+kubelet [管理](https://github.com/kubernetes/kubernetes/issues/14633) Pod 中每个容器的 hosts 文件，避免 Docker 在容器已经启动之后去 [修改](https://github.com/moby/moby/issues/17190) 该文件。
+
+因为该文件是托管性质的文件，无论容器重启或 Pod 重新调度，用户修改该 hosts 文件的任何内容，都会在 Kubelet 重新安装后被覆盖。因此，不建议修改该文件的内容。

cn/docs/concepts/services-networking/connect-applications-service.md

@@ -0,0 +1,381 @@
+---
+approvers:
+- caesarxuchao
+- lavalamp
+- thockin
+title: 应用连接到 Service
+---
+
+* TOC
+{:toc}
+
+
+
+## Kubernetes 连接容器模型
+
+既然有了一个持续运行、可复制的应用，我们就能够将它暴露到网络上。
+在讨论 Kubernetes 网络连接的方式之前，非常值得与 Docker 中 “正常” 方式的网络进行对比。 
+
+
+
+默认情况下，Docker 使用私有主机网络连接，只能与同在一台机器上的容器进行通信。
+为了实现容器的跨节点通信，必须在机器自己的 IP 上为这些容器分配端口，为容器进行端口转发或者代理。
+
+多个开发人员之间协调端口的使用很难做到规模化，那些难以控制的集群级别的问题，都会交由用户自己去处理。
+Kubernetes 假设 Pod 可与其它 Pod 通信，不管它们在哪个主机上。
+我们给 Pod 分配属于自己的集群私有 IP 地址，所以没必要在 Pod 或映射到的容器的端口和主机端口之间显式地创建连接。
+这表明了在 Pod 内的容器都能够连接到本地的每个端口，集群中的所有 Pod 不需要通过 NAT 转换就能够互相看到。
+文档的剩余部分将详述如何在一个网络模型之上运行可靠的服务。
+
+该指南使用一个简单的 Nginx server 来演示并证明谈到的概念。同样的原则也体现在一个更加完整的 [Jenkins CI 应用](http://blog.kubernetes.io/2015/07/strong-simple-ssl-for-kubernetes.html) 中。
+
+
+
+## 在集群中暴露 Pod
+
+我们在之前的示例中已经做过，然而再让我重试一次，这次聚焦在网络连接的视角。
+创建一个 Nginx Pod，指示它具有一个容器端口的说明：
+
+{% include code.html language="yaml" file="run-my-nginx.yaml" ghlink="/docs/concepts/services-networking/run-my-nginx.yaml" %}
+
+
+
+这使得可以从集群中任何一个节点来访问它。检查节点，该 Pod 正在运行：
+
+```shell
+$ kubectl create -f ./run-my-nginx.yaml
+$ kubectl get pods -l run=my-nginx -o wide
+NAME                        READY     STATUS    RESTARTS   AGE       IP            NODE
+my-nginx-3800858182-jr4a2   1/1       Running   0          13s       10.244.3.4    kubernetes-minion-905m
+my-nginx-3800858182-kna2y   1/1       Running   0          13s       10.244.2.5    kubernetes-minion-ljyd
+```
+
+
+
+检查 Pod 的 IP 地址：
+
+```shell
+$ kubectl get pods -l run=my-nginx -o yaml | grep podIP
+    podIP: 10.244.3.4
+    podIP: 10.244.2.5
+```
+
+
+
+应该能够通过 ssh 登录到集群中的任何一个节点上，使用 curl 也能调通所有 IP 地址。
+需要注意的是，容器不会使用该节点上的 80 端口，也不会使用任何特定的 NAT 规则去路由流量到 Pod 上。
+这意味着可以在同一个节点上运行多个 Pod，使用相同的容器端口，并且可以从集群中任何其他的 Pod 或节点上使用 IP 的方式访问到它们。
+像 Docker 一样，端口能够被发布到主机节点的接口上，但是出于网络模型的原因应该从根本上减少这种用法。
+
+如果对此好奇，可以获取更多关于 [如何实现网络模型](/docs/concepts/cluster-administration/networking/#how-to-achieve-this)  的内容。
+
+
+
+## 创建 Service
+
+我们有 Pod 在一个扁平的、集群范围的地址空间中运行 Nginx 服务，可以直接连接到这些 Pod，但如果某个节点死掉了会发生什么呢？
+Pod 会终止，Deployment 将创建新的 Pod，且使用不同的 IP。这正是 Service 要解决的问题。
+
+Kubernetes Service 从逻辑上定义了运行在集群中的一组 Pod，这些 Pod 提供了相同的功能。
+当每个 Service 创建时，会被分配一个唯一的 IP 地址（也称为 clusterIP）。
+这个 IP 地址与一个 Service 的生命周期绑定在一起，当 Service 存在的时候它也不会改变。
+可以配置 Pod 使它与 Service 进行通信，Pod 知道与 Service 通信将被自动地负载均衡到该 Service 中的某些 Pod 上。
+
+可以使用 `kubectl expose` 命令为 2个 Nginx 副本创建一个 Service：
+
+```shell
+$ kubectl expose deployment/my-nginx
+service "my-nginx" exposed
+```
+
+
+
+这等价于使用 `kubectl create -f` 命令创建，对应如下的 yaml 文件：
+
+{% include code.html language="yaml" file="nginx-svc.yaml" ghlink="/docs/concepts/services-networking/nginx-svc.yaml" %}
+
+
+
+上述规约将创建一个 Service，对应具有标签 `run: my-nginx` 的 Pod，目标 TCP 端口 80，并且在一个抽象的 Service 端口（`targetPort`：容器接收流量的端口；`port`：抽象的 Service 端口，可以使任何其它 Pod 访问该 Service 的端口）上暴露。
+查看 [Service API 对象](/docs/api-reference/{{page.version}}/#service-v1-core) 了解 Service 定义支持的字段列表。
+
+```shell
+$ kubectl get svc my-nginx
+NAME       CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
+my-nginx   10.0.162.149   <none>        80/TCP    21s
+```
+
+
+
+正如前面所提到的，一个 Service 由一组 backend Pod 组成。这些 Pod 通过 `endpoints` 暴露出来。
+Service Selector 将持续评估，结果被 POST 到一个名称为 `my-nginx` 的 Endpoint 对象上。
+当 Pod 终止后，它会自动从 Endpoint 中移除，新的能够匹配上 Service Selector 的 Pod 将自动地被添加到 Endpoint 中。
+检查该 Endpoint，注意到 IP 地址与在第一步创建的 Pod 是相同的。
+
+```shell
+$ kubectl describe svc my-nginx
+Name:                my-nginx
+Namespace:           default
+Labels:              run=my-nginx
+Selector:            run=my-nginx
+Type:                ClusterIP
+IP:                  10.0.162.149
+Port:                <unset> 80/TCP
+Endpoints:           10.244.2.5:80,10.244.3.4:80
+Session Affinity:    None
+No events.
+
+$ kubectl get ep my-nginx
+NAME       ENDPOINTS                     AGE
+my-nginx   10.244.2.5:80,10.244.3.4:80   1m
+```
+
+
+
+现在，能够从集群中任意节点上使用 curl 命令请求 Nginx Service  `<CLUSTER-IP>:<PORT>` 。
+注意 Service IP 完全是虚拟的，它从来没有走过网络，如果对它如何工作的原理感到好奇，可以阅读更多关于 [服务代理](/docs/user-guide/services/#virtual-ips-and-service-proxies) 的内容。
+
+
+
+## 访问 Service
+
+Kubernetes 支持两种主要的服务发现模式 —— 环境变量和 DNS。前者在单个节点上可用使用，然而后者必须使用 [kube-dns 集群插件](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/README.md)。
+
+
+
+### 环境变量
+
+当 Pod 在 Node 上运行时，kubelet 会为每个活跃的 Service 添加一组环境变量。这会有一个顺序的问题。想了解为何，检查正在运行的 Nginx Pod 的环境变量（Pod 名称将不会相同）：
+
+```shell
+$ kubectl exec my-nginx-3800858182-jr4a2 -- printenv | grep SERVICE
+KUBERNETES_SERVICE_HOST=10.0.0.1
+KUBERNETES_SERVICE_PORT=443
+KUBERNETES_SERVICE_PORT_HTTPS=443
+```
+
+
+
+注意，还没有谈及到 Service。这是因为创建副本先于 Service。
+这样做的另一个缺点是，调度器可能在同一个机器上放置所有 Pod，如果该机器宕机则所有的 Service 都会挂掉。
+正确的做法是，我们杀掉 2 个 Pod，等待 Deployment 去创建它们。
+这次 Service 会 *先于* 副本存在。这将实现调度器级别的 Service，能够使 Pod 分散创建（假定所有的 Node 都具有同样的容量），以及正确的环境变量：
+
+```shell
+$ kubectl scale deployment my-nginx --replicas=0; kubectl scale deployment my-nginx --replicas=2;
+
+$ kubectl get pods -l run=my-nginx -o wide
+NAME                        READY     STATUS    RESTARTS   AGE     IP            NODE
+my-nginx-3800858182-e9ihh   1/1       Running   0          5s      10.244.2.7    kubernetes-minion-ljyd
+my-nginx-3800858182-j4rm4   1/1       Running   0          5s      10.244.3.8    kubernetes-minion-905m
+```
+
+
+
+可能注意到，Pod 具有不同的名称，因为它们被杀掉后并被重新创建。
+
+```shell
+$ kubectl exec my-nginx-3800858182-e9ihh -- printenv | grep SERVICE
+KUBERNETES_SERVICE_PORT=443
+MY_NGINX_SERVICE_HOST=10.0.162.149
+KUBERNETES_SERVICE_HOST=10.0.0.1
+MY_NGINX_SERVICE_PORT=80
+KUBERNETES_SERVICE_PORT_HTTPS=443
+```
+
+### DNS
+
+
+
+Kubernetes 提供了一个 DNS 插件 Service，它使用 skydns 自动为其它 Service 指派 DNS 名字。
+如果它在集群中处于运行状态，可以通过如下命令来检查：
+
+```shell
+$ kubectl get services kube-dns --namespace=kube-system
+NAME       CLUSTER-IP   EXTERNAL-IP   PORT(S)         AGE
+kube-dns   10.0.0.10    <none>        53/UDP,53/TCP   8m
+```
+
+
+
+如果没有在运行，可以 [启用它](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/README.md#how-do-i-configure-it)。
+本段剩余的内容，将假设已经有一个 Service，它具有一个长久存在的 IP（my-nginx），一个为该 IP 指派名称的 DNS 服务器（kube-dns 集群插件），所以可以通过标准做法，使在集群中的任何 Pod 都能与该 Service 通信（例如：gethostbyname）。
+让我们运行另一个 curl 应用来进行测试：
+
+```shell
+$ kubectl run curl --image=radial/busyboxplus:curl -i --tty
+Waiting for pod default/curl-131556218-9fnch to be running, status is Pending, pod ready: false
+Hit enter for command prompt
+```
+
+
+然后，按回车并执行命令 `nslookup my-nginx`：
+
+```shell
+[ root@curl-131556218-9fnch:/ ]$ nslookup my-nginx
+Server:    10.0.0.10
+Address 1: 10.0.0.10
+
+Name:      my-nginx
+Address 1: 10.0.162.149
+```
+
+
+
+## Service 安全
+
+到现在为止，我们只在集群内部访问了 Nginx server。在将 Service 暴露到 Internet 之前，我们希望确保通信信道是安全的。对于这可能需要：
+
+
+
+* https 自签名证书（除非已经有了一个识别身份的证书）
+* 使用证书配置的 Nginx server
+* 使证书可以访问 Pod 的[秘钥](/docs/user-guide/secrets)
+
+可以从 [Nginx https 示例](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/https-nginx/) 获取所有上述内容，简明示例如下：
+
+```shell
+$ make keys secret KEY=/tmp/nginx.key CERT=/tmp/nginx.crt SECRET=/tmp/secret.json
+$ kubectl create -f /tmp/secret.json
+secret "nginxsecret" created
+$ kubectl get secrets
+NAME                  TYPE                                  DATA      AGE
+default-token-il9rc   kubernetes.io/service-account-token   1         1d
+nginxsecret           Opaque                                2         1m
+```
+
+
+
+现在修改 Nginx 副本，启动一个使用在秘钥中的证书的 https 服务器和 Servcie，都暴露端口（80 和 443）：
+
+{% include code.html language="yaml" file="nginx-secure-app.yaml" ghlink="/docs/concepts/services-networking/nginx-secure-app.yaml" %}
+
+
+
+关于 nginx-secure-app manifest 值得注意的点如下：
+
+
+
+- 它在相同的文件中包含了 Deployment 和 Service 的规格
+- [Nginx server](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/https-nginx/default.conf) 处理 80 端口上的 http 流量，以及 443  端口上的 https 流量，Nginx Service 暴露了这两个端口。
+- 每个容器访问挂载在 /etc/nginx/ssl 卷上的秘钥。这需要在 Nginx server 启动之前安装好。
+
+```shell
+$ kubectl delete deployments,svc my-nginx; kubectl create -f ./nginx-secure-app.yaml
+```
+
+
+
+这时可以从任何节点访问到 Nginx server。
+
+```shell
+$ kubectl get pods -o yaml | grep -i podip
+    podIP: 10.244.3.5
+node $ curl -k https://10.244.3.5
+...
+<h1>Welcome to nginx!</h1>
+```
+
+
+
+注意最后一步我们是如何提供 `-k` 参数执行 curl命令的，这是因为在证书生成时，我们不知道任何关于运行 Nginx 的 Pod 的信息，所以不得不在执行 curl 命令时忽略 CName 不匹配的情况。
+通过创建 Service，我们连接了在证书中的 CName 与在 Service 查询时被 Pod使用的实际 DNS 名字。
+让我们从一个 Pod 来测试（为了简化使用同一个秘钥，Pod 仅需要使用 nginx.crt 去访问 Service）：
+
+{% include code.html language="yaml" file="curlpod.yaml" ghlink="/docs/concepts/services-networking/curlpod.yaml" %}
+
+```shell
+$ kubectl create -f ./curlpod.yaml
+$ kubectl get pods -l app=curlpod
+NAME                               READY     STATUS    RESTARTS   AGE
+curl-deployment-1515033274-1410r   1/1       Running   0          1m
+$ kubectl exec curl-deployment-1515033274-1410r -- curl https://my-nginx --cacert /etc/nginx/ssl/nginx.crt
+...
+<title>Welcome to nginx!</title>
+...
+```
+
+
+## 暴露 Service
+
+对我们应用的某些部分，可能希望将 Service 暴露在一个外部 IP 地址上。
+Kubernetes 支持两种实现方式：NodePort 和 LoadBalancer。
+在上一段创建的 Service 使用了 `NodePort`，因此 Nginx https 副本已经就绪，如果使用一个公网 IP，能够处理 Internet 上的流量。
+
+```shell
+$ kubectl get svc my-nginx -o yaml | grep nodePort -C 5
+  uid: 07191fb3-f61a-11e5-8ae5-42010af00002
+spec:
+  clusterIP: 10.0.162.149
+  ports:
+  - name: http
+    nodePort: 31704
+    port: 8080
+    protocol: TCP
+    targetPort: 80
+  - name: https
+    nodePort: 32453
+    port: 443
+    protocol: TCP
+    targetPort: 443
+  selector:
+    run: my-nginx
+
+$ kubectl get nodes -o yaml | grep ExternalIP -C 1
+    - address: 104.197.41.11
+      type: ExternalIP
+    allocatable:
+--
+    - address: 23.251.152.56
+      type: ExternalIP
+    allocatable:
+...
+
+$ curl https://<EXTERNAL-IP>:<NODE-PORT> -k
+...
+<h1>Welcome to nginx!</h1>
+```
+
+
+
+让我们重新创建一个 Service，使用一个云负载均衡器，只需要将 `my-nginx` Service 的 `Type` 由 `NodePort` 改成 `LoadBalancer`。
+
+```shell
+$ kubectl edit svc my-nginx
+$ kubectl get svc my-nginx
+NAME       CLUSTER-IP     EXTERNAL-IP        PORT(S)               AGE
+my-nginx   10.0.162.149   162.222.184.144    80/TCP,81/TCP,82/TCP  21s
+
+$ curl https://<EXTERNAL-IP> -k
+...
+<title>Welcome to nginx!</title>
+```
+
+
+
+在 `EXTERNAL-IP` 列指定的 IP 地址是在公网上可用的。`CLUSTER-IP` 只在集群/私有云网络中可用。
+
+注意，在 AWS 上类型 `LoadBalancer` 创建一个 ELB，它使用主机名（比较长），而不是 IP。
+它太长以至于不能适配标准 `kubectl get svc` 的输出，事实上需要通过执行 `kubectl describe service my-nginx` 命令来查看它。
+可以看到类似如下内容：
+
+```shell
+$ kubectl describe service my-nginx
+...
+LoadBalancer Ingress:   a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.elb.amazonaws.com
+...
+```
+
+
+
+## 进一步阅读
+
+Kubernetes 也支持联合 Service，能够跨多个集群和云提供商，为 Service 提供逐步增强的可用性、更优的容错、更好的可伸缩性。
+查看 [联合 Service 用户指南](/docs/concepts/cluster-administration/federation-service-discovery/) 获取更进一步信息。
+
+
+
+## 下一步
+
+[了解更多关于 Kubernetes 的特性，有助于在生产环境中可靠地运行容器](/docs/user-guide/production-pods)
+

cn/docs/concepts/services-networking/curlpod.yaml

@@ -0,0 +1,25 @@
+apiVersion: apps/v1beta1
+kind: Deployment
+metadata:
+  name: curl-deployment
+spec:
+  replicas: 1
+  template:
+    metadata:
+      labels:
+        app: curlpod
+    spec:
+      volumes:
+      - name: secret-volume
+        secret:
+          secretName: nginxsecret
+      containers:
+      - name: curlpod
+        command:
+        - sh
+        - -c
+        - while true; do sleep 1; done
+        image: radial/busyboxplus:curl
+        volumeMounts:
+        - mountPath: /etc/nginx/ssl
+          name: secret-volume

cn/docs/concepts/services-networking/dns-pod-service.md

@@ -0,0 +1,419 @@
+---
+assignees:
+- davidopp
+- thockin
+title: DNS Pod 与 Service
+redirect_from:
+- "/docs/admin/dns/"
+- "/docs/admin/dns.html"
+---
+
+
+
+## 介绍
+
+Kubernetes 从 1.3 版本起， DNS 是内置的服务，通过插件管理器 [集群插件](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/README.md) 自动被启动。
+
+Kubernetes DNS 在集群中调度 DNS Pod 和 Service ，配置 kubelet 以通知个别容器使用 DNS Service 的 IP 解析 DNS 名字。
+
+
+
+
+## 怎样获取 DNS 名字?
+
+在集群中定义的每个 Service（包括 DNS 服务器自身）都会被指派一个 DNS 名称。
+默认，一个客户端 Pod 的 DNS 搜索列表将包含该 Pod 自己的 Namespace 和集群默认域。
+通过如下示例可以很好地说明：
+
+假设在 Kubernetes 集群的 Namespace `bar` 中，定义了一个Service `foo`。
+运行在Namespace `bar` 中的一个 Pod，可以简单地通过 DNS 查询 `foo` 来找到该 Service。
+运行在 Namespace `quux` 中的一个 Pod 可以通过 DNS 查询 `foo.bar` 找到该 Service。
+
+
+
+## 支持的 DNS 模式
+
+下面各段详细说明支持的记录类型和布局。
+如果任何其它的布局、名称或查询，碰巧也能够使用，这就需要研究下它们的实现细节，以免后续修改它们又不能使用了。
+
+
+
+### Service
+
+#### A 记录
+
+“正常” Service（除了 Headless Service）会以 `my-svc.my-namespace.svc.cluster.local` 这种名字的形式被指派一个 DNS A 记录。这会解析成该 Service 的 Cluster IP。
+
+“Headless” Service（没有Cluster IP）也会以 `my-svc.my-namespace.svc.cluster.local` 这种名字的形式被指派一个 DNS A 记录。
+不像正常 Service，它会解析成该 Service 选择的一组 Pod 的 IP。
+希望客户端能够使用这一组 IP，否则就使用标准的 round-robin 策略从这一组 IP 中进行选择。
+
+
+
+#### SRV 记录
+
+命名端口需要创建 SRV 记录，这些端口是正常 Service或 [Headless
+Services](/docs/concepts/services-networking/service/#headless-services) 的一部分。
+对每个命名端口，SRV 记录具有 `_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster.local` 这种形式。
+对普通 Service，这会被解析成端口号和 CNAME：`my-svc.my-namespace.svc.cluster.local`。
+对 Headless Service，这会被解析成多个结果，Service 对应的每个 backend Pod 各一个，包含 `auto-generated-name.my-svc.my-namespace.svc.cluster.local` 这种形式 Pod 的端口号和 CNAME。
+
+#### 后向兼容性
+
+上一版本的 kube-dns 使用 `my-svc.my-namespace.cluster.local` 这种形式的名字（后续会增加 'svc' 这一级），以后这将不再被支持。
+
+
+
+### Pod
+
+#### A 记录
+
+如果启用，Pod 会以 `pod-ip-address.my-namespace.pod.cluster.local` 这种形式被指派一个 DNS A 记录。
+
+例如，`default` Namespace 具有 DNS 名字  `cluster.local`，在该 Namespace 中一个 IP 为 `1.2.3.4` 的 Pod 将具有一个条目：`1-2-3-4.default.pod.cluster.local`。
+
+
+
+#### 基于 Pod hostname、subdomain 字段的 A 记录和主机名
+
+当前，创建 Pod 后，它的主机名是该 Pod 的 `metadata.name` 值。
+
+在 v1.2 版本中，用户可以配置 Pod annotation， 通过 `pod.beta.kubernetes.io/hostname` 来设置 Pod 的主机名。
+如果为 Pod 配置了 annotation，会优先使用 Pod 的名称作为主机名。
+例如，给定一个 Pod，它具有 annotation `pod.beta.kubernetes.io/hostname: my-pod-name`，该 Pod 的主机名被设置为 “my-pod-name”。
+
+
+
+在 v1.3 版本中，PodSpec 具有 `hostname` 字段，可以用来指定 Pod 的主机名。这个字段的值优先于 annotation `pod.beta.kubernetes.io/hostname`。
+在 v1.2 版本中引入了 beta 特性，用户可以为 Pod 指定 annotation，其中 `pod.beta.kubernetes.io/subdomain` 指定了 Pod 的子域名。
+最终的域名将是 “<hostname>.<subdomain>.<pod namespace>.svc.<cluster domain>”。
+举个例子，Pod 的主机名 annotation 设置为 “foo”，子域名 annotation 设置为 “bar”，在 Namespace “my-namespace” 中对应的 FQDN 为 “foo.bar.my-namespace.svc.cluster.local”。 
+
+
+
+在 v1.3 版本中，PodSpec 具有 `subdomain` 字段，可以用来指定 Pod 的子域名。
+这个字段的值优先于 annotation `pod.beta.kubernetes.io/subdomain` 的值。
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: default-subdomain
+spec:
+  selector:
+    name: busybox
+  clusterIP: None
+  ports:
+    - name: foo # Actually, no port is needed.
+      port: 1234 
+      targetPort: 1234
+---
+apiVersion: v1
+kind: Pod
+metadata:
+  name: busybox1
+  labels:
+    name: busybox
+spec:
+  hostname: busybox-1
+  subdomain: default-subdomain
+  containers:
+  - image: busybox
+    command:
+      - sleep
+      - "3600"
+    name: busybox
+---
+apiVersion: v1
+kind: Pod
+metadata:
+  name: busybox2
+  labels:
+    name: busybox
+spec:
+  hostname: busybox-2
+  subdomain: default-subdomain
+  containers:
+  - image: busybox
+    command:
+      - sleep
+      - "3600"
+    name: busybox
+```
+
+
+
+如果 Headless Service 与 Pod 在同一个 Namespace 中，它们具有相同的子域名，集群的 KubeDNS 服务器也会为该 Pod 的完整合法主机名返回 A 记录。
+在同一个 Namespace 中，给定一个主机名为 “busybox-1” 的 Pod，子域名设置为 “default-subdomain”，名称为 “default-subdomain” 的 Headless Service ，Pod 将看到自己的 FQDN 为 “busybox-1.default-subdomain.my-namespace.svc.cluster.local”。
+DNS 会为那个名字提供一个 A 记录，指向该 Pod 的 IP。
+“busybox1” 和 “busybox2” 这两个 Pod 分别具有它们自己的 A 记录。
+
+
+
+在Kubernetes v1.2 版本中，`Endpoints` 对象也具有 annotation `endpoints.beta.kubernetes.io/hostnames-map`。
+它的值是 map[string(IP)][endpoints.HostRecord] 的 JSON 格式，例如： '{"10.245.1.6":{HostName: "my-webserver"}}'。
+
+如果是 Headless Service 的 `Endpoints`，会以  <hostname>.<service name>.<pod namespace>.svc.<cluster domain> 的格式创建 A 记录。
+对示例中的 JSON 字符串，如果 `Endpoints` 是为名称为 “bar” 的 Headless Service 而创建的，其中一个 `Endpoints`  的 IP 是 “10.245.1.6”，则会创建一个名称为 “my-webserver.bar.my-namespace.svc.cluster.local” 的 A 记录，该 A 记录查询将返回 “10.245.1.6”。
+
+`Endpoints` annotation 通常没必要由最终用户指定，但可以被内部的 Service Controller 用来提供上述功能。
+
+
+
+在 v1.3 版本中，`Endpoints` 对象可以为任何 endpoint 指定 `hostname` 和 IP。
+`hostname` 字段优先于通过 `endpoints.beta.kubernetes.io/hostnames-map` annotation 指定的主机名。
+
+在 v1.3 版本中，下面的 annotation 是过时的：`pod.beta.kubernetes.io/hostname`、`pod.beta.kubernetes.io/subdomain`、`endpoints.beta.kubernetes.io/hostnames-map`。
+
+
+
+## 如何测试它是否可以使用?
+
+### 创建一个简单的 Pod 作为测试环境
+
+创建 `busybox.yaml` 文件，内容如下：
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: busybox
+  namespace: default
+spec:
+  containers:
+  - image: busybox
+    command:
+      - sleep
+      - "3600"
+    imagePullPolicy: IfNotPresent
+    name: busybox
+  restartPolicy: Always
+```
+
+
+
+然后，用该文件创建一个 Pod：
+
+```
+kubectl create -f busybox.yaml
+```
+
+
+
+### 等待这个 Pod 变成运行状态
+
+获取它的状态，执行如下命令：
+
+```
+kubectl get pods busybox
+```
+
+
+
+可以看到如下内容：
+
+```
+NAME      READY     STATUS    RESTARTS   AGE
+busybox   1/1       Running   0          <some-time>
+```
+
+
+
+### 验证 DNS 已经生效
+
+一旦 Pod 处于运行中状态，可以在测试环境中执行如下 nslookup 查询：
+
+```
+kubectl exec -ti busybox -- nslookup kubernetes.default
+```
+
+
+
+可以看到类似如下的内容：
+
+```
+Server:    10.0.0.10
+Address 1: 10.0.0.10
+
+Name:      kubernetes.default
+Address 1: 10.0.0.1
+```
+
+
+
+如果看到了，说明 DNS 已经可以正确工作了。
+
+### 问题排查技巧
+
+如果执行 nslookup 命令失败，检查如下内容：
+
+#### 先检查本地 DNS 配置
+
+查看配置文件 resolv.conf。（关于更多信息，参考下面的 “从 Node 继承 DNS” 和 “已知问题”。）
+
+```
+kubectl exec busybox cat /etc/resolv.conf
+```
+
+
+
+按照如下方法（注意搜索路径可能会因为云提供商不同而变化）验证搜索路径和 Name Server 的建立：
+
+```
+search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internal
+nameserver 10.0.0.10
+options ndots:5
+```
+
+
+
+#### 快速诊断
+
+出现类似如下指示的错误，说明 kube-dns 插件或相关 Service 存在问题：
+
+```
+$ kubectl exec -ti busybox -- nslookup kubernetes.default
+Server:    10.0.0.10
+Address 1: 10.0.0.10
+
+nslookup: can't resolve 'kubernetes.default'
+```
+
+
+
+或者
+
+```
+$ kubectl exec -ti busybox -- nslookup kubernetes.default
+Server:    10.0.0.10
+Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
+
+nslookup: can't resolve 'kubernetes.default'
+```
+
+
+
+#### 检查是否 DNS Pod 正在运行
+
+使用 `kubectl get pods` 命令验证 DNS Pod 正在运行：
+
+```
+kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
+```
+
+
+
+应该能够看到类似如下信息：
+
+```
+NAME                                                       READY     STATUS    RESTARTS   AGE
+...
+kube-dns-v19-ezo1y                                         3/3       Running   0           1h
+...
+```
+
+
+
+如果看到没有 Pod 运行，或 Pod 失败/结束，DNS 插件不能默认部署到当前的环境，必须手动部署。
+
+#### 检查 DNS Pod 中的错误信息
+
+使用 `kubectl logs` 命令查看 DNS 后台进程的日志：
+
+```
+kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c kubedns
+kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c dnsmasq
+kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c healthz
+```
+
+
+
+查看是否有任何可疑的日志。在行开头的字母 W、E、F 分别表示 警告、错误、失败。请搜索具有这些日志级别的日志行，通过  [Kubernetes 问题](https://github.com/kubernetes/kubernetes/issues) 报告意外的错误。
+
+#### DNS 服务是否运行?
+
+通过使用 `kubectl get service` 命令，验证 DNS 服务是否运行：
+
+```
+kubectl get svc --namespace=kube-system
+```
+
+
+
+应该能够看到：
+
+```
+NAME                    CLUSTER-IP     EXTERNAL-IP   PORT(S)             AGE
+...
+kube-dns                10.0.0.10      <none>        53/UDP,53/TCP        1h
+...
+```
+
+
+
+如果服务已经创建，或在这个例子中默认被创建，但是并没有看到，可以查看 [调试 Service 页面](/docs/tasks/debug-application-cluster/debug-service/) 获取更多信息。
+
+```
+kubectl get ep kube-dns --namespace=kube-system
+```
+
+
+
+应该能够看到类似如下信息：
+
+```
+NAME       ENDPOINTS                       AGE
+kube-dns   10.180.3.17:53,10.180.3.17:53    1h
+```
+
+
+
+如果没有看到 Endpoint，查看 [调试 Service 文档](/docs/tasks/debug-application-cluster/debug-service/) 中的 Endpoint 段内容。
+
+关于更多 Kubernetes DNS 的示例，参考 Kubernetes GitHub 仓库中 [集群 DNS 示例](https://git.k8s.io/kubernetes/examples/cluster-dns)。
+
+## Kubernetes Federation（多 Zone 支持)
+
+在1.3 发行版本中，为多站点 Kubernetes 安装引入了集群 Federation 支持。这需要对 Kubernetes 集群 DNS 服务器处理 DNS 查询的方式，做出一些微小（后向兼容）改变，从而便利了对联合 Service 的查询（跨多个 Kubernetes 集群）。参考 [集群 Federation 管理员指南](/docs/concepts/cluster-administration/federation/) 获取更多关于集群 Federation 和多站点支持的细节。
+
+
+
+## 工作原理
+
+运行的 Kubernetes DNS Pod 包含 3 个容器 —— kubedns、dnsmasq 和负责健康检查的 healthz。
+kubedns 进程监视 Kubernetes master 对 Service 和 Endpoint 操作的变更，并维护一个内存查询结构去处理 DNS 请求。dnsmasq 容器增加了一个 DNS 缓存来改善性能。为执行对 dnsmasq 和 kubedns 的健康检查，healthz 容器提供了一个单独的健康检查 Endpoint。
+
+DNS Pod 通过一个静态 IP 暴露为一个 Service。一旦 IP 被分配，kubelet 会通过 `--cluster-dns=10.0.0.10` 标志将配置的 DNS 传递给每一个容器。
+
+DNS 名字也需要域名，本地域名是可配置的，在 kubelet 中使用 `--cluster-domain=<default local domain>` 标志。
+
+Kubernetes 集群 DNS 服务器（根据 [SkyDNS](https://github.com/skynetservices/skydns) 库）支持正向查询（A 记录），Service 查询（SRV 记录）和反向 IP 地址查询（PTR 记录）。
+
+
+
+## 从 Node 继承 DNS
+当运行 Pod 时，kubelet 将集群 DNS 服务器和搜索路径追加到 Node 自己的 DNS 设置中。如果 Node 能够在大型环境中解析 DNS 名字，Pod 也应该没问题。参考下面 "已知问题” 中给出的更多说明。
+
+如果不想这样，或者希望 Pod 有一个不同的 DNS 配置，可以使用 kubelet 的 `--resolv-conf` 标志。设置为 "" 表示 Pod 将不继承自 DNS。设置为一个合法的文件路径，表示 kubelet 将使用这个文件而不是 `/etc/resolv.conf` 。
+
+
+
+## 已知问题
+
+Kubernetes 安装但并不配置 Node 的 resolv.conf 文件，而是默认使用集群 DNS的，因为那个过程本质上就是和特定的发行版本相关的。最终应该会被实现。
+
+Linux libc 在限制为3个 DNS `nameserver` 记录和3个 DNS `search` 记录是不可能卡住的（[查看 2005 年的一个 Bug](https://bugzilla.redhat.com/show_bug.cgi?id=168253)）。Kubernetes 需要使用1个  `nameserver`  记录和3个 `search` 记录。这意味着如果本地安装已经使用了3个 `nameserver` 或使用了3个以上 `search`，那些设置将会丢失。作为部分解决方法， Node 可以运行 `dnsmasq` ，它能提供更多 `nameserver` 条目，但不能运行更多 `search` 条目。可以使用 kubelet 的 `--resolv-conf` 标志。
+
+如果使用 3.3 版本的 Alpine 或更早版本作为 base 镜像，由于 Alpine 的一个已知问题，DNS 可能不会正确工作。查看 [这里](https://github.com/kubernetes/kubernetes/issues/30215) 获取更多信息。
+
+
+
+## 参考
+
+- [DNS 集群插件文档](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/README.md)
+
+
+
+## 下一步
+
+- [集群中 DNS Service 自动伸缩](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)

cn/docs/concepts/services-networking/hostaliases-pod.yaml

@@ -0,0 +1,21 @@
+apiVersion: v1
+kind: Pod
+metadata:
+  name: hostaliases-pod
+spec:
+  hostAliases:
+  - ip: "127.0.0.1"
+    hostnames:
+    - "foo.local"
+    - "bar.local"
+  - ip: "10.1.2.3"
+    hostnames:
+    - "foo.remote"
+    - "bar.remote"
+  containers:
+  - name: cat-hosts
+    image: busybox
+    command:
+    - cat
+    args:
+    - "/etc/hosts"

cn/docs/concepts/services-networking/ingress.md

@@ -0,0 +1,298 @@
+---
+approvers:
+- bprashanth
+title: Ingress Resources
+---
+
+* TOC
+{:toc}
+
+__Terminology__
+
+Throughout this doc you will see a few terms that are sometimes used interchangeably elsewhere, that might cause confusion. This section attempts to clarify them.
+
+* Node: A single virtual or physical machine in a Kubernetes cluster.
+* Cluster: A group of nodes firewalled from the internet, that are the primary compute resources managed by Kubernetes.
+* Edge router: A router that enforces the firewall policy for your cluster. This could be a gateway managed by a cloud provider or a physical piece of hardware.
+* Cluster network: A set of links, logical or physical, that facilitate communication within a cluster according to the [Kubernetes networking model](/docs/concepts/cluster-administration/networking/). Examples of a Cluster network include Overlays such as [flannel](https://github.com/coreos/flannel#flannel) or SDNs such as [OVS](/docs/admin/ovs-networking/).
+* Service: A Kubernetes [Service](/docs/concepts/services-networking/service/) that identifies a set of pods using label selectors. Unless mentioned otherwise, Services are assumed to have virtual IPs only routable within the cluster network.
+
+## What is Ingress?
+
+Typically, services and pods have IPs only routable by the cluster network. All traffic that ends up at an edge router is either dropped or forwarded elsewhere. Conceptually, this might look like:
+
+```
+    internet
+        |
+  ------------
+  [ Services ]
+```
+
+An Ingress is a collection of rules that allow inbound connections to reach the cluster services.
+
+```
+    internet
+        |
+   [ Ingress ]
+   --|-----|--
+   [ Services ]
+```
+
+It can be configured to give services externally-reachable URLs, load balance traffic, terminate SSL, offer name based virtual hosting etc. Users request ingress by POSTing the Ingress resource to the API server. An [Ingress controller](#ingress-controllers) is responsible for fulfilling the Ingress, usually with a loadbalancer, though it may also configure your edge router or additional frontends to help handle the traffic in an HA manner.
+
+## Prerequisites
+
+Before you start using the Ingress resource, there are a few things you should understand. The Ingress is a beta resource, not available in any Kubernetes release prior to 1.1. You need an Ingress controller to satisfy an Ingress, simply creating the resource will have no effect.
+
+GCE/GKE deploys an ingress controller on the master. You can deploy any number of custom ingress controllers in a pod. You must annotate each ingress with the appropriate class, as indicated [here](https://git.k8s.io/ingress/controllers/nginx#running-multiple-ingress-controllers) and [here](https://git.k8s.io/ingress/controllers/gce/BETA_LIMITATIONS.md#disabling-glbc).
+
+Make sure you review the [beta limitations](https://git.k8s.io/ingress/controllers/gce/BETA_LIMITATIONS.md) of this controller. In environments other than GCE/GKE, you need to [deploy a controller](https://git.k8s.io/ingress/controllers) as a pod.
+
+## The Ingress Resource
+
+A minimal Ingress might look like:
+
+```yaml
+apiVersion: extensions/v1beta1
+kind: Ingress
+metadata:
+  name: test-ingress
+  annotations:
+    ingress.kubernetes.io/rewrite-target: /
+spec:
+  rules:
+  - http:
+      paths:
+      - path: /testpath
+        backend:
+          serviceName: test
+          servicePort: 80
+```
+
+*POSTing this to the API server will have no effect if you have not configured an [Ingress controller](#ingress-controllers).*
+
+__Lines 1-6__: As with all other Kubernetes config, an Ingress needs `apiVersion`, `kind`, and `metadata` fields.  For general information about working with config files, see [deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/), [configuring containers](/docs/tasks/configure-pod-container/configmap/), [managing resources](/docs/concepts/cluster-administration/manage-deployment/) and [ingress configuration rewrite](https://github.com/kubernetes/ingress/blob/master/controllers/nginx/configuration.md#rewrite).
+
+__Lines 7-9__: Ingress [spec](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) has all the information needed to configure a loadbalancer or proxy server. Most importantly, it contains a list of rules matched against all incoming requests. Currently the Ingress resource only supports http rules.
+
+__Lines 10-11__: Each http rule contains the following information: A host (e.g.: foo.bar.com, defaults to * in this example), a list of paths (e.g.: /testpath) each of which has an associated backend (test:80). Both the host and path must match the content of an incoming request before the loadbalancer directs traffic to the backend.
+
+__Lines 12-14__: A backend is a service:port combination as described in the [services doc](/docs/concepts/services-networking/service/). Ingress traffic is typically sent directly to the endpoints matching a backend.
+
+__Global Parameters__: For the sake of simplicity the example Ingress has no global parameters, see the [API reference](https://releases.k8s.io/{{page.githubbranch}}/staging/src/k8s.io/api/extensions/v1beta1/types.go) for a full definition of the resource. One can specify a global default backend in the absence of which requests that don't match a path in the spec are sent to the default backend of the Ingress controller.
+
+## Ingress controllers
+
+In order for the Ingress resource to work, the cluster must have an Ingress controller running. This is unlike other types of controllers, which typically run as part of the `kube-controller-manager` binary, and which are typically started automatically as part of cluster creation. You need to choose the ingress controller implementation that is the best fit for your cluster, or implement one.  Examples and instructions can be found [here](https://git.k8s.io/ingress/controllers).
+
+## Before you begin
+
+The following document describes a set of cross platform features exposed through the Ingress resource. Ideally, all Ingress controllers should fulfill this specification, but we're not there yet. The docs for the GCE and nginx controllers are [here](https://git.k8s.io/ingress/controllers/gce/README.md) and [here](https://git.k8s.io/ingress/controllers/nginx/README.md) respectively. **Make sure you review controller specific docs so you understand the caveats of each one**.
+
+## Types of Ingress
+
+### Single Service Ingress
+
+There are existing Kubernetes concepts that allow you to expose a single service (see [alternatives](#alternatives)), however you can do so through an Ingress as well, by specifying a *default backend* with no rules.
+
+{% include code.html language="yaml" file="ingress.yaml" ghlink="/docs/concepts/services-networking/ingress.yaml" %}
+
+If you create it using `kubectl create -f` you should see:
+
+```shell
+$ kubectl get ing
+NAME                RULE          BACKEND        ADDRESS
+test-ingress        -             testsvc:80     107.178.254.228
+```
+
+Where `107.178.254.228` is the IP allocated by the Ingress controller to satisfy this Ingress. The `RULE` column shows that all traffic send to the IP is directed to the Kubernetes Service listed under `BACKEND`.
+
+### Simple fanout
+
+As described previously, pods within kubernetes have IPs only visible on the cluster network, so we need something at the edge accepting ingress traffic and proxying it to the right endpoints. This component is usually a highly available loadbalancer. An Ingress allows you to keep the number of loadbalancers down to a minimum, for example, a setup like:
+
+```shell
+foo.bar.com -> 178.91.123.132 -> / foo    s1:80
+                                 / bar    s2:80
+```
+
+would require an Ingress such as:
+
+```yaml
+apiVersion: extensions/v1beta1
+kind: Ingress
+metadata:
+  name: test
+  annotations:
+    ingress.kubernetes.io/rewrite-target: /
+spec:
+  rules:
+  - host: foo.bar.com
+    http:
+      paths:
+      - path: /foo
+        backend:
+          serviceName: s1
+          servicePort: 80
+      - path: /bar
+        backend:
+          serviceName: s2
+          servicePort: 80
+```
+
+When you create the Ingress with `kubectl create -f`:
+
+```shell
+$ kubectl get ing
+NAME      RULE          BACKEND   ADDRESS
+test      -
+          foo.bar.com
+          /foo          s1:80
+          /bar          s2:80
+```
+The Ingress controller will provision an implementation specific loadbalancer that satisfies the Ingress, as long as the services (s1, s2) exist. When it has done so, you will see the address of the loadbalancer under the last column of the Ingress.
+
+### Name based virtual hosting
+
+Name-based virtual hosts use multiple host names for the same IP address.
+
+```
+foo.bar.com --|                 |-> foo.bar.com s1:80
+              | 178.91.123.132  |
+bar.foo.com --|                 |-> bar.foo.com s2:80
+```
+
+The following Ingress tells the backing loadbalancer to route requests based on the [Host header](https://tools.ietf.org/html/rfc7230#section-5.4).
+
+```yaml
+apiVersion: extensions/v1beta1
+kind: Ingress
+metadata:
+  name: test
+spec:
+  rules:
+  - host: foo.bar.com
+    http:
+      paths:
+      - backend:
+          serviceName: s1
+          servicePort: 80
+  - host: bar.foo.com
+    http:
+      paths:
+      - backend:
+          serviceName: s2
+          servicePort: 80
+```
+
+__Default Backends__: An Ingress with no rules, like the one shown in the previous section, sends all traffic to a single default backend. You can use the same technique to tell a loadbalancer where to find your website's 404 page, by specifying a set of rules *and* a default backend. Traffic is routed to your default backend if none of the Hosts in your Ingress match the Host in the request header, and/or none of the paths match the URL of the request.
+
+### TLS
+
+You can secure an Ingress by specifying a [secret](/docs/user-guide/secrets) that contains a TLS private key and certificate. Currently the Ingress only supports a single TLS port, 443, and assumes TLS termination. If the TLS configuration section in an Ingress specifies different hosts, they will be multiplexed on the same port according to the hostname specified through the SNI TLS extension (provided the Ingress controller supports SNI). The TLS secret must contain keys named `tls.crt` and `tls.key` that contain the certificate and private key to use for TLS, e.g.:
+
+```yaml
+apiVersion: v1
+data:
+  tls.crt: base64 encoded cert
+  tls.key: base64 encoded key
+kind: Secret
+metadata:
+  name: testsecret
+  namespace: default
+type: Opaque
+```
+
+Referencing this secret in an Ingress will tell the Ingress controller to secure the channel from the client to the loadbalancer using TLS:
+
+```yaml
+apiVersion: extensions/v1beta1
+kind: Ingress
+metadata:
+  name: no-rules-map
+spec:
+  tls:
+    - secretName: testsecret
+  backend:
+    serviceName: s1
+    servicePort: 80
+```
+
+Note that there is a gap between TLS features supported by various Ingress controllers. Please refer to documentation on [nginx](https://git.k8s.io/ingress/controllers/nginx/README.md#https), [GCE](https://git.k8s.io/ingress/controllers/gce/README.md#tls), or any other platform specific Ingress controller to understand how TLS works in your environment.
+
+### Loadbalancing
+
+An Ingress controller is bootstrapped with some loadbalancing policy settings that it applies to all Ingress, such as the loadbalancing algorithm, backend weight scheme etc. More advanced loadbalancing concepts (e.g.: persistent sessions, dynamic weights) are not yet exposed through the Ingress. You can still get these features through the [service loadbalancer](https://git.k8s.io/contrib/service-loadbalancer). With time, we plan to distill loadbalancing patterns that are applicable cross platform into the Ingress resource.
+
+It's also worth noting that even though health checks are not exposed directly through the Ingress, there exist parallel concepts in Kubernetes such as [readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) which allow you to achieve the same end result. Please review the controller specific docs to see how they handle health checks ([nginx](https://git.k8s.io/ingress/controllers/nginx/README.md), [GCE](https://git.k8s.io/ingress/controllers/gce/README.md#health-checks)).
+
+## Updating an Ingress
+
+Say you'd like to add a new Host to an existing Ingress, you can update it by editing the resource:
+
+```shell
+$ kubectl get ing
+NAME      RULE          BACKEND   ADDRESS
+test      -                       178.91.123.132
+          foo.bar.com
+          /foo          s1:80
+$ kubectl edit ing test
+```
+
+This should pop up an editor with the existing yaml, modify it to include the new Host.
+
+```yaml
+spec:
+  rules:
+  - host: foo.bar.com
+    http:
+      paths:
+      - backend:
+          serviceName: s1
+          servicePort: 80
+        path: /foo
+  - host: bar.baz.com
+    http:
+      paths:
+      - backend:
+          serviceName: s2
+          servicePort: 80
+        path: /foo
+..
+```
+
+saving it will update the resource in the API server, which should tell the Ingress controller to reconfigure the loadbalancer.
+
+```shell
+$ kubectl get ing
+NAME      RULE          BACKEND   ADDRESS
+test      -                       178.91.123.132
+          foo.bar.com
+          /foo          s1:80
+          bar.baz.com
+          /foo          s2:80
+```
+
+You can achieve the same by invoking `kubectl replace -f` on a modified Ingress yaml file.
+
+## Failing across availability zones
+
+Techniques for spreading traffic across failure domains differs between cloud providers. Please check the documentation of the relevant Ingress controller for details. Please refer to the federation [doc](/docs/concepts/cluster-administration/federation/) for details on deploying Ingress in a federated cluster.
+
+## Future Work
+
+* Various modes of HTTPS/TLS support (e.g.: SNI, re-encryption)
+* Requesting an IP or Hostname via claims
+* Combining L4 and L7 Ingress
+* More Ingress controllers
+
+Please track the [L7 and Ingress proposal](https://github.com/kubernetes/kubernetes/pull/12827) for more details on the evolution of the resource, and the [Ingress repository](https://github.com/kubernetes/ingress/tree/master) for more details on the evolution of various Ingress controllers.
+
+## Alternatives
+
+You can expose a Service in multiple ways that don't directly involve the Ingress resource:
+
+* Use [Service.Type=LoadBalancer](/docs/user-guide/services/#type-loadbalancer)
+* Use [Service.Type=NodePort](/docs/user-guide/services/#type-nodeport)
+* Use a [Port Proxy](https://git.k8s.io/contrib/for-demos/proxy-to-service)
+* Deploy the [Service loadbalancer](https://git.k8s.io/contrib/service-loadbalancer). This allows you to share a single IP among multiple Services and achieve more advanced loadbalancing through Service Annotations.

cn/docs/concepts/services-networking/ingress.yaml

@@ -0,0 +1,9 @@
+apiVersion: extensions/v1beta1
+kind: Ingress
+metadata:
+  name: test-ingress
+spec:
+  backend:
+    serviceName: testsvc
+    servicePort: 80
+

cn/docs/concepts/services-networking/network-policies.md

@@ -0,0 +1,104 @@
+---
+approvers:
+- thockin
+- caseydavenport
+- danwinship
+title: 网络策略
+---
+
+* TOC
+{:toc}
+
+网络策略（NetworkPolicy）是一种关于pod间及pod与其他网络端点间所允许的通信规则的规范。
+
+`NetworkPolicy` 资源使用标签选择pod，并定义选定pod所允许的通信规则。
+
+## 前提
+
+网络策略通过网络插件来实现，所以用户必须使用支持 `NetworkPolicy` 的网络解决方案 - 简单地创建资源对象，而没有控制器来使它生效的话，是没有任何作用的。
+
+## 隔离和非隔离的Pod
+
+默认情况下，Pod是非隔离的，它们接受任何来源的流量。
+
+Pod可以通过相关的网络策略进行隔离。一旦命名空间中有网络策略选择了特定的Pod，该Pod会拒绝网络策略所不允许的连接。 (命名空间下其他未被网络策略所选择的Pod会继续接收所有的流量)
+
+## `NetworkPolicy` 资源
+
+通过[api参考](/docs/api-reference/{{page.version}}/#networkpolicy-v1-networking)来了解资源定义。
+
+下面是一个 `NetworkPolicy` 的示例:
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: test-network-policy
+  namespace: default
+spec:
+  podSelector:
+    matchLabels:
+      role: db
+  ingress:
+  - from:
+    - namespaceSelector:
+        matchLabels:
+          project: myproject
+    - podSelector:
+        matchLabels:
+          role: frontend
+    ports:
+    - protocol: TCP
+      port: 6379
+```
+
+除非选择支持网络策略的网络解决方案，否则将上述示例发送到API服务器没有任何效果。
+
+__必填字段__: 与所有其他的Kubernetes配置一样，`NetworkPolicy` 需要 `apiVersion`、 `kind`和 `metadata` 字段。 关于配置文件操作的一般信息，请参考 [这里](/docs/user-guide/simple-yaml)、 [这里](/docs/user-guide/configuring-containers)和 [这里](/docs/user-guide/working-with-resources)。
+
+__spec__: `NetworkPolicy` [spec](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) 中包含了在一个命名空间中定义特定网络策略所需的所有信息
+
+__podSelector__: 每个 `NetworkPolicy` 都包括一个 `podSelector` ，它对该策略所应用的一组Pod进行选择。因为 `NetworkPolicy` 目前只支持定义 `ingress` 规则，这里的 `podSelector` 本质上是为该策略定义 "目标pod" 。示例中的策略选择带有 "role=db" 标签的pod。空的 `podSelector` 选择命名空间下的所有pod。
+
+__ingress__: 每个 `NetworkPolicy` 包含一个 `ingress` 规则的白名单列表。 （其中的）规则允许同时匹配 `from` 和 `ports` 部分的流量。示例策略中包含一条简单的规则： 它匹配一个单一的端口，来自两个来源中的一个， 第一个通过 `namespaceSelector` 指定，第二个通过 `podSelector` 指定。
+
+所以，示例网络策略:
+
+1. 隔离 "default" 命名空间下 "role=db" 的pod (如果它们不是已经被隔离的话)。
+2. 允许从 "default" 命名空间下带有 "role=frontend" 标签的pod到 "default" 命名空间下的pod的6379 TCP端口的连接。
+3. 允许从带有 "project=myproject" 标签的命名空间下的任何pod到 "default" 命名空间下的pod的6379 TCP端口的连接。
+
+查看 [网络策略入门指南](/docs/getting-started-guides/network-policy/walkthrough) 了解更多示例。
+
+## 默认策略
+
+用户可以通过创建一个选择所有Pod，但是不允许任何通信的网络策略，来为一个命名空间创建 "默认的" 隔离策略：
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: default-deny
+spec:
+  podSelector:
+```
+
+这可以确保即使Pod在未被其他任何网络策略所选择的情况下仍能被隔离。
+
+或者，如果用户希望允许一个命名空间下的所有Pod的所有通信 (即使已经添加了策略，使得一些pod被 "隔离")，仍可以创建一个明确允许所有通信的策略：
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: allow-all
+spec:
+  podSelector:
+  ingress:
+  - {}
+```
+
+## 下一步呢？
+
+- 查看 [声明网络策略](/docs/tasks/administer-cluster/declare-network-policy/)
+  来进行更多的示例演练

cn/docs/concepts/services-networking/nginx-secure-app.yaml

@@ -0,0 +1,43 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-nginx
+  labels:
+    run: my-nginx
+spec:
+  type: NodePort
+  ports:
+  - port: 8080
+    targetPort: 80
+    protocol: TCP
+    name: http
+  - port: 443
+    protocol: TCP
+    name: https
+  selector:
+    run: my-nginx
+---
+apiVersion: apps/v1beta1
+kind: Deployment
+metadata:
+  name: my-nginx
+spec:
+  replicas: 1
+  template:
+    metadata:
+      labels:
+        run: my-nginx
+    spec:
+      volumes:
+      - name: secret-volume
+        secret:
+          secretName: nginxsecret
+      containers:
+      - name: nginxhttps
+        image: bprashanth/nginxhttps:1.0
+        ports:
+        - containerPort: 443
+        - containerPort: 80
+        volumeMounts:
+        - mountPath: /etc/nginx/ssl
+          name: secret-volume

cn/docs/concepts/services-networking/nginx-svc.yaml

@@ -0,0 +1,12 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-nginx
+  labels:
+    run: my-nginx
+spec:
+  ports:
+  - port: 80
+    protocol: TCP
+  selector:
+    run: my-nginx

cn/docs/concepts/services-networking/run-my-nginx.yaml

@@ -0,0 +1,17 @@
+apiVersion: apps/v1beta1
+kind: Deployment
+metadata:
+  name: my-nginx
+spec:
+  replicas: 2
+  template:
+    metadata:
+      labels:
+        run: my-nginx
+    spec:
+      containers:
+      - name: my-nginx
+        image: nginx
+        ports:
+        - containerPort: 80
+

cn/docs/concepts/services-networking/service.md

@@ -0,0 +1,631 @@
+---
+assignees:
+- bprashanth
+title: Service
+redirect_from:
+- "/docs/user-guide/services/"
+- "/docs/user-guide/services/index.html"
+---
+
+
+
+Kubernetes [`Pod`](/docs/user-guide/pods) 是有生命周期的，它们可以被创建，也可以被销毁，然而一旦被销毁生命就永远结束。 
+通过 [`ReplicationController`](/docs/user-guide/replication-controller) 能够动态地创建和销毁 `Pod`（例如，需要进行扩缩容，或者执行 [滚动升级](/docs/user-guide/kubectl/v1.7/#rolling-update)）。 
+每个 `Pod` 都会获取它自己的 IP 地址，即使这些 IP 地址不总是稳定可依赖的。
+这会导致一个问题：在 Kubernetes 集群中，如果一组 `Pod`（称为 backend）为其它 `Pod` （称为 frontend）提供服务，那么那些 frontend 该如何发现，并连接到这组 `Pod` 中的哪些 backend 呢？
+
+
+
+关于 `Service`
+
+
+
+Kubernetes `Service` 定义了这样一种抽象：一个 `Pod` 的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。
+这一组 `Pod` 能够被 `Service` 访问到，通常是通过 [`Label Selector`](/docs/concepts/overview/working-with-objects/labels/#label-selectors)（查看下面了解，为什么可能需要没有 selector 的 `Service`）实现的。
+
+
+
+举个例子，考虑一个图片处理 backend，它运行了3个副本。这些副本是可互换的 —— frontend 不需要关心它们调用了哪个 backend 副本。
+然而组成这一组 backend 程序的 `Pod` 实际上可能会发生变化，frontend 客户端不应该也没必要知道，而且也不需要跟踪这一组 backend 的状态。
+`Service` 定义的抽象能够解耦这种关联。
+
+
+
+对 Kubernetes 集群中的应用，Kubernetes 提供了简单的 `Endpoints` API，只要 `Service` 中的一组 `Pod` 发生变更，应用程序就会被更新。
+对非 Kubernetes 集群中的应用，Kubernetes 提供了基于 VIP 的网桥的方式访问 `Service`，再由 `Service` 重定向到 backend `Pod`。
+
+* TOC
+{:toc}
+
+
+
+## 定义 Service
+
+
+
+一个 `Service` 在 Kubernetes 中是一个 REST 对象，和 `Pod` 类似。
+像所有的 REST 对象一样， `Service` 定义可以基于 POST 方式，请求 apiserver 创建新的实例。
+例如，假定有一组 `Pod`，它们对外暴露了 9376 端口，同时还被打上 `"app=MyApp"` 标签。
+
+```yaml
+kind: Service
+apiVersion: v1
+metadata:
+  name: my-service
+spec:
+  selector:
+    app: MyApp
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9376
+```
+
+
+
+上述配置将创建一个名称为 “my-service” 的 `Service` 对象，它会将请求代理到使用 TCP 端口 9376，并且具有标签 `"app=MyApp"` 的 `Pod` 上。
+这个 `Service` 将被指派一个 IP 地址（通常称为 “Cluster IP”），它会被服务的代理使用（见下面）。
+该 `Service` 的 selector 将会持续评估，处理结果将被 POST 到一个名称为 “my-service” 的 `Endpoints` 对象上。
+
+
+
+需要注意的是， `Service` 能够将一个接收端口映射到任意的 `targetPort`。
+默认情况下，`targetPort` 将被设置为与 `port` 字段相同的值。
+可能更有趣的是，`targetPort` 可以是一个字符串，引用了 backend `Pod` 的一个端口的名称。
+但是，实际指派给该端口名称的端口号，在每个 backend `Pod` 中可能并不相同。
+对于部署和设计 `Service` ，这种方式会提供更大的灵活性。
+例如，可以在 backend 软件下一个版本中，修改 Pod 暴露的端口，并不会中断客户端的调用。
+
+
+
+Kubernetes `Service` 能够支持 `TCP` 和 `UDP` 协议，默认 `TCP` 协议。 
+
+
+
+### 没有 selector 的 Service
+
+
+
+Servcie 抽象了该如何访问 Kubernetes `Pod`，但也能够抽象其它类型的 backend，例如：
+
+* 希望在生产环境中使用外部的数据库集群，但测试环境使用自己的数据库。
+* 希望服务指向另一个 [`Namespace`](/docs/user-guide/namespaces) 中或其它集群中的服务。
+* 正在将工作负载转移到 Kubernetes 集群，和运行在 Kubernetes 集群之外的 backend。
+
+在任何这些场景中，都能够定义没有 selector 的 `Service` ：
+
+```yaml
+kind: Service
+apiVersion: v1
+metadata:
+  name: my-service
+spec:
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9376
+```
+
+
+由于这个 `Service` 没有 selector，就不会创建相关的 `Endpoints` 对象。可以手动将 `Service` 映射到指定的 `Endpoints`：
+
+```yaml
+kind: Endpoints
+apiVersion: v1
+metadata:
+  name: my-service
+subsets:
+  - addresses:
+      - ip: 1.2.3.4
+    ports:
+      - port: 9376
+```
+
+
+
+注意：Endpoint IP 地址不能是 loopback（127.0.0.0/8）、 link-local（169.254.0.0/16）、或者 link-local 多播（224.0.0.0/24）。
+
+
+
+访问没有 selector 的 `Service`，与有 selector 的 `Service` 的原理相同。请求将被路由到用户定义的 Endpoint（该示例中为 `1.2.3.4:9376`）。
+
+
+
+ExternalName `Service` 是 `Service` 的特例，它没有 selector，也没有定义任何的端口和 Endpoint。
+相反地，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务。
+
+```yaml
+kind: Service
+apiVersion: v1
+metadata:
+  name: my-service
+  namespace: prod
+spec:
+  type: ExternalName
+  externalName: my.database.example.com
+```
+
+
+
+当查询主机 `my-service.prod.svc.CLUSTER`时，集群的 DNS 服务将返回一个值为 `my.database.example.com` 的 `CNAME` 记录。
+访问这个服务的工作方式与其它的相同，唯一不同的是重定向发生在 DNS 层，而且不会进行代理或转发。
+如果后续决定要将数据库迁移到 Kubernetes 集群中，可以启动对应的 Pod，增加合适的 Selector 或 Endpoint，修改 `Service` 的 `type`。
+
+
+
+## VIP 和 Service 代理
+
+
+
+在 Kubernetes 集群中，每个 Node 运行一个 `kube-proxy` 进程。`kube-proxy` 负责为 `Service` 实现了一种 VIP（虚拟 IP）的形式，而不是 `ExternalName` 的形式。
+在 Kubernetes v1.0 版本，代理完全在 userspace。在 Kubernetes v1.1 版本，新增了 iptables 代理，但并不是默认的运行模式。
+从 Kubernetes v1.2 起，默认就是 iptables 代理。
+
+
+
+在 Kubernetes v1.0 版本，`Service` 是 “4层”（TCP/UDP over IP）概念。
+在 Kubernetes v1.1 版本，新增了 `Ingress` API（beta 版），用来表示 “7层”（HTTP）服务。
+
+
+
+### userspace 代理模式
+
+
+
+这种模式，kube-proxy 会监视 Kubernetes master 对 `Service` 对象和 `Endpoints` 对象的添加和移除。
+对每个 `Service`，它会在本地 Node 上打开一个端口（随机选择）。
+任何连接到“代理端口”的请求，都会被代理到 `Service` 的backend `Pods` 中的某个上面（如 `Endpoints` 所报告的一样）。
+使用哪个 backend `Pod`，是基于 `Service` 的 `SessionAffinity` 来确定的。
+最后，它安装 iptables 规则，捕获到达该 `Service` 的 `clusterIP`（是虚拟 IP）和 `Port` 的请求，并重定向到代理端口，代理端口再代理请求到 backend `Pod`。
+
+
+
+网络返回的结果是，任何到达 `Service` 的 IP:Port 的请求，都会被代理到一个合适的 backend，不需要客户端知道关于 Kubernetes、`Service`、或 `Pod` 的任何信息。
+
+
+
+默认的策略是，通过 round-robin 算法来选择 backend `Pod`。
+实现基于客户端 IP 的会话亲和性，可以通过设置 `service.spec.sessionAffinity` 的值为 `"ClientIP"` （默认值为 `"None"`）。
+
+
+
+![userspace代理模式下Service概览图](/images/docs/services-userspace-overview.svg)
+
+
+
+### iptables 代理模式
+
+
+
+这种模式，kube-proxy 会监视 Kubernetes master 对 `Service` 对象和 `Endpoints` 对象的添加和移除。
+对每个 `Service`，它会安装 iptables 规则，从而捕获到达该 `Service` 的 `clusterIP`（虚拟 IP）和端口的请求，进而将请求重定向到 `Service` 的一组 backend 中的某个上面。
+对于每个 `Endpoints` 对象，它也会安装 iptables 规则，这个规则会选择一个 backend `Pod`。
+
+
+
+默认的策略是，随机选择一个 backend。
+实现基于客户端 IP 的会话亲和性，可以将 `service.spec.sessionAffinity` 的值设置为 `"ClientIP"` （默认值为 `"None"`）。
+
+
+
+和 userspace 代理类似，网络返回的结果是，任何到达 `Service` 的 IP:Port 的请求，都会被代理到一个合适的 backend，不需要客户端知道关于 Kubernetes、`Service`、或 `Pod` 的任何信息。
+这应该比 userspace 代理更快、更可靠。然而，不像 userspace 代理，如果初始选择的 `Pod` 没有响应，iptables 代理能够自动地重试另一个 `Pod`，所以它需要依赖 [readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#defining-readiness-probes)。
+
+
+
+![iptables代理模式下Service概览图](/images/docs/services-iptables-overview.svg)
+
+
+
+## 多端口 Service
+
+
+
+很多 `Service` 需要暴露多个端口。对于这种情况，Kubernetes 支持在 `Service` 对象中定义多个端口。
+当使用多个端口时，必须给出所有的端口的名称，这样 Endpoint 就不会产生歧义，例如：
+
+```yaml
+kind: Service
+apiVersion: v1
+metadata:
+  name: my-service
+spec:
+    selector:
+      app: MyApp
+    ports:
+      - name: http
+        protocol: TCP
+        port: 80
+        targetPort: 9376
+      - name: https
+        protocol: TCP
+        port: 443
+        targetPort: 9377
+```
+
+
+
+## 选择自己的 IP 地址
+
+
+
+在 `Service` 创建的请求中，可以通过设置 `spec.clusterIP` 字段来指定自己的集群 IP 地址。
+比如，希望替换一个已经已存在的 DNS 条目，或者遗留系统已经配置了一个固定的 IP 且很难重新配置。
+用户选择的 IP 地址必须合法，并且这个 IP 地址在 `service-cluster-ip-range` CIDR 范围内，这对 API Server 来说是通过一个标识来指定的。
+如果 IP 地址不合法，API Server 会返回 HTTP 状态码 422，表示值不合法。
+
+
+
+### 为何不使用 round-robin DNS？
+
+
+
+一个不时出现的问题是，为什么我们都使用 VIP 的方式，而不使用标准的 round-robin DNS，有如下几个原因：
+
+* 长久以来，DNS 库都没能认真对待 DNS TTL、缓存域名查询结果
+* 很多应用只查询一次 DNS 并缓存了结果
+   * 就算应用和库能够正确查询解析，每个客户端反复重解析造成的负载也是非常难以管理的
+
+我们尽力阻止用户做那些对他们没有好处的事情，如果很多人都来问这个问题，我们可能会选择实现它。
+
+
+
+## 服务发现
+
+
+
+Kubernetes 支持2种基本的服务发现模式 —— 环境变量和 DNS。
+
+
+
+### 环境变量
+
+
+
+当 `Pod` 运行在 `Node` 上，kubelet 会为每个活跃的 `Service` 添加一组环境变量。
+它同时支持 [Docker links兼容](https://docs.docker.com/userguide/dockerlinks/) 变量（查看 [makeLinkVariables](http://releases.k8s.io/{{page.githubbranch}}/pkg/kubelet/envvars/envvars.go#L49)）、简单的 `{SVCNAME}_SERVICE_HOST` 和 `{SVCNAME}_SERVICE_PORT` 变量，这里 `Service` 的名称需大写，横线被转换成下划线。
+
+
+
+举个例子，一个名称为 `"redis-master"` 的 Service 暴露了 TCP 端口 6379，同时给它分配了 Cluster IP 地址 10.0.0.11，这个 Service 生成了如下环境变量：
+
+```shell
+REDIS_MASTER_SERVICE_HOST=10.0.0.11
+REDIS_MASTER_SERVICE_PORT=6379
+REDIS_MASTER_PORT=tcp://10.0.0.11:6379
+REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379
+REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
+REDIS_MASTER_PORT_6379_TCP_PORT=6379
+REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11
+```
+
+
+*这意味着需要有顺序的要求* ——  `Pod` 想要访问的任何 `Service` 必须在 `Pod` 自己之前被创建，否则这些环境变量就不会被赋值。DNS 并没有这个限制。
+
+### DNS
+
+
+
+一个可选（尽管强烈推荐）[集群插件](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/README.md) 是 DNS 服务器。
+DNS 服务器监视着创建新 `Service` 的 Kubernetes API，从而为每一个 `Service` 创建一组 DNS 记录。
+如果整个集群的 DNS 一直被启用，那么所有的 `Pod` 应该能够自动对 `Service` 进行名称解析。
+
+
+
+例如，有一个名称为 `"my-service"` 的 `Service`，它在 Kubernetes 集群中名为 `"my-ns"` 的 `Namespace` 中，为 `"my-service.my-ns"` 创建了一条 DNS 记录。
+在名称为 `"my-ns"` 的 `Namespace` 中的 `Pod` 应该能够简单地通过名称查询找到 `"my-service"`。
+在另一个 `Namespace` 中的 `Pod` 必须限定名称为 `"my-service.my-ns"`。
+这些名称查询的结果是 Cluster IP。
+
+
+
+Kubernetes 也支持对端口名称的 DNS SRV（Service）记录。
+如果名称为 `"my-service.my-ns"` 的 `Service` 有一个名为 `"http"` 的 `TCP` 端口，可以对 `"_http._tcp.my-service.my-ns"` 执行 DNS SRV 查询，得到 `"http"` 的端口号。
+
+
+
+Kubernetes DNS 服务器是唯一的一种能够访问 `ExternalName` 类型的 Service 的方式。
+更多信息可以查看[DNS Pod 和 Service](/docs/concepts/services-networking/dns-pod-service/)。
+
+
+
+## Headless Service
+
+
+
+有时不需要或不想要负载均衡，以及单独的 Service IP。
+遇到这种情况，可以通过指定 Cluster IP（`spec.clusterIP`）的值为 `"None"` 来创建 `Headless` Service。
+
+
+
+这个选项允许开发人员自由寻找他们自己的方式，从而降低与 Kubernetes 系统的耦合性。
+应用仍然可以使用一种自注册的模式和适配器，对其它需要发现机制的系统能够很容易地基于这个 API 来构建。
+
+
+
+对这类 `Service` 并不会分配 Cluster IP，kube-proxy 不会处理它们，而且平台也不会为它们进行负载均衡和路由。
+DNS 如何实现自动配置，依赖于 `Service` 是否定义了 selector。
+
+
+
+### 配置 Selector
+
+
+
+对定义了 selector 的 Headless Service，Endpoint 控制器在 API 中创建了 `Endpoints` 记录，并且修改 DNS 配置返回 A 记录（地址），通过这个地址直接到达 `Service` 的后端  `Pod` 上。
+
+
+
+### 不配置 Selector
+
+
+
+对没有定义 selector 的 Headless Service，Endpoint 控制器不会创建 `Endpoints` 记录。
+然而 DNS 系统会查找和配置，无论是：
+
+* `ExternalName` 类型 Service 的 CNAME 记录
+  * 记录：与 Service 共享一个名称的任何 `Endpoints`，以及所有其它类型
+
+
+
+## 发布服务 —— 服务类型
+
+对一些应用（如 Frontend）的某些部分，可能希望通过外部（Kubernetes 集群外部）IP 地址暴露 Service。
+
+
+
+Kubernetes `ServiceTypes` 允许指定一个需要的类型的 Service，默认是 `ClusterIP` 类型。
+
+`Type` 的取值以及行为如下：
+
+* `ClusterIP`：通过集群的内部 IP 暴露服务，选择该值，服务只能够在集群内部可以访问，这也是默认的 `ServiceType`。
+* `NodePort`：通过每个 Node 上的 IP 和静态端口（`NodePort`）暴露服务。`NodePort` 服务会路由到 `ClusterIP` 服务，这个 `ClusterIP` 服务会自动创建。通过请求 `<NodeIP>:<NodePort>`，可以从集群的外部访问一个 `NodePort` 服务。
+* `LoadBalancer`：使用云提供商的负载局衡器，可以向外部暴露服务。外部的负载均衡器可以路由到 `NodePort` 服务和 `ClusterIP` 服务。
+* `ExternalName`：通过返回 `CNAME` 和它的值，可以将服务映射到 `externalName` 字段的内容（例如， `foo.bar.example.com`）。
+    没有任何类型代理被创建，这只有 Kubernetes 1.7 或更高版本的 `kube-dns` 才支持。
+
+
+
+### NodePort 类型
+
+如果设置 `type` 的值为 `"NodePort"`，Kubernetes master 将从给定的配置范围内（默认：30000-32767）分配端口，每个 Node 将从该端口（每个 Node 上的同一端口）代理到 `Service`。该端口将通过 `Service` 的 `spec.ports[*].nodePort` 字段被指定。
+
+
+
+
+如果需要指定的端口号，可以配置 `nodePort` 的值，系统将分配这个端口，否则调用 API 将会失败（比如，需要关心端口冲突的可能性）。 
+
+
+
+这可以让开发人员自由地安装他们自己的负载均衡器，并配置 Kubernetes 不能完全支持的环境参数，或者直接暴露一个或多个 Node 的 IP 地址。
+
+
+
+需要注意的是，Service 将能够通过 `<NodeIP>:spec.ports[*].nodePort` 和 `spec.clusterIp:spec.ports[*].port` 而对外可见。
+
+
+
+### LoadBalancer 类型
+
+
+
+使用支持外部负载均衡器的云提供商的服务，设置 `type` 的值为 `"LoadBalancer"`，将为 `Service` 提供负载均衡器。
+负载均衡器是异步创建的，关于被提供的负载均衡器的信息将会通过 `Service` 的 `status.loadBalancer` 字段被发布出去。
+
+```yaml
+kind: Service
+apiVersion: v1
+metadata:
+  name: my-service
+spec:
+  selector:
+    app: MyApp
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9376
+      nodePort: 30061
+  clusterIP: 10.0.171.239
+  loadBalancerIP: 78.11.24.19
+  type: LoadBalancer
+status:
+  loadBalancer:
+    ingress:
+      - ip: 146.148.47.155
+```
+
+
+来自外部负载均衡器的流量将直接打到 backend `Pod` 上，不过实际它们是如何工作的，这要依赖于云提供商。
+在这些情况下，将根据用户设置的 `loadBalancerIP` 来创建负载均衡器。
+某些云提供商允许设置 `loadBalancerIP`。如果没有设置 `loadBalancerIP`，将会给负载均衡器指派一个临时 IP。
+如果设置了 `loadBalancerIP`，但云提供商并不支持这种特性，那么设置的 `loadBalancerIP` 值将会被忽略掉。
+
+
+
+### AWS 内部负载均衡器
+在混合云环境中，有时从虚拟私有云（VPC）环境中的服务路由流量是非常有必要的。
+可以通过在 `Service` 中增加 `annotation` 来实现，如下所示：
+
+```yaml
+[...]
+metadata: 
+    name: my-service
+    annotations: 
+        service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0
+[...]
+```
+
+
+在水平分割的 DNS 环境中，需要两个 `Service` 来将外部和内部的流量路由到 Endpoint 上。
+
+
+
+### AWS SSL 支持
+对运行在 AWS 上部分支持 SSL 的集群，从 1.3 版本开始，可以为 `LoadBalancer` 类型的 `Service` 增加两个 annotation：
+
+```
+    metadata:
+      name: my-service
+      annotations:
+        service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012
+```
+
+
+
+第一个 annotation 指定了使用的证书。它可以是第三方发行商发行的证书，这个证书或者被上传到 IAM，或者由 AWS 的证书管理器创建。
+
+```yaml
+    metadata:
+      name: my-service
+      annotations:
+         service.beta.kubernetes.io/aws-load-balancer-backend-protocol: (https|http|ssl|tcp)
+```
+
+
+第二个 annotation 指定了 `Pod` 使用的协议。
+对于 HTTPS 和 SSL，ELB 将期望该 `Pod` 基于加密的连接来认证自身。
+
+
+
+HTTP 和 HTTPS 将选择7层代理：ELB 将中断与用户的连接，当转发请求时，会解析 Header 信息并添加上用户的 IP 地址（`Pod` 将只能在连接的另一端看到该 IP 地址）。
+
+TCP 和 SSL 将选择4层代理：ELB 将转发流量，并不修改 Header 信息。
+
+
+
+### 外部 IP
+
+如果外部的 IP 路由到集群中一个或多个 Node 上，Kubernetes `Service` 会被暴露给这些 `externalIPs`。
+通过外部 IP（作为目的 IP 地址）进入到集群，打到 `Service` 的端口上的流量，将会被路由到 `Service` 的 Endpoint 上。
+`externalIPs` 不会被 Kubernetes 管理，它属于集群管理员的职责范畴。
+
+根据 `Service` 的规定，`externalIPs` 可以同任意的 `ServiceType` 来一起指定。
+在上面的例子中，`my-service` 可以在 80.11.12.10:80（外部 IP:端口）上被客户端访问。
+
+```yaml
+kind: Service
+apiVersion: v1
+metadata:
+  name: my-service
+spec:
+  selector:
+    app: MyApp
+  ports:
+    - name: http
+      protocol: TCP
+      port: 80
+      targetPort: 9376
+  externalIPs: 
+    - 80.11.12.10
+```
+
+
+
+## 不足之处
+
+为 VIP 使用 userspace 代理，将只适合小型到中型规模的集群，不能够扩展到上千 `Service` 的大型集群。
+查看 [最初设计方案](http://issue.k8s.io/1107) 获取更多细节。
+
+
+
+使用 userspace 代理，隐藏了访问 `Service` 的数据包的源 IP 地址。
+这使得一些类型的防火墙无法起作用。
+iptables 代理不会隐藏 Kubernetes 集群内部的 IP 地址，但却要求客户端请求必须通过一个负载均衡器或 Node 端口。
+
+
+
+`Type` 字段支持嵌套功能 —— 每一层需要添加到上一层里面。
+不会严格要求所有云提供商（例如，GCE 就没必要为了使一个 `LoadBalancer` 能工作而分配一个 `NodePort`，但是 AWS 需要 ），但当前 API 是强制要求的。
+
+
+
+## 未来工作
+
+未来我们能预见到，代理策略可能会变得比简单的 round-robin 均衡策略有更多细微的差别，比如 master 选举或分片。
+我们也能想到，某些 `Service` 将具有 “真正” 的负载均衡器，这种情况下 VIP 将简化数据包的传输。
+
+
+
+我们打算为 L7（HTTP）`Service` 改进我们对它的支持。
+
+我们打算为 `Service` 实现更加灵活的请求进入模式，这些 `Service` 包含当前 `ClusterIP`、`NodePort` 和 `LoadBalancer` 模式，或者更多。
+
+
+
+## VIP 的那些骇人听闻的细节
+
+对很多想使用 `Service` 的人来说，前面的信息应该足够了。
+然而，有很多内部原理性的内容，还是值去理解的。
+
+
+
+### 避免冲突
+
+Kubernetes 最主要的哲学之一，是用户不应该暴露那些能够导致他们操作失败、但又不是他们的过错的场景。
+这种场景下，让我们来看一下网络端口 —— 用户不应该必须选择一个端口号，而且该端口还有可能与其他用户的冲突。
+这就是说，在彼此隔离状态下仍然会出现失败。
+
+
+
+为了使用户能够为他们的 `Service` 选择一个端口号，我们必须确保不能有2个 `Service` 发生冲突。
+我们可以通过为每个 `Service` 分配它们自己的 IP 地址来实现。
+
+
+
+为了保证每个 `Service` 被分配到一个唯一的 IP，需要一个内部的分配器能够原子地更新 etcd 中的一个全局分配映射表，这个更新操作要先于创建每一个 `Service`。
+为了使 `Service` 能够获取到 IP，这个映射表对象必须在注册中心存在，否则创建 `Service` 将会失败，指示一个 IP 不能被分配。
+一个后台 Controller 的职责是创建映射表（从 Kubernetes 的旧版本迁移过来，旧版本中是通过在内存中加锁的方式实现），并检查由于管理员干预和清除任意 IP 造成的不合理分配，这些 IP 被分配了但当前没有 `Service` 使用它们。
+
+
+
+### IP 和 VIP
+
+不像 `Pod` 的 IP 地址，它实际路由到一个固定的目的地，`Service` 的 IP 实际上不能通过单个主机来进行应答。
+相反，我们使用 `iptables`（Linux 中的数据包处理逻辑）来定义一个虚拟IP地址（VIP），它可以根据需要透明地进行重定向。
+当客户端连接到 VIP 时，它们的流量会自动地传输到一个合适的 Endpoint。
+环境变量和 DNS，实际上会根据 `Service` 的 VIP 和端口来进行填充。
+
+
+
+#### Userspace
+
+作为一个例子，考虑前面提到的图片处理应用程序。
+当创建 backend `Service` 时，Kubernetes master 会给它指派一个虚拟 IP 地址，比如 10.0.0.1。
+假设 `Service` 的端口是 1234，该 `Service` 会被集群中所有的 `kube-proxy` 实例观察到。
+当代理看到一个新的 `Service`， 它会打开一个新的端口，建立一个从该 VIP 重定向到新端口的 iptables，并开始接收请求连接。
+
+
+
+当一个客户端连接到一个 VIP，iptables 规则开始起作用，它会重定向该数据包到 `Service代理` 的端口。
+`Service代理` 选择一个 backend，并将客户端的流量代理到 backend 上。
+
+这意味着 `Service` 的所有者能够选择任何他们想使用的端口，而不存在冲突的风险。
+客户端可以简单地连接到一个 IP 和端口，而不需要知道实际访问了哪些 `Pod`。
+
+
+
+#### Iptables
+
+再次考虑前面提到的图片处理应用程序。
+当创建 backend `Service` 时，Kubernetes master 会给它指派一个虚拟 IP 地址，比如 10.0.0.1。
+假设 `Service` 的端口是 1234，该 `Service` 会被集群中所有的 `kube-proxy` 实例观察到。
+当代理看到一个新的 `Service`， 它会安装一系列的 iptables 规则，从 VIP 重定向到 per-`Service` 规则。
+该 per-`Service` 规则连接到 per-`Endpoint` 规则，该 per-`Endpoint` 规则会重定向（目标 NAT）到 backend。
+
+
+
+当一个客户端连接到一个 VIP，iptables 规则开始起作用。一个 backend 会被选择（或者根据会话亲和性，或者随机），数据包被重定向到这个 backend。
+不像 userspace 代理，数据包从来不拷贝到用户空间，kube-proxy 不是必须为该 VIP 工作而运行，并且客户端 IP 是不可更改的。
+当流量打到 Node 的端口上，或通过负载均衡器，会执行相同的基本流程，但是在那些案例中客户端 IP 是可以更改的。
+
+
+
+## API 对象
+
+在 Kubernetes REST API 中，Service 是 top-level 资源。关于 API 对象的更多细节可以查看：[Service API 对象](/docs/api-reference/{{page.version}}/#service-v1-core)。
+
+
+
+## 更多信息
+
+阅读 [使用 Service 连接 Frontend 到 Backend](/docs/tutorials/connecting-apps/connecting-frontend-backend/)。

cn/docs/concepts/workloads/controllers/cron-jobs.md

@@ -0,0 +1,213 @@
+---
+assignees:
+- erictune
+- soltysh
+- janetkuo
+title: Cron Job
+redirect_from:
+- "/docs/concepts/jobs/cron-jobs/"
+- "/docs/concepts/jobs/cron-jobs.html"
+- "/docs/user-guide/cron-jobs/"
+- "/docs/user-guide/cron-jobs.html"
+---
+
+* TOC
+{:toc}
+
+
+
+## Cron Job 是什么？
+
+_Cron Job_ 管理基于时间的 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)，即：
+
+* 在给定时间点只运行一次
+* 在给定时间点周期性地运行
+
+一个 CronJob 对象类似于 _crontab_ （cron table）文件中的一行。它根据指定的预定计划周期性地运行一个 Job，格式可以参考 [Cron](https://en.wikipedia.org/wiki/Cron) 。
+
+
+
+**注意：** 在预定计划中，问号（`?`）和星号（`*`）的意义是相同的，表示给定字段的取值是任意可用值。
+
+**注意：** 在 Kubernetes 1.4 版本引入了 ScheduledJob 资源，但从 1.5 版本开始改成了 CronJob。
+
+典型的用法如下所示：
+
+
+
+* 在给定的时间点调度 Job 运行
+* 创建周期性运行的 Job，例如：数据库备份、发送邮件。
+
+### 前提条件
+
+
+
+当使用的 Kubernetes 集群，版本 >= 1.4（对 ScheduledJob），>= 1.5（对 CronJob），当启动 API Server（参考 [为集群开启或关闭 API 版本](/docs/admin/cluster-management/#turn-on-or-off-an-api-version-for-your-cluster) 获取更多信息）时，通过传递选项 `--runtime-config=batch/v2alpha1=true`  可以开启 batch/v2alpha1 API。
+
+## 创建 Cron Job
+
+下面是一个 Cron Job 的例子。它会每分钟运行一个 Job，打印出当前时间并输出问候语 hello。
+
+% include code.html language="yaml" file="cronjob.yaml" ghlink="/docs/concepts/workloads/controllers/cronjob.yaml" %}
+
+下载并运行该示例 Cron Job，然后执行如下命令：
+
+```shell
+$ kubectl create -f ./cronjob.yaml
+cronjob "hello" created
+```
+
+
+
+可选地，使用 `kubectl run` 创建一个 Cron Job，不需要写完整的配置：
+
+```shell
+$ kubectl run hello --schedule="*/1 * * * *" --restart=OnFailure --image=busybox -- /bin/sh -c "date; echo Hello from the Kubernetes cluster"
+cronjob "hello" created
+```
+
+
+
+创建该 Cron Job 之后，通过如下命令获取它的状态信息：
+
+```shell
+$ kubectl get cronjob hello
+NAME      SCHEDULE      SUSPEND   ACTIVE    LAST-SCHEDULE
+hello     */1 * * * *   False     0         <none>
+```
+
+
+
+如上所示，既没有 active 的 Job，也没有被调度的 Job。
+
+等待并观察创建的 Job，大约一分钟时间：
+
+```shell
+$ kubectl get jobs --watch
+NAME               DESIRED   SUCCESSFUL   AGE
+hello-4111706356   1         1         2s
+```
+
+
+
+现在能看到一个名称为 hello 的 Job 在运行。我们可以停止观察，并再次获取该 Job 的状态信息：
+
+```shell
+$ kubectl get cronjob hello
+NAME      SCHEDULE      SUSPEND   ACTIVE    LAST-SCHEDULE
+hello     */1 * * * *   False     0         Mon, 29 Aug 2016 14:34:00 -0700
+```
+
+
+应该能够看到名称为 “hello” 的 Job 在 `LAST-SCHEDULE` 指定的时间点被调度了。当前存在 0 个活跃（Active）的 Job，说明该 Job 已经被调度运行完成或失败。
+
+现在，找到最近一次被调度的 Job 创建的 Pod，能够看到其中一个 Pod 的标准输出。注意，Job 名称和 Pod 名称是不一样的。
+
+```shell
+# Replace "hello-4111706356" with the job name in your system
+$ pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items..metadata.name})
+
+$ echo $pods
+hello-4111706356-o9qcm
+
+$ kubectl logs $pods
+Mon Aug 29 21:34:09 UTC 2016
+Hello from the Kubernetes cluster
+```
+
+
+## 删除 Cron Job
+
+一旦不再需要 Cron Job，简单地可以使用 `kubectl` 命令删除它：
+
+```shell
+$ kubectl delete cronjob hello
+cronjob "hello" deleted
+```
+
+
+
+这将会终止正在创建的 Job。然而，运行中的 Job 将不会被终止，不会删除 Job 或 它们的 Pod。为了清理那些 Job 和 Pod，需要列出该 Cron Job 创建的全部 Job，然后删除它们：
+
+```shell
+$ kubectl get jobs
+NAME               DESIRED   SUCCESSFUL   AGE
+hello-1201907962   1         1            11m
+hello-1202039034   1         1            8m
+...
+
+$ kubectl delete jobs hello-1201907962 hello-1202039034 ...
+job "hello-1201907962" deleted
+job "hello-1202039034" deleted
+...
+```
+
+
+
+一旦 Job 被删除，由 Job 创建的 Pod 也会被删除。注意，所有由名称为 “hello” 的 Cron Job 创建的 Job 会以前缀字符串 “hello-” 进行命名。如果想要删除当前 Namespace 中的所有 Job，可以通过命令 `kubectl delete jobs --all` 立刻删除它们。
+
+
+
+## Cron Job 限制
+
+Cron Job 在每次调度运行时间内 _大概_ 会创建一个 Job 对象。我们之所以说 _大概_ ，是因为在特定的环境下可能会创建两个 Job，或者一个 Job 都没创建。我们尝试少发生这种情况，但却不能完全避免。因此，创建 Job 操作应该是 _幂等的_。
+
+Job 根据它所创建的 Pod 的并行度，负责重试创建 Pod，并就决定这一组 Pod 的成功或失败。Cron Job 根本不会去检查 Pod。
+
+
+
+## 编写 Cron Job 规约
+
+和其它 Kubernetes 配置一样，Cron Job 需要 `apiVersion`、 `kind`、和 `metadata` 这三个字段。
+关于如何实现一个配置文件的更新信息，参考文档 [部署应用](/docs/user-guide/deploying-applications)、
+[配置容器](/docs/user-guide/configuring-containers) 和 
+[使用 kubectl 管理资源](/docs/user-guide/working-with-resources)。
+
+Cron Job 也需要 [`.spec` 段](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status)。
+
+**注意：** 对一个 Cron Job 的所有修改，尤其是对其 `.spec` 的修改，仅会在下一次运行的时候生效。
+
+
+### 调度
+
+ `.spec.schedule` 是 `.spec` 中必需的字段，它的值是 [Cron](https://en.wikipedia.org/wiki/Cron) 格式字的符串，例如：`0 * * * *`，或者 `@hourly`，根据指定的调度时间 Job 会被创建和执行。
+
+
+
+### Job 模板
+
+`.spec.jobTemplate` 是另一个 `.spec` 中必需的字段。它是 Job 的模板。
+除了它可以是嵌套的，并且不具有 `apiVersion` 或 `kind` 字段之外，它和 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) 一样具有完全相同的模式（schema）。
+参考 [编写 Job 规格](/docs/concepts/jobs/run-to-completion-finite-workloads/#writing-a-job-spec)。
+
+
+
+### 启动 Job 的期限（秒级别）
+
+`.spec.startingDeadlineSeconds` 字段是可选的。它表示启动 Job 的期限（秒级别），如果因为任何原因而错过了被调度的时间，那么错过执行时间的 Job 将被认为是失败的。如果没有指定，则没有期限。
+
+
+
+### 并发策略
+
+`.spec.concurrencyPolicy` 字段也是可选的。它指定了如何处理被 Cron Job 创建的 Job 的并发执行。只允许指定下面策略中的一种：
+
+* `Allow`（默认）：允许并发运行 Job
+* `Forbid`：禁止并发运行，如果前一个还没有完成，则直接跳过下一个
+* `Replace`：取消当前正在运行的 Job，用一个新的来替换
+
+注意，当前策略只能应用于同一个 Cron Job 创建的 Job。如果存在多个 Cron Job，它们创建的 Job 之间总是允许并发运行。
+
+
+
+### 挂起
+
+`.spec.suspend` 字段也是可选的。如果设置为 `true`，后续所有执行都将被挂起。它对已经开始执行的 Job 不起作用。默认值为 `false`。
+
+
+
+### Job 历史限制
+
+`.spec.successfulJobsHistoryLimit` 和 `.spec.failedJobsHistoryLimit` 这两个字段是可选的。它们指定了可以保留完成和失败 Job 数量的限制。
+
+默认没有限制，所有成功和失败的 Job 都会被保留。然而，当运行一个 Cron Job 时，很快就会堆积很多 Job，推荐设置这两个字段的值。设置限制值为 `0`，相关类型的 Job 完成后将不会被保留。

cn/docs/concepts/workloads/controllers/cronjob.yaml

@@ -0,0 +1,18 @@
+apiVersion: batch/v2alpha1
+kind: CronJob
+metadata:
+  name: hello
+spec:
+  schedule: "*/1 * * * *"
+  jobTemplate:
+    spec:
+      template:
+        spec:
+          containers:
+          - name: hello
+            image: busybox
+            args:
+            - /bin/sh
+            - -c
+            - date; echo Hello from the Kubernetes cluster
+          restartPolicy: OnFailure

cn/docs/concepts/workloads/controllers/daemonset.md

@@ -0,0 +1,164 @@
+---
+assignees:
+- erictune
+title: DaemonSet
+redirect_from:
+- "/docs/admin/daemons/"
+- "/docs/admin/daemons.html"
+---
+
+* TOC
+{:toc}
+
+
+
+## 什么是 DaemonSet？
+
+ _DaemonSet_ 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时，也会为他们新增一个 Pod 。
+ 当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
+
+ 
+
+使用 DaemonSet 的一些典型用法：
+
+- 运行集群存储 daemon，例如在每个节点上运行 `glusterd`、`ceph`。
+- 在每个节点上运行日志收集 daemon，例如`fluentd`、`logstash`。
+- 在每个节点上运行监控 daemon，例如 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter)、`collectd`、Datadog 代理、New Relic 代理，或 Ganglia `gmond`。
+
+一个简单的用法是在所有的节点上都启动一个 DaemonSet，将被作为每种类型的 daemon 使用。
+一个稍微复杂的用法是单独对每种 daemon 类型使用多个 DaemonSet，但具有不同的标志，和/或对不同硬件类型具有不同的内存、CPU要求。
+
+
+
+## 编写 DaemonSet 规约
+
+### 必需字段
+
+
+
+和其它所有 Kubernetes 配置一样，DaemonSet 需要 `apiVersion`、`kind` 和 `metadata` 字段。
+有关配置文件的基本信息，详见文档 [deploying applications](/docs/user-guide/deploying-applications/)、[配置容器](/docs/user-guide/configuring-containers/) 和 [资源管理](/docs/concepts/tools/kubectl/object-management-overview/) 。
+
+DaemonSet 也需要一个 [`.spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) 配置段。
+
+
+
+### Pod 模板
+
+`.spec` 唯一必需的字段是 `.spec.template`。
+
+
+
+`.spec.template` 是一个 [Pod 模板](/docs/user-guide/replication-controller/#pod-template)。
+它与 [Pod](/docs/user-guide/pods) 具有相同的 schema，除了它是嵌套的，而且不具有 `apiVersion` 或 `kind` 字段。
+
+除了 Pod 必需字段外，在 DaemonSet 中的 Pod 模板必须指定合理的标签（查看 [Pod Selector](#pod-selector)）。
+
+在 DaemonSet 中的 Pod 模板必须具有一个值为 `Always` 的 [`RestartPolicy`](/docs/user-guide/pod-states)，或者未指定它的值，默认是 `Always`。
+
+
+
+### Pod Selector
+
+`.spec.selector` 字段表示 Pod Selector，它与 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) 或其它资源的 `.spec.selector` 的作用是相同的。
+
+`spec.selector` 表示一个对象，它由如下两个字段组成：
+
+* `matchLabels` - 与 [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/) 的 `.spec.selector` 的作用相同。
+* `matchExpressions` - 允许构建更加复杂的 Selector，可以通过指定 key、value 列表，以及与 key 和 value 列表相关的操作符。
+
+
+
+当上述两个字段都指定时，结果表示的是 AND 关系。
+
+如果指定了 `.spec.selector`，必须与 `.spec.template.metadata.labels` 相匹配。如果没有指定，它们默认是等价的。如果与它们配置的不匹配，则会被 API 拒绝。
+
+如果 Pod 的 label 与 selector 匹配，或者直接基于其它的 DaemonSet、或者 Controller（例如 ReplicationController），也不可以创建任何 Pod。
+否则 DaemonSet Controller 将认为那些 Pod 是它创建的。Kubernetes 不会阻止这样做。一个场景是，可能希望在一个具有不同值的、用来测试用的节点上手动创建 Pod。
+
+
+
+### 仅在某些节点上运行 Pod
+
+如果指定了 `.spec.template.spec.nodeSelector`，DaemonSet Controller 将在能够与 [Node Selector](/docs/concepts/configuration/assign-pod-node/) 匹配的节点上创建 Pod。
+类似这种情况，可以指定 `.spec.template.spec.affinity`，然后 DaemonSet Controller 将在能够与 [Node Affinity](/docs/concepts/configuration/assign-pod-node/) 匹配的节点上创建 Pod。
+如果根本就没有指定，则 DaemonSet Controller 将在所有节点上创建 Pod。
+
+
+
+## 如何调度 Daemon Pod
+
+正常情况下，Pod 运行在哪个机器上是由 Kubernetes 调度器来选择的。然而，由 Daemon Controller 创建的 Pod 已经确定了在哪个机器上（Pod 创建时指定了 `.spec.nodeName`），因此：
+
+- DaemonSet Controller 并不关心一个节点的 [`unschedulable`](/docs/admin/node/#manual-node-administration) 字段。
+- DaemonSet Controller 可以创建 Pod，即使调度器还没有启动，这对集群启动是非常有帮助的。
+
+
+
+Daemon Pod 关心 [Taint 和 Toleration](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature)，它们会为没有指定 `tolerationSeconds` 的 `node.alpha.kubernetes.io/notReady` 和 `node.alpha.kubernetes.io/unreachable` 的 Taint，创建具有 `NoExecute` 的 Toleration。这确保了当 alpha 特性的 `TaintBasedEvictions` 被启用时，发生节点故障，比如网络分区，这时它们将不会被清除掉（当 `TaintBasedEvictions` 特性没有启用，在这些场景下也不会被清除，但会因为 NodeController 的硬编码行为而被清除，而不会因为 Toleration 导致被清除）。
+
+
+
+## 与 Daemon Pod 通信
+
+与 DaemonSet 中的 Pod 进行通信，几种可能的模式如下：
+
+- **Push**：配置 DaemonSet 中的 Pod 向其它 Service 发送更新，例如统计数据库。它们没有客户端。
+- **NodeIP 和已知端口**：DaemonSet 中的 Pod 可以使用 `hostPort`，从而可以通过节点 IP 访问到 Pod。客户端能通过某种方法知道节点 IP 列表，并且基于此也可以知道端口。
+- **DNS**：创建具有相同 Pod Selector 的 [Headless Service](/docs/user-guide/services/#headless-services)，然后通过使用 `endpoints` 资源或从 DNS 检索到多个 A 记录来发现 DaemonSet。
+- **Service**：创建具有相同 Pod Selector 的 Service，并使用该 Service 随机访问到某个节点上的 daemon（没有办法访问到特定节点）。
+
+
+
+## 更新 DaemonSet
+
+如果修改了节点标签（Label），DaemonSet 将立刻向新匹配上的节点添加 Pod，同时删除新近不能够匹配的节点上的 Pod。
+
+我们可以修改 DaemonSet 创建的 Pod。然而，不允许对 Pod 的所有字段进行更新。当下次节点（即使具有相同的名称）被创建时，DaemonSet Controller 还会使用最初的模板。
+
+
+
+可以删除一个 DaemonSet。如果使用 `kubectl` 并指定 `--cascade=false` 选项，则 Pod 将被保留在节点上。然后可以创建具有不同模板的新 DaemonSet。具有不同模板的新 DaemonSet 将能够通过标签匹配并识别所有已经存在的 Pod。它不会修改或删除它们，即使是错误匹配了 Pod 模板。通过删除 Pod 或者删除节点，可以强制创建新的 Pod。
+
+在 Kubernetes 1.6 或以后版本，可以在 DaemonSet 上 [执行滚动升级](/docs/tasks/manage-daemon/update-daemon-set/)。
+
+未来的 Kubernetes 版本将支持节点的可控更新。
+
+
+
+## DaemonSet 的可替代选择
+
+### init 脚本
+
+我们很可能希望直接在一个节点上启动 daemon 进程（例如，使用 `init`、`upstartd`、或 `systemd`）。这非常好，但基于 DaemonSet 来运行这些进程有如下一些好处：
+
+
+
+- 像对待应用程序一样，具备为 daemon 提供监控和管理日志的能力。
+- 为 daemon 和应用程序使用相同的配置语言和工具（如 Pod 模板、`kubectl`）。
+- Kubernetes 未来版本可能会支持对 DaemonSet 创建 Pod 与节点升级工作流进行集成。
+- 在资源受限的容器中运行 daemon，能够增加 daemon 和应用容器的隔离性。然而，这也实现了在容器中运行 daemon，但却不能在 Pod 中运行（例如，直接基于 Docker 启动）。
+
+
+
+### 裸 Pod
+
+可能要直接创建 Pod，同时指定其运行在特定的节点上。
+然而，DaemonSet 替换了由于任何原因被删除或终止的 Pod，例如节点失败、例行节点维护、内核升级。由于这个原因，我们应该使用 DaemonSet 而不是单独创建 Pod。
+
+
+
+### 静态 Pod
+
+可能需要通过在一个指定目录下编写文件来创建 Pod，该目录受 Kubelet 所监视。这些 Pod 被称为 [静态 Pod](/docs/concepts/cluster-administration/static-pod/)。
+不像 DaemonSet，静态 Pod 不受 kubectl 和其它 Kubernetes API 客户端管理。静态 Pod 不依赖于 apiserver，这使得它们在集群启动的情况下非常有用。
+而且，未来静态 Pod 可能会被废弃掉。
+
+
+
+### Replication Controller
+
+DaemonSet 与 [Replication Controller](/docs/user-guide/replication-controller) 非常类似，它们都能创建 Pod，这些 Pod 对应的进程都不希望被终止掉（例如，Web 服务器、存储服务器）。
+为无状态的 Service 使用 Replication Controller，比如前端（Frontend）服务，实现对副本的数量进行扩缩容、平滑升级，比之于精确控制 Pod 运行在某个主机上要重要得多。
+需要 Pod 副本总是运行在全部或特定主机上，并需要先于其他 Pod 启动，当这被认为非常重要时，应该使用 Daemon Controller。
+

cn/docs/concepts/workloads/controllers/deployment.md

@@ -0,0 +1,935 @@
+---
+approvers:
+- bgrant0607
+- janetkuo
+title: Deployments
+---
+
+{% capture overview %}
+
+A _Deployment_ controller provides declarative updates for [Pods](/docs/concepts/workloads/pods/pod/) and
+[ReplicaSets](/docs/concepts/workloads/controllers/replicaset/).
+
+You describe a _desired state_ in a Deployment object, and the Deployment controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.
+
+**Note:** You should not manage ReplicaSets owned by a Deployment. All the use cases should be covered by manipulating the Deployment object. Consider opening an issue in the main Kubernetes repository if your use case is not covered below.
+{: .note}
+
+{% endcapture %}
+
+
+{% capture body %}
+
+## Use Case
+
+The following are typical use cases for Deployments:
+
+* [Create a Deployment to rollout a ReplicaSet](#creating-a-deployment). The ReplicaSet creates Pods in the background. Check the status of the rollout to see if it succeeds or not.
+* [Declare the new state of the Pods](#updating-a-deployment) by updating the PodTemplateSpec of the Deployment. A new ReplicaSet is created and the Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates the revision of the Deployment.
+* [Rollback to an earlier Deployment revision](#rolling-back-a-deployment) if the current state of the Deployment is not stable. Each rollback updates the revision of the Deployment.
+* [Scale up the Deployment to facilitate more load.](#scaling-a-deployment)
+* [Pause the Deployment](#pausing-and-resuming-a-deployment) to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout.
+* [Use the status of the Deployment](#deployment-status) as an indicator that a rollout has stuck
+* [Clean up older ReplicaSets](#clean-up-policy) that you don't need anymore
+
+
+## Creating a Deployment
+
+Here is an example Deployment. It creates a ReplicaSet to bring up three nginx Pods.
+
+{% include code.html language="yaml" file="nginx-deployment.yaml" ghlink="/docs/concepts/workloads/controllers/nginx-deployment.yaml" %}
+
+Run the example by downloading the example file and then running this command:
+
+```shell
+$ kubectl create -f docs/user-guide/nginx-deployment.yaml --record
+deployment "nginx-deployment" created
+```
+
+Setting the kubectl flag `--record` to `true` allows you to record current command in the annotations of
+the resources being created or updated. It is useful for future introspection: for example, to see the
+commands executed in each Deployment revision.
+
+Then running `get` immediately will give:
+
+```shell
+$ kubectl get deployments
+NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+nginx-deployment   3         0         0            0           1s
+```
+
+This indicates that the Deployment's number of desired replicas is 3 (according to deployment's `.spec.replicas`),
+the number of current replicas (`.status.replicas`) is 0, the number of up-to-date replicas (`.status.updatedReplicas`)
+is 0, and the number of available replicas (`.status.availableReplicas`) is also 0.
+
+To see the Deployment rollout status, run:
+
+```shell
+$ kubectl rollout status deployment/nginx-deployment
+Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
+deployment "nginx-deployment" successfully rolled out
+```
+
+Running the `get` again a few seconds later should give:
+
+```shell
+$ kubectl get deployments
+NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+nginx-deployment   3         3         3            3           18s
+```
+
+This indicates that the Deployment has created all three replicas, and all replicas are up-to-date (contains the
+latest pod template) and available (pod status is ready for at least Deployment's `.spec.minReadySeconds`). Running
+`kubectl get rs` and `kubectl get pods` will show the ReplicaSet (RS) and Pods created.
+
+```shell
+$ kubectl get rs
+NAME                          DESIRED   CURRENT   READY   AGE
+nginx-deployment-2035384211   3         3         3       18s
+```
+
+You may notice that the name of the ReplicaSet is always `<the name of the Deployment>-<hash value of the pod template>`.
+
+```shell
+$ kubectl get pods --show-labels
+NAME                                READY     STATUS    RESTARTS   AGE       LABELS
+nginx-deployment-2035384211-7ci7o   1/1       Running   0          18s       app=nginx,pod-template-hash=2035384211
+nginx-deployment-2035384211-kzszj   1/1       Running   0          18s       app=nginx,pod-template-hash=2035384211
+nginx-deployment-2035384211-qqcnn   1/1       Running   0          18s       app=nginx,pod-template-hash=2035384211
+```
+
+The created ReplicaSet ensures that there are three nginx Pods at all times.
+
+**Note:** You must specify an appropriate selector and pod template labels in a Deployment (in this case,
+`app = nginx`). That is, don't overlap with other controllers (including other Deployments, ReplicaSets,
+StatefulSets, etc.). Kubernetes doesn't stop you from overlapping, and if multiple
+controllers have overlapping selectors, those controllers may fight with each other and won't behave
+correctly.
+{: .note}
+
+### Pod-template-hash label
+
+**Note:** Do not change this label.
+{: .note}
+
+Note the pod-template-hash label in the example output in the pod labels above. This label is added by the
+Deployment controller to every ReplicaSet that a Deployment creates or adopts. Its purpose is to make sure that child
+ReplicaSets of a Deployment do not overlap. It is computed by hashing the PodTemplate of the ReplicaSet
+and using the resulting hash as the label value that will be added in the ReplicaSet selector, pod template labels,
+and in any existing Pods that the ReplicaSet may have.
+
+## Updating a Deployment
+
+**Note:** A Deployment's rollout is triggered if and only if the Deployment's pod template (that is, `.spec.template`)
+is changed, for example if the labels or container images of the template are updated. Other updates, such as scaling the Deployment, do not trigger a rollout.
+{: .note}
+
+Suppose that we now want to update the nginx Pods to use the `nginx:1.9.1` image
+instead of the `nginx:1.7.9` image.
+
+```shell
+$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
+deployment "nginx-deployment" image updated
+```
+
+Alternatively, we can `edit` the Deployment and change `.spec.template.spec.containers[0].image` from `nginx:1.7.9` to `nginx:1.9.1`:
+
+```shell
+$ kubectl edit deployment/nginx-deployment
+deployment "nginx-deployment" edited
+```
+
+To see the rollout status, run:
+
+```shell
+$ kubectl rollout status deployment/nginx-deployment
+Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
+deployment "nginx-deployment" successfully rolled out
+```
+
+After the rollout succeeds, you may want to `get` the Deployment:
+
+```shell
+$ kubectl get deployments
+NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+nginx-deployment   3         3         3            3           36s
+```
+
+The number of up-to-date replicas indicates that the Deployment has updated the replicas to the latest configuration.
+The current replicas indicates the total replicas this Deployment manages, and the available replicas indicates the
+number of current replicas that are available.
+
+We can run `kubectl get rs` to see that the Deployment updated the Pods by creating a new ReplicaSet and scaling it
+up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
+
+```shell
+$ kubectl get rs
+NAME                          DESIRED   CURRENT   READY   AGE
+nginx-deployment-1564180365   3         3         3       6s
+nginx-deployment-2035384211   0         0         0       36s
+```
+
+Running `get pods` should now show only the new Pods:
+
+```shell
+$ kubectl get pods
+NAME                                READY     STATUS    RESTARTS   AGE
+nginx-deployment-1564180365-khku8   1/1       Running   0          14s
+nginx-deployment-1564180365-nacti   1/1       Running   0          14s
+nginx-deployment-1564180365-z9gth   1/1       Running   0          14s
+```
+
+Next time we want to update these Pods, we only need to update the Deployment's pod template again.
+
+Deployment can ensure that only a certain number of Pods may be down while they are being updated. By
+default, it ensures that at least 1 less than the desired number of Pods are up (1 max unavailable).
+
+Deployment can also ensure that only a certain number of Pods may be created above the desired number of
+Pods. By default, it ensures that at most 1 more than the desired number of Pods are up (1 max surge).
+
+In a future version of Kubernetes, the defaults will change from 1-1 to 25%-25%.
+
+For example, if you look at the above Deployment closely, you will see that it first created a new Pod,
+then deleted some old Pods and created new ones. It does not kill old Pods until a sufficient number of
+new Pods have come up, and does not create new Pods until a sufficient number of old Pods have been killed.
+It makes sure that number of available Pods is at least 2 and the number of total Pods is at most 4.
+
+```shell
+$ kubectl describe deployments
+Name:           nginx-deployment
+Namespace:      default
+CreationTimestamp:  Tue, 15 Mar 2016 12:01:06 -0700
+Labels:         app=nginx
+Selector:       app=nginx
+Replicas:       3 updated | 3 total | 3 available | 0 unavailable
+StrategyType:       RollingUpdate
+MinReadySeconds:    0
+RollingUpdateStrategy:  1 max unavailable, 1 max surge
+OldReplicaSets:     <none>
+NewReplicaSet:      nginx-deployment-1564180365 (3/3 replicas created)
+Events:
+  FirstSeen LastSeen    Count   From                     SubobjectPath   Type        Reason              Message
+  --------- --------    -----   ----                     -------------   --------    ------              -------
+  36s       36s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-2035384211 to 3
+  23s       23s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 1
+  23s       23s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 2
+  23s       23s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 2
+  21s       21s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 0
+  21s       21s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 3
+```
+
+Here we see that when we first created the Deployment, it created a ReplicaSet (nginx-deployment-2035384211)
+and scaled it up to 3 replicas directly. When we updated the Deployment, it created a new ReplicaSet
+(nginx-deployment-1564180365) and scaled it up to 1 and then scaled down the old ReplicaSet to 2, so that at
+least 2 Pods were available and at most 4 Pods were created at all times. It then continued scaling up and down
+the new and the old ReplicaSet, with the same rolling update strategy. Finally, we'll have 3 available replicas
+in the new ReplicaSet, and the old ReplicaSet is scaled down to 0.
+
+### Rollover (aka multiple updates in-flight)
+
+Each time a new deployment object is observed by the deployment controller, a ReplicaSet is created to bring up
+the desired Pods if there is no existing ReplicaSet doing so. Existing ReplicaSet controlling Pods whose labels
+match `.spec.selector` but whose template does not match `.spec.template` are scaled down. Eventually, the new
+ReplicaSet will be scaled to `.spec.replicas` and all old ReplicaSets will be scaled to 0.
+
+If you update a Deployment while an existing rollout is in progress, the Deployment will create a new ReplicaSet
+as per the update and start scaling that up, and will roll over the ReplicaSet that it was scaling up previously
+ -- it will add it to its list of old ReplicaSets and will start scaling it down.
+
+For example, suppose you create a Deployment to create 5 replicas of `nginx:1.7.9`,
+but then updates the Deployment to create 5 replicas of `nginx:1.9.1`, when only 3
+replicas of `nginx:1.7.9` had been created. In that case, Deployment will immediately start
+killing the 3 `nginx:1.7.9` Pods that it had created, and will start creating
+`nginx:1.9.1` Pods. It will not wait for 5 replicas of `nginx:1.7.9` to be created
+before changing course.
+
+### Label selector updates
+
+It is generally discouraged to make label selector updates and it is suggested to plan your selectors up front.
+In any case, if you need to perform a label selector update, exercise great caution and make sure you have grasped
+all of the implications.
+
+* Selector additions require the pod template labels in the Deployment spec to be updated with the new label too,
+otherwise a validation error is returned. This change is a non-overlapping one, meaning that the new selector does
+not select ReplicaSets and Pods created with the old selector, resulting in orphaning all old ReplicaSets and
+creating a new ReplicaSet.
+* Selector updates -- that is, changing the existing value in a selector key -- result in the same behavior as additions.
+* Selector removals -- that is, removing an existing key from the Deployment selector -- do not require any changes in the
+pod template labels. No existing ReplicaSet is orphaned, and a new ReplicaSet is not created, but note that the
+removed label still exists in any existing Pods and ReplicaSets.
+
+## Rolling Back a Deployment
+
+Sometimes you may want to rollback a Deployment; for example, when the Deployment is not stable, such as crash looping.
+By default, all of the Deployment's rollout history is kept in the system so that you can rollback anytime you want
+(you can change that by modifying revision history limit).
+
+**Note:** A Deployment's revision is created when a Deployment's rollout is triggered. This means that the
+new revision is created if and only if the Deployment's pod template (`.spec.template`) is changed,
+for example if you update the labels or container images of the template. Other updates, such as scaling the Deployment,
+do not create a Deployment revision, so that we can facilitate simultaneous manual- or auto-scaling.
+This means that when you roll back to an earlier revision, only the Deployment's pod template part is
+rolled back.
+{: .note}
+
+Suppose that we made a typo while updating the Deployment, by putting the image name as `nginx:1.91` instead of `nginx:1.9.1`:
+
+```shell
+$ kubectl set image deployment/nginx-deployment nginx=nginx:1.91
+deployment "nginx-deployment" image updated
+```
+
+The rollout will be stuck.
+
+```shell
+$ kubectl rollout status deployments nginx-deployment
+Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
+```
+
+Press Ctrl-C to stop the above rollout status watch. For more information on stuck rollouts,
+[read more here](#deployment-status).
+
+You will also see that both the number of old replicas (nginx-deployment-1564180365 and
+nginx-deployment-2035384211) and new replicas (nginx-deployment-3066724191) are 2.
+
+```shell
+$ kubectl get rs
+NAME                          DESIRED   CURRENT   READY   AGE
+nginx-deployment-1564180365   2         2         0       25s
+nginx-deployment-2035384211   0         0         0       36s
+nginx-deployment-3066724191   2         2         2       6s
+```
+
+Looking at the Pods created, you will see that the 2 Pods created by new ReplicaSet are stuck in an image pull loop.
+
+```shell
+$ kubectl get pods
+NAME                                READY     STATUS             RESTARTS   AGE
+nginx-deployment-1564180365-70iae   1/1       Running            0          25s
+nginx-deployment-1564180365-jbqqo   1/1       Running            0          25s
+nginx-deployment-3066724191-08mng   0/1       ImagePullBackOff   0          6s
+nginx-deployment-3066724191-eocby   0/1       ImagePullBackOff   0          6s
+```
+
+**Note:** The Deployment controller will stop the bad rollout automatically, and will stop scaling up the new
+ReplicaSet. This depends on the rollingUpdate parameters (`maxUnavailable` specifically) that you have specified.
+Kubernetes by default sets the value to 1 and spec.replicas to 1 so if you haven't cared about setting those
+parameters, your Deployment can have 100% unavailability by default! This will be fixed in Kubernetes in a future
+version.
+{: .note}
+
+```shell
+$ kubectl describe deployment
+Name:           nginx-deployment
+Namespace:      default
+CreationTimestamp:  Tue, 15 Mar 2016 14:48:04 -0700
+Labels:         app=nginx
+Selector:       app=nginx
+Replicas:       2 updated | 3 total | 2 available | 2 unavailable
+StrategyType:       RollingUpdate
+MinReadySeconds:    0
+RollingUpdateStrategy:  1 max unavailable, 1 max surge
+OldReplicaSets:     nginx-deployment-1564180365 (2/2 replicas created)
+NewReplicaSet:      nginx-deployment-3066724191 (2/2 replicas created)
+Events:
+  FirstSeen LastSeen    Count   From                    SubobjectPath   Type        Reason              Message
+  --------- --------    -----   ----                    -------------   --------    ------              -------
+  1m        1m          1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-2035384211 to 3
+  22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 1
+  22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 2
+  22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 2
+  21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 0
+  21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 3
+  13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 1
+  13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-1564180365 to 2
+  13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 2
+```
+
+To fix this, we need to rollback to a previous revision of Deployment that is stable.
+
+### Checking Rollout History of a Deployment
+
+First, check the revisions of this deployment:
+
+```shell
+$ kubectl rollout history deployment/nginx-deployment
+deployments "nginx-deployment"
+REVISION    CHANGE-CAUSE
+1           kubectl create -f docs/user-guide/nginx-deployment.yaml --record
+2           kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
+3           kubectl set image deployment/nginx-deployment nginx=nginx:1.91
+```
+
+Because we recorded the command while creating this Deployment using `--record`, we can easily see
+the changes we made in each revision.
+
+To further see the details of each revision, run:
+
+```shell
+$ kubectl rollout history deployment/nginx-deployment --revision=2
+deployments "nginx-deployment" revision 2
+  Labels:       app=nginx
+          pod-template-hash=1159050644
+  Annotations:  kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
+  Containers:
+   nginx:
+    Image:      nginx:1.9.1
+    Port:       80/TCP
+     QoS Tier:
+        cpu:      BestEffort
+        memory:   BestEffort
+    Environment Variables:      <none>
+  No volumes.
+```
+
+### Rolling Back to a Previous Revision
+
+Now we've decided to undo the current rollout and rollback to the previous revision:
+
+```shell
+$ kubectl rollout undo deployment/nginx-deployment
+deployment "nginx-deployment" rolled back
+```
+
+Alternatively, you can rollback to a specific revision by specify that in `--to-revision`:
+
+```shell
+$ kubectl rollout undo deployment/nginx-deployment --to-revision=2
+deployment "nginx-deployment" rolled back
+```
+
+For more details about rollout related commands, read [`kubectl rollout`](/docs/user-guide/kubectl/{{page.version}}/#rollout).
+
+The Deployment is now rolled back to a previous stable revision. As you can see, a `DeploymentRollback` event
+for rolling back to revision 2 is generated from Deployment controller.
+
+```shell
+$ kubectl get deployment
+NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+nginx-deployment   3         3         3            3           30m
+
+$ kubectl describe deployment
+Name:           nginx-deployment
+Namespace:      default
+CreationTimestamp:  Tue, 15 Mar 2016 14:48:04 -0700
+Labels:         app=nginx
+Selector:       app=nginx
+Replicas:       3 updated | 3 total | 3 available | 0 unavailable
+StrategyType:       RollingUpdate
+MinReadySeconds:    0
+RollingUpdateStrategy:  1 max unavailable, 1 max surge
+OldReplicaSets:     <none>
+NewReplicaSet:      nginx-deployment-1564180365 (3/3 replicas created)
+Events:
+  FirstSeen LastSeen    Count   From                    SubobjectPath   Type        Reason              Message
+  --------- --------    -----   ----                    -------------   --------    ------              -------
+  30m       30m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-2035384211 to 3
+  29m       29m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 1
+  29m       29m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 2
+  29m       29m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 2
+  29m       29m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 0
+  29m       29m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 2
+  29m       29m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 1
+  29m       29m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-1564180365 to 2
+  2m        2m          1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-3066724191 to 0
+  2m        2m          1       {deployment-controller }                Normal      DeploymentRollback  Rolled back deployment "nginx-deployment" to revision 2
+  29m       2m          2       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 3
+```
+
+## Scaling a Deployment
+
+You can scale a Deployment by using the following command:
+
+```shell
+$ kubectl scale deployment nginx-deployment --replicas=10
+deployment "nginx-deployment" scaled
+```
+
+Assuming [horizontal pod autoscaling](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) is enabled
+in your cluster, you can setup an autoscaler for your Deployment and choose the minimum and maximum number of
+Pods you want to run based on the CPU utilization of your existing Pods.
+
+```shell
+$ kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80
+deployment "nginx-deployment" autoscaled
+```
+
+### Proportional scaling
+
+RollingUpdate Deployments support running multiple versions of an application at the same time. When you
+or an autoscaler scales a RollingUpdate Deployment that is in the middle of a rollout (either in progress
+or paused), then the Deployment controller will balance the additional replicas in the existing active
+ReplicaSets (ReplicaSets with Pods) in order to mitigate risk. This is called *proportional scaling*.
+
+For example, you are running a Deployment with 10 replicas, [maxSurge](#max-surge)=3, and [maxUnavailable](#max-unavailable)=2.
+
+```shell
+$ kubectl get deploy
+NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+nginx-deployment     10        10        10           10          50s
+```
+
+You update to a new image which happens to be unresolvable from inside the cluster.
+
+```shell
+$ kubectl set image deploy/nginx-deployment nginx=nginx:sometag
+deployment "nginx-deployment" image updated
+```
+
+The image update starts a new rollout with ReplicaSet nginx-deployment-1989198191, but it's blocked due to the
+maxUnavailable requirement that we mentioned above.
+
+```shell
+$ kubectl get rs
+NAME                          DESIRED   CURRENT   READY     AGE
+nginx-deployment-1989198191   5         5         0         9s
+nginx-deployment-618515232    8         8         8         1m
+```
+
+Then a new scaling request for the Deployment comes along. The autoscaler increments the Deployment replicas
+to 15. The Deployment controller needs to decide where to add these new 5 replicas. If we weren't using
+proportional scaling, all 5 of them would be added in the new ReplicaSet. With proportional scaling, we
+spread the additional replicas across all ReplicaSets. Bigger proportions go to the ReplicaSets with the
+most replicas and lower proportions go to ReplicaSets with less replicas. Any leftovers are added to the
+ReplicaSet with the most replicas. ReplicaSets with zero replicas are not scaled up.
+
+In our example above, 3 replicas will be added to the old ReplicaSet and 2 replicas will be added to the
+new ReplicaSet. The rollout process should eventually move all replicas to the new ReplicaSet, assuming
+the new replicas become healthy.
+
+```shell
+$ kubectl get deploy
+NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+nginx-deployment     15        18        7            8           7m
+$ kubectl get rs
+NAME                          DESIRED   CURRENT   READY     AGE
+nginx-deployment-1989198191   7         7         0         7m
+nginx-deployment-618515232    11        11        11        7m
+```
+
+## Pausing and Resuming a Deployment
+
+You can pause a Deployment before triggering one or more updates and then resume it. This will allow you to
+apply multiple fixes in between pausing and resuming without triggering unnecessary rollouts.
+
+For example, with a Deployment that was just created:
+
+```shell
+$ kubectl get deploy
+NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+nginx     3         3         3            3           1m
+$ kubectl get rs
+NAME               DESIRED   CURRENT   READY     AGE
+nginx-2142116321   3         3         3         1m
+```
+
+Pause by running the following command:
+
+```shell
+$ kubectl rollout pause deployment/nginx-deployment
+deployment "nginx-deployment" paused
+```
+
+Then update the image of the Deployment:
+
+```shell
+$ kubectl set image deploy/nginx-deployment nginx=nginx:1.9.1
+deployment "nginx-deployment" image updated
+```
+
+Notice that no new rollout started:
+
+```shell
+$ kubectl rollout history deploy/nginx-deployment
+deployments "nginx"
+REVISION  CHANGE-CAUSE
+1   <none>
+
+$ kubectl get rs
+NAME               DESIRED   CURRENT   READY     AGE
+nginx-2142116321   3         3         3         2m
+```
+
+You can make as many updates as you wish, for example, update the resources that will be used:
+
+```shell
+$ kubectl set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi
+deployment "nginx" resource requirements updated
+```
+
+The initial state of the Deployment prior to pausing it will continue its function, but new updates to
+the Deployment will not have any effect as long as the Deployment is paused.
+
+Eventually, resume the Deployment and observe a new ReplicaSet coming up with all the new updates:
+
+```shell
+$ kubectl rollout resume deploy/nginx-deployment
+deployment "nginx" resumed
+$ kubectl get rs -w
+NAME               DESIRED   CURRENT   READY     AGE
+nginx-2142116321   2         2         2         2m
+nginx-3926361531   2         2         0         6s
+nginx-3926361531   2         2         1         18s
+nginx-2142116321   1         2         2         2m
+nginx-2142116321   1         2         2         2m
+nginx-3926361531   3         2         1         18s
+nginx-3926361531   3         2         1         18s
+nginx-2142116321   1         1         1         2m
+nginx-3926361531   3         3         1         18s
+nginx-3926361531   3         3         2         19s
+nginx-2142116321   0         1         1         2m
+nginx-2142116321   0         1         1         2m
+nginx-2142116321   0         0         0         2m
+nginx-3926361531   3         3         3         20s
+^C
+$ kubectl get rs
+NAME               DESIRED   CURRENT   READY     AGE
+nginx-2142116321   0         0         0         2m
+nginx-3926361531   3         3         3         28s
+```
+
+**Note:** You cannot rollback a paused Deployment until you resume it.
+{: .note}
+
+## Deployment status
+
+A Deployment enters various states during its lifecycle. It can be [progressing](#progressing-deployment) while
+rolling out a new ReplicaSet, it can be [complete](#complete-deployment), or it can [fail to progress](#failed-deployment).
+
+### Progressing Deployment
+
+Kubernetes marks a Deployment as _progressing_ when one of the following tasks is performed:
+
+* The Deployment creates a new ReplicaSet.
+* The Deployment is scaling up its newest ReplicaSet.
+* The Deployment is scaling down its older ReplicaSet(s).
+* New Pods become ready or available (ready for at least [MinReadySeconds](#min-ready-seconds)).
+
+You can monitor the progress for a Deployment by using `kubectl rollout status`.
+
+### Complete Deployment
+
+Kubernetes marks a Deployment as _complete_ when it has the following characteristics:
+
+* All of the replicas associated with the Deployment have been updated to the latest version you've specified, meaning any
+updates you've requested have been completed.
+* All of the replicas associated with the Deployment are available.
+* No old replicas for the Deployment are running.
+
+You can check if a Deployment has completed by using `kubectl rollout status`. If the rollout completed
+successfully, `kubectl rollout status` returns a zero exit code.
+
+```shell
+$ kubectl rollout status deploy/nginx-deployment
+Waiting for rollout to finish: 2 of 3 updated replicas are available...
+deployment "nginx" successfully rolled out
+$ echo $?
+0
+```
+
+### Failed Deployment
+
+Your Deployment may get stuck trying to deploy its newest ReplicaSet without ever completing. This can occur
+due to some of the following factors:
+
+* Insufficient quota
+* Readiness probe failures
+* Image pull errors
+* Insufficient permissions
+* Limit ranges
+* Application runtime misconfiguration
+
+One way you can detect this condition is to specify a deadline parameter in your Deployment spec:
+([`spec.progressDeadlineSeconds`](#progress-deadline-seconds)). `spec.progressDeadlineSeconds` denotes the
+number of seconds the Deployment controller waits before indicating (in the Deployment status) that the
+Deployment progress has stalled.
+
+The following `kubectl` command sets the spec with `progressDeadlineSeconds` to make the controller report
+lack of progress for a Deployment after 10 minutes:
+
+```shell
+$ kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
+"nginx-deployment" patched
+```
+Once the deadline has been exceeded, the Deployment controller adds a DeploymentCondition with the following
+attributes to the Deployment's `status.conditions`:
+
+* Type=Progressing
+* Status=False
+* Reason=ProgressDeadlineExceeded
+
+See the [Kubernetes API conventions](https://git.k8s.io/community/contributors/devel/api-conventions.md#typical-status-properties) for more information on status conditions.
+
+**Note:** Kubernetes will take no action on a stalled Deployment other than to report a status condition with
+`Reason=ProgressDeadlineExceeded`. Higher level orchestrators can take advantage of it and act accordingly, for
+example, rollback the Deployment to its previous version.
+{: .note}
+
+**Note:** If you pause a Deployment, Kubernetes does not check progress against your specified deadline. You can
+safely pause a Deployment in the middle of a rollout and resume without triggering the condition for exceeding the
+deadline.
+{: .note}
+
+You may experience transient errors with your Deployments, either due to a low timeout that you have set or
+due to any other kind of error that can be treated as transient. For example, let's suppose you have
+insufficient quota. If you describe the Deployment you will notice the following section:
+
+```shell
+$ kubectl describe deployment nginx-deployment
+<...>
+Conditions:
+  Type            Status  Reason
+  ----            ------  ------
+  Available       True    MinimumReplicasAvailable
+  Progressing     True    ReplicaSetUpdated
+  ReplicaFailure  True    FailedCreate
+<...>
+```
+
+If you run `kubectl get deployment nginx-deployment -o yaml`, the Deployement status might look like this:
+
+```
+status:
+  availableReplicas: 2
+  conditions:
+  - lastTransitionTime: 2016-10-04T12:25:39Z
+    lastUpdateTime: 2016-10-04T12:25:39Z
+    message: Replica set "nginx-deployment-4262182780" is progressing.
+    reason: ReplicaSetUpdated
+    status: "True"
+    type: Progressing
+  - lastTransitionTime: 2016-10-04T12:25:42Z
+    lastUpdateTime: 2016-10-04T12:25:42Z
+    message: Deployment has minimum availability.
+    reason: MinimumReplicasAvailable
+    status: "True"
+    type: Available
+  - lastTransitionTime: 2016-10-04T12:25:39Z
+    lastUpdateTime: 2016-10-04T12:25:39Z
+    message: 'Error creating: pods "nginx-deployment-4262182780-" is forbidden: exceeded quota:
+      object-counts, requested: pods=1, used: pods=3, limited: pods=2'
+    reason: FailedCreate
+    status: "True"
+    type: ReplicaFailure
+  observedGeneration: 3
+  replicas: 2
+  unavailableReplicas: 2
+```
+
+Eventually, once the Deployment progress deadline is exceeded, Kubernetes updates the status and the
+reason for the Progressing condition:
+
+```
+Conditions:
+  Type            Status  Reason
+  ----            ------  ------
+  Available       True    MinimumReplicasAvailable
+  Progressing     False   ProgressDeadlineExceeded
+  ReplicaFailure  True    FailedCreate
+```
+
+You can address an issue of insufficient quota by scaling down your Deployment, by scaling down other
+controllers you may be running, or by increasing quota in your namespace. If you satisfy the quota
+conditions and the Deployment controller then completes the Deployment rollout, you'll see the
+Deployment's status update with a successful condition (`Status=True` and `Reason=NewReplicaSetAvailable`).
+
+```
+Conditions:
+  Type          Status  Reason
+  ----          ------  ------
+  Available     True    MinimumReplicasAvailable
+  Progressing   True    NewReplicaSetAvailable
+```
+
+`Type=Available` with `Status=True` means that your Deployment has minimum availability. Minimum availability is dictated
+by the parameters specified in the deployment strategy. `Type=Progressing` with `Status=True` means that your Deployment
+is either in the middle of a rollout and it is progressing or that it has successfully completed its progress and the minimum
+required new replicas are available (see the Reason of the condition for the particulars - in our case
+`Reason=NewReplicaSetAvailable` means that the Deployment is complete).
+
+You can check if a Deployment has failed to progress by using `kubectl rollout status`. `kubectl rollout status`
+returns a non-zero exit code if the Deployment has exceeded the progression deadline.
+
+```shell
+$ kubectl rollout status deploy/nginx-deployment
+Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
+error: deployment "nginx" exceeded its progress deadline
+$ echo $?
+1
+```
+
+### Operating on a failed deployment
+
+All actions that apply to a complete Deployment also apply to a failed Deployment. You can scale it up/down, roll back
+to a previous revision, or even pause it if you need to apply multiple tweaks in the Deployment pod template.
+
+## Clean up Policy
+
+You can set `.spec.revisionHistoryLimit` field in a Deployment to specify how many old ReplicaSets for
+this Deployment you want to retain. The rest will be garbage-collected in the background. By default,
+all revision history will be kept. In a future version, it will default to switch to 2.
+
+**Note:** Explicitly setting this field to 0, will result in cleaning up all the history of your Deployment
+thus that Deployment will not be able to roll back.
+{: .note}
+
+## Use Cases
+
+### Canary Deployment
+
+If you want to roll out releases to a subset of users or servers using the Deployment, you
+can create multiple Deployments, one for each release, following the canary pattern described in
+[managing resources](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments).
+
+## Writing a Deployment Spec
+
+As with all other Kubernetes configs, a Deployment needs `apiVersion`, `kind`, and `metadata` fields.
+For general information about working with config files, see [deploying applications](/docs/tutorials/stateless-application/run-stateless-application-deployment/),
+configuring containers, and [using kubectl to manage resources](/docs/tutorials/object-management-kubectl/object-management/) documents.
+
+A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status).
+
+### Pod Template
+
+The `.spec.template` is the only required field of the `.spec`.
+
+The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [Pod](/docs/concepts/workloads/pods/pod/), 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 Deployment must specify appropriate
+labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [selector](#selector)).
+
+Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/) equal to `Always` is
+allowed, which is the default if not specified.
+
+### Replicas
+
+`.spec.replicas` is an optional field that specifies the number of desired Pods. It defaults to 1.
+
+### Selector
+
+`.spec.selector` is an optional field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/)
+for the Pods targeted by this deployment.
+
+If specified, `.spec.selector` must match `.spec.template.metadata.labels`, or it will be rejected by
+the API.  If `.spec.selector` is unspecified, `.spec.selector.matchLabels` defaults to
+`.spec.template.metadata.labels`.
+
+A Deployment may terminate Pods whose labels match the selector if their template is different
+from `.spec.template` or if the total number of such Pods exceeds `.spec.replicas`. It brings up new
+Pods with `.spec.template` if the number of Pods is less than the desired number.
+
+**Note:** You should not create other pods whose labels match this selector, either directly, by creating
+another Deployment, or by creating another controller such as a ReplicaSet or a ReplicationController. If you
+do so, the first Deployment thinks that it created these other pods. Kubernetes does not stop you from doing this.
+{: .note}
+
+If you have multiple controllers that have overlapping selectors, the controllers will fight with each
+other and won't behave correctly.
+
+### Strategy
+
+`.spec.strategy` specifies the strategy used to replace old Pods by new ones.
+`.spec.strategy.type` can be "Recreate" or "RollingUpdate". "RollingUpdate" is
+the default value.
+
+#### Recreate Deployment
+
+All existing Pods are killed before new ones are created when `.spec.strategy.type==Recreate`.
+
+#### Rolling Update Deployment
+
+The Deployment updates Pods in a [rolling update](/docs/tasks/run-application/rolling-update-replication-controller/)
+fashion when `.spec.strategy.type==RollingUpdate`. You can specify `maxUnavailable` and `maxSurge` to control
+the rolling update process.
+
+##### Max Unavailable
+
+`.spec.strategy.rollingUpdate.maxUnavailable` is an optional field that specifies the maximum number
+of Pods that can be unavailable during the update process. The value can be an absolute number (for example, 5)
+or a percentage of desired Pods (for example, 10%). The absolute number is calculated from percentage by
+rounding down. The value cannot be 0 if `.spec.strategy.rollingUpdate.maxSurge` is 0. The default value is 25%.
+
+For example, when this value is set to 30%, the old ReplicaSet can be scaled down to 70% of desired
+Pods immediately when the rolling update starts. Once new Pods are ready, old ReplicaSet can be scaled
+down further, followed by scaling up the new ReplicaSet, ensuring that the total number of Pods available
+at all times during the update is at least 70% of the desired Pods.
+
+##### Max Surge
+
+`.spec.strategy.rollingUpdate.maxSurge` is an optional field that specifies the maximum number of Pods
+that can be created over the desired number of Pods. The value can be an absolute number (for example, 5) or a
+percentage of desired Pods (for example, 10%). The value cannot be 0 if `MaxUnavailable` is 0. The absolute number
+is calculated from the percentage by rounding up. The default value is 25%.
+
+For example, when this value is set to 30%, the new ReplicaSet can be scaled up immediately when the
+rolling update starts, such that the total number of old and new Pods does not exceed 130% of desired
+Pods. Once old Pods have been killed, the new ReplicaSet can be scaled up further, ensuring that the
+total number of Pods running at any time during the update is at most 130% of desired Pods.
+
+### Progress Deadline Seconds
+
+`.spec.progressDeadlineSeconds` is an optional field that specifies the number of seconds you want
+to wait for your Deployment to progress before the system reports back that the Deployment has
+[failed progressing](#failed-deployment) - surfaced as a condition with `Type=Progressing`, `Status=False`.
+and `Reason=ProgressDeadlineExceeded` in the status of the resource. The deployment controller will keep
+retrying the Deployment. In the future, once automatic rollback will be implemented, the deployment
+controller will roll back a Deployment as soon as it observes such a condition.
+
+If specified, this field needs to be greater than `.spec.minReadySeconds`.
+
+### Min Ready Seconds
+
+`.spec.minReadySeconds` is an optional field that specifies the minimum number of seconds for which a newly
+created Pod should be ready without any of its containers crashing, for it to be considered available.
+This defaults to 0 (the Pod will be considered available as soon as it is ready). To learn more about when
+a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
+
+### Rollback To
+
+`.spec.rollbackTo` is an optional field with the configuration the Deployment
+should roll back to. Setting this field triggers a rollback, and this field will
+be cleared by the server after a rollback is done.
+
+Because this field will be cleared by the server, it should not be used
+declaratively. For example, you should not perform `kubectl apply` with a
+manifest with `.spec.rollbackTo` field set.
+
+#### Revision
+
+`.spec.rollbackTo.revision` is an optional field specifying the revision to roll
+back to. Setting to 0 means rolling back to the last revision in history;
+otherwise, means rolling back to the specified revision. This defaults to 0 when
+[`spec.rollbackTo`](#rollback-to) is set.
+
+### Revision History Limit
+
+A Deployment's revision history is stored in the replica sets it controls.
+
+`.spec.revisionHistoryLimit` is an optional field that specifies the number of old ReplicaSets to retain
+to allow rollback. Its ideal value depends on the frequency and stability of new Deployments. All old
+ReplicaSets will be kept by default, consuming resources in `etcd` and crowding the output of `kubectl get rs`,
+if this field is not set. The configuration of each Deployment revision is stored in its ReplicaSets;
+therefore, once an old ReplicaSet is deleted, you lose the ability to rollback to that revision of Deployment.
+
+More specifically, setting this field to zero means that all old ReplicaSets with 0 replica will be cleaned up.
+In this case, a new Deployment rollout cannot be undone, since its revision history is cleaned up.
+
+### Paused
+
+`.spec.paused` is an optional boolean field for pausing and resuming a Deployment. The only difference between
+a paused Deployment and one that is not paused, is that any changes into the PodTemplateSpec of the paused
+Deployment will not trigger new rollouts as long as it is paused. A Deployment is not paused by default when
+it is created.
+
+## Alternative to Deployments
+
+### kubectl rolling update
+
+[Kubectl rolling update](/docs/user-guide/kubectl/{{page.version}}/#rolling-update) updates Pods and ReplicationControllers
+in a similar fashion. But Deployments are recommended, since they are declarative, server side, and have
+additional features, such as rolling back to any previous revision even after the rolling update is done.
+
+{% endcapture %}
+
+{% include templates/concept.md %}

cn/docs/concepts/workloads/controllers/frontend.yaml

@@ -0,0 +1,45 @@
+apiVersion: extensions/v1beta1
+kind: ReplicaSet
+metadata:
+  name: frontend
+  # these labels can be applied automatically
+  # from the labels in the pod template if not set
+  # labels:
+    # app: guestbook
+    # tier: frontend
+spec:
+  # this replicas value is default
+  # modify it according to your case
+  replicas: 3
+  # selector can be applied automatically
+  # from the labels in the pod template if not set,
+  # but we are specifying the selector here to
+  # demonstrate its usage.
+  selector:
+    matchLabels:
+      tier: frontend
+    matchExpressions:
+      - {key: tier, operator: In, values: [frontend]}
+  template:
+    metadata:
+      labels:
+        app: guestbook
+        tier: frontend
+    spec:
+      containers:
+      - name: php-redis
+        image: gcr.io/google_samples/gb-frontend:v3
+        resources:
+          requests:
+            cpu: 100m
+            memory: 100Mi
+        env:
+        - name: GET_HOSTS_FROM
+          value: dns
+          # If your cluster config does not include a dns service, then to
+          # instead access environment variables to find service host
+          # info, comment out the 'value: dns' line above, and uncomment the
+          # line below.
+          # value: env
+        ports:
+        - containerPort: 80

cn/docs/concepts/workloads/controllers/garbage-collection.md

@@ -0,0 +1,180 @@
+---
+title: 垃圾收集
+redirect_from:
+- "/docs/concepts/abstractions/controllers/garbage-collection/"
+- "/docs/concepts/abstractions/controllers/garbage-collection.html"
+- "/docs/user-guide/garbage-collection/"
+- "/docs/user-guide/garbage-collection.html"
+
+---
+
+{% capture overview %}
+
+
+
+Kubernetes 垃圾收集器的角色是删除指定的对象，这些对象曾经有但以后不再拥有 Owner 了。
+
+**注意**：垃圾收集是 beta 特性，在 Kubernetes 1.4 及以上版本默认启用。
+
+{% endcapture %}
+
+
+{% capture body %}
+
+
+## Owner 和 Dependent
+
+某些 Kubernetes 对象是其它一些对象的 Owner。例如，一个 ReplicaSet 是一组 Pod 的 Owner。
+具有 Owner 的对象被称为是 Owner 的 *Dependent*。
+每个 Dependent 对象具有一个指向其所属对象的 `metadata.ownerReferences` 字段。
+
+有时，Kubernetes 会自动设置 `ownerReference` 的值。
+例如，当创建一个 ReplicaSet 时，Kubernetes 自动设置 ReplicaSet 中每个 Pod 的 `ownerReference` 字段值。
+在 1.6 版本，Kubernetes 会自动为某些对象设置 `ownerReference` 的值，这些对象是由 ReplicationController、ReplicaSet、StatefulSet、DaemonSet 和 Deployment 所创建或管理。
+
+
+
+也可以通过手动设置 `ownerReference` 的值，来指定 Owner 和 Dependent 之间的关系。
+
+这里有一个配置文件，表示一个具有 3 个 Pod 的 ReplicaSet：
+
+{% include code.html language="yaml" file="my-repset.yaml" ghlink="/docs/concepts/workloads/controllers/my-repset.yaml" %}
+
+
+
+如果创建该 ReplicaSet，然后查看 Pod 的 metadata 字段，能够看到 OwnerReferences 字段：
+
+```shell
+kubectl create -f https://k8s.io/docs/concepts/abstractions/controllers/my-repset.yaml
+kubectl get pods --output=yaml
+```
+
+
+
+输出显示了 Pod 的 Owner 是名为 my-repset 的 ReplicaSet：
+
+```shell
+apiVersion: v1
+kind: Pod
+metadata:
+  ...
+  ownerReferences:
+  - apiVersion: extensions/v1beta1
+    controller: true
+    blockOwnerDeletion: true
+    kind: ReplicaSet
+    name: my-repset
+    uid: d9607e19-f88f-11e6-a518-42010a800195
+  ...
+```
+
+
+## 控制垃圾收集器删除 Dependent
+
+当删除对象时，可以指定是否该对象的 Dependent 也自动删除掉。
+自动删除 Dependent 也称为 *级联删除*。
+Kubernetes 中有两种 *级联删除* 的模式：*background* 模式和 *foreground* 模式。
+
+如果删除对象时，不自动删除它的 Dependent，这些 Dependent 被称作是原对象的 *孤儿*。
+
+
+
+### Background 级联删除
+
+在 *background 级联删除* 模式下，Kubernetes 会立即删除 Owner 对象，然后垃圾收集器会在后台删除这些 Dependent。
+
+
+
+### Foreground 级联删除
+
+在 *foreground 级联删除* 模式下，根对象首先进入 “删除中” 状态。在 “删除中” 状态会有如下的情况：
+
+ * 对象仍然可以通过 REST API 可见。
+ * 会设置对象的 `deletionTimestamp` 字段。
+ * 对象的 `metadata.finalizers` 字段包含了值 "foregroundDeletion"。
+
+ 一旦对象被设置为 “删除中” 状态，垃圾收集器会删除对象的所有 Dependent。
+ 垃圾收集器在删除了所有 “Blocking” 状态的 Dependent（对象的 `ownerReference.blockOwnerDeletion=true`）之后，它会删除 Owner 对象。
+
+
+
+注意，在 “foreground 删除” 模式下，只有设置了 `ownerReference.blockOwnerDeletion` 值得 Dependent 才能阻止删除 Owner 对象。
+在 Kubernetes 1.7 版本中将增加许可控制器（Admission Controller），基于 Owner 对象上的删除权限来控制用户去设置 `blockOwnerDeletion` 的值为 true，所以未授权的 Dependent 不能够延迟 Owner 对象的删除。
+
+如果一个对象的 `ownerReferences` 字段被一个 Controller（例如 Deployment 或 ReplicaSet）设置，`blockOwnerDeletion` 会被自动设置，不需要手动修改这个字段。
+
+
+
+### 设置级联删除策略
+
+通过为 Owner 对象设置 `deleteOptions.propagationPolicy` 字段，可以控制级联删除策略。
+可能的取值包括：“orphan”、“Foreground” 或 “Background”。
+
+对很多 Controller 资源，包括 ReplicationController、ReplicaSet、StatefulSet、DaemonSet 和 Deployment，默认的垃圾收集策略是 `orphan`。
+因此，除非指定其它的垃圾收集策略，否则所有 Dependent 对象使用的都是 `orphan` 策略。
+
+下面是一个在后台删除 Dependent 对象的例子：
+
+```shell
+kubectl proxy --port=8080
+curl -X DELETE localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/my-repset \
+-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
+-H "Content-Type: application/json"
+```
+
+
+
+下面是一个在前台删除 Dependent 对象的例子：
+
+```shell
+kubectl proxy --port=8080
+curl -X DELETE localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/my-repset \
+-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
+-H "Content-Type: application/json"
+```
+
+
+下面是一个孤儿 Dependent 的例子：
+
+```shell
+kubectl proxy --port=8080
+curl -X DELETE localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/my-repset \
+-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
+-H "Content-Type: application/json"
+```
+
+
+
+kubectl 也支持级联删除。
+通过设置 `--cascade` 为 true，可以使用 kubectl 自动删除 Dependent 对象。
+设置 `--cascade` 为 false，会使 Dependent 对象成为孤儿 Dependent 对象。
+`--cascade` 的默认值是 true。
+
+下面是一个例子，使一个 ReplicaSet 的 Dependent 对象成为孤儿 Dependent：
+
+
+```shell
+kubectl delete replicaset my-repset --cascade=false
+```
+
+
+
+## 已知的问题
+* 1.7 版本，垃圾收集不支持 [自定义资源](/docs/concepts/api-extension/custom-resources/)，比如那些通过 CustomResourceDefinition 新增，或者通过 API server 聚集而成的资源对象。
+
+[其它已知的问题](https://github.com/kubernetes/kubernetes/issues/26120)
+
+{% endcapture %}
+
+
+{% capture whatsnext %}
+
+
+
+[设计文档 1](https://git.k8s.io/community/contributors/design-proposals/garbage-collection.md)
+[设计文档 2](https://git.k8s.io/community/contributors/design-proposals/synchronous-garbage-collection.md)
+
+{% endcapture %}
+
+
+{% include templates/concept.md %}

cn/docs/concepts/workloads/controllers/hpa-rs.yaml

@@ -0,0 +1,11 @@
+apiVersion: autoscaling/v1
+kind: HorizontalPodAutoscaler
+metadata:
+  name: frontend-scaler
+spec:
+  scaleTargetRef:
+    kind: ReplicaSet
+    name: frontend
+  minReplicas: 3
+  maxReplicas: 10
+  targetCPUUtilizationPercentage: 50

cn/docs/concepts/workloads/controllers/job.yaml

@@ -0,0 +1,15 @@
+apiVersion: batch/v1
+kind: Job
+metadata:
+  name: pi
+spec:
+  template:
+    metadata:
+      name: pi
+    spec:
+      containers:
+      - name: pi
+        image: perl
+        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
+      restartPolicy: Never
+

cn/docs/concepts/workloads/controllers/my-repset.yaml

@@ -0,0 +1,17 @@
+apiVersion: extensions/v1beta1
+kind: ReplicaSet
+metadata:
+  name: my-repset
+spec:
+  replicas: 3
+  selector:
+    matchLabels:
+      pod-is-for: garbage-collection-example
+  template:
+    metadata:
+      labels:
+        pod-is-for: garbage-collection-example
+    spec:
+      containers:
+      - name: nginx
+        image: nginx

cn/docs/concepts/workloads/controllers/nginx-deployment.yaml

@@ -0,0 +1,16 @@
+apiVersion: apps/v1beta1 # for versions before 1.6.0 use extensions/v1beta1
+kind: Deployment
+metadata:
+  name: nginx-deployment
+spec:
+  replicas: 3
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.7.9
+        ports:
+        - containerPort: 80

cn/docs/concepts/workloads/controllers/petset.yaml

@@ -0,0 +1,51 @@
+# A headless service to create DNS records
+apiVersion: v1
+kind: Service
+metadata:
+  name: nginx
+  labels:
+    app: nginx
+spec:
+  ports:
+  - port: 80
+    name: web
+  # *.nginx.default.svc.cluster.local
+  clusterIP: None
+  selector:
+    app: nginx
+---
+apiVersion: apps/v1alpha1
+kind: PetSet
+metadata:
+  name: web
+spec:
+  serviceName: "nginx"
+  replicas: 2
+  template:
+    metadata:
+      labels:
+        app: nginx
+      annotations:
+        pod.alpha.kubernetes.io/initialized: "true"
+    spec:
+      terminationGracePeriodSeconds: 0
+      containers:
+      - name: nginx
+        image: gcr.io/google_containers/nginx-slim:0.8
+        ports:
+        - containerPort: 80
+          name: web
+        volumeMounts:
+        - name: www
+          mountPath: /usr/share/nginx/html
+  volumeClaimTemplates:
+  - metadata:
+      name: www
+      annotations:
+        volume.alpha.kubernetes.io/storage-class: anything
+    spec:
+      accessModes: [ "ReadWriteOnce" ]
+      resources:
+        requests:
+          storage: 1Gi
+

cn/docs/concepts/workloads/controllers/replication.yaml

@@ -0,0 +1,19 @@
+apiVersion: v1
+kind: ReplicationController
+metadata:
+  name: nginx
+spec:
+  replicas: 3
+  selector:
+    app: nginx
+  template:
+    metadata:
+      name: nginx
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx
+        ports:
+        - containerPort: 80

cn/docs/concepts/workloads/controllers/statefulset.md

@@ -0,0 +1,231 @@
+---
+approvers:
+- enisoc
+- erictune
+- foxish
+- janetkuo
+- kow3ns
+- smarterclayton
+title: StatefulSets
+---
+
+{% capture overview %}
+**StatefulSets are a beta feature in 1.7. This feature replaces the
+PetSets feature from 1.4. Users of PetSets are referred to the 1.5
+[Upgrade Guide](/docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set/)
+for further information on how to upgrade existing PetSets to StatefulSets.**
+
+{% include templates/glossary/snippet.md term="statefulset" length="long" %}
+{% endcapture %}
+
+{% capture body %}
+
+## Using StatefulSets
+
+StatefulSets are valuable for applications that require one or more of the
+following.
+
+* Stable, unique network identifiers.
+* Stable, persistent storage.
+* Ordered, graceful deployment and scaling.
+* Ordered, graceful deletion and termination.
+* Ordered, automated rolling updates.
+
+In the above, stable is synonymous with persistence across Pod (re)scheduling.
+If an application doesn't require any stable identifiers or ordered deployment,
+deletion, or scaling, you should deploy your application with a controller that
+provides a set of stateless replicas. Controllers such as
+[Deployment](/docs/concepts/workloads/controllers/deployment/) or
+[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) may be better suited to your stateless needs.
+
+## Limitations
+
+* StatefulSet is a beta resource, not available in any Kubernetes release prior to 1.5.
+* As with all alpha/beta resources, you can disable StatefulSet through the `--runtime-config` option passed to the apiserver.
+* The storage for a given Pod must either be provisioned by a [PersistentVolume Provisioner](http://releases.k8s.io/{{page.githubbranch}}/examples/persistent-volume-provisioning/README.md) based on the requested `storage class`, or pre-provisioned by an admin.
+* Deleting and/or scaling a StatefulSet down will *not* delete the volumes associated with the StatefulSet. This is done to ensure data safety, which is generally more valuable than an automatic purge of all related StatefulSet resources.
+* StatefulSets currently require a [Headless Service](/docs/concepts/services-networking/service/#headless-services) to be responsible for the network identity of the Pods. You are responsible for creating this Service.
+
+## Components
+The example below demonstrates the components of a StatefulSet.
+
+* A Headless Service, named nginx, is used to control the network domain.
+* The StatefulSet, named web, has a Spec that indicates that 3 replicas of the nginx container will be launched in unique Pods.
+* The volumeClaimTemplates will provide stable storage using [PersistentVolumes](/docs/concepts/storage/volumes/) provisioned by a
+ PersistentVolume Provisioner.
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: nginx
+  labels:
+    app: nginx
+spec:
+  ports:
+  - port: 80
+    name: web
+  clusterIP: None
+  selector:
+    app: nginx
+---
+apiVersion: apps/v1beta1
+kind: StatefulSet
+metadata:
+  name: web
+spec:
+  serviceName: "nginx"
+  replicas: 3
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      terminationGracePeriodSeconds: 10
+      containers:
+      - name: nginx
+        image: gcr.io/google_containers/nginx-slim:0.8
+        ports:
+        - containerPort: 80
+          name: web
+        volumeMounts:
+        - name: www
+          mountPath: /usr/share/nginx/html
+  volumeClaimTemplates:
+  - metadata:
+      name: www
+    spec:
+      accessModes: [ "ReadWriteOnce" ]
+      storageClassName: my-storage-class
+      resources:
+        requests:
+          storage: 1Gi
+```
+
+## Pod Identity
+StatefulSet Pods have a unique identity that is comprised of an ordinal, a
+stable network identity, and stable storage. The identity sticks to the Pod,
+regardless of which node it's (re)scheduled on.
+
+### Ordinal Index
+
+For a StatefulSet with N replicas, each Pod in the StatefulSet will be
+assigned an integer ordinal, in the range [0,N), that is unique over the Set.
+
+### Stable Network ID
+
+Each Pod in a StatefulSet derives its hostname from the name of the StatefulSet
+and the ordinal of the Pod. The pattern for the constructed hostname
+is `$(statefulset name)-$(ordinal)`. The example above will create three Pods
+named `web-0,web-1,web-2`.
+A StatefulSet can use a [Headless Service](/docs/concepts/services-networking/service/#headless-services)
+to control the domain of its Pods. The domain managed by this Service takes the form:
+`$(service name).$(namespace).svc.cluster.local`, where "cluster.local"
+is the [cluster domain](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/README.md).
+As each Pod is created, it gets a matching DNS subdomain, taking the form:
+`$(podname).$(governing service domain)`, where the governing service is defined
+by the `serviceName` field on the StatefulSet.
+
+Here are some examples of choices for Cluster Domain, Service name,
+StatefulSet name, and how that affects the DNS names for the StatefulSet's Pods.
+
+Cluster Domain | Service (ns/name) | StatefulSet (ns/name)  | StatefulSet Domain  | Pod DNS | Pod Hostname |
+-------------- | ----------------- | ----------------- | -------------- | ------- | ------------ |
+ cluster.local | default/nginx     | default/web       | nginx.default.svc.cluster.local | web-{0..N-1}.nginx.default.svc.cluster.local | web-{0..N-1} |
+ cluster.local | foo/nginx         | foo/web           | nginx.foo.svc.cluster.local     | web-{0..N-1}.nginx.foo.svc.cluster.local     | web-{0..N-1} |
+ kube.local    | foo/nginx         | foo/web           | nginx.foo.svc.kube.local        | web-{0..N-1}.nginx.foo.svc.kube.local        | web-{0..N-1} |
+
+Note that Cluster Domain will be set to `cluster.local` unless
+[otherwise configured](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/dns/README.md).
+
+### Stable Storage
+
+Kubernetes creates one [PersistentVolume](/docs/concepts/storage/volumes/) for each
+VolumeClaimTemplate. In the nginx example above, each Pod will receive a single PersistentVolume
+with a StorageClass of `my-storage-class` and 1 Gib of provisioned storage. If no StorageClass
+is specified, then the default StorageClass will be used. When a Pod is (re)scheduled
+onto a node, its `volumeMounts` mount the PersistentVolumes associated with its
+PersistentVolume Claims. Note that, the PersistentVolumes associated with the
+Pods' PersistentVolume Claims are not deleted when the Pods, or StatefulSet are deleted.
+This must be done manually.
+
+## Deployment and Scaling Guarantees
+
+* For a StatefulSet with N replicas, when Pods are being deployed, they are created sequentially, in order from {0..N-1}.
+* When Pods are being deleted, they are terminated in reverse order, from {N-1..0}.
+* Before a scaling operation is applied to a Pod, all of its predecessors must be Running and Ready.
+* Before a Pod is terminated, all of its successors must be completely shutdown.
+
+The StatefulSet should not specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. This practice is unsafe and strongly discouraged. For further explanation, please refer to [force deleting StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/).
+
+When the nginx example above is created, three Pods will be deployed in the order
+web-0, web-1, web-2. web-1 will not be deployed before web-0 is
+[Running and Ready](/docs/user-guide/pod-states), and web-2 will not be deployed until
+web-1 is Running and Ready. If web-0 should fail, after web-1 is Running and Ready, but before
+web-2 is launched, web-2 will not be launched until web-0 is successfully relaunched and
+becomes Running and Ready.
+
+If a user were to scale the deployed example by patching the StatefulSet such that
+`replicas=1`, web-2 would be terminated first. web-1 would not be terminated until web-2
+is fully shutdown and deleted. If web-0 were to fail after web-2 has been terminated and
+is completely shutdown, but prior to web-1's termination, web-1 would not be terminated
+until web-0 is Running and Ready.
+
+### Pod Management Policies
+In Kubernetes 1.7 and later, StatefulSet allows you to relax its ordering guarantees while
+preserving its uniqueness and identity guarantees via its `.spec.podManagementPolicy` field.
+
+#### OrderedReady Pod Management
+
+`OrderedReady` pod management is the default for StatefulSets. It implements the behavior
+described [above](#deployment-and-scaling-guarantees).
+
+#### Parallel Pod Management
+
+`Parallel` pod management tells the StatefulSet controller to launch or
+terminate all Pods in parallel, and to not wait for Pods to become Running
+and Ready or completely terminated prior to launching or terminating another
+Pod.
+
+## Update Strategies
+
+In Kubernetes 1.7 and later, StatefulSet's `.spec.updateStrategy` field allows you to configure
+and disable automated rolling updates for containers, labels, resource request/limits, and
+annotations for the Pods in a StatefulSet.
+
+### On Delete
+
+The `OnDelete` update strategy implements the legacy (1.6 and prior) behavior. It is the default
+strategy when `spec.updateStrategy` is left unspecified. When a StatefulSet's
+`.spec.updateStrategy.type` is set to `OnDelete`, the StatefulSet controller will not automatically
+update the Pods in a StatefulSet. Users must manually delete Pods to cause the controller to
+create new Pods that reflect modifications made to a StatefulSet's `.spec.template`.
+
+### Rolling Updates
+
+The `RollingUpdate` update strategy implements automated, rolling update for the Pods in a
+StatefulSet. When a StatefulSet's `.spec.updateStrategy.type` is set to `RollingUpdate`, the
+StatefulSet controller will delete and recreate each Pod in the StatefulSet. It will proceed
+in the same order as Pod termination (from the largest ordinal to the smallest), updating
+each Pod one at a time. It will wait until an updated Pod is Running and Ready prior to
+updating its predecessor.
+
+#### Partitions
+
+The `RollingUpdate` update strategy can be partitioned, by specifying a
+`.spec.updateStrategy.rollingUpdate.partition`. If a partition is specified, all Pods with an
+ordinal that is greater than or equal to the partition will be updated when the StatefulSet's
+`.spec.template` is updated. All Pods with an ordinal that is less than the partition will not
+be updated, and, even if they are deleted, they will be recreated at the previous version. If a
+StatefulSet's `.spec.updateStrategy.rollingUpdate.partition` is greater than its `.spec.replicas`,
+updates to its `.spec.template` will not be propagated to its Pods.
+In most cases you will not need to use a partition, but they are useful if you want to stage an
+update, roll out a canary, or perform a phased roll out.
+
+{% endcapture %}
+{% capture whatsnext %}
+
+* Follow an example of [deploying a stateful application](/docs/tutorials/stateful-application/basic-stateful-set).
+
+{% endcapture %}
+{% include templates/concept.md %}

cn/docs/concepts/workloads/pods/init-containers.md

@@ -0,0 +1,330 @@
+---
+assignees:
+- erictune
+title: Init 容器
+redirect_from:
+- "/docs/concepts/abstractions/init-containers/"
+- "/docs/concepts/abstractions/init-containers.html"
+- "/docs/user-guide/pods/init-container/"
+- "/docs/user-guide/pods/init-container.html"
+---
+
+{% capture overview %}
+
+本页提供了 Init 容器的概览，它是一种专用的容器，在应用容器启动之前运行，并包括一些应用镜像中不存在的实用工具和安装脚本。
+{% endcapture %}
+
+{:toc}
+
+
+这个特性在 1.6 版本已经退出 beta 版本。Init 容器可以在 PodSpec 中同应用的 `containers` 数组一起来指定。
+beta 注解的值将仍然需要保留，并覆盖 PodSpec 字段值。
+
+{% capture body %}
+
+
+## 理解 Init 容器
+
+
+
+[Pod](/docs/concepts/abstractions/pod/) 能够具有多个容器，应用运行在容器里面，但是它也可能有一个或多个先于应用容器启动的 Init 容器。
+
+Init 容器与普通的容器非常像，除了如下两点：
+
+
+
+* 它们总是运行到完成。
+* 每个都必须在下一个启动之前成功完成。
+
+
+
+如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的 `restartPolicy` 值为 Never，它不会重新启动。
+
+指定容器为 Init 容器，需要在 PodSpec 中添加 `initContainers` 字段，以 [v1.Container](/docs/api-reference/v1.6/#container-v1-core) 类型对象的 JSON 数组的形式，还有 app 的 `containers` 数组。
+Init 容器的状态在 `status.initContainerStatuses` 字段中以容器状态数组的格式返回（类似 `status.containerStatuses` 字段）。
+
+
+
+### 与普通容器的不同之处
+
+Init 容器支持应用容器的全部字段和特性，包括资源限制、数据卷和安全设置。
+然而，Init 容器对资源请求和限制的处理稍有不同，在下面 [资源](#resources) 处有说明。
+而且 Init 容器不支持 Readiness Probe，因为它们必须在 Pod 就绪之前运行完成。
+
+如果为一个 Pod 指定了多个 Init 容器，那些容器会按顺序一次运行一个。
+每个 Init 容器必须运行成功，下一个才能够运行。
+当所有的 Init 容器运行完成时，Kubernetes 初始化 Pod 并像平常一样运行应用容器。
+
+
+
+## Init 容器能做什么？
+
+因为 Init 容器具有与应用容器分离的单独镜像，它们的启动相关代码具有如下优势：
+
+* 它们可以包含并运行实用工具，处于安全考虑，是不建议在应用容器镜像中包含这些实用工具的。
+* 它们可以包含使用工具和定制化代码来安装，但是不能出现在应用镜像中。例如，创建镜像没必要 `FROM` 另一个镜像，只需要在安装过程中使用类似 `sed`、 `awk`、 `python` 或 `dig` 这样的工具。
+* 应用镜像可以分离出创建和部署的角色，而没有必要联合它们构建一个单独的镜像。
+* 它们使用 Linux Namespace，所以对应用容器具有不同的文件系统视图。因此，它们能够具有访问 Secret 的权限，而应用容器不能够访问。
+* 它们在应用容器启动之前运行完成，然而应用容器并行运行，所以 Init 容器提供了一种简单的方式来阻塞或延迟应用容器的启动，直到满足了一组先决条件。
+
+
+
+### 示例
+
+下面是一些如何使用 Init 容器的想法：
+
+* 等待一个 Service 完成创建，通过类似如下 shell 命令：
+
+        for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; exit 1
+
+* 注册这个 Pod 到远程服务器，通过在命令中调用 API，类似如下：
+
+        curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'
+
+* 在启动应用容器之前等一段时间，使用类似 `sleep 60` 的命令。
+* 克隆 Git 仓库到数据卷。
+* 将配置值放到配置文件中，运行模板工具为主应用容器动态地生成配置文件。例如，在配置文件中存放 POD_IP 值，并使用 Jinja 生成主应用配置文件。
+
+更多详细用法示例，可以在 [StatefulSet 文档](/docs/concepts/abstractions/controllers/statefulsets/) 和 [生产环境 Pod 指南](/docs/user-guide/production-pods.md#handling-initialization)  中找到。
+
+
+
+### 使用 Init 容器
+
+下面是 Kubernetes 1.5 版本 yaml 文件，展示了一个具有 2 个 Init 容器的简单 Pod。
+第一个等待  `myservice` 启动，第二个等待 `mydb` 启动。
+一旦这两个 Service 都启动完成，Pod 将开始启动。
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: myapp-pod
+  labels:
+    app: myapp
+  annotations:
+    pod.beta.kubernetes.io/init-containers: '[
+        {
+            "name": "init-myservice",
+            "image": "busybox",
+            "command": ["sh", "-c", "until nslookup myservice; do echo waiting for myservice; sleep 2; done;"]
+        },
+        {
+            "name": "init-mydb",
+            "image": "busybox",
+            "command": ["sh", "-c", "until nslookup mydb; do echo waiting for mydb; sleep 2; done;"]
+        }
+    ]'
+spec:
+  containers:
+  - name: myapp-container
+    image: busybox
+    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
+```
+
+
+
+这是 Kubernetes 1.6 版本的新语法，尽管老的 annotation 语法仍然可以使用。我们已经把 Init 容器的声明移到 `spec` 中：
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: myapp-pod
+  labels:
+    app: myapp
+spec:
+  containers:
+  - name: myapp-container
+    image: busybox
+    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
+  initContainers:
+  - name: init-myservice
+    image: busybox
+    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
+  - name: init-mydb
+    image: busybox
+    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
+```
+
+
+
+1.5 版本的语法在 1.6 版本仍然可以使用，但是我们推荐使用 1.6 版本的新语法。
+在 Kubernetes 1.6 版本中，Init 容器在 API 中新建了一个字段。
+虽然期望使用 beta 版本的 annotation，但在未来发行版将会被废弃掉。
+
+下面的 yaml 文件展示了 `mydb` 和 `myservice` 两个 Service：
+
+```
+kind: Service
+apiVersion: v1
+metadata:
+  name: myservice
+spec:
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9376
+---
+kind: Service
+apiVersion: v1
+metadata:
+  name: mydb
+spec:
+  ports:
+    - protocol: TCP
+      port: 80
+      targetPort: 9377
+```
+
+
+
+这个 Pod 可以使用下面的命令进行启动和调试：
+
+```
+$ kubectl create -f myapp.yaml
+pod "myapp-pod" created
+$ kubectl get -f myapp.yaml
+NAME        READY     STATUS     RESTARTS   AGE
+myapp-pod   0/1       Init:0/2   0          6m
+$ kubectl describe -f myapp.yaml 
+Name:          myapp-pod
+Namespace:     default
+[...]
+Labels:        app=myapp
+Status:        Pending
+[...]
+Init Containers:
+  init-myservice:
+[...]
+    State:         Running
+[...]
+  init-mydb:
+[...]
+    State:         Waiting
+      Reason:      PodInitializing
+    Ready:         False
+[...]
+Containers:
+  myapp-container:
+[...]
+    State:         Waiting
+      Reason:      PodInitializing
+    Ready:         False
+[...]
+Events:
+  FirstSeen    LastSeen    Count    From                      SubObjectPath                           Type          Reason        Message
+  ---------    --------    -----    ----                      -------------                           --------      ------        -------
+  16s          16s         1        {default-scheduler }                                              Normal        Scheduled     Successfully assigned myapp-pod to 172.17.4.201
+  16s          16s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Pulling       pulling image "busybox"
+  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Pulled        Successfully pulled image "busybox"
+  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Created       Created container with docker id 5ced34a04634; Security:[seccomp=unconfined]
+  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Started       Started container with docker id 5ced34a04634
+$ kubectl logs myapp-pod -c init-myservice # Inspect the first init container
+$ kubectl logs myapp-pod -c init-mydb      # Inspect the second init container
+```
+
+
+
+一旦我们启动了 `mydb` 和 `myservice` 这两个 Service，我们能够看到 Init 容器完成，并且 `myapp-pod` 被创建：
+
+```
+$ kubectl create -f services.yaml
+service "myservice" created
+service "mydb" created
+$ kubectl get -f myapp.yaml
+NAME        READY     STATUS    RESTARTS   AGE
+myapp-pod   1/1       Running   0          9m
+```
+
+
+
+这个例子非常简单，但是应该能够为创建自己的 Init 容器提供一些启发。
+
+
+
+## 具体行为
+
+在 Pod 启动过程中，Init 容器会按顺序在网络和数据卷初始化之后启动。
+每个容器必须在下一个容器启动之前成功退出。
+如果由于运行时或失败退出，导致容器启动失败，它会根据 Pod 的 `restartPolicy` 指定的策略进行重试。
+然而，如果 Pod 的 `restartPolicy` 设置为 Always，Init 容器失败时会使用 `RestartPolicy` 策略。
+
+
+
+在所有的 Init 容器没有成功之前，Pod 将不会变成 `Ready` 状态。
+Init 容器的端口将不会在 Service 中进行聚集。
+正在初始化中的 Pod 处于 `Pending` 状态，但应该会将条件 `Initializing` 设置为 true。
+
+如果 Pod [重启](#pod-restart-reasons)，所有 Init 容器必须重新执行。
+
+对 Init 容器 spec 的修改，被限制在容器 image 字段中。
+更改 Init 容器的 image 字段，等价于重启该 Pod。
+
+
+
+因为 Init 容器可能会被重启、重试或者重新执行，所以 Init 容器的代码应该是幂等的。
+特别地，被写到 `EmptyDirs` 中文件的代码，应该对输出文件可能已经存在做好准备。
+
+Init 容器具有应用容器的所有字段。
+然而 Kubernetes 禁止使用 `readinessProbe`，因为 Init 容器不能够定义不同于完成（completion）的就绪（readiness）。 
+这会在验证过程中强制执行。
+
+
+
+在 Pod 上使用 `activeDeadlineSeconds`，在容器上使用 `livenessProbe`，这样能够避免 Init 容器一直失败。
+这就为 Init 容器活跃设置了一个期限。
+
+在 Pod 中的每个 app 和 Init 容器的名称必须唯一；与任何其它容器共享同一个名称，会在验证时抛出错误。
+
+
+
+### 资源
+
+为 Init 容器指定顺序和执行逻辑，下面对资源使用的规则将被应用：
+
+
+
+* 在所有 Init 容器上定义的，任何特殊资源请求或限制的最大值，是 *有效初始请求/限制*
+* Pod 对资源的 *有效请求/限制* 要高于：
+  * 所有应用容器对某个资源的请求/限制之和
+  * 对某个资源的有效初始请求/限制
+* 基于有效请求/限制完成调度，这意味着 Init 容器能够为初始化预留资源，这些资源在 Pod 生命周期过程中并没有被使用。
+* Pod 的 *有效 QoS 层*，是 Init 容器和应用容器相同的 QoS 层。
+
+
+
+基于有效 Pod 请求和限制来应用配额和限制。
+Pod 级别的 cgroups 是基于有效 Pod 请求和限制，和调度器相同。
+
+
+
+### Pod 重启的原因
+
+Pod 能够重启，会导致 Init 容器重新执行，主要有如下几个原因：
+
+* 用户更新 PodSpec 导致 Init 容器镜像发生改变。应用容器镜像的变更只会重启应用容器。
+* Pod 基础设施容器被重启。这不多见，但某些具有 root 权限可访问 Node 的人可能会这样做。
+* 当 `restartPolicy` 设置为 Always，Pod 中所有容器会终止，强制重启，由于垃圾收集导致 Init 容器完成的记录丢失。
+
+
+
+## 支持与兼容性
+
+Apiserver 版本为 1.6 或更高版本的集群，通过使用 `spec.initContainers` 字段来支持 Init 容器。
+之前的版本可以使用 alpha 和 beta 注解支持 Init 容器。
+`spec.initContainers` 字段也被加入到 alpha 和 beta 注解中，所以 Kubernetes 1.3.0 版本或更高版本可以执行 Init 容器，并且 1.6 版本的 apiserver 能够安全的回退到 1.5.x 版本，而不会使存在的已创建 Pod 失去 Init 容器的功能。
+
+{% endcapture %}
+
+
+{% capture whatsnext %}
+
+
+
+* [创建具有 Init 容器的 Pod](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)
+
+{% endcapture %}
+
+
+{% include templates/concept.md %}

cn/docs/getting-started-guides/centos/centos_manual_config.md

@@ -1,5 +1,5 @@
 ---
-assignees:
+approvers:
 - thockin
 title: CentOS
 ---

cn/docs/getting-started-guides/coreos/bare_metal_offline.md

@@ -1,5 +1,5 @@
 ---
-assignees:
+approvers:
 - erictune
 - thockin
 title: Offline
@@ -705,4 +705,4 @@ IaaS Provider        | Config. Mgmt | OS     | Networking  | Docs
 -------------------- | ------------ | ------ | ----------  | ---------------------------------------------     | ---------| ----------------------------
 Bare-metal (Offline) | CoreOS       | CoreOS | flannel     | [docs](/docs/getting-started-guides/coreos/bare_metal_offline)              |          | Community ([@jeffbean](https://github.com/jeffbean))
 
-有关所有解决方案的支持级别信息，请参阅[解决方案列表](/docs/getting-started-guides/#table-of-solutions)。
+有关所有解决方案的支持级别信息，请参阅[解决方案列表](/docs/getting-started-guides/#table-of-solutions)。

cn/docs/tasks/access-application-cluster/access-cluster.md

@@ -0,0 +1,318 @@
+---
+title: Accessing Clusters
+---
+
+* TOC
+{:toc}
+
+## Accessing the cluster API
+
+### Accessing for the first time with kubectl
+
+When accessing the Kubernetes API for the first time, we suggest using the
+Kubernetes CLI, `kubectl`.
+
+To access a cluster, you need to know the location of the cluster and have credentials
+to access it.  Typically, this is automatically set-up when you work through
+a [Getting started guide](/docs/getting-started-guides/),
+or someone else setup the cluster and provided you with credentials and a location.
+
+Check the location and credentials that kubectl knows about with this command:
+
+```shell
+$ kubectl config view
+```
+
+Many of the [examples](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/) provide an introduction to using
+kubectl and complete documentation is found in the [kubectl manual](/docs/user-guide/kubectl/index).
+
+### Directly accessing the REST API
+
+Kubectl handles locating and authenticating to the apiserver.
+If you want to directly access the REST API with an http client like
+curl or wget, or a browser, there are several ways to locate and authenticate:
+
+  - Run kubectl in proxy mode.
+    - Recommended approach.
+    - Uses stored apiserver location.
+    - Verifies identity of apiserver using self-signed cert.  No MITM possible.
+    - Authenticates to apiserver.
+    - In future, may do intelligent client-side load-balancing and failover.
+  - Provide the location and credentials directly to the http client.
+    - Alternate approach.
+    - Works with some types of client code that are confused by using a proxy.
+    - Need to import a root cert into your browser to protect against MITM.
+
+#### Using kubectl proxy
+
+The following command runs kubectl in a mode where it acts as a reverse proxy.  It handles
+locating the apiserver and authenticating.
+Run it like this:
+
+```shell
+$ kubectl proxy --port=8080 &
+```
+
+See [kubectl proxy](/docs/user-guide/kubectl/v1.6/#proxy) for more details.
+
+Then you can explore the API with curl, wget, or a browser, like so:
+
+```shell
+$ curl http://localhost:8080/api/
+{
+  "versions": [
+    "v1"
+  ]
+}
+```
+
+#### Without kubectl proxy (before v1.3.x)
+
+It is possible to avoid using kubectl proxy by passing an authentication token
+directly to the apiserver, like this:
+
+```shell
+$ APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ")
+$ TOKEN=$(kubectl config view | grep token | cut -f 2 -d ":" | tr -d " ")
+$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
+{
+  "versions": [
+    "v1"
+  ]
+}
+```
+
+#### Without kubectl proxy (post v1.3.x)
+
+In Kubernetes version 1.3 or later, `kubectl config view` no longer displays the token. Use `kubectl describe secret...` to get the token for the default service account, like this:
+
+``` shell
+$ APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ")
+$ TOKEN=$(kubectl describe secret $(kubectl get secrets | grep default | cut -f1 -d ' ') | grep -E '^token' | cut -f2 -d':' | tr -d '\t')
+$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
+{
+  "kind": "APIVersions",
+  "versions": [
+    "v1"
+  ],
+  "serverAddressByClientCIDRs": [
+    {
+      "clientCIDR": "0.0.0.0/0",
+      "serverAddress": "10.0.1.149:443"
+    }
+  ]
+}
+```
+
+The above examples use the `--insecure` flag.  This leaves it subject to MITM
+attacks.  When kubectl accesses the cluster it uses a stored root certificate
+and client certificates to access the server.  (These are installed in the
+`~/.kube` directory).  Since cluster certificates are typically self-signed, it
+may take special configuration to get your http client to use root
+certificate.
+
+On some clusters, the apiserver does not require authentication; it may serve
+on localhost, or be protected by a firewall.  There is not a standard
+for this.  [Configuring Access to the API](/docs/admin/accessing-the-api)
+describes how a cluster admin can configure this.  Such approaches may conflict
+with future high-availability support.
+
+### Programmatic access to the API
+
+Kubernetes officially supports [Go](#go-client) and [Python](#python-client)
+client libraries.
+
+#### Go client
+
+* To get the library, run the following command: `go get k8s.io/client-go/<version number>/kubernetes`. See [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go) to see which versions are supported.
+* Write an application atop of the client-go clients. Note that client-go defines its own API objects, so if needed, please import API definitions from client-go rather than from the main repository, e.g., `import "k8s.io/client-go/1.4/pkg/api/v1"` is correct.
+
+The Go client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
+as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go).
+
+If the application is deployed as a Pod in the cluster, please refer to the [next section](#accessing-the-api-from-a-pod).
+
+#### Python client
+
+To use [Python client](https://github.com/kubernetes-incubator/client-python), run the following command: `pip install kubernetes`. See [Python Client Library page](https://github.com/kubernetes-incubator/client-python) for more installation options.
+
+The Python client can use the same [kubeconfig file](/docs/user-guide/kubeconfig-file)
+as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://github.com/kubernetes-incubator/client-python/tree/master/examples/example1.py).
+
+#### Other languages
+
+There are [client libraries](/docs/reference/client-libraries/) for accessing the API from other languages.
+See documentation for other libraries for how they authenticate.
+
+### Accessing the API from a Pod
+
+When accessing the API from a pod, locating and authenticating
+to the apiserver are somewhat different.
+
+The recommended way to locate the apiserver within the pod is with
+the `kubernetes` DNS name, which resolves to a Service IP which in turn
+will be routed to an apiserver.
+
+The recommended way to authenticate to the apiserver is with a
+[service account](/docs/tasks/configure-pod-container/configure-service-account/) credential.  By kube-system, a pod
+is associated with a service account, and a credential (token) for that
+service account is placed into the filesystem tree of each container in that pod,
+at `/var/run/secrets/kubernetes.io/serviceaccount/token`.
+
+If available, a certificate bundle is placed into the filesystem tree of each
+container at `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`, and should be
+used to verify the serving certificate of the apiserver.
+
+Finally, the default namespace to be used for namespaced API operations is placed in a file
+at `/var/run/secrets/kubernetes.io/serviceaccount/namespace` in each container.
+
+From within a pod the recommended ways to connect to API are:
+
+  - run a kubectl proxy as one of the containers in the pod, or as a background
+    process within a container.  This proxies the
+    Kubernetes API to the localhost interface of the pod, so that other processes
+    in any container of the pod can access it.  See this [example of using kubectl proxy
+    in a pod](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/kubectl-container/).
+  - use the Go client library, and create a client using the `rest.InClusterConfig()` and `kubernetes.NewForConfig()` functions.
+    They handle locating and authenticating to the apiserver. [example](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)
+
+In each case, the credentials of the pod are used to communicate securely with the apiserver.
+
+
+## Accessing services running on the cluster
+
+The previous section was about connecting the Kubernetes API server.  This section is about
+connecting to other services running on Kubernetes cluster.  In Kubernetes, the
+[nodes](/docs/admin/node), [pods](/docs/user-guide/pods) and [services](/docs/user-guide/services) all have
+their own IPs.  In many cases, the node IPs, pod IPs, and some service IPs on a cluster will not be
+routable, so they will not be reachable from a machine outside the cluster,
+such as your desktop machine.
+
+### Ways to connect
+
+You have several options for connecting to nodes, pods and services from outside the cluster:
+
+  - Access services through public IPs.
+    - Use a service with type `NodePort` or `LoadBalancer` to make the service reachable outside
+      the cluster.  See the [services](/docs/user-guide/services) and
+      [kubectl expose](/docs/user-guide/kubectl/v1.6/#expose) documentation.
+    - Depending on your cluster environment, this may just expose the service to your corporate network,
+      or it may expose it to the internet.  Think about whether the service being exposed is secure.
+      Does it do its own authentication?
+    - Place pods behind services.  To access one specific pod from a set of replicas, such as for debugging,
+      place a unique label on the pod and create a new service which selects this label.
+    - In most cases, it should not be necessary for application developer to directly access
+      nodes via their nodeIPs.
+  - Access services, nodes, or pods using the Proxy Verb.
+    - Does apiserver authentication and authorization prior to accessing the remote service.
+      Use this if the services are not secure enough to expose to the internet, or to gain
+      access to ports on the node IP, or for debugging.
+    - Proxies may cause problems for some web applications.
+    - Only works for HTTP/HTTPS.
+    - Described [here](#manually-constructing-apiserver-proxy-urls).
+  - Access from a node or pod in the cluster.
+    - Run a pod, and then connect to a shell in it using [kubectl exec](/docs/user-guide/kubectl/v1.6/#exec).
+      Connect to other nodes, pods, and services from that shell.
+    - Some clusters may allow you to ssh to a node in the cluster.  From there you may be able to
+      access cluster services.  This is a non-standard method, and will work on some clusters but
+      not others.  Browsers and other tools may or may not be installed.  Cluster DNS may not work.
+
+### Discovering builtin services
+
+Typically, there are several services which are started on a cluster by kube-system. Get a list of these
+with the `kubectl cluster-info` command:
+
+```shell
+$ kubectl cluster-info
+
+  Kubernetes master is running at https://104.197.5.247
+  elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
+  kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy
+  kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy
+  grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
+  heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
+```
+
+This shows the proxy-verb URL for accessing each service.
+For example, this cluster has cluster-level logging enabled (using Elasticsearch), which can be reached
+at `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` if suitable credentials are passed.  Logging can also be reached through a kubectl proxy, for example at:
+`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`.
+(See [above](#accessing-the-cluster-api) for how to pass credentials or use kubectl proxy.)
+
+#### Manually constructing apiserver proxy URLs
+
+As mentioned above, you use the `kubectl cluster-info` command to retrieve the service's proxy URL. To create proxy URLs that include service endpoints, suffixes, and parameters, you simply append to the service's proxy URL:
+`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy`
+
+If you haven't specified a name for your port, you don't have to specify *port_name* in the URL.
+
+##### Examples
+
+ * To access the Elasticsearch service endpoint `_search?q=user:kimchy`, you would use:   `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`
+ * To access the Elasticsearch cluster health information `_cluster/health?pretty=true`, you would use:   `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`
+
+```json
+  {
+    "cluster_name" : "kubernetes_logging",
+    "status" : "yellow",
+    "timed_out" : false,
+    "number_of_nodes" : 1,
+    "number_of_data_nodes" : 1,
+    "active_primary_shards" : 5,
+    "active_shards" : 5,
+    "relocating_shards" : 0,
+    "initializing_shards" : 0,
+    "unassigned_shards" : 5
+  }
+```
+
+#### Using web browsers to access services running on the cluster
+
+You may be able to put an apiserver proxy url into the address bar of a browser. However:
+
+  - Web browsers cannot usually pass tokens, so you may need to use basic (password) auth.  Apiserver can be configured to accept basic auth,
+    but your cluster may not be configured to accept basic auth.
+  - Some web apps may not work, particularly those with client side javascript that construct urls in a
+    way that is unaware of the proxy path prefix.
+
+## Requesting redirects
+
+The redirect capabilities have been deprecated and removed.  Please use a proxy (see below) instead.
+
+## So Many Proxies
+
+There are several different proxies you may encounter when using Kubernetes:
+
+  1. The [kubectl proxy](#directly-accessing-the-rest-api):
+    - runs on a user's desktop or in a pod
+    - proxies from a localhost address to the Kubernetes apiserver
+    - client to proxy uses HTTP
+    - proxy to apiserver uses HTTPS
+    - locates apiserver
+    - adds authentication headers
+  1. The [apiserver proxy](#discovering-builtin-services):
+    - is a bastion built into the apiserver
+    - connects a user outside of the cluster to cluster IPs which otherwise might not be reachable
+    - runs in the apiserver processes
+    - client to proxy uses HTTPS (or http if apiserver so configured)
+    - proxy to target may use HTTP or HTTPS as chosen by proxy using available information
+    - can be used to reach a Node, Pod, or Service
+    - does load balancing when used to reach a Service
+  1. The [kube proxy](/docs/user-guide/services/#ips-and-vips):
+    - runs on each node
+    - proxies UDP and TCP
+    - does not understand HTTP
+    - provides load balancing
+    - is just used to reach services
+  1. A Proxy/Load-balancer in front of apiserver(s):
+    - existence and implementation varies from cluster to cluster (e.g. nginx)
+    - sits between all clients and one or more apiservers
+    - acts as load balancer if there are several apiservers.
+  1. Cloud Load Balancers on external services:
+    - are provided by some cloud providers (e.g. AWS ELB, Google Cloud Load Balancer)
+    - are created automatically when the Kubernetes service has type `LoadBalancer`
+    - use UDP/TCP only
+    - implementation varies by cloud provider.
+
+Kubernetes users will typically not need to worry about anything other than the first two types.  The cluster admin
+will typically ensure that the latter types are setup correctly.

cn/docs/tasks/access-application-cluster/frontend.yaml

@@ -0,0 +1,34 @@
+kind: Service
+apiVersion: v1
+metadata:
+  name: frontend
+spec:
+  selector:
+    app: hello
+    tier: frontend
+  ports:
+  - protocol: "TCP"
+    port: 80
+    targetPort: 80
+  type: LoadBalancer
+---
+apiVersion: apps/v1beta1
+kind: Deployment
+metadata:
+  name: frontend
+spec:
+  replicas: 1
+  template:
+    metadata:
+      labels:
+        app: hello
+        tier: frontend
+        track: stable
+    spec:
+      containers:
+      - name: nginx
+        image: "gcr.io/google-samples/hello-frontend:1.0"
+        lifecycle:
+          preStop:
+            exec:
+              command: ["/usr/sbin/nginx","-s","quit"]

cn/docs/tasks/access-application-cluster/hello-service.yaml

@@ -0,0 +1,12 @@
+kind: Service
+apiVersion: v1
+metadata:
+  name: hello
+spec:
+  selector:
+    app: hello
+    tier: backend
+  ports:
+  - protocol: TCP
+    port: 80
+    targetPort: http

cn/docs/tasks/access-application-cluster/hello.yaml

@@ -0,0 +1,19 @@
+apiVersion: apps/v1beta1
+kind: Deployment
+metadata:
+  name: hello
+spec:
+  replicas: 7
+  template:
+    metadata:
+      labels:
+        app: hello
+        tier: backend
+        track: stable
+    spec:
+      containers:
+        - name: hello
+          image: "gcr.io/google-samples/hello-go-gke:1.0"
+          ports:
+            - name: http
+              containerPort: 80

cn/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md

@@ -0,0 +1,94 @@
+---
+title: Use Port Forwarding to Access Applications in a Cluster
+---
+
+{% capture overview %}
+
+This page shows how to use `kubectl port-forward` to connect to a Redis
+server running in a Kubernetes cluster. This type of connection can be useful
+for database debugging.
+
+{% endcapture %}
+
+
+{% capture prerequisites %}
+
+* {% include task-tutorial-prereqs.md %}
+
+* Install [redis-cli](http://redis.io/topics/rediscli).
+
+{% endcapture %}
+
+
+{% capture steps %}
+
+## Creating a pod to run a Redis server
+
+1. Create a pod:
+
+       kubectl create -f https://k8s.io/docs/tasks/access-application-cluster/redis-master.yaml
+
+    The output of a successful command verifies that the pod was created:
+
+        pod "redis-master" created
+
+1. Check to see whether the pod is running and ready:
+
+       kubectl get pods
+
+    When the pod is ready, the output displays a STATUS of Running:
+
+        NAME           READY     STATUS    RESTARTS   AGE
+        redis-master   2/2       Running   0          41s
+
+1. Verify that the Redis server is running in the pod and listening on port 6379:
+
+        {% raw %}
+       kubectl get pods redis-master --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
+        {% endraw %}
+
+    The output displays the port:
+
+        6379
+
+## Forward a local port to a port on the pod
+
+1. Forward port 6379 on the local workstation to port 6379 of redis-master pod:
+
+       kubectl port-forward redis-master 6379:6379
+
+    The output is similar to this:
+
+        I0710 14:43:38.274550    3655 portforward.go:225] Forwarding from 127.0.0.1:6379 -> 6379
+        I0710 14:43:38.274797    3655 portforward.go:225] Forwarding from [::1]:6379 -> 6379
+
+1. Start the Redis command line interface:
+
+       redis-cli
+
+1. At the Redis command line prompt, enter the `ping` command:
+
+       127.0.0.1:6379>ping
+
+    A successful ping request returns PONG.
+
+{% endcapture %}
+
+
+{% capture discussion %}
+
+## Discussion
+
+Connections made to local port 6379 are forwarded to port 6379 of the pod that
+is running the Redis server. With this connection in place you can use your
+local workstation to debug the database that is running in the pod.
+
+{% endcapture %}
+
+
+{% capture whatsnext %}
+Learn more about [kubectl port-forward](/docs/user-guide/kubectl/v1.6/#port-forward).
+{% endcapture %}
+
+
+{% include templates/task.md %}