Update config.toml(release-1.17) for 1.17 (#18031 )

Update for v1.17 (#18034 )
Reference Documentation for kubectl Commands for 1.17 (#18017 )
2019-12-09 16:01:31 -08:00 · 2019-12-09 15:14:40 -08:00 · 2019-12-09 15:12:40 -08:00 · 2019-12-09 12:58:03 -08:00 · 2019-12-09 12:44:04 -08:00 · 2019-12-06 17:48:50 -05:00
4279 changed files with 654658 additions and 101319 deletions
@@ -0,0 +1 @@
+**
@@ -0,0 +1,17 @@
+[*]
+end_of_line = lf
+insert_final_newline = false
+charset = utf-8
+max_line_length = 80
+trim_trailing_whitespace = true
+
+[*.{html,js,json,sass,md,mmark,toml,yaml}]
+indent_style = space
+indent_size = 2
+
+[*.{sh}]
+indent_style = space
+indent_size = 4
+
+[Makefile]
+indent_style = tab
@@ -1,22 +0,0 @@
-<!-- Thanks for filing an issue! Before submitting, please fill in the following information. -->
-
-<!--Required Information-->
-
-**This is a...** 
-<!-- choose one by changing [ ] to [x] -->
- [ ] Feature Request
- [ ] Bug Report
-
-**Problem:**
-
-
-**Proposed Solution:**
-
-
-**Page to Update:**
-https://kubernetes.io/...
-
-<!--Optional Information (remove the comment tags around information you would like to include)-->
-<!--Kubernetes Version:-->
-
-<!--Additional Information:-->
@@ -0,0 +1,23 @@
+---
+name: Bug Report
+about: Report a bug encountered with Kubernetes Website
+labels:
+- kind/bug
+---
+**This is a Bug Report**
+
+<!-- Thanks for filing an issue! Before submitting, please fill in the following information. -->
+<!-- See https://kubernetes.io/docs/contribute/start/ for guidance on writing an actionable issue description. -->
+
+<!--Required Information-->
+**Problem:**
+
+**Proposed Solution:**
+
+**Page to Update:**
+https://kubernetes.io/...
+
+<!--Optional Information (remove the comment tags around information you would like to include)-->
+<!--Kubernetes Version:-->
+
+<!--Additional Information:-->
@@ -0,0 +1,18 @@
+---
+name: Feature Request
+about: Suggest a/an feature/enhancement to the Kubernetes Website project
+labels:
+- kind/feature
+---
+**This is a Feature Request**
+
+<!-- Please only use this template for submitting feature/enhancement requests -->
+<!-- See https://kubernetes.io/docs/contribute/start/ for guidance on writing an actionable issue description. -->
+
+**What would you like to be added**
+<!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. -->
+
+**Why is this needed**
+
+**Comments**
+<!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). -->
@@ -0,0 +1,19 @@
+---
+name: Support Request
+about: Support request or question relating to Kubernetes Website project
+labels:
+- triage/support
+---
+**This is Support**
+
+<!--
+STOP -- PLEASE READ!
+
+GitHub is not the right place for support requests.
+
+If you're looking for help, check [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)
+
+You can also post your question on the [Kubernetes Slack](http://slack.k8s.io/) or the [Discuss Kubernetes](https://discuss.kubernetes.io/) forum.
+
+If the matter is security related, please disclose it privately via https://kubernetes.io/security/.
+-->
@@ -1,8 +1,17 @@
 >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-> For 1.11 Features: set Milestone to 1.11 and Base Branch to release-1.11
->^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-> NOTE: After opening the PR, please *un-check and re-check* the ["Allow edits from maintainers"](https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/) box so that maintainers can work on your patch and speed up the review process. This is a temporary workaround to address a known issue with GitHub.> 
+> Remember to delete this note before submitting your pull request.
+>
+> For pull requests on 1.17 Features: set Milestone to 1.17 and Base Branch to dev-1.17
+>
+> For pull requests on Chinese localization, set Base Branch to release-1.16
+> Feel free to ask questions in #kubernetes-docs-zh
+>
+> For pull requests on Korean Localization: set Base Branch to dev-1.16-ko.\<latest team milestone>
+>
+> If you need Help on editing and submitting pull requests, visit:
+> https://kubernetes.io/docs/contribute/start/#improve-existing-content.
+>
+> If you need Help on choosing which branch to use, visit:
+> https://kubernetes.io/docs/contribute/start#choose-which-git-branch-to-use.
+>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 >
-> Please delete this note before submitting the pull request.
-
-![Allow edits from maintainers checkbox](https://help.github.com/assets/images/help/pull_requests/allow-maintainers-to-make-edits-sidebar-checkbox.png)
@@ -1,7 +1,6 @@
 **/.DS_Store
 **/desktop.ini
 _site/**
-.sass-cache/**
 CNAME
 .travis.yml
 .idea/
@@ -29,3 +28,9 @@ nohup.out

 # Hugo output
 public/
+resources/
+
+# Netlify Functions build output
+package-lock.json
+functions/
+node_modules/
@@ -1,22 +0,0 @@
-language: go
-go:
-  - 1.9.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/website && cd $HOME/gopath/src/k8s.io/website
-# Fetch dependencies for us to run the tests in test/examples_test.go
- go get -t -v k8s.io/website/test
-# Make sure we are testing against the correct branch
- pushd $GOPATH/src/k8s.io/kubernetes && git checkout release-1.10 && popd
-
-# Simplified deduplication of dependencies.
- cp -L -R $GOPATH/src/k8s.io/kubernetes/vendor/ $GOPATH/src/
- rm -r $GOPATH/src/k8s.io/kubernetes/vendor/
-
-script:
-# TODO(bep)
- go test -v k8s.io/website/test #fixed by https://github.com/kubernetes/website/pull/8388
-#- ./verify-docs-format.sh
@@ -9,7 +9,8 @@ These are just guidelines, not rules. Use your best judgment, and feel free to p

 ### Code of Conduct

-Kubernetes follows the [Cloud Native Computing Foundation (CNCF) Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). By participating, you are expected to uphold this code. Please report unacceptable behavior to Sarah Novotny [sarahnovotny@google.com](mailto:sarahnovotny@google.com) and/or Dan Kohn [dan@linuxfoundation.org](mailto:dan@linuxfoundation.org).
+Kubernetes follows the [Cloud Native Computing Foundation (CNCF) Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). By participating, you are expected to uphold this code. Please report unacceptable behavior to the
+[Kubernetes Code of Conduct Committee](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct) <conduct@kubernetes.io>.

 ### Documentation and Site Decisions

@@ -12,16 +12,16 @@ RUN apk add --no-cache \
    curl \
    git \
    openssh-client \
-    rsync
+    rsync \
+    build-base \
+    libc6-compat

 ARG HUGO_VERSION

 RUN mkdir -p /usr/local/src && \
    cd /usr/local/src && \
-    curl -L https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_linux-64bit.tar.gz | tar -xz && \
+    curl -L https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_Linux-64bit.tar.gz | tar -xz && \
    mv hugo /usr/local/bin/hugo && \
-    curl -L https://bin.equinox.io/c/dhgbqpS8Bvy/minify-stable-linux-amd64.tgz | tar -xz && \
-    mv minify /usr/local/bin && \
    addgroup -Sg 1000 hugo && \
    adduser -Sg hugo -u 1000 -h /src hugo

@@ -1,27 +1,36 @@
 DOCKER       = docker
-HUGO_VERSION = 0.40.3
+HUGO_VERSION = 0.59.1
 DOCKER_IMAGE = kubernetes-hugo
-DOCKER_RUN   = $(DOCKER) run --rm --interactive --tty --volume $(PWD):/src
+DOCKER_RUN   = $(DOCKER) run --rm --interactive --tty --volume $(CURDIR):/src
+NODE_BIN     = node_modules/.bin
+NETLIFY_FUNC = $(NODE_BIN)/netlify-lambda

-.PHONY: all build sass build-preview help serve
+.PHONY: all build build-preview help serve

 help: ## Show this help.
 	@awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z_-]+:.*?## / {sub("\\\\n",sprintf("\n%22c"," "), $$2);printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}' $(MAKEFILE_LIST)

-all: build ## Build site with production settings and put deliverables in _site.
+all: build ## Build site with production settings and put deliverables in ./public

-sass: # Rebuild the SASS source into CSS
-	node-sass --output-style compact ./src/sass/styles.sass ./static/css/styles.css
-	node-sass --output-style compact ./src/sass/case_study_styles.sass ./static/css/case_study_styles.css
+build: ## Build site with production settings and put deliverables in ./public
+	hugo --minify

-build: ## Build site with production settings and put deliverables in _site.
-	hugo
+build-preview: ## Build site with drafts and future posts enabled
+	hugo --buildDrafts --buildFuture

-build-preview: ## Build site with drafts and future posts enabled.
-	hugo -D -F
+functions-build:
+	$(NETLIFY_FUNC) build functions-src
+
+check-headers-file:
+	scripts/check-headers-file.sh
+
+production-build: check-hugo-versions build check-headers-file ## Build the production site and ensure that noindex headers aren't added
+
+non-production-build: check-hugo-versions ## Build the non-production site, which adds noindex headers to prevent indexing
+	hugo --enableGitInfo

 serve: ## Boot the development server.
-	hugo server
+	hugo server --buildFuture

 docker-image:
 	$(DOCKER) build . --tag $(DOCKER_IMAGE) --build-arg HUGO_VERSION=$(HUGO_VERSION)
@@ -29,5 +38,12 @@ docker-image:
 docker-build:
 	$(DOCKER_RUN) $(DOCKER_IMAGE) hugo

-stage:
-	$(DOCKER_RUN) -p 1313:1313 $(DOCKER_IMAGE) hugo server --watch --bind 0.0.0.0
+docker-serve:
+	$(DOCKER_RUN) -p 1313:1313 $(DOCKER_IMAGE) hugo server --buildFuture --bind 0.0.0.0
+
+test-examples:
+	scripts/test_examples.sh install
+	scripts/test_examples.sh run
+
+check-hugo-versions:
+	scripts/hugo-version-check.sh $(HUGO_VERSION)
@@ -1,19 +1,16 @@
-# Reviewers can /lgtm /approve but not sufficient for auto-merge without an
-# approver
+# See the OWNERS docs at https://go.k8s.io/owners
+
 reviewers:
- zhangxiaoyu-zidif
- xiangpengzhao
- stewart-yu
- Rajakavitha1 
-# 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
+- sig-docs-en-reviews # Defined in OWNERS_ALIASES
+
 approvers:
- heckj
- bradamant3
- bradtopol
- steveperry-53
- zacharysarah
+- sig-docs-en-owners # Defined in OWNERS_ALIASES
+
+emeritus_approvers:
 - chenopis
- mistyhacks
- tengqm
+- jaredbhatti
+# stewart-yu, you're welcome to return when you're ready to resume PR wrangling
+- stewart-yu 
+
+labels:
+- sig/docs
@@ -1,199 +1,192 @@
 aliases:
-  sig-api-machinery: #Team: API Server; GH: sig-api-machinery-pr-reviews; e.g. Annotations, Labels
-    - lavalamp
-    - sttts
-    - liggitt
-    - smarterclayton
-    - deads2k
-  sig-apps: #Team: Workloads; GH: sig-apps-pr-reviews; e.g. ConfigMaps, CronJobs, CustomResourceDefinitions, DaemonSets, Deployments, Jobs, Secrets, StatefulSets
-    - enisoc
-    - erictune
-    - foxish
-    - janetkuo
-    - kow3ns
-    - lukaszo
-    - mfojtik
-    - smarterclayton
-    - soltysh
-    - tnozicka
-  sig-architecture: #GH: sig-architecture-pr-reviews
-    - smarterclayton
-    - bgrant0607
-  sig-auth: #GH: sig-auth-pr-reviews
-    - php-coder
-    - liggitt
-    - mikedanese
-    - ericchiang
-    - mattmoyer
-    - enj
-    - deads2k
-    - davidopp
-  sig-autoscaling: #GH: sig-autoscaling-pr-reviews
-    - DirectXMan12
-    - bskiba
-    - aleksandra-malinowska
-    - MaciekPytel
-    - davidopp
-    - mwielgus
-  sig-aws: #Amazon AWS
-    - justinsb
-    - kris-nova
-    - chrislovecnm
-    - mfburnett
-  sig-azure: #Microsoft Azure
-    - slack
-    - colemickens
-    - jdumars
-  sig-big-data: #GH: sig-big-data-pr-reviews
-    - foxish
-  sig-cli: #Team: CLI; GH: sig-cli-pr-reviews; e.g. kubectl
-    - adohe
-    - deads2k
-    - derekwaynecarr
-    - dims
-    - dshulyak
-    - eparis
-    - ericchiang
-    - ghodss
-    - mengqiy
-    - rootfs
-    - shiywang
-    - smarterclayton
-    - soltysh
-    - sttts
-  sig-cluster-lifecycle: #GH: sig-cluster-lifecycle-pr-reviews
+  sig-cluster-lifecycle-kubeadm-approvers: # Approving changes to kubeadm documentation
    - timothysc
+    - lukemarsden
    - luxas
-    - roberthbailey
-    - fabriziopandini 
-  sig-cluster-ops:
-    - zehicle
-    - jdumars
-  sig-contribex: #aka Contributor Experience; GH: sig-contributor-experience-pr-reviews
-    - rmmh
-    - cblecker
-    - apelisse
-    - grodrigues3
-    - spxtr
-  sig-contributor-experience: #GH: sig-contributor-experience-pr-reviews
-    - rmmh
-    - cblecker
-    - apelisse
-    - grodrigues3
-    - spxtr
-  sig-docs: #Team: documentation; GH: sig-docs-pr-reviews
+    - fabriziopandini
+  sig-cluster-lifecycle-kubeadm-reviewers: # Reviewing kubeadm documentation
+    - timothysc
+    - lukemarsden
+    - luxas
+    - fabriziopandini
+    - kad
+    - xiangpengzhao
+    - stealthybox
+    - liztio
+    - chuckha
+    - detiber
+    - dixudx
+  sig-docs-blog-owners: # Approvers for blog content
+    - castrojo
+    - kbarnard10
+    - zacharysarah
+  sig-docs-blog-reviewers: # Reviewers for blog content
+    - cody-clark
+    - mrbobbytables
+    - onlydole
+    - parispittman
+    - vonguard
+  sig-docs-de-owners: # Admins for German content
+    - bene2k1
+    - mkorbi
+    - rlenferink
+  sig-docs-de-reviews: # PR reviews for German content
+    - bene2k1
+    - mkorbi
+    - rlenferink
+  sig-docs-en-owners: # Admins for English content
    - bradamant3
+    - bradtopol
+    - daminisatya
+    - gochist
+    - jaredbhatti
+    - jimangel
+    - kbarnard10
+    - kbhawkey
+    - makoscafee
+    - rajakavitha1
+    - ryanmcginnis
+    - simplytunde
+    - steveperry-53
+    - xiangpengzhao
+    - zacharysarah
+    - zparnold
+  sig-docs-en-reviews: # PR reviews for English content
+    - rajakavitha1
+    - sftim
+    - tengqm
+  sig-docs-es-owners: # Admins for Spanish content
+    - raelga
+    - alexbrand
+  sig-docs-es-reviews: # PR reviews for Spanish content
+    - raelga
+    - alexbrand
+    # glo-pena
+    - electrocucaracha
+  sig-docs-fr-owners: # Admins for French content
+    - remyleone
+    - perriea
+    - rekcah78
+    - yastij
+    - smana
+    - rbenzair
+    - abuisine
+    - erickhun
+    - jygastaud
+    - awkif
+    - oussemos
+  sig-docs-fr-reviews: # PR reviews for French content
+    - remyleone
+    - perriea
+    - rekcah78
+    - yastij
+    - smana
+    - rbenzair
+    - abuisine
+    - erickhun
+    - jygastaud
+    - awkif
+    - oussemos
+  sig-docs-hi-owners: # Admins for Hindi content
+    - avidLearnerInProgress
+    - daminisatya
+    - mittalyashu
+    - Rajakavitha1
+  sig-docs-hi-reviews: # PR reviews for Hindi content
+    - avidLearnerInProgress
+    - daminisatya
+    - mittalyashu
+    - Rajakavitha1
+  sig-docs-id-owners: # Admins for Indonesian content
+    - girikuncoro
+    - irvifa
+  sig-docs-id-reviews: # PR reviews for Indonesian content
+    - girikuncoro
+    - irvifa
+  sig-docs-it-owners: # Admins for Italian content
+    - mattiaperi
+    - micheleberardi
+    - rlenferink
+  sig-docs-it-reviews: # PR reviews for Italian content
+    - mattiaperi
+    - micheleberardi
+    - rlenferink
+  sig-docs-ja-owners: # Admins for Japanese content
+    - cstoku
+    - inductor
+    - nasa9084
+  sig-docs-ja-reviews: # PR reviews for Japanese content
+    - cstoku
+    - inductor
+    - makocchi-git
+    - MasayaAoyama
+    - nasa9084
+    - oke-py
+  sig-docs-ko-owners: # Admins for Korean content
+    - ClaudiaJKang
+    - gochist
+    - ianychoi
+    - seokho-son
+    - zacharysarah
+  sig-docs-ko-reviews: # PR reviews for Korean content
+    - ClaudiaJKang
+    - gochist
+    - ianychoi
+    - seokho-son
+  sig-docs-maintainers: # Website maintainers
+    - bradamant3
+    - jimangel
+    - kbarnard10
+    - pwittrock
    - steveperry-53
    - zacharysarah
-    - bradtopol
-    - heckj
-  sig-federation: #Team: Federation; e.g. Federated Clusters
-    - csbell
-  sig-gcp: #Google Cloud Platform; GH: sig-gcp-pr-reviews
-    - abgworrall
-  sig-instrumentation: #GH: sig-instrumentation-pr-reviews; e.g. metrics, logging, events
-    - DirectXMan12
-    - x13n
-    - kawych
-    - brancz
-    - fabxc
-    - loburm
-    - piosz
-    - fgrzadkowski
-  sig-multicluster: #GH: sig-multicluster-pr-reviews; e.g. resiliency against availability zone outages; hybrid clouds; spanning multiple cloud providers; migration to public clouds
-    - madhusudancs
-    - marun
-    - jianhuiz
-    - shashidharatd
-    - nikhiljindal
-    - quinton-hoole
-    - mwielgus
-    - csbell
-  sig-network: #Team: Network; GH: sig-network-pr-reviews; e.g. Ingress, Network Policies, Services
-    - bowei
-    - caseydavenport
-    - danwinship
-    - dcbw
-    - dnardo
-    - freehan
-    - mrhohn
-    - nicksardo
-    - thockin
-  sig-node: #Team: Node; GH: sig-node-pr-reviews; e.g. Containers, Docker, Images, OS images, Pods, Registries
-    - Random-Liu
-    - dashpole
+    - zparnold
+  sig-docs-zh-owners: # Admins for Chinese content
+    - chenopis
+    - chenrui333
    - dchen1107
-    - derekwaynecarr
-    - dims
-    - feiskyer
-    - mtaufen
-    - ncdc
-    - pmorie
-    - resouer
-    - sjpotter
-    - tallclair
-    - tmrts
-    - vishh
-    - yifan-gu
-    - yujuhong
-  sig-onprem: #On-premises; GH: sig-onprem-pr-reviews
-    - zen
-    - idvoretskyi
-    - pigmej
-    - feiskyer
-    - nebril
-  sig-openstack: #GH: sig-openstack-pr-reviews
-    - hogepodge
-    - dklyle
-    - rjmorse
-  sig-pm: #aka Product Management
-    - apsinha
-    - idvoretskyi
-    - calebamiles
-  sig-product-management:
-    - apsinha
-    - idvoretskyi
-    - calebamiles
-  sig-release: #GH: sig-release-pr-reviews
-    - calebamiles
-    - enisoc
-    - pwittrock
-  sig-rktnetes:
-    - calebamiles
-  sig-scalability: #GH: sig-scalability-pr-reviews
-    - jbeda
-    - spiffxp
-    - lavalamp
-    - countspongebob
-  sig-scheduling: #Team: Sharing; GH: sig-scheduling-pr-reviews; e.g. Scheduler
-    - bsalamat
-    - davidopp
-    - jayunit100
-    - k82cn
-    - resouer
-    - timothysc
-    - wojtek-t
-  sig-service-catalog: #GH: sig-service-catalog-pr-reviews; e.g. Service Broker
-    - pmorie
-    - jessfraz
-    - pwittrock
-    - droot
-    - seans3
-  sig-storage: #Team: Storage; GH: sig-storage-pr-reviews; e.g. Volumes
-    - childsb
-    - jsafrane
-    - rootfs
-    - saad-ali
-    - matchstick
-    - msau42
-  sig-testing: #GH: sig-testing-pr-reviews
-    - fejta
-    - ixdy
-    - rmmh
-    - spiffxp
-    - spxtr
-  sig-ui: #User Interface
-    - danielromlein
-    - floreks
-  sig-windows:
-    - michmike
+    - haibinxie
+    - hanjiayao
+    - lichuqiang
+    - markthink
+    - SataQiu
+    - xiangpengzhao
+    - xichengliudui
+    - zacharysarah
+    - zhangxiaoyu-zidif
+  sig-docs-zh-reviews: # PR reviews for Chinese content
+    - chenrui333
+    - idealhack
+    - markthink
+    - SataQiu
+    - tengqm
+    - xiangpengzhao
+    - xichengliudui
+    - zhangxiaoyu-zidif
+    - pigletfly
+  sig-docs-pt-owners: # Admins for Portuguese content
+    - femrtnz
+    - jcjesus
+    - devlware
+  sig-docs-pt-reviews: # PR reviews for Portugese content
+    - femrtnz
+    - jcjesus
+    - devlware
+  sig-docs-vi-owners: # Admins for Vietnamese content
+    - huynguyennovem
+    - ngtuna
+    - truongnh1992
+  sig-docs-vi-reviews: # PR reviews for Vietnamese content
+    - huynguyennovem
+    - ngtuna
+    - truongnh1992
+  sig-docs-ru-owners: # Admins for Russian content
+    - msheldyakov
+    - aisonaku
+    - potapy4
+    - dianaabv
+  sig-docs-ru-reviews: # PR reviews for Russian content
+    - msheldyakov
+    - aisonaku
+    - potapy4
+    - dianaabv
@@ -0,0 +1,81 @@
+# Kubernetes Dokumentation
+
+[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website)
+[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
+
+Herzlich willkommen! Dieses Repository enthält alle Assets, die zur Erstellung der [Kubernetes-Website und Dokumentation](https://kubernetes.io/) erforderlich sind. Wir freuen uns sehr, dass Sie dazu beitragen wollen!
+
+## Beiträge zur Dokumentation
+
+Sie können auf die Schaltfläche **Fork** im oberen rechten Bereich des Bildschirms klicken, um eine Kopie dieses Repositorys in Ihrem GitHub-Konto zu erstellen. Diese Kopie wird als *Fork* bezeichnet. Nehmen Sie die gewünschten Änderungen an Ihrem Fork vor. Wenn Sie bereit sind, diese Änderungen an uns zu senden, gehen Sie zu Ihrem Fork und erstellen Sie eine neue Pull-Anforderung, um uns darüber zu informieren.
+
+Sobald Ihre Pull-Anfrage erstellt wurde, übernimmt ein Rezensent von Kubernetes die Verantwortung für klares, umsetzbares Feedback. Als Eigentümer des Pull-Request **liegt es in Ihrer Verantwortung Ihren Pull-Reqest enstsprechend des Feedbacks, dass Sie vom Kubernetes-Reviewer erhalten haben abzuändern.** Beachten Sie auch, dass Sie am Ende mehr als einen Rezensenten von Kubernetes erhalten, der Ihnen Feedback gibt, oder dass Sie Rückmeldungen von einem Rezensenten von Kubernetes erhalten, der sich von demjenigen unterscheidet, der ursprünglich für das Feedback zugewiesen wurde. In einigen Fällen kann es vorkommen, dass einer Ihrer Prüfer bei Bedarf eine technische Überprüfung von einem [Kubernetes Tech-Reviewer](https://github.com/kubernetes/website/wiki/tech-reviewers) anfordert. Reviewer geben ihr Bestes, um zeitnah Feedback zu geben, die Antwortzeiten können jedoch je nach den Umständen variieren.
+
+Weitere Informationen zum Beitrag zur Kubernetes-Dokumentation finden Sie unter:
+
+* [Mitwirkung beginnen](https://kubernetes.io/docs/contribute/start/)
+* [Ihre Dokumentationsänderungen bereitstellen](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
+* [Seitenvorlagen verwenden](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [Dokumentationsstil-Handbuch](http://kubernetes.io/docs/contribute/style/style-guide/)
+* [Übersetzung der Kubernetes-Dokumentation](https://kubernetes.io/docs/contribute/localization/)
+
+## `README.md`'s Localizing Kubernetes Documentation
+
+### Deutsch
+Die Betreuer der deutschen Lokalisierung erreichen Sie unter:
+
+* Benedikt Rollik ([@bene2k1](https://github.com/bene2k1))
+* Max Körbächer ([@mkorbi](https://github.com/mkorbi))
+* [Slack Kanal](https://kubernetes.slack.com/messages/kubernetes-docs-de)
+
+## Site lokal mit Docker ausführen
+
+Um die Kubernetes-Website lokal laufen zu lassen, empfiehlt es sich, ein spezielles [Docker](https://docker.com) Image auszuführen, das den statischen Site-Generator [Hugo](https://gohugo.io) enthält.
+
+> Unter Windows benötigen Sie einige weitere Tools, die Sie mit [Chocolatey](https://chocolatey.org) installieren können.
+`choco install make`
+
+> Wenn Sie die Website lieber lokal ohne Docker ausführen möchten, finden Sie weitere Informationen unter [Website lokal mit Hugo ausführen](#Die-Site-lokal-mit-Hugo-ausführen).
+
+Wenn Sie Docker [installiert](https://www.docker.com/get-started) haben, erstellen Sie das Docker-Image `kubernetes-hugo` lokal:
+
+```bash
+make docker-image
+```
+
+Nachdem das Image erstellt wurde, können Sie die Site lokal ausführen:
+
+```bash
+make docker-serve
+```
+
+Öffnen Sie Ihren Browser unter http://localhost:1313, um die Site anzuzeigen. Wenn Sie Änderungen an den Quelldateien vornehmen, aktualisiert Hugo die Site und erzwingt eine Browseraktualisierung.
+
+## Die Site lokal mit Hugo ausführen
+
+Hugo-Installationsanweisungen finden Sie in der [offiziellen Hugo-Dokumentation](https://gohugo.io/getting-started/installing/). Stellen Sie sicher, dass Sie die Hugo-Version installieren, die in der Umgebungsvariablen `HUGO_VERSION` in der Datei [`netlify.toml`](netlify.toml#L9) angegeben ist.
+
+So führen Sie die Site lokal aus, wenn Sie Hugo installiert haben:
+
+```bash
+make serve
+```
+
+Dadurch wird der lokale Hugo-Server an Port 1313 gestartet. Öffnen Sie Ihren Browser unter http://localhost:1313, um die Site anzuzeigen. Wenn Sie Änderungen an den Quelldateien vornehmen, aktualisiert Hugo die Site und erzwingt eine Browseraktualisierung.
+
+## Community, Diskussion, Beteiligung und Unterstützung
+
+Erfahren Sie auf der [Community-Seite](http://kubernetes.io/community/) wie Sie mit der Kubernetes-Community interagieren können.
+
+Sie können die Betreuer dieses Projekts unter folgender Adresse erreichen:
+
+- [Slack](https://kubernetes.slack.com/messages/sig-docs)
+- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
+
+### Verhaltensregeln
+
+Die Teilnahme an der Kubernetes-Community unterliegt dem [Kubernetes-Verhaltenskodex](code-of-conduct.md).
+
+## Vielen Dank!
+
+Kubernetes lebt vom Community Engagement und wir freuen uns sehr über Ihre Beiträge zu unserer Website und unserer Dokumentation!
@@ -0,0 +1,76 @@
+# La documentación de Kubernetes
+
+[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website)
+[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
+
+Bienvenido!
+Este repositorio contiene todos los recursos necesarios para construir el [sitio web de Kubernetes y su documentación](https://kubernetes.io/). ¡Estamos encantados de que quiera contribuir!
+
+## Contribuyendo con la documentación
+
+Puede hacer clic en el botón **Fork** situado en la esquina superior derecha de la pantalla para crear una copia de este repositorio en su cuenta de GitHub. A ese tipo de copia se le llama **Fork** (bifurcación) y le permite editar el contenido del repositorio en su copia personal. Realice los cambios que quiera en su **fork** y, cuando esté listo para enviarnos esos cambios, vaya a **fork** en repositorio en su GitHub y cree una nueva **pull request** para que tengamos constancia de la propuesta de cambios.
+
+Una vez la **pull request** ha sido creada, un revisor de Kubernetes asumirá la responsabilidad de proporcionar comentarios claros y prácticos sobre como continuar. Como propietario de la PR, **es su responsabilidad modificar la pull request para abordar los comentarios proporcionados por el revisor de Kubernetes.** Tenga en cuenta que algunas veces puede terminar teniendo más de un revisor de Kubernetes participando en la revisión, por lo que es posible que reciba comentarios de más revisores a parte del asignado originalmente en la creación de la **pull request**. Además, en algunas ocasiones, es posible que uno de sus revisores solicite una revisión técnica por parte de un [revisor técnico de Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers) si lo considera necesario.
+
+Los revisores harán todo lo posible para proporcionar toda la información necesaria para que la **pull request** siga adelante en un tiempo razonable, pero este tiempo de respuesta puede variar según las circunstancias.
+
+Para obtener más información sobre cómo contribuir a la documentación de Kubernetes, puede consultar:
+
+* [Empezando a contribuir](https://kubernetes.io/docs/contribute/start/)
+* [Visualizando sus cambios en su entorno local](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
+* [Utilizando las plantillas de las páginas](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [Guía de estilo de la documentación](http://kubernetes.io/docs/contribute/style/style-guide/)
+* [Traduciendo la documentación de Kubernetes](https://kubernetes.io/docs/contribute/localization/)
+
+## Levantando el sitio web kubernetes.io en su entorno local con Docker
+
+El método recomendado para levantar una copia local del sitio web kubernetes.io es utilizando la imagen de [Docker](https://docker.com) que incluye el generador de sitios estáticos [Hugo](https://gohugo.io).
+
+> Para Windows, algunas otras herramientas como Make son necesarias. Puede instalarlas utilizando el gestor [Chocolatey](https://chocolatey.org). `choco install make` o siguiendo las instrucciones de [Make for Windows](http://gnuwin32.sourceforge.net/packages/make.htm).
+
+> Si prefiere levantar el sitio web sin utilizar **Docker**, puede seguir las instrucciones disponibles en la sección [Levantando kubernetes.io en local con Hugo](#levantando-kubernetes.io-en-local-con-hugo).
+
+Una vez tenga Docker [configurado en su máquina](https://www.docker.com/get-started), puede construir la imagen de Docker `kubernetes-hugo` localmente ejecutando el siguiente comando en la raíz del repositorio:
+
+```bash
+make docker-image
+```
+
+Una vez tenga la imagen construida, puede levantar el sitio web ejecutando:
+
+```bash
+make docker-serve
+```
+
+Abra su navegador y visite http://localhost:1313 para acceder a su copia local del sitio. A medida que vaya haciendo cambios en el código fuente, Hugo irá actualizando la página y forzará la actualización en el navegador.
+
+## Levantando kubernetes.io en local con Hugo
+
+Revise la [documentación oficial de Hugo](https://gohugo.io/getting-started/installing/) para obtener las instrucciones de instalación en su sistema operativo. Asegúrese de instalar la versión de Hugo especificada en la variable de entorno  `HUGO_VERSION` del fichero [`netlify.toml`](netlify.toml#L9).
+
+Para levantar el sitio localmente una vez Hugo está instalado en su sistema, puede ejecutar el siguiente comando:
+
+```bash
+make serve
+```
+
+Este comando levantará un servidor de Hugo en el puerto **1313** al que podrá acceder visitando http://localhost:1313 y dónde podrá visualizar su copia local del sitio web. A medida que vaya haciendo cambios en el código fuente, Hugo irá actualizando la página y forzará la actualización en el navegador.
+
+## Comunidad, discusión, contribuir y soporte
+
+Aprenda como participar en la comunidad de Kubernetes visitando la [página de comunidad](http://kubernetes.io/community/).
+
+Puede ponerse en contacto con los mantenedores de este proyecto en:
+
+- [Slack](https://kubernetes.slack.com/messages/sig-docs)
+- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
+
+### Código de conducta
+
+La participación en la comunidad de Kubernetes está regulada por el [Código de Conducta de Kubernetes](code-of-conduct.md).
+
+## ¡Muchas gracias!
+
+Kubernetes es posible gracias a la participación de la comunidad y la documentación es vital para facilitar el acceso al proyecto.
+
+Agradecemos muchísimo sus contribuciones a nuestro sitio web y nuestra documentación.
@@ -0,0 +1,83 @@
+# Documentation de Kubernetes
+
+[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website)
+[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
+
+Bienvenue !
+Ce référentiel contient toutes les informations nécessaires à la construction du site web et de la documentation de Kubernetes.
+Nous sommes très heureux que vous vouliez contribuer !
+
+## Contribuer à la rédaction des docs
+
+Vous pouvez cliquer sur le bouton **Fork** en haut à droite de l'écran pour créer une copie de ce dépôt dans votre compte GitHub.
+Cette copie s'appelle un *fork*.
+Faites tous les changements que vous voulez dans votre fork, et quand vous êtes prêt à nous envoyer ces changements, allez dans votre fork et créez une nouvelle pull request pour nous le faire savoir.
+
+Une fois votre pull request créée, un examinateur de Kubernetes se chargera de vous fournir une revue claire et exploitable.
+En tant que propriétaire de la pull request, **il est de votre responsabilité de modifier votre pull request pour tenir compte des commentaires qui vous ont été fournis par l'examinateur de Kubernetes.**
+Notez également que vous pourriez vous retrouver avec plus d'un examinateur de Kubernetes pour vous fournir des commentaires ou vous pourriez finir par recevoir des commentaires d'un autre examinateur que celui qui vous a été initialement affecté pour vous fournir ces commentaires.
+De plus, dans certains cas, l'un de vos examinateur peut demander un examen technique à un [examinateur technique de Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers) au besoin.
+Les examinateurs feront de leur mieux pour fournir une revue rapidement, mais le temps de réponse peut varier selon les circonstances.
+
+Pour plus d'informations sur la contribution à la documentation Kubernetes, voir :
+
+* [Commencez à contribuer](https://kubernetes.io/docs/contribute/start/)
+* [Apperçu des modifications apportées à votre documentation](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
+* [Utilisation des modèles de page](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [Documentation Style Guide](http://kubernetes.io/docs/contribute/style/style-guide/)
+* [Traduction de la documentation Kubernetes](https://kubernetes.io/docs/contribute/localization/)
+
+## Exécuter le site localement en utilisant Docker
+
+La façon recommandée d'exécuter le site web Kubernetes localement est d'utiliser une image spécialisée [Docker](https://docker.com) qui inclut le générateur de site statique [Hugo](https://gohugo.io).
+
+> Si vous êtes sous Windows, vous aurez besoin de quelques outils supplémentaires que vous pouvez installer avec [Chocolatey](https://chocolatey.org). `choco install install make`
+
+> Si vous préférez exécuter le site Web localement sans Docker, voir [Exécuter le site localement avec Hugo](#running-the-site-locally-using-hugo) ci-dessous.
+
+Si vous avez Docker [up and running](https://www.docker.com/get-started), construisez l'image Docker `kubernetes-hugo' localement:
+
+```bash
+make docker-image
+```
+
+Une fois l'image construite, vous pouvez exécuter le site localement :
+
+```bash
+make docker-serve
+```
+
+Ouvrez votre navigateur à l'adresse: http://localhost:1313 pour voir le site.
+Lorsque vous apportez des modifications aux fichiers sources, Hugo met à jour le site et force le navigateur à rafraîchir la page.
+
+## Exécuter le site localement en utilisant Hugo
+
+Voir la [documentation officielle Hugo](https://gohugo.io/getting-started/installing/) pour les instructions d'installation Hugo.
+Assurez-vous d'installer la version Hugo spécifiée par la variable d'environnement `HUGO_VERSION` dans le fichier [`netlify.toml`](netlify.toml#L9).
+
+Pour exécuter le site localement lorsque vous avez Hugo installé :
+
+```bash
+make serve
+```
+
+Le serveur Hugo local démarrera sur le port 1313.
+Ouvrez votre navigateur à l'adresse: http://localhost:1313 pour voir le site.
+Lorsque vous apportez des modifications aux fichiers sources, Hugo met à jour le site et force le navigateur à rafraîchir la page.
+
+## Communauté, discussion, contribution et assistance
+
+Apprenez comment vous engager avec la communauté Kubernetes sur la [page communauté](http://kubernetes.io/community/).
+
+Vous pouvez joindre les responsables de ce projet à l'adresse :
+
+- [Slack](https://kubernetes.slack.com/messages/sig-docs)
+- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
+
+### Code de conduite
+
+La participation à la communauté Kubernetes est régie par le [Code de conduite de Kubernetes](code-of-conduct.md).
+
+## Merci !
+
+Kubernetes prospère grâce à la participation de la communauté, et nous apprécions vraiment vos contributions à notre site et à notre documentation !
@@ -0,0 +1,84 @@
+# कुबरनेट्स प्रलेखन
+
+[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website)
+[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
+
+स्वागत हे! इस रिपॉजिटरी में [कुबरनेट्स वेबसाइट और दस्तावेज](https://kubernetes.io/) बनाने के लिए आवश्यक सभी संपत्तियां हैं। हम बहुत खुश हैं कि आप योगदान करना चाहते हैं!
+
+## डॉक्स में योगदान देना
+
+आप अपने GitHub खाते में इस रिपॉजिटरी की एक copy बनाने के लिए स्क्रीन के ऊपरी-दाएँ क्षेत्र में **Fork** बटन पर क्लिक करें। इस copy को *Fork* कहा जाता है। अपने fork में कोई भी परिवर्तन करना चाहते हैं, और जब आप उन परिवर्तनों को हमारे पास भेजने के लिए तैयार हों, तो अपने fork पर जाएं और हमें इसके बारे में बताने के लिए एक नया pull request बनाएं।
+
+एक बार जब आपका pull request बन जाता है, तो एक कुबरनेट्स समीक्षक स्पष्ट, कार्रवाई योग्य प्रतिक्रिया प्रदान करने की जिम्मेदारी लेगा। pull request के मालिक के रूप में, **यह आपकी जिम्मेदारी है कि आप कुबरनेट्स समीक्षक द्वारा प्रदान की गई प्रतिक्रिया को संबोधित करने के लिए अपने pull request को संशोधित करें।**
+
+यह भी ध्यान दें कि आप एक से अधिक कुबरनेट्स समीक्षक आपको प्रतिक्रिया प्रदान कर सकते हैं या आप एक कुबरनेट्स समीक्षक से प्रतिक्रिया प्राप्त कर सकते हैं जो मूल रूप से आपको प्रतिक्रिया प्रदान करने के लिए दिए गए एक से भिन्न है। इसके अलावा, कुछ मामलों में, आपका एक समीक्षक जरूरत पड़ने पर [कुबेरनेट्स टेक समीक्षक](https://github.com/kubernetes/website/wiki/Tech-reviewers) से तकनीकी समीक्षा प्राप्त कर सकता है। समीक्षक समय पर प्रतिक्रिया देने के लिए पूरी कोशिश करेंगे, लेकिन परिस्थितियों के आधार पर प्रतिक्रिया समय अलग-अलग हो सकता है।
+
+कुबरनेट्स प्रलेखन में योगदान देने के बारे में अधिक जानकारी के लिए, देखें:
+
+* [योगदान देना शुरू करें](https://kubernetes.io/docs/contribute/start/)
+* [परिवर्तनों को अंतिम चरण में लेजाएं](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
+* [पेज टेम्पलेट](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [प्रलेखन शैली गाइड](http://kubernetes.io/docs/contribute/style/style-guide/)
+* [स्थानीयकरण कुबरनेट्स प्रलेखन](https://kubernetes.io/docs/contribute/localization/)
+
+## `README.md`'s स्थानीयकरण कुबरनेट्स प्रलेखन
+
+आप पर हिंदी स्थानीयकरण के maintainers तक पहुँच सकते हैं:
+
+* Yashu Mittal ([Twitter](https://twitter.com/mittalyashu77), [GitHub](https://github.com/mittalyashu))
+* [Slack channel](https://kubernetes.slack.com/messages/kubernetes-docs-hi)
+
+## स्थानीय रूप से डॉकर का उपयोग करके साइट चलाना
+
+कुबरनेट्स वेबसाइट को स्थानीय रूप से चलाने के लिए अनुशंसित तरीका एक विशेष [डॉकर](https://docker.com) image को चलाना है, जिसमें [Hugo](https://gohugo.io) स्टेटिक साइट जनरेटर शामिल है।
+
+> यदि आप विंडोज पर हैं, तो आपको कुछ और टूल्स की आवश्यकता होगी जिन्हें आप [Chocolatey](https://chocolatey.org) के साथ इंस्टॉल कर सकते हैं।
+
+> यदि आप डॉकर के बिना स्थानीय रूप से वेबसाइट चलाना पसंद करते हैं, तो नीचे Hugo का उपयोग करके स्थानीय रूप से साइट चलाना देखें।
+
+यदि आप डॉकर के बिना स्थानीय रूप से वेबसाइट चलाना पसंद करते हैं, तो नीचे दिए गए Hugo का उपयोग करके स्थानीय रूप से [साइट को चलाने](#running-the-site-locally-using-hugo) का तरीका देखें।
+
+यदि आप [डॉकर](https://www.docker.com/get-started) चला रहे हैं, तो स्थानीय रूप से `कुबेरनेट्स-ह्यूगो` Docker image बनाएँ:
+
+```bash
+make docker-image
+```
+
+एक बार image बन जाने के बाद, आप साइट को स्थानीय रूप से चला सकते हैं:
+
+```bash
+make docker-serve
+```
+
+साइट देखने के लिए अपने browser को `http://localhost:1313` पर खोलें। जैसा कि आप source फ़ाइलों में परिवर्तन करते हैं, Hugo साइट को अपडेट करता है और browser को refresh करने पर मजबूर करता है।
+
+## Hugo का उपयोग करते हुए स्थानीय रूप से साइट चलाना
+
+Hugo निर्देशों के लिए [आधिकारिक Hugo प्रलेखन](https://gohugo.io/getting-started/installing/) देखें। [`Netlify.toml`](netlify.toml#L9) फ़ाइल में `HUGO_VERSION` environment variable द्वारा निर्दिष्ट Hugo version को install करना सुनिश्चित करें।
+
+जब आप Hugo को install करते हैं तो स्थानीय रूप से साइट को चलाने के लिए:
+
+```bash
+make serve
+```
+
+यह पोर्ट `1313` पर Hugo सर्वर को शुरू करेगा। साइट देखने के लिए अपने browser को `http://localhost:1313` पर खोलें। जैसा कि आप source फ़ाइलों में परिवर्तन करते हैं, Hugo साइट को अपडेट करता है और एक browser को refresh करने पर मजबूर करता है।
+
+## समुदाय, चर्चा, योगदान और समर्थन
+
+[Community page](http://kubernetes.io/community/) पर कुबरनेट्स समुदाय के साथ जुड़ना सीखें।
+
+आप इस परियोजना के स्थानीयकरण तक पहुँच सकते हैं:
+
+- [Slack](https://kubernetes.slack.com/messages/sig-docs)
+- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
+
+## कोड ओफ़ कंडक्ट
+
+कुबरनेट्स समुदाय में भागीदारी [कुबरनेट्स कोड ओफ़ कंडक्ट](https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/hi.md) द्वारा शासित है.
+
+## धन्यवाद!
+
+कुबरनेट्स सामुदायिक भागीदारी पर पनपती है, और हम वास्तव में हमारी साइट और हमारे प्रलेखन में आपके योगदान की सराहना करते हैं!
+
+कुबरनेट्स आपकी भागीदारी पर निर्भर है, और हम हमारी साइट और प्रलेखन में आपके योगदान का मान करते हैं!
@@ -0,0 +1,72 @@
+# Dokumentasi Kubernetes
+
+[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website)
+[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
+
+Selamat datang! Repositori ini merupakan wadah bagi semua komponen yang dibutuhkan untuk membuat [dokumentasi Kubernetes](https://kubernetes.io/). Kami merasa sangat senang apabila kamu berminat untuk menjadi kontributor!
+
+## Kontribusi pada dokumentasi
+
+Pertama, kamu dapat menekan tombol **Fork** yang berada pada bagian atas layar, untuk menyalin repositori pada akun Github-mu. Salinan ini disebut sebagai **fork**. Kamu dapat menambahkan konten pada **fork** yang kamu miliki, setelah kamu merasa cukup untuk menambahkan konten yang kamu miliki dan ingin memberikan konten tersebut pada kami, kamu dapat melihat **fork** yang telah kamu buat dan membuat **pull request** untuk memberi tahu kami bahwa kamu ingin menambahkan konten yang telah kamu buat.
+
+Setelah kamu membuat sebuah **pull request**, seorang **reviewer** akan memberikan masukan terhadap konten yang kamu sediakan serta beberapa hal yang dapat kamu lakukan apabila perbaikan diperlukan terhadap konten yang telah kamu sediakan. Sebagai seorang yang membuat **pull request**, **sudah menjadi kewajiban kamu untuk melakukan modifikasi terhadap konten yang kamu berikan sesuai dengan masukan yang diberikan oleh seorang reviewer Kubernetes**. Perlu kamu ketahui bahwa kamu dapat saja memiliki lebih dari satu orang **reviewer Kubernetes** atau dalam kasus kamu bisa saja mendapatkan **reviewer Kubernetes** yang berbeda dengan **reviewer Kubernetes** awal yang ditugaskan untuk memberikan masukan terhadap konten yang kamu sediakan. Selain itu, seorang **reviewer Kubernetes** bisa saja meminta masukan teknis dari [reviewer teknis Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers) jika diperlukan. 
+
+Untuk informasi lebih lanjut mengenai tata cara melakukan kontribusi, kamu dapat melihat tautan di bawah ini:
+
+* [Petunjuk Melakukan Kontribusi](https://kubernetes.io/docs/contribute/start/)
+* [Melakukan Tahap Staging pada Konten Dokumentasi yang telah Kamu Sediakan](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
+* [Petunjuk Menggunakan Page Templates](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [Petunjuk untuk Documentation Style](http://kubernetes.io/docs/contribute/style/style-guide/)
+* [Petunjuk untuk Melakukan Lokalisasi Dokumentasi Kubernetes](https://kubernetes.io/docs/contribute/localization/)
+
+## Menjalankan Dokumentasi Kubernetes pada Mesin Lokal Kamu
+
+Petunjuk yang disarankan untuk menjalankan Dokumentasi Kubernetes pada mesin lokal kamus adalah dengan menggunakan [Docker](https://docker.com) **image** yang memiliki **package** [Hugo](https://gohugo.io), **Hugo** sendiri merupakan generator website statis. 
+
+> Jika kamu menggunakan Windows, kamu mungkin membutuhkan beberapa langkah tambahan untuk melakukan instalasi perangkat lunak yang dibutuhkan. Instalasi ini dapat dilakukan dengan menggunakan [Chocolatey](https://chocolatey.org). `choco install make`
+
+> Jika kamu ingin menjalankan **website** tanpa menggunakan **Docker**, kamu dapat melihat tautan berikut [Petunjuk untuk menjalankan website pada mesin lokal dengan menggunakan Hugo](#petunjuk-untuk-menjalankan-website-pada-mesin-lokal-denga-menggunakan-hugo) di bagian bawah.
+
+Jika kamu sudah memiliki **Docker** [yang sudah dapat digunakan](https://www.docker.com/get-started), kamu dapat melakukan **build** `kubernetes-hugo` **Docker image** secara lokal:
+
+```bash
+make docker-image
+```
+
+Setelah **image** berhasil di-**build**, kamu dapat menjalankan website tersebut pada mesin lokal-mu:
+
+```bash
+make docker-serve
+```
+
+Buka **browser** kamu ke http://localhost:1313 untuk melihat laman dokumentasi. Selama kamu melakukan penambahan konten, **Hugo** akan secara otomatis melakukan perubahan terhadap laman dokumentasi apabila **browser** melakukan proses **refresh**.
+
+
+## Petunjuk untuk menjalankan website pada mesin lokal dengan menggunakan Hugo
+
+Kamu dapat melihat [dokumentasi resmi Hugo](https://gohugo.io/getting-started/installing/) untuk mengetahui langkah yang diperlukan untuk melakukan instalasi **Hugo**. Pastikan kamu melakukan instalasi versi **Hugo** sesuai dengan versi yang tersedia pada **environment variable** `HUGO_VERSION` pada **file**[`netlify.toml`](netlify.toml#L9). 
+
+Untuk menjalankan laman pada mesin lokal setelah instalasi **Hugo**, kamu dapat menjalankan perintah berikut:
+
+```bash
+make serve
+```
+
+Buka **browser** kamu ke http://localhost:1313 untuk melihat laman dokumentasi. Selama kamu melakukan penambahan konten, **Hugo** akan secara otomatis melakukan perubahan terhadap laman dokumentasi apabila **browser** melakukan proses **refresh**.
+
+## Komunitas, Diskusi, Kontribusi, dan Bantuan
+
+Kamu dapat belajar bagaimana tata cara untuk ikut terlibat dalam komunitas Kubernetes melalui [laman komunitas](http://kubernetes.io/community/).
+
+Kamu dapat berinteraksi dengan **maintainers** project ini melalui:
+
+- [Slack](https://kubernetes.slack.com/messages/sig-docs)
+- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
+
+### Etika dalam Berkontribusi
+
+Partisipasi dalam komunitas Kubernetes diatur dalam [Etika dalam Berkontribusi pada Kubernetes](code-of-conduct.md).
+
+## Terima Kasih!
+
+Kubernetes sangat menjunjung tinggi partisipasi dari komunitas, dan kami sangat mengapresiasi kontribusi kamu pada laman dan dokumentasi kami!
@@ -0,0 +1,75 @@
+# Kubernetesのドキュメント
+
+[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website)
+[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
+
+ようこそ！このリポジトリには、[KubernetesのWebサイトとドキュメント](https://kubernetes.io/)をビルドするために必要な全アセットが格納されています。貢献に興味を持っていただきありがとうございます！
+
+## ドキュメントに貢献する
+
+GitHubの画面右上にある**Fork**ボタンをクリックすると、お使いのGitHubアカウントに紐付いた本リポジトリのコピーが作成され、このコピーのことを*フォーク*と呼びます。フォークリポジトリの中ではお好きなように変更を加えていただいて構いません。加えた変更をこのリポジトリに追加したい任意のタイミングにて、フォークリポジトリからPull Reqeustを作成してください。
+
+Pull Requestが作成されると、レビュー担当者が責任を持って明確かつ実用的なフィードバックを返します。
+Pull Requestの所有者は作成者であるため、**ご自身で作成したPull Requestを編集し、フィードバックに対応するのはご自身の役目です。**
+また、状況によっては2人以上のレビュアーからフィードバックが返されたり、アサインされていないレビュー担当者からのフィードバックが来ることがある点もご注意ください。
+さらに、特定のケースにおいては、レビュー担当者が[Kubernetes tech reviewer](https://github.com/kubernetes/website/wiki/Tech-reviewers)に対してレビューを依頼することもあります。
+レビュー担当者はタイムリーにフィードバックを提供するために最善を尽くしますが、応答時間は状況に応じて異なる場合があります。
+
+Kubernetesのドキュメントへの貢献に関する詳細については以下のページをご覧ください:
+
+* [貢献のはじめ方](https://kubernetes.io/docs/contribute/start/)
+* [ドキュメントの変更をステージする](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
+* [ページテンプレートの使い方](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [ドキュメントのスタイルガイド](http://kubernetes.io/docs/contribute/style/style-guide/)
+* [Kubernetesドキュメントの翻訳方法](https://kubernetes.io/docs/contribute/localization/)
+
+## Dockerを使ってローカル環境でWebサイトを動かす
+
+ローカル環境で本ページを動かすのに推奨される方法は、静的サイトジェネレータの[Hugo](https://gohugo.io)を動かすのに特化した[Docker](https://docker.com)イメージを使うことです。
+
+> Windows上で環境を作る場合は[Chocolatey](https://chocolatey.org)を使ってインストール可能な追加のツールが必要になります。 `choco install make`
+
+> Dockerを使わずに環境を構築したい場合は、[Hugoをローカル環境で動かす](#hugoをローカル環境で動かす)をご覧ください。
+
+既に[Dockerが動いている環境](https://www.docker.com/get-started)であれば、以下のコマンドを使って`kubernetes-hugo`イメージをローカルでビルドします:
+
+```bash
+make docker-image
+```
+
+イメージが作成されたら、以下のコマンドを使ってWebサイトをローカル上で動かすことができます:
+
+```bash
+make docker-serve
+```
+
+お使いのブラウザにて http://localhost:1313 にアクセスすることでWebサイトが開きます。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。
+
+## Hugoをローカル環境で動かす
+
+Hugoのインストール方法については[Hugoの公式ドキュメント](https://gohugo.io/getting-started/installing/)をご覧ください。このとき、[`netlify.toml`](netlify.toml#L9)ファイルに記述されている`HUGO_VERSION`と同じバージョンをインストールするようにしてください。
+
+Hugoがインストールできたら、以下のコマンドを使ってWebサイトをローカル上で動かすことができます:
+
+```bash
+make serve
+```
+
+これで、Hugoのサーバーが1313番ポートを使って開始します。 お使いのブラウザにて http://localhost:1313 にアクセスしてください。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。
+
+## コミュニティ内での議論、貢献、サポートなどについて
+
+[コミュニティのページ](http://kubernetes.io/community/)をご覧になることで、Kubernetesコミュニティとの関わり方を学ぶことができます。
+
+本プロジェクトのメンテナーには以下の方法で連絡することができます:
+
+- [Slack](https://kubernetes.slack.com/messages/kubernetes-docs-ja)
+- [メーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
+
+### 行動規範
+
+Kubernetesコミュニティへの参加については、[Kubernetesの行動規範](code-of-conduct.md)によって管理されています。
+
+## ありがとうございます！
+
+Kubernetesはコミュニティの参加によって成長しています。Webサイトおよびドキュメンテーションへの皆さんの貢献に感謝します！
@@ -0,0 +1,69 @@
+# 쿠버네티스 문서화
+
+[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website)
+[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
+
+환영합니다! 이 저장소는 쿠버네티스 웹사이트 및 문서화를 만드는 데 필요로 하는 모든 asset에 대한 공간을 제공합니다. 여러분이 기여를 원한다는 사실에 매우 기쁩니다!
+
+## 문서에 기여하기
+
+이 저장소에 대한 복제본을 여러분의 GitHub 계정에 생성하기 위해 화면 오른쪽 위 영역에 있는 **Fork** 버튼을 클릭 가능합니다. 이 복제본은 *fork* 라고 부릅니다. 여러분의 fork에서 원하는 임의의 변경 사항을 만들고, 해당 변경 사항을 보낼 준비가 되었다면, 여러분의 fork로 이동하여 새로운 풀 리퀘스트를 만들어 우리에게 알려주시기 바랍니다.
+
+여러분의 풀 리퀘스트가 생성된 이후에는, 쿠버네티스 리뷰어가 명료하고 실행 가능한 피드백을 제공하는 책임을 담당할 것입니다. 풀 리퀘스트의 오너로서, **쿠버네티스 리뷰어로부터 제공받은 피드백을 수용하기 위해 풀 리퀘스트를 수정하는 것은 여러분의 책임입니다.** 또한, 참고로 한 명 이상의 쿠버네티스 리뷰어가 여러분에게 피드백을 제공하는 상황에 처하거나, 또는 여러분에게 피드백을 제공하기로 원래 할당된 사람이 아닌 다른 쿠버네티스 리뷰어로부터 피드백을 받는 상황에 처할 수도 있습니다.  그뿐만 아니라, 몇몇 상황에서는, 필요에 따라 리뷰어 중 한 명이 [쿠버네티스 기술 리뷰어](https://github.com/kubernetes/website/wiki/Tech-reviewers)로부터의 기술 리뷰를 요청할지도 모릅니다. 리뷰어는 제시간에 피드백을 제공하기 위해 최선을 다할 것이지만, 응답 시간은 상황에 따라 달라질 수도 있습니다.
+
+쿠버네티스 문서화에 기여하기와 관련된 보다 자세한 정보는, 다음을 살펴봅니다:
+
+* [기여 시작하기](https://kubernetes.io/docs/contribute/start/)
+* [문서화 변경 사항 스테이징하기](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
+* [페이지 템플릿 사용하기](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [문서화 스타일 가이드](http://kubernetes.io/docs/contribute/style/style-guide/)
+* [쿠버네티스 문서화 로컬라이징](https://kubernetes.io/docs/contribute/localization/)
+
+## `README.md`에 대한 쿠버네티스 문서화 번역
+
+### 한국어
+
+`README.md` 번역 및 한국어 기여자를 위한 보다 자세한 가이드를 [한국어 README](README-ko.md) 페이지 혹은 [쿠버네티스 문서 한글화 가이드](https://kubernetes.io/ko/docs/contribute/localization_ko/)에서 살펴봅니다.
+
+한국어 번역 메인테이너에게 다음을 통해 연락 가능합니다.
+
+* 이덕준 ([GitHub - @gochist](https://github.com/gochist))
+* [Slack channel](https://kubernetes.slack.com/messages/kubernetes-docs-ko)
+
+## 도커를 사용하여 사이트를 로컬에서 실행하기
+
+쿠버네티스 웹사이트를 로컬에서 실행하기 위한 추천하는 방식은 [Hugo](https://gohugo.io) 정적 사이트 생성기를 포함하는 특별한 [도커](https://docker.com) 이미지를 실행하는 것입니다.
+
+> Windows에서 실행하는 경우, [Chocolatey](https://chocolatey.org)로 설치할 수 있는 명명 추가 도구를 필요로 할 것입니다. `choco install make`
+
+> 도커를 사용하지 않고 웹사이트를 로컬에서 실행하기를 선호하는 경우에는, 아래 [Hugo를 사용한 로컬 사이트 실행하기](#hugo를-사용한-로컬-사이트-실행하기)를 살펴봅니다.
+
+도커 [동작 및 실행](https://www.docker.com/get-started) 환경이 있는 경우, 로컬에서 `kubernetes-hugo` 도커 이미지를 빌드 합니다:
+
+```bash
+make docker-image
+```
+
+해당 이미지가 빌드 된 이후, 사이트를 로컬에서 실행할 수 있습니다:
+
+```bash
+make docker-serve
+```
+
+브라우저에서 http://localhost:1313 를 열어 사이트를 살펴봅니다. 소스 파일에 변경 사항이 있을 때, Hugo는 사이트를 업데이트하고 브라우저를 강제로 새로고침합니다.
+
+## Hugo를 사용한 로컬 사이트 실행하기
+
+Hugo 설치 안내를 위해서는 [공식 Hugo 문서화](https://gohugo.io/getting-started/installing/)를 살펴봅니다. [`netlify.toml`](netlify.toml#L9) 파일에 있는 `HUGO_VERSION` 환경 변수에서 지정된 Hugo 버전이 설치되었는지를 확인합니다.
+
+Hugo가 설치되었을 때 로컬에서 사이트를 실행하기 위해 (다음을 실행합니다):
+
+```bash
+make serve
+```
+
+이를 통해 로컬 Hugo 서버를 1313번 포트에 시작합니다. 브라우저에서 http://localhost:1313 를 열어 사이트를 살펴봅니다. 소스 파일에 변경 사항이 있을 때, Hugo는 사이트를 업데이트하고 브라우저를 강제로 새로고침합니다.
+
+## 감사합니다!
+
+쿠버네티스는 커뮤니티 참여와 함께 생존하며, 우리는 사이트 및 문서화에 대한 여러분의 컨트리뷰션에 대해 정말 감사하게 생각합니다!
@@ -0,0 +1,76 @@
+# A documentação do Kubernetes
+
+[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website)
+[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
+
+Bem vindos! Este repositório abriga todos os recursos necessários para criar o [site e documentação do Kubernetes](https://kubernetes.io/). Estamos muito satisfeitos por você querer contribuir!
+
+## Contribuindo com os documentos
+
+Você pode clicar no botão **Fork** na área superior direita da tela para criar uma cópia desse repositório na sua conta do GitHub. Esta cópia é chamada de *fork*. Faça as alterações desejadas no seu fork e, quando estiver pronto para enviar as alterações para nós, vá até o fork e crie uma nova solicitação de pull para nos informar sobre isso.
+
+Depois que seu **pull request** for criado, um revisor do Kubernetes assumirá a responsabilidade de fornecer um feedback claro e objetivo. Como proprietário do pull request, **é sua responsabilidade modificar seu pull request para abordar o feedback que foi fornecido a você pelo revisor do Kubernetes.** Observe também que você pode acabar tendo mais de um revisor do Kubernetes para fornecer seu feedback ou você pode acabar obtendo feedback de um revisor do Kubernetes que é diferente daquele originalmente designado para lhe fornecer feedback. Além disso, em alguns casos, um de seus revisores pode solicitar uma revisão técnica de um [revisor de tecnologia Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers) quando necessário. Os revisores farão o melhor para fornecer feedback em tempo hábil, mas o tempo de resposta pode variar de acordo com as circunstâncias.
+
+Para mais informações sobre como contribuir com a documentação do Kubernetes, consulte:
+
+* [Comece a contribuir](https://kubernetes.io/docs/contribute/start/)
+* [Preparando suas alterações na documentação](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
+* [Usando Modelos de Página](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [Guia de Estilo da Documentação](http://kubernetes.io/docs/contribute/style/style-guide/)
+* [Localizando documentação do Kubernetes](https://kubernetes.io/docs/contribute/localization/)
+
+Você pode contactar os mantenedores da localização em Português em:
+
+* Felipe ([GitHub - @femrtnz](https://github.com/femrtnz))
+* [Slack channel](https://kubernetes.slack.com/messages/kubernetes-docs-pt)
+
+## Executando o site localmente usando o Docker
+
+A maneira recomendada de executar o site do Kubernetes localmente é executar uma imagem especializada do [Docker](https://docker.com) que inclui o gerador de site estático [Hugo](https://gohugo.io).
+
+> Se você está rodando no Windows, você precisará de mais algumas ferramentas que você pode instalar com o [Chocolatey](https://chocolatey.org). `choco install make`
+
+> Se você preferir executar o site localmente sem o Docker, consulte [Executando o site localmente usando o Hugo](#executando-o-site-localmente-usando-o-hugo) abaixo.
+
+Se você tiver o Docker [em funcionamento](https://www.docker.com/get-started), crie a imagem do Docker do `kubernetes-hugo` localmente:
+
+```bash
+make docker-image
+```
+
+Depois que a imagem foi criada, você pode executar o site localmente:
+
+```bash
+make docker-serve
+```
+
+Abra seu navegador para http://localhost:1313 para visualizar o site. Conforme você faz alterações nos arquivos de origem, Hugo atualiza o site e força a atualização do navegador.
+
+## Executando o site localmente usando o Hugo
+
+Veja a [documentação oficial do Hugo](https://gohugo.io/getting-started/installing/) para instruções de instalação do Hugo. Certifique-se de instalar a versão do Hugo especificada pela variável de ambiente `HUGO_VERSION` no arquivo [`netlify.toml`](netlify.toml#L9).
+
+Para executar o site localmente quando você tiver o Hugo instalado:
+
+```bash
+make serve
+```
+
+Isso iniciará o servidor Hugo local na porta 1313. Abra o navegador para http://localhost:1313 para visualizar o site. Conforme você faz alterações nos arquivos de origem, Hugo atualiza o site e força a atualização do navegador.
+
+## Comunidade, discussão, contribuição e apoio
+
+Aprenda a se envolver com a comunidade do Kubernetes na [página da comunidade](http://kubernetes.io/community/).
+
+Você pode falar com os mantenedores deste projeto:
+
+- [Slack](https://kubernetes.slack.com/messages/sig-docs)
+- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
+
+### Código de conduta
+
+A participação na comunidade Kubernetes é regida pelo [Código de Conduta da Kubernetes](code-of-conduct.md).
+
+## Obrigado!
+
+O Kubernetes conta com a participação da comunidade e nós realmente agradecemos suas contribuições para o nosso site e nossa documentação!
@@ -0,0 +1,80 @@
+# Документация по Kubernetes
+
+[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website)
+[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
+
+Добро пожаловать! Данный репозиторий содержит все необходимые файлы для сборки [сайта Kubernetes и документации](https://kubernetes.io/). Мы благодарим вас за старания!
+
+## Вклад в документацию
+
+Нажмите на кнопку **Fork** в правом верхнем углу, чтобы создать копию этого репозитория в ваш GitHub-аккаунт. Это копия называется *форк-репозиторием*. Делайте любые изменения в вашем форк-репозитории, и когда вы будете готовы опубликовать изменения, откройте форк-репозиторий и создайте новый пулреквест, чтобы уведомить нас.
+
+После того, как вы отправите пулреквест, ревьювер Kubernetes даст по нему обратную связь. Вы, как автор пулреквеста, **должны обновить свой пулреквест после его рассмотрения ревьювером Kubernetes.** Вполне возможно, что более одного ревьювера Kubernetes оставят свои комментарии или даже может быть так, что новый комментарий ревьювера Kubernetes будет отличаться от первоначального назначенного ревьювера. Кроме того, в некоторых случаях один из ревьюверов может запросить технический обзор у [технического ревьювера Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers), если это будет необходимо. Ревьюверы сделают все возможное, чтобы как можно оперативно оставить свои предложения и пожелания, но время ответа может варьироваться в зависимости от обстоятельств.
+
+Узнать подробнее о том, как поучаствовать в документации Kubernetes, вы можете по ссылкам ниже:
+
+* [Начните вносить свой вклад](https://kubernetes.io/docs/contribute/start/)
+* [Просмотр локальных изменений](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
+* [Использование шаблонов страниц](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [Руководство по оформлению документации](http://kubernetes.io/docs/contribute/style/style-guide/)
+* [Руководство по локализации Kubernetes](https://kubernetes.io/docs/contribute/localization/)
+
+## `README.md` файлы на других языках
+|  |  |
+|---|---|
+|[Французский](README-fr.md)|[Корейский](README-ko.md)|
+|[Немецкий](README-de.md)|[Португальский](README-pt.md)|
+|[Хинди README](README-hi.md)|[Испанский](README-es.md)|
+|[Индонезийский](README-id.md)|[Китайский](README-zh.md)|
+|||
+
+## Запуск сайта локально с помощью Docker
+
+Рекомендованный способ запуска сайта Kubernetes на локальной машине - использовать специальный образ [Docker](https://docker.com), который включает статический генератор сайтов [Hugo](https://gohugo.io).
+
+> Если вы используете Windows, вам необходимо установить дополнительные инструменты через [Chocolatey](https://chocolatey.org). `choco install make`
+
+> Если вы хотите запустить сайт локально без Docker, обратитесь к разделу [Запуск сайта с помощью Hugo](#running-the-site-locally-using-hugo) ниже на этой странице.
+
+Когда Docker [установлен и запущен](https://www.docker.com/get-started), соберите локально Docker-образ `kubernetes-hugo`, выполнив команду в консоли:
+
+```bash
+make docker-image
+```
+
+После того, как вы собрали образ, можно запустить сайт локально:
+
+```bash
+make docker-serve
+```
+
+Откройте браузер и перейдите по ссылке http://localhost:1313, чтобы открыть сайт. Если вы редактируете исходные файлы сайта, Hugo автоматически применит изменения и обновит страницу в браузере.
+
+## Запуск веб-сайта с помощью Hugo {#running-the-site-locally-using-hugo}
+
+Обратитесь к [официальной документации Hugo](https://gohugo.io/getting-started/installing/), чтобы установить Hugo. Убедитесь, что вы установили правильную версию Hugo, которая устанавливается в переменной окружения `HUGO_VERSION` в файле [`netlify.toml`](netlify.toml#L9).
+
+После установки Hugo, чтобы запустить сайт, выполните в консоли:
+
+```bash
+make serve
+```
+
+Эта команда запустит сервер Hugo на порту 1313. Откройте браузер и перейдите по ссылке http://localhost:1313, чтобы открыть сайта. Если вы отредактируете исходные файлы сайта, Hugo автоматически применит изменения и обновит страницу в браузере.
+
+## Сообщество, обсуждение, вклад и поддержка
+
+Узнайте, как поучаствовать в жизни сообщества Kubernetes на [странице сообщества](http://kubernetes.io/community/).
+
+Вы можете связаться с сопровождающими этого проекта по:
+
+- [Канал в Slack](https://kubernetes.slack.com/messages/sig-docs)
+- [Рассылка](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
+
+### Нормы поведения
+
+Участие в сообществе Kubernetes регулируется [нормами поведения Kubernetes](code-of-conduct.md).
+
+## Спасибо!
+
+Kubernetes процветает благодаря сообществу и мы ценим ваш вклад в сайт и документацию!
@@ -0,0 +1,72 @@
+# Tài liệu Kubernetes
+
+[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website)
+[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
+
+Chào mừng! Kho lưu trữ này chứa tất cả các tài nguyên cần thiết để xây dựng [trang web của Kubernetes và các tài liệu](https://kubernetes.io/). Chúng tôi rất vui vì bạn muốn đóng góp.
+
+## Đóng góp cho tài liệu
+
+Bạn có thể click vào nút **Fork** ở góc trên bên phải màn hình để tạo bản sao của kho lưu trữ này trong tài khoản GitHub của bạn. Bản sao này được gọi là một bản *fork*. Thực hiện bất kì thay đổi nào mà bạn muốn trong bản fork của bạn và khi bạn sẵn sang gửi những thay đổi đó cho chúng tôi, hãy đến bản fork của bạn và tạo một Pull Request mới để cho chúng tôi biết về nó.
+
+Một khi Pull Request của bạn được tạo, reviewer sẽ chịu trách nhiệm cung cấp các phản hồi rõ ràng, có thể thực hiện được. Là chủ sở hữu của pull request, **bạn có trách nhiệm sửa đổi Pull Request của mình để giải quyết các phản hồi bởi reviewer.**  Ngoài ra, lưu ý rằng bạn có thể có nhiều hơn một reviewer cung cấp cho bạn các phản hồi hoặc bạn có thể nhận được phản hồi từ reviewer khác với reviewer ban đầu được chỉ định. Hơn nữa, trong một số trường hợp, một trong những reviewer của bạn có thể yêu cầu đánh giá kỹ thuật từ [Kubernetes tech reviewer](https://github.com/kubernetes/website/wiki/Tech-reviewers) khi cần. Các reviewers sẽ cố gắng hết sức để cung cấp phản hồi một cách kịp thời nhưng thời gian phản hồi có thể thay đổi tùy theo hoàn cảnh.
+
+Để biết thêm thông tin về việc đóng góp cho tài liệu Kubernetes, hãy xem:
+
+* [Bắt đầu đóng góp](https://kubernetes.io/docs/contribute/start/)
+* [Các giai đoạn thay đổi tài liệu](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
+* [Sử dụng các trang templates](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [Hướng dẫn biểu mẫu tài liệu](http://kubernetes.io/docs/contribute/style/style-guide/)
+* [Địa phương hóa tài liệu Kubernetes](https://kubernetes.io/docs/contribute/localization/)
+
+
+## Chạy website cục bộ dùng Docker
+
+Cách được đề xuất để chạy trang web Kubernetes cục bộ là dùng [Docker](https://docker.com) image chứa trình tạo web tĩnh [Hugo](https://gohugo.io).
+
+> Nếu bạn làm việc trên môi trường Windows, bạn sẽ cần thêm môt vài công cụ mà bạn có thể cài đặt với [Chocolatey](https://chocolatey.org). `choco install make`
+
+> Nếu bạn không muốn dùng Docker để chạy trang web cục bộ, hãy xem [Chạy website cục bộ dùng Hugo](#Chạy website cục bộ dùng Hugo) dưới đây.
+
+Nếu bạn có Docker đang [up và running](https://www.docker.com/get-started), build `kubernetes-hugo` Docker image cục bộ:
+
+```bash
+make docker-image
+```
+
+Khi image đã được built, bạn có thể chạy website cục bộ:
+
+```bash
+make docker-serve
+```
+
+Mở trình duyệt và đến địa chỉ http://localhost:1313 để xem website. Khi bạn thay đổi các file nguồn, Hugo cập nhật website và buộc làm mới trình duyệt.
+
+## Chạy website cục bộ dùng Hugo
+
+Hãy xem [tài liệu chính thức của Hugo](https://gohugo.io/getting-started/installing/) cho việc hướng dẫn cài đặt Hugo. Đảm bảo cài đặt phiên bản mở rộng của Hugo được xác định bởi biến môi trường `HUGO_VERSION` trong file [`netlify.toml`](netlify.toml#L9)
+
+Để chạy website cục bộ khi Hugo được cài đặt:
+
+```bash
+make serve
+```
+
+Câu lệnh trên sẽ khởi động server Hugo cục bộ trên cổng 1313. Mở trình duyệt và đến địa chỉ http://localhost:1313 để xem website. Khi bạn thay đổi các file nguồn, Hugo cập nhật website và buộc làm mới trình duyệt.
+
+## Cộng đồng, thảo luận, đóng góp và hỗ trợ
+
+Tìm hiểu cách tham gia với cộng đồng Kubernetes trên [trang cộng đồng](http://kubernetes.io/community/).
+
+Bạn có thể tiếp cận những maintainers của dự án này tại:
+
+- [Slack](https://kubernetes.slack.com/messages/sig-docs)
+- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
+
+### Quy tắc ứng xử
+
+Sự tham gia vào cộng đồng Kubernetes được điểu chỉnh bởi [Kubernetes Code of Conduct](code-of-conduct.md).
+
+## Cảm ơn!
+
+Kubernetes phát triển mạnh mẽ về sự tham gia của cộng đồng và chúng tôi đánh giá cao những đóng góp của bạn cho trang web và tài liệu của chúng tôi!
@@ -0,0 +1,182 @@
+# Kubernetes 文档
+<!--
+# The Kubernetes documentation
+ -->
+
+[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website)
+[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
+
+<!--
+Welcome! This repository houses all of the assets required to build the [Kubernetes website and documentation](https://kubernetes.io/).
+We're glad that you want to contribute!
+ -->
+欢迎！本仓库包含了所有用于构建 [Kubernetes 网站和文档](https://kubernetes.io/)的内容。
+我们非常高兴您想要参与贡献！
+
+<!--
+## Contributing to the docs
+ -->
+## 贡献文档
+
+<!--
+You can click the **Fork** button in the upper-right area of the screen to create a copy of this repository in your GitHub account.
+This copy is called a *fork*. Make any changes you want in your fork,
+and when you are ready to send those changes to us, go to your fork and create a new pull request to let us know about it.
+ -->
+您可以点击屏幕右上方的 **Fork** 按钮，在您的 GitHub 账户下创建一份本仓库的副本。这个副本叫做 *fork*。您可以对 fork 副本进行任意修改，
+当准备好把修改提交给我们时，您可以通过创建一个 pull request 来告知我们。
+
+<!--
+Once your pull request is created, a Kubernetes reviewer will take responsibility for providing clear, actionable feedback.
+As the owner of the pull request, **it is your responsibility to modify your pull request to address the feedback that has been provided to you by the Kubernetes reviewer.**
+Also, note that you may end up having more than one Kubernetes reviewer provide you feedback or you may end up getting feedback from a Kubernetes reviewer that is different than the one initially assigned to provide you feedback.
+Furthermore, in some cases, one of your reviewers might ask for a technical review from a [Kubernetes tech reviewer](https://github.com/kubernetes/website/wiki/Tech-reviewers) when needed.
+Reviewers will do their best to provide feedback in a timely fashion but response time can vary based on circumstances.
+ -->
+创建 pull request 后，Kubernetes 审核人员将负责提供清晰且可操作的反馈。作为 pull request 的所有者，**您有责任修改 pull request 以解决 Kubernetes 审核者提供给您的反馈。**
+另请注意，您最终可能会收到多个 Kubernetes 审核人员为您提供的反馈，也可能出现后面 Kubernetes 审核人员的反馈与前面审核人员的反馈不尽相同的情况。
+此外，在某些情况下，您的某位评审员可能会在需要时要求 [Kubernetes 技术评审员](https://github.com/kubernetes/website/wiki/Tech-reviewers) 进行技术评审。
+审稿人将尽最大努力及时提供反馈，但响应时间可能因情况而异。
+
+<!--
+For more information about contributing to the Kubernetes documentation, see:
+
+* [Start contributing](https://kubernetes.io/docs/contribute/start/)
+* [Staging Your Documentation Changes](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
+* [Using Page Templates](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [Documentation Style Guide](http://kubernetes.io/docs/contribute/style/style-guide/)
+* [Localizing Kubernetes Documentation](https://kubernetes.io/docs/contribute/localization/)
+ -->
+有关为 Kubernetes 文档做出贡献的更多信息，请参阅：
+
+* [开始贡献](https://kubernetes.io/docs/contribute/start/)
+* [缓存您的文档变更](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
+* [使用页面模版](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [文档风格指南](http://kubernetes.io/docs/contribute/style/style-guide/)
+* [本地化 Kubernetes 文档](https://kubernetes.io/docs/contribute/localization/)
+
+<!--
+## `README.md`'s Localizing Kubernetes Documentation
+ -->
+## `README.md` 的本地化 Kubernetes 文档
+
+<!--
+### Korean
+
+You can reach the maintainers of Korean localization at:
+
+* June Yi ([GitHub - @gochist](https://github.com/gochist))
+* [Slack channel](https://kubernetes.slack.com/messages/kubernetes-docs-ko)
+ -->
+### 中文
+
+可以通过以下方式联系中文本地化的维护人员：
+
+* Rui Chen ([GitHub - @chenrui333](https://github.com/chenrui333))
+* He Xiaolong ([GitHub - @markthink](https://github.com/markthink))
+* [Slack channel](https://kubernetes.slack.com/messages/kubernetes-docs-zh)
+
+<!--
+## Running the website locally using Docker
+ -->
+## 在本地使用 docker 运行网站
+
+<!--
+The recommended way to run the Kubernetes website locally is to run a specialized [Docker](https://docker.com) image that includes the [Hugo](https://gohugo.io) static website generator.
+ -->
+在本地运行 Kubernetes 网站的推荐方法是运行包含 [Hugo](https://gohugo.io) 静态网站生成器的专用 [Docker](https://docker.com) 镜像。
+
+<!--
+> If you are running on Windows, you'll need a few more tools which you can install with [Chocolatey](https://chocolatey.org). `choco install make`
+ -->
+> 如果您使用的是 Windows，则需要一些工具，可以使用 [Chocolatey](https://chocolatey.org) 进行安装。`choco install make`
+
+<!--
+> If you'd prefer to run the website locally without Docker, see [Running the website locally using Hugo](#running-the-site-locally-using-hugo) below.
+ -->
+> 如果您更喜欢在没有 Docker 的情况下在本地运行网站，请参阅下面的[使用 Hugo 在本地运行网站](#running-the-site-locally-using-hugo) 章节。
+
+<!--
+If you have Docker [up and running](https://www.docker.com/get-started), build the `kubernetes-hugo` Docker image locally:
+ -->
+如果您已经[安装运行](https://www.docker.com/get-started)了 Docker，使用以下命令在本地构建 `kubernetes-hugo` Docker 镜像：
+
+```bash
+make docker-image
+```
+
+<!--
+Once the image has been built, you can run the website locally:
+ -->
+一旦创建了镜像，您就可以在本地运行网站了：
+
+```bash
+make docker-serve
+```
+
+<!--
+Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.
+ -->
+打开浏览器访问 http://localhost:1313 以查看网站。当您对源文件进行更改时，Hugo 会更新网站并强制刷新浏览器。
+
+<!--
+## Running the website locally using Hugo
+ -->
+## 使用 Hugo 在本地运行网站
+
+<!--
+See the [official Hugo documentation](https://gohugo.io/getting-started/installing/) for Hugo installation instructions.
+Make sure to install the Hugo version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L9) file.
+ -->
+有关 Hugo 的安装说明，请参阅 [Hugo 官方文档](https://gohugo.io/getting-started/installing/)。
+确保安装对应版本的 Hugo，版本号由 [`netlify.toml`](netlify.toml#L9) 文件中的 `HUGO_VERSION` 环境变量指定。
+
+<!--
+To run the website locally when you have Hugo installed:
+ -->
+安装 Hugo 后，在本地运行网站：
+
+```bash
+make serve
+```
+
+<!--
+This will start the local Hugo server on port 1313. Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.
+ -->
+这将在 1313 端口上启动本地 Hugo 服务器。打开浏览器访问 http://localhost:1313 查看网站。当您对源文件进行更改时，Hugo 会更新网站并强制刷新浏览器。
+
+<!--
+## Community, discussion, contribution, and support
+ -->
+## 社区、讨论、贡献和支持
+
+<!--
+Learn how to engage with the Kubernetes community on the [community page](http://kubernetes.io/community/).
+ -->
+在[社区页面](http://kubernetes.io/community/)了解如何与 Kubernetes 社区互动。
+
+<!--
+You can reach the maintainers of this project at:
+ -->
+您可以通过以下方式联系该项目的维护人员：
+
+- [Slack](https://kubernetes.slack.com/messages/sig-docs)
+- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
+
+<!--
+### Code of conduct
+
+Participation in the Kubernetes community is governed by the [Kubernetes Code of Conduct](code-of-conduct.md).
+ -->
+### 行为准则
+
+参与 Kubernetes 社区受 [Kubernetes 行为准则](code-of-conduct.md)的约束。
+
+<!--
+## Thank you!
+
+Kubernetes thrives on community participation, and we appreciate your contributions to our website and our documentation!
+ -->
+## 感谢！
+
+Kubernetes 因为社区的参与而蓬勃发展，感谢您对我们网站和文档的贡献！
@@ -1,53 +1,82 @@
-## Instructions for Contributing to the Kubernetes Documentation
+# The Kubernetes documentation

-Welcome! We are very pleased you want to contribute to the Kubernetes documentation.
+[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website)
+[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)

-You can click the **Fork** button in the upper-right area of the screen to create a copy of this repository in your GitHub account called a *fork*. Make any changes you want in your fork, and when you are ready to send those changes to us, go to your fork and create a new pull request to let us know about it.
+Welcome! This repository houses all of the assets required to build the [Kubernetes website and documentation](https://kubernetes.io/). We're glad that you want to contribute!

-Once your pull request is created, a Kubernetes reviewer will take responsibility for providing clear, actionable feedback.  As the owner of the pull request, **it is your responsibility to modify your pull request to address the feedback that has been provided to you by the Kubernetes reviewer.**  Also note that you may end up having more than one Kubernetes reviewer provide you feedback or you may end up getting feedback from a Kubernetes reviewer that is different than the one originally assigned to provide you feedback. Furthermore, in some cases, one of your reviewers might ask for a technical review from a [Kubernetes tech reviewer](https://github.com/kubernetes/website/wiki/Tech-reviewers) when needed.  Reviewers will do their best to provide feedback in a timely fashion but response time can vary based on circumstances.
+## Contributing to the docs
+
+You can click the **Fork** button in the upper-right area of the screen to create a copy of this repository in your GitHub account. This copy is called a *fork*. Make any changes you want in your fork, and when you are ready to send those changes to us, go to your fork and create a new pull request to let us know about it.
+
+Once your pull request is created, a Kubernetes reviewer will take responsibility for providing clear, actionable feedback.  As the owner of the pull request, **it is your responsibility to modify your pull request to address the feedback that has been provided to you by the Kubernetes reviewer.**  Also, note that you may end up having more than one Kubernetes reviewer provide you feedback or you may end up getting feedback from a Kubernetes reviewer that is different than the one initially assigned to provide you feedback. Furthermore, in some cases, one of your reviewers might ask for a technical review from a [Kubernetes tech reviewer](https://github.com/kubernetes/website/wiki/Tech-reviewers) when needed.  Reviewers will do their best to provide feedback in a timely fashion but response time can vary based on circumstances.

 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/)
+* [Start contributing](https://kubernetes.io/docs/contribute/start/)
+* [Staging Your Documentation Changes](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
+* [Using Page Templates](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [Documentation Style Guide](http://kubernetes.io/docs/contribute/style/style-guide/)
+* [Localizing Kubernetes Documentation](https://kubernetes.io/docs/contribute/localization/)

-## Building the site using Docker
+## Localization `README.md`'s
+|  |  |
+|---|---|
+|[French README](README-fr.md)|[Korean README](README-ko.md)|
+|[German README](README-de.md)|[Portuguese README](README-pt.md)|
+|[Hindi README](README-hi.md)|[Spanish README](README-es.md)|
+|[Indonesian README](README-id.md)|[Chinese README](README-zh.md)|
+|[Japanese README](README-ja.md)|[Vietnamese README](README-vi.md)|
+|[Russian README](README-ru.md)|
+|||

-If you'd like, you can build the Kubernetes docs using Docker. To get started, build the image locally:
+## Running the website locally using Docker
+
+The recommended way to run the Kubernetes website locally is to run a specialized [Docker](https://docker.com) image that includes the [Hugo](https://gohugo.io) static website generator.
+
+> If you are running on Windows, you'll need a few more tools which you can install with [Chocolatey](https://chocolatey.org). `choco install make`
+
+> If you'd prefer to run the website locally without Docker, see [Running the website locally using Hugo](#running-the-site-locally-using-hugo) below.
+
+If you have Docker [up and running](https://www.docker.com/get-started), build the `kubernetes-hugo` Docker image locally:

 ```bash
-$ make docker-image
-
-# The underlying command:
-$ docker build . \
-  --tag kubernetes-hugo \
-  --build-arg HUGO_VERSION=0.40.3
+make docker-image
 ```

-You can create an image for a different version of Hugo by changing the value of the `HUGO_VERSION` argument for the build. You *must* specify a version or the image will not build.
-Once the `kubernetes-hugo` image has been built locally, you can build the site:
+Once the image has been built, you can run the website locally:

 ```bash
-$ make docker-serve
-
-# The underlying command:
-$ docker run \
-  --rm \
-  --interactive \
-  --tty \
-  --volume $(PWD):/src \
-  kubernetes-hugo:latest \
-  hugo
+make docker-serve
 ```

-As when building without using a Docker container, the results of the build will be published to the `public` directory (the default output directory for [Hugo](https://gohugo.io), the static site generator used to build this site).
+Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.
+
+## Running the website locally using Hugo
+
+See the [official Hugo documentation](https://gohugo.io/getting-started/installing/) for Hugo installation instructions. Make sure to install the Hugo extended version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L9) file.
+
+To run the website locally when you have Hugo installed:
+
+```bash
+make serve
+```
+
+This will start the local Hugo server on port 1313. Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.
+
+## Community, discussion, contribution, and support
+
+Learn how to engage with the Kubernetes community on the [community page](http://kubernetes.io/community/).
+
+You can reach the maintainers of this project at:
+
+- [Slack](https://kubernetes.slack.com/messages/sig-docs)
+- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
+
+### Code of conduct
+
+Participation in the Kubernetes community is governed by the [Kubernetes Code of Conduct](code-of-conduct.md).

 ## Thank you!

-Kubernetes thrives on community participation, and we really appreciate your
-contributions to our site and our documentation!
+Kubernetes thrives on community participation, and we appreciate your contributions to our website and our documentation!
@@ -1,15 +1,15 @@
 # Defined below are the security contacts for this repo.
 #
-# They are the contact point for the Product Security Team to reach out
+# They are the contact point for the Product Security Committee to reach out
 # to for triaging and handling of incoming issues.
 #
 # The below names agree to abide by the
-# [Embargo Policy](https://github.com/kubernetes/sig-release/blob/master/security-release-process-documentation/security-release-process.md#embargo-policy)
+# [Embargo Policy](https://git.k8s.io/security/private-distributors-list.md#embargo-policy)
 # and will be removed and replaced if they violate that agreement.
 #
 # DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE
 # INSTRUCTIONS AT https://kubernetes.io/security/

-chenopis
-jaredbhatti
+bradamant3
+jimangel
 zacharysarah
@@ -0,0 +1,302 @@
+$main-max-width: 1200px
+$vendor-strip-height: 44px
+$video-section-height: 550px
+
+@media screen and (min-width: 1025px)
+  #hamburger
+    display: none
+
+  ul.global-nav
+    display: inline-block
+
+  #docs #vendorStrip #searchBox:before
+    top: 15px
+
+  #vendorStrip
+    height: $vendor-strip-height
+    line-height: $vendor-strip-height
+
+    li
+      a.YAH
+        &:after
+          content: ""
+          display: block
+          position: absolute
+          left: 0
+          bottom: 0
+          width: 100%
+          height: 4px
+          background-color: $blue
+
+
+    #searchBox
+      float: right
+
+
+  #home
+    #hero
+      #vendorStrip
+        display: block
+
+  #docs
+    #hero
+      h1, h5
+        text-align: left
+
+      #vendorStrip
+        ul
+          float: left
+
+        #searchBox
+          float: right
+          width: 250px
+
+        #search
+          vertical-align: middle
+
+    .flyout-button
+      display: none
+
+    .logo
+      position: relative
+      float: left
+      display: block
+      width: 180px
+      height: 88px
+      top: 0
+      left: 0
+      transform: none
+      background-image: url(../images/nav_logo.svg)
+
+    &.flip-nav, &.open-nav
+      .logo
+        background-image: url(../images/nav_logo2.svg)
+
+
+  #encyclopedia
+    padding: 50px 50px 100px 100px
+    clear: both
+
+  #docsToc
+    position: relative
+    float: left
+    padding: 0 20px
+    left: 0
+    width: 350px
+    z-index: auto
+
+    .push-menu-close-button
+      display: none
+
+  #docsContent
+    width: calc(100% - 400px)
+
+    #editPageButton
+      right: -25px
+
+  section, header, footer
+    .main-section
+      max-width: $main-max-width
+
+  header, #vendorStrip, #encyclopedia, #hero h1, #hero h5, #docs #hero h1, #docs #hero h5,
+  #community #hero h1, .gridPage #hero h1, #community #hero h5, .gridPage #hero h5
+    padding-left: 100px
+    padding-right: 100px
+
+  #vendorStrip
+    padding-right: 10px
+
+  #home
+    section, header, footer
+      .main-section
+        max-width: 1000px
+
+  #oceanNodes
+    .main-section
+      position: relative
+      max-width: 830px
+
+      &:nth-child(1)
+        max-width: 1000px
+        padding-right: 475px
+
+        h3, p
+          text-align: left
+
+        .image-wrapper
+          position: absolute
+          max-width: 48%
+          transform: translateY(-50%)
+
+          img
+            width: 425px
+
+        //.content
+        //	width: 50%
+
+
+  #video
+    height: $video-section-height
+    position: relative
+    background-position: center center
+    background-size: cover
+
+
+
+  #talkToUs
+    h4
+      br
+        display: block
+
+    #bigSocial
+      div
+        width: calc(25% - 18px)
+
+      div + div
+        margin-left: 20px
+      //
+      //div:nth-child(3), div:nth-child(4)
+      //	margin-top: 0
+
+
+  //#home #bigSocial
+  //	div
+  //		width: calc(33% - 15px)
+  //
+  //	div:nth-child(3)
+  //		margin-top: inherit
+
+  // FOOTER
+  footer
+    width: 100%
+    background-image: url(../images/texture.png)
+    background-color: $dark-grey
+
+    .main-section
+      padding: 20px 0
+
+    nav
+      overflow: hidden
+      margin-bottom: 20px
+
+      a
+        width: 16.65%
+        float: left
+        font-size: 24px
+        font-weight: 300
+        white-space: nowrap
+
+    .social
+      padding: 0 30px
+      max-width: 1200px
+
+      div
+        float: left
+
+      div:last-child
+        float: right
+
+  #search, #wishField
+    background-color: transparent
+    padding: 10px
+    font-size: 16px
+    font-weight: 100
+    color: white
+    border: 1px solid white
+    transition: 0.3s
+
+    &:focus
+      background-color: $light-grey
+      color: $dark-grey
+
+  .social a
+    display: inline-block
+    background-image: url(../images/social_sprite.svg)
+    background-repeat: no-repeat
+    background-size: 350px
+    width: 50px
+    height: 50px
+    border-radius: 5px
+    margin-right: 10px
+
+    &:hover
+      background-color: #fff
+
+    span
+      position: absolute
+      display: block
+      height: 0
+      overflow: hidden
+
+  a.twitter
+    background-position: 0 0
+
+    &:hover
+      background-position: 0 100%
+
+  a.stack-overflow
+    background-position: -50px 0
+
+    &:hover
+      background-position: -50px 100%
+
+  a.slack
+    background-position: -100px 0
+
+    &:hover
+      background-position: -100px 100%
+
+  a.github
+    background-position: -150px 0
+
+    &:hover
+      background-position: -150px 100%
+
+  a.mailing-list
+    background-position: -200px 0
+
+    &:hover
+      background-position: -200px 100%
+
+  a.calendar
+    background-position: -250px 0
+
+    &:hover
+      background-position: -250px 100%
+
+  a.youtube
+    background-position: -300px 0
+
+    &:hover
+      background-position: -300px 100%
+
+  #community, .gridPage
+    #hero
+      text-align: left
+
+      h1
+        padding: 20px 100px
+
+    #tryKubernetes
+      width: auto
+      background-color: $blue
+      padding: 0 20px
+
+  #bigSocial
+    div
+      width: calc(25% - 18px)
+
+
+  #home #caseStudiesWrapper
+    div
+      width: 24%
+      min-height: 260px
+
+@media screen and (min-width: 1300px)
+  #vendorStrip
+    padding-right: 100px
+
+@media screen and (min-width: 456px)
+  #vendorStrip
+    li + li
+      margin-left: 20px
@@ -0,0 +1,61 @@
+html, body
+  margin: 0
+  padding: 0
+
+
+input, button
+  outline: none
+
+button
+  cursor: pointer
+
+ul, li
+  list-style: none
+
+ul
+  margin: 0
+  padding: 0
+	
+a
+  text-decoration: none
+
+// CONVENIENCE
+.clear
+  display: block
+  clear: both
+
+.light-text
+  color: white
+
+.right
+  float: right
+
+.left
+  float: left
+
+.center
+  text-align: center
+
+
+//mixins
+@mixin fullScreen
+  position: fixed
+  top: 0
+  left: 0
+  width: 100vw
+  height: 100vh
+
+
+@mixin pureCenter($left: 50%, $top: 50%)
+  position: absolute
+  top: $top
+  left: $left
+  transform: translate(-50%, -50%)
+
+
+@mixin maintain-aspect-ratio ($width-factor: 16, $height-factor: 9, $target-width: 80vw, $target-height: 80vh)
+  width: $target-width
+  height: $target-width * ($height-factor / $width-factor)
+  max-width: $target-height * ($width-factor / $height-factor)
+  max-height: $target-height
+
@@ -0,0 +1,86 @@
+h1
+  font-size: $h1-font-size
+  line-height: $h1-line-height
+
+h2
+  font-size: $h2-font-size
+  line-height: $h2-line-height
+
+h3
+  font-size: $h3-font-size
+  line-height: $h3-line-height
+
+h4
+  font-size: $h4-font-size
+  line-height: $h4-line-height
+
+h5
+  font-size: $h5-font-size
+  line-height: $h5-line-height
+
+p
+  font-size: $p-font-size
+  line-height: $p-line-height
+
+section, header, #vendorStrip
+  padding-left: $full-width-paddingX
+  padding-right: $full-width-paddingX
+
+  .main-section
+    width: $main-width
+    max-width: $main-max-width
+
+header
+  height: $header-height
+
+.nav-buttons
+  height: $header-height
+  line-height: $header-height
+
+  .button + *
+    margin-left: $nav-buttons-margin-left
+
+#hamburger
+  width: $hamburger-size
+  height: $hamburger-size
+
+#mainNav
+  padding: $main-nav-padding
+
+  h5
+    margin-bottom: $main-nav-h5-margin-bottom
+
+  h3
+    margin-bottom: $main-nav-h3-margin-bottom
+
+  .nav-box
+    width: $nav-box-width
+
+  .nav-box + .nav-box
+    margin-left: $nav-box-sibling-margin-left
+
+  .main-secton + .main-section
+    margin-top: $main-nav-main-sibling-margin-top
+
+  .left .button
+    height: $main-nav-left-button-size
+    line-height: $main-nav-left-button-size
+    font-size: $main-nav-left-button-font-size
+
+.open-nav, .y-enough
+  #tryKubernetes
+    margin-left: $nav-buttons-margin-left
+
+#hero
+  padding-top: $hero-padding-top
+
+#docs
+  #hero
+    h1, h5
+      padding-left: $full-width-paddingX
+      padding-right: $full-width-paddingX
+
+#vendorStrip
+  height: $vendor-strip-height
+  line-height: $vendor-strip-height
+  font-size: $vendor-strip-font-size
@@ -0,0 +1,25 @@
+$blue: #3371e3
+$light-grey: #f7f7f7
+$dark-grey: #303030
+$medium-grey: #4c4c4c
+$white: #ffffff
+
+$base-font: 'Roboto', sans-serif
+$mono-font: 'Roboto Mono', monospace
+
+
+*, .button
+  box-sizing: border-box
+  font-family: $base-font
+  background: none
+  margin: 0
+  border: 0
+
+body
+  font-family: $base-font
+
+h1, h2, h5, p
+  font-weight: 300
+
+h3, h4
+  font-weight: 400
@@ -0,0 +1,248 @@
+// TEXT
+//$h1-font-size: 60px
+//$h1-line-height: 80px
+//
+//$h2-font-size: 42px
+//$h2-line-height: 60px
+//
+//$h3-font-size: 26px
+//$h3-line-height: 32px
+//
+//$h4-font-size: 26px
+//$h4-line-height: 40px
+//
+//$h5-font-size: 18px
+//$h5-line-height: 36px
+//
+//$p-font-size: 20px
+//$p-line-height: 28px
+
+
+// header
+$full-width-paddingX: 20px
+
+$main-width: 100%
+$main-max-width: 100%
+
+$header-height: 80px
+
+$logo-width: 180px
+
+$nav-buttons-margin-left: 30px
+
+$hamburger-size: 50px
+
+
+// main nav
+$main-nav-padding: 140px 0 30px
+$main-nav-h5-margin-bottom: 1em
+$main-nav-h3-margin-bottom: 0.6em
+$nav-box-width: 20%
+$nav-box-sibling-margin-left: calc(20% / 3)
+$main-nav-main-sibling-margin-top: 60px
+$main-nav-left-button-size: 50px
+$main-nav-left-button-font-size: 18px
+
+
+// hero
+$hero-padding-top: 80px
+$headline-wrapper-margin-bottom: 40px
+$quickstart-button-padding: 0 50px
+$vendor-strip-font-size: 16px
+
+//video
+$video-section-height: 400px
+
+//features
+$features-h3-margin-bottom: 40px
+$feature-box-margin-bottom: 60px
+$feature-box-div-margin-bottom: 0
+$feature-box-div-width: 45%
+
+
+
+////////////////////////////////////////////////////////////////////////////////////////////////////
+////////////////////////////////////////////////////////////////////////////////////////////////////
+////////////////////////////////////////////////////////////////////////////////////////////////////
+
+@media screen and (min-width: 750px)
+  @import "size"
+
+  p
+    font-size: 16px
+    line-height: 24px
+    letter-spacing: 0.1px
+
+  h1
+    font-size: 36px
+    line-height: 44px
+
+  h3
+    font-size: 28px
+    line-height: 36px
+
+  h4
+    font-size: 24px
+    line-height: 40px
+
+
+
+  #home
+    #viewDocs, #tryKubernetes
+      display: inline-block
+
+  #vendorStrip
+    display: block
+    text-align: center
+
+    img
+      max-height: 24px
+      vertical-align: middle
+      margin: 0 30px
+
+  #docs
+    #vendorStrip
+      li
+        a
+          font-size: 1em
+          font-weight: normal
+
+        li + li
+          margin-left: 60px
+
+
+  #oceanNodes
+    h3
+      text-align: left
+      margin-bottom: 18px
+
+    main, .main-section
+      position: relative
+      clear: both
+      display: table
+      height: 160px
+
+      .content
+        display: table-cell
+        position: relative
+        vertical-align: middle
+
+      .image-wrapper
+        position: absolute
+        top: 50%
+        max-width: 25%
+        max-height: 100%
+        transform: translateY(-50%)
+
+      &:nth-child(odd)
+        padding-right: 210px
+
+        .image-wrapper
+          right: 0
+
+      &:nth-child(even)
+        padding-left: 210px
+
+        .image-wrapper
+          left: 0
+
+      &:nth-child(1)
+        padding-right: 0
+
+        h3, p
+          text-align: center
+
+        .image-wrapper
+          position: relative
+          display: block
+          float: none
+          max-width: 100%
+          transform: none
+
+        .content
+          display: block
+
+      img
+        width: 100%
+
+
+  #video
+    height: $video-section-height
+    display: block
+
+    & > .light-text
+      display: block
+
+  #mobileShowVideoButton
+    display: none
+
+  #features
+    padding-bottom: 60px
+
+    .feature-box
+      margin-bottom: 30px
+
+      &:last-child
+        margin-bottom: 0
+
+    h3
+      margin-bottom: $features-h3-margin-bottom
+
+    .feature-box
+      & > div
+        width: $feature-box-div-width
+        margin-bottom: $feature-box-div-margin-bottom
+
+  #talkToUs
+    #bigSocial
+      div
+        width: calc(50% - 15px)
+
+      div + div
+        margin-top: 0
+
+      div:nth-child(2)
+        margin-left: 20px
+
+      div:nth-child(3)
+
+      div:nth-child(4)
+        margin-left: 20px
+
+      a
+        display: inline-block
+        color: $blue
+        font-weight: 400
+        text-decoration: none
+
+  // FOOTER
+  footer
+    nav
+      text-align: center
+
+      a
+        width: 30%
+        padding: 0 20px
+
+    .social
+      text-align: center
+
+      div
+        display: inline-block
+
+      div:last-child
+        display: block
+        margin: 0
+
+      span
+        display: inline-block
+        margin-right: 10px
+
+      input
+        text-align: left
+
+
+
+  #home #caseStudiesWrapper
+    div
+      width: 48%
@@ -0,0 +1,11 @@
+@import "reset"
+@import "skin"
+
+// media queries
+@import "base"
+@import "tablet"
+@import "desktop"
+
+{{ if .Params.case_study_styles }}
+@import "case-studies"
+{{ end }}
@@ -4,10 +4,11 @@ title = "Kubernetes"
 defaultContentLanguage = "en"
 defaultContentLanguageInSubdir = false
 enableRobotsTXT = true
+disableBrowserError = true

 disableKinds = ["taxonomy", "taxonomyTerm"]

-ignoreFiles = [ "^OWNERS$", "README.md", "^node_modules$" ]
+ignoreFiles = [ "^OWNERS$", "README[-]+[a-z]*\\.md", "^node_modules$", "content/en/docs/doc-contributor-tools" ]

 contentDir = "content/en"

@@ -19,6 +20,14 @@ pygmentsUseClasses = false
 # See https://help.farbox.com/pygments.html
 pygmentsStyle = "emacs"

+# Enable Git variables like commit, lastmod
+enableGitInfo = true
+
+# Norwegian ("no") is sometimes but not currently used for testing.
+# Hindi is disabled because it's currently in development.
+# Italian is disabled until it meets minimum standards for quality.
+disableLanguages = ["hi", "it", "no"]
+
 [blackfriday]
 hrefTargetBlank = true
 fractions = false
@@ -27,71 +36,98 @@ fractions = false
 date = ["date", ":filename", "publishDate", "lastmod"]

 [permalinks]
-  blog = "/:section/:year/:month/:day/:slug/"
+blog = "/:section/:year/:month/:day/:slug/"

 # Be explicit about the output formats. We (currently) only want an RSS feed for the home page.
 [outputs]
-home = [ "HTML", "RSS"]
+home = [ "HTML", "RSS", "HEADERS" ]
 page = [ "HTML"]
 section = [ "HTML"]

+# Add a "text/netlify" media type for auto-generating the _headers file
+[mediaTypes]
+[mediaTypes."text/netlify"]
+delimiter = ""
+
 [outputFormats]
 [outputFormats.RSS]
 baseName = "feed"

+# _headers file output (uses the template at layouts/index.headers)
+[outputFormats.HEADERS]
+mediatype = "text/netlify"
+baseName = "_headers"
+isPlainText = true
+notAlternative = true
+
 [params]

 time_format_blog = "Monday, January 02, 2006"
 description = "Production-Grade Container Orchestration"
 showedit = true

-latest = "v1.10"
+latest = "v1.17"

-fullversion = "v1.10.3"
-version = "v1.10"
+fullversion = "v1.17.0"
+version = "v1.17"
 githubbranch = "master"
 docsbranch = "master"
 deprecated = false
 currentUrl = "https://kubernetes.io/docs/home/"
-nextUrl = "http://kubernetes-io-vnext-staging.netlify.com/"
+nextUrl = "https://kubernetes-io-vnext-staging.netlify.com/"
 githubWebsiteRepo = "github.com/kubernetes/website"
 githubWebsiteRaw = "raw.githubusercontent.com/kubernetes/website"

+# param for displaying an announcement block on every page; see PR #16210
+announcement = false
+# announcement_message is only displayed when announcement = true; update with your specific message
+announcement_message = "The Kubernetes Documentation team would like your feedback!  Please take a <a href='https://www.surveymonkey.com/r/8R237FN' target='_blank'>short survey</a> so we can improve the Kubernetes online documentation."
+
 [[params.versions]]
-fullversion = "v1.10.3"
-version = "v1.10"
-githubbranch = "v1.10.3"
-docsbranch = "release-1.10"
+fullversion = "v1.17.0"
+version = "v1.17"
+githubbranch = "v1.17.0"
+docsbranch = "release-1.17"
 url = "https://kubernetes.io"

-[[params.versions]]
-fullversion = "v1.9.7"
-version = "v1.9"
-githubbranch = "v1.9.7"
-docsbranch = "release-1.9"
-url = "https://v1-9.docs.kubernetes.io"
+[params.pushAssets]
+css = [
+  "callouts",
+  "styles",
+  "custom-jekyll/tags"
+]
+js = [
+  "custom-jekyll/tags",
+  "script"
+]

 [[params.versions]]
-fullversion = "v1.8.4"
-version = "v1.8"
-githubbranch = "v1.8.4"
-docsbranch = "release-1.8"
-url = "https://v1-8.docs.kubernetes.io"
+fullversion = "v1.16.3"
+version = "v1.16"
+githubbranch = "v1.16.3"
+docsbranch = "release-1.16"
+url = "https://v1-16.docs.kubernetes.io"

 [[params.versions]]
-fullversion = "v1.7.6"
-version = "v1.7"
-githubbranch = "v1.7.6"
-docsbranch = "release-1.7"
-url = "https://v1-7.docs.kubernetes.io"
+fullversion = "v1.15.6"
+version = "v1.15"
+githubbranch = "v1.15.6"
+docsbranch = "release-1.15"
+url = "https://v1-15.docs.kubernetes.io"

 [[params.versions]]
-fullversion = "v1.6.8"
-version = "v1.6"
-githubbranch = "v1.6.8"
-docsbranch = "release-1.6"
-url = "https://v1-6.docs.kubernetes.io"
+fullversion = "v1.14.9"
+version = "v1.14"
+githubbranch = "v1.14.9"
+docsbranch = "release-1.14"
+url = "https://v1-14.docs.kubernetes.io"

+[[params.versions]]
+fullversion = "v1.13.12"
+version = "v1.13"
+githubbranch = "v1.13.12"
+docsbranch = "release-1.13"
+url = "https://v1-13.docs.kubernetes.io"

 # Language definitions.

@@ -102,11 +138,151 @@ description = "Production-Grade Container Orchestration"
 languageName ="English"
 # Weight used for sorting.
 weight = 1
-[languages.cn]
+
+[languages.zh]
 title = "Kubernetes"
 description = "Production-Grade Container Orchestration"
-languageName ="Chinese"
+languageName = "中文 Chinese"
 weight = 2
-contentDir = "content/cn"
+contentDir = "content/zh"

+[languages.zh.params]
+time_format_blog = "2006.01.02"
+language_alternatives = ["en"]
+
+[languages.ko]
+title = "Kubernetes"
+description = "Production-Grade Container Orchestration"
+languageName = "한국어 Korean"
+weight = 3
+contentDir = "content/ko"
+
+[languages.ko.params]
+time_format_blog = "2006.01.02"
+language_alternatives = ["en"]
+
+[languages.ja]
+title = "Kubernetes"
+description = "Production-Grade Container Orchestration"
+languageName = "日本語 Japanese"
+weight = 4
+contentDir = "content/ja"
+
+[languages.ja.params]
+time_format_blog = "2006.01.02"
+language_alternatives = ["en"]
+
+[languages.fr]
+title = "Kubernetes"
+description = "Production-Grade Container Orchestration"
+languageName ="Français"
+weight = 5
+contentDir = "content/fr"
+
+[languages.fr.params]
+time_format_blog = "02.01.2006"
+# A list of language codes to look for untranslated content, ordered from left to right.
+language_alternatives = ["en"]
+
+[languages.it]
+title = "Kubernetes"
+description = "Production-Grade Container Orchestration"
+languageName ="Italian"
+weight = 6
+contentDir = "content/it"
+
+[languages.it.params]
+time_format_blog = "02.01.2006"
+# A list of language codes to look for untranslated content, ordered from left to right.
+language_alternatives = ["en"]
+
+[languages.no]
+title = "Kubernetes"
+description = "Production-Grade Container Orchestration"
+languageName ="Norsk"
+weight = 7
+contentDir = "content/no"
+
+[languages.no.params]
+time_format_blog = "02.01.2006"
+# A list of language codes to look for untranslated content, ordered from left to right.
+language_alternatives = ["en"]
+
+[languages.de]
+title = "Kubernetes"
+description = "Production-Grade Container Orchestration"
+languageName ="Deutsch"
+weight = 8
+contentDir = "content/de"
+
+[languages.de.params]
+time_format_blog = "02.01.2006"
+# A list of language codes to look for untranslated content, ordered from left to right.
+language_alternatives = ["en"]
+
+[languages.es]
+title = "Kubernetes"
+description = "Production-Grade Container Orchestration"
+languageName ="Español"
+weight = 9
+contentDir = "content/es"
+
+[languages.es.params]
+time_format_blog = "02.01.2006"
+# A list of language codes to look for untranslated content, ordered from left to right.
+language_alternatives = ["en"]
+
+[languages.pt]
+title = "Kubernetes"
+description = "Orquestração de contêineres em nível de produção"
+languageName ="Português"
+weight = 9
+contentDir = "content/pt"
+
+[languages.pt.params]
+time_format_blog = "02.01.2006"
+# A list of language codes to look for untranslated content, ordered from left to right.
+language_alternatives = ["en"]
+
+[languages.id]
+title = "Kubernetes"
+description = "Production-Grade Container Orchestration"
+languageName ="Bahasa Indonesia"
+weight = 10
+contentDir = "content/id"
+
+[languages.id.params]
+time_format_blog = "02.01.2006"
+# A list of language codes to look for untranslated content, ordered from left to right.
+language_alternatives = ["en"]
+
+[languages.hi]
+title = "Kubernetes"
+description = "Production-Grade Container Orchestration"
+languageName = "Hindi"
+weight = 11
+contentDir = "content/hi"
+
+[languages.hi.params]
+time_format_blog = "01.02.2006"
+language_alternatives = ["en"]
+
+[languages.vi]
+title = "Kubernetes"
+description = "Production-Grade Container Orchestration"
+languageName = "Vietnamese"
+contentDir = "content/vi"
+weight = 12
+
+[languages.ru]
+title = "Kubernetes"
+description = "Production-Grade Container Orchestration"
+languageName = "Русский"
+weight = 12
+contentDir = "content/ru"
+
+[languages.ru.params]
+time_format_blog = "02.01.2006"
+# A list of language codes to look for untranslated content, ordered from left to right.
+language_alternatives = ["en"]

@@ -1,153 +0,0 @@
---
-title: "生产级别的容器编排系统"
-abstract: "自动化的容器部署、扩展和管理"
-cid: "home"
---
-
-<section id="oceanNodes">
-    <main>
-        <div class="image-wrapper"><img src="/images/flower.png"></div>
-        <div class="content">
-            
-            <h3><a href="/docs/concepts/overview/what-is-kubernetes/">Kubernetes</a> 是用于自动部署，扩展和管理容器化应用程序的开源系统。</h3>
-            <p>它将组成应用程序的容器组合成逻辑单元，以便于管理和服务发现，Kubernetes 构建在 <a href="http://queue.acm.org/detail.cfm?id=2898444"> Google 15 年生产环境经验</a>基础之上,并结合来自社区的最佳创意和实践。</p>
-        </div>
-    </main>
-    <main>
-        <div class="image-wrapper"><img src="/images/scalable.png"></div>
-        <div class="content">
-            
-            <h4>星际尺度</h4>
-            <p>根据同样的原则设计，允许 Google 每周运行数十亿个容器，Kubernetes 可以在不增加您的 ops 团队的情况下进行弹性扩展。</p>
-        </div>
-    </main>
-    <main>
-        <div class="image-wrapper"><img src="/images/blocks.png"></div>
-        <div class="content">
-            
-            <h4>永不过时</h4>
-            <p>无论您应用运行在本地还是运行于全球任何地域，Kubernetes 的灵活性都可以随着您的需求复杂度不断增加，还可以持续、轻松地对外提供服务。</p>
-        </div>
-    </main>
-    <main>
-        <div class="image-wrapper"><img src="/images/suitcase.png"></div>
-        <div class="content">
-            
-            <h4>随处运行</h4>
-            <p>Kubernetes 是开源的，可以让您自由地部署在企业内部，私有云、混合云或公有云基础架构，使您轻松将应用迁移至任何位置。</p>
-        </div>
-    </main>
-</section>
-<section id="video">
-    <div class="light-text">
-        
-        <h2>Kubernetes: 最后&hellip; 它是真正的云平台</h2>
-        <p>Box 的联合创始人和服务架构师 Sam Ghods 发表了热情洋溢的演讲，随着使用 Kubernetes，我们首次有一个通用接口，可以建立真正的部署工具。</p>
-        <button id="desktopShowVideoButton" onclick="kub.showVideo()">观看视频</button>
-    </div>
-    <button id="mobileShowVideoButton" onclick="kub.showVideo()"></button>
-</section>
-<section id="features">
-    <main>
-        
-        <h3 class="center">Kubernetes 特性</h3>
-        <div class="feature-box">
-            <div>
-                
-                <h4><a href="/docs/concepts/configuration/manage-compute-resources-container/">自动包装</a></h4>
-                <p>根据资源需求和其他约束自动放置容器，同时不会牺牲可用性，混合关键和最大努力的工作负载，以提高资源利用率并节省更多资源。</p>
-            </div>
-            <div>
-                
-                <h4><a href="/docs/concepts/workloads/controllers/replicationcontroller/#what-is-a-replicationcontroller">自我修复</a></h4>
-                <p>重新启动失败的容器，在节点不可用时，替换和重新编排节点上的容器，终止不对用户定义的健康检查做出响应的容器，并且不会在客户端准备投放之前将其通告给客户端。</p>
-            </div>
-        </div>
-        <div class="feature-box">
-            <div>
-                
-                <h4><a href="/docs/tasks/run-application/horizontal-pod-autoscale/">横向缩放</a></h4>
-                <p>使用简单的命令或 UI，或者根据 CPU 的使用情况自动调整应用程序副本数。</p>
-            </div>
-            <div>
-                
-                <h4><a href="/docs/concepts/services-networking/service/">服务发现和负载均衡</a></h4>
-                <p>不需要修改您的应用程序来使用不熟悉的服务发现机制，Kubernetes 为容器提供了自己的 IP 地址和一组容器的单个 DNS 名称，并可以在它们之间进行负载均衡。</p>
-            </div>
-        </div>
-        <div class="feature-box">
-            <div>
-                
-                <h4><a href="/docs/concepts/workloads/controllers/deployment/#what-is-a-deployment">自动部署和回滚</a></h4>
-                <p>Kubernetes 逐渐部署对应用程序或其配置的更改，同时监视应用程序运行状况，以确保它不会同时终止所有实例。 如果出现问题，Kubernetes会为您恢复更改，利用日益增长的部署解决方案的生态系统。</p>
-            </div>
-            <div>
-                <h4><a href="/docs/concepts/configuration/secret/">密钥</a> 和 <a href="/docs/tasks/configure-pod-container/configure-pod-configmap/">配置</a> 管理</h4>
-                <p>部署和更新密钥和应用程序配置，不会重新编译您的镜像，不会在堆栈配置中暴露密钥(secrets)。</p>
-            </div>
-        </div>
-        <div class="feature-box">
-            <div>
-                <h4><a href="/docs/concepts/storage/persistent-volumes/">存储编排</a></h4>
-                <p>自动安装您所选择的存储系统，无论是本地存储，如公有云提供商 <a href="https://cloud.google.com/storage/">GCP</a> 或 <a href="https://aws.amazon.com/products/storage/">AWS</a>, 还是网络存储系统 NFS, iSCSI,
-            Gluster, Ceph, Cinder, 或 Flocker。</p>
-        </div>
-        <div>
-            <h4><a href="/docs/concepts/workloads/controllers/jobs-run-to-completion/">批处理</a></h4>
-            <p>除了服务之外，Kubernetes还可以管理您的批处理和 CI 工作负载，如果需要，替换出现故障的容器。</p>
-        </div>
-    </div>
-</main>
-</section>
-<section id="talkToUs">
-<main>
-    
-    <h3>实例探究</h3>
-    <div id="caseStudiesWrapper">
-        <div>
-            <p>使用Kubernetes来重塑世界上最大的教育公司</p>
-            <a href="/case-studies/pearson/">阅读更多</a>
-        </div>
-        <div>
-            <p>Kubernetes at Box: 微服务的最大优势</p>
-            <a href="https://blog.box.com/blog/kubernetes-box-microservices-maximum-velocity/">阅读更多</a>
-        </div>
-        <div>
-            <p>在 eBay 内部转移到 OpenStack 上的 Kubernetes 和容器</p>
-            <a href="https://www.nextplatform.com/2015/11/12/inside-ebays-shift-to-kubernetes-and-containers-atop-openstack/">阅读更多</a>
-        </div>
-        <div>
-            <p>将本地的集群迁移至 Kubernetes</p>
-            <a href="https://www.youtube.com/watch?v=6XGUTu3WhBw">观看视频</a>
-        </div>
-    </div>
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    <h5 style="text-align: center"><a href="/case-studies/" style="color: #3371E3; font-weight: 400">探究所有的案例</a></h5>
-</main>
-</section>
-<div id="videoPlayer">
-<iframe data-url="https://www.youtube.com/embed/of45hYbkIZs?autoplay=1" frameborder="0" allowfullscreen></iframe>
-<button id="closeButton"></button>
-</div>
@@ -1,4 +0,0 @@
---
-title: Home
-weight: 5
---
@@ -1,135 +0,0 @@
---
-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，其他（厂商的）集群设置方法各不相同。
@@ -1,156 +0,0 @@
---
-approvers:
- erictune
- lavalamp
- deads2k
- liggitt
-title: 概述
-content_template: templates/concept
---
-
-{{% capture overview %}}
-
-学习有关 Kubernetes 授权的更多信息，包括有关使用支持的授权模块创建策略的详细信息。
-
-{{% /capture %}}
-
-{{% 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 授权模块处于启用状态。但是，其输入文件最初设置为允许所有用户执行所有操作，集群管理员需要编辑该文件，或者配置不同的授权器来限制用户可以执行的操作。
-
-{{% /capture %}}
-{{% capture whatsnext %}}
-
-* 要学习有关身份验证的更多信息，请参阅**身份验证**[控制访问 Kubernetes API](docs/admin/access-the-api/)。
-* 要了解有关入学管理的更多信息，请参阅[使用 Admission 控制器](docs/admin/admission-controllers/)。
-*
-{{% /capture %}}
-
-
@@ -1,18 +0,0 @@
-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
@@ -1,214 +0,0 @@
---
-title: 构建高可用集群
---
-
-
-## 简介
-
-
-本文描述了如何构建一个高可用（high-availability, HA）的Kubernetes集群。这是一个非常高级的主题。
-
-对于仅希望使用Kubernetes进行试验的用户，推荐使用更简单的配置工具进行搭建，例如：
-[Minikube](/docs/getting-started-guides/minikube/)，或者尝试使用[Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) 来运行Kubernetes。
-
-此外，当前在我们的端到端（e2e）测试环境中，没有对Kubernetes高可用的支持进行连续测试。我们将会增加这个连续测试项，但当前对单节点master的安装测试得更加严格。
-
-{{< 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/{{< param "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。
@@ -1,229 +0,0 @@
---
-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中保存密钥。
-
-      --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
@@ -1,22 +0,0 @@
---
-approvers:
- 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网桥到达目标。
-
-
-
-
@@ -1,248 +0,0 @@
-title: 云控制器管理器的基本概念
-
-## 云控制器管理器
-
-云控制器管理器（CCM）这个概念创建的初衷是为了让特定的云服务供应商代码和Kubernetes核心相互独立演化。云控制器管理器与其他主要组件如Kubernetes控制器管理器，API服务器和调度程序同时运行。云控制器管理器也可以作为Kubernetes的插件启动，这种情况下，CCM运行在Kubernetes系统之上。
-
-云控制器管理器基于插件机制设计，允许新的云服务供应商通过插件轻松地与Kubernetes集成。目前已经有在Kubernetes上加入新的云服务供应商计划，并为云服务供应商提供从原先的旧模式迁移到新CCM模式的方案。
-
-本文讨论了云控制器管理器背后的概念，并提供了相关功能的详细信息。
-
-下面这张图描述了没有云控制器管理器的Kubernetes集群架构：
-
-![无云控制器管理器的 K8s 集群架构](/images/docs/pre-ccm-arch.png)
-
-## 设计
-
-在上图中，Kubernetes和云服务供应商通过几个不同的组件进行了集成，分别是：
-
-* Kubelet
-* Kubernetes 控制管理器
-* Kubernetes API服务器
-
-而CCM整合了前三个组件中的所有依赖于云的逻辑，用来创建与云的单点集成。新架构如下图所示：
-
-![有云控制器管理器的 K8s 集群架构](/images/docs/post-ccm-arch.png)
-
-## CCM的组件
-
-CCM突破了Kubernetes控制器管理器（KCM）的一些功能，并将其作为一个独立的进程运行。具体而言，它打破了KCM中与云相关的控制器。KCM具有以下依赖于云的控制器引擎：
-
-* 节点控制器
-* 卷控制器
-* 路由控制器
-* 服务控制器
-
-在1.8版本中，当前运行中的CCM从上面的列表中运行以下控制器：
-
-* 节点控制器
-* 路由控制器
-* 服务控制器
-
-另外，它运行另一个名为 PersistentVolumeLabels Controller 的控制器。这个控制器负责对在GCP和AWS云里创建的PersistentVolumes的域（Zone）和区（Region）标签进行设置。
-
-**注意**：卷控制器被特意设计为CCM之外的一部分。由于其中涉及到的复杂性和对现有供应商特定卷的逻辑抽象，因此决定了卷控制器不会被移动到CCM之中。
-
-原本计划使用CCM来支持卷的目的是为了引入FlexVolume卷来支持可插拔卷。然而，官方正在计划使用更具备竞争力的CSI来取代FlexVolume卷。
-
-考虑到这些正在进行中的变化，我们决定暂时停止当前工作直至CSI准备就绪。
-
-云服务供应商工作组（wg-cloud-provider）正在开展相关工作，以实现通过CCM支持PersistentVolume的功能。详细信息请参见[kubernetes/kubernetes＃52371](https://github.com/kubernetes/kubernetes/pull/52371)。
-
-## CCM功能
-
-CCM从Kubernetes组件中继承了与云服务供应商相关的功能。本节基于被CCM继承其功能的组件展开描述。
-
-### 1. Kubernetes 控制器管理器
-
-CCM的大部分功能都来自KCM。 如上一节所述，CCM运行以下控制引擎：
-
-* 节点控制器
-* 路由控制器
-* 服务控制器
-* PersistentVolumeLabels控制器
-
-#### 节点控制器
-
-节点控制器负责通过从云服务供应商获得有关在集群中运行的节点的信息来初始化节点。节点控制器执行以下功能：
-
-1.使用云特定域（Zone）/区（Region）标签初始化节点。
-
-1.使用特定于云的实例详细信息初始化节点，例如类型和大小。
-
-1.获取节点的网络地址和主机名。
-
-1.如果节点无响应，检查该节点是否已从云中删除。如果该节点已从云中删除，则删除Kubernetes节点对象。
-
-#### 路由控制器
-
-路由控制器负责为云配置正确的路由，以便Kubernetes集群中不同节点上的容器可以相互通信。路由控制器仅适用于Google Compute Engine平台。
-
-#### 服务控制器
-
-服务控制器负责监听服务的创建、更新和删除事件。根据Kubernetes中各个服务的当前状态，它将配置云负载平衡器（如ELB或Google LB）以反映Kubernetes中的服务状态。此外，它还确保云负载均衡器的服务后端保持最新。
-
-#### PersistentVolumeLabels 控制器
-
-PersistentVolumeLabels控制器在AWS的EBS卷、GCE的PD卷创建时申请标签，这使得用户不再需要手动设置这些卷标签。
-
-这些标签对于pod的调度工作是非常重要的，因为这些卷只能在它们所在的域（Zone）/区（Region）内工作，因此所有使用这些卷的pod都必须要在同一个域/区中才能保证进行调度正常进行。
-
-PersistentVolumeLabels控制器是专门为CCM创建的; 也就是说，在CCM创建之前它是不存在的。这样做是为了将Kubernetes API服务器（它是一个许可控制器）中的PV标签逻辑移动到CCM。 它不在KCM上运行。
-
-### 2. Kubelet
-
-Node控制器包含kubelet中依赖于云的功能。在系统引入CCM组件之前，是由kubelet采用包含云特定信息的方式对节点进行初始化，如IP地址、区（Region）/域（Zone）标签和实例类型信息；引入CCM之后，这部分的初始化操作就从kubelet转移到了CCM中。
-
-在引入CCM后的新的模型中，kubelet采用不包含云特定信息的方式初始化一个节点。但是，它会为新创建的节点添加一个污点，使得该节点不可被立即调度，直到CCM使用包含云的特定信息初始化节点后，才会删除该污点，使得该节点可被调度。
-
-### 3. Kubernetes API服务器
-
-PersistentVolumeLabels控制器将Kubernetes API服务器的依赖于云的功能移至CCM，如前面部分所述。
-
-## 插件机制
-
-云控制器管理器使用Go接口与外部对接从而实现功能扩展。具体来说，它使用了[这里](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go)定义的CloudProvider接口。
-
-上面强调的四个共享控制器的实现，以及一些辅助设施（scaffolding）和共享的云服务供应商接口，将被保留在Kubernetes核心当中。但云服务供应商特有的实现将会建立在核心之外，并实现核心中定义的接口。
-
-有关开发插件的更多信息，请参阅
-[开发云控制器管理器](/docs/tasks/administrators-cluster/developing-cloud-controller-manager/)。
-
-## 授权
-
-本节分解了CCM对各种API对象的访问，以执行其操作。
-
-### 节点控制器
-
-节点控制器仅适用于节点对象。它需要完全访问权限来获取、列出、创建、更新、修补、监视和删除节点对象。
-
-v1/Node: 
- Get
- List
- Create
- Update
- Patch
- Watch
-
-### 路由控制器
-
-路由控制器监听节点对象的创建并配置合适的路由。它需要对节点对象的访问权限。
-
-v1/Node: 
- Get
-
-### 服务控制器
-
-服务控制器侦听服务对象创建、更新和删除事件，然后对这些服务的端点进行恰当的配置。
-
-要访问服务，它需要罗列和监控权限。要更新服务，它需要修补和更新权限。
-
-要为服务设置端点，需要访问创建、列表、获取、监视和更新。
-
-v1/Service:
- List
- Get
- Watch
- Patch
- Update
-
-### PersistentVolumeLabels 控制器
-
-PersistentVolumeLabels控制器监听PersistentVolume（PV）创建事件并更新它们。该控制器需要访问列表、查看、获取和更新PV的权限。
-
-v1/PersistentVolume:
- Get
- List
- Watch
- Update
-
-### 其它
-
-CCM核心的实现需要创建事件的权限，为了确保安全操作，需要创建ServiceAccounts的权限。
-
-v1/Event:
- Create
- Patch
- Update
-
-v1/ServiceAccount:
- Create
-
-针对CCM的RBAC ClusterRole如下所示：
-
-```yaml
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
-  name: cloud-controller-manager
-rules:
- apiGroups:
-  - ""
-  resources:
-  - events
-  verbs:
-  - create
-  - patch
-  - update
- apiGroups:
-  - ""
-  resources:
-  - nodes
-  verbs:
-  - '*'
- apiGroups:
-  - ""
-  resources:
-  - nodes/status
-  verbs:
-  - patch
- apiGroups:
-  - ""
-  resources:
-  - services
-  verbs:
-  - list
-  - patch
-  - update
-  - watch
- apiGroups:
-  - ""
-  resources:
-  - serviceaccounts
-  verbs:
-  - create
- apiGroups:
-  - ""
-  resources:
-  - persistentvolumes
-  verbs:
-  - get
-  - list
-  - update
-  - watch
- apiGroups:
-  - ""
-  resources:
-  - endpoints
-  verbs:
-  - create
-  - get
-  - list
-  - watch
-  - update
-```
-
-## 供应商实施
-
-以下云服务供应商为自己的云部署了CCM。
-
-* [Digital Ocean]()
-* [Oracle]()
-* [Azure]()
-* [GCE]()
-* [AWS]()
-
-## 群集管理
-
-[这里](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)提供了配置和运行CCM的完整说明。
@@ -1,70 +0,0 @@
---
-approvers:
- dchen1107
- roberthbailey
- liggitt
-
-title: Master 节点通信
---
-
-{{< 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 Kubernetes Engine](https://cloud.google.com/kubernetes-engine/docs/) 使用 SSH 隧道保护 Master -> Cluster 通信路径。在这种配置下，apiserver 发起一个到集群中每个节点的 SSH 隧道（连接到在 22 端口监听的 ssh 服务）并通过这个隧道传输所有到 kubelet、node、pod 或者 service 的流量。这个隧道保证流量不会在集群运行的私有 GCE 网络之外暴露。
@@ -1,233 +0,0 @@
---
-approvers:
- caesarxuchao
- dchen1107
-
-title: Nodes
-redirect_from:
- "/docs/admin/node/"
- "/docs/admin/node.html"
- "/docs/concepts/nodes/node/"
- "/docs/concepts/nodes/node.html"
---
-
-{{< 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: k8s.gcr.io/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/{{< param "version" >}}/#node-v1-core).``
@@ -1,45 +0,0 @@
---
-
-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！
@@ -1,247 +0,0 @@
---
-cn-approvers:
- lichuqiang
-title: 证书
---
-
-{{< toc >}}
-
-## 创建证书
-
-当使用客户端证书进行认证时，用户可以使用现有部署脚本，或者通过 `easyrsa`、`openssl` 或
-`cfssl` 手动生成证书。
-
-### 使用现有部署脚本
-
-**现有部署脚本** 位于
-`cluster/saltbase/salt/generate-cert/make-ca-cert.sh`。
-
-执行该脚本时需传入两个参数。 第一个参数为 API 服务器的 IP 地址，第二个参数为对象的候补名称列表，
-形如 `IP:<ip地址> 或 DNS:<dns名称>`。
-
-脚本生成三个文件： `ca.crt`、`server.crt` 和 `server.key`。
-
-最后，将以下参数加入到  API 服务器的启动参数中：
-
-```
--client-ca-file=/srv/kubernetes/ca.crt
--tls-cert-file=/srv/kubernetes/server.crt
--tls-private-key-file=/srv/kubernetes/server.key
-```
-
-### easyrsa
-
-使用 **easyrsa** 能够手动地为集群生成证书。
-
-1.  下载、解压并初始化 easyrsa3 的补丁版本。
-
-        curl -L -O https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz
-        tar xzf easy-rsa.tar.gz
-        cd easy-rsa-master/easyrsa3
-        ./easyrsa init-pki
-1.  生成 CA（通过 `--batch` 参数设置自动模式。 通过 `--req-cn` 设置默认使用的 CN）
-
-        ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
-1.  生成服务器证书和密钥。
-    参数 `--subject-alt-name` 设置了访问 API 服务器时可能使用的 IP 和 DNS 名称。 `MASTER_CLUSTER_IP`
-    通常为 `--service-cluster-ip-range` 参数中指定的服务 CIDR 的 首个 IP 地址，`--service-cluster-ip-range`同时用于
-    API 服务器和控制器管理器组件。  `--days` 参数用于设置证书的有效期限。
-    下面的示例还假设用户使用 `cluster.local` 作为默认的 DNS 域名。
-
-        ./easyrsa --subject-alt-name="IP:${MASTER_IP}"\
-        "IP:${MASTER_CLUSTER_IP},"\
-        "DNS:kubernetes,"\
-        "DNS:kubernetes.default,"\
-        "DNS:kubernetes.default.svc,"\
-        "DNS:kubernetes.default.svc.cluster,"\
-        "DNS:kubernetes.default.svc.cluster.local" \
-        --days=10000 \
-        build-server-full server nopass
-1.  拷贝 `pki/ca.crt`、 `pki/issued/server.crt` 和 `pki/private/server.key` 至您的目录。
-1.  填充并在 API 服务器的启动参数中添加以下参数：
-
-        --client-ca-file=/yourdirectory/ca.crt
-        --tls-cert-file=/yourdirectory/server.crt
-        --tls-private-key-file=/yourdirectory/server.key
-
-### openssl
-
-使用 **openssl** 能够手动地为集群生成证书。
-
-1.  生成密钥位数为 2048 的 ca.key：
-
-        openssl genrsa -out ca.key 2048
-1.  依据 ca.key 生成 ca.crt （使用 -days 参数来设置证书有效时间）：
-
-        openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt
-1.  生成密钥位数为 2048 的 server.key：
-
-        openssl genrsa -out server.key 2048
-1.  创建用于生成证书签名请求（CSR）的配置文件。
-    确保在将其保存至文件（如`csr.conf`）之前将尖括号标记的值（如`<MASTER_IP>`）
-    替换为你想使用的真实值。 注意：`MASTER_CLUSTER_IP` 是前面小节中描述的 API 服务器的服务集群 IP
-    (service cluster IP)。 下面的示例也假设用户使用 `cluster.local` 作为默认的 DNS 域名。
-
-        [ req ]
-        default_bits = 2048
-        prompt = no
-        default_md = sha256
-        req_extensions = req_ext
-        distinguished_name = dn
-        
-        [ dn ]
-        C = <country>
-        ST = <state>
-        L = <city>
-        O = <organization>
-        OU = <organization unit>
-        CN = <MASTER_IP>
-        
-        [ req_ext ]
-        subjectAltName = @alt_names
-        
-        [ alt_names ]
-        DNS.1 = kubernetes
-        DNS.2 = kubernetes.default
-        DNS.3 = kubernetes.default.svc
-        DNS.4 = kubernetes.default.svc.cluster
-        DNS.5 = kubernetes.default.svc.cluster.local
-        IP.1 = <MASTER_IP>
-        IP.2 = <MASTER_CLUSTER_IP>
-        
-        [ v3_ext ]
-        authorityKeyIdentifier=keyid,issuer:always
-        basicConstraints=CA:FALSE
-        keyUsage=keyEncipherment,dataEncipherment
-        extendedKeyUsage=serverAuth,clientAuth
-        subjectAltName=@alt_names
-1.  基于配置文件生成证书签名请求：
-
-        openssl req -new -key server.key -out server.csr -config csr.conf
-1.  使用 ca.key、ca.crt 和 server.csr 生成服务器证书：
-
-        openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
-        -CAcreateserial -out server.crt -days 10000 \
-        -extensions v3_ext -extfile csr.conf
-1.  查看证书：
-
-        openssl x509  -noout -text -in ./server.crt
-
-最后，添加同样的参数到  API 服务器的启动参数中。
-
-### cfssl
-
-**cfssl** 是另一种用来生成证书的工具。
-
-1.  按如下所示的方式下载、解压并准备命令行工具。
-    注意：你可能需要基于硬件架构和你所使用的 cfssl 版本对示例命令进行修改。
-
-        curl -LO https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -o cfssl
-        chmod +x cfssl
-        curl -LO https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -o cfssljson
-        chmod +x cfssljson
-        curl -LO https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -o cfssl-certinfo
-        chmod +x cfssl-certinfo
-1.  创建目录来存放物料，并初始化 cfssl：
-
-        mkdir cert
-        cd cert
-        ../cfssl print-defaults config > config.json
-        ../cfssl print-defaults csr > csr.json
-1.  创建用来生成 CA 文件的 JSON 配置文件，例如 `ca-config.json`：
-
-        {
-          "signing": {
-            "default": {
-              "expiry": "8760h"
-            },
-            "profiles": {
-              "kubernetes": {
-                "usages": [
-                  "signing",
-                  "key encipherment",
-                  "server auth",
-                  "client auth",
-                ],
-                "expiry": "8760h"
-              }
-            }
-          }
-        }
-1.  创建用来生成 CA 证书签名请求（CSR）的 JSON 配置文件，例如 `ca-csr.json`。
-    确保将尖括号标记的值替换为你想使用的真实值。
-
-        {
-          "CN": "kubernetes",
-          "key": {
-            "algo": "rsa",
-            "size": 2048
-          },
-          "names":[{
-            "C": "<country>",
-            "ST": "<state>",
-            "L": "<city>",
-            "O": "<organization>",
-            "OU": "<organization unit>",
-          }]
-        }
-1.  生成 CA 密钥（`ca-key.pem`）和证书（`ca.pem`）：
-
-        ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca
-1.  按如下所示的方式创建用来为 API 服务器生成密钥和证书的 JSON 配置文件。
-    确保将尖括号标记的值替换为你想使用的真实值。 `MASTER_CLUSTER_IP` 是前面小节中描述的
-    API 服务器的服务集群 IP。 下面的示例也假设用户使用 `cluster.local` 作为默认的 DNS 域名。
-
-        {
-          "CN": "kubernetes",
-          "hosts": [
-            "127.0.0.1",
-            "<MASTER_IP>",
-            "<MASTER_CLUSTER_IP>",
-            "kubernetes",
-            "kubernetes.default",
-            "kubernetes.default.svc",
-            "kubernetes.default.svc.cluster",
-            "kubernetes.default.svc.cluster.local"
-          ],
-          "key": {
-            "algo": "rsa",
-            "size": 2048
-          },
-          "names": [{
-            "C": "<country>",
-            "ST": "<state>",
-            "L": "<city>",
-            "O": "<organization>",
-            "OU": "<organization unit>"
-          }]
-        } 
-1.  为 API 服务器生成密钥和证书，生成的秘钥和证书分别默认保存在文件 `server-key.pem`
-    和 `server.pem` 中：
-
-        ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \
-        --config=ca-config.json -profile=kubernetes \
-        server-csr.json | ../cfssljson -bare server
-
-
-## 分发自签名 CA 证书
-
-客户端节点可能拒绝承认自签名 CA 证书有效。
-对于非生产环境的部署，或运行在企业防火墙后的部署，用户可以向所有客户端分发自签名 CA 证书，
-并刷新本地的有效证书列表。
-
-在每个客户端上执行以下操作：
-
-```bash
-$ sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt
-$ sudo update-ca-certificates
-Updating certificates in /etc/ssl/certs...
-1 added, 0 removed; done.
-Running hooks in /etc/ca-certificates/update.d....
-done.
-```
-
-## 证书 API
-
-您可以按照[这里](/docs/tasks/tls/managing-tls-in-a-cluster)记录的方式，
-使用 `certificates.k8s.io` API 来准备 x509 证书，用于认证。
@@ -1,109 +0,0 @@
---
-title: 云供应商
-content_template: templates/concept
---
-
-{{% capture overview %}}
-本文介绍了如何管理运行在特定云供应商上的 Kubernetes 集群。
-{{% /capture %}}
-
-{{% capture body %}}
-# AWS
-本节介绍在 Amazon Web Services 上运行 Kubernetes 时可以使用的所有配置。
-
-## 负载均衡器
-用户可以通过配置注解（annotations）来设置 [外部负载均衡器](/docs/tasks/access-application-cluster/create-external-load-balancer/)，以在 AWS 中使用特定功能，如下所示：
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
-  name: example
-  namespace: kube-system
-  labels:
-    run: example
-  annotations:
-     service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:xx-xxxx-x:xxxxxxxxx:xxxxxxx/xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx #replace this value
-     service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
-spec:
-  type: LoadBalancer
-  ports:
-  - port: 443
-    targetPort: 5556
-    protocol: TCP
-  selector:
-    app: example
-```
-可以使用 _注解_ 将不同的设置应用于 AWS 中的负载平衡器服务。 下面描述了 AWS ELB 所支持的注解：
-
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval`：用于指定访问日志的间隔。
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled`：用于在服务中启用或禁用日志访问。
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name`：用于指定访问日志的 S3 桶名称。
-* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`：用于指定访问日志的 S3 桶前缀。
-* `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`：用于在服务中指定一个逗号分隔的键值对列表，它将作为附加标签被记录在 ELB 中。 例如： `"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`。
-* `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`：用于在服务中指定监听器后端（pod）所使用的协议。 如果指定 `http` （默认） 或 `https`， 将创建一个终止连接和解析头的 HTTPS 监听器。 如果设置为 `ssl` 或 `tcp`， 将会使用 “原生的” SSL 监听器。 如果设置为 `http` 且不使用 `aws-load-balancer-ssl-cert`，将使用 HTTP 监听器。
-* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`：用于在服务中请求安全监听器，其值为合法的证书 ARN（Amazon Resource Name）。 更多内容，请参考 [ELB 监听器配置](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html)。 证书 ARN 是 IAM（身份和访问管理） 或 CM（证书管理）类型的 ARN，例如 `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`。
-* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`：用于在服务中启用或禁用连接耗尽（connection draining）。
-* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`：用于在服务中指定连接耗尽超时时间。
-* `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`：用于在服务中指定空闲连接超时时间。
-* `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`：用于在服务中启用或禁用跨区域负载平衡。
-* `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`：用于在服务中指定要添加到创建的 ELB 中的其他安全组。
-* `service.beta.kubernetes.io/aws-load-balancer-internal`：用于在服务中表明需要内部 ELB。
-* `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`：用于在 ELB 上启用代理协议。 当前仅接受 `*` 值，也就是在所有 ELB 后端启用代理协议。 将来可能进行调整，只允许特定的后端设置代理协议。
-* `service.beta.kubernetes.io/aws-load-balancer-ssl-ports`：用于在服务中指定一个逗号分隔的端口列表，这些端口会使用 SSL/HTTPS 监听器。 默认为 `*`（全部）
-
-AWS 相关的注解信息取自 [aws.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/aws/aws.go) 文件的注释。
-
-# OpenStack
-本节介绍了使用 OpenStack 运行 Kubernetes 时所有可用的配置。
-
-## cloud.conf
-Kubernetes 知道如何通过文件 cloud.conf 与 OpenStack 进行交互。 该文件会为 Kubernetes 提供证书和 OpenStack 认证端点的区位信息。
-用户可以通过在其中指定以下信息来创建 cloud.conf 文件。
-
-### 最小配置
-这是一个最小配置的例子，它涉及最常用的值：
-
-```yaml
-[Global]
-username=user  
-password=pass  
-auth-url=https://<keystone_ip>/identity/v3  
-tenant-id=c869168a828847f39f7f06edd7305637  
-domain-id=2a73b8f597c04551a0fdc8e95544be8a
-
-[LoadBalancer]
-subnet-id=6937f8fa-858d-4bc9-a3a5-18d2c957166a  
-```
-
-#### 全局配置
-* `username`：指 keystone 中设置的一个合法用户的用户名。
-* `password`：指 keystone 中设置的一个合法用户的密码。
-* `auth-url`：用于认证的 keystone API 的 URL 。 在 OpenStack 控制面板上，可以在 “访问和安全（Access and Security）> api 访问（API Access）> 凭证（Credentials）” 路径下找到它。
-* `tenant-id`：用于指定要创建资源的项目 ID。
-* `domain-id`：用于指定用户所属的域（domain）ID。
-
-####  负载均衡器
-* `subnet-id`：用于指定要创建的负载均衡器所在的子网 ID。 可以在 “Network > Networks” 路径下找到它。 点击相应的网络获取其子网。
-
-### 可选配置
-
-#### 块存储
-
-Kubernetes 利用 OpenStack 服务目录对它知道如何使用的服务进行定位，包括 Cinder 块存储服务。 然而，云供应商的配置中包含一个附加选项，可以影响块存储 API 的使用方式：
-
-* `bs-version`：指所使用的块存储 API 版本。 其合法值为
-  `v1`、 `v2`、 `v3` 和 `auto`。 `auto` 为默认值，将使用底层 Openstack 所支持的块存储 API 的最新版本。
-
-如果在 OpenStack 上部署 Kubernetes <= 1.8 的版本，同时使用路径而不是端口来区分端点（endpoints），那么可能需要显式设置 `bs-version` 参数。 基于路径的端点形如 `http://foo.bar/volume` ，而基于端口的的端点形如
-`http://foo.bar:xxx`。
-
-在使用基于路径的端点，并且 Kubernetes 使用较旧的自动检索逻辑的环境中，尝试卷卸载（detachment）会返回 `BS API version autodetection failed.` 错误。 为了解决这个问题，可以通过添加以下内容到云供应商配置中，来强制使用 Cinder API V2 版本。
-
-```yaml
-[BlockStorage]
-bs-version=v2
-```
-{{% /capture %}}
-
-
@@ -1,87 +0,0 @@
---
-approvers:
- davidopp
- lavalamp
-
-title: 集群管理概述
-content_template: templates/concept
---
-
-{{% capture overview %}}
-
-集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。我们假设你对 [用户指南](/docs/user-guide/)中的概念有一些熟悉。
-{{% /capture %}}
-
-{{% 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 的日志如何工作以及怎样实现。
-
-{{% /capture %}}
-
-
@@ -1,64 +0,0 @@
---
-title: Kubernetes 中的代理
-content_template: templates/concept
---
-
-{{% capture overview %}}
-本文讲述了 Kubernetes 中所使用的代理。
-{{% /capture %}}
-
-{{% capture body %}}
-
-## 代理
-
-用户在使用 Kubernetes 的过程中可能遇到几种不同的代理（proxy）：
-
-  1. [kubectl proxy](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api)：
-
-    - 运行在用户的桌面或 pod 中
-    - 从本机地址到 Kubernetes apiserver 的代理
-    - 客户端到代理使用 HTTP 协议
-    - 代理到 apiserver 使用 HTTPS 协议
-    - 指向 apiserver
-    - 添加认证头信息
-
-  1. [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services)：
-
-    - 是一个建立在 apiserver 内部的“堡垒”
-    - 将集群外部的用户与群集 IP 相连接，这些IP是无法通过其他方式访问的
-    - 运行在 apiserver 进程内
-    - 客户端到代理使用 HTTPS 协议 (如果配置 apiserver 使用 HTTP 协议，则使用 HTTP 协议)
-    - 通过可用信息进行选择，代理到目的地可能使用 HTTP 或 HTTPS 协议
-    - 可以用来访问 Node、 Pod 或 Service
-    - 当用来访问 Service 时，会进行负载均衡
-
-  1. [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips)：
-
-    - 在每个节点上运行
-    - 代理 UDP 和 TCP
-    - 不支持 HTTP 
-    - 提供负载均衡能力
-    - 只用来访问 Service
-
-  1. apiserver 之前的代理/负载均衡器：
-
-    - 在不同集群间的存在形式和实现不同 (如 nginx)
-    - 位于所有客户端和一个或多个 apiserver 之间
-    - 存在多个 apiserver 时，扮演负载均衡器的角色
-
-  1. 外部服务的云负载均衡器：
-
-    - 由一些云供应商提供 (如AWS ELB、 Google Cloud Load Balancer)
-    - Kubernetes service 为 `LoadBalancer` 类型时自动创建
-    - 只使用 UDP/TCP 协议
-    - 不同云供应商的实现不同。
-
-Kubernetes 用户通常只需要关心前两种类型的代理，集群管理员通常需要确保后面几种类型的代理设置正确。
-
-## 请求重定向
-
-代理已经取代重定向功能，重定向已被弃用。
-
-{{% /capture %}}
-
-
@@ -1,100 +0,0 @@
---
-approvers:
- sttts
-title: Kubernetes集群中使用Sysctls
---
-
-{{< 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/{{< param "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上。
@@ -1,299 +0,0 @@
---
-title: Managing Compute Resources for Containers
-content_template: templates/concept
---
-
-{{% capture overview %}}
-
-当您定义 [Pod](/docs/user-guide/pods) 的时候可以选择为每个容器指定需要的 CPU 和内存（RAM）大小。当为容器指定了资源请求后，调度器就能够更好的判断出将容器调度到哪个节点上。如果您还为容器指定了资源限制，节点上的资源就可以按照指定的方式做竞争。关于资源请求和限制的不同点和更多资料请参考 [Resource QoS](https://git.k8s.io/community/contributors/design-proposals/resource-qos.md)。
-
-{{% /capture %}}
-
-
-{{% capture body %}}
-
-## 资源类型
-
-*CPU* 和 *内存* 都是 *资源类型*。资源类型具有基本单位。CPU 的单位是 core，内存的单位是 byte。
-
-CPU和内存统称为*计算资源*，也可以称为*资源*。计算资源的数量是可以被请求、分配、消耗和可测量的。它们与 [API 资源](/docs/api/) 不同。 API 资源（如 Pod 和 [Service](/docs/user-guide/services)）是可通过 Kubernetes API server 读取和修改的对象。
-
-## Pod 和 容器的资源请求和限制
-
-Pod 中的每个容器都可以指定以下的一个或者多个值：
-
- `spec.containers[].resources.limits.cpu`
- `spec.containers[].resources.limits.memory`
- `spec.containers[].resources.requests.cpu`
- `spec.containers[].resources.requests.memory`
-
-尽管只能在个别容器上指定请求和限制，但是我们可以方便地计算出 Pod 资源请求和限制。特定资源类型的Pod 资源请求/限制是 Pod 中每个容器的该类型的资源请求/限制的总和。
-
-## CPU 的含义
-
-CPU 资源的限制和请求以 *cpu* 为单位。
-
-Kubernetes 中的一个 cpu 等于：
-
- 1 AWS vCPU
- 1 GCP Core
- 1 Azure vCore
- 1 *Hyperthread* 在带有超线程的裸机 Intel 处理器上
-
-允许浮点数请求。具有 `spec.containers[].resources.requests.cpu` 为 0.5 的容器保证了一半 CPU 要求 1 CPU的一半。表达式 `0.1` 等价于表达式 `100m`，可以看作 “100 millicpu”。有些人说成是“一百毫 cpu”，其实说的是同样的事情。具有小数点（如 `0.1`）的请求由 API 转换为`100m`，精度不超过 `1m`。因此，可能会优先选择 `100m` 的形式。
-
-CPU 总是要用绝对数量，不可以使用相对数量；0.1 的 CPU 在单核、双核、48核的机器中的意义是一样的。
-
-## 内存的含义
-
-内存的限制和请求以字节为单位。您可以使用以下后缀之一作为平均整数或定点整数表示内存：E，P，T，G，M，K。您还可以使用两个字母的等效的幂数：Ei，Pi，Ti ，Gi，Mi，Ki。例如，以下代表大致相同的值：
-
-```shell
-128974848, 129e6, 129M, 123Mi
-```
-
-下面是个例子。
-
-以下 Pod 有两个容器。每个容器的请求为 0.25 cpu 和 64MiB（2<sup>26</sup> 字节）内存，每个容器的限制为 0.5 cpu 和 128MiB 内存。您可以说该 Pod 请求 0.5 cpu 和 128 MiB 的内存，限制为 1 cpu 和 256MiB 的内存。
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: frontend
-spec:
-  containers:
-  - name: db
-    image: mysql
-    resources:
-      requests:
-        memory: "64Mi"
-        cpu: "250m"
-      limits:
-        memory: "128Mi"
-        cpu: "500m"
-  - name: wp
-    image: wordpress
-    resources:
-      requests:
-        memory: "64Mi"
-        cpu: "250m"
-      limits:
-        memory: "128Mi"
-        cpu: "500m"
-```
-
-## 具有资源请求的 Pod 如何调度
-
-当您创建一个 Pod 时，Kubernetes 调度程序将为 Pod 选择一个节点。每个节点具有每种资源类型的最大容量：可为 Pod 提供的 CPU 和内存量。调度程序确保对于每种资源类型，调度的容器的资源请求的总和小于节点的容量。请注意，尽管节点上的实际内存或 CPU 资源使用量非常低，但如果容量检查失败，则调度程序仍然拒绝在该节点上放置 Pod。当资源使用量稍后增加时，例如在请求率的每日峰值期间，这可以防止节点上的资源短缺。
-
-## 具有资源限制的 Pod 如何运行
-
-当 kubelet 启动一个 Pod 的容器时，它会将 CPU 和内存限制传递到容器运行时。
-
-当使用 Docker 时：
-
- `spec.containers[].resources.requests.cpu` 的值将转换成 millicore 值，这是个浮点数，并乘以1024，这个数字中的较大者或2用作 `docker run` 命令中的[ `--cpu-shares`](https://docs.docker.com/engine/reference/run/#/cpu-share-constraint) 标志的值。
- `spec.containers[].resources.limits.cpu` 被转换成 millicore 值。被乘以 100000 然后 除以 1000。这个数字用作 `docker run` 命令中的 [`--cpu-quota`](https://docs.docker.com/engine/reference/run/#/cpu-quota-constraint) 标志的值。[`--cpu-quota` ] 标志被设置成了 100000，表示测量配额使用的默认100ms 周期。如果 [`--cpu-cfs-quota`] 标志设置为 true，则 kubelet 会强制执行 cpu 限制。从 Kubernetes 1.2 版本起，此标志默认为 true。
- `spec.containers[].resources.limits.memory` 被转换为整型，作为 `docker run` 命令中的 [`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints) 标志的值。
-
-如果容器超过其内存限制，则可能会被终止。如果可重新启动，则与所有其他类型的运行时故障一样，kubelet 将重新启动它。
-
-如果一个容器超过其内存请求，那么当节点内存不足时，它的 Pod 可能被逐出。
-
-容器可能被允许也可能不被允许超过其 CPU 限制时间。但是，由于 CPU 使用率过高，不会被杀死。
-
-要确定容器是否由于资源限制而无法安排或被杀死，请参阅 [疑难解答](#troubleshooting) 部分。
-
-## 监控计算资源使用
-
-Pod 的资源使用情况被报告为 Pod 状态的一部分。
-
-如果为集群配置了 [可选监控](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/README.md)，则可以从监控系统检索 Pod 资源的使用情况。
-
-## 疑难解答
-
-### 我的 Pod 处于 pending 状态且事件信息显示 failedScheduling
-
-如果调度器找不到任何该 Pod 可以匹配的节点，则该 Pod 将保持不可调度状态，直到找到一个可以被调度到的位置。每当调度器找不到 Pod 可以调度的地方时，会产生一个事件，如下所示：
-
-```shell
-$ kubectl describe pod frontend | grep -A 3 Events
-Events:
-  FirstSeen LastSeen   Count  From          Subobject   PathReason      Message
-  36s   5s     6      {scheduler }              FailedScheduling  Failed for reason PodExceedsFreeCPU and possibly others
-```
-
-在上述示例中，由于节点上的 CPU 资源不足，名为 “frontend” 的 Pod 将无法调度。由于内存不足（PodExceedsFreeMemory），类似的错误消息也可能会导致失败。一般来说，如果有这种类型的消息而处于 pending 状态，您可以尝试如下几件事情：
-
-```shell
-$ kubectl describe nodes e2e-test-minion-group-4lw4
-Name:            e2e-test-minion-group-4lw4
-[ ... lines removed for clarity ...]
-Capacity:
- alpha.kubernetes.io/nvidia-gpu:    0
- cpu:                               2
- memory:                            7679792Ki
- pods:                              110
-Allocatable:
- alpha.kubernetes.io/nvidia-gpu:    0
- cpu:                               1800m
- memory:                            7474992Ki
- pods:                              110
-[ ... lines removed for clarity ...]
-Non-terminated Pods:        (5 in total)
-  Namespace    Name                                  CPU Requests  CPU Limits  Memory Requests  Memory Limits
-  ---------    ----                                  ------------  ----------  ---------------  -------------
-  kube-system  fluentd-gcp-v1.38-28bv1               100m (5%)     0 (0%)      200Mi (2%)       200Mi (2%)
-  kube-system  kube-dns-3297075139-61lj3             260m (13%)    0 (0%)      100Mi (1%)       170Mi (2%)
-  kube-system  kube-proxy-e2e-test-...               100m (5%)     0 (0%)      0 (0%)           0 (0%)
-  kube-system  monitoring-influxdb-grafana-v4-z1m12  200m (10%)    200m (10%)  600Mi (8%)       600Mi (8%)
-  kube-system  node-problem-detector-v0.1-fj7m3      20m (1%)      200m (10%)  20Mi (0%)        100Mi (1%)
-Allocated resources:
-  (Total limits may be over 100 percent, i.e., overcommitted.)
-  CPU Requests    CPU Limits    Memory Requests    Memory Limits
-  ------------    ----------    ---------------    -------------
-  680m (34%)      400m (20%)    920Mi (12%)        1070Mi (14%)
-```
-
-在上面的输出中，您可以看到如果 Pod 请求超过 1120m CPU 或者 6.23Gi 内存，节点将无法满足。
-
-通过查看 `Pods` 部分，您将看到哪些 Pod 占用的节点上的资源。
-
-Pod 可用的资源量小于节点容量，因为系统守护程序使用一部分可用资源。 [NodeStatus](/docs/resources-reference/{{< param "version" >}}/#nodestatus-v1-core)  的 `allocatable` 字段给出了可用于 Pod 的资源量。有关更多信息，请参阅 [节点可分配资源](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md)。
-
-可以将 [资源配额](/docs/concepts/policy/resource-quotas/) 功能配置为限制可以使用的资源总量。如果与 namespace 配合一起使用，就可以防止一个团队占用所有资源。
-
-## 我的容器被终止了
-
-您的容器可能因为资源枯竭而被终止了。要查看容器是否因为遇到资源限制而被杀死，请在相关的 Pod 上调用 `kubectl describe pod`：
-
-```shell
-[12:54:41] $ kubectl describe pod simmemleak-hra99
-Name:                           simmemleak-hra99
-Namespace:                      default
-Image(s):                       saadali/simmemleak
-Node:                           kubernetes-node-tf0f/10.240.216.66
-Labels:                         name=simmemleak
-Status:                         Running
-Reason:
-Message:
-IP:                             10.244.2.75
-Replication Controllers:        simmemleak (1/1 replicas created)
-Containers:
-  simmemleak:
-    Image:  saadali/simmemleak
-    Limits:
-      cpu:                      100m
-      memory:                   50Mi
-    State:                      Running
-      Started:                  Tue, 07 Jul 2015 12:54:41 -0700
-    Last Termination State:     Terminated
-      Exit Code:                1
-      Started:                  Fri, 07 Jul 2015 12:54:30 -0700
-      Finished:                 Fri, 07 Jul 2015 12:54:33 -0700
-    Ready:                      False
-    Restart Count:              5
-Conditions:
-  Type      Status
-  Ready     False
-Events:
-  FirstSeen                         LastSeen                         Count  From                              SubobjectPath                       Reason      Message
-  Tue, 07 Jul 2015 12:53:51 -0700   Tue, 07 Jul 2015 12:53:51 -0700  1      {scheduler }                                                          scheduled   Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f
-  Tue, 07 Jul 2015 12:53:51 -0700   Tue, 07 Jul 2015 12:53:51 -0700  1      {kubelet kubernetes-node-tf0f}    implicitly required container POD   pulled      Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine
-  Tue, 07 Jul 2015 12:53:51 -0700   Tue, 07 Jul 2015 12:53:51 -0700  1      {kubelet kubernetes-node-tf0f}    implicitly required container POD   created     Created with docker id 6a41280f516d
-  Tue, 07 Jul 2015 12:53:51 -0700   Tue, 07 Jul 2015 12:53:51 -0700  1      {kubelet kubernetes-node-tf0f}    implicitly required container POD   started     Started with docker id 6a41280f516d
-  Tue, 07 Jul 2015 12:53:51 -0700   Tue, 07 Jul 2015 12:53:51 -0700  1      {kubelet kubernetes-node-tf0f}    spec.containers{simmemleak}         created     Created with docker id 87348f12526a
-```
-
-在上面的例子中，`Restart Count: 5` 意味着 Pod 中的 `simmemleak` 容器被终止并重启了五次。
-
-您可以使用 `kubectl get pod` 命令加上 `-o go-template=...` 选项来获取之前终止容器的状态。
-
-```shell
-[13:59:01] $ kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}'  simmemleak-60xbc
-Container Name: simmemleak
-LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]]
-```
-
-您可以看到容器因为 `reason:OOM killed` 被终止，`OOM` 表示 Out Of Memory。
-
-## 不透明整型资源（Alpha功能）
-
-Kubernetes 1.5 版本中引入不透明整型资源。不透明的整数资源允许集群运维人员发布新的节点级资源，否则系统将不了解这些资源。
-
-用户可以在 Pod 的 spec 中消费这些资源，就像 CPU 和内存一样。调度器负责资源计量，以便在不超过可用量的同时分配给 Pod。
-
-**注意：** 不透明整型资源在 kubernetes 1.5 中还是 Alpha 版本。只实现了资源计量，节点级别的隔离还处于积极的开发阶段。
-
-不透明整型资源是以 `pod.alpha.kubernetes.io/opaque-int-resource-` 为前缀的资源。API server 将限制这些资源的数量为整数。*有效* 数量的例子有 `3`、`3000m` 和 `3Ki`。*无效*数量的例子有 `0.5` 和 `1500m`。
-
-申请使用不透明整型资源需要两步。首先，集群运维人员必须在一个或多个节点上通告每个节点不透明的资源。然后，用户必须在 Pod 中请求不透明资源。
-
-要发布新的不透明整型资源，集群运维人员应向 API server 提交 `PATCH` HTTP请求，以指定集群中节点的`status.capacity` 的可用数量。在此操作之后，节点的 `status.capacity` 将包括一个新的资源。 `status.allocatable` 字段由 kubelet 异步地使用新资源自动更新。请注意，由于调度器在评估 Pod 适应度时使用节点 `status.allocatable` 值，所以在使用新资源修补节点容量和请求在该节点上调度资源的第一个 pod 之间可能会有短暂的延迟。
-
-**示例**
-
-这是一个 HTTP 请求，master 节点是 k8s-master，在 k8s-node-1 节点上通告 5 个 “foo” 资源。
-
-```http
-PATCH /api/v1/nodes/k8s-node-1/status HTTP/1.1
-Accept: application/json
-Content-Type: application/json-patch+json
-Host: k8s-master:8080
-
-```
-
-```shell
-curl --header "Content-Type: application/json-patch+json" \
--request PATCH \
--data '[{"op": "add", "path": "/status/capacity/pod.alpha.kubernetes.io~1opaque-int-resource-foo", "value": "5"}]' \
-http://k8s-master:8080/api/v1/nodes/k8s-node-1/status
-```
-
-**注意：** 在前面的请求中，`~1` 是 patch 路径中 `/` 字符的编码。JSON-Patch 中的操作路径值被解释为 JSON-Pointer。更多详细信息请参阅 [IETF RFC 6901, section 3](https://tools.ietf.org/html/rfc6901#section-3)。
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: my-pod
-spec:
-  containers:
-  - name: my-container
-    image: myimage
-    resources:
-      requests:
-        cpu: 2
-        pod.alpha.kubernetes.io/opaque-int-resource-foo: 1
-```
-
-## 计划改进
-
-在 kubernetes 1.5 版本中仅允许在容器上指定资源量。计划改进对所有容器在 Pod 中共享资源的计量，如 [emptyDir volume](/docs/concepts/storage/volumes/#emptydir)。
-
-在 kubernetes 1.5 版本中仅支持容器对 CPU 和内存的申请和限制。计划增加新的资源类型，包括节点磁盘空间资源和一个可支持自定义 [资源类型](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/resources.md) 的框架。
-
-Kubernetes 通过支持通过多级别的 [服务质量](http://issue.k8s.io/168) 来支持资源的过度使用。
-
-在 kubernetes 1.5 版本中，一个 CPU 单位在不同的云提供商和同一云提供商的不同机器类型中的意味都不同。例如，在 AWS 上，节点的容量报告为 [ECU](http://aws.amazon.com/ec2/faqs/)，而在 GCE 中报告为逻辑内核。我们计划修改 cpu 资源的定义，以便在不同的提供商和平台之间保持一致。
-
-{{% /capture %}}
-
-{{% capture whatsnext %}}
-
- 获取将 [CPU 和内存资源分配给容器](/docs/tasks/configure-pod-container/assign-cpu-ram-container/) 的实践经验
- [容器](/docs/api-reference/{{< param "version" >}}/#container-v1-core)
- [ResourceRequirements](/docs/resources-reference/{{< param "version" >}}/#resourcerequirements-v1-core)
-
-{{% /capture %}}
-
-
-
- [容器](/docs/api-reference/{{< param "version" >}}/#container-v1-core)
- [ResourceRequirements](/docs/resources-reference/{{< param "version" >}}/#resourcerequirements-v1-core)
-
-{{% /capture %}}
-
-
-
@@ -1,586 +0,0 @@
---
-approvers:
- mikedanese
-title: Secret
---
-
-`Secret` 对象类型用来保存敏感信息，例如密码、OAuth 令牌和 ssh key。将这些信息放在 `secret` 中比放在 `pod` 的定义或者 docker 镜像中来说更加安全和灵活。参阅 [Secret 设计文档](https://git.k8s.io/community/contributors/design-proposals/secrets.md) 获取更多详细信息。
-
-{{< toc >}}
-## Secret 概览
-
-Secret 是一种包含少量敏感信息例如密码、token 或 key 的对象。这样的信息可能会被放在 Pod spec 中或者镜像中；将其放在一个 secret 对象中可以更好地控制它的用途，并降低意外暴露的风险。
-
-用户可以创建 secret，同时系统也创建了一些 secret。
-
-要使用 secret，pod 需要引用 secret。Pod 可以用两种方式使用 secret：作为 [volume](/docs/concepts/storage/volumes/) 中的文件被挂载到 pod 中的一个或者多个容器里，或者当 kubelet 为 pod 拉取镜像时使用。
-
-### 内置 secret
-
-#### Service Account 使用 API 凭证自动创建和附加 secret
-
-Kubernetes 自动创建包含访问 API 凭据的 secret，并自动修改您的 pod 以使用此类型的 secret。
-
-如果需要，可以禁用或覆盖自动创建和使用API凭据。但是，如果您需要的只是安全地访问 apiserver，我们推荐这样的工作流程。
-
-参阅  [Service Account](/docs/user-guide/service-accounts) 文档获取关于 Service Account 如何工作的更多信息。
-
-### 创建您自己的 Secret
-
-#### 使用 kubectl 创建 Secret
-
-假设有些 pod 需要访问数据库。这些 pod 需要使用的用户名和密码在您本地机器的 `./username.txt` 和 `./password.txt` 文件里。
-
-```shell
-# Create files needed for rest of example.
-$ echo -n "admin" > ./username.txt
-$ echo -n "1f2d1e2e67df" > ./password.txt
-```
-
-`kubectl create secret` 命令将这些文件打包到一个 Secret 中并在 API server 中创建了一个对象。
-
-```shell
-$ kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt
-secret "db-user-pass" created
-```
-
-您可以这样检查刚创建的 secret：
-
-```shell
-$ kubectl get secrets
-NAME                  TYPE                                  DATA      AGE
-db-user-pass          Opaque                                2         51s
-
-$ kubectl describe secrets/db-user-pass
-Name:            db-user-pass
-Namespace:       default
-Labels:          <none>
-Annotations:     <none>
-
-Type:            Opaque
-
-Data
-====
-password.txt:    12 bytes
-username.txt:    5 bytes
-```
-
-请注意，默认情况下，`get` 和 `describe` 命令都不会显示文件的内容。这是为了防止将 secret 中的内容被意外暴露给从终端日志记录中刻意寻找它们的人。
-
-请参阅 [解码 secret](#decoding-a-secret) 了解如何查看它们的内容。
-
-#### 手动创建 Secret
-
-您也可以先以 json 或 yaml 格式在文件中创建一个 secret 对象，然后创建该对象。
-
-每一项必须是 base64 编码：
-
-```shell
-$ echo -n "admin" | base64
-YWRtaW4=
-$ echo -n "1f2d1e2e67df" | base64
-MWYyZDFlMmU2N2Rm
-```
-
-现在可以像这样写一个 secret 对象：
-
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  name: mysecret
-type: Opaque
-data:
-  username: YWRtaW4=
-  password: MWYyZDFlMmU2N2Rm
-```
-
-数据字段是一个映射。它的键必须匹配 [`DNS_SUBDOMAIN`](https://git.k8s.io/community/contributors/design-proposals/identifiers.md)，前导点也是可以的。这些值可以是任意数据，使用 base64 进行编码。
-
-使用  [`kubectl create`](/docs/user-guide/kubectl/v1.7/#create) 创建 secret：
-
-```shell
-$ kubectl create -f ./secret.yaml
-secret "mysecret" created
-```
-
-**编码注意：** secret 数据的序列化 JSON 和 YAML 值使用 base64 编码成字符串。换行符在这些字符串中无效，必须省略。当在 Darwin/OS X 上使用 `base64` 实用程序时，用户应避免使用 `-b` 选项来拆分长行。另外，对于 Linux 用户如果 `-w` 选项不可用的话，应该添加选项 `-w 0` 到 `base64` 命令或管道 `base64 | tr -d '\n' ` 。
-
-#### 解码 Secret
-
-可以使用 `kubectl get secret` 命令获取 secret。例如，获取在上一节中创建的 secret：
-
-```shell
-$ kubectl get secret mysecret -o yaml
-apiVersion: v1
-data:
-  username: YWRtaW4=
-  password: MWYyZDFlMmU2N2Rm
-kind: Secret
-metadata:
-  creationTimestamp: 2016-01-22T18:41:56Z
-  name: mysecret
-  namespace: default
-  resourceVersion: "164619"
-  selfLink: /api/v1/namespaces/default/secrets/mysecret
-  uid: cfee02d6-c137-11e5-8d73-42010af00002
-type: Opaque
-```
-
-解码密码字段：
-
-```shell
-$ echo "MWYyZDFlMmU2N2Rm" | base64 --decode
-1f2d1e2e67df
-```
-
-### 使用 Secret
-
-Secret 可以作为数据卷被挂载，或作为环境变量暴露出来以供 pod 中的容器使用。它们也可以被系统的其他部分使用，而不直接暴露在 pod 内。例如，它们可以保存凭据，系统的其他部分应该用它来代表您与外部系统进行交互。
-
-#### 在 Pod 中使用 Secret 文件
-
-在 Pod 中的 volume 里使用 Secret：
-
-1. 创建一个 secret 或者使用已有的 secret。多个 pod 可以引用同一个 secret。
-2. 修改您的 pod 的定义在 `spec.volumes[]` 下增加一个 volume。可以给这个 volume 随意命名，它的 `spec.volumes[].secret.secretName` 必须等于 secret 对象的名字。
-3. 将 `spec.containers[].volumeMounts[]` 加到需要用到该 secret 的容器中。指定 `spec.containers[].volumeMounts[].readOnly = true` 和 `spec.containers[].volumeMounts[].mountPath` 为您想要该 secret 出现的尚未使用的目录。
-4. 修改您的镜像并且／或者命令行让程序从该目录下寻找文件。Secret 的 `data` 映射中的每一个键都成为了 `mountPath` 下的一个文件名。
-
-这是一个在 pod 中使用 volume 挂在 secret 的例子：
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: mypod
-spec:
-  containers:
-  - name: mypod
-    image: redis
-    volumeMounts:
-    - name: foo
-      mountPath: "/etc/foo"
-      readOnly: true
-  volumes:
-  - name: foo
-    secret:
-      secretName: mysecret
-```
-
-您想要用的每个 secret 都需要在 `spec.volumes` 中指明。
-
-如果 pod 中有多个容器，每个容器都需要自己的 `volumeMounts` 配置块，但是每个 secret 只需要一个 `spec.volumes`。
-
-您可以打包多个文件到一个 secret 中，或者使用的多个 secret，怎样方便就怎样来。
-
-**向特性路径映射 secret 密钥**
-
-我们还可以控制 Secret key 映射在 volume 中的路径。您可以使用 `spec.volumes[].secret.items` 字段修改每个 key 的目标路径：
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: mypod
-spec:
-  containers:
-  - name: mypod
-    image: redis
-    volumeMounts:
-    - name: foo
-      mountPath: "/etc/foo"
-      readOnly: true
-  volumes:
-  - name: foo
-    secret:
-      secretName: mysecret
-      items:
-      - key: username
-        path: my-group/my-username
-```
-
-将会发生什么呢：
-
- `username` secret 存储在 `/etc/foo/my-group/my-username` 文件中而不是 `/etc/foo/username` 中。
- `password` secret 没有被映射
-
-如果使用了 `spec.volumes[].secret.items`，只有在 `items` 中指定的 key 被映射。要使用 secret 中所有的 key，所有这些都必须列在 `items` 字段中。所有列出的密钥必须存在于相应的 secret 中。否则，不会创建卷。
-
-**Secret 文件权限**
-
-您还可以指定 secret 将拥有的权限模式位文件。如果不指定，默认使用 `0644`。您可以为整个保密卷指定默认模式，如果需要，可以覆盖每个密钥。
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: mypod
-spec:
-  containers:
-  - name: mypod
-    image: redis
-    volumeMounts:
-    - name: foo
-      mountPath: "/etc/foo"
-  volumes:
-  - name: foo
-    secret:
-      secretName: mysecret
-      defaultMode: 256
-```
-
-然后，secret 将被挂载到 `/etc/foo` 目录，所有通过该 secret volume 挂载创建的文件的权限都是 `0400`。
-
-请注意，JSON 规范不支持八进制符号，因此使用 256 值作为 0400 权限。如果您使用 yaml 而不是 json 作为 pod，则可以使用八进制符号以更自然的方式指定权限。
-
-您还可以使用映射，如上一个示例，并为不同的文件指定不同的权限，如下所示：
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: mypod
-spec:
-  containers:
-  - name: mypod
-    image: redis
-    volumeMounts:
-    - name: foo
-      mountPath: "/etc/foo"
-  volumes:
-  - name: foo
-    secret:
-      secretName: mysecret
-      items:
-      - key: username
-        path: my-group/my-username
-        mode: 511
-```
-
-在这种情况下，导致 `/etc/foo/my-group/my-username` 的文件的权限值为 `0777`。由于 JSON 限制，必须以十进制格式指定模式。
-
-请注意，如果稍后阅读此权限值可能会以十进制格式显示。
-
-**从 Volume 中消费 secret 值**
-
-在挂载的 secret volume 的容器内，secret key 将作为文件，并且 secret 的值使用 base-64 解码并存储在这些文件中。这是在上面的示例容器内执行的命令的结果：
-
-```shell
-$ ls /etc/foo/
-username
-password
-$ cat /etc/foo/username
-admin
-$ cat /etc/foo/password
-1f2d1e2e67df
-```
-
-容器中的程序负责从文件中读取 secret。
-
-**挂载的 secret 被自动更新**
-
-当已经在 volume 中被消费的 secret 被更新时，被映射的 key 也将被更新。
-
-Kubelet 在周期性同步时检查被挂载的 secret 是不是最新的。但是，它正在使用其基于本地 ttl 的缓存来获取当前的 secret 值。结果是，当 secret 被更新的时刻到将新的 secret 映射到 pod 的时刻的总延迟可以与 kubelet 中的secret 缓存的 kubelet sync period + ttl 一样长。
-
-#### Secret 作为环境变量
-
-将 secret 作为 pod 中的环境变量使用：
-
-1. 创建一个 secret 或者使用一个已存在的 secret。多个 pod 可以引用同一个 secret。
-2. 修改 Pod 定义，为每个要使用 secret 的容器添加对应 secret key 的环境变量。消费secret key 的环境变量应填充 secret 的名称，并键入 `env[x].valueFrom.secretKeyRef`。
-3. 修改镜像并／或者命令行，以便程序在指定的环境变量中查找值。
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: secret-env-pod
-spec:
-  containers:
-  - name: mycontainer
-    image: redis
-    env:
-      - name: SECRET_USERNAME
-        valueFrom:
-          secretKeyRef:
-            name: mysecret
-            key: username
-      - name: SECRET_PASSWORD
-        valueFrom:
-          secretKeyRef:
-            name: mysecret
-            key: password
-  restartPolicy: Never
-```
-
-**消费环境变量里的 Secret 值**
-
-在一个消耗环境变量 secret 的容器中，secret key 作为包含 secret 数据的 base-64 解码值的常规环境变量。这是从上面的示例在容器内执行的命令的结果：
-
-```shell
-$ echo $SECRET_USERNAME
-admin
-$ echo $SECRET_PASSWORD
-1f2d1e2e67df
-```
-
-#### 使用 imagePullSecret
-
-imagePullSecret 是将包含 Docker（或其他）镜像注册表密码的 secret 传递给 Kubelet 的一种方式，因此可以代表您的 pod 拉取私有镜像。
-
-**手动指定 imagePullSecret**
-
-imagePullSecret 的使用在 [镜像文档](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) 中说明。
-
-### 安排 imagePullSecrets 自动附加
-
-您可以手动创建 imagePullSecret，并从 serviceAccount 引用它。使用该 serviceAccount 创建的任何 pod 和默认使用该 serviceAccount 的 pod 将会将其的 imagePullSecret 字段设置为服务帐户的 imagePullSecret 字段。有关该过程的详细说明，请参阅 [将 ImagePullSecrets 添加到服务帐户](/docs/tasks/configure-pod-container/configure-service-account/#adding-imagepullsecrets-to-a-service-account)。
-
-#### 自动挂载手动创建的 Secret
-
-手动创建的 secret（例如包含用于访问 github 帐户的令牌）可以根据其服务帐户自动附加到 pod。请参阅 [使用 PodPreset 向 Pod 中注入信息](/docs/tasks/run-application/podpreset/) 以获取该进程的详细说明。
-
-## 详细
-
-### 限制
-
-验证 secret volume 来源确保指定的对象引用实际上指向一个类型为 Secret 的对象。因此，需要在依赖于它的任何 pod 之前创建一个 secret。
-
-Secret API 对象驻留在命名空间中。它们只能由同一命名空间中的 pod 引用。
-
-每个 secret 的大小限制为1MB。这是为了防止创建非常大的 secret 会耗尽 apiserver 和 kubelet 的内存。然而，创建许多较小的 secret 也可能耗尽内存。更全面得限制 secret 对内存使用的功能还在计划中。
-
-Kubelet 仅支持从 API server 获取的 Pod 使用 secret。这包括使用 kubectl 创建的任何 pod，或间接通过 replication controller 创建的 pod。它不包括通过 kubelet `--manifest-url` 标志，其 `--config` 标志或其 REST API 创建的pod（这些不是创建 pod 的常用方法）。
-
-必须先创建 secret，除非将它们标记为可选项，否则必须在将其作为环境变量在 pod 中使用之前创建 secret。对不存在的 secret 的引用将阻止其启动。
-
-使用 `secretKeyRef` ，引用指定的 secret 中的不存在的 key ，这会阻止 pod 的启动。
-
-对于通过 `envFrom` 填充环境变量的 secret，这些环境变量具有被认为是无效环境变量名称的 key 将跳过这些键。该 pod 将被允许启动。将会有一个事件，其原因是 `InvalidVariableNames`，该消息将包含被跳过的无效键的列表。该示例显示一个 pod，它指的是包含2个无效键，1badkey 和 2alsobad 的默认/mysecret ConfigMap。
-
-```shell
-$ kubectl get events
-LASTSEEN   FIRSTSEEN   COUNT     NAME            KIND      SUBOBJECT                         TYPE      REASON
-0s         0s          1         dapi-test-pod   Pod                                         Warning   InvalidEnvironmentVariableNames   kubelet, 127.0.0.1      Keys [1badkey, 2alsobad] from the EnvFrom secret default/mysecret were skipped since they are considered invalid environment variable names.
-```
-
-### Secret 与 Pod 生命周期的联系
-
-通过 API 创建 Pod 时，不会检查应用的 secret 是否存在。一旦 Pod 被调度，kubelet 就会尝试获取该 secret 的值。如果获取不到该 secret，或者暂时无法与 API server 建立连接，kubelet 将会定期重试。Kubelet 将会报告关于 pod 的事件，并解释它无法启动的原因。一旦获取到 secret，kubelet将创建并装载一个包含它的卷。在所有 pod 的卷被挂载之前，都不会启动 pod 的容器。
-
-## 使用案例
-
-### 使用案例：包含 ssh 密钥的 pod
-
-创建一个包含 ssh key 的 secret：
-
-```shell
-$ kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub
-```
-
-**安全性注意事项**：发送自己的 ssh 密钥之前要仔细思考：集群的其他用户可能有权访问该密钥。使用您想要共享 Kubernetes 群集的所有用户可以访问的服务帐户，如果它们遭到入侵，可以撤销。
-
-现在我们可以创建一个使用 ssh 密钥引用 secret 的pod，并在一个卷中使用它：
-
-```yaml
-kind: Pod
-apiVersion: v1
-metadata:
-  name: secret-test-pod
-  labels:
-    name: secret-test
-spec:
-  volumes:
-  - name: secret-volume
-    secret:
-      secretName: ssh-key-secret
-  containers:
-  - name: ssh-test-container
-    image: mySshImage
-    volumeMounts:
-    - name: secret-volume
-      readOnly: true
-      mountPath: "/etc/secret-volume"
-```
-
-当容器中的命令运行时，密钥的片段将可在以下目录：
-
-```shell
-/etc/secret-volume/ssh-publickey
-/etc/secret-volume/ssh-privatekey
-```
-
-然后容器可以自由使用密钥数据建立一个 ssh 连接。
-
-### 使用案例：包含 prod/test 凭据的 pod
-
-下面的例子说明一个 pod 消费一个包含 prod 凭据的 secret，另一个 pod 使用测试环境凭据消费 secret。
-
-创建 secret：
-
-```shell
-$ kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11
-secret "prod-db-secret" created
-$ kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests
-secret "test-db-secret" created
-```
-
-创建 pod ：
-
-```yaml
-apiVersion: v1
-kind: List
-items:
- kind: Pod
-  apiVersion: v1
-  metadata:
-    name: prod-db-client-pod
-    labels:
-      name: prod-db-client
-  spec:
-    volumes:
-    - name: secret-volume
-      secret:
-        secretName: prod-db-secret
-    containers:
-    - name: db-client-container
-      image: myClientImage
-      volumeMounts:
-      - name: secret-volume
-        readOnly: true
-        mountPath: "/etc/secret-volume"
- kind: Pod
-  apiVersion: v1
-  metadata:
-    name: test-db-client-pod
-    labels:
-      name: test-db-client
-  spec:
-    volumes:
-    - name: secret-volume
-      secret:
-        secretName: test-db-secret
-    containers:
-    - name: db-client-container
-      image: myClientImage
-      volumeMounts:
-      - name: secret-volume
-        readOnly: true
-        mountPath: "/etc/secret-volume"
-```
-
-这两个容器将在其文件系统上显示以下文件，其中包含每个容器环境的值：
-
-```shell
-/etc/secret-volume/username
-/etc/secret-volume/password
-```
-
-请注意，两个 pod 的 spec 配置中仅有一个字段有所不同；这有助于使用普通的 pod 配置模板创建具有不同功能的 pod。您可以使用两个 service account 进一步简化基本 pod spec：一个名为 `prod-user` 拥有  `prod-db-secret` ，另一个称为 `test-user` 拥有 `test-db-secret` 。然后，pod spec 可以缩短为，例如：
-
-```yaml
-kind: Pod
-apiVersion: v1
-metadata:
-  name: prod-db-client-pod
-  labels:
-    name: prod-db-client
-spec:
-  serviceAccount: prod-db-client
-  containers:
-  - name: db-client-container
-    image: myClientImage
-```
-
-### 使用案例：Secret 卷中以点号开头的文件
-
-为了将数据“隐藏”起来（即文件名以点号开头的文件），简单地说让该键以一个点开始。例如，当如下 secret 被挂载到卷中：
-
-```yaml
-kind: Secret
-apiVersion: v1
-metadata:
-  name: dotfile-secret
-data:
-  .secret-file: dmFsdWUtMg0KDQo=
---
-kind: Pod
-apiVersion: v1
-metadata:
-  name: secret-dotfiles-pod
-spec:
-  volumes:
-  - name: secret-volume
-    secret:
-      secretName: dotfile-secret
-  containers:
-  - name: dotfile-test-container
-    image: k8s.gcr.io/busybox
-    command:
-    - ls
-    - "-l"
-    - "/etc/secret-volume"
-    volumeMounts:
-    - name: secret-volume
-      readOnly: true
-      mountPath: "/etc/secret-volume"
-```
-
-`Secret-volume` 将包含一个单独的文件，叫做 `.secret-file`，`dotfile-test-container` 的 `/etc/secret-volume/.secret-file` 路径下将有该文件。
-
-**注意**
-
-以点号开头的文件在 `ls -l` 的输出中被隐藏起来了；列出目录内容时，必须使用 `ls -la` 才能查看它们。
-
-### 使用案例：Secret 仅对 pod 中的一个容器可见
-
-考虑以下一个需要处理 HTTP 请求的程序，执行一些复杂的业务逻辑，然后使用 HMAC 签署一些消息。因为它具有复杂的应用程序逻辑，所以在服务器中可能会出现一个未被注意的远程文件读取漏洞，这可能会将私钥暴露给攻击者。
-
-这可以在两个容器中分为两个进程：前端容器，用于处理用户交互和业务逻辑，但无法看到私钥；以及可以看到私钥的签名者容器，并且响应来自前端的简单签名请求（例如通过本地主机网络）。
-
-使用这种分割方法，攻击者现在必须欺骗应用程序服务器才能进行任意的操作，这可能比使其读取文件更难。
-
-<!-- TODO: explain how to do this while still using automation. -->
-
-## 最佳实践
-
-### 客户端使用 Secret API
-
-当部署与 secret API 交互的应用程序时，应使用诸如 [RBAC](https://kubernetes.io/docs/admin/authorization/rbac/) 之类的 [授权策略](https://kubernetes.io/docs/admin/authorization/) 来限制访问。
-
-Secret 中的值对于不同的环境来说重要性可能不同，例如对于 Kubernetes 集群内部（例如 service account 令牌）和集群外部来说就不一样。即使一个应用程序可以理解其期望的与之交互的 secret 有多大的能力，但是同一命名空间中的其他应用程序却可能不这样认为。
-
-由于这些原因，在命名空间中 `watch` 和 `list`  secret 的请求是非常强大的功能，应该避免这样的行为，因为列出 secret 可以让客户端检查所有 secret 是否在该命名空间中。在群集中`watch` 和 `list` 所有 secret 的能力应该只保留给最有特权的系统级组件。
-
-需要访问 secrets API 的应用程序应该根据他们需要的 secret 执行 `get` 请求。这允许管理员限制对所有 secret 的访问，同时设置 [白名单访问](https://kubernetes.io/docs/admin/authorization/rbac/#referring-to-resources) 应用程序需要的各个实例。
-
-为了提高循环获取的性能，客户端可以设计引用 secret 的资源，然后 `watch` 资源，在引用更改时重新请求 secret。此外，还提出了一种 [”批量监控“ API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/bulk_watch.md) 来让客户端 `watch` 每个资源，该功能可能会在将来的 Kubernetes 版本中提供。
-
-## 安全属性
-
-### 保护
-
-因为 `secret` 对象可以独立于使用它们的 `pod` 而创建，所以在创建、查看和编辑 pod 的流程中 secret 被暴露的风险较小。系统还可以对 `secret` 对象采取额外的预防措施，例如避免将其写入到磁盘中可能的位置。
-
-只有当节点上的 pod 需要用到该 secret 时，该 secret 才会被发送到该节点上。它不会被写入磁盘，而是存储在 tmpfs 中。一旦依赖于它的 pod 被删除，它就被删除。
-
-在大多数 Kubernetes 项目维护的发行版中，用户与 API server 之间的通信以及从 API server 到 kubelet 的通信都受到 SSL/TLS 的保护。通过这些通道传输时，secret 受到保护。
-
-节点上的 secret 数据存储在 tmpfs 卷中，因此不会传到节点上的其他磁盘。
-
-同一节点上的很多个 pod 可能拥有多个 secret。但是，只有 pod 请求的 secret 在其容器中才是可见的。因此，一个 pod 不能访问另一个 Pod 的 secret。
-
-Pod 中有多个容器。但是，pod 中的每个容器必须请求其挂载卷中的 secret 卷才能在容器内可见。这可以用于 [在 Pod 级别构建安全分区](#使用案例secret-仅对-pod-中的一个容器可见)。
-
-### 风险
-
- API server 的 secret 数据以纯文本的方式存储在 etcd 中，因此：
-  - 管理员应该限制 admin 用户访问 etcd；
-  - API server 中的 secret 数据位于 etcd 使用的磁盘上；管理员可能希望在不再使用时擦除/粉碎 etcd 使用的磁盘
- 如果您将 secret 数据编码为 base64 的清单（JSON 或 YAML）文件，共享该文件或将其检入代码库，这样的话该密码将会被泄露。 Base64 编码不是一种加密方式，一样也是纯文本。
- 应用程序在从卷中读取 secret 后仍然需要保护 secret 的值，例如不会意外记录或发送给不信任方。
- 可以创建和使用 secret 的 pod 的用户也可以看到该 secret 的值。即使 API server 策略不允许用户读取 secret 对象，用户也可以运行暴露 secret 的 pod。
- 如果运行了多个副本，那么这些 secret 将在它们之间共享。默认情况下，etcd 不能保证与 SSL/TLS 的对等通信，尽管可以进行配置。
- 目前，任何节点的 root 用户都可以通过模拟 kubelet 来读取 API server 中的任何 secret。只有向实际需要它们的节点发送 secret 才能限制单个节点的根漏洞的影响，该功能还在计划中。
@@ -1,62 +0,0 @@
---
-approvers:
- mikedanese
- thockin
-title: 容器环境变量
-content_template: templates/concept
---
-
-{{% capture overview %}}
-
-本文介绍容器环境中对容器可用的资源。 
-
-{{% /capture %}}
-
-{{< toc >}}
-
-{{% capture body %}}
-
-## 容器环境
-
-Kubernetes 容器环境为容器提供了几类重要的资源：
-
-* 一个文件系统，其中包含一个[镜像](/docs/concepts/containers/images/)和一个或多个[卷](/docs/concepts/storage/volumes/)。
-* 容器本身相关的信息。
-* 集群中其他对象相关的信息。
-
-### 容器信息
-
-容器的 *hostname* 是容器所在的 Pod 名称。 可以通过 `hostname` 命令或调用 libc 中的
-[`gethostname`](http://man7.org/linux/man-pages/man2/gethostname.2.html)
-函数来获取。
-
-Pod 名称和名字空间可以通过
-[downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) 以环境变量方式访问。
-
-与 Docker 镜像中静态指定的环境变量一样，Pod 中用户定义的环境变量也可用于容器。
-
-### 集群信息
-
-容器创建时运行的所有服务的列表都会作为环境变量提供给容器。
-这些环境变量与 Docker 链接语法相匹配。
-
-对一个名为 *foo*，映射到名为 *bar* 的容器端口的服务，
-会定义如下变量：
-
-```shell
-FOO_SERVICE_HOST=<服务所在的主机地址>
-FOO_SERVICE_PORT=<服务所启用的端口>
-```
-
-服务具有专用 IP 地址，如果启用了 [DNS 插件](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)，还可以在容器中通过 DNS 进行访问。
-
-{{% /capture %}}
-
-{{% capture whatsnext %}}
-
-* 查看[容器生命周期挂钩（hooks）](/docs/concepts/containers/container-lifecycle-hooks/)了解更多。
-* 获取[为容器生命周期事件附加处理程序](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)的实践经验。
-
-{{% /capture %}}
-
-
@@ -1,297 +0,0 @@
---
-approvers:
- erictune
- thockin
-title: 镜像
-content_template: templates/concept
---
-
-{{% capture overview %}}
-
-在Kubernetes pod中引用镜像前，请创建Docker镜像，并将之推送到镜像仓库中。
-容器的“image”属性支持和Docker命令行相同的语法，包括私有仓库和标签。
-
-{{% /capture %}}
-
-{{< 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 Kubernetes 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 Kubernetes Engine 上，使用镜像全名(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 Kubernetes Engine 上运行集群，每个节点上都会有`.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 Kubernetes Engine 上运行集群，每个节点上都会有`.dockercfg`文件，它包含对Google Container Registry的凭证。
-不需要使用以下方法。
-
-**注意：** 该方法适用于能够对节点进行配置的情况。该方法在GCE及在其它能自动配置节点的云平台上并不适合。
-
-默认情况下，kubelet会尝试从指定的仓库拉取每一个镜像
-但是，如果容器属性`imagePullPolicy`设置为`IfNotPresent`或者`Never`，
-则会使用本地镜像（优先、唯一、分别）。
-
-如果依赖提前拉取镜像代替仓库认证，
-必须保证集群所有的节点提前拉取的镜像是相同的。
-
-可以用于提前载入指定的镜像以提高速度，或者作为私有仓库认证的一种替代方案
-
-所有的pod都可以使用node上缓存的镜像
-
-### 在pod上指定ImagePullSecrets
-
-**注意:** Google Kubernetes Engine,GCE及其他自动创建node的云平台上，推荐使用本方法。
-
-Kubernetes支持在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 Kubernetes Engine
-也能正常工作。
-
-### 使用场景
-
-配置私有仓库有多种方案，以下是一些常用场景和建议的解决方案。
-
-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中
-
-{{% /capture %}}
-
-
@@ -1,125 +0,0 @@
---
-approvers:
- lavalamp
-title: Kubernetes 组件
-redirect_from:
- "/docs/admin/cluster-components/"
- "/docs/admin/cluster-components.html"
-content_template: templates/concept
---
-{{% capture overview %}}
-本文档概述了 Kubernetes 所需的各种二进制组件, 用于提供齐全的功能。
-{{% /capture %}}
-
-{{% 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) 集群层面的日志。
-
-{{% /capture %}}
-
-
@@ -1,98 +0,0 @@
-# Kubernetes API 概述
-
-[API协议文档](https://git.k8s.io/community/contributors/devel/api-conventions.md)描述了主系统和API概念。
-
-[API参考文档](https://kubernetes.io/docs/reference)描述了API整体规范。
-
-[访问文档](https://kubernetes.io/docs/admin/accessing-the-api)讨论了通过远程访问API的相关问题。
-
-Kubernetes API是系统描述性配置的基础。 [Kubectl](https://kubernetes.io/docs/user-guide/kubectl/) 命令行工具被用于创建、更新、删除、获取API对象。
-
-Kubernetes 通过API资源存储自己序列化状态(现在存储在[etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/))。
-
-Kubernetes 被分成多个组件，各部分通过API相互交互。
-
-## API 变更
-
-根据经验，任何成功的系统都需要随着新的用例出现或现有用例发生变化的情况下，进行相应的进化与调整。因此，我们希望Kubernetes API也可以保持持续的进化和调整。同时，在较长一段时间内，我们也希望与现有客户端版本保持良好的向下兼容性。一般情况下，增加新的API资源和资源字段不会导致向下兼容性问题发生；但如果是需要删除一个已有的资源或者字段，那么必须通过[API废弃流程](/docs/reference/deprecation-policy/)来进行。
-
-参考[API变更文档](https://git.k8s.io/community/contributors/devel/api_changes.md)，了解兼容性变更的要素以及如何变更API的流程。
-
-## API Swagger 定义
-
-Kubernetes使用 [Swagger v1.2](http://swagger.io/) 与 [OpenAPI](https://www.openapis.org/) 记录API所有细节。Kubernetes apiserver (即 “master”)提供了一个API接口用于获取 Swagger 1.2 Kubernetes API 规范 ，默认在路径 **`/swaggerapi`** 下。你也可以为API服务器可以设置 **`-enable-swagger-ui=true`** 来启用API界面，之后使用浏览器访问 **`/swagger-ui`**，浏览API文档。
-
-
-Kubernetes从1.4版本开始，也支持通过 [**`/swagger.json`**](https://git.k8s.io/kubernetes/api/openapi-spec/swagger.json) 来访问 OpenAPI 形式给出的API文档。在我们将 Swagger v1.2 切换到 OpenAPI (aka Swagger v2.0) 期间，一部分工具(如 kubectl 与 swagger-ui )会继续使用 1.2 版本规范。Kubernetes 1.5 版本中的 OpenAPI 规范是 Beta 版本。
-
-Kubernetes实现了另一种基于Protobuf的序列化格式，该格式主要用于集群内通信，并在[设计方案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)中进行了说明，每个模式的IDL文件位于定义API对象的Go软件包中。
-
-## API 版本
-
-为了使删除字段或者重构资源表示更加容易，Kubernetes 支持多个API版本。每一个版本都在不同API路径下，例如 **`/api/v1`** 或者 **`/apis/extensions/v1beta1`**。
-
-我们选择在API级别进行版本化，而不是在资源或字段级别进行版本化，以确保API提供清晰，一致的系统资源和行为视图，并控制对已废止的API和/或实验性API的访问。 JSON和Protobuf序列化模式遵循架构更改的相同准则 - 下面的所有描述都同时适用于这两种格式。
-
-请注意，API版本控制和软件版本控制只有间接相关性。 [API和发行版本建议](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)描述了API版本与软件版本之间的关系。
-
-不同的API版本名称意味着不同级别的软件稳定性和支持程度。 每个级别的标准在[API变更文档](https://git.k8s.io/community/contributors/devel/api_changes.md#alpha-beta-and-stable-versions)中有更详细的描述。 内容主要概括如下：
-
-* Alpha 测试版本：
-
-  * 版本名称包含了 **`alpha`** (例如：**`v1alpha1`**)。
-
-  * 可能是有缺陷的。启用该功能可能会带来隐含的问题，默认情况是关闭的。
-
-  * 支持的功能可能在没有通知的情况下随时删除。
-
-  * API的更改可能会带来兼容性问题，但是在后续的软件发布中不会有任何通知。
-
-  * 由于bugs风险的增加和缺乏长期的支持，推荐在短暂的集群测试中使用。
-
-* Beta 测试版本：
-
-  * 版本名称包含了 **`beta`** (例如: **`v2beta3`**)。
-
-  * 代码已经测试过。启用该功能被认为是安全的，功能默认已启用。
-
-  * 所有已支持的功能不会被删除，细节可能会发生变化。
-
-  * 对象的模式和/或语义可能会在后续的beta测试版或稳定版中以不兼容的方式进行更改。 发生这种情况时，我们将提供迁移到下一个版本的说明。 这可能需要删除、编辑和重新创建API对象。执行编辑操作时需要谨慎行事，这可能需要停用依赖该功能的应用程序。
-
-  * 建议仅用于非业务关键型用途，因为后续版本中可能存在不兼容的更改。 如果您有多个可以独立升级的群集，则可以放宽此限制。
-
-  * **请尝试我们的 beta 版本功能并且给出反馈！一旦他们退出 beta 测试版，我们可能不会做出更多的改变。**
-
-* 稳定版本：
-
-  * 版本名称是 **`vX`**，其中 **`X`** 是整数。
-
-  * 功能的稳定版本将出现在许多后续版本的发行软件中。
-
-## API 组
-
-为了更容易地扩展Kubernetes API，我们实现了[*`API组`*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)。 API组在REST路径和序列化对象的 **`apiVersion`** 字段中指定。
-
-目前有几个API组正在使用中：
-
-1. 核心组（通常被称为遗留组）位于REST路径 **`/api/v1`** 并使用 **`apiVersion：v1`**。
-
-1. 指定的组位于REST路径 **`/apis/$GROUP_NAME/$VERSION`**，并使用 **`apiVersion：$GROUP_NAME/$VERSION`**（例如 **`apiVersion：batch/v1`**）。 在[Kubernetes API参考](https://kubernetes.io/docs/reference/)中可以看到支持的API组的完整列表。
-
-社区支持使用以下两种方式来提供自定义资源对API进行扩展[自定义资源](https://kubernetes.io/docs/concepts/api-extension/custom-resources/)：
-
-1. [CustomResourceDefinition](https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)适用于具有非常基本的CRUD需求的用户。
-
-1. 即将推出：需要全套Kubernetes API语义的用户可以实现自己的apiserver，并使用[聚合器](https://git.k8s.io/community/contributors/design-proposals/api-machinery/aggregated-api-servers.md)为客户提供无缝的服务。
-
-## 启用 API 组
-
-某些资源和API组默认情况下处于启用状态。 可以通过在apiserver上设置 **`--runtime-config`** 来启用或禁用它们。 **`--runtime-config`** 接受逗号分隔的值。 例如：要禁用batch/v1，请设置**`--runtime-config=batch/v1=false`**，以启用batch/v2alpha1，请设置**`--runtime-config=batch/v2alpha1`**。 该标志接受描述apiserver的运行时配置的逗号分隔的一组键值对。
-
-重要：启用或禁用组或资源需要重新启动apiserver和控制器管理器来使得 **`--runtime-config`** 更改生效。
-
-## 启用组中资源
-
-DaemonSets，Deployments，HorizontalPodAutoscalers，Ingress，Jobs和ReplicaSets是默认启用的。 其他扩展资源可以通过在apiserver上设置 **`--runtime-config`** 来启用。**`--runtime-config`** 接受逗号分隔的值。
-
-例如：要禁用 Deployment 和 Ingress，请设置 **`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingress=false`**
@@ -1,118 +0,0 @@
---
-approvers:
- k8s-merge-robot
-
-title: 认识 Kubernetes?
---
-
-Kubernetes 是一个跨主机集群的 [开源的容器调度平台，它可以自动化应用容器的部署、扩展和操作](http://www.slideshare.net/BrianGrant11/wso2con-us-2015-kubernetes-a-platform-for-automating-deployment-scaling-and-operations) , 提供以容器为中心的基础架构。
-
-使用 Kubernetes, 您可以快速高效地响应客户需求:
-
- - 快速、可预测地部署您的应用程序
- - 拥有即时扩展应用程序的能力
- - 不影响现有业务的情况下，无缝地发布新功能
- - 优化硬件资源，降低成本
-
-我们的目标是构建一个软件和工具的生态系统，以减轻您在公共云或私有云运行应用程序的负担。
-
-#### Kubernetes 具有如下特点:
-
-* **便携性**: 无论公有云、私有云、混合云还是多云架构都全面支持
-* **可扩展**: 它是模块化、可插拔、可挂载、可组合的，支持各种形式的扩展
-* **自修复**: 它可以自保持应用状态、可自重启、自复制、自缩放的，通过声明式语法提供了强大的自修复能力
-
-Kubernetes 项目由 Google 公司在 2014 年启动。Kubernetes 建立在 [Google 公司超过十余年的运维经验基础之上，Google 所有的应用都运行在容器上](https://research.google.com/pubs/pub43438.html), 再与社区中最好的想法和实践相结合，也许它是最受欢迎的容器平台。
-
-##### 准备好 [开始](/docs/getting-started-guides/)?
-
-## 为什么是容器?
-
-查看此文，可以了解为什么您要使用容器 [容器](http://aucouranton.com/2014/06/13/linux-containers-parallels-lxc-openvz-docker-and-more/)?
-
-![为什么是容器?](/images/docs/why_containers.svg)
-
-*传统* 部署应用程序的方式，一般是使用操作系统自带的包管理器在主机上安装应用依赖，之后再安装应用程序。这无疑将应用程序的可执行文件、应用的配置、应用依赖库和应用的生命周期与宿主机操作系统进行了紧耦合。在此情境下，可以通过构建不可改变的虚拟机镜像版本，通过镜像版本实现可预测的发布和回滚，但是虚拟机实在是太重量级了，且镜像体积太庞大，便捷性差。
-
-*新方式* 是基于操作系统级虚拟化而不是硬件级虚拟化方法来部署容器。容器之间彼此隔离并与主机隔离：它们具有自己的文件系统，不能看到彼此的进程，并且它们所使用的计算资源是可以被限制的。它们比虚拟机更容易构建，并且因为它们与底层基础架构和主机文件系统隔离，所以它们可以跨云和操作系统快速分发。
-
-由于容器体积小且启动快，因此可以在每个容器镜像中打包一个应用程序。这种一对一的应用镜像关系拥有很多好处。使用容器，不需要与外部的基础架构环境绑定, 因为每一个应用程序都不需要外部依赖，更不需要与外部的基础架构环境依赖。完美解决了从开发到生产环境的一致性问题。
-
-容器同样比虚拟机更加透明，这有助于监测和管理。尤其是容器进程的生命周期由基础设施管理，而不是由容器内的进程对外隐藏时更是如此。最后，每个应用程序用容器封装，管理容器部署就等同于管理应用程序部署。
-
-容器优点摘要:
-
-* **敏捷的应用程序创建和部署**:
-    与虚拟机镜像相比，容器镜像更容易创建，提升了硬件的使用效率。
-* **持续开发、集成和部署**:
-    提供可靠与频繁的容器镜像构建和部署，可以很方便及快速的回滚 (由于镜像不可变性).
-* **关注开发与运维的分离**:
-    在构建/发布时创建应用程序容器镜像，从而将应用程序与基础架构分离。
-* **开发、测试和生产环境的一致性**:
-    在笔记本电脑上运行与云中一样。
-* **云和操作系统的可移植性**:
-    可运行在 Ubuntu, RHEL, CoreOS, 内部部署, Google 容器引擎和其他任何地方。
-* **以应用为中心的管理**:
-    提升了操作系统的抽象级别，以便在使用逻辑资源的操作系统上运行应用程序。
-* **松耦合、分布式、弹性伸缩 [微服务](http://martinfowler.com/articles/microservices.html)**:
-    应用程序被分成更小，更独立的部分，可以动态部署和管理 - 而不是巨型单体应用运行在专用的大型机上。
-* **资源隔离**:
-    通过对应用进行资源隔离，可以很容易的预测应用程序性能。
-* **资源利用**:
-    高效率和高密度。
-
-#### 为什么我们需要 Kubernetes，它能做什么?
-
-最基础的，Kubernetes 可以在物理或虚拟机集群上调度和运行应用程序容器。然而，Kubernetes 还允许开发人员从物理和虚拟机'脱离'，从以**主机为中心**的基础架构转移到以**容器为中心**的基础架构，这样可以提供容器固有的全部优点和益处。Kubernetes 提供了基础设施来构建一个真正以**容器为中心**的开发环境。
-
-Kubernetes 满足了生产中运行应用程序的许多常见的需求，例如：
-
-* [Pod](/docs/user-guide/pods/) 提供复合应用并保留一个应用一个容器的容器模型,
-* [挂载外部存储](/docs/user-guide/volumes/),
-* [Secret管理](/docs/user-guide/secrets/),
-* [应用健康检查](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/),
-* [副本应用实例](/docs/user-guide/replication-controller/),
-* [横向自动扩缩容](/docs/user-guide/horizontal-pod-autoscaling/),
-* [服务发现](/docs/user-guide/connecting-applications/),
-* [负载均衡](/docs/user-guide/services/),
-* [滚动更新](/docs/user-guide/update-demo/),
-* [资源监测](/docs/user-guide/monitoring/),
-* [日志采集和存储](/docs/user-guide/logging/overview/),
-* [支持自检和调试](/docs/user-guide/introspection-and-debugging/),
-* [认证和鉴权](/docs/admin/authorization/).
-
-这提供了平台即服务 (PAAS) 的简单性以及基础架构即服务 (IAAS) 的灵活性，并促进跨基础设施供应商的可移植性。
-
-有关详细信息，请参阅 [用户指南](/docs/user-guide/).
-
-#### 为什么 Kubernetes 是一个平台?
-
-Kubernetes 提供了很多的功能，总会有新的场景受益于新特性。它可以简化应用程序的工作流，加快开发速度。被大家认可的应用编排通常需要有较强的自动化能力。这就是为什么 Kubernetes 被设计作为构建组件和工具的生态系统平台，以便更轻松地部署、扩展和管理应用程序。
-
-[Label](/docs/user-guide/labels/) 允许用户按照自己的方式组织管理对应的资源。 [注解](/docs/user-guide/annotations/) 使用户能够以自定义的描述信息来修饰资源，以适用于自己的工作流，并为管理工具提供检查点状态的简单方法。
-
-此外，[Kubernetes 控制面 (Control Plane)](/docs/admin/cluster-components) 是构建在相同的 [APIs](/docs/api/) 上面，开发人员和用户都可以用。用户可以编写自己的控制器， [调度器](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/docs/devel/scheduler.md)等等，如果这么做，根据新加的[自定义 API](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/docs/design/extending-api.md) ，可以扩展当前的通用 [CLI 命令行工具](/docs/user-guide/kubectl-overview/)。
-
-这种 [设计](https://git.k8s.io/community/contributors/design-proposals/architecture/principles.md) 使得许多其他系统可以构建在 Kubernetes 之上。
-
-#### Kubernetes 不是什么:
-
-Kubernetes 不是一个传统意义上，包罗万象的 PaaS (平台即服务) 系统。我们保留用户选择的自由，这非常重要。
-
-* Kubernetes 不限制支持的应用程序类型。 它不插手应用程序框架 (例如 [Wildfly](http://wildfly.org/)), 不限制支持的语言运行时 (例如 Java, Python, Ruby)，只迎合符合 [12种因素的应用程序](http://12factor.net/)，也不区分"应用程序"与"服务"。Kubernetes 旨在支持极其多样化的工作负载，包括无状态、有状态和数据处理工作负载。如果应用可以在容器中运行，它就可以在 Kubernetes 上运行。
-* Kubernetes 不提供作为内置服务的中间件 (例如 消息中间件)、数据处理框架 (例如 Spark)、数据库 (例如 mysql)或集群存储系统 (例如 Ceph)。这些应用可以运行在 Kubernetes 上。
-* Kubernetes 没有提供点击即部署的服务市场
-* Kubernetes 从源代码到镜像都是非垄断的。 它不部署源代码且不构建您的应用程序。 持续集成 (CI) 工作流是一个不同用户和项目都有自己需求和偏好的领域。 所以我们支持在 Kubernetes 分层的 CI 工作流，但不指定它应该如何工作。
-* Kubernetes 允许用户选择其他的日志记录，监控和告警系统 (虽然我们提供一些集成作为概念验证)
-* Kubernetes 不提供或授权一个全面的应用程序配置语言/系统 (例如 [jsonnet](https://github.com/google/jsonnet)).
-* Kubernetes 不提供也不采用任何全面机器配置、保养、管理或自我修复系统
-
-另一方面，许多 PaaS 系统*运行*在 Kubernetes 上面，例如  [Openshift](https://github.com/openshift/origin), [Deis](http://deis.io/), and [Eldarion](http://eldarion.cloud/)。 您也可以自定义您自己的 PaaS, 与您选择的 CI 系统集成，或与 Kubernetes 一起使用: 将您的容器镜像部署到 Kubernetes。
-
-由于 Kubernetes 在应用级别而不仅仅在硬件级别上运行，因此它提供 PaaS 产品通用的一些功能，例如部署、扩展、负载均衡、日志记录、监控等。但是，Kubernetes 不是单一的，默认解决方案是可选和可插拔的。
-
-此处，Kubernetes 不仅仅是一个 "编排系统"；它消除了编排的需要。 "编排"技术定义的是工作流的执行: 从 A 到 B，然后到 C。相反，Kubernetes 是包括一套独立、可组合的控制过程，通过声明式语法使其连续地朝着期望状态驱动当前状态。 不需要告诉它具体从 A 到 C 的过程，只要告诉到 C 的状态即可。 也不需要集中控制；该方法更类似于"编舞"。这使得系统更容易使用并且更强大、更可靠、更具弹性和可扩展性。
-
-#### *Kubernetes* 是什么意思? K8s?
-
-名称 **Kubernetes** 源于希腊语，意为 "舵手" 或 "飞行员"， 且是英文 "governor" 和 ["cybernetic"](http://www.etymonline.com/index.php?term=cybernetics)的词根。 **K8s** 是通过将 8 个字母 "ubernete" 替换为 8 而导出的缩写。另外，在中文里，k8s 的发音与 Kubernetes 的发音比较接近。
@@ -1,99 +0,0 @@
---
-title: 理解 Kubernetes 对象
-
-redirect_from:
- "/docs/concepts/abstractions/overview/"
- "/docs/concepts/abstractions/overview.html"
-content_template: templates/concept
---
-
-{{% capture overview %}}
-
-本页说明了 Kubernetes 对象在 Kubernetes API 中是如何表示的，以及如何在 `.yaml` 格式的文件中表示。
-{{% /capture %}}
-
-{{% 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 的必需字段和对象规约：
-
-{{< code file="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 格式。
-
-{{% /capture %}}
-
-{{% capture whatsnext %}}
-
-* 了解最重要的基本 Kubernetes 对象，例如 [Pod](/docs/concepts/abstractions/pod/)。
-{{% /capture %}}
-
-
@@ -1,16 +0,0 @@
-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
@@ -1,219 +0,0 @@
---
-approvers:
- 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 >}}
-
-
-
-## 什么是 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. 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 安全策略的例子，所有字段的设置都被允许：
-
-{{< code file="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 控制基于角色和组的已授权容器的访问 。
@@ -1,18 +0,0 @@
-apiVersion: extensions/v1beta1
-kind: PodSecurityPolicy
-metadata:
-  name: permissive
-spec:
-  seLinux:
-    rule: RunAsAny
-  supplementalGroups:
-    rule: RunAsAny
-  runAsUser:
-    rule: RunAsAny
-  fsGroup:
-    rule: RunAsAny
-  hostPorts:
-  - min: 8000
-    max: 8080
-  volumes:
-  - '*'
@@ -1,75 +0,0 @@
---
-approvers:
- 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 >}}
-
-
-
-当 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。
-
-{{< code file="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 重新安装后被覆盖。因此，不建议修改该文件的内容。
@@ -1,371 +0,0 @@
---
-approvers:
- caesarxuchao
- lavalamp
- thockin
-title: 应用连接到 Service
---
-
-{{< 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，指示它具有一个容器端口的说明：
-
-{{< code file="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 文件：
-
-{{< code file="nginx-svc.yaml" >}}
-
-
-
-上述规约将创建一个 Service，对应具有标签 `run: my-nginx` 的 Pod，目标 TCP 端口 80，并且在一个抽象的 Service 端口（`targetPort`：容器接收流量的端口；`port`：抽象的 Service 端口，可以使任何其它 Pod 访问该 Service 的端口）上暴露。
-查看 [Service API 对象](/docs/api-reference/{{< param "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/{{< param "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/{{< param "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/{{< param "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）：
-
-{{< code file="nginx-secure-app.yaml" >}}
-
-
-
-关于 nginx-secure-app manifest 值得注意的点如下：
-
-
-
- 它在相同的文件中包含了 Deployment 和 Service 的规格
- [Nginx server](https://github.com/kubernetes/kubernetes/tree/{{< param "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）：
-
-{{< code file="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/) 获取更进一步信息。
@@ -1,25 +0,0 @@
-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
@@ -1,419 +0,0 @@
---
-approvers:
- davidopp
- thockin
-title: DNS Pod 与 Service
-redirect_from:
- "/docs/admin/dns/"
- "/docs/admin/dns.html"
---
-
-
-
-## 介绍
-
-Kubernetes 从 1.3 版本起， DNS 是内置的服务，通过插件管理器 [集群插件](http://releases.k8s.io/{{< param "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/{{< param "githubbranch" >}}/cluster/addons/dns/README.md)
-
-
-
-## 下一步
-
- [集群中 DNS Service 自动伸缩](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)
@@ -1,21 +0,0 @@
-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"
@@ -1,9 +0,0 @@
-apiVersion: extensions/v1beta1
-kind: Ingress
-metadata:
-  name: test-ingress
-spec:
-  backend:
-    serviceName: testsvc
-    servicePort: 80
-
@@ -1,103 +0,0 @@
---
-approvers:
- thockin
- caseydavenport
- danwinship
-title: 网络策略
---
-
-{{< toc >}}
-
-网络策略（NetworkPolicy）是一种关于pod间及pod与其他网络端点间所允许的通信规则的规范。
-
-`NetworkPolicy` 资源使用标签选择pod，并定义选定pod所允许的通信规则。
-
-## 前提
-
-网络策略通过网络插件来实现，所以用户必须使用支持 `NetworkPolicy` 的网络解决方案 - 简单地创建资源对象，而没有控制器来使它生效的话，是没有任何作用的。
-
-## 隔离和非隔离的Pod
-
-默认情况下，Pod是非隔离的，它们接受任何来源的流量。
-
-Pod可以通过相关的网络策略进行隔离。一旦命名空间中有网络策略选择了特定的Pod，该Pod会拒绝网络策略所不允许的连接。 (命名空间下其他未被网络策略所选择的Pod会继续接收所有的流量)
-
-## `NetworkPolicy` 资源
-
-通过[api参考](/docs/api-reference/{{< param "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/)
-  来进行更多的示例演练
@@ -1,630 +0,0 @@
---
-approvers:
- 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 >}}
-
-
-
-## 定义 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/{{< param "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/{{< param "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/{{< param "version" >}}/#service-v1-core)。
-
-
-
-## 更多信息
-
-阅读 [使用 Service 连接 Frontend 到 Backend](/docs/tutorials/connecting-apps/connecting-frontend-backend/)。
@@ -1,212 +0,0 @@
---
-approvers:
- 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 >}}
-
-
-
-## 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 完成后将不会被保留。
@@ -1,163 +0,0 @@
---
-approvers:
- erictune
-title: DaemonSet
-redirect_from:
- "/docs/admin/daemons/"
- "/docs/admin/daemons.html"
---
-
-{{< 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.kubernetes.io/not-ready` 和 `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。
-
@@ -1,36 +0,0 @@
-apiVersion: extensions/v1beta1
-kind: DaemonSet
-metadata:
-  name: fluentd-elasticsearch
-  namespace: kube-system
-  labels:
-    k8s-app: fluentd-logging
-spec:
-  template:
-    metadata:
-      labels:
-        name: fluentd-elasticsearch
-    spec:
-      containers:
-      - name: fluentd-elasticsearch
-        image: k8s.gcr.io/fluentd-elasticsearch:1.20
-        resources:
-          limits:
-            memory: 200Mi
-          requests:
-            cpu: 100m
-            memory: 200Mi
-        volumeMounts:
-        - name: varlog
-          mountPath: /var/log
-        - name: varlibdockercontainers
-          mountPath: /var/lib/docker/containers
-          readOnly: true
-      terminationGracePeriodSeconds: 30
-      volumes:
-      - name: varlog
-        hostPath:
-          path: /var/log
-      - name: varlibdockercontainers
-        hostPath:
-          path: /var/lib/docker/containers
@@ -1,947 +0,0 @@
---
-approvers:
- bgrant0607
- janetkuo
-title: Deployments
-content_template: templates/concept
---
-
-{{% 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 >}}
-**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 >}}
-
-{{% /capture %}}
-
-
-{{% 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.
-
-{{< code file="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 >}}
-**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 >}}
-**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 >}}
-**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 >}}
-**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 >}}
-**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/{{< param "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 >}}
-**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 >}}
-**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 >}}
-**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 Deployment 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 >}}
-**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/#restart-policy) 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 >}}
-**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/{{< param "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.
-
-{{% /capture %}}
-
-
@@ -1,45 +0,0 @@
-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
@@ -1,181 +0,0 @@
---
-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"
-
-content_template: templates/concept
---
-
-{{% capture overview %}}
-
-
-
-Kubernetes 垃圾收集器的角色是删除指定的对象，这些对象曾经有但以后不再拥有 Owner 了。
-
-**注意**：垃圾收集是 beta 特性，在 Kubernetes 1.4 及以上版本默认启用。
-
-{{% /capture %}}
-
-
-{{% 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：
-
-{{< code file="my-repset.yaml" >}}
-
-
-
-如果创建该 ReplicaSet，然后查看 Pod 的 metadata 字段，能够看到 OwnerReferences 字段：
-
-```shell
-kubectl create -f https://k8s.io/docs/concepts/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)
-
-{{% /capture %}}
-
-
-{{% 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)
-
-{{% /capture %}}
-
-
-
@@ -1,15 +0,0 @@
-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
-
@@ -1,17 +0,0 @@
-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
@@ -1,16 +0,0 @@
-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
@@ -1,331 +0,0 @@
---
-approvers:
- 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"
-content_template: templates/concept
---
-
-{{% capture overview %}}
-
-本页提供了 Init 容器的概览，它是一种专用的容器，在应用容器启动之前运行，并包括一些应用镜像中不存在的实用工具和安装脚本。
-{{% /capture %}}
-
-{{< 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/tasks/configure-pod-container/configure-pod-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 容器的功能。
-
-{{% /capture %}}
-
-
-{{% capture whatsnext %}}
-
-
-
-* [创建具有 Init 容器的 Pod](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container)
-
-{{% /capture %}}
-
-
-
@@ -1,175 +0,0 @@
---
-title: Pod 的生命周期
-redirect_from:
- "/docs/user-guide/pod-states/"
- "/docs/user-guide/pod-states.html"
-content_template: templates/concept
---
-
-{{% capture overview %}}
-
-{{< comment >}}Updated: 4/14/2015{{< /comment >}}
-{{< comment >}}Edited and moved to Concepts section: 2/2/17{{< /comment >}}
-
-该页面将描述 Pod 的生命周期。
-
-{{% /capture %}}
-
-{{% capture body %}}
-
-## Pod phase
-
-Pod 的 `status` 定义在 [PodStatus](/docs/resources-reference/v1.7/#podstatus-v1-core) 对象中，其中有一个 `phase` 字段。
-
-Pod 的运行阶段（phase）是 Pod 在其生命周期中的简单宏观概述。该阶段并不是对容器或 Pod 的综合汇总，也不是为了做为综合状态机。
-
-Pod 相位的数量和含义是严格指定的。除了本文档中列举的内容外，不应该再假定 Pod 有其他的 `phase` 值。
-
-下面是 `phase` 可能的值：
-
- 挂起（Pending）：Pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度 Pod 的时间和通过网络下载镜像的时间，这可能需要花点时间。
- 运行中（Running）：该 Pod 已经绑定到了一个节点上，Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态。
- 成功（Succeeded）：Pod 中的所有容器都被成功终止，并且不会再重启。
- 失败（Failed）：Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。
- 未知（Unknown）：因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。
-
-## Pod 状态
-
-Pod 有一个 PodStatus 对象，其中包含一个 [PodCondition](/docs/resources-reference/v1.7/#podcondition-v1-core) 数组。 PodCondition 数组的每个元素都有一个 `type` 字段和一个 `status` 字段。`type` 字段是字符串，可能的值有 PodScheduled、Ready、Initialized 和 Unschedulable。`status` 字段是一个字符串，可能的值有 True、False 和 Unknown。
-
-## 容器探针
-
-[探针](/docs/resources-reference/v1.7/#probe-v1-core) 是由 [kubelet](/docs/admin/kubelet/) 对容器执行的定期诊断。要执行诊断，kubelet 调用由容器实现的 [Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler)。有三种类型的处理程序：
-
- [ExecAction](/docs/resources-reference/v1.7/#execaction-v1-core)：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
- [TCPSocketAction](/docs/resources-reference/v1.7/#tcpsocketaction-v1-core)：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
- [HTTPGetAction](/docs/resources-reference/v1.7/#httpgetaction-v1-core)：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。
-
-每次探测都将获得以下三种结果之一：
-
- 成功：容器通过了诊断。
- 失败：容器未通过诊断。
- 未知：诊断失败，因此不会采取任何行动。
-
-Kubelet 可以选择是否执行在容器上运行的两种探针执行和做出反应：
-
- `livenessProbe`：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其 [重启策略](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 的影响。如果容器不提供存活探针，则默认状态为 `Success`。
- `readinessProbe`：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 `Failure`。如果容器不提供就绪探针，则默认状态为 `Success`。
-
-### 该什么时候使用存活（liveness）和就绪（readiness）探针?
-
-如果容器中的进程能够在遇到问题或不健康的情况下自行崩溃，则不一定需要存活探针; kubelet 将根据 Pod 的`restartPolicy` 自动执行正确的操作。
-
-如果您希望容器在探测失败时被杀死并重新启动，那么请指定一个存活探针，并指定`restartPolicy` 为 Always 或 OnFailure。
-
-如果要仅在探测成功时才开始向 Pod 发送流量，请指定就绪探针。在这种情况下，就绪探针可能与存活探针相同，但是 spec 中的就绪探针的存在意味着 Pod 将在没有接收到任何流量的情况下启动，并且只有在探针探测成功后才开始接收流量。
-
-如果您希望容器能够自行维护，您可以指定一个就绪探针，该探针检查与存活探针不同的端点。
-
-请注意，如果您只想在 Pod 被删除时能够排除请求，则不一定需要使用就绪探针；在删除 Pod 时，Pod 会自动将自身置于未完成状态，无论就绪探针是否存在。当等待 Pod 中的容器停止时，Pod 仍处于未完成状态。
-
-## Pod 和容器状态
-
-有关 Pod 容器状态的详细信息，请参阅 [PodStatus](/docs/resources-reference/v1.7/#podstatus-v1-core) 和 [ContainerStatus](/docs/resources-reference/v1.7/#containerstatus-v1-core)。请注意，报告的 Pod 状态信息取决于当前的 [ContainerState](/docs/resources-reference/v1.7/#containerstatus-v1-core)。
-
-## 重启策略
-
-PodSpec 中有一个 `restartPolicy` 字段，可能的值为 Always、OnFailure 和 Never。默认为 Always。 `restartPolicy` 适用于 Pod 中的所有容器。`restartPolicy` 仅指通过同一节点上的 kubelet 重新启动容器。失败的容器由 kubelet 以五分钟为上限的指数退避延迟（10秒，20秒，40秒...）重新启动，并在成功执行十分钟后重置。如 [Pod 文档](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof) 中所述，一旦绑定到一个节点，Pod 将永远不会重新绑定到另一个节点。
-
-## Pod 的生命
-
-一般来说，Pod 不会消失，直到人为销毁他们。这可能是一个人或控制器。这个规则的唯一例外是成功或失败的 `phase` 超过一段时间（由 master 确定）的Pod将过期并被自动销毁。
-
-有三种可用的控制器：
-
- 使用 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/) 运行预期会终止的 Pod，例如批量计算。Job 仅适用于重启策略为 `OnFailure` 或 `Never` 的 Pod。
-
-
- 对预期不会终止的 Pod 使用 [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/)、[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) 和 [Deployment](/docs/concepts/workloads/controllers/deployment/) ，例如 Web 服务器。 ReplicationController 仅适用于具有 `restartPolicy` 为 Always 的 Pod。
- 提供特定于机器的系统服务，使用 [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) 为每台机器运行一个 Pod 。
-
-所有这三种类型的控制器都包含一个 PodTemplate。建议创建适当的控制器，让它们来创建 Pod，而不是直接自己创建 Pod。这是因为单独的 Pod 在机器故障的情况下没有办法自动复原，而控制器却可以。
-
-如果节点死亡或与集群的其余部分断开连接，则 Kubernetes 将应用一个策略将丢失节点上的所有 Pod 的 `phase` 设置为 Failed。
-
-## 示例
-
-### 高级 liveness 探针示例
-
-存活探针由 kubelet 来执行，因此所有的请求都在 kubelet 的网络命名空间中进行。
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  labels:
-    test: liveness
-  name: liveness-http
-spec:
-  containers:
-  - args:
-    - /server
-    image: k8s.gcr.io/liveness
-    livenessProbe:
-      httpGet:
-        # when "host" is not defined, "PodIP" will be used
-        # host: my-host
-        # when "scheme" is not defined, "HTTP" scheme will be used. Only "HTTP" and "HTTPS" are allowed
-        # scheme: HTTPS
-        path: /healthz
-        port: 8080
-        httpHeaders:
-        - name: X-Custom-Header
-          value: Awesome
-      initialDelaySeconds: 15
-      timeoutSeconds: 1
-    name: liveness
-```
-
-### 状态示例
-
- Pod 中只有一个容器并且正在运行。容器成功退出。
-  - 记录完成事件。
-  - 如果 `restartPolicy` 为：
-    - Always：重启容器；Pod `phase` 仍为 Running。
-    - OnFailure：Pod `phase` 变成 Succeeded。
-    - Never：Pod `phase` 变成 Succeeded。
- Pod 中只有一个容器并且正在运行。容器退出失败。
-  - 记录失败事件。
-  - 如果 `restartPolicy` 为：
-    - Always：重启容器；Pod `phase` 仍为 Running。
-    - OnFailure：重启容器；Pod `phase` 仍为 Running。
-    - Never：Pod `phase` 变成 Failed。
- Pod 中有两个容器并且正在运行。有一个容器退出失败。
-  - 记录失败事件。
-  - 如果 restartPolicy 为：
-    - Always：重启容器；Pod `phase` 仍为 Running。
-    - OnFailure：重启容器；Pod `phase` 仍为 Running。
-    - Never：不重启容器；Pod `phase` 仍为 Running。
-  - 如果有一个容器没有处于运行状态，并且两个容器退出：
-    - 记录失败事件。
-    - 如果 `restartPolicy` 为：
-      - Always：重启容器；Pod `phase` 仍为 Running。
-      - OnFailure：重启容器；Pod `phase` 仍为 Running。
-      - Never：Pod `phase` 变成 Failed。
- Pod 中只有一个容器并处于运行状态。容器运行时内存超出限制：
-  - 容器以失败状态终止。
-  - 记录 OOM 事件。
-  - 如果 `restartPolicy` 为：
-    - Always：重启容器；Pod `phase` 仍为 Running。
-    - OnFailure：重启容器；Pod `phase` 仍为 Running。
-    - Never: 记录失败事件；Pod `phase` 仍为 Failed。
- Pod 正在运行，磁盘故障：
-  - 杀掉所有容器。
-  - 记录适当事件。
-  - Pod `phase` 变成 Failed。
-  - 如果使用控制器来运行，Pod 将在别处重建。
- Pod 正在运行，其节点被分段。
-  - 节点控制器等待直到超时。
-  - 节点控制器将 Pod `phase` 设置为 Failed。
-  - 如果是用控制器来运行，Pod 将在别处重建。
-
-{{% /capture %}}
-
-
-
@@ -1,72 +0,0 @@
---
-approvers:
- jessfraz
-title: Pod Preset
-content_template: templates/concept
---
-
-{{% capture overview %}}
-本文提供了 PodPreset 的概述。 在 pod 创建时，用户可以使用 `podpreset` 对象将特定信息注入
-pod 中，这些信息可以包括 secret、 卷、卷挂载和环境变量。
-{{% /capture %}}
-
-{{< toc >}}
-
-{{% capture body %}}
-## 理解 Pod Preset
-
-`Pod Preset` 是一种 API 资源，在 pod 创建时，用户可以用它将额外的运行时需求信息注入 pod。
-使用[标签选择器（label selector）](/docs/concepts/overview/working-with-objects/labels/#label-selectors)来指定 Pod Preset 所适用的 pod。
-
-使用 Pod Preset 使得 pod 模板编写者不必显式地为每个 pod 设置信息。
-这样，使用特定服务的 pod 模板编写者不需要了解该服务的所有细节。
-
-了解更多的相关背景信息，请参考 [ PodPreset 设计提案](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)。
-
-## PodPreset 如何工作
-
-Kubernetes 提供了准入控制器 (`PodPreset`)，该控制器被启用时，会将 Pod Preset 
-应用于接收到的 pod 创建请求中。
-当出现 pod 创建请求时，系统会执行以下操作：
-
-1. 检索所有可用 `PodPresets` 。
-1. 检查 `PodPreset` 的标签选择器与要创建的 pod 的标签是否匹配。
-1. 尝试合并 `PodPreset` 中定义的各种资源，并注入要创建的 pod。
-1. 发生错误时抛出事件，该事件记录了 pod 信息合并错误，同时在 _不注入_ `PodPreset` 信息的情况下创建 pod。
-1. 为改动的 pod spec 添加注解，来表明它被 `PodPreset` 所修改。 注解形如：
-`podpreset.admission.kubernetes.io/podpreset-<pod-preset name>": "<resource version>"`。
-
-一个 Pod 可能不与任何 Pod Preset 匹配，也可能匹配多个 Pod Preset。 同时，一个 `PodPreset` 
-可能不应用于任何 Pod，也可能应用于多个 Pod。 当 `PodPreset` 应用于一个或多个 Pod 时，Kubernetes
-修改 pod spec。 对于 `Env`、 `EnvFrom` 和 `VolumeMounts` 的改动， Kubernetes 修改 pod 
-中所有容器的规格，对于卷的改动，Kubernetes 修改 Pod spec。
-
-{{< note >}}
-**注意：** Pod Preset 能够在适当的时候修改 Pod spec 的 `spec.containers` 字段，
-但是不会应用于 `initContainers` 字段。
-{{< /note >}}
-
-### 为特定 Pod 禁用 Pod Preset
-
-在一些情况下，用户不希望 pod 被 pod preset 所改动，这时，用户可以在 pod spec 中添加形如
- `podpreset.admission.kubernetes.io/exclude: "true"` 的注解。
-
-## 启用 Pod Preset
-
-为了在集群中使用 Pod Preset，必须确保以下几点：
-
-1.  已启用 api 类型 `settings.k8s.io/v1alpha1/podpreset`。 这可以通过在 API 服务器的
-    `--runtime-config` 配置项中包含 `settings.k8s.io/v1alpha1=true` 来实现。
-1.  已启用准入控制器 `PodPreset`。 启用的一种方式是在 API 服务器的 `--admission-control`
-    配置项中包含 `PodPreset` 。
-1.  已经通过在相应的名字空间中创建 `PodPreset` 对象，定义了 Pod preset。
-
-{{% /capture %}}
-
-{{% capture whatsnext %}}
-
-* [使用 PodPreset 将信息注入 Pods](/docs/tasks/inject-data-application/podpreset/)
-
-{{% /capture %}}
-
-
@@ -1,187 +0,0 @@
---
-title: 同 Pod 内的容器使用共享卷通信
-redirect_from:
- "/docs/user-guide/pods/multi-container/"
- "/docs/user-guide/pods/multi-container.html"
- "/docs/tasks/configure-pod-container/communicate-containers-same-pod/"
- "/docs/tasks/configure-pod-container/communicate-containers-same-pod.html"
-content_template: templates/task
---
-
-
-{{% capture overview %}}
-
-
-
-本文旨在说明如何让一个 Pod 内的两个容器使用一个卷（Volume）进行通信。
-
-{{% /capture %}}
-
-
-{{% capture prerequisites %}}
-
-{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-{{% /capture %}}
-
-
-{{% capture steps %}}
-
-
-## 创建一个包含两个容器的 Pod
-
-
-
-
-在这个练习中，你会创建一个包含两个容器的 Pod。两个容器共享一个卷用于他们之间的通信。
-Pod 的配置文件如下：
-
-{{< code file="two-container-pod.yaml" >}}
-
-
-
-在配置文件中，你可以看到 Pod 有一个共享卷，名为 `shared-data`。
-
-
-
-
-
-配置文件中的第一个容器运行了一个 nginx 服务器。共享卷的挂载路径是 `/usr/share/nginx/html`。
-第二个容器是基于 debian 镜像的，有一个 `/pod-data` 的挂载路径。第二个容器运行了下面的命令然后终止。
-
-    echo Hello from the debian container > /pod-data/index.html
-
-
-
-注意，第二个容器在 nginx 服务器的根目录下写了 `index.html` 文件。
-
-
-创建一个包含两个容器的 Pod：
-
-    kubectl create -f https://k8s.io/docs/tasks/access-application-cluster/two-container-pod.yaml
-
-
-查看 Pod 和容器的信息：
-
-    kubectl get pod two-containers --output=yaml
-
-
-这是输出的一部分：
-
-    apiVersion: v1
-    kind: Pod
-    metadata:
-      ...
-      name: two-containers
-      namespace: default
-      ...
-    spec:
-      ...
-      containerStatuses:
-
-      - containerID: docker://c1d8abd1 ...
-        image: debian
-        ...
-        lastState:
-          terminated:
-            ...
-        name: debian-container
-        ...
-
-      - containerID: docker://96c1ff2c5bb ...
-        image: nginx
-        ...
-        name: nginx-container
-        ...
-        state:
-          running:
-        ...
-
-
-
-你可以看到 debian 容器已经被终止了，而 nginx 服务器依然在运行。
-
-
-进入 nginx 容器的 shell：
-
-    kubectl exec -it two-containers -c nginx-container -- /bin/bash
-
-
-在 shell 中，确认 nginx 还在运行。
-
-    root@two-containers:/# ps aux
-
-
-输出类似于这样：
-
-    USER       PID  ...  STAT START   TIME COMMAND
-    root         1  ...  Ss   21:12   0:00 nginx: master process nginx -g daemon off;
-
-
-
-回忆一下，debian 容器在 nginx 的根目录下创建了 `index.html` 文件。
-使用 `curl` 向 nginx 服务器发送一个 GET 请求：
-
-    root@two-containers:/# apt-get update
-    root@two-containers:/# apt-get install curl
-    root@two-containers:/# curl localhost
-
-
-输出表示 nginx 提供了 debian 容器写的页面：
-
-    Hello from the debian container
-
-{{% /capture %}}
-
-
-{{% capture discussion %}}
-
-
-## 讨论
-
-
-
-
-
-
-
-
-Pod 能有多个容器的主要原因是为了支持辅助应用（helper applications），以协助主应用（primary application）。
-辅助应用的典型例子是数据抽取，数据推送和代理。辅助应用和主应用经常需要相互通信。
-就如这个练习所示，通信通常是通过共享文件系统完成的，或者，也通过回环网络接口 localhost 完成。
-举个网络接口的例子，web 服务器带有一个协助程序用于拉取 Git 仓库的更新。
-
-
-
-
-在本练习中的卷为 Pod 生命周期中的容器相互通信提供了一种方法。如果 Pod 被删除或者重建了，
-任何共享卷中的数据都会丢失。
-
-{{% /capture %}}
-
-
-{{% capture whatsnext %}}
-
-
-
-* 更多学习内容
-[混合容器的方式](http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html)。
-
-
-
-* 学习 [模块化架构的混合容器](http://www.slideshare.net/Docker/slideshare-burns)。
-
-
-
-* 参见 [配置一个使用存储卷的 Pod](/docs/tasks/configure-pod-container/configure-volume-storage/)。
-
-
-* 参见 [卷](/docs/api-reference/{{< param "version" >}}/#volume-v1-core)。
-
-
-* 参见 [Pod](/docs/api-reference/{{< param "version" >}}/#pod-v1-core).
-
-{{% /capture %}}
-
-
-
@@ -1,126 +0,0 @@
---
-approvers:
- bprashanth
- davidopp
-title: 配置你的云平台防火墙
---
-
-
-
-
-
-
-许多云服务商（比如 Google Compute Engine）定义防火墙以防止服务无意间暴露到 internet 上。
-当暴露服务给外网时，你可能需要在防火墙上开启一个或者更多的端口来支持服务。
-本文描述了这个过程，以及其他云服务商的具体信息。
-
-
-## 负载均衡（LoadBalancer）服务的访问限制
-
- 
- 
- 
- 当以 `spec.type: LoadBalancer` 使用服务时，你可以使用 `spec.loadBalancerSourceRanges` 指定允许访问负载均衡的 IP 段。
- 这个字段采用 CIDR 的 IP 段，Kubernetes 会使用这个段配置防火墙。支持这个功能的平台目前有 Google Compute Engine，Google Kubernetes Engine 和 AWS。
- 如果云服务商不支持这个功能，这个字段会被忽略。
-
- 
- 
- 假设 10.0.0.0/8 是内部的子网。在下面这个例子中，会创建一个只有集群内部 ip 可以访问的负载均衡器。
- 集群外部的客户端是无法访问这个负载均衡器的。
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
-  name: myapp
-spec:
-  ports:
-    - port: 8765
-      targetPort: 9376
-  selector:
-    app: example
-  type: LoadBalancer
-  loadBalancerSourceRanges:
-  - 10.0.0.0/8
-```
-
- 
- 这个例子中，会创建一个只能被 IP 为 130.211.204.1 和 130.211.204.2 的客户端访问的负载据衡器。
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
-  name: myapp
-spec:
-  ports:
-    - port: 8765
-      targetPort: 9376
-  selector:
-    app: example
-  type: LoadBalancer
-  loadBalancerSourceRanges:
-  - 130.211.204.1/32
-  - 130.211.204.2/32
-```
-
-
-### 谷歌计算引擎（Google Compute Engine）
-
-
-
-
-当以 `spec.type: LoadBalancer` 使用服务时，防火墙会被自动打开。
-然而，当以 `spec.type: NodePort` 使用服务时，防火墙默认 *不会* 被打开。
-
-
-Google Compute Engine 的防火墙文档在[别处](https://cloud.google.com/compute/docs/networking#firewalls_1)。
-
-
-你可以使用 `gcloud` 命令行工具添加一个防火墙：
-
-```shell
-$ gcloud compute firewall-rules create my-rule --allow=tcp:<port>
-```
-
-
-
-**注意**
-使用 Google Compute Engine 平台的防火墙时有一个重要的关于安全的注意点：
-
-
-
-
-
-
-
-在 Kubernetes v1.0.0 版本，GCE 防火墙是定义按虚拟机（VM）来的，而不是按 ip 来的。
-这就意味着当你在防火墙上打开一个服务端口时，任何在那台虚拟机 IP 上的同一端口的服务
-都有被外部访问的潜在可能。注意，这对于其他 Kubernetes 服务来说不是问题，因为他们监
-听的 IP 地址与主机节点的外部 IP 地址不同。
-
-
-考虑一下:
-
-   * 你创建了一个服务，使用了外部服务均衡 (IP 地址为 1.2.3.4) 和 80 端口。
-   * 你在防火墙上为集群的所有节点都打开了 80 端口，所以外部的服务可以向你的
-     服务发送数据包。
-   * 你又在虚拟机（IP 为2.3.4.5）上使用 80 端口启动了一台 nginx 服务器.
-     这个 nginx 在虚拟机的外部 IP 地址上也被暴露到了 internet 上。
-
-
-
-
-因此，在 Google Compute Engine 或者 Google Kubernetes Engine 上开启防火墙端口时请
-小心。你可能无意间把其他服务也暴露给了 internet。
-
-
-这个问题会在 Kubernetes 后续版本中被修复。
-
-
-### 其他云服务商
-
-
-即将更新
-
@@ -1,224 +0,0 @@
---
-title: 使用 Service 把前端连接到后端
-content_template: templates/tutorial
---
-
-
-{{% capture overview %}}
-
-
-
-
-本任务会描述如何创建前端微服务和后端微服务。后端微服务是一个 hello 欢迎程序。
-前端和后端的连接是通过 Kubernetes 服务对象（Service object）完成的。
-
-{{% /capture %}}
-
-
-{{% capture objectives %}}
-
-
-
-
-* 使用部署对象（Deployment object）创建并运行一个微服务
-* 从后端将流量路由到前端
-* 使用服务对象把前端应用连接到后端应用
-
-{{% /capture %}}
-
-
-{{% capture prerequisites %}}
-
-* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
-* 本任务使用 [外部负载均衡服务](/docs/tasks/access-application-cluster/create-external-load-balancer/)，
-  所以需要对应的可支持此功能的环境。如果你的环境不能支持，你可以使用
-  [NodePort](/docs/user-guide/services/#type-nodeport) 类型的服务代替。
-
-{{% /capture %}}
-
-
-{{% capture lessoncontent %}}
-
-
-### 使用部署对象（Deployment）创建后端
-
-
-
-后端是一个简单的 hello 欢迎微服务应用。这是后端应用的 Deployment 配置文件：
-
-{{< code file="hello.yaml" >}}
-
-
-创建后端 Deployment：
-
-```
-kubectl create -f https://k8s.io/docs/tasks/access-application-cluster/hello.yaml
-```
-
-
-查看后端的 Deployment 信息：
-
-```
-kubectl describe deployment hello
-```
-
-
-输出类似于：
-
-```
-Name:                           hello
-Namespace:                      default
-CreationTimestamp:              Mon, 24 Oct 2016 14:21:02 -0700
-Labels:                         app=hello
-                                tier=backend
-                                track=stable
-Selector:                       app=hello,tier=backend,track=stable
-Replicas:                       7 updated | 7 total | 7 available | 0 unavailable
-StrategyType:                   RollingUpdate
-MinReadySeconds:                0
-RollingUpdateStrategy:          1 max unavailable, 1 max surge
-OldReplicaSets:                 <none>
-NewReplicaSet:                  hello-3621623197 (7/7 replicas created)
-Events:
-...
-```
-
-
-### 创建后端服务对象（Service object）
-
-
-
-
-
-前端连接到后端的关键是 Service。Service 创建一个固定 IP 和 DNS 解析名入口，
-使得后端微服务可达。Service 使用 selector 标签来寻找目标 Pod。
-
-
-首先，浏览 Service 的配置文件：
-
-{{< code file="hello-service.yaml" >}}
-
-
-
-配置文件中，你可以看到 Service 将流量路由到包含 `app: hello` 和 `tier: backend` 标签的 Pod。
-
-
-创建 `hello` Service：
-
-```
-kubectl create -f https://k8s.io/docs/tasks/access-application-cluster/hello-service.yaml
-```
-
-
-
-此时，你已经有了一个在运行的后端 Deployment，你也有了一个 Service 用于路由网络流量。
-
-
-### 创建前端应用
-
-
-
-
-
-既然你已经有了后端应用，你可以创建一个前端应用连接到后端。前端应用通过 DNS 名连接到后端的工作 Pods。
-DNS 名是 "hello"，也就是 Service 配置文件中 `name` 字段的值。
-
-
-
-前端 Deployment 中的 Pods 运行一个 nginx 镜像，这个已经配置好镜像去寻找后端的 hello Service。
-只是 nginx 的配置文件：
-
-{{< code file="frontend/frontend.conf" >}}
-
-
-
-
-与后端类似，前端用包含一个 Deployment 和一个 Service。Service 的配置文件包含了 `type: LoadBalancer`，
-也就是说，Service 会使用你的云服务商的默认负载均衡设备。
-
-{{< code file="frontend.yaml" >}}
-
-
-创建前端 Deployment 和 Service：
-
-```
-kubectl create -f https://k8s.io/docs/tasks/access-application-cluster/frontend.yaml
-```
-
-
-通过输出确认两个资源都已经被创建：
-
-```
-deployment "frontend" created
-service "frontend" created
-```
-
-
-
-
-
-
-**注意**：这个 nginx 配置文件是被打包在 [容器镜像](/docs/tasks/access-application-cluster/frontend/Dockerfile) 里的。
-更好的方法是使用 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)，这样的话你可以更轻易地更改配置。
-
-
-### 与前端 Service 交互
-
-
-
-一旦你创建了 LoadBalancer 类型的 Service，你可以使用这条命令查看外部 IP：
-
-```
-kubectl get service frontend
-```
-
-
-
-外部 IP 字段的生成可能需要一些时间。如果是这种情况，外部 IP 会显示为 `<pending>`。
-
-```
-NAME       CLUSTER-IP      EXTERNAL-IP   PORT(S)  AGE
-frontend   10.51.252.116   <pending>     80/TCP   10s
-```
-
-
-使用相同的命令直到它显示外部 IP 地址：
-
-```
-NAME       CLUSTER-IP      EXTERNAL-IP        PORT(S)  AGE
-frontend   10.51.252.116   XXX.XXX.XXX.XXX    80/TCP   1m
-```
-
-
-### 通过前端发送流量
-
-
-
-前端和后端已经完成连接了。你可以使用 curl 命令通过你的前端 Service 的外部 IP 访问服务端点。
-
-```
-curl http://<EXTERNAL-IP>
-```
-
-
-后端生成的消息输出如下：
-
-```
-{"message":"Hello"}
-```
-
-{{% /capture %}}
-
-
-{{% capture whatsnext %}}
-
-
-
-* 了解更多 [Services](/docs/concepts/services-networking/service/)
-* 了解更多 [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)
-
-{{% /capture %}}
-
-
@@ -1,34 +0,0 @@
-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"]
@@ -1,19 +0,0 @@
-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
@@ -1,33 +0,0 @@
-apiVersion: v1
-kind: Pod
-metadata:
-  labels:
-    name: redis
-    redis-sentinel: "true"
-    role: master
-  name: redis-master
-spec:
-  containers:
-    - name: master
-      image: k8s.gcr.io/redis:v1
-      env:
-        - name: MASTER
-          value: "true"
-      ports:
-        - containerPort: 6379
-      resources:
-        limits:
-          cpu: "0.1"
-      volumeMounts:
-        - mountPath: /redis-master-data
-          name: data
-    - name: sentinel
-      image: kubernetes/redis:v1
-      env:
-        - name: SENTINEL
-          value: "true"
-      ports:
-        - containerPort: 26379
-  volumes:
-    - name: data
-      emptyDir: {}
@@ -1,412 +0,0 @@
---
-approvers:
- derekwaynecarr
- janetkuo
-
-title: 应用资源配额和限额
-redirect_from:
- "/docs/admin/resourcequota/walkthrough/"
- "/docs/admin/resourcequota/walkthrough.html"
- "/docs/tasks/configure-pod-container/apply-resource-quota-limit/"
- "/docs/tasks/configure-pod-container/apply-resource-quota-limit.html"
-content_template: templates/task
---
-
-{{% capture overview %}}
-
-
-本示例展示了在一个 namespace 中控制资源用量的典型设置。
-
-
-本文展示了以下资源的使用： [Namespace](/docs/admin/namespaces), [ResourceQuota](/docs/concepts/policy/resource-quotas/) 和  [LimitRange](/docs/tasks/configure-pod-container/limit-range/)。
-
-{{% /capture %}}
-
-{{% capture prerequisites %}}
-
-* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-{{% /capture %}}
-
-{{% capture steps %}}
-
-## 场景
-
-
-集群管理员正在操作一个代表用户群体的集群，他希望控制一个特定 namespace 中可以被使用的资源总量，以达到促进对集群的公平共享及控制成本的目的。
-
-
-集群管理员有以下目标：
-
-
-* 限制运行中 pods 使用的计算资源数量
-* 限制 persistent volume claims 数量以控制对存储的访问
-* 限制 load balancers 数量以控制成本
-* 防止使用 node ports 以保留稀缺资源
-* 提供默认计算资源请求以实现更好的调度决策
-
-
-## 创建 namespace
-
-
-本示例将在一个自定义的 namespace 中运行，以展示相关概念。
-
-
-让我们创建一个叫做 quota-example 的新 namespace：
-
-```shell
-$ kubectl create namespace quota-example
-namespace "quota-example" created
-$ kubectl get namespaces
-NAME            STATUS    AGE
-default         Active    2m
-kube-system     Active    2m
-quota-example   Active    39s
-```
-
-
-## 应用 object-count 配额到 namespace
-
-
-集群管理员想要控制下列资源：
-
-* persistent volume claims
-* load balancers
-* node ports
-
-
-我们来创建一个简单的配额，用于控制这个 namespace 中那些资源类型的对象数量。
-
-```shell
-$ kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/rq-object-counts.yaml --namespace=quota-example
-resourcequota "object-counts" created
-```
-
-
-配额系统将察觉到有一个配额被创建，并且会计算 namespace 中的资源消耗量作为响应。这应该会很快发生。
-
-
-让我们显示一下配额来观察这个 namespace 中当前被消耗的资源：
-
-```shell
-$ kubectl describe quota object-counts --namespace=quota-example
-Name:                  object-counts
-Namespace:             quota-example
-Resource               Used    Hard
--------               ----    ----
-persistentvolumeclaims 0    2
-services.loadbalancers 0    2
-services.nodeports     0    0
-```
-
-
-配额系统现在将阻止用户创建比各个资源指定数量更多的资源。
-
-
-
-## 应用计算资源配额到 namespace
-
-
-为了限制这个 namespace 可以被使用的计算资源数量，让我们创建一个跟踪计算资源的配额。
-
-```shell
-$ kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/rq-compute-resources.yaml --namespace=quota-example
-resourcequota "compute-resources" created
-```
-
-
-让我们显示一下配额来观察这个 namespace 中当前被消耗的资源：
-
-```shell
-$ kubectl describe quota compute-resources --namespace=quota-example
-Name:                  compute-resources
-Namespace:             quota-example
-Resource               Used Hard
--------               ---- ----
-limits.cpu             0    2
-limits.memory          0    2Gi
-pods                   0    4
-requests.cpu           0    1
-requests.memory        0    1Gi
-```
-
-
-配额系统现在会防止 namespace 拥有超过 4 个没有终止的 pods。此外它还将强制 pod 中的每个容器配置一个 `request` 并为 `cpu` 和 `memory` 定义 `limit`。
-
-
-## 应用默认资源请求和限制
-
-
-Pod 的作者很少为它们的 pods 指定资源请求和限制。
-
-
-既然我们对项目应用了配额，我们来看一下当终端用户通过创建一个没有 cpu 和 内存限制的 pod 时会发生什么。这通过在 pod 里创建一个 nginx 容器实现。
-
-
-作为演示，让我们来创建一个运行 nginx 的 deployment：
-
-```shell
-$ kubectl run nginx --image=nginx --replicas=1 --namespace=quota-example
-deployment "nginx" created
-```
-
-
-现在我们来看一下创建的 pods。
-
-```shell
-$ kubectl get pods --namespace=quota-example
-```
-
-
-发生了什么？我一个 pods 都没有！让我们 describe 这个 deployment 来看看发生了什么。
-
-```shell
-$ kubectl describe deployment nginx --namespace=quota-example
-Name:                   nginx
-Namespace:              quota-example
-CreationTimestamp:      Mon, 06 Jun 2016 16:11:37 -0400
-Labels:                 run=nginx
-Selector:               run=nginx
-Replicas:               0 updated | 1 total | 0 available | 1 unavailable
-StrategyType:           RollingUpdate
-MinReadySeconds:        0
-RollingUpdateStrategy:  1 max unavailable, 1 max surge
-OldReplicaSets:         <none>
-NewReplicaSet:          nginx-3137573019 (0/1 replicas created)
-...
-```
-
-
-Deployment 创建了一个对应的 replica set 并尝试按照大小来创建一个 pod。
-
-
-让我们看看 replica set 的更多细节。
-
-```shell
-$ kubectl describe rs nginx-3137573019 --namespace=quota-example
-Name:                   nginx-3137573019
-Namespace:              quota-example
-Image(s):               nginx
-Selector:               pod-template-hash=3137573019,run=nginx
-Labels:                 pod-template-hash=3137573019
-                        run=nginx
-Replicas:               0 current / 1 desired
-Pods Status:            0 Running / 0 Waiting / 0 Succeeded / 0 Failed
-No volumes.
-Events:
-  FirstSeen    LastSeen    Count From                    SubobjectPath Type      Reason        Message
-  ---------    --------  ----- ----                    -------------    --------  ------        -------
-  4m        7s        11    {replicaset-controller }              Warning   FailedCreate  Error creating: pods "nginx-3137573019-" is forbidden: Failed quota: compute-resources: must specify limits.cpu,limits.memory,requests.cpu,requests.memory
-```
-
-
-Kubernetes API server 拒绝了  replica set 创建一个 pod 的请求，因为我们的 pods 没有为 `cpu` 和 `memory` 指定 `requests` 或 `limits`。
-
-
-因此，我们来为 pod 指定它可以使用的 `cpu` 和 `memory` 默认数量。
-
-```shell
-$ kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/rq-limits.yaml --namespace=quota-example
-limitrange "limits" created
-$ kubectl describe limits limits --namespace=quota-example
-Name:           limits
-Namespace:      quota-example
-Type      Resource  Min  Max  Default Request   Default Limit   Max Limit/Request Ratio
----      --------  ---  ---  ---------------   -------------   -----------------------
-Container memory    -    -    256Mi             512Mi           -
-Container cpu       -    -    100m              200m            -
-```
-
-
-如果 Kubernetes API server 发现一个 namespace 中有一个创建 pod 的请求，并且 pod 中的容器没有设置任何计算资源请求时，作为准入控制的一部分，一个默认的 request 和 limit 将会被应用。
-
-
-在本例中，创建的每个 pod 都将拥有如下的计算资源限制：
-
-```shell
-$ kubectl run nginx \
-  --image=nginx \
-  --replicas=1 \
-  --requests=cpu=100m,memory=256Mi \
-  --limits=cpu=200m,memory=512Mi \
-  --namespace=quota-example
-```
-
-
-由于已经为我们的 namespace 申请了默认的计算资源，我们的 replica set 应该能够创建它的 pods 了。
-
-```shell
-$ kubectl get pods --namespace=quota-example
-NAME                     READY     STATUS    RESTARTS   AGE
-nginx-3137573019-fvrig   1/1       Running   0          6m
-```
-
-
-而且如果打印出我们在这个 namespace 中的配额使用情况：
-
-```shell
-$ kubectl describe quota --namespace=quota-example
-Name:           compute-resources
-Namespace:      quota-example
-Resource        Used    Hard
--------        ----    ----
-limits.cpu      200m    2
-limits.memory   512Mi   2Gi
-pods            1       4
-requests.cpu    100m    1
-requests.memory 256Mi   1Gi
-
-
-Name:                 object-counts
-Namespace:            quota-example
-Resource              Used    Hard
--------              ----    ----
-persistentvolumeclaims 0      2
-services.loadbalancers 0      2
-services.nodeports     0      0
-```
-
-
-就像你看到的，创建的 pod 消耗了明确的计算资源量，并且正被 Kubernetes 正确的追踪着。
-
-
-## 高级配额 scopes
-
-
-让我们想象一下如果你不希望为你的 namespace 指定默认计算资源使用量。
-
-
-作为替换，你希望用户在它们的 namespace 中运行指定数量的 `BestEffort` pods，以从宽松的计算资源中获得好处。然后要求用户为需要更高质量服务的 pods 配置一个显式的资源请求。
-
-
-让我们新建一个拥有两个配额的 namespace 来演示这种行为：
-
-```shell
-$ kubectl create namespace quota-scopes
-namespace "quota-scopes" created
-$ kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/rq-best-effort.yaml --namespace=quota-scopes
-resourcequota "best-effort" created
-$ kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/rq-not-best-effort.yaml --namespace=quota-scopes
-resourcequota "not-best-effort" created
-$ kubectl describe quota --namespace=quota-scopes
-Name:       best-effort
-Namespace:  quota-scopes
-Scopes:     BestEffort
- * Matches all pods that have best effort quality of service.
-Resource    Used    Hard
--------    ----  ----
-pods        0     10
-
-
-Name:             not-best-effort
-Namespace:        quota-scopes
-Scopes:           NotBestEffort
- * Matches all pods that do not have best effort quality of service.
-Resource          Used  Hard
--------          ----  ----
-limits.cpu        0     2
-limits.memory     0     2Gi
-pods              0     4
-requests.cpu      0     1
-requests.memory   0     1Gi
-```
-
-
-在这种场景下，一个没有配置计算资源请求的 pod 将会被 `best-effort` 配额跟踪。
-
-
-而配置了计算资源请求的则会被 `not-best-effort` 配额追踪。
-
-
-让我们创建两个 deployments 作为演示：
-
-```shell
-$ kubectl run best-effort-nginx --image=nginx --replicas=8 --namespace=quota-scopes
-deployment "best-effort-nginx" created
-$ kubectl run not-best-effort-nginx \
-  --image=nginx \
-  --replicas=2 \
-  --requests=cpu=100m,memory=256Mi \
-  --limits=cpu=200m,memory=512Mi \
-  --namespace=quota-scopes
-deployment "not-best-effort-nginx" created
-```
-
-
-虽然没有指定默认的 limits，`best-effort-nginx` deployment 还是会创建 8 个 pods。这是由于它被 `best-effort` 配额追踪，而 `not-best-effort` 配额将忽略它。`not-best-effort` 配额将追踪 `not-best-effort-nginx` deployment，因为它创建的 pods 具有 `Burstable` 服务质量。 
-
-
-让我们列出 namespace 中的 pods：
-
-```shell
-$ kubectl get pods --namespace=quota-scopes
-NAME                                     READY     STATUS    RESTARTS   AGE
-best-effort-nginx-3488455095-2qb41       1/1       Running   0          51s
-best-effort-nginx-3488455095-3go7n       1/1       Running   0          51s
-best-effort-nginx-3488455095-9o2xg       1/1       Running   0          51s
-best-effort-nginx-3488455095-eyg40       1/1       Running   0          51s
-best-effort-nginx-3488455095-gcs3v       1/1       Running   0          51s
-best-effort-nginx-3488455095-rq8p1       1/1       Running   0          51s
-best-effort-nginx-3488455095-udhhd       1/1       Running   0          51s
-best-effort-nginx-3488455095-zmk12       1/1       Running   0          51s
-not-best-effort-nginx-2204666826-7sl61   1/1       Running   0          23s
-not-best-effort-nginx-2204666826-ke746   1/1       Running   0          23s
-```
-
-
-如你看到的，所有 10 个 pods 都已经被准许创建。
-
-
-让我们 describe 这个 namespace 当前的配额使用情况：
-
-```shell
-$ kubectl describe quota --namespace=quota-scopes
-Name:            best-effort
-Namespace:       quota-scopes
-Scopes:          BestEffort
- * Matches all pods that have best effort quality of service.
-Resource         Used  Hard
--------         ----  ----
-pods             8     10
-
-
-Name:               not-best-effort
-Namespace:          quota-scopes
-Scopes:             NotBestEffort
- * Matches all pods that do not have best effort quality of service.
-Resource            Used  Hard
--------            ----  ----
-limits.cpu          400m  2
-limits.memory       1Gi   2Gi
-pods                2     4
-requests.cpu        200m  1
-requests.memory     512Mi 1Gi
-```
-
-
-如你看到的，`best-effort` 配额追踪了我们在 `best-effort-nginx` deployment 中创建的 8 个 pods 的资源用量，而 `not-best-effort` 配额追踪了我们在 `not-best-effort-nginx` deployment 中创的两个 pods 的用量。 
-
-
-Scopes 提供了一种来对任何配额文档追踪的资源集合进行细分的机制，给操作人员部署和追踪资源消耗带来更大的灵活性。
-
-
-除 `BestEffort` 和 `NotBestEffort` scopes 之外，还有用于限制长时间运行和有时限 pods 的scopes。`Terminating` scope 将匹配任何 `spec.activeDeadlineSeconds` 不为 `nil` 的 pod。`NotTerminating` scope 将匹配任何 `spec.activeDeadlineSeconds` 为 `nil` 的 pod。这些 scopes 允许你基于 pods 在你集群中 node 上的预期持久程度来为它们指定配额。
-
-{{% /capture %}}
-
-{{% capture discussion %}}
-
-## 总结
-
-
-消耗节点 cpu 和 memory 资源的动作受到 namespace 配额定义的硬性配额限制的管制。
-
-
-任意消耗那些资源的动作能够被调整，或者获得一个 namespace 级别的默认值以符合你最终的目标。
-
-
-可以基于服务质量或者在你集群中节点上的预期持久程度来分配配额。
-
-{{% /capture %}}
-
-
@@ -1,226 +0,0 @@
---
-approvers:
- lavalamp
- thockin
-title: 集群管理
---
-
-
-{{< toc >}}
-
-
-本文描述了和集群生命周期相关的几个主题：创建新集群、更新集群的 master 和 worker 节点、执行节点维护（例如升级内核）以及升级运行中集群的 Kubernetes API 版本。
-
-
-## 创建和配置集群
-
-
-要在一组机器上安装 Kubernetes， 请根据您的环境，查阅现有的 [入门指南](/docs/getting-started-guides/) 
-
-
-## 升级集群
-
-
-集群升级当前是配套提供的，某些发布版本在升级时可能需要特殊处理。推荐管理员在升级他们的集群前，同时查阅 [发行说明](https://git.k8s.io/kubernetes/CHANGELOG.md) 和版本具体升级说明。
-
-
-* [升级到 1.6](/docs/admin/upgrade-1-6)
-
-
-### 升级 Google Compute Engine 集群
-
-
-Google Compute Engine Open Source (GCE-OSS) 通过删除和重建 master 来支持 master 升级。通过维持相同的 Persistent Disk (PD) 以保证在升级过程中保留数据。
-
-
-GCE 的 Node 升级采用 [管理实例组](https://cloud.google.com/compute/docs/instance-groups/)，每个节点将被顺序的删除，然后使用新软件重建。任何运行在那个节点上的 Pod 需要用 Replication Controller 控制，或者在扩容之后手动重建。
-
-
-开源 Google Compute Engine (GCE) 集群上的升级过程由 `cluster/gce/upgrade.sh` 脚本控制。
-
-
-运行 `cluster/gce/upgrade.sh -h` 获取使用说明。
-
-
-例如，只将 master 升级到一个指定的版本 (v1.0.2):
-
-```shell
-cluster/gce/upgrade.sh -M v1.0.2
-```
-
-
-或者，将整个集群升级到最新的稳定版本：
-
-```shell
-cluster/gce/upgrade.sh release/stable
-```
-
-
-### 升级 Google Kubernetes Engine 集群
-
-
-Google Kubernetes Engine 自动升级 master 组件（例如 `kube-apiserver`、`kube-scheduler`）至最新版本。它还负责 master 运行的操作系统和其它组件。
-
-
-节点升级过程由用户初始化，[Google Kubernetes Engine 文档](https://cloud.google.com/kubernetes-engine/docs/clusters/upgrade) 里有相关描述。
-
-
-### 在其他平台上升级集群
-
-
-不同的供应商和工具管理升级的过程各不相同。建议您查阅它们有关升级的主要文档。
-
-* [kops](https://github.com/kubernetes/kops)
-* [kubespray](https://github.com/kubernetes-incubator/kubespray)
-* [CoreOS Tectonic](https://coreos.com/tectonic/docs/latest/admin/upgrade.html)
-* ...
-
-
-## 调整集群大小
-
-
-如果集群资源短缺，您可以轻松的添加更多的机器，如果集群正运行在[节点自注册模式](/docs/admin/node/#self-registration-of-nodes)下的话。如果正在使用的是 GCE 或者 Google Kubernetes Engine，这将通过调整管理节点的实例组的大小完成。在  [Google Cloud Console page](https://console.developers.google.com) 的 `Compute > Compute Engine > Instance groups > your group > Edit group` 下修改实例数量或使用 gcloud CLI 都可以完成这个任务。
-
-```shell
-gcloud compute instance-groups managed resize kubernetes-minion-group --size 42 --zone $ZONE
-```
-
-
-实例组将负责在新机器上放置恰当的镜像并启动它们。Kubelet 将向 API server 注册它的节点以使其可以用于调度。如果您对  instance group 进行缩容，系统将会随机选取节点来终止。
-
-
-在其他环境上，您可能需要手动配置机器并告诉 Kubelet API server 在哪台机器上运行。
-
-
-### 集群自动伸缩
-
-
-如果正在使用 GCE 或者 Google Kubernetes Engine，您可以配置您的集群，使其能够基于 pod 需求自动重新调整大小。
-
-
-如  [Compute Resource](/docs/concepts/configuration/manage-compute-resources-container/) 所述，用户可以控制预留多少 CPU 和内存来分配给 pod。这个信息被 Kubernetes scheduler 用来寻找一个运行 pod 的地方。如果没有一个节点有足够的空闲容量（或者不能满足其他 pod 的需求），这个 pod 就需要等待某些 pod 结束，或者一个新的节点被添加。
-
-
-集群 autoscaler 查找不能被调度的 pod 并检查添加一个新节点（和集群中其它节点类似的）是否有帮助。如果是的话，它将调整集群的大小以容纳等待调度的 pod。
-
-
-如果发现在一段延时时间内（默认10分钟，将来有可能改变）某些节点不再需要，集群 autoscaler 也会缩小集群。
-
-
-集群 autoscaler 在每一个实例组（GCE）或节点池（Google Kubernetes Engine）上配置。
-
-
-如果您使用 GCE，那么您可以在使用 kube-up.sh 脚本创建集群的时候启用它。要想配置集群 autoscaler，您需要设置三个环境变量：
-
-
-* `KUBE_ENABLE_CLUSTER_AUTOSCALER` - 如果设置为 true 将启用集群 autoscaler。
-* `KUBE_AUTOSCALER_MIN_NODES` - 集群的最小节点数量。
-* `KUBE_AUTOSCALER_MAX_NODES` - 集群的最大节点数量。
-
-
-示例：
-
-```shell
-KUBE_ENABLE_CLUSTER_AUTOSCALER=true KUBE_AUTOSCALER_MIN_NODES=3 KUBE_AUTOSCALER_MAX_NODES=10 NUM_NODES=5 ./cluster/kube-up.sh
-```
-
-
-在 Google Kubernetes Engine 上，您可以在创建、更新集群或创建一个特别的节点池（您希望自动伸缩的）时，通过给对应的 `gcloud` 命令传递 `--enable-autoscaling` `--min-nodes` 和 `--max-nodes` 来配置集群 autoscaler。
-
-
-示例：
-
-```shell
-gcloud container clusters create mytestcluster --zone=us-central1-b --enable-autoscaling --min-nodes=3 --max-nodes=10 --num-nodes=5
-```
-
-```shell
-gcloud container clusters update mytestcluster --enable-autoscaling --min-nodes=1 --max-nodes=15
-```
-
-
-**集群 autoscaler 期望节点未被手动修改过（例如通过 kubectl 添加标签），因为那些属性可能不能被传递到相同节点组中的新节点上。**
-
-
-## 维护节点
-
-
-如果需要重启节点（例如内核升级、libc 升级、硬件维修等），且停机时间很短时，当 Kubelet 重启后，它将尝试重启调度到节点上的 pod。如果重启花费较长时间（默认时间为 5 分钟，由 controller-manager 的 `--pod-eviction-timeout` 控制），节点控制器将会结束绑定到这个不可用节点上的 pod。如果存在对应的 replica set（或者 replication controller）时，则将在另一个节点上启动  pod 的新副本。所以，如果所有的 pod 都是复制而来，那么在不是所有节点都同时停机的前提下，升级可以在不需要特殊调整情况下完成。
-
-
-如果您希望更多的控制升级过程，可以使用下面的工作流程：
-
-
-使用 `kubectl drain` 优雅的结束节点上的所有 pod 并同时标记节点为不可调度：
-
-```shell
-kubectl drain $NODENAME
-```
-
-
-在您正试图使节点离线时，这将阻止新的 pod 落到它们上面。
-
-
-对于有 replica set 的 pod 来说，它们将会被新的 pod 替换并且将被调度到一个新的节点。此外，如果 pod 是一个 service 的一部分，则客户端将被自动重定向到新的 pod。
-
-
-对于没有 replica set 的 pod，您需要手动启动 pod 的新副本，并且如果它不是 service 的一部分，您需要手动将客户端重定向到这个 pod。
-
-
-在节点上执行维护工作。
-
-
-重新使节点可调度：
-
-```shell
-kubectl uncordon $NODENAME
-```
-
-
-如果删除了节点的虚拟机实例并重新创建，那么一个新的可调度节点资源将被自动创建（只在您使用支持节点发现的云服务提供商时；当前只有 Google Compute Engine，不包括在 Google Compute Engine 上使用  kube-register 的 CoreOS）。相关详细信息，请查阅 [节点](/docs/admin/node)。
-
-
-## 高级主题
-
-
-### 升级到不同的 API 版本
-
-
-当新的 API 版本发布时，您可能需要升级集群支持新的 API 版本（例如当 'v2' 发布时从  'v1' 切换到 'v2'）。
-
-
-这不是一个经常性的事件，但需要谨慎的处理。这里有一系列升级到新 API 版本的步骤。
-
-      1. 开启新 API 版本。
-      2. 升级集群存储来使用新版本。
-      3. 升级所有配置文件。识别使用旧 API 版本 endpoint 的用户。
-      4. 运行 `cluster/update-storage-objects.sh` 升级存储中的现有对象为新版本。
-      5. 关闭旧 API 版本。
-
-
-### 打开或关闭集群的 API 版本
-
-
-可以在启动 API server 时传递 `--runtime-config=api/<version>` 标志来打开或关闭特定的 API 版本。例如：要关闭 v1 API，请传递 `--runtime-config=api/v1=false`。运行时配置还支持两个特殊键值：api/all 和 api/legacy，分别控制全部和遗留 API。例如要关闭除 v1 外全部 API 版本，请传递 `--runtime-config=api/all=false,api/v1=true`。对于这些标志来说，_legacy_ API 指那些被显式废弃的 API（例如  `v1beta3`）。
-
-
-### 切换集群存储的 API 版本
-
-
-存储于磁盘中，用于在集群内部代表 Kubernetes 活跃资源的对象使用特定的 API 版本书写。当支撑的 API 改变时，这些对象可能需要使用更新的 API 重写。重写失败将最终导致资源不再能够被 Kubernetes API server 解析或使用。
-
-
-`kube-apiserver` 二进制文件的 `KUBE_API_VERSIONS` 环境变量控制了集群支持的 API 版本。列表中的第一个版本被用作集群的存储版本。因此，要设置特定的版本为存储版本，请将其放在 `KUBE_API_VERSIONS` 参数值版本列表的最前面。您需要重启 `kube-apiserver` 二进制以使这个变量的改动生效。
-
-
-### 切换配置文件为新 API 版本
-
-
-可以使用 `kubectl convert` 命令对不同 API 版本的配置文件进行转换。
-
-```shell
-kubectl convert -f pod.yaml --output-version v1
-```
-
-
-更多选项请参考 [kubectl convert](/docs/user-guide/kubectl/v1.6/#convert)  命令用法。
@@ -1,33 +0,0 @@
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: kube-dns-autoscaler
-  namespace: kube-system
-  labels:
-    k8s-app: kube-dns-autoscaler
-spec:
-  selector:
-    matchLabels:
-       k8s-app: kube-dns-autoscaler
-  template:
-    metadata:
-      labels:
-        k8s-app: kube-dns-autoscaler
-    spec:
-      containers:
-      - name: autoscaler
-        image: k8s.gcr.io/cluster-proportional-autoscaler-amd64:1.1.1
-        resources:
-            requests:
-                cpu: "20m"
-                memory: "10Mi"
-        command:
-          - /cluster-proportional-autoscaler
-          - --namespace=kube-system
-          - --configmap=kube-dns-autoscaler
-          - --target=<SCALE_TARGET>
-          # When cluster is using large nodes(with more cores), "coresPerReplica" should dominate.
-          # If using small nodes, "nodesPerReplica" should dominate.
-          - --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"min":1}}
-          - --logtostderr=true
-          - --v=2
@@ -1,11 +0,0 @@
-apiVersion: v1
-kind: Pod
-metadata:
-  name: default-mem-demo-2
-spec:
-  containers:
-  - name: defalt-mem-demo-2-ctr
-    image: nginx
-    resources:
-      limits:
-        memory: "1Gi"
@@ -1,43 +0,0 @@
-apiVersion: apps/v1beta1
-kind: Deployment
-metadata:
-  labels:
-    component: scheduler
-    tier: control-plane
-  name: my-scheduler
-  namespace: kube-system
-spec:
-  replicas: 1
-  template:
-    metadata:
-      labels:
-        component: scheduler
-        tier: control-plane
-        version: second
-    spec:
-      containers:
-      - command:
-        - /usr/local/bin/kube-scheduler
-        - --address=0.0.0.0
-        - --leader-elect=false
-        - --scheduler-name=my-scheduler
-        image: gcr.io/my-gcp-project/my-kube-scheduler:1.0
-        livenessProbe:
-          httpGet:
-            path: /healthz
-            port: 10251
-          initialDelaySeconds: 15
-        name: kube-second-scheduler
-        readinessProbe:
-          httpGet:
-            path: /healthz
-            port: 10251
-        resources:
-          requests:
-            cpu: '0.1'
-        securityContext:
-          privileged: false
-        volumeMounts: []
-      hostNetwork: false
-      hostPID: false
-      volumes: []
@@ -1,14 +0,0 @@
-apiVersion: apps/v1beta1
-kind: Deployment
-metadata:
-  name: pod-quota-demo
-spec:
-  replicas: 3
-  template:
-    metadata:
-      labels:
-        purpose: quota-demo
-    spec:
-      containers:
-      - name: pod-quota-demo
-        image: nginx
@@ -1,11 +0,0 @@
-kind: PersistentVolumeClaim
-apiVersion: v1
-metadata:
-  name: pvc-quota-demo-2
-spec:
-  storageClassName: manual
-  accessModes:
-    - ReadWriteOnce
-  resources:
-    requests:
-      storage: 4Gi
@@ -1,16 +0,0 @@
-apiVersion: v1
-kind: Pod
-metadata:
-  name: cpu-demo-2
-spec:
-  containers:
-  - name: cpu-demo-ctr-2
-    image: vish/stress
-    resources:
-      limits:
-        cpu: "100"
-      requests:
-        cpu: "100"
-    args:
-    - -cpus
-    - "2"
@@ -1,16 +0,0 @@
-apiVersion: v1
-kind: Pod
-metadata:
-  name: cpu-demo
-spec:
-  containers:
-  - name: cpu-demo-ctr
-    image: vish/stress
-    resources:
-      limits:
-        cpu: "1"
-      requests:
-        cpu: "0.5"
-    args:
-    - -cpus
-    - "2"
--- a/Show More
+++ b/Show More