diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES
index 9498e2c228..c39698ba81 100644
--- a/OWNERS_ALIASES
+++ b/OWNERS_ALIASES
@@ -107,10 +107,12 @@ aliases:
- danninov
sig-docs-it-owners: # Admins for Italian content
- fabriziopandini
+ - Fale
- mattiaperi
- micheleberardi
sig-docs-it-reviews: # PR reviews for Italian content
- fabriziopandini
+ - Fale
- mattiaperi
- micheleberardi
sig-docs-ja-owners: # Admins for Japanese content
@@ -138,6 +140,7 @@ aliases:
- ianychoi
- seokho-son
- ysyukr
+ - pjhwa
sig-docs-leads: # Website chairs and tech leads
- jimangel
- kbarnard10
@@ -214,4 +217,4 @@ aliases:
- butuzov
- idvoretskyi
- MaxymVlasov
- - Potapy4
\ No newline at end of file
+ - Potapy4
diff --git a/README.md b/README.md
index d4c13cb77c..9ff0c14e53 100644
--- a/README.md
+++ b/README.md
@@ -58,6 +58,43 @@ 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.
+### Troubleshooting macOS for too many open files
+
+If you run `make serve` on macOS and receive the following error:
+
+```
+ERROR 2020/08/01 19:09:18 Error: listen tcp 127.0.0.1:1313: socket: too many open files
+make: *** [serve] Error 1
+```
+
+Try checking the current limit for open files:
+
+`launchctl limit maxfiles`
+
+Then run the following commands:
+
+```
+#!/bin/sh
+
+# These are the original gist links, linking to my gists now.
+# curl -O https://gist.githubusercontent.com/a2ikm/761c2ab02b7b3935679e55af5d81786a/raw/ab644cb92f216c019a2f032bbf25e258b01d87f9/limit.maxfiles.plist
+# curl -O https://gist.githubusercontent.com/a2ikm/761c2ab02b7b3935679e55af5d81786a/raw/ab644cb92f216c019a2f032bbf25e258b01d87f9/limit.maxproc.plist
+
+curl -O https://gist.githubusercontent.com/tombigel/d503800a282fcadbee14b537735d202c/raw/ed73cacf82906fdde59976a0c8248cce8b44f906/limit.maxfiles.plist
+curl -O https://gist.githubusercontent.com/tombigel/d503800a282fcadbee14b537735d202c/raw/ed73cacf82906fdde59976a0c8248cce8b44f906/limit.maxproc.plist
+
+sudo mv limit.maxfiles.plist /Library/LaunchDaemons
+sudo mv limit.maxproc.plist /Library/LaunchDaemons
+
+sudo chown root:wheel /Library/LaunchDaemons/limit.maxfiles.plist
+sudo chown root:wheel /Library/LaunchDaemons/limit.maxproc.plist
+
+sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
+```
+
+This works for Catalina as well as Mojave macOS.
+
+
# Get involved with SIG Docs
Learn more about SIG Docs Kubernetes community and meetings on the [community page](https://github.com/kubernetes/community/tree/master/sig-docs#meetings).
@@ -102,4 +139,4 @@ Participation in the Kubernetes community is governed by the [CNCF Code of Condu
# Thank you!
-Kubernetes thrives on community participation, and we appreciate your contributions to our website and our documentation!
\ No newline at end of file
+Kubernetes thrives on community participation, and we appreciate your contributions to our website and our documentation!
diff --git a/assets/scss/_base.scss b/assets/scss/_base.scss
index ad462067c6..4b9125bcd9 100644
--- a/assets/scss/_base.scss
+++ b/assets/scss/_base.scss
@@ -832,3 +832,16 @@ section#cncf {
font-size: 1rem;
}
}
+
+/* DOCUMENTATION */
+
+body.td-documentation {
+ header > .header-filler {
+ height: $hero-padding-top;
+ background-color: black;
+ }
+ /* Special case for if an announcement is active */
+ header section#announcement ~ .header-filler {
+ display: none;
+ }
+}
diff --git a/assets/scss/_custom.scss b/assets/scss/_custom.scss
index 6d353c380c..563d87272f 100644
--- a/assets/scss/_custom.scss
+++ b/assets/scss/_custom.scss
@@ -1,3 +1,5 @@
+$announcement-size-adjustment: 8px;
+
/* GLOBAL */
.td-main {
.row {
@@ -284,6 +286,82 @@ blockquote {
border-left-color: #d9534f !important;
}
+.deprecation-warning {
+ padding: 20px;
+ margin: 20px 0;
+ background-color: #faf5b6;
+ color: #000;
+}
+
+body.td-home .deprecation-warning, body.td-blog .deprecation-warning, body.td-documentation .deprecation-warning {
+ border-radius: 3px;
+}
+
+body.td-home #deprecation-warning {
+ max-width: 1000px;
+ margin-top: 2.5rem;
+ margin-left: auto;
+ margin-right: auto;
+}
+
+#caseStudies body > #deprecation-warning, body.cid-casestudies > #deprecation-warning, body.cid-community > #deprecation-warning {
+ display: inline-block;
+ vertical-align: top;
+ position: relative;
+ background-color: #326ce5; // Kubernetes blue
+ color: #fff;
+ padding: 0;
+ margin: 0;
+ width: 100vw;
+}
+#caseStudies body > #deprecation-warning, body.cid-casestudies > #deprecation-warning {
+ padding-top: 32px;
+}
+body.cid-partners > #deprecation-warning {
+ padding: 0;
+ margin-right: 0;
+ margin-left: 0;
+ margin-top: 0;
+ width: 100vw;
+}
+body.cid-partners > #deprecation-warning > .content {
+ width: 100%;
+ max-width: initial;
+ margin-right: 0;
+ margin-left: 0;
+ margin-top: 0;
+ padding-left: 5vw;
+ padding-right: 5vw;
+ padding-top: 2rem;
+ padding-bottom: 2rem;
+}
+body.cid-community > #deprecation-warning > .deprecation-warning {
+ margin-left: 20px;
+ margin-right: 20px;
+ color: #faf5b6;
+ background-color: inherit;
+}
+body.cid-community > #deprecation-warning > .deprecation-warning > * {
+ color: inherit;
+ background-color: inherit;
+}
+
+#caseStudies body > #deprecation-warning > .deprecation-warning, body.cid-casestudies > #deprecation-warning > .deprecation-warning {
+ color: inherit;
+ background: inherit;
+ width: 80%;
+ margin: 0;
+ margin-top: 120px;
+ margin-left: auto;
+ margin-right: auto;
+ border-radius: initial;
+}
+#deprecation-warning > .deprecation-warning a {
+ background: transparent;
+ color: inherit;
+ text-decoration: underline;
+}
+
// search & sidebar
.td-sidebar {
@media only screen and (min-width: 768px) {
@@ -390,4 +468,47 @@ main.content {
}
}
}
-}
\ No newline at end of file
+}
+
+/* ANNOUNCEMENTS */
+section#fp-announcement ~ .header-hero {
+ padding: $announcement-size-adjustment 0;
+
+ > div {
+ margin-top: $announcement-size-adjustment;
+ margin-bottom: $announcement-size-adjustment;
+ }
+
+ h1, h2, h3, h4, h5 {
+ margin: $announcement-size-adjustment 0;
+ }
+}
+
+section#announcement ~ .header-hero {
+ padding: #{$announcement-size-adjustment / 2} 0;
+
+ > div {
+ margin-top: #{$announcement-size-adjustment / 2};
+ margin-bottom: #{$announcement-size-adjustment / 2};
+ padding-bottom: #{$announcement-size-adjustment / 2};
+ }
+
+ h1, h2, h3, h4, h5 {
+ margin: #{$announcement-size-adjustment / 2} 0;
+ }
+}
+
+/* DOCUMENTATION */
+
+/* Don't show lead text */
+body.td-documentation {
+ main {
+ @media only screen {
+ > * {
+ > .lead:first-of-type {
+ display: none;
+ }
+ }
+ }
+ }
+}
diff --git a/assets/scss/_tablet.scss b/assets/scss/_tablet.scss
index 299e50eebd..b368d54494 100644
--- a/assets/scss/_tablet.scss
+++ b/assets/scss/_tablet.scss
@@ -23,7 +23,7 @@ $main-nav-left-button-size: 50px;
$main-nav-left-button-font-size: 18px;
// hero
-$hero-padding-top: 136px;
+$hero-padding-top: 116px;
$headline-wrapper-margin-bottom: 40px;
$quickstart-button-padding: 0 50px;
$vendor-strip-font-size: 16px;
diff --git a/content/de/docs/tasks/administer-cluster/_index.md b/content/de/docs/tasks/administer-cluster/_index.md
index 50eeb8f461..42cb183b03 100755
--- a/content/de/docs/tasks/administer-cluster/_index.md
+++ b/content/de/docs/tasks/administer-cluster/_index.md
@@ -1,5 +1,6 @@
---
title: "Einen Cluster verwalten"
+description: Lerne allgemeine Aufgaben zur Verwaltung eines Clusters kennen.
weight: 20
---
diff --git a/content/de/docs/tasks/administer-cluster/kubeadm/_index.md b/content/de/docs/tasks/administer-cluster/kubeadm/_index.md
new file mode 100644
index 0000000000..d965870f67
--- /dev/null
+++ b/content/de/docs/tasks/administer-cluster/kubeadm/_index.md
@@ -0,0 +1,5 @@
+---
+title: "Verwaltung mit kubeadm"
+weight: 10
+---
+
diff --git a/content/de/docs/tutorials/_index.md b/content/de/docs/tutorials/_index.md
index 1dcbbd8a63..e00382c893 100644
--- a/content/de/docs/tutorials/_index.md
+++ b/content/de/docs/tutorials/_index.md
@@ -46,16 +46,6 @@ Bevor Sie die einzelnen Lernprogramme durchgehen, möchten Sie möglicherweise e
* [ZooKeeper, ein verteiltes CP-System](/docs/tutorials/stateful-application/zookeeper/)
-## CI/CD Pipeline
-
-* [Einrichten einer CI/CD-Pipeline mit Kubernetes Teil 1: Übersicht](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/5/set-cicd-pipeline-kubernetes-part-1-overview)
-
-* [Einrichten einer CI/CD-Pipeline mit einem Jenkins-Pod in Kubernetes (Teil 2)](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/6/set-cicd-pipeline-jenkins-pod-kubernetes-part-2)
-
-* [Ausführen und Skalieren einer verteilten Kreuzworträtsel-App mit CI/CD auf Kubernetes (Teil 3)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/run-and-scale-distributed-crossword-puzzle-app-cicd-kubernetes-part-3)
-
-* [CI/CD für eine verteilte Kreuzworträtsel-App auf Kubernetes einrichten (Teil 4)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/set-cicd-distributed-crossword-puzzle-app-kubernetes-part-4)
-
## Clusters
* [AppArmor](/docs/tutorials/clusters/apparmor/)
diff --git a/content/en/blog/_posts/2018-12-04-kubeadm-ga-release.md b/content/en/blog/_posts/2018-12-04-kubeadm-ga-release.md
index b2ea7cb71b..8601a7b94d 100644
--- a/content/en/blog/_posts/2018-12-04-kubeadm-ga-release.md
+++ b/content/en/blog/_posts/2018-12-04-kubeadm-ga-release.md
@@ -23,7 +23,7 @@ To keep kubeadm lean, focused, and vendor/infrastructure agnostic, the following
- Non-critical add-ons, e.g. for monitoring, logging, and visualization
- Specific cloud provider integrations
-Infrastructure provisioning, for example, is left to other SIG Cluster Lifecycle projects, such as the [Cluster API](https://github.com/kubernetes-sigs/cluster-api). Instead, kubeadm covers only the common denominator in every Kubernetes cluster: the [control plane](/docs/concepts/#kubernetes-control-plane). The user may install their preferred networking solution and other add-ons on top of Kubernetes *after* cluster creation.
+Infrastructure provisioning, for example, is left to other SIG Cluster Lifecycle projects, such as the [Cluster API](https://github.com/kubernetes-sigs/cluster-api). Instead, kubeadm covers only the common denominator in every Kubernetes cluster: the [control plane](/docs/concepts/overview/components/#control-plane-components). The user may install their preferred networking solution and other add-ons on top of Kubernetes *after* cluster creation.
### What kubeadm's GA release means
diff --git a/content/en/blog/_posts/2019-06-24-kubeadm-ha-v115.md b/content/en/blog/_posts/2019-06-24-kubeadm-ha-v115.md
index f0ff1f75cc..b2d377d0eb 100644
--- a/content/en/blog/_posts/2019-06-24-kubeadm-ha-v115.md
+++ b/content/en/blog/_posts/2019-06-24-kubeadm-ha-v115.md
@@ -43,7 +43,7 @@ Those tasks are addressed by other SIG Cluster Lifecycle projects, such as the
[Cluster API](https://github.com/kubernetes-sigs/cluster-api) for infrastructure provisioning and management.
Instead, kubeadm covers only the common denominator in every Kubernetes cluster: the
-[control plane](https://kubernetes.io/docs/concepts/#kubernetes-control-plane).
+[control plane](/docs/concepts/overview/components/#control-plane-components).
diff --git a/content/en/blog/_posts/2020-05-29-K8s-KPIs-with-Kuberhealthy.md b/content/en/blog/_posts/2020-05-29-K8s-KPIs-with-Kuberhealthy.md
index c812715154..608524738e 100644
--- a/content/en/blog/_posts/2020-05-29-K8s-KPIs-with-Kuberhealthy.md
+++ b/content/en/blog/_posts/2020-05-29-K8s-KPIs-with-Kuberhealthy.md
@@ -175,7 +175,7 @@ We calculate this by measuring Kuberhealthy's [deployment check](https://github.
- PromQL Query (Availability % over the past 30 days):
```promql
- 1 - (sum(count_over_time(kuberhealthy_check{check="kuberhealthy/deployment", status="0"}[30d])) OR vector(0))/(sum(count_over_time(kuberhealthy_check{check="kuberhealthy/deployment", status="1"}[30d])) * 100)
+ 1 - (sum(count_over_time(kuberhealthy_check{check="kuberhealthy/deployment", status="0"}[30d])) OR vector(0)) / sum(count_over_time(kuberhealthy_check{check="kuberhealthy/deployment", status="1"}[30d]))
```
*Utilization*
diff --git a/content/en/blog/_posts/2020-08-14-introducing-hierarchical-namespaces.md b/content/en/blog/_posts/2020-08-14-introducing-hierarchical-namespaces.md
new file mode 100644
index 0000000000..3778240f6c
--- /dev/null
+++ b/content/en/blog/_posts/2020-08-14-introducing-hierarchical-namespaces.md
@@ -0,0 +1,199 @@
+---
+layout: blog
+title: "Introducing Hierarchical Namespaces"
+date: 2020-08-14
+---
+
+**Author**: Adrian Ludwin (Google)
+
+Safely hosting large numbers of users on a single Kubernetes cluster has always
+been a troublesome task. One key reason for this is that different organizations
+use Kubernetes in different ways, and so no one tenancy model is likely to suit
+everyone. Instead, Kubernetes offers you building blocks to create your own
+tenancy solution, such as Role Based Access Control (RBAC) and NetworkPolicies;
+the better these building blocks, the easier it is to safely build a multitenant
+cluster.
+
+# Namespaces for tenancy
+
+By far the most important of these building blocks is the namespace, which forms
+the backbone of almost all Kubernetes control plane security and sharing
+policies. For example, RBAC, NetworkPolicies and ResourceQuotas all respect
+namespaces by default, and objects such as Secrets, ServiceAccounts and
+Ingresses are freely usable _within_ any one namespace, but fully segregated
+from _other_ namespaces.
+
+Namespaces have two key properties that make them ideal for policy enforcement.
+Firstly, they can be used to **represent ownership**. Most Kubernetes objects
+_must_ be in a namespace, so if you use namespaces to represent ownership, you
+can always count on there being an owner.
+
+Secondly, namespaces have **authorized creation and use**. Only
+highly-privileged users can create namespaces, and other users require explicit
+permission to use those namespaces - that is, create, view or modify objects in
+those namespaces. This allows them to be carefully created with appropriate
+policies, before unprivileged users can create “regular” objects like pods and
+services.
+
+# The limits of namespaces
+
+However, in practice, namespaces are not flexible enough to meet some common use
+cases. For example, let’s say that one team owns several microservices with
+different secrets and quotas. Ideally, they should place these services into
+different namespaces in order to isolate them from each other, but this presents
+two problems.
+
+Firstly, these namespaces have no common concept of ownership, even though
+they’re both owned by the same team. This means that if the team controls
+multiple namespaces, not only does Kubernetes not have any record of their
+common owner, but namespaced-scoped policies cannot be applied uniformly across
+them.
+
+Secondly, teams generally work best if they can operate autonomously, but since
+namespace creation is highly privileged, it’s unlikely that any member of the
+dev team is allowed to create namespaces. This means that whenever a team wants
+a new namespace, they must raise a ticket to the cluster administrator. While
+this is probably acceptable for small organizations, it generates unnecessary
+toil as the organization grows.
+
+# Introducing hierarchical namespaces
+
+[Hierarchical
+namespaces](https://github.com/kubernetes-sigs/multi-tenancy/blob/master/incubator/hnc/docs/user-guide/concepts.md#basic)
+are a new concept developed by the [Kubernetes Working Group for Multi-Tenancy
+(wg-multitenancy)](https://github.com/kubernetes-sigs/multi-tenancy) in order to
+solve these problems. In its simplest form, a hierarchical namespace is a
+regular Kubernetes namespace that contains a small custom resource that
+identifies a single, optional, parent namespace. This establishes the concept of
+ownership _across_ namespaces, not just _within_ them.
+
+This concept of ownership enables two additional types of behaviours:
+
+* **Policy inheritance:** if one namespace is a child of another, policy objects
+ such as RBAC RoleBindings are [copied from the parent to the
+ child](https://github.com/kubernetes-sigs/multi-tenancy/blob/master/incubator/hnc/docs/user-guide/concepts.md#basic-propagation).
+* **Delegated creation:** you usually need cluster-level privileges to create a
+ namespace, but hierarchical namespaces adds an alternative:
+ [_subnamespaces_](https://github.com/kubernetes-sigs/multi-tenancy/blob/master/incubator/hnc/docs/user-guide/concepts.md#basic-subns),
+ which can be manipulated using only limited permissions in the parent
+ namespace.
+
+This solves both of the problems for our dev team. The cluster administrator can
+create a single “root” namespace for the team, along with all necessary
+policies, and then delegate permission to create subnamespaces to members of
+that team. Those team members can then create subnamespaces for their own use,
+without violating the policies that were imposed by the cluster administrators.
+
+# Hands-on with hierarchical namespaces
+
+Hierarchical namespaces are provided by a Kubernetes extension known as the
+[**Hierarchical Namespace
+Controller**](https://github.com/kubernetes-sigs/multi-tenancy/tree/master/incubator/hnc),
+or **HNC**. The HNC consists of two components:
+
+* The **manager** runs on your cluster, manages subnamespaces, propagates policy
+ objects, ensures that your hierarchies are legal and manages extension points.
+* The **kubectl plugin**, called `kubectl-hns`, makes it easy for users to
+ interact with the manager.
+
+Both can be easily installed from the [releases page of our
+repo](https://github.com/kubernetes-sigs/multi-tenancy/releases).
+
+Let’s see HNC in action. Imagine that I do not have namespace creation
+privileges, but I can view the namespace `team-a` and create subnamespaces
+within it[1](#note-1). Using the plugin, I can now say:
+
+```bash
+$ kubectl hns create svc1-team-a -n team-a
+```
+
+This creates a subnamespace called `svc1-team-a`. Note that since subnamespaces
+are just regular Kubernetes namespaces, all subnamespace names must still be
+unique.
+
+I can view the structure of these namespaces by asking for a tree view:
+
+```bash
+$ kubectl hns tree team-a
+# Output:
+team-a
+└── svc1-team-a
+```
+
+And if there were any policies in the parent namespace, these now appear in the
+child as well[2](#note-2). For example, let’s say that `team-a` had
+an RBAC RoleBinding called `sres`. This rolebinding will also be present in the
+subnamespace:
+
+```bash
+$ kubectl describe rolebinding sres -n svc1-team-a
+# Output:
+Name: sres
+Labels: hnc.x-k8s.io/inheritedFrom=team-a # inserted by HNC
+Annotations:
+Role:
+ Kind: ClusterRole
+ Name: admin
+Subjects: ...
+```
+
+Finally, HNC adds labels to these namespaces with useful information about the
+hierarchy which you can use to apply other policies. For example, you can create
+the following NetworkPolicy:
+
+```yaml
+kind: NetworkPolicy
+apiVersion: networking.k8s.io/v1
+metadata:
+ name: allow-team-a
+ namespace: team-a
+spec:
+ ingress:
+ - from:
+ - namespaceSelector:
+ matchExpressions:
+ - key: 'team-a.tree.hnc.x-k8s.io/depth' # Label created by HNC
+ operator: Exists
+```
+
+This policy will both be propagated to all descendants of `team-a`, and will
+_also_ allow ingress traffic between all of those namespaces. The “tree” label
+can only be applied by HNC, and is guaranteed to reflect the latest hierarchy.
+
+You can learn all about the features of HNC from the [user
+guide](https://github.com/kubernetes-sigs/multi-tenancy/tree/master/incubator/hnc/docs/user-guide).
+
+# Next steps and getting involved
+
+If you think that hierarchical namespaces can work for your organization, [HNC
+v0.5.1 is available on
+GitHub](https://github.com/kubernetes-sigs/multi-tenancy/releases/tag/hnc-v0.5.1).
+We’d love to know what you think of it, what problems you’re using it to solve
+and what features you’d most like to see added. As with all early software, you
+should be cautious about using HNC in production environments, but the more
+feedback we get, the sooner we’ll be able to drive to HNC 1.0.
+
+We’re also open to additional contributors, whether it’s to fix or report bugs,
+or help prototype new features such as exceptions, improved monitoring,
+hierarchical resource quotas or fine-grained configuration.
+
+Please get in touch with us via our
+[repo](https://github.com/kubernetes-sigs/multi-tenancy), [mailing
+list](https://groups.google.com/g/kubernetes-wg-multitenancy) or on
+[Slack](https://kubernetes.slack.com/messages/wg-multitenancy) - we look forward
+to hearing from you!
+
+---
+
+_[Adrian Ludwin](https://twitter.com/aludwin) is a software engineer and the
+tech lead for the Hierarchical Namespace Controller._
+
+
+
+_Note 1: technically, you create a small object called a "subnamespace anchor"
+in the parent namespace, and then HNC creates the subnamespace for you._
+
+
+
+_Note 2: By default, only RBAC Roles and RoleBindings are propagated, but you
+can configure HNC to propagate any namespaced Kubernetes object._
diff --git a/content/en/blog/_posts/2020-08-21-Moving-Forward-From-Beta/feature_stages.svg b/content/en/blog/_posts/2020-08-21-Moving-Forward-From-Beta/feature_stages.svg
new file mode 100644
index 0000000000..4999c0c11f
--- /dev/null
+++ b/content/en/blog/_posts/2020-08-21-Moving-Forward-From-Beta/feature_stages.svg
@@ -0,0 +1,47 @@
+
+
diff --git a/content/en/blog/_posts/2020-08-21-Moving-Forward-From-Beta/index.md b/content/en/blog/_posts/2020-08-21-Moving-Forward-From-Beta/index.md
new file mode 100644
index 0000000000..3be4481954
--- /dev/null
+++ b/content/en/blog/_posts/2020-08-21-Moving-Forward-From-Beta/index.md
@@ -0,0 +1,111 @@
+---
+layout: blog
+title: "Moving Forward From Beta"
+date: 2020-08-21
+slug: moving-forward-from-beta
+---
+
+**Author**: Tim Bannister, The Scale Factory
+
+In Kubernetes, features follow a defined
+[lifecycle](/docs/reference/command-line-tools-reference/feature-gates/#feature-stages).
+First, as the twinkle of an eye in an interested developer. Maybe, then,
+sketched in online discussions, drawn on the online equivalent of a cafe
+napkin. This rough work typically becomes a
+[Kubernetes Enhancement Proposal](https://github.com/kubernetes/enhancements/blob/master/keps/0001-kubernetes-enhancement-proposal-process.md#kubernetes-enhancement-proposal-process) (KEP), and
+from there it usually turns into code.
+
+For Kubernetes v1.20 and onwards, we're focusing on helping that code
+graduate into stable features.
+
+That lifecycle I mentioned runs as follows:
+
+
+
+Usually, alpha features aren't enabled by default. You turn them on by setting a feature
+gate; usually, by setting a command line flag on each of the components that use the
+feature.
+
+(If you use Kubernetes through a managed service offering such as AKS, EKS, GKE, etc then
+the vendor who runs that service may have decided what feature gates are enabled for you).
+
+There's a defined process for graduating an existing, alpha feature into the beta phase.
+This is important because **beta features are enabled by default**, with the feature flag still
+there so cluster operators can opt out if they want.
+
+A similar but more thorough set of graduation criteria govern the transition to general
+availability (GA), also known as "stable". GA features are part of Kubernetes, with a
+commitment that they are staying in place throughout the current major version.
+
+Having beta features on by default lets Kubernetes and its contributors get valuable
+real-world feedback. However, there's a mismatch of incentives. Once a feature is enabled
+by default, people will use it. Even if there might be a few details to shake out,
+the way Kubernetes' REST APIs and conventions work mean that any future stable API is going
+to be compatible with the most recent beta API: your API objects won't stop working when
+a beta feature graduates to GA.
+
+For the API and its resources in particular, there's a much less strong incentive to move
+features from beta to GA than from alpha to beta. Vendors who want a particular feature
+have had good reason to help get code to the point where features are enabled by default,
+and beyond that the journey has been less clear.
+
+KEPs track more than code improvements. Essentially, anything that would need
+communicating to the wider community merits a KEP. That said, most KEPs cover
+Kubernetes features (and the code to implement them).
+
+You might know that [Ingress](/docs/concepts/services-networking/ingress/)
+has been in Kubernetes for a while, but did you realize that it actually went beta in 2015? To help
+drive things forward, Kubernetes' Architecture Special Interest Group (SIG) have a new approach in
+mind.
+
+## Avoiding permanent beta
+
+For Kubernetes REST APIs, when a new feature's API reaches beta, that starts a countdown.
+The beta-quality API now has **nine calendar months** to either:
+- reach GA, and deprecate the beta, or
+- have a new beta version (_and deprecate the previous beta_).
+
+To be clear, at this point **only REST APIs are affected**. For example, _APIListChunking_ is
+a beta feature but isn't itself a REST API. Right now there are no plans to automatically
+deprecate _APIListChunking_ nor any other features that aren't REST APIs.
+
+If a REST API reaches the end of that 9 month countdown, then the next Kubernetes release
+will deprecate that API version. There's no option for the REST API to stay at the same
+beta version beyond the first Kubernetes release to come out after the 9 month window.
+
+### What this means for you
+
+If you're using Kubernetes, there's a good chance that you're using a beta feature. Like
+I said, there are lots of them about.
+As well as Ingress, you might be using [CronJob](/docs/concepts/workloads/controllers/cron-jobs/),
+or [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/), or others.
+There's an even bigger chance that you're running on a control plane with at least one beta
+feature enabled.
+
+If you're using or generating Kubernetes manifests that use beta APIs like Ingress, you'll
+need to plan to revise those. The current APIs are going to be deprecated following a
+schedule (the 9 months I mentioned earlier) and after a further 9 months those deprecated
+APIs will be removed. At that point, to stay current with Kubernetes, you should already
+have migrated.
+
+### What this means for Kubernetes contributors
+
+The motivation here seems pretty clear: get features stable. Guaranteeing that beta
+features will be deprecated adds a pretty big incentive so that people who want the
+feature continue their effort until the code, documentation and tests are ready for this
+feature to graduate to stable, backed by several Kubernetes' releases of evidence in
+real-world use.
+
+### What this means for the ecosystem
+
+In my opinion, these harsh-seeming measures make a lot of sense, and are going to be
+good for Kubernetes. Deprecating existing APIs, through a rule that applies across all
+the different Special Interest Groups (SIGs), helps avoid stagnation and encourages
+fixes.
+
+Let's say that an API goes to beta and then real-world experience shows that it
+just isn't right - that, fundamentally, the API has shortcomings. With that 9 month
+countdown ticking, the people involved have the means and the justification to revise
+and release an API that deals with the problem cases. Anyone who wants to live with
+the deprecated API is welcome to - Kubernetes is open source - but their needs do not
+have to hold up progress on the feature.
diff --git a/content/en/docs/_index.md b/content/en/docs/_index.md
index 05e96e2901..e06ebf76a5 100644
--- a/content/en/docs/_index.md
+++ b/content/en/docs/_index.md
@@ -1,3 +1,4 @@
---
+linktitle: Kubernetes Documentation
title: Documentation
---
diff --git a/content/en/docs/concepts/architecture/controller.md b/content/en/docs/concepts/architecture/controller.md
index 547a624a94..72e628dad3 100644
--- a/content/en/docs/concepts/architecture/controller.md
+++ b/content/en/docs/concepts/architecture/controller.md
@@ -113,9 +113,9 @@ useful changes, it doesn't matter if the overall state is or is not stable.
As a tenet of its design, Kubernetes uses lots of controllers that each manage
a particular aspect of cluster state. Most commonly, a particular control loop
(controller) uses one kind of resource as its desired state, and has a different
-kind of resource that it manages to make that desired state happen. For example,
+kind of resource that it manages to make that desired state happen. For example,
a controller for Jobs tracks Job objects (to discover new work) and Pod objects
-(to run the Jobs, and then to see when the work is finished). In this case
+(to run the Jobs, and then to see when the work is finished). In this case
something else creates the Jobs, whereas the Job controller creates Pods.
It's useful to have simple controllers rather than one, monolithic set of control
@@ -154,8 +154,7 @@ controller does.
## {{% heading "whatsnext" %}}
-* Read about the [Kubernetes control plane](/docs/concepts/#kubernetes-control-plane)
-* Discover some of the basic [Kubernetes objects](/docs/concepts/#kubernetes-objects)
+* Read about the [Kubernetes control plane](/docs/concepts/overview/components/#control-plane-components)
+* Discover some of the basic [Kubernetes objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/)
* Learn more about the [Kubernetes API](/docs/concepts/overview/kubernetes-api/)
* If you want to write your own controller, see [Extension Patterns](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) in Extending Kubernetes.
-
diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md
index 5482b074bc..b1e1f0dc24 100644
--- a/content/en/docs/concepts/architecture/nodes.md
+++ b/content/en/docs/concepts/architecture/nodes.md
@@ -98,7 +98,7 @@ You can modify Node objects regardless of the setting of `--register-node`.
For example, you can set labels on an existing Node, or mark it unschedulable.
You can use labels on Nodes in conjunction with node selectors on Pods to control
-scheduling. For example, you can to constrain a Pod to only be eligible to run on
+scheduling. For example, you can constrain a Pod to only be eligible to run on
a subset of the available nodes.
Marking a node as unschedulable prevents the scheduler from placing new pods onto
diff --git a/content/en/docs/concepts/cluster-administration/addons.md b/content/en/docs/concepts/cluster-administration/addons.md
index d2565d1e38..05a65a1efc 100644
--- a/content/en/docs/concepts/cluster-administration/addons.md
+++ b/content/en/docs/concepts/cluster-administration/addons.md
@@ -29,7 +29,7 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift.
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) is an SDN platform that provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring.
* [Romana](https://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize).
-* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database.
+* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database.
## Service Discovery
@@ -49,5 +49,3 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply
There are several other add-ons documented in the deprecated [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) directory.
Well-maintained ones should be linked to here. PRs welcome!
-
-
diff --git a/content/en/docs/concepts/cluster-administration/cloud-providers.md b/content/en/docs/concepts/cluster-administration/cloud-providers.md
index 7b10760adf..89bd0be3f6 100644
--- a/content/en/docs/concepts/cluster-administration/cloud-providers.md
+++ b/content/en/docs/concepts/cluster-administration/cloud-providers.md
@@ -6,7 +6,7 @@ weight: 30
This page explains how to manage Kubernetes running on a specific
-cloud provider.
+cloud provider. There are many other third-party cloud provider projects, but this list is specific to projects embedded within, or relied upon by Kubernetes itself.
### kubeadm
@@ -116,15 +116,6 @@ If you wish to use the external cloud provider, its repository is [kubernetes/cl
The Azure cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
Note that the Kubernetes Node name must match the Azure VM name.
-## CloudStack
-
-If you wish to use the external cloud provider, its repository is [apache/cloudstack-kubernetes-provider](https://github.com/apache/cloudstack-kubernetes-provider)
-
-### Node Name
-
-The CloudStack cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
-Note that the Kubernetes Node name must match the CloudStack VM name.
-
## GCE
If you wish to use the external cloud provider, its repository is [kubernetes/cloud-provider-gcp](https://github.com/kubernetes/cloud-provider-gcp#readme)
@@ -138,11 +129,6 @@ Note that the first segment of the Kubernetes Node name must match the GCE insta
If you wish to use the external cloud provider, its repository is [kubernetes-sigs/cloud-provider-huaweicloud](https://github.com/kubernetes-sigs/cloud-provider-huaweicloud).
-### Node Name
-
-The HUAWEI CLOUD provider needs the private IP address of the node as the name of the Kubernetes Node object.
-Please make sure indicating `--hostname-override=` when starting kubelet on the node.
-
## OpenStack
This section describes all the possible configurations which can
be used when using OpenStack with Kubernetes.
@@ -251,11 +237,9 @@ file:
values are `v1` or `v2`. Where no value is provided automatic detection will
select the highest supported version exposed by the underlying OpenStack
cloud.
-* `use-octavia` (Optional): Used to determine whether to look for and use an
- Octavia LBaaS V2 service catalog endpoint. Valid values are `true` or `false`.
- Where `true` is specified and an Octaiva LBaaS V2 entry can not be found, the
- provider will fall back and attempt to find a Neutron LBaaS V2 endpoint
- instead. The default value is `false`.
+* `use-octavia`(Optional): Whether or not to use Octavia for LoadBalancer type
+ of Service implementation instead of using Neutron-LBaaS. Default: true
+ Attention: Openstack CCM use Octavia as default load balancer implementation since v1.17.0
* `subnet-id` (Optional): Used to specify the id of the subnet you want to
create your loadbalancer on. Can be found at Network > Networks. Click on the
respective network to get its subnets.
@@ -362,19 +346,7 @@ Kubernetes network plugin and should appear in the `[Route]` section of the
[kubenet](/docs/concepts/cluster-administration/network-plugins/#kubenet)
on OpenStack.
-## OVirt
-
-### Node Name
-
-The OVirt cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
-Note that the Kubernetes Node name must match the VM FQDN (reported by OVirt under `...`)
-
-## Photon
-
-### Node Name
-
-The Photon cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
-Note that the Kubernetes Node name must match the Photon VM name (or if `overrideIP` is set to true in the `--cloud-config`, the Kubernetes Node name must match the Photon VM IP address).
+[kubenet]: /docs/concepts/cluster-administration/network-plugins/#kubenet
## vSphere
@@ -388,46 +360,3 @@ If you are running vSphere < 6.7U3, the in-tree vSphere cloud provider is recomm
{{< /tabs >}}
For in-depth documentation on the vSphere cloud provider, visit the [vSphere cloud provider docs site](https://cloud-provider-vsphere.sigs.k8s.io).
-
-## IBM Cloud Kubernetes Service
-
-### Compute nodes
-By using the IBM Cloud Kubernetes Service provider, you can create clusters with a mixture of virtual and physical (bare metal) nodes in a single zone or across multiple zones in a region. For more information, see [Planning your cluster and worker node setup](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes).
-
-The name of the Kubernetes Node object is the private IP address of the IBM Cloud Kubernetes Service worker node instance.
-
-### Networking
-The IBM Cloud Kubernetes Service provider provides VLANs for quality network performance and network isolation for nodes. You can set up custom firewalls and Calico network policies to add an extra layer of security for your cluster, or connect your cluster to your on-prem data center via VPN. For more information, see [Planning your cluster network setup](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters).
-
-To expose apps to the public or within the cluster, you can leverage NodePort, LoadBalancer, or Ingress services. You can also customize the Ingress application load balancer with annotations. For more information, see [Choosing an app exposure service](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning).
-
-### Storage
-The IBM Cloud Kubernetes Service provider leverages Kubernetes-native persistent volumes to enable users to mount file, block, and cloud object storage to their apps. You can also use database-as-a-service and third-party add-ons for persistent storage of your data. For more information, see [Planning highly available persistent storage](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning).
-
-## Baidu Cloud Container Engine
-
-### Node Name
-
-The Baidu cloud provider uses the private IP address of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
-Note that the Kubernetes Node name must match the Baidu VM private IP.
-
-## Tencent Kubernetes Engine
-
-If you wish to use the external cloud provider, its repository is [TencentCloud/tencentcloud-cloud-controller-manager](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager).
-
-### Node Name
-
-The Tencent cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
-Note that the Kubernetes Node name must match the Tencent VM private IP.
-
-## Alibaba Cloud Kubernetes
-
- If you wish to use the external cloud provider, its repository is [kubernetes/cloud-provider-alibaba-cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud).
-
-### Node Name
-
-Alibaba Cloud does not require the format of node name, but the kubelet needs to add `--provider-id=${REGION_ID}.${INSTANCE_ID}`. The parameter `${REGION_ID}` represents the region id of the Kubernetes and `${INSTANCE_ID}` denotes the Alibaba ECS (Elastic Compute Service) ID.
-
-### Load Balancers
-
-You can setup external load balancers to use specific features in Alibaba Cloud by configuring the [annotations](https://www.alibabacloud.com/help/en/doc-detail/86531.htm) .
diff --git a/content/en/docs/concepts/configuration/manage-resources-containers.md b/content/en/docs/concepts/configuration/manage-resources-containers.md
index c30e8d243b..1f907ad0d0 100644
--- a/content/en/docs/concepts/configuration/manage-resources-containers.md
+++ b/content/en/docs/concepts/configuration/manage-resources-containers.md
@@ -111,7 +111,7 @@ CPU is always requested as an absolute quantity, never as a relative quantity;
### Meaning of memory
Limits and requests for `memory` are measured in bytes. You can express memory as
-a plain integer or as a fixed-point integer using one of these suffixes:
+a plain integer or as a fixed-point number using one of these suffixes:
E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
Mi, Ki. For example, the following represent roughly the same value:
@@ -311,7 +311,7 @@ You can use _ephemeral-storage_ for managing local ephemeral storage. Each Conta
* `spec.containers[].resources.requests.ephemeral-storage`
Limits and requests for `ephemeral-storage` are measured in bytes. You can express storage as
-a plain integer or as a fixed-point integer using one of these suffixes:
+a plain integer or as a fixed-point number using one of these suffixes:
E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
Mi, Ki. For example, the following represent roughly the same value:
diff --git a/content/en/docs/concepts/configuration/resource-bin-packing.md b/content/en/docs/concepts/configuration/resource-bin-packing.md
index 08a99de201..9d6ab31889 100644
--- a/content/en/docs/concepts/configuration/resource-bin-packing.md
+++ b/content/en/docs/concepts/configuration/resource-bin-packing.md
@@ -172,7 +172,7 @@ Node Score:
intel.com/foo = resourceScoringFunction((2+2),8)
= (100 - ((8-4)*100/8)
- = (100 - 25)
+ = (100 - 50)
= 50
= rawScoringFunction(50)
= 5
diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md
index b9ada35d3b..48f1fa6e6d 100644
--- a/content/en/docs/concepts/configuration/secret.md
+++ b/content/en/docs/concepts/configuration/secret.md
@@ -352,6 +352,8 @@ NAME TYPE DATA
db-user-pass-96mffmfh4k Opaque 2 51s
```
+You can view a description of the secret:
+
```shell
kubectl describe secrets/db-user-pass-96mffmfh4k
```
@@ -1002,6 +1004,8 @@ The output is similar to:
secret "prod-db-secret" created
```
+You can also create a secret for test environment credentials.
+
```shell
kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests
```
diff --git a/content/en/docs/concepts/containers/container-lifecycle-hooks.md b/content/en/docs/concepts/containers/container-lifecycle-hooks.md
index c8e93e93db..09d5530a29 100644
--- a/content/en/docs/concepts/containers/container-lifecycle-hooks.md
+++ b/content/en/docs/concepts/containers/container-lifecycle-hooks.md
@@ -30,7 +30,7 @@ There are two hooks that are exposed to Containers:
`PostStart`
-This hook executes immediately after a container is created.
+This hook is executed immediately after a container is created.
However, there is no guarantee that the hook will execute before the container ENTRYPOINT.
No parameters are passed to the handler.
diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md
index e136da173a..ddd294feda 100644
--- a/content/en/docs/concepts/containers/images.md
+++ b/content/en/docs/concepts/containers/images.md
@@ -94,7 +94,7 @@ runtime to authenticate to a private container registry.
This approach is suitable if you can control node configuration.
{{< note >}}
-Kubernetes as only supports the `auths` and `HttpHeaders` section in Docker configuration.
+Default Kubernetes only supports the `auths` and `HttpHeaders` section in Docker configuration.
Docker credential helpers (`credHelpers` or `credsStore`) are not supported.
{{< /note >}}
diff --git a/content/en/docs/concepts/extend-kubernetes/operator.md b/content/en/docs/concepts/extend-kubernetes/operator.md
index 31e8473ca9..14ed2d5233 100644
--- a/content/en/docs/concepts/extend-kubernetes/operator.md
+++ b/content/en/docs/concepts/extend-kubernetes/operator.md
@@ -9,7 +9,7 @@ weight: 30
Operators are software extensions to Kubernetes that make use of
[custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
to manage applications and their components. Operators follow
-Kubernetes principles, notably the [control loop](/docs/concepts/#kubernetes-control-plane).
+Kubernetes principles, notably the [control loop](/docs/concepts/architecture/controller).
diff --git a/content/en/docs/concepts/security/pod-security-standards.md b/content/en/docs/concepts/security/pod-security-standards.md
index 9829692126..f7103dd220 100644
--- a/content/en/docs/concepts/security/pod-security-standards.md
+++ b/content/en/docs/concepts/security/pod-security-standards.md
@@ -209,11 +209,11 @@ well as lower-trust users.The following listed controls should be enforced/disal
Privilege Escalation
- Privilege escalation to root should not be allowed.
+ Privilege escalation (such as via set-user-ID or set-group-ID file mode) should not be allowed.
diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md
index 4933513929..8c2ad3ddb1 100644
--- a/content/en/docs/concepts/storage/persistent-volumes.md
+++ b/content/en/docs/concepts/storage/persistent-volumes.md
@@ -259,7 +259,7 @@ Expanding EBS volumes is a time-consuming operation. Also, there is a per-volume
If expanding underlying storage fails, the cluster administrator can manually recover the Persistent Volume Claim (PVC) state and cancel the resize requests. Otherwise, the resize requests are continuously retried by the controller without administrator intervention.
1. Mark the PersistentVolume(PV) that is bound to the PersistentVolumeClaim(PVC) with `Retain` reclaim policy.
-2. Delete the PVC. Since PV has `Retain` reclaim policy - we will not loose any data when we recreate the PVC.
+2. Delete the PVC. Since PV has `Retain` reclaim policy - we will not lose any data when we recreate the PVC.
3. Delete the `claimRef` entry from PV specs, so as new PVC can bind to it. This should make the PV `Available`.
4. Re-create the PVC with smaller size than PV and set `volumeName` field of the PVC to the name of the PV. This should bind new PVC to existing PV.
5. Don't forget to restore the reclaim policy of the PV.
diff --git a/content/en/docs/concepts/storage/volume-snapshots.md b/content/en/docs/concepts/storage/volume-snapshots.md
index a6cc122086..51da1b05ae 100644
--- a/content/en/docs/concepts/storage/volume-snapshots.md
+++ b/content/en/docs/concepts/storage/volume-snapshots.md
@@ -94,14 +94,14 @@ using the attribute `volumeSnapshotClassName`. If nothing is set, then the defau
For pre-provisioned snapshots, you need to specify a `volumeSnapshotContentName` as the source for the snapshot as shown in the following example. The `volumeSnapshotContentName` source field is required for pre-provisioned snapshots.
-```
+```yaml
apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshot
metadata:
name: test-snapshot
spec:
source:
- volumeSnapshotContentName: test-content
+ volumeSnapshotContentName: test-content
```
## Volume Snapshot Contents
diff --git a/content/en/docs/concepts/workloads/controllers/daemonset.md b/content/en/docs/concepts/workloads/controllers/daemonset.md
index 0d1e1d34b3..ecf884884a 100644
--- a/content/en/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/en/docs/concepts/workloads/controllers/daemonset.md
@@ -7,7 +7,7 @@ reviewers:
- kow3ns
title: DaemonSet
content_type: concept
-weight: 50
+weight: 40
---
diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md
index 6e6b8c8ecf..b73f78712e 100644
--- a/content/en/docs/concepts/workloads/controllers/deployment.md
+++ b/content/en/docs/concepts/workloads/controllers/deployment.md
@@ -8,7 +8,7 @@ feature:
Kubernetes progressively rolls out changes to your application or its configuration, while monitoring application health to ensure it doesn't kill all your instances at the same time. If something goes wrong, Kubernetes will rollback the change for you. Take advantage of a growing ecosystem of deployment solutions.
content_type: concept
-weight: 30
+weight: 10
---
@@ -84,7 +84,7 @@ Follow the steps given below to create the above Deployment:
2. Run `kubectl get deployments` to check if the Deployment was created.
If the Deployment is still being created, the output is similar to the following:
- ```shell
+ ```
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 0/3 0 0 1s
```
@@ -100,21 +100,21 @@ Follow the steps given below to create the above Deployment:
3. To see the Deployment rollout status, run `kubectl rollout status deployment.v1.apps/nginx-deployment`.
The output is similar to:
- ```shell
+ ```
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment.apps/nginx-deployment successfully rolled out
```
4. Run the `kubectl get deployments` again a few seconds later.
The output is similar to this:
- ```shell
+ ```
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 18s
```
Notice that the Deployment has created all three replicas, and all replicas are up-to-date (they contain the latest Pod template) and available.
5. To see the ReplicaSet (`rs`) created by the Deployment, run `kubectl get rs`. The output is similar to this:
- ```shell
+ ```
NAME DESIRED CURRENT READY AGE
nginx-deployment-75675f5897 3 3 3 18s
```
@@ -131,7 +131,7 @@ Follow the steps given below to create the above Deployment:
6. To see the labels automatically generated for each Pod, run `kubectl get pods --show-labels`.
The output is similar to:
- ```shell
+ ```
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
@@ -1054,7 +1054,7 @@ The `.spec.template` and `.spec.selector` are the only required field of the `.s
The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="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)).
+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.
diff --git a/content/en/docs/concepts/workloads/controllers/garbage-collection.md b/content/en/docs/concepts/workloads/controllers/garbage-collection.md
index 79cc905f58..93a3c912fb 100644
--- a/content/en/docs/concepts/workloads/controllers/garbage-collection.md
+++ b/content/en/docs/concepts/workloads/controllers/garbage-collection.md
@@ -1,7 +1,7 @@
---
title: Garbage Collection
content_type: concept
-weight: 70
+weight: 60
---
diff --git a/content/en/docs/concepts/workloads/controllers/job.md b/content/en/docs/concepts/workloads/controllers/job.md
index 479858e3d4..b65ed27ae2 100644
--- a/content/en/docs/concepts/workloads/controllers/job.md
+++ b/content/en/docs/concepts/workloads/controllers/job.md
@@ -8,7 +8,7 @@ feature:
title: Batch execution
description: >
In addition to services, Kubernetes can manage your batch and CI workloads, replacing containers that fail, if desired.
-weight: 60
+weight: 50
---
diff --git a/content/en/docs/concepts/workloads/controllers/replicaset.md b/content/en/docs/concepts/workloads/controllers/replicaset.md
index ef2a069ca1..15a9918a1c 100644
--- a/content/en/docs/concepts/workloads/controllers/replicaset.md
+++ b/content/en/docs/concepts/workloads/controllers/replicaset.md
@@ -5,7 +5,7 @@ reviewers:
- madhusudancs
title: ReplicaSet
content_type: concept
-weight: 10
+weight: 20
---
@@ -245,9 +245,10 @@ For the template's [restart policy](/docs/concepts/workloads/Pods/pod-lifecycle/
The `.spec.selector` field is a [label selector](/docs/concepts/overview/working-with-objects/labels/). As discussed
[earlier](#how-a-replicaset-works) these are the labels used to identify potential Pods to acquire. In our
`frontend.yaml` example, the selector was:
-```shell
+
+```yaml
matchLabels:
- tier: frontend
+ tier: frontend
```
In the ReplicaSet, `.spec.template.metadata.labels` must match `spec.selector`, or it will
diff --git a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
index 941d8f585e..5d02e2826f 100644
--- a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
@@ -10,7 +10,7 @@ feature:
Restarts containers that fail, replaces and reschedules containers when nodes die, kills containers that don't respond to your user-defined health check, and doesn't advertise them to clients until they are ready to serve.
content_type: concept
-weight: 20
+weight: 90
---
diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md
index fd9833356a..64cef43470 100644
--- a/content/en/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/en/docs/concepts/workloads/controllers/statefulset.md
@@ -8,7 +8,7 @@ reviewers:
- smarterclayton
title: StatefulSets
content_type: concept
-weight: 40
+weight: 30
---
diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
index 35fbb562bf..0daf25de1a 100644
--- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -124,9 +124,9 @@ about when the container entered the `Running` state.
### `Terminated` {#container-state-terminated}
-A container in the `Terminated` state has begin execution and has then either run to
-completion or has failed for some reason. When you use `kubectl` to query a Pod with
-a container that is `Terminated`, you see a reason, and exit code, and the start and
+A container in the `Terminated` state began execution and then either ran to
+completion or failed for some reason. When you use `kubectl` to query a Pod with
+a container that is `Terminated`, you see a reason, an exit code, and the start and
finish time for that container's period of execution.
If a container has a `preStop` hook configured, that runs before the container enters
@@ -341,8 +341,8 @@ before the Pod is allowed to be forcefully killed. With that forceful shutdown t
place, the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} attempts graceful
shutdown.
-Typically, the container runtime sends a a TERM signal is sent to the main process in each
-container. Once the grace period has expired, the KILL signal is sent to any remainig
+Typically, the container runtime sends a TERM signal to the main process in each
+container. Once the grace period has expired, the KILL signal is sent to any remaining
processes, and the Pod is then deleted from the
{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}. If the kubelet or the
container runtime's management service is restarted while waiting for processes to terminate, the
@@ -442,4 +442,3 @@ This avoids a resource leak as Pods are created and terminated over time.
* For detailed information about Pod / Container status in the API, see [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
and
[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
-
diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md
index bd936615a8..f7c5cfa322 100644
--- a/content/en/docs/reference/access-authn-authz/authentication.md
+++ b/content/en/docs/reference/access-authn-authz/authentication.md
@@ -669,7 +669,7 @@ rules:
```
Extra fields are evaluated as sub-resources of the resource "userextras". To
-allow a user to use impersonation headers for the extra field "scopes," a user
+allow a user to use impersonation headers for the extra field "scopes", a user
should be granted the following role:
```yaml
diff --git a/content/en/docs/reference/glossary/kube-apiserver.md b/content/en/docs/reference/glossary/kube-apiserver.md
index 6de64bba5f..2762c9ceea 100755
--- a/content/en/docs/reference/glossary/kube-apiserver.md
+++ b/content/en/docs/reference/glossary/kube-apiserver.md
@@ -2,7 +2,7 @@
title: API server
id: kube-apiserver
date: 2018-04-12
-full_link: /docs/reference/generated/kube-apiserver/
+full_link: /docs/concepts/overview/components/#kube-apiserver
short_description: >
Control plane component that serves the Kubernetes API.
diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md
index 71f7e6d3f7..e20826ca43 100644
--- a/content/en/docs/reference/kubectl/cheatsheet.md
+++ b/content/en/docs/reference/kubectl/cheatsheet.md
@@ -12,17 +12,11 @@ card:
-See also: [Kubectl Overview](/docs/reference/kubectl/overview/) and [JsonPath Guide](/docs/reference/kubectl/jsonpath).
-
-This page is an overview of the `kubectl` command.
-
-
+This page contains a list of commonly used `kubectl` commands and flags.
-# kubectl - Cheat Sheet
-
-## Kubectl Autocomplete
+## Kubectl autocomplete
### BASH
@@ -31,7 +25,7 @@ source <(kubectl completion bash) # setup autocomplete in bash into the current
echo "source <(kubectl completion bash)" >> ~/.bashrc # add autocomplete permanently to your bash shell.
```
-You can also use a shorthand alias for `kubectl` that also works with completion:
+You can also use a shorthand alias for `kubectl` that also works with completion:
```bash
alias k=kubectl
@@ -45,7 +39,7 @@ source <(kubectl completion zsh) # setup autocomplete in zsh into the current s
echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # add autocomplete permanently to your zsh shell
```
-## Kubectl Context and Configuration
+## Kubectl context and configuration
Set which Kubernetes cluster `kubectl` communicates with and modifies configuration
information. See [Authenticating Across Clusters with kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) documentation for
@@ -77,14 +71,15 @@ kubectl config set-context --current --namespace=ggckad-s2
# set a context utilizing a specific username and namespace.
kubectl config set-context gce --user=cluster-admin --namespace=foo \
&& kubectl config use-context gce
-
+
kubectl config unset users.foo # delete user foo
```
-## Apply
+## Kubectl apply
+
`apply` manages applications through files defining Kubernetes resources. It creates and updates resources in a cluster through running `kubectl apply`. This is the recommended way of managing Kubernetes applications on production. See [Kubectl Book](https://kubectl.docs.kubernetes.io).
-## Creating Objects
+## Creating objects
Kubernetes manifests can be defined in YAML or JSON. The file extension `.yaml`,
`.yml`, and `.json` can be used.
@@ -138,7 +133,7 @@ EOF
```
-## Viewing, Finding Resources
+## Viewing, finding resources
```bash
# Get commands with basic output
@@ -213,8 +208,7 @@ kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
```
-## Updating Resources
-
+## Updating resources
```bash
kubectl set image deployment/frontend www=image:v2 # Rolling update "www" containers of "frontend" deployment, updating the image
@@ -241,7 +235,7 @@ kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # Add an annota
kubectl autoscale deployment foo --min=2 --max=10 # Auto scale a deployment "foo"
```
-## Patching Resources
+## Patching resources
```bash
# Partially update a node
@@ -260,7 +254,8 @@ kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "
kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'
```
-## Editing Resources
+## Editing resources
+
Edit any API resource in your preferred editor.
```bash
@@ -268,7 +263,7 @@ kubectl edit svc/docker-registry # Edit the service named d
KUBE_EDITOR="nano" kubectl edit svc/docker-registry # Use an alternative editor
```
-## Scaling Resources
+## Scaling resources
```bash
kubectl scale --replicas=3 rs/foo # Scale a replicaset named 'foo' to 3
@@ -277,7 +272,7 @@ kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # If the deplo
kubectl scale --replicas=5 rc/foo rc/bar rc/baz # Scale multiple replication controllers
```
-## Deleting Resources
+## Deleting resources
```bash
kubectl delete -f ./pod.json # Delete a pod using the type and name specified in pod.json
@@ -313,7 +308,7 @@ kubectl exec my-pod -c my-container -- ls / # Run command in existing po
kubectl top pod POD_NAME --containers # Show metrics for a given pod and its containers
```
-## Interacting with Nodes and Cluster
+## Interacting with Nodes and cluster
```bash
kubectl cordon my-node # Mark my-node as unschedulable
@@ -393,17 +388,12 @@ Verbosity | Description
`--v=8` | Display HTTP request contents.
`--v=9` | Display HTTP request contents without truncation of contents.
-
-
## {{% heading "whatsnext" %}}
-
-* Learn more about [Overview of kubectl](/docs/reference/kubectl/overview/).
+* Read the [kubectl overview](/docs/reference/kubectl/overview/) and learn about [JsonPath](/docs/reference/kubectl/jsonpath).
* See [kubectl](/docs/reference/kubectl/kubectl/) options.
-* Also [kubectl Usage Conventions](/docs/reference/kubectl/conventions/) to understand how to use it in reusable scripts.
+* Also read [kubectl Usage Conventions](/docs/reference/kubectl/conventions/) to understand how to use kubectl in reusable scripts.
* See more community [kubectl cheatsheets](https://github.com/dennyzhang/cheatsheet-kubernetes-A4).
-
-
diff --git a/content/en/docs/reference/scheduling/config.md b/content/en/docs/reference/scheduling/config.md
index 75e87a80b6..530e881cbd 100644
--- a/content/en/docs/reference/scheduling/config.md
+++ b/content/en/docs/reference/scheduling/config.md
@@ -13,7 +13,17 @@ file and passing its path as a command line argument.
-## Minimal Configuration
+A scheduling Profile allows you to configure the different stages of scheduling
+in the {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}.
+Each stage is exposed in a extension point. Plugins provide scheduling behaviors
+by implementing one or more of these extension points.
+
+You can specify scheduling profiles by running `kube-scheduler --config `,
+using the component config APIs
+([`v1alpha1`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha1?tab=doc#KubeSchedulerConfiguration)
+or [`v1alpha2`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha2?tab=doc#KubeSchedulerConfiguration)).
+The `v1alpha2` API allows you to configure kube-scheduler to run
+[multiple profiles](#multiple-profiles).
A minimal configuration looks as follows:
@@ -90,6 +100,10 @@ for that extension point. This can also be used to rearrange plugins order, if
desired.
### Scheduling plugins
+1. `UnReserve`: This is an informational extension point that is called if
+ a Pod is rejected after being reserved and put on hold by a `Permit` plugin.
+
+## Scheduling plugins
The following plugins, enabled by default, implement one or more of these
extension points:
@@ -236,4 +250,3 @@ only has one pending pods queue.
* Read the [kube-scheduler reference](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)
* Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/)
-
diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md
index 9e45b8fe57..65bb9df2c7 100644
--- a/content/en/docs/setup/production-environment/container-runtimes.md
+++ b/content/en/docs/setup/production-environment/container-runtimes.md
@@ -221,64 +221,89 @@ sysctl --system
{{< tabs name="tab-cri-cri-o-installation" >}}
{{% tab name="Debian" %}}
+To install CRI-O on the following operating systems, set the environment variable $OS to the appropriate field in the following table:
+
+| Operating system | $OS |
+| ---------------- | ----------------- |
+| Debian Unstable | `Debian_Unstable` |
+| Debian Testing | `Debian_Testing` |
+
+
+Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
+For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`.
+You can pin your installation to a specific release.
+To install version 1.18.3, set `VERSION=1.18:1.18.3`.
+
+
+Then run
```shell
-# Debian Unstable/Sid
-echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add -
+echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
+echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
+
+curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | apt-key add -
+curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | apt-key add -
+
+apt-get update
+apt-get install cri-o cri-o-runc
```
-```shell
-# Debian Testing
-echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add -
-```
+{{% /tab %}}
-```shell
-# Debian 10
-echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add -
-```
+{{% tab name="Ubuntu" %}}
-```shell
-# Raspbian 10
-echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add -
-```
+To install on the following operating systems, set the environment variable $OS to the appropriate field in the following table:
-and then install CRI-O:
+| Operating system | $OS |
+| ---------------- | ----------------- |
+| Ubuntu 20.04 | `xUbuntu_20.04` |
+| Ubuntu 19.10 | `xUbuntu_19.10` |
+| Ubuntu 19.04 | `xUbuntu_19.04` |
+| Ubuntu 18.04 | `xUbuntu_18.04` |
+
+
+Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
+For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`.
+You can pin your installation to a specific release.
+To install version 1.18.3, set `VERSION=1.18:1.18.3`.
+
+
+Then run
```shell
-sudo apt-get install cri-o-1.17
+echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
+echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
+
+curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | apt-key add -
+curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | apt-key add -
+
+apt-get update
+apt-get install cri-o cri-o-runc
```
{{% /tab %}}
-{{% tab name="Ubuntu 18.04, 19.04 and 19.10" %}}
+{{% tab name="CentOS" %}}
+To install on the following operating systems, set the environment variable $OS to the appropriate field in the following table:
+
+| Operating system | $OS |
+| ---------------- | ----------------- |
+| Centos 8 | `CentOS_8` |
+| Centos 8 Stream | `CentOS_8_Stream` |
+| Centos 7 | `CentOS_7` |
+
+
+Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
+For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`.
+You can pin your installation to a specific release.
+To install version 1.18.3, set `VERSION=1.18:1.18.3`.
+
+
+Then run
```shell
-# Configure package repository
-. /etc/os-release
-sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list"
-wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add -
-sudo apt-get update
+curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo
+curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo
+yum install cri-o
```
-```shell
-# Install CRI-O
-sudo apt-get install cri-o-1.17
-```
-{{% /tab %}}
-
-{{% tab name="CentOS/RHEL 7.4+" %}}
-
-```shell
-# Install prerequisites
-curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/CentOS_7/devel:kubic:libcontainers:stable.repo
-curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}/CentOS_7/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo
-```
-
-```shell
-# Install CRI-O
-yum install -y cri-o
-```
{{% /tab %}}
{{% tab name="openSUSE Tumbleweed" %}}
@@ -286,6 +311,23 @@ yum install -y cri-o
```shell
sudo zypper install cri-o
```
+{{% /tab %}}
+{{% tab name="Fedora" %}}
+
+Set `$VERSION` to the CRI-O version that matches your Kubernetes version.
+For instance, if you want to install CRI-O 1.18, `VERSION=1.18`
+You can find available versions with:
+```shell
+dnf module list cri-o
+```
+CRI-O does not support pinning to specific releases on Fedora.
+
+Then run
+```shell
+dnf module enable cri-o:$VERSION
+dnf install cri-o
+```
+
{{% /tab %}}
{{< /tabs >}}
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
index 82184f7784..3462e78323 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
@@ -1,14 +1,14 @@
---
reviewers:
- sig-cluster-lifecycle
-title: Creating a single control-plane cluster with kubeadm
+title: Creating a cluster with kubeadm
content_type: task
weight: 30
---
-The `kubeadm` tool helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
+Creating a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
`kubeadm` also supports other cluster
lifecycle functions, such as [bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) and cluster upgrades.
@@ -60,7 +60,7 @@ Any commands under `kubeadm alpha` are, by definition, supported on an alpha lev
## Objectives
-* Install a single control-plane Kubernetes cluster or [high-availability cluster](/docs/setup/production-environment/tools/kubeadm/high-availability/)
+* Install a single control-plane Kubernetes cluster
* Install a Pod network on the cluster so that your Pods can
talk to each other
@@ -554,7 +554,7 @@ Workarounds:
* Use multiple control-plane nodes. You can read
[Options for Highly Available topology](/docs/setup/production-environment/tools/kubeadm/ha-topology/) to pick a cluster
- topology that provides higher availabilty.
+ topology that provides [high-availability](/docs/setup/production-environment/tools/kubeadm/high-availability/).
### Platform compatibility {#multi-platform}
diff --git a/content/en/docs/setup/release/version-skew-policy.md b/content/en/docs/setup/release/version-skew-policy.md
index 310127f838..0cd1ab597d 100644
--- a/content/en/docs/setup/release/version-skew-policy.md
+++ b/content/en/docs/setup/release/version-skew-policy.md
@@ -155,7 +155,7 @@ Running a cluster with `kubelet` instances that are persistently two minor versi
Example:
-If `kube-proxy` version is **{{< skew latestVersion >}}**:
+If `kube-proxy` version is **{{< skew oldestMinorVersion >}}**:
-* `kubelet` version must be at the same minor version as **{{< skew latestVersion >}}**.
+* `kubelet` version must be at the same minor version as **{{< skew oldestMinorVersion >}}**.
* `kube-apiserver` version must be between **{{< skew oldestMinorVersion >}}** and **{{< skew latestVersion >}}**, inclusive.
diff --git a/content/en/docs/tasks/_index.md b/content/en/docs/tasks/_index.md
index 0d424ee4db..500a250fa5 100644
--- a/content/en/docs/tasks/_index.md
+++ b/content/en/docs/tasks/_index.md
@@ -12,4 +12,4 @@ show how to do individual tasks. A task page shows how to do a
single thing, typically by giving a short sequence of steps.
If you would like to write a task page, see
-[Creating a Documentation Pull Request](/docs/home/contribute/create-pull-request/).
+[Creating a Documentation Pull Request](/docs/contribute/new-content/open-a-pr/).
diff --git a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md
index 79c5260ead..ce39aa01a5 100644
--- a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md
+++ b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md
@@ -80,7 +80,8 @@ spec:
requests:
cpu: 700m
memory: 200Mi
-...
+ ...
+status:
qosClass: Guaranteed
```
@@ -134,7 +135,8 @@ spec:
memory: 200Mi
requests:
memory: 100Mi
-...
+ ...
+status:
qosClass: Burstable
```
@@ -174,6 +176,7 @@ spec:
...
resources: {}
...
+status:
qosClass: BestEffort
```
@@ -219,6 +222,7 @@ spec:
name: qos-demo-4-ctr-2
resources: {}
...
+status:
qosClass: Burstable
```
diff --git a/content/en/docs/tasks/debug-application-cluster/audit.md b/content/en/docs/tasks/debug-application-cluster/audit.md
index 3d3d801a37..c4b0c72805 100644
--- a/content/en/docs/tasks/debug-application-cluster/audit.md
+++ b/content/en/docs/tasks/debug-application-cluster/audit.md
@@ -251,7 +251,7 @@ different audit policies.
### Use fluentd to collect and distribute audit events from log file
-[Fluentd](http://www.fluentd.org/) is an open source data collector for unified logging layer.
+[Fluentd](https://www.fluentd.org/) is an open source data collector for unified logging layer.
In this example, we will use fluentd to split audit events by different namespaces.
{{< note >}}
@@ -379,7 +379,7 @@ different users into different files.
bin/logstash -f /etc/logstash/config --path.settings /etc/logstash/
```
-1. create a [kubeconfig file](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) for kube-apiserver webhook audit backend
+1. create a [kubeconfig file](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) for kube-apiserver webhook audit backend
cat < /etc/kubernetes/audit-webhook-kubeconfig
apiVersion: v1
@@ -413,9 +413,5 @@ plugin which supports full-text search and analytics.
## {{% heading "whatsnext" %}}
-
-Visit [Auditing with Falco](/docs/tasks/debug-application-cluster/falco).
-
Learn about [Mutating webhook auditing annotations](/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations).
-
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-application.md b/content/en/docs/tasks/debug-application-cluster/debug-application.md
index edd23c35e7..f665accb18 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-application.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-application.md
@@ -10,10 +10,7 @@ content_type: concept
This guide is to help users debug applications that are deployed into Kubernetes and not behaving correctly.
This is *not* a guide for people who want to debug their cluster. For that you should check out
-[this guide](/docs/admin/cluster-troubleshooting).
-
-
-
+[this guide](/docs/tasks/debug-application-cluster/debug-cluster).
@@ -46,7 +43,8 @@ there are insufficient resources of one type or another that prevent scheduling.
your pod. Reasons include:
* **You don't have enough resources**: You may have exhausted the supply of CPU or Memory in your cluster, in this case
-you need to delete Pods, adjust resource requests, or add new nodes to your cluster. See [Compute Resources document](/docs/user-guide/compute-resources/#my-pods-are-pending-with-event-message-failedscheduling) for more information.
+you need to delete Pods, adjust resource requests, or add new nodes to your cluster. See
+[Compute Resources document](/docs/concepts/configuration/manage-resources-containers/) for more information.
* **You are using `hostPort`**: When you bind a Pod to a `hostPort` there are a limited number of places that pod can be
scheduled. In most cases, `hostPort` is unnecessary, try using a Service object to expose your Pod. If you do require
@@ -161,13 +159,13 @@ check:
* Can you connect to your pods directly? Get the IP address for the Pod, and try to connect directly to that IP.
* Is your application serving on the port that you configured? Kubernetes doesn't do port remapping, so if your application serves on 8080, the `containerPort` field needs to be 8080.
-
-
## {{% heading "whatsnext" %}}
+If none of the above solves your problem, follow the instructions in
+[Debugging Service document](/docs/tasks/debug-application-cluster/debug-service/)
+to make sure that your `Service` is running, has `Endpoints`, and your `Pods` are
+actually serving; you have DNS working, iptables rules installed, and kube-proxy
+does not seem to be misbehaving.
-If none of the above solves your problem, follow the instructions in [Debugging Service document](/docs/user-guide/debugging-services) to make sure that your `Service` is running, has `Endpoints`, and your `Pods` are actually serving; you have DNS working, iptables rules installed, and kube-proxy does not seem to be misbehaving.
-
-You may also visit [troubleshooting document](/docs/troubleshooting/) for more information.
-
+You may also visit [troubleshooting document](/docs/tasks/debug-application-cluster/troubleshooting/) for more information.
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-cluster.md b/content/en/docs/tasks/debug-application-cluster/debug-cluster.md
index 0a66bed195..fdde133345 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-cluster.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-cluster.md
@@ -10,10 +10,7 @@ content_type: concept
This doc is about cluster troubleshooting; we assume you have already ruled out your application as the root cause of the
problem you are experiencing. See
the [application troubleshooting guide](/docs/tasks/debug-application-cluster/debug-application) for tips on application debugging.
-You may also visit [troubleshooting document](/docs/troubleshooting/) for more information.
-
-
-
+You may also visit [troubleshooting document](/docs/tasks/debug-application-cluster/troubleshooting/) for more information.
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-init-containers.md b/content/en/docs/tasks/debug-application-cluster/debug-init-containers.md
index a6a3a44d98..c3cf109ea7 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-init-containers.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-init-containers.md
@@ -15,10 +15,8 @@ content_type: task
This page shows how to investigate problems related to the execution of
Init Containers. The example command lines below refer to the Pod as
- `` and the Init Containers as `` and
- ``.
-
-
+`` and the Init Containers as `` and
+``.
## {{% heading "prerequisites" %}}
@@ -26,11 +24,9 @@ Init Containers. The example command lines below refer to the Pod as
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* You should be familiar with the basics of
- [Init Containers](/docs/concepts/abstractions/init-containers/).
+ [Init Containers](/docs/concepts/workloads/pods/init-containers/).
* You should have [Configured an Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/).
-
-
## Checking the status of Init Containers
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
index 8fb5bffd37..65dfb63322 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
@@ -9,8 +9,6 @@ content_type: task
This page shows how to debug Pods and ReplicationControllers.
-
-
## {{% heading "prerequisites" %}}
@@ -20,8 +18,6 @@ This page shows how to debug Pods and ReplicationControllers.
{{< glossary_tooltip text="Pods" term_id="pod" >}} and with
Pods' [lifecycles](/docs/concepts/workloads/pods/pod-lifecycle/).
-
-
## Debugging Pods
@@ -51,9 +47,9 @@ can not schedule your pod. Reasons include:
You may have exhausted the supply of CPU or Memory in your cluster. In this
case you can try several things:
-* [Add more nodes](/docs/admin/cluster-management/#resizing-a-cluster) to the cluster.
+* [Add more nodes](/docs/tasks/administer-cluster/cluster-management/#resizing-a-cluster) to the cluster.
-* [Terminate unneeded pods](/docs/user-guide/pods/single-container/#deleting_a_pod)
+* [Terminate unneeded pods](/docs/concepts/workloads/pods/#pod-termination)
to make room for pending pods.
* Check that the pod is not larger than your nodes. For example, if all
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-service.md b/content/en/docs/tasks/debug-application-cluster/debug-service.md
index c4e12042fb..4ee9d6f490 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-service.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-service.md
@@ -13,9 +13,6 @@ Deployment (or other workload controller) and created a Service, but you
get no response when you try to access it. This document will hopefully help
you to figure out what's going wrong.
-
-
-
## Running commands in a Pod
@@ -658,7 +655,7 @@ This might sound unlikely, but it does happen and it is supposed to work.
This can happen when the network is not properly configured for "hairpin"
traffic, usually when `kube-proxy` is running in `iptables` mode and Pods
are connected with bridge network. The `Kubelet` exposes a `hairpin-mode`
-[flag](/docs/admin/kubelet/) that allows endpoints of a Service to loadbalance
+[flag](/docs/reference/command-line-tools-reference/kubelet/) that allows endpoints of a Service to loadbalance
back to themselves if they try to access their own Service VIP. The
`hairpin-mode` flag must either be set to `hairpin-veth` or
`promiscuous-bridge`.
@@ -724,15 +721,13 @@ Service is not working. Please let us know what is going on, so we can help
investigate!
Contact us on
-[Slack](/docs/troubleshooting/#slack) or
+[Slack](/docs/tasks/debug-application-cluster/troubleshooting/#slack) or
[Forum](https://discuss.kubernetes.io) or
[GitHub](https://github.com/kubernetes/kubernetes).
-
-
## {{% heading "whatsnext" %}}
-
-Visit [troubleshooting document](/docs/troubleshooting/) for more information.
+Visit [troubleshooting document](/docs/tasks/debug-application-cluster/troubleshooting/)
+for more information.
diff --git a/content/en/docs/tasks/debug-application-cluster/debug-stateful-set.md b/content/en/docs/tasks/debug-application-cluster/debug-stateful-set.md
index 755c9b725e..bd7ce6e951 100644
--- a/content/en/docs/tasks/debug-application-cluster/debug-stateful-set.md
+++ b/content/en/docs/tasks/debug-application-cluster/debug-stateful-set.md
@@ -12,19 +12,13 @@ content_type: task
---
-
This task shows you how to debug a StatefulSet.
-
-
## {{% heading "prerequisites" %}}
-
* You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster.
* You should have a StatefulSet running that you want to investigate.
-
-
## Debugging a StatefulSet
@@ -37,18 +31,12 @@ kubectl get pods -l app=myapp
```
If you find that any Pods listed are in `Unknown` or `Terminating` state for an extended period of time,
-refer to the [Deleting StatefulSet Pods](/docs/tasks/manage-stateful-set/delete-pods/) task for
+refer to the [Deleting StatefulSet Pods](/docs/tasks/run-application/delete-stateful-set/) task for
instructions on how to deal with them.
You can debug individual Pods in a StatefulSet using the
[Debugging Pods](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/) guide.
-
-
## {{% heading "whatsnext" %}}
-
Learn more about [debugging an init-container](/docs/tasks/debug-application-cluster/debug-init-containers/).
-
-
-
diff --git a/content/en/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md b/content/en/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
index c47b117391..17e2ac45a2 100644
--- a/content/en/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
+++ b/content/en/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
@@ -10,7 +10,7 @@ title: Logging Using Elasticsearch and Kibana
On the Google Compute Engine (GCE) platform, the default logging support targets
[Stackdriver Logging](https://cloud.google.com/logging/), which is described in detail
-in the [Logging With Stackdriver Logging](/docs/user-guide/logging/stackdriver).
+in the [Logging With Stackdriver Logging](/docs/tasks/debug-application-cluster/logging-stackdriver).
This article describes how to set up a cluster to ingest logs into
[Elasticsearch](https://www.elastic.co/products/elasticsearch) and view
@@ -90,7 +90,8 @@ Elasticsearch, and is part of a service named `kibana-logging`.
The Elasticsearch and Kibana services are both in the `kube-system` namespace
and are not directly exposed via a publicly reachable IP address. To reach them,
-follow the instructions for [Accessing services running in a cluster](/docs/concepts/cluster-administration/access-cluster/#accessing-services-running-on-the-cluster).
+follow the instructions for
+[Accessing services running in a cluster](/docs/tasks/access-application-cluster/access-cluster/#accessing-services-running-on-the-cluster).
If you try accessing the `elasticsearch-logging` service in your browser, you'll
see a status page that looks something like this:
@@ -102,7 +103,7 @@ like. See [Elasticsearch's documentation](https://www.elastic.co/guide/en/elasti
for more details on how to do so.
Alternatively, you can view your cluster's logs using Kibana (again using the
-[instructions for accessing a service running in the cluster](/docs/user-guide/accessing-the-cluster/#accessing-services-running-on-the-cluster)).
+[instructions for accessing a service running in the cluster](/docs/tasks/access-application-cluster/access-cluster/#accessing-services-running-on-the-cluster)).
The first time you visit the Kibana URL you will be presented with a page that
asks you to configure your view of the ingested logs. Select the option for
timeseries values and select `@timestamp`. On the following page select the
diff --git a/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md b/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md
index be80133d34..1703bbbe42 100644
--- a/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md
+++ b/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md
@@ -317,8 +317,8 @@ After some time, Stackdriver Logging agent pods will be restarted with the new c
### Changing fluentd parameters
Fluentd configuration is stored in the `ConfigMap` object. It is effectively a set of configuration
-files that are merged together. You can learn about fluentd configuration on the [official
-site](http://docs.fluentd.org).
+files that are merged together. You can learn about fluentd configuration on the
+[official site](https://docs.fluentd.org).
Imagine you want to add a new parsing logic to the configuration, so that fluentd can understand
default Python logging format. An appropriate fluentd filter looks similar to this:
@@ -356,7 +356,7 @@ using [guide above](#changing-daemonset-parameters).
### Adding fluentd plugins
Fluentd is written in Ruby and allows to extend its capabilities using
-[plugins](http://www.fluentd.org/plugins). If you want to use a plugin, which is not included
+[plugins](https://www.fluentd.org/plugins). If you want to use a plugin, which is not included
in the default Stackdriver Logging container image, you have to build a custom image. Imagine
you want to add Kafka sink for messages from a particular container for additional processing.
You can re-use the default [container image sources](https://git.k8s.io/contrib/fluentd/fluentd-gcp-image)
diff --git a/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
index 098776cb7b..00c5eb8944 100644
--- a/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
+++ b/content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
@@ -13,9 +13,6 @@ are available in Kubernetes through the Metrics API. These metrics can be either
by user, for example by using `kubectl top` command, or used by a controller in the cluster, e.g.
Horizontal Pod Autoscaler, to make decisions.
-
-
-
## The Metrics API
@@ -41,11 +38,19 @@ The API requires metrics server to be deployed in the cluster. Otherwise it will
### CPU
-CPU is reported as the average usage, in [CPU cores](/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu), over a period of time. This value is derived by taking a rate over a cumulative CPU counter provided by the kernel (in both Linux and Windows kernels). The kubelet chooses the window for the rate calculation.
+CPU is reported as the average usage, in
+[CPU cores](/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu),
+over a period of time. This value is derived by taking a rate over a cumulative CPU counter
+provided by the kernel (in both Linux and Windows kernels).
+The kubelet chooses the window for the rate calculation.
### Memory
-Memory is reported as the working set, in bytes, at the instant the metric was collected. In an ideal world, the "working set" is the amount of memory in-use that cannot be freed under memory pressure. However, calculation of the working set varies by host OS, and generally makes heavy use of heuristics to produce an estimate. It includes all anonymous (non-file-backed) memory since kubernetes does not support swap. The metric typically also includes some cached (file-backed) memory, because the host OS cannot always reclaim such pages.
+Memory is reported as the working set, in bytes, at the instant the metric was collected.
+In an ideal world, the "working set" is the amount of memory in-use that cannot be freed under memory pressure.
+However, calculation of the working set varies by host OS, and generally makes heavy use of heuristics to produce an estimate.
+It includes all anonymous (non-file-backed) memory since kubernetes does not support swap.
+The metric typically also includes some cached (file-backed) memory, because the host OS cannot always reclaim such pages.
## Metrics Server
@@ -54,9 +59,12 @@ It is deployed by default in clusters created by `kube-up.sh` script
as a Deployment object. If you use a different Kubernetes setup mechanism you can deploy it using the provided
[deployment components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases) file.
-Metric server collects metrics from the Summary API, exposed by [Kubelet](/docs/admin/kubelet/) on each node.
+Metric server collects metrics from the Summary API, exposed by
+[Kubelet](/docs/reference/command-line-tools-reference/kubelet/) on each node.
Metrics Server is registered with the main API server through
-[Kubernetes aggregator](/docs/concepts/api-extension/apiserver-aggregation/).
+[Kubernetes aggregator](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
+
+Learn more about the metrics server in
+[the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md).
-Learn more about the metrics server in [the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md).
diff --git a/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
index 6cb716da9c..8255d06afe 100644
--- a/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
+++ b/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
@@ -10,29 +10,32 @@ title: Tools for Monitoring Resources
To scale an application and provide a reliable service, you need to
understand how the application behaves when it is deployed. You can examine
application performance in a Kubernetes cluster by examining the containers,
-[pods](/docs/user-guide/pods), [services](/docs/user-guide/services), and
+[pods](/docs/concepts/workloads/pods/),
+[services](/docs/concepts/services-networking/service/), and
the characteristics of the overall cluster. Kubernetes provides detailed
information about an application's resource usage at each of these levels.
This information allows you to evaluate your application's performance and
where bottlenecks can be removed to improve overall performance.
-
-
-In Kubernetes, application monitoring does not depend on a single monitoring solution. On new clusters, you can use [resource metrics](#resource-metrics-pipeline) or [full metrics](#full-metrics-pipeline) pipelines to collect monitoring statistics.
+In Kubernetes, application monitoring does not depend on a single monitoring solution.
+On new clusters, you can use [resource metrics](#resource-metrics-pipeline) or
+[full metrics](#full-metrics-pipeline) pipelines to collect monitoring statistics.
## Resource metrics pipeline
The resource metrics pipeline provides a limited set of metrics related to
-cluster components such as the [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale) controller, as well as the `kubectl top` utility.
+cluster components such as the
+[Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/)
+controller, as well as the `kubectl top` utility.
These metrics are collected by the lightweight, short-term, in-memory
[metrics-server](https://github.com/kubernetes-incubator/metrics-server) and
are exposed via the `metrics.k8s.io` API.
metrics-server discovers all nodes on the cluster and
queries each node's
-[kubelet](/docs/reference/command-line-tools-reference/kubelet) for CPU and
+[kubelet](/docs/reference/command-line-tools-reference/kubelet/) for CPU and
memory usage. The kubelet acts as a bridge between the Kubernetes master and
the nodes, managing the pods and containers running on a machine. The kubelet
translates each pod into its constituent containers and fetches individual
diff --git a/content/en/docs/tasks/debug-application-cluster/troubleshooting.md b/content/en/docs/tasks/debug-application-cluster/troubleshooting.md
index 82301275ce..24123e1d33 100644
--- a/content/en/docs/tasks/debug-application-cluster/troubleshooting.md
+++ b/content/en/docs/tasks/debug-application-cluster/troubleshooting.md
@@ -11,15 +11,14 @@ title: Troubleshooting
Sometimes things go wrong. This guide is aimed at making them right. It has
two sections:
- * [Troubleshooting your application](/docs/tasks/debug-application-cluster/debug-application/) - Useful for users who are deploying code into Kubernetes and wondering why it is not working.
- * [Troubleshooting your cluster](/docs/tasks/debug-application-cluster/debug-cluster/) - Useful for cluster administrators and people whose Kubernetes cluster is unhappy.
+* [Troubleshooting your application](/docs/tasks/debug-application-cluster/debug-application/) - Useful
+ for users who are deploying code into Kubernetes and wondering why it is not working.
+* [Troubleshooting your cluster](/docs/tasks/debug-application-cluster/debug-cluster/) - Useful
+ for cluster administrators and people whose Kubernetes cluster is unhappy.
You should also check the known issues for the [release](https://github.com/kubernetes/kubernetes/releases)
you're using.
-
-
-
## Getting help
@@ -37,12 +36,12 @@ accomplish commonly used tasks, and [Tutorials](/docs/tutorials/) are more
comprehensive walkthroughs of real-world, industry-specific, or end-to-end
development scenarios. The [Reference](/docs/reference/) section provides
detailed documentation on the [Kubernetes API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
-and command-line interfaces (CLIs), such as [`kubectl`](/docs/user-guide/kubectl-overview/).
+and command-line interfaces (CLIs), such as [`kubectl`](/docs/reference/kubectl/overview/).
You may also find the Stack Overflow topics relevant:
- * [Kubernetes](http://stackoverflow.com/questions/tagged/kubernetes)
- * [Google Kubernetes Engine](http://stackoverflow.com/questions/tagged/google-container-engine)
+* [Kubernetes](https://stackoverflow.com/questions/tagged/kubernetes)
+* [Google Kubernetes Engine](https://stackoverflow.com/questions/tagged/google-container-engine)
## Help! My question isn't covered! I need help now!
@@ -50,15 +49,16 @@ You may also find the Stack Overflow topics relevant:
Someone else from the community may have already asked a similar question or may
be able to help with your problem. The Kubernetes team will also monitor
-[posts tagged Kubernetes](http://stackoverflow.com/questions/tagged/kubernetes).
-If there aren't any existing questions that help, please [ask a new one](http://stackoverflow.com/questions/ask?tags=kubernetes)!
+[posts tagged Kubernetes](https://stackoverflow.com/questions/tagged/kubernetes).
+If there aren't any existing questions that help, please
+[ask a new one](https://stackoverflow.com/questions/ask?tags=kubernetes)!
### Slack
The Kubernetes team hangs out on Slack in the `#kubernetes-users` channel. You
can participate in discussion with the Kubernetes team [here](https://kubernetes.slack.com).
Slack requires registration, but the Kubernetes team is open invitation to
-anyone to register [here](http://slack.kubernetes.io). Feel free to come and ask
+anyone to register [here](https://slack.kubernetes.io). Feel free to come and ask
any and all questions.
Once registered, browse the growing list of channels for various subjects of
diff --git a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md
index 834c6983f7..337b426d2d 100644
--- a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md
+++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md
@@ -673,6 +673,8 @@ spec:
cronSpec:
type: string
pattern: '^(\d+|\*)(/\d+)?(\s+(\d+|\*)(/\d+)?){4}$'
+ image:
+ type: string
replicas:
type: integer
minimum: 1
@@ -720,6 +722,8 @@ spec:
cronSpec:
type: string
pattern: '^(\d+|\*)(/\d+)?(\s+(\d+|\*)(/\d+)?){4}$'
+ image:
+ type: string
replicas:
type: integer
minimum: 1
diff --git a/content/en/docs/tasks/manage-kubernetes-objects/declarative-config.md b/content/en/docs/tasks/manage-kubernetes-objects/declarative-config.md
index 308a4cf9b8..75c9d56a83 100644
--- a/content/en/docs/tasks/manage-kubernetes-objects/declarative-config.md
+++ b/content/en/docs/tasks/manage-kubernetes-objects/declarative-config.md
@@ -1005,7 +1005,7 @@ template:
* [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/)
* [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/imperative-config/)
-* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
+* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl-commands/)
* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
diff --git a/content/en/docs/tasks/manage-kubernetes-objects/imperative-command.md b/content/en/docs/tasks/manage-kubernetes-objects/imperative-command.md
index dd8b6b0f53..f8403dec17 100644
--- a/content/en/docs/tasks/manage-kubernetes-objects/imperative-command.md
+++ b/content/en/docs/tasks/manage-kubernetes-objects/imperative-command.md
@@ -167,7 +167,7 @@ kubectl create --edit -f /tmp/srv.yaml
* [Managing Kubernetes Objects Using Object Configuration (Imperative)](/docs/tasks/manage-kubernetes-objects/imperative-config/)
* [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tasks/manage-kubernetes-objects/declarative-config/)
-* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
+* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl-commands/)
* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
diff --git a/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md b/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md
index 97b62e6f0f..a8faefd63e 100644
--- a/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md
+++ b/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md
@@ -150,7 +150,7 @@ template:
* [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/)
* [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tasks/manage-kubernetes-objects/declarative-config/)
-* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
+* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl-commands/)
* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
diff --git a/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md
index a7d887da3b..01b03233c8 100644
--- a/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md
+++ b/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md
@@ -832,7 +832,7 @@ deployment.apps "dev-my-nginx" deleted
* [Kustomize](https://github.com/kubernetes-sigs/kustomize)
* [Kubectl Book](https://kubectl.docs.kubernetes.io)
-* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
+* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl-commands/)
* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
diff --git a/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md b/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md
index 55d9128f20..2613579ccf 100644
--- a/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md
+++ b/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md
@@ -229,7 +229,7 @@ The `kubectl patch` command has a `type` parameter that you can set to one of th
For a comparison of JSON patch and JSON merge patch, see
-[JSON Patch and JSON Merge Patch](http://erosb.github.io/post/json-patch-vs-merge-patch/).
+[JSON Patch and JSON Merge Patch](https://erosb.github.io/post/json-patch-vs-merge-patch/).
The default value for the `type` parameter is `strategic`. So in the preceding exercise, you
did a strategic merge patch.
diff --git a/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md
index e706c6179a..cda469f217 100644
--- a/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md
+++ b/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md
@@ -37,13 +37,23 @@ You can perform a graceful pod deletion with the following command:
kubectl delete pods
```
-For the above to lead to graceful termination, the Pod **must not** specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. The practice of setting a `pod.Spec.TerminationGracePeriodSeconds` of 0 seconds is unsafe and strongly discouraged for StatefulSet Pods. Graceful deletion is safe and will ensure that the Pod [shuts down gracefully](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) before the kubelet deletes the name from the apiserver.
+For the above to lead to graceful termination, the Pod **must not** specify a
+`pod.Spec.TerminationGracePeriodSeconds` of 0. The practice of setting a
+`pod.Spec.TerminationGracePeriodSeconds` of 0 seconds is unsafe and strongly discouraged
+for StatefulSet Pods. Graceful deletion is safe and will ensure that the Pod
+[shuts down gracefully](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
+before the kubelet deletes the name from the apiserver.
-Kubernetes (versions 1.5 or newer) will not delete Pods just because a Node is unreachable. The Pods running on an unreachable Node enter the 'Terminating' or 'Unknown' state after a [timeout](/docs/admin/node/#node-condition). Pods may also enter these states when the user attempts graceful deletion of a Pod on an unreachable Node. The only ways in which a Pod in such a state can be removed from the apiserver are as follows:
+Kubernetes (versions 1.5 or newer) will not delete Pods just because a Node is unreachable.
+The Pods running on an unreachable Node enter the 'Terminating' or 'Unknown' state after a
+[timeout](/docs/concepts/architecture/nodes/#node-condition).
+Pods may also enter these states when the user attempts graceful deletion of a Pod
+on an unreachable Node.
+The only ways in which a Pod in such a state can be removed from the apiserver are as follows:
- * The Node object is deleted (either by you, or by the [Node Controller](/docs/admin/node)).
- * The kubelet on the unresponsive Node starts responding, kills the Pod and removes the entry from the apiserver.
- * Force deletion of the Pod by the user.
+* The Node object is deleted (either by you, or by the [Node Controller](/docs/concepts/architecture/nodes/)).
+* The kubelet on the unresponsive Node starts responding, kills the Pod and removes the entry from the apiserver.
+* Force deletion of the Pod by the user.
The recommended best practice is to use the first or second approach. If a Node is confirmed to be dead (e.g. permanently disconnected from the network, powered down, etc), then delete the Node object. If the Node is suffering from a network partition, then try to resolve this or wait for it to resolve. When the partition heals, the kubelet will complete the deletion of the Pod and free up its name in the apiserver.
diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
index 6806ba0dc0..2c00e4aa7b 100644
--- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
@@ -15,11 +15,9 @@ Horizontal Pod Autoscaler automatically scales the number of pods
in a replication controller, deployment, replica set or stateful set based on observed CPU utilization
(or, with beta support, on some other, application-provided metrics).
-This document walks you through an example of enabling Horizontal Pod Autoscaler for the php-apache server. For more information on how Horizontal Pod Autoscaler behaves, see the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/).
-
-
-
-
+This document walks you through an example of enabling Horizontal Pod Autoscaler for the php-apache server.
+For more information on how Horizontal Pod Autoscaler behaves, see the
+[Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/).
## {{% heading "prerequisites" %}}
@@ -459,12 +457,12 @@ HorizontalPodAutoscaler.
## Appendix: Quantities
All metrics in the HorizontalPodAutoscaler and metrics APIs are specified using
-a special whole-number notation known in Kubernetes as a *quantity*. For example,
+a special whole-number notation known in Kubernetes as a
+{{< glossary_tooltip term_id="quantity" text="quantity">}}. For example,
the quantity `10500m` would be written as `10.5` in decimal notation. The metrics APIs
will return whole numbers without a suffix when possible, and will generally return
quantities in milli-units otherwise. This means you might see your metric value fluctuate
-between `1` and `1500m`, or `1` and `1.5` when written in decimal notation. See the
-[glossary entry on quantities](/docs/reference/glossary?core-object=true#term-quantity) for more information.
+between `1` and `1500m`, or `1` and `1.5` when written in decimal notation.
## Appendix: Other possible scenarios
diff --git a/content/en/docs/tasks/run-application/run-replicated-stateful-application.md b/content/en/docs/tasks/run-application/run-replicated-stateful-application.md
index 2a7d255c2b..a5346f0272 100644
--- a/content/en/docs/tasks/run-application/run-replicated-stateful-application.md
+++ b/content/en/docs/tasks/run-application/run-replicated-stateful-application.md
@@ -33,7 +33,7 @@ on general patterns for running stateful applications in Kubernetes.
* This tutorial assumes you are familiar with
[PersistentVolumes](/docs/concepts/storage/persistent-volumes/)
and [StatefulSets](/docs/concepts/workloads/controllers/statefulset/),
- as well as other core concepts like [Pods](/docs/concepts/workloads/pods/pod/),
+ as well as other core concepts like [Pods](/docs/concepts/workloads/pods/),
[Services](/docs/concepts/services-networking/service/), and
[ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/).
* Some familiarity with MySQL helps, but this tutorial aims to present
@@ -297,7 +297,7 @@ running while you force a Pod out of the Ready state.
### Break the Readiness Probe
-The [readiness probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-readiness-probes)
+The [readiness probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes)
for the `mysql` container runs the command `mysql -h 127.0.0.1 -e 'SELECT 1'`
to make sure the server is up and able to execute queries.
diff --git a/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md b/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md
index 499bc1fa90..95213176bf 100644
--- a/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md
+++ b/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md
@@ -8,14 +8,13 @@ content_type: task
{{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}}
-Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes cluster. Up to date information on this process can be found at the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog/blob/master/docs/install.md) repo.
-
-
-
+Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes cluster.
+Up to date information on this process can be found at the
+[kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog/blob/master/docs/install.md) repo.
## {{% heading "prerequisites" %}}
-* Understand the key concepts of [Service Catalog](/docs/concepts/service-catalog/).
+* Understand the key concepts of [Service Catalog](/docs/concepts/extend-kubernetes/service-catalog/).
* Service Catalog requires a Kubernetes cluster running version 1.7 or higher.
* You must have a Kubernetes cluster with cluster DNS enabled.
* If you are using a cloud-based Kubernetes cluster or {{< glossary_tooltip text="Minikube" term_id="minikube" >}}, you may already have cluster DNS enabled.
diff --git a/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md b/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md
index a45474e297..937f1170a7 100644
--- a/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md
+++ b/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md
@@ -19,7 +19,7 @@ Service Catalog itself can work with any kind of managed service, not just Googl
## {{% heading "prerequisites" %}}
-* Understand the key concepts of [Service Catalog](/docs/concepts/service-catalog/).
+* Understand the key concepts of [Service Catalog](/docs/concepts/extend-kubernetes/service-catalog/).
* Install [Go 1.6+](https://golang.org/dl/) and set the `GOPATH`.
* Install the [cfssl](https://github.com/cloudflare/cfssl) tool needed for generating SSL artifacts.
* Service Catalog requires Kubernetes version 1.7+.
diff --git a/content/en/docs/tasks/tools/_index.md b/content/en/docs/tasks/tools/_index.md
index 7f43d34be7..a942f3ea87 100755
--- a/content/en/docs/tasks/tools/_index.md
+++ b/content/en/docs/tasks/tools/_index.md
@@ -33,7 +33,7 @@ Once you have Minikube working, you can use it to
## kind
Like Minikube, [kind](https://kind.sigs.k8s.io/docs/) lets you run Kubernetes on
-your local compute. Unlike Minikuke, kind only works with a single container runtime:
+your local computer. Unlike Minikube, kind only works with a single container runtime:
it requires that you have [Docker](https://docs.docker.com/get-docker/) installed
and configured.
diff --git a/content/en/docs/tasks/tools/install-kubectl.md b/content/en/docs/tasks/tools/install-kubectl.md
index e3d6c0aa9c..2d9c8f1adb 100644
--- a/content/en/docs/tasks/tools/install-kubectl.md
+++ b/content/en/docs/tasks/tools/install-kubectl.md
@@ -11,13 +11,18 @@ card:
---
-The Kubernetes command-line tool, [kubectl](/docs/user-guide/kubectl/), allows you to run commands against Kubernetes clusters. You can use kubectl to deploy applications, inspect and manage cluster resources, and view logs. For a complete list of kubectl operations, see [Overview of kubectl](/docs/reference/kubectl/overview/).
+The Kubernetes command-line tool, [kubectl](/docs/reference/kubectl/kubectl/), allows
+you to run commands against Kubernetes clusters.
+You can use kubectl to deploy applications, inspect and manage cluster resources,
+and view logs. For a complete list of kubectl operations, see
+[Overview of kubectl](/docs/reference/kubectl/overview/).
## {{% heading "prerequisites" %}}
-You must use a kubectl version that is within one minor version difference of your cluster. For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master. Using the latest version of kubectl helps avoid unforeseen issues.
-
+You must use a kubectl version that is within one minor version difference of your cluster.
+For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master.
+Using the latest version of kubectl helps avoid unforeseen issues.
diff --git a/content/en/docs/tutorials/_index.md b/content/en/docs/tutorials/_index.md
index 2313d78e87..b4f0709a76 100644
--- a/content/en/docs/tutorials/_index.md
+++ b/content/en/docs/tutorials/_index.md
@@ -45,16 +45,6 @@ Before walking through each tutorial, you may want to bookmark the
* [Running ZooKeeper, A CP Distributed System](/docs/tutorials/stateful-application/zookeeper/)
-## CI/CD Pipeline
-
-* [Set Up a CI/CD Pipeline with Kubernetes Part 1: Overview](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/5/set-cicd-pipeline-kubernetes-part-1-overview)
-
-* [Set Up a CI/CD Pipeline with a Jenkins Pod in Kubernetes (Part 2)](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/6/set-cicd-pipeline-jenkins-pod-kubernetes-part-2)
-
-* [Run and Scale a Distributed Crossword Puzzle App with CI/CD on Kubernetes (Part 3)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/run-and-scale-distributed-crossword-puzzle-app-cicd-kubernetes-part-3)
-
-* [Set Up CI/CD for a Distributed Crossword Puzzle App on Kubernetes (Part 4)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/set-cicd-distributed-crossword-puzzle-app-kubernetes-part-4)
-
## Clusters
* [AppArmor](/docs/tutorials/clusters/apparmor/)
diff --git a/content/en/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/en/docs/tutorials/kubernetes-basics/explore/explore-intro.html
index f3608039dc..3b5a51dc40 100644
--- a/content/en/docs/tutorials/kubernetes-basics/explore/explore-intro.html
+++ b/content/en/docs/tutorials/kubernetes-basics/explore/explore-intro.html
@@ -29,7 +29,7 @@ weight: 10
Kubernetes Pods
-
When you created a Deployment in Module 2, Kubernetes created a Pod to host your application instance. A Pod is a Kubernetes abstraction that represents a group of one or more application containers (such as Docker or rkt), and some shared resources for those containers. Those resources include:
+
When you created a Deployment in Module 2, Kubernetes created a Pod to host your application instance. A Pod is a Kubernetes abstraction that represents a group of one or more application containers (such as Docker), and some shared resources for those containers. Those resources include:
Shared storage, as Volumes
Networking, as a unique cluster IP address
@@ -51,7 +51,7 @@ weight: 10
- A Pod is a group of one or more application containers (such as Docker or rkt) and includes shared storage (volumes), IP address and information about how to run them.
+ A Pod is a group of one or more application containers (such as Docker) and includes shared storage (volumes), IP address and information about how to run them.
@@ -79,7 +79,7 @@ weight: 10
Every Kubernetes Node runs at least:
Kubelet, a process responsible for communication between the Kubernetes Master and the Node; it manages the Pods and the containers running on a machine.
-
A container runtime (like Docker, rkt) responsible for pulling the container image from a registry, unpacking the container, and running the application.
+
A container runtime (like Docker) responsible for pulling the container image from a registry, unpacking the container, and running the application.
diff --git a/content/en/docs/tutorials/services/source-ip.md b/content/en/docs/tutorials/services/source-ip.md
index 3bdf9d492f..2d938f3031 100644
--- a/content/en/docs/tutorials/services/source-ip.md
+++ b/content/en/docs/tutorials/services/source-ip.md
@@ -150,7 +150,7 @@ ip addr
…then use `wget` to query the local webserver
```shell
-# Replace 10.0.170.92 with the Pod's IPv4 address
+# Replace "10.0.170.92" with the IPv4 address of the Service named "clusterip"
wget -qO - 10.0.170.92
```
```
diff --git a/content/es/docs/tutorials/_index.md b/content/es/docs/tutorials/_index.md
index ebf5de461c..47db2da8b9 100644
--- a/content/es/docs/tutorials/_index.md
+++ b/content/es/docs/tutorials/_index.md
@@ -49,16 +49,6 @@ Antes de recorrer cada tutorial, recomendamos añadir un marcador a
* [Running ZooKeeper, A CP Distributed System](/docs/tutorials/stateful-application/zookeeper/)
-## Pipelines de CI/CD
-
-* [Set Up a CI/CD Pipeline with Kubernetes Part 1: Overview](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/5/set-cicd-pipeline-kubernetes-part-1-overview)
-
-* [Set Up a CI/CD Pipeline with a Jenkins Pod in Kubernetes (Part 2)](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/6/set-cicd-pipeline-jenkins-pod-kubernetes-part-2)
-
-* [Run and Scale a Distributed Crossword Puzzle App with CI/CD on Kubernetes (Part 3)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/run-and-scale-distributed-crossword-puzzle-app-cicd-kubernetes-part-3)
-
-* [Set Up CI/CD for a Distributed Crossword Puzzle App on Kubernetes (Part 4)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/set-cicd-distributed-crossword-puzzle-app-kubernetes-part-4)
-
## Clústers
* [AppArmor](/docs/tutorials/clusters/apparmor/)
diff --git a/content/fr/_index.html b/content/fr/_index.html
index 3b659534e8..db8c749aeb 100644
--- a/content/fr/_index.html
+++ b/content/fr/_index.html
@@ -41,7 +41,6 @@ Kubernetes est une solution open-source qui vous permet de tirer parti de vos in
diff --git a/content/fr/docs/tasks/configure-pod-container/quality-service-pod.md b/content/fr/docs/tasks/configure-pod-container/quality-service-pod.md
index 8b666ccd98..93e785f54c 100644
--- a/content/fr/docs/tasks/configure-pod-container/quality-service-pod.md
+++ b/content/fr/docs/tasks/configure-pod-container/quality-service-pod.md
@@ -75,7 +75,8 @@ spec:
requests:
cpu: 700m
memory: 200Mi
-...
+ ...
+status:
qosClass: Guaranteed
```
@@ -124,7 +125,8 @@ spec:
memory: 200Mi
requests:
memory: 100Mi
-...
+ ...
+status:
qosClass: Burstable
```
@@ -163,6 +165,7 @@ spec:
...
resources: {}
...
+status:
qosClass: BestEffort
```
@@ -208,6 +211,7 @@ spec:
name: qos-demo-4-ctr-2
resources: {}
...
+status:
qosClass: Burstable
```
diff --git a/content/fr/docs/tutorials/_index.md b/content/fr/docs/tutorials/_index.md
index 10e1124620..aad40f53aa 100644
--- a/content/fr/docs/tutorials/_index.md
+++ b/content/fr/docs/tutorials/_index.md
@@ -47,17 +47,6 @@ Avant d'explorer chacun des tutoriels, il peut-être utile de garder un signet p
* [Exécuter ZooKeeper, un système distribué CP (EN)](/docs/tutorials/stateful-application/zookeeper/)
-## Pipeline d'Intégration continue et de déploiement continu (CI/CD)
-
-* Mettre en place un pipeline CI/CD avec Kubernetes:
- * [1ère partie: Vue d'ensemble (EN)](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/5/set-cicd-pipeline-kubernetes-part-1-overview)
-
- * [2ème partie: avec un Pod Jenkins (EN)](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/6/set-cicd-pipeline-jenkins-pod-kubernetes-part-2)
-
- * [3ème partie: Exécuter et mettre à l'échelle une application distribuée de mots croisés (EN)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/run-and-scale-distributed-crossword-puzzle-app-cicd-kubernetes-part-3)
-
- * [4ème partie: mettre en place un pipeline CI/CD pour une application distribuée de mots croisés avec Kubernetes (EN)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/set-cicd-distributed-crossword-puzzle-app-kubernetes-part-4)
-
## Clusters
* [AppArmor (EN)](/docs/tutorials/clusters/apparmor/)
diff --git a/content/id/docs/tasks/administer-cluster/dns-debugging-resolution.md b/content/id/docs/tasks/administer-cluster/dns-debugging-resolution.md
new file mode 100644
index 0000000000..aeeeab1001
--- /dev/null
+++ b/content/id/docs/tasks/administer-cluster/dns-debugging-resolution.md
@@ -0,0 +1,254 @@
+---
+reviewers:
+title: Debugging Resolusi DNS
+content_type: task
+min-kubernetes-server-version: v1.6
+---
+
+
+Laman ini menyediakan beberapa petunjuk untuk mendiagnosis masalah DNS.
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}}
+Klaster kamu harus dikonfigurasi untuk menggunakan
+{{< glossary_tooltip text="addon" term_id="addons" >}} CoreDNS atau pendahulunya,
+kube-dns.
+
+{{% version-check %}}
+
+
+
+### Membuat Pod sederhana yang digunakan sebagai lingkungan pengujian
+
+{{< codenew file="admin/dns/dnsutils.yaml" >}}
+
+Gunakan manifes berikut untuk membuat sebuah Pod:
+
+```shell
+kubectl apply -f https://k8s.io/examples/admin/dns/dnsutils.yaml
+```
+```
+pod/dnsutils created
+```
+…dan verifikasi statusnya:
+```shell
+kubectl get pods dnsutils
+```
+```
+NAME READY STATUS RESTARTS AGE
+dnsutils 1/1 Running 0
+```
+
+Setelah Pod tersebut berjalan, kamu dapat menjalankan perintah `nslookup` di lingkungan tersebut.
+Jika kamu melihat hal seperti ini, maka DNS sudah berjalan dengan benar.
+
+```shell
+kubectl exec -i -t dnsutils -- nslookup kubernetes.default
+```
+```
+Server: 10.0.0.10
+Address 1: 10.0.0.10
+
+Name: kubernetes.default
+Address 1: 10.0.0.1
+```
+
+Jika perintah `nslookup` gagal, periksa hal berikut:
+
+### Periksa konfigurasi DNS lokal terlebih dahulu
+
+Periksa isi dari berkas resolv.conf.
+(Lihat [_Inheriting_ DNS dari node](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) dan
+[Isu-isu yang dikenal](#known-issues) di bawah ini untuk informasi lebih lanjut)
+
+```shell
+kubectl exec -ti dnsutils -- cat /etc/resolv.conf
+```
+
+Verifikasi _path_ pencarian dan nama server telah dibuat agar tampil seperti di bawah ini (perlu diperhatikan bahwa _path_ pencarian dapat berbeda tergantung dari penyedia layanan cloud):
+
+```
+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
+```
+
+Kesalahan yang muncul berikut ini mengindikasikan terdapat masalah dengan _add-on_ CoreDNS (atau kube-dns) atau Service terkait:
+
+```shell
+kubectl exec -i -t dnsutils -- nslookup kubernetes.default
+```
+```
+Server: 10.0.0.10
+Address 1: 10.0.0.10
+
+nslookup: can't resolve 'kubernetes.default'
+```
+
+atau
+
+```shell
+kubectl exec -i -t dnsutils -- 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'
+```
+
+### Periksa apakah Pod DNS sedang berjalan
+
+Gunakan perintah `kubectl get pods` untuk memverifikasi apakah Pod DNS sedang berjalan.
+
+```shell
+kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
+```
+```
+NAME READY STATUS RESTARTS AGE
+...
+coredns-7b96bf9f76-5hsxb 1/1 Running 0 1h
+coredns-7b96bf9f76-mvmmt 1/1 Running 0 1h
+...
+```
+
+{{< note >}}
+Nilai dari label `k8s-app` adalah `kube-dns` baik untuk CoreDNS maupun kube-dns.
+{{< /note >}}
+
+Jika kamu melihat tidak ada Pod CoreDNS yang sedang berjalan atau Pod tersebut gagal/telah selesai, _add-on_ DNS mungkin tidak dijalankan (_deployed_) secara bawaan di lingkunganmu saat ini dan kamu harus menjalankannya secara manual.
+
+### Periksa kesalahan pada Pod DNS
+
+Gunakan perintah `kubectl logs` untuk melihat log dari Container DNS.
+
+Untuk CoreDNS:
+```shell
+kubectl logs --namespace=kube-system -l k8s-app=kube-dns
+```
+
+Berikut contoh log dari CoreDNS yang sehat (_healthy_):
+
+```
+.:53
+2018/08/15 14:37:17 [INFO] CoreDNS-1.2.2
+2018/08/15 14:37:17 [INFO] linux/amd64, go1.10.3, 2e322f6
+CoreDNS-1.2.2
+linux/amd64, go1.10.3, 2e322f6
+2018/08/15 14:37:17 [INFO] plugin/reload: Running configuration MD5 = 24e6c59e83ce706f07bcc82c31b1ea1c
+```
+
+Periksa jika ada pesan mencurigakan atau tidak terduga dalam log.
+
+### Apakah layanan DNS berjalan?
+
+Verifikasi apakah layanan DNS berjalan dengan menggunakan perintah `kubectl get service`.
+
+```shell
+kubectl get svc --namespace=kube-system
+```
+```
+NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+...
+kube-dns ClusterIP 10.0.0.10 53/UDP,53/TCP 1h
+...
+```
+
+{{< note >}}
+Nama layanan adalah `kube-dns` baik untuk CoreDNS maupun kube-dns.
+{{< /note >}}
+
+Jika kamu telah membuat Service atau seharusnya Service telah dibuat secara bawaan namun ternyata tidak muncul, lihat
+[_debugging_ Service](/docs/tasks/debug-application-cluster/debug-service/) untuk informasi lebih lanjut.
+
+### Apakah endpoint DNS telah ekspos?
+
+Kamu dapat memverifikasikan apakah _endpoint_ DNS telah diekspos dengan menggunakan perintah `kubectl get endpoints`.
+
+```shell
+kubectl get endpoints kube-dns --namespace=kube-system
+```
+```
+NAME ENDPOINTS AGE
+kube-dns 10.180.3.17:53,10.180.3.17:53 1h
+```
+
+Jika kamu tidak melihat _endpoint_, lihat bagian _endpoint_ pada dokumentasi
+[_debugging_ Service](/docs/tasks/debug-application-cluster/debug-service/).
+
+Untuk tambahan contoh Kubernetes DNS, lihat
+[contoh cluster-dns](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns) pada repositori Kubernetes GitHub.
+
+### Apakah kueri DNS diterima/diproses?
+
+Kamu dapat memverifikasi apakah kueri telah diterima oleh CoreDNS dengan menambahkan plugin `log` pada konfigurasi CoreDNS (alias Corefile).
+CoreDNS Corefile disimpan pada {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} dengan nama `coredns`. Untuk mengeditnya, gunakan perintah:
+
+```
+kubectl -n kube-system edit configmap coredns
+```
+
+Lalu tambahkan `log` pada bagian Corefile seperti contoh berikut:
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ name: coredns
+ namespace: kube-system
+data:
+ Corefile: |
+ .:53 {
+ log
+ errors
+ health
+ kubernetes cluster.local in-addr.arpa ip6.arpa {
+ pods insecure
+ upstream
+ fallthrough in-addr.arpa ip6.arpa
+ }
+ prometheus :9153
+ proxy . /etc/resolv.conf
+ cache 30
+ loop
+ reload
+ loadbalance
+ }
+```
+
+Setelah perubahan disimpan, perubahan dapat memakan waktu satu hingga dua menit untuk Kubernetes menyebarkan perubahan ini pada Pod CoreDNS.
+
+Berikutnya, coba buat beberapa kueri dan lihat log pada bagian atas dari dokumen ini. Jika pod CoreDNS menerima kueri, kamu seharusnya akan melihatnya pada log.
+
+Berikut ini contoh kueri yang terdapat di dalam log:
+
+```
+.:53
+2018/08/15 14:37:15 [INFO] CoreDNS-1.2.0
+2018/08/15 14:37:15 [INFO] linux/amd64, go1.10.3, 2e322f6
+CoreDNS-1.2.0
+linux/amd64, go1.10.3, 2e322f6
+2018/09/07 15:29:04 [INFO] plugin/reload: Running configuration MD5 = 162475cdf272d8aa601e6fe67a6ad42f
+2018/09/07 15:29:04 [INFO] Reloading complete
+172.17.0.18:41675 - [07/Sep/2018:15:29:11 +0000] 59925 "A IN kubernetes.default.svc.cluster.local. udp 54 false 512" NOERROR qr,aa,rd,ra 106 0.000066649s
+```
+
+## Isu-isu yang Dikenal
+
+Beberapa distribusi Linux (contoh Ubuntu) menggunakan _resolver_ DNS lokal secara bawaan (systemd-resolved).
+Systemd-resolved memindahkan dan mengganti `/etc/resolv.conf` dengan berkas _stub_ yang dapat menyebabkan _forwarding loop_ yang fatal saat meresolusi nama pada server _upstream_. Ini dapat diatasi secara manual dengan menggunakan _flag_ kubelet `--resolv-conf`
+untuk mengarahkan ke `resolv.conf` yang benar (Pada `systemd-resolved`, ini berada di `/run/systemd/resolve/resolv.conf`).
+kubeadm akan otomatis mendeteksi `systemd-resolved`, dan menyesuaikan _flag_ kubelet sebagai mana mestinya.
+
+Pemasangan Kubernetes tidak menggunakan berkas `resolv.conf` pada _node_ untuk digunakan sebagai klaster DNS secara _default_, karena proses ini umumnya spesifik pada distribusi tertentu. Hal ini bisa jadi akan diimplementasi nantinya.
+
+Libc Linux (alias glibc) secara bawaan memiliki batasan `nameserver` DNS sebanyak 3 rekaman (_records_). Selain itu, pada glibc versi yang lebih lama dari glibc-2.17-222 ([versi terbaru lihat isu ini](https://access.redhat.com/solutions/58028)), jumlah rekaman DNS `search` dibatasi sejumlah 6 ([lihat masalah sejak 2005 ini](https://bugzilla.redhat.com/show_bug.cgi?id=168253)). Kubernetes membutuhkan 1 rekaman `nameserver` dan 3 rekaman `search`. Ini berarti jika instalasi lokal telah menggunakan 3 `nameserver` atau menggunakan lebih dari 3 `search`,sementara versi glibc kamu termasuk yang terkena dampak, beberapa dari pengaturan tersebut akan hilang. Untuk menyiasati batasan rekaman DNS `nameserver`, _node_ dapat menjalankan `dnsmasq`,yang akan menyediakan `nameserver` lebih banyak. Kamu juga dapat menggunakan kubelet `--resolv-conf` _flag_. Untuk menyiasati batasan rekaman `search`, pertimbangkan untuk memperbarui distribusi linux kamu atau memperbarui glibc ke versi yang tidak terdampak.
+
+Jika kamu menggunakan Alpine versi 3.3 atau lebih lama sebagai dasar _image_ kamu, DNS mungkin tidak dapat bekerja dengan benar disebabkan masalah dengan Alpine.
+[Masalah 30215](https://github.com/kubernetes/kubernetes/issues/30215) Kubernetes menyediakan informasi lebih detil tentang ini.
+
+## {{% heading "whatsnext" %}}
+
+- Lihat [Penyekalaan otomatis Service DNS dalam klaster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/).
+- Baca [DNS untuk Service dan Pod](/docs/concepts/services-networking/dns-pod-service/)
\ No newline at end of file
diff --git a/content/id/docs/tasks/configure-pod-container/static-pod.md b/content/id/docs/tasks/configure-pod-container/static-pod.md
new file mode 100644
index 0000000000..6088b458db
--- /dev/null
+++ b/content/id/docs/tasks/configure-pod-container/static-pod.md
@@ -0,0 +1,243 @@
+---
+title: Membuat Pod Statis
+weight: 170
+content_type: task
+---
+
+
+
+Pod statis dikelola langsung oleh _daemon_ kubelet pada suatu Node spesifik,
+tanpa {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}
+mengobservasi mereka.
+Tidak seperti Pod yang dikelola oleh _control plane_ (contohnya,
+{{< glossary_tooltip text="Deployment" term_id="deployment" >}});
+kubelet akan memantau setiap Pod statis (dan menjalankan ulang jika
+Pod mengalami kegagalan).
+
+Pod statis selalu terikat pada satu {{< glossary_tooltip term_id="kubelet" >}}
+di dalam Node spesifik.
+
+Kubelet secara otomatis akan mengulang untuk membuat sebuah
+{{< glossary_tooltip text="Pod mirror" term_id="mirror-pod" >}}
+pada server API Kubernetes untuk setiap Pod statis.
+Ini berarti Pod yang berjalan pada Node akan terlihat oleh API server,
+namun tidak dapat mengontrol dari sana.
+
+{{< note >}}
+Jika kamu menjalankan klaster Kubernetes dan menggunakan Pod statis
+untuk menjalankan Pod pada setiap Node, kamu kemungkinan harus menggunakan
+sebuah {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}.
+{{< /note >}}
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+Laman ini mengasumsikan kamu menggunakan {{< glossary_tooltip term_id="docker" >}}
+untuk menjalankan Pod, dan Node kamu berjalan menggunakan sistem operasi Fedora.
+Instruksi untuk distribusi lain atau instalasi Kubernetes mungkin berbeda.
+
+
+
+## Membuat sebuah Pod statis
+
+Kamu dapat mengatur Pod statis dengan menggunakan sebuah
+[berkas konfigurasi pada _file system_](#konfigurasi-melalui-berkas-sistem)
+atau sebuah [berkas konfigurasi ditempatkan pada web](#konfigurasi-melalui-http).
+
+### Manifes Pod statis pada berkas sistem (_file system_) {#konfigurasi-melalui-berkas-sistem}
+
+Manifes adalah standar definisi Pod dalam format JSON atau YAML pada suatu direktori.
+Gunakan _field_ `staticPodPath: ` pada
+[berkas konfigurasi kubelet](/docs/tasks/administer-cluster/kubelet-config-file),
+yang akan membaca direktori
+secara berkala dan membuat atau menghapus Pod statis sesuai dengan berkas YAML/JSON
+yang bertambah atau berkurang disana.
+
+Catatan bahwa kubelet akan mengabaikan berkas yang diawali dengan titik (_dot_)
+ketika memindai suatu direktori.
+
+Sebagai contoh, ini cara untuk memulai server web sederhana sebagai Pod statis:
+
+1. Pilih Node yang kamu pilih untuk menjalankan Pod statis. Dalam contoh ini adalah `my-node1`.
+
+ ```shell
+ ssh my-node1
+ ```
+
+2. Pilih sebuah direktori, katakan `/etc/kubelet.d` dan letakkan berkas definisi Pod untuk web server disana, contohnya `/etc/kubelet.d/static-web.yaml`:
+
+ ```shell
+ # Jalankan perintah ini pada Node tempat kubelet sedang berjalan
+ mkdir /etc/kubelet.d/
+ cat </etc/kubelet.d/static-web.yaml
+ apiVersion: v1
+ kind: Pod
+ metadata:
+ name: static-web
+ labels:
+ role: myrole
+ spec:
+ containers:
+ - name: web
+ image: nginx
+ ports:
+ - name: web
+ containerPort: 80
+ protocol: TCP
+ EOF
+ ```
+
+3. Atur kubelet pada Node untuk menggunakan direktori ini dengan menjalankannya menggunakan argumen `--pod-manifest-path=/etc/kubelet.d/`. Pada Fedora, ubah berkas `/etc/kubernetes/kubelet` dengan menambahkan baris berikut:
+
+ ```
+ KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
+ ```
+ atau tambahkan _field_ `staticPodPath: ` pada [berkas konfigurasi kubelet](/docs/tasks/administer-cluster/kubelet-config-file).
+
+4. Jalankan ulang kubelet. Pada Fedora, kamu dapat menjalankan:
+
+ ```shell
+ # Jalankan perintah berikut pada Node tempat kubelet berjalan
+ systemctl restart kubelet
+ ```
+
+### Manifes Pod statis pada Web {#konfigurasi-melalui-http}
+
+Berkas yang ditentukan pada argumen `--manifest-url=` akan diunduh oleh kubelet secara berkala
+dan kubelet akan menginterpretasinya sebagai sebuah berkas JSON/YAML yang berisikan definisi Pod.
+Mirip dengan cara kerja [manifes pada _filesystem_](##konfigurasi-melalui-berkas-sistem),
+kubelet akan mengambil manifes berdasarkan jadwal. Jika ada perubahan pada daftar
+Pod statis, maka kubelet akan menerapkannya.
+
+Untuk menggunakan cara ini:
+
+1. Buat sebuah berkas YAML dan simpan pada suatu web server sehingga kamu pada memberikan URL tersebut pada kubelet.
+
+ ```yaml
+ apiVersion: v1
+ kind: Pod
+ metadata:
+ name: static-web
+ labels:
+ role: myrole
+ spec:
+ containers:
+ - name: web
+ image: nginx
+ ports:
+ - name: web
+ containerPort: 80
+ protocol: TCP
+ ```
+
+2. Atur kubelet pada suatu Node untuk menggunakan manifes pada web ini dengan menjalankan menggunakan argumen `--manifest-url=`. Pada Fedora, ubah pada `/etc/kubernetes/kubelet` untuk menambahkan baris ini:
+
+ ```
+ KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --manifest-url="
+ ```
+
+3. Jalankan ulang kubelet. Pada Fedora, kamu dapat menjalankan:
+
+ ```shell
+ # Jalankan perintah ini pada Node tempat kubelet berjalan
+ systemctl restart kubelet
+ ```
+
+## Mengobservasi perilaku Pod statis
+
+Ketika kubelet berjalan, secara otomatis akan menjalankan semua Pod statis yang terdefinisi.
+Ketika kamu mendefinisikan Pod statis dan menjalankan ulang kubelet, Pod statis yang baru
+akan dijalankan.
+
+Kamu dapat melihat Container yang berjalan (termasuk Pod statis) dengan menjalankan (pada Node):
+```shell
+# Jalankan perintah ini pada Node tempat kubelet berjalan
+docker ps
+```
+
+Keluarannya kira-kira seperti berikut:
+
+```
+CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
+f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c
+```
+
+Kamu dapat melihat Pod _mirror_ tersebut pada API server:
+
+```shell
+kubectl get pods
+```
+```
+NAME READY STATUS RESTARTS AGE
+static-web-my-node1 1/1 Running 0 2m
+```
+
+{{< note >}}
+Pastikan kubelet memiliki izin untuk membuat Pod _mirror_ pada server API. Jika tidak,
+pembuatannya akan ditolak oleh API server. Lihat
+[PodSecurityPolicy](/id/docs/concepts/policy/pod-security-policy/).
+{{< /note >}}
+
+
+{{< glossary_tooltip term_id="label" text="Label" >}} dari Pod statis
+akan dibuat juga pada Pod _mirror_. Kamu dapat menggunakan label tersebut
+seperti biasa menggunakan {{< glossary_tooltip term_id="selector" text="selector-selector" >}},
+atau yang lainnya.
+
+Kamu dapat mencoba untuk menggunakan kubelet untuk menghapus Pod _mirror_ tersebut pada API server,
+namun kubelet tidak akan menghapus Pod statis:
+
+```shell
+kubectl delete pod static-web-my-node1
+```
+```
+pod "static-web-my-node1" deleted
+```
+Kamu akan melihat bahwa Pod tersebut tetap berjalan:
+```shell
+kubectl get pods
+```
+```
+NAME READY STATUS RESTARTS AGE
+static-web-my-node1 1/1 Running 0 12s
+```
+
+Kembali ke Node tempat kubelet berjalan, kamu dapat mencoba menghentikan Container
+Docker secara manual.
+Kamu akan melihat, setelah beberapa saat, kubelet akan mengetahui dan akan menjalankan ulang Pod
+secara otomatis:
+
+```shell
+# Jalankan perintah ini pada Node tempat kubelet berjalan
+docker stop f6d05272b57e # ganti dengan ID pada Container-mu
+sleep 20
+docker ps
+```
+```
+CONTAINER ID IMAGE COMMAND CREATED ...
+5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ...
+```
+
+## Penambahan dan pengurangan secara dinamis pada Pod statis
+
+Direktori konfigurasi (`/etc/kubelet.d` pada contoh kita) akan dipindai secara berkala oleh kubelet
+untuk melakukan perubahan dan penambahan/pengurangan
+Pod sesuai dengan penambahan/pengurangan berkas pada direktori tersebut.
+
+```shell
+# Ini mengasumsikan kamu menggunakan konfigurasi Pod statis pada _filesystem_
+# Jalankan perintah ini pada Node tempat kubelet berjalan
+#
+mv /etc/kubelet.d/static-web.yaml /tmp
+sleep 20
+docker ps
+# Kamu mendapatkan bahwa tidak ada Container nginx yang berjalan
+mv /tmp/static-web.yaml /etc/kubelet.d/
+sleep 20
+docker ps
+```
+```
+CONTAINER ID IMAGE COMMAND CREATED ...
+e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago
+```
diff --git a/content/id/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/id/docs/tasks/inject-data-application/distribute-credentials-secure.md
new file mode 100644
index 0000000000..c08db9484f
--- /dev/null
+++ b/content/id/docs/tasks/inject-data-application/distribute-credentials-secure.md
@@ -0,0 +1,253 @@
+---
+title: Mendistribusikan Kredensial dengan Aman Menggunakan Secret
+content_type: task
+weight: 50
+min-kubernetes-server-version: v1.6
+---
+
+
+Laman ini menjelaskan bagaimana cara menginjeksi data sensitif, seperti kata sandi (_password_) dan kunci enkripsi, ke dalam Pod.
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+### Mengubah data rahasia kamu ke dalam representasi Base64
+
+Misalnya kamu mempunyai dua buah data rahasia: sebuah nama pengguna `my-app` dan kata sandi
+`39528$vdg7Jb`. Pertama, gunakan alat penyandian Base64 untuk mengubah nama pengguna kamu dan kata sandi ke dalam representasi Base64. Berikut ini contoh menggunakan program Base64 yang umum digunakan:
+
+```shell
+echo -n 'my-app' | base64
+echo -n '39528$vdg7Jb' | base64
+```
+
+Hasil keluaran menampilkan representasi Base64 dari nama pengguna kamu yaitu `bXktYXBw`,
+dan representasi Base64 dari kata sandi kamu yaitu `Mzk1MjgkdmRnN0pi`.
+
+{{< caution >}}
+Gunakan alat yang telah dipercayai oleh OS kamu untuk menghindari risiko dari penggunaan alat eksternal.
+{{< /caution >}}
+
+
+
+## Membuat Secret
+
+Berikut ini adalah berkas konfigurasi yang dapat kamu gunakan untuk membuat Secret yang akan menampung nama pengguna dan kata sandi kamu:
+
+{{< codenew file="pods/inject/secret.yaml" >}}
+
+1. Membuat Secret
+
+ ```shell
+ kubectl apply -f https://k8s.io/examples/pods/inject/secret.yaml
+ ```
+
+1. Melihat informasi dari Secret:
+
+ ```shell
+ kubectl get secret test-secret
+ ```
+
+ Hasil keluaran:
+
+ ```
+ NAME TYPE DATA AGE
+ test-secret Opaque 2 1m
+ ```
+
+1. Melihat informasi detil dari Secret:
+
+ ```shell
+ kubectl describe secret test-secret
+ ```
+
+ Hasil keluaran:
+
+ ```
+ Name: test-secret
+ Namespace: default
+ Labels:
+ Annotations:
+
+ Type: Opaque
+
+ Data
+ ====
+ password: 13 bytes
+ username: 7 bytes
+ ```
+
+### Membuat Secret langsung dengan kubectl
+
+Jika kamu ingin melompati langkah penyandian dengan Base64, kamu dapat langsung membuat Secret yang sama dengan menggunakan perintah `kubectl create secret`. Contohnya:
+
+```shell
+kubectl create secret generic test-secret --from-literal='username=my-app' --from-literal='password=39528$vdg7Jb'
+```
+
+Tentu saja ini lebih mudah. Pendekatan yang mendetil setiap langkah di atas bertujuan untuk mendemonstrasikan apa yang sebenarnya terjadi pada setiap langkah.
+
+
+## Membuat Pod yang memiliki akses ke data Secret melalui Volume
+
+Berikut ini adalah berkas konfigurasi yang dapat kamu gunakan untuk membuat Pod:
+
+{{< codenew file="pods/inject/secret-pod.yaml" >}}
+
+1. Membuat Pod:
+
+ ```shell
+ kubectl apply -f https://k8s.io/examples/pods/inject/secret-pod.yaml
+ ```
+
+1. Verifikasikan apakah Pod kamu sudah berjalan:
+
+ ```shell
+ kubectl get pod secret-test-pod
+ ```
+
+ Hasil keluaran:
+ ```
+ NAME READY STATUS RESTARTS AGE
+ secret-test-pod 1/1 Running 0 42m
+ ```
+
+1. Gunakan _shell_ untuk masuk ke dalam Container yang berjalan di dalam Pod kamu:
+ ```shell
+ kubectl exec -i -t secret-test-pod -- /bin/bash
+ ```
+
+1. Data Secret terekspos ke Container melalui Volume yang dipasang (_mount_) pada
+`/etc/secret-volume`.
+
+ Di dalam _shell_ kamu, tampilkan berkas yang ada di dalam direktori `/etc/secret-volume`:
+ ```shell
+ # Jalankan ini di dalam shell dalam Container
+ ls /etc/secret-volume
+ ```
+ Hasil keluaran menampilkan dua buah berkas, masing-masing untuk setiap data Secret:
+ ```
+ password username
+ ```
+
+1. Di dalam _shell_ kamu, tampilkan konten dari berkas `username` dan `password`:
+ ```shell
+ # Jalankan ini di dalam shell dalam Container
+ echo "$( cat /etc/secret-volume/username )"
+ echo "$( cat /etc/secret-volume/password )"
+ ```
+ Hasil keluarannya adalah nama pengguna dan kata sandi kamu:
+ ```
+ my-app
+ 39528$vdg7Jb
+ ```
+
+## Mendefinisikan variabel lingkungan Container menggunakan data Secret
+
+### Mendefinisikan variabel lingkungan Container menggunakan data dari Secret tunggal
+
+* Definisikan variabel lingkungan sebagai pasangan _key-value_ pada Secret:
+
+ ```shell
+ kubectl create secret generic backend-user --from-literal=backend-username='backend-admin'
+ ```
+
+* Tentukan nilai `backend-username` yang didefinisikan di Secret ke variabel lingkungan `SECRET_USERNAME` di dalam spesifikasi Pod.
+
+ {{< codenew file="pods/inject/pod-single-secret-env-variable.yaml" >}}
+
+* Membuat Pod:
+
+ ```shell
+ kubectl create -f https://k8s.io/examples/pods/inject/pod-single-secret-env-variable.yaml
+ ```
+
+* Di dalam _shell_ kamu, tampilkan konten dari variabel lingkungan `SECRET_USERNAME` dari Container
+
+ ```shell
+ kubectl exec -i -t env-single-secret -- /bin/sh -c 'echo $SECRET_USERNAME'
+ ```
+
+ Hasil keluarannya
+ ```
+ backend-admin
+ ```
+
+### Mendefinisikan variabel lingkungan Container dengan data dari multipel Secret
+
+* Seperti contoh sebelumnya, buat Secret terlebih dahulu.
+
+ ```shell
+ kubectl create secret generic backend-user --from-literal=backend-username='backend-admin'
+ kubectl create secret generic db-user --from-literal=db-username='db-admin'
+ ```
+
+* Definisikan variabel lingkungan di dalam spesifikasi Pod.
+
+ {{< codenew file="pods/inject/pod-multiple-secret-env-variable.yaml" >}}
+
+* Membuat Pod:
+
+ ```shell
+ kubectl create -f https://k8s.io/examples/pods/inject/pod-multiple-secret-env-variable.yaml
+ ```
+
+* Di dalam _shell_ kamu, tampilkan konten dari variabel lingkungan Container
+
+ ```shell
+ kubectl exec -i -t envvars-multiple-secrets -- /bin/sh -c 'env | grep _USERNAME'
+ ```
+ Hasil keluarannya
+ ```
+ DB_USERNAME=db-admin
+ BACKEND_USERNAME=backend-admin
+ ```
+
+
+## Mengonfigurasi semua pasangan _key-value_ di dalam Secret sebagai variabel lingkungan Container
+
+{{< note >}}
+Fitur ini tersedia mulai dari Kubernetes v1.6 dan yang lebih baru.
+{{< /note >}}
+
+* Membuat Secret yang berisi banyak pasangan _key-value_
+
+ ```shell
+ kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb'
+ ```
+
+* Gunakan envFrom untuk mendefinisikan semua data Secret sebagai variabel lingkungan Container. _Key_ dari Secret akan mennjadi nama variabel lingkungan di dalam Pod.
+
+ {{< codenew file="pods/inject/pod-secret-envFrom.yaml" >}}
+
+* Membuat Pod:
+
+ ```shell
+ kubectl create -f https://k8s.io/examples/pods/inject/pod-secret-envFrom.yaml
+ ```
+
+* Di dalam _shell_ kamu, tampilkan variabel lingkungan Container `username` dan `password`
+
+ ```shell
+ kubectl exec -i -t envfrom-secret -- /bin/sh -c 'echo "username: $username\npassword: $password\n"'
+ ```
+
+ Hasil keluarannya
+ ```
+ username: my-app
+ password: 39528$vdg7Jb
+ ```
+
+### Referensi
+
+* [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
+* [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)
+* [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
+
+## {{% heading "whatsnext" %}}
+
+* Pelajari lebih lanjut [Secret](/id/docs/concepts/configuration/secret/).
+* Pelajari lebih lanjut [Volume](/id/docs/concepts/storage/volumes/).
diff --git a/content/id/docs/tutorials/_index.md b/content/id/docs/tutorials/_index.md
index f56702b94e..d2c8c3e8b4 100644
--- a/content/id/docs/tutorials/_index.md
+++ b/content/id/docs/tutorials/_index.md
@@ -46,16 +46,6 @@ Sebelum melangkah lebih lanjut ke tutorial, sebaiknya tandai dulu halaman [Kamus
* [Menjalankan ZooKeeper, sebuah sistem terdistribusi yang berbasis CP](/docs/tutorials/stateful-application/zookeeper/)
-## Pipeline CI/CD
-
-* [Menyiapkan Pipeline CI/CD dengan Kubernetes Bagian 1: Ringkasan](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/5/set-cicd-pipeline-kubernetes-part-1-overview)
-
-* [Menyiapkan Pipeline CI/CD dengan Jenkins Pod di Kubernetes (Part 2)](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/6/set-cicd-pipeline-jenkins-pod-kubernetes-part-2)
-
-* [Menjalankan dan Mereplikasi Aplikasi Teka-Teki Terdistribusi dengan CI/CD pada Kubernetes (Bagian 3)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/run-and-scale-distributed-crossword-puzzle-app-cicd-kubernetes-part-3)
-
-* [Menyiapkan CI/CD untuk Aplikasi Teka-Teki Terdistribusi pada Kubernetes (Bagian 4)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/set-cicd-distributed-crossword-puzzle-app-kubernetes-part-4)
-
## Klaster
* [AppArmor](/docs/tutorials/clusters/apparmor/)
diff --git a/content/id/examples/admin/dns/dnsutils.yaml b/content/id/examples/admin/dns/dnsutils.yaml
new file mode 100644
index 0000000000..9192bf3502
--- /dev/null
+++ b/content/id/examples/admin/dns/dnsutils.yaml
@@ -0,0 +1,14 @@
+apiVersion: v1
+kind: Pod
+metadata:
+ name: dnsutils
+ namespace: default
+spec:
+ containers:
+ - name: dnsutils
+ image: gcr.io/kubernetes-e2e-test-images/dnsutils:1.3
+ command:
+ - sleep
+ - "3600"
+ imagePullPolicy: IfNotPresent
+ restartPolicy: Always
diff --git a/content/id/examples/pods/inject/pod-multiple-secret-env-variable.yaml b/content/id/examples/pods/inject/pod-multiple-secret-env-variable.yaml
new file mode 100644
index 0000000000..f285e41932
--- /dev/null
+++ b/content/id/examples/pods/inject/pod-multiple-secret-env-variable.yaml
@@ -0,0 +1,19 @@
+apiVersion: v1
+kind: Pod
+metadata:
+ name: envvars-multiple-secrets
+spec:
+ containers:
+ - name: envars-test-container
+ image: nginx
+ env:
+ - name: BACKEND_USERNAME
+ valueFrom:
+ secretKeyRef:
+ name: backend-user
+ key: backend-username
+ - name: DB_USERNAME
+ valueFrom:
+ secretKeyRef:
+ name: db-user
+ key: db-username
diff --git a/content/id/examples/pods/inject/pod-secret-envFrom.yaml b/content/id/examples/pods/inject/pod-secret-envFrom.yaml
new file mode 100644
index 0000000000..eb1d3213ef
--- /dev/null
+++ b/content/id/examples/pods/inject/pod-secret-envFrom.yaml
@@ -0,0 +1,11 @@
+apiVersion: v1
+kind: Pod
+metadata:
+ name: envfrom-secret
+spec:
+ containers:
+ - name: envars-test-container
+ image: nginx
+ envFrom:
+ - secretRef:
+ name: test-secret
diff --git a/content/id/examples/pods/inject/pod-single-secret-env-variable.yaml b/content/id/examples/pods/inject/pod-single-secret-env-variable.yaml
new file mode 100644
index 0000000000..af4cf8732f
--- /dev/null
+++ b/content/id/examples/pods/inject/pod-single-secret-env-variable.yaml
@@ -0,0 +1,14 @@
+apiVersion: v1
+kind: Pod
+metadata:
+ name: env-single-secret
+spec:
+ containers:
+ - name: envars-test-container
+ image: nginx
+ env:
+ - name: SECRET_USERNAME
+ valueFrom:
+ secretKeyRef:
+ name: backend-user
+ key: backend-username
diff --git a/content/id/examples/pods/inject/secret-pod.yaml b/content/id/examples/pods/inject/secret-pod.yaml
new file mode 100644
index 0000000000..1c6aca3b3f
--- /dev/null
+++ b/content/id/examples/pods/inject/secret-pod.yaml
@@ -0,0 +1,17 @@
+apiVersion: v1
+kind: Pod
+metadata:
+ name: secret-test-pod
+spec:
+ containers:
+ - name: test-container
+ image: nginx
+ volumeMounts:
+ # nama harus sesuai dengan nama Volume di bawah ini
+ - name: secret-volume
+ mountPath: /etc/secret-volume
+ # Data Secret diekspos ke Container di dalam Pod melalui Volume
+ volumes:
+ - name: secret-volume
+ secret:
+ secretName: test-secret
diff --git a/content/id/examples/pods/inject/secret.yaml b/content/id/examples/pods/inject/secret.yaml
new file mode 100644
index 0000000000..706ca8670f
--- /dev/null
+++ b/content/id/examples/pods/inject/secret.yaml
@@ -0,0 +1,7 @@
+apiVersion: v1
+kind: Secret
+metadata:
+ name: test-secret
+data:
+ username: bXktYXBw
+ password: Mzk1MjgkdmRnN0pi
diff --git a/content/it/docs/tutorials/_index.md b/content/it/docs/tutorials/_index.md
index 88ffbe41e5..04069ff5eb 100644
--- a/content/it/docs/tutorials/_index.md
+++ b/content/it/docs/tutorials/_index.md
@@ -46,16 +46,6 @@ Prima di procedere con vari tutorial, raccomandiamo di aggiungere il
* [Eseguire ZooKeeper, un sistema distribuito CP](/docs/tutorials/stateful-application/zookeeper/)
-## CI/CD Pipelines
-
-* [Set Up a CI/CD Pipeline with Kubernetes Part 1: Overview](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/5/set-cicd-pipeline-kubernetes-part-1-overview)
-
-* [Set Up a CI/CD Pipeline with a Jenkins Pod in Kubernetes (Part 2)](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/6/set-cicd-pipeline-jenkins-pod-kubernetes-part-2)
-
-* [Run and Scale a Distributed Crossword Puzzle App with CI/CD on Kubernetes (Part 3)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/run-and-scale-distributed-crossword-puzzle-app-cicd-kubernetes-part-3)
-
-* [Set Up CI/CD for a Distributed Crossword Puzzle App on Kubernetes (Part 4)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/set-cicd-distributed-crossword-puzzle-app-kubernetes-part-4)
-
## Clusters
* [AppArmor](/docs/tutorials/clusters/apparmor/)
diff --git a/content/ja/case-studies/appdirect/index.html b/content/ja/case-studies/appdirect/index.html
index 276a174752..e2b8948bf6 100644
--- a/content/ja/case-studies/appdirect/index.html
+++ b/content/ja/case-studies/appdirect/index.html
@@ -9,7 +9,7 @@ logo: appdirect_featured_logo.png
featured: true
weight: 4
quote: >
- 私たちはたくさんの人からの関心を得るためにさまざまな戦略を試みています。Kubernetesとクラウドネイティブ技術は、いまやデファクトのエコシステムとみなされています。
+ 私たちはたくさんの人からの関心を得るためにさまざまな戦略を試みています。Kubernetesとクラウドネイティブ技術は、いまやデファクトのエコシステムとみなされています。
---
エンジニアリングのレベルが上がり続けるにつれて、プラットフォームチームは新たな課題を抱えることになります。Kubernetesプラットフォームが誰からでもアクセス可能で簡単に利用できる、それを確実にしていくことが求められるのです。「チームにより多くの人を追加したとき、彼らが効率的で生産的であり、プラットフォームの強化の仕方を知っていることを確実にするにはどうすればいいでしょうか？」とLacerteは問います。そのために、私たちにはエバンジェリストがいて、ドキュメントを用意して、いくつかのプロジェクトの事例を紹介できるようにしているのです。なので実際にデモをして、AMA(Ask Me Anything: 何でも聞いてほしい)セッションを設けるのです。私たちはたくさんの人からの関心を得るためにさまざまな戦略を試みています。」
エンジニアリングのレベルが上がり続けるにつれて、プラットフォームチームは新たな課題を抱えることになります。Kubernetesプラットフォームが誰からでもアクセス可能で簡単に利用できる、それを確実にしていくことが求められるのです。「チームにより多くの人を追加したとき、彼らが効率的で生産的であり、プラットフォームの強化の仕方を知っていることを確実にするにはどうすればいいでしょうか？」とLacerteは問います。そのために、私たちにはエバンジェリストがいて、ドキュメントを用意して、いくつかのプロジェクトの事例を紹介できるようにしているのです。なので実際にデモをして、AMA(Ask Me Anything: 何でも聞いてほしい)セッションを設けるのです。私たちはたくさんの人からの関心を得るためにさまざまな戦略を試みています。」
私たちはissueとpull requestを作り、SIGミーティング、Kubernetesミートアップ、Kubeconに参加する人々です。そして、Kubernetesの採用とイノベーションを提唱し、kubectl get podsを実行し、数多くの重要な方法でコントリビュートする人々です。このページを読み進めて、この素晴らしいコミュニティに参加してコミュニティの一員になる方法について知ってください。
diff --git a/content/ko/docs/concepts/architecture/control-plane-node-communication.md b/content/ko/docs/concepts/architecture/control-plane-node-communication.md
index 62fd283b2f..7d5e86837e 100644
--- a/content/ko/docs/concepts/architecture/control-plane-node-communication.md
+++ b/content/ko/docs/concepts/architecture/control-plane-node-communication.md
@@ -43,7 +43,7 @@ API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다.
이 연결을 확인하려면, `--kubelet-certificate-authority` 플래그를 사용하여 API 서버에 kubelet의 서빙 인증서를 확인하는 데 사용할 루트 인증서 번들을 제공한다.
-이것이 가능하지 않은 경우, 신뢰할 수 없는 네트워크 또는 공용 네트워크를 통한 연결을 피하기 위해 필요한 경우 API 서버와 kubelet 사이에 [SSH 터널링](/ko/docs/concepts/architecture/control-plane-node-communication/#ssh-터널)을
+이것이 가능하지 않은 경우, 신뢰할 수 없는 네트워크 또는 공용 네트워크를 통한 연결을 피하기 위해 필요한 경우 API 서버와 kubelet 사이에 [SSH 터널링](#ssh-터널)을
사용한다.
마지막으로, kubelet API를 보호하려면 [Kubelet 인증 및/또는 권한 부여](/docs/admin/kubelet-authentication-authorization/)를 활성화해야 한다.
diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md
index 7fb92302f9..eab7eb0de2 100644
--- a/content/ko/docs/concepts/architecture/nodes.md
+++ b/content/ko/docs/concepts/architecture/nodes.md
@@ -20,8 +20,6 @@ weight: 10
{{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}
그리고 {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}가 포함된다.
-
-
## 관리
@@ -336,5 +334,5 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
* [노드에 대한 API 정의](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)를 읽어본다.
* 아키텍처 디자인 문서의 [노드](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
섹션을 읽어본다.
-* [테인트와 톨러레이션](/ko/docs/concepts/configuration/taint-and-toleration/)을 읽어본다.
+* [테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 읽어본다.
* [클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)을 읽어본다.
diff --git a/content/ko/docs/concepts/cluster-administration/_index.md b/content/ko/docs/concepts/cluster-administration/_index.md
index c21e17e3ec..cde1b093b5 100755
--- a/content/ko/docs/concepts/cluster-administration/_index.md
+++ b/content/ko/docs/concepts/cluster-administration/_index.md
@@ -55,14 +55,14 @@ no_list: true
* [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)는 인증과 권한 부여 후 쿠버네티스 API 서버에 대한 요청을 가로채는 플러그인에 대해 설명한다.
-* [쿠버네티스 클러스터에서 Sysctls 사용하기](/docs/concepts/cluster-administration/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다.
+* [쿠버네티스 클러스터에서 Sysctls 사용하기](/docs/tasks/administer-cluster/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다.
* [감사(audit)](/docs/tasks/debug-application-cluster/audit/)는 쿠버네티스의 감사 로그를 다루는 방법에 대해 설명한다.
### kubelet 보안
- * [마스터-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/)
+ * [컨트롤 플레인-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/)
* [TLS 부트스트래핑(bootstrapping)](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
- * [Kubelet 인증/인가](/docs/admin/kubelet-authentication-authorization/)
+ * [Kubelet 인증/인가](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)
## 선택적 클러스터 서비스
diff --git a/content/ko/docs/concepts/cluster-administration/addons.md b/content/ko/docs/concepts/cluster-administration/addons.md
index 1838688d38..067ebab037 100644
--- a/content/ko/docs/concepts/cluster-administration/addons.md
+++ b/content/ko/docs/concepts/cluster-administration/addons.md
@@ -5,35 +5,30 @@ content_type: concept
-
애드온은 쿠버네티스의 기능을 확장한다.
이 페이지는 사용 가능한 일부 애드온과 관련 설치 지침 링크를 나열한다.
각 섹션의 애드온은 알파벳 순으로 정렬되어 있다. 순서는 우선 순위와는 상관없다.
-
-
-
## 네트워킹과 네트워크 폴리시
-
* [ACI](https://www.github.com/noironetworks/aci-containers)는 Cisco ACI로 통합 컨테이너 네트워킹 및 네트워크 보안을 제공한다.
* [Calico](https://docs.projectcalico.org/latest/introduction/)는 네트워킹 및 네트워크 폴리시 제공자이다. Calico는 유연한 네트워킹 옵션을 지원하므로 BGP 유무에 관계없이 비-오버레이 및 오버레이 네트워크를 포함하여 가장 상황에 맞는 옵션을 선택할 수 있다. Calico는 동일한 엔진을 사용하여 서비스 메시 계층(service mesh layer)에서 호스트, 파드 및 (이스티오(istio)와 Envoy를 사용하는 경우) 애플리케이션에 대한 네트워크 폴리시를 적용한다.
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install)은 Flannel과 Calico를 통합하여 네트워킹 및 네트워크 폴리시를 제공한다.
* [Cilium](https://github.com/cilium/cilium)은 L3 네트워크 및 네트워크 폴리시 플러그인으로 HTTP/API/L7 폴리시를 투명하게 시행할 수 있다. 라우팅 및 오버레이/캡슐화 모드를 모두 지원하며, 다른 CNI 플러그인 위에서 작동할 수 있다.
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)를 사용하면 쿠버네티스는 Calico, Canal, Flannel, Romana 또는 Weave와 같은 CNI 플러그인을 완벽하게 연결할 수 있다.
-* [Contiv](http://contiv.github.io)는 다양한 유스케이스와 풍부한 폴리시 프레임워크를 위해 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 그리고 Cisco-SDN/ACI)을 제공한다. Contiv 프로젝트는 완전히 [오픈소스](http://github.com/contiv)이다. [인스톨러](http://github.com/contiv/install)는 kubeadm을 이용하거나, 그렇지 않은 경우에 대해서도 설치 옵션을 모두 제공한다.
-* [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 [Tungsten Fabric](https://tungsten.io)을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다.
+* [Contiv](https://contiv.github.io)는 다양한 유스케이스와 풍부한 폴리시 프레임워크를 위해 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 그리고 Cisco-SDN/ACI)을 제공한다. Contiv 프로젝트는 완전히 [오픈소스](https://github.com/contiv)이다. [인스톨러](https://github.com/contiv/install)는 kubeadm을 이용하거나, 그렇지 않은 경우에 대해서도 설치 옵션을 모두 제공한다.
+* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 [Tungsten Fabric](https://tungsten.io)을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다.
* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다.
* [Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스 파드에서 여러 네트워크 인터페이스를 지원하는 플러그인이다.
* [Multus](https://github.com/Intel-Corp/multus-cni)는 쿠버네티스에서 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드 외에 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)을 지원하기 위해 쿠버네티스에서 다중 네트워크 지원을 위한 멀티 플러그인이다.
* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)은 OVN 기반의 CNI 컨트롤러 플러그인으로 클라우드 네이티브 기반 서비스 기능 체인(Service function chaining(SFC)), 다중 OVN 오버레이 네트워킹, 동적 서브넷 생성, 동적 가상 네트워크 생성, VLAN 공급자 네트워크, 직접 공급자 네트워크와 멀티 클러스터 네트워킹의 엣지 기반 클라우드 등 네이티브 워크로드에 이상적인 멀티 네티워크 플러그인이다.
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다.
-* [Romana](http://romana.io)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다.
+* [Romana](https://romana.io)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다.
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다.
## 서비스 검색
diff --git a/content/ko/docs/concepts/cluster-administration/cloud-providers.md b/content/ko/docs/concepts/cluster-administration/cloud-providers.md
index 3d5ba7e9d0..9c1c556808 100644
--- a/content/ko/docs/concepts/cluster-administration/cloud-providers.md
+++ b/content/ko/docs/concepts/cluster-administration/cloud-providers.md
@@ -8,8 +8,6 @@ weight: 30
이 페이지에서는 특정 클라우드 제공자에서 실행 중인 쿠버네티스를 관리하는 방법에
대해 설명한다.
-
-
### kubeadm
[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)은 쿠버네티스 클러스터를 생성하는 데 많이 사용하는 옵션이다.
@@ -45,8 +43,10 @@ controllerManager:
mountPath: "/etc/kubernetes/cloud.conf"
```
-인-트리 클라우드 제공자는 일반적으로 [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/)
-및 [kubelet](/docs/admin/kubelet/)의 커맨드 라인에 지정된 `--cloud-provider` 와 `--cloud-config` 가 모두 필요하다.
+인-트리 클라우드 제공자는 일반적으로
+[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/),
+[kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
+및 [kubelet](/docs/reference/command-line-tools-reference/kubelet/)의 커맨드 라인에 지정된 `--cloud-provider` 와 `--cloud-config` 가 모두 필요하다.
각 제공자에 대해 `--cloud-config` 에 지정된 파일의 내용도 아래에 설명되어 있다.
모든 외부 클라우드 제공자의 경우, 아래 제공자에 대한 제목 아래에 있는 개별 리포지터리의 지침을 따르거나,
@@ -358,12 +358,9 @@ OpenStack 제공자에 대한 다음의 구성 옵션은 [kubenet]
`extraroutes` 확장을 지원하는 경우 경로를 추가할 라우터를 지정하는 데 `router-id`
를 사용한다. 선택한 라우터는 클러스터 노드를 포함하는 프라이빗 네트워크에
걸쳐 있어야 한다(일반적으로 하나의 노드 네트워크만 있으며, 이 값은
- 노드 네트워크의 기본 라우터여야 한다). 이 값은 OpenStack에서 [kubenet]을 사용하는 데
- 필요하다.
-
-[kubenet]: /ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet
-
-
+ 노드 네트워크의 기본 라우터여야 한다). 이 값은 OpenStack에서
+ [kubenet](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet)을
+ 사용하는 데 필요하다.
## OVirt
diff --git a/content/ko/docs/concepts/cluster-administration/logging.md b/content/ko/docs/concepts/cluster-administration/logging.md
index 4f516ed41e..4896a8e7b8 100644
--- a/content/ko/docs/concepts/cluster-administration/logging.md
+++ b/content/ko/docs/concepts/cluster-administration/logging.md
@@ -10,9 +10,6 @@ weight: 60
그러나, 일반적으로 컨테이너 엔진이나 런타임에서 제공하는 기본 기능은 완전한 로깅 솔루션으로 충분하지 않다. 예를 들어, 컨테이너가 크래시되거나, 파드가 축출되거나, 노드가 종료된 경우에도 여전히 애플리케이션의 로그에 접근하려고 한다. 따라서, 로그는 노드, 파드 또는 컨테이너와는 독립적으로 별도의 스토리지와 라이프사이클을 가져야 한다. 이 개념을 _클러스터-레벨-로깅_ 이라고 한다. 클러스터-레벨 로깅은 로그를 저장하고, 분석하고, 쿼리하기 위해 별도의 백엔드가 필요하다. 쿠버네티스는 로그 데이터를 위한 네이티브 스토리지 솔루션을 제공하지 않지만, 기존의 많은 로깅 솔루션을 쿠버네티스 클러스터에 통합할 수 있다.
-
-
-
클러스터-레벨 로깅 아키텍처는 로깅 백엔드가
@@ -132,7 +129,7 @@ systemd를 사용하지 않으면, `/var/log` 디렉터리의 `.log` 파일에
쿠버네티스 클러스터는 노드-레벨 로깅 에이전트를 사용하는 것이 가장 일반적이며 권장되는 방법으로, 이는 노드별 하나의 에이전트만 생성하며, 노드에서 실행되는 애플리케이션을 변경할 필요가 없기 때문이다. 그러나, 노드-레벨 로깅은 _애플리케이션의 표준 출력과 표준 에러에 대해서만 작동한다_ .
-쿠버네티스는 로깅 에이전트를 지정하지 않지만, 쿠버네티스 릴리스에는 두 가지 선택적인 로깅 에이전트(Google 클라우드 플랫폼과 함께 사용하기 위한 [스택드라이버(Stackdriver) 로깅](/docs/user-guide/logging/stackdriver)과 [엘라스틱서치(Elasticsearch)](/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/))가 패키지로 함께 제공된다. 전용 문서에서 자세한 정보와 지침을 찾을 수 있다. 두 가지 다 사용자 정의 구성이 된 [fluentd](http://www.fluentd.org/)를 에이전트로써 노드에서 사용한다.
+쿠버네티스는 로깅 에이전트를 지정하지 않지만, 쿠버네티스 릴리스에는 두 가지 선택적인 로깅 에이전트(Google 클라우드 플랫폼과 함께 사용하기 위한 [스택드라이버(Stackdriver) 로깅](/docs/tasks/debug-application-cluster/logging-stackdriver/)과 [엘라스틱서치(Elasticsearch)](/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/))가 패키지로 함께 제공된다. 전용 문서에서 자세한 정보와 지침을 찾을 수 있다. 두 가지 다 사용자 정의 구성이 된 [fluentd](http://www.fluentd.org/)를 에이전트로써 노드에서 사용한다.
### 로깅 에이전트와 함께 사이드카 컨테이너 사용
@@ -239,7 +236,7 @@ fluentd를 구성하기 위한 [컨피그맵](/docs/tasks/configure-pod-containe
{{< note >}}
fluentd의 구성은 이 문서의 범위를 벗어난다.
fluentd를 구성하는 것에 대한 자세한 내용은,
-[공식 fluentd 문서](http://docs.fluentd.org/)를 참고한다.
+[공식 fluentd 문서](https://docs.fluentd.org/)를 참고한다.
{{< /note >}}
두 번째 파일은 fluentd가 실행되는 사이드카 컨테이너가 있는 파드를 설명한다.
diff --git a/content/ko/docs/concepts/cluster-administration/manage-deployment.md b/content/ko/docs/concepts/cluster-administration/manage-deployment.md
index c2835e78cb..be5befdbd3 100644
--- a/content/ko/docs/concepts/cluster-administration/manage-deployment.md
+++ b/content/ko/docs/concepts/cluster-administration/manage-deployment.md
@@ -8,9 +8,6 @@ weight: 40
애플리케이션을 배포하고 서비스를 통해 노출했다. 이제 무엇을 해야 할까? 쿠버네티스는 확장과 업데이트를 포함하여, 애플리케이션 배포를 관리하는 데 도움이 되는 여러 도구를 제공한다. 더 자세히 설명할 기능 중에는 [구성 파일](/ko/docs/concepts/configuration/overview/)과 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)이 있다.
-
-
-
## 리소스 구성 구성하기
@@ -321,7 +318,7 @@ metadata:
kubectl scale deployment/my-nginx --replicas=1
```
```shell
-deployment.extensions/my-nginx scaled
+deployment.apps/my-nginx scaled
```
이제 디플로이먼트가 관리하는 파드가 하나만 있다.
@@ -354,7 +351,8 @@ horizontalpodautoscaler.autoscaling/my-nginx autoscaled
### kubectl apply
-구성 파일 셋을 소스 제어에서 유지하는 것이 좋으며([코드로서의 구성](http://martinfowler.com/bliki/InfrastructureAsCode.html) 참조),
+구성 파일 셋을 소스 제어에서 유지하는 것이 좋으며
+([코드로서의 구성](https://martinfowler.com/bliki/InfrastructureAsCode.html) 참조),
그렇게 하면 구성하는 리소스에 대한 코드와 함께 버전을 지정하고 유지할 수 있다.
그런 다음, [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply)를 사용하여 구성 변경 사항을 클러스터로 푸시할 수 있다.
diff --git a/content/ko/docs/concepts/cluster-administration/networking.md b/content/ko/docs/concepts/cluster-administration/networking.md
index 28508d58f2..e5c492491a 100644
--- a/content/ko/docs/concepts/cluster-administration/networking.md
+++ b/content/ko/docs/concepts/cluster-administration/networking.md
@@ -10,14 +10,11 @@ weight: 50
문제가 있다.
1. 고도로 결합된 컨테이너 간의 통신: 이 문제는
- [파드](/ko/docs/concepts/workloads/pods/pod/)와 `localhost` 통신으로 해결된다.
+ {{< glossary_tooltip text="파드" term_id="pod" >}}와 `localhost` 통신으로 해결된다.
2. 파드 간 통신: 이 문제가 이 문서의 주요 초점이다.
3. 파드와 서비스 간 통신: 이 문제는 [서비스](/ko/docs/concepts/services-networking/service/)에서 다룬다.
4. 외부와 서비스 간 통신: 이 문제는 [서비스](/ko/docs/concepts/services-networking/service/)에서 다룬다.
-
-
-
쿠버네티스는 애플리케이션 간에 머신을 공유하는 것이다. 일반적으로,
@@ -91,7 +88,7 @@ Antrea는 Open vSwitch의 "프로그래밍이 가능한" 특성으로 인해 Ope
### Apstra의 AOS
-[AOS](http://www.apstra.com/products/aos/)는 단순한 통합 플랫폼에서 복잡한 데이터센터 환경을 만들고 관리하는 의도기반(Intent-Based) 네트워킹 시스템이다. AOS는 확장성이 뛰어난 분산 설계를 활용하여 네트워크 중단을 제거하면서 비용을 최소화한다.
+[AOS](https://www.apstra.com/products/aos/)는 단순한 통합 플랫폼에서 복잡한 데이터센터 환경을 만들고 관리하는 의도기반(Intent-Based) 네트워킹 시스템이다. AOS는 확장성이 뛰어난 분산 설계를 활용하여 네트워크 중단을 제거하면서 비용을 최소화한다.
AOS 레퍼런스 디자인은 현재 레거시 Layer-2 스위칭 문제를 제거하는 Layer-3 연결 호스트를 지원한다. 이 Layer-3 호스트는 리눅스 서버(Debian, Ubuntu, CentOS)일 수 있으며 랙 상단 스위치(TOR)와 직접 BGP 인접 관계를 만든다. AOS는 라우팅 인접성을 자동화한 다음 쿠버네티스 디플로이먼트에서 일반적으로 사용되는 RHI(Route Health Injection)에 대한 세밀한 제어를 제공한다.
@@ -99,7 +96,7 @@ AOS는 쿠버네티스가 애플리케이션 요구 사항에 따라 네트워
AOS는 Cisco, Arista, Dell, Mellanox, HPE 그리고 Microsoft SONiC, Dell OPX 및 Cumulus Linux와 같은 개방형 네트워크 운영체제와 수많은 화이트-박스 시스템을 포함한 제조업체의 일반적인 벤더 장비 사용을 지원한다.
-AOS 시스템 작동 방식에 대한 자세한 내용은 다음을 참고한다. http://www.apstra.com/products/how-it-works/
+AOS 시스템 작동 방식에 대한 자세한 내용은 다음을 참고한다. https://www.apstra.com/products/how-it-works/
### 쿠버네티스용 AWS VPC CNI
@@ -121,7 +118,7 @@ Azure CNI는 [Azure 쿠버네티스 서비스(Azure Kubernetes Service, AKS)](ht
빅 클라우드 패브릭의 가상 파드 멀티 테넌트 아키텍처를 통해 쿠버네티스, RedHat OpenShift, Mesosphere DC/OS 및 Docker Swarm과 같은 컨테이너 오케스트레이션 시스템은 VMware, OpenStack 및 Nutanix와 같은 VM 오케스트레이션 시스템과 함께 네이티브로 통합된다. 고객은 원하는 수의 클러스터를 안전하게 상호 연결할 수 있으며 필요한 경우 이들 사이의 테넌트 간 통신을 활성화할 수 있다.
-가트너는 최신의 [매직 쿼드런트(Magic Quadrant)](http://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html)에서 BCF를 비저너리(Visionary)로 인정했다. BCF 쿠버네티스 온-프레미스 디플로이먼트 중 하나(지리적으로 다른 리전에 걸쳐 여러 DC에서 실행되는 쿠버네티스, DC/OS 및 VMware 포함)도 [여기](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/)에서 사례로 참조된다.
+가트너는 최신의 [매직 쿼드런트(Magic Quadrant)](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html)에서 BCF를 비저너리(Visionary)로 인정했다. BCF 쿠버네티스 온-프레미스 디플로이먼트 중 하나(지리적으로 다른 리전에 걸쳐 여러 DC에서 실행되는 쿠버네티스, DC/OS 및 VMware 포함)도 [여기](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/)에서 사례로 참조된다.
### 실리움(Cilium)
@@ -133,7 +130,7 @@ Azure CNI는 [Azure 쿠버네티스 서비스(Azure Kubernetes Service, AKS)](ht
### 화웨이의 CNI-Genie
-[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)는 쿠버네티스가 런타임 시 [쿠버네티스 네트워크 모델](https://github.com/kubernetes/website/blob/master/content/en/docs/concepts/cluster-administration/networking.md#the-kubernetes-network-model)의 [서로 다른 구현에 동시에 접근](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables)할 수 있는 CNI 플러그인이다. 여기에는 [플라넬(Flannel)](https://github.com/coreos/flannel#flannel), [캘리코](http://docs.projectcalico.org/), [로마나(Romana)](http://romana.io), [위브넷(Weave-net)](https://www.weave.works/products/weave-net/)과 같은 [CNI 플러그인](https://github.com/containernetworking/cni#3rd-party-plugins)으로 실행되는 모든 구현이 포함된다.
+[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)는 쿠버네티스가 런타임 시 [쿠버네티스 네트워크 모델](https://github.com/kubernetes/website/blob/master/content/en/docs/concepts/cluster-administration/networking.md#the-kubernetes-network-model)의 [서로 다른 구현에 동시에 접근](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables)할 수 있는 CNI 플러그인이다. 여기에는 [플라넬(Flannel)](https://github.com/coreos/flannel#flannel), [캘리코](https://docs.projectcalico.org/), [로마나(Romana)](https://romana.io), [위브넷(Weave-net)](https://www.weave.works/products/weave-net/)과 같은 [CNI 플러그인](https://github.com/containernetworking/cni#3rd-party-plugins)으로 실행되는 모든 구현이 포함된다.
CNI-Genie는 각각 다른 CNI 플러그인에서 [하나의 파드에 여러 IP 주소를 할당](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod)하는 것도 지원한다.
@@ -155,11 +152,11 @@ VPC 라우팅 테이블을 조정하여 각 호스트에 인스턴스별 서브
### 콘티브(Contiv)
-[콘티브](https://github.com/contiv/netplugin)는 다양한 적용 사례에서 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 또는 Cisco-SDN/ACI)을 제공한다. [콘티브](http://contiv.io)는 모두 오픈소스이다.
+[콘티브](https://github.com/contiv/netplugin)는 다양한 적용 사례에서 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 또는 Cisco-SDN/ACI)을 제공한다. [콘티브](https://contiv.io)는 모두 오픈소스이다.
### 콘트레일(Contrail) / 텅스텐 패브릭(Tungsten Fabric)
-[텅스텐 패브릭](https://tungsten.io)을 기반으로 하는 [콘트레일](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 진정한 개방형 멀티 클라우드 네트워크 가상화 및 정책 관리 플랫폼이다. 콘트레일 및 텅스텐 패브릭은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 다양한 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어메탈 워크로드에 대해 서로 다른 격리 모드를 제공한다.
+[텅스텐 패브릭](https://tungsten.io)을 기반으로 하는 [콘트레일](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 진정한 개방형 멀티 클라우드 네트워크 가상화 및 정책 관리 플랫폼이다. 콘트레일 및 텅스텐 패브릭은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 다양한 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어메탈 워크로드에 대해 서로 다른 격리 모드를 제공한다.
### DANM
@@ -240,7 +237,7 @@ sysctl net.ipv4.ip_forward=1
### Kube-router
-[kube-router](https://github.com/cloudnativelabs/kube-router)는 쿠버네티스를 위한 특수 목적의 네트워킹 솔루션으로 고성능 및 운영 단순성을 제공한다. 큐브 라우터는 리눅스 [LVS/IPVS](http://www.linuxvirtualserver.org/software/ipvs.html) 기반 서비스 프록시, 오버레이가 없는 리눅스 커널 포워딩 기반의 파드 간 네트워킹 솔루션 그리고 iptables/ipset 기반 네트워크 정책 집행도구를 제공한다.
+[kube-router](https://github.com/cloudnativelabs/kube-router)는 쿠버네티스를 위한 특수 목적의 네트워킹 솔루션으로 고성능 및 운영 단순성을 제공한다. 큐브 라우터는 리눅스 [LVS/IPVS](https://www.linuxvirtualserver.org/software/ipvs.html) 기반 서비스 프록시, 오버레이가 없는 리눅스 커널 포워딩 기반의 파드 간 네트워킹 솔루션 그리고 iptables/ipset 기반 네트워크 정책 집행도구를 제공한다.
### L2 네트워크 및 리눅스 브릿지
@@ -250,8 +247,8 @@ sysctl net.ipv4.ip_forward=1
철저히 테스트되지 않았다. 이 기술을 사용하여
프로세스를 완료한 경우, 알려주길 바란다.
-Lars Kellogg-Stedman이 제공하는 [이 훌륭한
-튜토리얼](http://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/)의
+Lars Kellogg-Stedman이 제공하는
+[이 훌륭한 튜토리얼](https://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/)의
"With Linux Bridge devices" 섹션을 참고한다.
### Multus(멀티 네트워크 플러그인)
@@ -272,7 +269,7 @@ Multus는 CNI 명세를 구현하는 모든 [레퍼런스 플러그인](https://
### Nuage Networks VCS(가상 클라우드 서비스)
-[Nuage](http://www.nuagenetworks.net)는 확장성이 뛰어난 정책 기반의 소프트웨어 정의 네트워킹(SDN) 플랫폼을 제공한다. Nuage는 개방형 표준을 기반으로 구축된 풍부한 기능의 SDN 컨트롤러와 함께 데이터 플레인용 오픈소스 Open vSwitch를 사용한다.
+[Nuage](https://www.nuagenetworks.net)는 확장성이 뛰어난 정책 기반의 소프트웨어 정의 네트워킹(SDN) 플랫폼을 제공한다. Nuage는 개방형 표준을 기반으로 구축된 풍부한 기능의 SDN 컨트롤러와 함께 데이터 플레인용 오픈소스 Open vSwitch를 사용한다.
Nuage 플랫폼은 오버레이를 사용하여 쿠버네티스 파드와 쿠버네티스가 아닌 환경(VM 및 베어메탈 서버) 간에 완벽한 정책 기반의 네트워킹을 제공한다. Nuage의 정책 추상화 모델은 애플리케이션을 염두에 두고 설계되었으며 애플리케이션에 대한 세분화된 정책을 쉽게 선언할 수 있도록 한다. 플랫폼의 실시간 분석 엔진을 통해 쿠버네티스 애플리케이션에 대한 가시성과 보안 모니터링이 가능하다.
@@ -292,7 +289,7 @@ OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크
### 프로젝트 캘리코
-[프로젝트 캘리코](http://docs.projectcalico.org/)는 오픈소스 컨테이너 네트워킹 공급자 및 네트워크 정책 엔진이다.
+[프로젝트 캘리코](https://docs.projectcalico.org/)는 오픈소스 컨테이너 네트워킹 공급자 및 네트워크 정책 엔진이다.
캘리코는 리눅스(오픈소스)와 윈도우(독점 - [Tigera](https://www.tigera.io/essentials/)에서 사용 가능) 모두에서 인터넷과 동일한 IP 네트워킹 원칙을 기반으로 쿠버네티스 파드를 연결하기 위한 확장성이 뛰어난 네트워킹 및 네트워크 정책 솔루션을 제공한다. 캘리코는 캡슐화나 오버레이 없이 구축되어 고성능의 대규모 데이터센터 네트워킹을 제공할 수 있다. 또한 캘리코는 분산 방화벽을 통해 쿠버네티스 파드에 대해 세분화된 의도기반의 네트워크 보안 정책을 제공한다.
@@ -300,7 +297,7 @@ OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크
### 로마나
-[로마나](http://romana.io)는 오버레이 네트워크 없이 쿠버네티스를 배포할 수 있는 오픈소스 네트워크 및 보안 자동화 솔루션이다. 로마나는 쿠버네티스 [네트워크 폴리시](/ko/docs/concepts/services-networking/network-policies/)를 지원하여 네트워크 네임스페이스에서 격리를 제공한다.
+[로마나](https://romana.io)는 오버레이 네트워크 없이 쿠버네티스를 배포할 수 있는 오픈소스 네트워크 및 보안 자동화 솔루션이다. 로마나는 쿠버네티스 [네트워크 폴리시](/ko/docs/concepts/services-networking/network-policies/)를 지원하여 네트워크 네임스페이스에서 격리를 제공한다.
### Weaveworks의 위브넷
@@ -310,13 +307,9 @@ OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크
독립형으로 실행된다. 두 버전에서, 실행하기 위해 구성이나 추가 코드가 필요하지 않으며,
두 경우 모두, 쿠버네티스의 표준과 같이 네트워크에서 파드별로 하나의 IP 주소를 제공한다.
-
-
## {{% heading "whatsnext" %}}
-
네트워크 모델의 초기 설계와 그 근거 및 미래의 계획은
[네트워킹 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)에
자세히 설명되어 있다.
-
diff --git a/content/ko/docs/concepts/configuration/configmap.md b/content/ko/docs/concepts/configuration/configmap.md
index 3b339ca18f..8e025addd3 100644
--- a/content/ko/docs/concepts/configuration/configmap.md
+++ b/content/ko/docs/concepts/configuration/configmap.md
@@ -224,7 +224,7 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최
- 애플리케이션 중단을 일으킬 수 있는 우발적(또는 원하지 않는) 업데이트로부터 보호
- immutable로 표시된 컨피그맵에 대한 감시를 중단하여, kube-apiserver의 부하를 크게 줄임으로써 클러스터의 성능을 향상시킴
-이 기능을 사용하려면 `ImmutableEmphemeralVolumes`
+이 기능을 사용하려면 `ImmutableEphemeralVolumes`
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하고
시크릿 또는 컨피그맵의 `immutable` 필드를 `true` 로 한다. 다음은 예시이다.
```yaml
diff --git a/content/ko/docs/concepts/configuration/manage-resources-containers.md b/content/ko/docs/concepts/configuration/manage-resources-containers.md
index 42036c7da8..99e5c27298 100644
--- a/content/ko/docs/concepts/configuration/manage-resources-containers.md
+++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md
@@ -132,11 +132,9 @@ metadata:
name: frontend
spec:
containers:
- - name: db
- image: mysql
+ - name: app
+ image: images.my-company.example/app:v4
env:
- - name: MYSQL_ROOT_PASSWORD
- value: "password"
resources:
requests:
memory: "64Mi"
@@ -144,8 +142,8 @@ spec:
limits:
memory: "128Mi"
cpu: "500m"
- - name: wp
- image: wordpress
+ - name: log-aggregator
+ image: images.my-company.example/log-aggregator:v6
resources:
requests:
memory: "64Mi"
@@ -330,18 +328,15 @@ metadata:
name: frontend
spec:
containers:
- - name: db
- image: mysql
- env:
- - name: MYSQL_ROOT_PASSWORD
- value: "password"
+ - name: app
+ image: images.my-company.example/app:v4
resources:
requests:
ephemeral-storage: "2Gi"
limits:
ephemeral-storage: "4Gi"
- - name: wp
- image: wordpress
+ - name: log-aggregator
+ image: images.my-company.example/log-aggregator:v6
resources:
requests:
ephemeral-storage: "2Gi"
@@ -757,4 +752,4 @@ LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-0
* [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) API 레퍼런스 읽어보기
-* XFS의 [프로젝트 쿼터](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html)에 대해 읽어보기
+* XFS의 [프로젝트 쿼터](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html)에 대해 읽어보기
diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md
index 387a794a6b..eb7aa1ff93 100644
--- a/content/ko/docs/concepts/configuration/overview.md
+++ b/content/ko/docs/concepts/configuration/overview.md
@@ -71,7 +71,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
## 컨테이너 이미지
-[imagePullPolicy](/ko/docs/concepts/containers/images/#이미지-업데이트)와 이미지의 태그는 [kubelet](/docs/admin/kubelet/)이 명시된 이미지를 풀(pull) 하려고 시도할 때 영향을 미친다.
+[imagePullPolicy](/ko/docs/concepts/containers/images/#이미지-업데이트)와 이미지의 태그는 [kubelet](/docs/reference/command-line-tools-reference/kubelet/)이 명시된 이미지를 풀(pull) 하려고 시도할 때 영향을 미친다.
- `imagePullPolicy: IfNotPresent`: 이미지가 로컬에 이미 존재하지 않으면 이미지가 풀(Pull) 된다.
diff --git a/content/ko/docs/concepts/configuration/pod-priority-preemption.md b/content/ko/docs/concepts/configuration/pod-priority-preemption.md
index e0d6317b29..da165814da 100644
--- a/content/ko/docs/concepts/configuration/pod-priority-preemption.md
+++ b/content/ko/docs/concepts/configuration/pod-priority-preemption.md
@@ -252,7 +252,7 @@ spec:
#### 선점 피해자의 정상적인 종료
파드가 축출되면, 축출된 피해자 파드는
-[정상적인 종료 기간](/ko/docs/concepts/workloads/pods/pod/#파드의-종료)을 가진다.
+[정상적인 종료 기간](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-종료)을 가진다.
피해자 파드는 작업을 종료하고 빠져나가는 데(exit) 많은 시간을 가진다. 그렇지 않으면,
파드는 강제종료(kill) 된다. 이 정상적인 종료 기간은 스케줄러가 파드를 축출하는
지점과 보류 중인 파드(P)를 노드(N)에서 스케줄링할 수 있는 시점 사이의
@@ -265,7 +265,7 @@ spec:
#### PodDisruptionBudget을 지원하지만, 보장하지 않음
-[Pod Disruption Budget(PDB)](/ko/docs/concepts/workloads/pods/disruptions/)은
+[Pod Disruption Budget](/ko/docs/concepts/workloads/pods/disruptions/)(PDB)은
애플리케이션 소유자가 자발적 중단에서 동시에 다운된 복제된
애플리케이션의 파드 수를 제한할 수 있다. 쿠버네티스는 파드를
선점할 때 PDB를 지원하지만, PDB를 따르는 것이 최선의 노력이다. 스케줄러는
diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md
new file mode 100644
index 0000000000..5b95d9a484
--- /dev/null
+++ b/content/ko/docs/concepts/configuration/secret.md
@@ -0,0 +1,1268 @@
+---
+title: 시크릿(Secret)
+content_type: concept
+feature:
+ title: 시크릿과 구성 관리
+ description: >
+ 사용자의 이미지를 다시 빌드하거나 스택 구성의 시크릿을 노출하지 않고 시크릿과 애플리케이션 구성을 배포하고 업데이트한다.
+weight: 30
+---
+
+
+
+쿠버네티스 시크릿을 사용하면 비밀번호, OAuth 토큰, ssh 키와 같은
+민감한 정보를 저장하고 관리할 수 있다. 기밀 정보를 시크릿에 저장하는 것이
+{{< glossary_tooltip term_id="pod" text="파드" >}} 정의나
+{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}} 내에 그대로 두는 것보다 안전하고 유연하다. 자세한 내용은 [시크릿 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)를 참고한다.
+
+
+
+
+
+## 시크릿 개요
+
+시크릿은 비밀번호, 토큰 또는 키와 같은 소량의
+민감한 데이터를 포함하는 오브젝트이다. 그렇지 않으면 이러한 정보가
+파드 명세 또는 이미지에 포함될 수 있다. 사용자는 시크릿을 생성할 수 있으며 시스템도
+일부 시크릿을 생성한다.
+
+시크릿을 사용하려면, 파드가 시크릿을 참조해야 한다.
+시크릿은 세 가지 방법으로 파드와 함께 사용할 수 있다.
+
+- 하나 이상의 컨테이너에 마운트된
+{{< glossary_tooltip text="볼륨" term_id="volume" >}} 내의
+[파일](#시크릿을-파드의-파일로-사용하기)로써 사용.
+- [컨테이너 환경 변수](#시크릿을-환경-변수로-사용하기)로써 사용.
+- 파드의 [이미지를 가져올 때 kubelet](#imagepullsecrets-사용하기)에 의해 사용.
+
+### 빌트인 시크릿
+
+#### 서비스 어카운트는 API 자격 증명으로 시크릿을 자동으로 생성하고 연결함
+
+쿠버네티스는 API 접근을 위한 자격 증명이 포함된
+시크릿을 자동으로 생성하고 이러한 유형의 시크릿을 사용하도록 파드를 자동으로
+수정한다.
+
+원하는 경우 API 자격 증명의 자동 생성 및 사용을 비활성화하거나
+오버라이드할 수 있다. 그러나, API 서버에 안전하게 접근하기만 하면 되는 경우,
+자동 생성 및 사용이 권장되는 워크플로이다.
+
+서비스 어카운트 작동 방식에 대한 자세한 내용은
+[서비스어카운트(ServiceAccount)](/docs/tasks/configure-pod-container/configure-service-account/) 문서를 참고한다.
+
+### 자신만의 시크릿 생성하기
+
+#### `kubectl` 사용하여 시크릿 생성하기
+
+시크릿에는 파드가 데이터베이스에 접근하는 데 필요한 사용자 자격 증명이 포함될 수 있다.
+예를 들어, 데이터베이스 연결 문자열은
+사용자명(username)과 비밀번호(password)로 구성된다. 사용자명은 `./username.txt` 파일에
+저장하고 비밀번호는 로컬 시스템의 `./password.txt` 파일에 저장할 수 있다.
+
+```shell
+# 예제를 위해서 필요한 파일들을 생성한다.
+echo -n 'admin' > ./username.txt
+echo -n '1f2d1e2e67df' > ./password.txt
+```
+
+`kubectl create secret` 명령은 이러한 파일을 시크릿으로 패키징하고
+API 서버에 오브젝트를 생성한다.
+시크릿 오브젝트의 이름은 유효한
+[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
+
+```shell
+kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+secret "db-user-pass" created
+```
+
+기본 키 이름은 파일명(filename)이다. 선택적으로 `--from-file=[key=]source]` 를 사용하여 키 이름을 설정할 수 있다.
+
+```shell
+kubectl create secret generic db-user-pass --from-file=username=./username.txt --from-file=password=./password.txt
+```
+
+{{< note >}}
+`$`, `\`, `*`, `=`, 그리고 `!` 등의 특수 문자는 [셸](https://ko.wikipedia.org/wiki/셸)에 의해 해석되고 이스케이핑이 필요하다.
+대부분의 셸에서, 비밀번호를 이스케이프하는 가장 쉬운 방법은 작은 따옴표(`'`)로 묶는 것이다.
+예를 들어, 실제 비밀번호가 `S!B\*d$zDsb=` 이면, 다음과 같은 명령을 실행해야 한다.
+
+```shell
+kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb='
+```
+
+파일(`--from-file`)에서는 비밀번호의 특수 문자를 이스케이프할 필요가 없다.
+{{< /note >}}
+
+다음의 명령으로 시크릿이 생성되었는지 확인할 수 있다.
+
+```shell
+kubectl get secrets
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+NAME TYPE DATA AGE
+db-user-pass Opaque 2 51s
+```
+
+시크릿에 대한 설명을 볼 수 있다.
+
+```shell
+kubectl describe secrets/db-user-pass
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+Name: db-user-pass
+Namespace: default
+Labels:
+Annotations:
+
+Type: Opaque
+
+Data
+====
+password.txt: 12 bytes
+username.txt: 5 bytes
+```
+
+{{< note >}}
+`kubectl get` 명령과 `kubectl describe` 명령은 기본적으로 시크릿의 내용을 표시하지
+않는다. 이는 시크릿이 우연히 다른 사람에게 노출되거나,
+터미널 로그에 저장되지 않도록 보호하기 위함이다.
+{{< /note >}}
+
+시크릿 내용을 보는 방법을 익히기 위해서는 [시크릿 디코딩하기](#시크릿-디코딩하기)를 참고한다.
+
+#### 수동으로 시크릿 생성하기
+
+먼저 JSON 또는 YAML 형식으로 파일에 시크릿을 생성한
+다음 해당 오브젝트를 생성할 수도 있다.
+시크릿 오브젝트의 이름은 유효한
+[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
+[시크릿](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)은
+두 개의 맵(`data` 와 `stringData`)을
+포함한다. `data` 필드는 base64를 사용하여, 인코딩된 임의 데이터를 저장하는 데
+사용된다. `stringData` 필드는 편의를 위해 제공되며, 시크릿 데이터를 인코딩되지 않은
+문자열로 제공할 수 있다.
+
+예를 들어, `data` 필드를 사용하여 시크릿에 두 개의 문자열을 저장하려면, 다음과 같이
+문자열을 base64로 변환한다.
+
+```shell
+echo -n 'admin' | base64
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+YWRtaW4=
+```
+
+```shell
+echo -n '1f2d1e2e67df' | base64
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+MWYyZDFlMmU2N2Rm
+```
+
+다음과 같은 시크릿을 작성한다.
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+ name: mysecret
+type: Opaque
+data:
+ username: YWRtaW4=
+ password: MWYyZDFlMmU2N2Rm
+```
+
+이제 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply)를 사용하여 시크릿을 생성한다.
+
+```shell
+kubectl apply -f ./secret.yaml
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+secret "mysecret" created
+```
+
+특정 시나리오의 경우, `stringData` 필드를 대신 사용할 수 있다. 이
+필드를 사용하면 base64로 인코딩되지 않은 문자열을 시크릿에 직접 넣을 수 있으며,
+시크릿이 생성되거나 업데이트될 때 문자열이 인코딩된다.
+
+이에 대한 실질적인 예는 애플리케이션 배포 시에
+구성 파일 저장을 위해서 시크릿을 사용하되, 배포 프로세스 중에 해당 구성 파일의
+일부를 채우려는 경우이다.
+
+예를 들어, 애플리케이션이 다음 구성 파일을 사용하는 경우,
+
+```yaml
+apiUrl: "https://my.api.com/api/v1"
+username: "user"
+password: "password"
+```
+
+다음 정의를 사용하여 이를 시크릿에 저장할 수 있다.
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+ name: mysecret
+type: Opaque
+stringData:
+ config.yaml: |-
+ apiUrl: "https://my.api.com/api/v1"
+ username: {{username}}
+ password: {{password}}
+```
+
+그런 다음 `kubectl apply` 를 실행하기 전에 배포 도구로
+`{{username}}` 및 `{{password}}` 템플릿 변수를 바꿀 수 있다.
+
+`stringData` 필드는 쓰기 전용의 편의 필드이다. 이 내용은 시크릿을
+검색할 때 출력되지 않는다. 예를 들어, 다음 명령을 실행해본다.
+
+```shell
+kubectl get secret mysecret -o yaml
+```
+
+출력 결과는 다음과 비슷하다.
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+ creationTimestamp: 2018-11-15T20:40:59Z
+ name: mysecret
+ namespace: default
+ resourceVersion: "7225"
+ uid: c280ad2e-e916-11e8-98f2-025000000001
+type: Opaque
+data:
+ config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
+```
+
+`username` 과 같은 필드가 `data` 와 `stringData` 모두에 지정되면,
+`stringData` 의 값이 사용된다. 예를 들어, 다음의 시크릿 정의를 보자.
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+ name: mysecret
+type: Opaque
+data:
+ username: YWRtaW4=
+stringData:
+ username: administrator
+```
+
+아래의 시크릿에서 결과는 다음과 같다.
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+ creationTimestamp: 2018-11-15T20:46:46Z
+ name: mysecret
+ namespace: default
+ resourceVersion: "7579"
+ uid: 91460ecb-e917-11e8-98f2-025000000001
+type: Opaque
+data:
+ username: YWRtaW5pc3RyYXRvcg==
+```
+
+위의 `YWRtaW5pc3RyYXRvcg==` 를 디코딩하면 `administrator` 가 된다.
+
+`data` 와 `stringData` 의 키는 영숫자,
+'-', '_' 또는 '.'로 구성되어야 한다.
+
+{{< note >}}
+시크릿 데이터의 직렬화된 JSON 및 YAML 값은
+base64 문자열로 인코딩된다. 줄바꿈은 이러한 문자열 내에서 유효하지 않으므로
+생략해야 한다. Darwin/macOS에서 `base64` 유틸리티를 사용할 때,
+사용자는 긴 라인을 분할하는 `-b` 옵션을 사용하면 안된다. 반대로, 리눅스 사용자는
+`-w` 옵션을 사용할 수 없는 경우 `base64` 명령이나 `base64 | tr -d '\n'` 파이프라인에
+`-w 0` 옵션을 추가 *해야 한다*.
+{{< /note >}}
+
+#### 생성기를 통해 시크릿 생성하기
+
+쿠버네티스 v1.14부터 `kubectl` 은 [Kustomize를 사용한 오브젝트 관리](/ko/docs/tasks/manage-kubernetes-objects/kustomization/)를 지원한다. Kustomize는 시크릿과 컨피그맵(ConfigMap)을 생성하기 위한
+리소스 생성기를 제공한다. Kustomize 생성기는 디렉터리 내의
+`kustomization.yaml` 파일에 지정되어야 한다. 시크릿을 생성한 후,
+`kubectl apply` 를 사용하여 API 서버에서 시크릿을 만들 수 있다.
+
+#### 파일을 통해 시크릿 생성하기
+
+./username.txt 와 ./password.txt 파일에서
+`secretGenerator` 를 정의하여 시크릿을 생성할 수 있다.
+
+```shell
+cat <./kustomization.yaml
+secretGenerator:
+- name: db-user-pass
+ files:
+ - username.txt
+ - password.txt
+EOF
+```
+
+`kustomization.yaml` 을 포함하는 디렉터리를 적용하여 시크릿을 생성한다.
+
+```shell
+kubectl apply -k .
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+secret/db-user-pass-96mffmfh4k created
+```
+
+시크릿이 생성되었는지 다음의 명령으로 확인할 수 있다.
+
+```shell
+kubectl get secrets
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+NAME TYPE DATA AGE
+db-user-pass-96mffmfh4k Opaque 2 51s
+```
+
+```shell
+kubectl describe secrets/db-user-pass-96mffmfh4k
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+Name: db-user-pass
+Namespace: default
+Labels:
+Annotations:
+
+Type: Opaque
+
+Data
+====
+password.txt: 12 bytes
+username.txt: 5 bytes
+```
+
+#### 문자열 리터럴(literals)을 통해 시크릿 생성하기
+
+문자열 리터럴인 `username=admin` 과 `password=secret` 을
+`secretGenerator` 에 정의하여 시크릿을 만들 수 있다.
+
+```shell
+cat <./kustomization.yaml
+secretGenerator:
+- name: db-user-pass
+ literals:
+ - username=admin
+ - password=secret
+EOF
+```
+
+`kustomization.yaml` 을 포함하는 디렉터리를 적용하여 시크릿을 생성한다.
+
+```shell
+kubectl apply -k .
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+secret/db-user-pass-dddghtt9b5 created
+```
+
+{{< note >}}
+시크릿이 생성될 때, 시크릿의 이름은 시크릿 데이터를
+해시하고, 해시된 값을 이름에 추가하는 방식으로 만들어진다. 이 방식은
+데이터가 수정될 때마다 새로운 시크릿이 생성되도록 만든다.
+{{< /note >}}
+
+#### 시크릿 디코딩하기
+
+`kubectl get secret` 을 실행하여 시크릿을 검색할 수 있다.
+예를 들어, 다음 명령을 실행하여 이전 섹션에서
+생성된 시크릿을 볼 수 있다.
+
+```shell
+kubectl get secret mysecret -o yaml
+```
+
+출력 결과는 다음과 비슷하다.
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+ creationTimestamp: 2016-01-22T18:41:56Z
+ name: mysecret
+ namespace: default
+ resourceVersion: "164619"
+ uid: cfee02d6-c137-11e5-8d73-42010af00002
+type: Opaque
+data:
+ username: YWRtaW4=
+ password: MWYyZDFlMmU2N2Rm
+```
+
+`password` 필드를 디코딩한다.
+
+```shell
+echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+1f2d1e2e67df
+```
+
+#### 시크릿 편집하기
+
+기존 시크릿은 다음 명령을 사용하여 편집할 수 있다.
+
+```shell
+kubectl edit secrets mysecret
+```
+
+이렇게 하면 기본으로 설정된 에디터가 열리고 `data` 필드에 base64로 인코딩된 시크릿 값을 업데이트할 수 있다.
+
+```yaml
+# 아래 오브젝트를 수정한다. '#'로 시작하는 줄은 무시되고,
+# 빈 파일은 편집이 취소될 것이다. 이 파일을 저장하는 도중에 오류가 발생하면
+# 관련 오류와 함께 다시 열린다.
+#
+apiVersion: v1
+data:
+ username: YWRtaW4=
+ password: MWYyZDFlMmU2N2Rm
+kind: Secret
+metadata:
+ annotations:
+ kubectl.kubernetes.io/last-applied-configuration: { ... }
+ creationTimestamp: 2016-01-22T18:41:56Z
+ name: mysecret
+ namespace: default
+ resourceVersion: "164619"
+ uid: cfee02d6-c137-11e5-8d73-42010af00002
+type: Opaque
+```
+
+## 시크릿 사용하기
+
+시크릿은 데이터 볼륨으로 마운트되거나 파드의 컨테이너에서 사용할
+{{< glossary_tooltip text="환경 변수" term_id="container-env-variables" >}}로
+노출될 수 있다. 또한, 시크릿은 파드에 직접 노출되지 않고,
+시스템의 다른 부분에서도 사용할 수 있다. 예를 들어, 시크릿은
+시스템의 다른 부분이 사용자를 대신해서 외부 시스템과 상호 작용하는 데 사용해야 하는
+자격 증명을 보유할 수 있다.
+
+### 시크릿을 파드의 파일로 사용하기
+
+파드의 볼륨에서 시크릿을 사용하려면 다음과 같이 한다.
+
+1. 시크릿을 생성하거나 기존 시크릿을 사용한다. 여러 파드가 동일한 시크릿을 참조할 수 있다.
+1. `.spec.volumes[].` 아래에 볼륨을 추가하려면 파드 정의를 수정한다. 볼륨의 이름을 뭐든지 지정하고, 시크릿 오브젝트의 이름과 동일한 `.spec.volumes[].secret.secretName` 필드를 생성한다.
+1. 시크릿이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를 추가한다. 시크릿을 표시하려는 사용되지 않은 디렉터리 이름에 `.spec.containers[].volumeMounts[].readOnly = true` 와 `.spec.containers[].volumeMounts[].mountPath` 를 지정한다.
+1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을 수정한다. 시크릿 `data` 맵의 각 키는 `mountPath` 아래의 파일명이 된다.
+
+다음은 볼륨에 시크릿을 마운트하는 파드의 예시이다.
+
+```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
+```
+
+사용하려는 각 시크릿은 `.spec.volumes` 에서 참조해야 한다.
+
+파드에 여러 컨테이너가 있는 경우, 모든 컨테이너는
+자체 `volumeMounts` 블록이 필요하지만, 시크릿에 대해서는 시크릿당 하나의 `.spec.volumes` 만 필요하다.
+
+많은 파일을 하나의 시크릿으로 패키징하거나, 여러 시크릿을 사용할 수 있으며, 어느 쪽이든 편리한 방법을 사용하면 된다.
+
+#### 특정 경로에 대한 시크릿 키 투영하기
+
+시크릿 키가 투영되는 볼륨 내 경로를 제어할 수도 있다.
+`.spec.volumes[].secret.items` 필드를 사용하여 각 키의 대상 경로를 변경할 수 있다.
+
+```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` 시크릿은 `/etc/foo/username` 대신 `/etc/foo/my-group/my-username` 아래의 파일에 저장된다.
+* `password` 시크릿은 투영되지 않는다.
+
+`.spec.volumes[].secret.items` 를 사용하면, `items` 에 지정된 키만 투영된다.
+시크릿의 모든 키를 사용하려면, 모든 키가 `items` 필드에 나열되어야 한다.
+나열된 모든 키는 해당 시크릿에 존재해야 한다. 그렇지 않으면, 볼륨이 생성되지 않는다.
+
+#### 시크릿 파일 퍼미션
+
+단일 시크릿 키에 대한 파일 접근 퍼미션 비트를 설정할 수 있다.
+만약 사용자가 퍼미션을 지정하지 않는다면, 기본적으로 `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: 0400
+```
+
+그러고 나면, 시크릿이 `/etc/foo` 에 마운트되고 시크릿 볼륨 마운트로 생성된
+모든 파일의 퍼미션은 `0400` 이 될 것이다.
+
+참고로 JSON 스펙은 8진수 표기법을 지원하지 않으므로, 0400 퍼미션에 대해서
+값 256을 사용한다. 파드에 대해 JSON 대신 YAML을 사용하는 경우, 8진수 표기법을
+사용하여 보다 자연스러운 방식으로 퍼미션을 지정할 수 있다.
+
+참고로 파드에 `kubectl exec` 을 사용하는 경우, 예상되는 파일 모드를 찾기 위해
+심볼릭 링크를 따라가야 한다. 예를 들면, 다음과 같다.
+
+파드에서 시크릿 파일 모드를 확인한다.
+```
+kubectl exec mypod -it sh
+
+cd /etc/foo
+ls -l
+```
+
+출력 결과는 다음과 비슷하다.
+```
+total 0
+lrwxrwxrwx 1 root root 15 May 18 00:18 password -> ..data/password
+lrwxrwxrwx 1 root root 15 May 18 00:18 username -> ..data/username
+```
+
+올바른 파일 모드를 찾으려면 심볼릭 링크를 따라간다.
+
+```
+cd /etc/foo/..data
+ls -l
+```
+
+출력 결과는 다음과 비슷하다.
+```
+total 8
+-r-------- 1 root root 12 May 18 00:18 password
+-r-------- 1 root root 5 May 18 00:18 username
+```
+
+이전 예제에서와 같이 매핑을 사용하여, 다음과 같이
+다른 파일에 대해 다른 퍼미션을 지정할 수도 있다.
+
+```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: 0777
+```
+
+이 경우, `/etc/foo/my-group/my-username` 에 있는 파일은
+결과적으로 `0777` 퍼미션 값을 갖게 된다. JSON을 사용하는 경우, JSON 제한으로 인해
+10진수 표기법(`511`)으로 모드를 지정해야 한다.
+
+참고로 이 퍼미션 값은 나중에 읽을 때 10진수 표기법으로
+표시될 수 있다.
+
+#### 볼륨에서 시크릿 값 사용하기
+
+시크릿 볼륨을 마운트하는 컨테이너 내부에서, 시크릿 키는 파일로
+나타나고 시크릿 값은 base64로 디코딩되어 이런 파일 내에 저장된다.
+다음은 위의 예에서 컨테이너 내부에서 실행된 명령의 결과이다.
+
+```shell
+ls /etc/foo/
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+username
+password
+```
+
+```shell
+cat /etc/foo/username
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+admin
+```
+
+```shell
+cat /etc/foo/password
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+1f2d1e2e67df
+```
+
+컨테이너의 프로그램은 파일에서 시크릿을 읽는 역할을
+한다.
+
+#### 마운트된 시크릿은 자동으로 업데이트됨
+
+볼륨에서 현재 사용되는 시크릿이 업데이트되면, 투영된 키도 결국 업데이트된다.
+kubelet은 마운트된 시크릿이 모든 주기적인 동기화에서 최신 상태인지 여부를 확인한다.
+그러나, kubelet은 시크릿의 현재 값을 가져 오기 위해 로컬 캐시를 사용한다.
+캐시의 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의
+`ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용하여 구성할 수 있다.
+시크릿은 watch(기본값), ttl 기반 또는 단순히 API 서버로 모든 요청을 직접
+리디렉션하여 전파할 수 있다.
+결과적으로, 시크릿이 업데이트된 순간부터 새로운 키가 파드에 투영되는
+순간까지의 총 지연 시간은 kubelet 동기화 시간 + 캐시
+전파 지연만큼 길 수 있다. 여기서 캐시 전파 지연은 선택한 캐시 유형에 따라
+달라질 수 있다(캐시 전파 지연은 각 캐시 유형에 따라 watch 전파 지연, 캐시의 ttl, 또는 0 에 상응함).
+
+{{< note >}}
+시크릿을 [subPath](/ko/docs/concepts/storage/volumes/#subpath-사용하기)
+볼륨 마운트로 사용하는 컨테이너는 시크릿 업데이트를
+받지 않는다.
+{{< /note >}}
+
+{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+
+쿠버네티스 알파 기능인 _변경할 수 없는(immutable) 시크릿과 컨피그맵_ 은
+개별 시크릿과 컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 시크릿을 광범위하게 사용하는
+클러스터(최소 수만 개의 고유한 시크릿이 파드에 마운트)의 경우, 데이터 변경을 방지하면
+다음과 같은 이점이 있다.
+
+- 애플리케이션 중단을 유발할 수 있는 우발적(또는 원하지 않는) 업데이트로부터 보호
+- immutable로 표시된 시크릿에 대한 감시를 중단하여, kube-apiserver의 부하를
+크게 줄임으로써 클러스터의 성능을 향상시킴
+
+이 기능을 사용하려면, `ImmutableEphemeralVolumes`
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하고
+시크릿 또는 컨피그맵의 `immutable` 필드를 `true` 로 한다. 다음은 예시이다.
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+ ...
+data:
+ ...
+immutable: true
+```
+
+{{< note >}}
+시크릿 또는 컨피그맵을 immutable로 표시하면, 이 변경 사항을 되돌리거나
+`data` 필드 내용을 변경할 수 _없다_. 시크릿을 삭제하고 다시 생성할 수만 있다.
+기존 파드는 삭제된 시크릿에 대한 마운트 포인트를 유지하며, 이러한 파드를 다시 생성하는 것을
+권장한다.
+{{< /note >}}
+
+### 시크릿을 환경 변수로 사용하기
+
+파드에서 {{< glossary_tooltip text="환경 변수" term_id="container-env-variables" >}}에
+시크릿을 사용하려면 다음과 같이 한다.
+
+1. 시크릿을 생성하거나 기존 시크릿을 사용한다. 여러 파드가 동일한 시크릿을 참조할 수 있다.
+1. 사용하려는 각 시크릿 키에 대한 환경 변수를 추가하려면 시크릿 키 값을 사용하려는 각 컨테이너에서 파드 정의를 수정한다. 시크릿 키를 사용하는 환경 변수는 시크릿의 이름과 키를 `env[].valueFrom.secretKeyRef` 에 채워야 한다.
+1. 프로그램이 지정된 환경 변수에서 값을 찾도록 이미지 및/또는 커맨드 라인을 수정한다.
+
+다음은 환경 변수의 시크릿을 사용하는 파드의 예시이다.
+
+```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
+```
+
+#### 환경 변수에서 시크릿 값 사용하기
+
+환경 변수에서 시크릿을 사용하는 컨테이너 내부에서, 시크릿 키는
+시크릿 데이터의 base64 디코딩된 값을 포함하는 일반 환경 변수로 나타난다.
+다음은 위의 예에서 컨테이너 내부에서 실행된 명령의 결과이다.
+
+```shell
+echo $SECRET_USERNAME
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+admin
+```
+
+```shell
+echo $SECRET_PASSWORD
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+1f2d1e2e67df
+```
+
+### imagePullSecrets 사용하기
+
+`imagePullSecrets` 필드는 동일한 네임스페이스의 시크릿에 대한 참조 목록이다.
+`imagePullSecretsDocker` 를 사용하여 도커(또는 다른 컨테이너) 이미지 레지스트리
+비밀번호가 포함된 시크릿을 kubelet에 전달할 수 있다. kubelet은 이 정보를 사용해서 파드를 대신하여 프라이빗 이미지를 가져온다.
+`imagePullSecrets` 필드에 대한 자세한 정보는 [PodSpec API](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#podspec-v1-core)를 참고한다.
+
+#### imagePullSecret 수동으로 지정하기
+
+[컨테이너 이미지 문서](/ko/docs/concepts/containers/images/#파드에-imagepullsecrets-명시)에서 `ImagePullSecrets` 지정하는 방법을 배울 수 있다.
+
+### imagePullSecrets가 자동으로 연결되도록 정렬하기
+
+수동으로 `imagePullSecrets` 를 생성하고, 서비스어카운트(ServiceAccount)에서
+참조할 수 있다. 해당 서비스어카운트로 생성되거나
+기본적인 서비스어카운트로 생성된 모든 파드는 파드의 `imagePullSecrets`
+필드를 가져오고 서비스 어카운트의 필드로 설정한다.
+해당 프로세스에 대한 자세한 설명은
+[서비스 어카운트에 ImagePullSecrets 추가하기](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)를 참고한다.
+
+### 수동으로 생성된 시크릿의 자동 마운트
+
+수동으로 생성된 시크릿(예: GitHub 계정에 접근하기 위한 토큰이 포함된 시크릿)은
+시크릿의 서비스 어카운트를 기반한 파드에 자동으로 연결될 수 있다.
+해당 프로세스에 대한 자세한 설명은 [파드프리셋(PodPreset)을 사용하여 파드에 정보 주입하기](/docs/tasks/inject-data-application/podpreset/)를 참고한다.
+
+## 상세 내용
+
+### 제약 사항
+
+시크릿 볼륨 소스는 지정된 오브젝트 참조가
+실제로 시크릿 유형의 오브젝트를 가리키는지 확인하기 위해 유효성을 검사한다. 따라서, 시크릿에
+의존하는 모든 파드보다 먼저 시크릿을 만들어야 한다.
+
+시크릿 리소스는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}에 존재한다.
+시크릿은 동일한 네임스페이스에 있는 파드에서만 참조할 수 있다.
+
+개별 시크릿의 크기는 1MiB로 제한된다. 이는 API 서버와
+kubelet 메모리를 소진시키는 매우 큰 시크릿 생성을 막기 위한 것이다.
+그러나, 많은 작은 시크릿을 만들어도 메모리가 고갈될 수 있다. 시크릿으로
+인한 메모리 사용에 대한 보다 포괄적인 제한은 향후 버전에 계획된 기능이다.
+
+kubelet은 API 서버에서 시크릿을 가져오는 파드에 대한
+시크릿 사용만 지원한다.
+여기에는 `kubectl` 을 사용하거나, 레플리케이션 컨트롤러를 통해 간접적으로 생성된 모든
+파드가 포함된다. kubelet의 `--manifest-url` 플래그, `--config` 플래그 또는
+kubectl의 REST API(이 방법들은 파드를 생성하는 일반적인 방법이 아님)로
+생성된 파드는 포함하지 않는다.
+
+시크릿은 optional(선택 사항)로 표시되지 않는 한 파드에서 환경
+변수로 사용되기 전에 생성되어야 한다. 존재하지 않는 시크릿을
+참조하면 파드가 시작되지 않는다.
+
+명명된 시크릿에 존재하지 않는 키에 대한 참조(`secretKeyRef` 필드)는
+파드가 시작되지 않도록 한다.
+
+잘못된 환경 변수 이름으로 간주되는 키가 있는 `envFrom` 필드로
+환경 변수를 채우는 데 사용되는 시크릿은 해당 키를
+건너뛴다. 이러면 해당 파드가 시작될 수 있다. 원인이 `InvalidVariableNames` 인
+이벤트가 발생하며 건너뛴 유효하지 않은 키 목록이
+포함된 메시지가 생성된다. 다음의 예는 2개의 유효하지 않은
+키(`1badkey` 와 `2alsobad`)가 포함된 default/mysecret을 참조하는 파드를 보여준다.
+
+```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.
+```
+
+### 시크릿 및 파드 수명 상호 작용
+
+쿠버네티스 API를 호출하여 파드가 생성될 때, 참조된 시크릿이 있는지 확인하지
+않는다. 일단 파드가 스케줄되면, kubelet은 시크릿 값 가져오기를
+시도한다. 시크릿이 존재하지 않거나 API 서버에 대한
+일시적인 연결 부족으로 인해 시크릿을 가져올 수 없는 경우, kubelet은
+주기적으로 재시도한다. kubelet은 아직 시작되지 않은 이유를 설명하는
+파드에 대한 이벤트를 보고한다. 시크릿을 가져오면, kubelet은
+이를 포함하는 볼륨을 생성하고 마운트한다. 모든 파드의 볼륨이
+마운트될 때까지 파드의 컨테이너는 시작되지 않는다.
+
+## 사용 사레
+
+### 사용 사례: 컨테이너 환경 변수로 사용하기
+
+시크릿 정의를 작성한다.
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+ name: mysecret
+type: Opaque
+data:
+ USER_NAME: YWRtaW4=
+ PASSWORD: MWYyZDFlMmU2N2Rm
+```
+
+시크릿을 생성한다.
+```shell
+kubectl apply -f mysecret.yaml
+```
+
+모든 시크릿 데이터를 컨테이너 환경 변수로 정의하는 데 `envFrom` 을 사용한다. 시크릿의 키는 파드의 환경 변수 이름이 된다.
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ name: secret-test-pod
+spec:
+ containers:
+ - name: test-container
+ image: k8s.gcr.io/busybox
+ command: [ "/bin/sh", "-c", "env" ]
+ envFrom:
+ - secretRef:
+ name: mysecret
+ restartPolicy: Never
+```
+
+### 사용 사례: ssh 키가 있는 파드
+
+몇 가지 ssh 키를 포함하는 시크릿을 생성한다.
+
+```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
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+secret "ssh-key-secret" created
+```
+
+ssh 키를 포함하는 `secretGenerator` 필드가 있는 `kustomization.yaml` 를 만들 수도 있다.
+
+{{< caution >}}
+사용자 자신의 ssh 키를 보내기 전에 신중하게 생각한다. 클러스터의 다른 사용자가 시크릿에 접근할 수 있다. 쿠버네티스 클러스터를 공유하는 모든 사용자가 접근할 수 있도록 하려는 서비스 어카운트를 사용하고, 사용자가 손상된 경우 이 계정을 취소할 수 있다.
+{{< /caution >}}
+
+이제 ssh 키를 가진 시크릿을 참조하고
+볼륨에서 시크릿을 사용하는 파드를 만들 수 있다.
+
+```yaml
+apiVersion: v1
+kind: Pod
+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"
+```
+
+컨테이너의 명령이 실행될 때, 다음 위치에서 키 부분을 사용할 수 있다.
+
+```
+/etc/secret-volume/ssh-publickey
+/etc/secret-volume/ssh-privatekey
+```
+
+그러면 컨테이너는 ssh 연결을 맺기 위해 시크릿 데이터를 자유롭게 사용할 수 있다.
+
+### 사용 사례: 운영 / 테스트 자격 증명이 있는 파드
+
+이 예제에서는 운영 환경의 자격 증명이 포함된 시크릿을
+사용하는 파드와 테스트 환경의 자격 증명이 있는 시크릿을 사용하는 다른 파드를
+보여준다.
+
+사용자는 `secretGenerator` 필드가 있는 `kustomization.yaml` 을 만들거나
+`kubectl create secret` 을 실행할 수 있다.
+
+```shell
+kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+secret "prod-db-secret" created
+```
+
+```shell
+kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests
+```
+
+출력 결과는 다음과 비슷하다.
+
+```
+secret "test-db-secret" created
+```
+
+{{< note >}}
+`$`, `\`, `*`, `=` 그리고 `!` 와 같은 특수 문자는 사용자의 [셸](https://ko.wikipedia.org/wiki/셸)에 의해 해석되고 이스케이핑이 필요하다.
+대부분의 셸에서 비밀번호를 이스케이프하는 가장 쉬운 방법은 작은 따옴표(`'`)로 묶는 것이다.
+예를 들어, 실제 비밀번호가 `S!B\*d$zDsb=` 이면, 다음과 같은 명령을 실행해야 한다.
+
+```shell
+kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb='
+```
+
+파일(`--from-file`)에서는 비밀번호의 특수 문자를 이스케이프할 필요가 없다.
+{{< /note >}}
+
+이제 파드를 생성한다.
+
+```shell
+cat < 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"
+EOF
+```
+
+동일한 kustomization.yaml에 파드를 추가한다.
+
+```shell
+cat <> kustomization.yaml
+resources:
+- pod.yaml
+EOF
+```
+
+다음을 실행하여 API 서버에 이러한 모든 오브젝트를 적용한다.
+
+```shell
+kubectl apply -k .
+```
+
+두 컨테이너 모두 각 컨테이너의 환경에 대한 값을 가진 파일시스템에 다음의 파일이 존재한다.
+
+```
+/etc/secret-volume/username
+/etc/secret-volume/password
+```
+
+두 파드의 사양이 한 필드에서만 어떻게 다른지 확인한다. 이를 통해
+공통 파드 템플릿에서 다양한 기능을 가진 파드를 생성할 수 있다.
+
+두 개의 서비스 어카운트를 사용하여 기본 파드 명세를 더욱 단순화할 수 있다.
+
+1. `prod-db-secret` 을 가진 `prod-user`
+1. `test-db-secret` 을 가진 `test-user`
+
+파드 명세는 다음과 같이 단축된다.
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ name: prod-db-client-pod
+ labels:
+ name: prod-db-client
+spec:
+ serviceAccount: prod-db-client
+ containers:
+ - name: db-client-container
+ image: myClientImage
+```
+
+### 사용 사례: 시크릿 볼륨의 도트 파일(dotfile)
+
+점으로 시작하는 키를 정의하여 데이터를 "숨김"으로 만들 수 있다.
+이 키는 도트 파일 또는 "숨겨진" 파일을 나타낸다. 예를 들어, 다음 시크릿이 `secret-volume` 볼륨에
+마운트되면 아래와 같다.
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+ name: dotfile-secret
+data:
+ .secret-file: dmFsdWUtMg0KDQo=
+---
+apiVersion: v1
+kind: Pod
+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-file` 이라는 하나의 파일을 포함하고,
+`dotfile-test-container` 는 `/etc/secret-volume/.secret-file` 경로에
+이 파일을 가지게 된다.
+
+{{< note >}}
+`ls -l` 명령의 결과에서 숨겨진 점으로 시작하는 파일들은
+디렉터리 내용을 나열할 때 `ls -la` 를 사용해야 이 파일들을 볼 수 있다.
+{{< /note >}}
+
+### 사용 사례: 파드의 한 컨테이너에 표시되는 시크릿
+
+HTTP 요청을 처리하고, 복잡한 비즈니스 로직을 수행한 다음, HMAC이 있는 일부 메시지에
+서명해야 하는 프로그램을 고려한다. 애플리케이션 로직이
+복잡하기 때문에, 서버에서 눈에 띄지 않는 원격 파일 읽기 공격이
+있을 수 있으며, 이로 인해 프라이빗 키가 공격자에게 노출될 수 있다.
+
+이는 두 개의 컨테이너의 두 개 프로세스로 나눌 수 있다. 사용자 상호 작용과
+비즈니스 로직을 처리하지만, 프라이빗 키를 볼 수 없는 프론트엔드 컨테이너와
+프라이빗 키를 볼 수 있고, 프론트엔드의 간단한 서명 요청(예를 들어, localhost 네트워킹을 통해)에
+응답하는 서명자 컨테이너로 나눌 수 있다.
+
+이 분할된 접근 방식을 사용하면, 공격자는 이제 애플리케이션 서버를 속여서
+파일을 읽는 것보다 다소 어려운 임의적인 어떤 작업을 수행해야
+한다.
+
+
+
+## 모범 사례
+
+### 시크릿 API를 사용하는 클라이언트
+
+시크릿 API와 상호 작용하는 애플리케이션을 배포할 때, [RBAC](
+/docs/reference/access-authn-authz/rbac/)과 같은 [인가 정책](
+/docs/reference/access-authn-authz/authorization/)을
+사용하여 접근를 제한해야 한다.
+
+시크릿은 종종 다양한 중요도에 걸친 값을 보유하며, 이 중 많은 부분이
+쿠버네티스(예: 서비스 어카운트 토큰)와 외부 시스템으로 단계적으로
+확대될 수 있다. 개별 앱이 상호 작용할 것으로 예상되는 시크릿의 힘에 대해 추론할 수 있더라도
+동일한 네임스페이스 내의 다른 앱이 이러한 가정을
+무효화할 수 있다.
+
+이러한 이유로 네임스페이스 내 시크릿에 대한 `watch` 와 `list` 요청은
+매우 강력한 기능이며, 시크릿을 나열하면 클라이언트가 해당 네임스페이스에
+있는 모든 시크릿의 값을 검사할 수 있기 때문에 피해야 한다. 클러스터의
+모든 시크릿을 감시(`watch`)하고 나열(`list`)하는 기능은 가장 특권이 있는 시스템 레벨의
+컴포넌트에 대해서만 예약되어야 한다.
+
+시크릿 API에 접근해야 하는 애플리케이션은 필요한 시크릿에 대한 `get` 요청을
+수행해야 한다. 이를 통해 관리자는 앱에 필요한
+[개별 인스턴스에 대한 접근을 허용 목록에 추가](
+/docs/reference/access-authn-authz/rbac/#referring-to-resources)하면서 모든 시크릿에 대한 접근을
+제한할 수 있다.
+
+`get` 반복을 통한 성능 향상을 위해, 클라이언트는 시크릿을
+참조한 다음 리소스를 감시(`watch`)하고, 참조가 변경되면 시크릿을 다시 요청하는 리소스를
+설계할 수 있다. 덧붙여, 클라이언트에게 개별 리소스를 감시(`watch`)하도록 하는 ["대량 감시" API](
+https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/bulk_watch.md)도
+제안되었으며, 쿠버네티스의 후속 릴리스에서 사용할 수
+있을 것이다.
+
+## 보안 속성
+
+### 보호
+
+시크릿은 시크릿을 사용하는 파드와 독립적으로 생성될 수
+있으므로, 파드 생성, 보기, 편집 워크플로 중에
+시크릿이 노출될 위험이 적다. 또한 시스템은 가능한 경우
+디스크에 기록하지 않는 등 시크릿에 대한 추가 예방 조치를
+취할 수 있다.
+
+해당 노드의 파드에 필요한 경우에만 시크릿이 노드로 전송된다.
+kubelet은 시크릿이 디스크 저장소에 기록되지 않도록 시크릿을
+`tmpfs` 에 저장한다. 일단 시크릿에 의존하는 파드가 삭제되면, kubelet은
+시크릿 데이터의 로컬 복제본도 삭제한다.
+
+동일한 노드의 여러 파드에 대한 시크릿이 있을 수 있다. 그러나
+파드가 요청하는 시크릿만 해당 컨테이너 내에서 잠재적으로 볼 수 있다.
+따라서, 하나의 파드는 다른 파드의 시크릿에 접근할 수 없다.
+
+파드에는 여러 개의 컨테이너가 있을 수 있다. 그러나, 파드의 각 컨테이너는
+컨테이너 내에서 볼 수 있도록 파드의 `volumeMounts` 에 있는 시크릿 볼륨을
+요청해야 한다. 이것은 유용한 [파드 레벨에서의 보안
+파티션](#사용-사례-파드의-한-컨테이너에-표시되는-시크릿)을 구성하는 데 사용할 수 있다.
+
+대부분의 쿠버네티스 배포판에서, 사용자와 API 서버 간,
+API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다.
+이러한 채널을 통해 전송될 때 시크릿이 보호된다.
+
+{{< feature-state for_k8s_version="v1.13" state="beta" >}}
+
+시크릿 데이터에 대해 [저장 시 암호화(encryption at rest)](/docs/tasks/administer-cluster/encrypt-data/)를
+활성화할 수 있으며, 이를 통해 보안성에 대한 보장 없이는 시크릿이 {{< glossary_tooltip term_id="etcd" >}}에 저장되지 않도록 한다 .
+
+### 위험
+
+ - API 서버에서 시크릿 데이터는 {{< glossary_tooltip term_id="etcd" >}}에 저장된다.
+ 따라서,
+ - 관리자는 클러스터 데이터에 대해 저장 시 암호화를 활성화해야 한다. (v1.13 이상 필요)
+ - 관리자는 etcd에 대한 접근을 admin 사용자로 제한해야 한다.
+ - 관리자는 더 이상 사용하지 않을 때 etcd에서 사용하는 디스크를 지우거나 폐기할 수 있다.
+ - 클러스터에서 etcd를 실행하는 경우, 관리자는 etcd peer-to-peer 통신에 대해
+ SSL/TLS를 사용해야 한다.
+ - base64로 인코딩된 시크릿 데이터가 있는 매니페스트(JSON 또는 YAML)
+ 파일을 통해 시크릿을 구성하는 경우, 이 파일을 공유하거나 소스 리포지터리에
+ 체크인하면 시크릿이 손상된다. Base64 인코딩은 암호화 방법이 _아니며_
+ 일반 텍스트와 동일한 것으로 간주된다.
+ - 실수로 기록하거나 신뢰할 수 없는 상대방에게 전송하지 않는 것과 같이,
+ 애플리케이션은 볼륨에서 읽은 후에 시크릿 값을 보호해야 한다.
+ - 시크릿을 사용하는 파드를 생성할 수 있는 사용자는 해당 시크릿의 값도 볼 수 있다.
+ API 서버 정책이 해당 사용자가 시크릿을 읽을 수 있도록 허용하지 않더라도, 사용자는
+ 시크릿을 노출하는 파드를 실행할 수 있다.
+ - 현재, 모든 노드에 대한 루트 권한이 있는 모든 사용자는 kubelet을 가장하여
+ API 서버에서 _모든_ 시크릿을 읽을 수 있다. 단일 노드에 대한 루트 취약점 공격의
+ 영향을 제한하기 위해, 실제로 필요한 노드에만 시크릿을 보내는 것이 앞으로 계획된
+ 기능이다.
diff --git a/content/ko/docs/concepts/containers/container-environment.md b/content/ko/docs/concepts/containers/container-environment.md
index 799306a9ff..c6cb09965a 100644
--- a/content/ko/docs/concepts/containers/container-environment.md
+++ b/content/ko/docs/concepts/containers/container-environment.md
@@ -25,7 +25,7 @@ weight: 20
컨테이너의 *호스트네임* 은 컨테이너가 동작 중인 파드의 이름과 같다.
그것은 `hostname` 커맨드 또는 libc의
-[`gethostname`](http://man7.org/linux/man-pages/man2/gethostname.2.html)
+[`gethostname`](https://man7.org/linux/man-pages/man2/gethostname.2.html)
함수 호출을 통해서 구할 수 있다.
파드 이름과 네임스페이스는
@@ -48,7 +48,7 @@ FOO_SERVICE_HOST=<서비스가 동작 중인 호스트>
FOO_SERVICE_PORT=<서비스가 동작 중인 포트>
```
-서비스에 지정된 IP 주소가 있고 [DNS 애드온](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다.
+서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다.
diff --git a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md
index ac29c19c1b..0fe4bb9b9d 100644
--- a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md
+++ b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md
@@ -39,7 +39,7 @@ Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로
파라미터는 핸들러에 전달되지 않는다.
종료 동작에 더 자세한 대한 설명은
-[파드의 종료](/ko/docs/concepts/workloads/pods/pod/#파드의-종료)에서 찾을 수 있다.
+[파드의 종료](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-종료)에서 찾을 수 있다.
### 훅 핸들러 구현
diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md
index 0f7bb0cb13..f17841027b 100644
--- a/content/ko/docs/concepts/containers/images.md
+++ b/content/ko/docs/concepts/containers/images.md
@@ -262,7 +262,7 @@ EOF
이것은 프라이빗 레지스트리를 사용하는 각 파드에 대해서 수행될 필요가 있다.
-그러나, 이 필드의 셋팅은 [서비스 어카운트](/docs/user-guide/service-accounts) 리소스에
+그러나, 이 필드의 셋팅은 [서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-accounts/)) 리소스에
imagePullSecrets을 셋팅하여 자동화할 수 있다.
자세한 지침을 위해서는 [서비스 어카운트에 ImagePullSecrets 추가](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)를 확인한다.
diff --git a/content/ko/docs/concepts/extend-kubernetes/_index.md b/content/ko/docs/concepts/extend-kubernetes/_index.md
index 29d8672fca..e6d64bdfb7 100644
--- a/content/ko/docs/concepts/extend-kubernetes/_index.md
+++ b/content/ko/docs/concepts/extend-kubernetes/_index.md
@@ -19,9 +19,6 @@ no_list: true
어떤 익스텐션(extension) 포인트와 패턴이 있는지,
그리고 그것들의 트레이드오프와 제약에 대한 소개 자료로 유용할 것이다.
-
-
-
## 개요
@@ -32,14 +29,14 @@ no_list: true
*구성 파일* 및 *플래그* 는 온라인 문서의 레퍼런스 섹션에 각 바이너리 별로 문서화되어 있다.
-* [kubelet](/docs/admin/kubelet/)
-* [kube-apiserver](/docs/admin/kube-apiserver/)
-* [kube-controller-manager](/docs/admin/kube-controller-manager/)
-* [kube-scheduler](/docs/admin/kube-scheduler/).
+* [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
+* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
+* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
+* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/).
호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서 플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경 가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후 쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시 시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다.
-[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/), [네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 *빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 있다. 또한, 이들 API가 안정적인 경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/deprecation-policy/)을 사용할 수 있다. 이러한 이유로 인해 구성 파일과 플래그보다 선호된다.
+[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/), [네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 *빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 있다. 또한, 이들 API가 안정적인 경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/using-api/deprecation-policy/)을 사용할 수 있다. 이러한 이유로 인해 *구성 파일* 과 *플래그* 보다 선호된다.
## 익스텐션
@@ -71,7 +68,7 @@ no_list: true
웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다.
*바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다.
바이너리 플러그인은 kubelet(예:
-[Flex Volume 플러그인](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)과
+[Flex Volume 플러그인](/ko/docs/concepts/storage/volumes/#flexVolume)과
[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과
kubectl에서
사용한다.
@@ -93,12 +90,12 @@ kubectl에서
1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
-2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#api-접근-익스텐션) 섹션에 설명되어 있다.
-3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/extend-cluster/#사용자-정의-유형) 섹션에 설명된대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
-4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스케줄러-익스텐션) 섹션에 설명되어 있다.
+2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](#api-접근-익스텐션) 섹션에 설명되어 있다.
+3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](#사용자-정의-유형) 섹션에 설명된대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
+4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](#스케줄러-익스텐션) 섹션에 설명되어 있다.
5. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다.
-6. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다.
-7. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 [스토리지 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스토리지-플러그인)을 통해 지원될 수 있다.
+6. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다.
+7. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 [스토리지 플러그인](#스토리지-플러그인)을 통해 지원될 수 있다.
어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다.
@@ -173,14 +170,14 @@ Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도
### 네트워크 플러그인
-노드-레벨의 [네트워크 플러그인](/docs/admin/network-plugins/)을 통해 다양한 네트워킹 패브릭을 지원할 수 있다.
+노드-레벨의 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을 통해 다양한 네트워킹 패브릭을 지원할 수 있다.
### 스케줄러 익스텐션
스케줄러는 파드를 감시하고 파드를 노드에 할당하는 특수한 유형의
컨트롤러이다. 다른 쿠버네티스 컴포넌트를 계속 사용하면서
기본 스케줄러를 완전히 교체하거나,
-[여러 스케줄러](/docs/tasks/administer-cluster/configure-multiple-schedulers/)를
+[여러 스케줄러](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)를
동시에 실행할 수 있다.
이것은 중요한 부분이며, 거의 모든 쿠버네티스 사용자는 스케줄러를 수정할
@@ -191,9 +188,6 @@ Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도
[웹훅](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)을
지원한다.
-
-
-
## {{% heading "whatsnext" %}}
diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
index db2eddb3d1..fd8f2c0107 100644
--- a/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
+++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
@@ -11,8 +11,6 @@ weight: 10
애그리게이션 레이어는 [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)와는 다르며, 애그리게이션 레이어는 {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} 가 새로운 종류의 오브젝트를 인식하도록 하는 방법이다.
-
-
## 애그리게이션 레이어
@@ -30,11 +28,8 @@ extention API server가 레이턴시 요구 사항을 달성할 수 없는 경
`EnableAggregatedDiscoveryTimeout=false` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 설정해서 타임아웃
제한을 비활성화 할 수 있다. 이 사용 중단(deprecated)된 기능 게이트는 향후 릴리스에서 제거될 예정이다.
-
-
## {{% heading "whatsnext" %}}
-
* 사용자의 환경에서 Aggregator를 동작시키려면, [애그리게이션 레이어를 설정한다](/docs/tasks/extend-kubernetes/configure-aggregation-layer/).
* 다음에, [확장 API 서버를 구성해서](/docs/tasks/extend-kubernetes/setup-extension-api-server/) 애그리게이션 레이어와 연계한다.
* 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)를 배워본다.
diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
index 159c0fc846..18b98db97c 100644
--- a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
@@ -10,8 +10,6 @@ weight: 10
커스텀 리소스를 추가할 시기와 독립형 서비스를 사용하는 시기에 대해 설명한다. 커스텀 리소스를
추가하는 두 가지 방법과 이들 중에서 선택하는 방법에 대해 설명한다.
-
-
## 커스텀 리소스
@@ -49,7 +47,9 @@ _선언_ 하거나 지정할 수 있게 해주며 쿠버네티스 오브젝트
## 쿠버네티스 클러스터에 커스텀 리소스를 추가해야 하나?
-새로운 API를 생성할 때 [쿠버네티스 클러스터 API와 생성한 API를 애그리게이트](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)할 것인지 아니면 생성한 API를 독립적으로 유지할 것인지 고려하자.
+새로운 API를 생성할 때
+[쿠버네티스 클러스터 API와 생성한 API를 애그리게이트](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)할 것인지
+아니면 생성한 API를 독립적으로 유지할 것인지 고려하자.
| API 애그리게이트를 고려할 경우 | 독립 API를 고려할 경우 |
| ---------------------------- | ---------------------------- |
diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
index bfdb7ef8c3..2c57af0b5d 100644
--- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
@@ -18,8 +18,6 @@ weight: 20
및 공급 업체별 초기화 및 설정이 필요할 수 있는 기타 유사한 컴퓨팅 리소스가
포함된다.
-
-
## 장치 플러그인 등록
@@ -38,9 +36,9 @@ service Registration {
* 유닉스 소켓의 이름.
* 빌드된 장치 플러그인 API 버전.
* 알리려는 `ResourceName`. 여기서 `ResourceName` 은
- [확장된 리소스 네이밍 체계](/ko/docs/concepts/configuration/manage-resources-containers/#확장된-리소스)를
- `vendor-domain/resourcetype` 의 형식으로 따라야 한다.
- (예를 들어, NVIDIA GPU는 `nvidia.com/gpu` 로 알려진다.)
+ [확장된 리소스 네이밍 체계](/ko/docs/concepts/configuration/manage-resources-containers/#확장된-리소스)를
+ `vendor-domain/resourcetype` 의 형식으로 따라야 한다.
+ (예를 들어, NVIDIA GPU는 `nvidia.com/gpu` 로 알려진다.)
성공적으로 등록하고 나면, 장치 플러그인은 kubelet이 관리하는
장치 목록을 전송한 다음, kubelet은 kubelet 노드 상태 업데이트의 일부로
diff --git a/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md b/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md
index 543b5cfa48..8a98d9bd28 100644
--- a/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md
+++ b/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md
@@ -12,14 +12,14 @@ weight: 10
이 가이드는 쿠버네티스 클러스터를 사용자 정의하기 위한 옵션을 설명한다.
쿠버네티스 클러스터를 업무 환경의 요구에 맞게
-조정하는 방법을 이해하려는 {{< glossary_tooltip text="클러스터 운영자" term_id="cluster-operator" >}}를 대상으로 한다.
-잠재적인 {{< glossary_tooltip text="플랫폼 개발자" term_id="platform-developer" >}} 또는 쿠버네티스 프로젝트 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}인 개발자에게도
+조정하는 방법을 이해하려는 {{< glossary_tooltip text="클러스터 운영자" term_id="cluster-operator" >}}를
+대상으로 한다.
+잠재적인 {{< glossary_tooltip text="플랫폼 개발자" term_id="platform-developer" >}} 또는
+쿠버네티스 프로젝트 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}인 개발자에게도
어떤 익스텐션 포인트와 패턴이 있는지,
그리고 그것들의 트레이드오프와 제약에 대한 소개 자료로 유용할 것이다.
-
-
## 개요
@@ -30,14 +30,14 @@ weight: 10
*구성 파일* 및 *플래그* 는 온라인 문서의 레퍼런스 섹션에 각 바이너리 별로 문서화되어 있다.
-* [kubelet](/docs/admin/kubelet/)
-* [kube-apiserver](/docs/admin/kube-apiserver/)
-* [kube-controller-manager](/docs/admin/kube-controller-manager/)
-* [kube-scheduler](/docs/admin/kube-scheduler/).
+* [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
+* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
+* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
+* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/).
호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서 플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경 가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후 쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시 시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다.
-[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/ko/docs/concepts/policy/pod-security-policy/), [네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 *빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 있다. 또한, 이들 API가 안정적인 경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/deprecation-policy/)을 사용할 수 있다. 이러한 이유로 인해 구성 파일과 플래그보다 선호된다.
+[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/ko/docs/concepts/policy/pod-security-policy/), [네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 *빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 있다. 또한, 이들 API가 안정적인 경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/using-api/deprecation-policy/)을 사용할 수 있다. 이러한 이유로 인해 구성 파일과 플래그보다 선호된다.
## 익스텐션(Extension) {#익스텐션}
@@ -69,7 +69,7 @@ weight: 10
웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다.
*바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다.
바이너리 플러그인은 kubelet(예:
-[Flex Volume 플러그인](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)과
+[Flex Volume 플러그인](/ko/docs/concepts/storage/volumes/#flexVolume)과
[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과
kubectl에서
사용한다.
@@ -90,13 +90,13 @@ kubectl에서
-1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
-2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#api-접근-익스텐션) 섹션에 설명되어 있다.
-3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/extend-cluster/#사용자-정의-유형) 섹션에 설명된대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
-4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스케줄러-익스텐션) 섹션에 설명되어 있다.
-5. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다.
-6. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다.
-7. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 [스토리지 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스토리지-플러그인)을 통해 지원될 수 있다.
+1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
+2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#api-접근-익스텐션) 섹션에 설명되어 있다.
+3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/extend-cluster/#사용자-정의-유형) 섹션에 설명된대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
+4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스케줄러-익스텐션) 섹션에 설명되어 있다.
+5. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다.
+6. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다.
+7. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 [스토리지 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스토리지-플러그인)을 통해 지원될 수 있다.
어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다.
@@ -157,7 +157,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치
### 스토리지 플러그인
-[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)을 사용하면
+[Flex Volumes](/ko/docs/concepts/storage/volumes/#flexVolume)을 사용하면
Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써
빌트인 지원 없이 볼륨 유형을 마운트 할 수 있다.
@@ -168,17 +168,17 @@ Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도
통해 새로운 노드 리소스(CPU 및 메모리와 같은 빌트인 자원 외에)를
발견할 수 있게 해준다.
-
### 네트워크 플러그인
-노드-레벨의 [네트워크 플러그인](/docs/admin/network-plugins/)을 통해 다양한 네트워킹 패브릭을 지원할 수 있다.
+노드-레벨의 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을 통해
+다양한 네트워킹 패브릭을 지원할 수 있다.
### 스케줄러 익스텐션
스케줄러는 파드를 감시하고 파드를 노드에 할당하는 특수한 유형의
컨트롤러이다. 다른 쿠버네티스 컴포넌트를 계속 사용하면서
기본 스케줄러를 완전히 교체하거나,
-[여러 스케줄러](/docs/tasks/administer-cluster/configure-multiple-schedulers/)를
+[여러 스케줄러](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)를
동시에 실행할 수 있다.
이것은 중요한 부분이며, 거의 모든 쿠버네티스 사용자는 스케줄러를 수정할
@@ -190,11 +190,8 @@ Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도
지원한다.
-
-
## {{% heading "whatsnext" %}}
-
* [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기
* [동적 어드미션 컨트롤](/docs/reference/access-authn-authz/extensible-admission-controllers/)에 대해 알아보기
* 인프라스트럭처 익스텐션에 대해 더 알아보기
diff --git a/content/ko/docs/concepts/extend-kubernetes/operator.md b/content/ko/docs/concepts/extend-kubernetes/operator.md
index c663964e21..bcd9bb9945 100644
--- a/content/ko/docs/concepts/extend-kubernetes/operator.md
+++ b/content/ko/docs/concepts/extend-kubernetes/operator.md
@@ -11,9 +11,6 @@ weight: 30
사용하여 애플리케이션 및 해당 컴포넌트를 관리하는 쿠버네티스의 소프트웨어 익스텐션이다. 오퍼레이터는
쿠버네티스 원칙, 특히 [컨트롤 루프](/ko/docs/concepts/#쿠버네티스-컨트롤-플레인)를 따른다.
-
-
-
## 동기 부여
diff --git a/content/ko/docs/concepts/extend-kubernetes/service-catalog.md b/content/ko/docs/concepts/extend-kubernetes/service-catalog.md
new file mode 100644
index 0000000000..6e27220d68
--- /dev/null
+++ b/content/ko/docs/concepts/extend-kubernetes/service-catalog.md
@@ -0,0 +1,236 @@
+---
+title: 서비스 카탈로그
+content_type: concept
+weight: 40
+---
+
+
+{{< glossary_definition term_id="service-catalog" length="all" prepend="서비스 카탈로그는" >}}
+
+[오픈 서비스 브로커 API 명세](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md)에 정의된 서비스 브로커는 AWS, GCP 또는 Azure와 같은 타사 클라우드 공급자에 의해 제공되고 관리되는 매니지드 서비스의 세트에 대한 엔드포인트다.
+매니지드 서비스의 예로 Microsoft Azure Cloud Queue, Amazon Simple Quere Service, Google Cloud Pub/Sub이 있으나 애플리케이션에서 사용할 수 있는 모든 소프트웨어 제품일 수 있다.
+
+{{< glossary_tooltip text="클러스터 오퍼레이터" term_id="cluster-operator" >}}는 서비스 카탈로그를 사용하여 서비스 브로커가 제공하는 매니지드 서비스 목록을 탐색하거나 매니지드 서비스 인스턴스를 프로비저닝하고, 쿠버네티스 클러스터 내의 애플리케이션에서 사용할 수 있도록 바인딩할 수 있다.
+
+
+
+
+
+## 유스케이스 예제
+
+한 {{< glossary_tooltip text="애플리케이션 개발자" term_id="application-developer" >}}가 쿠버네티스 클러스터 내에서 실행되는 애플리케이션 중 일부로 메시지 큐를 사용하기를 원한다.
+그러나 그러한 서비스에 대한 설정과 관리에는 부담이 따른다.
+다행히 서비스 브로커를 통해 메시지 큐를 매니지드 서비스로 제공하는 클라우드 공급자가 있다.
+
+클러스터 운영자는 서비스 카탈로그를 설정하고 이를 이용하여 클라우드 공급자의 서비스 브로커와 통신하여 메시지 큐 서비스의 인스턴스를 프로비저닝하고 쿠버네티스 클러스터 내의 애플리케이션에서 사용할 수 있게 한다.
+따라서 애플리케이션 개발자는 메시지 큐의 세부 구현 또는 관리에 신경 쓸 필요가 없다.
+애플리케이션은 그것을 서비스로 간단하게 사용할 수 있다.
+
+## 아키텍처
+
+서비스 카탈로그는 [오픈 서비스 브로커 API](https://github.com/openservicebrokerapi/servicebroker)를 사용하여 쿠버네티스 API 서버가 초기 프로비저닝을 협상하고 애플리케이션이 매니지드 서비스를 사용하는데 필요한 자격 증명을 검색하는 중개자 역할을 하는 서비스 브로커와 통신한다.
+
+스토리지에 etcd를 사용하여 확장 API 서버와 컨트롤러로 구현된다. 또한 쿠버네티스 1.7 이상에서 제공하는 [애그리게이션 레이어(aggregation layer)](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하여 API를 제공한다.
+
+
+
+
+
+
+### API 리소스
+
+서비스 카탈로그는 `servicecatalog.k8s.io` API를 설치하고 다음 쿠버네티스 리소스를 제공한다.
+
+* `ClusterServiceBroker`: 서버 연결 세부 사항을 캡슐화한, 서비스 브로커의 클러스터 내부 대표.
+이들은 클러스터 내에서 새로운 유형의 매니지드 서비스를 사용할 수 있도록 하려는 클러스터 운영자가 만들고 관리한다.
+* `ClusterServiceClass`: 특정 서비스 브로커가 제공하는 매니지드 서비스.
+새로운 `ClusterServiceBroker` 리소스가 클러스터에 추가되면 서비스 카탈로그 컨트롤러는 서비스 브로커에 연결해서 사용 가능한 매니지드 서비스 목록을 얻는다. 그 다음 각 매니지드 서비스에 해당하는 새로운 `ClusterServiceClass` 리소스를 만든다.
+* `ClusterServicePlan`: 매니지드 서비스의 특별 요청. 예를 들어, 매니지드 서비스는 무료 혹은 유료 티어와 같이 사용 가능한 서로 다른 상품이 있거나, SSD 스토리지를 사용하거나 더 많은 리소스를 갖는 등 다른 구성 옵션을 가질 수 있다. `ClusterServiceClass`와 유사하게, 새로운 `ClusterServiceBroker`가 클러스터에 추가되면, 서비스 카탈로그는 각 매니지드 서비스에 사용 가능한 서비스 플랜에 해당하는 새로운 `ClusterServicePlan` 리소스를 작성한다.
+* `ServiceInstance`: `ClusterServiceClass`의 프로비저닝된 인스턴스.
+클러스터 운영자가 하나 이상의 클러스터 애플리케이션에서 사용할 수 있도록 매니지드 서비스의 특정 인스턴스를 사용하기 위해 생성한다.
+새로운 `ServiceInstance`리소스가 생성되면, 서비스 카탈로그 컨트롤러는 해당 서비스 브로커에 연결하여 서비스 인스턴스를 프로비저닝하도록 지시한다.
+* `ServiceBinding`: `ServiceInstance`에 대한 자격 증명에 액세스한다.
+자신의 애플리케이션이 `ServiceInstance`를 사용하기를 원하는 클러스터 운영자가 이들을 생성한다.
+서비스 카탈로그 컨트롤러는 생성 시 파드에 마운트될 수 있는 서비스 인스턴스에 대한 연결 세부 정보와 자격 증명이 포함된 쿠버네티스 '시크릿(secret)'을 생성한다.
+
+### 인증
+
+서비스 카탈로그는 다음의 인증 방법을 지원한다.
+
+* 기본 (username/password)
+* [OAuth 2.0 Bearer Token](https://tools.ietf.org/html/rfc6750)
+
+## 사용법
+
+클러스터 운영자는 서비스 카탈로그 API 리소스를 사용하여 매니지드 서비스를 프로비저닝하여 쿠버네티스 클러스터 내에서 사용할 수 있게 한다. 관련 단계는 다음과 같다.
+
+1. 서비스 브로커에서 사용 가능한 매니지드 서비스와 서비스 플랜을 나열.
+1. 매니지드 서비스의 새 인스턴스 프로비저닝.
+1. 연결 자격 증명을 반환하는 매니지드 서비스에 바인딩.
+1. 연결 자격 증명을 애플리케이션에 매핑.
+
+### 매니지드 서비스와 서비스 플랜 나열
+
+먼저, 클러스터 운영자는 `servicecatalog.k8s.io` 그룹 내에 `ClusterServiceBroker` 리소스를 생성해야 한다. 이 리소스는 서비스 브로커 엔드포인트에 접근하는데 필요한 URL과 연결 세부 사항을 포함한다.
+
+다음은 `ClusterServiceBroker` 리소스 예시이다.
+
+```yaml
+apiVersion: servicecatalog.k8s.io/v1beta1
+kind: ClusterServiceBroker
+metadata:
+ name: cloud-broker
+spec:
+ # 서비스 브로커의 엔드포인트를 가리킨다. (이 예시는 동작하지 않는 URL이다.)
+ url: https://servicebroker.somecloudprovider.com/v1alpha1/projects/service-catalog/brokers/default
+ #####
+ # bearer 토큰 정보 혹은 TLS용 caBundle과 같은
+ # 서비스 브로커와 통신하는데 사용될 수 있는 값을 여기에 추가할 수 있다.
+ #####
+```
+
+다음은 서비스 브로커에서 사용 가능한 매니지드 서비스와 플랜을 나열하는 단계를 설명하는 시퀀스 다이어그램이다.
+
+
+
+1. `ClusterServiceBroker` 리소스가 서비스 카탈로그에 추가되면, 사용 가능한 서비스 목록에 대한 외부 서비스 브로커에 대한 호출을 발생시킨다.
+1. 서비스 브로커는 사용 가능한 매니지드 서비스 목록과 서비스 플랜 목록을 반환한다. 이 목록은 각각 로컬 `ClusterServiceClass`와 `ClusterServicePlan` 리소스로 캐시된다.
+1. 그런 다음 클러스터 운영자는 다음의 명령어를 사용하여 가용한 관리 서비스 목록을 얻을 수 있다.
+
+ kubectl get clusterserviceclasses -o=custom-columns=SERVICE\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName
+
+ 아래와 같은 형태의 서비스 이름 목록이 출력된다.
+
+ SERVICE NAME EXTERNAL NAME
+ 4f6e6cf6-ffdd-425f-a2c7-3c9258ad2468 cloud-provider-service
+ ... ...
+
+ 또한 다음의 명령어를 사용하여 가용한 서비스 플랜을 볼 수 있다.
+
+ kubectl get clusterserviceplans -o=custom-columns=PLAN\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName
+
+ 아래와 같은 형태의 플랜 이름 목록이 출력된다.
+
+ PLAN NAME EXTERNAL NAME
+ 86064792-7ea2-467b-af93-ac9694d96d52 service-plan-name
+ ... ...
+
+
+### 새 인스턴스 프로비저닝
+
+클러스터 운영자는 `ServiceInstance` 리소스를 생성하여 새 인스턴스 프로비저닝을 시작할 수 있다.
+
+다음은 `ServiceInstance` 리소스의 예시이다.
+
+```yaml
+apiVersion: servicecatalog.k8s.io/v1beta1
+kind: ServiceInstance
+metadata:
+ name: cloud-queue-instance
+ namespace: cloud-apps
+spec:
+ # 이전에 반환된 서비스 중 하나를 참조
+ clusterServiceClassExternalName: cloud-provider-service
+ clusterServicePlanExternalName: service-plan-name
+ #####
+ # 이곳에 서비스 브로커가 사용할 수 있는
+ # 파라미터를 추가할 수 있다.
+ #####
+```
+
+다음의 시퀀스 다이어그램은 매니지드 서비스의 새 인스턴스 프로비저닝과 관련된 일련의 단계를 보여준다.
+
+
+
+1. `ServiceInstance` 리소스가 생성되면, 서비스 카탈로그는 서비스 인스턴스를 프로비저닝하기 위해 외부의 서비스 브로커 호출을 초기화한다.
+1. 서비스 브로커는 새로운 매니지드 서비스 인스턴스를 생성하고 HTTP 응답을 리턴한다.
+1. 그 후 클러스터 운영자는 인스턴스 상태가 준비되었는지 점검할 수 있다.
+
+### 매니지드 서비스에 바인딩
+
+새 인스턴스가 프로비저닝된 후, 클러스터 운영자는 애플리케이션이 서비스를 사용하는데 필요한 자격 증명을 얻기 위해 매니지드 서비스에 바인드해야 한다. 이것은 `ServiceBinding` 리소스를 생성하는 것으로 이루어진다.
+
+다음은 `ServiceBinding` 리소스의 예시다.
+
+```yaml
+apiVersion: servicecatalog.k8s.io/v1beta1
+kind: ServiceBinding
+metadata:
+ name: cloud-queue-binding
+ namespace: cloud-apps
+spec:
+ instanceRef:
+ name: cloud-queue-instance
+ #####
+ # 서비스 브로커가 사용할 수 있는 secretName, 서비스 어카운트 파라미터 등의
+ # 추가 정보를 여기에 추가할 수 있다.
+ #####
+```
+
+다음의 시퀀스 다이어그램은 매니지드 서비스 인스턴스에 바인딩하는 단계를 보여준다.
+
+
+
+1. `ServiceBinding`이 생성된 이후, 서비스 카탈로그는 서비스 인스턴스와 바인딩하는데 필요한 정보를 요청하는 외부 서비스 브로커를 호출한다.
+1. 서비스 브로커는 적절한 서비스 어카운트에 대한 애플리케이션 권한/역할을 활성화한다.
+1. 서비스 브로커는 매니지드 서비스 인스턴스에 연결하고 액세스하는데 필요한 정보를 리턴한다. 이는 제공자와 서비스에 특화되어 있으므로 서비스 프로바이더와 매니지드 서비스에 따라 다를 수 있다.
+
+### 연결 자격 증명 매핑
+
+바인딩 후 마지막 단계는 연결 자격 증명과 서비스 특화 정보를 애플리케이션에 매핑하는 것이다.
+이런 정보는 클러스터의 애플리케이션이 액세스하여 매니지드 서비스와 직접 연결하는데 사용할 수 있는 시크릿으로 저장된다.
+
+
+
+
+
+#### 파드 구성 파일
+
+이 매핑을 수행하는 한 가지 방법은 선언적 파드 구성을 사용하는 것이다.
+
+다음 예시는 서비스 자격 증명을 애플리케이션에 매핑하는 방법을 설명한다. `sa-key`라는 키는 `provider-cloud-key`라는 볼륨에 저장되며, 애플리케이션은 이 볼륨을 `/var/secrets/provider/key.json`에 마운트한다. 환경 변수 `PROVIDER_APPLICATION_CREDENTIALS`는 마운트된 파일의 값에서 매핑된다.
+
+```yaml
+...
+ spec:
+ volumes:
+ - name: provider-cloud-key
+ secret:
+ secretName: sa-key
+ containers:
+...
+ volumeMounts:
+ - name: provider-cloud-key
+ mountPath: /var/secrets/provider
+ env:
+ - name: PROVIDER_APPLICATION_CREDENTIALS
+ value: "/var/secrets/provider/key.json"
+```
+
+다음 예시는 시크릿 값을 애플리케이션 환경 변수에 매핑하는 방법을 설명한다. 이 예시에서 메시지 큐 토픽 이름은 `topic` 라는 키의 `provider-queue-credentials` 시크릿에서 환경 변수 `TOPIC`에 매핑된다.
+
+
+```yaml
+...
+ env:
+ - name: "TOPIC"
+ valueFrom:
+ secretKeyRef:
+ name: provider-queue-credentials
+ key: topic
+```
+
+
+
+
+## {{% heading "whatsnext" %}}
+
+* 만약 당신이 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}에 익숙하다면, 당신의 쿠버네티스 클러스터에 [Helm을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-helm/)할 수 있다. 다른 방법으로 [SC tool을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-sc/)할 수 있다.
+* [샘플 서비스 브로커](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) 살펴보기
+* [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) 프로젝트 탐색
+* [svc-cat.io](https://svc-cat.io/docs/) 살펴보기
+
+
+
+
+
diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md
index 26047a8814..8ce410330c 100644
--- a/content/ko/docs/concepts/overview/kubernetes-api.md
+++ b/content/ko/docs/concepts/overview/kubernetes-api.md
@@ -22,9 +22,6 @@ card:
API 엔드포인트, 리소스 타입과 샘플은 [API Reference](/ko/docs/reference)에 기술되어 있다.
-
-
-
## API 변경
@@ -84,7 +81,7 @@ OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다.
## API 버전 규칙
필드를 없애거나 리소스 표현을 재구성하기 쉽도록,
-쿠버네티스는 `/api/v1`이나 `/apis/extensions/v1beta1`과 같이
+쿠버네티스는 `/api/v1`이나 `/apis/rbac.authorization.k8s.io/v1alpha1`과 같이
각각 다른 API 경로에서 복수의 API 버전을 지원한다.
버전 관리는 API가 시스템 리소스와 동작에 대해 명확하고 일관된 보기를
@@ -156,14 +153,6 @@ API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명
{{< note >}}그룹이나 리소스를 활성화 또는 비활성화하려면 kube-apiserver와
controller-manager를 재시작해서 `--runtime-config` 변경 사항을 반영해야 한다. {{< /note >}}
-## extensions/v1beta1 그룹 내 특정 리소스 활성화하기
-
-데몬셋, 디플로이먼트, 스테이트풀셋, 네트워크폴리시, 파드시큐리티폴리시 그리고 레플리카셋은 `extensions/v1beta1` API 그룹에서 기본적으로 비활성화되어있다.
-예시: 디플로이먼트와 데몬셋의 활성화 설정은
-`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true` 를 입력한다.
-
-{{< note >}}개별 리소스의 활성화/비활성화는 레거시 문제로 `extensions/v1beta1` API 그룹에서만 지원된다. {{< /note >}}
-
## 지속성
쿠버네티스는 API 리소스에 대한 직렬화된 상태를 {{< glossary_tooltip term_id="etcd" >}}에
diff --git a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md
index 73fa4ff4d0..c43acf468c 100644
--- a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+++ b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md
@@ -92,5 +92,5 @@ deployment.apps/nginx-deployment created
## {{% heading "whatsnext" %}}
* API 개념의 더 많은 설명은 [Kubernetes API 개요](/ko/docs/reference/using-api/api-overview/)를 본다.
-* [파드](/ko/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다.
+* [파드](/ko/docs/concepts/workloads/pods/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다.
* 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다.
diff --git a/content/ko/docs/concepts/overview/working-with-objects/labels.md b/content/ko/docs/concepts/overview/working-with-objects/labels.md
index ed896ce005..a007375673 100644
--- a/content/ko/docs/concepts/overview/working-with-objects/labels.md
+++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md
@@ -20,10 +20,9 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이
}
```
-레이블은 UI와 CLI에서 효율적인 쿼리를 사용하고 검색에 사용하기에 적합하다. 식별되지 않는 정보는 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)으로 기록해야 한다.
-
-
-
+레이블은 UI와 CLI에서 효율적인 쿼리를 사용하고 검색에 사용하기에
+적합하다. 식별되지 않는 정보는
+[어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/)으로 기록해야 한다.
@@ -183,7 +182,10 @@ kubectl get pods -l 'environment,environment notin (frontend)'
### API 오브젝트에서 참조 설정
-[`services`](/ko/docs/concepts/services-networking/service/) 와 [`replicationcontrollers`](/ko/docs/concepts/workloads/controllers/replicationcontroller/)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 [파드](/ko/docs/concepts/workloads/pods/pod/)와 같은 다른 리소스 집합을 선택한다.
+[`services`](/ko/docs/concepts/services-networking/service/) 와
+[`replicationcontrollers`](/ko/docs/concepts/workloads/controllers/replicationcontroller/)와 같은
+일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서
+[파드](/ko/docs/concepts/workloads/pods/pod/)와 같은 다른 리소스 집합을 선택한다.
#### 서비스와 레플리케이션 컨트롤러
@@ -208,7 +210,11 @@ selector:
#### 세트-기반 요건을 지원하는 리소스
-[`Job`](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/), [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/), [`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/) 그리고 [`DaemonSet`](/ko/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다.
+[`Job`](/ko/docs/concepts/workloads/controllers/job/),
+[`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/),
+[`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/) 그리고
+[`DaemonSet`](/ko/docs/concepts/workloads/controllers/daemonset/) 같은
+새로운 리소스들은 _집합성 기준_ 의 요건도 지원한다.
```yaml
selector:
@@ -226,4 +232,3 @@ selector:
레이블을 통해 선택하는 사용 사례 중 하나는 파드를 스케줄 할 수 있는 노드 셋을 제한하는 것이다.
자세한 내용은 [노드 선택](/ko/docs/concepts/scheduling-eviction/assign-pod-node/) 문서를 참조한다.
-
diff --git a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md
index ec4df0668d..3d11774cce 100644
--- a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md
+++ b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md
@@ -9,9 +9,6 @@ weight: 30
쿠버네티스는 동일한 물리 클러스터를 기반으로 하는 여러 가상 클러스터를 지원한다.
이런 가상 클러스터를 네임스페이스라고 한다.
-
-
-
## 여러 개의 네임스페이스를 사용하는 경우
@@ -32,12 +29,13 @@ weight: 30
동일한 소프트웨어의 다른 버전과 같이 약간 다른 리소스를 분리하기 위해
여러 네임스페이스를 사용할 필요는 없다. 동일한 네임스페이스 내에서 리소스를
-구별하기 위해 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 사용한다.
+구별하기 위해 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을
+사용한다.
## 네임스페이스 다루기
-네임스페이스의 생성과 삭제는 [네임스페이스 관리자 가이드 문서](/docs/tasks/administer-cluster/namespaces/)에
-기술되어 있다.
+네임스페이스의 생성과 삭제는
+[네임스페이스 관리자 가이드 문서](/docs/tasks/administer-cluster/namespaces/)에 기술되어 있다.
{{< note >}}
쿠버네티스 시스템 네임스페이스용으로 예약되어 있으므로, `kube-` 접두사로 네임스페이스를 생성하지 않는다.
@@ -89,7 +87,7 @@ kubectl config view --minify | grep namespace:
## 네임스페이스와 DNS
-[서비스](/docs/user-guide/services)를 생성하면 해당
+[서비스](/ko/docs/concepts/services-networking/service/)를 생성하면 해당
[DNS 엔트리](/ko/docs/concepts/services-networking/dns-pod-service/)가 생성된다.
이 엔트리는 `<서비스-이름>.<네임스페이스-이름>.svc.cluster.local`의 형식을 갖는데,
이는 컨테이너가 `<서비스-이름>`만 사용하는 경우, 네임스페이스 내에 국한된 서비스로 연결된다.
@@ -100,7 +98,8 @@ kubectl config view --minify | grep namespace:
대부분의 쿠버네티스 리소스(예를 들어, 파드, 서비스, 레플리케이션 컨트롤러 외)는
네임스페이스에 속한다. 하지만 네임스페이스 리소스 자체는 네임스페이스에 속하지 않는다.
-그리고 [노드](/ko/docs/concepts/architecture/nodes/)나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느
+그리고 [노드](/ko/docs/concepts/architecture/nodes/)나
+퍼시스턴트 볼륨과 같은 저수준 리소스는 어느
네임스페이스에도 속하지 않는다.
다음은 네임스페이스에 속하지 않는 쿠버네티스 리소스를 조회하는 방법이다.
@@ -113,8 +112,6 @@ kubectl api-resources --namespaced=true
kubectl api-resources --namespaced=false
```
-
-
## {{% heading "whatsnext" %}}
* [신규 네임스페이스 생성](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)에 대해 더 배우기.
diff --git a/content/ko/docs/concepts/overview/working-with-objects/object-management.md b/content/ko/docs/concepts/overview/working-with-objects/object-management.md
index 590116af6f..4c1570c458 100644
--- a/content/ko/docs/concepts/overview/working-with-objects/object-management.md
+++ b/content/ko/docs/concepts/overview/working-with-objects/object-management.md
@@ -10,27 +10,26 @@ weight: 15
제공한다. Kubectl로 오브젝트 관리하기에 대한 자세한 설명은
[Kubectl 서적](https://kubectl.docs.kubernetes.io)에서 확인한다.
-
## 관리 기법
{{< warning >}}
쿠버네티스 오브젝트는 하나의 기법만 사용하여 관리해야 한다. 동일한 오브젝트에
-대해 혼합하고 일치시키는 기법은 확실하지 않은 동작을 초래하게 된다.
+대해 여러 기법을 혼용하는 것은 예상치 못한 동작을 초래하게 된다.
{{< /warning >}}
-| Management technique | Operates on |Recommended environment | Supported writers | Learning curve |
-|----------------------------------|----------------------|------------------------|--------------------|----------------|
-| Imperative commands | Live objects | Development projects | 1+ | Lowest |
-| Imperative object configuration | Individual files | Production projects | 1 | Moderate |
-| Declarative object configuration | Directories of files | Production projects | 1+ | Highest |
+| 관리기법 | 대상 | 권장 환경 | 지원하는 작업자 수 | 학습 난이도 |
+|--------------------|-----------------|------------|-----------------|----------|
+| 명령형 커맨드 | 활성 오브젝트 | 개발 환경 | 1+ | 낮음 |
+| 명령형 오브젝트 구성 | 개별 파일 | 프로덕션 환경 | 1 | 보통 |
+| 선언형 오브젝트 구성 | 파일이 있는 디렉터리 | 프로덕션 환경 | 1+ | 높음 |
## 명령형 커맨드
명령형 커맨드를 사용할 경우, 사용자는 클러스터 내 활성 오브젝트를 대상으로
-직접 동작시킨다. 사용자는 `kubectl` 커맨드에 인수 또는 플래그로 작업을
-제공한다.
+직접 동작시킨다. 사용자는 실행할 작업을 인수 또는 플래그로 `kubectl` 커맨드에
+지정한다.
이것은 클러스터에서 일회성 작업을 개시시키거나 동작시키기 위한
가장 단순한 방법이다. 이 기법은 활성 오브젝트를 대상으로 직접적인
@@ -38,7 +37,7 @@ weight: 15
### 예시
-디플로이먼트 오브젝트를 생성하기 위해 nginx 컨테이너의 인스턴스를 구동시킨다.
+디플로이먼트 오브젝트를 생성하여 nginx 컨테이너의 인스턴스를 구동시킨다.
```sh
kubectl create deployment nginx --image nginx
@@ -60,8 +59,8 @@ kubectl create deployment nginx --image nginx
## 명령형 오브젝트 구성
-명령형 오브젝트 구성에서 kubectl 커맨드는 작업(생성, 교체 등),
-선택적 플래그, 그리고 최소 하나의 파일 이름을 정의한다.
+명령형 오브젝트 구성에서는 kubectl 커맨드로 작업(생성, 교체 등),
+선택적 플래그, 그리고 최소 하나의 파일 이름을 지정한다.
그 파일은 YAML 또는 JSON 형식으로 오브젝트의 완전한 정의를
포함해야만 한다.
@@ -118,7 +117,7 @@ kubectl replace -f nginx.yaml
선언형 오브젝트 구성에 비해 단점은 다음과 같다.
-- 명령형 오브젝트 구성은 디렉터리가 아닌, 파일에 대해 가장 효과가 있다.
+- 명령형 오브젝트 구성은 디렉터리가 아닌, 파일에 가장 적합하다.
- 활성 오브젝트에 대한 업데이트는 구성 파일에 반영되어야 한다. 그렇지 않으면 다음 교체 중에 손실된다.
## 선언형 오브젝트 구성
@@ -167,11 +166,8 @@ kubectl apply -R -f configs/
- 선언형 오브젝트 구성은 예상치 못한 결과를 디버깅하고 이해하기가 더 어렵다.
- diff를 사용한 부분 업데이트는 복잡한 병합 및 패치 작업을 일으킨다.
-
-
## {{% heading "whatsnext" %}}
-
- [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/)
- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
diff --git a/content/ko/docs/concepts/policy/limit-range.md b/content/ko/docs/concepts/policy/limit-range.md
index 84656375c0..8a8270be8c 100644
--- a/content/ko/docs/concepts/policy/limit-range.md
+++ b/content/ko/docs/concepts/policy/limit-range.md
@@ -6,13 +6,10 @@ weight: 10
-기본적으로 컨테이너는 쿠버네티스 클러스터에서 무제한 [컴퓨팅 리소스](/docs/user-guide/compute-resources)로 실행된다.
+기본적으로 컨테이너는 쿠버네티스 클러스터에서 무제한 [컴퓨팅 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)로 실행된다.
리소스 쿼터을 사용하면 클러스터 관리자는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}별로 리소스 사용과 생성을 제한할 수 있다.
네임스페이스 내에서 파드나 컨테이너는 네임스페이스의 리소스 쿼터에 정의된 만큼의 CPU와 메모리를 사용할 수 있다. 하나의 파드 또는 컨테이너가 사용 가능한 모든 리소스를 독점할 수 있다는 우려가 있다. 리밋레인지는 네임스페이스에서 리소스 할당(파드 또는 컨테이너)을 제한하는 정책이다.
-
-
-
_리밋레인지_ 는 다음과 같은 제약 조건을 제공한다.
@@ -52,11 +49,8 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다.
경합이나 리밋레인지 변경은 이미 생성된 리소스에 영향을 미치지 않는다.
-
-
## {{% heading "whatsnext" %}}
-
자세한 내용은 [LimitRanger 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)를 참조한다.
제한의 사용에 대한 예시는 다음을 참조한다.
@@ -67,5 +61,3 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다.
- [네임스페이스당 기본 메모리 요청과 제한을 설정하는 방법](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/).
- [네임스페이스당 최소 및 최대 스토리지 사용량을 설정하는 방법](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage).
- [네임스페이스당 할당량을 설정하는 자세한 예시](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/).
-
-
diff --git a/content/ko/docs/concepts/policy/pod-security-policy.md b/content/ko/docs/concepts/policy/pod-security-policy.md
index c0ccaea504..a81038e444 100644
--- a/content/ko/docs/concepts/policy/pod-security-policy.md
+++ b/content/ko/docs/concepts/policy/pod-security-policy.md
@@ -11,9 +11,6 @@ weight: 20
파드 시큐리티 폴리시를 사용하면 파드 생성 및 업데이트에 대한 세분화된 권한을
부여할 수 있다.
-
-
-
## 파드 시큐리티 폴리시란?
@@ -140,7 +137,7 @@ RBAC 바인딩에 대한 자세한 예는,
### 문제 해결
-- [컨트롤러 관리자](/docs/admin/kube-controller-manager/)는
+- [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)는
[보안 API 포트](/docs/reference/access-authn-authz/controlling-access/)에 대해 실행해야 하며,
슈퍼유저 권한이 없어야 한다. 그렇지 않으면 요청이 인증 및 권한 부여 모듈을 우회하고,
모든 파드시큐리티폴리시 오브젝트가 허용되며
@@ -626,13 +623,9 @@ spec:
- `allowedUnsafeSysctls` - `forbiddenSysctls`에 나열되지 않는 한 기본 목록에서 허용하지 않은 특정 sysctls를 허용한다.
[Sysctl 문서](
-/docs/concepts/cluster-administration/sysctl-cluster/#podsecuritypolicy)를 참고하길 바란다.
-
-
+/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)를 참고하길 바란다.
## {{% heading "whatsnext" %}}
-
-폴리시 권장 사항에 대해서는 [파드 보안 표준](/docs/concepts/security/pod-security-standards/)을 참조한다.
-
-API 세부 정보는 [파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조한다.
+- 폴리시 권장 사항에 대해서는 [파드 보안 표준](/docs/concepts/security/pod-security-standards/)을 참조한다.
+- API 세부 정보는 [파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조한다.
diff --git a/content/ko/docs/concepts/policy/resource-quotas.md b/content/ko/docs/concepts/policy/resource-quotas.md
index ca1af3adc2..13107a0613 100644
--- a/content/ko/docs/concepts/policy/resource-quotas.md
+++ b/content/ko/docs/concepts/policy/resource-quotas.md
@@ -11,9 +11,6 @@ weight: 10
리소스 쿼터는 관리자가 이 문제를 해결하기 위한 도구이다.
-
-
-
`ResourceQuota` 오브젝트로 정의된 리소스 쿼터는 네임스페이스별 총 리소스 사용을 제한하는
@@ -25,15 +22,21 @@ weight: 10
- 다른 팀은 다른 네임스페이스에서 작동한다. 현재 이것은 자발적이지만 ACL을 통해 이 필수 사항을
적용하기 위한 지원이 계획되어 있다.
+
- 관리자는 각 네임스페이스에 대해 하나의 `ResourceQuota`를 생성한다.
+
- 사용자는 네임스페이스에서 리소스(파드, 서비스 등)를 생성하고 쿼터 시스템은
사용량을 추적하여 `ResourceQuota`에 정의된 하드(hard) 리소스 제한을 초과하지 않도록 한다.
+
- 리소스를 생성하거나 업데이트할 때 쿼터 제약 조건을 위반하면 위반된 제약 조건을 설명하는
메시지와 함께 HTTP 상태 코드 `403 FORBIDDEN`으로 요청이 실패한다.
+
- `cpu`, `memory`와 같은 컴퓨트 리소스에 대해 네임스페이스에서 쿼터가 활성화된 경우
사용자는 해당값에 대한 요청 또는 제한을 지정해야 한다. 그렇지 않으면 쿼터 시스템이
파드 생성을 거부할 수 있다. 힌트: 컴퓨트 리소스 요구 사항이 없는 파드를 기본값으로 설정하려면 `LimitRanger` 어드미션 컨트롤러를 사용하자.
- 이 문제를 회피하는 방법에 대한 예제는 [연습](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)을 참고하길 바란다.
+
+ 이 문제를 회피하는 방법에 대한 예제는
+ [연습](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)을 참고하길 바란다.
`ResourceQuota` 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-서브도메인-이름)이어야 한다.
@@ -61,7 +64,7 @@ API 서버 `--enable-admission-plugins=` 플래그의 인수 중 하나로
## 컴퓨트 리소스 쿼터
-지정된 네임스페이스에서 요청할 수 있는 총 [컴퓨트 리소스](/docs/user-guide/compute-resources) 합을 제한할 수 있다.
+지정된 네임스페이스에서 요청할 수 있는 총 [컴퓨트 리소스](/ko/docs/concepts/configuration/manage-resources-containers/) 합을 제한할 수 있다.
다음과 같은 리소스 유형이 지원된다.
@@ -594,9 +597,6 @@ plugins:
[리소스 쿼터를 사용하는 방법에 대한 자세한 예](/docs/tasks/administer-cluster/quota-api-object/)를 참고하길 바란다.
-
-
## {{% heading "whatsnext" %}}
-
-자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고하길 바란다.
+- 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고하길 바란다.
diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md
index 3c0a4c5110..a306a26a23 100644
--- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md
+++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md
@@ -10,8 +10,6 @@ weight: 10
파드를 실행할 수 있도록 {{< glossary_tooltip text="파드" term_id="pod" >}}가
{{< glossary_tooltip text="노드" term_id="node" >}}에 적합한지 확인하는 것을 말한다.
-
-
## 스케줄링 개요 {#scheduling}
@@ -92,6 +90,6 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기
* [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기
* kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기
-* [멀티 스케줄러 구성하기](/docs/tasks/administer-cluster/configure-multiple-schedulers/)에 대해 배우기
+* [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기
* [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기
* [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/)에 대해 배우기
diff --git a/content/ko/docs/concepts/services-networking/connect-applications-service.md b/content/ko/docs/concepts/services-networking/connect-applications-service.md
index 1993fc860d..97345c0efb 100644
--- a/content/ko/docs/concepts/services-networking/connect-applications-service.md
+++ b/content/ko/docs/concepts/services-networking/connect-applications-service.md
@@ -129,7 +129,7 @@ curl을 할 수 있을 것이다. 서비스 IP는 완전히 가상이므로 외
쿠버네티스는 서비스를 찾는 두 가지 기본 모드인 환경 변수와 DNS를
지원한다. 전자는 기본적으로 작동하지만 후자는
-[CoreDNS 클러스터 애드온](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)이 필요하다.
+[CoreDNS 클러스터 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)이 필요하다.
{{< note >}}
만약 서비스 환경 변수가 필요하지 않은 경우(소유한 프로그램과의 예상되는 충돌 가능성,
처리할 변수가 너무 많은 경우, DNS만 사용하는 경우 등) [파드 사양](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)에서
diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md
index 3f5a05f4ee..927201d90c 100644
--- a/content/ko/docs/concepts/services-networking/dns-pod-service.md
+++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md
@@ -65,10 +65,19 @@ SRV 레코드는 노멀 서비스 또는
### A/AAAA 레코드
-디플로이먼트나 데몬셋으로 생성되는 파드는 다음과 같은
-DNS 주소를 갖게 된다.
+일반적으로 파드에는 다음과 같은 DNS 주소를 갖는다.
-`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example.`
+`pod-ip-address.my-namespace.pod.cluster-domain.example`.
+
+예를 들어, `default` 네임스페이스의 파드에 IP 주소 172.17.0.3이 있고,
+클러스터의 도메인 이름이 `cluster.local` 이면, 파드는 다음과 같은 DNS 주소를 갖는다.
+
+`172-17-0-3.default.pod.cluster.local`.
+
+서비스에 의해 노출된 디플로이먼트(Deployment)나 데몬셋(DaemonSet)에 의해 생성된
+모든 파드는 다음과 같은 DNS 주소를 갖는다.
+
+`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example`.
### 파드의 hostname 및 subdomain 필드
diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md
index 47d2687dee..5d6dbefafe 100644
--- a/content/ko/docs/concepts/services-networking/ingress-controllers.md
+++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md
@@ -26,7 +26,7 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Datawire](https://www.datawire.io/)의
[커뮤니티](https://www.getambassador.io/docs) 혹은 [상업적](https://www.getambassador.io/pro/) 지원을 제공하는
[Envoy](https://www.envoyproxy.io) 기반 인그레스 컨트롤러다.
-* [AppsCode Inc.](https://appscode.com) 는 가장 널리 사용되는 [HAProxy](http://www.haproxy.org/) 기반 인그레스 컨트롤러인 [Voyager](https://appscode.com/products/voyager)에 대한 지원 및 유지 보수를 제공한다.
+* [AppsCode Inc.](https://appscode.com) 는 가장 널리 사용되는 [HAProxy](https://www.haproxy.org/) 기반 인그레스 컨트롤러인 [Voyager](https://appscode.com/products/voyager)에 대한 지원 및 유지 보수를 제공한다.
* [AWS ALB 인그레스 컨트롤러](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)는 [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/)를 사용하여 인그레스를 활성화한다.
* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러로
VMware에서 제공하고 지원한다.
diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md
index 23ab2d1ade..b5cf1df0ce 100644
--- a/content/ko/docs/concepts/services-networking/ingress.md
+++ b/content/ko/docs/concepts/services-networking/ingress.md
@@ -429,7 +429,7 @@ TLS 기능을 제공하는 다양한 인그레스 컨트롤러간의 기능
얻을 수 있다.
또한, 헬스 체크를 인그레스를 통해 직접 노출되지 않더라도, 쿠버네티스에는
-[준비 상태 프로브](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)와
+[준비 상태 프로브](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)와
같은 동일한 최종 결과를 얻을 수 있는 병렬 개념이
있다는 점도 주목할 가치가 있다. 컨트롤러 별
설명서를 검토하여 헬스 체크를 처리하는 방법을 확인한다(
diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md
index adcf9f9e9a..4d8bb47bda 100644
--- a/content/ko/docs/concepts/services-networking/network-policies.md
+++ b/content/ko/docs/concepts/services-networking/network-policies.md
@@ -4,8 +4,6 @@ content_type: concept
weight: 50
---
-{{< toc >}}
-
네트워크 정책은 {{< glossary_tooltip text="파드" term_id="pod">}} 그룹이 서로 간에 또는 다른 네트워크 엔드포인트와 통신할 수 있도록 허용하는 방법에 대한 명세이다.
diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md
index 429708e4bf..90ec166c03 100644
--- a/content/ko/docs/concepts/services-networking/service.md
+++ b/content/ko/docs/concepts/services-networking/service.md
@@ -18,8 +18,6 @@ weight: 10
쿠버네티스는 파드에게 고유한 IP 주소와 파드 집합에 대한 단일 DNS 명을 부여하고,
그것들 간에 로드-밸런스를 수행할 수 있다.
-
-
## 동기
@@ -388,7 +386,7 @@ CIDR 범위 내의 유효한 IPv4 또는 IPv6 주소여야 한다.
파드가 노드에서 실행될 때, kubelet은 각 활성화된 서비스에 대해
환경 변수 세트를 추가한다. [도커 링크
호환](https://docs.docker.com/userguide/dockerlinks/) 변수
-([makeLinkVariables](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L49) 참조)와
+([makeLinkVariables](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L49) 참조)와
보다 간단한 `{SVCNAME}_SERVICE_HOST` 및 `{SVCNAME}_SERVICE_PORT` 변수를 지원하고,
이때 서비스 이름은 대문자이고 대시는 밑줄로 변환된다.
@@ -752,7 +750,7 @@ TCP 및 SSL은 4 계층 프록시를 선택한다. ELB는 헤더를 수정하지
`443`, `8443`은 SSL 인증서를 사용하지만, `80`은 단순히
프록시만 하는 HTTP이다.
-쿠버네티스 v1.9부터는 서비스에 대한 HTTPS 또는 SSL 리스너와 함께 [사전에 정의된 AWS SSL 정책](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)을 사용할 수 있다.
+쿠버네티스 v1.9부터는 서비스에 대한 HTTPS 또는 SSL 리스너와 함께 [사전에 정의된 AWS SSL 정책](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)을 사용할 수 있다.
사용 가능한 정책을 확인하려면, `aws` 커맨드라인 툴을 사용한다.
```bash
@@ -887,7 +885,7 @@ AWS에서 네트워크 로드 밸런서를 사용하려면, `nlb` 값이 설정
```
{{< note >}}
-NLB는 특정 인스턴스 클래스에서만 작동한다. 지원되는 인스턴스 유형 목록은 엘라스틱 로드 밸런싱에 대한 [AWS 문서](http://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets)
+NLB는 특정 인스턴스 클래스에서만 작동한다. 지원되는 인스턴스 유형 목록은 엘라스틱 로드 밸런싱에 대한 [AWS 문서](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets)
를 참고한다.
{{< /note >}}
@@ -1044,8 +1042,8 @@ spec:
## 단점
VIP용으로 유저스페이스 프록시를 사용하면, 중소 급 스케일에서는 동작하지만, 수천 개의
-서비스가 포함된 대규모 클러스터로는 확장되지 않는다. [포털에 대한
-독창적인 설계 제안](http://issue.k8s.io/1107)에 이에 대한 자세한 내용이
+서비스가 포함된 대규모 클러스터로는 확장되지 않는다.
+[포털에 대한 독창적인 설계 제안](https://github.com/kubernetes/kubernetes/issues/1107)에 이에 대한 자세한 내용이
있다.
유저스페이스 프록시를 사용하면 서비스에 접근하는 패킷의 소스 IP 주소가
diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md
index c5a09d23e9..71e78eae96 100644
--- a/content/ko/docs/concepts/storage/persistent-volumes.md
+++ b/content/ko/docs/concepts/storage/persistent-volumes.md
@@ -13,9 +13,6 @@ weight: 20
이 페이지는 쿠버네티스의 _퍼시스턴트 볼륨_ 의 현재 상태를 설명한다. [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 익숙해지는 것을 추천한다.
-
-
-
## 소개
@@ -142,7 +139,11 @@ Events:
기본 볼륨 플러그인에서 지원하는 경우 `Recycle` 반환 정책은 볼륨에서 기본 스크럽(`rm -rf /thevolume/*`)을 수행하고 새 클레임에 다시 사용할 수 있도록 한다.
-그러나 관리자는 [여기](/docs/admin/kube-controller-manager/)에 설명된대로 쿠버네티스 컨트롤러 관리자 커맨드라인 인자(command line arguments)를 사용하여 사용자 정의 재활용 파드 템플릿을 구성할 수 있다. 사용자 정의 재활용 파드 템플릿에는 아래 예와 같이 `volumes` 명세가 포함되어야 한다.
+그러나 관리자는 [레퍼런스](/docs/reference/command-line-tools-reference/kube-controller-manager/)에
+설명된대로 쿠버네티스 컨트롤러 관리자 커맨드라인 인자(command line arguments)를
+사용하여 사용자 정의 재활용 파드 템플릿을 구성할 수 있다.
+사용자 정의 재활용 파드 템플릿에는 아래 예와 같이 `volumes` 명세가
+포함되어야 한다.
```yaml
apiVersion: v1
diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md
index 7df975db14..69b74ddefe 100644
--- a/content/ko/docs/concepts/storage/storage-classes.md
+++ b/content/ko/docs/concepts/storage/storage-classes.md
@@ -10,8 +10,6 @@ weight: 30
[볼륨](/ko/docs/concepts/storage/volumes/)과
[퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes)에 익숙해지는 것을 권장한다.
-
-
## 소개
diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md
index c93cc5018e..f57a003d13 100644
--- a/content/ko/docs/concepts/storage/volumes.md
+++ b/content/ko/docs/concepts/storage/volumes.md
@@ -15,9 +15,6 @@ kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상
[파드](/ko/docs/concepts/workloads/pods/pod/)에 대해 익숙해지는 것을 추천한다.
-
-
-
## 배경
@@ -95,7 +92,7 @@ kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상
### awsElasticBlockStore {#awselasticblockstore}
`awsElasticBlockStore` 볼륨은 아마존 웹 서비스 (AWS) [EBS
-볼륨](http://aws.amazon.com/ebs/)을 파드에 마운트 한다. 파드를
+볼륨](https://aws.amazon.com/ebs/)을 파드에 마운트 한다. 파드를
제거할 때 지워지는 `emptyDir` 와는 다르게 EBS 볼륨의
내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는 EBS 볼륨에
데이터를 미리 채울 수 있으며, 파드간에 데이터를 "전달(handed off)"
@@ -396,8 +393,8 @@ Flocker는 파드가 스케줄 되어있는 노드에 다시 연결한다. 이
### gcePersistentDisk {#gcepersistentdisk}
-`gcePersistentDisk` 볼륨은 구글 컴퓨트 엔진 (GCE) [퍼시스턴트
-디스크](http://cloud.google.com/compute/docs/disks)를 파드에 마운트 한다. 파드를
+`gcePersistentDisk` 볼륨은 구글 컴퓨트 엔진 (GCE)
+[퍼시스턴트 디스크](https://cloud.google.com/compute/docs/disks)를 파드에 마운트 한다. 파드를
제거할 때 지워지는 `emptyDir` 와는 다르게 PD의 내용은 유지되고,
볼륨은 마운트 해제만 된다. 이는 PD에 데이터를
미리 채울 수 있으며, 파드간에 데이터를 "전달(handed off)" 할 수 있다는 것을 의미한다.
@@ -532,7 +529,7 @@ spec:
### glusterfs {#glusterfs}
-`glusterfs` 볼륨을 사용하면 [Glusterfs](http://www.gluster.org) (오픈
+`glusterfs` 볼륨을 사용하면 [Glusterfs](https://www.gluster.org) (오픈
소스 네트워크 파일시스템) 볼륨을 파드에 마운트 할수 있다. 파드를
제거할 때 지워지는 `emptyDir` 와는 다르게 `glusterfs`
볼륨의 내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는
@@ -583,7 +580,7 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드간에 데
* 쿠버네티스가 계획한 대로 리소스 인식 스케줄링을 추가하면 `hostPath` 에서
사용되는 리소스를 설명할 수 없다.
* 기본 호스트에 생성된 파일 또는 디렉터리는 root만 쓸 수 있다.
- 프로세스를 [특권을 가진(privileged) 컨테이너](/docs/user-guide/security-context)에서
+ 프로세스를 [특권을 가진(privileged) 컨테이너](/docs/tasks/configure-pod-container/security-context/)에서
루트로 실행하거나
`hostPath` 볼륨에 쓸 수 있도록 호스트의 파일 권한을 수정해야 한다.
@@ -960,8 +957,8 @@ CSI 는 쿠버네티스 내에서 Quobyte 볼륨을 사용하기 위해 권장
### rbd {#rbd}
-`rbd` 볼륨을 사용하면 [Rados Block
-Device](http://ceph.com/docs/master/rbd/rbd/)를 파드에 마운트할 수
+`rbd` 볼륨을 사용하면
+[Rados Block Device](https://ceph.com/docs/master/rbd/rbd/)를 파드에 마운트할 수
있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 다르게 `rbd` 볼륨의
내용은 유지되고, 볼륨은 마운트 해제만 된다. 이
의미는 RBD 볼륨에 데이터를 미리 채울 수 있으며, 데이터를
@@ -1038,7 +1035,7 @@ tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토
업데이트를 수신하지 못한다.
{{< /note >}}
-시크릿에 대해서 [여기](/docs/user-guide/secrets)에 더 자세한 설명이 있다.
+시크릿에 대해서 [여기](/docs/concepts/configuration/secret/)에 더 자세한 설명이 있다.
### storageOS {#storageos}
@@ -1237,12 +1234,13 @@ spec:
사용할 수 있는 공간의 크기는 제한이 없으며, 컨테이너간 또는 파드간
격리는 없다.
-앞으로 `emptyDir` 과 `hostPath` 볼륨이 [리소스](/docs/user-guide/compute-resources)
+앞으로 `emptyDir` 과 `hostPath` 볼륨이 [리소스](/ko/docs/concepts/configuration/manage-resources-containers/)
사양을 사용해서 일정량의 공간을 요청하고, 여러 매체 유형이
있는 클러스터에 사용할 매체 유형을 선택할 수
있을 것으로 기대한다.
## 아웃 오브 트리 볼륨 플러그인
+
아웃 오브 트리 볼륨 플러그인에는 컨테이너 스토리지 인터페이스 (CSI) 그리고
FlexVolume이 포함된다. 스토리지 벤더들은 이 플러그인을 쿠버네티스 리포지터리에
추가하지 않고도 사용자 정의 스토리지 플러그인을 만들 수 있다.
@@ -1318,7 +1316,7 @@ CSI 호환 볼륨 드라이버가 쿠버네티스 클러스터에 배포되면
정의된 대로 CSI 드라이버의 `CreateVolumeResponse` 와 `volume.attributes`
필드에서 반환되는 매핑과 일치해야 한다.
이 매핑은 `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`,
- 그리고 `NodePublishVolumeRequest` 의 `volume_attributes` 필드를
+ 그리고 `NodePublishVolumeRequest` 의 `volume_context` 필드를
통해 CSI 드라이버로 전달된다.
- `controllerPublishSecretRef`: CSI의 `ControllerPublishVolume`
그리고 `ControllerUnpublishVolume` 호출을 완료하기 위해 CSI 드라이버에 전달하려는
diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md
index c06a43edf6..dca5a651f4 100644
--- a/content/ko/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md
@@ -20,9 +20,6 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도
더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만,
각기 다른 하드웨어 유형에 따라 서로 다른 플래그, 메모리, CPU 요구가 달라진다.
-
-
-
## 데몬셋 사양 작성
@@ -42,7 +39,8 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
### 필수 필드
다른 모든 쿠버네티스 설정과 마찬가지로 데몬셋에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다.
-일반적인 설정파일 작업에 대한 정보는 [애플리케이션 배포하기](/docs/user-guide/deploying-applications/),
+일반적인 설정파일 작업에 대한 정보는
+[스테이트리스 애플리케이션 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/),
[컨테이너 구성하기](/ko/docs/tasks/) 그리고 [kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다.
데몬셋 오브젝트의 이름은 유효한
@@ -54,7 +52,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
`.spec.template` 는 `.spec` 의 필수 필드 중 하나이다.
-`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#파드-템플릿)이다. 이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 [파드](/ko/docs/concepts/workloads/pods/pod/)와 정확히 같은 스키마를 가진다.
+`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 정확히 같은 스키마를 가진다.
데몬셋의 파드 템플릿에는 파드의 필수 필드 외에도 적절한 레이블이 명시되어야
한다([파드 셀렉터](#파드-셀렉터)를 본다).
@@ -65,7 +63,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
### 파드 셀렉터
`.spec.selector` 필드는 파드 셀렉터이다. 이것은
-[잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)의 `.spec.selector` 와 같은 동작을 한다.
+[잡](/ko/docs/concepts/workloads/controllers/job/)의 `.spec.selector` 와 같은 동작을 한다.
쿠버네티스 1.8 부터는 레이블이 `.spec.template` 와 일치하는 파드 셀렉터를 명시해야 한다.
파드 셀렉터는 비워두면 더 이상 기본 값이 설정이 되지 않는다.
diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md
index 91b20304c7..e782c7c60d 100644
--- a/content/ko/docs/concepts/workloads/controllers/deployment.md
+++ b/content/ko/docs/concepts/workloads/controllers/deployment.md
@@ -1,6 +1,4 @@
---
-
-
title: 디플로이먼트
feature:
title: 자동화된 롤아웃과 롤백
@@ -13,18 +11,15 @@ weight: 30
-_디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와
-[레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)에 대한 선언적 업데이트를 제공한다.
+_디플로이먼트(Deployment)_ 는 {{< glossary_tooltip text="파드" term_id="pod" >}}와
+{{< glossary_tooltip term_id="replica-set" text="레플리카셋(ReplicaSet)" >}}에 대한 선언적 업데이트를 제공한다.
-디플로이먼트에서 _의도하는 상태_ 를 설명하고, 디플로이먼트 {{< glossary_tooltip term_id="controller" >}} 는 현재 상태에서 의도하는 상태로 비율을 조정하며 변경한다. 새 레플리카셋을 생성하는 디플로이먼트를 정의하거나 기존 디플로이먼트를 제거하고, 모든 리소스를 새 디플로이먼트에 적용할 수 있다.
+디플로이먼트에서 _의도하는 상태_ 를 설명하고, 디플로이먼트 {{< glossary_tooltip term_id="controller" >}}는 현재 상태에서 의도하는 상태로 비율을 조정하며 변경한다. 새 레플리카셋을 생성하는 디플로이먼트를 정의하거나 기존 디플로이먼트를 제거하고, 모든 리소스를 새 디플로이먼트에 적용할 수 있다.
{{< note >}}
디플로이먼트가 소유하는 레플리카셋은 관리하지 말아야 한다. 사용자의 유스케이스가 다음에 포함되지 않는 경우 쿠버네티스 리포지터리에 이슈를 올릴 수 있다.
{{< /note >}}
-
-
-
## 유스케이스
@@ -1042,7 +1037,8 @@ echo $?
## 디플로이먼트 사양 작성
다른 모든 쿠버네티스 설정과 마찬가지로 디플로이먼트에는 `.apiVersion`, `.kind` 그리고 `.metadata` 필드가 필요하다.
-설정 파일 작업에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tutorials/stateless-application/run-stateless-application-deployment/),
+설정 파일 작업에 대한 일반적인 내용은
+[애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/),
컨테이너 구성하기 그리고 [kubectl을 사용해서 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참조한다.
디플로이먼트 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
@@ -1053,8 +1049,8 @@ echo $?
`.spec.template` 과 `.spec.selector` 은 `.spec` 에서 유일한 필수 필드이다.
-`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#파드-템플릿)이다.
-이것은 [파드](/ko/docs/concepts/workloads/pods/pod/)와 정확하게 동일한 스키마를 가지고 있고, 중첩된 것을 제외하면 `apiVersion` 과 `kind` 를 가지고 있지 않는다.
+`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다.
+이것은 {{< glossary_tooltip text="파드" term_id="pod" >}}와 정확하게 동일한 스키마를 가지고 있고, 중첩된 것을 제외하면 `apiVersion` 과 `kind` 를 가지고 있지 않는다.
파드에 필요한 필드 외에 디플로이먼트 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 명시해야 한다.
레이블의 경우 다른 컨트롤러와 겹치지 않도록 해야한다. 자세한 것은 [셀렉터](#셀렉터)를 참조한다.
@@ -1155,10 +1151,6 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설
이 기본 값은 0이다(파드는 준비되는 즉시 사용할 수 있는 것으로 간주됨).
파드가 준비되었다고 간주되는 시기에 대한 자세한 내용은 [컨테이너 프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)를 참조한다.
-### 롤백 대상
-
-`.spec.rollbackTo` 필드는 API 버전 `extensions/v1beta1` 과 `apps/v1beta1` 에서 사용되지 않는다. `apps/v1beta2` 로 시작하는 API 버전에서는 더 이상 지원되지 않는다. 대신, [이전 수정 버전으로 롤백](#이전-수정-버전으로-롤백)에서 소개한 `kubectl rollout undo` 를 사용해야 한다.
-
### 수정 버전 기록 제한
디플로이먼트의 수정 버전 기록은 자신이 컨트롤하는 레플리카셋에 저장된다.
diff --git a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md
index 03083b86ed..902326a9a4 100644
--- a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md
+++ b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md
@@ -111,12 +111,6 @@ metadata:
인수를 `propagationPolicy` 필드에 설정한다. 여기에 가능한 값으로는 "Orphan",
"Foreground" 또는 "Background" 이다.
-쿠버네티스 1.9 이전에는 많은 컨트롤러의 리소스에 대한 기본 가비지 수집 정책이 `orphan` 이었다.
-여기에는 레플리케이션컨트롤러, 레플리카셋, 스테이트풀셋, 데몬셋 그리고
-디플로이먼트가 포함된다. 그룹 버전 `extensions/v1beta1`, `apps/v1beta1` 그리고 `apps/v1beta2` 의 kinds에서는
-달리 지정하지 않는 한 오브젝트가 분리되는 것이 기본이다. 쿠버네티스 1.9에서는 그룹 버전 `apps/v1` 의 모든 kinds에 해당하는
-종속 오브젝트들이 기본적으로 삭제된다.
-
여기에 백그라운드에서 종속 항목을 삭제하는 예시가 있다.
```shell
diff --git a/content/ko/docs/concepts/workloads/controllers/job.md b/content/ko/docs/concepts/workloads/controllers/job.md
index 7b48a96c67..a77678a975 100644
--- a/content/ko/docs/concepts/workloads/controllers/job.md
+++ b/content/ko/docs/concepts/workloads/controllers/job.md
@@ -21,9 +21,6 @@ weight: 70
잡을 사용하면 여러 파드를 병렬로 실행할 수도 있다.
-
-
-
## 예시 잡 실행하기
@@ -119,7 +116,7 @@ kubectl logs $pods
`.spec.template` 은 `.spec` 의 유일한 필수 필드이다.
-`.spec.template` 은 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#파드-템플릿)이다. 이것은 `apiVersion` 또는 `kind` 가 없다는 것을 제외한다면 [파드](/ko/docs/concepts/workloads/pods/pod/)와 정확하게 같은 스키마를 가지고 있다.
+`.spec.template` 은 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 이것은 `apiVersion` 또는 `kind` 가 없다는 것을 제외한다면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 정확하게 같은 스키마를 가지고 있다.
추가로 파드의 필수 필드 외에도 잡의 파드 템플릿은 적절한
레이블([파드 셀렉터](#파드-셀렉터)를 본다)과 적절한 재시작 정책을 명시해야 한다.
@@ -211,7 +208,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
이렇게 하려면 `.spec.backoffLimit` 에 잡을 실패로 간주하기 이전에
재시도할 횟수를 설정한다. 백오프 제한은 기본적으로 6으로 설정되어 있다. 잡과
관련한 실패한 파드는 최대 6분안에서 기하급수적으로 증가하는 백-오프 지연 (10초, 20초, 40초 ...)
-한도가 되어 잡 컨트롤러에 의해 재생성된다. 잡의 파드가 삭제되거나
+한도가 되어 잡 컨트롤러에 의해 재생성된다. 잡의 파드가 삭제되거나
해당 시간 동안 잡에 대한 다른 파드가 실패 없이 성공했을 때 백 오프
카운트가 재설정된다.
diff --git a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
index c2414d9fdd..e800a253d7 100644
--- a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
@@ -20,9 +20,6 @@ _레플리케이션컨트롤러_ 는 언제든지 지정된 수의 파드 레플
실행 중임을 보장한다.
다시 말하면, 레플리케이션 컨트롤러는 파드 또는 동일 종류의 파드의 셋이 항상 기동되고 사용 가능한지 확인한다.
-
-
-
## 레플리케이션 컨트롤러의 동작방식
@@ -123,7 +120,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
`.spec.template` 는 오직 `.spec` 필드에서 요구되는 것이다.
-`.spec.template` 는 [파드 개요](/ko/docs/concepts/workloads/pods/pod-overview/#파드-템플릿) 이다. 정확하게 [파드](/ko/docs/concepts/workloads/pods/pod/) 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다.
+`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿) 이다. 정확하게 {{< glossary_tooltip text="파드" term_id="pod" >}} 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다.
파드에 필요한 필드 외에도 레플리케이션 컨트롤러의 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 지정해야 한다. 레이블의 경우 다른 컨트롤러와
중첩되지 않도록 하라. [파드 셀렉터](#파드-셀렉터)를 참조하라.
@@ -131,7 +128,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
오직 `Always` 와 동일한 [`.spec.template.spec.restartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책) 만 허용되며, 특별히 지정되지 않으면 기본값이다.
로컬 컨테이너의 재시작의 경우, 레플리케이션 컨트롤러는 노드의 에이전트에게 위임한다.
-예를 들어 [Kubelet](/docs/admin/kubelet/) 혹은 도커이다.
+예를 들어 [Kubelet](/docs/reference/command-line-tools-reference/kubelet/) 혹은 도커이다.
### 레플리케이션 컨트롤러에서 레이블
@@ -211,7 +208,7 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히
레플리케이션 컨트롤러는 파드를 하나씩 교체함으로써 서비스에 대한 롤링 업데이트를 쉽게 하도록 설계되었다.
-[#1353](http://issue.k8s.io/1353) 에서 설명한 것처럼, 권장되는 접근법은 1 개의 레플리카를 가진 새로운 레플리케이션 컨트롤러를 생성하고 새로운 (+1) 컨트롤러 및 이전 (-1) 컨트롤러를 차례대로 스케일한 후 0개의 레플리카가 되면 이전 컨트롤러를 삭제하는 것이다. 예상치 못한 오류와 상관없이 파드 세트를 예측 가능하게 업데이트한다.
+[#1353](https://issue.k8s.io/1353) 에서 설명한 것처럼, 권장되는 접근법은 1 개의 레플리카를 가진 새로운 레플리케이션 컨트롤러를 생성하고 새로운 (+1) 컨트롤러 및 이전 (-1) 컨트롤러를 차례대로 스케일한 후 0개의 레플리카가 되면 이전 컨트롤러를 삭제하는 것이다. 예상치 못한 오류와 상관없이 파드 세트를 예측 가능하게 업데이트한다.
이상적으로 롤링 업데이트 컨트롤러는 애플리케이션 준비 상태를 고려하며 주어진 시간에 충분한 수의 파드가 생산적으로 제공되도록 보장할 것이다.
@@ -236,11 +233,11 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히
## 레플리케이션 컨트롤러의 책임
-레플리케이션 컨트롤러는 의도한 수의 파드가 해당 레이블 선택기와 일치하고 동작하는지를 단순히 확인한다. 현재, 종료된 파드만 해당 파드의 수에서 제외된다. 향후 시스템에서 사용할 수 있는 [readiness](http://issue.k8s.io/620) 및 기타 정보가 고려될 수 있으며 교체 정책에 대한 통제를 더 추가 할 수 있고 외부 클라이언트가 임의로 정교한 교체 또는 스케일 다운 정책을 구현하기 위해 사용할 수 있는 이벤트를 내보낼 계획이다.
+레플리케이션 컨트롤러는 의도한 수의 파드가 해당 레이블 선택기와 일치하고 동작하는지를 단순히 확인한다. 현재, 종료된 파드만 해당 파드의 수에서 제외된다. 향후 시스템에서 사용할 수 있는 [readiness](https://issue.k8s.io/620) 및 기타 정보가 고려될 수 있으며 교체 정책에 대한 통제를 더 추가 할 수 있고 외부 클라이언트가 임의로 정교한 교체 또는 스케일 다운 정책을 구현하기 위해 사용할 수 있는 이벤트를 내보낼 계획이다.
-레플리케이션 컨트롤러는 이 좁은 책임에 영원히 제약을 받는다. 그 자체로는 준비성 또는 활성 프로브를 실행하지 않을 것이다. 오토 스케일링을 수행하는 대신, 외부 오토 스케일러 ([#492](http://issue.k8s.io/492)에서 논의된) 가 레플리케이션 컨트롤러의 `replicas` 필드를 변경함으로써 제어되도록 의도되었다. 레플리케이션 컨트롤러에 스케줄링 정책 (예를 들어 [spreading](http://issue.k8s.io/367#issuecomment-48428019)) 을 추가하지 않을 것이다. 오토사이징 및 기타 자동화 된 프로세스를 방해할 수 있으므로 제어된 파드가 현재 지정된 템플릿과 일치하는지 확인해야 한다. 마찬가지로 기한 완료, 순서 종속성, 구성 확장 및 기타 기능은 다른 곳에 속한다. 대량의 파드 생성 메커니즘 ([#170](http://issue.k8s.io/170)) 까지도 고려해야 한다.
+레플리케이션 컨트롤러는 이 좁은 책임에 영원히 제약을 받는다. 그 자체로는 준비성 또는 활성 프로브를 실행하지 않을 것이다. 오토 스케일링을 수행하는 대신, 외부 오토 스케일러 ([#492](https://issue.k8s.io/492)에서 논의된) 가 레플리케이션 컨트롤러의 `replicas` 필드를 변경함으로써 제어되도록 의도되었다. 레플리케이션 컨트롤러에 스케줄링 정책 (예를 들어 [spreading](https://issue.k8s.io/367#issuecomment-48428019)) 을 추가하지 않을 것이다. 오토사이징 및 기타 자동화 된 프로세스를 방해할 수 있으므로 제어된 파드가 현재 지정된 템플릿과 일치하는지 확인해야 한다. 마찬가지로 기한 완료, 순서 종속성, 구성 확장 및 기타 기능은 다른 곳에 속한다. 대량의 파드 생성 메커니즘 ([#170](https://issue.k8s.io/170)) 까지도 고려해야 한다.
-레플리케이션 컨트롤러는 조합 가능한 빌딩-블록 프리미티브가 되도록 고안되었다. 향후 사용자의 편의를 위해 더 상위 수준의 API 및/또는 도구와 그리고 다른 보완적인 기본 요소가 그 위에 구축 될 것으로 기대한다. 현재 kubectl이 지원하는 "매크로" 작업 (실행, 스케일)은 개념 증명의 예시이다. 예를 들어 [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) 와 같이 레플리케이션 컨트롤러, 오토 스케일러, 서비스, 정책 스케줄링, 카나리 등을 관리할 수 있다.
+레플리케이션 컨트롤러는 조합 가능한 빌딩-블록 프리미티브가 되도록 고안되었다. 향후 사용자의 편의를 위해 더 상위 수준의 API 및/또는 도구와 그리고 다른 보완적인 기본 요소가 그 위에 구축 될 것으로 기대한다. 현재 kubectl이 지원하는 "매크로" 작업 (실행, 스케일)은 개념 증명의 예시이다. 예를 들어 [Asgard](https://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) 와 같이 레플리케이션 컨트롤러, 오토 스케일러, 서비스, 정책 스케줄링, 카나리 등을 관리할 수 있다.
## API 오브젝트
@@ -280,4 +277,4 @@ API 오브젝트에 대한 더 자세한 것은
## 더 자세한 정보는
-[스테이트리스 애플리케이션 레플리케이션 컨트롤러 실행하기](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/)를 참고한다.
+[스테이트리스 애플리케이션 디플로이먼트 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/)를 참고한다.
diff --git a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md
index 3d110ee6c6..a941266230 100644
--- a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md
+++ b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md
@@ -18,12 +18,6 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
kube-apiserver와 kube-controller-manager와 함께
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)로 `TTLAfterFinished` 를 활성화할 수 있다.
-
-
-
-
-
-
## TTL 컨트롤러
@@ -80,7 +74,6 @@ TTL 컨트롤러는 쿠버네티스 리소스에
## {{% heading "whatsnext" %}}
+* [자동으로 잡 정리](/ko/docs/concepts/workloads/controllers/job/#완료된-잡을-자동으로-정리)
-[자동으로 잡 정리](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/#완료된-잡을-자동으로-정리)
-
-[디자인 문서](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
+* [디자인 문서](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
diff --git a/content/ko/docs/concepts/workloads/pods/_index.md b/content/ko/docs/concepts/workloads/pods/_index.md
index 35ded5ad4a..42e0b14607 100644
--- a/content/ko/docs/concepts/workloads/pods/_index.md
+++ b/content/ko/docs/concepts/workloads/pods/_index.md
@@ -1,4 +1,269 @@
---
-title: "파드"
+title: 파드
+content_type: concept
weight: 10
+no_list: true
+card:
+ name: concepts
+ weight: 60
---
+
+
+
+_파드(Pod)_ 는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다.
+
+_파드_ (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로)는 하나 이상의
+{{< glossary_tooltip text="컨테이너" term_id="container" >}}의 그룹이다.
+이 그룹은 스토리지/네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. 파드의 콘텐츠는 항상 함께 배치되고,
+함께 스케줄되며, 공유 콘텍스트에서 실행된다. 파드는
+애플리케이션 별 "논리 호스트"를 모델링한다. 여기에는 상대적으로 밀접하게 결합된 하나 이상의
+애플리케이션 컨테이너가 포함된다.
+클라우드가 아닌 콘텍스트에서, 동일한 물리 또는 가상 머신에서 실행되는 애플리케이션은 동일한 논리 호스트에서 실행되는 클라우드 애플리케이션과 비슷하다.
+
+애플리케이션 컨테이너와 마찬가지로, 파드에는
+파드 시작 중에 실행되는 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)가
+포함될 수 있다. 클러스터가 제공하는 경우, 디버깅을 위해
+[임시 컨테이너](/ko/docs/concepts/workloads/pods/ephemeral-containers/)를
+삽입할 수도 있다.
+
+
+
+## 파드란 무엇인가?
+
+{{< note >}}
+[도커](https://www.docker.com/)가 가장 일반적으로
+잘 알려진 런타임이지만, 쿠버네티스는 도커보다
+{{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}을
+더 많이 지원하며, 도커의 일부 용어를 사용하면 파드를 설명하는 데 도움이 된다.
+{{< /note >}}
+
+파드의 공유 콘텍스트는 리눅스 네임스페이스, 컨트롤 그룹(cgroup) 및
+도커 컨테이너를 격리하는 것과 같이 잠재적으로 다른 격리 요소들이다.
+파드의 콘텍스트 내에서 개별 애플리케이션은
+추가적으로 하위 격리가 적용된다.
+
+도커 개념 측면에서, 파드는 공유 네임스페이스와 공유 파일시스템 볼륨이
+있는 도커 컨테이너 그룹과 비슷하다.
+
+## 파드의 사용
+
+일반적으로 싱글톤(singleton) 파드를 포함하여 파드를 직접 만들 필요가 없다. 대신, {{< glossary_tooltip text="디플로이먼트(Deployment)"
+term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="job" >}}과 같은 워크로드 리소스를 사용하여 생성한다.
+파드가 상태를 추적해야 한다면,
+{{< glossary_tooltip text="스테이트풀셋(StatefulSet)" term_id="statefulset" >}} 리소스를 고려한다.
+
+쿠버네티스 클러스터의 파드는 두 가지 주요 방식으로 사용된다.
+
+* **단일 컨테이너를 실행하는 파드**. "파드 당 하나의 컨테이너" 모델은
+ 가장 일반적인 쿠버네티스 유스케이스이다. 이 경우, 파드를 단일 컨테이너를 둘러싼
+ 래퍼(wrapper)로 생각할 수 있다. 쿠버네티스는 컨테이너를 직접 관리하는 대신
+ 파드를 관리한다.
+* **함께 작동해야 하는 여러 컨테이너를 실행하는 파드**. 파드는
+ 밀접하게 결합되어 있고 리소스를 공유해야 하는 함께 배치된 여러 개의 컨테이너로
+ 구성된 애플리케이션을 캡슐화할 수 있다. 이런 함께 배치된 컨테이너는
+ 하나의 결합된 서비스 단위를 형성한다. 예를 들어, 하나의 컨테이너는 공유 볼륨에
+ 저장된 데이터를 퍼블릭에 제공하는 반면, 별도의 _사이드카_ 컨테이너는
+ 해당 파일을 새로 고치거나 업데이트한다.
+ 파드는 이러한 컨테이너, 스토리지 리소스, 임시 네트워크 ID를
+ 단일 단위로 함께 래핑한다.
+
+ {{< note >}}
+ 단일 파드에서 함께 배치된 또는 함께 관리되는 여러 컨테이너를 그룹화하는 것은
+ 비교적 고급 유스케이스이다. 이 패턴은 컨테이너가 밀접하게 결합된
+ 특정 인스턴스에서만 사용해야 한다.
+ {{< /note >}}
+
+각 파드는 특정 애플리케이션의 단일 인스턴스를 실행하기 위한 것이다. 더 많은
+인스턴스를 실행하여 더 많은 전체 리소스를 제공하기 위해 애플리케이션을
+수평적으로 확장하려면, 각 인스턴스에 하나씩, 여러 파드를 사용해야 한다.
+쿠버네티스에서는 이를 일반적으로 _레플리케이션_ 이라고 한다.
+복제된 파드는 일반적으로 워크로드 리소스와
+해당 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}에 의해 그룹으로 생성되고 관리된다.
+
+쿠버네티스가 워크로드 리소스와 해당 컨트롤러를 사용하여 애플리케이션 스케일링과
+자동 복구를 구현하는 방법에 대한 자세한 내용은
+[파드와 컨트롤러](#파드와-컨트롤러)를 참고한다.
+
+### 파드가 여러 컨테이너를 관리하는 방법
+
+파드는 응집력있는 서비스 단위를 형성하는 여러 협력 프로세스(컨테이너)를
+지원하도록 설계되었다. 파드의 컨테이너는 클러스터의 동일한 물리 또는 가상 머신에서
+자동으로 같은 위치에 배치되고 함께 스케줄된다. 컨테이너는
+리소스와 의존성을 공유하고, 서로 통신하고, 종료 시기와 방법을
+조정할 수 있다.
+
+예를 들어, 다음 다이어그램에서와 같이
+공유 볼륨의 파일에 대한 웹 서버 역할을 하는 컨테이너와, 원격 소스에서 해당 파일을 업데이트하는
+별도의 "사이드카" 컨테이너가 있을 수 있다.
+
+{{< figure src="/images/docs/pod.svg" alt="예제 파드 다이어그램" width="50%" >}}
+
+일부 파드에는 {{< glossary_tooltip text="앱 컨테이너" term_id="app-container" >}} 뿐만 아니라 {{< glossary_tooltip text="초기화 컨테이너" term_id="init-container" >}}를 갖고 있다. 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 실행되고 완료된다.
+
+파드는 기본적으로 파드에 속한 컨테이너에 [네트워킹](#파드-네트워킹)과 [스토리지](#pod-storage)라는
+두 가지 종류의 공유 리소스를 제공한다.
+
+## 파드 작업
+
+사용자가 쿠버네티스에서 직접 개별 파드를 만드는 경우는 거의 없다. 싱글톤 파드도 마찬가지이다. 이는
+파드가 상대적으로 일시적인, 일회용 엔티티로 설계되었기 때문이다. 파드가
+생성될 때(사용자가 직접 또는
+{{< glossary_tooltip text="컨트롤러" term_id="controller" >}}가 간접적으로), 새 파드는
+클러스터의 {{< glossary_tooltip text="노드" term_id="node" >}}에서 실행되도록 스케줄된다.
+파드는 파드 실행이 완료되거나, 파드 오브젝트가 삭제되거나,
+리소스 부족으로 인해 파드가 *축출* 되거나, 노드가 실패할 때까지 해당 노드에 남아있다.
+
+{{< note >}}
+파드에서 컨테이너를 다시 시작하는 것과 파드를 다시 시작하는 것을 혼동해서는 안된다. 파드는
+프로세스가 아니라 컨테이너를 실행하기 위한 환경이다. 파드는
+삭제될 때까지 유지된다.
+{{< /note >}}
+
+파드 오브젝트에 대한 매니페스트를 만들 때, 지정된 이름이 유효한
+[DNS 하위 도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인한다.
+
+### 파드와 컨트롤러
+
+워크로드 리소스를 사용하여 여러 파드를 만들고 관리할 수 있다. 리소스에 대한 컨트롤러는
+파드 장애 시 복제 및 롤아웃과 자동 복구를
+처리한다. 예를 들어, 노드가 실패하면, 컨트롤러는 해당 노드의 파드가 작동을 중지했음을
+인식하고 대체 파드를 생성한다. 스케줄러는
+대체 파드를 정상 노드에 배치한다.
+
+다음은 하나 이상의 파드를 관리하는 워크로드 리소스의 몇 가지 예시이다.
+
+* {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}
+* {{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}}
+* {{< glossary_tooltip text="데몬셋(DaemonSet)" term_id="daemonset" >}}
+
+### 파드 템플릿
+
+{{< glossary_tooltip text="워크로드" term_id="workload" >}} 리소스에 대한 컨트롤러는
+_파드 템플릿_ 에서 파드를 생성하고 사용자 대신 해당 파드를 관리한다.
+
+파드템플릿(PodTemplate)은 파드를 생성하기 위한 명세이며,
+[디플로이먼트](/docs/concepts/workloads/controllers/deployment/),
+[잡](/docs/concepts/jobs/run-to-completion-finite-workloads/) 및
+[데몬셋](/docs/concepts/workloads/controllers/daemonset/)과 같은 워크로드 리소스에 포함된다.
+
+워크로드 리소스의 각 컨트롤러는 워크로드 오브젝트 내부의 `PodTemplate` 을
+사용하여 실제 파드를 생성한다. `PodTemplate` 은 앱을 실행하는 데 사용되는 워크로드 리소스가
+무엇이든지 원하는 상태의 일부이다.
+
+아래 샘플은 하나의 컨테이너를 시작하는 `template` 이 있는 간단한 잡의
+매니페스트이다. 해당 파드의 컨테이너는 메시지를 출력한 다음 일시 중지한다.
+
+```yaml
+apiVersion: batch/v1
+kind: Job
+metadata:
+ name: hello
+spec:
+ template:
+ # 여기서부터 파드 템플릿이다
+ spec:
+ containers:
+ - name: hello
+ image: busybox
+ command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
+ restartPolicy: OnFailure
+ # 여기까지 파드 템플릿이다
+```
+
+파드 템플릿을 수정하거나 새로운 파드 템플릿으로 바꿔도 이미 존재하는
+파드에는 영향을 주지 않는다. 파드는 템플릿 업데이트를 직접 받지 않는다. 대신,
+수정된 파드 템플릿과 일치하는 새로운 파드가 생성된다.
+
+예를 들어, 디플로이먼트 컨트롤러는 실행 중인 파드가 각 디플로이먼트 오브젝트에 대한 현재
+파드 템플릿과 일치하는지 확인한다. 템플릿이 업데이트된 경우, 디플로이먼트는
+기존 파드를 제거하고 업데이트된 템플릿을 기반으로 새로운 파드를 생성해야 한다. 각 워크로드
+리소스는 파드 템플릿의 변경 사항을 처리하기 위한 자체 규칙을 구현한다.
+
+노드에서 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}은
+파드 템플릿과 업데이트에 대한 상세 정보를 직접 관찰하거나 관리하지 않는다. 이러한
+상세 내용은 추상화된다. 이러한 추상화와 관심사 분리(separation of concerns)는
+시스템 시맨틱을 단순화하고, 기존 코드를 변경하지 않고도 클러스터의 동작을
+확장할 수 있게 한다.
+
+## 리소스 공유와 통신
+
+파드는 파드에 속한 컨테이너 간의 데이터 공유와 통신을
+지원한다.
+
+### 파드 스토리지 {#pod-storage}
+
+파드는 공유 스토리지 {{< glossary_tooltip text="볼륨" term_id="volume" >}}의
+집합을 지정할 수 있다. 파드의 모든 컨테이너는
+공유 볼륨에 접근할 수 있으므로, 해당 컨테이너가 데이터를 공유할 수
+있다. 또한 볼륨은 내부 컨테이너 중 하나를 다시
+시작해야 하는 경우 파드의 영구 데이터를 유지하도록 허용한다.
+쿠버네티스가 공유 스토리지를 구현하고 파드에서 사용할 수 있도록 하는 방법에 대한
+자세한 내용은 [스토리지](/ko/docs/concepts/storage/)를 참고한다.
+
+### 파드 네트워킹
+
+각 파드에는 각 주소 패밀리에 대해 고유한 IP 주소가 할당된다. 파드의
+모든 컨테이너는 IP 주소와 네트워크 포트를 포함하여 네트워크 네임스페이스를
+공유한다. 파드 내부(그때 **만** 해당)에서, 파드에 속한
+컨테이너는 `localhost` 를 사용하여 서로 통신할 수 있다. 파드의 컨테이너가
+*파드 외부의* 엔티티와 통신할 때,
+공유 네트워크 리소스(포트와 같은)를 사용하는 방법을 조정해야 한다.
+파드 내에서 컨테이너는 IP 주소와 포트 공간을 공유하며,
+`localhost` 를 통해 서로를 찾을 수 있다. 파드의 컨테이너는 SystemV 세마포어 또는
+POSIX 공유 메모리와 같은 표준 프로세스 간 통신을 사용하여 서로
+통신할 수도 있다. 다른 파드의 컨테이너는
+고유한 IP 주소를 가지며
+[특별한 구성](/ko/docs/concepts/policy/pod-security-policy/) 없이 IPC로 통신할 수 없다.
+다른 파드에서 실행되는 컨테이너와 상호 작용하려는 컨테이너는 IP 네트워킹을
+사용하여 통신할 수 있다.
+
+파드 내의 컨테이너는 시스템 호스트명이 파드에 대해 구성된
+`name` 과 동일한 것으로 간주한다. [네트워킹](/ko/docs/concepts/cluster-administration/networking/) 섹션에 이에 대한
+자세한 내용이 있다.
+
+## 컨테이너에 대한 특권 모드
+
+파드의 모든 컨테이너는 컨테이너 명세의 [보안 콘텍스트](/docs/tasks/configure-pod-container/security-context/)에 있는 `privileged` 플래그를 사용하여 특권 모드를 활성화할 수 있다. 이는 네트워크 스택 조작이나 하드웨어 장치 접근과 같은 운영 체제 관리 기능을 사용하려는 컨테이너에 유용하다.
+특권이 있는 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스가 가지는 거의 동일한 권한을 가진다.
+
+{{< note >}}
+이 설정을 사용하려면 사용자의 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}이 특권이 있는 컨테이너의 개념을 지원해야 한다.
+{{< /note >}}
+
+## 정적 파드
+
+_정적 파드_ 는 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}가
+관찰하는 대신 특정 노드의 kubelet 데몬에 의해 직접
+관리된다.
+대부분의 파드는 컨트롤 플레인(예를 들어,
+{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}})에 의해 관리되고, 정적 파드의
+경우, kubelet이 각 정적 파드를 직접 감독한다(실패하면 다시 시작한다).
+
+정적 파드는 항상 특정 노드의 {{< glossary_tooltip term_id="kubelet" >}} 하나에 바인딩된다.
+정적 파드의 주요 용도는 자체 호스팅 컨트롤 플레인을 실행하는 것이다. 즉,
+kubelet을 사용하여 개별 [컨트롤 플레인 컴포넌트](/ko/docs/concepts/overview/components/#컨트롤-플레인-컴포넌트)를 감독한다.
+
+kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버에서 {{< glossary_tooltip text="미러 파드" term_id="mirror-pod" >}}를
+생성하려고 한다.
+즉, 노드에서 실행되는 파드는 API 서버에서 보이지만,
+여기에서 제어할 수는 없다는 의미이다.
+
+## {{% heading "whatsnext" %}}
+
+* [파드의 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에 대해 알아본다.
+* [PodPresets](/ko/docs/concepts/workloads/pods/podpreset/)에 대해 알아본다.
+* [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)와 이를 사용하여
+ 다양한 컨테이너 런타임 구성으로 다양한 파드를 설정하는 방법에 대해 알아본다.
+* [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽어본다.
+* [PodDisruptionBudget](https://kubernetes.io/ko/docs/concepts/workloads/pods/disruptions/)과 이를 사용하여 서비스 중단 중에 애플리케이션 가용성을 관리하는 방법에 대해 읽어본다.
+* 파드는 쿠버네티스 REST API의 최상위 리소스이다.
+ [파드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
+ 오브젝트 정의는 오브젝트를 상세히 설명한다.
+* [분산 시스템 툴킷: 컴포지트 컨테이너에 대한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)은 둘 이상의 컨테이너가 있는 파드의 일반적인 레이아웃을 설명한다.
+
+쿠버네티스가 다른 리소스({{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}}이나 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}와 같은)에서 공통 파드 API를 래핑하는 이유에 대한 콘텍스트를 이해하기 위해서, 다음을 포함한 선행 기술에 대해 읽어볼 수 있다.
+ * [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
+ * [Borg](https://research.google.com/pubs/pub43438.html)
+ * [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
+ * [Omega](https://research.google/pubs/pub41684/)
+ * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/).
diff --git a/content/ko/docs/concepts/workloads/pods/disruptions.md b/content/ko/docs/concepts/workloads/pods/disruptions.md
index 0e46b4bf5e..5f13dddef9 100644
--- a/content/ko/docs/concepts/workloads/pods/disruptions.md
+++ b/content/ko/docs/concepts/workloads/pods/disruptions.md
@@ -12,9 +12,6 @@ weight: 60
또한 클러스터의 업그레이드와 오토스케일링과 같은
클러스터의 자동화 작업을 하려는 관리자를 위한 것이다.
-
-
-
## 자발적 중단과 비자발적 중단
@@ -44,7 +41,7 @@ weight: 60
- 재시작을 유발하는 디플로이먼트의 파드 템플릿 업데이트
- 파드를 직접 삭제(예: 우연히)
-클러스터 관리자의 작업:
+클러스터 관리자의 작업은 다음을 포함한다.
- 복구 또는 업그레이드를 위한 [노드 드레이닝](/docs/tasks/administer-cluster/safely-drain-node/).
- 클러스터의 스케일 축소를 위한
@@ -68,7 +65,7 @@ weight: 60
비자발적인 중단으로 인한 영향을 경감하기 위한 몇 가지 방법은 다음과 같다.
-- 파드가 필요로 하는 [리소스를 요청](/docs/tasks/configure-pod-container/assign-cpu-ram-container)하는지 확인한다.
+- 파드가 필요로 하는 [리소스를 요청](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)하는지 확인한다.
- 고가용성이 필요한 경우 애플리케이션을 복제한다.
(복제된 [스테이트리스](/docs/tasks/run-application/run-stateless-application-deployment/) 및
[스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/) 애플리케이션에 대해 알아보기.)
@@ -86,58 +83,57 @@ weight: 60
클러스터 관리자 또는 호스팅 공급자는
예측 가능한 자발적 중단 수준에 대해 문서화해야 한다.
-쿠버네티스는 자주 발생하는 자발적 중단에도 고가용성 애플리케이션을
-실행 할 수 있는 기능을 제공한다.
-우리는 이 기능을 *Disruption Budgets* 이라 부른다.
-
-
-## Disruption Budgets의 작동 방식
+## 파드 disruption budgets
{{< feature-state for_k8s_version="v1.5" state="beta" >}}
-애플리케이션 소유자는 각 애플리케이션에 대해 `PodDisruptionBudget` 오브젝트(PDB)를 만들 수 있다.
+쿠버네티스는 자발적인 중단이 자주 발생하는 경우에도 고 가용성 애플리케이션을
+실행하는 데 도움이 되는 기능을 제공한다.
+
+애플리케이션 소유자로써, 사용자는 각 애플리케이션에 대해 PodDisruptionBudget(PDB)을 만들 수 있다.
PDB는 자발적 중단으로
일시에 중지되는 복제된 애플리케이션 파드의 수를 제한한다.
-예를 들어 정족수 기반의 애플리케이션이
+예를 들어, 정족수 기반의 애플리케이션이
실행 중인 레플리카의 수가 정족수 이하로 떨어지지 않도록 한다.
웹 프런트 엔드는 부하를 처리하는 레플리카의 수가
일정 비율 이하로 떨어지지 않도록 보장할 수 있다.
클러스터 관리자와 호스팅 공급자는 직접적으로 파드나 디플로이먼트를 제거하는 대신
[Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)로
-불리는 Pod Disruption Budget을 준수하는 도구를 이용해야 한다.
-예를 들어 `kubectl drain` 명령어나 Kubernetes-on-GCE 클러스터 업그레이드 스크립트(`cluster/gce/upgrade.sh`)이다.
+불리는 PodDisruptionBudget을 준수하는 도구를 이용해야 한다.
-클러스터 관리자가 노드를 비우고자 할 경우에는 `kubectl drain` 명령어를 사용한다.
-해당 도구는 머신에 존재하는 모든 파드를 축출하려는 시도를 한다.
+예를 들어, `kubectl drain` 하위 명령을 사용하면 노드를 서비스 중단으로 표시할 수
+있다. `kubectl drain` 을 실행하면, 도구는 사용자가 서비스를 중단하는 노드의
+모든 파드를 축출하려고 한다. `kubectl` 이 사용자를 대신하여 수행하는
축출 요청은 일시적으로 거부될 수 있으며,
-도구는 모든 파드가 종료되거나
+도구는 대상 노드의 모든 파드가 종료되거나
설정 가능한 타임아웃이 도래할 때까지 주기적으로 모든 실패된 요청을 다시 시도한다.
PDB는 애플리케이션이 필요로 하는 레플리카의 수에 상대적으로, 용인할 수 있는 레플리카의 수를 지정한다.
예를 들어 `.spec.replicas: 5` 의 값을 갖는 디플로이먼트는 어느 시점에든 5개의 파드를 가져야 한다.
만약 해당 디플로이먼트의 PDB가 특정 시점에 파드를 4개 허용한다면,
-Eviction API는 한 번에 2개의 파드가 아닌, 1개의 파드의 자발적인 중단을 허용한다.
+Eviction API는 한 번에 1개(2개의 파드가 아닌)의 파드의 자발적인 중단을 허용한다.
파드 그룹은 레이블 셀렉터를 사용해서 지정한 애플리케이션으로 구성되며
애플리케이션 컨트롤러(디플로이먼트, 스테이트풀셋 등)를 사용한 것과 같다.
-파드의 "의도"하는 수량은 파드 컨트롤러의 `.spec.replicas` 를 기반으로 계산한다.
-컨트롤러는 오브젝트의 `.metadata.ownerReferences` 를 사용해서 파드를 발견한다.
+파드의 "의도"하는 수량은 해당 파드를 관리하는 워크로드 리소스의 `.spec.replicas` 를
+기반으로 계산한다. 컨트롤 플레인은 파드의 `.metadata.ownerReferences` 를 검사하여
+소유하는 워크로드 리소스를 발견한다.
PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생하는 것을 막을 수는 없지만,
버짓이 차감된다.
애플리케이션의 롤링 업그레이드로 파드가 삭제되거나 사용할 수 없는 경우 중단 버짓에 영향을 준다.
-그러나 컨트롤러(디플로이먼트, 스테이트풀셋과 같은)는
-롤링 업데이트시 PDB의 제한을 받지 않는다.
-애플리케이션 업데이트 진행 중 발생하는 중단 처리는 컨트롤러 사양에 구성되어있다.
-([디플로이먼트 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-업데이트)에 대해 알아보기.)
+그러나 워크로드 리소스(디플로이먼트, 스테이트풀셋과 같은)는
+롤링 업데이트 시 PDB의 제한을 받지 않는다. 대신, 애플리케이션 업데이트 중
+실패 처리는 특정 워크로드 리소스에 대한 명세에서 구성된다.
-파드를 Eviction API로 축출하면 정상적으로 종료된다.
-([파드사양](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)에서 `terminationGracePeriodSeconds` 를 참조.)
+Eviction API를 사용하여 파드를 축출하면,
+[PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)의
+`terminationGracePeriodSeconds` 설정을 준수하여 정상적으로 [종료됨](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-종료) 상태가 된다.)
-## PDB 예시
+## PodDisruptionBudget 예시 {#pdb-example}
`node-1` 부터 `node-3` 까지 3개의 노드가 있는 클러스터가 있다고 하자.
클러스터에는 여러 애플리케이션을 실행하고 있다.
@@ -267,3 +263,6 @@ Pod Disruption Budget을 사용할 필요가 없다.
* [Pod Disruption Budget 설정하기](/docs/tasks/run-application/configure-pdb/)의 단계를 따라서 애플리케이션을 보호한다.
* [노드 비우기](/docs/tasks/administer-cluster/safely-drain-node/)에 대해 자세히 알아보기
+
+* 롤아웃 중에 가용성을 유지하는 단계를 포함하여
+ [디플로이먼트 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-업데이트)에 대해 알아보기
diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
index 379266e351..43d54aff46 100644
--- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -6,17 +6,61 @@ weight: 30
-{{< comment >}}Updated: 4/14/2015{{< /comment >}}
-{{< comment >}}Edited and moved to Concepts section: 2/2/17{{< /comment >}}
-
-이 페이지는 파드의 라이프사이클을 설명한다.
+이 페이지에서는 파드의 라이프사이클을 설명한다. 파드는 정의된 라이프사이클을 따른다.
+`Pending` [단계](#파드의-단계)에서 시작해서, 기본 컨테이너 중 적어도 하나
+이상이 OK로 시작하면 `Running` 단계를 통과하고, 그런 다음 파드의 컨테이너가
+실패로 종료되었는지 여부에 따라 `Succeeded` 또는 `Failed` 단계로 이동한다.
+파드가 실행되는 동안, kubelet은 일종의 오류를 처리하기 위해 컨테이너를 다시
+시작할 수 있다. 파드 내에서, 쿠버네티스는 다양한 컨테이너
+[상태](#컨테이너-상태)와 핸들을 추적한다.
+쿠버네티스 API에서 파드는 명세와 실제 상태를 모두 가진다.
+파드 오브젝트의 상태는 일련의 [파드 조건](#파드의-조건)으로 구성된다.
+사용자의 애플리케이션에 유용한 경우, 파드의 조건 데이터에
+[사용자 정의 준비성 정보](#pod-readiness-gate)를 삽입할 수도 있다.
+파드는 파드의 수명 중 한 번만 [스케줄](/ko/docs/concepts/scheduling-eviction/)된다.
+파드가 노드에 스케줄(할당)되면, 파드는 중지되거나 [종료](#pod-termination)될 때까지
+해당 노드에서 실행된다.
-## 파드의 단계(phase)
+## 파드의 수명
+
+개별 애플리케이션 컨테이너와 마찬가지로, 파드는 비교적
+임시(계속 이어지는 것이 아닌) 엔티티로 간주된다. 파드가 생성되고, 고유
+ID([UID](/ko/docs/concepts/overview/working-with-objects/names/#uids))가
+할당되고, 종료(재시작 정책에 따라) 또는 삭제될 때까지 남아있는 노드에
+스케줄된다.
+만약 {{< glossary_tooltip term_id="node" text="노드" >}}가 종료되면, 해당 노드에 스케줄된 파드는
+타임아웃 기간 후에 [삭제되도록 스케줄된다](#pod-garbage-collection).
+
+파드는 자체적으로 자가 치유되지 않는다. 파드가
+{{< glossary_tooltip text="노드" term_id="node" >}}에 스케줄된 후에 실패하거나,
+스케줄 작업 자체가 실패하면, 파드는 삭제된다. 마찬가지로, 파드는
+리소스 부족 또는 노드 유지 관리 작업으로 인해 축출되지 않는다. 쿠버네티스는
+{{< glossary_tooltip term_id="controller" text="컨트롤러" >}}라
+부르는 하이-레벨 추상화를 사용하여
+상대적으로 일회용인 파드 인스턴스를 관리하는 작업을 처리한다.
+
+UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되지 않는다. 대신,
+해당 파드는 사용자가 원하는 이름은 같지만, UID가 다른, 거의 동일한 새 파드로
+대체될 수 있다.
+
+{{< glossary_tooltip term_id="volume" text="볼륨" >}}과
+같은 어떤 것이 파드와 동일한 수명을 갖는다는 것은,
+특정 파드(정확한 UID 포함)가 존재하는 한 그것이 존재함을
+의미한다. 어떤 이유로든 해당 파드가 삭제되고, 동일한 대체 파드가
+생성되더라도, 관련된 그것(이 예에서는 볼륨)도 폐기되고
+새로 생성된다.
+
+{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}}
+
+*컨테이너 간의 공유 스토리지에 퍼시스턴트 볼륨을 사용하는 웹 서버와
+파일 풀러(puller)가 포함된 다중 컨테이너 파드이다.*
+
+## 파드의 단계
파드의 `status` 필드는
`phase` 필드를 포함하는
@@ -34,189 +78,107 @@ weight: 30
값 | 의미
:-----|:-----------
-`Pending` | 파드가 쿠버네티스 시스템에 의해서 승인되었지만, 파드를 위한 하나 또는 하나 이상의 컨테이너 이미지 생성이 아직 완료되지 않았다. 여기에는 스케줄되기 이전까지의 시간 뿐만 아니라 오래 걸릴 수 있는 네트워크를 통한 이미지 다운로드 시간도 포함된다.
-`Running` | 파드가 한 노드에 결합되었고, 모든 컨테이너들의 생성이 완료되었다. 적어도 하나의 컨테이너가 동작 중이거나, 시작 또는 재시작 중에 있다.
-`Succeeded` | 파드에 있는 모든 컨테이너들이 성공으로 종료되었고, 재시작되지 않을 것이다.
-`Failed` | 파드에 있는 모든 컨테이너들이 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다. 즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었다.
-`Unknown` | 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 일반적으로 파드 호스트와의 통신 오류에 의해서 발생한다.
+`Pending` | 파드가 쿠버네티스 클러스터에서 승인되었지만, 하나 이상의 컨테이너가 설정되지 않았고 실행할 준비가 되지 않았다. 여기에는 파드가 스케줄되기 이전까지의 시간 뿐만 아니라 네트워크를 통한 컨테이너 이미지 다운로드 시간도 포함된다.
+`Running` | 파드가 노드에 바인딩되었고, 모든 컨테이너가 생성되었다. 적어도 하나의 컨테이너가 아직 실행 중이거나, 시작 또는 재시작 중에 있다.
+`Succeeded` | 파드에 있는 모든 컨테이너들이 성공적으로 종료되었고, 재시작되지 않을 것이다.
+`Failed` | 파드에 있는 모든 컨테이너가 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다. 즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었다.
+`Unknown` | 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 이 단계는 일반적으로 파드가 실행되어야 하는 노드와의 통신 오류로 인해 발생한다.
-## 파드의 조건(condition)
+노드가 죽거나 클러스터의 나머지와의 연결이 끊어지면, 쿠버네티스는
+손실된 노드의 모든 파드의 `phase` 를 Failed로 설정하는 정책을 적용한다.
+
+## 컨테이너 상태
+
+전체 파드의 [단계](#파드의-단계)뿐 아니라, 쿠버네티스는 파드 내부의
+각 컨테이너 상태를 추적한다.
+[컨테이너 라이프사이클 훅(hook)](/docs/concepts/containers/container-lifecycle-hooks/)을
+사용하여 컨테이너 라이프사이클의 특정 지점에서 실행할 이벤트를 트리거할 수 있다.
+
+일단 {{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}가
+노드에 파드를 할당하면, kubelet은 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}을
+사용하여 해당 파드에 대한 컨테이너 생성을 시작한다.
+표시될 수 있는 세 가지 컨테이너 상태는 `Waiting`, `Running` 그리고 `Terminated` 이다.
+
+파드의 컨테이너 상태를 확인하려면, `kubectl describe pod ` 를
+사용할 수 있다. 출력 결과는 해당 파드 내의 각 컨테이너 상태가
+표시된다.
+
+각 상태에는 특정한 의미가 있다.
+
+### `Waiting` {#container-state-waiting}
+
+만약 컨테이너가 `Running` 또는 `Terminated` 상태가 아니면, `Waiting` 상태이다.
+`Waiting` 상태의 컨테이너는 시작을 완료하는 데 필요한
+작업(예를 들어, 컨테이너 이미지 레지스트리에서 컨테이너 이미지 가져오거나,
+{{< glossary_tooltip text="시크릿(Secret)" term_id="secret" >}} 데이터를 적용하는 작업)을
+계속 실행하고 있는 중이다.
+`kubectl` 을 사용하여 컨테이너가 `Waiting` 인 파드를 쿼리하면, 컨테이너가
+해당 상태에 있는 이유를 요약하는 Reason 필드도 표시된다.
+
+### `Running` {#container-state-running}
+
+`Running` 상태는 컨테이너가 문제없이 실행되고 있음을 나타낸다. `postStart` 훅이
+구성되어 있었다면, 이미 실행이 완료되었다. `kubectl` 을
+사용하여 컨테이너가 `Running` 인 파드를 쿼리하면, 컨테이너가 `Running` 상태에 진입한 시기에 대한
+정보도 볼 수 있다.
+
+### `Terminated` {#container-state-terminated}
+
+`Terminated` 상태의 컨테이너는 실행을 시작한 다음 완료될 때까지
+실행되었거나 어떤 이유로 실패했다. `kubectl` 을 사용하여 컨테이너가 `Terminated` 인 파드를
+쿼리하면, 이유와 종료 코드 그리고 해당 컨테이너의 실행 기간에 대한 시작과
+종료 시간이 표시된다.
+
+컨테이너에 구성된 `preStop` 훅이 있는 경우, 컨테이너가 `Terminated` 상태에 들어가기 전에
+실행된다.
+
+## 컨테이너 재시작 정책 {#restart-policy}
+
+파드의 `spec` 에는 `restartPolicy` 필드가 있다. 사용 가능한 값은 Always, OnFailure 그리고
+Never이다. 기본값은 Always이다.
+
+`restartPolicy` 는 파드의 모든 컨테이너에 적용된다. `restartPolicy` 는
+동일한 노드에서 kubelet에 의한 컨테이너 재시작만을 의미한다. 파드의 컨테이너가
+종료된 후, kubelet은 5분으로 제한되는 지수 백오프 지연(10초, 20초, 40초, …)으로
+컨테이너를 재시작한다. 컨테이너가 10분 동안 아무런 문제없이 실행되면,
+kubelet은 해당 컨테이너의 재시작 백오프 타이머를
+재설정한다.
+
+## 파드의 조건
파드는 하나의 PodStatus를 가지며,
그것은 파드가 통과했거나 통과하지 못한 조건에 대한
[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core) 배열을 가진다.
-PodCondition 배열의 각 요소는 다음 여섯 가지 필드를 가질 수 있다.
-* `lastProbeTime` 필드는
-파드의 조건이 마지막으로 조사된 시점의 타임스탬프를 제공한다.
+* `PodScheduled`: 파드가 노드에 스케줄되었다.
+* `ContainersReady`: 파드의 모든 컨테이너가 준비되었다.
+* `Initialized`: 모든 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)가
+ 성공적으로 시작되었다.
+* `Ready`: 파드는 요청을 처리할 수 있으며 일치하는 모든 서비스의 로드
+ 밸런싱 풀에 추가되어야 한다.
-* `lastTransitionTime` 필드는
-파드가 마지막으로 한 상태에서 다른 상태로 전환된 시점의 타임스탬프를 제공한다.
+필드 이름 | 설명
+:--------------------|:-----------
+`type` | 이 파드 조건의 이름이다.
+`status` | 가능한 값이 "`True`", "`False`", 또는 "`Unknown`"으로, 해당 조건이 적용 가능한지 여부를 나타낸다.
+`lastProbeTime` | 파드 조건이 마지막으로 프로브된 시간의 타임스탬프이다.
+`lastTransitionTime` | 파드가 한 상태에서 다른 상태로 전환된 마지막 시간에 대한 타임스탬프이다.
+`reason` | 조건의 마지막 전환에 대한 이유를 나타내는 기계가 판독 가능한 UpperCamelCase 텍스트이다.
+`message` | 마지막 상태 전환에 대한 세부 정보를 나타내는 사람이 읽을 수 있는 메시지이다.
-* `message` 필드는
-전환에 대한 세부 정보를 표시한, 사람이 읽을 수 있는 메시지이다.
-
-* `reason` 필드는 마지막으로 발생한 전환의 이유다. 이유는 유일하게, 한 단어로, 카멜 표기법(CamelCase)으로 표기된다.
-
-* `status` 필드는 `True`", "`False`", 그리고 "`Unknown`"으로 지정될 수 있는 문자열이다.
-
-* `type` 필드는 다음과 같은 가능한 값들의 문자열이다.
-
- * `PodScheduled`: 파드가 하나의 노드로 스케줄 완료되었음.
- * `Ready`: 파드는 요청들을 수행할 수 있으며
- 모든 매칭 서비스들의 로드밸런싱 풀에 추가되어야 함.
- * `Initialized`: 모든 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers)가
- 성공적으로 시작 완료되었음.
- * `ContainersReady`: 파드 내의 모든 컨테이너가 준비 상태임.
-
-
-
-## 컨테이너 프로브(probe)
-
-[프로브](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)는
-컨테이너에서 [kubelet](/docs/admin/kubelet/)에 의해 주기적으로 수행되는 진단(diagnostic)이다.
-진단을 수행하기 위해서,
-kubelet은 컨테이너에 의해서 구현된
-[핸들러](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)를 호출한다.
-핸들러에는 다음과 같이 세 가지 타입이 있다.
-
-* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core)
- 은 컨테이너 내에서 지정된 명령어를 실행한다.
- 명령어가 상태 코드 0으로 종료되면 진단이 성공한 것으로 간주한다.
-
-* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core)
- 은 지정된 포트에서 컨테이너의 IP주소에 대해 TCP 검사를 수행한다.
- 포트가 활성화되어 있다면 진단이 성공한 것으로 간주한다.
-
-* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core)
- 은 지정한 포트 및 경로에서 컨테이너의 IP주소에
- 대한 HTTP Get 요청을 수행한다. 응답의 상태 코드가 200 이상 400 미만이면
- 진단이 성공한 것으로 간주한다.
-
-각 probe는 다음 세 가지 결과 중 하나를 가진다.
-
-* Success: 컨테이너가 진단을 통과함.
-* Failure: 컨테이너가 진단에 실패함.
-* Unknown: 진단 자체가 실패하였으므로 아무런 액션도 수행되면 안됨.
-
-kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 종류의 프로브를 수행하고
-그에 반응할 수 있다.
-
-* `livenessProbe`: 컨테이너가 동작 중인지 여부를 나타낸다. 만약
- 활성 프로브(liveness probe)에 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는
- [재시작 정책](#재시작-정책)의 대상이 된다. 만약 컨테이너가
- 활성 프로브를 제공하지 않는 경우, 기본 상태는 `Success`이다.
-
-* `readinessProbe`: 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다.
- 만약 준비성 프로브(readiness probe)가 실패한다면, 엔드포인트 컨트롤러는
- 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. 준비성 프로브의
- 초기 지연 이전의 기본 상태는 `Failure`이다. 만약 컨테이너가 준비성 프로브를
- 지원하지 않는다면, 기본 상태는 `Success`이다.
-
-* `startupProbe`: 컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다.
- 스타트업 프로브(startup probe)가 주어진 경우, 성공할 때 까지 다른 나머지 프로브는
- 활성화 되지 않는다. 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고,
- 컨테이너는 [재시작 정책](#재시작-정책)에 따라 처리된다. 컨테이너에 스타트업
- 프로브가 없는 경우, 기본 상태는 `Success`이다.
-
-### 언제 활성 프로브를 사용해야 하는가?
-
-{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-
-만약 컨테이너 속 프로세스가 어떠한 이슈에 직면하거나 건강하지 못한
-상태(unhealthy)가 되는 등 프로세스 자체의 문제로 중단될 수 있더라도, 활성 프로브가
-반드시 필요한 것은 아니다. 그 경우에는 kubelet이 파드의 `restartPolicy`에
-따라서 올바른 대처를 자동적으로 수행할 것이다.
-
-프로브가 실패한 후 컨테이너가 종료되거나 재시작되길 원한다면, 활성 프로브를
-지정하고, `restartPolicy`를 항상(Always) 또는 실패 시(OnFailure)로 지정한다.
-
-### 언제 준비성 프로브를 사용해야 하는가?
-
-{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-
-프로브가 성공한 경우에만 파드에 트래픽 전송을 시작하려고 한다면, 준비성 프로브를 지정하길 바란다.
-이 경우에서는, 준비성 프로브가 활성 프로브와 유사해 보일 수도 있지만,
-스팩에 준비성 프로브가 존재한다는 것은 파드가 트래픽을 받지 않는 상태에서
-시작되고 프로브가 성공하기 시작한 이후에만 트래픽을 받는다는 뜻이다.
-만약 컨테이너가 대량의 데이터, 설정 파일들,
-또는 시동 중 마그레이션을 처리해야 한다면, 준비성 프로브를 지정하길 바란다.
-
-만약 당신의 컨테이너가 유지 관리를 위해서 자체 중단되게 하려면,
-준비성 프로브를 지정하길 바란다.
-준비성 프로브는 활성 프로브와는 다르게 준비성에 특정된 엔드포인트를 확인한다.
-
-파드가 삭제될 때 단지 요청들이 흘려 보낼(drain) 목적으로,
-준비성 프로브가 필요하지는 않다는 점을 유념해야한다. 삭제 시에, 파드는
-프로브의 존재 여부와 무관하게 자동으로 스스로를 준비되지 않은 상태(unready)로 변경한다.
-파드는 파드 내의 모든 컨테이너들이 중지될 때까지 준비되지 않은 상태로
-남아있는다.
-
-### 언제 스타트업 프로브를 사용해야 하는가?
-
-{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
-
-컨테이너가 보통 `initialDelaySeconds + failureThreshold × periodSeconds` 이후에 기동된다면, 스타트업 프로브가 활성화 프로브와 같은 엔드포인트를 체크하도록 명시해야 한다. `periodSeconds`의 기본 값은 30s 이다.
-이 때 컨테이너가 활성화 프로브의 기본 값 변경 없이 기동되도록 하려면 `failureThreshold`를 충분히 높게 설정해주어야 한다. 그래야 데드락(deadlocks)을 방지하는데 도움이 된다.
-
-활성, 준비성 및 스타트업 프로브를 설정하는 방법에 대한 추가적인 정보는,
-[활성, 준비성 및 스타트업 프로브 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)를 참조하면 된다.
-
-## 파드 및 컨테이너 상태
-
-파드 및 컨테이너 상태에 대한 자세한 정보는,
-[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) 및
-[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)를 참조하면 된다.
-파드의 상태로서 보고되는 정보는
-현재의 [ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)에
-의존적이라는 점에 유의하길 바란다.
-
-## 컨테이너 상태
-
-일단 스케줄러가 파드를 노드에 할당하면, kubelet이 컨테이너 런타임으로 컨테이너를 만들기 시작한다. 컨테이너에 세 가지 상태가 있는데, Waiting, Running, 그리고 Terminated이다. 컨테이너의 상태를 체크하려면 `kubectl describe pod [POD_NAME]` 명령을 사용할 수 있다. 상태는 파드 안에 있는 컨테이너 각각에 대해 출력된다.
-
-* `Waiting`: 컨테이너의 기본 상태이다. 컨테이너가 Running 이나 Terminated 상태가 아닌 경우, Waiting 상태이다. Waiting 상태의 컨테이너는 이미지를 내려받거나(pull), 시크릿을 적용하는 등의 필요한 오퍼레이션이 수행 중인 상태이다. 이 상태와 더불어서, 더 자세한 정보를 제공하기 위해 상태에 대한 메시지와 이유가 출력된다.
-
- ```yaml
- ...
- State: Waiting
- Reason: ErrImagePull
- ...
- ```
-
-* `Running`: 컨테이너가 이슈 없이 구동된다는 뜻이다. `postStart` 훅(있는 경우)은 컨테이너가 Running 상태가 되기 전에 실행된다. 이 상태는 컨테이너가 언제 Running 상태에 돌입한 시간도 함께 출력된다.
-
- ```yaml
- ...
- State: Running
- Started: Wed, 30 Jan 2019 16:46:38 +0530
- ...
- ```
-
-* `Terminated`: 컨테이너가 실행이 완료되어 구동을 멈추었다는 뜻이다. 컨테이너가 성공적으로 작업을 완료했을 때나 어떤 이유에서 실패했을 때 이 상태가 된다. 원인과 종료 코드(exit code)가 컨테이너의 시작과 종료 시간과 함께 무조건 출력된다. 컨테이너가 Terminated 상태가 되기 전에, `preStop` 훅이 (존재한다면) 실행된다.
-
- ```yaml
- ...
- State: Terminated
- Reason: Completed
- Exit Code: 0
- Started: Wed, 30 Jan 2019 11:45:26 +0530
- Finished: Wed, 30 Jan 2019 11:45:26 +0530
- ...
- ```
## 파드의 준비성(readiness) {#pod-readiness-gate}
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
애플리케이션은 추가 피드백 또는 신호를 PodStatus: _Pod readiness_
-와 같이 주입할 수 있다. 이를 사용하기 위해, 파드의 준비성을 평가하기
-위한 추가적인 조건들을 `PodSpec` 내의 `ReadinessGate` 필드를 통해서 지정할 수 있다.
+와 같이 주입할 수 있다. 이를 사용하기 위해, kubelet이 파드의 준비성을 평가하기
+위한 추가적인 조건들을 파드의 `spec` 내 `readinessGate` 필드를 통해서 지정할 수 있다.
준비성 게이트는 파드에 대한 `status.condition` 필드의 현재
상태에 따라 결정된다. 만약 쿠버네티스가 `status.conditions` 필드에서 해당하는
조건을 찾지 못한다면, 그 조건의 상태는
-기본 값인 "`False`"가 된다. 아래는 한 예제를 보여준다.
+기본 값인 "`False`"가 된다.
여기 예제가 있다.
@@ -258,151 +220,225 @@ status:
경우에 **만** 해당 파드가 준비된 것으로 평가된다.
* 파드 내의 모든 컨테이너들이 준비 상태이다.
-* `ReadinessGates`에 지정된 모든 조건들이 `True` 이다.
+* `readinessGates`에 지정된 모든 조건들이 `True` 이다.
파드의 컨테이너가 Ready 이나 적어도 한 개의 사용자 지정 조건이 빠졌거나 `False` 이면,
-Kubelet은 파드의 상태를 `ContainerReady`로 설정한다.
+kubelet은 파드의 [조건](#파드의-조건)을 `ContainerReady` 로 설정한다.
-## 재시작 정책
+## 컨테이너 프로브(probe)
-PodSpec은 항상(Always), 실패 시(OnFailure), 절대 안 함(Never) 값으로 설정 가능한 `restartPolicy` 필드를 가지고 있다.
-기본 값은 항상(Always)이다.
-`restartPolicy`는 파드 내의 모든 컨테이너들에 적용된다. `restartPolicy`는
-같은 노드에 있는 kubelet에 의한 컨테이너들의 재시작에만 관련되어 있다.
-kubelet에 의해서 재시작되는 종료된 컨테이너는
-5분으로 제한된 지수 백-오프 지연(10초, 20초, 40초 ...)을 기준으로 재시작되며,
-10분의 성공적 실행 후에 재설정된다.
-[파드 문서](/ko/docs/concepts/workloads/pods/pod/#파드의-내구성-또는-결핍)에서 의논된 바와 같이,
-파드는 일단 한 노드에 바운드되고 나면, 다른 노드에 다시 바운드되지 않는다.
+[프로브](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)는
+컨테이너에서 [kubelet](/docs/admin/kubelet/)에 의해 주기적으로 수행되는 진단(diagnostic)이다.
+진단을 수행하기 위해서,
+kubelet은 컨테이너에 의해서 구현된
+[핸들러](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)를 호출한다.
+핸들러에는 다음과 같이 세 가지 타입이 있다.
+* [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core)은
+ 컨테이너 내에서 지정된 명령어를 실행한다.
+ 명령어가 상태 코드 0으로 종료되면 진단이 성공한 것으로 간주한다.
-## 파드의 일생(lifetime)
+* [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core)은
+ 지정된 포트에서 컨테이너의 IP주소에 대해 TCP 검사를 수행한다.
+ 포트가 활성화되어 있다면 진단이 성공한 것으로 간주한다.
-일반적으로, 파드는 사람 혹은
-{{< glossary_tooltip term_id="controller" text="컨트롤러" >}}의
-프로세스가 명시적으로 파드를 삭제할 때까지 남아 있다.
-컨트롤 플레인은 파드의 수가 설정된 임계치(kube-controller-manager에서
-`terminated-pod-gc-threshold`에 의해 결정)를 초과할 때,
-종료된 파드들(`Succeeded` 또는 `Failed` 단계)을 정리한다.
-이로써 시간이 지남에 따라 파드들이 생성 및 종료되며 발생하는 리소스 누수를 피할 수 있다.
+* [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core)은
+ 지정한 포트 및 경로에서 컨테이너의 IP주소에
+ 대한 HTTP `GET` 요청을 수행한다. 응답의 상태 코드가 200 이상 400 미만이면
+ 진단이 성공한 것으로 간주한다.
-파드에는 다음과 같은 다양한 종류의 리소스가 있다.
+각 probe는 다음 세 가지 결과 중 하나를 가진다.
-- 예를 들어 웹 서버와 같이 종료되지 않을 것으로 예상되는 파드용
- {{< glossary_tooltip term_id="deployment" >}}, {{< glossary_tooltip term_id="replica-set" >}} 또는
- {{< glossary_tooltip term_id="statefulset" >}}을 사용한다.
+* `Success`: 컨테이너가 진단을 통과함.
+* `Failure`: 컨테이너가 진단에 실패함.
+* `Unknown`: 진단 자체가 실패하였으므로 아무런 액션도 수행되면 안됨.
-- 배치 연산과 같이, 종료가 예상되는 파드를 위해서는
- {{< glossary_tooltip term_id="job" >}}을
- 사용하길 바란다. 잡은 `restartPolicy`가 실패 시(OnFailure) 또는 절대 안 함(Never)으로
- 지정된 경우에 적합하다.
+kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 종류의 프로브를 수행하고
+그에 반응할 수 있다.
-- 적합한 노드 당 하나씩 실행해야 하는 파드에는
- {{< glossary_tooltip term_id="daemonset" >}}을 사용한다.
+* `livenessProbe`: 컨테이너가 동작 중인지 여부를 나타낸다. 만약
+ 활성 프로브(liveness probe)에 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는
+ [재시작 정책](#restart-policy)의 대상이 된다. 만약 컨테이너가
+ 활성 프로브를 제공하지 않는 경우, 기본 상태는 `Success`이다.
-모든 워크로드 리소스에는 파드명세가 포함된다. 사용자가 직접적으로 파드를 생성하는
-것보다 적절한 워크로드 리소스를 생성하고 리소스 컨트롤러가
-사용자를 위한 파드를 생성하도록 하는 것을 권장한다.
+* `readinessProbe`: 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다.
+ 만약 준비성 프로브(readiness probe)가 실패한다면, 엔드포인트 컨트롤러는
+ 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. 준비성 프로브의
+ 초기 지연 이전의 기본 상태는 `Failure`이다. 만약 컨테이너가 준비성 프로브를
+ 지원하지 않는다면, 기본 상태는 `Success`이다.
-만약 노드가 죽거나 다른 클러스터의 다른 노드들로부터 연결이 끊기면, 쿠버네티스는
-잃어버린 노드에 있는 모든 파드의 `phase`를 실패된(Failed)으로 설정하는 정책을 적용한다.
+* `startupProbe`: 컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다.
+ 스타트업 프로브(startup probe)가 주어진 경우, 성공할 때까지 다른 나머지 프로브는
+ 활성화되지 않는다. 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고,
+ 컨테이너는 [재시작 정책](#restart-policy)에 따라 처리된다. 컨테이너에 스타트업
+ 프로브가 없는 경우, 기본 상태는 `Success`이다.
-## 예제
+활성, 준비성 및 스타트업 프로브를 설정하는 방법에 대한 추가적인 정보는,
+[활성, 준비성 및 스타트업 프로브 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)를 참조하면 된다.
-### 고급 활성 프로브 예제
+### 언제 활성 프로브를 사용해야 하는가?
-활성 프로브는 kubelet에 의해서 실행된다. 따라서 모든 요청은
-kubelet 네트워크 네임스페이스에서 이루어진다.
+{{< feature-state for_k8s_version="v1.0" state="stable" >}}
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
- labels:
- test: liveness
- name: liveness-http
-spec:
- containers:
- - args:
- - /server
- image: k8s.gcr.io/liveness
- livenessProbe:
- httpGet:
- # "host"가 정의되지 않은 경우, "PodIP" 가 사용될 것이다.
- # host: my-host
- # "scheme"이 정의되지 않은 경우, "HTTP" 스키마가 사용될 것이다. "HTTP"와 "HTTPS"만 허용된다.
- # scheme: HTTPS
- path: /healthz
- port: 8080
- httpHeaders:
- - name: X-Custom-Header
- value: Awesome
- initialDelaySeconds: 15
- timeoutSeconds: 1
- name: liveness
-```
+만약 컨테이너 속 프로세스가 어떠한 이슈에 직면하거나 건강하지 못한
+상태(unhealthy)가 되는 등 프로세스 자체의 문제로 중단될 수 있더라도, 활성 프로브가
+반드시 필요한 것은 아니다. 그 경우에는 kubelet이 파드의 `restartPolicy`에
+따라서 올바른 대처를 자동적으로 수행할 것이다.
-### 상태 예제
+프로브가 실패한 후 컨테이너가 종료되거나 재시작되길 원한다면, 활성 프로브를
+지정하고, `restartPolicy`를 항상(Always) 또는 실패 시(OnFailure)로 지정한다.
- * 파드가 동작 중이고 하나의 컨테이너를 가지고 있다. 컨테이너는 성공으로 종료됐다.
- * 완료 이벤트를 기록한다.
- * 만약 `restartPolicy`가 :
- * 항상(Always)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다.
- * 실패 시(OnFailure)이면: 파드의 `phase`는 Succeeded가 된다.
- * 절대 안 함(Never)이면: 파드의 `phase`는 Succeeded가 된다.
+### 언제 준비성 프로브를 사용해야 하는가?
- * 파드가 동작 중이고 하나의 컨테이너를 가지고 있다. 컨테이너는 실패로 종료됐다.
- * 실패 이벤트를 기록한다.
- * 만약 `restartPolicy`가 :
- * 항상(Always)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다.
- * 실패 시(OnFailure)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다.
- * 절대 안 함(Never)이면: 파드의 `phase`는 Failed가 된다.
+{{< feature-state for_k8s_version="v1.0" state="stable" >}}
- * 파드가 동작 중이고 두 개의 컨테이너를 가지고 있다. 컨테이너 1이 실패로 종료됐다.
- * 실패 이벤트를 기록한다.
- * 만약 `restartPolicy`가 :
- * 항상(Always)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다.
- * 실패 시(OnFailure)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다.
- * 절대 안 함(Never)이면: 컨테이너는 재시작되지 않고, 파드의 `phase`는 Running으로 유지된다.
- * 만약 컨테이너 1이 동작 중이 아니고, 컨테이너 2가 종료됐다면 :
- * 실패 이벤트를 기록한다.
- * 만약 `restartPolicy`가 :
- * 항상(Always)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다.
- * 실패 시(OnFailure)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다.
- * 절대 안 함(Never)이면: 파드의 `phase`는 Failed가 된다.
+프로브가 성공한 경우에만 파드에 트래픽 전송을 시작하려고 한다면,
+준비성 프로브를 지정하길 바란다. 이 경우에서는, 준비성 프로브가 활성 프로브와 유사해
+보일 수도 있지만, 스팩에 준비성 프로브가 존재한다는 것은 파드가
+트래픽을 받지 않는 상태에서 시작되고 프로브가 성공하기 시작한 이후에만
+트래픽을 받는다는 뜻이다.
+만약 컨테이너가 대량의 데이터, 설정 파일들,
+또는 시동 중 마그레이션을 처리해야 한다면, 준비성 프로브를 지정하길 바란다.
- * 파드는 동작 중이고 하나의 컨테이너를 가지고 있다. 컨테이너의 메모리가 부족하다.
- * 컨테이너는 실패로 종료된다.
- * 메모리 부족(OOM) 이벤트를 기록한다.
- * 만약 `restartPolicy`가 :
- * 항상(Always)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다.
- * 실패 시(OnFailure)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다.
- * 절대 안 함(Never)이면: 로그 실패 이벤트가 발생되고, 파드의 `phase`는 Failed가 된다.
+만약 당신의 컨테이너가 유지 관리를 위해서 자체 중단되게 하려면,
+준비성 프로브를 지정하길 바란다.
+준비성 프로브는 활성 프로브와는 다르게 준비성에 특정된 엔드포인트를 확인한다.
- * 파드 동작 중에, 디스크가 죽었다.
- * 모든 컨테이너들을 죽인다.
- * 적절한 이벤트를 기록한다.
- * 파드의 `phase`는 Failed가 된다.
- * 만약 컨트롤러로 실행되었다면, 파드는 어딘가에서 재생성된다.
+{{< note >}}
+파드가 삭제될 때 단지 요청들을 흘려 보낼(drain) 목적으로,
+준비성 프로브가 필요하지는 않다는 점을 유념해야 한다. 삭제 시에, 파드는
+프로브의 존재 여부와 무관하게 자동으로 스스로를 준비되지 않은 상태(unready)로 변경한다.
+파드는 파드 내의 모든 컨테이너들이 중지될 때까지 준비되지 않은 상태로
+남아 있다.
+{{< /note >}}
- * 파드 동작 중에, 파드가 있는 노드가 세그먼티드 아웃되었다.
- * 노드 컨트롤러가 타임아웃을 기다린다.
- * 노드 컨트롤러가 파드의 `phase`를 Failed로 설정한다.
- * 만약 컨트롤러로 실행되었다면, 파드는 어딘가에서 재생성된다.
+### 언제 스타트업 프로브를 사용해야 하는가?
+{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+스타트업 프로브는 서비스를 시작하는 데 오랜 시간이 걸리는 컨테이너가 있는
+파드에 유용하다. 긴 활성 간격을 설정하는 대신, 컨테이너가 시작될 때
+프로브를 위한 별도의 구성을 설정하여, 활성 간격보다
+긴 시간을 허용할 수 있다.
+
+컨테이너가 보통 `initialDelaySeconds + failureThreshold × periodSeconds`
+이후에 기동된다면, 스타트업 프로브가
+활성화 프로브와 같은 엔드포인트를 확인하도록 지정해야 한다.
+`periodSeconds`의 기본값은 30s 이다. 이 때 컨테이너가 활성화 프로브의
+기본값 변경 없이 기동되도록 하려면, `failureThreshold` 를 충분히 높게 설정해주어야
+한다. 그래야 데드락(deadlocks)을 방지하는데 도움이 된다.
+
+## 파드의 종료 {#pod-termination}
+
+파드는 클러스터의 노드에서 실행되는 프로세스를 나타내므로, 해당 프로세스가
+더 이상 필요하지 않을 때 정상적으로 종료되도록 하는 것이 중요하다(`KILL`
+시그널로 갑자기 중지되고 정리할 기회가 없는 것 보다).
+
+디자인 목표는 삭제를 요청하고 프로세스가 종료되는 시기를 알 수
+있을 뿐만 아니라, 삭제가 결국 완료되도록 하는 것이다.
+사용자가 파드의 삭제를 요청하면, 클러스터는 파드가 강제로 종료되기 전에
+의도한 유예 기간을 기록하고 추적한다. 강제 종료 추적이
+적용되면, {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}은 정상
+종료를 시도한다.
+
+일반적으로, 컨테이너 런타임은 TERM 시그널을 각 컨테이너의 기본 프로세스로
+전송한다. 일단 유예 기간이 만료되면, KILL 시그널이 나머지 프로세스로
+전송되고, 그런 다음 파드는
+{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}로부터 삭제된다. 프로세스가
+종료될 때까지 기다리는 동안 kubelet 또는 컨테이너 런타임의 관리 서비스가 다시 시작되면, 클러스터는
+전체 원래 유예 기간을 포함하여 처음부터 다시 시도한다.
+
+플로우의 예는 다음과 같다.
+
+1. 이 `kubectl` 도구를 사용하여 기본 유예 기간(30초)으로 특정 파드를 수동으로
+ 삭제한다.
+1. API 서버의 파드는 유예 기간과 함께 파드가 "dead"로 간주되는
+ 시간으로 업데이트된다.
+ `kubectl describe` 를 사용하여 삭제하려는 파드를 확인하면, 해당 파드가 "Terminating"으로
+ 표시된다.
+ 파드가 실행 중인 노드에서, kubelet이 파드가 종료된 것(terminating)으로 표시되었음을
+ 확인하는 즉시(정상적인 종료 기간이 설정됨), kubelet은 로컬 파드의 종료
+ 프로세스를 시작한다.
+ 1. 파드의 컨테이너 중 하나가 `preStop`
+ [훅](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)을 정의한 경우, kubelet은
+ 컨테이너 내부에서 해당 훅을 실행한다. 유예 기간이 만료된 후 `preStop` 훅이
+ 계속 실행되면, kubelet은 2초의 작은 일회성 유예 기간 연장을
+ 요청한다.
+ {{< note >}}
+ `preStop` 훅을 완료하는 데 기본 유예 기간이 허용하는 것보다 오랜 시간이 필요한 경우,
+ 이에 맞게 `terminationGracePeriodSeconds` 를 수정해야 한다.
+ {{< /note >}}
+ 1. kubelet은 컨테이너 런타임을 트리거하여 각 컨테이너 내부의 프로세스 1에 TERM 시그널을
+ 보낸다.
+ {{< note >}}
+ 파드의 컨테이너는 서로 다른 시간에 임의의 순서로 TERM 시그널을
+ 수신한다. 종료 순서가 중요한 경우, `preStop` 훅을 사용하여 동기화하는 것이 좋다.
+ {{< /note >}}
+1. kubelet이 정상 종료를 시작하는 동시에, 컨트롤 플레인은
+ 구성된 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}가 있는
+ {{< glossary_tooltip term_id="service" text="서비스" >}}를 나타내는
+ 엔드포인트(Endpoint)(그리고, 활성화된 경우, 엔드포인트슬라이스(EndpointSlice)) 오브젝트에서 종료된 파드를 제거한다.
+ {{< glossary_tooltip text="레플리카셋(ReplicaSet)" term_id="replica-set" >}}과 기타 워크로드 리소스는
+ 더 이상 종료된 파드를 유효한 서비스 내 복제본으로 취급하지 않는다. 로드 밸런서(서비스 프록시와 같은)가
+ 종료 유예 기간이 _시작되는_ 즉시 엔드포인트 목록에서 파드를 제거하므로 느리게 종료되는
+ 파드는 트래픽을 계속 제공할 수 없다.
+1. 유예 기간이 만료되면, kubelet은 강제 종료를 트리거한다. 컨테이너 런타임은
+ `SIGKILL` 을 파드의 모든 컨테이너에서 여전히 실행 중인 모든 프로세스로 전송한다.
+ kubelet은 해당 컨테이너 런타임이 하나를 사용하는 경우 숨겨진 `pause` 컨테이너도 정리한다.
+1. kubelet은 유예 기간을 0(즉시 삭제)으로 설정하여, API 서버에서 파드 오브젝트의
+ 강제 삭제를 트리거한다.
+1. API 서버가 파드의 API 오브젝트를 삭제하면, 더 이상 클라이언트에서 볼 수 없다.
+
+### 강제 파드 종료 {#pod-termination-forced}
+
+{{< caution >}}
+강제 삭제는 일부 워크로드와 해당 파드에 대해서 잠재적으로 중단될 수 있다.
+{{< /caution >}}
+
+기본적으로, 모든 삭제는 30초 이내에는 정상적으로 수행된다. `kubectl delete` 명령은
+기본값을 재정의하고 사용자의 고유한 값을 지정할 수 있는 `--grace-period=` 옵션을
+지원한다.
+
+유예 기간을 `0` 로 강제로 즉시 설정하면 API 서버에서 파드가
+삭제된다. 파드가 노드에서 계속 실행 중인 경우, 강제 삭제는 kubelet을 트리거하여
+즉시 정리를 시작한다.
+
+{{< note >}}
+강제 삭제를 수행하려면 `--grace-period=0` 와 함께 추가 플래그 `--force` 를 지정해야 한다.
+{{< /note >}}
+
+강제 삭제가 수행되면, API 서버는 실행 중인 노드에서
+파드가 종료되었다는 kubelet의 확인을 기다리지 않는다.
+API에서 즉시 파드를 제거하므로 동일한 이름으로 새로운 파드를 생성할 수
+있다. 노드에서 즉시 종료되도록 설정된 파드는 강제 종료되기 전에
+작은 유예 기간이 계속 제공된다.
+
+스테이트풀셋(StatefulSet)의 일부인 파드를 강제 삭제해야 하는 경우,
+[스테이트풀셋에서 파드를 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한
+태스크 문서를 참고한다.
+
+### 실패한 파드의 가비지 콜렉션 {#pod-garbage-collection}
+
+실패한 파드의 경우, API 오브젝트는 사람이나
+{{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 프로세스가
+명시적으로 파드를 제거할 때까지 클러스터의 API에 남아 있다.
+
+컨트롤 플레인은 파드 수가 구성된 임계값(kube-controller-manager에서
+`terminated-pod-gc-threshold` 에 의해 결정됨)을 초과할 때 종료된 파드(`Succeeded` 또는
+`Failed` 단계 포함)를 정리한다.
+이렇게 하면 시간이 지남에 따라 파드가 생성되고 종료될 때 리소스 유출이 방지된다.
## {{% heading "whatsnext" %}}
+* [컨테이너 라이프사이클 이벤트에 핸들러를 연결](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)하는
+ 핸즈온 연습을 해보자.
-* Hands-on 경험하기
- [컨테이너 라이프사이클 이벤트에 핸들러 부착하기](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
-
-* Hands-on 경험하기
- [활성, 준비성 및 스타트업 프로브 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/).
-
-* [컨테이너 라이프사이클 후크(hook)](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배우기.
-
+* [활성, 준비성 및 스타트업 프로브 설정](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)하는
+ 핸즈온 연습을 해보자.
+* [컨테이너 라이프사이클 훅](/docs/concepts/containers/container-lifecycle-hooks/)에 대해 자세히 알아보자.
+* API의 파드 / 컨테이너 상태에 대한 자세한 내용은 [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
+그리고
+[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)를 참고한다.
diff --git a/content/ko/docs/concepts/workloads/pods/pod-overview.md b/content/ko/docs/concepts/workloads/pods/pod-overview.md
deleted file mode 100644
index bf52e77c2a..0000000000
--- a/content/ko/docs/concepts/workloads/pods/pod-overview.md
+++ /dev/null
@@ -1,120 +0,0 @@
----
-title: 파드(Pod) 개요
-content_type: concept
-weight: 10
-card:
- name: concepts
- weight: 60
----
-
-
-이 페이지는 쿠버네티스 객체 모델 중 가장 작은 배포 가능한 객체인 `파드` 에 대한 개요를 제공한다.
-
-
-
-
-## 파드에 대해 이해하기
-
-*파드* 는 쿠버네티스 애플리케이션의 기본 실행 단위이다. 쿠버네티스 객체 모델 중 만들고 배포할 수 있는 가장 작고 간단한 단위이다. 파드는 {{< glossary_tooltip term_id="cluster" text="클러스터" >}} 에서의 Running 프로세스를 나타낸다.
-
-파드는 애플리케이션 컨테이너(또는, 몇몇의 경우, 다중 컨테이너), 저장소 리소스, 특정 네트워크 정체성(IP 주소) 및 컨테이너가 동작하기 위해 만들어진 옵션들을 캡슐화 한다. 파드는 배포의 단위를 말한다. 아마 단일 {{< glossary_tooltip text="컨테이너" term_id="container" >}}로 구성되어 있거나, 강하게 결합되어 리소스를 공유하는 소수의 컨테이너로 구성되어 있는 *쿠버네티스에서의 애플리케이션 단일 인스턴스* 를 의미한다.
-
-[도커](https://www.docker.com)는 쿠버네티스 파드에서 사용되는 가장 대표적인 컨테이너 런타임이지만, 파드는 다른 [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/) 역시 지원한다.
-
-
-쿠버네티스 클러스터 내부의 파드는 주로 두 가지 방법으로 사용된다.
-
-* **단일 컨테이너만 동작하는 파드**. "단일 컨테이너 당 한 개의 파드" 모델은 쿠버네티스 사용 사례 중 가장 흔하다. 이 경우, 한 개의 파드가 단일 컨테이너를 감싸고 있다고 생각할 수 있으며, 쿠버네티스는 컨테이너가 아닌 파드를 직접 관리한다고 볼 수 있다.
-* **함께 동작하는 작업이 필요한 다중 컨테이너가 동작하는 파드**. 아마 파드는 강하게 결합되어 있고 리소스 공유가 필요한 다중으로 함께 배치된 컨테이너로 구성되어 있을 것이다. 이렇게 함께 배치되어 설치된 컨테이너는 단일 결합 서비스 단위일 것이다. 한 컨테이너는 공유 볼륨에서 퍼블릭으로 파일들을 옮기고, 동시에 분리되어 있는 "사이드카" 컨테이너는 그 파일들을 업데이트 하거나 복구한다. 파드는 이 컨테이너와 저장소 리소스들을 한 개의 관리 가능한 요소로 묶는다.
-
-각각의 파드는 주어진 애플리케이션에서 단일 인스턴스로 동작하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(더 많은 인스턴스를 실행해서 더 많은 전체 리소스를 제공하는 것), 각 인스턴스 당 한 개씩 다중 파드를 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 _복제_ 라고 한다.
-복제된 파드는 일반적으로 워크로드 리소스와 해당 {{< glossary_tooltip text="_컨트롤러_" term_id="controller" >}}에 의해 그룹으로 생성과 관리된다.
-쿠버네티스가 컨트롤러를 사용해서 워크로드의 확장과 복구를 구현하는 방법에 대한 자세한 내용은 [파드와 컨트롤러](#파드와-컨트롤러)를 참고한다.
-
-## 어떻게 파드가 다중 컨테이너를 관리하는가
-
-파드는 결합도가 있는 단위의 서비스를 형성하는 다중 협력 프로세스(컨테이너)를 지원하도록 디자인 되었다. 파드 내부의 컨테이너는 자동으로 동일한 물리적 또는 가상의 머신의 클러스터에 함께 배치되고 스케쥴된다. 컨테이너는 리소스와 의존성 공유, 다른 컨테이너와의 통신 그리고 언제,어떻게 조절하는지를 공유할 수 있다.
-
-단일 파드 내부에서 함께 배치되고 관리되는 컨테이너 그룹은 상대적으로 심화된 사용 예시임에 유의하자. 컨테이너가 강하게 결합된 특별한 인스턴스의 경우에만 이 패턴을 사용하는게 좋다. 예를 들어, 공유 볼륨 내부 파일의 웹 서버 역할을 하는 컨테이너와 원격 소스로부터 그 파일들을 업데이트하는 분리된 "사이드카" 컨테이너가 있는 경우 아래 다이어그램의 모습일 것이다.
-
-{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}}
-
-몇몇의 파드는 {{< glossary_tooltip text="init containers" term_id="init-container" >}} 뿐만 아니라 {{< glossary_tooltip text="app containers" term_id="app-container" >}} 도 가진다. 초기 컨테이너는 앱 컨테이너 시작이 완료되기 전에 동작한다.
-
-파드는 같은 파드 안에 속한 컨테이너에게 두 가지 공유 리소스를 제공한다. *네트워킹* 과 *저장소*.
-
-#### 네트워킹
-
-각각의 파드는 각 주소 패밀리의 고유한 IP 주소를 할당 받는다. 한 파드 내부의 모든 컨테이너는 네트워크 네임스페이스와 IP주소 및 네트워크 포트를 공유한다. *파드 안에 있는* 컨테이너는 다른 컨테이너와 `localhost` 를 통해서 통신할 수 있다. 특정 파드 안에 있는 컨테이너가 *파드 밖의* 요소들과 통신하기 위해서는, 네트워크 리소스를 어떻게 쓰고 있는지 공유해야 한다(예를 들어 포트 등).
-
-#### 저장소
-
-파드는 공유 저장소 집합인 {{< glossary_tooltip text="볼륨" term_id="volume" >}}을 명시할 수 있다. 파드 내부의 모든 컨테이너는 공유 볼륨에 접근할 수 있고, 그 컨테이너끼리 데이터를 공유하는 것을 허용한다. 또한 볼륨은 컨테이너가 재시작되어야 하는 상황에도 파드 안의 데이터가 영구적으로 유지될 수 있게 한다. 쿠버네티스가 어떻게 파드 안의 공유 저장소를 사용하는지 보려면 [볼륨](/ko/docs/concepts/storage/volumes/)을 참고하길 바란다.
-
-## 파드 작업
-
-직접 쿠버네티스에서 싱글톤 파드이더라도 개별 파드를 만들 일이 거의 없을 것이다. 그 이유는 파드가 상대적으로 수명이 짧고 일시적이기 때문이다. 파드가 만들어지면(직접 만들거나, {{< glossary_tooltip text="_컨트롤러_" term_id="controller" >}}에 의해서 간접적으로 만들어지거나), 그것은 클러스터의 {{< glossary_tooltip term_id="node" >}}에서 동작할 것이다. 파드는 프로세스가 종료되거나, 파드 오브젝트가 삭제되거나, 파드가 리소스의 부족으로 인해 *축출되거나*, 노드에 장애가 생기지 않는 한 노드에 남아있다.
-
-{{< note >}}
-파드 내부에서 재시작되는 컨테이너를 파드와 함께 재시작되는 컨테이너로 혼동해서는 안된다. 파드는 프로세스가 아니라, 컨테이너를 실행하는 환경이다. 파드는 삭제될 때까지 유지된다.
-{{< /note >}}
-
-파드는 스스로 자신을 치료하지 않는다. 만약 파드가 스케줄링된 노드에 장애가 생기거나, 스케쥴링 동작이 스스로 실패할 경우 파드는 삭제된다. 그와 비슷하게, 파드는 리소스나 노드의 유지 부족으로 인해 축출되는 상황에서 살아남지 못할 것이다. 쿠버네티스는 상대적으로 일시적인 파드 인스턴스를 관리하는 작업을 처리하는 *컨트롤러* 라고 하는 고수준의 추상적 개념을 사용한다. 즉, 파드를 직접적으로 사용할 수 있지만, 컨트롤러를 사용하여 파드를 관리하는 것이 쿠버네티스에서는 훨씬 더 보편적이다.
-
-### 파드와 컨트롤러
-
-워크로드 리소스를 사용해서 여러 파드를 생성하고 관리할 수 있다. 리소스 컨트롤러는 파드 장애 발생 시 복제, 롤아웃, 자동 복구를 처리한다. 예를 들어, 노드에 장애가 발생하면, 컨트롤러는 해당 노드의 파드는 작동을 멈추고 교체용 파드를 생성한다는 것을 알게 된다. 스케줄러는 교체용 파드를 정상적인 노드에 배치하게 된다.
-
-다음은 하나 이상의 파드를 관리하는 워크로드 리소스의 예이다.
-
-* {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}
-* {{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}}
-* {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}}
-
-
-## 파드 템플릿
-
-{{< glossary_tooltip text="워크로드" term_id="workload" >}} 리소스에 대한 컨트롤러는 파드 템플릿으로 파드를 생성하고
-사용자를 대신해서 이러한 파드를 관리한다.
-
-파드템플릿은 파드를 생성하기 위한 명세이며
-[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/),
-[잡](/ko/docs/concepts/jobs/run-to-completion-finite-workloads/) 그리고
-[데몬셋](/ko/docs/concepts/workloads/controllers/daemonset/)과 같은 워크로드 리소스에 포함되어 있다.
-
-워크로드 리소스의 각 컨트롤러는 워크로드 오브젝트 내부의 파드템플릿을 사용해서 실제 파드를 만든다. 파드템플릿은 앱을 실행하는 데 사용되는 모든 워크로드 리소스의 의도하는 상태의 일부이다.
-
-아래 샘플은 하나의 컨테이너를 시작하는 `template` 이 있는 간단한 잡에 대한 매니페스트이다. 파드의 컨테이너가 메시지를 출력한 후 일시 중지하게 된다.
-
-```yaml
-apiVersion: batch/v1
-kind: Job
-metadata:
- name: hello
-spec:
- template:
- # 이것이 파드 템플릿이다.
- spec:
- containers:
- - name: hello
- image: busybox
- command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
- restartPolicy: OnFailure
- # 여기가 파드 템플릿의 끝이다.
-```
-
-파드 템플릿을 수정하거나 새 파드 템플릿으로 전환해도 이미 존재하는 파드에는 영향을 미치지 않는다. 파드는 템플릿 업데이트를 직접 수신하지 않지만, 대신에 수정된 파드 템플릿과 일치하는 새 파드가 생성된다.
-
-예를 들어, 디플로이먼트 컨트롤러는 실행 중인 파드가 현재 파드 템플릿과 일치하는지 확인한다. 템플릿이 업데이트되면, 컨트롤러는 업데이트된 템플릿을 기반으로 기존 파드를 제거하고 새 파드를 생성한다. 각 워크로드 컨트롤러는 파드 템플릿의 변경사항을 처리하기 위해 자체 규칙을 구현한다.
-
-노드에서 "kubelet"이 파드 템플릿과 업데이트에 관련된 세부 정보를 직접 관찰하거나 관리하지 않으며, 이러한 세부 정보는 추상화되지 않는다. 이러한 추상화와 분리는 시스템 시맨틱을 단순화하며, 기존 코드를 변경하지 않고 클러스터의 동작을 확장할 수 있도록 한다.
-
-
-
-## {{% heading "whatsnext" %}}
-
-* [파드](/ko/docs/concepts/workloads/pods/pod/)에 대해 더 배워보자.
-* [분산 시스템 툴킷: 복합 컨테이너의 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)은 둘 이상의 컨테이너가 있는 파드의 공통 레이아웃에 대해 설명한다.
-* 파드의 동작에 대해 더 알아보자.
- * [파드 종료](/ko/docs/concepts/workloads/pods/pod/#파드의-종료)
- * [파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)
diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
index d92b18a1bf..8fe6e45134 100644
--- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@@ -1,7 +1,7 @@
---
title: 파드 토폴로지 분배 제약 조건
content_type: concept
-weight: 50
+weight: 40
---
diff --git a/content/ko/docs/concepts/workloads/pods/pod.md b/content/ko/docs/concepts/workloads/pods/pod.md
deleted file mode 100644
index e3464ff5cf..0000000000
--- a/content/ko/docs/concepts/workloads/pods/pod.md
+++ /dev/null
@@ -1,206 +0,0 @@
----
-title: 파드
-content_type: concept
-weight: 20
----
-
-
-
-_파드_ 는 쿠버네티스에서 생성되고 관리될 수 있는
-배포 가능한 최소 컴퓨팅 단위이다.
-
-
-
-
-
-
-## 파드는 무엇인가?
-
-_파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로) 하나 이상의(도커 컨테이너 같은)
-{{< glossary_tooltip text="컨테이너" term_id="container" >}} 그룹이다.
-이 그룹은 스토리지/네트워크를 공유하고,
-해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다.
-파드의 콘텐츠들은 항상 함께 배치되고 같이 스케줄되며, 공유 컨텍스트 내에서 구동된다.
-파드는 애플리케이션에 특화된 "논리 호스트"를 모델로 하고 있다.
-이것은 하나 또는 강하게 서로 결합되어 있는 여러 애플리케이션 컨테이너를 포함한다.
-컨테이너 이전의 세상에서 같은 물리적 또는 가상의 머신에서 실행되는 것은
-같은 논리적 호스트에서 실행되고 있는 것을 의미한다.
-
-쿠버네티스는 도커 이외에도 많은 컨테이너 런타임을 지원하지만,
-도커는 가장 일반적으로 알려진 런타임이므로 도커 용어로 파드를 설명하는 것이 도움이 된다.
-
-파드의 공유 컨텍스트는 리눅스 네임스페이스, 컨트롤 그룹(cgroup) 및
-도커 컨테이너를 격리하는 것과 같이 잠재적으로 다른 격리 요소들이다.
-파드의 컨텍스트 내에서 개별 응용 프로그램은
-추가적으로 하위 격리가 적용된다.
-
-파드 안의 컨테이너들은 IP주소와 포트 공간을 공유하고,
-서로를 `localhost` 를 통해 찾을 수 있다.
-그들은 또한 SystemV 세마포어나, POSIX 공유 메모리와 같은 표준 프로세스 간 통신 방식으로
-서로 통신할 수 있다.
-다른 파드의 컨테이너에는 고유한 IP 주소가 있고,
-[특별한 구성](/ko/docs/concepts/policy/pod-security-policy/) 없이는 IPC에 의해서 통신 할 수 없다.
-컨테이너는 주로 서로의 IP 주소를 통해 소통한다.
-
-또한 파드 안의 애플리케이션은 파드의 일부로 정의되어,
-각각의 애플리케이션의 파일시스템에 마운트 할 수 있도록 만들어진
-공유 볼륨에 엑세스 할 수 있다.
-
-[도커](https://www.docker.com/)의 구조 관점에서 보면
-파드는 공유 네임스페이스와 공유 [볼륨](/ko/docs/concepts/storage/volumes/)을 가진
-도커 컨테이너 그룹으로 모델링 된다.
-
-개별 애플리케이션 컨테이너와 같이, 파드는 상대적으로 수명이 짧은 엔터티로 간주된다.
-[파드의 생애](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에서 논의된 것과 같이,
-파드가 만들어지고 고유한 ID(UID)가 할당되고,
-재시작 정책에 따라서 종료 또는 삭제될 때 까지 노드에 스케줄된다.
-노드가 종료되면 해당 노드로 스케줄 된 파드는 제한시간이 지나면 삭제되도록 스케줄된다.
-해당 파드(UID로 정의된)는 새로운 노드에 "리스케줄(reschedule)" 되지 않는다.
-대신, 동일한 파드로,
-원한다면 이름도 동일하게, 교체될 수 있지만, 새로운 UID가 부여된다.
-더 자세한 내용은 [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)를 참조한다.
-
-볼륨과 같이 파드와 동일한 수명이 있다고 하면,
-UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것을 의미한다.
-어떤 이유로든 해당 파드가 삭제 된 경우,
-동일한 대체품이 만들어 지더라도 관련된 것(예 : 볼륨) 또한 삭제되고 새로 만들어진다.
-
-{{< figure src="/images/docs/pod.svg" title="파드 다이어그램" width="50%" >}}
-
-*파일 풀러(Puller)와 컨테이너 간 공유 스토리지로 퍼시스턴트 볼륨을 사용하는
-웹 서버를 포함하는 멀티 컨테이너 파드.*
-
-## 파드의 의의
-
-### 관리
-
-파드는 응집력 있는 서비스 단위를 형성하는 여러 개의 협력 프로세스를 모델로 한다.
-파드는 그 구성 요소 집합보다 높은 수준의 추상화를 제공함으로써
-애플리케이션 배포 및 관리를 단순화한다.
-파드는 전개 단위, 수평 확장 및 복제를 한다.
-공동 스케줄링,
-공유된 생애주기(예: 종료), 조정된 복제, 자원 공유 및 종속성 관리는
-파드의 컨테이너에 대해 자동으로 처리된다.
-
-### 리소스 공유 및 통신
-
-파드는 그 구성 요소 간에 데이터 공유 및 통신이 가능하다.
-
-파드의 모든 애플리케이션은 동일한 네트워크 네임스페이스(동일한 IP 및 포트 공간)를 사용하므로
-서로를 찾고 통신하는데 `localhost`를 사용할 수 있다.
-이 때문에 파드의 애플리케이션은 포트 사용을 조정 해야한다.
-각 파드에는 다른 물리적 컴퓨터 및 파드들과
-네트워크를 통해 통신할 수 있는 공유 네트워크 공간의 IP 주소가 있다.
-
-호스트 이름은 파드 안에있는 애플리케이션 컨테이너의 파드 이름으로 설정된다.
-더 자세한 내용은
-[네트워킹](/ko/docs/concepts/cluster-administration/networking/) 섹션을 참조한다.
-
-파드는 파드 안의 애플리케이션 컨테이너를 정의하는 것 이외에도 공유 저장 볼륨의 집합을 지정한다.
-볼륨은 컨테이너가 재시작되어도 데이터가 생존할 수 있도록 하고,
-파드 안의 애플리케이션들끼리 데이터를 공유할 수 있게 해준다.
-
-## 파드의 사용
-
-파드는 수직으로 통합 된 애플리케이션 스택(예 : LAMP)을 호스팅하는 데 사용할 수 있다.
-하지만, 주요 동기는 공동 배치 및 공동 관리되는 헬퍼(helper) 프로그램을 지원하는 것이다.
-예를 들면,
-
-* 컨텐츠 관리 시스템, 파일과 데이터 로더, 로컬 캐시 관리 등.
-* 로그와 백업 체크포인트, 압축, 로테이션, 스냅샷 등.
-* 데이터 변동 감시자, 로그 추적자, 로깅 및 모니터링 어댑터, 이벤트 관리 등.
-* 프록시, 브릿지, 어댑터
-* 컨트롤러, 매니저, 설정, 업데이트
-
-일반적으로 하나의 파드는
-동일한 애플리케이션의 여러 인스턴스를 실행하도록 사용하지 않는다.
-
-더 자세한 설명을 보려면
-[분산 시스템 툴킷: 복합 컨테이너를 위한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)을
-참조한다.
-
-## 고려된 대안
-
-_싱글 (도커)컨테이너에서 다중 프로그램을 실행하지 않는 이유는 무엇인가?_
-
-1. 투명도. 인프라에 파드 내의 컨테이너를 표시하면,
- 인프라에서 프로세스 관리와 리소스 모니터링과 같은 기능을
- 제공할 수 있다.
- 이 기능들은 사용자에게 편의를 제공한다.
-1. 소프트웨어 의존성 분리. 각각의 컨테이너는 독립적으로 버전 관리,
- 재빌드, 재배포될 수 있다.
- 언젠가는 쿠버네티스에서 개별 컨테이너의 실시간 업데이트도 할 수 있을 것이다.
-1. 사용의 편의성. 사용자는 자신의 프로세스 매니저를 따로 실행 할 필요가 없고,
- 시그널이나 종료 코드(exit-code) 전파 등에 대해 걱정할 필요가 없다.
-1. 효율성. 인프라측에서 많은 책임을 가지고 있으므로,
- 컨테이너는 더 가벼워 질 수 있다.
-
-_컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하지 않는 이유는 무엇인가?_
-
-이와 같은 접근은 공동위치를 제공하지만,
-리소스 공유, IPC, 보장된 생애 공유, 관리의 단순화와 같은
-파드가 가진 대부분의 장점을 제공하지 못한다.
-
-## 파드의 내구성 (또는 결핍)
-
-파드는 내구성이 강한 엔터티로 취급하지는 않는다. 파드는 스케줄링 실패, 노드 장애 또는 그 밖에 리소스가 부족해서, 또는 노드 정비를 위한 경우와 같이 축출(eviction)되는 상황에서는 살아남을 수 없을 것이다.
-
-일반적으로 사용자는 파드를 직접 만들 필요가 없다.
-싱글톤이라도 대부분 [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/)와 같은 컨트롤러를 사용한다.
-컨트롤러는 클러스터 범위에서
-복제와 롤아웃 관리 뿐 만 아니라 자가치료 기능도 제공한다.
-[스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)과 같은
-컨트롤러는 상태를 저장하는 파드에도
-위와 같은 기능 제공을 할 수 있다.
-
-사용자 지향적으로 선정된 API를 사용하는 것은 [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)와 [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)를 비롯한 클러스터 스케줄링 시스템에서 비교적 일반적이다.
-
-파드는 아래와 같은 사항들을 용이하게 하기 위해 노출이 된다:
-
-* 스케줄러 및 컨트롤러 연결 가능
-* "프록시" 없이 컨트롤러 API를 통한 파드-레벨 수준의 동작 지원
-* 부트스트랩과 같이 컨트롤러의 생애와 파드의 생애 분리
-* 컨트롤러와 서비스의 분리 — 파드를 감시하는 엔드 포인트 컨트롤러
-* 클러스터 레벨과 kubelet 레벨 기능의 깔끔한 구성 — Kubelet은 효과적인 "파드 컨트롤러" 이다.
-* 계획된 삭제 또는 이미지 프리페칭과 같이 파드가 종료되기 전에 교체가 될 것이고, 삭제 전에는 확실히 교체되는 고가용성 애플리케이션.
-
-## 파드의 종료
-
-파드는 클러스터의 노드에서 실행 중인 프로세스를 나타내므로, 이러한 프로세스가 더 이상 필요하지 않을 때(KILL 시그널로 강제로 죽여서 정리할 기회를 주지 않는 것과 대조적으로) 정상적으로 종료 되도록 허용하는 것이 중요하다. 사용자는 삭제를 요청할 수 있어야 하며, 프로세스가 종료 될 때 알 수 있어야 할 뿐만 아니라, 삭제가 결국 완료되는 것을 확인할 수 있어야 한다. 사용자가 파드를 삭제하도록 요청하면, 시스템은 파드가 강제로 종료되기 전에 예정된 유예 기간을 기록하고, TERM 시그널이 각 컨테이너의 주 프로세스로 전송된다. 유예 기간이 만료되면, KILL 신호가 해당 프로세스로 전송되고, 파드가 API 서버에서 삭제된다. 프로세스가 종료되기를 기다리는 동안 Kubelet 또는 컨테이너 관리자가 다시 시작되면, 종료가 전체 유예 기간과 함께 재시도된다.
-
-흐름 예시:
-
-1. 사용자가 파드 삭제 명령을 내린다. (기본 유예 기간 30초)
-1. API 서버 안의 파드는 유예 기간에 따라, 시간을 넘은(죽은) 것으로 간주되는 파드가 업데이트된다.
-1. 클라이언트 명령에서 파드는 "Terminating" 이라는 문구를 나타낸다.
-1. (3번 단계와 동시에) Kubelet은 파드가 2번 단계에서 설정된 시간으로 인해 Terminating으로 표시되는 것을 확인하면 파드 종료 단계를 시작한다.
- 1. 파드의 컨테이너 중 하나에 [preStop hook](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)이 정의된 경우, 해당 컨테이너 내부에서 실행된다. 유예 기간이 만료된 후에도 `preStop` 훅이 계속 실행 중이면, 유예 기간을 짧게(2초)를 1회 연장해서 2번 단계를 실행한다.
- 1. 파드의 프로세스에 TERM 시그널이 전달된다. 파드의 모든 컨테이너가 TERM 시그널을 동시에 받기 때문에 컨테이너의 종료 순서가 중요한 경우에는 `preStop` 훅이 각각 필요할 수 있음을 알아두자. 만약 `preStop` 훅을 완료하는 데 더 오랜 시간이 필요한 경우 `terminationGracePeriodSeconds` 를 수정해야 한다.
-1. (3번 단계와 동시에) 파드는 서비스를 위해 엔드포인트 목록에서 제거되며, 더 이상 레플리케이션 컨트롤러가 실행 중인 파드로 고려하지 않는다. 느리게 종료되는 파드는 로드밸런서(서비스 프록시와 같은)의 로테이션에서 지워지기 때문에 트래픽을 계속 처리할 수 없다.
-1. 유예 기간이 만료되면, 파드에서 실행중이던 모든 프로세스가 SIGKILL로 종료된다.
-1. Kubelet은 유예기간 0(즉시 삭제)을 세팅하여 API 서버에서 파드 삭제를 끝낼 것이다. API 서버에서 사라진 파드는 클라이언트에게서 더 이상 보이지 않는다.
-
-기본적으로 모든 삭제는 30초 이내에 끝이 난다. `kubectl delete` 명령은 사용자가 기본 설정을 오버라이드하고 자신이 원하는 값을 설정할 수 있게 해주는 `--grace-period=` 옵션을 지원한다. `0` 값은 파드를 [강제로 삭제한다](/ko/docs/concepts/workloads/pods/pod/#파드-강제-삭제).
-kubectl 1.5 버전 이상에서는, 강제 삭제 수행을 위해서 반드시 `--grace-period=0` 와 함께 추가 플래그인 `--force` 를 지정해야 한다.
-
-### 파드 강제 삭제
-
-파드 강제 삭제는 클러스터 및 etcd에서 즉시 삭제하는 것으로 정의된다. 강제 삭제가 수행되면, API 서버는 kubelet에서 실행 중이던 노드에서 파드가 종료되었다는 확인을 기다리지 않는다. API에서 파드를 즉시 제거하므로 동일한 이름으로 새 파드를 만들 수 있다. 노드에서 즉시 종결되도록 설정된 파드에는 강제 삭제되기 전에 짧은 유예 기간이 주어진다.
-
-강제 삭제는 일부 파드의 경우 잠재적으로 위험할 수 있으므로 주의해서 수행해야 한다. 스테이트풀셋 파드의 경우 [스테이트풀셋 파드 삭제](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한 작업 문서를 참조한다.
-
-## 파드 컨테이너의 특권(Privileged) 모드
-
-파드의 모든 컨테이너는 컨테이너 스펙의 [시큐리티 콘텍스트(security context)](/docs/tasks/configure-pod-container/security-context/)의 `privileged` 플래그를 사용하여 특권 모드를 사용할 수 있다. 이것은 네트워크 스택을 조작하고 장치에 액세스하는 것과 같은 리눅스 기능을 사용하려는 컨테이너에 유용하다. 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스에서 사용할 수 있는 거의 동일한 권한을 갖는다. 특권 모드를 사용하면 네트워크 및 볼륨 플러그인을 kubelet에 컴파일할 필요가 없는 별도의 파드로 쉽게 만들 수 있다.
-
-{{< note >}}
-이와 같은 설정을 위해서는 컨테이너 런타임에서 반드시 특권 컨테이너 개념을 지원해야 한다.
-{{< /note >}}
-
-## API 오브젝트
-
-파드는 쿠버네티스 REST API에서 최상위 리소스이다.
-API 오브젝트에 더 자세한 정보는 아래 내용을 참조한다:
-[파드 API 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core).
-파드 오브젝트에 대한 매니페스트를 생성할때는 지정된 이름이 유효한
-[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인해야 한다.
diff --git a/content/ko/docs/concepts/workloads/pods/podpreset.md b/content/ko/docs/concepts/workloads/pods/podpreset.md
index 9793dbc52e..6fad15ece7 100644
--- a/content/ko/docs/concepts/workloads/pods/podpreset.md
+++ b/content/ko/docs/concepts/workloads/pods/podpreset.md
@@ -1,6 +1,4 @@
---
-
-
title: 파드 프리셋
content_type: concept
weight: 50
@@ -32,20 +30,20 @@ weight: 50
클러스터에서 파드 프리셋을 사용하기 위해서는 다음 사항이 반드시 이행되어야 한다.
-1. API 타입 `settings.k8s.io/v1alpha1/podpreset`을 활성화하였다.
- 예를 들면, 이것은 API 서버의 `--runtime-config` 옵션에 `settings.k8s.io/v1alpha1=true`을 포함하여 완료할 수 있다.
- minikube에서는 클러스터가 시작할 때
- `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`
- 플래그를 추가한다.
-1. 어드미션 컨트롤러 `PodPreset`을 활성화하였다. 이것을 이루는 방법 중 하나는
- API 서버를 위해서 명시된 `--enable-admission-plugins` 옵션에 `PodPreset`을 포함하는 것이다.
- minikube에서는 클러스터가 시작할 때
+1. API 타입 `settings.k8s.io/v1alpha1/podpreset`을 활성화하였다.
+ 예를 들면, 이것은 API 서버의 `--runtime-config` 옵션에 `settings.k8s.io/v1alpha1=true`을 포함하여 완료할 수 있다.
+ minikube에서는 클러스터가 시작할 때
+ `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true`
+ 플래그를 추가한다.
+1. 어드미션 컨트롤러 `PodPreset`을 활성화하였다. 이것을 이루는 방법 중 하나는
+ API 서버를 위해서 명시된 `--enable-admission-plugins` 옵션에 `PodPreset`을 포함하는 것이다.
+ minikube에서는 클러스터가 시작할 때
- ```shell
- --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
- ```
+ ```shell
+ --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
+ ```
- 플래그를 추가한다.
+ 플래그를 추가한다.
## 어떻게 동작하는가
@@ -64,31 +62,28 @@ weight: 50
수정되었음을 표시한다. 해당 어노테이션은 다음의 양식을 따른다.
`podpreset.admission.kubernetes.io/podpreset-<파드-프리셋 이름>: "<리소스 버전>"`.
-각 파드는 0개 이상의 파드 프리셋에 일치될 수 있고, 각 `PodPreset`은 0개 이상의
-파드에 적용될 수 있다. 하나의 `PodPreset`이 한 개 이상의 파드에 적용되었을
-때, 쿠버네티스는 해당 파드의 스펙을 수정한다. `Env`, `EnvFrom`, `VolumeMounts`의
+각 파드는 0개 이상의 파드프리셋에 일치될 수 있고, 각 파드프리셋은 0개 이상의
+파드에 적용될 수 있다. 하나의 파드프리셋이 한 개 이상의 파드에 적용되었을
+때, 쿠버네티스는 해당 파드의 스펙을 수정한다. `env`, `envFrom`, `volumeMounts`의
변경에 대해서는, 쿠버네티스가 파드 내의 모든 컨테이너의 컨테이너 스펙을
-수정한다. `Volume` 변경에 대해서는, 쿠버네티스는 해당 파드의 스펙을 수정한다.
+수정한다. `volume` 변경에 대해서는, 쿠버네티스는 해당 파드의 스펙을 수정한다.
{{< note >}}
파드 프리셋은 적절한 경우 파드 스펙의 다음 필드를 수정할 수도 있다.
- `.spec.containers` 필드
-- `initContainers` 필드(쿠버네티스 버전 1.14.0 이후에서 필요)
+- `.spec.initContainers` 필드
{{< /note >}}
### 특정 파드의 파드 프리셋 비활성화하기
어떠한 파드 프리셋 변이에 의해서도 파드에 변경이 일어나지 않게 하고 싶은 경우가
-있을 것이다. 이 경우에는, 다음과 같은 양식으로 어노테이션을 파드 스펙에
+있을 것이다. 이 경우에는, 다음과 같은 양식으로 어노테이션을 파드의 `.spec` 에
추가한다. `podpreset.admission.kubernetes.io/exclude: "true"`.
## {{% heading "whatsnext" %}}
-
[파드프리셋을 사용하여 파드에 데이터 주입하기](/docs/tasks/inject-data-application/podpreset/)를 본다.
배경에 대한 자세한 정보를 위해서는, [파드프리셋을 위한 디자인 제안](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md)을 본다.
-
-
diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md
index 714ae70f36..d5f424cdc7 100644
--- a/content/ko/docs/contribute/_index.md
+++ b/content/ko/docs/contribute/_index.md
@@ -53,8 +53,8 @@ card:
- [기여 개요](/ko/docs/contribute/new-content/overview/)를 읽고
기여할 수 있는 다양한 방법에 대해 알아봅니다.
-- [kubernetes/website에 기여하기](https://github.com/kubernetes/website/contribute)를
- 참조하여 좋은 진입점이 되는 이슈를 찾을 수 있습니다.
+- [`kubernetes/website` 이슈 목록](https://github.com/kubernetes/website/issues/)을
+ 확인하여 좋은 진입점이 되는 이슈를 찾을 수 있습니다.
- 기존 문서에 대해 [GitHub을 사용해서 풀 리퀘스트 열거나](/ko/docs/contribute/new-content/new-content/#github을-사용하여-변경하기)
GitHub에서의 이슈 제기에 대해 자세히 알아봅니다.
- 정확성과 언어에 대해 다른 쿠버네티스 커뮤니티 맴버의
diff --git a/content/ko/docs/contribute/participate/_index.md b/content/ko/docs/contribute/participate/_index.md
index f66c7f952b..ef271ca31c 100644
--- a/content/ko/docs/contribute/participate/_index.md
+++ b/content/ko/docs/contribute/participate/_index.md
@@ -106,7 +106,7 @@ PR 소유자에게 조언하는데 활용된다.
- 모든 쿠버네티스 멤버는 코멘트에 `/lgtm` 을 추가해서 `lgtm` 레이블을 추가할 수 있다.
- SIG Docs 승인자들만이 코멘트에 `/approve` 를
추가해서 풀 리퀘스트를 병합할 수 있다. 일부 승인자들은
- [PR Wrangler](/ko/docs/contribute/advanced/#일주일-동안-pr-랭글러-wrangler-되기) 또는 [SIG Docs 의장](#sig-docs-의장)과
+ [PR Wrangler](/ko/docs/contribute/participate/pr-wranglers/) 또는 [SIG Docs 의장](#sig-docs-의장)과
같은 특정 역할도 수행한다.
diff --git a/content/ko/docs/contribute/participate/pr-wranglers.md b/content/ko/docs/contribute/participate/pr-wranglers.md
index 4581400ea3..d614905f0a 100644
--- a/content/ko/docs/contribute/participate/pr-wranglers.md
+++ b/content/ko/docs/contribute/participate/pr-wranglers.md
@@ -36,17 +36,30 @@ PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다.
이 쿼리들을 수행하여 작업한 후에는, 리뷰할 나머지 PR 목록은 일반적으로 작다.
이 쿼리들은 특히 현지화 PR을 제외한다. 모든 쿼리는 마지막 쿼리를 제외하고 메인 브렌치를 대상으로 한다.
-- [CLA 서명 없음, 병합할 수 없음](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen):
+- [CLA 서명 없음, 병합할 수 없음](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3Alanguage%2Fen):
CLA에 서명하도록 기여자에게 상기시킨다. 봇과 사람이 이미 알렸다면, PR을 닫고
CLA에 서명한 후 PR을 열 수 있음을 알린다.
**작성자가 CLA에 서명하지 않은 PR은 리뷰하지 않는다!**
-- [LGTM 필요](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+):
+- [LGTM 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+-label%3Algtm):
멤버의 LGTM이 필요한 PR을 나열한다. PR에 기술 리뷰가 필요한 경우, 봇이 제안한 리뷰어 중 한 명을
지정한다. 콘텐츠에 대한 작업이 필요하다면, 제안하거나 인라인 피드백을 추가한다.
-- [LGTM 보유, 문서 승인 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm):
+- [LGTM 보유, 문서 승인 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+label%3Algtm+):
병합을 위해 `/approve` 코멘트가 필요한 PR을 나열한다.
-- [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): 명확한 결격 사유가 없는 메인 브랜치에 대한 PR을 나열한다. ([XS, S, M, L, XL, XXL] 크기의 PR을 작업할 때 크기 레이블에서 "XS"를 변경한다)
-- [메인 브랜치이외의 브랜치에 대한 PR](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): `dev-` 브랜치에 대한 것일 경우, 곧 출시될 예정인 릴리스이다. `/assign @` 을 사용하여 [문서 릴리스 관리자](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles)를 할당한다. 오래된 브랜치에 대한 PR인 경우, PR 작성자가 가장 적합한 브랜치를 대상으로 하고 있는지 여부를 파악할 수 있도록 도와준다.
+- [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22): 명확한 결격 사유가 없는 메인 브랜치에 대한 PR을 나열한다. ([XS, S, M, L, XL, XXL] 크기의 PR을 작업할 때 크기 레이블에서 "XS"를 변경한다)
+- [메인 브랜치이외의 브랜치에 대한 PR](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3Alanguage%2Fen+-base%3Amaster): `dev-` 브랜치에 대한 것일 경우, 곧 출시될 예정인 릴리스이다. `/assign @` 을 사용하여 [문서 릴리스 관리자](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles)를 할당한다. 오래된 브랜치에 대한 PR인 경우, PR 작성자가 가장 적합한 브랜치를 대상으로 하고 있는지 여부를 파악할 수 있도록 도와준다.
+
+### 랭글러를 위한 유용한 Prow 명령어
+
+```
+# 한글 레이블 추가
+/language ko
+
+# 둘 이상의 커밋인 경우 PR에 스쿼시 레이블 추가
+/label tide/merge-method-squash
+
+# Prow를 통해 PR 제목 변경(예: 진행 중인 작업(work-in-progress) [WIP] 또는 PR의 더 상세한 내용)
+/retitle [WIP]
+```
### 풀 리퀘스트를 종료하는 시기
diff --git a/content/ko/docs/contribute/participate/roles-and-responsibilties.md b/content/ko/docs/contribute/participate/roles-and-responsibilities.md
similarity index 100%
rename from content/ko/docs/contribute/participate/roles-and-responsibilties.md
rename to content/ko/docs/contribute/participate/roles-and-responsibilities.md
diff --git a/content/ko/docs/reference/glossary/pod.md b/content/ko/docs/reference/glossary/pod.md
index 565361ea7b..158e24c0af 100755
--- a/content/ko/docs/reference/glossary/pod.md
+++ b/content/ko/docs/reference/glossary/pod.md
@@ -2,18 +2,17 @@
title: 파드(Pod)
id: pod
date: 2018-04-12
-full_link: /ko/docs/concepts/workloads/pods/pod-overview/
+full_link: /ko/docs/concepts/workloads/pods/
short_description: >
파드는 클러스터에서 실행 중인 컨테이너의 집합을 나타낸다.
-aka:
+aka:
tags:
- core-object
- fundamental
---
가장 작고 단순한 쿠버네티스 오브젝트. 파드는 사용자 클러스터에서 동작하는 {{< glossary_tooltip text="컨테이너" term_id="container" >}}의 집합을 나타낸다.
-<!--more-->
+<!--more-->
파드는 일반적으로 하나의 기본 컨테이너를 실행하기 위해서 구성된다. 또한 파드는 로깅과 같이 보완적인 기능을 추가하기 위한 사이드카 컨테이너를 선택적으로 실행할 수 있다. 파드는 보통 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}에 의해서 관리된다.
-
diff --git a/content/ko/docs/reference/using-api/api-overview.md b/content/ko/docs/reference/using-api/api-overview.md
index d961283b99..0ac842ccc6 100644
--- a/content/ko/docs/reference/using-api/api-overview.md
+++ b/content/ko/docs/reference/using-api/api-overview.md
@@ -28,7 +28,7 @@ API 오브젝트로 취급되고,
## API 버전 규칙
필드를 없애거나 리소스 표현을 재구성하기 쉽도록,
-쿠버네티스는 `/api/v1`이나 `/apis/extensions/v1beta1`과 같이
+쿠버네티스는 `/api/v1`이나 `/apis/rbac.authorization.k8s.io/v1alpha1`과 같이
각각 다른 API 경로에서 복수의 API 버전을 지원한다.
아래를 위해 버전은 리소스나 필드 수준보다는 API 수준에서 설정된다.
@@ -76,7 +76,7 @@ API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다.
현재 다음과 같은 다양한 API 그룹이 사용되고 있다:
-* *핵심* (또는 *레거시*라고 불리는) 그룹은 `apiVersion: v1`와 같이 `apiVersion` 필드에 명시되지 않고 REST 경로 `/api/v1`에 있다.
+* *핵심* (또는 *레거시* 라고 불리는) 그룹은 `apiVersion: v1`와 같이 `apiVersion` 필드에 명시되지 않고 REST 경로 `/api/v1`에 있다.
* 이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며 `apiVersion: $GROUP_NAME/$VERSION`을 사용한다
(예를 들어 `apiVersion: batch/v1`). 지원되는 API 그룹 전체의 목록은 [쿠버네티스 API 참조 문서](/ko/docs/reference/)에서 확인할 수 있다.
@@ -101,11 +101,3 @@ API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다.
그룹이나 리소스를 활성화 또는 비활성화하려면, apiserver와 controller-manager를 재시작하여
`--runtime-config` 변경을 반영해야 한다.
{{< /note >}}
-
-## extensions/v1beta1 그룹 내 특정 리소스 활성화 하기
-
-데몬셋, 디플로이먼트, 스테이트풀셋, 네트워크정책, 파드보안정책 그리고 레플리카셋은 `extensions/v1beta1` API 그룹에서 기본적으로 비활성화되어있다.
-예시: 디플로이먼트와 데몬셋의 활성화 설정은
-`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true` 를 입력한다.
-
-{{< note >}}개별 리소스의 활성화/비활성화는 레거시 문제로 `extensions/v1beta1` API 그룹에서만 지원된다. {{< /note >}}
diff --git a/content/ko/docs/setup/best-practices/cluster-large.md b/content/ko/docs/setup/best-practices/cluster-large.md
index d29c8f49c2..39efd52b80 100644
--- a/content/ko/docs/setup/best-practices/cluster-large.md
+++ b/content/ko/docs/setup/best-practices/cluster-large.md
@@ -17,7 +17,7 @@ weight: 20
클러스터는 쿠버네티스 에이전트가 구동하는 노드(물리 또는 가상 머신)의 집합이며, "마스터"(클러스터-수준 컨트롤 플레인)에 의해 관리된다.
-보통 클러스터 내 노드 수는 플랫폼별 `config-default.sh` 파일 (예를 들면, [GCE의 `config-default.sh`](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh))에 있는 `NUM_NODES` 값에 따라 조절된다.
+보통 클러스터 내 노드 수는 플랫폼별 `config-default.sh` 파일 (예를 들면, [GCE의 `config-default.sh`](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/gce/config-default.sh))에 있는 `NUM_NODES` 값에 따라 조절된다.
하지만 단순히 값만 매우 크게 바꾼다면, 클라우드 프로바이더에 따라 셋업 스크립트가 실패할 수도 있다. 예를 들어, GCE에 배포할 때 쿼터 이슈가 발생하여 클러스터 구축이 실패할 수 있다.
@@ -77,7 +77,7 @@ AWS에서, 마스터 노드의 크기는 클러스터 시작 시에 설정된
### 애드온 자원
-[클러스터 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons)이 메모리 누수 등 노드 상의 가용한 리소스를 모두 소비하는 리소스 이슈를 방지하기 위해, 쿠버네티스는 애드온 컨테이너가 소비할 수 있는 CPU와 메모리 리소스를 제한하는 리소스 상한을 둔다(PR [#10653](http://pr.k8s.io/10653/files)과 [#10778](http://pr.k8s.io/10778/files) 참고).
+[클러스터 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons)이 메모리 누수 등 노드 상의 가용한 리소스를 모두 소비하는 리소스 이슈를 방지하기 위해, 쿠버네티스는 애드온 컨테이너가 소비할 수 있는 CPU와 메모리 리소스를 제한하는 리소스 상한을 둔다(PR [#10653](https://pr.k8s.io/10653/files)과 [#10778](https://pr.k8s.io/10778/files) 참고).
예시:
@@ -91,34 +91,32 @@ AWS에서, 마스터 노드의 크기는 클러스터 시작 시에 설정된
memory: 200Mi
```
-힙스터(Heapster)를 제외하고, 이러한 상한들은 정적이며 4-노드 클러스터에서 구동한 애드온으로부터 수집한 데이터에 기반한 것이다.([#10335](http://issue.k8s.io/10335#issuecomment-117861225) 참고). 애드온이 큰 클러스터에서 구동되면 더 많은 리소스를 소비한다([#5880](http://issue.k8s.io/5880#issuecomment-113984085) 참고). 따라서, 이러한 값의 조정 없이 큰 클러스터를 배포하면, 애드온들이 상한에 걸려 반복적으로 죽을 수 있다.
+힙스터(Heapster)를 제외하고, 이러한 상한들은 정적이며 4-노드 클러스터에서 구동한 애드온으로부터 수집한 데이터에 기반한 것이다.([#10335](https://issue.k8s.io/10335#issuecomment-117861225) 참고). 애드온이 큰 클러스터에서 구동되면 더 많은 리소스를 소비한다([#5880](https://issue.k8s.io/5880#issuecomment-113984085) 참고). 따라서, 이러한 값의 조정 없이 큰 클러스터를 배포하면, 애드온들이 상한에 걸려 반복적으로 죽을 수 있다.
많은 노드를 가진 클러스터를 생성할 때는 애드온 리소스 이슈를 피하기 위해 다음을 고려하라.
* 다음 애드온을 사용한다면, 클러스터의 크기를 확장할 때 그에 맞게 메모리와 CPU 상한을 규모를 조정하라 (전체 클러스터를 담당하는 각 레플리카는, 메모리와 CPU 사용량이 대체로 클러스터의 크기/부하에 따라 비율적으로 증가할 것이다).
- * [InfluxDB와 Grafana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
- * [kubedns, dnsmasq, 사이드카](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
- * [Kibana](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
+ * [InfluxDB와 Grafana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml)
+ * [kubedns, dnsmasq, 사이드카](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/kube-dns.yaml.in)
+ * [Kibana](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml)
* 다음 애드온들을 쓴다면 클러스터 크기에 따라 레플리카 수를 조절해준다(각각 레플리카가 여러 개 두면 늘어나는 부하를 처리하는 데 도움이 되지만, 레플리카 당 부하도 약간 늘어나게 되므로 CPU/메모리 상한을 높이는 것을 고려해보자):
- * [elasticsearch](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
+ * [elasticsearch](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/es-statefulset.yaml)
* 다음의 애드온들을 쓴다면, 클러스터 크기에 따라 각각 메모리와 CPU 상한을 조금 더 높이자(노드 당 레플리카 1개만 있어도 클러스터 부하량/크기에 따라 CPU/메모리 사용율은 조금씩 증가한다).
- * [ElasticSearch 플러그인을 적용한 FluentD](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
- * [GCP 플러그인을 적용한 FluentD](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
+ * [ElasticSearch 플러그인을 적용한 FluentD](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml)
+ * [GCP 플러그인을 적용한 FluentD](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/fluentd-gcp/fluentd-gcp-ds.yaml)
-힙스터의 리소스 상한은 클러스터 최초 크기에 기초하여 동적으로 설정된다([#16185](http://issue.k8s.io/16185)과
-[#22940](http://issue.k8s.io/22940) 참조). 힙스터에 리소스가 부족한 경우라면,
+힙스터의 리소스 상한은 클러스터 최초 크기에 기초하여 동적으로 설정된다([#16185](https://issue.k8s.io/16185)과
+[#22940](https://issue.k8s.io/22940) 참조). 힙스터에 리소스가 부족한 경우라면,
힙스터 메모리 요청량(상세내용은 해당 PR 참조)을 계산하는 공식을 적용해보자.
-애드온 컨테이너가 리소스 상한에 걸리는 것을 탐지하는 방법에 대해서는 [컴퓨트 리소스의 트러블슈팅 섹션](/ko/docs/concepts/configuration/manage-resources-containers/#문제-해결)을 참고하라.
-
-[미래](http://issue.k8s.io/13048)에는 모든 클러스터 애드온의 리소스 상한을 클러스터 크기에 맞게 설정해주고 클러스터를 키우거나 줄일 때 동적으로 조절해줄 수 있기를 기대한다.
-이런 기능들에 대한 PR은 언제든 환영한다.
+애드온 컨테이너가 리소스 상한에 걸리는 것을 탐지하는 방법에 대해서는
+[컴퓨트 리소스의 트러블슈팅 섹션](/ko/docs/concepts/configuration/manage-resources-containers/#문제-해결)을 참고하라.
### 시작 시 사소한 노드 오류 허용
-다양한 이유로(자세한 내용은 [#18969](https://github.com/kubernetes/kubernetes/issues/18969) 참고) 매우 큰 `NUM_NODES`를 주고
+다양한 이유로(자세한 내용은 [#18969](https://github.com/kubernetes/kubernetes/issues/18969) 참고) 매우 큰 `NUM_NODES`를 주고
`kube-up.sh`을 실행하면 제대로 기동되지 않은 극소수의 노드들 때문에 실패할 수 있다.
현재로서는 두 가지 선택지가 있다. 클러스터를 재시작하거나(`kube-down.sh` 한 후 다시 `kube-up.sh` ),
-`kube-up.sh` 실행 전에 환경변수 `ALLOWED_NOTREADY_NODES`를 적당한 값으로 설정해주는 것이다.
+`kube-up.sh` 실행 전에 환경변수 `ALLOWED_NOTREADY_NODES`를 적당한 값으로 설정해주는 것이다.
이렇게 하면 `NUM_NODES`에 못 미치는 경우에도 `kube-up.sh`이 성공할 수 있다.
실패 원인에 따라 일부 노드들이 늦게 결합되거나, 클러스터가 `NUM_NODES - ALLOWED_NOTREADY_NODES`의 크기로 남을 수 있다.
diff --git a/content/ko/docs/setup/best-practices/multiple-zones.md b/content/ko/docs/setup/best-practices/multiple-zones.md
index 2ccd3873a0..0693169e5d 100644
--- a/content/ko/docs/setup/best-practices/multiple-zones.md
+++ b/content/ko/docs/setup/best-practices/multiple-zones.md
@@ -74,7 +74,7 @@ federation support).
a single master node by default. While services are highly
available and can tolerate the loss of a zone, the control plane is
located in a single zone. Users that want a highly available control
-plane should follow the [high availability](/docs/admin/high-availability) instructions.
+plane should follow the [high availability](/docs/setup/production-environment/tools/kubeadm/high-availability/) instructions.
### Volume limitations
The following limitations are addressed with [topology-aware volume binding](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드).
diff --git a/content/ko/docs/setup/learning-environment/minikube.md b/content/ko/docs/setup/learning-environment/minikube.md
index 16ea2ad587..18e4811457 100644
--- a/content/ko/docs/setup/learning-environment/minikube.md
+++ b/content/ko/docs/setup/learning-environment/minikube.md
@@ -509,6 +509,4 @@ Minikube에 대한 더 자세한 정보는, [제안](https://git.k8s.io/communit
## 커뮤니티
-컨트리뷰션, 질문과 의견은 모두 환영하며 격려한다! Minikube 개발자는 [슬랙](https://kubernetes.slack.com)에 #minikube 채널(초청받으려면 [여기](http://slack.kubernetes.io/))에 상주하고 있다. 또한 [kubernetes-dev 구글 그룹 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-dev)도 있다. 메일링 리스트에 포스팅한다면 제목에 "minikube: "라는 접두어를 사용하자.
-
-
+컨트리뷰션, 질문과 의견은 모두 환영하며 격려한다! Minikube 개발자는 [슬랙](https://kubernetes.slack.com)에 `#minikube` 채널(초청받으려면 [여기](https://slack.kubernetes.io/))에 상주하고 있다. 또한 [kubernetes-dev 구글 그룹 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-dev)도 있다. 메일링 리스트에 포스팅한다면 제목에 "minikube: "라는 접두어를 사용하자.
diff --git a/content/ko/docs/setup/production-environment/tools/kops.md b/content/ko/docs/setup/production-environment/tools/kops.md
index 644ca5dae4..0df78ff580 100644
--- a/content/ko/docs/setup/production-environment/tools/kops.md
+++ b/content/ko/docs/setup/production-environment/tools/kops.md
@@ -140,7 +140,7 @@ Route53 hosted zone은 서브도메인도 지원한다. 여러분의 hosted zone
`example.com`하위에는 그렇지 않을 수 있다).
`dev.example.com`을 hosted zone으로 사용하고 있다고 가정해보자.
-보통 사용자는 [일반적인 방법](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html) 에 따라 생성하거나
+보통 사용자는 [일반적인 방법](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html) 에 따라 생성하거나
`aws route53 create-hosted-zone --name dev.example.com --caller-reference 1` 와 같은 커맨드를 이용한다.
그 후 도메인 내 레코드들을 확인할 수 있도록 상위 도메인내에 NS 레코드를 생성해야 한다. 여기서는,
diff --git a/content/ko/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/ko/docs/tasks/access-application-cluster/service-access-application-cluster.md
index 7565152bf0..a7351040e6 100644
--- a/content/ko/docs/tasks/access-application-cluster/service-access-application-cluster.md
+++ b/content/ko/docs/tasks/access-application-cluster/service-access-application-cluster.md
@@ -45,13 +45,14 @@ weight: 60
kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml
```
앞의 명령은
- [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)
+ {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}
오브젝트와 연관된
- [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/)
+ {{< glossary_tooltip term_id="replica-set" text="레플리카셋(ReplicaSet)" >}}
오브젝트를 생성한다. 레플리카셋은 두 개의
- [파드](/ko/docs/concepts/workloads/pods/pod/)를 갖고,
+ {{< glossary_tooltip text="파드" term_id="pod" >}}를 갖고,
각각은 Hello World 애플리케이션을 실행한다.
+
1. 디플로이먼트에 대한 정보를 보여준다.
```shell
kubectl get deployments hello-world
@@ -155,4 +156,3 @@ weight: 60
[서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에
대해 더 알아본다.
-
diff --git a/content/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/content/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
index dfd9923113..2d1b723e27 100644
--- a/content/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
+++ b/content/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
@@ -4,7 +4,7 @@ content_type: task
---
<!-- overview -->
-이 페이지는 쿠버네티스 퍼시트턴트볼륨(PersistentVolume)의 반환 정책을
+이 페이지는 쿠버네티스 퍼시트턴트볼륨(PersistentVolume)의 반환 정책을
변경하는 방법을 보여준다.
@@ -19,14 +19,14 @@ content_type: task
## 왜 퍼시스턴트볼륨 반환 정책을 변경하는가?
-`PersistentVolumes` 은 "Retain(보존)", "Recycle(재활용)", "Delete(삭제)" 를 포함한
-다양한 반환 정책을 갖는다. 동적으로 프로비저닝 된 `PersistentVolumes` 의 경우
-기본 반환 정책은 "Delete" 이다. 이는 사용자가 해당 `PersistentVolumeClaim` 을 삭제하면,
+퍼시스턴트볼륨은 "Retain(보존)", "Recycle(재활용)", "Delete(삭제)" 를 포함한
+다양한 반환 정책을 갖는다. 동적으로 프로비저닝 된 퍼시스턴트볼륨의 경우
+기본 반환 정책은 "Delete" 이다. 이는 사용자가 해당 `PersistentVolumeClaim` 을 삭제하면,
동적으로 프로비저닝 된 볼륨이 자동적으로 삭제됨을 의미한다.
볼륨에 중요한 데이터가 포함된 경우, 이러한 자동 삭제는 부적절 할 수 있다.
이 경우에는, "Retain" 정책을 사용하는 것이 더 적합하다.
-"Retain" 정책에서, 사용자가 `PersistentVolumeClaim` 을 삭제할 경우 해당하는
-`PersistentVolume` 은 삭제되지 않는다.
+"Retain" 정책에서, 사용자가 퍼시스턴트볼륨클레임을 삭제할 경우 해당하는
+퍼시스턴트볼륨은 삭제되지 않는다.
대신, `Released` 단계로 이동되어, 모든 데이터를 수동으로 복구할 수 있다.
## 퍼시스턴트볼륨 반환 정책 변경하기
@@ -44,7 +44,7 @@ content_type: task
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 6s
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim3 manual 3s
- 이 목록은 동적으로 프로비저닝 된 볼륨을 쉽게 식별할 수 있도록
+ 이 목록은 동적으로 프로비저닝 된 볼륨을 쉽게 식별할 수 있도록
각 볼륨에 바인딩 되어 있는 퍼시스턴트볼륨클레임(PersistentVolumeClaim)의 이름도 포함한다.
1. 사용자의 퍼시스턴트볼륨 중 하나를 선택한 후에 반환 정책을 변경한다.
@@ -77,8 +77,8 @@ kubectl patch pv <your-pv-name> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\"
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 36s
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Retain Bound default/claim3 manual 33s
- 위 결과에서, `default/claim3` 클레임과 바인딩 되어 있는 볼륨이 `Retain` 반환 정책을
- 갖는 것을 볼 수 있다. 사용자가 `default/claim3` 클레임을 삭제할 경우,
+ 위 결과에서, `default/claim3` 클레임과 바인딩 되어 있는 볼륨이 `Retain` 반환 정책을
+ 갖는 것을 볼 수 있다. 사용자가 `default/claim3` 클레임을 삭제할 경우,
볼륨은 자동으로 삭제 되지 않는다.
@@ -93,5 +93,3 @@ kubectl patch pv <your-pv-name> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\"
* [퍼시스턴트볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core)
* [퍼시스턴트볼륨클레임](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)의 `persistentVolumeReclaimPolicy` 필드에 대해 보기.
-
-
diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
index 2cf5a8b6e5..fef1abead5 100644
--- a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
+++ b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
@@ -137,7 +137,7 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow
### 윈도우 워커 노드 조인(joining)
{{< note >}}
`Containers` 기능을 설치하고 도커를 설치해야 한다.
-[윈도우 서버에 Docker Engine - Enterprise 설치](https://docs.docker.com/ee/docker-ee/windows/docker-ee/#install-docker-engine---enterprise)에서 설치에 대한 내용을 참고할 수 있다.
+[윈도우 서버에 Docker Engine - Enterprise 설치](https://docs.mirantis.com/docker-enterprise/v3.1/dockeree-products/docker-engine-enterprise/dee-windows.html)에서 설치에 대한 내용을 참고할 수 있다.
{{< /note >}}
{{< note >}}
@@ -181,5 +181,3 @@ flannel 파드가 실행되면, 노드는 `Ready` 상태가 되고 워크로드
- [윈도우 kubeadm 노드 업그레이드](/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)
-
-
diff --git a/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md b/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md
index bf948856a0..77ac7ce6d5 100644
--- a/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md
+++ b/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md
@@ -80,7 +80,8 @@ spec:
requests:
cpu: 700m
memory: 200Mi
-...
+ ...
+status:
qosClass: Guaranteed
```
@@ -134,7 +135,8 @@ spec:
memory: 200Mi
requests:
memory: 100Mi
-...
+ ...
+status:
qosClass: Burstable
```
@@ -174,6 +176,7 @@ spec:
...
resources: {}
...
+status:
qosClass: BestEffort
```
@@ -219,6 +222,7 @@ spec:
name: qos-demo-4-ctr-2
resources: {}
...
+status:
qosClass: Burstable
```
diff --git a/content/ko/docs/tasks/configure-pod-container/static-pod.md b/content/ko/docs/tasks/configure-pod-container/static-pod.md
index 8eb1c0a68f..41e1f6f7b0 100644
--- a/content/ko/docs/tasks/configure-pod-container/static-pod.md
+++ b/content/ko/docs/tasks/configure-pod-container/static-pod.md
@@ -14,7 +14,7 @@ content_template: task
직접 관리된다.
컨트롤 플레인에 의해 관리되는 파드(예를 들어 {{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}})와는 달리,
kubelet 이 각각의 스태틱 파드를 감시한다.
-(만약 충돌이 날 경우 다시 구동한다.)
+(만약 실패할 경우 다시 구동한다.)
스태틱 파드는 항상 특정 노드에 있는 하나의 {{< glossary_tooltip term_id="kubelet" >}}에 매여 있다.
diff --git a/content/ko/docs/tasks/extend-kubernetes/_index.md b/content/ko/docs/tasks/extend-kubernetes/_index.md
new file mode 100644
index 0000000000..f6394b6b60
--- /dev/null
+++ b/content/ko/docs/tasks/extend-kubernetes/_index.md
@@ -0,0 +1,5 @@
+---
+title: "쿠버네티스 확장"
+description: 쿠버네티스 클러스터를 작업 환경의 요구에 맞게 조정하는 고급 과정을 이해한다.
+weight: 90
+---
diff --git a/content/ko/docs/tasks/extend-kubernetes/setup-extension-api-server.md b/content/ko/docs/tasks/extend-kubernetes/setup-extension-api-server.md
new file mode 100644
index 0000000000..69dd891509
--- /dev/null
+++ b/content/ko/docs/tasks/extend-kubernetes/setup-extension-api-server.md
@@ -0,0 +1,53 @@
+---
+title: 확장 API 서버 설정
+content_type: task
+weight: 15
+---
+
+<!-- overview -->
+
+애그리게이션 레이어(aggregation layer)와 작동하도록 확장 API 서버를 설정하면 쿠버네티스 API 서버를 쿠버네티스의 핵심 API의 일부가 아닌 추가 API로 확장할 수 있다.
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+* [애그리게이션 레이어를 구성](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)하고 apiserver 플래그를 활성화해야 한다.
+
+
+
+<!-- steps -->
+
+## 애그리게이션 레이어와 작동하도록 확장 API 서버 설정
+
+다음 단계는 확장 API 서버를 *높은 수준* 으로 설정하는 방법을 설명한다. 이 단계는 YAML 구성을 사용하거나 API를 사용하는 것에 상관없이 적용된다. 둘 사이의 차이점을 구체적으로 식별하려고 시도한다. YAML 구성을 사용하여 구현하는 방법에 대한 구체적인 예를 보려면, 쿠버네티스 리포지터리에서 [sample-apiserver](https://github.com/kubernetes/sample-apiserver/blob/master/README.md)를 참고할 수 있다.
+
+또는, [apiserver-builder](https://github.com/kubernetes-sigs/apiserver-builder-alpha/blob/master/README.md)와 같은 기존의 타사 솔루션을 사용하여 스켈레톤(skeleton)을 생성하고 다음 단계를 모두 자동화해야 한다.
+
+1. API서비스(APIService) API가 활성화되어 있는지 확인한다(`--runtime-config` 확인). 클러스터에서 일부러 해제하지 않았다면, 기본적으로 활성화되어 있어야 한다.
+1. API서비스 오브젝트를 추가하거나 클러스터 관리자가 작성하도록 RBAC 규칙을 작성해야 할 수도 있다. (API 확장은 전체 클러스터에 영향을 주기 때문에, 운영 중인 클러스터에서 API 확장에 대한 테스트/개발/디버깅을 수행하지 않는 것이 좋다.)
+1. 확장 API 서비스를 실행하려는 쿠버네티스 네임스페이스를 생성한다.
+1. HTTPS를 위해 확장 API 서버가 사용하는 서버 인증서에 서명하는 데 사용할 CA 인증서를 생성하거나 가져온다.
+1. HTTPS를 위해 API 서버가 사용할 서버 인증서/키를 생성한다. 이 인증서는 위의 CA 인증서에 의해 서명해야 한다. 또한 Kube DNS 이름의 CN이 있어야 한다. 이것은 쿠버네티스 서비스에서 파생되었으며 `<service name>.<service name namespace>.svc` 형식이다.
+1. 네임스페이스에 서버 인증서/키를 사용하여 쿠버네티스 시크릿을 생성한다.
+1. 확장 API 서버에 대한 쿠버네티스 디플로이먼트를 생성하고 시크릿을 볼륨으로 로드하는지 확인한다. 확장 API 서버의 작동하는(working) 이미지에 대한 참조를 포함해야 한다. 디플로이먼트는 네임스페이스에도 있어야 한다.
+1. 확장 API 서버가 해당 볼륨에서 해당 인증서를 로드하고 HTTPS 핸드셰이크에 사용되는지 확인한다.
+1. 네임스페이스에서 쿠버네티스 서비스 어카운트를 생성한다.
+1. 리소스에 허용하려는 작업에 대한 쿠버네티스 클러스터 롤(role)을 생성한다.
+1. 네임스페이스의 서비스 어카운트에서 방금 만든 클러스터 롤로 쿠버네티스 클러스터 롤 바인딩을 생성한다.
+1. 네임스페이스의 서비스 어카운트에서 `system:auth-delegator` 클러스터 롤로 쿠버네티스 클러스터 롤 바인딩을 만들어 인증 결정을 쿠버네티스 핵심 API 서버에 위임한다.
+1. 네임스페이스의 서비스 어카운트에서 `extension-apiserver-authentication-reader` 롤로 쿠버네티스 롤 바인딩을 생성한다. 이를 통해 확장 API 서버가 `extension-apiserver-authentication` 컨피그맵(configmap)에 접근할 수 있다.
+1. 쿠버네티스 API 서비스를 생성한다. 위의 CA 인증서는 base64로 인코딩되어, 새로운 라인이 제거되고 API 서비스에서 spec.caBundle로 사용되어야 한다. 이것은 namespaced가 아니어야 한다. [kube-aggregator API](https://github.com/kubernetes/kube-aggregator/)를 사용하는 경우, base64 인코딩이 수행되므로 PEM 인코딩된 CA 번들만 통과한다.
+1. kubectl을 사용하여 리소스를 얻는다. kubectl을 실행하면, "No resources found."가 반환된다. 이 메시지는
+모든 것이 작동됐지만 현재 해당 리소스 유형의 오브젝트가 생성되지 않았음을 나타낸다.
+
+
+## {{% heading "whatsnext" %}}
+
+
+* [API 애그리게이션 레이어를 구성](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)하고 apiserver 플래그를 활성화하는 단계를 수행한다.
+* 높은 수준의 개요에 대해서는, [애그리게이션 레이어로 쿠버네티스 API 확장하기](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 참고한다.
+* [커스텀 리소스 데피니션을 사용하여 쿠버네티스 API 확장](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)하는 방법에 대해 알아본다.
diff --git a/content/ko/docs/tasks/run-application/delete-stateful-set.md b/content/ko/docs/tasks/run-application/delete-stateful-set.md
index 4c50079dc3..a2c43f3321 100644
--- a/content/ko/docs/tasks/run-application/delete-stateful-set.md
+++ b/content/ko/docs/tasks/run-application/delete-stateful-set.md
@@ -52,7 +52,7 @@ kubectl delete pods -l app=myapp
### 퍼시스턴트볼륨(PersistentVolume)
-스테이트풀셋의 파드들을 삭제하는 것이 연결된 볼륨을 삭제하는 것은 아니다. 이것은 볼륨을 삭제하기 전에 볼륨에서 데이터를 복사할 수 있는 기회를 준다. 파드들이 [terminating 상태](/ko/docs/concepts/workloads/pods/pod/#파드의-종료)가 된 후 PVC를 삭제하는 것은 스토리지클래스(StorageClass) 와 반환 정책에 따라 백업 퍼시스턴트볼륨이 삭제될 수도 있다. 클레임 삭제 후 볼륨에 접근할 수 있다고 가정하면 안된다.
+스테이트풀셋의 파드들을 삭제하는 것이 연결된 볼륨을 삭제하는 것은 아니다. 이것은 볼륨을 삭제하기 전에 볼륨에서 데이터를 복사할 수 있는 기회를 준다. 파드가 종료된 후 PVC를 삭제하면 스토리지 클래스와 반환 정책에 따라 백업 퍼시스턴트볼륨 삭제가 트리거될 수 있다. 클레임 삭제 후 볼륨에 접근할 수 있다고 가정하면 안된다.
{{< note >}}
PVC를 삭제할 때 데이터 손실될 수 있음에 주의하자.
diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
index ee5db9d3f2..b42f8952b8 100644
--- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
@@ -42,7 +42,7 @@ Dockerfile은 다음과 같다.
```
FROM php:5-apache
-ADD index.php /var/www/html/index.php
+COPY index.php /var/www/html/index.php
RUN chmod a+rx index.php
```
@@ -481,5 +481,3 @@ kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml
```
horizontalpodautoscaler.autoscaling/php-apache created
```
-
-
diff --git a/content/ko/docs/tasks/tools/_index.md b/content/ko/docs/tasks/tools/_index.md
index bcfcd12e4e..8f45c8ddc2 100755
--- a/content/ko/docs/tasks/tools/_index.md
+++ b/content/ko/docs/tasks/tools/_index.md
@@ -2,5 +2,40 @@
title: "도구 설치"
description: 컴퓨터에서 쿠버네티스 도구를 설정한다.
weight: 10
+no_list: true
---
+## kubectl
+
+쿠버네티스 커맨드 라인 도구인 `kubectl` 사용하면 쿠버네티스 클러스터에 대해 명령을
+실행할 수 있다. kubectl을 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및
+관리하고, 로그를 볼 수 있다.
+
+클러스터에 접근하기 위해 `kubectl` 을 다운로드 및 설치하고 설정하는 방법에 대한 정보는
+[kubectl 설치 및 설정](/ko/docs/tasks/tools/install-kubectl/)을 참고한다.
+
+`kubectl` 레퍼런스 문서를 읽어볼 수도 있다.
+
+## Minikube
+
+[Minikube](https://minikube.sigs.k8s.io/)는 쿠버네티스를 로컬에서 실행할 수 있는
+도구이다. Minikube는 개인용 컴퓨터(윈도우, macOS 및 리눅스 PC 포함)에서
+단일 노드 쿠버네티스 클러스터를 실행하여 쿠버네티스를 사용해보거나 일상적인 개발 작업을
+수행할 수 있다.
+
+공식 사이트에서의 [시작하기!](https://minikube.sigs.k8s.io/docs/start/)
+가이드를 따라 해볼 수 있고, 또는 도구 설치에 중점을 두고 있다면
+[Minikube 설치](/docs/tasks/tools/install-minikube/)를 읽어볼 수 있다.
+
+Minikube가 작동하면, 이를 사용하여
+[샘플 애플리케이션을 실행](/docs/tutorials/hello-minikube/)해볼 수 있다.
+
+## kind
+
+Minikube와 마찬가지로, [kind](https://kind.sigs.k8s.io/docs/)를 사용하면 로컬 컴퓨터에서
+쿠버네티스를 실행할 수 있다. Minikuke와 달리, kind는 단일 컨테이너 런타임에서만 작동한다.
+kind는 [도커](https://docs.docker.com/get-docker/)를 설치하고
+구성해야 한다.
+
+[퀵 스타트](https://kind.sigs.k8s.io/docs/user/quick-start/)는 kind를 시작하고 실행하기 위해
+수행해야 하는 작업을 보여준다.
diff --git a/content/ko/docs/tasks/tools/install-kubectl.md b/content/ko/docs/tasks/tools/install-kubectl.md
index e4c8011614..baf003f595 100644
--- a/content/ko/docs/tasks/tools/install-kubectl.md
+++ b/content/ko/docs/tasks/tools/install-kubectl.md
@@ -26,7 +26,7 @@ card:
1. 다음 명령으로 최신 릴리스를 다운로드한다.
```
- curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl
+ curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl"
```
특정 버전을 다운로드하려면, `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다.
diff --git a/content/ko/docs/tutorials/_index.md b/content/ko/docs/tutorials/_index.md
index a0dfb80ca1..a0af5ff5b5 100644
--- a/content/ko/docs/tutorials/_index.md
+++ b/content/ko/docs/tutorials/_index.md
@@ -45,16 +45,6 @@ content_type: concept
* [분산 시스템 코디네이터 ZooKeeper 실행하기](/ko/docs/tutorials/stateful-application/zookeeper/)
-## CI/CD 파이프라인
-
-* [Set Up a CI/CD Pipeline with Kubernetes Part 1: Overview](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/5/set-cicd-pipeline-kubernetes-part-1-overview)
-
-* [Set Up a CI/CD Pipeline with a Jenkins Pod in Kubernetes (Part 2)](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/6/set-cicd-pipeline-jenkins-pod-kubernetes-part-2)
-
-* [Run and Scale a Distributed Crossword Puzzle App with CI/CD on Kubernetes (Part 3)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/run-and-scale-distributed-crossword-puzzle-app-cicd-kubernetes-part-3)
-
-* [Set Up CI/CD for a Distributed Crossword Puzzle App on Kubernetes (Part 4)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/set-cicd-distributed-crossword-puzzle-app-kubernetes-part-4)
-
## 클러스터
* [AppArmor](/ko/docs/tutorials/clusters/apparmor/)
diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md
index 9d71638252..35b4365eb2 100644
--- a/content/ko/docs/tutorials/hello-minikube.md
+++ b/content/ko/docs/tutorials/hello-minikube.md
@@ -59,13 +59,13 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
minikube dashboard
```
-3. Katacoda 환경에서는: 터미널 패널의 상단에서 플러스를 클릭하고, 이어서 **Select port to view on Host 1**를 클릭
+3. Katacoda 환경에서는: 터미널 패널의 상단에서 플러스를 클릭하고, 이어서 **Select port to view on Host 1** 을 클릭
-4. Katacoda 환경에서는: 30000 을 입력하고 **Display Port**을 클릭.
+4. Katacoda 환경에서는: 30000 을 입력하고 **Display Port** 를 클릭.
## 디플로이먼트 만들기
-쿠버네티스 [*파드*](/ko/docs/concepts/workloads/pods/pod/)는 관리와
+쿠버네티스 [*파드*](/ko/docs/concepts/workloads/pods/)는 관리와
네트워킹 목적으로 함께 묶여 있는 하나 이상의 컨테이너 그룹이다.
이 튜토리얼의 파드에는 단 하나의 컨테이너만 있다. 쿠버네티스
[*디플로이먼트*](/ko/docs/concepts/workloads/controllers/deployment/)는 파드의
@@ -97,7 +97,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
```shell
kubectl get pods
```
-
+
다음과 유사하게 출력된다.
```
@@ -282,5 +282,3 @@ minikube delete
* [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해서 더 배워 본다.
* [애플리케이션 배포](/docs/tasks/run-application/run-stateless-application-deployment/)에 대해서 더 배워 본다.
* [서비스 오브젝트](/ko/docs/concepts/services-networking/service/)에 대해서 더 배워 본다.
-
-
diff --git a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
index 34a69387dc..e2b8098b9e 100644
--- a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+++ b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
@@ -20,7 +20,7 @@ weight: 20
<div class="row">
<div class="col-md-12">
<p>
- 파드는 쿠버네티스 애플리케이션의 기본 실행 단위이다. 각 파드는 클러스터에서 실행중인 워크로드의 일부를 나타낸다. <a href="/ko/docs/concepts/workloads/pods/pod-overview/#파드에-대해-이해하기">파드에 대해 더 자세히 알아본다</a>.
+ 파드는 쿠버네티스 애플리케이션의 기본 실행 단위이다. 각 파드는 클러스터에서 실행중인 워크로드의 일부를 나타낸다. <a href="/ko/docs/concepts/workloads/pods/">파드에 대해 더 자세히 알아본다</a>.
</p>
</div>
</div>
diff --git a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html
index 6726fdd6e0..ebc880dbdd 100644
--- a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html
+++ b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html
@@ -28,7 +28,7 @@ weight: 10
<div class="col-md-8">
<h3>쿠버네티스 서비스들에 대한 개요</h3>
- <p>쿠버네티스 <a href="/ko/docs/concepts/workloads/pods/pod-overview/">파드들</a> 은 언젠가는 죽게된다. 실제 파드들은 <a href="/ko/docs/concepts/workloads/pods/pod-lifecycle/">생명주기</a>를 갖는다. 워커 노드가 죽으면, 노드 상에서 동작하는 파드들 또한 종료된다. <a href="/ko/docs/concepts/workloads/controllers/replicaset/">레플리카셋(ReplicaSet)</a>은 여러분의 애플리케이션이 지속적으로 동작할 수 있도록 새로운 파드들의 생성을 통해 동적으로 클러스터를 미리 지정해 둔 상태로 되돌려 줄 수도 있다. 또 다른 예시로서, 3개의 복제본을 갖는 이미지 처리용 백엔드를 고려해 보자. 그 복제본들은 교체 가능한 상태이다. 그래서 프론트엔드 시스템은 하나의 파드가 소멸되어 재생성이 되더라도, 백엔드 복제본들에 의한 영향을 받아서는 안된다. 즉, 동일 노드 상의 파드들이라 할지라도, 쿠버네티스 클러스터 내 각 파드는 유일한 IP 주소를 가지며, 여러분의 애플리케이션들이 지속적으로 기능할 수 있도록 파드들 속에서 발생하는 변화에 대해 자동으로 조정해 줄 방법이 있어야 한다.</p>
+ <p>쿠버네티스 <a href="/ko/docs/concepts/workloads/pods/">파드들</a> 은 언젠가는 죽게된다. 실제 파드들은 <a href="/ko/docs/concepts/workloads/pods/pod-lifecycle/">생명주기</a>를 갖는다. 워커 노드가 죽으면, 노드 상에서 동작하는 파드들 또한 종료된다. <a href="/ko/docs/concepts/workloads/controllers/replicaset/">레플리카셋(ReplicaSet)</a>은 여러분의 애플리케이션이 지속적으로 동작할 수 있도록 새로운 파드들의 생성을 통해 동적으로 클러스터를 미리 지정해 둔 상태로 되돌려 줄 수도 있다. 또 다른 예시로서, 3개의 복제본을 갖는 이미지 처리용 백엔드를 고려해 보자. 그 복제본들은 교체 가능한 상태이다. 그래서 프론트엔드 시스템은 하나의 파드가 소멸되어 재생성이 되더라도, 백엔드 복제본들에 의한 영향을 받아서는 안된다. 즉, 동일 노드 상의 파드들이라 할지라도, 쿠버네티스 클러스터 내 각 파드는 유일한 IP 주소를 가지며, 여러분의 애플리케이션들이 지속적으로 기능할 수 있도록 파드들 속에서 발생하는 변화에 대해 자동으로 조정해 줄 방법이 있어야 한다.</p>
<p>쿠버네티스에서 서비스는 하나의 논리적인 파드 셋과 그 파드들에 접근할 수 있는 정책을 정의하는 추상적 개념이다. 서비스는 종속적인 파드들 사이를 느슨하게 결합되도록 해준다. 서비스는 모든 쿠버네티스 오브젝트들과 같이 YAML <a href="/ko/docs/concepts/configuration/overview/#일반적인-구성-팁">(보다 선호하는)</a> 또는 JSON을 이용하여 정의된다. 서비스가 대상으로 하는 파드 셋은 보통 <i>LabelSelector</i>에 의해 결정된다 (여러분이 왜 스펙에 <code>selector</code>가 포함되지 않은 서비스를 필요로 하게 될 수도 있는지에 대해 아래에서 확인해 보자).</p>
diff --git a/content/ko/docs/tutorials/services/source-ip.md b/content/ko/docs/tutorials/services/source-ip.md
index ae9e5abf03..382f096375 100644
--- a/content/ko/docs/tutorials/services/source-ip.md
+++ b/content/ko/docs/tutorials/services/source-ip.md
@@ -177,7 +177,7 @@ service/nodeport exposed
```shell
NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport)
-NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="IPAddress")].address }')
+NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="InternalIP")].address }')
```
클라우드 공급자 상에서 실행한다면,
@@ -206,17 +206,19 @@ client_address=10.240.0.3
시각적으로
-```
- client
- \ ^
- \ \
- v \
- node 1 <--- node 2
- | ^ SNAT
- | | --->
- v |
- endpoint
-```
+{{< mermaid >}}
+graph LR;
+ client(client)-->node2[Node 2];
+ node2-->client;
+ node2-. SNAT .->node1[Node 1];
+ node1-. SNAT .->node2;
+ node1-->endpoint(Endpoint);
+
+ classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+ classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+ class node1,node2,endpoint k8s;
+ class client plain;
+{{</ mermaid >}}
이를 피하기 위해 쿠버네티스는
@@ -261,17 +263,18 @@ client_address=104.132.1.79
시각적으로
-```
- client
- ^ / \
- / / \
- / v X
- node 1 node 2
- ^ |
- | |
- | v
- endpoint
-```
+{{< mermaid >}}
+graph TD;
+ client --> node1[Node 1];
+ client(client) --x node2[Node 2];
+ node1 --> endpoint(endpoint);
+ endpoint --> node1;
+
+ classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+ classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+ class node1,node2,endpoint k8s;
+ class client plain;
+{{</ mermaid >}}
@@ -324,17 +327,7 @@ client_address=10.240.0.5
시각적으로:
-```
- client
- |
- lb VIP
- / ^
- v /
-health check ---> node 1 node 2 <--- health check
- 200 <--- ^ | ---> 500
- | V
- endpoint
-```
+
이것은 어노테이션을 설정하여 테스트할 수 있다.
diff --git a/content/ko/docs/tutorials/stateful-application/zookeeper.md b/content/ko/docs/tutorials/stateful-application/zookeeper.md
index 490f6ff18d..a253f04a0b 100644
--- a/content/ko/docs/tutorials/stateful-application/zookeeper.md
+++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md
@@ -82,7 +82,7 @@ kubectl apply -f https://k8s.io/examples/application/zookeeper/zookeeper.yaml
이는 `zk-hs` 헤드리스 서비스, `zk-cs` 서비스,
`zk-pdb` PodDisruptionBudget과 `zk` 스테이트풀셋을 생성한다.
-```shell
+```
service/zk-hs created
service/zk-cs created
poddisruptionbudget.policy/zk-pdb created
@@ -98,7 +98,7 @@ kubectl get pods -w -l app=zk
`zk-2` 파드가 Running and Ready 상태가 되면, `CTRL-C`를 눌러 kubectl을 종료하자.
-```shell
+```
NAME READY STATUS RESTARTS AGE
zk-0 0/1 Pending 0 0s
zk-0 0/1 Pending 0 0s
@@ -135,7 +135,7 @@ for i in 0 1 2; do kubectl exec zk-$i -- hostname; done
스테이트풀셋 컨트롤러는 각 순번 인덱스에 기초하여 각 파드에 고유한 호스트네임을 부여한다. 각 호스트네임은 `<스테이트풀셋 이름>-<순번 인덱스>` 형식을 취한다. `zk` 스테이트풀셋의 `replicas` 필드는 `3`으로 설정되었기 때문에, 그 스테이트풀셋 컨트롤러는 3개 파드의 호스트네임을 `zk-0`, `zk-1`,
`zk-2`로 정한다.
-```shell
+```
zk-0
zk-1
zk-2
@@ -151,7 +151,7 @@ for i in 0 1 2; do echo "myid zk-$i";kubectl exec zk-$i -- cat /var/lib/zookeepe
식별자는 자연수이고, 순번 인덱스들도 음수가 아니므로, 순번에 1을 더하여 순번을 만들 수 있다.
-```shell
+```
myid zk-0
1
myid zk-1
@@ -169,7 +169,7 @@ for i in 0 1 2; do kubectl exec zk-$i -- hostname -f; done
`zk-hs` 서비스는 모든 파드를 위한 도메인인
`zk-hs.default.svc.cluster.local`을 만든다.
-```shell
+```
zk-0.zk-hs.default.svc.cluster.local
zk-1.zk-hs.default.svc.cluster.local
zk-2.zk-hs.default.svc.cluster.local
@@ -188,7 +188,7 @@ kubectl exec zk-0 -- cat /opt/zookeeper/conf/zoo.cfg
연관된다.
이들은 `zk` 스테이트풀셋의 파드의 FQDNS을 설정한다.
-```shell
+```
clientPort=2181
dataDir=/var/lib/zookeeper/data
dataLogDir=/var/lib/zookeeper/log
@@ -212,7 +212,9 @@ server.3=zk-2.zk-hs.default.svc.cluster.local:2888:3888
합의 프로토콜에서 각 참여자의 식별자는 고유해야 한다. Zab 프로토콜에 두 참여자가 동일한 고유 식별자로 요청해서는 안된다. 이는 시스템 프로세스가 어떤 프로세스가 어떤 데이터를 커밋했는지 동의하도록 하기 위해 필수적이다. 동일 순번으로 두 개의 파드가 실행했다면 두 ZooKeeper 서버는 모두 동일한 서버로 식별된다.
```shell
kubectl get pods -w -l app=zk
+```
+```
NAME READY STATUS RESTARTS AGE
zk-0 0/1 Pending 0 0s
zk-0 0/1 Pending 0 0s
@@ -236,7 +238,7 @@ ZooKeeper 서버의 FQDN은 단일 엔드포인트로 확인되고
해당 엔드포인트는 `myid` 파일에 구성된 식별자를 가진
고유한 ZooKeeper 서버가 된다.
-```shell
+```
zk-0.zk-hs.default.svc.cluster.local
zk-1.zk-hs.default.svc.cluster.local
zk-2.zk-hs.default.svc.cluster.local
@@ -244,7 +246,7 @@ zk-2.zk-hs.default.svc.cluster.local
이것은 ZooKeeper의 `zoo.cfg` 파일에 `servers` 속성이 정확히 구성된 앙상블로 나타나는 것을 보증한다.
-```shell
+```
server.1=zk-0.zk-hs.default.svc.cluster.local:2888:3888
server.2=zk-1.zk-hs.default.svc.cluster.local:2888:3888
server.3=zk-2.zk-hs.default.svc.cluster.local:2888:3888
@@ -260,7 +262,8 @@ server.3=zk-2.zk-hs.default.svc.cluster.local:2888:3888
```shell
kubectl exec zk-0 zkCli.sh create /hello world
-
+```
+```
WATCHER::
WatchedEvent state:SyncConnected type:None path:null
@@ -276,7 +279,7 @@ kubectl exec zk-1 zkCli.sh get /hello
`zk-0`에서 생성한 그 데이터는 앙상블 내에 모든 서버에서
사용할 수 있다.
-```shell
+```
WATCHER::
WatchedEvent state:SyncConnected type:None path:null
@@ -307,6 +310,9 @@ ZooKeeper는 모든 항목을 내구성있는 WAL에 커밋하고 메모리 상
```shell
kubectl delete statefulset zk
+```
+
+```
statefulset.apps "zk" deleted
```
@@ -318,7 +324,7 @@ kubectl get pods -w -l app=zk
`zk-0`이 완전히 종료되면 `CTRL-C`를 이용해 kubectl을 종료하자.
-```shell
+```
zk-2 1/1 Terminating 0 9m
zk-0 1/1 Terminating 0 11m
zk-1 1/1 Terminating 0 10m
@@ -349,7 +355,7 @@ kubectl get pods -w -l app=zk
`zk-2` 파드가 Running과 Ready가 되면 `CTRL-C`를 이용하여 kubectl을 종료한다.
-```shell
+```
NAME READY STATUS RESTARTS AGE
zk-0 0/1 Pending 0 0s
zk-0 0/1 Pending 0 0s
@@ -377,7 +383,7 @@ kubectl exec zk-2 zkCli.sh get /hello
`zk` 스테이트풀셋의 모든 파드를 종료하고 재생성했음에도, 앙상블은 여전히 원래 값을 돌려준다.
-```shell
+```
WATCHER::
WatchedEvent state:SyncConnected type:None path:null
@@ -422,7 +428,7 @@ kubectl get pvc -l app=zk
`스테이트풀셋`의 파드를 재생성할 때에 파드의 퍼시스턴트볼륨도 다시 마운트한다.
-```shell
+```
NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
datadir-zk-0 Bound pvc-bed742cd-bcb1-11e6-994f-42010a800002 20Gi RWO 1h
datadir-zk-1 Bound pvc-bedd27d2-bcb1-11e6-994f-42010a800002 20Gi RWO 1h
@@ -457,6 +463,8 @@ ZooKeeper 앙상블에 서버는 리더 선출과 쿼럼을 구성하기 위한
```shell
kubectl get sts zk -o yaml
+```
+```
…
command:
- sh
@@ -499,7 +507,7 @@ kubectl exec zk-0 cat /usr/etc/zookeeper/log4j.properties
아래 로깅 구성은 ZooKeeper가 모든 로그를
표준 출력 스트림으로 처리하게 한다.
-```shell
+```
zookeeper.root.logger=CONSOLE
zookeeper.console.threshold=INFO
log4j.rootLogger=${zookeeper.root.logger}
@@ -519,7 +527,7 @@ kubectl logs zk-0 --tail 20
`kubectl logs`를 이용하거나 쿠버네티스 대시보드에서 표준 출력과 표준 오류로 쓰인 애플리케이션 로그를 볼 수 있다.
-```shell
+```
2016-12-06 19:34:16,236 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52740
2016-12-06 19:34:16,237 [myid:1] - INFO [Thread-1136:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52740 (no session established for client)
2016-12-06 19:34:26,155 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52749
@@ -575,7 +583,7 @@ kubectl exec zk-0 -- ps -elf
`securityContext` 오브젝트의 `runAsUser` 필드 값이 1000 이므로
루트 사용자로 실행하는 대신 ZooKeeper 프로세스는 ZooKeeper 사용자로 실행된다.
-```shell
+```
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
4 S zookeep+ 1 0 0 80 0 - 1127 - 20:46 ? 00:00:00 sh -c zkGenConfig.sh && zkServer.sh start-foreground
0 S zookeep+ 27 1 0 80 0 - 1155556 - 20:46 ? 00:00:19 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,CONSOLE -cp /usr/bin/../build/classes:/usr/bin/../build/lib/*.jar:/usr/bin/../share/zookeeper/zookeeper-3.4.9.jar:/usr/bin/../share/zookeeper/slf4j-log4j12-1.6.1.jar:/usr/bin/../share/zookeeper/slf4j-api-1.6.1.jar:/usr/bin/../share/zookeeper/netty-3.10.5.Final.jar:/usr/bin/../share/zookeeper/log4j-1.2.16.jar:/usr/bin/../share/zookeeper/jline-0.9.94.jar:/usr/bin/../src/java/lib/*.jar:/usr/bin/../etc/zookeeper: -Xmx2G -Xms2G -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /usr/bin/../etc/zookeeper/zoo.cfg
@@ -591,7 +599,7 @@ kubectl exec -ti zk-0 -- ls -ld /var/lib/zookeeper/data
`securityContext` 오브젝트의 `fsGroup` 필드 값이 1000 이므로, 파드의 퍼시스턴트 볼륨의 소유권은 ZooKeeper 그룹으로 지정되어 ZooKeeper 프로세스에서 읽고 쓸 수 있다.
-```shell
+```
drwxr-sr-x 3 zookeeper zookeeper 4096 Dec 5 20:45 /var/lib/zookeeper/data
```
@@ -613,7 +621,8 @@ drwxr-sr-x 3 zookeeper zookeeper 4096 Dec 5 20:45 /var/lib/zookeeper/data
```shell
kubectl patch sts zk --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/resources/requests/cpu", "value":"0.3"}]'
-
+```
+```
statefulset.apps/zk patched
```
@@ -621,7 +630,8 @@ statefulset.apps/zk patched
```shell
kubectl rollout status sts/zk
-
+```
+```
waiting for statefulset rolling update to complete 0 pods at revision zk-5db4499664...
Waiting for 1 pods to be ready...
Waiting for 1 pods to be ready...
@@ -640,7 +650,9 @@ statefulset rolling update complete 3 pods at revision zk-5db4499664...
```shell
kubectl rollout history sts/zk
+```
+```
statefulsets "zk"
REVISION
1
@@ -651,7 +663,9 @@ REVISION
```shell
kubectl rollout undo sts/zk
+```
+```
statefulset.apps/zk rolled back
```
@@ -671,7 +685,7 @@ kubectl exec zk-0 -- ps -ef
컨테이너의 엔트리 포인트로 PID 1 인 명령이 사용되었으며
ZooKeeper 프로세스는 엔트리 포인트의 자식 프로세스로 PID 27 이다.
-```shell
+```
UID PID PPID C STIME TTY TIME CMD
zookeep+ 1 0 0 15:03 ? 00:00:00 sh -c zkGenConfig.sh && zkServer.sh start-foreground
zookeep+ 27 1 0 15:03 ? 00:00:03 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,CONSOLE -cp /usr/bin/../build/classes:/usr/bin/../build/lib/*.jar:/usr/bin/../share/zookeeper/zookeeper-3.4.9.jar:/usr/bin/../share/zookeeper/slf4j-log4j12-1.6.1.jar:/usr/bin/../share/zookeeper/slf4j-api-1.6.1.jar:/usr/bin/../share/zookeeper/netty-3.10.5.Final.jar:/usr/bin/../share/zookeeper/log4j-1.2.16.jar:/usr/bin/../share/zookeeper/jline-0.9.94.jar:/usr/bin/../src/java/lib/*.jar:/usr/bin/../etc/zookeeper: -Xmx2G -Xms2G -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /usr/bin/../etc/zookeeper/zoo.cfg
@@ -691,7 +705,7 @@ kubectl exec zk-0 -- pkill java
ZooKeeper 프로세스의 종료는 부모 프로세스의 종료를 일으킨다. 컨테이너 `재시작정책`이 Always이기 때문에 부모 프로세스를 재시작했다.
-```shell
+```
NAME READY STATUS RESTARTS AGE
zk-0 1/1 Running 0 21m
zk-1 1/1 Running 0 20m
@@ -731,7 +745,7 @@ zk-0 1/1 Running 1 29m
검사는 ZooKeeper의 `ruok` 4 글자 단어를 이용해서 서버의 건강을 테스트하는
배쉬 스크립트를 호출한다.
-```bash
+```
OK=$(echo ruok | nc 127.0.0.1 $1)
if [ "$OK" == "imok" ]; then
exit 0
@@ -758,7 +772,9 @@ ZooKeeper의 활성도 검사에 실패하면,
```shell
kubectl get pod -w -l app=zk
+```
+```
NAME READY STATUS RESTARTS AGE
zk-0 1/1 Running 0 1h
zk-1 1/1 Running 0 1h
@@ -823,7 +839,7 @@ for i in 0 1 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo "";
`zk` `스테이트풀셋`에 모든 파드는 다른 노드에 배포된다.
-```shell
+```
kubernetes-node-cxpk
kubernetes-node-a5aq
kubernetes-node-2g2d
@@ -882,7 +898,7 @@ kubectl get pdb zk-pdb
`max-unavailable` 필드는 쿠버네티스가 `zk` `스테이트풀셋`에서 최대 1개의 파드는
언제든지 가용하지 않을 수 있음을 나타낸다.
-```shell
+```
NAME MIN-AVAILABLE MAX-UNAVAILABLE ALLOWED-DISRUPTIONS AGE
zk-pdb N/A 1 1
```
@@ -897,7 +913,9 @@ kubectl get pods -w -l app=zk
```shell
for i in 0 1 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo ""; done
+```
+```
kubernetes-node-pb41
kubernetes-node-ixsl
kubernetes-node-i4c4
@@ -908,6 +926,9 @@ kubernetes-node-i4c4
```shell
kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
+```
+
+```
node "kubernetes-node-group-pb41" cordoned
WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-group-pb41, kube-proxy-kubernetes-node-group-pb41; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-o5elz
@@ -918,7 +939,7 @@ node "kubernetes-node-group-pb41" drained
클러스터에 4개 노드가 있기 때문에 `kubectl drain`이 성공하여
`zk-0`을 다른 노드로 재스케쥴링 된다.
-```shell
+```
NAME READY STATUS RESTARTS AGE
zk-0 1/1 Running 2 1h
zk-1 1/1 Running 0 1h
@@ -940,7 +961,9 @@ zk-0 1/1 Running 0 1m
```shell
kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data "kubernetes-node-ixsl" cordoned
+```
+```
WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-ixsl, kube-proxy-kubernetes-node-ixsl; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-voc74
pod "zk-1" deleted
node "kubernetes-node-ixsl" drained
@@ -950,7 +973,9 @@ node "kubernetes-node-ixsl" drained
```shell
kubectl get pods -w -l app=zk
+```
+```
NAME READY STATUS RESTARTS AGE
zk-0 1/1 Running 2 1h
zk-1 1/1 Running 0 1h
@@ -978,6 +1003,8 @@ zk-1 0/1 Pending 0 0s
```shell
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
+```
+```
node "kubernetes-node-i4c4" cordoned
WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog
@@ -999,7 +1026,7 @@ kubectl exec zk-0 zkCli.sh get /hello
`PodDisruptionBudget`이 존중되기 때문에 서비스는 여전히 가용하다.
-```shell
+```
WatchedEvent state:SyncConnected type:None path:null
world
cZxid = 0x200000002
@@ -1019,7 +1046,8 @@ numChildren = 0
```shell
kubectl uncordon kubernetes-node-pb41
-
+```
+```
node "kubernetes-node-pb41" uncordoned
```
@@ -1027,7 +1055,8 @@ node "kubernetes-node-pb41" uncordoned
```shell
kubectl get pods -w -l app=zk
-
+```
+```
NAME READY STATUS RESTARTS AGE
zk-0 1/1 Running 2 1h
zk-1 1/1 Running 0 1h
diff --git a/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md
index 719c998366..6b7c019d7f 100644
--- a/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md
+++ b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md
@@ -52,11 +52,11 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
위의 명령어는
- [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/)
+ {{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}}
오브젝트와 관련된
- [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/)
+ {{< glossary_tooltip term_id="replica-set" text="레플리카셋(ReplicaSet)" >}}
오브젝트를 생성한다. 레플리카셋은 다섯 개의
- [파드](/ko/docs/concepts/workloads/pods/pod/)가 있으며,
+ {{< glossary_tooltip text="파드" term_id="pod" >}}가 있으며,
각 파드는 Hello World 애플리케이션을 실행한다.
1. 디플로이먼트에 대한 정보를 확인한다.
diff --git a/content/pl/_index.html b/content/pl/_index.html
index f127bff2c7..1e759a89e7 100644
--- a/content/pl/_index.html
+++ b/content/pl/_index.html
@@ -41,13 +41,13 @@ Kubernetes jako projekt open-source daje Ci wolność wyboru ⏤ skorzystaj z pr
<button id="desktopShowVideoButton" onclick="kub.showVideo()">Obejrzyj wideo</button>
<br>
<br>
- <br>
- <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Weź udział w wirtualnym KubeCon 17-20.08.2020</a>
+ <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Weź udział w wirtualnym KubeCon EU 17-20.08.2020</a>
<br>
<br>
<br>
<br>
- <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">Weź udział w KubeCon w Bostonie 17-20.11.2020</a>
+ <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">Weź udział w wirtualnym KubeCon NA w 17-20.11.2020</a>
+
</div>
<div id="videoPlayer">
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
diff --git a/content/pl/docs/concepts/_index.md b/content/pl/docs/concepts/_index.md
index ec7abd87ce..a5a5848cfc 100644
--- a/content/pl/docs/concepts/_index.md
+++ b/content/pl/docs/concepts/_index.md
@@ -8,64 +8,3 @@ weight: 40
<!-- overview -->
Rozdział dotyczący pojęć ma za zadanie pomóc w zrozumieniu poszczególnych składowych systemu oraz obiektów abstrakcyjnych, których Kubernetes używa do reprezentacji {{< glossary_tooltip text="klastra" term_id="cluster" length="all" >}}, a także posłużyć do lepszego poznania działania całego systemu.
-
-
-
-<!-- body -->
-
-## Przegląd
-
-Pracując w środowisku Kubernetes, używasz *obiektów API Kubernetes* aby opisać *zamierzony stan* klastra: jakie aplikacje lub inne zadania chcesz uruchomić, jakich obrazów kontenerów chcesz użyć, ilu replik potrzebujesz, które zasoby dyskowe i sieciowe chcesz udostępnić itp. Zamierzony stan uzyskuje się definiując obiekty API Kubernetes, zazwyczaj przy pomocy polecenia `kubectl`. Możesz także używać API bezpośrednio, aby konfigurować i modyfikować stan klastra.
-
-Gdy tylko zdefiniujesz zamierzony stan, warstwa sterowania Kubernetes (*Kubernetes Control Plane*) podejmuje działania, aby aktualny stan klastra był zgodny ze stanem zamierzonym, wykorzystując do tego Pod Lifecycle Event Generator ([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md)). W tym celu Kubernetes wykonuje szereg automatycznych zadań, takich jak start lub restart kontenerów, skalowanie liczby replik dla danej aplikacji itp. Warstwa sterowania Kubernetes to zbiór różnych procesów działających na klastrze:
-
-* **Kubernetes Master** to zbiór trzech procesów uruchamianych na pojedynczym węźle klastra, który pełni rolę węzła _master_. Te procesy to: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) oraz [kube-scheduler](/docs/admin/kube-scheduler/).
-* Na każdym węźle klastra, nie będącym węzłem typu _Master_, działają dwa procesy:
- * **[kubelet](/docs/admin/kubelet/)**, który komunikuje się z Kubernetes Master.
- * **[kube-proxy](/docs/admin/kube-proxy/)**, proxy sieciowe pośredniczące w usługach sieciowych Kubernetes.
-
-## Obiekty Kubernetes
-
-Kubernetes składa się z różnych abstrakcyjnych obiektów, które reprezentują stan systemu: wdrożone aplikacje i zadania w kontenerach, powiązane zasoby sieciowe i dyskowe oraz inne informacje o tym, co się dzieje na klasterze. Te abstrakcyjne obiekty są reprezentowane przez API Kubernetes. [Opis obiektów w Kubernetesie](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) zawiera więcej szczegółów na ten temat.
-
-Do podstawowych obiektów Kubernetes należą:
-
-* [Pod](/docs/concepts/workloads/pods/pod-overview/)
-* [Service *(Serwis)*](/docs/concepts/services-networking/service/)
-* [Volume *(Wolumin)*](/docs/concepts/storage/volumes/)
-* [Namespace *(Przestrzeń nazw)*](/docs/concepts/overview/working-with-objects/namespaces/)
-
-Kubernetes zawiera także obiekty abstrakcyjne wyższego poziomu, zbudowane z obiektów podstawowych przy wykorzystaniu [kontrolerów](/docs/concepts/architecture/controller/), które dostarczają dodatkowe funkcjonalności i udogodnienia. Należą do nich:
-
- * [Deployment](/docs/concepts/workloads/controllers/deployment/)
- * [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
- * [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
- * [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
- * [Job](/docs/concepts/workloads/controllers/job/)
-
-## Warstwa sterowania (*Kubernetes Control Plane*) {#warstwa-sterowania}
-
-Różne komponenty warstwy sterowania, takie jak: *Kubernetes Master* czy *kubelet*, odpowiadają za to, jak Kubernetes komunikuje się z klastrem. Warstwa sterowania przechowuje informacje o wszystkich obiektach Kubernetes w systemie i w sposób ciągły steruje ich stanem. Pętle sterowania reagują na zmiany zachodzące w klastrze w sposób ciągły, starając się doprowadzić, aby stan faktyczny wszystkich obiektów odpowiadał stanowi zamierzonemu przez użytkownika.
-
-Przykładowo, kiedy używasz Kubernetes API do stworzenia Deploymentu, podajesz oczekiwany stan systemu. Warstwa sterowania Kubernetes zapisuje stworzenie tego obiektu, a następnie realizuje Twoje polecenie startując wymagane aplikacje i zlecając ich uruchomienie na węzłach klastra - w ten sposób starając się zapewnić, że faktyczny stan klastra jest zgodny ze stanem zamierzonym.
-
-### Kubernetes Master
-
-*Kubernetes Master* odpowiada za utrzymanie klastra w zamierzonym stanie. Za każdym razem, kiedy korzystasz z `kubectl`, łączysz się z węzłem typu *master* danego klastra.
-
-> "*Master*" odnosi się do zbioru procesów zarządzających stanem klastra. Zazwyczaj procesy te są uruchomione na pojedynczym węźle klastra, który jest określany jako "master". Master może być też zreplikowany w celu zagwarantowania wyższej dostępności i niezawodności.
-
-### Węzły (*Kubernetes Nodes*) {#wezly}
-
-Węzły klastra to maszyny (wirtualne, fizyczne i in.), na których uruchamiane są aplikacje i inne zadania. Kubernetes master steruje każdym z węzłów — rzadko kiedy zachodzi konieczność bezpośredniej interakcji z węzłami.
-
-
-
-## {{% heading "whatsnext" %}}
-
-
-Jeśli chcesz dodać stronę z nowym pojęciem, odwiedź
-[Page Content Types](/docs/contribute/style/page-content-types/#concept),
-aby dowiedzieć się o tworzeniu stron opisujących pojęcia.
-
-
diff --git a/content/pl/docs/concepts/overview/_index.md b/content/pl/docs/concepts/overview/_index.md
index 9d2cdd909c..32ab47ea71 100755
--- a/content/pl/docs/concepts/overview/_index.md
+++ b/content/pl/docs/concepts/overview/_index.md
@@ -1,4 +1,5 @@
---
title: "Przegląd"
weight: 20
----
\ No newline at end of file
+description: Ogólny zarys Kubernetesa i komponentów, z których jest zbudowany.
+---
diff --git a/content/pl/docs/concepts/overview/components.md b/content/pl/docs/concepts/overview/components.md
index 3dcc818d1f..ce4ea28ff2 100644
--- a/content/pl/docs/concepts/overview/components.md
+++ b/content/pl/docs/concepts/overview/components.md
@@ -1,6 +1,9 @@
---
-title: Składniki Kubernetes
+title: Składniki Kubernetesa
content_type: concept
+description: >
+ Klaster Kubernetesa tworzą: komponenty warstwy sterowania
+ oraz zbiór maszyn nazywanych węzłami.
weight: 20
card:
name: concepts
diff --git a/content/pl/docs/concepts/overview/kubernetes-api.md b/content/pl/docs/concepts/overview/kubernetes-api.md
index e13a77196f..5761b20c61 100644
--- a/content/pl/docs/concepts/overview/kubernetes-api.md
+++ b/content/pl/docs/concepts/overview/kubernetes-api.md
@@ -2,6 +2,9 @@
title: API Kubernetes
content_type: concept
weight: 30
+description: >
+ API Kubernetesa służy do odpytywania i zmiany stanu obiektów Kubernetesa.
+ Sercem warstwy sterowania Kubernetesa jest serwer API i udostępniane przez niego HTTP API. Przez ten serwer odbywa się komunikacja pomiędzy użytkownikami, różnymi częściami składowymi klastra oraz komponentami zewnętrznymi.
card:
name: concepts
weight: 30
@@ -17,9 +20,6 @@ API Kubernetes pozwala na sprawdzanie i zmianę stanu obiektów (przykładowo: p
Punkt dostępowe _(endpoints)_ API, typy zasobów i przykłady opisane są w [API Reference](/docs/reference/kubernetes-api/).
-
-
-
<!-- body -->
## Zmiany w API
@@ -80,7 +80,7 @@ W Kubernetes zaimplementowany jest alternatywny format serializacji na potrzeby
Aby ułatwić usuwanie poszczególnych pól lub restrukturyzację reprezentacji zasobów, Kubernetes obsługuje
równocześnie wiele wersji API, każde poprzez osobną ścieżkę API, na przykład: `/api/v1` lub
-`/apis/extensions/v1beta1`.
+`/apis/rbac.authorization.k8s.io/v1alpha1`.
Zdecydowaliśmy się na rozdział wersji na poziomie całego API, a nie na poziomie poszczególnych zasobów lub pól, aby być pewnym,
że API odzwierciedla w sposób przejrzysty i spójny zasoby systemowe i ich zachowania i pozwala
@@ -127,7 +127,7 @@ Obecne w użyciu jest kilka grup API:
1. Nazwane grupy udostępnione są przez ścieżkę REST `/apis/$GROUP_NAME/$VERSION` i używają `apiVersion: $GROUP_NAME/$VERSION`
(np. `apiVersion: batch/v1`). Pełna lista wpieranych grup API jest dostępna w [Kubernetes API reference](/pl/docs/reference/).
-API może być rozbudowane na dwa sposoby przy użyciu [custom resources](/docs/concepts/api-extension/custom-resources/):
+API może być rozbudowane na dwa sposoby przy użyciu [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/):
1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)
jest przewidziana dla użytkowników z minimalnymi wymaganiami CRUD.
@@ -147,20 +147,11 @@ Ta opcja przyjmuje rozdzielony przecinkami zbiór par klucz=wartość, który op
{{< note >}}Włączenie lub wyłączenie grup lub zasobów wymaga restartu kube-apiserver i kube-controller-manager,
aby zmiany w `--runtime-config` zostały wprowadzone.{{< /note >}}
-## Dostęp do grup zasobów _extensions/v1beta1_
-
-DaemonSets, Deployments, HorizontalPodAutoscalers, Ingresses, Jobs i ReplicaSets znajdują się w grupie API `extensions/v1beta1` i są domyślnie wyłączone.
-Przykładowo: aby włączyć deployments i daemonsets, ustaw
-`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`.
-
-{{< note >}}Włączanie i wyłączanie pojedynczych zasobów możliwe jest jedynie w ramach grupy API `extensions/v1beta1` z przyczyn historycznych{{< /note >}}
-
## Trwałość
Kubernetes przechowuje swój stan w postaci serializowanej jako zasoby API zapisywane w
{{< glossary_tooltip term_id="etcd" >}}.
-
## {{% heading "whatsnext" %}}
[Controlling API Access](/docs/reference/access-authn-authz/controlling-access/) opisuje
diff --git a/content/pl/docs/contribute/_index.md b/content/pl/docs/contribute/_index.md
index c8fa5f636b..a6f9356a58 100644
--- a/content/pl/docs/contribute/_index.md
+++ b/content/pl/docs/contribute/_index.md
@@ -27,42 +27,60 @@ Zapraszamy do współpracy wszystkich - zarówno nowicjuszy, jak i doświadczony
## Jak zacząć?
-Każdy może otworzyć zgłoszenie dotyczące dokumentacji lub zaproponować zmianę poprzez *pull request* (PR) do [repozytorium GitHub `kubernetes/website`](https://github.com/kubernetes/website). Aby móc sprawnie funkcjonować w społeczności Kubernetes,
-wymagana jest pewna biegłość w korzystaniu z [git-a](https://git-scm.com/) i [GitHub-a](https://lab.github.com/).
+Każdy może otworzyć zgłoszenie dotyczące dokumentacji lub zaproponować zmianę poprzez
+*pull request* (PR) do
+[repozytorium GitHub `kubernetes/website`](https://github.com/kubernetes/website).
+Aby móc sprawnie funkcjonować w społeczności Kubernetes,
+wymagana jest pewna biegłość w korzystaniu z
+[git-a](https://git-scm.com/) i
+[GitHub-a](https://lab.github.com/).
Aby zaangażować się w prace nad dokumentacją należy:
1. Podpisać [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md) CNCF.
-2. Zapoznać się z [repozytorium dokumentacji](https://github.com/kubernetes/website) i z [generatorem statycznej strony](https://gohugo.io) www.
-3. Zrozumieć podstawowe procesy [otwierania *pull request*](/docs/contribute/new-content/new-content/) oraz [recenzowania zmian](/docs/contribute/review/reviewing-prs/).
+1. Zapoznać się z [repozytorium dokumentacji](https://github.com/kubernetes/website)
+ i z [generatorem statycznej strony](https://gohugo.io) www.
+1. Zrozumieć podstawowe procesy [otwierania *pull request*](/docs/contribute/new-content/new-content/) oraz
+ [recenzowania zmian](/docs/contribute/review/reviewing-prs/).
Do realizacji niektórych zadań potrzeba wyższego poziomu zaufania i odpowiednich uprawnień w organizacji Kubernetes.
-Zajrzyj do [Participating in SIG Docs](/docs/contribute/participating/) po więcej szczegółów dotyczących
+Zajrzyj do [Participating in SIG Docs](/docs/contribute/participate/) po więcej szczegółów dotyczących
ról i uprawnień.
## Pierwsze kroki
-- Przeczytaj [Contribution overview](/docs/contribute/new-content/overview/), aby dowiedzieć się o różnych sposobach współpracy.
-- Zajrzyj do [Contribute to kubernetes/website](https://github.com/kubernetes/website/contribute) aby znaleźć dobre zgłoszenie na początek.
-- [Otwórz *pull request* przy pomocy GitHub-a](/docs/contribute/new-content/new-content/#changes-using-github) dotyczący zmiany istniejącej dokumentacji i dowiedz się, jak otwierać zgłoszenia przy GitHub-ie.
-- [Zrecenzuj *pull requests*](/docs/contribute/review/reviewing-prs/) innego członka społeczności Kubernetes pod kątem dokładności i stylu.
-- Zapoznaj się z poradnikami Kubernetesa dotyczącymi [zawartości](/docs/contribute/style/content-guide/) i [stylu](/docs/contribute/style/style-guide/), aby twoje uwagi były zgodne z tymi wytycznymi.
-- Przeczytaj o [różnych typach zawartości na stronie](/docs/contribute/style/page-content-types/) i [skrótach Hugo](/docs/contribute/style/hugo-shortcodes/).
+- Przeczytaj [Contribution overview](/docs/contribute/new-content/overview/),
+ aby dowiedzieć się o różnych sposobach współpracy.
+- Zajrzyj do [Contribute to kubernetes/website](https://github.com/kubernetes/website/contribute),
+ aby znaleźć dobre zgłoszenie na początek.
+- [Otwórz *pull request* przy pomocy GitHub-a](/docs/contribute/new-content/new-content/#changes-using-github)
+ dotyczący zmiany istniejącej dokumentacji i dowiedz się, jak otwierać zgłoszenia przy GitHub-ie.
+- [Zrecenzuj *pull requests*](/docs/contribute/review/reviewing-prs/)
+ innego członka społeczności Kubernetes pod kątem dokładności i stylu.
+- Zapoznaj się z poradnikami Kubernetesa dotyczącymi [zawartości](/docs/contribute/style/content-guide/)
+ i [stylu](/docs/contribute/style/style-guide/), aby twoje uwagi były zgodne z tymi wytycznymi.
+- Przeczytaj o [różnych typach zawartości na stronie](/docs/contribute/style/page-content-types/)
+ i [skrótach Hugo](/docs/contribute/style/hugo-shortcodes/).
## Co dalej?
-- Naucz się, jak [pracować z lokalną kopią](/docs/contribute/new-content/new-content/#fork-the-repo) repozytorium.
+- Naucz się, jak [pracować z lokalną kopią](/docs/contribute/new-content/new-content/#fork-the-repo)
+ repozytorium.
- Udokumentuj [nowe funkcjonalności](/docs/contribute/new-content/new-features/).
-- Włącz się w prace [SIG Docs](/docs/contribute/participating/) i zostań [członkiem organizacji lub recenzentem](/docs/contribute/participating/#roles-and-responsibilities).
+- Włącz się w prace [SIG Docs](/docs/contribute/participating/)
+ i zostań [członkiem organizacji lub recenzentem](/docs/contribute/participating/#roles-and-responsibilities).
- Pomagaj przy [tłumaczeniu](/docs/contribute/localization/).
## Włącz się w prace SIG Docs
-[SIG Docs](/docs/contribute/participating/) to grupa, która publikuje i utrzymuje dokumentację Kubernetesa i jej stronę www. Zaangażowanie się w prace SIG Docs to doskonała okazja dla współtwórców Kubernetesa (rozwijających nowe funkcjonalności lub działających w innych obszarach), aby wywierać wpływ na cały projekt Kubernetes.
+[SIG Docs](/docs/contribute/participating/) to grupa, która publikuje
+i utrzymuje dokumentację Kubernetesa i jej stronę www. Zaangażowanie się w prace SIG Docs
+to doskonała okazja dla współtwórców Kubernetesa (rozwijających nowe funkcjonalności
+lub działających w innych obszarach), aby wywierać wpływ na cały projekt Kubernetes.
Aby włączyć się w komunikację w ramach SIG Docs, możesz:
-- [Dołączyć do kanału `#sig-docs` na komunikatorze Slack dla Kubernetesa](http://slack.k8s.io/). Nie zapomnij
+- [Dołączyć do kanału `#sig-docs` na komunikatorze Slack dla Kubernetesa](https://slack.k8s.io/). Nie zapomnij
się przedstawić!
- [Zapisać się na listę `kubernetes-sig-docs`](https://groups.google.com/forum/#!forum/kubernetes-sig-docs),
na której prowadzone są dyskusje o szerszym zasięgu i zapisywane oficjalne decyzje.
@@ -73,5 +91,3 @@ Aby włączyć się w komunikację w ramach SIG Docs, możesz:
- Odwiedź [stronę społeczności Kubernetes](/community/). Korzystaj z Twittera i Stack Overflow, dowiedz się o spotkaniach lokalnych grup Kubernetes, różnych wydarzeniach i nie tylko.
- Przeczytaj [ściągawkę dla współtwórców](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet), aby zaangażować się w dalszy rozwój Kubernetesa.
- Przygotuj [wpis na blogu lub *case study*](/docs/contribute/new-content/blogs-case-studies/).
-
-
diff --git a/content/pl/docs/reference/_index.md b/content/pl/docs/reference/_index.md
index 15374cdaa9..c8c2ff8835 100644
--- a/content/pl/docs/reference/_index.md
+++ b/content/pl/docs/reference/_index.md
@@ -33,7 +33,7 @@ biblioteki to:
## Dokumentacja poleceń tekstowych *(CLI)*
* [kubectl](/docs/reference/kubectl/overview/) - Główne narzędzie tekstowe (linii poleceń) do zarządzania klastrem Kubernetes.
- * [JSONPath](/docs/reference/kubectl/jsonpath/) - Podręcznik składni [wyrażeń JSONPath](http://goessner.net/articles/JsonPath/) dla kubectl.
+ * [JSONPath](/docs/reference/kubectl/jsonpath/) - Podręcznik składni [wyrażeń JSONPath](https://goessner.net/articles/JsonPath/) dla kubectl.
* [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - Narzędzie tekstowe do łatwego budowania klastra Kubernetes spełniającego niezbędne wymogi bezpieczeństwa.
## Dokumentacja komponentów
@@ -48,6 +48,6 @@ biblioteki to:
## Dokumentacja projektowa
-Archiwum dokumentacji projektowej różnych funkcjonalności Kubernetes. Warto zacząć od [Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) oraz [Kubernetes Design Overview](https://git.k8s.io/community/contributors/design-proposals).
-
-
+Archiwum dokumentacji projektowej różnych funkcjonalności Kubernetes. Warto zacząć od
+[Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) oraz
+[Kubernetes Design Overview](https://git.k8s.io/community/contributors/design-proposals).
diff --git a/content/pl/docs/setup/_index.md b/content/pl/docs/setup/_index.md
index 2b014be8a4..6107fe0f03 100644
--- a/content/pl/docs/setup/_index.md
+++ b/content/pl/docs/setup/_index.md
@@ -17,26 +17,15 @@ card:
<!-- overview -->
Ten rozdział poświęcony jest różnym metodom konfiguracji i uruchomienia Kubernetesa.
+Instalując Kubernetesa, przy wyborze platformy kieruj się: łatwością w utrzymaniu, spełnianymi wymogami bezpieczeństwa, poziomem sterowania, dostępnością zasobów oraz doświadczeniem wymaganym do zarządzania klastrem.
-Istnieje wiele rozwiązań dopasowanych do różnych potrzeb użytkowników: łatwości w utrzymaniu, wymagań bezpieczeństwa, poziomu sterowania, dostępności zasobów oraz niezbędnego doświadczenia do zarządzania klastrem.
-
-Klaster Kubernetes możesz zainstalować na lokalnym komputerze, w chmurze czy w prywatnym centrum obliczeniowym albo skorzystać z klastra Kubernetes udostępnianego jako usługa. Inną możliwością jest budowa własnego rozwiązania opartego o różnych dostawców usług chmurowych, bądź bazującego bezpośrednio na sprzęcie fizycznym.
-
-W dużym uproszczeniu, możesz zbudować klaster Kubernetes zarówno w środowisku szkoleniowym, jak i na potrzeby produkcyjne.
+Klaster Kubernetes możesz zainstalować na lokalnym komputerze, w chmurze czy w prywatnym centrum obliczeniowym albo skorzystać z klastra Kubernetes udostępnianego jako usługa. Inną możliwością jest budowa własnego systemu opartego o różnych dostawców usług chmurowych, bądź bazującego bezpośrednio na sprzęcie fizycznym.
<!-- body -->
## Środowisko do nauki {#srodowisko-do-nauki}
-Aby uruchomić klaster Kubernetes do nauki na lokalnym komputerze, skorzystaj z rozwiązań opartych o Dockera — z narzędzi wspieranych przez społeczność Kubernetesa, bądź innych narzędzi dostępnych w ekosystemie.
-
-{{< table caption="Tabela z rozwiązaniami pozwalającymi na uruchomienie Kubernetesa na komputerze lokalnym - wspieranymi przez społeczność lub innymi dostępnymi w ekosystemie" >}}
-
-|Społeczność |Ekosystem |
-| ------------ | -------- |
-| [Minikube](/docs/setup/learning-environment/minikube/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)|
-| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Minishift](https://docs.okd.io/latest/minishift/)|
-| | [MicroK8s](https://microk8s.io/)|
+Do nauki Kubernetesa wykorzystaj narzędzia wspierane przez społeczność Kubernetesa lub inne narzędzia dostępne w ekosystemie, aby uruchomić klaster Kubernetesa na swoim komputerze lokalnym.
## Środowisko produkcyjne {#srodowisko-produkcyjne}
diff --git a/content/pl/docs/tasks/_index.md b/content/pl/docs/tasks/_index.md
index 5a185543c3..94c292d8a6 100644
--- a/content/pl/docs/tasks/_index.md
+++ b/content/pl/docs/tasks/_index.md
@@ -11,7 +11,5 @@ W tej części dokumentacji Kubernetesa znajdują się opisy
sposobu realizacji różnych zadań. Przedstawione są one zazwyczaj jako
krótka sekwencja kilku kroków związanych z pojedynczym zadaniem.
-## {{% heading "whatsnext" %}}
-
Jeśli chciałbyś stworzyć nową stronę poświęconą jakiemuś zadaniu, przeczytaj
[Jak przygotować propozycję zmian (PR)](/docs/home/contribute/create-pull-request/).
diff --git a/content/pl/docs/tutorials/_index.md b/content/pl/docs/tutorials/_index.md
index 0f9d7ac723..5593490dc3 100644
--- a/content/pl/docs/tutorials/_index.md
+++ b/content/pl/docs/tutorials/_index.md
@@ -14,8 +14,6 @@ z których każda zawiera sekwencję odpowiednich kroków.
Przed zapoznaniem się z samouczkami warto stworzyć zakładkę do
[słownika](/docs/reference/glossary/), aby móc się później do niego na bieżąco odwoływać.
-
-
<!-- body -->
## Podstawy
@@ -46,16 +44,6 @@ Przed zapoznaniem się z samouczkami warto stworzyć zakładkę do
* [Running ZooKeeper, A CP Distributed System](/docs/tutorials/stateful-application/zookeeper/)
-## CI/CD Pipeline
-
-* [Set Up a CI/CD Pipeline with Kubernetes Part 1: Overview](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/5/set-cicd-pipeline-kubernetes-part-1-overview)
-
-* [Set Up a CI/CD Pipeline with a Jenkins Pod in Kubernetes (Part 2)](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/6/set-cicd-pipeline-jenkins-pod-kubernetes-part-2)
-
-* [Run and Scale a Distributed Crossword Puzzle App with CI/CD on Kubernetes (Part 3)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/run-and-scale-distributed-crossword-puzzle-app-cicd-kubernetes-part-3)
-
-* [Set Up CI/CD for a Distributed Crossword Puzzle App on Kubernetes (Part 4)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/set-cicd-distributed-crossword-puzzle-app-kubernetes-part-4)
-
## Klastry
* [AppArmor](/docs/tutorials/clusters/apparmor/)
@@ -64,13 +52,8 @@ Przed zapoznaniem się z samouczkami warto stworzyć zakładkę do
* [Using Source IP](/docs/tutorials/services/source-ip/)
-
-
## {{% heading "whatsnext" %}}
-
Jeśli chciałbyś napisać nowy samouczek, odwiedź
[Content Page Types](/docs/contribute/style/page-content-types/),
gdzie znajdziesz dodatkowe informacje o tym typie strony.
-
-
diff --git a/content/pl/docs/tutorials/hello-minikube.md b/content/pl/docs/tutorials/hello-minikube.md
index 653f9403de..a56396843c 100644
--- a/content/pl/docs/tutorials/hello-minikube.md
+++ b/content/pl/docs/tutorials/hello-minikube.md
@@ -63,7 +63,7 @@ W tym samouczku wykorzystamy obraz kontenera, który korzysta z NGINX, aby wyśw
## Stwórz Deployment
-[*Pod*](/docs/concepts/workloads/pods/pod/) w Kubernetes to grupa jednego lub wielu kontenerów
+[*Pod*](/docs/concepts/workloads/pods/) w Kubernetes to grupa jednego lub wielu kontenerów
połączonych ze sobą na potrzeby administrowania i dostępu sieci. W tym samouczku Pod
zawiera tylko jeden kontener. [*Deployment*](/docs/concepts/workloads/controllers/deployment/)
w Kubernetes monitoruje stan twojego Poda
@@ -115,7 +115,9 @@ wykorzystując podany obraz Dockera.
kubectl config view
```
- {{< note >}}Więcej informacji na temat polecenia `kubectl` znajdziesz w [przeglądzie kubectl](/docs/user-guide/kubectl-overview/).{{< /note >}}
+ {{< note >}}
+ Więcej informacji na temat polecenia `kubectl` znajdziesz w [przeglądzie kubectl](/docs/reference/kubectl/overview/).
+ {{< /note >}}
## Stwórz Serwis
diff --git a/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
index ea083b33e7..4b6676a0c2 100644
--- a/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+++ b/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
@@ -20,7 +20,7 @@ weight: 20
<div class="row">
<div class="col-md-12">
<p>
- Pod to podstawowy element odpowiedzialny za uruchomienie aplikacji na Kubernetesie. Każdy pod to część składowa całościowego obciążenia Twojego klastra. <a href="/docs/concepts/workloads/pods/pod-overview/#understanding-pods">Dowiedz się więcej na temat Podów</a>.
+ Pod to podstawowy element odpowiedzialny za uruchomienie aplikacji na Kubernetesie. Każdy pod to część składowa całościowego obciążenia Twojego klastra. <a href="/docs/concepts/workloads/pods/">Dowiedz się więcej na temat Podów</a>.
</p>
</div>
</div>
diff --git a/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html
index d3fa9a8343..4ad9a7be76 100644
--- a/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html
+++ b/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html
@@ -28,7 +28,7 @@ weight: 10
<div class="col-md-8">
<h3>Kubernetes Services - przegląd</h3>
- <p><a href="/docs/concepts/workloads/pods/pod-overview/">Pody</a> Kubernetes są nietrwałe. Pody mają swój <a href="/docs/concepts/workloads/pods/pod-lifecycle/">cykl życia</a>. Jeśli węzeł roboczy ulegnie awarii, tracone są wszystkie pody działające na węźle. <a href="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> będzie próbował automatycznie doprowadzić klaster z powrotem do pożądanego stanu tworząc nowe pody i w ten sposób zapewnić działanie aplikacji. Innym przykładem może być system na back-endzie przetwarzania obrazów posiadający 3 repliki. Każda z tych replik jest wymienna - system front-endu nie powinien musieć pilnować replik back-endu ani tego, czy któryś z podów przestał działać i został odtworzony na nowo. Nie należy jednak zapominać o tym, że każdy Pod w klastrze Kubernetes ma swój unikatowy adres IP, nawet pody w obrębie tego samego węzła, zatem powinna istnieć metoda automatycznego uzgadniania zmian pomiędzy podami, aby aplikacja mogła dalej funkcjonować.</p>
+ <p><a href="/docs/concepts/workloads/pods/">Pody</a> Kubernetes są nietrwałe. Pody mają swój <a href="/docs/concepts/workloads/pods/pod-lifecycle/">cykl życia</a>. Jeśli węzeł roboczy ulegnie awarii, tracone są wszystkie pody działające na węźle. <a href="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> będzie próbował automatycznie doprowadzić klaster z powrotem do pożądanego stanu tworząc nowe pody i w ten sposób zapewnić działanie aplikacji. Innym przykładem może być system na back-endzie przetwarzania obrazów posiadający 3 repliki. Każda z tych replik jest wymienna - system front-endu nie powinien musieć pilnować replik back-endu ani tego, czy któryś z podów przestał działać i został odtworzony na nowo. Nie należy jednak zapominać o tym, że każdy Pod w klastrze Kubernetes ma swój unikatowy adres IP, nawet pody w obrębie tego samego węzła, zatem powinna istnieć metoda automatycznego uzgadniania zmian pomiędzy podami, aby aplikacja mogła dalej funkcjonować.</p>
<p>Serwis w Kubernetes jest abstrakcyjnym obiektem, która definiuje logiczny zbiór podów oraz politykę dostępu do nich. Serwisy pozwalają na swobodne łączenie zależnych podów. Serwis jest zdefiniowany w YAMLu <a href="/docs/concepts/configuration/overview/#general-configuration-tips">(zalecane)</a> lub w JSONie - tak, jak wszystkie obiekty Kubernetes. Zbiór podów, które obsługuje Serwis, jest zazwyczaj określany przez <i>LabelSelector</i> (poniżej opisane jest, w jakich przypadkach możesz potrzebować zdefiniować Serwis bez specyfikowania <code>selektora</code>).</p>
diff --git a/content/pl/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/pl/docs/tutorials/kubernetes-basics/scale/scale-intro.html
index 89d4240889..91eb10eb6d 100644
--- a/content/pl/docs/tutorials/kubernetes-basics/scale/scale-intro.html
+++ b/content/pl/docs/tutorials/kubernetes-basics/scale/scale-intro.html
@@ -40,7 +40,7 @@ weight: 10
</ul>
</div>
<div class="content__box content__box_fill">
- <p><i> Od samego początku w ramach Deploymentu można uruchomić wiele instancji — skorzystaj z parametru --replicas polecenia kubectl run</i></p>
+ <p><i> Od samego początku w ramach Deploymentu można uruchomić wiele instancji — skorzystaj z parametru --replicas polecenia kubectl create deployment</i></p>
</div>
</div>
</div>
diff --git a/content/pt/docs/tutorials/_index.md b/content/pt/docs/tutorials/_index.md
index 85941bc187..a488f84388 100644
--- a/content/pt/docs/tutorials/_index.md
+++ b/content/pt/docs/tutorials/_index.md
@@ -43,16 +43,6 @@ Antes de iniciar um tutorial, é interessante que vocẽ salve a página de [Glo
* [Executando ZooKeeper no Kubernetes](/docs/tutorials/stateful-application/zookeeper/)
-## Pipelines de CI/CD
-
-* [Configurando um Pipeline CI/CD com Kubernetes Parte 1: Visão Geral](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/5/set-cicd-pipeline-kubernetes-part-1-overview)
-
-* [Configurando um Pipeline CI/CD com um Pod Jenkins no Kubernetes (Parte 2)](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/6/set-cicd-pipeline-jenkins-pod-kubernetes-part-2)
-
-* [Executando e escalando um aplicativo distribuído de palavras cruzadas com CI/CD no Kubernetes (Parte 3)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/run-and-scale-distributed-crossword-puzzle-app-cicd-kubernetes-part-3)
-
-* [Configurando um CI/CD para um aplicativo distribuído de palavras cruzadas no Kubernetes (Parte 4)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/set-cicd-distributed-crossword-puzzle-app-kubernetes-part-4)
-
## Clusters
* [AppArmor](/docs/tutorials/clusters/apparmor/)
diff --git a/content/ru/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/ru/docs/tasks/configure-pod-container/assign-cpu-resource.md
index c94a1ba15e..f82d690af5 100644
--- a/content/ru/docs/tasks/configure-pod-container/assign-cpu-resource.md
+++ b/content/ru/docs/tasks/configure-pod-container/assign-cpu-resource.md
@@ -144,7 +144,7 @@ kubectl delete pod cpu-demo --namespace=cpu-example
чем контейнер, запрашивающий 1 CPU. Можно использовать окончание m для обозначения милли. Например,
100m CPU, 100 milliCPU и 0.1 CPU обозначают одно и то же. Точность выше 1m не поддерживается.
-CPU всегда запрашивается в абсолютных величинах, не в относиительных; 0.1 будет одинаковой частью от CPU
+CPU всегда запрашивается в абсолютных величинах, не в относительных; 0.1 будет одинаковой частью от CPU
для одноядерного, двухъядерного или 48-ядерного процессора.
## Запрос ресурсов CPU больше доступного на ноде
@@ -263,4 +263,4 @@ kubectl delete namespace cpu-example
* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/)
-* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
\ No newline at end of file
+* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
diff --git a/content/ru/docs/tutorials/_index.md b/content/ru/docs/tutorials/_index.md
index 0ae88119cc..e251975329 100644
--- a/content/ru/docs/tutorials/_index.md
+++ b/content/ru/docs/tutorials/_index.md
@@ -43,16 +43,6 @@ content_type: concept
* [Запуск ZooKeeper, A CP Distributed System](/docs/tutorials/stateful-application/zookeeper/)
-## Конвейерная обработка CI/CD
-
-* [Настройка конвейера CI/CD с Kubernetes Часть 1: Обзор](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/5/set-cicd-pipeline-kubernetes-part-1-overview)
-
-* [Настройка конвейера CI/CD с подом Jenkins в Kubernetes (Часть 2)](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/6/set-cicd-pipeline-jenkins-pod-kubernetes-part-2)
-
-* [Запуск и масштабирование приложения распределённого кроссворда с CI/CD в Kubernetes (Часть 3)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/run-and-scale-distributed-crossword-puzzle-app-cicd-kubernetes-part-3)
-
-* [Настройка CI/CD для приложения распределённого кроссворда в Kubernetes (Часть 4)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/set-cicd-distributed-crossword-puzzle-app-kubernetes-part-4)
-
## Кластеры
* [AppArmor](/docs/tutorials/clusters/apparmor/)
diff --git a/content/uk/docs/tutorials/_index.md b/content/uk/docs/tutorials/_index.md
index 90cb51eb12..09c8b1e7a8 100644
--- a/content/uk/docs/tutorials/_index.md
+++ b/content/uk/docs/tutorials/_index.md
@@ -57,16 +57,6 @@ Before walking through each tutorial, you may want to bookmark the
* [Running ZooKeeper, A CP Distributed System](/docs/tutorials/stateful-application/zookeeper/)
-## CI/CD Pipeline
-
-* [Set Up a CI/CD Pipeline with Kubernetes Part 1: Overview](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/5/set-cicd-pipeline-kubernetes-part-1-overview)
-
-* [Set Up a CI/CD Pipeline with a Jenkins Pod in Kubernetes (Part 2)](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/6/set-cicd-pipeline-jenkins-pod-kubernetes-part-2)
-
-* [Run and Scale a Distributed Crossword Puzzle App with CI/CD on Kubernetes (Part 3)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/run-and-scale-distributed-crossword-puzzle-app-cicd-kubernetes-part-3)
-
-* [Set Up CI/CD for a Distributed Crossword Puzzle App on Kubernetes (Part 4)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/set-cicd-distributed-crossword-puzzle-app-kubernetes-part-4)
-
## Кластери
* [AppArmor](/docs/tutorials/clusters/apparmor/)
diff --git a/content/zh/blog/_posts/2018-04-25-open-source-charts-2017.md b/content/zh/blog/_posts/2018-04-25-open-source-charts-2017.md
new file mode 100644
index 0000000000..2c38dd1be0
--- /dev/null
+++ b/content/zh/blog/_posts/2018-04-25-open-source-charts-2017.md
@@ -0,0 +1,102 @@
+---
+title: Kubernetes 社区 - 2017 年开源排行榜榜首
+date: 2018-04-25
+slug: open-source-charts-2017
+---
+<!--
+---
+title: Kubernetes Community - Top of the Open Source Charts in 2017
+date: 2018-04-25
+slug: open-source-charts-2017
+---
+--->
+
+<!--
+2017 was a huge year for Kubernetes, and GitHub’s latest [Octoverse report](https://octoverse.github.com) illustrates just how much attention this project has been getting.
+
+Kubernetes, an [open source platform for running application containers](/docs/concepts/overview/what-is-kubernetes/), provides a consistent interface that enables developers and ops teams to automate the deployment, management, and scaling of a wide variety of applications on just about any infrastructure.
+--->
+对于 Kubernetes 来说，2017 年是丰收的一年，GitHub的最新 [Octoverse 报告](https://octoverse.github.com) 说明了该项目获得了多少关注。
+
+Kubernetes 是 [用于运行应用程序容器的开源平台](/docs/concepts/overview/what-is-kubernetes/)，它提供了一个统一的界面，使开发人员和操作团队能够自动执行部署、管理和扩展几乎任何基础架构上的各种应用程序。
+
+<!--
+Solving these shared challenges by leveraging a wide community of expertise and industrial experience, as Kubernetes does, helps engineers focus on building their own products at the top of the stack, rather than needlessly duplicating work that now exists as a standard part of the “cloud native” toolkit.
+
+However, achieving these gains via ad-hoc collective organizing is its own unique challenge, one which makes it increasingly difficult to support open source, community-driven efforts through periods of rapid growth.
+
+Read on to find out how the Kubernetes Community has addressed these scaling challenges to reach the top of the charts in GitHub’s 2017 Octoverse report.
+--->
+Kubernetes 所做的，是通过利用广泛的专业知识和行业经验来解决这些共同的挑战，可以帮助工程师专注于在堆栈的顶部构建自己的产品，而不是不必要地进行重复工作，比如现在已经存在的 “云原生” 工具包的标准部分。
+
+但是，通过临时的集体组织来实现这些收益是它独有的挑战，这使得支持开源，社区驱动的工作变得越来越困难。
+
+继续阅读以了解 Kubernetes 社区如何解决这些挑战，从而在 GitHub 的 2017 Octoverse 报告中位居榜首。
+
+<!--
+## Most-Discussed on GitHub
+
+The top two most-discussed repos of 2017 are both based on Kubernetes:
+
+
+
+Of all the open source repositories on GitHub, none received more issue comments than [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes/). [OpenShift](http://openshift.com/), a [CNCF certified distribution of Kubernetes](https://www.cncf.io/announcement/2017/11/13/cloud-native-computing-foundation-launches-certified-kubernetes-program-32-conformant-distributions-platforms/), took second place.
+
+Open discussion with ample time for community feedback and review helps build shared infrastructure and establish new standards for cloud native computing.
+--->
+## GitHub 上讨论最多的
+
+2017 年讨论最多的两个仓库都是基于 Kubernetes 的：
+
+！[讨论最多](/images/blog-logging/2018-04-24-open-source-charts-2017/most-discussed.png)
+
+在 GitHub 的所有开源存储库中，没有比 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes/) 收到更多的评论。 [OpenShift](http://openshift.com/)， [CNCF 认证的 Kubernetes 发行版](https://www.cncf.io/announcement/2017/11/13/cloud-native-computing-foundation-launches-certified-kubernetes-program-32-conformant-distributions-platforms/) 排名第二。
+
+利用充足时间进行公开讨论来获取社区反馈和审查，有助于建立共享的基础架构并为云原生计算建立新标准。
+
+<!--
+## Most Reviewed on GitHub
+
+Successfully scaling an open source effort’s communications often leads to better coordination and higher-quality feature delivery. The Kubernetes project’s [Special Interest Group (SIG)](https://github.com/kubernetes/community/blob/master/sig-list.md) structure has helped it become GitHub’s second most reviewed project:
+
+
+
+Using SIGs to segment and standardize mechanisms for community participation helps channel more frequent reviews from better-qualified community members.
+
+When managed effectively, active community discussions indicate more than just a highly contentious codebase, or a project with an extensive list of unmet needs.
+--->
+## GitHub 上审阅最多的
+
+成功扩展开放源代码工作的通信通常会带来更好的协调和更高质量的功能交付。Kubernetes 项目的 [Special Interest Group（SIG）](https://github.com/kubernetes/community/blob/master/sig-list.md) 结构已使其成为 GitHub 审阅第二多的项目：
+
+！[审阅最多](/images/blog-logging/2018-04-24-open-source-charts-2017/most-reviews.png)
+
+使用 SIG 对社区参与机制进行细分和标准化有助于从资格更高的社区成员中获得更频繁的审阅。
+
+如果得到有效管理，活跃的社区讨论不仅表明代码库存在很大的争议，也可能表明项目包含大量未满足的需求。
+
+<!--
+Scaling a project’s capacity to handle issues and community interactions helps to expand the conversation. Meanwhile, large communities come with more diverse use cases and a larger array of support problems to manage. The Kubernetes [SIG organization structure](https://github.com/kubernetes/community#sigs) helps to address the challenges of complex communication at scale.
+
+SIG meetings provide focused opportunities for users, maintainers, and specialists from various disciplines to collaborate together in support of this community effort. These investments in organizing help create an environment where it’s easier to prioritize architecture discussion and planning over commit velocity; enabling the project to sustain this kind of scale.
+--->
+扩展项目处理问题和社区互动的能力有助于扩大交流。同时，大型社区具有更多不同的用例和更多的支持问题需要管理。Kubernetes [SIG 组织结构](https://github.com/kubernetes/community#sigs) 帮助应对大规模复杂通信的挑战。
+
+SIG 会议为不同学科的用户、维护者和专家提供了重点合作的机会，以共同协作来支持社区的工作。这些在组织上的投资有助于创建一个环境，在这样的环境中，可以更轻松地将架构讨论和规划的优先级排到提交速度前面，并使项目能够维持这种规模。
+
+<!--
+## Join the party!
+
+You may already be using solutions that are successfully managed and scaled on Kubernetes. For example, GitHub.com, which hosts Kubernetes’ upstream source code, [now runs on Kubernetes](https://githubengineering.com/kubernetes-at-github/) as well!
+
+Check out the [Kubernetes Contributors’ guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) for more information on how to get started as a contributor.
+
+You can also join the [weekly Kubernetes Community meeting](https://github.com/kubernetes/community/tree/master/communication#weekly-meeting) and consider [joining a SIG or two](https://github.com/kubernetes/community/blob/master/sig-list.md#master-sig-list).
+--->
+## 加入我们！
+
+您可能已经在 Kubernetes 上成功使用管理和扩展的解决方案。例如，托管 Kubernetes 上游源代码的 GitHub.com [现在也可以在 Kubernetes 上运行](https://githubengineering.com/kubernetes-at-github/) ！
+
+请查看 [Kubernetes 贡献者指南](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) ，以获取有关如何开始作为贡献者的更多信息。
+
+您也可以参加 [每周 Kubernetes 的社区会议](https://github.com/kubernetes/community/tree/master/communication#weekly-meeting) 并考虑 [加入一个或两个 SIG](https://github.com/kubernetes/community/blob/master/sig-list.md#master-sig-list)。
diff --git a/content/zh/blog/_posts/2018-07-10-coredns-ga.md b/content/zh/blog/_posts/2018-07-10-coredns-ga.md
new file mode 100644
index 0000000000..1fc8aa5249
--- /dev/null
+++ b/content/zh/blog/_posts/2018-07-10-coredns-ga.md
@@ -0,0 +1,307 @@
+---
+layout: blog
+title: "用于 Kubernetes 集群 DNS 的 CoreDNS GA 正式发布"
+date: 2018-07-10
+---
+<!--
+---
+layout: blog
+title: "CoreDNS GA for Kubernetes Cluster DNS"
+date: 2018-07-10
+---
+--->
+
+<!--
+**Author**: John Belamaric (Infoblox)
+
+**Editor’s note: this post is part of a [series of in-depth articles](https://kubernetes.io/blog/2018/06/27/kubernetes-1.11-release-announcement/) on what’s new in Kubernetes 1.11**
+--->
+**作者**：John Belamaric (Infoblox)
+
+**编者注：这篇文章是 [系列深度文章](https://kubernetes.io/blog/2018/06/27/kubernetes-1.11-release-announcement/) 中的一篇，介绍了 Kubernetes 1.11 新增的功能
+
+<!--
+## Introduction
+
+In Kubernetes 1.11, [CoreDNS](https://coredns.io) has reached General Availability (GA) for DNS-based service discovery, as an alternative to the kube-dns addon. This means that CoreDNS will be offered as an option in upcoming versions of the various installation tools. In fact, the kubeadm team chose to make it the default option starting with Kubernetes 1.11.
+--->
+## 介绍
+
+在 Kubernetes 1.11 中，[CoreDNS](https://coredns.io) 已经达到基于 DNS 服务发现的 General Availability (GA)，可以替代 kube-dns 插件。这意味着 CoreDNS 会作为即将发布的安装工具的选项之一上线。实际上，从 Kubernetes 1.11 开始，kubeadm 团队选择将它设为默认选项。
+
+<!--
+DNS-based service discovery has been part of Kubernetes for a long time with the kube-dns cluster addon. This has generally worked pretty well, but there have been some concerns around the reliability, flexibility and security of the implementation.
+
+CoreDNS is a general-purpose, authoritative DNS server that provides a backwards-compatible, but extensible, integration with Kubernetes. It resolves the issues seen with kube-dns, and offers a number of unique features that solve a wider variety of use cases.
+
+In this article, you will learn about the differences in the implementations of kube-dns and CoreDNS, and some of the helpful extensions offered by CoreDNS.
+--->
+很久以来， kube-dns 集群插件一直是 Kubernetes 的一部分，用来实现基于 DNS 的服务发现。
+通常，此插件运行平稳，但对于实现的可靠性、灵活性和安全性仍存在一些疑虑。
+
+CoreDNS 是通用的、权威的 DNS 服务器，提供与 Kubernetes 向后兼容但可扩展的集成。它解决了 kube-dns 遇到的问题，并提供了许多独特的功能，可以解决各种用例。
+
+在本文中，您将了解 kube-dns 和 CoreDNS 的实现有何差异，以及 CoreDNS 提供的一些非常有用的扩展。
+
+<!--
+## Implementation differences
+
+In kube-dns, several containers are used within a single pod: `kubedns`, `dnsmasq`, and `sidecar`. The `kubedns`
+container watches the Kubernetes API and serves DNS records based on the [Kubernetes DNS specification](https://github.com/kubernetes/dns/blob/master/docs/specification.md), `dnsmasq` provides caching and stub domain support, and `sidecar` provides metrics and health checks.
+--->
+## 实现差异
+
+在 kube-dns 中，一个 Pod 中使用多个 容器：`kubedns`、`dnsmasq`、和 `sidecar`。`kubedns` 容器监视 Kubernetes API 并根据 [Kubernetes DNS 规范](https://github.com/kubernetes/dns/blob/master/docs/specification.md) 提供 DNS 记录，`dnsmasq` 提供缓存和存根域支持，`sidecar` 提供指标和健康检查。
+
+<!--
+This setup leads to a few issues that have been seen over time. For one, security vulnerabilities in `dnsmasq` have led to the need
+for a security-patch release of Kubernetes in the past. Additionally, because `dnsmasq` handles the stub domains,
+but `kubedns` handles the External Services, you cannot use a stub domain in an external service, which is very
+limiting to that functionality (see [dns#131](https://github.com/kubernetes/dns/issues/131)).
+
+All of these functions are done in a single container in CoreDNS, which is running a process written in Go. The
+different plugins that are enabled replicate (and enhance) the functionality found in kube-dns.
+--->
+随着时间的推移，此设置会导致一些问题。一方面，以往 `dnsmasq` 中的安全漏洞需要通过发布 Kubernetes 的安全补丁来解决。但是，由于 `dnsmasq` 处理存根域，而 `kubedns` 处理外部服务，因此您不能在外部服务中使用存根域，导致这个功能具有局限性（请参阅 [dns#131](https://github.com/kubernetes/dns/issues/131)）。
+
+在 CoreDNS 中，所有这些功能都是在一个容器中完成的，该容器运行用 Go 编写的进程。所启用的不同插件可复制（并增强）在 kube-dns 中存在的功能。
+
+<!--
+## Configuring CoreDNS
+
+In kube-dns, you can [modify a ConfigMap](https://kubernetes.io/blog/2017/04/configuring-private-dns-zones-upstream-nameservers-kubernetes/) to change the behavior of your service discovery. This allows the addition of
+features such as serving stub domains, modifying upstream nameservers, and enabling federation.
+--->
+## 配置 CoreDNS
+
+在 kube-dns 中，您可以 [修改 ConfigMap](https://kubernetes.io/blog/2017/04/configuring-private-dns-zones-upstream-nameservers-kubernetes/) 来更改服务发现的行为。用户可以添加诸如为存根域提供服务、修改上游名称服务器以及启用联盟之类的功能。
+
+<!--
+In CoreDNS, you similarly can modify the ConfigMap for the CoreDNS [Corefile](https://coredns.io/2017/07/23/corefile-explained/) to change how service discovery
+works. This Corefile configuration offers many more options than you will find in kube-dns, since it is the
+primary configuration file that CoreDNS uses for configuration of all of its features, even those that are not
+Kubernetes related.
+
+When upgrading from kube-dns to CoreDNS using `kubeadm`, your existing ConfigMap will be used to generate the
+customized Corefile for you, including all of the configuration for stub domains, federation, and upstream nameservers. See [Using CoreDNS for Service Discovery](/docs/tasks/administer-cluster/coredns/) for more details.
+--->
+在 CoreDNS 中，您可以类似地修改 CoreDNS [Corefile](https://coredns.io/2017/07/23/corefile-explained/) 的 ConfigMap，以更改服务发现的工作方式。这种 Corefile 配置提供了比 kube-dns 中更多的选项，因为它是 CoreDNS 用于配置所有功能的主要配置文件，即使与 Kubernetes 不相关的功能也可以操作。
+
+使用 `kubeadm` 将 kube-dns 升级到 CoreDNS 时，现有的 ConfigMap 将被用来为您生成自定义的 Corefile，包括存根域、联盟和上游名称服务器的所有配置。更多详细信息，请参见
+[使用 CoreDNS 进行服务发现](/zh/docs/tasks/administer-cluster/coredns/)。
+
+<!--
+## Bug fixes and enhancements
+
+There are several open issues with kube-dns that are resolved in CoreDNS, either in default configuration or with some customized configurations.
+--->
+## 错误修复和增强
+
+在 CoreDNS 中解决了 kube-dn 的多个未解决问题，无论是默认配置还是某些自定义配置。
+
+<!--
+ * [dns#55 - Custom DNS entries for kube-dns](https://github.com/kubernetes/dns/issues/55) may be handled using the "fallthrough" mechanism in the [kubernetes plugin](https://coredns.io/plugins/kubernetes), using the [rewrite plugin](https://coredns.io/plugins/rewrite), or simply serving a subzone with a different plugin such as the [file plugin](https://coredns.io/plugins/file).
+
+ * [dns#116 - Only one A record set for headless service with pods having single hostname](https://github.com/kubernetes/dns/issues/116). This issue is fixed without any additional configuration.
+ * [dns#131 - externalName not using stubDomains settings](https://github.com/kubernetes/dns/issues/131). This issue is fixed without any additional configuration.
+ * [dns#167 - enable skyDNS round robin A/AAAA records](https://github.com/kubernetes/dns/issues/167). The equivalent functionality can be configured using the [load balance plugin](https://coredns.io/plugins/loadbalance).
+ * [dns#190 - kube-dns cannot run as non-root user](https://github.com/kubernetes/dns/issues/190). This issue is solved today by using a non-default image, but it will be made the default CoreDNS behavior in a future release.
+ * [dns#232 - fix pod hostname to be podname for dns srv records](https://github.com/kubernetes/dns/issues/232) is an enhancement that is supported through the "endpoint_pod_names" feature described below.
+--->
+ * [dns#55 - kube-dns 的自定义 DNS 条目](https://github.com/kubernetes/dns/issues/55) 可以使用 [kubernetes 插件](https://coredns.io/plugins/kubernetes) 中的 "fallthrough" 机制，使用 [rewrite 插件](https://coredns.io/plugins/rewrite)，或者分区使用不同的插件，例如 [file 插件](https://coredns.io/plugins/file)。
+
+ * [dns#116 - 对具有相同主机名的、提供无头服务服务的 Pod 仅设置了一个 A 记录](https://github.com/kubernetes/dns/issues/116)。无需任何其他配置即可解决此问题。
+ * [dns#131 - externalName 未使用 stubDomains 设置](https://github.com/kubernetes/dns/issues/131)。无需任何其他配置即可解决此问题。
+ * [dns#167 - 允许 skyDNS 为 A/AAAA 记录提供轮换](https://github.com/kubernetes/dns/issues/167)。可以使用 [负载均衡插件](https://coredns.io/plugins/loadbalance) 配置等效功能。
+ * [dns#190 - kube-dns 无法以非 root 用户身份运行](https://github.com/kubernetes/dns/issues/190)。今天，通过使用 non-default 镜像解决了此问题，但是在将来的版本中，它将成为默认的 CoreDNS 行为。
+ * [dns#232 - 在 dns srv 记录中修复 pod hostname 为 podname](https://github.com/kubernetes/dns/issues/232) 是通过下面提到的 "endpoint_pod_names" 功能进行支持的增强功能。
+
+
+<!--
+## Metrics
+
+The functional behavior of the default CoreDNS configuration is the same as kube-dns. However,
+one difference you need to be aware of is that the published metrics are not the same. In kube-dns,
+you get separate metrics for `dnsmasq` and `kubedns` (skydns). In CoreDNS there is a completely
+different set of metrics, since it is all a single process. You can find more details on these
+metrics on the CoreDNS [Prometheus plugin](https://coredns.io/plugins/metrics/) page.
+--->
+## 指标
+
+CoreDNS 默认配置的功能性行为与 kube-dns 相同。但是，你需要了解的差别之一是二者发布的指标是不同的。在 kube-dns 中，您将分别获得 `dnsmasq` 和 `kubedns`（skydns）的度量值。在 CoreDNS 中，存在一组完全不同的指标，因为它们在同一个进程中。您可以在 CoreDNS [Prometheus 插件](https://coredns.io/plugins/metrics/) 页面上找到有关这些指标的更多详细信息。
+
+<!--
+## Some special features
+
+The standard CoreDNS Kubernetes configuration is designed to be backwards compatible with the prior
+kube-dns behavior. But with some configuration changes, CoreDNS can allow you to modify how the
+DNS service discovery works in your cluster. A number of these features are intended to still be
+compliant with the [Kubernetes DNS specification](https://github.com/kubernetes/dns/blob/master/docs/specification.md);
+they enhance functionality but remain backward compatible. Since CoreDNS is not
+*only* made for Kubernetes, but is instead a general-purpose DNS server, there are many things you
+can do beyond that specification.
+--->
+## 一些特殊功能
+
+标准的 CoreDNS Kubernetes 配置旨在与以前的 kube-dns 在行为上向后兼容。但是，通过进行一些配置更改，CoreDNS 允许您修改 DNS 服务发现在群集中的工作方式。这些功能中的许多功能仍要符合 [Kubernetes DNS规范](https://github.com/kubernetes/dns/blob/master/docs/specification.md)；它们在增强了功能的同时保持向后兼容。由于 CoreDNS 并非 *仅* 用于 Kubernetes，而是通用的 DNS 服务器，因此您可以做很多超出该规范的事情。
+
+<!--
+### Pods verified mode
+
+In kube-dns, pod name records are "fake". That is, any "a-b-c-d.namespace.pod.cluster.local" query will
+return the IP address "a.b.c.d". In some cases, this can weaken the identity guarantees offered by TLS. So,
+CoreDNS offers a "pods verified" mode, which will only return the IP address if there is a pod in the
+specified namespace with that IP address.
+--->
+### Pod 验证模式
+
+在 kube-dns 中，Pod 名称记录是 "伪造的"。也就是说，任何 "a-b-c-d.namespace.pod.cluster.local" 查询都将返回 IP 地址 "a.b.c.d"。在某些情况下，这可能会削弱 TLS 提供的身份确认。因此，CoreDNS 提供了一种 "Pod 验证" 的模式，该模式仅在指定名称空间中存在具有该 IP 地址的 Pod 时才返回 IP 地址。
+
+<!--
+### Endpoint names based on pod names
+
+In kube-dns, when using a headless service, you can use an SRV request to get a list of
+all endpoints for the service:
+--->
+### 基于 Pod 名称的端点名称
+
+在 kube-dns 中，使用无头服务时，可以使用 SRV 请求获取该服务的所有端点的列表：
+
+```
+dnstools# host -t srv headless
+headless.default.svc.cluster.local has SRV record 10 33 0 6234396237313665.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 10 33 0 6662363165353239.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 10 33 0 6338633437303230.headless.default.svc.cluster.local.
+dnstools#
+```
+
+<!--
+However, the endpoint DNS names are (for practical purposes) random. In CoreDNS, by default, you get endpoint
+DNS names based upon the endpoint IP address:
+--->
+但是，端点 DNS 名称（出于实际目的）是随机的。在 CoreDNS 中，默认情况下，您所获得的端点 DNS 名称是基于端点 IP 地址生成的：
+
+```
+dnstools# host -t srv headless
+headless.default.svc.cluster.local has SRV record 0 25 443 172-17-0-14.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 0 25 443 172-17-0-18.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 0 25 443 172-17-0-4.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 0 25 443 172-17-0-9.headless.default.svc.cluster.local.
+```
+
+<!--
+For some applications, it is desirable to have the pod name for this, rather than the pod IP
+address (see for example [kubernetes#47992](https://github.com/kubernetes/kubernetes/issues/47992) and [coredns#1190](https://github.com/coredns/coredns/pull/1190)). To enable this in CoreDNS, you specify the "endpoint_pod_names" option in your Corefile, which results in this:
+--->
+对于某些应用程序，你会希望在这里使用 Pod 名称，而不是 Pod IP 地址（例如，参见 [kubernetes#47992](https://github.com/kubernetes/kubernetes/issues/47992) 和 [coredns#1190](https://github.com/coredns/coredns/pull/1190)）。要在 CoreDNS 中启用此功能，请在 Corefile 中指定 "endpoint_pod_names" 选项，结果如下：
+
+```
+dnstools# host -t srv headless
+headless.default.svc.cluster.local has SRV record 0 25 443 headless-65bb4c479f-qv84p.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 0 25 443 headless-65bb4c479f-zc8lx.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 0 25 443 headless-65bb4c479f-q7lf2.headless.default.svc.cluster.local.
+headless.default.svc.cluster.local has SRV record 0 25 443 headless-65bb4c479f-566rt.headless.default.svc.cluster.local.
+```
+
+<!--
+### Autopath
+
+CoreDNS also has a special feature to improve latency in DNS requests for external names. In Kubernetes, the
+DNS search path for pods specifies a long list of suffixes. This enables the use of short names when requesting
+services in the cluster - for example, "headless" above, rather than "headless.default.svc.cluster.local". However,
+when requesting an external name - "infoblox.com", for example - several invalid DNS queries are made by the client,
+requiring a roundtrip from the client to kube-dns each time (actually to `dnsmasq` and then to `kubedns`, since [negative caching is disabled](https://github.com/kubernetes/dns/issues/121)):
+--->
+### 自动路径
+
+CoreDNS 还具有一项特殊功能，可以改善 DNS 中外部名称请求的延迟。在 Kubernetes 中，Pod 的 DNS 搜索路径指定了一长串后缀。这一特点使得你可以针对集群中服务使用短名称 - 例如，上面的 "headless"，而不是 "headless.default.svc.cluster.local"。但是，当请求一个外部名称（例如 "infoblox.com"）时，客户端会进行几个无效的 DNS 查询，每次都需要从客户端到 kube-dns 往返（实际上是到 `dnsmasq`，然后到 `kubedns`），因为 [禁用了负缓存](https://github.com/kubernetes/dns/issues/121)）
+
+ * infoblox.com.default.svc.cluster.local -> NXDOMAIN
+ * infoblox.com.svc.cluster.local -> NXDOMAIN
+ * infoblox.com.cluster.local -> NXDOMAIN
+ * infoblox.com.your-internal-domain.com -> NXDOMAIN
+<!--
+ * infoblox.com -> returns a valid record
+--->
+ * infoblox.com -> 返回有效记录
+
+<!--
+In CoreDNS, an optional feature called [autopath](https://coredns.io/plugins/autopath) can be enabled that will cause this search path to be followed
+*in the server*. That is, CoreDNS will figure out from the source IP address which namespace the client pod is in,
+and it will walk this search list until it gets a valid answer. Since the first 3 of these are resolved internally
+within CoreDNS itself, it cuts out all of the back and forth between the client and server, reducing latency.
+--->
+在 CoreDNS 中，可以启用 [autopath](https://coredns.io/plugins/autopath) 的可选功能，该功能使搜索路径在 *服务器端* 遍历。也就是说，CoreDNS 将基于源 IP 地址判断客户端 Pod 所在的命名空间，并且遍历此搜索列表，直到获得有效答案为止。由于其中的前三个是在 CoreDNS 本身内部解决的，因此它消除了客户端和服务器之间所有的来回通信，从而减少了延迟。
+
+<!--
+### A few other Kubernetes specific features
+
+In CoreDNS, you can use standard DNS zone transfer to export the entire DNS record set. This is useful for
+debugging your services as well as importing the cluster zone into other DNS servers.
+
+You can also filter by namespaces or a label selector. This can allow you to run specific CoreDNS instances that will only server records that match the filters, exposing only a limited set of your services via DNS.
+--->
+### 其他一些特定于 Kubernetes 的功能
+
+在 CoreDNS 中，您可以使用标准 DNS 区域传输来导出整个 DNS 记录集。这对于调试服务以及将集群区导入其他 DNS 服务器很有用。
+
+您还可以按名称空间或标签选择器进行过滤。这样，您可以运行特定的 CoreDNS 实例，该实例仅服务与过滤器匹配的记录，从而通过 DNS 公开受限的服务集。
+
+<!--
+## Extensibility
+
+In addition to the features described above, CoreDNS is easily extended. It is possible to build custom versions
+of CoreDNS that include your own features. For example, this ability has been used to extend CoreDNS to do recursive resolution
+with the [unbound plugin](https://coredns.io/explugins/unbound), to server records directly from a database with the [pdsql plugin](https://coredns.io/explugins/pdsql), and to allow multiple CoreDNS instances to share a common level 2 cache with the [redisc plugin](https://coredns.io/explugins/redisc).
+
+Many other interesting extensions have been added, which you will find on the [External Plugins](https://coredns.io/explugins/) page of the CoreDNS site. One that is really interesting for Kubernetes and Istio users is the [kubernetai plugin](https://coredns.io/explugins/kubernetai), which allows a single CoreDNS instance to connect to multiple Kubernetes clusters and provide service discovery across all of them.
+--->
+## 可扩展性
+
+除了上述功能之外，CoreDNS 还可轻松扩展，构建包含您独有的功能的自定义版本的 CoreDNS。例如，这一能力已被用于扩展 CoreDNS 来使用 [unbound 插件](https://coredns.io/explugins/unbound) 进行递归解析、使用 [pdsql 插件](https://coredns.io/explugins/pdsql) 直接从数据库提供记录，以及使用 [redisc 插件](https://coredns.io/explugins/redisc) 与多个 CoreDNS 实例共享一个公共的 2 级缓存。
+
+已添加的还有许多其他有趣的扩展，您可以在 CoreDNS 站点的 [外部插件](https://coredns.io/explugins/) 页面上找到这些扩展。Kubernetes 和 Istio 用户真正感兴趣的是 [kubernetai 插件](https://coredns.io/explugins/kubernetai)，它允许单个 CoreDNS 实例连接到多个 Kubernetes 集群并在所有集群中提供服务发现 。
+
+<!--
+## What's Next?
+
+CoreDNS is an independent project, and as such is developing many features that are not directly
+related to Kubernetes. However, a number of these will have applications within Kubernetes. For example,
+the upcoming integration with policy engines will allow CoreDNS to make intelligent choices about which endpoint
+to return when a headless service is requested. This could be used to route traffic to a local pod, or
+to a more responsive pod. Many other features are in development, and of course as an open source project, we welcome you to suggest and contribute your own features!
+
+The features and differences described above are a few examples. There is much more you can do with CoreDNS.
+You can find out more on the [CoreDNS Blog](https://coredns.io/blog).
+--->
+## 下一步工作
+
+CoreDNS 是一个独立的项目，许多与 Kubernetes 不直接相关的功能正在开发中。但是，其中许多功能将在 Kubernetes 中具有对应的应用。例如，与策略引擎完成集成后，当请求无头服务时，CoreDNS 能够智能地选择返回哪个端点。这可用于将流量分流到到本地 Pod 或响应更快的 Pod。更多的其他功能正在开发中，当然作为一个开源项目，我们欢迎您提出建议并贡献自己的功能特性！
+
+上述特征和差异是几个示例。CoreDNS 还可以做更多的事情。您可以在 [CoreDNS 博客](https://coredns.io/blog) 上找到更多信息。
+
+<!--
+### Get involved with CoreDNS
+
+CoreDNS is an incubated [CNCF](https:://cncf.io) project.
+
+We're most active on Slack (and GitHub):
+--->
+### 参与 CoreDNS
+
+CoreDNS 是一个 [CNCF](https:://cncf.io) 孵化项目。
+
+我们在 Slack（和 GitHub）上最活跃：
+
+- Slack: #coredns on <https://slack.cncf.io>
+- GitHub: <https://github.com/coredns/coredns>
+
+<!--
+More resources can be found:
+--->
+更多资源请浏览：
+
+- Website: <https://coredns.io>
+- Blog: <https://blog.coredns.io>
+- Twitter: [@corednsio](https://twitter.com/corednsio)
+- Mailing list/group: <coredns-discuss@googlegroups.com>
diff --git a/content/zh/blog/_posts/2019-03-07-raw-block-volume-support-to-beta.md b/content/zh/blog/_posts/2019-03-07-raw-block-volume-support-to-beta.md
new file mode 100644
index 0000000000..3ac5bc89c4
--- /dev/null
+++ b/content/zh/blog/_posts/2019-03-07-raw-block-volume-support-to-beta.md
@@ -0,0 +1,219 @@
+---
+title: Raw Block Volume 支持进入 Beta
+date: 2019-03-07
+---
+<!--
+---
+title: Raw Block Volume support to Beta
+date: 2019-03-07
+---
+--->
+
+<!--
+**Authors:**
+Ben Swartzlander (NetApp), Saad Ali (Google)
+
+Kubernetes v1.13 moves raw block volume support to beta. This feature allows persistent volumes to be exposed inside containers as a block device instead of as a mounted file system.
+--->
+**作者：**
+Ben Swartzlander (NetApp), Saad Ali (Google)
+
+Kubernetes v1.13 中对原生数据块卷（Raw Block Volume）的支持进入 Beta 阶段。此功能允许将持久卷作为块设备而不是作为已挂载的文件系统暴露在容器内部。
+
+<!--
+## What are block devices?
+
+Block devices enable random access to data in fixed-size blocks. Hard drives, SSDs, and CD-ROMs drives are all examples of block devices.
+
+Typically persistent storage is implemented in a layered maner with a file system (like ext4) on top of a block device (like a spinning disk or SSD). Applications then read and write files instead of operating on blocks. The operating systems take care of reading and writing files, using the specified filesystem, to the underlying device as blocks.
+
+It's worth noting that while whole disks are block devices, so are disk partitions, and so are LUNs from a storage area network (SAN) device.
+--->
+## 什么是块设备？
+
+块设备允许对固定大小的块中的数据进行随机访问。硬盘驱动器、SSD 和 CD-ROM 驱动器都是块设备的例子。
+
+通常，持久性性存储是在通过在块设备（例如磁盘或 SSD）之上构造文件系统（例如 ext4）的分层方式实现的。这样应用程序就可以读写文件而不是操作数据块进。操作系统负责使用指定的文件系统将文件读写转换为对底层设备的数据块读写。
+
+值得注意的是，整个磁盘都是块设备，磁盘分区也是如此，存储区域网络（SAN）设备中的 LUN 也是一样的。
+
+<!--
+## Why add raw block volumes to kubernetes?
+
+There are some specialized applications that require direct access to a block device because, for example, the file system layer introduces unneeded overhead. The most common case is databases, which prefer to organize their data directly on the underlying storage. Raw block devices are also commonly used by any software which itself implements some kind of storage service (software defined storage systems).
+--->
+## 为什么要将 raw block volume 添加到 kubernetes？
+
+有些特殊的应用程序需要直接访问块设备，原因例如，文件系统层会引入不必要的开销。最常见的情况是数据库，通常会直接在底层存储上组织数据。原生的块设备（Raw Block Devices）还通常由能自己实现某种存储服务的软件（软件定义的存储系统）使用。
+
+<!--
+From a programmer's perspective, a block device is a very large array of bytes, usually with some minimum granularity for reads and writes, often 512 bytes, but frequently 4K or larger.
+
+As it becomes more common to run database software and storage infrastructure software inside of Kubernetes, the need for raw block device support in Kubernetes becomes more important.
+--->
+从程序员的角度来看，块设备是一个非常大的字节数组，具有某种最小读写粒度，通常为 512 个字节，大部分情况为 4K 或更大。
+
+随着在 Kubernetes 中运行数据库软件和存储基础架构软件变得越来越普遍，在 Kubernetes 中支持原生块设备的需求变得越来越重要。
+
+<!--
+## Which volume plugins support raw blocks?
+
+As of the publishing of this blog, the following in-tree volumes types support raw blocks:
+--->
+## 哪些卷插件支持 raw block？
+
+在发布此博客时，以下 in-tree 卷类型支持原生块设备：
+
+- AWS EBS
+- Azure Disk
+- Cinder
+- Fibre Channel
+- GCE PD
+- iSCSI
+- Local volumes
+- RBD (Ceph)
+- Vsphere
+
+<!--
+Out-of-tree [CSI volume drivers](https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/) may also support raw block volumes. Kubernetes CSI support for raw block volumes is currently alpha. See documentation [here](https://kubernetes-csi.github.io/docs/raw-block.html).
+--->
+Out-of-tree [CSI 卷驱动程序](https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/) 可能也支持原生数据块卷。Kubernetes CSI 对原生数据块卷的支持目前为 alpha 阶段。参考 [这篇](https://kubernetes-csi.github.io/docs/raw-block.html) 文档。
+
+<!--
+## Kubernetes raw block volume API
+
+Raw block volumes share a lot in common with ordinary volumes. Both are requested by creating `PersistentVolumeClaim` objects which bind to `PersistentVolume` objects, and are attached to Pods in Kubernetes by including them in the volumes array of the `PodSpec`.
+
+There are 2 important differences however. First, to request a raw block `PersistentVolumeClaim`, you must set `volumeMode = "Block"` in the `PersistentVolumeClaimSpec`. Leaving `volumeMode` blank is the same as specifying `volumeMode = "Filesystem"` which results in the traditional behavior. `PersistentVolumes` also have a `volumeMode` field in their `PersistentVolumeSpec`, and `"Block"` type PVCs can only bind to `"Block"` type PVs and `"Filesystem"` PVCs can only bind to `"Filesystem"` PVs.
+--->
+## Kubernetes raw block volume 的 API
+
+原生数据块卷与普通存储卷有很多共同点。两者都通过创建与 `PersistentVolume` 对象绑定的 `PersistentVolumeClaim` 对象发起请求，并通过将它们加入到 `PodSpec` 的 volumes 数组中来连接到 Kubernetes 中的 Pod。
+
+但是有两个重要的区别。首先，要请求原生数据块设备的 `PersistentVolumeClaim` 必须在 `PersistentVolumeClaimSpec` 中设置 `volumeMode = "Block"`。`volumeMode` 为空时与传统设置方式中的指定 `volumeMode = "Filesystem"` 是一样的。`PersistentVolumes` 在其 `PersistentVolumeSpec` 中也有一个 `volumeMode` 字段，`"Block"` 类型的 PVC 只能绑定到 `"Block"` 类型的 PV 上，而`"Filesystem"` 类型的 PVC 只能绑定到 `"Filesystem"` PV 上。
+
+<!--
+Secondly, when using a raw block volume in your Pods, you must specify a `VolumeDevice` in the Container portion of the `PodSpec` rather than a `VolumeMount`. `VolumeDevices` have `devicePaths` instead of `mountPaths`, and inside the container, applications will see a device at that path instead of a mounted file system.
+
+Applications open, read, and write to the device node inside the container just like they would interact with any block device on a system in a non-containerized or virtualized context.
+--->
+其次，在 Pod 中使用原生数据块卷时，必须在 `PodSpec` 的 Container 部分指定一个 `VolumeDevice`，而不是 `VolumeMount`。`VolumeDevices` 具备 `devicePaths` 而不是 `mountPaths`，在容器中，应用程序将看到位于该路径的设备，而不是挂载了的文件系统。
+
+应用程序打开、读取和写入容器内的设备节点，就像它们在非容器化或虚拟环境中与系统上的任何块设备交互一样。
+
+<!--
+## Creating a new raw block PVC
+
+First, ensure that the provisioner associated with the storage class you choose is one that support raw blocks. Then create the PVC.
+--->
+## 创建一个新的原生块设备 PVC
+
+首先，请确保与您选择的存储类关联的驱动支持原生块设备。然后创建 PVC。
+
+```
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+ name: my-pvc
+spec:
+ accessModes:
+ - ReadWriteMany
+ volumeMode: Block
+ storageClassName: my-sc
+ resources:
+ requests:
+ storage: 1Gi
+```
+
+<!--
+## Using a raw block PVC
+
+When you use the PVC in a pod definition, you get to choose the device path for the block device rather than the mount path for the file system.
+--->
+## 使用原生块 PVC
+
+在 Pod 定义中使用 PVC 时，需要选择块设备的设备路径，而不是文件系统的安装路径。
+
+```
+apiVersion: v1
+kind: Pod
+metadata:
+ name: my-pod
+spec:
+ containers:
+ - name: my-container
+ image: busybox
+ command:
+ - sleep
+ - “3600”
+ volumeDevices:
+ - devicePath: /dev/block
+ name: my-volume
+ imagePullPolicy: IfNotPresent
+ volumes:
+ - name: my-volume
+ persistentVolumeClaim:
+ claimName: my-pvc
+```
+
+<!--
+## As a storage vendor, how do I add support for raw block devices to my CSI plugin?
+
+Raw block support for CSI plugins is still alpha, but support can be added today. The [CSI specification](https://github.com/container-storage-interface/spec/blob/master/spec.md) details how to handle requests for volume that have the `BlockVolume` capability instead of the `MountVolume` capability. CSI plugins can support both kinds of volumes, or one or the other. For more details see [documentation here](https://kubernetes-csi.github.io/docs/raw-block.html).
+--->
+## 作为存储供应商，我如何在 CSI 插件中添加对原生块设备的支持？
+
+CSI 插件的原生块支持仍然是 alpha 版本，但是现在可以改进了。[CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md) 详细说明了如何处理具有 `BlockVolume` 能力而不是 `MountVolume` 能力的卷的请求。CSI 插件可以支持两种类型的卷，也可以支持其中一种或另一种。更多详细信息，请查看 [这个文档](https://kubernetes-csi.github.io/docs/raw-block.html)。
+
+
+<!--
+## Issues/gotchas
+
+Because block devices are actually devices, it’s possible to do low-level actions on them from inside containers that wouldn’t be possible with file system volumes. For example, block devices that are actually SCSI disks support sending SCSI commands to the device using Linux ioctls.
+--->
+## 问题/陷阱
+
+由于块设备实质上还是设备，因此可以从容器内部对其进行底层操作，而文件系统的卷则无法执行这些操作。例如，实际上是块设备的 SCSI 磁盘支持使用 Linux ioctl 向设备发送 SCSI 命令。
+
+<!--
+By default, Linux won’t allow containers to send SCSI commands to disks from inside containers though. In order to do so, you must grant the `SYS_RAWIO` capability to the container security context to allow this. See documentation [here](/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container).
+
+Also, while Kubernetes is guaranteed to deliver a block device to the container, there’s no guarantee that it’s actually a SCSI disk or any other kind of disk for that matter. The user must either ensure that the desired disk type is used with his pods, or only deploy applications that can handle a variety of block device types.
+--->
+默认情况下，Linux 不允许容器将 SCSI 命令从容器内部发送到磁盘。为此，必须向容器安全层级认证 `SYS_RAWIO` 功能实现这种行为。请参阅 [这篇](/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container) 文档。
+
+另外，尽管 Kubernetes 保证可以将块设备交付到容器中，但不能保证它实际上是 SCSI 磁盘或任何其他类型的磁盘。用户必须确保所需的磁盘类型与 Pod 一起使用，或只部署可以处理各种块设备类型的应用程序。
+
+<!--
+## How can I learn more?
+
+Check out additional documentation on the snapshot feature here: [Raw Block Volume Support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)
+
+How do I get involved?
+
+Join the Kubernetes storage SIG and the CSI community and help us add more great features and improve existing ones like raw block storage!
+--->
+## 如何学习更多？
+
+在此处查看有关 snapshot 功能的其他文档：[Raw Block Volume 支持](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)
+
+如何参与进来？
+
+加入 Kubernetes 存储 SIG 和 CSI 社区，帮助我们添加更多出色的功能并改进现有功能，就像 raw block 存储一样！
+
+https://github.com/kubernetes/community/tree/master/sig-storage
+https://github.com/container-storage-interface/community/blob/master/README.md
+
+<!--
+Special thanks to all the contributors who helped add block volume support to Kubernetes including:
+--->
+特别感谢所有为 Kubernetes 增加 block volume 支持的贡献者，包括：
+
+- Ben Swartzlander (https://github.com/bswartz)
+- Brad Childs (https://github.com/childsb)
+- Erin Boyd (https://github.com/erinboyd)
+- Masaki Kimura (https://github.com/mkimuram)
+- Matthew Wong (https://github.com/wongma7)
+- Michelle Au (https://github.com/msau42)
+- Mitsuhiro Tanino (https://github.com/mtanino)
+- Saad Ali (https://github.com/saad-ali)
diff --git a/content/zh/docs/concepts/architecture/_index.md b/content/zh/docs/concepts/architecture/_index.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/concepts/architecture/cloud-controller.md b/content/zh/docs/concepts/architecture/cloud-controller.md
index 8e1ab7c05f..5253b6cc54 100644
--- a/content/zh/docs/concepts/architecture/cloud-controller.md
+++ b/content/zh/docs/concepts/architecture/cloud-controller.md
@@ -265,7 +265,7 @@ The implementation of the four shared controllers highlighted above, and some sc
For more information about developing plugins, see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
-->
-有关开发插件的更多信息，请参阅[开发云控制器管理器](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)。
+有关开发插件的更多信息，请参阅[开发云控制器管理器](/zh/docs/tasks/administer-cluster/developing-cloud-controller-manager/)。
<!--
## Authorization
@@ -494,7 +494,7 @@ Complete instructions for configuring and running the CCM are provided
[here](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager).
-->
-[这里](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)提供了有关配置和运行 CCM 的完整说明。
+[这里](/zh/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)提供了有关配置和运行 CCM 的完整说明。
diff --git a/content/zh/docs/concepts/architecture/control-plane-node-communication.md b/content/zh/docs/concepts/architecture/control-plane-node-communication.md
index 23ae4e3919..8dd4d9c7b5 100644
--- a/content/zh/docs/concepts/architecture/control-plane-node-communication.md
+++ b/content/zh/docs/concepts/architecture/control-plane-node-communication.md
@@ -32,10 +32,10 @@ One or more forms of [authorization](/docs/reference/access-authn-authz/authoriz
Kubernetes 采用的是中心辐射型（Hub-and-Spoke）API 模式。
所有从集群（或所运行的 Pods）发出的 API 调用都终止于 apiserver（其它控制面组件都没有被设计为可暴露远程服务）。
apiserver 被配置为在一个安全的 HTTPS 端口（443）上监听远程连接请求，
-并启用一种或多种形式的客户端[身份认证](/zh/docs/reference/access-authn-authz/authentication/)机制。
+并启用一种或多种形式的客户端[身份认证](/docs/reference/access-authn-authz/authentication/)机制。
一种或多种客户端[鉴权机制](/zh/docs/reference/access-authn-authz/authorization/)应该被启用，
-特别是在允许使用[匿名请求](/zh/docs/reference/access-authn-autha/authentication/#anonymous-requests)
-或[服务账号令牌](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。
+特别是在允许使用[匿名请求](/docs/reference/access-authn-authz/authentication/#anonymous-requests)
+或[服务账号令牌](/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。
<!--
Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. For example, on a default GKE deployment, the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates.
@@ -168,5 +168,5 @@ Konnectivity 服务包含两个部分：Konnectivity 服务器和 Konnectivity
控制面网络和节点网络中。Konnectivity 代理建立并维持到 Konnectivity 服务器的网络连接。
启用 Konnectivity 服务之后，所有控制面到节点的通信都通过这些连接传输。
-请浏览 [Konnectivity 服务任务](/zh/docs/tasks/extend-kubernetes/setup-konnectivity/)
+请浏览 [Konnectivity 服务任务](/docs/tasks/extend-kubernetes/setup-konnectivity/)
在你的集群中配置 Konnectivity 服务。
diff --git a/content/zh/docs/concepts/architecture/nodes.md b/content/zh/docs/concepts/architecture/nodes.md
index ac6d1f3e95..00e221aec1 100644
--- a/content/zh/docs/concepts/architecture/nodes.md
+++ b/content/zh/docs/concepts/architecture/nodes.md
@@ -252,7 +252,7 @@ kubectl describe node <节点名称>
The usage of these fields varies depending on your cloud provider or bare metal configuration.
-->
-### 地址 {#addresses}
+### 地址 {#addresses}
这些字段的用法取决于你的云服务商或者物理机配置。
diff --git a/content/zh/docs/concepts/cluster-administration/_index.md b/content/zh/docs/concepts/cluster-administration/_index.md
index f0525696c3..fd60a3457f 100644
--- a/content/zh/docs/concepts/cluster-administration/_index.md
+++ b/content/zh/docs/concepts/cluster-administration/_index.md
@@ -103,7 +103,7 @@ Before choosing a guide, here are some considerations:
* [证书](/zh/docs/concepts/cluster-administration/certificates/)节描述了使用不同的工具链生成证书的步骤。
* [Kubernetes 容器环境](/zh/docs/concepts/containers/container-environment/)描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。
* [控制到 Kubernetes API 的访问](/zh/docs/reference/access-authn-authz/controlling-access/)描述了如何为用户和 service accounts 建立权限许可。
-* [认证](/zh/docs/reference/access-authn-authz/authentication/)节阐述了 Kubernetes 中的身份认证功能，包括许多认证选项。
+* [认证](/docs/reference/access-authn-authz/authentication/)节阐述了 Kubernetes 中的身份认证功能，包括许多认证选项。
* [鉴权](/zh/docs/reference/access-authn-authz/authorization/)从认证中分离出来，用于控制如何处理 HTTP 请求。
* [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers) 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。
* [在 Kubernetes 集群中使用 Sysctls](/zh/docs/tasks/administer-cluster/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。
diff --git a/content/zh/docs/concepts/cluster-administration/logging.md b/content/zh/docs/concepts/cluster-administration/logging.md
old mode 100755
new mode 100644
index e0a47b8c84..ad44bbc5cb
--- a/content/zh/docs/concepts/cluster-administration/logging.md
+++ b/content/zh/docs/concepts/cluster-administration/logging.md
@@ -274,7 +274,7 @@ Using a node-level logging agent is the most common and encouraged approach for
Kubernetes doesn't specify a logging agent, but two optional logging agents are packaged with the Kubernetes release: [Stackdriver Logging](/docs/user-guide/logging/stackdriver) for use with Google Cloud Platform, and [Elasticsearch](/docs/user-guide/logging/elasticsearch). You can find more information and instructions in the dedicated documents. Both use [fluentd](http://www.fluentd.org/) with custom configuration as an agent on the node.
-->
Kubernetes 并不指定日志代理，但是有两个可选的日志代理与 Kubernetes 发行版一起发布。
-[Stackdriver 日志](/zh/docs/tasks/debug-application-cluster/logging-stackdriver/)
+[Stackdriver 日志](/docs/tasks/debug-application-cluster/logging-stackdriver/)
适用于 Google Cloud Platform，和
[Elasticsearch](/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/)。
你可以在专门的文档中找到更多的信息和说明。
@@ -447,7 +447,7 @@ which uses fluentd as a logging agent. Here are two configuration files that
you can use to implement this approach. The first file contains
a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to configure fluentd.
-->
-例如，你可以使用 [Stackdriver](/zh/docs/tasks/debug-application-cluster/logging-stackdriver/)，
+例如，你可以使用 [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/)，
它使用 fluentd 作为日志记录代理。
以下是两个可用于实现此方法的配置文件。
第一个文件包含配置 fluentd 的
diff --git a/content/zh/docs/concepts/cluster-administration/manage-deployment.md b/content/zh/docs/concepts/cluster-administration/manage-deployment.md
index cc2224db49..55038e290d 100644
--- a/content/zh/docs/concepts/cluster-administration/manage-deployment.md
+++ b/content/zh/docs/concepts/cluster-administration/manage-deployment.md
@@ -531,7 +531,7 @@ For more information, please see [kubectl scale](/docs/reference/generated/kubec
Sometimes it's necessary to make narrow, non-disruptive updates to resources you've created.
-->
-## 就地更新资源
+## 就地更新资源 {#in-place-updates-of-resources}
有时，有必要对你所创建的资源进行小范围、无干扰地更新。
diff --git a/content/zh/docs/concepts/cluster-administration/monitoring.md b/content/zh/docs/concepts/cluster-administration/monitoring.md
index afd8d12b64..a7e8e5c3c8 100644
--- a/content/zh/docs/concepts/cluster-administration/monitoring.md
+++ b/content/zh/docs/concepts/cluster-administration/monitoring.md
@@ -219,6 +219,6 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
* 了解有关 [Prometheus 指标相关的文本格式](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)
* 查看 [Kubernetes 稳定版指标](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)列表
-* 了解有关 [Kubernetes 指标弃用策略](/zh/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior )
+* 了解有关 [Kubernetes 指标弃用策略](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior )
diff --git a/content/zh/docs/concepts/configuration/secret.md b/content/zh/docs/concepts/configuration/secret.md
index 47b0e983ff..44ab02eae1 100644
--- a/content/zh/docs/concepts/configuration/secret.md
+++ b/content/zh/docs/concepts/configuration/secret.md
@@ -473,7 +473,7 @@ you can create the Secret on the API server with `kubectl apply`.
-->
#### 从生成器创建 Secret
-Kubectl 从 1.14 版本开始支持[使用 Kustomize 管理对象](/zh/docs/tasks/manage-kubernetes-objects/kustomization/)。
+Kubectl 从 1.14 版本开始支持[使用 Kustomize 管理对象](/docs/tasks/manage-kubernetes-objects/kustomization/)。
Kustomize 提供资源生成器创建 Secret 和 ConfigMaps。
Kustomize 生成器要在当前目录内的 `kustomization.yaml` 中指定。
生成 Secret 之后，使用 `kubectl apply` 在 API 服务器上创建对象。
diff --git a/content/zh/docs/concepts/containers/images.md b/content/zh/docs/concepts/containers/images.md
index d47a9c21d6..946c74ce77 100644
--- a/content/zh/docs/concepts/containers/images.md
+++ b/content/zh/docs/concepts/containers/images.md
@@ -89,34 +89,34 @@ Instead, specify a meaningful tag such as `v1.42.0`.
<!--
## Updating Images
-The default pull policy is `IfNotPresent` which causes the Kubelet to skip
+The default pull policy is `IfNotPresent` which causes the
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} to skip
pulling an image if it already exists. If you would like to always force a pull,
you can do one of the following:
--->
-## 更新镜像 {#updating-images}
-默认的镜像拉取策略是 `IfNotPresent`：在镜像已经存在的情况下，`kubelet` 将不再去拉取镜像。
-如果希望强制总是拉取镜像，你可以执行以下操作之一：
-
-<!--
- set the `imagePullPolicy` of the container to `Always`.
- omit the `imagePullPolicy` and use `:latest` as the tag for the image to use.
- omit the `imagePullPolicy` and the tag for the image to use.
- enable the [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) admission controller.
+
+When `imagePullPolicy` is defined without a specific value, it is also set to `Always`.
-->
+## 更新镜像 {#updating-images}
+
+默认的镜像拉取策略是 `IfNotPresent`：在镜像已经存在的情况下，
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} 将不再去拉取镜像。
+如果希望强制总是拉取镜像，你可以执行以下操作之一：
+
- 设置容器的 `imagePullPolicy` 为 `Always`。
- 省略 `imagePullPolicy`，并使用 `:latest` 作为要使用的镜像的标签。
- 省略 `imagePullPolicy` 和要使用的镜像标签。
- 启用 [AlwaysPullImages](/zh/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)
准入控制器（Admission Controller）。
-<!--
-When `imagePullPolicy` is defined without a specific value, it is also set to `Always`.
--->
如果 `imagePullPolicy` 未被定义为特定的值，也会被设置为 `Always`。
<!--
-## Building Multi-architecture Images with Manifests
+## Multi-architecture Images with Manifests
As well as providing binary images, a container registry can also serve a [container image manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md). A manifest can reference image manifests for architecture-specific versions of an container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using.
@@ -139,27 +139,27 @@ YAML 文件也能兼容。
<!--
## Using a Private Registry
-Private registries may require keys to read images from them.
+Private registries may require keys to read images from them.
Credentials can be provided in several ways:
-->
-## 使用私有仓库 {#using-a-private-registry}
+## 使用私有仓库 {#using-a-private-registry}
从私有仓库读取镜像时可能需要密钥。
-凭据信息可以用以下方式提供:
+凭证可以用以下方式提供:
<!--
-- Configuring Nodes to Authenticate to a Private Registry
- - all pods can read any configured private registries
- - requires node configuration by cluster administrator
-- Pre-pulled Images
- - all pods can use any images cached on a node
- - requires root access to all nodes to setup
-- Specifying ImagePullSecrets on a Pod
- - only pods which provide own keys can access the private registry
-- Vendor-specific or local extensions
- - if you're using a custom node configuration, you (or your cloud
- provider) can implement your mechanism for authenticating the node
- to the container registry.
+ - Configuring Nodes to Authenticate to a Private Registry
+ - all pods can read any configured private registries
+ - requires node configuration by cluster administrator
+ - Pre-pulled Images
+ - all pods can use any images cached on a node
+ - requires root access to all nodes to setup
+ - Specifying ImagePullSecrets on a Pod
+ - only pods which provide own keys can access the private registry
+ - Vendor-specific or local extensions
+ - if you're using a custom node configuration, you (or your cloud
+ provider) can implement your mechanism for authenticating the node
+ to the container registry.
-->
- 配置节点向私有仓库进行身份验证
- 所有 Pod 均可读取任何已配置的私有仓库
@@ -174,9 +174,9 @@ Credentials can be provided in several ways:
向容器仓库认证的机制
<!--
-These options are explained in more detail below.
+These options are explaind in more detail below.
-->
-下面将详细描述每一种方案。
+下面将详细描述每一项。
<!--
### Configuring Nodes to authenticate to a Private Registry
@@ -299,21 +299,6 @@ EOF
pod/private-image-test-1 created
```
-<!--
-If everything is working, then, after a few moments, you can run:
--->
-如果一切正常，一段时间后，可以运行:
-
-```shell
-kubectl logs private-image-test-1
-```
-
-并看到命令输出为：
-
-```
-SUCCESS
-```
-
<!--
If you suspect that the command failed, you can run:
-->
@@ -388,7 +373,7 @@ All pods will have read access to any pre-pulled images.
<!--
### Specifying ImagePullSecrets on a Pod
-->
-### 为 Pod 设置 ImagePullSecrets
+### 在 Pod 上指定 ImagePullSecrets {#specifying-imagepullsecrets-on-a-pod}
<!--
This is the recommended approach to run containers based on images
@@ -408,9 +393,9 @@ Kubernetes 支持在 Pod 中设置容器镜像仓库的密钥。
Run the following command, substituting the appropriate uppercase values:
-->
-#### 创建包含 Docker 配置的Secret
+#### 使用 Docker Config 创建 Secret {#creating-a-secret-with-docker-config}
-将大写字母代替为合适的值，运行以下命令：
+运行以下命令，将大写字母代替为合适的值：
```shell
kubectl create secret docker-registry <名称> \
diff --git a/content/zh/docs/concepts/extend-kubernetes/_index.md b/content/zh/docs/concepts/extend-kubernetes/_index.md
index e79067baad..ab475eee2d 100644
--- a/content/zh/docs/concepts/extend-kubernetes/_index.md
+++ b/content/zh/docs/concepts/extend-kubernetes/_index.md
@@ -97,7 +97,7 @@ API 通常用于托管的 Kubernetes 服务和受控的 Kubernetes 安装环境
这些 API 是声明式的，与 Pod 这类其他 Kubernetes 资源遵从相同的约定，所以
新的集群配置是可复用的，并且可以当作应用程序来管理。
此外，对于稳定版本的 API 而言，它们与其他 Kubernetes API 一样，采纳的是
-一种[预定义的支持策略](/zh/docs/reference/using-api/deprecation-policy/)。
+一种[预定义的支持策略](/docs/reference/using-api/deprecation-policy/)。
出于以上原因，在条件允许的情况下，基于 API 的方案应该优先于*配置文件*和*参数标志*。
<!--
@@ -259,7 +259,7 @@ For more about Custom Resources, see the [Custom Resources concept guide](/docs/
不要使用自定义资源来充当应用、用户或者监控数据的数据存储。
-关于自定义资源的更多信息，可参见[自定义资源概念指南](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
+关于自定义资源的更多信息，可参见[自定义资源概念指南](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
<!--
### Combining New APIs with Automation
@@ -307,7 +307,7 @@ Kubernetes has several built-in authentication methods that it supports. It can
Kubernetes 提供若干内置的身份认证方法。
它也可以运行在某中身份认证代理的后面，并且可以将来自鉴权头部的令牌发送到
某个远程服务（Webhook）来执行验证操作。
-所有这些方法都在[身份认证文档](/zh/docs/reference/access-authn-authz/authentication/)
+所有这些方法都在[身份认证文档](/docs/reference/access-authn-authz/authentication/)
中详细论述。
<!--
@@ -319,11 +319,11 @@ Kubernetes provides several built-in authentication methods, and an [Authenticat
-->
### 身份认证 {#authentication}
-[身份认证](/zh/docs/reference/access-authn-authz/authentication/)负责将所有请求中
+[身份认证](/docs/reference/access-authn-authz/authentication/)负责将所有请求中
的头部或证书映射到发出该请求的客户端的用户名。
Kubernetes 提供若干种内置的认证方法，以及
-[认证 Webhook](/zh/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)
+[认证 Webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)
方法以备内置方法无法满足你的要求。
<!--
@@ -443,7 +443,7 @@ the nodes chosen for a pod.
* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/)
* Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/)
-->
-* 进一步了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+* 进一步了解[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
* 了解[动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
* 进一步了解基础设施扩展
* [网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
diff --git a/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
index d91546feb6..641fc8e732 100644
--- a/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
+++ b/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
@@ -91,6 +91,6 @@ to disable the timeout restriction. This deprecated feature gate will be removed
了解如何在自己的环境中启用聚合器。
* 接下来，了解[安装扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)，
开始使用聚合层。
-* 也可以学习怎样[使用自定义资源定义扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
+* 也可以学习怎样[使用自定义资源定义扩展 Kubernetes API](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
* 阅读 [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io) 的规范
diff --git a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
index 964c5dc392..5802bb4884 100644
--- a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+++ b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
@@ -61,7 +61,7 @@ to advertise that the node has 2 “Foo” devices installed and available.
* 设备插件的 Unix 套接字。
* 设备插件的 API 版本。
* `ResourceName` 是需要公布的。这里 `ResourceName` 需要遵循
- [扩展资源命名方案](/zh/docs/concepts/configuration/manage-resources-container/#extended-resources)，
+ [扩展资源命名方案](/zh/docs/concepts/configuration/manage-resources-containers/#extended-resources)，
类似于 `vendor-domain/resourcetype`。（比如 NVIDIA GPU 就被公布为 `nvidia.com/gpu`。）
成功注册后，设备插件就向 kubelet 发送他所管理的设备列表，然后 kubelet 负责将这些资源发布到 API 服务器，作为 kubelet 节点状态更新的一部分。
@@ -378,8 +378,8 @@ Here are some examples of device plugin implementations:
* Learn about the [Topology Manager] (/docs/tasks/adminster-cluster/topology-manager/)
-->
* 查看[调度 GPU 资源](/zh/docs/tasks/manage-gpus/scheduling-gpus/) 来学习使用设备插件
-* 查看在上如何[公布节点上的扩展资源](/docs/tasks/administer-cluster/extended-resource-node/)
+* 查看在上如何[公布节点上的扩展资源](/zh/docs/tasks/administer-cluster/extended-resource-node/)
* 阅读如何在 Kubernetes 中使用 [TLS Ingress 的硬件加速](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/)
-* 学习[拓扑管理器](/zh/docs/tasks/adminster-cluster/topology-manager/)
+* 学习[拓扑管理器](/zh/docs/tasks/administer-cluster/topology-manager/)
diff --git a/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md b/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md
index 4c2c7cbc53..cb1ace4a9c 100644
--- a/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md
+++ b/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md
@@ -89,7 +89,7 @@ Flags and configuration files may not always be changeable in a hosted Kubernete
它们是声明性的，并使用与其他 Kubernetes 资源（如 Pod ）相同的约定，所以新的集群配置可以重复使用，
并以与应用程序相同的方式进行管理。
而且，当它们变稳定后，也遵循和其他 Kubernetes API 一样的
-[支持政策](/zh/docs/reference/using-api/deprecation-policy/)。
+[支持政策](/docs/reference/using-api/deprecation-policy/)。
出于这些原因，在合适的情况下它们优先于 *配置文件* 和 *标志* 被使用。
<!--
@@ -243,7 +243,7 @@ For more about Custom Resources, see the [Custom Resources concept guide](/docs/
不要使用自定义资源作为应用、用户或者监控数据的数据存储。
有关自定义资源的更多信息，请查看
-[自定义资源概念指南](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
+[自定义资源概念指南](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
<!--
### Combining New APIs with Automation
@@ -288,7 +288,7 @@ Kubernetes has several built-in authentication methods that it supports. It can
Kubernetes 有几个它支持的内置认证方法。它还可以位于身份验证代理之后，并将 Authorziation 头部
中的令牌发送给远程服务（webhook）进行验证。所有这些方法都在
-[身份验证文档](/zh/docs/reference/access-authn-authz/authentication/)中介绍。
+[身份验证文档](/docs/reference/access-authn-authz/authentication/)中介绍。
<!--
### Authentication
@@ -299,11 +299,11 @@ Kubernetes provides several built-in authentication methods, and an [Authenticat
-->
### 身份认证 {#authentication}
-[身份认证](/zh/docs/reference/access-authn-authz/authentication/)
+[身份认证](/docs/reference/access-authn-authz/authentication/)
将所有请求中的头部字段或证书映射为发出请求的客户端的用户名。
Kubernetes 提供了几种内置的身份认证方法，如果这些方法不符合你的需求，可以使用
-[身份认证 Webhook](/zh/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 方法。
+[身份认证 Webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 方法。
<!--
### Authorization
@@ -420,7 +420,7 @@ the nodes chosen for a pod.
* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/)
* Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/)
-->
-* 详细了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+* 详细了解[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
* 了解[动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
* 详细了解基础设施扩展
* [网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
diff --git a/content/zh/docs/concepts/extend-kubernetes/operator.md b/content/zh/docs/concepts/extend-kubernetes/operator.md
index 5cf55cbb8c..f3777c6b2c 100644
--- a/content/zh/docs/concepts/extend-kubernetes/operator.md
+++ b/content/zh/docs/concepts/extend-kubernetes/operator.md
@@ -20,7 +20,7 @@ Kubernetes principles, notably the [control loop](/docs/concepts/#kubernetes-con
-->
Operator 是 Kubernetes 的扩展软件，它利用
-[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)管理应用及其组件。
+[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)管理应用及其组件。
Operator 遵循 Kubernetes 的理念，特别是在[控制回路](/zh/docs/concepts/#kubernetes-control-plane)方面。
@@ -66,7 +66,7 @@ Kubernetes 为自动化而生。无需任何修改，您即可以从 Kubernetes
Kubernetes {{< glossary_tooltip text="控制器" term_id="controller" >}} 使您无需修改 Kubernetes 自身的代码，即可以扩展集群的行为。
Operator 是 Kubernetes API 的客户端，充当
-[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)的控制器。
+[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)的控制器。
<!--
## An example Operator {#example}
@@ -212,7 +212,7 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie
* Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators
-->
-* 详细了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+* 详细了解[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
* 在 [OperatorHub.io](https://operatorhub.io/) 上找到现成的、适合您的 Operator
* 借助已有的工具来编写您自己的 Operator，例如：
* [KUDO](https://kudo.dev/) (Kubernetes 通用声明式 Operator)
diff --git a/content/zh/docs/concepts/overview/components.md b/content/zh/docs/concepts/overview/components.md
index a8cc964c64..ebf3b2b4bf 100644
--- a/content/zh/docs/concepts/overview/components.md
+++ b/content/zh/docs/concepts/overview/components.md
@@ -100,8 +100,6 @@ These controllers include:
<!--
### cloud-controller-manager
-{{< glossary_definition term_id="cloud-controller-manager" length="short" >}}
-
The cloud-controller-manager only runs controllers that are specific to your cloud provider.
If you are running Kubernetes on your own premises, or in a learning environment inside your
own PC, the cluster does not have a cloud controller manager.
@@ -118,6 +116,8 @@ The following controllers can have cloud provider dependencies:
-->
### cloud-controller-manager
+{{< glossary_definition term_id="cloud-controller-manager" length="short" >}}
+
`cloud-controller-manager` 进运行特定于云平台的控制回路。
如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境，
所部属的环境中不需要云控制器管理器。
diff --git a/content/zh/docs/concepts/overview/kubernetes-api.md b/content/zh/docs/concepts/overview/kubernetes-api.md
index 99d65a572f..6188d8f1f3 100644
--- a/content/zh/docs/concepts/overview/kubernetes-api.md
+++ b/content/zh/docs/concepts/overview/kubernetes-api.md
@@ -57,7 +57,7 @@ Kubernetes 项目的目标是 _不要_ 引发现有客户端的兼容性问题
一般而言，新的 API 资源和新的资源字段可以被频繁地添加进来。
删除资源或者字段则要遵从
-[API 废弃策略](/zh/docs/reference/using-api/deprecation-policy/)。
+[API 废弃策略](/docs/reference/using-api/deprecation-policy/)。
关于什么是兼容性的变更，如何变更 API 等详细信息，可参考
[API 变更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)。
@@ -281,9 +281,9 @@ There are two paths to extending the API with [custom resources](/docs/concepts/
to make it seamless for clients.
-->
有两种途径来扩展 Kubernetes API 以支持
-[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)：
+[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)：
-1. 使用 [CustomResourceDefinition](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)，
+1. 使用 [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)，
你可以用声明式方式来定义 API 如何提供你所选择的资源 API。
1. 你也可以选择[实现自己的扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)
diff --git a/content/zh/docs/concepts/overview/working-with-objects/object-management.md b/content/zh/docs/concepts/overview/working-with-objects/object-management.md
index 5ae25eeebd..fc48eb7489 100644
--- a/content/zh/docs/concepts/overview/working-with-objects/object-management.md
+++ b/content/zh/docs/concepts/overview/working-with-objects/object-management.md
@@ -325,7 +325,7 @@ Disadvantages compared to imperative object configuration:
- [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
-->
- [使用命令式命令管理 Kubernetes 对象](/docs/tasks/manage-kubernetes-objects/imperative-command/)
-- [使用对象配置管理 Kubernetes 对象（命令式）](/docs/tasks/manage-kubernetes-objects/imperative-config/)
+- [使用对象配置管理 Kubernetes 对象（命令式）](/zh/docs/tasks/manage-kubernetes-objects/imperative-config/)
- [使用对象配置管理 Kubernetes 对象（声明式）](/docs/tasks/manage-kubernetes-objects/declarative-config/)
- [使用 Kustomize（声明式）管理 Kubernetes 对象](/docs/tasks/manage-kubernetes-objects/kustomization/)
- [Kubectl 命令参考](/docs/reference/generated/kubectl/kubectl-commands/)
diff --git a/content/zh/docs/concepts/policy/pod-security-policy.md b/content/zh/docs/concepts/policy/pod-security-policy.md
index 3c24f027b0..38c97dcc6e 100644
--- a/content/zh/docs/concepts/policy/pod-security-policy.md
+++ b/content/zh/docs/concepts/policy/pod-security-policy.md
@@ -696,7 +696,7 @@ several security mechanisms.
See [Pod Security Standards](/docs/concepts/security/pod-security-standards/#policy-instantiation) for more examples.
-->
更多的示例可参考
-[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/#policy-instantiation)。
+[Pod 安全标准](/docs/concepts/security/pod-security-standards/#policy-instantiation)。
<!--
## Policy Reference
@@ -1219,7 +1219,7 @@ By default, all safe sysctls are allowed.
- Refer to [Pod Security Policy Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) for the api details.
-->
-- 参阅[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)
+- 参阅[Pod 安全标准](/docs/concepts/security/pod-security-standards/)
了解策略建议。
- 阅读 [Pod 安全策略参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy)了解 API 细节。
diff --git a/content/zh/docs/concepts/policy/resource-quotas.md b/content/zh/docs/concepts/policy/resource-quotas.md
index 73234a7cf3..f6bd8acf9e 100644
--- a/content/zh/docs/concepts/policy/resource-quotas.md
+++ b/content/zh/docs/concepts/policy/resource-quotas.md
@@ -190,7 +190,7 @@ In addition, you can limit consumption of storage resources based on associated
-->
## 存储资源配额
-用户可以对给定命名空间下的[存储资源](/zh/docs/concepts/storage/persistent-volumes/)总量进行限制。
+用户可以对给定命名空间下的[存储资源](/docs/concepts/storage/persistent-volumes/)总量进行限制。
此外，还可以根据相关的存储类（Storage Class）来限制存储资源的消耗。
@@ -205,9 +205,9 @@ In addition, you can limit consumption of storage resources based on associated
| 资源名称 | 描述 |
| --------------------- | ----------------------------------------------------------- |
| `requests.storage` | 所有 PVC，存储资源的需求总量不能超过该值。 |
-| `persistentvolumeclaims` | 在该命名空间中所允许的 [PVC](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 总量。 |
+| `persistentvolumeclaims` | 在该命名空间中所允许的 [PVC](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 总量。 |
| `<storage-class-name>.storageclass.storage.k8s.io/requests.storage` | 在所有与 storage-class-name 相关的持久卷声明中，存储请求的总和不能超过该值。 |
-| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` | 在与 storage-class-name 相关的所有持久卷声明中，命名空间中可以存在的[持久卷申领](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)总数。 |
+| `<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims` | 在与 storage-class-name 相关的所有持久卷声明中，命名空间中可以存在的[持久卷申领](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)总数。 |
<!--
For example, if an operator wants to quota storage with `gold` storage class separate from `bronze` storage class, the operator can
@@ -307,7 +307,7 @@ The following types are supported:
| 资源名称 | 描述 |
| ------------------------------- | ------------------------------------------------- |
| `configmaps` | 在该命名空间中允许存在的 ConfigMap 总数上限。 |
-| `persistentvolumeclaims` | 在该命名空间中允许存在的 [PVC](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 的总数上限。 |
+| `persistentvolumeclaims` | 在该命名空间中允许存在的 [PVC](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 的总数上限。 |
| `pods` | 在该命名空间中允许存在的非终止状态的 pod 总数上限。Pod 终止状态等价于 Pod 的 `.status.phase in (Failed, Succeeded)` = true |
| `replicationcontrollers` | 在该命名空间中允许存在的 RC 总数上限。 |
| `resourcequotas` | 在该命名空间中允许存在的资源配额总数上限。 |
@@ -387,7 +387,7 @@ Pods can be created at a specific [priority](/docs/concepts/configuration/pod-pr
You can control a pod's consumption of system resources based on a pod's priority, by using the `scopeSelector`
field in the quota spec.
-->
-Pod 可以创建为特定的[优先级](/zh/docs/concepts/configuration/pod-priority-preemption/#pod-priority)。
+Pod 可以创建为特定的[优先级](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)。
通过使用配额规约中的 `scopeSelector` 字段，用户可以根据 Pod 的优先级控制其系统资源消耗。
<!--
diff --git a/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md
old mode 100755
new mode 100644
index 1635c410d2..6d5c10b7b4
--- a/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md
+++ b/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md
@@ -520,6 +520,6 @@ arbitrary tolerations to DaemonSets.
* Read about [pod priority](/docs/concepts/configuration/pod-priority-preemption/)
-->
* 阅读[资源耗尽的处理](/zh/docs/tasks/administer-cluster/out-of-resource/)，以及如何配置其行为
-* 阅读 [Pod 优先级](/zh/docs/concepts/configuration/pod-priority-preemption/)
+* 阅读 [Pod 优先级](/docs/concepts/configuration/pod-priority-preemption/)
diff --git a/content/zh/docs/concepts/storage/dynamic-provisioning.md b/content/zh/docs/concepts/storage/dynamic-provisioning.md
index d2e8cff8e5..a45d65fd65 100644
--- a/content/zh/docs/concepts/storage/dynamic-provisioning.md
+++ b/content/zh/docs/concepts/storage/dynamic-provisioning.md
@@ -22,7 +22,7 @@ automatically provisions storage when it is requested by users.
-->
动态卷供应允许按需创建存储卷。
如果没有动态供应，集群管理员必须手动地联系他们的云或存储提供商来创建新的存储卷，
-然后在 Kubernetes 集群创建 [`PersistentVolume` 对象](/zh/docs/concepts/storage/persistent-volumes/)来表示这些卷。
+然后在 Kubernetes 集群创建 [`PersistentVolume` 对象](/docs/concepts/storage/persistent-volumes/)来表示这些卷。
动态供应功能消除了集群管理员预先配置存储的需要。 相反，它在用户请求时自动供应存储。
<!-- body -->
@@ -199,7 +199,7 @@ Zones in a Region. Single-Zone storage backends should be provisioned in the Zon
Pods are scheduled. This can be accomplished by setting the [Volume Binding
Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode).
-->
-在[多区域](/zh/docs/setup/best-practices/multiple-zones/)集群中，Pod 可以被分散到多个区域。
+在[多区域](/docs/setup/best-practices/multiple-zones/)集群中，Pod 可以被分散到多个区域。
单区域存储后端应该被供应到 Pod 被调度到的区域。
这可以通过设置[卷绑定模式](/zh/docs/concepts/storage/storage-classes/#volume-binding-mode)来实现。
diff --git a/content/zh/docs/concepts/storage/storage-classes.md b/content/zh/docs/concepts/storage/storage-classes.md
index b2d98c25aa..91761b546e 100644
--- a/content/zh/docs/concepts/storage/storage-classes.md
+++ b/content/zh/docs/concepts/storage/storage-classes.md
@@ -18,7 +18,7 @@ with [volumes](/docs/concepts/storage/volumes/) and
[persistent volumes](/docs/concepts/storage/persistent-volumes) is suggested.
-->
本文描述了 Kubernetes 中 StorageClass 的概念。建议先熟悉 [卷](/zh/docs/concepts/storage/volumes/) 和
-[持久卷](/zh/docs/concepts/storage/persistent-volumes) 的概念。
+[持久卷](/docs/concepts/storage/persistent-volumes) 的概念。
<!-- body -->
@@ -67,7 +67,7 @@ for details.
-->
管理员可以为没有申请绑定到特定 StorageClass 的 PVC 指定一个默认的存储类 ：
更多详情请参阅
-[PersistentVolumeClaim 章节](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。
+[PersistentVolumeClaim 章节](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。
```yaml
apiVersion: storage.k8s.io/v1
@@ -240,7 +240,7 @@ the class or PV, so mount of the PV will simply fail if one is invalid.
The `volumeBindingMode` field controls when [volume binding and dynamic
provisioning](/docs/concepts/storage/persistent-volumes/#provisioning) should occur.
-->
-`volumeBindingMode` 字段控制了[卷绑定和动态分配](/zh/docs/concepts/storage/persistent-volumes/#provisioning)
+`volumeBindingMode` 字段控制了[卷绑定和动态分配](/docs/concepts/storage/persistent-volumes/#provisioning)
应该发生在什么时候。
<!--
diff --git a/content/zh/docs/concepts/storage/volume-snapshots.md b/content/zh/docs/concepts/storage/volume-snapshots.md
index aaa68a342d..7c6f9ee6b4 100644
--- a/content/zh/docs/concepts/storage/volume-snapshots.md
+++ b/content/zh/docs/concepts/storage/volume-snapshots.md
@@ -18,7 +18,7 @@ weight: 20
In Kubernetes, a _VolumeSnapshot_ represents a snapshot of a volume on a storage system. This document assumes that you are already familiar with Kubernetes [persistent volumes](/docs/concepts/storage/persistent-volumes/).
-->
在 Kubernetes 中，卷快照是一个存储系统上卷的快照，本文假设你已经熟悉了 Kubernetes
-的 [持久卷](/zh/docs/concepts/storage/persistent-volumes/)。
+的 [持久卷](/docs/concepts/storage/persistent-volumes/)。
<!-- body -->
@@ -260,5 +260,5 @@ the *dataSource* field in the `PersistentVolumeClaim` object.
For more details, see
[Volume Snapshot and Restore Volume from Snapshot](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
-->
-更多详细信息，请参阅 [卷快照和从快照还原卷](/zh/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)。
+更多详细信息，请参阅 [卷快照和从快照还原卷](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)。
diff --git a/content/zh/docs/concepts/storage/volumes.md b/content/zh/docs/concepts/storage/volumes.md
index 262798346f..c6cbd24458 100644
--- a/content/zh/docs/concepts/storage/volumes.md
+++ b/content/zh/docs/concepts/storage/volumes.md
@@ -916,7 +916,7 @@ Watch out when using this type of volume, because:
* 具有相同配置（例如从 podTemplate 创建）的多个 Pod 会由于节点上文件的不同而在不同节点上有不同的行为。
* 当 Kubernetes 按照计划添加资源感知的调度时，这类调度机制将无法考虑由 `hostPath` 使用的资源。
* 基础主机上创建的文件或目录只能由 root 用户写入。您需要在
-[特权容器](/zh/docs/tasks/configure-pod-container/security-context/)
+[特权容器](/docs/tasks/configure-pod-container/security-context/)
中以 root 身份运行进程，或者修改主机上的文件权限以便容器能够写入 `hostPath` 卷。
<!--
@@ -1190,7 +1190,7 @@ A `persistentVolumeClaim` volume is used to mount a
way for users to "claim" durable storage (such as a GCE PersistentDisk or an
iSCSI volume) without knowing the details of the particular cloud environment.
-->
-`persistentVolumeClaim` 卷用来将[持久卷](/zh/docs/concepts/storage/persistent-volumes/)（PersistentVolume）挂载到 Pod 中。
+`persistentVolumeClaim` 卷用来将[持久卷](/docs/concepts/storage/persistent-volumes/)（PersistentVolume）挂载到 Pod 中。
持久卷是用户在不知道特定云环境细节的情况下"申领"持久存储（例如 GCE PersistentDisk 或者 iSCSI 卷）的一种方法。
<!--
@@ -1198,7 +1198,7 @@ See the [PersistentVolumes example](/docs/concepts/storage/persistent-volumes/)
details.
-->
-更多详情请参考[持久卷示例](/zh/docs/concepts/storage/persistent-volumes/)
+更多详情请参考[持久卷示例](/docs/concepts/storage/persistent-volumes/)
### projected {#projected}
@@ -1887,7 +1887,7 @@ specification, and to select the type of media to use, for clusters that have
several media types.
-->
将来，我们希望 `emptyDir` 卷和 `hostPath` 卷能够使用
-[resource](/zh/docs/concepts/configuration/manage-compute-resources-containers/)
+[resource](/zh/docs/concepts/configuration/manage-resources-containers/)
规约来请求一定量的空间，
并且能够为具有多种介质类型的集群选择要使用的介质类型。
@@ -2115,7 +2115,7 @@ CSI块卷支持功能已启用，但默认情况下启用。必须为此功能
Learn how to
[setup your PV/PVC with raw block volume support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support).
-->
-学习怎样[安装您的带有块卷支持的 PV/PVC](/zh/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)。
+学习怎样[安装您的带有块卷支持的 PV/PVC](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)。
<!--
#### CSI ephemeral volumes
diff --git a/content/zh/docs/concepts/workloads/controllers/cron-jobs.md b/content/zh/docs/concepts/workloads/controllers/cron-jobs.md
index f6a5eefa9c..11e9752bac 100644
--- a/content/zh/docs/concepts/workloads/controllers/cron-jobs.md
+++ b/content/zh/docs/concepts/workloads/controllers/cron-jobs.md
@@ -20,7 +20,7 @@ A _Cron Job_ creates [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-com
One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically
on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format.
-->
-_Cron Job_ 创建基于时间调度的 [Jobs](/zh/docs/concepts/workloads/controllers/jobs-run-to-completion/)。
+_Cron Job_ 创建基于时间调度的 [Jobs](/zh/docs/concepts/workloads/controllers/job/)。
一个 CronJob 对象就像 _crontab_ (cron table) 文件中的一行。
它用 [Cron](https://en.wikipedia.org/wiki/Cron) 格式进行编写，
@@ -136,9 +136,8 @@ For example, suppose a CronJob is set to schedule a new Job every one minute beg
`startingDeadlineSeconds` field is not set. If the CronJob controller happens to
be down from `08:29:00` to `10:21:00`, the job will not start as the number of missed jobs which missed their schedule is greater than 100.
-->
-例如，假设一个 CronJob 被设置为 `08:30:00` 准时开始，它的 `startingDeadlineSeconds`
-字段被设置为 10，如果在 `08:29:00` 时将 CronJob 控制器的时间改为 `08:42:00`，Job 将不会启动。
-如果觉得晚些开始比没有启动好，那请设置一个较长的 `startingDeadlineSeconds`。
+例如，假设一个 CronJob 被设置为从 `08:30:00` 开始每隔一分钟创建一个新的 Job，并且它的 `startingDeadlineSeconds` 字段
+未被设置。如果 CronJob 控制器从 `08:29:00` 到 `10:21:00` 终止运行，则该 Job 将不会启动，因为其错过的调度次数超过了100。
<!--
To illustrate this concept further, suppose a CronJob is set to schedule a new Job every one minute beginning at `08:30:00`, and its
diff --git a/content/zh/docs/concepts/workloads/controllers/daemonset.md b/content/zh/docs/concepts/workloads/controllers/daemonset.md
index c9b58f7bd5..e04b2282db 100644
--- a/content/zh/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/zh/docs/concepts/workloads/controllers/daemonset.md
@@ -199,7 +199,7 @@ If you do not specify either, then the DaemonSet controller will create Pods on
-->
### 仅在某些节点上运行 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。
+如果指定了 `.spec.template.spec.nodeSelector`，DaemonSet Controller 将在能够与 [Node Selector](/zh/docs/concepts/scheduling-eviction/assign-pod-node/) 匹配的节点上创建 Pod。类似这种情况，可以指定 `.spec.template.spec.affinity`，然后 DaemonSet Controller 将在能够与 [node Affinity](/zh/docs/concepts/scheduling-eviction/assign-pod-node/) 匹配的节点上创建 Pod。
如果根本就没有指定，则 DaemonSet Controller 将在所有节点上创建 Pod。
<!--
@@ -232,7 +232,7 @@ DaemonSet 确保所有符合条件的节点都运行该 Pod 的一个副本。
* Pod 行为的不一致性：正常 Pod 在被创建后等待调度时处于 `Pending` 状态，
DaemonSet Pods 创建后不会处于 `Pending` 状态下。这使用户感到困惑。
-* [Pod 抢占](/zh/docs/concepts/configuration/pod-priority-preemption/)
+* [Pod 抢占](/docs/concepts/configuration/pod-priority-preemption/)
由默认调度器处理。启用抢占后，DaemonSet 控制器将在不考虑 Pod 优先级和抢占
的情况下制定调度决策。
diff --git a/content/zh/docs/concepts/workloads/controllers/deployment.md b/content/zh/docs/concepts/workloads/controllers/deployment.md
index 007eaf9771..d0537de82a 100644
--- a/content/zh/docs/concepts/workloads/controllers/deployment.md
+++ b/content/zh/docs/concepts/workloads/controllers/deployment.md
@@ -21,7 +21,7 @@ A _Deployment_ controller provides declarative updates for [Pods](/docs/concepts
[ReplicaSets](/docs/concepts/workloads/controllers/replicaset/).
-->
-一个 _Deployment_ 控制器为 [Pods](/docs/concepts/workloads/pods/pod/)和 [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/)提供描述性的更新方式。
+一个 _Deployment_ 控制器为 [Pods](/zh/docs/concepts/workloads/pods/)和 [ReplicaSets](/zh/docs/concepts/workloads/controllers/replicaset/)提供描述性的更新方式。
<!--
@@ -1030,7 +1030,7 @@ deployment.apps/nginx-deployment scaled
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.
-->
-假设启用[水平自动缩放 Pod](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)在集群中，可以为 Deployment 设置自动缩放器，并选择最小和最大
+假设启用[水平自动缩放 Pod](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)在集群中，可以为 Deployment 设置自动缩放器，并选择最小和最大
要基于现有 Pods 的 CPU 利用率运行的 Pods。
```shell
@@ -1726,7 +1726,7 @@ thus that Deployment will not be able to roll back.
can create multiple Deployments, one for each release, following the canary pattern described in
[managing resources](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments).
-->
-如果要使用 Deployment 向用户或服务器子集展开版本，则可以创建多个 Deployments ，每个版本一个，遵循[资源管理](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)。
+如果要使用 Deployment 向用户或服务器子集展开版本，则可以创建多个 Deployments ，每个版本一个，遵循[资源管理](/zh/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)。
<!--
## Writing a Deployment Spec
@@ -1738,7 +1738,7 @@ can create multiple Deployments, one for each release, following the canary patt
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/concepts/overview/working-with-objects/object-management/) documents.
-->
-同其他 Kubernetes 配置， Deployment 需要 `apiVersion`， `kind`， 和 `metadata` 字段。有关配置文件的其他信息，参考 [应用 Deployment ](/docs/tutorials/stateless-application/run-stateless-application-deployment/)，配置容器，和 [使用 kubectl 管理资源](/docs/concepts/overview/working-with-objects/object-management/) 相关文档。
+同其他 Kubernetes 配置， Deployment 需要 `apiVersion`， `kind`， 和 `metadata` 字段。有关配置文件的其他信息，参考 [应用 Deployment ](/zh/docs/tasks/run-application/run-stateless-application-deployment/)，配置容器，和 [使用 kubectl 管理资源](/zh/docs/concepts/overview/working-with-objects/object-management/) 相关文档。
<!--
A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
@@ -1759,7 +1759,7 @@ configuring containers, and [using kubectl to manage resources](/docs/concepts/o
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`.
-->
-`.spec.template` 是一个 [Pod 示例](/docs/concepts/workloads/pods/pod-overview/#pod-templates)。它和 [Pod](/docs/concepts/workloads/pods/pod/)的约束完全相同，除了它是嵌套的，而且没有 `apiVersion` 或 `kind`。
+`.spec.template` 是一个 [Pod 示例](/zh/docs/concepts/workloads/pods/#pod-templates)。它和 [Pod](/zh/docs/concepts/workloads/pods)的约束完全相同，除了它是嵌套的，而且没有 `apiVersion` 或 `kind`。
<!--
In addition to required fields for a Pod, a Pod template in a Deployment must specify appropriate
@@ -1768,10 +1768,10 @@ labels and an appropriate restart policy. For labels, make sure not to overlap w
除了 Pod 的必填字段外， Deployment 中的 Pod 模板必须指定适当的标签和适当的重新启动策略。对于标签，请确保不要与其他控制器重叠。请参考[选择器](#selector))。
<!--
- Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Always` is
+ Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/#restart-policy) equal to `Always` is
allowed, which is the default if not specified.
-->
-只有 [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 等于 `Always` 被允许，这是在没有指定时的默认设置。
+只有 [`.spec.template.spec.restartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 等于 `Always` 被允许，这是在没有指定时的默认设置。
<!--
### Replicas
@@ -1792,7 +1792,7 @@ allowed, which is the default if not specified.
`.spec.selector` is an required field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/)
for the Pods targeted by this Deployment.
-->
-`.spec.selector` 是指定本次 Deployment Pods [标签选择器](/docs/concepts/overview/working-with-objects/labels/)的必要字段。
+`.spec.selector` 是指定本次 Deployment Pods [标签选择器](/zh/docs/concepts/overview/working-with-objects/labels/)的必要字段。
<!--
`.spec.selector` must match `.spec.template.metadata.labels`, or it will be rejected by the API.
@@ -1857,7 +1857,7 @@ the default value.
fashion when `.spec.strategy.type==RollingUpdate`. You can specify `maxUnavailable` and `maxSurge` to control
the rolling update process.
-->
- Deployment 会在 `.spec.strategy.type==RollingUpdate`时，采取 [滚动更新](/docs/tasks/run-application/rolling-update-replication-controller/)的方式更新Pods。可以指定 `maxUnavailable` 和 `maxSurge` 来控制滚动更新操作。
+ Deployment 会在 `.spec.strategy.type==RollingUpdate`时，采取滚动更新的方式更新Pods。可以指定 `maxUnavailable` 和 `maxSurge` 来控制滚动更新操作。
<!--
##### Max Unavailable
@@ -1932,7 +1932,7 @@ created Pod should be ready without any of its containers crashing, for it to be
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).
-->
-`.spec.minReadySeconds` 是一个可选字段，用于指定新创建的 Pod 在没有任意容器崩溃情况下的最小就绪时间，以便将其视为可用。默认值为 0（Pod 在准备就绪后立即将被视为可用）。了解有关何时Pod 被视为已准备就绪，参考[容器探针](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
+`.spec.minReadySeconds` 是一个可选字段，用于指定新创建的 Pod 在没有任意容器崩溃情况下的最小就绪时间，以便将其视为可用。默认值为 0（Pod 在准备就绪后立即将被视为可用）。了解有关何时Pod 被视为已准备就绪，参考[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
<!--
### Rollback To
diff --git a/content/zh/docs/concepts/workloads/controllers/job.md b/content/zh/docs/concepts/workloads/controllers/job.md
index 3156ff6a53..513591b317 100644
--- a/content/zh/docs/concepts/workloads/controllers/job.md
+++ b/content/zh/docs/concepts/workloads/controllers/job.md
@@ -812,7 +812,7 @@ for pods with `RestartPolicy` equal to `OnFailure` or `Never`.
-->
### 副本控制器 {#replication-controller}
-Job 与[副本控制器](/docs/user-guide/replication-controller)是彼此互补的。
+Job 与[副本控制器](/zh/docs/concepts/workloads/controllers/replicationcontroller/)是彼此互补的。
副本控制器管理的是那些不希望被终止的 Pod （例如，Web 服务器），
Job 管理的是那些希望被终止的 Pod（例如，批处理作业）。
diff --git a/content/zh/docs/concepts/workloads/controllers/replicaset.md b/content/zh/docs/concepts/workloads/controllers/replicaset.md
index 76e06b6490..60fb6bc36d 100644
--- a/content/zh/docs/concepts/workloads/controllers/replicaset.md
+++ b/content/zh/docs/concepts/workloads/controllers/replicaset.md
@@ -81,9 +81,9 @@ their ReplicaSets.
-->
## 怎样使用 ReplicaSet {#how-to-use-a-replicaset}
-大多数支持 Replication Controllers 的[`kubectl`](/docs/user-guide/kubectl/)命令也支持 ReplicaSets。但[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是个例外。如果您想要滚动更新功能请考虑使用 Deployment。[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是必需的，而 Deployment 是声明性的，因此我们建议通过 [`rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)命令使用 Deployment。
+大多数支持 Replication Controllers 的[`kubectl`](/zh/docs/reference/kubectl/kubectl/)命令也支持 ReplicaSets。但[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是个例外。如果您想要滚动更新功能请考虑使用 Deployment。[`rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 命令是必需的，而 Deployment 是声明性的，因此我们建议通过 [`rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)命令使用 Deployment。
-虽然 ReplicaSets 可以独立使用，但今天它主要被[Deployments](/docs/concepts/workloads/controllers/deployment/) 用作协调 Pod 创建、删除和更新的机制。
+虽然 ReplicaSets 可以独立使用，但今天它主要被[Deployments](/zh/docs/concepts/workloads/controllers/deployment/) 用作协调 Pod 创建、删除和更新的机制。
当您使用 Deployment 时，您不必担心还要管理它们创建的 ReplicaSet。Deployment 会拥有并管理它们的 ReplicaSet。
<!--
@@ -171,7 +171,7 @@ A ReplicaSet also needs a [`.spec` section](https://git.k8s.io/community/contrib
## 编写 ReplicaSet Spec
-与所有其他 Kubernetes API 对象一样，ReplicaSet 也需要 `apiVersion`、`kind`、和 `metadata` 字段。有关使用清单的一般信息，请参见 [使用 kubectl 管理对象](/docs/concepts/overview/object-management-kubectl/overview/)。
+与所有其他 Kubernetes API 对象一样，ReplicaSet 也需要 `apiVersion`、`kind`、和 `metadata` 字段。有关使用清单的一般信息，请参见 [使用 kubectl 管理对象](/zh/docs/concepts/overview/working-with-objects/object-management/)。
ReplicaSet 也需要 [`.spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) 部分。
@@ -195,15 +195,15 @@ for example the [Kubelet](/docs/admin/kubelet/) or Docker.
### Pod 模版
-`.spec.template` 是 `.spec` 唯一需要的字段。`.spec.template` 是 [Pod 模版](/docs/concepts/workloads/pods/pod-overview/#pod-templates)。它和 [Pod](/docs/concepts/workloads/pods/pod/) 的语法几乎完全一样，除了它是嵌套的并没有 `apiVersion` 和 `kind`。
+`.spec.template` 是 `.spec` 唯一需要的字段。`.spec.template` 是 [Pod 模版](/zh/docs/concepts/workloads/pods/#pod-templates)。它和 [Pod](/zh/docs/concepts/workloads/pods/) 的语法几乎完全一样，除了它是嵌套的并没有 `apiVersion` 和 `kind`。
除了所需的 Pod 字段之外，ReplicaSet 中的 Pod 模板必须指定适当的标签和适当的重启策略。
对于标签，请确保不要与其他控制器重叠。更多信息请参考 [Pod 选择器](#pod-selector)。
-对于 [重启策略](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)，`.spec.template.spec.restartPolicy` 唯一允许的取值是 `Always`，这也是默认值.
+对于 [重启策略](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)，`.spec.template.spec.restartPolicy` 唯一允许的取值是 `Always`，这也是默认值.
-对于本地容器重新启动，ReplicaSet 委托给了节点上的代理去执行，例如[Kubelet](/docs/admin/kubelet/) 或 Docker 去执行。
+对于本地容器重新启动，ReplicaSet 委托给了节点上的代理去执行，例如[Kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 或 Docker 去执行。
<!--
### Pod Selector
@@ -221,7 +221,7 @@ In Kubernetes 1.9 the API version `apps/v1` on the ReplicaSet kind is the curren
### Pod 选择器
-`.spec.selector` 字段是[标签选择器](/docs/concepts/overview/working-with-objects/labels/)。ReplicaSet 管理所有标签匹配与标签选择器的 Pod。它不区分自己创建或删除的 Pod 和其他人或进程创建或删除的pod。这允许在不影响运行中的 Pod 的情况下替换副本集。
+`.spec.selector` 字段是[标签选择器](/zh/docs/concepts/overview/working-with-objects/labels/)。ReplicaSet 管理所有标签匹配与标签选择器的 Pod。它不区分自己创建或删除的 Pod 和其他人或进程创建或删除的pod。这允许在不影响运行中的 Pod 的情况下替换副本集。
`.spec.template.metadata.labels` 必须匹配 `.spec.selector`，否则它将被 API 拒绝。
@@ -279,7 +279,7 @@ When using the REST API or the `client-go` library, you must set `propagationPol
### 删除 ReplicaSet 和它的 Pod
要删除 ReplicaSet 和它的所有 Pod，使用[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 命令。
-默认情况下，[垃圾收集器](/docs/concepts/workloads/controllers/garbage-collection/) 自动删除所有依赖的 Pod。
+默认情况下，[垃圾收集器](/zh/docs/concepts/workloads/controllers/garbage-collection/) 自动删除所有依赖的 Pod。
当使用 REST API 或 `client-go` 库时，您必须在删除选项中将 `propagationPolicy` 设置为 `Background` 或 `Foreground`。例如：
@@ -405,9 +405,9 @@ application using a Deployment, please read [Run a Stateless Application Using a
### Deployment （推荐）
-[`Deployment`](/docs/concepts/workloads/controllers/deployment/) 是一个高级 API 对象，它以 `kubectl rolling-update` 的方式更新其底层副本集及其Pod。
+[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 是一个高级 API 对象，它以 `kubectl rolling-update` 的方式更新其底层副本集及其Pod。
如果您需要滚动更新功能，建议使用 Deployment，因为 Deployment 与 `kubectl rolling-update` 不同的是：它是声明式的、服务器端的、并且具有其他特性。
-有关使用 Deployment 来运行无状态应用的更多信息，请参阅 [使用 Deployment 运行无状态应用](/docs/tasks/run-application/run-stateless-application-deployment/)。
+有关使用 Deployment 来运行无状态应用的更多信息，请参阅 [使用 Deployment 运行无状态应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)。
<!--
### Bare Pods
@@ -431,7 +431,7 @@ Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead o
### Job
-使用[`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) 代替ReplicaSet，可以用于那些期望自行终止的 Pod。
+使用[`Job`](/zh/docs/concepts/workloads/controllers/job/) 代替ReplicaSet，可以用于那些期望自行终止的 Pod。
<!--
### DaemonSet
@@ -444,7 +444,7 @@ safe to terminate when the machine is otherwise ready to be rebooted/shutdown.
### DaemonSet
-对于管理那些提供主机级别功能（如主机监控和主机日志）的容器，就要用[`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) 而不用 ReplicaSet。
+对于管理那些提供主机级别功能（如主机监控和主机日志）的容器，就要用[`DaemonSet`](/zh/docs/concepts/workloads/controllers/daemonset/) 而不用 ReplicaSet。
这些 Pod 的寿命与主机寿命有关：这些 Pod 需要先于主机上的其他 Pod 运行，并且在机器准备重新启动/关闭时安全地终止。
diff --git a/content/zh/docs/concepts/workloads/controllers/replicationcontroller.md b/content/zh/docs/concepts/workloads/controllers/replicationcontroller.md
index b719c0661f..7c3b5988e1 100644
--- a/content/zh/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/content/zh/docs/concepts/workloads/controllers/replicationcontroller.md
@@ -211,7 +211,7 @@ for example the [Kubelet](/docs/admin/kubelet/) or Docker.
只允许 [`.spec.template.spec.restartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 等于 `Always`，如果没有指定，这是默认值。
对于本地容器重启，ReplicationController 委托给节点上的代理，
-例如 [Kubelet](/docs/reference/command-line-toolls-reference/kubelet/) 或 Docker。
+例如 [Kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 或 Docker。
<!--
### Labels on the ReplicationController
@@ -546,7 +546,7 @@ Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead o
### Job
对于预期会自行终止的 Pod (即批处理任务)，使用
-[`Job`](/docs/concepts/workloads/controllers/job/) 而不是 ReplicationController。
+[`Job`](/zh/docs/concepts/workloads/controllers/job/) 而不是 ReplicationController。
<!--
### DaemonSet
diff --git a/content/zh/docs/concepts/workloads/controllers/statefulset.md b/content/zh/docs/concepts/workloads/controllers/statefulset.md
index 955774f469..a827581250 100644
--- a/content/zh/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/zh/docs/concepts/workloads/controllers/statefulset.md
@@ -140,7 +140,7 @@ spec:
* 名为 `nginx` 的 Headless Service 用来控制网络域名。
* 名为 `web` 的 StatefulSet 有一个 Spec，它表明将在独立的 3 个 Pod 副本中启动 nginx 容器。
* `volumeClaimTemplates` 将通过 PersistentVolumes 驱动提供的
- [PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
+ [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
<!--
## Pod Selector
@@ -232,7 +232,7 @@ This must be done manually.
-->
### 稳定的存储 {#stable-storage}
-Kubernetes 为每个 VolumeClaimTemplate 创建一个 [PersistentVolume](/zh/docs/concepts/storage/persistent-volumes/)。
+Kubernetes 为每个 VolumeClaimTemplate 创建一个 [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)。
在上面的 nginx 示例中，每个 Pod 将会得到基于 StorageClass `my-storage-class` 提供的
1 Gib 的 PersistentVolume。如果没有声明 StorageClass，就会使用默认的 StorageClass。
当一个 Pod 被调度（重新调度）到节点上时，它的 `volumeMounts` 会挂载与其
@@ -254,6 +254,8 @@ the StatefulSet.
<!--
## Deployment and Scaling Guarantees
+-->
+## 部署和扩缩保证 {#deployment-and-scaling-guarantees}
* For a StatefulSet with N replicas, when Pods are being deployed, they are created sequentially, in order from {0..N-1}.
* When Pods are being deleted, they are terminated in reverse order, from {N-1..0}.
diff --git a/content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md
index 3b2ddc60c7..7aecf4dc00 100644
--- a/content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md
+++ b/content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md
@@ -48,7 +48,7 @@ up finished Jobs (either `Complete` or `Failed`) automatically by specifying the
TTL 控制器现在只支持 Job。集群操作员可以通过指定 Job 的 `.spec.ttlSecondsAfterFinished`
字段来自动清理已结束的作业（`Complete` 或 `Failed`），如
-[示例](/zh/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
+[示例](/zh/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)
所示。
<!--
diff --git a/content/zh/docs/concepts/workloads/pods/_index.md b/content/zh/docs/concepts/workloads/pods/_index.md
index ac5806e3f0..dc908e196a 100644
--- a/content/zh/docs/concepts/workloads/pods/_index.md
+++ b/content/zh/docs/concepts/workloads/pods/_index.md
@@ -286,7 +286,7 @@ PodTemplates are specifications for creating Pods, and are included in workload
Pod 模板是包含在工作负载对象中的规范，用来创建 Pod。这类负载资源包括
[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)、
-[Job](/zh/docs/concepts/workloads/containers/job/) 和
+[Job](/zh/docs/concepts/workloads/controllers/job/) 和
[DaemonSets](/zh/docs/concepts/workloads/controllers/daemonset/)等。
<!--
@@ -431,7 +431,7 @@ Processes within a privileged container get almost the same privileges that are
## 容器的特权模式 {#rivileged-mode-for-containers}
Pod 中的任何容器都可以使用容器规约中的
-[安全性上下文](/zh/docs/tasks/configure-pod-container/security-context/)中的
+[安全性上下文](/docs/tasks/configure-pod-container/security-context/)中的
`privileged` 参数启用特权模式。
这对于想要使用使用操作系统管理权能（Capabilities，如操纵网络堆栈和访问设备）
的容器很有用。
@@ -516,7 +516,7 @@ To understand the context for why Kubernetes wraps a common Pod API in other res
或 {{< glossary_tooltip text="Deployment" term_id="deployment" >}}）
封装通用的 Pod API，相关的背景信息可以在前人的研究中找到。具体包括：
- * [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
+ * [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)
* [Borg](https://research.google.com/pubs/pub43438.html)
* [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
* [Omega](https://research.google/pubs/pub41684/)
diff --git a/content/zh/docs/concepts/workloads/pods/disruptions.md b/content/zh/docs/concepts/workloads/pods/disruptions.md
index 304f3703d5..3b97c72fdf 100644
--- a/content/zh/docs/concepts/workloads/pods/disruptions.md
+++ b/content/zh/docs/concepts/workloads/pods/disruptions.md
@@ -147,7 +147,7 @@ or across zones (if using a
和[有状态](/zh/docs/tasks/run-application/run-replicated-stateful-application/)应用程序的信息。）
- 为了在运行复制应用程序时获得更高的可用性，请跨机架（使用
[反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)）或跨区域
- （如果使用[多区域集群](/zh/docs/setup/best-practices/multiple-zones/)）扩展应用程序。
+ （如果使用[多区域集群](/docs/setup/best-practices/multiple-zones/)）扩展应用程序。
<!--
The frequency of voluntary disruptions varies. On a basic Kubernetes cluster, there are
@@ -204,7 +204,7 @@ instead of directly deleting pods or deployments. Examples are the `kubectl dra
and the Kubernetes-on-GCE cluster upgrade script (`cluster/gce/upgrade.sh`).
-->
集群管理员和托管提供商应该使用遵循 Pod Disruption Budgets 的接口
-（通过调用[Eviction API](/zh/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)），
+（通过调用[Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)），
而不是直接删除 Pod 或 Deployment。
<!--
@@ -267,7 +267,7 @@ hornoring the
`terminationGracePeriodSeconds` setting in its [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).)
-->
当使用驱逐 API 驱逐 Pod 时，Pod 会被体面地
-[终止](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)，期间会
+[终止](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)，期间会
参考 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
中的 `terminationGracePeriodSeconds` 配置值。
@@ -497,7 +497,7 @@ the nodes in your cluster, such as a node or system software upgrade, here are s
including steps to maintain its availability during the rollout.
-->
* 参考[配置 Pod 干扰预算](/zh/docs/tasks/run-application/configure-pdb/)中的方法来保护你的应用。
-* 进一步了解[排空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)的信息。
+* 进一步了解[排空节点](/docs/tasks/administer-cluster/safely-drain-node/)的信息。
* 了解[更新 Deployment](/zh/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)
的过程，包括如何在其进程中维持应用的可用性
diff --git a/content/zh/docs/concepts/workloads/pods/ephemeral-containers.md b/content/zh/docs/concepts/workloads/pods/ephemeral-containers.md
index 430a1d3c55..0667aa206a 100644
--- a/content/zh/docs/concepts/workloads/pods/ephemeral-containers.md
+++ b/content/zh/docs/concepts/workloads/pods/ephemeral-containers.md
@@ -34,7 +34,7 @@ feature could change significantly in the future or be removed entirely.
{{< warning >}}
临时容器处于早期的 alpha 阶段，不适用于生产环境集群。
应该预料到临时容器在某些情况下不起作用，例如在定位容器的命名空间时。
-根据 [Kubernetes 弃用政策](/zh/docs/reference/using-api/deprecation-policy/)，
+根据 [Kubernetes 弃用政策](/docs/reference/using-api/deprecation-policy/)，
此 alpha 功能将来可能发生重大变化或被完全删除。
{{< /warning >}}
diff --git a/content/zh/docs/reference/access-authn-authz/admission-controllers.md b/content/zh/docs/reference/access-authn-authz/admission-controllers.md
old mode 100755
new mode 100644
index ac42b47703..93be72db24
--- a/content/zh/docs/reference/access-authn-authz/admission-controllers.md
+++ b/content/zh/docs/reference/access-authn-authz/admission-controllers.md
@@ -1017,7 +1017,7 @@ for more information.
-->
该准入控制器根据与 PodPreset 中条件的匹配情况，将指定字段注入一个 pod。
-另请参见 [PodPreset 概念](/docs/concepts/workloads/pods/podpreset/)和[使用 PodPreset 将信息注入 Pod](/docs/tasks/inject-data-application/podpreset) 获取详情。
+另请参见 [PodPreset 概念](/zh/docs/concepts/workloads/pods/podpreset/)和[使用 PodPreset 将信息注入 Pod](/zh/docs/tasks/inject-data-application/podpreset) 获取详情。
### PodSecurityPolicy {#podsecuritypolicy}
diff --git a/content/zh/docs/reference/command-line-tools-reference/feature-gates.md b/content/zh/docs/reference/command-line-tools-reference/feature-gates.md
index b91c41bc79..295eb2a968 100644
--- a/content/zh/docs/reference/command-line-tools-reference/feature-gates.md
+++ b/content/zh/docs/reference/command-line-tools-reference/feature-gates.md
@@ -576,7 +576,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `EnableAggregatedDiscoveryTimeout` （ *已弃用* ）：对聚集的发现调用启用五秒钟超时设置。
- `EnableEquivalenceClassCache`：调度 Pod 时，使 scheduler 缓存节点的等效项。
- `EphemeralContainers`：启用添加 {{< glossary_tooltip text="临时容器" term_id="ephemeral-container" >}} 到正在运行的 Pod 的特性。
-- `EvenPodsSpread`：使 Pod 能够在拓扑域之间平衡调度。请参阅 [Pod 拓扑扩展约束](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)。
+- `EvenPodsSpread`：使 Pod 能够在拓扑域之间平衡调度。请参阅 [Pod 拓扑扩展约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)。
- `ExpandInUsePersistentVolumes`：启用扩展使用中的 PVC。请查阅 [调整使用中的 PersistentVolumeClaim 的大小](/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim)。
- `ExpandPersistentVolumes`：启用持久卷的扩展。请查阅[扩展永久卷声明](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)。
- `ExperimentalCriticalPodAnnotation`：启用将特定 Pod 注解为 *critical* 的方式，用于[确保其调度](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)。从 v1.13 开始，Pod 优先级和抢占功能已弃用此特性。
@@ -650,7 +650,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `PersistentLocalVolumes`：在 Pod 中启用 “本地” 卷类型的使用。如果请求 “本地” 卷，则必须指定 Pod 亲和力。
- `PodOverhead`：启用 [PodOverhead](/docs/concepts/configuration/pod-overhead/) 特性以解决 Pod 开销。
- `PodPriority`：根据[优先级](/docs/concepts/configuration/pod-priority-preemption/)启用 Pod 的调度和抢占。
-- `PodReadinessGates`：启用 `PodReadinessGate` 字段的设置以扩展 Pod 准备状态评估。有关更多详细信息，请参见 [Pod readiness 特性门控](/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)。
+- `PodReadinessGates`：启用 `PodReadinessGate` 字段的设置以扩展 Pod 准备状态评估。有关更多详细信息，请参见 [Pod readiness 特性门控](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)。
<!--
- `PodShareProcessNamespace`: Enable the setting of `shareProcessNamespace` in a Pod for sharing
@@ -710,7 +710,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
- `ServiceLoadBalancerFinalizer`：为服务负载均衡启用终结器保护。
- `ServiceNodeExclusion`：启用从云提供商创建的负载均衡中排除节点。如果节点标记有 `alpha.service-controller.kubernetes.io/exclude-balancer` 键或 `node.kubernetes.io/exclude-from-external-load-balancers`，则可以排除节点。
- `ServiceTopology`: 启用服务拓扑可以让一个服务基于集群的节点拓扑进行流量路由。有关更多详细信息，请参见[Service 拓扑](https://kubernetes.io/zh/docs/concepts/services-networking/service-topology/)
-- `StartupProbe`：在 kubelet 中启用 [startup](/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe) 探针。
+- `StartupProbe`：在 kubelet 中启用 [startup](/zh/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe) 探针。
- `StorageObjectInUseProtection`：如果仍在使用 PersistentVolume 或 PersistentVolumeClaim 对象，则将其推迟。
<!--
diff --git a/content/zh/docs/reference/glossary/addons.md b/content/zh/docs/reference/glossary/addons.md
index c4280561ac..00a871a227 100644
--- a/content/zh/docs/reference/glossary/addons.md
+++ b/content/zh/docs/reference/glossary/addons.md
@@ -2,7 +2,7 @@
title: 附加组件
id: addons
date: 2019-12-15
-full_link: /docs/concepts/cluster-administration/addons/
+full_link: /zh/docs/concepts/cluster-administration/addons/
short_description: >
扩展 Kubernetes 功能的资源。
@@ -17,7 +17,7 @@ tags:
title: Add-ons
id: addons
date: 2019-12-15
-full_link: /docs/concepts/cluster-administration/addons/
+full_link: /zh/docs/concepts/cluster-administration/addons/
short_description: >
Resources that extend the functionality of Kubernetes.
diff --git a/content/zh/docs/reference/glossary/admission-controller.md b/content/zh/docs/reference/glossary/admission-controller.md
index 4ce643553b..adbd681fae 100644
--- a/content/zh/docs/reference/glossary/admission-controller.md
+++ b/content/zh/docs/reference/glossary/admission-controller.md
@@ -2,7 +2,7 @@
title: 准入控制器
id: admission-controller
date: 2019-06-28
-full_link: /docs/reference/access-authn-authz/admission-controllers/
+full_link: /zh/docs/reference/access-authn-authz/admission-controllers/
short_description: >
在对象持久化之前拦截 Kubernetes Api 服务器请求的一段代码
aka:
@@ -16,7 +16,7 @@ tags:
title: Admission Controller
id: admission-controller
date: 2019-06-28
-full_link: /docs/reference/access-authn-authz/admission-controllers/
+full_link: /zh/docs/reference/access-authn-authz/admission-controllers/
short_description: >
A piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object.
diff --git a/content/zh/docs/reference/glossary/aggregation-layer.md b/content/zh/docs/reference/glossary/aggregation-layer.md
index 982c7ef3a2..ffcd784d55 100644
--- a/content/zh/docs/reference/glossary/aggregation-layer.md
+++ b/content/zh/docs/reference/glossary/aggregation-layer.md
@@ -2,7 +2,7 @@
title: 聚合层
id: aggregation-layer
date: 2018-10-08
-full_link: /docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
+full_link: /zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
short_description: >
聚合层允许您在自己的集群上安装额外的 Kubernetes 风格的 API。
@@ -18,7 +18,7 @@ tags:
title: Aggregation Layer
id: aggregation-layer
date: 2018-10-08
-full_link: /docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
+full_link: /zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
short_description: >
The aggregation layer lets you install additional Kubernetes-style APIs in your cluster.
diff --git a/content/zh/docs/reference/glossary/annotation.md b/content/zh/docs/reference/glossary/annotation.md
index 75705d9745..a5da0a060f 100644
--- a/content/zh/docs/reference/glossary/annotation.md
+++ b/content/zh/docs/reference/glossary/annotation.md
@@ -2,7 +2,7 @@
title: 注解
id: annotation
date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/annotations
+full_link: /zh/docs/concepts/overview/working-with-objects/annotations/
short_description: >
注解是以键值对的形式给资源对象附加随机的无法标识的元数据。
@@ -16,7 +16,7 @@ tags:
title: Annotation
id: annotation
date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/annotations
+full_link: /zh/docs/concepts/overview/working-with-objects/annotations/
short_description: >
A key-value pair that is used to attach arbitrary non-identifying metadata to objects.
diff --git a/content/zh/docs/reference/glossary/api-group.md b/content/zh/docs/reference/glossary/api-group.md
index 4687391f62..07c222acbe 100644
--- a/content/zh/docs/reference/glossary/api-group.md
+++ b/content/zh/docs/reference/glossary/api-group.md
@@ -2,7 +2,7 @@
title: API Group
id: api-group
date: 2019-09-02
-full_link: /docs/concepts/overview/kubernetes-api/#api-groups
+full_link: /zh/docs/concepts/overview/kubernetes-api/#api-groups
short_description: >
Kubernetes API 中的一组相关路径
@@ -16,7 +16,7 @@ tags:
title: API Group
id: api-group
date: 2019-09-02
-full_link: /docs/concepts/overview/kubernetes-api/#api-groups
+full_link: /zh/docs/concepts/overview/kubernetes-api/#api-groups
short_description: >
A set of related paths in the Kubernetes API.
diff --git a/content/zh/docs/reference/glossary/approver.md b/content/zh/docs/reference/glossary/approver.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/certificate.md b/content/zh/docs/reference/glossary/certificate.md
index 238178c890..c966aea2cb 100644
--- a/content/zh/docs/reference/glossary/certificate.md
+++ b/content/zh/docs/reference/glossary/certificate.md
@@ -2,7 +2,7 @@
title: 证书
id: certificate
date: 2018-04-12
-full_link: /docs/tasks/tls/managing-tls-in-a-cluster/
+full_link: /zh/docs/tasks/tls/managing-tls-in-a-cluster/
short_description: >
证书是个安全加密文件，用来确认对 Kubernetes 集群访问的合法性。
@@ -16,7 +16,7 @@ tags:
title: Certificate
id: certificate
date: 2018-04-12
-full_link: /docs/tasks/tls/managing-tls-in-a-cluster/
+full_link: /zh/docs/tasks/tls/managing-tls-in-a-cluster/
short_description: >
A cryptographically secure file used to validate access to the Kubernetes cluster.
diff --git a/content/zh/docs/reference/glossary/cloud-controller-manager.md b/content/zh/docs/reference/glossary/cloud-controller-manager.md
old mode 100755
new mode 100644
index b6254d7ce9..2fcd729f57
--- a/content/zh/docs/reference/glossary/cloud-controller-manager.md
+++ b/content/zh/docs/reference/glossary/cloud-controller-manager.md
@@ -2,7 +2,7 @@
title: 云控制器管理器
id: cloud-controller-manager
date: 2018-04-12
-full_link: /docs/tasks/administer-cluster/running-cloud-controller/
+full_link: /zh/docs/tasks/administer-cluster/running-cloud-controller/
short_description: >
云控制器管理器是 1.8 的 alpha 特性。在未来发布的版本中，这是将 Kubernetes 与任何其他云集成的最佳方式。
@@ -18,7 +18,7 @@ tags:
title: Cloud Controller Manager
id: cloud-controller-manager
date: 2018-04-12
-full_link: /docs/tasks/administer-cluster/running-cloud-controller/
+full_link: /zh/docs/tasks/administer-cluster/running-cloud-controller/
short_description: >
Cloud Controller Manager is an alpha feature in 1.8. In upcoming releases it will be the preferred way to integrate Kubernetes with any cloud.
diff --git a/content/zh/docs/reference/glossary/cloud-provider.md b/content/zh/docs/reference/glossary/cloud-provider.md
index 16851569d6..30462f792b 100644
--- a/content/zh/docs/reference/glossary/cloud-provider.md
+++ b/content/zh/docs/reference/glossary/cloud-provider.md
@@ -2,7 +2,7 @@
title: 云供应商
id: cloud-provider
date: 2018-04-12
-full_link: /docs/concepts/cluster-administration/cloud-providers
+full_link: /zh/docs/concepts/cluster-administration/cloud-providers/
short_description: >
云供应商是提供可以用来运行 Kubernetes 集群的云计算平台的公司。
@@ -16,7 +16,7 @@ tags:
title: Cloud Provider
id: cloud-provider
date: 2018-04-12
-full_link: /docs/concepts/cluster-administration/cloud-providers
+full_link: /zh/docs/concepts/cluster-administration/cloud-providers/
short_description: >
Cloud provider is a company that offers cloud computing platform that can run Kubernetes clusters.
diff --git a/content/zh/docs/reference/glossary/cni.md b/content/zh/docs/reference/glossary/cni.md
index 361a7f0911..93028f7747 100644
--- a/content/zh/docs/reference/glossary/cni.md
+++ b/content/zh/docs/reference/glossary/cni.md
@@ -2,7 +2,7 @@
title: CNI (容器网络接口)
id: cni
date: 2018-05-25
-full_link: /docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni
+full_link: /zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni
short_description: >
容器网络接口 (CNI) 插件是遵循 appc/CNI 协议的一类网络插件。
@@ -17,7 +17,7 @@ tags:
title: CNI (Container network interface)
id: cni
date: 2018-05-25
-full_link: /docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni
+full_link: /zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni
short_description: >
Container network interface (CNI) plugins are a type of Network plugin that adheres to the appc/CNI specification.
diff --git a/content/zh/docs/reference/glossary/configmap.md b/content/zh/docs/reference/glossary/configmap.md
index d3d0945cdc..d761b26e74 100644
--- a/content/zh/docs/reference/glossary/configmap.md
+++ b/content/zh/docs/reference/glossary/configmap.md
@@ -2,7 +2,7 @@
title: ConfigMap
id: configmap
date: 2018-04-12
-full_link: /docs/tasks/configure-pod-container/configure-pod-configmap/
+full_link: /zh/docs/tasks/configure-pod-container/configure-pod-configmap/
short_description: >
ConfigMap 是一种 API 对象，用来将非机密性的数据保存到健值对中。使用时可以用作环境变量、命令行参数或者存储卷中的配置文件。
@@ -16,7 +16,7 @@ tags:
title: ConfigMap
id: configmap
date: 2018-04-12
-full_link: /docs/tasks/configure-pod-container/configure-pod-configmap/
+full_link: /zh/docs/tasks/configure-pod-container/configure-pod-configmap/
short_description: >
An API object used to store non-confidential data in key-value pairs. Can be consumed as environment variables, command-line arguments, or config files in a volume.
diff --git a/content/zh/docs/reference/glossary/container-lifecycle-hooks.md b/content/zh/docs/reference/glossary/container-lifecycle-hooks.md
index 3d1b708fe0..20e65157a0 100644
--- a/content/zh/docs/reference/glossary/container-lifecycle-hooks.md
+++ b/content/zh/docs/reference/glossary/container-lifecycle-hooks.md
@@ -2,7 +2,7 @@
title: 容器生命周期钩子
id: container-lifecycle-hooks
date: 2018-10-08
-full_link: /docs/concepts/containers/container-lifecycle-hooks/
+full_link: /zh/docs/concepts/containers/container-lifecycle-hooks/
short_description: >
生命周期钩子暴露容器管理生命周期中的事件，允许用户在事件发生时运行代码。
@@ -15,7 +15,7 @@ tags:
title: Container Lifecycle Hooks
id: container-lifecycle-hooks
date: 2018-10-08
-full_link: /docs/concepts/containers/container-lifecycle-hooks/
+full_link: /zh/docs/concepts/containers/container-lifecycle-hooks/
short_description: >
The lifecycle hooks expose events in the container management lifecycle and let the user run code when the events occur.
diff --git a/content/zh/docs/reference/glossary/container.md b/content/zh/docs/reference/glossary/container.md
index 16d99f4e30..1b2a98d43b 100644
--- a/content/zh/docs/reference/glossary/container.md
+++ b/content/zh/docs/reference/glossary/container.md
@@ -2,7 +2,7 @@
title: 容器
id: container
date: 2018-04-12
-full_link: /docs/concepts/overview/what-is-kubernetes/#why-containers
+full_link: /zh/docs/concepts/overview/what-is-kubernetes/#why-containers
short_description: >
容器是可移植、可执行的轻量级的镜像，镜像中包含软件及其相关依赖。
@@ -17,7 +17,7 @@ tags:
title: Container
id: container
date: 2018-04-12
-full_link: /docs/concepts/overview/what-is-kubernetes/#why-containers
+full_link: /zh/docs/concepts/overview/what-is-kubernetes/#why-containers
short_description: >
A lightweight and portable executable image that contains software and all of its dependencies.
diff --git a/content/zh/docs/reference/glossary/contributor.md b/content/zh/docs/reference/glossary/contributor.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/cri.md b/content/zh/docs/reference/glossary/cri.md
index 42c6d4a76a..96fd7f4bf4 100644
--- a/content/zh/docs/reference/glossary/cri.md
+++ b/content/zh/docs/reference/glossary/cri.md
@@ -2,7 +2,7 @@
title: 容器运行时接口 (CRI)
id: cri
date: 2019-03-07
-full_link: /docs/concepts/overview/components/#container-runtime
+full_link: /zh/docs/concepts/overview/components/#container-runtime
short_description: >
一组与 kubelet 集成的容器运行时 API
@@ -18,7 +18,7 @@ tags:
title: Container runtime interface (CRI)
id: cri
date: 2019-03-07
-full_link: /docs/concepts/overview/components/#container-runtime
+full_link: /zh/docs/concepts/overview/components/#container-runtime
short_description: >
An API for container runtimes to integrate with kubelet
diff --git a/content/zh/docs/reference/glossary/cronjob.md b/content/zh/docs/reference/glossary/cronjob.md
index 5af7746647..e6838de86c 100644
--- a/content/zh/docs/reference/glossary/cronjob.md
+++ b/content/zh/docs/reference/glossary/cronjob.md
@@ -2,7 +2,7 @@
title: CronJob
id: cronjob
date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/cron-jobs/
+full_link: /zh/docs/concepts/workloads/controllers/cron-jobs/
short_description: >
管理定期运行的 [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)。
@@ -17,7 +17,7 @@ tags:
title: CronJob
id: cronjob
date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/cron-jobs/
+full_link: /zh/docs/concepts/workloads/controllers/cron-jobs/
short_description: >
Manages a [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) that runs on a periodic schedule.
diff --git a/content/zh/docs/reference/glossary/csi.md b/content/zh/docs/reference/glossary/csi.md
index afacbf8f1d..2b77146757 100644
--- a/content/zh/docs/reference/glossary/csi.md
+++ b/content/zh/docs/reference/glossary/csi.md
@@ -2,7 +2,7 @@
title: 容器存储接口 (CSI)
id: csi
date: 2018-06-25
-full_link: /docs/concepts/storage/volumes/#csi
+full_link: /zh/docs/concepts/storage/volumes/#csi
short_description: >
容器存储接口 （CSI）定义了存储系统暴露给容器的标准接口。
@@ -17,7 +17,7 @@ tags:
title: Container Storage Interface (CSI)
id: csi
date: 2018-06-25
-full_link: /docs/concepts/storage/volumes/#csi
+full_link: /zh/docs/concepts/storage/volumes/#csi
short_description: >
The Container Storage Interface (CSI) defines a standard interface to expose storage systems to containers.
diff --git a/content/zh/docs/reference/glossary/daemonset.md b/content/zh/docs/reference/glossary/daemonset.md
index f0ec7e9cda..ea250d02bc 100644
--- a/content/zh/docs/reference/glossary/daemonset.md
+++ b/content/zh/docs/reference/glossary/daemonset.md
@@ -2,7 +2,7 @@
title: DaemonSet
id: daemonset
date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/daemonset
+full_link: /zh/docs/concepts/workloads/controllers/daemonset/
short_description: >
确保 Pod 的副本在集群中的一组节点上运行。
@@ -18,7 +18,7 @@ tags:
title: DaemonSet
id: daemonset
date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/daemonset
+full_link: /zh/docs/concepts/workloads/controllers/daemonset/
short_description: >
Ensures a copy of a Pod is running across a set of nodes in a cluster.
diff --git a/content/zh/docs/reference/glossary/deployment.md b/content/zh/docs/reference/glossary/deployment.md
index 08abdc60c8..05bce1377b 100644
--- a/content/zh/docs/reference/glossary/deployment.md
+++ b/content/zh/docs/reference/glossary/deployment.md
@@ -2,7 +2,7 @@
title: Deployment
id: deployment
date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/deployment/
+full_link: /zh/docs/concepts/workloads/controllers/deployment/
short_description: >
Deployment 是管理应用副本的 API 对象。
@@ -18,7 +18,7 @@ tags:
title: Deployment
id: deployment
date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/deployment/
+full_link: /zh/docs/concepts/workloads/controllers/deployment/
short_description: >
An API object that manages a replicated application.
diff --git a/content/zh/docs/reference/glossary/developer.md b/content/zh/docs/reference/glossary/developer.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/device-plugin.md b/content/zh/docs/reference/glossary/device-plugin.md
index e6bc32b572..af7e491426 100644
--- a/content/zh/docs/reference/glossary/device-plugin.md
+++ b/content/zh/docs/reference/glossary/device-plugin.md
@@ -2,7 +2,7 @@
title: 驱动插件
id: device-plugin
date: 2019-02-02
-full_link: /docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/
+full_link: /zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/
short_description: >
在 Kubernetes 中运行的容器提供对供应商特定资源的访问权限。
aka:
@@ -15,7 +15,7 @@ tags:
title: Device Plugin
id: device-plugin
date: 2019-02-02
-full_link: /docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/
+full_link: /zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/
short_description: >
Containers running in Kubernetes that provide access to a vendor specific resource.
aka:
diff --git a/content/zh/docs/reference/glossary/disruption.md b/content/zh/docs/reference/glossary/disruption.md
index 0d8133938e..e175b930d7 100644
--- a/content/zh/docs/reference/glossary/disruption.md
+++ b/content/zh/docs/reference/glossary/disruption.md
@@ -2,7 +2,7 @@
title: 干扰
id: disruption
date: 2019-09-10
-full_link: /docs/concepts/workloads/pods/disruptions/
+full_link: /zh/docs/concepts/workloads/pods/disruptions/
short_description: >
导致 Pod 服务停止的事件。
aka:
@@ -17,7 +17,7 @@ tags:
title: Disruption
id: disruption
date: 2019-09-10
-full_link: /docs/concepts/workloads/pods/disruptions/
+full_link: /zh/docs/concepts/workloads/pods/disruptions/
short_description: >
An event that leads to Pod(s) going out of service
aka:
diff --git a/content/zh/docs/reference/glossary/docker.md b/content/zh/docs/reference/glossary/docker.md
old mode 100755
new mode 100644
index 1d7c9a8511..55782a84c8
--- a/content/zh/docs/reference/glossary/docker.md
+++ b/content/zh/docs/reference/glossary/docker.md
@@ -2,7 +2,7 @@
title: docker
id: docker
date: 2018-04-12
-full_link: /docs/reference/kubectl/docker-cli-to-kubectl/
+full_link: /zh/docs/reference/kubectl/docker-cli-to-kubectl/
short_description: >
Docker 是一种可以提供操作系统级别虚拟化（也称作容器）的软件技术。
@@ -16,7 +16,7 @@ tags:
title: docker
id: docker
date: 2018-04-12
-full_link: /docs/reference/kubectl/docker-cli-to-kubectl/
+full_link: /zh/docs/reference/kubectl/docker-cli-to-kubectl/
short_description: >
Docker is a software technology providing operating-system-level virtualization also known as containers.
diff --git a/content/zh/docs/reference/glossary/downstream.md b/content/zh/docs/reference/glossary/downstream.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/dynamic-volume-provisioning.md b/content/zh/docs/reference/glossary/dynamic-volume-provisioning.md
old mode 100755
new mode 100644
index 4f53bbef9d..1d3c67e285
--- a/content/zh/docs/reference/glossary/dynamic-volume-provisioning.md
+++ b/content/zh/docs/reference/glossary/dynamic-volume-provisioning.md
@@ -2,7 +2,7 @@
title: 动态卷供应
id: dynamicvolumeprovisioning
date: 2018-04-12
-full_link: /docs/concepts/storage/dynamic-provisioning
+full_link: /zh/docs/concepts/storage/dynamic-provisioning/
short_description: >
允许用户请求自动创建存储卷。
@@ -17,7 +17,7 @@ tags:
title: Dynamic Volume Provisioning
id: dynamicvolumeprovisioning
date: 2018-04-12
-full_link: /docs/concepts/storage/dynamic-provisioning
+full_link: /zh/docs/concepts/storage/dynamic-provisioning/
short_description: >
Allows users to request automatic creation of storage Volumes.
diff --git a/content/zh/docs/reference/glossary/endpoint-slice.md b/content/zh/docs/reference/glossary/endpoint-slice.md
index d59366f7cd..c108efd602 100644
--- a/content/zh/docs/reference/glossary/endpoint-slice.md
+++ b/content/zh/docs/reference/glossary/endpoint-slice.md
@@ -2,7 +2,7 @@
title: 端点切片
id: endpoint-slice
date: 2018-04-12
-full_link: /docs/concepts/services-networking/endpoint-slices/
+full_link: /zh/docs/concepts/services-networking/endpoint-slices/
short_description: >
一种将网络端点与 Kubernetes 资源组合在一起的方法。
@@ -17,7 +17,7 @@ tags:
title: Endpoint Slice
id: endpoint-slice
date: 2018-04-12
-full_link: /docs/concepts/services-networking/endpoint-slices/
+full_link: /zh/docs/concepts/services-networking/endpoint-slices/
short_description: >
A way to group network endpoints together with Kubernetes resources.
diff --git a/content/zh/docs/reference/glossary/ephemeral-container.md b/content/zh/docs/reference/glossary/ephemeral-container.md
index c7426f6a6f..fa95887e8d 100644
--- a/content/zh/docs/reference/glossary/ephemeral-container.md
+++ b/content/zh/docs/reference/glossary/ephemeral-container.md
@@ -2,7 +2,7 @@
title: 临时容器
id: ephemeral-container
date: 2019-08-26
-full_link: /docs/concepts/workloads/pods/ephemeral-containers/
+full_link: /zh/docs/concepts/workloads/pods/ephemeral-containers/
short_description: >
您可以在 Pod 中临时运行的一种容器类型
aka:
@@ -16,7 +16,7 @@ tags:
title: Ephemeral Container
id: ephemeral-container
date: 2019-08-26
-full_link: /docs/concepts/workloads/pods/ephemeral-containers/
+full_link: /zh/docs/concepts/workloads/pods/ephemeral-containers/
short_description: >
A type of container type that you can temporarily run inside a Pod
diff --git a/content/zh/docs/reference/glossary/etcd.md b/content/zh/docs/reference/glossary/etcd.md
index e73a8215c6..e0e11082a8 100644
--- a/content/zh/docs/reference/glossary/etcd.md
+++ b/content/zh/docs/reference/glossary/etcd.md
@@ -2,7 +2,7 @@
title: etcd
id: etcd
date: 2018-04-12
-full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/
+full_link: /zh/docs/tasks/administer-cluster/configure-upgrade-etcd/
short_description: >
etcd 是兼具一致性和高可用性的键值数据库，用作保存 Kubernetes 所有集群数据的后台数据库。
@@ -17,7 +17,7 @@ tags:
title: etcd
id: etcd
date: 2018-04-12
-full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/
+full_link: /zh/docs/tasks/administer-cluster/configure-upgrade-etcd/
short_description: >
Consistent and highly-available key value store used as Kubernetes' backing store for all cluster data.
diff --git a/content/zh/docs/reference/glossary/extensions.md b/content/zh/docs/reference/glossary/extensions.md
index 345342affe..ebc25eca05 100644
--- a/content/zh/docs/reference/glossary/extensions.md
+++ b/content/zh/docs/reference/glossary/extensions.md
@@ -2,7 +2,7 @@
title: 扩展组件
id: Extensions
date: 2019-02-01
-full_link: /docs/concepts/extend-kubernetes/extend-cluster/#extensions
+full_link: /zh/docs/concepts/extend-kubernetes/extend-cluster/#extensions
short_description: >
扩展组件是扩展并与 Kubernetes 深度集成以支持新型硬件的软件组件。
aka:
@@ -17,7 +17,7 @@ tags:
title: Extensions
id: Extensions
date: 2019-02-01
-full_link: /docs/concepts/extend-kubernetes/extend-cluster/#extensions
+full_link: /zh/docs/concepts/extend-kubernetes/extend-cluster/#extensions
short_description: >
Extensions are software components that extend and deeply integrate with Kubernetes to support new types of hardware.
diff --git a/content/zh/docs/reference/glossary/flexvolume.md b/content/zh/docs/reference/glossary/flexvolume.md
index fdb0becda9..af28200f40 100644
--- a/content/zh/docs/reference/glossary/flexvolume.md
+++ b/content/zh/docs/reference/glossary/flexvolume.md
@@ -2,7 +2,7 @@
title: FlexVolume
id: flexvolume
date: 2018-06-25
-full_link: /docs/concepts/storage/volumes/#flexvolume
+full_link: /zh/docs/concepts/storage/volumes/#flexvolume
short_description: >
Flexvolume 是创建 out-of-tree 卷插件的一种接口。 {{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}} 是比 Flexvolume 更新的接口，它解决了 Flexvolumes 的一些问题。
@@ -16,7 +16,7 @@ tags:
title: FlexVolume
id: flexvolume
date: 2018-06-25
-full_link: /docs/concepts/storage/volumes/#flexvolume
+full_link: /zh/docs/concepts/storage/volumes/#flexvolume
short_description: >
FlexVolume is an interface for creating out-of-tree volume plugins. The {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} is a newer interface which addresses several problems with FlexVolumes.
diff --git a/content/zh/docs/reference/glossary/helm-chart.md b/content/zh/docs/reference/glossary/helm-chart.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/horizontal-pod-autoscaler.md b/content/zh/docs/reference/glossary/horizontal-pod-autoscaler.md
old mode 100755
new mode 100644
index 663ebd26c8..3a94a04b5a
--- a/content/zh/docs/reference/glossary/horizontal-pod-autoscaler.md
+++ b/content/zh/docs/reference/glossary/horizontal-pod-autoscaler.md
@@ -2,7 +2,7 @@
title: Pod 水平自动扩缩器
id: horizontal-pod-autoscaler
date: 2018-04-12
-full_link: /docs/tasks/run-application/horizontal-pod-autoscale/
+full_link: /zh/docs/tasks/run-application/horizontal-pod-autoscale/
short_description: >
Pod 水平自动扩缩器（Horizontal Pod Autoscaler）是一种 API 资源，它根据目标 CPU 利用率或自定义度量目标扩缩 Pod 副本的数量。
@@ -16,7 +16,7 @@ tags:
title: Horizontal Pod Autoscaler
id: horizontal-pod-autoscaler
date: 2018-04-12
-full_link: /docs/tasks/run-application/horizontal-pod-autoscale/
+full_link: /zh/docs/tasks/run-application/horizontal-pod-autoscale/
short_description: >
An API resource that automatically scales the number of pod replicas based on targeted CPU utilization or custom metric targets.
diff --git a/content/zh/docs/reference/glossary/image.md b/content/zh/docs/reference/glossary/image.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/index.md b/content/zh/docs/reference/glossary/index.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/ingress.md b/content/zh/docs/reference/glossary/ingress.md
index 806dec752d..972c2b0873 100644
--- a/content/zh/docs/reference/glossary/ingress.md
+++ b/content/zh/docs/reference/glossary/ingress.md
@@ -2,7 +2,7 @@
title: Ingress
id: ingress
date: 2018-04-12
-full_link: /docs/concepts/services-networking/ingress/
+full_link: /zh/docs/concepts/services-networking/ingress/
short_description: >
Ingress 是对集群中服务的外部访问进行管理的 API 对象，典型的访问方式是 HTTP。
@@ -18,7 +18,7 @@ tags:
title: Ingress
id: ingress
date: 2018-04-12
-full_link: /docs/concepts/services-networking/ingress/
+full_link: /zh/docs/concepts/services-networking/ingress/
short_description: >
An API object that manages external access to the services in a cluster, typically HTTP.
diff --git a/content/zh/docs/reference/glossary/init-container.md b/content/zh/docs/reference/glossary/init-container.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/istio.md b/content/zh/docs/reference/glossary/istio.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/job.md b/content/zh/docs/reference/glossary/job.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/kops.md b/content/zh/docs/reference/glossary/kops.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/kube-apiserver.md b/content/zh/docs/reference/glossary/kube-apiserver.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/kube-controller-manager.md b/content/zh/docs/reference/glossary/kube-controller-manager.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/kube-proxy.md b/content/zh/docs/reference/glossary/kube-proxy.md
old mode 100755
new mode 100644
index 5b323f0d28..79c7e2b82a
--- a/content/zh/docs/reference/glossary/kube-proxy.md
+++ b/content/zh/docs/reference/glossary/kube-proxy.md
@@ -2,7 +2,7 @@
title: kube-proxy
id: kube-proxy
date: 2018-04-12
-full_link: /docs/reference/command-line-tools-reference/kube-proxy/
+full_link: /zh/docs/reference/command-line-tools-reference/kube-proxy/
short_description: >
`kube-proxy` 是集群中每个节点上运行的网络代理。
@@ -15,7 +15,7 @@ tags:
title: kube-proxy
id: kube-proxy
date: 2018-04-12
-full_link: /docs/reference/command-line-tools-reference/kube-proxy/
+full_link: /zh/docs/reference/command-line-tools-reference/kube-proxy/
short_description: >
`kube-proxy` is a network proxy that runs on each node in the cluster.
diff --git a/content/zh/docs/reference/glossary/kube-scheduler.md b/content/zh/docs/reference/glossary/kube-scheduler.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/kubectl.md b/content/zh/docs/reference/glossary/kubectl.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/kubelet.md b/content/zh/docs/reference/glossary/kubelet.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/kubernetes-api.md b/content/zh/docs/reference/glossary/kubernetes-api.md
old mode 100755
new mode 100644
index fc1dbeac6a..b21b771bfb
--- a/content/zh/docs/reference/glossary/kubernetes-api.md
+++ b/content/zh/docs/reference/glossary/kubernetes-api.md
@@ -2,7 +2,7 @@
title: Kubernetes API
id: kubernetes-api
date: 2018-04-12
-full_link: /docs/concepts/overview/kubernetes-api/
+full_link: /zh/docs/concepts/overview/kubernetes-api/
short_description: >
Kubernetes API 是通过 RESTful 接口提供 Kubernetes 功能服务并负责集群状态存储的应用程序。
@@ -17,7 +17,7 @@ tags:
title: Kubernetes API
id: kubernetes-api
date: 2018-04-12
-full_link: /docs/concepts/overview/kubernetes-api/
+full_link: /zh/docs/concepts/overview/kubernetes-api/
short_description: >
The application that serves Kubernetes functionality through a RESTful interface and stores the state of the cluster.
diff --git a/content/zh/docs/reference/glossary/label.md b/content/zh/docs/reference/glossary/label.md
old mode 100755
new mode 100644
index 6201aaeb29..c2644dd0d5
--- a/content/zh/docs/reference/glossary/label.md
+++ b/content/zh/docs/reference/glossary/label.md
@@ -2,7 +2,7 @@
title: 标签
id: label
date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/labels
+full_link: /zh/docs/concepts/overview/working-with-objects/labels/
short_description: >
用来为对象设置可标识的属性标记；这些标记对用户而言是有意义且重要的。
@@ -15,7 +15,7 @@ tags:
title: Label
id: label
date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/labels
+full_link: /zh/docs/concepts/overview/working-with-objects/labels/
short_description: >
Tags objects with identifying attributes that are meaningful and relevant to users.
diff --git a/content/zh/docs/reference/glossary/logging.md b/content/zh/docs/reference/glossary/logging.md
index 980555c79a..2dfd03ccf3 100644
--- a/content/zh/docs/reference/glossary/logging.md
+++ b/content/zh/docs/reference/glossary/logging.md
@@ -2,7 +2,7 @@
title: 日志
id: logging
date: 2019-04-04
-full_link: /docs/concepts/cluster-administration/logging/
+full_link: /zh/docs/concepts/cluster-administration/logging/
short_description: >
日志是集群或应用程序记录的事件列表。
@@ -18,7 +18,7 @@ tags:
title: Logging
id: logging
date: 2019-04-04
-full_link: /docs/concepts/cluster-administration/logging/
+full_link: /zh/docs/concepts/cluster-administration/logging/
short_description: >
Logs are the list of events that are logged by cluster or application.
diff --git a/content/zh/docs/reference/glossary/managed-service.md b/content/zh/docs/reference/glossary/managed-service.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/minikube.md b/content/zh/docs/reference/glossary/minikube.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/mirror-pod.md b/content/zh/docs/reference/glossary/mirror-pod.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/name.md b/content/zh/docs/reference/glossary/name.md
old mode 100755
new mode 100644
index dcc6028b3d..ae6b77e72a
--- a/content/zh/docs/reference/glossary/name.md
+++ b/content/zh/docs/reference/glossary/name.md
@@ -2,7 +2,7 @@
title: 名称
id: name
date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/names
+full_link: /zh/docs/concepts/overview/working-with-objects/names/
short_description: >
客户端提供的字符串，用来指代资源 URL 中的对象，如 `/api/v1/pods/some-name`。
@@ -16,7 +16,7 @@ tags:
title: Name
id: name
date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/names
+full_link: /zh/docs/concepts/overview/working-with-objects/names/
short_description: >
A client-provided string that refers to an object in a resource URL, such as `/api/v1/pods/some-name`.
diff --git a/content/zh/docs/reference/glossary/namespace.md b/content/zh/docs/reference/glossary/namespace.md
index 42019215cf..29f2108fb9 100644
--- a/content/zh/docs/reference/glossary/namespace.md
+++ b/content/zh/docs/reference/glossary/namespace.md
@@ -2,7 +2,7 @@
title: 命名空间
id: namespace
date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/namespaces
+full_link: /zh/docs/concepts/overview/working-with-objects/namespaces/
short_description: >
命名空间是 Kubernetes 为了在同一物理集群上支持多个虚拟集群而使用的一种抽象。
@@ -16,7 +16,7 @@ tags:
title: Namespace
id: namespace
date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/namespaces
+full_link: /zh/docs/concepts/overview/working-with-objects/namespaces/
short_description: >
An abstraction used by Kubernetes to support multiple virtual clusters on the same physical cluster.
diff --git a/content/zh/docs/reference/glossary/network-policy.md b/content/zh/docs/reference/glossary/network-policy.md
old mode 100755
new mode 100644
index 25269bcc05..4898c145a7
--- a/content/zh/docs/reference/glossary/network-policy.md
+++ b/content/zh/docs/reference/glossary/network-policy.md
@@ -2,7 +2,7 @@
title: 网络策略
id: network-policy
date: 2018-04-12
-full_link: /docs/concepts/services-networking/network-policies/
+full_link: /zh/docs/concepts/services-networking/network-policies/
short_description: >
网络策略是一种规范，规定了允许 Pod 组之间、Pod 与其他网络端点之间以怎样的方式进行通信。
@@ -18,7 +18,7 @@ tags:
title: Network Policy
id: network-policy
date: 2018-04-12
-full_link: /docs/concepts/services-networking/network-policies/
+full_link: /zh/docs/concepts/services-networking/network-policies/
short_description: >
A specification of how groups of Pods are allowed to communicate with each other and with other network endpoints.
diff --git a/content/zh/docs/reference/glossary/node.md b/content/zh/docs/reference/glossary/node.md
old mode 100755
new mode 100644
index d1756799b7..1277aa26ab
--- a/content/zh/docs/reference/glossary/node.md
+++ b/content/zh/docs/reference/glossary/node.md
@@ -2,7 +2,7 @@
title: 节点
id: node
date: 2018-04-12
-full_link: /docs/concepts/architecture/nodes/
+full_link: /zh/docs/concepts/architecture/nodes/
short_description: >
Kubernetes 中的工作机器称作节点。
@@ -15,7 +15,7 @@ tags:
title: Node
id: node
date: 2018-04-12
-full_link: /docs/concepts/architecture/nodes/
+full_link: /zh/docs/concepts/architecture/nodes/
short_description: >
A node is a worker machine in Kubernetes.
diff --git a/content/zh/docs/reference/glossary/operator-pattern.md b/content/zh/docs/reference/glossary/operator-pattern.md
index 6e7235fb89..e4b47f68c7 100644
--- a/content/zh/docs/reference/glossary/operator-pattern.md
+++ b/content/zh/docs/reference/glossary/operator-pattern.md
@@ -2,7 +2,7 @@
title: Operator 模式
id: operator-pattern
date: 2019-05-21
-full_link: /docs/concepts/extend-kubernetes/operator/
+full_link: /zh/docs/concepts/extend-kubernetes/operator/
short_description: >
一种用于管理自定义资源的专用控制器
@@ -17,7 +17,7 @@ tags:
title: Operator pattern
id: operator-pattern
date: 2019-05-21
-full_link: /docs/concepts/extend-kubernetes/operator/
+full_link: /zh/docs/concepts/extend-kubernetes/operator/
short_description: >
A specialized controller used to manage a custom resource
diff --git a/content/zh/docs/reference/glossary/persistent-volume-claim.md b/content/zh/docs/reference/glossary/persistent-volume-claim.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/platform-developer.md b/content/zh/docs/reference/glossary/platform-developer.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/pod-disruption-budget.md b/content/zh/docs/reference/glossary/pod-disruption-budget.md
index 3c04a0cc95..d2ff489fd5 100644
--- a/content/zh/docs/reference/glossary/pod-disruption-budget.md
+++ b/content/zh/docs/reference/glossary/pod-disruption-budget.md
@@ -37,4 +37,4 @@ tags:
<!--
A [Pod Disruption Budget](/docs/concepts/workloads/pods/disruptions/) allows an application owner to create an object for a replicated application, that ensures a certain number or percentage of Pods with an assigned label will not be voluntarily evicted at any point in time. PDBs cannot prevent an involuntary disruption, but will count against the budget.
-->
- [Pod Disruption Budget](/docs/concepts/workloads/pods/disruptions/) 使应用所有者能够为多实例应用创建一个对象，来确保一定数量的具有指定标签的 Pod 在任何时候都不会被主动驱逐。 PDB 无法防止非主动的中断，但是会计入预算（budget）。
\ No newline at end of file
+ [Pod Disruption Budget](/zh/docs/concepts/workloads/pods/disruptions/) 使应用所有者能够为多实例应用创建一个对象，来确保一定数量的具有指定标签的 Pod 在任何时候都不会被主动驱逐。 PDB 无法防止非主动的中断，但是会计入预算（budget）。
\ No newline at end of file
diff --git a/content/zh/docs/reference/glossary/pod-lifecycle.md b/content/zh/docs/reference/glossary/pod-lifecycle.md
index bb3811ccf8..8d313b7cf0 100644
--- a/content/zh/docs/reference/glossary/pod-lifecycle.md
+++ b/content/zh/docs/reference/glossary/pod-lifecycle.md
@@ -39,4 +39,4 @@ short_description: >
<!--
The [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/) is a high level summary of where a Pod is in its lifecyle. A Pod’s `status` field is a [PodStatus](/docs/reference/generated/kubernetes-api/v1.13/#podstatus-v1-core) object, which has a `phase` field that displays one of the following phases: Running, Pending, Succeeded, Failed, Unknown, Completed, or CrashLoopBackOff.
-->
-[Pod 生命周期](/docs/concepts/workloads/pods/pod-lifecycle/) 是关于 Pod 在其生命周期中处于哪个阶段的更高层次概述。Pod 的`status` 字段是 [PodStatus](/docs/reference/generated/kubernetes-api/v1.13/#podstatus-v1-core) 对象, 该对象的 `phase` 字段包含了下面的状态: Running、Pending、Succeeded、Failed、Unknown、Completed 或 CrashLoopBackOff。
+[Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/) 是关于 Pod 在其生命周期中处于哪个阶段的更高层次概述。Pod 的`status` 字段是 [PodStatus](/docs/reference/generated/kubernetes-api/v1.13/#podstatus-v1-core) 对象, 该对象的 `phase` 字段包含了下面的状态: Running、Pending、Succeeded、Failed、Unknown、Completed 或 CrashLoopBackOff。
diff --git a/content/zh/docs/reference/glossary/pod-security-policy.md b/content/zh/docs/reference/glossary/pod-security-policy.md
index e9937009cd..d443e88df0 100644
--- a/content/zh/docs/reference/glossary/pod-security-policy.md
+++ b/content/zh/docs/reference/glossary/pod-security-policy.md
@@ -2,7 +2,7 @@
title: Pod 安全策略
id: pod-security-policy
date: 2018-04-12
-full_link: /docs/concepts/policy/pod-security-policy/
+full_link: /zh/docs/concepts/policy/pod-security-policy/
short_description: >
为 Pod 的创建和更新操作启用细粒度的授权。
@@ -17,7 +17,7 @@ tags:
title: Pod Security Policy
id: pod-security-policy
date: 2018-04-12
-full_link: /docs/concepts/policy/pod-security-policy/
+full_link: /zh/docs/concepts/policy/pod-security-policy/
short_description: >
Enables fine-grained authorization of pod creation and updates.
diff --git a/content/zh/docs/reference/glossary/pod.md b/content/zh/docs/reference/glossary/pod.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/podpreset.md b/content/zh/docs/reference/glossary/podpreset.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/rbac.md b/content/zh/docs/reference/glossary/rbac.md
old mode 100755
new mode 100644
index 6f045ed9d0..e0efa640e7
--- a/content/zh/docs/reference/glossary/rbac.md
+++ b/content/zh/docs/reference/glossary/rbac.md
@@ -2,7 +2,7 @@
title: RBAC（基于角色的访问控制）
id: rbac
date: 2018-04-12
-full_link: /docs/reference/access-authn-authz/rbac/
+full_link: /zh/docs/reference/access-authn-authz/rbac/
short_description: >
管理授权决策，允许管理员通过 Kubernetes API 动态配置访问策略。
@@ -17,7 +17,7 @@ tags:
title: RBAC (Role-Based Access Control)
id: rbac
date: 2018-04-12
-full_link: /docs/reference/access-authn-authz/rbac/
+full_link: /zh/docs/reference/access-authn-authz/rbac/
short_description: >
Manages authorization decisions, allowing admins to dynamically configure access policies through the Kubernetes API.
diff --git a/content/zh/docs/reference/glossary/replica-set.md b/content/zh/docs/reference/glossary/replica-set.md
old mode 100755
new mode 100644
index 5f394133b6..40378c2555
--- a/content/zh/docs/reference/glossary/replica-set.md
+++ b/content/zh/docs/reference/glossary/replica-set.md
@@ -2,7 +2,7 @@
title: ReplicaSet
id: replica-set
date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/replicaset/
+full_link: /zh/docs/concepts/workloads/controllers/replicaset/
short_description: >
ReplicaSet 是下一代副本控制器。
@@ -18,7 +18,7 @@ tags:
title: ReplicaSet
id: replica-set
date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/replicaset/
+full_link: /zh/docs/concepts/workloads/controllers/replicaset/
short_description: >
ReplicaSet is the next-generation Replication Controller.
diff --git a/content/zh/docs/reference/glossary/resource-quota.md b/content/zh/docs/reference/glossary/resource-quota.md
old mode 100755
new mode 100644
index c0f40f3234..658a1633ce
--- a/content/zh/docs/reference/glossary/resource-quota.md
+++ b/content/zh/docs/reference/glossary/resource-quota.md
@@ -2,7 +2,7 @@
title: 资源配额
id: resource-quota
date: 2018-04-12
-full_link: /docs/concepts/policy/resource-quotas/
+full_link: /zh/docs/concepts/policy/resource-quotas/
short_description: >
资源配额提供了限制每个命名空间的资源消耗总和的约束。
@@ -18,7 +18,7 @@ tags:
title: Resource Quotas
id: resource-quota
date: 2018-04-12
-full_link: /docs/concepts/policy/resource-quotas/
+full_link: /zh/docs/concepts/policy/resource-quotas/
short_description: >
Provides constraints that limit aggregate resource consumption per namespace.
diff --git a/content/zh/docs/reference/glossary/secret.md b/content/zh/docs/reference/glossary/secret.md
old mode 100755
new mode 100644
index a43dbb6ece..8bbb57df6b
--- a/content/zh/docs/reference/glossary/secret.md
+++ b/content/zh/docs/reference/glossary/secret.md
@@ -2,7 +2,7 @@
title: Secret
id: secret
date: 2018-04-12
-full_link: /docs/concepts/configuration/secret/
+full_link: /zh/docs/concepts/configuration/secret/
short_description: >
Secret 用于存储敏感信息，如密码、OAuth 令牌和 SSH 密钥。
@@ -17,7 +17,7 @@ tags:
title: Secret
id: secret
date: 2018-04-12
-full_link: /docs/concepts/configuration/secret/
+full_link: /zh/docs/concepts/configuration/secret/
short_description: >
Stores sensitive information, such as passwords, OAuth tokens, and ssh keys.
diff --git a/content/zh/docs/reference/glossary/security-context.md b/content/zh/docs/reference/glossary/security-context.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/selector.md b/content/zh/docs/reference/glossary/selector.md
index 5a3e83ef0d..a3dcd0b71b 100644
--- a/content/zh/docs/reference/glossary/selector.md
+++ b/content/zh/docs/reference/glossary/selector.md
@@ -2,7 +2,7 @@
title: 选择算符
id: selector
date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/labels/
+full_link: /zh/docs/concepts/overview/working-with-objects/labels/
short_description: >
选择算符允许用户通过标签对一组资源对象进行筛选过滤。
@@ -16,7 +16,7 @@ tags:
title: Selector
id: selector
date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/labels/
+full_link: /zh/docs/concepts/overview/working-with-objects/labels/
short_description: >
Allows users to filter a list of resources based on labels.
diff --git a/content/zh/docs/reference/glossary/service-account.md b/content/zh/docs/reference/glossary/service-account.md
old mode 100755
new mode 100644
index 4dd29b301b..28c7ffd9b6
--- a/content/zh/docs/reference/glossary/service-account.md
+++ b/content/zh/docs/reference/glossary/service-account.md
@@ -2,7 +2,7 @@
title: 服务账户
id: service-account
date: 2018-04-12
-full_link: /docs/tasks/configure-pod-container/configure-service-account/
+full_link: /zh/docs/tasks/configure-pod-container/configure-service-account/
short_description: >
为在 Pod 中运行的进程提供标识。
@@ -17,7 +17,7 @@ tags:
title: Service Account
id: service-account
date: 2018-04-12
-full_link: /docs/tasks/configure-pod-container/configure-service-account/
+full_link: /zh/docs/tasks/configure-pod-container/configure-service-account/
short_description: >
Provides an identity for processes that run in a Pod.
diff --git a/content/zh/docs/reference/glossary/service-broker.md b/content/zh/docs/reference/glossary/service-broker.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/service.md b/content/zh/docs/reference/glossary/service.md
old mode 100755
new mode 100644
index 54a03b3b1a..95e3b9e007
--- a/content/zh/docs/reference/glossary/service.md
+++ b/content/zh/docs/reference/glossary/service.md
@@ -2,7 +2,7 @@
title: Service
id: service
date: 2018-04-12
-full_link: /docs/concepts/services-networking/service/
+full_link: /zh/docs/concepts/services-networking/service/
short_description: >
将运行在一组 {{< glossary_tooltip text="Pods" term_id="pod" >}} 上的应用程序公开为网络服务的抽象方法。
diff --git a/content/zh/docs/reference/glossary/sig.md b/content/zh/docs/reference/glossary/sig.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/statefulset.md b/content/zh/docs/reference/glossary/statefulset.md
index ff63c63ce1..8003a09893 100644
--- a/content/zh/docs/reference/glossary/statefulset.md
+++ b/content/zh/docs/reference/glossary/statefulset.md
@@ -2,7 +2,7 @@
title: StatefulSet
id: statefulset
date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/statefulset/
+full_link: /zh/docs/concepts/workloads/controllers/statefulset/
short_description: >
StatefulSet 用来管理 Deployment 和伸缩一组 Pod，并且能为这些 Pod 提供*序号和唯一性保证*。
aka:
@@ -18,7 +18,7 @@ tags:
title: StatefulSet
id: statefulset
date: 2018-04-12
-full_link: /docs/concepts/workloads/controllers/statefulset/
+full_link: /zh/docs/concepts/workloads/controllers/statefulset/
short_description: >
Manages the deployment and scaling of a set of Pods, *and provides guarantees about the ordering and uniqueness* of these Pods.
diff --git a/content/zh/docs/reference/glossary/static-pod.md b/content/zh/docs/reference/glossary/static-pod.md
index 83659846fd..44e2a72bed 100644
--- a/content/zh/docs/reference/glossary/static-pod.md
+++ b/content/zh/docs/reference/glossary/static-pod.md
@@ -2,7 +2,7 @@
title: 静态 Pod
id: static-pod
date: 2019-02-12
-full_link: /docs/tasks/configure-pod-container/static-pod/
+full_link: /zh/docs/tasks/configure-pod-container/static-pod/
short_description: >
由特定节点上的 kubelet 守护进程直接管理的 pod。
@@ -16,7 +16,7 @@ tags:
title: Static Pod
id: static-pod
date: 2019-02-12
-full_link: /docs/tasks/configure-pod-container/static-pod/
+full_link: /zh/docs/tasks/configure-pod-container/static-pod/
short_description: >
A pod managed directly by the kubelet daemon on a specific node.
diff --git a/content/zh/docs/reference/glossary/storage-class.md b/content/zh/docs/reference/glossary/storage-class.md
index 49cadefe44..ad102de155 100644
--- a/content/zh/docs/reference/glossary/storage-class.md
+++ b/content/zh/docs/reference/glossary/storage-class.md
@@ -2,7 +2,7 @@
title: 存储类别
id: storageclass
date: 2018-04-12
-full_link: /docs/concepts/storage/storage-classes
+full_link: /zh/docs/concepts/storage/storage-classes/
short_description: >
StorageClass 是管理员用来描述不同的可用存储类型的一种方法。
@@ -17,7 +17,7 @@ tags:
title: Storage Class
id: storageclass
date: 2018-04-12
-full_link: /docs/concepts/storage/storage-classes
+full_link: /zh/docs/concepts/storage/storage-classes/
short_description: >
A StorageClass provides a way for administrators to describe different available storage types.
diff --git a/content/zh/docs/reference/glossary/sysctl.md b/content/zh/docs/reference/glossary/sysctl.md
index 46a6dd98f3..42ed215d6d 100644
--- a/content/zh/docs/reference/glossary/sysctl.md
+++ b/content/zh/docs/reference/glossary/sysctl.md
@@ -2,7 +2,7 @@
title: sysctl
id: sysctl
date: 2019-02-12
-full_link: /docs/tasks/administer-cluster/sysctl-cluster/
+full_link: /zh/docs/tasks/administer-cluster/sysctl-cluster/
short_description: >
用于获取和设置 Unix 内核参数的接口
@@ -16,7 +16,7 @@ tags:
title: sysctl
id: sysctl
date: 2019-02-12
-full_link: /docs/tasks/administer-cluster/sysctl-cluster/
+full_link: /zh/docs/tasks/administer-cluster/sysctl-cluster/
short_description: >
An interface for getting and setting Unix kernel parameters
diff --git a/content/zh/docs/reference/glossary/uid.md b/content/zh/docs/reference/glossary/uid.md
old mode 100755
new mode 100644
index 5990d46d1d..01805ee534
--- a/content/zh/docs/reference/glossary/uid.md
+++ b/content/zh/docs/reference/glossary/uid.md
@@ -2,7 +2,7 @@
title: UID
id: uid
date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/names
+full_link: /zh/docs/concepts/overview/working-with-objects/names/
short_description: >
由 Kubernetes 系统生成、用来唯一标识对象的字符串。
@@ -16,7 +16,7 @@ tags:
title: UID
id: uid
date: 2018-04-12
-full_link: /docs/concepts/overview/working-with-objects/names
+full_link: /zh/docs/concepts/overview/working-with-objects/names/
short_description: >
A Kubernetes systems-generated string to uniquely identify objects.
diff --git a/content/zh/docs/reference/glossary/volume-plugin.md b/content/zh/docs/reference/glossary/volume-plugin.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/glossary/volume.md b/content/zh/docs/reference/glossary/volume.md
old mode 100755
new mode 100644
index 279626861d..a170f0f3b8
--- a/content/zh/docs/reference/glossary/volume.md
+++ b/content/zh/docs/reference/glossary/volume.md
@@ -2,7 +2,7 @@
title: 卷
id: volume
date: 2018-04-12
-full_link: /docs/concepts/storage/volumes/
+full_link: /zh/docs/concepts/storage/volumes/
short_description: >
包含可被 Pod 中容器访问的数据的目录。
@@ -16,7 +16,7 @@ tags:
title: Volume
id: volume
date: 2018-04-12
-full_link: /docs/concepts/storage/volumes/
+full_link: /zh/docs/concepts/storage/volumes/
short_description: >
A directory containing data, accessible to the containers in a pod.
diff --git a/content/zh/docs/reference/glossary/workload.md b/content/zh/docs/reference/glossary/workload.md
index 1fb3586d86..d21e50e3b0 100644
--- a/content/zh/docs/reference/glossary/workload.md
+++ b/content/zh/docs/reference/glossary/workload.md
@@ -2,7 +2,7 @@
title: 工作负载
id: workloads
date: 2019-02-13
-full_link: /docs/concepts/workloads/
+full_link: /zh/docs/concepts/workloads/
short_description: >
工作负载是在 Kubernetes 上运行的应用程序。
@@ -15,7 +15,7 @@ tags:
title: Workload
id: workloads
date: 2019-02-13
-full_link: /docs/concepts/workloads/
+full_link: /zh/docs/concepts/workloads/
short_description: >
A workload is an application running on Kubernetes.
diff --git a/content/zh/docs/reference/kubectl/_index.md b/content/zh/docs/reference/kubectl/_index.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/reference/setup-tools/kubeadm/_index.md b/content/zh/docs/reference/setup-tools/kubeadm/_index.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/setup/best-practices/cluster-large.md b/content/zh/docs/setup/best-practices/cluster-large.md
index c694fd4dc2..a9237ebc48 100644
--- a/content/zh/docs/setup/best-practices/cluster-large.md
+++ b/content/zh/docs/setup/best-practices/cluster-large.md
@@ -170,7 +170,7 @@ On AWS, master node sizes are currently set at cluster startup time and do not c
<!--
### Addon Resources
-->
-### 插件资源
+### 插件资源 {#addon-resources}
<!--
To prevent memory leaks or other resource issues in [cluster addons](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons) from consuming all the resources available on a node, Kubernetes sets resource limits on addon containers to limit the CPU and Memory resources they can consume (See PR [#10653](http://pr.k8s.io/10653/files) and [#10778](http://pr.k8s.io/10778/files)).
diff --git a/content/zh/docs/setup/learning-environment/minikube.md b/content/zh/docs/setup/learning-environment/minikube.md
index 5696f59519..bd828ec871 100644
--- a/content/zh/docs/setup/learning-environment/minikube.md
+++ b/content/zh/docs/setup/learning-environment/minikube.md
@@ -374,12 +374,10 @@ minikube start --kubernetes-version {{< param "fullversion" >}}
```
<!--
#### Specifying the VM driver
--->
-#### 指定 VM 驱动程序
-<!--
You can change the VM driver by adding the `--vm-driver=<enter_driver_name>` flag to `minikube start`.
-->
+#### 指定 VM 驱动程序 {#specifying-the-vm-driver}
您可以通过将 `--vm-driver=<enter_driver_name>` 参数添加到 `minikube start` 来更改 VM 驱动程序。
<!--
diff --git a/content/zh/docs/tasks/_index.md b/content/zh/docs/tasks/_index.md
index 892ea33b1e..dff8e43aa2 100644
--- a/content/zh/docs/tasks/_index.md
+++ b/content/zh/docs/tasks/_index.md
@@ -5,188 +5,19 @@ weight: 50
content_type: concept
---
<!--
----
title: Tasks
main_menu: true
weight: 50
content_type: concept
----
-->
-{{< toc >}}
-
<!-- overview -->
-
-Kubernetes 文档这一部分包含的一些页面展示如何去做单个任务。一个任务页面展示了如何执行操作单一的项目，通常是通过给出若干步骤。
<!--
This section of the Kubernetes documentation contains pages that
show how to do individual tasks. A task page shows how to do a
single thing, typically by giving a short sequence of steps.
-->
-
-
-<!-- body -->
-
-## Web 用户界面 (Dashboard)
-
-部署和访问 Dashboard Web 用户界面，以帮助您管理和监控 Kubernetes 集群中的容器化应用程序。
-
-<!--
-## Web UI (Dashboard)
-
-Deploy and access the Dashboard web user interface to help you manage and monitor containerized applications in a Kubernetes cluster.
--->
-
-## 使用 kubectl 命令行
-
-下载并设置用于直接管理 Kubernetes 集群的 kubectl 命令行工具。
-
-<!--
-## Using the kubectl Command-line
-
-Install and setup the `kubectl` command-line tool used to directly manage Kubernetes clusters.
--->
-
-## 配置 Pod 和容器
-
-执行 Pod 和容器的常见配置任务。
-
-<!--
-## Configuring Pods and Containers
-
-Perform common configuration tasks for Pods and Containers.
--->
-
-## 运行应用程序
-
-执行常见的应用程序管理任务，例如滚动更新、将信息注入 Pod、以及 Pod 水平自动伸缩。
-
-<!--
-## Running Applications
-
-Perform common application management tasks, such as rolling updates, injecting information into pods, and horizontal Pod autoscaling.
--->
-
-## 运行 Job
-
-使用并行处理方式运行 Job。
-
-<!--
-## Running Jobs
-
-Run Jobs using parallel processing.
--->
-
-## 访问集群中的应用程序
-
-配置负载均衡和端口转发、或者设置防火墙、或者配置 DNS 以访问集群中的应用程序。
-
-<!--
-## Accessing Applications in a Cluster
-
-Configure load balancing, port forwarding, or setup firewall or DNS configurations to access applications in a cluster.
--->
-
-## 监控、日志记录和调试
-
-设置监控和日志记录以对集群进行故障排除或者调试容器化应用程序。
-
-<!--
-## Monitoring, Logging, and Debugging
-
-Setup monitoring and logging to troubleshoot a cluster or debug a containerized application.
--->
-
-## 访问 Kubernetes API
-
-了解直接访问 Kubernetes API 的各种方法。
-
-<!--
-## Accessing the Kubernetes API
-
-Learn various methods to directly access the Kubernetes API.
--->
-
-## 使用 TLS
-
-配置您的应用程序去信任和使用集群的根证书机构（ CA ）。
-
-<!--
-## Using TLS
-
-Configure your application to trust and use the cluster root Certificate Authority (CA).
--->
-
-## 管理集群
-
-了解管理集群的常见任务。
-
-<!--
-## Administering a Cluster
-
-Learn common tasks for administering a cluster.
--->
-
-## 管理联邦
-
-配置集群联邦中的组件。
-
-<!--
-## Administering Federation
-
-Configure components in a cluster federation.
--->
-
-## 管理状态应用程序
-
-执行管理有状态应用程序的常见任务，包括扩展、删除和调试 StatefulSets。
-
-<!--
-## Managing Stateful Applications
-
-Perform common tasks for managing Stateful applications, including scaling, deleting, and debugging StatefulSets.
--->
-
-## 集群 Daemons
-
-执行管理 DaemonSet 的常见任务，例如执行滚动更新。
-
-<!--
-## Cluster Daemons
-
-Perform common tasks for managing a DaemonSet, such as performing a rolling update.
--->
-
-## 管理 GPU
-
-配置和调度 NVIDIA GPU 作为集群中节点使用的资源。
-
-<!--
-## Managing GPUs
-
-Configure and schedule NVIDIA GPUs for use as a resource by nodes in a cluster.
--->
-
-## 管理 HugePage
-
-配置和调度 HugePage 作为集群中的可调度资源。
-
-<!--
-## Managing HugePages
-
-Configure and schedule huge pages as a schedulable resource in a cluster.
--->
-
-
-
-## {{% heading "whatsnext" %}}
-
-
-如果您想编写任务页面，请参阅[创建文档提取请求](/docs/home/contribute/create-pull-request/)。
-<!--
-If you would like to write a task page, see
-[Creating a Documentation Pull Request](/docs/home/contribute/create-pull-request/).
--->
-
+Kubernetes 文档这一部分包含的一些页面展示如何去完成单个任务。
+每个任务页面是一般通过给出若干步骤展示如何执行完成某事。
diff --git a/content/zh/docs/tasks/access-application-cluster/access-cluster.md b/content/zh/docs/tasks/access-application-cluster/access-cluster.md
index 5ed7151349..b7b4d18657 100644
--- a/content/zh/docs/tasks/access-application-cluster/access-cluster.md
+++ b/content/zh/docs/tasks/access-application-cluster/access-cluster.md
@@ -268,7 +268,7 @@ is associated with a service account, and a credential (token) for that
service account is placed into the filesystem tree of each container in that pod,
at `/var/run/secrets/kubernetes.io/serviceaccount/token`.
-->
-### 从 Pod 中访问 API
+### 从 Pod 中访问 API {#accessing-the-api-from-a-pod}
当你从 Pod 中访问 API 时，定位和验证 apiserver 会有些许不同。
@@ -319,7 +319,7 @@ their own IPs. In many cases, the node IPs, pod IPs, and some service IPs on a
routable, so they will not be reachable from a machine outside the cluster,
such as your desktop machine.
-->
-## 访问集群中正在运行的服务
+## 访问集群中正在运行的服务 {#accessing-services-running-on-the-cluster}
上一节介绍了如何连接 Kubernetes API 服务。本节介绍如何连接到 Kubernetes 集群上运行的其他服务。
在 Kubernetes 中，[节点](/docs/admin/node)，[pods](/docs/user-guide/pods) 和 [服务](/docs/user-guide/services) 都有自己的 IP。
diff --git a/content/zh/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md b/content/zh/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
index 18f2b1d44a..78b68d326b 100644
--- a/content/zh/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
+++ b/content/zh/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md
@@ -2,25 +2,36 @@
title: 同 Pod 内的容器使用共享卷通信
content_type: task
---
-
-
+<!--
+title: Communicate Between Containers in the Same Pod Using a Shared Volume
+content_type: task
+weight: 110
+-->
<!-- overview -->
+<!--
+This page shows how to use a Volume to communicate between two Containers running
+in the same Pod. See also how to allow processes to communicate by
+[sharing process namespace](/docs/tasks/configure-pod-container/share-process-namespace/)
+between containers.
+-->
本文旨在说明如何让一个 Pod 内的两个容器使用一个卷（Volume）进行通信。
-
-
+参阅如何让两个进程跨容器通过
+[共享进程名字空间](/zh/docs/tasks/configure-pod-container/share-process-namespace/)。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
-
<!-- steps -->
+<!--
+## Creating a Pod that runs two Containers
+In this exercise, you create a Pod that runs two Containers. The two containers
+share a Volume that they can use to communicate. Here is the configuration file
+for the Pod:
+-->
## 创建一个包含两个容器的 Pod
在这个练习中，你会创建一个包含两个容器的 Pod。两个容器共享一个卷用于他们之间的通信。
@@ -28,142 +39,175 @@ Pod 的配置文件如下：
{{< codenew file="pods/two-container-pod.yaml" >}}
+<!--
+In the configuration file, you can see that the Pod has a Volume named
+`shared-data`.
+
+The first container listed in the configuration file runs an nginx server. The
+mount path for the shared Volume is `/usr/share/nginx/html`.
+The second container is based on the debian image, and has a mount path of
+`/pod-data`. The second container runs the following command and then terminates.
+-->
在配置文件中，你可以看到 Pod 有一个共享卷，名为 `shared-data`。
配置文件中的第一个容器运行了一个 nginx 服务器。共享卷的挂载路径是 `/usr/share/nginx/html`。
第二个容器是基于 debian 镜像的，有一个 `/pod-data` 的挂载路径。第二个容器运行了下面的命令然后终止。
- echo Hello from the debian container > /pod-data/index.html
+```shell
+echo Hello from the debian container > /pod-data/index.html
+```
+<!--
+Notice that the second container writes the `index.html` file in the root
+directory of the nginx server.
+
+Create the Pod and the two Containers:
+-->
注意，第二个容器在 nginx 服务器的根目录下写了 `index.html` 文件。
-
创建一个包含两个容器的 Pod：
- kubectl apply -f https://k8s.io/examples/pods/two-container-pod.yaml
+```shell
+kubectl apply -f https://k8s.io/examples/pods/two-container-pod.yaml
+```
+<!--
+View information about the Pod and the Containers:
+-->
查看 Pod 和容器的信息：
- kubectl get pod two-containers --output=yaml
-
+```shell
+kubectl get pod two-containers --output=yaml
+```
+<!--
+Here is a portion of the output:
+-->
这是输出的一部分：
- apiVersion: v1
- kind: Pod
- metadata:
- ...
- name: two-containers
- namespace: default
- ...
- spec:
- ...
- containerStatuses:
+```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:
+ - containerID: docker://c1d8abd1 ...
+ image: debian
+ ...
+ lastState:
+ terminated:
...
+ name: debian-container
+ ...
+ - containerID: docker://96c1ff2c5bb ...
+ image: nginx
+ ...
+ name: nginx-container
+ ...
+ state:
+ running:
+ ...
+```
+<!--
+You can see that the debian Container has terminated, and the nginx Container
+is still running.
+Get a shell to nginx Container:
+-->
你可以看到 debian 容器已经被终止了，而 nginx 服务器依然在运行。
-
进入 nginx 容器的 shell：
- kubectl exec -it two-containers -c nginx-container -- /bin/bash
-
+```shell
+kubectl exec -it two-containers -c nginx-container -- /bin/bash
+```
+<!--
+In your shell, verify that nginx is running:
+-->
在 shell 中，确认 nginx 还在运行。
- root@two-containers:/# ps aux
-
+```
+root@two-containers:/# ps aux
+```
+<!--
+The output is similar to this:
+-->
输出类似于这样：
- USER PID ... STAT START TIME COMMAND
- root 1 ... Ss 21:12 0:00 nginx: master process nginx -g daemon off;
-
-
+```
+USER PID ... STAT START TIME COMMAND
+root 1 ... Ss 21:12 0:00 nginx: master process nginx -g daemon off;
+```
+<!--
+Recall that the debian Container created the `index.html` file in the nginx root
+directory. Use `curl` to send a GET request to the nginx server:
+-->
回忆一下，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
-
+```
+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
-
-
-
-
+```
+Hello from the debian container
+```
<!-- discussion -->
+<!--
+## Discussion
+The primary reason that Pods can have multiple containers is to support
+helper applications that assist a primary application. Typical examples of
+helper applications are data pullers, data pushers, and proxies.
+Helper and primary applications often need to communicate with each other.
+Typically this is done through a shared filesystem, as shown in this exercise,
+or through the loopback network interface, localhost. An example of this pattern is a
+web server along with a helper program that polls a Git repository for new updates.
+-->
## 讨论
-
-
-
-
-
-
-
Pod 能有多个容器的主要原因是为了支持辅助应用（helper applications），以协助主应用（primary application）。
辅助应用的典型例子是数据抽取，数据推送和代理。辅助应用和主应用经常需要相互通信。
就如这个练习所示，通信通常是通过共享文件系统完成的，或者，也通过回环网络接口 localhost 完成。
举个网络接口的例子，web 服务器带有一个协助程序用于拉取 Git 仓库的更新。
-
-
-
+<!--
+The Volume in this exercise provides a way for Containers to communicate during
+the life of the Pod. If the Pod is deleted and recreated, any data stored in
+the shared Volume is lost.
+-->
在本练习中的卷为 Pod 生命周期中的容器相互通信提供了一种方法。如果 Pod 被删除或者重建了，
任何共享卷中的数据都会丢失。
-
-
-
## {{% heading "whatsnext" %}}
-
-
-
-* 更多学习内容
-[混合容器的方式](http://kubernetes.io/blog/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).
-
-
-
-
+<!--
+* Learn more about [patterns for composite containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns).
+* Learn about [composite containers for modular architecture](https://www.slideshare.net/Docker/slideshare-burns).
+* See [Configuring a Pod to Use a Volume for Storage](/docs/tasks/configure-pod-container/configure-volume-storage/).
+* See [Configure a Pod to share process namespace between containers in a Pod](/docs/tasks/configure-pod-container/share-process-namespace/)
+* See [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core).
+* See [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core).
+-->
+* 进一步了解[复合容器的模式](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns.html)
+* 学习[模块化架构中的复合容器](https://www.slideshare.net/Docker/slideshare-burns)
+* 参见[配置 Pod 使用卷来存储数据](/zh/docs/tasks/configure-pod-container/configure-volume-storage/)
+* 参考 [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)
+* 参考 [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
diff --git a/content/zh/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/content/zh/docs/tasks/access-application-cluster/connecting-frontend-backend.md
index 2c91610128..f66cd77124 100644
--- a/content/zh/docs/tasks/access-application-cluster/connecting-frontend-backend.md
+++ b/content/zh/docs/tasks/access-application-cluster/connecting-frontend-backend.md
@@ -1,67 +1,85 @@
---
title: 使用 Service 把前端连接到后端
content_type: tutorial
+weight: 70
---
-
<!-- overview -->
-
-
+<!--
+This task shows how to create a frontend and a backend
+microservice. The backend microservice is a hello greeter. The
+frontend and backend are connected using a Kubernetes
+{{< glossary_tooltip term_id="service" >}} object.
+-->
本任务会描述如何创建前端微服务和后端微服务。后端微服务是一个 hello 欢迎程序。
-前端和后端的连接是通过 Kubernetes 服务对象（Service object）完成的。
-
-
-
+前端和后端的连接是通过 Kubernetes {{< glossary_tooltip term_id="service" text="服务" >}}
+完成的。
## {{% heading "objectives" %}}
-
-
-
-
+<!--
+* Create and run a microservice using a {{< glossary_tooltip term_id="deployment" >}} object.
+* Route traffic to the backend using a frontend.
+* Use a Service object to connect the frontend application to the
+ backend application.
+-->
* 使用部署对象（Deployment object）创建并运行一个微服务
* 从后端将流量路由到前端
* 使用服务对象把前端应用连接到后端应用
-
-
-
## {{% heading "prerequisites" %}}
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
-* 本任务使用 [外部负载均衡服务](/docs/tasks/access-application-cluster/create-external-load-balancer/)，
- 所以需要对应的可支持此功能的环境。如果你的环境不能支持，你可以使用
- [NodePort](/docs/user-guide/services/#type-nodeport) 类型的服务代替。
-
-
+<!--
+This task uses
+[Services with external load balancers](/docs/tasks/access-application-cluster/create-external-load-balancer/), which
+require a supported environment. If your environment does not support this, you can use a Service of type
+[NodePort](/docs/concepts/services-networking/service/#nodeport) instead.
+-->
+本任务使用 [外部负载均衡服务](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/)，
+所以需要对应的可支持此功能的环境。如果你的环境不能支持，你可以使用
+[NodePort](/zh/docs/concepts/services-networking/service/#nodeport)
+类型的服务代替。
<!-- lessoncontent -->
+<!--
+## Creating the backend using a Deployment
+The backend is a simple hello greeter microservice. Here is the configuration
+file for the backend Deployment:
+-->
### 使用部署对象（Deployment）创建后端
后端是一个简单的 hello 欢迎微服务应用。这是后端应用的 Deployment 配置文件：
{{< codenew file="service/access/hello.yaml" >}}
+<!--
+Create the backend Deployment:
+-->
创建后端 Deployment：
```shell
kubectl apply -f https://k8s.io/examples/service/access/hello.yaml
```
+<!--
+View information about the backend Deployment:
+-->
查看后端的 Deployment 信息：
```
kubectl describe deployment hello
```
+<!--
+The output is similar to this:
+-->
输出类似于：
```
@@ -71,45 +89,88 @@ CreationTimestamp: Mon, 24 Oct 2016 14:21:02 -0700
Labels: app=hello
tier=backend
track=stable
+Annotations: deployment.kubernetes.io/revision=1
Selector: app=hello,tier=backend,track=stable
-Replicas: 7 updated | 7 total | 7 available | 0 unavailable
+Replicas: 7 desired | 7 updated | 7 total | 7 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 1 max surge
+Pod Template:
+ Labels: app=hello
+ tier=backend
+ track=stable
+ Containers:
+ hello:
+ Image: "gcr.io/google-samples/hello-go-gke:1.0"
+ Port: 80/TCP
+ Environment: <none>
+ Mounts: <none>
+ Volumes: <none>
+Conditions:
+ Type Status Reason
+ ---- ------ ------
+ Available True MinimumReplicasAvailable
+ Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: hello-3621623197 (7/7 replicas created)
Events:
...
```
+<!--
+## Creating the backend Service object
-### 创建后端服务对象（Service object）
+The key to connecting a frontend to a backend is the backend
+Service. A Service creates a persistent IP address and DNS name entry
+so that the backend microservice can always be reached. A Service uses
+{{< glossary_tooltip text="selectors" term_id="selector" >}} to find
+the Pods that it routes traffic to.
+First, explore the Service configuration file:
+-->
+### 创建后端服务对象
-
-
-
-前端连接到后端的关键是 Service。Service 创建一个固定 IP 和 DNS 解析名入口，
-使得后端微服务可达。Service 使用 selector 标签来寻找目标 Pod。
-
+前端连接到后端的关键是 Service（服务）。Service 创建一个固定 IP 和 DNS 解析名入口，
+使得后端微服务可达。Service 使用
+{{< glossary_tooltip text="选择算符" term_id="selector" >}}
+来寻找目标 Pod。
首先，浏览 Service 的配置文件：
{{< codenew file="service/access/hello-service.yaml" >}}
-
+<!--
+In the configuration file, you can see that the Service routes traffic to Pods
+that have the labels `app: hello` and `tier: backend`.
+-->
配置文件中，你可以看到 Service 将流量路由到包含 `app: hello` 和 `tier: backend` 标签的 Pod。
-
+<!--
+Create the `hello` Service:
+-->
创建 `hello` Service：
```shell
kubectl apply -f https://k8s.io/examples/service/access/hello-service.yaml
```
+<!--
+At this point, you have a backend Deployment running, and you have a
+Service that can route traffic to it.
+-->
此时，你已经有了一个在运行的后端 Deployment，你也有了一个 Service 用于路由网络流量。
+<!--
+## Creating the frontend
+Now that you have your backend, you can create a frontend that connects to the backend.
+The frontend connects to the backend worker Pods by using the DNS name
+given to the backend Service. The DNS name is "hello", which is the value
+of the `name` field in the preceding Service configuration file.
+
+The Pods in the frontend Deployment run an nginx image that is configured
+to find the hello backend Service. Here is the nginx configuration file:
+-->
### 创建前端应用
既然你已经有了后端应用，你可以创建一个前端应用连接到后端。前端应用通过 DNS 名连接到后端的工作 Pods。
@@ -120,35 +181,68 @@ DNS 名是 "hello"，也就是 Service 配置文件中 `name` 字段的值。
{{< codenew file="service/access/frontend.conf" >}}
+<!--
+Similar to the backend, the frontend has a Deployment and a Service. The
+configuration for the Service has `type: LoadBalancer`, which means that
+the Service uses the default load balancer of your cloud provider.
+-->
与后端类似，前端用包含一个 Deployment 和一个 Service。Service 的配置文件包含了 `type: LoadBalancer`，
也就是说，Service 会使用你的云服务商的默认负载均衡设备。
{{< codenew file="service/access/frontend.yaml" >}}
+<!--
+Create the frontend Deployment and Service:
+-->
创建前端 Deployment 和 Service：
```shell
kubectl apply -f https://k8s.io/examples/service/access/frontend.yaml
```
+<!--
+The output verifies that both resources were created:
+-->
通过输出确认两个资源都已经被创建：
```
-deployment "frontend" created
-service "frontend" created
+deployment.apps/frontend created
+service/frontend created
```
-**注意**：这个 nginx 配置文件是被打包在 [容器镜像](/docs/tasks/access-application-cluster/frontend/Dockerfile) 里的。
-更好的方法是使用 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)，这样的话你可以更轻易地更改配置。
+<!--
+The nginx configuration is baked into the
+[container image](/examples/service/access/Dockerfile). A better way to do this would
+be to use a
+[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/),
+so that you can change the configuration more easily.
+-->
+{{< note >}}
+这个 nginx 配置文件是被打包在
+[容器镜像](/examples/service/access/Dockerfile) 里的。
+更好的方法是使用
+[ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)，
+这样的话你可以更轻易地更改配置。
+{{< /note >}}
+<!--
+## Interact with the frontend Service
+
+Once you’ve created a Service of type LoadBalancer, you can use this
+command to find the external IP:
+-->
### 与前端 Service 交互
一旦你创建了 LoadBalancer 类型的 Service，你可以使用这条命令查看外部 IP：
-```
+```shell
kubectl get service frontend
```
+<!--
+This displays the configuration for the `frontend` Service and watches for
+changes. Initially, the external IP is listed as `<pending>`:
+-->
外部 IP 字段的生成可能需要一些时间。如果是这种情况，外部 IP 会显示为 `<pending>`。
```
@@ -156,43 +250,72 @@ NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend 10.51.252.116 <pending> 80/TCP 10s
```
-
-使用相同的命令直到它显示外部 IP 地址：
+<!--
+As soon as an external IP is provisioned, however, the configuration updates
+to include the new IP under the `EXTERNAL-IP` heading:
+-->
+当外部 IP 地址被分配可用时，配置会更新，在 `EXTERNAL-IP` 头部下显示新的 IP：
```
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend 10.51.252.116 XXX.XXX.XXX.XXX 80/TCP 1m
```
+<!--
+That IP can now be used to interact with the `frontend` service from outside the
+cluster.
+-->
+这一新的 IP 地址就可以用来从集群外与 `frontend` 服务交互了。
+
+<!--
+## Send traffic through the frontend
+
+The frontend and backends are now connected. You can hit the endpoint
+by using the curl command on the external IP of your frontend Service.
+-->
### 通过前端发送流量
-
-
前端和后端已经完成连接了。你可以使用 curl 命令通过你的前端 Service 的外部 IP 访问服务端点。
-```
+```shell
curl http://<EXTERNAL-IP>
```
-
+<!--
+The output shows the message generated by the backend:
+-->
后端生成的消息输出如下：
-```
+```json
{"message":"Hello"}
```
+## {{% heading "cleanup" %}}
+<!--
+To delete the Services, enter this command:
+-->
+要删除服务，输入下面的命令：
+```shell
+kubectl delete services frontend hello
+```
+<!--
+To delete the Deployments, the ReplicaSets and the Pods that are running the backend and frontend applications, enter this command:
+-->
+要删除在前端和后端应用中运行的 Deployment、ReplicaSet 和 Pod，输入下面的命令：
+
+```shell
+kubectl delete deployment frontend hello
+```
## {{% heading "whatsnext" %}}
-
-
-
-* 了解更多 [Services](/docs/concepts/services-networking/service/)
-* 了解更多 [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)
-
-
-
+<!--
+* Learn more about [Services](/docs/concepts/services-networking/service/)
+* Learn more about [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/)
+-->
+* 进一步了解[Service](/zh/docs/concepts/services-networking/service/)
+* 进一步了解[ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)
diff --git a/content/zh/docs/tasks/access-application-cluster/create-external-load-balancer.md b/content/zh/docs/tasks/access-application-cluster/create-external-load-balancer.md
index d6887556e2..75fe4b6e13 100644
--- a/content/zh/docs/tasks/access-application-cluster/create-external-load-balancer.md
+++ b/content/zh/docs/tasks/access-application-cluster/create-external-load-balancer.md
@@ -1,15 +1,13 @@
---
-title: 创建一个外部负载均衡器
+title: 创建外部负载均衡器
content_type: task
weight: 80
---
<!--
----
title: Create an External Load Balancer
content_type: task
weight: 80
----
-->
<!-- overview -->
@@ -19,10 +17,10 @@ This page shows how to create an External Load Balancer.
-->
本文展示如何创建一个外部负载均衡器。
-{{< note >}}
<!--
This feature is only available for cloud providers or environments which support external load balancers.
-->
+{{< note >}}
此功能仅适用于支持外部负载均衡器的云提供商或环境。
{{< /note >}}
@@ -33,7 +31,9 @@ that sends traffic to the correct port on your cluster nodes
_provided your cluster runs in a supported environment and is configured with
the correct cloud load balancer provider package_.
-->
-创建服务时，您可以选择自动创建云网络负载均衡器。这提供了一个外部可访问的 IP 地址，可将流量分配到集群节点上的正确端口上 _假设集群在支持的环境中运行，并配置了正确的云负载平衡器提供商包_。
+创建服务时，你可以选择自动创建云网络负载均衡器。这提供了一个外部可访问的 IP 地址，
+可将流量分配到集群节点上的正确端口上
+（ _假设集群在支持的环境中运行，并配置了正确的云负载平衡器提供商包_）。
<!--
For information on provisioning and using an Ingress resource that can give
@@ -41,17 +41,13 @@ services externally-reachable URLs, load balance the traffic, terminate SSL etc.
please check the [Ingress](/docs/concepts/services-networking/ingress/)
documentation.
-->
-有关如何配置和使用 Ingress 资源为服务提供外部可访问的 URL、负载均衡流量、终止 SSL 等功能，请查看 [Ingress](/docs/concepts/services-networking/ingress/) 文档。
-
-
+有关如何配置和使用 Ingress 资源为服务提供外部可访问的 URL、负载均衡流量、终止 SSL 等功能，
+请查看 [Ingress](/zh/docs/concepts/services-networking/ingress/) 文档。
## {{% heading "prerequisites" %}}
-
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
<!-- steps -->
<!--
@@ -62,7 +58,8 @@ To create an external load balancer, add the following line to your
-->
## 配置文件
-要创建外部负载均衡器，请将以下内容添加到 [服务配置文件](/docs/concepts/services-networking/service/#loadbalancer)：
+要创建外部负载均衡器，请将以下内容添加到
+[服务配置文件](/zh/docs/concepts/services-networking/service/#loadbalancer)：
```yaml
type: LoadBalancer
@@ -71,7 +68,7 @@ To create an external load balancer, add the following line to your
<!--
Your configuration file might look like:
-->
-您的配置文件可能会如下所示：
+你的配置文件可能会如下所示：
```yaml
apiVersion: v1
@@ -95,7 +92,7 @@ its `--type=LoadBalancer` flag:
-->
## 使用 kubectl
-您也可以使用 `kubectl expose` 命令及其 `--type=LoadBalancer` 参数创建服务：
+你也可以使用 `kubectl expose` 命令及其 `--type=LoadBalancer` 参数创建服务：
```bash
kubectl expose rc example --port=8765 --target-port=9376 \
@@ -112,7 +109,8 @@ For more information, including optional flags, refer to the
-->
此命令通过使用与引用资源（在上面的示例的情况下，名为 `example` 的 replication controller）相同的选择器来创建一个新的服务。
-更多信息（包括更多的可选参数），请参阅 [`kubectl expose` reference](/docs/reference/generated/kubectl/kubectl-commands/#expose)。
+更多信息（包括更多的可选参数），请参阅
+[`kubectl expose` 指南](/docs/reference/generated/kubectl/kubectl-commands/#expose)。
<!--
## Finding your IP address
@@ -120,9 +118,9 @@ For more information, including optional flags, refer to the
You can find the IP address created for your service by getting the service
information through `kubectl`:
-->
-## 找到您的 IP 地址
+## 找到你的 IP 地址
-您可以通过 `kubectl` 获取服务信息，找到为您的服务创建的 IP 地址：
+你可以通过 `kubectl` 获取服务信息，找到为你的服务创建的 IP 地址：
```bash
kubectl describe services example-service
@@ -154,28 +152,29 @@ The IP address is listed next to `LoadBalancer Ingress`.
-->
IP 地址列在 `LoadBalancer Ingress` 旁边。
-{{< note >}}
<!--
If you are running your service on Minikube, you can find the assigned IP address and port with:
-->
-**注意：** 如果您在 Minikube 上运行服务，您可以通过以下命令找到分配的 IP 地址和端口：
-{{< /note >}}
+{{< note >}}
+如果你在 Minikube 上运行服务，你可以通过以下命令找到分配的 IP 地址和端口：
+
```bash
minikube service example-service --url
```
+{{< /note >}}
<!--
## Preserving the client source IP
--->
-## 保留客户端源 IP
-<!--
Due to the implementation of this feature, the source IP seen in the target
container is *not the original source IP* of the client. To enable
preservation of the client IP, the following fields can be configured in the
service spec (supported in GCE/Google Kubernetes Engine environments):
-->
-由于此功能的实现，目标容器中看到的源 IP 将 *不是客户端的原始源 IP*。要启用保留客户端 IP，可以在服务的 spec 中配置以下字段（支持 GCE/Google Kubernetes Engine 环境）：
+## 保留客户端源 IP
+
+由于此功能的实现，目标容器中看到的源 IP 将 *不是客户端的原始源 IP*。
+要启用保留客户端 IP，可以在服务的 spec 中配置以下字段（支持 GCE/Google Kubernetes Engine 环境）：
<!--
* `service.spec.externalTrafficPolicy` - denotes if this Service desires to route
@@ -186,7 +185,11 @@ load-spreading. Local preserves the client source IP and avoids a second hop
for LoadBalancer and NodePort type services, but risks potentially imbalanced
traffic spreading.
-->
-* `service.spec.externalTrafficPolicy` - 表示此服务是否希望将外部流量路由到节点本地或集群范围的端点。有两个可用选项：Cluster（默认）和 Local。Cluster 隐藏了客户端源 IP，可能导致第二跳到另一个节点，但具有良好的整体负载分布。Local 保留客户端源 IP 并避免 LoadBalancer 和 NodePort 类型服务的第二跳，但存在潜在的不均衡流量传播风险。
+* `service.spec.externalTrafficPolicy` - 表示此服务是否希望将外部流量路由到节点本地或集群范围的端点。
+ 有两个可用选项：Cluster（默认）和 Local。
+ Cluster 隐藏了客户端源 IP，可能导致第二跳到另一个节点，但具有良好的整体负载分布。
+ Local 保留客户端源 IP 并避免 LoadBalancer 和 NodePort 类型服务的第二跳，
+ 但存在潜在的不均衡流量传播风险。
<!--
* `service.spec.healthCheckNodePort` - specifies the health check nodePort
@@ -198,8 +201,11 @@ user-specified `healthCheckNodePort` value if specified by the client. It only h
effect when `type` is set to LoadBalancer and `externalTrafficPolicy` is set
to Local.
-->
-
-* `service.spec.healthCheckNodePort` - 指定服务的 healthcheck nodePort（数字端口号）。如果未指定 `healthCheckNodePort`，服务控制器从集群的 NodePort 范围内分配一个端口。您可以通过设置 API 服务器的命令行选项 `--service-node-port-range` 来配置上述范围。它将会使用用户指定的 `healthCheckNodePort` 值（如果被客户端指定）。仅当 `type` 设置为 LoadBalancer 并且 `externalTrafficPolicy` 设置为 Local 时才生效。
+* `service.spec.healthCheckNodePort` - 指定服务的 healthcheck nodePort（数字端口号）。
+ 如果未指定 `healthCheckNodePort`，服务控制器从集群的 NodePort 范围内分配一个端口。
+ 你可以通过设置 API 服务器的命令行选项 `--service-node-port-range` 来配置上述范围。
+ 它将会使用用户指定的 `healthCheckNodePort` 值（如果被客户端指定）。
+ 仅当 `type` 设置为 LoadBalancer 并且 `externalTrafficPolicy` 设置为 Local 时才生效。
<!--
Setting `externalTrafficPolicy` to Local in the Service configuration file
@@ -224,10 +230,7 @@ spec:
<!--
## Garbage Collecting Load Balancers
--->
-## 垃圾收集负载均衡器
-<!--
In usual case, the correlating load balancer resources in cloud provider should
be cleaned up soon after a LoadBalancer type Service is deleted. But it is known
that there are various corner cases where cloud resources are orphaned after the
@@ -235,7 +238,12 @@ associated Service is deleted. Finalizer Protection for Service LoadBalancers wa
introduced to prevent this from happening. By using finalizers, a Service resource
will never be deleted until the correlating load balancer resources are also deleted.
-->
-在通常情况下，应在删除 LoadBalancer 类型服务后立即清除云提供商中的相关负载均衡器资源。但是，众所周知，在删除关联的服务后，云资源被孤立的情况很多。引入了针对服务负载均衡器的终结器保护，以防止这种情况发生。通过使用终结器，在删除相关的负载均衡器资源之前，也不会删除服务资源。
+## 回收负载均衡器
+
+在通常情况下，应在删除 LoadBalancer 类型服务后立即清除云提供商中的相关负载均衡器资源。
+但是，众所周知，在删除关联的服务后，云资源被孤立的情况很多。
+引入了针对服务负载均衡器的终结器保护，以防止这种情况发生。
+通过使用终结器，在删除相关的负载均衡器资源之前，也不会删除服务资源。
<!--
Specifically, if a Service has `type` LoadBalancer, the service controller will attach
@@ -244,25 +252,18 @@ The finalizer will only be removed after the load balancer resource is cleaned u
This prevents dangling load balancer resources even in corner cases such as the
service controller crashing.
-->
-具体来说，如果服务具有 `type` LoadBalancer，则服务控制器将附加一个名为 `service.kubernetes.io/load-balancer-cleanup` 的终结器。
+具体来说，如果服务具有 `type` LoadBalancer，则服务控制器将附加一个名为
+`service.kubernetes.io/load-balancer-cleanup` 的终结器。
仅在清除负载均衡器资源后才能删除终结器。
即使在诸如服务控制器崩溃之类的极端情况下，这也可以防止负载均衡器资源悬空。
-<!--
-This feature is beta and enabled by default since Kubernetes v1.16. You can also
-enable it in v1.15 (alpha) via the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
-`ServiceLoadBalancerFinalizer`.
--->
-自 Kubernetes v1.16 起，此功能为 beta 版本并默认启用。您也可以通过[功能开关](/docs/reference/command-line-tools-reference/feature-gates/)`ServiceLoadBalancerFinalizer` 在 v1.15 （alpha）中启用它。
-
<!--
## External Load Balancer Providers
+
+It is important to note that the datapath for this functionality is provided by a load balancer external to the Kubernetes cluster.
-->
## 外部负载均衡器提供商
-<!--
-It is important to note that the datapath for this functionality is provided by a load balancer external to the Kubernetes cluster.
--->
请务必注意，此功能的数据路径由 Kubernetes 集群外部的负载均衡器提供。
<!--
@@ -272,7 +273,11 @@ pods. The Kubernetes service controller automates the creation of the external l
firewall rules (if needed) and retrieves the external IP allocated by the cloud provider and populates it in the service
object.
-->
-当服务 `type` 设置为 LoadBalancer 时，Kubernetes 向集群中的 pod 提供的功能等同于 `type` 等于 ClusterIP，并通过使用 Kubernetes pod 的条目对负载均衡器（从外部到 Kubernetes）进行编程来扩展它。 Kubernetes 服务控制器自动创建外部负载均衡器、健康检查（如果需要）、防火墙规则（如果需要），并获取云提供商分配的外部 IP 并将其填充到服务对象中。
+当服务 `type` 设置为 LoadBalancer 时，Kubernetes 向集群中的 Pod 提供的功能等同于
+`type` 等于 ClusterIP，并通过使用 Kubernetes pod 的条目对负载均衡器（从外部到 Kubernetes）
+进行编程来扩展它。
+Kubernetes 服务控制器自动创建外部负载均衡器、健康检查（如果需要）、防火墙规则（如果需要），
+并获取云提供商分配的外部 IP 并将其填充到服务对象中。
<!--
## Caveats and Limitations when preserving source IPs
@@ -282,7 +287,8 @@ kube-proxy rules which would correctly balance across all endpoints.
-->
## 保留源 IP 时的注意事项和限制
-GCE/AWS 负载均衡器不为其目标池提供权重。对于旧的 LB kube-proxy 规则来说，这不是一个问题，它可以在所有端点之间正确平衡。
+GCE/AWS 负载均衡器不为其目标池提供权重。
+对于旧的 LB kube-proxy 规则来说，这不是一个问题，它可以在所有端点之间正确平衡。
<!--
With the new functionality, the external traffic is not equally load balanced across pods, but rather
@@ -290,13 +296,16 @@ equally balanced at the node level (because GCE/AWS and other external LB implem
for specifying the weight per node, they balance equally across all target nodes, disregarding the number of
pods on each node).
-->
-使用新功能，外部流量不会在 pod 之间平均负载，而是在节点级别平均负载（因为 GCE/AWS 和其他外部 LB 实现无法指定每个节点的权重，因此它们的平衡跨所有目标节点，并忽略每个节点上的 pod 数量）。
+使用新功能，外部流量不会在 pod 之间平均负载，而是在节点级别平均负载
+（因为 GCE/AWS 和其他外部 LB 实现无法指定每个节点的权重，
+因此它们的平衡跨所有目标节点，并忽略每个节点上的 Pod 数量）。
<!--
We can, however, state that for NumServicePods << NumNodes or NumServicePods >> NumNodes, a fairly close-to-equal
distribution will be seen, even without weights.
-->
-但是，我们可以声明，对于 NumServicePods << NumNodes 或 NumServicePods >> NumNodes 时，即使没有权重，也会看到接近相等的分布。
+但是，我们可以声明，对于 `NumServicePods << NumNodes` 或 `NumServicePods >> NumNodes` 时，
+即使没有权重，也会看到接近相等的分布。
<!--
Once the external load balancers provide weights, this functionality can be added to the LB programming path.
@@ -307,6 +316,5 @@ Internal pod to pod traffic should behave similar to ClusterIP services, with eq
一旦外部负载平衡器提供权重，就可以将此功能添加到 LB 编程路径中。
*未来工作：1.4 版本不提供权重支持，但可能会在将来版本中添加*
-内部 pod 到 pod 的流量应该与 ClusterIP 服务类似，所有 pod 的概率相同。
-
+内部 Pod 到 Pod 的流量应该与 ClusterIP 服务类似，所有 Pod 的概率相同。
diff --git a/content/zh/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/zh/docs/tasks/access-application-cluster/list-all-running-container-images.md
index ebc5dfdc9c..3b1aed6bcb 100644
--- a/content/zh/docs/tasks/access-application-cluster/list-all-running-container-images.md
+++ b/content/zh/docs/tasks/access-application-cluster/list-all-running-container-images.md
@@ -5,11 +5,9 @@ weight: 100
---
<!--
----
title: List All Container Images Running in a Cluster
content_type: task
weight: 100
----
-->
<!-- overview -->
@@ -18,17 +16,12 @@ weight: 100
This page shows how to use kubectl to list all of the Container images
for Pods running in a cluster.
-->
-本文展示如何使用 kubectl 来列出集群中所有运行 pod 的容器的镜像
-
-
+本文展示如何使用 kubectl 来列出集群中所有运行 Pod 的容器的镜像
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
<!-- steps -->
<!--
@@ -36,7 +29,7 @@ In this exercise you will use kubectl to fetch all of the Pods
running in a cluster, and format the output to pull out the list
of Containers for each.
-->
-在本练习中，您将使用 kubectl 来获取集群中运行的所有 Pod，并格式化输出来提取每个 pod 中的容器列表。
+在本练习中，你将使用 kubectl 来获取集群中运行的所有 Pod，并格式化输出来提取每个 Pod 中的容器列表。
<!--
## List all Containers in all namespaces
@@ -57,13 +50,14 @@ of Containers for each.
- 使用 `kubectl get pods --all-namespaces` 获取所有命名空间下的所有 Pod
- 使用 `-o jsonpath={..image}` 来格式化输出，以仅包含容器镜像名称。
这将以递归方式从返回的 json 中解析出 `image` 字段。
- - 参阅 [jsonpath reference](/docs/user-guide/jsonpath/) 来获取更多关于如何使用 jsonpath 的信息。
+ - 参阅 [jsonpath 说明](/zh/docs/reference/kubectl/jsonpath/)
+ 获取更多关于如何使用 jsonpath 的信息。
- 使用标准化工具来格式化输出：`tr`, `sort`, `uniq`
- 使用 `tr` 以用换行符替换空格
- 使用 `sort` 来对结果进行排序
- 使用 `uniq` 来聚合镜像计数
-```sh
+```shell
kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
tr -s '[[:space:]]' '\n' |\
sort |\
@@ -83,7 +77,7 @@ e.g. many fields are called `name` within a given item:
作为替代方案，可以使用 Pod 的镜像字段的绝对路径。这确保即使字段名称重复的情况下也能检索到正确的字段，例如，特定项目中的许多字段都称为 `name`：
-```sh
+```shell
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}"
```
@@ -102,13 +96,14 @@ jsonpath 解释如下：
- `.containers[*]`: 对于每个容器
- `.image`: 获取镜像
-{{< note >}}
<!--
When fetching a single Pod by name, e.g. `kubectl get pod nginx`,
the `.items[*]` portion of the path should be omitted because a single
Pod is returned instead of a list of items.
-->
-**注意：** 按名字获取单个 Pod 时，例如 `kubectl get pod nginx`，路径的 `.items[*]` 部分应该省略，因为返回的是一个 Pod 而不是一个项目列表。
+{{< note >}}
+按名字获取单个 Pod 时，例如 `kubectl get pod nginx`，路径的 `.items[*]` 部分应该省略，
+因为返回的是一个 Pod 而不是一个项目列表。
{{< /note >}}
<!--
@@ -121,7 +116,7 @@ iterate over elements individually.
可以使用 `range` 操作进一步控制格式化，以单独操作每个元素。
-```sh
+```shell
kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
sort
```
@@ -132,11 +127,11 @@ sort
To target only Pods matching a specific label, use the -l flag. The
following matches only Pods with labels matching `app=nginx`.
-->
-## 列出以 label 过滤后的 Pod 的所有容器
+## 列出以标签过滤后的 Pod 的所有容器
要获取匹配特定标签的 Pod，请使用 -l 参数。以下匹配仅与标签 `app=nginx` 相符的 Pod。
-```sh
+```shell
kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx
```
@@ -150,7 +145,7 @@ following matches only Pods in the `kube-system` namespace.
要获取匹配特定命名空间的 Pod，请使用 namespace 参数。以下仅匹配 `kube-system` 命名空间下的 Pod。
-```sh
+```shell
kubectl get pods --namespace kube-system -o jsonpath="{..image}"
```
@@ -164,33 +159,20 @@ for formatting the output:
作为 jsonpath 的替代，Kubectl 支持使用 [go-templates](https://golang.org/pkg/text/template/) 来格式化输出：
-
-```sh
+```shell
kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}"
```
-
-
-
-
-<!-- discussion -->
-
-
-
## {{% heading "whatsnext" %}}
-
<!--
### Reference
-* [Jsonpath](/docs/user-guide/jsonpath/) reference guide
+* [Jsonpath](/docs/reference/kubectl/jsonpath/) reference guide
* [Go template](https://golang.org/pkg/text/template/) reference guide
-->
### 参考
-* [Jsonpath](/docs/user-guide/jsonpath/) 参考指南
+* [Jsonpath](/zh/docs/reference/kubectl/jsonpath/) 参考指南
* [Go template](https://golang.org/pkg/text/template/) 参考指南
-
-
-
diff --git a/content/zh/docs/tasks/access-application-cluster/service-access-application-cluster.md b/content/zh/docs/tasks/access-application-cluster/service-access-application-cluster.md
index 454773b100..b5a7084a46 100644
--- a/content/zh/docs/tasks/access-application-cluster/service-access-application-cluster.md
+++ b/content/zh/docs/tasks/access-application-cluster/service-access-application-cluster.md
@@ -5,11 +5,9 @@ weight: 60
---
<!--
----
title: Use a Service to Access an Application in a Cluster
content_type: tutorial
weight: 60
----
-->
<!-- overview -->
@@ -19,22 +17,15 @@ This page shows how to create a Kubernetes Service object that external
clients can use to access an application running in a cluster. The Service
provides load balancing for an application that has two running instances.
-->
-本文展示如何创建一个 Kubernetes 服务对象，能让外部客户端访问在集群中运行的应用。该服务为一个应用的两个运行实例提供负载均衡。
-
-
-
+本文展示如何创建一个 Kubernetes 服务对象，能让外部客户端访问在集群中运行的应用。
+该服务为一个应用的两个运行实例提供负载均衡。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
-
## {{% heading "objectives" %}}
-
<!--
* Run two instances of a Hello World application.
* Create a Service object that exposes a node port.
@@ -44,9 +35,6 @@ provides load balancing for an application that has two running instances.
* 创建一个服务对象来暴露 node port。
* 使用服务对象来访问正在运行的应用。
-
-
-
<!-- lessoncontent -->
<!--
@@ -59,6 +47,7 @@ Here is the configuration file for the application Deployment:
这是应用程序部署的配置文件：
{{< codenew file="service/access/hello-application.yaml" >}}
+
<!--
1. Run a Hello World application in your cluster:
Create the application Deployment using the file above:
@@ -74,17 +63,23 @@ Here is the configuration file for the application Deployment:
each of which runs the Hello World application.
-->
-1. 在您的集群中运行一个 Hello World 应用：
+1. 在你的集群中运行一个 Hello World 应用：
使用上面的文件创建应用程序 Deployment：
+
```shell
kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml
```
- 上面的命令创建一个 [Deployment](/docs/concepts/workloads/controllers/deployment/) 对象和一个关联的 [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) 对象。这个 ReplicaSet 有两个 [Pod](/docs/concepts/workloads/pods/pod/)，每个 Pod 都运行着 Hello World 应用。
+
+ 上面的命令创建一个 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 对象
+ 和一个关联的 [ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) 对象。
+ 这个 ReplicaSet 有两个 [Pod](/zh/docs/concepts/workloads/pods/)，
+ 每个 Pod 都运行着 Hello World 应用。
<!--
1. Display information about the Deployment:
-->
-1. 展示 Deployment 的信息：
+2. 展示 Deployment 的信息：
+
```shell
kubectl get deployments hello-world
kubectl describe deployments hello-world
@@ -93,7 +88,8 @@ Here is the configuration file for the application Deployment:
<!--
1. Display information about your ReplicaSet objects:
-->
-1. 展示您的 ReplicaSet 对象信息：
+3. 展示你的 ReplicaSet 对象信息：
+
```shell
kubectl get replicasets
kubectl describe replicasets
@@ -102,7 +98,8 @@ Here is the configuration file for the application Deployment:
<!--
1. Create a Service object that exposes the deployment:
-->
-1. 创建一个服务对象来暴露 deployment：
+4. 创建一个服务对象来暴露 Deployment：
+
```shell
kubectl expose deployment hello-world --type=NodePort --name=example-service
```
@@ -110,14 +107,17 @@ Here is the configuration file for the application Deployment:
<!--
1. Display information about the Service:
-->
-1. 展示服务信息：
+5. 展示 Service 信息：
+
```shell
kubectl describe services example-service
```
-<!--
+
+ <!--
The output is similar to this:
--->
+ -->
输出类似于：
+
```shell
Name: example-service
Namespace: default
@@ -133,23 +133,27 @@ Here is the configuration file for the application Deployment:
Session Affinity: None
Events: <none>
```
-<!--
+
+ <!--
Make a note of the NodePort value for the service. For example,
in the preceding output, the NodePort value is 31496.
--->
+ -->
注意服务中的 NodePort 值。例如在上面的输出中，NodePort 是 31496。
<!--
1. List the pods that are running the Hello World application:
-->
-1. 列出运行 Hello World 应用的 pod：
+7. 列出运行 Hello World 应用的 Pod：
+
```shell
kubectl get pods --selector="run=load-balancer-example" --output=wide
```
-<!--
+
+ <!--
The output is similar to this:
--->
+ -->
输出类似于：
+
```shell
NAME READY STATUS ... IP NODE
hello-world-2895499144-bsbk5 1/1 Running ... 10.200.1.4 worker1
@@ -171,25 +175,28 @@ Here is the configuration file for the application Deployment:
1. Use the node address and node port to access the Hello World application:
-->
-1. 获取运行 Hello World 的 pod 的其中一个节点的公共 IP 地址。如何获得此地址取决于您设置集群的方式。
- 例如，如果您使用的是 Minikube，则可以通过运行 `kubectl cluster-info` 来查看节点地址。
- 如果您使用的是 Google Compute Engine 实例，则可以使用 `gcloud compute instances list` 命令查看节点的公共地址。
+8. 获取运行 Hello World 的 pod 的其中一个节点的公共 IP 地址。如何获得此地址取决于你设置集群的方式。
+ 例如，如果你使用的是 Minikube，则可以通过运行 `kubectl cluster-info` 来查看节点地址。
+ 如果你使用的是 Google Compute Engine 实例，则可以使用 `gcloud compute instances list` 命令查看节点的公共地址。
-1. 在您选择的节点上，创建一个防火墙规则以开放 node port 上的 TCP 流量。
- 例如，如果您的服务的 NodePort 值为 31568，请创建一个防火墙规则以允许 31568 端口上的 TCP 流量。
+9. 在你选择的节点上，创建一个防火墙规则以开放节点端口上的 TCP 流量。
+ 例如，如果你的服务的 NodePort 值为 31568，请创建一个防火墙规则以允许 31568 端口上的 TCP 流量。
不同的云提供商提供了不同方法来配置防火墙规则。
-1. 使用节点地址和 node port 来访问 Hello World 应用：
+10. 使用节点地址和 node port 来访问 Hello World 应用：
+
```shell
curl http://<public-node-ip>:<node-port>
```
-<!--
+
+ <!--
where `<public-node-ip>` is the public IP address of your node,
and `<node-port>` is the NodePort value for your service. The
response to a successful request is a hello message:
--->
- 这里的 `<public-node-ip>` 是您节点的公共 IP 地址，`<node-port>` 是您服务的 NodePort 值。
+ -->
+ 这里的 `<public-node-ip>` 是你节点的公共 IP 地址，`<node-port>` 是你服务的 NodePort 值。
对于请求成功的响应是一个 hello 消息：
+
```shell
Hello Kubernetes!
```
@@ -203,20 +210,19 @@ to create a Service.
-->
## 使用服务配置文件
-作为 `kubectl expose` 的替代方法，您可以使用 [服务配置文件](/docs/concepts/services-networking/service/) 来创建服务。
-
-
-
+作为 `kubectl expose` 的替代方法，你可以使用
+[服务配置文件](/zh/docs/concepts/services-networking/service/) 来创建服务。
## {{% heading "cleanup" %}}
-
<!--
To delete the Service, enter this command:
-->
想要删除服务，输入以下命令：
- kubectl delete services example-service
+```shell
+kubectl delete services example-service
+```
<!--
To delete the Deployment, the ReplicaSet, and the Pods that are running
@@ -224,17 +230,15 @@ the Hello World application, enter this command:
-->
想要删除运行 Hello World 应用的 Deployment、ReplicaSet 和 Pod，输入以下命令：
- kubectl delete deployment hello-world
-
-
-
+```shell
+kubectl delete deployment hello-world
+```
## {{% heading "whatsnext" %}}
-
<!--
Learn more about
[connecting applications with services](/docs/concepts/services-networking/connect-applications-service/).
-->
-学习更多关于如何 [通过服务连接应用](/docs/concepts/services-networking/connect-applications-service/)。
+- 进一步了解[通过服务连接应用](/zh/docs/concepts/services-networking/connect-applications-service/)。
diff --git a/content/zh/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/zh/docs/tasks/access-application-cluster/web-ui-dashboard.md
index 6096d7febe..511ef95ee7 100644
--- a/content/zh/docs/tasks/access-application-cluster/web-ui-dashboard.md
+++ b/content/zh/docs/tasks/access-application-cluster/web-ui-dashboard.md
@@ -1,18 +1,13 @@
---
-reviewers:
-- bryk
-- mikedanese
-- rf232
-title: 网页界面 (Dashboard)
+title: Web 界面 (Dashboard)
content_type: concept
weight: 10
card:
name: tasks
weight: 30
- title: 使用网页界面 Dashboard
+ title: 使用 Web 界面 Dashboard
---
<!--
----
reviewers:
- bryk
- mikedanese
@@ -24,35 +19,40 @@ card:
name: tasks
weight: 30
title: Use the Web UI Dashboard
----
-->
<!-- overview -->
<!--
-Dashboard is a web-based Kubernetes user interface. You can use Dashboard to deploy containerized applications to a Kubernetes cluster, troubleshoot your containerized application, and manage the cluster resources. You can use Dashboard to get an overview of applications running on your cluster, as well as for creating or modifying individual Kubernetes resources (such as Deployments, Jobs, DaemonSets, etc). For example, you can scale a Deployment, initiate a rolling update, restart a pod or deploy new applications using a deploy wizard.
+Dashboard is a web-based Kubernetes user interface.
+You can use Dashboard to deploy containerized applications to a Kubernetes cluster,
+troubleshoot your containerized application, and manage the cluster resources.
+You can use Dashboard to get an overview of applications running on your cluster,
+as well as for creating or modifying individual Kubernetes resources
+(such as Deployments, Jobs, DaemonSets, etc).
+For example, you can scale a Deployment, initiate a rolling update, restart a pod
+or deploy new applications using a deploy wizard.
Dashboard also provides information on the state of Kubernetes resources in your cluster and on any errors that may have occurred.
-->
-Dashboard 是基于网页的 Kubernetes 用户界面。您可以使用 Dashboard 将容器应用部署到 Kubernetes 集群中，也可以对容器应用排错，还能管理集群资源。您可以使用 Dashboard 获取运行在集群中的应用的概览信息，也可以创建或者修改 Kubernetes 资源（如 Deployment，Job，DaemonSet 等等）。例如，您可以对 Deployment 实现弹性伸缩、发起滚动升级、重启 Pod 或者使用向导创建新的应用。
+Dashboard 是基于网页的 Kubernetes 用户界面。
+你可以使用 Dashboard 将容器应用部署到 Kubernetes 集群中，也可以对容器应用排错，还能管理集群资源。
+你可以使用 Dashboard 获取运行在集群中的应用的概览信息，也可以创建或者修改 Kubernetes 资源
+（如 Deployment，Job，DaemonSet 等等）。
+例如，你可以对 Deployment 实现弹性伸缩、发起滚动升级、重启 Pod 或者使用向导创建新的应用。
Dashboard 同时展示了 Kubernetes 集群中的资源状态信息和所有报错信息。
-
-
-
<!-- body -->
<!--
## Deploying the Dashboard UI
--->
-## 部署 Dashboard UI
-<!--
The Dashboard UI is not deployed by default. To deploy it, run the following command:
-->
+## 部署 Dashboard UI
默认情况下不会部署 Dashboard。可以通过以下命令部署：
```
@@ -61,15 +61,19 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/a
<!--
## Accessing the Dashboard UI
+
+To protect your cluster data, Dashboard deploys with a minimal RBAC configuration by default.
+Currently, Dashboard only supports logging in with a Bearer Token.
+To create a token for this demo, you can follow our guide on
+[creating a sample user](https://github.com/kubernetes/dashboard/wiki/Creating-sample-user).
-->
## 访问 Dashboard UI
-<!--
-To protect your cluster data, Dashboard deploys with a minimal RBAC configuration by default. Currently, Dashboard only supports logging in with a Bearer Token. To create a token for this demo, you can follow our guide on [creating a sample user](https://github.com/kubernetes/dashboard/wiki/Creating-sample-user).
--->
-为了保护您的集群数据，默认情况下，Dashboard 会使用最少的 RBAC 配置进行部署。
+为了保护你的集群数据，默认情况下，Dashboard 会使用最少的 RBAC 配置进行部署。
当前，Dashboard 仅支持使用 Bearer 令牌登录。
-要为此样本演示创建令牌，您可以按照[创建示例用户](https://github.com/kubernetes/dashboard/wiki/Creating-sample-user)上的指南进行操作。
+要为此样本演示创建令牌，你可以按照
+[创建示例用户](https://github.com/kubernetes/dashboard/wiki/Creating-sample-user)
+上的指南进行操作。
<!--
The sample user created in the tutorial will have administrative privileges and is for educational purposes only.
@@ -80,12 +84,12 @@ The sample user created in the tutorial will have administrative privileges and
<!--
### Command line proxy
--->
-### 命令行代理
-<!--
+
You can access Dashboard using the kubectl command-line tool by running the following command:
-->
-您可以使用 kubectl 命令行工具访问 Dashboard，命令如下：
+### 命令行代理
+
+你可以使用 kubectl 命令行工具访问 Dashboard，命令如下：
```
kubectl proxy
@@ -116,7 +120,10 @@ Kubeconfig 身份验证方法不支持外部身份提供程序或基于 x509 证
<!--
When you access Dashboard on an empty cluster, you'll see the welcome page. This page contains a link to this document as well as a button to deploy your first application. In addition, you can view which system applications are running by default in the `kube-system` [namespace](/docs/tasks/administer-cluster/namespaces/) of your cluster, for example the Dashboard itself.
-->
-当访问空集群的 Dashboard 时，您会看到欢迎界面。页面包含一个指向此文档的链接，以及一个用于部署第一个应用程序的按钮。此外，您可以看到在默认情况下有哪些默认系统应用运行在 `kube-system` [命名空间](/docs/tasks/administer-cluster/namespaces/) 中，比如 Dashboard 自己。
+当访问空集群的 Dashboard 时，你会看到欢迎界面。
+页面包含一个指向此文档的链接，以及一个用于部署第一个应用程序的按钮。
+此外，你可以看到在默认情况下有哪些默认系统应用运行在 `kube-system`
+[名字空间](/zh/docs/tasks/administer-cluster/namespaces/) 中，比如 Dashboard 自己。
<!--
@@ -125,183 +132,242 @@ When you access Dashboard on an empty cluster, you'll see the welcome page. This
<!--
## Deploying containerized applications
+
+Dashboard lets you create and deploy a containerized application as a Deployment and optional Service with a simple wizard. You can either manually specify application details, or upload a YAML or JSON file containing application configuration.
-->
## 部署容器化应用
-<!--
-Dashboard lets you create and deploy a containerized application as a Deployment and optional Service with a simple wizard. You can either manually specify application details, or upload a YAML or JSON file containing application configuration.
--->
-通过一个简单的部署向导，您可以使用 Dashboard 将容器化应用作为一个 Deployment 和可选的 Service 进行创建和部署。可以手工指定应用的详细配置，或者上传一个包含应用配置的 YAML 或 JSON 文件。
+通过一个简单的部署向导，你可以使用 Dashboard 将容器化应用作为一个 Deployment 和可选的 Service 进行创建和部署。可以手工指定应用的详细配置，或者上传一个包含应用配置的 YAML 或 JSON 文件。
<!--
Click the **CREATE** button in the upper right corner of any page to begin.
-->
-点击任何页面右上角的 **创建** 按钮以开始。
+点击任何页面右上角的 **CREATE** 按钮以开始。
<!--
### Specifying application details
+
+The deploy wizard expects that you provide the following information:
-->
### 指定应用的详细配置
-<!--
-The deploy wizard expects that you provide the following information:
--->
-部署向导需要您提供以下信息：
+部署向导需要你提供以下信息：
<!--
- **App name** (mandatory): Name for your application. A [label](/docs/concepts/overview/working-with-objects/labels/) with the name will be added to the Deployment and Service, if any, that will be deployed.
-->
-- **应用名称**（必填）：应用的名称。内容为`应用名称`的[标签](/docs/concepts/overview/working-with-objects/labels/) 会被添加到任何将被部署的 Deployment 和 Service。
+- **应用名称**（必填）：应用的名称。内容为`应用名称`的
+ [标签](/zh/docs/concepts/overview/working-with-objects/labels/)
+ 会被添加到任何将被部署的 Deployment 和 Service。
-<!--
+ <!--
The application name must be unique within the selected Kubernetes [namespace](/docs/tasks/administer-cluster/namespaces/). It must start with a lowercase character, and end with a lowercase character or a number, and contain only lowercase letters, numbers and dashes (-). It is limited to 24 characters. Leading and trailing spaces are ignored.
--->
- 在选定的 Kubernetes [命名空间](/docs/tasks/administer-cluster/namespaces/) 中，应用名称必须唯一。必须由小写字母开头，以数字或者小写字母结尾，并且只含有小写字母、数字和中划线（-）。小于等于24个字符。开头和结尾的空格会被忽略。
+ -->
+ 在选定的 Kubernetes [名字空间](/zh/docs/tasks/administer-cluster/namespaces/) 中，
+ 应用名称必须唯一。必须由小写字母开头，以数字或者小写字母结尾，
+ 并且只含有小写字母、数字和中划线（-）。小于等于24个字符。开头和结尾的空格会被忽略。
<!--
- **Container image** (mandatory): The URL of a public Docker [container image](/docs/concepts/containers/images/) on any registry, or a private image (commonly hosted on the Google Container Registry or Docker Hub). The container image specification must end with a colon.
-->
-- **容器镜像**（必填）：公共镜像仓库上的 Docker [容器镜像](/docs/concepts/containers/images/) 或者私有镜像仓库（通常是 Google Container Registery 或者 Docker Hub）的 URL。容器镜像参数说明必须以冒号结尾。
+- **容器镜像**（必填）：公共镜像仓库上的 Docker
+ [容器镜像](/zh/docs/concepts/containers/images/) 或者私有镜像仓库
+ （通常是 Google Container Registery 或者 Docker Hub）的 URL。容器镜像参数说明必须以冒号结尾。
<!--
- **Number of pods** (mandatory): The target number of Pods you want your application to be deployed in. The value must be a positive integer.
-->
-- **pod 的数量**（必填）：您希望应用程序部署的 Pod 的数量。值必须为正整数。
+- **Pod 的数量**（必填）：你希望应用程序部署的 Pod 的数量。值必须为正整数。
-<!--
- A [Deployment](/docs/concepts/workloads/controllers/deployment/) will be created to maintain the desired number of Pods across your cluster.
--->
- 系统会创建一个 [Deployment](/docs/concepts/workloads/controllers/deployment/) 用于保证集群中运行了期望的 Pod 数量。
+ <!--
+ A [Deployment](/docs/concepts/workloads/controllers/deployment/) will be created to
+ maintain the desired number of Pods across your cluster.
+ -->
+ 系统会创建一个 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/)
+ 以保证集群中运行期望的 Pod 数量。
<!--
- **Service** (optional): For some parts of your application (e.g. frontends) you may want to expose a [Service](/docs/concepts/services-networking/service/) onto an external, maybe public IP address outside of your cluster (external Service). For external Services, you may need to open up one or more ports to do so. Find more details [here](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/).
-->
-- **服务**（可选）：对于部分应用（比如前端），您可能想对外暴露一个 [Service](/docs/concepts/services-networking/service/) ，这个 Service（外部 Service）可能用的是集群之外的公网 IP 地址。对于外部 Service 的情况，需要开放一个或者多个端口来满足。更多信息请参考 [这里](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/)。
+- **服务**（可选）：对于部分应用（比如前端），你可能想对外暴露一个
+ [Service](/zh/docs/concepts/services-networking/service/) ，这个 Service
+ 可能用的是集群之外的公网 IP 地址（外部 Service）。
+ 对于外部 Service 的情况，需要开放一个或者多个端口来满足。
+ 更多信息请参考 [这里](/zh/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/)。
-<!--
+ <!--
+ For external Services, you may need to open up one or more ports to do so.
+ -->
+ {{< note >}}
+ 对于外部服务，你可能需要开放一个或多个端口才行。
+ {{< /note >}}
+
+ <!--
Other Services that are only visible from inside the cluster are called internal Services.
--->
+ -->
其它只能对集群内部可见的 Service 称为内部 Service。
-<!--
- Irrespective of the Service type, if you choose to create a Service and your container listens on a port (incoming), you need to specify two ports. The Service will be created mapping the port (incoming) to the target port seen by the container. This Service will route to your deployed Pods. Supported protocols are TCP and UDP. The internal DNS name for this Service will be the value you specified as application name above.
- -->
- 不管哪种 Service 类型，如果您选择创建一个 Service，而且容器在一个端口上开启了监听（入向的），那么您需要定义两个端口。创建的 Service 会把（入向的）端口映射到容器可见的目标端口。该 Service 会把流量路由到您部署的 Pod。支持的协议有 TCP 和 UDP。这个 Service 的内部 DNS 解析名就是之前您定义的应用名称的值。
+ <!--
+ Irrespective of the Service type, if you choose to create a Service and your container listens
+ on a port (incoming), you need to specify two ports.
+ The Service will be created mapping the port (incoming) to the target port seen by the container.
+ This Service will route to your deployed Pods. Supported protocols are TCP and UDP.
+ The internal DNS name for this Service will be the value you specified as application name above.
+ -->
+ 不管哪种 Service 类型，如果你选择创建一个 Service，而且容器在一个端口上开启了监听（入向的），
+ 那么你需要定义两个端口。创建的 Service 会把（入向的）端口映射到容器可见的目标端口。
+ 该 Service 会把流量路由到你部署的 Pod。支持的协议有 TCP 和 UDP。
+ 这个 Service 的内部 DNS 解析名就是之前你定义的应用名称的值。
<!--
If needed, you can expand the **Advanced options** section where you can specify more settings:
-->
-如果需要，您可以打开 **高级选项** 部分，这里您可以定义更多设置：
+如果需要，你可以打开 **Advanced Options** 部分，这里你可以定义更多设置：
<!--
-- **Description**: The text you enter here will be added as an [annotation](/docs/concepts/overview/working-with-objects/annotations/) to the Deployment and displayed in the application's details.
+- **Description**: The text you enter here will be added as an
+ [annotation](/docs/concepts/overview/working-with-objects/annotations/)
+ to the Deployment and displayed in the application's details.
-->
-- **描述**：这里您输入的文本会作为一个 [注解](/docs/concepts/overview/working-with-objects/annotations/) 添加到 Deployment，并显示在应用的详细信息中。
+- **描述**：这里你输入的文本会作为一个
+ [注解](/zh/docs/concepts/overview/working-with-objects/annotations/)
+ 添加到 Deployment，并显示在应用的详细信息中。
<!--
- **Labels**: Default [labels](/docs/concepts/overview/working-with-objects/labels/) to be used for your application are application name and version. You can specify additional labels to be applied to the Deployment, Service (if any), and Pods, such as release, environment, tier, partition, and release track.
-->
-- **标签**：应用默认使用的 [标签](/docs/concepts/overview/working-with-objects/labels/) 是应用名称和版本。您可以为 Deployment、Service（如果有）定义额外的标签，比如 release（版本）、environment（环境）、tier（层级）、partition（分区） 和 release track（版本跟踪）。
+- **标签**：应用默认使用的
+ [标签](/zh/docs/concepts/overview/working-with-objects/labels/) 是应用名称和版本。
+ 你可以为 Deployment、Service（如果有）定义额外的标签，比如 release（版本）、
+ environment（环境）、tier（层级）、partition（分区） 和 release track（版本跟踪）。
-<!--
- Example:
--->
+ <!-- Example: -->
例子：
```conf
-release=1.0
-tier=frontend
-environment=pod
-track=stable
-```
+ release=1.0
+ tier=frontend
+ environment=pod
+ track=stable
+ ```
<!--
- **Namespace**: Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called [namespaces](/docs/tasks/administer-cluster/namespaces/). They let you partition resources into logically named groups.
-->
-- **命名空间**：Kubernetes 支持多个虚拟集群依附于同一个物理集群。这些虚拟集群被称为 [命名空间](/docs/tasks/administer-cluster/namespaces/)，可以让您将资源划分为逻辑命名的组。
+- **名字空间**：Kubernetes 支持多个虚拟集群依附于同一个物理集群。
+ 这些虚拟集群被称为
+ [名字空间](/zh/docs/tasks/administer-cluster/namespaces/)，
+ 可以让你将资源划分为逻辑命名的组。
-<!--
- Dashboard offers all available namespaces in a dropdown list, and allows you to create a new namespace. The namespace name may contain a maximum of 63 alphanumeric characters and dashes (-) but can not contain capital letters.
--->
-Dashboard 通过下拉菜单提供所有可用的命名空间，并允许您创建新的命名空间。命名空间的名称最长可以包含 63 个字母或数字和中横线（-），但是不能包含大写字母。
-<!--
- Namespace names should not consist of only numbers. If the name is set as a number, such as 10, the pod will be put in the default namespace.
--->
- 命名空间的名称不能只包含数字。如果名字被设置成一个数字，比如 10，pod 就
+ <!--
+ Dashboard offers all available namespaces in a dropdown list, and allows you to create a new namespace.
+ The namespace name may contain a maximum of 63 alphanumeric characters and dashes (-)
+ but can not contain capital letters.
+ -->
+ Dashboard 通过下拉菜单提供所有可用的名字空间，并允许你创建新的名字空间。
+ 名字空间的名称最长可以包含 63 个字母或数字和中横线（-），但是不能包含大写字母。
-<!--
- In case the creation of the namespace is successful, it is selected by default. If the creation fails, the first namespace is selected.
--->
- 在 namespace 创建成功的情况下，默认会使用新创建的命名空间。如果创建失败，那么第一个命名空间会被选中。
+ <!--
+ Namespace names should not consist of only numbers.
+ If the name is set as a number, such as 10, the pod will be put in the default namespace.
+ -->
+ 名字空间的名称不能只包含数字。如果名字被设置成一个数字，比如 10，pod 就
+
+ <!--
+ In case the creation of the namespace is successful, it is selected by default.
+ If the creation fails, the first namespace is selected.
+ -->
+ 在名字空间创建成功的情况下，默认会使用新创建的名字空间。如果创建失败，那么第一个名字空间会被选中。
<!--
- **Image Pull Secret**: In case the specified Docker container image is private, it may require [pull secret](/docs/concepts/configuration/secret/) credentials.
-->
-- **镜像拉取 Secret**：如果要使用私有的 Docker 容器镜像，需要拉取 [secret](/docs/concepts/configuration/secret/) 凭证。
+- **镜像拉取 Secret**：如果要使用私有的 Docker 容器镜像，需要拉取
+ [Secret](/zh/docs/concepts/configuration/secret/) 凭证。
-<!--
- Dashboard offers all available secrets in a dropdown list, and allows you to create a new secret. The secret name must follow the DNS domain name syntax, e.g. `new.image-pull.secret`. The content of a secret must be base64-encoded and specified in a [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) file. The secret name may consist of a maximum of 253 characters.
--->
- Dashboard 通过下拉菜单提供所有可用的 secret，并允许您创建新的 secret。secret 名称必须遵循 DNS 域名语法，比如 `new.image-pull.secret`。secret 的内容必须是 base64 编码的，并且在一个 [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) 文件中声明。secret 名称最大可以包含 253 个字符。
+ <!--
+ Dashboard offers all available secrets in a dropdown list, and allows you to create a new secret.
+ The secret name must follow the DNS domain name syntax, e.g. `new.image-pull.secret`.
+ The content of a secret must be base64-encoded and specified in a
+ [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) file.
+ The secret name may consist of a maximum of 253 characters.
+ -->
+ Dashboard 通过下拉菜单提供所有可用的 Secret，并允许你创建新的 Secret。
+ Secret 名称必须遵循 DNS 域名语法，比如 `new.image-pull.secret`。
+ Secret 的内容必须是 base64 编码的，并且在一个
+ [`.dockercfg`](/zh/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)
+ 文件中声明。Secret 名称最大可以包含 253 个字符。
-<!--
- In case the creation of the image pull secret is successful, it is selected by default. If the creation fails, no secret is applied.
--->
- 在镜像拉取 secret 创建成功的情况下，默认会使用新创建的 secret。如果创建失败，则不会使用任何 secret。
+ <!--
+ In case the creation of the image pull secret is successful, it is selected by default.
+ If the creation fails, no secret is applied.
+ -->
+ 在镜像拉取 Secret 创建成功的情况下，默认会使用新创建的 Secret。
+ 如果创建失败，则不会使用任何 Secret。
<!--
- **CPU requirement (cores)** and **Memory requirement (MiB)**: You can specify the minimum [resource limits](/docs/tasks/configure-pod-container/limit-range/) for the container. By default, Pods run with unbounded CPU and memory limits.
-->
-- **CPU 需求（核数）**和**内存需求（MiB）**：您可以为容器定义最小的 [资源限制](/docs/tasks/configure-pod-container/limit-range/)。默认情况下，Pod 没有 CPU 和内存限制。
+- **CPU 需求（核数）**和**内存需求（MiB）**：你可以为容器定义最小的
+ [资源限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)。
+ 默认情况下，Pod 没有 CPU 和内存限制。
<!--
- **Run command** and **Run command arguments**: By default, your containers run the specified Docker image's default [entrypoint command](/docs/user-guide/containers/#containers-and-commands). You can use the command options and arguments to override the default.
-->
-- **运行命令**和**运行命令参数**：默认情况下，您的容器会运行 Docker 镜像的默认 [入口命令](/docs/user-guide/containers/#containers-and-commands)。您可以使用 command 选项覆盖默认值。
+- **运行命令**和**运行命令参数**：默认情况下，你的容器会运行 Docker 镜像的默认
+ [入口命令](/zh/docs/tasks/inject-data-application/define-command-argument-container/)。
+ 你可以使用 command 选项覆盖默认值。
<!--
- **Run as privileged**: This setting determines whether processes in [privileged containers](/docs/user-guide/pods/#privileged-mode-for-pod-containers) are equivalent to processes running as root on the host. Privileged containers can make use of capabilities like manipulating the network stack and accessing devices.
-->
-- **以特权运行**：这个设置决定了在 [特权容器](/docs/user-guide/pods/#privileged-mode-for-pod-containers) 中运行的进程是否像主机中使用 root 运行的进程一样。特权容器可以使用诸如操纵网络堆栈和访问设备的功能。
+- **以特权模式运行**：这个设置决定了在
+ [特权容器](/zh/docs/concepts/workloads/pods/#privileged-mode-for-containers)
+ 中运行的进程是否像主机中使用 root 运行的进程一样。
+ 特权容器可以使用诸如操纵网络堆栈和访问设备的功能。
<!--
- **Environment variables**: Kubernetes exposes Services through [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/). You can compose environment variable or pass arguments to your commands using the values of environment variables. They can be used in applications to find a Service. Values can reference other variables using the `$(VAR_NAME)` syntax.
-->
-- **环境变量**：Kubernetes 通过 [环境变量](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) 暴露 Service。您可以构建环境变量，或者将环境变量的值作为参数传递给您的命令。它们可以被应用用于查找 Service。值可以通过 `$(VAR_NAME)` 语法关联其他变量。
+- **环境变量**：Kubernetes 通过
+ [环境变量](/zh/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)
+ 暴露 Service。你可以构建环境变量，或者将环境变量的值作为参数传递给你的命令。
+ 它们可以被应用用于查找 Service。值可以通过 `$(VAR_NAME)` 语法关联其他变量。
<!--
### Uploading a YAML or JSON file
+
+Kubernetes supports declarative configuration. In this style, all configuration is stored in YAML or JSON configuration files using the Kubernetes [API](/docs/concepts/overview/kubernetes-api/) resource schemas.
-->
### 上传 YAML 或者 JSON 文件
-<!--
-Kubernetes supports declarative configuration. In this style, all configuration is stored in YAML or JSON configuration files using the Kubernetes [API](/docs/concepts/overview/kubernetes-api/) resource schemas.
--->
-Kubernetes 支持声明式配置。所有的配置都存储在遵循 Kubernetes [API](/docs/concepts/overview/kubernetes-api/) 架构的 YAML 或者 JSON 配置文件中。
+Kubernetes 支持声明式配置。所有的配置都存储在遵循 Kubernetes
+[API](/zh/docs/concepts/overview/kubernetes-api/) 规范的 YAML 或者 JSON 配置文件中。
<!--
As an alternative to specifying application details in the deploy wizard, you can define your application in YAML or JSON files, and upload the files using Dashboard:
-->
-作为一种替代在部署向导中指定应用详情的方式，您可以在 YAML 或者 JSON 文件中定义应用，并且使用 Dashboard 上传文件：
+作为一种替代在部署向导中指定应用详情的方式，你可以在 YAML 或者 JSON 文件中定义应用，并且使用 Dashboard 上传文件：
<!--
## Using Dashboard
--->
-## 使用 Dashboard
-<!--
+
Following sections describe views of the Kubernetes Dashboard UI; what they provide and how can they be used.
-->
+## 使用 Dashboard
+
以下各节描述了 Kubernetes Dashboard UI 视图；包括它们提供的内容，以及怎么使用它们。
<!--
### Navigation
--->
-### 导航栏
-<!--
When there are Kubernetes objects defined in the cluster, Dashboard shows them in the initial view. By default only objects from the _default_ namespace are shown and this can be changed using the namespace selector located in the navigation menu.
-->
-当在集群中定义 Kubernetes 对象时，Dashboard 会在初始视图中显示它们。默认情况下只会显示 _默认_ 命名空间中的对象，可以通过更改导航栏菜单中的命名空间筛选器进行改变。
+### 导航
+
+当在集群中定义 Kubernetes 对象时，Dashboard 会在初始视图中显示它们。
+默认情况下只会显示 _默认_ 名字空间中的对象，可以通过更改导航栏菜单中的名字空间筛选器进行改变。
<!--
Dashboard shows most Kubernetes object kinds and groups them in a few menu categories.
@@ -310,58 +376,66 @@ Dashboard 展示大部分 Kubernetes 对象，并将它们分组放在几个菜
<!--
#### Admin Overview
+
+For cluster and namespace administrators, Dashboard lists Nodes, Namespaces and Persistent Volumes and has detail views for them. Node list view contains CPU and memory usage metrics aggregated across all Nodes. The details view shows the metrics for a Node, its specification, status, allocated resources, events and pods running on the node.
-->
#### 管理概述
-<!--
-For cluster and namespace administrators, Dashboard lists Nodes, Namespaces and Persistent Volumes and has detail views for them. Node list view contains CPU and memory usage metrics aggregated across all Nodes. The details view shows the metrics for a Node, its specification, status, allocated resources, events and pods running on the node.
--->
-集群和命名空间管理的视图, Dashboard 会列出节点、命名空间和持久卷，并且有它们的详细视图。节点列表视图包含从所有节点聚合的 CPU 和内存使用的度量值。详细信息视图显示了一个节点的度量值，它的规格、状态、分配的资源、事件和这个节点上运行的 Pod。
+集群和名字空间管理的视图, Dashboard 会列出节点、名字空间和持久卷，并且有它们的详细视图。
+节点列表视图包含从所有节点聚合的 CPU 和内存使用的度量值。
+详细信息视图显示了一个节点的度量值，它的规格、状态、分配的资源、事件和这个节点上运行的 Pod。
<!--
#### Workloads
Shows all applications running in the selected namespace. The view lists applications by workload kind (e.g., Deployments, Replica Sets, Stateful Sets, etc.) and each workload kind can be viewed separately. The lists summarize actionable information about the workloads, such as the number of ready pods for a Replica Set or current memory usage for a Pod.
-->
#### 负载
-显示选中的命名空间中所有运行的应用。视图按照负载类型（如 Deployment、ReplicaSet、StatefulSet 等）罗列应用，并且每种负载都可以单独查看。列表总结了关于负载的可执行信息，比如一个 ReplicaSet 的准备状态的 Pod 数量，或者目前一个 Pod 的内存使用量。
+
+显示选中的名字空间中所有运行的应用。
+视图按照负载类型（如 Deployment、ReplicaSet、StatefulSet 等）罗列应用，并且每种负载都可以单独查看。
+列表总结了关于负载的可执行信息，比如一个 ReplicaSet 的准备状态的 Pod 数量，或者目前一个 Pod 的内存使用量。
<!--
Detail views for workloads show status and specification information and surface relationships between objects. For example, Pods that Replica Set is controlling or New Replica Sets and Horizontal Pod Autoscalers for Deployments.
-->
-工作负载的详情视图展示了对象的状态、详细信息和相互关系。例如，ReplicaSet 所控制的 Pod，或者 Deployment 关联的 新 ReplicaSet 和 Pod 水平扩展控制器。
+工作负载的详情视图展示了对象的状态、详细信息和相互关系。
+例如，ReplicaSet 所控制的 Pod，或者 Deployment 关联的 新 ReplicaSet 和 Pod 水平扩展控制器。
<!--
#### Services
Shows Kubernetes resources that allow for exposing services to external world and discovering them within a cluster. For that reason, Service and Ingress views show Pods targeted by them, internal endpoints for cluster connections and external endpoints for external users.
-->
#### 服务
-展示允许暴露给外网服务和允许集群内部发现的 Kubernetes 资源。因此，Service 和 Ingress 视图展示他们关联的 Pod、给集群连接使用的内部端点和给外部用户使用的外部端点。
+
+展示允许暴露给外网服务和允许集群内部发现的 Kubernetes 资源。
+因此，Service 和 Ingress 视图展示他们关联的 Pod、给集群连接使用的内部端点和给外部用户使用的外部端点。
<!--
#### Storage
--->
-#### 存储
-<!--
+
Storage view shows Persistent Volume Claim resources which are used by applications for storing data.
-->
+#### 存储
+
存储视图展示持久卷申领（PVC）资源，这些资源被应用程序用来存储数据。
<!--
#### Config Maps and Secrets
--->
-#### 配置
-<!--
+
Shows all Kubernetes resources that are used for live configuration of applications running in clusters. The view allows for editing and managing config objects and displays secrets hidden by default.
-->
-展示的所有 Kubernetes 资源是在集群中运行的应用程序的实时配置。通过这个视图可以编辑和管理配置对象，并显示那些默认隐藏的 secret。
+#### ConfigMap 和 Secret
+
+展示的所有 Kubernetes 资源是在集群中运行的应用程序的实时配置。
+通过这个视图可以编辑和管理配置对象，并显示那些默认隐藏的 secret。
<!--
#### Logs viewer
--->
-#### 日志查看器
-<!--
+
Pod lists and detail pages link to logs viewer that is built into Dashboard. The viewer allows for drilling down logs from containers belonging to a single Pod.
-->
+#### 日志查看器
+
Pod 列表和详细信息页面可以链接到 Dashboard 内置的日志查看器。查看器可以钻取属于同一个 Pod 的不同容器的日志。
<!--
@@ -369,16 +443,11 @@ Pod 列表和详细信息页面可以链接到 Dashboard 内置的日志查看
-->
-
-
## {{% heading "whatsnext" %}}
-
<!--
For more information, see the
[Kubernetes Dashboard project page](https://github.com/kubernetes/dashboard).
-->
-更多信息，参见
-[Kubernetes Dashboard 项目页面](https://github.com/kubernetes/dashboard).
-
+更多信息，参见 [Kubernetes Dashboard 项目页面](https://github.com/kubernetes/dashboard).
diff --git a/content/zh/docs/tasks/administer-cluster/_index.md b/content/zh/docs/tasks/administer-cluster/_index.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/tasks/administer-cluster/access-cluster-api.md b/content/zh/docs/tasks/administer-cluster/access-cluster-api.md
index 29631fb3c4..1d2bed1a0a 100644
--- a/content/zh/docs/tasks/administer-cluster/access-cluster-api.md
+++ b/content/zh/docs/tasks/administer-cluster/access-cluster-api.md
@@ -2,106 +2,124 @@
title: 使用 Kubernetes API 访问集群
content_type: task
---
-<!-- ---
+<!--
title: Access Clusters Using the Kubernetes API
content_type: task
---- -->
+-->
+
<!-- overview -->
-<!-- This page shows how to access clusters using the Kubernetes API. -->
+
+<!--
+This page shows how to access clusters using the Kubernetes API.
+-->
本页展示了如何使用 Kubernetes API 访问集群
-
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
-<!-- ## Accessing the cluster API -->
+<!--
+## Accessing the cluster API
+### Accessing for the first time with kubectl
+-->
## 访问集群 API
-<!-- ### Accessing for the first time with kubectl -->
-
### 使用 kubectl 进行首次访问
-<!-- When accessing the Kubernetes API for the first time, use the
-Kubernetes command-line tool, `kubectl`. -->
-
+<!--
+When accessing the Kubernetes API for the first time, use the
+Kubernetes command-line tool, `kubectl`.
+-->
首次访问 Kubernetes API 时，请使用 Kubernetes 命令行工具 `kubectl` 。
-<!-- To access a cluster, you need to know the location of the cluster and have credentials
+<!--
+To access a cluster, you need to know the location of the cluster and have credentials
to access it. Typically, this is automatically set-up when you work through
a [Getting started guide](/docs/setup/),
-or someone else setup the cluster and provided you with credentials and a location. -->
-
-要访问集群，您需要知道集群位置并拥有访问它的凭证。通常，当您完成[入门指南](/docs/setup/)时，这会自动设置完成，或者由其他人设置好集群并将凭证和位置提供给您。
-
-<!-- Check the location and credentials that kubectl knows about with this command: -->
+or someone else setup the cluster and provided you with credentials and a location.
+-->
+要访问集群，你需要知道集群位置并拥有访问它的凭证。
+通常，当你完成[入门指南](/zh/docs/setup/)时，这会自动设置完成，或者由其他人设置好集群并将凭证和位置提供给你。
+<!--
+Check the location and credentials that kubectl knows about with this command:
+-->
使用此命令检查 kubectl 已知的位置和凭证：
```shell
kubectl config view
```
-<!-- Many of the [examples](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/) provide an introduction to using
-kubectl. Complete documentation is found in the [kubectl manual](/docs/reference/kubectl/overview/). -->
+<!--
+Many of the [examples](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/) provide an introduction to using
+kubectl. Complete documentation is found in the [kubectl manual](/docs/reference/kubectl/overview/).
+-->
-许多[样例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/)提供了使用 kubectl 的介绍。完整文档请见 [kubectl 手册](/docs/reference/kubectl/overview/)。
+许多[样例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/)
+提供了使用 kubectl 的介绍。完整文档请见 [kubectl 手册](/zh/docs/reference/kubectl/overview/)。
-<!-- ### Directly accessing the REST API -->
+<!--
+### Directly accessing the REST API
+kubectl handles locating and authenticating to the API server. If you want to directly access the REST API with an http client like
+`curl` or `wget`, or a browser, there are multiple ways you can locate and authenticate against the API server:
+-->
### 直接访问 REST API
-<!-- kubectl handles locating and authenticating to the API server. If you want to directly access the REST API with an http client like
-`curl` or `wget`, or a browser, there are multiple ways you can locate and authenticate against the API server: -->
+kubectl 处理对 API 服务器的定位和身份验证。如果你想通过 http 客户端（如 `curl` 或 `wget`，或浏览器）直接访问 REST API，你可以通过多种方式对 API 服务器进行定位和身份验证：
-kubectl 处理对 API 服务器的定位和身份验证。如果您想通过 http 客户端（如 `curl` 或 `wget`，或浏览器）直接访问 REST API，您可以通过多种方式对 API 服务器进行定位和身份验证：
+ <!--
+1. Run kubectl in proxy mode (recommended). This method is recommended, since it uses the stored apiserver location and verifies the identity of the API server using a self-signed cert. No man-in-the-middle (MITM) attack is possible using this method.
+ 1. Alternatively, you can provide the location and credentials directly to the http client. This works with client code that is confused by proxies. To protect against man in the middle attacks, you'll need to import a root cert into your browser.
+-->
+1. 以代理模式运行 kubectl（推荐）。
+ 推荐使用此方法，因为它用存储的 apiserver 位置并使用自签名证书验证 API 服务器的标识。
+ 使用这种方法无法进行中间人（MITM）攻击。
+2. 另外，你可以直接为 HTTP 客户端提供位置和身份认证。
+ 这适用于被代理混淆的客户端代码。
+ 为防止中间人攻击，你需要将根证书导入浏览器。
- <!-- 1. Run kubectl in proxy mode (recommended). This method is recommended, since it uses the stored apiserver location and verifies the identity of the API server using a self-signed cert. No man-in-the-middle (MITM) attack is possible using this method.
- 1. Alternatively, you can provide the location and credentials directly to the http client. This works with client code that is confused by proxies. To protect against man in the middle attacks, you'll need to import a root cert into your browser. -->
+<!--
+Using the Go or Python client libraries provides accessing kubectl in proxy mode.
+-->
+使用 Go 或 Python 客户端库可以在代理模式下访问 kubectl。
- 1. 以代理模式运行 kubectl（推荐）。 推荐使用此方法，因为它用存储的 apiserver 位置并使用自签名证书验证 API 服务器的标识。使用这种方法无法进行中间人（MITM）攻击。
- 2. 另外，您可以直接为 http 客户端提供位置和身份认证。这适用于被代理混淆的客户端代码。为防止中间人攻击，您需要将根证书导入浏览器。
-
- <!-- Using the Go or Python client libraries provides accessing kubectl in proxy mode. -->
-
- 使用 Go 或 Python 客户端库可以在代理模式下访问 kubectl。
-
-<!-- #### Using kubectl proxy -->
+<!--
+#### Using kubectl proxy
+The following command runs kubectl in a mode where it acts as a reverse proxy. It handles
+locating the API server and authenticating.
+-->
#### 使用 kubectl 代理
-<!-- The following command runs kubectl in a mode where it acts as a reverse proxy. It handles
-locating the API server and authenticating. -->
-
下列命令使 kubectl 运行在反向代理模式下。它处理 API 服务器的定位和身份认证。
<!-- Run it like this: -->
-
像这样运行它：
```shell
kubectl proxy --port=8080 &
```
-<!-- See [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands/#proxy) for more details. -->
-
+<!--
+See [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands/#proxy) for more details.
+-->
参见 [kubectl 代理](/docs/reference/generated/kubectl/kubectl-commands/#proxy) 获取更多细节。
-<!-- Then you can explore the API with curl, wget, or a browser, like so: -->
-
-然后您可以通过 curl，wget，或浏览器浏览 API，像这样：
+<!--
+Then you can explore the API with curl, wget, or a browser, like so:
+-->
+然后你可以通过 curl，wget，或浏览器浏览 API，像这样：
```shell
curl http://localhost:8080/api/
```
<!-- The output is similar to this: -->
-
输出类似如下：
```json
@@ -118,38 +136,38 @@ curl http://localhost:8080/api/
}
```
-<!-- #### Without kubectl proxy -->
+<!--
+#### Without kubectl proxy
-#### 不使用 kubectl 代理
-
-<!-- It is possible to avoid using kubectl proxy by passing an authentication token
+It is possible to avoid using kubectl proxy by passing an authentication token
directly to the API server, like this:
-Using `grep/cut` approach: -->
+Using `grep/cut` approach:
+-->
+#### 不使用 kubectl 代理
通过将身份认证令牌直接传给 API 服务器，可以避免使用 kubectl 代理，像这样：
使用 `grep/cut` 方式：
```shell
-# Check all possible clusters, as you .KUBECONFIG may have multiple contexts:
+# 查看所有的集群，因为你的 .kubeconfig 文件中可能包含多个上下文
kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.cluster.server}{"\n"}{end}'
-# Select name of cluster you want to interact with from above output:
+# 从上述命令输出中选择你要与之交互的集群的名称
export CLUSTER_NAME="some_server_name"
-# Point to the API server refering the cluster name
+# 指向引用该集群名称的 API 服务器
APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}")
-# Gets the token value
+# 获得令牌
TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='default')].data.token}"|base64 -d)
-# Explore the API with TOKEN
+# 使用令牌玩转 API
curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
```
<!-- The output is similar to this: -->
-
输出类似如下：
```json
@@ -168,13 +186,15 @@ curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
```
<!-- Using `jsonpath` approach: -->
-
使用 `jsonpath` 方式：
+```shell
+APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
+TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode )
+curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
```
-$ APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
-$ TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode )
-$ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
+
+```json
{
"kind": "APIVersions",
"versions": [
@@ -189,46 +209,72 @@ $ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
}
```
-<!-- The above example uses the `--insecure` flag. This leaves it subject to MITM
+<!--
+The above example uses the `--insecure` flag. This leaves it subject to MITM
attacks. When kubectl accesses the cluster it uses a stored root certificate
and client certificates to access the server. (These are installed in the
`~/.kube` directory). Since cluster certificates are typically self-signed, it
may take special configuration to get your http client to use root
-certificate. -->
+certificate.
+-->
+上面例子使用了 `--insecure` 标志位。这使它易受到 MITM 攻击。
+当 kubectl 访问集群时，它使用存储的根证书和客户端证书访问服务器。
+（已安装在 `~/.kube` 目录下）。
+由于集群认证通常是自签名的，因此可能需要特殊设置才能让你的 http 客户端使用根证书。
-上面例子使用了 `--insecure` 标志位。这使它易受到 MITM 攻击。当 kubectl 访问集群时，它使用存储的根证书和客户端证书访问服务器。（已安装在 `~/.kube` 目录下）。由于集群认证通常是自签名的，因此可能需要特殊设置才能让你的 http 客户端使用根证书。
-
-<!-- On some clusters, the API server does not require authentication; it may serve
+<!--
+On some clusters, the API server does not require authentication; it may serve
on localhost, or be protected by a firewall. There is not a standard
for this. [Configuring Access to the API](/docs/reference/access-authn-authz/controlling-access/)
describes how a cluster admin can configure this. Such approaches may conflict
-with future high-availability support. -->
+with future high-availability support.
+-->
+在一些集群中，API 服务器不需要身份认证；它运行在本地，或由防火墙保护着。
+对此并没有一个标准。
+[配置对 API 的访问](/zh/docs/reference/access-authn-authz/controlling-access/)
+阐述了一个集群管理员如何对此进行配置。这种方法可能与未来的高可用性支持发生冲突。
-在一些集群中，API 服务器不需要身份认证；它运行在本地，或由防火墙保护着。对此并没有一个标准。[配置对 API 的访问](/docs/reference/access-authn-authz/controlling-access/) 阐述了一个集群管理员如何对此进行配置。这种方法可能与未来的高可用性支持发生冲突。
-
-<!-- ### Programmatic access to the API -->
+<!--
+### Programmatic access to the API
+Kubernetes officially supports client libraries for [Go](#go-client), [Python](#python-client), [Java](#java-client), [dotnet](#dotnet-client), [Javascript](#javascript-client), and [Haskell](#haskell-client). There are other client libraries that are provided and maintained by their authors, not the Kubernetes team. See [client libraries](/docs/reference/using-api/client-libraries/) for accessing the API from other languages and how they authenticate.
+-->
### 编程方式访问 API
-<!-- Kubernetes officially supports client libraries for [Go](#go-client) and
-[Python](#python-client). -->
-
-Kubernetes 官方支持 [Go](#go-客户端) 和 [Python](#python-客户端) 的客户端库.
+Kubernetes 官方支持 [Go](#go-client)、[Python](#python-client)、[Java](#java-client)、
+[dotnet](#dotnet-client)、[Javascript](#javascript-client) 和 [Haskell](#haskell-client)
+语言的客户端库。还有一些其他客户端库由对应作者而非 Kubernetes 团队提供并维护。
+参考[客户端库](/zh/docs/reference/using-api/client-libraries/)了解如何使用其他语言
+来访问 API 以及如何执行身份认证。
<!-- #### Go client -->
-#### Go 客户端
+#### Go 客户端 {#go-client}
-<!-- * To get the library, run the following command: `go get k8s.io/client-go/<version number>/kubernetes` See [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go) to see which versions are supported.
-* Write an application atop of the client-go clients. Note that client-go defines its own API objects, so if needed, please import API definitions from client-go rather than from the main repository, e.g., `import "k8s.io/client-go/1.4/pkg/api/v1"` is correct. -->
+<!--
+* To get the library, run the following command: `go get k8s.io/client-go/<version number>/kubernetes` See [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go) to see which versions are supported.
+* Write an application atop of the client-go clients.-->
-* 要获取库，运行下列命令：`go get k8s.io/client-go/<version number>/kubernetes` 参见 [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go) 查看受支持的版本。
-* 基于 client-go 客户端编写应用程序。注意 client-go 定义了自己的 API 对象，因此如果需要，请从 client-go 而不是主仓库导入 API 定义，例如 `import "k8s.io/client-go/1.4/pkg/api/v1"` 是正确做法。
+* 要获取库，运行下列命令：`go get k8s.io/client-go/<版本号>/kubernetes`，
+ 参见 [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go) 查看受支持的版本。
+* 基于 client-go 客户端编写应用程序。
-<!-- The Go client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
-as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go): -->
+<!--
+Note that client-go defines its own API objects, so if needed, please import API definitions from client-go rather than from the main repository, e.g., `import "k8s.io/client-go/kubernetes"` is correct.
+-->
+{{< note >}}
+注意 client-go 定义了自己的 API 对象，因此如果需要，请从 client-go 而不是主仓库导入
+API 定义，例如 `import "k8s.io/client-go/kubernetes"` 是正确做法。
+{{< /note >}}
-Go 客户端可以使用与 kubectl 命令行工具相同的 [kubeconfig 文件](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) 定位和验证 API 服务器。参见这个 [例子](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)：
+<!--
+The Go client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
+as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go):
+-->
+Go 客户端可以使用与 kubectl 命令行工具相同的
+[kubeconfig 文件](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+定位和验证 API 服务器。参见这个
+[例子](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)：
```golang
import (
@@ -237,33 +283,43 @@ import (
"k8s.io/client-go/1.4/pkg/api/v1"
"k8s.io/client-go/1.4/tools/clientcmd"
)
-...
- // uses the current context in kubeconfig
- config, _ := clientcmd.BuildConfigFromFlags("", "path to kubeconfig")
- // creates the clientset
- clientset, _:= kubernetes.NewForConfig(config)
- // access the API to list pods
- pods, _:= clientset.CoreV1().Pods("").List(v1.ListOptions{})
- fmt.Printf("There are %d pods in the cluster\n", len(pods.Items))
-...
+
+func main() {
+ // uses the current context in kubeconfig
+ // path-to-kubeconfig -- for example, /root/.kube/config
+ config, _ := clientcmd.BuildConfigFromFlags("", "<path-to-kubeconfig>")
+ // creates the clientset
+ clientset, _ := kubernetes.NewForConfig(config)
+ // access the API to list pods
+ pods, _ := clientset.CoreV1().Pods("").List(v1.ListOptions{})
+ fmt.Printf("There are %d pods in the cluster\n", len(pods.Items))
+}
```
-<!-- If the application is deployed as a Pod in the cluster, please refer to the [next section](#accessing-the-api-from-a-pod). -->
-
-如果该应用程序部署为集群中的一个 Pod，请参阅 [下一节](#从-pod-中访问-api)。
+<!--
+If the application is deployed as a Pod in the cluster, please refer to the [next section](#accessing-the-api-from-a-pod).
+-->
+如果该应用程序部署为集群中的一个
+Pod，请参阅[下一节](#accessing-the-api-from-within-accessing-the-api-from-within-a-pod)。
<!-- #### Python client -->
+#### Python 客户端 {#python-client}
-#### Python 客户端
+<!--
+To use [Python client](https://github.com/kubernetes-client/python), run the following command: `pip install kubernetes` See [Python Client Library page](https://github.com/kubernetes-client/python) for more installation options.
+-->
+要使用 [Python 客户端](https://github.com/kubernetes-client/python)，运行下列命令：
+`pip install kubernetes`。
+参见 [Python 客户端库主页](https://github.com/kubernetes-client/python) 了解更多安装选项。
-<!-- To use [Python client](https://github.com/kubernetes-client/python), run the following command: `pip install kubernetes` See [Python Client Library page](https://github.com/kubernetes-client/python) for more installation options. -->
-
-要使用 [Python 客户端](https://github.com/kubernetes-client/python)，运行下列命令：`pip install kubernetes` 参见 [Python 客户端库主页](https://github.com/kubernetes-client/python) 查看更多安装选项。
-
-<!-- The Python client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
-as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/python/blob/master/examples/out_of_cluster_config.py): -->
-
-Python 客户端可以使用与 kubectl 命令行工具相同的 [kubeconfig 文件](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/) 定位和验证 API 服务器。参见这个 [例子](https://github.com/kubernetes-client/python/blob/master/examples/out_of_cluster_config.py)：
+<!--
+The Python client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
+as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/python/blob/master/examples/out_of_cluster_config.py):
+-->
+Python 客户端可以使用与 kubectl 命令行工具相同的
+[kubeconfig 文件](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+定位和验证 API 服务器。参见这个
+[例子](https://github.com/kubernetes-client/python/blob/master/examples/out_of_cluster_config.py)：
```python
from kubernetes import client, config
@@ -277,77 +333,351 @@ for i in ret.items:
print("%s\t%s\t%s" % (i.status.pod_ip, i.metadata.namespace, i.metadata.name))
```
-<!-- #### Other languages -->
+<!-- #### Java client -->
+#### Java 客户端 {#java-client}
-#### 其他语言
+<!--
+* To install the [Java Client](https://github.com/kubernetes-client/java), simply execute :
+-->
+* 要安装 [Java 客户端](https://github.com/kubernetes-client/java)，只需执行：
-<!-- There are [client libraries](/docs/reference/using-api/client-libraries/) for accessing the API from other languages. See documentation for other libraries for how they authenticate. -->
+```shell
+# 克隆 Java 库
+git clone --recursive https://github.com/kubernetes-client/java
-有许多 [客户端库](/docs/reference/using-api/client-libraries/) 可以用于从其他语言访问 API。请参阅其他库的文档了解它们的身份验证方式。
+# 安装项目文件、POM 等
+cd java
+mvn install
+```
-<!-- ### Accessing the API from a Pod -->
+<!--
+See [https://github.com/kubernetes-client/java/releases](https://github.com/kubernetes-client/java/releases) to see which versions are supported.
+The Java client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/KubeConfigFileClientExample.java):
+-->
+参阅[https://github.com/kubernetes-client/java/releases](https://github.com/kubernetes-client/java/releases)
+了解当前支持的版本。
+
+Java 客户端可以使用 kubectl 命令行所使用的
+[kubeconfig 文件](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+以定位 API 服务器并向其认证身份。
+参看此[示例](https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/KubeConfigFileClientExample.java)：
+
+```java
+package io.kubernetes.client.examples;
+
+import io.kubernetes.client.ApiClient;
+import io.kubernetes.client.ApiException;
+import io.kubernetes.client.Configuration;
+import io.kubernetes.client.apis.CoreV1Api;
+import io.kubernetes.client.models.V1Pod;
+import io.kubernetes.client.models.V1PodList;
+import io.kubernetes.client.util.ClientBuilder;
+import io.kubernetes.client.util.KubeConfig;
+import java.io.FileReader;
+import java.io.IOException;
+
+/**
+ * A simple example of how to use the Java API from an application outside a kubernetes cluster
+ *
+ * <p>Easiest way to run this: mvn exec:java
+ * -Dexec.mainClass="io.kubernetes.client.examples.KubeConfigFileClientExample"
+ *
+ */
+public class KubeConfigFileClientExample {
+ public static void main(String[] args) throws IOException, ApiException {
+
+ // file path to your KubeConfig
+ String kubeConfigPath = "~/.kube/config";
+
+ // loading the out-of-cluster config, a kubeconfig from file-system
+ ApiClient client =
+ ClientBuilder.kubeconfig(KubeConfig.loadKubeConfig(new FileReader(kubeConfigPath))).build();
+
+ // set the global default api-client to the in-cluster one from above
+ Configuration.setDefaultApiClient(client);
+
+ // the CoreV1Api loads default api-client from global configuration.
+ CoreV1Api api = new CoreV1Api();
+
+ // invokes the CoreV1Api client
+ V1PodList list = api.listPodForAllNamespaces(null, null, null, null, null, null, null, null, null);
+ System.out.println("Listing all pods: ");
+ for (V1Pod item : list.getItems()) {
+ System.out.println(item.getMetadata().getName());
+ }
+ }
+}
+```
+
+<!--
+#### dotnet client
+
+To use [dotnet client](https://github.com/kubernetes-client/csharp), run the following command: `dotnet add package KubernetesClient --version 1.6.1` See [dotnet Client Library page](https://github.com/kubernetes-client/csharp) for more installation options. See [https://github.com/kubernetes-client/csharp/releases](https://github.com/kubernetes-client/csharp/releases) to see which versions are supported.
+
+The dotnet client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/csharp/blob/master/examples/simple/PodList.cs):
+-->
+#### .Net 客户端 {#dotnet-client}
+
+要使用 [.Net 客户端](https://github.com/kubernetes-client/csharp)，运行下面的命令：
+`dotnet add package KubernetesClient --version 1.6.1`。
+参见 [.Net 客户端库页面](https://github.com/kubernetes-client/csharp)了解更多安装选项。
+关于可支持的版本，参见[https://github.com/kubernetes-client/csharp/releases](https://github.com/kubernetes-client/csharp/releases)。
+
+```csharp
+using System;
+using k8s;
+
+namespace simple
+{
+ internal class PodList
+ {
+ private static void Main(string[] args)
+ {
+ var config = KubernetesClientConfiguration.BuildDefaultConfig();
+ IKubernetes client = new Kubernetes(config);
+ Console.WriteLine("Starting Request!");
+
+ var list = client.ListNamespacedPod("default");
+ foreach (var item in list.Items)
+ {
+ Console.WriteLine(item.Metadata.Name);
+ }
+ if (list.Items.Count == 0)
+ {
+ Console.WriteLine("Empty!");
+ }
+ }
+ }
+}
+```
+
+<!--
+#### JavaScript client
+
+To install [JavaScript client](https://github.com/kubernetes-client/javascript), run the following command: `npm install @kubernetes/client-node`. See [https://github.com/kubernetes-client/javascript/releases](https://github.com/kubernetes-client/javascript/releases) to see which versions are supported.
+
+The JavaScript client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/javascript/blob/master/examples/example.js):
+-->
+#### JavaScript 客户端 {#javascript-client}
+
+要安装 [JavaScript 客户端](https://github.com/kubernetes-client/javascript)，运行下面的命令：
+`npm install @kubernetes/client-node`。
+参考[https://github.com/kubernetes-client/javascript/releases](https://github.com/kubernetes-client/javascript/releases)了解可支持的版本。
+
+JavaScript 客户端可以使用 kubectl 命令行所使用的
+[kubeconfig 文件](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+以定位 API 服务器并向其认证身份。
+参见[此例](https://github.com/kubernetes-client/javascript/blob/master/examples/example.js)：
+
+```javascript
+const k8s = require('@kubernetes/client-node');
+
+const kc = new k8s.KubeConfig();
+kc.loadFromDefault();
+
+const k8sApi = kc.makeApiClient(k8s.CoreV1Api);
+
+k8sApi.listNamespacedPod('default').then((res) => {
+ console.log(res.body);
+});
+```
+
+<!--
+#### Haskell client
+
+See [https://github.com/kubernetes-client/haskell/releases](https://github.com/kubernetes-client/haskell/releases) to see which versions are supported.
+
+The [Haskell client](https://github.com/kubernetes-client/haskell) can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+as the kubectl CLI does to locate and authenticate to the API server. See this [example](https://github.com/kubernetes-client/haskell/blob/master/kubernetes-client/example/App.hs):
+-->
+#### Haskell 客户端 {#haskell-client}
+
+参考 [https://github.com/kubernetes-client/haskell/releases](https://github.com/kubernetes-client/haskell/releases) 了解支持的版本。
+
+[Haskell 客户端](https://github.com/kubernetes-client/haskell)
+可以使用 kubectl 命令行所使用的
+[kubeconfig 文件](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+以定位 API 服务器并向其认证身份。
+参见[此例](https://github.com/kubernetes-client/haskell/blob/master/kubernetes-client/example/App.hs)：
+
+```haskell
+exampleWithKubeConfig :: IO ()
+exampleWithKubeConfig = do
+ oidcCache <- atomically $ newTVar $ Map.fromList []
+ (mgr, kcfg) <- mkKubeClientConfig oidcCache $ KubeConfigFile "/path/to/kubeconfig"
+ dispatchMime
+ mgr
+ kcfg
+ (CoreV1.listPodForAllNamespaces (Accept MimeJSON))
+ >>= print
+```
+
+
+<!--
+### Accessing the API from within a Pod
+
+When accessing the API from within a Pod, locating and authenticating
+to the API server are slightly different to the external client case described above.
+-->
### 从 Pod 中访问 API
-<!-- When accessing the API from a Pod, locating and authenticating
-to the API server are somewhat different. -->
+从 Pod 内部访问 API 时，定位 API 服务器和向服务器认证身份的操作
+与上面描述的外部客户场景不同。
-从 Pod 访问 API 时，对 API 服务器的定位和身份验证会有所不同。
-
-<!-- The easiest way to use the Kubernetes API from a Pod is to use
+<!--
+The easiest way to use the Kubernetes API from a Pod is to use
one of the official [client libraries](/docs/reference/using-api/client-libraries/). These
-libraries can automatically discover the API server and authenticate. -->
+libraries can automatically discover the API server and authenticate.
+-->
+从 Pod 使用 Kubernetes API 的最简单的方法就是使用官方的
+[客户端库](/zh/docs/reference/using-api/client-libraries/)。
+这些库可以自动发现 API 服务器并进行身份验证。
-从 Pod 使用 Kubernetes API 的最简单的方法就是使用一个官方的 [客户端库](/docs/reference/using-api/client-libraries/)。这些库可以自动发现 API 服务器并进行身份验证。
+<!--
+#### Using Official Client Libraries
-<!-- While running in a Pod, the Kubernetes apiserver is accessible via a Service named
+From within a Pod, the recommended ways to connect to the Kubernetes API are:
+
+ - For a Go client, use the official [Go client library](https://github.com/kubernetes/client-go/).
+ The `rest.InClusterConfig()` function handles API host discovery and authentication automatically.
+ See [an example here](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go).
+
+ - For a Python client, use the official [Python client library](https://github.com/kubernetes-client/python/).
+ The `config.load_incluster_config()` function handles API host discovery and authentication automatically.
+ See [an example here](https://github.com/kubernetes-client/python/blob/master/examples/in_cluster_config.py).
+
+ - There are a number of other libraries available, please refer to the [Client Libraries](/docs/reference/using-api/client-libraries/) page.
+
+In each case, the service account credentials of the Pod are used to communicate
+securely with the API server.
+-->
+#### 使用官方客户端库
+
+从一个 Pod 内部连接到 Kubernetes API 的推荐方式为：
+
+- 对于 Go 语言客户端，使用官方的 [Go 客户端库](https://github.com/kubernetes/client-go/)。
+ 函数 `rest.InClusterConfig()` 自动处理 API 主机发现和身份认证。
+ 参见[这里的一个例子](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)。
+
+- 对于 Python 客户端，使用官方的 [Python 客户端库](https://github.com/kubernetes-client/python/)。
+ 函数 `config.load_incluster_config()` 自动处理 API 主机的发现和身份认证。
+ 参见[这里的一个例子](https://github.com/kubernetes-client/python/blob/master/examples/in_cluster_config.py)。
+
+- 还有一些其他可用的客户端库，请参阅[客户端库](/zh/docs/reference/using-api/client-libraries/)页面。
+
+在以上场景中，客户端库都使用 Pod 的服务账号凭据来与 API 服务器安全地通信。
+
+<!--
+#### Directly accessing the REST API
+
+While running in a Pod, the Kubernetes apiserver is accessible via a Service named
`kubernetes` in the `default` namespace. Therefore, Pods can use the
`kubernetes.default.svc` hostname to query the API server. Official client libraries
-do this automatically. -->
+do this automatically.
+-->
+#### 直接访问 REST API
-在运行在 Pod 中时，可以通过 `default` 命名空间中的名为 `kubernetes` 的服务访问 Kubernetes apiserver。也就是说，Pods 可以使用 `kubernetes.default.svc` 主机名来查询 API 服务器。官方客户端库自动完成这个工作。
+在运行在 Pod 中时，可以通过 `default` 命名空间中的名为 `kubernetes` 的服务访问
+Kubernetes API 服务器。也就是说，Pod 可以使用 `kubernetes.default.svc` 主机名
+来查询 API 服务器。官方客户端库自动完成这个工作。
-<!-- From within a Pod, the recommended way to authenticate to the API server is with a
+<!--
+The recommended way to authenticate to the API server is with a
[service account](/docs/user-guide/service-accounts) credential. By default, a Pod
is associated with a service account, and a credential (token) for that
service account is placed into the filesystem tree of each container in that Pod,
-at `/var/run/secrets/kubernetes.io/serviceaccount/token`. -->
+at `/var/run/secrets/kubernetes.io/serviceaccount/token`.
+-->
+向 API 服务器进行身份认证的推荐做法是使用
+[服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/)凭据。
+默认情况下，每个 Pod 与一个服务账号关联，该服务账户的凭证（令牌）放置在此 Pod 中
+每个容器的文件系统树中的 `/var/run/secrets/kubernetes.io/serviceaccount/token` 处。
-从一个 Pod 内，向 API 服务器进行身份认证的推荐的做法是使用 [服务账号](/docs/user-guide/service-accounts) 凭证。默认的，一个 Pod 与一个服务账号关联，该服务账户的凭证（令牌）放置在此 Pod 中每个容器的文件系统树中的 `/var/run/secrets/kubernetes.io/serviceaccount/token` 处。
-
-<!-- If available, a certificate bundle is placed into the filesystem tree of each
+<!--
+If available, a certificate bundle is placed into the filesystem tree of each
container at `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`, and should be
-used to verify the serving certificate of the API server. -->
+used to verify the serving certificate of the API server.
+-->
+如果由证书包可用，则凭证包被放入每个容器的文件系统树中的
+`/var/run/secrets/kubernetes.io/serviceaccount/ca.crt` 处，
+且将被用于验证 API 服务器的服务证书。
-如果可用，凭证包被放入每个容器的文件系统树中的 `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt` 处，并且将被用于验证 API 服务器的服务证书。
+<!--
+Finally, the default namespace to be used for namespaced API operations is placed in a file
+at `/var/run/secrets/kubernetes.io/serviceaccount/namespace` in each container.
+-->
+最后，用于命名空间域 API 操作的默认命名空间放置在每个容器中的
+`/var/run/secrets/kubernetes.io/serviceaccount/namespace` 文件中。
-<!-- Finally, the default namespace to be used for namespaced API operations is placed in a file
-at `/var/run/secrets/kubernetes.io/serviceaccount/namespace` in each container. -->
+<!--
+#### Using kubectl proxy
-最后，用于命名空间 API 操作的默认的命名空间放置在每个容器中的 `/var/run/secrets/kubernetes.io/serviceaccount/namespace` 文件中。
+If you would like to query the API without an official client library, you can run `kubectl proxy`
+as the [command](/docs/tasks/inject-data-application/define-command-argument-container/)
+of a new sidecar container in the Pod. This way, `kubectl proxy` will authenticate
+to the API and expose it on the `localhost` interface of the Pod, so that other containers
+in the Pod can use it directly.
+-->
+#### 使用 kubectl proxy {#use-kubectl-proxy}
-<!-- From within a Pod, the recommended ways to connect to the Kubernetes API are: -->
+如果你希望不实用官方客户端库就完成 API 查询，可以将 `kubectl proxy` 作为
+[command](/zh/docs/tasks/inject-data-application/define-command-argument-container/)
+在 Pod 启动一个边车（Sidecar）容器。这样，`kubectl proxy` 自动完成对 API
+的身份认证，并将其暴露到 Pod 的 `localhost` 接口，从而 Pod 中的其他容器可以
+直接使用 API。
-从一个 Pod 内，连接 Kubernetes API 的推荐方法是：
+<!--
+#### Without using a proxy
-<!-- - Use one of the official [client libraries](/docs/reference/using-api/client-libraries/)
- as they handle API host discovery and authentication automatically.
- For Go client, the `rest.InClusterConfig()` function assists with this.
- See [an example here](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go). -->
+It is possible to avoid using the kubectl proxy by passing the authentication token
+directly to the API server. The internal certificate secures the connection.
+-->
+#### 不使用代理 {#without-using-a-proxy}
- - 使用官方的 [客户端库](/docs/reference/using-api/client-libraries/) 因为他们会自动地完成 API 主机发现和身份认证。以 Go 客户端来说，`rest.InClusterConfig()` 可以帮助解决这个问题。参见 [这里的一个例子](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)。
+通过将认证令牌直接发送到 API 服务器，也可以避免运行 kubectl proxy 命令。
+内部的证书机制能够为链接提供保护。
-<!-- - If you would like to query the API without an official client library, you can run `kubectl proxy`
- as the [command](/docs/tasks/inject-data-application/define-command-argument-container/)
- of a new sidecar container in the Pod. This way, `kubectl proxy` will authenticate
- to the API and expose it on the `localhost` interface of the Pod, so that other containers
- in the Pod can use it directly. -->
+```shell
+# 指向内部 API 服务器的主机名
+APISERVER=https://kubernetes.default.svc
- - 如果您想要在没有官方客户端库的情况下查询 API，可以在 Pod 里以一个新的边车容器的 [命令](/docs/tasks/inject-data-application/define-command-argument-container/)的方式运行 `kubectl proxy` 。此方式下，`kubectl proxy` 将对 API 进行身份验证并将其公开在 Pod 的 `localhost` 接口上，以便 Pod 中的其他容器可以直接使用它。
+# 服务账号令牌的路径
+SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
-<!-- In each case, the service account credentials of the Pod are used to communicate
-securely with the API server. -->
+# 读取 Pod 的名字空间
+NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
-在每种情况下，Pod 的服务账号凭证被用于与 API 服务器的安全通信。
+# 读取服务账号的持有者令牌
+TOKEN=$(cat ${SERVICEACCOUNT}/token)
+# 引用内部整数机构（CA）
+CACERT=${SERVICEACCOUNT}/ca.crt
+
+# 使用令牌访问 API
+curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api
+```
+
+<!--
+The output will be similar to this:
+-->
+输出类似于：
+
+```json
+{
+ "kind": "APIVersions",
+ "versions": [
+ "v1"
+ ],
+ "serverAddressByClientCIDRs": [
+ {
+ "clientCIDR": "0.0.0.0/0",
+ "serverAddress": "10.0.1.149:443"
+ }
+ ]
+}
+```
diff --git a/content/zh/docs/tasks/administer-cluster/change-default-storage-class.md b/content/zh/docs/tasks/administer-cluster/change-default-storage-class.md
index 8685c3ca12..7ce89691f4 100644
--- a/content/zh/docs/tasks/administer-cluster/change-default-storage-class.md
+++ b/content/zh/docs/tasks/administer-cluster/change-default-storage-class.md
@@ -1,104 +1,153 @@
---
-
title: 改变默认 StorageClass
content_type: task
---
<!-- overview -->
-
+<!--
+This page shows how to change the default Storage Class that is used to
+provision volumes for PersistentVolumeClaims that have no special requirements.
+-->
本文展示了如何改变默认的 Storage Class，它用于为没有特殊需求的 PersistentVolumeClaims 配置 volumes。
-
-
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
<!-- steps -->
+<!--
+## Why change the default storage class?
-## 为什么要改变默认 storage class？
-
-
-取决于安装模式，您的 Kubernetes 集群可能和一个被标记为默认的已有 StorageClass 一起部署。这个默认的 StorageClass 以后将被用于动态的为没有特定 storage class 需求的 PersistentVolumeClaims 配置存储。更多细节请查看 [PersistentVolumeClaim 文档](/docs/user-guide/persistent-volumes/#class-1)。
-
-
-预先安装的默认 StorageClass 可能不能很好的适应您期望的工作负载；例如，它配置的存储可能太过昂贵。如果是这样的话，您可以改变默认 StorageClass，或者完全禁用它以防止动态配置存储。
-
-
-简单的删除默认 StorageClass 可能行不通，因为它可能会被您集群中的扩展管理器自动重建。请查阅您的安装文档中关于扩展管理器的细节，以及如何禁用单个扩展。
+Depending on the installation method, your Kubernetes cluster may be deployed with
+an existing StorageClass that is marked as default. This default StorageClass
+is then used to dynamically provision storage for PersistentVolumeClaims
+that do not require any specific storage class. See
+[PersistentVolumeClaim documentation](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
+for details.
+-->
+## 为什么要改变默认存储类？
+
+取决于安装模式，你的 Kubernetes 集群可能和一个被标记为默认的已有 StorageClass 一起部署。
+这个默认的 StorageClass 以后将被用于动态的为没有特定存储类需求的 PersistentVolumeClaims
+配置存储。更多细节请查看 [PersistentVolumeClaim 文档](/zh/docs/user-guide/persistent-volumes/#class-1)。
+
+<!--
+The pre-installed default StorageClass may not fit well with your expected workload;
+for example, it might provision storage that is too expensive. If this is the case,
+you can either change the default StorageClass or disable it completely to avoid
+dynamic provisioning of storage.
+-->
+预先安装的默认 StorageClass 可能不能很好的适应你期望的工作负载；例如，它配置的存储可能太过昂贵。
+如果是这样的话，你可以改变默认 StorageClass，或者完全禁用它以防止动态配置存储。
+
+<!--
+Simply deleting the default StorageClass may not work, as it may be re-created
+automatically by the addon manager running in your cluster. Please consult the docs for your installation
+for details about addon manager and how to disable individual addons.
+-->
+简单的删除默认 StorageClass 可能行不通，因为它可能会被你集群中的扩展管理器自动重建。
+请查阅你的安装文档中关于扩展管理器的细节，以及如何禁用单个扩展。
+<!--
+## Changing the default StorageClass
+-->
## 改变默认 StorageClass
+<!--
+1. List the StorageClasses in your cluster:
+-->
+1. 列出你的集群中的 StorageClasses：
-1. 列出您集群中的 StorageClasses：
+ ```shell
+ kubectl get storageclass
+ ```
- ```bash
- kubectl get storageclass
- ```
+ 输出类似这样：
- 输出类似这样：
-
- ```bash
- NAME PROVISIONER AGE
- standard (default) kubernetes.io/gce-pd 1d
- gold kubernetes.io/gce-pd 1d
- ```
-
- 默认 StorageClass 以 `(default)` 标记。
+ ```bash
+ NAME PROVISIONER AGE
+ standard (default) kubernetes.io/gce-pd 1d
+ gold kubernetes.io/gce-pd 1d
+ ```
+ 默认 StorageClass 以 `(default)` 标记。
+<!--
+1. Mark the default StorageClass as non-default:
+-->
2. 标记默认 StorageClass 非默认：
+
+ <!--
+ The default StorageClass has an annotation
+ `storageclass.kubernetes.io/is-default-class` set to `true`. Any other value
+ or absence of the annotation is interpreted as `false`.
+ To mark a StorageClass as non-default, you need to change its value to `false`:
+ -->
+ 默认 StorageClass 的注解 `storageclass.kubernetes.io/is-default-class` 设置为 `true`。
+ 注解的其它任意值或者缺省值将被解释为 `false`。
- 默认 StorageClass 的注解 `storageclass.kubernetes.io/is-default-class` 设置为 `true`。注解的其它任意值或者缺省值将被解释为 `false`。
-
- 要标记一个 StorageClass 为非默认的，您需要改变它的值为 `false`：
+ 要标记一个 StorageClass 为非默认的，你需要改变它的值为 `false`：
- ```bash
- kubectl patch storageclass <your-class-name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
- ```
-
-
- 这里的 `<your-class-name>` 是您选择的 StorageClass 的名字。
+ ```bash
+ kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
+ ```
+ <!--
+ where `standard` is the name of your chosen StorageClass.
+ -->
+ 这里的 `standard` 是你选择的 StorageClass 的名字。
+<!--
+1. Mark a StorageClass as default:
+-->
3. 标记一个 StorageClass 为默认的：
+ <!--
+ Similarly to the previous step, you need to add/set the annotation
+ `storageclass.kubernetes.io/is-default-class=true`.
+ -->
+ 和前面的步骤类似，你需要添加/设置注解 `storageclass.kubernetes.io/is-default-class=true`。
- 和前面的步骤类似，您需要添加/设置注解 `storageclass.kubernetes.io/is-default-class=true`。
+ ```bash
+ kubectl patch storageclass <your-class-name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
+ ```
- ```bash
- kubectl patch storageclass <your-class-name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
- ```
+ <!--
+ Please note that at most one StorageClass can be marked as default. If two
+ or more of them are marked as default, a `PersistentVolumeClaim` without
+ `storageClassName` explicitly specified cannot be created.
+ -->
+ 请注意，最多只能有一个 StorageClass 能够被标记为默认。
+ 如果它们中有两个或多个被标记为默认，Kubernetes 将忽略这个注解，
+ 也就是它将表现为没有默认 StorageClass。
- 请注意，最多只能有一个 StorageClass 能够被标记为默认。如果它们中有两个或多个被标记为默认，Kubernetes 将忽略这个注解，也就是它将表现为没有默认 StorageClass。
+<!--
+1. Verify that your chosen StorageClass is default:
+-->
+4. 验证你选用的 StorageClass 为默认的：
+ ```bash
+ kubectl get storageclass
+ ```
-4. 验证您选用的 StorageClass 为默认的：
-
- ```bash
- kubectl get storageclass
- ```
-
- 输出类似这样：
-
- ```bash
- NAME PROVISIONER AGE
- standard kubernetes.io/gce-pd 1d
- gold (default) kubernetes.io/gce-pd 1d
- ```
-
+ <!--
+ The output is similar to this:
+ -->
+ 输出类似这样：
+ ```bash
+ NAME PROVISIONER AGE
+ standard kubernetes.io/gce-pd 1d
+ gold (default) kubernetes.io/gce-pd 1d
+ ```
## {{% heading "whatsnext" %}}
-
-* 了解更多关于 [StorageClasses](/docs/concepts/storage/persistent-volumes/)。
-
-
+<!--
+* Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/).
+-->
+* 进一步了解 [StorageClasses](/docs/concepts/storage/persistent-volumes/)
diff --git a/content/zh/docs/tasks/administer-cluster/cluster-management.md b/content/zh/docs/tasks/administer-cluster/cluster-management.md
index 0e4c3393de..c70475e6bf 100644
--- a/content/zh/docs/tasks/administer-cluster/cluster-management.md
+++ b/content/zh/docs/tasks/administer-cluster/cluster-management.md
@@ -3,130 +3,276 @@ approvers:
- lavalamp
- thockin
title: 集群管理
+content_type: task
---
+<!--
+This document describes several topics related to the lifecycle of a cluster: creating a new cluster,
+upgrading your cluster's
+master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a
+running cluster.
+-->
+本文描述了和集群生命周期相关的几个主题：创建新集群、更新集群的主控节点和工作节点、
+执行节点维护（例如升级内核）以及升级运行中集群的 Kubernetes API 版本。
-{{< toc >}}
-
-
-本文描述了和集群生命周期相关的几个主题：创建新集群、更新集群的 master 和 worker 节点、执行节点维护（例如升级内核）以及升级运行中集群的 Kubernetes API 版本。
+<!-- body -->
+<!--
+## Creating and configuring a Cluster
+To install Kubernetes on a set of machines, consult one of the existing [Getting Started guides](/docs/setup/) depending on your environment.
+-->
## 创建和配置集群
-
-要在一组机器上安装 Kubernetes， 请根据您的环境，查阅现有的 [入门指南](/docs/getting-started-guides/)
+要在一组机器上安装 Kubernetes，请根据你的环境，查阅现有的[入门指南](/zh/docs/setup/)
+<!--
+## Upgrading a cluster
+
+The current state of cluster upgrades is provider dependent, and some releases may require special care when upgrading. It is recommended that administrators consult both the [release notes](https://git.k8s.io/kubernetes/CHANGELOG/README.md), as well as the version specific upgrade notes prior to upgrading their clusters.
+-->
## 升级集群
+集群升级当前是配套提供的，某些发布版本在升级时可能需要特殊处理。
+推荐管理员在升级他们的集群前，同时查阅
+[发行说明](https://git.k8s.io/kubernetes/CHANGELOG.md) 和版本具体升级说明。
-集群升级当前是配套提供的，某些发布版本在升级时可能需要特殊处理。推荐管理员在升级他们的集群前，同时查阅 [发行说明](https://git.k8s.io/kubernetes/CHANGELOG.md) 和版本具体升级说明。
+<!--
+### Upgrading an Azure Kubernetes Service (AKS) cluster
+Azure Kubernetes Service enables easy self-service upgrades of the control plane and nodes in your cluster. The process is
+currently user-initiated and is described in the [Azure AKS documentation](https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster).
+-->
+### 升级 Azure Kubernetes Service（AKS）集群
-* [升级到 1.6](/docs/admin/upgrade-1-6)
+Azure Kubernetes Service 支持自服务式的控制面升级和集群节点升级。
+升级过程目前是由用户发起的，具体文档参见
+[Azure AKS 文档](https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster)。
+<!--
+### Upgrading Google Compute Engine clusters
+Google Compute Engine Open Source (GCE-OSS) support master upgrades by deleting and
+recreating the master, while maintaining the same Persistent Disk (PD) to ensure that data is retained across the
+upgrade.
+-->
### 升级 Google Compute Engine 集群
+Google Compute Engine Open Source（GCE-OSS）通过删除和重建主控节点来支持主控节点升级。
+通过维持相同的 Persistent Disk (PD) 以保证在升级过程中保留数据。
-Google Compute Engine Open Source (GCE-OSS) 通过删除和重建 master 来支持 master 升级。通过维持相同的 Persistent Disk (PD) 以保证在升级过程中保留数据。
+<!--
+Node upgrades for GCE use a [Managed Instance Group](https://cloud.google.com/compute/docs/instance-groups/), each node
+is sequentially destroyed and then recreated with new software. Any Pods that are running on that node need to be
+controlled by a Replication Controller, or manually re-created after the roll out.
+-->
+GCE 的 节点升级采用[受控实例组](https://cloud.google.com/compute/docs/instance-groups/)，
+每个节点将被顺序删除，然后使用新软件重建。
+任何运行在那个节点上的 Pod 需要用副本控制器控制，或者在扩容之后手动重建。
+<!--
+Upgrades on open source Google Compute Engine (GCE) clusters are controlled by the `cluster/gce/upgrade.sh` script.
-GCE 的 Node 升级采用 [管理实例组](https://cloud.google.com/compute/docs/instance-groups/)，每个节点将被顺序的删除，然后使用新软件重建。任何运行在那个节点上的 Pod 需要用 Replication Controller 控制，或者在扩容之后手动重建。
-
+Get its usage by running `cluster/gce/upgrade.sh -h`.
+For example, to upgrade just your master to a specific version (v1.0.2):
+-->
开源 Google Compute Engine (GCE) 集群上的升级过程由 `cluster/gce/upgrade.sh` 脚本控制。
-
运行 `cluster/gce/upgrade.sh -h` 获取使用说明。
-
-例如，只将 master 升级到一个指定的版本 (v1.0.2):
+例如，只将主控节点升级到一个指定的版本（v1.0.2）：
```shell
cluster/gce/upgrade.sh -M v1.0.2
```
-
+<!--
+Alternatively, to upgrade your entire cluster to the latest stable release:
+-->
或者，将整个集群升级到最新的稳定版本：
```shell
cluster/gce/upgrade.sh release/stable
```
+<!--
+### Upgrading Google Kubernetes Engine clusters
+Google Kubernetes Engine automatically updates master components (e.g. `kube-apiserver`, `kube-scheduler`) to the latest version. It also handles upgrading the operating system and other components that the master runs on.
+-->
### 升级 Google Kubernetes Engine 集群
+Google Kubernetes Engine 自动升级主控节点组件（例如 `kube-apiserver`、`kube-scheduler`）至最新版本。
+它还负责主控节点运行的操作系统和其它组件的升级。
-Google Kubernetes Engine 自动升级 master 组件（例如 `kube-apiserver`、`kube-scheduler`）至最新版本。它还负责 master 运行的操作系统和其它组件。
+<!--
+The node upgrade process is user-initiated and is described in the [Google Kubernetes Engine documentation](https://cloud.google.com/kubernetes-engine/docs/clusters/upgrade).
+-->
+节点升级过程由用户发起，[Google Kubernetes Engine 文档](https://cloud.google.com/kubernetes-engine/docs/clusters/upgrade)中有相关描述。
+<!--
+### Upgrading an Amazon EKS Cluster
-节点升级过程由用户初始化，[Google Kubernetes Engine 文档](https://cloud.google.com/kubernetes-engine/docs/clusters/upgrade) 里有相关描述。
+Amazon EKS cluster's master components can be upgraded by using eksctl, AWS Management Console, or AWS CLI. The process is user-initiated and is described in the [Amazon EKS documentation](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html).
+-->
+### 升级 Amazon EKS 集群
+Amazon EKS 集群的主控组件可以使用 eksctl、AWS 管理控制台或者 AWS CLI 来升级。
+升级过程由用户发起，具体参看
+[Amazon EKS 文档](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html)。
+<!--
+### Upgrading an Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) cluster
+
+Oracle creates and manages a set of master nodes in the Oracle control plane on your behalf (and associated Kubernetes infrastructure such as etcd nodes) to ensure you have a highly available managed Kubernetes control plane. You can also seamlessly upgrade these master nodes to new versions of Kubernetes with zero downtime. These actions are described in the [OKE documentation](https://docs.cloud.oracle.com/iaas/Content/ContEng/Tasks/contengupgradingk8smasternode.htm).
+-->
+### 升级 Oracle Cloud Infrastructure 上的 Container Engine for Kubernetes (OKE) 集群
+
+Oracle 在 Oracle 控制面替你创建和管理一组主控节点（及相关的 Kubernetes 基础设施，
+如 etcd 节点）。你可以在不停机的情况下无缝升级这些主控节点到新的 Kubernetes 版本。
+相关的操作可参考
+[OKE 文档](https://docs.cloud.oracle.com/iaas/Content/ContEng/Tasks/contengupgradingk8smasternode.htm)。
+
+<!--
+### Upgrading clusters on other platforms
+
+Different providers, and tools, will manage upgrades differently. It is recommended that you consult their main documentation regarding upgrades.
+-->
### 在其他平台上升级集群
-
-不同的供应商和工具管理升级的过程各不相同。建议您查阅它们有关升级的主要文档。
+不同的供应商和工具管理升级的过程各不相同。建议你查阅它们有关升级的主要文档。
* [kops](https://github.com/kubernetes/kops)
* [kubespray](https://github.com/kubernetes-incubator/kubespray)
* [CoreOS Tectonic](https://coreos.com/tectonic/docs/latest/admin/upgrade.html)
+* [Digital Rebar](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html)
* ...
+<!--
+To upgrade a cluster on a platform not mentioned in the above list, check the order of component upgrade on the
+[Skewed versions](/docs/setup/release/version-skew-policy/#supported-component-upgrade-order) page.
+-->
+要在上面列表中没有提及的平台上升级集群时，请参阅
+[版本偏差](/zh/docs/setup/release/version-skew-policy/#supported-component-upgrade-order)
+页面所讨论的组件升级顺序。
+<!--
+## Resizing a cluster
+
+If your cluster runs short on resources you can easily add more machines to it if your cluster
+is running in [Node self-registration mode](/docs/concepts/architecture/nodes/#self-registration-of-nodes).
+If you're using GCE or Google Kubernetes Engine it's done by resizing the Instance Group managing your Nodes.
+It can be accomplished by modifying number of instances on
+`Compute > Compute Engine > Instance groups > your group > Edit group`
+[Google Cloud Console page](https://console.developers.google.com) or using gcloud CLI:
+-->
## 调整集群大小
-
-如果集群资源短缺，您可以轻松的添加更多的机器，如果集群正运行在[节点自注册模式](/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 都可以完成这个任务。
+如果集群资源短缺，且集群正运行在
+[节点自注册模式](/zh/docs/concepts/architecture/nodes/#self-registration-of-nodes)，
+你可以轻松地添加更多的机器。
+如果正在使用的是 GCE 或者 Google Kubernetes Engine，添加节点将通过调整管理节点的实例组的大小完成。
+在 [Google Cloud 控制台](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
```
+<!--
+The Instance Group will take care of putting appropriate image on new machines and starting them,
+while the Kubelet will register its Node with the API server to make it available for scheduling.
+If you scale the instance group down, system will randomly choose Nodes to kill.
+-->
+实例组将负责在新机器上放置恰当的镜像并启动它们。
+kubelet 将向 API 服务器注册它的节点以使其可以用于调度。
+如果你对实例组进行缩容，系统将会随机选取节点来终止。
-实例组将负责在新机器上放置恰当的镜像并启动它们。Kubelet 将向 API server 注册它的节点以使其可以用于调度。如果您对 instance group 进行缩容，系统将会随机选取节点来终止。
-
-
-在其他环境上，您可能需要手动配置机器并告诉 Kubelet API server 在哪台机器上运行。
+<!--
+In other environments you may need to configure the machine yourself and tell the Kubelet on which machine API server is running.
+-->
+在其他环境中，你可能需要手动配置机器并告诉 kubelet API 服务器在哪台机器上运行。
+<!--
+### Cluster autoscaling
+If you are using GCE or Google Kubernetes Engine, you can configure your cluster so that it is automatically rescaled based on
+pod needs.
+-->
### 集群自动伸缩
+如果正在使用 GCE 或者 Google Kubernetes Engine，你可以配置你的集群，
+使其能够基于 Pod 需求自动重新调整大小。
-如果正在使用 GCE 或者 Google Kubernetes Engine，您可以配置您的集群，使其能够基于 pod 需求自动重新调整大小。
+<!--
+As described in [Compute Resource](/docs/concepts/configuration/manage-resources-containers/),
+users can reserve how much CPU and memory is allocated to pods.
+This information is used by the Kubernetes scheduler to find a place to run the pod. If there is
+no node that has enough free capacity (or doesn't match other pod requirements) then the pod has
+to wait until some pods are terminated or a new node is added.
+-->
+如[计算资源](/zh/docs/concepts/configuration/manage-resources-containers/)所述，
+用户可以控制预留多少 CPU 和内存来分配给 Pod。
+这个信息被 Kubernetes 调度器用来寻找一个运行 Pod 的地方。
+如果没有一个节点有足够的空闲容量（或者不能满足 Pod 的其他需求），
+这个 Pod 就需要等待某些 Pod 结束，或者一个新的节点被添加。
+<!--
+Cluster autoscaler looks for the pods that cannot be scheduled and checks if adding a new node, similar
+to the other in the cluster, would help. If yes, then it resizes the cluster to accommodate the waiting pods.
+-->
+集群 Autoscaler 查找不能被调度的 Pod 并检查添加一个新节点（和集群中其它节点类似的）
+是否有帮助。如果是的话，它将调整集群的大小以容纳等待调度的 Pod。
-如 [Compute Resource](/docs/concepts/configuration/manage-compute-resources-container/) 所述，用户可以控制预留多少 CPU 和内存来分配给 pod。这个信息被 Kubernetes scheduler 用来寻找一个运行 pod 的地方。如果没有一个节点有足够的空闲容量（或者不能满足其他 pod 的需求），这个 pod 就需要等待某些 pod 结束，或者一个新的节点被添加。
+<!--
+Cluster autoscaler also scales down the cluster if it notices that one or more nodes are not needed anymore for
+an extended period of time (10min but it may change in the future).
+-->
+如果发现在一段延时时间内（默认 10 分钟，将来有可能改变）某些节点不再需要，
+集群 Autoscaler 也会缩小集群。
+<!--
+Cluster autoscaler is configured per instance group (GCE) or node pool (Google Kubernetes Engine).
+-->
+集群 Autoscaler 基于每个实例组（GCE）或节点池（Google Kubernetes Engine）来配置。
-集群 autoscaler 查找不能被调度的 pod 并检查添加一个新节点（和集群中其它节点类似的）是否有帮助。如果是的话，它将调整集群的大小以容纳等待调度的 pod。
+<!--
+If you are using GCE then you can either enable it while creating a cluster with kube-up.sh script.
+To configure cluster autoscaler you have to set three environment variables:
+-->
+如果你使用 GCE，那么你可以在使用 kube-up.sh 脚本创建集群的时候启用集群自动扩缩。
+要想配置集群 Autoscaler，你需要设置三个环境变量：
+<!--
+* `KUBE_ENABLE_CLUSTER_AUTOSCALER` - it enables cluster autoscaler if set to true.
+* `KUBE_AUTOSCALER_MIN_NODES` - minimum number of nodes in the cluster.
+* `KUBE_AUTOSCALER_MAX_NODES` - maximum number of nodes in the cluster.
-如果发现在一段延时时间内（默认10分钟，将来有可能改变）某些节点不再需要，集群 autoscaler 也会缩小集群。
-
-
-集群 autoscaler 在每一个实例组（GCE）或节点池（Google Kubernetes Engine）上配置。
-
-
-如果您使用 GCE，那么您可以在使用 kube-up.sh 脚本创建集群的时候启用它。要想配置集群 autoscaler，您需要设置三个环境变量：
-
-
-* `KUBE_ENABLE_CLUSTER_AUTOSCALER` - 如果设置为 true 将启用集群 autoscaler。
+Example:
+-->
+* `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
```
+<!--
+On Google Kubernetes Engine you configure cluster autoscaler either on cluster creation or update or when creating a particular node pool
+(which you want to be autoscaled) by passing flags `--enable-autoscaling` `--min-nodes` and `--max-nodes`
+to the corresponding `gcloud` commands.
-在 Google Kubernetes Engine 上，您可以在创建、更新集群或创建一个特别的节点池（您希望自动伸缩的）时，通过给对应的 `gcloud` 命令传递 `--enable-autoscaling` `--min-nodes` 和 `--max-nodes` 来配置集群 autoscaler。
-
+Examples:
+-->
+在 Google Kubernetes Engine 上，你可以在创建、更新集群或创建一个特别的（你希望自动伸缩的）
+节点池时，通过给对应的 `gcloud` 命令传递 `--enable-autoscaling`、`--min-nodes` 和
+`--max-nodes` 来配置集群 Autoscaler。
示例：
@@ -139,88 +285,168 @@ gcloud container clusters update mytestcluster --enable-autoscaling --min-nodes=
```
-**集群 autoscaler 期望节点未被手动修改过（例如通过 kubectl 添加标签），因为那些属性可能不能被传递到相同节点组中的新节点上。**
+<!--
+**Cluster autoscaler expects that nodes have not been manually modified (e.g. by adding labels via kubectl) as those properties would not be propagated to the new nodes within the same instance group.**
+
+For more details about how the cluster autoscaler decides whether, when and how
+to scale a cluster, please refer to the [FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)
+documentation from the autoscaler project.
+-->
+
+**集群 Autoscaler 期望节点未被手动修改过（例如通过 kubectl 添加标签），因自行指定的属性
+可能不能被传递到相同节点组中的新节点上。**
+
+关于集群 Autoscaler 如何决定是否、合适以及怎样对集群进行缩放的细节，请参考 autoscaler 项目的
+[FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)
+文档。
+<!--
+## Maintenance on a Node
+
+If you need to reboot a node (such as for a kernel upgrade, libc upgrade, hardware repair, etc.), and the downtime is
+brief, then when the Kubelet restarts, it will attempt to restart the pods scheduled to it. If the reboot takes longer
+(the default time is 5 minutes, controlled by `-pod-eviction-timeout` on the controller-manager),
+then the node controller will terminate the pods that are bound to the unavailable node. If there is a corresponding
+replica set (or replication controller), then a new copy of the pod will be started on a different node. So, in the case where all
+pods are replicated, upgrades can be done without special coordination, assuming that not all nodes will go down at the same time.
+-->
## 维护节点
+如果需要重启节点（例如内核升级、libc 升级、硬件维修等），且停机时间很短时，
+kubelet 重启后，将尝试重启调度到节点上的 Pod。如果重启花费较长时间（默认时间为 5 分钟，由
+控制器管理器的 `--pod-eviction-timeout` 控制），节点控制器将会结束绑定到这个不可用节点上的 Pod。
+如果存在对应的 ReplicaSet（或者 ReplicationController），则将在另一个节点上启动 Pod 的新副本。
+所以，如果所有的 Pod 都是多副本的，那么在不是所有节点都同时停机的前提下，升级可以在不需要特殊
+调整情况下完成。
-如果需要重启节点（例如内核升级、libc 升级、硬件维修等），且停机时间很短时，当 Kubelet 重启后，它将尝试重启调度到节点上的 pod。如果重启花费较长时间（默认时间为 5 分钟，由 controller-manager 的 `--pod-eviction-timeout` 控制），节点控制器将会结束绑定到这个不可用节点上的 pod。如果存在对应的 replica set（或者 replication controller）时，则将在另一个节点上启动 pod 的新副本。所以，如果所有的 pod 都是复制而来，那么在不是所有节点都同时停机的前提下，升级可以在不需要特殊调整情况下完成。
+<!--
+If you want more control over the upgrading process, you may use the following workflow:
+Use `kubectl drain` to gracefully terminate all pods on the node while marking the node as unschedulable:
+-->
+如果你希望对升级过程有更多的控制，可以使用下面的工作流程：
-如果您希望更多的控制升级过程，可以使用下面的工作流程：
-
-
-使用 `kubectl drain` 优雅的结束节点上的所有 pod 并同时标记节点为不可调度：
+使用 `kubectl drain` 体面地结束节点上的所有 Pod 并同时标记节点为不可调度：
```shell
kubectl drain $NODENAME
```
+<!--
+This keeps new pods from landing on the node while you are trying to get them off.
-在您正试图使节点离线时，这将阻止新的 pod 落到它们上面。
+For pods with a replica set, the pod will be replaced by a new pod which will be scheduled to a new node. Additionally, if the pod is part of a service, then clients will automatically be redirected to the new pod.
+-->
+在你试图使节点离线时，这样做将阻止新的 Pod 落到它们上面。
+对于有 ReplicaSet 的 Pod 来说，它们将会被新的 Pod 替换并且将被调度到一个新的节点。
+此外，如果 Pod 是一个 Service 的一部分，则客户端将被自动重定向到新的 Pod。
-对于有 replica set 的 pod 来说，它们将会被新的 pod 替换并且将被调度到一个新的节点。此外，如果 pod 是一个 service 的一部分，则客户端将被自动重定向到新的 pod。
+<!--
+For pods with no replica set, you need to bring up a new copy of the pod, and assuming it is not part of a service, redirect clients to it.
+Perform maintenance work on the node.
-对于没有 replica set 的 pod，您需要手动启动 pod 的新副本，并且如果它不是 service 的一部分，您需要手动将客户端重定向到这个 pod。
-
+Make the node schedulable again:
+-->
+对于没有 ReplicaSet 的 Pod，你需要手动启动 Pod 的新副本，并且
+如果它不是 Service 的一部分，你需要手动将客户端重定向到这个 Pod。
在节点上执行维护工作。
-
重新使节点可调度：
```shell
kubectl uncordon $NODENAME
```
+<!--
+If you deleted the node's VM instance and created a new one, then a new schedulable node resource will
+be created automatically (if you're using a cloud provider that supports
+node discovery; currently this is only Google Compute Engine, not including CoreOS on Google Compute Engine using kube-register).
+See [Node](/docs/concepts/architecture/nodes/) for more details.
+-->
+如果删除了节点的虚拟机实例并重新创建，那么一个新的可调度节点资源将被自动创建
+（只在你使用支持节点发现的云服务提供商时；当前只有 Google Compute Engine，
+不包括在 Google Compute Engine 上使用 kube-register 的 CoreOS）。
+相关详细信息，请查阅[节点](/zh/docs/concepts/architecture/nodes/)。
-如果删除了节点的虚拟机实例并重新创建，那么一个新的可调度节点资源将被自动创建（只在您使用支持节点发现的云服务提供商时；当前只有 Google Compute Engine，不包括在 Google Compute Engine 上使用 kube-register 的 CoreOS）。相关详细信息，请查阅 [节点](/docs/admin/node)。
+<!--
+## Advanced Topics
+### Upgrading to a different API version
+When a new API version is released, you may need to upgrade a cluster to support the new API version (e.g. switching from 'v1' to 'v2' when 'v2' is launched).
+-->
## 高级主题
-
### 升级到不同的 API 版本
+当新的 API 版本发布时，你可能需要升级集群支持新的 API 版本
+（例如当 'v2' 发布时从 'v1' 切换到 'v2'）。
-当新的 API 版本发布时，您可能需要升级集群支持新的 API 版本（例如当 'v2' 发布时从 'v1' 切换到 'v2'）。
-
+<!--
+This is an infrequent event, but it requires careful management. There is a sequence of steps to upgrade to a new API version.
+ 1. Turn on the new API version.
+ 1. Upgrade the cluster's storage to use the new version.
+ 1. Upgrade all config files. Identify users of the old API version endpoints.
+ 1. Update existing objects in the storage to new version by running `cluster/update-storage-objects.sh`.
+ 1. Turn off the old API version.
+-->
这不是一个经常性的事件，但需要谨慎的处理。这里有一系列升级到新 API 版本的步骤。
- 1. 开启新 API 版本。
- 2. 升级集群存储来使用新版本。
- 3. 升级所有配置文件。识别使用旧 API 版本 endpoint 的用户。
- 4. 运行 `cluster/update-storage-objects.sh` 升级存储中的现有对象为新版本。
- 5. 关闭旧 API 版本。
+1. 开启新 API 版本
+1. 升级集群存储来使用新版本
+1. 升级所有配置文件；识别使用旧 API 版本末端的用户
+1. 运行 `cluster/update-storage-objects.sh` 升级存储中的现有对象为新版本
+1. 关闭旧 API 版本
+<!--
+### Turn on or off an API version for your cluster
+Specific API versions can be turned on or off by passing `-runtime-config=api/<version>` flag while bringing up the API server. For example: to turn off v1 API, pass `--runtime-config=api/v1=false`.
+runtime-config also supports 2 special keys: api/all and api/legacy to control all and legacy APIs respectively.
+For example, for turning off all API versions except v1, pass `--runtime-config=api/all=false,api/v1=true`.
+For the purposes of these flags, _legacy_ APIs are those APIs which have been explicitly deprecated (e.g. `v1beta3`).
+-->
### 打开或关闭集群的 API 版本
+可以在启动 API 服务器时传递 `--runtime-config=api/<version>` 标志来打开或关闭特定的 API 版本。
+例如：要关闭 v1 API，请传递 `--runtime-config=api/v1=false`。
+`runtime-config` 还支持两个特殊键值：`api/all` 和 `api/legacy`，分别控制全部和遗留 API。
+例如要关闭除 v1 外全部 API 版本，请传递 `--runtime-config=api/all=false,api/v1=true`。
+对于这些标志来说，_遗留（Legacy）_ API 指的是那些被显式废弃的 API（例如 `v1beta3`）。
-可以在启动 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`）。
-
+<!--
+### Switching your cluster's storage API version
+The objects that are stored to disk for a cluster's internal representation of the Kubernetes resources active in the cluster are written using a particular version of the API.
+When the supported API changes, these objects may need to be rewritten in the newer API. Failure to do this will eventually result in resources that are no longer decodable or usable
+by the Kubernetes API server.
+-->
### 切换集群存储的 API 版本
+存储于磁盘中、用于在集群内部代表 Kubernetes 活跃资源的对象使用特定的 API 版本表达。
+当所支持的 API 改变时，这些对象可能需要使用更新的 API 重写。
+重写失败将最终导致资源不再能够被 Kubernetes API server 解析或使用。
-存储于磁盘中，用于在集群内部代表 Kubernetes 活跃资源的对象使用特定的 API 版本书写。当支撑的 API 改变时，这些对象可能需要使用更新的 API 重写。重写失败将最终导致资源不再能够被 Kubernetes API server 解析或使用。
+<!--
+### Switching your config files to a new API version
+You can use `kubectl convert` command to convert config files between different API versions.
+-->
+### 切换配置文件到新 API 版本
-`kube-apiserver` 二进制文件的 `KUBE_API_VERSIONS` 环境变量控制了集群支持的 API 版本。列表中的第一个版本被用作集群的存储版本。因此，要设置特定的版本为存储版本，请将其放在 `KUBE_API_VERSIONS` 参数值版本列表的最前面。您需要重启 `kube-apiserver` 二进制以使这个变量的改动生效。
-
-
-### 切换配置文件为新 API 版本
-
-
-可以使用 `kubectl convert` 命令对不同 API 版本的配置文件进行转换。
+你可以使用 `kubectl convert` 命令对不同 API 版本的配置文件进行转换。
```shell
kubectl convert -f pod.yaml --output-version v1
```
+<!--
+For more options, please refer to the usage of [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) command.
+-->
+更多选项请参考 [`kubectl convert`](/docs/reference/generated/kubectl/kubectl-commands/#convert) 命令用法。
-更多选项请参考 [kubectl convert](/docs/user-guide/kubectl/v1.6/#convert) 命令用法。
diff --git a/content/zh/docs/tasks/administer-cluster/coredns.md b/content/zh/docs/tasks/administer-cluster/coredns.md
index 23e881485f..f68ce54759 100644
--- a/content/zh/docs/tasks/administer-cluster/coredns.md
+++ b/content/zh/docs/tasks/administer-cluster/coredns.md
@@ -1,19 +1,15 @@
---
-reviewers:
-- johnbelamaric
title: 使用 CoreDNS 进行服务发现
min-kubernetes-server-version: v1.9
content_type: task
---
<!--
----
reviewers:
- johnbelamaric
title: Using CoreDNS for Service Discovery
min-kubernetes-server-version: v1.9
content_type: task
----
-->
<!-- overview -->
@@ -23,55 +19,50 @@ This page describes the CoreDNS upgrade process and how to install CoreDNS inste
-->
此页面介绍了 CoreDNS 升级过程以及如何安装 CoreDNS 而不是 kube-dns。
-
-
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
<!-- steps -->
<!--
## About CoreDNS
--->
-## 关于 CoreDNS
-
-<!--
[CoreDNS](https://coredns.io) is a flexible, extensible DNS server that can serve as the Kubernetes cluster DNS.
Like Kubernetes, the CoreDNS project is hosted by the {{< glossary_tooltip text="CNCF" term_id="cncf" >}}.
-->
-[CoreDNS](https://coredns.io) 是一个灵活可扩展的 DNS 服务器，可以作为 Kubernetes 集群 DNS。与 Kubernetes 一样，CoreDNS 项目由 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} 托管。
+## 关于 CoreDNS
+
+[CoreDNS](https://coredns.io) 是一个灵活可扩展的 DNS 服务器，可以作为 Kubernetes 集群 DNS。
+与 Kubernetes 一样，CoreDNS 项目由 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} 托管。
<!--
You can use CoreDNS instead of kube-dns in your cluster by replacing kube-dns in an existing
deployment, or by using tools like kubeadm that will deploy and upgrade the cluster for you.
-->
-通过在现有的集群中替换 kube-dns，可以在集群中使用 CoreDNS 代替 kube-dns 部署，或者使用 kubeadm 等工具来为您部署和升级集群。
+通过在现有的集群中替换 kube-dns，可以在集群中使用 CoreDNS 代替 kube-dns 部署，
+或者使用 kubeadm 等工具来为你部署和升级集群。
<!--
## Installing CoreDNS
--->
-## 安装 CoreDNS
-
-<!--
For manual deployment or replacement of kube-dns, see the documentation at the
[CoreDNS GitHub project.](https://github.com/coredns/deployment/tree/master/kubernetes)
-->
-有关手动部署或替换 kube-dns，请参阅 [CoreDNS GitHub 工程](https://github.com/coredns/deployment/tree/master/kubernetes)。
+## 安装 CoreDNS
+
+有关手动部署或替换 kube-dns，请参阅
+[CoreDNS GitHub 工程](https://github.com/coredns/deployment/tree/master/kubernetes)。
<!--
## Migrating to CoreDNS
+
+### Upgrading an existing cluster with kubeadm
-->
+
## 迁移到 CoreDNS
-<!--
-## Upgrading an existing cluster with kubeadm
--->
-
-## 使用 kubeadm 升级现有集群
+### 使用 kubeadm 升级现有集群
<!--
In Kubernetes version 1.10 and later, you can also move to CoreDNS when you use `kubeadm` to upgrade
@@ -79,14 +70,16 @@ a cluster that is using `kube-dns`. In this case, `kubeadm` will generate the Co
("Corefile") based upon the `kube-dns` ConfigMap, preserving configurations for federation,
stub domains, and upstream name server.
-->
-在 Kubernetes 1.10 及更高版本中，当您使用 `kubeadm` 升级使用 `kube-dns` 的集群时，您还可以迁移到 CoreDNS。
-在本例中 `kubeadm` 将生成 CoreDNS 配置（"Corefile"）基于 `kube-dns` ConfigMap，保存联邦、存根域和上游名称服务器的配置。
+在 Kubernetes 1.10 及更高版本中，当你使用 `kubeadm` 升级使用 `kube-dns` 的集群时，你还可以迁移到 CoreDNS。
+在本例中 `kubeadm` 将生成 CoreDNS 配置（"Corefile"）基于 `kube-dns` ConfigMap，
+保存联邦、存根域和上游名称服务器的配置。
<!--
If you are moving from kube-dns to CoreDNS, make sure to set the `CoreDNS` feature gate to `true`
during an upgrade. For example, here is what a `v1.11.0` upgrade would look like:
-->
-如果您正在从 kube-dns 迁移到 CoreDNS，请确保在升级期间将 `CoreDNS` 特性门设置为 `true`。例如，`v1.11.0` 升级应该是这样的:
+如果你正在从 kube-dns 迁移到 CoreDNS，请确保在升级期间将 `CoreDNS` 特性门设置为 `true`。
+例如，`v1.11.0` 升级应该是这样的:
```
kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true
@@ -98,8 +91,8 @@ is used by default. Follow the guide outlined [here](/docs/reference/setup-tools
your upgraded cluster to use kube-dns.
-->
在 Kubernetes 版本 1.13 和更高版本中，`CoreDNS`特性门已经删除，CoreDNS 在默认情况下使用。
-如果您想升级集群以使用 kube-dns，请遵循
-[此处](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon) 。
+如果你想升级集群以使用 kube-dns，请遵循
+[此处](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon) 。
<!--
In versions prior to 1.11 the Corefile will be **overwritten** by the one created during upgrade.
@@ -107,86 +100,92 @@ In versions prior to 1.11 the Corefile will be **overwritten** by the one create
customizations after the new ConfigMap is up and running.
-->
在 1.11 之前的版本中，核心文件将被升级过程中创建的文件覆盖。
-**如果已对其进行自定义，则应保存现有的 ConfigMap。** 在新的 ConfigMap 启动并运行后，您可以重新应用自定义。
+**如果已对其进行自定义，则应保存现有的 ConfigMap。**
+在新的 ConfigMap 启动并运行后，你可以重新应用自定义。
<!--
If you are running CoreDNS in Kubernetes version 1.11 and later, during upgrade,
your existing Corefile will be retained.
-->
-如果您在 Kubernetes 1.11 及更高版本中运行 CoreDNS，则在升级期间，将保留现有的 Corefile。
+如果你在 Kubernetes 1.11 及更高版本中运行 CoreDNS，则在升级期间，将保留现有的 Corefile。
<!--
## Installing kube-dns instead of CoreDNS with kubeadm
-->
## 使用 kubeadm 安装 kube-dns 而不是 CoreDNS
-{{< note >}}
-
<!--
In Kubernetes 1.11, CoreDNS has graduated to General Availability (GA)
and is installed by default.
-->
-在 Kubernetes 1.11 中，CoreDNS 已经升级到通用可用性(GA)，并默认安装。
-
+{{< note >}}
+在 Kubernetes 1.11 中，CoreDNS 已经升级到通用可用性（GA），并默认安装。
{{< /note >}}
+<!--
+In Kubernetes 1.18, kube-dns usage with kubeadm has been deprecated and will be removed in a future version.
+-->
+{{< warning >}}
+在 Kubernetes 1.18 中，用 kubeadm 来安装 kube-dns 这一做法已经被废弃，
+会在将来版本中移除。
+{{< /warning >}}
+
<!--
To install kube-dns on versions prior to 1.13, set the `CoreDNS` feature gate
value to `false`:
-->
-若要在1.13之前到版本上安装 kube-dns，请将 `CoreDNS` 特性门值设置为 `false`：
+若要在 1.13 之前版本上安装 kube-dns，请将 `CoreDNS` 特性门控设置为 `false`：
-```
+```shell
kubeadm init --feature-gates=CoreDNS=false
```
<!--
For versions 1.13 and later, follow the guide outlined [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon).
-->
-对于 1.13 版和更高版本，请遵循[此处](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)概述到指南。
+对于 1.13 版和更高版本，请遵循
+[此处](/zh/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)概述到指南。
<!--
## Upgrading CoreDNS
--->
-## 升级 CoreDNS
-<!--
CoreDNS is available in Kubernetes since v1.9.
You can check the version of CoreDNS shipped with Kubernetes and the changes made to CoreDNS [here](https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md).
-->
+## 升级 CoreDNS
+
从 v1.9 起，Kubernetes 提供了 CoreDNS。
-您可以在[此处](https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md)检查 Kubernetes 随附的 CoreDNS 版本以及对 CoreDNS 所做的更改。
+你可以在[此处](https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md)
+查看 Kubernetes 随附的 CoreDNS 版本以及对 CoreDNS 所做的更改。
<!--
CoreDNS can be upgraded manually in case you want to only upgrade CoreDNS or use your own custom image.
There is a helpful [guideline and walkthrough](https://github.com/coredns/deployment/blob/master/kubernetes/Upgrading_CoreDNS.md) available to ensure a smooth upgrade.
-->
-如果您只想升级 CoreDNS 或使用自己的自定义镜像，则可以手动升级 CoreDNS。
+如果你只想升级 CoreDNS 或使用自己的自定义镜像，则可以手动升级 CoreDNS。
+参看[指南和演练](https://github.com/coredns/deployment/blob/master/kubernetes/Upgrading_CoreDNS.md)
+文档了解如何平滑升级。
+
<!--
## Tuning CoreDNS
--->
-## CoreDNS 调优
-
-<!--
When resource utilisation is a concern, it may be useful to tune the configuration of CoreDNS. For more details, check out the
[documentation on scaling CoreDNS]((https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md)).
-->
-当涉及到资源利用时，优化内核的配置可能是有用的。有关详细信息，请参阅 [关于扩展 CoreDNS 的文档](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md)。
-
+## CoreDNS 调优
+当资源利用方面有问题时，优化 CoreDNS 的配置可能是有用的。
+有关详细信息，请参阅[有关扩缩 CoreDNS 的文档](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md)。
## {{% heading "whatsnext" %}}
-
<!--
You can configure [CoreDNS](https://coredns.io) to support many more use cases than
kube-dns by modifying the `Corefile`. For more information, see the
[CoreDNS site](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/).
-->
-您可以通过修改 `Corefile` 来配置 [CoreDNS](https://coredns.io)，以支持比 ku-dns 更多的用例。有关更多信息，请参考 [CoreDNS 网站](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/)。
-
-
-
+你可以通过修改 `Corefile` 来配置 [CoreDNS](https://coredns.io)，以支持比 kube-dns 更多的用例。
+请参考 [CoreDNS 网站](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/)
+以了解更多信息。
diff --git a/content/zh/docs/tasks/administer-cluster/cpu-management-policies.md b/content/zh/docs/tasks/administer-cluster/cpu-management-policies.md
index c3960f1c28..a264ee538a 100644
--- a/content/zh/docs/tasks/administer-cluster/cpu-management-policies.md
+++ b/content/zh/docs/tasks/administer-cluster/cpu-management-policies.md
@@ -1,20 +1,15 @@
---
title: 控制节点上的 CPU 管理策略
-reviewers:
-- sjenning
-- ConnorDoyle
-- balajismaniam
content_type: task
---
<!--
-
title: Control CPU Management Policies on the Node
reviewers:
- sjenning
- ConnorDoyle
- balajismaniam
content_type: task
---->
+-->
<!-- overview -->
@@ -27,19 +22,15 @@ stronger guarantees in terms of latency and/or performance in order to operate
acceptably. The kubelet provides methods to enable more complex workload
placement policies while keeping the abstraction free from explicit placement
directives.
---->
-按照设计，Kubernetes 对 pod 执行相关的很多方面进行了抽象，使得用户不必关心。然
-而，为了正常运行，有些工作负载要求在延迟和/或性能方面有更强的保证。 为此，kubelet 提供方法来实现更复杂的负载放置策略，同时保持抽象，避免显式的放置指令。
-
-
+-->
+按照设计，Kubernetes 对 pod 执行相关的很多方面进行了抽象，使得用户不必关心。
+然而，为了正常运行，有些工作负载要求在延迟和/或性能方面有更强的保证。
+为此，kubelet 提供方法来实现更复杂的负载放置策略，同时保持抽象，避免显式的放置指令。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
<!-- steps -->
<!--
@@ -51,38 +42,38 @@ the workload can move to different CPU cores depending on
whether the pod is throttled and which CPU cores are available at
scheduling time. Many workloads are not sensitive to this migration and thus
work fine without any intervention.
---->
+-->
## CPU 管理策略
-默认情况下，kubelet 使用 [CFS 配额](https://en.wikipedia.org/wiki/Completely_Fair_Scheduler) 来执行 pod 的 CPU 约束。当节点上运行了很多 CPU 密集的 pod 时，工作负载可能会迁移到不同的 CPU 核，这取决于调度时 pod 是否被扼制，以及哪些 CPU 核是可用的。许多工作负载对这种迁移不敏感，因此无需任何干预即可正常工作。
+默认情况下，kubelet 使用 [CFS 配额](https://en.wikipedia.org/wiki/Completely_Fair_Scheduler)
+来执行 Pod 的 CPU 约束。
+当节点上运行了很多 CPU 密集的 Pod 时，工作负载可能会迁移到不同的 CPU 核，
+这取决于调度时 Pod 是否被扼制，以及哪些 CPU 核是可用的。
+许多工作负载对这种迁移不敏感，因此无需任何干预即可正常工作。
<!--
However, in workloads where CPU cache affinity and scheduling latency
significantly affect workload performance, the kubelet allows alternative CPU
management policies to determine some placement preferences on the node.
---->
-然而，有些工作负载的性能明显地受到 CPU 缓存亲和性以及调度延迟的影响，对此，kubelet 提供了可选的 CPU 管理策略，来确定节点上的一些分配偏好。
+-->
+然而，有些工作负载的性能明显地受到 CPU 缓存亲和性以及调度延迟的影响。
+对此，kubelet 提供了可选的 CPU 管理策略，来确定节点上的一些分配偏好。
<!--
### Configuration
-The CPU Manager is an alpha feature in Kubernetes v1.8. It was enabled by
-default as a beta feature since v1.10.
-
-The CPU Manager policy is set with the `--cpu-manager-policy` kubelet
+The CPU Manager policy is set with the `-cpu-manager-policy` kubelet
option. There are two supported policies:
---->
+-->
### 配置
-CPU 管理器（CPU Manager）作为 alpha 特性引入 Kubernetes 1.8 版本。从 1.10 版本开始，作为 beta 特性默认开启。
-
CPU 管理策略通过 kubelet 参数 `--cpu-manager-policy` 来指定。支持两种策略：
<!--
* `none`: the default, which represents the existing scheduling behavior.
* `static`: allows pods with certain resource characteristics to be
granted increased CPU affinity and exclusivity on the node.
---->
+-->
* `none`: 默认策略，表示现有的调度行为。
* `static`: 允许为节点上具有某些资源特征的 pod 赋予增强的 CPU 亲和性和独占性。
@@ -90,10 +81,12 @@ CPU 管理策略通过 kubelet 参数 `--cpu-manager-policy` 来指定。支持
The CPU manager periodically writes resource updates through the CRI in
order to reconcile in-memory CPU assignments with cgroupfs. The reconcile
frequency is set through a new Kubelet configuration value
-`--cpu-manager-reconcile-period`. If not specified, it defaults to the same
-duration as `--node-status-update-frequency`.
---->
-CPU 管理器定期通过 CRI 写入资源更新，以保证内存中 CPU 分配与 cgroupfs 一致。同步频率通过新增的 Kubelet 配置参数 `--cpu-manager-reconcile-period` 来设置。 如果不指定，默认与 `--node-status-update-frequency` 的周期相同。
+`-cpu-manager-reconcile-period`. If not specified, it defaults to the same
+duration as `-node-status-update-frequency`.
+-->
+CPU 管理器定期通过 CRI 写入资源更新，以保证内存中 CPU 分配与 cgroupfs 一致。
+同步频率通过新增的 Kubelet 配置参数 `--cpu-manager-reconcile-period` 来设置。
+如果不指定，默认与 `--node-status-update-frequency` 的周期相同。
<!--
### None policy
@@ -103,10 +96,12 @@ affinity scheme, providing no affinity beyond what the OS scheduler does
automatically. Limits on CPU usage for
[Guaranteed pods](/docs/tasks/configure-pod-container/quality-service-pod/)
are enforced using CFS quota.
---->
-### None 策略
+-->
+### none 策略
-`none` 策略显式地启用现有的默认 CPU 亲和方案，不提供操作系统调度器默认行为之外的亲和性策略。 通过 CFS 配额来实现 [Guaranteed pods](/docs/tasks/configure-pod-container/quality-service-pod/) 的 CPU 使用限制。
+`none` 策略显式地启用现有的默认 CPU 亲和方案，不提供操作系统调度器默认行为之外的亲和性策略。
+通过 CFS 配额来实现 [Guaranteed pods](/zh/docs/tasks/configure-pod-container/quality-service-pod/)
+的 CPU 使用限制。
<!--
### Static policy
@@ -114,40 +109,30 @@ are enforced using CFS quota.
The `static` policy allows containers in `Guaranteed` pods with integer CPU
`requests` access to exclusive CPUs on the node. This exclusivity is enforced
using the [cpuset cgroup controller](https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt).
---->
-### Static 策略
+-->
+### static 策略
-`static` 策略针对具有整数型 CPU `requests` 的 `Guaranteed` pod ，它允许该类 pod 中的容器访问节点上的独占 CPU 资源。这种独占性是使用 [cpuset cgroup 控制器](https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt) 来实现的。
+`static` 策略针对具有整数型 CPU `requests` 的 `Guaranteed` Pod ，它允许该类 Pod
+中的容器访问节点上的独占 CPU 资源。这种独占性是使用
+[cpuset cgroup 控制器](https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt) 来实现的。
<!--
-{{< note >}}
System services such as the container runtime and the kubelet itself can continue to run on these exclusive CPUs. The exclusivity only extends to other pods.
-{{< /note >}}
---->
+-->
{{< note >}}
-诸如容器运行时和 kubelet 本身的系统服务可以继续在这些独占 CPU 上运行。独占性仅针对其他 pod。
+诸如容器运行时和 kubelet 本身的系统服务可以继续在这些独占 CPU 上运行。独占性仅针对其他 Pod。
{{< /note >}}
<!--
-{{< note >}}
-The alpha version of this policy does not guarantee static
-exclusive allocations across Kubelet restarts.
-{{< /note >}}
---->
-{{< note >}}
-该策略的 alpha 版本不保证 Kubelet 重启前后的静态独占性分配。
-{{< /note >}}
-
-<!--
-{{< note >}}
CPU Manager doesn't support offlining and onlining of
CPUs at runtime. Also, if the set of online CPUs changes on the node,
the node must be drained and CPU manager manually reset by deleting the
state file `cpu_manager_state` in the kubelet root directory.
-{{< /note >}}
---->
+-->
{{< note >}}
-CPU 管理器不支持运行时下线和上线 CPUs。此外，如果节点上的在线 CPUs 集合发生变化，则必须驱逐节点上的 pods，并通过删除 kubelet 根目录中的状态文件 `cpu_manager_state` 来手动重置 CPU 管理器。
+CPU 管理器不支持运行时下线和上线 CPUs。此外，如果节点上的在线 CPUs 集合发生变化，
+则必须驱逐节点上的 Pod，并通过删除 kubelet 根目录中的状态文件 `cpu_manager_state`
+来手动重置 CPU 管理器。
{{< /note >}}
<!--
@@ -172,15 +157,15 @@ exclusive CPUs.
的 CPU 集合。`Guaranteed` pod 中的容器，如果声明了非整数值的 CPU `requests` ，也将运行在共享池的 CPU 上。只有 `Guaranteed` pod 中，指定了整数型 CPU `requests` 的容器，才会被分配独占 CPU 资源。
<!--
-{{< note >}}
The kubelet requires a CPU reservation greater than zero be made
using either `--kube-reserved` and/or `--system-reserved` or `--reserved-cpus` when the static
policy is enabled. This is because zero CPU reservation would allow the shared
pool to become empty.
-{{< /note >}}
--->
{{< note >}}
-当启用 static 策略时，要求使用 `--kube-reserved` 和/或 `--system-reserved` 或 `--reserved-cpus` 来保证预留的 CPU 值大于零。 这是因为零预留 CPU 值可能使得共享池变空。
+当启用 static 策略时，要求使用 `--kube-reserved` 和/或 `--system-reserved` 或
+`--reserved-cpus` 来保证预留的 CPU 值大于零。
+这是因为零预留 CPU 值可能使得共享池变空。
{{< /note >}}
<!--
@@ -194,8 +179,12 @@ affinity and decreases context switches due to throttling for the CPU-bound
workload.
Consider the containers in the following pod specs:
---->
-当 `Guaranteed` pod 调度到节点上时，如果其容器符合静态分配要求，相应的 CPU 会被从共享池中移除，并放置到容器的 cpuset 中。因为这些容器所使用的 CPU 受到调度域本身的限制，所以不需要使用 CFS 配额来进行 CPU 的绑定。换言之，容器 cpuset 中的 CPU 数量与 pod 规格中指定的整数型 CPU `limit` 相等。这种静态分配增强了 CPU 亲和性，减少了 CPU 密集的工作负载在节流时引起的上下文切换。
+-->
+当 `Guaranteed` Pod 调度到节点上时，如果其容器符合静态分配要求，
+相应的 CPU 会被从共享池中移除，并放置到容器的 cpuset 中。
+因为这些容器所使用的 CPU 受到调度域本身的限制，所以不需要使用 CFS 配额来进行 CPU 的绑定。
+换言之，容器 cpuset 中的 CPU 数量与 Pod 规约中指定的整数型 CPU `limit` 相等。
+这种静态分配增强了 CPU 亲和性，减少了 CPU 密集的工作负载在节流时引起的上下文切换。
考虑以下 Pod 规格的容器：
@@ -209,8 +198,9 @@ spec:
<!--
This pod runs in the `BestEffort` QoS class because no resource `requests` or
`limits` are specified. It runs in the shared pool.
---->
-该 pod 属于 `BestEffort` QoS 类型，因为其未指定 `requests` 或 `limits` 值。 所以该容器运行在共享 CPU 池中。
+-->
+该 Pod 属于 `BestEffort` QoS 类型，因为其未指定 `requests` 或 `limits` 值。
+所以该容器运行在共享 CPU 池中。
```yaml
spec:
@@ -228,8 +218,9 @@ spec:
This pod runs in the `Burstable` QoS class because resource `requests` do not
equal `limits` and the `cpu` quantity is not specified. It runs in the shared
pool.
---->
-该 pod 属于 `Burstable` QoS 类型，因为其资源 `requests` 不等于 `limits`， 且未指定 `cpu` 数量。所以该容器运行在共享 CPU 池中。
+-->
+该 Pod 属于 `Burstable` QoS 类型，因为其资源 `requests` 不等于 `limits`，且未指定 `cpu` 数量。
+所以该容器运行在共享 CPU 池中。
```yaml
spec:
@@ -248,8 +239,9 @@ spec:
<!--
This pod runs in the `Burstable` QoS class because resource `requests` do not
equal `limits`. It runs in the shared pool.
---->
-该 pod 属于 `Burstable` QoS 类型，因为其资源 `requests` 不等于 `limits`。所以该容器运行在共享 CPU 池中。
+-->
+该 pod 属于 `Burstable` QoS 类型，因为其资源 `requests` 不等于 `limits`。
+所以该容器运行在共享 CPU 池中。
```yaml
spec:
@@ -269,8 +261,10 @@ spec:
This pod runs in the `Guaranteed` QoS class because `requests` are equal to `limits`.
And the container's resource limit for the CPU resource is an integer greater than
or equal to one. The `nginx` container is granted 2 exclusive CPUs.
---->
-该 pod 属于 `Guaranteed` QoS 类型，因为其 `requests` 值与 `limits`相等。同时，容器对 CPU 资源的限制值是一个大于或等于 1 的整数值。所以，该 `nginx` 容器被赋予 2 个独占 CPU。
+-->
+该 Pod 属于 `Guaranteed` QoS 类型，因为其 `requests` 值与 `limits`相等。
+同时，容器对 CPU 资源的限制值是一个大于或等于 1 的整数值。
+所以，该 `nginx` 容器被赋予 2 个独占 CPU。
```yaml
spec:
@@ -290,8 +284,9 @@ spec:
This pod runs in the `Guaranteed` QoS class because `requests` are equal to `limits`.
But the container's resource limit for the CPU resource is a fraction. It runs in
the shared pool.
---->
-该 pod 属于 `Guaranteed` QoS 类型，因为其 `requests` 值与 `limits`相等。但是容器对 CPU 资源的限制值是一个小数。所以该容器运行在共享 CPU 池中。
+-->
+该 Pod 属于 `Guaranteed` QoS 类型，因为其 `requests` 值与 `limits`相等。
+但是容器对 CPU 资源的限制值是一个小数。所以该容器运行在共享 CPU 池中。
```yaml
spec:
@@ -309,7 +304,9 @@ This pod runs in the `Guaranteed` QoS class because only `limits` are specified
and `requests` are set equal to `limits` when not explicitly specified. And the
container's resource limit for the CPU resource is an integer greater than or
equal to one. The `nginx` container is granted 2 exclusive CPUs.
---->
-该 pod 属于 `Guaranteed` QoS 类型，因其指定了 `limits` 值，同时当未显式指定时，`requests` 值被设置为与 `limits` 值相等。同时，容器对 CPU 资源的限制值是一个大于或等于 1 的整数值。所以，该 `nginx` 容器被赋予 2 个独占 CPU。
-
+-->
+该 Pod 属于 `Guaranteed` QoS 类型，因其指定了 `limits` 值，同时当未显式指定时，
+`requests` 值被设置为与 `limits` 值相等。
+同时，容器对 CPU 资源的限制值是一个大于或等于 1 的整数值。
+所以，该 `nginx` 容器被赋予 2 个独占 CPU。
diff --git a/content/zh/docs/tasks/administer-cluster/declare-network-policy.md b/content/zh/docs/tasks/administer-cluster/declare-network-policy.md
index f54c581d5d..efe1942339 100644
--- a/content/zh/docs/tasks/administer-cluster/declare-network-policy.md
+++ b/content/zh/docs/tasks/administer-cluster/declare-network-policy.md
@@ -1,5 +1,6 @@
---
title: 声明网络策略
+min-kubernetes-server-version: v1.8
content_type: task
---
<!--
@@ -16,7 +17,9 @@ content_type: task
<!--
This document helps you get started using the Kubernetes [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) to declare network policies that govern how pods communicate with each other.
-->
-本文可以帮助您开始使用 Kubernetes 的 [NetworkPolicy API](/zh/docs/concepts/services-networking/network-policies/) 声明网络策略去管理 Pod 之间的通信
+本文可以帮助你开始使用 Kubernetes 的
+[NetworkPolicy API](/zh/docs/concepts/services-networking/network-policies/)
+声明网络策略去管理 Pod 之间的通信
## {{% heading "prerequisites" %}}
@@ -31,13 +34,13 @@ Make sure you've configured a network provider with network policy support. Ther
* [Romana](/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy/)
* [Weave Net](/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy/)
-->
-您首先需要有一个支持网络策略的 Kubernetes 集群。已经有许多支持 NetworkPolicy 的网络提供商，包括：
+你首先需要有一个支持网络策略的 Kubernetes 集群。已经有许多支持 NetworkPolicy 的网络提供商，包括：
-* [Calico](/zh/docs/tasks/configure-pod-container/calico-network-policy/)
+* [Calico](/zh/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy/)
* [Cilium](/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy/)
* [Kube-router](/zh/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy/)
-* [Romana](/zh/docs/tasks/configure-pod-container/romana-network-policy/)
-* [Weave 网络](/zh/docs/tasks/configure-pod-container/weave-network-policy/)
+* [Romana](/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy/)
+* [Weave 网络](/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy/)
<!--
The above list is sorted alphabetically by product name, not by recommendation or preference. This example is valid for a Kubernetes cluster using any of these providers.
@@ -56,13 +59,14 @@ To see how Kubernetes network policy works, start off by creating an `nginx` Dep
-->
## 创建一个`nginx` Deployment 并且通过服务将其暴露
-为了查看 Kubernetes 网络策略是怎样工作的，可以从创建一个`nginx` deployment 并且通过服务将其暴露开始
+为了查看 Kubernetes 网络策略是怎样工作的，可以从创建一个`nginx` Deployment 并且通过服务将其暴露开始
-```console
+```shell
kubectl create deployment nginx --image=nginx
```
+
```none
-deployment "nginx" created
+deployment.apps/nginx created
```
<!--
@@ -73,8 +77,9 @@ Expose the Deployment through a Service called `nginx`.
```console
kubectl expose deployment nginx --port=80
```
+
```none
-service "nginx" exposed
+service/nginx exposed
```
<!--
@@ -103,7 +108,7 @@ You should be able to access the new `nginx` service from other Pods. To access
-->
## 通过从 Pod 访问服务对其进行测试
-您应该可以从其它的 Pod 访问这个新的 `nginx` 服务。
+你应该可以从其它的 Pod 访问这个新的 `nginx` 服务。
要从 default 命名空间中的其它s Pod 来访问该服务。可以启动一个 busybox 容器：
```console
@@ -118,6 +123,7 @@ In your shell, run the following command:
```shell
wget --spider --timeout=1 nginx
```
+
```none
Connecting to nginx (10.100.0.16:80)
remote file exists
diff --git a/content/zh/docs/tasks/administer-cluster/developing-cloud-controller-manager.md b/content/zh/docs/tasks/administer-cluster/developing-cloud-controller-manager.md
index 82710c17d8..445dd4ac48 100644
--- a/content/zh/docs/tasks/administer-cluster/developing-cloud-controller-manager.md
+++ b/content/zh/docs/tasks/administer-cluster/developing-cloud-controller-manager.md
@@ -1,52 +1,46 @@
---
-reviewers:
-- luxas
-- thockin
-- wlan0
title: 开发云控制器管理器
-content_type: concept
+content_type: task
---
<!--
----
reviewers:
- luxas
- thockin
- wlan0
title: Developing Cloud Controller Manager
content_type: concept
----
-->
-
-
<!-- overview -->
{{< feature-state for_k8s_version="v1.11" state="beta" >}}
-<!--
-In upcoming releases, Cloud Controller Manager will
-be the preferred way to integrate Kubernetes with any cloud. This will ensure cloud providers
-can develop their features independently from the core Kubernetes release cycles.**
--->
-在即将发布的版本中，云控制器管理器将是把 Kubernetes 与任何云集成的首选方式。 这将确保驱动可以独立于核心 Kubernetes 发布周期开发其功能。
-
-{{< feature-state for_k8s_version="1.8" state="alpha" >}}
-
-<!--
-Before going into how to build your own cloud controller manager, some background on how it works under the hood is helpful. The cloud controller manager is code from `kube-controller-manager` utilizing Go interfaces to allow implementations from any cloud to be plugged in. Most of the scaffolding and generic controller implementations will be in core, but it will always exec out to the cloud interfaces it is provided, so long as the [cloud provider interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go#L42-L62) is satisfied.
--->
-在讨论如何构建自己的云控制器管理器之前，了解有关它如何工作的一些背景知识是有帮助的。云控制器管理器是来自 `kube-controller-manager` 的代码，利用 Go 接口允许插入任何云的实现。大多数框架和通用控制器的实现在 core，但只要满足 [云提供者接口](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go#L42-L62)，它就会始终执行它所提供的云接口。
-
-<!--
-To dive a little deeper into implementation details, all cloud controller managers will import packages from Kubernetes core, the only difference being each project will register their own cloud providers by calling [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go#L56-L66) where a global variable of available cloud providers is updated.
--->
-为了深入了解实施细节，所有云控制器管理器都将从 Kubernetes 核心导入依赖包，唯一的区别是每个项目都会通过调用 [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go#L56-L66) 来注册自己的驱动，更新可用驱动的全局变量。
-
-
+{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="组件 cloud-controller-manager 是">}}
<!-- body -->
+<!--
+## Background
+
+Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the `cloud-controller-manager` binary allows cloud vendors to evolve independently from the core Kubernetes code.
+-->
+## 背景
+
+由于云驱动的开发和发布与 Kubernetes 项目本身步调不同，将特定于云环境
+的代码抽象到 `cloud-controller-manager` 二进制组件有助于云厂商独立于
+Kubernetes 核心代码推进其驱动开发。
+
+<!--
+The Kubernetes project provides skeleton cloud-controller-manager code with Go interfaces to allow you (or your cloud provider) to plug in your own implementations. This means that a cloud provider can implement a cloud-controller-manager by importing packages from Kubernetes core; each cloudprovider will register their own code by calling `cloudprovider.RegisterCloudProvider` to update a global variable of available cloud providers.
+-->
+Kubernetes 项目提供 cloud-controller-manager 的框架代码，其中包含 Go
+语言的接口，便于你（或者你的云驱动提供者）接驳你自己的实现。
+这意味着每个云驱动可以通过从 Kubernetes 核心代码导入软件包来实现一个
+cloud-controller-manager；每个云驱动会通过调用
+`cloudprovider.RegisterCloudProvider` 接口来注册其自身实现代码，从而更新
+记录可用云驱动的全局变量。
+
<!--
## Developing
-->
@@ -57,28 +51,35 @@ To dive a little deeper into implementation details, all cloud controller manage
<!--
To build an out-of-tree cloud-controller-manager for your cloud, follow these steps:
-->
-要为您的云构建一个 out-of-tree 云控制器管理器，请按照下列步骤操作：
+要为你的云环境构建一个 out-of-tree 云控制器管理器：
<!--
1. Create a go package with an implementation that satisfies [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go).
2. Use [main.go in cloud-controller-manager](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/controller-manager.go) from Kubernetes core as a template for your main.go. As mentioned above, the only difference should be the cloud package that will be imported.
3. Import your cloud package in `main.go`, ensure your package has an `init` block to run [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/plugins.go#L42-L52).
-->
-1. 使用满足 [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go) 的实现创建一个 go 包。
-2. 使用来自 Kubernetes 核心包的 [cloud-controller-manager 中的 main.go](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/controller-manager.go) 作为 main.go 的模板。如上所述，唯一的区别应该是将导入的云包。
+1. 使用满足 [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go)
+ 的实现创建一个 Go 语言包。
+2. 使用来自 Kubernetes 核心代码库的
+ [cloud-controller-manager 中的 main.go](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/controller-manager.go)
+ 作为 main.go 的模板。如上所述，唯一的区别应该是将导入的云包。
3. 在 `main.go` 中导入你的云包，确保你的包有一个 `init` 块来运行 cloudprovider.RegisterCloudProvider。
<!--
-Using existing out-of-tree cloud providers as an example may be helpful. You can find the list [here](/docs/tasks/administer-cluster/running-cloud-controller.md#examples).
+Many cloud providers publish their controller manager code as open source. If you are creating
+a new cloud-controller-manager from scratch, you could take an existing out-of-tree cloud
+controller manager as your starting point.
-->
-用现有的 out-of-tree 云驱动作为例子可能会有所帮助。你可以在这里找到 [清单](/docs/tasks/administer-cluster/running-cloud-controller.md#examples)。
-
+很多云驱动都将其控制器管理器代码以开源代码的形式公开。
+如果你在开发一个新的 cloud-controller-manager，你可以选择某个 out-of-tree
+云控制器管理器作为出发点。
### In Tree
<!--
-For in-tree cloud providers, you can run the in-tree cloud controller manager as a [Daemonset](/examples/admin/cloud/ccm-example.yaml) in your cluster. See the [running cloud controller manager docs](/docs/tasks/administer-cluster/running-cloud-controller.md) for more details.
+For in-tree cloud providers, you can run the in-tree cloud controller manager as a {{< glossary_tooltip term_id="daemonset" >}} in your cluster. See [Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/) for more details.
-->
-对于 in-tree 驱动，您可以将 in-tree 云控制器管理器作为群集中的 [Daemonset](/examples/admin/cloud/ccm-example.yaml) 运行。有关详细信息，请参阅 [运行的云控制器管理器文档](/docs/tasks/administer-cluster/running-cloud-controller.md)。
-
+对于 in-tree 驱动，你可以将 in-tree 云控制器管理器作为群集中的
+{{< glossary_tooltip term_id="daemonset" text="Daemonset" >}} 来运行。
+有关详细信息，请参阅[云控制器管理器管理](/zh/docs/tasks/administer-cluster/running-cloud-controller/)。
diff --git a/content/zh/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/zh/docs/tasks/administer-cluster/dns-custom-nameservers.md
index 5667dc1a41..168d01d664 100644
--- a/content/zh/docs/tasks/administer-cluster/dns-custom-nameservers.md
+++ b/content/zh/docs/tasks/administer-cluster/dns-custom-nameservers.md
@@ -1,85 +1,92 @@
---
-reviewers:
-- bowei
-- zihongz
title: 自定义 DNS 服务
content_type: task
+min-kubernetes-server-version: v1.12
---
<!--
----
reviewers:
- bowei
- zihongz
title: Customizing DNS Service
content_type: task
----
+min-kubernetes-server-version: v1.12
-->
<!-- overview -->
<!--
-This page explains how to configure your DNS Pod and customize the
-DNS resolution process. In Kubernetes version 1.11 and later, CoreDNS is at GA
-and is installed by default with kubeadm. See [CoreDNS ConfigMap options](#coredns-configmap-options)
-and [Using CoreDNS for Service Discovery](/docs/tasks/administer-cluster/coredns/).
+This page explains how to configure your DNS
+{{< glossary_tooltip text="Pod(s)" term_id="pod" >}} and customize the
+DNS resolution process in your cluster.
-->
-本页说明如何配置 DNS Pod 和自定义 DNS 解析过程。 在 Kubernetes 1.11 和更高版本中，CoreDNS 位于 GA
-并且默认情况下与 kubeadm 一起安装。 请参见[CoreDNS 的 ConfigMap 选项](#coredns-configmap-options)
-and [使用 CoreDNS 进行服务发现](/docs/tasks/administer-cluster/coredns/)。
-
+本页说明如何配置 DNS {{< glossary_tooltip text="Pod(s)" term_id="pod" >}}，以及定制集群中 DNS 解析过程。
## {{% heading "prerequisites" %}}
-<!--
-* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-* Kubernetes version 1.6 or later. To work with CoreDNS, version 1.9 or later.
-* The appropriate add-on: kube-dns or CoreDNS. To install with kubeadm,
-see [the kubeadm reference documentation](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-phase-addon).
--->
-* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-* Kubernetes 版本 1.6 或更新。如果与 CoreDNS 匹配，版本 1.9 或更新。
-* 合适的 add-on 插件: kube-dns 或 CoreDNS. 使用 kubeadm 安装，请参见 [kubeadm 帮助文档](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-phase-addon).
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+<!--
+Your cluster must be running the CoreDNS add-on.
+[Migrating to CoreDNS](/docs/tasks/administer-cluster/coredns/#migrating-to-coredns)
+explains how to use `kubeadm` to migrate from `kube-dns`.
+-->
+你的集群必须运行 CoreDNS 插件。
+文档[迁移到 CoreDNS](/zh/docs/tasks/administer-cluster/coredns/#migrating-to-coredns)
+解释了如何使用 `kubeadm` 从 `kube-dns` 迁移到 CoreDNS。
+
+{{% version-check %}}
<!-- steps -->
<!--
## Introduction
+
+DNS is a built-in Kubernetes service launched automatically
+using the addon manager
+[cluster add-on](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md).
-->
## 介绍
-<!--
-DNS is a built-in Kubernetes service launched automatically
-using the addon manager
-[cluster add-on](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md).
--->
-DNS 是使用插件管理器[集群 add-on](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md)自动启动的内置的 Kubernetes 服务。
+DNS 是使用[集群插件](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md)
+管理器自动启动的内置的 Kubernetes 服务。
<!--
-As of Kubernetes v1.12, CoreDNS is the recommended DNS Server, replacing kube-dns. However, kube-dns may still be installed by
-default with certain Kubernetes installer tools. Refer to the documentation provided by your installer to know which DNS server is installed by default.
+As of Kubernetes v1.12, CoreDNS is the recommended DNS Server, replacing kube-dns. If your cluster
+originally used kube-dns, you may still have `kube-dns` deployed rather than CoreDNS.
-->
-从 Kubernetes v1.12 开始，CoreDNS 是推荐的 DNS 服务器，取代了kube-dns。 但是，默认情况下，某些 Kubernetes 安装程序工具仍可能安装 kube-dns。 请参阅安装程序提供的文档，以了解默认情况下安装了哪个 DNS 服务器。
+从 Kubernetes v1.12 开始，CoreDNS 是推荐的 DNS 服务器，取代了 kube-dns。 如果
+你的集群原来使用 kube-dns，你可能部署的仍然是 `kube-dns` 而不是 CoreDNS。
-<!--
-The CoreDNS Deployment is exposed as a Kubernetes Service with a static IP.
-Both the CoreDNS and kube-dns Service are named `kube-dns` in the `metadata.name` field. This is done so that there is greater interoperability with workloads that relied on the legacy `kube-dns` Service name to resolve addresses internal to the cluster. It abstracts away the implementation detail of which DNS provider is running behind that common endpoint.
-The kubelet passes DNS to each container with the `--cluster-dns=<dns-service-ip>` flag.
+<!--
+Both the CoreDNS and kube-dns Service are named `kube-dns` in the `metadata.name` field.
+This is so that there is greater interoperability with workloads that relied on the legacy `kube-dns` Service name to resolve addresses internal to the cluster. Using a Service named `kube-dns` abstracts away the implementation detail of which DNS provider is running behind that common name.
-->
-CoreDNS 的部署，作为一个 Kubernetes 服务，通过静态 IP 的方式暴露。
-CoreDNS 和 kube-dns 服务在 `metadata.name` 字段中均被命名为 `kube-dns`。 这样做是为了与依靠传统 `kube-dns` 服务名称来解析集群内部地址的工作负载具有更大的互操作性。它抽象出哪个 DNS 提供程序在该公共端点后面运行的实现细节。
-kubelet 使用 `--cluster-dns = <dns-service-ip>` 标志将 DNS 传递到每个容器。
+{{< note >}}
+CoreDNS 和 kube-dns 的 Service 都在其 `metadata.name` 字段使用名字 `kube-dns`。
+这是为了能够与依靠传统 `kube-dns` 服务名称来解析集群内部地址的工作负载具有更好的互操作性。
+使用 `kube-dns` 作为服务名称可以抽离共有名称之后运行的是哪个 DNS 提供程序这一实现细节。
+{{< /note >}}
+
+<!--
+If you are running CoreDNS as a Deployment, it will typically be exposed as a Kubernetes Service with a static IP address.
+The kubelet passes DNS resolver information to each container with the `-cluster-dns=<dns-service-ip>` flag.
+-->
+如果你在使用 Deployment 运行 CoreDNS，则该 Deployment 通常会向外暴露为一个具有
+静态 IP 地址 Kubernetes 服务。
+kubelet 使用 `--cluster-dns=<DNS 服务 IP>` 标志将 DNS 解析器的信息传递给每个容器。
<!--
DNS names also need domains. You configure the local domain in the kubelet
-with the flag `--cluster-domain=<default-local-domain>`.
+with the flag `-cluster-domain=<default-local-domain>`.
-->
-DNS 名称也需要域。 您可在 kubelet 中使用 `--cluster-domain = <default-local-domain>` 标志配置本地域。
+DNS 名称也需要域名。 你可在 kubelet 中使用 `--cluster-domain=<默认本地域名>`
+标志配置本地域名。
<!--
-The DNS server supports forward lookups (A records), port lookups (SRV records), reverse IP address lookups (PTR records),
-and more. For more information see [DNS for Services and Pods] (/docs/concepts/services-networking/dns-pod-service/).
+The DNS server supports forward lookups (A and AAAA records), port lookups (SRV records), reverse IP address lookups (PTR records),
+and more. For more information, see [DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/).
-->
-DNS 服务器支持正向查找（A 记录），端口发现（SRV 记录），反向 IP 地址发现（PTR 记录）等。 更多信息，请参见[Pod 和 服务的 DNS] (/docs/concepts/services-networking/dns-pod-service/)。
+DNS 服务器支持正向查找（A 和 AAAA 记录）、端口发现（SRV 记录）、反向 IP 地址发现（PTR 记录）等。
+更多信息，请参见[Pod 和 服务的 DNS](/zh/docs/concepts/services-networking/dns-pod-service/)。
<!--
If a Pod's `dnsPolicy` is set to "`default`", it inherits the name resolution
@@ -87,19 +94,19 @@ configuration from the node that the Pod runs on. The Pod's DNS resolution
should behave the same as the node.
But see [Known issues](/docs/tasks/administer-cluster/dns-debugging-resolution/#known-issues).
-->
-如果 Pod 的 dnsPolicy 设置为 "`default`"，则它将从 Pod 运行所在节点上的配置中继承名称解析配置。 Pod 的 DNS 解析应该与节点相同。
-但请参阅[已知问题](/docs/tasks/administer-cluster/dns-debugging-resolution/#known-issues)。
+如果 Pod 的 `dnsPolicy` 设置为 "`default`"，则它将从 Pod 运行所在节点继承名称解析配置。
+Pod 的 DNS 解析行为应该与节点相同。
+但请参阅[已知问题](/zh/docs/tasks/administer-cluster/dns-debugging-resolution/#known-issues)。
<!--
If you don't want this, or if you want a different DNS config for pods, you can
-use the kubelet's `--resolv-conf` flag. Set this flag to "" to prevent Pods from
+use the kubelet's `-resolv-conf` flag. Set this flag to "" to prevent Pods from
inheriting DNS. Set it to a valid file path to specify a file other than
`/etc/resolv.conf` for DNS inheritance.
-->
-如果您不想这样做，或者想要为 Pod 使用其他 DNS 配置，则可以
-使用 kubelet 的 `--resolv-conf` 标志。 将此标志设置为 "" 以避免 Pod
-继承 DNS。 将其设置为有效的文件路径以指定除以下以外的文件
-`/etc/resolv.conf`，用于 DNS 继承。
+如果你不想这样做，或者想要为 Pod 使用其他 DNS 配置，则可以
+使用 kubelet 的 `--resolv-conf` 标志。 将此标志设置为 "" 可以避免 Pod 继承 DNS。
+将其设置为有别于 `/etc/resolv.conf` 的有效文件路径可以设定 DNS 继承不同的配置。
## CoreDNS
@@ -107,27 +114,26 @@ inheriting DNS. Set it to a valid file path to specify a file other than
CoreDNS is a general-purpose authoritative DNS server that can serve as cluster DNS, complying with the [dns specifications]
(https://github.com/kubernetes/dns/blob/master/docs/specification.md).
-->
-CoreDNS是通用的权威DNS服务器，可以用作集群DNS，符合[dns 规范]
-(https://github.com/kubernetes/dns/blob/master/docs/specification.md)。
+CoreDNS 是通用的权威 DNS 服务器，可以用作集群 DNS，符合
+[DNS 规范](https://github.com/kubernetes/dns/blob/master/docs/specification.md)。
<!--
### CoreDNS ConfigMap options
--->
-### CoreDNS ConfigMap 选项
-<!--
CoreDNS is a DNS server that is modular and pluggable, and each plugin adds new functionality to CoreDNS.
This can be configured by maintaining a [Corefile](https://coredns.io/2017/07/23/corefile-explained/), which is the CoreDNS
configuration file. A cluster administrator can modify the ConfigMap for the CoreDNS Corefile to change how service discovery works.
-->
+### CoreDNS ConfigMap 选项 {#coredns-configmap-options}
+
CoreDNS 是模块化且可插拔的 DNS 服务器，每个插件都为 CoreDNS 添加了新功能。
-可以通过维护[Corefile](https://coredns.io/2017/07/23/corefile-explained/)，即CoreDNS
-配置文件。 集群管理员可以修改 CoreDNS Corefile 的 ConfigMap，以更改服务发现的工作方式。
+可以通过维护 [Corefile](https://coredns.io/2017/07/23/corefile-explained/)，即 CoreDNS 配置文件，
+来定制其行为。 集群管理员可以修改 CoreDNS Corefile 的 ConfigMap，以更改服务发现的工作方式。
<!--
In Kubernetes, CoreDNS is installed with the following default Corefile configuration.
-->
-在 Kubernetes 中，已经使用以下默认 Corefile 配置安装了 CoreDNS。
+在 Kubernetes 中，CoreDNS 安装时使用如下默认 Corefile 配置。
```yaml
apiVersion: v1
@@ -139,11 +145,15 @@ data:
Corefile: |
.:53 {
errors
- health
+ health {
+ lameduck 5s
+ }
+ ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
upstream
fallthrough in-addr.arpa ip6.arpa
+ ttl 30
}
prometheus :9153
proxy ./etc/resolv.conf
@@ -153,78 +163,92 @@ data:
loadbalance
}
```
+
<!--
The Corefile configuration includes the following [plugins](https://coredns.io/plugins/) of CoreDNS:
-->
-Corefile 配置包括以下 CoreDNS 的 [插件](https://coredns.io/plugins/)：
+Corefile 配置包括以下 CoreDNS [插件](https://coredns.io/plugins/)：
<!--
* [errors](https://coredns.io/plugins/errors/): Errors are logged to stdout.
* [health](https://coredns.io/plugins/health/): Health of CoreDNS is reported to http://localhost:8080/health.
* [kubernetes](https://coredns.io/plugins/kubernetes/): CoreDNS will reply to DNS queries based on IP of the services and pods of Kubernetes. You can find more details [here](https://coredns.io/plugins/kubernetes/).
-->
-* [错误](https://coredns.io/plugins/errors/)：错误记录到 stdout。
-* [健康](https://coredns.io/plugins/health/)：CoreDNS 的健康报告给 http://localhost:8080/health。
-* [kubernetes](https://coredns.io/plugins/kubernetes/)：CoreDNS 将基于 Kubernetes 的服务和 Pod 的 IP 答复 DNS 查询。 您可以在 [此处](https://coredns.io/plugins/kubernetes/).
+* [errors](https://coredns.io/plugins/errors/)：错误记录到标准输出。
+* [health](https://coredns.io/plugins/health/)：在 http://localhost:8080/health 处提供 CoreDNS 的健康报告。
+* [ready](https://coredns.io/plugins/ready/)：在端口 8181 上提供的一个 HTTP 末端，当所有能够
+ 表达自身就绪的插件都已就绪时，在此末端返回 200 OK。
+* [kubernetes](https://coredns.io/plugins/kubernetes/)：CoreDNS 将基于 Kubernetes 的服务和 Pod 的
+ IP 答复 DNS 查询。你可以在 CoreDNS 网站阅读[更多细节](https://coredns.io/plugins/kubernetes/)。
+ 你可以使用 `ttl` 来定制响应的 TTL。默认值是 5 秒钟。TTL 的最小值可以是 0 秒钟，
+ 最大值为 3600 秒。将 TTL 设置为 0 可以禁止对 DNS 记录进行缓存。
-<!--
-> The `pods insecure` option is provided for backward compatibility with kube-dns. You can use the `pods verified` option, which returns an A record only if there exists a pod in same namespace with matching IP. The `pods disabled` option can be used if you don't use pod records.
--->
->提供 `pods insecure` 选项是为了与 kube-dns 向前兼容。 您可以使用 `pods verified` 选项，该选项仅在相同名称空间中存在具有匹配 IP 的 pod 时才返回 A 记录。 如果您不使用 Pod 记录，则可以使用 `pods disabled` 选项。
-<!--
-`Upstream` is used for resolving services that point to external hosts (External Services).
--->
-'Upstream' 用来解析指向外部主机的服务（外部服务）。
+ <!--
+ The `pods insecure` option is provided for backward compatibility with kube-dns. You can use the
+ `pods verified` option, which returns an A record only if there exists a pod in same namespace
+ with matching IP. The `pods disabled` option can be used if you don't use pod records.
+ -->
+ `pods insecure` 选项是为了与 kube-dns 向后兼容。你可以使用 `pods verified` 选项，该选项使得
+ 仅在相同名称空间中存在具有匹配 IP 的 Pod 时才返回 A 记录。如果你不使用 Pod 记录，则可以使用
+ `pods disabled` 选项。
<!--
* [prometheus](https://coredns.io/plugins/prometheus/): Metrics of CoreDNS are available at http://localhost:9153/metrics in [Prometheus](https://prometheus.io/) format.
-* [proxy](https://coredns.io/plugins/proxy/): Any queries that are not within the cluster domain of Kubernetes will be forwarded to predefined resolvers (/etc/resolv.conf).
+* [forward](https://coredns.io/plugins/forward/): Any queries that are not within the cluster domain of Kubernetes will be forwarded to predefined resolvers (/etc/resolv.conf).
* [cache](https://coredns.io/plugins/cache/): This enables a frontend cache.
* [loop](https://coredns.io/plugins/loop/): Detects simple forwarding loops and halts the CoreDNS process if a loop is found.
* [reload](https://coredns.io/plugins/reload): Allows automatic reload of a changed Corefile. After you edit the ConfigMap configuration, allow two minutes for your changes to take effect.
* [loadbalance](https://coredns.io/plugins/loadbalance): This is a round-robin DNS loadbalancer that randomizes the order of A, AAAA, and MX records in the answer.
-->
-* [prometheus](https://coredns.io/plugins/prometheus/)：CoreDNS的度量标准以[Prometheus](https://prometheus.io/)格式在 http://localhost:9153/metrics 上提供。
-* [proxy](https://coredns.io/plugins/proxy/): 不在 Kubernetes 集群域内的任何查询都将转发到预定义的解析器 (/etc/resolv.conf).
-* [cache](https://coredns.io/plugins/cache/)：这将启用前端缓存。
-* [loop](https://coredns.io/plugins/loop/)：检测到简单的转发循环，如果发现死循环，则中止 CoreDNS 进程。
-* [reload](https://coredns.io/plugins/reload)：允许自动重新加载已更改的 Corefile。 编辑 ConfigMap 配置后，请等待两分钟，以使更改生效。
-* [loadbalance](https://coredns.io/plugins/loadbalance)：这是一个轮询 DNS 负载均衡器，它在应答中随机分配 A，AAAA 和 MX 记录的顺序。
+* [prometheus](https://coredns.io/plugins/prometheus/)：CoreDNS 的度量指标值以
+ [Prometheus](https://prometheus.io/) 格式在 http://localhost:9153/metrics 上提供。
+* [forward](https://coredns.io/plugins/forward/): 不在 Kubernetes 集群域内的任何查询都将转发到
+ 预定义的解析器 (/etc/resolv.conf).
+* [cache](https://coredns.io/plugins/cache/)：启用前端缓存。
+* [loop](https://coredns.io/plugins/loop/)：检测到简单的转发环，如果发现死循环，则中止 CoreDNS 进程。
+* [reload](https://coredns.io/plugins/reload)：允许自动重新加载已更改的 Corefile。
+ 编辑 ConfigMap 配置后，请等待两分钟，以使更改生效。
+* [loadbalance](https://coredns.io/plugins/loadbalance)：这是一个轮转式 DNS 负载均衡器，
+ 它在应答中随机分配 A、AAAA 和 MX 记录的顺序。
<!--
You can modify the default CoreDNS behavior by modifying the ConfigMap.
-->
-您可以通过修改 ConfigMap 来修改默认的 CoreDNS 行为。
+你可以通过修改 ConfigMap 来更改默认的 CoreDNS 行为。
<!--
### Configuration of Stub-domain and upstream nameserver using CoreDNS
+
+CoreDNS has the ability to configure stubdomains and upstream nameservers using the [forward plugin](https://coredns.io/plugins/forward/).
-->
### 使用 CoreDN 配置存根域和上游域名服务器
-<!--
-CoreDNS has the ability to configure stubdomains and upstream nameservers using the [proxy plugin](https://coredns.io/plugins/proxy/). .
--->
-CoreDNS 能够使用 [proxy plugin](https://coredns.io/plugins/proxy/). 配置存根域和上游域名服务器。
+CoreDNS 能够使用 [forward 插件](https://coredns.io/plugins/forward/)配置存根域和上游域名服务器。
<!--
#### Example
+
If a cluster operator has a [Consul](https://www.consul.io/) domain server located at 10.150.0.1, and all Consul names have the suffix .consul.local. To configure it in CoreDNS, the cluster administrator creates the following stanza in the CoreDNS ConfigMap.
-->
#### 示例
-如果集群操作员的 [Consul](https://www.consul.io/) 域服务器位于 10.150.0.1，并且所有 Consul 名称都带有后缀.consul.local。 要在 CoreDNS 中对其进行配置，集群管理员可以在 CoreDNS 的 ConfigMap 中创建加入以下字段。
+
+如果集群操作员在 10.150.0.1 处运行了 [Consul](https://www.consul.io/) 域服务器，
+且所有 Consul 名称都带有后缀 `.consul.local`。要在 CoreDNS 中对其进行配置，
+集群管理员可以在 CoreDNS 的 ConfigMap 中创建加入以下字段。
```
consul.local:53 {
errors
cache 30
- proxy . 10.150.0.1
+ forward . 10.150.0.1
}
```
<!--
-To explicitly force all non-cluster DNS lookups to go through a specific nameserver at 172.16.0.1, point the `proxy` and `forward` to the nameserver instead of `/etc/resolv.conf`
+To explicitly force all non-cluster DNS lookups to go through a specific nameserver at 172.16.0.1, point the `forward` to the nameserver instead of `/etc/resolv.conf`
-->
-要显式强制所有非集群 DNS 查找通过特定的域名服务器（位于172.16.0.1），请将 `proxy` 和 `forward` 指向域名服务器，而不是 `/etc/resolv.conf`。
+要显式强制所有非集群 DNS 查找通过特定的域名服务器（位于 172.16.0.1），可将 `forward`
+指向该域名服务器，而不是 `/etc/resolv.conf`。
```
proxy . 172.16.0.1
@@ -233,7 +257,7 @@ proxy . 172.16.0.1
<!--
The final ConfigMap along with the default `Corefile` configuration looks like:
-->
-最终的 ConfigMap 以及默认的 `Corefile` 配置如下所示：
+最终的包含默认的 `Corefile` 配置的 ConfigMap 如下所示：
```yaml
apiVersion: v1
@@ -248,11 +272,10 @@ data:
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
- upstream 172.16.0.1
fallthrough in-addr.arpa ip6.arpa
}
prometheus :9153
- proxy . 172.16.0.1
+ forward . 172.16.0.1
cache 30
loop
reload
@@ -261,245 +284,23 @@ data:
consul.local:53 {
errors
cache 30
- proxy . 10.150.0.1
+ forward . 10.150.0.1
}
```
+
<!--
-In Kubernetes version 1.10 and later, kubeadm supports automatic translation of the CoreDNS ConfigMap from the kube-dns ConfigMap.
-***Note: While kube-dns accepts an FQDN for stubdomain and nameserver (eg: ns.foo.com), CoreDNS does not support this feature.
+The `kubeadm` supports automatic translation of the CoreDNS ConfigMap from the kube-dns ConfigMap.
+-->
+工具 `kubeadm` 支持将 kube-dns ConfigMap 自动转换为 CoreDNS ConfigMap。
+
+<!--
+While kube-dns accepts an FQDN for stubdomain and nameserver (eg: ns.foo.com), CoreDNS does not support this feature.
During translation, all FQDN nameservers will be omitted from the CoreDNS config.***
-->
-在 Kubernetes 1.10 和更高版本中，kubeadm 支持将 kube-dns ConfigMap 自动转换为 CoreDNS ConfigMap。
-***注意：尽管kube-dns接受 stubdomain 和 nameserver 的 FQDN（例如：ns.foo.com），但 CoreDNS 不支持此功能。
-转换期间，CoreDNS 配置中将省略所有 FQDN 域名服务器。***
-
-## Kube-dns
-
-<!--
-Kube-dns is now available as an optional DNS server since CoreDNS is now the default.
-The running DNS Pod holds 3 containers:
-
-- "`kubedns`": watches the Kubernetes master for changes
- in Services and Endpoints, and maintains in-memory lookup structures to serve
- DNS requests.
-- "`dnsmasq`": adds DNS caching to improve performance.
-- "`sidecar`": provides a single health check endpoint
- to perform healthchecks for `dnsmasq` and `kubedns`.
--->
-由于 CoreDNS 现在是默认设置，因此 Kube-dns 现在可以用作可选的 DNS 服务器。
-正在运行的DNS Pod包含3个容器：
-
-- "`kubedns`"：监测 Kubernetes 主节点的服务和 Endpoints 的更改，并维护内存中的查找结构以服务
- DNS 请求。
-- "`dnsmasq`"：添加 DNS 缓存以提高性能。
-- "`sidecar`"：提供单个运行状况检查端点，对 dnsmasq 和 Kubedns 进行健康检查。
-
-<!--
-### Configure stub-domain and upstream DNS servers
-
-Cluster administrators can specify custom stub domains and upstream nameservers
-by providing a ConfigMap for kube-dns (`kube-system:kube-dns`).
-
-For example, the following ConfigMap sets up a DNS configuration with a single stub domain and two
-upstream nameservers:
--->
-### 配置存根域和上游 DNS 服务器
-
-集群管理员可以指定自定义存根域和上游域名服务器通过为 kube-dns (`kube-system:kube-dns`) 提供 ConfigMap。
-
-例如，以下 ConfigMap 使用单个存根域和两个上游域名服务器设置 DNS 配置：
-
-```yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
- name: kube-dns
- namespace: kube-system
-data:
- stubDomains: |
- {"acme.local": ["1.2.3.4"]}
- upstreamNameservers: |
- ["8.8.8.8", "8.8.4.4"]
-```
-
-<!--
-DNS requests with the “.acme.local” suffix
-are forwarded to a DNS listening at 1.2.3.4. Google Public DNS
-serves the upstream queries.
-
-The table below describes how queries with certain domain names map to
-their destination DNS servers:
-
-| Domain name | Server answering the query |
-| ----------- | -------------------------- |
-| kubernetes.default.svc.cluster.local| kube-dns |
-| foo.acme.local| custom DNS (1.2.3.4) |
-| widget.com | upstream DNS (one of 8.8.8.8, 8.8.4.4) |
-
-See [ConfigMap options](#configmap-options) for
-details about the configuration option format.
--->
-带 “.acme.local” 后缀的 DNS 请求 被转发到侦听 1.2.3.4 的 DNS。 通过 Google 公共 DNS 进行向上查询。
-
-下表描述了具有特定域名的查询如何映射到
-其目标DNS服务器：
-
-| 域名 | 服务器回答查询 |
-| ------------------ | -------------------------- |
-| kubernetes.default.svc.cluster.local | kube-dns |
-| foo.acme.local | 自定义 DNS（1.2.3.4）|
-| widget.com | 上游 DNS（8.8.8.8、8.8.4.4中的一个）|
-
-请参见 [ConfigMap options](#configmap-options) 有关配置选项格式的详细信息。
-
-
-
-<!-- discussion -->
-
-<!--
-#### Effects on Pods
-
-Custom upstream nameservers and stub domains do not affect Pods with a
-`dnsPolicy` set to "`Default`" or "`None`".
--->
-#### 对 Pod 的影响
-
-自定义上游域名服务器和存根域不影响 `dnsPolicy` 设置为 "`Default`" 或 "`None`" 的 Pod。
-
-<!--
-If a Pod's `dnsPolicy` is set to "`ClusterFirst`", its name resolution is
-handled differently, depending on whether stub-domain and upstream DNS servers
-are configured.
--->
-如果 Pod 的 `dnsPolicy` 设置为 "`ClusterFirst`"，则根据是否配置了存根域和上游 DNS 服务器来不同地处理其名称解析。
-
-<!--
-**Without custom configurations**: Any query that does not match the configured
-cluster domain suffix, such as "www.kubernetes.io", is forwarded to the upstream
-nameserver inherited from the node.
-
-**With custom configurations**: If stub domains and upstream DNS servers are
-configured,
-DNS queries are routed according to the following flow:
-
-1. The query is first sent to the DNS caching layer in kube-dns.
-
-1. From the caching layer, the suffix of the request is examined and then
- forwarded to the appropriate DNS, based on the following cases:
-
- * *Names with the cluster suffix*, for example ".cluster.local":
- The request is sent to kube-dns.
-
- * *Names with the stub domain suffix*, for example ".acme.local":
- The request is sent to the configured custom DNS resolver, listening for example at 1.2.3.4.
-
- * *Names without a matching suffix*, for example "widget.com":
- The request is forwarded to the upstream DNS,
- for example Google public DNS servers at 8.8.8.8 and 8.8.4.4.
--->
-**不使用自定义配置**：任何与配置不匹配的查询
-集群域后缀（例如 "www.kubernetes.io"）将转发到从节点继承的上游域名服务器。
-
-**使用自定义配置**：如果存根域和上游 DNS 服务器
-配置完成后，DNS 查询将按照以下流程进行路由：：
-
-1.首先将查询发送到 kube-dns 中的 DNS 缓存层。
-
-1.在以下情况下，从缓存层检查请求的后缀，然后将其转发到适当的 DNS：：
-
- * *带集群后缀的名称*，例如 ".cluster.local"：
- 该请求被发送到 kube-dns。
-
- * *带存根域名后缀的名称*，例如 ".acme.local"：
- 该请求将发送到已配置的自定义 DNS 解析器，例如在 1.2.3.4 处进行侦听。
-
- * *名称没有匹配的后缀*，例如 "widget.com"：
- 该请求被转发到上游 DNS，
- 例如位于 8.8.8.8 和 8.8.4.4 的 Google 公共 DNS 服务器。
-
-<!--
-
--->
-
-
-<!--
-### ConfigMap options
--->
-### ConfigMap 选项
-
-<!--
-Options for the kube-dns `kube-system:kube-dns` ConfigMap:
-
-| Field | Format | Description |
-| ----- | ------ | ----------- |
-| `stubDomains` (optional) | A JSON map using a DNS suffix key such as “acme.local”, and a value consisting of a JSON array of DNS IPs. | The target nameserver can itself be a Kubernetes Service. For instance, you can run your own copy of dnsmasq to export custom DNS names into the ClusterDNS namespace. |
-| `upstreamNameservers` (optional) | A JSON array of DNS IPs. | If specified, the values replace the nameservers taken by default from the node’s `/etc/resolv.conf`. Limits: a maximum of three upstream nameservers can be specified. |
--->
-kube-dns `kube-system:kube-dns` 的 ConfigMap 选项：
-
-| 领域 | 格式 | 描述 |
-| ----- | ------ | ----------- |
-| `stubDomains`（可选）| 使用 DNS 后缀键（例如“ acme.local”）和由 DNS IP 的 JSON 数组组成的值的 JSON 映射。 | 目标域名服务器本身可以是 Kubernetes 服务。 例如，您可以运行自己的 dnsmasq 副本，以将自定义 DNS 名称导出到 ClusterDNS 命名空间中。 |
-| `upstreamNameservers`（可选）| DNS IP的 JSON 数组。 | 如果指定，则这些值替换默认情况下从节点的 `/etc/resolv.conf` 中获取的域名服务器。 限制：最多可以指定三个上游域名服务器。 |
-
-<!--
-#### Examples
-
-##### Example: Stub domain
-
-In this example, the user has a Consul DNS service discovery system they want to
-integrate with kube-dns. The consul domain server is located at 10.150.0.1, and
-all consul names have the suffix `.consul.local`. To configure Kubernetes, the
-cluster administrator creates the following ConfigMap:
--->
-#### 例子
-
-##### 示例：存根域
-
-在此示例中，用户具有他们想与 kube-dns 集成的 Consul DNS 服务发现系统。 consul 域服务器位于 10.150.0.1，所有领事名称均带有后缀 `.consul.local`。 要配置 Kubernetes，集群管理员将创建以下 ConfigMap：
-
-```yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
- name: kube-dns
- namespace: kube-system
-data:
- stubDomains: |
- {"consul.local": ["10.150.0.1"]}
-```
-
-<!--
-Note that the cluster administrator does not want to override the node’s
-upstream nameservers, so they did not specify the optional
-`upstreamNameservers` field.
-
-##### Example: Upstream nameserver
-
-In this example the cluster administrator wants to explicitly force all
-non-cluster DNS lookups to go through their own nameserver at 172.16.0.1.
-In this case, they create a ConfigMap with the
-`upstreamNameservers` field specifying the desired nameserver:
--->
-需要注意的是集群管理员不希望覆盖节点的上游域名服务器，所以他们没有指定可选的 `upstreamNameservers` 字段。
-
-##### 示例： 上游域名服务器
-
-在此示例中，集群管理员希望显式强制所有非集群 DNS 查找通过其自己的域名服务器172.16.0.1）。 在这种情况下，他们使用指定所需域名服务器的 `upstreamNameservers` 字段创建一个 ConfigMap：
-
-
-```yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
- name: kube-dns
- namespace: kube-system
-data:
- upstreamNameservers: |
- ["172.16.0.1"]
-```
-
-
+{{< note >}}
+尽管 kube-dns 接受 FQDN（例如：ns.foo.com）作为存根域和名字服务器，CoreDNS 不支持此功能。
+转换期间，CoreDNS 配置中将忽略所有的 FQDN 域名服务器。
+{{< /note >}}
<!--
## CoreDNS configuration equivalent to kube-dns
@@ -515,12 +316,12 @@ This example ConfigMap for kubedns specifies federations, stubdomains and upstre
## CoreDNS 配置等同于 kube-dns
CoreDNS 不仅仅提供 kube-dns 的功能。
-为 kube-dns 创建的 ConfigMap 支持 `StubDomains` 和 `upstreamNameservers` 转换为 CoreDNS 中的 `proxy` 插件。
+为 kube-dns 创建的 ConfigMap 支持 `StubDomains` 和 `upstreamNameservers` 转换为 CoreDNS 中的 `forward` 插件。
同样，kube-dns 中的 `Federations` 插件会转换为 CoreDNS 中的 `federation` 插件。
### 示例
-用于 kubedns 的此示例 ConfigMap 描述了 federations, stubdomains and upstreamnameservers：
+用于 kubedns 的此示例 ConfigMap 描述了 federations、stubdomains and upstreamnameservers：
```yaml
apiVersion: v1
@@ -539,58 +340,59 @@ The equivalent configuration in CoreDNS creates a Corefile:
-->
CoreDNS 中的等效配置将创建一个 Corefile：
-* For federations:
-```yaml
-federation cluster.local {
- foo foo.feddomain.com
- }
-```
+* 针对 federations:
-* For stubDomains:
-```yaml
-abc.com:53 {
- errors
- cache 30
- proxy . 1.2.3.4
- }
- my.cluster.local:53 {
- errors
- cache 30
- proxy . 2.3.4.5
- }
-```
+ ```yaml
+ federation cluster.local {
+ foo foo.feddomain.com
+ }
+ ```
+
+* 针对 stubDomains:
+
+ ```yaml
+ abc.com:53 {
+ errors
+ cache 30
+ proxy . 1.2.3.4
+ }
+ my.cluster.local:53 {
+ errors
+ cache 30
+ proxy . 2.3.4.5
+ }
+ ```
<!--
The complete Corefile with the default plugins:
-->
带有默认插件的完整 Corefile：
-```yaml
+```
.:53 {
- errors
- health
- kubernetes cluster.local in-addr.arpa ip6.arpa {
- upstream 8.8.8.8 8.8.4.4
- pods insecure
- fallthrough in-addr.arpa ip6.arpa
- }
- federation cluster.local {
- foo foo.feddomain.com
- }
- prometheus :9153
- proxy . 8.8.8.8 8.8.4.4
- cache 30
+ errors
+ health
+ kubernetes cluster.local in-addr.arpa ip6.arpa {
+ pods insecure
+ fallthrough in-addr.arpa ip6.arpa
}
- abc.com:53 {
- errors
- cache 30
- proxy . 1.2.3.4
- }
- my.cluster.local:53 {
- errors
- cache 30
- proxy . 2.3.4.5
+ federation cluster.local {
+ foo foo.feddomain.com
}
+ prometheus :9153
+ forward . 8.8.8.8 8.8.4.4
+ cache 30
+}
+abc.com:53 {
+ errors
+ cache 30
+ forward . 1.2.3.4
+}
+my.cluster.local:53 {
+ errors
+ cache 30
+ forward . 2.3.4.5
+}
```
<!--
@@ -599,15 +401,18 @@ The complete Corefile with the default plugins:
To migrate from kube-dns to CoreDNS, [a detailed blog](https://coredns.io/2018/05/21/migration-from-kube-dns-to-coredns/) is available to help users adapt CoreDNS in place of kube-dns.
A cluster administrator can also migrate using [the deploy script](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh).
-## What's next
-- [Debugging DNS Resolution](/docs/tasks/administer-cluster/dns-debugging-resolution/).
-```
-->
## 迁移到 CoreDNS
-要将 kube-dns 迁移到 CoreDNS，可使用 [详细博客](https://coredns.io/2018/05/21/migration-from-kube-dns-to-coredns/) 来帮助用户在迁移自 kube-dns。
-集群管理员还可以使用[部署脚本](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh) 进行迁移。
+要从 kube-dns 迁移到 CoreDNS，[此博客](https://coredns.io/2018/05/21/migration-from-kube-dns-to-coredns/)
+提供了帮助用户将 kube-dns 替换为 CoreDNS。
+集群管理员还可以使用[部署脚本](https://github.com/coredns/deployment/blob/master/kubernetes/deploy.sh)
+进行迁移。
+
+## {{% heading "whatsnext" %}}
+
+<!--
+- Read [Debugging DNS Resolution](/docs/tasks/administer-cluster/dns-debugging-resolution/).
+-->
+- 阅读[调试 DNS 解析](/zh/docs/tasks/administer-cluster/dns-debugging-resolution/)
-＃＃ 下一步是什么
-- [调试 DNS 解析](/docs/tasks/administer-cluster/dns-debugging-resolution/)。
-```
diff --git a/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md b/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md
index 5a34f2331d..423c8e5d8f 100644
--- a/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md
+++ b/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md
@@ -1,34 +1,37 @@
---
title: 调试 DNS 问题
content_type: task
+min-kubernetes-server-version: v1.6
---
<!-- overview -->
<!--
This page provides hints on diagnosing DNS problems.
-->
-
这篇文章提供了一些关于 DNS 问题诊断的方法。
<!-- steps -->
## {{% heading "prerequisites" %}}
-<!-- ZH: The following include shortcode misbehaves even when inside a HTML
-comment. This may be a generic problem to be fixed.-->
+{{< include "task-tutorial-prereqs.md" >}}
+
+<!--
+Your cluster must be configured to use the CoreDNS
+{{< glossary_tooltip text="addon" term_id="addons" >}} or its precursor,
+kube-dns.
+-->
+
+你的集群必须使用了 CoreDNS {{< glossary_tooltip text="插件" term_id="addons" >}}
+或者其前身，`kube-dns`。
+
+{{< version-check >}}
-- {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-- Kubernetes 1.6 或者以上版本。
-- 集群必须使用了 `coredns` (或者 `kube-dns`)插件。
-
<!--
### Create a simple Pod to use as a test environment
-Create a file named busybox.yaml with the following contents:
-{{< codenew file="admin/dns/busybox.yaml" >}}
-
-Then create a pod using this file and verify its status:
+Use that manifest to create a Pod:
```shell
kubectl create -f https://k8s.io/examples/admin/dns/busybox.yaml
@@ -39,47 +42,45 @@ NAME READY STATUS RESTARTS AGE
busybox 1/1 Running 0 <some-time>
```
-->
-
### 创建一个简单的 Pod 作为测试环境
-新建一个名为 busybox.yaml 的文件并填入下列内容：
+{{< codenew file="admin/dns/dnsutils.yaml" >}}
-{{< codenew file="admin/dns/busybox.yaml" >}}
-
-然后使用这个文件创建一个 Pod 并验证其状态：
+使用上面的清单来创建一个 Pod：
```shell
-kubectl create -f https://k8s.io/examples/admin/dns/busybox.yaml
-pod/busybox created
+kubectl apply -f https://k8s.io/examples/admin/dns/dnsutils.yaml
+```
-kubectl get pods busybox
-NAME READY STATUS RESTARTS AGE
-busybox 1/1 Running 0 <some-time>
+```
+pod/dnsutils created
```
<!--
+…and verify its status:
+-->
+验证其状态：
+```shell
+kubectl get pods dnsutils
+```
+
+```
+NAME READY STATUS RESTARTS AGE
+dnsutils 1/1 Running 0 <some-time>
+```
+
+<!--
Once that pod is running, you can exec `nslookup` in that environment.
If you see something like the following, DNS is working correctly.
-
-```shell
-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
-```
-
-If the `nslookup` command fails, check the following:
-
-->
-
-只要 Pod 处于 running 状态，您就可以在环境里执行 `nslookup` 。
-如果您看到类似下列的内容，则表示 DNS 是正常运行的。
+一旦 Pod 处于运行状态，你就可以在该环境里执行 `nslookup`。
+如果你看到类似下列的内容，则表示 DNS 是正常运行的。
```shell
-kubectl exec -ti busybox -- nslookup kubernetes.default
+kubectl exec -i -t dnsutils -- nslookup kubernetes.default
+```
+```
Server: 10.0.0.10
Address 1: 10.0.0.10
@@ -87,42 +88,34 @@ Name: kubernetes.default
Address 1: 10.0.0.1
```
+<!--
+If the `nslookup` command fails, check the following:
+-->
如果 `nslookup` 命令执行失败，请检查下列内容：
<!--
-
### Check the local DNS configuration first
Take a look inside the resolv.conf file.
(See [Inheriting DNS from the node](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) and
[Known issues](#known-issues) below for more information)
-
-```shell
-kubectl exec busybox cat /etc/resolv.conf
-```
-
-Verify that the search path and name server are set up like the following
-(note that search path may vary for different cloud providers):
-
-```
-search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internal
-nameserver 10.0.0.10
-options ndots:5
-```
-->
-
### 先检查本地的 DNS 配置
查看 resolv.conf 文件的内容
-(阅读下面的 [从节点继承 DNS 配置](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) 和
-[已知问题](#known-issues) ，获取更多信息)
+（阅读[从节点继承 DNS 配置](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/) 和
+后文的[已知问题](#known-issues) ，获取更多信息)
```shell
-kubectl exec busybox cat /etc/resolv.conf
+kubectl exec -ti dnsutils -- cat /etc/resolv.conf
```
-验证 search 和 name server 的配置是否类似下面的配置
-(注意 search 根据不同的云提供商可能会有所不同):
+<!--
+Verify that the search path and name server are set up like the following
+(note that search path may vary for different cloud providers):
+-->
+验证 search 和 nameserver 的配置是否与下面的内容类似
+（注意 search 根据不同的云提供商可能会有所不同)：
```
search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internal
@@ -131,34 +124,18 @@ options ndots:5
```
<!--
-
-Errors such as the following indicate a problem with the coredns/kube-dns add-on or
-associated Services:
-
-```
-kubectl exec -ti busybox -- nslookup kubernetes.default
-Server: 10.0.0.10
-Address 1: 10.0.0.10
-
-nslookup: can't resolve 'kubernetes.default'
-```
-
-or
-
-```
-kubectl exec -ti busybox -- nslookup kubernetes.default
-Server: 10.0.0.10
-Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
-
-nslookup: can't resolve 'kubernetes.default'
-```
-
+Errors such as the following indicate a problem with the CoreDNS (or kube-dns)
+add-on or with associated Services:
-->
-
-下列错误表示 coredns/kube-dns 或者相关服务出现了问题：
+下列错误表示 CoreDNS （或 kube-dns）插件或者相关服务出现了问题：
+
+```
+kubectl exec -i -t dnsutils -- nslookup kubernetes.default
+```
+
+输出为：
```
-kubectl exec -ti busybox -- nslookup kubernetes.default
Server: 10.0.0.10
Address 1: 10.0.0.10
@@ -168,7 +145,6 @@ 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
@@ -176,44 +152,19 @@ nslookup: can't resolve 'kubernetes.default'
```
<!--
-
### Check if the DNS pod is running
Use the `kubectl get pods` command to verify that the DNS pod is running.
-
-For CoreDNS:
-```shell
-kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
-NAME READY STATUS RESTARTS AGE
-...
-coredns-7b96bf9f76-5hsxb 1/1 Running 0 1h
-coredns-7b96bf9f76-mvmmt 1/1 Running 0 1h
-...
-```
-
-Or for kube-dns:
-```shell
-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
-...
-```
-
-If you see that no pod is running or that the pod has failed/completed, the DNS
-add-on may not be deployed by default in your current environment and you will
-have to deploy it manually.
-
-->
-
### 检查 DNS Pod 是否运行
使用 `kubectl get pods` 命令来验证 DNS Pod 是否运行。
-对于 CoreDNS 的情况:
-
```shell
kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
+```
+
+```
NAME READY STATUS RESTARTS AGE
...
coredns-7b96bf9f76-5hsxb 1/1 Running 0 1h
@@ -221,52 +172,37 @@ coredns-7b96bf9f76-mvmmt 1/1 Running 0 1h
...
```
-或者是 kube-dns:
-
-```shell
-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 的状态是 failed 或者 completed， 那可能这个 DNS 插件在您当前的环境里并没有成功部署，您将需要手动去部署它。
+<!--
+The value for label `k8s-app` is `kube-dns` for both CoreDNS and kube-dns deployments.
+-->
+{{< note >}}
+对于 CoreDNS 和 kube-dns 部署而言，标签 `k8s-app` 的值都应该是 `kube-dns`。
+{{< /note >}}
<!--
+If you see that no CoreDNS pod is running or that the pod has failed/completed,
+the DNS add-on may not be deployed by default in your current environment and you
+will have to deploy it manually.
+-->
+如果你发现没有 CoreDNS Pod 在运行，或者该 Pod 的状态是 failed 或者 completed，
+那可能这个 DNS 插件在您当前的环境里并没有成功部署，你将需要手动去部署它。
+<!--
### Check for Errors in the DNS pod
Use `kubectl logs` command to see logs for the DNS containers.
-
-For CoreDNS:
-```shell
-for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name); do kubectl logs --namespace=kube-system $p; done
-```
-
-Here is an example of a healthy CoreDNS log:
-
-```
-.:53
-2018/08/15 14:37:17 [INFO] CoreDNS-1.2.2
-2018/08/15 14:37:17 [INFO] linux/amd64, go1.10.3, 2e322f6
-CoreDNS-1.2.2
-linux/amd64, go1.10.3, 2e322f6
-2018/08/15 14:37:17 [INFO] plugin/reload: Running configuration MD5 = 24e6c59e83ce706f07bcc82c31b1ea1c
-```
-
-->
-
-### 检查 DNS pod 里的错误
+### 检查 DNS Pod 里的错误
使用 `kubectl logs` 命令来查看 DNS 容器的日志信息。
-对于 CoreDNS:
-
```shell
-for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name); do kubectl logs --namespace=kube-system $p; done
+kubectl logs --namespace=kube-system -l k8s-app=kube-dns
```
+<!--
+Here is an example of a healthy CoreDNS log:
+-->
下列是一个正常运行的 CoreDNS 日志信息：
```
@@ -279,146 +215,99 @@ linux/amd64, go1.10.3, 2e322f6
```
<!--
-
-For kube-dns, there are 3 sets of logs:
-
-```shell
-kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c kubedns
-
-kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c dnsmasq
-
-kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c sidecar
-```
-
-See if there are any suspicious error messages in the logs. In kube-dns, a '`W`', '`E`' or '`F`' at the beginning
-of a line represents a Warning, Error or Failure. Please search for entries that have these
-as the logging level and use
-[kubernetes issues](https://github.com/kubernetes/kubernetes/issues)
-to report unexpected errors.
-
+See if there are any suspicious or unexpected messages in the logs.
-->
+查看是否日志中有一些可疑的或者意外的消息。
-对于 kube-dns, 总共有三种类型的日志需要查看：
-
-```shell
-kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c kubedns
-
-kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c dnsmasq
-
-kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c sidecar
-```
-
-看日志信息里是否有可疑的错误，对于 kube-dns, 一个 '`W`', '`E`' 或者 '`F`' 开头的行表示对应的 Warning（警告）， Error（错误）或者 Failure（失败）。请搜索日志等级是否有这样的关键字的日志信息并使用 [kubernetes issues](https://github.com/kubernetes/kubernetes/issues) 来提交错误报告。
+<!--
+### Is DNS service up?
+Verify that the DNS service is up by using the `kubectl get service` command.
+-->
### 检查是否启用了 DNS 服务
-使用`kubectl get service` 命令来检查 DNS 服务是否已经启用。
+使用 `kubectl get service` 命令来检查 DNS 服务是否已经启用。
```shell
kubectl get svc --namespace=kube-system
+```
+
+```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
...
kube-dns ClusterIP 10.0.0.10 <none> 53/UDP,53/TCP 1h
...
```
-注意不管是 CoreDNS 还是 kube-dns ， 这个 service 的名字都会是“kube-dns” 。
-如果您已经创建了这个 service 或者说在这个例子里它应该是默认自动创建的，但是它并没有出现，请阅读 [services 纠错](/docs/tasks/debug-application-cluster/debug-service/)来获取更多信息。
+<!--
+The service name is `kube-dns` for both CoreDNS and kube-dns deployments.
+-->
+
+{{< note >}}
+不管是 CoreDNS 还是 kube-dns，这个服务的名字都会是 `kube-dns` 。
+{{< /note >}}
<!--
+If you have created the Service or in the case it should be created by default
+but it does not appear, see
+[debugging Services](/docs/tasks/debug-application-cluster/debug-service/) for
+more information.
+-->
+如果你已经创建了 DNS 服务，或者该服务应该是默认自动创建的但是它并没有出现，
+请阅读[调试服务](/zh/docs/tasks/debug-application-cluster/debug-service/)
+来获取更多信息。
+<!--
### Are DNS endpoints exposed?
You can verify that DNS endpoints are exposed by using the `kubectl get endpoints`
command.
+-->
+### DNS 的末端公开了吗？
+
+你可以使用 `kubectl get endpoints` 命令来验证 DNS 的末端是否公开了。
```shell
kubectl get ep kube-dns --namespace=kube-system
+```
+```
NAME ENDPOINTS AGE
kube-dns 10.180.3.17:53,10.180.3.17:53 1h
```
+<!--
If you do not see the endpoints, see endpoints section in the
[debugging services](/docs/tasks/debug-application-cluster/debug-service/) documentation.
For additional Kubernetes DNS examples, see the
[cluster-dns examples](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)
in the Kubernetes GitHub repository.
-
-->
+如果你没看到对应的末端，请阅读
+[调试服务](/zh/docs/tasks/debug-application-cluster/debug-service/)的末端部分。
-### DNS 的 endpoints 公开了吗？
-
-您可以使用 `kubectl get endpoints`命令来验证 DNS 的 endpoint 是否公开了。
-
-```shell
-kubectl get ep kube-dns --namespace=kube-system
-NAME ENDPOINTS AGE
-kube-dns 10.180.3.17:53,10.180.3.17:53 1h
-```
-
-如果您没看到对应的 endpoints， 请阅读[services 纠错](/docs/tasks/debug-application-cluster/debug-service/)的 endpoints 小节。
-
-若需要更多的 Kubernetes DNS 例子，请在 Kubernetes GitHub 仓库里查看[cluster-dns 例子](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns) 。
+若需要了解更多的 Kubernetes DNS 例子，请在 Kubernetes GitHub 仓库里查看
+[cluster-dns 示例](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)。
<!--
-
### Are DNS queries being received/processed?
You can verify if queries are being received by CoreDNS by adding the `log` plugin to the CoreDNS configuration (aka Corefile).
The CoreDNS Corefile is held in a ConfigMap named `coredns`. To edit it, use the command ...
-
-```
-kubectl -n kube-system edit configmap coredns
-```
-
-->
-
### DNS 查询有被接收或者执行吗？
-您可以通过给 CoreDNS 的配置文件 (也叫 Corefile)添加`log`插件来判断查询是否被正确接收。
- CoreDNS 的 Corefile 被保存在一个叫 `coredns` 的 ConfigMap 里，使用下列命令来编辑它：
+你可以通过给 CoreDNS 的配置文件（也叫 Corefile）添加 `log` 插件来检查查询是否被正确接收。
+CoreDNS 的 Corefile 被保存在一个叫 `coredns` 的 ConfigMap 里，使用下列命令来编辑它：
```
kubectl -n kube-system edit configmap coredns
```
<!--
-
Then add `log` in the Corefile section per the example below.
-
-```
-apiVersion: v1
-kind: ConfigMap
-metadata:
- name: coredns
- namespace: kube-system
-data:
- Corefile: |
- .:53 {
- log
- errors
- health
- kubernetes cluster.local in-addr.arpa ip6.arpa {
- pods insecure
- upstream
- fallthrough in-addr.arpa ip6.arpa
- }
- prometheus :9153
- proxy . /etc/resolv.conf
- cache 30
- loop
- reload
- loadbalance
- }
-
-```
-
-After saving the changes, it may take up to minute or two for Kubernetes to propagate these changes to the CoreDNS pods.
-
-->
-
-然后类似下面的例子给 Corefile 添加 `log`。
+然后按下面的例子给 Corefile 添加 `log`。
```
apiVersion: v1
@@ -438,38 +327,27 @@ data:
fallthrough in-addr.arpa ip6.arpa
}
prometheus :9153
- proxy . /etc/resolv.conf
+ forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}
-
```
-保存这些更改后，您可能会需要等待一到两分钟让 Kubernetes 把这些更改应用到 CoreDNS 的 pods 里。
-
<!--
+After saving the changes, it may take up to minute or two for Kubernetes to propagate these changes to the CoreDNS pods.
+-->
+保存这些更改后，你可能会需要等待一到两分钟让 Kubernetes 把这些更改应用到
+CoreDNS 的 Pod 里。
+<!--
Next, make some queries and view the logs per the sections above in this document. If CoreDNS pods are receiving the queries, you should see them in the logs.
Here is an example of a query in the log.
-
-```
-.:53
-2018/08/15 14:37:15 [INFO] CoreDNS-1.2.0
-2018/08/15 14:37:15 [INFO] linux/amd64, go1.10.3, 2e322f6
-CoreDNS-1.2.0
-linux/amd64, go1.10.3, 2e322f6
-2018/09/07 15:29:04 [INFO] plugin/reload: Running configuration MD5 = 162475cdf272d8aa601e6fe67a6ad42f
-2018/09/07 15:29:04 [INFO] Reloading complete
-172.17.0.18:41675 - [07/Sep/2018:15:29:11 +0000] 59925 "A IN kubernetes.default.svc.cluster.local. udp 54 false 512" NOERROR qr,aa,rd,ra 106 0.000066649s
-
-```
-
-->
-
-接下来，发起一些查询并依照本文上面章节的内容查看日志信息，如果 CoreDNS 的 pods 接收到这些查询，您将可以在日志信息里看到他们。
+接下来，发起一些查询并依照前文所述查看日志信息，如果 CoreDNS 的 Pod 接收到这些查询，
+你将可以在日志信息里看到它们。
下面是日志信息里的查询例子：
@@ -486,65 +364,73 @@ linux/amd64, go1.10.3, 2e322f6
```
<!--
-
## Known issues
Some Linux distributions (e.g. Ubuntu), use a local DNS resolver by default (systemd-resolved).
Systemd-resolved moves and replaces `/etc/resolv.conf` with a stub file that can cause a fatal forwarding
-loop when resolving names in upstream servers. This can be fixed manually by using kubelet's `--resolv-conf` flag
+loop when resolving names in upstream servers. This can be fixed manually by using kubelet's `-resolv-conf` flag
to point to the correct `resolv.conf` (With `systemd-resolved`, this is `/run/systemd/resolve/resolv.conf`).
-kubeadm (>= 1.11) automatically detects `systemd-resolved`, and adjusts the kubelet flags accordingly.
-
+kubeadm automatically detects `systemd-resolved`, and adjusts the kubelet flags accordingly.
-->
+## 已知问题 {#known-issues}
-## 已知问题
-
-有些 Linux 发行版本 (比如 Ubuntu)， 默认使用一个本地的 DNS 解析器 (systemd-resolved)。
-Systemd-resolved 会用一个 stub 文件来覆盖 `/etc/resolv.conf`从而在解析域名的时候导致了重复向 DNS 上游服务器推送请求。 这个问题可以通过手动指定 kubelet 的 `--resolv-conf` 标签为正确的 `resolv.conf` (如果是 `systemd-resolved`，则这个文件路径为 `/run/systemd/resolve/resolv.conf`) 来解决。
-kubeadm (>= 1.11) 会自动检测`systemd-resolved`并对应的更改 kubelet 的标签。
+有些 Linux 发行版本（比如 Ubuntu）默认使用一个本地的 DNS 解析器（systemd-resolved）。
+`systemd-resolved` 会用一个存根文件（Stub File）来覆盖 `/etc/resolv.conf` 内容，
+从而可能在上游服务器中解析域名产生转发环（forwarding loop）。 这个问题可以通过手动指定
+kubelet 的 `--resolv-conf` 标志为正确的 `resolv.conf`（如果是 `systemd-resolved`，
+则这个文件路径为 `/run/systemd/resolve/resolv.conf`）来解决。
+kubeadm 会自动检测 `systemd-resolved` 并对应的更改 kubelet 的命令行标志。
<!--
Kubernetes installs do not configure the nodes' `resolv.conf` files to use the
cluster DNS by default, because that process is inherently distribution-specific.
This should probably be implemented eventually.
+-->
+Kubernetes 的安装并不会默认配置节点的 `resolv.conf` 文件来使用集群的 DNS 服务，因为这个配置对于不同的发行版本是不一样的。这个问题应该迟早会被解决的。
-Linux's libc is impossibly stuck ([see this bug from
-2005](https://bugzilla.redhat.com/show_bug.cgi?id=168253)) with limits of just
-3 DNS `nameserver` records and 6 DNS `search` records. Kubernetes needs to
-consume 1 `nameserver` record and 3 `search` records. This means that if a
-local installation already uses 3 `nameserver`s or uses more than 3 `search`es,
-some of those settings will be lost. As a partial workaround, the node can run
-`dnsmasq` which will provide more `nameserver` entries, but not more `search`
-entries. You can also use kubelet's `--resolv-conf` flag.
+<!--
+Linux's libc (a.k.a. glibc) has a limit for the DNS `nameserver` records to 3
+by default. What's more, for the glibc versions which are older than
+glibc-2.17-222 ([the new versions update see this
+issue](https://access.redhat.com/solutions/58028)), the allowed number of DNS
+`search` records has been limited to 6 ([see this bug from
+2005](https://bugzilla.redhat.com/show_bug.cgi?id=168253)). Kubernetes needs
+to consume 1 `nameserver` record and 3 `search` records. This means that if a
+local installation already uses 3 `nameserver`s or uses more than 3 `search`es
+while your glibc version is in the affected list, some of those settings will
+be lost. To work around the DNS `nameserver` records limit, the node can run
+`dnsmasq`, which will provide more `nameserver` entries. You can also use
+kubelet's `--resolv-conf` flag. To fix the DNS `search` records limit,
+consider upgrading your linux distribution or upgrading to an unaffected
+version of glibc.
+-->
+Linux 的 libc 限制 `nameserver` 只能有三个记录。不仅如此，对于 glibc-2.17-222
+之前的版本（[参见此 Issue 了解新版本的更新](https://access.redhat.com/solutions/58028)），`search` 的记录不能超过 6 个
+（ [详情请查阅这个 2005 年的 bug](https://bugzilla.redhat.com/show_bug.cgi?id=168253)）。
+Kubernetes 需要占用一个 `nameserver` 记录和三个`search`记录。
+这意味着如果一个本地的安装已经使用了三个 `nameserver` 或者使用了超过三个
+`search` 记录，而你的 glibc 版本也在有问题的版本列表中，那么有些配置很可能会丢失。
+为了绕过 DNS `nameserver` 个数限制，节点可以运行 `dnsmasq`，以提供更多的
+`nameserver` 记录。你也可以使用kubelet 的 `--resolv-conf` 标志来解决这个问题。
+要想修复 DNS `search` 记录个数限制问题，可以考虑升级你的 Linux 发行版本，或者
+升级 glibc 到一个不再受此困扰的版本。
+<!--
If you are using Alpine version 3.3 or earlier as your base image, DNS may not
work properly owing to a known issue with Alpine.
Check [here](https://github.com/kubernetes/kubernetes/issues/30215)
for more information.
-->
-Kubernetes 的安装并不会默认配置节点的 `resolv.conf` 文件来使用集群的 DNS 服务，因为这个配置对于不同的发行版本是不一样的。这个问题应该迟早会被解决的。
+如果你使用 Alpine 3.3 或更早版本作为你的基础镜像，DNS 可能会由于 Alpine 中
+一个已知的问题导致无法正常工作。
+请查看[这里](https://github.com/kubernetes/kubernetes/issues/30215)获取更多信息。
-Linux 的 libc 会在仅有三个 DNS 的 `nameserver` 和六个 DNS 的`search` 记录时会不可思议的卡死 ([详情请查阅这个2005年的bug](https://bugzilla.redhat.com/show_bug.cgi?id=168253))。Kubernetes 需要占用一个 `nameserver` 记录和三个`search`记录。这意味着如果一个本地的安装已经使用了三个`nameserver`或者使用了超过三个的 `search`记录，那有些配置很可能会丢失。有一个不完整的解决方案就是在节点上使用`dnsmasq`来提供更多的`nameserver`配置，但是无法提供更多的`search`记录。您也可以使用kubelet 的 `--resolv-conf` 标签来解决这个问题。
-
-如果您是使用 Alpine 3.3 或者更早版本作为您的基础镜像，DNS 可能会由于Alpine 一个已知的问题导致无法正常工作，请查看[这里](https://github.com/kubernetes/kubernetes/issues/30215)获取更多资料。
+## {{% heading "whatsnext" %}}
<!--
-## References
-
-- [DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/)
-- [Docs for the kube-dns DNS cluster addon](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/README.md)
-
-## What's next
- [Autoscaling the DNS Service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/).
+- [DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/)
-->
-
-## 参考
-
-- [Services 和 Pods 的 DNS 指南](/docs/concepts/services-networking/dns-pod-service/)
-- [kube-dns DNS 插件文档](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/README.md)
-
-## 接下来
-
-- [集群里自动伸缩 DNS Service](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/).
-
+- 参阅[自动扩缩集群中的 DNS 服务](/zh/docs/tasks/administer-cluster/dns-horizontal-autoscaling/).
+- 阅读[服务和 Pod 的 DNS](/zh/docs/concepts/services-networking/dns-pod-service/)
diff --git a/content/zh/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md b/content/zh/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
index 698a58bf7e..048c49028c 100644
--- a/content/zh/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
+++ b/content/zh/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md
@@ -1,12 +1,10 @@
---
-title: 集群 DNS 服务自动伸缩
+title: 自动扩缩集群 DNS 服务
content_type: task
---
<!--
----
title: Autoscale the DNS Service in a Cluster
content_type: task
----
-->
<!-- overview -->
@@ -14,12 +12,10 @@ content_type: task
This page shows how to enable and configure autoscaling of the DNS service in a
Kubernetes cluster.
-->
-本页展示了如何在集群中启用和配置 DNS 服务的自动伸缩功能。
-
+本页展示了如何在集群中启用和配置 DNS 服务的自动扩缩功能。
## {{% heading "prerequisites" %}}
-
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
@@ -29,14 +25,12 @@ Kubernetes cluster.
* Kubernetes version 1.4.0 or later is recommended.
-->
-* 本指南假设您的节点使用 AMD64 或 Intel 64 CPU 架构
+* 本指南假设你的节点使用 AMD64 或 Intel 64 CPU 架构
-* 确保已启用 [DNS 功能](/docs/concepts/services-networking/dns-pod-service/)本身。
+* 确保已启用 [DNS 功能](/zh/docs/concepts/services-networking/dns-pod-service/)本身。
* 建议使用 Kubernetes 1.4.0 或更高版本。
-
-
<!-- steps -->
<!--
@@ -60,7 +54,7 @@ If you see "dns-autoscaler" in the output, DNS horizontal autoscaling is
already enabled, and you can skip to
[Tuning autoscaling parameters](#tuning-autoscaling-parameters).
-->
-## 确定是否 DNS 水平 水平自动伸缩特性已经启用
+## 确定是否 DNS 水平 水平自动扩缩特性已经启用 {#determining-whether-dns-horizontal-autoscaling-is-already-enabled}
在 kube-system 命名空间中列出集群中的 {{< glossary_tooltip text="Deployments" term_id="deployment" >}} ：
@@ -70,15 +64,18 @@ kubectl get deployment --namespace=kube-system
输出类似如下这样：
- NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
- ...
- dns-autoscaler 1 1 1 1 ...
- ...
+```
+NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
+...
+dns-autoscaler 1 1 1 1 ...
+...
+```
-如果在输出中看到 “dns-autoscaler”，说明 DNS 水平自动伸缩已经启用，可以跳到 [调优自动伸缩参数](#tuning-autoscaling-parameters)。
+如果在输出中看到 “dns-autoscaler”，说明 DNS 水平自动扩缩已经启用，可以跳到
+[调优自动扩缩参数](#tuning-autoscaling-parameters)。
<!--
-## Getting the name of your DNS Deployment or ReplicationController
+## Getting the name of your DNS Deployment {#find-scaling-target}
List the Deployments in your cluster in the kube-system namespace:
@@ -87,127 +84,88 @@ kubectl get deployment --namespace=kube-system
```
The output is similar to this:
+-->
+## 获取 DNS Deployment 的名称 {#find-scaling-target}
- NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
- ...
- coredns 2 2 2 2 ...
- ...
-
-
-In Kubernetes versions earlier than 1.12, the DNS Deployment was called "kube-dns".
-
-In Kubernetes versions earlier than 1.5 DNS was implemented using a
-ReplicationController instead of a Deployment. So if you don't see kube-dns,
-or a similar name, in the preceding output, list the ReplicationControllers in
-your cluster in the kube-system namespace:
+列出集群内 kube-system 名字空间中的 DNS Deployment：
```shell
-kubectl get rc --namespace=kube-system
+kubectl get deployment -l k8s-app=kube-dns --namespace=kube-system
```
-The output is similar to this:
+输出类似如下这样：
- NAME DESIRED CURRENT READY AGE
- ...
- kube-dns-v20 1 1 1 ...
- ...
+```
+NAME READY UP-TO-DATE AVAILABLE AGE
+...
+coredns 2/2 2 2 ...
+...
+```
+
+<!--
+If you don't see a Deployment for DNS services, you can also look for it by name:
-->
-## 获取 DNS Deployment 或 ReplicationController 的名称
-
-列出集群内 kube-system namespace 中的 Deployment：
+如果看不到 DNS 服务的 Deployment，你也可以通过名字来查找：
```shell
kubectl get deployment --namespace=kube-system
```
-输出类似如下这样：
+<!--
+and look for a deployment named `coredns` or `kube-dns`.
+-->
+并在输出中寻找名称为 `coredns` 或 `kube-dns` 的 Deployment。
- NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
- ...
- coredns 2 2 2 2 ...
- ...
+<!--
+Your scale target is:
+-->
+你的扩缩目标为：
-在早于 1.12 的 Kubernetes 版本中，DNS 部署称为 “kube-dns”。
-
-Kubernetes 1.5 或之前版本，DNS 通过使用 ReplicationController 来实现，而不是 Deployment。 所以看不到 kube-dns 或者类似的名称，在之前的输出中，列出了集群内 kube-system namespace 中的 ReplicationController：
-
-```shell
-kubectl get rc --namespace=kube-system
+```
+Deployment/<your-deployment-name>
```
-输出类似如下这样：
-
- NAME DESIRED CURRENT READY AGE
- ...
- kube-dns-v20 1 1 1 ...
- ...
-
<!--
-## Determining your scale target
-
-If you have a DNS Deployment, your scale target is:
-
- Deployment/<your-deployment-name>
-
where `<your-deployment-name>` is the name of your DNS Deployment. For example, if
your DNS Deployment name is coredns, your scale target is Deployment/coredns.
-
-If you have a DNS ReplicationController, your scale target is:
-
- ReplicationController/<your-rc-name>
-
-where `<your-rc-name>` is the name of your DNS ReplicationController. For example,
-if your DNS ReplicationController name is kube-dns-v20, your scale target is
-ReplicationController/kube-dns-v20.
-->
-## 确定伸缩目标
-
-如果有一个 DNS Deployment，伸缩目标是：
-
- Deployment/<your-deployment-name>
-
-其中 `<your-deployment-name>` 是 DNS 部署的名称。例如，如果您的 DNS 部署名称是 coredns，则您的扩展目标是 Deployment/coredns。
-
-如果有一个 DNS ReplicationController，那么伸缩目标为：
-
- ReplicationController/<your-rc-name>
-
-这里 `<your-rc-name>` 是 DNS ReplicationController 的名称。 例如，DNS ReplicationController 的名称是 kube-dns-v20，则伸缩目标为 ReplicationController/kube-dns-v20。
+其中 `<your-deployment-name>` 是 DNS Deployment 的名称。
+例如，如果你的 DNS Deployment 名称是 `coredns`，则你的扩展目标是 Deployment/coredns。
<!--
-## Enabling DNS horizontal autoscaling
+CoreDNS is the default DNS service for Kubernetes. CoreDNS sets the label
+`k8s-app=kube-dns` so that it can work in clusters that originally used
+kube-dns.
+-->
+{{< note >}}
+CoreDNS 是 Kubernetes 的默认 DNS 服务。CoreDNS 设置标签 `k8s-app=kube-dns`，
+以便能够在原来使用 `kube-dns` 的集群中工作。
+{{< /note >}}
+
+<!--
+## Enabling DNS horizontal autoscaling {#enablng-dns-horizontal-autoscaling}
In this section, you create a Deployment. The Pods in the Deployment run a
container based on the `cluster-proportional-autoscaler-amd64` image.
Create a file named `dns-horizontal-autoscaler.yaml` with this content:
-
-{{< codenew file="admin/dns/dns-horizontal-autoscaler.yaml" >}}
-
-In the file, replace `<SCALE_TARGET>` with your scale target.
-
-Go to the directory that contains your configuration file, and enter this
-command to create the Deployment:
-
-```shell
-kubectl apply -f dns-horizontal-autoscaler.yaml
-```
-
-The output of a successful command is:
-
- deployment.apps/dns-autoscaler created
-
-DNS horizontal autoscaling is now enabled.
-->
-## 启用 DNS 水平自动伸缩
+## 启用 DNS 水平自动扩缩 {#enablng-dns-horizontal-autoscaling}
-在本段，我们创建一个 Deployment。Deployment 中的 Pod 运行一个基于 `cluster-proportional-autoscaler-amd64` 镜像的容器。
+在本节，我们创建一个 Deployment。Deployment 中的 Pod 运行一个基于
+`cluster-proportional-autoscaler-amd64` 镜像的容器。
创建文件 `dns-horizontal-autoscaler.yaml`，内容如下所示：
{{< codenew file="admin/dns/dns-horizontal-autoscaler.yaml" >}}
-在文件中，将 `<SCALE_TARGET>` 替换成 scale 目标。
+<!--
+In the file, replace `<SCALE_TARGET>` with your scale target.
+
+Go to the directory that contains your configuration file, and enter this
+command to create the Deployment:
+-->
+在文件中，将 `<SCALE_TARGET>` 替换成扩缩目标。
进入到包含配置文件的目录中，输入如下命令创建 Deployment：
@@ -215,46 +173,77 @@ DNS horizontal autoscaling is now enabled.
kubectl apply -f dns-horizontal-autoscaler.yaml
```
+<!--
+The output of a successful command is:
+-->
一个成功的命令输出是：
- deployment.apps/dns-autoscaler created
-
-DNS 水平自动伸缩在已经启用了。
+```
+deployment.apps/dns-autoscaler created
+```
<!--
-## Tuning autoscaling parameters
+DNS horizontal autoscaling is now enabled.
+-->
+DNS 水平自动扩缩在已经启用了。
+
+<!--
+## Tuning autoscaling parameters {#tuning-autoscaling-parameters}
Verify that the dns-autoscaler {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} exists:
+-->
+## 调优自动扩缩参数 {#tuning-autoscaling-parameters}
+
+验证 dns-autoscaler {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} 是否存在：
```shell
kubectl get configmap --namespace=kube-system
```
+<!--
The output is similar to this:
+-->
+输出类似于：
- NAME DATA AGE
- ...
- dns-autoscaler 1 ...
- ...
+```
+NAME DATA AGE
+...
+dns-autoscaler 1 ...
+...
+```
+<!--
Modify the data in the ConfigMap:
+-->
+修改该 ConfigMap 中的数据：
```shell
kubectl edit configmap dns-autoscaler --namespace=kube-system
```
+<!--
Look for this line:
+-->
+找到如下这行内容：
```yaml
linear: '{"coresPerReplica":256,"min":1,"nodesPerReplica":16}'
```
+<!--
Modify the fields according to your needs. The "min" field indicates the
minimal number of DNS backends. The actual number of backends number is
calculated using this equation:
+-->
- replicas = max( ceil( cores * 1/coresPerReplica ) , ceil( nodes * 1/nodesPerReplica ) )
+根据需要修改对应的字段。“min” 字段表明 DNS 后端的最小数量。
+实际后端的数量通过使用如下公式来计算：
+```
+replicas = max( ceil( cores * 1/coresPerReplica ) , ceil( nodes * 1/nodesPerReplica ) )
+```
+
+<!--
Note that the values of both `coresPerReplica` and `nodesPerReplica` are
integers.
@@ -265,42 +254,13 @@ cores, `nodesPerReplica` dominates.
There are other supported scaling patterns. For details, see
[cluster-proportional-autoscaler](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler).
-->
-## 调优自动伸缩参数
-
-验证 dns-autoscaler {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} 是否存在：
-
-```shell
-kubectl get configmap --namespace=kube-system
-```
-
-输出类似如下所示：
-
- NAME DATA AGE
- ...
- dns-autoscaler 1 ...
- ...
-
-修改该 ConfigMap 中的数据：
-
-```shell
-kubectl edit configmap dns-autoscaler --namespace=kube-system
-```
-
-找到如下这行内容：
-
-```yaml
-linear: '{"coresPerReplica":256,"min":1,"nodesPerReplica":16}'
-```
-
-根据需要修改对应的字段。“min” 字段说明 DNS 后端的最小数量。实际后端的数量，通过使用如下公式来计算：
-
- replicas = max( ceil( cores * 1/coresPerReplica ) , ceil( nodes * 1/nodesPerReplica ) )
-
注意 `coresPerReplica` 和 `nodesPerReplica` 的值都是整数。
-想法是，当一个集群使用具有很多核心的节点时，由 `coresPerReplica` 来控制。 当一个集群使用具有较少核心的节点时，由 `nodesPerReplica` 来控制。
+背后的思想是，当一个集群使用具有很多核心的节点时，由 `coresPerReplica` 来控制。
+当一个集群使用具有较少核心的节点时，由 `nodesPerReplica` 来控制。
-其它的伸缩模式也是支持的，详情查看 [cluster-proportional-autoscaler](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler)。
+其它的扩缩模式也是支持的，详情查看
+[cluster-proportional-autoscaler](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler)。
<!--
## Disable DNS horizontal autoscaling
@@ -308,37 +268,16 @@ linear: '{"coresPerReplica":256,"min":1,"nodesPerReplica":16}'
There are a few options for tuning DNS horizontal autoscaling. Which option to
use depends on different conditions.
-->
-## 禁用 DNS 水平自动伸缩
+## 禁用 DNS 水平自动扩缩
-有几个 DNS 水平自动伸缩的选项。具体使用哪个选项因环境而异。
+有几个可供调优的 DNS 水平自动扩缩选项。具体使用哪个选项因环境而异。
<!--
### Option 1: Scale down the dns-autoscaler deployment to 0 replicas
This option works for all situations. Enter this command:
-
-```shell
-kubectl scale deployment --replicas=0 dns-autoscaler --namespace=kube-system
-```
-
-The output is:
-
- deployment.extensions/dns-autoscaler scaled
-
-Verify that the replica count is zero:
-
-```shell
-kubectl get deployment --namespace=kube-system
-```
-
-The output displays 0 in the DESIRED and CURRENT columns:
-
- NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
- ...
- dns-autoscaler 0 0 0 0 ...
- ...
-->
-### 选项 1：调小 dns-autoscaler deployment 至 0 个副本
+### 选项 1：缩容 dns-autoscaler Deployment 至 0 个副本
该选项适用于所有场景。运行如下命令：
@@ -346,48 +285,54 @@ The output displays 0 in the DESIRED and CURRENT columns:
kubectl scale deployment --replicas=0 dns-autoscaler --namespace=kube-system
```
+<!-- The output is: -->
输出如下所示：
- deployment.extensions/dns-autoscaler scaled
+```
+deployment.apps/dns-autoscaler scaled
+```
+<!--
+Verify that the replica count is zero:
+-->
验证当前副本数为 0：
```shell
-kubectl get deployment --namespace=kube-system
+kubectl get rs --namespace=kube-system
```
+<!--
+The output displays 0 in the DESIRED and CURRENT columns:
+-->
输出内容中，在 DESIRED 和 CURRENT 列显示为 0：
- NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
- ...
- dns-autoscaler 0 0 0 0 ...
- ...
+```
+NAME DESIRED CURRENT READY AGE
+...
+dns-autoscaler-6b59789fc8 0 0 0 ...
+...
+```
<!--
### Option 2: Delete the dns-autoscaler deployment
This option works if dns-autoscaler is under your own control, which means
no one will re-create it:
-
-```shell
-kubectl delete deployment dns-autoscaler --namespace=kube-system
-```
-
-The output is:
-
- deployment.extensions "dns-autoscaler" deleted
-->
### 选项 2：删除 dns-autoscaler Deployment
-如果 dns-autoscaler 为您所控制，该选项可以正常工作，也就说没有人会去重新创建它：
+如果 dns-autoscaler 为你所控制，也就说没有人会去重新创建它，可以选择此选项：
```shell
kubectl delete deployment dns-autoscaler --namespace=kube-system
```
+<!-- The output is:-->
输出内容如下所示：
- deployment.extensions "dns-autoscaler" deleted
+```
+deployment.apps "dns-autoscaler" deleted
+```
<!--
### Option 3: Delete the dns-autoscaler manifest file from the master node
@@ -395,27 +340,28 @@ kubectl delete deployment dns-autoscaler --namespace=kube-system
This option works if dns-autoscaler is under control of the (deprecated)
[Addon Manager](https://git.k8s.io/kubernetes/cluster/addons/README.md),
and you have write access to the master node.
+-->
+### 选项 3：从主控节点删除 dns-autoscaler 清单文件
+如果 dns-autoscaler 在[插件管理器](https://git.k8s.io/kubernetes/cluster/addons/README.md)
+的控制之下，并且具有操作 master 节点的写权限，可以使用此选项。
+
+<!--
Sign in to the master node and delete the corresponding manifest file.
The common path for this dns-autoscaler is:
+-->
+登录到主控节点，删除对应的清单文件。
+dns-autoscaler 对应的路径一般为：
- /etc/kubernetes/addons/dns-horizontal-autoscaler/dns-horizontal-autoscaler.yaml
+```
+/etc/kubernetes/addons/dns-horizontal-autoscaler/dns-horizontal-autoscaler.yaml
+```
+<!--
After the manifest file is deleted, the Addon Manager will delete the
dns-autoscaler Deployment.
-->
-### 选项 3：从 master 节点删除 dns-autoscaler manifest 文件
-
-如果 dns-autoscaler 在[插件管理器](https://git.k8s.io/kubernetes/cluster/addons/README.md)的控制之下，该选项可以工作，并且具有操作 master 节点的写权限。
-
-登录到 master 节点，删除对应的 manifest 文件。
-dns-autoscaler 的路径一般为：
-
- /etc/kubernetes/addons/dns-horizontal-autoscaler/dns-horizontal-autoscaler.yaml
-
-当 manifest 文件删除后，插件管理器将删除 dns-autoscaler Deployment。
-
-
+当清单文件被删除后，插件管理器将删除 dns-autoscaler Deployment。
<!-- discussion -->
@@ -427,63 +373,45 @@ the DNS service.
* An autoscaler Pod runs a client that polls the Kubernetes API server for the
number of nodes and cores in the cluster.
+-->
+## 理解 DNS 水平自动扩缩工作原理
+* cluster-proportional-autoscaler 应用独立于 DNS 服务部署。
+
+* autoscaler Pod 运行一个客户端，它通过轮询 Kubernetes API 服务器获取集群中节点和核心的数量。
+
+<!--
* A desired replica count is calculated and applied to the DNS backends based on
the current schedulable nodes and cores and the given scaling parameters.
* The scaling parameters and data points are provided via a ConfigMap to the
autoscaler, and it refreshes its parameters table every poll interval to be up
to date with the latest desired scaling parameters.
+-->
+* 系统会基于当前可调度的节点个数、核心数以及所给的扩缩参数，计算期望的副本数并应用到 DNS 后端。
+* 扩缩参数和数据点会基于一个 ConfigMap 来提供给 autoscaler，它会在每次轮询时刷新它的参数表，
+ 以与最近期望的扩缩参数保持一致。
+
+<!--
* Changes to the scaling parameters are allowed without rebuilding or restarting
the autoscaler Pod.
* The autoscaler provides a controller interface to support two control
patterns: *linear* and *ladder*.
-->
-## 理解 DNS 水平自动伸缩工作原理
-
-* cluster-proportional-autoscaler 应用独立于 DNS service 部署。
-
-* autoscaler Pod 运行一个客户端，它通过轮询 Kubernetes API server 获取集群中节点和核心的数量。
-
-* 一个期望的副本数会被计算，并根据当前可调度的节点、核心数、给定伸缩参数，被应用到 DNS 后端。
-
-* 伸缩参数和数据点会基于一个 ConfigMap 来提供给 autoscaler，它会在每次轮询时刷新它的参数表，以与最近期望的伸缩参数保持一致。
-
-* 允许对伸缩参数进行修改，而不需要重建或重启 autoscaler Pod。
+* 扩缩参数是可以被修改的，而且不需要重建或重启 autoscaler Pod。
* autoscaler 提供了一个控制器接口来支持两种控制模式：*linear* 和 *ladder*。
-<!--
-## Future enhancements
-
-Control patterns, in addition to linear and ladder, that consider custom metrics
-are under consideration as a future development.
-
-Scaling of DNS backends based on DNS-specific metrics is under consideration as
-a future development. The current implementation, which uses the number of nodes
-and cores in cluster, is limited.
-
-Support for custom metrics, similar to that provided by
-[Horizontal Pod Autoscaling](/docs/tasks/run-application/horizontal-pod-autoscale/),
-is under consideration as a future development.
--->
-## 未来功能增强
-
-控制模式，除了 linear 和 ladder，正在考虑未来将开发自定义 metric。
-
-基于 DNS 特定 metric 的 DNS 后端的伸缩，考虑未来会开发。当前实现是使用集群中节点和核心的数量是受限制的。
-
-支持自定义 metric，类似于 [Horizontal Pod 自动伸缩](/docs/tasks/run-application/horizontal-pod-autoscale/) 所提供的，考虑未来进行开发。
-
-
-
## {{% heading "whatsnext" %}}
<!--
+* Read about [Guaranteed Scheduling For Critical Add-On Pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/).
* Learn more about the
[implementation of cluster-proportional-autoscaler](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler).
--->
-* 了解更多关于 [cluster-proportional-autoscaler 实现](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler)的相关信息。
+
+-->
+* 阅读[为关键插件 Pod 提供的调度保障](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)
+* 进一步了解 [cluster-proportional-autoscaler 实现](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler)
diff --git a/content/zh/docs/tasks/administer-cluster/encrypt-data.md b/content/zh/docs/tasks/administer-cluster/encrypt-data.md
index 5db9e194ab..65e7689406 100644
--- a/content/zh/docs/tasks/administer-cluster/encrypt-data.md
+++ b/content/zh/docs/tasks/administer-cluster/encrypt-data.md
@@ -1,17 +1,13 @@
---
-reviewers:
-- smarterclayton
title: 静态加密 Secret 数据
content_type: task
---
<!--
----
reviewers:
- smarterclayton
title: Encrypting Secret Data at Rest
content_type: task
----
-->
<!-- overview -->
@@ -20,42 +16,21 @@ This page shows how to enable and configure encryption of secret data at rest.
-->
本文展示如何启用和配置静态 Secret 数据的加密
-
## {{% heading "prerequisites" %}}
-
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
-* Kubernetes version 1.7.0 or later is required
-
* etcd v3 or later is required
-
-* Encryption at rest is alpha in 1.7.0 which means it may change without notice. Users may be required to decrypt their data prior to upgrading to 1.8.0.
-->
-* 需要 Kubernetes 1.7.0 或者更高版本
-
* 需要 etcd v3 或者更高版本
-* 静态数据加密在 1.7.0 中仍然是 alpha 版本，这意味着它可能会在没有通知的情况下进行更改。在升级到 1.8.0 之前，用户可能需要解密他们的数据。
-
-
-
-{{< toc >}}
-
-## {{% heading "prerequisites" %}}
-
-
-{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
-
<!-- steps -->
<!--
## Configuration and determining whether encryption at rest is already enabled
-The `kube-apiserver` process accepts an argument `--experimental-encryption-provider-config`
+The `kube-apiserver` process accepts an argument `-experimental-encryption-provider-config`
that controls how API data is encrypted in etcd. An example configuration
is provided below.
@@ -69,8 +44,8 @@ is provided below.
## 理解静态数据加密
```yaml
-kind: EncryptionConfiguration
apiVersion: apiserver.config.k8s.io/v1
+kind: EncryptionConfiguration
resources:
- resources:
- secrets
@@ -100,23 +75,31 @@ Each `resources` array item is a separate config and contains a complete configu
that should be encrypted. The `providers` array is an ordered list of the possible encryption
providers. Only one provider type may be specified per entry (`identity` or `aescbc` may be provided,
but not both in the same item).
+-->
+每个 `resources` 数组项目是一个单独的完整的配置。
+`resources.resources` 字段是要加密的 Kubernetes 资源名称（`resource` 或 `resource.group`）的数组。
+`providers` 数组是可能的加密 provider 的有序列表。
+每个条目只能指定一个 provider 类型（可以是 `identity` 或 `aescbc`，但不能在同一个项目中同时指定）。
+<!--
The first provider in the list is used to encrypt resources going into storage. When reading
resources from storage each provider that matches the stored data attempts to decrypt the data in
order. If no provider can read the stored data due to a mismatch in format or secret key, an error
is returned which prevents clients from accessing that resource.
+-->
+列表中的第一个 provider 用于加密进入存储的资源。
+当从存储器读取资源时，与存储的数据匹配的所有 provider 将按顺序尝试解密数据。
+如果由于格式或密钥不匹配而导致没有 provider 能够读取存储的数据，则会返回一个错误，以防止客户端访问该资源。
+<!--
**IMPORTANT:** If any resource is not readable via the encryption config (because keys were changed),
the only recourse is to delete that key from the underlying etcd directly. Calls that attempt to
read that resource will fail until it is deleted or a valid decryption key is provided.
-->
-每个 `resources` 数组项目是一个单独的完整的配置。 `resources.resources` 字段是要加密的 Kubernetes 资源名称（`resource` 或 `resource.group`）的数组。
-`providers` 数组是可能的加密 provider 的有序列表。每个条目只能指定一个 provider 类型（可以是 `identity` 或 `aescbc`，但不能在同一个项目中同时指定）。
-
-列表中的第一个提供者用于加密进入存储的资源。当从存储器读取资源时，与存储的数据匹配的所有提供者将尝试按顺序解密数据。
-如果由于格式或密钥不匹配而导致提供者无法读取存储的数据，则会返回一个错误，以防止客户端访问该资源。
-
-**重要：** 如果通过加密配置无法读取资源（因为密钥已更改），唯一的方法是直接从基础 etcd 中删除该密钥。任何尝试读取资源的调用将会失败，直到它被删除或提供有效的解密密钥。
+{{< caution >}}
+**重要：** 如果通过加密配置无法读取资源（因为密钥已更改），唯一的方法是直接从底层 etcd 中删除该密钥。
+任何尝试读取资源的调用将会失败，直到它被删除或提供有效的解密密钥。
+{{< /caution >}}
### Providers:
@@ -132,28 +115,57 @@ Name | Encryption | Strength | Speed | Key Length | Other Considerations
Each provider supports multiple keys - the keys are tried in order for decryption, and if the provider
is the first provider, the first key is used for encryption.
-->
-名称 | 加密类型 | 强度 | 速度 | 密钥长度 | 其它事项
+{{< table caption="Kubernetes 静态数据加密的 Providers" >}}
+名称 | 加密类型 | 强度 | 速度 | 密钥长度 | 其它事项
-----|------------|----------|-------|------------|---------------------
`identity` | 无 | N/A | N/A | N/A | 不加密写入的资源。当设置为第一个 provider 时，资源将在新值写入时被解密。
`aescbc` | 填充 PKCS#7 的 AES-CBC | 最强 | 快 | 32字节 | 建议使用的加密项，但可能比 `secretbox` 稍微慢一些。
`secretbox` | XSalsa20 和 Poly1305 | 强 | 更快 | 32字节 | 较新的标准，在需要高度评审的环境中可能不被接受。
-`aesgcm` | 带有随机数的 AES-GCM | 必须每 200k 写入一次 | 最快 | 16, 24, 或者 32字节 | 建议不要使用，除非实施了自动密钥循环方案。
-`kms` | 使用信封加密方案：数据使用带有 PKCS#7 填充的 AES-CBC 通过 data encryption keys（DEK）加密，DEK 根据 Key Management Service（KMS）中的配置通过 key encryption keys（KEK）加密 | 最强 | 快 | 32字节 | 建议使用第三方工具进行密钥管理。为每个加密生成新的 DEK，并由用户控制 KEK 轮换来简化密钥轮换。[配置 KMS 提供程序](/docs/tasks/administer-cluster/kms-provider/)
+`aesgcm` | 带有随机数的 AES-GCM | 必须每 200k 写入一次 | 最快 | 16, 24 或者 32字节 | 建议不要使用，除非实施了自动密钥循环方案。
+`kms` | 使用信封加密方案：数据使用带有 PKCS#7 填充的 AES-CBC 通过数据加密密钥（DEK）加密，DEK 根据 Key Management Service（KMS）中的配置通过密钥加密密钥（Key Encryption Keys，KEK）加密 | 最强 | 快 | 32字节 | 建议使用第三方工具进行密钥管理。为每个加密生成新的 DEK，并由用户控制 KEK 轮换来简化密钥轮换。[配置 KMS 提供程序](/zh/docs/tasks/administer-cluster/kms-provider/)
每个 provider 都支持多个密钥 - 在解密时会按顺序使用密钥，如果是第一个 provider，则第一个密钥用于加密。
+<!--
+__Storing the raw encryption key in the EncryptionConfig only moderately improves your security posture, compared to no encryption.
+Please use `kms` provider for additional security.__ By default, the `identity` provider is used to protect secrets in etcd, which
+provides no encryption. `EncryptionConfiguration` was introduced to encrypt secrets locally, with a locally managed key.
+-->
+__在 EncryptionConfig 中保存原始的加密密钥与不加密相比只会略微地提升安全级别。
+请使用 `kms` 驱动以获得更强的安全性。__
+默认情况下，`identity` 驱动被用来对 etcd 中的 Secret 提供保护，
+而这个驱动不提供加密能力。
+`EncryptionConfiguration` 的引入是为了能够使用本地管理的密钥来在本地加密 Secret 数据。
+
+<!--
+Encrypting secrets with a locally managed key protects against an etcd compromise, but it fails to protect against a host compromise.
+Since the encryption keys are stored on the host in the EncryptionConfig YAML file, a skilled attacker can access that file and
+extract the encryption keys.
+-->
+使用本地管理的密钥来加密 Secret 能够保护数据免受 etcd 破坏的影响，不过无法针对
+主机被侵入提供防护。
+这是因为加密的密钥保存在主机上的 EncryptionConfig YAML 文件中，有经验的入侵者
+仍能访问该文件并从中提取出加密密钥。
+
+<!--
+Envelope encryption creates dependence on a separate key, not stored in Kubernetes. In this case, an attacker would need to compromise etcd, the kubeapi-server, and the third-party KMS provider to retrieve the plaintext values, providing a higher level of security than locally-stored encryption keys.
+-->
+封套加密（Envelope Encryption）引入了对独立密钥的依赖，而这个密钥并不保存在 Kubernetes 中。
+在这种情况下下，入侵者需要攻破 etcd、kube-apiserver 和第三方的 KMS
+驱动才能获得明文数据，因而这种方案提供了比本地保存加密密钥更高的安全级别。
+
<!--
## Encrypting your data
Create a new encryption config file:
-->
-## 加密您的数据
+## 加密你的数据
创建一个新的加密配置文件：
```yaml
-kind: EncryptionConfiguration
apiVersion: apiserver.config.k8s.io/v1
+kind: EncryptionConfiguration
resources:
- resources:
- secrets
@@ -172,11 +184,11 @@ To create a new secret perform the following steps:
-->
遵循如下步骤来创建一个新的 secret：
-1. 生成一个 32 字节的随机密钥并进行 base64 编码。如果您在 Linux 或 Mac OS X 上，请运行以下命令：
+1. 生成一个 32 字节的随机密钥并进行 base64 编码。如果你在 Linux 或 Mac OS X 上，请运行以下命令：
- ```
- head -c 32 /dev/urandom | base64
- ```
+ ```
+ head -c 32 /dev/urandom | base64
+ ```
<!--
2. Place that value in the secret field.
@@ -186,11 +198,15 @@ To create a new secret perform the following steps:
**IMPORTANT:** Your config file contains keys that can decrypt content in etcd, so you must properly restrict permissions on your masters so only the user who runs the kube-apiserver can read it.
-->
2. 将这个值放入到 secret 字段中。
-3. 设置 `kube-apiserver` 的 `--experimental-encryption-provider-config` 参数，将其指定到配置文件所在位置。
-4. 重启您的 API server。
+3. 设置 `kube-apiserver` 的 `--experimental-encryption-provider-config` 参数，将其指向
+ 配置文件所在位置。
+4. 重启你的 API server。
-**重要：** 您的配置文件包含可以解密 etcd 内容的密钥，因此您必须正确限制主设备的权限，以便只有能运行 kube-apiserver 的用户才能读取它。
+{{< caution >}}
+你的配置文件包含可以解密 etcd 内容的密钥，因此你必须正确限制主控节点的访问权限，
+以便只有能运行 kube-apiserver 的用户才能读取它。
+{{< caution >}}
<!--
## Verifying that data is encrypted
@@ -201,53 +217,58 @@ program to retrieve the contents of your secret.
1. Create a new secret called `secret1` in the `default` namespace:
-->
-## 验证数据是否被加密
+## 验证数据已被加密
数据在写入 etcd 时会被加密。重新启动你的 `kube-apiserver` 后，任何新创建或更新的密码在存储时都应该被加密。
如果想要检查，你可以使用 `etcdctl` 命令行程序来检索你的加密内容。
1. 创建一个新的 secret，名称为 `secret1`，命名空间为 `default`：
- ```
- kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
- ```
+ ```shell
+ kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
+ ```
<!--
2. Using the etcdctl commandline, read that secret out of etcd:
-->
2. 使用 etcdctl 命令行，从 etcd 中读取 secret：
- ```
- ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C
- ```
+ ```shell
+ ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C
+ ```
+
+ <!--
+ where `[...]` must be the additional arguments for connecting to the etcd server.
+ -->
+ 这里的 `[...]` 是用来连接 etcd 服务的额外参数。
<!--
- where `[...]` must be the additional arguments for connecting to the etcd server.
3. Verify the stored secret is prefixed with `k8s:enc:aescbc:v1:` which indicates the `aescbc` provider has encrypted the resulting data.
4. Verify the secret is correctly decrypted when retrieved via the API:
-->
- 这里的 `[...]` 是用来连接 etcd 服务的额外参数。
3. 验证存储的密钥前缀是否为 `k8s:enc:aescbc:v1:`，这表明 `aescbc` provider 已加密结果数据。
4. 通过 API 检索，验证 secret 是否被正确解密：
- ```
- kubectl describe secret secret1 -n default
- ```
-
-<!--
- should match `mykey: mydata`
--->
- 必须匹配 `mykey: mydata`
+ ```shell
+ kubectl describe secret secret1 -n default
+ ```
+ <!--
+ should match `mykey: mydata`, mydata is encoded, check [decoding a secret](/docs/concepts/configuration/secret#decoding-a-secret) to
+ completely decode the secret.
+ -->
+ 其输出应该是 `mykey: bXlkYXRh`，`mydata` 数据是被加密过的，请参阅
+ [解密 Secret](/zh/docs/concepts/configuration/secret#decoding-a-secret)
+ 了解如何完全解码 Secret 内容。
<!--
## Ensure all secrets are encrypted
Since secrets are encrypted on write, performing an update on a secret will encrypt that content.
-->
-## 确保所有 secret 都被加密
+## 确保所有 Secret 都被加密
-由于 secret 是在写入时被加密，因此对 secret 执行更新也会加密该内容。
+由于 Secret 是在写入时被加密，因此对 Secret 执行更新也会加密该内容。
```
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
@@ -255,13 +276,17 @@ kubectl get secrets --all-namespaces -o json | kubectl replace -f -
<!--
The command above reads all secrets and then updates them to apply server side encryption.
+-->
+上面的命令读取所有 Secret，然后使用服务端加密来更新其内容。
+
+<!--
If an error occurs due to a conflicting write, retry the command.
For larger clusters, you may wish to subdivide the secrets by namespace or script an update.
-->
-上面的命令读取所有 secret，然后使用服务端加密来进行更新。
+{{< note >}}
如果由于冲突写入而发生错误，请重试该命令。
-对于较大的集群，您可能希望通过命名空间或更新脚本来分割 secret。
-
+对于较大的集群，你可能希望通过命名空间或更新脚本来对 Secret 进行划分。
+{{< /note >}}
<!--
## Rotating a decryption key
@@ -273,14 +298,15 @@ the presence of a highly available deployment where multiple `kube-apiserver` pr
2. Restart all `kube-apiserver` processes to ensure each server can decrypt using the new key
3. Make the new key the first entry in the `keys` array so that it is used for encryption in the config
4. Restart all `kube-apiserver` processes to ensure each server now encrypts using the new key
-5. Run `kubectl get secrets --all-namespaces -o json | kubectl replace -f -` to encrypt all existing secrets with the new key
+5. Run `kubectl get secrets -all-namespaces -o json | kubectl replace -f -` to encrypt all existing secrets with the new key
6. Remove the old decryption key from the config after you back up etcd with the new key in use and update all secrets
With a single `kube-apiserver`, step 2 may be skipped.
-->
-## 回滚解密密钥
+## 轮换解密密钥
-在不发生停机的情况下更改 secret 需要多步操作，特别是在有多个 `kube-apiserver` 进程正在运行的高可用部署的情况下。
+在不发生停机的情况下更改 Secret 需要多步操作，特别是在有多个 `kube-apiserver` 进程正在运行的
+高可用环境中。
1. 生成一个新密钥并将其添加为所有服务器上当前提供程序的第二个密钥条目
2. 重新启动所有 `kube-apiserver` 进程以确保每台服务器都可以使用新密钥进行解密
@@ -291,7 +317,6 @@ With a single `kube-apiserver`, step 2 may be skipped.
如果只有一个 `kube-apiserver`，第 2 步可能可以忽略。
-
<!--
## Decrypting all data
@@ -302,8 +327,8 @@ To disable encryption at rest place the `identity` provider as the first entry i
要禁用 rest 加密，请将 `identity` provider 作为配置中的第一个条目：
```yaml
-kind: EncryptionConfiguration
apiVersion: apiserver.config.k8s.io/v1
+kind: EncryptionConfiguration
resources:
- resources:
- secrets
@@ -316,11 +341,16 @@ resources:
```
<!--
-and restart all `kube-apiserver` processes. Then run the command `kubectl get secrets --all-namespaces -o json | kubectl replace -f -`
+and restart all `kube-apiserver` processes. Then run
+-->
+并重新启动所有 `kube-apiserver` 进程。然后运行：
+
+```
+kubectl get secrets -all-namespaces -o json | kubectl replace -f -`
+```
+
+<!--
to force all secrets to be decrypted.
-->
-并重新启动所有 `kube-apiserver` 进程。然后运行命令 `kubectl get secrets --all-namespaces -o json | kubectl replace -f -` 强制解密所有 secret。
-
-
-
+以强制解密所有 secret。
diff --git a/content/zh/docs/tasks/administer-cluster/extended-resource-node.md b/content/zh/docs/tasks/administer-cluster/extended-resource-node.md
index 9a73d35278..9eeb4e09bc 100644
--- a/content/zh/docs/tasks/administer-cluster/extended-resource-node.md
+++ b/content/zh/docs/tasks/administer-cluster/extended-resource-node.md
@@ -3,10 +3,8 @@ title: 为节点发布扩展资源
content_type: task
---
<!--
----
title: Advertise Extended Resources for a Node
content_type: task
----
-->
<!-- overview -->
@@ -16,38 +14,27 @@ This page shows how to specify extended resources for a Node.
Extended resources allow cluster administrators to advertise node-level
resources that would otherwise be unknown to Kubernetes.
-->
-本文展示了如何为节点指定扩展资源。 扩展资源允许集群管理员发布节点级别的资源，这些资源在不进行发布的情况下无法被 Kubernetes 感知。
-
-
-
-
+本文展示了如何为节点指定扩展资源（Extended Resource）。
+扩展资源允许集群管理员发布节点级别的资源，这些资源在不进行发布的情况下无法被 Kubernetes 感知。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
-
<!-- steps -->
<!--
## Get the names of your Nodes
-```shell
-kubectl get nodes
-```
-
Choose one of your Nodes to use for this exercise.
-->
-## 获取您的节点名称
+## 获取你的节点名称
```shell
kubectl get nodes
```
-选择您的一个节点用于此练习。
+选择一个节点用于此练习。
<!--
## Advertise a new extended resource on one of your Nodes
@@ -56,6 +43,12 @@ To advertise a new extended resource on a Node, send an HTTP PATCH request to
the Kubernetes API server. For example, suppose one of your Nodes has four dongles
attached. Here's an example of a PATCH request that advertises four dongle resources
for your Node.
+-->
+## 在你的一个节点上发布一种新的扩展资源
+
+为在一个节点上发布一种新的扩展资源，需要发送一个 HTTP PATCH 请求到 Kubernetes API server。
+例如：假设你的一个节点上带有四个 dongle 资源。
+下面是一个 PATCH 请求的示例，该请求为你的节点发布四个 dongle 资源。
```shell
PATCH /api/v1/nodes/<your-node-name>/status HTTP/1.1
@@ -72,101 +65,51 @@ Host: k8s-master:8080
]
```
+<!--
Note that Kubernetes does not need to know what a dongle is or what a dongle is for.
The preceding PATCH request just tells Kubernetes that your Node has four things that
you call dongles.
Start a proxy, so that you can easily send requests to the Kubernetes API server:
+-->
+注意：Kubernetes 不需要了解 dongle 资源的含义和用途。
+前面的 PATCH 请求仅仅告诉 Kubernetes 你的节点拥有四个你称之为 dongle 的东西。
+
+启动一个代理（proxy），以便你可以很容易地向 Kubernetes API server 发送请求：
```shell
kubectl proxy
```
+<!--
In another command window, send the HTTP PATCH request.
Replace `<your-node-name>` with the name of your Node:
+-->
+
+在另一个命令窗口中，发送 HTTP PATCH 请求。 用你的节点名称替换 `<your-node-name>`：
```shell
curl --header "Content-Type: application/json-patch+json" \
---request PATCH \
---data '[{"op": "add", "path": "/status/capacity/example.com~1dongle", "value": "4"}]' \
-http://localhost:8001/api/v1/nodes/<your-node-name>/status
+ --request PATCH \
+ --data '[{"op": "add", "path": "/status/capacity/example.com~1dongle", "value": "4"}]' \
+ http://localhost:8001/api/v1/nodes/<your-node-name>/status
```
-{{< note >}}
+<!--
In the preceding request, `~1` is the encoding for the character / in
the patch path. The operation path value in JSON-Patch is interpreted as a
JSON-Pointer. For more details, see
[IETF RFC 6901](https://tools.ietf.org/html/rfc6901), section 3.
-{{< /note >}}
-
-The output shows that the Node has a capacity of 4 dongles:
-
-```
-"capacity": {
- "cpu": "2",
- "memory": "2049008Ki",
- "example.com/dongle": "4",
-```
-
-Describe your Node:
-
-```
-kubectl describe node <your-node-name>
-```
-
-Once again, the output shows the dongle resource:
-
-```yaml
-Capacity:
- cpu: 2
- memory: 2049008Ki
- example.com/dongle: 4
-```
-
-Now, application developers can create Pods that request a certain
-number of dongles. See
-[Assign Extended Resources to a Container](/docs/tasks/configure-pod-container/extended-resource/).
-->
-## 在您的一个节点上发布一种新的扩展资源
-
-为在一个节点上发布一种新的扩展资源，需要发送一个 HTTP PATCH 请求到 Kubernetes API server。 例如：假设您的一个节点上带有四个 dongle 资源。下面是一个 PATCH 请求的示例， 该请求为您的节点发布四个 dongle 资源。
-
-```shell
-PATCH /api/v1/nodes/<your-node-name>/status HTTP/1.1
-Accept: application/json
-Content-Type: application/json-patch+json
-Host: k8s-master:8080
-
-[
- {
- "op": "add",
- "path": "/status/capacity/example.com~1dongle",
- "value": "4"
- }
-]
-```
-
-注意：Kubernetes 不需要了解 dongle 资源的含义和用途。 前面的 PATCH 请求仅仅告诉 Kubernetes 您的节点拥有四个您称之为 dongle 的东西。
-
-启动一个代理（proxy），以便您可以很容易地向 Kubernetes API server 发送请求：
-
-```shell
-kubectl proxy
-```
-
-在另一个命令窗口中，发送 HTTP PATCH 请求。 用您的节点名称替换 `<your-node-name>`：
-
-```shell
-curl --header "Content-Type: application/json-patch+json" \
---request PATCH \
---data '[{"op": "add", "path": "/status/capacity/example.com~1dongle", "value": "4"}]' \
-http://localhost:8001/api/v1/nodes/<your-node-name>/status
-```
-
{{< note >}}
-在前面的请求中，`~1` 为 patch 路径中 “/” 符号的编码。JSON-Patch 中的操作路径值被解析为 JSON 指针。 更多细节，请查看 [IETF RFC 6901](https://tools.ietf.org/html/rfc6901) 的第 3 部分。
+在前面的请求中，`~1` 为 patch 路径中 “/” 符号的编码。
+JSON-Patch 中的操作路径值被解析为 JSON 指针。
+更多细节，请查看 [IETF RFC 6901](https://tools.ietf.org/html/rfc6901) 的第 3 节。
{{< /note >}}
+<!--
+The output shows that the Node has a capacity of 4 dongles:
+-->
输出显示该节点的 dongle 资源容量（capacity）为 4：
```
@@ -176,12 +119,14 @@ http://localhost:8001/api/v1/nodes/<your-node-name>/status
"example.com/dongle": "4",
```
-描述您的节点：
+<!-- Describe your Node: -->
+描述你的节点：
-```
+```shell
kubectl describe node <your-node-name>
```
+<!-- Once again, the output shows the dongle resource: -->
输出再次展示了 dongle 资源：
```yaml
@@ -191,7 +136,13 @@ Capacity:
example.com/dongle: 4
```
-现在，应用开发者可以创建请求一定数量 dongle 资源的 Pod 了。 参见[将扩展资源分配给容器](/docs/tasks/configure-pod-container/extended-resource/)。
+<!--
+Now, application developers can create Pods that request a certain
+number of dongles. See
+[Assign Extended Resources to a Container](/docs/tasks/configure-pod-container/extended-resource/).
+-->
+现在，应用开发者可以创建请求一定数量 dongle 资源的 Pod 了。
+参见[将扩展资源分配给容器](/zh/docs/tasks/configure-pod-container/extended-resource/)。
<!--
## Discussion
@@ -202,17 +153,25 @@ running on the Node, it can have a certain number of dongles to be shared
by all components running on the Node. And just as application developers
can create Pods that request a certain amount of memory and CPU, they can
create Pods that request a certain number of dongles.
+-->
+## 讨论
+扩展资源类似于内存和 CPU 资源。例如，正如一个节点拥有一定数量的内存和 CPU 资源，
+它们被节点上运行的所有组件共享，该节点也可以拥有一定数量的 dongle 资源，
+这些资源同样被节点上运行的所有组件共享。
+此外，正如应用开发者可以创建请求一定数量的内存和 CPU 资源的 Pod，
+他们也可以创建请求一定数量 dongle 资源的 Pod。
+
+<!--
Extended resources are opaque to Kubernetes; Kubernetes does not
know anything about what they are. Kubernetes knows only that a Node
has a certain number of them. Extended resources must be advertised in integer
amounts. For example, a Node can advertise four dongles, but not 4.5 dongles.
-->
-## 讨论
-
-扩展资源类似于内存和 CPU 资源。 例如，正如一个节点拥有一定数量的内存和 CPU 资源， 它们被节点上运行的所有组件共享，该节点也可以拥有一定数量的 dongle 资源， 这些资源同样被节点上运行的所有组件共享。 此外，正如应用开发者可以创建请求一定数量的内存和 CPU 资源的 Pod， 他们也可以创建请求一定数量 dongle 资源的 Pod。
-
-扩展资源对 Kubernetes 是不透明的。 Kubernetes 不知道扩展资源含义相关的任何信息。 Kubernetes 只了解一个节点拥有一定数量的扩展资源。 扩展资源必须以整形数量进行发布。 例如，一个节点可以发布 4 个 dongle 资源，但是不能发布 4.5 个。
+扩展资源对 Kubernetes 是不透明的。Kubernetes 不知道扩展资源含义相关的任何信息。
+Kubernetes 只了解一个节点拥有一定数量的扩展资源。
+扩展资源必须以整形数量进行发布。
+例如，一个节点可以发布 4 个 dongle 资源，但是不能发布 4.5 个。
<!--
### Storage example
@@ -222,28 +181,13 @@ create a name for the special storage, say example.com/special-storage.
Then you could advertise it in chunks of a certain size, say 100 GiB. In that case,
your Node would advertise that it has eight resources of type
example.com/special-storage.
-
-```yaml
-Capacity:
- ...
- example.com/special-storage: 8
-```
-
-If you want to allow arbitrary requests for special storage, you
-could advertise special storage in chunks of size 1 byte. In that case, you would advertise
-800Gi resources of type example.com/special-storage.
-
-```yaml
-Capacity:
- ...
- example.com/special-storage: 800Gi
-```
-
-Then a Container could request any number of bytes of special storage, up to 800Gi.
-->
### 存储示例
-假设一个节点拥有一种特殊类型的磁盘存储，其容量为 800 GiB。 您可以为该特殊存储创建一个名称， 如 example.com/special-storage。 然后您就可以按照一定规格的块（如 100 GiB）对其进行发布。 在这种情况下，您的节点将会通知它拥有八个 example.com/special-storage 类型的资源。
+假设一个节点拥有一种特殊类型的磁盘存储，其容量为 800 GiB。
+你可以为该特殊存储创建一个名称，如 `example.com/special-storage`。
+然后你就可以按照一定规格的块（如 100 GiB）对其进行发布。
+在这种情况下，你的节点将会通知它拥有八个 `example.com/special-storage` 类型的资源。
```yaml
Capacity:
@@ -251,7 +195,13 @@ Capacity:
example.com/special-storage: 8
```
-如果您想要允许针对特殊存储任意（数量）的请求，您可以按照 1 byte 大小的块来发布特殊存储。 在这种情况下，您将会发布 800Gi 数量的 example.com/special-storage 类型的资源。
+<!--
+If you want to allow arbitrary requests for special storage, you
+could advertise special storage in chunks of size 1 byte. In that case, you would advertise
+800Gi resources of type example.com/special-storage.
+-->
+如果你想要允许针对特殊存储任意（数量）的请求，你可以按照 1 字节大小的块来发布特殊存储。
+在这种情况下，你将会发布 800Gi 数量的 example.com/special-storage 类型的资源。
```yaml
Capacity:
@@ -259,50 +209,21 @@ Capacity:
example.com/special-storage: 800Gi
```
+<!--
+Then a Container could request any number of bytes of special storage, up to 800Gi.
+-->
然后，容器就能够请求任意数量（多达 800Gi）字节的特殊存储。
+```yaml
+Capacity:
+ ...
+ example.com/special-storage: 800Gi
+```
+
<!--
## Clean up
Here is a PATCH request that removes the dongle advertisement from a Node.
-
-```
-PATCH /api/v1/nodes/<your-node-name>/status HTTP/1.1
-Accept: application/json
-Content-Type: application/json-patch+json
-Host: k8s-master:8080
-
-[
- {
- "op": "remove",
- "path": "/status/capacity/example.com~1dongle",
- }
-]
-```
-
-Start a proxy, so that you can easily send requests to the Kubernetes API server:
-
-```shell
-kubectl proxy
-```
-
-In another command window, send the HTTP PATCH request.
-Replace `<your-node-name>` with the name of your Node:
-
-```shell
-curl --header "Content-Type: application/json-patch+json" \
---request PATCH \
---data '[{"op": "remove", "path": "/status/capacity/example.com~1dongle"}]' \
-http://localhost:8001/api/v1/nodes/<your-node-name>/status
-```
-
-Verify that the dongle advertisement has been removed:
-
-```
-kubectl describe node <your-node-name> | grep dongle
-```
-
-(you should not see any output)
-->
## 清理
@@ -322,13 +243,20 @@ Host: k8s-master:8080
]
```
-启动一个代理，以便您可以很容易地向 Kubernetes API server 发送请求：
+<!--
+Start a proxy, so that you can easily send requests to the Kubernetes API server:
+-->
+启动一个代理，以便你可以很容易地向 Kubernetes API 服务器发送请求：
```shell
kubectl proxy
```
-在另一个命令窗口中，发送 HTTP PATCH 请求。 用您的节点名称替换 `<your-node-name>`：
+<!--
+In another command window, send the HTTP PATCH request.
+Replace `<your-node-name>` with the name of your Node:
+-->
+在另一个命令窗口中，发送 HTTP PATCH 请求。用你的节点名称替换 `<your-node-name>`：
```shell
curl --header "Content-Type: application/json-patch+json" \
@@ -337,20 +265,23 @@ curl --header "Content-Type: application/json-patch+json" \
http://localhost:8001/api/v1/nodes/<your-node-name>/status
```
+<!--
+Verify that the dongle advertisement has been removed:
+-->
验证 dongle 资源的发布已经被移除：
```
kubectl describe node <your-node-name> | grep dongle
```
-
+<!--
+(you should not see any output)
+-->
+(你应该看不到任何输出)
## {{% heading "whatsnext" %}}
-
-(你不应该看到任何输出)
-
<!--
### For application developers
@@ -363,11 +294,10 @@ kubectl describe node <your-node-name> | grep dongle
-->
### 针对应用开发人员
-* [将扩展资源分配给容器](/docs/tasks/configure-pod-container/extended-resource/)
+* [将扩展资源分配给容器](/zh/docs/tasks/configure-pod-container/extended-resource/)
### 针对集群管理员
-* [为 Namespace 配置最小和最大内存约束](/docs/tasks/administer-cluster/memory-constraint-namespace/)
-* [为 Namespace 配置最小和最大 CPU 约束](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
-
+* [为名字空间配置最小和最大内存约束](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
+* [为名字空间配置最小和最大 CPU 约束](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
diff --git a/content/zh/docs/tasks/administer-cluster/ip-masq-agent.md b/content/zh/docs/tasks/administer-cluster/ip-masq-agent.md
index 5200659a66..e6c126ea1e 100644
--- a/content/zh/docs/tasks/administer-cluster/ip-masq-agent.md
+++ b/content/zh/docs/tasks/administer-cluster/ip-masq-agent.md
@@ -3,10 +3,8 @@ title: IP Masquerade Agent 用户指南
content_type: task
---
<!--
----
title: IP Masquerade Agent User Guide
content_type: task
----
-->
<!-- overview -->
@@ -15,14 +13,10 @@ This page shows how to configure and enable the ip-masq-agent.
-->
此页面展示如何配置和启用 ip-masq-agent。
-
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
<!-- discussion -->
<!--
## IP Masquerade Agent User Guide
@@ -37,7 +31,7 @@ ip-masq-agent 配置 iptables 规则以隐藏位于集群节点 IP 地址后面
<!--
### **Key Terms**
-->
-### **关键词**
+### **关键术语**
<!--
* **NAT (Network Address Translation)**
@@ -70,7 +64,17 @@ ip-masq-agent 配置 iptables 规则以隐藏位于集群节点 IP 地址后面
<!--
The ip-masq-agent configures iptables rules to handle masquerading node/pod IP addresses when sending traffic to destinations outside the cluster node's IP and the Cluster IP range. This essentially hides pod IP addresses behind the cluster node's IP address. In some environments, traffic to "external" addresses must come from a known machine address. For example, in Google Cloud, any traffic to the internet must come from a VM's IP. When containers are used, as in Google Kubernetes Engine, the Pod IP will be rejected for egress. To avoid this, we must hide the Pod IP behind the VM's own IP address - generally known as "masquerade". By default, the agent is configured to treat the three private IP ranges specified by [RFC 1918](https://tools.ietf.org/html/rfc1918) as non-masquerade [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing). These ranges are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. The agent will also treat link-local (169.254.0.0/16) as a non-masquerade CIDR by default. The agent is configured to reload its configuration from the location */etc/config/ip-masq-agent* every 60 seconds, which is also configurable.
-->
-ip-masq-agent 配置 iptables 规则，以便在将流量发送到集群节点的IP和集群IP范围之外的目标时处理伪装节点/pod 的 IP 地址。这基本上隐藏了集群节点 IP 地址后面的pod IP地址。在某些环境中，去往“外部”地址的流量必须从已知的机器地址发出。例如，在 Google Cloud 中，任何到互联网的流量都必须来自 VM 的 IP。使用容器时，如 Google Kubernetes Engine，从Pod IP 发出的流量将被拒绝出出站。为了避免这种情况，我们必须将 Pod IP 隐藏在 VM 自己的IP地址后面 - 通常称为“伪装”。默认情况下，代理配置为将[RFC 1918](https://tools.ietf.org/html/rfc1918)指定的三个私有IP范围视为非伪装[CIDR](https://zh.wikipedia.org/wiki/%E6%97%A0%E7%B1%BB%E5%88%AB%E5%9F%9F%E9%97%B4%E8%B7%AF%E7%94%B1)。这些范围是 10.0.0.0/8,172.16.0.0/12 和 192.168.0.0/16。默认情况下，代理还将链路本地地址(169.254.0.0/16)视为非伪装 CIDR。代理程序配置为每隔60秒从*/etc/config/ip-masq-agent*重新加载其配置，这也是可修改的。
+ip-masq-agent 配置 iptables 规则，以便在将流量发送到集群节点的 IP 和集群 IP 范围之外的目标时
+处理伪装节点/Pod 的 IP 地址。这基本上隐藏了集群节点 IP 地址后面的 Pod IP 地址。
+在某些环境中，去往“外部”地址的流量必须从已知的机器地址发出。
+例如，在 Google Cloud 中，任何到互联网的流量都必须来自 VM 的 IP。
+使用容器时，如 Google Kubernetes Engine，从 Pod IP 发出的流量将被拒绝出站。
+为了避免这种情况，我们必须将 Pod IP 隐藏在 VM 自己的 IP 地址后面 - 通常称为“伪装”。
+默认情况下，代理配置为将[RFC 1918](https://tools.ietf.org/html/rfc1918)指定的三个私有
+IP 范围视为非伪装 [CIDR](https://zh.wikipedia.org/wiki/%E6%97%A0%E7%B1%BB%E5%88%AB%E5%9F%9F%E9%97%B4%E8%B7%AF%E7%94%B1)。
+这些范围是 10.0.0.0/8,172.16.0.0/12 和 192.168.0.0/16。
+默认情况下，代理还将链路本地地址（169.254.0.0/16）视为非伪装 CIDR。
+代理程序配置为每隔 60 秒从 */etc/config/ip-masq-agent* 重新加载其配置，这也是可修改的。
@@ -87,7 +91,7 @@ The agent configuration file must be written in YAML or JSON syntax, and may con
<!--
* **masqLinkLocal:** A Boolean (true / false) which indicates whether to masquerade traffic to the link local prefix 169.254.0.0/16. False by default.
-->
-* **masqLinkLocal:** 布尔值 (true / false)，表示是否将流量伪装到本地链路前缀169.254.0.0/16。 默认为 false。
+* **masqLinkLocal:** 布尔值 (true / false)，表示是否将流量伪装到本地链路前缀 169.254.0.0/16。默认为 false。
<!--
* **resyncInterval:** An interval at which the agent attempts to reload config from disk. e.g. '30s' where 's' is seconds, 'ms' is milliseconds etc...
@@ -97,7 +101,10 @@ The agent configuration file must be written in YAML or JSON syntax, and may con
<!--
Traffic to 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16) ranges will NOT be masqueraded. Any other traffic (assumed to be internet) will be masqueraded. An example of a local destination from a pod could be its Node's IP address as well as another node's address or one of the IP addresses in Cluster's IP range. Any other traffic will be masqueraded by default. The below entries show the default set of rules that are applied by the ip-masq-agent:
-->
-10.0.0.0/8,172.16.0.0/12和192.168.0.0/16）范围内的流量不会被伪装。任何其他流量（假设是互联网）将被伪装。pod 访问本地目的地的例子，可以是其节点的 IP 地址、另一节点的地址或集群的 IP 地址范围内的一个 IP 地址。默认情况下，任何其他流量都将伪装。以下条目展示了 ip-masq-agent 的默认使用的规则：
+10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16 范围内的流量不会被伪装。
+任何其他流量（假设是互联网）将被伪装。
+Pod 访问本地目的地的例子，可以是其节点的 IP 地址、另一节点的地址或集群的 IP 地址范围内的一个 IP 地址。
+默认情况下，任何其他流量都将伪装。以下条目展示了 ip-masq-agent 的默认使用的规则：
<!--
```
@@ -123,9 +130,11 @@ MASQUERADE all -- anywhere anywhere /* ip-masq-agent:
<!--
By default, in GCE/Google Kubernetes Engine starting with Kubernetes version 1.7.0, if network policy is enabled or you are using a cluster CIDR not in the 10.0.0.0/8 range, the ip-masq-agent will run in your cluster. If you are running in another environment, you can add the ip-masq-agent [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) to your cluster:
-->
-默认情况下，从 Kubernetes 1.7.0 版本开始的 GCE/Google Kubernetes Engine 中，如果启用了网络策略，或者您使用的集群 CIDR 不在 10.0.0.0/8 范围内，则 ip-masq-agent 将在您的集群中运行。如果您在其他环境中运行，则可以将 ip-masq-agent [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) 添加到您的集群：
-
-
+默认情况下，从 Kubernetes 1.7.0 版本开始的 GCE/Google Kubernetes Engine 中，
+如果启用了网络策略，或者你使用的集群 CIDR 不在 10.0.0.0/8 范围内，
+则 ip-masq-agent 将在你的集群中运行。
+如果你在其他环境中运行，则可以将 ip-masq-agent
+[DaemonSet](/zh/docs/concepts/workloads/controllers/daemonset/) 添加到你的集群：
<!-- steps -->
@@ -143,7 +152,7 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes-incubator/ip-masq-
<!--
You must also apply the appropriate node label to any nodes in your cluster that you want the agent to run on.
-->
-您必须同时将适当的节点标签应用于集群中希望代理运行的任何节点。
+你必须同时将适当的节点标签应用于集群中希望代理运行的任何节点。
`
kubectl label nodes my-node beta.kubernetes.io/masq-agent-ds-ready=true
@@ -157,7 +166,11 @@ More information can be found in the ip-masq-agent documentation [here](https://
<!--
In most cases, the default set of rules should be sufficient; however, if this is not the case for your cluster, you can create and apply a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to customize the IP ranges that are affected. For example, to allow only 10.0.0.0/8 to be considered by the ip-masq-agent, you can create the following [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) in a file called "config".
-->
-在大多数情况下，默认的规则集应该足够；但是，如果您的群集不是这种情况，则可以创建并应用 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) 来自定义受影响的 IP 范围。 例如，要允许 ip-masq-agent 仅作用于 10.0.0.0/8，您可以一个名为 “config” 的文件中创建以下 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) 。
+在大多数情况下，默认的规则集应该足够；但是，如果你的群集不是这种情况，则可以创建并应用
+[ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)
+来自定义受影响的 IP 范围。
+例如，要允许 ip-masq-agent 仅作用于 10.0.0.0/8，你可以一个名为 “config” 的文件中创建以下
+[ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) 。
{{< note >}}
<!--
@@ -175,7 +188,7 @@ resyncInterval: 60s
<!--
Run the following command to add the config map to your cluster:
-->
-运行以下命令将配置映射添加到您的集群：
+运行以下命令将配置映射添加到你的集群：
```
kubectl create configmap ip-masq-agent --from-file=config --namespace=kube-system
@@ -185,8 +198,9 @@ kubectl create configmap ip-masq-agent --from-file=config --namespace=kube-syste
This will update a file located at */etc/config/ip-masq-agent* which is periodically checked every *resyncInterval* and applied to the cluster node.
After the resync interval has expired, you should see the iptables rules reflect your changes:
-->
-这将更新位于 */etc/config/ip-masq-agent* 的一个文件，该文件以 *resyncInterval* 为周期定期检查并应用于集群节点。
-重新同步间隔到期后，您应该看到您的更改在 iptables 规则中体现：
+这将更新位于 */etc/config/ip-masq-agent* 的一个文件，该文件以 *resyncInterval*
+为周期定期检查并应用于集群节点。
+重新同步间隔到期后，你应该看到你的更改在 iptables 规则中体现：
<!--
```
diff --git a/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
index b005e3e343..e01404b95d 100644
--- a/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
+++ b/content/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
@@ -1,25 +1,26 @@
---
-reviewers:
-- sig-cluster-lifecycle
title: 升级 kubeadm 集群
content_type: task
+weight: 20
+min-kubernetes-server-version: 1.18
---
<!--
----
reviewers:
- sig-cluster-lifecycle
title: Upgrading kubeadm clusters
content_type: task
----
+weight: 20
+min-kubernetes-server-version: 1.18
-->
<!-- overview -->
<!--
This page explains how to upgrade a Kubernetes cluster created with kubeadm from version
-1.16.x to version 1.17.x, and from version 1.17.x to 1.17.y (where `y > x`).
+1.17.x to version 1.18.x, and from version 1.18.x to 1.18.y (where `y > x`).
-->
-本页介绍了如何将 `kubeadm` 创建的 Kubernetes 集群从 1.16.x 版本升级到 1.17.x 版本，以及从版本 1.17.x 升级到 1.17.y ，其中 `y > x`。
+本页介绍如何将 `kubeadm` 创建的 Kubernetes 集群从 1.17.x 版本升级到 1.18.x 版本，
+或者从版本 1.18.x 升级到 1.18.y ，其中 `y > x`。
<!--
To see information about upgrading clusters created using older versions of kubeadm,
@@ -47,79 +48,68 @@ The upgrade workflow at high level is the following:
-->
升级工作的基本流程如下：
-1. 升级主控制平面节点。
-1. 升级其他控制平面节点。
-1. 升级工作节点。
+1. 升级主控制平面节点
+1. 升级其他控制平面节点
+1. 升级工作节点
## {{% heading "prerequisites" %}}
<!--
-- You need to have a kubeadm Kubernetes cluster running version 1.16.0 or later.
+- You need to have a kubeadm Kubernetes cluster running version 1.17.0 or later.
- [Swap must be disabled](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux).
- The cluster should use a static control plane and etcd pods or external etcd.
- Make sure you read the [release notes]({{< latest-release-notes >}}) carefully.
- Make sure to back up any important components, such as app-level state stored in a database.
`kubeadm upgrade` does not touch your workloads, only components internal to Kubernetes, but backups are always a best practice.
-->
-- 您需要有一个由 `kubeadm` 创建并运行着 1.16.0 或更高版本的 Kubernetes 集群。
-- [禁用 Swap](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux)。
-- 集群应使用静态的控制平面和 etcd pod 或者 外部 etcd。
+- 你需要有一个由 `kubeadm` 创建并运行着 1.17.0 或更高版本的 Kubernetes 集群。
+- [禁用交换分区](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux)。
+- 集群应使用静态的控制平面和 etcd Pod 或者 外部 etcd。
- 务必仔细认真阅读[发行说明]({{< latest-release-notes >}})。
- 务必备份所有重要组件，例如存储在数据库中应用层面的状态。
- `kubeadm upgrade` 不会影响您的工作负载，只会涉及 Kubernetes 内部的组件，但备份终究是好的。
+ `kubeadm upgrade` 不会影响你的工作负载，只会涉及 Kubernetes 内部的组件，但备份终究是好的。
<!--
### Additional information
--->
-### 附加信息
-<!--
- All containers are restarted after upgrade, because the container spec hash value is changed.
- You only can upgrade from one MINOR version to the next MINOR version,
or between PATCH versions of the same MINOR. That is, you cannot skip MINOR versions when you upgrade.
For example, you can upgrade from 1.y to 1.y+1, but not from 1.y to 1.y+2.
-->
-- 升级后，因为容器 spec 哈希值已更改，所以所有容器都会重新启动。
-- 您只能从一个次版本升级到下一个次版本，或者同样次版本的补丁版。也就是说，升级时无法跳过版本。
- 例如，您只能从 1.y 升级到 1.y+1，而不能从 from 1.y 升级到 1.y+2。
+### 附加信息
+
+- 升级后，因为容器规约的哈希值已更改，所有容器都会被重新启动。
+- 你只能从一个次版本升级到下一个次版本，或者在次版本相同时升级补丁版本。
+ 也就是说，升级时不可以跳过次版本。
+ 例如，你只能从 1.y 升级到 1.y+1，而不能从 from 1.y 升级到 1.y+2。
<!-- steps -->
<!--
## Determine which version to upgrade to
+
+Find the latest stable 1.18 version:
-->
## 确定要升级到哪个版本
-<!--
-Find the latest stable 1.18 version:
-
-{{< tabs name="k8s_install_versions" >}}
-{{% tab name="Ubuntu, Debian or HypriotOS" %}}
- apt update
- apt-cache policy kubeadm
- # find the latest 1.18 version in the list
- # it should look like 1.18.x-00, where x is the latest patch
-{{% /tab %}}
-{{% tab name="CentOS, RHEL or Fedora" %}}
- yum list --showduplicates kubeadm --disableexcludes=kubernetes
- # find the latest 1.18 version in the list
- # it should look like 1.18.x-0, where x is the latest patch
-{{% /tab %}}
-{{< /tabs >}}
--->
找到最新的稳定版 1.18：
{{< tabs name="k8s_install_versions" >}}
-{{% tab name="Ubuntu, Debian or HypriotOS" %}}
- apt update
- apt-cache policy kubeadm
- # 在列表中查找最新的 1.18 版本
- # 它看起来应该是 1.18.x-00 ，其中 x 是最新的补丁
+{{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
+```
+apt update
+apt-cache policy kubeadm
+# 在列表中查找最新的 1.18 版本
+# 它看起来应该是 1.18.x-00 ，其中 x 是最新的补丁
+```
{{% /tab %}}
-{{% tab name="CentOS, RHEL or Fedora" %}}
- yum list --showduplicates kubeadm --disableexcludes=kubernetes
- # 在列表中查找最新的 1.18 版本
- # 它看起来应该是 1.18.x-0 ，其中 x 是最新的补丁版本
+{{% tab name="CentOS、RHEL 或 Fedora" %}}
+```
+yum list --showduplicates kubeadm --disableexcludes=kubernetes
+# 在列表中查找最新的 1.18 版本
+# 它看起来应该是 1.18.x-0 ，其中 x 是最新的补丁版本
+```
{{% /tab %}}
{{< /tabs >}}
@@ -134,32 +124,23 @@ Find the latest stable 1.18 version:
<!--
- On your first control plane node, upgrade kubeadm:
-
-{{< tabs name="k8s_install_kubeadm_first_cp" >}}
-{{% tab name="Ubuntu, Debian or HypriotOS" %}}
- # replace x in 1.18.x-00 with the latest patch version
- apt-mark unhold kubeadm && \
- apt-get update && apt-get install -y kubeadm=1.18.x-00 && \
- apt-mark hold kubeadm
-{{% /tab %}}
-{{% tab name="CentOS, RHEL or Fedora" %}}
- # replace x in 1.18.x-0 with the latest patch version
- yum install -y kubeadm-1.18.x-0 -disableexcludes=kubernetes
-{{% /tab %}}
-{{< /tabs >}}
-->
- 在第一个控制平面节点上，升级 kubeadm :
{{< tabs name="k8s_install_kubeadm_first_cp" >}}
-{{% tab name="Ubuntu, Debian or HypriotOS" %}}
- # 用最新的修补程序版本替换 1.18.x-00 中的 x
- apt-mark unhold kubeadm && \
- apt-get update && apt-get install -y kubeadm=1.18.x-00 && \
- apt-mark hold kubeadm
+{{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
+```shell
+# 用最新的修补程序版本替换 1.18.x-00 中的 x
+apt-mark unhold kubeadm && \
+apt-get update && apt-get install -y kubeadm=1.18.x-00 && \
+apt-mark hold kubeadm
+```
{{% /tab %}}
-{{% tab name="CentOS, RHEL or Fedora" %}}
- # 用最新的修补程序版本替换 1.18.x-0 中的 x
- yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes
+{{% tab name="CentOS、RHEL 或 Fedora" %}}
+```shell
+# 用最新的修补程序版本替换 1.18.x-0 中的 x
+yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes
+```
{{% /tab %}}
{{< /tabs >}}
@@ -202,7 +183,7 @@ Find the latest stable 1.18 version:
<!--
You should see output similar to this:
-->
- 您应该可以看到与下面类似的输出：
+ 你应该可以看到与下面类似的输出：
```none
[upgrade/config] Making sure the configuration is correct:
@@ -240,18 +221,17 @@ Find the latest stable 1.18 version:
<!--
This command checks that your cluster can be upgraded, and fetches the versions you can upgrade to.
-->
- 此命令检查您的集群是否可以升级，并可以获取到升级的版本。
+ 此命令检查你的集群是否可以升级，并可以获取到升级的版本。
<!--
`kubeadm upgrade` also automatically renews the certificates that it manages on this node.
To opt-out of certificate renewal the flag `-certificate-renewal=false` can be used.
For more information see the [certificate management guide](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs).
-->
-
{{< note >}}
`kubeadm upgrade` 也会自动对它在此节点上管理的证书进行续约。
如果选择不对证书进行续约，可以使用标志 `--certificate-renewal=false`。
-关于更多细节信息，可参见[证书管理指南](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)。
+关于更多细节信息，可参见[证书管理指南](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)。
{{</ note >}}
<!--
@@ -272,7 +252,7 @@ For more information see the [certificate management guide](/docs/tasks/administ
<!--
You should see output similar to this:
-->
- 您应该可以看见与下面类似的输出：
+ 你应该可以看见与下面类似的输出：
```none
[upgrade/config] Making sure the configuration is correct:
@@ -364,8 +344,9 @@ For more information see the [certificate management guide](/docs/tasks/administ
-->
- 手动升级你的 CNI 驱动插件。
- 您的容器网络接口（CNI）驱动应该提供了程序自身的升级说明。
- 检查[插件](/docs/concepts/cluster-administration/addons/)页面查找您 CNI 所提供的程序，并查看是否需要其他升级步骤。
+ 你的容器网络接口（CNI）驱动应该提供了程序自身的升级说明。
+ 参阅[插件](/zh/docs/concepts/cluster-administration/addons/)页面查找你 CNI 所提供的程序，
+ 并查看是否需要其他升级步骤。
如果 CNI 提供程序作为 DaemonSet 运行，则在其他控制平面节点上不需要此步骤。
@@ -414,18 +395,27 @@ sudo kubeadm upgrade apply
{{< tabs name="k8s_install_kubelet" >}}
{{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
- # 用最新的补丁版本替换 1.18.x-00 中的 x
- apt-mark unhold kubelet kubectl && \
- apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \
- apt-mark hold kubelet kubectl
- -
- # 从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：
- apt-get update && \
- apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00
+```shell
+# 用最新的补丁版本替换 1.18.x-00 中的 x
+apt-mark unhold kubelet kubectl && \
+apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \
+apt-mark hold kubelet kubectl
+```
+
+从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：
+
+```shell
+apt-get update && \
+apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00
+```
{{% /tab %}}
{{% tab name="CentOS、RHEL 或 Fedora" %}}
- # 用最新的补丁版本替换 1.18.x-00 中的 x
- yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes
+
+用最新的补丁版本替换 1.18.x-00 中的 x
+
+```shell
+yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes
+```
{{% /tab %}}
{{< /tabs >}}
@@ -456,36 +446,33 @@ without compromising the minimum required capacity for running your workloads.
<!--
- Upgrade kubeadm on all worker nodes:
-
-{{< tabs name="k8s_install_kubeadm_worker_nodes" >}}
-{{% tab name="Ubuntu, Debian or HypriotOS" %}}
- # replace x in 1.18.x-00 with the latest patch version
- apt-mark unhold kubeadm && \
- apt-get update && apt-get install -y kubeadm=1.18.x-00 && \
- apt-mark hold kubeadm
-{{% /tab %}}
-{{% tab name="CentOS, RHEL or Fedora" %}}
- # replace x in 1.18.x-0 with the latest patch version
- yum install -y kubeadm-1.18.x-0 -disableexcludes=kubernetes
-{{% /tab %}}
-{{< /tabs >}}
-->
- 在所有工作节点升级 kubeadm:
{{< tabs name="k8s_install_kubeadm_worker_nodes" >}}
{{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
- # 将 1.18.x-00 中的 x 替换为最新的补丁版本
- apt-mark unhold kubeadm && \
- apt-get update && apt-get install -y kubeadm=1.18.x-00 && \
- apt-mark hold kubeadm
- -
- # 从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：
- apt-get update && \
- apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00
+
+```shell
+# 将 1.18.x-00 中的 x 替换为最新的补丁版本
+apt-mark unhold kubeadm && \
+apt-get update && apt-get install -y kubeadm=1.18.x-00 && \
+apt-mark hold kubeadm
+```
+
+从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：
+
+```shell
+apt-get update && \
+apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00
+```
+
{{% /tab %}}
{{% tab name="CentOS、RHEL 或 Fedora" %}}
- # 用最新的补丁版本替换 1.18.x-00 中的 x
- yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes
+
+```shell
+# 用最新的补丁版本替换 1.18.x-00 中的 x
+yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes
+```
{{% /tab %}}
{{< /tabs >}}
@@ -557,18 +544,29 @@ without compromising the minimum required capacity for running your workloads.
{{< tabs name="k8s_kubelet_and_kubectl" >}}
{{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
- # 将 1.18.x-00 中的 x 替换为最新的补丁版本
- apt-mark unhold kubelet kubectl && \
- apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \
- apt-mark hold kubelet kubectl
- -
- # 从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：
- apt-get update && \
- apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00
+
+```shell
+# 将 1.18.x-00 中的 x 替换为最新的补丁版本
+apt-mark unhold kubelet kubectl && \
+apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \
+apt-mark hold kubelet kubectl
+```
+
+从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：
+
+```
+apt-get update && \
+apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00
+```
+
{{% /tab %}}
{{% tab name="CentOS, RHEL or Fedora" %}}
- # 将 1.18.x-00 中的 x 替换为最新的补丁版本
- yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes
+
+```shell
+# 将 1.18.x-00 中的 x 替换为最新的补丁版本
+yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes
+```
+
{{% /tab %}}
{{< /tabs >}}
@@ -601,10 +599,10 @@ without compromising the minimum required capacity for running your workloads.
-->
- 通过将节点标记为可调度，让节点重新上线:
- ```shell
- # 将 <node-to-drain> 替换为当前节点的名称
- kubectl uncordon <node-to-drain>
- ```
+ ```shell
+ # 将 <node-to-drain> 替换为当前节点的名称
+ kubectl uncordon <node-to-drain>
+ ```
<!--
## Verify the status of the cluster
@@ -638,9 +636,9 @@ To recover from a bad state, you can also run `kubeadm upgrade --force` without
-->
## 从故障状态恢复
-如果 `kubeadm upgrade` 失败并且没有回滚，例如由于执行期间意外关闭，您可以再次运行 `kubeadm upgrade`。
-此命令是幂等的，并最终确保实际状态是您声明的所需状态。
-要从故障状态恢复，您还可以运行 `kubeadm upgrade --force` 而不去更改集群正在运行的版本。
+如果 `kubeadm upgrade` 失败并且没有回滚，例如由于执行期间意外关闭，你可以再次运行 `kubeadm upgrade`。
+此命令是幂等的，并最终确保实际状态是你声明的所需状态。
+要从故障状态恢复，你还可以运行 `kubeadm upgrade --force` 而不去更改集群正在运行的版本。
<!--
During upgrade kubeadm writes the following backup folders under `/etc/kubernetes/tmp`:
@@ -690,7 +688,7 @@ and post-upgrade manifest file for a certain component, a backup file for it wil
`kubeadm upgrade apply` 做了以下工作：
-- 检查您的集群是否处于可升级状态:
+- 检查你的集群是否处于可升级状态:
- API 服务器是可访问的
- 所有节点处于 `Ready` 状态
- 控制面是健康的
diff --git a/content/zh/docs/tasks/administer-cluster/kubelet-config-file.md b/content/zh/docs/tasks/administer-cluster/kubelet-config-file.md
index 677bb4426c..e41eb9e3d9 100644
--- a/content/zh/docs/tasks/administer-cluster/kubelet-config-file.md
+++ b/content/zh/docs/tasks/administer-cluster/kubelet-config-file.md
@@ -1,29 +1,26 @@
---
-reviewers:
-- mtaufen
-- dawnchen
title: 通过配置文件设置 Kubelet 参数
content_type: task
---
<!--
----
reviewers:
- mtaufen
- dawnchen
title: Set Kubelet parameters via a config file
content_type: task
----
--->
<!-- overview -->
-{{< feature-state state="beta" >}}
+
+{{< feature-state for_k8s_version="v1.10" state="beta" >}}
<!--
A subset of the Kubelet's configuration parameters may be
set via an on-disk config file, as a substitute for command-line flags.
This functionality is considered beta in v1.10.
--->
-通过保存在硬盘的配置文件设置 Kubelet 的配置参数子集，可以作为命令行参数的替代。此功能在 v1.10 中为 beta 版。
+通过保存在硬盘的配置文件设置 kubelet 的部分配置参数，这可以作为命令行参数的替代。
+此功能在 v1.10 中为 beta 版。
<!--
Providing parameters via a config file is the recommended approach because
@@ -31,65 +28,86 @@ it simplifies node deployment and configuration management.
--->
建议通过配置文件的方式提供参数，因为这样可以简化节点部署和配置管理。
-
-
## {{% heading "prerequisites" %}}
-
<!--
- A v1.10 or higher Kubelet binary must be installed for beta functionality.
---->
-- 需要安装 1.10 或更高版本的 Kubelet 二进制文件，才能实现 beta 功能。
-
-
+-->
+- 需要安装 1.10 或更高版本的 kubelet 可执行文件，才能使用此 beta 功能。
<!-- steps -->
<!--
## Create the config file
---->
+
+The subset of the Kubelet's configuration that can be configured via a file
+is defined by the `KubeletConfiguration` struct
+[here (v1beta1)](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go).
+-->
## 创建配置文件
+`KubeletConfiguration` 结构体定义了可以通过文件配置的 Kubelet 配置子集，
+该结构体在 [这里（v1beta1）](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)
+可以找到。
-`KubeletConfiguration` 结构体定义了可以通过文件配置的 Kubelet 配置子集，该结构体在 [这里（v1beta1）](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go) 可以找到, 配置文件必须是这个结构体中参数的 JSON 或 YAML 表现形式。
+<!--
+The configuration file must be a JSON or YAML representation of the parameters
+in this struct. Make sure the Kubelet has read permissions on the file.
+Here is an example of what this file might look like:
+-->
+配置文件必须是这个结构体中参数的 JSON 或 YAML 表现形式。
+确保 kubelet 可以读取该文件。
-在单独的文件夹中创建一个名为 `kubelet` 的文件，并保证 Kubelet 可以读取该文件夹及文件。您应该在这个 `kubelet` 文件中编写 Kubelet 配置。
+下面是一个 Kubelet 配置文件示例：
-这是一个 Kubelet 配置文件示例：
-
-```
+```yaml
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
evictionHard:
memory.available: "200Mi"
```
-在这个示例中, 当可用内存低于200Mi 时, Kubelet 将会开始驱逐 Pods。 没有声明的其余配置项都将使用默认值, 命令行中的 flags 将会覆盖配置文件中的对应值。
-
-
-作为一个小技巧，您可以从活动节点生成配置文件，相关方法请查看 [重新配置活动集群节点的 Kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet)。
-
-
-## 启动通过配置文件配置的 Kubelet 进程
<!--
+In the example, the Kubelet is configured to evict Pods when available memory drops below 200Mi.
+All other Kubelet configuration values are left at their built-in defaults, unless overridden
+by flags. Command line flags which target the same value as a config file will override that value.
+
+For a trick to generate a configuration file from a live node, see
+[Reconfigure a Node's Kubelet in a Live Cluster](/docs/tasks/administer-cluster/reconfigure-kubelet).
+-->
+在这个示例中, 当可用内存低于 200Mi 时, kubelet 将会开始驱逐 Pods。
+没有声明的其余配置项都将使用默认值，除非使用命令行参数来重载。
+命令行中的参数将会覆盖配置文件中的对应值。
+
+作为一个小技巧，你可以从活动节点生成配置文件，相关方法请查看
+[重新配置活动集群节点的 kubelet](/zh/docs/tasks/administer-cluster/reconfigure-kubelet)。
+
+<!--
+## Start a Kubelet process configured via the config file
+
Start the Kubelet with the `--config` flag set to the path of the Kubelet's config file.
The Kubelet will then load its config from this file.
--->
+
+## 启动通过配置文件配置的 Kubelet 进程
+
启动 Kubelet 需要将 `--config` 参数设置为 Kubelet 配置文件的路径。Kubelet 将从此文件加载其配置。
<!--
Note that command line flags which target the same value as a config file will override that value.
This helps ensure backwards compatibility with the command-line API.
---->
-请注意，命令行参数与配置文件有相同的值时，就会覆盖配置文件中的该值。这有助于确保命令行 API 的向后兼容性。
+-->
+请注意，命令行参数与配置文件有相同的值时，就会覆盖配置文件中的该值。
+这有助于确保命令行 API 的向后兼容性。
<!--
Note that relative file paths in the Kubelet config file are resolved relative to the
location of the Kubelet config file, whereas relative paths in command line flags are resolved
relative to the Kubelet's current working directory.
---->
-请注意，Kubelet 配置文件中的相对文件路径是相对于 Kubelet 配置文件的位置解析的，而命令行参数中的相对路径是相对于 Kubelet 的当前工作目录解析的。
+-->
+请注意，kubelet 配置文件中的相对文件路径是相对于 kubelet 配置文件的位置解析的，
+而命令行参数中的相对路径是相对于 kubelet 的当前工作目录解析的。
<!--
Note that some default values differ between command-line flags and the Kubelet config file.
@@ -97,23 +115,23 @@ If `--config` is provided and the values are not specified via the command line,
defaults for the `KubeletConfiguration` version apply.
In the above example, this version is `kubelet.config.k8s.io/v1beta1`.
--->
-请注意，命令行参数和 Kubelet 配置文件的某些默认值不同。如果设置了 `--config`，并且没有通过命令行指定值，则 `KubeletConfiguration` 版本的默认值生效。在上面的例子中，version 是 `kubelet.config.k8s.io/v1beta1`。
-
-
+请注意，命令行参数和 Kubelet 配置文件的某些默认值不同。
+如果设置了 `--config`，并且没有通过命令行指定值，则 `KubeletConfiguration`
+版本的默认值生效。在上面的例子中，version 是 `kubelet.config.k8s.io/v1beta1`。
<!-- discussion -->
<!--
## Relationship to Dynamic Kubelet Config
---->
-## 与动态 Kubelet 配置的关系
-<!--
If you are using the [Dynamic Kubelet Configuration](/docs/tasks/administer-cluster/reconfigure-kubelet)
feature, the combination of configuration provided via `--config` and any flags which override these values
is considered the default "last known good" configuration by the automatic rollback mechanism.
--->
-如果您正在使用 [动态 Kubelet 配置](/docs/tasks/administer-cluster/reconfigure-kubelet) 特性，那么自动回滚机制将认为是 "最后已知正常（last known good）" 的配置，通过 `--config` 提供的配置与覆盖这些值的任何参数的结合。
-
+## 与动态 Kubelet 配置的关系
+
+如果你正在使用[动态 kubelet 配置](/zh/docs/tasks/administer-cluster/reconfigure-kubelet)特性，
+那么自动回滚机制将认为通过 `--config` 提供的配置与覆盖这些值的任何参数的组合是
+ "最后已知正常（last known good）" 的配置。
diff --git a/content/zh/docs/tasks/administer-cluster/limit-storage-consumption.md b/content/zh/docs/tasks/administer-cluster/limit-storage-consumption.md
index 29070a748f..b3969099a1 100644
--- a/content/zh/docs/tasks/administer-cluster/limit-storage-consumption.md
+++ b/content/zh/docs/tasks/administer-cluster/limit-storage-consumption.md
@@ -3,13 +3,10 @@ title: 限制存储消耗
content_type: task
---
<!--
----
title: Limit Storage Consumption
content_type: task
----
-->
-
<!-- overview -->
<!--
@@ -22,17 +19,15 @@ The following resources are used in the demonstration: [ResourceQuota](/docs/con
[LimitRange](/docs/tasks/administer-cluster/memory-default-namespace/),
and [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/).
-->
-演示中用到了以下资源：[ResourceQuota](/docs/concepts/policy/resource-quotas/)，[LimitRange](/docs/tasks/administer-cluster/memory-default-namespace/) 和 [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/)。
-
+演示中用到了以下资源：[ResourceQuota](/zh/docs/concepts/policy/resource-quotas/)，
+[LimitRange](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) 和
+[PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/)。
## {{% heading "prerequisites" %}}
-
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
<!-- steps -->
<!--
@@ -139,6 +134,3 @@ cluster's storage budget without risk of any one project going over their allotm
-->
限制范围对象可以用来设置可请求的存储量上限，而资源配额对象则可以通过申领计数和累计存储容量有效地限制命名空间耗用的存储量。这两种机制使得集群管理员能够规划其集群存储预算而不会发生任一项目超量分配的风险。
-
-
-
diff --git a/content/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md b/content/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md
index de2cb0f12d..25c24ab519 100644
--- a/content/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md
+++ b/content/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md
@@ -1,15 +1,13 @@
---
-title: 为命名空间配置CPU最小和最大限制
+title: 为命名空间配置 CPU 最小和最大约束
content_type: task
weight: 40
---
<!--
----
title: Configure Minimum and Maximum CPU Constraints for a Namespace
content_type: task
weight: 40
----
-->
<!-- overview -->
@@ -21,25 +19,19 @@ and Pods in a namespace. You specify minimum and maximum CPU values in a
object. If a Pod does not meet the constraints imposed by the LimitRange, it cannot be created
in the namespace.
-->
-
-本章介绍命名空间中可以被容器和Pod使用的CPU资源的最小和最大值。你可以通过 [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core) 对象声明 CPU 的最小和最大值. 如果 Pod 不能满足 LimitRange 的限制，它就不能在命名空间中创建。
-
-
-
+本页介绍如何为命名空间中容器和 Pod 使用的 CPU 资源设置最小和最大值。
+你可以通过
+[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
+对象声明 CPU 的最小和最大值. 如果 Pod 不能满足 LimitRange 的限制，它就不能在命名空间中创建。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
-Each node in your cluster must have at least 1 CPU.
+Your cluster must have at least 1 CPU available for use to run the task examples.
-->
-
-你的集群中每个节点至少要有1个CPU。
-
-
-
+你的集群中每个节点至少要有 1 个 CPU 可用才能运行本任务示例。
<!-- steps -->
@@ -49,7 +41,6 @@ Each node in your cluster must have at least 1 CPU.
Create a namespace so that the resources you create in this exercise are
isolated from the rest of your cluster.
-->
-
## 创建命名空间
创建一个命名空间，以便本练习中创建的资源和集群的其余资源相隔离。
@@ -63,7 +54,6 @@ kubectl create namespace constraints-cpu-example
Here's the configuration file for a LimitRange:
-->
-
## 创建 LimitRange 和 Pod
这里给出了 LimitRange 的配置文件：
@@ -73,17 +63,15 @@ Here's the configuration file for a LimitRange:
<!--
Create the LimitRange:
-->
-
创建 LimitRange:
```shell
-kubectl create -f https://k8s.io/examples/admin/resource/cpu-constraints.yaml --namespace=constraints-cpu-example
+kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints.yaml --namespace=constraints-cpu-example
```
<!--
View detailed information about the LimitRange:
-->
-
查看 LimitRange 详情：
```shell
@@ -95,8 +83,8 @@ The output shows the minimum and maximum CPU constraints as expected. But
notice that even though you didn't specify default values in the configuration
file for the LimitRange, they were created automatically.
-->
-
-输出结果显示 CPU 的最小和最大限制符合预期。但需要注意的是，尽管你在 LimitRange 的配置文件中你没有声明默认值，默认值也会被自动创建。
+输出结果显示 CPU 的最小和最大限制符合预期。但需要注意的是，尽管你在 LimitRange
+的配置文件中你没有声明默认值，默认值也会被自动创建。
```yaml
limits:
@@ -127,45 +115,43 @@ CPU request and limit to the Container.
* 如果容器没有声明自己的 CPU 请求和限制，将为容器指定默认 CPU 请求和限制。
-* 核查容器声明的 CPU 请求确保其大于或者等于200 millicpu。
+* 核查容器声明的 CPU 请求确保其大于或者等于 200 millicpu。
-* 核查容器声明的 CPU 限制确保其小于或者等于800 millicpu。
+* 核查容器声明的 CPU 限制确保其小于或者等于 800 millicpu。
-
-{{< note >}} 当创建 LimitRange 对象时，你也可以声明 huge-page 和 GPU 的限制。当这些资源同时声明了 'default' 和 ‘defaultRequest’ 参数时，两个参数值必须相同。 {{< /note >}}
<!--
When creating a `LimitRange` object, you can specify limits on huge-pages
or GPUs as well. However, when both `default` and `defaultRequest` are specified
on these resources, the two values must be the same.
-->
-
-
-
+{{< note >}}
+当创建 LimitRange 对象时，你也可以声明大页面和 GPU 的限制。
+当这些资源同时声明了 'default' 和 'defaultRequest' 参数时，两个参数值必须相同。
+{{< /note >}}
<!--
Here's the configuration file for a Pod that has one Container. The Container manifest
specifies a CPU request of 500 millicpu and a CPU limit of 800 millicpu. These satisfy the
minimum and maximum CPU constraints imposed by the LimitRange.
-->
-
-这里给出了包含一个容器的 Pod 的配置文件。该容器声明了500 millicpu的 CPU 请求和800 millicpu的 CPU 限制。这些参数满足了 LimitRange 对象规定的 CPU 最小和最大限制。
+这里给出了包含一个容器的 Pod 的配置文件。
+该容器声明了 500 millicpu 的 CPU 请求和 800 millicpu 的 CPU 限制。
+这些参数满足了 LimitRange 对象规定的 CPU 最小和最大限制。
{{< codenew file="admin/resource/cpu-constraints-pod.yaml" >}}
<!--
Create the Pod:
-->
-
创建Pod：
```shell
-kubectl create -f https://k8s.io/examples/admin/resource/cpu-constraints-pod.yaml --namespace=constraints-cpu-example
+kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod.yaml --namespace=constraints-cpu-example
```
<!--
Verify that the Pod's Container is running:
-->
-
确认一下 Pod 中的容器在运行：
```shell
@@ -175,7 +161,6 @@ kubectl get pod constraints-cpu-demo --namespace=constraints-cpu-example
<!--
View detailed information about the Pod:
-->
-
查看 Pod 的详情：
```shell
@@ -186,8 +171,8 @@ kubectl get pod constraints-cpu-demo --output=yaml --namespace=constraints-cpu-e
The output shows that the Container has a CPU request of 500 millicpu and CPU limit
of 800 millicpu. These satisfy the constraints imposed by the LimitRange.
-->
-
-输出结果表明容器的 CPU 请求为500 millicpu，CPU限制为800 millicpu。这些参数满足 LimitRange 规定的限制范围。
+输出结果表明容器的 CPU 请求为 500 millicpu，CPU 限制为 800 millicpu。
+这些参数满足 LimitRange 规定的限制范围。
```yaml
resources:
@@ -200,7 +185,6 @@ resources:
<!--
## Delete the Pod
-->
-
## 删除 Pod
```shell
@@ -213,28 +197,26 @@ kubectl delete pod constraints-cpu-demo --namespace=constraints-cpu-example
Here's the configuration file for a Pod that has one Container. The Container specifies a
CPU request of 500 millicpu and a cpu limit of 1.5 cpu.
-->
-
## 尝试创建一个超过最大 CPU 限制的 Pod
-这里给出了包含一个容器的 Pod 的配置文件。容器声明了500 millicpu的CPU请求和1.5 cpu的 CPU 限制。
+这里给出了包含一个容器的 Pod 的配置文件。容器声明了 500 millicpu 的 CPU
+请求和 1.5 CPU 的 CPU 限制。
{{< codenew file="admin/resource/cpu-constraints-pod-2.yaml" >}}
<!--
Attempt to create the Pod:
-->
-
尝试创建 Pod：
```shell
-kubectl create -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-2.yaml --namespace=constraints-cpu-example
+kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-2.yaml --namespace=constraints-cpu-example
```
<!--
The output shows that the Pod does not get created, because the Container specifies a CPU limit that is
too large:
-->
-
输出结果表明 Pod 没有创建成功，因为容器声明的 CPU 限制太大了：
```
@@ -248,7 +230,6 @@ pods "constraints-cpu-demo-2" is forbidden: maximum cpu usage per Container is 8
Here's the configuration file for a Pod that has one Container. The Container specifies a
CPU request of 100 millicpu and a CPU limit of 800 millicpu.
-->
-
## 尝试创建一个不满足最小 CPU 请求的 Pod
这里给出了包含一个容器的 Pod 的配置文件。该容器声明了100 millicpu的 CPU 请求和800 millicpu的 CPU 限制。
@@ -258,18 +239,16 @@ CPU request of 100 millicpu and a CPU limit of 800 millicpu.
<!--
Attempt to create the Pod:
-->
-
尝试创建 Pod：
```shell
-kubectl create -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-3.yaml --namespace=constraints-cpu-example
+kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-3.yaml --namespace=constraints-cpu-example
```
<!--
The output shows that the Pod does not get created, because the Container specifies a CPU
request that is too small:
-->
-
输出结果显示 Pod 没有创建成功，因为容器声明的 CPU 请求太小了：
```
@@ -283,27 +262,24 @@ pods "constraints-cpu-demo-4" is forbidden: minimum cpu usage per Container is 2
Here's the configuration file for a Pod that has one Container. The Container does not
specify a CPU request, and it does not specify a CPU limit.
-->
+## 创建一个没有声明 CPU 请求和 CPU 限制的 Pod
-## 创建一个没有声明CPU请求和CPU限制的Pod
-
-这里给出了包含一个容器的Pod的配置文件。该容器没有声明CPU请求和CPU限制。
+这里给出了包含一个容器的 Pod 的配置文件。该容器没有设定 CPU 请求和 CPU 限制。
{{< codenew file="admin/resource/cpu-constraints-pod-4.yaml" >}}
<!--
Create the Pod:
-->
-
创建 Pod：
```shell
-kubectl create -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-4.yaml --namespace=constraints-cpu-example
+kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-4.yaml --namespace=constraints-cpu-example
```
<!--
View detailed information about the Pod:
-->
-
查看 Pod 的详情：
```
@@ -314,8 +290,8 @@ kubectl get pod constraints-cpu-demo-4 --namespace=constraints-cpu-example --out
The output shows that the Pod's Container has a CPU request of 800 millicpu and a CPU limit of 800 millicpu.
How did the Container get those values?
-->
-
-输出结果显示 Pod 的容器有个800 millicpu的 CPU 请求和800 millicpu的 CPU 限制。容器时怎样得到那些值的呢？
+输出结果显示 Pod 的容器有个 800 millicpu 的 CPU 请求和 800 millicpu 的 CPU 限制。
+容器是怎样得到那些值的呢？
```yaml
resources:
@@ -330,8 +306,8 @@ Because your Container did not specify its own CPU request and limit, it was giv
[default CPU request and limit](/docs/tasks/administer-cluster/cpu-default-namespace/)
from the LimitRange.
-->
-
-因为你的容器没有声明自己的 CPU 请求和限制，LimitRange 给它指定了[默认的CPU请求和限制](/docs/tasks/administer-cluster/cpu-default-namespace/)
+因为你的 Container 没有声明自己的 CPU 请求和限制，LimitRange 给它指定了
+[默认的 CPU 请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
<!--
At this point, your Container might be running or it might not be running. Recall that a prerequisite
@@ -342,8 +318,10 @@ enough CPU to accommodate the 800 millicpu request.
Delete your Pod:
-->
-
-此时，你的容器可能运行也可能没有运行。回想一下，本任务的先决条件是你的节点要有1 个 CPU。如果你的每个节点仅有1个 CPU，那么可能没有任何一个节点可以满足800 millicpu的 CPU 请求。如果你在用的节点恰好有两个 CPU，那么你才可能有足够的 CPU来满足800 millicpu的请求。
+此时，你的容器可能运行也可能没有运行。
+回想一下，本任务的先决条件是你的节点要有 1 个 CPU。
+如果你的每个节点仅有 1 个 CPU，那么可能没有任何一个节点可以满足 800 millicpu 的 CPU 请求。
+如果你在用的节点恰好有两个 CPU，那么你才可能有足够的 CPU 来满足 800 millicpu 的请求。
```
kubectl delete pod constraints-cpu-demo-4 --namespace=constraints-cpu-example
@@ -356,21 +334,18 @@ The maximum and minimum CPU constraints imposed on a namespace by a LimitRange a
when a Pod is created or updated. If you change the LimitRange, it does not affect
Pods that were created previously.
-->
-
## CPU 最小和最大限制的强制执行
-只有当Pod创建或者更新时，LimitRange为命名空间规定的CPU最小和最大限制才会被强制执行。如果你对LimitRange进行修改，那不会影响此前创建的Pod。
+只有当 Pod 创建或者更新时，LimitRange 为命名空间规定的 CPU 最小和最大限制才会被强制执行。
+如果你对 LimitRange 进行修改，那不会影响此前创建的 Pod。
<!--
## Motivation for minimum and maximum CPU constraints
--->
-## 最小和最大 CPU 限制范围的动机
-
-<!--
As a cluster administrator, you might want to impose restrictions on the CPU resources that Pods can use.
For example:
-->
+## 最小和最大 CPU 限制范围的动机
作为集群管理员，你可能想设定 Pod 可以使用的 CPU 资源限制。例如：
@@ -383,18 +358,17 @@ You want to allow production workloads to consume up to 3 CPU, but you want deve
to 1 CPU. You create separate namespaces for production and development, and you apply CPU constraints to
each namespace.
-->
-
-* 集群中的每个节点有两个 CPU。你不想接受任何请求超过2个 CPU 的 Pod，因为集群中没有节点可以支持这种请求。
-
-* 你的生产和开发部门共享一个集群。你想允许生产工作负载消耗3个 CPU，而开发工作负载的消耗限制为1个 CPU。你为生产和开发创建不同的命名空间，并且你为每个命名空间都应用了 CPU 限制。
+* 集群中的每个节点有两个 CPU。你不想接受任何请求超过 2 个 CPU 的 Pod，因为集群中没有节点可以支持这种请求。
+* 你的生产和开发部门共享一个集群。你想允许生产工作负载消耗 3 个 CPU，
+ 而开发部门工作负载的消耗限制为 1 个 CPU。
+ 你可以为生产和开发创建不同的命名空间，并且为每个命名空间都应用 CPU 限制。
<!--
## Clean up
Delete your namespace:
-->
-
-## 环境清理
+## 清理
删除你的命名空间：
@@ -402,11 +376,8 @@ Delete your namespace:
kubectl delete namespace constraints-cpu-example
```
-
-
## {{% heading "whatsnext" %}}
-
<!--
### For cluster administrators
@@ -425,34 +396,24 @@ kubectl delete namespace constraints-cpu-example
### 集群管理员参考：
-* [为命名空间配置默认内存请求和限制](/docs/tasks/administer-cluster/memory-default-namespace/)
-
-* [为命名空间配置内存限制的最小值和最大值](/docs/tasks/administer-cluster/memory-constraint-namespace/)
-
-* [为命名空间配置 CPU 限制的最小值和最大值](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
-
-* [为命名空间配置内存和 CPU 配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
-
-* [为命名空间配置 Pod 配额](/docs/tasks/administer-cluster/quota-pod-namespace/)
-
-* [为 API 对象配置配额](/docs/tasks/administer-cluster/quota-api-object/)
+* [为命名空间配置默认内存请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
+* [为命名空间配置内存限制的最小值和最大值](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
+* [为命名空间配置 CPU 限制的最小值和最大值](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
+* [为命名空间配置内存和 CPU 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
+* [为命名空间配置 Pod 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
+* [为 API 对象配置配额](/zh/docs/tasks/administer-cluster/quota-api-object/)
<!--
### For app developers
* [Assign Memory Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/)
-
* [Assign CPU Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/)
-
* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
-->
### 应用开发者参考：
-* [为容器和 Pod 分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/)
-
-* [为容器和 Pod 分配 CPU 资源](/docs/tasks/configure-pod-container/assign-cpu-resource/)
-
-* [为 Pod 配置 Service 数量](/docs/tasks/configure-pod-container/quality-service-pod/)
-
+* [为容器和 Pod 分配内存资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)
+* [为容器和 Pod 分配 CPU 资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/)
+* [为 Pod 配置 Service 数量](/zh/docs/tasks/configure-pod-container/quality-service-pod/)
diff --git a/content/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md b/content/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md
index 6aa7b7ac0e..e4365a4c23 100644
--- a/content/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md
+++ b/content/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md
@@ -1,15 +1,13 @@
---
-title: 为命名空间配置默认的CPU请求和限制
+title: 为命名空间配置默认的 CPU 请求和限制
content_type: task
weight: 20
---
<!--
----
title: Configure Default CPU Requests and Limits for a Namespace
content_type: task
weight: 20
----
-->
<!-- overview -->
@@ -20,29 +18,24 @@ that has a default CPU limit, and the Container does not specify its own CPU lim
the Container is assigned the default CPU limit. Kubernetes assigns a default CPU request
under certain conditions that are explained later in this topic.
-->
-
本章介绍怎样为命名空间配置默认的 CPU 请求和限制。
-一个 Kubernetes 集群可被划分为多个命名空间。如果在配置了 CPU 限制的命名空间创建容器，并且该容器没有声明自己的 CPU 限制，那么这个容器会被指定默认的 CPU 限制。Kubernetes 在一些特定情况还会指定 CPU 请求，本文后续章节将会对其进行解释。
-
+一个 Kubernetes 集群可被划分为多个命名空间。如果在配置了 CPU 限制的命名空间创建容器，
+并且该容器没有声明自己的 CPU 限制，那么这个容器会被指定默认的 CPU 限制。
+Kubernetes 在一些特定情况还会指定 CPU 请求，本文后续章节将会对其进行解释。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
<!-- steps -->
<!--
## Create a namespace
--->
-## 创建命名空间
-
-<!--
Create a namespace so that the resources you create in this exercise are
isolated from the rest of your cluster.
-->
+## 创建命名空间
创建一个命名空间，以便本练习中创建的资源和集群的其余部分相隔离。
@@ -52,14 +45,11 @@ kubectl create namespace default-cpu-example
<!--
## Create a LimitRange and a Pod
--->
-创建 LimitRange 和 Pod
-
-<!--
Here's the configuration file for a LimitRange object. The configuration specifies
a default CPU request and a default CPU limit.
-->
+## 创建 LimitRange 和 Pod
这里给出了 LimitRange 对象的配置文件。该配置声明了一个默认的 CPU 请求和一个默认的 CPU 限制。
@@ -68,11 +58,10 @@ a default CPU request and a default CPU limit.
<!--
Create the LimitRange in the default-cpu-example namespace:
-->
-
在命名空间 default-cpu-example 中创建 LimitRange 对象：
```shell
-kubectl create -f https://k8s.io/examples/admin/resource/cpu-defaults.yaml --namespace=default-cpu-example
+kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults.yaml --namespace=default-cpu-example
```
<!--
@@ -84,8 +73,8 @@ CPU limit of 1.
Here's the configuration file for a Pod that has one Container. The Container
does not specify a CPU request and limit.
-->
-
-现在如果在 default-cpu-example 命名空间创建一个容器，该容器没有声明自己的 CPU 请求和限制时，将会给它指定默认的 CPU 请求0.5和默认的 CPU 限制值1.
+现在如果在 default-cpu-example 命名空间创建一个容器，该容器没有声明自己的 CPU 请求和限制时，
+将会给它指定默认的 CPU 请求0.5和默认的 CPU 限制值1.
这里给出了包含一个容器的 Pod 的配置文件。该容器没有声明 CPU 请求和限制。
@@ -94,17 +83,15 @@ does not specify a CPU request and limit.
<!--
Create the Pod.
-->
-
创建 Pod。
```shell
-kubectl create -f https://k8s.io/examples/admin/resource/cpu-defaults-pod.yaml --namespace=default-cpu-example
+kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod.yaml --namespace=default-cpu-example
```
<!--
View the Pod's specification:
-->
-
查看该 Pod 的声明：
```shell
@@ -115,7 +102,6 @@ kubectl get pod default-cpu-demo --output=yaml --namespace=default-cpu-example
The output shows that the Pod's Container has a CPU request of 500 millicpus and
a CPU limit of 1 cpu. These are the default values specified by the LimitRange.
-->
-
输出显示该 Pod 的容器有一个500 millicpus的 CPU 请求和一个1 cpu的 CPU 限制。这些是 LimitRange 声明的默认值。
```shell
@@ -132,14 +118,11 @@ containers:
<!--
## What if you specify a Container's limit, but not its request?
--->
-## 你只声明容器的限制，而不声明请求会怎么样？
-
-<!--
Here's the configuration file for a Pod that has one Container. The Container
specifies a CPU limit, but not a request:
-->
+## 你只声明容器的限制，而不声明请求会怎么样？
这是包含一个容器的 Pod 的配置文件。该容器声明了 CPU 限制，而没有声明 CPU 请求。
@@ -148,17 +131,15 @@ specifies a CPU limit, but not a request:
<!--
Create the Pod:
-->
-
创建 Pod
```shell
-kubectl create -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-2.yaml --namespace=default-cpu-example
+kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-2.yaml --namespace=default-cpu-example
```
<!--
View the Pod specification:
-->
-
查看 Pod 的声明：
```
@@ -169,7 +150,6 @@ kubectl get pod default-cpu-demo-2 --output=yaml --namespace=default-cpu-example
The output shows that the Container's CPU request is set to match its CPU limit.
Notice that the Container was not assigned the default CPU request value of 0.5 cpu.
-->
-
输出显示该容器的 CPU 请求和 CPU 限制设置相同。注意该容器没有被指定默认的 CPU 请求值0.5 cpu。
```
@@ -182,14 +162,11 @@ resources:
<!--
## What if you specify a Container's request, but not its limit?
--->
-## 你只声明容器的请求，而不声明它的限制会怎么样？
-
-<!--
Here's the configuration file for a Pod that has one Container. The Container
specifies a CPU request, but not a limit:
-->
+## 你只声明容器的请求，而不声明它的限制会怎么样？
这里给出了包含一个容器的 Pod 的配置文件。该容器声明了 CPU 请求，而没有声明 CPU 限制。
@@ -198,18 +175,16 @@ specifies a CPU request, but not a limit:
<!--
Create the Pod:
-->
-
创建 Pod：
```shell
-kubectl create -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-3.yaml --namespace=default-cpu-example
+kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-3.yaml --namespace=default-cpu-example
```
<!--
View the Pod specification:
-->
-
-查看 Pod 的声明：
+查看 Pod 的规约：
```
kubectl get pod default-cpu-demo-3 --output=yaml --namespace=default-cpu-example
@@ -220,8 +195,8 @@ The output shows that the Container's CPU request is set to the value specified
Container's configuration file. The Container's CPU limit is set to 1 cpu, which is the
default CPU limit for the namespace.
-->
-
-结果显示该容器的 CPU 请求被设置为容器配置文件中声明的数值。容器的CPU限制被设置为1 cpu，即该命名空间的默认 CPU 限制值。
+结果显示该容器的 CPU 请求被设置为容器配置文件中声明的数值。
+容器的CPU限制被设置为 1 CPU，即该命名空间的默认 CPU 限制值。
```
resources:
@@ -233,11 +208,7 @@ resources:
<!--
## Motivation for default CPU limits and requests
--->
-## 默认 CPU 限制和请求的动机
-
-<!--
If your namespace has a
[resource quota](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/),
it is helpful to have a default value in place for CPU limit.
@@ -249,69 +220,49 @@ Here are two of the restrictions that a resource quota imposes on a namespace:
If a Container does not specify its own CPU limit, it is given the default limit, and then
it can be allowed to run in a namespace that is restricted by a quota.
-->
+## 默认 CPU 限制和请求的动机
-如果你的命名空间有一个[资源配额](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/),那么有一个默认的 CPU 限制是有帮助的。这里有两条资源配额强加给命名空间的限制：
+如果你的命名空间有一个
+[资源配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)，
+那么有一个默认的 CPU 限制是有帮助的。这里有资源配额强加给命名空间的两条限制：
* 命名空间中运行的每个容器必须有自己的 CPU 限制。
* 命名空间中所有容器使用的 CPU 总和不能超过一个声明值。
如果容器没有声明自己的 CPU 限制，将会给它一个默认限制，这样它就能被允许运行在一个有配额限制的命名空间中。
-
-
## {{% heading "whatsnext" %}}
-
<!--
### For cluster administrators
--->
-### 集群管理员参考
-
-<!--
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)
-
* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)
-
* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
-
* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
-
* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/)
-
* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
-->
+### 集群管理员参考
-* [为命名空间配置默认内存请求和限制](/docs/tasks/administer-cluster/memory-default-namespace/)
-
-* [为命名空间配置内存限制的最小值和最大值](/docs/tasks/administer-cluster/memory-constraint-namespace/)
-
-* [为命名空间配置 CPU 限制的最小值和最大值](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
-
-* [为命名空间配置内存和 CPU 配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
-
-* [为命名空间配置 Pod 配额](/docs/tasks/administer-cluster/quota-pod-namespace/)
-
-* [为 API 对象配置配额](/docs/tasks/administer-cluster/quota-api-object/)
+* [为命名空间配置默认内存请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
+* [为命名空间配置内存限制的最小值和最大值](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
+* [为命名空间配置 CPU 限制的最小值和最大值](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
+* [为命名空间配置内存和 CPU 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
+* [为命名空间配置 Pod 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
+* [为 API 对象配置配额](/zh/docs/tasks/administer-cluster/quota-api-object/)
<!--
### For app developers
--->
-### 应用开发者参考
-
-<!--
* [Assign Memory Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/)
-
* [Assign CPU Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/)
-
* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
-->
+### 应用开发者参考
-* [为容器和 Pod 分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/)
-
-* [为容器和 Pod 分配 CPU 资源](/docs/tasks/configure-pod-container/assign-cpu-resource/)
-
-* [为 Pod 配置 Service 数量](/docs/tasks/configure-pod-container/quality-service-pod/)
+* [为容器和 Pod 分配内存资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)
+* [为容器和 Pod 分配 CPU 资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/)
+* [为 Pod 配置 Service 数量](/zh/docs/tasks/configure-pod-container/quality-service-pod/)
diff --git a/content/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md b/content/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md
index 48cfd64b47..ef9881d09b 100644
--- a/content/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md
+++ b/content/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md
@@ -5,11 +5,9 @@ weight: 30
---
<!--
----
title: Configure Minimum and Maximum Memory Constraints for a Namespace
content_type: task
weight: 30
----
-->
<!-- overview -->
@@ -21,25 +19,18 @@ running in a namespace. You specify minimum and maximum memory values in a
object. If a Pod does not meet the constraints imposed by the LimitRange,
it cannot be created in the namespace.
-->
-
-此页面介绍如何设置在命名空间中运行的容器使用的内存的最小值和最大值。 您可以在 [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)对象中指定最小和最大内存值。 如果 Pod 不满足 LimitRange 施加的约束，则无法在命名空间中创建它。
-
-
-
+本页介绍如何设置在命名空间中运行的容器使用的内存的最小值和最大值。 你可以在
+[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core)
+对象中指定最小和最大内存值。如果 Pod 不满足 LimitRange 施加的约束，则无法在命名空间中创建它。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
Each node in your cluster must have at least 1 GiB of memory.
-->
-
-集群中每个节点必须至少要有1 GiB 的内存。
-
-
-
+集群中每个节点必须至少要有 1 GiB 的内存。
<!-- steps -->
@@ -49,7 +40,6 @@ Each node in your cluster must have at least 1 GiB of memory.
Create a namespace so that the resources you create in this exercise are
isolated from the rest of your cluster.
-->
-
## 创建命名空间
创建一个命名空间，以便在此练习中创建的资源与群集的其余资源隔离。
@@ -63,28 +53,24 @@ kubectl create namespace constraints-mem-example
Here's the configuration file for a LimitRange:
-->
-
## 创建 LimitRange 和 Pod
下面是 LimitRange 的配置文件：
-
{{< codenew file="admin/resource/memory-constraints.yaml" >}}
<!--
Create the LimitRange:
-->
-
创建 LimitRange:
```shell
-kubectl create -f https://k8s.io/examples/admin/resource/memory-constraints.yaml --namespace=constraints-mem-example
+kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints.yaml --namespace=constraints-mem-example
```
<!--
View detailed information about the LimitRange:
-->
-
查看 LimitRange 的详情：
```shell
@@ -96,8 +82,7 @@ The output shows the minimum and maximum memory constraints as expected. But
notice that even though you didn't specify default values in the configuration
file for the LimitRange, they were created automatically.
-->
-
-输出显示预期的最小和最大内存约束。 但请注意，即使您没有在 LimitRange 的配置文件中指定默认值，也会自动创建它们。
+输出显示预期的最小和最大内存约束。 但请注意，即使你没有在 LimitRange 的配置文件中指定默认值，也会自动创建它们。
```
limits:
@@ -127,7 +112,6 @@ Here's the configuration file for a Pod that has one Container. The Container ma
specifies a memory request of 600 MiB and a memory limit of 800 MiB. These satisfy the
minimum and maximum memory constraints imposed by the LimitRange.
-->
-
现在，只要在 constraints-mem-example 命名空间中创建容器，Kubernetes 就会执行下面的步骤：
* 如果 Container 未指定自己的内存请求和限制，将为它指定默认的内存请求和限制。
@@ -136,24 +120,23 @@ minimum and maximum memory constraints imposed by the LimitRange.
* 验证 Container 的内存限制是否小于或等于1 GiB。
-这里给出了包含一个 Container 的 Pod 配置文件。Container 声明了600 MiB 的内存请求和800 MiB 的内存限制， 这些满足了 LimitRange 施加的最小和最大内存约束。
+这里给出了包含一个 Container 的 Pod 配置文件。Container 声明了 600 MiB 的内存请求和
+800 MiB 的内存限制， 这些满足了 LimitRange 施加的最小和最大内存约束。
{{< codenew file="admin/resource/memory-constraints-pod.yaml" >}}
<!--
Create the Pod:
-->
-
创建 Pod：
```shell
-kubectl create -f https://k8s.io/examples/admin/resource/memory-constraints-pod.yaml --namespace=constraints-mem-example
+kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod.yaml --namespace=constraints-mem-example
```
<!--
Verify that the Pod's Container is running:
-->
-
确认下 Pod 中的容器在运行：
```shell
@@ -163,7 +146,6 @@ kubectl get pod constraints-mem-demo --namespace=constraints-mem-example
<!--
View detailed information about the Pod:
-->
-
查看 Pod 详情：
```shell
@@ -174,7 +156,6 @@ kubectl get pod constraints-mem-demo --output=yaml --namespace=constraints-mem-e
The output shows that the Container has a memory request of 600 MiB and a memory limit
of 800 MiB. These satisfy the constraints imposed by the LimitRange.
-->
-
输出结果显示容器的内存请求为600 MiB，内存限制为800 MiB。这些满足了 LimitRange 设定的限制范围。
```yaml
@@ -188,7 +169,6 @@ resources:
<!--
Delete your Pod:
-->
-
删除你创建的 Pod：
```shell
@@ -201,7 +181,6 @@ kubectl delete pod constraints-mem-demo --namespace=constraints-mem-example
Here's the configuration file for a Pod that has one Container. The Container specifies a
memory request of 800 MiB and a memory limit of 1.5 GiB.
-->
-
## 尝试创建一个超过最大内存限制的 Pod
这里给出了包含一个容器的 Pod 的配置文件。容器声明了800 MiB 的内存请求和1.5 GiB 的内存限制。
@@ -211,18 +190,16 @@ memory request of 800 MiB and a memory limit of 1.5 GiB.
<!--
Attempt to create the Pod:
-->
-
尝试创建 Pod:
```shell
-kubectl create -f https://k8s.io/examples/admin/resource/memory-constraints-pod-2.yaml --namespace=constraints-mem-example
+kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-2.yaml --namespace=constraints-mem-example
```
<!--
The output shows that the Pod does not get created, because the Container specifies a memory limit that is
too large:
-->
-
输出结果显示 Pod 没有创建成功，因为容器声明的内存限制太大了：
```
@@ -236,7 +213,6 @@ pods "constraints-mem-demo-2" is forbidden: maximum memory usage per Container i
Here's the configuration file for a Pod that has one Container. The Container specifies a
memory request of 100 MiB and a memory limit of 800 MiB.
-->
-
## 尝试创建一个不满足最小内存请求的 Pod
这里给出了包含一个容器的 Pod 的配置文件。容器声明了100 MiB 的内存请求和800 MiB 的内存限制。
@@ -246,18 +222,16 @@ memory request of 100 MiB and a memory limit of 800 MiB.
<!--
Attempt to create the Pod:
-->
-
尝试创建 Pod：
```shell
-kubectl create -f https://k8s.io/examples/admin/resource/memory-constraints-pod-3.yaml --namespace=constraints-mem-example
+kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-3.yaml --namespace=constraints-mem-example
```
<!--
The output shows that the Pod does not get created, because the Container specifies a memory
request that is too small:
-->
-
输出结果显示 Pod 没有创建成功，因为容器声明的内存请求太小了：
```
@@ -271,7 +245,6 @@ pods "constraints-mem-demo-3" is forbidden: minimum memory usage per Container i
Here's the configuration file for a Pod that has one Container. The Container does not
specify a memory request, and it does not specify a memory limit.
-->
-
## 创建一个没有声明内存请求和限制的 Pod
这里给出了包含一个容器的 Pod 的配置文件。容器没有声明内存请求，也没有声明内存限制。
@@ -281,17 +254,15 @@ specify a memory request, and it does not specify a memory limit.
<!--
Create the Pod:
-->
-
创建 Pod：
```shell
-kubectl create -f https://k8s.io/examples/admin/resource/memory-constraints-pod-4.yaml --namespace=constraints-mem-example
+kubectl apply -f https://k8s.io/examples/admin/resource/memory-constraints-pod-4.yaml --namespace=constraints-mem-example
```
<!--
View detailed information about the Pod:
-->
-
查看 Pod 详情：
```
@@ -302,7 +273,6 @@ kubectl get pod constraints-mem-demo-4 --namespace=constraints-mem-example --out
The output shows that the Pod's Container has a memory request of 1 GiB and a memory limit of 1 GiB.
How did the Container get those values?
-->
-
输出结果显示 Pod 的内存请求为1 GiB，内存限制为1 GiB。容器怎样获得哪些数值呢？
```
@@ -318,8 +288,8 @@ Because your Container did not specify its own memory request and limit, it was
[default memory request and limit](/docs/tasks/administer-cluster/memory-default-namespace/)
from the LimitRange.
-->
-
-因为你的容器没有声明自己的内存请求和限制，它从 LimitRange 那里获得了[默认的内存请求和限制](/docs/tasks/administer-cluster/memory-default-namespace/)。
+因为你的容器没有声明自己的内存请求和限制，它从 LimitRange 那里获得了
+[默认的内存请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)。
<!--
At this point, your Container might be running or it might not be running. Recall that a prerequisite
@@ -330,8 +300,9 @@ enough space to accommodate the 1 GiB request.
Delete your Pod:
-->
-
-此时，你的容器可能运行起来也可能没有运行起来。回想一下我们本次任务的先决条件是你的每个节点都至少有1 GiB 的内存。如果你的每个节点都只有1 GiB 的内存，那将没有一个节点拥有足够的可分配内存来满足1 GiB 的内存请求。
+此时，你的容器可能运行起来也可能没有运行起来。
+回想一下我们本次任务的先决条件是你的每个节点都至少有1 GiB 的内存。
+如果你的每个节点都只有1 GiB 的内存，那将没有一个节点拥有足够的可分配内存来满足1 GiB 的内存请求。
删除你的 Pod：
@@ -346,15 +317,14 @@ The maximum and minimum memory constraints imposed on a namespace by a LimitRang
when a Pod is created or updated. If you change the LimitRange, it does not affect
Pods that were created previously.
-->
-
## 强制执行内存最小和最大限制
-LimitRange 为命名空间设定的最小和最大内存限制只有在 Pod 创建和更新时才会强制执行。如果你更新 LimitRange，它不会影响此前创建的 Pod。
+LimitRange 为命名空间设定的最小和最大内存限制只有在 Pod 创建和更新时才会强制执行。
+如果你更新 LimitRange，它不会影响此前创建的 Pod。
<!--
## Motivation for minimum and maximum memory constraints
-->
-
## 设置内存最小和最大限制的动因
<!--
@@ -362,25 +332,26 @@ As a cluster administrator, you might want to impose restrictions on the amount
For example:
* Each Node in a cluster has 2 GB of memory. You do not want to accept any Pod that requests
-more than 2 GB of memory, because no Node in the cluster can support the request.
+ more than 2 GB of memory, because no Node in the cluster can support the request.
* A cluster is shared by your production and development departments.
-You want to allow production workloads to consume up to 8 GB of memory, but
-you want development workloads to be limited to 512 MB. You create separate namespaces
-for production and development, and you apply memory constraints to each namespace.
+ You want to allow production workloads to consume up to 8 GB of memory, but
+ you want development workloads to be limited to 512 MB. You create separate namespaces
+ for production and development, and you apply memory constraints to each namespace.
-->
-
做为集群管理员，你可能想规定 Pod 可以使用的内存总量限制。例如：
-* 集群的每个节点有2 GB 内存。你不想接受任何请求超过2 GB 的 Pod，因为集群中没有节点可以满足。
+* 集群的每个节点有 2 GB 内存。你不想接受任何请求超过 2 GB 的 Pod，因为集群中没有节点可以满足。
+* 集群由生产部门和开发部门共享。你希望允许产品部门的负载最多耗用 8 GB 内存，
+ 但是开发部门的负载最多可使用 512 MiB。
+ 这时，你可以为产品部门和开发部门分别创建名字空间，并为各个名字空间设置内存约束。
<!--
## Clean up
Delete your namespace:
-->
-
-## 数据清理
+## 清理
删除你的命名空间：
@@ -388,57 +359,39 @@ Delete your namespace:
kubectl delete namespace constraints-mem-example
```
-
-
## {{% heading "whatsnext" %}}
-
<!--
### For cluster administrators
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)
-
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/)
-
* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
-
* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
-
* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/)
-
* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
-->
### 集群管理员参考
-* [为命名空间配置默认内存请求和限制](/docs/tasks/administer-cluster/memory-default-namespace/)
-
-* [为命名空间配置内存限制的最小值和最大值](/docs/tasks/administer-cluster/memory-constraint-namespace/)
-
-* [为命名空间配置 CPU 限制的最小值和最大值](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
-
-* [为命名空间配置内存和 CPU 配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
-
-* [为命名空间配置 Pod 配额](/docs/tasks/administer-cluster/quota-pod-namespace/)
-
-* [为 API 对象配置配额](/docs/tasks/administer-cluster/quota-api-object/)
+* [为命名空间配置默认内存请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
+* [为命名空间配置内存限制的最小值和最大值](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
+* [为命名空间配置 CPU 限制的最小值和最大值](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
+* [为命名空间配置内存和 CPU 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
+* [为命名空间配置 Pod 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
+* [为 API 对象配置配额](/zh/docs/tasks/administer-cluster/quota-api-object/)
<!--
### For app developers
* [Assign Memory Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/)
-
* [Assign CPU Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/)
-
* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
-->
### 应用开发者参考
-* [为容器和 Pod 分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/)
-
-* [为容器和 Pod 分配 CPU 资源](/docs/tasks/configure-pod-container/assign-cpu-resource/)
-
-* [为 Pod 配置 Service 数量](/docs/tasks/configure-pod-container/quality-service-pod/)
-
+* [为容器和 Pod 分配内存资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)
+* [为容器和 Pod 分配 CPU 资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/)
+* [为 Pod 配置 Service 数量](/zh/docs/tasks/configure-pod-container/quality-service-pod/)
diff --git a/content/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md b/content/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md
index 7a2259a274..eaecd09ee0 100644
--- a/content/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md
+++ b/content/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md
@@ -5,11 +5,9 @@ weight: 10
---
<!--
----
title: Configure Default Memory Requests and Limits for a Namespace
content_type: task
weight: 10
----
-->
<!-- overview -->
@@ -21,35 +19,29 @@ does not specify its own memory limit, then the Container is assigned the defaul
Kubernetes assigns a default memory request under certain conditions that are explained later in this topic.
-->
-本文介绍怎样给命名空间配置默认的内存请求和限制。如果在一个有默认内存限制的命名空间创建容器，该容器没有声明自己的内存限制时，将会被指定默认内存限制。Kubernetes 还为某些情况指定了默认的内存请求，本章后面会进行介绍。
-
-
+本文介绍怎样给命名空间配置默认的内存请求和限制。
+如果在一个有默认内存限制的命名空间创建容器，该容器没有声明自己的内存限制时，
+将会被指定默认内存限制。
+Kubernetes 还为某些情况指定了默认的内存请求，本章后面会进行介绍。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
Each node in your cluster must have at least 2 GiB of memory.
-->
-
-你的集群中的每个节点必须至少有2 GiB的内存。
-
-
+你的集群中的每个节点必须至少有 2 GiB 的内存。
<!-- steps -->
<!--
## Create a namespace
--->
-## 创建命名空间
-
-<!--
Create a namespace so that the resources you create in this exercise are
isolated from the rest of your cluster.
-->
+## 创建命名空间
创建一个命名空间，以便本练习中所建的资源与集群的其余资源相隔离。
@@ -59,14 +51,11 @@ kubectl create namespace default-mem-example
<!--
## Create a LimitRange and a Pod
--->
-## 创建 LimitRange 和 Pod
-
-<!--
Here's the configuration file for a LimitRange object. The configuration specifies
a default memory request and a default memory limit.
-->
+## 创建 LimitRange 和 Pod
这里给出了一个限制范围对象的配置文件。该配置声明了一个默认的内存请求和一个默认的内存限制。
@@ -75,11 +64,10 @@ a default memory request and a default memory limit.
<!--
Create the LimitRange in the default-mem-example namespace:
-->
-
在 default-mem-example 命名空间创建限制范围：
```shell
-kubectl create -f https://k8s.io/examples/admin/resource/memory-defaults.yaml --namespace=default-mem-example
+kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults.yaml --namespace=default-mem-example
```
<!--
@@ -91,25 +79,23 @@ memory limit of 512 MiB.
Here's the configuration file for a Pod that has one Container. The Container
does not specify a memory request and limit.
-->
-
-现在，如果在 default-mem-example 命名空间创建容器，并且该容器没有声明自己的内存请求和限制值，它将被指定一个默认的内存请求256 MiB和一个默认的内存限制512 Mib。
+现在，如果在 default-mem-example 命名空间创建容器，并且该容器没有声明自己的内存请求和限制值，
+它将被指定默认的内存请求 256 MiB 和默认的内存限制 512 MiB。
{{< codenew file="admin/resource/memory-defaults-pod.yaml" >}}
<!--
Create the Pod.
-->
-
创建 Pod
```shell
-kubectl create -f https://k8s.io/examples/admin/resource/memory-defaults-pod.yaml --namespace=default-mem-example
+kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults-pod.yaml --namespace=default-mem-example
```
<!--
View detailed information about the Pod:
-->
-
查看 Pod 的详情：
```shell
@@ -120,8 +106,8 @@ kubectl get pod default-mem-demo --output=yaml --namespace=default-mem-example
The output shows that the Pod's Container has a memory request of 256 MiB and
a memory limit of 512 MiB. These are the default values specified by the LimitRange.
-->
-
-输出内容显示该Pod的容器有一个256 MiB的内存请求和一个512 MiB的内存限制。这些都是限制范围声明的默认值。
+输出内容显示该 Pod 的容器有 256 MiB 的内存请求和 512 MiB 的内存限制。
+这些都是 LimitRange 设置的默认值。
```shell
containers:
@@ -138,7 +124,6 @@ containers:
<!--
Delete your Pod:
-->
-
删除你的 Pod：
```shell
@@ -147,14 +132,11 @@ kubectl delete pod default-mem-demo --namespace=default-mem-example
<!--
## What if you specify a Container's limit, but not its request?
--->
-## 声明容器的限制而不声明它的请求会怎么样？
-
-<!--
Here's the configuration file for a Pod that has one Container. The Container
specifies a memory limit, but not a request:
-->
+## 声明容器的限制而不声明它的请求会怎么样？
这里给出了包含一个容器的 Pod 的配置文件。该容器声明了内存限制，而没有声明内存请求：
@@ -163,17 +145,15 @@ specifies a memory limit, but not a request:
<!--
Create the Pod:
-->
-
创建 Pod：
```shell
-kubectl create -f https://k8s.io/examples/admin/resource/memory-defaults-pod-2.yaml --namespace=default-mem-example
+kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults-pod-2.yaml --namespace=default-mem-example
```
<!--
View detailed information about the Pod:
-->
-
查看 Pod 的详情：
```shell
@@ -184,8 +164,7 @@ kubectl get pod default-mem-demo-2 --output=yaml --namespace=default-mem-example
The output shows that the Container's memory request is set to match its memory limit.
Notice that the Container was not assigned the default memory request value of 256Mi.
-->
-
-输出结果显示容器的内存请求被设置为它的内存限制相同的值。注意该容器没有被指定默认的内存请求值256Mi。
+输出结果显示容器的内存请求被设置为它的内存限制相同的值。注意该容器没有被指定默认的内存请求值 256MiB。
```
resources:
@@ -198,14 +177,12 @@ resources:
<!--
## What if you specify a Container's request, but not its limit?
-->
-
## 声明容器的内存请求而不声明内存限制会怎么样？
<!--
Here's the configuration file for a Pod that has one Container. The Container
specifies a memory request, but not a limit:
-->
-
这里给出了一个包含一个容器的 Pod 的配置文件。该容器声明了内存请求，但没有内存限制：
{{< codenew file="admin/resource/memory-defaults-pod-3.yaml" >}}
@@ -213,17 +190,15 @@ specifies a memory request, but not a limit:
<!--
Create the Pod:
-->
-
创建 Pod：
```shell
-kubectl create -f https://k8s.io/examples/admin/resource/memory-defaults-pod-3.yaml --namespace=default-mem-example
+kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults-pod-3.yaml --namespace=default-mem-example
```
<!--
View the Pod's specification:
-->
-
查看 Pod 声明：
```shell
@@ -235,8 +210,8 @@ The output shows that the Container's memory request is set to the value specifi
Container's configuration file. The Container's memory limit is set to 512Mi, which is the
default memory limit for the namespace.
-->
-
-输出结果显示该容器的内存请求被设置为了容器配置文件中声明的数值。容器的内存限制被设置为512Mi，即命名空间的默认内存限制。
+输出结果显示该容器的内存请求被设置为了容器配置文件中声明的数值。
+容器的内存限制被设置为 512MiB，即命名空间的默认内存限制。
```
resources:
@@ -248,23 +223,20 @@ resources:
<!--
## Motivation for default memory limits and requests
--->
-## 设置默认内存限制和请求的动机
-
-<!--
If your namespace has a resource quota,
it is helpful to have a default value in place for memory limit.
Here are two of the restrictions that a resource quota imposes on a namespace:
-->
+## 设置默认内存限制和请求的动机
-如果你的命名空间有资源配额，那么默认内存限制是很有帮助的。下面是一个例子，通过资源配额为命名空间设置两项约束：
+如果你的命名空间有资源配额，那么默认内存限制是很有帮助的。
+下面是一个例子，通过资源配额为命名空间设置两项约束：
<!--
* Every Container that runs in the namespace must have its own memory limit.
* The total amount of memory used by all Containers in the namespace must not exceed a specified limit.
-->
-
* 运行在命名空间中的每个容器必须有自己的内存限制。
* 命名空间中所有容器的内存使用量之和不能超过声明的限制值。
@@ -272,21 +244,13 @@ Here are two of the restrictions that a resource quota imposes on a namespace:
If a Container does not specify its own memory limit, it is given the default limit, and then
it can be allowed to run in a namespace that is restricted by a quota.
-->
-
如果一个容器没有声明自己的内存限制，会被指定默认限制，然后它才会被允许在限定了配额的命名空间中运行。
-
-
## {{% heading "whatsnext" %}}
-
<!--
### For cluster administrators
--->
-### 集群管理员参考
-
-<!--
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/)
* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)
@@ -299,37 +263,27 @@ it can be allowed to run in a namespace that is restricted by a quota.
* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
-->
+### 集群管理员参考
-* [为命名空间配置默认的 CPU 请求和限制](/docs/tasks/administer-cluster/cpu-default-namespace/)
-
-* [为命名空间配置最小和最大内存限制](/docs/tasks/administer-cluster/memory-constraint-namespace/)
-
-* [为命名空间配置最小和最大 CPU 限制](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
-
-* [为命名空间配置内存和 CPU 配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
-
-* [为命名空间配置 Pod 配额](/docs/tasks/administer-cluster/quota-pod-namespace/)
-
-* [为 API 对象配置配额](/docs/tasks/administer-cluster/quota-api-object/)
+* [为命名空间配置默认的 CPU 请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
+* [为命名空间配置最小和最大内存限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
+* [为命名空间配置最小和最大 CPU 限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
+* [为命名空间配置内存和 CPU 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
+* [为命名空间配置 Pod 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
+* [为 API 对象配置配额](/zh/docs/tasks/administer-cluster/quota-api-object/)
<!--
### For app developers
--->
-### 应用开发者参考
-
-<!--
* [Assign Memory Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/)
* [Assign CPU Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
-->
+### 应用开发者参考
-* [为容器和 Pod 分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/)
-
-* [为容器和 Pod 分配 CPU 资源](/docs/tasks/configure-pod-container/assign-cpu-resource/)
-
-* [为 Pod 配置服务数量](/docs/tasks/configure-pod-container/quality-service-pod/)
-
+* [为容器和 Pod 分配内存资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)
+* [为容器和 Pod 分配 CPU 资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/)
+* [为 Pod 配置服务数量](/zh/docs/tasks/configure-pod-container/quality-service-pod/)
diff --git a/content/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md b/content/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md
index 74b6b528eb..51e433497f 100644
--- a/content/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md
+++ b/content/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace.md
@@ -5,11 +5,9 @@ weight: 50
---
<!--
----
title: Configure Memory and CPU Quotas for a Namespace
content_type: task
weight: 50
----
-->
<!-- overview -->
@@ -20,27 +18,18 @@ can be used by all Containers running in a namespace. You specify quotas in a
[ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core)
object.
-->
-
-本文介绍怎样为命名空间设置容器可用的内存和 CPU 总量。你可以通过 [ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core)
+本文介绍怎样为命名空间设置容器可用的内存和 CPU 总量。你可以通过
+[ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core)
对象设置配额.
-
-
-
-
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
Each node in your cluster must have at least 1 GiB of memory.
-->
-
-集群中每个节点至少有1 GiB的内存。
-
-
-
+集群中每个节点至少有 1 GiB 的内存。
<!-- steps -->
@@ -64,7 +53,6 @@ kubectl create namespace quota-mem-cpu-example
Here is the configuration file for a ResourceQuota object:
-->
-
## 创建 ResourceQuota
这里给出一个 ResourceQuota 对象的配置文件：
@@ -74,17 +62,15 @@ Here is the configuration file for a ResourceQuota object:
<!--
Create the ResourceQuota:
-->
-
创建 ResourceQuota
```shell
-kubectl create -f https://k8s.io/examples/admin/resource/quota-mem-cpu.yaml --namespace=quota-mem-cpu-example
+kubectl apply -f https://k8s.io/examples/admin/resource/quota-mem-cpu.yaml --namespace=quota-mem-cpu-example
```
<!--
View detailed information about the ResourceQuota:
-->
-
查看 ResourceQuota 详情：
```shell
@@ -100,7 +86,6 @@ The ResourceQuota places these requirements on the quota-mem-cpu-example namespa
* The CPU request total for all Containers must not exceed 1 cpu.
* The CPU limit total for all Containers must not exceed 2 cpu.
-->
-
ResourceQuota 在 quota-mem-cpu-example 命名空间中设置了如下要求：
* 每个容器必须有内存请求和限制，以及 CPU 请求和限制。
@@ -114,28 +99,24 @@ ResourceQuota 在 quota-mem-cpu-example 命名空间中设置了如下要求：
Here is the configuration file for a Pod:
-->
-
## 创建 Pod
这里给出 Pod 的配置文件：
{{< codenew file="admin/resource/quota-mem-cpu-pod.yaml" >}}
-
<!--
Create the Pod:
-->
-
创建 Pod：
```shell
-kubectl create -f https://k8s.io/examples/admin/resource/quota-mem-cpu-pod.yaml --namespace=quota-mem-cpu-example
+kubectl apply -f https://k8s.io/examples/admin/resource/quota-mem-cpu-pod.yaml --namespace=quota-mem-cpu-example
```
<!--
Verify that the Pod's Container is running:
-->
-
检查下 Pod 中的容器在运行：
```
@@ -145,7 +126,6 @@ kubectl get pod quota-mem-cpu-demo --namespace=quota-mem-cpu-example
<!--
Once again, view detailed information about the ResourceQuota:
-->
-
再查看 ResourceQuota 的详情：
```
@@ -157,7 +137,6 @@ The output shows the quota along with how much of the quota has been used.
You can see that the memory and CPU requests and limits for your Pod do not
exceed the quota.
-->
-
输出结果显示了配额以及有多少配额已经被使用。你可以看到 Pod 的内存和 CPU 请求值及限制值没有超过配额。
```
@@ -179,7 +158,6 @@ status:
Here is the configuration file for a second Pod:
-->
-
## 尝试创建第二个 Pod
这里给出了第二个 Pod 的配置文件：
@@ -194,19 +172,20 @@ request exceeds the memory request quota. 600 MiB + 700 MiB > 1 GiB.
Attempt to create the Pod:
-->
-配置文件中，你可以看到 Pod 的内存请求为700 MiB。请注意新的内存请求与已经使用的内存请求只和超过了内存请求的配额。600 MiB + 700 MiB > 1 GiB。
+配置文件中，你可以看到 Pod 的内存请求为 700 MiB。
+请注意新的内存请求与已经使用的内存请求只和超过了内存请求的配额。
+600 MiB + 700 MiB > 1 GiB。
尝试创建 Pod：
```shell
-kubectl create -f https://k8s.io/examples/admin/resource/quota-mem-cpu-pod-2.yaml --namespace=quota-mem-cpu-example
+kubectl apply -f https://k8s.io/examples/admin/resource/quota-mem-cpu-pod-2.yaml --namespace=quota-mem-cpu-example
```
<!--
The second Pod does not get created. The output shows that creating the second Pod
would cause the memory request total to exceed the memory request quota.
-->
-
第二个 Pod 不能被创建成功。输出结果显示创建第二个 Pod 会导致内存请求总量超过内存请求配额。
```
@@ -225,20 +204,20 @@ You can also restrict the totals for memory limit, cpu request, and cpu limit.
If you want to restrict individual Containers, instead of totals for all Containers, use a
[LimitRange](/docs/tasks/administer-cluster/memory-constraint-namespace/).
-->
-
## 讨论
-如你在本练习中所见，你可以用 ResourceQuota 限制命名空间中所有容器的内存请求总量。同样你也可以限制内存限制总量、CPU 请求总量、CPU 限制总量。
+如你在本练习中所见，你可以用 ResourceQuota 限制命名空间中所有容器的内存请求总量。
+同样你也可以限制内存限制总量、CPU 请求总量、CPU 限制总量。
-如果你想对单个容器而不是所有容器进行限制，就请使用 [LimitRange](/docs/tasks/administer-cluster/memory-constraint-namespace/)。
+如果你想对单个容器而不是所有容器进行限制，就请使用
+[LimitRange](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。
<!--
## Clean up
Delete your namespace:
-->
-
-## 数据清理
+## 清理
删除你的命名空间：
@@ -246,57 +225,38 @@ Delete your namespace:
kubectl delete namespace quota-mem-cpu-example
```
-
-
## {{% heading "whatsnext" %}}
-
<!--
### For cluster administrators
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)
-
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/)
-
* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)
-
* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
-
* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/)
-
* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
-->
### 集群管理员参考
-* [为命名空间配置默认内存请求和限制](/docs/tasks/administer-cluster/memory-default-namespace/)
-
-* [为命名空间配置内存限制的最小值和最大值](/docs/tasks/administer-cluster/memory-constraint-namespace/)
-
-* [为命名空间配置 CPU 限制的最小值和最大值](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
-
-* [为命名空间配置内存和 CPU 配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
-
-* [为命名空间配置 Pod 配额](/docs/tasks/administer-cluster/quota-pod-namespace/)
-
-* [为 API 对象配置配额](/docs/tasks/administer-cluster/quota-api-object/)
+* [为命名空间配置默认内存请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
+* [为命名空间配置内存限制的最小值和最大值](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
+* [为命名空间配置 CPU 限制的最小值和最大值](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
+* [为命名空间配置内存和 CPU 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
+* [为命名空间配置 Pod 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
+* [为 API 对象配置配额](/zh/docs/tasks/administer-cluster/quota-api-object/)
<!--
### For app developers
* [Assign Memory Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/)
-
* [Assign CPU Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/)
-
* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
-->
-
### 应用开发者参考
-* [为容器和 Pod 分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/)
-
-* [为容器和 Pod 分配CPU资源](/docs/tasks/configure-pod-container/assign-cpu-resource/)
-
-* [为 Pod 配置 Service 数量](/docs/tasks/configure-pod-container/quality-service-pod/)
-
+* [为容器和 Pod 分配内存资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)
+* [为容器和 Pod 分配CPU资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/)
+* [为 Pod 配置 Service 数量](/zh/docs/tasks/configure-pod-container/quality-service-pod/)
diff --git a/content/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md b/content/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md
index 7490e4c37d..724a711d00 100644
--- a/content/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md
+++ b/content/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md
@@ -1,28 +1,34 @@
---
-title: 配置命名空间下pod总数
+title: 配置命名空间下 Pod 配额
content_type: task
weight: 60
---
-
<!-- overview -->
-本文主要描述如何配置一个命名空间下可运行的pod总数。资源配额详细信息可查看：[资源配额](/docs/api-reference/v1.7/#resourcequota-v1-core)
-。
-
-
-
+<!--
+This page shows how to set a quota for the total number of Pods that can run
+in a namespace. You specify quotas in a
+[ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core)
+object.
+-->
+本文主要描述如何配置一个命名空间下可运行的 Pod 个数配额。
+你可以使用
+[ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core)
+对象来配置配额。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
-
<!-- steps -->
+<!--
+## Create a namespace
+
+Create a namespace so that the resources you create in this exercise are
+isolated from the rest of your cluster.
+-->
## 创建一个命名空间
首先创建一个命名空间，这样可以将本次操作中创建的资源与集群其他资源隔离开来。
@@ -31,25 +37,39 @@ weight: 60
kubectl create namespace quota-pod-example
```
-## 创建资源配额
+<!--
+## Create a ResourceQuota
-下面是一个资源配额的配置文件：
+Here is the configuration file for a ResourceQuota object:
+-->
+## 创建 ResourceQuota
+
+下面是一个 ResourceQuota 的配置文件：
{{< codenew file="admin/resource/quota-pod.yaml" >}}
-创建这个资源配额：
+<!-- 创建 ResourceQuota: -->
+创建这个 ResourceQuota：
```shell
kubectl apply -f https://k8s.io/examples/admin/resource/quota-pod.yaml --namespace=quota-pod-example
```
+<!--
+View detailed information about the ResourceQuota:
+-->
查看资源配额的详细信息：
```shell
kubectl get resourcequota pod-demo --namespace=quota-pod-example --output=yaml
```
-从输出的信息我们可以看到，该命名空间下pod的配额是2个，目前创建的pods数为0，配额使用率为0。
+<!--
+The output shows that the namespace has a quota of two Pods, and that currently there are
+no Pods; that is, none of the quota is used.
+-->
+从输出的信息我们可以看到，该命名空间下 Pod 的配额是 2 个，目前创建的 Pod 数为 0，
+配额使用率为 0。
```yaml
spec:
@@ -62,25 +82,40 @@ status:
pods: "0"
```
-下面是一个Deployment的配置文件：
+<!--
+Here is the configuration file for a Deployment:
+-->
+下面是一个 Deployment 的配置文件：
{{< codenew file="admin/resource/quota-pod-deployment.yaml" >}}
-在配置文件中， `replicas: 3` 告诉kubernetes尝试创建三个pods，且运行相同的应用。
+<!--
+In the configuration file, `replicas: 3` tells Kubernetes to attempt to create three Pods, all running the same application.
-创建这个Deployment：
+Create the Deployment:
+-->
+在配置文件中，`replicas: 3` 告诉 Kubernetes 尝试创建三个 Pods，且运行相同的应用。
+
+创建这个 Deployment：
```shell
kubectl apply -f https://k8s.io/examples/admin/resource/quota-pod-deployment.yaml --namespace=quota-pod-example
```
-查看Deployment的详细信息：
+<!--
+View detailed information about the Deployment:
+-->
+查看 Deployment 的详细信息：
```shell
kubectl get deployment pod-quota-demo --namespace=quota-pod-example --output=yaml
```
-从输出的信息我们可以看到，尽管尝试创建三个pod，但是由于配额的限制，只有两个pod能被成功创建。
+<!--
+The output shows that even though the Deployment specifies three replicas, only two
+Pods were created because of the quota.
+-->
+从输出的信息我们可以看到，尽管尝试创建三个 Pod，但是由于配额的限制，只有两个 Pod 能被成功创建。
```yaml
spec:
@@ -95,6 +130,11 @@ lastUpdateTime: 2017-07-07T20:57:05Z
exceeded quota: pod-demo, requested: pods=1, used: pods=2, limited: pods=2'
```
+<!--
+## Clean up
+
+Delete your namespace:
+-->
## 清理
删除命名空间：
@@ -103,36 +143,37 @@ lastUpdateTime: 2017-07-07T20:57:05Z
kubectl delete namespace quota-pod-example
```
-
-
## {{% heading "whatsnext" %}}
+<!--
+### For cluster administrators
-### 对于集群管理
-
-* [配置命名空间下，内存默认的request值和limit值](/docs/tasks/administer-cluster/memory-default-namespace/)
-
-* [配置命名空间下，CPU默认的request值和limit值](/docs/tasks/administer-cluster/cpu-default-namespace/)
-
-* [配置命名空间下，内存的最小值和最大值](/docs/tasks/administer-cluster/memory-constraint-namespace/)
-
-* [配置命名空间下，CPU的最小值和最大值](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
-
-* [配置命名空间下，内存和CPU的配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
-
-* [配置命名空间下，API对象的配额](/docs/tasks/administer-cluster/quota-api-object/)
-
-### 对于应用开发
-
-* [给容器和pod分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/)
-
-* [给容器和pod分配CPU资源](/docs/tasks/configure-pod-container/assign-cpu-resource/)
-
-* [配置pod的QoS](/docs/tasks/configure-pod-container/quality-service-pod/)
-
-
+* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
+* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
+* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
+* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
+* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
+* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
+-->
+### 集群管理人员参考
+* [为命名空间配置默认的内存请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
+* [为命名空间配置默认的的 CPU 请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
+* [为命名空间配置内存的最小值和最大值约束](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
+* [为命名空间配置 CPU 的最小值和最大值约束](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
+* [为命名空间配置内存和 CPU 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
+* [为 API 对象的设置配额](/zh/docs/tasks/administer-cluster/quota-api-object/)
+<!--
+### For app developers
+* [Assign Memory Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/)
+* [Assign CPU Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/)
+* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
+-->
+### 应用开发人员参考
+* [为容器和 Pod 分配内存资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)
+* [给容器和 Pod 分配 CPU 资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/)
+* [配置 Pod 的服务质量](/zh/docs/tasks/configure-pod-container/quality-service-pod/)
diff --git a/content/zh/docs/tasks/administer-cluster/namespaces-walkthrough.md b/content/zh/docs/tasks/administer-cluster/namespaces-walkthrough.md
index 5564bec734..db84fcae80 100644
--- a/content/zh/docs/tasks/administer-cluster/namespaces-walkthrough.md
+++ b/content/zh/docs/tasks/administer-cluster/namespaces-walkthrough.md
@@ -1,81 +1,82 @@
---
-reviewers:
-- derekwaynecarr
-- janetkuo
-title: 命名空间演练
+title: 名字空间演练
content_type: task
---
-<!-- ---
+<!--
reviewers:
- derekwaynecarr
- janetkuo
title: Namespaces Walkthrough
content_type: task
---- -->
+-->
<!-- overview -->
-<!-- Kubernetes {{< glossary_tooltip text="namespaces" term_id="namespace" >}}
-help different projects, teams, or customers to share a Kubernetes cluster. -->
-
-Kubernetes {{< glossary_tooltip text="命名空间" term_id="namespace" >}}
+<!--
+Kubernetes {{< glossary_tooltip text="namespaces" term_id="namespace" >}}
+help different projects, teams, or customers to share a Kubernetes cluster.
+-->
+Kubernetes {{< glossary_tooltip text="名字空间" term_id="namespace" >}}
有助于不同的项目、团队或客户去共享 Kubernetes 集群。
-<!-- It does this by providing the following:
+<!--
+It does this by providing the following:
1. A scope for [Names](/docs/concepts/overview/working-with-objects/names/).
-2. A mechanism to attach authorization and policy to a subsection of the cluster. -->
-
+2. A mechanism to attach authorization and policy to a subsection of the cluster.
+-->
名字空间通过以下方式实现这点：
-1. 为[名字](/docs/concepts/overview/working-with-objects/names/)设置作用域.
+1. 为[名字](/zh/docs/concepts/overview/working-with-objects/names/)设置作用域.
2. 为集群中的部分资源关联鉴权和策略的机制。
-<!-- Use of multiple namespaces is optional. -->
-
-使用多个命名空间是可选的。
-
-<!-- This example demonstrates how to use Kubernetes namespaces to subdivide your cluster. -->
-
-此示例演示了如何使用 Kubernetes 命名空间细分群集。
-
+<!--
+Use of multiple namespaces is optional.
+This example demonstrates how to use Kubernetes namespaces to subdivide your cluster.
+-->
+使用多个名字空间是可选的。
+此示例演示了如何使用 Kubernetes 名字空间细分群集。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
<!-- steps -->
-<!-- ## Prerequisites -->
+<!--
+## Prerequisites
-## 环境准备
-
-<!-- This example assumes the following:
+This example assumes the following:
1. You have an [existing Kubernetes cluster](/docs/setup/).
-2. You have a basic understanding of Kubernetes _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, and _[Deployments](/docs/concepts/workloads/controllers/deployment/)_. -->
+2. You have a basic understanding of Kubernetes _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, and _[Deployments](/docs/concepts/workloads/controllers/deployment/)_.
+-->
+## 环境准备
此示例作如下假设：
-1. 您已拥有一个 [配置好的 Kubernetes 集群](/docs/setup/)。
-2. 您已对 Kubernetes 的 _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_ 和 _[Deployments](/docs/concepts/workloads/controllers/deployment/)_ 有基本理解。
+1. 你已拥有一个[配置好的 Kubernetes 集群](/zh/docs/setup/)。
+2. 你已对 Kubernetes 的 _[Pods](/zh/docs/concepts/workloads/pods/)_、
+ _[Services](/zh/docs/concepts/services-networking/service/)_ 和
+ _[Deployments](/zh/docs/concepts/workloads/controllers/deployment/)_
+ 有基本理解。
-<!-- ## Understand the default namespace
+<!--
+## Understand the default namespace
By default, a Kubernetes cluster will instantiate a default namespace when provisioning the cluster to hold the default set of Pods,
-Services, and Deployments used by the cluster. -->
+Services, and Deployments used by the cluster.
+-->
+1. 理解默认名字空间
-1. 理解默认命名空间
+默认情况下，Kubernetes 集群会在配置集群时实例化一个默认名字空间，用以存放集群所使用的默认
+Pod、Service 和 Deployment 集合。
-默认情况下，Kubernetes 集群会在配置集群时实例化一个默认命名空间，用以存放集群所使用的默认 Pods、Services 和 Deployments 集合。
-
-<!-- Assuming you have a fresh cluster, you can inspect the available namespaces by doing the following: -->
-
-假设您有一个新的集群，您可以通过执行以下操作来检查可用的命名空间：
+<!--
+Assuming you have a fresh cluster, you can inspect the available namespaces by doing the following:
+-->
+假设你有一个新的集群，你可以通过执行以下操作来检查可用的名字空间：
```shell
kubectl get namespaces
@@ -85,72 +86,89 @@ NAME STATUS AGE
default Active 13m
```
-<!-- ## Create new namespaces -->
+<!--
+## Create new namespaces
-## 创建新的命名空间
+For this exercise, we will create two additional Kubernetes namespaces to hold our content.
+-->
+## 创建新的名字空间
-<!-- For this exercise, we will create two additional Kubernetes namespaces to hold our content. -->
-
-在本练习中，我们将创建两个额外的 Kubernetes 命名空间来保存我们的内容。
-
-<!-- Let's imagine a scenario where an organization is using a shared Kubernetes cluster for development and production use cases. -->
+在本练习中，我们将创建两个额外的 Kubernetes 名字空间来保存我们的内容。
+<!--
+Let's imagine a scenario where an organization is using a shared Kubernetes cluster for development and production use cases.
+-->
我们假设一个场景，某组织正在使用共享的 Kubernetes 集群来支持开发和生产：
-<!-- The development team would like to maintain a space in the cluster where they can get a view on the list of Pods, Services, and Deployments
+<!--
+The development team would like to maintain a space in the cluster where they can get a view on the list of Pods, Services, and Deployments
they use to build and run their application. In this space, Kubernetes resources come and go, and the restrictions on who can or cannot modify resources
-are relaxed to enable agile development. -->
+are relaxed to enable agile development.
+-->
+开发团队希望在集群中维护一个空间，以便他们可以查看用于构建和运行其应用程序的 Pod、Service
+和 Deployment 列表。在这个空间里，Kubernetes 资源被自由地加入或移除，
+对谁能够或不能修改资源的限制被放宽，以实现敏捷开发。
-开发团队希望在集群中维护一个空间，以便他们可以查看用于构建和运行其应用程序的 Pods、Services 和 Deployments 列表。在这个空间里，Kubernetes 资源被自由地加入或移除，对谁能够或不能修改资源的限制被放宽，以实现敏捷开发。
+<!--
+The operations team would like to maintain a space in the cluster where they can enforce strict procedures on who can or cannot manipulate the set of
+Pods, Services, and Deployments that run the production site.
+-->
+运维团队希望在集群中维护一个空间，以便他们可以强制实施一些严格的规程，
+对谁可以或谁不可以操作运行生产站点的 Pod、Service 和 Deployment 集合进行控制。
-<!-- The operations team would like to maintain a space in the cluster where they can enforce strict procedures on who can or cannot manipulate the set of
-Pods, Services, and Deployments that run the production site. -->
+<!--
+One pattern this organization could follow is to partition the Kubernetes cluster into two namespaces: `development` and `production`.
+-->
+该组织可以遵循的一种模式是将 Kubernetes 集群划分为两个名字空间：`development` 和 `production`。
-运维团队希望在集群中维护一个空间，以便他们可以强制实施一些严格的规程，对谁可以或谁不可以操作运行生产站点的 Pods、Services 和 Deployments 集合进行控制。
+<!--
+Let's create two new namespaces to hold our work.
+-->
+让我们创建两个新的名字空间来保存我们的工作。
-<!-- One pattern this organization could follow is to partition the Kubernetes cluster into two namespaces: `development` and `production`. -->
-
-该组织可以遵循的一种模式是将 Kubernetes 集群划分为两个命名空间：development 和 production。
-
-<!-- Let's create two new namespaces to hold our work. -->
-
-让我们创建两个新的命名空间来保存我们的工作。
-
-<!-- Use the file [`namespace-dev.json`](/examples/admin/namespace-dev.json) which describes a `development` namespace: -->
-
-文件 [`namespace-dev.json`](/examples/admin/namespace-dev.json) 描述了 development 命名空间:
+<!--
+Use the file [`namespace-dev.json`](/examples/admin/namespace-dev.json) which describes a `development` namespace:
+-->
+文件 [`namespace-dev.json`](/examples/admin/namespace-dev.json) 描述了 `development` 名字空间:
{{< codenew language="json" file="admin/namespace-dev.json" >}}
-<!-- Create the `development` namespace using kubectl. -->
+<!--
+Create the `development` namespace using kubectl.
+-->
-使用 kubectl 创建 development 命名空间。
+使用 kubectl 创建 `development` 名字空间。
```shell
kubectl create -f https://k8s.io/examples/admin/namespace-dev.json
```
-<!-- Save the following contents into file [`namespace-prod.json`](/examples/admin/namespace-prod.json) which describes a `production` namespace: -->
-
-将下列的内容保存到文件 [`namespace-prod.json`](/examples/admin/namespace-prod.json) 中，这些内容是对 production 命名空间的描述：
+<!--
+Save the following contents into file [`namespace-prod.json`](/examples/admin/namespace-prod.json) which describes a `production` namespace:
+-->
+将下列的内容保存到文件 [`namespace-prod.json`](/examples/admin/namespace-prod.json) 中，
+这些内容是对 `production` 名字空间的描述：
{{< codenew language="json" file="admin/namespace-prod.json" >}}
-<!-- And then let's create the `production` namespace using kubectl. -->
-
-让我们使用 kubectl 创建 production 命名空间。
+<!--
+And then let's create the `production` namespace using kubectl.
+-->
+让我们使用 kubectl 创建 `production` 名字空间。
```shell
kubectl create -f https://k8s.io/examples/admin/namespace-prod.json
```
-<!-- To be sure things are right, let's list all of the namespaces in our cluster. -->
-
-为了确保一切正常，我们列出集群中的所有命名空间。
+<!--
+To be sure things are right, let's list all of the namespaces in our cluster.
+-->
+为了确保一切正常，我们列出集群中的所有名字空间。
```shell
kubectl get namespaces --show-labels
```
+
```
NAME STATUS AGE LABELS
default Active 32m <none>
@@ -158,29 +176,32 @@ development Active 29s name=development
production Active 23s name=production
```
-<!-- ## Create pods in each namespace -->
+<!--
+## Create pods in each namespace
-## 在每个命名空间中创建 pod
+A Kubernetes namespace provides the scope for Pods, Services, and Deployments in the cluster.
-<!-- A Kubernetes namespace provides the scope for Pods, Services, and Deployments in the cluster.
+Users interacting with one namespace do not see the content in another namespace.
-Users interacting with one namespace do not see the content in another namespace. -->
+To demonstrate this, let's spin up a simple Deployment and Pods in the `development` namespace.
+-->
+## 在每个名字空间中创建 pod
-Kubernetes 命名空间为集群中的 Pods、Services 和 Deployments 提供了作用域。
+Kubernetes 名字空间为集群中的 Pod、Service 和 Deployment 提供了作用域。
-与一个命名空间交互的用户不会看到另一个命名空间中的内容。
+与一个名字空间交互的用户不会看到另一个名字空间中的内容。
-<!-- To demonstrate this, let's spin up a simple Deployment and Pods in the `development` namespace. -->
-
-为了演示这一点，让我们在 development 命名空间中启动一个简单的 Deployment 和 Pod。
-
-<!-- We first check what is the current context: -->
+为了演示这一点，让我们在 development 名字空间中启动一个简单的 Deployment 和 Pod。
+<!--
+We first check what is the current context:
+-->
我们首先检查一下当前的上下文：
```shell
kubectl config view
```
+
```yaml
apiVersion: v1
clusters:
@@ -207,6 +228,7 @@ users:
password: h5M0FtUUIflBSdI7
username: admin
```
+
```shell
kubectl config current-context
```
@@ -214,9 +236,11 @@ kubectl config current-context
lithe-cocoa-92103_kubernetes
```
-<!-- The next step is to define a context for the kubectl client to work in each namespace. The value of "cluster" and "user" fields are copied from the current context. -->
-
-下一步是为 kubectl 客户端定义一个上下文，以便在每个命名空间中工作。"cluster" 和 "user" 字段的值将从当前上下文中复制。
+<!--
+The next step is to define a context for the kubectl client to work in each namespace. The value of "cluster" and "user" fields are copied from the current context.
+-->
+下一步是为 kubectl 客户端定义一个上下文，以便在每个名字空间中工作。
+"cluster" 和 "user" 字段的值将从当前上下文中复制。
```shell
kubectl config set-context dev --namespace=development \
@@ -228,15 +252,17 @@ kubectl config set-context prod --namespace=production \
--user=lithe-cocoa-92103_kubernetes
```
-<!-- By default, the above commands adds two contexts that are saved into file
+<!--
+By default, the above commands adds two contexts that are saved into file
`.kube/config`. You can now view the contexts and alternate against the two
-new request contexts depending on which namespace you wish to work against. -->
-
-默认地，上述命令会添加两个上下文到 `.kube/config` 文件中。
-您现在可以查看上下文并根据您希望使用的命名空间并在这两个新的请求上下文之间切换。
-
-<!-- To view the new contexts: -->
+new request contexts depending on which namespace you wish to work against.
+-->
+默认情况下，上述命令会添加两个上下文到 `.kube/config` 文件中。
+你现在可以查看上下文并根据你希望使用的名字空间并在这两个新的请求上下文之间切换。
+<!--
+To view the new contexts:
+-->
查看新的上下文：
```shell
@@ -279,41 +305,50 @@ users:
username: admin
```
-<!-- Let's switch to operate in the `development` namespace. -->
-
-让我们切换到 development 命名空间进行操作。
+<!--
+Let's switch to operate in the `development` namespace.
+-->
+让我们切换到 `development` 名字空间进行操作。
```shell
kubectl config use-context dev
```
-<!-- You can verify your current context by doing the following: -->
-
-您可以使用下列命令验证当前上下文：
+<!--
+You can verify your current context by doing the following:
+-->
+你可以使用下列命令验证当前上下文：
```shell
kubectl config current-context
```
+
```
dev
```
-<!-- At this point, all requests we make to the Kubernetes cluster from the command line are scoped to the `development` namespace. -->
-
-此时，我们从命令行向 Kubernetes 集群发出的所有请求都限定在 development 命名空间中。
-
-<!-- Let's create some contents. -->
+<!--
+At this point, all requests we make to the Kubernetes cluster from the command line are scoped to the `development` namespace.
+-->
+此时，我们从命令行向 Kubernetes 集群发出的所有请求都限定在 `development` 名字空间中。
+<!--
+Let's create some contents.
+-->
让我们创建一些内容。
-```shell
-kubectl run snowflake --image=k8s.gcr.io/serve_hostname --replicas=2
-```
-<!-- We have just created a deployment whose replica size is 2 that is running the pod called `snowflake` with a basic container that just serves the hostname.
-Note that `kubectl run` creates deployments only on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead.
-If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) for more details. -->
+{{< codenew file="admin/snowflake-deployment.yaml" >}}
-我们刚刚创建了一个副本大小为 2 的 deployment，该 deployment 运行名为 snowflake 的 pod，其中包含一个仅提供主机名服务的基本容器。请注意，`kubectl run` 仅在 Kubernetes 集群版本 >= v1.2 时创建 deployment。如果您运行在旧版本上，则会创建 replication controller。如果期望执行旧版本的行为，请使用 `--generator=run/v1` 创建 replication controller。 参见 [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) 获取更多细节。
+<!--
+Apply the manifest to create a Deployment
+-->
+应用清单文件来创建 Deployment。
+
+<!--
+We have just created a deployment whose replica size is 2 that is running the pod called `snowflake` with a basic container that just serves the hostname.
+-->
+我们刚刚创建了一个副本大小为 2 的 Deployment，该 Deployment 运行名为 `snowflake` 的 Pod，
+其中包含一个仅提供主机名服务的基本容器。
```shell
kubectl get deployment
@@ -324,7 +359,7 @@ snowflake 2 2 2 2 2m
```
```shell
-kubectl get pods -l run=snowflake
+kubectl get pods -l app=snowflake
```
```
NAME READY STATUS RESTARTS AGE
@@ -332,41 +367,51 @@ snowflake-3968820950-9dgr8 1/1 Running 0 2m
snowflake-3968820950-vgc4n 1/1 Running 0 2m
```
-<!-- And this is great, developers are able to do what they want, and they do not have to worry about affecting content in the `production` namespace. -->
+<!--
+And this is great, developers are able to do what they want, and they do not have to worry about affecting content in the `production` namespace.
+-->
+这很棒，开发人员可以做他们想要的事情，而不必担心影响 `production` 名字空间中的内容。
-这很棒，开发人员可以做他们想要的事情，而不必担心影响 production 命名空间中的内容。
-
-<!-- Let's switch to the `production` namespace and show how resources in one namespace are hidden from the other. -->
-
-让我们切换到 production 命名空间，展示一个命名空间中的资源如何对另一个命名空间不可见。
+<!--
+Let's switch to the `production` namespace and show how resources in one namespace are hidden from the other.
+-->
+让我们切换到 `production` 名字空间，展示一个名字空间中的资源如何对另一个名字空间不可见。
```shell
kubectl config use-context prod
```
-<!-- The `production` namespace should be empty, and the following commands should return nothing. -->
-
-`production` 命名空间应该是空的，下列命令应该返回的内容为空。
+<!--
+The `production` namespace should be empty, and the following commands should return nothing.
+-->
+`production` 名字空间应该是空的，下列命令应该返回的内容为空。
```shell
kubectl get deployment
kubectl get pods
```
-<!-- Production likes to run cattle, so let's create some cattle pods. -->
-
-生产环境需要运行 cattle，让我们创建一些名为 cattle 的 pods。
+<!--
+Production likes to run cattle, so let's create some cattle pods.
+-->
+生产环境需要以放牛的方式运维，让我们创建一些名为 `cattle` 的 Pod。
```shell
-kubectl run cattle --image=k8s.gcr.io/serve_hostname --replicas=5
+kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname
+kubectl scale deployment cattle --replicas=5
kubectl get deployment
```
+
```
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
cattle 5 5 5 5 10s
+```
+```shell
kubectl get pods -l run=cattle
+```
+```
NAME READY STATUS RESTARTS AGE
cattle-2263376956-41xy6 1/1 Running 0 34s
cattle-2263376956-kw466 1/1 Running 0 34s
@@ -375,13 +420,14 @@ cattle-2263376956-p5p3i 1/1 Running 0 34s
cattle-2263376956-sxpth 1/1 Running 0 34s
```
-<!-- At this point, it should be clear that the resources users create in one namespace are hidden from the other namespace. -->
-
-此时，应该很清楚的展示了用户在一个命名空间中创建的资源对另一个命名空间是不可见的。
-
-<!-- As the policy support in Kubernetes evolves, we will extend this scenario to show how you can provide different
-authorization rules for each namespace. -->
-
-随着 Kubernetes 中的策略支持的发展，我们将扩展此场景，以展示如何为每个命名空间提供不同的授权规则。
+<!--
+At this point, it should be clear that the resources users create in one namespace are hidden from the other namespace.
+-->
+此时，应该很清楚的展示了用户在一个名字空间中创建的资源对另一个名字空间是不可见的。
+<!--
+As the policy support in Kubernetes evolves, we will extend this scenario to show how you can provide different
+authorization rules for each namespace.
+-->
+随着 Kubernetes 中的策略支持的发展，我们将扩展此场景，以展示如何为每个名字空间提供不同的授权规则。
diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md
index 4abb9ad1b9..1089591a98 100644
--- a/content/zh/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md
+++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md
@@ -1,53 +1,38 @@
---
-reviewers:
-- caseydavenport
-title: 使用 Calico 作为 NetworkPolicy
+title: 使用 Calico 提供 NetworkPolicy
content_type: task
weight: 10
---
<!-- overview -->
-<!-- This page shows a couple of quick ways to create a Calico cluster on Kubernetes. -->
-本页展示了两种在 Kubernetes 上快速创建 Calico 集群的方法。
-
+<!--
+This page shows a couple of quick ways to create a Calico cluster on Kubernetes.
+-->
+本页展示了几种在 Kubernetes 上快速创建 Calico 集群的方法。
## {{% heading "prerequisites" %}}
-<!-- Decide whether you want to deploy a [cloud](#creating-a-calico-cluster-with-google-kubernetes-engine-gke) or [local](#creating-a-local-calico-cluster-with-kubeadm) cluster. -->
-
-决定您想部署一个[云](#在-Google-Kubernetes-Engine-GKE-上创建一个-Calico-集群) 还是 [本地](#使用-kubeadm-创建一个本地-Calico-集群) 集群。
-
+<!--
+Decide whether you want to deploy a [cloud](#creating-a-calico-cluster-with-google-kubernetes-engine-gke) or [local](#creating-a-local-calico-cluster-with-kubeadm) cluster.
+-->
+确定你想部署一个[云版本](#gke-cluster)还是[本地版本](#local-cluster)的集群。
<!-- steps -->
-<!-- ## Creating a Calico cluster with Google Kubernetes Engine (GKE)
+
+<!--
+## Creating a Calico cluster with Google Kubernetes Engine (GKE)
**Prerequisite**: [gcloud](https://cloud.google.com/sdk/docs/quickstarts).
-
-1. To launch a GKE cluster with Calico, just include the `--enable-network-policy` flag.
-
- **Syntax**
- ```shell
- gcloud container clusters create [CLUSTER_NAME] --enable-network-policy
- ```
-
- **Example**
- ```shell
- gcloud container clusters create my-calico-cluster --enable-network-policy
- ```
-
-1. To verify the deployment, use the following command.
-
- ```shell
- kubectl get pods --namespace=kube-system
- ```
-
- The Calico pods begin with `calico`. Check to make sure each one has a status of `Running`.
- -->
-## 在 Google Kubernetes Engine (GKE) 上创建一个 Calico 集群
+-->
+## 在 Google Kubernetes Engine (GKE) 上创建一个 Calico 集群 {#gke-cluster}
**先决条件**: [gcloud](https://cloud.google.com/sdk/docs/quickstarts)
-1. 启动一个带有 Calico 的 GKE 集群，只需加上flag `--enable-network-policy`。
+<!--
+1. To launch a GKE cluster with Calico, just include the `--enable-network-policy` flag.
+-->
+1. To launch a GKE cluster with Calico, just include the `--enable-network-policy` flag.
+1. 启动一个带有 Calico 的 GKE 集群，只需加上参数 `--enable-network-policy`。
**语法**
```shell
@@ -59,33 +44,36 @@ weight: 10
gcloud container clusters create my-calico-cluster --enable-network-policy
```
-1. 使用如下命令验证部署是否正确。
+<!--
+1. To verify the deployment, use the following command.
+-->
+2. 使用如下命令验证部署是否正确。
```shell
kubectl get pods --namespace=kube-system
```
+ <!--
+ The Calico pods begin with `calico`. Check to make sure each one has a status of `Running`.
+ -->
Calico 的 pods 名以 `calico` 打头，检查确认每个 pods 状态为 `Running`。
-
-<!--
+<!--
## Creating a local Calico cluster with kubeadm
To get a local single-host Calico cluster in fifteen minutes using kubeadm, refer to the
[Calico Quickstart](https://docs.projectcalico.org/latest/getting-started/kubernetes/).
-
-->
+## 使用 kubeadm 创建一个本地 Calico 集群 {#local-cluster}
-## 使用 kubeadm 创建一个本地 Calico 集群
-
-在15分钟内使用 kubeadm 得到一个本地单主机 Calico 集群，请参考
+使用 kubeadm 在 15 分钟内得到一个本地单主机 Calico 集群，请参考
[Calico 快速入门](https://docs.projectcalico.org/latest/getting-started/kubernetes/)。
-
-
-
## {{% heading "whatsnext" %}}
-<!-- Once your cluster is running, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. -->
-集群运行后，您可以按照 [声明 Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) 去尝试使用 Kubernetes NetworkPolicy。
+<!--
+Once your cluster is running, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy.
+-->
+集群运行后，您可以按照[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/)
+去尝试使用 Kubernetes NetworkPolicy。
diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
index 151985e4bc..5f2724bbad 100644
--- a/content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
+++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
@@ -1,30 +1,25 @@
---
-reviewers:
-- danwent
-title: 使用 Cilium 作为 NetworkPolicy
+title: 使用 Cilium 提供 NetworkPolicy
content_type: task
weight: 20
---
<!-- overview -->
-<!-- This page shows how to use Cilium for NetworkPolicy.
+<!--
+This page shows how to use Cilium for NetworkPolicy.
-For background on Cilium, read the [Introduction to Cilium](https://cilium.readthedocs.io/en/latest/intro). -->
-
-本页展示了如何使用 Cilium 作为 NetworkPolicy。
+For background on Cilium, read the [Introduction to Cilium](https://cilium.readthedocs.io/en/latest/intro).
+-->
+本页展示如何使用 Cilium 提供 NetworkPolicy。
关于 Cilium 的背景知识，请阅读 [Cilium 介绍](https://cilium.readthedocs.io/en/latest/intro)。
-
-
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
<!-- steps -->
+
<!--
## Deploying Cilium on Minikube for Basic Testing
@@ -32,32 +27,68 @@ To get familiar with Cilium easily you can follow the
[Cilium Kubernetes Getting Started Guide](https://docs.cilium.io/en/latest/gettingstarted/minikube/)
to perform a basic DaemonSet installation of Cilium in minikube.
-Installation in a minikube setup uses a simple ''all-in-one'' YAML
-file that includes DaemonSet configurations for Cilium, to connect
-to the minikube's etcd instance as well as appropriate RBAC settings:
- -->
-
+To start minikube, minimal version required is >= v1.3.1, run the with the
+following arguments:
+-->
## 在 Minikube 上部署 Cilium 用于基本测试
-为了轻松熟悉 Cilium 您可以根据[Cilium Kubernetes 入门指南](https://docs.cilium.io/en/latest/gettingstarted/minikube/)在 minikube 中执行一个 cilium 的基本的 DaemonSet 安装。
+为了轻松熟悉 Cilium 你可以根据
+[Cilium Kubernetes 入门指南](https://docs.cilium.io/en/latest/gettingstarted/minikube/)
+在 minikube 中执行一个 cilium 的基本 DaemonSet 安装。
-在 minikube 中的安装配置使用一个简单的“一体化” YAML 文件，包括了 Cilium 的 DaemonSet 配置，连接 minikube 的 etcd 实例，以及适当的 RBAC 设置。
+要启动 minikube，需要的最低版本为 1.3.1，使用下面的参数运行：
```shell
-$ kubectl create -f https://raw.githubusercontent.com/cilium/cilium/master/examples/kubernetes/cilium.yaml
-configmap "cilium-config" created
-secret "cilium-etcd-secrets" created
-serviceaccount "cilium" created
-clusterrolebinding "cilium" created
-daemonset "cilium" created
-clusterrole "cilium" created
+minikube version
```
+```
+minikube version: v1.3.1
+```
+
+```shell
+minikube start --network-plugin=cni --memory=4096
+```
+
+<!--
+Mount the BPF filesystem:
+-->
+挂载 BPF 文件系统：
+
+```shell
+minikube ssh -- sudo mount bpffs -t bpf /sys/fs/bpf
+```
+
+<!--
+For minikube you can deploy this simple ''all-in-one'' YAML file that includes
+DaemonSet configurations for Cilium as well as appropriate RBAC settings:
+-->
+在 minikube 环境中，你可以部署下面的"一体化" YAML 文件，其中包含 Cilium
+的 DaemonSet 配置以及适当的 RBAC 配置：
+
+
+```shell
+kubectl create -f https://raw.githubusercontent.com/cilium/cilium/master/examples/kubernetes/cilium.yaml
+```
+
+```
+configmap/cilium-config created
+serviceaccount/cilium created
+serviceaccount/cilium-operator created
+clusterrole.rbac.authorization.k8s.io/cilium created
+clusterrole.rbac.authorization.k8s.io/cilium-operator created
+clusterrolebinding.rbac.authorization.k8s.io/cilium created
+clusterrolebinding.rbac.authorization.k8s.io/cilium-operator created
+daemonset.apps/cilium create
+deployment.apps/cilium-operator created
+```
+
<!--
The remainder of the Getting Started Guide explains how to enforce both L3/L4
(i.e., IP address + port) security policies, as well as L7 (e.g., HTTP) security
policies using an example application.
-->
-入门指南其余的部分用一个示例应用说明了如何强制执行L3/L4（即 IP 地址+端口）的安全策略以及L7 （如 HTTP）的安全策略。
+入门指南其余的部分用一个示例应用说明了如何强制执行 L3/L4（即 IP 地址+端口）的安全策略
+以及L7 （如 HTTP）的安全策略。
<!--
## Deploying Cilium for Production Use
@@ -67,14 +98,14 @@ For detailed instructions around deploying Cilium for production, see:
This documentation includes detailed requirements, instructions and example
production DaemonSet files.
-->
-
## 部署 Cilium 用于生产用途
-关于部署 Cilium 用于生产的详细说明，请见[Cilium Kubernetes 安装指南](https://cilium.readthedocs.io/en/latest/gettingstarted/#installation)
-，此文档包括详细的需求、说明和生产用途 DaemonSet 文件示例。
-
+关于部署 Cilium 用于生产的详细说明，请见
+[Cilium Kubernetes 安装指南](https://cilium.readthedocs.io/en/latest/gettingstarted/#installation)，
+此文档包括详细的需求、说明和生产用途 DaemonSet 文件示例。
<!-- discussion -->
+
<!--
## Understanding Cilium components
@@ -83,53 +114,40 @@ this list of Pods run:
-->
## 了解 Cilium 组件
-部署使用 Cilium 的集群会添加 Pods 到`kube-system`命名空间。 要查看此Pod列表，运行：
+部署使用 Cilium 的集群会添加 Pods 到 `kube-system` 命名空间。要查看 Pod 列表，运行：
```shell
kubectl get pods --namespace=kube-system
```
<!-- You'll see a list of Pods similar to this: -->
-您将看到像这样的 Pods 列表：
+你将看到像这样的 Pods 列表：
```console
-NAME DESIRED CURRENT READY NODE-SELECTOR AGE
-cilium 1 1 1 <none> 2m
+NAME READY STATUS RESTARTS AGE
+cilium-6rxbd 1/1 Running 0 1m
...
```
+
<!--
-There are two main components to be aware of:
-
-- One `cilium` Pod runs on each node in your cluster and enforces network policy
+A `cilium` Pod runs on each node in your cluster and enforces network policy
on the traffic to/from Pods on that node using Linux BPF.
-- For production deployments, Cilium should leverage the key-value store cluster
-(e.g., etcd) used by Kubernetes, which typically runs on the Kubernetes master nodes.
-The [Cilium Kubernetes Installation Guide](https://cilium.readthedocs.io/en/latest/gettingstarted/#installation)
-includes an example DaemonSet which can be customized to point to this key-value
-store cluster. The simple ''all-in-one'' DaemonSet for minikube requires no such
-configuration because it automatically connects to the minikube's etcd instance.
- -->
-有两个主要组件需要注意：
-
-- 在集群中的每个节点上都会运行一个 `cilium` Pod，并利用Linux BPF执行网络策略管理该节点上进出 Pod 的流量。
-- 对于生产部署，Cilium 应该复用 Kubernetes 所使用的键值存储集群（如 etcd），其通常在Kubernetes 的 master 节点上运行。
-[Cilium Kubernetes安装指南](https://cilium.readthedocs.io/en/latest/gettingstarted/#installation)
-包括了一个示例 DaemonSet，可以自定义指定此键值存储集群。
-简单的 minikube 的“一体化” DaemonSet 不需要这样的配置，因为它会自动连接到 minikube 的 etcd 实例。
-
-
+-->
+你的集群中的每个节点上都会运行一个 `cilium` Pod，通过使用 Linux BPF
+针对该节点上的 Pod 的入站、出站流量实施网络策略控制。
## {{% heading "whatsnext" %}}
-<!-- Once your cluster is running, you can follow the
+<!--
+Once your cluster is running, you can follow the
[Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/)
to try out Kubernetes NetworkPolicy with Cilium.
Have fun, and if you have questions, contact us using the
-[Cilium Slack Channel](https://cilium.herokuapp.com/). -->
-群集运行后，您可以按照[声明网络策略](/docs/tasks/administer-cluster/declare-network-policy/)
-用 Cilium 试用 Kubernetes NetworkPolicy。
-玩得开心，如果您有任何疑问，请联系我们
-[Cilium Slack Channel](https://cilium.herokuapp.com/)。
-
-
+[Cilium Slack Channel](https://cilium.herokuapp.com/).
+-->
+集群运行后，你可以按照
+[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/)
+试用基于 Cilium 的 Kubernetes NetworkPolicy。
+玩得开心，如果你有任何疑问，请到 [Cilium Slack 频道](https://cilium.herokuapp.com/)
+联系我们。
diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md
index 7c4fb19240..5e7ae8f98d 100644
--- a/content/zh/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md
+++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md
@@ -1,33 +1,42 @@
---
-reviewers:
-- murali-reddy
-title: 使用 Kube-router 作为 NetworkPolicy
+title: 使用 kube-router 提供 NetworkPolicy
content_type: task
weight: 30
---
<!-- overview -->
-<!-- This page shows how to use [Kube-router](https://github.com/cloudnativelabs/kube-router) for NetworkPolicy. -->
-本页展示了如何使用 [Kube-router](https://github.com/cloudnativelabs/kube-router) 作为 NetworkPolicy。
+<!--
+This page shows how to use [Kube-router](https://github.com/cloudnativelabs/kube-router) for NetworkPolicy.
+-->
+本页展示如何使用 [Kube-router](https://github.com/cloudnativelabs/kube-router) 提供 NetworkPolicy。
## {{% heading "prerequisites" %}}
-<!-- You need to have a Kubernetes cluster running. If you do not already have a cluster, you can create one by using any of the cluster installers like Kops, Bootkube, Kubeadm etc. -->
-
-您需要拥有一个正在运行的 Kubernetes 集群。如果您还没有集群，可以使用任意的集群安装器如 Kops，Bootkube，Kubeadm 等创建一个。
-
+<!--
+You need to have a Kubernetes cluster running. If you do not already have a cluster, you can create one by using any of the cluster installers like Kops, Bootkube, Kubeadm etc.
+-->
+你需要拥有一个运行中的 Kubernetes 集群。如果你还没有集群，可以使用任意的集群
+安装程序如 Kops、Bootkube、Kubeadm 等创建一个。
<!-- steps -->
-<!-- ## Installing Kube-router addon
-The Kube-router Addon comes with a Network Policy Controller that watches Kubernetes API server for any NetworkPolicy and pods updated and configures iptables rules and ipsets to allow or block traffic as directed by the policies. Please follow the [trying Kube-router with cluster installers](https://www.kube-router.io/docs/user-guide/#try-kube-router-with-cluster-installers) guide to install Kube-router addon. -->
+<!--
+## Installing Kube-router addon
-## 安装 Kube-router 插件
-Kube-router 插件自带一个Network Policy 控制器，监视来自于Kubernetes API server 的 NetworkPolicy 和 pods 的变化，根据策略指示配置 iptables 规则和 ipsets 来允许或阻止流量。请根据 [尝试通过集群安装器使用 Kube-router](https://www.kube-router.io/docs/user-guide/#try-kube-router-with-cluster-installers) 指南安装 Kube-router 插件。
+The Kube-router Addon comes with a Network Policy Controller that watches Kubernetes API server for any NetworkPolicy and pods updated and configures iptables rules and ipsets to allow or block traffic as directed by the policies. Please follow the [trying Kube-router with cluster installers](https://www.kube-router.io/docs/user-guide/#try-kube-router-with-cluster-installers) guide to install Kube-router addon.
+-->
+## 安装 kube-router 插件
+kube-router 插件自带一个网络策略控制器，监视来自于 Kubernetes API 服务器的
+NetworkPolicy 和 Pod 的变化，根据策略指示配置 iptables 规则和 ipsets 来允许或阻止流量。
+请根据 [通过集群安装程序尝试 kube-router](https://www.kube-router.io/docs/user-guide/#try-kube-router-with-cluster-installers) 指南安装 kube-router 插件。
## {{% heading "whatsnext" %}}
-<!-- Once you have installed the Kube-router addon, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. -->
-在您安装 Kube-router 插件后，可以根据 [声明 Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) 去尝试使用 Kubernetes NetworkPolicy。
+<!--
+Once you have installed the Kube-router addon, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy.
+-->
+在你安装了 kube-router 插件后，可以参考
+[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/)
+去尝试使用 Kubernetes NetworkPolicy。
diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
index e355e9c547..ca64910989 100644
--- a/content/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
+++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
@@ -1,7 +1,5 @@
---
-reviewers:
-- chrismarino
-title: 使用 Romana 作为 NetworkPolicy
+title: 使用 Romana 提供 NetworkPolicy
content_type: task
weight: 40
---
@@ -11,15 +9,10 @@ weight: 40
<!-- This page shows how to use Romana for NetworkPolicy. -->
本页展示如何使用 Romana 作为 NetworkPolicy。
-
-
## {{% heading "prerequisites" %}}
-
<!-- Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/). -->
-完成[kubeadm 入门指南](/docs/getting-started-guides/kubeadm/)中的1、2、3步。
-
-
+完成 [kubeadm 入门指南](/zh/docs/reference/setup-tools/kubeadm/kubeadm/)中的 1、2、3 步。
<!-- steps -->
<!--
@@ -37,23 +30,22 @@ To apply network policies use one of the following:
-->
## 使用 kubeadm 安装 Romana
-按照[容器化安装指南](https://github.com/romana/romana/tree/master/containerize)获取 kubeadm。
+按照[容器化安装指南](https://github.com/romana/romana/tree/master/containerize)，使用 kubeadm 安装。
-## 运用网络策略
+## 应用网络策略
-使用以下的一种方式去运用网络策略：
+使用以下的一种方式应用网络策略：
* [Romana 网络策略](https://github.com/romana/romana/wiki/Romana-policies)
* [Romana 网络策略例子](https://github.com/romana/core/blob/master/doc/policy.md)
* NetworkPolicy API
-
-
## {{% heading "whatsnext" %}}
<!--
Once you have installed Romana, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy.
-->
-Romana 安装完成后，您可以按照[声明 Network Policy](/docs/tasks/administer-cluster/declare-network-policy/)去尝试使用 Kubernetes NetworkPolicy。
-
+Romana 安装完成后，你可以按照
+[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/)
+去尝试使用 Kubernetes NetworkPolicy。
diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md
index 5e7b4baaba..251f28f7bf 100644
--- a/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md
+++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md
@@ -1,28 +1,28 @@
---
-reviewers:
-- bboreham
-title: 使用 Weave Net 作为 NetworkPolicy
+title: 使用 Weave Net 提供 NetworkPolicy
content_type: task
weight: 50
---
<!-- overview -->
-<!-- This page shows how to use Weave Net for NetworkPolicy. -->
-
-本页展示了如何使用使用 Weave Net 作为 NetworkPolicy。
-
-
+<!--
+This page shows how to use Weave Net for NetworkPolicy.
+-->
+本页展示如何使用使用 Weave Net 提供 NetworkPolicy。
## {{% heading "prerequisites" %}}
<!--
You need to have a Kubernetes cluster. Follow the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/) to bootstrap one.
-->
-您需要拥有一个 Kubernetes 集群。按照[kubeadm 入门指南](/docs/getting-started-guides/kubeadm/)来引导一个。
+你需要拥有一个 Kubernetes 集群。按照
+[kubeadm 入门指南](/zh/docs/reference/setup-tools/kubeadm/kubeadm/)
+来启动一个。
<!-- steps -->
+
<!--
## Install the Weave Net addon
@@ -32,20 +32,21 @@ The Weave Net addon for Kubernetes comes with a [Network Policy Controller](http
-->
## 安装 Weave Net 插件
-按照[通过插件集成Kubernetes](https://www.weave.works/docs/net/latest/kube-addon/)指南。
+按照[通过插件集成 Kubernetes](https://www.weave.works/docs/net/latest/kube-addon/)
+指南执行安装。
-Kubernetes 的 Weave Net 插件带有[网络策略控制器](https://www.weave.works/docs/net/latest/kube-addon/#npc)，可自动监控 Kubernetes 所有名称空间中的任何 NetworkPolicy 注释。 配置`iptables`规则以允许或阻止策略指示的流量。
+Kubernetes 的 Weave Net 插件带有
+[网络策略控制器](https://www.weave.works/docs/net/latest/kube-addon/#npc)，
+可自动监控 Kubernetes 所有名字空间的 NetworkPolicy 注释，
+配置 `iptables` 规则以允许或阻止策略指示的流量。
<!--
-
## Test the installation
Verify that the weave works.
Enter the following command:
-
-->
-
## 测试安装
验证 weave 是否有效。
@@ -67,17 +68,21 @@ weave-net-7nmwt 2/2 Running 3 9d
weave-net-pmw8w 2/2 Running 0 9d 192.168.2.216 worknode2
```
-<!-- Each Node has a weave Pod, and all Pods are `Running` and `2/2 READY`. (`2/2` means that each Pod has `weave` and `weave-npc`.) -->
-每个 Node 都有一个 weave Pod，所有 Pod 都是`Running`和`2/2 READY`。（`2/2`表示每个Pod都有`weave`和`weave-npc`。）
-
-
+<!--
+Each Node has a weave Pod, and all Pods are `Running` and `2/2 READY`. (`2/2` means that each Pod has `weave` and `weave-npc`.)
+-->
+每个 Node 都有一个 weave Pod，所有 Pod 都是`Running` 和 `2/2 READY`。
+（`2/2` 表示每个 Pod 都有 `weave` 和 `weave-npc`）
## {{% heading "whatsnext" %}}
<!--
Once you have installed the Weave Net addon, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. If you have any question, contact us at [#weave-community on Slack or Weave User Group](https://github.com/weaveworks/weave#getting-help).
-->
-
-安装Weave Net插件后，您可以按照[声明网络策略](/docs/tasks/administration-cluster/declare-network-policy/)来试用 Kubernetes NetworkPolicy。 如果您有任何疑问，请联系我们[#weave-community on Slack 或 Weave User Group](https://github.com/weaveworks/weave#getting-help)。
-
+安装 Weave Net 插件后，你可以参考
+[声明网络策略](/zh/docs/tasks/administration-cluster/declare-network-policy/)
+来试用 Kubernetes NetworkPolicy。
+如果你有任何疑问，请通过
+[Slack 上的 #weave-community 频道或者 Weave 用户组](https://github.com/weaveworks/weave#getting-help)
+联系我们。
diff --git a/content/zh/docs/tasks/administer-cluster/out-of-resource.md b/content/zh/docs/tasks/administer-cluster/out-of-resource.md
index 927fb1ab56..69dc7ae65b 100644
--- a/content/zh/docs/tasks/administer-cluster/out-of-resource.md
+++ b/content/zh/docs/tasks/administer-cluster/out-of-resource.md
@@ -1,20 +1,14 @@
---
-reviewers:
-- derekwaynecarr
-- vishh
-- timstclair
title: 配置资源不足时的处理方式
content_type: concept
---
<!--
----
reviewers:
- derekwaynecarr
- vishh
- timstclair
title: Configure Out Of Resource Handling
content_type: concept
----
-->
<!-- overview -->
@@ -27,13 +21,11 @@ are low. This is especially important when dealing with incompressible
compute resources, such as memory or disk space. If such resources are exhausted,
nodes become unstable.
-->
+本页介绍如何使用 `kubelet` 配置资源不足时的处理方式。
-本页介绍了如何使用`kubelet`配置资源不足时的处理方式。
-
-当可用计算资源较少时，`kubelet`需要保证节点稳定性。这在处理如内存和硬盘之类的不可压缩资源时尤为重要。如果任意一种资源耗尽，节点将会变得不稳定。
-
-
-
+当可用计算资源较少时，`kubelet`需要保证节点稳定性。
+这在处理如内存和硬盘之类的不可压缩资源时尤为重要。
+如果任意一种资源耗尽，节点将会变得不稳定。
<!-- body -->
@@ -47,11 +39,12 @@ a Pod, it terminates all of its containers and transitions its `PodPhase` to `Fa
If the evicted Pod is managed by a Deployment, the Deployment will create another Pod
to be scheduled by Kubernetes.
-
-->
## 驱逐策略
-`kubelet` 能够主动监测和防止计算资源的全面短缺。在那种情况下，`kubelet`可以主动地结束一个或多个 pod 以回收短缺的资源。当 `kubelet` 结束一个 pod 时，它将终止 pod 中的所有容器，而 pod 的 `PodPhase` 将变为 `Failed`。
+`kubelet` 能够主动监测和防止计算资源的全面短缺。
+在那种情况下，`kubelet` 可以主动地结束一个或多个 Pod 以回收短缺的资源。
+当 `kubelet` 结束一个 Pod 时，它将终止 Pod 中的所有容器，而 Pod 的 `PodPhase` 将变为 `Failed`。
如果被驱逐的 Pod 由 Deployment 管理，这个 Deployment 会创建另一个 Pod 给 Kubernetes 来调度。
@@ -61,7 +54,13 @@ to be scheduled by Kubernetes.
The `kubelet` supports eviction decisions based on the signals described in the following
table. The value of each signal is described in the Description column, which is based on
the `kubelet` summary API.
+-->
+### 驱逐信号
+`kubelet` 支持按照以下表格中描述的信号触发驱逐决定。
+每个信号的值在 description 列描述，基于 `kubelet` 摘要 API。
+
+<!--
| Eviction Signal | Description |
|----------------------------|-----------------------------------------------------------------------|
| `memory.available` | `memory.available` := `node.status.capacity[memory]` - `node.stats.memory.workingSet` |
@@ -69,11 +68,23 @@ the `kubelet` summary API.
| `nodefs.inodesFree` | `nodefs.inodesFree` := `node.stats.fs.inodesFree` |
| `imagefs.available` | `imagefs.available` := `node.stats.runtime.imagefs.available` |
| `imagefs.inodesFree` | `imagefs.inodesFree` := `node.stats.runtime.imagefs.inodesFree` |
+-->
+| 驱逐信号 | 描述 |
+|----------------------------|-----------------------------------------------------------------------|
+| `memory.available` | `memory.available` := `node.status.capacity[memory]` - `node.stats.memory.workingSet` |
+| `nodefs.available` | `nodefs.available` := `node.stats.fs.available` |
+| `nodefs.inodesFree` | `nodefs.inodesFree` := `node.stats.fs.inodesFree` |
+| `imagefs.available` | `imagefs.available` := `node.stats.runtime.imagefs.available` |
+| `imagefs.inodesFree` | `imagefs.inodesFree` := `node.stats.runtime.imagefs.inodesFree` |
+<!--
Each of the above signals supports either a literal or percentage based value.
The percentage based value is calculated relative to the total capacity
associated with each signal.
+-->
+上面的每个信号都支持字面值或百分比的值。基于百分比的值的计算与每个信号对应的总容量相关。
+<!--
The value for `memory.available` is derived from the cgroupfs instead of tools
like `free -m`. This is important because `free -m` does not work in a
container, and if users use the [node
@@ -85,13 +96,30 @@ reproduces the same set of steps that the `kubelet` performs to calculate
`memory.available`. The `kubelet` excludes inactive_file (i.e. # of bytes of
file-backed memory on inactive LRU list) from its calculation as it assumes that
memory is reclaimable under pressure.
+-->
+`memory.available` 的值从 cgroupfs 获取，而不是通过类似 `free -m` 的工具。
+这很重要，因为 `free -m` 不能在容器中工作，并且如果用户使用了
+[节点可分配资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
+特性，资源不足的判定将同时在本地 cgroup 层次结构的终端用户 Pod 部分和根节点做出。
+这个[脚本](/zh/docs/tasks/administer-cluster/out-of-resource/memory-available.sh)
+复现了与 `kubelet` 计算 `memory.available` 相同的步骤。
+`kubelet` 将 `inactive_file`（意即活动 LRU 列表上基于文件后端的内存字节数）从计算中排除，
+因为它假设内存在出现压力时将被回收。
+
+<!--
`kubelet` supports only two filesystem partitions.
1. The `nodefs` filesystem that kubelet uses for volumes, daemon logs, etc.
2. The `imagefs` filesystem that container runtimes uses for storing images and
container writable layers.
+-->
+`kubelet` 只支持两种文件系统分区。
+1. `nodefs` 文件系统，kubelet 将其用于卷和守护程序日志等。
+2. `imagefs` 文件系统，容器运行时用于保存镜像和容器可写层。
+
+<!--
`imagefs` is optional. `kubelet` auto-discovers these filesystems using
cAdvisor. `kubelet` does not care about any other filesystems. Any other types
of configurations are not currently supported by the kubelet. For example, it is
@@ -101,30 +129,13 @@ In future releases, the `kubelet` will deprecate the existing [garbage
collection](/docs/concepts/cluster-administration/kubelet-garbage-collection/)
support in favor of eviction in response to disk pressure.
-->
-### 驱逐信号
+`imagefs` 可选。`kubelet` 使用 cAdvisor 自动发现这些文件系统。
+`kubelet` 不关心其它文件系统。当前不支持配置任何其它类型。
+例如，在专用 `filesytem` 中存储卷和日志是不可以的。
-`kubelet` 支持按照以下表格中描述的信号触发驱逐决定。每个信号的值在 description 列描述，基于 `kubelet` 摘要 API。
-
-| 驱逐信号 | 描述 |
-|----------------------------|-----------------------------------------------------------------------|
-| `memory.available` | `memory.available` := `node.status.capacity[memory]` - `node.stats.memory.workingSet` |
-| `nodefs.available` | `nodefs.available` := `node.stats.fs.available` |
-| `nodefs.inodesFree` | `nodefs.inodesFree` := `node.stats.fs.inodesFree` |
-| `imagefs.available` | `imagefs.available` := `node.stats.runtime.imagefs.available` |
-| `imagefs.inodesFree` | `imagefs.inodesFree` := `node.stats.runtime.imagefs.inodesFree` |
-
-上面的每个信号都支持字面值或百分比的值。基于百分比的值的计算与每个信号对应的总容量相关。
-
-`memory.available` 的值从 cgroupfs 获取，而不是通过类似 `free -m` 的工具。这很重要，因为 `free -m` 不能在容器中工作，并且如果用户使用了 [可分配节点](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)特性，资源不足的判定将同时在本地 cgroup 层次结构的终端用户 pod 部分和根节点做出。这个 [脚本](/docs/tasks/administer-cluster/out-of-resource/memory-available.sh)复现了与 `kubelet` 计算 `memory.available` 相同的步骤。`kubelet`将`inactive_file`（意即活动 LRU 列表上基于文件后端的内存字节数）从计算中排除，因为它假设内存在出现压力时将被回收。
-
-`kubelet` 只支持两种文件系统分区。
-
-1. `nodefs` 文件系统，kubelet 将其用于卷和守护程序日志等。
-2. `imagefs` 文件系统，容器运行时用于保存镜像和容器可写层。
-
-`imagefs`可选。`kubelet`使用 cAdvisor 自动发现这些文件系统。`kubelet`不关心其它文件系统。当前不支持配置任何其它类型。例如，在专用`文件系统`中存储卷和日志是不可以的。
-
-在将来的发布中，`kubelet`将废除当前存在的 [垃圾回收](/docs/concepts/cluster-administration/kubelet-garbage-collection/) 机制，这种机制目前支持将驱逐操作作为对磁盘压力的响应。
+在将来的发布中，`kubelet`将废除当前存在的
+[垃圾回收](/zh/docs/concepts/cluster-administration/kubelet-garbage-collection/)
+机制，这种机制目前支持将驱逐操作作为对磁盘压力的响应。
<!--
### Eviction Thresholds
@@ -157,9 +168,11 @@ either `memory.available<10%` or `memory.available<1Gi`. You cannot use both.
* 合法的 `eviction-signal` 标志如上所示。
* `operator` 是所需的关系运算符，例如 `<`。
-* `quantity` 是驱逐阈值值标志，例如 `1Gi`。合法的标志必须匹配 Kubernetes 使用的数量表示。驱逐阈值也可以使用 `%` 标记表示百分比。
+* `quantity` 是驱逐阈值值标志，例如 `1Gi`。合法的标志必须匹配 Kubernetes 使用的数量表示。
+ 驱逐阈值也可以使用 `%` 标记表示百分比。
-举例说明，如果一个节点有 `10Gi` 内存，希望在可用内存下降到 `1Gi` 以下时引起驱逐操作，则驱逐阈值可以使用下面任意一种方式指定（但不是两者同时）。
+举例说明，如果一个节点有 `10Gi` 内存，希望在可用内存下降到 `1Gi` 以下时引起驱逐操作，
+则驱逐阈值可以使用下面任意一种方式指定（但不是两者同时）。
* `memory.available<10%`
* `memory.available<1Gi`
@@ -172,14 +185,25 @@ administrator-specified grace period. No action is taken by the `kubelet`
to reclaim resources associated with the eviction signal until that grace
period has been exceeded. If no grace period is provided, the `kubelet`
returns an error on startup.
+-->
+#### 软驱逐阈值
+软驱逐阈值使用一对由驱逐阈值和管理员必须指定的宽限期组成的配置对。在超过宽限期前，`kubelet`不会采取任何动作回收和驱逐信号关联的资源。如果没有提供宽限期，`kubelet`启动时将报错。
+
+<!--
In addition, if a soft eviction threshold has been met, an operator can
specify a maximum allowed Pod termination grace period to use when evicting
pods from the node. If specified, the `kubelet` uses the lesser value among
the `pod.Spec.TerminationGracePeriodSeconds` and the max allowed grace period.
If not specified, the `kubelet` kills Pods immediately with no graceful
termination.
+-->
+此外，如果达到了软驱逐阈值，操作员可以指定从节点驱逐 pod 时，在宽限期内允许结束的 pod 的最大数量。
+如果指定了 `pod.Spec.TerminationGracePeriodSeconds` 值，
+`kubelet` 将使用它和宽限期二者中较小的一个。
+如果没有指定，`kubelet`将立即终止 pod，而不会优雅结束它们。
+<!--
To configure soft eviction thresholds, the following flags are supported:
* `eviction-soft` describes a set of eviction thresholds (e.g. `memory.available<1.5Gi`) that if met over a
@@ -189,12 +213,6 @@ correspond to how long a soft eviction threshold must hold before triggering a P
* `eviction-max-pod-grace-period` describes the maximum allowed grace period (in seconds) to use when terminating
pods in response to a soft eviction threshold being met.
-->
-#### 软驱逐阈值
-
-软驱逐阈值使用一对由驱逐阈值和管理员必须指定的宽限期组成的配置对。在超过宽限期前，`kubelet`不会采取任何动作回收和驱逐信号关联的资源。如果没有提供宽限期，`kubelet`启动时将报错。
-
-此外，如果达到了软驱逐阈值，操作员可以指定从节点驱逐 pod 时，在宽限期内允许结束的 pod 的最大数量。如果指定了 `pod.Spec.TerminationGracePeriodSeconds` 值，`kubelet`将使用它和宽限期二者中较小的一个。如果没有指定，`kubelet`将立即终止 pod，而不会优雅结束它们。
-
软驱逐阈值的配置支持下列标记：
* `eviction-soft` 描述了驱逐阈值的集合（例如 `memory.available<1.5Gi`），如果在宽限期之外满足条件将触发 pod 驱逐。
@@ -223,7 +241,8 @@ The `kubelet` has the following default hard eviction threshold:
-->
#### 硬驱逐阈值
-硬驱逐阈值没有宽限期，一旦察觉，`kubelet`将立即采取行动回收关联的短缺资源。如果满足硬驱逐阈值，`kubelet`将立即结束 pod 而不是优雅终止。
+硬驱逐阈值没有宽限期，一旦察觉，`kubelet`将立即采取行动回收关联的短缺资源。
+如果满足硬驱逐阈值，`kubelet`将立即结束 pod 而不是优雅终止。
硬驱逐阈值的配置支持下列标记：
@@ -257,7 +276,14 @@ The `kubelet` maps one or more eviction signals to a corresponding node conditio
If a hard eviction threshold has been met, or a soft eviction threshold has been met
independent of its associated grace period, the `kubelet` reports a condition that
reflects the node is under pressure.
+-->
+### 节点状态
+`kubelet` 会将一个或多个驱逐信号映射到对应的节点状态。
+
+如果满足硬驱逐阈值，或者满足独立于其关联宽限期的软驱逐阈值时，`kubelet`将报告节点处于压力下的状态。
+
+<!--
The following node conditions are defined that correspond to the specified eviction signal.
| Node Condition | Eviction Signal | Description |
@@ -268,18 +294,12 @@ The following node conditions are defined that correspond to the specified evict
The `kubelet` continues to report node status updates at the frequency specified by
`--node-status-update-frequency` which defaults to `10s`.
-->
-### 节点状态
-
-`kubelet` 会将一个或多个驱逐信号映射到对应的节点状态。
-
-如果满足硬驱逐阈值，或者满足独立于其关联宽限期的软驱逐阈值时，`kubelet`将报告节点处于压力下的状态。
-
下列节点状态根据相应的驱逐信号定义。
| 节点状态 | 驱逐信号 | 描述 |
|-------------------------|-------------------------------|--------------------------------------------|
-| `MemoryPressure` | `memory.available` | Available memory on the node has satisfied an eviction threshold |
-| `DiskPressure` | `nodefs.available`, `nodefs.inodesFree`, `imagefs.available`, or `imagefs.inodesFree` | Available disk space and inodes on either the node's root filesystem or image filesystem has satisfied an eviction threshold |
+| `MemoryPressure` | `memory.available` | 节点上可用内存量达到逐出阈值 |
+| `DiskPressure` | `nodefs.available`, `nodefs.inodesFree`, `imagefs.available`, 或 `imagefs.inodesFree` | 节点或者节点的根文件系统或镜像文件系统上可用磁盘空间和 i 节点个数达到逐出阈值 |
`kubelet` 将以 `--node-status-update-frequency` 指定的频率连续报告节点状态更新，其默认值为 `10s`。
@@ -303,7 +323,8 @@ condition back to `false`.
-->
### 节点状态振荡
-如果节点在软驱逐阈值的上下振荡，但没有超过关联的宽限期时，将引起对应节点的状态持续在 true 和 false 间跳变，并导致不好的调度结果。
+如果节点在软驱逐阈值的上下振荡，但没有超过关联的宽限期时，将引起对应节点的状态持续在
+true 和 false 间跳变，并导致不好的调度结果。
为了防止这种振荡，可以定义下面的标志，用于控制 `kubelet` 从压力状态中退出之前必须等待的时间。
@@ -326,7 +347,8 @@ machine has a dedicated `imagefs` configured for the container runtime.
如果满足驱逐阈值并超过了宽限期，`kubelet`将启动回收压力资源的过程，直到它发现低于设定阈值的信号为止。
-`kubelet`将尝试在驱逐终端用户 pod 前回收节点层级资源。发现磁盘压力时，如果节点针对容器运行时配置有独占的 `imagefs`，`kubelet`回收节点层级资源的方式将会不同。
+`kubelet` 将尝试在驱逐终端用户 pod 前回收节点层级资源。
+发现磁盘压力时，如果节点针对容器运行时配置有独占的 `imagefs`，`kubelet`回收节点层级资源的方式将会不同。
<!--
#### With `imagefs`
@@ -342,13 +364,13 @@ If `nodefs` filesystem has met eviction thresholds, `kubelet` frees up disk spac
1. Delete dead Pods and their containers
2. Delete all unused images
-->
-#### 使用 `Imagefs`
+#### 使用 `imagefs`
如果 `nodefs` 文件系统满足驱逐阈值，`kubelet`通过驱逐 pod 及其容器来释放磁盘空间。
如果 `imagefs` 文件系统满足驱逐阈值，`kubelet`通过删除所有未使用的镜像来释放磁盘空间。
-#### 未使用 `Imagefs`
+#### 未使用 `imagefs`
如果 `nodefs` 满足驱逐阈值，`kubelet`将以下面的顺序释放磁盘空间：
@@ -363,6 +385,16 @@ If the `kubelet` is unable to reclaim sufficient resource on the node, `kubelet`
The `kubelet` ranks Pods for eviction first by whether or not their usage of the starved resource exceeds requests,
then by [Priority](/docs/concepts/configuration/pod-priority-preemption/), and then by the consumption of the starved compute resource relative to the Pods' scheduling requests.
+-->
+### 驱逐最终用户的 pod
+
+如果 `kubelet` 在节点上无法回收足够的资源，`kubelet`将开始驱逐 pod。
+
+`kubelet` 首先根据他们对短缺资源的使用是否超过请求来排除 pod 的驱逐行为，
+然后通过[优先级](/zh/docs/concepts/configuration/pod-priority-preemption/)，
+然后通过相对于 pod 的调度请求消耗急需的计算资源。
+
+<!--
As a result, `kubelet` ranks and evicts Pods in the following order:
* `BestEffort` or `Burstable` Pods whose usage of a starved resource exceeds its request.
@@ -376,25 +408,29 @@ and `journald`) is consuming more resources than were reserved via `system-reser
less than requests remaining, then the node must choose to evict such a Pod in order to
preserve node stability and to limit the impact of the unexpected consumption to other Pods.
In this case, it will choose to evict pods of Lowest Priority first.
+-->
+`kubelet` 按以下顺序对要驱逐的 pod 排名：
+* `BestEffort` 或 `Burstable`，其对短缺资源的使用超过了其请求，此类 pod 按优先级排序，然后使用高于请求。
+* `Guaranteed` pod 和 `Burstable` pod，其使用率低于请求，最后被驱逐。
+ `Guaranteed` Pod 只有为所有的容器指定了要求和限制并且它们相等时才能得到保证。
+ 由于另一个 Pod 的资源消耗，这些 Pod 保证永远不会被驱逐。
+ 如果系统守护进程（例如 `kubelet`、`docker`、和 `journald`）消耗的资源多于通过
+ `system-reserved` 或 `kube-reserved` 分配保留的资源，并且该节点只有 `Guaranteed` 或
+ `Burstable` Pod 使用少于剩余的请求，然后节点必须选择驱逐这样的 Pod
+ 以保持节点的稳定性并限制意外消耗对其他 pod 的影响。
+ 在这种情况下，它将首先驱逐优先级最低的 pod。
+
+<!--
If necessary, `kubelet` evicts Pods one at a time to reclaim disk when `DiskPressure`
is encountered. If the `kubelet` is responding to `inode` starvation, it reclaims
`inodes` by evicting Pods with the lowest quality of service first. If the `kubelet`
is responding to lack of available disk, it ranks Pods within a quality of service
that consumes the largest amount of disk and kill those first.
-->
-### 驱逐最终用户的 pod
-
-如果 `kubelet` 在节点上无法回收足够的资源，`kubelet`将开始驱逐 pod。
-
-`kubelet` 首先根据他们对短缺资源的使用是否超过请求来排除 pod 的驱逐行为，然后通过 [优先级](/docs/concepts/configuration/pod-priority-preemption/)，然后通过相对于 pod 的调度请求消耗急需的计算资源。
-
-`kubelet` 按以下顺序对要驱逐的 pod 排名：
-
-* `BestEffort` 或 `Burstable`，其对短缺资源的使用超过了其请求，此类 pod 按优先级排序，然后使用高于请求。
-* `Guaranteed` pod 和 `Burstable` pod，其使用率低于请求，最后被驱逐。`Guaranteed`pod 只有为所有的容器指定了要求和限制并且它们相等时才能得到保证。由于另一个 pod 的资源消耗，这些 pod 保证永远不会被驱逐。如果系统守护进程（例如 `kubelet`、`docker`、和 `journald`）消耗的资源多于通过 `system-reserved` 或 `kube-reserved` 分配保留的资源，并且该节点只有 `Guaranteed` 或 `Burstable` pod 使用少于剩余的请求，然后节点必须选择驱逐这样的 pod 以保持节点的稳定性并限制意外消耗对其他 pod 的影响。在这种情况下，它将首先驱逐优先级最低的 pod。
-
-必要时，`kubelet`会在遇到 `DiskPressure` 时驱逐一个 pod 来回收磁盘空间。如果 `kubelet` 响应 `inode` 短缺，它会首先驱逐服务质量最低的 pod 来回收 `inodes`。如果 `kubelet` 响应缺少可用磁盘，它会将 pod 排在服务质量范围内，该服务会消耗大量的磁盘并首先结束这些磁盘。
+必要时，`kubelet`会在遇到 `DiskPressure` 时逐个驱逐 Pod 来回收磁盘空间。
+如果 `kubelet` 响应 `inode` 短缺，它会首先驱逐服务质量最低的 Pod 来回收 `inodes`。
+如果 `kubelet` 响应缺少可用磁盘，它会将 Pod 排在服务质量范围内，该服务会消耗大量的磁盘并首先结束这些磁盘。
<!--
#### With `imagefs`
@@ -425,31 +461,20 @@ If `nodefs` is triggering evictions, `kubelet` sorts Pods based on their total d
In certain scenarios, eviction of Pods could result in reclamation of small amount of resources. This can result in
`kubelet` hitting eviction thresholds in repeated successions. In addition to that, eviction of resources like `disk`,
is time consuming.
-
-To mitigate these issues, `kubelet` can have a per-resource `minimum-reclaim`. Whenever `kubelet` observes
-resource pressure, `kubelet` attempts to reclaim at least `minimum-reclaim` amount of resource below
-the configured eviction threshold.
-
-For example, with the following configuration:
-
-```
---eviction-hard=memory.available<500Mi,nodefs.available<1Gi,imagefs.available<100Gi
---eviction-minimum-reclaim="memory.available=0Mi,nodefs.available=500Mi,imagefs.available=2Gi"`
-```
-
-If an eviction threshold is triggered for `memory.available`, the `kubelet` works to ensure
-that `memory.available` is at least `500Mi`. For `nodefs.available`, the `kubelet` works
-to ensure that `nodefs.available` is at least `1.5Gi`, and for `imagefs.available` it
-works to ensure that `imagefs.available` is at least `102Gi` before no longer reporting pressure
-on their associated resources.
-
-The default `eviction-minimum-reclaim` is `0` for all resources.
-->
### 最小驱逐回收
在某些场景，驱逐 pod 会导致回收少量资源。这将导致 `kubelet` 反复碰到驱逐阈值。除此之外，对如 `disk` 这类资源的驱逐时比较耗时的。
-为了减少这类问题，`kubelet`可以为每个资源配置一个 `minimum-reclaim`。当 `kubelet` 发现资源压力时，`kubelet`将尝试至少回收驱逐阈值之下 `minimum-reclaim` 数量的资源。
+<!--
+To mitigate these issues, `kubelet` can have a per-resource `minimum-reclaim`. Whenever `kubelet` observes
+resource pressure, `kubelet` attempts to reclaim at least `minimum-reclaim` amount of resource below
+the configured eviction threshold.
+
+For example, with the following configuration:
+-->
+为了减少这类问题，`kubelet`可以为每个资源配置一个 `minimum-reclaim`。
+当 `kubelet` 发现资源压力时，`kubelet`将尝试至少回收驱逐阈值之下 `minimum-reclaim` 数量的资源。
例如使用下面的配置：
@@ -458,7 +483,19 @@ The default `eviction-minimum-reclaim` is `0` for all resources.
--eviction-minimum-reclaim="memory.available=0Mi,nodefs.available=500Mi,imagefs.available=2Gi"`
```
-如果 `memory.available` 驱逐阈值被触发，`kubelet`将保证 `memory.available` 至少为 `500Mi`。对于 `nodefs.available`，`kubelet`将保证 `nodefs.available` 至少为 `1.5Gi`。对于 `imagefs.available`，`kubelet`将保证 `imagefs.available` 至少为 `102Gi`，直到不再有相关资源报告压力为止。
+<!--
+If an eviction threshold is triggered for `memory.available`, the `kubelet` works to ensure
+that `memory.available` is at least `500Mi`. For `nodefs.available`, the `kubelet` works
+to ensure that `nodefs.available` is at least `1.5Gi`, and for `imagefs.available` it
+works to ensure that `imagefs.available` is at least `102Gi` before no longer reporting pressure
+on their associated resources.
+
+The default `eviction-minimum-reclaim` is `0` for all resources.
+-->
+如果 `memory.available` 驱逐阈值被触发，`kubelet` 将保证 `memory.available` 至少为 `500Mi`。
+对于 `nodefs.available`，`kubelet` 将保证 `nodefs.available` 至少为 `1.5Gi`。
+对于 `imagefs.available`，`kubelet` 将保证 `imagefs.available` 至少为 `102Gi`，
+直到不再有相关资源报告压力为止。
所有资源的默认 `eviction-minimum-reclaim` 值为 `0`。
@@ -480,8 +517,8 @@ pods on the node.
| 节点状态 | 调度器行为 |
| ---------------- | ------------------------------------------------ |
-| `MemoryPressure` | No new `BestEffort` Pods are scheduled to the node. |
-| `DiskPressure` | No new Pods are scheduled to the node. |
+| `MemoryPressure` | 新的 `BestEffort` Pod 不会被调度到该节点 |
+| `DiskPressure` | 没有新的 Pod 会被调度到该节点 |
<!--
## Node OOM Behavior
@@ -490,13 +527,29 @@ If the node experiences a system OOM (out of memory) event prior to the `kubelet
the node depends on the [oom_killer](https://lwn.net/Articles/391222/) to respond.
The `kubelet` sets a `oom_score_adj` value for each container based on the quality of service for the Pod.
+-->
+## 节点 OOM 行为
+如果节点在 `kubelet` 回收内存之前经历了系统 OOM（内存不足）事件，它将基于
+[oom-killer](https://lwn.net/Articles/391222/) 做出响应。
+
+`kubelet` 基于 pod 的 service 质量为每个容器设置一个 `oom_score_adj` 值。
+
+<!--
| Quality of Service | oom_score_adj |
|----------------------------|-----------------------------------------------------------------------|
| `Guaranteed` | -998 |
| `BestEffort` | 1000 |
| `Burstable` | min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999) |
+-->
+| Service 质量 | oom_score_adj |
+|----------------------------|-----------------------------------------------------------------------|
+| `Guaranteed` | -998 |
+| `BestEffort` | 1000 |
+| `Burstable` | min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999) |
+
+<!--
If the `kubelet` is unable to reclaim memory prior to a node experiencing system OOM, the `oom_killer` calculates
an `oom_score` based on the percentage of memory it's using on the node, and then add the `oom_score_adj` to get an
effective `oom_score` for the container, and then kills the container with the highest score.
@@ -507,23 +560,14 @@ to reclaim memory.
Unlike Pod eviction, if a Pod container is OOM killed, it may be restarted by the `kubelet` based on its `RestartPolicy`.
-->
-## 节点 OOM 行为
+如果 `kubelet` 在节点经历系统 OOM 之前无法回收内存，`oom_killer` 将基于它在节点上
+使用的内存百分比算出一个 `oom_score`，并加上 `oom_score_adj` 得到容器的有效
+`oom_score`，然后结束得分最高的容器。
-如果节点在 `kubelet` 回收内存之前经历了系统 OOM（内存不足）事件，它将基于 [oom-killer](https://lwn.net/Articles/391222/) 做出响应。
+预期的行为应该是拥有最低服务质量并消耗和调度请求相关内存量最多的容器第一个被结束，以回收内存。
-`kubelet` 基于 pod 的 service 质量为每个容器设置一个 `oom_score_adj` 值。
-
-| Service 质量 | oom_score_adj |
-|----------------------------|-----------------------------------------------------------------------|
-| `Guaranteed` | -998 |
-| `BestEffort` | 1000 |
-| `Burstable` | min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999) |
-
-如果 `kubelet` 在节点经历系统 OOM 之前无法回收内存，`oom_killer`将基于它在节点上使用的内存百分比算出一个 `oom_score`，并加上 `oom_score_adj` 得到容器的有效 `oom_score`，然后结束得分最高的容器。
-
-预期的行为应该是拥有最低 service 质量并消耗和调度请求相关内存量最多的容器第一个被结束，以回收内存。
-
-和 pod 驱逐不同，如果一个 pod 的容器是被 OOM 结束的，基于其 `RestartPolicy`，它可能会被 `kubelet` 重新启动。
+和 pod 驱逐不同，如果一个 Pod 的容器是被 OOM 结束的，基于其 `RestartPolicy`，
+它可能会被 `kubelet` 重新启动。
<!--
## Best Practices
@@ -539,19 +583,6 @@ Consider the following scenario:
* Operator wants to evict Pods at 95% memory utilization to reduce incidence of system OOM.
To facilitate this scenario, the `kubelet` would be launched as follows:
-
-```
---eviction-hard=memory.available<500Mi
---system-reserved=memory=1.5Gi
-```
-
-Implicit in this configuration is the understanding that "System reserved" should include the amount of memory
-covered by the eviction threshold.
-
-To reach that capacity, either some Pod is using more than its request, or the system is using more than `1.5Gi - 500Mi = 1Gi`.
-
-This configuration ensures that the scheduler does not place Pods on a node that immediately induce memory pressure
-and trigger eviction assuming those Pods use less than their configured request.
-->
## 最佳实践
@@ -572,6 +603,15 @@ and trigger eviction assuming those Pods use less than their configured request.
--system-reserved=memory=1.5Gi
```
+<!--
+Implicit in this configuration is the understanding that "System reserved" should include the amount of memory
+covered by the eviction threshold.
+
+To reach that capacity, either some Pod is using more than its request, or the system is using more than `1.5Gi - 500Mi = 1Gi`.
+
+This configuration ensures that the scheduler does not place Pods on a node that immediately induce memory pressure
+and trigger eviction assuming those Pods use less than their configured request.
+-->
这个配置的暗示是理解系统保留应该包含被驱逐阈值覆盖的内存数量。
要达到这个容量，要么某些 pod 使用了超过它们请求的资源，要么系统使用的内存超过 `1.5Gi - 500Mi = 1Gi`。
@@ -595,11 +635,13 @@ for eviction. Instead `DaemonSet` should ideally launch `Guaranteed` Pods.
-->
### DaemonSet
-我们永远都不希望 `kubelet` 驱逐一个从 `DaemonSet` 派生的 pod，因为这个 pod 将立即被重建并调度回相同的节点。
+我们永远都不希望 `kubelet` 驱逐一个从 `DaemonSet` 派生的 Pod，因为这个 Pod 将立即被重建并调度回相同的节点。
-目前，`kubelet`没有办法区分一个 pod 是由 `DaemonSet` 还是其他对象创建。如果/当这个信息可用时，`kubelet`可能会预先将这些 pod 从提供给驱逐策略的候选集合中过滤掉。
+目前，`kubelet`没有办法区分一个 Pod 是由 `DaemonSet` 还是其他对象创建。
+如果/当这个信息可用时，`kubelet` 可能会预先将这些 pod 从提供给驱逐策略的候选集合中过滤掉。
-总之，强烈推荐 `DaemonSet` 不要创建 `BestEffort` 的 pod，防止其被识别为驱逐的候选 pod。相反，理想情况下 `DaemonSet` 应该启动 `Guaranteed` 的 pod。
+总之，强烈推荐 `DaemonSet` 不要创建 `BestEffort` 的 Pod，防止其被识别为驱逐的候选 Pod。
+相反，理想情况下 `DaemonSet` 应该启动 `Guaranteed` 的 pod。
<!--
## Deprecation of existing feature flags to reclaim disk
@@ -608,7 +650,14 @@ for eviction. Instead `DaemonSet` should ideally launch `Guaranteed` Pods.
As disk based eviction matures, the following `kubelet` flags are marked for deprecation
in favor of the simpler configuration supported around eviction.
+-->
+## 现有的回收磁盘特性标签已被弃用
+`kubelet` 已经按需求清空了磁盘空间以保证节点稳定性。
+
+当磁盘驱逐成熟时，下面的 `kubelet` 标志将被标记为废弃的，以简化支持驱逐的配置。
+
+<!--
| Existing Flag | New Flag |
| ------------- | -------- |
| `--image-gc-high-threshold` | `--eviction-hard` or `eviction-soft` |
@@ -619,11 +668,6 @@ in favor of the simpler configuration supported around eviction.
| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` |
| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` |
-->
-## 弃用现有特性标签以回收磁盘
-
-`kubelet` 已经按需求清空了磁盘空间以保证节点稳定性。
-
-当磁盘驱逐成熟时，下面的 `kubelet` 标志将被标记为废弃的，以简化支持驱逐的配置。
| 现有标签 | 新标签 |
| ------------- | -------- |
@@ -639,26 +683,28 @@ in favor of the simpler configuration supported around eviction.
## Known issues
The following sections describe known issues related to out of resource handling.
+-->
+## 已知问题
+以下部分描述了与资源外处理有关的已知问题。
+
+<!--
### kubelet may not observe memory pressure right away
The `kubelet` currently polls `cAdvisor` to collect memory usage stats at a regular interval. If memory usage
increases within that window rapidly, the `kubelet` may not observe `MemoryPressure` fast enough, and the `OOMKiller`
will still be invoked. We intend to integrate with the `memcg` notification API in a future release to reduce this
latency, and instead have the kernel tell us when a threshold has been crossed immediately.
-
-If you are not trying to achieve extreme utilization, but a sensible measure of overcommit, a viable workaround for
-this issue is to set eviction thresholds at approximately 75% capacity. This increases the ability of this feature
-to prevent system OOMs, and promote eviction of workloads so cluster state can rebalance.
-->
-## 已知问题
-
-以下部分描述了与资源外处理有关的已知问题。
-
### kubelet 可能无法立即发现内存压力
`kubelet`当前通过以固定的时间间隔轮询 `cAdvisor` 来收集内存使用数据。如果内存使用在那个时间窗口内迅速增长，`kubelet`可能不能足够快的发现 `MemoryPressure`，`OOMKiller`将不会被调用。我们准备在将来的发行版本中通过集成 `memcg` 通知 API 来减小这种延迟。当超过阈值时，内核将立即告诉我们。
+<!--
+If you are not trying to achieve extreme utilization, but a sensible measure of overcommit, a viable workaround for
+this issue is to set eviction thresholds at approximately 75% capacity. This increases the ability of this feature
+to prevent system OOMs, and promote eviction of workloads so cluster state can rebalance.
+-->
如果您想处理可察觉的超量使用而不要求极端精准，可以设置驱逐阈值为大约 75% 容量作为这个问题的变通手段。这将增强这个特性的能力，防止系统 OOM，并提升负载卸载能力，以再次平衡集群状态。
<!--
@@ -669,5 +715,7 @@ the ability to get root container stats on an on-demand basis [(https://github.c
-->
### kubelet 可能会驱逐超过需求数量的 pod
-由于状态采集的时间差，驱逐操作可能驱逐比所需的更多的 pod。将来可通过添加从根容器获取所需状态的能力 [https://github.com/google/cadvisor/issues/1247](https://github.com/google/cadvisor/issues/1247) 来减缓这种状况。
+由于状态采集的时间差，驱逐操作可能驱逐比所需的更多的 pod。将来可通过添加从根容器获取所需状态的能力
+[https://github.com/google/cadvisor/issues/1247](https://github.com/google/cadvisor/issues/1247)
+来减缓这种状况。
diff --git a/content/zh/docs/tasks/administer-cluster/quota-api-object.md b/content/zh/docs/tasks/administer-cluster/quota-api-object.md
index 6011da5a29..f868d3bc5f 100644
--- a/content/zh/docs/tasks/administer-cluster/quota-api-object.md
+++ b/content/zh/docs/tasks/administer-cluster/quota-api-object.md
@@ -4,10 +4,8 @@ content_type: task
---
<!--
----
title: Configure Quotas for API Objects
content_type: task
----
-->
<!-- overview -->
@@ -20,22 +18,14 @@ You specify quotas in a
[ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core)
object.
-->
-
-本文讨论如何为 API 对象配置配额，包括 PersistentVolumeClaims 和 Services。
+本文讨论如何为 API 对象配置配额，包括 PersistentVolumeClaim 和 Service。
配额限制了可以在命名空间中创建的特定类型对象的数量。
-您可以在 [ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core) 对象中指定配额。
-
-
-
+你可以在 [ResourceQuota](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcequota-v1-core) 对象中指定配额。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
-
<!-- steps -->
<!--
@@ -44,7 +34,6 @@ object.
Create a namespace so that the resources you create in this exercise are
isolated from the rest of your cluster.
-->
-
## 创建命名空间
创建一个命名空间以便本例中创建的资源和集群中的其余部分相隔离。
@@ -58,7 +47,6 @@ kubectl create namespace quota-object-example
Here is the configuration file for a ResourceQuota object:
-->
-
## 创建 ResourceQuota
下面是一个 ResourceQuota 对象的配置文件：
@@ -68,17 +56,15 @@ Here is the configuration file for a ResourceQuota object:
<!--
Create the ResourceQuota:
-->
-
-创建 ResourceQuota
+创建 ResourceQuota：
```shell
-kubectl create -f https://k8s.io/examples/admin/resource/quota-objects.yaml --namespace=quota-object-example
+kubectl apply -f https://k8s.io/examples/admin/resource/quota-objects.yaml --namespace=quota-object-example
```
<!--
View detailed information about the ResourceQuota:
-->
-
查看 ResourceQuota 的详细信息：
```shell
@@ -90,9 +76,8 @@ The output shows that in the quota-object-example namespace, there can be at mos
one PersistentVolumeClaim, at most two Services of type LoadBalancer, and no Services
of type NodePort.
-->
-
-输出结果表明在 quota-object-example 命名空间中，至多只能有一个 PersistentVolumeClaim，最多两个 LoadBalancer 类型的服务，不能有 NodePort 类型的服务。
-
+输出结果表明在 quota-object-example 命名空间中，至多只能有一个 PersistentVolumeClaim，
+最多两个 LoadBalancer 类型的服务，不能有 NodePort 类型的服务。
```yaml
status:
@@ -111,7 +96,6 @@ status:
Here is the configuration file for a PersistentVolumeClaim object:
-->
-
## 创建 PersistentVolumeClaim
下面是一个 PersistentVolumeClaim 对象的配置文件：
@@ -121,17 +105,15 @@ Here is the configuration file for a PersistentVolumeClaim object:
<!--
Create the PersistentVolumeClaim:
-->
-
创建 PersistentVolumeClaim：
```shell
-kubectl create -f https://k8s.io/examples/admin/resource/quota-objects-pvc.yaml --namespace=quota-object-example
+kubectl apply -f https://k8s.io/examples/admin/resource/quota-objects-pvc.yaml --namespace=quota-object-example
```
<!--
Verify that the PersistentVolumeClaim was created:
-->
-
确认已创建完 PersistentVolumeClaim：
```shell
@@ -141,10 +123,9 @@ kubectl get persistentvolumeclaims --namespace=quota-object-example
<!--
The output shows that the PersistentVolumeClaim exists and has status Pending:
-->
-
输出信息表明 PersistentVolumeClaim 存在并且处于 Pending 状态：
-```shell
+```
NAME STATUS
pvc-quota-demo Pending
```
@@ -154,7 +135,6 @@ pvc-quota-demo Pending
Here is the configuration file for a second PersistentVolumeClaim:
-->
-
## 尝试创建第二个 PersistentVolumeClaim
下面是第二个 PersistentVolumeClaim 的配置文件：
@@ -164,7 +144,6 @@ Here is the configuration file for a second PersistentVolumeClaim:
<!--
Attempt to create the second PersistentVolumeClaim:
-->
-
尝试创建第二个 PersistentVolumeClaim：
```shell
@@ -174,23 +153,21 @@ kubectl create -f https://k8s.io/examples/admin/resource/quota-objects-pvc-2.yam
The output shows that the second PersistentVolumeClaim was not created,
because it would have exceeded the quota for the namespace.
-->
-
输出信息表明第二个 PersistentVolumeClaim 没有创建成功，因为这会超出命名空间的配额。
-
```
persistentvolumeclaims "pvc-quota-demo-2" is forbidden:
exceeded quota: object-quota-demo, requested: persistentvolumeclaims=1,
used: persistentvolumeclaims=1, limited: persistentvolumeclaims=1
```
+
<!--
## Notes
These are the strings used to identify API resources that can be constrained
by quotas:
-->
-
-## 注意事项
+## 说明
下面这些字符串可被用来标识那些能被配额限制的 API 资源：
@@ -212,20 +189,16 @@ by quotas:
Delete your namespace:
-->
-
## 清理
-删除您的命名空间：
+删除你的命名空间：
```shell
kubectl delete namespace quota-object-example
```
-
-
## {{% heading "whatsnext" %}}
-
<!--
### For cluster administrators
@@ -244,17 +217,12 @@ kubectl delete namespace quota-object-example
### 集群管理员参考
-* [为命名空间配置默认的内存请求和限制](/docs/tasks/administer-cluster/memory-default-namespace/)
-
-* [为命名空间配置默认的 CPU 请求和限制](/docs/tasks/administer-cluster/cpu-default-namespace/)
-
-* [为命名空间配置内存的最小和最大限制](/docs/tasks/administer-cluster/memory-constraint-namespace/)
-
-* [为命名空间配置 CPU 的最小和最大限制](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
-
-* [为命名空间配置 CPU 和内存配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
-
-* [为命名空间配置 Pod 配额](/docs/tasks/administer-cluster/quota-pod-namespace/)
+* [为命名空间配置默认的内存请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
+* [为命名空间配置默认的 CPU 请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
+* [为命名空间配置内存的最小和最大限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
+* [为命名空间配置 CPU 的最小和最大限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
+* [为命名空间配置 CPU 和内存配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
+* [为命名空间配置 Pod 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
<!--
### For app developers
@@ -268,9 +236,7 @@ kubectl delete namespace quota-object-example
### 应用开发者参考
-* [为容器和 Pod 分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/)
-* [为容器和 Pod 分配 CPU 资源](/docs/tasks/configure-pod-container/assign-cpu-resource/)
-* [为 Pod 配置服务质量](/docs/tasks/configure-pod-container/quality-service-pod/)
-
-
+* [为容器和 Pod 分配内存资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)
+* [为容器和 Pod 分配 CPU 资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/)
+* [为 Pod 配置服务质量](/zh/docs/tasks/configure-pod-container/quality-service-pod/)
diff --git a/content/zh/docs/tasks/administer-cluster/reconfigure-kubelet.md b/content/zh/docs/tasks/administer-cluster/reconfigure-kubelet.md
index 126cbf4b19..1a4867a9e7 100644
--- a/content/zh/docs/tasks/administer-cluster/reconfigure-kubelet.md
+++ b/content/zh/docs/tasks/administer-cluster/reconfigure-kubelet.md
@@ -1,18 +1,14 @@
---
-title: 在实时集群上重新配置节点的 Kubelet
+title: 在运行中的集群上重新配置节点的 kubelet
content_type: task
---
<!--
-
----
reviewers:
- mtaufen
- dawnchen
title: Reconfigure a Node's Kubelet in a Live Cluster
content_type: task
----
-
-->
<!-- overview -->
@@ -24,12 +20,12 @@ content_type: task
allows you to change the configuration of each Kubelet in a live Kubernetes
cluster by deploying a ConfigMap and configuring each Node to use it.
-->
-[动态Kubelet配置](https://github.com/kubernetes/enhancements/issues/281)
-引导你在一个运行的 Kubernetes 集群上更改每一个 Kubelet 的配置，通过部署 ConfigMap 并配置每个节点来使用它。
+[动态 kubelet 配置](https://github.com/kubernetes/enhancements/issues/281)
+允许你在一个运行的 Kubernetes 集群上通过部署 ConfigMap
+并配置每个节点来使用它来更改每个 kubelet 的配置，。
-{{< warning >}}
<!--
-All Kubelet configuration parameters can be changed dynamically,
+All kubelet configuration parameters can be changed dynamically,
but this is unsafe for some parameters. Before deciding to change a parameter
dynamically, you need a strong understanding of how that change will affect your
cluster's behavior. Always carefully test configuration changes on a small set
@@ -37,34 +33,58 @@ of nodes before rolling them out cluster-wide. Advice on configuring specific
fields is available in the inline `KubeletConfiguration`
[type documentation](https://github.com/kubernetes/kubernetes/blob/release-1.11/pkg/kubelet/apis/kubeletconfig/v1beta1/types.go).
-->
-**警告**：所有Kubelet配置参数都可以动态地更改，但这对某些参数来说是不安全的。在决定动态更改参数之前，你需要深刻理解这种变化将如何影响你的集群的行为。
-在把一组节点推广到集群范围之前，都要仔细地测试这些节点上的配置变化。与配置相关的建议可以在具体的文件下找到，内联 `KubeletConfiguration`
-[类型文档](https://github.com/kubernetes/kubernetes/blob/release-1.11/pkg/kubelet/apis/kubeletconfig/v1beta1/types.go)。
+{{< warning >}}
+所有 kubelet 配置参数都可以动态更改，但这对某些参数来说是不安全的。
+在决定动态更改参数之前，你需要深刻理解这种变化将如何影响你的集群的行为。
+在把一组变更推广到集群范围之前，需要在较小规模的节点集合上仔细地测试这些配置变化。
+与特定字段配置相关的建议可以在源码中 `KubeletConfiguration`
+[类型文档](https://github.com/kubernetes/kubernetes/blob/release-1.11/pkg/kubelet/apis/kubeletconfig/v1beta1/types.go)中找到。
{{< /warning >}}
-
-
## {{% heading "prerequisites" %}}
<!--
-- Kubernetes v1.11 or higher on both the Master and the Nodes
-- kubectl v1.11 or higher, configured to communicate with the cluster
-- The Kubelet's `--dynamic-config-dir` flag must be set to a writable
- directory on the Node.
+You need to have a Kubernetes cluster.
+You also need kubectl v1.11 or higher, configured to communicate with your cluster.
+{{< version-check >}}
+Your cluster API server version (eg v1.12) must be no more than one minor
+version away from the version of kubectl that you are using. For example,
+if your cluster is running v1.16 then you can use kubectl v1.15, v1.16
+or v1.17; other combinations
+[aren't supported](/docs/setup/release/version-skew-policy/#kubectl).
-->
+你需要一个 Kubernetes 集群。
+你需要 v1.11 或更高版本的 kubectl，并以配置好与集群通信。
+{{< version-check >}}
+你的集群 API 服务器版本（如 v1.12）不能比你所用的 kubectl
+的版本差不止一个小版本号。
+例如，如果你的集群在运行 v1.16，那么你可以使用 v1.15、v1.16、v1.17 的 kubectl，
+所有其他的组合都是
+[不支持的](/zh/docs/setup/release/version-skew-policy/#kubectl)。
-- Kubernetes v1.11 或者更高版本配置在主节点和节点上
-- kubectl v1.11 或者更高版本和集群配置通信
-- The Kubelet `--dynamic-config-dir` flag 必须设置在节点的可写目录上
+<!--
+Some of the examples use the command line tool
+[jq](https://stedolan.github.io/jq/). You do not need `jq` to complete the task,
+because there are manual alternatives.
+For each node that you're reconfiguring, you must set the kubelet
+`-dynamic-config-dir` flag to a writable directory.
+-->
+某些例子中使用了命令行工具 [jq](https://stedolan.github.io/jq/)。
+你并不一定需要 `jq` 才能完成这些任务，因为总是有一些手工替代的方式。
+针对你所重新配置的每个节点，你必须设置 kubelet 的参数
+`-dynamic-config-dir`，使之指向一个可写的目录。
<!-- steps -->
-<!-- ## Reconfiguring the Kubelet on a Live Node in your Cluster -->
-## 在你集群中的一个实时节点上配置Kubelet
+<!--
+## Reconfiguring the kubelet on a running node in your cluster
+
+### Basic Workflow Overview
+-->
+## 重配置 集群中运行节点上的 kubelet
-<!-- ### Basic Workflow Overview -->
### 基本工作流程概述
<!--
@@ -75,24 +95,25 @@ Kubelet's configuration.
2. Wrap this file in a ConfigMap and save it to the Kubernetes control plane.
3. Update the Kubelet's corresponding Node object to use this ConfigMap.
-->
-在实时集群中配置 Kubelet 的基本工作流程如下：
+在运行中的集群中配置 kubelet 的基本工作流程如下：
-1. 编写一个 YAML 或 JSON 的配置文件包含 Kubelet 的配置。
+1. 编写一个 YAML 或 JSON 的配置文件包含 kubelet 的配置。
2. 将此文件包装在 ConfigMap 中并将其保存到 Kubernetes 控制平面。
-3. 更新 Kubelet 的相应节点对象以使用此 ConfigMap。
+3. 更新 kubelet 的相应节点对象以使用此 ConfigMap。
<!--
-Each Kubelet watches a configuration reference on its respective Node object.
+Each kubelet watches a configuration reference on its respective Node object.
When this reference changes, the Kubelet downloads the new configuration,
updates a local reference to refer to the file, and exits.
For the feature to work correctly, you must be running an OS-level service
manager (such as systemd), which will restart the Kubelet if it exits. When the
Kubelet is restarted, it will begin using the new configuration.
-->
-每个 Kubelet 都会在其各自的节点对象上查看配置引用。当此引用更改时，Kubelet 将下载新配置，
+每个 kubelet 都会在其各自的节点对象上监测（Watch）配置引用。当引用更改时，kubelet 将下载新配置，
更新本地引用以引用该文件，然后退出。
-要想使该功能正常地工作，您必须运行操作系统级别的服务管理器（如systemd），如果退出，将重启Kubelet。
-当Kubelet重新启动时，它将开始使用新配置。
+要想使该功能正常地工作，你必须运行操作系统级别的服务管理器（如 systemd），
+在 kubelet 退出时将其重启。
+kubelet 重新启动时，将开始使用新配置。
<!--
The new configuration completely overrides configuration provided by `--config`,
@@ -100,8 +121,9 @@ and is overridden by command-line flags. Unspecified values in the new configura
will receive default values appropriate to the configuration version
(e.g. `kubelet.config.k8s.io/v1beta1`), unless overridden by flags.
-->
-这个新配置完全地覆盖 `--config` 所提供的配置，并被命令行标志覆盖。新配置中未指定的值将收到适合配置版本的默认值
-(e.g. `kubelet.config.k8s.io/v1beta1`)，除非被标志覆盖。
+这个新配置完全地覆盖 `--config` 所提供的配置，并被命令行标志覆盖。
+新配置中未指定的值将收到适合配置版本的默认值
+(e.g. `kubelet.config.k8s.io/v1beta1`)，除非被命令行标志覆盖。
<!--
The status of the Node's Kubelet configuration is reported via
@@ -109,50 +131,54 @@ The status of the Node's Kubelet configuration is reported via
ConfigMap, you can observe this status to confirm that the Node is using the
intended configuration.
-->
-这个节点的 Kubelet 配置状态通过命令 `Node.Spec.Status.Config` 获取。一旦您已经改变了一个节点去使用新的 ConfigMap ，
-您就可以观察此状态以确认这个节点正在使用的预期配置。
+节点 kubelet 配置状态可通过 `node.spec.status.config` 获取。
+一旦你已经改变了一个节点去使用新的 ConfigMap，
+就可以观察此状态以确认该节点正在使用的预期配置。
<!--
This document describes editing Nodes using `kubectl edit`.
There are other ways to modify a Node's spec, including `kubectl patch`, for
example, which facilitate scripted workflows.
-->
-这个文档描述编辑节点信息用命令 `kubectl edit`，还有一些其他的方式去修改节点的规范，包括命令 `kubectl patch`，
-例如，哪一个更利于脚本化的工作流程。
+本文用命令 `kubectl edit` 描述节点的编辑，还有一些其他的方式去修改节点的规约，
+包括更利于脚本化的工作流程的 `kubectl patch`。
<!--
This document only describes a single Node consuming each ConfigMap. Keep in
mind that it is also valid for multiple Nodes to consume the same ConfigMap.
-->
-这个文档仅仅讲述了在单节点上使用每一个 ConfigMap。请注意对于多个节点使用相同的 ConfigMap 也是有效的。
+本文仅仅讲述在单节点上使用每个 ConfigMap。请注意对于多个节点使用相同的 ConfigMap
+也是合法的。
-{{< warning >}}
<!--
While it is *possible* to change the configuration by
updating the ConfigMap in-place, this causes all Kubelets configured with
that ConfigMap to update simultaneously. It is much safer to treat ConfigMaps
-as immutable by convention, aided by `kubectl`'s `--append-hash` option,
+as immutable by convention, aided by `kubectl`'s `-append-hash` option,
and incrementally roll out updates to `Node.Spec.ConfigSource`.
-->
-**警告**：通过更新本地的 ConfigMap *有可能* 会改变配置信息，这样会导致所有 Kubelets 所配置的 ConfigMap 同步更新。
-它是更安全的去处理 ConfigMap 按照惯例不变，借助于 `kubectl`'s `--append-hash` 选项，并逐步把更新推广到 `Node.Spec.ConfigSource`。
+{{< warning >}}
+通过就地更新 ConfigMap 来更改配置是 *可能的*。
+尽管如此，这样做会导致所有配置为使用该 ConfigMap 的 kubelet 被同时更新。
+更安全的做法是按惯例将 ConfigMap 视为不可变更的，借助于
+`kubectl` 的 `--append-hash` 选项逐步把更新推广到 `node.spec.configSource`。
{{< /warning >}}
-<!-- ### Automatic RBAC rules for Node Authorizer -->
-### 节点授权器的自动RBAC规则
-
<!--
+### Automatic RBAC rules for Node Authorizer
+
Previously, you were required to manually create RBAC rules
to allow Nodes to access their assigned ConfigMaps. The Node Authorizer now
automatically configures these rules.
-->
-以前，您需要手动创建RBAC规则允许节点访问其分配的ConfigMaps。 节点授权器现在
-自动地配置这些规则。
+### 节点鉴权器的自动 RBAC 规则
-<!-- ### Generating a file that contains the current configuration -->
-### 生成包含当前配置的文件
+以前，你需要手动创建 RBAC 规则以允许节点访问其分配的 ConfigMap。节点鉴权器现在
+能够自动配置这些规则。
<!--
+### Generating a file that contains the current configuration
+
The Dynamic Kubelet Configuration feature allows you to provide an override for
the entire configuration object, rather than a per-field overlay. This is a
simpler model that makes it easier to trace the source of configuration values
@@ -160,131 +186,138 @@ and debug issues. The compromise, however, is that you must start with knowledge
of the existing configuration to ensure that you only change the fields you
intend to change.
-->
-动态 Kubelet 配置特性允许您提供覆盖对于整个配置对象，而不是每个字段的叠加。 这是一个
-更简单的模型，可以更轻松地跟踪配置值的来源和调试问题。 然而，妥协是你必须从现有配置的认识开始，
-以确保您只更改您打算修改的字段。
+### 生成包含当前配置的文件
+
+动态 kubelet 配置特性允许你为整个配置对象提供一个重载配置，而不是靠单个字段的叠加。
+这是一个更简单的模型，可以更轻松地跟踪配置值的来源，更便于调试问题。
+然而，相应的代价是你必须首先了解现有配置，以确保你只更改你打算修改的字段。
<!--
-Ideally, the Kubelet would be bootstrapped from a file on disk
-and you could edit this file (which could also be version-controlled),
-to create the first Kubelet ConfigMap
-(see [Set Kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file)),
-Currently, the Kubelet is bootstrapped with **a combination of this file and command-line flags**
-that can override the configuration in the file.
-As a workaround, you can generate a config file containing a Node's current
-configuration by accessing the Kubelet server's `configz` endpoint via the
-kubectl proxy. This endpoint, in its current implementation, is intended to be
-used only as a debugging aid. Do not rely on the of this endpoint for
-production scenarios. The examples below use the `jq` command to streamline
-working with JSON. To follow the tasks as written, you need to have `jq`
-installed, but you can adapt the tasks if you prefer to extract the
-`kubeletconfig` subobject manually.
+The kubelet loads settings from its configuration file, but you can set command
+line flags to override the configuration in the file. This means that if you
+only know the contents of the configuration file, and you don't know the
+command line overrides, then you do not know the running configuration either.
-->
-理想情况下，Kubelet 将被引导从磁盘上的一个文件，并且你可以编辑这个文件（也可以是版本控制的），
-去创建第一个 Kubelet ConfigMap (参考文档 [通过配置文件设置Kubelet参数](/docs/tasks/administer-cluster/kubelet-config-file))，
-目前，Kubelet 使用 **文件和命令行标志的组合** 进行引导来覆盖文件中的配置。
-作为解决方法，您可以生成一个配置文件包含节点当前的组态，通过 kubectl 代理访问Kubelet服务器的 `configz` 端点。
-该端点在其当前实现中，旨在被用来作为一个调试辅助工具。在生产环境下，不要依赖此端点的特性。
-下面的例子使用 `jq` 命令来简化使用 JSON。按照所写的步骤，您需要安装 `jq` ，
-但如果您喜欢手动提取 `kubeletconfig` 子对象，您也可以完成这个任务。
+组件 kubelet 从其配置文件中加载配置数据，不过你可以通过设置命令行标志
+来重载文件中的一些配置。这意味着，如果你仅知道配置文件的内容，而你不知道
+命令行重载了哪些配置，你就无法知道 kubelet 的运行时配置是什么。
+
+<!--
+Because you need to know the running configuration in order to override it,
+you can fetch the running configuration from the kubelet. You can generate a
+config file containing a Node's current configuration by accessing the kubelet's
+`configz` endpoint, through `kubectl proxy`. The next section explains how to
+do this.
+-->
+因为你需要知道运行时所使用的配置才能重载之，你可以从 kubelet 取回其运行时配置。
+你可以通过访问 kubelet 的 `configz` 末端来生成包含节点当前配置的配置文件；
+这一操作可以通过 `kubectl proxy` 来完成。
+下一节解释如何完成这一操作。
+
+<!--
+The kubelet's `configz` endpoint is there to help with debugging, and is not
+a stable part of kubelet behavior.
+Do not rely on the behavior of this endpoint for production scenarios or for
+use with automated tools.
+-->
+{{< caution >}}
+组件 `kubelet` 上的 `configz` 末端是用来协助调试的，并非 kubelet 稳定行为的一部分。
+请不要在产品环境下依赖此末端的行为，也不要在自动化工具中使用此末端。
+{{< /caution >}}
+
+<!--
+For more information on configuring the kubelet via a configuration file, see
+[Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file)).
+-->
+关于如何使用配置文件来配置 kubelet 行为的更多信息可参见
+[通过配置文件设置 kubelet 参数](/zh/docs/tasks/administer-cluster/kubelet-config-file)
+文档。
<!-- #### Generate the configuration file -->
#### 生成配置文件
+<!--
+The steps below use the `jq` command to streamline working with JSON.
+To follow the tasks as written, you need to have `jq` installed. You can
+adapt the steps if you prefer to extract the `kubeletconfig` subobject manually.
+-->
+{{< note >}}
+下面的任务步骤中使用了 `jq` 命令以方便处理 JSON 数据。为了完成这里讲述的任务，
+你需要安装 `jq`。如果你更希望手动提取 `kubeletconfig` 子对象，也可以对这里
+的对应步骤做一些调整。
+{{< /note >}}
+
<!--
1. Choose a Node to reconfigure. In this example, the name of this Node is
referred to as `NODE_NAME`.
2. Start the kubectl proxy in the background using the following command:
+-->
+1. 选择要重新配置的节点。在本例中，此节点的名称为 `NODE_NAME`。
+2. 使用以下命令在后台启动 kubectl 代理：
- ```bash
- kubectl proxy --port=8001 &
- ```
-
+ ```bash
+ kubectl proxy --port=8001 &
+ ```
+<!--
3. Run the following command to download and unpack the configuration from the
`configz` endpoint. The command is long, so be careful when copying and
pasting. **If you use zsh**, note that common zsh configurations add backslashes
to escape the opening and closing curly braces around the variable name in the URL.
For example: `${NODE_NAME}` will be rewritten as `$\{NODE_NAME\}` during the paste.
You must remove the backslashes before running the command, or the command will fail.
-
- ```bash
- NODE_NAME="the-name-of-the-node-you-are-reconfiguring"; curl -sSL "http://localhost:8001/api/v1/nodes/${NODE_NAME}/proxy/configz" | jq '.kubeletconfig|.kind="KubeletConfiguration"|.apiVersion="kubelet.config.k8s.io/v1beta1"' > kubelet_configz_${NODE_NAME}
- ```
-->
+3. 运行以下命令从 `configz` 端点中下载并解压配置。这个命令很长，因此在复制粘贴时要小心。
+ **如果你使用 zsh**，请注意常见的 zsh 配置要添加反斜杠转义 URL 中变量名称周围的大括号。
+ 例如：在粘贴时，`${NODE_NAME}` 将被重写为 `$\{NODE_NAME\}`。
+ 你必须在运行命令之前删除反斜杠，否则命令将失败。
-1. 选择一个节点去重新配置，在此示例中，此节点的名称为 `NODE_NAME`。
-2. 使用以下命令在后台启动 kubectl 代理：
+ ```bash
+ NODE_NAME="the-name-of-the-node-you-are-reconfiguring"; curl -sSL "http://localhost:8001/api/v1/nodes/${NODE_NAME}/proxy/configz" | jq '.kubeletconfig|.kind="KubeletConfiguration"|.apiVersion="kubelet.config.k8s.io/v1beta1"' > kubelet_configz_${NODE_NAME}
+ ```
- ```bash
- kubectl proxy --port=8001 &
- ```
-
-3. 运行以下命令从 `configz` 端点中下载并解压配置。这个命令很长，因此在复制和黏贴时要小心。
-**如果您使用 zsh**，请注意常见的 zsh 配置添加反斜杠转义 URL 中变量名称周围的大括号的开始和结束。
-例如：在粘贴期间，`$ {NODE_NAME}` 将被重写为 `$\{NODE_NAME\}`。
-您必须在运行命令之前删除反斜杠，否则命令将失败。
-
- ```bash
- NODE_NAME="the-name-of-the-node-you-are-reconfiguring"; curl -sSL "http://localhost:8001/api/v1/nodes/${NODE_NAME}/proxy/configz" | jq '.kubeletconfig|.kind="KubeletConfiguration"|.apiVersion="kubelet.config.k8s.io/v1beta1"' > kubelet_configz_${NODE_NAME}
- ```
-
-{{< note >}}
-
-**注意**：You need to manually add the `kind` and `apiVersion` to the downloaded
+<!--
+You need to manually add the `kind` and `apiVersion` to the downloaded
object，because they are not reported by the `configz` endpoint。
-您需要手动将 `kind` 和 `apiVersion` 添加到下载对象中，因为它们不是由 `configz` 端点报出的。
-
+-->
+{{< note >}}
+你需要手动将 `kind` 和 `apiVersion` 添加到下载对象中，因为它们不是由 `configz` 末端
+返回的。
{{< /note >}}
-<!-- #### Edit the configuration file -->
-#### 修改配置文件
<!--
+#### Edit the configuration file
+
Using a text editor, change one of the parameters in the
file generated by the previous procedure. For example, you
might edit the QPS parameter `eventRecordQPS`.
-->
+#### 修改配置文件
-使用文本编辑器，在这个文件里，改变之前的程序生成的一个参数。例如，你或许会修改 QPS 参数 `eventRecordQPS`。
-
-<!-- #### Push the configuration file to the control plane -->
-#### 把配置文件推送到控制平面
+使用文本编辑器，改变上述操作生成的文件中一个参数。
+例如，你或许会修改 QPS 参数 `eventRecordQPS`。
<!--
+#### Push the configuration file to the control plane
+
Push the edited configuration file to the control plane with the
following command:
-
-```bash
-kubectl -n kube-system create configmap my-node-config --from-file=kubelet=kubelet_configz_${NODE_NAME} --append-hash -o yaml
-```
-->
+#### 把配置文件推送到控制平面
-用以下命令把配置文件推送到控制平面：
+用以下命令把编辑后的配置文件推送到控制平面：
```bash
-kubectl -n kube-system create configmap my-node-config --from-file=kubelet=kubelet_configz_${NODE_NAME} --append-hash -o yaml
+kubectl -n kube-system create configmap my-node-config \
+ --from-file=kubelet=kubelet_configz_${NODE_NAME} \
+ --append-hash -o yaml
```
<!--
This is an example of a valid response:
-
-```none
-apiVersion: v1
-kind: ConfigMap
-metadata:
- creationTimestamp: 2017-09-14T20:23:33Z
- name: my-node-config-gkt4c2m4b2
- namespace: kube-system
- resourceVersion: "119980"
- selfLink: /api/v1/namespaces/kube-system/configmaps/my-node-config-gkt4c2m4b2
- uid: 946d785e-998a-11e7-a8dd-42010a800006
-data:
- kubelet: |
- {...}
-```
-->
-这是一个有效响应的例子：
+下面是合法响应的一个例子：
-```none
+```yaml
apiVersion: v1
kind: ConfigMap
metadata:
@@ -300,53 +333,40 @@ data:
```
<!--
-The ConfigMap is created in the `kube-system` namespace because this
-ConfigMap configures a Kubelet, which is Kubernetes system component.
+You created that ConfigMap inside the `kube-system` namespace because the kubelet
+is a Kubernetes system component.
-->
-
-ConfigMap 是在 `kube-system` 命名空间中创建的，因为 ConfigMap 配置了 Kubelet，它是 Kubernetes 的系统组件。
+你会在 `kube-system` 命名空间中创建 ConfigMap，因为 kubelet 是 Kubernetes 的系统组件。
<!--
-The `--append-hash` option appends a short checksum of the ConfigMap contents
+The `-append-hash` option appends a short checksum of the ConfigMap contents
to the name. This is convenient for an edit-then-push workflow, because it
automatically, yet deterministically, generates new names for new ConfigMaps.
The name that includes this generated hash is referred to as `CONFIG_MAP_NAME`
in the following examples.
-->
-
-`--append-hash` 选项给 ConfigMap 内容附加了一个简短校验和。这对于编辑然后推送工作流程很方便，因为它
-自动并确定地为新 ConfigMaps 生成新的名称。在以下示例中，包含生成的哈希名称为 `CONFIG_MAP_NAME`。
-
-<!-- #### Set the Node to use the new configuration -->
-#### 用新配置创建新的节点
+`--append-hash` 选项给 ConfigMap 内容附加了一个简短校验和。
+这对于先编辑后推送的工作流程很方便，
+因为它自动并确定地为新 ConfigMap 生成新的名称。
+在以下示例中，包含生成的哈希字符串的对象名被称为 `CONFIG_MAP_NAME`。
<!--
+#### Set the Node to use the new configuration
+
+
Edit the Node's reference to point to the new ConfigMap with the
following command:
-
-```bash
-kubectl edit node ${NODE_NAME}
-```
-
-In your text editor, add the following YAML under `spec`:
-
-```yaml
-configSource:
- configMap:
- name: CONFIG_MAP_NAME
- namespace: kube-system
- kubeletConfigKey: kubelet
-```
-->
-
-用下面的命令行编辑节点的参数来指向新的 ConfigMap：
+#### 配置节点使用新的配置
```bash
kubectl edit node ${NODE_NAME}
```
-<!-- In your text editor, add the following YAML under `spec`: -->
-在您的文本编辑器中，在 `spec` 下增添以下 YAML：
+<!--
+In your text editor, add the following YAML under `spec`:
+-->
+在你的文本编辑器中，在 `spec` 下增添以下 YAML：
```yaml
configSource:
@@ -361,14 +381,12 @@ You must specify all three of `name`, `namespace`, and `kubeletConfigKey`.
The `kubeletConfigKey` parameter shows the Kubelet which key of the ConfigMap
contains its config.
-->
-
-您必须指定这三个参数中的每一个`name`，`namespace`和`kubeletConfigKey`。
-`kubeletConfigKey`这个参数显示出 Kubelet 上的哪个 key 包含了 ConfigMap 的配置。
-
-<!-- #### Observe that the Node begins using the new configuration -->
-#### 使用新配置监察节点
+你必须同时指定 `name`、`namespace` 和 `kubeletConfigKey` 这三个属性。
+`kubeletConfigKey` 这个参数通知 kubelet ConfigMap 中的哪个键下面包含所要的配置。
<!--
+#### Observe that the Node begins using the new configuration
+
Retrieve the Node using the `kubectl get node ${NODE_NAME} -o yaml` command and inspect
`Node.Status.Config`. The config sources corresponding to the `active`,
`assigned`, and `lastKnownGood` configurations are reported in the status.
@@ -379,13 +397,16 @@ Retrieve the Node using the `kubectl get node ${NODE_NAME} -o yaml` command and
- The `lastKnownGood` configuration is the version the
Kubelet will fall back to if an invalid config is assigned in `Node.Spec.ConfigSource`.
-->
+#### 观察节点开始使用新配置
-用 `kubectl get node ${NODE_NAME} -o yaml` 命令回收节点并用命令 `Node.Status.Config` 检查节点状态配置。
-在这个状态报告的配置里，对应这些配置源`active`，`assigned`和 `lastKnownGood`。
+用 `kubectl get node ${NODE_NAME} -o yaml` 命令读取节点并检查 `node.status.config` 内容。
+状态部分报告了对应 `active`（使用中的）配置、`assigned`（被赋予的）配置和
+`lastKnownGood`（最近已知可用的）配置的配置源。
-- `active` 是 Kubelet 当前运行的版本。
-- `assigned` 参数是 Kubelet 基于 `Node.Spec.ConfigSource` 的最新版本。
-- `lastKnownGood` 参数是 Kubelet 的回退版本，如果在 `Node.Spec.ConfigSource` 中分配了无效的配置。
+- `active` 是 kubelet 当前运行时所使用的版本。
+- `assigned` 参数是 kubelet 基于 `node.spec.configSource` 所解析出来的最新版本。
+- `lastKnownGood` 参数是 kubelet 的回退版本；如果在 `node.spec.configSource` 中
+ 包含了无效的配置值，kubelet 可以回退到这个版本。
<!--
The`lastKnownGood` configuration might not be present if it is set to its default value,
@@ -394,60 +415,24 @@ match a valid `assigned` config after the Kubelet becomes comfortable with the c
The details of how the Kubelet determines a config should become the `lastKnownGood` are
not guaranteed by the API, but is currently implemented as a 10-minute grace period.
-->
-
-如果用本地的配置部署节点，使其设置成默认值，这个`lastKnownGood`配置可能不存在。
-在 Kubelet 配置好后，将更新 `lastKnownGood` 去匹配一个有效的 `assigned` 配置。
-判断如何配置 Kubelet 的细节是使`lastKnownGood`不受 API 限制，但目前实施为 10 分钟的宽限期。
+如果用本地配置部署节点，使其设置成默认值，这个 `lastKnownGood` 配置可能不存在。
+在 kubelet 配置好后，将更新 `lastKnownGood` 为一个有效的 `assigned` 配置。
+决定如何确定某配置成为 `lastKnownGood` 配置的细节并不在 API 保障范畴，
+不过目前实现中采用了 10 分钟的宽限期。
<!--
You can use the following command (using `jq`) to filter down
to the config status:
-
-```bash
-kubectl get no ${NODE_NAME} -o json | jq '.status.config'
-```
-
-The following is an example response:
-
-```json
-{
- "active": {
- "configMap": {
- "kubeletConfigKey": "kubelet",
- "name": "my-node-config-9mbkccg2cc",
- "namespace": "kube-system",
- "resourceVersion": "1326",
- "uid": "705ab4f5-6393-11e8-b7cc-42010a800002"
- }
- },
- "assigned": {
- "configMap": {
- "kubeletConfigKey": "kubelet",
- "name": "my-node-config-9mbkccg2cc",
- "namespace": "kube-system",
- "resourceVersion": "1326",
- "uid": "705ab4f5-6393-11e8-b7cc-42010a800002"
- }
- },
- "lastKnownGood": {
- "configMap": {
- "kubeletConfigKey": "kubelet",
- "name": "my-node-config-9mbkccg2cc",
- "namespace": "kube-system",
- "resourceVersion": "1326",
- "uid": "705ab4f5-6393-11e8-b7cc-42010a800002"
- }
- }
-}
-
-```
-->
-您可以使用以下命令（using `jq`）过滤到配置状态：
+你可以使用以下命令（使用 `jq`）过滤出配置状态：
```bash
kubectl get no ${NODE_NAME} -o json | jq '.status.config'
```
+<!--
+The following is an example response:
+-->
以下是一个响应示例：
```json
@@ -480,9 +465,15 @@ kubectl get no ${NODE_NAME} -o json | jq '.status.config'
}
}
}
-
```
+<!--
+If you do not have `jq`, you can look at the whole response and find `Node.Status.Config`
+by eye.
+-->
+如果你没有安装 `jq`，你可以查看整个响应对象，查找其中的 `node.status.config`
+部分。
+
<!--
If an error occurs, the Kubelet reports it in the `Node.Status.Config.Error`
structure. Possible errors are listed in
@@ -490,74 +481,72 @@ structure. Possible errors are listed in
You can search for the identical text in the Kubelet log for additional details
and context about the error.
-->
-
-如果发生错误，Kubelet 会在 `Node.Status.Config.Error` 中显示出它的结构体。可能的错误列在 [了解节点配置错误信息](#了解节点配置错误信息)。
-您可以在 Kubelet 日志中搜索相同的文本以获取更多详细信息和有关错误的上下文。
-
-<!-- #### Make more changes -->
-#### 做出更多的改变
+如果发生错误，kubelet 会在 `node.status.config.error` 中显示出错误信息的结构体。
+可能的错误列在[了解节点配置错误信息](#understanding-node-config-status-errors)节。
+你可以在 kubelet 日志中搜索相同的文本以获取更多详细信息和有关错误的上下文。
<!--
+#### Make more changes
+
Follow the workflow above to make more changes and push them again. Each time
-you push a ConfigMap with new contents, the --append-hash kubectl option creates
+you push a ConfigMap with new contents, the -append-hash kubectl option creates
the ConfigMap with a new name. The safest rollout strategy is to first create a
new ConfigMap, and then update the Node to use the new ConfigMap.
-->
+#### 做出更多的改变 {#make-more-changes}
-按照下面的工作流程做出更多的改变并再次推送它们。你每次推送一个 ConfigMap 的新内容时，--append-hash kubectl 选项都会给 ConfigMap 创建一个新的名称。
-最安全的推出策略是首先创建一个新的 ConfigMap，然后更新 节点 以使用新的 ConfigMap。
-
-<!-- #### Reset the Node to use its local default configuration -->
-#### 重置节点以使用其本地默认配置
+按照下面的工作流程做出更多的改变并再次推送它们。
+你每次推送一个 ConfigMap 的新内容时，kubeclt 的 `--append-hash` 选项都会给
+ConfigMap 创建一个新的名称。
+最安全的上线策略是首先创建一个新的 ConfigMap，然后更新节点以使用新的 ConfigMap。
<!--
+#### Reset the Node to use its local default configuration
+
To reset the Node to use the configuration it was provisioned with, edit the
Node using `kubectl edit node ${NODE_NAME}` and remove the
`Node.Spec.ConfigSource` field.
-->
-重置节点去使用已经配好的的配置，用 `kubectl edit node $ {NODE_NAME}` 命令编辑节点，并删除
-`Node.Spec.ConfigSource` 字段。
+#### 重置节点以使用其本地默认配置
-<!-- #### Observe that the Node is using its local default configuration -->
-#### 监察正在使用本地默认配置的节点
+要重置节点，使其使用节点创建时使用的配置，可以用
+`kubectl edit node $ {NODE_NAME}` 命令编辑节点，并删除 `node.spec.configSource`
+字段。
+
+<!--
+#### Observe that the Node is using its local default configuration
-<!--
After removing this subfield, `Node.Status.Config` eventually becomes
empty, since all config sources have been reset to `nil`, which indicates that
the local default config is `assigned`, `active`, and `lastKnownGood`, and no
error is reported.
-->
-在删除此字段后，`Node.Status.Config` 最终变成空，所有配置源都已重置为 `nil`，这表示
-本地默认配置是`assigned`，`active` 和 `lastKnownGood`这三个参数，没有报告错误。
-
+#### 观察节点正在使用本地默认配置
+在删除此字段后，`node.status.config` 最终变成空，所有配置源都已重置为 `nil`。
+这表示本地默认配置成为了 `assigned`、`active` 和 `lastKnownGood` 配置，
+并且没有报告错误。
<!-- discussion -->
-<!-- ## Kubectl Patch Example -->
-## Kubectl 补丁示例
-
<!--
+## `kubectl patch` example
+
You can change a Node's configSource using several different mechanisms.
This example uses `kubectl patch`:
-
-```bash
-kubectl patch node ${NODE_NAME} -p "{\"spec\":{\"configSource\":{\"configMap\":{\"name\":\"${CONFIG_MAP_NAME}\",\"namespace\":\"kube-system\",\"kubeletConfigKey\":\"kubelet\"}}}}"
-```
-->
+## `kubectl patch` 示例
-您可以使用几种不同的机制来更改节点的 configSource。
-这个例子使用`kubectl patch`：
+你可以使用几种不同的机制来更改节点的 configSource。
+
+本例使用`kubectl patch`：
```bash
kubectl patch node ${NODE_NAME} -p "{\"spec\":{\"configSource\":{\"configMap\":{\"name\":\"${CONFIG_MAP_NAME}\",\"namespace\":\"kube-system\",\"kubeletConfigKey\":\"kubelet\"}}}}"
```
-
-<!-- ## Understanding how the Kubelet checkpoints config -->
-
-## 了解 Kubelet 检查点的配置方式
-
<!--
+## Understanding how the Kubelet checkpoints config
+
When a new config is assigned to the Node, the Kubelet downloads and unpacks the
config payload as a set of files on the local disk. The Kubelet also records metadata
that locally tracks the assigned and last-known-good config sources, so that the
@@ -567,9 +556,13 @@ exits if it detects that the assigned config has changed. When the Kubelet is
restarted by the OS-level service manager (such as `systemd`), it reads the new
metadata and uses the new config.
-->
+## 了解 Kubelet 如何为配置生成检查点
-当为节点分配新配置时，Kubelet 会在本地磁盘上，下载并解压配置负载为一组文件。Kubelet 还记录元数据
-在本地跟踪已分配和最后已知良好的配置源，以便 Kubelet 知道在重新启动时使用哪个配置，即使 API 服务器变为不可用。在检查点配置和相关元数据之后，如果检测到已分配的配置改变了，则 Kubelet 退出。当 Kubelet 被 OS 级服务管理器（例如`systemd`）重新启动时，它会读取新的元数据并使用新配置。
+当为节点赋予新配置时，kubelet 会下载并解压配置负载为本地磁盘上的一组文件。
+kubelet 还记录一些元数据，用以在本地跟踪已赋予的和最近已知良好的配置源，以便
+kubelet 在重新启动时知道使用哪个配置，即使 API 服务器变为不可用。
+在为配置信息和相关元数据生成检查点之后，如果检测到已赋予的配置发生改变，则 kubelet 退出。
+当 kubelet 被 OS 级服务管理器（例如 `systemd`）重新启动时，它会读取新的元数据并使用新配置。
<!--
The recorded metadata is fully resolved, meaning that it contains all necessary
@@ -578,16 +571,20 @@ This is in contrast to `Node.Spec.ConfigSource`, where the intended config is de
via the idempotent `namespace/name` that identifies the target ConfigMap; the Kubelet
tries to use the latest version of this ConfigMap.
-->
-当记录的元数据已被完全解析时，意味着它包含的所有必需的信息去选择一个指定的
-配置版本通常是`UID`和`ResourceVersion`。与`Node.Spec.ConfigSource`形成对比，
-通过幂等`namespace/name`预期声明配置来标识目标 ConfigMap；Kubelet 尝试使用此 ConfigMap 的最新版本。
+当记录的元数据已被完全解析时，意味着它包含选择一个指定的配置版本所需的所有信息
+-- 通常是 `UID` 和 `ResourceVersion`。
+这与 `node.spec.configSource` 形成对比，后者通过幂等的 `namespace/name` 声明来标识
+目标 ConfigMap；kubelet 尝试使用此 ConfigMap 的最新版本。
<!--
When you are debugging problems on a node, you can inspect the Kubelet's config
metadata and checkpoints. The structure of the Kubelet's checkpointing directory is:
+-->
+当你在调试节点上问题时，可以检查 kubelet 的配置元数据和检查点。kubelet 的检查点目录结构是：
+<!--
```none
-- --dynamic-config-dir (root for managing dynamic config)
+- -dynamic-config-dir (root for managing dynamic config)
| - meta
| - assigned (encoded kubeletconfig/v1beta1.SerializedNodeConfigSource object, indicating the assigned config)
| - last-known-good (encoded kubeletconfig/v1beta1.SerializedNodeConfigSource object, indicating the last-known-good config)
@@ -599,97 +596,61 @@ metadata and checkpoints. The structure of the Kubelet's checkpointing directory
```
-->
-当您在节点上调试问题时，可以检查 Kubelet 的配置元数据和检查点。Kubelet 的检查点目录结构是：
-
```none
-- --dynamic-config-dir (root for managing dynamic config)
-| - meta
- | - assigned (encoded kubeletconfig/v1beta1.SerializedNodeConfigSource object, indicating the assigned config)
- | - last-known-good (encoded kubeletconfig/v1beta1.SerializedNodeConfigSource object, indicating the last-known-good config)
+- --dynamic-config-dir （用于管理动态配置的根目录）
+|-- meta
+ | - assigned （编码后的 kubeletconfig/v1beta1.SerializedNodeConfigSource 对象，对应赋予的配置）
+ | - last-known-good （编码后的 kubeletconfig/v1beta1.SerializedNodeConfigSource 对象，对应最近已知可用配置）
| - checkpoints
- | - uid1 (dir for versions of object identified by uid1)
- | - resourceVersion1 (dir for unpacked files from resourceVersion1 of object with uid1)
+ | - uid1 （用 uid1 来标识的对象版本目录)
+ | - resourceVersion1 （uid1 对象 resourceVersion1 版本下所有解压文件的目录）
| - ...
| - ...
```
-<!-- ## Understanding Node.Status.Config.Error messages -->
+<!--
+## Understanding Node.Status.Config.Error messages {#understanding-node-config-status-errors}
-## 了解节点配置错误信息
-
-<!--
The following table describes error messages that can occur
when using Dynamic Kubelet Config. You can search for the identical text
in the Kubelet log for additional details and context about the error.
-->
+## 了解节点配置错误信息 {#understanding-node-config-status-errors}
-下表描述了使用 Dynamic Kubelet 配置时可能发生的错误消息。您可以在 Kubelet 日志中搜索相同的文本
-来获取有关错误的其他详细信息和上下文。
+下表描述了使用动态 kubelet 配置时可能发生的错误消息。
+你可以在 kubelet 日志中搜索相同的文本来获取有关错误的其他详细信息和上下文。
<!--
-<table>
-<table align="left">
-<tr>
- <th>Error Message</th>
- <th>Possible Causes</th>
-</tr>
-<tr>
- <td><p>failed to load config, see Kubelet log for details</p></td>
- <td><p>The Kubelet likely could not parse the downloaded config payload, or encountered a filesystem error attempting to load the payload from disk.</p></td>
-</tr>
-<tr>
- <td><p>failed to validate config, see Kubelet log for details</p></td>
- <td><p>The configuration in the payload, combined with any command-line flag overrides, and the sum of feature gates from flags, the config file, and the remote payload, was determined to be invalid by the Kubelet.</p></td>
-</tr>
-<tr>
- <td><p>invalid NodeConfigSource, exactly one subfield must be non-nil, but all were nil</p></td>
- <td><p>Since Node.Spec.ConfigSource is validated by the API server to contain at least one non-nil subfield, this likely means that the Kubelet is older than the API server and does not recognize a newer source type.</p></td>
-</tr>
-<tr>
- <td><p>failed to sync: failed to download config, see Kubelet log for details</p></td>
- <td><p>The Kubelet could not download the config. It is possible that Node.Spec.ConfigSource could not be resolved to a concrete API object, or that network errors disrupted the download attempt. The Kubelet will retry the download when in this error state.</p></td>
-</tr>
-<tr>
- <td><p>failed to sync: internal failure, see Kubelet log for details</p></td>
- <td><p>The Kubelet encountered some internal problem and failed to update its config as a result. Examples include filesystem errors and reading objects from the internal informer cache.</p></td>
-</tr>
-<tr>
- <td><p>internal failure, see Kubelet log for details</p></td>
- <td><p>The Kubelet encountered some internal problem while manipulating config, outside of the configuration sync loop.</p></td>
-</tr>
-</table>
+Error Message | Possible Causes
+:----------------| :----------------
+failed to load config, see Kubelet log for details | The kubelet likely could not parse the downloaded config payload, or encountered a filesystem error attempting to load the payload from disk.
+failed to validate config, see Kubelet log for details | The configuration in the payload, combined with any command-line flag overrides, and the sum of feature gates from flags, the config file, and the remote payload, was determined to be invalid by the kubelet.
+invalid NodeConfigSource, exactly one subfield must be non-nil, but all were nil | Since Node.Spec.ConfigSource is validated by the API server to contain at least one non-nil subfield, this likely means that the kubelet is older than the API server and does not recognize a newer source type.
+failed to sync: failed to download config, see Kubelet log for details | The kubelet could not download the config. It is possible that Node.Spec.ConfigSource could not be resolved to a concrete API object, or that network errors disrupted the download attempt. The kubelet will retry the download when in this error state.
+failed to sync: internal failure, see Kubelet log for details | The kubelet encountered some internal problem and failed to update its config as a result. Examples include filesystem errors and reading objects from the internal informer cache.
+internal failure, see Kubelet log for details | The kubelet encountered some internal problem while manipulating config, outside of the configuration sync loop.
-->
-<table>
-<table align="left">
-<tr>
- <th>错误信息</th>
- <th>可能的原因</th>
-</tr>
-<tr>
- <td><p>无法加载配置，请参阅 Kubelet 日志了解详细信息</p></td>
- <td><p>Kubelet可能无法解析下载配置的有效负载，或者当尝试从磁盘中加载有效负载时，遇到文件系统错误。</p></td>
-</tr>
-<tr>
- <td><p>无法验证配置，请参阅 Kubelet 日志了解详细信息</p></td>
- <td><p>有效负载中的配置将任何命令行标志所覆盖的和这些标志的特性们合并，包括配置文件和远程有效负载，
- 它们一起被 Kubelet 确定为无效。</p></td>
-</tr>
-<tr>
- <td><p>无效的 NodeConfigSource，理应刚好一个子字段必须是非空的，但这些字段都是空的</p></td>
- <td><p>由 API 服务器验证 Node.Spec.ConfigSource 是否包含至少一个非空子字段，可能原因是 Kubelet 比 API 服务器版本低，不识别更新的源类型。</p></td>
-</tr>
-<tr>
- <td><p>无法同步：无法下载配置，请参阅 Kubelet 日志了解详细信息</p></td>
- <td><p>Kubelet 无法下载配置。可能是 Node.Spec.ConfigSource 无法解析为具体的 API 对象，或者网络错误中断了下载。 当处于此错误状态时，Kubelet 将重新下载。</p></td>
-</tr>
-<tr>
- <td><p>无法同步：内部故障，请参阅 Kubelet 日志了解详细信息</p></td>
- <td><p>Kubelet遇到了一些内部问题，因此无法更新其配置。 例如包括文件系统错误和从内部函数缓存中读取对象。</p></td>
-</tr>
-<tr>
- <td><p>内部故障，请参阅 Kubelet 日志了解详细信息</p></td>
- <td><p>在配置同步循环之外操作配置时，Kubelet 遇到了一些内部问题。</p></td>
-</tr>
-</table>
+{{< table caption = "理解 node.status.config.error 消息" >}}
+ 错误信息 | 可能的原因
+:----------------| :----------------
+failed to load config, see Kubelet log for details | kubelet 可能无法解析下载配置的有效负载，或者当尝试从磁盘中加载有效负载时，遇到文件系统错误。
+failed to validate config, see Kubelet log for details | 有效负载中的配置，与命令行标志所产生的覆盖配置以及特行门控的组合、配置文件本身、远程负载被 kubelet 判定为无效。
+invalid NodeConfigSource, exactly one subfield must be non-nil, but all were nil | 由于 API 服务器负责对 node.spec.configSource 执行验证，检查其中是否包含至少一个非空子字段，这个消息可能意味着 kubelet 比 API 服务器版本低，因而无法识别更新的源类型。
+failed to sync: failed to download config, see Kubelet log for details | kubelet 无法下载配置数据。可能是 node.spec.configSource 无法解析为具体的 API 对象，或者网络错误破坏了下载。处于此错误状态时，kubelet 将重新尝试下载。
+failed to sync: internal failure, see Kubelet log for details | kubelet 遇到了一些内部问题，因此无法更新其配置。 例如：发生文件系统错误或无法从内部缓存中读取对象。
+internal failure, see Kubelet log for details | 在对配置进行同步的循环之外操作配置时，kubelet 遇到了一些内部问题。
+
+{{< /table >}}
+
+## {{% heading "whatsnext" %}}
+
+<!--
+ - For more information on configuring the kubelet via a configuration file, see
+[Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file).
+- See the reference documentation for [`NodeConfigSource`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodeconfigsource-v1-core)
+-->
+- 关于如何通过配置文件来配置 kubelet 的更多细节信息，可参阅
+ [使用配置文件设置 kubelet 参数](/zh/docs/tasks/administer-cluster/kubelet-config-file).
+- 阅读 API 文档中 [`NodeConfigSource`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodeconfigsource-v1-core) 说明
diff --git a/content/zh/docs/tasks/administer-cluster/running-cloud-controller.md b/content/zh/docs/tasks/administer-cluster/running-cloud-controller.md
index 1e0371908e..bef6360559 100644
--- a/content/zh/docs/tasks/administer-cluster/running-cloud-controller.md
+++ b/content/zh/docs/tasks/administer-cluster/running-cloud-controller.md
@@ -1,36 +1,37 @@
---
-reviewers:
-- luxas
-- thockin
-- wlan0
title: Kubernetes 云管理控制器
content_type: concept
---
<!--
----
reviewers:
- luxas
- thockin
- wlan0
title: Kubernetes Cloud Controller Manager
content_type: concept
----
-->
<!-- overview -->
-{{< feature-state state="beta" >}}
+{{< feature-state state="beta" for_k8s_version="v1.11" >}}
+
<!--
-Kubernetes v1.6 introduced a new binary called `cloud-controller-manager`. `cloud-controller-manager` is a daemon that embeds cloud-specific control loops. These cloud-specific control loops were originally in the `kube-controller-manager`. Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the `cloud-controller-manager` binary allows cloud vendors to evolve independently from the core Kubernetes code.
-
-The `cloud-controller-manager` can be linked to any cloud provider that satisfies [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go). For backwards compatibility, the [cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager) provided in the core Kubernetes project uses the same cloud libraries as `kube-controller-manager`. Cloud providers already supported in Kubernetes core are expected to use the in-tree cloud-controller-manager to transition out of Kubernetes core. In future Kubernetes releases, all cloud controller managers will be developed outside of the core Kubernetes project managed by sig leads or cloud vendors.
+Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the {{< glossary_tooltip text="`cloud-controller-manager`" term_id="cloud-controller-manager" >}} binary allows cloud vendors to evolve independently from the core Kubernetes code.
-->
-Kubernetes v1.6 包含一个新的二进制文件，叫做 `cloud-controller-manager`。`cloud-controller-manager` 是一个嵌入了特定云服务控制循环逻辑的守护进程。这些特定云服务控制循环逻辑最初存在于 `kube-controller-manager` 中。由于云服务提供商开发和发布的速度与 Kubernetes 项目不同，将服务提供商专用代码从 `cloud-controller-manager` 二进制中抽象出来有助于云服务厂商在 Kubernetes 核心代码之外独立进行开发。
-
-`cloud-controller-manager` 可以被链接到任何满足 [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go) 约束的云服务提供商。为了兼容旧版本，Kubernetes 核心项目中提供的 [cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager) 使用和 `kube-controller-manager` 相同的云服务类库。已经在 Kubernetes 核心项目中支持的云服务提供商预计将通过使用 in-tree 的 cloud-controller-manager 过渡到 Kubernetes 核心之外。在将来的 Kubernetes 发布中，所有的云管理控制器将在 Kubernetes 核心项目之外，由 sig 领导者或者云服务厂商进行开发。
-
-
+由于云驱动的开发和发布的步调与 Kubernetes 项目不同，将服务提供商专用代码抽象到
+{{< glossary_tooltip text="`cloud-controller-manager`" term_id="cloud-controller-manager" >}}
+二进制中有助于云服务厂商在 Kubernetes 核心代码之外独立进行开发。
+<!--
+The `cloud-controller-manager` can be linked to any cloud provider that satisfies [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go). For backwards compatibility, the [cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager) provided in the core Kubernetes project uses the same cloud libraries as `kube-controller-manager`. Cloud providers already supported in Kubernetes core are expected to use the in-tree cloud-controller-manager to transition out of Kubernetes core.
+-->
+`cloud-controller-manager` 可以被链接到任何满足
+[cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go)
+约束的云服务提供商。为了兼容旧版本，Kubernetes 核心项目中提供的
+[cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager)
+使用和 `kube-controller-manager` 相同的云服务类库。
+已经在 Kubernetes 核心项目中支持的云服务提供商预计将通过使用 in-tree 的 cloud-controller-manager
+过渡为非 Kubernetes 核心代码。
<!-- body -->
@@ -49,52 +50,68 @@ Every cloud has their own set of requirements for running their own cloud provid
### 需求
-每个云服务都有一套各自的需求用于系统平台的集成，这不应与运行 `kube-controller-manager` 的需求有太大差异。作为经验法则，你需要：
+每个云服务都有一套各自的需求用于系统平台的集成，这不应与运行
+`kube-controller-manager` 的需求有太大差异。作为经验法则，你需要：
-* 云服务认证 / 授权：您的云服务可能需要使用令牌或者 IAM 规则以允许对其 API 的访问
-* kubernetes 认证 / 授权：cloud-controller-manager 可能需要 RBAC 规则以访问 kubernetes apiserver
-* 高可用：类似于 kube-controller-manager，您可能希望通过主节点选举（默认开启）配置一个高可用的云管理控制器。
+* 云服务认证/授权：你的云服务可能需要使用令牌或者 IAM 规则以允许对其 API 的访问
+* kubernetes 认证/授权：cloud-controller-manager 可能需要 RBAC 规则以访问 kubernetes apiserver
+* 高可用：类似于 kube-controller-manager，你可能希望通过主节点选举（默认开启）配置一个高可用的云管理控制器。
<!--
### Running cloud-controller-manager
Successfully running cloud-controller-manager requires some changes to your cluster configuration.
+-->
+### 运行云管理控制器
+你需要对集群配置做适当的修改以成功地运行云管理控制器：
+
+<!--
* `kube-apiserver` and `kube-controller-manager` MUST NOT specify the `--cloud-provider` flag. This ensures that it does not run any cloud specific loops that would be run by cloud controller manager. In the future, this flag will be deprecated and removed.
* `kubelet` must run with `--cloud-provider=external`. This is to ensure that the kubelet is aware that it must be initialized by the cloud controller manager before it is scheduled any work.
+-->
+* 一定不要为 `kube-apiserver` 和 `kube-controller-manager` 指定 `--cloud-provider` 标志。
+ 这将保证它们不会运行任何云服务专用循环逻辑，这将会由云管理控制器运行。未来这个标记将被废弃并去除。
+* `kubelet` 必须使用 `--cloud-provider=external` 运行。
+ 这是为了保证让 kubelet 知道在执行任何任务前，它必须被云管理控制器初始化。
+<!--
Keep in mind that setting up your cluster to use cloud controller manager will change your cluster behaviour in a few ways:
+-->
+请记住，设置群集使用云管理控制器将用多种方式更改群集行为：
+<!--
* kubelets specifying `--cloud-provider=external` will add a taint `node.cloudprovider.kubernetes.io/uninitialized` with an effect `NoSchedule` during initialization. This marks the node as needing a second initialization from an external controller before it can be scheduled work. Note that in the event that cloud controller manager is not available, new nodes in the cluster will be left unschedulable. The taint is important since the scheduler may require cloud specific information about nodes such as their region or type (high cpu, gpu, high memory, spot instance, etc).
+-->
+* 指定了 `--cloud-provider=external` 的 kubelet 将被添加一个 `node.cloudprovider.kubernetes.io/uninitialized`
+ 的污点，导致其在初始化过程中不可调度（`NoSchedule`）。
+ 这将标记该节点在能够正常调度前，需要外部的控制器进行二次初始化。
+ 请注意，如果云管理控制器不可用，集群中的新节点会一直处于不可调度的状态。
+ 这个污点很重要，因为调度器可能需要关于节点的云服务特定的信息，比如他们的区域或类型
+ （高端 CPU、GPU 支持、内存较大、临时实例等）。
+
+<!--
* cloud information about nodes in the cluster will no longer be retrieved using local metadata, but instead all API calls to retrieve node information will go through cloud controller manager. This may mean you can restrict access to your cloud API on the kubelets for better security. For larger clusters you may want to consider if cloud controller manager will hit rate limits since it is now responsible for almost all API calls to your cloud from within the cluster.
+-->
+* 集群中节点的云服务信息将不再能够从本地元数据中获取，取而代之的是所有获取节点信息的
+ API 调用都将通过云管理控制器。这意味着你可以通过限制到 kubelet 云服务 API 的访问来提升安全性。
+ 在更大的集群中你可能需要考虑云管理控制器是否会遇到速率限制，
+ 因为它现在负责集群中几乎所有到云服务的 API 调用。
-
-As of v1.8, cloud controller manager can implement:
+<!--
+Cloud controller manager can implement:
* node controller - responsible for updating kubernetes nodes using cloud APIs and deleting kubernetes nodes that were deleted on your cloud.
* service controller - responsible for loadbalancers on your cloud against services of type LoadBalancer.
* route controller - responsible for setting up network routes on your cloud
* any other features you would like to implement if you are running an out-of-tree provider.
-->
-### 运行云管理控制器
+云管理控制器可以实现：
-您需要对集群配置做适当的修改以成功地运行云管理控制器：
-
-* 一定不要为 `kube-apiserver` 和 `kube-controller-manager` 指定 `--cloud-provider` 标志。这将保证它们不会运行任何云服务专用循环逻辑，这将会由云管理控制器运行。未来这个标记将被废弃并去除。
-* `kubelet` 必须使用 `--cloud-provider=external` 运行。这是为了保证让 kubelet 知道在执行任何任务前，它必须被云管理控制器初始化。
-
-请记住，设置群集使用云管理控制器将用多种方式更改群集行为：
-
-* 指定了 `--cloud-provider=external` 的 kubelet 将被添加一个 `node.cloudprovider.kubernetes.io/uninitialized` 的污点，导致其在初始化过程中不可调度（`NoSchedule`）。这将标记该节点在能够正常调度前，需要外部的控制器进行二次初始化。请注意，如果云管理控制器不可用，集群中的新节点会一直处于不可调度的状态。这个污点很重要，因为调度器可能需要关于节点的云服务特定的信息，比如他们的区域或类型（high cpu, gpu, high memory, spot instance 等）。
-* 集群中节点的云服务信息将不再能够从本地元数据中获取，取而代之的是所有获取节点信息的 API 调用都将通过云管理控制器。这意味着你可以通过限制到 kubelet 云服务 API 的访问来提升安全性。在更大的集群中您可能需要考虑云管理控制器是否会遇到速率限制，因为它现在负责集群中几乎所有到云服务的 API 调用。
-
-
-对于 v1.8 版本，云管理控制器可以实现：
-
-* node 控制器 - 负责使用云服务 API 更新 kubernetes 节点并删除在云服务上已经删除的 kubernetes 节点。
-* service 控制器 - 负责在云服务上为类型为 LoadBalancer 的 service 提供负载均衡器。
-* route 控制器 - 负责在云服务上配置网络路由。
-* 如果您使用的是 out-of-tree 提供商，请按需实现其余任意特性。
+* 节点控制器 - 负责使用云服务 API 更新 kubernetes 节点并删除在云服务上已经删除的 kubernetes 节点。
+* 服务控制器 - 负责在云服务上为类型为 LoadBalancer 的 service 提供负载均衡器。
+* 路由控制器 - 负责在云服务上配置网络路由。
+* 如果你使用的是 out-of-tree 提供商，请按需实现其余任意特性。
<!--
## Examples
@@ -102,28 +119,23 @@ As of v1.8, cloud controller manager can implement:
If you are using a cloud that is currently supported in Kubernetes core and would like to adopt cloud controller manager, see the [cloud controller manager in kubernetes core](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager).
For cloud controller managers not in Kubernetes core, you can find the respective projects in repos maintained by cloud vendors or sig leads.
-
-* [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
-* [keepalived](https://github.com/munnerz/keepalived-cloud-provider)
-* [Oracle Cloud Infrastructure](https://github.com/oracle/oci-cloud-controller-manager)
-* [Rancher](https://github.com/rancher/rancher-cloud-controller-manager)
-
-For providers already in Kubernetes core, you can run the in-tree cloud controller manager as a Daemonset in your cluster, use the following as a guideline:
-
-{{< codenew file="admin/cloud/ccm-example.yaml" >}}
-->
## 示例
-如果当前 Kubernetes 内核支持您使用的云服务，并且想要采用云管理控制器，请参见 [kubernetes 内核中的云管理控制器](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager)。
+如果当前 Kubernetes 内核支持你使用的云服务，并且想要采用云管理控制器，请参见
+[kubernetes 内核中的云管理控制器](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager)。
-对于不在 Kubernetes 内核中的云管理控制器，您可以在云服务厂商或 sig 领导者的源中找到对应的项目。
+对于不在 Kubernetes 核心代码库中的云管理控制器，你可以在云服务厂商或 SIG 领导者的源中找到对应的项目。
* [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
* [keepalived](https://github.com/munnerz/keepalived-cloud-provider)
* [Oracle Cloud Infrastructure](https://github.com/oracle/oci-cloud-controller-manager)
* [Rancher](https://github.com/rancher/rancher-cloud-controller-manager)
-对于已经存在于 Kubernetes 内核中的提供商，您可以在集群中将 in-tree 云管理控制器作为守护进程运行。请使用如下指南：
+<!--
+For providers already in Kubernetes core, you can run the in-tree cloud controller manager as a Daemonset in your cluster, use the following as a guideline:
+-->
+对于已经存在于 Kubernetes 内核中的提供商，你可以在集群中将 in-tree 云管理控制器作为守护进程运行。请使用如下指南：
{{< codenew file="admin/cloud/ccm-example.yaml" >}}
@@ -131,49 +143,59 @@ For providers already in Kubernetes core, you can run the in-tree cloud controll
## Limitations
Running cloud controller manager comes with a few possible limitations. Although these limitations are being addressed in upcoming releases, it's important that you are aware of these limitations for production workloads.
-
-### Support for Volumes
-
-Cloud controller manager does not implement any of the volume controllers found in `kube-controller-manager` as the volume integrations also require coordination with kubelets. As we evolve CSI (container storage interface) and add stronger support for flex volume plugins, necessary support will be added to cloud controller manager so that clouds can fully integrate with volumes. Learn more about out-of-tree CSI volume plugins [here](https://github.com/kubernetes/features/issues/178).
-
-### Scalability
-
-In the previous architecture for cloud providers, we relied on kubelets using a local metadata service to retrieve node information about itself. With this new architecture, we now fully rely on the cloud controller managers to retrieve information for all nodes. For very larger clusters, you should consider possible bottle necks such as resource requirements and API rate limiting.
-->
## 限制
运行云管理控制器会有一些可能的限制。虽然以后的版本将处理这些限制，但是知道这些生产负载的限制很重要。
+<!--
+### Support for Volumes
+
+Cloud controller manager does not implement any of the volume controllers found in `kube-controller-manager` as the volume integrations also require coordination with kubelets. As we evolve CSI (container storage interface) and add stronger support for flex volume plugins, necessary support will be added to cloud controller manager so that clouds can fully integrate with volumes. Learn more about out-of-tree CSI volume plugins [here](https://github.com/kubernetes/features/issues/178).
+-->
### 对 Volume 的支持
云管理控制器未实现 `kube-controller-manager` 中的任何 volume 控制器，因为和 volume 的集成还需要与 kubelet 协作。由于我们引入了 CSI (容器存储接口，container storage interface) 并对弹性 volume 插件添加了更强大的支持，云管理控制器将添加必要的支持，以使云服务同 volume 更好的集成。请在 [这里](https://github.com/kubernetes/features/issues/178) 了解更多关于 out-of-tree CSI volume 插件的信息。
+<!--
+### Scalability
+
+In the previous architecture for cloud providers, we relied on kubelets using a local metadata service to retrieve node information about itself. With this new architecture, we now fully rely on the cloud controller managers to retrieve information for all nodes. For very larger clusters, you should consider possible bottle necks such as resource requirements and API rate limiting.
+-->
### 可扩展性
-在以前为云服务提供商提供的架构中，我们依赖 kubelet 的本地元数据服务来获取关于它本身的节点信息。通过这个新的架构，现在我们完全依赖云管理控制器来获取所有节点的信息。对于非常大的集群，您需要考虑可能的瓶颈，例如资源需求和 API 速率限制。
+在以前为云服务提供商提供的架构中，我们依赖 kubelet 的本地元数据服务来获取关于它本身的节点信息。通过这个新的架构，现在我们完全依赖云管理控制器来获取所有节点的信息。对于非常大的集群，你需要考虑可能的瓶颈，例如资源需求和 API 速率限制。
<!--
### Chicken and Egg
The goal of the cloud controller manager project is to decouple development of cloud features from the core Kubernetes project. Unfortunately, many aspects of the Kubernetes project has assumptions that cloud provider features are tightly integrated into the project. As a result, adopting this new architecture can create several situations where a request is being made for information from a cloud provider, but the cloud controller manager may not be able to return that information without the original request being complete.
-
-A good example of this is the TLS bootstrapping feature in the Kubelet. Currently, TLS bootstrapping assumes that the Kubelet has the ability to ask the cloud provider (or a local metadata service) for all its address types (private, public, etc) but cloud controller manager cannot set a node's address types without being initialized in the first place which requires that the kubelet has TLS certificates to communicate with the apiserver.
-
-As this initiative evolves, changes will be made to address these issues in upcoming releases.
-
-## Developing your own Cloud Controller Manager
-
-To build and develop your own cloud controller manager, read the [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager.md) doc.
-->
### 鸡和蛋的问题
-云管理控制器的目标是将云服务特性的开发从 Kubernetes 核心项目中解耦。不幸的是，Kubernetes 项目的许多方面都假设云服务提供商的特性同项目紧密结合。因此，这种新架构的采用可能导致某些场景下，当一个请求需要从云服务提供商获取信息时，在该请求没有完成的情况下云管理控制器不能返回那些信息。
+云管理控制器的目标是将云服务特性的开发从 Kubernetes 核心项目中解耦。
+不幸的是，Kubernetes 项目的许多方面都假设云服务提供商的特性同项目紧密结合。
+因此，这种新架构的采用可能导致某些场景下，当一个请求需要从云服务提供商获取信息时，
+在该请求没有完成的情况下云管理控制器不能返回那些信息。
-Kubelet 中的 TLS 引导特性是一个很好的例子。目前，TLS 引导认为 Kubelet 有能力从云提供商（或本地元数据服务）获取所有的地址类型（私有、公用等），但在被初始化之前，云管理控制器不能设置节点地址类型，而这需要 kubelet 拥有 TLS 证书以和 apiserver 通信。
+<!--
+A good example of this is the TLS bootstrapping feature in the Kubelet. Currently, TLS bootstrapping assumes that the Kubelet has the ability to ask the cloud provider (or a local metadata service) for all its address types (private, public, etc) but cloud controller manager cannot set a node's address types without being initialized in the first place which requires that the kubelet has TLS certificates to communicate with the apiserver.
-随着这种措施的演进，将来的发行版中将作出改变来解决这些问题。
+As this initiative evolves, changes will be made to address these issues in upcoming releases.
+-->
+Kubelet 中的 TLS 引导特性是一个很好的例子。
+目前，TLS 引导认为 kubelet 有能力从云提供商（或本地元数据服务）获取所有的地址类型（私有、公用等），
+但在被初始化之前，云管理控制器不能设置节点地址类型，而这需要 kubelet 拥有
+TLS 证书以和 API 服务器通信。
-## 开发自己的云管理控制器
+随着整个动议的演进，将来的发行版中将作出改变来解决这些问题。
-要构建和开发您自己的云管理控制器，请阅读 [开发云管理控制器](/docs/tasks/administer-cluster/developing-cloud-controller-manager.md) 文档。
+## {{% heading "whatsnext" %}}
+
+<!--
+To build and develop your own cloud controller manager, read the [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager.md) doc.
+-->
+要构建和开发你自己的云管理控制器，请阅读
+[开发云管理控制器](/zh/docs/tasks/administer-cluster/developing-cloud-controller-manager/)
+文档。
diff --git a/content/zh/docs/tasks/administer-cluster/securing-a-cluster.md b/content/zh/docs/tasks/administer-cluster/securing-a-cluster.md
index 77a32f2bca..ee3a9cf5fa 100644
--- a/content/zh/docs/tasks/administer-cluster/securing-a-cluster.md
+++ b/content/zh/docs/tasks/administer-cluster/securing-a-cluster.md
@@ -1,14 +1,8 @@
---
-reviewers:
-- smarterclayton
-- liggitt
-- ericchiang
-- destijl
-title: 集群安全
+title: 保护集群安全
content_type: task
---
<!--
----
reviewers:
- smarterclayton
- liggitt
@@ -16,7 +10,6 @@ reviewers:
- destijl
title: Securing a Cluster
content_type: task
----
-->
<!-- overview -->
@@ -27,15 +20,10 @@ and provides recommendations on overall security.
-->
本文档涉及与保护集群免受意外或恶意访问有关的主题，并对总体安全性提出建议。
-
-
## {{% heading "prerequisites" %}}
-
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
<!-- steps -->
<!--
@@ -57,7 +45,7 @@ the cluster components. Note that some components and installation methods may e
HTTP and administrators should familiarize themselves with the settings of each component to identify
potentially unsecured traffic.
-->
-### 为 API 交互提供传输层安全 （TLS）
+### 为所有 API 交互使用传输层安全 （TLS）
Kubernetes 期望集群中所有的 API 通信在默认情况下都使用 TLS 加密，大多数安装方法也允许创建所需的证书并且分发到集群组件中。请注意，某些组件和安装方法可能使用 HTTP 来访问本地端口， 管理员应该熟悉每个组件的设置，以识别潜在的不安全的流量。
@@ -76,11 +64,15 @@ Consult the [authentication reference document](/docs/reference/access-authn-aut
-->
### API 认证
-安装集群时，选择一个 API 服务器的身份验证机制，去使用与之匹配的公共访问模式。例如，小型的单用户集群可能希望使用简单的证书或静态承载令牌方法。更大的集群则可能希望整合现有的、OIDC、LDAP 等允许用户分组的服务器。
+安装集群时，选择一个 API 服务器的身份验证机制，去使用与之匹配的公共访问模式。
+例如，小型的单用户集群可能希望使用简单的证书或静态承载令牌方法。
+更大的集群则可能希望整合现有的、OIDC、LDAP 等允许用户分组的服务器。
-所有 API 客户端都必须经过身份验证，即使它是基础设施的一部分，比如节点、代理、调度程序和卷插件。这些客户端通常使用 [服务帐户](/docs/reference/access-authn-authz/service-accounts-admin/) 或 X509 客户端证书，并在集群启动时自动创建或是作为集群安装的一部分进行设置。
+所有 API 客户端都必须经过身份验证，即使它是基础设施的一部分，比如节点、代理、调度程序和卷插件。
+这些客户端通常使用 [服务帐户](/zh/docs/reference/access-authn-authz/service-accounts-admin/)
+或 X509 客户端证书，并在集群启动时自动创建或是作为集群安装的一部分进行设置。
-如果您希望获取更多信息，请参考 [认证参考文档](/docs/reference/access-authn-authz/authentication/)。
+如果你希望获取更多信息，请参考[认证参考文档](/zh/docs/reference/access-authn-authz/authentication/)。
<!--
### API Authorization
@@ -92,11 +84,28 @@ resources (pods, services, nodes) and can be namespace or cluster scoped. A set
roles are provided that offer reasonable default separation of responsibility depending on what
actions a client might want to perform. It is recommended that you use the [Node](/docs/reference/access-authn-authz/node/) and [RBAC](/docs/reference/access-authn-authz/rbac/) authorizers together, in combination with the
[NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) admission plugin.
+-->
+### API 授权
+一旦通过身份认证，每个 API 的调用都将通过鉴权检查。
+Kubernetes 集成[基于角色的访问控制（RBAC）](/zh/docs/reference/access-authn-authz/rbac/)组件，
+将传入的用户或组与一组绑定到角色的权限匹配。
+这些权限将动作（get，create，delete）和资源（pod，service, node）在命名空间或者集群范围内结合起来，
+根据客户可能希望执行的操作，提供了一组提供合理的违约责任分离的外包角色。
+建议你将[节点](/zh/docs/reference/access-authn-authz/node/) 和
+[RBAC](/zh/docs/reference/access-authn-authz/rbac/) 一起作为授权者，再与
+[NodeRestriction](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)
+准入插件结合使用。
+
+<!--
As with authentication, simple and broad roles may be appropriate for smaller clusters, but as
more users interact with the cluster, it may become necessary to separate teams into separate
namespaces with more limited roles.
+-->
+与身份验证一样，简单而广泛的角色可能适合于较小的集群，但是随着更多的用户与集群交互，
+可能需要将团队划分成有更多角色限制的单独的命名空间。
+<!--
With authorization, it is important to understand how updates on one object may cause actions in
other places. For instance, a user may not be able to create pods directly, but allowing them to
create a deployment, which creates pods on their behalf, will let them create those pods
@@ -107,15 +116,14 @@ to prevent accidental escalation. You can make roles specific to your use case i
Consult the [authorization reference section](/docs/reference/access-authn-authz/authorization/) for more information.
-->
-### API 授权
+就鉴权而言，理解怎么样更新一个对象可能导致在其它地方的发生什么样的行为是非常重要的。
+例如，用户可能不能直接创建 Pod，但允许他们通过创建一个 Deployment 来创建这些 Pod，
+这将让他们间接创建这些 Pod。
+同样地，从 API 删除一个节点将导致调度到这些节点上的 Pod 被中止，并在其他节点上重新创建。
+原生的角色设计代表了灵活性和常见用例之间的平衡，但有限制的角色应该仔细审查，
+以防止意外升级。如果外包角色不满足你的需求，则可以为用例指定特定的角色。
-一旦使用授权，每个 API 的调用都将通过授权检查。Kubernetes 集成 [基于访问控制（RBAC）](/docs/reference/access-authn-authz/rbac/) 的组件，将传入的用户或组与一组绑定到角色的权限匹配。这些权限将动作（get，create，delete）和资源（pod，service, node）在命名空间或者集群范围内结合起来，根据客户可能希望执行的操作，提供了一组提供合理的违约责任分离的外包角色。建议您将[节点](/docs/reference/access-authn-authz/node/) 和 [RBAC](/docs/reference/access-authn-authz/rbac/) 一起作为授权者，再与 [NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) 准入插件结合使用。
-
-与身份验证一样，简单而广泛的角色可能适合于较小的集群，但是随着更多的用户与集群交互，可能需要将团队划分成有更多角色限制的单独的命名空间。
-
-使用授权时，理解怎么样更新一个对象可能导致在其它地方的发生什么样的行为是非常重要的。例如，用户可能不能直接创建 pod，但允许他们通过创建一个 deployment 来创建这些 pod，这将让他们间接创建这些 pod。同样地，从 API 删除一个节点将导致调度到这些节点上的 pod 被中止，并在其他节点上重新创建。外包角色代表了灵活性和常见用例之间的平衡，但有限制的角色应该仔细审查，以防止意外升级。如果外包角色不满足您的需求，则可以为用例指定特定的角色。
-
-如果您希望获取更多信息，请参考 [授权参考部分](/docs/reference/access-authn-authz/authorization/)。
+如果你希望获取更多信息，请参阅[鉴权参考](/zh/docs/reference/access-authn-authz/authorization/)。
<!--
## Controlling access to the Kubelet
@@ -128,11 +136,13 @@ Consult the [Kubelet authentication/authorization reference](/docs/admin/kubelet
-->
## 控制对 Kubelet 的访问
-Kubelet 公开 HTTPS 端点，这些端点授予节点和容器强大的控制权。默认情况下，Kubelet 允许对此 API 进行未经身份验证的访问。
+Kubelet 公开 HTTPS 端点，这些端点授予节点和容器强大的控制权。
+默认情况下，Kubelet 允许对此 API 进行未经身份验证的访问。
生产级别的集群应启用 Kubelet 身份验证和授权。
-如果您希望获取更多信息，请参考 [Kubelet 身份验证 / 授权参考](/docs/admin/kubelet-authentication-authorization)。
+如果你希望获取更多信息，请参考
+[Kubelet 身份验证/授权参考](/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)。
<!--
## Controlling the capabilities of a workload or user at runtime
@@ -143,7 +153,8 @@ cluster, themselves, and other resources.
-->
## 控制运行时负载或用户的能力
-Kubernetes 中的授权故意设置为了高层级，它侧重于对资源的粗行为。更强大的控制是以通过用例限制这些对象如何作用于集群、自身和其他资源上的**策略**存在的。
+Kubernetes 中的授权故意设置为了高层级，它侧重于对资源的粗粒度行为。
+更强大的控制是以通过用例限制这些对象如何作用于集群、自身和其他资源上的**策略**存在的。
<!--
### Limiting resource usage on a cluster
@@ -159,10 +170,14 @@ reserved resources like memory, or to provide default limits when none are speci
-->
### 限制集群上的资源使用
-[资源配额](/docs/concepts/policy/resource-quotas/)限制了授予命名空间的资源的数量或容量。这通常用于限制命名空间可以分配的 CPU、内存或持久磁盘的数量，但也可以控制每个命名空间中有多少个 pod、服务或卷的存在。
-
-[限制范围](/docs/tasks/administer-cluster/memory-default-namespace/)限制了上述某些资源的最大值或者最小值，以防止用户使用类似内存这样的通用保留资源时请求不合理的过高或过低的值，或者在没有指定的情况下提供默认限制。
+[资源配额](/zh/docs/concepts/policy/resource-quotas/)
+限制了授予命名空间的资源的数量或容量。
+这通常用于限制命名空间可以分配的 CPU、内存或持久磁盘的数量，但也可以控制
+每个命名空间中有多少个 Pod、服务或卷的存在。
+[限制范围](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)限制
+上述某些资源的最大值或者最小值，以防止用户使用类似内存这样的通用保留资源时请求
+不合理的过高或过低的值，或者在没有指定的情况下提供默认限制。
<!--
### Controlling what privileges containers run with
@@ -172,7 +187,17 @@ that allows it to request access to running as a specific Linux user on a node (
access to run privileged or access the host network, and other controls that would otherwise
allow it to run unfettered on a hosting node. [Pod security policies](/docs/concepts/policy/pod-security-policy/)
can limit which users or service accounts can provide dangerous security context settings. For example, pod security policies can limit volume mounts, especially `hostPath`, which are aspects of a pod that should be controlled.
+-->
+### 控制容器运行的特权
+Pod 定义包含了一个[安全上下文](/zh/docs/tasks/configure-pod-container/security-context/)，
+用于描述允许它请求访问某个节点上的特定 Linux 用户（如 root）、获得特权或访问主机网络、
+以及允许它在主机节点上不受约束地运行的其它控件。
+[Pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/)
+可以限制哪些用户或服务帐户可以提供危险的安全上下文设置。
+例如，Pod 的安全策略可以限制卷挂载，尤其是 `hostpath`，这些都是 Pod 应该控制的一些方面。
+
+<!--
Generally, most application workloads need limited access to host resources so they can
successfully run as a root process (uid 0) without access to host information. However,
considering the privileges associated with the root user, you should write application
@@ -180,11 +205,10 @@ containers to run as a non-root user. Similarly, administrators who wish to prev
client applications from escaping their containers should use a restrictive pod security
policy.
-->
-### 控制容器运行的特权
-
-pod 定义包含了一个[安全上下文](/docs/tasks/configure-pod-container/security-context/)，用于描述允许它请求访问某个节点上的特定 Linux 用户（如 root）、获得特权或访问主机网络、以及允许它在主机节点上不受约束地运行的其它控件。[Pod 安全策略](/docs/concepts/policy/pod-security-policy/)可以限制哪些用户或服务帐户可以提供危险的安全上下文设置。例如，pod 的安全策略可以限制卷挂载，尤其是 `hostpath`，这些都是 pod 应该控制的一些方面。
-
-一般来说，大多数应用程序需要限制对主机资源的访问，他们可以在不能访问主机信息的情况下成功以根进程（UID 0）运行。但是，考虑到与 root 用户相关的特权，在编写应用程序容器时，您应该使用非 root 用户运行。类似地，希望阻止客户端应用程序逃避其容器的管理员，应该使用限制性的 pod 安全策略。
+一般来说，大多数应用程序需要限制对主机资源的访问，
+他们可以在不能访问主机信息的情况下成功以根进程（UID 0）运行。
+但是，考虑到与 root 用户相关的特权，在编写应用程序容器时，你应该使用非 root 用户运行。
+类似地，希望阻止客户端应用程序逃避其容器的管理员，应该使用限制性的 pod 安全策略。
<!--
### Restricting network access
@@ -193,7 +217,15 @@ The [network policies](/docs/tasks/administer-cluster/declare-network-policy/) f
allows application authors to restrict which pods in other namespaces may access pods and ports
within their namespaces. Many of the supported [Kubernetes networking providers](/docs/concepts/cluster-administration/networking/)
now respect network policy.
+-->
+### 限制网络访问
+基于命名空间的[网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/)
+允许应用程序作者限制其它命名空间中的哪些 Pod 可以访问它们命名空间内的 Pod 和端口。
+现在已经有许多支持网络策略的
+[Kubernetes 网络供应商](/zh/docs/concepts/cluster-administration/networking/)。
+
+<!--
Quota and limit ranges can also be used to control whether users may request node ports or
load balanced services, which on many clusters can control whether those users applications
are visible outside of the cluster.
@@ -202,13 +234,11 @@ Additional protections may be available that control network rules on a per plug
environment basis, such as per-node firewalls, physically separating cluster nodes to
prevent cross talk, or advanced networking policy.
-->
-### 限制网络访问
+对于可以控制用户的应用程序是否在集群之外可见的许多集群，配额和限制范围也可用于
+控制用户是否可以请求节点端口或负载均衡服务。
-基于命名空间的[网络策略](/docs/tasks/administer-cluster/declare-network-policy/)允许应用程序作者限制其它命名空间中的哪些 pod 可以访问它们命名空间内的 pod 和端口。现在已经有许多支持网络策略的 [Kubernetes 网络供应商](/docs/concepts/cluster-administration/networking/)。
-
-对于可以控制用户的应用程序是否在集群之外可见的许多集群，配额和限制范围也可用于控制用户是否可以请求节点端口或负载均衡服务。
-
-在插件或者环境基础上控制网络规则可以增加额外的保护措施，比如节点防火墙、物理分离群集节点以防止串扰、或者高级的网络策略。
+在插件或者环境基础上控制网络规则可以增加额外的保护措施，比如节点防火墙、物理分离
+群集节点以防止串扰、或者高级的网络策略。
<!--
### Restricting cloud metadata API access
@@ -224,9 +254,14 @@ to the metadata API, and avoid using provisioning data to deliver secrets.
-->
### 限制云 metadata API 访问
-云平台（AWS, Azure, GCE 等）经常讲 metadate 本地服务暴露给实例。默认情况下，这些 API 可由运行在实例上的 pod 访问，并且可以包含该云节点的凭据或配置数据（如 kubelet 凭据）。这些凭据可以用于在集群内升级或在同一账户下升级到其他云服务。
+云平台（AWS, Azure, GCE 等）经常讲 metadate 本地服务暴露给实例。
+默认情况下，这些 API 可由运行在实例上的 Pod 访问，并且可以包含
+该云节点的凭据或配置数据（如 kubelet 凭据）。
+这些凭据可以用于在集群内升级或在同一账户下升级到其他云服务。
-在云平台上运行 Kubernetes 时，限制对实例凭据的权限，使用[网络策略](/docs/tasks/administer-cluster/declare-network-policy/)限制对 metadate API 的 pod 访问，并避免使用配置数据来传递机密。
+在云平台上运行 Kubernetes 时，限制对实例凭据的权限，使用
+[网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/)
+限制对 metadata API 的 pod 访问，并避免使用配置数据来传递机密。
<!--
### Controlling which nodes pods may access
@@ -241,11 +276,17 @@ As an administrator, a beta admission plugin `PodNodeSelector` can be used to fo
within a namespace to default or require a specific node selector, and if end users cannot
alter namespaces, this can strongly limit the placement of all of the pods in a specific workload.
-->
-### 控制 pod 可以访问那些节点
+### 控制 Pod 可以访问哪些节点
-默认情况下，对哪些节点可以运行 pod 没有任何限制。Kubernetes 给最终用户提供了[一组丰富的策略用于控制 pod 放在节点上的位置](/docs/concepts/configuration/assign-pod-node/)，以及[基于 pod 位置和驱逐的污点](/docs/concepts/configuration/taint-and-toleration/)。对于许多集群，可以约定由作者采用或者强制通过工具使用这些策略来分离工作负载。
+默认情况下，对哪些节点可以运行 pod 没有任何限制。
+Kubernetes 给最终用户提供了
+[一组丰富的策略用于控制 pod 放在节点上的位置](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)，
+以及[基于污点的 Pod 放置和驱逐](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。
+对于许多集群，可以约定由作者采用或者强制通过工具使用这些策略来分离工作负载。
-作为管理员，β 特性的准入插件 `PodNodeSelector` 可用于强制命名空间中的 pod 使用默认或需要使用特定的节点选择器。如果最终用户无法改变命名空间，这可以强烈地限制所有的 pod 在特定工作负载的位置。
+对于管理员，Beta 阶段的准入插件 `PodNodeSelector` 可用于强制命名空间中的 Pod
+使用默认或需要使用特定的节点选择器。
+如果最终用户无法改变命名空间，这可以强烈地限制所有的 pod 在特定工作负载的位置。
<!--
## Protecting cluster components from compromise
@@ -274,10 +315,16 @@ access to a subset of the keyspace is strongly recommended.
-->
### 限制访问 etcd
-对于 API 来说，拥有 etcd 后端的写访问权限，相当于获得了整个集群的 root 权限，并且可以使用写访问权限来相当快速地升级。从 API 服务器访问它们的 etcd 服务器，管理员应该使用广受信任的凭证，如通过 TLS 客户端证书的相互认证。往往，我们建议将 etcd 服务器隔离到只有API服务器可以访问的防火墙后面。
+对于 API 来说，拥有 etcd 后端的写访问权限，相当于获得了整个集群的 root 权限，
+并且可以使用写访问权限来相当快速地升级。
+从 API 服务器访问它们的 etcd 服务器，管理员应该使用广受信任的凭证，
+如通过 TLS 客户端证书的相互认证。
+通常，我们建议将 etcd 服务器隔离到只有API服务器可以访问的防火墙后面。
{{< caution >}}
-允许集群中其它组件拥有读或写全空间的权限去访问 etcd 实例，相当于授予群集管理员访问的权限。对于非 master 组件，强烈推荐使用单独的 etcd 实例，或者使用 etcd 的访问控制列表去限制只能读或者写空间的一个子集。
+允许集群中其它组件拥有读或写全空间的权限去访问 etcd 实例，相当于授予群集管理员访问的权限。
+对于非主控组件，强烈推荐使用单独的 etcd 实例，或者使用 etcd 的访问控制列表
+去限制只能读或者写空间的一个子集。
{{< /caution >}}
<!--
@@ -289,7 +336,9 @@ and archive the audit file on a secure server.
-->
### 开启审计日志
-[审计日志](/docs/tasks/debug-application-cluster/audit/)是 β 特性，记录了 API 在发生破坏时进行后续分析的操作。建议启用审计日志，并将审计文件归档到安全服务器上。
+[审计日志](/zh/docs/tasks/debug-application-cluster/audit/)是 Beta 特性，
+负责记录 API 操作以便在发生破坏时进行事后分析。
+建议启用审计日志，并将审计文件归档到安全服务器上。
<!--
### Restrict access to alpha or beta features
@@ -299,9 +348,11 @@ that result in security vulnerabilities. Always assess the value an alpha or bet
provide against the possible risk to your security posture. When in doubt, disable features you
do not use.
-->
-### 限制使用 α 和 β 特性
+### 限制使用 alpha 和 beta 特性
-Kubernetes 的 α 和 β 特性还在积极发展当中，可能存在导致安全漏洞的缺陷或错误。要始终评估 α 和 β 特性可能为您的安全态势带来的风险。当您怀疑存在风险时，可以禁用那些不需要使用的特性。
+Kubernetes 的 alpha 和 beta 特性还在努力开发中，可能存在导致安全漏洞的缺陷或错误。
+要始终评估 alpha 和 beta 特性可能为你的安全态势带来的风险。
+当你怀疑存在风险时，可以禁用那些不需要使用的特性。
<!--
### Rotate infrastructure credentials frequently
@@ -312,9 +363,13 @@ an authentication provider that can control how long issued tokens are available
lifetimes where possible. If you use service account tokens in external integrations, plan to
rotate those tokens frequently. For example, once the bootstrap phase is complete, a bootstrap token used for setting up nodes should be revoked or its authorization removed.
-->
-### 频繁回收基础证书
+### 频繁回收基础设施证书
-一个 secret 或凭据的寿命越短，攻击者就越难使用该凭据，在证书上设置短生命周期并实现自动回收，是控制安全的一个好方法。因此，使用身份验证提供程序时，应该要求可以控制发布令牌的可用时间，并尽可能使用短寿命。如果在外部集成中使用服务帐户令牌，则应该频繁地回收这些令牌。例如，一旦引导阶段完成，就应该撤销用于设置节点的引导令牌，或者取消它的授权。
+一个 Secret 或凭据的寿命越短，攻击者就越难使用该凭据。
+在证书上设置短生命周期并实现自动回收，是控制安全的一个好方法。
+因此，使用身份验证提供程序时，应该要求可以控制发布令牌的可用时间，并尽可能使用短寿命。
+如果在外部集成中使用服务帐户令牌，则应该频繁地回收这些令牌。
+例如，一旦引导阶段完成，就应该撤销用于设置节点的引导令牌，或者取消它的授权。
<!--
### Review third party integrations before enabling them
@@ -332,9 +387,16 @@ or run with elevated permissions if those service accounts are granted access to
-->
### 在启用第三方集成之前，请先审查它们
-许多集成到 Kubernetes 的第三方都可以改变您集群的安全配置。启用集成时，在授予访问权限之前，您应该始终检查扩展请求的权限。例如，许多安全集成可以请求访问来查看集群上的所有 secret，从而有效地使该组件成为集群管理。当有疑问时，如果可能的话，将集成限制在单个命名空间中运行。
+许多集成到 Kubernetes 的第三方都可以改变你集群的安全配置。
+启用集成时，在授予访问权限之前，你应该始终检查扩展所请求的权限。
+例如，许多安全集成可以请求访问来查看集群上的所有 Secret，
+从而有效地使该组件成为集群管理。
+当有疑问时，如果可能的话，将集成限制在单个命名空间中运行。
-如果组件创建的 pod 能够在命名空间中做一些类似 `kube-system` 命名空间中的事情，那么它也可能是出乎意料的强大。因为这些 pod 可以访问服务账户的 secret，或者，如果这些服务帐户被授予访问许可的 [pod 安全策略](/docs/concepts/policy/pod-security-policy/)的权限，它们能以高权限运行。
+如果组件创建的 Pod 能够在命名空间中做一些类似 `kube-system` 命名空间中的事情，
+那么它也可能是出乎意料的强大。
+因为这些 Pod 可以访问服务账户的 Secret，或者，如果这些服务帐户被授予访问许可的
+[Pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/)的权限，它们能以高权限运行。
<!--
### Encrypt secrets at rest
@@ -349,11 +411,16 @@ parties that gain access to your etcd backups from viewing the content of those
this feature is currently experimental, it may offer an additional level of defense when backups
are not encrypted or an attacker gains read access to etcd.
-->
-### 使用加密的 rest
+### 对 Secret 进行静态加密
-一般情况下，etcd 数据库包含了通过 Kubernetes API 可以访问到的所有信息，并且可以授予攻击者对集群状态的可见性。始终使用经过良好审查的备份和加密解决方案来加密备份，并考虑在可能的情况下使用全磁盘加密。
+一般情况下，etcd 数据库包含了通过 Kubernetes API 可以访问到的所有信息，
+并且可以授予攻击者对集群状态的可见性。
+始终使用经过良好审查的备份和加密解决方案来加密备份，并考虑在可能的情况下使用全磁盘加密。
-Kubernetes 1.7 包含了 [rest 加密](/docs/tasks/administer-cluster/encrypt-data/)，它是一个 α 特性，会加密 etcd 里面的 `Secret` 资源，以防止某一方通过查看这些 secret 的内容获取 etcd 的备份。虽然目前这还只是实验性的功能，但是在备份没有加密或者攻击者获取到 etcd 的读访问权限的时候，它能提供额外的防御层级。
+Kubernetes 1.7 包含了[静态数据加密](/zh/docs/tasks/administer-cluster/encrypt-data/)，
+它是一个 alpha 特性，会加密 etcd 里面的 `Secret` 资源，以防止某一方通过查看
+etcd 的备份文件查看到这些 Secret 的内容。虽然目前这还只是实验性的功能，
+但是在备份没有加密或者攻击者获取到 etcd 的读访问权限的时候，它能提供额外的防御层级。
<!--
### Receiving alerts for security updates and reporting vulnerabilities
@@ -364,7 +431,9 @@ page for more on how to report vulnerabilities.
-->
### 接收安全更新和报告漏洞的警报
-加入 [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernetes-announce) 组，能够获取有关安全公告的邮件。有关如何报告漏洞的更多信息，请参见 [安全报告](/security/)页面。
+加入 [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernetes-announce)
+组，能够获取有关安全公告的邮件。有关如何报告漏洞的更多信息，请参见
+[安全报告](/zh/docs/reference/issues-security/security/)页面。
diff --git a/content/zh/docs/tasks/administer-cluster/sysctl-cluster.md b/content/zh/docs/tasks/administer-cluster/sysctl-cluster.md
index a0677d067c..8091f60b2b 100644
--- a/content/zh/docs/tasks/administer-cluster/sysctl-cluster.md
+++ b/content/zh/docs/tasks/administer-cluster/sysctl-cluster.md
@@ -1,52 +1,46 @@
---
title: 在 Kubernetes 集群中使用 sysctl
-reviewers:
-- sttts
content_type: task
---
<!--
-
----
title: Using sysctls in a Kubernetes Cluster
reviewers:
- sttts
content_type: task
----
-
--->
<!-- overview -->
-{{< feature-state for_k8s_version="v1.11" state="beta" >}}
+
+{{< feature-state for_k8s_version="v1.12" state="beta" >}}
<!--
This document describes how to configure and use kernel parameters within a
-Kubernetes cluster using the sysctl interface.
---->
-本文档介绍如何通过 sysctl 接口在 Kubernetes 集群中配置和使用内核参数。
-
-
+Kubernetes cluster using the {{< glossary_tooltip term_id="sysctl" >}}
+interface.
+-->
+本文档介绍如何通过 {{< glossary_tooltip term_id="sysctl" >}}
+接口在 Kubernetes 集群中配置和使用内核参数。
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
<!-- steps -->
<!--
## Listing all Sysctl Parameters
---->
+-->
## 获取 Sysctl 的参数列表
<!--
In Linux, the sysctl interface allows an administrator to modify kernel
parameters at runtime. Parameters are available via the `/proc/sys/` virtual
process file system. The parameters cover various subsystems such as:
---->
-在 Linux 中，管理员可以通过 sysctl 接口修改内核运行时的参数。在 `/proc/sys/` 虚拟文件系统下存放许多内核参数。这些参数涉及了多个内核子系统，如：
+-->
+在 Linux 中，管理员可以通过 sysctl 接口修改内核运行时的参数。在 `/proc/sys/`
+虚拟文件系统下存放许多内核参数。这些参数涉及了多个内核子系统，如：
<!--
- kernel (common prefix: `kernel.`)
@@ -54,12 +48,12 @@ process file system. The parameters cover various subsystems such as:
- virtual memory (common prefix: `vm.`)
- MDADM (common prefix: `dev.`)
- More subsystems are described in [Kernel docs](https://www.kernel.org/doc/Documentation/sysctl/README).
---->
-- 内核子系统 (通常前缀为: `kernel.`)
-- 网络子系统 (通常前缀为: `net.`)
-- 虚拟内存子系统 (通常前缀为: `vm.`)
-- MDADM 子系统 (通常前缀为: `dev.`)
-- 更多子系统请参见 [内核文档](https://www.kernel.org/doc/Documentation/sysctl/README)。
+-->
+- 内核子系统（通常前缀为: `kernel.`）
+- 网络子系统（通常前缀为: `net.`）
+- 虚拟内存子系统（通常前缀为: `vm.`）
+- MDADM 子系统（通常前缀为: `dev.`）
+- 更多子系统请参见[内核文档](https://www.kernel.org/doc/Documentation/sysctl/README)。
<!--
To get a list of all parameters, you can run
@@ -67,27 +61,28 @@ To get a list of all parameters, you can run
若要获取完整的参数列表，请执行以下命令
```shell
-$ sudo sysctl -a
+sudo sysctl -a
```
<!--
## Enabling Unsafe Sysctls
---->
-## 启用非安全的 Sysctl 参数
-<!--
Sysctls are grouped into _safe_ and _unsafe_ sysctls. In addition to proper
namespacing a _safe_ sysctl must be properly _isolated_ between pods on the same
node. This means that setting a _safe_ sysctl for one pod
---->
-sysctl 参数分为 _安全_ 和 _非安全的_。_安全_ sysctl 参数除了需要设置恰当的命名空间外，在同一 node 上的不同 Pod 之间也必须是 _相互隔离的_。这意味着在 Pod 上设置 _安全_ sysctl 参数
+-->
+## 启用非安全的 Sysctl 参数
+
+sysctl 参数分为 _安全_ 和 _非安全的_。
+_安全_ sysctl 参数除了需要设置恰当的命名空间外，在同一 node 上的不同 Pod
+之间也必须是 _相互隔离的_。这意味着在 Pod 上设置 _安全_ sysctl 参数
<!--
- must not have any influence on any other pod on the node
- must not allow to harm the node's health
- must not allow to gain CPU or memory resources outside of the resource limits
of a pod.
---->
+-->
- 必须不能影响到节点上的其他 Pod
- 必须不能损害节点的健康
- 必须不允许使用超出 Pod 的资源限制的 CPU 或内存资源。
@@ -95,117 +90,130 @@ sysctl 参数分为 _安全_ 和 _非安全的_。_安全_ sysctl 参数除了
<!--
By far, most of the _namespaced_ sysctls are not necessarily considered _safe_.
The following sysctls are supported in the _safe_ set:
---->
-至今为止，大多数 _有命名空间的_ sysctl 参数不一定被认为是 _安全_ 的。以下几种 sysctl 参数是 _安全的_：
+-->
+至今为止，大多数 _有命名空间的_ sysctl 参数不一定被认为是 _安全_ 的。
+以下几种 sysctl 参数是 _安全的_：
-- `kernel.shm_rmid_forced`,
-- `net.ipv4.ip_local_port_range`,
-- `net.ipv4.tcp_syncookies`.
+- `kernel.shm_rmid_forced`
+- `net.ipv4.ip_local_port_range`
+- `net.ipv4.tcp_syncookies`
+- `net.ipv4.ping_group_range` （从 Kubernetes 1.18 开始）
-{{< note >}}
<!--
The example `net.ipv4.tcp_syncookies` is not namespaced on Linux kernel version 4.4 or lower.
---->
-**注意**: 示例中的 `net.ipv4.tcp_syncookies` 在Linux 内核 4.4 或更低的版本中是无命名空间的。
+-->
+{{< note >}}
+示例中的 `net.ipv4.tcp_syncookies` 在Linux 内核 4.4 或更低的版本中是无命名空间的。
{{< /note >}}
<!--
This list will be extended in future Kubernetes versions when the kubelet
supports better isolation mechanisms.
---->
-在未来的 Kubernetes 版本中，若kubelet 支持更好的隔离机制，则上述列表中将会列出更多 _安全的_ sysctl 参数。
+-->
+在未来的 Kubernetes 版本中，若 kubelet 支持更好的隔离机制，则上述列表中将会
+列出更多 _安全的_ sysctl 参数。
<!--
All _safe_ sysctls are enabled by default.
---->
+-->
所有 _安全的_ sysctl 参数都默认启用。
<!--
All _unsafe_ sysctls are disabled by default and must be allowed manually by the
cluster admin on a per-node basis. Pods with disabled unsafe sysctls will be
scheduled, but will fail to launch.
---->
-所有 _非安全的_ sysctl 参数都默认禁用，且必须由集群管理员在每个节点上手动开启。那些设置了不安全 sysctl 参数的 Pod 仍会被调度，但无法正常启动。
+-->
+所有 _非安全的_ sysctl 参数都默认禁用，且必须由集群管理员在每个节点上手动开启。
+那些设置了不安全 sysctl 参数的 Pod 仍会被调度，但无法正常启动。
<!--
With the warning above in mind, the cluster admin can allow certain _unsafe_
sysctls for very special situations like e.g. high-performance or real-time
application tuning. _Unsafe_ sysctls are enabled on a node-by-node basis with a
flag of the kubelet, e.g.:
---->
-参考上述警告，集群管理员只有在一些非常特殊的情况下（如：高可用或实时应用调整），才可以启用特定的 _非安全的_ sysctl 参数。如需启用 _非安全的_ sysctl 参数，请您在每个节点上分别设置 kubelet 命令行参数，例如：
+-->
+参考上述警告，集群管理员只有在一些非常特殊的情况下（如：高可用或实时应用调整），
+才可以启用特定的 _非安全的_ sysctl 参数。
+如需启用 _非安全的_ sysctl 参数，请你在每个节点上分别设置 kubelet 命令行参数，例如：
```shell
-$ kubelet --allowed-unsafe-sysctls \
+kubelet --allowed-unsafe-sysctls \
'kernel.msg*,net.core.somaxconn' ...
```
+
<!--
-For minikube, this can be done via the `extra-config` flag:
---->
-如果您使用 minikube，可以通过 `extra-config` 参数来配置：
+For {{< glossary_tooltip term_id="minikube" >}}, this can be done via the `extra-config` flag:
+-->
+如果你使用 {{< glossary_tooltip term_id="minikube" >}}，可以通过 `extra-config` 参数来配置：
```shell
-$ minikube start --extra-config="kubelet.AllowedUnsafeSysctls=kernel.msg*,net.core.somaxconn"...
+minikube start --extra-config="kubelet.AllowedUnsafeSysctls=kernel.msg*,net.core.somaxconn"...
```
<!--
Only _namespaced_ sysctls can be enabled this way.
---->
+-->
只有 _有命名空间的_ sysctl 参数可以通过该方式启用。
<!--
## Setting Sysctls for a Pod
---->
-## 设置 Pod 的 Sysctl 参数
-<!--
A number of sysctls are _namespaced_ in today's Linux kernels. This means that
they can be set independently for each pod on a node. Only namespaced sysctls
are configurable via the pod securityContext within Kubernetes.
---->
-目前，在 Linux 内核中，有许多的 sysctl 参数都是 _有命名空间的_ 。 这就意味着可以为节点上的每个 Pod 分别去设置它们的 sysctl 参数。 在 Kubernetes 中，只有那些有命名空间的 sysctl 参数可以通过 Pod 的 securityContext 对其进行配置。
+-->
+## 设置 Pod 的 Sysctl 参数
+
+目前，在 Linux 内核中，有许多的 sysctl 参数都是 _有命名空间的_ 。
+这就意味着可以为节点上的每个 Pod 分别去设置它们的 sysctl 参数。
+在 Kubernetes 中，只有那些有命名空间的 sysctl 参数可以通过 Pod 的 securityContext 对其进行配置。
<!--
The following sysctls are known to be namespaced. This list could change
in future versions of the Linux kernel.
---->
+-->
以下列出有命名空间的 sysctl 参数，在未来的 Linux 内核版本中，此列表可能会发生变化。
- `kernel.shm*`,
- `kernel.msg*`,
- `kernel.sem`,
- `fs.mqueue.*`,
-- `net.*`（内核中网络配置项相关参数），如果它可以在容器命名空间里被更改。然而，也有一些特例
- (例如，`net.netfilter.nf_conntrack_max` 和
- `net.netfilter.nf_conntrack_expect_max`
- 可以在容器命名空间里被更改，但它们是非命名空间的)。
+- `net.*`（内核中可以在容器命名空间里被更改的网络配置项相关参数）。然而也有一些特例
+ （例如，`net.netfilter.nf_conntrack_max` 和 `net.netfilter.nf_conntrack_expect_max`
+ 可以在容器命名空间里被更改，但它们是非命名空间的）。
<!--
Sysctls with no namespace are called _node-level_ sysctls. If you need to set
them, you must manually configure them on each node's operating system, or by
using a DaemonSet with privileged containers.
---->
-没有命名空间的 sysctl 参数称为 _节点级别的_ sysctl 参数。 如果需要对其进行设置，则必须在每个节点的操作系统上手动地去配置它们，或者通过在 DaemonSet 中运行特权模式容器来配置。
+-->
+没有命名空间的 sysctl 参数称为 _节点级别的_ sysctl 参数。
+如果需要对其进行设置，则必须在每个节点的操作系统上手动地去配置它们，
+或者通过在 DaemonSet 中运行特权模式容器来配置。
<!--
Use the pod securityContext to configure namespaced sysctls. The securityContext
applies to all containers in the same pod.
---->
-可使用 pod 的 securityContext 来配置有命名空间的 sysctl 参数，securityContext 应用于同一个 pod 中的所有容器。
+-->
+可使用 Pod 的 securityContext 来配置有命名空间的 sysctl 参数，
+securityContext 应用于同一个 Pod 中的所有容器。
<!--
This example uses the pod securityContext to set a safe sysctl
`kernel.shm_rmid_forced` and two unsafe sysctls `net.core.somaxconn` and
`kernel.msgmax` There is no distinction between _safe_ and _unsafe_ sysctls in
the specification.
---->
-此示例中，使用 Pod SecurityContext 来对一个安全的 sysctl 参数 `kernel.shm_rmid_forced` 以及两个非安全的 sysctl 参数 `net.core.somaxconn`和 `kernel.msgmax` 进行设置。在 Pod 规格中对 _安全的_ 和 _非安全的_ sysctl 参数不做区分。
+-->
+此示例中，使用 Pod SecurityContext 来对一个安全的 sysctl 参数
+`kernel.shm_rmid_forced` 以及两个非安全的 sysctl 参数
+`net.core.somaxconn` 和 `kernel.msgmax` 进行设置。
+在 Pod 规约中对 _安全的_ 和 _非安全的_ sysctl 参数不做区分。
-{{< warning >}}
<!--
Only modify sysctl parameters after you understand their effects, to avoid
destabilizing your operating system.
---->
-为了避免破坏操作系统的稳定性，请您在了解变更后果之后再修改 sysctl 参数。
+-->
+{{< warning >}}
+为了避免破坏操作系统的稳定性，请你在了解变更后果之后再修改 sysctl 参数。
{{< /warning >}}
```yaml
@@ -227,14 +235,15 @@ spec:
<!-- discussion -->
-
-{{< warning >}}
<!--
Due to their nature of being _unsafe_, the use of _unsafe_ sysctls
is at-your-own-risk and can lead to severe problems like wrong behavior of
containers, resource shortage or complete breakage of a node.
---->
-**警告**：由于 _非安全的_ sysctl 参数其本身具有不稳定性，在使用 _非安全的_ sysctl 参数时可能会导致一些严重问题，如容器的错误行为、机器资源不足或节点被完全破坏，用户需自行承担风险。
+-->
+{{< warning >}}
+由于 _非安全的_ sysctl 参数其本身具有不稳定性，在使用 _非安全的_ sysctl 参数
+时可能会导致一些严重问题，如容器的错误行为、机器资源不足或节点被完全破坏，
+用户需自行承担风险。
{{< /warning >}}
<!--
@@ -242,8 +251,11 @@ It is good practice to consider nodes with special sysctl settings as
_tainted_ within a cluster, and only schedule pods onto them which need those
sysctl settings. It is suggested to use the Kubernetes [_taints and toleration_
feature](/docs/reference/generated/kubectl/kubectl-commands/#taint) to implement this.
---->
-最佳实践方案是将集群中具有特殊 sysctl 设置的节点视为 _受感染的_，并且只调度需要使用到特殊 sysctl 设置的 Pod 到这些节点上。 建议使用 Kubernetes 的 [ _taints 和 toleration_ 特性](/docs/reference/generated/kubectl/kubectl-commands/#taint) 来实现它。
+-->
+最佳实践方案是将集群中具有特殊 sysctl 设置的节点视为 _有污点的_，并且只调度
+需要使用到特殊 sysctl 设置的 Pod 到这些节点上。
+建议使用 Kubernetes 的
+[污点和容忍度特性](/docs/reference/generated/kubectl/kubectl-commands/#taint) 来实现它。
<!--
A pod with the _unsafe_ sysctls will fail to launch on any node which has not
@@ -252,10 +264,11 @@ is recommended to use
[_taints and toleration_ feature](/docs/reference/generated/kubectl/kubectl-commands/#taint) or
[taints on nodes](/docs/concepts/configuration/taint-and-toleration/)
to schedule those pods onto the right nodes.
---->
-设置了 _非安全的_ sysctl 参数的 pod，在禁用了以下两种 _非安全的_ sysctl 参数配置的节点上启动都会失败。与 _节点级别的_ sysctl 一样，建议开启
-[_taints 和 toleration_ 特性](/docs/reference/generated/kubectl/kubectl-commands/#taint) 或
-[taints on nodes](/docs/concepts/configuration/taint-and-toleration/)
+-->
+设置了 _非安全的_ sysctl 参数的 Pod 在禁用了这两种 _非安全的_ sysctl 参数配置
+的节点上启动都会失败。与 _节点级别的_ sysctl 一样，建议开启
+[污点和容忍度特性](/docs/reference/generated/kubectl/kubectl-commands/#taint) 或
+[为节点配置污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)
以便将 Pod 调度到正确的节点之上。
## PodSecurityPolicy
@@ -266,56 +279,72 @@ sysctls or sysctl patterns in the `forbiddenSysctls` and/or
`allowedUnsafeSysctls` fields of the PodSecurityPolicy. A sysctl pattern ends
with a `*` character, such as `kernel.*`. A `*` character on its own matches
all sysctls.
---->
-您可以通过在 PodSecurityPolicy 的 `forbiddenSysctls` 和/或 `allowedUnsafeSysctls` 字段中，指定 sysctl 或填写 sysctl 匹配模式来进一步为 Pod 设置 sysctl 参数。sysctl 参数匹配模式以 `*` 字符结尾，如 `kernel.*`。 单独的 `*` 字符匹配所有 sysctl 参数。
+-->
+你可以通过在 PodSecurityPolicy 的 `forbiddenSysctls` 和/或 `allowedUnsafeSysctls`
+字段中，指定 sysctl 或填写 sysctl 匹配模式来进一步为 Pod 设置 sysctl 参数。
+sysctl 参数匹配模式以 `*` 字符结尾，如 `kernel.*`。
+单独的 `*` 字符匹配所有 sysctl 参数。
<!--
By default, all safe sysctls are allowed.
---->
+-->
所有 _安全的_ sysctl 参数都默认启用。
<!--
Both `forbiddenSysctls` and `allowedUnsafeSysctls` are lists of plain sysctl names
or sysctl patterns (which end with `*`). The string `*` matches all sysctls.
---->
-`forbiddenSysctls` 和 `allowedUnsafeSysctls` 的值都是字符串列表类型，可以添加 sysctl 参数名称，也可以添加 sysctl 参数匹配模式（以`*`结尾）。 只填写 `*` 则匹配所有的 sysctl 参数。
+-->
+`forbiddenSysctls` 和 `allowedUnsafeSysctls` 的值都是字符串列表类型，
+可以添加 sysctl 参数名称，也可以添加 sysctl 参数匹配模式（以`*`结尾）。
+只填写 `*` 则匹配所有的 sysctl 参数。
<!--
The `forbiddenSysctls` field excludes specific sysctls. You can forbid a
combination of safe and unsafe sysctls in the list. To forbid setting any
sysctls, use `*` on its own.
---->
-`forbiddenSysctls` 字段用于禁用特定的 sysctl 参数。 您可以在列表中禁用安全和非安全的 sysctl 参数的组合。 要禁用所有的 sysctl 参数，请设置为 `*`。
+-->
+`forbiddenSysctls` 字段用于禁用特定的 sysctl 参数。
+你可以在列表中禁用安全和非安全的 sysctl 参数的组合。
+要禁用所有的 sysctl 参数，请设置为 `*`。
<!--
If you specify any unsafe sysctl in the `allowedUnsafeSysctls` field and it is
not present in the `forbiddenSysctls` field, that sysctl can be used in Pods
using this PodSecurityPolicy. To allow all unsafe sysctls in the
PodSecurityPolicy to be set, use `*` on its own.
---->
-如果要在 `allowedUnsafeSysctls` 字段中指定一个非安全的 sysctl 参数，并且它在`forbiddenSysctls` 字段中未被禁用，则可以在 Pod 中通过 PodSecurityPolicy 启用该 sysctl 参数。 若要在 PodSecurityPolicy 中开启所有非安全的 sysctl 参数，请设 `allowedUnsafeSysctls` 字段值为 `*`。
+-->
+如果要在 `allowedUnsafeSysctls` 字段中指定一个非安全的 sysctl 参数，
+并且它在 `forbiddenSysctls` 字段中未被禁用，则可以在 Pod 中通过
+PodSecurityPolicy 启用该 sysctl 参数。
+若要在 PodSecurityPolicy 中开启所有非安全的 sysctl 参数，
+请设 `allowedUnsafeSysctls` 字段值为 `*`。
<!--
Do not configure these two fields such that there is overlap, meaning that a
given sysctl is both allowed and forbidden.
---->
-`allowedUnsafeSysctls` 与 `forbiddenSysctls` 两字段的配置不能重叠，否则这就意味着存在某个 sysctl 参数既被启用又被禁用。
+-->
+`allowedUnsafeSysctls` 与 `forbiddenSysctls` 两字段的配置不能重叠，
+否则这就意味着存在某个 sysctl 参数既被启用又被禁用。
-{{< warning >}}
<!--
If you whitelist unsafe sysctls via the `allowedUnsafeSysctls` field
in a PodSecurityPolicy, any pod using such a sysctl will fail to start
if the sysctl is not whitelisted via the `--allowed-unsafe-sysctls` kubelet
flag as well on that node.
--->
-**警告**：如果您通过 PodSecurityPolicy 中的 `allowedUnsafeSysctls` 字段将非安全的 sysctl 参数列入白名单，但该 sysctl 参数未通过 kubelet 命令行参数 `--allowed-unsafe-sysctls` 在节点上将其列入白名单，则设置了这个 sysctl 参数的 Pod 将会启动失败。
+{{< warning >}}
+如果你通过 PodSecurityPolicy 中的 `allowedUnsafeSysctls` 字段将非安全的 sysctl
+参数列入白名单，但该 sysctl 参数未通过 kubelet 命令行参数
+`--allowed-unsafe-sysctls` 在节点上将其列入白名单，则设置了这个 sysctl
+参数的 Pod 将会启动失败。
{{< /warning >}}
<!--
This example allows unsafe sysctls prefixed with `kernel.msg` to be set and
disallows setting of the `kernel.shm_rmid_forced` sysctl.
---->
-以下示例设置启用了以 `kernel.msg` 为前缀的非安全的 sysctl 参数，以及禁用了 sysctl 参数 `kernel.shm_rmid_forced`。
+-->
+以下示例设置启用了以 `kernel.msg` 为前缀的非安全的 sysctl 参数，同时禁用了
+sysctl 参数 `kernel.shm_rmid_forced`。
```yaml
apiVersion: policy/v1beta1
@@ -330,4 +359,3 @@ spec:
...
```
-
diff --git a/content/zh/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/zh/docs/tasks/configure-pod-container/assign-cpu-resource.md
index 86dcbc1ac5..19a48d27fb 100644
--- a/content/zh/docs/tasks/configure-pod-container/assign-cpu-resource.md
+++ b/content/zh/docs/tasks/configure-pod-container/assign-cpu-resource.md
@@ -5,11 +5,9 @@ weight: 20
---
<!--
----
title: Assign CPU Resources to Containers and Pods
content_type: task
weight: 20
----
-->
<!-- overview -->
@@ -20,15 +18,12 @@ a container. Containers cannot use more CPU than the configured limit.
Provided the system has CPU time free, a container is guaranteed to be
allocated as much CPU as it requests.
-->
-此页面显示如何将 CPU *request* 和 CPU *limit* 分配给一个容器。容器使用的 CPU 不能超过配额限制。
-如果系统有空闲的 CPU 时间，则可以保证根据请求给容器分配尽可能多的 CPU 资源。
-
-
-
+本页面展示如何为容器设置 CPU *request（请求）* 和 CPU *limit（限制）*。
+容器使用的 CPU 不能超过所配置的限制。
+如果系统有空闲的 CPU 时间，则可以保证给容器分配其所请求数量的 CPU 资源。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
@@ -42,55 +37,51 @@ running, you can skip those steps.
If you are running {{< glossary_tooltip term_id="minikube" >}}, run the
following command to enable metrics-server:
-->
+集群中的每个节点必须至少有 1 个 CPU 可用才能运行本任务中的示例。
-集群中的每个节点必须至少具有 1 个 CPU。
-
-此页面上的一些步骤要求您在集群中运行[metrics-server](https://github.com/kubernetes-incubator/metrics-server)
-服务。如果您的集群中已经有正在运行的 metrics-server 服务，那么您可以跳过这些步骤。
-
-如果您正在运行{{< glossary_tooltip term_id="minikube" >}}，请运行以下命令启用 metrics-server：
+本页的一些步骤要求你在集群中运行[metrics-server](https://github.com/kubernetes-incubator/metrics-server)
+服务。如果你的集群中已经有正在运行的 metrics-server 服务，可以跳过这些步骤。
+如果你正在运行{{< glossary_tooltip term_id="minikube" >}}，请运行以下命令启用 metrics-server：
```shell
minikube addons enable metrics-server
```
+
<!--
To see whether metrics-server (or another provider of the resource metrics
API, `metrics.k8s.io`) is running, type the following command:
-->
-
-查看是 metrics-server（或者其他资源度量 API 服务提供者，`metrics.k8s.io` ）是否正在运行，请键入以下命令：
+查看 metrics-server（或者其他资源度量 API `metrics.k8s.io` 服务提供者）是否正在运行，
+请键入以下命令：
```shell
kubectl get apiservices
```
+
<!--
If the resource metrics API is available, the output will include a
reference to `metrics.k8s.io`.
-->
-
-如果资源指标 API 可用，则会输出将包含一个参考信息 `metrics.k8s.io`。
-
+如果资源指标 API 可用，则会输出将包含一个对 `metrics.k8s.io` 的引用。
```
NAME
v1beta1.metrics.k8s.io
```
-
-
-
<!-- steps -->
-
<!--
## Create a namespace
Create a {{< glossary_tooltip term_id="namespace" >}} so that the resources you
create in this exercise are isolated from the rest of your cluster.
-->
-## 创建一个命名空间
-创建一个命名空间 {{< glossary_tooltip term_id="namespace" >}}，以便在本练习中创建的资源与集群的其余部分资源隔离。
+## 创建一个名字空间
+
+创建一个{{< glossary_tooltip text="名字空间" term_id="namespace" >}}，以便将
+本练习中创建的资源与集群的其余部分资源隔离。
```shell
kubectl create namespace cpu-example
@@ -112,21 +103,20 @@ The `-cpus "2"` argument tells the Container to attempt to use 2 CPUs.
Create the Pod:
-->
+## 指定 CPU 请求和 CPU 限制
-## 指定一个 CPU 请求和 CPU 限制
+要为容器指定 CPU 请求，请在容器资源清单中包含 `resources: requests` 字段。
+要指定 CPU 限制，请包含 `resources:limits`。
-要为容器指定 CPU 请求，请包含 `resources：requests` 字段
-在容器资源清单中。要指定 CPU 限制，请包含 `resources：limits`。
-
-在本练习中，您将创建一个具有一个容器的 Pod。容器将会请求 0.5 个 CPU，而且最多限制使用 1 个 CPU。
+在本练习中，你将创建一个具有一个容器的 Pod。容器将会请求 0.5 个 CPU，而且最多限制使用 1 个 CPU。
这是 Pod 的配置文件：
{{< codenew file="pods/resource/cpu-request-limit.yaml" >}}
配置文件的 `args` 部分提供了容器启动时的参数。
--cpus "2"参数告诉容器尝试使用 2 个 CPU。
+`-cpus "2"` 参数告诉容器尝试使用 2 个 CPU。
-创建 Pod 命令如下：
+创建 Pod：
```shell
kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit.yaml --namespace=cpu-example
@@ -135,7 +125,7 @@ kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit.yaml --
<!--
Verify that the Pod is running:
-->
-验证上述创建的 Pod 处于 Running 状态
+验证所创建的 Pod 处于 Running 状态
```shell
kubectl get pod cpu-demo --namespace=cpu-example
@@ -144,7 +134,7 @@ kubectl get pod cpu-demo --namespace=cpu-example
<!--
View detailed information about the Pod:
-->
-查看显示关于 Pod 的详细信息
+查看显示关于 Pod 的详细信息：
```shell
kubectl get pod cpu-demo --output=yaml --namespace=cpu-example
@@ -154,7 +144,6 @@ kubectl get pod cpu-demo --output=yaml --namespace=cpu-example
The output shows that the one container in the Pod has a CPU request of 500 milliCPU
and a CPU limit of 1 CPU.
-->
-
输出显示 Pod 中的一个容器的 CPU 请求为 500 milli CPU，并且 CPU 限制为 1 个 CPU。
```yaml
@@ -168,7 +157,7 @@ resources:
<!--
Use `kubectl top` to fetch the metrics for the pod:
-->
-使用 `kubectl top` 命令来获取该 Pod 的指标数据：
+使用 `kubectl top` 命令来获取该 Pod 的度量值数据：
```shell
kubectl top pod cpu-demo --namespace=cpu-example
@@ -178,29 +167,31 @@ kubectl top pod cpu-demo --namespace=cpu-example
This example output shows that the Pod is using 974 milliCPU, which is
just a bit less than the limit of 1 CPU specified in the Pod configuration.
-->
-此示例的输出，显示 Pod 使用的是974 milliCPU，即仅略低于 Pod 配置中指定的 1 个 CPU 的限制。
+此示例输出显示 Pod 使用的是 974 milliCPU，即仅略低于 Pod 配置中指定的 1 个 CPU 的限制。
+
```
NAME CPU(cores) MEMORY(bytes)
cpu-demo 974m <something>
```
+
<!--
Recall that by setting `-cpu "2"`, you configured the Container to attempt to use 2 CPUs, but the Container is only being allowed to use about 1 CPU. The container's CPU use is being throttled, because the container is attempting to use more CPU resources than its limit.
-->
-回想一下，通过设置 `- CPU "2"`，您将容器配置为尝试使用 2 个 CPU，但是只允许容器使用大约 1 个 CPU。容器的 CPU 使用量受到限制，因为该容器正尝试使用超出其限制的 CPU 资源。
-
+回想一下，通过设置 `-cpu "2"`，你将容器配置为尝试使用 2 个 CPU，
+但是容器只被允许使用大约 1 个 CPU。
+容器的 CPU 用量受到限制，因为该容器正尝试使用超出其限制的 CPU 资源。
<!--
-{{< note >}}
Another possible explanation for the CPU use being below 1.0 is that the Node might not have
enough CPU resources available. Recall that the prerequisites for this exercise require each of
your Nodes to have at least 1 CPU. If your Container runs on a Node that has only 1 CPU, the Container
cannot use more than 1 CPU regardless of the CPU limit specified for the Container.
-{{< /note >}}
-->
-
{{< note >}}
-CPU 使用率低于1.0的另一种可能的解释是，节点可能没有足够的 CPU 资源可用。回想一下，此练习的先决条件需要
-您的节点至少具有 1 个 CPU。如果您的容器在只有 1 个 CPU 的节点上运行，则容器无论为容器指定的 CPU 限制如何，都不能使用超过 1 个 CPU。
+CPU 使用率低于 1.0 的另一种可能的解释是，节点可能没有足够的 CPU 资源可用。
+回想一下，此练习的先决条件需要你的节点至少具有 1 个 CPU 可用。
+如果你的容器在只有 1 个 CPU 的节点上运行，则容器无论为容器指定的 CPU 限制如何，
+都不能使用超过 1 个 CPU。
{{< /note >}}
<!--
@@ -213,14 +204,14 @@ The CPU resource is measured in *CPU* units. One CPU, in Kubernetes, is equivale
* 1 Azure vCore
* 1 Hyperthread on a bare-metal Intel processor with Hyperthreading
-->
+## CPU 单位 {#cpu-units}
-## CPU 单元
- CPU 资源以 *CPU* 单位度量。Kubernetes中的一个 CPU 等同于：
+CPU 资源以 *CPU* 单位度量。Kubernetes 中的一个 CPU 等同于：
* 1 个 AWS vCPU
* 1 个 GCP核心
* 1 个 Azure vCore
-* 1 个具有超线程功能的裸机英特尔处理器上的超线程
+* 裸机上具有超线程能力的英特尔处理器上的 1 个超线程
<!--
Fractional values are allowed. A Container that requests 0.5 CPU is guaranteed half as much
@@ -232,13 +223,13 @@ amount of CPU on a single-core, dual-core, or 48-core machine.
Delete your Pod:
-->
-
-允许使用小数值。要求 0.5 CPU 的容器保证一半 CPU 作为请求 1 个 CPU 的容器。
-您可以使用后缀 m 表示毫。例如 100m CPU，100 milliCPU 和 0.1 CPU 都相同。
+小数值是可以使用的。一个请求 0.5 CPU 的容器保证会获得请求 1 个 CPU 的容器的 CPU 的一半。
+你可以使用后缀 `m` 表示毫。例如 `100m` CPU、100 milliCPU 和 0.1 CPU 都相同。
精度不能超过 1m。
-始终要求 CPU 是绝对数量，而不是相对数量。0.1 在单核，双核或 48 核计算机上的 CPU 数量值是一样的。
+CPU 请求只能使用绝对数量，而不是相对数量。0.1 在单核、双核或 48 核计算机上的 CPU 数量值是一样的。
+删除 Pod：
```shell
kubectl delete pod cpu-demo --namespace=cpu-example
@@ -264,23 +255,21 @@ capacity of any Node in your cluster.
Create the Pod:
-->
+## 设置超过节点能力的 CPU 请求
+CPU 请求和限制与都与容器相关，但是我们可以考虑一下 Pod 具有对应的 CPU 请求和限制这样的场景。
+Pod 对 CPU 用量的请求等于 Pod 中所有容器的请求数量之和。
+同样，Pod 的 CPU 资源限制等于 Pod 中所有容器 CPU 资源限制数之和。
-## 对您的节点而言，设置一个 CPU 过大的请求
+Pod 调度是基于资源请求值来进行的。
+仅在某节点具有足够的 CPU 资源来满足 Pod CPU 请求时，Pod 将会在对应节点上运行：
-CPU 请求和限制与容器相关联，但是我们可以考虑一下 CPU 对应 Pod 的请求和限制这样的场景：Pod 对 CPU 使用量的请求等于 Pod 中所有容器的请求数量。
-同样，CPU 对 Pod 请求资源的限制等于 Pod 中所有容器的请求的 CPU 资源限制数。
-
-Pod 调度基于请求。仅在以下情况下，Pod 将会在节点上运行：节点具有足够的 CPU 资源可用于满足 Pod CPU 请求。
-
-在本练习中，您将创建一个 Pod，该 Pod 的 CPU 请求对于集群中任何节点的容量而言都会过大。
-
-这是 Pod 的配置文件，Pod 中有一个容器。容器请求 100 个 CPU，这可能会超出集群中任何节点的容量。
+在本练习中，你将创建一个 Pod，该 Pod 的 CPU 请求对于集群中任何节点的容量而言都会过大。
+下面是 Pod 的配置文件，其中有一个容器。容器请求 100 个 CPU，这可能会超出集群中任何节点的容量。
{{< codenew file="pods/resource/cpu-request-limit-2.yaml" >}}
-使用如下命令创建该 Pod
-
+创建 Pod：
```shell
kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit-2.yaml --namespace=cpu-example
@@ -288,7 +277,7 @@ kubectl apply -f https://k8s.io/examples/pods/resource/cpu-request-limit-2.yaml
<!--
View the Pod status:
-->
-查看该 Pod 的状态
+查看该 Pod 的状态：
```shell
kubectl get pod cpu-demo-2 --namespace=cpu-example
@@ -298,9 +287,8 @@ kubectl get pod cpu-demo-2 --namespace=cpu-example
The output shows that the Pod status is Pending. That is, the Pod has not been
scheduled to run on any Node, and it will remain in the Pending state indefinitely:
-->
-
-输出显示 Pod 状态为Pending。也就是说，尚未将 Pod 调度到任何节点上运行，
-并且 Pod 将无限期地处于Pending状态：
+输出显示 Pod 状态为 Pending。也就是说，Pod 未被调度到任何节点上运行，
+并且 Pod 将无限期地处于 Pending 状态：
```shell
kubectl get pod cpu-demo-2 --namespace=cpu-example
@@ -310,12 +298,12 @@ NAME READY STATUS RESTARTS AGE
cpu-demo-2 0/1 Pending 0 7m
```
-
<!--
View detailed information about the Pod, including events:
-->
-查看有关 Pod 的详细信息，包括事件如下：
+查看有关 Pod 的详细信息，包含事件：
+
```shell
kubectl describe pod cpu-demo-2 --namespace=cpu-example
```
@@ -324,8 +312,7 @@ kubectl describe pod cpu-demo-2 --namespace=cpu-example
The output shows that the Container cannot be scheduled because of insufficient
CPU resources on the Nodes:
-->
-
-输出显示由于节点上的 CPU 资源不足，无法调度容器
+输出显示由于节点上的 CPU 资源不足，无法调度容器：
```
Events:
@@ -337,8 +324,7 @@ Events:
<!--
Delete your Pod:
-->
-
-删除您的 Pod
+删除你的 Pod：
```shell
kubectl delete pod cpu-demo-2 --namespace=cpu-example
@@ -357,16 +343,16 @@ Container is automatically assigned the default limit. Cluster administrators ca
[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core/)
to specify a default value for the CPU limit.
-->
-## 如果没有指定 CPU 限制
+## 如果不指定 CPU 限制
-如果您没有为容器指定 CPU 限制，则适用以下情况之一：
+如果你没有为容器指定 CPU 限制，则会发生以下情况之一：
-* 容器在可以使用的 CPU 资源上没有上限。容器可以使用运行该节点的所有可用 CPU 资源。
-
-* 容器在具有默认 CPU 限制的命名空间中运行，并且系统会自动为容器分配默认限制。集群管理员可以使用
-[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core/)
-指定 CPU 限制的默认值。
+* 容器在可以使用的 CPU 资源上没有上限。因而可以使用所在节点上所有的可用 CPU 资源。
+* 容器在具有默认 CPU 限制的名字空间中运行，系统会自动为容器设置默认限制。
+ 集群管理员可以使用
+ [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core/)
+ 指定 CPU 限制的默认值。
<!--
## Motivation for CPU requests and limits
@@ -379,25 +365,20 @@ scheduled. By having a CPU limit that is greater than the CPU request, you accom
* The Pod can have bursts of activity where it makes use of CPU resources that happen to be available.
* The amount of CPU resources a Pod can use during a burst is limited to some reasonable amount.
-->
-
## CPU 请求和限制的初衷
-通过配置 CPU 请求和在您的容器中运行的容器的限制
-集群，您可以有效利用集群上可用的 CPU 资源
-节点。通过将 Pod CPU 请求保持在较低水平，可以使 Pod 成为
-预定的。通过使 CPU 限制大于 CPU 请求，您可以完成两件事：
-
-* Pod 可能会有大量活动，它利用恰好可用的 CPU 资源。
-* Pod 在突发期间可以使用的 CPU 资源数量被限制为合理的数量。
-
+通过配置你的集群中运行的容器的 CPU 请求和限制，你可以有效利用集群上可用的 CPU 资源。
+通过将 Pod CPU 请求保持在较低水平，可以使 Pod 更有机会被调度。
+通过使 CPU 限制大于 CPU 请求，你可以完成两件事：
+* Pod 可能会有突发性的活动，它可以利用碰巧可用的 CPU 资源。
+* Pod 在突发负载期间可以使用的 CPU 资源数量仍被限制为合理的数量。
<!--
## Clean up
Delete your namespace:
-->
-
## 清理
删除名称空间：
@@ -406,8 +387,6 @@ Delete your namespace:
kubectl delete namespace cpu-example
```
-
-
## {{% heading "whatsnext" %}}
@@ -420,43 +399,29 @@ kubectl delete namespace cpu-example
-->
### 针对应用开发者
-* [将内存资源分配给容器和 Pod](/docs/tasks/configure-pod-container/assign-memory-resource/)
-* [配置 Pod 服务质量](/docs/tasks/configure-pod-container/quality-service-pod/)
+* [将内存资源分配给容器和 Pod](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)
+* [配置 Pod 服务质量](/zh/docs/tasks/configure-pod-container/quality-service-pod/)
<!--
### For cluster administrators
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)
-
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/cpu-default-namespace/)
-
* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)
-
* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
-
* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
-
* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/)
-
* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
-->
### 针对集群管理员
-* [配置名称空间的默认内存请求和限制](/docs/tasks/administer-cluster/memory-default-namespace/)
-
-* [为命名空间配置默认的 CPU 请求和限制](/docs/tasks/administer-cluster/cpu-default-namespace/)
-
-* [为命名空间配置最小和最大内存限制](/docs/tasks/administer-cluster/memory-constraint-namespace/)
-
-* [为命名空间配置最小和最大 CPU 约束](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
-
-* [为命名空间配置内存和 CPU 配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
-
-* [为命名空间配置 Pod 配额](/docs/tasks/administer-cluster/quota-pod-namespace/)
-
-* [配置 API 对象的配额](/docs/tasks/administer-cluster/quota-api-object/)
-
-
+* [配置名称空间的默认内存请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
+* [为名字空间配置默认 CPU 请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
+* [为名字空间配置最小和最大内存限制](/zh/docs/tasks/administer-cluster//manage-resources/memory-constraint-namespace/)
+* [为名字空间配置最小和最大 CPU 约束](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
+* [为名字空间配置内存和 CPU 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
+* [为名字空间配置 Pod 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
+* [配置 API 对象的配额](/zh/docs/tasks/administer-cluster/quota-api-object/)
diff --git a/content/zh/docs/tasks/configure-pod-container/assign-pods-nodes.md b/content/zh/docs/tasks/configure-pod-container/assign-pods-nodes.md
index be2f8d030b..5ad4f62c28 100644
--- a/content/zh/docs/tasks/configure-pod-container/assign-pods-nodes.md
+++ b/content/zh/docs/tasks/configure-pod-container/assign-pods-nodes.md
@@ -4,11 +4,9 @@ content_type: task
weight: 120
---
<!--
----
title: Assign Pods to Nodes
content_type: task
weight: 120
----
-->
<!-- overview -->
@@ -21,82 +19,84 @@ Kubernetes cluster.
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
<!-- steps -->
<!--
## Add a label to a node
+
+1. List the nodes in your cluster:
-->
## 给节点添加标签
-<!--
-1. List the nodes in your cluster:
--->
1. 列出集群中的节点
- kubectl get nodes
+ ```shell
+ kubectl get nodes
+ ```
- <!--
- The output is similar to this:
- -->
- 输出类似如下：
+ <!-- The output is similar to this: -->
+ 输出类似如下：
- NAME STATUS AGE VERSION
- worker0 Ready 1d v1.6.0+fff5156
- worker1 Ready 1d v1.6.0+fff5156
- worker2 Ready 1d v1.6.0+fff5156
+ ```
+ NAME STATUS AGE VERSION
+ worker0 Ready 1d v1.6.0+fff5156
+ worker1 Ready 1d v1.6.0+fff5156
+ worker2 Ready 1d v1.6.0+fff5156
+ ```
<!--
1. Chose one of your nodes, and add a label to it:
-->
-1. 选择其中一个节点，为它添加标签：
+2. 选择其中一个节点，为它添加标签：
- kubectl label nodes <your-node-name> disktype=ssd
+ ```shell
+ kubectl label nodes <your-node-name> disktype=ssd
+ ```
- <!--
- where `<your-node-name>` is the name of your chosen node.
- -->
- `<your-node-name>` 是你选择的节点的名称。
+ <!--
+ where `<your-node-name>` is the name of your chosen node.
+ -->
+ `<your-node-name>` 是你选择的节点的名称。
<!--
1. Verify that your chosen node has a `disktype=ssd` label:
-->
-1. 验证你选择的节点是否有 `disktype=ssd` 标签：
+3. 验证你选择的节点是否有 `disktype=ssd` 标签：
- kubectl get nodes --show-labels
+ ```shell
+ kubectl get nodes --show-labels
+ ```
+ <!--
+ The output is similar to this:
+ -->
+ 输出类似如下：
- <!--
- The output is similar to this:
- -->
- 输出类似如下：
-
- NAME STATUS AGE VERSION LABELS
- worker0 Ready 1d v1.6.0+fff5156 ...,disktype=ssd,kubernetes.io/hostname=worker0
- worker1 Ready 1d v1.6.0+fff5156 ...,kubernetes.io/hostname=worker1
- worker2 Ready 1d v1.6.0+fff5156 ...,kubernetes.io/hostname=worker2
-
- <!--
- In the preceding output, you can see that the `worker0` node has a
- `disktype=ssd` label.
- -->
- 在前面的输出中，你可以看到 `worker0` 节点有 `disktype=ssd` 标签。
+ ```
+ NAME STATUS AGE VERSION LABELS
+ worker0 Ready 1d v1.6.0+fff5156 ...,disktype=ssd,kubernetes.io/hostname=worker0
+ worker1 Ready 1d v1.6.0+fff5156 ...,kubernetes.io/hostname=worker1
+ worker2 Ready 1d v1.6.0+fff5156 ...,kubernetes.io/hostname=worker2
+ ```
+ <!--
+ In the preceding output, you can see that the `worker0` node has a
+ `disktype=ssd` label.
+ -->
+ 在前面的输出中，你可以看到 `worker0` 节点有 `disktype=ssd` 标签。
<!--
## Create a pod that gets scheduled to your chosen node
--->
-## 创建一个调度到你选择的节点的 pod
-<!--
This pod configuration file describes a pod that has a node selector,
`disktype: ssd`. This means that the pod will get scheduled on a node that has
a `disktype=ssd` label.
-->
-该 pod 配置文件描述了一个拥有节点选择器 `disktype: ssd` 的 pod。这表明该 pod 将被调度到
+## 创建一个调度到你选择的节点的 pod
+
+此 Pod 配置文件描述了一个拥有节点选择器 `disktype: ssd` 的 Pod。这表明该 Pod 将被调度到
有 `disktype=ssd` 标签的节点。
{{< codenew file="pods/pod-nginx.yaml" >}}
@@ -107,24 +107,26 @@ a `disktype=ssd` label.
-->
1. 使用该配置文件去创建一个 pod，该 pod 将被调度到你选择的节点上：
- kubectl create -f https://k8s.io/examples/pods/pod-nginx.yaml
+ ```shell
+ kubectl create -f https://k8s.io/examples/pods/pod-nginx.yaml
+ ```
<!--
1. Verify that the pod is running on your chosen node:
-->
-1. 验证 pod 是不是运行在你选择的节点上：
+2. 验证 pod 是不是运行在你选择的节点上：
- kubectl get pods --output=wide
-
- <!--
- The output is similar to this:
- -->
- 输出类似如下：
-
- NAME READY STATUS RESTARTS AGE IP NODE
- nginx 1/1 Running 0 13s 10.200.0.4 worker0
+ ```shell
+ kubectl get pods --output=wide
+ ```
+ <!-- The output is similar to this: -->
+ 输出类似如下：
+ ```
+ NAME READY STATUS RESTARTS AGE IP NODE
+ nginx 1/1 Running 0 13s 10.200.0.4 worker0
+ ```
## {{% heading "whatsnext" %}}
@@ -132,6 +134,5 @@ a `disktype=ssd` label.
Learn more about
[labels and selectors](/docs/concepts/overview/working-with-objects/labels/).
-->
-了解更多关于
-[标签和选择器](/docs/concepts/overview/working-with-objects/labels/)。
+进一步了解[标签和选择器](/zh/docs/concepts/overview/working-with-objects/labels/)
diff --git a/content/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md b/content/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
index 8c0cc202d6..a4ead7966a 100644
--- a/content/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
+++ b/content/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md
@@ -4,11 +4,9 @@ content_type: task
weight: 140
---
<!--
----
title: Attach Handlers to Container Lifecycle Events
content_type: task
weight: 140
----
-->
<!-- overview -->
@@ -23,33 +21,26 @@ Container is terminated.
当一个容器启动后，Kubernetes 将立即发送 postStart 事件；在容器被终结之前，
Kubernetes 将发送一个 preStop 事件。
-
-
-
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
<!-- steps -->
<!--
## Define postStart and preStop handlers
--->
-## 定义 postStart 和 preStop 处理函数
-<!--
In this exercise, you create a Pod that has one Container. The Container has handlers
for the postStart and preStop events.
-->
+## 定义 postStart 和 preStop 处理函数
+
在本练习中，你将创建一个包含一个容器的 Pod，该容器为 postStart 和 preStop 事件提供对应的处理函数。
<!--
Here is the configuration file for the Pod:
-->
-下面是对应 Pod 的配置文件
+下面是对应 Pod 的配置文件：
{{< codenew file="pods/lifecycle-events.yaml" >}}
@@ -59,55 +50,58 @@ file to the Container's `/usr/share` directory. The preStop command shuts down
nginx gracefully. This is helpful if the Container is being terminated because of a failure.
-->
在上述配置文件中，你可以看到 postStart 命令在容器的 `/usr/share` 目录下写入文件 `message`。
-命令 preStop 负责优雅地终止 nginx 服务。当因为失效而导致容器终止时，这一处理方式很有用。```
+命令 preStop 负责优雅地终止 nginx 服务。当因为失效而导致容器终止时，这一处理方式很有用。
<!--
Create the Pod:
-->
创建 Pod：
- kubectl apply -f https://k8s.io/examples/pods/lifecycle-events.yaml
+```shell
+kubectl apply -f https://k8s.io/examples/pods/lifecycle-events.yaml
+```
<!--
Verify that the Container in the Pod is running:
-->
验证 Pod 中的容器已经运行：
- kubectl get pod lifecycle-demo
+```shell
+kubectl get pod lifecycle-demo
+```
<!--
Get a shell into the Container running in your Pod:
-->
使用 shell 连接到你的 Pod 里的容器：
- kubectl exec -it lifecycle-demo -- /bin/bash
+```
+kubectl exec -it lifecycle-demo -- /bin/bash
+```
<!--
In your shell, verify that the `postStart` handler created the `message` file:
-->
在 shell 中，验证 `postStart` 处理函数创建了 `message` 文件：
- root@lifecycle-demo:/# cat /usr/share/message
+```
+root@lifecycle-demo:/# cat /usr/share/message
+```
<!--
The output shows the text written by the postStart handler:
-->
命令行输出的是 `postStart` 处理函数所写入的文本
- Hello from the postStart handler
-
-
-
-
+```
+Hello from the postStart handler
+```
<!-- discussion -->
<!--
## Discussion
--->
-## 讨论
-<!--
Kubernetes sends the postStart event immediately after the Container is created.
There is no guarantee, however, that the postStart handler is called before
the Container's entrypoint is called. The postStart handler runs asynchronously
@@ -115,9 +109,13 @@ relative to the Container's code, but Kubernetes' management of the container
blocks until the postStart handler completes. The Container's status is not
set to RUNNING until the postStart handler completes.
-->
-Kubernetes 在容器创建后立即发送 postStart 事件。然而，postStart 处理函数的调用不保证早于容器的入口点（entrypoint）
+## 讨论
+
+Kubernetes 在容器创建后立即发送 postStart 事件。
+然而，postStart 处理函数的调用不保证早于容器的入口点（entrypoint）
的执行。postStart 处理函数与容器的代码是异步执行的，但 Kubernetes
-的容器管理逻辑会一直阻塞等待 postStart 处理函数执行完毕。只有 postStart 处理函数执行完毕，容器的状态才会变成
+的容器管理逻辑会一直阻塞等待 postStart 处理函数执行完毕。
+只有 postStart 处理函数执行完毕，容器的状态才会变成
RUNNING。
<!--
@@ -128,34 +126,28 @@ unless the Pod's grace period expires. For more details, see
-->
Kubernetes 在容器结束前立即发送 preStop 事件。除非 Pod 宽限期限超时，Kubernetes 的容器管理逻辑
会一直阻塞等待 preStop 处理函数执行完毕。更多的相关细节，可以参阅
-[Pods 的结束](/docs/user-guide/pods/#termination-of-pods)。
+[Pods 的结束](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。
<!--
-{{< note >}}
Kubernetes only sends the preStop event when a Pod is *terminated*.
This means that the preStop hook is not invoked when the Pod is *completed*.
This limitation is tracked in [issue #55087](https://github.com/kubernetes/kubernetes/issues/55807).
-{{< /note >}}
-->
{{< note >}}
-Kubernetes 只有在 Pod *结束（Terminated）* 的时候才会发送 preStop 事件，这意味着在 Pod *完成（Completed）* 时
+Kubernetes 只有在 Pod *结束（Terminated）* 的时候才会发送 preStop 事件，
+这意味着在 Pod *完成（Completed）* 时
preStop 的事件处理逻辑不会被触发。这个限制在
[issue #55087](https://github.com/kubernetes/kubernetes/issues/55807) 中被追踪。
{{< /note >}}
-
-
-
## {{% heading "whatsnext" %}}
-
<!--
* Learn more about [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/).
* Learn more about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/).
-->
-* 进一步了解[容器生命周期回调](/docs/concepts/containers/container-lifecycle-hooks/)。
-* 进一步了解[Pod 的生命周期](/docs/concepts/workloads/pods/pod-lifecycle/)。
-
+* 进一步了解[容器生命周期回调](/zh/docs/concepts/containers/container-lifecycle-hooks/)。
+* 进一步了解[Pod 的生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/)。
<!--
### Reference
@@ -170,6 +162,3 @@ preStop 的事件处理逻辑不会被触发。这个限制在
* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
* 参阅 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) 中关于`terminationGracePeriodSeconds` 的部分
-
-
-
diff --git a/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
index 737e668f55..f8ceb4f6d9 100644
--- a/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
+++ b/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
@@ -16,7 +16,10 @@ despite bugs.
-->
这篇文章介绍如何给容器配置存活、就绪和启动探测器。
-[kubelet](/zh/docs/admin/kubelet/) 使用存活探测器来知道什么时候要重启容器。例如，存活探测器可以捕捉到死锁（应用程序在运行，但是无法继续执行后面的步骤）。这样的情况下重启容器有助于让应用程序在有问题的情况下更可用。
+[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/)
+使用存活探测器来知道什么时候要重启容器。
+例如，存活探测器可以捕捉到死锁（应用程序在运行，但是无法继续执行后面的步骤）。
+这样的情况下重启容器有助于让应用程序在有问题的情况下更可用。
<!--
The kubelet uses readiness probes to know when a Container is ready to start
@@ -30,19 +33,20 @@ it succeeds, making sure those probes don't interfere with the application start
This can be used to adopt liveness checks on slow starting containers, avoiding them
getting killed by the kubelet before they are up and running.
-->
-kubelet 使用就绪探测器可以知道容器什么时候准备好了并可以开始接受请求流量， 当一个 Pod 内的所有容器都准备好了，才能把这个 Pod 看作就绪了。这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。在 Pod 还没有准备好的时候，会从 Service 的负载均衡器中被剔除的。
-
-kubelet 使用启动探测器可以知道应用程序容器什么时候启动了。如果配置了这类探测器，就可以控制容器在启动成功后再进行存活性和就绪检查，确保这些存活、就绪探测器不会影响应用程序的启动。这可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉。
-
+kubelet 使用就绪探测器可以知道容器什么时候准备好了并可以开始接受请求流量， 当一个 Pod
+内的所有容器都准备好了，才能把这个 Pod 看作就绪了。
+这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。
+在 Pod 还没有准备好的时候，会从 Service 的负载均衡器中被剔除的。
+kubelet 使用启动探测器可以知道应用程序容器什么时候启动了。
+如果配置了这类探测器，就可以控制容器在启动成功后再进行存活性和就绪检查，
+确保这些存活、就绪探测器不会影响应用程序的启动。
+这可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
<!-- steps -->
<!--
@@ -57,9 +61,11 @@ In this exercise, you create a Pod that runs a Container based on the
-->
## 定义存活命令 {#define-a-liveness-command}
-许多长时间运行的应用程序最终会过渡到断开的状态，除非重新启动，否则无法恢复。Kubernetes 提供了存活探测器来发现并补救这种情况。
+许多长时间运行的应用程序最终会过渡到断开的状态，除非重新启动，否则无法恢复。
+Kubernetes 提供了存活探测器来发现并补救这种情况。
-在这篇练习中，会创建一个 Pod，其中运行一个基于 `k8s.gcr.io/busybox` 镜像的容器。下面是这个 Pod 的配置文件。
+在这篇练习中，你会创建一个 Pod，其中运行一个基于 `k8s.gcr.io/busybox` 镜像的容器。
+下面是这个 Pod 的配置文件。
{{< codenew file="pods/probe/exec-liveness.yaml" >}}
@@ -75,7 +81,12 @@ and restarts it.
When the Container starts, it executes this command:
-->
-在这个配置文件中，可以看到 Pod 中只有一个容器。`periodSeconds` 字段指定了 kubelet 应该每 5 秒执行一次存活探测。`initialDelaySeconds` 字段告诉 kubelet 在执行第一次探测前应该等待 5 秒。kubelet 在容器内执行命令 `cat /tmp/healthy` 来进行探测。如果命令执行成功并且返回值为 0，kubelet 就会认为这个容器是健康存活的。如果这个命令返回非 0 值，kubelet 会杀死这个容器并重新启动它。
+在这个配置文件中，可以看到 Pod 中只有一个容器。
+`periodSeconds` 字段指定了 kubelet 应该每 5 秒执行一次存活探测。
+`initialDelaySeconds` 字段告诉 kubelet 在执行第一次探测前应该等待 5 秒。
+kubelet 在容器内执行命令 `cat /tmp/healthy` 来进行探测。
+如果命令执行成功并且返回值为 0，kubelet 就会认为这个容器是健康存活的。
+如果这个命令返回非 0 值，kubelet 会杀死这个容器并重新启动它。
当容器启动时，执行如下的命令：
@@ -90,7 +101,9 @@ code. After 30 seconds, `cat /tmp/healthy` returns a failure code.
Create the Pod:
-->
-这个容器生命的前 30 秒， `/tmp/healthy` 文件是存在的。所以在这最开始的 30 秒内，执行命令 `cat /tmp/healthy` 会返回成功码。30 秒之后，执行命令 `cat /tmp/healthy` 就会返回失败码。
+这个容器生命的前 30 秒， `/tmp/healthy` 文件是存在的。
+所以在这最开始的 30 秒内，执行命令 `cat /tmp/healthy` 会返回成功代码。
+30 秒之后，执行命令 `cat /tmp/healthy` 就会返回失败代码。
创建 Pod：
@@ -110,9 +123,9 @@ kubectl describe pod liveness-exec
<!--
The output indicates that no liveness probes have failed yet:
-->
-输出结果显示还没有存活探测器失败：
+输出结果表明还没有存活探测器失败：
-```shell
+```
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
24s 24s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
@@ -137,7 +150,7 @@ probes have failed, and the containers have been killed and recreated.
-->
在输出结果的最下面，有信息显示存活探测器失败了，这个容器被杀死并且被重建了。
-```shell
+```
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
37s 37s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
@@ -162,7 +175,7 @@ The output shows that `RESTARTS` has been incremented:
-->
输出结果显示 `RESTARTS` 的值增加了 1。
-```shell
+```
NAME READY STATUS RESTARTS AGE
liveness-exec 1/1 Running 1 1m
```
@@ -176,7 +189,8 @@ image.
-->
## 定义一个存活态 HTTP 请求接口 {#define-a-liveness-HTTP-request}
-另外一种类型的存活探测方式是使用 HTTP GET 请求。下面是一个 Pod 的配置文件，其中运行一个基于 `k8s.gcr.io/liveness` 镜像的容器。
+另外一种类型的存活探测方式是使用 HTTP GET 请求。
+下面是一个 Pod 的配置文件，其中运行一个基于 `k8s.gcr.io/liveness` 镜像的容器。
{{< codenew file="pods/probe/http-liveness.yaml" >}}
@@ -191,7 +205,12 @@ returns a success code, the kubelet considers the Container to be alive and
healthy. If the handler returns a failure code, the kubelet kills the Container
and restarts it.
-->
-在这个配置文件中，可以看到 Pod 也只有一个容器。`periodSeconds` 字段指定了 kubelet 每隔 3 秒执行一次存活探测。`initialDelaySeconds` 字段告诉 kubelet 在执行第一次探测前应该等待 3 秒。kubelet 会向容器内运行的服务（服务会监听 8080 端口）发送一个 HTTP GET 请求来执行探测。如果服务上 `/healthz` 路径下的处理程序返回成功码，则 kubelet 认为容器是健康存活的。如果处理程序返回失败码，则 kubelet 会杀死这个容器并且重新启动它。
+在这个配置文件中，可以看到 Pod 也只有一个容器。
+`periodSeconds` 字段指定了 kubelet 每隔 3 秒执行一次存活探测。
+`initialDelaySeconds` 字段告诉 kubelet 在执行第一次探测前应该等待 3 秒。
+kubelet 会向容器内运行的服务（服务会监听 8080 端口）发送一个 HTTP GET 请求来执行探测。
+如果服务器上 `/healthz` 路径下的处理程序返回成功代码，则 kubelet 认为容器是健康存活的。
+如果处理程序返回失败代码，则 kubelet 会杀死这个容器并且重新启动它。
<!--
Any code greater than or equal to 200 and less than 400 indicates success. Any
@@ -203,7 +222,7 @@ You can see the source code for the server in
For the first 10 seconds that the Container is alive, the `/healthz` handler
returns a status of 200. After that, the handler returns a status of 500.
-->
-任何大于或等于 200 并且小于 400 的返回码标示成功，其它返回码都标示失败。
+任何大于或等于 200 并且小于 400 的返回代码标示成功，其它返回代码都标示失败。
可以在这里看服务的源码 [server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/liveness/server.go)。
@@ -229,7 +248,8 @@ checks will fail, and the kubelet will kill and restart the Container.
To try the HTTP liveness check, create a Pod:
-->
-kubelet 在容器启动之后 3 秒开始执行健康检测。所以前几次健康检查都是成功的。但是 10 秒之后，健康检查会失败，并且 kubelet 会杀死容器再重新启动容器。
+kubelet 在容器启动之后 3 秒开始执行健康检测。所以前几次健康检查都是成功的。
+但是 10 秒之后，健康检查会失败，并且 kubelet 会杀死容器再重新启动容器。
创建一个 Pod 来测试 HTTP 的存活检测：
@@ -254,7 +274,9 @@ the HTTP liveness probe uses that proxy.
In releases after v1.13, local HTTP proxy environment variable settings do not
affect the HTTP liveness probe.
-->
-在 1.13（包括 1.13版本）之前的版本中，如果在 Pod 运行的节点上设置了环境变量 `http_proxy`（或者 `HTTP_PROXY`），HTTP 的存活探测会使用这个代理。在 1.13 之后的版本中，设置本地的 HTTP 代理环境变量不会影响 HTTP 的存活探测。
+在 1.13（包括 1.13版本）之前的版本中，如果在 Pod 运行的节点上设置了环境变量
+`http_proxy`（或者 `HTTP_PROXY`），HTTP 的存活探测会使用这个代理。
+在 1.13 之后的版本中，设置本地的 HTTP 代理环境变量不会影响 HTTP 的存活探测。
<!--
## Define a TCP liveness probe
@@ -266,7 +288,9 @@ can’t it is considered a failure.
-->
## 定义 TCP 的存活探测 {#define-a-TCP-liveness-probe}
-第三种类型的存活探测是使用 TCP 套接字。通过配置，kubelet 会尝试在指定端口和容器建立套接字链接。如果能建立链接，这个容器就被看作是健康的，如果不能则这个容器就被看作是有问题的。
+第三种类型的存活探测是使用 TCP 套接字。
+通过配置，kubelet 会尝试在指定端口和容器建立套接字链接。
+如果能建立连接，这个容器就被看作是健康的，如果不能则这个容器就被看作是有问题的。
{{< codenew file="pods/probe/tcp-liveness-readiness.yaml" >}}
@@ -286,9 +310,15 @@ will be restarted.
To try the TCP liveness check, create a Pod:
-->
-如你所见，TCP 检测的配置和 HTTP 检测非常相似。下面这个例子同时使用就绪和存活探测器。kubelet 会在容器启动 5 秒后发送第一个就绪探测。这会尝试连接 `goproxy` 容器的 8080 端口。如果探测成功，这个 Pod 会被标记为就绪状态，kubelet 将继续每隔 10 秒运行一次检测。
+如你所见，TCP 检测的配置和 HTTP 检测非常相似。
+下面这个例子同时使用就绪和存活探测器。kubelet 会在容器启动 5 秒后发送第一个就绪探测。
+这会尝试连接 `goproxy` 容器的 8080 端口。
+如果探测成功，这个 Pod 会被标记为就绪状态，kubelet 将继续每隔 10 秒运行一次检测。
-除了就绪探测，这个配置包括了一个存活探测。kubelet 会在容器启动 15 秒后进行第一次存活探测。就像就绪探测一样，会尝试连接 `goproxy` 容器的 8080 端口。如果存活探测失败，这个容器会被重新启动。
+除了就绪探测，这个配置包括了一个存活探测。
+kubelet 会在容器启动 15 秒后进行第一次存活探测。
+就像就绪探测一样，会尝试连接 `goproxy` 容器的 8080 端口。
+如果存活探测失败，这个容器会被重新启动。
```shell
kubectl apply -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml
@@ -312,7 +342,8 @@ for HTTP or TCP liveness checks:
-->
## 使用命名端口 {#use-a-named-port}
-对于 HTTP 或者 TCP 存活检测可以使用命名的[容器端口](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerport-v1-core)。
+对于 HTTP 或者 TCP 存活检测可以使用命名的
+[ContainerPort](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerport-v1-core)。
```yaml
ports:
@@ -341,7 +372,10 @@ So, the previous example would become:
-->
## 使用启动探测器保护慢启动容器 {#define-startup-probes}
-有时候，会有一些现有的应用程序在启动时需要较多的初始化时间。要不影响对引起探测死锁的快速响应，这种情况下，设置存活探测参数是要技巧的。技巧就是使用一个命令来设置启动探测，针对HTTP 或者 TCP 检测，可以通过设置 `failureThreshold * periodSeconds` 参数来保证有足够长的时间应对糟糕情况下的启动时间。
+有时候，会有一些现有的应用程序在启动时需要较多的初始化时间。
+要不影响对引起探测死锁的快速响应，这种情况下，设置存活探测参数是要技巧的。
+技巧就是使用一个命令来设置启动探测，针对HTTP 或者 TCP 检测，可以通过设置
+`failureThreshold * periodSeconds` 参数来保证有足够长的时间应对糟糕情况下的启动时间。
所以，前面的例子就变成了：
@@ -392,12 +426,16 @@ Services.
-->
## 定义就绪探测器 {#define-readiness-probes}
-有时候，应用程序会暂时性的不能提供通信服务。例如，应用程序在启动时可能需要加载很大的数据或配置文件，或是启动后要依赖等待外部服务。在这种情况下，既不想杀死应用程序，也不想给它发送请求。Kubernetes 提供了就绪探测器来发现并缓解这些情况。容器所在 Pod 上报还未就绪的信息，并且不接受通过 Kubernetes Service 的流量。
+有时候，应用程序会暂时性的不能提供通信服务。
+例如，应用程序在启动时可能需要加载很大的数据或配置文件，或是启动后要依赖等待外部服务。
+在这种情况下，既不想杀死应用程序，也不想给它发送请求。
+Kubernetes 提供了就绪探测器来发现并缓解这些情况。
+容器所在 Pod 上报还未就绪的信息，并且不接受通过 Kubernetes Service 的流量。
-{{< note >}}
<!--
Readiness probes runs on the container during its whole lifecycle.
-->
+{{< note >}}
就绪探测器在容器的整个生命周期中保持运行状态。
{{< /note >}}
@@ -405,7 +443,8 @@ Readiness probes runs on the container during its whole lifecycle.
Readiness probes are configured similarly to liveness probes. The only difference
is that you use the `readinessProbe` field instead of the `livenessProbe` field.
-->
-就绪探测器的配置和存活探测器的配置相似。唯一区别就是要使用 `readinessProbe` 字段，而不是 `livenessProbe` 字段。
+就绪探测器的配置和存活探测器的配置相似。
+唯一区别就是要使用 `readinessProbe` 字段，而不是 `livenessProbe` 字段。
```yaml
readinessProbe:
@@ -426,17 +465,18 @@ for it, and that containers are restarted when they fail.
-->
HTTP 和 TCP 的就绪探测器配置也和存活探测器的配置一样的。
-就绪和存活探测可以在同一个容器上并行使用。两者都用可以确保流量不会发给还没有准备好的容器，并且容器会在它们失败的时候被重新启动。
+就绪和存活探测可以在同一个容器上并行使用。
+两者都用可以确保流量不会发给还没有准备好的容器，并且容器会在它们失败的时候被重新启动。
<!--
## Configure Probes
-->
## 配置探测器 {#configure-probes}
-{{< comment >}}
<!--
Eventually, some of this section could be moved to a concept topic.
-->
+{{< comment >}}
最后，本节的一些内容可以放到某个概念主题里。
{{< /comment >}}
@@ -445,7 +485,8 @@ Eventually, some of this section could be moved to a concept topic.
you can use to more precisely control the behavior of liveness and readiness
checks:
-->
-[探测器](/zh/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)有很多配置字段，可以使用这些字段精确的控制存活和就绪检测的行为：
+[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)
+有很多配置字段，可以使用这些字段精确的控制存活和就绪检测的行为：
<!--
* `initialDelaySeconds`: Number of seconds after the container has started
@@ -464,8 +505,11 @@ Defaults to 3. Minimum value is 1.
* `initialDelaySeconds`：容器启动后要等待多少秒后存活和就绪探测器才被初始化，默认是 0 秒，最小值是 0。
* `periodSeconds`：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。
* `timeoutSeconds`：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。
-* `successThreshold`：探测器在失败后，被视为成功的最小连续成功数。默认值是 1。存活探测的这个值必须是 1。最小值是 1。
-* `failureThreshold`：当探测失败时，Kubernetes 的重试次数。存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
+* `successThreshold`：探测器在失败后，被视为成功的最小连续成功数。默认值是 1。
+ 存活探测的这个值必须是 1。最小值是 1。
+* `failureThreshold`：当探测失败时，Kubernetes 的重试次数。
+ 存活探测情况下的放弃就意味着重新启动容器。
+ 就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
<!--
[HTTP probes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core)
@@ -479,7 +523,8 @@ set "Host" in httpHeaders instead.
* `port`: Name or number of the port to access on the container. Number must be
in the range 1 to 65535.
-->
-[HTTP 探测器](/zh/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core)可以在 `httpGet` 上配置额外的字段：
+[HTTP Probes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core)
+可以在 `httpGet` 上配置额外的字段：
* `host`：连接使用的主机名，默认是 Pod 的 IP。也可以在 HTTP 头中设置 “Host” 来代替。
* `scheme` ：用于设置连接主机的方式（HTTP 还是 HTTPS）。默认是 HTTP。
@@ -502,20 +547,25 @@ For a TCP probe, the kubelet makes the probe connection at the node, not in the
means that you can not use a service name in the `host` parameter since the kubelet is unable
to resolve it.
-->
-对于 HTTP 探测，kubelet 发送一个 HTTP 请求到指定的路径和端口来执行检测。除非 `httpGet` 中的 `host` 字段设置了，否则 kubelet 默认是给 Pod 的 IP 地址发送探测。如果 `scheme` 字段设置为了 `HTTPS`，kubelet 会跳过证书验证发送 HTTPS 请求。大多数情况下，不需要设置`host` 字段。这里有个需要设置 `host` 字段的场景，假设容器监听 127.0.0.1，并且 Pod 的 `hostNetwork` 字段设置为了 `true`。那么 `httpGet` 中的 `host` 字段应该设置为 127.0.0.1。可能更常见的情况是如果 Pod 依赖虚拟主机，你不应该设置 `host` 字段，而是应该在 `httpHeaders` 中设置 `Host`。
-
-对于一次 TCP 探测，kubelet 在节点上（不是在 Pod 里面）建立探测连接，这意味着你不能在 `host` 参数上配置 service name，因为 kubelet 不能解析 service name。
-
+对于 HTTP 探测，kubelet 发送一个 HTTP 请求到指定的路径和端口来执行检测。
+除非 `httpGet` 中的 `host` 字段设置了，否则 kubelet 默认是给 Pod 的 IP 地址发送探测。
+如果 `scheme` 字段设置为了 `HTTPS`，kubelet 会跳过证书验证发送 HTTPS 请求。
+大多数情况下，不需要设置`host` 字段。
+这里有个需要设置 `host` 字段的场景，假设容器监听 127.0.0.1，并且 Pod 的 `hostNetwork`
+字段设置为了 `true`。那么 `httpGet` 中的 `host` 字段应该设置为 127.0.0.1。
+可能更常见的情况是如果 Pod 依赖虚拟主机，你不应该设置 `host` 字段，而是应该在
+`httpHeaders` 中设置 `Host`。
+对于一次 TCP 探测，kubelet 在节点上（不是在 Pod 里面）建立探测连接，
+这意味着你不能在 `host` 参数上配置服务名称，因为 kubelet 不能解析服务名称。
## {{% heading "whatsnext" %}}
-
<!--
* Learn more about
[Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
-->
-* 进一步了解[容器探测器](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
+* 进一步了解[容器探测器](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
<!--
### Reference
@@ -525,8 +575,9 @@ to resolve it.
* [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)
-->
### 参考 {#reference}
+
* [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
-* [容器](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
-* [探测器](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)
+* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
+* [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)
diff --git a/content/zh/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/zh/docs/tasks/configure-pod-container/configure-pod-configmap.md
index 5ccf0ed36c..bdf8695bbc 100644
--- a/content/zh/docs/tasks/configure-pod-container/configure-pod-configmap.md
+++ b/content/zh/docs/tasks/configure-pod-container/configure-pod-configmap.md
@@ -1,5 +1,5 @@
---
-title: 使用 ConfigMap 配置 Pod
+title: 配置 Pod 使用 ConfigMap
content_type: task
weight: 150
card:
@@ -16,69 +16,92 @@ card:
-->
<!-- overview -->
-<!-- ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. This page provides a series of usage examples demonstrating how to create ConfigMaps and configure Pods using data stored in ConfigMaps. -->
-ConfigMap 允许您将配置文件与镜像文件分离，以使容器化的应用程序具有可移植性。该页面提供了一系列使用示例，这些示例演示了如何使用存储在 ConfigMap 中的数据创建 ConfigMap 和配置 Pod。
-
-
+<!--
+ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. This page provides a series of usage examples demonstrating how to create ConfigMaps and configure Pods using data stored in ConfigMaps.
+-->
+ConfigMap 允许你将配置文件与镜像文件分离，以使容器化的应用程序具有可移植性。
+本页提供了一系列使用示例，这些示例演示了如何创建 ConfigMap 以及配置 Pod
+使用存储在 ConfigMap 中的数据。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
<!-- steps -->
+<!--
+## Create a ConfigMap
-
-<!-- ## Create a ConfigMap
-You can use either `kubectl create configmap` or a ConfigMap generator in `kustomization.yaml` to create a ConfigMap. Note that `kubectl` starts to support `kustomization.yaml` since 1.14. -->
+You can use either `kubectl create configmap` or a ConfigMap generator in `kustomization.yaml` to create a ConfigMap. Note that `kubectl` starts to support `kustomization.yaml` since 1.14.
+-->
## 创建 ConfigMap
-您可以在 `kustomization.yaml` 中使用 `kubectl create configmap` 或 ConfigMap 生成器来创建ConfigMap。注意，从 1.14 版本开始， `kubectl` 开始支持 `kustomization.yaml`。
-<!-- ### Create a ConfigMap Using kubectl create configmap -->
-### 使用 kubectl 创建 ConfigMap
+你可以使用 `kubectl create configmap` 或者在 `kustomization.yaml` 中的 ConfigMap 生成器
+来创建 ConfigMap。注意，`kubectl` 从 1.14 版本开始支持 `kustomization.yaml`。
-<!-- Use the `kubectl create configmap` command to create configmaps from [directories](#create-configmaps-from-directories), [files](#create-configmaps-from-files), or [literal values](#create-configmaps-from-literal-values): -->
-在[目录](#create-configmaps-from-directories), [文件](#create-configmaps-from-files), 或者[文字值](#create-configmaps-from-literal-values)中使用 `kubectl create configmap` 命令创建configmap：
+<!--
+### Create a ConfigMap Using kubectl create configmap
+
+Use the `kubectl create configmap` command to create configmaps from [directories](#create-configmaps-from-directories), [files](#create-configmaps-from-files), or [literal values](#create-configmaps-from-literal-values):
+-->
+### 使用 kubectl create configmap 创建 ConfigMap
+
+你可以使用 `kubectl create configmap` 命令基于
+[目录](#create-configmaps-from-directories)、[文件](#create-configmaps-from-files)
+或者[字面值](#create-configmaps-from-literal-values)来创建 ConfigMap：
```shell
kubectl create configmap <map-name> <data-source>
```
-<!-- where \<map-name> is the name you want to assign to the ConfigMap and \<data-source> is the directory, file, or literal value to draw the data from. -->
-其中， \<map-name> 是要分配给 ConfigMap 的名称，\<data-source> 是要从中提取数据的目录，文件或者文字值。
+<!--
+where \<map-name> is the name you want to assign to the ConfigMap and \<data-source> is the directory, file, or literal value to draw the data from.
+The name of a ConfigMap object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+-->
+其中，\<map-name\> 是要设置的 ConfigMap 名称，\<data-source\> 是要从中提取数据的目录、
+文件或者字面值。
+ConfigMap 对象的名称必须是合法的
+[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
-<!-- The data source corresponds to a key-value pair in the ConfigMap, where -->
-数据源对应于 ConfigMap 中的 key-value (键值对)
+<!--
+When you are creating a ConfigMap based on a file, the key in the \<data-source> defaults to the basename of the file, and the value defaults to the file content.
+-->
+在你基于文件来创建 ConfigMap 时，\<data-source\> 中的键名默认取自
+文件的基本名，而对应的值则默认为文件的内容。
-<!-- * key = the file name or the key you provided on the command line, and
-* value = the file contents or the literal value you provided on the command line. -->
-* key = 您在命令行上提供的文件名或者密钥
-* value = 您在命令行上提供的文件内容或者文字值
-
-<!-- You can use [`kubectl describe`](/docs/reference/generated/kubectl/kubectl-commands/#describe) or
+<!--
+You can use [`kubectl describe`](/docs/reference/generated/kubectl/kubectl-commands/#describe) or
[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get) to retrieve information
-about a ConfigMap. -->
-您可以使用[`kubectl describe`](/docs/reference/generated/kubectl/kubectl-commands/#describe)或者
-[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get)检索有关 ConfigMap 的信息。
+about a ConfigMap.
+-->
+你可以使用[`kubectl describe`](/docs/reference/generated/kubectl/kubectl-commands/#describe) 或者
+[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get) 获取有关 ConfigMap 的信息。
-<!-- #### Create ConfigMaps from directories
+<!--
+#### Create ConfigMaps from directories
-You can use `kubectl create configmap` to create a ConfigMap from multiple files in the same directory. -->
-#### 根据目录创建 ConfigMap
+You can use `kubectl create configmap` to create a ConfigMap from multiple
+files in the same directory.
+When you are creating a ConfigMap based on a directory, kubectl identifies
+files whose basename is a valid key in the directory and packages each of
+those files into the new ConfigMap. Any directory entries except regular files
+are ignored (e.g. subdirectories, symlinks, devices, pipes, etc).
-<!-- You can use `kubectl create configmap` to create a ConfigMap from multiple files in the same directory.
-
-For example: -->
-你可以使用 `kubectl create configmap` 从同一目录中的多个文件创建 ConfigMap。
+For example:
+-->
+#### 基于目录创建 ConfigMap {#create-configmaps-from-directories}
+你可以使用 `kubectl create configmap` 基于同一目录中的多个文件创建 ConfigMap。
+当你基于目录来创建 ConfigMap 时，kubectl 识别目录下基本名可以作为合法键名的
+文件，并将这些文件打包到新的 ConfigMap 中。普通文件之外的所有目录项都会被
+忽略（例如，子目录、符号链接、设备、管道等等）。
例如：
+
```shell
# 创建本地目录
mkdir -p configure-pod-container/configmap/
-# 将样本文件下载到 `configure-pod-container/configmap/` 目录
+# 将实例文件下载到 `configure-pod-container/configmap/` 目录
wget https://kubernetes.io/examples/configmap/game.properties -O configure-pod-container/configmap/game.properties
wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-container/configmap/ui.properties
@@ -86,42 +109,63 @@ wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-con
kubectl create configmap game-config --from-file=configure-pod-container/configmap/
```
-<!-- combines the contents of the `configure-pod-container/configmap/` directory -->
-合并 `configure-pod-container/configmap/` 目录的内容
-
-```shell
-game.properties
-ui.properties
-```
-
-<!-- into the following ConfigMap: -->
-进入以下 ConfigMap 中：
+<!--
+The above command packages each file, in this case, `game.properties` and
+`ui.properties` in the `configure-pod-container/configmap/` directory into the
+game-config ConfigMap. You can display details of the ConfigMap using the
+following command:
+-->
+以上命令将 `configure-pod-container/configmap` 目录下的所有文件，也就是
+`game.properties` 和 `ui.properties` 打包到 game-config ConfigMap
+中。你可以使用下面的命令显示 ConfigMap 的详细信息：
```shell
kubectl describe configmaps game-config
```
-<!-- where the output is similar to this: -->
+<!--
+The output is similar to this:
+-->
输出类似以下内容：
+
```
-Name: game-config
-Namespace: default
-Labels: <none>
-Annotations: <none>
+Name: game-config
+Namespace: default
+Labels: <none>
+Annotations: <none>
Data
====
-game.properties: 158 bytes
-ui.properties: 83 bytes
+game.properties:
+----
+enemies=aliens
+lives=3
+enemies.cheat=true
+enemies.cheat.level=noGoodRotten
+secret.code.passphrase=UUDDLRLRBABAS
+secret.code.allowed=true
+secret.code.lives=30
+ui.properties:
+----
+color.good=purple
+color.bad=yellow
+allow.textmode=true
+how.nice.to.look=fairlyNice
```
-<!-- The `game.properties` and `ui.properties` files in the `configure-pod-container/configmap/` directory are represented in the `data` section of the ConfigMap. -->
-`configure-pod-container/configmap/` 目录中的 `game.properties` 和 `ui.properties` 文件在 ConfigMap 的 `data` 部分中表示。
+<!--
+The `game.properties` and `ui.properties` files in the `configure-pod-container/configmap/` directory are represented in the `data` section of the ConfigMap.
+-->
+`configure-pod-container/configmap/` 目录中的 `game.properties` 和 `ui.properties`
+文件出现在 ConfigMap 的 `data` 部分。
```shell
kubectl get configmaps game-config -o yaml
```
-<!-- The output is similar to this: -->
+
+<!--
+The output is similar to this:
+-->
输出类似以下内容:
```yaml
@@ -150,74 +194,111 @@ data:
how.nice.to.look=fairlyNice
```
-<!-- #### Create ConfigMaps from files -->
-#### 根据文件创建 ConfigMap
+<!--
+#### Create ConfigMaps from files
-<!-- You can use `kubectl create configmap` to create a ConfigMap from an individual file, or from multiple files.
+You can use `kubectl create configmap` to create a ConfigMap from an individual file, or from multiple files.
-For example, -->
-您可以使用 `kubectl create configmap` 从单个文件或多个文件创建 ConfigMap。
+For example,
+-->
+#### 基于文件创建 ConfigMap {#create-configmaps-from-files}
-例如
+你可以使用 `kubectl create configmap` 基于单个文件或多个文件创建 ConfigMap。
+
+例如：
```shell
kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties
```
-<!-- would produce the following ConfigMap: -->
+<!--
+would produce the following ConfigMap:
+-->
将产生以下 ConfigMap:
```shell
kubectl describe configmaps game-config-2
```
-<!-- where the output is similar to this: -->
+<!--
+where the output is similar to this:
+-->
输出类似以下内容:
```
-Name: game-config-2
-Namespace: default
-Labels: <none>
-Annotations: <none>
+Name: game-config-2
+Namespace: default
+Labels: <none>
+Annotations: <none>
Data
====
-game.properties: 158 bytes
+game.properties:
+----
+enemies=aliens
+lives=3
+enemies.cheat=true
+enemies.cheat.level=noGoodRotten
+secret.code.passphrase=UUDDLRLRBABAS
+secret.code.allowed=true
+secret.code.lives=30
```
-<!-- You can pass in the `--from-file` argument multiple times to create a ConfigMap from multiple data sources. -->
-您可以传入多个 `--from-file` 参数，从多个数据源创建 ConfigMap。
+<!--
+You can pass in the `--from-file` argument multiple times to create a ConfigMap from multiple data sources.
+-->
+你可以多次使用 `--from-file` 参数，从多个数据源创建 ConfigMap。
```shell
kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties --from-file=configure-pod-container/configmap/ui.properties
```
-<!-- Describe the above `game-config-2` configmap created -->
+<!--
+Describe the above `game-config-2` configmap created
+-->
描述上面创建的 `game-config-2` configmap
```shell
kubectl describe configmaps game-config-2
```
-<!-- The output is similar to this: -->
+<!--
+The output is similar to this:
+-->
输出类似以下内容:
```
-Name: game-config-2
-Namespace: default
-Labels: <none>
-Annotations: <none>
+Name: game-config-2
+Namespace: default
+Labels: <none>
+Annotations: <none>
Data
====
-game.properties: 158 bytes
-ui.properties: 83 bytes
+game.properties:
+----
+enemies=aliens
+lives=3
+enemies.cheat=true
+enemies.cheat.level=noGoodRotten
+secret.code.passphrase=UUDDLRLRBABAS
+secret.code.allowed=true
+secret.code.lives=30
+ui.properties:
+----
+color.good=purple
+color.bad=yellow
+allow.textmode=true
+how.nice.to.look=fairlyNice
```
-<!-- Use the option `--from-env-file` to create a ConfigMap from an env-file, for example: -->
+<!--
+Use the option `--from-env-file` to create a ConfigMap from an env-file, for example:
+-->
使用 `--from-env-file` 选项从环境文件创建 ConfigMap，例如：
-<!-- ```shell
+<!--
+```shell
# Env-files contain a list of environment variables.
# These syntax rules apply:
# Each line in an env file has to be in VAR=VAL format.
@@ -232,25 +313,33 @@ wget https://kubernetes.io/examples/configmap/game-env-file.properties -O config
cat configure-pod-container/configmap/game-env-file.properties
enemies=aliens
lives=3
-allowed="true" -->
+allowed="true"
+-->
+
+Env 文件包含环境变量列表。
+其中适用以下语法规则:
+
+- Env 文件中的每一行必须为 VAR=VAL 格式。
+- 以＃开头的行（即注释）将被忽略。
+- 空行将被忽略。
+- 引号不会被特殊处理（即它们将成为 ConfigMap 值的一部分）。
+
+将示例文件下载到 `configure-pod-container/configmap/` 目录
+
```shell
-# 环境文件包含环境变量列表。
-# 语法规则:
-# env 文件中的每一行必须为 VAR = VAL 格式。
-# 以＃开头的行(即注释)将被忽略。
-# 空行将被忽略。
-# 引号没有特殊处理(即它们将成为 ConfigMap 值的一部分)。
-
-# 将样本文件下载到 `configure-pod-container/configmap/` 目录
wget https://kubernetes.io/examples/configmap/game-env-file.properties -O configure-pod-container/configmap/game-env-file.properties
+```
-# env文件 `game-env-file.properties` 如下所示
+env 文件 `game-env-file.properties` 如下所示：
+
+```shell
cat configure-pod-container/configmap/game-env-file.properties
+```
+
+```
enemies=aliens
lives=3
allowed="true"
-
-# 注释及其上方的空行将被忽略
```
```shell
@@ -258,15 +347,20 @@ kubectl create configmap game-config-env-file \
--from-env-file=configure-pod-container/configmap/game-env-file.properties
```
-<!-- would produce the following ConfigMap: -->
-将产生以下 ConfigMap:
+<!--
+would produce the following ConfigMap:
+-->
+将产生以下 ConfigMap：
```shell
kubectl get configmap game-config-env-file -o yaml
```
-<!-- where the output is similar to this: -->
-输出类似以下内容:
+<!--
+where the output is similar to this:
+-->
+输出类似以下内容：
+
```yaml
apiVersion: v1
kind: ConfigMap
@@ -283,10 +377,20 @@ data:
lives: "3"
```
-<!-- When passing `--from-env-file` multiple times to create a ConfigMap from multiple data sources, only the last env-file is used: -->
-当使用多个 `--from-env-file` 来从多个数据源创建 ConfigMap 时，仅仅最后一个 env 文件有效:
+<!--
+When passing `--from-env-file` multiple times to create a ConfigMap from multiple data sources, only the last env-file is used:
+-->
+{{< caution >}}
+当多次使用 `--from-env-file` 来从多个数据源创建 ConfigMap 时，仅仅最后一个 env 文件有效。
+{{< /caution >}}
-<!-- ```shell
+<!--
+The behavior of passing `--from-env-file` multiple times is demonstrated by:
+-->
+下面是一个多次使用 `--from-env-file` 参数的示例：
+
+<!--
+```shell
# Download the sample files into `configure-pod-container/configmap/` directory
wget https://k8s.io/examples/configmap/ui-env-file.properties -O configure-pod-container/configmap/ui-env-file.properties
@@ -294,7 +398,8 @@ wget https://k8s.io/examples/configmap/ui-env-file.properties -O configure-pod-c
kubectl create configmap config-multi-env-files \
--from-env-file=configure-pod-container/configmap/game-env-file.properties \
--from-env-file=configure-pod-container/configmap/ui-env-file.properties
-``` -->
+```
+-->
```shell
# 将样本文件下载到 `configure-pod-container/configmap/` 目录
wget https://k8s.io/examples/configmap/ui-env-file.properties -O configure-pod-container/configmap/ui-env-file.properties
@@ -305,14 +410,18 @@ kubectl create configmap config-multi-env-files \
--from-env-file=configure-pod-container/configmap/ui-env-file.properties
```
-<!-- would produce the following ConfigMap: -->
+<!--
+would produce the following ConfigMap:
+-->
将产生以下 ConfigMap:
```shell
kubectl get configmap config-multi-env-files -o yaml
```
-<!-- where the output is similar to this: -->
+<!--
+where the output is similar to this:
+-->
输出类似以下内容:
```yaml
apiVersion: v1
@@ -330,18 +439,24 @@ data:
textmode: "true"
```
-<!-- #### Define the key to use when creating a ConfigMap from a file -->
+<!--
+#### Define the key to use when creating a ConfigMap from a file
+
+You can define a key other than the file name to use in the `data` section of your ConfigMap when using the `--from-file` argument:
+-->
#### 定义从文件创建 ConfigMap 时要使用的键
-<!-- You can define a key other than the file name to use in the `data` section of your ConfigMap when using the `--from-file` argument: -->
-您可以在使用 `--from-file` 参数时,在 ConfigMap 的 `data` 部分中定义除文件名以外的其他键:
+在使用 `--from-file` 参数时，你可以定义在 ConfigMap 的 `data` 部分出现键名，
+而不是按默认行为使用文件名：
```shell
kubectl create configmap game-config-3 --from-file=<my-key-name>=<path-to-file>
```
-<!-- where `<my-key-name>` is the key you want to use in the ConfigMap and `<path-to-file>` is the location of the data source file you want the key to represent. -->
-`<my-key-name>` 是您要在 ConfigMap 中使用的键名， `<path-to-file>` 是您想要键表示数据源文件的位置。
+<!--
+where <my-key-name> is the key you want to use in the ConfigMap and `<path-to-file>` is the location of the data source file you want the key to represent.
+-->
+`<my-key-name>` 是你要在 ConfigMap 中使用的键名，`<path-to-file>` 是你想要键表示数据源文件的位置。
<!-- For example: -->
例如:
@@ -350,14 +465,18 @@ kubectl create configmap game-config-3 --from-file=<my-key-name>=<path-to-file>
kubectl create configmap game-config-3 --from-file=game-special-key=configure-pod-container/configmap/game.properties
```
-<!-- would produce the following ConfigMap: -->
+<!--
+would produce the following ConfigMap:
+-->
将产生以下 ConfigMap:
+
```
kubectl get configmaps game-config-3 -o yaml
```
<!-- where the output is similar to this: -->
-输出类似以下内容:
+输出类似以下内容：
+
```yaml
apiVersion: v1
kind: ConfigMap
@@ -379,25 +498,32 @@ data:
secret.code.lives=30
```
-<!-- #### Create ConfigMaps from literal values -->
-#### 根据文字值创建 ConfigMap
+<!--
+#### Create ConfigMaps from literal values
-<!-- You can use `kubectl create configmap` with the `--from-literal` argument to define a literal value from the command line: -->
-您可以将 `kubectl create configmap` 与 `--from-literal` 参数一起使用，从命令行定义文字值:
+You can use `kubectl create configmap` with the `--from-literal` argument to define a literal value from the command line:
+-->
+#### 根据字面值创建 ConfigMap {#create-configmaps-from-literal-values}
+你可以将 `kubectl create configmap` 与 `--from-literal` 参数一起使用，从命令行定义文字值:
```shell
kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm
```
-<!-- You can pass in multiple key-value pairs. Each pair provided on the command line is represented as a separate entry in the `data` section of the ConfigMap. -->
-您可以传入多个键值对。命令行中提供的每对在 ConfigMap 的 `data` 部分中均表示为单独的条目。
+<!--
+You can pass in multiple key-value pairs. Each pair provided on the command line is represented as a separate entry in the `data` section of the ConfigMap.
+-->
+你可以传入多个键值对。命令行中提供的每对键值在 ConfigMap 的 `data` 部分中均表示为单独的条目。
```shell
kubectl get configmaps special-config -o yaml
```
-<!-- The output is similar to this: -->
+<!--
+The output is similar to this:
+-->
输出类似以下内容:
+
```yaml
apiVersion: v1
kind: ConfigMap
@@ -413,30 +539,32 @@ data:
special.type: charm
```
-<!-- ### Create a ConfigMap from generator -->
-#### 根据生成器创建 ConfigMap
-<!-- `kubectl` supports `kustomization.yaml` since 1.14.
+<!--
+### Create a ConfigMap from generator
+
+
+`kubectl` supports `kustomization.yaml` since 1.14.
You can also create a ConfigMap from generators and then apply it to create the object on
the Apiserver. The generators
-should be specified in a `kustomization.yaml` inside a directory. -->
-自 1.14 开始， `kubectl` 开始支持 `kustomization.yaml`。
-您还可以从生成器创建 ConfigMap，然后将其应用于 Apiserver 创建对象。生成器应在目录内的 `kustomization.yaml` 中指定。
+should be specified in a `kustomization.yaml` inside a directory.
+-->
+### 基于生成器创建 ConfigMap
+
+自 1.14 开始，`kubectl` 开始支持 `kustomization.yaml`。
+你还可以基于生成器创建 ConfigMap，然后将其应用于 API 服务器上创建对象。
+生成器应在目录内的 `kustomization.yaml` 中指定。
+
+<!--
+#### Generate ConfigMaps from files
+
+For example, to generate a ConfigMap from files `configure-pod-container/configmap/kubectl/game.properties`
+-->
+#### 基于文件生成 ConfigMap
+
+例如，要从 `configure-pod-container/configmap/kubectl/game.properties` 文件生成一个 ConfigMap：
-<!-- #### Generate ConfigMaps from files -->
-#### 根据文件生成 ConfigMap
-<!-- For example, to generate a ConfigMap from files `configure-pod-container/configmap/kubectl/game.properties`
```shell
-# Create a kustomization.yaml file with ConfigMapGenerator
-cat <<EOF >./kustomization.yaml
-configMapGenerator:
-- name: game-config-4
- files:
- - configure-pod-container/configmap/kubectl/game.properties
-EOF
-``` -->
-例如，要从 `configure-pod-container/configmap/kubectl/game.properties` 文件生成一个 ConfigMap
-```shell
-# 使用 ConfigMapGenerator 创建 kustomization.yaml 文件
+# 创建包含 ConfigMapGenerator 的 kustomization.yaml 文件
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: game-config-4
@@ -445,18 +573,28 @@ configMapGenerator:
EOF
```
-<!-- Apply the kustomization directory to create the ConfigMap object. -->
-使用 kustomization 目录创建 ConfigMap 对象
+<!--
+Apply the kustomization directory to create the ConfigMap object.
+-->
+使用 kustomization 目录创建 ConfigMap 对象：
+
```shell
kubectl apply -k .
+```
+```
configmap/game-config-4-m9dm2f92bt created
```
-<!-- You can check that the ConfigMap was created like this: -->
-您可以检查 ConfigMap 是这样创建的:
+<!--
+You can check that the ConfigMap was created like this:
+-->
+你可以检查 ConfigMap 是这样创建的:
```shell
kubectl get configmap
+```
+
+```
NAME DATA AGE
game-config-4-m9dm2f92bt 1 37s
@@ -482,28 +620,28 @@ secret.code.lives=30
Events: <none>
```
-<!-- Note that the generated ConfigMap name has a suffix appended by hashing the contents. This ensures that a
-new ConfigMap is generated each time the content is modified. -->
-请注意，生成的 ConfigMap 名称具有通过对内容进行散列而附加的后缀，这样可以确保每次修改内容时都会生成新的 ConfigMap。
+<!--
+Note that the generated ConfigMap name has a suffix appended by hashing the contents. This ensures that a
+new ConfigMap is generated each time the content is modified.
+-->
+请注意，生成的 ConfigMap 名称具有通过对内容进行散列而附加的后缀，
+这样可以确保每次修改内容时都会生成新的 ConfigMap。
-<!-- #### Define the key to use when generating a ConfigMap from a file -->
-#### 定义从文件生成 ConfigMap 时要使用的键
-<!-- You can define a key other than the file name to use in the ConfigMap generator.
+<!--
+#### Define the key to use when generating a ConfigMap from a file
+
+You can define a key other than the file name to use in the ConfigMap generator.
For example, to generate a ConfigMap from files `configure-pod-container/configmap/kubectl/game.properties`
-with the key `game-special-key` -->
-您可以定义一个非文件名的键，在 ConfigMap 生成器中使用。例如，使用 `game-special-key` 从 `configure-pod-container / configmap / kubectl / game.properties` 文件生成 ConfigMap。
+with the key `game-special-key`
+-->
+#### 定义从文件生成 ConfigMap 时要使用的键
+
+在 ConfigMap 生成器，你可以定义一个非文件名的键名。
+例如，从 `configure-pod-container/configmap/game.properties` 文件生成 ConfigMap，
+但使用 `game-special-key` 作为键名：
-<!-- ```shell
-# Create a kustomization.yaml file with ConfigMapGenerator
-cat <<EOF >./kustomization.yaml
-configMapGenerator:
-- name: game-config-5
- files:
- - game-special-key=configure-pod-container/configmap/kubectl/game.properties
-EOF
-``` -->
```shell
-# 使用 ConfigMapGenerator 创建 kustomization.yaml 文件
+# 创建包含 ConfigMapGenerator 的 kustomization.yaml 文件
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: game-config-5
@@ -512,20 +650,31 @@ configMapGenerator:
EOF
```
-<!-- Apply the kustomization directory to create the ConfigMap object. -->
+<!--
+Apply the kustomization directory to create the ConfigMap object.
+-->
使用 Kustomization 目录创建 ConfigMap 对象。
+
```shell
kubectl apply -k .
+```
+```
configmap/game-config-5-m67dt67794 created
```
-<!-- #### Generate ConfigMaps from Literals -->
-#### 从文字值生成 ConfigMap
-<!-- To generate a ConfigMap from literals `special.type=charm` and `special.how=very`,
-you can specify the ConfigMap generator in `kusotmization.yaml` as -->
-要从文字 `special.type=charm` 和 `special.how=very` 生成 ConfigMap，可以在 `kusotmization.yaml` 中将 ConfigMap 生成器指定。
+<!--
+#### Generate ConfigMaps from Literals
+
+To generate a ConfigMap from literals `special.type=charm` and `special.how=very`,
+you can specify the ConfigMap generator in `kusotmization.yaml` as
+-->
+#### 从字面值生成 ConfigMap
+
+要基于字符串 `special.type=charm` 和 `special.how=very` 生成 ConfigMap，
+可以在 `kusotmization.yaml` 中配置 ConfigMap 生成器：
+
```shell
-# 使用 ConfigMapGenerator 创建 kustomization.yaml 文件
+# 创建带有 ConfigMapGenerator 的 kustomization.yaml 文件
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: special-config-2
@@ -534,27 +683,40 @@ configMapGenerator:
- special.type=charm
EOF
```
-<!-- Apply the kustomization directory to create the ConfigMap object. -->
-使用 Kustomization 目录创建 ConfigMap 对象。
+
+<!--
+Apply the kustomization directory to create the ConfigMap object.
+-->
+应用 Kustomization 目录创建 ConfigMap 对象。
+
```shell
kubectl apply -k .
+```
+```
configmap/special-config-2-c92b5mmcf2 created
```
-<!-- ## Define container environment variables using ConfigMap data -->
+<!--
+## Define container environment variables using ConfigMap data
+
+### Define a container environment variable with data from a single ConfigMap
+-->
## 使用 ConfigMap 数据定义容器环境变量
-<!-- ### Define a container environment variable with data from a single ConfigMap -->
### 使用单个 ConfigMap 中的数据定义容器环境变量
-<!-- 1. Define an environment variable as a key-value pair in a ConfigMap: -->
-1. 在 ConfigMap 中将环境变量定义为键值对:
+<!--
+1. Define an environment variable as a key-value pair in a ConfigMap:
+-->
+1. 在 ConfigMap 中将环境变量定义为键值对:
- ```shell
- kubectl create configmap special-config --from-literal=special.how=very
- ```
+ ```shell
+ kubectl create configmap special-config --from-literal=special.how=very
+ ```
-<!-- 2. Assign the `special.how` value defined in the ConfigMap to the `SPECIAL_LEVEL_KEY` environment variable in the Pod specification. -->
+<!--
+2. Assign the `special.how` value defined in the ConfigMap to the `SPECIAL_LEVEL_KEY` environment variable in the Pod specification.
+-->
2. 将 ConfigMap 中定义的 `special.how` 值分配给 Pod 规范中的 `SPECIAL_LEVEL_KEY` 环境变量。
{{< codenew file="pods/pod-single-configmap-env-variable.yaml" >}}
@@ -562,29 +724,33 @@ configmap/special-config-2-c92b5mmcf2 created
<!-- Create the Pod: -->
创建 Pod:
- ```shell
- kubectl create -f https://kubernetes.io/examples/pods/pod-single-configmap-env-variable.yaml
- ```
+ ```shell
+ kubectl create -f https://kubernetes.io/examples/pods/pod-single-configmap-env-variable.yaml
+ ```
<!-- Now, the Pod's output includes environment variable `SPECIAL_LEVEL_KEY=very`. -->
现在，Pod 的输出包含环境变量 `SPECIAL_LEVEL_KEY=very`。
-<!-- ### Define container environment variables with data from multiple ConfigMaps -->
+<!--
+### Define container environment variables with data from multiple ConfigMaps
+-->
### 使用来自多个 ConfigMap 的数据定义容器环境变量
- <!-- * As with the previous example, create the ConfigMaps first. -->
- * 与前面的示例一样，首先创建 ConfigMap。
+<!-- * As with the previous example, create the ConfigMaps first. -->
+* 与前面的示例一样，首先创建 ConfigMap。
- {{< codenew file="configmap/configmaps.yaml" >}}
+ {{< codenew file="configmap/configmaps.yaml" >}}
- <!-- Create the ConfigMap: -->
- 创建 ConfigMap:
+ <!-- Create the ConfigMap: -->
+ 创建 ConfigMap:
- ```shell
- kubectl create -f https://kubernetes.io/examples/configmap/configmaps.yaml
- ```
+ ```shell
+ kubectl create -f https://kubernetes.io/examples/configmap/configmaps.yaml
+ ```
-<!-- * Define the environment variables in the Pod specification. -->
+<!--
+* Define the environment variables in the Pod specification.
+-->
* 在 Pod 规范中定义环境变量。
{{< codenew file="pods/pod-multiple-configmap-env-variable.yaml" >}}
@@ -592,22 +758,28 @@ configmap/special-config-2-c92b5mmcf2 created
<!-- Create the Pod: -->
创建 Pod:
- ```shell
- kubectl create -f https://kubernetes.io/examples/pods/pod-multiple-configmap-env-variable.yaml
- ```
+ ```shell
+ kubectl create -f https://kubernetes.io/examples/pods/pod-multiple-configmap-env-variable.yaml
+ ```
<!-- Now, the Pod's output includes environment variables `SPECIAL_LEVEL_KEY=very` and `LOG_LEVEL=INFO`. -->
现在，Pod 的输出包含环境变量 `SPECIAL_LEVEL_KEY=very` 和 `LOG_LEVEL=INFO`。
-<!-- ## Configure all key-value pairs in a ConfigMap as container environment variables -->
+<!--
+## Configure all key-value pairs in a ConfigMap as container environment variables
+-->
## 将 ConfigMap 中的所有键值对配置为容器环境变量
+<!--
+This functionality is available in Kubernetes v1.6 and later.
+-->
{{< note >}}
-<!-- This functionality is available in Kubernetes v1.6 and later. -->
-Kubernetes v1.6 和更高版本提供了此功能。
+Kubernetes v1.6 和更高版本支持此功能。
{{< /note >}}
-<!-- * Create a ConfigMap containing multiple key-value pairs. -->
+<!--
+* Create a ConfigMap containing multiple key-value pairs.
+-->
* 创建一个包含多个键值对的 ConfigMap。
{{< codenew file="configmap/configmap-multikeys.yaml" >}}
@@ -615,165 +787,245 @@ Kubernetes v1.6 和更高版本提供了此功能。
<!-- Create the ConfigMap: -->
创建 ConfigMap:
- ```shell
- kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml
- ```
+ ```shell
+ kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml
+ ```
-<!-- * Use `envFrom` to define all of the ConfigMap's data as container environment variables. The key from the ConfigMap becomes the environment variable name in the Pod. -->
+<!--
+* Use `envFrom` to define all of the ConfigMap's data as container environment variables. The key from the ConfigMap becomes the environment variable name in the Pod.
+-->
* 使用 `envFrom` 将所有 ConfigMap 的数据定义为容器环境变量，ConfigMap 中的键成为 Pod 中的环境变量名称。
- {{< codenew file="pods/pod-configmap-envFrom.yaml" >}}
+ {{< codenew file="pods/pod-configmap-envFrom.yaml" >}}
- <!-- Create the Pod: -->
-创建 Pod:
+ <!-- Create the Pod: -->
+ 创建 Pod:
- ```shell
- kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-envFrom.yaml
- ```
+ ```shell
+ kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-envFrom.yaml
+ ```
- <!-- Now, the Pod's output includes environment variables `SPECIAL_LEVEL=very` and `SPECIAL_TYPE=charm`. -->
-现在，Pod 的输出包含环境变量 `SPECIAL_LEVEL=very` 和 `SPECIAL_TYPE=charm`。
+ <!-- Now, the Pod's output includes environment variables `SPECIAL_LEVEL=very` and `SPECIAL_TYPE=charm`. -->
+ 现在，Pod 的输出包含环境变量 `SPECIAL_LEVEL=very` 和 `SPECIAL_TYPE=charm`。
-
-<!-- ## Use ConfigMap-defined environment variables in Pod commands -->
+<!--
+## Use ConfigMap-defined environment variables in Pod commands
+-->
## 在 Pod 命令中使用 ConfigMap 定义的环境变量
-<!-- You can use ConfigMap-defined environment variables in the `command` section of the Pod specification using the `$(VAR_NAME)` Kubernetes substitution syntax. -->
-您可以使用 `$(VAR_NAME)` Kubernetes 替换语法在 Pod 规范的 `command` 部分中使用 ConfigMap 定义的环境变量。
+<!--
+You can use ConfigMap-defined environment variables in the `command` section of the Pod specification using the `$(VAR_NAME)` Kubernetes substitution syntax.
+-->
+你可以使用 `$(VAR_NAME)` Kubernetes 替换语法在 Pod 规约的 `command` 部分中使用 ConfigMap 定义的环境变量。
-<!-- For example, the following Pod specification -->
+<!--
+For example, the following Pod specification
+-->
例如，以下 Pod 规范
{{< codenew file="pods/pod-configmap-env-var-valueFrom.yaml" >}}
-<!-- created by running -->
-通过运行创建
+<!--
+created by running
+-->
+通过运行下面命令创建 Pod：
```shell
kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-env-var-valueFrom.yaml
```
-<!-- produces the following output in the `test-container` container: -->
+<!--
+produces the following output in the `test-container` container:
+-->
在 `test-container` 容器中产生以下输出:
-```shell
+```
very charm
```
-<!-- ## Add ConfigMap data to a Volume -->
-## 将 ConfigMap 数据添加到一个容器中
+<!--
+## Add ConfigMap data to a Volume
-<!-- As explained in [Create ConfigMaps from files](#create-configmaps-from-files), when you create a ConfigMap using ``--from-file``, the filename becomes a key stored in the `data` section of the ConfigMap. The file contents become the key's value. -->
-如[根据文件创建ConfigMap](＃create-configmaps-from-files)中所述，当您使用 ``--from-file`` 创建 ConfigMap 时，文件名成为存储在 ConfigMap 的 `data` 部分中的键，文件内容成为键对应的值。
+As explained in [Create ConfigMaps from files](#create-configmaps-from-files), when you create a ConfigMap using ``--from-file``, the filename becomes a key stored in the `data` section of the ConfigMap. The file contents become the key's value.
+-->
+## 将 ConfigMap 数据添加到一个卷中
-<!-- The examples in this section refer to a ConfigMap named special-config, shown below. -->
+如基于文件创建 ConfigMap](#create-configmaps-from-files) 中所述，当你使用
+`--from-file` 创建 ConfigMap 时，文件名成为存储在 ConfigMap 的 `data` 部分中的键，
+文件内容成为键对应的值。
+
+<!--
+The examples in this section refer to a ConfigMap named special-config, shown below.
+-->
本节中的示例引用了一个名为 special-config 的 ConfigMap，如下所示：
{{< codenew file="configmap/configmap-multikeys.yaml" >}}
-<!-- Create the ConfigMap: -->
+<!--
+Create the ConfigMap:
+-->
创建 ConfigMap:
```shell
kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml
```
-<!-- ### Populate a Volume with data stored in a ConfigMap -->
+<!--
+### Populate a Volume with data stored in a ConfigMap
+
+Add the ConfigMap name under the `volumes` section of the Pod specification.
+This adds the ConfigMap data to the directory specified as `volumeMounts.mountPath` (in this case, `/etc/config`).
+The `command` section references the `special.level` item stored in the ConfigMap.
+-->
### 使用存储在 ConfigMap 中的数据填充数据卷
-<!-- Add the ConfigMap name under the `volumes` section of the Pod specification.
-This adds the ConfigMap data to the directory specified as `volumeMounts.mountPath` (in this case, `/etc/config`).
-The `command` section references the `special.level` item stored in the ConfigMap. -->
-在 Pod 规范的 `volumes` 部分下添加 ConfigMap 名称。
-这会将 ConfigMap 数据添加到指定为 `volumeMounts.mountPath` 的目录(在本例中为`/etc/config`)。
-`command` 引用存储在 ConfigMap 中的 `special.level`。
+在 Pod 规约的 `volumes` 部分下添加 ConfigMap 名称。
+这会将 ConfigMap 数据添加到指定为 `volumeMounts.mountPath` 的目录（在本例中为 `/etc/config`）。
+`command` 部分引用存储在 ConfigMap 中的 `special.level`。
{{< codenew file="pods/pod-configmap-volume.yaml" >}}
<!-- Create the Pod: -->
-创建Pod:
+创建 Pod:
```shell
kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume.yaml
```
-<!-- When the pod runs, the command `ls /etc/config/` produces the output below: -->
-运行命令 `ls /etc/config/` 产生下面的输出:
+<!--
+When the pod runs, the command `ls /etc/config/` produces the output below:
+-->
+Pod 运行时，命令 `ls /etc/config/` 产生下面的输出：
```shell
SPECIAL_LEVEL
SPECIAL_TYPE
```
-
+<!--
+If there are some files in the `/etc/config/` directory, they will be deleted.
+-->
{{< caution >}}
-<!-- If there are some files in the `/etc/config/` directory, they will be deleted. -->
如果在 `/etc/config/` 目录中有一些文件，它们将被删除。
{{< /caution >}}
-<!-- ### Add ConfigMap data to a specific path in the Volume -->
+<!--
+Text data is exposed as files using the UTF-8 character encoding. To use some other character encoding, use binaryData.
+-->
+{{< note >}}
+文本数据会使用 UTF-8 字符编码的形式展现为文件。如果使用其他字符编码，
+可以使用 `binaryData`。
+{{< /note >}}
+
+<!--
+### Add ConfigMap data to a specific path in the Volume
+
+Use the `path` field to specify the desired file path for specific ConfigMap items.
+In this case, the `SPECIAL_LEVEL` item will be mounted in the `config-volume` volume at `/etc/config/keys`.
+-->
### 将 ConfigMap 数据添加到数据卷中的特定路径
-<!-- Use the `path` field to specify the desired file path for specific ConfigMap items.
-In this case, the `SPECIAL_LEVEL` item will be mounted in the `config-volume` volume at `/etc/config/keys`. -->
-使用 `path` 字段为特定的 ConfigMap 项目指定所需的文件路径。
-在这种情况下, `SPECIAL_LEVEL` 将挂载在 `/etc/config/keys` 目录下的 `config-volume` 数据卷中。
+使用 `path` 字段为特定的 ConfigMap 项目指定预期的文件路径。
+在这里，`SPECIAL_LEVEL` 将挂载在 `config-volume` 数据卷中 `/etc/config/keys` 目录下。
{{< codenew file="pods/pod-configmap-volume-specific-key.yaml" >}}
-<!-- Create the Pod: -->
-创建Pod:
+<!--
+Create the Pod:
+-->
+创建Pod：
```shell
kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume-specific-key.yaml
```
-<!-- When the pod runs, the command `cat /etc/config/keys` produces the output below: -->
-当 pod 运行时，命令 `cat /etc/config/keys` 产生以下输出:
+<!--
+When the pod runs, the command `cat /etc/config/keys` produces the output below:
+-->
+当 pod 运行时，命令 `cat /etc/config/keys` 产生以下输出：
-```shell
+```
very
```
-
+<!--
+Like before, all previous files in the `/etc/config/` directory will be deleted.
+-->
{{< caution >}}
-<!-- Like before, all previous files in the `/etc/config/` directory will be deleted. -->
-如之前所说，`/etc/config/` 目录中所有先前的文件都将被删除。
+如前，`/etc/config/` 目录中所有先前的文件都将被删除。
{{< /caution >}}
-<!-- ### Project keys to specific paths and file permissions -->
+<!--
+### Project keys to specific paths and file permissions
+
+You can project keys to specific paths and specific permissions on a per-file
+basis. The [Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) user guide explains the syntax.
+-->
### 映射键以指定路径和文件权限
-<!-- You can project keys to specific paths and specific permissions on a per-file
-basis. The [Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) user guide explains the syntax. -->
-您可以通过映射键来指定每个文件的特定路径和特定权限。[Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) 用户指南说明了语法。
+你可以通过指定键名到特定目录的投射关系，也可以逐个文件地设定访问权限。
+[Secret 用户指南](/zh/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod)
+中对这一语法提供了解释。
-<!-- ### Mounted ConfigMaps are updated automatically -->
+<!--
+### Mounted ConfigMaps are updated automatically
+-->
### 挂载的 ConfigMap 将自动更新
-<!-- When a ConfigMap already being consumed in a volume is updated, projected keys are eventually updated as well. Kubelet is checking whether the mounted ConfigMap is fresh on every periodic sync. However, it is using its local ttl-based cache for getting the current value of the ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as kubelet sync period + ttl of ConfigMaps cache in kubelet. -->
-更新已经在数据卷中使用的 ConfigMap 时，最终也会更新映射键。Kubelet 在每次定期同步时都会检查已挂载的 ConfigMap 是否过期。它使用其基于本地 ttl 的缓存来获取 ConfigMap 的当前值。因此，更新 ConfigMap 到将新键映射到 Pod 的总延迟可能与 kubelet 同步周期 + ConfigMap 在 kubelet 中缓存的 ttl 一样长。
+<!--
+When a ConfigMap already being consumed in a volume is updated, projected keys
+are eventually updated as well. Kubelet is checking whether the mounted
+ConfigMap is fresh on every periodic sync. However, it is using its local
+ttl-based cache for getting the current value of the ConfigMap. As a result,
+the total delay from the moment when the ConfigMap is updated to the moment
+when new keys are projected to the pod can be as long as kubelet sync period
+(1 minute by default) + ttl of ConfigMaps cache (1 minute by default) in
+kubelet. You can trigger an immediate refresh by updating one of the pod's
+annotations.
+-->
+更新已经在数据卷中使用的 ConfigMap 时，已映射的键最终也会被更新。
+`kubelet` 在每次定期同步时都会检查已挂载的 ConfigMap 是否是最新的。
+但是，它使用其本地的基于 TTL 的缓存来获取 ConfigMap 的当前值。
+因此，从更新 ConfigMap 到将新键映射到 Pod 的总延迟可能与
+kubelet 同步周期 + ConfigMap 在 kubelet 中缓存的 TTL 一样长。
+<!--
+A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive ConfigMap updates.
+-->
{{< note >}}
-<!-- A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive ConfigMap updates. -->
-使用 ConfigMap 作为[子路径](/docs/concepts/storage/volumes/#using-subpath)的数据卷将不会收到 ConfigMap 更新。
+使用 ConfigMap 作为 [subPath](/zh/docs/concepts/storage/volumes/#using-subpath)
+的数据卷将不会收到 ConfigMap 更新。
{{< /note >}}
-
-
<!-- discussion -->
-<!-- ## Understanding ConfigMaps and Pods -->
+<!--
+## Understanding ConfigMaps and Pods
+
+The ConfigMap API resource stores configuration data as key-value pairs. The data can be consumed in pods or provide the configurations for system components such as controllers. ConfigMap is similar to [Secrets](/docs/concepts/configuration/secret/), but provides a means of working with strings that don't contain sensitive information. Users and system components alike can store configuration data in ConfigMap.
+-->
## 了解 ConfigMap 和 Pod
-<!-- The ConfigMap API resource stores configuration data as key-value pairs. The data can be consumed in pods or provide the configurations for system components such as controllers. ConfigMap is similar to [Secrets](/docs/concepts/configuration/secret/), but provides a means of working with strings that don't contain sensitive information. Users and system components alike can store configuration data in ConfigMap. -->
-ConfigMap API 资源将配置数据存储为键值对。数据可以在 Pod 中使用，也可以提供系统组件(如控制器)的配置。ConfigMap 与 [Secrets](/docs/concepts/configuration/secret/)类似，但是提供了一种使用不包含敏感信息的字符串的方法。用户和系统组件都可以在 ConfigMap 中存储配置数据。
+ConfigMap API 资源将配置数据存储为键值对。
+数据可以在 Pod 中使用，也可以提供系统组件（如控制器）的配置。
+ConfigMap 与 [Secret](/zh/docs/concepts/configuration/secret/) 类似，
+但是提供了一种使用不包含敏感信息的字符串的方法。
+用户和系统组件都可以在 ConfigMap 中存储配置数据。
+<!--
+ConfigMaps should reference properties files, not replace them. Think of the ConfigMap as representing something similar to the Linux `/etc` directory and its contents. For example, if you create a [Kubernetes Volume](/docs/concepts/storage/volumes/) from a ConfigMap, each data item in the ConfigMap is represented by an individual file in the volume.
+-->
{{< note >}}
-<!-- ConfigMaps should reference properties files, not replace them. Think of the ConfigMap as representing something similar to the Linux `/etc` directory and its contents. For example, if you create a [Kubernetes Volume](/docs/concepts/storage/volumes/) from a ConfigMap, each data item in the ConfigMap is represented by an individual file in the volume. -->
-ConfigMap 应该引用属性文件，而不是替换它们。可以将 ConfigMap 理解为类似于 Linux `/etc` 目录及其内容的东西。例如，如果您从 ConfigMap 创建[Kubernetes Volume](/docs/concepts/storage/volumes/)，则 ConfigMap 中的每个数据项都由该数据卷中的单个文件表示。
+ConfigMap 应该引用属性文件，而不是替换它们。可以将 ConfigMap 理解为类似于 Linux
+`/etc` 目录及其内容的东西。例如，如果你从 ConfigMap 创建
+[Kubernetes 卷](/zh/docs/concepts/storage/volumes/)，则 ConfigMap
+中的每个数据项都由该数据卷中的单个文件表示。
{{< /note >}}
-<!-- The ConfigMap's `data` field contains the configuration data. As shown in the example below, this can be simple -- like individual properties defined using `--from-literal` -- or complex -- like configuration files or JSON blobs defined using `--from-file`. -->
-ConfigMap 的 `data` 字段包含配置数据。如下例所示，它可以简单（如用 `--from-literal` 的单个属性定义）或复杂（如用 `--from-file` 的配置文件或 JSON blob定义）。
+<!--
+The ConfigMap's `data` field contains the configuration data. As shown in the example below, this can be simple -- like individual properties defined using `--from-literal` -- or complex -- like configuration files or JSON blobs defined using `--from-file`.
+-->
+ConfigMap 的 `data` 字段包含配置数据。如下例所示，它可以简单
+（如用 `--from-literal` 的单个属性定义）或复杂
+（如用 `--from-file` 的配置文件或 JSON blob定义）。
```yaml
apiVersion: v1
@@ -783,53 +1035,62 @@ metadata:
name: example-config
namespace: default
data:
- # example of a simple property defined using --from-literal
+ # 使用 --from-literal 定义的简单属性
example.property.1: hello
example.property.2: world
- # example of a complex property defined using --from-file
+ # 使用 --from-file 定义复杂属性的例子
example.property.file: |-
property.1=value-1
property.2=value-2
property.3=value-3
```
-<!-- ### Restrictions -->
-### 限制规定
+<!--
+### Restrictions
-<!-- - You must create a ConfigMap before referencing it in a Pod specification (unless you mark the ConfigMap as "optional"). If you reference a ConfigMap that doesn't exist, the Pod won't start. Likewise, references to keys that don't exist in the ConfigMap will prevent the pod from starting. -->
-- 在 Pod 规范中引用之前，必须先创建一个 ConfigMap(除非将 ConfigMap 标记为"可选")。如果引用的 ConfigMap 不存在，则 Pod 将不会启动。同样，引用 ConfigMap 中不存在的键也会阻止 Pod 启动。
+- You must create a ConfigMap before referencing it in a Pod specification (unless you mark the ConfigMap as "optional"). If you reference a ConfigMap that doesn't exist, the Pod won't start. Likewise, references to keys that don't exist in the ConfigMap will prevent the pod from starting.
+-->
+### 限制
-<!-- - If you use `envFrom` to define environment variables from ConfigMaps, keys that are considered invalid will be skipped. The pod will be allowed to start, but the invalid names will be recorded in the event log (`InvalidVariableNames`). The log message lists each skipped key. For example: -->
-- 如果您使用 `envFrom` 从 ConfigMap 中定义环境变量，那么将忽略被认为无效的键。可以启动 Pod，但无效名称将记录在事件日志中(InvalidVariableNames)。日志消息列出了每个跳过的键。例如:
+- 在 Pod 规范中引用之前，必须先创建一个 ConfigMap（除非将 ConfigMap 标记为"可选"）。
+ 如果引用的 ConfigMap 不存在，则 Pod 将不会启动。同样，引用 ConfigMap 中不存在的键也会阻止 Pod 启动。
- ```shell
- kubectl get events
- ```
+<!--
+- If you use `envFrom` to define environment variables from ConfigMaps, keys that are considered invalid will be skipped. The pod will be allowed to start, but the invalid names will be recorded in the event log (`InvalidVariableNames`). The log message lists each skipped key. For example:
+-->
+- 如果你使用 `envFrom` 基于 ConfigMap 定义环境变量，那么无效的键将被忽略。
+ 可以启动 Pod，但无效名称将记录在事件日志中（`InvalidVariableNames`）。
+ 日志消息列出了每个跳过的键。例如:
- <!-- The output is similar to this: -->
- 输出与此类似:
- ```
- LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE
- 0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames {kubelet, 127.0.0.1} Keys [1badkey, 2alsobad] from the EnvFrom configMap default/myconfig were skipped since they are considered invalid environment variable names.
- ```
+ ```shell
+ kubectl get events
+ ```
-<!-- - ConfigMaps reside in a specific [namespace](/docs/concepts/overview/working-with-objects/namespaces/). A ConfigMap can only be referenced by pods residing in the same namespace. -->
-- ConfigMap 位于特定的[命名空间](/docs/concepts/overview/working-with-objects/namespaces/)中. 每个 ConfigMap 只能被同一命名空间中的 Pod 引用.
+ <!-- The output is similar to this: -->
+ 输出与此类似:
-<!-- - Kubelet doesn't support the use of ConfigMaps for pods not found on the API server. This includes pods created via the Kubelet's `--manifest-url` flag, `--config` flag, or the Kubelet REST API. -->
-- Kubelet 不支持将 ConfigMap 用于未在 API 服务器上找到的 Pod。包括通过 Kubelet 的 `--manifest-url` 参数，`--config` 参数或者 Kubelet REST API 创建的容器。
-
- {{< note >}}
- <!-- These are not commonly-used ways to create pods. -->
- 以上并不是创建 Pod 的常用方法。
- {{< /note >}}
+ ```
+ LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE
+ 0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames {kubelet, 127.0.0.1} Keys [1badkey, 2alsobad] from the EnvFrom configMap default/myconfig were skipped since they are considered invalid environment variable names.
+ ```
+<!--
+- ConfigMaps reside in a specific {{< glossary_tooltip term_id="namespace" >}}. A ConfigMap can only be referenced by pods residing in the same namespace.
+-->
+- ConfigMap 位于特定的{{< glossary_tooltip term_id="namespace" text="名字空间" >}}
+ 中。每个 ConfigMap 只能被同一名字空间中的 Pod 引用.
+<!--
+- You can't use ConfigMaps for {{< glossary_tooltip text="static pods" term_id="static-pod" >}}, because the Kubelet does not support this.
+-->
+- 你不能将 ConfigMap 用于 {{< glossary_tooltip text="静态 Pod" term_id="static-pod" >}}，
+ 因为 Kubernetes 不支持这种用法。
## {{% heading "whatsnext" %}}
-<!-- * Follow a real world example of [Configuring Redis using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/). -->
-* 遵循[使用ConfigMap配置Redis](/docs/tutorials/configuration/configure-redis-using-configmap/)的真实案例。
-
-
+<!--
+* Follow a real world example of [Configuring Redis using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/).
+-->
+* 浏览[使用 ConfigMap 配置 Redis](/zh/docs/tutorials/configuration/configure-redis-using-configmap/)
+ 真实实例
diff --git a/content/zh/docs/tasks/configure-pod-container/configure-pod-initialization.md b/content/zh/docs/tasks/configure-pod-container/configure-pod-initialization.md
index 170d8b1a5d..1807a22fee 100644
--- a/content/zh/docs/tasks/configure-pod-container/configure-pod-initialization.md
+++ b/content/zh/docs/tasks/configure-pod-container/configure-pod-initialization.md
@@ -5,11 +5,9 @@ weight: 130
---
<!--
----
title: Configure Pod Initialization
content_type: task
weight: 130
----
-->
<!-- overview -->
@@ -19,14 +17,10 @@ application Container runs.
-->
本文介绍在应用容器运行前，怎样利用 Init 容器初始化 Pod。
-
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
<!-- steps -->
<!--
@@ -38,10 +32,9 @@ container starts.
Here is the configuration file for the Pod:
-->
+## 创建一个包含 Init 容器的 Pod {#creating-a-pod-that-has-an-init-container}
-## 创建一个包含 Init 容器的 Pod
-
-本例中您将创建一个包含一个应用容器和一个 Init 容器的 Pod。Init 容器在应用容器启动前运行完成。
+本例中你将创建一个包含一个应用容器和一个 Init 容器的 Pod。Init 容器在应用容器启动前运行完成。
下面是 Pod 的配置文件：
@@ -56,13 +49,14 @@ shared Volume at `/work-dir`, and the application container mounts the shared
Volume at `/usr/share/nginx/html`. The init container runs the following command
and then terminates:
-->
-
-配置文件中，您可以看到应用容器和 Init 容器共享了一个卷。
+配置文件中，你可以看到应用容器和 Init 容器共享了一个卷。
Init 容器将共享卷挂载到了 `/work-dir` 目录，应用容器将共享卷挂载到了 `/usr/share/nginx/html` 目录。
Init 容器执行完下面的命令就终止：
- wget -O /work-dir/index.html http://kubernetes.io
+```shell
+wget -O /work-dir/index.html http://kubernetes.io
+```
<!--
Notice that the init container writes the `index.html` file in the root directory
@@ -70,37 +64,41 @@ of the nginx server.
Create the Pod:
-->
-
请注意 Init 容器在 nginx 服务器的根目录写入 `index.html`。
创建 Pod：
- kubectl create -f https://k8s.io/examples/pods/init-containers.yaml
+```shell
+kubectl create -f https://k8s.io/examples/pods/init-containers.yaml
+```
<!--
Verify that the nginx container is running:
-->
-
检查 nginx 容器运行正常：
- kubectl get pod init-demo
+```shell
+kubectl get pod init-demo
+```
<!--
The output shows that the nginx container is running:
-->
-
结果表明 nginx 容器运行正常：
- NAME READY STATUS RESTARTS AGE
- init-demo 1/1 Running 0 1m
+```
+NAME READY STATUS RESTARTS AGE
+init-demo 1/1 Running 0 1m
+```
<!--
Get a shell into the nginx container running in the init-demo Pod:
-->
-
通过 shell 进入 init-demo Pod 中的 nginx 容器：
- kubectl exec -it init-demo -- /bin/bash
+```shell
+kubectl exec -it init-demo -- /bin/bash
+```
<!--
In your shell, send a GET request to the nginx server:
@@ -108,33 +106,33 @@ In your shell, send a GET request to the nginx server:
在 shell 中，发送个 GET 请求到 nginx 服务器：
- root@nginx:~# apt-get update
- root@nginx:~# apt-get install curl
- root@nginx:~# curl localhost
+```
+root@nginx:~# apt-get update
+root@nginx:~# apt-get install curl
+root@nginx:~# curl localhost
+```
<!--
The output shows that nginx is serving the web page that was written by the init container:
-->
-
结果表明 nginx 正在为 Init 容器编写的 web 页面服务：
- <!Doctype html>
- <html id="home">
-
- <head>
- ...
- "url": "http://kubernetes.io/"}</script>
- </head>
- <body>
- ...
- <p>Kubernetes is open source giving you the freedom to take advantage ...</p>
- ...
-
+```
+<!Doctype html>
+<html id="home">
+<head>
+...
+"url": "http://kubernetes.io/"}</script>
+</head>
+<body>
+ ...
+ <p>Kubernetes is open source giving you the freedom to take advantage ...</p>
+ ...
+```
## {{% heading "whatsnext" %}}
-
<!--
* Learn more about
[communicating between Containers running in the same Pod](/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/).
@@ -143,11 +141,8 @@ The output shows that nginx is serving the web page that was written by the init
* Learn more about [Debugging Init Containers](/docs/tasks/debug-application-cluster/debug-init-containers/)
-->
-* 进一步了解 [相同 Pod 中的容器间的通信](/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/)。
-* 进一步了解 [Init 容器](/docs/concepts/workloads/pods/init-containers/)。
-* 进一步了解 [卷](/docs/concepts/storage/volumes/)。
-* 进一步了解 [Init 容器排错](/docs/tasks/debug-application-cluster/debug-init-containers/)。
-
-
-
+* 进一步了解[同一 Pod 中的容器间的通信](/zh/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/)。
+* 进一步了解 [Init 容器](/zh/docs/concepts/workloads/pods/init-containers/)。
+* 进一步了解[卷](/zh/docs/concepts/storage/volumes/)。
+* 进一步了解 [Init 容器排错](/zh/docs/tasks/debug-application-cluster/debug-init-containers/)。
diff --git a/content/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage.md b/content/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage.md
index ec91c53ec5..089ed655e8 100644
--- a/content/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage.md
+++ b/content/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage.md
@@ -1,21 +1,16 @@
---
-reviewers:
-- jpeeler
-- pmorie
title: 配置 Pod 使用投射卷作存储
content_type: task
weight: 70
---
<!--
----
reviewers:
- jpeeler
- pmorie
title: Configure a Pod to Use a Projected Volume for Storage
content_type: task
weight: 70
----
-->
<!-- overview -->
@@ -25,22 +20,20 @@ several existing volume sources into the same directory. Currently, `secret`, `c
and `serviceAccountToken` volumes can be projected.
-->
-本文介绍怎样通过[`投射`](/docs/concepts/storage/volumes/#projected) 卷将现有的多个卷资源挂载到相同的目录。
+本文介绍怎样通过[`projected`](/zh/docs/concepts/storage/volumes/#projected) 卷将现有的多个卷资源挂载到相同的目录。
当前，`secret`、`configMap`、`downwardAPI` 和 `serviceAccountToken` 卷可以被投射。
-{{< note >}}
<!--
`serviceAccountToken` is not a volume type.
-->
+{{< note >}}
`serviceAccountToken` 不是一种卷类型
{{< /note >}}
-
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
<!-- steps -->
<!--
@@ -51,62 +44,74 @@ In this exercise, you create username and password Secrets from local files. You
Here is the configuration file for the Pod:
-->
-## 为 Pod 配置投射卷
+## 为 Pod 配置 projected 卷
-本练习中，您将从本地文件来创建包含有用户名和密码的 Secret。然后创建运行一个容器的 Pod，该 Pod 使用[`投射`](/docs/concepts/storage/volumes/#projected) 卷将 Secret 挂载到相同的路径下。
+本练习中，您将从本地文件来创建包含有用户名和密码的 Secret。然后创建运行一个容器的 Pod，
+该 Pod 使用[`projected`](/zh/docs/concepts/storage/volumes/#projected) 卷将 Secret 挂载到相同的路径下。
下面是 Pod 的配置文件：
{{< codenew file="pods/storage/projected.yaml" >}}
-1. <!--Create the Secrets:-->创建 Secrets:
-```shell
- <!--# Create files containing the username and password:--># 创建包含用户名和密码的文件:
- echo -n "admin" > ./username.txt
- echo -n "1f2d1e2e67df" > ./password.txt-->
+1. <!--Create the Secrets:-->
+ 创建 Secrets:
- <!--# Package these files into secrets:--># 将上述文件引用到 Secret：
- kubectl create secret generic user --from-file=./username.txt
- kubectl create secret generic pass --from-file=./password.txt
-```
+ ```shell
+ # 创建包含用户名和密码的文件:
+ echo -n "admin" > ./username.txt
+ echo -n "1f2d1e2e67df" > ./password.txt-->
-1. <!--Create the Pod:-->创建 Pod：
+ # 将上述文件引用到 Secret：
+ kubectl create secret generic user --from-file=./username.txt
+ kubectl create secret generic pass --from-file=./password.txt
+ ```
-```shell
- kubectl create -f https://k8s.io/examples/pods/storage/projected.yaml
-```
+2. <!--Create the Pod:-->
+ 创建 Pod：
-<!--Verify that the Pod's Container is running, and then watch for changes to
-the Pod:-->确认 Pod 中的容器运行正常，然后监视 Pod 的变化：
+ ```shell
+ kubectl create -f https://k8s.io/examples/pods/storage/projected.yaml
+ ```
-```shell
- kubectl get --watch pod test-projected-volume
-```
+ <!--
+ Verify that the Pod's Container is running, and then watch for changes to
+ the Pod:
+ -->
+ 确认 Pod 中的容器运行正常，然后监视 Pod 的变化：
- <!--The output looks like this:-->输出结果和下面类似：
- NAME READY STATUS RESTARTS AGE
- test-projected-volume 1/1 Running 0 14s
+ ```shell
+ kubectl get --watch pod test-projected-volume
+ ```
-1. <!--In another terminal, get a shell to the running Container:-->在另外一个终端中，打开容器的 shell：
-```shell
- kubectl exec -it test-projected-volume -- /bin/sh
-```
+ <!--The output looks like this:-->
+ 输出结果和下面类似：
-1. <!--In your shell, verify that the `projected-volume` directory contains your projected sources:-->在 shell 中，确认 `projected-volume` 目录包含你的投射源：
-```shell
- ls /projected-volume/
-```
+ ```
+ NAME READY STATUS RESTARTS AGE
+ test-projected-volume 1/1 Running 0 14s
+ ```
+3. <!--In another terminal, get a shell to the running Container:-->
+ 在另外一个终端中，打开容器的 shell：
+
+ ```shell
+ kubectl exec -it test-projected-volume -- /bin/sh
+ ```
+
+4. <!--In your shell, verify that the `projected-volume` directory contains your projected sources:-->
+ 在 shell 中，确认 `projected-volume` 目录包含你的投射源：
+
+ ```shell
+ ls /projected-volume/
+ ```
## {{% heading "whatsnext" %}}
-
<!--
* Learn more about [`projected`](/docs/concepts/storage/volumes/#projected) volumes.
* Read the [all-in-one volume](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md) design document.
-->
-* 进一步了解[`投射`](/docs/concepts/storage/volumes/#projected) 卷。
+* 进一步了解[`projected`](/zh/docs/concepts/storage/volumes/#projected) 卷。
* 阅读[一体卷](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md)设计文档。
-
diff --git a/content/zh/docs/tasks/configure-pod-container/configure-runasusername.md b/content/zh/docs/tasks/configure-pod-container/configure-runasusername.md
index d6a2476c6f..b64a51b2ab 100644
--- a/content/zh/docs/tasks/configure-pod-container/configure-runasusername.md
+++ b/content/zh/docs/tasks/configure-pod-container/configure-runasusername.md
@@ -1,15 +1,13 @@
---
-title: 为 Windows 的 pod 和容器配置 RunAsUserName
+title: 为 Windows 的 Pod 和容器配置 RunAsUserName
content_type: task
weight: 20
---
<!--
----
title: Configure RunAsUserName for Windows pods and containers
content_type: task
weight: 20
----
-->
<!-- overview -->
@@ -19,36 +17,38 @@ weight: 20
<!--
This page shows how to enable and use the `RunAsUserName` feature for pods and containers that will run on Windows nodes. This feature is meant to be the Windows equivalent of the Linux-specific `runAsUser` feature, allowing users to run the container entrypoints with a different username that their default ones.
-->
+本页展示如何为运行在 Windows 节点上的 pod 和容器启用并使用 `RunAsUserName` 功能。
+此功能旨在成为 Windows 版的 `runAsUser`（Linux），允许用户使用与默认用户名不同的
+用户名运行容器 entrypoint。
-本页展示如何为运行在 Windows 节点上的 pod 和容器启用并使用 `RunAsUserName` 功能。此功能旨在成为 Windows 版的 `runAsUser`（Linux），允许用户使用与默认用户名不同的用户名运行容器 entrypoint。
-
-{{< note >}}
<!--
This feature is in beta. The overall functionality for `RunAsUserName` will not change, but there may be some changes regarding the username validation.
-->
-该功能目前处于 beta 状态。 `RunAsUserName` 的整体功能不会出现变更，但是关于用户名验证的部分可能会有所更改。
+{{< note >}}
+此功能目前处于 Beta 状态。`RunAsUserName` 的整体功能不会出现变更，
+但是关于用户名验证的部分可能会有所更改。
{{< /note >}}
-
-
## {{% heading "prerequisites" %}}
-
<!--
You need to have a Kubernetes cluster and the kubectl command-line tool must be configured to communicate with your cluster. The cluster is expected to have Windows worker nodes where pods with containers running Windows workloads will get scheduled.
-->
-
-你必须有一个 Kubernetes 集群，并且 kubectl 必须能和集群通信。集群应该要有 Windows 工作节点，将在其中调度运行 Windows 工作负载的 pod 和容器。
+你必须有一个 Kubernetes 集群，并且 kubectl 必须能和集群通信。
+集群应该要有 Windows 工作节点，将在其中调度运行 Windows 工作负载的 pod 和容器。
<!--
## Set the Username for a Pod
To specify the username with which to execute the Pod's container processes, include the `securityContext` field ([PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core) in the Pod specification, and within it, the `windowsOptions` ([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core) field containing the `runAsUserName` field.
-->
-
## 为 Pod 设置 Username
-要指定运行 Pod 容器时所使用的用户名，请在 Pod 声明中包含 `securityContext` （[PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)）字段，并在其内部包含 `windowsOptions` （[WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core)）字段的 `runAsUserName` 字段。
+要指定运行 Pod 容器时所使用的用户名，请在 Pod 声明中包含 `securityContext`
+（[PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)）字段，
+并在其内部包含 `windowsOptions`
+（[WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core)）
+字段的 `runAsUserName` 字段。
<!--
The Windows security context options that you specify for a Pod apply to all Containers and init Containers in the Pod.
@@ -56,7 +56,7 @@ The Windows security context options that you specify for a Pod apply to all Con
Here is a configuration file for a Windows Pod that has the `runAsUserName` field set:
-->
-您为 Pod 指定的 Windows SecurityContext 选项适用于该 Pod 中（包括 init 容器）的所有容器。
+你为 Pod 指定的 Windows SecurityContext 选项适用于该 Pod 中（包括 init 容器）的所有容器。
这儿有一个已经设置了 `runAsUserName` 字段的 Windows Pod 的配置文件：
@@ -127,17 +127,15 @@ The Windows security context options that you specify for a Container apply only
Here is the configuration file for a Pod that has one Container, and the `runAsUserName` field is set at the Pod level and the Container level:
-->
+你为容器指定的 Windows SecurityContext 选项仅适用于该容器，并且它会覆盖 Pod 级别设置。
-您为容器指定的 Windows SecurityContext 选项仅适用于该容器，并且它会覆盖 Pod 级别设置。
-
-这儿有一个 Pod 的配置文件，其只有一个容器，并且在 Pod 级别和容器级别都设置了 `runAsUserName`：
+这里有一个 Pod 的配置文件，其中只有一个容器，并且在 Pod 级别和容器级别都设置了 `runAsUserName`：
{{< codenew file="windows/run-as-username-container.yaml" >}}
<!--
Create the Pod:
-->
-
创建 Pod：
```shell
@@ -147,7 +145,6 @@ kubectl apply -f https://k8s.io/examples/windows/run-as-username-container.yaml
<!--
Verify that the Pod's Container is running:
-->
-
验证 Pod 容器是否在运行：
```shell
@@ -157,7 +154,6 @@ kubectl get pod run-as-username-container-demo
<!--
Get a shell to the running Container:
-->
-
获取该容器的 shell：
```shell
@@ -167,7 +163,6 @@ kubectl exec -it run-as-username-container-demo -- powershell
<!--
Check that the shell is running user the correct username (the one set at the Container level):
-->
-
检查运行 shell 的用户的用户名是否正确（应该是容器级别设置的那个）：
```powershell
@@ -177,10 +172,9 @@ echo $env:USERNAME
<!--
The output should be:
-->
-
输出结果应该是这样：
-```shell
+```
ContainerAdministrator
```
@@ -189,10 +183,11 @@ ContainerAdministrator
In order to use this feature, the value set in the `runAsUserName` field must be a valid username. It must have the following format: `DOMAIN\USER`, where `DOMAIN\` is optional. Windows user names are case insensitive. Additionally, there are some restrictions regarding the `DOMAIN` and `USER`:
-->
-
## Windows Username 的局限性
-想要使用此功能，在 `runAsUserName` 字段中设置的值必须是有效的用户名。它必须是 `DOMAIN\USER` 这种格式，其中 `DOMAIN\` 是可选的。Windows 用户名不区分大小写。此外，关于 `DOMAIN` 和 `USER` 还有一些限制：
+想要使用此功能，在 `runAsUserName` 字段中设置的值必须是有效的用户名。
+它必须是 `DOMAIN\USER` 这种格式，其中 `DOMAIN\` 是可选的。
+Windows 用户名不区分大小写。此外，关于 `DOMAIN` 和 `USER` 还有一些限制：
<!--
- The `runAsUserName` field cannot be empty, and it cannot contain control characters (ASCII values: `0x00-0x1F`, `0x7F`)
@@ -201,7 +196,6 @@ In order to use this feature, the value set in the `runAsUserName` field must be
- DNS names: maximum 255 characters, contains only alphanumeric characters, dots, and dashes, and it cannot start or end with a `.` (dot) or `-` (dash).
- The `USER` must have at most 20 characters, it cannot contain *only* dots or spaces, and it cannot contain the following characters: `" / \ [ ] : ; | = , + * ? < > @`.
-->
-
- `runAsUserName` 字段不能为空，并且不能包含控制字符（ASCII 值：`0x00-0x1F`、`0x7F`）
- `DOMAIN` 必须是 NetBios 名称或 DNS 名称，每种名称都有各自的局限性：
- NetBios 名称：最多 15 个字符，不能以 `.`（点）开头，并且不能包含以下字符：`\ / : * ? " < > |`
@@ -213,24 +207,19 @@ Examples of acceptable values for the `runAsUserName` field: `ContainerAdministr
For more information about these limtations, check [here](https://support.microsoft.com/en-us/help/909264/naming-conventions-in-active-directory-for-computers-domains-sites-and) and [here](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.localaccounts/new-localuser?view=powershell-5.1).
-->
-
-`runAsUserName` 字段接受的值的一些示例：`ContainerAdministrator`、`ContainerUser`、`NT AUTHORITY\NETWORK SERVICE`、`NT AUTHORITY\LOCAL SERVICE`。
+`runAsUserName` 字段接受的值的一些示例：`ContainerAdministrator`、`ContainerUser`、
+`NT AUTHORITY\NETWORK SERVICE`、`NT AUTHORITY\LOCAL SERVICE`。
关于这些限制的更多信息，可以查看[这里](https://support.microsoft.com/en-us/help/909264/naming-conventions-in-active-directory-for-computers-domains-sites-and)和[这里](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.localaccounts/new-localuser?view=powershell-5.1)。
-
-
## {{% heading "whatsnext" %}}
-
<!--
* [Guide for scheduling Windows containers in Kubernetes](/docs/setup/production-environment/windows/user-guide-windows-containers/)
* [Managing Workload Identity with Group Managed Service Accounts (GMSA)](/docs/setup/production-environment/windows/user-guide-windows-containers/#managing-workload-identity-with-group-managed-service-accounts)
* [Configure GMSA for Windows pods and containers](/docs/tasks/configure-pod-container/configure-gmsa/)
-->
-
-* [Kubernetes 中调度 Windows 容器的指南](/docs/setup/production-environment/windows/user-guide-windows-containers/)
-* [使用组托管服务帐户（GMSA）管理工作负载身份](/docs/setup/production-environment/windows/user-guide-windows-containers/#managing-workload-identity-with-group-managed-service-accounts)
-* [Windows 下 pod 和容器的 GMSA 配置](/docs/tasks/configure-pod-container/configure-gmsa/)
-
+* [Kubernetes 中调度 Windows 容器的指南](/zh/docs/setup/production-environment/windows/user-guide-windows-containers/)
+* [使用组托管服务帐户（GMSA）管理工作负载身份](/zh/docs/setup/production-environment/windows/user-guide-windows-containers/#managing-workload-identity-with-group-managed-service-accounts)
+* [Windows 下 pod 和容器的 GMSA 配置](/zh/docs/tasks/configure-pod-container/configure-gmsa/)
diff --git a/content/zh/docs/tasks/configure-pod-container/configure-service-account.md b/content/zh/docs/tasks/configure-pod-container/configure-service-account.md
index 5c53b1d259..bf9f9bf87e 100644
--- a/content/zh/docs/tasks/configure-pod-container/configure-service-account.md
+++ b/content/zh/docs/tasks/configure-pod-container/configure-service-account.md
@@ -1,15 +1,10 @@
---
-reviewers:
-- bprashanth
-- liggitt
-- thockin
title: 为 Pod 配置服务账户
content_type: task
weight: 90
---
<!--
----
reviewers:
- bprashanth
- liggitt
@@ -17,7 +12,6 @@ reviewers:
title: Configure Service Accounts for Pods
content_type: task
weight: 90
----
-->
<!-- overview -->
@@ -25,26 +19,16 @@ weight: 90
<!--
A service account provides an identity for processes that run in a Pod.
-*This is a user introduction to Service Accounts. See also the
-[Cluster Admin Guide to Service Accounts](/docs/reference/access-authn-authz/service-accounts-admin/).*
--->
-
-服务账户为 Pod 中运行的进程提供了一个标识。
-
-*本文是服务账户的用户使用介绍。您也可以参考[集群管理指南之服务账户](/docs/reference/access-authn-authz/service-accounts-admin/)。*
-
-
-{{< note >}}
-<!--
-This document describes how service accounts behave in a cluster set up
-as recommended by the Kubernetes project. Your cluster administrator may have
+This document is a user introduction to Service Accounts and describes how service accounts behave in a cluster set up
+as recommended by the Kubernetes project. Your cluster administrator may have
customized the behavior in your cluster, in which case this documentation may
not apply.
-->
+服务账户为 Pod 中运行的进程提供了一个标识。
-本文档描述 Kubernetes 项目推荐的集群中服务帐户的行为。
-集群管理员也可能已经定制了服务账户在集群中的属性，在这种情况下，本文档可能并不适用。
-
+{{< note >}}
+本文是服务账户的用户使用介绍，描述服务账号在集群中如何起作用。
+你的集群管理员可能已经对你的集群做了定制，因此导致本文中所讲述的内容并不适用。
{{< /note >}}
<!--
@@ -55,20 +39,15 @@ cluster). Processes in containers inside pods can also contact the apiserver.
When they do, they are authenticated as a particular Service Account (for example,
`default`).
-->
-
-当您（人类）访问集群时（例如，使用 `kubectl`），api 服务器将您的身份验证为特定的用户帐户（当前这通常是 `admin`，除非您的集群管理员已经定制了您的集群配置）。
+当你（自然人）访问集群时（例如，使用 `kubectl`），API 服务器将你的身份验证为
+特定的用户帐户（当前这通常是 `admin`，除非你的集群管理员已经定制了你的集群配置）。
Pod 内的容器中的进程也可以与 api 服务器接触。
当它们进行身份验证时，它们被验证为特定的服务帐户（例如，`default`）。
-
-
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
<!-- steps -->
<!--
@@ -80,12 +59,11 @@ If you get the raw json or yaml for a pod you have created (for example, `kubect
you can see the `spec.serviceAccountName` field has been
[automatically set](/docs/user-guide/working-with-resources/#resources-are-automatically-modified).
-->
-
## 使用默认的服务账户访问 API 服务器
-当您创建 Pod 时，如果没有指定服务账户，Pod 会被指定命名空间中的`default`服务账户。
-如果您查看 Pod 的原始 json 或 yaml（例如：`kubectl get pods/podname -o yaml`），
-您可以看到 `spec.serviceAccountName` 字段已经被[自动设置](/docs/user-guide/working-with-resources/#resources-are-automatically-modified)了。
+当你创建 Pod 时，如果没有指定服务账户，Pod 会被指定给命名空间中的 `default` 服务账户。
+如果你查看 Pod 的原始 JSON 或 YAML（例如：`kubectl get pods/podname -o yaml`），
+你可以看到 `spec.serviceAccountName` 字段已经被自动设置了。
<!--
You can access the API from inside a pod using automatically mounted service account credentials,
@@ -95,11 +73,14 @@ The API permissions of the service account depend on the [authorization plugin a
In version 1.6+, you can opt out of automounting API credentials for a service account by setting
`automountServiceAccountToken: false` on the service account:
-->
+你可以使用自动挂载给 Pod 的服务账户凭据访问 API，
+[访问集群](/zh/docs/tasks/access-application-cluster/access-cluster/#accessing-the-api-from-a-pod)
+中有相关描述。
+服务账户的 API 许可取决于你所使用的
+[鉴权插件和策略](/zh/docs/reference/access-authn-authz/authorization/#authorization-modules)。
-您可以使用自动挂载给 Pod 的服务账户凭据访问 API，[访问集群](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod) 中有相关描述。
-服务账户的 API 许可取决于您所使用的[授权插件和策略](/docs/reference/access-authn-authz/authorization/#authorization-modules)。
-
-在 1.6 以上版本中，您可以通过在服务账户上设置 `automountServiceAccountToken: false` 来实现不给服务账号自动挂载 API 凭据：
+在 1.6 以上版本中，你可以通过在服务账户上设置 `automountServiceAccountToken: false`
+来实现不给服务账号自动挂载 API 凭据：
```yaml
@@ -114,8 +95,7 @@ automountServiceAccountToken: false
<!--
In version 1.6+, you can also opt out of automounting API credentials for a particular pod:
-->
-
-在 1.6 以上版本中，您也可以选择不给特定 Pod 自动挂载 API 凭据：
+在 1.6 以上版本中，你也可以选择不给特定 Pod 自动挂载 API 凭据：
```yaml
apiVersion: v1
@@ -130,19 +110,19 @@ spec:
<!--
The pod spec takes precedence over the service account if both specify a `automountServiceAccountToken` value.
+-->
+如果 Pod 和服务账户都指定了 `automountServiceAccountToken` 值，则 Pod 的 spec 优先于服务帐户。
+<!--
## Use Multiple Service Accounts.
Every namespace has a default service account resource called `default`.
You can list this and any other serviceAccount resources in the namespace with this command:
-->
-
-如果 Pod 和服务账户都指定了 `automountServiceAccountToken` 值，则 Pod 的 spec 优先于服务帐户。
-
-## 使用多个服务账户
+## 使用多个服务账户 {#use-multiple-service-accounts}
每个命名空间都有一个名为 `default` 的服务账户资源。
-您可以用下面的命令查询这个服务账户以及命名空间中的其他 serviceAccount 资源：
+你可以用下面的命令查询这个服务账户以及命名空间中的其他 ServiceAccount 资源：
```shell
kubectl get serviceAccounts
@@ -153,8 +133,7 @@ default 1 1d
<!--
You can create additional ServiceAccount objects like this:
-->
-
-您可以像这样来创建额外的 ServiceAccount 对象：
+你可以像这样来创建额外的 ServiceAccount 对象：
```shell
kubectl create -f - <<EOF
@@ -169,8 +148,7 @@ serviceaccount/build-robot created
<!--
If you get a complete dump of the service account object, like this:
-->
-
-如果您查询服务帐户对象的完整信息，如下所示：
+如果你查询服务帐户对象的完整信息，如下所示：
```shell
kubectl get serviceaccounts/build-robot -o yaml
@@ -194,12 +172,12 @@ You may use authorization plugins to [set permissions on service accounts](/docs
To use a non-default service account, simply set the `spec.serviceAccountName`
field of a pod to the name of the service account you wish to use.
-->
+那么你就能看到系统已经自动创建了一个令牌并且被服务账户所引用。
-那么您就能看到系统已经自动创建了一个令牌并且被服务账户所引用。
+你可以使用授权插件来
+[设置服务账户的访问许可](/zh/docs/reference/access-authn-authz/rbac/#service-account-permissions)。
-您可以使用授权插件来 [设置服务账户的访问许可](/docs/reference/access-authn-authz/rbac/#service-account-permissions)。
-
-要使用非默认的服务账户，只需简单的将 Pod 的 `spec.serviceAccountName` 字段设置为您想用的服务账户名称。
+要使用非默认的服务账户，只需简单的将 Pod 的 `spec.serviceAccountName` 字段设置为你想用的服务账户名称。
<!--
The service account has to exist at the time the pod is created, or it will be rejected.
@@ -208,12 +186,11 @@ You cannot update the service account of an already created pod.
You can clean up the service account from this example like this:
-->
-
Pod 被创建时服务账户必须存在，否则会被拒绝。
-您不能更新已经创建好的 Pod 的服务账户。
+你不能更新已经创建好的 Pod 的服务账户。
-您可以清除服务账户，如下所示：
+你可以清除服务账户，如下所示：
```shell
kubectl delete serviceaccount/build-robot
@@ -225,7 +202,6 @@ kubectl delete serviceaccount/build-robot
Suppose we have an existing service account named "build-robot" as mentioned above, and we create
a new secret manually.
-->
-
## 手动创建服务账户 API 令牌
假设我们有一个上面提到的名为 "build-robot" 的服务账户，然后我们手动创建一个新的 Secret。
@@ -248,8 +224,7 @@ Now you can confirm that the newly built secret is populated with an API token f
Any tokens for non-existent service accounts will be cleaned up by the token controller.
-->
-
-现在，您可以确认新构建的 Secret 中填充了 "build-robot" 服务帐户的 API 令牌。
+现在，你可以确认新构建的 Secret 中填充了 "build-robot" 服务帐户的 API 令牌。
令牌控制器将清理不存在的服务帐户的所有令牌。
@@ -270,50 +245,74 @@ namespace: 7 bytes
token: ...
```
-{{< note >}}
<!--
The content of `token` is elided here.
-->
+{{< note >}}
这里省略了 `token` 的内容。
{{< /note >}}
<!--
## Add ImagePullSecrets to a service account
-First, create an imagePullSecret, as described [here](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
-Next, verify it has been created. For example:
+### Create an imagePullSecret
+
+- Create an imagePullSecret, as described in [Specifying ImagePullSecret on a Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
-->
+## 为服务账户添加 ImagePullSecrets {#add-imagepullsecrets-to-a-service-account}
-## 为服务账户添加 ImagePullSecrets
+### 创建 ImagePullSecret
-首先，创建一个 ImagePullSecrets，可以参考[这里](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) 的描述。
-然后，确认创建是否成功。例如：
+- 创建一个 ImagePullSecret，如同[为 Pod 设置 ImagePullSecret](/zh/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)所述。
+
+ ```shell
+ kubectl create secret docker-registry myregistrykey --docker-server=DUMMY_SERVER \
+ --docker-username=DUMMY_USERNAME --docker-password=DUMMY_DOCKER_PASSWORD \
+ --docker-email=DUMMY_DOCKER_EMAIL
+ ```
-```shell
-kubectl get secrets myregistrykey
-NAME TYPE DATA AGE
-myregistrykey kubernetes.io/.dockerconfigjson 1 1d
-```
<!--
+- Verify it has been created.
+-->
+- 确认创建成功：
+
+ ```shell
+ kubectl get secrets myregistrykey
+ ```
+
+ <!-- The output is similar to this: -->
+ 输出类似于：
+
+ ```
+ NAME TYPE DATA AGE
+ myregistrykey kubernetes.io/.dockerconfigjson 1 1d
+ ```
+
+<!--
+### Add image pull secret to service account
+
Next, modify the default service account for the namespace to use this secret as an imagePullSecret.
-->
+### 将镜像拉取 Secret 添加到服务账号
-接着修改命名空间的默认服务帐户，以将该 Secret 用作 imagePullSecret。
+接着修改命名空间的 `default` 服务帐户，以将该 Secret 用作 imagePullSecret。
```shell
kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'
```
<!--
-Interactive version requiring manual edit:
+You can instead use `kubectl edit`, or manually edit the YAML manifests as shown below:
-->
-
-需要手动编辑的交互式版本：
+你也可以使用 `kubectl edit`，或者如下所示手动编辑 YAML 清单：
```shell
kubectl get serviceaccounts default -o yaml > ./sa.yaml
+```
-cat sa.yaml
+`sa.yaml` 文件的内容类似于：
+
+```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
@@ -324,13 +323,19 @@ metadata:
uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
secrets:
- name: default-token-uudge
+```
-vi sa.yaml
-[editor session not shown]
-[delete line with key "resourceVersion"]
-[add lines with "imagePullSecrets:"]
+<!--
+Using your editor of choice (for example `vi`), open the `sa.yaml` file, delete line with key `resourceVersion`, add lines with `imagePullSecrets:` and save.
-cat sa.yaml
+The output of the `sa.yaml` file is similar to this:
+-->
+使用你常用的编辑器（例如 `vi`），打开 `sa.yaml` 文件，删除带有键名
+`resourceVersion` 的行，添加带有 `imagePullSecrets:` 的行，最后保存文件。
+
+所得到的 `sa.yaml` 文件类似于：
+
+```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
@@ -342,37 +347,46 @@ secrets:
- name: default-token-uudge
imagePullSecrets:
- name: myregistrykey
-
-kubectl replace serviceaccount default -f ./sa.yaml
-serviceaccounts/default
```
<!--
-Now, any new pods created in the current namespace will have this added to their spec:
+Finally replace the serviceaccount with the new updated `sa.yaml` file
-->
+最后，用新的更新的 `sa.yaml` 文件替换服务账号。
-现在，在当前命名空间中创建的每个新 Pod 的 spec 中都会添加下面的内容：
-
-```yaml
-spec:
- imagePullSecrets:
- - name: myregistrykey
+```shell
+kubectl replace serviceaccount default -f ./sa.yaml
```
-<!--## Adding Secrets to a service account.
+<!--
+### Verify imagePullSecrets was added to pod spec
-TODO: Test and explain how to use additional non-K8s secrets with an existing service account.
+Now, when a new Pod is created in the current namespace and using the default ServiceAccount, the new Pod has its `spec.imagePullSecrets` field set automatically:
-->
+### 验证镜像拉取 Secret 已经被添加到 Pod 规约
+
+现在，在当前命名空间中创建的每个使用默认服务账号的新 Pod，新 Pod 都会自动
+设置其 `.spec.imagePullSecrets` 字段：
+
+```shell
+kubectl run nginx --image=nginx --restart=Never
+kubectl get pod nginx -o=jsonpath='{.spec.imagePullSecrets[0].name}{"\n"}'
+```
+
+<!-- The output is: -->
+输出为：
+
+```
+myregistrykey
+```
<!--
## Service Account Token Volume Projection
-->
-
-## 服务帐户令牌卷投影
+## 服务帐户令牌卷投射 {#service-account-token-volume-projection}
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
-{{< note >}}
<!--
This ServiceAccountTokenVolumeProjection is __beta__ in 1.12 and
enabled by passing all of the following flags to the API server:
@@ -381,13 +395,13 @@ enabled by passing all of the following flags to the API server:
* `--service-account-signing-key-file`
* `--service-account-api-audiences`
-->
-
-ServiceAccountTokenVolumeProjection 在 1.12 版本中是 __beta__ 阶段，可以通过向 API 服务器传递以下所有参数来启用它：
+{{< note >}}
+ServiceAccountTokenVolumeProjection 在 1.12 版本中是 __beta__ 阶段，
+可以通过向 API 服务器传递以下所有参数来启用它：
* `--service-account-issuer`
* `--service-account-signing-key-file`
* `--service-account-api-audiences`
-
{{< /note >}}
<!--
@@ -397,9 +411,8 @@ duration. These properties are not configurable on the default service account
token. The service account token will also become invalid against the API when
the Pod or the ServiceAccount is deleted.
-->
-
kubelet 还可以将服务帐户令牌投影到 Pod 中。
-您可以指定令牌的所需属性，例如受众和有效持续时间。
+你可以指定令牌的所需属性，例如受众和有效持续时间。
这些属性在默认服务帐户令牌上无法配置。
当删除 Pod 或 ServiceAccount 时，服务帐户令牌也将对 API 无效。
@@ -409,44 +422,151 @@ This behavior is configured on a PodSpec using a ProjectedVolume type called
pod with a token with an audience of "vault" and a validity duration of two
hours, you would configure the following in your PodSpec:
-->
+使用名为 [ServiceAccountToken](/zh/docs/concepts/storage/volumes/#projected) 的
+ProjectedVolume 类型在 PodSpec 上配置此功能。
+要向 Pod 提供具有 "vault" 用户以及两个小时有效期的令牌，可以在 PodSpec 中配置以下内容：
-使用名为 [ServiceAccountToken](/docs/concepts/storage/volumes/#projected) 的 ProjectedVolume 类型在 PodSpec 上配置此功能。
-要向 Pod 提供具有 "vault" 观众以及两个小时有效期的令牌，可以在 PodSpec 中配置以下内容：
+{{< codenew file="pods/pod-projected-svc-token.yaml" >}}
-```yaml
-kind: Pod
-apiVersion: v1
-spec:
- containers:
- - image: nginx
- name: nginx
- volumeMounts:
- - mountPath: /var/run/secrets/tokens
- name: vault-token
- volumes:
- - name: vault-token
- projected:
- sources:
- - serviceAccountToken:
- path: vault-token
- expirationSeconds: 7200
- audience: vault
+<!--
+Create the Pod:
+-->
+创建 Pod：
+
+```shell
+kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml
```
<!--
The kubelet will request and store the token on behalf of the pod, make the
-token available to the pod at a configurable file path, and refresh the token as
-it approaches expiration. Kubelet proactively rotates the token if it is older
-than 80% of its total TTL, or if the token is older than 24 hours.
+token available to the pod at a configurable file path, and refresh the token as it approaches expiration. Kubelet proactively rotates the token if it is older than 80% of its total TTL, or if the token is older than 24 hours.
-The application is responsible for reloading the token when it rotates. Periodic
-reloading (e.g. once every 5 minutes) is sufficient for most usecases.
+The application is responsible for reloading the token when it rotates. Periodic reloading (e.g. once every 5 minutes) is sufficient for most use cases.
-->
+`kubelet` 组件会替 Pod 请求令牌并将其保存起来，通过将令牌存储到一个可配置的
+路径使之在 Pod 内可用，并在令牌快要到期的时候刷新它。
+`kubelet` 会在令牌存在期达到其 TTL 的 80% 的时候或者令牌生命期超过 24 小时
+的时候主动轮换它。
-Kubelet 将代表 Pod 请求和存储令牌，使令牌在可配置的文件路径上对 Pod 可用，并在令牌接近到期时刷新令牌。
-如果令牌存活时间大于其总 TTL 的 80% 或者大于 24 小时，Kubelet 则会主动旋转令牌。
+应用程序负责在令牌被轮换时重新加载其内容。对于大多数使用场景而言，周期性地
+（例如，每隔 5 分钟）重新加载就足够了。
-应用程序负责在令牌旋转时重新加载令牌。
-对于大多数情况，定期重新加载（例如，每 5 分钟一次）就足够了。
+<!--
+## Service Account Issuer Discovery
+-->
+## 发现服务账号分发者
+
+{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+
+<!--
+The Service Account Issuer Discovery feature is enabled by enabling the
+`ServiceAccountIssuerDiscovery` [feature gate](/docs/reference/command-line-tools-reference/feature-gates)
+and then enabling the Service Account Token Projection feature as described
+[above](#service-account-token-volume-projection).
+-->
+通过启用 `ServiceAccountIssuerDiscovery`
+[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates)，
+并按[前文所述](#service-account-token-volume-projection)启用服务账号令牌投射，
+可以启用发现服务账号分发者（Service Account Issuer Discovery）这一功能特性。
+
+<!--
+The issuer URL must comply with the
+[OIDC Discovery Spec](https://openid.net/specs/openid-connect-discovery-1_0.html). In
+practice, this means it must use the `https` scheme, and should serve an OpenID
+provider configuration at `{service-account-issuer}/.well-known/openid-configuration`.
+
+If the URL does not comply, the `ServiceAccountIssuerDiscovery` endpoints will
+not be registered, even if the feature is enabled.
+-->
+{{< note >}}
+分发者的 URL 必须遵从
+[OIDC 发现规范](https://openid.net/specs/openid-connect-discovery-1_0.html)。
+这意味着 URL 必须使用 `https` 模式，并且必须在
+`{service-account-issuer}/.well-known/openid-configuration`
+路径提供 OpenID 提供者（Provider）配置。
+
+如果 URL 没有遵从这一规范，`ServiceAccountIssuerDiscovery` 末端就不会被注册，
+即使该特性已经被启用。
+{{< /note >}}
+
+<!--
+The Service Account Issuer Discovery feature enables federation of Kubernetes
+service account tokens issued by a cluster (the _identity provider_) with
+external systems (_relying parties_).
+
+When enabled, the Kubernetes API server provides an OpenID Provider
+Configuration document at `/.well-known/openid-configuration` and the associated
+JSON Web Key Set (JWKS) at `/openid/v1/jwks`. The OpenID Provider Configuration
+is sometimes referred to as the _discovery document_.
+-->
+发现服务账号分发者这一功能使得用户能够用联邦的方式结合使用 Kubernetes
+集群（_Identity Provider_，标识提供者）与外部系统（_relying parties_，
+依赖方）所分发的服务账号令牌。
+
+当此功能被启用时，Kubernetes API 服务器会在 `/.well-known/openid-configuration`
+提供一个 OpenID 提供者配置文档，并在 `/openid/v1/jwks` 处提供与之关联的
+JSON Web Key Set（JWKS）。
+这里的 OpenID 提供者配置有时候也被称作 _发现文档（Discovery Document）_。
+
+<!--
+When enabled, the cluster is also configured with a default RBAC ClusterRole
+called `system:service-account-issuer-discovery`. No role bindings are provided
+by default. Administrators may, for example, choose whether to bind the role to
+`system:authenticated` or `system:unauthenticated` depending on their security
+requirements and which external systems they intend to federate with.
+-->
+特性被启用时，集群也会配置名为 `system:service-account-issuer-discovery`
+的默认 RBAC ClusterRole，但默认情况下不提供角色绑定对象。
+举例而言，管理员可以根据其安全性需要以及期望集成的外部系统选择是否将该角色绑定到
+`system:authenticated` 或 `system:unauthenticated`。
+
+<!--
+The responses served at `/.well-known/openid-configuration` and
+`/openid/v1/jwks` are designed to be OIDC compatible, but not strictly OIDC
+compliant. Those documents contain only the parameters necessary to perform
+validation of Kubernetes service account tokens.
+-->
+{{< note >}}
+对 `/.well-known/openid-configuration` 和 `/openid/v1/jwks` 路径请求的响应
+被设计为与 OIDC 兼容，但不是完全与其一致。
+返回的文档仅包含对 Kubernetes 服务账号令牌进行验证所必须的参数。
+{{< /note >}}
+
+<!--
+The JWKS response contains public keys that a relying party can use to validate
+the Kubernetes service account tokens. Relying parties first query for the
+OpenID Provider Configuration, and use the `jwks_uri` field in the response to
+find the JWKS.
+-->
+JWKS 响应包含依赖方可以用来验证 Kubernetes 服务账号令牌的公钥数据。
+依赖方先会查询 OpenID 提供者配置，之后使用返回响应中的 `jwks_uri` 来查找
+JWKS。
+
+<!--
+In many cases, Kubernetes API servers are not available on the public internet,
+but public endpoints that serve cached responses from the API server can be made
+available by users or service providers. In these cases, it is possible to
+override the `jwks_uri` in the OpenID Provider Configuration so that it points
+to the public endpoint, rather than the API server's address, by passing the
+`--service-account-jwks-uri` flag to the API server. Like the issuer URL, the
+JWKS URI is required to use the `https` scheme.
+-->
+在很多场合，Kubernetes API 服务器都不会暴露在公网上，不过对于缓存并向外提供 API
+服务器响应数据的公开末端而言，用户或者服务提供商可以选择将其暴露在公网上。
+在这种环境中，可能会重载 OpenID 提供者配置中的
+`jwks_uri`，使之指向公网上可用的末端地址，而不是 API 服务器的地址。
+这时需要向 API 服务器传递 `--service-account-jwks-uri` 参数。
+与分发者 URL 类似，此 JWKS URI 也需要使用 `https` 模式。
+## {{% heading "whatsnext" %}}
+
+<!--
+- [Cluster Admin Guide to Service Accounts](/docs/reference/access-authn-authz/service-accounts-admin/)
+- [Service Account Signing Key Retrieval KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/20190730-oidc-discovery.md)
+- [OIDC Discovery Spec](https://openid.net/specs/openid-connect-discovery-1_0.html)
+-->
+- [服务账号的集群管理员指南](/zh/docs/reference/access-authn-authz/service-accounts-admin/)
+- [服务账号签署密钥检索 KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/20190730-oidc-discovery.md)
+- [OIDC 发现规范](https://openid.net/specs/openid-connect-discovery-1_0.html)
+
diff --git a/content/zh/docs/tasks/configure-pod-container/configure-volume-storage.md b/content/zh/docs/tasks/configure-pod-container/configure-volume-storage.md
index 2f5b7a4e5c..5e5a9907e9 100644
--- a/content/zh/docs/tasks/configure-pod-container/configure-volume-storage.md
+++ b/content/zh/docs/tasks/configure-pod-container/configure-volume-storage.md
@@ -4,19 +4,12 @@ content_type: task
weight: 50
---
<!--
----
title: Configure a Pod to Use a Volume for Storage
content_type: task
weight: 50
----
-->
<!-- overview -->
-
-此页面展示了如何配置 Pod 以使用卷进行存储。
-
-只要容器存在，容器的文件系统就会存在，因此当一个容器终止并重新启动，对该容器的文件系统改动将丢失。对于独立于容器的持久化存储，您可以使用[卷](/docs/concepts/storage/volumes/)。这对于有状态应用程序尤为重要，例如键值存储（如 Redis）和数据库。
-
<!--
This page shows how to configure a Pod to use a Volume for storage.
@@ -26,21 +19,18 @@ consistent storage that is independent of the Container, you can use a
[Volume](/docs/concepts/storage/volumes/). This is especially important for stateful
applications, such as key-value stores (such as Redis) and databases.
-->
+此页面展示了如何配置 Pod 以使用卷进行存储。
-
+只要容器存在，容器的文件系统就会存在，因此当一个容器终止并重新启动，对该容器的文件系统改动将丢失。
+对于独立于容器的持久化存储，你可以使用[卷](/zh/docs/concepts/storage/volumes/)。
+这对于有状态应用程序尤为重要，例如键值存储（如 Redis）和数据库。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
<!-- steps -->
-## 为 Pod 配置卷
-
-在本练习中，您将创建一个运行 Pod，该 Pod 仅运行一个容器并拥有一个类型为 [emptyDir](/docs/concepts/storage/volumes/#emptydir) 的卷，在整个 Pod 生命周期中一直存在，即使 Pod 中的容器被终止和重启。以下是 Pod 的配置：
<!--
## Configure a volume for a Pod
@@ -51,145 +41,143 @@ Volume of type
that lasts for the life of the Pod, even if the Container terminates and
restarts. Here is the configuration file for the Pod:
-->
+## 为 Pod 配置卷 {#configure-a-volume-for-a-pod}
+
+在本练习中，你将创建一个运行 Pod，该 Pod 仅运行一个容器并拥有一个类型为
+[emptyDir](/zh/docs/concepts/storage/volumes/#emptydir) 的卷，
+在整个 Pod 生命周期中一直存在，即使 Pod 中的容器被终止和重启。以下是 Pod 的配置：
+
{{< codenew file="pods/storage/redis.yaml" >}}
-1. 创建 Pod:
<!--
1.Create the Pod:
-->
+1. 创建 Pod:
- ```shell
- kubectl apply -f https://k8s.io/examples/pods/storage/redis.yaml
- ```
+ ```shell
+ kubectl apply -f https://k8s.io/examples/pods/storage/redis.yaml
+ ```
-1. 验证 Pod 中的容器是否正在运行，然后留意 Pod 的更改：
<!--
-1.Verify that the Pod's Container is running, and then watch for changes to
-the Pod:
+1.Verify that the Pod's Container is running, and then watch for changes to the Pod:
-->
+2. 验证 Pod 中的容器是否正在运行，然后留意 Pod 的更改：
- ```shell
- kubectl get pod redis --watch
- ```
+ ```shell
+ kubectl get pod redis --watch
+ ```
- 输出如下：
+ 输出如下：
- ```shell
- NAME READY STATUS RESTARTS AGE
- redis 1/1 Running 0 13s
- ```
+ ```shell
+ NAME READY STATUS RESTARTS AGE
+ redis 1/1 Running 0 13s
+ ```
-1. 在另一个终端，用 shell 连接正在运行的容器：
<!--
1.In another terminal, get a shell to the running Container:
-->
+3. 在另一个终端，用 shell 连接正在运行的容器：
- ```shell
- kubectl exec -it redis -- /bin/bash
- ```
+ ```shell
+ kubectl exec -it redis -- /bin/bash
+ ```
-1. 在您的 shell 终端中，切换到 `/data/redis` 目录下，然后创建一个文件：
<!--
1.In your shell, go to `/data/redis`, and then create a file:
-->
+4. 在你的 Shell中，切换到 `/data/redis` 目录下，然后创建一个文件：
- ```shell
- root@redis:/data# cd /data/redis/
- root@redis:/data/redis# echo Hello > test-file
- ```
+ ```shell
+ root@redis:/data# cd /data/redis/
+ root@redis:/data/redis# echo Hello > test-file
+ ```
-1. 在您的 shell 终端中，列出正在运行的进程：
<!--
1.In your shell, list the running processes:
-->
+5. 在你的 Shell 中，列出正在运行的进程：
- ```shell
- root@redis:/data/redis# apt-get update
- root@redis:/data/redis# apt-get install procps
- root@redis:/data/redis# ps aux
- ```
+ ```shell
+ root@redis:/data/redis# apt-get update
+ root@redis:/data/redis# apt-get install procps
+ root@redis:/data/redis# ps aux
+ ```
- 输出类似于：
+ 输出类似于：
- ```shell
- USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
- redis 1 0.1 0.1 33308 3828 ? Ssl 00:46 0:00 redis-server *:6379
- root 12 0.0 0.0 20228 3020 ? Ss 00:47 0:00 /bin/bash
- root 15 0.0 0.0 17500 2072 ? R+ 00:48 0:00 ps aux
- ```
+ ```shell
+ USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
+ redis 1 0.1 0.1 33308 3828 ? Ssl 00:46 0:00 redis-server *:6379
+ root 12 0.0 0.0 20228 3020 ? Ss 00:47 0:00 /bin/bash
+ root 15 0.0 0.0 17500 2072 ? R+ 00:48 0:00 ps aux
+ ```
-1. 在您的 shell 终端中，结束 Redis 进程：
<!--
1.In your shell, kill the Redis process:
-->
+6. 在你的 Shell 中，结束 Redis 进程：
- ```shell
- root@redis:/data/redis# kill <pid>
- ```
+ ```shell
+ root@redis:/data/redis# kill <pid>
+ ```
- 其中 `<pid>` 是 Redis 进程的 ID (PID)。
+ 其中 `<pid>` 是 Redis 进程的 ID (PID)。
-1. 在您原先终端中，留意 Redis Pod 的更改。最终您将会看到和下面类似的输出：
<!--
1. In your original terminal, watch for changes to the Redis Pod. Eventually,
you will see something like this:
-->
+7. 在你原先终端中，留意 Redis Pod 的更改。最终你将会看到和下面类似的输出：
- ```shell
- NAME READY STATUS RESTARTS AGE
- redis 1/1 Running 0 13s
- redis 0/1 Completed 0 6m
- redis 1/1 Running 1 6m
- ```
+ ```shell
+ NAME READY STATUS RESTARTS AGE
+ redis 1/1 Running 0 13s
+ redis 0/1 Completed 0 6m
+ redis 1/1 Running 1 6m
+ ```
-此时，容器已经终止并重新启动。这是因为 Redis Pod 的 [restartPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) 为 `Always`。
<!--
At this point, the Container has terminated and restarted. This is because the
Redis Pod has a
[restartPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
of `Always`.
-->
+此时，容器已经终止并重新启动。这是因为 Redis Pod 的
+[restartPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
+为 `Always`。
-1. 用 shell 终端进入重新启动的容器中：
<!--
1.Get a shell into the restarted Container:
-->
+1. 用 Shell 进入重新启动的容器中：
- ```shell
- kubectl exec -it redis -- /bin/bash
- ```
+ ```shell
+ kubectl exec -it redis -- /bin/bash
+ ```
-1. 在您的 shell 终端中，进入到 `/data/redis` 目录下，并确认 `test-file` 文件是否仍然存在。
<!--
1.In your shell, goto `/data/redis`, and verify that `test-file` is still there.
-->
+2. 在你的 Shell 中，进入到 `/data/redis` 目录下，并确认 `test-file` 文件是否仍然存在。
- ```shell
- root@redis:/data/redis# cd /data/redis/
- root@redis:/data/redis# ls
- test-file
- ```
+ ```shell
+ root@redis:/data/redis# cd /data/redis/
+ root@redis:/data/redis# ls
+ test-file
+ ```
-1. 删除为此练习所创建的 Pod：
<!--
1.Delete the Pod that you created for this exercise:
-->
+3. 删除为此练习所创建的 Pod：
- ```shell
- kubectl delete pod redis
- ```
-
-
+ ```shell
+ kubectl delete pod redis
+ ```
## {{% heading "whatsnext" %}}
-
-* 参阅[卷](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)。
-
-* 参阅 [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)。
-
-* 除了 `emptyDir` 提供的本地磁盘存储外，Kubernetes 还支持许多不同的网络附加存储解决方案，包括 GCE 上的 PD 和 EC2 上的 EBS，它们是关键数据的首选，并将处理节点上的一些细节，例如安装和卸载设备。了解更多详情请参阅[卷](/docs/concepts/storage/volumes/)。
-
<!--
* See [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core).
@@ -201,5 +189,9 @@ GCE and EBS on EC2, which are preferred for critical data and will handle
details such as mounting and unmounting the devices on the nodes. See
[Volumes](/docs/concepts/storage/volumes/) for more details.
-->
-
+* 参阅 [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)。
+* 参阅 [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)。
+* 除了 `emptyDir` 提供的本地磁盘存储外，Kubernetes 还支持许多不同的网络附加存储解决方案，
+ 包括 GCE 上的 PD 和 EC2 上的 EBS，它们是关键数据的首选，并将处理节点上的一些细节，
+ 例如安装和卸载设备。了解更多详情请参阅[卷](/zh/docs/concepts/storage/volumes/)。
diff --git a/content/zh/docs/tasks/configure-pod-container/extended-resource.md b/content/zh/docs/tasks/configure-pod-container/extended-resource.md
index 005152b9e9..e34a5e4eb1 100644
--- a/content/zh/docs/tasks/configure-pod-container/extended-resource.md
+++ b/content/zh/docs/tasks/configure-pod-container/extended-resource.md
@@ -5,11 +5,9 @@ weight: 40
---
<!--
----
title: Assign Extended Resources to a Container
content_type: task
weight: 40
----
-->
<!-- overview -->
@@ -21,14 +19,8 @@ This page shows how to assign extended resources to a Container.
-->
本文介绍如何为容器指定扩展资源。
-{{< feature-state state="stable" >}}
-
-
-
-
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
@@ -36,11 +28,9 @@ Before you do this exercise, do the exercise in
[Advertise Extended Resources for a Node](/docs/tasks/administer-cluster/extended-resource-node/).
That will configure one of your Nodes to advertise a dongle resource.
-->
-在您开始此练习前，请先练习[为节点广播扩展资源](/docs/tasks/administer-cluster/extended-resource-node/)。
-在那个练习中将配置您的一个节点来广播 dongle 资源。
-
-
-
+在你开始此练习前，请先练习
+[为节点广播扩展资源](/zh/docs/tasks/administer-cluster/extended-resource-node/)。
+在那个练习中将配置你的一个节点来广播 dongle 资源。
<!-- steps -->
@@ -57,9 +47,10 @@ Here is the configuration file for a Pod that has one Container:
-->
## 给 Pod 分派扩展资源
-要请求扩展资源，需要在您的容器清单中包括 `resources:requests` 字段。
+要请求扩展资源，需要在你的容器清单中包括 `resources:requests` 字段。
扩展资源可以使用任何完全限定名称，只是不能使用 `*.kubernetes.io/`。
-有效的扩展资源名的格式为 `example.com/foo`，其中 `example.com` 应被替换为您的组织的域名，而 `foo` 则是描述性的资源名称。
+有效的扩展资源名的格式为 `example.com/foo`，其中 `example.com` 应被替换为
+你的组织的域名，而 `foo` 则是描述性的资源名称。
下面是包含一个容器的 Pod 配置文件：
@@ -70,7 +61,7 @@ In the configuration file, you can see that the Container requests 3 dongles.
Create a Pod:
-->
-在配置文件中，您可以看到容器请求了 3 个 dongles。
+在配置文件中，你可以看到容器请求了 3 个 dongles。
创建 Pod：
@@ -137,7 +128,7 @@ kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod-2.y
<!--
Describe the Pod
-->
-描述 Pod
+描述 Pod：
```shell
kubectl describe pod extended-resource-demo-2
@@ -175,7 +166,7 @@ It has a status of Pending:
-->
输出结果表明 Pod 虽然被创建了，但没有被调度到节点上正常运行。Pod 的状态为 Pending：
-```yaml
+```
NAME READY STATUS RESTARTS AGE
extended-resource-demo-2 0/1 Pending 0 6m
```
@@ -185,7 +176,7 @@ extended-resource-demo-2 0/1 Pending 0 6m
Delete the Pods that you created for this exercise:
-->
-## 环境清理
+## 清理
删除本练习中创建的 Pod：
@@ -194,11 +185,8 @@ kubectl delete pod extended-resource-demo
kubectl delete pod extended-resource-demo-2
```
-
-
## {{% heading "whatsnext" %}}
-
<!--
### For application developers
@@ -207,8 +195,8 @@ kubectl delete pod extended-resource-demo-2
-->
## 应用开发者参考
-* [为容器和 Pod 分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/)
-* [为容器和 Pod 分配 CPU 资源](/docs/tasks/configure-pod-container/assign-cpu-resource/)
+* [为容器和 Pod 分配内存资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)
+* [为容器和 Pod 分配 CPU 资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/)
<!--
### For cluster administrators
@@ -217,7 +205,5 @@ kubectl delete pod extended-resource-demo-2
-->
### 集群管理员参考
-* [为节点广播扩展资源](/docs/tasks/administer-cluster/extended-resource-node/)
-
-
+* [为节点广播扩展资源](/zh/docs/tasks/administer-cluster/extended-resource-node/)
diff --git a/content/zh/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/zh/docs/tasks/configure-pod-container/pull-image-private-registry.md
index b8228ac2ba..f9e4389762 100644
--- a/content/zh/docs/tasks/configure-pod-container/pull-image-private-registry.md
+++ b/content/zh/docs/tasks/configure-pod-container/pull-image-private-registry.md
@@ -5,11 +5,9 @@ weight: 100
---
<!--
----
title: Pull an Image from a Private Registry
content_type: task
weight: 100
----
-->
<!-- overview -->
@@ -18,24 +16,17 @@ weight: 100
This page shows how to create a Pod that uses a Secret to pull an image from a
private Docker registry or repository.
-->
-
本文介绍如何使用 Secret 从私有的 Docker 镜像仓库或代码仓库拉取镜像来创建 Pod。
-
-
## {{% heading "prerequisites" %}}
-
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
* To do this exercise, you need a
[Docker ID](https://docs.docker.com/docker-id/) and password.
-->
-
-您需要 [Docker ID](https://docs.docker.com/docker-id/) 和密码来进行本练习。
-
-
+你需要 [Docker ID](https://docs.docker.com/docker-id/) 和密码来进行本练习。
<!-- steps -->
@@ -44,7 +35,6 @@ private Docker registry or repository.
On your laptop, you must authenticate with a registry in order to pull a private image:
-->
-
## 登录 Docker 镜像仓库
在个人电脑上，要想拉取私有镜像必须在镜像仓库上进行身份验证。
@@ -60,8 +50,7 @@ The login process creates or updates a `config.json` file that holds an authoriz
View the `config.json` file:
-->
-
-当提示时，输入 Docker 用户名和密码。
+当出现提示时，输入 Docker 用户名和密码。
登录过程会创建或更新保存有授权令牌的 `config.json` 文件。
@@ -74,7 +63,6 @@ cat ~/.docker/config.json
<!--
The output contains a section similar to this:
-->
-
输出结果包含类似于以下内容的部分：
```json
@@ -87,10 +75,10 @@ The output contains a section similar to this:
}
```
-{{< note >}}
<!--
If you use a Docker credentials store, you won't see that `auth` entry but a `credsStore` entry with the name of the store as value.
-->
+{{< note >}}
如果使用 Docker 凭证仓库，则不会看到 `auth` 条目，看到的将是以仓库名称作为值的 `credsStore` 条目。
{{< /note >}}
@@ -101,15 +89,21 @@ A Kubernetes cluster uses the Secret of `docker-registry` type to authenticate w
Create this Secret, naming it `regcred`:
-->
-
## 在集群中创建保存授权令牌的 Secret
Kubernetes 集群使用 `docker-registry` 类型的 Secret 来通过容器仓库的身份验证，进而提取私有映像。
创建 Secret，命名为 `regcred`：
-```shell
+<!--
kubectl create secret docker-registry regcred --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>
+-->
+```shell
+kubectl create secret docker-registry regcred \
+ --docker-server=<你的镜像仓库服务器> \
+ --docker-username=<你的用户名> \
+ --docker-password=<你的密码> \
+ --docker-email=<你的邮箱地址>
```
<!--
@@ -122,22 +116,21 @@ where:
You have successfully set your Docker credentials in the cluster as a Secret called `regcred`.
-->
-
在这里：
-* `<your-registry-server>` 是你的私有 Docker 仓库全限定域名（FQDN）。(参考 https://index.docker.io/v1/ 中关于 DockerHub 的部分)
+* `<your-registry-server>` 是你的私有 Docker 仓库全限定域名（FQDN）。
+ (参考 https://index.docker.io/v1/ 中关于 DockerHub 的部分)
* `<your-name>` 是你的 Docker 用户名。
* `<your-pword>` 是你的 Docker 密码。
* `<your-email>` 是你的 Docker 邮箱。
-这样您就成功地将集群中的 Docker 凭据设置为名为 `regcred` 的 Secret。
+这样你就成功地将集群中的 Docker 凭据设置为名为 `regcred` 的 Secret。
<!--
## Inspecting the Secret `regcred`
To understand the contents of the `regcred` Secret you just created, start by viewing the Secret in YAML format:
-->
-
## 检查 Secret `regcred`
要了解你创建的 `regcred` Secret 的内容，可以用 YAML 格式进行查看：
@@ -146,10 +139,7 @@ To understand the contents of the `regcred` Secret you just created, start by vi
kubectl get secret regcred --output=yaml
```
-<!--
-The output is similar to this:
--->
-
+<!-- The output is similar to this: -->
输出和下面类似：
```yaml
@@ -170,7 +160,6 @@ The value of the `.dockerconfigjson` field is a base64 representation of your Do
To understand what is in the `.dockerconfigjson` field, convert the secret data to a
readable format:
-->
-
`.dockerconfigjson` 字段的值是 Docker 凭据的 base64 表示。
要了解 `dockerconfigjson` 字段中的内容，请将 Secret 数据转换为可读格式：
@@ -179,10 +168,7 @@ readable format:
kubectl get secret regcred --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode
```
-<!--
-The output is similar to this:
--->
-
+<!-- The output is similar to this: -->
输出和下面类似：
```json
@@ -192,7 +178,6 @@ The output is similar to this:
<!--
To understand what is in the `auth` field, convert the base64-encoded data to a readable format:
-->
-
要了解 `auth` 字段中的内容，请将 base64 编码过的数据转换为可读格式：
```shell
@@ -202,7 +187,6 @@ echo "c3R...zE2" | base64 --decode
<!--
The output, username and password concatenated with a `:`, is similar to this:
-->
-
输出结果中，用户名和密码用 `:` 链接，类似下面这样：
```none
@@ -213,26 +197,23 @@ janedoe:xxxxxxxxxxx
Notice that the Secret data contains the authorization token similar to your local `~/.docker/config.json` file.
You have successfully set your Docker credentials as a Secret called `regcred` in the cluster.
+-->
+注意，Secret 数据包含与本地 `~/.docker/config.json` 文件类似的授权令牌。
+这样你就已经成功地将 Docker 凭据设置为集群中的名为 `regcred` 的 Secret。
+
+<!--
## Create a Pod that uses your Secret
Here is a configuration file for a Pod that needs access to your Docker credentials in `regcred`:
-->
-
-注意，Secret 数据包含与本地 `~/.docker/config.json` 文件类似的授权令牌。
-
-这样您就已经成功地将 Docker 凭据设置为集群中的名为 `regcred` 的 Secret。
-
-## 创建一个使用您的 Secret 的 Pod
+## 创建一个使用你的 Secret 的 Pod
下面是一个 Pod 配置文件，它需要访问 `regcred` 中的 Docker 凭据：
{{< codenew file="pods/private-reg-pod.yaml" >}}
-<!--
-Download the above file:
--->
-
+<!-- Download the above file: -->
下载上述文件：
```shell
@@ -242,7 +223,6 @@ wget -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yam
<!--
In file `my-private-reg-pod.yaml`, replace `<your-private-image>` with the path to an image in a private registry such as:
-->
-
在`my-private-reg-pod.yaml` 文件中，使用私有仓库的镜像路径替换 `<your-private-image>`，例如：
```none
@@ -255,22 +235,18 @@ The `imagePullSecrets` field in the configuration file specifies that Kubernetes
Create a Pod that uses your Secret, and verify that the Pod is running:
-->
-
要从私有仓库拉取镜像，Kubernetes 需要凭证。
配置文件中的 `imagePullSecrets` 字段表明 Kubernetes 应该通过名为 `regcred` 的 Secret 获取凭证。
创建使用了你的 Secret 的 Pod，并检查它是否正常运行：
```shell
-kubectl create -f my-private-reg-pod.yaml
+kubectl apply -f my-private-reg-pod.yaml
kubectl get pod private-reg
```
-
-
## {{% heading "whatsnext" %}}
-
<!--
* Learn more about [Secrets](/docs/concepts/configuration/secret/).
* Learn more about [using a private registry](/docs/concepts/containers/images/#using-a-private-registry).
@@ -279,10 +255,10 @@ kubectl get pod private-reg
* See the `imagePullSecrets` field of [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
-->
-* 进一步了解 [Secrets](/docs/concepts/configuration/secret/)。
-* 进一步了解 [使用私有仓库](/docs/concepts/containers/images/#using-a-private-registry)。
-* 参考 [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-)。
-* 参考 [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)。
-* 参考 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) 中的 `imagePullSecrets` 字段 。
+* 进一步了解 [Secret](/zh/docs/concepts/configuration/secret/)
+* 进一步了解 [使用私有仓库](/zh/docs/concepts/containers/images/#using-a-private-registry)
+* 参考 [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-)
+* 参考 [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
+* 参考 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) 中的 `imagePullSecrets` 字段
diff --git a/content/zh/docs/tasks/configure-pod-container/quality-service-pod.md b/content/zh/docs/tasks/configure-pod-container/quality-service-pod.md
index 680d38b316..9808a3b9cb 100644
--- a/content/zh/docs/tasks/configure-pod-container/quality-service-pod.md
+++ b/content/zh/docs/tasks/configure-pod-container/quality-service-pod.md
@@ -5,11 +5,9 @@ weight: 30
---
<!--
----
title: Configure Quality of Service for Pods
content_type: task
weight: 30
----
-->
<!-- overview -->
@@ -19,20 +17,13 @@ This page shows how to configure Pods so that they will be assigned particular
Quality of Service (QoS) classes. Kubernetes uses QoS classes to make decisions about
scheduling and evicting Pods.
-->
-
-本文介绍怎样配置 Pod 让其获得特定的服务质量（QoS）类。Kubernetes 使用 QoS 类来决定 Pod 的调度和驱逐策略。
-
-
-
+本页介绍怎样配置 Pod 让其获得特定的服务质量（QoS）类。Kubernetes 使用 QoS 类来决定 Pod 的调度和驱逐策略。
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
-
<!-- steps -->
<!--
@@ -40,8 +31,7 @@ scheduling and evicting Pods.
When Kubernetes creates a Pod it assigns one of these QoS classes to the Pod:
-->
-
-## QoS 类
+## QoS 类 {#qos-classes}
Kubernetes 创建 Pod 时就给它指定了下列一种 QoS 类：
@@ -75,7 +65,6 @@ For a Pod to be given a QoS class of Guaranteed:
Here is the configuration file for a Pod that has one Container. The Container has a memory limit and a
memory request, both equal to 200 MiB. The Container has a CPU limit and a CPU request, both equal to 700 milliCPU:
-->
-
## 创建一个 QoS 类为 Guaranteed 的 Pod
对于 QoS 类为 Guaranteed 的 Pod：
@@ -129,18 +118,18 @@ spec:
requests:
cpu: 700m
memory: 200Mi
-...
+ ...
+status:
qosClass: Guaranteed
```
-{{< note >}}
<!--
If a Container specifies its own memory limit, but does not specify a memory request, Kubernetes
automatically assigns a memory request that matches the limit. Similarly, if a Container specifies its own
CPU limit, but does not specify a CPU request, Kubernetes automatically assigns a CPU request that matches
the limit.
-->
-
+{{< note >}}
如果容器指定了自己的内存限制，但没有指定内存请求，Kubernetes 会自动为它指定与内存限制匹配的内存请求。
同样，如果容器指定了自己的 CPU 限制，但没有指定 CPU 请求，Kubernetes 会自动为它指定与 CPU 限制匹配的 CPU 请求。
{{< /note >}}
@@ -166,7 +155,6 @@ A Pod is given a QoS class of Burstable if:
Here is the configuration file for a Pod that has one Container. The Container has a memory limit of 200 MiB
and a memory request of 100 MiB.
-->
-
## 创建一个 QoS 类为 Burstable 的 Pod
如果满足下面条件，将会指定 Pod 的 QoS 类为 Burstable：
@@ -216,14 +204,14 @@ spec:
memory: 200Mi
requests:
memory: 100Mi
-...
+ ...
+status:
qosClass: Burstable
```
<!--
Delete your Pod:
-->
-
删除 Pod：
```shell
@@ -239,7 +227,6 @@ have any memory or CPU limits or requests.
Here is the configuration file for a Pod that has one Container. The Container has no memory or CPU
limits or requests:
-->
-
## 创建一个 QoS 类为 BestEffort 的 Pod
对于 QoS 类为 BestEffort 的 Pod，Pod 中的容器必须没有设置内存和 CPU 限制或请求。
@@ -247,14 +234,11 @@ limits or requests:
下面是包含一个容器的 Pod 配置文件。
容器没有设置内存和 CPU 限制或请求。
-
-
{{< codenew file="pods/qos/qos-pod-3.yaml" >}}
<!--
Create the Pod:
-->
-
创建 Pod：
```shell
@@ -264,7 +248,6 @@ kubectl create -f https://k8s.io/examples/pods/qos/qos-pod-3.yaml --namespace=qo
<!--
View detailed information about the Pod:
-->
-
查看 Pod 详情：
```shell
@@ -274,7 +257,6 @@ kubectl get pod qos-demo-3 --namespace=qos-example --output=yaml
<!--
The output shows that Kubernetes gave the Pod a QoS class of BestEffort.
-->
-
结果表明 Kubernetes 为 Pod 配置的 QoS 类为 BestEffort。
```yaml
@@ -283,13 +265,13 @@ spec:
...
resources: {}
...
+status:
qosClass: BestEffort
```
<!--
Delete your Pod:
-->
-
删除 Pod：
```shell
@@ -302,14 +284,12 @@ kubectl delete pod qos-demo-3 --namespace=qos-example
Here is the configuration file for a Pod that has two Containers. One container specifies a memory
request of 200 MiB. The other Container does not specify any requests or limits.
-->
-
## 创建包含两个容器的 Pod
下面是包含两个容器的 Pod 配置文件。
一个容器指定了内存请求 200 MiB。
另外一个容器没有指定任何请求和限制。
-
{{< codenew file="pods/qos/qos-pod-4.yaml" >}}
<!--
@@ -318,7 +298,6 @@ criteria for QoS class Guaranteed, and one of its Containers has a memory reques
Create the Pod:
-->
-
注意此 Pod 满足 Burstable QoS 类的标准。
也就是说它不满足 Guaranteed QoS 类标准，因为它的一个容器设有内存请求。
@@ -331,7 +310,6 @@ kubectl create -f https://k8s.io/examples/pods/qos/qos-pod-4.yaml --namespace=qo
<!--
View detailed information about the Pod:
-->
-
查看 Pod 详情：
```shell
@@ -341,7 +319,6 @@ kubectl get pod qos-demo-4 --namespace=qos-example --output=yaml
<!--
The output shows that Kubernetes gave the Pod a QoS class of Burstable:
-->
-
结果表明 Kubernetes 为 Pod 配置的 QoS 类为 Burstable：
```yaml
@@ -356,13 +333,13 @@ spec:
name: qos-demo-4-ctr-2
resources: {}
...
+status:
qosClass: Burstable
```
<!--
Delete your Pod:
-->
-
删除 Pod：
```shell
@@ -374,7 +351,6 @@ kubectl delete pod qos-demo-4 --namespace=qos-example
Delete your namespace:
-->
-
## 环境清理
删除命名空间：
@@ -383,12 +359,8 @@ Delete your namespace:
kubectl delete namespace qos-example
```
-
-
## {{% heading "whatsnext" %}}
-
-
<!--
### For app developers
@@ -396,12 +368,11 @@ kubectl delete namespace qos-example
* [Assign CPU Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/)
-->
-
### 应用开发者参考
-* [为 Pod 和容器分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/)
+* [为 Pod 和容器分配内存资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)
-* [为 Pod 和容器分配 CPU 资源](/docs/tasks/configure-pod-container/assign-cpu-resource/)
+* [为 Pod 和容器分配 CPU 资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/)
<!--
### For cluster administrators
@@ -425,21 +396,20 @@ kubectl delete namespace qos-example
### 集群管理员参考
-* [为命名空间配置默认的内存请求和限制](/docs/tasks/administer-cluster/memory-default-namespace/)
+* [为命名空间配置默认的内存请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
+* [为命名空间配置默认的 CPU 请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace)
-* [为命名空间配置默认的 CPU 请求和限制](/docs/tasks/administer-cluster/cpu-default-namespace/)
+* [为命名空间配置最小和最大内存限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
-* [为命名空间配置最小和最大内存限制](/docs/tasks/administer-cluster/memory-constraint-namespace/)
+* [为命名空间配置最小和最大 CPU 限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
-* [为命名空间配置最小和最大 CPU 限制](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
+* [为命名空间配置内存和 CPU 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
-* [为命名空间配置内存和 CPU 配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
+* [为命名空间配置 Pod 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
-* [为命名空间配置 Pod 配额](/docs/tasks/administer-cluster/quota-pod-namespace/)
+* [为 API 对象配置配额](/zh/docs/tasks/administer-cluster/quota-api-object/)
-* [为 API 对象配置配额](/docs/tasks/administer-cluster/quota-api-object/)
-
-* [控制节点上的拓扑管理策略](/docs/tasks/administer-cluster/topology-manager/)
+* [控制节点上的拓扑管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)
diff --git a/content/zh/docs/tasks/configure-pod-container/static-pod.md b/content/zh/docs/tasks/configure-pod-container/static-pod.md
index eef7ea7f2b..573bdd8d2d 100644
--- a/content/zh/docs/tasks/configure-pod-container/static-pod.md
+++ b/content/zh/docs/tasks/configure-pod-container/static-pod.md
@@ -1,6 +1,4 @@
---
-reviewers:
-- jsafrane
title: 创建静态 Pod
weight: 170
content_type: task
@@ -17,8 +15,10 @@ Unlike Pods that are managed by the control plane (for example, a
instead, the kubelet watches each static Pod (and restarts it if it crashes).
-->
-*静态 Pod* 在指定的节点上由 kubelet 守护进程直接管理，不需要 {{< glossary_tooltip text="API 服务" term_id="kube-apiserver" >}} 监管。
-不像 Pod 是由控制面管理的（例如，{{< glossary_tooltip text="Deployment" term_id="deployment" >}}）；相反 kubelet 监视每个静态 Pod（在它崩溃之后重新启动）。
+*静态 Pod* 在指定的节点上由 kubelet 守护进程直接管理，不需要
+{{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}} 监管。
+与由控制面管理的 Pod（例如，{{< glossary_tooltip text="Deployment" term_id="deployment" >}}）
+不同；kubelet 监视每个静态 Pod（在它崩溃之后重新启动）。
<!--
Static Pods are always bound to one {{< glossary_tooltip term_id="kubelet" >}} on a specific node.
@@ -35,18 +35,17 @@ Pods to run a Pod on every node, you should probably be using a
instead.
{{< /note >}}
-->
-
静态 Pod 永远都会绑定到一个指定节点上的 {{< glossary_tooltip term_id="kubelet" >}}。
-kubelet 会尝试通过 Kubernetes API 服务器为每个静态 Pod 自动创建一个 {{< glossary_tooltip text="镜像 Pod" term_id="mirror-pod" >}}。
+kubelet 会尝试通过 Kubernetes API 服务器为每个静态 Pod 自动创建一个
+{{< glossary_tooltip text="镜像 Pod" term_id="mirror-pod" >}}。
这意味着节点上运行的静态 Pod 对 API 服务来说是不可见的，但是不能通过 API 服务器来控制。
{{< note >}}
-如果你在运行一个 Kubernetes 集群，并且在每个节点上都运行一个静态 Pod，就可能需要考虑使用 {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}} 替代这种方式。
+如果你在运行一个 Kubernetes 集群，并且在每个节点上都运行一个静态 Pod，
+就可能需要考虑使用 {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}} 替代这种方式。
{{< /note >}}
-
-
## {{% heading "prerequisites" %}}
@@ -57,12 +56,10 @@ This page assumes you're using {{< glossary_tooltip term_id="docker" >}} to run
and that your nodes are running the Fedora operating system.
Instructions for other distributions or Kubernetes installations may vary.
-->
-
-本文假定你在使用 {{< glossary_tooltip term_id="docker" >}} 来运行 Pod，并且你的节点是运行着 Fedora 操作系统。
+本文假定你在使用 {{< glossary_tooltip term_id="docker" >}} 来运行 Pod，
+并且你的节点是运行着 Fedora 操作系统。
其它发行版或者 Kubernetes 部署版本上操作方式可能不一样。
-
-
<!-- steps -->
<!--
@@ -70,10 +67,11 @@ Instructions for other distributions or Kubernetes installations may vary.
You can configure a static Pod with either a [file system hosted configuration file](/docs/tasks/configure-pod-container/static-pod/#configuration-files) or a [web hosted configuration file](/docs/tasks/configure-pod-container/static-pod/#pods-created-via-http).
-->
-
## 创建静态 Pod {#static-pod-creation}
-可以通过[文件系统上的配置文件](/docs/tasks/configure-pod-container/static-pod/#configuration-files)或者 [web 网络上的配置文件](/docs/tasks/configure-pod-container/static-pod/#pods-created-via-http)来配置静态 Pod。
+可以通过[文件系统上的配置文件](/zh/docs/tasks/configure-pod-container/static-pod/#configuration-files)
+或者 [web 网络上的配置文件](/zh/docs/tasks/configure-pod-container/static-pod/#pods-created-via-http)
+来配置静态 Pod。
<!--
### Filesystem-hosted static Pod manifest {#configuration-files}
@@ -83,10 +81,12 @@ Note that the kubelet will ignore files starting with dots when scanning the spe
For example, this is how to start a simple web server as a static Pod:
-->
-
### 文件系统上的静态 Pod 声明文件 {#configuration-files}
-声明文件是标准的 Pod 定义文件，以 JSON 或者 YAML 格式存储在指定目录。路径设置在 [Kubelet 配置文件](/docs/tasks/administer-cluster/kubelet-config-file)的 `staticPodPath: <目录>` 字段，kubelet 会定期的扫描这个文件夹下的 YAML/JSON 文件来创建/删除静态 Pod。
+声明文件是标准的 Pod 定义文件，以 JSON 或者 YAML 格式存储在指定目录。路径设置在
+[Kubelet 配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/)
+的 `staticPodPath: <目录>` 字段，kubelet 会定期的扫描这个文件夹下的 YAML/JSON
+文件来创建/删除静态 Pod。
注意 kubelet 扫描目录的时候会忽略以点开头的文件。
例如：下面是如何以静态 Pod 的方式启动一个简单 web 服务：
@@ -97,9 +97,9 @@ For example, this is how to start a simple web server as a static Pod:
1. 选择一个要运行静态 Pod 的节点。在这个例子中选择 `my-node1`。
- ```shell
- ssh my-node1
- ```
+ ```shell
+ ssh my-node1
+ ```
<!--
2. Choose a directory, say `/etc/kubelet.d` and place a web server Pod definition there, e.g. `/etc/kubelet.d/static-web.yaml`:
@@ -123,29 +123,30 @@ For example, this is how to start a simple web server as a static Pod:
protocol: TCP
EOF
-->
+2. 选择一个目录，比如在 `/etc/kubelet.d` 目录来保存 web 服务 Pod 的定义文件，
+ `/etc/kubelet.d/static-web.yaml`：
-1. 选择一个目录，比如在 `/etc/kubelet.d` 目录来保存 web 服务 Pod 的定义文件， `/etc/kubelet.d/static-web.yaml`：
+ ```shell
+ # 在 kubelet 运行的节点上执行以下命令
+ mkdir /etc/kubelet.d/
+ cat <<EOF >/etc/kubelet.d/static-web.yaml
+ apiVersion: v1
+ kind: Pod
+ metadata:
+ name: static-web
+ labels:
+ role: myrole
+ spec:
+ containers:
+ - name: web
+ image: nginx
+ ports:
+ - name: web
+ containerPort: 80
+ protocol: TCP
+ EOF
+ ```
- ```shell
- # 在 kubelet 运行的节点上执行以下命令
- mkdir /etc/kubelet.d/
- cat <<EOF >/etc/kubelet.d/static-web.yaml
- apiVersion: v1
- kind: Pod
- metadata:
- name: static-web
- labels:
- role: myrole
- spec:
- containers:
- - name: web
- image: nginx
- ports:
- - name: web
- containerPort: 80
- protocol: TCP
- EOF
- ```
<!--
1. Configure your kubelet on the node to use this directory by running it with `--pod-manifest-path=/etc/kubelet.d/` argument. On Fedora edit `/etc/kubernetes/kubelet` to include this line:
@@ -154,13 +155,13 @@ For example, this is how to start a simple web server as a static Pod:
```
or add the `staticPodPath: <the directory>` field in the [KubeletConfiguration file](/docs/tasks/administer-cluster/kubelet-config-file).
-->
-
3. 配置这个节点上的 kubelet，使用这个参数执行 `--pod-manifest-path=/etc/kubelet.d/`：
- ```
- KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
- ```
- 或者在 [Kubelet配置文件](/docs/tasks/administer-cluster/kubelet-config-file)中添加 `staticPodPath: <目录>`字段。
+ ```
+ KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
+ ```
+ 或者在 [Kubelet配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/)
+ 中添加 `staticPodPath: <目录>`字段。
<!--
1. Restart the kubelet. On Fedora, you would run:
@@ -170,13 +171,13 @@ For example, this is how to start a simple web server as a static Pod:
systemctl restart kubelet
```
-->
+4. 重启 kubelet。Fedora 上使用下面的命令：
-1. 重启 kubelet。Fedora 上使用下面的命令：
+ ```shell
+ # 在 kubelet 运行的节点上执行以下命令
+ systemctl restart kubelet
+ ```
- ```shell
- # 在 kubelet 运行的节点上执行以下命令
- systemctl restart kubelet
- ```
<!--
### Web-hosted static pod manifest {#pods-created-via-http}
@@ -188,46 +189,46 @@ Pods, the kubelet applies them.
To use this approach:
-->
-
### Web 网上的静态 Pod 声明文件 {#pods-created-via-http}
-Kubelet 根据 `--manifest-url=<URL>` 参数的配置定期的下载指定文件，并且转换成 JSON/YAML 格式的 Pod 容器定义文件。
-与[文件系统上的声明文件](#configuration-files)使用方式类似，kubelet 调度获取声明文件。如果静态 Pod 的声明文件有改变，kubelet会应用这些改变。
+Kubelet 根据 `--manifest-url=<URL>` 参数的配置定期的下载指定文件，并且转换成
+JSON/YAML 格式的 Pod 定义文件。
+与[文件系统上的清单文件](#configuration-files)使用方式类似，kubelet 调度获取清单文件。
+如果静态 Pod 的清单文件有改变，kubelet 会应用这些改变。
按照下面的方式来：
<!--
1. Create a YAML file and store it on a web server so that you can pass the URL of that file to the kubelet.
-->
-
1. 创建一个 YAML 文件，并保存在保存在 web 服务上，为 kubelet 生成一个 URL。
- ```yaml
- apiVersion: v1
- kind: Pod
- metadata:
- name: static-web
- labels:
- role: myrole
- spec:
- containers:
- - name: web
- image: nginx
- ports:
- - name: web
- containerPort: 80
- protocol: TCP
- ```
+ ```yaml
+ apiVersion: v1
+ kind: Pod
+ metadata:
+ name: static-web
+ labels:
+ role: myrole
+ spec:
+ containers:
+ - name: web
+ image: nginx
+ ports:
+ - name: web
+ containerPort: 80
+ protocol: TCP
+ ```
<!--
2. Configure the kubelet on your selected node to use this web manifest by running it with `--manifest-url=<manifest-url>`. On Fedora, edit `/etc/kubernetes/kubelet` to include this line:
-->
+2. 通过在选择的节点上使用 `--manifest-url=<manifest-url>` 配置运行 kubelet。
+ 在 Fedora 添加下面这行到 `/etc/kubernetes/kubelet` ：
-1. 通过在选择的节点上使用 `--manifest-url=<manifest-url>` 配置运行 kubelet。在 Fedora 添加下面这行到 `/etc/kubernetes/kubelet` ：
-
- ```
- KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --manifest-url=<manifest-url>"
- ```
+ ```
+ KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --manifest-url=<manifest-url>"
+ ```
<!--
3. Restart the kubelet. On Fedora, you would run:
@@ -236,13 +237,13 @@ Kubelet 根据 `--manifest-url=<URL>` 参数的配置定期的下载指定文件
systemctl restart kubelet
```
-->
+3. 重启 kubelet。在 Fedora 上运行如下命令：
-1. 重启 kubelet。在 Fedora 上运行如下命令：
+ ```shell
+ # 在 kubelet 运行的节点上执行以下命令
+ systemctl restart kubelet
+ ```
- ```shell
- # 在 kubelet 运行的节点上执行以下命令
- systemctl restart kubelet
- ```
<!--
## Observe static pod behavior {#behavior-of-static-pods}
@@ -258,48 +259,49 @@ docker ps
The output might be something like:
-->
-
## 观察静态 pod 的行为 {#behavior-of-static-pods}
-当 kubelet 启动时，会自动启动所有定义的静态 Pod。当定义了一个静态 Pod 并重新启动 kubelet 时，新的静态 Pod 就应该已经在运行了。
+当 kubelet 启动时，会自动启动所有定义的静态 Pod。
+当定义了一个静态 Pod 并重新启动 kubelet 时，新的静态 Pod 就应该已经在运行了。
可以在节点上运行下面的命令来查看正在运行的容器（包括静态 Pod）：
+
```shell
# 在 kubelet 运行的节点上执行以下命令
docker ps
```
+
<!--
The output might be something like:
-->
-
输出可能会像这样：
```
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c
```
+
<!--
You can see the mirror Pod on the API server:
-->
-
可以在 API 服务上看到镜像 Pod：
```shell
kubectl get pods
```
+
```
NAME READY STATUS RESTARTS AGE
static-web-my-node1 1/1 Running 0 2m
```
+
<!--
-{{< note >}}
Make sure the kubelet has permission to create the mirror Pod in the API server. If not, the creation request is rejected by the API server. See
[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/).
-{{< /note >}}
-->
-
{{< note >}}
-要确保 kubelet 在 API 服务上有创建镜像 Pod 的权限。如果没有，创建请求会被 API 服务拒绝。可以看[Pod安全策略](/docs/concepts/policy/pod-security-policy/)。
+要确保 kubelet 在 API 服务上有创建镜像 Pod 的权限。如果没有，创建请求会被 API 服务拒绝。
+可以看[Pod安全策略](/zh/docs/concepts/policy/pod-security-policy/)。
{{< /note >}}
<!--
@@ -307,7 +309,8 @@ Make sure the kubelet has permission to create the mirror Pod in the API server.
propagated into the mirror Pod. You can use those labels as normal via
{{< glossary_tooltip term_id="selector" text="selectors" >}}, etc.
-->
-静态 Pod 上的{{< glossary_tooltip term_id="label" text="标签" >}} 被传到镜像 Pod。 你可以通过 {{< glossary_tooltip term_id="selector" text="选择算符" >}} 使用这些标签，比如。
+静态 Pod 上的{{< glossary_tooltip term_id="label" text="标签" >}} 被传到镜像 Pod。
+你可以通过 {{< glossary_tooltip term_id="selector" text="选择算符" >}} 使用这些标签。
<!--
If you try to use `kubectl` to delete the mirror Pod from the API server,
@@ -321,17 +324,21 @@ kubectl delete pod static-web-my-node1
```
pod "static-web-my-node1" deleted
```
+
<!--
You can see that the Pod is still running:
-->
可以看到 Pod 还在运行：
+
```shell
kubectl get pods
```
+
```
NAME READY STATUS RESTARTS AGE
static-web-my-node1 1/1 Running 0 12s
```
+
<!--
Back on your node where the kubelet is running, you can try to stop the Docker
container manually.
@@ -345,20 +352,22 @@ sleep 20
docker ps
```
-->
-
回到 kubelet 运行的节点上，可以手工停止 Docker 容器。
可以看到过了一段时间后 kubelet 会发现容器停止了并且会自动重启 Pod：
```shell
# 在 kubelet 运行的节点上执行以下命令
-docker stop f6d05272b57e # 把 ID 换为你的容器的 ID
+# 把 ID 换为你的容器的 ID
+docker stop f6d05272b57e
sleep 20
docker ps
```
+
```
CONTAINER ID IMAGE COMMAND CREATED ...
5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ...
```
+
<!--
## Dynamic addition and removal of static pods
@@ -379,12 +388,12 @@ docker ps
-->
## 动态增加和删除静态 pod
-运行中的 kubelet 会定期扫描配置的目录(比如例子中的 `/etc/kubelet.d` 目录)中的变化，并且根据文件中出现/消失的 Pod 来添加/删除 Pod。
+运行中的 kubelet 会定期扫描配置的目录(比如例子中的 `/etc/kubelet.d` 目录)中的变化，
+并且根据文件中出现/消失的 Pod 来添加/删除 Pod。
```shell
# 前提是你在用主机文件系统上的静态 Pod 配置文件
# 在 kubelet 运行的节点上执行以下命令
-#
mv /etc/kubelet.d/static-web.yaml /tmp
sleep 20
docker ps
@@ -393,6 +402,7 @@ mv /tmp/static-web.yaml /etc/kubelet.d/
sleep 20
docker ps
```
+
```
CONTAINER ID IMAGE COMMAND CREATED ...
e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago
diff --git a/content/zh/docs/tasks/configure-pod-container/translate-compose-kubernetes.md b/content/zh/docs/tasks/configure-pod-container/translate-compose-kubernetes.md
index 9ecc6c22f2..175bdac0da 100644
--- a/content/zh/docs/tasks/configure-pod-container/translate-compose-kubernetes.md
+++ b/content/zh/docs/tasks/configure-pod-container/translate-compose-kubernetes.md
@@ -7,13 +7,9 @@ weight: 200
---
<!--
----
-reviewers:
-- cdrage
title: Translate a Docker Compose File to Kubernetes Resources
content_type: task
weight: 170
----
-->
<!-- overview -->
@@ -21,52 +17,41 @@ weight: 170
<!--
What's Kompose? It's a conversion tool for all things compose (namely Docker Compose) to container orchestrators (Kubernetes or OpenShift).
-->
-
-Kompose 是什么？它是个转换工具，可将 compose（即 Docker Compose）所组装的所有内容转换成容器编排器（Kubernetes 或 OpenShift）可识别的形式。
+Kompose 是什么？它是个转换工具，可将 compose（即 Docker Compose）所组装的所有内容
+转换成容器编排器（Kubernetes 或 OpenShift）可识别的形式。
<!--
More information can be found on the Kompose website at [http://kompose.io](http://kompose.io).
-->
-
更多信息请参考 Kompose 官网 [http://kompose.io](http://kompose.io)。
-
-
-
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
<!-- steps -->
<!--
## Install Kompose
--->
-## 安装 Kompose
-
-<!--
We have multiple ways to install Kompose. Our preferred method is downloading the binary from the latest GitHub release.
-->
+## 安装 Kompose
我们有很多种方式安装 Kompose。首选方式是从最新的 GitHub 发布页面下载二进制文件。
<!--
## GitHub release
--->
-## GitHub 发布版本
-
-<!--
Kompose is released via GitHub on a three-week cycle, you can see all current releases on the [GitHub release page](https://github.com/kubernetes/kompose/releases).
-->
+## GitHub 发布版本
-Kompose 通过 GitHub 发布版本，发布周期为三星期。您可以在[GitHub 发布页面](https://github.com/kubernetes/kompose/releases)上看到所有当前版本。
+Kompose 通过 GitHub 发布版本，发布周期为三星期。
+你可以在 [GitHub 发布页面](https://github.com/kubernetes/kompose/releases)
+上看到所有当前版本。
-```sh
+```shell
# Linux
curl -L https://github.com/kubernetes/kompose/releases/download/v1.16.0/kompose-linux-amd64 -o kompose
@@ -83,18 +68,16 @@ sudo mv ./kompose /usr/local/bin/kompose
<!--
Alternatively, you can download the [tarball](https://github.com/kubernetes/kompose/releases).
-->
-或者，您可以下载 [tarball](https://github.com/kubernetes/kompose/releases)。
+或者，你可以下载 [tarball](https://github.com/kubernetes/kompose/releases)。
## Go
<!--
Installing using `go get` pulls from the master branch with the latest development changes.
-->
-
用 `go get` 命令从主分支拉取最新的开发变更的方法安装 Kompose。
-
-```sh
+```shell
go get -u github.com/kubernetes/kompose
```
@@ -104,17 +87,17 @@ go get -u github.com/kubernetes/kompose
Kompose is in [EPEL](https://fedoraproject.org/wiki/EPEL) CentOS repository.
If you don't have [EPEL](https://fedoraproject.org/wiki/EPEL) repository already installed and enabled you can do it by running `sudo yum install epel-release`
-->
-
Kompose 位于 [EPEL](https://fedoraproject.org/wiki/EPEL) CentOS 代码仓库。
-如果您还没有安装启用 [EPEL](https://fedoraproject.org/wiki/EPEL) 代码仓库，请运行命令 `sudo yum install epel-release`。
+如果你还没有安装启用 [EPEL](https://fedoraproject.org/wiki/EPEL) 代码仓库，
+请运行命令 `sudo yum install epel-release`。
<!--
If you have [EPEL](https://fedoraproject.org/wiki/EPEL) enabled in your system, you can install Kompose like any other package.
-->
+如果你的系统中已经启用了 [EPEL](https://fedoraproject.org/wiki/EPEL)，
+你就可以像安装其他软件包一样安装 Kompose。
-如果您的系统中已经启用了 [EPEL](https://fedoraproject.org/wiki/EPEL)，您就可以像安装其他软件包一样安装 Kompose。
-
-```bash
+```shell
sudo yum -y install kompose
```
@@ -123,10 +106,9 @@ sudo yum -y install kompose
<!--
Kompose is in Fedora 24, 25 and 26 repositories. You can install it just like any other package.
-->
+Kompose 位于 Fedora 24、25 和 26 的代码仓库。你可以像安装其他软件包一样安装 Kompose。
-Kompose 位于 Fedora 24、25 和 26 的代码仓库。您可以像安装其他软件包一样安装 Kompose。
-
-```bash
+```shell
sudo dnf -y install kompose
```
@@ -135,152 +117,154 @@ sudo dnf -y install kompose
<!--
On macOS you can install latest release via [Homebrew](https://brew.sh):
-->
+在 macOS 上你可以通过 [Homebrew](https://brew.sh) 安装 Kompose 的最新版本：
-在 macOS 上您可以通过 [Homebrew](https://brew.sh) 安装 Kompose 的最新版本：
-
-```bash
+```shell
brew install kompose
-
```
+
<!--
## Use Kompose
-->
-
## 使用 Kompose
<!--
In just a few steps, we'll take you from Docker Compose to Kubernetes. All
you need is an existing `docker-compose.yml` file.
-->
-
再需几步，我们就把你从 Docker Compose 带到 Kubernetes。
-您只需要一个现有的 `docker-compose.yml` 文件。
+你只需要一个现有的 `docker-compose.yml` 文件。
1. <!--Go to the directory containing your `docker-compose.yml` file. If you don't
have one, test using this one.-->
进入 `docker-compose.yml` 文件所在的目录。如果没有，请使用下面这个进行测试。
- ```yaml
- version: "2"
+ ```yaml
+ version: "2"
- services:
+ services:
- redis-master:
- image: k8s.gcr.io/redis:e2e
- ports:
- - "6379"
+ redis-master:
+ image: k8s.gcr.io/redis:e2e
+ ports:
+ - "6379"
- redis-slave:
- image: gcr.io/google_samples/gb-redisslave:v3
- ports:
- - "6379"
- environment:
- - GET_HOSTS_FROM=dns
-
- frontend:
- image: gcr.io/google-samples/gb-frontend:v4
- ports:
- - "80:80"
- environment:
- - GET_HOSTS_FROM=dns
- labels:
- kompose.service.type: LoadBalancer
- ```
+ redis-slave:
+ image: gcr.io/google_samples/gb-redisslave:v3
+ ports:
+ - "6379"
+ environment:
+ - GET_HOSTS_FROM=dns
+ frontend:
+ image: gcr.io/google-samples/gb-frontend:v4
+ ports:
+ - "80:80"
+ environment:
+ - GET_HOSTS_FROM=dns
+ labels:
+ kompose.service.type: LoadBalancer
+ ```
2. <!--Run the `kompose up` command to deploy to Kubernetes directly, or skip to
the next step instead to generate a file to use with `kubectl`.-->
运行 `kompose up` 命令直接部署到 Kubernetes，或者跳到下一步，生成 `kubectl` 使用的文件。
- ```bash
- $ kompose up
- We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application.
- If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead.
+ ```bash
+ $ kompose up
+ We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application.
+ If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead.
- INFO Successfully created Service: redis
- INFO Successfully created Service: web
- INFO Successfully created Deployment: redis
- INFO Successfully created Deployment: web
-
- Your application has been deployed to Kubernetes. You can run 'kubectl get deployment,svc,pods,pvc' for details.
- ```
+ INFO Successfully created Service: redis
+ INFO Successfully created Service: web
+ INFO Successfully created Deployment: redis
+ INFO Successfully created Deployment: web
+ Your application has been deployed to Kubernetes. You can run 'kubectl get deployment,svc,pods,pvc' for details.
+ ```
3. <!--To convert the `docker-compose.yml` file to files that you can use with
`kubectl`, run `kompose convert` and then `kubectl create -f <output file>`.-->
- 要将 `docker-compose.yml` 转换为 `kubectl` 可用的文件，请运行 `kompose convert` 命令进行转换，然后运行 `kubectl create -f <output file>` 进行创建。
+ 要将 `docker-compose.yml` 转换为 `kubectl` 可用的文件，请运行 `kompose convert` 命令进行转换，
+ 然后运行 `kubectl create -f <output file>` 进行创建。
- ```bash
- $ kompose convert
- INFO Kubernetes file "frontend-service.yaml" created
- INFO Kubernetes file "redis-master-service.yaml" created
- INFO Kubernetes file "redis-slave-service.yaml" created
- INFO Kubernetes file "frontend-deployment.yaml" created
- INFO Kubernetes file "redis-master-deployment.yaml" created
- INFO Kubernetes file "redis-slave-deployment.yaml" created
- ```
+ ```shell
+ kompose convert
+ ```
- ```bash
- $ kubectl create -f frontend-service.yaml,redis-master-service.yaml,redis-slave-service.yaml,frontend-deployment.yaml,redis-master-deployment.yaml,redis-slave-deployment.yaml
- service/frontend created
- service/redis-master created
- service/redis-slave created
- deployment.apps/frontend created
- deployment.apps/redis-master created
- deployment.apps/redis-slave created
- ```
-<!--
- Your deployments are running in Kubernetes.
--->
- 您部署的应用在 Kubernetes 中运行起来了。
+ ```
+ INFO Kubernetes file "frontend-service.yaml" created
+ INFO Kubernetes file "redis-master-service.yaml" created
+ INFO Kubernetes file "redis-slave-service.yaml" created
+ INFO Kubernetes file "frontend-deployment.yaml" created
+ INFO Kubernetes file "redis-master-deployment.yaml" created
+ INFO Kubernetes file "redis-slave-deployment.yaml" created
+ ```
+ ```shell
+ kubectl create -f frontend-service.yaml,redis-master-service.yaml,redis-slave-service.yaml,frontend-deployment.yaml,redis-master-deployment.yaml,redis-slave-deployment.yaml
+ ```
-4. <!--Access your application.-->访问您的应用。
+ ```
+ service/frontend created
+ service/redis-master created
+ service/redis-slave created
+ deployment.apps/frontend created
+ deployment.apps/redis-master created
+ deployment.apps/redis-slave created
+ ```
- <!--If you're already using `minikube` for your development process:-->
+ <!--
+ Your deployments are running in Kubernetes.
+ -->
+ 你部署的应用在 Kubernetes 中运行起来了。
- 如果您在开发过程中使用 `minikube`，请执行：
+4. <!--Access your application.-->
+ 访问你的应用
- ```bash
- $ minikube service frontend
- ```
+ <!--If you're already using `minikube` for your development process:-->
- <!--Otherwise, let's look up what IP your service is using!-->
- 否则，我们要查看一下您的服务使用了什么 IP！
+ 如果你在开发过程中使用 `minikube`，请执行：
- ```sh
- $ kubectl describe svc frontend
- Name: frontend
- Namespace: default
- Labels: service=frontend
- Selector: service=frontend
- Type: LoadBalancer
- IP: 10.0.0.183
- LoadBalancer Ingress: 192.0.2.89
- Port: 80 80/TCP
- NodePort: 80 31144/TCP
- Endpoints: 172.17.0.4:80
- Session Affinity: None
- No events.
+ ```shell
+ minikube service frontend
+ ```
- ```
+ <!--Otherwise, let's look up what IP your service is using!-->
+ 否则，我们要查看一下你的服务使用了什么 IP！
- <!--If you're using a cloud provider, your IP will be listed next to `LoadBalancer Ingress`.-->
- 如果您使用的是云提供商，您的 IP 将在 `LoadBalancer Ingress` 字段给出。
+ ```shell
+ kubectl describe svc frontend
+ ```
- ```sh
- $ curl http://192.0.2.89
- ```
+ ```
+ Name: frontend
+ Namespace: default
+ Labels: service=frontend
+ Selector: service=frontend
+ Type: LoadBalancer
+ IP: 10.0.0.183
+ LoadBalancer Ingress: 192.0.2.89
+ Port: 80 80/TCP
+ NodePort: 80 31144/TCP
+ Endpoints: 172.17.0.4:80
+ Session Affinity: None
+ No events.
+ ```
+ <!--If you're using a cloud provider, your IP will be listed next to `LoadBalancer Ingress`.-->
+ 如果你使用的是云提供商，你的 IP 将在 `LoadBalancer Ingress` 字段给出。
+ ```shell
+ curl http://192.0.2.89
+ ```
<!-- discussion -->
<!--
## User Guide
-->
-
-## 用户指南
+## 用户指南 {#user-guide}
<!--
- CLI
@@ -294,11 +278,11 @@ you need is an existing `docker-compose.yml` file.
- [Restart](#restart)
- [Docker Compose Versions](#docker-compose-versions)
-->
-
- CLI
- [`kompose convert`](#kompose-convert)
- [`kompose up`](#kompose-up)
- [`kompose down`](#kompose-down)
+
- 文档
- [构建和推送 Docker 镜像](#构建和推送-docker-镜像)
- [其他转换方式](#其他转换方式)
@@ -310,9 +294,8 @@ you need is an existing `docker-compose.yml` file.
Kompose has support for two providers: OpenShift and Kubernetes.
You can choose a targeted provider using global option `--provider`. If no provider is specified, Kubernetes is set by default.
-->
-
Kompose 支持两种驱动：OpenShift 和 Kubernetes。
-您可以通过全局选项 `--provider` 选择驱动方式。如果没有指定，会将 Kubernetes 作为默认驱动。
+你可以通过全局选项 `--provider` 选择驱动方式。如果没有指定，会将 Kubernetes 作为默认驱动。
## `kompose convert`
@@ -320,8 +303,10 @@ Kompose 支持将 V1、V2 和 V3 版本的 Docker Compose 文件转换为 Kubern
### Kubernetes
-```sh
-$ kompose --file docker-voting.yml convert
+```shell
+kompose --file docker-voting.yml convert
+```
+```
WARN Unsupported key networks - ignoring
WARN Unsupported key build - ignoring
INFO Kubernetes file "worker-svc.yaml" created
@@ -334,8 +319,13 @@ INFO Kubernetes file "result-deployment.yaml" created
INFO Kubernetes file "vote-deployment.yaml" created
INFO Kubernetes file "worker-deployment.yaml" created
INFO Kubernetes file "db-deployment.yaml" created
+```
-$ ls
+```shell
+ls
+```
+
+```
db-deployment.yaml docker-compose.yml docker-gitlab.yml redis-deployment.yaml result-deployment.yaml vote-deployment.yaml worker-deployment.yaml
db-svc.yaml docker-voting.yml redis-svc.yaml result-svc.yaml vote-svc.yaml worker-svc.yaml
```
@@ -343,11 +333,12 @@ db-svc.yaml docker-voting.yml redis-svc.yaml result-svc.yam
<!--
You can also provide multiple docker-compose files at the same time:
-->
+你也可以同时提供多个 docker-compose 文件进行转换：
-您也可以同时提供多个 docker-compose 文件进行转换：
-
-```sh
-$ kompose -f docker-compose.yml -f docker-guestbook.yml convert
+```shell
+kompose -f docker-compose.yml -f docker-guestbook.yml convert
+```
+```
INFO Kubernetes file "frontend-service.yaml" created
INFO Kubernetes file "mlbparks-service.yaml" created
INFO Kubernetes file "mongodb-service.yaml" created
@@ -359,8 +350,13 @@ INFO Kubernetes file "mongodb-deployment.yaml" created
INFO Kubernetes file "mongodb-claim0-persistentvolumeclaim.yaml" created
INFO Kubernetes file "redis-master-deployment.yaml" created
INFO Kubernetes file "redis-slave-deployment.yaml" created
+```
-$ ls
+```shell
+ls
+```
+
+```
mlbparks-deployment.yaml mongodb-service.yaml redis-slave-service.jsonmlbparks-service.yaml
frontend-deployment.yaml mongodb-claim0-persistentvolumeclaim.yaml redis-master-service.yaml
frontend-service.yaml mongodb-deployment.yaml redis-slave-deployment.yaml
@@ -370,13 +366,15 @@ redis-master-deployment.yaml
<!--
When multiple docker-compose files are provided the configuration is merged. Any configuration that is common will be over ridden by subsequent file.
-->
-
当提供多个 docker-compose 文件时，配置将会合并。任何通用的配置都将被后续文件覆盖。
### OpenShift
-```sh
-$ kompose --provider openshift --file docker-voting.yml convert
+```shell
+kompose --provider openshift --file docker-voting.yml convert
+```
+
+```
WARN [worker] Service cannot be created because of missing port.
INFO OpenShift file "vote-service.yaml" created
INFO OpenShift file "db-service.yaml" created
@@ -397,13 +395,15 @@ INFO OpenShift file "result-imagestream.yaml" created
<!--
It also supports creating buildconfig for build directive in a service. By default, it uses the remote repo for the current git branch as the source repo, and the current branch as the source branch for the build. You can specify a different source repo and branch using ``--build-repo`` and ``--build-branch`` options respectively.
-->
-
kompose 还支持为服务中的构建指令创建 buildconfig。
默认情况下，它使用当前 git 分支的 remote 仓库作为源仓库，使用当前分支作为构建的源分支。
-您可以分别使用 ``--build-repo`` 和 ``--build-branch`` 选项指定不同的源仓库和分支。
+你可以分别使用 ``--build-repo`` 和 ``--build-branch`` 选项指定不同的源仓库和分支。
-```sh
-$ kompose --provider openshift --file buildconfig/docker-compose.yml convert
+```shell
+kompose --provider openshift --file buildconfig/docker-compose.yml convert
+```
+
+```
WARN [foo] Service cannot be created because of missing port.
INFO OpenShift Buildconfig using git@github.com:rtnpro/kompose.git::master as source.
INFO OpenShift file "foo-deploymentconfig.yaml" created
@@ -411,12 +411,12 @@ INFO OpenShift file "foo-imagestream.yaml" created
INFO OpenShift file "foo-buildconfig.yaml" created
```
-{{< note >}}
<!--
If you are manually pushing the Openshift artifacts using ``oc create -f``, you need to ensure that you push the imagestream artifact before the buildconfig artifact, to workaround this Openshift issue: https://github.com/openshift/origin/issues/4518 .
-->
-
-如果使用 ``oc create -f`` 手动推送 Openshift 工件，则需要确保在构建配置工件之前推送 imagestream 工件，以解决 Openshift 的这个问题：https://github.com/openshift/origin/issues/4518 。
+{{< note >}}
+如果使用 ``oc create -f`` 手动推送 Openshift 工件，则需要确保在构建配置工件之前推送
+imagestream 工件，以解决 Openshift 的这个问题：https://github.com/openshift/origin/issues/4518 。
{{< /note >}}
## `kompose up`
@@ -424,13 +424,15 @@ If you are manually pushing the Openshift artifacts using ``oc create -f``, you
<!--
Kompose supports a straightforward way to deploy your "composed" application to Kubernetes or OpenShift via `kompose up`.
-->
-
-Kompose 支持通过 `kompose up` 直接将您的"复合的（composed）" 应用程序部署到 Kubernetes 或 OpenShift。
+Kompose 支持通过 `kompose up` 直接将你的"复合的（composed）" 应用程序部署到 Kubernetes 或 OpenShift。
### Kubernetes
-```sh
-$ kompose --file ./examples/docker-guestbook.yml up
+```shell
+kompose --file ./examples/docker-guestbook.yml up
+```
+
+```
We are going to create Kubernetes deployments and services for your Dockerized application.
If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead.
@@ -442,8 +444,13 @@ INFO Successfully created deployment: redis-slave
INFO Successfully created deployment: frontend
Your application has been deployed to Kubernetes. You can run 'kubectl get deployment,svc,pods' for details.
+```
-$ kubectl get deployment,svc,pods
+```shell
+kubectl get deployment,svc,pods
+```
+
+```
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deployment.extensions/frontend 1 1 1 1 4m
deployment.extensions/redis-master 1 1 1 1 4m
@@ -469,13 +476,18 @@ pod/redis-slave-2504961300-nve7b 1/1 Running 0 4m
**注意**：
-- 您必须有一个运行正常的 Kubernetes 集群，该集群具有预先配置的 kubectl 上下文。
-- 此操作仅生成 Deployment 和 Service 对象并将其部署到 Kubernetes。如果需要部署其他不同类型的资源，请使用 `kompose convert` 和 `kubectl create -f` 命令。
+- 你必须有一个运行正常的 Kubernetes 集群，该集群具有预先配置的 kubectl 上下文。
+- 此操作仅生成 Deployment 和 Service 对象并将其部署到 Kubernetes。
+ 如果需要部署其他不同类型的资源，请使用 `kompose convert` 和 `kubectl create -f` 命令。
### OpenShift
-```sh
-$ kompose --file ./examples/docker-guestbook.yml --provider openshift up
+
+```shell
+kompose --file ./examples/docker-guestbook.yml --provider openshift up
+```
+
+```
We are going to create OpenShift DeploymentConfigs and Services for your Dockerized application.
If you need different kind of resources, use the 'kompose convert' and 'oc create -f' commands instead.
@@ -490,8 +502,13 @@ INFO Successfully created deployment: redis-master
INFO Successfully created ImageStream: redis-master
Your application has been deployed to OpenShift. You can run 'oc get dc,svc,is' for details.
+```
-$ oc get dc,svc,is
+```shell
+oc get dc,svc,is
+```
+
+```
NAME REVISION DESIRED CURRENT TRIGGERED BY
dc/frontend 0 1 0 config,image(frontend:v4)
dc/redis-master 0 1 0 config,image(redis-master:e2e)
@@ -510,10 +527,9 @@ is/redis-slave 172.30.12.200:5000/fff/redis-slave v1
**Note**:
- You must have a running OpenShift cluster with a pre-configured `oc` context (`oc login`)
-->
-
**注意**：
-- 您必须有一个运行正常的 OpenShift 集群，该集群具有预先配置的 `oc` 上下文 (`oc login`)。
+- 你必须有一个运行正常的 OpenShift 集群，该集群具有预先配置的 `oc` 上下文 (`oc login`)。
## `kompose down`
@@ -521,10 +537,15 @@ is/redis-slave 172.30.12.200:5000/fff/redis-slave v1
Once you have deployed "composed" application to Kubernetes, `$ kompose down` will help you to take the application out by deleting its deployments and services. If you need to remove other resources, use the 'kubectl' command.
-->
-您一旦将"复合(composed)" 应用部署到 Kubernetes，`$ kompose down` 命令将能帮您通过删除 Deployment 和 Service 对象来删除应用。如果需要删除其他资源，请使用 'kubectl' 命令。
+你一旦将"复合(composed)" 应用部署到 Kubernetes，`kompose down`
+命令将能帮你通过删除 Deployment 和 Service 对象来删除应用。
+如果需要删除其他资源，请使用 'kubectl' 命令。
-```sh
-$ kompose --file docker-guestbook.yml down
+```shell
+kompose --file docker-guestbook.yml down
+```
+
+```
INFO Successfully deleted service: redis-master
INFO Successfully deleted deployment: redis-master
INFO Successfully deleted service: redis-slave
@@ -535,8 +556,11 @@ INFO Successfully deleted deployment: frontend
<!--
**Note**:
+
- You must have a running Kubernetes cluster with a pre-configured kubectl context.
+
## Build and Push Docker Images
+
Kompose supports both building and pushing Docker images. When using the `build` key within your Docker Compose file, your image will:
- Automatically be built with Docker using the `image` key specified within your file
- Be pushed to the correct Docker repository using local credentials (located at `.docker/config`)
@@ -545,14 +569,14 @@ Using an [example Docker Compose file](https://raw.githubusercontent.com/kuberne
**注意**：
-- 您必须有一个运行正常的 Kubernetes 集群，该集群具有预先配置的 kubectl 上下文。
+- 你必须有一个运行正常的 Kubernetes 集群，该集群具有预先配置的 kubectl 上下文。
## 构建和推送 Docker 镜像
-Kompose 支持构建和推送 Docker 镜像。如果 Docker Compose 文件中使用了 `build` 关键字，您的镜像将会：
+Kompose 支持构建和推送 Docker 镜像。如果 Docker Compose 文件中使用了 `build` 关键字，你的镜像将会：
- - 使用文档中指定的 `image` 键自动构建 Docker 镜像
- - 使用本地凭据推送到正确的 Docker 仓库
+- 使用文档中指定的 `image` 键自动构建 Docker 镜像
+- 使用本地凭据推送到正确的 Docker 仓库
使用 [Docker Compose 文件示例](https://raw.githubusercontent.com/kubernetes/kompose/master/examples/buildconfig/docker-compose.yml)
@@ -568,11 +592,13 @@ services:
<!--
Using `kompose up` with a `build` key:
-->
-
使用带有 `build` 键的 `kompose up` 命令：
-```none
-$ kompose up
+```shell
+kompose up
+```
+
+```
INFO Build key detected. Attempting to build and push image 'docker.io/foo/bar'
INFO Building image 'docker.io/foo/bar' from directory 'build'
INFO Image 'docker.io/foo/bar' from directory 'build' built successfully
@@ -591,30 +617,36 @@ Your application has been deployed to Kubernetes. You can run 'kubectl get deplo
<!--
In order to disable the functionality, or choose to use BuildConfig generation (with OpenShift) `--build (local|build-config|none)` can be passed.
-->
+要想禁用该功能，或者使用 BuildConfig 中的版本（在 OpenShift 中），
+可以通过传递 `--build (local|build-config|none)` 参数来实现。
-要想禁用该功能，或者使用 BuildConfig 中的版本（在 OpenShift 中），可以通过传递 `--build (local|build-config|none)` 参数来实现。
-
-```sh
+```shell
# Disable building/pushing Docker images
-$ kompose up --build none
+kompose up --build none
# Generate Build Config artifacts for OpenShift
-$ kompose up --provider openshift --build build-config
+kompose up --provider openshift --build build-config
```
<!--
## Alternative Conversions
+
The default `kompose` transformation will generate Kubernetes [Deployments](/docs/concepts/workloads/controllers/deployment/) and [Services](/docs/concepts/services-networking/service/), in yaml format. You have alternative option to generate json with `-j`. Also, you can alternatively generate [Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/) objects, [Daemon Sets](/docs/concepts/workloads/controllers/daemonset/), or [Helm](https://github.com/helm/helm) charts.
-->
-
## 其他转换方式
-默认的 `kompose` 转换会生成 yaml 格式的 Kubernetes [Deployment](/docs/concepts/workloads/controllers/deployment/) 和 [Service](/docs/concepts/services-networking/service/) 对象。
-您可以选择通过 `-j` 参数生成 json 格式的对象。
-您也可以替换生成 [Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/) 对象、[Daemon Sets](/docs/concepts/workloads/controllers/daemonset/) 或 [Helm](https://github.com/helm/helm) charts。
+默认的 `kompose` 转换会生成 yaml 格式的 Kubernetes
+[Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 和
+[Service](/zh/docs/concepts/services-networking/service/) 对象。
+你可以选择通过 `-j` 参数生成 json 格式的对象。
+你也可以替换生成 [Replication Controllers](/zh/docs/concepts/workloads/controllers/replicationcontroller/) 对象、
+[Daemon Sets](/zh/docs/concepts/workloads/controllers/daemonset/) 或
+[Helm](https://github.com/helm/helm) charts。
-```sh
-$ kompose convert -j
+```shell
+kompose convert -j
+```
+```
INFO Kubernetes file "redis-svc.json" created
INFO Kubernetes file "web-svc.json" created
INFO Kubernetes file "redis-deployment.json" created
@@ -624,11 +656,12 @@ INFO Kubernetes file "web-deployment.json" created
<!--
The `*-deployment.json` files contain the Deployment objects.
-->
-
`*-deployment.json` 文件中包含 Deployment 对象。
-```sh
-$ kompose convert --replication-controller
+```shell
+kompose convert --replication-controller
+```
+```
INFO Kubernetes file "redis-svc.yaml" created
INFO Kubernetes file "web-svc.yaml" created
INFO Kubernetes file "redis-replicationcontroller.yaml" created
@@ -639,10 +672,15 @@ INFO Kubernetes file "web-replicationcontroller.yaml" created
The `*-replicationcontroller.yaml` files contain the Replication Controller objects. If you want to specify replicas (default is 1), use `--replicas` flag: `$ kompose convert --replication-controller --replicas 3`
-->
-`*-replicationcontroller.yaml` 文件包含 Replication Controller 对象。如果您想指定副本数（默认为 1），可以使用 `--replicas` 参数：`$ kompose convert --replication-controller --replicas 3`
+`*-replicationcontroller.yaml` 文件包含 Replication Controller 对象。
+如果你想指定副本数（默认为 1），可以使用 `--replicas` 参数：
+`kompose convert --replication-controller --replicas 3`
-```sh
-$ kompose convert --daemon-set
+```shell
+kompose convert --daemon-set
+```
+
+```
INFO Kubernetes file "redis-svc.yaml" created
INFO Kubernetes file "web-svc.yaml" created
INFO Kubernetes file "redis-daemonset.yaml" created
@@ -653,20 +691,26 @@ INFO Kubernetes file "web-daemonset.yaml" created
The `*-daemonset.yaml` files contain the Daemon Set objects
If you want to generate a Chart to be used with [Helm](https://github.com/kubernetes/helm) simply do:
-->
-
`*-daemonset.yaml` 文件包含 Daemon Set 对象。
-如果您想生成 [Helm](https://github.com/kubernetes/helm) 可用的 Chart，只需简单的执行下面的命令：
+如果你想生成 [Helm](https://github.com/kubernetes/helm) 可用的 Chart，只需简单的执行下面的命令：
-```sh
-$ kompose convert -c
+```shell
+kompose convert -c
+```
+```
INFO Kubernetes file "web-svc.yaml" created
INFO Kubernetes file "redis-svc.yaml" created
INFO Kubernetes file "web-deployment.yaml" created
INFO Kubernetes file "redis-deployment.yaml" created
chart created in "./docker-compose/"
+```
-$ tree docker-compose/
+```shell
+tree docker-compose/
+```
+
+```
docker-compose
├── Chart.yaml
├── README.md
@@ -679,35 +723,36 @@ docker-compose
<!--
The chart structure is aimed at providing a skeleton for building your Helm charts.
+-->
+这个 Chart 结构旨在为构建 Helm Chart 提供框架。
+
+<!--
## Labels
+
`kompose` supports Kompose-specific labels within the `docker-compose.yml` file in order to explicitly define a service's behavior upon conversion.
- `kompose.service.type` defines the type of service to be created.
+
For example:
-->
-
-这个图标结构旨在为构建 Helm Chart 提供框架。
-
## 标签
`kompose` 支持 `docker-compose.yml` 文件中用于 Kompose 的标签，以便在转换时明确定义 Service 的行为。
-- `kompose.service.type` 定义要创建的 Service 类型。
+- `kompose.service.type` 定义要创建的 Service 类型。例如：
-
-
-```yaml
-version: "2"
-services:
- nginx:
- image: nginx
- dockerfile: foobar
- build: ./foobar
- cap_add:
- - ALL
- container_name: foobar
- labels:
- kompose.service.type: nodeport
-```
+ ```yaml
+ version: "2"
+ services:
+ nginx:
+ image: nginx
+ dockerfile: foobar
+ build: ./foobar
+ cap_add:
+ - ALL
+ container_name: foobar
+ labels:
+ kompose.service.type: nodeport
+ ```
<!--
- `kompose.service.expose` defines if the service needs to be made accessible from outside the cluster or not. If the value is set to "true", the provider sets the endpoint automatically, and for any other value, the value is set as the hostname. If multiple ports are defined in a service, the first one is chosen to be the exposed.
@@ -715,29 +760,31 @@ services:
- For the OpenShift provider, a route is created.
For example:
-->
+- `kompose.service.expose` 定义是否允许从集群外部访问 Service。
+ 如果该值被设置为 "true"，提供程序将自动设置端点，对于任何其他值，该值将被设置为主机名。
+ 如果在 Service 中定义了多个端口，则选择第一个端口作为公开端口。
-- `kompose.service.expose` 定义 是否允许从集群外部访问 Service。如果该值被设置为 "true"，提供程序将自动设置端点，对于任何其他值，该值将被设置为主机名。如果在 Service 中定义了多个端口，则选择第一个端口作为公开端口。
- 对于 Kubernetes 驱动程序，创建了一个 Ingress 资源，并且假定已经配置了相应的 Ingress 控制器。
- 对于 OpenShift 驱动程序, 创建一个 route。
-例如：
+ 例如：
-```yaml
-version: "2"
-services:
- web:
- image: tuna/docker-counter23
- ports:
- - "5000:5000"
- links:
- - redis
- labels:
- kompose.service.expose: "counter.example.com"
- redis:
- image: redis:3.0
- ports:
- - "6379"
-```
+ ```yaml
+ version: "2"
+ services:
+ web:
+ image: tuna/docker-counter23
+ ports:
+ - "5000:5000"
+ links:
+ - redis
+ labels:
+ kompose.service.expose: "counter.example.com"
+ redis:
+ image: redis:3.0
+ ports:
+ - "6379"
+ ```
<!--
The currently supported options are:
@@ -749,27 +796,27 @@ The currently supported options are:
当前支持的选项有:
-| 键 | 值 |
+| 键 | 值 |
|----------------------|-------------------------------------|
| kompose.service.type | nodeport / clusterip / loadbalancer |
| kompose.service.expose| true / hostname |
-
-{{< note >}}
<!--
The `kompose.service.type` label should be defined with `ports` only, otherwise `kompose` will fail.
-->
+{{< note >}}
`kompose.service.type` 标签应该只用`ports`来定义，否则 `kompose` 会失败。
{{< /note >}}
<!--
## Restart
+
If you want to create normal pods without controllers you can use `restart` construct of docker-compose to define that. Follow table below to see what happens on the `restart` value.
-->
-
## 重启
-如果你想创建没有控制器的普通 Pod，可以使用 docker-compose 的 `restart` 结构来定义它。请参考下表了解 `restart` 的不同参数。
+如果你想创建没有控制器的普通 Pod，可以使用 docker-compose 的 `restart` 结构来定义它。
+请参考下表了解 `restart` 的不同参数。
<!--
| `docker-compose` `restart` | object created | Pod `restartPolicy` |
@@ -788,18 +835,16 @@ If you want to create normal pods without controllers you can use `restart` cons
| `no` | Pod | `Never` |
-
-{{< note >}}
<!--
The controller object could be `deployment` or `replicationcontroller`, etc.
-->
+{{< note >}}
控制器对象可以是 `deployment` 或 `replicationcontroller` 等。
{{< /note >}}
<!--
For e.g. `pival` service will become pod down here. This container calculated value of `pi`.
-->
-
例如，`pival` Service 将在这里变成 Pod。这个容器的计算值为 `pi`。
```yaml
@@ -814,32 +859,36 @@ services:
<!--
### Warning about Deployment Config's
+
If the Docker Compose file has a volume specified for a service, the Deployment (Kubernetes) or DeploymentConfig (OpenShift) strategy is changed to "Recreate" instead of "RollingUpdate" (default). This is done to avoid multiple instances of a service from accessing a volume at the same time.
-->
### 关于 Deployment Config 的提醒
-如果 Docker Compose 文件中为服务声明了卷，Deployment (Kubernetes) 或 DeploymentConfig (OpenShift) 的策略会从 "RollingUpdate" (默认) 变为 "Recreate"。
+如果 Docker Compose 文件中为服务声明了卷，Deployment (Kubernetes) 或 DeploymentConfig (OpenShift)
+的策略会从 "RollingUpdate" (默认) 变为 "Recreate"。
这样做的目的是为了避免服务的多个实例同时访问卷。
<!--
If the Docker Compose file has service name with `_` in it (eg.`web_service`), then it will be replaced by `-` and the service name will be renamed accordingly (eg.`web-service`). Kompose does this because "Kubernetes" doesn't allow `_` in object name.
Please note that changing service name might break some `docker-compose` files.
-->
-
-如果 Docker Compose 文件中的服务名包含 `_` (例如 `web_service`)，那么将会被替换为 `-`，服务也相应的会重命名(例如 `web-service`)。
+如果 Docker Compose 文件中的服务名包含 `_` (例如 `web_service`)，
+那么将会被替换为 `-`，服务也相应的会重命名(例如 `web-service`)。
Kompose 这样做的原因是 "Kubernetes" 不允许对象名称中包含 `_`。
<!--
## Docker Compose Versions
+
Kompose supports Docker Compose versions: 1, 2 and 3. We have limited support on versions 2.1 and 3.2 due to their experimental nature.
A full list on compatibility between all three versions is listed in our [conversion document](https://github.com/kubernetes/kompose/blob/master/docs/conversion.md) including a list of all incompatible Docker Compose keys.
-->
-
## Docker Compose 版本
Kompose 支持的 Docker Compose 版本包括：1、2 和 3。有限支持 2.1 和 3.2 版本，因为它们还在实验阶段。
-所有三个版本的兼容性列表请查看我们的 [转换文档](https://github.com/kubernetes/kompose/blob/master/docs/conversion.md)，文档中列出了所有不兼容的 Docker Compose 关键字。
+所有三个版本的兼容性列表请查看我们的
+[转换文档](https://github.com/kubernetes/kompose/blob/master/docs/conversion.md)，
+文档中列出了所有不兼容的 Docker Compose 关键字。
diff --git a/content/zh/docs/tasks/debug-application-cluster/audit.md b/content/zh/docs/tasks/debug-application-cluster/audit.md
index 594ba79b27..274bee2ed4 100644
--- a/content/zh/docs/tasks/debug-application-cluster/audit.md
+++ b/content/zh/docs/tasks/debug-application-cluster/audit.md
@@ -1,12 +1,15 @@
---
+title: 审计
+content_type: concept
+---
+<!--
reviewers:
- soltysh
- sttts
- ericchiang
content_type: concept
title: Auditing
----
-
+-->
<!-- overview -->
{{< feature-state state="beta" >}}
@@ -17,7 +20,8 @@ the sequence of activities that have affected system by individual users, admini
or other components of the system. It allows cluster administrator to
answer the following questions:
-->
-Kubernetes 审计功能提供了与安全相关的按时间顺序排列的记录集，记录单个用户、管理员或系统其他组件影响系统的活动顺序。
+Kubernetes 审计功能提供了与安全相关的按时间顺序排列的记录集，记录每个用户、管理员
+或系统其他组件影响系统的活动顺序。
它能帮助集群管理员处理以下问题：
<!--
@@ -37,22 +41,19 @@ Kubernetes 审计功能提供了与安全相关的按时间顺序排列的记录
- 它从哪触发的？
- 活动的后续处理行为是什么？
-
-
-{{< toc >}}
-
<!-- body -->
<!--
-[Kube-apiserver][kube-apiserver] performs auditing. Each request on each stage
+[Kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
+performs auditing. Each request on each stage
of its execution generates an event, which is then pre-processed according to
a certain policy and written to a backend. The policy determines what's recorded
and the backends persist the records. The current backend implementations
include logs files and webhooks.
-->
-[Kube-apiserver][kube-apiserver] 执行审计。每个执行阶段的每个请求都会生成一个事件，然后根据特定策略对事件进行预处理并写入后端。
-您可以在 [设计方案][auditing-proposal] 中找到更多详细信息。
-该策略确定记录的内容并且在后端存储记录。当前的后端支持日志文件和 webhook。
+[kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)
+执行审计。每个执行阶段的每个请求都会生成一个事件，然后根据特定策略对事件进行预处理并写入后端。
+该策略确定要记录的内容和用来存储记录的后端。当前的后端支持日志文件和 webhook。
<!--
Each request can be recorded with an associated "stage". The known stages are:
@@ -67,23 +68,21 @@ Each request can be recorded with an associated "stage". The known stages are:
will be sent.
- `Panic` - Events generated when a panic occurred.
-->
-
每个请求都可以用相关的 "stage" 记录。已知的 stage 有：
- `RequestReceived` - 事件的 stage 将在审计处理器接收到请求后，并且在委托给其余处理器之前生成。
-
-- `ResponseStarted` - 在响应消息的头部发送后，但是响应消息体发送前。这个 stage 仅为长时间运行的请求生成（例如 watch）。
-
+- `ResponseStarted` - 在响应消息的头部发送后，但是响应消息体发送前。
+ 这个阶段仅为长时间运行的请求生成（例如 watch）。
- `ResponseComplete` - 当响应消息体完成并且没有更多数据需要传输的时候。
- `Panic` - 当 panic 发生时生成。
-{{< note >}}
<!--
The audit logging feature increases the memory consumption of the API
server because some context required for auditing is stored for each request.
Additionally, memory consumption depends on the audit logging configuration.
-->
-**注意** 审计日志记录功能会增加 API server 的内存消耗，因为需要为每个请求存储审计所需的某些上下文。
+{{< note >}}
+审计日志记录功能会增加 API server 的内存消耗，因为需要为每个请求存储审计所需的某些上下文。
此外，内存消耗取决于审计日志记录的配置。
{{< /note >}}
@@ -96,10 +95,13 @@ they should include. The audit policy object structure is defined in the
compared against the list of rules in order. The first matching rule sets the
"audit level" of the event. The known audit levels are:
-->
-## 审计策略
+## 审计策略 {#audit-policy}
-审计政策定义了关于应记录哪些事件以及应包含哪些数据的规则。审计策略对象结构在 [`audit.k8s.io` API 组][auditing-api] 中定义。
-处理事件时，将按顺序与规则列表进行比较。第一个匹配规则设置事件的 [审计级别][auditing-level]。已知的审计级别有：
+审计政策定义了关于应记录哪些事件以及应包含哪些数据的规则。
+审计策略对象结构定义在
+[`audit.k8s.io` API 组](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go)
+处理事件时，将按顺序与规则列表进行比较。第一个匹配规则设置事件的
+"审计级别"。已知的审计级别有：
<!--
- `None` - don't log events that match this rule.
@@ -111,9 +113,11 @@ compared against the list of rules in order. The first matching rule sets the
This does not apply for non-resource requests.
-->
- `None` - 符合这条规则的日志将不会记录。
-- `Metadata` - 记录请求的 metadata（请求的用户、timestamp、resource、verb 等等），但是不记录请求或者响应的消息体。
-- `Request` - 记录事件的 metadata 和请求的消息体，但是不记录响应的消息体。这不适用于非资源类型的请求。
-- `RequestResponse` - 记录事件的 metadata，请求和响应的消息体。这不适用于非资源类型的请求。
+- `Metadata` - 记录请求的元数据（请求的用户、时间戳、资源、动词等等），
+ 但是不记录请求或者响应的消息体。
+- `Request` - 记录事件的元数据和请求的消息体，但是不记录响应的消息体。
+ 这不适用于非资源类型的请求。
+- `RequestResponse` - 记录事件的元数据，请求和响应的消息体。这不适用于非资源类型的请求。
<!--
You can pass a file with the policy to [kube-apiserver][kube-apiserver]
@@ -123,7 +127,8 @@ A policy with no (0) rules is treated as illegal.
Below is an example audit policy file:
-->
-您可以使用 `--audit-policy-file` 标志将包含策略的文件传递给 [kube-apiserver][kube-apiserver]。如果不设置该标志，则不记录事件。
+你可以使用 `--audit-policy-file` 标志将包含策略的文件传递给 `kube-apiserver`。
+如果不设置该标志，则不记录事件。
注意 `rules` 字段 __必须__ 在审计策略文件中提供。没有（0）规则的策略将被视为非法配置。
以下是一个审计策略文件的示例：
@@ -133,10 +138,10 @@ Below is an example audit policy file:
<!--
You can use a minimal audit policy file to log all requests at the `Metadata` level:
-->
-您可以使用最低限度的审计策略文件在 `Metadata` 级别记录所有请求：
+你可以使用最低限度的审计策略文件在 `Metadata` 级别记录所有请求：
```yaml
-# Log all requests at the Metadata level.
+# 在 Metadata 级别为所有请求生成日志
apiVersion: audit.k8s.io/v1beta1
kind: Policy
rules:
@@ -144,10 +149,14 @@ rules:
```
<!--
-The [audit profile used by GCE][gce-audit-profile] should be used as reference by
-admins constructing their own audit profiles.
+The audit profile used by GCE should be used as reference by admins constructing their own audit profiles. You can check the
+[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)
+script, which generates the audit policy file. You can see most of the audit policy file by looking directly at the script.
-->
-管理员构建自己的审计配置文件时，应使用 [GCE 使用的审计配置文件][gce-audit-profile] 作为参考。
+管理员构建自己的审计配置文件时，可参考
+[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)
+脚本，该脚本生成审计策略文件。你可以直接在脚本中看到审计策略的绝大部份内容。
+[]。
<!--
## Audit backends
@@ -160,26 +169,29 @@ Audit backends persist audit events to an external storage.
In both cases, audit events structure is defined by the API in the
`audit.k8s.io` API group. The current version of the API is
-[`v1beta1`][auditing-api].
+[`v1`](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go).
-->
-## 审计后端
+## 审计后端 {#audit-backends}
-审计后端实现将审计事件导出到外部存储。
-[Kube-apiserver][kube-apiserver] 提供两个后端：
+审计后端实现将审计事件导出到外部存储。 `Kube-apiserver` 提供两个后端：
- Log 后端，将事件写入到磁盘
- Webhook 后端，将事件发送到外部 API
-在这两种情况下，审计事件结构均由 `audit.k8s.io` API 组中的 API 定义。当前版本的 API 是 [`v1beta1`][auditing-api]。
+在这两种情况下，审计事件结构均由 `audit.k8s.io` API 组中的 API 定义。
+当前版本的 API 是
+[`v1`](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go).
-{{< note >}}
<!--
In case of patches, request body is a JSON array with patch operations, not a JSON object
with an appropriate Kubernetes API object. For example, the following request body is a valid patch
request to `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`.
-->
-**注意：** 在 patch 请求的情况下，请求的消息体需要是一个 JSON 串指定 patch 操作，而不是一个完整的 Kubernetes API 对象 JSON 串。
-例如，以下的示例是一个合法的 patch 请求消息体，该请求对应 `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`。
+{{< note >}}
+在 patch 请求的情况下，请求的消息体需要是一个 JSON 串指定 patch 操作，
+而不是一个完整的 Kubernetes API 对象 JSON 串。
+例如，以下的示例是一个合法的 patch 请求消息体，该请求对应
+`/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`。
```json
[
@@ -204,7 +216,8 @@ log audit backend using the following [kube-apiserver][kube-apiserver] flags:
-->
### Log 后端
-Log 后端将审计事件写入 JSON 格式的文件。您可以使用以下 [kube-apiserver][kube-apiserver] 标志配置 Log 审计后端：
+Log 后端将审计事件写入 JSON 格式的文件。你可以使用以下 `kube-apiserver` 标志配置
+Log 审计后端：
<!--
- `--audit-log-path` specifies the log file path that log backend uses to write
@@ -218,6 +231,50 @@ Log 后端将审计事件写入 JSON 格式的文件。您可以使用以下 [ku
- `--audit-log-maxbackup` 定义了要保留的审计日志文件的最大数量
- `--audit-log-maxsize` 定义审计日志文件的最大大小（兆字节）
+<!--
+In case kube-apiserver is configured as a Pod,remember to mount the hostPath to the location of the policy file and log file. For example,
+`
+--audit-policy-file=/etc/kubernetes/audit-policy.yaml
+--audit-log-path=/var/log/audit.log
+`
+then mount the volumes:
+-->
+如果 `kube-apiserver` 被配置为运行在 Pod 中，请记得将包含策略文件和日志文件的
+位置用 `hostPath` 挂载到 Pod 中。例如，
+
+```
+--audit-policy-file=/etc/kubernetes/audit-policy.yaml
+--audit-log-path=/var/log/audit.log
+```
+
+接下来挂载数据卷：
+
+```
+volumeMounts:
+ - mountPath: /etc/kubernetes/audit-policy.yaml
+ name: audit
+ readOnly: true
+ - mountPath: /var/log/audit.log
+ name: audit-log
+ readOnly: false
+```
+
+<!-- finally the hostPath: -->
+下面是 hostPath 卷本身。
+
+```
+- name: audit
+ hostPath:
+ path: /etc/kubernetes/audit-policy.yaml
+ type: File
+
+- name: audit-log
+ hostPath:
+ path: /var/log/audit.log
+ type: FileOrCreate
+
+```
+
<!--
### Webhook backend
@@ -225,10 +282,10 @@ Webhook backend sends audit events to a remote API, which is assumed to be the
same API as [kube-apiserver][kube-apiserver] exposes. You can configure webhook
audit backend using the following kube-apiserver flags:
-->
-### Webhook 后端
+### Webhook 后端 {#webhook-backend}
-Webhook 后端将审计事件发送到远程 API，该远程 API 应该暴露与 [kube-apiserver][kube-apiserver] 相同的API。
-您可以使用如下 kube-apiserver 标志来配置 webhook 审计后端：
+Webhook 后端将审计事件发送到远程 API，该远程 API 应该暴露与 `kube-apiserver` 相同的API。
+你可以使用如下 kube-apiserver 标志来配置 webhook 审计后端：
<!--
- `--audit-webhook-config-file` specifies the path to a file with a webhook
@@ -239,14 +296,15 @@ Webhook 后端将审计事件发送到远程 API，该远程 API 应该暴露与
The webhook config file uses the kubeconfig format to specify the remote address of
the service and credentials used to connect to it.
-->
-- `--audit-webhook-config-file` webhook 配置文件的路径。Webhook 配置文件实际上是一个 [kubeconfig][kubeconfig]。
+- `--audit-webhook-config-file` webhook 配置文件的路径。Webhook 配置文件实际上是一个
+ [kubeconfig 文件](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
- `--audit-webhook-initial-backoff` 指定在第一次失败后重发请求等待的时间。随后的请求将以指数退避重试。
webhook 配置文件使用 kubeconfig 格式指定服务的远程地址和用于连接它的凭据。
+<!--
### Batching
-<!--
Both log and webhook backends support batching. Using webhook as an example, here's the list of
available flags. To get the same flag for log backend, replace `webhook` with `log` in the flag
name. By default, batching is enabled in `webhook` and disabled in `log`. Similarly, by default
@@ -255,14 +313,20 @@ throttling is enabled in `webhook` and disabled in `log`.
- `--audit-webhook-mode` defines the buffering strategy. One of the following:
- `batch` - buffer events and asynchronously process them in batches. This is the default.
- `blocking` - block API server responses on processing each individual event.
+ - `blocking-strict` - Same as blocking, but when there is a failure during audit logging at RequestReceived stage, the whole request to apiserver will fail.
-->
+### 批处理 {#batching}
-log 和 webhook 后端都支持 batch。以 webhook 为例，以下是可用参数列表。要获取 log 后端的同样参数，请在参数名称中将 `webhook` 替换为 `log`。
-默认情况下，在 `webhook` 中启用 batch，在 `log` 中禁用 batch。同样，默认情况下，在 `webhook` 中启用限制，在 `log` 中禁用限制。
+log 和 webhook 后端都支持批处理。以 webhook 为例，以下是可用参数列表。要获取 log 后端的同样参数，
+请在参数名称中将 `webhook` 替换为 `log`。
+默认情况下，在 `webhook` 中启用批处理，在 `log` 中禁用批处理。
+同样，默认情况下，在 `webhook` 中启用带宽限制，在 `log` 中禁用带宽限制。
- `--audit-webhook-mode` 定义缓存策略，可选值如下：
- `batch` - 以批处理缓存事件和异步的过程。这是默认值。
- - `blocking` - 阻止 API server 处理每个单独事件的响应。
+ - `blocking` - 在 API 服务器处理每个单独事件时，阻塞其响应。
+ - `blocking-strict` - 与 `blocking` 相同，不过当审计日志在 RequestReceived 阶段
+ 失败时，整个 API 服务请求会失效。
<!--
The following flags are used only in the `batch` mode.
@@ -283,7 +347,7 @@ The following flags are used only in the `batch` mode.
如果传入事件的速率溢出缓存区，则会丢弃事件。
- `--audit-webhook-batch-max-size` 定义一个 batch 中的最大事件数。
- `--audit-webhook-batch-max-wait` 无条件 batch 队列中的事件前等待的最大事件。
-- `--audit-webhook-batch-throttle-qps` 每秒生成的最大 batch 平均值。
+- `--audit-webhook-batch-throttle-qps` 每秒生成的最大批次数。
- `--audit-webhook-batch-throttle-burst` 在达到允许的 QPS 前，同一时刻允许存在的最大 batch 生成数。
<!--
@@ -305,7 +369,7 @@ you should set throttling level at least 2 QPS. Assuming that the backend can ta
例如，如果 kube-apiserver 每秒收到 100 个请求，并且每个请求仅在 `ResponseStarted` 和 `ResponseComplete` 阶段进行审计，则应该考虑每秒生成约 200 个审计事件。
假设批处理中最多有 100 个事件，则应将限制级别设置为至少 2 个 QPS。
-假设后端最多需要 5 秒钟来写入事件，您应该设置缓冲区大小以容纳最多 5 秒的事件，即 10 个 batch，即 1000 个事件。
+假设后端最多需要 5 秒钟来写入事件，你应该设置缓冲区大小以容纳最多 5 秒的事件，即 10 个 batch，即 1000 个事件。
<!--
In most cases however, the default parameters should be sufficient and you don't have to worry about
@@ -316,13 +380,14 @@ and in the logs to monitor the state of the auditing subsystem.
- `apiserver_audit_error_total` metric contains the total number of events dropped due to an error
during exporting.
-->
-但是，在大多数情况下，默认参数应该足够了，您不必手动设置它们。您可以查看 kube-apiserver 公开的以下 Prometheus 指标，并在日志中监控审计子系统的状态。
+但是，在大多数情况下，默认参数应该足够了，你不必手动设置它们。
+你可以查看 kube-apiserver 公开的以下 Prometheus 指标，并在日志中监控审计子系统的状态。
- `apiserver_audit_event_total` 包含所有暴露的审计事件数量的指标。
- `apiserver_audit_error_total` 在暴露时由于发生错误而被丢弃的事件的数量。
<!--
-## Multi-cluster setup
+## Setup for multiple API servers
If you're extending the Kubernetes API with the [aggregation layer][kube-aggregator], you can also
set up audit logging for the aggregated apiserver. To do this, pass the configuration options in the
@@ -330,67 +395,85 @@ same format as described above to the aggregated apiserver and set up the log in
to pick up audit logs. Different apiservers can have different audit configurations and different
audit policies.
-->
-## 多集群配置
+## 多 API 服务器的配置
-如果您通过 [aggregation layer][kube-aggregator] 对 Kubernetes API 进行扩展，那么您也可以为聚合的 apiserver 设置审计日志。
-想要这么做，您需要以上述的格式给聚合的 apiserver 配置参数，并且配置日志管道以采用审计日志。不同的 apiserver 可以配置不同的审计配置和策略。
+如果你通过[聚合层](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+对 Kubernetes API 进行扩展，那么你也可以为聚合的 API 服务器设置审计日志。
+想要这么做，你需要以上述的格式给聚合的 API 服务器配置参数，并且配置日志管道以采用审计日志。
+不同的 API 服务器可以配置不同的审计配置和策略。
<!--
## Log Collector Examples
### Use fluentd to collect and distribute audit events from log file
-[Fluentd][fluentd] is an open source data collector for unified logging layer.
+[Fluentd](http://www.fluentd.org/) is an open source data collector for unified logging layer.
In this example, we will use fluentd to split audit events by different namespaces.
-
-1. install [fluentd, fluent-plugin-forest and fluent-plugin-rewrite-tag-filter][fluentd_install_doc] in the kube-apiserver node
-1. create a config file for fluentd
-->
-## 日志选择器示例
+## 日志收集器示例
### 使用 fluentd 从日志文件中选择并且分发审计日志
-[Fluentd][fluentd] 是一个开源的数据采集器，可以从统一的日志层中采集。
+[Fluentd](https://www.fluentd.org/) 是一个开源的数据采集器，可以从统一的日志层中采集。
在以下示例中，我们将使用 fluentd 来按照命名空间划分审计事件。
-1. 在 kube-apiserver node 节点上安装 [fluentd, fluent-plugin-forest and fluent-plugin-rewrite-tag-filter][fluentd_install_doc]
+<!--
+The `fluent-plugin-forest` and `fluent-plugin-rewrite-tag-filter` are plugins for fluentd.
+You can get details about plugin installation from
+[fluentd plugin-management](https://docs.fluentd.org/v1.0/articles/plugin-management).
+-->
+{{< note >}}
+`fluent-plugin-forest` 和 `fluent-plugin-rewrite-tag-filter` fluentd 的插件。
+你可以在 [fluentd plugin-management](https://docs.fluentd.org/v1.0/articles/plugin-management)
+了解安装插件相关的细节。
+{{< /note >}}
+
+<!--
+1. Install [`fluentd`](https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd),
+ `fluent-plugin-forest` and `fluent-plugin-rewrite-tag-filter` in the kube-apiserver node
+
+1. Create a config file for fluentd
+-->
+1. 在 kube-apiserver 节点上安装 [`fluentd`](https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd)、
+, `fluent-plugin-forest` 和 `fluent-plugin-rewrite-tag-filter`。
+
1. 为 fluentd 创建一个配置文件
- ```none
- $ cat <<EOF > /etc/fluentd/config
- # fluentd conf runs in the same host with kube-apiserver
- <source>
+ ```none
+ $ cat <<EOF > /etc/fluentd/config
+ # fluentd 运行在 kube-apiserver 相同的主机上
+ <source>
@type tail
- # audit log path of kube-apiserver
+ # kube-apiserver 审计日志路径
path /var/log/audit
pos_file /var/log/audit.pos
format json
time_key time
time_format %Y-%m-%dT%H:%M:%S.%N%z
tag audit
- </source>
+ </source>
- <filter audit>
+ <filter audit>
#https://github.com/fluent/fluent-plugin-rewrite-tag-filter/issues/13
type record_transformer
enable_ruby
<record>
namespace ${record["objectRef"].nil? ? "none":(record["objectRef"]["namespace"].nil? ? "none":record["objectRef"]["namespace"])}
</record>
- </filter>
+ </filter>
- <match audit>
- # route audit according to namespace element in context
+ <match audit>
+ # 根据上下文中的名字空间元素对审计进行路由
@type rewrite_tag_filter
rewriterule1 namespace ^(.+) ${tag}.$1
- </match>
+ </match>
- <filter audit.**>
+ <filter audit.**>
@type record_transformer
remove_keys namespace
- </filter>
+ </filter>
- <match audit.**>
+ <match audit.**>
@type forest
subtype file
remove_prefix audit
@@ -401,119 +484,124 @@ In this example, we will use fluentd to split audit events by different namespac
format json
include_time_key true
</template>
- </match>
- ```
+ </match>
+ ```
<!--
1. start fluentd
-->
-1. 启动 fluentd
+3. 启动 fluentd
- ```shell
- $ fluentd -c /etc/fluentd/config -vv
- ```
+ ```shell
+ fluentd -c /etc/fluentd/config -vv
+ ```
<!--
1. start kube-apiserver with the following options:
-->
-1. 给 kube-apiserver 配置以下参数并启动：
+4. 给 kube-apiserver 配置以下参数并启动：
- ```shell
- --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/kube-audit --audit-log-format=json
- ```
+ ```shell
+ --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/kube-audit --audit-log-format=json
+ ```
<!--
1. check audits for different namespaces in `/var/log/audit-*.log`
-->
-1. 在 `/var/log/audit-*.log` 文件中检查不同命名空间的审计事件
+5. 在 `/var/log/audit-*.log` 文件中检查不同命名空间的审计事件
<!--
### Use logstash to collect and distribute audit events from webhook backend
-[Logstash][logstash] is an open source, server-side data processing tool. In this example,
+
+[Logstash](https://www.elastic.co/products/logstash)
+is an open source, server-side data processing tool. In this example,
we will use logstash to collect audit events from webhook backend, and save events of
different users into different files.
-1. install [logstash][logstash_install_doc]
+1. install [logstash](https://www.elastic.co/guide/en/logstash/current/installing-logstash.html)
1. create config file for logstash
-->
### 使用 logstash 采集并分发 webhook 后端的审计事件
-[Logstash][logstash] 是一个开源的、服务器端的数据处理工具。在下面的示例中，我们将使用 logstash 采集 webhook 后端的审计事件，并且将来自不同用户的事件存入不同的文件。
+[Logstash](https://www.elastic.co/products/logstash) 是一个开源的、服务器端的数据处理工具。
+在下面的示例中，我们将使用 logstash 采集 webhook 后端的审计事件，并且将来自不同用户的事件存入不同的文件。
+
+1. 安装 [logstash](https://www.elastic.co/guide/en/logstash/current/installing-logstash.html)
-1. 安装 [logstash][logstash_install_doc]
1. 为 logstash 创建配置文件
- ```none
- $ cat <<EOF > /etc/logstash/config
- input{
- http{
- #TODO, figure out a way to use kubeconfig file to authenticate to logstash
- #https://www.elastic.co/guide/en/logstash/current/plugins-inputs-http.html#plugins-inputs-http-ssl
- port=>8888
- }
- }
- filter{
- split{
- # Webhook audit backend sends several events together with EventList
- # split each event here.
- field=>[items]
- # We only need event subelement, remove others.
- remove_field=>[headers, metadata, apiVersion, "@timestamp", kind, "@version", host]
- }
- mutate{
- rename => {items=>event}
- }
- }
- output{
- file{
- # Audit events from different users will be saved into different files.
- path=>"/var/log/kube-audit-%{[event][user][username]}/audit"
- }
- }
- ```
+ ```none
+ cat <<EOF > /etc/logstash/config
+ input{
+ http{
+ #TODO, figure out a way to use kubeconfig file to authenticate to logstash
+ #https://www.elastic.co/guide/en/logstash/current/plugins-inputs-http.html#plugins-inputs-http-ssl
+ port=>8888
+ }
+ }
+ filter{
+ split{
+ # Webhook 审计后端与 EventList 一起发送若干事件
+ # 对事件进行分割
+ field=>[items]
+ # 我们只需要 event 子元素，去掉其他元素
+ remove_field=>[headers, metadata, apiVersion, "@timestamp", kind, "@version", host]
+ }
+ mutate{
+ rename => {items=>event}
+ }
+ }
+ output{
+ file{
+ # 来自不同用户的审计事件会被保存到不同文件中
+ path=>"/var/log/kube-audit-%{[event][user][username]}/audit"
+ }
+ }
+ ```
<!--
1. start logstash
-->
-1. 启动 logstash
+3. 启动 logstash
- ```shell
- $ bin/logstash -f /etc/logstash/config --path.settings /etc/logstash/
- ```
+ ```shell
+ bin/logstash -f /etc/logstash/config --path.settings /etc/logstash/
+ ```
<!--
1. create a [kubeconfig file](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) for kube-apiserver webhook audit backend
-->
-1. 为 kube-apiserver webhook 审计后端创建一个 [kubeconfig 文件](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/)
+4. 为 kube-apiserver webhook 审计后端创建一个
+ [kubeconfig 文件](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
- ```none
- $ cat <<EOF > /etc/kubernetes/audit-webhook-kubeconfig
- apiVersion: v1
- clusters:
- - cluster:
- server: http://<ip_of_logstash>:8888
- name: logstash
- contexts:
- - context:
- cluster: logstash
- user: ""
- name: default-context
- current-context: default-context
- kind: Config
- preferences: {}
- users: []
- EOF
- ```
+ ```bash
+ cat <<EOF > /etc/kubernetes/audit-webhook-kubeconfig
+ apiVersion: v1
+ clusters:
+ - cluster:
+ server: http://<ip_of_logstash>:8888
+ name: logstash
+ contexts:
+ - context:
+ cluster: logstash
+ user: ""
+ name: default-context
+ current-context: default-context
+ kind: Config
+ preferences: {}
+ users: []
+ EOF
+ ```
<!--
1. start kube-apiserver with the following options:
-->
-1. 为 kube-apiserver 配置以下参数并启动：
+5. 为 kube-apiserver 配置以下参数并启动：
- ```shell
- --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig
- ```
+ ```shell
+ --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig
+ ```
<!--
1. check audits in logstash node's directories `/var/log/kube-audit-*/audit`
@@ -522,91 +610,18 @@ Note that in addition to file output plugin, logstash has a variety of outputs t
let users route data where they want. For example, users can emit audit events to elasticsearch
plugin which supports full-text search and analytics.
-->
-1. 在 logstash node 节点的 `/var/log/kube-audit-*/audit` 目录中检查审计事件
+6. 在 logstash 节点的 `/var/log/kube-audit-*/audit` 目录中检查审计事件
-注意到，除了文件输出插件外，logstash 还有其它多种输出可以让用户路由不同的数据。例如，用户可以将审计事件发送给支持全文搜索和分析的 elasticsearch 插件。
+请注意，除了文件输出插件外，logstash 还有其它多种输出可以让用户路由不同的数据。
+例如，用户可以将审计事件发送给支持全文搜索和分析的 elasticsearch 插件。
+
+## {{% heading "whatsnext" %}}
<!--
-## Legacy Audit
+Visit [Auditing with Falco](/docs/tasks/debug-application-cluster/falco).
-__Note:__ Legacy Audit is deprecated and is disabled by default since 1.8 and
-will be removed in 1.12. To fallback to this legacy audit, disable the advanced
-auditing feature using the `AdvancedAuditing` feature gate in [kube-apiserver][kube-apiserver]:
+Learn about [Mutating webhook auditing annotations](/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations).
-->
-## 传统的审计
-
-__注意：__ 传统审计已被弃用，自 1.8 版本以后默认禁用，并且将会在 1.12 版本中彻底移除。
-如果想要回退到传统的审计功能，请使用 [kube-apiserver][kube-apiserver] 中 feature gate 的 `AdvancedAuditing` 功能来禁用高级审核功能：
-
-```
---feature-gates=AdvancedAuditing=false
-```
-
-<!--
-In legacy format, each audit log entry contains two lines:
-
-1. The request line containing a unique ID to match the response and request
- metadata, such as the source IP, requesting user, impersonation information,
- resource being requested, etc.
-2. The response line containing a unique ID matching the request line and the response code.
-
-Example output for `admin` user listing pods in the `default` namespace:
--->
-在传统格式中，每个审计文件条目包含两行：
-
-1. 请求行包含唯一 ID 以匹配响应和请求元数据，例如源 IP、请求用户、模拟信息和请求的资源等。
-2. 响应行包含与请求行和响应代码相匹配的唯一 ID。
-
-```
-2017-03-21T03:57:09.106841886-04:00 AUDIT: id="c939d2a7-1c37-4ef1-b2f7-4ba9b1e43b53" ip="127.0.0.1" method="GET" user="admin" groups="\"system:masters\",\"system:authenticated\"" as="<self>" asgroups="<lookup>" namespace="default" uri="/api/v1/namespaces/default/pods"
-2017-03-21T03:57:09.108403639-04:00 AUDIT: id="c939d2a7-1c37-4ef1-b2f7-4ba9b1e43b53" response="200"
-```
-
-<!--
-### Configuration
-
-[Kube-apiserver][kube-apiserver] provides the following options which are responsible
-for configuring where and how audit logs are handled:
--->
-### 配置
-
-[Kube-apiserver][kube-apiserver] 提供以下选项，负责配置审核日志的位置和处理方式：
-
-<!--
-- `audit-log-path` - enables the audit log pointing to a file where the requests are being logged to, '-' means standard out.
-- `audit-log-maxage` - specifies maximum number of days to retain old audit log files based on the timestamp encoded in their filename.
-- `audit-log-maxbackup` - specifies maximum number of old audit log files to retain.
-- `audit-log-maxsize` - specifies maximum size in megabytes of the audit log file before it gets rotated. Defaults to 100MB.
--->
-- `audit-log-path` - 使审计日志指向请求被记录到的文件，'-' 表示标准输出。
-- `audit-log-maxage` - 根据文件名中编码的时间戳指定保留旧审计日志文件的最大天数。
-- `audit-log-maxbackup` - 指定要保留的旧审计日志文件的最大数量。
-- `audit-log-maxsize` - 指定审核日志文件的最大大小（兆字节）。默认为100MB。
-
-<!--
-If an audit log file already exists, Kubernetes appends new audit logs to that file.
-Otherwise, Kubernetes creates an audit log file at the location you specified in
-`audit-log-path`. If the audit log file exceeds the size you specify in `audit-log-maxsize`,
-Kubernetes will rename the current log file by appending the current timestamp on
-the file name (before the file extension) and create a new audit log file.
-Kubernetes may delete old log files when creating a new log file; you can configure
-how many files are retained and how old they can be by specifying the `audit-log-maxbackup`
-and `audit-log-maxage` options.
--->
-如果审核日志文件已经存在，则 Kubernetes 会将新的审核日志附加到该文件。
-否则，Kubernetes 会在您在 `audit-log-path` 中指定的位置创建一个审计日志文件。
-如果审计日志文件超过了您在 `audit-log-maxsize` 中指定的大小，则 Kubernetes 将通过在文件名（在文件扩展名之前）附加当前时间戳并重新创建一个新的审计日志文件来重命名当前日志文件。
-Kubernetes 可能会在创建新的日志文件时删除旧的日志文件; 您可以通过指定 `audit-log-maxbackup` 和 `audit-log-maxage` 选项来配置保留多少文件以及它们的保留时间。
-
-[kube-apiserver]: /docs/admin/kube-apiserver
-[auditing-proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/auditing.md
-[auditing-api]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1beta1/types.go
-[gce-audit-profile]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh#L735
-[kubeconfig]: /docs/tasks/access-application-cluster/configure-access-multiple-clusters/
-[fluentd]: http://www.fluentd.org/
-[fluentd_install_doc]: https://docs.fluentd.org/v/0.12/articles/quickstart#step1-installing-fluentd
-[logstash]: https://www.elastic.co/products/logstash
-[logstash_install_doc]: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html
-[kube-aggregator]: /docs/concepts/api-extension/apiserver-aggregation
+* 了解 [Mutating webhook 审计注解](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations)
diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-application-introspection.md b/content/zh/docs/tasks/debug-application-cluster/debug-application-introspection.md
index 6be1e8946f..51e1f353b8 100644
--- a/content/zh/docs/tasks/debug-application-cluster/debug-application-introspection.md
+++ b/content/zh/docs/tasks/debug-application-cluster/debug-application-introspection.md
@@ -17,46 +17,43 @@ your pods. But there are a number of ways to get even more information about you
前面我们介绍了如何使用 `kubectl get pods` 来查询 pod 的简单信息。
除此之外，还有一系列的方法来获取应用的更详细信息。
-
-
-
<!-- body -->
<!--
## Using `kubectl describe pod` to fetch details about pods
-->
-## 使用 `kubectl describe pod` 命令获取 pod 详情
+## 使用 `kubectl describe pod` 命令获取 Pod 详情
<!--
For this example we'll use a Deployment to create two pods, similar to the earlier example.
-->
-与之前的例子类似，我们使用一个 Deployment 来创建两个 pod。
+与之前的例子类似，我们使用一个 Deployment 来创建两个 Pod。
{{< codenew file="application/nginx-with-request.yaml" >}}
<!--
Create deployment by running following command:
-->
-使用如下命令创建 deployment：
+使用如下命令创建 Deployment：
```shell
kubectl apply -f https://k8s.io/examples/application/nginx-with-request.yaml
```
-```none
+```
deployment.apps/nginx-deployment created
```
<!--
Check pod status by following command:
-->
-使用如下命令查看 pod 状态：
+使用如下命令查看 Pod 状态：
```shell
kubectl get pods
```
-```none
+```
NAME READY STATUS RESTARTS AGE
nginx-deployment-1006230814-6winp 1/1 Running 0 11s
nginx-deployment-1006230814-fmgu3 1/1 Running 0 11s
@@ -65,13 +62,13 @@ nginx-deployment-1006230814-fmgu3 1/1 Running 0 11s
<!--
We can retrieve a lot more information about each of these pods using `kubectl describe pod`. For example:
-->
-我们可以使用 `kubectl describe pod` 命令来查询每个 pod 的更多信息，比如：
+我们可以使用 `kubectl describe pod` 命令来查询每个 Pod 的更多信息，比如：
```shell
kubectl describe pod nginx-deployment-1006230814-6winp
```
-```none
+```
Name: nginx-deployment-1006230814-6winp
Namespace: default
Node: kubernetes-node-wul5/10.240.0.9
@@ -130,34 +127,37 @@ Events:
Here you can see configuration information about the container(s) and Pod (labels, resource requirements, etc.),
as well as status information about the container(s) and Pod (state, readiness, restart count, events, etc.).
-->
-这里可以看到容器和 pod 的 label、资源需求等配置信息，还可以看到状态、就绪状态、重启次数、事件等状态信息。
+这里可以看到容器和 Pod 的标签、资源需求等配置信息，还可以看到状态、就绪态、
+重启次数、事件等状态信息。
<!--
The container state is one of Waiting, Running, or Terminated.
Depending on the state, additional information will be provided -- here you can see that for a container in Running state, the system tells you when the container started.
-->
-容器状态包括 Waiting、Running 和 Terminated。
-根据状态的不同，将提供额外的信息——在这里您可以看到，对于处于运行状态的容器，系统会告诉您容器的启动时间。
+容器状态是 Waiting、Running 和 Terminated 之一。
+根据状态的不同，还有对应的额外的信息 —— 在这里你可以看到，
+对于处于运行状态的容器，系统会告诉你容器的启动时间。
<!--
Ready tells you whether the container passed its last readiness probe.
(In this case, the container does not have a readiness probe configured; the container is assumed to be ready if no readiness probe is configured.)
-->
-Ready 指示是否通过了最后一个就绪探测。
-(在本例中，容器没有配置就绪探测；如果没有配置就绪探测，则假定容器已经就绪。)
+Ready 指示是否通过了最后一个就绪态探测。
+(在本例中，容器没有配置就绪态探测；如果没有配置就绪态探测，则假定容器已经就绪。)
<!--
Restart Count tells you how many times the container has been restarted;
this information can be useful for detecting crash loops in containers that are configured with a restart policy of 'always.'
-->
-Restart Count 告诉您容器已重启的次数；
-这些信息对于定位配置了“always”重启策略的容器持续崩溃问题非常有用。
+Restart Count 告诉你容器已重启的次数；
+这些信息对于定位配置了 “Always” 重启策略的容器持续崩溃问题非常有用。
<!--
Currently the only Condition associated with a Pod is the binary Ready condition,
which indicates that the pod is able to service requests and should be added to the load balancing pools of all matching services.
-->
-目前，唯一与 Pod 有关的状态是就绪状态，这表明 Pod 能够为请求提供服务，并且应该添加到相应服务的负载平衡池中。
+目前，唯一与 Pod 有关的状态是 Ready 状况，该状况表明 Pod 能够为请求提供服务，
+并且应该添加到相应服务的负载均衡池中。
<!--
Lastly, you see a log of recent events related to your Pod.
@@ -166,19 +166,15 @@ The system compresses multiple identical events by indicating the first and last
"SubobjectPath" tells you which object (e.g. container within the pod) is being referred to,
and "Reason" and "Message" tell you what happened.
-->
-最后，您将看到与 Pod 相关的近期事件。
-系统通过指示第一次和最后一次看到它以及看到它的次数来压缩多个相同的事件。
-“From”表示记录事件的组件，
-“SubobjectPath”告诉您引用了哪个对象(例如pod中的容器)，
-“Reason”和“Message”告诉您发生了什么。
-
+最后，你还可以看到与 Pod 相关的近期事件。
+系统通过指示第一次和最后一次看到事件以及看到该事件的次数来压缩多个相同的事件。
+“From” 标明记录事件的组件，
+“SubobjectPath” 告诉你引用了哪个对象（例如 Pod 中的容器），
+“Reason” 和 “Message” 告诉你发生了什么。
<!--
## Example: debugging Pending Pods
--->
-## 例子: 调试 Pending Pods
-<!--
A common scenario that you can detect using events is when you've created a Pod that won't fit on any node.
For example, the Pod might request more resources than are free on any node,
or it might specify a label selector that doesn't match any nodes.
@@ -187,19 +183,20 @@ on a four-node cluster where each (virtual) machine has 1 CPU.
In that case one of the Pods will not be able to schedule.
(Note that because of the cluster addon pods such as fluentd, skydns, etc., that run on each node, if we requested 1000 millicores then none of the Pods would be able to schedule.)
-->
-一个常见的场景是，当你创建了一个 Pod，但是他没有被调度到任何一个 node，可以使用 event 来调试。
-比如说，这个 Pod 需求的资源比较多，没有任何一个 node 能够满足，或者它指定了一个标签，没有 node 被匹配到。
-假如，我们创建之前的 Deployment 时指定副本数是5（不再是2），并且需求 600 millicore（不再是 500），
-对于一个4个节点的集群并且每个节点只有1个CPU。
-这个情况下，至少有一个 Pod 不能被调度。
-（需要注意的是，其他集群组件，比如 fluentd、skydns等等会在每个 node 上运行，
-如果我们需求 1000 millicore，那么将不会有 Pod 会被调度。）
+## 例子: 调试 Pending 状态的 Pod
+
+可以使用事件来调试的一个常见的场景是，你创建 Pod 无法被调度到任何节点。
+比如，Pod 请求的资源比较多，没有任何一个节点能够满足，或者它指定了一个标签，没有节点可匹配。
+假定我们创建之前的 Deployment 时指定副本数是 5（不再是 2），并且请求 600 毫核（不再是 500），
+对于一个 4 个节点的集群，若每个节点只有 1 个 CPU，这时至少有一个 Pod 不能被调度。
+（需要注意的是，其他集群插件 Pod，比如 fluentd、skydns 等等会在每个节点上运行，
+如果我们需求 1000 毫核，将不会有 Pod 会被调度。）
```shell
kubectl get pods
```
-```none
+```
NAME READY STATUS RESTARTS AGE
nginx-deployment-1006230814-6winp 1/1 Running 0 7m
nginx-deployment-1006230814-fmgu3 1/1 Running 0 7m
@@ -211,13 +208,14 @@ nginx-deployment-1370807587-fz9sd 0/1 Pending 0 1m
<!--
To find out why the nginx-deployment-1370807587-fz9sd pod is not running, we can use `kubectl describe pod` on the pending Pod and look at its events:
-->
-为了查找 Pod nginx-deployment-1370807587-fz9sd 没有运行的原因，我们可以使用 `kubectl describe pod` 命令查询处理 pending 状态的 Pod：
+为了查找 Pod nginx-deployment-1370807587-fz9sd 没有运行的原因，我们可以使用
+`kubectl describe pod` 命令描述 Pod，查看其事件：
```shell
kubectl describe pod nginx-deployment-1370807587-fz9sd
```
-```none
+```
Name: nginx-deployment-1370807587-fz9sd
Namespace: default
Node: /
@@ -256,13 +254,13 @@ Here you can see the event generated by the scheduler saying that the Pod failed
The message tells us that there were not enough resources for the Pod on any of the nodes.
-->
这里你可以看到由调度器记录的事件，它表明了 Pod 不能被调度的原因是 `FailedScheduling`（也可能是其他值）。
-这个信息表明，没有任何 node 拥有足够多的资源。
+其 message 部分表明没有任何节点拥有足够多的资源。
<!--
To correct this situation, you can use `kubectl scale` to update your Deployment to specify four or fewer replicas.
(Or you could just leave the one Pod pending, which is harmless.)
-->
-要纠正这种情况，可以使用“kubectl scale”更新部署，以指定四个或更少的副本。
+要纠正这种情况，可以使用 `kubectl scale` 更新 Deployment，以指定 4 个或更少的副本。
(或者你可以让 Pod 继续保持这个状态，这是无害的。)
<!--
@@ -270,7 +268,8 @@ Events such as the ones you saw at the end of `kubectl describe pod` are persist
provide high-level information on what is happening in the cluster.
To list all events you can use
-->
-与您在“kubectl describe pod”结尾处看到的一样，这些事件都将保存在 etcd 中，并提供关于集群中正在发生的事情的高级信息。
+你在 `kubectl describe pod` 结尾处看到的事件都保存在 etcd 中，
+并提供关于集群中正在发生的事情的高级信息。
如果需要列出所有事件，可使用命令：
```shell
@@ -282,9 +281,9 @@ but you have to remember that events are namespaced.
This means that if you're interested in events for some namespaced object
(e.g. what happened with Pods in namespace `my-namespace`) you need to explicitly provide a namespace to the command:
-->
-但是，需要注意的是，事件是按照 namespace 分组的。
-如果你对些些 namespace 下的对象感兴趣（比如查看 namespace `my-namespace` 下的 Pod 事件）,
-你需要显式的在命令行中指定 namespace：
+但是，需要注意的是，事件是区分名字空间的。
+如果你对某些名字空间域的对象（比如 `my-namespace` 名字下的 Pod）的事件感兴趣,
+你需要显式地在命令行中指定名字空间：
```shell
kubectl get events --namespace=my-namespace
@@ -293,7 +292,7 @@ kubectl get events --namespace=my-namespace
<!--
To see events from all namespaces, you can use the `--all-namespaces` argument.
-->
-查看所有 namespace 的事件，可使用 `--all-namespaces` 参数：
+查看所有 namespace 的事件，可使用 `--all-namespaces` 参数。
<!--
In addition to `kubectl describe pod`, another way to get extra information about a pod (beyond what is provided by `kubectl get pod`) is
@@ -302,9 +301,11 @@ This will give you, in YAML format, even more information than `kubectl describe
Here you will see things like annotations (which are key-value metadata without the label restrictions, that is used internally by Kubernetes system components),
restart policy, ports, and volumes.
-->
-除了 `kubectl describe pod` 以外，另一种获取 Pod 额外信息（超越 `kubectl get pod`）的方法是给 `kubectl get pod` 增加 `-o yaml` 输出格式参数。
-这将以YAML格式为您提供比“kubectl describe pod”更多的信息——实际上是系统拥有的关于pod的所有信息。
-在这里，您将看到注释(没有标签限制的键值元数据，由Kubernetes系统组件在内部使用)、重启策略、端口和卷。
+除了 `kubectl describe pod` 以外，另一种获取 Pod 额外信息（除了 `kubectl get pod`）的方法
+是给 `kubectl get pod` 增加 `-o yaml` 输出格式参数。
+该命令将以 YAML 格式为你提供比 `kubectl describe pod` 更多的信息 —— 实际上是系统拥有的关于 Pod 的所有信息。
+在这里，你将看到注解（没有标签限制的键值元数据，由 Kubernetes 系统组件在内部使用）、
+重启策略、端口和卷等。
```shell
kubectl get pod nginx-deployment-1006230814-6winp -o yaml
@@ -382,10 +383,7 @@ status:
<!--
## Example: debugging a down/unreachable node
--->
-## 例子: 调试 down/unreachable node
-<!--
Sometimes when debugging it can be useful to look at the status of a node
-- for example, because you've noticed strange behavior of a Pod that's running on the node,
or to find out why a Pod won't schedule onto the node.
@@ -397,17 +395,19 @@ Notice the events that show the node is NotReady, and
also notice that the pods are no longer running
(they are evicted after five minutes of NotReady status).
-->
-有时候，在调试时，查看节点的状态是很有用的——例如，因为您已经注意到节点上运行的 Pod 的奇怪行为，
+## 示例：调试宕机或无法联系的节点
+
+有时候，在调试时，查看节点的状态是很有用的 —— 例如，因为你已经注意到节点上运行的 Pod 的奇怪行为，
或者想了解为什么 Pod 不会调度到节点上。
-与Pods一样，您可以使用 `kubectl describe node` 和 `kubectl get node -o yaml` 来查询节点的详细信息。
-例如，如果某个节点关闭(与网络断开连接，或者 kubelet 挂掉，无法重新启动，等等)，您将看到以下情况。
-请注意显示节点未就绪的事件，也请注意 pod 不再运行(它们在5分钟未就绪状态后被驱逐)。
+与 Pod 一样，你可以使用 `kubectl describe node` 和 `kubectl get node -o yaml` 来查询节点的详细信息。
+例如，如果某个节点宕机（与网络断开连接，或者 kubelet 挂掉无法重新启动等等），你将看到以下情况。
+请注意显示节点未就绪的事件，也请注意 Pod 不再运行(它们在5分钟未就绪状态后被驱逐)。
```shell
kubectl get nodes
```
-```none
+```
NAME STATUS ROLES AGE VERSION
kubernetes-node-861h NotReady <none> 1h v1.13.0
kubernetes-node-bols Ready <none> 1h v1.13.0
@@ -518,11 +518,8 @@ status:
systemUUID: ABE5F6B4-D44B-108B-C46A-24CCE16C8B6E
```
-
-
## {{% heading "whatsnext" %}}
-
<!--
Learn about additional debugging tools, including:
-->
@@ -536,11 +533,10 @@ Learn about additional debugging tools, including:
* [Connecting to containers via port forwarding](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
* [Inspect Kubernetes node with crictl](/docs/tasks/debug-application-cluster/crictl/)
-->
-* [日志](/docs/concepts/cluster-administration/logging/)
-* [监控](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
-* [使用 `exec` 进入容器](/docs/tasks/debug-application-cluster/get-shell-running-container/)
-* [使用代理连接容器](/docs/tasks/extend-kubernetes/http-proxy-access-api/)
-* [使用端口转发连接容器](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
-* [使用 crictl 检查节点](/docs/tasks/debug-application-cluster/crictl/)
-
+* [日志](/zh/docs/concepts/cluster-administration/logging/)
+* [监控](/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
+* [使用 `exec` 进入容器](/zh/docs/tasks/debug-application-cluster/get-shell-running-container/)
+* [使用代理连接容器](/zh/docs/tasks/extend-kubernetes/http-proxy-access-api/)
+* [使用端口转发连接容器](/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
+* [使用 crictl 检查节点](/zh/docs/tasks/debug-application-cluster/crictl/)
diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-cluster.md b/content/zh/docs/tasks/debug-application-cluster/debug-cluster.md
index 548600633e..0735ed6bd6 100644
--- a/content/zh/docs/tasks/debug-application-cluster/debug-cluster.md
+++ b/content/zh/docs/tasks/debug-application-cluster/debug-cluster.md
@@ -1,14 +1,39 @@
---
title: 集群故障排查
+content_type: concept
---
+<!--
+reviewers:
+- davidopp
+title: Troubleshoot Clusters
+content_type: concept
+-->
+<!-- overview -->
+
+<!--
+This doc is about cluster troubleshooting; we assume you have already ruled out your application as the root cause of the
+problem you are experiencing. See
+the [application troubleshooting guide](/docs/tasks/debug-application-cluster/debug-application) for tips on application debugging.
+You may also visit [troubleshooting document](/docs/troubleshooting/) for more information.
+-->
本篇文档是介绍集群故障排查的；我们假设对于你碰到的问题，你已经排除了是由应用程序造成的。
-对于应用的调试，请参阅[应用故障排查指南](/cn/docs/tasks/debug-application-cluster/debug-application)。
-你也可以访问[troubleshooting document](/docs/troubleshooting/)来获取更多的信息。
+对于应用的调试，请参阅[应用故障排查指南](/zh/docs/tasks/debug-application-cluster/debug-application/)。
+你也可以访问[故障排查](/zh/docs/tasks/debug-application-cluster/troubleshooting/)
+来获取更多的信息。
-## 显示出集群的节点列表
+<!-- body -->
-调试的第一步是查看所有的节点是否都正确的注册。
+<!--
+## Listing your cluster
+
+The first thing to debug in your cluster is if your nodes are all registered correctly.
+
+Run
+-->
+## 列举集群节点
+
+调试的第一步是查看所有的节点是否都已正确注册。
运行
@@ -16,99 +41,211 @@ title: 集群故障排查
kubectl get nodes
```
-接下来，验证你的所有节点都能够显示出来，并且都处于`Ready`状态。
+<!--
+And verify that all of the nodes you expect to see are present and that they are all in the `Ready` state.
-## 查看logs
+To get detailed information about the overall health of your cluster, you can run:
+-->
+验证你所希望看见的所有节点都能够显示出来，并且都处于 `Ready` 状态。
-现在，挖掘出集群更深层的信息就需要登录到相关的机器上。下面是相关log文件所在的位置。
-(注意，对于基于systemd的系统，你可能需要使用`journalctl`)
+为了了解你的集群的总体健康状况详情，你可以运行：
+```shell
+kubectl cluster-info dump
+```
+<!--
+## Looking at logs
+
+For now, digging deeper into the cluster requires logging into the relevant machines. Here are the locations
+of the relevant log files. (note that on systemd-based systems, you may need to use `journalctl` instead)
+-->
+## 查看日志
+
+到这里，挖掘出集群更深层的信息就需要登录到相关的机器上。下面是相关日志文件所在的位置。
+（注意，对于基于 systemd 的系统，你可能需要使用`journalctl`）。
+
+<!--
### Master
- * /var/log/kube-apiserver.log - API Server, 提供API服务
- * /var/log/kube-scheduler.log - Scheduler, 负责调度决策
- * /var/log/kube-controller-manager.log - 管理replication controllers的控制器
+ * `/var/log/kube-apiserver.log` - API Server, responsible for serving the API
+ * `/var/log/kube-scheduler.log` - Scheduler, responsible for making scheduling decisions
+ * `/var/log/kube-controller-manager.log` - Controller that manages replication controllers
+-->
+### 主控节点
+* `/var/log/kube-apiserver.log` - API 服务器, 提供API服务
+* `/var/log/kube-scheduler.log` - 调度器, 负责产生调度决策
+* `/var/log/kube-controller-manager.log` - 管理副本控制器的控制器
+
+<!--
### Worker Nodes
- * /var/log/kubelet.log - Kubelet, 管控节点上运行的容器
- * /var/log/kube-proxy.log - Kube Proxy, 负责服务的负载均衡
+* `/var/log/kubelet.log` - Kubelet, responsible for running containers on the node
+* `/var/log/kube-proxy.log` - Kube Proxy, responsible for service load balancing
+-->
-## 集群故障模式的概述
+### 工作节点
-下面是一个不完整的列表，列举了一些可能出错的场景，以及通过调整集群配置来解决相关问题的方法。
+* `/var/log/kubelet.log` - `kubelet`，负责在节点运行容器
+* `/var/log/kube-proxy.log` - `kube-proxy`, 负责服务的负载均衡
-根本原因：
- - VM(s)关机
+<!--
+## A general overview of cluster failure modes
+
+This is an incomplete list of things that could go wrong, and how to adjust your cluster setup to mitigate the problems.
+-->
+## 集群故障模式的一般性概述
+
+下面是一个不完整的列表，列举了一些可能的出错场景，以及通过调整集群配置来解决相关问题的方法。
+
+<!--
+### Root causes:
+
+ - VM(s) shutdown
+ - Network partition within cluster, or between cluster and users
+ - Crashes in Kubernetes software
+ - Data loss or unavailability of persistent storage (e.g. GCE PD or AWS EBS volume)
+ - Operator error, for example misconfigured Kubernetes software or application software
+-->
+### 根本原因
+
+ - VM(s) 关机
- 集群之间，或者集群和用户之间网络分裂
- - Kubernetes软件本身崩溃了
- - 数据丢失或者持久化存储不可用(如:GCE PD 或 AWS EBS卷)
- - 操作错误，如：Kubernetes或者应用程序配置错误
+ - Kubernetes 软件本身崩溃
+ - 数据丢失或者持久化存储不可用（如：GCE PD 或 AWS EBS 卷）
+ - 操作错误，如：Kubernetes 或者应用程序配置错误
-具体情况:
+<!--
+### Specific scenarios:
- - Apiserver所在的VM关机或者apiserver崩溃
- - 结果
- - 不能停止，更新，或者启动新的pods，services，replication controller
- - 现有的pods和services在不依赖Kubernetes API的情况下应该能继续正常工作
- - Apiserver 后端存储丢失
- - 结果
- - apiserver应该不能起来
- - kubelets将不能访问它，但是能够继续运行之前的Pods和提供相同的服务代理
- - 在apiserver重启之前，需要手动恢复或者重创apiserver的状态
-
- - Kubernetes服务组件(节点控制器，副本控制器，调度器等等)所在的VM关机或者崩溃
- - 当前，这些控制器是和apiserver共存的，它们不可用的现象是与apiserver类似的
- - 将来，这些控制器也会复制为多份，并且可能为非共存的
- - 它们没有自己的持久状态
- - 单个节点(VM或者物理机)关机
- - 结果
- - 此节点上的所有Pods都停止运行
- - 网络分裂(Network partition)
- - 结果
- - partition A认为partition B中所有的节点都down掉了；partition B认为apiserver是down掉了(假定master所在的VM位于partition A内)。
- - Kubelet软件故障
- - 结果
- - 崩溃的kubelet就不能在其所在的节点上启动新的pods
- - kubelet可能删掉pods或者不删
- - 节点被标识为非健康态
- - 副本控制器会在其它的节点上启动新的pods
- - 集群操作错误
- - 结果
- - 丢失pods，服务等等
- - 丢失apiserver后端存储
- - 用户无法读取API
- - 等等
+ - Apiserver VM shutdown or apiserver crashing
+ - Results
+ - unable to stop, update, or start new pods, services, replication controller
+ - existing pods and services should continue to work normally, unless they depend on the Kubernetes API
+ - Apiserver backing storage lost
+ - Results
+ - apiserver should fail to come up
+ - kubelets will not be able to reach it but will continue to run the same pods and provide the same service proxying
+ - manual recovery or recreation of apiserver state necessary before apiserver is restarted
+-->
+### 具体情况:
-缓解措施:
+- API 服务器所在的 VM 关机或者 API 服务器崩溃
+ - 结果
+ - 不能停止、更新或者启动新的 Pod、服务或副本控制器
+ - 现有的 Pod 和服务在不依赖 Kubernetes API 的情况下应该能继续正常工作
+- API 服务器的后端存储丢失
+ - 结果
+ - API 服务器应该不能启动
+ - kubelet 将不能访问 API 服务器，但是能够继续运行之前的 Pod 和提供相同的服务代理
+ - 在 API 服务器重启之前，需要手动恢复或者重建 API 服务器的状态
+<!--
+ - Supporting services (node controller, replication controller manager, scheduler, etc) VM shutdown or crashes
+ - currently those are colocated with the apiserver, and their unavailability has similar consequences as apiserver
+ - in future, these will be replicated as well and may not be co-located
+ - they do not have their own persistent state
+ - Individual node (VM or physical machine) shuts down
+ - Results
+ - pods on that Node stop running
+ - Network partition
+ - Results
+ - partition A thinks the nodes in partition B are down; partition B thinks the apiserver is down. (Assuming the master VM ends up in partition A.)
+-->
+- Kubernetes 服务组件（节点控制器、副本控制器管理器、调度器等）所在的 VM 关机或者崩溃
+ - 当前，这些控制器是和 API 服务器在一起运行的，它们不可用的现象是与 API 服务器类似的
+ - 将来，这些控制器也会复制为多份，并且可能不在运行于同一节点上
+ - 它们没有自己的持久状态
+- 单个节点（VM 或者物理机）关机
+ - 结果
+ - 此节点上的所有 Pod 都停止运行
+- 网络分裂
+ - 结果
+ - 分区 A 认为分区 B 中所有的节点都已宕机；分区 B 认为 API 服务器宕机
+ （假定主控节点所在的 VM 位于分区 A 内)。
+<!--
+ - Kubelet software fault
+ - Results
+ - crashing kubelet cannot start new pods on the node
+ - kubelet might delete the pods or not
+ - node marked unhealthy
+ - replication controllers start new pods elsewhere
+ - Cluster operator error
+ - Results
+ - loss of pods, services, etc
+ - lost of apiserver backing store
+ - users unable to read API
+ - etc.
+-->
+- kubelet 软件故障
+ - 结果
+ - 崩溃的 kubelet 就不能在其所在的节点上启动新的 Pod
+ - kubelet 可能删掉 Pod 或者不删
+ - 节点被标识为非健康态
+ - 副本控制器会在其它的节点上启动新的 Pod
+- 集群操作错误
+ - 结果
+ - 丢失 Pod 或服务等等
+ - 丢失 API 服务器的后端存储
+ - 用户无法读取API
+ - 等等
-- 措施：对于IaaS上的VMs，使用IaaS的自动VM重启功能
- - 缓解：Apiserver VM关机或apiserver崩溃
- - 缓解：Kubernetes服务组件所在的VM关机或崩溃
+<!--
+### Mitigations:
-- 措施: 对于具有apiserver+etcd的VM，使用IaaS提供的可靠的存储（例如GCE PD或者AWS EBS卷）
- - 缓解：Apiserver后端存储的丢失
+- Action: Use IaaS provider's automatic VM restarting feature for IaaS VMs
+ - Mitigates: Apiserver VM shutdown or apiserver crashing
+ - Mitigates: Supporting services VM shutdown or crashes
-- 措施：使用（实验）[高可用性](/docs/admin/high-availability)的配置
- - 缓解：master VM关机或者master组件(scheduler, API server, controller-managing)崩馈
+- Action: Use IaaS providers reliable storage (e.g. GCE PD or AWS EBS volume) for VMs with apiserver+etcd
+ - Mitigates: Apiserver backing storage lost
+
+- Action: Use [high-availability](/docs/admin/high-availability) configuration
+ - Mitigates: Control plane node shutdown or control plane components (scheduler, API server, controller-manager) crashing
+ - Will tolerate one or more simultaneous node or component failures
+ - Mitigates: API server backing storage (i.e., etcd's data directory) lost
+ - Assumes HA (highly-available) etcd configuration
+-->
+### 缓解措施：
+
+- 措施：对于 IaaS 上的 VMs，使用 IaaS 的自动 VM 重启功能
+ - 缓解：API 服务器 VM 关机或 API 服务器崩溃
+ - 缓解：Kubernetes 服务组件所在的 VM 关机或崩溃
+
+- 措施: 对于运行 API 服务器和 etcd 的 VM，使用 IaaS 提供的可靠的存储（例如 GCE PD 或者 AWS EBS 卷）
+ - 缓解：API 服务器后端存储的丢失
+
+- 措施：使用[高可用性](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/)的配置
+ - 缓解：主控节点 VM 关机或者主控节点组件（调度器、API 服务器、控制器管理器）崩馈
- 将容许一个或多个节点或组件同时出现故障
- - 缓解：apiserver后端存储(例如etcd的数据目录)丢失
- - 假定你使用了集群化的etcd。
+ - 缓解：API 服务器后端存储（例如 etcd 的数据目录）丢失
+ - 假定你使用了高可用的 etcd 配置
-- 措施：定期的对apiserver的PDs/EBS卷进行快照
- - 缓解：apiserver后端存储丢失
+<!--
+- Action: Snapshot apiserver PDs/EBS-volumes periodically
+ - Mitigates: Apiserver backing storage lost
+ - Mitigates: Some cases of operator error
+ - Mitigates: Some cases of Kubernetes software fault
+
+- Action: use replication controller and services in front of pods
+ - Mitigates: Node shutdown
+ - Mitigates: Kubelet software fault
+
+- Action: applications (containers) designed to tolerate unexpected restarts
+ - Mitigates: Node shutdown
+ - Mitigates: Kubelet software fault
+-->
+- 措施：定期对 API 服务器的 PDs/EBS 卷执行快照操作
+ - 缓解：API 服务器后端存储丢失
- 缓解：一些操作错误的场景
- - 缓解：一些Kubernetes软件本身故障的场景
+ - 缓解：一些 Kubernetes 软件本身故障的场景
-- 措施：在pods的前面使用副本控制器或服务
+- 措施：在 Pod 的前面使用副本控制器或服务
- 缓解：节点关机
- - 缓解：Kubelet软件故障
+ - 缓解：kubelet 软件故障
- 措施：应用（容器）设计成容许异常重启
- 缓解：节点关机
- - 缓解：Kubelet软件故障
+ - 缓解：kubelet 软件故障
-- 措施：[多个独立的集群](/docs/admin/multi-cluster)(并且避免一次性地对所有的集群进行有风险性的修改)
- - 缓解：以上列出的所有情况
diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-init-containers.md b/content/zh/docs/tasks/debug-application-cluster/debug-init-containers.md
index 9b91aad043..8e35642baf 100644
--- a/content/zh/docs/tasks/debug-application-cluster/debug-init-containers.md
+++ b/content/zh/docs/tasks/debug-application-cluster/debug-init-containers.md
@@ -1,18 +1,9 @@
---
-reviewers:
-- bprashanth
-- enisoc
-- erictune
-- foxish
-- janetkuo
-- kow3ns
-- smarterclayton
title: 调试 Init 容器
content_type: task
---
<!--
----
reviewers:
- bprashanth
- enisoc
@@ -23,7 +14,6 @@ reviewers:
- smarterclayton
title: Debug Init Containers
content_type: task
----
-->
<!-- overview -->
@@ -34,15 +24,12 @@ Init Containers. The example command lines below refer to the Pod as
`<pod-name>` and the Init Containers as `<init-container-1>` and
`<init-container-2>`.
-->
-
-此页显示如何核查与 init 容器执行相关的问题。
-下面的示例命令行将 Pod 称为 `<pod-name>`，而 init 容器称为 `<init-container-1>` 和 `<init-container-2>`。
-
-
+此页显示如何核查与 Init 容器执行相关的问题。
+下面的示例命令行将 Pod 称为 `<pod-name>`，而 Init 容器称为 `<init-container-1>` 和
+`<init-container-2>`。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
@@ -51,10 +38,8 @@ Init Containers. The example command lines below refer to the Pod as
* You should have [Configured an Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/).
-->
-* 您应该熟悉 [Init 容器](/docs/concepts/abstractions/init-containers/)的基础知识。
-* 您应该已经[配置好一个 Init 容器](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/)。
-
-
+* 你应该熟悉 [Init 容器](/zh/docs/concepts/workloads/pods/init-containers/)的基础知识。
+* 你应该已经[配置好一个 Init 容器](/zh/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/)。
<!-- steps -->
@@ -88,18 +73,14 @@ NAME READY STATUS RESTARTS AGE
See [Understanding Pod status](#understanding-pod-status) for more examples of
status values and their meanings.
-->
-
-更多状态值及其含义请参考[了解 Pod 的状态](#understanding-pod-status)。
+更多状态值及其含义请参考[理解 Pod 的状态](#understanding-pod-status)。
<!--
## Getting details about Init Containers
--->
-## 获取 Init 容器详情
-
-<!--
View more detailed information about Init Container execution:
-->
+## 获取 Init 容器详情 {#getting-details-about-init-containers}
查看 Init 容器运行的更多详情：
@@ -110,8 +91,7 @@ kubectl describe pod <pod-name>
<!--
For example, a Pod with two Init Containers might show the following:
-->
-
-例如，对于包含两个 Init 容器的 Pod 应该显示如下信息：
+例如，对于包含两个 Init 容器的 Pod 可能显示如下信息：
```
Init Containers:
@@ -145,8 +125,7 @@ Init Containers:
You can also access the Init Container statuses programmatically by reading the
`status.initContainerStatuses` field on the Pod Spec:
-->
-
-您还可以通过读取 Pod Spec 上的 `status.initContainerStatuses` 字段以编程方式了解 Init 容器的状态：
+你还可以通过编程方式读取 Pod Spec 上的 `status.initContainerStatuses` 字段，了解 Init 容器的状态：
```shell
kubectl get pod nginx --template '{{.status.initContainerStatuses}}'
@@ -155,21 +134,17 @@ kubectl get pod nginx --template '{{.status.initContainerStatuses}}'
<!--
This command will return the same information as above in raw JSON.
-->
-
此命令将返回与原始 JSON 中相同的信息.
<!--
## Accessing logs from Init Containers
--->
-## 通过 Init 容器访问日志
-
-<!--
Pass the Init Container name along with the Pod name
to access its logs.
-->
+## 通过 Init 容器访问日志 {#accessing-logs-from-init-containers}
-一起传递 Init 容器名称与 Pod 名称来访问它的日志。
+与 Pod 名称一起传递 Init 容器名称，以访问容器的日志。
```shell
kubectl logs <pod-name> -c <init-container-2>
@@ -180,25 +155,19 @@ Init Containers that run a shell script print
commands as they're executed. For example, you can do this in Bash by running
`set -x` at the beginning of the script.
-->
-
-运行 shell 脚本打印命令的init容器,执行 shell 脚本。
-例如，您可以在 Bash 中通过在脚本的开头运行 `set -x` 来实现。
-
-
+运行 Shell 脚本的 Init 容器在执行 Shell 脚本时输出命令本身。
+例如，你可以在 Bash 中通过在脚本的开头运行 `set -x` 来实现。
<!-- discussion -->
<!--
## Understanding Pod status
--->
-## 了解 Pod 的状态
-
-<!--
A Pod status beginning with `Init:` summarizes the status of Init Container
execution. The table below describes some example status values that you might
see while debugging Init Containers.
-->
+## 理解 Pod 的状态 {#understanding-pod-status}
以 `Init:` 开头的 Pod 状态汇总了 Init 容器执行的状态。
下表介绍调试 Init 容器时可能看到的一些状态值示例。
@@ -213,13 +182,11 @@ Status | Meaning
`PodInitializing` or `Running` | The Pod has already finished executing Init Containers.
-->
-状态 | 含义
+状态 | 含义
------ | -------
`Init:N/M` | Pod 包含 `M` 个 Init 容器，其中 `N` 个已经运行完成。
`Init:Error` | Init 容器已执行失败。
-`Init:CrashLoopBackOff` | Init 容器反复执行失败。
+`Init:CrashLoopBackOff` | Init 容器执行总是失败。
`Pending` | Pod 还没有开始执行 Init 容器。
`PodInitializing` or `Running` | Pod 已经完成执行 Init 容器。
-
-
diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
index 671f7cf67a..8f2721eb7a 100644
--- a/content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
+++ b/content/zh/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md
@@ -1,16 +1,12 @@
---
-reviewers:
-- bprashanth
-title: 调试 Pods 和 Replication Controllers
+title: 调试 Pods 和 ReplicationControllers
content_type: task
---
<!--
----
reviewers:
- bprashanth
title: Debug Pods and ReplicationControllers
content_type: task
----
-->
<!-- overview -->
@@ -18,37 +14,31 @@ content_type: task
<!--
This page shows how to debug Pods and ReplicationControllers.
-->
-此页面告诉您如何调试 Pod 和 ReplicationController。
-
+此页面展示如何调试 Pod 和 ReplicationController。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
* You should be familiar with the basics of
[Pods](/docs/concepts/workloads/pods/pod/) and [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/).
-->
-* 您应该先熟悉
- [Pods](/docs/concepts/workloads/pods/pod/) 和 [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/) 的基础概念。
-
-
+* 你应该先熟悉 [Pods](/zh/docs/concepts/workloads/pods/pod/) 和
+ [Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/) 的基础概念。
<!-- steps -->
<!--
## Debugging Pods
--->
-## 调试 Pod
-<!--
The first step in debugging a pod is taking a look at it. Check the current
state of the pod and recent events with the following command:
-->
+## 调试 Pod {#debugging-pods}
-调试一个 pod 的第一步是观察它。使用下面的命令检查这个 pod 的当前状态和最近事件：
+调试一个 pod 的第一步是观察它。使用下面的命令检查 Pod 的当前状态和最近事件：
```shell
kubectl describe pods ${POD_NAME}
@@ -60,14 +50,13 @@ there been recent restarts?
Continue debugging depending on the state of the pods.
-->
-看看 pod 中的容器的状态。他们都是 `Running` 吗？有最近重启了吗？
+看看 Pod 中的容器的状态。它们都是 `Running` 吗？最近有重启吗？
-根据 pod 的状态继续调试。
+根据 Pod 的状态继续调试。
<!--
### My pod stays pending
-->
-### 我的 Pod 卡在 Pending
<!--
If a pod is stuck in `Pending` it means that it can not be scheduled onto a
@@ -76,16 +65,15 @@ another that prevent scheduling. Look at the output of the `kubectl describe
...` command above. There should be messages from the scheduler about why it
can not schedule your pod. Reasons include:
-->
-如果一个 pod 被卡在 `Pending` 状态，就意味着它不能调度在某个节点上。一般来说，这是因为某种类型的资源不足而
-阻止调度。 看看上面的命令 `kubectl describe ...` 的输出。调度器的消息中应该会包含无法调度 Pod 的原因。
+### 我的 Pod 停滞在 Pending 状态
+
+如果 Pod 被卡在 `Pending` 状态，就意味着它不能调度在某个节点上。一般来说，这是因为某种类型的资源不足而
+导致无法调度。 查看上面的命令 `kubectl describe ...` 的输出。调度器的消息中应该会包含无法调度 Pod 的原因。
原因包括：
<!--
#### Insufficient resources
--->
-#### 资源不足
-<!--
You may have exhausted the supply of CPU or Memory in your cluster. In this
case you can try several things:
@@ -102,22 +90,25 @@ case you can try several things:
command. Here are some example command lines that extract just the necessary
information:
-->
-您可能已经耗尽了集群中供应的 CPU 或内存。在这个情况下你可以尝试几件事情：
+#### 资源不足
-* [添加更多节点](/docs/admin/cluster-management/#resizing-a-cluster) 到集群。
+你可能已经耗尽了集群中供应的 CPU 或内存。在这个情况下你可以尝试几件事情：
-* [终止不需要的 pod](/docs/user-guide/pods/single-container/#deleting_a_pod)
- 为 pending 中的 pod 提供空间。
+* [添加更多节点](/zh/docs/tasks/administer-cluster/cluster-management/) 到集群。
-* 检查该 pod 是否不大于您的节点。例如，如果全部节点具有 `cpu:1` 容量，那么具有 `cpu: 1.1` 请求的 pod 永远不会被调度。
+* [终止不需要的 Pod](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
+ 为 Pending 状态的 Pod 提供空间。
- 您可以使用 `kubectl get nodes -o <format>` 命令来检查节点容量。
- 下面是一些能够提取必要信息的命令示例：
+* 检查该 Pod 是否不大于你的节点。例如，如果全部节点具有 `cpu:1` 容量，那么具有
+ 请求为 `cpu: 1.1` 的 Pod 永远不会被调度。
- ```shell
- kubectl get nodes -o yaml | egrep '\sname:|cpu:|memory:'
- kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, cap: .status.capacity}'
- ```
+ 你可以使用 `kubectl get nodes -o <format>` 命令来检查节点容量。
+ 下面是一些能够提取必要信息的命令示例：
+
+ ```shell
+ kubectl get nodes -o yaml | egrep '\sname:|cpu:|memory:'
+ kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, cap: .status.capacity}'
+ ```
<!--
The [resource quota](/docs/concepts/policy/resource-quotas/)
@@ -125,29 +116,26 @@ case you can try several things:
resources that can be consumed. If used in conjunction with namespaces, it can
prevent one team from hogging all the resources.
-->
- 可以考虑配置 [资源配额](/docs/concepts/policy/resource-quotas/) 来限制可耗用的资源总量。如果与命名空间一起使用，它可以防止一个团队吞噬所有的资源。
+ 可以考虑配置[资源配额](/zh/docs/concepts/policy/resource-quotas/) 来限制可耗用的资源总量。
+ 如果与命名空间一起使用，它可以防止一个团队吞噬所有的资源。
<!--
#### Using hostPort
--->
-#### 使用hostPort
-<!--
When you bind a pod to a `hostPort` there are a limited number of places that
the pod can be scheduled. In most cases, `hostPort` is unnecessary; try using a
service object to expose your pod. If you do require `hostPort` then you can
only schedule as many pods as there are nodes in your container cluster.
-->
-当你将一个 pod 绑定到一个 `hostPort` 时，这个 pod 能被调度的位置数量有限。
-在大多数情况下，`hostPort` 是不必要的; 尝试使用服务对象来暴露您的 pod。
+#### 使用hostPort
+
+当你将一个 Pod 绑定到某 `hostPort` 时，这个 Pod 能被调度的位置数量有限。
+在大多数情况下，`hostPort` 是不必要的; 尝试使用服务对象来暴露你的 Pod。
如果你需要 `hostPort`，那么你可以调度的 Pod 数量不能超过集群的节点个数。
<!--
### My pod stays waiting
--->
-### 我的 Pod 一直在 Waiting
-<!--
If a pod is stuck in the `Waiting` state, then it has been scheduled to a
worker node, but it can't run on that machine. Again, the information from
`kubectl describe ...` should be informative. The most common cause of
@@ -158,94 +146,43 @@ worker node, but it can't run on that machine. Again, the information from
* Run a manual `docker pull <image>` on your machine to see if the image can be
pulled.
-->
-如果一个 pod 被卡在 `Waiting` 状态，那么它已被调度在某个工作节点，但它不能在该机器上运行。
-再次，来自 `kubectl describe ...` 的内容应该是可以提供信息的。
-最常见的原因 `Waiting` 的 pod 是无法拉取镜像。有三件事要检查：
+### 我的 Pod 一直在 Waiting
-* 确保您的镜像的名称正确。
-* 您是否将镜像推送到存储库？
-* 在您的机器上手动运行 `docker pull <image>`，看看是否可以拉取镜像。
+如果 Pod 一直停滞在 `Waiting` 状态，那么它已被调度在某个工作节点，但它不能在该机器上运行。
+再次，来自 `kubectl describe ...` 的内容应该是可以是很有用的。
+最常见的原因 `Waiting` 的 Pod 是无法拉取镜像。有三件事要检查：
+* 确保你的镜像的名称正确。
+* 你是否将镜像推送到存储库？
+* 在你的机器上手动运行 `docker pull <image>`，看看是否可以拉取镜像。
<!--
### My pod is crashing or otherwise unhealthy
-First, take a look at the logs of the current container:
-
-```shell
-kubectl logs ${POD_NAME} ${CONTAINER_NAME}
-```
-
-If your container has previously crashed, you can access the previous
-container's crash log with:
-
-```shell
-kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}
-```
-
-Alternately, you can run commands inside that container with `exec`:
-
-```shell
-kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
-```
+Once your pod has been scheduled, the methods described in [Debug Running Pods](
+/docs/tasks/debug-application-cluster/debug-running-pod/) are available for debugging.
-->
-### 我的 Pod 一直 Crashing 或者有别的不健康状态
+### 我的 Pod 一直 Crashing 或者其他不健康状态
-首先，查看当前容器的日志：
-
- $ kubectl logs ${POD_NAME} ${CONTAINER_NAME}
-
-如果您的容器先前已崩溃，则可以访问上一个容器的崩溃日志：
-
- $ kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}
-
-或者，您可以使用 `exec` 在该容器内运行命令：
-
- $ kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
-
-
-<!--
-{{< note >}}
-`-c ${CONTAINER_NAME}` is optional. You can omit it for pods that
-only contain a single container.
-{{< /note >}}
--->
-{{< note >}}
-`-c ${CONTAINER_NAME}` 是可选的，对于只包含一个容器的 pod 可以省略。
-{{< /note >}}
-
-<!--
-As an example, to look at the logs from a running Cassandra pod, you might run:
--->
-例如，要查看正在运行的Cassandra pod的日志，可以运行：
-
-```shell
-kubectl exec cassandra -- cat /var/log/cassandra/system.log
-```
-
-<!--
-If none of these approaches work, you can find the host machine that the pod is
-running on and SSH into that host.
--->
-如果这些方法都不起作用，您可以找到该运行 pod 所在的主机并 SSH 到该主机。
+一旦 Pod 已经被调度，就可以依据
+[调试运行中的 Pod](/zh/docs/tasks/debug-application-cluster/debug-running-pod/)
+展开进一步的调试工作。
<!--
## Debugging ReplicationControllers
--->
-## 调试 Replication Controller
-<!--
ReplicationControllers are fairly straightforward. They can either create pods
or they can't. If they can't create pods, then please refer to the
[instructions above](#debugging-pods) to debug your pods.
-->
-Replication Controller 相当简单。他们只会能或不能创建 pod。如果他们无法创建 pod，那么请参考
-[上面的说明](#debugging_pods) 来调试你的pod。
+## 调试 Replication Controller
+
+Replication Controller 相当简单。它们或者能或者不能创建 Pod。如果它们无法创建 Pod，
+请参考[上面的说明](#debugging_pods) 来调试你的 Pod。
<!--
You can also use `kubectl describe rc ${CONTROLLER_NAME}` to inspect events
related to the replication controller.
-->
-您也可以使用`kubectl describe rc ${CONTROLLER_NAME}`来检查和Replication Controllers有关的事件。
-
+你也可以使用 `kubectl describe rc ${CONTROLLER_NAME}` 来检查和副本控制器有关的事件。
diff --git a/content/zh/docs/tasks/debug-application-cluster/debug-stateful-set.md b/content/zh/docs/tasks/debug-application-cluster/debug-stateful-set.md
index e6ad084295..7131a23a52 100644
--- a/content/zh/docs/tasks/debug-application-cluster/debug-stateful-set.md
+++ b/content/zh/docs/tasks/debug-application-cluster/debug-stateful-set.md
@@ -4,77 +4,54 @@ content_type: task
---
<!-- overview -->
-
-此任务展示如何调试StatefulSet。
-
-
+<!--
+This task shows you how to debug a StatefulSet.
+-->
+此任务展示如何调试 StatefulSet。
## {{% heading "prerequisites" %}}
-
-
-* 你需要有一个Kubernetes集群，通过必要的配置使kubectl命令行工具与您的集群进行通信。
-* 你应该有一个运行中的StatefulSet，以便用于调试。
-
-
+<!--
+* You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster.
+* You should have a StatefulSet running that you want to investigate.
+-->
+* 你需要有一个 Kubernetes 集群，已配置好的 kubectl 命令行工具与你的集群进行通信。
+* 你应该有一个运行中的 StatefulSet，以便用于调试。
<!-- steps -->
-## 调试StatefulSet
+<!--
+## Debugging a StatefulSet
-由于StatefulSet在创建时设置了`app=myapp`标签，列出仅属于该StatefulSet的所有pod时，可以使用以下命令：
+In order to list all the pods which belong to a StatefulSet, which have a label `app=myapp` set on them,
+you can use the following:
+-->
+## 调试 StatefulSet {#debuggin-a-statefulset}
+
+StatefulSet 在创建 Pod 时为其设置了 `app=myapp` 标签，列出仅属于某 StatefulSet
+的所有 Pod 时，可以使用以下命令：
```shell
kubectl get pods -l app=myapp
```
-如果您发现列出的任何Pods长时间处于`Unknown` 或`Terminating`状态，关于如何处理它们的说明任务,请参阅[删除 StatefulSet Pods](/docs/tasks/manage-stateful-set/delete-pods/)。您可以参考[调试 Pods](/docs/user-guide/debugging-pods-and-replication-controllers/#debugging-pods)指南来调试StatefulSet中的各个Pod。
-
-StatefulSets提供调试机制，可以使用注解来暂停所有控制器在Pod上的操作。在任何StatefulSet Pod上设置`pod.alpha.kubernetes.io/initialized`注解为`"false"`将*暂停* StatefulSet的所有操作。暂停时，StatefulSet将不执行任何伸缩操作。一旦调试钩子设置完成后，就可以在StatefulSet pod的容器内执行命令，而不会造成伸缩操作的干扰。您可以通过执行以下命令将注解设置为`"false"`：
-
-```shell
-kubectl annotate pods <pod-name> pod.alpha.kubernetes.io/initialized="false" --overwrite
-```
-
-当注解设置为`"false"`时，StatefulSet在其Pods变得不健康或不可用时将不会响应。StatefulSet不会创建副本Pod直到每个Pod上删除注解或将注解设置为`"true"`。
-
-### 逐步初始化
-
-创建StatefulSet之前，您可以通过使用和上文相同的注解，即将yaml文件中`.spec.template.metadata.annotations`里的`pod.alpha.kubernetes.io/initialized`字段设置为`"false"`，对竞态条件的StatefulSet进行调试。
-
-```yaml
-apiVersion: apps/v1beta1
-kind: StatefulSet
-metadata:
- name: my-app
-spec:
- serviceName: "my-app"
- replicas: 3
- template:
- metadata:
- labels:
- app: my-app
- annotations:
- pod.alpha.kubernetes.io/initialized: "false"
-...
-...
-...
-
-```
-
-设置注解后，如果创建了StatefulSet，您可以等待每个Pod来验证它是否正确初始化。StatefulSet将不会创建任何后续的Pods，直到在已经创建的每个Pod上将调试注解设置为`"true"` (或删除)。 您可以通过执行以下命令将注解设置为`"true"`：
-
-```shell
-kubectl annotate pods <pod-name> pod.alpha.kubernetes.io/initialized="true" --overwrite
-```
-
-
+<!--
+If you find that any Pods listed are in `Unknown` or `Terminating` state for an extended period of time,
+refer to the [Deleting StatefulSet Pods](/docs/tasks/manage-stateful-set/delete-pods/) task for
+instructions on how to deal with them.
+You can debug individual Pods in a StatefulSet using the
+[Debugging Pods](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/) guide.
+-->
+如果你发现列出的任何 Pod 长时间处于 `Unknown` 或 `Terminating` 状态，请参阅
+[删除 StatefulSet Pods](/zh/docs/tasks/manage-stateful-set/delete-pods/)
+了解如何处理它们的说明。
+你可以参考[调试 Pods](/zh/docs/tasks/debug-application-cluster/debug-application/)
+来调试 StatefulSet 中的各个 Pod。
## {{% heading "whatsnext" %}}
-
-点击链接[调试init-container](/docs/tasks/troubleshoot/debug-init-containers/)，了解更多信息。
-
-
-
+<!--
+Learn more about [debugging an init-container](/docs/tasks/debug-application-cluster/debug-init-containers/).
+-->
+* 进一步了解如何[调试 Init 容器](/zh/docs/tasks/debug-application-cluster/debug-init-containers/)
diff --git a/content/zh/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md b/content/zh/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md
index b5d2ac48ae..93c6cfc31c 100644
--- a/content/zh/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md
+++ b/content/zh/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md
@@ -4,10 +4,8 @@ content_type: task
---
<!--
----
title: Determine the Reason for Pod Failure
content_type: task
----
-->
<!-- overview -->
@@ -16,33 +14,24 @@ content_type: task
This page shows how to write and read a Container
termination message.
-->
-
本文介绍如何编写和读取容器的终止消息。
<!--
-Termination messages provide a way for containers to write information about
-fatal events to a location where it can be easily retrieved and surfaced by
-tools like dashboards and monitoring software. In most cases, information that
-you put in a termination message should also be written to the general
+Termination messages provide a way for containers to write information about
+fatal events to a location where it can be easily retrieved and surfaced by
+tools like dashboards and monitoring software. In most cases, information that
+you put in a termination message should also be written to the general
[Kubernetes logs](/docs/concepts/cluster-administration/logging/).
-->
-
-终止消息为容器提供了一种方法，可以将有关致命事件的信息写入某个位置，在该位置可以通过仪表板和监控软件等工具轻松检索和显示致命事件。
-在大多数情况下，您放入终止消息中的信息也应该写入[常规 Kubernetes 日志](/docs/concepts/cluster-administration/logging/)。
-
-
-
-
-
+终止消息为容器提供了一种方法，可以将有关致命事件的信息写入某个位置，
+在该位置可以通过仪表板和监控软件等工具轻松检索和显示致命事件。
+在大多数情况下，您放入终止消息中的信息也应该写入
+[常规 Kubernetes 日志](/zh/docs/concepts/cluster-administration/logging/)。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
-
<!-- steps -->
<!--
@@ -52,7 +41,6 @@ In this exercise, you create a Pod that runs one container.
The configuration file specifies a command that runs when
the container starts.
-->
-
## 读写终止消息
在本练习中，您将创建运行一个容器的 Pod。
@@ -62,59 +50,69 @@ the container starts.
1. <!--Create a Pod based on the YAML configuration file:-->基于 YAML 配置文件创建 Pod：
- kubectl create -f https://k8s.io/examples/debug/termination.yaml
+ ```shell
+ kubectl create -f https://k8s.io/examples/debug/termination.yaml
+ ```
- <!--In the YAML file, in the `cmd` and `args` fields, you can see that the
- container sleeps for 10 seconds and then writes "Sleep expired" to
- the `/dev/termination-log` file. After the container writes
- the "Sleep expired" message, it terminates.-->
- YAML 文件中，在 `cmd` 和 `args` 字段，你可以看到容器休眠 10 秒然后将 "Sleep expired" 写入 `/dev/termination-log` 文件。
- 容器写完 "Sleep expired" 消息后，它就终止了。
+ <!--In the YAML file, in the `cmd` and `args` fields, you can see that the
+ container sleeps for 10 seconds and then writes "Sleep expired" to
+ the `/dev/termination-log` file. After the container writes
+ the "Sleep expired" message, it terminates.-->
+ YAML 文件中，在 `cmd` 和 `args` 字段，你可以看到容器休眠 10 秒然后将 "Sleep expired"
+ 写入 `/dev/termination-log` 文件。
+ 容器写完 "Sleep expired" 消息后就终止了。
1. <!--Display information about the Pod:-->显示 Pod 的信息：
- kubectl get pod termination-demo
+ ```shell
+ kubectl get pod termination-demo
+ ```
- <!--Repeat the preceding command until the Pod is no longer running.-->
- 重复前面的命令直到 Pod 不再运行。
+ <!--Repeat the preceding command until the Pod is no longer running.-->
+ 重复前面的命令直到 Pod 不再运行。
-1. <!--Display detailed information about the Pod:-->显示 Pod 的详细信息：
+1. <!--Display detailed information about the Pod:-->
+ 显示 Pod 的详细信息：
- kubectl get pod --output=yaml
+ ```shell
+ kubectl get pod --output=yaml
+ ```
- <!--The output includes the "Sleep expired" message:-->输出结果包含 "Sleep expired" 消息：
+ <!--The output includes the "Sleep expired" message:-->输出结果包含 "Sleep expired" 消息：
+ ```yaml
+ apiVersion: v1
+ kind: Pod
+ ...
+ lastState:
+ terminated:
+ containerID: ...
+ exitCode: 0
+ finishedAt: ...
+ message: |
+ Sleep expired
+ ...
+ ```
- apiVersion: v1
- kind: Pod
- ...
- lastState:
- terminated:
- containerID: ...
- exitCode: 0
- finishedAt: ...
- message: |
- Sleep expired
- ...
+1. <!--Use a Go template to filter the output so that it includes only the termination message:-->
+ 使用 Go 模板过滤输出结果，使其只含有终止消息：
-1. <!--Use a Go template to filter the output so that it includes only the termination message:-->使用 Go 模板过滤输出结果，使其只含有终止消息：
-
- kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}"
+ ```shell
+ kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}"
+ ```
<!--
## Customizing the termination message
--->
-## 定制终止消息
-
-<!--
Kubernetes retrieves termination messages from the termination message file
specified in the `terminationMessagePath` field of a Container, which as a default
value of `/dev/termination-log`. By customizing this field, you can tell Kubernetes
to use a different file. Kubernetes use the contents from the specified file to
populate the Container's status message on both success and failure.
-->
+## 定制终止消息
-Kubernetes 从容器的 `terminationMessagePath` 字段中指定的终止消息文件中检索终止消息，默认值为 `/dev/termination-log`。
+Kubernetes 从容器的 `terminationMessagePath` 字段中指定的终止消息文件中检索终止消息，
+默认值为 `/dev/termination-log`。
通过定制这个字段，您可以告诉 Kubernetes 使用不同的文件。
Kubernetes 使用指定文件中的内容在成功和失败时填充容器的状态消息。
@@ -122,7 +120,6 @@ Kubernetes 使用指定文件中的内容在成功和失败时填充容器的状
In the following example, the container writes termination messages to
`/tmp/my-log` for Kubernetes to retrieve:
-->
-
在下例中，容器将终止消息写入 `/tmp/my-log` 给 Kubernetes 来接收：
```yaml
@@ -152,11 +149,8 @@ is empty and the container exited with an error. The log output is limited to
通过将 `terminationMessagePolicy` 设置为 "`FallbackToLogsOnError`"，你就可以告诉 Kubernetes，在容器因错误退出时，如果终止消息文件为空，则使用容器日志输出的最后一块作为终止消息。
日志输出限制为 2048 字节或 80 行，以较小者为准。
-
-
## {{% heading "whatsnext" %}}
-
<!--
* See the `terminationMessagePath` field in
[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core).
@@ -164,11 +158,8 @@ is empty and the container exited with an error. The log output is limited to
* Learn about [Go templates](https://golang.org/pkg/text/template/).
-->
-* 参考[容器](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)的 `terminationMessagePath` 字段。
-* 了解[接收日志](/docs/concepts/cluster-administration/logging/)。
+* 参考 [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
+ 资源的 `terminationMessagePath` 字段。
+* 了解[接收日志](/zh/docs/concepts/cluster-administration/logging/)。
* 了解 [Go 模版](https://golang.org/pkg/text/template/)。
-
-
-
-
diff --git a/content/zh/docs/tasks/debug-application-cluster/events-stackdriver.md b/content/zh/docs/tasks/debug-application-cluster/events-stackdriver.md
index 160a99a6a7..04a20a7174 100644
--- a/content/zh/docs/tasks/debug-application-cluster/events-stackdriver.md
+++ b/content/zh/docs/tasks/debug-application-cluster/events-stackdriver.md
@@ -1,19 +1,14 @@
---
-reviewers:
-- piosz
-- x13n
content_type: concept
title: StackDriver 中的事件
---
<!--
----
reviewers:
- piosz
- x13n
content_type: concept
title: Events in Stackdriver
----
-->
<!-- overview -->
@@ -27,8 +22,10 @@ for debugging your application in the [Application Introspection and Debugging
section.
-->
-Kubernetes 事件是一种对象，它为用户提供了洞察集群内发生的事情的能力，例如调度程序做出了什么决定，或者为什么某些 Pod 被逐出节点。
-您可以在[应用程序自检和调试](/docs/tasks/debug-application-cluster/debug-application-introspection/)中阅读有关使用事件调试应用程序的更多信息。
+Kubernetes 事件是一种对象，它为用户提供了洞察集群内发生的事情的能力，
+例如调度程序做出了什么决定，或者为什么某些 Pod 被逐出节点。
+你可以在[应用程序自检和调试](/zh/docs/tasks/debug-application-cluster/debug-application-introspection/)
+中阅读有关使用事件调试应用程序的更多信息。
<!--
Since events are API objects, they are stored in the apiserver on master. To
@@ -37,8 +34,7 @@ removed one hour after the last occurrence. To provide longer history
and aggregation capabilities, a third party solution should be installed
to capture events.
-->
-
-因为事件是 API 对象，所以它们存储在主节点上的 apiserver 中。
+因为事件是 API 对象，所以它们存储在主控节点上的 API 服务器中。
为了避免主节点磁盘空间被填满，将强制执行保留策略：事件在最后一次发生的一小时后将会被删除。
为了提供更长的历史记录和聚合能力，应该安装第三方解决方案来捕获事件。
@@ -46,10 +42,8 @@ to capture events.
This article describes a solution that exports Kubernetes events to
Stackdriver Logging, where they can be processed and analyzed.
-->
-
本文描述了一个将 Kubernetes 事件导出为 Stackdriver Logging 的解决方案，在这里可以对它们进行处理和分析。
-{{< note >}}
<!--
It is not guaranteed that all events happening in a cluster will be
exported to Stackdriver. One possible scenario when events will not be
@@ -58,24 +52,21 @@ upgrade). In most cases it's fine to use events for purposes like setting up
[metrics][sdLogMetrics] and [alerts][sdAlerts], but you should be aware
of the potential inaccuracy.
-->
+{{< note >}}
不能保证集群中发生的所有事件都将导出到 Stackdriver。
事件不能导出的一种可能情况是事件导出器没有运行（例如，在重新启动或升级期间）。
-在大多数情况下，可以将事件用于设置 [metrics][sdLogMetrics] 和 [alerts][sdAlerts] 等目的，但您应该注意潜在的不准确性。
+在大多数情况下，可以将事件用于设置
+[metrics](https://cloud.google.com/logging/docs/view/logs_based_metrics) 和
+[alerts](https://cloud.google.com/logging/docs/view/logs_based_metrics#creating_an_alerting_policy)
+等目的，但你应该注意其潜在的不准确性。
{{< /note >}}
-[sdLogMetrics]: https://cloud.google.com/logging/docs/view/logs_based_metrics
-[sdAlerts]: https://cloud.google.com/logging/docs/view/logs_based_metrics#creating_an_alerting_policy
-
-
-
-
<!-- body -->
<!--
## Deployment
-->
-
-## 部署
+## 部署 {#deployment}
### Google Kubernetes Engine
@@ -91,21 +82,18 @@ average, approximately 100Mb RAM and 100m CPU is needed.
-->
在 Google Kubernetes Engine 中，如果启用了云日志，那么事件导出器默认部署在主节点运行版本为 1.7 及更高版本的集群中。
-为了防止干扰您的工作负载，事件导出器没有设置资源，并且处于尽力而为的 QoS 类型中，这意味着它将在资源匮乏的情况下第一个被杀死。
+为了防止干扰你的工作负载，事件导出器没有设置资源，并且处于尽力而为的 QoS 类型中，这意味着它将在资源匮乏的情况下第一个被杀死。
如果要导出事件，请确保有足够的资源给事件导出器 Pod 使用。
这可能会因为工作负载的不同而有所不同，但平均而言，需要大约 100MB 的内存和 100m 的 CPU。
<!--
### Deploying to the Existing Cluster
--->
-### 部署到现有集群
-
-<!--
Deploy event exporter to your cluster using the following command:
-->
+### 部署到现有集群
-使用下面的命令将事件导出器部署到您的集群：
+使用下面的命令将事件导出器部署到你的集群：
```shell
kubectl create -f https://k8s.io/examples/debug/event-exporter.yaml
@@ -123,27 +111,27 @@ requests. As mentioned earlier, 100Mb RAM and 100m CPU should be enough.
由于事件导出器访问 Kubernetes API，因此它需要权限才能访问。
以下的部署配置为使用 RBAC 授权。
它设置服务帐户和集群角色绑定，以允许事件导出器读取事件。
-为了确保事件导出器 Pod 不会从节点中退出，您可以另外设置资源请求。
+为了确保事件导出器 Pod 不会从节点中退出，你可以另外设置资源请求。
如前所述，100MB 内存和 100m CPU 应该就足够了。
{{< codenew file="debug/event-exporter.yaml" >}}
<!--
## User Guide
--->
-## 用户指南
-
-<!--
Events are exported to the `GKE Cluster` resource in Stackdriver Logging.
You can find them by selecting an appropriate option from a drop-down menu
of available resources:
-->
+## 用户指南 {#user-guide}
事件在 Stackdriver Logging 中被导出到 `GKE Cluster` 资源。
-您可以通过从可用资源的下拉菜单中选择适当的选项来找到它们：
+你可以通过从可用资源的下拉菜单中选择适当的选项来找到它们：
+<!--
<img src="/images/docs/stackdriver-event-exporter-resource.png" alt="Events location in the Stackdriver Logging interface" width="500">
+-->
+<img src="/images/docs/stackdriver-event-exporter-resource.png" alt="Stackdriver 日志接口中事件的位置" width="500">
<!--
You can filter based on the event object fields using Stackdriver Logging
@@ -151,8 +139,9 @@ You can filter based on the event object fields using Stackdriver Logging
For example, the following query will show events from the scheduler
about pods from deployment `nginx-deployment`:
-->
-
-您可以使用 Stackdriver Logging 的[过滤机制](https://cloud.google.com/logging/docs/view/advanced_filters)基于事件对象字段进行过滤。
+你可以使用 Stackdriver Logging 的
+[过滤机制](https://cloud.google.com/logging/docs/view/advanced_filters)
+基于事件对象字段进行过滤。
例如，下面的查询将显示调度程序中有关 Deployment `nginx-deployment` 中的 Pod 的事件：
```
@@ -162,6 +151,6 @@ jsonPayload.source.component="default-scheduler"
jsonPayload.involvedObject.name:"nginx-deployment"
```
-{{< figure src="/images/docs/stackdriver-event-exporter-filter.png" alt="Filtered events in the Stackdriver Logging interface" width="500" >}}
+{{< figure src="/images/docs/stackdriver-event-exporter-filter.png" alt="在 Stackdriver 接口中过滤的事件" width="500" >}}
diff --git a/content/zh/docs/tasks/debug-application-cluster/falco.md b/content/zh/docs/tasks/debug-application-cluster/falco.md
deleted file mode 100644
index 585d044677..0000000000
--- a/content/zh/docs/tasks/debug-application-cluster/falco.md
+++ /dev/null
@@ -1,239 +0,0 @@
----
-reviewers:
-- soltysh
-- sttts
-- ericchiang
-content_type: concept
-title: 使用 Falco 审计
----
-<!--
----
-reviewers:
-- soltysh
-- sttts
-- ericchiang
-content_type: concept
-title: Auditing with Falco
----
--->
-<!-- overview -->
-<!--
-### Use Falco to collect audit events
--->
-### 使用 Falco 采集审计事件
-
-<!--
-[Falco](https://falco.org/) is an open source project for intrusion and abnormality detection for Cloud Native platforms.
-This section describes how to set up Falco, how to send audit events to the Kubernetes Audit endpoint exposed by Falco, and how Falco applies a set of rules to automatically detect suspicious behavior.
--->
-[Falco](https://falco.org/)是一个开源项目，用于为云原生平台提供入侵和异常检测。本节介绍如何设置 Falco、如何将审计事件发送到 Falco 公开的 Kubernetes Audit 端点、以及 Falco 如何应用一组规则来自动检测可疑行为。
-
-
-
-<!-- body -->
-
-<!--
-#### Install Falco
--->
-#### 安装 Falco
-
-<!--
-Install Falco by using one of the following methods:
--->
-使用以下方法安装 Falco ：
-
-<!--
-- [Standalone Falco][falco_installation]
-- [Kubernetes DaemonSet][falco_installation]
-- [Falco Helm Chart][falco_helm_chart]
--->
-- [独立安装 Falco][falco_installation]
-- [Kubernetes DaemonSet][falco_installation]
-- [Falco Helm Chart][falco_helm_chart]
-
-<!--
-Once Falco is installed make sure it is configured to expose the Audit webhook. To do so, use the following configuration:
--->
-安装完成 Falco 后，请确保将其配置为公开 Audit Webhook。为此，请使用以下配置：
-
-```yaml
-webserver:
- enabled: true
- listen_port: 8765
- k8s_audit_endpoint: /k8s_audit
- ssl_enabled: false
- ssl_certificate: /etc/falco/falco.pem
-```
-
-<!--
-This configuration is typically found in the `/etc/falco/falco.yaml` file. If Falco is installed as a Kubernetes DaemonSet, edit the `falco-config` ConfigMap and add this configuration.
--->
-此配置通常位于 `/etc/falco/falco.yaml` 文件中。如果 Falco 作为 Kubernetes DaemonSet 安装，请编辑 `falco-config` ConfigMap 并添加此配置。
-<!--
-#### Configure Kubernetes Audit
--->
-#### 配置 Kubernetes 审计
-
-<!--
-1. Create a [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) for the [kube-apiserver][kube-apiserver] webhook audit backend.
-
- cat <<EOF > /etc/kubernetes/audit-webhook-kubeconfig
- apiVersion: v1
- kind: Config
- clusters:
- - cluster:
- server: http://<ip_of_falco>:8765/k8s_audit
- name: falco
- contexts:
- - context:
- cluster: falco
- user: ""
- name: default-context
- current-context: default-context
- preferences: {}
- users: []
- EOF
--->
-1. 为 [kube-apiserver][kube-apiserver] webhook 审计后端创建一个[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)文件。
-
- cat <<EOF > /etc/kubernetes/audit-webhook-kubeconfig
- apiVersion: v1
- kind: Config
- clusters:
- - cluster:
- server: http://<ip_of_falco>:8765/k8s_audit
- name: falco
- contexts:
- - context:
- cluster: falco
- user: ""
- name: default-context
- current-context: default-context
- preferences: {}
- users: []
- EOF
-<!--
-1. Start [kube-apiserver][kube-apiserver] with the following options:
-
- ```shell
- --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig
- ```
--->
-2. 使用以下选项启动 [kube-apiserver][kube-apiserver]：
-
- ```shell
- --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig
- ```
-<!--
-#### Audit Rules
--->
-#### 审计规则
-
-<!--
-Rules devoted to Kubernetes Audit Events can be found in [k8s_audit_rules.yaml][falco_k8s_audit_rules]. If Audit Rules is installed as a native package or using the official Docker images, Falco copies the rules file to `/etc/falco/`, so they are available for use.
-
-There are three classes of rules.
-
-The first class of rules looks for suspicious or exceptional activities, such as:
--->
-
-专门用于 Kubernetes 审计事件的规则可以在 [k8s_audit_rules.yaml][falco_k8s_audit_rules] 中找到。如果审计规则是作为本机软件包安装或使用官方 Docker 镜像安装的，则 Falco 会将规则文件复制到 `/etc/falco/` 中以便使用。
-
-共有三类规则。
-
-第一类规则用于查找可疑或异常活动，例如：
-
-<!--
-- Any activity by an unauthorized or anonymous user.
-- Creating a pod with an unknown or disallowed image.
-- Creating a privileged pod, a pod mounting a sensitive filesystem from the host, or a pod using host networking.
-- Creating a NodePort service.
-- Creating a ConfigMap containing private credentials, such as passwords and cloud provider secrets.
-- Attaching to or executing a command on a running pod.
-- Creating a namespace external to a set of allowed namespaces.
-- Creating a pod or service account in the kube-system or kube-public namespaces.
-- Trying to modify or delete a system ClusterRole.
-- Creating a ClusterRoleBinding to the cluster-admin role.
-- Creating a ClusterRole with wildcarded verbs or resources. For example, overly permissive.
-- Creating a ClusterRole with write permissions or a ClusterRole that can execute commands on pods.
--->
--未经授权或匿名用户的任何活动。
--创建使用未知或不允许的镜像的 pod。
--创建特权 Pod，从主机安装敏感文件系统的 Pod 或使用主机网络的 Pod。
--创建 NodePort 服务。
--创建包含私有证书（例如密码和云提供商 secrets ）的 ConfigMap。
--在正在运行的 Pod 上附加或执行命令。
--在一组允许的名称空间之外创建一个名称空间。
--在 kube-system 或 kube-public 命名空间中创建 pod 或服务帐户。
--尝试修改或删除系统 ClusterRole。
--创建一个 ClusterRoleBinding 到 cluster-admin 角色。
--创建 ClusterRole 时在动词或资源中使用通配符。 例如，过度赋权。
--创建具有写权限的 ClusterRole 或可以在 Pod 上执行命令的 ClusterRole。
-
-<!--
-A second class of rules tracks resources being created or destroyed, including:
-
-- Deployments
-- Services
-- ConfigMaps
-- Namespaces
-- Service accounts
-- Role/ClusterRoles
-- Role/ClusterRoleBindings
--->
-第二类规则跟踪正在创建或销毁的资源，包括：
-
-- Deployments
-- Services
-- ConfigMaps
-- Namespaces
-- Service accounts
-- Role/ClusterRoles
-- Role/ClusterRoleBindings
-
-<!--
-The final class of rules simply displays any Audit Event received by Falco. This rule is disabled by default, as it can be quite noisy.
-
-For further details, see [Kubernetes Audit Events][falco_ka_docs] in the Falco documentation.
--->
-
-最后一类规则仅负责显示 Falco 收到的所有审核事件。默认情况下，此规则是禁用的，因为它可能会很吵。
-
-有关更多详细信息，请参阅 Falco 文档中的[Kubernetes审计事件][falco_ka_docs]。
-
-<!--
-[kube-apiserver]: /docs/admin/kube-apiserver
-[auditing-proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/auditing.md
-[auditing-api]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go
-[gce-audit-profile]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh#L735
-[kubeconfig]: /docs/tasks/access-application-cluster/configure-access-multiple-clusters/
-[fluentd]: http://www.fluentd.org/
-[fluentd_install_doc]: https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd
-[fluentd_plugin_management_doc]: https://docs.fluentd.org/v1.0/articles/plugin-management
-[logstash]: https://www.elastic.co/products/logstash
-[logstash_install_doc]: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html
-[kube-aggregator]: /docs/concepts/api-extension/apiserver-aggregation
-[falco_website]: https://www.falco.org
-[falco_k8s_audit_rules]: https://github.com/falcosecurity/falco/blob/master/rules/k8s_audit_rules.yaml
-[falco_ka_docs]: https://falco.org/docs/event-sources/kubernetes-audit
-[falco_installation]: https://falco.org/docs/installation
-[falco_helm_chart]: https://github.com/helm/charts/tree/master/stable/falco
--->
-[kube-apiserver]: /docs/admin/kube-apiserver
-[auditing-proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/auditing.md
-[auditing-api]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go
-[gce-audit-profile]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh#L735
-[kubeconfig]: /docs/tasks/access-application-cluster/configure-access-multiple-clusters/
-[fluentd]: http://www.fluentd.org/
-[fluentd_install_doc]: https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd
-[fluentd_plugin_management_doc]: https://docs.fluentd.org/v1.0/articles/plugin-management
-[logstash]: https://www.elastic.co/products/logstash
-[logstash_install_doc]: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html
-[kube-aggregator]: /docs/concepts/api-extension/apiserver-aggregation
-[falco_website]: https://www.falco.org
-[falco_k8s_audit_rules]: https://github.com/falcosecurity/falco/blob/master/rules/k8s_audit_rules.yaml
-[falco_ka_docs]: https://falco.org/docs/event-sources/kubernetes-audit
-[falco_installation]: https://falco.org/docs/installation
-[falco_helm_chart]: https://github.com/falcosecurity/charts/tree/master/falco
-
-
diff --git a/content/zh/docs/tasks/debug-application-cluster/local-debugging.md b/content/zh/docs/tasks/debug-application-cluster/local-debugging.md
index 7414f18e64..99bb4fc56f 100644
--- a/content/zh/docs/tasks/debug-application-cluster/local-debugging.md
+++ b/content/zh/docs/tasks/debug-application-cluster/local-debugging.md
@@ -4,10 +4,8 @@ content_type: task
---
<!--
----
title: Developing and debugging services locally
content_type: task
----
-->
<!-- overview -->
@@ -15,28 +13,25 @@ content_type: task
<!--
Kubernetes applications usually consist of multiple, separate services, each running in its own container. Developing and debugging these services on a remote Kubernetes cluster can be cumbersome, requiring you to [get a shell on a running container](/docs/tasks/debug-application-cluster/get-shell-running-container/) and running your tools inside the remote shell.
-->
-
Kubernetes 应用程序通常由多个独立的服务组成，每个服务都在自己的容器中运行。
-在远端的 Kubernetes 集群上开发和调试这些服务可能很麻烦，需要[在运行的容器上打开 shell](/docs/tasks/debug-application-cluster/get-shell-running-container/)，然后在远端 shell 中运行您所需的工具。
+在远端的 Kubernetes 集群上开发和调试这些服务可能很麻烦，需要
+[在运行的容器上打开 Shell](/zh/docs/tasks/debug-application-cluster/get-shell-running-container/)，
+然后在远端 Shell 中运行你所需的工具。
<!--
`telepresence` is a tool to ease the process of developing and debugging services locally, while proxying the service to a remote Kubernetes cluster. Using `telepresence` allows you to use custom tools, such as a debugger and IDE, for a local service and provides the service full access to ConfigMap, secrets, and the services running on the remote cluster.
-->
-
`telepresence` 是一种工具，用于在本地轻松开发和调试服务，同时将服务代理到远程 Kubernetes 集群。
-使用 `telepresence` 可以为本地服务使用自定义工具（如调试器和 IDE），并提供对 Configmap、Secrets 和远程集群上运行的服务的完全访问。
+使用 `telepresence` 可以为本地服务使用自定义工具（如调试器和 IDE），
+并提供对 Configmap、Secret 和远程集群上运行的服务的完全访问。
<!--
This document describes using `telepresence` to develop and debug services running on a remote cluster locally.
---
-
+-->
本文档描述如何在本地使用 `telepresence` 开发和调试远程集群上运行的服务。
-
-
## {{% heading "prerequisites" %}}
-
<!--
* Kubernetes cluster is installed
* `kubectl` is configured to communicate with the cluster
@@ -47,8 +42,6 @@ This document describes using `telepresence` to develop and debug services runni
* 配置好 `kubectl` 与集群交互
* [Telepresence](https://www.telepresence.io/reference/install) 安装完毕
-
-
<!-- steps -->
<!--
@@ -56,40 +49,39 @@ This document describes using `telepresence` to develop and debug services runni
Open a terminal and run `telepresence` with no arguments to get a `telepresence` shell. This shell runs locally, giving you full access to your local filesystem.
-->
-
-打开终端，不带参数运行 `telepresence`，以打开 `telepresence` shell。这个 shell 在本地运行，使您可以完全访问本地文件系统。
+打开终端，不带参数运行 `telepresence`，以打开 `telepresence` Shell。
+这个 Shell 在本地运行，使你可以完全访问本地文件系统。
<!--
The `telepresence` shell can be used in a variety of ways. For example, write a shell script on your laptop, and run it directly from the shell in real time. You can do this on a remote shell as well, but you might not be able to use your preferred code editor, and the script is deleted when the container is terminated.
Enter `exit` to quit and close the shell.
-->
-
-`telepresence` shell 的使用方式多种多样。
-例如，在你的笔记本电脑上写一个 shell 脚本，然后直接在 shell 中实时运行它。
-您也可以在远端 shell 上执行此操作，但这样可能无法使用首选的代码编辑器，并且在容器终止时脚本将被删除。
+`telepresence` Shell 的使用方式多种多样。
+例如，在你的笔记本电脑上写一个 Shell 脚本，然后直接在 Shell 中实时运行它。
+你也可以在远端 Shell 上执行此操作，但这样可能无法使用首选的代码编辑器，并且在容器终止时脚本将被删除。
<!--
## Developing or debugging an existing service
When developing an application on Kubernetes, you typically program or debug a single service. The service might require access to other services for testing and debugging. One option is to use the continuous deployment pipeline, but even the fastest deployment pipeline introduces a delay in the program or debug cycle.
-->
-
## 开发和调试现有的服务
在 Kubernetes 上开发应用程序时，通常对单个服务进行编程或调试。
服务可能需要访问其他服务以进行测试和调试。
-一种选择是使用连续部署管道，但即使最快的部署管道也会在程序或调试周期中引入延迟。
+一种选择是使用连续部署流水线，但即使最快的部署流水线也会在程序或调试周期中引入延迟。
<!--
Use the `--swap-deployment` option to swap an existing deployment with the Telepresence proxy. Swapping allows you to run a service locally and connect to the remote Kubernetes cluster. The services in the remote cluster can now access the locally running instance.
To run telepresence with `--swap-deployment`, enter:
-->
+使用 `--swap-deployment` 选项将现有部署与 Telepresence 代理交换。
+交换允许你在本地运行服务并能够连接到远端的 Kubernetes 集群。
+远端集群中的服务现在就可以访问本地运行的实例。
-使用 `--swap-deployment` 选项将现有部署与 Telepresence 代理交换。交换允许您在本地运行服务并能够连接到远端的 Kubernetes 集群。远端的集群中的服务现在就可以访问本地运行的实例。
-
-到运行 telepresence 并带有 `--swap-deployment` 选项，请输入：
+要运行 telepresence 并带有 `--swap-deployment` 选项，请输入：
`telepresence --swap-deployment $DEPLOYMENT_NAME`
@@ -98,31 +90,25 @@ where $DEPLOYMENT_NAME is the name of your existing deployment.
Running this command spawns a shell. In the shell, start your service. You can then make edits to the source code locally, save, and see the changes take effect immediately. You can also run your service in a debugger, or any other local development tool.
-->
+这里的 `$DEPLOYMENT_NAME` 是你现有的部署名称。
-这里的 $DEPLOYMENT_NAME 是您现有的部署名称。
-
-运行此命令将生成 shell。在 shell 中，启动您的服务。
-然后，您就可以在本地对源代码进行编辑、保存并能看到更改立即生效。您还可以在调试器或任何其他本地开发工具中运行服务。
-
-
+运行此命令将生成 Shell。在该 Shell 中，启动你的服务。
+然后，你就可以在本地对源代码进行编辑、保存并能看到更改立即生效。
+你还可以在调试器或任何其他本地开发工具中运行服务。
## {{% heading "whatsnext" %}}
-
<!--
If you're interested in a hands-on tutorial, check out [this tutorial](https://cloud.google.com/community/tutorials/developing-services-with-k8s) that walks through locally developing the Guestbook application on Google Kubernetes Engine.
-->
-
-如果您对实践教程感兴趣，请查看[本教程](https://cloud.google.com/community/tutorials/developing-services-with-k8s)，其中介绍了在 Google Kubernetes Engine 上本地开发 Guestbook 应用程序。
+如果你对实践教程感兴趣，请查看[本教程](https://cloud.google.com/community/tutorials/developing-services-with-k8s)，其中介绍了在 Google Kubernetes Engine 上本地开发 Guestbook 应用程序。
<!--
Telepresence has [numerous proxying options](https://www.telepresence.io/reference/methods), depending on your situation.
For further reading, visit the [Telepresence website](https://www.telepresence.io).
-->
-
-Telepresence 有[多种代理选项](https://www.telepresence.io/reference/methods)，以满足您的各种情况。
+Telepresence 有[多种代理选项](https://www.telepresence.io/reference/methods)，以满足你的各种情况。
要了解更多信息，请访问 [Telepresence 网站](https://www.telepresence.io)。
-
diff --git a/content/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md b/content/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
index fce78f5e36..b2532f8a1f 100644
--- a/content/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
+++ b/content/zh/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
@@ -1,19 +1,14 @@
---
-reviewers:
-- piosz
-- x13n
content_type: concept
title: 使用 ElasticSearch 和 Kibana 进行日志管理
---
<!--
----
reviewers:
- piosz
- x13n
content_type: concept
title: Logging Using Elasticsearch and Kibana
----
-->
<!-- overview -->
@@ -23,8 +18,10 @@ On the Google Compute Engine (GCE) platform, the default logging support targets
[Stackdriver Logging](https://cloud.google.com/logging/), which is described in detail
in the [Logging With Stackdriver Logging](/docs/user-guide/logging/stackdriver).
-->
-
-在 Google Compute Engine (GCE) 平台上，默认的日志管理支持目标是 [Stackdriver Logging](https://cloud.google.com/logging/)，在 [使用 Stackdriver Logging 管理日志](/docs/user-guide/logging/stackdriver)中详细描述了这一点。
+在 Google Compute Engine (GCE) 平台上，默认的日志管理支持目标是
+[Stackdriver Logging](https://cloud.google.com/logging/)，
+在[使用 Stackdriver Logging 管理日志](/zh/docs/tasks/debug-application-cluster/logging-stackdriver/)
+中详细描述了这一点。
<!--
This article describes how to set up a cluster to ingest logs into
@@ -32,18 +29,19 @@ This article describes how to set up a cluster to ingest logs into
them using [Kibana](https://www.elastic.co/products/kibana), as an alternative to
Stackdriver Logging when running on GCE.
-->
+本文介绍了如何设置一个集群，将日志导入
+[Elasticsearch](https://www.elastic.co/products/elasticsearch)，并使用
+[Kibana](https://www.elastic.co/products/kibana) 查看日志，作为在 GCE 上
+运行应用时使用 Stackdriver Logging 管理日志的替代方案。
-本文介绍了如何设置一个集群，将日志导入[Elasticsearch](https://www.elastic.co/products/elasticsearch)，并使用 [Kibana](https://www.elastic.co/products/kibana) 查看日志，作为在 GCE 上运行应用时使用 Stackdriver Logging 管理日志的替代方案。
-
-{{< note >}}
<!--
You cannot automatically deploy Elasticsearch and Kibana in the Kubernetes cluster hosted on Google Kubernetes Engine. You have to deploy them manually.
-->
-您不能在 Google Kubernetes Engine 平台运行的 Kubernetes 集群上自动的部署 Elasticsearch 和 Kibana。您必须手动部署它们。
+{{< note >}}
+你不能在 Google Kubernetes Engine 平台运行的 Kubernetes 集群上自动部署
+Elasticsearch 和 Kibana。你必须手动部署它们。
{{< /note >}}
-
-
<!-- body -->
<!--
@@ -51,8 +49,7 @@ To use Elasticsearch and Kibana for cluster logging, you should set the
following environment variable as shown below when creating your cluster with
kube-up.sh:
-->
-
-要使用 Elasticsearch 和 Kibana 处理集群日志，您应该在使用 kube-up.sh 脚本创建集群时设置下面所示的环境变量：
+要使用 Elasticsearch 和 Kibana 处理集群日志，你应该在使用 kube-up.sh 脚本创建集群时设置下面所示的环境变量：
```shell
KUBE_LOGGING_DESTINATION=elasticsearch
@@ -61,18 +58,20 @@ KUBE_LOGGING_DESTINATION=elasticsearch
<!--
You should also ensure that `KUBE_ENABLE_NODE_LOGGING=true` (which is the default for the GCE platform).
-->
-
-您还应该确保设置了 `KUBE_ENABLE_NODE_LOGGING=true` （这是 GCE 平台的默认设置）。
+你还应该确保设置了 `KUBE_ENABLE_NODE_LOGGING=true` （这是 GCE 平台的默认设置）。
<!--
Now, when you create a cluster, a message will indicate that the Fluentd log
collection daemons that run on each node will target Elasticsearch:
-->
-
-现在，当您创建集群时，将有一条消息将指示每个节点上运行的 Fluentd 日志收集守护进程以 ElasticSearch 为日志输出目标：
+现在，当你创建集群时，将有一条消息将指示每个节点上运行的 fluentd 日志收集守护进程
+以 ElasticSearch 为日志输出目标：
```shell
-$ cluster/kube-up.sh
+cluster/kube-up.sh
+```
+
+```
...
Project: kubernetes-satnam
Zone: us-central1-b
@@ -96,11 +95,14 @@ The per-node Fluentd pods, the Elasticsearch pods, and the Kibana pods should
all be running in the kube-system namespace soon after the cluster comes to
life.
-->
-
-每个节点的 Fluentd pod、Elasticsearch pod 和 Kibana pod 都应该在集群启动后不久运行在 kube-system 命名空间中。
+每个节点的 Fluentd Pod、Elasticsearch Pod 和 Kibana Pod 都应该在集群启动后不久运行在
+kube-system 命名空间中。
```shell
-$ kubectl get pods --namespace=kube-system
+kubectl get pods --namespace=kube-system
+```
+
+```
NAME READY STATUS RESTARTS AGE
elasticsearch-logging-v1-78nog 1/1 Running 0 2h
elasticsearch-logging-v1-nj2nb 1/1 Running 0 2h
@@ -122,10 +124,12 @@ Elasticsearch pods store the logs and expose them via a REST API.
The `kibana-logging` pod provides a web UI for reading the logs stored in
Elasticsearch, and is part of a service named `kibana-logging`.
-->
-
-`fluentd-elasticsearch` pod 从每个节点收集日志并将其发送到 `elasticsearch-logging` pods，该 pod 是名为 `elasticsearch-logging` 的[服务](/docs/concepts/services-networking/service/)的一部分。
+`fluentd-elasticsearch` Pod 从每个节点收集日志并将其发送到 `elasticsearch-logging` Pod，
+该 Pod 是名为 `elasticsearch-logging` 的
+[服务](/zh/docs/concepts/services-networking/service/)的一部分。
这些 ElasticSearch pod 存储日志，并通过 REST API 将其公开。
-`kibana-logging` pod 提供了一个用于读取 ElasticSearch 中存储的日志的 Web UI，它是名为 `kibana-logging` 的服务的一部分。
+`kibana-logging` pod 提供了一个用于读取 ElasticSearch 中存储的日志的 Web UI，
+它是名为 `kibana-logging` 的服务的一部分。
<!--
The Elasticsearch and Kibana services are both in the `kube-system` namespace
@@ -134,13 +138,14 @@ follow the instructions for [Accessing services running in a cluster](/docs/conc
-->
Elasticsearch 和 Kibana 服务都位于 `kube-system` 命名空间中，并且没有通过可公开访问的 IP 地址直接暴露。
-要访问它们，请参照[访问集群中运行的服务](/docs/concepts/cluster-administration/access-cluster/#accessing-services-running-on-the-cluster)的说明进行操作。
+要访问它们，请参照
+[访问集群中运行的服务](/zh/docs/tasks/access-application-cluster/access-cluster/#accessing-services-running-on-the-cluster)
+的说明进行操作。
<!--
If you try accessing the `elasticsearch-logging` service in your browser, you'll
see a status page that looks something like this:
-->
-
如果你想在浏览器中访问 `elasticsearch-logging` 服务，你将看到类似下面的状态页面：
@@ -150,7 +155,6 @@ You can now type Elasticsearch queries directly into the browser, if you'd
like. See [Elasticsearch's documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html)
for more details on how to do so.
-->
-
现在你可以直接在浏览器中输入 Elasticsearch 查询，如果你愿意的话。
请参考 [Elasticsearch 的文档](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html) 以了解这样做的更多细节。
@@ -165,11 +169,12 @@ You can set the refresh interval to 5 seconds to have the logs
regularly refreshed.
-->
-或者，您可以使用 Kibana 查看集群的日志（再次使用[访问集群中运行的服务的说明](/docs/user-guide/accessing-the-cluster/#accessing-services-running-on-the-cluster)）。
-第一次访问 Kibana URL 时，将显示一个页面，要求您配置所接收日志的视图。
+或者，你可以使用 Kibana 查看集群的日志（再次使用
+[访问集群中运行的服务的说明](/zh/docs/tasks/access-application-cluster/access-cluster/#accessing-services-running-on-the-cluster)）。
+第一次访问 Kibana URL 时，将显示一个页面，要求你配置所接收日志的视图。
选择时间序列值的选项，然后选择 `@timestamp`。
-在下面的页面中选择 `Discover` 选项卡，然后您应该能够看到所摄取的日志。
-您可以将刷新间隔设置为 5 秒，以便定期刷新日志。
+在下面的页面中选择 `Discover` 选项卡，然后你应该能够看到所摄取的日志。
+你可以将刷新间隔设置为 5 秒，以便定期刷新日志。
<!--
Here is a typical view of ingested logs from the Kibana viewer:
@@ -179,16 +184,12 @@ Here is a typical view of ingested logs from the Kibana viewer:
-
-
## {{% heading "whatsnext" %}}
-
<!--
Kibana opens up all sorts of powerful options for exploring your logs! For some
ideas on how to dig into it, check out [Kibana's documentation](https://www.elastic.co/guide/en/kibana/current/discover.html).
-->
-
-Kibana 为浏览您的日志提供了各种强大的选项！有关如何深入研究它的一些想法，请查看 [Kibana 的文档](https://www.elastic.co/guide/en/kibana/current/discover.html)。
-
+Kibana 为浏览你的日志提供了各种强大的选项！有关如何深入研究它的一些想法，
+请查看 [Kibana 的文档](https://www.elastic.co/guide/en/kibana/current/discover.html)。
diff --git a/content/zh/docs/tasks/debug-application-cluster/monitor-node-health.md b/content/zh/docs/tasks/debug-application-cluster/monitor-node-health.md
index 59cf513428..b34d1040d9 100644
--- a/content/zh/docs/tasks/debug-application-cluster/monitor-node-health.md
+++ b/content/zh/docs/tasks/debug-application-cluster/monitor-node-health.md
@@ -3,18 +3,14 @@ content_type: task
title: 节点健康监测
---
<!--
----
reviewers:
- Random-Liu
- dchen1107
content_type: task
title: Monitor Node Health
----
-->
<!-- overview -->
-
-*节点问题探测器* 是一个 [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) 用来监控节点健康。它从各种守护进程收集节点问题，并以[NodeCondition](/docs/concepts/architecture/nodes/#condition) 和 [Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core) 的形式报告给 apiserver 。
<!--
*Node problem detector* is a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) monitoring the
node health. It collects node problems from various daemons and reports them
@@ -22,6 +18,12 @@ to the apiserver as [NodeCondition](/docs/concepts/architecture/nodes/#condition
and [Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core).
-->
+*节点问题探测器* 是一个 [DaemonSet](/zh/docs/concepts/workloads/controllers/daemonset/)，
+用来监控节点健康。它从各种守护进程收集节点问题，并以
+[NodeCondition](/zh/docs/concepts/architecture/nodes/#condition) 和
+[Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core)
+的形式报告给 API 服务器。
+
<!--
It supports some known kernel issue detection now, and will detect more and
more node problems over time.
@@ -33,7 +35,8 @@ Currently Kubernetes won't take any action on the node conditions and events
generated by node problem detector. In the future, a remedy system could be
introduced to deal with node problems.
-->
-目前，Kubernetes 不会对节点问题检测器监测到的节点状态和事件采取任何操作。将来可能会引入一个补救系统来处理这些节点问题。
+目前，Kubernetes 不会对节点问题检测器监测到的节点状态和事件采取任何操作。
+将来可能会引入一个补救系统来处理这些节点问题。
<!--
See more information
@@ -41,75 +44,71 @@ See more information
-->
更多信息请参阅 [这里](https://github.com/kubernetes/node-problem-detector)。
-
-
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
<!-- steps -->
<!--
## Limitations
--->
-## 局限性
-<!--
* The kernel issue detection of node problem detector only supports file based
kernel log now. It doesn't support log tools like journald.
-->
-* 节点问题检测器的内核问题检测现在只支持基于文件类型的内核日志。 它不支持像 journald 这样的命令行日志工具。
+## 局限性 {#limitations}
+
+* 节点问题检测器的内核问题检测现在只支持基于文件类型的内核日志。
+ 它不支持像 journald 这样的命令行日志工具。
<!--
* The kernel issue detection of node problem detector has assumption on kernel
-log format, and now it only works on Ubuntu and Debian. However, it is easy to extend
-it to [support other log format](/docs/tasks/debug-application-cluster/monitor-node-health/#support-other-log-format).
+ log format, and now it only works on Ubuntu and Debian. However, it is easy to extend
+ it to [support other log format](/docs/tasks/debug-application-cluster/monitor-node-health/#support-other-log-format).
-->
-* 节点问题检测器的内核问题检测对内核日志格式有一定要求，现在它只适用于 Ubuntu 和 Debian。但是，将其扩展为 [支持其它日志格式](/docs/tasks/debug-application-cluster/monitor-node-health/#support-other-log-format) 也很容易。
+* 节点问题检测器的内核问题检测对内核日志格式有一定要求，现在它只适用于 Ubuntu 和 Debian。
+ 不过将其扩展为[支持其它日志格式](#support-other-log-format) 也很容易。
<!--
## Enable/Disable in GCE cluster
--->
-## 在 GCE 集群中启用/禁用
-<!--
Node problem detector is [running as a cluster addon](/docs/setup/cluster-large/#addon-resources) enabled by default in the
gce cluster.
-->
-节点问题检测器在 gce 集群中以[集群插件的形式](/docs/setup/cluster-large/#addon-resources)默认启用。
+## 在 GCE 集群中启用/禁用
+
+节点问题检测器在 gce 集群中以
+[集群插件的形式](/zh/docs/setup/best-practices/cluster-large/#addon-resources)
+默认启用。
<!--
You can enable/disable it by setting the environment variable
`KUBE_ENABLE_NODE_PROBLEM_DETECTOR` before `kube-up.sh`.
-->
-您可以在运行 `kube-up.sh` 之前，以设置环境变量 `KUBE_ENABLE_NODE_PROBLEM_DETECTOR` 的形式启用/禁用它。
+你可以在运行 `kube-up.sh` 之前，以设置环境变量 `KUBE_ENABLE_NODE_PROBLEM_DETECTOR` 的形式启用/禁用它。
<!--
## Use in Other Environment
--->
-## 在其它环境中使用
-<!--
To enable node problem detector in other environment outside of GCE, you can use
either `kubectl` or addon pod.
-->
-要在 GCE 之外的其他环境中启用节点问题检测器，您可以使用 `kubectl` 或插件 pod。
+## 在其它环境中使用 {#use-in-other-environment}
+
+要在 GCE 之外的其他环境中启用节点问题检测器，你可以使用 `kubectl` 或插件 pod。
<!--
### Kubectl
--->
-### Kubectl
-<!--
This is the recommended way to start node problem detector outside of GCE. It
provides more flexible management, such as overwriting the default
configuration to fit it into your environment or detect
customized node problems.
-->
-这是在 GCE 之外启动节点问题检测器的推荐方法。它的管理更加灵活，例如覆盖默认配置以使其适合您的环境或检测自定义节点问题。
+### Kubectl
+
+这是在 GCE 之外启动节点问题检测器的推荐方法。
+它的管理更加灵活，例如覆盖默认配置以使其适合你的环境或检测自定义节点问题。
<!--
* **Step 1:** `node-problem-detector.yaml`:
@@ -118,12 +117,11 @@ customized node problems.
{{< codenew file="debug/node-problem-detector.yaml" >}}
-
<!--
***Notice that you should make sure the system log directory is right for your
OS distro.***
-->
-***请注意保证您的系统日志路径与您的 OS 发行版相对应。***
+***请注意保证你的系统日志路径与你的 OS 发行版相对应。***
<!--
* **Step 2:** Start node problem detector with `kubectl`:
@@ -136,39 +134,40 @@ OS distro.***
<!--
### Addon Pod
--->
-### 插件 Pod
-<!--
This is for those who have their own cluster bootstrap solution, and don't need
to overwrite the default configuration. They could leverage the addon pod to
further automate the deployment.
-->
-这适用于拥有自己的集群引导程序解决方案的用户，并且不需要覆盖默认配置。 他们可以利用插件 Pod 进一步自动化部署。
+### 插件 Pod {#addon-pod}
+
+这适用于拥有自己的集群引导程序解决方案的用户，并且不需要覆盖默认配置。
+他们可以利用插件 Pod 进一步自动化部署。
<!--
Just create `node-problem-detector.yaml`, and put it under the addon pods directory
`/etc/kubernetes/addons/node-problem-detector` on master node.
-->
-只需创建 `node-problem-detector.yaml`，并将其放在主节点上的插件 pod 目录 `/etc/kubernetes/addons/node-problem-detector` 下。
-
+只需创建 `node-problem-detector.yaml`，并将其放在主节点上的插件 pod 目录
+`/etc/kubernetes/addons/node-problem-detector` 下。
<!--
## Overwrite the Configuration
--->
-## 覆盖配置文件
-<!--
The [default configuration](https://github.com/kubernetes/node-problem-detector/tree/v0.1/config)
is embedded when building the docker image of node problem detector.
-->
-构建节点问题检测器的 docker 镜像时，会嵌入[默认配置](https://github.com/kubernetes/node-problem-detector/tree/v0.1/config)。
+## 覆盖配置文件
+
+构建节点问题检测器的 docker 镜像时，会嵌入
+[默认配置](https://github.com/kubernetes/node-problem-detector/tree/v0.1/config)。
<!--
However, you can use [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to overwrite it
following the steps:
-->
-不过，您可以像下面这样使用 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) 将其覆盖：
+不过，你可以像下面这样使用 [ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)
+将其覆盖：
<!--
* **Step 1:** Change the config files in `config/`.
@@ -182,7 +181,6 @@ node-problem-detector-config --from-file=config/`.
{{< codenew file="debug/node-problem-detector-configmap.yaml" >}}
-
<!--
* **Step 4:** Re-create the node problem detector with the new yaml file:
-->
@@ -206,13 +204,12 @@ ConfigMap, configuration overwriting is not supported now.
<!--
## Kernel Monitor
--->
-## 内核监视器
-<!--
*Kernel Monitor* is a problem daemon in node problem detector. It monitors kernel log
and detects known kernel issues following predefined rules.
-->
+## 内核监视器
+
*内核监视器* 是节点问题检测器中的问题守护进程。它监视内核日志并按照预定义规则检测已知内核问题。
<!--
@@ -222,18 +219,17 @@ The rule list is extensible, and you can always extend it by overwriting the
configuration.
-->
内核监视器根据 [`config/kernel-monitor.json`](https://github.com/kubernetes/node-problem-detector/blob/v0.1/config/kernel-monitor.json) 中的一组预定义规则列表匹配内核问题。
-规则列表是可扩展的，您始终可以通过覆盖配置来扩展它。
+规则列表是可扩展的，你始终可以通过覆盖配置来扩展它。
<!--
### Add New NodeConditions
--->
-### 添加新的 NodeCondition
-<!--
To support new node conditions, you can extend the `conditions` field in
`config/kernel-monitor.json` with new condition definition:
-->
-您可以使用新的状态描述来扩展 `config/kernel-monitor.json` 中的 `conditions` 字段以支持新的节点状态。
+### 添加新的 NodeCondition
+
+你可以使用新的状态描述来扩展 `config/kernel-monitor.json` 中的 `conditions` 字段以支持新的节点状态。
```json
{
@@ -245,14 +241,13 @@ To support new node conditions, you can extend the `conditions` field in
<!--
### Detect New Problems
--->
-### 检测新的问题
-<!--
To detect new problems, you can extend the `rules` field in `config/kernel-monitor.json`
with new rule definition:
-->
-您可以使用新的规则描述来扩展 `config/kernel-monitor.json` 中的 `rules` 字段以检测新问题。
+### 检测新的问题
+
+你可以使用新的规则描述来扩展 `config/kernel-monitor.json` 中的 `rules` 字段以检测新问题。
```json
{
@@ -265,42 +260,40 @@ with new rule definition:
<!--
### Change Log Path
--->
-### 更改日志路径
-<!--
Kernel log in different OS distros may locate in different path. The `log`
field in `config/kernel-monitor.json` is the log path inside the container.
You can always configure it to match your OS distro.
-->
-不同操作系统发行版的内核日志的可能不同。 `config/kernel-monitor.json` 中的 `log` 字段是容器内的日志路径。您始终可以修改配置使其与您的 OS 发行版匹配。
+### 更改日志路径
+
+不同操作系统发行版的内核日志的可能不同。 `config/kernel-monitor.json` 中的 `log` 字段是容器内的日志路径。你始终可以修改配置使其与你的 OS 发行版匹配。
<!--
### Support Other Log Format
--->
-### 支持其它日志格式
-<!--
Kernel monitor uses [`Translator`](https://github.com/kubernetes/node-problem-detector/blob/v0.1/pkg/kernelmonitor/translator/translator.go)
plugin to translate kernel log the internal data structure. It is easy to
implement a new translator for a new log format.
-->
-内核监视器使用 [`Translator`] 插件将内核日志转换为内部数据结构。我们可以很容易为新的日志格式实现新的翻译器。
+### 支持其它日志格式 {#support-other-log-format}
+内核监视器使用 [`Translator`] 插件将内核日志转换为内部数据结构。
+我们可以很容易为新的日志格式实现新的翻译器。
<!-- discussion -->
<!--
## Caveats
--->
-## 注意事项
-<!--
It is recommended to run the node problem detector in your cluster to monitor
the node health. However, you should be aware that this will introduce extra
resource overhead on each node. Usually this is fine, because:
-->
-我们建议在集群中运行节点问题检测器来监视节点运行状况。但是，您应该知道这将在每个节点上引入额外的资源开销。一般情况下没有影响，因为：
+## 注意事项 {#caveats}
+
+我们建议在集群中运行节点问题检测器来监视节点运行状况。
+但是，你应该知道这将在每个节点上引入额外的资源开销。一般情况下没有影响，因为：
<!--
* The kernel log is generated relatively slowly.
diff --git a/content/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
index ba7c28b8ad..fb878af5de 100644
--- a/content/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
+++ b/content/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
@@ -1,47 +1,41 @@
---
-reviewers:
-- fgrzadkowski
-- piosz
title: 资源指标管道
content_type: concept
---
<!--
----
reviewers:
- fgrzadkowski
- piosz
title: Resource metrics pipeline
content_type: concept
----
-->
<!-- overview -->
<!--
-Starting from Kubernetes 1.8, resource usage metrics, such as container CPU and memory usage,
+Resource usage metrics, such as container CPU and memory usage,
are available in Kubernetes through the Metrics API. These metrics can be either accessed directly
by user, for example by using `kubectl top` command, or used by a controller in the cluster, e.g.
Horizontal Pod Autoscaler, to make decisions.
-->
-从 Kubernetes 1.8开始，资源使用指标，例如容器 CPU 和内存使用率，可通过 Metrics API 在 Kubernetes 中获得。这些指标可以直接被用户访问，比如使用`kubectl top`命令行，或者这些指标由集群中的控制器使用，例如，Horizontal Pod Autoscaler，使用这些指标来做决策。
-
-
-
+资源使用指标，例如容器 CPU 和内存使用率，可通过 Metrics API 在 Kubernetes 中获得。
+这些指标可以直接被用户访问，比如使用 `kubectl top` 命令行，或者这些指标由集群中的控制器使用，
+例如，Horizontal Pod Autoscaler，使用这些指标来做决策。
<!-- body -->
<!--
## The Metrics API
--->
-## Metrics API
-<!--
Through the Metrics API you can get the amount of resource currently used
by a given node or a given pod. This API doesn't store the metric values,
so it's not possible for example to get the amount of resources used by a
given node 10 minutes ago.
-->
-通过 Metrics API，您可以获得指定节点或 pod 当前使用的资源量。此 API 不存储指标值，因此想要获取某个指定节点10分钟前的资源使用量是不可能的。
+## Metrics API {#the-metrics-api}
+
+通过 Metrics API，你可以获得指定节点或 Pod 当前使用的资源量。
+此 API 不存储指标值，因此想要获取某个指定节点 10 分钟前的资源使用量是不可能的。
<!--
The API is no different from any other API:
@@ -52,15 +46,16 @@ The API is no different from any other API:
- it is discoverable through the same endpoint as the other Kubernetes APIs under `/apis/metrics.k8s.io/` path
- it offers the same security, scalability and reliability guarantees
-->
-- 此 API 和其它 Kubernetes API 一起位于同一端点（endpoint）之下，是可发现的，路径为`/apis/metrics.k8s.io/`
+- 此 API 和其它 Kubernetes API 一起位于同一端点（endpoint）之下，是可发现的，
+ 路径为 `/apis/metrics.k8s.io/`
- 它提供相同的安全性、可扩展性和可靠性保证
<!--
The API is defined in [k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go)
repository. You can find more information about the API there.
-->
-Metrics API 在[k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go)
-仓库中定义。您可以在那里找到有关 Metrics API 的更多信息。
+Metrics API 在 [k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go)
+仓库中定义。你可以在那里找到有关 Metrics API 的更多信息。
<!--
The API requires metrics server to be deployed in the cluster. Otherwise it will be not available.
@@ -70,36 +65,66 @@ Metrics API 需要在集群中部署 Metrics Server。否则它将不可用。
{{< /note >}}
<!--
-## Metrics Server
+## Measuring Resource Usage
+
+### CPU
+
+CPU is reported as the average usage, in [CPU cores](/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu), over a period of time. This value is derived by taking a rate over a cumulative CPU counter provided by the kernel (in both Linux and Windows kernels). The kubelet chooses the window for the rate calculation.
-->
-## Metrics Server
+## 度量资源用量 {#measuring-resource-usage}
+
+### CPU
+
+CPU 用量按其一段时间内的平均值统计，单位为
+[CPU 核](/zh/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu)。
+此度量值通过在内核（包括 Linux 和 Windows）提供的累积 CPU 计数器乘以一个系数得到。
+`kubelet` 组件负责选择计算系数所使用的窗口大小。
+
+### 内存 {#memory}
+
+内存用量按工作集（Working Set）的大小字节数统计，其数值为收集度量值的那一刻的内存用量。
+如果一切都很理想化，“工作集” 是任务在使用的内存总量，该内存是不可以在内存压力较大
+的情况下被释放的。
+不过，具体的工作集计算方式取决于宿主 OS，有很大不同，且通常都大量使用启发式
+规则来给出一个估计值。
+其中包含所有匿名内存使用（没有后台文件提供存储者），因为 Kubernetes 不支持交换分区。
+度量值通常包含一些高速缓存（有后台文件提供存储）内存，因为宿主操作系统并不是总能
+回收这些页面。
<!--
+## Metrics Server
+
[Metrics Server](https://github.com/kubernetes-incubator/metrics-server) is a cluster-wide aggregator of resource usage data.
Starting from Kubernetes 1.8 it's deployed by default in clusters created by `kube-up.sh` script
as a Deployment object. If you use a different Kubernetes setup mechanism you can deploy it using the provided
[deployment yamls](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy).
It's supported in Kubernetes 1.7+ (see details below).
-->
-[Metrics Server](https://github.com/kubernetes-incubator/metrics-server)是集群范围资源使用数据的聚合器。
-从 Kubernetes 1.8开始，它作为 Deployment 对象，被默认部署在由`kube-up.sh`脚本创建的集群中。
-如果您使用不同的 Kubernetes 安装方法，则可以使用提供的[deployment yamls](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy)来部署。它在 Kubernetes 1.7+中得到支持（详见下文）。
+## Metrics 服务器 {#metrics-server}
+
+[Metrics 服务器](https://github.com/kubernetes-incubator/metrics-server)是集群范围资源使用数据的聚合器。
+在由 `kube-up.sh` 脚本创建的集群中默认会以 Deployment 的形式被部署。
+如果你使用其他 Kubernetes 安装方法，则可以使用提供的
+[deployment yamls](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy)
+来部署。
<!--
Metric server collects metrics from the Summary API, exposed by [Kubelet](/docs/admin/kubelet/) on each node.
-->
-Metric server 从每个节点上的 [Kubelet](/docs/admin/kubelet/) 公开的 Summary API 中采集指标信息。
+Metric server 从每个节点上的 [Kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/)
+公开的 Summary API 中采集指标信息。
<!--
Metrics Server registered in the main API server through
[Kubernetes aggregator](/docs/concepts/api-extension/apiserver-aggregation/),
which was introduced in Kubernetes 1.7.
-->
-通过在主 API server 中注册的 Metrics Server [Kubernetes 聚合器](/docs/concepts/api-extension/apiserver-aggregation/) 来采集指标信息， 这是在 Kubernetes 1.7 中引入的。
+Metrics 服务器通过
+[Kubernetes 聚合器](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+注册到主 API 服务器。
<!--
Learn more about the metrics server in [the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md).
-->
-在[设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)中可以了解到有关 Metrics Server 的更多信息。
-
+在[设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)中可以了解到有关 Metrics 服务器的更多信息。
diff --git a/content/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/content/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
index a91705008b..9ed63ffa71 100644
--- a/content/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
+++ b/content/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring.md
@@ -1,16 +1,12 @@
---
-reviewers:
-- mikedanese
content_type: concept
title: 资源监控工具
---
<!--
----
reviewers:
- mikedanese
content_type: concept
title: Tools for Monitoring Resources
----
-->
<!-- overview -->
@@ -25,12 +21,12 @@ information about an application's resource usage at each of these levels.
This information allows you to evaluate your application's performance and
where bottlenecks can be removed to improve overall performance.
-->
-要扩展应用程序并提供可靠的服务，您需要了解应用程序在部署时的行为。
-您可以通过检测容器检查 Kubernetes 集群中的应用程序性能，[pods](/docs/user-guide/pods), [服务](/docs/user-guide/services)和整个集群的特征。
+要扩展应用程序并提供可靠的服务，你需要了解应用程序在部署时的行为。
+你可以通过检测容器检查 Kubernetes 集群中的应用程序性能，
+[Pods](/zh/docs/concepts/workloads/pods), [服务](/zh/docs/concepts/services-networking/service/)
+和整个集群的特征。
Kubernetes 在每个级别上提供有关应用程序资源使用情况的详细信息。
-此信息使您可以评估应用程序的性能，以及在何处可以消除瓶颈以提高整体性能。
-
-
+此信息使你可以评估应用程序的性能，以及在何处可以消除瓶颈以提高整体性能。
<!-- body -->
@@ -38,22 +34,26 @@ Kubernetes 在每个级别上提供有关应用程序资源使用情况的详细
In Kubernetes, application monitoring does not depend on a single monitoring solution. On new clusters, you can use [resource metrics](#resource-metrics-pipeline) or [full metrics](#full-metrics-pipeline) pipelines to collect monitoring statistics.
-->
在 Kubernetes 中，应用程序监控不依赖单个监控解决方案。
-在新集群上，您可以使用[资源度量](#资源度量管道)或[完整度量](#完整度量管道)管道来收集监视统计信息。
+在新集群上，你可以使用[资源度量](#resource-metrics-pipeline)或
+[完整度量](#full-metrics-pipeline)管道来收集监视统计信息。
<!--
## Resource metrics pipeline
--->
-## 资源度量管道
-<!--
The resource metrics pipeline provides a limited set of metrics related to
cluster components such as the [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale) controller, as well as the `kubectl top` utility.
These metrics are collected by the lightweight, short-term, in-memory
[metrics-server](https://github.com/kubernetes-incubator/metrics-server) and
are exposed via the `metrics.k8s.io` API.
-->
-资源指标管道提供了一组与集群组件，例如[Horizontal Pod Autoscaler]控制器(/docs/tasks/run-application/horizontal-pod-autoscale)，以及 `kubectl top` 实用程序相关的有限度量。
-这些指标是由轻量级的、短期内存[度量服务器](https://github.com/kubernetes-incubator/metrics-server)收集的，通过 `metrics.k8s.io` 公开。
+## 资源度量管道 {#resource-metrics-pipeline}
+
+资源指标管道提供了一组与集群组件，例如
+[Horizontal Pod Autoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/)控制器，
+以及 `kubectl top` 实用程序相关的有限度量。
+这些指标是由轻量级的、短期、内存存储的
+[度量服务器](https://github.com/kubernetes-incubator/metrics-server)收集的，
+通过 `metrics.k8s.io` 公开。
<!--
metrics-server discovers all nodes on the cluster and
@@ -69,7 +69,8 @@ resource usage statistics through the metrics-server Resource Metrics API.
This API is served at `/metrics/resource/v1beta1` on the kubelet's authenticated and
read-only ports.
-->
-度量服务器发现集群中的所有节点，并且查询每个节点的[kubelet](/docs/reference/command-line-tools-reference/kubelet)以获取 CPU 和内存使用情况。
+度量服务器发现集群中的所有节点，并且查询每个节点的
+[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet)以获取 CPU 和内存使用情况。
Kubelet 充当 Kubernetes 主节点与节点之间的桥梁，管理机器上运行的 Pod 和容器。
kubelet 将每个 pod 转换为其组成的容器，并在容器运行时通过容器运行时界面获取各个容器使用情况统计信息。
kubelet 从集成的 cAdvisor 获取此信息，以进行旧式 Docker 集成。
@@ -78,10 +79,7 @@ kubelet 从集成的 cAdvisor 获取此信息，以进行旧式 Docker 集成。
<!--
## Full metrics pipeline
--->
-## 完整度量管道
-<!--
A full metrics pipeline gives you access to richer metrics. Kubernetes can
respond to these metrics by automatically scaling or adapting the cluster
based on its current state, using mechanisms such as the Horizontal Pod
@@ -89,17 +87,18 @@ Autoscaler. The monitoring pipeline fetches metrics from the kubelet and
then exposes them to Kubernetes via an adapter by implementing either the
`custom.metrics.k8s.io` or `external.metrics.k8s.io` API.
-->
-一个完整度量管道可以让您访问更丰富的度量。
+## 完整度量管道 {#full-metrics-pipeline}
+
+一个完整度量管道可以让你访问更丰富的度量。
Kubernetes 还可以根据集群的当前状态，使用 Pod 水平自动扩缩器等机制，通过自动调用扩展或调整集群来响应这些度量。
-监控管道从 kubelet 获取度量，然后通过适配器将它们公开给 Kubernetes，方法是实现 `custom.metrics.k8s.io` 或 `external.metrics.k8s.io` API。
+监控管道从 kubelet 获取度量值，然后通过适配器将它们公开给 Kubernetes，
+方法是实现 `custom.metrics.k8s.io` 或 `external.metrics.k8s.io` API。
<!--
[Prometheus](https://prometheus.io), a CNCF project, can natively monitor Kubernetes, nodes, and Prometheus itself.
Full metrics pipeline projects that are not part of the CNCF are outside the scope of Kubernetes documentation.
-->
-[Prometheus](https://prometheus.io)，一个 CNCF 项目，可以原生监控 Kubernetes、节点和
+[Prometheus](https://prometheus.io) 是一个 CNCF 项目，可以原生监控 Kubernetes、节点和
Prometheus 本身。
完整度量管道项目不属于 CNCF 的一部分，不在 Kubernetes 文档的范围之内。
-
-
diff --git a/content/zh/docs/tasks/debug-application-cluster/troubleshooting.md b/content/zh/docs/tasks/debug-application-cluster/troubleshooting.md
index 396e7ffc59..4b7ff235ff 100644
--- a/content/zh/docs/tasks/debug-application-cluster/troubleshooting.md
+++ b/content/zh/docs/tasks/debug-application-cluster/troubleshooting.md
@@ -7,13 +7,11 @@ title: 排错
---
<!--
----
reviewers:
- brendandburns
- davidopp
content_type: concept
title: Troubleshooting
----
-->
<!-- overview -->
@@ -22,26 +20,21 @@ title: Troubleshooting
Sometimes things go wrong. This guide is aimed at making them right. It has
two sections:
-->
-
-有时候事情会出错。本指南旨在正确解决这些问题。它包含两个部分：
+有时候事情会出错。本指南旨在解决这些问题。它包含两个部分：
<!--
* [Troubleshooting your application](/docs/tasks/debug-application-cluster/debug-application/) - Useful for users who are deploying code into Kubernetes and wondering why it is not working.
* [Troubleshooting your cluster](/docs/tasks/debug-application-cluster/debug-cluster/) - Useful for cluster administrators and people whose Kubernetes cluster is unhappy.
-->
- * [应用排错](/docs/tasks/debug-application-cluster/debug-application/) - 用于部署代码到 Kubernetes 并想知道代码为什么不能正常运行的用户。
- * [集群排错](/docs/tasks/debug-application-cluster/debug-cluster/) - 用于集群管理员以及 Kubernetes 集群表现异常的用户。
+* [应用排错](/zh/docs/tasks/debug-application-cluster/debug-application/) - 用于部署代码到 Kubernetes 并想知道代码为什么不能正常运行的用户。
+* [集群排错](/zh/docs/tasks/debug-application-cluster/debug-cluster/) - 用于集群管理员以及 Kubernetes 集群表现异常的用户。
<!--
You should also check the known issues for the [release](https://github.com/kubernetes/kubernetes/releases)
you're using.
-->
-
-您也应该查看所用[版本](https://github.com/kubernetes/kubernetes/releases)的已知问题。
-
-
-
+你也应该查看所用[发行版本](https://github.com/kubernetes/kubernetes/releases)的已知问题。
<!-- body -->
@@ -51,10 +44,9 @@ you're using.
If your problem isn't answered by any of the guides above, there are variety of
ways for you to get help from the Kubernetes team.
-->
+## 获取帮助 {#getting-help}
-## 获取帮助
-
-如果您的问题在上述指南中没有得到答案，您还有另外几种方式从 Kubernetes 团队获得帮助。
+如果你的问题在上述指南中没有得到答案，你还有另外几种方式从 Kubernetes 团队获得帮助。
<!--
### Questions
@@ -69,45 +61,44 @@ development scenarios. The [Reference](/docs/reference/) section provides
detailed documentation on the [Kubernetes API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
and command-line interfaces (CLIs), such as [`kubectl`](/docs/user-guide/kubectl-overview/).
-->
-
### 提问
-网站上的文档针对回答各类问题进行了结构化组织和分类。
-[概念](/docs/concepts/)部分解释了 Kubernetes 体系结构以及每个组件的工作方式，[安装](/docs/setup/)部分提供了入门的实用说明。
-[任务](/docs/tasks/)部分展示了如何完成常用任务，[入门](/docs/tutorials/)部分则是对现实世界、特定行业或端到端开发场景的更全面的演练。
-[参考](/docs/reference/)部分提供了详细的 [Kubernetes API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 文档和命令行 (CLI) 接口，例如[`kubectl`](/docs/user-guide/kubectl-overview/)。
+本网站上的文档针对回答各类问题进行了结构化组织和分类。
+[概念](/zh/docs/concepts/)部分解释 Kubernetes 体系结构以及每个组件的工作方式，
+[安装](/zh/docs/setup/)部分提供了安装的实用说明。
+[任务](/zh/docs/tasks/)部分展示了如何完成常用任务，
+[教程](/zh/docs/tutorials/)部分则提供对现实世界、特定行业或端到端开发场景的更全面的演练。
+[参考](/zh/docs/reference/)部分提供了详细的
+[Kubernetes API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 文档
+和命令行 (CLI) 接口的文档，例如[`kubectl`](/zh/docs/reference/kubectl/overview/)。
<!--
You may also find the Stack Overflow topics relevant:
-->
+你还在 StackOverflow 上查找相关主题：
-您还可以找到堆栈溢出相关的主题：
-
- * [Kubernetes](http://stackoverflow.com/questions/tagged/kubernetes)
- * [Google Kubernetes Engine](http://stackoverflow.com/questions/tagged/google-container-engine)
+* [Kubernetes](https://stackoverflow.com/questions/tagged/kubernetes)
+* [Google Kubernetes Engine](https://stackoverflow.com/questions/tagged/google-container-engine)
<!--
## Help! My question isn't covered! I need help now!
-->
-
## 求救！我的问题还没有解决！我需要立即得到帮助！
<!--
### Stack Overflow
--->
-### 堆栈溢出
-
-<!--
Someone else from the community may have already asked a similar question or may
be able to help with your problem. The Kubernetes team will also monitor
-[posts tagged Kubernetes](http://stackoverflow.com/questions/tagged/kubernetes).
-If there aren't any existing questions that help, please [ask a new one](http://stackoverflow.com/questions/ask?tags=kubernetes)!
+[posts tagged Kubernetes](https://stackoverflow.com/questions/tagged/kubernetes).
+If there aren't any existing questions that help, please
+[ask a new one](https://stackoverflow.com/questions/ask?tags=kubernetes)!
-->
+### StackOverflow {#stack-overflow}
-社区中的其他人可能已经问过和您类似的问题，这或许能帮助解决您的问题。
-Kubernetes 团队还会监视[带有 Kubernetes 标签的帖子](http://stackoverflow.com/questions/tagged/kubernetes)。
-如果现有的问题对您没有帮助，请[问一个新问题](http://stackoverflow.com/questions/ask?tags=kubernetes)!
+社区中的其他人可能已经问过和你类似的问题，也可能能够帮助解决你的问题。
+Kubernetes 团队还会监视[带有 Kubernetes 标签的帖子](https://stackoverflow.com/questions/tagged/kubernetes)。
+如果现有的问题对你没有帮助，请[问一个新问题](https://stackoverflow.com/questions/ask?tags=kubernetes)!
<!--
### Slack
@@ -115,16 +106,15 @@ Kubernetes 团队还会监视[带有 Kubernetes 标签的帖子](http://stackove
The Kubernetes team hangs out on Slack in the `#kubernetes-users` channel. You
can participate in discussion with the Kubernetes team [here](https://kubernetes.slack.com).
Slack requires registration, but the Kubernetes team is open invitation to
-anyone to register [here](http://slack.kubernetes.io). Feel free to come and ask
+anyone to register [here](https://slack.kubernetes.io). Feel free to come and ask
any and all questions.
-->
-
### Slack
Kubernetes 团队在 Slack 中建有 `#kubernetes-users` 频道。
-您可以[在这里](https://kubernetes.slack.com)参加与 Kubernetes 团队的讨论。
-Slack 需要注册，但 Kubernetes 团队公开邀请任何人[在这里](http://slack.kubernetes.io)注册。
-欢迎您随时来问任何问题。
+你可以[在这里](https://kubernetes.slack.com)参与 Kubernetes 团队的讨论。
+Slack 需要注册，但 Kubernetes 团队公开邀请任何人[在这里](https://slack.kubernetes.io)注册。
+欢迎你随时来问任何问题。
<!--
Once registered, browse the growing list of channels for various subjects of
@@ -132,15 +122,14 @@ interest. For example, people new to Kubernetes may also want to join the
`#kubernetes-novice` channel. As another example, developers should join the
`#kubernetes-dev` channel.
-->
-
-一旦注册完成，您就可以浏览各种感兴趣的频道列表。
-例如，Kubernetes 新人可能还想加入 `#kubernetes-novice` 频道。作为另一个例子，开发人员应该加入 `#kubernetes-dev` 频道。
+一旦注册完成，你就可以浏览各种感兴趣的频道列表。
+例如，Kubernetes 新人可能还想加入 `#kubernetes-novice` 频道。
+又比如，开发人员应该加入 `#kubernetes-dev` 频道。
<!--
There are also many country specific/local language channels. Feel free to join
these channels for localized support and info:
-->
-
还有许多国家/地区语言频道。请随时加入这些频道以获得本地化支持和信息：
<!--
@@ -158,7 +147,6 @@ these channels for localized support and info:
- Spain: `#es-users`
- Turkey: `#tr-users`, `#tr-events`
-->
-
- 中国： `#cn-users`, `#cn-events`
- 法国： `#fr-users`, `#fr-events`
- 德国： `#de-users`, `#de-events`
@@ -179,21 +167,20 @@ these channels for localized support and info:
The Kubernetes Official Forum [discuss.kubernetes.io](https://discuss.kubernetes.io)
-->
-
-### 论坛
+### 论坛 {#forum}
Kubernetes 官方论坛 [discuss.kubernetes.io](https://discuss.kubernetes.io)
-
<!--
### Bugs and Feature requests
If you have what looks like a bug, or you would like to make a feature request,
please use the [Github issue tracking system](https://github.com/kubernetes/kubernetes/issues).
-->
+### Bugs 和功能请求（Feature Request）
-如果你发现一个看起来像 bug 的东西，或者你想提出一个功能请求，请使用[Github 问题跟踪系统](https://github.com/kubernetes/kubernetes/issues)。
-
+如果你发现一个看起来像 Bug 的问题，或者你想提出一个功能请求，请使用
+[Github 问题跟踪系统](https://github.com/kubernetes/kubernetes/issues)。
<!--
Before you file an issue, please search existing issues to see if your issue is
@@ -202,19 +189,17 @@ already covered.
If filing a bug, please include detailed information about how to reproduce the
problem, such as:
-->
+在提交问题之前，请搜索现有问题以查看是否其中已涵盖你的问题。
-在提交问题之前，请搜索现有问题以查看是否已涵盖您的问题。
-
-如果提交 bug，请提供如何重现问题的详细信息，例如：
+如果提交 Bug，请提供如何重现问题的详细信息，例如：
<!--
* Kubernetes version: `kubectl version`
* Cloud provider, OS distro, network configuration, and Docker version
* Steps to reproduce the problem
-->
-
* Kubernetes 版本：获取版本的命令为 `kubectl version`
-* 云提供商，OS 发行版、网络配置和 Docker 版本
+* 云提供商、OS 发行版、网络配置和 Docker 版本
* 重现问题的步骤
diff --git a/content/zh/docs/tasks/example-task-template.md b/content/zh/docs/tasks/example-task-template.md
deleted file mode 100644
index e3cf46734f..0000000000
--- a/content/zh/docs/tasks/example-task-template.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: 示例任务的模板
-reviewers:
-- chenopis
-content_type: task
-toc_hide: true
----
-
-<!--
----
-title: Example Task Template
-reviewers:
-- chenopis
-content_type: task
-toc_hide: true
----
--->
-
-<!-- overview -->
-
-<!--
-Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document.
--->
-
-{{< note >}}
-还要确保为新文档[在目录中创建一个条目](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents)。
-{{< /note >}}
-
-<!--
-This page shows how to ...
--->
-这个页面展示了如何...
-
-
-
-## {{% heading "prerequisites" %}}
-
-
-<!--
-* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-* Do this.
-* Do this too.
--->
-
-
-* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-* 做这个。
-* 也做这个。
-
-
-
-<!-- steps -->
-
-<!--
-## Doing ...
--->
-
-## 做...
-
-<!--
-1. Do this.
-1. Do this next. Possibly read this [related explanation](...).
--->
-
-1. 做这个。
-1. 接下来做这个。可能需要阅读一下这个[相关解释](...).
-
-
-
-<!-- discussion -->
-
-<!--
-## Understanding ...
-**[Optional Section]**
--->
-
-## 理解 ...
-
-**[可选部分]**
-
-<!--
-Here's an interesting thing to know about the steps you just did.
--->
-关于你刚才所做的过程，有一点是需要知道的。
-
-
-
-## {{% heading "whatsnext" %}}
-
-
-<!--
-**[Optional Section]**
--->
-
-**[可选部分]**
-
-<!--
-* Learn more about [Writing a New Topic](/docs/home/contribute/write-new-topic/).
-* See [Using Page Templates - Task template](/docs/home/contribute/page-templates/#task_template) for how to use this template.
--->
-
-* 了解更多关于[撰写新主题](/docs/home/contribute/write-new-topic/).
-* 查看[使用页面模板-任务模板](/docs/home/contribute/page-templates/#task_template) for how to use this template.
-
-
-
-
diff --git a/content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md b/content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md
index c22481b71c..bba139ae1d 100644
--- a/content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md
+++ b/content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md
@@ -1,9 +1,7 @@
---
title: 用插件扩展 kubectl
-reviewers:
-- juanvallejo
-- soltysh
-description: 使用 kubectl 插件，你可以通过添加新的子命令来扩展 kubectl 命令的功能。
+description: 通过创建和安装 kubectl 插件扩展 kubectl
+content_type: task
---
<!--
@@ -11,76 +9,69 @@ title: Extend kubectl with plugins
reviewers:
- juanvallejo
- soltysh
-description: With kubectl plugins, you can extend the functionality of the kubectl command by adding new subcommands.
+description: Extend kubectl by creating and installing kubectl plugins.
content_type: task
-->
<!-- overview -->
-{{< feature-state state="stable" >}}
-
<!--
This guide demonstrates how to install and write extensions for [kubectl](/docs/reference/kubectl/kubectl/). By thinking of core `kubectl` commands as essential building blocks for interacting with a Kubernetes cluster, a cluster administrator can think
of plugins as a means of utilizing these building blocks to create more complex behavior. Plugins extend `kubectl` with new sub-commands, allowing for new and custom features not included in the main distribution of `kubectl`.
-->
-本指南演示了如何为 [kubectl](/docs/reference/kubectl/kubectl/) 安装和编写扩展。
-通过将核心 `kubectl` 命令看作与 Kubernetes 集群交互的基本构建块，集群管理员可以将插件视为一种利用这些构建块创建更复杂行为的方法。
+本指南演示了如何为 [kubectl](/zh/docs/reference/kubectl/kubectl/) 安装和编写扩展。
+通过将核心 `kubectl` 命令看作与 Kubernetes 集群交互的基本构建块，
+集群管理员可以将插件视为一种利用这些构建块创建更复杂行为的方法。
插件用新的子命令扩展了 `kubectl`，允许新的和自定义的特性不包括在 `kubectl` 的主要发行版中。
-
-
## {{% heading "prerequisites" %}}
-
<!--
You need to have a working `kubectl` binary installed.
-->
-您需要安装一个工作的二进制 `kubectl`。
-
-{{< note >}}
-
-<!--
-Plugins were officially introduced as an alpha feature in the v1.8.0 release. They have been re-worked in the v1.12.0 release to support a wider range of use-cases. So, while some parts of the plugins feature were already available in previous versions, a `kubectl` version of 1.12.0 or later is recommended if you are following these docs.
--->
-插件在 v1.8.0 版本中正式作为 alpha 特性引入。它们已经在 v1.12.0 版本中工作，以支持更广泛的用例。因此，虽然在以前的版本中已经提供了部分插件特性，但如果您遵循这些文档，建议使用 1.12.0 或更高版本的 `kubectl`。
-
-{{< /note >}}
-
-
+你需要安装一个可用的 `kubectl` 可执行文件。
<!-- steps -->
<!--
## Installing kubectl plugins
--->
-## 安装 kubectl 插件
-
-<!--
A plugin is nothing more than a standalone executable file, whose name begins with `kubectl-`. To install a plugin, simply move this executable file to anywhere on your PATH.
-->
-插件只不过是一个独立的可执行文件，名称以 `kubectl-` 开头。要安装插件，只需将此可执行文件移动到路径上的任何位置。
+## 安装 kubectl 插件
-{{< note >}}
+插件只不过是一个独立的可执行文件，名称以 `kubectl-` 开头。
+要安装插件，只需将此可执行文件移动到 PATH 中的任何位置。
<!--
-Kubernetes does not provide a package manager or anything similar to install or update plugins. It is your responsibility to ensure that plugin executables have a filename that begins with `kubectl-`, and that they are placed somewhere on your PATH.
+You can also discover and install kubectl plugins available in the open source
+using [Krew](https://krew.dev/). Krew is a plugin manager maintained by
+the Kubernetes SIG CLI community.
-->
-Kubernetes 不提供包管理器或任何类似于安装或更新插件的东西。你有责任确保插件可执行文件的文件名以 `kubectl-` 开头，并将它们放在你路径的某个位置。
-{{< /note >}}
+你也可以使用 [Krew](https://krew.dev/) 来发现和安装开源的 kubectl 插件。
+Krew 是一个由 Kubernetes SIG CLI 社区维护的插件管理器。
+
+<!--
+Kubectl plugins available via the Krew [plugin index](https://index.krew.dev/)
+are not audited for security. You should install and run third-party plugins at your
+own risk, since they are arbitrary programs running on your machine.
+-->
+{{< caution >}}
+Krew [插件索引](https://index.krew.dev/)所维护的 kubectl 插件并未经过安全性审查。
+你要了解安装和运行第三方插件的安全风险，因为它们本质上时是一些在你的机器上
+运行的程序。
+{{< /caution >}}
<!--
### Discovering plugins
--->
-### 发现插件
-
-<!--
`kubectl` provides a command `kubectl plugin list` that searches your PATH for valid plugin executables.
Executing this command causes a traversal of all files in your PATH. Any files that are executable, and begin with `kubectl-` will show up *in the order in which they are present in your PATH* in this command's output.
A warning will be included for any files beginning with `kubectl-` that are *not* executable.
A warning will also be included for any valid plugin files that overlap each other's name.
-->
+### 发现插件
+
`kubectl` 提供一个命令 `kubectl plugin list`，用于搜索路径查找有效的插件可执行文件。
执行此命令将遍历路径中的所有文件。任何以 `kubectl-` 开头的可执行文件都将在这个命令的输出中以它们在路径中出现的顺序显示。
任何以 `kubectl-` 开头的文件如果`不可执行`，都将包含一个警告。
@@ -88,52 +79,58 @@ A warning will also be included for any valid plugin files that overlap each oth
<!--
#### Limitations
--->
+It is currently not possible to create plugins that overwrite existing `kubectl` commands. For example, creating a plugin `kubectl-version` will cause that plugin to never be executed, as the existing `kubectl version` command will always take precedence over it. Due to this limitation, it is also *not* possible to use plugins to add new subcommands to existing `kubectl` commands. For example, adding a subcommand `kubectl create foo` by naming your plugin `kubectl-create-foo` will cause that plugin to be ignored.
+
+`kubectl plugin list` shows warnings for any valid plugins that attempt to do this.
+-->
#### 限制
-<!--
-It is currently not possible to create plugins that overwrite existing `kubectl` commands. For example, creating a plugin `kubectl-version` will cause that plugin to never be executed, as the existing `kubectl version` command will always take precedence over it. Due to this limitation, it is also *not* possible to use plugins to add new subcommands to existing `kubectl` commands. For example, adding a subcommand `kubectl create foo` by naming your plugin `kubectl-create-foo` will cause that plugin to be ignored. Warnings will appear under the output of `kubectl plugin list` for any valid plugins that attempt to do this.
--->
-目前无法创建覆盖现有 `kubectl` 命令的插件，例如，创建一个插件 `kubectl-version` 将导致该插件永远不会被执行，因为现有的 `kubectl-version` 命令总是优先于它执行。
-由于这个限制，也不可能使用插件将新的子命令添加到现有的 `kubectl` 命令中。例如，通过将插件命名为 `kubectl-create-foo` 来添加子命令 `kubectl create foo` 将导致该插件被忽略。对于任何试图这样做的有效插件 `kubectl plugin list` 的输出中将显示警告。
+目前无法创建覆盖现有 `kubectl` 命令的插件。
+例如，创建一个插件 `kubectl-version` 将导致该插件永远不会被执行，
+因为现有的 `kubectl-version` 命令总是优先于它执行。
+由于这个限制，也不可能使用插件将新的子命令添加到现有的 `kubectl` 命令中。
+例如，通过将插件命名为 `kubectl-create-foo` 来添加子命令 `kubectl create foo` 将导致该插件被忽略。
+
+对于任何试图这样做的有效插件 `kubectl plugin list` 的输出中将显示警告。
<!--
## Writing kubectl plugins
--->
-## 编写 kubectl 插件
-
-<!--
You can write a plugin in any programming language or script that allows you to write command-line commands.
-->
-你可以用任何编程语言或脚本编写插件，允许您编写命令行命令。
+## 编写 kubectl 插件
+
+你可以用任何编程语言或脚本编写插件，允许你编写命令行命令。
<!--
-There is no plugin installation or pre-loading required. Plugin executables receive the inherited environment from the `kubectl` binary.
-A plugin determines which command path it wishes to implement based on its name. For example, a plugin wanting to provide a new command
-`kubectl foo`, would simply be named `kubectl-foo`, and live somewhere in the user's PATH.
+There is no plugin installation or pre-loading required. Plugin executables receive
+the inherited environment from the `kubectl` binary.
+A plugin determines which command path it wishes to implement based on its name. For
+example, a plugin wanting to provide a new command `kubectl foo`, would simply be named
+`kubectl-foo`, and live somewhere in the user's PATH.
-->
-不需要安装插件或预加载，插件可执行程序从 `kubectl` 二进制文件接收继承的环境，插件根据其名称确定它希望实现的命令路径。
-例如，一个插件想要提供一个新的命令 `kubectl foo`，它将被简单地命名为 `kubectl-foo`，并且位于用户路径的某个位置。
+不需要安装插件或预加载，插件可执行程序从 `kubectl` 二进制文件接收继承的环境，
+插件根据其名称确定它希望实现的命令路径。
+例如，一个插件想要提供一个新的命令 `kubectl foo`，它将被简单地命名为 `kubectl-foo`，
+并且位于用户 PATH 的某个位置。
<!--
### Example plugin
-->
-
### 示例插件
```
#!/bin/bash
-# optional argument handling
+# 可选的参数处理
if [[ "$1" == "version" ]]
then
echo "1.0.0"
exit 0
fi
-# optional argument handling
+# 可选的参数处理
if [[ "$1" == "config" ]]
then
echo $KUBECONFIG
@@ -146,7 +143,6 @@ echo "I am a plugin named kubectl-foo"
<!--
### Using a plugin
-->
-
### 使用插件
<!--
@@ -161,7 +157,7 @@ sudo chmod +x ./kubectl-foo
<!--
and place it anywhere in your PATH:
-->
-并将它放在你的路径中的任何地方：
+并将它放在你的 PATH 中的任何地方：
```
sudo mv ./kubectl-foo /usr/local/bin
@@ -218,72 +214,86 @@ Additionally, the first argument that is passed to a plugin will always be the f
<!--
### Naming a plugin
--->
-### 命名插件
-
-<!--
As seen in the example above, a plugin determines the command path that it will implement based on its filename. Every sub-command in the command path that a plugin targets, is separated by a dash (`-`).
For example, a plugin that wishes to be invoked whenever the command `kubectl foo bar baz` is invoked by the user, would have the filename of `kubectl-foo-bar-baz`.
-->
+### 命名插件
+
如上面的例子所示，插件根据文件名确定要实现的命令路径，插件所针对的命令路径中的每个子命令都由破折号（`-`）分隔。
例如，当用户调用命令 `kubectl foo bar baz` 时，希望调用该命令的插件的文件名为 `kubectl-foo-bar-baz`。
<!--
#### Flags and argument handling
-->
-
#### 参数和标记处理
-{{< note >}}
<!--
-Unlike previous versions of `kubectl`, the plugin mechanism will _not_ create any custom, plugin-specific values or environment variables to a plugin process.
-This means that environment variables such as `KUBECTL_PLUGINS_CURRENT_NAMESPACE` are no longer provided to a plugin. Plugins must parse all of the arguments passed to them by a user,
-and handle flag validation as part of their own implementation. For plugins written in Go, a set of utilities has been provided under [k8s.io/cli-runtime](https://github.com/kubernetes/cli-runtime) to assist with this.
--->
-与以前版本的 `kubectl` 不同，插件机制不会为插件进程创建任何定制的、特定于插件的值或环境变量，这意味着像 `KUBECTL_PLUGINS_CURRENT_NAMESPACE` 这样的环境变量不再提供给插件。
-插件必须解析用户传递给它们的所有参数，并将参数验证作为它们自己实现的一部分处理。对于用 Go 编写的插件，在 [k8s.io/cli-runtime](https://github.com/kubernetes/cli-runtime) 下提供了一组实用程序来帮助实现这一点。
+The plugin mechanism doest _not_ create any custom, plugin-specific values or environment variables to a plugin process.
+An older kubectl plugin mechanism provided environment variables such as `KUBECTL_PLUGINS_CURRENT_NAMESPACE`; that no longer happens.
+-->
+{{< note >}}
+插件机制不会为插件进程创建任何定制的、特定于插件的值或环境变量。
+
+较老的插件机制会提供环境变量（例如 `KUBECTL_PLUGINS_CURRENT_NAMESPACE`）；这种机制已被废弃。
{{< /note >}}
<!--
-Taking our `kubectl-foo-bar-baz` plugin from the above scenario, we further explore additional cases where users invoke our plugin while providing additional flags and arguments.
-For example, in a situation where a user invokes the command `kubectl foo bar baz arg1 --flag=value arg2`, the plugin mechanism will first try to find the plugin with the longest possible name, which in this case
-would be `kubectl-foo-bar-baz-arg1`. Upon not finding that plugin, it then treats the last dash-separated value as an argument (`arg1` in this case), and attempts to find the next longest possible name, `kubectl-foo-bar-baz`.
-Upon finding a plugin with this name, it then invokes that plugin, passing all args and flags after its name to the plugin executable.
+kubectl plugins must parse and validate all of the arguments passed to them.
+See [using the command line runtime package](#using-the-command-line-runtime-package) for details of a Go library aimed at plugin authors.
+
+Here are some additional cases where users invoke your plugin while providing additional flags and arguments. This builds upon the the `kubectl-foo-bar-baz` plugin from the scenario above.
-->
-从上面的场景中使用我们的 `kubectl-foo-bar-baz` 插件，我们将进一步研究用户在提供额外标记和参数的同时调用我们的插件的其他情况。
-例如，在用户调用命令 `kubectl foo bar baz arg1 --flag=value arg2` 的情况下，插件机制将首先尝试找到名称可能最长的插件，在本例中是 `kubectl-foo-bar-baz-arg1`。
-当没有找到这个插件时，它就会将最后一个以破折号分隔的值视为参数（在本例中为 `arg1`），并尝试找到下一个最长的名称 `kubectl-foo-bar-baz`。
-在找到具有此名称的插件后，它将调用该插件，并在其名称之后将所有参数和标志传递给插件可执行文件。
+kubeclt 插件必须解析并检查传递给它们的所有参数。
+参阅[使用命令行运行时包](#using-the-command-line-runtime-package)了解针对
+插件开发人员的 Go 库的细节。
<!--
-Example:
+Here are some additional cases where users invoke your plugin while providing additional flags and arguments. This builds upon the the `kubectl-foo-bar-baz` plugin from the scenario above.
-->
+这里是一些用户调用你的插件的时候提供额外标志和参数的场景。
+这些场景时基于上述案例中的 `kubectl-foo-bar-baz` 插件的。
+
+<!--
+If you run `kubectl foo bar baz arg1 -flag=value arg2`, kubectl's plugin mechanism will first try to find the plugin with the longest possible name, which in this case
+would be `kubectl-foo-bar-baz-arg1`. Upon not finding that plugin, kubectl then treats the last dash-separated value as an argument (`arg1` in this case), and attempts to find the next longest possible name, `kubectl-foo-bar-baz`.
+Upon having found a plugin with this name, kubectl then invokes that plugin, passing all args and flags after the plugin's name as arguments to the plugin process.
+-->
+
+如果你运行 `kubectl foo bar baz arg1 --flag=value arg2`，kubeclt 的插件机制将首先尝试找到
+最长可能名称的插件，在本例中是 `kubectl-foo-bar-baz-arg1`。
+当没有找到这个插件时，kubectl 就会将最后一个以破折号分隔的值视为参数（在本例中为 `arg1`），
+并尝试找到下一个最长的名称 `kubectl-foo-bar-baz`。
+在找到具有此名称的插件后，它将调用该插件，并在其名称之后将所有参数和标志传递给插件进程。
+
+<!-- Example: -->
示例：
```bash
-# create a plugin
+# 创建一个插件
echo -e '#!/bin/bash\n\necho "My first command-line argument was $1"' > kubectl-foo-bar-baz
sudo chmod +x ./kubectl-foo-bar-baz
-# "install" our plugin by placing it on our PATH
+# 将插件放到 PATH 下完成"安装"
sudo mv ./kubectl-foo-bar-baz /usr/local/bin
-# ensure our plugin is recognized by kubectl
+# 确保 kubectl 能够识别我们的插件
kubectl plugin list
```
+
```
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-foo-bar-baz
```
-```
-# test that calling our plugin via a "kubectl" command works
-# even when additional arguments and flags are passed to our
-# plugin executable by the user.
+
+```shell
+# 测试通过 "kubectl" 命令来调用我们的插件时可行的
+# 即使我们给插件传递一些额外的参数或标志
kubectl foo bar baz arg1 --meaningless-flag=true
```
+
```
My first command-line argument was arg1
```
@@ -291,35 +301,32 @@ My first command-line argument was arg1
<!--
As you can see, our plugin was found based on the `kubectl` command specified by a user, and all extra arguments and flags were passed as-is to the plugin executable once it was found.
-->
-正如你所看到的，我们的插件是基于用户指定的 `kubectl` 命令找到的，所有额外的参数和标记都是按原样传递给插件可执行文件的。
+正如你所看到的，我们的插件是基于用户指定的 `kubectl` 命令找到的，
+所有额外的参数和标记都是按原样传递给插件可执行文件的。
<!--
#### Names with dashes and underscores
--->
-#### 带有破折号和下划线的名称
-
-<!--
Although the `kubectl` plugin mechanism uses the dash (`-`) in plugin filenames to separate the sequence of sub-commands processed by the plugin, it is still possible to create a plugin
command containing dashes in its commandline invocation by using underscores (`_`) in its filename.
-->
-虽然 `kubectl` 插件机制在插件文件名中使用破折号（`-`）分隔插件处理的子命令序列，但是仍然可以通过在文件名中使用下划线（`-`）来创建命令行中包含破折号的插件命令。
+#### 带有破折号和下划线的名称
-<!--
-Example:
--->
+虽然 `kubectl` 插件机制在插件文件名中使用破折号（`-`）分隔插件处理的子命令序列，
+但是仍然可以通过在文件名中使用下划线（`-`）来创建命令行中包含破折号的插件命令。
+<!-- Example: -->
例子：
```bash
-# create a plugin containing an underscore in its filename
+# 创建文件名中包含下划线的插件
echo -e '#!/bin/bash\n\necho "I am a plugin with a dash in my name"' > ./kubectl-foo_bar
sudo chmod +x ./kubectl-foo_bar
-# move the plugin into your PATH
+# 将插件放到 PATH 下
sudo mv ./kubectl-foo_bar /usr/local/bin
-# our plugin can now be invoked from `kubectl` like so:
+# 现在可以通过 kubectl 来调用插件
kubectl foo-bar
```
```
@@ -330,42 +337,46 @@ I am a plugin with a dash in my name
Note that the introduction of underscores to a plugin filename does not prevent us from having commands such as `kubectl foo_bar`.
The command from the above example, can be invoked using either a dash (`-`) or an underscore (`_`):
-->
-请注意，在插件文件名中引入下划线并不会阻止我们使用 `kubectl foo_bar` 之类的命令。可以使用破折号（`-`）或下划线（`-`）调用上面示例中的命令:
+请注意，在插件文件名中引入下划线并不会阻止我们使用 `kubectl foo_bar` 之类的命令。
+可以使用破折号（`-`）或下划线（`-`）调用上面示例中的命令:
-```bash
-# our plugin can be invoked with a dash
+```shell
+# 我们的插件也可以用破折号来调用
kubectl foo-bar
```
+
```
I am a plugin with a dash in my name
```
-```bash
-# it can also be invoked using an underscore
+```shell
+# 你也可以使用下划线来调用我们的定制命令
kubectl foo_bar
```
+
```
I am a plugin with a dash in my name
```
<!--
#### Name conflicts and overshadowing
--->
-#### 命名冲突和弊端
-
-<!--
It is possible to have multiple plugins with the same filename in different locations throughout your PATH.
For example, given a PATH with the following value: `PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins`, a copy of plugin `kubectl-foo` could exist in `/usr/local/bin/plugins` and `/usr/local/bin/moreplugins`,
such that the output of the `kubectl plugin list` command is:
-->
-可以在路径的不同位置使用多个文件名相同的插件，
-例如，给定一个路径的值为: `PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins`，在 `/usr/local/bin/plugins` 和 `/usr/local/bin/moreplugins` 中可以存在一个插件 `kubectl-foo` 的副本，这样 `kubectl plugin list` 命令的输出就是:
+#### 命名冲突和弊端
+
+可以在 `PATH` 的不同位置提供多个文件名相同的插件，
+例如，给定一个 `PATH` 为: `PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins`，
+在 `/usr/local/bin/plugins` 和 `/usr/local/bin/moreplugins` 中可以存在一个插件
+`kubectl-foo` 的副本，这样 `kubectl plugin list` 命令的输出就是:
```bash
PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins kubectl plugin list
```
-```bash
+
+```
The following kubectl-compatible plugins are available:
/usr/local/bin/plugins/kubectl-foo
@@ -378,28 +389,29 @@ error: one plugin warning was found
<!--
In the above scenario, the warning under `/usr/local/bin/moreplugins/kubectl-foo` tells us that this plugin will never be executed. Instead, the executable that appears first in our PATH, `/usr/local/bin/plugins/kubectl-foo`, will always be found and executed first by the `kubectl` plugin mechanism.
-->
-在上面的场景中 `/usr/local/bin/moreplugins/kubectl-foo` 下的警告告诉我们这个插件永远不会被执行。相反，首先出现在我们路径中的可执行文件 `/usr/local/bin/plugins/kubectl-foo` 总是首先被 `kubectl` 插件机制找到并执行。
+在上面的场景中 `/usr/local/bin/moreplugins/kubectl-foo` 下的警告告诉我们这个插件永远不会被执行。
+相反，首先出现在我们路径中的可执行文件 `/usr/local/bin/plugins/kubectl-foo`
+总是首先被 `kubectl` 插件机制找到并执行。
<!--
A way to resolve this issue is to ensure that the location of the plugin that you wish to use with `kubectl` always comes first in your PATH. For example, if we wanted to always use `/usr/local/bin/moreplugins/kubectl-foo` anytime that the `kubectl` command `kubectl foo` was invoked, we would simply change the value of our PATH to be `PATH=/usr/local/bin/moreplugins:/usr/local/bin/plugins`.
-->
解决这个问题的一种方法是你确保你希望与 `kubectl` 一起使用的插件的位置总是在你的路径中首先出现。
-例如，如果我们总是想使用 `/usr/local/bin/moreplugins/kubectl foo`，那么在调用 `kubectl` 命令 `kubectl foo` 时，我们只需将路径的值更改为 `PATH=/usr/local/bin/moreplugins:/usr/local/bin/plugins`。
-
+例如，如果我们总是想使用 `/usr/local/bin/moreplugins/kubectl foo`，
+那么在调用 `kubectl` 命令 `kubectl foo` 时，我们只需将路径的值更改为 `PATH=/usr/local/bin/moreplugins:/usr/local/bin/plugins`。
<!--
#### Invocation of the longest executable filename
--->
-#### 调用最长的可执行文件名
-
-<!--
There is another kind of overshadowing that can occur with plugin filenames. Given two plugins present in a user's PATH `kubectl-foo-bar` and `kubectl-foo-bar-baz`, the `kubectl` plugin mechanism will always choose the longest possible plugin name for a given user command. Some examples below, clarify this further:
-->
-对于插件文件名而言还有另一种弊端，给定用户路径中的两个插件 `kubectl-foo-bar` 和 `kubectl-foo-bar-baz` ，`kubectl` 插件机制总是为给定的用户命令选择尽可能长的插件名称。下面的一些例子进一步的说明了这一点：
+#### 调用最长的可执行文件名
+
+对于插件文件名而言还有另一种弊端，给定用户路径中的两个插件 `kubectl-foo-bar` 和 `kubectl-foo-bar-baz`
+`kubectl` 插件机制总是为给定的用户命令选择尽可能长的插件名称。下面的一些例子进一步的说明了这一点：
```bash
-# for a given kubectl command, the plugin with the longest possible filename will always be preferred
+# 对于给定的 kubectl 命令，最长可能文件名的插件是被优先选择的
kubectl foo bar baz
```
```
@@ -435,6 +447,7 @@ This design choice ensures that plugin sub-commands can be implemented across mu
```bash
ls ./plugin_command_tree
```
+
```
kubectl-parent
kubectl-parent-subcommand
@@ -443,14 +456,13 @@ kubectl-parent-subcommand-subsubcommand
<!--
### Checking for plugin warnings
--->
-### 检查插件警告
-
-<!--
You can use the aforementioned `kubectl plugin list` command to ensure that your plugin is visible by `kubectl`, and verify that there are no warnings preventing it from being called as a `kubectl` command.
-->
-你可以使用前面提到的 `kubectl plugin list` 命令来确保你的插件可以被 `kubectl` 看到，并且验证没有警告防止它被称为 `kubectl` 命令。
+### 检查插件警告
+
+你可以使用前面提到的 `kubectl plugin list` 命令来确保你的插件可以被 `kubectl` 看到，
+并且验证没有警告防止它被称为 `kubectl` 命令。
```bash
kubectl plugin list
@@ -469,46 +481,105 @@ error: 2 plugin warnings were found
<!--
### Using the command line runtime package
--->
-### 使用命令行 runtime 包
+If you're writing a plugin for kubectl and you're using Go, you can make use
+of the
+[cli-runtime](https://github.com/kubernetes/cli-runtime) utility libraries.
+
+These libraries provide helpers for parsing or updating a user's
+[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+file, for making REST-style requests to the API server, or to bind flags
+associated with configuration and printing.
+
+See the [Sample CLI Plugin](https://github.com/kubernetes/sample-cli-plugin) for
+an example usage of the tools provided in the CLI Runtime repo.
+-->
+### 使用命令行运行时包 {#using-the-command-line-runtime-package}
+
+如果你在编写 kubectl 插件，而且你选择使用 Go 语言，你可以利用
+[cli-runtime](https://github.com/kubernetes/cli-runtime) 工具库。
+
+这些库提供了一些辅助函数，用来解析和更新用户的
+[kubeconfig](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+文件，向 API 服务器发起 REST 风格的请求，或者将参数绑定到某配置上，
+抑或将其打印输出。
+
+关于 CLI Runtime 仓库所提供的工具的使用实例，可参考
+[CLI 插件示例](https://github.com/kubernetes/sample-cli-plugin) 项目。
<!--
-As part of the plugin mechanism update in the v1.12.0 release, an additional set of utilities have been made available to plugin authors. These utilities
-exist under the [k8s.io/cli-runtime](https://github.com/kubernetes/cli-runtime) repository, and can be used by plugins written in Go to parse and update
-a user's KUBECONFIG file, obtain REST clients to talk to the API server, and automatically bind flags associated with configuration and printing.
+## Distributing kubectl plugins
+
+If you have developed a plugin for others to use, you should consider how you
+package it, distribute it and deliver updates to your users.
-->
-作为 v1.12.0 版本中插件机制更新的一部分，插件作者可以使用另外一组实用程序。这些实用程序在，
-[k8s.io/cli-runtime](https://github.com/kubernetes/cli-runtime) 存储库，并且可以被编写在 Go 中的插件用来解析和更新，
-用户的 KUBECONFIG 文件，获取 REST 客户端与 API 服务器通信，并自动绑定与配置和打印相关的参数。
+## 分发 kubectl 插件
+
+如果你开发了一个插件给别人使用，你应该考虑如何为其封装打包、如何分发软件
+以及将来的更新到用户。
<!--
-Plugins *do not* have to be written in Go in order to be recognized as valid plugins by `kubectl`, but they do have to use Go in order to take advantage of
-the tools and utilities in the CLI Runtime repository.
+### Krew {#distributing-krew}
+
+[Krew](https://krew.dev/) offers a cross-platform way to package and
+distribute your plugins. This way, you use a single packaging format for all
+target platforms (Linux, Windows, macOS etc) and deliver updates to your users.
+Krew also maintains a [plugin
+index](https://index.krew.dev/) so that other people can
+discover your plugin and install it.
-->
-插件*不*必须用 Go 编写才能被 `kubectl` 识别为有效的插件，但是它们必须使用 Go 才能使用的 CLI Runtime 存储库中的工具和实用程序。
+### Krew {#distributing-krew}
+
+[Krew](https://krew.dev/) 提供了一种对插件进行打包和分发的跨平台方式。
+基于这种方式，你会在所有的目标平台（Linux、Windows、macOS 等）使用同一
+种打包形式，包括为用户提供更新。
+Krew 也维护一个[插件索引（plugin index）](https://index.krew.dev/)
+以便其他人能够发现你的插件并安装之。
<!--
-See the [Sample CLI Plugin](https://github.com/kubernetes/sample-cli-plugin) for an example usage of the tools provided in the CLI Runtime repo.
+### Native / platform specific package management {#distributing-native}
+
+Alternatively, you can use traditional package managers such as, `apt` or `yum`
+on Linux, Chocolatey on Windows, and Homebrew on macOS. Any package
+manager will be suitable if it can place new executables placed somewhere
+in the user's `PATH`.
+As a plugin author, if you pick this option then you also have the burden
+of updating your kubectl plugin’s distribution package across multiple
+platforms for each release.
-->
-参见 [CLI 插件示例](https://github.com/kubernetes/sample-cli-plugin)了解 CLI Runtime 存储库中提供的工具的使用示例。
+### 原生的与特定平台的包管理 {#distributing-native}
+另一种方式是，你可以使用传统的包管理器（例如 Linux 上 的 `apt` 或 `yum`，
+Windows 上的 Chocolatey、macOs 上的 Homebrew）。
+只要能够将新的可执行文件放到用户的 `PATH` 路径上某处，这种包管理器就符合需要。
+作为一个插件作者，如果你选择这种方式来纷飞，你就需要自己来管理和更新
+你的 kubectl 插件的分发包，包括所有平台和所有发行版本。
+<!--
+### Source code {#distributing-source-code}
+You can publish the source code; for example, as a Git repository. If you
+choose this option, someone who wants to use that plugin must fetch the code,
+set up a build environment (if it needs compiling), and deploy the plugin.
+If you also make compiled packages available, or use Krew, that will make
+installs easier.
+-->
+### 源代码 {#distributing-source-code}
+
+你也可以发布你的源代码，例如，发布为某个 Git 仓库。
+如果你选择这条路线，希望使用该插件的用户必须取回代码、配置一个构造环境
+（如果需要编译的话）并部署该插件。
+如果你也提供编译后的软件包，或者使用 Krew，那就会大大简化安装过程了。
## {{% heading "whatsnext" %}}
-
<!--
* Check the Sample CLI Plugin repository for [a detailed example](https://github.com/kubernetes/sample-cli-plugin) of a plugin written in Go.
* In case of any questions, feel free to reach out to the [CLI SIG team](https://github.com/kubernetes/community/tree/master/sig-cli).
-* Binary plugins are a beta feature, so this is the time to contribute ideas and improvements to the codebase. We're also excited to hear about what you're planning to implement with plugins, so [let us know](https://github.com/kubernetes/community/tree/master/sig-cli)!
+* Read about [Krew](https://krew.dev/), a package manager for kubectl plugins.
-->
* 查看 CLI 插件库示例，查看用 Go 编写的插件的[详细示例](https://github.com/kubernetes/sample-cli-plugin)
-* 如有任何问题，请随时联系 [CLI SIG 小组](https://github.com/kubernetes/community/tree/master/sig-cli)
-* 二进制插件是 beta 版的特性，所以现在是时候为代码库贡献一些想法和改进了。我们也很高兴听到您计划用插件实现什么，所以[让我们知道](https://github.com/kubernetes/community/tree/master/sig-cli)！
-
-
-
+* 如有任何问题，请随时联系 [SIG CLI ](https://github.com/kubernetes/community/tree/master/sig-cli)
+* 了解 [Krew](https://krew.dev/)，一个 kubectl 插件管理器。
diff --git a/content/zh/docs/tasks/extend-kubernetes/_index.md b/content/zh/docs/tasks/extend-kubernetes/_index.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md b/content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md
index 11035e4e07..a37263f949 100644
--- a/content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md
+++ b/content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md
@@ -1,14 +1,9 @@
---
title: 配置聚合层
-reviewers:
-- lavalamp
-- cheftako
-- chenopis
content_type: task
weight: 10
---
<!--
----
title: Configure the Aggregation Layer
reviewers:
- lavalamp
@@ -16,7 +11,6 @@ reviewers:
- chenopis
content_type: task
weight: 10
----
-->
<!-- overview -->
@@ -24,35 +18,29 @@ weight: 10
<!--
Configuring the [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs.
-->
-
-配置 [聚合层](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 允许 Kubernetes apiserver 使用其它 API 扩展，这些 API 不是核心 Kubernetes API 的一部分。
-
-
+配置 [聚合层](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 允许
+Kubernetes apiserver 使用其它 API 扩展，这些 API 不是核心 Kubernetes API 的一部分。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-{{< note >}}
-
<!--
There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA.
-->
-
-要使聚合层在您的环境中正常工作以支持代理服务器和扩展 apiserver 之间的相互 TLS 身份验证，需要满足一些设置要求。Kubernetes 和 kube-apiserver 具有多个 CA，因此请确保代理是由聚合层 CA 签名的，而不是由主 CA 签名的。
-
-{{< caution >}}
+{{< note >}}
+要使聚合层在您的环境中正常工作以支持代理服务器和扩展 apiserver 之间的相互 TLS 身份验证，
+需要满足一些设置要求。Kubernetes 和 kube-apiserver 具有多个 CA，
+因此请确保代理是由聚合层 CA 签名的，而不是由主 CA 签名的。
+{{< /note >}}
<!--
Reusing the same CA for different client types can negatively impact the cluster's ability to function. For more information, see [CA Reusage and Conflicts](#ca-reusage-and-conflicts).
-->
-对不同的客户端类型重复使用相同的 CA 会对群集的功能产生负面影响。有关更多信息，请参见 [CA重用和冲突](#ca-重用和冲突)。
-
+{{< caution >}}
+对不同的客户端类型重复使用相同的 CA 会对群集的功能产生负面影响。有关更多信息，请参见
+[CA 重用和冲突](#ca-reusage-and-conflicts)。
{{< /caution >}}
-{{< /note >}}
-
-
<!-- steps -->
@@ -62,7 +50,14 @@ Reusing the same CA for different client types can negatively impact the cluster
Unlike Custom Resource Definitions (CRDs), the Aggregation API involves another server - your Extension apiserver - in addition to the standard Kubernetes apiserver. The Kubernetes apiserver will need to communicate with your extension apiserver, and your extension apiserver will need to communicate with the Kubernetes apiserver. In order for this communication to be secured, the Kubernetes apiserver uses x509 certificates to authenticate itself to the extension apiserver.
This section describes how the authentication and authorization flows work, and how to configure them.
+-->
+## 身份认证流程
+与自定义资源定义（CRD）不同，除标准的 Kubernetes apiserver 外，Aggregation API 还涉及另一个服务器：扩展 apiserver。Kubernetes apiserver 将需要与您的扩展 apiserver 通信，并且您的扩展 apiserver 也需要与 Kubernetes apiserver 通信。为了确保此通信的安全，Kubernetes apiserver 使用 x509 证书向扩展 apiserver 认证。
+
+本节介绍身份认证和鉴权流程的工作方式以及如何配置它们。
+
+<!--
The high-level flow is as follows:
1. Kubernetes apiserver: authenticate the requesting user and authorize their rights to the requested API path.
@@ -79,13 +74,6 @@ The flow can be seen in the following diagram.
The source for the above swimlanes can be found in the source of this document.
-->
-
-## 认证流程
-
-与自定义资源定义（CRD）不同，除标准的 Kubernetes apiserver 外，Aggregation API 还涉及另一个服务器：扩展 apiserver。Kubernetes apiserver 将需要与您的扩展 apiserver 通信，并且您的扩展 apiserver 也需要与 Kubernetes apiserver 通信。为了确保此通信的安全，Kubernetes apiserver 使用 x509 证书向扩展 apiserver 认证。
-
-本节介绍身份认证和鉴权流程的工作方式以及如何配置它们。
-
大致流程如下：
1. Kubernetes apiserver：对发出请求的用户身份认证，并对请求的 API 路径执行鉴权。
@@ -264,20 +252,7 @@ The Kubernetes apiserver connects to the extension apiserver over TLS, authentic
* signed client certificate file via `--proxy-client-cert-file`
* certificate of the CA that signed the client certificate file via `--requestheader-client-ca-file`
* valid Common Names (CN) in the signed client certificate via `--requestheader-allowed-names`
-
-The Kubernetes apiserver will use the files indicated by `--proxy-client-*-file` to authenticate to the extension apiserver. In order for the request to be considered valid by a compliant extension apiserver, the following conditions must be met:
-
-1. The connection must be made using a client certificate that is signed by the CA whose certificate is in `--requestheader-client-ca-file`.
-2. The connection must be made using a client certificate whose CN is one of those listed in `--requestheader-allowed-names`. **Note:** You can set this option to blank as `--requestheader-allowed-names=""`. This will indicate to an extension apiserver that _any_ CN is acceptable.
-
-When started with these options, the Kubernetes apiserver will:
-
-1. Use them to authenticate to the extension apiserver.
-2. Create a configmap in the `kube-system` namespace called `extension-apiserver-authentication`, in which it will place the CA certificate and the allowed CNs. These in turn can be retrieved by extension apiservers to validate requests.
-
-Note that the same client certificate is used by the Kubernetes apiserver to authenticate against _all_ extension apiservers. It does not create a client certificate per extension apiserver, but rather a single one to authenticate as the Kubernetes apiserver. This same one is reused for all extension apiserver requests.
-->
-
#### Kubernetes Apiserver 客户端认证
Kubernetes apiserver 通过 TLS 连接到扩展 apiserver，并使用客户端证书认证。您必须在启动时使用提供的标志向 Kubernetes apiserver 提供以下内容：
@@ -287,12 +262,29 @@ Kubernetes apiserver 通过 TLS 连接到扩展 apiserver，并使用客户端
* 通过 `--requestheader-client-ca-file` 签署客户端证书文件的 CA 证书
* 通过 `--requestheader-allowed-names` 在签署的客户证书中有效的公用名（CN）
-Kubernetes apiserver 将使用由 --proxy-client-*-file 指示的文件来验证扩展 apiserver。为了使合规的扩展 apiserver 能够将该请求视为有效，必须满足以下条件：
+<!--
+The Kubernetes apiserver will use the files indicated by `--proxy-client-*-file` to authenticate to the extension apiserver. In order for the request to be considered valid by a compliant extension apiserver, the following conditions must be met:
+
+1. The connection must be made using a client certificate that is signed by the CA whose certificate is in `--requestheader-client-ca-file`.
+2. The connection must be made using a client certificate whose CN is one of those listed in `--requestheader-allowed-names`. **Note:** You can set this option to blank as `--requestheader-allowed-names=""`. This will indicate to an extension apiserver that _any_ CN is acceptable.
+-->
+Kubernetes apiserver 将使用由 `--proxy-client-*-file` 指示的文件来验证扩展 apiserver。为了使合规的扩展 apiserver 能够将该请求视为有效，必须满足以下条件：
1. 连接必须使用由 CA 签署的客户端证书，该证书的证书位于 `--requestheader-client-ca-file` 中。
2. 连接必须使用客户端证书，该客户端证书的 CN 是 `--requestheader-allowed-names` 中列出的证书之一。
-**注意：**您可以将此选项设置为空白，即为`--requestheader-allowed-names`。这将向扩展 apiserver 指示任何 CN 是可接受的。
+{{< note >}}
+您可以将此选项设置为空白，即为`--requestheader-allowed-names`。这将向扩展 apiserver 指示任何 CN 是可接受的。
+{{< /note >}}
+
+<!--
+When started with these options, the Kubernetes apiserver will:
+
+1. Use them to authenticate to the extension apiserver.
+2. Create a configmap in the `kube-system` namespace called `extension-apiserver-authentication`, in which it will place the CA certificate and the allowed CNs. These in turn can be retrieved by extension apiservers to validate requests.
+
+Note that the same client certificate is used by the Kubernetes apiserver to authenticate against _all_ extension apiservers. It does not create a client certificate per extension apiserver, but rather a single one to authenticate as the Kubernetes apiserver. This same one is reused for all extension apiserver requests.
+-->
使用这些选项启动时，Kubernetes apiserver 将：
1. 使用它们向扩展 apiserver 认证。
@@ -305,9 +297,9 @@ Kubernetes apiserver 将使用由 --proxy-client-*-file 指示的文件来验证
When the Kubernetes apiserver proxies the request to the extension apiserver, it informs the extension apiserver of the username and group with which the original request successfully authenticated. It provides these in http headers of its proxied request. You must inform the Kubernetes apiserver of the names of the headers to be used.
-* the header in which to store the username via `--requestheader-username-headers`
-* the header in which to store the group via `--requestheader-group-headers`
-* the prefix to append to all extra headers via `--requestheader-extra-headers-prefix`
+* the header in which to store the username via `-requestheader-username-headers`
+* the header in which to store the group via `-requestheader-group-headers`
+* the prefix to append to all extra headers via `-requestheader-extra-headers-prefix`
These header names are also placed in the `extension-apiserver-authentication` configmap, so they can be retrieved and used by extension apiservers.
-->
@@ -336,14 +328,7 @@ The extension apiserver, upon receiving a proxied request from the Kubernetes ap
* Was signed by the CA whose certificate matches the retrieved CA certificate.
* Has a CN in the list of allowed CNs, unless the list is blank, in which case all CNs are allowed.
* Extract the username and group from the appropriate headers
-
-If the above passes, then the request is a valid proxied request from a legitimate authenticating proxy, in this case the Kubernetes apiserver.
-
-Note that it is the responsibility of the extension apiserver implementation to provide the above. Many do it by default, leveraging the `k8s.io/apiserver/` package. Others may provide options to override it using command-line options.
-
-In order to have permission to retrieve the configmap, an extension apiserver requires the appropriate role. There is a default role named `extension-apiserver-authentication-reader` in the `kube-system` namespace which can be assigned.
-->
-
### 扩展 Apiserver 认证
扩展 apiserver 在收到来自 Kubernetes apiserver 的代理请求后，必须验证该请求确实确实来自有效的身份验证代理，该认证代理由 Kubernetes apiserver 履行。扩展 apiserver 通过以下方式对其认证：
@@ -358,6 +343,13 @@ In order to have permission to retrieve the configmap, an extension apiserver re
* 在允许的 CN 列表中有一个 CN，除非列表为空，在这种情况下允许所有 CN。
* 从适当的头部中提取用户名和组
+<!--
+If the above passes, then the request is a valid proxied request from a legitimate authenticating proxy, in this case the Kubernetes apiserver.
+
+Note that it is the responsibility of the extension apiserver implementation to provide the above. Many do it by default, leveraging the `k8s.io/apiserver/` package. Others may provide options to override it using command-line options.
+
+In order to have permission to retrieve the configmap, an extension apiserver requires the appropriate role. There is a default role named `extension-apiserver-authentication-reader` in the `kube-system` namespace which can be assigned.
+-->
如果以上均通过，则该请求是来自合法认证代理（在本例中为 Kubernetes apiserver）的有效代理请求。
请注意，扩展 apiserver 实现负责提供上述内容。默认情况下，许多扩展 apiserver 实现利用 `k8s.io/apiserver/` 软件包来做到这一点。也有一些实现可能支持使用命令行选项来覆盖这些配置。
@@ -371,10 +363,11 @@ The extension apiserver now can validate that the user/group retrieved from the
In order for the extension apiserver to be authorized itself to submit the `SubjectAccessReview` request to the Kubernetes apiserver, it needs the correct permissions. Kubernetes includes a default `ClusterRole` named `system:auth-delegator` that has the appropriate permissions. It can be granted to the extension apiserver's service account.
-->
-
### 扩展 Apiserver 对请求鉴权
-扩展 apiserver 现在可以验证从标头检索的`user/group`是否有权执行给定请求。通过向 Kubernetes apiserver 发送标准 [SubjectAccessReview](/zh/docs/reference/access-authn-authz/authorization/) 请求来实现。
+扩展 apiserver 现在可以验证从标头检索的`user/group`是否有权执行给定请求。
+通过向 Kubernetes apiserver 发送标准
+[SubjectAccessReview](/zh/docs/reference/access-authn-authz/authorization/) 请求来实现。
为了使扩展 apiserver 本身被鉴权可以向 Kubernetes apiserver 提交 SubjectAccessReview 请求，它需要正确的权限。Kubernetes 包含一个具有相应权限的名为`system：auth-delegator` 的默认 `ClusterRole`，可以将其授予扩展 apiserver 的服务帐户。
@@ -383,21 +376,19 @@ In order for the extension apiserver to be authorized itself to submit the `Subj
If the `SubjectAccessReview` passes, the extension apiserver executes the request.
-
## Enable Kubernetes Apiserver flags
Enable the aggregation layer via the following kube-apiserver flags. They may have already been taken care of by your provider.
-->
-
### 扩展 Apiserver 执行
-如果`SubjectAccessReview`通过，则扩展 apiserver 执行请求。
-
+如果 `SubjectAccessReview` 通过，则扩展 apiserver 执行请求。
## 启用 Kubernetes Apiserver 标志
通过以下 kube-apiserver 标志启用聚合层。您的服务提供商可能已经为您完成了这些工作：
+```
--requestheader-client-ca-file=<path to aggregator CA cert>
--requestheader-allowed-names=front-proxy-client
--requestheader-extra-headers-prefix=X-Remote-Extra-
@@ -405,13 +396,14 @@ Enable the aggregation layer via the following kube-apiserver flags. They may ha
--requestheader-username-headers=X-Remote-User
--proxy-client-cert-file=<path to aggregator proxy cert>
--proxy-client-key-file=<path to aggregator proxy key>
+```
+
<!--
### CA Reusage and Conflicts
The Kubernetes apiserver has two client CA options:
-->
-
-### CA-重用和冲突
+### CA-重用和冲突 {#ca-reusage-and-conflicts}
Kubernetes apiserver 有两个客户端 CA 选项：
@@ -423,40 +415,38 @@ Each of these functions independently and can conflict with each other, if not u
* `--client-ca-file`: When a request arrives to the Kubernetes apiserver, if this option is enabled, the Kubernetes apiserver checks the certificate of the request. If it is signed by one of the CA certificates in the file referenced by `--client-ca-file`, then the request is treated as a legitimate request, and the user is the value of the common name `CN=`, while the group is the organization `O=`. See the [documentaton on TLS authentication](/docs/reference/access-authn-authz/authentication/#x509-client-certs).
* `--requestheader-client-ca-file`: When a request arrives to the Kubernetes apiserver, if this option is enabled, the Kubernetes apiserver checks the certificate of the request. If it is signed by one of the CA certificates in the file reference by `--requestheader-client-ca-file`, then the request is treated as a potentially legitimate request. The Kubernetes apiserver then checks if the common name `CN=` is one of the names in the list provided by `--requestheader-allowed-names`. If the name is allowed, the request is approved; if it is not, the request is not.
-
-If _both_ `--client-ca-file` and `--requestheader-client-ca-file` are provided, then the request first checks the `--requestheader-client-ca-file` CA and then the `--client-ca-file`. Normally, different CAs, either root CAs or intermediate CAs, are used for each of these options; regular client requests match against `--client-ca-file`, while aggregation requests match against `--requestheader-client-ca-file`. However, if both use the _same_ CA, then client requests that normally would pass via `--client-ca-file` will fail, because the CA will match the CA in `--requestheader-client-ca-file`, but the common name `CN=` will **not** match one of the acceptable common names in `--requestheader-allowed-names`. This can cause your kubelets and other control plane components, as well as end-users, to be unable to authenticate to the Kubernetes apiserver.
-
-For this reason, use different CA certs for the `--client-ca-file` option - to authorize control plane components and end-users - and the `--requestheader-client-ca-file` option - to authorize aggregation apiserver requests.
-->
-
这些功能中的每个功能都是独立的；如果使用不正确，可能彼此冲突。
* `--client-ca-file`：当请求到达 Kubernetes apiserver 时，如果启用了此选项，则 Kubernetes apiserver 会检查请求的证书。如果它是由 `--client-ca-file` 引用的文件中的 CA 证书之一签名的，并且用户是公用名`CN=`的值，而组是组织`O=` 的取值，则该请求被视为合法请求。请参阅 [关于 TLS 身份验证的文档](/docs/reference/access-authn-authz/authentication/#x509-client-certs)。
* `--requestheader-client-ca-file`：当请求到达 Kubernetes apiserver 时，如果启用此选项，则 Kubernetes apiserver 会检查请求的证书。如果它是由文件引用中的 --requestheader-client-ca-file 所签署的 CA 证书之一签名的，则该请求将被视为潜在的合法请求。然后，Kubernetes apiserver 检查通用名称`CN=`是否是 --requestheader-allowed-names 提供的列表中的名称之一。如果名称允许，则请求被批准；如果不是，则请求被拒绝。
+<!--
+If _both_ `--client-ca-file` and `--requestheader-client-ca-file` are provided, then the request first checks the `--requestheader-client-ca-file` CA and then the `--client-ca-file`. Normally, different CAs, either root CAs or intermediate CAs, are used for each of these options; regular client requests match against `--client-ca-file`, while aggregation requests match against `--requestheader-client-ca-file`. However, if both use the _same_ CA, then client requests that normally would pass via `--client-ca-file` will fail, because the CA will match the CA in `--requestheader-client-ca-file`, but the common name `CN=` will **not** match one of the acceptable common names in `--requestheader-allowed-names`. This can cause your kubelets and other control plane components, as well as end-users, to be unable to authenticate to the Kubernetes apiserver.
+
+For this reason, use different CA certs for the `--client-ca-file` option - to authorize control plane components and end-users - and the `--requestheader-client-ca-file` option - to authorize aggregation apiserver requests.
+-->
如果同时提供了 `--client-ca-file` 和`--requestheader-client-ca-file`，则首先检查 `--requestheader-client-ca-file` CA，然后再检查`--client-ca-file`。通常，这些选项中的每一个都使用不同的 CA（根 CA 或中间 CA）。常规客户端请求与 --client-ca-file 相匹配，而聚合请求与 `--requestheader-client-ca-file` 相匹配。但是，如果两者都使用同一个 CA，则通常会通过 `--client-ca-file` 传递的客户端请求将失败，因为 CA 将与
`--requestheader-client-ca-file` 中的 CA 匹配，但是通用名称 `CN=` 将不匹配 `--requestheader-allowed-names` 中可接受的通用名称之一。这可能导致您的 kubelet 和其他控制平面组件以及最终用户无法向 Kubernetes apiserver 认证。
因此，请对用于控制平面组件和最终用户鉴权的 `--client-ca-file` 选项和用于聚合 apiserver 鉴权的 `--requestheader-client-ca-file` 选项使用不同的 CA 证书。
-{{< warning >}}
-
<!--
Do **not** reuse a CA that is used in a different context unless you understand the risks and the mechanisms to protect the CA's usage.
-->
-
+{{< warning >}}
除非您了解风险和保护 CA 用法的机制，否则 *不要* 重用在不同上下文中使用的 CA。
-
{{< /warning >}}
+
<!--
If you are not running kube-proxy on a host running the API server, then you must make sure that the system is enabled with the following `kube-apiserver` flag:
-->
-
如果您未在运行 API 服务器的主机上运行 kube-proxy，则必须确保使用以下 `kube-apiserver` 标志启用系统：
- --enable-aggregator-routing=true
-
+```
+--enable-aggregator-routing=true
+```
<!--
### Register APIService objects
@@ -464,13 +454,11 @@ If you are not running kube-proxy on a host running the API server, then you mus
You can dynamically configure what client requests are proxied to extension
apiserver. The following is an example registration:
-->
-
### 注册 APIService 对象
您可以动态配置将哪些客户端请求代理到扩展 apiserver。以下是注册示例：
```yaml
-
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
@@ -485,6 +473,14 @@ spec:
name: < 拓展 Apiserver 服务的 name >
caBundle: < PEM 编码的 CA 证书，用于对 Webhook 服务器的证书签名 >
```
+
+<!--
+The name of an APIService object must be a valid
+[path segment name](/docs/concepts/overview/working-with-objects/names#path-segment-names).
+-->
+APIService 对象的名称必须是合法的
+[路径片段名称](/zh/docs/concepts/overview/working-with-objects/names#path-segment-names)。
+
<!--
#### Contacting the extension apiserver
@@ -499,8 +495,6 @@ Here is an example of an extension apiserver that is configured to be called on
at the subpath "/my-path", and to verify the TLS connection against the ServerName
`my-service-name.my-service-namespace.svc` using a custom CA bundle.
-->
-
-
#### 调用扩展 apiserver
一旦 Kubernetes apiserver 确定应将请求发送到扩展 apiserver，它需要知道如何调用它。
@@ -536,8 +530,8 @@ spec:
* Learn how to [Extend the Kubernetes API Using Custom Resource Definitions](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/).
-->
-* 使用聚合层 [建立扩展 api-server](/zh/docs/tasks/access-kubernetes-api/setup-extension-api-server/)。
-* 有关高级概述，请参阅 [使用聚合层扩展 Kubernetes API](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)。
-* 了解如何 [使用自定义资源扩展 Kubernetes API](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)。
+* 使用聚合层[安装扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)。
+* 有关高级概述，请参阅[使用聚合层扩展 Kubernetes API](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)。
+* 了解如何 [使用自定义资源扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
diff --git a/content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md b/content/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md
similarity index 51%
rename from content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md
rename to content/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md
index 7f2b41da33..8c4a150ffd 100644
--- a/content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md
+++ b/content/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md
@@ -1,64 +1,65 @@
---
title: 配置多个调度器
content_type: task
+weight: 20
---
<!--
----
reviewers:
- davidopp
- madhusudancs
title: Configure Multiple Schedulers
content_type: task
----
+weight: 20
-->
<!-- overview -->
<!--
Kubernetes ships with a default scheduler that is described [here](/docs/admin/kube-scheduler/).
--->
-Kubernetes 自带了一个默认调度器，其详细描述请查阅[这里](/docs/reference/command-line-tools-reference/kube-scheduler/)。
-<!--
If the default scheduler does not suit your needs you can implement your own scheduler.
+Not just that, you can even run multiple schedulers simultaneously alongside
+the default scheduler and instruct Kubernetes what scheduler to use for each
+of your pods. Let's learn how to run multiple schedulers in Kubernetes with an
+example.
-->
-如果默认调度器不适合您的需求，您可以实现自己的调度器。
-<!--
-Not just that, you can even run multiple schedulers simultaneously alongside the default scheduler and instruct Kubernetes what scheduler to use for each of your pods. Let's learn how to run multiple schedulers in Kubernetes with an example.
--->
-不仅如此，您甚至可以伴随着默认调度器同时运行多个调度器，并告诉 Kubernetes 为每个 pod 使用什么调度器。
+Kubernetes 自带了一个默认调度器，其详细描述请查阅
+[这里](/zh/docs/reference/command-line-tools-reference/kube-scheduler/)。
+如果默认调度器不适合你的需求，你可以实现自己的调度器。
+不仅如此，你甚至可以和默认调度器一起同时运行多个调度器，并告诉 Kubernetes 为每个
+Pod 使用哪个调度器。
让我们通过一个例子讲述如何在 Kubernetes 中运行多个调度器。
<!--
-A detailed description of how to implement a scheduler is outside the scope of this document. Please refer to the kube-scheduler implementation in[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/pkg/scheduler)in the Kubernetes source directory for a canonical example.
+A detailed description of how to implement a scheduler is outside the scope of
+this document. Please refer to the kube-scheduler implementation
+in[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{< param
+"githubbranch" >}}/pkg/scheduler)in the Kubernetes source directory for a
+canonical example.
-->
关于实现调度器的具体细节描述超出了本文范围。
-请参考 kube-scheduler 的实现，规范示例代码位于 [pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/pkg/scheduler)。
-
-
-
+请参考 kube-scheduler 的实现，规范示例代码位于
+[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/pkg/scheduler)。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
<!-- steps -->
<!--
## Package the scheduler
+
+Package your scheduler binary into a container image. For the purposes of this example,
+let's just use the default scheduler (kube-scheduler) as our second scheduler as well.
+Clone the [Kubernetes source code from Github](https://github.com/kubernetes/kubernetes)
+and build the source.
-->
## 打包调度器
-<!--
-Package your scheduler binary into a container image. For the purposes of this example,let's just use the default scheduler (kube-scheduler) as our second scheduler as well.
--->
-将调度器二进制文件打包到容器镜像中。出于示例目的，我们就使用默认调度器（kube-scheduler）作为我们的第二个调度器。
-<!--
-Clone the [Kubernetes source code from Github](https://github.com/kubernetes/kubernetes)and build the source.
--->
-从 Github 克隆 [Kubernetes 源代码](https://github.com/kubernetes/kubernetes)，并编译构建源代码。
+将调度器可执行文件打包到容器镜像中。出于示例目的，我们就使用默认调度器
+（kube-scheduler）作为我们的第二个调度器。
+克隆 [Github 上 Kubernetes 源代码](https://github.com/kubernetes/kubernetes)，
+并编译构建源代码。
```shell
git clone https://github.com/kubernetes/kubernetes.git
@@ -77,13 +78,14 @@ ADD ./_output/dockerized/bin/linux/amd64/kube-scheduler /usr/local/bin/kube-sche
```
<!--
-Save the file as `Dockerfile`, build the image and push it to a registry. This example pushes the image to[Google Container Registry (GCR)](https://cloud.google.com/container-registry/).
+Save the file as `Dockerfile`, build the image and push it to a registry. This example
+pushes the image to
+[Google Container Registry (GCR)](https://cloud.google.com/container-registry/).
+For more details, please read the GCR
+[documentation](https://cloud.google.com/container-registry/docs/).
-->
将文件保存为 `Dockerfile`，构建镜像并将其推送到镜像仓库。
此示例将镜像推送到 [Google 容器镜像仓库（GCR）](https://cloud.google.com/container-registry/)。
-<!--
-For more details, please read the GCR[documentation](https://cloud.google.com/container-registry/docs/).
--->
有关详细信息，请阅读 GCR [文档](https://cloud.google.com/container-registry/docs/)。
```shell
@@ -93,29 +95,43 @@ gcloud docker -- push gcr.io/my-gcp-project/my-kube-scheduler:1.0
<!--
## Define a Kubernetes Deployment for the scheduler
+
+Now that we have our scheduler in a container image, we can just create a pod
+config for it and run it in our Kubernetes cluster. But instead of creating a pod
+directly in the cluster, let's use a [Deployment](/docs/concepts/workloads/controllers/deployment/)
+for this example. A [Deployment](/docs/concepts/workloads/controllers/deployment/) manages a
+[Replica Set](/docs/concepts/workloads/controllers/replicaset/) which in turn manages the pods,
+thereby making the scheduler resilient to failures. Here is the deployment
+config. Save it as `my-scheduler.yaml`:
-->
## 为调度器定义 Kubernetes Deployment
-<!--
-Now that we have our scheduler in a container image, we can just create a pod config for it and run it in our Kubernetes cluster. But instead of creating a pod directly in the cluster, let's use a [Deployment](/docs/concepts/workloads/controllers/deployment/)for this example. A [Deployment](/docs/concepts/workloads/controllers/deployment/) manages a[Replica Set](/docs/concepts/workloads/controllers/replicaset/) which in turn manages the pods,thereby making the scheduler resilient to failures. Here is the deployment config. Save it as `my-scheduler.yaml`:
--->
-现在我们将调度器放在容器镜像中，我们可以为它创建一个 pod 配置，并在我们的 Kubernetes 集群中运行它。
-但是与其在集群中直接创建一个 pod，不如使用 [Deployment](/docs/concepts/workloads/controllers/deployment/)。
-[Deployment](/docs/concepts/workloads/controllers/deployment/) 管理一个 [Replica Set](/docs/concepts/workloads/controllers/replicaset/)，Replica Set 再管理 pod，从而使调度器能够适应故障。
-以下是 Deployment 配置，被保存为 `my-scheduler.yaml`：
+现在我们将调度器放在容器镜像中，我们可以为它创建一个 Pod 配置，并在我们的 Kubernetes 集群中
+运行它。但是与其在集群中直接创建一个 Pod，不如使用
+[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)。
+Deployment 管理一个 [ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/)，
+ReplicaSet 再管理 Pod，从而使调度器能够免受一些故障的影响。
+以下是 Deployment 配置，将其保存为 `my-scheduler.yaml`：
{{< codenew file="admin/sched/my-scheduler.yaml" >}}
<!--
-An important thing to note here is that the name of the scheduler specified as an argument to the scheduler command in the container spec should be unique. This is the name that is matched against the value of the optional `spec.schedulerName` on pods, to determine whether this scheduler is responsible for scheduling a particular pod.
+An important thing to note here is that the name of the scheduler specified as an
+argument to the scheduler command in the container spec should be unique.
+This is the name that is matched against the value of the optional `spec.schedulerName`
+on pods, to determine whether this scheduler is responsible for scheduling a particular pod.
-->
-这里需要注意的是，在该部署文件中 Container 的 spec 配置的调度器启动命令参数（--scheduler-name）指定的调度器名称应该是惟一的。
-这个名称应该与 pods 上的可选参数 `spec.schedulerName` 的值相匹配，也就是说调度器名称的匹配关系决定了 pods 的调度任务由哪个调度器负责。
+这里需要注意的是，在容器规约中配置的调度器启动命令参数（--scheduler-name）所指定的
+调度器名称应该是唯一的。
+这个名称应该与 Pod 上的可选参数 `spec.schedulerName` 的值相匹配，也就是说调度器名称的匹配
+关系决定了 Pods 的调度任务由哪个调度器负责。
<!--
-Note also that we created a dedicated service account `my-scheduler` and bind the cluster role`system:kube-scheduler` to it so that it can acquire the same privileges as `kube-scheduler`.
+Note also that we created a dedicated service account `my-scheduler` and bind the cluster role
+`system:kube-scheduler` to it so that it can acquire the same privileges as `kube-scheduler`.
-->
-还要注意，我们创建了一个专用服务帐户 `my-scheduler` 并将集群角色 `system:kube-scheduler` 绑定到它，以便它可以获得与 `kube-scheduler` 相同的权限。
+还要注意，我们创建了一个专用服务账号 `my-scheduler` 并将集群角色 `system:kube-scheduler`
+绑定到它，以便它可以获得与 `kube-scheduler` 相同的权限。
<!--
Please see the[kube-scheduler documentation](/docs/admin/kube-scheduler/) for detailed description of other command line arguments.
@@ -124,12 +140,11 @@ Please see the[kube-scheduler documentation](/docs/admin/kube-scheduler/) for de
<!--
## Run the second scheduler in the cluster
+
+In order to run your scheduler in a Kubernetes cluster, just create the deployment specified in the config above in a Kubernetes cluster:
-->
## 在集群中运行第二个调度器
-<!--
-In order to run your scheduler in a Kubernetes cluster, just create the deployment specified in the config above in a Kubernetes cluster:
--->
为了在 Kubernetes 集群中运行我们的第二个调度器，只需在 Kubernetes 集群中创建上面配置中指定的 Deployment：
```shell
@@ -139,10 +154,15 @@ kubectl create -f my-scheduler.yaml
<!--
Verify that the scheduler pod is running:
-->
-验证调度器 pod 正在运行：
+验证调度器 Pod 正在运行：
```shell
-$ kubectl get pods --namespace=kube-system
+kubectl get pods --namespace=kube-system
+```
+
+输出类似于：
+
+```
NAME READY STATUS RESTARTS AGE
....
my-scheduler-lnf4s-4744f 1/1 Running 0 2m
@@ -152,16 +172,21 @@ my-scheduler-lnf4s-4744f 1/1 Running 0 2m
<!--
You should see a "Running" my-scheduler pod, in addition to the default kube-scheduler pod in this list.
-->
-此列表中，除了默认的 kube-scheduler pod 之外，您应该还能看到处于 “Running” 状态的 my-scheduler pod。
+此列表中，除了默认的 `kube-scheduler` Pod 之外，你应该还能看到处于 “Running” 状态的
+`my-scheduler` Pod。
+
<!--
+### Enable leader election
+
To run multiple-scheduler with leader election enabled, you must do the following:
--->
-要在启用了 leader 选举的情况下运行多调度器，您必须执行以下操作：
-<!--
First, update the following fields in your YAML file:
-->
+### 启用领导者选举
+
+要在启用了 leader 选举的情况下运行多调度器，你必须执行以下操作：
+
首先，更新上述 Deployment YAML（my-scheduler.yaml）文件中的以下字段：
* `--leader-elect=true`
@@ -171,110 +196,98 @@ First, update the following fields in your YAML file:
<!--
If RBAC is enabled on your cluster, you must update the `system:kube-scheduler` cluster role. Add you scheduler name to the resourceNames of the rule applied for endpoints resources, as in the following example:
-->
-如果在集群上启用了 RBAC，则必须更新 `system：kube-scheduler` 集群角色。将调度器名称添加到应用于端点资源的规则的 resourceNames，如以下示例所示：
-```
-$ kubectl edit clusterrole system:kube-scheduler
-- apiVersion: rbac.authorization.k8s.io/v1
- kind: ClusterRole
- metadata:
- annotations:
- rbac.authorization.kubernetes.io/autoupdate: "true"
- labels:
- kubernetes.io/bootstrapping: rbac-defaults
- name: system:kube-scheduler
- rules:
- - apiGroups:
- - ""
- resourceNames:
- - kube-scheduler
- - my-scheduler
- resources:
- - endpoints
- verbs:
- - delete
- - get
- - patch
- - update
+如果在集群上启用了 RBAC，则必须更新 `system：kube-scheduler` 集群角色。
+将调度器名称添加到应用于端点资源的规则的 resourceNames，如以下示例所示：
+
+```shell
+kubectl edit clusterrole system:kube-scheduler
```
+{{< codenew file="admin/sched/clusterrole.yaml" >}}
+
<!--
## Specify schedulers for pods
-->
-## 指定 pod 的调度器
+## 为 Pod 指定调度器
<!--
Now that our second scheduler is running, let's create some pods, and direct them to be scheduled by either the default scheduler or the one we just deployed. In order to schedule a given pod using a specific scheduler, we specify the name of the scheduler in that pod spec. Let's look at three examples.
-->
-现在我们的第二个调度器正在运行，让我们创建一些 pod，并指定它们由默认调度器或我们刚部署的调度器进行调度。
-为了使用特定的调度器调度给定的 pod，我们在那个 pod 的 spec 中指定调度器的名称。让我们看看三个例子。
-
+现在我们的第二个调度器正在运行，让我们创建一些 Pod，并指定它们由默认调度器或我们刚部署的
+调度器进行调度。
+为了使用特定的调度器调度给定的 Pod，我们在那个 Pod 的规约中指定调度器的名称。让我们看看三个例子。
<!--
- Pod spec without any scheduler name
-->
- - Pod spec 没有任何调度器名称
+- Pod spec 没有任何调度器名称
{{< codenew file="admin/sched/pod1.yaml" >}}
-<!--
+ <!--
When no scheduler name is supplied, the pod is automatically scheduled using the default-scheduler.
--->
-如果未提供调度器名称，则会使用 default-scheduler 自动调度 pod。
+ -->
+ 如果未提供调度器名称，则会使用 default-scheduler 自动调度 pod。
-<!--
+ <!--
Save this file as `pod1.yaml` and submit it to the Kubernetes cluster.
--->
-将此文件另存为 `pod1.yaml`，并将其提交给 Kubernetes 集群。
+ -->
+ 将此文件另存为 `pod1.yaml`，并将其提交给 Kubernetes 集群。
-```shell
-kubectl create -f pod1.yaml
-```
+ ```shell
+ kubectl create -f pod1.yaml
+ ```
<!--
- Pod spec with `default-scheduler`
-->
- - Pod spec 设置为 `default-scheduler`
+- Pod spec 设置为 `default-scheduler`
{{< codenew file="admin/sched/pod2.yaml" >}}
-<!--
+ <!--
A scheduler is specified by supplying the scheduler name as a value to `spec.schedulerName`. In this case, we supply the name of the default scheduler which is `default-scheduler`.
--->
-通过将调度器名称作为 `spec.schedulerName` 参数的值来指定调度器。在这种情况下，我们提供默认调度器的名称，即 `default-scheduler`。
+ -->
+ 通过将调度器名称作为 `spec.schedulerName` 参数的值来指定调度器。
+ 在这种情况下，我们提供默认调度器的名称，即 `default-scheduler`。
-<!--
+ <!--
Save this file as `pod2.yaml` and submit it to the Kubernetes cluster.
--->
-将此文件另存为 `pod2.yaml`，并将其提交给 Kubernetes 集群。
+ -->
+ 将此文件另存为 `pod2.yaml`，并将其提交给 Kubernetes 集群。
-```shell
-kubectl create -f pod2.yaml
-```
+ ```shell
+ kubectl create -f pod2.yaml
+ ```
<!--
- Pod spec with `my-scheduler`
-->
- - Pod spec 设置为 `my-scheduler`
+- Pod spec 设置为 `my-scheduler`
{{< codenew file="admin/sched/pod3.yaml" >}}
-<!--
- In this case, we specify that this pod should be scheduled using the scheduler that we deployed - `my-scheduler`. Note that the value of `spec.schedulerName` should match the name supplied to the scheduler command as an argument in the deployment config for the scheduler.
--->
-在这种情况下，我们指定此 pod 使用我们部署的 `my-scheduler` 来调度。
-请注意，`spec.schedulerName` 参数的值应该与 Deployment 中配置的提供给 scheduler 命令的参数名称匹配。
+ <!--
+ In this case, we specify that this pod should be scheduled using the
+ scheduler that we deployed - `my-scheduler`. Note that the value of
+ `spec.schedulerName` should match the name supplied to the scheduler command
+ as an argument in the deployment config for the scheduler.
+ -->
+ 在这种情况下，我们指定此 pod 使用我们部署的 `my-scheduler` 来调度。
+ 请注意，`spec.schedulerName` 参数的值应该与 Deployment 中配置的提供给
+ scheduler 命令的参数名称匹配。
-<!--
+ <!--
Save this file as `pod3.yaml` and submit it to the Kubernetes cluster.
--->
-将此文件另存为 `pod3.yaml`，并将其提交给 Kubernetes 集群。
+ -->
+ 将此文件另存为 `pod3.yaml`，并将其提交给 Kubernetes 集群。
-```shell
-kubectl create -f pod3.yaml
-```
+ ```shell
+ kubectl create -f pod3.yaml
+ ```
<!--
- Verify that all three pods are running.
+Verify that all three pods are running.
-->
确认所有三个 pod 都在运行。
@@ -282,8 +295,6 @@ kubectl create -f pod3.yaml
kubectl get pods
```
-
-
<!-- discussion -->
<!--
@@ -294,18 +305,19 @@ kubectl get pods
<!--
In order to make it easier to work through these examples, we did not verify that the pods were actually scheduled using the desired schedulers. We can verify that by changing the order of pod and deployment config submissions above. If we submit all the pod configs to a Kubernetes cluster before submitting the scheduler deployment config,we see that the pod `annotation-second-scheduler` remains in "Pending" state forever while the other two pods get scheduled. Once we submit the scheduler deployment config and our new scheduler starts running, the `annotation-second-scheduler` pod gets scheduled as well.
-->
-为了更容易地完成这些示例，我们没有验证 pod 实际上是使用所需的调度程序调度的。
-我们可以通过更改 pod 的顺序和上面的部署配置提交来验证这一点。
-如果我们在提交调度器部署配置之前将所有 pod 配置提交给 Kubernetes 集群，我们将看到注解了 `annotation-second-scheduler` 的 pod 始终处于 “Pending” 状态，而其他两个 pod 被调度。
-一旦我们提交调度器部署配置并且我们的新调度器开始运行，注解了 `annotation-second-scheduler` 的 pod 就能被调度。
-
+为了更容易地完成这些示例，我们没有验证 Pod 实际上是使用所需的调度程序调度的。
+我们可以通过更改 Pod 的顺序和上面的部署配置提交来验证这一点。
+如果我们在提交调度器部署配置之前将所有 Pod 配置提交给 Kubernetes 集群，
+我们将看到注解了 `annotation-second-scheduler` 的 Pod 始终处于 “Pending” 状态，
+而其他两个 Pod 被调度。
+一旦我们提交调度器部署配置并且我们的新调度器开始运行，注解了
+`annotation-second-scheduler` 的 pod 就能被调度。
<!--
Alternatively, one could just look at the "Scheduled" entries in the event logs to verify that the pods were scheduled by the desired schedulers.
-->
-或者，可以查看事件日志中的 “Scheduled” 条目，以验证是否由所需的调度器调度了 pod。
+或者，可以查看事件日志中的 “Scheduled” 条目，以验证是否由所需的调度器调度了 Pod。
```shell
kubectl get events
```
-
diff --git a/content/zh/docs/tasks/extend-kubernetes/custom-resources/_index.md b/content/zh/docs/tasks/extend-kubernetes/custom-resources/_index.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md b/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md
index 11ec974476..c479dce83f 100644
--- a/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md
+++ b/content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md
@@ -1,21 +1,17 @@
---
-title: 用户自定义资源版本
-reviewers:
-- mbohlool
-- sttts
-- liggitt
+title: 用户自定义资源的版本
content_type: task
weight: 30
+min-kubernetes-server-version: v1.16
---
<!--
----
title: Versions in CustomResourceDefinitions
reviewers:
- sttts
- liggitt
content_type: task
weight: 30
----
+min-kubernetes-server-version: v1.16
-->
<!-- overview -->
@@ -24,28 +20,22 @@ This page explains how to add versioning information to
[CustomResourceDefinitions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions), to indicate the stability
level of your CustomResourceDefinitions or advance your API to a new version with conversion between API representations. It also describes how to upgrade an object from one version to another.
-->
-
-本页介绍了如何添加版本信息到 [CustomResourceDefinitions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions)，如何表示 CustomResourceDefinitions 的稳定水平或者用 API 之间的表征的转换提高您的 API 到一个新的版本。它还描述了如何将对象从一个版本升级到另一个版本。
-
-
+本页介绍如何添加版本信息到
+[CustomResourceDefinitions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions)，
+如何表示 CustomResourceDefinitions 的稳定水平或者用 API 之间的表征的转换提高您的 API 到一个新的版本。
+本页还描述如何将对象从一个版本升级到另一个版本。
## {{% heading "prerequisites" %}}
-
-{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+{{< include "task-tutorial-prereqs.md" >}}
<!--
-* Make sure your Kubernetes cluster has a master version of 1.16.0 or higher for `apiextensions.k8s.io/v1`, or 1.11.0 or higher for `apiextensions.k8s.io/v1beta1`.
+You should have a initial understanding of [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
-->
-* 确保您的 Kubernetes 集群的主版本为`apiextensions.k8s.io/v1`的1.16.0或更高版本，`apiextensions.k8s.io/v1beta1`的1.11.0或更高版本。
-
-<!--
-* Read about [custom resources](/docs/concepts/api-extension/custom-resources/).
--->
-
-* 阅读 [custom resources](/docs/concepts/api-extension/custom-resources/)。
-
+你应该对[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+有一些初步了解。
+{{< version-check >}}
<!-- steps -->
@@ -54,8 +44,6 @@ level of your CustomResourceDefinitions or advance your API to a new version wit
-->
## 概览
-{{< feature-state state="stable" for_kubernetes_version="1.16" >}}
-
<!--
The CustomResourceDefinition API provides a workflow for introducing and upgrading
to new versions of a CustomResourceDefinition.
@@ -70,7 +58,16 @@ Once the CustomResourceDefinition is created, clients may begin using the
`v1beta1` API.
Later it might be necessary to add new version such as `v1`.
+-->
+CustomResourceDefinition API 提供了用于引入和升级的工作流程到 CustomResourceDefinition 的新版本。
+创建 CustomResourceDefinition 时，会在 CustomResourceDefinition `spec.versions` 列表设置适当的稳定级和版本号。例如`v1beta1`表示第一个版本尚未稳定。所有自定义资源对象将首先存储在这个版本
+
+创建 CustomResourceDefinition 后，客户端可以开始使用 v1beta1 API。
+
+稍后可能需要添加新版本，例如 v1。
+
+<!--
Adding a new version:
1. Pick a conversion strategy. Since custom resource objects need to be able to
@@ -88,7 +85,17 @@ Adding a new version:
`spec.versions` list with `served:true`. Also, set `spec.conversion` field
to the selected conversion strategy. If using a conversion webhook, configure
`spec.conversion.webhookClientConfig` field to call the webhook.
+-->
+增加一个新版本：
+1. 选择一种转化策略。由于自定义资源对象需要能够两种版本都可用，这意味着它们有时会以与存储版本不同的版本。为了能够做到这一点，
+ 有时必须在它们存储的版本和提供的版本。如果转换涉及结构变更，并且需要自定义逻辑，转换应该使用 webhook。如果没有结构变更，
+ 则使用 None 默认转换策略，不同版本时只有`apiVersion`字段有变更。
+2. 如果使用转换 Webhook，请创建并部署转换 Webhook。希望看到更多详细信息，请参见 [Webhook conversion](#webhook转换)。
+3. 更新 CustomResourceDefinition，来将新版本包含在具有`served：true`的 spec.versions 列表。另外，设置`spec.conversion`字段
+ 到所选的转换策略。如果使用转换 Webhook，请配置`spec.conversion.webhookClientConfig`来调用 webhook。
+
+<!--
Once the new version is added, clients may incrementally migrate to the new
version. It is perfectly safe for some clients to use the old version while
others use the new version.
@@ -99,7 +106,16 @@ Migrate stored objects to the new version:
It is safe for clients to use both the old and new version before, during and
after upgrading the objects to a new stored version.
+-->
+添加新版本后，客户端可以逐步迁移到新版本。对于某些客户而言，在使用旧版本的同时支持其他人使用新版本。
+将存储的对象迁移到新版本：
+
+1. 请参阅 [将现有对象升级到新的存储版本](#将现有对象升级到新的存储版本) 章节。
+
+对于客户来说，在将对象升级到新的存储版本之前，期间和之后使用旧版本和新版本都是安全的。
+
+<!--
Removing an old version:
1. Ensure all clients are fully migrated to the new version. The kube-apiserver
@@ -115,39 +131,7 @@ Removing an old version:
1. Verify that the old version is no longer listed in the CustomResourceDefinition `status.storedVersions`.
1. Remove the old version from the CustomResourceDefinition `spec.versions` list.
1. Drop conversion support for the old version in conversion webhooks.
-
-## Specify multiple versions
-
-The CustomResourceDefinition API `versions` field can be used to support multiple versions of custom resources that you
-have developed. Versions can have different schemas, and conversion webhooks can convert custom resources between versions.
-Webhook conversions should follow the [Kubernetes API conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md) wherever applicable.
-Specifically, See the [API change documentation](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md) for a set of useful gotchas and suggestions.
-->
-CustomResourceDefinition API 提供了用于引入和升级的工作流程到 CustomResourceDefinition 的新版本。
-
-创建 CustomResourceDefinition 时，会在 CustomResourceDefinition `spec.versions` 列表设置适当的稳定级和版本号。例如`v1beta1`表示第一个版本尚未稳定。所有自定义资源对象将首先存储在这个版本
-
-创建 CustomResourceDefinition 后，客户端可以开始使用 v1beta1 API。
-
-稍后可能需要添加新版本，例如 v1。
-
-增加一个新版本：
-
-1. 选择一种转化策略。由于自定义资源对象需要能够两种版本都可用，这意味着它们有时会以与存储版本不同的版本。为了能够做到这一点，
- 有时必须在它们存储的版本和提供的版本。如果转换涉及结构变更，并且需要自定义逻辑，转换应该使用 webhook。如果没有结构变更，
- 则使用 None 默认转换策略，不同版本时只有`apiVersion`字段有变更。
-2. 如果使用转换 Webhook，请创建并部署转换 Webhook。希望看到更多详细信息，请参见 [Webhook conversion](#webhook转换)。
-3. 更新 CustomResourceDefinition，来将新版本包含在具有`served：true`的 spec.versions 列表。另外，设置`spec.conversion`字段
- 到所选的转换策略。如果使用转换 Webhook，请配置`spec.conversion.webhookClientConfig`来调用 webhook。
-
-添加新版本后，客户端可以逐步迁移到新版本。对于某些客户而言，在使用旧版本的同时支持其他人使用新版本。
-
-将存储的对象迁移到新版本：
-
-1. 请参阅 [将现有对象升级到新的存储版本](#将现有对象升级到新的存储版本) 章节。
-
-对于客户来说，在将对象升级到新的存储版本之前，期间和之后使用旧版本和新版本都是安全的。
-
删除旧版本：
1. 确保所有客户端都已完全迁移到新版本。kube-apiserver 可以查看日志以帮助识别仍通过进行访问的所有客户端旧版本。
@@ -159,17 +143,28 @@ CustomResourceDefinition API 提供了用于引入和升级的工作流程到 Cu
4. 从 CustomResourceDefinition`spec.versions` 列表中删除旧版本。
5. 在转换 webhooks 中放弃对旧版本的转换支持。
-## 指定多个版本
+<!--
+## Specify multiple versions
+
+The CustomResourceDefinition API `versions` field can be used to support multiple versions of custom resources that you
+have developed. Versions can have different schemas, and conversion webhooks can convert custom resources between versions.
+Webhook conversions should follow the [Kubernetes API conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md) wherever applicable.
+Specifically, See the [API change documentation](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md) for a set of useful gotchas and suggestions.
+-->
+## 指定多个版本 {#specify-multiple-versions}
CustomResourceDefinition API 的`versions`字段可用于支持您自定义资源的多个版本已经开发的。版本可以具有不同的架构，并且转换 Webhooks 可以在版本之间转换自定义资源。
在适用的情况下，Webhook 转换应遵循 [Kubernetes API](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md)。
-{{< note >}}
+<!--
In `apiextensions.k8s.io/v1beta1`, there was a `version` field instead of `versions`. The
`version` field is deprecated and optional, but if it is not empty, it must
match the first item in the `versions` field.
-
-
+-->
+{{< note >}}
+在 `apiextensions.k8s.io/v1beta1` 版本中，有一个 `version` 字段，名字不叫做 `versions`。
+`version` 字段已经被废弃，成为可选项。不过如果该字段不是空，则必须与
+`versions` 字段中的第一个条目匹配。
{{< /note >}}
<!--
@@ -177,13 +172,13 @@ This example shows a CustomResourceDefinition with two versions. For the first
example, the assumption is all versions share the same schema with no conversion
between them. The comments in the YAML provide more context.
-->
-
此示例显示了两个版本的 CustomResourceDefinition。第一个例子，假设所有的版本共享相同的模式而它们之间没有转换。YAML 中的评论提供了更多背景信息。
+
{{< tabs name="CustomResourceDefinition_versioning_example_1" >}}
{{% tab name="apiextensions.k8s.io/v1" %}}
```yaml
-apiVersion: apiextensions.k8s.io/v1beta1
+apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
# name must match the spec fields below, and be in the form: <plural>.<group>
@@ -304,21 +299,19 @@ After creation, the API server starts to serve each enabled version at an HTTP
REST endpoint. In the above example, the API versions are available at
`/apis/example.com/v1beta1` and `/apis/example.com/v1`.
-->
-
-在创建之后，apiserver 开始在 HTTP REST 端点上为每个启用的版本提供服务。在上面的示例中，API 版本可以在`/apis/example.com/v1beta1` 和 `/apis/example.com/v1`中获得。
+在创建之后，apiserver 开始在 HTTP REST 端点上为每个启用的版本提供服务。
+在上面的示例中，API 版本可以在`/apis/example.com/v1beta1` 和 `/apis/example.com/v1`中获得。
<!--
### Version priority
--->
-### 版本优先级
-<!--
Regardless of the order in which versions are defined in a
CustomResourceDefinition, the version with the highest priority is used by
kubectl as the default version to access objects. The priority is determined
by parsing the _name_ field to determine the version number, the stability
(GA, Beta, or Alpha), and the sequence within that stability level.
-->
+### 版本优先级
不考虑 CustomResourceDefinition 中版本被定义的顺序，kubectl 使用具有最高优先级的版本作为访问对象的默认版本。
通过解析 _name_ 字段确定优先级来决定版本号，稳定性（GA，Beta，或者 Alpha），以及该稳定性水平内的序列。
@@ -352,9 +345,11 @@ like `v2` or `v2beta1`. Versions are sorted using the following algorithm:
-->
- 遵循 Kubernetes 版本模式的条目在不符合条件的条目之前进行排序。
- 对于遵循 Kubernetes 版本模式的条目，版本字符串的数字部分从最大到最小排序。
-- 如果字符串`beta` 或 `alpha`跟随第一数字部分，它们按顺序排序，在没有`beta` 或 `alpha`后缀（假定为 GA 版本）的等效字符串后面。
+- 如果字符串 `beta` 或 `alpha` 跟随第一数字部分，它们按顺序排序，在没有 `beta` 或 `alpha`
+ 后缀（假定为 GA 版本）的等效字符串后面。
- 如果另一个数字跟在`beta`或`alpha`之后，那么这些数字也是从最大到最小排序。
-- 不符合上述格式的字符串按字母顺序排序，数字部分不经过特殊处理。请注意，在下面的示例中，`foo1`在 `foo10`上方排序。这与遵循 Kubernetes 版本模式的条目的数字部分排序不同。
+- 不符合上述格式的字符串按字母顺序排序，数字部分不经过特殊处理。
+ 请注意，在下面的示例中，`foo1`在 `foo10`上方排序。这与遵循 Kubernetes 版本模式的条目的数字部分排序不同。
<!--
This might make sense if you look at the following sorted version list:
@@ -380,24 +375,24 @@ version sort order is `v1`, followed by `v1beta1`. This causes the kubectl
command to use `v1` as the default version unless the provided object specifies
the version.
-->
-
-对于 [指定多个版本](#指定多个版本) 中的示例，版本排序顺序为`v1`，后跟着`v1beta1`。
-这导致了 kubectl 命令使用`v1`作为默认版本，除非提供对象指定版本。
+对于 [指定多个版本](#specify-multiple-versions) 中的示例，版本排序顺序为 `v1`，后跟着 `v1beta1`。
+这导致了 kubectl 命令使用 `v1` 作为默认版本，除非提供对象指定版本。
<!--
## Webhook conversion
+
+Webhook conversion is available as beta since 1.15, and as alpha since Kubernetes 1.13. The
+`CustomResourceWebhookConversion` feature should be enabled. Please refer to the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) documentation for more information.
-->
## Webhook转换
-<!--
-Webhook conversion is introduced in Kubernetes 1.13 as an alpha feature. To use it, the
-`CustomResourceWebhookConversion` feature should be enabled. Please refer to the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) documentation for more information.
--->
+{{< feature-state state="stable" for_k8s_version="v1.16" >}}
{{< note >}}
-
-Webhook 转换在 Kubernetes 1.13 中作为 alpha 功能引入。要使用它，应启用`CustomResourceWebhookConversion`功能。请参阅 [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) 文档以获得更多信息。
-
+Webhook 转换在 Kubernetes 1.15 中作为 beta 功能。
+要使用它，应启用`CustomResourceWebhookConversion`功能。
+在大多数集群上，这类 beta 特性应该时自动启用的。
+请参阅[特行门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) 文档以获得更多信息。
{{< /note >}}
<!--
@@ -423,10 +418,7 @@ To cover all of these cases and to optimize conversion by the API server, the co
<!--
### Write a conversion webhook server
--->
-### 编写一个转换webhook服务
-<!--
Please refer to the implementation of the [custom resource conversion webhook
server](https://github.com/kubernetes/kubernetes/tree/v1.15.0/test/images/crd-conversion-webhook/main.go)
that is validated in a Kubernetes e2e test. The webhook handles the
@@ -436,8 +428,9 @@ contains a list of custom resources that need to be converted independently with
changing the order of objects.
The example server is organized in a way to be reused for other conversions. Most of the common code are located in the [framework file](https://github.com/kubernetes/kubernetes/tree/v1.15.0/test/images/crd-conversion-webhook/converter/framework.go) that leaves only [one function](https://github.com/kubernetes/kubernetes/blob/v1.15.0/test/images/crd-conversion-webhook/converter/example_converter.go#L29-L80) to be implemented for different conversions.
-->
+### 编写一个转换 Webhook 服务器
-请参考 [自定义资源转换 webhook 服务](https://github.com/kubernetes/kubernetes/tree/v1.13.0/test/images/crd-conversion-webhook/main.go) 的实施，这在 Kubernetes e2e 测试中得到验证。webhook 处理由 apiserver 发送的`ConversionReview`请求，并发送回包含在`ConversionResponse`中的转换结果。请注意，请求包含需要独立转换不改变对象顺序的自定义资源列表。示例服务器的组织方式使其可以重用于其他转换。大多数常见代码都位于 [框架文件](https://github.com/kubernetes/kubernetes/tree/v1.14.0/test/images/crd-conversion-webhook/converter/framework.go) 中，只留下 [示例](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/images/crd-conversion-webhook/converter/example_converter.go#L29-L80) 用于实施不同的转换。
+请参考[自定义资源转换 webhook 服务](https://github.com/kubernetes/kubernetes/tree/v1.15.0/test/images/crd-conversion-webhook/main.go) 的实施，这在 Kubernetes e2e 测试中得到验证。webhook 处理由 apiserver 发送的`ConversionReview`请求，并发送回包含在`ConversionResponse`中的转换结果。请注意，请求包含需要独立转换不改变对象顺序的自定义资源列表。示例服务器的组织方式使其可以重用于其他转换。大多数常见代码都位于 [框架文件](https://github.com/kubernetes/kubernetes/tree/v1.14.0/test/images/crd-conversion-webhook/converter/framework.go) 中，只留下 [示例](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/images/crd-conversion-webhook/converter/example_converter.go#L29-L80) 用于实施不同的转换。
<!--
The example conversion webhook server leaves the `ClientAuth` field
@@ -447,27 +440,27 @@ authenticate the identity of the clients, supposedly API servers. If you need
mutual TLS or other ways to authenticate the clients, see
how to [authenticate API servers](/docs/reference/access-authn-authz/extensible-admission-controllers/#authenticate-apiservers).
-->
-
{{< note >}}
-
-示例转换 webhook 服务器留下`ClientAuth`字段 [empty](https://github.com/kubernetes/kubernetes/tree/v1.13.0/test/images/crd-conversion-webhook/config.go#L47-L48)，默认为`NoClientCert`。
+示例转换 webhook 服务器留下`ClientAuth`字段为
+[空](https://github.com/kubernetes/kubernetes/tree/v1.13.0/test/images/crd-conversion-webhook/config.go#L47-L48)，
+默认为`NoClientCert`。
这意味着 webhook 服务器没有验证客户端的身份，据称是 apiserver。
-如果您需要相互 TLS 或者其他方式来验证客户端，请参阅如何 [验证 API 服务](/docs/reference/access-authn-authz/extensible-admission-controllers/#authenticate-apiservers)。
-
+如果您需要相互 TLS 或者其他方式来验证客户端，请参阅如何
+[验证 API 服务](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#authenticate-apiservers)。
{{< /note >}}
<!--
### Deploy the conversion webhook service
--->
-### 部署转换webhook服务
-<!--
Documentation for deploying the conversion webhook is the same as for the [admission webhook example service](/docs/reference/access-authn-authz/extensible-admission-controllers/#deploy_the_admission_webhook_service).
The assumption for next sections is that the conversion webhook server is deployed to a service named `example-conversion-webhook-server` in `default` namespace and serving traffic on path `/crdconvert`.
-->
-用于部署转换 webhook 的文档与 [准入webhook示例服务](/docs/reference/access-authn-authz/extensible-admission-controllers/#deploy_the_admission_webhook_service)。
+### 部署转换 Webhook 服务
+
+用于部署转换 webhook 的文档与
+[准入webhook示例服务](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#deploy_the_admission_webhook_service)。
下一节的假设是转换 webhook 服务器部署到`default`命名空间中名为`example-conversion-webhook-server`的服务器上，并在路径`/crdconvert`上提供流量。
<!--
@@ -484,14 +477,13 @@ if a different port is used for the service.
<!--
### Configure CustomResourceDefinition to use conversion webhooks
--->
-### 配置CustomResourceDefinition以使用转换webhooks
-<!--
The `None` conversion example can be extended to use the conversion webhook by modifying `conversion`
section of the `spec`:
-->
-通过修改`spec`中的`conversion`部分，可以扩展`None`转换示例来使用转换 webhook。
+### 配置 CustomResourceDefinition 以使用转换 Webhook
+
+通过修改 `spec` 中的 `conversion` 部分，可以扩展 `None` 转换示例来使用转换 webhook。
{{< tabs name="CustomResourceDefinition_versioning_example_2" >}}
{{% tab name="apiextensions.k8s.io/v1" %}}
@@ -641,11 +633,7 @@ Make sure the conversion service is up and running before applying new changes.
<!--
### Contacting the webhook
--->
-### 调用-webhook
-
-<!--
Once the API server has determined a request should be sent to a conversion webhook,
it needs to know how to contact the webhook. This is specified in the `webhookClientConfig`
stanza of the webhook configuration.
@@ -653,10 +641,12 @@ stanza of the webhook configuration.
Conversion webhooks can either be called via a URL or a service reference,
and can optionally include a custom CA bundle to use to verify the TLS connection.
-->
+### 调用 Webhook
apiserver 一旦确定请求应发送到转换 webhook，它需要知道如何调用 webhook。这是在`webhookClientConfig`中指定的 webhook 配置。
转换 webhook 可以通过调用 URL 或服务，并且可以选择包含自定义 CA 包，以用于验证 TLS 连接。
+
### URL
<!--
@@ -744,8 +734,6 @@ Here is an example of a webhook that is configured to call a service on port "12
at the subpath "/my-path", and to verify the TLS connection against the ServerName
`my-service-name.my-service-namespace.svc` using a custom CA bundle.
-->
-
-
### 服务引用
`webhookClientConfig`内部的`service`段是对转换 webhook 服务的引用。如果 Webhook 在集群中运行，则应使用`service`而不是`url`。
@@ -796,6 +784,7 @@ spec:
```
{{% /tab %}}
{{< /tabs >}}
+
<!--
## Webhook request and response
@@ -808,8 +797,7 @@ serialized to JSON as the body.
Webhooks can specify what versions of `ConversionReview` objects they accept
with the `conversionReviewVersions` field in their CustomResourceDefinition:
-->
-
-## Webhook-请求和响应
+## Webhook 请求和响应
### 请求
@@ -1112,7 +1100,6 @@ should be avoided whenever possible, and should not be used to enforce validatio
<!--
Example of a response from a webhook indicating a conversion request failed, with an optional message:
-->
-
来自 Webhook 的响应示例，指示转换请求失败，并带有可选消息：
{{< tabs name="ConversionReview_response_failure" >}}
diff --git a/content/zh/docs/tasks/extend-kubernetes/setup-extension-api-server.md b/content/zh/docs/tasks/extend-kubernetes/setup-extension-api-server.md
index dd162bdc15..38aba0c76f 100644
--- a/content/zh/docs/tasks/extend-kubernetes/setup-extension-api-server.md
+++ b/content/zh/docs/tasks/extend-kubernetes/setup-extension-api-server.md
@@ -1,15 +1,10 @@
---
-title: 设置一个扩展的 API server
-reviewers:
-- lavalamp
-- cheftako
-- chenopis
+title: 安装一个扩展的 API server
content_type: task
weight: 15
---
<!--
----
title: Setup an extension API server
reviewers:
- lavalamp
@@ -17,7 +12,6 @@ reviewers:
- chenopis
content_type: task
weight: 15
----
-->
<!-- overview -->
@@ -25,28 +19,18 @@ weight: 15
<!--
Setting up an extension API server to work the aggregation layer allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs.
-->
-设置一个扩展的 API server 来使用聚合层以让 Kubernetes apiserver 使用其它 API 进行扩展，这些 API 不是核心 Kubernetes API 的一部分。
-
-
+安装扩展的 API 服务器来使用聚合层以让 Kubernetes API 服务器使用其它 API 进行扩展，
+这些 API 不是核心 Kubernetes API 的一部分。
## {{% heading "prerequisites" %}}
-
-<!--
-* You need to have a Kubernetes cluster running.
-* You must [configure the aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) and enable the apiserver flags.
--->
-* 您需要拥有一个运行的 Kubernetes 集群。
-* 您必须 [配置聚合层](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) 并且启用 apiserver 的相关参数。
-
-
-
-## {{% heading "prerequisites" %}}
-
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
+<!--
+* You must [configure the aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) and enable the apiserver flags.
+-->
+* 你必须[配置聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
+ 并且启用 API 服务器的相关参数。
<!-- steps -->
@@ -57,55 +41,76 @@ The following steps describe how to set up an extension-apiserver *at a high lev
Alternatively, you can use an existing 3rd party solution, such as [apiserver-builder](https://github.com/Kubernetes-incubator/apiserver-builder/blob/master/README.md), which should generate a skeleton and automate all of the following steps for you.
-->
-## 设置一个扩展的 api-server 来使用聚合层
+## 安装一个扩展的 API 服务器来使用聚合层
-以下步骤描述如何 *在一个高层次* 设置一个扩展的 apiserver。无论您使用的是 YAML 配置还是使用 API，这些步骤都适用。目前我们正在尝试区分出两者的区别。有关使用 YAML 配置的具体示例，您可以在 Kubernetes 库中查看 [sample-apiserver](https://github.com/kubernetes/sample-apiserver/blob/master/README.md)。
+以下步骤描述如何 *在一个高层次* 设置一个扩展的 apiserver。无论你使用的是 YAML 配置还是使用 API，这些步骤都适用。
+目前我们正在尝试区分出两者的区别。有关使用 YAML 配置的具体示例，你可以在 Kubernetes 库中查看
+[sample-apiserver](https://github.com/kubernetes/sample-apiserver/blob/master/README.md)。
-或者，您可以使用现有的第三方解决方案，例如 [apiserver-builder](https://github.com/Kubernetes-incubator/apiserver-builder/blob/master/README.md)，它将生成框架并自动执行以下所有步骤。
+或者，你可以使用现有的第三方解决方案，例如
+[apiserver-builder](https://github.com/Kubernetes-incubator/apiserver-builder/blob/master/README.md)，
+它将生成框架并自动执行以下所有步骤。
<!--
-1. Make sure the APIService API is enabled (check `--runtime-config`). It should be on by default, unless it's been deliberately turned off in your cluster.
+1. Make sure the APIService API is enabled (check `-runtime-config`). It should be on by default, unless it's been deliberately turned off in your cluster.
1. You may need to make an RBAC rule allowing you to add APIService objects, or get your cluster administrator to make one. (Since API extensions affect the entire cluster, it is not recommended to do testing/development/debug of an API extension in a live cluster.)
1. Create the Kubernetes namespace you want to run your extension api-service in.
1. Create/get a CA cert to be used to sign the server cert the extension api-server uses for HTTPS.
1. Create a server cert/key for the api-server to use for HTTPS. This cert should be signed by the above CA. It should also have a CN of the Kube DNS name. This is derived from the Kubernetes service and be of the form `<service name>.<service name namespace>.svc`
1. Create a Kubernetes secret with the server cert/key in your namespace.
1. Create a Kubernetes deployment for the extension api-server and make sure you are loading the secret as a volume. It should contain a reference to a working image of your extension api-server. The deployment should also be in your namespace.
+-->
+1. 确保启用了 APIService API（检查 `--runtime-config`）。默认应该是启用的，除非被特意关闭了。
+2. 你可能需要制定一个 RBAC 规则，以允许你添加 APIService 对象，或让你的集群管理员创建一个。
+ （由于 API 扩展会影响整个集群，因此不建议在实时集群中对 API 扩展进行测试/开发/调试）
+3. 创建 Kubernetes 命名空间，扩展的 api-service 将运行在该命名空间中。
+4. 创建（或获取）用来签署服务器证书的 CA 证书，扩展 api-server 中将使用该证书做 HTTPS 连接。
+5. 为 api-server 创建一个服务端的证书（或秘钥）以使用 HTTPS。这个证书应该由上述的 CA 签署。
+ 同时应该还要有一个 Kube DNS 名称的 CN，这是从 Kubernetes 服务派生而来的，
+ 格式为 `<service name>.<service name namespace>.svc`。
+6. 使用命名空间中的证书（或秘钥）创建一个 Kubernetes secret。
+7. 为扩展 api-server 创建一个 Kubernetes Deployment，并确保以卷的方式挂载了 Secret。
+ 它应该包含对扩展 api-server 镜像的引用。Deployment 也应该在同一个命名空间中。
+
+<!--
1. Make sure that your extension-apiserver loads those certs from that volume and that they are used in the HTTPS handshake.
1. Create a Kubernetes service account in your namespace.
1. Create a Kubernetes cluster role for the operations you want to allow on your resources.
1. Create a Kubernetes cluster role binding from the service account in your namespace to the cluster role you just created.
1. Create a Kubernetes cluster role binding from the service account in your namespace to the `system:auth-delegator` cluster role to delegate auth decisions to the Kubernetes core API server.
1. Create a Kubernetes role binding from the service account in your namespace to the `extension-apiserver-authentication-reader` role. This allows your extension api-server to access the `extension-apiserver-authentication` configmap.
+-->
+8. 确保你的扩展 apiserver 从该卷中加载了那些证书，并在 HTTPS 握手过程中使用它们。
+9. 在你的命令空间中创建一个 Kubernetes 服务账号。
+10. 为资源允许的操作创建 Kubernetes 集群角色。
+11. 用你命令空间中的服务账号创建一个 Kubernetes 集群角色绑定，绑定到你刚创建的角色上。
+12. 用你命令空间中的服务账号创建一个 Kubernetes 集群角色绑定，绑定到 `system:auth-delegator`
+ 集群角色，以将 auth 决策委派给 Kubernetes 核心 API 服务器。
+13. 以你命令空间中的服务账号创建一个 Kubernetes 集群角色绑定，绑定到
+ `extension-apiserver-authentication-reader` 角色。
+ 这将让你的扩展 api-server 能够访问 `extension-apiserver-authentication` configmap。
+
+<!--
1. Create a Kubernetes apiservice. The CA cert above should be base64 encoded, stripped of new lines and used as the spec.caBundle in the apiservice. This should not be namespaced. If using the [kube-aggregator API](https://github.com/kubernetes/kube-aggregator/), only pass in the PEM encoded CA bundle because the base 64 encoding is done for you.
1. Use kubectl to get your resource. When run, kubectl should return "No resources found.". This message indicates that everything worked but you currently have no objects of that resource type created.
-->
-1. 确保启用了 APIService API（检查 `--runtime-config`）。默认应该是启用的，除非被特意关闭了。
-1. 您可能需要制定一个 RBAC 规则，以允许您添加 APIService 对象，或让您的集群管理员创建一个。（由于 API 扩展会影响整个集群，因此不建议在实时集群中对 API 扩展进行测试/开发/调试）
-1. 创建 Kubernetes 命名空间，扩展的 api-service 将运行在该命名空间中。
-1. 创建（或获取）用来签署服务器证书的 CA 证书，扩展 api-server 中将使用该证书做 HTTPS 连接。
-1. 为 api-server 创建一个服务端的证书（或秘钥）以使用 HTTPS。这个证书应该由上述的 CA 签署。同时应该还要有一个 Kube DNS 名称的 CN，这是从 Kubernetes 服务派生而来的，格式为 `<service name>.<service name namespace>.svc`。
-1. 使用命名空间中的证书（或秘钥）创建一个 Kubernetes secret。
-1. 为扩展 api-server 创建一个 Kubernetes deployment，并确保以卷的方式挂载了 secret。它应该包含对扩展 api-server 镜像的引用。Deployment 也应该在同一个命名空间中。
-1. 确保您的扩展 apiserver 从该卷中加载了那些证书，并在 HTTPS 握手过程中使用它们。
-1. 在您的命令空间中创建一个 Kubernetes service account。
-1. 为资源允许的操作创建 Kubernetes 集群角色。
-1. 以您命令空间中的 service account 创建一个 Kubernetes 集群角色绑定，绑定到您刚创建的角色上。
-1. 以您命令空间中的 service account 创建一个 Kubernetes 集群角色绑定，绑定到 `system:auth-delegator` 集群角色，以将 auth 决策委派给 Kubernetes 核心 API 服务器。
-1. 以您命令空间中的 service account 创建一个 Kubernetes 集群角色绑定，绑定到 `extension-apiserver-authentication-reader` 角色。这将让您的扩展 api-server 能够访问 `extension-apiserver-authentication` configmap。
-1. 创建一个 Kubernetes apiservice。上述的 CA 证书应该使用 base64 编码，剥离新行并用作 apiservice 中的 spec.caBundle。这不应该是命名空间化的。如果使用了 [kube-aggregator API](https://github.com/kubernetes/kube-aggregator/)，那么只需要传入 PEM 编码的 CA 绑定，因为 base 64 编码已经完成了。
-1. 使用 kubectl 来获得您的资源。它应该返回 "找不到资源"。此消息表示一切正常，但您目前还没有创建该资源类型的对象。
-
-
+14. 创建一个 Kubernetes apiservice。
+ 上述的 CA 证书应该使用 base64 编码，剥离新行并用作 apiservice 中的 spec.caBundle。
+ 该资源不应放到任何名字空间。如果使用了
+ [kube-aggregator API](https://github.com/kubernetes/kube-aggregator/)，那么只需要传入
+ PEM 编码的 CA 绑定，因为 base 64 编码已经完成了。
+15. 使用 kubectl 来获得你的资源。
+ 它应该返回 "找不到资源"。此消息表示一切正常，但你目前还没有创建该资源类型的对象。
## {{% heading "whatsnext" %}}
-
<!--
* If you haven't already, [configure the aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) and enable the apiserver flags.
* For a high level overview, see [Extending the Kubernetes API with the aggregation layer](/docs/concepts/api-extension/apiserver-aggregation).
* Learn how to [Extend the Kubernetes API Using Custom Resource Definitions](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/).
-->
-* 如果你还未配置，请 [配置聚合层](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) 并启用 apiserver 的相关参数。
-* 高级概述，请参阅 [使用聚合层扩展 Kubernetes API](/docs/concepts/api-extension/apiserver-aggregation)。
-* 了解如何 [使用 Custom Resource Definition 扩展 Kubernetes API](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)。
+* 如果你还未配置，请[配置聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
+ 并启用 apiserver 的相关参数。
+* 高级概述，请参阅[使用聚合层扩展 Kubernetes API](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation)。
+* 了解如何[使用 Custom Resource Definition 扩展 Kubernetes API](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
+
diff --git a/content/zh/docs/tasks/inject-data-application/define-command-argument-container.md b/content/zh/docs/tasks/inject-data-application/define-command-argument-container.md
index bf788388dd..6688e6fab1 100644
--- a/content/zh/docs/tasks/inject-data-application/define-command-argument-container.md
+++ b/content/zh/docs/tasks/inject-data-application/define-command-argument-container.md
@@ -1,14 +1,12 @@
---
-title: 为容器设置启动时要执行的命令及其入参
+title: 为容器设置启动时要执行的命令和参数
content_type: task
weight: 10
---
<!--
----
title: Define a Command and Arguments for a Container
content_type: task
weight: 10
----
-->
<!-- overview -->
@@ -17,34 +15,27 @@ weight: 10
This page shows how to define commands and arguments when you run a container
in a {{< glossary_tooltip term_id="pod" >}}.
-->
-本页将展示如何为 {{< glossary_tooltip term_id="pod" >}} 中的容器设置启动时要执行的命令及其入参。
-
-
-
+本页将展示如何为 {{< glossary_tooltip text="Pod" term_id="pod" >}}
+中容器设置启动时要执行的命令及其参数。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
-
<!-- steps -->
<!--
## Define a command and arguments when you create a Pod
--->
-## 创建 Pod 时设置命令及入参
-<!--
When you create a Pod, you can define a command and arguments for the
containers that run in the Pod. To define a command, include the `command`
field in the configuration file. To define arguments for the command, include
the `args` field in the configuration file. The command and arguments that
you define cannot be changed after the Pod is created.
-->
-创建 Pod 时，可以为其下的容器设置启动时要执行的命令及其入参。如果要设置命令，就填写在配置文件的 `command` 字段下，如果要设置命令的入参，就填写在配置文件的 `args` 字段下。一旦 Pod 创建完成，该命令及其入参就无法再进行更改了。
+## 创建 Pod 时设置命令及参数
+
+创建 Pod 时，可以为其下的容器设置启动时要执行的命令及其参数。如果要设置命令，就填写在配置文件的 `command` 字段下，如果要设置命令的参数，就填写在配置文件的 `args` 字段下。一旦 Pod 创建完成，该命令及其参数就无法再进行更改了。
<!--
The command and arguments that you define in the configuration file
@@ -52,23 +43,22 @@ override the default command and arguments provided by the container image.
If you define args, but do not define a command, the default command is used
with your new arguments.
-->
-如果在配置文件中设置了容器启动时要执行的命令及其入参，那么容器镜像中自带的命令与入参将会被覆盖而不再执行。如果配置文件中只是设置了入参，却没有设置其对应的命令，那么容器镜像中自带的命令会使用该新入参作为其执行时的入参。
+如果在配置文件中设置了容器启动时要执行的命令及其参数，那么容器镜像中自带的命令与参数将会被覆盖而不再执行。如果配置文件中只是设置了参数，却没有设置其对应的命令，那么容器镜像中自带的命令会使用该新参数作为其执行时的参数。
<!--
-{{< note >}}
The `command` field corresponds to `entrypoint` in some container
runtimes. Refer to the [Notes](#notes) below.
-{{< /note >}}
-->
{{< note >}}
-在有些容器运行时中，`command` 字段对应 `entrypoint`，请参阅下面的 [注意](#注意)。
+在有些容器运行时中，`command` 字段对应 `entrypoint`，请参阅下面的
+[说明事项](#notes)。
{{< /note >}}
<!--
In this exercise, you create a Pod that runs one container. The configuration
file for the Pod defines a command and two arguments:
-->
-本示例中，将创建一个只包含单个容器的 Pod。在 Pod 配置文件中设置了一个命令与两个入参：
+本示例中，将创建一个只包含单个容器的 Pod。在 Pod 配置文件中设置了一个命令与两个参数：
{{< codenew file="pods/commands.yaml" >}}
@@ -77,23 +67,23 @@ file for the Pod defines a command and two arguments:
-->
1. 基于 YAML 文件创建一个 Pod：
- ```shell
- kubectl apply -f https://k8s.io/examples/pods/commands.yaml
- ```
+ ```shell
+ kubectl apply -f https://k8s.io/examples/pods/commands.yaml
+ ```
<!--
1. List the running Pods:
-->
2. 获取正在运行的 Pods：
+
+ ```shell
+ kubectl get pods
+ ```
- ```shell
- kubectl get pods
- ```
-
- <!--
- The output shows that the container that ran in the command-demo Pod has completed.
- -->
- 查询结果显示在 command-demo 这个 Pod 下运行的容器已经启动完成。
+ <!--
+ The output shows that the container that ran in the command-demo Pod has completed.
+ -->
+ 查询结果显示在 command-demo 这个 Pod 下运行的容器已经启动完成。
<!--
1. To see the output of the command that ran in the container, view the logs
@@ -101,19 +91,19 @@ from the Pod:
-->
3. 如果要获取容器启动时执行命令的输出结果，可以通过 Pod 的日志进行查看：
- ```shell
- kubectl logs command-demo
- ```
+ ```shell
+ kubectl logs command-demo
+ ```
- <!--
- The output shows the values of the HOSTNAME and KUBERNETES_PORT environment variables:
- -->
- 日志中显示了 HOSTNAME 与 KUBERNETES_PORT 这两个环境变量的值：
-
- ```
- command-demo
- tcp://10.3.240.1:443
- ```
+ <!--
+ The output shows the values of the HOSTNAME and KUBERNETES_PORT environment variables:
+ -->
+ 日志中显示了 HOSTNAME 与 KUBERNETES_PORT 这两个环境变量的值：
+
+ ```
+ command-demo
+ tcp://10.3.240.1:443
+ ```
<!--
## Use environment variables to define arguments
@@ -122,9 +112,9 @@ In the preceding example, you defined the arguments directly by
providing strings. As an alternative to providing strings directly,
you can define arguments by using environment variables:
-->
-## 使用环境变量来设置入参
+## 使用环境变量来设置参数
-在上面的示例中，我们直接将一串字符作为命令的入参。除此之外，我们还可以将环境变量作为命令的入参。
+在上面的示例中，我们直接将一串字符作为命令的参数。除此之外，我们还可以将环境变量作为命令的参数。
```yaml
env:
@@ -141,13 +131,13 @@ the techniques available for defining environment variables, including
and
[Secrets](/docs/concepts/configuration/secret/).
-->
-这意味着你可以将那些用来设置环境变量的方法应用于设置命令的入参，其中包括了 [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) 与 [Secrets](/docs/concepts/configuration/secret/)。
+这意味着你可以将那些用来设置环境变量的方法应用于设置命令的参数，其中包括了
+[ConfigMaps](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) 与
+[Secrets](/zh/docs/concepts/configuration/secret/)。
<!--
-{{< note >}}
The environment variable appears in parentheses, `"$(VAR)"`. This is
required for the variable to be expanded in the `command` or `args` field.
-{{< /note >}}
-->
{{< note >}}
环境变量需要加上括号，类似于 `"$(VAR)"`。这是在 `command` 或 `args` 字段使用变量的格式要求。
@@ -160,9 +150,11 @@ In some cases, you need your command to run in a shell. For example, your
command might consist of several commands piped together, or it might be a shell
script. To run your command in a shell, wrap it like this:
-->
-## 通过 shell 来执行命令
+## 在 Shell 来执行命令
-有时候，您需要在 shell 脚本中运行命令。 例如，您要执行的命令可能由多个命令组合而成，或者它就是一个 shell 脚本。这时，就可以通过如下方式在 shell 中执行命令：
+有时候，你需要在 Shell 脚本中运行命令。
+例如，你要执行的命令可能由多个命令组合而成，或者它就是一个 Shell 脚本。
+这时，就可以通过如下方式在 Shell 中执行命令：
```shell
command: ["/bin/sh"]
@@ -175,16 +167,16 @@ args: ["-c", "while true; do echo hello; sleep 10;done"]
This table summarizes the field names used by Docker and Kubernetes.
| Description | Docker field name | Kubernetes field name |
-|----------------------------------------|------------------------|-----------------------|
-| The command run by the container | Entrypoint | command |
-| The arguments passed to the command | Cmd | args |
+|----------------------------------------|------------------------|---------------------|
+| The command run by the container | Entrypoint | command |
+| The arguments passed to the command | Cmd | args |
-->
-## 注意
+## 说明事项 {#notes}
下表给出了 Docker 与 Kubernetes 中对应的字段名称。
-| 描述 | Docker 字段名称 | Kubernetes 字段名称 |
-|------------------|--------------------|-----------------------|
+| 描述 | Docker 字段名称 | Kubernetes 字段名称 |
+|--------------------|--------------------|-----------------------|
| 容器执行的命令 | Entrypoint | command |
| 传给命令的参数 | Cmd | args |
@@ -207,13 +199,15 @@ Cmd defined in the Docker image are ignored. Your `command` is run with your
-->
如果要覆盖默认的 Entrypoint 与 Cmd，需要遵循如下规则：
-* 如果在容器配置中没有设置 `command` 或者 `args`，那么将使用 Docker 镜像自带的命令及其入参。
+* 如果在容器配置中没有设置 `command` 或者 `args`，那么将使用 Docker 镜像自带的命令及其参数。
-* 如果在容器配置中只设置了 `command` 但是没有设置 `args`，那么容器启动时只会执行该命令，Docker 镜像中自带的命令及其入参会被忽略。
+* 如果在容器配置中只设置了 `command` 但是没有设置 `args`，那么容器启动时只会执行该命令，
+ Docker 镜像中自带的命令及其参数会被忽略。
-* 如果在容器配置中只设置了 `args`，那么 Docker 镜像中自带的命令会使用该新入参作为其执行时的入参。
+* 如果在容器配置中只设置了 `args`，那么 Docker 镜像中自带的命令会使用该新参数作为其执行时的参数。
-* 如果在容器配置中同时设置了 `command` 与 `args`，那么 Docker 镜像中自带的命令及其入参会被忽略。容器启动时只会执行配置中设置的命令，并使用配置中设置的入参作为命令的入参。
+* 如果在容器配置中同时设置了 `command` 与 `args`，那么 Docker 镜像中自带的命令及其参数会被忽略。
+ 容器启动时只会执行配置中设置的命令，并使用配置中设置的参数作为命令的参数。
<!--
Here are some examples:
@@ -225,9 +219,9 @@ Here are some examples:
| `[/ep-1]` | `[foo bar]` | <not set> | `[zoo boo]` | `[ep-1 zoo boo]` |
| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | `[zoo boo]` | `[ep-2 zoo boo]` |
-->
-下表涵盖了各类设置场景：
+下面是一些例子：
-| 镜像 Entrypoint | 镜像 Cmd | 容器 command | 容器 args | 命令执行 |
+| 镜像 Entrypoint | 镜像 Cmd | 容器 command | 容器 args | 命令执行 |
|--------------------|------------------|---------------------|--------------------|------------------|
| `[/ep-1]` | `[foo bar]` | <not set> | <not set> | `[ep-1 foo bar]` |
| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | <not set> | `[ep-2]` |
@@ -235,21 +229,15 @@ Here are some examples:
| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | `[zoo boo]` | `[ep-2 zoo boo]` |
-
-
## {{% heading "whatsnext" %}}
-
<!--
* Learn more about [configuring pods and containers](/docs/tasks/).
* Learn more about [running commands in a container](/docs/tasks/debug-application-cluster/get-shell-running-container/).
* See [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core).
-->
-* 了解更多 [pod 和容器的配置](/docs/tasks/)。
-* 了解更多 [在容器中运行命令](/docs/tasks/debug-application-cluster/get-shell-running-container/)。
-* 请参阅 [有关容器的文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)。
-
-
-
-
+* 进一步了解[配置 Pod 和容器](/zh/docs/tasks/)
+* 进一步了解[在容器中运行命令](/zh/docs/tasks/debug-application-cluster/get-shell-running-container/)
+* 参阅 [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
+ API 资源
diff --git a/content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md
index fa76d03559..05a207a236 100644
--- a/content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md
+++ b/content/zh/docs/tasks/inject-data-application/define-environment-variable-container.md
@@ -1,14 +1,13 @@
---
title: 为容器设置环境变量
content_type: task
+weight: 20
---
<!--
----
title: Define Environment Variables for a Container
content_type: task
weight: 20
----
-->
<!-- overview -->
@@ -17,26 +16,17 @@ weight: 20
This page shows how to define environment variables for a container
in a Kubernetes Pod.
-->
-
本页将展示如何为 kubernetes Pod 下的容器设置环境变量。
-
-
-
## {{% heading "prerequisites" %}}
-
-{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
-
+{{< include "task-tutorial-prereqs.md" >}}
<!-- steps -->
<!--
## Define an environment variable for a container
-->
-
## 为容器设置一个环境变量
<!--
@@ -44,7 +34,6 @@ When you create a Pod, you can set environment variables for the containers
that run in the Pod. To set environment variables, include the `env` or
`envFrom` field in the configuration file.
-->
-
创建 Pod 时，可以为其下的容器设置环境变量。通过配置文件的 `env` 或者 `envFrom` 字段来设置环境变量。
<!--
@@ -53,7 +42,6 @@ file for the Pod defines an environment variable with name `DEMO_GREETING` and
value `"Hello from the environment"`. Here is the configuration file for the
Pod:
-->
-
本示例中，将创建一个只包含单个容器的 Pod。Pod 的配置文件中设置环境变量的名称为 `DEMO_GREETING`，
其值为 `"Hello from the environment"`。下面是 Pod 的配置文件内容：
@@ -172,19 +160,15 @@ Upon creation, the command `echo Warm greetings to The Most Honorable Kubernetes
-->
创建后，命令 `echo Warm greetings to The Most Honorable Kubernetes` 将在容器中运行。
-
-
## {{% heading "whatsnext" %}}
-
<!--
* Learn more about [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/).
* Learn about [using secrets as environment variables](/docs/user-guide/secrets/#using-secrets-as-environment-variables).
* See [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core).
-->
-* 有关环境变量的更多信息，请参阅[这里](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)。
-* 有关如何通过环境变量来使用 Secret，请参阅[这里](/docs/user-guide/secrets/#using-secrets-as-environment-variables)。
+* 进一步了解[环境变量](/zh/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)
+* 进一步了解[通过环境变量来使用 Secret](/zh/docs/concepts/configuration/secret/#using-secrets-as-environment-variables)
* 关于 [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core) 资源的信息。
-
diff --git a/content/zh/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/zh/docs/tasks/inject-data-application/distribute-credentials-secure.md
index ce0b85820d..6683178d1d 100644
--- a/content/zh/docs/tasks/inject-data-application/distribute-credentials-secure.md
+++ b/content/zh/docs/tasks/inject-data-application/distribute-credentials-secure.md
@@ -1,201 +1,367 @@
---
title: 使用 Secret 安全地分发凭证
content_type: task
+weight: 50
+min-kubernetes-server-version: v1.6
---
<!-- overview -->
+<!--
+This page shows how to securely inject sensitive data, such as passwords and
+encryption keys, into Pods.
+-->
本文展示如何安全地将敏感数据（如密码和加密密钥）注入到 Pods 中。
-
## {{% heading "prerequisites" %}}
-
-{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+{{< include "task-tutorial-prereqs.md" >}}
+<!--
+### Convert your secret data to a base-64 representation
-<!-- steps -->
+Suppose you want to have two pieces of secret data: a username `my-app` and a password
+`39528$vdg7Jb`. First, use a base64 encoding tool to convert your username and password to a base64 representation. Here's an example using the commonly available base64 program:
+-->
+### 将 secret 数据转换为 base-64 形式
-## 将 secret 数据转换为 base-64 形式
+假设用户想要有两条 Secret 数据：用户名 `my-app` 和密码 `39528$vdg7Jb`。
+首先使用 [Base64 编码](https://www.base64encode.org/) 将用户名和密码转化为 base-64 形式。
+下面是一个使用常用的 base64 程序的示例：
-假设用户想要有两条 secret 数据：用户名 `my-app` 和密码
-`39528$vdg7Jb`。 首先使用 [Base64 编码](https://www.base64encode.org/) 将用户名和密码转化为 base-64 形式。 这里是一个 Linux 示例：
-
- ```shell
- echo -n 'my-app' | base64
- echo -n '39528$vdg7Jb' | base64
- ```
+```shell
+echo -n 'my-app' | base64
+echo -n '39528$vdg7Jb' | base64
+```
+<!--
+The output shows that the base-64 representation of your username is `bXktYXBw`,
+and the base-64 representation of your password is `Mzk1MjgkdmRnN0pi`.
+-->
结果显示 base-64 形式的用户名为 `bXktYXBw`，
base-64 形式的密码为 `Mzk1MjgkdmRnN0pi`。
+<!--
+Use a local tool trusted by your OS to decrease the security risks of external tools.
+-->
+{{< caution >}}
+使用你的操作系统所能信任的本地工具以降低使用外部工具的风险。
+{{< /caution >}}
+
+<!-- steps -->
+
+<!--
+## Create a Secret
+
+Here is a configuration file you can use to create a Secret that holds your
+username and password:
+-->
## 创建 Secret
这里是一个配置文件，可以用来创建存有用户名和密码的 Secret:
{{< codenew file="pods/inject/secret.yaml" >}}
-1. 创建 Secret
+1. <!--Create the Secret -->
+ 创建 Secret：
- ```shell
- kubectl create -f https://k8s.io/examples/pods/inject/secret.yaml
- ```
+ ```shell
+ kubectl apply -f https://k8s.io/examples/pods/inject/secret.yaml
+ ```
- {{< note >}}
- 如果想要跳过 Base64 编码的步骤，可以使用 `kubectl create secret` 命令来创建 Secret：
- {{< /note >}}
+1. <!-- View information about the Secret -->
+ 查看 Secret 相关信息：
- ```shell
- kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb'
- ```
-
-1. 查看 Secret 相关信息：
-
- kubectl get secret test-secret
+ ```shell
+ kubectl get secret test-secret
+ ```
+ <!-- Output: -->
输出：
- ```shell
- NAME TYPE DATA AGE
- test-secret Opaque 2 1m
- ```
+ ```shell
+ NAME TYPE DATA AGE
+ test-secret Opaque 2 1m
+ ```
-1. 查看 Secret 相关的更多详细信息：
+1. <!-- View more detailed information about the Secret -->
+ 查看 Secret 相关的更多详细信息：
- kubectl describe secret test-secret
+ ```shell
+ kubectl describe secret test-secret
+ ```
- 输出：
+ <!-- Output: -->
+ 输出：
- ```shell
- Name: test-secret
- Namespace: default
- Labels: <none>
- Annotations: <none>
+ ```shell
+ Name: test-secret
+ Namespace: default
+ Labels: <none>
+ Annotations: <none>
- Type: Opaque
+ Type: Opaque
- Data
- ====
- password: 13 bytes
- username: 7 bytes
- ```
+ Data
+ ====
+ password: 13 bytes
+ username: 7 bytes
+ ```
-## 创建可以通过卷访问 secret 数据的 Pod
+<!--
+### Create a Secret directly with kubectl
+
+If you want to skip the Base64 encoding step, you can create the
+same Secret using the `kubectl create secret` command. For example:
+-->
+### 直接用 kubectl 创建 Secret
+
+如果你希望略过 Base64 编码的步骤，你也可以使用 `kubectl create secret`
+命令直接创建 Secret。例如：
+
+```shell
+kubectl create secret generic test-secret --from-literal='username=my-app' --from-literal='password=39528$vdg7Jb'
+```
+
+<!--
+This is more convenient. The detailed approach shown earlier runs
+through each step explicitly to demonstrate what is happening.
+-->
+这是一种更为方便的方法。
+前面展示的详细分解步骤有助于了解究竟发生了什么事情。
+
+<!--
+## Create a Pod that has access to the secret data through a Volume
+
+Here is a configuration file you can use to create a Pod:
+-->
+## 创建一个可以通过卷访问 secret 数据的 Pod
这里是一个可以用来创建 pod 的配置文件：
{{< codenew file="pods/inject/secret-pod.yaml" >}}
-1. 创建 Pod：
+1. <!-- Create the Pod:-->
+ 创建 Pod：
- ```shell
- kubectl create -f secret-pod.yaml
- ```
+ ```shell
+ kubectl create -f secret-pod.yaml
+ ```
-1. 确认 Pod 正在运行：
+1. <!-- Verify that your Pod is running: -->
+ 确认 Pod 正在运行：
- ```shell
- kubectl get pod secret-test-pod
- ```
-
- 输出：
+ ```shell
+ kubectl get pod secret-test-pod
+ ```
- ```shell
- NAME READY STATUS RESTARTS AGE
- secret-test-pod 1/1 Running 0 42m
- ```
-
-1. 在 Pod 中运行的容器中获取一个 shell：
+ 输出：
- ```shell
- kubectl exec -it secret-test-pod -- /bin/bash
- ```
+ ```shell
+ NAME READY STATUS RESTARTS AGE
+ secret-test-pod 1/1 Running 0 42m
+ ```
-1. secret 数据通过挂载在 `/etc/secret-volume` 目录下的卷暴露在容器中。
-在 shell 中，进入 secret 数据被暴露的目录：
+1. <!-- Get a shell into the Container that is running in your Pod:-->
+ 获取一个 shell 进入 Pod 中运行的容器：
- ```shell
- root@secret-test-pod:/# cd /etc/secret-volume
- ```
-1. 在 shell 中，列出 `/etc/secret-volume` 目录的文件：
+ ```shell
+ kubectl exec -it secret-test-pod -- /bin/bash
+ ```
- ```shell
- root@secret-test-pod:/etc/secret-volume# ls
- ```
+1. <!-- The secret data is exposed to the Container through a Volume mounted under
+ `/etc/secret-volume`.
- 输出显示了两个文件，每个对应一条 secret 数据：
+ In your shell, list the files in the `/etc/secret-volume` directory:
+ -->
+ Secret 数据通过挂载在 `/etc/secret-volume` 目录下的卷暴露在容器中。
- ```shell
- password username
- ```
+ 在 shell 中，列举 `/etc/secret-volume` 目录下的文件：
-1. 在 shell 中，显示 `username` 和 `password` 文件的内容：
+ ```shell
+ ls /etc/secret-volume
+ ```
- ```shell
- root@secret-test-pod:/etc/secret-volume# cat username; echo; cat password; echo
- ```
+ <!--
+ The output shows two files, one for each piece of secret data:
+ -->
+ 输出包含两个文件，每个对应一个 Secret 数据条目：
- 输出为用户名和密码：
+ ```
+ password username
+ ```
- ```shell
- my-app
- 39528$vdg7Jb
- ```
+1. <!--
+ In your shell, display the contents of the `username` and `password` files:
+ -->
+ 在 Shell 中，显示 `username` 和 `password` 文件的内容：
-## 创建通过环境变量访问 secret 数据的 Pod
+ ```shell
+ # 在容器中 Shell 运行下面命令
+ echo "$(cat /etc/secret-volume/username)"
+ echo "$(cat /etc/secret-volume/password)"
+ ```
-这里是一个可以用来创建 pod 的配置文件：
+ <!--
+ The output is your username and password:
+ -->
+ 输出为用户名和密码：
-{{< codenew file="pods/inject/secret-envars-pod.yaml" >}}
+ ```shell
+ my-app
+ 39528$vdg7Jb
+ ```
-1. 创建 Pod：
+<!--
+## Define container environment variables using Secret data
- ```shell
- kubectl create -f https://k8s.io/examples/pods/inject/secret-envars-pod.yaml
- ```
+### Define a container environment variable with data from a single Secret
-1. 确认 Pod 正在运行：
+-->
+## 使用 Secret 数据定义容器变量
- ```shell
- kubectl get pod secret-envars-test-pod
- ```
+### 使用来自 Secret 中的数据定义容器变量
- 输出：
+<!--
+* Define an environment variable as a key-value pair in a Secret:
+-->
+* 定义环境变量为 Secret 中的键值偶对：
- ```shell
- NAME READY STATUS RESTARTS AGE
- secret-envars-test-pod 1/1 Running 0 4m
- ```
+ ```shell
+ kubectl create secret generic backend-user --from-literal=backend-username='backend-admin'
+ ```
-1. 在 Pod 中运行的容器中获取一个 shell：
+<!--
+* Assign the `backend-username` value defined in the Secret to the `SECRET_USERNAME` environment variable in the Pod specification.
+-->
+* 在 Pod 规约中，将 Secret 中定义的值 `backend-username` 赋给 `SECRET_USERNAME` 环境变量
- ```shell
- kubectl exec -it secret-envars-test-pod -- /bin/bash
- ```
+ {{< codenew file="pods/inject/pod-single-secret-env-variable.yaml" >}}
-1. 在 shell 中，显示环境变量：
+<!--
+* Create the Pod:
+-->
+* 创建 Pod：
- ```shell
- root@secret-envars-test-pod:/# printenv
- ```
+ ```shell
+ kubectl create -f https://k8s.io/examples/pods/inject/pod-single-secret-env-variable.yaml
+ ```
- 输出包括用户名和密码：
+<!--
+* In your shell, display the content of `SECRET_USERNAME` container environment variable
+-->
+* 在 Shell 中，显示容器环境变量 `SECRET_USERNAME` 的内容：
- ```shell
- ...
- SECRET_USERNAME=my-app
- ...
- SECRET_PASSWORD=39528$vdg7Jb
- ```
+ ```shell
+ kubectl exec -i -t env-single-secret -- /bin/sh -c 'echo $SECRET_USERNAME'
+ ```
+ 输出为：
+ ```
+ backend-admin
+ ```
+<!--
+### Define container environment variables with data from multiple Secrets
+-->
+### 使用来自多个 Secret 的数据定义环境变量
-## {{% heading "whatsnext" %}}
+<!--
+* As with the previous example, create the Secrets first.
+-->
+* 和前面的例子一样，先创建 Secret：
+ ```shell
+ kubectl create secret generic backend-user --from-literal=backend-username='backend-admin'
+ kubectl create secret generic db-user --from-literal=db-username='db-admin'
+ ```
-* 了解更多关于 [Secrets](/docs/concepts/configuration/secret/)。
-* 了解 [Volumes](/docs/concepts/storage/volumes/)。
+<!--
+* Define the environment variables in the Pod specification.
+-->
+* 在 Pod 规约中定义环境变量：
+ {{< codenew file="pods/inject/pod-multiple-secret-env-variable.yaml" >}}
+
+<!--
+* Create the Pod:
+-->
+* 创建 Pod：
+
+ ```shell
+ kubectl create -f https://k8s.io/examples/pods/inject/pod-multiple-secret-env-variable.yaml
+ ```
+
+<!--
+* In your shell, display the container environment variables
+-->
+* 在你的 Shell 中，显示容器环境变量的内容：
+
+ ```shell
+ kubectl exec -i -t envvars-multiple-secrets -- /bin/sh -c 'env | grep _USERNAME'
+ ```
+
+ 输出：
+ ```
+ DB_USERNAME=db-admin
+ BACKEND_USERNAME=backend-admin
+ ```
+
+<!--
+## Configure all key-value pairs in a Secret as container environment variables
+-->
+## 将 Secret 中的所有键值偶对定义为环境变量
+
+<!--
+This functionality is available in Kubernetes v1.6 and later.
+-->
+{{< note >}}
+此功能在 Kubernetes 1.6 版本之后可用。
+{{< /note >}}
+
+<!--
+* Create a Secret containing multiple key-value pairs
+-->
+* 创建包含多个键值偶对的 Secret：
+
+ ```shell
+ kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb'
+ ```
+
+<!--
+* Use envFrom to define all of the Secret’s data as container environment variables. The key from the Secret becomes the environment variable name in the Pod.
+-->
+* 使用 `envFrom` 来将 Secret 中的所有数据定义为环境变量。
+ Secret 中的键名成为容器中的环境变量名：
+
+ {{< codenew file="pods/inject/pod-secret-envFrom.yaml" >}}
+
+<!--
+* Create the Pod:
+-->
+* 创建 Pod：
+
+ ```shell
+ kubectl create -f https://k8s.io/examples/pods/inject/pod-secret-envFrom.yaml
+ ```
+
+<!--
+* In your shell, display `username` and `password` container environment variables
+-->
+* 在 Shell 中，显示环境变量 `username` 和 `password` 的内容：
+
+ ```shell
+ kubectl exec -i -t envfrom-secret -- /bin/sh -c 'echo "username: $username\npassword: $password\n"'
+ ```
+
+ 输出为：
+
+ ```
+ username: my-app
+ password: 39528$vdg7Jb
+ ```
+
+<!-- ### References -->
### 参考
* [Secret](/docs/api-reference/{{< param "version" >}}/#secret-v1-core)
@@ -203,3 +369,13 @@ base-64 形式的密码为 `Mzk1MjgkdmRnN0pi`。
* [Pod](/docs/api-reference/{{< param "version" >}}/#pod-v1-core)
+## {{% heading "whatsnext" %}}
+
+<!--
+* Learn more about [Secrets](/docs/concepts/configuration/secret/).
+* Learn about [Volumes](/docs/concepts/storage/volumes/).
+-->
+* 进一步了解 [Secret](/zh/docs/concepts/configuration/secret/)。
+* 了解 [Volumes](/zh/docs/concepts/storage/volumes/)。
+
+
diff --git a/content/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md b/content/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
index 84ddad382e..bdb38da4bd 100644
--- a/content/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
+++ b/content/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
@@ -1,61 +1,103 @@
---
-title: 通过文件将Pod信息呈现给容器
+title: 通过文件将 Pod 信息呈现给容器
content_type: task
+weight: 40
---
<!-- overview -->
-此页面描述Pod如何使用DownwardAPIVolumeFile把自己的信息呈现给pod中运行的容器。DownwardAPIVolumeFile可以呈现pod的字段和容器字段。
-
-
-
+<!--
+This page shows how a Pod can use a DownwardAPIVolumeFile to expose information
+about itself to Containers running in the Pod. A DownwardAPIVolumeFile can expose
+Pod fields and Container fields.
+-->
+此页面描述 Pod 如何使用 DownwardAPIVolumeFile 把自己的信息呈现给 Pod 中运行的容器。
+DownwardAPIVolumeFile 可以呈现 Pod 的字段和容器字段。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
<!-- steps -->
+<!--
+## The Downward API
+
+There are two ways to expose Pod and Container fields to a running Container:
+
+* [Environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#the-downward-api)
+* Volume Files
+-->
## Downward API
-有两种方式可以将Pod和Container字段呈现给运行中的容器：
+有两种方式可以将 Pod 和 Container 字段呈现给运行中的容器：
* [环境变量](/docs/tasks/configure-pod-container/environment-variable-expose-pod-information/)
-* DownwardAPIVolumeFile
+* 卷文件
-这两种呈现Pod和Container字段的方式都称为*Downward API*。
+这两种呈现 Pod 和 Container 字段的方式都称为 *Downward API*。
-## 存储Pod字段
+<!--
+## Store Pod fields
-在这个练习中，你将创建一个包含一个容器的pod。这是该pod的配置文件：
+In this exercise, you create a Pod that has one Container.
+Here is the configuration file for the Pod:
+-->
+## 存储 Pod 字段
+
+在这个练习中，你将创建一个包含一个容器的 Pod。Pod 的配置文件如下：
{{< codenew file="pods/inject/dapi-volume.yaml" >}}
-在配置文件中，你可以看到Pod有一个`downwardAPI`类型的Volume，并且挂载到容器中的`/etc`。
+<!--
+In the configuration file, you can see that the Pod has a `downwardAPI` Volume,
+and the Container mounts the Volume at `/etc/podinfo`.
-查看`downwardAPI`下面的`items`数组。每个数组元素都是一个[DownwardAPIVolumeFile](/docs/resources-reference/{{< param "version" >}}/#downwardapivolumefile-v1-core)。
-第一个元素指示Pod的`metadata.labels`字段的值保存在名为`labels`的文件中。
-第二个元素指示Pod的`annotations`字段的值保存在名为`annotations`的文件中。
+Look at the `items` array under `downwardAPI`. Each element of the array is a
+[DownwardAPIVolumeFile](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core).
+The first element specifies that the value of the Pod's
+`metadata.labels` field should be stored in a file named `labels`.
+The second element specifies that the value of the Pod's `annotations`
+field should be stored in a file named `annotations`.
+-->
+在配置文件中，你可以看到 Pod 有一个 `downwardAPI` 类型的卷，并且挂载到容器中的 `/etc` 目录。
+查看 `downwardAPI` 下面的 `items` 数组。
+每个数组元素都是一个
+[DownwardAPIVolumeFile](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)
+对象。
+第一个元素指示 Pod 的 `metadata.labels` 字段的值保存在名为 `labels` 的文件中。
+第二个元素指示 Pod 的 `annotations` 字段的值保存在名为 `annotations` 的文件中。
+
+<!--
+The fields in this example are Pod fields. They are not
+fields of the Container in the Pod.
+-->
{{< note >}}
本示例中的字段是Pod字段，不是Pod中容器的字段。
{{< /note >}}
+<!--
+Create the Pod:
+-->
创建 Pod：
```shell
kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume.yaml
```
+<!--
+Verify that the Container in the Pod is running:
+-->
验证Pod中的容器运行正常：
```shell
kubectl get pods
```
+<!--
+View the Container's logs:
+-->
查看容器的日志：
```shell
@@ -67,7 +109,7 @@ The output shows the contents of the labels file and the annotations file:
-->
输出显示 `labels` 和 `annotations` 文件的内容：
-```shell
+```
cluster="test-cluster1"
rack="rack-22"
zone="us-est-coast"
@@ -76,70 +118,100 @@ build="two"
builder="john-doe"
```
-进入Pod中运行的容器，打开一个shell：
+<!--
+Get a shell into the Container that is running in your Pod:
+-->
+进入 Pod 中运行的容器，打开一个 Shell：
-```
+```shell
kubectl exec -it kubernetes-downwardapi-volume-example -- sh
```
-在该shell中，查看`labels`文件：
+<!--
+In your shell, view the `labels` file:
+-->
+在该 Shell中，查看 `labels` 文件：
```shell
/# cat /etc/labels
```
-输出显示Pod的所有labels都已写入`labels`文件。
+<!--
+The output shows that all of the Pod's labels have been written
+to the `labels` file:
+-->
+输出显示 Pod 的所有标签都已写入 `labels` 文件。
-```shell
+```
cluster="test-cluster1"
rack="rack-22"
zone="us-est-coast"
```
+<!--
+Similarly, view the `annotations` file:
+-->
同样，查看`annotations`文件：
```shell
/# cat /etc/annotations
```
-查看`/etc`目录下的文件：
+<!--
+View the files in the `/etc/podinfo` directory:
+-->
+查看`/etc/podinfo`目录下的文件：
```shell
-/# ls -laR /etc
+/# ls -laR /etc/podinfo
```
-在输出中可以看到，`labels` 和 `annotations`文件都在一个临时子目录中：这个例子，`..2019_12_05_07_00_34.813117769`。在`/etc`目录中，`..data`是一个指向临时子目录
-的符号链接。`/etc`目录中，`labels` 和 `annotations`也是符号链接。
+<!--
+In the output, you can see that the `labels` and `annotations` files
+are in a temporary subdirectory: in this example,
+`..2982_06_02_21_47_53.299460680`. In the `/etc/podinfo` directory, `..data` is
+a symbolic link to the temporary subdirectory. Also in the `/etc/podinfo` directory,
+`labels` and `annotations` are symbolic links.
+-->
+在输出中可以看到，`labels` 和 `annotations` 文件都在一个临时子目录中。
+在这个例子，`..2982_06_02_21_47_53.299460680`。
+在 `/etc/podinfo` 目录中，`..data` 是一个指向临时子目录
+的符号链接。`/etc/podinfo` 目录中，`labels` 和 `annotations` 也是符号链接。
```
-/etc/podinfo # ls -alRL
-.:
-total 8
-drwxrwxrwt 3 root root 120 Dec 5 07:00 .
-drwxr-xr-x 1 root root 21 Dec 5 07:00 ..
-drwxr-xr-x 2 root root 80 Dec 5 07:00 ..2019_12_05_07_00_34.813117769
-drwxr-xr-x 2 root root 80 Dec 5 07:00 ..data
--rw-r--r-- 1 root root 1123 Dec 5 07:00 annotations
--rw-r--r-- 1 root root 39 Dec 5 07:00 labels
+drwxr-xr-x ... Feb 6 21:47 ..2982_06_02_21_47_53.299460680
+lrwxrwxrwx ... Feb 6 21:47 ..data -> ..2982_06_02_21_47_53.299460680
+lrwxrwxrwx ... Feb 6 21:47 annotations -> ..data/annotations
+lrwxrwxrwx ... Feb 6 21:47 labels -> ..data/labels
-./..2019_12_05_07_00_34.813117769:
+/etc/..2982_06_02_21_47_53.299460680:
total 8
-drwxr-xr-x 2 root root 80 Dec 5 07:00 .
-drwxrwxrwt 3 root root 120 Dec 5 07:00 ..
--rw-r--r-- 1 root root 1123 Dec 5 07:00 annotations
--rw-r--r-- 1 root root 39 Dec 5 07:00 labels
-
-./..data:
-total 8
-drwxr-xr-x 2 root root 80 Dec 5 07:00 .
-drwxrwxrwt 3 root root 120 Dec 5 07:00 ..
--rw-r--r-- 1 root root 1123 Dec 5 07:00 annotations
--rw-r--r-- 1 root root 39 Dec 5 07:00 labels
+-rw-r--r-- ... Feb 6 21:47 annotations
+-rw-r--r-- ... Feb 6 21:47 labels
```
-用符号链接可实现元数据的动态原子刷新；更新将写入一个新的临时目录，然后`..data`符号链接完成原子更新，通过使用[rename(2)](http://man7.org/linux/man-pages/man2/rename.2.html)。
+<!--
+Using symbolic links enables dynamic atomic refresh of the metadata; updates are
+written to a new temporary directory, and the `..data` symlink is updated
+atomically using
+[rename(2)](http://man7.org/linux/man-pages/man2/rename.2.html).
+-->
+用符号链接可实现元数据的动态原子性刷新；更新将写入一个新的临时目录，
+然后通过使用[rename(2)](http://man7.org/linux/man-pages/man2/rename.2.html)
+完成 `..data` 符号链接的原子性更新。
-退出shell：
+<!--
+A container using Downward API as a
+[subPath](/docs/concepts/storage/volumes/#using-subpath) volume mount will not
+receive Downward API updates.
+-->
+{{< note >}}
+如果容器以
+[subPath](/zh/docs/concepts/storage/volumes/#using-subpath)卷挂载方式来使用
+Downward API，则该容器无法收到更新事件。
+{{< /note >}}
+
+退出 Shell：
```shell
/# exit
@@ -147,15 +219,36 @@ drwxrwxrwt 3 root root 120 Dec 5 07:00 ..
## 存储容器字段
-前面的练习中，你将Pod字段保存到DownwardAPIVolumeFile中。接下来这个练习，你将存储容器字段。这里是包含一个容器的pod的配置文件：
+<!--
+The preceding exercise, you stored Pod fields in a DownwardAPIVolumeFile.
+In this next exercise, you store Container fields. Here is the configuration
+file for a Pod that has one Container:
+-->
+前面的练习中，你将 Pod 字段保存到 DownwardAPIVolumeFile 中。
+接下来这个练习，你将存储 Container 字段。这里是包含一个容器的 Pod 的配置文件：
{{< codenew file="pods/inject/dapi-volume-resources.yaml" >}}
-在这个配置文件中，你可以看到Pod有一个`downwardAPI`类型的Volume,并且挂载到容器的`/etc`目录。
+<!--
+In the configuration file, you can see that the Pod has a `downwardAPI` Volume,
+and the Container mounts the Volume at `/etc/podinfo`.
-查看`downwardAPI`下面的`items`数组。每个数组元素都是一个DownwardAPIVolumeFile。
+Look at the `items` array under `downwardAPI`. Each element of the array is a
+DownwardAPIVolumeFile.
-第一个元素指定名为`client-container`的容器中`limits.cpu`字段的值应保存在名为`cpu_limit`的文件中。
+The first element specifies that in the Container named `client-container`,
+the value of the `limits.cpu` field in the format specified by `1m` should be
+stored in a file named `cpu_limit`. The `divisor` field is optional and has the
+default value of `1` which means cores for cpu and bytes for memory.
+
+Create the Pod:
+-->
+在这个配置文件中，你可以看到 Pod 有一个 `downwardAPI` 类型的卷，并且挂载到容器的 `/etc/podinfo` 目录。
+
+查看 `downwardAPI` 下面的 `items` 数组。每个数组元素都是一个 DownwardAPIVolumeFile。
+
+第一个元素指定名为 `client-container` 的容器中 `limits.cpu` 字段的值应保存在名为
+`cpu_limit` 的文件中。
创建Pod：
@@ -163,81 +256,148 @@ drwxrwxrwt 3 root root 120 Dec 5 07:00 ..
kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume-resources.yaml
```
-进入Pod中运行的容器，打开一个shell：
+<!--
+Get a shell into the Container that is running in your Pod:
+-->
+打开一个 Shell，进入 Pod 中运行的容器：
```
kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh
```
-在shell中，查看`cpu_limit`文件：
+<!--
+In your shell, view the `cpu_limit` file:
+-->
+在 Shell 中，查看 `cpu_limit` 文件：
```shell
/# cat /etc/cpu_limit
```
-你可以使用同样的命令查看`cpu_request`, `mem_limit` 和`mem_request` 文件.
-
+<!--
+You can use similar commands to view the `cpu_request`, `mem_limit` and
+`mem_request` files.
+-->
+你可以使用同样的命令查看 `cpu_request`、`mem_limit` 和 `mem_request` 文件.
<!-- discussion -->
-
+<!--
## Capabilities of the Downward API
+-->
+## Downward API 的能力
-下面这些信息可以通过环境变量和DownwardAPIVolumeFiles提供给容器：
+<!--
+The following information is available to containers through environment
+variables and `downwardAPI` volumes:
-能通过`fieldRef`获得的：
- * `metadata.name` - Pod名称
- * `metadata.namespace` - Pod名字空间
+* Information available via `fieldRef`:
+ * `metadata.name` - the pod’s name
+ * `metadata.namespace` - the pod’s namespace
+ * `metadata.uid` - the pod’s UID, available since v1.8.0-alpha.2
+ * `metadata.labels['<KEY>']` - the value of the pod’s label `<KEY>` (for example, `metadata.labels['mylabel']`); available in Kubernetes 1.9+
+ * `metadata.annotations['<KEY>']` - the value of the pod’s annotation `<KEY>` (for example, `metadata.annotations['myannotation']`); available in Kubernetes 1.9+
+-->
+下面这些信息可以通过环境变量和 `downwardAPI` 卷提供给容器：
+
+* 能通过 `fieldRef` 获得的：
+ * `metadata.name` - Pod 名称
+ * `metadata.namespace` - Pod 名字空间
* `metadata.uid` - Pod的UID, 版本要求 v1.8.0-alpha.2
- * `metadata.labels['<KEY>']` - 单个 pod 标签值 `<KEY>` (例如, `metadata.labels['mylabel']`); 版本要求 Kubernetes 1.9+
- * `metadata.annotations['<KEY>']` - 单个 pod 的标注值 `<KEY>` (例如, `metadata.annotations['myannotation']`); 版本要求 Kubernetes 1.9+
+ * `metadata.labels['<KEY>']` - Pod 标签 `<KEY>` 的值 (例如, `metadata.labels['mylabel']`）；
+ 版本要求 Kubernetes 1.9+
+ * `metadata.annotations['<KEY>']` - Pod 的注解 `<KEY>` 的值（例如, `metadata.annotations['myannotation']`）； 版本要求 Kubernetes 1.9+
-能通过`resourceFieldRef`获得的：
- * 容器的CPU约束值
- * 容器的CPU请求值
+<!--
+* Information available via `resourceFieldRef`:
+ * A Container’s CPU limit
+ * A Container’s CPU request
+ * A Container’s memory limit
+ * A Container’s memory request
+ * A Container’s ephemeral-storage limit, available since v1.8.0-beta.0
+ * A Container’s ephemeral-storage request, available since v1.8.0-beta.0
+-->
+* 能通过 `resourceFieldRef` 获得的：
+ * 容器的 CPU 约束值
+ * 容器的 CPU 请求值
* 容器的内存约束值
* 容器的内存请求值
* 容器的临时存储约束值, 版本要求 v1.8.0-beta.0
* 容器的临时存储请求值, 版本要求 v1.8.0-beta.0
-此外，以下信息可通过DownwardAPIVolumeFiles从`fieldRef`获得：
-
+<!--
+In addition, the following information is available through
+`downwardAPI` volume `fieldRef`:
+-->
+此外，以下信息可通过 `downwardAPI` 卷从 `fieldRef` 获得：
+<!--
* `metadata.labels` - all of the pod’s labels, formatted as `label-key="escaped-label-value"` with one label per line
* `metadata.annotations` - all of the pod’s annotations, formatted as `annotation-key="escaped-annotation-value"` with one annotation per line
-* `metadata.labels` - 所有Pod的标签，以`label-key="escaped-label-value"`格式显示，每行显示一个label
-* `metadata.annotations` - Pod的注释，以`annotation-key="escaped-annotation-value"`格式显示，每行显示一个标签
+-->
+* `metadata.labels` - Pod 的所有标签，以 `label-key="escaped-label-value"` 格式显示，每行显示一个标签
+* `metadata.annotations` - Pod 的所有注解，以 `annotation-key="escaped-annotation-value"`
+ 格式显示，每行显示一个标签
-以下信息可通过环境变量从`fieldRef`获得：
+<!--
+The following information is available through environment variables:
+-->
+以下信息可通过环境变量获得：
-* `status.podIP` - 节点IP
-* `spec.serviceAccountName` - Pod服务帐号名称, 版本要求 v1.4.0-alpha.3
+* `status.podIP` - 节点 IP
+* `spec.serviceAccountName` - Pod 服务帐号名称, 版本要求 v1.4.0-alpha.3
* `spec.nodeName` - 节点名称, 版本要求 v1.4.0-alpha.3
-* `status.hostIP` - 节点IP, 版本要求 v1.7.0-alpha.1
+* `status.hostIP` - 节点 IP, 版本要求 v1.7.0-alpha.1
+<!--
+If CPU and memory limits are not specified for a Container, the
+Downward API defaults to the node allocatable value for CPU and memory.
+-->
{{< note >}}
-如果容器未指定CPU和memory limits，则Downward API默认为节点可分配值。
+如果容器未指定 CPU 和内存限制，则 Downward API 默认将节点可分配值
+视为容器的 CPU 和内存限制。
{{< /note >}}
-## 投射密钥到指定路径并且指定文件权限
+<!--
+## Project keys to specific paths and file permissions
-你可以将密钥投射到指定路径并且指定每个文件的访问权限。更多信息，请参阅[Secrets](/docs/concepts/configuration/secret/).
+You can project keys to specific paths and specific permissions on a per-file
+basis. For more information, see
+[Secrets](/docs/concepts/configuration/secret/).
+-->
+## 投射键名到指定路径并且指定文件权限
+你可以将键名投射到指定路径并且指定每个文件的访问权限。
+更多信息，请参阅[Secrets](/zh/docs/concepts/configuration/secret/).
+
+<!--
+## Motivation for the Downward API
+
+It is sometimes useful for a Container to have information about itself, without
+being overly coupled to Kubernetes. The Downward API allows containers to consume
+information about themselves or the cluster without using the Kubernetes client
+or API server.
+
+An example is an existing application that assumes a particular well-known
+environment variable holds a unique identifier. One possibility is to wrap the
+application, but that is tedious and error prone, and it violates the goal of low
+coupling. A better option would be to use the Pod's name as an identifier, and
+inject the Pod's name into the well-known environment variable.
+-->
## Downward API的动机
-对于容器来说，有时候拥有自己的信息是很有用的，可避免与Kubernetes过度耦合。Downward API使得容器使用自己或者集群的信息，而不必通过Kubernetes客户端或API服务器。
-
-一个例子是有一个现有的应用假定要用一个非常熟悉的环境变量来保存一个唯一标识。一种可能是给应用增加处理层，但这样是冗余和易出错的，而且它违反了低耦合的目标。更好的选择是使用Pod名称作为标识，把Pod名称注入这个环境变量中。
-
+对于容器来说，有时候拥有自己的信息是很有用的，可避免与 Kubernetes 过度耦合。
+Downward API 使得容器使用自己或者集群的信息，而不必通过 Kubernetes 客户端或
+API 服务器来获得。
+一个例子是有一个现有的应用假定要用一个非常熟悉的环境变量来保存一个唯一标识。
+一种可能是给应用增加处理层，但这样是冗余和易出错的，而且它违反了低耦合的目标。
+更好的选择是使用 Pod 名称作为标识，把 Pod 名称注入这个环境变量中。
## {{% heading "whatsnext" %}}
-* [PodSpec](/docs/resources-reference/{{< param "version" >}}/#podspec-v1-core)
-* [Volume](/docs/resources-reference/{{< param "version" >}}/#volume-v1-core)
-* [DownwardAPIVolumeSource](/docs/resources-reference/{{< param "version" >}}/#downwardapivolumesource-v1-core)
-* [DownwardAPIVolumeFile](/docs/resources-reference/{{< param "version" >}}/#downwardapivolumefile-v1-core)
-* [ResourceFieldSelector](/docs/resources-reference/{{< param "version" >}}/#resourcefieldselector-v1-core)
-
-
-
+* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
+* [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)
+* [DownwardAPIVolumeSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumesource-v1-core)
+* [DownwardAPIVolumeFile](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)
+* [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core)
diff --git a/content/zh/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md b/content/zh/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md
index 46e101baa5..189606aab6 100644
--- a/content/zh/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md
+++ b/content/zh/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md
@@ -1,70 +1,112 @@
---
-title: 通过环境变量将Pod信息呈现给容器
+title: 通过环境变量将 Pod 信息呈现给容器
content_type: task
+weight: 30
---
-
+<!--
+title: Expose Pod Information to Containers Through Environment Variables
+content_type: task
+weight: 30
+-->
<!-- overview -->
-此页面显示了Pod如何使用环境变量把自己的信息呈现给pod中运行的容器。环境变量可以呈现pod的字段和容器字段。
-
-有两种方式可以将Pod和Container字段呈现给运行中的容器：
-环境变量 和[DownwardAPIVolumeFiles](/docs/resources-reference/{{< param "version" >}}/#downwardapivolumefile-v1-core).
-这两种呈现Pod和Container字段的方式都称为*Downward API*。
-
-
-
+<!--
+This page shows how a Pod can use environment variables to expose information
+about itself to Containers running in the Pod. Environment variables can expose
+Pod fields and Container fields.
+-->
+此页面展示 Pod 如何使用环境变量把自己的信息呈现给 Pod 中运行的容器。
+环境变量可以呈现 Pod 的字段和容器字段。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
-
<!-- steps -->
## Downward API
-有两种方式可以将Pod和Container字段呈现给运行中的容器：
+<!--
+There are two ways to expose Pod and Container fields to a running Container:
+
+* Environment variables
+* [Volume Files](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)
+
+Together, these two ways of exposing Pod and Container fields are called the
+*Downward API*.
+-->
+
+有两种方式可以将 Pod 和 Container 字段呈现给运行中的容器：
* 环境变量
-* [DownwardAPIVolumeFiles](/docs/resources-reference/{{< param "version" >}}/#downwardapivolumefile-v1-core)
+* [卷文件](/docs/resources-reference/{{< param "version" >}}/#downwardapivolumefile-v1-core)
-这两种呈现Pod和Container字段的方式都称为*Downward API*。
+这两种呈现 Pod 和 Container 字段的方式统称为 *Downward API*。
+<!--
+## Use Pod fields as values for environment variables
-## 用Pod字段作为环境变量的值
+In this exercise, you create a Pod that has one Container. Here is the
+configuration file for the Pod:
+-->
+## 用 Pod 字段作为环境变量的值
-在这个练习中，你将创建一个包含一个容器的pod。这是该pod的配置文件：
+在这个练习中，你将创建一个包含一个容器的 Pod。这是该 Pod 的配置文件：
{{< codenew file="pods/inject/dapi-envars-pod.yaml" >}}
-这个配置文件中，你可以看到五个环境变量。`env`字段是一个[EnvVars](/docs/resources-reference/{{< param "version" >}}/#envvar-v1-core)类型的数组。
-数组中第一个元素指定`MY_NODE_NAME`这个环境变量从Pod的`spec.nodeName`字段获取变量值。同样，其它环境变量也是从Pod的字段获取它们的变量值。
+<!--
+In the configuration file, you can see five environment variables. The `env`
+field is an array of
+[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core).
+The first element in the array specifies that the `MY_NODE_NAME` environment
+variable gets its value from the Pod's `spec.nodeName` field. Similarly, the
+other environment variables get their names from Pod fields.
+-->
+这个配置文件中，你可以看到五个环境变量。`env` 字段是一个
+[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core).
+对象的数组。
+数组中第一个元素指定 `MY_NODE_NAME` 这个环境变量从 Pod 的 `spec.nodeName` 字段获取变量值。
+同样，其它环境变量也是从 Pod 的字段获取它们的变量值。
+<!--
+The fields in this example are Pod fields. They are not fields of the
+Container in the Pod.
+-->
{{< note >}}
-本示例中的字段是Pod字段，不是Pod中容器的字段。
+本示例中的字段是 Pod 字段，不是 Pod 中 Container 的字段。
{{< /note >}}
+<!--
+Create the Pod:
+-->
创建Pod：
```shell
kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-pod.yaml
```
-验证Pod中的容器运行正常：
+<!--
+Verify that the Container in the Pod is running:
+-->
+验证 Pod 中的容器运行正常：
```
kubectl get pods
```
+<!--
+View the Container's logs:
+-->
查看容器日志：
```
kubectl logs dapi-envars-fieldref
```
+<!--
+The output shows the values of selected environment variables:
+-->
输出信息显示了所选择的环境变量的值：
```
@@ -75,21 +117,36 @@ default
default
```
-要了解为什么这些值在日志中，请查看配置文件中的`command` 和 `args`字段。 当容器启动时，它将五个环境变量的值写入stdout。每十秒重复执行一次。
+<!--
+To see why these values are in the log, look at the `command` and `args` fields
+in the configuration file. When the Container starts, it writes the values of
+five environment variables to stdout. It repeats this every ten seconds.
-接下来，进入Pod中运行的容器，打开一个shell：
+Next, get a shell into the Container that is running in your Pod:
+-->
+要了解为什么这些值在日志中，请查看配置文件中的`command` 和 `args`字段。
+当容器启动时，它将五个环境变量的值写入 stdout。每十秒重复执行一次。
+
+接下来，通过打开一个 Shell 进入 Pod 中运行的容器：
```
kubectl exec -it dapi-envars-fieldref -- sh
```
-在shell中，查看环境变量：
+<!--
+In your shell, view the environment variables:
+-->
+在 Shell 中，查看环境变量：
```
/# printenv
```
-输出信息显示环境变量已经指定为Pod的字段的值。
+<!--
+The output shows that certain environment variables have been assigned the
+values of Pod fields:
+-->
+输出信息显示环境变量已经设置为 Pod 字段的值。
```
MY_POD_SERVICE_ACCOUNT=default
@@ -102,14 +159,43 @@ MY_NODE_NAME=minikube
MY_POD_NAME=dapi-envars-fieldref
```
-## 用容器字段作为环境变量的值
+<!--
+## Use Container fields as values for environment variables
-前面的练习中，你将Pod字段作为环境变量的值。接下来这个练习，你将用容器字段作为环境变量的值。这里是包含一个容器的pod的配置文件：
+In the preceding exercise, you used Pod fields as the values for environment
+variables. In this next exercise, you use Container fields as the values for
+environment variables. Here is the configuration file for a Pod that has one
+container:
+-->
+## 用 Container 字段作为环境变量的值
+
+前面的练习中，你将 Pod 字段作为环境变量的值。
+接下来这个练习中，你将用 Container 字段作为环境变量的值。这里是包含一个容器的 Pod 的配置文件：
{{< codenew file="pods/inject/dapi-envars-container.yaml" >}}
-这个配置文件中，你可以看到四个环境变量。`env`字段是一个[EnvVars](/docs/resources-reference/{{< param "version" >}}/#envvar-v1-core)
-类型的数组。数组中第一个元素指定`MY_CPU_REQUEST`这个环境变量从容器的`requests.cpu`字段获取变量值。同样，其它环境变量也是从容器的字段获取它们的变量值。
+<!--
+In the configuration file, you can see four environment variables. The `env`
+field is an array of
+[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core).
+The first element in the array specifies that the `MY_CPU_REQUEST` environment
+variable gets its value from the `requests.cpu` field of a Container named
+`test-container`. Similarly, the other environment variables get their values
+from Container fields.
+
+The fields in this example are Pod fields. They are not fields of the
+Container in the Pod.
+
+Create the Pod:
+-->
+这个配置文件中，你可以看到四个环境变量。`env` 字段是一个
+[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core).
+对象的数组。数组中第一个元素指定 `MY_CPU_REQUEST` 这个环境变量从 Container 的 `requests.cpu`
+字段获取变量值。同样，其它环境变量也是从 Container 的字段获取它们的变量值。
+
+{{< note >}}
+本例中使用的是 Container 的字段而不是 Pod 的字段。
+{{< /note >}}
创建Pod：
@@ -117,18 +203,27 @@ MY_POD_NAME=dapi-envars-fieldref
kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-container.yaml
```
-验证Pod中的容器运行正常：
+<!--
+Verify that the Container in the Pod is running:
+-->
+验证 Pod 中的容器运行正常：
```
kubectl get pods
```
+<!--
+View the Container's logs:
+-->
查看容器日志：
```
kubectl logs dapi-envars-resourcefieldref
```
+<!--
+The output shows the values of selected environment variables:
+-->
输出信息显示了所选择的环境变量的值：
```
@@ -138,20 +233,23 @@ kubectl logs dapi-envars-resourcefieldref
67108864
```
-
-
## {{% heading "whatsnext" %}}
+<!--
+* [Defining Environment Variables for a Container](/docs/tasks/inject-data-application/define-environment-variable-container/)
+* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
+* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
+* [EnvVar](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)
+* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)
+* [ObjectFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectfieldselector-v1-core)
+* [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core)
+-->
-* [给容器定义环境变量](/docs/tasks/configure-pod-container/define-environment-variable-container/)
-* [PodSpec](/docs/resources-reference/{{< param "version" >}}/#podspec-v1-core)
-* [Container](/docs/resources-reference/{{< param "version" >}}/#container-v1-core)
-* [EnvVar](/docs/resources-reference/{{< param "version" >}}/#envvar-v1-core)
-* [EnvVarSource](/docs/resources-reference/{{< param "version" >}}/#envvarsource-v1-core)
-* [ObjectFieldSelector](/docs/resources-reference/{{< param "version" >}}/#objectfieldselector-v1-core)
-* [ResourceFieldSelector](/docs/resources-reference/{{< param "version" >}}/#resourcefieldselector-v1-core)
-
-
-
-
+* [给容器定义环境变量](/zh/docs/tasks/inject-data-application/define-environment-variable-container/)
+* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
+* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
+* [EnvVar](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)
+* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)
+* [ObjectFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectfieldselector-v1-core)
+* [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core)
diff --git a/content/zh/docs/tasks/inject-data-application/podpreset.md b/content/zh/docs/tasks/inject-data-application/podpreset.md
index 54efeee257..2765869e40 100644
--- a/content/zh/docs/tasks/inject-data-application/podpreset.md
+++ b/content/zh/docs/tasks/inject-data-application/podpreset.md
@@ -1,29 +1,80 @@
---
-approvers:
+title: 使用 PodPreset 将信息注入 Pod
+min-kubernetes-server-version: v1.6
+content_type: task
+weight: 60
+---
+<!--
+reviewers:
- jessfraz
-title: 使用 PodPreset 将信息注入 Pods
----
+title: Inject Information into Pods Using a PodPreset
+min-kubernetes-server-version: v1.6
+content_type: task
+weight: 60
+-->
-在 pod 创建时，用户可以使用 `podpreset` 对象将 secrets、卷挂载和环境变量等信息注入其中。
-本文展示了一些 `PodPreset` 资源使用的示例。
-用户可以从[理解 Pod Presets](/docs/concepts/workloads/pods/podpreset/) 中了解 PodPresets 的整体情况。
+{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
-{{< toc >}}
+<!--
+This page shows how to use PodPreset objects to inject information like {{< glossary_tooltip text="Secrets" term_id="secret" >}}, volume mounts, and {{< glossary_tooltip text="environment variables" term_id="container-env-variables" >}} into Pods at creation time.
+-->
+本页展示如何在创建 Pod 时 使用 PodPreset 对象将类似
+{{< glossary_tooltip text="Secret" term_id="secret" >}}、卷挂载和
+{{< glossary_tooltip text="环境变量" term_id="container-env-variables" >}}
+这类信息注入到 Pod 中。
-## 创建 Pod Preset
+## {{% heading "prerequisites" %}}
-### 简单的 Pod Spec 示例
+<!--
+You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one using [Minikube](/docs/setup/learning-environment/minikube/).
+Make sure that you have [enabled PodPreset](/docs/concepts/workloads/pods/podpreset/#enable-pod-preset) in your cluster.
+-->
+你需要一个运行的 Kubernetes 集群以及配置好与集群通信的 kubectl 命令行工具。
+如果你还没有集群，可以使用 [Minikube](/zh/docs/setup/learning-environment/minikube/)
+安装一个。
+确保你已经在集群中[启用了 PodPreset](/docs/concepts/workloads/pods/podpreset/#enable-pod-preset)。
-这里是一个简单的示例，展示了如何通过 Pod Preset 修改 Pod spec 。
+<!--
+## Use Pod presets to inject environment variables and volumes
+
+In this step, you create a preset that has a volume mount and one environment variable.
+Here is the manifest for the PodPreset:
+-->
+## 使用 PodPreset 来注入环境变量和卷
+
+在这一步中，你要创建一个 PodPreset 对象，其中包含卷挂载和一个环境变量。
+下面是 PodPreset 的清单：
{{< codenew file="podpreset/preset.yaml" >}}
+<!--
+The name of a PodPreset object must be a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+-->
+PodPreset 对象的名称必须是一个合法的
+[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
+
+<!--
+In the manifest, you can see that the preset has an environment variable definition called `DB_PORT`
+and a volume mount definition called `cache-volume` which is mounted under `/cache`. The {{< glossary_tooltip text="selector" term_id="selector" >}} specifies that
+the preset will act upon any Pod that is labeled `role:frontend`.
+
+Create the PodPreset:
+-->
+在清单中，你可以看到 PodPreset 有一个名为 `DB_PORT` 的环境变量定义，
+和一个名为 `cache-volume` 的卷挂载定义，该卷挂载于 `/cache` 下。
+{{< glossary_tooltip text="选择算符" term_id="selector" >}} 设定此 PodPreset
+将应用于所有匹配 `role:frontend` 标签的 Pods。
+
创建 PodPreset：
```shell
kubectl apply -f https://k8s.io/examples/podpreset/preset.yaml
```
+<!--
+Verify that the PodPreset has been created:
+-->
检查所创建的 PodPreset：
```shell
@@ -34,130 +85,427 @@ NAME AGE
allow-database 1m
```
-新的 PodPreset 会对所有具有标签 `role: frontend` 的 Pods 采取行动。
-
-**用户提交的 pod spec：**
+<!--
+This manifest defines a Pod labelled `role: frontend` (matching the PodPreset's selector):
+-->
+下面的清单定义了一个带有标签 `role: frontend` 的 Pod（与 PodPreset
+的选择算符匹配）：
{{< codenew file="podpreset/pod.yaml" >}}
+<!--
+Create the Pod:
+-->
创建 Pod：
```shell
kubectl create -f https://k8s.io/examples/podpreset/pod.yaml
```
-列举运行中的 Pods：
+<!--
+Verify that the Pod is running:
+-->
+验证 Pod 出于运行状态：
```shell
kubectl get pods
```
+
```
NAME READY STATUS RESTARTS AGE
website 1/1 Running 0 4m
```
-**通过准入控制器后的 Pod 规约：**
-
-{{< codenew file="podpreset/merged.yaml" >}}
-
-要查看如上输出，运行下面的命令：
+<!--
+View the Pod spec altered by the admission controller in order to see the effects of the preset
+having been applied:
+-->
+查看被准入控制器更改过的 Pod 规约，以了解 PodPreset 在 Pod 上执行过的操作：
```shell
kubectl get pod website -o yaml
```
+{{< codenew file="podpreset/merged.yaml" >}}
+
+<!--
+The `DB_PORT` environment variable, the `volumeMount` and the `podpreset.admission.kubernetes.io` annotation
+of the Pod verify that the preset has been applied.
+-->
+Pod 的环境变量 `DB_PORT`，`volumeMount` 和 `podpreset.admission.kubernetes.io` 注解
+表明 PodPreset 确实起了作用。
+
+<!--
+## Pod spec with ConfigMap example
+
+This is an example to show how a Pod spec is modified by a Pod preset
+that references a ConfigMap containing environment variables.
+-->
### 带有 ConfigMap 的 Pod Spec 示例
这里的示例展示了如何通过 PodPreset 修改 Pod 规约，PodPreset 中定义了 `ConfigMap`
作为环境变量取值来源。
-**用户提交的 pod spec：**
-
-{{< codenew file="podpreset/pod.yaml" >}}
-
-**用户提交的 `ConfigMap`：**
+<!--
+Here is the manifest containing the definition of the ConfigMap:
+-->
+包含 ConfigMap 定义的清单：
{{< codenew file="podpreset/configmap.yaml" >}}
-**PodPreset 示例：**
+<!--
+Create the ConfigMap:
+-->
+创建 ConfigMap：
+
+```shell
+kubectl create -f https://k8s.io/examples/podpreset/configmap.yaml
+```
+
+<!--
+Here is a PodPreset manifest referencing that ConfigMap:
+-->
+引用该 ConfigMap 的 PodPreset 的清单：
{{< codenew file="podpreset/allow-db.yaml" >}}
-**通过准入控制器后的 Pod spec：**
+<!--
+Create the preset that references the ConfigMap:
+-->
+创建 PodPreset：
-{{< codenew file="podpreset/allow-db-merged.yaml" >}}
+```shell
+kubectl create -f https://k8s.io/examples/podpreset/allow-db.yaml
+```
-### 带有 Pod Spec 的 ReplicaSet 示例
-
-以下示例展示了（通过 ReplicaSet 创建 pod 后）只有 pod spec 会被 Pod Preset 所修改。
-
-**用户提交的 ReplicaSet：**
-
-{{< codenew file="podpreset/replicaset.yaml" >}}
-
-**PodPreset 示例：**
-
-{{< codenew file="podpreset/preset.yaml" >}}
-
-**通过准入控制器后的 Pod spec：**
-
-注意 ReplicaSet spec 没有改变，用户必须检查单独的 pod 来验证 PodPreset 已被应用。
-
-{{< codenew file="podpreset/replicaset-merged.yaml" >}}
-
-### 多 PodPreset 示例
-
-这里的示例展示了如何通过多个 Pod 注入策略修改 Pod spec。
-
-**用户提交的 Pod 规约：**
+<!--
+The following manifest defines a Pod matching the PodPreset for this example:
+-->
+下面的清单包含与 PodPreset 匹配的 Pod：
{{< codenew file="podpreset/pod.yaml" >}}
-**PodPreset 示例：**
+<!--
+Create the Pod:
+-->
+创建 Pod：
+
+```shell
+kubectl create -f https://k8s.io/examples/podpreset/pod.yaml
+```
+
+<!--
+View the Pod spec altered by the admission controller in order to see the effects of the preset
+having been applied:
+-->
+查看 Pod 规约被准入控制器修改后的结果，了解 PodPreset 应用之后的效果：
+
+```shell
+kubectl get pod website -o yaml
+```
+
+{{< codenew file="podpreset/allow-db-merged.yaml" >}}
+
+<!--
+The `DB_PORT` environment variable and the `podpreset.admission.kubernetes.io` annotation of the Pod
+verify that the preset has been applied.
+-->
+Pod 的环境变量 `DB_PORT` 和 `podpreset.admission.kubernetes.io` 注解
+表明 PodPreset 确实起了作用。
+<!--
+## ReplicaSet with Pod spec example
+
+This is an example to show that only Pod specs are modified by Pod presets. Other workload types
+like ReplicaSets or Deployments are unaffected.
+
+Here is the manifest for the PodPreset for this example:
+-->
+### 带有 Pod Spec 的 ReplicaSet 示例
+
+以下示例展示了（通过 ReplicaSet 创建 Pod 后）只有 Pod 规约会被 PodPreset 所修改,
+其他资源类型（如 ReplicaSet、Deployment）不受影响。
+
+下面是本例所用 PodPreset 的清单：
{{< codenew file="podpreset/preset.yaml" >}}
-**另一个 Pod Preset 示例：**
+<!--
+Create the preset:
+-->
+创建 Preset：
+
+```shell
+kubectl apply -f https://k8s.io/examples/podpreset/preset.yaml
+```
+
+<!--
+This manifest defines a ReplicaSet that manages three application Pods:
+-->
+此清单定义了一个管理三个应用 Pod 的 ReplicaSet：
+
+{{< codenew file="podpreset/replicaset.yaml" >}}
+
+<!--
+Create the ReplicaSet:
+-->
+创建 ReplicaSet：
+
+```shell
+kubectl create -f https://k8s.io/examples/podpreset/replicaset.yaml
+```
+
+<!--
+Verify that the Pods created by the ReplicaSet are running:
+-->
+验证 ReplicaSet 所创建的 Pod 处于运行状态：
+
+```shell
+kubectl get pods
+```
+
+<!--
+The output shows that the Pods are running:
+-->
+输出显示 Pod 正在运行：
+
+```
+NAME READY STATUS RESTARTS AGE
+frontend-2l94q 1/1 Running 0 2m18s
+frontend-6vdgn 1/1 Running 0 2m18s
+frontend-jzt4p 1/1 Running 0 2m18s
+```
+
+<!--
+View the `spec` of the ReplicaSet:
+-->
+查看 ReplicaSet 的 `spec` 内容：
+
+```shell
+kubectl get replicasets frontend -o yaml
+```
+
+<!--
+The ReplicaSet object's `spec` was not changed, nor does the ReplicaSet contain a
+`podpreset.admission.kubernetes.io` annotation. This is because a PodPreset only
+applies to Pod objects.
+
+To see the effects of the preset having been applied, you need to look at individual Pods.
+-->
+{{< note >}}
+ReplicaSet 对象的 `spec` 未被改变，ReplicaSet 也没有被添加
+`podpreset.admission.kubernetes.io` 注解。这是因为，PodPreset 只针对
+Pod 对象起作用。
+
+要查看 PodPreset 的应用效果，你需要逐个地查看 Pod。
+{{< /note >}}
+
+<!--
+The command to view the specs of the affected Pods is:
+-->
+查看被影响的 Pod 的规约的命令是：
+
+```shell
+kubectl get pod --selector=role=frontend -o yaml
+```
+
+{{< codenew file="podpreset/replicaset-merged.yaml" >}}
+
+<!--
+Again the `podpreset.admission.kubernetes.io` annotation of the Pods
+verifies that the preset has been applied.
+-->
+再一次，Pod 的 `podpreset.admission.kubernetes.io` 注解表明 PodPreset
+已经被应用过。
+
+<!--
+## Multiple Pod presets example
+
+This is an example to show how a Pod spec is modified by multiple Pod presets.
+
+Here is the manifest for the first PodPreset:
+-->
+### 多 PodPreset 示例
+
+这里的示例展示了如何通过多个 PodPreset 对象修改 Pod 规约。
+
+第一个 PodPreset 的清单如下：
+
+{{< codenew file="podpreset/preset.yaml" >}}
+
+<!--
+Create the first PodPreset for this example:
+-->
+为此例创建第一个 PodPreset：
+
+```shell
+kubectl apply -f https://k8s.io/examples/podpreset/preset.yaml
+```
+
+<!--
+Here is the manifest for the second PodPreset:
+-->
+下面是第二个 PodPreset 的清单：
{{< codenew file="podpreset/proxy.yaml" >}}
-**通过准入控制器后的 Pod 规约：**
+<!--
+Create the second preset:
+-->
+创建第二个 PodPreset：
+
+```shell
+kubectl apply -f https://k8s.io/examples/podpreset/proxy.yaml
+```
+
+<!--
+Here's a manifest containing the definition of an applicable Pod (matched by two PodPresets):
+-->
+下面是包含可被修改的 Pod 定义的清单（此 Pod 同时被两个 PodPreset 匹配到）：
+
+{{< codenew file="podpreset/pod.yaml" >}}
+
+<!--
+Create the Pod:
+-->
+创建 Pod：
+
+```shell
+kubectl create -f https://k8s.io/examples/podpreset/pod.yaml
+```
+
+<!--
+View the Pod spec altered by the admission controller in order to see the effects of both presets
+having been applied:
+-->
+查看被准入控制器更改后的 Pod 规约，以了解被两个 PodPreset 一同修改
+后的效果：
+
+```shell
+kubectl get pod website -o yaml
+```
{{< codenew file="podpreset/multi-merged.yaml" >}}
+<!--
+The `DB_PORT` environment variable, the `proxy-volume` VolumeMount and the two `podpreset.admission.kubernetes.io`
+annotations of the Pod verify that both presets have been applied.
+-->
+Pod 定义中的 `DB_PORT` 环境变量、`proxy-volume` 卷挂载以及
+两个 `podpreset.admission.kubernetes.io` 可以证明两个 Preset 都被应用了。
+
+<!--
+## Conflict example
+
+This is an example to show how a Pod spec is not modified by a Pod preset when there is a conflict.
+The conflict in this example consists of a `VolumeMount` in the PodPreset conflicting with a Pod that defines the same `mountPath`.
+
+Here is the manifest for the PodPreset:
+-->
### 冲突示例
-这里的示例展示了 PodPreset 与原 Pod 存在冲突时，Pod spec 不会被修改。
+这里的示例展示了 PodPreset 与原 Pod 存在冲突时，Pod 规约不会被修改。
+本例中的冲突是指 PodPreset 中的 `volumeMount` 与 Pod 中定义的卷挂载在
+`mountPath` 上有冲突。
-**用户提交的 Pod 规约：**
-
-{{< codenew file="podpreset/conflict-pod.yaml" >}}
-
-**PodPreset 示例：**
+下面是 PodPreset 的清单：
{{< codenew file="podpreset/conflict-preset.yaml" >}}
-**因存在冲突，通过准入控制器后的 Pod spec 不会改变：**
+<!--
+Note the `mountPath` value of `/cache`.
+
+Create the preset:
+-->
+注意 `mountPath` 的取值是 `/cache`。
+创建 PodPreset：
+
+```shell
+kubectl apply -f https://k8s.io/examples/podpreset/conflict-preset.yaml
+```
+
+<!--
+Here is the manifest for the Pod:
+-->
+下面是 Pod 的清单：
{{< codenew file="podpreset/conflict-pod.yaml" >}}
-**如果运行 `kubectl describe...` 用户会看到以下事件：**
+<!--
+Note the volumeMount element with the same path as in the PodPreset.
-```
-$ kubectl describe ...
-....
-Events:
- FirstSeen LastSeen Count From SubobjectPath Reason Message
- Tue, 07 Feb 2017 16:56:12 -0700 Tue, 07 Feb 2017 16:56:12 -0700 1 {podpreset.admission.kubernetes.io/podpreset-allow-database } conflict Conflict on pod preset. Duplicate mountPath /cache.
+Create the Pod:
+-->
+注意清单中 `volumeMount` 元素的取值与 PodPreset 中的路径值相同。
+
+创建 Pod：
+
+```shell
+kubectl create -f https://k8s.io/examples/podpreset/conflict-pod.yaml
```
+<!--
+View the Pod spec:
+-->
+查看 Pod 规约：
+
+```shell
+kubectl get pod website -o yaml
+```
+
+{{< codenew file="podpreset/conflict-pod.yaml" >}}
+
+<!--
+You can see there is no preset annotation (`podpreset.admission.kubernetes.io`). Seeing no annotation tells you that no preset has not been applied to the Pod.
+
+However, the
+[PodPreset admission controller](/docs/reference/access-authn-authz/admission-controllers/#podpreset)
+logs a warning containing details of the conflict.
+You can view the warning using `kubectl`:
+-->
+这里你可以看到 Pod 上并没有 PodPreset 的注解 podpreset.admission.kubernetes.io`。
+这意味着没有 PodPreset 被应用到 Pod 之上。
+
+不过 [PodPreset 准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#podpreset)
+还是为所发生的冲突留下了一条警告性质的日志。
+你可以通过 `kubectl` 来查看此警告信息：
+
+```shell
+kubectl -n kube-system logs -l=component=kube-apiserver
+```
+
+<!--
+The output should look similar to:
+-->
+输出类似于：
+
+```
+W1214 13:00:12.987884 1 admission.go:147] conflict occurred while applying podpresets: allow-database on pod: err: merging volume mounts for allow-database has a conflict on mount path /cache:
+v1.VolumeMount{Name:"other-volume", ReadOnly:false, MountPath:"/cache", SubPath:"", MountPropagation:(*v1.MountPropagationMode)(nil), SubPathExpr:""}
+does not match
+core.VolumeMount{Name:"cache-volume", ReadOnly:false, MountPath:"/cache", SubPath:"", MountPropagation:(*core.MountPropagationMode)(nil), SubPathExpr:""}
+ in container
+```
+
+注意这里关于卷挂载路径冲突的消息。
+
+<!--
+## Deleting a PodPreset
+
+Once you don't need a PodPreset anymore, you can delete it with `kubectl`:
+-->
## 删除 Pod Preset
-一旦用户不再需要 pod preset，可以使用 `kubectl` 进行删除：
+一旦用户不再需要 PodPreset，可以使用 `kubectl` 将其删除：
```shell
kubectl delete podpreset allow-database
```
+
+<!--
+The output shows that the PodPreset was deleted:
+-->
+输出显示 PodPreset 已经被删除：
+
```
podpreset "allow-database" deleted
```
diff --git a/content/zh/docs/tasks/job/automated-tasks-with-cron-jobs.md b/content/zh/docs/tasks/job/automated-tasks-with-cron-jobs.md
index 503741d091..fdf54115bf 100644
--- a/content/zh/docs/tasks/job/automated-tasks-with-cron-jobs.md
+++ b/content/zh/docs/tasks/job/automated-tasks-with-cron-jobs.md
@@ -1,20 +1,17 @@
---
-reviewers:
-- chenopis
-
title: 使用 CronJob 运行自动化任务
content_type: task
weight: 10
+min-kubernetes-server-version: v1.8
---
<!--
----
title: Running Automated Tasks with a CronJob
reviewers:
- chenopis
content_type: task
weight: 10
----
+min-kubernetes-server-version: v1.8
-->
<!-- overview -->
@@ -31,14 +28,15 @@ Cron jobs can also schedule individual tasks for a specific time, such as if you
CronJobs 在创建周期性以及重复性的任务时很有帮助，例如执行备份操作或者发送邮件。CronJobs 也可以在特定时间调度单个任务，例如你想调度低活跃周期的任务。
-{{< note >}}
<!--
CronJob resource in `batch/v2alpha1` API group has been deprecated starting from cluster version 1.8.
You should switch to using `batch/v1beta1`, instead, which is enabled by default in the API server.
Examples in this document use `batch/v1beta1` in all examples.
-->
-从集群版本1.8开始，`batch/v2alpha1` API 组中的 CronJob 资源已经被废弃。
-你应该切换到 API 服务器默认启用的 `batch/v1beta1` API 组。本文中的所有示例使用了`batch/v1beta1`。
+{{< note >}}
+从集群版本 1.8 开始，`batch/v2alpha1` API 组中的 CronJob 资源已经被废弃。
+你应该切换到 API 服务器默认启用的 `batch/v1beta1` API 组。
+本文中的所有示例使用了 `batch/v1beta1`。
{{< /note >}}
<!--
@@ -47,30 +45,15 @@ For example, in certain circumstances, a single cron job can create multiple job
Therefore, jobs should be idempotent.
For more limitations, see [CronJobs](/docs/concepts/workloads/controllers/cron-jobs).
-->
-
CronJobs 有一些限制和特点。
例如，在特定状况下，同一个 CronJob 可以创建多个任务。
因此，任务应该是幂等的。
查看更多限制，请参考 [CronJobs](/zh/docs/concepts/workloads/controllers/cron-jobs)。
-
-
## {{% heading "prerequisites" %}}
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-<!--
-* You need a working Kubernetes cluster at version >= 1.8 (for CronJob). For previous versions of cluster (< 1.8)
-you need to explicitly enable `batch/v2alpha1` API by passing `--runtime-config=batch/v2alpha1=true` to
-the API server (see [Turn on or off an API version for your cluster](/docs/admin/cluster-management/#turn-on-or-off-an-api-version-for-your-cluster)
-for more), and then restart both the API server and the controller manager
-component.
--->
-
-* 你需要一个版本 >=1.8 且工作正常的 Kubernetes 集群。对于更早的版本（ <1.8 ），你需要对 API 服务器设置 `--runtime-config=batch/v2alpha1=true` 来开启 `batch/v2alpha1` API，(更多信息请查看 [为你的集群开启或关闭 API 版本](/zh/docs/tasks/administer-cluster/cluster-management/#打开或关闭集群的-api-版本)
-), 然后重启 API 服务器和控制管理器。
-
-
<!-- steps -->
@@ -80,7 +63,6 @@ component.
Cron jobs require a config file.
This example cron job config `.spec` file prints the current time and a hello message every minute:
-->
-
## 创建 CronJob
CronJob 需要一个配置文件。
@@ -91,61 +73,69 @@ CronJob 需要一个配置文件。
<!--
Run the example cron job by downloading the example file and then running this command:
-->
-
想要运行示例的 CronJob，可以下载示例文件并执行命令：
```shell
-$ kubectl create -f ./cronjob.yaml
-cronjob "hello" created
+kubectl create -f ./cronjob.yaml
```
-
-<!--
-Alternatively, you can use `kubectl run` to create a cron job without writing a full config:
--->
-
-或者你也可以使用 `kubectl run` 来创建一个 CronJob 而不需要编写完整的配置：
-
-```shell
-$ kubectl run hello --schedule="*/1 * * * *" --restart=OnFailure --image=busybox -- /bin/sh -c "date; echo Hello from the Kubernetes cluster"
-cronjob "hello" created
+```
+cronjob.batch/hello created
```
<!--
After creating the cron job, get its status using this command:
-->
-
创建好 CronJob 后，使用下面的命令来获取其状态：
```shell
-$ kubectl get cronjob hello
-NAME SCHEDULE SUSPEND ACTIVE LAST-SCHEDULE
-hello */1 * * * * False 0 <none>
+kubectl get cronjob hello
```
+<!--
+The output is similar to this:
+-->
+输出类似于：
+
+```
+NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
+hello */1 * * * * False 0 50s 75s
+```
<!--
As you can see from the results of the command, the cron job has not scheduled or run any jobs yet.
Watch for the job to be created in around one minute:
-->
-
就像你从命令返回结果看到的那样，CronJob 还没有调度或执行任何任务。大约需要一分钟任务才能创建好。
```shell
-$ kubectl get jobs --watch
-NAME DESIRED SUCCESSFUL AGE
-hello-4111706356 1 1 2s
+kubectl get jobs --watch
+```
+
+```
+NAME COMPLETIONS DURATION AGE
+hello-4111706356 0/1 0s
+hello-4111706356 0/1 0s 0s
+hello-4111706356 1/1 5s 5s
```
<!--
Now you've seen one running job scheduled by the "hello" cron job.
You can stop watching the job and view the cron job again to see that it scheduled the job:
-->
-
-现在你已经看到了一个运行中的任务被 “hello” CronJob 调度。你可以停止监视这个任务，然后再次查看 CronJob 就能看到它调度任务：
+现在你已经看到了一个运行中的任务被 “hello” CronJob 调度。
+你可以停止监视这个任务，然后再次查看 CronJob 就能看到它调度任务：
```shell
-$ kubectl get cronjob hello
-NAME SCHEDULE SUSPEND ACTIVE LAST-SCHEDULE
-hello */1 * * * * False 0 Mon, 29 Aug 2016 14:34:00 -0700
+kubectl get cronjob hello
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于：
+
+```
+NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
+hello */1 * * * * False 0 50s 75s
```
<!--
@@ -155,21 +145,34 @@ There are currently 0 active jobs, meaning that the job has completed or failed.
Now, find the pods that the last scheduled job created and view the standard output of one of the pods.
Note that the job name and pod name are different.
-->
-
-你应该能看到 “hello” CronJob 在 `LAST-SCHEDULE` 声明的时间点成功的调度了一次任务。有0个活跃的任务意味着任务执行完毕或者执行失败。
+你应该能看到 “hello” CronJob 在 `LAST-SCHEDULE` 声明的时间点成功的调度了一次任务。
+有 0 个活跃的任务意味着任务执行完毕或者执行失败。
现在，找到最后一次调度任务创建的 Pod 并查看一个 Pod 的标准输出。请注意任务名称和 Pod 名称是不同的。
+<!--
+The job name and pod name are different.
+-->
+{{< note >}}
+Job 名称和 Pod 名称不同。
+{{< /note >}}
```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})
+# 在你的系统上将 "hello-4111706356" 替换为 Job 名称
+pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items..metadata.name})
+```
-$ echo $pods
-hello-4111706356-o9qcm
+<!--
+Show pod log:
+-->
+查看 Pod 日志：
-$ kubectl logs $pods
-Mon Aug 29 21:34:09 UTC 2016
+```shell
+kubectl logs $pods
+```
+
+```
+Fri Feb 22 11:02:09 UTC 2019
Hello from the Kubernetes cluster
```
@@ -179,41 +182,42 @@ Hello from the Kubernetes cluster
When you don't need a cron job any more, delete it with `kubectl delete cronjob`:
-->
-## 删除 CronJob
-
当你不再需要 CronJob 时，可以用 `kubectl delete cronjob` 删掉它：
```shell
-$ kubectl delete cronjob hello
-cronjob "hello" deleted
+kubectl delete cronjob hello
```
+
<!--
Deleting the cron job removes all the jobs and pods it created and stops it from creating additional jobs.
You can read more about removing jobs in [garbage collection](/docs/concepts/workloads/controllers/garbage-collection/).
-->
-
-删除 CronJob 会清除它创建的所有任务和 Pod，并阻止它创建额外的任务。你可以查阅 [垃圾收集](/zh/docs/concepts/workloads/controllers/garbage-collection/)。
+删除 CronJob 会清除它创建的所有任务和 Pod，并阻止它创建额外的任务。你可以查阅
+[垃圾收集](/zh/docs/concepts/workloads/controllers/garbage-collection/)。
<!--
## Writing a Cron Job Spec
As with all other Kubernetes configs, a cron job needs `apiVersion`, `kind`, and `metadata` fields. For general
-information about working with config files, see [deploying applications](/docs/user-guide/deploying-applications),
-and [using kubectl to manage resources](/docs/user-guide/working-with-resources) documents.
+information about working with config files, see [deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/),
+and [using kubectl to manage resources](/docs/concepts/overview/working-with-objects/object-management/) documents.
A cron job config also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
-->
-
## 编写 CronJob 声明信息
-像 Kubernetes 的其他配置一样，CronJob 需要 `apiVersion`、 `kind`、 和 `metadata` 域。配置文件的一般信息，请参考 [部署应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/) 和 [使用 kubectl 管理资源](/zh/docs/concepts/overview/working-with-objects/object-management/).
+像 Kubernetes 的其他配置一样，CronJob 需要 `apiVersion`、`kind`、和 `metadata` 域。
+配置文件的一般信息，请参考
+[部署应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/) 和
+[使用 kubectl 管理资源](/zh/docs/concepts/overview/working-with-objects/object-management/).
-CronJob 配置也需要包括[`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
+CronJob 配置也需要包括
+[`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
-{{< note >}}
<!--
All modifications to a cron job, especially its `.spec`, are applied only to the following runs.
-->
+{{< note >}}
对 CronJob 的所有改动，特别是它的 `.spec`，只会影响将来的运行实例。
{{< /note >}}
@@ -223,16 +227,16 @@ All modifications to a cron job, especially its `.spec`, are applied only to the
The `.spec.schedule` is a required field of the `.spec`.
It takes a [Cron](https://en.wikipedia.org/wiki/Cron) format string, such as `0 * * * *` or `@hourly`, as schedule time of its jobs to be created and executed.
-->
-
### 时间安排
-`.spec.schedule` 是 `.spec` 需要的域。它使用了 [Cron](https://en.wikipedia.org/wiki/Cron) 格式串，例如 `0 * * * *` or `@hourly` ，做为它的任务被创建和执行的调度时间。
+`.spec.schedule` 是 `.spec` 需要的域。它使用了 [Cron](https://en.wikipedia.org/wiki/Cron)
+格式串，例如 `0 * * * *` or `@hourly` ，做为它的任务被创建和执行的调度时间。
<!--
The format also includes extended `vixie cron` step values. As explained in the [FreeBSD manual](https://www.freebsd.org/cgi/man.cgi?crontab%285%29):
-->
-
-该格式也包含了扩展的 `vixie cron` 步长值。[FreeBSD 手册](https://www.freebsd.org/cgi/man.cgi?crontab%285%29)中解释如下:
+该格式也包含了扩展的 `vixie cron` 步长值。
+[FreeBSD 手册](https://www.freebsd.org/cgi/man.cgi?crontab%285%29)中解释如下:
<!--
> Step values can be used in conjunction with ranges. Following a range
@@ -244,13 +248,14 @@ The format also includes extended `vixie cron` step values. As explained in the
-->
> 步长可被用于范围组合。范围后面带有 `/<数字>` 可以声明范围内的步幅数值。
-> 例如，`0-23/2` 可被用在小时域来声明命令在其他数值的小时数执行（ V7 标准中对应的方法是`0,2,4,6,8,10,12,14,16,18,20,22`）。
+> 例如，`0-23/2` 可被用在小时域来声明命令在其他数值的小时数执行
+> （ V7 标准中对应的方法是`0,2,4,6,8,10,12,14,16,18,20,22`）。
> 步长也可以放在通配符后面，因此如果你想表达 "每两小时"，就用 `*/2` 。
-{{< note >}}
<!--
A question mark (`?`) in the schedule has the same meaning as an asterisk `*`, that is, it stands for any of available value for a given field.
-->
+{{< note >}}
调度中的问号 (`?`) 和星号 `*` 含义相同，表示给定域的任何可用值。
{{< /note >}}
@@ -258,14 +263,18 @@ A question mark (`?`) in the schedule has the same meaning as an asterisk `*`, t
### Job Template
The `.spec.jobTemplate` is the template for the job, and it is required.
-It has exactly the same schema as a [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/), except that it is nested and does not have an `apiVersion` or `kind`.
-For information about writing a job `.spec`, see [Writing a Job Spec](/docs/concepts/workloads/controllers/jobs-run-to-completion/#writing-a-job-spec).
+It has exactly the same schema as a [Job](/docs/concepts/workloads/controllers/job/),
+except that it is nested and does not have an `apiVersion` or `kind`.
+For information about writing a job `.spec`, see
+[Writing a Job Spec](/docs/concepts/workloads/controllers/job/#writing-a-job-spec).
-->
-
### 任务模版
-`.spec.jobTemplate`是任务的模版，它是必须的。它和 [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)的语法完全一样，除了它是嵌套的没有 `apiVersion` 和 `kind`。
-编写任务的 `.spec` ，请参考 [编写任务的Spec](/docs/concepts/workloads/controllers/jobs-run-to-completion/#writing-a-job-spec)。
+`.spec.jobTemplate`是任务的模版，它是必须的。它和
+[Job](/zh/docs/concepts/workloads/controllers/job/)的语法完全一样，
+除了它是嵌套的没有 `apiVersion` 和 `kind`。
+编写任务的 `.spec` ，请参考
+[编写 Job 的Spec](/zh/docs/concepts/workloads/controllers/job/#writing-a-job-spec)。
<!--
### Starting Deadline
@@ -276,8 +285,7 @@ After the deadline, the cron job does not start the job.
Jobs that do not meet their deadline in this way count as failed jobs.
If this field is not specified, the jobs have no deadline.
-->
-
-### 开始的最后期限
+### 开始的最后期限 {#starting-deadline}
`.spec.startingDeadlineSeconds` 域是可选的。
它表示任务如果由于某种原因错过了调度时间，开始该任务的截止时间的秒数。过了截止时间，CronJob 就不会开始任务。
@@ -294,11 +302,15 @@ field is set (not null), the CronJob controller counts how many missed jobs occu
schedules occurred in the last 200 seconds. In that case, if there were more than 100 missed schedules in the
last 200 seconds, the cron job is no longer scheduled.
-->
-
-CronJob 控制器会统计错过了多少次调度。如果错过了100次以上的调度，CronJob 就不再调度了。当没有设置 `.spec.startingDeadlineSeconds` 时，CronJob 控制器统计从`status.lastScheduleTime`到当前的调度错过次数。
-例如一个 CronJob 期望每分钟执行一次，`status.lastScheduleTime`是 5:00am，但现在是 7:00am。那意味着120次调度被错过了，所以 CronJob 将不再被调度。
-如果设置了 `.spec.startingDeadlineSeconds` 域(非空)，CronJob 控制器统计从 `.spec.startingDeadlineSeconds` 到当前时间错过了多少次任务。
-例如设置了 `200`，它会统计过去200秒内错过了多少次调度。在那种情况下，如果过去200秒内错过了超过100次的调度，CronJob 就不再调度。
+CronJob 控制器会统计错过了多少次调度。如果错过了100次以上的调度，CronJob 就不再调度了。
+当没有设置 `.spec.startingDeadlineSeconds` 时，CronJob 控制器统计从
+`status.lastScheduleTime` 到当前的调度错过次数。
+例如一个 CronJob 期望每分钟执行一次，`status.lastScheduleTime`是 `5:00am`，
+但现在是 `7:00am`。那意味着 120 次调度被错过了，所以 CronJob 将不再被调度。
+如果设置了 `.spec.startingDeadlineSeconds` 域(非空)，CronJob 控制器统计从
+`.spec.startingDeadlineSeconds` 到当前时间错过了多少次任务。
+例如设置了 `200`，它会统计过去 200 秒内错过了多少次调度。
+在那种情况下，如果过去 200 秒内错过了超过 100 次的调度，CronJob 就不再调度。
<!--
### Concurrency Policy
@@ -314,10 +326,10 @@ the spec may specify only one of the following concurrency policies:
Note that concurrency policy only applies to the jobs created by the same cron job.
If there are multiple cron jobs, their respective jobs are always allowed to run concurrently.
-->
-
### 并发性规则
-`.spec.concurrencyPolicy` 也是可选的。它声明了 CronJob 创建的任务执行时发生重叠如何处理。spec 仅能声明下列规则中的一种：
+`.spec.concurrencyPolicy` 也是可选的。它声明了 CronJob 创建的任务执行时发生重叠如何处理。
+spec 仅能声明下列规则中的一种：
* `Allow` (默认)：CronJob 允许并发任务执行。
* `Forbid`： CronJob 不允许并发任务执行；如果新任务的执行时间到了而老任务没有执行完，CronJob 会忽略新任务的执行。
@@ -333,17 +345,18 @@ If it is set to `true`, all subsequent executions are suspended.
This setting does not apply to already started executions.
Defaults to false.
-->
-
### 挂起
-`.spec.suspend`域也是可选的。如果设置为 `true` ，后续发生的执行都会挂起。这个设置对已经开始的执行不起作用。默认是关闭的。
+`.spec.suspend`域也是可选的。如果设置为 `true` ，后续发生的执行都会挂起。
+这个设置对已经开始的执行不起作用。默认是关闭的。
-{{< caution >}}
<!--
Executions that are suspended during their scheduled time count as missed jobs.
When `.spec.suspend` changes from `true` to `false` on an existing cron job without a [starting deadline](#starting-deadline), the missed jobs are scheduled immediately.
-->
-在调度时间内挂起的执行都会被统计为错过的任务。当 `.spec.suspend` 从 `true` 改为 `false` 时，且没有 [开始的最后期限](#starting-deadline)，错过的任务会被立即调度。
+{{< caution >}}
+在调度时间内挂起的执行都会被统计为错过的任务。当 `.spec.suspend` 从 `true` 改为 `false` 时，
+且没有 [开始的最后期限](#starting-deadline)，错过的任务会被立即调度。
{{< /caution >}}
<!--
@@ -353,7 +366,6 @@ The `.spec.successfulJobsHistoryLimit` and `.spec.failedJobsHistoryLimit` fields
These fields specify how many completed and failed jobs should be kept.
By default, they are set to 3 and 1 respectively. Setting a limit to `0` corresponds to keeping none of the corresponding kind of jobs after they finish.
-->
-
### 任务历史限制
`.spec.successfulJobsHistoryLimit` 和 `.spec.failedJobsHistoryLimit`是可选的。
diff --git a/content/zh/docs/tasks/job/coarse-parallel-processing-work-queue.md b/content/zh/docs/tasks/job/coarse-parallel-processing-work-queue.md
index 8a74313894..0259283757 100644
--- a/content/zh/docs/tasks/job/coarse-parallel-processing-work-queue.md
+++ b/content/zh/docs/tasks/job/coarse-parallel-processing-work-queue.md
@@ -1,5 +1,6 @@
---
title: 使用工作队列进行粗粒度并行处理
+min-kubernetes-server-version: v1.8
content_type: task
weight: 30
---
@@ -7,6 +8,7 @@ weight: 30
<!--
---
title: Coarse Parallel Processing Using a Work Queue
+min-kubernetes-server-version: v1.8
content_type: task
weight: 30
---
@@ -30,7 +32,6 @@ Here is an overview of the steps in this example:
1. **Start a Job that works on tasks from the queue**. The Job starts several pods. Each pod takes
one task from the message queue, processes it, and repeats until the end of the queue is reached.
-->
-
本例中，我们会运行包含多个并行工作进程的 Kubernetes Job。
本例中，每个 Pod 一旦被创建，会立即从任务队列中取走一个工作单元并完成它，然后将工作单元从队列中删除后再退出。
@@ -44,8 +45,6 @@ Here is an overview of the steps in this example:
1. **启动一个在队列中执行这些任务的 Job**。该 Job 启动多个 Pod。每个 Pod 从消息队列中取走一个任务，处理它，然后重复执行，直到队列的队尾。
-
-
## {{% heading "prerequisites" %}}
@@ -54,12 +53,11 @@ Be familiar with the basic,
non-parallel, use of [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/).
-->
-要熟悉 Job 基本用法（非并行的），请参考 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)。
+要熟悉 Job 基本用法（非并行的），请参考
+[Job](/zh/docs/concepts/workloads/controllers/job/)。
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
<!-- steps -->
<!--
@@ -72,7 +70,6 @@ cluster and reuse it for many jobs, as well as for long-running services.
Start RabbitMQ as follows:
-->
-
## 启动消息队列服务
本例使用了 RabbitMQ，使用其他 AMQP 类型的消息服务应该比较容易。
@@ -82,9 +79,17 @@ Start RabbitMQ as follows:
按下面的方法启动 RabbitMQ：
```shell
-$ kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.3/examples/celery-rabbitmq/rabbitmq-service.yaml
+kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.3/examples/celery-rabbitmq/rabbitmq-service.yaml
+```
+```
service "rabbitmq-service" created
-$ kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.3/examples/celery-rabbitmq/rabbitmq-controller.yaml
+```
+
+```shell
+kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.3/examples/celery-rabbitmq/rabbitmq-controller.yaml
+```
+
+```
replicationcontroller "rabbitmq-controller" created
```
@@ -103,7 +108,6 @@ and experiment with queues.
First create a temporary interactive Pod.
-->
-
## 测试消息队列服务
现在，我们可以试着访问消息队列。我们将会创建一个临时的可交互的 Pod，在它上面安装一些工具，然后用队列做实验。
@@ -112,7 +116,9 @@ First create a temporary interactive Pod.
```shell
# 创建一个临时的可交互的 Pod
-$ kubectl run -i --tty temp --image ubuntu:14.04
+kubectl run -i --tty temp --image ubuntu:14.04
+```
+```
Waiting for pod default/temp-loe07 to be running, status is Pending, pod ready: false
... [ previous line repeats several times .. hit return when it stops ] ...
```
@@ -122,7 +128,6 @@ Note that your pod name and command prompt will be different.
Next install the `amqp-tools` so we can work with message queues.
-->
-
请注意你的 Pod 名称和命令提示符将会不同。
接下来安装 `amqp-tools` ，这样我们就能用消息队列了。
@@ -148,10 +153,6 @@ Next, we will check that we can discover the rabbitmq service:
<!--
# Note the rabbitmq-service has a DNS name, provided by Kubernetes:
-->
-<!--
-# Your address will vary.
--->
-
```
# 请注意 rabbitmq-service 有Kubernetes 提供的 DNS 名称，
@@ -162,54 +163,43 @@ Address: 10.0.0.10#53
Name: rabbitmq-service.default.svc.cluster.local
Address: 10.0.147.152
-# 你的 IP 地址将会发生变化。
+# 你的 IP 地址会不同
```
<!--
If Kube-DNS is not setup correctly, the previous step may not work for you.
You can also find the service IP in an env var:
-->
-
如果 Kube-DNS 没有正确安装，上一步可能会出错。
你也可以在环境变量中找到服务 IP。
<!--
# Your address will vary.
-->
-
```
# env | grep RABBIT | grep HOST
RABBITMQ_SERVICE_SERVICE_HOST=10.0.147.152
-# 你的 IP 地址将会发生变化。
+# 你的 IP 地址会有所不同
```
<!--
Next we will verify we can create a queue, and publish and consume messages.
-->
-
接着我们将要确认可以创建队列，并能发布消息和消费消息。
<!--
# In the next line, rabbitmq-service is the hostname where the rabbitmq-service
# can be reached. 5672 is the standard port for rabbitmq.
--->
-<!--
+
# If you could not resolve "rabbitmq-service" in the previous step,
# then use this command instead:
# root@temp-loe07:/# BROKER_URL=amqp://guest:guest@$RABBITMQ_SERVICE_SERVICE_HOST:5672
-
# Now create a queue:
-
--->
-<!--
# and publish a message to it:
--->
-<!--
# and get it back.
-->
-
```shell
# 下一行，rabbitmq-service 是访问 rabbitmq-service 的主机名。5672是 rabbitmq 的标准端口。
@@ -232,6 +222,7 @@ root@temp-loe07:/# /usr/bin/amqp-consume --url=$BROKER_URL -q foo -c 1 cat && ec
Hello
root@temp-loe07:/#
```
+
<!--
In the last command, the `amqp-consume` tool takes one message (`-c 1`)
from the queue, and passes that message to the standard input of an arbitrary command. In this case, the program `cat` is just printing
@@ -255,7 +246,6 @@ In a practice, the content of the messages might be:
- configuration parameters to a simulation
- frame numbers of a scene to be rendered
-->
-
## 为队列增加任务
现在让我们给队列增加一些任务。在我们的示例中，任务是多个待打印的字符串。
@@ -283,9 +273,9 @@ In practice, you might write a program to fill the queue using an amqp client li
例如，我们创建队列并使用 amqp 命令行工具向队列中填充消息。实践中，你可以写个程序来利用 amqp 客户端库来填充这些队列。
```shell
-$ /usr/bin/amqp-declare-queue --url=$BROKER_URL -q job1 -d job1
-$ for f in apple banana cherry date fig grape lemon melon
+/usr/bin/amqp-declare-queue --url=$BROKER_URL -q job1 -d job1
+for f in apple banana cherry date fig grape lemon melon
do
/usr/bin/amqp-publish --url=$BROKER_URL -r job1 -p -b $f
done
@@ -302,7 +292,6 @@ We will use the `amqp-consume` utility to read the message
from the queue and run our actual program. Here is a very simple
example program:
-->
-
这样，我们给队列中填充了8个消息。
## 创建镜像
@@ -322,10 +311,14 @@ and [worker.py](/examples/application/job/rabbitmq/worker.py). In either case,
build the image with this command:
-->
-现在，编译镜像。如果你在用源代码树，那么切换到目录 `examples/job/work-queue-1`。否则的话，创建一个临时目录，切换到这个目录。下载 [Dockerfile](/examples/application/job/rabbitmq/Dockerfile)，和 [worker.py](/examples/application/job/rabbitmq/worker.py)。无论哪种情况，都可以用下面的命令编译镜像
+现在，编译镜像。如果你在用源代码树，那么切换到目录 `examples/job/work-queue-1`。
+否则的话，创建一个临时目录，切换到这个目录。下载
+[Dockerfile](/examples/application/job/rabbitmq/Dockerfile)，和
+[worker.py](/examples/application/job/rabbitmq/worker.py)。
+无论哪种情况，都可以用下面的命令编译镜像
```shell
-$ docker build -t job-wq-1 .
+docker build -t job-wq-1 .
```
<!--
@@ -333,8 +326,8 @@ For the [Docker Hub](https://hub.docker.com/), tag your app image with
your username and push to the Hub with the below commands. Replace
`<username>` with your Hub username.
-->
-
-对于 [Docker Hub](https://hub.docker.com/), 给你的应用镜像打上标签，标签为你的用户名，然后用下面的命令推送到 Hub。用你的 Hub 用户名替换 `<username>`。
+对于 [Docker Hub](https://hub.docker.com/), 给你的应用镜像打上标签，
+标签为你的用户名，然后用下面的命令推送到 Hub。用你的 Hub 用户名替换 `<username>`。
```shell
docker tag job-wq-1 <username>/job-wq-1
@@ -347,8 +340,9 @@ Registry](https://cloud.google.com/tools/container-registry/), tag
your app image with your project ID, and push to GCR. Replace
`<project>` with your project ID.
-->
-
-如果你在用[谷歌容器仓库](https://cloud.google.com/tools/container-registry/)，用你的项目 ID 作为标签打到你的应用镜像上，然后推送到 GCR。用你的项目 ID 替换 `<project>`。
+如果你在用[谷歌容器仓库](https://cloud.google.com/tools/container-registry/)，
+用你的项目 ID 作为标签打到你的应用镜像上，然后推送到 GCR。
+用你的项目 ID 替换 `<project>`。
```shell
docker tag job-wq-1 gcr.io/<project>/job-wq-1
@@ -361,7 +355,6 @@ gcloud docker -- push gcr.io/<project>/job-wq-1
Here is a job definition. You'll need to make a copy of the Job and edit the
image to match the name you used, and call it `./job.yaml`.
-->
-
## 定义 Job
这里给出一个 Job 定义 yaml文件。你需要拷贝一份并编辑镜像以匹配你使用的名称，保存为 `./job.yaml`。
@@ -377,7 +370,6 @@ done. So we set, `.spec.completions: 8` for the example, since we put 8 items i
So, now run the Job:
-->
-
本例中，每个 Pod 使用队列中的一个消息然后退出。这样，Job 的完成计数就代表了完成的工作项的数量。本例中我们设置 `.spec.completions: 8`，因为我们放了8项内容在队列中。
## 运行 Job
@@ -395,7 +387,10 @@ Now wait a bit, then check on the job.
稍等片刻，然后检查 Job。
```shell
-$ kubectl describe jobs/job-wq-1
+kubectl describe jobs/job-wq-1
+```
+
+```
Name: job-wq-1
Namespace: default
Selector: controller-uid=41d75705-92df-11e7-b85e-fa163ee3c11f
@@ -434,11 +429,8 @@ Events:
<!--
All our pods succeeded. Yay.
-->
-
我们所有的 Pod 都成功了。耶！
-
-
<!-- discussion -->
<!--
@@ -451,12 +443,12 @@ It does require that you run a message queue service.
If running a queue service is inconvenient, you may
want to consider one of the other [job patterns](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns).
-->
-
## 替代方案
本文所讲述的处理方法的好处是你不需要修改你的 "worker" 程序使其知道工作队列的存在。
- 本文所描述的方法需要你运行一个消息队列服务。如果不方便运行消息队列服务，你也许会考虑另外一种[任务模式](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns)。
+本文所描述的方法需要你运行一个消息队列服务。如果不方便运行消息队列服务，你也许会考虑另外一种
+[任务模式](/zh/docs/concepts/workloads/controllers/job/#job-patterns)。
<!--
This approach creates a pod for every work item. If your work items only take a few seconds,
@@ -470,9 +462,15 @@ A [different example](/docs/tasks/job/fine-parallel-processing-work-queue/), sho
communicate with the work queue using a client library.
-->
-本文所述的方法为每个工作项创建了一个 Pod。如果你的工作项仅需数秒钟，为每个工作项创建 Pod会增加很多的常规消耗。可以考虑另外的方案请参考[示例](/docs/tasks/job/fine-parallel-processing-work-queue/)，这种方案可以实现每个 Pod 执行多个工作项。
+本文所述的方法为每个工作项创建了一个 Pod。
+如果你的工作项仅需数秒钟，为每个工作项创建 Pod会增加很多的常规消耗。
+可以考虑另外的方案请参考[示例](/zh/docs/tasks/job/fine-parallel-processing-work-queue/)，
+这种方案可以实现每个 Pod 执行多个工作项。
-示例中，我们使用 `amqp-consume` 从消息队列读取消息并执行我们真正的程序。这样的好处是你不需要修改你的程序使其知道队列的存在。要了解怎样使用客户端库和工作队列通信，请参考[不同的示例](/docs/tasks/job/fine-parallel-processing-work-queue/)。
+示例中，我们使用 `amqp-consume` 从消息队列读取消息并执行我们真正的程序。
+这样的好处是你不需要修改你的程序使其知道队列的存在。
+要了解怎样使用客户端库和工作队列通信，请参考
+[不同的示例](/zh/docs/tasks/job/fine-parallel-processing-work-queue/)。
<!--
## Caveats
@@ -491,15 +489,14 @@ exits with success, or if the node crashes before the kubelet is able to post th
back to the api-server, then the Job will not appear to be complete, even though all items
in the queue have been processed.
-->
-
## 友情提醒
如果设置的完成数量小于队列中的消息数量，会导致一部分消息项不会被执行。
-如果设置的完成数量大于队列中的消息数量，当队列中所有的消息都处理完成后，Job 也会显示为未完成。Job 将创建 Pod 并阻塞等待消息输入。
+如果设置的完成数量大于队列中的消息数量，当队列中所有的消息都处理完成后，
+Job 也会显示为未完成。Job 将创建 Pod 并阻塞等待消息输入。
当发生下面两种情况时，即使队列中所有的消息都处理完了，Job 也不会显示为完成状态：
* 在 amqp-consume 命令拿到消息和容器成功退出之间的时间段内，执行杀死容器操作；
* 在 kubelet 向 api-server 传回 Pod 成功运行之前，发生节点崩溃。
-
diff --git a/content/zh/docs/tasks/job/fine-parallel-processing-work-queue.md b/content/zh/docs/tasks/job/fine-parallel-processing-work-queue.md
old mode 100755
new mode 100644
index 45951f4706..bd6688374b
--- a/content/zh/docs/tasks/job/fine-parallel-processing-work-queue.md
+++ b/content/zh/docs/tasks/job/fine-parallel-processing-work-queue.md
@@ -1,16 +1,14 @@
---
-cn-approvers:
-- linyouchong
title: 使用工作队列进行精细的并行处理
content_type: task
+min-kubernetes-server-version: v1.8
weight: 40
---
<!--
----
title: Fine Parallel Processing Using a Work Queue
content_type: task
weight: 40
----
+min-kubernetes-server-version: v1.8
-->
<!-- overview -->
@@ -24,14 +22,12 @@ worker processes in a given pod.
<!--
In this example, as each pod is created, it picks up one unit of work
from a task queue, processes it, and repeats until the end of the queue is reached.
+
+Here is an overview of the steps in this example:
-->
在这个例子中，当每个pod被创建时，它会从一个任务队列中获取一个工作单元，处理它，然后重复，直到到达队列的尾部。
-
-<!--
-Here is an overview of the steps in this example:
--->
-下面是这个示例的步骤概述
+下面是这个示例的步骤概述：
<!--
1. **Start a storage service to hold the work queue.** In this example, we use Redis to store
@@ -41,77 +37,55 @@ Here is an overview of the steps in this example:
as Redis once and reuse it for the work queues of many jobs, and other things.
-->
-1. **启动存储服务用于保存工作队列。** 在这个例子中，我们使用 Redis 来存储工作项。在上一个例子中，我们使用了 RabbitMQ。在这个例子中，由于 AMQP 不能为客户端提供一个良好的方法来检测一个有限长度的工作队列是否为空，我们使用了 Redis 和一个自定义的工作队列客户端库。在实践中，您可能会设置一个类似于 Redis 的存储库，并将其同时用于多项任务或其他事务的工作队列。
+1. **启动存储服务用于保存工作队列。** 在这个例子中，我们使用 Redis 来存储工作项。
+ 在上一个例子中，我们使用了 RabbitMQ。
+ 在这个例子中，由于 AMQP 不能为客户端提供一个良好的方法来检测一个有限长度的工作队列是否为空，
+ 我们使用了 Redis 和一个自定义的工作队列客户端库。
+ 在实践中，你可能会设置一个类似于 Redis 的存储库，并将其同时用于多项任务或其他事务的工作队列。
<!--
1. **Create a queue, and fill it with messages.** Each message represents one task to be done. In
this example, a message is just an integer that we will do a lengthy computation on.
-->
-
-2. **创建一个队列，然后向其中填充消息。** 每个消息表示一个将要被处理的工作任务。在这个例子中，消息只是一个我们将用于进行长度计算的整数。
+2. **创建一个队列，然后向其中填充消息。** 每个消息表示一个将要被处理的工作任务。
+ 在这个例子中，消息只是一个我们将用于进行长度计算的整数。
<!--
1. **Start a Job that works on tasks from the queue**. The Job starts several pods. Each pod takes
one task from the message queue, processes it, and repeats until the end of the queue is reached.
-->
-
-3. **启动一个 Job 对队列中的任务进行处理**。这个 Job 启动了若干个 Pod 。每个 Pod 从消息队列中取出一个工作任务，处理它，然后重复，直到到达队列的尾部。
-
-
-
-{{< toc >}}
+3. **启动一个 Job 对队列中的任务进行处理**。这个 Job 启动了若干个 Pod 。
+ 每个 Pod 从消息队列中取出一个工作任务，处理它，然后重复，直到到达队列的尾部。
## {{% heading "prerequisites" %}}
-
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
-<!-- steps -->
-
<!--
Be familiar with the basic,
-non-parallel, use of [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/).
+non-parallel, use of [Job](/docs/concepts/workloads/controllers/job/).
-->
-熟秋基础知识，非并行方式运行 [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/)。
-
-
+熟悉基本的、非并行的 [Job](/zh/docs/concepts/workloads/controllers/job/)。
<!-- steps -->
<!--
## Starting Redis
--->
-## 启动 Redis
-<!--
For this example, for simplicity, we will start a single instance of Redis.
See the [Redis Example](https://github.com/kubernetes/examples/tree/master/guestbook) for an example
of deploying Redis scalably and redundantly.
-->
+## 启动 Redis
+
对于这个例子，为了简单起见，我们将启动一个单实例的 Redis。
-了解如何部署一个可伸缩、高可用的 Redis 例子，请查看 [Redis 样例](https://github.com/kubernetes/examples/tree/master/guestbook)
+了解如何部署一个可伸缩、高可用的 Redis 例子，请查看
+[Redis 示例](https://github.com/kubernetes/examples/tree/master/guestbook)
<!--
-If you are working from the website source tree, you can go to the following
-directory and start a temporary Pod running Redis and a service so we can find it.
+You could also download the following files directly:
-->
-如果您在使用本文档库的源代码目录，您可以进入如下目录，然后启动一个临时的 Pod 用于运行 Redis 和 一个临时的 service 以便我们能够找到这个 Pod
-
-```shell
-$ cd content/en/examples/application/job/redis
-$ kubectl create -f ./redis-pod.yaml
-pod/redis-master created
-$ kubectl create -f ./redis-service.yaml
-service/redis created
-```
-
-<!--
-If you're not working from the source tree, you could also download the following
-files directly:
--->
-如果您没有使用本文档库的源代码目录，您可以直接下载如下文件：
+你可以直接下载如下文件：
- [`redis-pod.yaml`](/examples/application/job/redis/redis-pod.yaml)
- [`redis-service.yaml`](/examples/application/job/redis/redis-service.yaml)
@@ -122,22 +96,22 @@ files directly:
<!--
## Filling the Queue with tasks
+
+Now let's fill the queue with some "tasks". In our example, our tasks are just strings to be
+printed.
+
+Start a temporary interactive pod for running the Redis CLI.
-->
## 使用任务填充队列
-<!--
-Now let's fill the queue with some "tasks". In our example, our tasks are just strings to be
-printed.
--->
现在，让我们往队列里添加一些“任务”。在这个例子中，我们的任务只是一些将被打印出来的字符串。
-<!--
-Start a temporary interactive pod for running the Redis CLI.
--->
启动一个临时的可交互的 pod 用于运行 Redis 命令行界面。
```shell
-$ kubectl run -i --tty temp --image redis --command "/bin/sh"
+kubectl run -i --tty temp --image redis --command "/bin/sh"
+```
+```
Waiting for pod default/redis2-c7h78 to be running, status is Pending, pod ready: false
Hit enter for command prompt
```
@@ -188,29 +162,26 @@ So, the list with key `job2` will be our work queue.
Note: if you do not have Kube DNS setup correctly, you may need to change
the first step of the above block to `redis-cli -h $REDIS_SERVICE_HOST`.
-->
-注意：如果您还没有正确地配置 Kube DNS，您可能需要将上面的第一步改为 `redis-cli -h $REDIS_SERVICE_HOST`。
-
+注意：如果你还没有正确地配置 Kube DNS，你可能需要将上面的第一步改为
+`redis-cli -h $REDIS_SERVICE_HOST`。
<!--
## Create an Image
--->
-创建镜像
-<!--
Now we are ready to create an image that we will run.
--->
-现在我们已经准备好创建一个我们要运行的镜像
-<!--
We will use a python worker program with a redis client to read
the messages from the message queue.
--->
-我们会使用一个带有 redis 客户端的 python 工作程序从消息队列中读出消息。
-<!--
A simple Redis work queue client library is provided,
called rediswq.py ([Download](/examples/application/job/redis/rediswq.py)).
-->
+## 创建镜像
+
+现在我们已经准备好创建一个我们要运行的镜像
+
+我们会使用一个带有 redis 客户端的 python 工作程序从消息队列中读出消息。
+
这里提供了一个简单的 Redis 工作队列客户端库，叫 rediswq.py ([下载](/examples/application/job/redis/rediswq.py))。
<!--
@@ -222,12 +193,12 @@ Job 中每个 Pod 内的 “工作程序” 使用工作队列客户端库获取
{{< codenew language="python" file="application/job/redis/worker.py" >}}
<!--
-If you are working from the source tree,
-change directory to the `content/en/examples/application/job/redis/` directory.
-Otherwise, download [`worker.py`](/examples/application/job/redis/worker.py), [`rediswq.py`](/examples/application/job/redis/rediswq.py), and [`Dockerfile`](/examples/application/job/redis/Dockerfile)
+You could download [`worker.py`](/examples/application/job/redis/worker.py), [`rediswq.py`](/examples/application/job/redis/rediswq.py), and [`Dockerfile`](/examples/application/job/redis/Dockerfile)
using above links. Then build the image:
-->
-如果您在使用本文档库的源代码目录，请将当前目录切换到 `content/en/examples/application/job/redis/`。否则，请点击链接下载 [`worker.py`](/examples/application/job/redis/worker.py)、 [`rediswq.py`](/examples/application/job/redis/rediswq.py) 和 [`Dockerfile`](/examples/application/job/redis/Dockerfile)。然后构建镜像：
+你也可以下载 [`worker.py`](/examples/application/job/redis/worker.py)、
+[`rediswq.py`](/examples/application/job/redis/rediswq.py) 和
+[`Dockerfile`](/examples/application/job/redis/Dockerfile)。然后构建镜像：
```shell
docker build -t job-wq-2 .
@@ -235,15 +206,15 @@ docker build -t job-wq-2 .
<!--
### Push the image
--->
-### Push 镜像
-<!--
For the [Docker Hub](https://hub.docker.com/), tag your app image with
your username and push to the Hub with the below commands. Replace
`<username>` with your Hub username.
-->
-对于 [Docker Hub](https://hub.docker.com/)，请先用您的用户名给镜像打上标签，然后使用下面的命令 push 您的镜像到仓库。请将 `<username>` 替换为您自己的用户名。
+### Push 镜像
+
+对于 [Docker Hub](https://hub.docker.com/)，请先用你的用户名给镜像打上标签，
+然后使用下面的命令 push 你的镜像到仓库。请将 `<username>` 替换为你自己的用户名。
```shell
docker tag job-wq-2 <username>/job-wq-2
@@ -254,7 +225,8 @@ docker push <username>/job-wq-2
You need to push to a public repository or [configure your cluster to be able to access
your private repository](/docs/concepts/containers/images/).
-->
-您需要将镜像 push 到一个公共仓库或者 [配置集群访问您的私有仓库](/docs/concepts/containers/images/)。
+你需要将镜像 push 到一个公共仓库或者
+[配置集群访问你的私有仓库](/zh/docs/concepts/containers/images/)。
<!--
If you are using [Google Container
@@ -262,8 +234,8 @@ Registry](https://cloud.google.com/tools/container-registry/), tag
your app image with your project ID, and push to GCR. Replace
`<project>` with your project ID.
-->
-如果您使用的是 [Google Container
-Registry](https://cloud.google.com/tools/container-registry/)，请先用您的 project ID 给您的镜像打上标签，然后 push 到 GCR 。请将 `<project>` 替换为您自己的 project ID
+如果你使用的是 [Google Container Registry](https://cloud.google.com/tools/container-registry/)，
+请先用你的 project ID 给你的镜像打上标签，然后 push 到 GCR 。请将 `<project>` 替换为你自己的 project ID
```shell
docker tag job-wq-2 gcr.io/<project>/job-wq-2
@@ -272,12 +244,11 @@ gcloud docker -- push gcr.io/<project>/job-wq-2
<!--
## Defining a Job
+
+Here is the job definition:
-->
## 定义一个 Job
-<!--
-Here is the job definition:
--->
这是 job 定义：
{{< codenew file="application/job/redis/job.yaml" >}}
@@ -286,7 +257,7 @@ Here is the job definition:
Be sure to edit the job template to
change `gcr.io/myproject` to your own path.
-->
-请确保将 job 模板中的 `gcr.io/myproject` 更改为您自己的路径。
+请确保将 job 模板中的 `gcr.io/myproject` 更改为你自己的路径。
<!--
In this example, each pod works on several items from the queue and then exits when there are no more items.
@@ -297,21 +268,25 @@ exits with success, the controller knows the work is done, and the Pods will exi
So, we set the completion count of the Job to 1. The job controller will wait for the other pods to complete
too.
-->
-在这个例子中，每个 pod 处理了队列中的多个项目，直到队列中没有项目时便退出。因为是由工作程序自行检测工作队列是否为空，并且 Job 控制器不知道工作队列的存在，所以依赖于工作程序在完成工作时发出信号。工作程序以成功退出的形式发出信号表示工作队列已经为空。所以，只要有任意一个工作程序成功退出，控制器就知道工作已经完成了，所有的 Pod 将很快会退出。因此，我们将 Job 的 completion count 设置为 1 。尽管如此，Job 控制器还是会等待其它 Pod 完成。
-
+在这个例子中，每个 pod 处理了队列中的多个项目，直到队列中没有项目时便退出。
+因为是由工作程序自行检测工作队列是否为空，并且 Job 控制器不知道工作队列的存在，
+所以依赖于工作程序在完成工作时发出信号。
+工作程序以成功退出的形式发出信号表示工作队列已经为空。
+所以，只要有任意一个工作程序成功退出，控制器就知道工作已经完成了，所有的 Pod 将很快会退出。
+因此，我们将 Job 的完成计数（Completion Count）设置为 1 。
+尽管如此，Job 控制器还是会等待其它 Pod 完成。
<!--
## Running the Job
+
+So, now run the Job:
-->
## 运行 Job
-<!--
-So, now run the Job:
--->
现在运行这个 Job ：
```shell
-kubectl create -f ./job.yaml
+kubectl apply -f ./job.yaml
```
<!--
@@ -320,7 +295,10 @@ Now wait a bit, then check on the job.
稍等片刻，然后检查这个 Job。
```shell
-$ kubectl describe jobs/job-wq-2
+kubectl describe jobs/job-wq-2
+```
+
+```
Name: job-wq-2
Namespace: default
Selector: controller-uid=b1c7e4e3-92e1-11e7-b85e-fa163ee3c11f
@@ -345,9 +323,15 @@ Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
33s 33s 1 {job-controller } Normal SuccessfulCreate Created pod: job-wq-2-lglf8
+```
+查看日志：
-$ kubectl logs pods/job-wq-2-7r7b2
+```shell
+kubectl logs pods/job-wq-2-7r7b2
+```
+
+```
Worker with sessionID: bbd72d0a-9e5c-4dd6-abf6-416cc267991f
Initial queue state: empty=False
Working on banana
@@ -358,22 +342,21 @@ Working on lemon
<!--
As you can see, one of our pods worked on several work units.
-->
-您可以看到，其中的一个 pod 处理了若干个工作单元。
-
-
+你可以看到，其中的一个 pod 处理了若干个工作单元。
<!-- discussion -->
<!--
## Alternatives
-->
-## 其它
+## 替代方案
<!--
If running a queue service or modifying your containers to use a work queue is inconvenient, you may
want to consider one of the other [job patterns](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns).
-->
-如果您不方便运行一个队列服务或者修改您的容器用于运行一个工作队列，您可以考虑其它的 [job 模式](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns)。
+如果你不方便运行一个队列服务或者修改你的容器用于运行一个工作队列，你可以考虑其它的
+[Job 模式](/zh/docs/concepts/workloads/controllers/job/#job-patterns)。
<!--
If you have a continuous stream of background processing work to run, then
@@ -381,6 +364,7 @@ consider running your background workers with a `replicationController` instead,
and consider running a background processing library such as
[https://github.com/resque/resque](https://github.com/resque/resque).
-->
-如果您有连续的后台处理业务，那么可以考虑使用 `replicationController` 来运行您的后台业务，和运行一个类似 [https://github.com/resque/resque](https://github.com/resque/resque) 的后台处理库。
-
+如果你有连续的后台处理业务，那么可以考虑使用 `replicationController` 来运行你的后台业务，
+和运行一个类似 [https://github.com/resque/resque](https://github.com/resque/resque)
+的后台处理库。
diff --git a/content/zh/docs/tasks/manage-daemon/rollback-daemon-set.md b/content/zh/docs/tasks/manage-daemon/rollback-daemon-set.md
index 780a16f95e..b3efaa83d1 100644
--- a/content/zh/docs/tasks/manage-daemon/rollback-daemon-set.md
+++ b/content/zh/docs/tasks/manage-daemon/rollback-daemon-set.md
@@ -3,29 +3,48 @@ approvers:
- janetkuo
title: 对 DaemonSet 执行回滚
content_type: task
+weight: 20
+min-kubernetes-server-version: 1.7
---
+<!--
+reviewers:
+- janetkuo
+title: Perform a Rollback on a DaemonSet
+content_type: task
+weight: 20
+min-kubernetes-server-version: 1.7
+-->
<!-- overview -->
-
-本文展示了如何对 DaemonSet 执行回滚。
-
-
-
+<!--
+This page shows how to perform a rollback on a {{< glossary_tooltip term_id="daemonset" >}}.
+-->
+本文展示了如何对 {{< glossary_tooltip term_id="daemonset" text="DaemonSet" >}} 执行回滚。
## {{% heading "prerequisites" %}}
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-* DaemonSet 滚动升级历史和 DaemonSet 回滚特性仅在 Kubernetes 1.7 及以后版本的 `kubectl` 中支持。
-* 确保您了解如何 [对 DaemonSet 执行滚动升级](/docs/tasks/manage-daemon/update-daemon-set/)。
-
-
-
+<!--
+You should already know how to [perform a rolling update on a
+ DaemonSet](/docs/tasks/manage-daemon/update-daemon-set/).
+-->
+你应该已经了解如何[为 DaemonSet 执行滚东更新](/zh/docs/tasks/manage-daemon/update-daemon-set/)。
<!-- steps -->
+<!--
+## Performing a rollback on a DaemonSet
+
+### Step 1: Find the DaemonSet revision you want to roll back to
+
+You can skip this step if you just want to roll back to the last revision.
+
+List all revisions of a DaemonSet:
+-->
## 对 DaemonSet 执行回滚
-### 步骤 1： 找到想要 DaemonSet 回滚到的历史版本（revision）
+### 步骤 1：找到想要 DaemonSet 回滚到的历史修订版本（revision）
如果只想回滚到最后一个版本，可以跳过这一步。
@@ -35,7 +54,10 @@ content_type: task
kubectl rollout history daemonset <daemonset-name>
```
-该命令返回 DaemonSet 版本列表：
+<!--
+This returns a list of DaemonSet revisions:
+-->
+此命令返回 DaemonSet 版本列表：
```shell
daemonsets "<daemonset-name>"
@@ -45,7 +67,16 @@ REVISION CHANGE-CAUSE
...
```
-* 在创建时，DaemonSet 的变化原因从 `kubernetes.io/change-cause` 注解（annotation）复制到其版本中。 用户可以在 `kubectl` 中指定 `--record=true` ，将执行的命令记录在变化原因注解中。
+<!--
+* Change cause is copied from DaemonSet annotation `kubernetes.io/change-cause`
+ to its revisions upon creation. You may specify `-record=true` in `kubectl`
+ to record the command executed in the change cause annotation.
+
+To see the details of a specific revision:
+-->
+* 在创建时，DaemonSet 的变化原因从 `kubernetes.io/change-cause` 注解（annotation）
+ 复制到其修订版本中。用户可以在 `kubectl` 命令中设置 `--record=true`，
+ 将执行的命令记录在变化原因注解中。
执行以下命令，来查看指定版本的详细信息：
@@ -53,7 +84,10 @@ REVISION CHANGE-CAUSE
kubectl rollout history daemonset <daemonset-name> --revision=1
```
-该命令返回相应版本的详细信息：
+<!--
+This returns the details of that revision:
+-->
+该命令返回相应修订版本的详细信息：
```shell
daemonsets "<daemonset-name>" with revision #1
@@ -68,73 +102,137 @@ app:
Volumes: ...
```
-### 步骤 2： 回滚到指定版本
+<!--
+### Step 2: Roll back to a specific revision
+-->
+### 步骤 2：回滚到指定版本
```shell
-# 在 --to-revision 中指定您从步骤 1 中获取的版本序号
+# 在 --to-revision 中指定你从步骤 1 中获取的修订版本
kubectl rollout undo daemonset <daemonset-name> --to-revision=<revision>
```
+<!--
+If it succeeds, the command returns:
+-->
如果成功，命令会返回：
```shell
daemonset "<daemonset-name>" rolled back
```
+<!--
+If `--to-revision` flag is not specified, kubectl picks the most recent revision.
+-->
+{{< note >}}
如果 `--to-revision` 参数未指定，将选中最近的版本。
+{{< /note >}}
-### 步骤 3： 观察 DaemonSet 回滚进度
+<!--
+### Step 3: Watch the progress of the DaemonSet rollback
-`kubectl rollout undo daemonset` 向服务器表明启动 DaemonSet 回滚。 真正的回滚是在服务器端异步完成的。
+`kubectl rollout undo daemonset` tells the server to start rolling back the
+DaemonSet. The real rollback is done asynchronously inside the cluster
+{{< glossary_tooltip term_id="control-plane" text="control plane" >}}.
+-->
+### 步骤 3：监视 DaemonSet 回滚进度
-执行以下命令，来观察 DaemonSet 回滚进度：
+`kubectl rollout undo daemonset` 向服务器表明启动 DaemonSet 回滚。
+真正的回滚是在集群的
+{{< glossary_tooltip term_id="control-plane" text="控制面" >}}
+异步完成的。
+
+<!--
+To watch the progress of the rollback:
+-->
+执行以下命令，来监视 DaemonSet 回滚进度：
```shell
kubectl rollout status ds/<daemonset-name>
```
+<!--
+When the rollback is complete, the output is similar to:
+-->
回滚完成时，输出形如：
-```shell
+```
daemonset "<daemonset-name>" successfully rolled out
```
-
-
-
<!-- discussion -->
-## 理解 DaemonSet 版本
+<!--
+## Understanding DaemonSet revisions
-在前面的 `kubectl rollout history` 步骤中，您获得了一个版本列表，每个版本都存储在名为
- `ControllerRevision` 的资源中。 `ControllerRevision` 仅在 Kubernetes 1.7 及以后的版本中可用。
+In the previous `kubectl rollout history` step, you got a list of DaemonSet
+revisions. Each revision is stored in a resource named ControllerRevision.
-查找原始的版本资源，来查看每个版本中存储了什么内容：
+To see what is stored in each revision, find the DaemonSet revision raw
+resources:
+-->
+## 理解 DaemonSet 修订版本
+
+在前面的 `kubectl rollout history` 步骤中，你获得了一个修订版本列表，每个修订版本都存储在名为
+ `ControllerRevision` 的资源中。
+
+要查看每个修订版本中保存的内容，可以找到 DaemonSet 修订版本的原生资源：
```shell
kubectl get controllerrevision -l <daemonset-selector-key>=<daemonset-selector-value>
```
+<!--
+This returns a list of ControllerRevisions:
+-->
该命令返回 `ControllerRevisions` 列表：
-```shell
+```
NAME CONTROLLER REVISION AGE
<daemonset-name>-<revision-hash> DaemonSet/<daemonset-name> 1 1h
<daemonset-name>-<revision-hash> DaemonSet/<daemonset-name> 2 1h
```
+<!--
+Each ControllerRevision stores the annotations and template of a DaemonSet
+revision.
+-->
每个 `ControllerRevision` 中存储了相应 DaemonSet 版本的注解和模板。
-`kubectl rollout undo` 采用特定 `ControllerRevision` ，并用
+<!--
+`kubectl rollout undo` takes a specific ControllerRevision and replaces
+DaemonSet template with the template stored in the ControllerRevision.
+`kubectl rollout undo` is equivalent to updating DaemonSet template to a
+previous revision through other commands, such as `kubectl edit` or `kubectl
+apply`.
+-->
+`kubectl rollout undo` 选择特定的 `ControllerRevision`，并用
`ControllerRevision` 中存储的模板代替 DaemonSet 的模板。
-`kubectl rollout undo` 相当于通过其他命令（如 `kubectl edit` 或 `kubectl apply`）将 DaemonSet 模板更新至先前的版本。
+`kubectl rollout undo` 相当于通过其他命令（如 `kubectl edit` 或 `kubectl apply`）
+将 DaemonSet 模板更新至先前的版本。
-注意 DaemonSet 版本只会向前滚动。 也就是说，回滚完成后，所回滚到的 `ControllerRevision` 版本号 (`.revision` 字段) 会增加。 例如，如果用户在系统中有版本 1 和版本 2，并从版本 2 回滚到版本 1 ，带有 `.revision: 1` 的`ControllerRevision` 将变为 `.revision: 3`。
-
-## 故障排除
-
-* 查看 [DaemonSet 滚动升级故障排除](/docs/tasks/manage-daemon/update-daemon-set/#troubleshooting)。
+<!--
+DaemonSet revisions only roll forward. That is to say, after a
+rollback completes, the revision number (`.revision` field) of the
+ControllerRevision being rolled back to will advance. For example, if you
+have revision 1 and 2 in the system, and roll back from revision 2 to revision
+1, the ControllerRevision with `.revision: 1` will become `.revision: 3`.
+-->
+{{< note >}}
+注意 DaemonSet 修订版本只会正向变化。也就是说，回滚完成后，所回滚到的
+`ControllerRevision` 版本号 (`.revision` 字段) 会增加。
+例如，如果用户在系统中有版本 1 和版本 2，并从版本 2 回滚到版本 1，
+带有 `.revision: 1` 的`ControllerRevision` 将变为 `.revision: 3`。
+{{< /note >}}
+<!--
+## Troubleshooting
+* See [troubleshooting DaemonSet rolling
+ update](/docs/tasks/manage-daemon/update-daemon-set/#troubleshooting).
+-->
+## 故障排查
+
+* 参阅 [DaemonSet 滚动升级故障排除](/zh/docs/tasks/manage-daemon/update-daemon-set/#troubleshooting)。
diff --git a/content/zh/docs/tasks/manage-daemon/update-daemon-set.md b/content/zh/docs/tasks/manage-daemon/update-daemon-set.md
index 7ad4b7259d..a501558cda 100644
--- a/content/zh/docs/tasks/manage-daemon/update-daemon-set.md
+++ b/content/zh/docs/tasks/manage-daemon/update-daemon-set.md
@@ -1,50 +1,38 @@
---
-reviewers:
-- janetkuo
title: 对 DaemonSet 执行滚动更新
content_type: task
+weight: 10
---
<!--
----
reviewers:
- janetkuo
title: Perform a Rolling Update on a DaemonSet
content_type: task
----
---->
+-->
<!-- overview -->
-
<!--
This page shows how to perform a rolling update on a DaemonSet.
---->
+-->
本文介绍了如何对 DaemonSet 执行滚动更新。
-
-
-
## {{% heading "prerequisites" %}}
-
<!--
* The DaemonSet rolling update feature is only supported in Kubernetes version 1.6 or later.
---->
+-->
* Kubernetes 1.6 或者更高版本中才支持 DaemonSet 滚动更新功能。
-
-
-
<!-- steps -->
<!--
## DaemonSet Update Strategy
---->
+
+DaemonSet has two update strategy types:
+-->
## DaemonSet 更新策略
-<!--
-DaemonSet has two update strategy types:
---->
DaemonSet 有两种更新策略：
<!--
@@ -56,282 +44,283 @@ DaemonSet 有两种更新策略：
With `RollingUpdate` update strategy, after you update a
DaemonSet template, old DaemonSet pods will be killed, and new DaemonSet pods
will be created automatically, in a controlled fashion.
---->
+ At most one pod of the DaemonSet will be running on each node during the whole update process.
+-->
-* OnDelete: 使用 `OnDelete` 更新策略时，在更新 DaemonSet 模板后，只有当您手动删除老的 DaemonSet pods 之后，新的 DaemonSet pods *才会*被自动创建。跟 Kubernetes 1.6 以前的版本类似。
-* RollingUpdate: 这是默认的更新策略。使用 `RollingUpdate` 更新策略时，在更新 DaemonSet 模板后，老的 DaemonSet pods 将被终止，并且将以受控方式自动创建新的 DaemonSet pods。
+* OnDelete: 使用 `OnDelete` 更新策略时，在更新 DaemonSet 模板后，只有当你手动删除老的
+ DaemonSet pods 之后，新的 DaemonSet Pod *才会*被自动创建。跟 Kubernetes 1.6 以前的版本类似。
+* RollingUpdate: 这是默认的更新策略。使用 `RollingUpdate` 更新策略时，在更新 DaemonSet 模板后，
+ 老的 DaemonSet pods 将被终止，并且将以受控方式自动创建新的 DaemonSet pods。
+ 更新期间，最多只能有 DaemonSet 的一个 Pod 运行于每个节点上。
<!--
## Performing a Rolling Update
---->
-## 执行滚动更新
-<!--
To enable the rolling update feature of a DaemonSet, you must set its
`.spec.updateStrategy.type` to `RollingUpdate`.
---->
+-->
+## 执行滚动更新
+
要启用 DaemonSet 的滚动更新功能，必须设置 `.spec.updateStrategy.type` 为 `RollingUpdate`。
<!--
You may want to set [`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/docs/concepts/workloads/controllers/deployment/#max-unavailable) (default
to 1) and [`.spec.minReadySeconds`](/docs/concepts/workloads/controllers/deployment/#min-ready-seconds) (default to 0) as well.
---->
-您可能想设置[`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/docs/concepts/workloads/controllers/deployment/#max-unavailable) (默认为 1) 和[`.spec.minReadySeconds`](/docs/concepts/workloads/controllers/deployment/#min-ready-seconds) (默认为 0)。
+-->
+你可能想设置
+[`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/zh/docs/concepts/workloads/controllers/deployment/#max-unavailable) (默认为 1) 和
+[`.spec.minReadySeconds`](/zh/docs/concepts/workloads/controllers/deployment/#min-ready-seconds) (默认为 0)。
<!--
-### Step 1: Checking DaemonSet `RollingUpdate` update strategy
---->
-### 步骤 1: 检查 DaemonSet 的滚动更新策略
+### Creating a DaemonSet with `RollingUpdate` update strategy
+
+This YAML file specifies a DaemonSet with an update strategy as 'RollingUpdate'
+-->
+### 创建带有 `RollingUpdate` 更新策略的 DaemonSet
+
+下面的 YAML 包含一个 DaemonSet，其更新策略为 'RollingUpdate'：
+
+{{< codenew file="controllers/fluentd-daemonset.yaml" >}}
<!--
-First, check the update strategy of your DaemonSet, and make sure it's set to
+After verifying the update strategy of the DaemonSet manifest, create the DaemonSet:
+-->
+检查了 DaemonSet 清单中更新策略的设置之后，创建 DaemonSet：
+
+```shell
+kubectl create -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml
+```
+
+<!--
+Alternatively, use `kubectl apply` to create the same DaemonSet if you plan to
+update the DaemonSet with `kubectl apply`.
+-->
+另一种方式是如果你希望使用 `kubectl apply` 来更新 DaemonSet 的话，也可以
+使用 `kubectl apply` 来创建 DaemonSet：
+
+```shell
+kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml
+```
+
+<!--
+### Checking DaemonSet `RollingUpdate` update strategy
+
+Check the update strategy of your DaemonSet, and make sure it's set to
`RollingUpdate`:
---->
+-->
+### 检查 DaemonSet 的滚动更新策略
+
首先，检查 DaemonSet 的更新策略，确保已经将其设置为 `RollingUpdate`:
```shell
-kubectl get ds/<daemonset-name> -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}'
+kubectl get ds/fluentd-elasticsearch -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}' -n kube-system
```
<!--
If you haven't created the DaemonSet in the system, check your DaemonSet
manifest with the following command instead:
---->
+-->
如果还没在系统中创建 DaemonSet，请使用以下命令检查 DaemonSet 的清单：
```shell
-kubectl create -f ds.yaml --dry-run -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}'
+kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml --dry-run=client -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}'
```
+
<!--
The output from both commands should be:
---->
+-->
两个命令的输出都应该为：
-```shell
+```
RollingUpdate
```
<!--
If the output isn't `RollingUpdate`, go back and modify the DaemonSet object or
manifest accordingly.
---->
+-->
如果输出不是 `RollingUpdate`，请返回并相应地修改 DaemonSet 对象或者清单。
<!--
-### Step 2: Creating a DaemonSet with `RollingUpdate` update strategy
---->
-### 步骤 2：使用 `RollingUpdate` 更新策略创建 DaemonSet
+### Updating a DaemonSet template
-<!--
-If you have already created the DaemonSet, you may skip this step and jump to
-step 3.
---->
-如果已经创建了 DaemonSet，则可以跳过该步骤并跳转到步骤 3。
-
-<!--
-After verifying the update strategy of the DaemonSet manifest, create the DaemonSet:
---->
-验证 DaemonSet 清单的更新策略后，创建 DaemonSet：
-
-```shell
-kubectl create -f ds.yaml
-```
-
-<!--
-Alternatively, use `kubectl apply` to create the same DaemonSet if you plan to
-update the DaemonSet with `kubectl apply`.
---->
-或者，您打算使用 `kubectl apply` 更新 DaemonSet，请使用 `kubectl apply` 创建相同的 DaemonSet。
-
-```shell
-kubectl apply -f ds.yaml
-```
-
-<!--
-### Step 3: Updating a DaemonSet template
---->
-### 步骤 3：更新 DaemonSet 模板
-
-<!--
Any updates to a `RollingUpdate` DaemonSet `.spec.template` will trigger a rolling
-update. This can be done with several different `kubectl` commands.
---->
-对 `RollingUpdate` DaemonSet `.spec.template` 的任何更新都将触发滚动更新。这可以通过几个不同的 `kubectl` 命令来完成。
+update. Let's update the DaemonSet by applying a new YAML file. This can be done with several different `kubectl` commands.
+-->
+### 更新 DaemonSet 模板
+
+对 `RollingUpdate` DaemonSet 的 `.spec.template` 的任何更新都将触发滚动更新。
+这可以通过几个不同的 `kubectl` 命令来完成。
+
+{{< codenew file="controllers/fluentd-daemonset-update.yaml" >}}
<!--
#### Declarative commands
---->
+
+If you update DaemonSets using
+[configuration files](/docs/tasks/manage-kubernetes-objects/declarative-config/),
+use `kubectl apply`:
+-->
#### 声明式命令
-<!--
-If you update DaemonSets using
-[configuration files](/docs/concepts/overview/object-management-kubectl/declarative-config/),
-use `kubectl apply`:
---->
-如果您使用[配置文件](/docs/concepts/overview/object-management-kubectl/declarative-config/)来更新 DaemonSets，请使用 `kubectl apply`:
+如果你使用
+[配置文件](/zh/docs/tasks/manage-kubernetes-objects/declarative-config/)
+来更新 DaemonSet，请使用 `kubectl apply`:
```shell
-kubectl apply -f ds-v2.yaml
+kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset-update.yaml
```
<!--
#### Imperative commands
---->
-#### 命令式命令
-<!--
If you update DaemonSets using
[imperative commands](/docs/concepts/overview/object-management-kubectl/imperative-command/),
-use `kubectl edit` or `kubectl patch`:
---->
-如果您使用[命令式命令](/docs/concepts/overview/object-management-kubectl/imperative-command/)来更新 DaemonSets，请使用`kubectl edit` 或者 `kubectl patch`:
+use `kubectl edit`:
+-->
+#### 指令式命令
+
+如果你使用
+[指令式命令](/zh/docs/tasks/manage-kubernetes-objects/imperative-command/)
+来更新 DaemonSets，请使用`kubectl edit`：
```shell
-kubectl edit ds/<daemonset-name>
-```
-
-```shell
-kubectl patch ds/<daemonset-name> -p=<strategic-merge-patch>
+kubectl edit ds/fluentd-elasticsearch -n kube-system
```
<!--
##### Updating only the container image
---->
-##### 只更新容器镜像
-<!--
If you just need to update the container image in the DaemonSet template, i.e.
`.spec.template.spec.containers[*].image`, use `kubectl set image`:
--->
-如果您只需要更新 DaemonSet 模板里的容器镜像，比如，`.spec.template.spec.containers[*].image`, 请使用 `kubectl set image`:
+##### 只更新容器镜像
+
+如果你只需要更新 DaemonSet 模板里的容器镜像，比如，`.spec.template.spec.containers[*].image`,
+请使用 `kubectl set image`:
```shell
-kubectl set image ds/<daemonset-name> <container-name>=<container-new-image>
+kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=quay.io/fluentd_elasticsearch/fluentd:v2.6.0 -n kube-system
```
<!--
### Step 4: Watching the rolling update status
---->
-### 步骤 4：查看滚动更新状态
-<!--
Finally, watch the rollout status of the latest DaemonSet rolling update:
---->
+-->
+### 监视滚动更新状态
+
最后，观察 DaemonSet 最新滚动更新的进度：
```shell
-kubectl rollout status ds/<daemonset-name>
+kubectl rollout status ds/fluentd-elasticsearch -n kube-system
```
<!--
When the rollout is complete, the output is similar to this:
---->
+-->
当滚动更新完成时，输出结果如下：
-```shell
-daemonset "<daemonset-name>" successfully rolled out
+```
+daemonset "fluentd-elasticsearch" successfully rolled out
```
<!--
## Troubleshooting
---->
+
+### DaemonSet rolling update is stuck
+-->
## 故障排查
-<!--
-### DaemonSet rolling update is stuck
---->
### DaemonSet 滚动更新卡住
-<!--
-Sometimes, a DaemonSet rolling update may be stuck. Here are some possible
-causes:
---->
-有时，DaemonSet 滚动更新可能会卡住。可能原因如下：
-
-<!--
-#### Some nodes run out of resources
---->
-#### 一些节点资源用尽
-
<!--
The rollout is stuck because new DaemonSet pods can't be scheduled on at least one
node. This is possible when the node is
[running out of resources](/docs/tasks/administer-cluster/out-of-resource/).
---->
-由于新 DaemonSet pods 无法调度到至少一个节点时，滚动更新就会卡住。这可能是由于节点已经[资源用尽](/docs/tasks/administer-cluster/out-of-resource/)。
-<!--
When this happens, find the nodes that don't have the DaemonSet pods scheduled on
by comparing the output of `kubectl get nodes` and the output of:
---->
-发生这种情况时，通过对 `kubectl get nodes` 和下面命令行的输出作比较，找出没有调度部署 DaemonSet pods 的节点：
+-->
+有时，DaemonSet 滚动更新可能会卡住，其 Pod 至少在某个节点上无法调度运行。
+当节点上[可用资源耗尽](/zh/docs/tasks/administer-cluster/out-of-resource/)时，
+这是可能的。
+
+发生这种情况时，通过对 `kubectl get nodes` 和下面命令行的输出作比较，
+找出没有调度部署 DaemonSet Pods 的节点：
```shell
-kubectl get pods -l <daemonset-selector-key>=<daemonset-selector-value> -o wide
+kubectl get pods -l name=fluentd-elasticsearch -o wide -n kube-system
```
<!--
Once you've found those nodes, delete some non-DaemonSet pods from the node to
make room for new DaemonSet pods.
---->
-一旦找到这些节点，从节点上删除一些非 DaemonSet pods，为新的 DaemonSet pods 腾出空间。
+-->
+一旦找到这些节点，从节点上删除一些非 DaemonSet Pod，为新的 DaemonSet Pod 腾出空间。
<!--
-{{< note >}}
This will cause service disruption when deleted pods are not controlled by any controllers or pods are not
replicated. This does not respect [PodDisruptionBudget](/docs/tasks/configure-pod-container/configure-pod-disruption-budget/)
either.
-{{< /note >}}
---->
+-->
{{< note >}}
-当所删除的 pods 不受任何控制器管理，也不是多副本的 pods，上述操作将导致服务中断。
-同时，上述操作也不会考虑 [PodDisruptionBudget](/docs/tasks/configure-pod-container/configure-pod-disruption-budget/) 所施加的约束。
+当所删除的 Pod 不受任何控制器管理，也不是多副本的 Pod时，上述操作将导致服务中断。
+同时，上述操作也不会考虑
+[PodDisruptionBudget](/zh/docs/tasks/configure-pod-container/configure-pod-disruption-budget/)
+所施加的约束。
{{< /note >}}
<!--
#### Broken rollout
---->
-#### 滚动更新中断
-
-
-<!--
If the recent DaemonSet template update is broken, for example, the container is
crash looping, or the container image doesn't exist (often due to a typo),
DaemonSet rollout won't progress.
---->
-如果最近的 DaemonSet 模板更新被破坏了，比如，容器处于崩溃循环状态或者容器镜像不存在(通常由于拼写错误)，就会发生 DaemonSet 滚动更新中断。
+-->
+#### 不完整的滚动更新
+
+如果最近的 DaemonSet 模板更新被破坏了，比如，容器处于崩溃循环状态或者容器镜像不存在
+（通常由于拼写错误），就会发生 DaemonSet 滚动更新中断。
<!--
To fix this, just update the DaemonSet template again. New rollout won't be
blocked by previous unhealthy rollouts.
---->
+-->
要解决此问题，只需再次更新 DaemonSet 模板即可。以前不健康的滚动更新不会阻止新的滚动更新。
<!--
#### Clock skew
---->
-#### 时钟偏差
-<!--
If `.spec.minReadySeconds` is specified in the DaemonSet, clock skew between
master and nodes will make DaemonSet unable to detect the right rollout
progress.
---->
-如果在 DaemonSet 中指定了 `.spec.minReadySeconds`，主节点和工作节点之间的时钟偏差会使 DaemonSet 无法检测到正确的滚动更新进度。
+-->
+#### 时钟偏差
+如果在 DaemonSet 中指定了 `.spec.minReadySeconds`，主控节点和工作节点之间的时钟偏差会使
+DaemonSet 无法检测到正确的滚动更新进度。
+<!--
+## Clean up
+Delete DaemonSet from a namespace :
+-->
+## 清理
+
+从名字空间中删除 DaemonSet：
+
+```shell
+kubectl delete ds fluentd-elasticsearch -n kube-system
+```
## {{% heading "whatsnext" %}}
-
<!--
* See [Task: Performing a rollback on a
DaemonSet](/docs/tasks/manage-daemon/rollback-daemon-set/)
* See [Concepts: Creating a DaemonSet to adopt existing DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)
---->
-* 查看[任务: 在 DaemonSet 上执行回滚](/docs/tasks/manage-daemon/rollback-daemon-set/)
-* 查看[概念: 创建 DaemonSet 以适应现有的 DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)
-
+-->
+* 查看[任务：在 DaemonSet 上执行回滚](/zh/docs/tasks/manage-daemon/rollback-daemon-set/)
+* 查看[概念：创建 DaemonSet 以收养现有 DaemonSet Pod](/zh/docs/concepts/workloads/controllers/daemonset/)
diff --git a/content/zh/docs/tasks/manage-gpus/scheduling-gpus.md b/content/zh/docs/tasks/manage-gpus/scheduling-gpus.md
index ac4f179771..f2045e78ca 100644
--- a/content/zh/docs/tasks/manage-gpus/scheduling-gpus.md
+++ b/content/zh/docs/tasks/manage-gpus/scheduling-gpus.md
@@ -1,76 +1,69 @@
---
-reviewers:
-- vishh
content_type: concept
title: 调度 GPUs
+description: 配置和调度 GPU 成一类资源以供集群中节点使用
---
<!--
----
reviewers:
- vishh
content_type: concept
title: Schedule GPUs
----
---->
+description: Configure and schedule GPUs for use as a resource by nodes in a cluster.
+-->
<!-- overview -->
+{{< feature-state state="beta" for_k8s_version="v1.10" >}}
+
<!--
-Kubernetes includes **experimental** support for managing AMD and NVIDIA GPUs spread
-across nodes. The support for NVIDIA GPUs was added in v1.6 and has gone through
-multiple backwards incompatible iterations. The support for AMD GPUs was added in
-v1.9 via [device plugin](#deploying-amd-gpu-device-plugin).
+Kubernetes includes **experimental** support for managing AMD and NVIDIA GPUs
+(graphical processing units) across several nodes.
This page describes how users can consume GPUs across different Kubernetes versions
and the current limitations.
---->
-Kubernetes 支持对节点上的 AMD 和 NVIDA GPU 进行管理，目前处于**实验**状态。对 NVIDIA GPU 的支持在 v1.6 中加入，已经经历了多次不向后兼容的迭代。而对 AMD GPU 的支持则在 v1.9 中通过 [设备插件](#deploying-amd-gpu-device-plugin) 加入。
-
-这个页面介绍了用户如何在不同的 Kubernetes 版本中使用 GPU，以及当前存在的一些限制。
-
-
+-->
+Kubernetes 支持对节点上的 AMD 和 NVIDA GPU （图形处理单元）进行管理，目前处于**实验**状态。
+本页介绍用户如何在不同的 Kubernetes 版本中使用 GPU，以及当前存在的一些限制。
<!-- body -->
<!--
-## v1.8 onwards
+## Using device plugins
-**From 1.8 onwards, the recommended way to consume GPUs is to use [device
-plugins](/docs/concepts/cluster-administration/device-plugins).**
+Kubernetes implements {{< glossary_tooltip text="Device Plugins" term_id="device-plugin" >}}
+to let Pods access specialized hardware features such as GPUs.
-To enable GPU support through device plugins before 1.10, the `DevicePlugins`
-feature gate has to be explicitly set to true across the system:
-`--feature-gates="DevicePlugins=true"`. This is no longer required starting
-from 1.10.
---->
-## 从 v1.8 起
+As an administrator, you have to install GPU drivers from the corresponding
+hardware vendor on the nodes and run the corresponding device plugin from the
+GPU vendor:
+-->
+## 使用设备插件 {#using-device-plugins}
-**从 1.8 版本开始，我们推荐通过 [设备插件](/docs/concepts/cluster-administration/device-plugins) 的方式来使用 GPU。**
+Kubernetes 实现了{{< glossary_tooltip text="设备插件（Device Plugins）" term_id="device-plugin" >}}
+以允许 Pod 访问类似 GPU 这类特殊的硬件功能特性。
-在 1.10 版本之前，为了通过设备插件开启 GPU 的支持，我们需要在系统中将 `DevicePlugins` 这一特性开关显式地设置为 true：`--feature-gates="DevicePlugins=true"`。不过，
-从 1.10 版本开始，我们就不需要这一步骤了。
+作为集群管理员，你要在节点上安装来自对应硬件厂商的 GPU 驱动程序，并运行
+来自 GPU 厂商的对应的设备插件。
+
+* [AMD](#deploying-amd-gpu-device-plugin)
+* [NVIDIA](#deploying-nvidia-gpu-device-plugin)
<!--
-Then you have to install GPU drivers from the corresponding vendor on the nodes
-and run the corresponding device plugin from the GPU vendor
-([AMD](#deploying-amd-gpu-device-plugin), [NVIDIA](#deploying-nvidia-gpu-device-plugin)).
+When the above conditions are true, Kubernetes will expose `amd.com/gpu` or
+`nvidia.com/gpu` as a schedulable resource.
-When the above conditions are true, Kubernetes will expose `nvidia.com/gpu` or
-`amd.com/gpu` as a schedulable resource.
---->
-接着你需要在主机节点上安装对应厂商的 GPU 驱动并运行对应厂商的设备插件 ([AMD](#deploying-amd-gpu-device-plugin)、[NVIDIA](#deploying-nvidia-gpu-device-plugin))。
-
-当上面的条件都满足，Kubernetes 将会暴露 `nvidia.com/gpu` 或 `amd.com/gpu` 来作为
-一种可调度的资源。
-
-<!--
You can consume these GPUs from your containers by requesting
`<vendor>.com/gpu` just like you request `cpu` or `memory`.
However, there are some limitations in how you specify the resource requirements
when using GPUs:
---->
-你也能通过像请求 `cpu` 或 `memory` 一样请求 `<vendor>.com/gpu` 来在容器中使用 GPU。然而，当你要通过指定资源请求来使用 GPU 时，存在着以下几点限制：
+-->
+当以上条件满足时，Kubernetes 将暴露 `amd.com/gpu` 或 `nvidia.com/gpu` 为
+可调度的资源。
+
+你可以通过请求 `<vendor>.com/gpu` 资源来使用 GPU 设备，就像你为 CPU
+和内存所做的那样。
+不过，使用 GPU 时，在如何指定资源需求这个方面还是有一些限制的：
<!--
- GPUs are only supposed to be specified in the `limits` section, which means:
@@ -79,21 +72,21 @@ when using GPUs:
* You can specify GPU in both `limits` and `requests` but these two values
must be equal.
* You cannot specify GPU `requests` without specifying `limits`.
-- Containers (and pods) do not share GPUs. There's no overcommitting of GPUs.
+- Containers (and Pods) do not share GPUs. There's no overcommitting of GPUs.
- Each container can request one or more GPUs. It is not possible to request a
fraction of a GPU.
+-->
+- GPUs 只能设置在 `limits` 部分，这意味着：
+ * 你可以指定 GPU 的 `limits` 而不指定其 `requests`，Kubernetes 将使用限制
+ 值作为默认的请求值；
+ * 你可以同时指定 `limits` 和 `requests`，不过这两个值必须相等。
+ * 你不可以仅指定 `requests` 而不指定 `limits`。
+- 容器（以及 Pod）之间是不共享 GPU 的。GPU 也不可以过量分配（Overcommitting）。
+- 每个容器可以请求一个或者多个 GPU，但是用小数值来请求部分 GPU 是不允许的。
+<!--
Here's an example:
---->
-- GPU 仅仅支持在 `limits` 部分被指定，这表明：
- * 你可以仅仅指定 GPU 的 `limits` 字段而不必须指定 `requests` 字段，因为 Kubernetes 会默认使用 limit 字段的值来作为 request 字段的默认值。
- * 你能同时指定 GPU 的 `limits` 和 `requests` 字段，但这两个值必须相等。
- * 你不能仅仅指定 GPU 的 `request` 字段而不指定 `limits`。
-- 容器（以及 pod）并不会共享 GPU，也不存在对 GPU 的过量使用。
-- 每一个容器能够请求一个或多个 GPU。然而只请求一个 GPU 的一部分是不允许的。
-
-下面是一个例子:
-
+-->
```yaml
apiVersion: v1
kind: Pod
@@ -115,8 +108,8 @@ spec:
The [official AMD GPU device plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin)
has the following requirements:
---->
-### 部署 AMD GPU 设备插件
+-->
+### 部署 AMD GPU 设备插件 {#deploying-amd-gpu-device-plugin}
[官方的 AMD GPU 设备插件](https://github.com/RadeonOpenCompute/k8s-device-plugin) 有以下要求：
@@ -132,37 +125,37 @@ kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device
# For Kubernetes v1.10
kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device-plugin/r1.10/k8s-ds-amdgpu-dp.yaml
```
---->
+-->
- Kubernetes 节点必须预先安装 AMD GPU 的 Linux 驱动。
如果你的集群已经启动并且满足上述要求的话，可以这样部署 AMD 设备插件：
-```
-# 针对 Kubernetes v1.9
-kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device-plugin/r1.9/k8s-ds-amdgpu-dp.yaml
-# 针对 Kubernetes v1.10
+```shell
kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device-plugin/r1.10/k8s-ds-amdgpu-dp.yaml
```
<!--
-Report issues with this device plugin to [RadeonOpenCompute/k8s-device-plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin).
---->
-请到 [RadeonOpenCompute/k8s-device-plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin) 报告有关此设备插件的问题。
+You can report issues with this third-party device plugin by logging an issue in
+[RadeonOpenCompute/k8s-device-plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin).
+-->
+你可以到 [RadeonOpenCompute/k8s-device-plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin)
+项目报告有关此设备插件的问题。
<!--
### Deploying NVIDIA GPU device plugin
There are currently two device plugin implementations for NVIDIA GPUs:
+-->
+### 部署 NVIDIA GPU 设备插件 {#deploying-nvidia-gpu-device-plugin}
+对于 NVIDIA GPUs，目前存在两种设备插件的实现：
+
+<!--
#### Official NVIDIA GPU device plugin
The [official NVIDIA GPU device plugin](https://github.com/NVIDIA/k8s-device-plugin)
has the following requirements:
---->
-### 部署 NVIDIA GPU 设备插件
-
-对于 NVIDIA GPUs，目前存在两种设备插件的实现：
-
+-->
#### 官方的 NVIDIA GPU 设备插件
[官方的 NVIDIA GPU 设备插件](https://github.com/NVIDIA/k8s-device-plugin) 有以下要求:
@@ -176,34 +169,18 @@ has the following requirements:
To deploy the NVIDIA device plugin once your cluster is running and the above
requirements are satisfied:
---->
+-->
- Kubernetes 的节点必须预先安装了 NVIDIA 驱动
- Kubernetes 的节点必须预先安装 [nvidia-docker 2.0](https://github.com/NVIDIA/nvidia-docker)
- Docker 的[默认运行时](https://github.com/NVIDIA/k8s-device-plugin#preparing-your-gpu-nodes)必须设置为 nvidia-container-runtime，而不是 runc
-- NVIDIA 驱动版本 ~= 361.93
+- NVIDIA 驱动版本 ~= 384.81
如果你的集群已经启动并且满足上述要求的话，可以这样部署 NVIDIA 设备插件：
-<!--
+```shell
+kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/1.0.0-beta4/nvidia-device-plugin.yml
```
-# For Kubernetes v1.8
-kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v1.8/nvidia-device-plugin.yml
-
-# For Kubernetes v1.9
-kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v1.9/nvidia-device-plugin.yml
-```
-
-Report issues with this device plugin to [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin).
---->
-```
-# 针对 Kubernetes v1.8
-kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v1.8/nvidia-device-plugin.yml
-
-# 针对 Kubernetes v1.9
-kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v1.9/nvidia-device-plugin.yml
-```
-
-请到 [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin) 报告有关此设备插件的问题。
+请到 [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin)项目报告有关此设备插件的问题。
<!--
#### NVIDIA GPU device plugin used by GCE
@@ -213,29 +190,15 @@ doesn't require using nvidia-docker and should work with any container runtime
that is compatible with the Kubernetes Container Runtime Interface (CRI). It's tested
on [Container-Optimized OS](https://cloud.google.com/container-optimized-os/)
and has experimental code for Ubuntu from 1.9 onwards.
---->
+-->
#### GCE 中使用的 NVIDIA GPU 设备插件
[GCE 使用的 NVIDIA GPU 设备插件](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu) 并不要求使用 nvidia-docker，并且对于任何实现了 Kubernetes CRI 的容器运行时，都应该能够使用。这一实现已经在 [Container-Optimized OS](https://cloud.google.com/container-optimized-os/) 上进行了测试，并且在 1.9 版本之后会有对于 Ubuntu 的实验性代码。
-<!--
-On your 1.12 cluster, you can use the following commands to install the NVIDIA drivers and device plugin:
+你可以使用下面的命令来安装 NVIDIA 驱动以及设备插件：
```
-# Install NVIDIA drivers on Container-Optimized OS:
-kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/stable/daemonset.yaml
-
-# Install NVIDIA drivers on Ubuntu (experimental):
-kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/stable/nvidia-driver-installer/ubuntu/daemonset.yaml
-
-# Install the device plugin:
-kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.12/cluster/addons/device-plugins/nvidia-gpu/daemonset.yaml
-```
---->
-在你 1.12 版本的集群上，你能使用下面的命令来安装 NVIDIA 驱动以及设备插件：
-
-```
-# 在容器优化的操作系统上安装 NVIDIA 驱动:
+# 在 COntainer-Optimized OS 上安装 NVIDIA 驱动:
kubectl create -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/stable/daemonset.yaml
# 在 Ubuntu 上安装 NVIDIA 驱动 (实验性质):
@@ -248,11 +211,12 @@ kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/releas
<!--
Report issues with this device plugin and installation method to [GoogleCloudPlatform/container-engine-accelerators](https://github.com/GoogleCloudPlatform/container-engine-accelerators).
-Instructions for using NVIDIA GPUs on GKE are
-[here](https://cloud.google.com/kubernetes-engine/docs/how-to/gpus)
---->
+Google publishes its own [instructions](https://cloud.google.com/kubernetes-engine/docs/how-to/gpus) for using NVIDIA GPUs on GKE .
+-->
请到 [GoogleCloudPlatform/container-engine-accelerators](https://github.com/GoogleCloudPlatform/container-engine-accelerators) 报告有关此设备插件以及安装方法的问题。
+关于如何在 GKE 上使用 NVIDIA GPUs，Google 也提供自己的[指令](https://cloud.google.com/kubernetes-engine/docs/how-to/gpus)。
+
<!--
## Clusters containing different types of GPUs
@@ -261,20 +225,15 @@ can use [Node Labels and Node Selectors](/docs/tasks/configure-pod-container/ass
to schedule pods to appropriate nodes.
For example:
---->
-## 集群内存在不同类型的 NVIDIA GPU
+-->
+## 集群内存在不同类型的 GPU
-如果集群内部的不同节点上有不同类型的 NVIDIA GPU，那么你可以使用 [节点标签和节点选择器](/docs/tasks/configure-pod-container/assign-pods-nodes/) 来将 pod 调度到合适的节点上。
+如果集群内部的不同节点上有不同类型的 NVIDIA GPU，那么你可以使用
+[节点标签和节点选择器](/zh/docs/tasks/configure-pod-container/assign-pods-nodes/)
+来将 pod 调度到合适的节点上。
例如：
-<!--
-```shell
-# Label your nodes with the accelerator type they have.
-kubectl label nodes <node-with-k80> accelerator=nvidia-tesla-k80
-kubectl label nodes <node-with-p100> accelerator=nvidia-tesla-p100
-```
---->
```shell
# 为你的节点加上它们所拥有的加速器类型的标签
kubectl label nodes <node-with-k80> accelerator=nvidia-tesla-k80
@@ -282,9 +241,22 @@ kubectl label nodes <node-with-p100> accelerator=nvidia-tesla-p100
```
<!--
-For AMD GPUs, you can deploy [Node Labeller](https://github.com/RadeonOpenCompute/k8s-device-plugin/tree/master/cmd/k8s-node-labeller), which automatically labels your nodes with GPU properties. Currently supported properties:
---->
-对于 AMD GPUs，您可以部署 [节点标签器](https://github.com/RadeonOpenCompute/k8s-device-plugin/tree/master/cmd/k8s-node-labeller)，它会自动给节点打上 GPU 属性标签。目前支持的属性：
+## Automatic node labelling {#node-labeller}
+-->
+## 自动节点标签 {#node-labeller}
+
+<!--
+If you're using AMD GPU devices, you can deploy
+[Node Labeller](https://github.com/RadeonOpenCompute/k8s-device-plugin/tree/master/cmd/k8s-node-labeller).
+Node Labeller is a {{< glossary_tooltip text="controller" term_id="controller" >}} that automatically
+labels your nodes with GPU properties.
+
+At the moment, that controller can add labels for:
+-->
+如果你在使用 AMD GPUs，你可以部署
+[Node Labeller](https://github.com/RadeonOpenCompute/k8s-device-plugin/tree/master/cmd/k8s-node-labeller)，
+它是一个 {{< glossary_tooltip text="控制器" term_id="controller" >}}，
+会自动给节点打上 GPU 属性标签。目前支持的属性：
<!--
* Device ID (-device-id)
@@ -300,7 +272,6 @@ For AMD GPUs, you can deploy [Node Labeller](https://github.com/RadeonOpenComput
* CZ - Carrizo
* AI - Arctic Islands
* RV - Raven
-
Example result:
--->
* 设备 ID (-device-id)
@@ -319,7 +290,11 @@ Example result:
示例:
- $ kubectl describe node cluster-node-23
+```shell
+kubectl describe node cluster-node-23
+```
+
+```
Name: cluster-node-23
Roles: <none>
Labels: beta.amd.com/gpu.cu-count.64=1
@@ -333,11 +308,12 @@ Example result:
Annotations: kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
node.alpha.kubernetes.io/ttl: 0
......
+```
<!--
-Specify the GPU type in the pod spec:
---->
-在 pod 的 spec 字段中指定 GPU 的类型：
+With the Node Labeller in use, you can specify the GPU type in the Pod spec:
+-->
+使用了 Node Labeller 的时候，你可以在 Pod 的规约中指定 GPU 的类型：
```yaml
apiVersion: v1
@@ -360,5 +336,6 @@ spec:
<!--
This will ensure that the pod will be scheduled to a node that has the GPU type
you specified.
---->
-这能够保证 pod 能够被调度到你所指定类型的 GPU 的节点上去。
+-->
+这能够保证 Pod 能够被调度到你所指定类型的 GPU 的节点上去。
+
diff --git a/content/zh/docs/tasks/manage-kubernetes-objects/imperative-config.md b/content/zh/docs/tasks/manage-kubernetes-objects/imperative-config.md
index 1cd2daf0a1..d270a85df4 100644
--- a/content/zh/docs/tasks/manage-kubernetes-objects/imperative-config.md
+++ b/content/zh/docs/tasks/manage-kubernetes-objects/imperative-config.md
@@ -4,11 +4,9 @@ content_type: task
weight: 40
---
<!--
----
title: Imperative Management of Kubernetes Objects Using Configuration Files
content_type: task
weight: 40
----
-->
<!-- overview -->
@@ -20,29 +18,24 @@ This document explains how to define and manage objects using configuration file
可以使用 `kubectl` 命令行工具以及用 YAML 或 JSON 编写的对象配置文件来创建、更新和删除 Kubernetes 对象。
本文档说明了如何使用配置文件定义和管理对象。
-
## {{% heading "prerequisites" %}}
-
<!--
Install [`kubectl`](/docs/tasks/tools/install-kubectl/).
-->
-安装 [`kubectl`](/docs/tasks/tools/install-kubectl/) 。
+安装 [`kubectl`](/zh/docs/tasks/tools/install-kubectl/) 。
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
-
-
<!-- steps -->
<!--
## Trade-offs
+
+The `kubectl` tool supports three kinds of object management:
-->
## 权衡
-<!--
-The `kubectl` tool supports three kinds of object management:
--->
`kubectl` 工具支持三种对象管理：
<!--
@@ -58,30 +51,26 @@ The `kubectl` tool supports three kinds of object management:
See [Kubernetes Object Management](/docs/concepts/overview/working-with-objects/object-management/)
for a discussion of the advantages and disadvantage of each kind of object management.
-->
-参看 [Kubernetes 对象管理](/docs/concepts/overview/working-with-objects/object-management/) 讨论每种对象管理的优缺点。
+参看 [Kubernetes 对象管理](/zh/docs/concepts/overview/working-with-objects/object-management/)
+中关于每种对象管理的优缺点的讨论。
<!--
## How to create objects
--->
-## 如何创建对象
-<!--
You can use `kubectl create -f` to create an object from a configuration file.
Refer to the [kubernetes API reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
for details.
-->
-您可以使用 `kubectl create -f` 从配置文件创建一个对象。
+## 如何创建对象
+
+你可以使用 `kubectl create -f` 从配置文件创建一个对象。
请参考 [kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 有关详细信息。
* `kubectl create -f <filename|url>`
<!--
## How to update objects
--->
-## 如何更新对象
-{{< warning >}}
-<!--
Updating objects with the `replace` command drops all
parts of the spec not specified in the configuration file. This
should not be used with objects whose specs are partially managed
@@ -90,8 +79,12 @@ the `externalIPs` field is managed independently from the configuration
file. Independently managed fields must be copied to the configuration
file to prevent `replace` from dropping them.
-->
+## 如何更新对象
+
+{{< warning >}}
使用 `replace` 命令更新对象会删除所有未在配置文件中指定的规范的某些部分。
-不应将其规范由集群部分管理的对象使用，比如类型为 `LoadBalancer` 的服务，其中 `externalIPs` 字段独立于配置文件进行管理。
+不应将其规范由集群部分管理的对象使用，比如类型为 `LoadBalancer` 的服务，
+其中 `externalIPs` 字段独立于配置文件进行管理。
必须将独立管理的字段复制到配置文件中，以防止 `replace` 删除它们。
{{< /warning >}}
@@ -99,33 +92,31 @@ file to prevent `replace` from dropping them.
You can use `kubectl replace -f` to update a live object according to a
configuration file.
-->
-您可以使用 `kubectl replace -f` 根据配置文件更新活动对象。
+你可以使用 `kubectl replace -f` 根据配置文件更新活动对象。
* `kubectl replace -f <filename|url>`
<!--
## How to delete objects
--->
-## 如何删除对象
-<!--
You can use `kubectl delete -f` to delete an object that is described in a
configuration file.
-->
-您可以使用 `kubectl delete -f` 删除配置文件中描述的对象。
+## 如何删除对象
+
+你可以使用 `kubectl delete -f` 删除配置文件中描述的对象。
* `kubectl delete -f <filename|url>`
<!--
## How to view an object
--->
-## 如何查看对象
-<!--
You can use `kubectl get -f` to view information about an object that is
described in a configuration file.
-->
-您可以使用 `kubectl get -f` 查看有关配置文件中描述的对象的信息。
+## 如何查看对象
+
+你可以使用 `kubectl get -f` 查看有关配置文件中描述的对象的信息。
* `kubectl get -f <filename|url> -o yaml`
@@ -138,10 +129,7 @@ Use `kubectl get -h` to see a list of options.
<!--
## Limitations
--->
-## 局限性
-<!--
The `create`, `replace`, and `delete` commands work well when each object's
configuration is fully defined and recorded in its configuration
file. However when a live object is updated, and the updates are not merged
@@ -150,6 +138,8 @@ is executed. This can happen if a controller, such as
a HorizontalPodAutoscaler, makes updates directly to a live object. Here's
an example:
-->
+## 局限性
+
当完全定义每个对象的配置并将其记录在其配置文件中时，`create`、 `replace` 和`delete` 命令会很好的工作。
但是，当更新一个活动对象，并且更新没有合并到其配置文件中时，下一次执行 `replace` 时，更新将丢失。
如果控制器,例如 HorizontalPodAutoscaler ,直接对活动对象进行更新，则会发生这种情况。
@@ -173,17 +163,16 @@ If you need to support multiple writers to the same object, you can use
<!--
## Creating and editing an object from a URL without saving the configuration
--->
-## 从 URL 创建和编辑对象而不保存配置
-<!--
Suppose you have the URL of an object configuration file. You can use
`kubectl create --edit` to make changes to the configuration before the
object is created. This is particularly useful for tutorials and tasks
that point to a configuration file that could be modified by the reader.
-->
-假设您具有对象配置文件的 URL。
-您可以在创建对象之前使用 `kubectl create --edit` 对配置进行更改。
+## 从 URL 创建和编辑对象而不保存配置
+
+假设你具有对象配置文件的 URL。
+你可以在创建对象之前使用 `kubectl create --edit` 对配置进行更改。
这对于指向可以由读者修改的配置文件的教程和任务特别有用。
```shell
@@ -192,13 +181,12 @@ kubectl create -f <url> --edit
<!--
## Migrating from imperative commands to imperative object configuration
--->
-## 从命令式命令迁移到命令式对象配置
-<!--
Migrating from imperative commands to imperative object configuration involves
several manual steps.
-->
+## 从命令式命令迁移到命令式对象配置
+
从命令式命令迁移到命令式对象配置涉及几个手动步骤。
<!--
@@ -206,33 +194,33 @@ several manual steps.
-->
1. 将活动对象导出到本地对象配置文件：
- ```shell
- kubectl get <kind>/<name> -o yaml > <kind>_<name>.yaml
- ```
+ ```shell
+ kubectl get <kind>/<name> -o yaml > <kind>_<name>.yaml
+ ```
<!--
1. Manually remove the status field from the object configuration file.
-->
-1. 从对象配置文件中手动删除状态字段。
+2. 从对象配置文件中手动删除状态字段。
<!--
1. For subsequent object management, use `replace` exclusively.
-->
-1. 对于后续的对象管理，只能使用 `replace` 。
+3. 对于后续的对象管理，只能使用 `replace` 。
- ```shell
- kubectl replace -f <kind>_<name>.yaml
- ```
+ ```shell
+ kubectl replace -f <kind>_<name>.yaml
+ ```
<!--
## Defining controller selectors and PodTemplate labels
-->
## 定义控制器选择器和 PodTemplate 标签
-{{< warning >}}
<!--
Updating selectors on controllers is strongly discouraged.
-->
+{{< warning >}}
不建议在控制器上更新选择器。
{{< /warning >}}
@@ -242,9 +230,7 @@ used only by the controller selector with no other semantic meaning.
-->
推荐的方法是定义单个不变的 PodTemplate 标签，该标签仅由控制器选择器使用，而没有其他语义。
-<!--
-Example label:
--->
+<!-- Example label: -->
标签示例：
```yaml
@@ -257,21 +243,17 @@ template:
controller-selector: "apps/v1/deployment/nginx"
```
-
-
## {{% heading "whatsnext" %}}
-
<!--
* [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/)
* [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tasks/manage-kubernetes-objects/declarative-config/)
* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
-->
-* [使用命令式命令管理 Kubernetes 对象](/docs/tasks/manage-kubernetes-objects/imperative-command/)
-* [使用对象配置管理 Kubernetes 对象 (声明式)](/docs/tasks/manage-kubernetes-objects/declarative-config/)
-* [Kubectl 命令参考](/docs/reference/generated/kubectl/kubectl/)
+* [使用命令式命令管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/imperative-command/)
+* [使用对象配置管理 Kubernetes 对象 (声明式)](/zh/docs/tasks/manage-kubernetes-objects/declarative-config/)
+* [Kubectl 命令参考](/docs/reference/generated/kubectl/kubectl-commands/)
* [Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
-
diff --git a/content/zh/docs/tasks/network/validate-dual-stack.md b/content/zh/docs/tasks/network/validate-dual-stack.md
index c0d1363fcc..2f67abbf70 100644
--- a/content/zh/docs/tasks/network/validate-dual-stack.md
+++ b/content/zh/docs/tasks/network/validate-dual-stack.md
@@ -6,13 +6,11 @@ title: 验证 IPv4/IPv6 双协议栈
content_type: task
---
<!--
----
reviewers:
- lachie83
- khenidak
title: Validate IPv4/IPv6 dual-stack
content_type: task
----
-->
<!-- overview -->
@@ -21,10 +19,8 @@ This document shares how to validate IPv4/IPv6 dual-stack enabled Kubernetes clu
-->
这篇文章分享了如何验证 IPv4/IPv6 双协议栈的 Kubernetes 集群。
-
## {{% heading "prerequisites" %}}
-
<!--
* Kubernetes 1.16 or later
* Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces)
@@ -34,27 +30,24 @@ This document shares how to validate IPv4/IPv6 dual-stack enabled Kubernetes clu
-->
* Kubernetes 1.16 或更高版本
* 提供程序对双协议栈网络的支持 (云供应商或其他方式必须能够为 Kubernetes 节点提供可路由的 IPv4/IPv6 网络接口)
-* Kubenet 网络插件
+* 一个能够支持双协议栈的[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)，
+ （如 kubenet 或 Calico）。
* Kube-proxy 在 IPVS 模式下运行
-* [启用双协议栈](/docs/concepts/services-networking/dual-stack/) 集群
-
-
+* [启用双协议栈](/zh/docs/concepts/services-networking/dual-stack/) 集群
<!-- steps -->
<!--
## Validate addressing
+
+### Validate node addressing
+
+Each dual-stack Node should have a single IPv4 block and a single IPv6 block allocated. Validate that IPv4/IPv6 Pod address ranges are configured by running the following command. Replace the sample node name with a valid dual-stack Node from your cluster. In this example, the Node's name is `k8s-linuxpool1-34450317-0`:
-->
## 验证寻址
-<!--
-### Validate node addressing
--->
### 验证节点寻址
-<!--
-Each dual-stack Node should have a single IPv4 block and a single IPv6 block allocated. Validate that IPv4/IPv6 Pod address ranges are configured by running the following command. Replace the sample node name with a valid dual-stack Node from your cluster. In this example, the Node's name is `k8s-linuxpool1-34450317-0`:
--->
每个双协议栈节点应分配一个 IPv4 块和一个 IPv6 块。
通过运行以下命令来验证是否配置了 IPv4/IPv6 Pod 地址范围。
将示例节点名称替换为集群中的有效双协议栈节点。
@@ -63,10 +56,12 @@ Each dual-stack Node should have a single IPv4 block and a single IPv6 block all
```shell
kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .spec.podCIDRs}}{{printf "%s\n" .}}{{end}}'
```
+
```
10.244.1.0/24
a00:100::/24
```
+
<!--
There should be one IPv4 block and one IPv6 block allocated.
-->
@@ -75,7 +70,9 @@ There should be one IPv4 block and one IPv6 block allocated.
<!--
Validate that the node has an IPv4 and IPv6 interface detected (replace node name with a valid node from the cluster. In this example the node name is k8s-linuxpool1-34450317-0):
-->
-验证节点是否检测到 IPv4 和 IPv6 接口（用集群中的有效节点替换节点名称。在此示例中，节点名称为 k8s-linuxpool1-34450317-0）：
+验证节点是否检测到 IPv4 和 IPv6 接口（用集群中的有效节点替换节点名称。
+在此示例中，节点名称为 `k8s-linuxpool1-34450317-0`）：
+
```shell
kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .status.addresses}}{{printf "%s: %s \n" .type .address}}{{end}}'
```
@@ -87,16 +84,17 @@ InternalIP: 2001:1234:5678:9abc::5
<!--
### Validate Pod addressing
+
+Validate that a Pod has an IPv4 and IPv6 address assigned. (replace the Pod name with a valid Pod in your cluster. In this example the Pod name is pod01)
-->
### 验证 Pod 寻址
-<!--
-Validate that a Pod has an IPv4 and IPv6 address assigned. (replace the Pod name with a valid Pod in your cluster. In this example the Pod name is pod01)
--->
验证 Pod 已分配了 IPv4 和 IPv6 地址。（用集群中的有效 Pod 替换 Pod 名称。在此示例中， Pod 名称为 pod01）
+
```shell
kubectl get pods pod01 -o go-template --template='{{range .status.podIPs}}{{printf "%s \n" .ip}}{{end}}'
```
+
```
10.244.1.4
a00:100::4
@@ -123,6 +121,7 @@ The following command prints the value of the `MY_POD_IPS` environment variable
```shell
kubectl exec -it pod01 -- set | grep MY_POD_IPS
```
+
```
MY_POD_IPS=10.244.1.4,a00:100::4
```
@@ -135,6 +134,7 @@ Pod 的 IP 地址也将被写入容器内的 `/etc/hosts` 文件中。在双栈
```shell
kubectl exec -it pod01 -- cat /etc/hosts
```
+
```
# Kubernetes-managed hosts file.
127.0.0.1 localhost
@@ -149,12 +149,11 @@ a00:100::4 pod01
<!--
## Validate Services
+
+Create the following Service without the `ipFamily` field set. When this field is not set, the Service gets an IP from the first configured range via `--service-cluster-ip-range` flag on the kube-controller-manager.
-->
## 验证服务
-<!--
-Create the following Service without the `ipFamily` field set. When this field is not set, the Service gets an IP from the first configured range via `--service-cluster-ip-range` flag on the kube-controller-manager.
--->
在不设置 `ipFamily` 字段的情况下创建以下服务。
如果未设置此字段，则服务会通过 kube-controller-manager 上的 `--service-cluster-ip-range` 标志从第一个配置的范围中获取 IP。
@@ -163,7 +162,8 @@ Create the following Service without the `ipFamily` field set. When this field i
<!--
By viewing the YAML for the Service you can observe that the Service has the `ipFamily` field has set to reflect the address family of the first configured range set via `--service-cluster-ip-range` flag on kube-controller-manager.
-->
-通过查看该服务的 YAML ，您可以观察到该服务的 `ipFamily` 字段已设置为反映通过 kube-controller-manager 上的 `--service-cluster-ip-range` 标志设置的第一个配置范围的地址族。
+通过查看该服务的 YAML ，您可以观察到该服务的 `ipFamily` 字段已设置为反映通过
+kube-controller-manager 上的 `--service-cluster-ip-range` 标志设置的第一个配置范围的地址族。
```shell
kubectl get svc my-service -o yaml
@@ -216,12 +216,11 @@ my-service ClusterIP fe80:20d::d06b <none> 80/TCP 9s
<!--
### Create a dual-stack load balanced Service
+
+If the cloud provider supports the provisioning of IPv6 enabled external load balancer, create the following Service with both the `ipFamily` field set to `IPv6` and the `type` field set to `LoadBalancer`
-->
### 创建双协议栈负载均衡服务
-<!--
-If the cloud provider supports the provisioning of IPv6 enabled external load balancer, create the following Service with both the `ipFamily` field set to `IPv6` and the `type` field set to `LoadBalancer`
--->
如果云提供商支持配置启用 IPv6 的外部负载均衡器，则将 `ipFamily` 字段设置为 `IPv6` 并将 `type` 字段设置为 `LoadBalancer`的方式创建以下服务
{{< codenew file="service/networking/dual-stack-ipv6-lb-svc.yaml" >}}
@@ -237,7 +236,3 @@ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S
my-service ClusterIP fe80:20d::d06b 2001:db8:f100:4002::9d37:c0d7 80:31868/TCP 30s
```
-
-
-
-
diff --git a/content/zh/docs/tasks/run-application/configure-pdb.md b/content/zh/docs/tasks/run-application/configure-pdb.md
index faeba16c3c..5fb983c4ee 100644
--- a/content/zh/docs/tasks/run-application/configure-pdb.md
+++ b/content/zh/docs/tasks/run-application/configure-pdb.md
@@ -1,71 +1,71 @@
---
-title: 指定应用程序的中断预算（Disruption Budget）
+title: 为应用程序设置干扰预算（Disruption Budget）
content_type: task
weight: 110
---
-<!-- ---
+<!--
title: Specifying a Disruption Budget for your Application
content_type: task
weight: 110
---- -->
+-->
<!-- overview -->
-<!-- This page shows how to limit the number of concurrent disruptions
+{{< feature-state for_k8s_version="v1.5" state="beta" >}}
+
+<!--
+This page shows how to limit the number of concurrent disruptions
that your application experiences, allowing for higher availability
while permitting the cluster administrator to manage the clusters
-nodes. -->
-
-本文展示了如何限制应用程序的并发中断数量，在允许集群管理员管理集群节点的同时保证高可用。
-
-
+nodes.
+-->
+本文展示如何限制应用程序的并发干扰数量，在允许集群管理员管理集群节点的同时保证高可用。
## {{% heading "prerequisites" %}}
-
-<!-- * You are the owner of an application running on a Kubernetes cluster that requires
- high availability. -->
-* 用户是 Kubernetes 集群中有高可用需求的应用的所有者。
-
-<!-- * You should know how to deploy [Replicated Stateless Applications](/docs/tasks/run-application/run-stateless-application-deployment/)
- and/or [Replicated Stateful Applications](/docs/tasks/run-application/run-replicated-stateful-application/). -->
-* 用户应了解如何部署 [无状态应用](/docs/tasks/run-application/run-stateless-application-deployment/)
-和/或 [有状态应用](/docs/tasks/run-application/run-replicated-stateful-application/)。
-
-<!-- * You should have read about [Pod Disruptions](/docs/concepts/workloads/pods/disruptions/). -->
-* 用户应当已经阅读过关于 [Pod 中断](/docs/concepts/workloads/pods/disruptions/) 的文档。
-
-<!-- * You should confirm with your cluster owner or service provider that they respect
- Pod Disruption Budgets. -->
-* 用户应当与集群所有者或服务提供者确认其遵从 Pod 中断预算（Pod Disruption Budgets）的规则。
-
-
+<!--
+* You are the owner of an application running on a Kubernetes cluster that requires
+ high availability.
+* You should know how to deploy [Replicated Stateless Applications](/docs/tasks/run-application/run-stateless-application-deployment/)
+ and/or [Replicated Stateful Applications](/docs/tasks/run-application/run-replicated-stateful-application/).
+* You should have read about [Pod Disruptions](/docs/concepts/workloads/pods/disruptions/).
+* You should confirm with your cluster owner or service provider that they respect
+ Pod Disruption Budgets.
+-->
+* 你是 Kubernetes 集群中某应用的所有者，该应用有高可用要求。
+* 你应了解如何部署[无状态应用](.zh/docs/tasks/run-application/run-stateless-application-deployment/)
+ 和/或[有状态应用](/zh/docs/tasks/run-application/run-replicated-stateful-application/)。
+* 你应当已经阅读过关于 [Pod 干扰](/zh/docs/concepts/workloads/pods/disruptions/) 的文档。
+* 用户应当与集群所有者或服务提供者确认其遵从 Pod 干扰预算（Pod Disruption Budgets）的规则。
<!-- steps -->
-<!-- ## Protecting an Application with a PodDisruptionBudget -->
-## 用 PodDisruptionBudget 来保护应用
+<!--
+## Protecting an Application with a PodDisruptionBudget
-<!-- 1. Identify what application you want to protect with a PodDisruptionBudget (PDB).
+1. Identify what application you want to protect with a PodDisruptionBudget (PDB).
1. Think about how your application reacts to disruptions.
1. Create a PDB definition as a YAML file.
-1. Create the PDB object from the YAML file. -->
+1. Create the PDB object from the YAML file.
+-->
+## 用 PodDisruptionBudget 来保护应用
1. 确定想要使用 PodDisruptionBudget (PDB) 来保护的应用。
-1. 考虑应用对中断的反应。
+1. 考虑应用对干扰的反应。
1. 以 YAML 文件形式定义 PDB 。
1. 通过 YAML 文件创建 PDB 对象。
-
-
<!-- discussion -->
-<!-- ## Identify an Application to Protect -->
+<!--
+## Identify an Application to Protect
+
+The most common use case when you want to protect an application
+specified by one of the built-in Kubernetes controllers:
+-->
## 确定要保护的应用
-<!-- The most common use case when you want to protect an application
-specified by one of the built-in Kubernetes controllers: -->
用户想要保护通过内置的 Kubernetes 控制器指定的应用，这是最常见的使用场景：
- Deployment
@@ -73,24 +73,34 @@ specified by one of the built-in Kubernetes controllers: -->
- ReplicaSet
- StatefulSet
-<!-- In this case, make a note of the controller's `.spec.selector`; the same
-selector goes into the PDBs `.spec.selector`. -->
-在这种情况下，在控制器的 `.spec.selector` 字段中做记录，并在 PDB 的 `.spec.selector` 字段中加入同样的选择器。
+<!--
+In this case, make a note of the controller's `.spec.selector`; the same
+selector goes into the PDBs `.spec.selector`.
+-->
+在这种情况下，在控制器的 `.spec.selector` 字段中做记录，并在 PDB 的
+`.spec.selector` 字段中加入同样的选择算符。
-<!-- You can also use PDBs with pods which are not controlled by one of the above
+<!--
+You can also use PDBs with pods which are not controlled by one of the above
controllers, or arbitrary groups of pods, but there are some restrictions,
-described in [Arbitrary Controllers and Selectors](#arbitrary-controllers-and-selectors). -->
-用户也可以用 PDB 来保护不受上述控制器控制的 pod，或任意组（arbitrary groups）的 pod， 但是正如 [任意控制器和选择器](#arbitrary-controllers-and-selectors) 中描述的，这里存在一些限制。
+described in [Arbitrary Controllers and Selectors](#arbitrary-controllers-and-selectors).
+-->
+用户也可以用 PDB 来保护不受上述控制器控制的 Pod，或任意的 Pod 集合，但是正如
+[任意控制器和选择算符](#arbitrary-controllers-and-selectors)中描述的，这里存在一些限制。
-<!-- ## Think about how your application reacts to disruptions -->
-## 考虑应用对中断的反应
+<!--
+## Think about how your application reacts to disruptions
-<!-- Decide how many instances can be down at the same time for a short period
-due to a voluntary disruption. -->
-确定在自发中断时，多少实例可以在短时间内同时关闭。
+Decide how many instances can be down at the same time for a short period
+due to a voluntary disruption.
+-->
+## 考虑应用对干扰的反应
-<!-- - Stateless frontends:
- - Concern: don't reduce serving capacity by more than 10%.
+确定在自发干扰时，多少实例可以在短时间内同时关闭。
+
+<!--
+- Stateless frontends:
+ - Concern: don't reduce serving capacity by more than 10%.
- Solution: use PDB with minAvailable 90% for example.
- Single-instance Stateful Application:
- Concern: do not terminate this application without talking to me.
@@ -105,231 +115,310 @@ due to a voluntary disruption. -->
- Possible Solution 2: set minAvailable to quorum-size (e.g. 3 when scale is 5). (Allows more disruptions at once).
- Restartable Batch Job:
- Concern: Job needs to complete in case of voluntary disruption.
- - Possible solution: Do not create a PDB. The Job controller will create a replacement pod. -->
-
+ - Possible solution: Do not create a PDB. The Job controller will create a replacement pod.
+-->
- 无状态的前端：
- - 关注：不能降低服务能力 10% 以上。
- - 解决方案：例如，使用 PDB，指定其 minAvailable 值为 90%。
+ - 关注：不能降低服务能力 10% 以上。
+ - 解决方案：例如，使用 PDB，指定其 minAvailable 值为 90%。
- 单实例有状态应用：
- - 关注：不要在不通知的情况下终止该应用。
- - 可能的解决方案 1：不使用 PDB，并忍受偶尔的停机。
- - 可能的解决方案 2：设置 maxUnavailable=0 的 PDB。意为（Kubernetes 范畴之外的） 集群操作人员需要在终止应用前与用户协商，协商后准备停机，然后删除 PDB 表示准备中断，后续再重新创建。
-- 多实例有状态应用， 如 Consul、ZooKeeper 或 etcd：
- - 关注：不要将实例数量减少至低于仲裁规模（below quorum），否则将写入失败。
- - 可能的解决方案 1：设置 maxUnavailable 值为 1 (适用于不同规模的应用)。
- - 可能的解决方案 2：设置 minAvailable 值为仲裁规模（例如规模为 5 时设置为 3）。 (允许每次更多的中断)。
+ - 关注：不要在不通知的情况下终止该应用。
+ - 可能的解决方案 1：不使用 PDB，并忍受偶尔的停机。
+ - 可能的解决方案 2：设置 maxUnavailable=0 的 PDB。
+ 意为（Kubernetes 范畴之外的）集群操作人员需要在终止应用前与用户协商，
+ 协商后准备停机，然后删除 PDB 表示准备接受干扰，后续再重新创建。
+- 多实例有状态应用，如 Consul、ZooKeeper 或 etcd：
+ - 关注：不要将实例数量减少至低于仲裁规模，否则将出现写入失败。
+ - 可能的解决方案 1：设置 maxUnavailable 值为 1 (适用于不同规模的应用)。
+ - 可能的解决方案 2：设置 minAvailable 值为仲裁规模（例如规模为 5 时设置为 3）。
+ (允许同时出现更多的干扰)。
- 可重新启动的批处理任务：
- - 关注： 自发中断的情况下，需要确保任务完成。
- - 可能的解决方案：不创建 PDB。 任务控制器会创建一个替换的 pod。
+ - 关注：自发干扰的情况下，需要确保任务完成。
+ - 可能的解决方案：不创建 PDB。 任务控制器会创建一个替换 Pod。
-<!-- ### Rounding logic when specifying percentages -->
+<!--
+### Rounding logic when specifying percentages
+
+Values for `minAvailable` or `maxUnavailable` can be expressed as integers or as a percentage.
+-->
### 指定百分比时的舍入逻辑
-<!-- Values for `minAvailable` or `maxUnavailable` can be expressed as integers or as a percentage. -->
`minAvailable` 或 `maxUnavailable` 的值可以表示为整数或百分比。
-<!-- - When you specify an integer, it represents a number of Pods. For instance, if you set `minAvailable` to 10, then 10
- Pods must always be available, even during a disruption. -->
-- 指定整数时，它表示许多Pod。 例如，如果将minAvailable设置为10，那么即使在中断期间，也必须始终有10个Pod可用。
-<!-- - When you specify a percentage by setting the value to a string representation of a percentage (eg. `"50%"`), it represents a percentage of
+<!--
+- When you specify an integer, it represents a number of Pods. For instance, if you set `minAvailable` to 10, then 10
+ Pods must always be available, even during a disruption.
+- When you specify a percentage by setting the value to a string representation of a percentage (eg. `"50%"`), it represents a percentage of
total Pods. For instance, if you set `minUnavailable` to `"50%"`, then only 50% of the Pods can be unavailable during a
- disruption. -->
-- 通过将值设置为百分比的字符串表示形式（例如“50％”）来指定百分比时，它表示总 Pod 数的百分比。例如，如果将 "minUnavailable" 设置为“50％”，则只有50％的 Pod 可以中断。
+ disruption.
+-->
+- 指定整数值时，它表示 Pod 个数。例如，如果将 minAvailable 设置为 10，
+ 那么即使在干扰期间，也必须始终有 10 个Pod可用。
+- 通过将值设置为百分比的字符串表示形式（例如 “50％”）来指定百分比时，它表示占总 Pod 数的百分比。
+ 例如，如果将 "minUnavailable" 设置为 “50％”，则干扰期间只允许 50％ 的 Pod 不可用。
-<!-- When you specify the value as a percentage, it may not map to an exact number of Pods. For example, if you have 7 Pods and
-you set `minAvailable` to `"50%"`, it's not immediately obvious whether that means 3 Pods or 4 Pods must be available.
-Kubernetes rounds up to the nearest integer, so in this case, 4 Pods must be available. You can examine the
+<!--
+When you specify the value as a percentage, it may not map to an exact number
+of Pods. For example, if you have 7 Pods and you set `minAvailable` to
+`"50%"`, it's not immediately obvious whether that means 3 Pods or 4 Pods must
+be available. Kubernetes rounds up to the nearest integer, so in this case, 4
+Pods must be available. You can examine the
[code](https://github.com/kubernetes/kubernetes/blob/23be9587a0f8677eb8091464098881df939c44a9/pkg/controller/disruption/disruption.go#L539)
-that controls this behavior. -->
-如果将值指定为百分比，则可能无法映射到确切数量的 Pod 。例如，如果您有 7 个 Pod ，并且你将 `minAvailable` 设置为 `"50％"`，这不清楚是 3 个 Pod 或 4 个 Pod 必须可用。
-Kubernetes 向上取整到最接近的整数，因此在这种情况下，必须有 4 个 Pod 。
-您可以检查控制此行为的[代码](https://github.com/kubernetes/kubernetes/blob/23be9587a0f8677eb8091464098881df939c44a9/pkg/controller/disruption/disruption.go#L539)。
+that controls this behavior.
+-->
+如果将值指定为百分比，则可能无法映射到确切数量的 Pod。例如，如果你有 7 个 Pod，
+并且你将 `minAvailable` 设置为 `"50％"`，具体是 3 个 Pod 或 4 个 Pod 必须可用
+并非显而易见。
+Kubernetes 采用向上取整到最接近的整数的办法，因此在这种情况下，必须有 4 个 Pod。
+你可以检查控制此行为的
+[代码](https://github.com/kubernetes/kubernetes/blob/23be9587a0f8677eb8091464098881df939c44a9/pkg/controller/disruption/disruption.go#L539)。
-<!-- ## Specifying a PodDisruptionBudget -->
+<!--
+## Specifying a PodDisruptionBudget
+
+A `PodDisruptionBudget` has three fields:
+-->
## 指定 PodDisruptionBudget
-<!-- A `PodDisruptionBudget` has three fields: -->
一个 `PodDisruptionBudget` 有 3 个字段：
-<!-- * A label selector `.spec.selector` to specify the set of
+<!--
+* A label selector `.spec.selector` to specify the set of
pods to which it applies. This field is required.
* `.spec.minAvailable` which is a description of the number of pods from that
set that must still be available after the eviction, even in the absence
of the evicted pod. `minAvailable` can be either an absolute number or a percentage.
-* `.spec.maxUnavailable` (available in Kubernetes 1.7 and higher) which is a description
-of the number of pods from that set that can be unavailable after the eviction.
-It can be either an absolute number or a percentage. -->
-* 标签选择器 `.spec.selector` ，用于指定其所作用的 pod 集合， 该字段为必须字段。
-* `.spec.minAvailable` 表示驱逐后仍然保证可用的 pod 数量。即使因此影响到 pod 驱逐（即该条件在和 pod 驱逐发生冲突时优先保证）。
- `minAvailable` 值可以是绝对值，也可以是百分比。
-* `.spec.maxUnavailable` （Kubernetes 1.7 及更高的版本中可用）表示驱逐后允许不可用的 pod 的最大数量。
-其值可以是绝对值或是百分比。
+* `.spec.maxUnavailable` (available in Kubernetes 1.7 and higher) which is a description
+of the number of pods from that set that can be unavailable after the eviction.
+It can be either an absolute number or a percentage.
+-->
+* 标签选择算符 `.spec.selector` 用于指定其所作用的 Pod 集合，该字段为必需字段。
+* `.spec.minAvailable` 表示驱逐后仍须保证可用的 Pod 数量。即使因此影响到 Pod 驱逐
+ （即该条件在和 Pod 驱逐发生冲突时优先保证）。
+ `minAvailable` 值可以是绝对值，也可以是百分比。
+* `.spec.maxUnavailable` （Kubernetes 1.7 及更高的版本中可用）表示驱逐后允许不可用的
+ Pod 的最大数量。其值可以是绝对值或是百分比。
-{{< note >}}
-<!-- For versions 1.8 and earlier: When creating a `PodDisruptionBudget`
+<!--
+For versions 1.8 and earlier: When creating a `PodDisruptionBudget`
object using the `kubectl` command line tool, the `minAvailable` field has a
-default value of 1 if neither `minAvailable` nor `maxUnavailable` is specified. -->
-对于1.8及更早的版本：当你用 `kubectl` 命令行工具创建 `PodDisruptionBudget`对象时，如果既未指定 `minAvailable` 也未指定 `maxUnavailable`，
-则 `minAvailable` 字段有一个默认值1。
+default value of 1 if neither `minAvailable` nor `maxUnavailable` is specified.
+-->
+{{< note >}}
+对于1.8及更早的版本：当你用 `kubectl` 命令行工具创建 `PodDisruptionBudget` 对象时，
+如果既未指定 `minAvailable` 也未指定 `maxUnavailable`，
+则 `minAvailable` 字段有一个默认值 1。
{{< /note >}}
-<!-- You can specify only one of `maxUnavailable` and `minAvailable` in a single `PodDisruptionBudget`.
-`maxUnavailable` can only be used to control the eviction of pods
+<!--
+You can specify only one of `maxUnavailable` and `minAvailable` in a single `PodDisruptionBudget`.
+`maxUnavailable` can only be used to control the eviction of pods
that have an associated controller managing them. In the examples below, "desired replicas"
is the `scale` of the controller managing the pods being selected by the
-`PodDisruptionBudget`. -->
-用户在同一个 `PodDisruptionBudget` 中只能够指定 `maxUnavailable` 和 `minAvailable` 中的一个。`maxUnavailable`
-只能够用于控制存在相应控制器的 pod 的驱逐（即不受控制器控制的 pod 不在 `maxUnavailable` 控制范围内）。在下面的示例中，
-“所需副本” 指的是相应控制器的 `scale`， 控制器对 `PodDisruptionBudget` 所选择的 pod 进行管理。
+`PodDisruptionBudget`.
+-->
+用户在同一个 `PodDisruptionBudget` 中只能够指定 `maxUnavailable` 和 `minAvailable` 中的一个。
+`maxUnavailable` 只能够用于控制存在相应控制器的 Pod 的驱逐（即不受控制器控制的 Pod 不在
+`maxUnavailable` 控制范围内）。在下面的示例中，
+“所需副本” 指的是相应控制器的 `scale`，控制器对 `PodDisruptionBudget` 所选择的 Pod 进行管理。
-<!-- Example 1: With a `minAvailable` of 5, evictions are allowed as long as they leave behind
-5 or more healthy pods among those selected by the PodDisruptionBudget's `selector`. -->
-示例 1：设置 `minAvailable` 值为 5 的情况下，驱逐时需保证 PodDisruptionBudget 的 `selector` 选中的 pod 中 5 个 或 5 个以上处于健康状态。
+<!--
+Example 1: With a `minAvailable` of 5, evictions are allowed as long as they leave behind
+5 or more healthy pods among those selected by the PodDisruptionBudget's `selector`.
+-->
+示例 1：设置 `minAvailable` 值为 5 的情况下，驱逐时需保证 PodDisruptionBudget 的 `selector`
+选中的 Pod 中 5 个或 5 个以上处于健康状态。
-<!-- Example 2: With a `minAvailable` of 30%, evictions are allowed as long as at least 30%
-of the number of desired replicas are healthy. -->
-示例 2：设置 `minAvailable` 值为 30% 的情况下，驱逐时需保证 pod 所需副本的至少 30% 处于健康状态。
+<!--
+Example 2: With a `minAvailable` of 30%, evictions are allowed as long as at least 30%
+of the number of desired replicas are healthy.
+-->
+示例 2：设置 `minAvailable` 值为 30% 的情况下，驱逐时需保证 Pod 所需副本的至少 30% 处于健康状态。
-<!-- Example 3: With a `maxUnavailable` of 5, evictions are allowed as long as there are at most 5
-unhealthy replicas among the total number of desired replicas. -->
+<!--
+Example 3: With a `maxUnavailable` of 5, evictions are allowed as long as there are at most 5
+unhealthy replicas among the total number of desired replicas.
+-->
示例 3：设置 `maxUnavailable` 值为 5 的情况下，驱逐时需保证所需副本中最多 5 个处于不可用状态。
-Example 4: With a `maxUnavailable` of 30%, evictions are allowed as long as no more than 30%
+<!--
+Example 4: With a `maxUnavailable` of 30%, evictions are allowed as long as no more than 30%
of the desired replicas are unhealthy.
-示例4： 设置 `maxUnavailable` 值为 30% 的情况下，驱逐时需保证所需副本中最多 30% 处于不可用状态。
+-->
+示例 4：设置 `maxUnavailable` 值为 30% 的情况下，驱逐时需保证所需副本中最多 30% 处于不可用状态。
-<!-- In typical usage, a single budget would be used for a collection of pods managed by
-a controller—for example, the pods in a single ReplicaSet or StatefulSet. -->
-在典型用法中，中断预算会被用于一个控制器管理的一组 pod 中——例如：一个 ReplicaSet 或 StatefulSet 中的 pod。
+<!--
+In typical usage, a single budget would be used for a collection of pods managed by
+a controller—for example, the pods in a single ReplicaSet or StatefulSet.
+-->
+在典型用法中，干扰预算会被用于一个控制器管理的一组 Pod 中 —— 例如：一个 ReplicaSet 或 StatefulSet
+中的 Pod。
-{{< note >}}
-<!-- A disruption budget does not truly guarantee that the specified
+<!--
+A disruption budget does not truly guarantee that the specified
number/percentage of pods will always be up. For example, a node that hosts a
pod from the collection may fail when the collection is at the minimum size
specified in the budget, thus bringing the number of available pods from the
collection below the specified size. The budget can only protect against
-voluntary evictions, not all causes of unavailability. -->
-注意：中断预算并不能真正保证指定数量/百分比的 pod 一直处于运行状态。例如： 当 pod 集合的
-规模处于预算指定的最小值时，承载集合中某个 pod 的节点发生了故障，这样就导致集合中可用 pod 的
-数量低于预算指定值。预算只能够针对自发的驱逐提供保护，而不能针对所有 pod 不可用的诱因。
+voluntary evictions, not all causes of unavailability.
+-->
+{{< note >}}
+干扰预算并不能真正保证指定数量/百分比的 Pod 一直处于运行状态。例如： 当 Pod 集合的
+规模处于预算指定的最小值时，承载集合中某个 Pod 的节点发生了故障，这样就导致集合中可用 Pod 的
+数量低于预算指定值。预算只能够针对自发的驱逐提供保护，而不能针对所有 Pod 不可用的诱因。
{{< /note >}}
-<!-- A `maxUnavailable` of 0% (or 0) or a `minAvailable` of 100% (or equal to the
-number of replicas) may block node drains entirely. This is permitted as per the
-semantics of `PodDisruptionBudget`. -->
-设置 `maxUnavailable` 值为 0% （或 0 ）或设置 `minAvailable` 值为 100% （或等于副本数） 可能会
-阻塞节点，导致资源耗尽。按照 `PodDisruptionBudget` 的语义，这是允许的。
+<!--
+A `maxUnavailable` of 0% (or 0) or a `minAvailable` of 100% (or equal to the
+number of replicas) may block node drains entirely. This is permitted as per the
+semantics of `PodDisruptionBudget`.
+-->
+设置 `maxUnavailable` 值为 0%（或 0）或设置 `minAvailable` 值为 100%（或等于副本数）
+可能会阻塞节点，导致资源耗尽。按照 `PodDisruptionBudget` 的语义，这是允许的。
-<!-- You can find examples of pod disruption budgets defined below. They match pods with the label
-`app: zookeeper`. -->
-用户可以在下面看到 pod 中断预算定义的示例，它们与带有 `app: zookeeper` 标签的 pod 相匹配：
+<!--
+You can find examples of pod disruption budgets defined below. They match pods with the label
+`app: zookeeper`.
+-->
+用户可以在下面看到 pod 干扰预算定义的示例，它们与带有 `app: zookeeper` 标签的 pod 相匹配：
-<!-- Example PDB Using minAvailable: -->
+<!--
+Example PDB Using minAvailable:
+-->
使用 minAvailable 的PDB 示例：
{{< codenew file="policy/zookeeper-pod-disruption-budget-minavailable.yaml" >}}
-<!-- Example PDB Using maxUnavailable (Kubernetes 1.7 or higher): -->
+<!--
+Example PDB Using maxUnavailable (Kubernetes 1.7 or higher):
+-->
使用 maxUnavailable 的 PDB 示例（Kubernetes 1.7 或更高的版本）：
{{< codenew file="policy/zookeeper-pod-disruption-budget-maxunavailable.yaml" >}}
-<!-- For example, if the above `zk-pdb` object selects the pods of a StatefulSet of size 3, both
+<!--
+For example, if the above `zk-pdb` object selects the pods of a StatefulSet of size 3, both
specifications have the exact same meaning. The use of `maxUnavailable` is recommended as it
-automatically responds to changes in the number of replicas of the corresponding controller. -->
-例如，如果上述 `zk-pdb` 选择的是一个规格为 3 的 StatefulSet 对应的 pod，那么上面两种规范的含义完全相同。
+automatically responds to changes in the number of replicas of the corresponding controller.
+-->
+例如，如果上述 `zk-pdb` 选择的是一个规格为 3 的 StatefulSet 对应的 Pod，
+那么上面两种规范的含义完全相同。
推荐使用 `maxUnavailable` ，因为它自动响应控制器副本数量的变化。
+<!--
## Create the PDB object
+
+You can create the PDB object with a command like `kubectl apply -f mypdb.yaml`.
+-->
## 创建 PDB 对象
-<!-- You can create the PDB object with a command like `kubectl apply -f mypdb.yaml`. -->
-用户可以通过类似 `kubectl create -f mypdb.yaml` 的命令来创建 PDB。
+你可以通过类似 `kubectl apply -f mypdb.yaml` 的命令来创建 PDB。
-<!-- You cannot update PDB objects. They must be deleted and re-created. -->
+<!--
+You cannot update PDB objects. They must be deleted and re-created.
+-->
PDB 对象无法更新，必须删除后重新创建。
+<!--
## Check the status of the PDB
+
+Use kubectl to check that your PDB is created.
+-->
## 检查 PDB 的状态
-<!-- Use kubectl to check that your PDB is created. -->
使用 kubectl 来确认 PDB 被创建。
-<!-- Assuming you don't actually have pods matching `app: zookeeper` in your namespace,
-then you'll see something like this: -->
-假设用户的名字空间下没有匹配 `app: zookeeper` 的 pod，用户会看到类似下面的信息：
+<!--
+Assuming you don't actually have pods matching `app: zookeeper` in your namespace,
+then you'll see something like this:
+-->
+假设用户的名字空间下没有匹配 `app: zookeeper` 的 Pod，用户会看到类似下面的信息：
```shell
kubectl get poddisruptionbudgets
```
```
-NAME MIN-AVAILABLE ALLOWED-DISRUPTIONS AGE
-zk-pdb 2 0 7s
+NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE
+zk-pdb 2 N/A 0 7s
```
-<!-- If there are matching pods (say, 3), then you would see something like this: -->
-假设有匹配的 pod (比如说 3 个), 那么用户会看到类似下面的信息：
+<!--
+If there are matching pods (say, 3), then you would see something like this:
+-->
+假设有匹配的 Pod (比如说 3 个), 那么用户会看到类似下面的信息：
```shell
kubectl get poddisruptionbudgets
```
```
-NAME MIN-AVAILABLE ALLOWED-DISRUPTIONS AGE
-zk-pdb 2 1 7s
+NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE
+zk-pdb 2 N/A 1 7s
+
```
-<!-- The non-zero value for `ALLOWED-DISRUPTIONS` means that the disruption controller has seen the pods,
-counted the matching pods, and updated the status of the PDB. -->
-`ALLOWED-DISRUPTIONS` 值非 0 意味着中断控制器已经感知到相应的 pod， 对匹配的 pod 进行统计，并更新了 PDB 的状态。
+<!--
+The non-zero value for `ALLOWED-DISRUPTIONS` means that the disruption controller has seen the pods,
+counted the matching pods, and updated the status of the PDB.
+
+You can get more information about the status of a PDB with this command:
+-->
+`ALLOWED-DISRUPTIONS` 值非 0 意味着干扰控制器已经感知到相应的 Pod，对匹配的 Pod 进行统计，
+并更新了 PDB 的状态。
-<!-- You can get more information about the status of a PDB with this command: -->
用户可以通过以下命令获取更多 PDB 状态相关信息：
```shell
kubectl get poddisruptionbudgets zk-pdb -o yaml
```
+
```yaml
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
- creationTimestamp: 2017-08-28T02:38:26Z
+ anntation: {}
+ creationTimestamp: "2020-03-04T04:22:56Z"
generation: 1
name: zk-pdb
…
status:
currentHealthy: 3
- desiredHealthy: 3
- disruptedPods: null
+ desiredHealthy: 2
disruptionsAllowed: 1
expectedPods: 3
observedGeneration: 1
```
-<!-- ## Arbitrary Controllers and Selectors -->
-## 任意控制器和选择器
+<!--
+## Arbitrary Controllers and Selectors
-<!-- You can skip this section if you only use PDBs with the built-in
+You can skip this section if you only use PDBs with the built-in
application controllers (Deployment, ReplicationController, ReplicaSet, and StatefulSet),
-with the PDB selector matching the controller's selector. -->
-如果用户只使用与内置的应用控制器（Deployment、ReplicationController、ReplicaSet 和 StatefulSet）
-对应的 PDB，也就是 PDB 的选择器与 控制器的选择器相匹配，那么可以跳过这一节。
+with the PDB selector matching the controller's selector.
+-->
+## 任意控制器和选择算符 {#arbitrary-controllers-and-selectors}
-<!-- You can use a PDB with pods controlled by another type of controller, by an
-"operator", or bare pods, but with these restrictions: -->
-用户可以使用这样的 PDB：它对应的 pod 可能由其他类型的控制器控制，可能由 "operator" 控制，
-也可能为“裸的（不受控制器控制）” pod，但该类 PDB 存在以下限制：
+如果你只使用与内置的应用控制器（Deployment、ReplicationController、ReplicaSet 和 StatefulSet）
+对应的 PDB，也就是 PDB 的选择算符与 控制器的选择算符相匹配，那么可以跳过这一节。
+<!--
+You can use a PDB with pods controlled by another type of controller, by an
+"operator", or bare pods, but with these restrictions:
+-->
+你可以使用这样的 PDB：它对应的 Pod 可能由其他类型的控制器控制，可能由 "operator" 控制，
+也可能为“裸的（不受控制器控制）” Pod，但该类 PDB 存在以下限制：
+
+<!--
- only `.spec.minAvailable` can be used, not `.spec.maxUnavailable`.
- only an integer value can be used with `.spec.minAvailable`, not a percentage.
+-->
- 只能够使用 `.spec.minAvailable` ，而不能够使用 `.spec.maxUnavailable。`
- 只能够使用整数作为 `.spec.minAvailable` 的值，而不能使用百分比。
-<!-- You can use a selector which selects a subset or superset of the pods belonging to a built-in
+<!--
+You can use a selector which selects a subset or superset of the pods belonging to a built-in
controller. However, when there are multiple PDBs in a namespace, you must be careful not
-to create PDBs whose selectors overlap. -->
-用户可以令选择器选择一个内置控制器所控制 pod 的子集或父集。然而，当名字空间下存在多个 PDB 时，
-用户必须小心，保证 PDB 的选择器之间不重叠。
-
-
+to create PDBs whose selectors overlap.
+-->
+你可以令选择算符选择一个内置控制器所控制 Pod 的子集或父集。
+然而，当名字空间下存在多个 PDB 时，用户必须小心，保证 PDB 的选择算符之间不重叠。
diff --git a/content/zh/docs/tasks/run-application/delete-stateful-set.md b/content/zh/docs/tasks/run-application/delete-stateful-set.md
index 92c35c7ded..e1dbe5b946 100644
--- a/content/zh/docs/tasks/run-application/delete-stateful-set.md
+++ b/content/zh/docs/tasks/run-application/delete-stateful-set.md
@@ -1,66 +1,76 @@
---
+title: 删除 StatefulSet
+content_type: task
+weight: 60
+---
+
+<!--
reviewers:
- bprashanth
- erictune
- foxish
- janetkuo
- smarterclayton
-title: 删除 StatefulSet
+title: Delete a StatefulSet
content_type: task
weight: 60
----
+-->
<!-- overview -->
<!--
This task shows you how to delete a StatefulSet.
--->
-本文介绍如何删除 StatefulSet。
-
-
+本任务展示如何删除 StatefulSet。
## {{% heading "prerequisites" %}}
-
<!--
* This task assumes you have an application running on your cluster represented by a StatefulSet.
--->
-* 本文假设在您的集群上已经运行了由 StatefulSet 创建的应用。
-
-
+* 本任务假设在你的集群上已经运行了由 StatefulSet 创建的应用。
<!-- steps -->
-## 删除 StatefulSet
+## 删除 StatefulSet {#deleting-a-statefulset}
<!--
You can delete a StatefulSet in the same way you delete other resources in Kubernetes: use the `kubectl delete` command, and specify the StatefulSet either by file or by name.
--->
-您可以像删除 Kubernetes 中的其他资源一样删除 StatefulSet：使用 `kubectl delete` 命令，并按文件或者名字指定 StatefulSet。
+你可以像删除 Kubernetes 中的其他资源一样删除 StatefulSet：使用 `kubectl delete` 命令，并按文件或者名字指定 StatefulSet。
```shell
kubectl delete -f <file.yaml>
```
+<!--
```shell
kubectl delete statefulsets <statefulset-name>
```
+-->
+```shell
+kubectl delete statefulsets <statefulset 名称>
+```
<!--
You may need to delete the associated headless service separately after the StatefulSet itself is deleted.
---->
-删除 StatefulSet 之后，您可能需要单独删除关联的无头服务。
```shell
kubectl delete service <service-name>
```
+-->
+删除 StatefulSet 之后，你可能需要单独删除关联的无头服务。
+
+```shell
+kubectl delete service <服务名称>
+```
<!--
Deleting a StatefulSet through kubectl will scale it down to 0, thereby deleting all pods that are a part of it.
If you want to delete just the StatefulSet and not the pods, use `--cascade=false`.
--->
-通过 kubectl 删除 StatefulSet 会将其缩容为0，因此删除属于它的所有pods。
-如果您只想删除 StatefulSet 而不删除 pods，使用 `--cascade=false`。
+通过 `kubectl` 删除 StatefulSet 会将其缩容为 0，因此删除属于它的所有 Pod。
+如果你只想删除 StatefulSet 而不删除 Pod，使用 `--cascade=false`。
```shell
kubectl delete -f <file.yaml> --cascade=false
@@ -69,67 +79,72 @@ kubectl delete -f <file.yaml> --cascade=false
<!--
By passing `--cascade=false` to `kubectl delete`, the Pods managed by the StatefulSet are left behind even after the StatefulSet object itself is deleted. If the pods have a label `app=myapp`, you can then delete them as follows:
--->
-通过将 `--cascade=false` 传递给 `kubectl delete`，在删除 StatefulSet 对象之后，StatefulSet 管理的 pods 会被保留下来。如果 pods 有一个标签 `app=myapp`，则可以按照如下方式删除它们：
+通过将 `--cascade=false` 传递给 `kubectl delete`，在删除 StatefulSet 对象之后，
+StatefulSet 管理的 Pod 会被保留下来。如果 Pod 具有标签 `app=myapp`，则可以按照
+如下方式删除它们：
```shell
kubectl delete pods -l app=myapp
```
+
+<!--
### Persistent Volumes
-<!--
Deleting the Pods in a StatefulSet will not delete the associated volumes. This is to ensure that you have the chance to copy data off the volume before deleting it. Deleting the PVC after the pods have left the [terminating state](/docs/concepts/workloads/pods/pod/#termination-of-pods) might trigger deletion of the backing Persistent Volumes depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion.
---->
-删除 StatefulSet 管理的 pods 并不会删除关联的卷。这是为了确保您有机会在删除卷之前从卷中复制数据。在pods离开[终止状态](/docs/concepts/workloads/pods/pod/#termination-of-pods)后删除 PVC 可能会触发删除支持的 Persistent Volumes，具体取决于存储类和回收策略。声明删除后，您永远不应该假设能够访问卷。
+-->
+### 持久卷 {#persistent-volumes}
+
+删除 StatefulSet 管理的 Pod 并不会删除关联的卷。这是为了确保你有机会在删除卷之前从卷中复制数据。
+在 Pod 离开[终止状态](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
+后删除 PVC 可能会触发删除背后的 PV 持久卷，具体取决于存储类和回收策略。
+永远不要假定在 PVC 删除后仍然能够访问卷。
<!--
-**Note: Use caution when deleting a PVC, as it may lead to data loss.**
---->
-**注意：删除 PVC 时要谨慎，因为这可能会导致数据丢失。**
+Use caution when deleting a PVC, as it may lead to data loss.
+-->
+{{< note >}}
+删除 PVC 时要谨慎，因为这可能会导致数据丢失。
+{{< /note >}}
<!--
### Complete deletion of a StatefulSet
---->
-### 完全删除 StatefulSet
-<!--
To simply delete everything in a StatefulSet, including the associated pods, you can run a series of commands similar to the following:
---->
-要简单地删除 StatefulSet 中的所有内容，包括关联的 pods，您可能需要运行一系列类似于以下内容的命令：
+-->
+### 完全删除 StatefulSet {#complete-deletion-of-a-statefulset}
+
+要简单地删除 StatefulSet 中的所有内容，包括关联的 pods，你可能需要运行一系列类似于以下内容的命令：
```shell
grace=$(kubectl get pods <stateful-set-pod> --template '{{.spec.terminationGracePeriodSeconds}}')
kubectl delete statefulset -l app=myapp
sleep $grace
kubectl delete pvc -l app=myapp
-
```
<!--
In the example above, the Pods have the label `app=myapp`; substitute your own label as appropriate.
---->
-在上面的例子中，pods 的标签为 `app=myapp`；适当地替换您自己的标签。
+-->
+在上面的例子中，Pod 的标签为 `app=myapp`；适当地替换你自己的标签。
<!--
### Force deletion of StatefulSet pods
---->
-### 强制删除 StatefulSet 类型的 pods
-<!--
If you find that some pods in your StatefulSet are stuck in the 'Terminating' or 'Unknown' states for an extended period of time, you may need to manually intervene to forcefully delete the pods from the apiserver. This is a potentially dangerous task. Refer to [Deleting StatefulSet Pods](/docs/tasks/manage-stateful-set/delete-pods/) for details.
---->
-如果您发现 StatefulSet 中的某些 pods 长时间处于 'Terminating' 或者 'Unknown' 状态，则可能需要手动干预以强制从 apiserver 中删除 pods。这是一项潜在的危险任务。详细信息请阅读[删除 StatefulSet 类型的 Pods](/docs/tasks/manage-stateful-set/delete-pods/)。
-
+-->
+### 强制删除 StatefulSet 的 Pod
+如果你发现 StatefulSet 的某些 Pod 长时间处于 'Terminating' 或者 'Unknown' 状态，
+则可能需要手动干预以强制从 API 服务器中删除这些 Pod。
+这是一项有点危险的任务。详细信息请阅读
+[删除 StatefulSet 类型的 Pods](/zh/docs/tasks/run-application/delete-stateful-set/）。
## {{% heading "whatsnext" %}}
-
<!--
Learn more about [force deleting StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/).
--->
-了解更多有关[强制删除 StatefulSet 类型的 Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/)。
-
-
+进一步了解[强制删除 StatefulSet 的 Pods](/zh/docs/tasks/run-application/force-delete-stateful-set-pod/)。
diff --git a/content/zh/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/zh/docs/tasks/run-application/force-delete-stateful-set-pod.md
index 3a401d617a..c2e678d93c 100644
--- a/content/zh/docs/tasks/run-application/force-delete-stateful-set-pod.md
+++ b/content/zh/docs/tasks/run-application/force-delete-stateful-set-pod.md
@@ -1,16 +1,10 @@
---
-reviewers:
-- bprashanth
-- erictune
-- foxish
-- smarterclayton
title: 强制删除 StatefulSet 类型的 Pods
content_type: task
weight: 70
---
<!--
----
reviewers:
- bprashanth
- erictune
@@ -19,54 +13,55 @@ reviewers:
title: Force Delete StatefulSet Pods
content_type: task
weight: 70
----
---->
+-->
<!-- overview -->
<!--
-This page shows how to delete Pods which are part of a stateful set, and explains the considerations to keep in mind when doing so.
---->
-本文介绍了如何删除 StatefulSet 管理的部分 pods，并且解释了这样操作时需要记住的注意事项。
-
+This page shows how to delete Pods which are part of a {{< glossary_tooltip text="stateful set" term_id="StatefulSet" >}}, and explains the considerations to keep in mind when doing so.
+-->
+本文介绍了如何删除 {{< glossary_tooltip text="StatefulSet" term_id="StatefulSet" >}}
+管理的 Pods，并且解释了这样操作时需要记住的注意事项。
## {{% heading "prerequisites" %}}
-
<!--
* This is a fairly advanced task and has the potential to violate some of the properties inherent to StatefulSet.
* Before proceeding, make yourself familiar with the considerations enumerated below.
---->
+-->
* 这是一项相当高级的任务，并且可能会违反 StatefulSet 固有的某些属性。
* 继续任务之前，请熟悉下面列举的注意事项。
-
-
<!-- steps -->
<!--
## StatefulSet considerations
---->
+
+In normal operation of a StatefulSet, there is **never** a need to force delete a StatefulSet Pod. The [StatefulSet controller](/docs/concepts/workloads/controllers/statefulset/) is responsible for creating, scaling and deleting members of the StatefulSet. It tries to ensure that the specified number of Pods from ordinal 0 through N-1 are alive and ready. StatefulSet ensures that, at any time, there is at most one Pod with a given identity running in a cluster. This is referred to as *at most one* semantics provided by a StatefulSet.
+-->
## StatefulSet 注意事项
-<!--
-In normal operation of a StatefulSet, there is **never** a need to force delete a StatefulSet Pod. The StatefulSet controller is responsible for creating, scaling and deleting members of the StatefulSet. It tries to ensure that the specified number of Pods from ordinal 0 through N-1 are alive and ready. StatefulSet ensures that, at any time, there is at most one Pod with a given identity running in a cluster. This is referred to as *at most one* semantics provided by a StatefulSet.
---->
-在 StatefulSet 的正常操作中，**永远不**需要强制删除 StatefulSet 管理的 pod。StatefulSet 控制器负责创建，扩容和删除 StatefulSet 管理的 pods。它尝试确保从序号 0 到 N-1 指定数量的 pods 处于活动状态并准备就绪。StatefulSet 确保在任何时候，集群中最多只有一个具有给定标识的 pod。这就是所谓的由 StatefulSet 提供的*最多一个*的语义。
+在 StatefulSet 的正常操作中，**永远不**需要强制删除 StatefulSet 管理的 Pod。
+[StatefulSet 控制器](/zh/docs/concepts/workloads/controllers/statefulset/)负责创建、
+扩缩和删除 StatefulSet 管理的 Pods。它尝试确保指定数量的从序数 0 到 N-1 的 Pod
+处于活跃状态并准备就绪。StatefulSet 确保在任何时候，集群中最多只有一个具有给定标识的 Pod。
+这就是所谓的由 StatefulSet 提供的*最多一个（At Most One）*的语义。
<!--
Manual force deletion should be undertaken with caution, as it has the potential to violate the at most one semantics inherent to StatefulSet. StatefulSets may be used to run distributed and clustered applications which have a need for a stable network identity and stable storage. These applications often have configuration which relies on an ensemble of a fixed number of members with fixed identities. Having multiple members with the same identity can be disastrous and may lead to data loss (e.g. split brain scenario in quorum-based systems).
---->
-应谨慎进行手动强制删除操作，因为它可能会违反 StatefulSet 固有的至多一个的语义。StatefulSets 可用于运行分布式和集群级的应用，这些应用需要稳定的网络标识和可靠的存储。这些应用通常配置为具有固定标识固定数量的成员集合。具有相同身份的多个成员可能是灾难性的，并且可能导致数据丢失 (e.g. 基于 quorum 系统中的脑裂场景)。
+-->
+应谨慎进行手动强制删除操作，因为它可能会违反 StatefulSet 固有的至多一个的语义。
+StatefulSets 可用于运行分布式和集群级的应用，这些应用需要稳定的网络标识和可靠的存储。
+这些应用通常配置为具有固定标识固定数量的成员集合。
+具有相同身份的多个成员可能是灾难性的，并且可能导致数据丢失 (例如：票选系统中的脑裂场景)。
<!--
## Delete Pods
---->
-## 删除 Pods
-<!--
You can perform a graceful pod deletion with the following command:
---->
-您可以使用下面的命令执行优雅地删除 pod:
+-->
+## 删除 Pods {#delete-pods}
+
+你可以使用下面的命令执行体面地删除 Pod:
```shell
kubectl delete pods <pod>
@@ -74,52 +69,69 @@ kubectl delete pods <pod>
<!--
For the above to lead to graceful termination, the Pod **must not** specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. The practice of setting a `pod.Spec.TerminationGracePeriodSeconds` of 0 seconds is unsafe and strongly discouraged for StatefulSet Pods. Graceful deletion is safe and will ensure that the [Pod shuts down gracefully](/docs/user-guide/pods/#termination-of-pods) before the kubelet deletes the name from the apiserver.
---->
-为了使上面的方法能够正常终止，Pod **一定不能**设置 `pod.Spec.TerminationGracePeriodSeconds` 为 0。将 `pod.Spec.TerminationGracePeriodSeconds` 设置为 0s 的做法是不安全的，强烈建议 StatefulSet 类型的 pods 不要使用。优雅删除是安全的，并且会在 kubelet 从 apiserver 中删除名称之前确保 [优雅地关闭 pod ](/docs/user-guide/pods/#termination-of-pods)。
+-->
+为了让上面操作能够体面地终止 Pod，Pod **一定不能** 设置 `pod.Spec.TerminationGracePeriodSeconds` 为 0。
+将 `pod.Spec.TerminationGracePeriodSeconds` 设置为 0s 的做法是不安全的，强烈建议 StatefulSet 类型的
+Pod 不要使用。体面删除是安全的，并且会在 kubelet 从 API 服务器中删除资源名称之前确保
+[体面地结束 pod ](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。
<!--
Kubernetes (versions 1.5 or newer) will not delete Pods just because a Node is unreachable. The Pods running on an unreachable Node enter the 'Terminating' or 'Unknown' state after a [timeout](/docs/admin/node/#node-condition). Pods may also enter these states when the user attempts graceful deletion of a Pod on an unreachable Node. The only ways in which a Pod in such a state can be removed from the apiserver are as follows:
---->
-Kubernetes (1.5 版本或者更新版本)不会因为一个 Node 无法访问而删除 pods。在无法访问节点上运行的 pods 在[超时](/docs/admin/node/#node-condition)后会进入'Terminating' 或者 'Unknown' 状态。当用户尝试优雅删除无法访问节点上的 pod 时，pods 也可能会进入这些状态。从 apiserver 中删除处于这些状态 pod 的唯一方法如下：
+-->
+Kubernetes（1.5 版本或者更新版本）不会因为一个节点无法访问而删除 Pod。
+在无法访问的节点上运行的 Pod 在
+[超时](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-condition)
+后会进入'Terminating' 或者 'Unknown' 状态。
+当用户尝试体面地删除无法访问的节点上的 Pod 时 Pod 也可能会进入这些状态。
+从 API 服务器上删除处于这些状态 Pod 的仅有可行方法如下：
<!--
* The Node object is deleted (either by you, or by the [Node Controller](/docs/admin/node)).<br/>
* The kubelet on the unresponsive Node starts responding, kills the Pod and removes the entry from the apiserver.<br/>
* Force deletion of the Pod by the user.
---->
- * Node 对象被删除(要么您删除, 或者[Node Controller](/docs/admin/node))。<br/>
- * 无响应节点上的 kubelet 开始响应，杀死 pod 并从 apiserver 中移除该条目。<br/>
- * 用户强制删除 pod。
+-->
+* 删除 Node 对象（要么你来删除, 要么[节点控制器](/zh/docs/concepts/architecture/nodes/#node-controller)
+ 来删除）
+* 无响应节点上的 kubelet 开始响应，杀死 Pod 并从 API 服务器上移除 Pod 对象
+* 用户强制删除 pod
<!--
The recommended best practice is to use the first or second approach. If a Node is confirmed to be dead (e.g. permanently disconnected from the network, powered down, etc), then delete the Node object. If the Node is suffering from a network partition, then try to resolve this or wait for it to resolve. When the partition heals, the kubelet will complete the deletion of the Pod and free up its name in the apiserver.
---->
-推荐使用第一种或者第二种方法。如果确认节点已经不可用了 (比如，永久断开网络，断电等)，则删除 Node 对象。如果节点遇到网裂，请尝试解决该问题或者等待其解决。当网裂愈合时，kubelet 将完成 pod 的删除并从 apiserver 中释放其名字。
+-->
+推荐使用第一种或者第二种方法。如果确认节点已经不可用了 (比如，永久断开网络、断电等)，
+则应删除 Node 对象。
+如果节点遇到网裂问题，请尝试解决该问题或者等待其解决。
+当网裂愈合时，kubelet 将完成 Pod 的删除并从 API 服务器上释放其名字。
<!--
Normally, the system completes the deletion once the Pod is no longer running on a Node, or the Node is deleted by an administrator. You may override this by force deleting the Pod.
---->
-通常，pod 一旦不在节点上运行，或者管理员删除了节点，系统就会完成删除。你可以通过强制删除 pod 来覆盖它。
+-->
+通常，Pod 一旦不在节点上运行，或者管理员删除了节点，系统就会完成其删除动作。
+你也可以通过强制删除 Pod 来绕过这一机制。
<!--
### Force Deletion
---->
-### 强制删除
-<!--
Force deletions **do not** wait for confirmation from the kubelet that the Pod has been terminated. Irrespective of whether a force deletion is successful in killing a Pod, it will immediately free up the name from the apiserver. This would let the StatefulSet controller create a replacement Pod with that same identity; this can lead to the duplication of a still-running Pod, and if said Pod can still communicate with the other members of the StatefulSet, will violate the at most one semantics that StatefulSet is designed to guarantee.
---->
-强制删除**不要**等待来自 kubelet 的确认 pod 已被终止。无论强制删除是否成功杀死了 pod，它都会立即从 apiserver 中释放该名字。这将让 StatefulSet 控制器创建一个具有相同标识的替换 pod；这可能导致正在运行 pod 的重复，并且如果所述 pod 仍然可以与 StatefulSet 的成员通信，则将违反 StatefulSet 旨在保证的最多一个的语义。
+-->
+### 强制删除 {#force-deletion}
+
+强制删除**不会**等待来自 kubelet 对 Pod 已终止的确认消息。
+无论强制删除是否成功杀死了 Pod，它都会立即从 API 服务器中释放该名字。
+这将让 StatefulSet 控制器创建一个具有相同标识的替身 Pod；因而可能导致正在运行 Pod 的重复，
+并且如果所述 Pod 仍然可以与 StatefulSet 的成员通信，则将违反 StatefulSet 所要保证的
+最多一个的语义。
<!--
When you force delete a StatefulSet pod, you are asserting that the Pod in question will never again make contact with other Pods in the StatefulSet and its name can be safely freed up for a replacement to be created.
---->
-当你强制删除 StatefulSet 类型的 pod 时，你要确保有问题的 pod 不会再和 StatefulSet 管理的其他 pods通信，并且可以安全地释放其名字以便创建替换 pod。
+-->
+当你强制删除 StatefulSet 类型的 Pod 时，你要确保有问题的 Pod 不会再和 StatefulSet 管理的其他
+Pod 通信并且可以安全地释放其名字以便创建替代 Pod。
<!--
If you want to delete a Pod forcibly using kubectl version >= 1.5, do the following:
---->
-如果要使用 kubectl version >= 1.5 强制删除 pod，请执行下面命令：
+-->
+如果要使用 kubectl 1.5 以上版本强制删除 Pod，请执行下面命令：
```shell
kubectl delete pods <pod> --grace-period=0 --force
@@ -127,16 +139,17 @@ kubectl delete pods <pod> --grace-period=0 --force
<!--
If you're using any version of kubectl <= 1.4, you should omit the `--force` option and use:
---->
-如果您使用 kubectl <= 1.4 的任何版本，则应省略 `--force` 选项：
+-->
+如果你使用 kubectl 的 1.4 以下版本，则应省略 `--force` 选项：
```shell
kubectl delete pods <pod> --grace-period=0
```
+
<!--
If even after these commands the pod is stuck on `Unknown` state, use the following command to remove the pod from the cluster:
---->
-如果在这些命令后 pod 仍处于`Unknown`状态，请使用以下命令从集群中删除 pod:
+-->
+如果在这些命令后 Pod 仍处于 `Unknown` 状态，请使用以下命令从集群中删除 Pod:
```shell
kubectl patch pod <pod> -p '{"metadata":{"finalizers":null}}'
@@ -144,17 +157,15 @@ kubectl patch pod <pod> -p '{"metadata":{"finalizers":null}}'
<!--
Always perform force deletion of StatefulSet Pods carefully and with complete knowledge of the risks involved.
---->
+-->
请始终谨慎地执行强制删除 StatefulSet 类型的 pods，并完全了解所涉及地风险。
-
## {{% heading "whatsnext" %}}
-
<!--
Learn more about [debugging a StatefulSet](/docs/tasks/debug-application-cluster/debug-stateful-set/).
---->
-进一步了解[调试 StatefulSet](/docs/tasks/debug-application-cluster/debug-stateful-set/)。
+-->
+进一步了解[调试 StatefulSet](/zh/docs/tasks/debug-application-cluster/debug-stateful-set/)。
diff --git a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
index 58ee1d72a2..1dd802ae11 100644
--- a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+++ b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
@@ -1,13 +1,19 @@
---
+title: Horizontal Pod Autoscaler 演练
+content_type: task
+weight: 100
+---
+
+<!--
reviewers:
- fgrzadkowski
- jszczepkowski
- justinsb
- directxman12
-title: Horizontal Pod Autoscaler演练
+title: Horizontal Pod Autoscaler Walkthrough
content_type: task
weight: 100
----
+-->
<!-- overview -->
@@ -16,32 +22,30 @@ Horizontal Pod Autoscaler automatically scales the number of pods
in a replication controller, deployment or replica set based on observed CPU utilization
(or, with beta support, on some other, application-provided metrics).
-->
-Horizontal Pod Autoscaler 可以根据CPU利用率自动伸缩 replication controller、deployment 或者 replica set 中的Pod数量
+Horizontal Pod Autoscaler 可以根据 CPU 利用率自动扩缩 ReplicationController、Deployment 或者 ReplicaSet 中的 Pod 数量
（也可以基于其他应用程序提供的度量指标，目前这一功能处于 beta 版本）。
<!--
This document walks you through an example of enabling Horizontal Pod Autoscaler for the php-apache server. For more information on how Horizontal Pod Autoscaler behaves, see the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/).
-->
-本文将引导您了解如何为 php-apache 服务器配置和使用 Horizontal Pod Autoscaler。
-更多 Horizontal Pod Autoscaler 的信息请参阅 [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/)。
-
-
-
-
+本文将引领你了解如何为 php-apache 服务器配置和使用 Horizontal Pod Autoscaler。
+更多 Horizontal Pod Autoscaler 的信息请参阅
+[Horizontal Pod Autoscaler 用户指南](/zh/docs/tasks/run-application/horizontal-pod-autoscale/)。
## {{% heading "prerequisites" %}}
-
<!--
This example requires a running Kubernetes cluster and kubectl, version 1.2 or later.
[metrics-server](https://github.com/kubernetes-incubator/metrics-server/) monitoring needs to be deployed in the cluster
to provide metrics via the resource metrics API, as Horizontal Pod Autoscaler uses this API to collect metrics. The instructions for deploying this are on the GitHub repository of [metrics-server](https://github.com/kubernetes-incubator/metrics-server/), if you followed [getting started on GCE guide](/docs/setup/production-environment/turnkey/gce/),
metrics-server monitoring will be turned-on by default.
-->
-本文示例需要一个1.2或者更高版本的可运行的 Kubernetes 集群以及 kubectl。
-[metrics-server](https://github.com/kubernetes-incubator/metrics-server/) 也需要部署到集群中，
-它可以通过 resource metrics API 对外提供度量数据，Horizontal Pod Autoscaler 正是根据此 API 来获取度量数据，部署方法请参考 [metrics-server](https://github.com/kubernetes-incubator/metrics-server/) 。
-如果你正在使用GCE，按照 [getting started on GCE guide](/docs/setup/production-environment/turnkey/gce/) 操作，metrics-server 会默认启动。
+本文示例需要一个运行中的 Kubernetes 集群以及 kubectl，集群中还要部署 1.2 或更高
+版本的 [Metrics 服务器](https://github.com/kubernetes-incubator/metrics-server/)。
+Metrics 服务器可以通过资源度量值 API 对外提供度量数据，Horizontal Pod Autoscaler
+正是根据此 API 来获取度量数据。
+部署方法请参考 [metrics-server](https://github.com/kubernetes-incubator/metrics-server/) 。
+如果你正在使用 GCE，按照 [GCE 指南中的入门说明](/zh/docs/setup/production-environment/turnkey/gce/) 操作，metrics-server 会默认启动。
<!--
To specify multiple resource metrics for a Horizontal Pod Autoscaler, you must have a Kubernetes cluster
@@ -51,36 +55,36 @@ not related to any Kubernetes object you must have a Kubernetes cluster at versi
you must be able to communicate with the API server that provides the external metrics API.
See the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) for more details.
-->
-如果需要为 Horizontal Pod Autoscaler 指定多种资源度量指标，您的 Kubernetes 集群以及 kubectl 至少需要达到1.6版本。
-此外，如果要使用自定义度量指标，您的Kubernetes 集群还必须能够与提供这些自定义指标的API服务器通信。
-最后，如果要使用与 Kubernetes 对象无关的度量指标，则 Kubernetes 集群版本至少需要达到1.10版本，同样，需要保证集群能够与提供这些外部指标的API服务器通信。
-更多详细信息，请参阅[Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics)。
-
-
+如果需要为 Horizontal Pod Autoscaler 指定多种资源度量指标，你的 Kubernetes 集群以及 kubectl 至少需要达到 1.6 版本。
+此外，如果要使用自定义度量指标，你的 Kubernetes 集群还必须能够与提供这些自定义指标
+的 API 服务器通信。
+最后，如果要使用与 Kubernetes 对象无关的度量指标，则 Kubernetes 集群版本至少需要
+达到 1.10 版本，同样，需要保证集群能够与提供这些外部指标的 API 服务器通信。
+更多详细信息，请参阅[Horizontal Pod Autoscaler 用户指南](/zh/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics)。
<!-- steps -->
<!--
## Run & expose php-apache server
-->
-## 第一步：运行 php-apache 服务器并暴露服务
+## 运行 php-apache 服务器并暴露服务
<!--
To demonstrate Horizontal Pod Autoscaler we will use a custom docker image based on the php-apache image.
The Dockerfile has the following content:
-->
-为了演示 Horizontal Pod Autoscaler，我们将使用一个基于 php-apache 镜像的定制 Docker 镜像。
-Dockerfile 内容如下：
+为了演示 Horizontal Pod Autoscaler，我们将使用一个基于 php-apache 镜像的定制 Docker 镜像。 Dockerfile 内容如下：
```
FROM php:5-apache
COPY index.php /var/www/html/index.php
RUN chmod a+rx index.php
```
+
<!--
It defines an index.php page which performs some CPU intensive computations:
-->
-它定义一个 index.php 页面来执行一些 CPU 密集型计算：
+该文件定义了一个 index.php 页面来执行一些 CPU 密集型计算：
```
<?php
@@ -91,14 +95,16 @@ It defines an index.php page which performs some CPU intensive computations:
echo "OK!";
?>
```
+
<!--
First, we will start a deployment running the image and expose it as a service:
-->
-首先，我们先启动一个 deployment 来运行这个镜像并暴露一个服务:
+首先，我们先启动一个 Deployment 来运行这个镜像并暴露一个服务：
```shell
kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --expose --port=80
```
+
```
service/php-apache created
deployment.apps/php-apache created
@@ -106,10 +112,7 @@ deployment.apps/php-apache created
<!--
## Create Horizontal Pod Autoscaler
--->
-## 创建 Horizontal Pod Autoscaler
-<!--
Now that the server is running, we will create the autoscaler using
[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale).
The following command will create a Horizontal Pod Autoscaler that maintains between 1 and 10 replicas of the Pods
@@ -117,18 +120,23 @@ controlled by the php-apache deployment we created in the first step of these in
Roughly speaking, HPA will increase and decrease the number of replicas
(via the deployment) to maintain an average CPU utilization across all Pods of 50%
(since each pod requests 200 milli-cores by [kubectl run](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/docs/user-guide/kubectl/kubectl_run.md), this means average CPU usage of 100 milli-cores).
-See [here](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#autoscaling-algorithm) for more details on the algorithm.
+See [here](/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details) for more details on the algorithm.
-->
-现在，php-apache服务器已经运行，我们将通过 [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale) 命令创建 Horizontal Pod Autoscaler。
-以下命令将创建一个 Horizontal Pod Autoscaler 用于控制我们上一步骤中创建的 deployment，使 Pod 的副本数量在维持在1到10之间。
-大致来说，HPA 将通过增加或者减少 Pod 副本的数量（通过 Deployment ）以保持所有 Pod 的平均CPU利用率在50%以内
-（由于每个 Pod 通过 [kubectl run](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/docs/user-guide/kubectl/kubectl_run.md)
-申请了200 milli-cores CPU，所以50%的 CPU 利用率意味着平均 CPU 利用率为100 milli-cores）。
-相关算法的详情请参阅[here](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#autoscaling-algorithm)。
+## 创建 Horizontal Pod Autoscaler
+
+现在，php-apache 服务器已经运行，我们将通过
+[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale)
+命令创建 Horizontal Pod Autoscaler。
+以下命令将创建一个 Horizontal Pod Autoscaler 用于控制我们上一步骤中创建的
+Deployment，使 Pod 的副本数量维持在 1 到 10 之间。
+大致来说，HPA 将通过增加或者减少 Pod 副本的数量（通过 Deployment）以保持所有 Pod 的平均 CPU 利用率在 50% 以内（由于每个 Pod 通过 `kubectl run` 请求 200 毫核的 CPU）
+，这意味着平均 CPU 利用率为 100 毫核）。
+相关算法的详情请参阅[文档](/zh/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details)。
```shell
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
```
+
```
horizontalpodautoscaler.autoscaling/php-apache autoscaled
```
@@ -136,11 +144,12 @@ horizontalpodautoscaler.autoscaling/php-apache autoscaled
<!--
We may check the current status of autoscaler by running:
-->
-我们可以通过以下命令查看 autoscaler 的状态：
+我们可以通过以下命令查看 Autoscaler 的状态：
```shell
kubectl get hpa
```
+
```
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 18s
@@ -151,19 +160,18 @@ php-apache Deployment/php-apache/scale 0% / 50% 1 10 1
Please note that the current CPU consumption is 0% as we are not sending any requests to the server
(the ``CURRENT`` column shows the average across all the pods controlled by the corresponding deployment).
-->
-请注意在上面的命令输出中，当前的CPU利用率是0%，这是由于我们尚未发送任何请求到服务器
-（``CURRENT`` 列显示了相应 deployment 所控制的所有 Pod 的平均 CPU 利用率）。
+请注意当前的 CPU 利用率是 0%，这是由于我们尚未发送任何请求到服务器
+（``CURRENT`` 列显示了相应 Deployment 所控制的所有 Pod 的平均 CPU 利用率）。
<!--
## Increase load
--->
-## 增加负载
-<!--
Now, we will see how the autoscaler reacts to increased load.
We will start a container, and send an infinite loop of queries to the php-apache service (please run it in a different terminal):
-->
-现在，我们将看到 autoscaler 如何对增加负载作出反应。
+## 增加负载
+
+现在，我们将看到 Autoscaler 如何对增加负载作出反应。
我们将启动一个容器，并通过一个循环向 php-apache 服务器发送无限的查询请求（请在另一个终端中运行以下命令）：
```shell
@@ -177,7 +185,7 @@ while true; do wget -q -O- http://php-apache; done
<!--
Within a minute or so, we should see the higher CPU load by executing:
-->
-在几分钟时间内，通过以下命令，我们可以看到CPU负载升高了：
+一分钟时间左右之后，通过以下命令，我们可以看到 CPU 负载升高了：
```shell
kubectl get hpa
@@ -192,7 +200,8 @@ php-apache Deployment/php-apache/scale 305% / 50% 305% 1 10
Here, CPU consumption has increased to 305% of the request.
As a result, the deployment was resized to 7 replicas:
-->
-这时，由于请求增多，CPU利用率已经升至305%。 可以看到，deployment 的副本数量已经增长到了7：
+这时，由于请求增多，CPU 利用率已经升至 305%。
+可以看到，Deployment 的副本数量已经增长到了 7：
```shell
kubectl get deployment php-apache
@@ -203,22 +212,17 @@ php-apache 7 7 7 7 19m
```
<!--
-{{< note >}}
It may take a few minutes to stabilize the number of replicas. Since the amount
of load is not controlled in any way it may happen that the final number of replicas
will differ from this example.
-{{< /note >}}
-->
{{< note >}}
-有时最终副本的数量可能需要几分钟才能稳定下来。 由于环境的差异，不同环境中最终的副本数量可能与本示例中的数量不同。
+有时最终副本的数量可能需要几分钟才能稳定下来。由于环境的差异，不同环境中最终的副本数量可能与本示例中的数量不同。
{{< /note >}}
<!--
## Stop load
--->
-## 停止负载
-<!--
We will finish our example by stopping the user load.
In the terminal where we created the container with `busybox` image, terminate
@@ -226,9 +230,11 @@ the load generation by typing `<Ctrl> + C`.
Then we will verify the result state (after a minute or so):
-->
+## 停止负载
+
我们将通过停止负载来结束我们的示例。
-在我们创建 busybox 容器的终端中，输入`<Ctrl> + C`来终止负载的产生。
+在我们创建 busybox 容器的终端中，输入`<Ctrl> + C` 来终止负载的产生。
然后我们可以再次查看负载状态（等待几分钟时间）：
@@ -251,36 +257,31 @@ php-apache 1 1 1 1 27m
<!--
Here CPU utilization dropped to 0, and so HPA autoscaled the number of replicas back down to 1.
-->
-这时，CPU利用率已经降到0，所以 HPA 将自动缩减副本数量至1。
+这时，CPU 利用率已经降到 0，所以 HPA 将自动缩减副本数量至 1。
<!--
-{{< note >}}
Autoscaling the replicas may take a few minutes.
-{{< /note >}}
-->
{{< note >}}
-自动伸缩完成副本数量的改变可能需要几分钟的时间。
+自动扩缩完成副本数量的改变可能需要几分钟的时间。
{{< /note >}}
-
-
<!-- discussion -->
<!--
## Autoscaling on multiple metrics and custom metrics
--->
-## 基于多项度量指标和自定义度量指标自动伸缩
-<!--
You can introduce additional metrics to use when autoscaling the `php-apache` Deployment
by making use of the `autoscaling/v2beta2` API version.
-->
-利用`autoscaling/v2beta2`API版本，您可以在自动伸缩 php-apache 这个 Deployment 时引入其他度量指标。
+## 基于多项度量指标和自定义度量指标自动扩缩
+
+利用 `autoscaling/v2beta2` API 版本，你可以在自动扩缩 php-apache 这个 Deployment 时使用其他度量指标。
<!--
First, get the YAML of your HorizontalPodAutoscaler in the `autoscaling/v2beta2` form:
-->
-首先，获取`autoscaling/v2beta2`格式的 HorizontalPodAutoscaler 的YAML文件：
+首先，将 HorizontalPodAutoscaler 的 YAML 文件改为 `autoscaling/v2beta2` 格式：
```shell
kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml
@@ -289,7 +290,7 @@ kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml
<!--
Open the `/tmp/hpa-v2.yaml` file in an editor, and you should see YAML which looks like this:
-->
-在编辑器中打开`/tmp/hpa-v2.yaml`：
+在编辑器中打开 `/tmp/hpa-v2.yaml`：
```yaml
apiVersion: autoscaling/v2beta2
@@ -332,25 +333,25 @@ the only other supported resource metric is memory. These resources do not chan
to cluster, and should always be available, as long as the `metrics.k8s.io` API is available.
-->
需要注意的是，`targetCPUUtilizationPercentage` 字段已经被名为 `metrics` 的数组所取代。
-CPU利用率这个度量指标是一个*resource metric*(资源度量指标)，因为它表示容器上指定资源的百分比。
-除CPU外，您还可以指定其他资源度量指标。默认情况下，目前唯一支持的其他资源度量指标为内存。
-只要`metrics.k8s.io` API存在，这些资源度量指标就是可用的，并且他们不会在不同的Kubernetes集群中改变名称。
+CPU 利用率这个度量指标是一个 *resource metric*（资源度量指标），因为它表示容器上指定资源的百分比。
+除 CPU 外，你还可以指定其他资源度量指标。默认情况下，目前唯一支持的其他资源度量指标为内存。
+只要 `metrics.k8s.io` API 存在，这些资源度量指标就是可用的，并且他们不会在不同的 Kubernetes 集群中改变名称。
<!--
You can also specify resource metrics in terms of direct values, instead of as percentages of the
requested value, by using a `target` type of `AverageValue` instead of `AverageUtilization`, and
setting the corresponding `target.averageValue` field instead of the `target.averageUtilization`.
-->
-您还可以指定资源度量指标使用绝对数值，而不是百分比，你需要将`target`类型`AverageUtilization`替换成`AverageValue`，同时
-将`target.averageUtilization`替换成`target.averageValue`并设定相应的值。
+你还可以指定资源度量指标使用绝对数值，而不是百分比，你需要将 `target` 类型 `AverageUtilization` 替换成 `AverageValue`，同时
+将 `target.averageUtilization` 替换成 `target.averageValue` 并设定相应的值。
<!--
There are two other types of metrics, both of which are considered *custom metrics*: pod metrics and
object metrics. These metrics may have names which are cluster specific, and require a more
advanced cluster monitoring setup.
-->
-还有两种其他类型的度量指标，他们被认为是*custom metrics*（自定义度量指标）：
-即 Pod 度量指标和对象度量指标（pod metrics and object metrics）。
+还有两种其他类型的度量指标，他们被认为是 *custom metrics*（自定义度量指标）：
+即 pod 度量指标和 object 度量指标。
这些度量指标可能具有特定于集群的名称，并且需要更高级的集群监控设置。
<!--
@@ -358,13 +359,13 @@ The first of these alternative metric types is *pod metrics*. These metrics des
are averaged together across pods and compared with a target value to determine the replica count.
They work much like resource metrics, except that they *only* support a `target` type of `AverageValue`.
-->
-第一种可选的度量指标类型是 Pod 度量指标。这些指标从某一方面描述了Pod，在不同Pod之间进行平均，并通过与一个目标值比对来确定副本的数量。
-它们的工作方式与资源度量指标非常相像，差别是它们仅支持`target` 类型为`AverageValue`。
+第一种可选的度量指标类型是 pod 度量指标。这些指标从某一方面描述了Pod，在不同 Pod 之间进行平均，并通过与一个目标值比对来确定副本的数量。
+它们的工作方式与资源度量指标非常相像，差别是它们仅支持 `target` 类型为 `AverageValue`。
<!--
Pod metrics are specified using a metric block like this:
-->
-Pod 度量指标通过如下代码块定义：
+pod 度量指标通过如下代码块定义：
```yaml
type: Pods
@@ -385,11 +386,11 @@ metric from the API. With `AverageValue`, the value returned from the custom met
by the number of pods before being compared to the target. The following example is the YAML
representation of the `requests-per-second` metric.
-->
-第二种可选的度量指标类型是对象度量指标。相对于描述 Pod，这些度量指标用于描述一个在相同名字空间(namespace)中的其他对象。
-请注意这些度量指标用于描述这些对象，并非从对象中获取。
-对象度量指标支持的`target`类型包括`Value`和`AverageValue`。如果是`Value`类型，target值将直接与API返回的度量指标比较，
-而`AverageValue`类型，API返回的度量指标将按照 Pod 数量拆分，然后再与target值比较。
-下面的 YAML 文件展示了一个表示`requests-per-second`的度量指标。
+第二种可选的度量指标类型是对象（object）度量指标。相对于描述 Pod，这些度量指标用于描述一个在相同名字空间中的其他对象。
+请注意这些度量指标用于描述这些对象，并非从对象中获取指标。
+对象度量指标支持的 `target` 类型包括 `Value` 和 `AverageValue`。如果是 `Value` 类型，`target` 值将直接与 API 返回的度量指标比较，
+而对于 `AverageValue` 类型，API 返回的度量值将按照 Pod 数量拆分，然后再与 `target` 值比较。
+下面的 YAML 文件展示了一个表示 `requests-per-second` 的度量指标。
```yaml
type: Object
@@ -410,14 +411,15 @@ If you provide multiple such metric blocks, the HorizontalPodAutoscaler will con
The HorizontalPodAutoscaler will calculate proposed replica counts for each metric, and then choose the
one with the highest replica count.
-->
-如果您指定了多个上述类型的度量指标，HorizontalPodAutoscaler 将会依次考量各个指标。
+如果你指定了多个上述类型的度量指标，HorizontalPodAutoscaler 将会依次考量各个指标。
HorizontalPodAutoscaler 将会计算每一个指标所提议的副本数量，然后最终选择一个最高值。
<!--
For example, if you had your monitoring system collecting metrics about network traffic,
you could update the definition above using `kubectl edit` to look like this:
-->
-比如，如果您的监控系统能够提供网络流量数据，您可以通过`kubectl edit`命令将上述 Horizontal Pod Autoscaler 的定义更改为：
+比如，如果你的监控系统能够提供网络流量数据，你可以通过 `kubectl edit` 命令
+将上述 Horizontal Pod Autoscaler 的定义更改为：
```yaml
apiVersion: autoscaling/v2beta1
@@ -483,24 +485,26 @@ Then, your HorizontalPodAutoscaler would attempt to ensure that each pod was con
50% of its requested CPU, serving 1000 packets per second, and that all pods behind the main-route
Ingress were serving a total of 10000 requests per second.
-->
-然后，您的 HorizontalPodAutoscaler 将会尝试确保每个Pod的CPU利用率在50%以内，每秒能够服务1000个数据包请求，
-并确保所有在Ingress后的Pod每秒能够服务的请求总数达到10000个。
+这样，你的 HorizontalPodAutoscaler 将会尝试确保每个 Pod 的 CPU 利用率在 50% 以内，
+每秒能够服务 1000 个数据包请求，
+并确保所有在 Ingress 后的 Pod 每秒能够服务的请求总数达到 10000 个。
<!--
### Autoscaling on more specific metrics
--->
-### 多个度量指标下伸缩
-<!--
Many metrics pipelines allow you to describe metrics either by name or by a set of additional
descriptors called _labels_. For all non-resource metric types (pod, object, and external,
described below), you can specify an additional label selector which is passed to your metric
pipeline. For instance, if you collect a metric `http_requests` with the `verb`
label, you can specify the following metric block to scale only on GET requests:
-->
-许多度量管道允许您通过名称或附加的_labels_来描述度量指标。对于所有非资源类型度量指标(pod、object和后面将介绍的external)，
-，可以额外指定一个标签选择器。例如，如果你希望收集包含`verb`标签的`http_requests`度量指标，
-你可以在 GET 请求中指定需要的度量指标，如下所示：
+### 基于更确定的度量值来扩缩
+
+许多度量流水线允许你通过名称或附加的_标签_来描述度量指标。
+对于所有非资源类型度量指标（pod、object 和后面将介绍的 external），
+可以额外指定一个标签选择算符。例如，如果你希望收集包含 `verb` 标签的
+`http_requests` 度量指标，可以按如下所示设置度量指标块，使得扩缩操作仅针对
+GET 请求执行：
```yaml
type: Object
@@ -517,23 +521,24 @@ match multiple series. The selector is additive, and cannot select metrics
that describe objects that are **not** the target object (the target pods in the case of the `Pods`
type, and the described object in the case of the `Object` type).
-->
-这个选择器使用与 Kubernetes 标签选择器相同的语法。
-如果名称和标签选择器匹配到多个系列，监测管道会决定如何将多个系列合并成单个值。
-选择器是附加的，它不会选择目标以外的对象（类型为`Pods`的目标和类型为`Object`的目标）。
+这个选择算符使用与 Kubernetes 标签选择算符相同的语法。
+如果名称和标签选择算符匹配到多个系列，监测管道会决定如何将多个系列合并成单个值。
+选择算符是可以累加的，它不会选择目标以外的对象（类型为 `Pods` 的目标 Pods 或者
+类型为 `Object` 的目标对象）。
<!--
### Autoscaling on metrics not related to Kubernetes objects
--->
-### 基于Kubernetes以外的度量指标伸缩
-<!--
Applications running on Kubernetes may need to autoscale based on metrics that don't have an obvious
relationship to any object in the Kubernetes cluster, such as metrics describing a hosted service with
no direct correlation to Kubernetes namespaces. In Kubernetes 1.10 and later, you can address this use case
with *external metrics*.
-->
-运行在 Kubernetes 上的应用程序可能需要基于与 Kubernetes 集群中的任何对象没有明显关系的度量指标进行自动伸缩，
-例如那些描述不在 Kubernetes 任何 namespaces 服务的度量指标。
+### 基于与 Kubernetes 对象无关的度量指标执行扩缩
+
+运行在 Kubernetes 上的应用程序可能需要基于与 Kubernetes 集群中的任何对象没有明显关系的度量指标进行自动扩缩，
+例如那些描述与任何 Kubernetes 名字空间中的服务都无直接关联的度量指标。
+在 Kubernetes 1.10 及之后版本中，你可以使用外部度量指标（external metrics）。
<!--
Using external metrics requires knowledge of your monitoring system; the setup is
@@ -545,17 +550,19 @@ the sum of their values is used by the HorizontalPodAutoscaler.
External metrics support both the `Value` and `AverageValue` target types, which function exactly the same
as when you use the `Object` type.
-->
-使用外部的度量指标，需要了解你使用的监控系统，相关的设置与使用自定义试题指标类似。
-External metrics 可以使用你的监控系统的任何指标来自动伸缩你的集群。你只需要在`metric`块中提供`name` 和 `selector`，同时将类型由`Object`改为`External`。
-如果`metricSelector`匹配到多个度量指标，HorizontalPodAutoscaler 将会把它们加和。
-External metrics 同时支持`Value`和`AverageValue`类型，这与`Object`类型的度量指标相同。
+使用外部度量指标时，需要了解你所使用的监控系统，相关的设置与使用自定义指标时类似。
+外部度量指标使得你可以使用你的监控系统的任何指标来自动扩缩你的集群。
+你只需要在 `metric` 块中提供 `name` 和 `selector`，同时将类型由 `Object` 改为 `External`。
+如果 `metricSelector` 匹配到多个度量指标，HorizontalPodAutoscaler 将会把它们加和。
+外部度量指标同时支持 `Value` 和 `AverageValue` 类型，这与 `Object` 类型的度量指标相同。
<!--
For example if your application processes tasks from a hosted queue service, you could add the following
section to your HorizontalPodAutoscaler manifest to specify that you need one worker per 30 outstanding tasks.
-->
-例如，如果你的应用程序处理主机上的消息队列，
-为了让每30个任务有1个worker，你可以将下面的内容添加到 HorizontalPodAutoscaler 的配置中。
+例如，如果你的应用程序处理来自主机上消息队列的任务，
+为了让每 30 个任务有 1 个工作者实例，你可以将下面的内容添加到
+HorizontalPodAutoscaler 的配置中。
```yaml
- type: External
@@ -573,34 +580,37 @@ When possible, it's preferable to use the custom metric target types instead of
easier for cluster administrators to secure the custom metrics API. The external metrics API potentially allows
access to any metric, so cluster administrators should take care when exposing it.
-->
-如果可能，还是推荐 custom metric 而不是 external metrics，因为这便于让系统管理员加固 custom metrics API。
-而 external metrics API 可以允许访问所有的度量指标，当暴露这些服务时，系统管理员需要仔细考虑这个问题。
+如果可能，还是推荐定制度量指标而不是外部度量指标，因为这便于让系统管理员加固定制度量指标 API。
+而外部度量指标 API 可以允许访问所有的度量指标。
+当暴露这些服务时，系统管理员需要仔细考虑这个问题。
<!--
## Appendix: Horizontal Pod Autoscaler Status Conditions
--->
-## 附录：Horizontal Pod Autoscaler状态条件
-<!--
When using the `autoscaling/v2beta2` form of the HorizontalPodAutoscaler, you will be able to see
*status conditions* set by Kubernetes on the HorizontalPodAutoscaler. These status conditions indicate
whether or not the HorizontalPodAutoscaler is able to scale, and whether or not it is currently restricted
in any way.
-->
-当使用`autoscaling/v2beta2`格式的 HorizontalPodAutoscaler 时，您将可以看到 Kubernetes 为 HorizongtalPodAutoscaler 设置的状态条件（status conditions）。
-这些状态条件可以显示当前 HorizontalPodAutoscaler 是否能够执行伸缩以及是否受到一定的限制。
+## 附录：Horizontal Pod Autoscaler 状态条件
+
+使用 `autoscaling/v2beta2` 格式的 HorizontalPodAutoscaler 时，你将可以看到
+Kubernetes 为 HorizongtalPodAutoscaler 设置的状态条件（Status Conditions）。
+这些状态条件可以显示当前 HorizontalPodAutoscaler 是否能够执行扩缩以及是否受到一定的限制。
<!--
The conditions appear in the `status.conditions` field. To see the conditions affecting a HorizontalPodAutoscaler,
we can use `kubectl describe hpa`:
-->
`status.conditions`字段展示了这些状态条件。
-可以通过`kubectl describe hpa`命令查看当前影响 HorizontalPodAutoscaler 的各种状态条件信息：
+可以通过 `kubectl describe hpa` 命令查看当前影响 HorizontalPodAutoscaler
+的各种状态条件信息：
```shell
kubectl describe hpa cm-test
```
-```shell
+
+```
Name: cm-test
Namespace: prom
Labels: <none>
@@ -633,18 +643,15 @@ you may wish to raise or lower the minimum or maximum replica count constraints
HorizontalPodAutoscaler.
-->
对于上面展示的这个 HorizontalPodAutoscaler，我们可以看出有若干状态条件处于健康状态。
-首先，`AbleToScale` 表明 HPA 是否可以获取和更新伸缩信息，以及是否存在阻止伸缩的各种回退条件。
-其次，`ScalingActive` 表明HPA是否被启用（即目标的副本数量不为零） 以及是否能够完成伸缩计算。
+首先，`AbleToScale` 表明 HPA 是否可以获取和更新扩缩信息，以及是否存在阻止扩缩的各种回退条件。
+其次，`ScalingActive` 表明 HPA 是否被启用（即目标的副本数量不为零） 以及是否能够完成扩缩计算。
当这一状态为 `False` 时，通常表明获取度量指标存在问题。
-最后一个条件 `ScalingLimitted` 表明所需伸缩的值被 HorizontalPodAutoscaler 所定义的最大或者最小值所限制（即已经达到最大或者最小伸缩值）。
-这通常表明您可能需要调整 HorizontalPodAutoscaler 所定义的最大或者最小副本数量的限制了。
+最后一个条件 `ScalingLimitted` 表明所需扩缩的值被 HorizontalPodAutoscaler 所定义的最大或者最小值所限制（即已经达到最大或者最小扩缩值）。
+这通常表明你可能需要调整 HorizontalPodAutoscaler 所定义的最大或者最小副本数量的限制了。
<!--
## Appendix: Quantities
--->
-## 附录：Quantities
-<!--
All metrics in the HorizontalPodAutoscaler and metrics APIs are specified using
a special whole-number notation known in Kubernetes as a *quantity*. For example,
the quantity `10500m` would be written as `10.5` in decimal notation. The metrics APIs
@@ -653,27 +660,28 @@ quantities in milli-units otherwise. This means you might see your metric value
between `1` and `1500m`, or `1` and `1.5` when written in decimal notation. See the
[glossary entry on quantities](/docs/reference/glossary?core-object=true#term-quantity) for more information.
-->
-HorizontalPodAutoscaler 和 metrics api 中的所有的度量指标使用 Kubernetes 中称为 *quantity* （）殊整数表示。
-例如，数量`10500m`用十进制表示为`10.5`。
-如果可能的话，metrics api 将返回没有后缀的整数，否则返回以千分单位的数量。
-这意味着您可能会看到您的度量指标在`1`和`1500m`之间波动，或者在十进制记数法中的`1`和`1.5`。
-更多信息，请参阅[度量术语](/docs/reference/glossary?core-object=true#term-quantity)
+## 附录：量纲
+
+HorizontalPodAutoscaler 和 度量指标 API 中的所有的度量指标使用 Kubernetes 中称为 *quantity* （量纲）的特殊整数表示。
+例如，数量 `10500m` 用十进制表示为 `10.5`。
+如果可能的话，度量指标 API 将返回没有后缀的整数，否则返回以千分单位的数量。
+这意味着你可能会看到你的度量指标在 `1` 和 `1500m` （也就是在十进制记数法中的 `1` 和 `1.5`）之间波动。
+更多信息，请参阅[度量术语](/docs/reference/glossary?core-object=true#term-quantity)。
<!--
## Appendix: Other possible scenarios
+
+### Creating the autoscaler declaratively
-->
## 附录：其他可能的情况
-<!--
-### Creating the autoscaler declaratively
--->
-### 使用YAML文件创建 autoscaler
+### 使用 YAML 文件以声明式方式创建 Autoscaler
<!--
Instead of using `kubectl autoscale` command to create a HorizontalPodAutoscaler imperatively we
can use the following file to create it declaratively:
-->
-除了使用 `kubectl autoscale` 命令，也可以文件创建 HorizontalPodAutoscaler ：
+除了使用 `kubectl autoscale` 命令，也可以文件创建 HorizontalPodAutoscaler：
{{< codenew file="application/hpa/php-apache.yaml" >}}
@@ -682,11 +690,10 @@ We will create the autoscaler by executing the following command:
-->
使用如下命令创建 autoscaler：
-
-
```shell
kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml
```
+
```
horizontalpodautoscaler.autoscaling/php-apache created
```
diff --git a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md
index 10966fdf4d..717640bb86 100644
--- a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md
+++ b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md
@@ -1,13 +1,9 @@
---
-reviewers:
-- fgrzadkowski
-- jszczepkowski
-- directxman12
-title: Pod 水平自动伸缩
+title: Pod 水平自动扩缩
feature:
- title: 水平伸缩
+ title: 水平扩缩
description: >
- 使用一个简单的命令、一个UI或基于CPU使用情况自动对应用程序进行伸缩。
+ 使用一个简单的命令、一个UI或基于CPU使用情况自动对应用程序进行扩缩。
content_type: concept
weight: 90
@@ -22,10 +18,11 @@ in a replication controller, deployment or replica set based on observed CPU uti
support, on some other application-provided metrics). Note that Horizontal
Pod Autoscaling does not apply to objects that can't be scaled, for example, DaemonSets.
-->
-Pod 水平自动伸缩（Horizontal Pod Autoscaler）特性，
-可以基于CPU利用率自动伸缩 replication controller、deployment和 replica set 中的 pod 数量，（除了 CPU 利用率）也可以
-基于其他应程序提供的度量指标[custom metrics](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md)。
-pod 自动缩放不适用于无法缩放的对象，比如 DaemonSets。
+Pod 水平自动扩缩（Horizontal Pod Autoscaler）
+可以基于 CPU 利用率自动扩缩 ReplicationController、Deployment 和 ReplicaSet 中的 Pod 数量。
+除了 CPU 利用率，也可以基于其他应程序提供的[自定义度量指标](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md)
+来执行自动扩缩。
+Pod 自动扩缩不适用于无法扩缩的对象，比如 DaemonSet。
<!--
The Horizontal Pod Autoscaler is implemented as a Kubernetes API resource and a controller.
@@ -33,28 +30,25 @@ The resource determines the behavior of the controller.
The controller periodically adjusts the number of replicas in a replication controller or deployment
to match the observed average CPU utilization to the target specified by user.
-->
-Pod 水平自动伸缩特性由 Kubernetes API 资源和控制器实现。资源决定了控制器的行为。
-控制器会周期性的获取平均 CPU 利用率，并与目标值相比较后来调整 replication controller 或 deployment 中的副本数量。
-
-
-
+Pod 水平自动扩缩特性由 Kubernetes API 资源和控制器实现。资源决定了控制器的行为。
+控制器会周期性的调整副本控制器或 Deployment 中的副本数量，以使得 Pod 的平均 CPU
+利用率与用户所设定的目标值匹配。
<!-- body -->
<!--
## How does the Horizontal Pod Autoscaler work?
-->
-## Pod 水平自动伸缩工作机制
+## Pod 水平自动扩缩工作机制
-
+
<!--
The Horizontal Pod Autoscaler is implemented as a control loop, with a period controlled
by the controller manager's `--horizontal-pod-autoscaler-sync-period` flag (with a default
value of 15 seconds).
-->
-Pod 水平自动伸缩的实现是一个控制循环，由 controller manager 的 `--horizontal-pod-autoscaler-sync-period` 参数
-指定周期（默认值为15秒）。
+Pod 水平自动扩缩器的实现是一个控制回路，由控制器管理器的 `--horizontal-pod-autoscaler-sync-period` 参数指定周期（默认值为 15 秒）。
<!--
During each period, the controller manager queries the resource utilization against the
@@ -62,8 +56,8 @@ metrics specified in each HorizontalPodAutoscaler definition. The controller ma
obtains the metrics from either the resource metrics API (for per-pod resource metrics),
or the custom metrics API (for all other metrics).
-->
-每个周期内，controller manager 根据每个 HorizontalPodAutoscaler 定义中指定的指标查询资源利用率。
-controller manager 可以从 resource metrics API（每个pod 资源指标）和 custom metrics API（其他指标）获取指标。
+每个周期内，控制器管理器根据每个 HorizontalPodAutoscaler 定义中指定的指标查询资源利用率。
+控制器管理器可以从资源度量指标 API（按 Pod 统计的资源用量）和自定义度量指标 API（其他指标）获取度量值。
<!--
* For per-pod resource metrics (like CPU), the controller fetches the metrics
@@ -75,26 +69,28 @@ controller manager 可以从 resource metrics API（每个pod 资源指标）和
of target specified) across all targeted pods, and produces a ratio used to scale
the number of desired replicas.
-->
-* 对于每个 pod 的资源指标（如 CPU），控制器从资源指标 API 中获取每一个 HorizontalPodAutoscaler 指定
-的 pod 的指标，然后，如果设置了目标使用率，控制器获取每个 pod 中的容器资源使用情况，并计算资源使用率。
-如果使用原始值，将直接使用原始数据（不再计算百分比）。
-然后，控制器根据平均的资源使用率或原始值计算出缩放的比例，进而计算出目标副本数。
+* 对于按 Pod 统计的资源指标（如 CPU），控制器从资源指标 API 中获取每一个
+ HorizontalPodAutoscaler 指定的 Pod 的度量值，如果设置了目标使用率，
+ 控制器获取每个 Pod 中的容器资源使用情况，并计算资源使用率。
+ 如果设置了 target 值，将直接使用原始数据（不再计算百分比）。
+ 接下来，控制器根据平均的资源使用率或原始值计算出扩缩的比例，进而计算出目标副本数。
-<!--
+ <!--
Please note that if some of the pod's containers do not have the relevant resource request set,
CPU utilization for the pod will not be defined and the autoscaler will
not take any action for that metric. See the [algorithm
details](#algorithm-details) section below for more information about
how the autoscaling algorithm works.
--->
-需要注意的是，如果 pod 某些容器不支持资源采集，那么控制器将不会使用该 pod 的 CPU 使用率。
-下面的[算法细节](#algorithm-details)章节将会介绍详细的算法。
+ -->
+ 需要注意的是，如果 Pod 某些容器不支持资源采集，那么控制器将不会使用该 Pod 的 CPU 使用率。
+ 下面的[算法细节](#algorithm-details)章节将会介绍详细的算法。
<!--
* For per-pod custom metrics, the controller functions similarly to per-pod resource metrics,
except that it works with raw values, not utilization values.
-->
-* 如果 pod 使用自定义指示，控制器机制与资源指标类似，区别在于自定义指标只使用原始值，而不是使用率。
+* 如果 Pod 使用自定义指示，控制器机制与资源指标类似，区别在于自定义指标只使用
+ 原始值，而不是使用率。
<!--
* For object metrics and external metrics, a single metric is fetched, which describes
@@ -104,8 +100,8 @@ controller manager 可以从 resource metrics API（每个pod 资源指标）和
comparison is made.
-->
* 如果pod 使用对象指标和外部指标（每个指标描述一个对象信息）。
- 这个指标将直接跟据目标设定值相比较，并生成一个上面提到的缩放比例。在 `autoscaling/v2beta2` 版本API中，
- 这个指标也可以根据 pod 数量平分后再计算。
+ 这个指标将直接跟据目标设定值相比较，并生成一个上面提到的扩缩比例。
+ 在 `autoscaling/v2beta2` 版本API中，这个指标也可以根据 Pod 数量平分后再计算。
<!--
The HorizontalPodAutoscaler normally fetches metrics from a series of aggregated APIs (`metrics.k8s.io`,
@@ -114,10 +110,10 @@ metrics-server, which needs to be launched separately. See
[metrics-server](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server)
for instructions. The HorizontalPodAutoscaler can also fetch metrics directly from Heapster.
-->
-通常情况下，控制器将从一系列的聚合 API（`metrics.k8s.io`、`custom.metrics.k8s.io`和`external.metrics.k8s.io`）
-中获取指标数据。
-`metrics.k8s.io` API 通常由 metrics-server（需要额外启动）提供。
-可以从[metrics-server](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server) 获取更多信息。
+通常情况下，控制器将从一系列的聚合 API（`metrics.k8s.io`、`custom.metrics.k8s.io`
+和 `external.metrics.k8s.io`）中获取度量值。
+`metrics.k8s.io` API 通常由 Metrics 服务器（需要额外启动）提供。
+可以从 [metrics-server](/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server) 获取更多信息。
另外，控制器也可以直接从 Heapster 获取指标。
{{< note >}}
@@ -125,13 +121,13 @@ for instructions. The HorizontalPodAutoscaler can also fetch metrics directly fr
<!--
Fetching metrics from Heapster is deprecated as of Kubernetes 1.11.
-->
-自 Kubernetes 1.11起，从 Heapster 获取指标特性已废弃。
+自 Kubernetes 1.11 起，从 Heapster 获取指标特性已废弃。
{{< /note >}}
<!--
See [Support for metrics APIs](#support-for-metrics-apis) for more details.
-->
-关于指标 API 更多信息，请参考[Support for metrics APIs](#support-for-metrics-apis)。
+关于指标 API 更多信息，请参考[度量值指标 API 的支持](#support-for-metrics-apis)。
<!--
The autoscaler accesses corresponding scalable controllers (such as replication controllers, deployments, and replica sets)
@@ -139,21 +135,21 @@ by using the scale sub-resource. Scale is an interface that allows you to dynami
each of their current states. More details on scale sub-resource can be found
[here](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource).
-->
-自动缩放控制器使用 scale sub-resource 访问相应可支持缩放的控制器（如replication controllers、deployments 和 replica sets）。
+自动扩缩控制器使用 scale 子资源访问相应可支持扩缩的控制器（如副本控制器、
+Deployments 和 ReplicaSet）。
`scale` 是一个可以动态设定副本数量和检查当前状态的接口。
-更多关于 scale sub-resource 的信息，请参考[这里](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource).
+关于 scale 子资源的更多信息，请参考[这里](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource).
<!--
### Algorithm Details
--->
-### 算法细节
-<!--
From the most basic perspective, the Horizontal Pod Autoscaler controller
operates on the ratio between desired metric value and current metric
value:
-->
-从最基本的角度来看，pod 水平自动缩放控制器跟据当前指标和期望指标来计算缩放比例。
+### 算法细节 {#algorithm-details}
+
+从最基本的角度来看，Pod 水平自动扩缩控制器跟据当前指标和期望指标来计算扩缩比例。
<!--
```
@@ -161,7 +157,7 @@ desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricVal
```
-->
```
-期望副本数 = ceil[当前副本数 * ( 当前指标 / 期望指标 )]
+期望副本数 = ceil[当前副本数 * (当前指标 / 期望指标)]
```
<!--
@@ -172,11 +168,12 @@ replicas, since `50.0 / 100.0 == 0.5`. We'll skip scaling if the ratio is
sufficiently close to 1.0 (within a globally-configurable tolerance, from
the `--horizontal-pod-autoscaler-tolerance` flag, which defaults to 0.1).
-->
-例如，当前指标为`200m`，目标设定值为`100m`,那么由于`200.0 / 100.0 == 2.0`，
+例如，当前度量值为 `200m`，目标设定值为 `100m`，那么由于 `200.0/100.0 == 2.0`，
副本数量将会翻倍。
-如果当前指标为`50m`，副本数量将会减半，因为`50.0 / 100.0 == 0.5`。
-如果计算出的缩放比例接近1.0（跟据`--horizontal-pod-autoscaler-tolerance` 参数全局配置的容忍值，默认为0.1），
-将会放弃本次缩放。
+如果当前指标为 `50m`，副本数量将会减半，因为`50.0/100.0 == 0.5`。
+如果计算出的扩缩比例接近 1.0
+（跟据`--horizontal-pod-autoscaler-tolerance` 参数全局配置的容忍值，默认为 0.1），
+将会放弃本次扩缩。
<!--
When a `targetAverageValue` or `targetAverageUtilization` is specified,
@@ -186,28 +183,27 @@ Before checking the tolerance and deciding on the final values, we take
pod readiness and missing metrics into consideration, however.
-->
如果 HorizontalPodAutoscaler 指定的是`targetAverageValue` 或 `targetAverageUtilization`，
-那么将会把指定pod的平均指标做为`currentMetricValue`。
-然而，在检查容忍度和决定最终缩放值前，我们仍然会把那些无法获取指标的pod统计进去。
+那么将会把指定 Pod 度量值的平均值做为 `currentMetricValue`。
+然而，在检查容忍度和决定最终扩缩值前，我们仍然会把那些无法获取指标的 Pod 统计进去。
<!--
All Pods with a deletion timestamp set (i.e. Pods in the process of being
shut down) and all failed Pods are discarded.
--->
-所有被标记了删除时间戳(Pod正在关闭过程中)的 pod 和 失败的 pod 都会被忽略。
-<!--
If a particular Pod is missing metrics, it is set aside for later; Pods
with missing metrics will be used to adjust the final scaling amount.
-->
-如果某个 pod 缺失指标信息，它将会被搁置，只在最终确定缩值时再考虑。
+所有被标记了删除时间戳（Pod 正在关闭过程中）的 Pod 和 失败的 Pod 都会被忽略。
+
+如果某个 Pod 缺失度量值，它将会被搁置，只在最终确定扩缩数量时再考虑。
<!--
When scaling on CPU, if any pod has yet to become ready (i.e. it's still
initializing) *or* the most recent metric point for the pod was before it
became ready, that pod is set aside as well.
-->
-当使用 CPU 指标来缩放时，任何还未就绪（例如还在初始化）状态的 pod *或* 最近的指标为就绪状态前的 pod，
-也会被搁置
+当使用 CPU 指标来扩缩时，任何还未就绪（例如还在初始化）状态的 Pod *或* 最近的指标
+度量值采集于就绪状态前的 Pod，该 Pod 也会被搁置。
<!--
Due to technical constraints, the HorizontalPodAutoscaler controller
@@ -221,18 +217,20 @@ ready to be the first if it occurred within a longer, configurable time
since it started. This value is configured with the `--horizontal-pod-autoscaler-cpu-initialization-period` flag, and its
default is 5 minutes.
-->
-由于受技术限制，pod 水平缩放控制器无法准确的知道 pod 什么时候就绪，
-也就无法决定是否暂时搁置该 pod。
-`--horizontal-pod-autoscaler-initial-readiness-delay` 参数（默认为30s），用于设置 pod 准备时间，
-在此时间内的 pod 统统被认为未就绪。
-`--horizontal-pod-autoscaler-cpu-initialization-period`参数（默认为5分钟），用于设置 pod 的初始化时间，
-在此时间内的 pod，CPU 资源指标将不会被采纳。
+由于受技术限制，Pod 水平扩缩控制器无法准确的知道 Pod 什么时候就绪，
+也就无法决定是否暂时搁置该 Pod。
+`--horizontal-pod-autoscaler-initial-readiness-delay` 参数（默认为 30s）用于设置 Pod 准备时间，
+在此时间内的 Pod 统统被认为未就绪。
+`--horizontal-pod-autoscaler-cpu-initialization-period` 参数（默认为5分钟）
+用于设置 Pod 的初始化时间，
+在此时间内的 Pod，CPU 资源度量值将不会被采纳。
<!--
The `currentMetricValue / desiredMetricValue` base scale ratio is then
calculated using the remaining pods not set aside or discarded from above.
-->
-在排除掉被搁置的 pod 后，缩放比例就会跟据`currentMetricValue / desiredMetricValue`计算出来。
+在排除掉被搁置的 Pod 后，扩缩比例就会跟据`currentMetricValue/desiredMetricValue`
+计算出来。
<!--
If there were any missing metrics, we recompute the average more
@@ -240,10 +238,10 @@ conservatively, assuming those pods were consuming 100% of the desired
value in case of a scale down, and 0% in case of a scale up. This dampens
the magnitude of any potential scale.
-->
-如果有任何 pod 的指标缺失，我们会更保守地重新计算平均值，
-在需要缩小时假设这些 pod 消耗了目标值的 100%，
-在需要放大时假设这些 pod 消耗了0%目标值。
-这可以在一定程度上抑制伸缩的幅度。
+如果缺失任何的度量值，我们会更保守地重新计算平均值，
+在需要缩小时假设这些 Pod 消耗了目标值的 100%，
+在需要放大时假设这些 Pod 消耗了 0% 目标值。
+这可以在一定程度上抑制扩缩的幅度。
<!--
Furthermore, if any not-yet-ready pods were present, and we would have
@@ -251,8 +249,8 @@ scaled up without factoring in missing metrics or not-yet-ready pods, we
conservatively assume the not-yet-ready pods are consuming 0% of the
desired metric, further dampening the magnitude of a scale up.
-->
-此外，如果存在任何尚未就绪的pod，我们可以在不考虑遗漏指标或尚未就绪的pods的情况下进行伸缩，
-我们保守地假设尚未就绪的pods消耗了试题指标的0%，从而进一步降低了伸缩的幅度。
+此外，如果存在任何尚未就绪的 Pod，我们可以在不考虑遗漏指标或尚未就绪的 Pod 的情况下进行扩缩，
+我们保守地假设尚未就绪的 Pod 消耗了试题指标的 0%，从而进一步降低了扩缩的幅度。
<!--
After factoring in the not-yet-ready pods and missing metrics, we
@@ -260,9 +258,9 @@ recalculate the usage ratio. If the new ratio reverses the scale
direction, or is within the tolerance, we skip scaling. Otherwise, we use
the new ratio to scale.
-->
-在缩放方向（缩小或放大）确定后，我们会把未就绪的 pod 和缺少指标的 pod 考虑进来再次计算使用率。
-如果新的比率与缩放方向相反，或者在容忍范围内，则跳过缩放。
-否则，我们使用新的缩放比例。
+在扩缩方向（缩小或放大）确定后，我们会把未就绪的 Pod 和缺少指标的 Pod 考虑进来再次计算使用率。
+如果新的比率与扩缩方向相反，或者在容忍范围内，则跳过扩缩。
+否则，我们使用新的扩缩比例。
<!--
Note that the *original* value for the average utilization is reported
@@ -271,7 +269,7 @@ not-yet-ready pods or missing metrics, even when the new usage ratio is
used.
-->
注意，平均利用率的*原始*值会通过 HorizontalPodAutoscaler 的状态体现（
-即使使用了新的使用率，也不考虑未就绪 pod 和 缺少指标的 pod)。
+即使使用了新的使用率，也不考虑未就绪 Pod 和 缺少指标的 Pod)。
<!--
If multiple metrics are specified in a HorizontalPodAutoscaler, this
@@ -281,9 +279,9 @@ into a desired replica count (e.g. due to an error fetching the metrics
from the metrics APIs), scaling is skipped.
-->
如果创建 HorizontalPodAutoscaler 时指定了多个指标，
-那么会按照每个指标分别计算缩放副本数，取最大的进行缩放。
-如果任何一个指标无法顺利的计算出缩放副本数（比如，通过 API 获取指标时出错），
-那么本次缩放会被跳过。
+那么会按照每个指标分别计算扩缩副本数，取最大的进行扩缩。
+如果任何一个指标无法顺利的计算出扩缩副本数（比如，通过 API 获取指标时出错），
+那么本次扩缩会被跳过。
<!--
Finally, just before HPA scales the target, the scale recommendation is recorded. The
@@ -293,54 +291,58 @@ This value can be configured using the `--horizontal-pod-autoscaler-downscale-st
This means that scaledowns will occur gradually, smoothing out the impact of rapidly
fluctuating metric values.
-->
-最后，在 HPA 控制器执行缩放操作之前，会记录缩放建议信息（scale recommendation）。
+最后，在 HPA 控制器执行扩缩操作之前，会记录扩缩建议信息。
控制器会在操作时间窗口中考虑所有的建议信息，并从中选择得分最高的建议。
-这个值可通过 kube-controller-manager 服务的启动参数 `--horizontal-pod-autoscaler-downscale-stabilization` 进行配置，
-默认值为 5min。
+这个值可通过 `kube-controller-manager` 服务的启动参数 `--horizontal-pod-autoscaler-downscale-stabilization` 进行配置，
+默认值为 5 分钟。
这个配置可以让系统更为平滑地进行缩容操作，从而消除短时间内指标值快速波动产生的影响。
<!--
## API Object
--->
-## API 对象
-<!--
The Horizontal Pod Autoscaler is an API resource in the Kubernetes `autoscaling` API group.
The current stable version, which only includes support for CPU autoscaling,
can be found in the `autoscaling/v1` API version.
-->
+## API 对象 {#api-object}
+
HorizontalPodAutoscaler 是 Kubernetes `autoscaling` API 组的资源。
-在当前稳定版本（`autoscaling/v1`）中只支持基于CPU指标的缩放。
+在当前稳定版本（`autoscaling/v1`）中只支持基于 CPU 指标的扩缩。
<!--
The beta version, which includes support for scaling on memory and custom metrics,
can be found in `autoscaling/v2beta2`. The new fields introduced in `autoscaling/v2beta2`
are preserved as annotations when working with `autoscaling/v1`.
-->
-在 beta 版本（`autoscaling/v2beta2`），引入了基于内存和自定义指标的缩放。
-在`autoscaling/v2beta2`版本中新引入的字段在`autoscaling/v1`版本中基于 annotation 实现。
+API 的 beta 版本（`autoscaling/v2beta2`）引入了基于内存和自定义指标的扩缩。
+在 `autoscaling/v2beta2` 版本中新引入的字段在 `autoscaling/v1` 版本中以注解
+的形式得以保留。
<!--
+When you create a HorizontalPodAutoscaler API object, make sure the name specified is a valid
+[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+
More details about the API object can be found at
[HorizontalPodAutoscaler Object](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object).
-->
-更多有关 API 对象的信息，请查阅[HorizontalPodAutoscaler Object](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object)。
+创建 HorizontalPodAutoscaler 对象时，需要确保所给的名称是一个合法的
+[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
+有关 API 对象的更多信息，请查阅[HorizontalPodAutoscaler 对象设计文档](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object)。
<!--
## Support for Horizontal Pod Autoscaler in kubectl
--->
-## 使用 kubectl 操作 Horizontal Pod Autoscaler
-<!--
Horizontal Pod Autoscaler, like every API resource, is supported in a standard way by `kubectl`.
We can create a new autoscaler using `kubectl create` command.
We can list autoscalers by `kubectl get hpa` and get detailed description by `kubectl describe hpa`.
Finally, we can delete an autoscaler using `kubectl delete hpa`.
-->
-与其他 API 资源类似，`kubectl` 也标准支持 Pod 自动伸缩。
-我们可以通过 `kubectl create` 命令创建一个自动伸缩对象，
-通过 `kubectl get hpa` 命令来获取所有自动伸缩对象，
-通过 `kubectl describe hpa` 命令来查看自动伸缩对象的详细信息。
+## kubectl 对 Horizontal Pod Autoscaler 的支持
+
+与其他 API 资源类似，`kubectl` 以标准方式支持 HPA。
+我们可以通过 `kubectl create` 命令创建一个 HPA 对象，
+通过 `kubectl get hpa` 命令来获取所有 HPA 对象，
+通过 `kubectl describe hpa` 命令来查看 HPA 对象的详细信息。
最后，可以使用 `kubectl delete hpa` 命令删除对象。
<!--
@@ -350,28 +352,26 @@ will create an autoscaler for replication set *foo*, with target CPU utilization
and the number of replicas between 2 and 5.
The detailed documentation of `kubectl autoscale` can be found [here](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
-->
-此外，还有个简便的命令 `kubectl autoscale` 来创建自动伸缩对象。
+此外，还有个简便的命令 `kubectl autoscale` 来创建 HPA 对象。
例如，命令 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80` 将会为名
-为 *foo* 的 replication set 创建一个自动伸缩对象，
-对象目标CPU使用率为 `80%`，副本数量配置为 2 到 5 之间。
+为 *foo* 的 ReplicationSet 创建一个 HPA 对象，
+目标 CPU 使用率为 `80%`，副本数量配置为 2 到 5 之间。
<!--
## Autoscaling during rolling update
--->
-## 滚动升级时缩放
-
-<!--
Currently in Kubernetes, it is possible to perform a [rolling update](/docs/tasks/run-application/rolling-update-replication-controller/)
by managing replication controllers directly,
or by using the deployment object, which manages the underlying replica sets for you.
Horizontal Pod Autoscaler only supports the latter approach: the Horizontal Pod Autoscaler is bound to the deployment object,
it sets the size for the deployment object, and the deployment is responsible for setting sizes of underlying replica sets.
-->
-目前在 Kubernetes 中，可以针对 replication controllers 或 deployment 执行
-滚动升级[rolling update](/docs/tasks/run-application/rolling-update-replication-controller/)，他们会为你管理底层副本数。
-Pod 水平缩放只支持后一种：Horizontal Pod Autoscaler 会被绑定到 deployment 对象中，Horizontal Pod Autoscaler 设置副本数量时，
-deployment 会设置底层副本数。
+## 滚动升级时扩缩 {#autoscaling-during-roling-update}
+
+目前在 Kubernetes 中，可以针对 ReplicationController 或 Deployment 执行
+滚动更新，它们会为你管理底层副本数。
+Pod 水平扩缩只支持后一种：HPA 会被绑定到 Deployment 对象，
+HPA 设置副本数量时，Deployment 会设置底层副本数。
<!--
Horizontal Pod Autoscaler does not work with rolling update using direct manipulation of replication controllers,
@@ -379,35 +379,36 @@ i.e. you cannot bind a Horizontal Pod Autoscaler to a replication controller and
The reason this doesn't work is that when rolling update creates a new replication controller,
the Horizontal Pod Autoscaler will not be bound to the new replication controller.
-->
-当使用 replication controllers 执行滚动升级时， Horizontal Pod Autoscaler 不能工作，
-也就是说你不能将 Horizontal Pod Autoscaler 绑定到某个 replication controller
-再执行滚动升级（例如使用 `kubectl rolling-update` 命令）。
-Horizontal Pod Autoscaler 不能工作的原因是，Horizontal Pod Autoscaler 无法绑定到滚动升级时创建的新副本。
+通过直接操控副本控制器执行滚动升级时，HPA 不能工作，
+也就是说你不能将 HPA 绑定到某个 RC 再执行滚动升级
+（例如使用 `kubectl rolling-update` 命令）。
+HPA 不能工作的原因是它无法绑定到滚动更新时所新创建的副本控制器。
<!--
## Support for cooldown/delay
--->
-## 冷却/延迟
-<!--
When managing the scale of a group of replicas using the Horizontal Pod Autoscaler,
it is possible that the number of replicas keeps fluctuating frequently due to the
dynamic nature of the metrics evaluated. This is sometimes referred to as *thrashing*.
-->
-当使用 Horizontal Pod Autoscaler 管理一组副本缩放时，
-有可能因为指标动态的变化造成副本数量频繁的变化，有时这被称为 *抖动*。
+## 冷却/延迟支持
+
+当使用 Horizontal Pod Autoscaler 管理一组副本扩缩时，
+有可能因为指标动态的变化造成副本数量频繁的变化，有时这被称为
+*抖动（Thrashing）*。
<!--
Starting from v1.6, a cluster operator can mitigate this problem by tuning
the global HPA settings exposed as flags for the `kube-controller-manager` component:
-->
-从 v1.6 版本起，集群操作员可以开启某些 `kube-controller-manager` 全局的参数来缓和这个问题。
+从 v1.6 版本起，集群操作员可以调节某些 `kube-controller-manager` 的全局参数来
+缓解这个问题。
<!--
Starting from v1.12, a new algorithmic update removes the need for the
upscale delay.
-->
-从 v1.12 开始，算法调整后，就不用这么做了。
+从 v1.12 开始，算法调整后，扩容操作时的延迟就不必设置了。
<!--
- `--horizontal-pod-autoscaler-downscale-stabilization`: The value for this option is a
@@ -415,10 +416,10 @@ upscale delay.
downscale operation can be performed after the current one has completed.
The default value is 5 minutes (`5m0s`).
-->
-- `--horizontal-pod-autoscaler-downscale-stabilization`: 这个 `kube-controller-manager` 的参数表示缩容冷却时间。
- 即自从上次缩容执行结束后，多久可以再次执行缩容，默认时间是5分钟(`5m0s`)。
+- `--horizontal-pod-autoscaler-downscale-stabilization`:
+ `kube-controller-manager` 的这个参数表示缩容冷却时间。
+ 即自从上次缩容执行结束后，多久可以再次执行缩容，默认时间是 5 分钟(`5m0s`)。
-{{< note >}}
<!--
When tuning these parameter values, a cluster operator should be aware of the possible
consequences. If the delay (cooldown) value is set too long, there could be complaints
@@ -426,43 +427,43 @@ that the Horizontal Pod Autoscaler is not responsive to workload changes. Howeve
the delay value is set too short, the scale of the replicas set may keep thrashing as
usual.
-->
-当启用这个参数时，集群操作员需要明白其可能的影响。
-如果延迟（冷却）时间设置的太长，那么 Horizontal Pod Autoscaler 可能会不能很好的改变负载。
-如果延迟（冷却）时间设备的太短，那么副本数量有可能跟以前一样抖动。
+{{< note >}}
+当调整这些参数时，集群操作员需要明白其可能的影响。
+如果延迟（冷却）时间设置的太长，Horizontal Pod Autoscaler 可能会不能很好的改变负载。
+如果延迟（冷却）时间设置的太短，那么副本数量有可能跟以前一样出现抖动。
{{< /note >}}
<!--
## Support for multiple metrics
--->
-## 多指标支持
-<!--
Kubernetes 1.6 adds support for scaling based on multiple metrics. You can use the `autoscaling/v2beta2` API
version to specify multiple metrics for the Horizontal Pod Autoscaler to scale on. Then, the Horizontal Pod
Autoscaler controller will evaluate each metric, and propose a new scale based on that metric. The largest of the
proposed scales will be used as the new scale.
-->
-在 Kubernetes 1.6 支持了基于多个指标进行缩放。
+## 多指标支持 {#support-for-multiple-metrics}
+
+Kubernetes 1.6 开始支持基于多个度量值进行扩缩。
你可以使用 `autoscaling/v2beta2` API 来为 Horizontal Pod Autoscaler 指定多个指标。
-Horizontal Pod Autoscaler 会跟据每个指标计算，并生成一个缩放建议。
-幅度最大的缩放建议会被采纳。
+Horizontal Pod Autoscaler 会跟据每个指标计算，并生成一个扩缩建议。
+幅度最大的扩缩建议会被采纳。
<!--
## Support for custom metrics
--->
-## 自定义指标支持
-{{< note >}}
-<!--
Kubernetes 1.2 added alpha support for scaling based on application-specific metrics using special annotations.
Support for these annotations was removed in Kubernetes 1.6 in favor of the new autoscaling API. While the old method for collecting
custom metrics is still available, these metrics will not be available for use by the Horizontal Pod Autoscaler, and the former
annotations for specifying which custom metrics to scale on are no longer honored by the Horizontal Pod Autoscaler controller.
-->
-在 Kubernetes 1.2 增加的 alpha 的缩放支持基于特定的 annotation。
-自从 Kubernetes 1.6 起，由于缩放 API 的引入，这些 annotation 就不再支持了。
-虽然收集自定义指标的旧方法仍然可用，但是 Horizontal Pod Autoscaler 调度器将不会再使用这些指标，
-同时，Horizontal Pod Autoscaler 也不再使用之前的用于指定用户自定义指标的 annotation 了。
+## 自定义指标支持 {#support-for-custom-metrics}
+
+{{< note >}}
+在 Kubernetes 1.2 增加了支持基于使用特殊注解表达的、特定于具体应用的扩缩能力，
+此能力处于 Alpha 阶段。
+从 Kubernetes 1.6 起，由于新的 autoscaling API 的引入，这些 annotation 就被废弃了。
+虽然收集自定义指标的旧方法仍然可用，Horizontal Pod Autoscaler 调度器将不会再使用这些度量值。
+同时，Horizontal Pod Autoscaler 也不再使用之前用于指定用户自定义指标的注解。
{{< /note >}}
<!--
@@ -477,52 +478,41 @@ Kubernetes 会通过用户自定义指标 API 来获取相应的指标。
<!--
See [Support for metrics APIs](#support-for-metrics-apis) for the requirements.
-->
-关于指标 API 的要求，请查阅 [Support for metrics APIs](#support-for-metrics-apis)。
+关于指标 API 的要求，请参阅[对 Metrics API 的支持](#support-for-metrics-apis)。
<!--
## Support for metrics APIs
--->
-## 指标 API
-<!--
By default, the HorizontalPodAutoscaler controller retrieves metrics from a series of APIs. In order for it to access these
APIs, cluster administrators must ensure that:
-->
-默认情况下，HorizontalPodAutoscaler 控制器会从一系列的 API 中请求指标数据。
-集群管理员需要确保下述条件，以保证这些 API 可以访问：
+## 对 Metrics API 的支持 {#support-for-metrics-apis}
+
+默认情况下，HorizontalPodAutoscaler 控制器会从一系列的 API 中检索度量值。
+集群管理员需要确保下述条件，以保证 HPA 控制器能够访问这些 API：
<!--
* The [API aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) is enabled.
--->
-* [API aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) 已开启
-
-<!--
* The corresponding APIs are registered:
-
* For resource metrics, this is the `metrics.k8s.io` API, generally provided by [metrics-server](https://github.com/kubernetes-incubator/metrics-server).
It can be launched as a cluster addon.
-
* For custom metrics, this is the `custom.metrics.k8s.io` API. It's provided by "adapter" API servers provided by metrics solution vendors.
Check with your metrics pipeline, or the [list of known solutions](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api).
If you would like to write your own, check out the [boilerplate](https://github.com/kubernetes-incubator/custom-metrics-apiserver) to get started.
-
* For external metrics, this is the `external.metrics.k8s.io` API. It may be provided by the custom metrics adapters provided above.
--->
-
-* 相应的 API 已注册：
-
- * 资源指标会使用 `metrics.k8s.io` API，一般由 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) 提供。
- 它可以做为集群组件启动。
- * 用户指标会使用 `custom.metrics.k8s.io` API。
- 它由其他厂商的“适配器”API 服务器提供。
- 确认你的指标管道，或者查看 [list of known solutions](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api)。
- * 外部指标会使用 `external.metrics.k8s.io` API。可能由上面的用户指标适配器提供。
-
-<!--
* The `--horizontal-pod-autoscaler-use-rest-clients` is `true` or unset. Setting this to false switches to Heapster-based autoscaling, which is deprecated.
-->
+* 启用了 [API 聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
+* 相应的 API 已注册：
+
+ * 对于资源指标，将使用 `metrics.k8s.io` API，一般由 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) 提供。
+ 它可以做为集群插件启动。
+ * 对于自定义指标，将使用 `custom.metrics.k8s.io` API。
+ 它由其他度量指标方案厂商的“适配器（Adapter）” API 服务器提供。
+ 确认你的指标流水线，或者查看[已知方案列表](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api)。
+ * 对于外部指标，将使用 `external.metrics.k8s.io` API。可能由上面的自定义指标适配器提供。
* `--horizontal-pod-autoscaler-use-rest-clients` 参数设置为 `true` 或者不设置。
- 如果设置为 false，则会切换到基于 Heapster 的自动缩放，这个特性已经被弃用了。
+ 如果设置为 false，则会切换到基于 Heapster 的自动扩缩，这个特性已经被弃用了。
<!--
For more information on these different metrics paths and how they differ please see the relevant design proposals for
@@ -530,31 +520,27 @@ For more information on these different metrics paths and how they differ please
[custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md)
and [external.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/external-metrics-api.md).
-->
-更多关于指标来源以及其区别，请参阅相关的设计文档，
+关于指标来源以及其区别的更多信息，请参阅相关的设计文档，
[the HPA V2](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-v2.md)、
-[custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md)和
+[custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md) 和
[external.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/external-metrics-api.md)。
<!--
For examples of how to use them see [the walkthrough for using custom metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)
and [the walkthrough for using external metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects).
-->
-如何使用它们的示例，请参考
-[the walkthrough for using custom metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)
-和 [the walkthrough for using external metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects)。
-
-
+关于如何使用它们的示例，请参考
+[使用自定义指标的教程](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)
+和[使用外部指标的教程](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects)。
## {{% heading "whatsnext" %}}
-
<!--
* Design documentation: [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md).
* kubectl autoscale command: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
* Usage example of [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).
-->
-* 设计文档：[Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md).
-* kubectl 自动缩放命令： [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
-* 使用示例：[Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).
-
+* 设计文档：[Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md)
+* `kubectl autoscale` 命令： [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
+* 使用示例：[Horizontal Pod Autoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).
diff --git a/content/zh/docs/tasks/run-application/rolling-update-replication-controller.md b/content/zh/docs/tasks/run-application/rolling-update-replication-controller.md
deleted file mode 100644
index d715d73f17..0000000000
--- a/content/zh/docs/tasks/run-application/rolling-update-replication-controller.md
+++ /dev/null
@@ -1,514 +0,0 @@
----
-reviewers:
-- janetkuo
-title: 基于Replication Controller执行滚动升级
-content_type: concept
-weight: 80
----
-
-<!--
----
-reviewers:
-- janetkuo
-title: Perform Rolling Update Using a Replication Controller
-content_type: concept
-weight: 80
----
--->
-
-## 概述
-
-**注**: 创建副本应用的首选方法是使用[Deployment](/docs/api-reference/{{< param "version" >}}/#deployment-v1beta1-apps)，Deployment使用[ReplicaSet](/docs/api-reference/{{< param "version" >}}/#replicaset-v1beta1-extensions)来进行副本控制。
-更多信息, 查看[使用Deployment运行一个无状态应用](/docs/tasks/run-application/run-stateless-application-deployment/)。
-
-<!--
-{{< note >}}
-**Note**: The preferred way to create a replicated application is to use a
-[Deployment](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deployment-v1-apps),
-which in turn uses a
-[ReplicaSet](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replicaset-v1-apps).
-For more information, see
-[Running a Stateless Application Using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/).
-{{< /note >}}
--->
-
-为了在更新服务的同时不中断业务， `kubectl` 支持['滚动更新'](/docs/user-guide/kubectl/v1.6/#rolling-update)，它一次更新一个pod，而不是同时停止整个服务。 有关更多信息，请参阅 [滚动更新设计文档](https://git.k8s.io/community/contributors/design-proposals/cli/simple-rolling-update.md) 和 [滚动更新示例](/docs/tasks/run-application/rolling-update-replication-controller/)。
-
-<!--
-To update a service without an outage, `kubectl` supports what is called [rolling update](/docs/reference/generated/kubectl/kubectl-commands/#rolling-update), which updates one pod at a time, rather than taking down the entire service at the same time. See the [rolling update design document](https://git.k8s.io/community/contributors/design-proposals/cli/simple-rolling-update.md) for more information.
--->
-
-请注意， `kubectl rolling-update` 仅支持Replication Controllers。 但是，如果使用Replication Controllers部署应用，请考虑将其切换到[Deployments](/docs/concepts/workloads/controllers/deployment/). Deployment是一种被推荐使用的更高级别的控制器，它可以对应用进行声明性的自动滚动更新。 如果您仍然希望保留您的Replication Controllers并使用 `kubectl rolling-update`进行滚动更新， 请继续往下阅读：
-
-<!--
-Note that `kubectl rolling-update` only supports Replication Controllers. However, if you deploy applications with Replication Controllers,
-consider switching them to [Deployments](/docs/concepts/workloads/controllers/deployment/). A Deployment is a higher-level controller that automates rolling updates
-of applications declaratively, and therefore is recommended. If you still want to keep your Replication Controllers and use `kubectl rolling-update`, keep reading:
--->
-
-滚动更新可以对replication controller所管理的Pod的配置进行变更，变更可以通过一个新的配置文件来进行，或者，如果只更新镜像，则可以直接指定新的容器镜像。
-
-<!--
-A rolling update applies changes to the configuration of pods being managed by
-a replication controller. The changes can be passed as a new replication
-controller configuration file; or, if only updating the image, a new container
-image can be specified directly.
--->
-
-滚动更新的工作流程：
-
-<!--
-A rolling update works by:
--->
-
-1. 通过新的配置创建一个replication controller
-2. 在新的控制器上增加副本数，在旧的上面减少副本数，直到副本数达到期望值
-3. 删除之前的replication controller
-
-<!--
-1. Creating a new replication controller with the updated configuration.
-2. Increasing/decreasing the replica count on the new and old controllers until
- the correct number of replicas is reached.
-3. Deleting the original replication controller.
--->
-
-使用`kubectl rolling-update`命令来进行滚动更新：
-
- $ kubectl rolling-update NAME \
- ([NEW_NAME] --image=IMAGE | -f FILE)
-
-<!--
-Rolling updates are initiated with the `kubectl rolling-update` command:
-
- $ kubectl rolling-update NAME \
- ([NEW_NAME] --image=IMAGE | -f FILE)
--->
-
-## 通过配置文件更新
-
-通过配置文件来进行滚动更新，需要在`kubectl rolling-update`命令后面带上新的配置文件：
-
- $ kubectl rolling-update NAME -f FILE
-
-这个配置文件必须满足以下条件：
-
-* 指定不同的`metadata.name`值
-
-* 至少要修改`spec.selector`中的一个标签值
-
-* `metadata.namespace`字段必须相同
-
-Replication Controllers的配置文件详细介绍见[创建Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/).
-
-<!--
-## Passing a configuration file
-
-To initiate a rolling update using a configuration file, pass the new file to
-`kubectl rolling-update`:
-
- $ kubectl rolling-update NAME -f FILE
-
-The configuration file must:
-
-* Specify a different `metadata.name` value.
-
-* Overwrite at least one common label in its `spec.selector` field.
-
-* Use the same `metadata.namespace`.
-
-Replication controller configuration files are described in
-[Creating Replication Controllers](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/).
--->
-
-### 示例
-
- // 通过新的配置文件frontend-v2.json来更新frontend-v1的pods
- $ kubectl rolling-update frontend-v1 -f frontend-v2.json
-
- // 将frontend-v2.json数据传到标准输入来更新frontend-v1的pods
- $ cat frontend-v2.json | kubectl rolling-update frontend-v1 -f -
-
-<!--
-### Examples
-
- // Update pods of frontend-v1 using new replication controller data in frontend-v2.json.
- $ kubectl rolling-update frontend-v1 -f frontend-v2.json
-
- // Update pods of frontend-v1 using JSON data passed into stdin.
- $ cat frontend-v2.json | kubectl rolling-update frontend-v1 -f -
--->
-
-## 更新容器镜像
-
-仅更新容器镜像的话，可通过如下命令，该命令可以指定一个新的控制器名称（可选），通过`--image`参数来指定新的镜像名称和标签。
-
- $ kubectl rolling-update NAME [NEW_NAME] --image=IMAGE:TAG
-
-`--image`参数仅支持单容器pod，多容器pod使用`--image`参数会返回错误。
-
-如果没有指定 `NEW_NAME` ，新的replication controller创建后会使用一个临时名称，当更新完成，旧的controller被删除后，新的controller名称会被更新成旧的controller名称。
-
-如果`IMAGE:TAG` 和当前值相同，更新就会失败。 因此，我们建议使用版本号来作为标签，而不是使用 `:latest`。从一个 `image:latest`镜像升级到一个新的 `image:latest` 镜像将会失败，即使这两个镜像不是相同的。
-所以，我们不建议使用 `:latest` 来作为标签，详细信息见[最佳配置实践](/docs/concepts/configuration/overview/#container-images) 。
-
-<!--
-## Updating the container image
-
-To update only the container image, pass a new image name and tag with the
-`--image` flag and (optionally) a new controller name:
-
- $ kubectl rolling-update NAME [NEW_NAME] --image=IMAGE:TAG
-
-The `--image` flag is only supported for single-container pods. Specifying
-`--image` with multi-container pods returns an error.
-
-If no `NEW_NAME` is specified, a new replication controller is created with
-a temporary name. Once the rollout is complete, the old controller is deleted,
-and the new controller is updated to use the original name.
-
-The update will fail if `IMAGE:TAG` is identical to the
-current value. For this reason, we recommend the use of versioned tags as
-opposed to values such as `:latest`. Doing a rolling update from `image:latest`
-to a new `image:latest` will fail, even if the image at that tag has changed.
-Moreover, the use of `:latest` is not recommended, see
-[Best Practices for Configuration](/docs/concepts/configuration/overview/#container-images) for more information.
--->
-
-### 示例
-
- // 更新frontend-v1的pod到frontend-v2
- $ kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2
-
- // 更新frontend的pods，不更改replication controller的名称
- $ kubectl rolling-update frontend --image=image:v2
-
-<!--
-### Examples
-
- // Update the pods of frontend-v1 to frontend-v2
- $ kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2
-
- // Update the pods of frontend, keeping the replication controller name
- $ kubectl rolling-update frontend --image=image:v2
--->
-
-## 必选和可选字段
-
-必选字段：
-
-* `NAME`: 需要进行滚动更新的replication controller名称
-
-下面两个字段选其一：
-
-* `-f FILE`: 新的replication controller的配置文件，JSON或者YAML格式均可。配置文件必须指定一个新的顶层`id`值，且至少包含一个现有`spec.selector`中的键值对。
- 详细信息见[通过Replication Controller运行无状态应用](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/#replication-controller-configuration-file)。
-<br>
-<br>
- 或者：
-<br>
-<br>
-* `--image IMAGE:TAG`: 更新后的镜像的名称和标签。必须和当前的image:tag不同。
-
-可选字段包括：
-
-* `NEW_NAME`: 只和 `--image` 一起使用，不和 `-f FILE` 一起使用。标识新的replication controller的名称。
-* `--poll-interval DURATION`: 在更新后轮询控制器状态的间隔时间。有效单位有 `ns` （纳秒），`us` 或 `µs`（微秒），`ms`（毫秒），`s`（秒），`m`（分钟）或 `h`（小时）。 单位可以自由组合（例如 `1m30s`）。 默认值为 `3s`。
-* `--timeout DURATION`: 退出更新之前，等待控制器更新一个pod的最大时间。默认是`5m0s`。有效单位如`--poll-interval`所述。
-* `--update-period DURATION`: 更新两个pod之间等待的时间，默认值是`1m0s`。有效单位如`--poll-interval`所述。
-
-有关`kubectl rolling-update`命令的更多信息见[`kubectl`参考](/docs/user-guide/kubectl/v1.6/#rolling-update).
-
-<!--
-## Required and optional fields
-
-Required fields are:
-
-* `NAME`: The name of the replication controller to update.
-
-as well as either:
-
-* `-f FILE`: A replication controller configuration file, in either JSON or
- YAML format. The configuration file must specify a new top-level `id` value
- and include at least one of the existing `spec.selector` key:value pairs.
- See the
- [Run Stateless AP Replication Controller](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/#replication-controller-configuration-file)
- page for details.
-<br>
-<br>
- or:
-<br>
-<br>
-* `--image IMAGE:TAG`: The name and tag of the image to update to. Must be
- different than the current image:tag currently specified.
-
-Optional fields are:
-
-* `NEW_NAME`: Only used in conjunction with `--image` (not with `-f FILE`). The
- name to assign to the new replication controller.
-* `--poll-interval DURATION`: The time between polling the controller status
- after update. Valid units are `ns` (nanoseconds), `us` or `µs` (microseconds),
- `ms` (milliseconds), `s` (seconds), `m` (minutes), or `h` (hours). Units can
- be combined (e.g. `1m30s`). The default is `3s`.
-* `--timeout DURATION`: The maximum time to wait for the controller to update a
- pod before exiting. Default is `5m0s`. Valid units are as described for
- `--poll-interval` above.
-* `--update-period DURATION`: The time to wait between updating pods. Default
- is `1m0s`. Valid units are as described for `--poll-interval` above.
-
-Additional information about the `kubectl rolling-update` command is available
-from the [`kubectl` reference](/docs/reference/generated/kubectl/kubectl-commands/#rolling-update).
--->
-
-## 实践
-
-现在你运行了一个1.7.9版本的nginx应用：
-
-```yaml
-apiVersion: v1
-kind: ReplicationController
-metadata:
- name: my-nginx
-spec:
- replicas: 5
- template:
- metadata:
- labels:
- app: nginx
- spec:
- containers:
- - name: nginx
- image: nginx:1.7.9
- ports:
- - containerPort: 80
-```
-
-要更新到1.9.1版本，你可以使用[`kubectl rolling-update --image`](https://git.k8s.io/community/contributors/design-proposals/cli/simple-rolling-update.md)来指定一个新的镜像：
-
-```shell
-$ kubectl rolling-update my-nginx --image=nginx:1.9.1
-Created my-nginx-ccba8fbd8cc8160970f63f9a2696fc46
-```
-
-在终端上打开另一个窗口 ，你可以看到`kubectl` 给每个pod都增加了一个值为配置文件哈希值的 `deployment` 标签，用来区分新旧pod：
-
-```shell
-$ kubectl get pods -l app=nginx -L deployment
-NAME READY STATUS RESTARTS AGE DEPLOYMENT
-my-nginx-ccba8fbd8cc8160970f63f9a2696fc46-k156z 1/1 Running 0 1m ccba8fbd8cc8160970f63f9a2696fc46
-my-nginx-ccba8fbd8cc8160970f63f9a2696fc46-v95yh 1/1 Running 0 35s ccba8fbd8cc8160970f63f9a2696fc46
-my-nginx-divi2 1/1 Running 0 2h 2d1d7a8f682934a254002b56404b813e
-my-nginx-o0ef1 1/1 Running 0 2h 2d1d7a8f682934a254002b56404b813e
-my-nginx-q6all 1/1 Running 0 8m 2d1d7a8f682934a254002b56404b813e
-```
-
-使用`kubectl rolling-update`可以实时看到更新的进度：
-
-```
-Scaling up my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 from 0 to 3, scaling down my-nginx from 3 to 0 (keep 3 pods available, don't exceed 4 pods)
-Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 up to 1
-Scaling my-nginx down to 2
-Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 up to 2
-Scaling my-nginx down to 1
-Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 up to 3
-Scaling my-nginx down to 0
-Update succeeded. Deleting old controller: my-nginx
-Renaming my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 to my-nginx
-replicationcontroller "my-nginx" rolling updated
-```
-
-如果遇到问题，你可以中途停止滚动更新，并且使用 `--rollback` 来回滚到以前的版本:
-
-```shell
-$ kubectl rolling-update my-nginx --rollback
-Setting "my-nginx" replicas to 1
-Continuing update with existing controller my-nginx.
-Scaling up nginx from 1 to 1, scaling down my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 from 1 to 0 (keep 1 pods available, don't exceed 2 pods)
-Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 down to 0
-Update succeeded. Deleting my-nginx-ccba8fbd8cc8160970f63f9a2696fc46
-replicationcontroller "my-nginx" rolling updated
-```
-
-这个例子说明容器的不变性是个巨大的优点。
-
-如果你不仅仅是需要更新镜像，(例如，更新命令参数，环境变量等)，你可以创建一个新的replication controller配置文件，包含一个新的名称和不同的标签值，例如：
-
-```yaml
-apiVersion: v1
-kind: ReplicationController
-metadata:
- name: my-nginx-v4
-spec:
- replicas: 5
- selector:
- app: nginx
- deployment: v4
- template:
- metadata:
- labels:
- app: nginx
- deployment: v4
- spec:
- containers:
- - name: nginx
- image: nginx:1.9.2
- args: ["nginx", "-T"]
- ports:
- - containerPort: 80
-```
-
-然后使用它来进行更新：
-
-```shell
-$ kubectl rolling-update my-nginx -f ./nginx-rc.yaml
-Created my-nginx-v4
-Scaling up my-nginx-v4 from 0 to 5, scaling down my-nginx from 4 to 0 (keep 4 pods available, don't exceed 5 pods)
-Scaling my-nginx-v4 up to 1
-Scaling my-nginx down to 3
-Scaling my-nginx-v4 up to 2
-Scaling my-nginx down to 2
-Scaling my-nginx-v4 up to 3
-Scaling my-nginx down to 1
-Scaling my-nginx-v4 up to 4
-Scaling my-nginx down to 0
-Scaling my-nginx-v4 up to 5
-Update succeeded. Deleting old controller: my-nginx
-replicationcontroller "my-nginx-v4" rolling updated
-```
-<!--
-## Walkthrough
-
-Let's say you were running version 1.7.9 of nginx:
-
-```yaml
-apiVersion: v1
-kind: ReplicationController
-metadata:
- name: my-nginx
-spec:
- replicas: 5
- template:
- metadata:
- labels:
- app: nginx
- spec:
- containers:
- - name: nginx
- image: nginx:1.7.9
- ports:
- - containerPort: 80
-```
-
-To update to version 1.9.1, you can use [`kubectl rolling-update --image`](https://git.k8s.io/community/contributors/design-proposals/cli/simple-rolling-update.md) to specify the new image:
-
-```shell
-$ kubectl rolling-update my-nginx --image=nginx:1.9.1
-Created my-nginx-ccba8fbd8cc8160970f63f9a2696fc46
-```
-
-In another window, you can see that `kubectl` added a `deployment` label to the pods, whose value is a hash of the configuration, to distinguish the new pods from the old:
-
-```shell
-$ kubectl get pods -l app=nginx -L deployment
-NAME READY STATUS RESTARTS AGE DEPLOYMENT
-my-nginx-ccba8fbd8cc8160970f63f9a2696fc46-k156z 1/1 Running 0 1m ccba8fbd8cc8160970f63f9a2696fc46
-my-nginx-ccba8fbd8cc8160970f63f9a2696fc46-v95yh 1/1 Running 0 35s ccba8fbd8cc8160970f63f9a2696fc46
-my-nginx-divi2 1/1 Running 0 2h 2d1d7a8f682934a254002b56404b813e
-my-nginx-o0ef1 1/1 Running 0 2h 2d1d7a8f682934a254002b56404b813e
-my-nginx-q6all 1/1 Running 0 8m 2d1d7a8f682934a254002b56404b813e
-```
-
-`kubectl rolling-update` reports progress as it progresses:
-
-```
-Scaling up my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 from 0 to 3, scaling down my-nginx from 3 to 0 (keep 3 pods available, don't exceed 4 pods)
-Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 up to 1
-Scaling my-nginx down to 2
-Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 up to 2
-Scaling my-nginx down to 1
-Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 up to 3
-Scaling my-nginx down to 0
-Update succeeded. Deleting old controller: my-nginx
-Renaming my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 to my-nginx
-replicationcontroller "my-nginx" rolling updated
-```
-
-If you encounter a problem, you can stop the rolling update midway and revert to the previous version using `--rollback`:
-
-```shell
-$ kubectl rolling-update my-nginx --rollback
-Setting "my-nginx" replicas to 1
-Continuing update with existing controller my-nginx.
-Scaling up nginx from 1 to 1, scaling down my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 from 1 to 0 (keep 1 pods available, don't exceed 2 pods)
-Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 down to 0
-Update succeeded. Deleting my-nginx-ccba8fbd8cc8160970f63f9a2696fc46
-replicationcontroller "my-nginx" rolling updated
-```
-
-This is one example where the immutability of containers is a huge asset.
-
-If you need to update more than just the image (e.g., command arguments, environment variables), you can create a new replication controller, with a new name and distinguishing label value, such as:
-
-```yaml
-apiVersion: v1
-kind: ReplicationController
-metadata:
- name: my-nginx-v4
-spec:
- replicas: 5
- selector:
- app: nginx
- deployment: v4
- template:
- metadata:
- labels:
- app: nginx
- deployment: v4
- spec:
- containers:
- - name: nginx
- image: nginx:1.9.2
- args: ["nginx", "-T"]
- ports:
- - containerPort: 80
-```
-
-and roll it out:
-
-```shell
-$ kubectl rolling-update my-nginx -f ./nginx-rc.yaml
-Created my-nginx-v4
-Scaling up my-nginx-v4 from 0 to 5, scaling down my-nginx from 4 to 0 (keep 4 pods available, don't exceed 5 pods)
-Scaling my-nginx-v4 up to 1
-Scaling my-nginx down to 3
-Scaling my-nginx-v4 up to 2
-Scaling my-nginx down to 2
-Scaling my-nginx-v4 up to 3
-Scaling my-nginx down to 1
-Scaling my-nginx-v4 up to 4
-Scaling my-nginx down to 0
-Scaling my-nginx-v4 up to 5
-Update succeeded. Deleting old controller: my-nginx
-replicationcontroller "my-nginx-v4" rolling updated
-```
--->
-
-## 故障分析
-
-如果更新过程中，达到超时时长`timeout`后还没更新完成，则更新会失败。这时，一些pod会属于新的replication controller，一些会属于旧的。
-
-如果更新失败，可以尝试使用同样的命令来继续更新过程。
-
-在尝试更新之前如果需要回滚到之前的状态，可在之前的命令后面添加`--rollback=true`参数，这将回退所有的更改。
-
-<!--
-## Troubleshooting
-
-If the `timeout` duration is reached during a rolling update, the operation will
-fail with some pods belonging to the new replication controller, and some to the
-original controller.
-
-To continue the update from where it failed, retry using the same command.
-
-To roll back to the original state before the attempted update, append the
-`--rollback=true` flag to the original command. This will revert all changes.
--->
diff --git a/content/zh/docs/tasks/run-application/scale-stateful-set.md b/content/zh/docs/tasks/run-application/scale-stateful-set.md
index ef0e5223e2..595373ea94 100644
--- a/content/zh/docs/tasks/run-application/scale-stateful-set.md
+++ b/content/zh/docs/tasks/run-application/scale-stateful-set.md
@@ -1,92 +1,167 @@
---
-approvers:
-- bprashanth
-- enisoc
-- erictune
-- foxish
-- janetkuo
-- kow3ns
-- smarterclayton
-title: 弹缩StatefulSet
+title: 扩缩 StatefulSet
content_type: task
---
<!-- overview -->
-本文介绍如何弹缩StatefulSet.
+<!--
+This task shows how to scale a StatefulSet. Scaling a StatefulSet refers to increasing or decreasing the number of replicas.
+-->
+本文介绍如何扩缩StatefulSet。StatefulSet 的扩缩指的是增加或者减少副本个数。
## {{% heading "prerequisites" %}}
+<!--
+* StatefulSets are only available in Kubernetes version 1.5 or later.
+ To check your version of Kubernetes, run `kubectl version`.
-* StatefulSets仅适用于Kubernetes1.5及以上版本.
-* **不是所有Stateful应用都适合弹缩.** 在弹缩前您的应用前. 您必须充分了解您的应用, 不适当的弹缩StatefulSet或许会造成应用自身功能的不稳定.
-* 仅当您确定该Stateful应用的集群是完全健康才可执行弹缩操作.
+* Not all stateful applications scale nicely. If you are unsure about whether to scale your StatefulSets, see [StatefulSet concepts](/docs/concepts/workloads/controllers/statefulset/) or [StatefulSet tutorial](/docs/tutorials/stateful-application/basic-stateful-set/) for further information.
+* You should perform scaling only when you are confident that your stateful application
+ cluster is completely healthy.
+-->
+* StatefulSets 仅适用于 Kubernetes 1.5 及以上版本。
+* 不是所有 Stateful 应用都能很好地执行扩缩操作。
+ 如果你不是很确定是否要扩缩你的 StatefulSet，可先参阅
+ [StatefulSet 概念](/zh/docs/concepts/workloads/controllers/statefulset/)
+ 或者 [StatefulSet 教程](/zh/docs/tutorials/stateful-application/basic-stateful-set/)。
+* 仅当你确定你的有状态应用的集群是完全健康的，才可执行扩缩操作.
<!-- steps -->
-## 使用 `kubectl` 弹缩StatefulSets
+<!--
+## Scaling StatefulSets
-弹缩请确认 `kubectl` 已经升级到Kubernetes1.5及以上版本. 如果不确定, 执行 `kubectl version` 命令并检查使用的 `Client Version`.
+### Use kubectl to scale StatefulSets
-### `kubectl 弹缩`
-
-首先, 找到您想要弹缩的StatefulSet. 记住, 您需先清楚是否能弹缩该应用.
+First, find the StatefulSet you want to scale.
```shell
kubectl get statefulsets <stateful-set-name>
```
+-->
+## 扩缩 StatefulSet {#scaling-statefulset}
-改变StatefulSet副本数量:
+## 使用 `kubectl` 扩缩 StatefulSet
+
+首先，找到你要扩缩的 StatefulSet。
+
+```shell
+kubectl get statefulsets <statefulset 名称>
+```
+
+<!--
+Change the number of replicas of your StatefulSet:
```shell
kubectl scale statefulsets <stateful-set-name> --replicas=<new-replicas>
```
+-->
+更改 StatefulSet 中副本个数：
-### 可使用其他命令: `kubectl apply` / `kubectl edit` / `kubectl patch`
+```shell
+kubectl scale statefulsets <statefulset 名称> --replicas=<新的副本数>
+```
-另外, 您可以 [in-place updates](/docs/concepts/cluster-administration/manage-deployment/#in-place-updates-of-resources) StatefulSets.
+<!--
+### Make in-place updates on your StatefulSets
-如果您的StatefulSet开始由 `kubectl apply` 或 `kubectl create --save-config` 创建,更新StatefulSet manifests中的 `.spec.replicas`, 然后执行命令 `kubectl apply`:
+Alternatively, you can do [in-place updates](/docs/concepts/cluster-administration/manage-deployment/#in-place-updates-of-resources) on your StatefulSets.
+If your StatefulSet was initially created with `kubectl apply`,
+update `.spec.replicas` of the StatefulSet manifests, and then do a `kubectl apply`:
+-->
+### 对 StatefulSet 执行就地更新
+
+另外, 你可以[就地更新](/zh/docs/concepts/cluster-administration/manage-deployment/#in-place-updates-of-resources) StatefulSet。
+
+如果你的 StatefulSet 最初通过 `kubectl apply` 或 `kubectl create --save-config` 创建,
+你可以更新 StatefulSet 清单中的 `.spec.replicas`, 然后执行命令 `kubectl apply`:
+
+<!--
```shell
kubectl apply -f <stateful-set-file-updated>
```
-除此之外, 可以通过命令 `kubectl edit` 编辑该字段:
+Otherwise, edit that field with `kubectl edit`:
```shell
kubectl edit statefulsets <stateful-set-name>
```
-或使用 `kubectl patch`:
+Or use `kubectl patch`:
```shell
kubectl patch statefulsets <stateful-set-name> -p '{"spec":{"replicas":<new-replicas>}}'
```
+-->
+```shell
+kubectl apply -f <更新后的 statefulset 文件>
+```
-## 排查故障
+否则，可以使用 `kubectl edit` 编辑副本字段：
-### 缩容工作不正常
+```shell
+kubectl edit statefulsets <statefulset 名称>
+```
-当Stateful管理下的任何一个Pod不健康时您不能缩容该StatefulSet. 仅当Stateful下的所有Pods都处于运行和ready状态后才可缩容.
+或者使用 `kubectl patch`：
-当一个StatefulSet的size > 1, 如果有一个Pod不健康, 没有办法让Kubernetes知道是否是由于永久性故障还是瞬态(升级/维护/节点重启)导致. 如果该Pod不健康是由于永久性
-故障导致, 则在不纠正该故障的情况下进行缩容可能会导致一种状态， 即StatefulSet下的Pod数量低于应正常运行的副本数. 这也许会导致StatefulSet不可用.
+```shell
+kubectl patch statefulsets <statefulset 名称> -p '{"spec":{"replicas":<new-replicas>}}'
+```
-如果由于瞬态故障而导致Pod不健康,并且Pod可能再次可用，那么瞬态错误可能会干扰您对
-StatefulSet的扩容/缩容操作. 一些分布式数据库在节点加入和同时离开时存在问题. 在
-这些情况下，最好是在应用级别进行弹缩操作, 并且只有在您确保Stateful应用的集群是完全健康时才执行弹缩.
+<!--
+## Troubleshooting
+### Scaling down does not work right
+-->
+## 故障排查 {#troubleshooting}
+### 缩容操作无法正常工作
+<!--
+You cannot scale down a StatefulSet when any of the stateful Pods it manages is unhealthy. Scaling down only takes place
+after those stateful Pods become running and ready.
+
+If spec.replicas > 1, Kubernetes cannot determine the reason for an unhealthy Pod. It might be the result of a permanent fault or of a transient fault. A transient fault can be caused by a restart required by upgrading or maintenance.
+-->
+当 Stateful 所管理的任何 Pod 不健康时，你不能对该 StatefulSet 执行缩容操作。
+仅当 StatefulSet 的所有 Pod 都处于运行状态和 Ready 状况后才可缩容.
+
+如果 `spec.replicas` 大于 1，Kubernetes 无法判定 Pod 不健康的原因。
+Pod 不健康可能是由于永久性故障造成也可能是瞬态故障。
+瞬态故障可能是节点升级或维护而引起的节点重启造成的。
+
+<!--
+If the Pod is unhealthy due to a permanent fault, scaling
+without correcting the fault may lead to a state where the StatefulSet membership
+drops below a certain minimum number of replicas that are needed to function
+correctly. This may cause your StatefulSet to become unavailable.
+-->
+如果该 Pod 不健康是由于永久性故障导致, 则在不纠正该故障的情况下进行缩容可能会导致
+StatefulSet 进入一种状态，其成员 Pod 数量低于应正常运行的副本数。
+这种状态也许会导致 StatefulSet 不可用。
+
+<!--
+If the Pod is unhealthy due to a transient fault and the Pod might become available again,
+the transient error may interfere with your scale-up or scale-down operation. Some distributed
+databases have issues when nodes join and leave at the same time. It is better
+to reason about scaling operations at the application level in these cases, and
+perform scaling only when you are sure that your stateful application cluster is
+completely healthy.
+-->
+如果由于瞬态故障而导致 Pod 不健康并且 Pod 可能再次变为可用，那么瞬态错误可能会干扰
+你对 StatefulSet 的扩容/缩容操作。 一些分布式数据库在同时有节点加入和离开时
+会遇到问题。在这些情况下，最好是在应用级别进行分析扩缩操作的状态, 并且只有在确保
+Stateful 应用的集群是完全健康时才执行扩缩操作。
## {{% heading "whatsnext" %}}
-
-了解更多 [deleting a StatefulSet](/docs/tasks/manage-stateful-set/deleting-a-statefulset/).
-
-
-
+<!--
+* Learn more about [deleting a StatefulSet](/docs/tasks/run-application/delete-stateful-set/).
+-->
+* 进一步了解[删除 StatefulSet](/zh/docs/tasks/run-application/delete-stateful-set/)
diff --git a/content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md b/content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md
index 91116c46f0..5e102f790c 100644
--- a/content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md
+++ b/content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md
@@ -3,16 +3,14 @@ title: 使用 Helm 安装 Service Catalog
content_type: task
---
<!--
----
title: Install Service Catalog using Helm
reviewers:
- chenopis
content_type: task
----
-->
<!-- overview -->
-{{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}}
+{{< glossary_definition term_id="service-catalog" length="all" prepend="服务目录（Service Catalog）是" >}}
<!--
Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes cluster. Up to date information on this process can be found at the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/docs/install.md) repo.
@@ -21,7 +19,6 @@ Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes clust
要获取有关此过程的最新信息，请浏览 [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/docs/install.md) 仓库。
-
## {{% heading "prerequisites" %}}
<!--
@@ -35,27 +32,24 @@ Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes clust
* Follow the [Helm install instructions](https://github.com/kubernetes/helm/blob/master/docs/install.md).
* If you already have an appropriate version of Helm installed, execute `helm init` to install Tiller, the server-side component of Helm.
-->
-* 理解 [Service Catalog](/docs/concepts/service-catalog/) 的关键概念。
+* 理解[服务目录](/zh/docs/concepts/service-catalog/) 的关键概念。
* Service Catalog 需要 Kubernetes 集群版本在 1.7 或更高版本。
-* 您必须启用 Kubernetes 集群的 DNS 功能。
+* 你必须启用 Kubernetes 集群的 DNS 功能。
* 如果使用基于云的 Kubernetes 集群或 {{< glossary_tooltip text="Minikube" term_id="minikube" >}}，则可能已经启用了集群 DNS。
- * 如果您正在使用 `hack/local-up-cluster.sh`，请确保设置了 `KUBE_ENABLE_CLUSTER_DNS` 环境变量，然后运行安装脚本。
+ * 如果你正在使用 `hack/local-up-cluster.sh`，请确保设置了 `KUBE_ENABLE_CLUSTER_DNS` 环境变量，然后运行安装脚本。
* [安装和设置 v1.7 或更高版本的 kubectl](/zh/docs/tasks/tools/install-kubectl/)，确保将其配置为连接到 Kubernetes 集群。
-* 安装 v2.7.0 或更高版本的 [Helm](http://helm.sh/)。
+* 安装 v2.7.0 或更高版本的 [Helm](https://helm.sh/)。
* 遵照 [Helm 安装说明](https://github.com/kubernetes/helm/blob/master/docs/install.md)。
* 如果已经安装了适当版本的 Helm，请执行 `helm init` 来安装 Helm 的服务器端组件 Tiller。
-
-
<!-- steps -->
<!--
## Add the service-catalog Helm repository
+
+Once Helm is installed, add the *service-catalog* Helm repository to your local machine by executing the following command:
-->
## 添加 service-catalog Helm 仓库
-<!--
-Once Helm is installed, add the *service-catalog* Helm repository to your local machine by executing the following command:
--->
安装 Helm 后，通过执行以下命令将 *service-catalog* Helm 存储库添加到本地计算机：
```shell
@@ -83,18 +77,16 @@ svc-cat/catalog 0.0.1 service-catalog API server and controller-manag...
<!--
## Enable RBAC
+
+Your Kubernetes cluster must have RBAC enabled, which requires your Tiller Pod(s) to have `cluster-admin` access.
+
+If you are using Minikube, run the `minikube start` command with the following flag:
-->
## 启用 RBAC
-<!--
-Your Kubernetes cluster must have RBAC enabled, which requires your Tiller Pod(s) to have `cluster-admin` access.
--->
-您的 Kubernetes 集群必须启用 RBAC，这需要您的 Tiller Pod 具有 `cluster-admin` 访问权限。
+你的 Kubernetes 集群必须启用 RBAC，这需要你的 Tiller Pod 具有 `cluster-admin` 访问权限。
-<!--
-If you are using Minikube, run the `minikube start` command with the following flag:
--->
-如果您使用的是 Minikube，请使用以下参数运行 `minikube start` 命令：
+如果你使用的是 Minikube，请使用以下参数运行 `minikube start` 命令：
```shell
minikube start --extra-config=apiserver.Authorization.Mode=RBAC
@@ -103,7 +95,7 @@ minikube start --extra-config=apiserver.Authorization.Mode=RBAC
<!--
If you are using `hack/local-up-cluster.sh`, set the `AUTHORIZATION_MODE` environment variable with the following values:
-->
-如果您使用 `hack/local-up-cluster.sh`，请使用以下值设置 `AUTHORIZATION_MODE` 环境变量：
+如果你使用 `hack/local-up-cluster.sh`，请使用以下值设置 `AUTHORIZATION_MODE` 环境变量：
```
AUTHORIZATION_MODE=Node,RBAC hack/local-up-cluster.sh -O
@@ -114,11 +106,12 @@ By default, `helm init` installs the Tiller Pod into the `kube-system` namespace
-->
默认情况下，`helm init` 将 Tiller Pod 安装到 `kube-system` 命名空间，Tiller 配置为使用 `default` 服务帐户。
-{{< note >}}
<!--
If you used the `--tiller-namespace` or `--service-account` flags when running `helm init`, the `--serviceaccount` flag in the following command needs to be adjusted to reference the appropriate namespace and ServiceAccount name.
-->
-如果在运行 `helm init` 时使用了 `--tiller-namespace` 或 `--service-account` 参数，则需要调整以下命令中的 `--serviceaccount` 参数以引用相应的 namespace 和 ServiceAccount 名称。
+{{< note >}}
+如果在运行 `helm init` 时使用了 `--tiller-namespace` 或 `--service-account` 参数，
+则需要调整以下命令中的 `--serviceaccount` 参数以引用相应的名字空间和服务账号名称。
{{< /note >}}
<!--
@@ -134,12 +127,11 @@ kubectl create clusterrolebinding tiller-cluster-admin \
<!--
## Install Service Catalog in your Kubernetes cluster
+
+Install Service Catalog from the root of the Helm repository using the following command:
-->
## 在 Kubernetes 集群中安装 Service Catalog
-<!--
-Install Service Catalog from the root of the Helm repository using the following command:
--->
使用以下命令从 Helm 存储库的根目录安装 Service Catalog：
{{< tabs name="helm-versions" >}}
@@ -149,11 +141,12 @@ helm install catalog svc-cat/catalog --namespace catalog
```
{{% /tab %}}
{{% tab name="Helm version 2" %}}
+
```shell
helm install svc-cat/catalog --name catalog --namespace catalog
```
-
-
+{{% /tab %}}
+{{< /tabs >}}
## {{% heading "whatsnext" %}}
@@ -163,3 +156,4 @@ helm install svc-cat/catalog --name catalog --namespace catalog
-->
* 查看[示例服务代理](https://github.com/openservicebrokerapi/servicebroker/blob/mastergettingStarted.md#sample-service-brokers)。
* 探索 [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) 项目。
+
diff --git a/content/zh/docs/tasks/service-catalog/install-service-catalog-using-sc.md b/content/zh/docs/tasks/service-catalog/install-service-catalog-using-sc.md
index dd179932c5..3139539017 100644
--- a/content/zh/docs/tasks/service-catalog/install-service-catalog-using-sc.md
+++ b/content/zh/docs/tasks/service-catalog/install-service-catalog-using-sc.md
@@ -6,26 +6,23 @@ content_type: task
---
<!--
----
title: Install Service Catalog using SC
reviewers:
- chenopis
content_type: task
----
-->
<!-- overview -->
-{{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}}
+{{< glossary_definition term_id="service-catalog" length="all" prepend="服务目录（Service Catalog）是" >}}
<!--
Use the [Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation) tool to easily install or uninstall Service Catalog on your Kubernetes cluster. This CLI tool is installed as `sc` in your local environment.
-->
-使用[服务目录安装程序](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation)工具可以轻松地在 Kubernetes 集群上安装或卸载服务目录。
+使用[服务目录安装程序](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation)
+工具可以轻松地在 Kubernetes 集群上安装或卸载服务目录。
这个 CLI 工具以 `sc` 命令形式被安装在您的本地环境中。
-
-
## {{% heading "prerequisites" %}}
<!--
@@ -38,27 +35,25 @@ Use the [Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-s
kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=<user-name>
-->
-* 了解[服务目录](/docs/concepts/service-catalog/)的主要概念。
+* 了解[服务目录](/zh/docs/concepts/service-catalog/)的主要概念。
* 安装 [Go 1.6+](https://golang.org/dl/) 以及设置 `GOPATH`。
* 安装生成 SSL 工件所需的 [cfssl](https://github.com/cloudflare/cfssl) 工具。
* 服务目录需要 Kubernetes 1.7+ 版本。
-* [安装和设置 kubectl](/docs/tasks/tools/install-kubectl/)，以便将其配置为连接到 Kubernetes v1.7+ 集群。
+* [安装和设置 kubectl](/zh/docs/tasks/tools/install-kubectl/)，以便将其配置为连接到 Kubernetes v1.7+ 集群。
* 要安装服务目录，kubectl 用户必须绑定到 *cluster-admin* 角色。为了确保这是正确的，请运行以下命令：
- kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=<user-name>
-
-
-
+ ```
+ kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=<user-name>
+ ```
<!-- steps -->
<!--
## Install `sc` in your local environment
+
+Install the `sc` CLI tool using the `go get` command:
-->
## 在本地环境中安装 `sc`
-<!--
-Install the `sc` CLI tool using the `go get` command:
--->
使用 `go get` 命令安装 `sc` CLI 工具：
```Go
@@ -72,12 +67,11 @@ After running the above command, `sc` should be installed in your `GOPATH/bin` d
<!--
## Install Service Catalog in your Kubernetes cluster
+
+First, verify that all dependencies have been installed. Run:
-->
## 在 Kubernetes 集群中安装服务目录
-<!--
-First, verify that all dependencies have been installed. Run:
--->
首先，检查是否已经安装了所有依赖项。运行：
```shell
@@ -104,20 +98,17 @@ sc install --etcd-backup-storageclass "standard"
<!--
## Uninstall Service Catalog
+
+If you would like to uninstall Service Catalog from your Kubernetes cluster using the `sc` tool, run:
-->
## 卸载服务目录
-<!--
-If you would like to uninstall Service Catalog from your Kubernetes cluster using the `sc` tool, run:
--->
如果您想使用 `sc` 工具从 Kubernetes 集群卸载服务目录，请运行：
```shell
sc uninstall
```
-
-
## {{% heading "whatsnext" %}}
<!--
diff --git a/content/zh/docs/tasks/tls/_index.md b/content/zh/docs/tasks/tls/_index.md
old mode 100755
new mode 100644
diff --git a/content/zh/docs/tasks/tls/certificate-rotation.md b/content/zh/docs/tasks/tls/certificate-rotation.md
index 398ffe23cf..681a6f3a18 100644
--- a/content/zh/docs/tasks/tls/certificate-rotation.md
+++ b/content/zh/docs/tasks/tls/certificate-rotation.md
@@ -1,45 +1,89 @@
---
-approvers:
-- jcbsmpsn
-- mikedanese
-title: 证书轮换
+title: 为 kubelet 配置证书轮换
content_type: task
---
+<!--
+reviewers:
+- jcbsmpsn
+- mikedanese
+title: Configure Certificate Rotation for the Kubelet
+content_type: task
+-->
<!-- overview -->
+<!--
+This page shows how to enable and configure certificate rotation for the kubelet.
+-->
本文展示如何在 kubelet 中启用并配置证书轮换。
+{{< feature-state for_k8s_version="v1.8" state="beta" >}}
## {{% heading "prerequisites" %}}
-
+<!--
+* Kubernetes version 1.8.0 or later is required
+-->
* 要求 Kubernetes 1.8.0 或更高的版本
-* Kubelet 证书轮换在 1.8.0 版本中处于 beta 阶段, 这意味着该特性可能在没有通知的情况下发生变化。
-
-
-
<!-- steps -->
+<!--
+## Overview
+
+The kubelet uses certificates for authenticating to the Kubernetes API. By
+default, these certificates are issued with one year expiration so that they do
+not need to be renewed too frequently.
+-->
## 概述
Kubelet 使用证书进行 Kubernetes API 的认证。
默认情况下，这些证书的签发期限为一年，所以不需要太频繁地进行更新。
-Kubernetes 1.8 版本中包含 beta 特性 [kubelet 证书轮换](/docs/tasks/administer-cluster/certificate-rotation/)，
+<!--
+Kubernetes 1.8 contains [kubelet certificate
+rotation](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), a beta feature
+that will automatically generate a new key and request a new certificate from
+the Kubernetes API as the current certificate approaches expiration. Once the
+new certificate is available, it will be used for authenticating connections to
+the Kubernetes API.
+-->
+Kubernetes 1.8 版本中包含 beta 特性
+[kubelet 证书轮换](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)，
在当前证书即将过期时，
将自动生成新的秘钥，并从 Kubernetes API 申请新的证书。 一旦新的证书可用，它将被用于与
Kubernetes API 间的连接认证。
+<!--
+## Enabling client certificate rotation
+
+The `kubelet` process accepts an argument `--rotate-certificates` that controls
+if the kubelet will automatically request a new certificate as the expiration of
+the certificate currently in use approaches. Since certificate rotation is a
+beta feature, the feature flag must also be enabled with
+`--feature-gates=RotateKubeletClientCertificate=true`.
+-->
## 启用客户端证书轮换
`kubelet` 进程接收 `--rotate-certificates` 参数，该参数决定 kubelet 在当前使用的证书即将到期时，
-是否会自动申请新的证书。 由于证书轮换是 beta 特性，必须通过参数 `--feature-gates=RotateKubeletClientCertificate=true` 进行启用。
-
+是否会自动申请新的证书。 由于证书轮换是 beta 特性，必须通过参数
+`--feature-gates=RotateKubeletClientCertificate=true` 进行启用。
+<!--
+The `kube-controller-manager` process accepts an argument
+`--experimental-cluster-signing-duration` that controls how long certificates
+will be issued for.
+-->
`kube-controller-manager` 进程接收
`--experimental-cluster-signing-duration` 参数，该参数控制证书签发的有效期限。
+<!--
+## Understanding the certificate rotation configuration
+
+When a kubelet starts up, if it is configured to bootstrap (using the
+`--bootstrap-kubeconfig` flag), it will use its initial certificate to connect
+to the Kubernetes API and issue a certificate signing request. You can view the
+status of certificate signing requests using:
+-->
## 理解证书轮换配置
当 kubelet 启动时，如被配置为自举（使用`--bootstrap-kubeconfig` 参数），kubelet 会使用其初始证书连接到
@@ -49,18 +93,38 @@ Kubernetes API ，并发送证书签名的请求。 可以通过以下方式查
kubectl get csr
```
+<!--
+Initially a certificate signing request from the kubelet on a node will have a
+status of `Pending`. If the certificate signing requests meets specific
+criteria, it will be auto approved by the controller manager, then it will have
+a status of `Approved`. Next, the controller manager will sign a certificate,
+issued for the duration specified by the
+`--experimental-cluster-signing-duration` parameter, and the signed certificate
+will be attached to the certificate signing requests.
+-->
最初，来自节点上 kubelet 的证书签名请求处于 `Pending` 状态。 如果证书签名请求满足特定条件，
控制器管理器会自动批准，此时请求会处于 `Approved` 状态。 接下来，控制器管理器会签署证书，
证书的有效期限由 `--experimental-cluster-signing-duration` 参数指定，签署的证书会被附加到证书签名请求中。
+<!--
+The kubelet will retrieve the signed certificate from the Kubernetes API and
+write that to disk, in the location specified by `--cert-dir`. Then the kubelet
+will use the new certificate to connect to the Kubernetes API.
+-->
Kubelet 会从 Kubernetes API 取回签署的证书，并将其写入磁盘，存储位置通过 `--cert-dir` 参数指定。
然后 kubelet 会使用新的证书连接到 Kubernetes API。
+<!--
+As the expiration of the signed certificate approaches, the kubelet will
+automatically issue a new certificate signing request, using the Kubernetes
+API. Again, the controller manager will automatically approve the certificate
+request and attach a signed certificate to the certificate signing request. The
+kubelet will retrieve the new signed certificate from the Kubernetes API and
+write that to disk. Then it will update the connections it has to the
+Kubernetes API to reconnect using the new certificate.
+-->
当签署的证书即将到期时，kubelet 会使用 Kubernetes API，发起新的证书签名请求。
同样地，控制器管理器会自动批准证书请求，并将签署的证书附加到证书签名请求中。 Kubelet
会从 Kubernetes API 取回签署的证书，并将其写入磁盘。 然后它会更新与 Kubernetes API
的连接，使用新的证书重新连接到 Kubernetes API。
-
-
-
diff --git a/content/zh/docs/tasks/tools/install-minikube.md b/content/zh/docs/tasks/tools/install-minikube.md
index fce7facc9d..270524f109 100644
--- a/content/zh/docs/tasks/tools/install-minikube.md
+++ b/content/zh/docs/tasks/tools/install-minikube.md
@@ -8,14 +8,12 @@ card:
---
<!--
----
title: Install Minikube
content_type: task
weight: 20
card:
name: tasks
weight: 10
----
-->
<!-- overview -->
@@ -23,14 +21,10 @@ card:
<!--
This page shows you how to install [Minikube](/docs/tutorials/hello-minikube), a tool that runs a single-node Kubernetes cluster in a virtual machine on your personal computer.
-->
-
-本页面讲述如何安装 [Minikube](/docs/tutorials/hello-minikube)，该工具用于在您电脑中的虚拟机上运行一个单节点的 Kubernetes 集群。
-
-
+本页面讲述如何安装 [Minikube](/zh/docs/tutorials/hello-minikube)，该工具用于在你电脑中的虚拟机上运行一个单节点的 Kubernetes 集群。
## {{% heading "prerequisites" %}}
-
{{< tabs name="minikube_before_you_begin" >}}
{{% tab name="Linux" %}}
@@ -38,7 +32,7 @@ This page shows you how to install [Minikube](/docs/tutorials/hello-minikube), a
To check if virtualization is supported on Linux, run the following command and verify that the output is non-empty:
-->
-若要检查您的 Linux 是否支持虚拟化技术，请运行下面的命令并验证输出结果是否不为空：
+若要检查你的 Linux 是否支持虚拟化技术，请运行下面的命令并验证输出结果是否不为空：
```
grep -E --color 'vmx|svm' /proc/cpuinfo
@@ -51,8 +45,7 @@ grep -E --color 'vmx|svm' /proc/cpuinfo
<!--
To check if virtualization is supported on macOS, run the following command on your terminal.
-->
-
-若要检查您的 macOS 是否支持虚拟化技术，请运行下面的命令：
+若要检查你的 macOS 是否支持虚拟化技术，请运行下面的命令：
```
sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
@@ -61,8 +54,7 @@ sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
<!--
If you see `VMX` in the output (should be colored), the VT-x feature is enabled in your machine.
-->
-
-如果你在输出结果中看到了 `VMX` （应该会高亮显示）的字眼，说明您的电脑已启用 VT-x 特性。
+如果你在输出结果中看到了 `VMX` （应该会高亮显示）的字眼，说明你的电脑已启用 VT-x 特性。
{{% /tab %}}
@@ -70,8 +62,7 @@ If you see `VMX` in the output (should be colored), the VT-x feature is enabled
<!--
To check if virtualization is supported on Windows 8 and above, run the following command on your Windows terminal or command prompt.
-->
-
-若要检查您的 Windows8 及以上的系统是否支持虚拟化技术，请终端或者 cmd 中运行以下命令：
+若要检查你的 Windows8 及以上的系统是否支持虚拟化技术，请终端或者 cmd 中运行以下命令：
```
systeminfo
@@ -79,8 +70,7 @@ systeminfo
<!--
If you see the following output, virtualization is supported on Windows.
-->
-
-如果您看到下面的输出，则表示该 Windows 支持虚拟化技术。
+如果你看到下面的输出，则表示该 Windows 支持虚拟化技术。
```
Hyper-V Requirements: VM Monitor Mode Extensions: Yes
@@ -92,24 +82,19 @@ Hyper-V Requirements: VM Monitor Mode Extensions: Yes
<!--
If you see the following output, your system already has a Hypervisor installed and you can skip the next step.
-->
-
-如果您看到下面的输出，则表示您的操作系统已经安装了 Hypervisor，您可以跳过安装 Hypervisor 的步骤。
+如果你看到下面的输出，则表示你的操作系统已经安装了 Hypervisor，你可以跳过安装 Hypervisor 的步骤。
```
Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed.
```
-
{{% /tab %}}
{{< /tabs >}}
-
-
<!-- steps -->
<!--
# Installing minikube
-->
-
## 安装 minikube
{{< tabs name="tab_with_md" >}}
@@ -120,10 +105,10 @@ Hyper-V Requirements: A hypervisor has been detected. Features required for
Make sure you have kubectl installed. You can install kubectl according to the instructions in [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux).
-->
-
### 安装 kubectl
-请确保你已正确安装 kubectl。您可以根据[安装并设置 kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux) 的说明来安装 kubectl。
+请确保你已正确安装 kubectl。你可以根据[安装并设置 kubectl](/zh/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux)
+的说明来安装 kubectl。
<!--
### Install a Hypervisor
@@ -141,9 +126,8 @@ If you do not already have a hypervisor installed, install one of these now:
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
-->
-• [KVM](https://www.linux-kvm.org/)，也使用了 QEMU
-
-• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
+- [KVM](https://www.linux-kvm.org/)，KVM 也使用了 QEMU
+- [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
<!--
Minikube also supports a `--vm-driver=none` option that runs the Kubernetes components on the host and not in a VM.
@@ -153,19 +137,17 @@ If you're using the `none` driver in Debian or a derivative, use the `.deb` pack
Docker rather than the snap package, which does not work with Minikube.
You can download `.deb` packages from [Docker](https://www.docker.com/products/docker-desktop).
-->
-
-Minikube 还支持使用一个 `--vm-driver=none` 选项，让 Kubernetes 组件运行在主机中，而不是在 VM 中。
+Minikube 还支持使用一个 `--vm-driver=none` 选项，让 Kubernetes 组件运行在主机上，而不是在 VM 中。
使用这种驱动方式需要 [Docker](https://www.docker.com/products/docker-desktop) 和 Linux 环境，但不需要 hypervisor。
如果你在 Debian 系的 OS 中使用了 `none` 这种驱动方式，请使用 `.deb` 包安装 Docker，不要使用 snap 包的方式，Minikube 不支持这种方式。
你可以从 [Docker](https://www.docker.com/products/docker-desktop) 下载 `.deb` 包。
-{{< caution >}}
<!--
The `none` VM driver can result in security and data loss issues.
Before using `--vm-driver=none`, consult [this documentation](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) for more information.
-->
-
+{{< caution >}}
`none` VM 驱动方式存在导致安全和数据丢失的问题。
使用 `--vm-driver=none` 之前，请参考[这个文档](https://minikube.sigs.k8s.io/docs/reference/drivers/none/)获取详细信息。
{{< /caution >}}
@@ -173,15 +155,16 @@ Before using `--vm-driver=none`, consult [this documentation](https://minikube.s
<!--
Minikube also supports a `vm-driver=podman` similar to the Docker driver. Podman run as superuser privilege (root user) is the best way to ensure that your containers have full access to any feature available on your system.
-->
-
Minikube 还支持另外一个类似于 Docker 驱动的方式 `vm-driver=podman`。
-使用超级用户权限（root 用户）运行 Podman 可以最好的确保容器具有足够的权限使用你操作系统上的所有特性。
+使用超级用户权限（root 用户）运行 Podman 可以最好的确保容器具有足够的权限使用
+你的操作系统上的所有特性。
-{{< caution >}}
<!--
The `podman` driver requires running the containers as root because regular user accounts don’t have full access to all operating system features that their containers might need to run.
-->
-`Podman` 驱动方式需要以 root 用户身份运行容器，因为普通用户帐户没有足够的权限使用容器运行可能需要的操作系统上的所有特性。
+{{< caution >}}
+`Podman` 驱动需要以 root 用户身份运行容器，因为普通用户帐户没有足够的权限
+使用容器运行可能需要的操作系统上的所有特性。
{{< /caution >}}
<!--
@@ -192,12 +175,11 @@ from Minikube's [releases](https://github.com/kubernetes/minikube/releases) page
Use your Linux's distribution's package tool to install a suitable package.
-->
-
### 使用包安装 Minikube
-Minikube 有 *实验性* 的安装包。你可以在 Minikube 在 GitHub 上的 [releases](https://github.com/kubernetes/minikube/releases) 找到 Linux (AMD64) 的包。
+Minikube 有 *实验性* 的安装包。你可以在 Minikube 在 GitHub 上的[发行版本](https://github.com/kubernetes/minikube/releases) 找到 Linux (AMD64) 的包。
-根据您的 Linux 发行版选择安装合适的包。
+根据你的 Linux 发行版选择安装合适的包。
<!--
### Install Minikube via direct download
@@ -205,7 +187,6 @@ Minikube 有 *实验性* 的安装包。你可以在 Minikube 在 GitHub 上的
If you're not installing via a package, you can download a stand-alone
binary and use that.
-->
-
### 直接下载并安装 Minikube
如果你不想通过包安装，你也可以下载并使用一个单节点二进制文件。
@@ -218,7 +199,7 @@ curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/miniku
<!--
Here's an easy way to add the Minikube executable to your path:
-->
-将 Minikube 可执行文件添加至 path：
+将 Minikube 可执行文件添加至 PATH：
```shell
sudo mkdir -p /usr/local/bin/
@@ -230,7 +211,6 @@ sudo install minikube /usr/local/bin/
As yet another alternative, you can install Minikube using Linux [Homebrew](https://docs.brew.sh/Homebrew-on-Linux):
-->
-
### 使用 Homebrew 安装 Minikube
你还可以使用 Linux [Homebrew](https://docs.brew.sh/Homebrew-on-Linux) 安装 Minikube：
@@ -240,6 +220,7 @@ brew install minikube
```
{{% /tab %}}
+
{{% tab name="macOS" %}}
<!--
@@ -247,32 +228,28 @@ brew install minikube
Make sure you have kubectl installed. You can install kubectl according to the instructions in [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos).
-->
-
### 安装 kubectl
-请确保你已正确安装 kubectl。您可以根据[安装并设置 kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux) 的说明来安装 kubectl。
+请确保你已正确安装 kubectl。你可以根据[安装并设置 kubectl](/zh/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux)
+的说明来安装 kubectl。
<!--
### Install a Hypervisor
If you do not already have a hypervisor installed, install one of these now:
-->
-
### 安装 Hypervisor
如果你还没有安装 hypervisor，请选择以下方式之一进行安装：
• [HyperKit](https://github.com/moby/hyperkit)
-
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
-
• [VMware Fusion](https://www.vmware.com/products/fusion)
<!--
### Install Minikube
The easiest way to install Minikube on macOS is using [Homebrew](https://brew.sh):
-->
-
### 安装 Minikube
macOS 安装 Minikube 最简单的方法是使用 [Homebrew](https://brew.sh)：
@@ -284,8 +261,7 @@ brew install minikube
<!--
You can also install it on macOS by downloading a stand-alone binary:
-->
-
-你也可以通过下载单节点二进制文件进行安装：
+你也可以通过下载独立的可执行文件进行安装：
```shell
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \
@@ -295,8 +271,7 @@ curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/miniku
<!--
Here's an easy way to add the Minikube executable to your path:
-->
-
-这是一个简单的将 Minikube 可执行文件添加至 path 的方法：
+下面是一个简单的将 Minikube 可执行文件添加至 PATH 的方法：
```shell
sudo mv minikube /usr/local/bin
@@ -310,29 +285,27 @@ sudo mv minikube /usr/local/bin
Make sure you have kubectl installed. You can install kubectl according to the instructions in [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows).
-->
-
### 安装 kubectl
-请确保你已正确安装 kubectl。您可以根据[安装并设置 kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows) 的说明来安装 kubectl。
+请确保你已正确安装 kubectl。你可以根据[安装并设置 kubectl](/zh/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows)
+的说明来安装 kubectl。
<!--
### Install a Hypervisor
If you do not already have a hypervisor installed, install one of these now:
-->
-
### 安装 Hypervisor
如果你还没有安装 hypervisor，请选择以下方式之一进行安装：
• [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install)
-
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
-{{< note >}}
<!--
Hyper-V can run on three versions of Windows 10: Windows 10 Enterprise, Windows 10 Professional, and Windows 10 Education.
-->
+{{< note >}}
Hyper-V 可以运行在三个版本的 Windows 10 上：企业版、专业版和教育版（Enterprise, Professional, Education）。
{{< /note >}}
@@ -341,7 +314,6 @@ Hyper-V 可以运行在三个版本的 Windows 10 上：企业版、专业版和
The easiest way to install Minikube on Windows is using [Chocolatey](https://chocolatey.org/) (run as an administrator):
-->
-
### 使用 Chocolatey 安装 Minikube
Windows 安装 Minikube 最简单的方法是使用 [Chocolatey](https://chocolatey.org/) （以管理员身份运行）：
@@ -353,7 +325,6 @@ choco install minikube
<!--
After Minikube has finished installing, close the current CLI session and restart. Minikube should have been added to your path automatically.
-->
-
完成 Minikube 的安装后，关闭当前 CLI 界面再重新打开。
Minikube 应该已经自动添加至 path 中。
@@ -372,7 +343,6 @@ To install Minikube manually on Windows using [Windows Installer](https://docs.m
To install Minikube manually on Windows, download [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest), rename it to `minikube.exe`, and add it to your path.
-->
-
### 直接下载并安装 Minikube
想在 Windows 上手动安装 Minikube，下载 [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest) 并将其重命名为 `minikube.exe`，然后将其添加至 path 即可。
@@ -380,15 +350,11 @@ To install Minikube manually on Windows, download [`minikube-windows-amd64`](htt
{{% /tab %}}
{{< /tabs >}}
-
-
-
<!--
## Confirm Installation
To confirm successful installation of both a hypervisor and Minikube, you can run the following command to start up a local Kubernetes cluster:
-->
-
## 安装确认
要确认 hypervisor 和 Minikube 均已成功安装，可以运行以下命令来启动本地 Kubernetes 集群：
@@ -396,10 +362,11 @@ To confirm successful installation of both a hypervisor and Minikube, you can ru
<!--
For setting the `--vm-driver` with `minikube start`, enter the name of the hypervisor you installed in lowercase letters where `<driver_name>` is mentioned below. A full list of `--vm-driver` values is available in [specifying the VM driver documentation](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver).
-->
-
{{< note >}}
-若要为 `minikube start` 设置 `--vm-driver`，在下面提到 `<driver_name>` 的地方，用小写字母输入你安装的 hypervisor 的名称。
-[指定 VM 驱动程序](/docs/setup/learning-environment/minikube/#specifying-the-vm-driver) 列举了 `--vm-driver` 值的完整列表。
+若要为 `minikube start` 设置 `--vm-driver`，在下面提到 `<驱动名称>` 的地方，
+用小写字母输入你安装的 hypervisor 的名称。
+[指定 VM 驱动程序](/zh/docs/setup/learning-environment/minikube/#specifying-the-vm-driver)
+列举了 `--vm-driver` 值的完整列表。
{{< /note >}}
{{< note >}}
@@ -407,15 +374,14 @@ For setting the `--vm-driver` with `minikube start`, enter the name of the hyper
{{< /note >}}
```shell
-minikube start --vm-driver=<driver_name>
-# Or when you need
-minikube start --vm-driver=<driver_name> --image-repository=registry.cn-hangzhou.aliyuncs.com/google_containers
+minikube start --vm-driver=<驱动名称>
+# 或者在需要时
+minikube start --vm-driver=<驱动名称> --image-repository=registry.cn-hangzhou.aliyuncs.com/google_containers
```
<!--
Once `minikube start` finishes, run the command below to check the status of the cluster:
-->
-
一旦 `minikube start` 完成，你可以运行下面的命令来检查集群的状态：
```shell
@@ -425,7 +391,6 @@ minikube status
<!--
If your cluster is running, the output from `minikube status` should be similar to:
-->
-
如果你的集群正在运行，`minikube status` 的输出结果应该类似于这样：
```
@@ -438,8 +403,7 @@ kubeconfig: Configured
<!--
After you have confirmed whether Minikube is working with your chosen hypervisor, you can continue to use Minikube or you can stop your cluster. To stop your cluster, run:
-->
-
-在确认 Minikube 与 hypervisor 均正常工作后，您可以继续使用 Minikube 或停止集群。要停止集群，请运行：
+在确认 Minikube 与 hypervisor 均正常工作后，你可以继续使用 Minikube 或停止集群。要停止集群，请运行：
```shell
minikube stop
@@ -450,40 +414,33 @@ minikube stop
If you have previously installed Minikube, and run:
-->
+## 清理本地状态 {#cleanup-local-state}
-## 清理本地状态{#cleanup-local-state}
-
-如果您之前安装过 Minikube，并运行了：
+如果你之前安装过 Minikube，并运行了：
```shell
minikube start
```
-<!--
-and `minikube start` returned an error:
--->
-
+<!-- and `minikube start` returned an error: -->
并且 `minikube start` 返回了一个错误：
+
```
machine does not exist
```
-<!--
-then you need to clear minikube's local state:
--->
-
+<!-- then you need to clear minikube's local state: -->
那么，你需要清理 minikube 的本地状态：
+
```shell
minikube delete
```
-
## {{% heading "whatsnext" %}}
-
-
<!--
* [Running Kubernetes Locally via Minikube](/docs/setup/learning-environment/minikube/)
-->
-* [使用 Minikube 在本地运行 Kubernetes](/docs/setup/learning-environment/minikube/)
+* [使用 Minikube 在本地运行 Kubernetes](/zh/docs/setup/learning-environment/minikube/)
+
diff --git a/content/zh/docs/tutorials/_index.md b/content/zh/docs/tutorials/_index.md
index 97db0a8e7e..0125b0e9ca 100644
--- a/content/zh/docs/tutorials/_index.md
+++ b/content/zh/docs/tutorials/_index.md
@@ -123,36 +123,6 @@ Before walking through each tutorial, you may want to bookmark the
* [Running ZooKeeper, A CP Distributed System](/docs/tutorials/stateful-application/zookeeper/)
-->
-## CI/CD 管道
-
-<!--
-## CI/CD Pipeline
--->
-
-* [用 Kubernetes 第一部分：概述建立 CI/CD 管道](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/5/set-cicd-pipeline-kubernetes-part-1-overview)
-
-<!--
-* [Set Up a CI/CD Pipeline with Kubernetes Part 1: Overview](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/5/set-cicd-pipeline-kubernetes-part-1-overview)
--->
-
-* [与 Kubernetes 中的 Jenkins Pod 一起建立 CI/CD 管道(第二部分)](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/6/set-cicd-pipeline-jenkins-pod-kubernetes-part-2)
-
-<!--
-* [Set Up a CI/CD Pipeline with a Jenkins Pod in Kubernetes (Part 2)](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/6/set-cicd-pipeline-jenkins-pod-kubernetes-part-2)
--->
-
-* [在 Kubernetes 上运行并扩展一个带有 CI/CD 的分布式填字游戏应用程序(第三部分)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/run-and-scale-distributed-crossword-puzzle-app-cicd-kubernetes-part-3)
-
-<!--
-* [Run and Scale a Distributed Crossword Puzzle App with CI/CD on Kubernetes (Part 3)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/run-and-scale-distributed-crossword-puzzle-app-cicd-kubernetes-part-3)
--->
-
-* [为 Kubernetes 上的分布式填字游戏应用程序设置 CI/CD (第四部分))](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/set-cicd-distributed-crossword-puzzle-app-kubernetes-part-4)
-
-<!--
-* [Set Up CI/CD for a Distributed Crossword Puzzle App on Kubernetes (Part 4)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/set-cicd-distributed-crossword-puzzle-app-kubernetes-part-4)
--->
-
## 集群
* [AppArmor](/zh/docs/tutorials/clusters/apparmor/)
diff --git a/content/zh/examples/admin/sched/clusterrole.yaml b/content/zh/examples/admin/sched/clusterrole.yaml
new file mode 100644
index 0000000000..554b8659db
--- /dev/null
+++ b/content/zh/examples/admin/sched/clusterrole.yaml
@@ -0,0 +1,37 @@
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+ annotations:
+ rbac.authorization.kubernetes.io/autoupdate: "true"
+ labels:
+ kubernetes.io/bootstrapping: rbac-defaults
+ name: system:kube-scheduler
+rules:
+ - apiGroups:
+ - coordination.k8s.io
+ resources:
+ - leases
+ verbs:
+ - create
+ - apiGroups:
+ - coordination.k8s.io
+ resourceNames:
+ - kube-scheduler
+ - my-scheduler
+ resources:
+ - leases
+ verbs:
+ - get
+ - update
+ - apiGroups:
+ - ""
+ resourceNames:
+ - kube-scheduler
+ - my-scheduler
+ resources:
+ - endpoints
+ verbs:
+ - delete
+ - get
+ - patch
+ - update
diff --git a/layouts/_default/baseof.html b/layouts/_default/baseof.html
index e85e55e474..612bddbb2c 100644
--- a/layouts/_default/baseof.html
+++ b/layouts/_default/baseof.html
@@ -3,7 +3,7 @@
<head>
{{ partial "head.html" . }}
</head>
- <body class="td-{{ .Kind }}">
+ <body class="td-{{ .Kind }}{{- if ne .Params.cid "" -}}{{- printf " cid-%s" (lower .Params.cid) -}}{{- end -}}">
<header>
{{ partial "navbar.html" . }}
</header>
@@ -27,7 +27,7 @@
</section>
{{ block "post-hero" . }}
{{ block "deprecated" . }}
- {{ if .IsHome }}
+ {{ if or .IsHome ( eq .Params.cid "partners" ) ( eq .Params.cid "community" ) }}
{{ partial "deprecation-warning.html" . }}
{{ end }}
{{ end }}
diff --git a/layouts/blog/baseof.html b/layouts/blog/baseof.html
index 09099263a5..0e03cce7d5 100644
--- a/layouts/blog/baseof.html
+++ b/layouts/blog/baseof.html
@@ -27,6 +27,9 @@
{{ partial "blog-sidebar.html" . }}
</div>
<main class="col-12 col-md-9 col-xl-8 pl-md-5 pr-md-4" role="main">
+ {{ block "deprecated" . }}
+ {{ partial "deprecation-warning.html" . }}
+ {{ end }}
{{ with .CurrentSection.OutputFormats.Get "rss" -}}
<a class="btn btn-lg -bg-orange td-rss-button d-none d-lg-block" href="{{ .Permalink | safeURL }}" target="_blank">
RSS <i class="fa fa-rss ml-2 "></i>
diff --git a/layouts/case-studies/list.html b/layouts/case-studies/list.html
index deec393953..06dc81d865 100644
--- a/layouts/case-studies/list.html
+++ b/layouts/case-studies/list.html
@@ -12,6 +12,7 @@
<section id="mainContent">
<div class="main-section">
<div class="content">
+ {{ partial "deprecation-warning.html" . }}
<div class="case-studies">
{{ range $featured }}
{{ template "case-study-featured-block" (dict "ctx" $ "page" .) }}
diff --git a/layouts/case-studies/single-baseof.html b/layouts/case-studies/single-baseof.html
index 64b48a4e13..23b0894543 100644
--- a/layouts/case-studies/single-baseof.html
+++ b/layouts/case-studies/single-baseof.html
@@ -5,6 +5,7 @@
</head>
<body>
{{ partial "navbar.html" . }}
+ {{ partial "deprecation-warning.html" . }}
{{ block "main" . }}{{ end }}
{{ partialCached "footer.html" . }}
<!-- Disabling this as elements queries do not appear to exist on case studies -->
diff --git a/layouts/docs/baseof.html b/layouts/docs/baseof.html
index 2b5aea8268..04ca30871b 100644
--- a/layouts/docs/baseof.html
+++ b/layouts/docs/baseof.html
@@ -4,18 +4,11 @@
{{ partial "head.html" . }}
<title>{{ if .IsHome }}{{ .Site.Title }}{{ else }}{{ with .Title }}{{ . }} | {{ end }}{{ .Site.Title }}{{ end }}
-
+
{{ partial "navbar.html" . }}
{{ partial "announcement.html" . }}
-
-
The `kubeadm` tool helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
+
+ 
+
+ 
+ 
+ 
+
+
+
+
+
+