Initial commit for Ukrainian localization (#18569 )

* Initial commit for Ukrainian localization * Fix misspell and crosslink * Add Nikita Potapenko to PR reviewers https://github.com/kubernetes/website/pull/18569#issuecomment-573014402 Co-authored-by: Anastasiya Kulyk <56824659+anastyakulyk@users.noreply.github.com>
Fix typo and remove duplicate reference (#17666 )
2020-01-13 08:51:38 -08:00 · 2020-01-13 04:43:37 -08:00 · 2020-01-13 04:35:36 -08:00 · 2020-01-13 00:53:37 -08:00 · 2020-01-13 00:51:37 -08:00 · 2020-01-13 00:49:38 -08:00
73 changed files with 2115 additions and 918 deletions
@@ -216,3 +216,11 @@ aliases:
    - aisonaku
    - potapy4
    - dianaabv
+  sig-docs-uk-owners: # Admins for Ukrainian content
+    - anastyakulyk
+    - MaxymVlasov
+  sig-docs-uk-reviews: # PR reviews for Ukrainian content
+    - anastyakulyk
+    - idvoretskyi
+    - MaxymVlasov
+    - Potapy4
@@ -0,0 +1,71 @@
+# Документація Kubernetes
+
+[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website)
+[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
+
+Вітаємо! В цьому репозиторії міститься все необхідне для роботи над [вебсайтом і документацією Kubernetes](https://kubernetes.io/). Ми щасливі, що ви хочете зробити свій внесок!
+
+## Внесок у документацію
+
+Ви можете створити копію цього репозиторія у своєму акаунті на GitHub, натиснувши на кнопку **Fork**, що розташована справа зверху. Ця копія називатиметься *fork* (відгалуження). Зробіть будь-які необхідні зміни у своєму відгалуженні. Коли ви будете готові надіслати їх нам, перейдіть до свого відгалуження і створіть новий pull request, щоб сповістити нас.
+
+Після того, як ви створили pull request, рецензент Kubernetes зобов’язується надати вам по ньому чіткий і конструктивний коментар. **Ваш обов’язок як творця pull request - відкоригувати його відповідно до зауважень рецензента Kubernetes.** Також, зауважте: може статися так, що ви отримаєте коментарі від декількох рецензентів Kubernetes або від іншого рецензента, ніж той, якого вам було призначено від початку. Крім того, за потреби один із ваших рецензентів може запросити технічну перевірку від одного з [технічних рецензентів Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers). Рецензенти намагатимуться відреагувати вчасно, проте час відповіді може відрізнятися в залежності від обставин.
+
+Більше інформації про внесок у документацію Kubernetes ви знайдете у наступних джерелах:
+
+* [Внесок: з чого почати](https://kubernetes.io/docs/contribute/start/)
+* [Візуалізація запропонованих змін до документації](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
+* [Використання шаблонів сторінок](http://kubernetes.io/docs/contribute/style/page-templates/)
+* [Керівництво зі стилю оформлення документації](http://kubernetes.io/docs/contribute/style/style-guide/)
+* [Переклад документації Kubernetes іншими мовами](https://kubernetes.io/docs/contribute/localization/)
+
+## Запуск сайту локально за допомогою Docker
+
+Для локального запуску вебсайту Kubernetes рекомендовано запустити спеціальний [Docker](https://docker.com)-образ, що містить генератор статичних сайтів [Hugo](https://gohugo.io).
+
+> Якщо ви працюєте під Windows, вам знадобиться ще декілька інструментів, які можна встановити за допомогою [Chocolatey](https://chocolatey.org). `choco install make`
+
+> Якщо ви вважаєте кращим запустити вебсайт локально без використання Docker, дивіться пункт нижче [Запуск сайту локально за допомогою Hugo](#запуск-сайту-локально-зa-допомогою-hugo).
+
+Якщо у вас вже [запущений](https://www.docker.com/get-started) Docker, зберіть локальний Docker-образ `kubernetes-hugo`:
+
+```bash
+make docker-image
+```
+
+Після того, як образ зібрано, ви можете запустити вебсайт локально:
+
+```bash
+make docker-serve
+```
+
+Відкрийте у своєму браузері http://localhost:1313, щоб побачити вебсайт. По мірі того, як ви змінюєте початковий код, Hugo актуалізує вебсайт відповідно до внесених змін і оновлює сторінку у браузері.
+
+## Запуск сайту локально зa допомогою Hugo
+
+Для інструкцій по установці Hugo дивіться [офіційну документацію](https://gohugo.io/getting-started/installing/). Обов’язково встановіть розширену версію Hugo, яка позначена змінною оточення `HUGO_VERSION` у файлі [`netlify.toml`](netlify.toml#L9).
+
+Після установки Hugo запустіть вебсайт локально командою:
+
+```bash
+make serve
+```
+
+Команда запустить локальний Hugo-сервер на порту 1313. Відкрийте у своєму браузері http://localhost:1313, щоб побачити вебсайт. По мірі того, як ви змінюєте початковий код, Hugo актуалізує вебсайт відповідно до внесених змін і оновлює сторінку у браузері.
+
+## Спільнота, обговорення, внесок і підтримка
+
+Дізнайтеся, як долучитися до спільноти Kubernetes на [сторінці спільноти](http://kubernetes.io/community/).
+
+Для зв’язку із супроводжуючими проекту скористайтеся:
+
+- [Slack](https://kubernetes.slack.com/messages/sig-docs)
+- [Поштова розсилка](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
+
+### Кодекс поведінки
+
+Участь у спільноті Kubernetes визначається правилами [Кодексу поведінки спільноти Kubernetes](code-of-conduct.md).
+
+## Дякуємо!
+
+Долучення до спільноти - запорука успішного розвитку Kubernetes. Ми цінуємо ваш внесок у наш вебсайт і документацію!
@@ -27,7 +27,7 @@ For more information about contributing to the Kubernetes documentation, see:
 |[Hindi README](README-hi.md)|[Spanish README](README-es.md)|
 |[Indonesian README](README-id.md)|[Chinese README](README-zh.md)|
 |[Japanese README](README-ja.md)|[Vietnamese README](README-vi.md)|
-|[Russian README](README-ru.md)|
+|[Russian README](README-ru.md)|[Ukrainian README](README-uk.md)
 |||

 ## Running the website locally using Docker
@@ -246,7 +246,7 @@ language_alternatives = ["en"]

 [languages.id]
 title = "Kubernetes"
-description = "Production-Grade Container Orchestration"
+description = "Orkestrasi Kontainer dengan Skala Produksi"
 languageName ="Bahasa Indonesia"
 weight = 10
 contentDir = "content/id"
@@ -286,3 +286,14 @@ time_format_blog = "02.01.2006"
 # A list of language codes to look for untranslated content, ordered from left to right.
 language_alternatives = ["en"]

+[languages.uk]
+title = "Kubernetes"
+description = "Довершена система оркестрації контейнерів"
+languageName = "Українська"
+weight = 13
+contentDir = "content/uk"
+
+[languages.uk.params]
+time_format_blog = "02.01.2006"
+# A list of language codes to look for untranslated content, ordered from left to right.
+language_alternatives = ["en"]
@@ -20,11 +20,11 @@ Dieser Abschnitt der Kubernetes-Dokumentation enthält Referenzinformationen.

 * [Kubernetes API Überblick](/docs/reference/using-api/api-overview/) - Übersicht über die API für Kubernetes.
 * Kubernetes API Versionen
+  * [1.17](/docs/reference/generated/kubernetes-api/v1.17/)
+  * [1.16](/docs/reference/generated/kubernetes-api/v1.16/)
+  * [1.15](/docs/reference/generated/kubernetes-api/v1.15/)
  * [1.14](/docs/reference/generated/kubernetes-api/v1.14/)
  * [1.13](/docs/reference/generated/kubernetes-api/v1.13/)
-  * [1.12](/docs/reference/generated/kubernetes-api/v1.12/)
-  * [1.11](/docs/reference/generated/kubernetes-api/v1.11/)
-  * [1.10](/docs/reference/generated/kubernetes-api/v1.10/)

 ## API-Clientbibliotheken

@@ -48,7 +48,7 @@ The following applications are now available:
 1. [Create a chart](https://github.com/kubernetes/helm/blob/master/docs/charts.md)
 2. Developer provides parameters via the [values.yaml](https://github.com/kubernetes/helm/blob/master/docs/charts.md#values-files) file allowing users to customize their deployment. This can be seen as the API between chart devs and chart users.
 3. A [README](https://github.com/kubernetes/charts/tree/master/stable/mariadb) is written to help describe the application and its parameterized values.
-4. Once the application installs properly and the values customize the deployment appropriately, the developer adds a [NOTES.txt](https://github.com/kubernetes/helm/blob/master/docs/charts.md#chart-license-readme-and-notes) file that is shown as soon as the user installs. This file generally points out the next steps for the user to connect to or use the application.
+4. Once the application installs properly and the values customize the deployment appropriately, the developer adds a [NOTES.txt](https://github.com/helm/helm/blob/dev-v2/docs/charts.md) file that is shown as soon as the user installs. This file generally points out the next steps for the user to connect to or use the application.
 5. If the application requires persistent storage, the developer adds a mechanism to store the data such that pod restarts do not lose data. Most charts requiring this today are using [dynamic volume provisioning](https://kubernetes.io/blog/2016/10/dynamic-provisioning-and-storage-in-kubernetes) to abstract away underlying storage details from the user which allows a single configuration to work against Kubernetes installations.
 6. Submit a [Pull Request to the Kubernetes Charts repo](https://github.com/kubernetes/charts/pulls). Once tested and reviewed, the PR will be merged.
 7. Once merged to the master branch, the chart will be packaged and released to Helm’s default repository and available for users to install.
@@ -5,7 +5,7 @@ tags:
 date: 2018-03-26
 modified_time: '2018-03-27T11:01:39.569-07:00'
 blogger_id: tag:blogger.com,1999:blog-112706738355446097.post-6519705795358457586
-blogger_orig_url: https://kubernetes.io/blog/2018/03/kubernetes-1.10-stabilizing-storage-security-networking
+blogger_orig_url: https://kubernetes.io/blog/2018/03/26/kubernetes-1.10-stabilizing-storage-security-networking/
 slug: kubernetes-1.10-stabilizing-storage-security-networking
 date: 2018-03-26
 ---
@@ -85,7 +85,7 @@ That way, your clients can always use the short form on the left, and always be
 As further reading, a more elaborate example for users is available in the [Multi-Cluster Service DNS with ExternalDNS guide](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/servicedns-with-externaldns.md).

 # Try it yourself
-To get started with Federation v2, please refer to the [user guide](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md). Deployment can be accomplished with a [Helm chart](https://github.com/kubernetes-sigs/federation-v2/blob/master/charts/federation-v2/README.md), and once the control plane is available, the [user guide’s example](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md#example) can be used to get some hands-on experience with using Federation V2.
+To get started with Federation v2, please refer to the [user guide](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md). Deployment can be accomplished with a [Helm chart](https://github.com/kubernetes-sigs/kubefed/blob/master/charts/kubefed/README.md), and once the control plane is available, the [user guide’s example](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md#example) can be used to get some hands-on experience with using Federation V2.

 Federation v2 can be deployed in both _cluster-scoped_ and _namespace-scoped_ configurations.  A cluster-scoped deployment will require cluster-admin privileges to both host and member clusters, and may be a good fit for evaluating federation on clusters that are not running critical workloads. Namespace-scoped deployment requires access to only a single namespace on host and member clusters, and is a better fit for evaluating federation on clusters running workloads.  Most of the user guide refers to cluster-scoped deployment, with the [namespaced federation](https://github.com/kubernetes-sigs/federation-v2/blob/master/docs/userguide.md#namespaced-federation) section documenting how use of a namespaced deployment differs.  The same cluster can host multiple federations, and clusters can be part of multiple federations when using namespaced federation.

@@ -229,6 +229,7 @@ The following cloud providers have implemented CCMs:
 * [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
 * [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
 * [GCP](https://github.com/kubernetes/cloud-provider-gcp)
+* [Hetzner](https://github.com/hetznercloud/hcloud-cloud-controller-manager)
 * [Linode](https://github.com/linode/linode-cloud-controller-manager)
 * [OpenStack](https://github.com/kubernetes/cloud-provider-openstack)
 * [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
@@ -23,7 +23,7 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply
 * [ACI](https://www.github.com/noironetworks/aci-containers) provides integrated container networking and network security with Cisco ACI.
 * [Calico](https://docs.projectcalico.org/latest/getting-started/kubernetes/) is a secure L3 networking and network policy provider.
 * [Canal](https://github.com/tigera/canal/tree/master/k8s-install) unites Flannel and Calico, providing networking and network policy.
-* [Cilium](https://github.com/cilium/cilium) is a L3 network and network policy plugin that can enforce HTTP/API/L7 policies transparently. Both routing and overlay/encapsulation mode are supported.
+* [Cilium](https://github.com/cilium/cilium) is a L3 network and network policy plugin that can enforce HTTP/API/L7 policies transparently. Both routing and overlay/encapsulation mode are supported, and it can work on top of other CNI plugins.
 * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Calico, Canal, Flannel, Romana, or Weave.
 * [Contiv](http://contiv.github.io) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](http://github.com/contiv). The [installer](http://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options.
 * [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is an open source, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide isolation modes for virtual machines, containers/pods and bare metal workloads.
@@ -125,7 +125,7 @@ BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](http
 providing and transparently securing network connectivity between application
 containers. Cilium is L7/HTTP aware and can enforce network policies on L3-L7
 using an identity based security model that is decoupled from network
-addressing.
+addressing, and it can be used in combination with other CNI plugins.

 ### CNI-Genie from Huawei

@@ -205,7 +205,7 @@ example, run these on your desktop/laptop:

 Verify by creating a pod that uses a private image, e.g.:

-```yaml
+```shell
 kubectl apply -f - <<EOF
 apiVersion: v1
 kind: Pod
@@ -218,20 +218,27 @@ spec:
      imagePullPolicy: Always
      command: [ "echo", "SUCCESS" ]
 EOF
+```
+```
 pod/private-image-test-1 created
 ```

-If everything is working, then, after a few moments, you should see:
+If everything is working, then, after a few moments, you can run:

 ```shell
 kubectl logs private-image-test-1
+```
+and see that the command outputs:
+```
 SUCCESS
 ```

-If it failed, then you will see:
-
+If you suspect that the command failed, you can run:
 ```shell
-kubectl describe pods/private-image-test-1 | grep "Failed"
+kubectl describe pods/private-image-test-1 | grep 'Failed'
+```
+In case of failure, the output is similar to:
+```
  Fri, 26 Jun 2015 15:36:13 -0700    Fri, 26 Jun 2015 15:39:13 -0700    19    {kubelet node-i2hq}    spec.containers{uses-private-image}    failed        Failed to pull image "user/privaterepo:v1": Error: image user/privaterepo:v1 not found
 ```

@@ -358,7 +365,8 @@ common use cases and suggested solutions.
   - Generate registry credential for each tenant, put into secret, and populate secret to each tenant namespace.
   - The tenant adds that secret to imagePullSecrets of each namespace.

-{{% /capture %}}

 If you need access to multiple registries, you can create one secret for each registry.
 Kubelet will merge any `imagePullSecrets` into a single virtual `.docker/config.json`
+
+{{% /capture %}}
@@ -361,7 +361,7 @@ podsecuritypolicy "example" deleted

 ### Example Policies

-This is the least restricted policy you can create, equivalent to not using the
+This is the least restrictive policy you can create, equivalent to not using the
 pod security policy admission controller:

 {{< codenew file="policy/privileged-psp.yaml" >}}
@@ -401,8 +401,6 @@ pods on the same node.
 network namespace. Defined as a list of `HostPortRange`, with `min`(inclusive)
 and `max`(inclusive). Defaults to no allowed host ports.

-**AllowedHostPaths** - See [Volumes and file systems](#volumes-and-file-systems).
-
 ### Volumes and file systems

 **Volumes** - Provides a whitelist of allowed volume types. The allowable values
@@ -17,7 +17,7 @@ Now that you have a continuously running, replicated application you can expose

 By default, Docker uses host-private networking, so containers can talk to other containers only if they are on the same machine. In order for Docker containers to communicate across nodes, there must be allocated ports on the machine’s own IP address, which are then forwarded or proxied to the containers. This obviously means that containers must either coordinate which ports they use very carefully or ports must be allocated dynamically.

-Coordinating ports across multiple developers is very difficult to do at scale and exposes users to cluster-level issues outside of their control. Kubernetes assumes that pods can communicate with other pods, regardless of which host they land on. We give every pod its own cluster-private-IP address so you do not need to explicitly create links between pods or map container ports to host ports. This means that containers within a Pod can all reach each other's ports on localhost, and all pods in a cluster can see each other without NAT. The rest of this document will elaborate on how you can run reliable services on such a networking model.
+Coordinating port allocations across multiple developers or teams that provide containers is very difficult to do at scale, and exposes users to cluster-level issues outside of their control. Kubernetes assumes that pods can communicate with other pods, regardless of which host they land on. Kubernetes gives every pod its own cluster-private IP address, so you do not need to explicitly create links between pods or map container ports to host ports. This means that containers within a Pod can all reach each other's ports on localhost, and all pods in a cluster can see each other without NAT. The rest of this document elaborates on how you can run reliable services on such a networking model.

 This guide uses a simple nginx server to demonstrate proof of concept. The same principles are embodied in a more complete [Jenkins CI application](https://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes).

@@ -49,7 +49,7 @@ ports:
    port: 80
 endpoints:
  - addresses:
-    - "10.1.2.3"
+      - "10.1.2.3"
    conditions:
      ready: true
    hostname: pod-1
@@ -22,6 +22,7 @@ Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.i

 ## Additional controllers

+* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress) is an ingress controller that enables ingress to [AKS clusters](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) using the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview).
 * [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io) based ingress 
  controller with [community](https://www.getambassador.io/docs) or 
  [commercial](https://www.getambassador.io/pro/) support from [Datawire](https://www.datawire.io/).
@@ -485,7 +485,7 @@ The default is `ClusterIP`.

     with its value. No proxying of any kind is set up.
     {{< note >}}
-     You need CoreDNS version 1.7 or higher to use the `ExternalName` type.
+     You need either kube-dns version 1.7 or CoreDNS version 0.0.8 or higher to use the `ExternalName` type.
     {{< /note >}}

 You can also use [Ingress](/docs/concepts/services-networking/ingress/) to expose your Service. Ingress is not a Service type, but it acts as the entry point for your cluster. It lets you consolidate your routing rules into a single resource as it can expose multiple services under the same IP address.
@@ -887,7 +887,7 @@ There are other annotations for managing Cloud Load Balancers on TKE as shown be
    metadata:
      name: my-service
      annotations:
-        # Bind Loadbalancers with speicfied nodes
+        # Bind Loadbalancers with specified nodes
        service.kubernetes.io/qcloud-loadbalancer-backends-label: key in (value1, value2)

        # ID of an existing load balancer
@@ -1015,7 +1015,7 @@ worth understanding.
 One of the primary philosophies of Kubernetes is that you should not be
 exposed to situations that could cause your actions to fail through no fault
 of your own. For the design of the Service resource, this means not making
-you choose your own port number for a if that choice might collide with
+you choose your own port number if that choice might collide with
 someone else's choice.  That is an isolation failure.

 In order to allow you to choose a port number for your Services, we must
@@ -24,7 +24,7 @@ can be represented as `1k`, and `1000000` as `1M`. You can also specify
 binary-notation suffixes; the number 2048 can be written as `2Ki`.

 The accepted decimal (power-of-10) units are `m` (milli), `k` (kilo,
-intentionally lowercase), `M` (mega), `G` (giga), `T` (terra), `P` (peta),
+intentionally lowercase), `M` (mega), `G` (giga), `T` (tera), `P` (peta),
 `E` (exa).

 The accepted binary (power-of-2) units are `Ki` (kibi), `Mi` (mebi), `Gi` (gibi),
@@ -161,7 +161,6 @@ kubectl get services --sort-by=.metadata.name
 kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'

 # List PersistentVolumes in test namespace sorted by capacity
-
 kubectl get pv -n test --sort-by=.spec.capacity.storage

 # Get the version label of all pods with label app=cassandra
@@ -195,6 +194,9 @@ kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secre

 # List Events sorted by timestamp
 kubectl get events --sort-by=.metadata.creationTimestamp
+
+# Compares the current state of the cluster against the state that the cluster would be in if the manifest was applied.
+kubectl diff -f ./my-manifest.yaml
 ```

 ## Updating Resources
@@ -260,7 +260,7 @@ These commands should be run after `kubeadm init` but before `kubeadm join`.
 ### Using kubeadm join with a configuration file {#config-file}

 {{< caution >}}
-The config file is still considered alpha and may change in future versions.
+The config file is still considered beta and may change in future versions.
 {{< /caution >}}

 It's possible to configure `kubeadm join` with a configuration file instead of command
@@ -117,7 +117,7 @@ brew update && brew install kops

 ### (2/5) Create a route53 domain for your cluster

-kops uses DNS for discovery, both inside the cluster and so that you can reach the kubernetes API server
+kops uses DNS for discovery, both inside the cluster and outside, so that you can reach the kubernetes API server
 from clients.

 kops has a strong opinion on the cluster name: it should be a valid DNS name.  By doing so you will
@@ -319,23 +319,12 @@ kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/canal.yaml
 {{% /tab %}}

 {{% tab name="Cilium" %}}
-For more information about using Cilium with Kubernetes, see [Kubernetes Install guide for Cilium](https://docs.cilium.io/en/stable/kubernetes/).
-
 For Cilium to work correctly, you must pass `--pod-network-cidr=10.217.0.0/16` to `kubeadm init`.

-These commands will deploy Cilium with its own etcd managed by etcd operator.
-
-_Note_: If you are running kubeadm in a single node please untaint it so that
-etcd-operator pods can be scheduled in the control-plane node.
-
-```shell
-kubectl taint nodes <node-name> node-role.kubernetes.io/master:NoSchedule-
-```
-
 To deploy Cilium you just need to run:

 ```shell
-kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.5/examples/kubernetes/1.14/cilium.yaml
+kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml
 ```

 Once all Cilium pods are marked as `READY`, you start using your cluster.
@@ -349,6 +338,10 @@ NAME           READY   STATUS    RESTARTS   AGE
 cilium-drxkl   1/1     Running   0          18m
 ```

+Cilium can be used as a replacement for kube-proxy, see [Kubernetes without kube-proxy](https://docs.cilium.io/en/stable/gettingstarted/kubeproxy-free).
+
+For more information about using Cilium with Kubernetes, see [Kubernetes Install guide for Cilium](https://docs.cilium.io/en/stable/kubernetes/).
+
 {{% /tab %}}

 {{% tab name="Contiv-VPP" %}}
@@ -217,7 +217,7 @@ systemctl enable --now kubelet
    `net.bridge.bridge-nf-call-iptables` is set to 1 in your `sysctl` config, e.g.

    ```bash
-    cat <<EOF >  /etc/sysctl.d/k8s.conf
+    cat <<EOF > /etc/sysctl.d/k8s.conf
    net.bridge.bridge-nf-call-ip6tables = 1
    net.bridge.bridge-nf-call-iptables = 1
    EOF
@@ -10,7 +10,7 @@ weight: 20
 {{% capture overview %}}
 This page shows how to use Cilium for NetworkPolicy.

-For background on Cilium, read the [Introduction to Cilium](https://cilium.readthedocs.io/en/stable/intro).
+For background on Cilium, read the [Introduction to Cilium](https://docs.cilium.io/en/stable/intro).
 {{% /capture %}}

 {{% capture prerequisites %}}
@@ -23,36 +23,45 @@ For background on Cilium, read the [Introduction to Cilium](https://cilium.readt
 ## Deploying Cilium on Minikube for Basic Testing

 To get familiar with Cilium easily you can follow the
-[Cilium Kubernetes Getting Started Guide](https://cilium.readthedocs.io/en/stable/gettingstarted/minikube/)
+[Cilium Kubernetes Getting Started Guide](https://docs.cilium.io/en/stable/gettingstarted/minikube/)
 to perform a basic DaemonSet installation of Cilium in minikube.

-To start minikube, minimal version required is >= v0.33.1, run the with the
+To start minikube, minimal version required is >= v1.3.1, run the with the
 following arguments:

 ```shell
 minikube version
 ```
 ```
-minikube version: v0.33.1
+minikube version: v1.3.1
 ```

 ```shell
 minikube start --network-plugin=cni --memory=4096
 ```

-For minikube you can deploy this simple ''all-in-one'' YAML file that includes
-DaemonSet configurations for Cilium, and the necessary configurations to connect
-to the etcd instance deployed in minikube as well as appropriate RBAC settings:
+Mount the BPF filesystem:

 ```shell
-kubectl create -f  https://raw.githubusercontent.com/cilium/cilium/v1.5/examples/kubernetes/1.14/cilium-minikube.yaml
+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:
+
+```shell
+kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml
 ```
 ```
 configmap/cilium-config created
-daemonset.apps/cilium created
-clusterrolebinding.rbac.authorization.k8s.io/cilium created
-clusterrole.rbac.authorization.k8s.io/cilium 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
@@ -62,7 +71,7 @@ policies using an example application.
 ## Deploying Cilium for Production Use

 For detailed instructions around deploying Cilium for production, see:
-[Cilium Kubernetes Installation Guide](https://cilium.readthedocs.io/en/stable/kubernetes/intro/)
+[Cilium Kubernetes Installation Guide](https://docs.cilium.io/en/stable/kubernetes/intro/)
 This documentation includes detailed requirements, instructions and example
 production DaemonSet files.

@@ -86,14 +95,8 @@ 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 a key-value store
-(e.g., etcd). The [Cilium Kubernetes Installation Guide](https://cilium.readthedocs.io/en/stable/kubernetes/intro/)
-will provide the necessary steps on how to install this required key-value
-store as well how to configure it in Cilium.

 {{% /capture %}}

@@ -356,7 +356,7 @@ and the Pod's `hostNetwork` field is true. Then `host`, under `httpGet`, should
 to 127.0.0.1. If your pod relies on virtual hosts, which is probably the more common
 case, you should not use `host`, but rather set the `Host` header in `httpHeaders`.

-For a probe, the kubelet makes the probe connection at the node, not in the pod, which
+For a TCP probe, the kubelet makes the probe connection at the node, not in the pod, which
 means that you can not use a service name in the `host` parameter since the kubelet is unable
 to resolve it.

@@ -592,7 +592,7 @@ basis. The [Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files

 ### Mounted ConfigMaps are updated automatically

-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.
+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.

 {{< note >}}
 A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive ConfigMap updates.
@@ -78,7 +78,7 @@ fi
 # optional argument handling
 if [[ "$1" == "config" ]]
 then
-    echo $KUBECONFIG
+    echo "$KUBECONFIG"
    exit 0
 fi

@@ -1,5 +1,6 @@
 ---
 title: Running Automated Tasks with a CronJob
+min-kubernetes-server-version: v1.8
 reviewers:
 - chenopis
 content_template: templates/task
@@ -24,7 +25,7 @@ For more limitations, see [CronJobs](/docs/concepts/workloads/controllers/cron-j

 {{% capture prerequisites %}}

-* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+* {{< include "task-tutorial-prereqs.md" >}}

 {{% /capture %}}

@@ -1,5 +1,6 @@
 ---
 title: Coarse Parallel Processing Using a Work Queue
+min-kubernetes-server-version: v1.8
 content_template: templates/task
 weight: 30
 ---
@@ -30,7 +31,7 @@ Here is an overview of the steps in this example:
 Be familiar with the basic,
 non-parallel, use of [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/).

-{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+{{< include "task-tutorial-prereqs.md" >}}

 {{% /capture %}}

@@ -1,6 +1,7 @@
 ---
 title: Fine Parallel Processing Using a Work Queue
 content_template: templates/task
+min-kubernetes-server-version: v1.8
 weight: 40
 ---

@@ -29,7 +30,7 @@ Here is an overview of the steps in this example:

 {{% capture prerequisites %}}

-{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+{{< include "task-tutorial-prereqs.md" >}}

 {{% /capture %}}

@@ -1,6 +1,7 @@
 ---
 title: Parallel Processing using Expansions
 content_template: templates/concept
+min-kubernetes-server-version: v1.8
 weight: 20
 ---

@@ -2,6 +2,7 @@
 reviewers:
 - lachie83
 - khenidak
+min-kubernetes-server-version: v1.16
 title: Validate IPv4/IPv6 dual-stack
 content_template: templates/task
 ---
@@ -12,12 +13,13 @@ This document shares how to validate IPv4/IPv6 dual-stack enabled Kubernetes clu

 {{% capture 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)
 * Kubenet network plugin
 * Kube-proxy running in mode IPVS
 * [Dual-stack enabled](/docs/concepts/services-networking/dual-stack/) cluster

+{{< version-check >}}
+
 {{% /capture %}}

 {{% capture steps %}}
@@ -114,13 +114,13 @@ the name of the MySQL Service defined above, and WordPress will access the datab
      
 3. Add them to `kustomization.yaml` file.

-      ```shell
-      cat <<EOF >>./kustomization.yaml
-      resources:
-        - mysql-deployment.yaml
-        - wordpress-deployment.yaml
-      EOF
-      ```
+```shell
+cat <<EOF >>./kustomization.yaml
+resources:
+  - mysql-deployment.yaml
+  - wordpress-deployment.yaml
+EOF
+```

 ## Apply and Verify
 The `kustomization.yaml` contains all the resources for deploying a WordPress site and a 
@@ -1,4 +1,4 @@
 FROM node:6.14.2
 EXPOSE 8080
 COPY server.js .
-CMD node server.js
+CMD [ "node", "server.js" ]
@@ -1,7 +1,7 @@
 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 by using
-[Minikube](/docs/setup/minikube),
+[Minikube](/docs/setup/learning-environment/minikube/),
 or you can use one of these Kubernetes playgrounds:

 * [Katacoda](https://www.katacoda.com/courses/kubernetes/playground)
@@ -0,0 +1,21 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: nginx-deployment
+  labels:
+    app: nginx
+spec:
+  replicas: 3
+  selector:
+    matchLabels:
+      app: nginx
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.7.9
+        ports:
+        - containerPort: 80
@@ -7,7 +7,7 @@ content_template: templates/concept

 {{% capture overview %}}

-В данном разделе документации Kubernetes можно найти руководства. В каждом руководстве показывано, как достичь определённой цели, а не просто выполнить одно задание (/docs/tasks/). Большинство уроков состоят из нескольких разделов, каждая из которых включает в себя последовательность шагов для выполнения. Перед тем как приступить к выполнению уроков, может быть полезно сохранить [Стандартизированный Словарь](/docs/reference/glossary/) для последующих обращений.
+В данном разделе документации Kubernetes можно найти руководства. В них рассказывается, как достичь определённой цели, а не просто выполнить одно задачу (/docs/tasks/). Большинство уроков состоит из нескольких разделов, каждый из которых включает в себя шаги для последовательного выполнения. Перед тем как приступить к выполнению уроков, может быть полезно ознакомиться со [словарем терминов](/docs/reference/glossary/) для последующих обращений.

 {{% /capture %}}

@@ -15,7 +15,7 @@ content_template: templates/concept

 ## Основы

-* [Основы Kubernetes](/docs/tutorials/kubernetes-basics/) - глубокое инерактивное руководства, направленный на понимание системы Kubernetes и предлагающий попробовать некоторые основные возможности Kubernetes.
+* [Основы Kubernetes](/docs/tutorials/kubernetes-basics/) - глубокое интерактивное руководство, направленное на понимание системы и предлагающее попробовать некоторые основные возможности Kubernetes.

 * [Масштабируемые микросервисы с Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)

@@ -29,7 +29,7 @@ content_template: templates/concept

 ## Stateless приложения

-* [Установка внешнего IP Address для получения доступа к приложению в кластере](/docs/tutorials/stateless-application/expose-external-ip-address/)
+* [Установка внешнего IP адреса для получения доступа к приложению в кластере](/docs/tutorials/stateless-application/expose-external-ip-address/)

 * [Пример: развёртывание приложения "Гостевая книга" на PHP с использованием Redis](/docs/tutorials/stateless-application/guestbook/)

@@ -49,7 +49,7 @@ content_template: templates/concept

 * [Настройка 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  в KubernetesR (Часть 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 (Часть 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)

@@ -65,6 +65,6 @@ content_template: templates/concept

 {{% capture whatsnext %}}

-Если вы хотите создать руководство самостоятельно, обратитесь к странице [Использование шаблонов страниц](/docs/home/contribute/page-templates/), чтобы узнать информацию и посмотреть шаблоны для составлении руководств.
+Если вы хотите создать руководство самостоятельно, обратитесь к странице [Использование шаблонов страниц](/docs/home/contribute/page-templates/), чтобы узнать информацию и посмотреть шаблоны для составления руководств.

 {{% /capture %}}
@@ -11,13 +11,13 @@ card:
 ---

 {{% capture overview %}}
-Эта страница посвящена обзору Kubernetes.
+Эта страница посвящена краткому обзору Kubernetes.
 {{% /capture %}}

 {{% capture body %}}
-Kubernetes - это портативная расширяемая платформа с открытым исходным кодом для управления контейнерными рабочими нагрузками и службами, которая облегчает декларативную настройку и автоматизацию. У платформы есть большая, быстро растущая экосистема. Kubernetes службы, поддержка и инструменты широко доступны.
+Kubernetes — это портативная расширяемая платформа с открытым исходным кодом для управления контейнеризованными рабочими нагрузками и сервисами, которая облегчает как декларативную настройку, так и автоматизацию. У платформы есть большая, быстро растущая экосистема. Сервисы, поддержка и инструменты Kubernetes широко доступны.

-Название Kubernetes происходит от греческого, что означает рулевой или штурман. Google открыл проект Kubernetes в 2014 году. Kubernetes базируется на [десятилетнем опыте Google, при работе с масштабными рабочими нагрузками](https://ai.google/research/pubs/pub43438), в сочетании с лучшими в своем классе идеями и практиками сообщества.
+Название Kubernetes происходит от греческого, что означает рулевой или штурман. Google открыл исходный код Kubernetes в 2014 году. Kubernetes основывается на [десятилетнем опыте работе Google с масштабными рабочими нагрузками](https://ai.google/research/pubs/pub43438), в сочетании с лучшими в своем классе идеями и практиками сообщества.

 ## История
 Давайте вернемся назад и посмотрим, почему Kubernetes так полезен.
@@ -25,67 +25,67 @@ Kubernetes - это портативная расширяемая платфор
 ![Эволюция развертывания](/images/docs/Container_Evolution.svg)

 **Традиционная эра развертывания:**
-Ранее организации запускали приложения на физических серверах. Не было никакого способа определить границы ресурсов для приложений на физическом сервере, и это вызвало проблемы с распределением ресурсов. Например, если несколько приложений выполняются на физическом сервере, могут быть случаи, когда одно приложение будет занимать большую часть ресурсов, и в результате другие приложения будут работать хуже. Решением для этого было бы запустить каждое приложение на другом физическом сервере. Но это не масштабировалось, поскольку ресурсы использовались непрактично, и организациям было дорого поддерживать множество физических серверов.
+Ранее организации запускали приложения на физических серверах. Не было никакого способа определить границы ресурсов для приложений на физическом сервере, и это вызвало проблемы с распределением ресурсов. Например, если несколько приложений выполняются на физическом сервере, могут быть случаи, когда одно приложение будет занимать большую часть ресурсов, и в результате чего другие приложения будут работать хуже. Решением этого было запустить каждое приложение на другом физическом сервере. Но это не масштабировалось, поскольку ресурсы использовались не полностью, из-за чего организациям было накладно поддерживать множество физических серверов.

-**Эра виртуального развертывания:**  В качестве решения была введена виртуализация. Это позволило запускать несколько виртуальных машин (ВМ) на одном физическом сервере ЦП. Виртуализация позволяет изолировать приложения между виртуальными машинами и обеспечивает уровень безопасности, поскольку информация одного приложения не может быть свободно доступна другому приложению.
+**Эра виртуального развертывания:**  В качестве решения была представлена виртуализация. Она позволила запускать несколько виртуальных машин (ВМ) на одном физическом сервере. Виртуализация изолирует приложения между виртуальными машинами и обеспечивает определенный уровень безопасности, поскольку информация одного приложения не может быть свободно доступна другому приложению.

-Виртуализация позволяет лучше использовать ресурсы на физическом сервере и обеспечивает лучшую масштабируемость, поскольку приложение можно легко добавить или обновить, также снижаются затраты на оборудование и многое другое. С помощью виртуализации вы можете представить набор физических ресурсов в виде кластера одноразовых виртуальных машин.
+Виртуализация позволяет лучше использовать ресурсы на физическом сервере и обеспечивает лучшую масштабируемость, поскольку приложение можно легко добавить или обновить, кроме этого снижаются затраты на оборудование и многое другое. С помощью виртуализации можно превратить набор физических ресурсов в кластер одноразовых виртуальных машин.

 Каждая виртуальная машина представляет собой полноценную машину, на которой выполняются все компоненты, включая собственную операционную систему, поверх виртуализированного оборудования.

 **Эра контейнеров:** Контейнеры похожи на виртуальные машины, но у них есть свойства изоляции для совместного использования операционной системы (ОС) между приложениями. Поэтому контейнеры считаются легкими. Подобно виртуальной машине, контейнер имеет свою собственную файловую систему, процессор, память, пространство процесса и многое другое. Поскольку они не связаны с базовой инфраструктурой, они переносимы между облаками и дистрибутивами ОС.

-Контейнеры стали популярными, потому что они предоставляют дополнительные преимущества, например:
+Контейнеры стали популярными из-за таких дополнительных преимуществ как:

 * Гибкое создание и развертывание приложений: простота и эффективность создания образа контейнера по сравнению с использованием образа виртуальной машины.
 * Непрерывная разработка, интеграция и развертывание: обеспечивает надежную и частую сборку и развертывание образа контейнера с быстрым и простым откатом (благодаря неизменности образа).
-* Разделение задач между Dev и Ops: создавайте образы контейнеров приложений во время сборки / релиза, а не во время развертывания, тем самым отделяя приложения от инфраструктуры.
+* Разделение задач между Dev и Ops: создавайте образы контейнеров приложений во время сборки/релиза, а не во время развертывания, тем самым отделяя приложения от инфраструктуры.
 * Наблюдаемость охватывает не только информацию и метрики на уровне ОС, но также информацию о работоспособности приложений и другие сигналы.
 * Идентичная окружающая среда при разработке, тестировании и релизе: на ноутбуке работает так же, как и в облаке.
 * Переносимость облачных и операционных систем: работает на Ubuntu, RHEL, CoreOS, on-prem, Google Kubernetes Engine и в любом другом месте.
 * Управление, ориентированное на приложения: повышает уровень абстракции от запуска ОС на виртуальном оборудовании до запуска приложения в ОС с использованием логических ресурсов.
-* Слабосвязанные, распределенные, гибкие, выделенные микроуслуги: приложения разбиты на более мелкие независимые части, которые можно динамически развертывать и управлять ими, а не монолитным стеком, работающим на одной большой специализированной машине.
+* Слабосвязанные, распределенные, гибкие, выделенные микросервисы: вместо монолитного стека на одной большой выделенной машине, приложения разбиты на более мелкие независимые части, которые можно динамически развертывать и управлять.
 * Изоляция ресурсов: предсказуемая производительность приложения.
 * Грамотное использование ресурсов: высокая эффективность и компактность.

 ## Зачем вам Kubernetes и что он может сделать?

-Контейнеры - хороший способ связать и запустить ваши приложения. В производственной среде вам необходимо управлять контейнерами, которые запускают приложения, и обеспечивать отсутствие простоев. Например, если контейнер выходит из строя, необходимо запустить другой контейнер. Не было бы проще, если бы такое поведение обрабатывалось системой?
+Контейнеры — отличный способ связать и запустить ваши приложения. В производственной среде необходимо управлять контейнерами, которые запускают приложения, и гарантировать отсутствие простоев. Например, если контейнер выходит из строя, необходимо запустить другой контейнер. Не было бы проще, если бы такое поведение обрабатывалось системой?

-Вот тут Kubernetes приходит на помощь! Kubernetes предоставляет вам платформу для гибкой работы распределенных систем. Он заботится о масштабировании и обработке ошибок для вашего приложения, предоставляет шаблоны развертывания и многое другое. Например, Kubernetes может легко управлять canary-развертыванием для вашей системы.
+Вот тут Kubernetes приходит на помощь! Kubernetes дает вам фреймворк для гибкой работы распределенных систем. Он занимается масштабированием и обработкой ошибок в приложении, предоставляет шаблоны развертывания и многое другое. Например, Kubernetes может легко управлять канареечным развертыванием вашей системы.

 Kubernetes предоставляет вам:

-* **Мониторинг сервисов и распределение нагрузки**  
-Kubernetes может обноружить контейнер, используя DNS-имя или собственный IP-адрес. Если трафик в контейнере высокий, Kubernetes может сбалансировать нагрузку и распределить сетевой трафик, чтобы развертывание было стабильным.
-* **Орекстрация хранилища**  
+* **Мониторинг сервисов и распределение нагрузки**
+Kubernetes может обнаружить контейнер, используя имя DNS или собственный IP-адрес. Если трафик в контейнере высокий, Kubernetes может сбалансировать нагрузку и распределить сетевой трафик, чтобы развертывание было стабильным.
+* **Орекстрация хранилища**
 Kubernetes позволяет вам автоматически смонтировать систему хранения по вашему выбору, такую как локальное хранилище, провайдеры общедоступного облака и многое другое.
-* **Автоматическое развертывание и откаты**  
-Вы можете описать желаемое состояние для ваших развернутых контейнеров, используя Kubernetes, и это может изменить фактическое состояние на желаемое состояние с высокой скоростью. Например, вы можете автоматизировать Kubernetes для создания новых контейнеров для вашего развертывания, удаления существующих контейнеров и распределения всех их ресурсов в новый контейнер.
-* **Автоматическое распределение нагрузки**  
-Вы предоставляете Kubernetes кластерных нод, который он может использовать для запуска контейнерных задач. Вы сообщаете Kubernetes, сколько ЦП и памяти (ОЗУ) требуется каждому контейнеру. Kubernetes может разместить контейнеры на ваших нодах, чтобы наилучшим образом использовать ваши ресурсы.
-* **Самоконтроль**  
-Kubernetes перезапускает контейнеры, которые дают сбой, заменяет контейнеры, убивает контейнеры, которые не отвечают на ваши проверки работоспособности, определенные пользователем, и не показывает их клиентам, пока они не будут готовы к обслуживанию.
-* **Управление конфиденциальной информацией и конфигурацией**  
-Kubernetes позволяет хранить и управлять конфиденциальной информацией, такой как пароли, токены OAuth и ключи ssh. Вы можете развертывать и обновлять конфиденциальную информацию и конфигурацию приложения, не перестраивая образы контейнеров и не раскрывая конфиденциальную информацию в конфигурации стека.
+* **Автоматическое развертывание и откаты**
+Используя Kubernetes можно описать желаемое состояние развернутых контейнеров и изменить фактическое состояние на желаемое. Например, вы можете автоматизировать Kubernetes на создание новых контейнеров для развертывания, удаления существующих контейнеров и распределения всех их ресурсов в новый контейнер.
+* **Автоматическое распределение нагрузки**
+Вы предоставляете Kubernetes кластер узлов, который он может использовать для запуска контейнерных задач. Вы указываете Kubernetes, сколько ЦП и памяти (ОЗУ) требуется каждому контейнеру. Kubernetes может разместить контейнеры на ваших узлах так, чтобы наиболее эффективно использовать ресурсы.
+* **Самоконтроль**
+Kubernetes перезапускает отказавшие контейнеры, заменяет и завершает работу контейнеров, которые не проходят определенную пользователем проверку работоспособности, и не показывает их клиентам, пока они не будут готовы к обслуживанию.
+* **Управление конфиденциальной информацией и конфигурацией**
+Kubernetes может хранить и управлять конфиденциальной информацией, такой как пароли, OAuth-токены и ключи SSH. Вы можете развертывать и обновлять конфиденциальную информацию и конфигурацию приложения без изменений образов контейнеров и не раскрывая конфиденциальную информацию в конфигурации стека.

 ## Чем Kubernetes не является

-Kubernetes - это не традиционная комплексная система PaaS (платформа как услуга). Поскольку Kubernetes работает на уровне контейнеров, а не на уровне оборудования, он предоставляет некоторые общеприменимые функции, общие для PaaS, такие как развертывание, масштабирование, балансировка нагрузки, ведение журналов и мониторинг. Тем не менее, Kubernetes не является монолитным, и эти решения по умолчанию являются дополнительными и подключаемыми. Kubernetes предоставляет строительные блоки для построения платформы, но сохраняет выбор за пользователем и гибкость там, где это важно.
+Kubernetes ― это не традиционная комплексная система PaaS (платформа как услуга). Поскольку Kubernetes работает на уровне контейнеров, а не на уровне оборудования, у него имеется определенные общеприменимые возможности, характерные для PaaS, такие как развертывание, масштабирование, балансировка нагрузки, ведение журналов и мониторинг. Тем не менее, Kubernetes это не монолитное решение, поэтому указанные возможности по умолчанию являются дополнительными и подключаемыми. У Kubernetes есть компоненты для создания платформы разработчика, но он сохраняет право выбора за пользователем и гибкость там, где это важно.

 Kubernetes:

-* Не ограничивает типы поддерживаемых приложений. Kubernetes стремится поддерживать чрезвычайно разнообразные рабочие нагрузки, включая рабочие нагрузки без сохранения состояния и обработки данных. Если приложение может работать в контейнере, оно должно отлично работать в Kubernetes.
-* Не развертывает исходный код и не создает ваше приложение. Рабочие процессы непрерывной интеграции, доставки и развертывания (CI / CD) определяются культурой и предпочтениями организации, а также техническими требованиями.
-* Не предоставляет сервисы уровня приложения, такие как промежуточное программное обеспечение (например, очереди сообщений), платформы обработки данных (например, Spark), базы данных (например, mysql), кэши или кластерные системы хранения (например, Ceph), как встроенные сервисы. Такие компоненты могут работать в Kubernetes и / или могут быть доступны для приложений, работающих в Kubernetes, через переносные механизмы, такие как Open Service Broker.
-* Не требует ведения журнала, мониторинга или оповещения. Он обеспечивает некоторые интеграции в качестве доказательства концепции и механизмы для сбора и экспорта метрик.
-* Не предоставляет и не требует настройки языка / системы (например, jsonnet). Он предоставляет декларативный API, который может быть нацелен на произвольные формы декларативных спецификаций.
+* Не ограничивает типы поддерживаемых приложений. Kubernetes стремится поддерживать широкий спектр рабочих нагрузок, включая те, у которых есть или отсутствует состояние, а также связанные с обработкой данных. Если приложение может работать в контейнере, оно должно отлично работать и в Kubernetes.
+* Не развертывает исходный код и не собирает приложение. Рабочие процессы непрерывной интеграции, доставки и развертывания (CI/CD) определяются культурой и предпочтениями организации, а также техническими требованиями.
+* Не предоставляет сервисы для приложения, такие как промежуточное программное обеспечение (например, очереди сообщений), платформы обработки данных (например, Spark), базы данных (например, MySQL), кеши или кластерные системы хранения (например, Ceph), как встроенные сервисы. Такие компоненты могут работать в Kubernetes и/или могут быть доступны для приложений, работающих в Kubernetes, через переносные механизмы, такие как Open Service Broker.
+* Не включает решения для ведения журнала, мониторинга или оповещения. Он обеспечивает некоторые интеграции в качестве доказательства концепции и механизмы для сбора и экспорта метрик.
+* Не указывает и не требует настройки языка/системы (например, Jsonnet). Он предоставляет декларативный API, который может быть нацелен на произвольные формы декларативных спецификаций.
 * Не предоставляет и не принимает никаких комплексных систем конфигурации, технического обслуживания, управления или самовосстановления.
-* Кроме того, Kubernetes - это не просто система оркестровки. Фактически это устраняет необходимость в оркестровке. Техническое определение оркестровки - это выполнение определенного рабочего процесса: сначала делайте A, затем B, затем C. В отличие от этого, Kubernetes содержит набор независимых, компонуемых процессов управления, которые непрерывно приводят текущее состояние к предоставленному желаемому состоянию. Неважно, как добраться от А до С. Централизованный контроль также не требуется. В результате получается система, которая более проста в использовании и является более мощной, надежной, устойчивой и расширяемой.
+* Кроме того, Kubernetes — это не просто система оркестрации. Фактически, Kubernetes устраняет необходимость в этом. Техническое определение оркестрации — это выполнение определенного рабочего процесса: сначала сделай A, затем B, затем C. Напротив, Kubernetes содержит набор независимых, компонуемых процессов управления, которые непрерывно переводит текущее состояние к предполагаемому состоянию. Неважно, как добраться от А до С. Не требуется также централизованный контроль. Это делает систему более простой в использовании, более мощной, надежной, устойчивой и расширяемой.

 {{% /capture %}}

 {{% capture whatsnext %}}
-*   Посмотрите на [Компоненты Kubernetes](/docs/concepts/overview/components/)
+*   Изучите [Компоненты Kubernetes](/docs/concepts/overview/components/)
 *   Готовы [начать](/docs/setup/)?
 {{% /capture %}}
@@ -20,6 +20,7 @@ content_template: templates/concept

 * [Обзор Kubernetes API](/docs/reference/using-api/api-overview/) - Обзор API для Kubernetes.
 * Версии Kubernetes API
+  * [1.17](/docs/reference/generated/kubernetes-api/v1.17/)
  * [1.16](/docs/reference/generated/kubernetes-api/v1.16/)
  * [1.15](/docs/reference/generated/kubernetes-api/v1.15/)
  * [1.14](/docs/reference/generated/kubernetes-api/v1.14/)
@@ -40,8 +41,8 @@ content_template: templates/concept

 * [kubectl](/docs/user-guide/kubectl-overview) - Основной инструмент CLI для запуска команд и управления кластерами Kubernetes.
    * [JSONPath](/docs/user-guide/jsonpath/) - Документация по синтаксису использования [выражений JSONPath](http://goessner.net/articles/JsonPath/) с kubectl.
-* [kubeadm](/docs/admin/kubeadm/) - Инструмент CLI для простого обеспечения безопасного кластера Kubernetes.
-* [kubefed](/docs/admin/kubefed/) - Инструмент CLI, чтобы помочь вам администрировать ваши федеративные кластеры.
+* [kubeadm](/docs/admin/kubeadm/) - Инструмент CLI для легкого разворачивания защищенного кластера Kubernetes.
+* [kubefed](/docs/admin/kubefed/) - Инструмент CLI для помощи в администрировании федеративных кластеров.

 ## Ссылки на конфигурации

@@ -47,12 +47,12 @@ content_template: templates/concept
 ## Облачные решения "под ключ"


-Такие решения озволяют создавать кластеры Kubernetes с помощью небольшого количества команд. Эти решения имеют большую поддежку сообществом и активно развиваются. Они могут быть размещены на разнообразных IaaS облачных провайдерах, при этом предлагая большую свободу и гибкость в обмен на приложенные усилия.
+Такие решения позволяют создавать кластеры Kubernetes с помощью небольшого количества команд. Эти решения имеют большую поддержку сообществом и активно развиваются. Они могут быть размещены на разнообразных IaaS облачных провайдерах, при этом предлагая большую свободу и гибкость в обмен на приложенные усилия.

-Вам следует выбрать облачное решение "под ключ", если вы":
+Вам следует выбрать облачное решение "под ключ", если вы:

 * Хотите получить больший контроль над кластерами, чем позволяют размещённые решения
-* Хотите получить больше контроля над оперциями Want to take on more operations ownership 
+* Хотите получить больше контроля над операциями

 Выбрать [облачное решение "под ключ"](/docs/setup/pick-right-solution/#turnkey-cloud-solutions)

@@ -63,7 +63,7 @@ content_template: templates/concept
 Вам следует выбрать местное резервное решение "под ключ", если:

 * Вы хотите развернуть кластер в приватной облачной сети
-* У вас есть выделенная команда SRE специалистов
+* У вас есть выделенная команда SRE-специалистов
 * У вас есть ресурсы для размещения и мониторинга собственных кластеров

 Выбрать [местное резервное решение "под ключ"](/docs/setup/pick-right-solution/#on-premises-turnkey-cloud-solutions).
@@ -1,473 +0,0 @@
---
-title: Установка и настройка kubectl
-content_template: templates/task
-weight: 10
-card:
-  name: tasks
-  weight: 20
-  title: Установка kubectl
---
-
-{{% capture overview %}}
-[kubectl](/docs/user-guide/kubectl/) - это утилита командной строки для Kubernetes, позволяющая выполнять команды на кластере Kubernetes. kubectl можно использовать для развёртывания приложений, инспектирования и управления ресурсами кластера, а также для просмотра логов. Для ознакомления с полным списком возможностей kubectl, обратитесь к странице [Обзор kubectl](/docs/reference/kubectl/overview/).
-{{% /capture %}}
-
-{{% capture prerequisites %}}
-Необходимо использовать версию kubectl на одну минорную версию отличающуюся от вашего кластера. Например, клиент с версией v1.2 должен работать с версиями мастера v1.1, v1.2 и v1.3. Использование последней стабильной версии kubectl позволяет избежать непредвиденных проблем.
-{{% /capture %}}
-
-{{% capture steps %}}
-
-## Установка kubectl на Linux
-
-### Установка бинарного файла kubectl с использованием curl на Linux
-
-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 -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` на команду с выбранной версией.
-
-    Например, для установки версии {{< param "fullversion" >}} на Linux введите:
-    
-    ```
-    curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
-    ```
-
-2. Сделайте бинарный файл kubectl исполняемым.
-
-    ```
-    chmod +x ./kubectl
-    ```
-
-3. Переместите файл в директорию из переменной окружения PATH.
-
-    ```
-    sudo mv ./kubectl /usr/local/bin/kubectl
-    ```
-4. Чтобы проверить актуальность установленной версии, выполните команду:
-
-    ```
-    kubectl version
-    ```
-
-### Установка с использованием нативного менеджера пакетов
-
-{{< tabs name="kubectl_install" >}}
-{{< tab name="Ubuntu, Debian или HypriotOS" codelang="bash" >}}
-sudo apt-get update && sudo apt-get install -y apt-transport-https
-curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
-echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
-sudo apt-get update
-sudo apt-get install -y kubectl
-{{< /tab >}}
-{{< tab name="CentOS, RHEL или Fedora" codelang="bash" >}}cat <<EOF > /etc/yum.repos.d/kubernetes.repo
-[kubernetes]
-name=Kubernetes
-baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
-enabled=1
-gpgcheck=1
-repo_gpgcheck=1
-gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
-EOF
-yum install -y kubectl
-{{< /tab >}}
-{{< /tabs >}}
-
-### Установка с использованием других менеджеров пакетов
-
-Если вы используете Ubuntu или другой дистрибутив Linux, поддерживающий пакетный менеджер [snap](https://snapcraft.io/docs/core/install), kubectl доступен в виде приложения [snap](https://snapcraft.io/).
-
-Если вы пользователь Linux и используете пакетный менеджер [Homebrew](https://docs.brew.sh/Homebrew-on-Linux), kubectl доступен для [установки](https://docs.brew.sh/Homebrew-on-Linux#install).
-
-{{< tabs name="other_kubectl_install" >}}
-{{< tab name="Snap" codelang="bash" >}}
-sudo snap install kubectl --classic
-
-kubectl version
-{{< /tab >}}
-{{< tab name="Homebrew" codelang="bash" >}}
-brew install kubectl
-
-kubectl version
-{{< /tab >}}
-{{< /tabs >}}
-
-## Установка kubectl на macOS
-
-### Установка бинарного файла kubectl с использованием curl на macOS
-
-1. Загрузите последний релиз с помощью команды:
-
-    ```		 
-    curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl"
-    ```
-
-    Для установки конкретной версии замените эту часть команды `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` на команду с выбранной версией.
-
-    Например, для установки версии {{< param "fullversion" >}} на macOS введите:
-		  
-    ```
-    curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
-    ```
-
-2. Сделайте бинарный файл kubectl исполняемым.
-
-    ```
-    chmod +x ./kubectl
-    ```
-
-3. Переместите файл в директорию из переменной окружения PATH.
-
-    ```
-    sudo mv ./kubectl /usr/local/bin/kubectl
-    ```
-4. Чтобы проверить актуальность установленной версии, выполните команду:
-
-    ```
-    kubectl version
-    ```
-
-### Установка с использованием Homebrew на macOS
-
-Если вы пользователь macOS и используете пакетный менеджер [Homebrew](https://brew.sh/), вы можете установить kubectl с помощью Homebrew.
-
-1. Для установки, выполните команду:
-
-    ```
-    brew install kubectl 
-    ```
-    или 
-    
-    ```
-    brew install kubernetes-cli
-    ```
-
-2. Чтобы проверить актуальность установленной версии, выполните команду:
-
-    ```
-    kubectl version
-    ```
-
-### Установка с использованием Macports на macOS
-
-Если вы пользователь macOS и используете пакетный менеджер [Macports](https://macports.org/), вы можете установить kubectl с помощью Macports.
-
-1. Для установки, выполните команду:
-
-    ```
-    sudo port selfupdate
-    sudo port install kubectl
-    ```
-    
-2. Чтобы проверить актуальность установленной версии, выполните команду:
-
-    ```
-    kubectl version
-    ```
-
-## Установка kubectl на Windows
-
-### Установка бинарного файла kubectl с использованием curl на Windows
-
-1. Загрузите последний релиз {{< param "fullversion" >}} по [этой ссылке](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe).
-
-    Или, если у вас установлена утилита `curl`, воспользуйтесь командой:
-
-    ```
-    curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
-    ```
-
-    Чтобы определить последнюю стабильную версию (например, для написания скриптов), обратитесь к [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)..
-
-2. Добавьте путь к бинарному файлу в переменную окружения PATH.
-3. Проверьте, что установленная версия `kubectl` соответствует загруженной:
-
-    ```
-    kubectl version
-    ```
-{{< note >}}
-[Docker Desktop для Windows](https://docs.docker.com/docker-for-windows/#kubernetes) добавляет в PATH собственную версию `kubectl`. Если вы устанавливали Docker Desktop ранее, вам может быть необходимо разметить запись в переменной PATH до добавленной приложением Docker Desktop или удалить Docker Desktop `kubectl`.
-{{< /note >}}
-
-### Установка с помощью Powershell из PSGallery
-
-Если вы пользователь Windows и используете пакетный менеджер [Powershell Gallery](https://www.powershellgallery.com/), вы можете установить kubectl с помощью Powershell.
-
-1. Для установки, выполните команду (не забудьте указать `DownloadLocation`):
-
-    ```
-    Install-Script -Name install-kubectl -Scope CurrentUser -Force
-    install-kubectl.ps1 [-DownloadLocation <path>]
-    ```
-    
-    {{< note >}} Если вы не укажете `DownloadLocation`, `kubectl` будет установлен во временную пользовательскую директорию.{{< /note >}}
-    
-    Установщик создаст `$HOME/.kube` и даст ему инструкции по созданию файла конфигурации
-
-2. Чтобы проверить актуальность установленной версии, выполните команду:
-
-    ```
-    kubectl version
-    ```
-
-    {{< note >}}Обновление производится с помощью повторного выполнения команд из пункта 1.{{< /note >}}
-
-### Установка на Windows с использованием Chocolatey или Scoop
-
-Для установки kubectl на Windows можно использовать пакетный менеджер [Chocolatey](https://chocolatey.org) или установщик командной строки [Scoop](https://scoop.sh).
-{{< tabs name="kubectl_win_install" >}}
-{{% tab name="choco" %}}
-
-    choco install kubernetes-cli
-
-{{% /tab %}}
-{{% tab name="scoop" %}}
-
-    scoop install kubectl
-
-{{% /tab %}}
-{{< /tabs >}}
-2. Чтобы проверить актуальность установленной версии, выполните команду:
-
-    ```
-    kubectl version
-    ```
-
-3. Перейдите в домашнюю директорию:
-
-    ```
-    cd %USERPROFILE%
-    ```
-4. Создайте директорию`.kube`:
-
-    ```
-    mkdir .kube
-    ```
-
-5. Перейдите в только что созданную директорию `.kube`:
-
-    ```
-    cd .kube
-    ```
-
-6. Настройте kubectl на использование удалённого кластера Kubernetes:
-
-    ```
-    New-Item config -type file
-    ```
-    
-    {{< note >}}Вы можете отредактировать конфигурационный файл с помощью удобного вам текстового редактора, например Notepad.{{< /note >}}
-
-## Загрузка как часть Google Cloud SDK
-
-Вы можете установить kubectl как часть Google Cloud SDK.
-
-1. Установите [Google Cloud SDK](https://cloud.google.com/sdk/).
-2. Запустите команду установки `kubectl`:
-
-    ```
-    gcloud components install kubectl
-    ```
-    
-3. Чтобы проверить актуальность установленной версии, выполните команду:
-
-    ```
-    kubectl version
-    ```
-
-## Проверка конфигурации kubectl 
-
-Для того, чтобы kubectl мог найти и получить доступ к кластеру Kubernetes, необходим [файл kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/), который создаётся автоматически при создании кластера с использованием [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) или успешном развёртывании кластера Minikube. По умолчанию настройки kubectl находятся в `~/.kube/config`.
-
-Проверить, что kubectl настроен правильно, можно получив состояние кластера:
-
-```shell
-kubectl cluster-info
-```
-Если вы видите в ответе URL, доступ kubectl к вашему кластеру настроен правильно.
-
-Если вы видите сообщение, аналогичное данному, kubectl сконфигурирован неверно или kubectl не может установить связь с вашим кластером.
-
-```shell
-The connection to the server <server-name:port> was refused - did you specify the right host or port?
-```
-
-Например, если вы хотите запустить кластер Kubernetes на вашем ноутбуке (локально), вам сначала потребуется установить инструмент, такой как Minikube, и затем перевыполнить указанные выше команды.
-
-Если kubectl cluster-info возвращает в ответе url, но вы не можете получить доступ к вашему кластеру, используйте следующую команду для проверку корректности настроек:
-
-```shell
-kubectl cluster-info dump
-```
-
-## Дополнительные настройки kubectl
-
-### Включение автодополнения командной оболочки
-
-kubectl предоставляет поддержку автодополнения для Bash и Zsh, что может позволить вам сильно сократить время набора команд.
-
-Ниже указаны инструкции для настройки автодополнения для Bash (включая разницу между Linux и macOS) и Zsh.
-
-{{< tabs name="kubectl_autocompletion" >}}
-
-{{% tab name="Bash на Linux" %}}
-
-### Введение
-
-Скрипт для дополнений kubectl для Bash может быть сгенерирован с помощью команды `kubectl completion bash`. После завершения выполнения скрипта в вашем командной оболочке будет доступно автодополнение команд kubectl.
-
-Однако выполнение скрипта зависит от [**bash-completion**](https://github.com/scop/bash-completion), что значит, что сначала необходимо установить данную утилиту (чтобы проверить, установлена ли у вас утилита bash-completion, используйте команду `type _init_completion`).
-
-### Установка bash-completion
-
-bash-completion предоставляется многими пакетными менеджерами (посмотрите [здесь](https://github.com/scop/bash-completion#installation)). Вы можете установить данную утилиту с помощью `apt-get install bash-completion` или `yum install bash-completion`, и т.д.
-
-Команды, указанные выше, создадут `/usr/share/bash-completion/bash_completion` - главный скрипт для bash-completion. В зависимости от используемого пакетного менеджера может потребоваться вручную указать данный файл в вашем `~/.bashrc`.
-
-Для проверки перезапустите вашу командную оболочку и введите `type _init_completion`. Если команда выполнилась успешно, настройка завершена, иначе добавьте в `~/.bashrc` следующую строку:
-
-```shell
-source /usr/share/bash-completion/bash_completion
-```
-
-Перезапустите вашу командную оболочку и проверьте, что bash-completion установлен корректно выполнив `type _init_completion`.
-
-### Включение автодополнения kubectl
-
-Теперь вам необходимо убедиться, что скрипт для дополнения команд kubectl применён во всех сессиях вашей командной оболочки. Есть два способа сделать это:
-
- Примените скрипт дополнений в вашем `~/.bashrc` файле:
-
-    ```shell
-    echo 'source <(kubectl completion bash)' >>~/.bashrc
-    ```
-
- Добавьте скрипт дополнений в директорию `/etc/bash_completion.d`:
-
-    ```shell
-    kubectl completion bash >/etc/bash_completion.d/kubectl
-    ```
- Если у вас настроен псевдоним для kubectl, вы можете расширить действие дополнений в командной оболочке для работы с этим псевдонимом:
-
-    ```shell
-    echo 'alias k=kubectl' >>~/.bashrc
-    echo 'complete -F __start_kubectl k' >>~/.bashrc
-    ```
-
-{{< note >}}
-Все исходные скрипты bash-completion находятся в `/etc/bash_completion.d`.
-{{< /note >}}
-
-Оба подхода равнозначны. После перезагрузки командной оболочки автодополнение kubectl должно работать.
-
-{{% /tab %}}
-
-
-{{% tab name="Bash на macOS" %}}
-
-
-### Введение
-
-Скрипт дополнений kubectl может быть сгенерирован с помощью команды `kubectl completion bash`. Применение этого скрипта в вашей командной оболочке активирует дополнения kubectl.
-
-Однако скрипт дополнений kubectl зависит от утилиты [**bash-completion**](https://github.com/scop/bash-completion), которую необходимо установить заранее.
-
-{{< warning>}}
-Существуют две версии bash-completion, v1 и v2. V1 используется для Bash 3.2 (версия по умолчанию для macOS), а версия v2 для Bash 4.1+. Скрипт дополнений kubectl **не работает** корректно с bash-completion v1 и Bash 3.2. Для работы скрипта требуется **bash-completion v2** и **Bash 4.1+**. Поэтому, для возможности корректной работы дополнений kubectl, вам требуется установить и использовать Bash 4.1+ ([*инструкция*](https://itnext.io/upgrading-bash-on-macos-7138bd1066ba)). В следующих шагах инструкции предполагается, что вы используете Bash 4.1+ (т.е. версию Bash 4.1 или новее).
-{{< /warning >}}
-
-
-### Установка bash-completion
-
-{{< note >}}
-Как было упомянуто ранее, данные инструкции предполагают, что вы используете Bash 4.1+, что значит, что будет установлена версия bash-completion v2 (вместо Bash 3.2 и bash-completion v1, для которых дополнения kubectl не будут работать).
-{{< /note >}}
-
-Проверить, установлена ли у вас уже версия bash-completion v2 с помощью команды `type _init_completion`. Если нет, вы можете установить утилиту с помощью Homebrew:
-
-```shell
-brew install bash-completion@2
-```
-
-Следуя инструкции в выводе данной команды, добавьте следующую информацию в файл `~/.bashrc`:
-
-```shell
-export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
-[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh"
-```
-
-Перезапустите вашу командную оболочку и проверьте, что версия bash-completion v2 установлена корректно, используя команду `type _init_completion`.
-
-### Включение автодополнения kubectl
-
-Теперь вам необходимо убедиться, что скрипт для дополнения команд kubectl применён во всех сессиях вашей командной оболочки. Есть несколько способов сделать это:
-
- Примените скрипт дополнений в вашем `~/.bashrc` файле:
-
-    ```shell
-    echo 'source <(kubectl completion bash)' >>~/.bashrc
-
-    ```
-
- Добавьте скрипт дополнений в директорию `/usr/local/etc/bash_completion.d`:
-
-    ```shell
-    kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
-    ```
-
- Если у вас настроен псевдоним для kubectl, вы можете расширить действие дополнений в командной оболочке для работы с этим псевдонимом:
-
-    ```shell
-    echo 'alias k=kubectl' >>~/.bashrc
-    echo 'complete -F __start_kubectl k' >>~/.bashrc
-    ```
-    
- Если вы устанавливали kubectl с помощью Homebrew (как указано [выше](#install-with-homebrew-on-macos)), тогда скрипт дополнений kubectl уже должен находиться в `/usr/local/etc/bash_completion.d/kubectl`. В этом случае, вам не нужно ничего делать дополнительно.
-
-{{< note >}}
-Установка bash-completion v2 с использованием Homebrew размещает все файлы в директории`BASH_COMPLETION_COMPAT_DIR`, поэтому предыдущие два способа работают.
-{{< /note >}}
-
-В любом случае, после перезагрузки вашей командной оболочки, дополнения kubectl должны работать.
-{{% /tab %}}
-
-{{% tab name="Zsh" %}}
-
-Скрипт дополнений kubectl может быть сгенерирован с помощью команды `kubectl completion zsh`. Применение этого скрипта в вашей командной оболочке активирует дополнения kubectl.
-
-Чтобы сделать это во всех сессиях вашей командной оболочки, добавьте следующую информацию в файл `~/.zshrc`:
-
-```shell
-source <(kubectl completion zsh)
-```
-
-Если у вас настроен псевдоним для kubectl, вы можете расширить действие дополнений в командной оболочке для работы с этим псевдонимом:
-
-```shell
-echo 'alias k=kubectl' >>~/.zshrc
-echo 'complete -F __start_kubectl k' >>~/.zshrc
-```
-    
-После перезагрузки вашей командной оболочки автодополнения kubectl должны работать.
-
-Если вы получаете ошибку `complete:13: command not found: compdef`, тогда добавьте следующее в начало вашего файла `~/.zshrc`:
-
-```shell
-autoload -Uz compinit
-compinit
-```
-{{% /tab %}}
-{{< /tabs >}}
-
-{{% /capture %}}
-
-{{% capture whatsnext %}}
-* [Установка Minikube](/docs/tasks/tools/install-minikube/)
-* Обратитесь к [руководствам по началу работы](/docs/setup/), чтобы узнать больше о создании кластеров. 
-* [Узнайте, как запустить и опубликовать ваше приложение.](/docs/tasks/access-application-cluster/service-access-application-cluster/)
-* Если вам нужен доступ к кластеру, созданному не вами, обратитесь к [документу по созданию общего доступа к кластеру](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
-* Прочитайте [справочную документацию по kubectl](/docs/reference/kubectl/kubectl/)
-{{% /capture %}}
@@ -61,9 +61,9 @@ Katacoda предоставляет бесплатную, встроенную
    minikube dashboard
    ```

-3. Только для окружения Katacoda: В верхней части панели нажмите знак "плюч", а затем нажмите на **Select port to view on Host 1** (**Выберите порт для отображения на хосте 1**). 
+3. Только для окружения Katacoda: В верхней части панели нажмите знак "плюс", а затем на **Select port to view on Host 1** (**Выберите порт для отображения на хосте 1**).

-4. Только для окружения Katacoda: Type `30000`, and then click **Display Port** (**Показать порт**). 
+4. Только для окружения Katacoda: введите `30000`, а затем нажмите **Display Port** (**Показать порт**).

 ## Создание Deployment

@@ -118,7 +118,7 @@ Katacoda предоставляет бесплатную, встроенную

 По-умолчанию под доступен только при обращении по его внутреннему IP адресу внутри кластера Kubernetes. Чтобы сделать контейнер `hello-node` доступным вне виртульной сети Kubernetes, необходимо представить под как [*сервис*](/docs/concepts/services-networking/service/) Kubernetes.

-1. Представить под для видимости в публичной сети Интернет можно с помощью команды `kubectl expose`:
+1. Сделать под доступным для публичной сети Интернет можно с помощью команды `kubectl expose`:

    ```shell
    kubectl expose deployment hello-node --type=LoadBalancer --port=8080
@@ -154,11 +154,11 @@ Katacoda предоставляет бесплатную, встроенную

    Откроется окно браузера, в котором запущено ваше приложение и будет отображено сообщение "Hello World".

-## Добавление аддонов
+## Добавление дополнений

-В Minikube есть набор встроенных аддонов, которые могут быть включены, выключены и открыты в локальном окружении Kubernetes.
+В Minikube есть набор встроенных дополнений, которые могут быть включены, выключены и открыты в локальном окружении Kubernetes.

-1. Отобразить текущие поддерживаемые аддоны:
+1. Отобразить текущие поддерживаемые дополнения:

    ```shell
    minikube addons list
@@ -184,16 +184,16 @@ Katacoda предоставляет бесплатную, встроенную
    storage-provisioner: enabled
    ```
   
-2. Включить расширение, например, `heapster`:
+2. Включить дополнение, например, `metrics-server`:

    ```shell
-    minikube addons enable heapster
+    minikube addons enable metrics-server
    ```
  
    Вывод:

    ```shell
-    heapster was successfully enabled
+    metrics-server was successfully enabled
    ```

 3. Посмотреть Pod и Service, которые вы только что создали:
@@ -206,7 +206,7 @@ Katacoda предоставляет бесплатную, встроенную

    ```shell
    NAME                                        READY     STATUS    RESTARTS   AGE
-    pod/heapster-9jttx                          1/1       Running   0          26s
+    pod/metrics-server-6754dbc9df-q8zlg         1/1       Running   0          26s
    pod/influxdb-grafana-b29w8                  2/2       Running   0          26s
    pod/kube-addon-manager-minikube             1/1       Running   0          34m
    pod/kube-dns-6dcb57bcc8-gv7mw               3/3       Running   0          34m
@@ -214,23 +214,23 @@ Katacoda предоставляет бесплатную, встроенную
    pod/storage-provisioner                     1/1       Running   0          34m

    NAME                           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
-    service/heapster               ClusterIP   10.96.241.45    <none>        80/TCP              26s
+    service/metrics-server         ClusterIP   10.96.94.175    <none>        443/TCP             26s
    service/kube-dns               ClusterIP   10.96.0.10      <none>        53/UDP,53/TCP       34m
    service/kubernetes-dashboard   NodePort    10.109.29.1     <none>        80:30000/TCP        34m
    service/monitoring-grafana     NodePort    10.99.24.54     <none>        80:30002/TCP        26s
    service/monitoring-influxdb    ClusterIP   10.111.169.94   <none>        8083/TCP,8086/TCP   26s
    ```

-4. Отключить `heapster`:
+4. Отключить `metrics-server`:

    ```shell
-    minikube addons disable heapster
+    minikube addons disable metrics-server
    ```
  
    Вывод:

    ```shell
-    heapster was successfully disabled
+    metrics-server was successfully disabled
    ```

 ## Освобождение ресурсов
@@ -258,8 +258,8 @@ minikube delete

 {{% capture whatsnext %}}

-* Больше об [объекте(ах?) деплоймента](/docs/concepts/workloads/controllers/deployment/).
-* Большо о [развёртывании приложения](/docs/user-guide/deploying-applications/).
+* Больше об [объектах деплоймента](/docs/concepts/workloads/controllers/deployment/).
+* Больше о [развёртывании приложения](/docs/user-guide/deploying-applications/).
 * Больше об [объектах сервиса](/docs/concepts/services-networking/service/).

 {{% /capture %}}
@@ -1,4 +1,4 @@
 FROM node:6.14.2
 EXPOSE 8080
 COPY server.js .
-CMD node server.js
+CMD [ "node", "server.js" ]
@@ -0,0 +1,13 @@
+# See the OWNERS docs at https://go.k8s.io/owners
+
+# This is the directory for Ukrainian source content.
+# Teams and members are visible at https://github.com/orgs/kubernetes/teams.
+
+reviewers:
+- sig-docs-uk-reviews
+
+approvers:
+- sig-docs-uk-owners
+
+labels:
+- language/uk
@@ -43,7 +43,7 @@ As part of Bloomberg's continued commitment to developing the Kubernetes ecosyst



-作为Bloomberg [继续致力于开发Kubernetes生态系统]的一部分（https://www.techatbloomberg.com/blog/bloomberg-awarded-first-cncf-end-user-award-contributions-kubernetes/），我们很高兴能够宣布Kubernetes Airflow Operator的发布; [Apache Airflow]（https://airflow.apache.org/）的机制，一种流行的工作流程编排框架，使用Kubernetes API可以在本机启动任意的Kubernetes Pod。
+作为Bloomberg [继续致力于开发Kubernetes生态系统]的一部分（https://www.techatbloomberg.com/blog/bloomberg-awarded-first-cncf-end-user-award-contributions-kubernetes/），我们很高兴能够宣布Kubernetes Airflow Operator的发布; [Apache Airflow](https://airflow.apache.org/)的机制，一种流行的工作流程编排框架，使用Kubernetes API可以在本机启动任意的Kubernetes Pod。



@@ -127,7 +127,7 @@ Airflow users are always looking for ways to make deployments and ETL pipelines



-在进一步讨论之前，我们应该澄清Airflow中的[Operator]（https://airflow.apache.org/concepts.html#operators）是一个任务定义。 当用户创建DAG时，他们将使用像“SparkSubmitOperator”或“PythonOperator”这样的operator分别提交/监视Spark作业或Python函数。 Airflow附带了Apache Spark，BigQuery，Hive和EMR等框架的内置运算符。 它还提供了一个插件入口点，允许DevOps工程师开发自己的连接器。
+在进一步讨论之前，我们应该澄清Airflow中的[Operator](https://airflow.apache.org/concepts.html#operators)是一个任务定义。 当用户创建DAG时，他们将使用像“SparkSubmitOperator”或“PythonOperator”这样的operator分别提交/监视Spark作业或Python函数。 Airflow附带了Apache Spark，BigQuery，Hive和EMR等框架的内置运算符。 它还提供了一个插件入口点，允许DevOps工程师开发自己的连接器。



@@ -163,7 +163,7 @@ For operators that are run within static Airflow workers, dependency management

 * 配置和依赖的灵活性：

-对于在静态Airflow工作程序中运行的operator，依赖关系管理可能变得非常困难。 如果开发人员想要运行一个需要[SciPy]（https://www.scipy.org） 的任务和另一个需要[NumPy]（http://www.numpy.org） 的任务，开发人员必须维护所有Airflow节点中的依赖关系或将任务卸载到其他计算机（如果外部计算机以未跟踪的方式更改，则可能导致错误）。 自定义Docker镜像允许用户确保任务环境，配置和依赖关系完全是幂等的。
+对于在静态Airflow工作程序中运行的operator，依赖关系管理可能变得非常困难。 如果开发人员想要运行一个需要[SciPy](https://www.scipy.org)的任务和另一个需要[NumPy](http://www.numpy.org)的任务，开发人员必须维护所有Airflow节点中的依赖关系或将任务卸载到其他计算机（如果外部计算机以未跟踪的方式更改，则可能导致错误）。 自定义Docker镜像允许用户确保任务环境，配置和依赖关系完全是幂等的。



@@ -207,7 +207,7 @@ The Kubernetes Operator uses the Kubernetes Python Client to generate a request



-Kubernetes Operator使用[Kubernetes Python客户端]（https://github.com/kubernetes-client/Python)生成由APIServer处理的请求（1）。 然后，Kubernetes将使用您定义的需求启动您的pod（2）。映像文件中将加载环境变量，Secret和依赖项，执行单个命令。 一旦启动作业，operator只需要监视跟踪日志的状况（3）。 用户可以选择将日志本地收集到调度程序或当前位于其Kubernetes集群中的任何分布式日志记录服务。
+Kubernetes Operator使用[Kubernetes Python客户端](https://github.com/kubernetes-client/Python)生成由APIServer处理的请求（1）。 然后，Kubernetes将使用您定义的需求启动您的pod（2）。映像文件中将加载环境变量，Secret和依赖项，执行单个命令。 一旦启动作业，operator只需要监视跟踪日志的状况（3）。 用户可以选择将日志本地收集到调度程序或当前位于其Kubernetes集群中的任何分布式日志记录服务。



@@ -375,7 +375,7 @@ Finally, update your DAGs to reflect the new release version and you should be r



-[在Jenkins构建中生成Docker镜像和缓冲版本]（https://getintodevops.com/blog/building-your-first-Docker-image-with-jenkins-2-guide-for-developers）。
+[在Jenkins构建中生成Docker镜像和缓冲版本](https://getintodevops.com/blog/building-your-first-Docker-image-with-jenkins-2-guide-for-developers)。



@@ -655,7 +655,7 @@ Special thanks to the Apache Airflow and Kubernetes communities, particularly Gr



-此功能只是将Apache Airflow集成到Kubernetes中的多项主要工作的开始。 Kubernetes Operator已合并到[Airflow的1.10发布分支]（https://github.com/apache/incubator-airflow/tree/v1-10-test）（实验模式中的执行模块），以及完整的k8s本地调度程序称为Kubernetes Executor（即将发布文章）。这些功能仍处于早期采用者/贡献者可能对这些功能的未来产生巨大影响的阶段。
+此功能只是将Apache Airflow集成到Kubernetes中的多项主要工作的开始。 Kubernetes Operator已合并到[Airflow的1.10发布分支](https://github.com/apache/incubator-airflow/tree/v1-10-test)（实验模式中的执行模块），以及完整的k8s本地调度程序称为Kubernetes Executor（即将发布文章）。这些功能仍处于早期采用者/贡献者可能对这些功能的未来产生巨大影响的阶段。



@@ -132,7 +132,7 @@ Prow 让我们做以下事情：
 * 标出长时间保持不活动状态 issues/Pull Requests
 * 自动合并符合我们PR工作流程要求的 Pull Requests
 * 运行定义为[Knative Builds](https://github.com/knative/build)的 Kubernetes Pods或 Jenkins jobs的 CI 作业
-* 实施组织范围和重构 GitHub 仓库策略，如[Knative Builds]（https://github.com/kubernetes/test-infra/tree/master/prow/cmd/branchprotector）和[GitHub labels]（https://github.com/kubernetes/test-infra/tree/master/label_sync）
+* 实施组织范围和重构 GitHub 仓库策略，如[Knative Builds](https://github.com/kubernetes/test-infra/tree/master/prow/cmd/branchprotector)和[GitHub labels](https://github.com/kubernetes/test-infra/tree/master/label_sync)

 <!--
 Prow was initially developed by the engineering productivity team building Google Kubernetes Engine, and is actively contributed to by multiple members of Kubernetes SIG Testing. Prow has been adopted by several other open source projects, including Istio, JetStack, Knative and OpenShift. [Getting started with Prow](https://github.com/kubernetes/test-infra/blob/master/prow/getting_started.md) takes a Kubernetes cluster and `kubectl apply starter.yaml` (running pods on a Kubernetes cluster).
@@ -0,0 +1,137 @@
+---
+layout: blog
+title: "2019 指导委员会选举结果"
+date: 2019-10-03
+slug: 2019-steering-committee-election-results
+---
+<!--
+---
+layout: blog
+title: "2019 Steering Committee Election Results"
+date: 2019-10-03
+slug: 2019-steering-committee-election-results
+---
+-->
+<!--
+**Authors**: Bob Killen (University of Michigan), Jorge Castro (VMware),
+Brian Grant (Google), and Ihor Dvoretskyi (CNCF)
+-->
+**作者**：Bob Killen (University of Michigan), Jorge Castro (VMware),
+Brian Grant (Google), and Ihor Dvoretskyi (CNCF)
+<!--
+The [2019 Steering Committee Election] is a landmark milestone for the
+Kubernetes project. The initial bootstrap committee is graduating to emeritus
+and the committee has now shrunk to its final allocation of seven seats. All
+members of the Steering Committee are now fully elected by the Kubernetes
+Community.
+-->
+[2019 指导委员会选举][2019 Steering Committee Election] 是 Kubernetes 项目的重要里程碑。最初的自助委员会正逐步退休，现在该委员会已缩减到最后分配的 7 个席位。指导委员会的所有成员现在都由 Kubernetes 社区选举产生。
+<!--
+Moving forward elections will elect either 3 or 4 people to the committee for
+two-year terms.
+-->
+接下来的选举将选出 3 到 4 名委员，任期两年。
+<!--
+## **Results**
+
+The Kubernetes Steering Committee Election is now complete and the following
+candidates came ahead to secure two-year terms that start immediately
+(in alphabetical order by GitHub handle):
+-->
+## 选举结果
+
+Kubernetes 指导委员会选举现已完成，以下候选人提前获得立即开始的两年任期 (按 GitHub handle 的字母顺序排列) ：
+
+* **Christoph Blecker ([@cblecker]), Red Hat**
+* **Derek Carr ([@derekwaynecarr]), Red Hat**
+* **Nikhita Raghunath ([@nikhita]), Loodse**
+* **Paris Pittman ([@parispittman])**, **Google**
+<!--
+They join Aaron Crickenberger ([@spiffxp]), Google; Davanum Srinivas ([@dims]),
+VMware; and Timothy St. Clair ([@timothysc]), VMware, to round out the committee.
+The seats held by Aaron, Davanum, and Timothy will be up for election around
+this time next year.
+-->
+他们加入了 Aaron Crickenberger ([@spiffxp])， Google；Davanum Srinivas ([@dims])，VMware; and Timothy St. Clair ([@timothysc]), VMware，使得委员会更圆满。Aaron、Davanum 和 Timothy 占据的这些席位将会在明年的这个时候进行选举。
+
+<!--
+## Big Thanks!
+
+* Thanks to the initial bootstrap committee for establishing the initial
+  project governance and overseeing a multi-year transition period:
+-->
+## 诚挚的感谢！
+
+* 感谢最初的引导委员会创立了最初项目的管理并监督了多年的过渡期：
+    * Joe Beda ([@jbeda]), VMware
+    * Brendan Burns ([@brendandburns]), Microsoft
+    * Clayton Coleman ([@smarterclayton]), Red Hat
+    * Brian Grant ([@bgrant0607]), Google
+    * Tim Hockin ([@thockin]), Google
+    * Sarah Novotny ([@sarahnovotny]), Microsoft
+    * Brandon Philips ([@philips]), Red Hat
+<!--
+* And also thanks to the other Emeritus Steering Committee Members. Your
+  prior service is appreciated by the community:
+-->
+* 同样感谢其他的已退休指导委员会成员。社区对你们先前的服务表示赞赏：
+    * Quinton Hoole ([@quinton-hoole]), Huawei
+    * Michelle Noorali ([@michelleN]), Microsoft
+    * Phillip Wittrock ([@pwittrock]), Google
+<!--
+* Thanks to the candidates that came forward to run for election. May we always
+  have a strong set of people who want to push the community forward like yours
+  in every election.
+* Thanks to all 377 voters who cast a ballot.
+* And last but not least…Thanks to Cornell University for hosting [CIVS]!
+-->
+* 感谢参选的候选人。 愿在每次选举中，我们都能拥有一群像您一样推动社区向前发展的人。
+* 感谢所有投票的377位选民。
+* 最后，感谢康奈尔大学举办的 [CIVS]!
+<!--
+## Get Involved with the Steering Committee
+
+You can follow along with Steering Committee [backlog items] and weigh in by
+filing an issue or creating a PR against their [repo]. They meet bi-weekly on
+[Wednesdays at 8pm UTC] and regularly attend Meet Our Contributors.  They can
+also be contacted at their public mailing list [steering@kubernetes.io].
+
+Steering Committee Meetings:
+-->
+## 参与指导委员会
+
+你可以跟进指导委员会的 [代办事项][backlog items]，通过提出问题或者向 [仓库][repo] 提交一个 pr 。他们每两周一次，在 [UTC 时间周三晚上 8 点][Wednesdays at 8pm UTC] 会面，并定期与我们的贡献者见面。也可以通过他们的公共邮件列表 [steering@kubernetes.io] 联系他们。
+
+指导委员会会议：
+<!--
+* [YouTube Playlist]
+-->
+* [YouTube 播放列表][YouTube Playlist]
+
+[2019 Steering Committee Election]: https://git.k8s.io/community/events/elections/2021
+
+[@cblecker]: https://github.com/cblecker
+[@derekwaynecarr]: https://github.com/derekwaynecarr
+[@nikhita]: https://github.com/nikhita
+[@parispittman]: https://github.com/parispittman
+[@spiffxp]: https://github.com/spiffxp
+[@dims]: https://github.com/dims
+[@timothysc]: https://github.com/timothysc
+[@jbeda]: https://github.com/jbeda
+[@brendandburns]: https://github.com/brendandburns
+[@smarterclayton]: https://github.com/smarterclayton
+[@bgrant0607]: https://github.com/bgrant0607
+[@thockin]: https://github.com/thockin
+[@sarahnovotny]: https://github.com/sarahnovotny
+[@philips]: https://github.com/philips
+[@quinton-hoole]: https://github.com/quinton-hoole
+[@michelleN]: https://github.com/michelleN
+[@pwittrock]: https://github.com/pwittrock
+
+[CIVS]: https://civs.cs.cornell.edu/
+[backlog items]: https://github.com/kubernetes/steering/projects/1
+[repo]: https://github.com/kubernetes/steering
+[Wednesdays at 8pm UTC]: https://github.com/kubernetes/steering
+[steering@kubernetes.io]: mailto:steering@kubernetes.io
+[YouTube Playlist]: https://www.youtube.com/playlist?list=PL69nYSiGNLP1yP1B_nd9-drjoxp0Q14qM
+
@@ -0,0 +1,205 @@
+---
+title: '使用 Microk8s 在 Linux 上本地运行 Kubernetes'
+
+date: 2019-11-26
+---
+<!--
+---                                           
+title: 'Running Kubernetes locally on Linux with Microk8s'                                                           
+date: 2019-11-26
+---
+-->
+<!--
+**Authors**: [Ihor Dvoretskyi](https://twitter.com/idvoretskyi), Developer Advocate, Cloud Native Computing Foundation; [Carmine Rimi](https://twitter.com/carminerimi)
+-->
+**作者**: [Ihor Dvoretskyi](https://twitter.com/idvoretskyi)，开发支持者，云原生计算基金会；[Carmine Rimi](https://twitter.com/carminerimi)
+<!--
+This article, the second in a [series](/blog/2019/03/28/running-kubernetes-locally-on-linux-with-minikube-now-with-kubernetes-1.14-support/) about local deployment options on Linux, and covers [MicroK8s](https://microk8s.io/). Microk8s is the click-and-run solution for deploying a Kubernetes cluster locally, originally developed by Canonical, the publisher of Ubuntu.
+-->
+本文是关于 Linux 上的本地部署选项[系列](https://twitter.com/idvoretskyi)的第二篇，涵盖了 [MicroK8s](https://microk8s.io/)。Microk8s 是本地部署 Kubernetes 集群的 'click-and-run' 方案，最初由 Ubuntu 的发布者 Canonical 开发。
+<!--
+While Minikube usually spins up a local virtual machine (VM) for the Kubernetes cluster, MicroK8s doesn’t require a VM. It uses [snap](https://snapcraft.io/) packages, an application packaging and isolation technology.
+-->
+虽然 Minikube 通常为 Kubernetes 集群创建一个本地虚拟机（VM），但是 MicroK8s 不需要 VM。它使用[snap](https://snapcraft.io/) 包，这是一种应用程序打包和隔离技术。
+<!--
+This difference has its pros and cons. Here we’ll discuss a few of the interesting differences, and comparing the benefits of a VM based approach with the benefits of a non-VM approach. One of the first factors is cross-platform portability. While a Minikube VM is portable across operating systems - it supports not only Linux, but Windows, macOS, and even FreeBSD - Microk8s requires Linux, and only on those distributions [that support snaps](https://snapcraft.io/docs/installing-snapd). Most popular Linux distributions are supported. 
+-->
+这种差异有其优点和缺点。在这里，我们将讨论一些有趣的区别，并且基于 VM 的方法和非 VM 方法的好处。第一个因素是跨平台的移植性。虽然 Minikube VM 可以跨操作系统移植——它不仅支持 Linux，还支持 Windows、macOS、甚至 FreeBSD，但 Microk9s 需要 Linux，而且只在[那些支持 snaps](https://snapcraft.io/docs/installing-snapd) 的发行版上。支持大多数流行的 Linux 发行版。
+<!--
+Another factor to consider is resource consumption. While a VM appliance gives you greater portability, it does mean you’ll consume more resources to run the VM, primarily because the VM ships a complete operating system, and runs on top of a hypervisor. You’ll consume more disk space when the VM is dormant. You’ll consume more RAM and CPU while it is running. Since Microk8s doesn’t require spinning up a virtual machine you’ll have more resources to run your workloads and other applications. Given its smaller footprint, MicroK8s is ideal for IoT devices - you can even use it on a Raspberry Pi device!
+-->
+另一个考虑到的因素是资源消耗。虽然 VM 设备为您提供了更好的可移植性，但它确实意味着您将消耗更多资源来运行 VM，这主要是因为 VM 提供了一个完整的操作系统，并且运行在管理程序之上。当 VM 处于休眠时你将消耗更多的磁盘空间。当它运行时，你将会消耗更多的 RAM 和 CPU。因为 MIcrok8s 不需要创建虚拟机，你将会有更多的资源去运行你的工作负载和其他设备。考虑到所占用的空间更小，MIcroK8s 是物联网设备的理想选择-你甚至可以在 Paspberry Pi 和设备上使用它！
+<!--
+Finally, the projects appear to follow a different release cadence and strategy. MicroK8s, and snaps in general provide [channels](https://snapcraft.io/docs/channels) that allow you to consume beta and release candidate versions of new releases of Kubernetes, as well as the previous stable release. Microk8s generally releases the stable release of upstream Kubernetes almost immediately.
+-->
+最后，项目似乎遵循了不同的发布节奏和策略。Microk8s 和 snaps 通常提供[渠道](https://snapcraft.io/docs/channels)允许你使用测试版和发布 KUbernetes 新版本的候选版本，同样也提供先前稳定版本。Microk8s 通常几乎立刻发布 Kubernetes 上游的稳定版本。
+<!--
+But wait, there’s more! Minikube and MicroK8s both started as single-node clusters. Essentially, they allow you to create a Kubernetes cluster with a single worker node. That is about to change - there’s an early alpha release of MicroK8s that includes clustering. With this capability, you can create Kubernetes clusters with as many worker nodes as you wish. This is effectively an un-opinionated option for creating a cluster - the developer must create the network connectivity between the nodes, as well as integrate with other infrastructure that may be required, like an external load-balancer. In summary, MicroK8s offers a quick and easy way to turn a handful of computers or VMs into a multi-node Kubernetes cluster. We’ll write more about this kind of architecture in a future article.
+-->
+但是等等，还有更多！Minikube 和 Microk8s 都是作为单节点集群启动的。本质上来说，它们允许你用单个工作节点创建 Kubernetes 集群。这种情况即将改变 - MicroK8s 早期的 alpha 版本包括集群。有了这个能力，你可以创建正如你希望多的工作节点的 KUbernetes 集群。对于创建集群来说，这是一个没有主见的选项 - 开发者在节点之间创建网络连接和集成了其他所需要的基础设施，比如一个外部的负载均衡。总的来说，MicroK8s 提供了一种快速简易的方法，使得少量的计算机和虚拟机变成一个多节点的 Kubernetes 集群。以后我们将撰写更多这种体系结构的文章。
+<!--
+## Disclaimer
+
+This is not an official guide to MicroK8s. You may find detailed information on running and using MicroK8s on it's official [webpage](https://microk8s.io/docs/), where different use cases, operating systems, environments, etc. are covered. Instead, the purpose of this post is to provide clear and easy guidelines for running MicroK8s on Linux.
+-->
+## 免责声明 
+
+这不是 MicroK8s 官方介绍文档。你可以在它的官方[网页](https://microk8s.io/docs/)查询运行和使用 MicroK8s 的详情信息，其中覆盖了不同的用例，操作系统，环境等。相反，这篇文章的意图是提供在 Linux 上运行 MicroK8s 清晰易懂的指南。
+<!--
+## Prerequisites
+
+A Linux distribution that [supports snaps](https://snapcraft.io/docs/installing-snapd), is required. In this guide, we’ll use Ubuntu 18.04 LTS, it supports snaps out-of-the-box.
+If you are interested in running Microk8s on Windows or Mac, you should check out [Multipass](https://multipass.run) to stand up a quick Ubuntu VM as the official way to run virtual Ubuntu on your system.
+-->
+## 前提条件 
+
+一个[支持 snaps](https://snapcraft.io/docs/installing-snapd) 的 Linux 发行版是被需要的。这篇指南，我们将会用支持 snaps 且即开即用的 Ubuntu 18.04 LTS。如果你对运行在 Windows 或者 Mac 上的 MicroK8s 感兴趣，你应该检查[多通道](https://multipass.run)，安装一个快速的 Ubuntu VM，作为在你的系统上运行虚拟机 Ubuntu 的官方方式。
+<!--
+## MicroK8s installation
+
+MicroK8s installation is straightforward:
+-->
+## MicroK8s 安装
+
+简洁的 MicroK8s 安装：
+```shell
+sudo snap install microk8s --classic
+```
+
+<center>{{<figure width="600" src="/images/blog/2019-11-05-kubernetes-with-microk8s/001-install.png">}}</center>
+<!--
+The command above installs a local single-node Kubernetes cluster in seconds. Once the command execution is finished, your Kubernetes cluster is up and running.
+
+You may verify the MicroK8s status with the following command:
+-->
+以上的命令将会在几秒内安装一个本地单节点的 Kubernetes 集群。一旦命令执行结束，你的 Kubernetes 集群将会启动并运行。
+```shell
+sudo microk8s.status
+```
+
+<center>{{<figure width="600" src="/images/blog/2019-11-05-kubernetes-with-microk8s/002-status.png">}}</center>
+
+<!--
+## Using microk8s
+
+Using MicroK8s is as straightforward as installing it. MicroK8s itself includes a `kubectl` binary, which can be accessed by running the `microk8s.kubectl` command. As an example: 
+-->
+## 使用 microk8s
+使用 MicrosK8s 就像和安装它一样便捷。MicroK8s 本身包括一个 `kubectl` 库，该库可以通过执行 `microk8s.kubectl` 命令去访问。例如：
+```shell
+microk8s.kubectl get nodes
+```
+
+<center>{{<figure width="600" src="/images/blog/2019-11-05-kubernetes-with-microk8s/003-nodes.png">}}</center>
+
+<!--
+While using the prefix `microk8s.kubectl` allows for a parallel install of another system-wide kubectl without impact, you can easily get rid of it by using the `snap alias` command:
+-->
+当使用前缀 `microk8s.kubectl` 时，允许在没有影响的情况下并行地安装另一个系统级的 kubectl，你可以便捷地使用 `snap alias` 命令摆脱它：
+```shell
+sudo snap alias microk8s.kubectl kubectl
+```
+<!--
+This will allow you to simply use `kubectl` after. You can revert this change using the `snap unalias` command.
+-->
+<center>{{<figure width="600" src="/images/blog/2019-11-05-kubernetes-with-microk8s/004-alias.png">}}</center>
+
+这将允许你以后便捷地使用 `kubectl`，你可以用 `snap unalias`命令恢复这个改变。
+```shell
+kubectl get nodes
+```
+
+<center>{{<figure width="600" src="/images/blog/2019-11-05-kubernetes-with-microk8s/005-nodes.png">}}</center>
+
+<!--
+## MicroK8s addons
+
+One of the biggest benefits of using Microk8s is the fact that it also supports various add-ons and extensions. What is even more important is they are shipped out of the box, the user just has to enable them.
+
+The full list of extensions can be checked by running the `microk8s.status` command:
+-->
+## MicroK8s 插件
+使用 MIcroK8s 其中最大的好处之一事实上是也支持各种各样的插件和扩展。更重要的是它们是开箱即用的，用户仅仅需要启动它们。通过运行 `microk8s.status` 命令检查出扩展的完整列表。
+```
+sudo microk8s.status
+```
+<!--
+As of the time of writing this article, the following add-ons are supported:
+-->
+截至到写这篇文章为止，MicroK8s 已支持以下插件：
+
+<center>{{<figure width="600" src="/images/blog/2019-11-05-kubernetes-with-microk8s/006-status.png">}}</center>
+
+<!--
+More add-ons are being created and contributed by the community all the time, it definitely helps to check often!
+-->
+社区创建和贡献了越来越多的插件，经常检查他们是十分有帮助的。
+<!--
+## Release channels
+-->
+## 发布渠道
+```shell
+sudo snap info microk8s
+```
+
+<center>{{<figure width="600" src="/images/blog/2019-11-05-kubernetes-with-microk8s/010-releases.png">}}</center>
+
+<!--
+## Installing the sample application
+
+In this tutorial we’ll use NGINX as a sample application ([the official Docker Hub image](https://hub.docker.com/_/nginx)).
+
+It will be installed as a Kubernetes deployment:
+-->
+## 安装简单的应用 
+
+在这篇指南中我将会用 NGINX 作为一个示例应用程序（[官方 Docker Hub 镜像](https://hub.docker.com/_/nginx)）。
+
+```shell
+kubectl create deployment nginx --image=nginx
+```
+<!--
+To verify the installation, let’s run the following:
+-->
+为了检查安装，让我们运行以下命令：
+```shell
+kubectl get deployments
+```
+
+```shell
+kubectl get pods
+```
+
+<center>{{<figure width="600" src="/images/blog/2019-11-05-kubernetes-with-microk8s/007-deployments.png">}}</center>
+
+<!--
+Also, we can retrieve the full output of all available objects within our Kubernetes cluster:
+-->
+我们也可以检索出 Kubernetes 集群中所有可用对象的完整输出。
+```shell
+kubectl get all --all-namespaces
+```
+
+<center>{{<figure width="600" src="/images/blog/2019-11-05-kubernetes-with-microk8s/008-all.png">}}</center>
+
+<!--
+## Uninstalling MicroK8s
+
+Uninstalling your microk8s cluster is so easy as uninstalling the snap:
+-->
+## 卸载 MircroK8s
+
+卸载您的 microk8s 集群与卸载 Snap 同样便捷。
+```shell
+sudo snap remove microk8s
+```
+
+<center>{{<figure width="600" src="/images/blog/2019-11-05-kubernetes-with-microk8s/009-remove.png">}}</center>
+
+<!--
+## Screencast
+-->
+## 截屏视频
+[![asciicast](https://asciinema.org/a/263394.svg)](https://asciinema.org/a/263394)
+
+
@@ -0,0 +1,139 @@
+---
+layout: blog
+title: "使用 Java 开发一个 Kubernetes controller"
+date: 2019-11-26
+slug: Develop-A-Kubernetes-Controller-in-Java
+---
+<!--
+---
+layout: blog
+title: "Develop a Kubernetes controller in Java"
+date: 2019-11-26
+slug: Develop-A-Kubernetes-Controller-in-Java
+---
+-->
+
+<!--
+**Authors:** Min Kim (Ant Financial), Tony Ado (Ant Financial)
+-->
+**作者:** Min Kim (蚂蚁金服), Tony Ado (蚂蚁金服)
+<!--
+The official [Kubernetes Java SDK](https://github.com/kubernetes-client/java) project
+recently released their latest work on providing the Java Kubernetes developers
+a handy Kubernetes controller-builder SDK which is helpful for easily developing
+advanced workloads or systems.  
+-->
+[Kubernetes Java SDK](https://github.com/kubernetes-client/java) 官方项目最近发布了他们的最新工作，为 Java Kubernetes 开发人员提供一个便捷的 Kubernetes 控制器-构建器 SDK，它有助于轻松开发高级工作负载或系统。
+<!--
+## Overall
+
+Java is no doubt one of the most popular programming languages in the world but
+it's been difficult for a period time for those non-Golang developers to build up
+their customized controller/operator due to the lack of library resources in the 
+community. In the world of Golang, there're already some excellent controller
+frameworks, for example, [controller runtime](https://github.com/kubernetes-sigs/controller-runtime),
+[operator SDK](https://github.com/operator-framework/operator-sdk). These
+existing Golang frameworks are relying on the various utilities from the
+[Kubernetes Golang SDK](https://github.com/kubernetes/client-go) proven to
+be stable over years. Driven by the emerging need of further integration into
+the platform of Kubernetes, we not only ported many essential toolings from the Golang
+SDK into the kubernetes Java SDK including informers, work-queues, leader-elections,
+etc. but also developed a controller-builder SDK which wires up everything into
+a runnable controller without hiccups.
+-->
+
+## 综述 
+
+Java 无疑是世界上最流行的编程语言之一，但由于社区中缺少库资源，一段时间以来，那些非 Golang 开发人员很难构建他们定制的 controller/operator。在 Golang 的世界里，已经有一些很好的 controller 框架了，例如，[controller runtime](https://github.com/kubernetes-sigs/controller-runtime)，[operator SDK](https://github.com/operator-framework/operator-sdk)。这些现有的 Golang 框架依赖于 [Kubernetes Golang SDK](https://github.com/kubernetes/client-go) 提供的各种实用工具，这些工具经过多年证明是稳定的。受进一步集成到 Kubernetes 平台的需求驱动，我们不仅将 Golang SDK 中的许多基本工具移植到 kubernetes Java SDK 中，包括 informers、work-queues、leader-elections 等，也开发了一个控制器构建 SDK，它可以将所有东西连接到一个可运行的控制器中，而不会产生任何问题。
+
+<!--
+## Backgrounds
+
+Why use Java to implement Kubernetes tooling? You might pick Java for:
+
+- __Integrating legacy enterprise Java systems__: Many companies have their legacy
+systems or frameworks written in Java in favor of stability. We are not able to
+move everything to Golang easily.
+
+- __More open-source community resources__: Java is mature and has accumulated abundant open-source
+libraries over decades, even though Golang is getting more and more fancy and
+popular for developers. Additionally, nowadays developers are able to develop
+their aggregated-apiservers over SQL-storage and Java has way better support on SQLs.
+-->
+## 背景 
+
+为什么要使用 Java 实现 kubernetes 工具？选择 Java 的原因可能是：
+- __集成遗留的企业级 Java 系统__：许多公司的遗留系统或框架都是用 Java 编写的，用以支持稳定性。我们不能轻易把所有东西搬到 Golang。
+
+- __更多开源社区的资源__：Java 是成熟的，并且在过去几十年中累计了丰富的开源库，尽管 Golang 对于开发人员来说越来越具有吸引力，越来越流行。此外，现在开发人员能够在 SQL 存储上开发他们的聚合-apiserver，而 Java 在 SQL 上有更好的支持。
+
+<!--
+## How to use?
+
+Take maven project as example, adding the following dependencies into your dependencies:
+-->
+## 如何去使用
+以 maven 项目为例，将以下依赖项添加到您的依赖中：
+```xml
+<dependency>
+    <groupId>io.kubernetes</groupId>
+    <artifactId>client-java-extended</artifactId>
+    <version>6.0.1</version>
+</dependency>
+```
+<!--
+Then we can make use of the provided builder libraries to write your own controller.
+For example, the following one is a simple controller prints out node information
+on watch notification, see complete example [here](https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/ControllerExample.java):
+-->
+然后我们可以使用提供的生成器库来编写自己的控制器。例如，下面是一个简单的控制，它打印出关于监视通知的节点信息，请看完整的例子：
+```java
+...
+    Reconciler reconciler = new Reconciler() {
+      @Override
+      public Result reconcile(Request request) {
+        V1Node node = nodeLister.get(request.getName());
+        System.out.println("triggered reconciling " + node.getMetadata().getName());
+        return new Result(false);
+      }
+    };
+    Controller controller =
+        ControllerBuilder.defaultBuilder(informerFactory)
+            .watch(
+                (workQueue) -> ControllerBuilder.controllerWatchBuilder(V1Node.class, workQueue).build())
+            .withReconciler(nodeReconciler) // required, set the actual reconciler
+            .withName("node-printing-controller") // optional, set name for controller for logging, thread-tracing
+            .withWorkerCount(4) // optional, set worker thread count
+            .withReadyFunc( nodeInformer::hasSynced) // optional, only starts controller when the cache has synced up
+            .build();
+```
+<!--
+If you notice, the new Java controller framework learnt a lot from the design of
+[controller-runtime](https://github.com/kubernetes-sigs/controller-runtime) which
+successfully encapsulates the complex components inside controller into several
+clean interfaces. With the help of Java Generics, we even move on a bit and simply
+the encapsulation in a better way.
+-->
+如果您留意，新的 Java 控制器框架很多地方借鉴于 [controller-runtime](https://github.com/kubernetes-sigs/controller-runtime) 的设计，它成功地将控制器内部的复杂组件封装到几个干净的接口中。在 Java 泛型的帮助下，我们甚至更进一步，以更好的方式简化了封装。
+
+<!--
+As for more advanced usage, we can wrap multiple controllers into a controller-manager
+or a leader-electing controller which helps deploying in HA setup. In a word, we can
+basically find most of the equivalence implementations here from Golang SDK and
+more advanced features are under active development by us.
+-->
+我们可以将多个控制器封装到一个 controller-manager 或 leader-electing controller 中，这有助于在 HA 设置中进行部署。
+
+<!--
+## Future steps
+
+The community behind the official Kubernetes Java SDK project will be focusing on
+providing more useful utilities for developers who hope to program cloud native
+Java applications to extend Kubernetes. If you are interested in more details,
+please look at our repo [kubernetes-client/java](https://github.com/kubernetes-client/java).
+Feel free to share also your feedback with us, through Issues or [Slack](http://kubernetes.slack.com/messages/kubernetes-client/).
+-->
+## 未来计划 
+
+Kubernetes Java SDK 项目背后的社区将专注于为希望编写云原生 Java 应用程序来扩展 Kubernetes 的开发人员提供更有用的实用程序。如果您对更详细的信息感兴趣，请查看我们的仓库 [kubernetes-client/java](https://github.com/kubernetes-client/java)。请通过问题或 [Slack](http://kubernetes.slack.com/messages/kubernetes-client/) 与我们分享您的反馈。
+
@@ -191,7 +191,7 @@ A desired state of an object is described by a Deployment, and if changes to tha
 <!--
 The [imagePullPolicy](/docs/concepts/containers/images/#updating-images) and the tag of the image affect when the [kubelet](/docs/admin/kubelet/) attempts to pull the specified image.
 -->
-当 [kubelet](/docs/admin/kubelet/)尝试拉取指定的镜像时，[imagePullPolicy]（/ docs / concepts / containers / images / #updating-images）和镜像的标签会生效。
+当 [kubelet](/docs/admin/kubelet/)尝试拉取指定的镜像时，[imagePullPolicy](/docs/concepts/containers/images/#updating-images)和镜像的标签会生效。

 <!--
 - `imagePullPolicy: IfNotPresent`: the image is pulled only if it is not already present locally.
@@ -57,7 +57,7 @@ is the default scheduler for Kubernetes and runs as part of the
 kube-scheduler is designed so that, if you want and need to, you can
 write your own scheduling component and use that instead.
 -->
-[kube-scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) 是 Kubernetes 集群的默认调度器，并且是集群 {{< glossary_tooltip text="控制面" term_id="control-plane" >}} 的一部分。如果你真的希望或者有这方面的需求，kube-scheduler 在设计上是允许你自己写一个调度组件并替换原有的 kube-scheduler。
+[kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) 是 Kubernetes 集群的默认调度器，并且是集群 {{< glossary_tooltip text="控制面" term_id="control-plane" >}} 的一部分。如果你真的希望或者有这方面的需求，kube-scheduler 在设计上是允许你自己写一个调度组件并替换原有的 kube-scheduler。

 <!--
 For every newly created pods or other unscheduled pods, kube-scheduler
@@ -208,13 +208,13 @@ kube-scheduler 有一系列的默认调度策略。

 - `MaxCSIVolumeCount`：检查 Node 上已经挂载的 {{< glossary_tooltip text="CSI" term_id="csi" >}}
  存储卷数量是否超过了指定的最大值。
-  
+
 - `CheckNodeMemoryPressure`：如果 Node 上报了内存资源压力过大，而且没有配置异常，那么 Pod 将不会被调度到这个 Node 上。

 - `CheckNodePIDPressure`：如果 Node 上报了 PID 资源压力过大，而且没有配置异常，那么 Pod 将不会被调度到这个 Node 上。

 - `CheckNodeDiskPressure`：如果 Node 上报了磁盘资源压力过大（文件系统满了或者将近满了），
-  而且配置异常，那么 Pod 将不会被调度到这个 Node 上。
+  而且配置没有异常，那么 Pod 将不会被调度到这个 Node 上。

 - `CheckNodeCondition`：Node 可以上报其自身的状态，如磁盘、网络不可用，表明 kubelet 未准备好运行 pod。
  如果 Node 被设置成这种状态，那么 pod 将不会被调度到这个 Node 上。
@@ -294,7 +294,7 @@ kube-scheduler 有一系列的默认调度策略。
  计算其优先级。使用这个策略可以将两个不同 Pod 运行在不同的 Node 上。

 - `NodeAffinityPriority`：基于 Pod 属性中 PreferredDuringSchedulingIgnoredDuringExecution 来进行 Node 亲和性调度。你可以通过这篇文章
-  [Pods 到 Nodes 的分派](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/) 来了解到更详细的内容。
+  [Pods 到 Nodes 的分派](/zh/docs/concepts/configuration/assign-pod-node/) 来了解到更详细的内容。

 - `TaintTolerationPriority`：基于 Pod 中对每个 Node 上污点容忍程度进行优先级评估，这个策略能够调整待选 Node 的排名。

@@ -304,16 +304,16 @@ kube-scheduler 有一系列的默认调度策略。
  没有归属于同一个 Service 的 Pod，这个策略更倾向于将 Pod 调度到这类 Node 上。最终的目的：即使在一个 Node 宕机之后 Service 也具有很强容灾能力。

 - `CalculateAntiAffinityPriorityMap`：这个策略主要是用来实现[pod反亲和]
-  (https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)。
-  
+  (/zh/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)。
+
 - `EqualPriorityMap`：将所有的 Node 设置成相同的权重为 1。

 {{% /capture %}}
 {{% capture whatsnext %}}
-* 阅读关于 [调度器性能调优](/docs/concepts/scheduling/scheduler-perf-tuning/)
-* 阅读关于 [Pod 拓扑分布约束](/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/administer-cluster/topology-manager/)
-* 了解关于 [Pod 额外开销](/docs/concepts/configuration/pod-overhead/)
+* 阅读关于 [调度器性能调优](/zh/docs/concepts/scheduling/scheduler-perf-tuning/)
+* 阅读关于 [Pod 拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
+* 阅读关于 kube-scheduler 的 [参考文档](/zh/docs/reference/command-line-tools-reference/kube-scheduler/)
+* 了解关于 [配置多个调度器](/zh/docs/tasks/administer-cluster/configure-multiple-schedulers/) 的方式
+* 了解关于 [拓扑结构管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)
+* 了解关于 [Pod 额外开销](/zh/docs/concepts/configuration/pod-overhead/)
 {{% /capture %}}
@@ -66,6 +66,7 @@ Service
 服务（Service）：
 Kubernetes {{< glossary_tooltip term_id="service" >}} 使用 {{< glossary_tooltip text="标签" term_id="label" >}} 选择器（selectors）标识的一组 Pod。除非另有说明，否则假定服务只具有在集群网络中可路由的虚拟 IP。

+
 <!--
 ## What is Ingress?
 -->
@@ -76,8 +77,9 @@ Ingress exposes HTTP and HTTPS routes from outside the cluster to
 {{< link text="services" url="/docs/concepts/services-networking/service/" >}} within the cluster.
 Traffic routing is controlled by rules defined on the Ingress resource. 
 -->
-Ingress公开了从集群外部到集群内 {{< link text="services" url="/docs/concepts/services-networking/service/" >}} 的HTTP和HTTPS路由。
-流量路由由Ingress资源上定义的规则控制。
+
+Ingress 公开了从集群外部到集群内 {{< link text="services" url="/docs/concepts/services-networking/service/" >}} 的HTTP和HTTPS路由。
+流量路由由 Ingress 资源上定义的规则控制。

 ```none
    internet
@@ -699,11 +701,9 @@ Please check the documentation of the relevant [Ingress controller](/docs/concep
 for details on deploying Ingress in a federated cluster.
 -->

-## 跨可用区失败
-
 用于跨故障域传播流量的技术在云提供商之间是不同的。详情请查阅相关 Ingress 控制器的文档。
-请查看相关[Ingress控制器](/docs/concepts/services-networking/ingress-controllers)的文档以了解详细信息。
-您还可以参考[联合文档](/docs/concepts/cluster-administration/federation/)，以获取有关在联合集群中部署Ingress的详细信息。
+请查看相关[ Ingress 控制器](/docs/concepts/services-networking/ingress-controllers)的文档以了解详细信息。
+您还可以参考[联邦文档](/docs/concepts/cluster-administration/federation/)，以获取有关在联合集群中部署Ingress的详细信息。


 <!--
@@ -815,7 +815,7 @@ The default is `ClusterIP`.

     with its value. No proxying of any kind is set up.
     {{< note >}}
-     You need CoreDNS version 1.7 or higher to use the `ExternalName` type.
+     You need either kube-dns version 1.7 or CoreDNS version 0.0.8 or higher to use the `ExternalName` type.
     {{< /note >}}

 You can also use [Ingress](/docs/concepts/services-networking/ingress/) to expose your Service. Ingress is not a Service type, but it acts as the entry point for your cluster. It lets you consolidate your routing rules into a single resource as it can expose multiple services under the same IP address.
@@ -7,10 +7,12 @@ weight: 20
 <!--
 ---
 reviewers:
- jsafrane
 - saad-ali
 - thockin
 - msau42
+- jingxu97
+- xing-yang
+- yuxiangqian
 title: Volume Snapshots
 content_template: templates/concept
 weight: 20
@@ -19,23 +21,22 @@ weight: 20

 {{% capture overview %}}

-{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
-<!--
-This document describes the current state of `VolumeSnapshots` in Kubernetes. Familiarity with [persistent volumes](/docs/concepts/storage/persistent-volumes/) is suggested.
-->
+{{< feature-state for_k8s_version="1.17" state="beta" >}}

-本文档描述 Kubernetes 中 `VolumeSnapshots` 的当前状态。建议先熟悉[持久卷](/docs/concepts/storage/persistent-volumes/)。
+<!--
+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 的 [持久卷](/docs/concepts/storage/persistent-volumes/)。

 {{% /capture %}}

-
 {{% capture body %}}

 <!--
 ## Introduction
 -->

-## 介绍
+## 介绍 {#introduction}

 <!--
 Similar to how API resources `PersistentVolume` and `PersistentVolumeClaim` are used to provision volumes for users and administrators, `VolumeSnapshotContent` and `VolumeSnapshot` API resources are provided to create volume snapshots for users and administrators.
@@ -45,7 +46,7 @@ Similar to how API resources `PersistentVolume` and `PersistentVolumeClaim` are
 <!--
 A `VolumeSnapshotContent` is a snapshot taken from a volume in the cluster that has been provisioned by an administrator. It is a resource in the cluster just like a PersistentVolume is a cluster resource.
 -->
-`VolumeSnapshotContent` 是从管理员已提供的集群中的卷获取的快照。就像持久卷是集群的资源一样，它也是集群中的资源。
+`VolumeSnapshotContent` 是一种快照，从管理员已提供的集群中的卷获取。就像持久卷是集群的资源一样，它也是集群中的资源。

 <!--
 A `VolumeSnapshot` is a request for snapshot of a volume by a user. It is similar to a PersistentVolumeClaim.
@@ -53,12 +54,9 @@ A `VolumeSnapshot` is a request for snapshot of a volume by a user. It is simila
 `VolumeSnapshot` 是用户对于卷的快照的请求。它类似于持久卷声明。

 <!--
-While `VolumeSnapshots` allow a user to consume abstract storage resources, cluster administrators
-need to be able to offer a variety of `VolumeSnapshotContents` without exposing
-users to the details of how those volume snapshots should be provisioned. For these needs
-there is the `VolumeSnapshotClass` resource.
+`VolumeSnapshotClass` allows you to specify different attributes belonging to a `VolumeSnapshot`. These attibutes may differ among snapshots taken from the same volume on the storage system and therefore cannot be expressed by using the same `StorageClass` of a `PersistentVolumeClaim`.
 -->
-`VolumeSnapshots` 允许用户消费抽象的存储资源，集群管理员需要能够提供多种 `VolumeSnapshotContents`，又不会向用户暴露这些应该供应的卷快照的细节。为了实现这些需求，就需要 `VolumeSnapshotClass` 资源。
+`VolumeSnapshotClass` 允许指定属于 `VolumeSnapshot` 的不同属性。从存储系统上相同卷上获取的不同快照，这些参数可能会不一样，因此不能用一个 `PersistentVolumeClaim` 的相同 `StorageClass` 来指卷快照。

 <!--
 Users need to be aware of the following when using this feature:
@@ -66,178 +64,192 @@ Users need to be aware of the following when using this feature:
 当使用该功能时，用户需要注意以下几点：

 <!--
-* API Objects `VolumeSnapshot`, `VolumeSnapshotContent`, and `VolumeSnapshotClass` are CRDs, not part of the core API.
+* API Objects `VolumeSnapshot`, `VolumeSnapshotContent`, and `VolumeSnapshotClass` are {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}, not part of the core API.
 * `VolumeSnapshot` support is only available for CSI drivers.
-* As part of the deployment process, the Kubernetes team provides a sidecar helper container for the snapshot controller called `external-snapshotter`. It watches `VolumeSnapshot` objects and triggers `CreateSnapshot` and `DeleteSnapshot` operations against a CSI endpoint.
-* CSI drivers may or may not have implemented the volume snapshot functionality. The CSI drivers that have provided support for volume snapshot will likely use `external-snapshotter`.
-* The CSI drivers that support volume snapshot will automatically install CRDs defined for the volume snapshots.
+* As part of the deployment process in the beta version of `VolumeSnapshot`, the Kubernetes team provides a snapshot controller to be deployed into the control plane, and a sidecar helper container called csi-snapshotter to be deployed together with the CSI driver.  The snapshot controller watches `VolumeSnapshot` and `VolumeSnapshotContent` objects and is responsible for the creation and deletion of `VolumeSnapshotContent` object in dynamic provisioning.  The sidecar csi-snapshotter watches `VolumeSnapshotContent` objects and triggers `CreateSnapshot` and `DeleteSnapshot` operations against a CSI endpoint.
+* CSI drivers may or may not have implemented the volume snapshot functionality. The CSI drivers that have provided support for volume snapshot will likely use the csi-snapshotter. See [CSI Driver documentation](https://kubernetes-csi.github.io/docs/) for details.
+* The CRDs and snapshot controller installations are the responsibility of the Kubernetes distribution.
 -->
-* API 对象 `VolumeSnapshot`，`VolumeSnapshotContent` 和 `VolumeSnapshotClass` 是 CRD，不是核心 API 的部分。
+* API 对象 `VolumeSnapshot`，`VolumeSnapshotContent` 和 `VolumeSnapshotClass` 是 {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}，不是核心 API 的部分。
 * `VolumeSnapshot` 支持仅可用于 CSI 驱动。
-* 作为部署过程的一部分，Kubernetes 团队为快照控制器提供了一个名为 `external-snapshotter` 的 sidecar 帮助容器。它监视 `VolumeSnapshot` 对象然后向 CSI 端点触发 `CreateSnapshot` 和 `DeleteSnapshot` 操作。
-* CSI 驱动可能实现，也可能没有实现卷快照功能。CSI 驱动可能会使用 `external-snapshotter` 来提供对卷快照的支持。
-* 支持卷快照的 CSI 驱动将自动安装 用于定义卷快照定义的 CRD。
+* 作为 beta 版本 `VolumeSnapshot` 部署过程的一部分，Kubernetes 团队提供了一个部署于控制平面的快照控制器，并且提供了一个叫做 `csi-snapshotter` 的 sidecar 帮助容器，它和 CSI 驱动程序部署在一起。快照控制器监视 `VolumeSnapshot` 和 `VolumeSnapshotContent` 对象，并且负责动态的创建和删除 `VolumeSnapshotContent` 对象。sidecar csi-snapshotter 监视 `VolumeSnapshotContent` 对象，并且触发针对 CSI 端点的 `CreateSnapshot` 和 `DeleteSnapshot` 的操作。
+* CSI 驱动可能实现，也可能没有实现卷快照功能。CSI 驱动可能会使用 csi-snapshotter 来提供对卷快照的支持。详见 [CSI 驱动程序文档](https://kubernetes-csi.github.io/docs/)
+* Kubernetes 负责 CRDs 和快照控制器的安装。

 <!--
 ## Lifecycle of a volume snapshot and volume snapshot content
-->
-## 卷快照和卷快照内容的生命周期

-<!--
 `VolumeSnapshotContents` are resources in the cluster. `VolumeSnapshots` are requests for those resources. The interaction between `VolumeSnapshotContents` and `VolumeSnapshots` follow this lifecycle:
 -->
+## 卷快照和卷快照内容的生命周期 {#lifecycle-of-a-volume-snapshot-and-volume-snapshot-content}
+
 `VolumeSnapshotContents` 是集群中的资源。`VolumeSnapshots` 是对于这些资源的请求。`VolumeSnapshotContents` 和 `VolumeSnapshots` 之间的交互遵循以下生命周期：

 <!--
 ### Provisioning Volume Snapshot
+
+There are two ways snapshots may be provisioned: pre-provisioned or dynamically provisioned.
 -->
-### 供应卷快照
+### 供应卷快照 {#provisioning-volume-snapshot}
+
+快照可以通过两种方式进行配置：预配置或动态配置。

 <!--
-There are two ways snapshots may be provisioned: statically or dynamically.
+#### Pre-provisioned {#static}
+A cluster administrator creates a number of `VolumeSnapshotContents`. They carry the details of the real volume snapshot on the storage system which is available for use by cluster users. They exist in the Kubernetes API and are available for consumption.
 -->
-快照可以通过两种方式进行供应：静态或动态。
-
-<!--
-#### Static
-->
-#### 静态的
-<!--
-A cluster administrator creates a number of `VolumeSnapshotContents`. They carry the details of the real storage which is available for use by cluster users. They exist in the Kubernetes API and are available for consumption.
-->
-集群管理员创建多个 `VolumeSnapshotContents`。它们带有实际存储的详细信息，可以供集群用户使用。它们存在于 Kubernetes API 中，并且能够被使用。
+#### 预配置 {#static}
+集群管理员创建多个 `VolumeSnapshotContents`。它们带有存储系统上实际卷快照的详细信息，可以供集群用户使用。它们存在于 Kubernetes API 中，并且能够被使用。

 <!--
 #### Dynamic
+
+Instead of using a pre-existing snapshot, you can request that a snapshot to be dynamically taken from a PersistentVolumeClaim. The [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/) specifies storage provider-specific parameters to use when taking a snapshot.
 -->
-#### 动态的
-<!--
-When none of the static `VolumeSnapshotContents` the administrator created matches a user's `VolumeSnapshot`,
-the cluster may try to dynamically provision a volume snapshot specially for the `VolumeSnapshot` object.
-This provisioning is based on `VolumeSnapshotClasses`: the `VolumeSnapshot` must request a
-[volume snapshot class](/docs/concepts/storage/volume-snapshot-classes/) and
-the administrator must have created and configured that class in order for dynamic
-provisioning to occur.
-->
-当管理员创建的静态 `VolumeSnapshotContents` 都不能匹配用户的 `VolumeSnapshot`，集群可能会尝试专门为 `VolumeSnapshot` 对象供应一个卷快照。此供应基于 `VolumeSnapshotClasses`：`VolumeSnapshot` 必须请求[卷快照类](/docs/concepts/storage/volume-snapshot-classes/)并且管理员必须已经创建并配置了该类，才能进行动态供应。
+#### 动态的 {#dynamic}
+
+可以从一个 `PersistentVolumeClaim` 申请动态的获取一个快照，而不用使用已经存在的快照。在使用快照时，[卷快照类](/docs/concepts/storage/volume-snapshot-classes/)指定确切的存储提供者参数。

 <!--
 ### Binding
+
+The snapshot controller handles the binding of a `VolumeSnapshot` object with an appropriate `VolumeSnapshotContent` object, in both pre-provisioned and dynamically provisioned scenarios. The binding is a one-to-one mapping.
 -->
-### 绑定
+### 绑定 {#binding}
+
+在预配置和动态配置场景下，快照控制器处理绑定 `VolumeSnapshot` 对象和其合适的 `VolumeSnapshotContent` 对象。绑定关系是一对一的。

 <!--
-A user creates, or has already created in the case of dynamic provisioning, a `VolumeSnapshot` with a specific amount of storage requested and with certain access modes. A control loop watches for new VolumeSnapshots, finds a matching VolumeSnapshotContent (if possible), and binds them together. If a VolumeSnapshotContent was dynamically provisioned for a new VolumeSnapshot, the loop will always bind that VolumeSnapshotContent to the VolumeSnapshot. Once bound, `VolumeSnapshot` binds are exclusive, regardless of how they were bound. A VolumeSnapshot to VolumeSnapshotContent binding is a one-to-one mapping.
+In the case of pre-provisioned binding, the VolumeSnapshot will remain unbound until the requested VolumeSnapshotContent object is created.
 -->
-用户创建，或在动态供应场景下已经创建了的 `VolumeSnapshot` 具有特定数量的存储请求和特定的访问模式。一个控制循环监视新的 VolumeSnapshots，找到匹配的 VolumeSnapshotContent（如果可能），并把它们绑定到一起。如果 VolumeSnapshotContent 是给动态供应给一个新的VolumeSnapshot，循环将依然绑定 VolumeSnapshotContent 到 VolumeSnapshot。一旦绑定，无论是如何绑定的，`VolumeSnapshot` 绑定都是排他的。VolumeSnapshot 到 VolumeSnapshotContent 的绑定是一对一的映射。
+在预配置快照绑定场景下，`VolumeSnapshotContent` 对象创建之后，才会和 `VolumeSnapshot` 进行绑定。

 <!--
-VolumeSnapshots will remain unbound indefinitely if a matching VolumeSnapshotContent does not exist. VolumeSnapshots will be bound as matching VolumeSnapshotContents become available.
-->
-如果不存在匹配的 VolumeSnapshotContent，VolumeSnapshots 将永远保持未绑定状态。当匹配的 VolumeSnapshotContents 可用时，将绑定 VolumeSnapshots。
+### Persistent Volume Claim as Snapshot Source Protection

-<!--
-### Persistent Volume Claim in Use Protection
-->
-### 使用保护的持久性卷声明
-
-<!--
 The purpose of the Persistent Volume Claim Object in Use Protection feature is to ensure that in-use PVC API objects are not removed from the system (as this may result in data loss).
+
+The purpose of this protection is to ensure that in-use PersistentVolumeClaim API objects are not removed from the system while a snapshot is being taken from it (as this may result in data loss).
 -->
-使用保护的持久性卷声明功能的目的是确保使用中的 PVC API 对象不会从系统中被删除（因为这可能会导致数据丢失）。
+### 快照源的持久性卷声明保护
+
+这种保护的目的是确保当从 `PersistentVolumeClaim` API 对象中做快照的时候，它不会被从系统中删除（因为这可能会导致数据丢失）。

 <!--
-If a PVC is in active use by a snapshot as a source to create the snapshot, the PVC is in-use. If a user deletes a PVC API object in active use as a snapshot source, the PVC object is not removed immediately. Instead, removal of the PVC object is postponed until the PVC is no longer actively used by any snapshots. A PVC is no longer used as a snapshot source when `ReadyToUse` of the snapshot `Status` becomes `true`.
+
+While a snapshot is being taken of a PersistentVolumeClaim, that PersistentVolumeClaim is in-use. If you delete a PersistentVolumeClaim API object in active use as a snapshot source, the PersistentVolumeClaim object is not removed immediately. Instead, removal of the PersistentVolumeClaim object is postponed until the snapshot is readyToUse or aborted.
 -->
 如果一个 PVC 正在被快照用来作为源进行快照创建，则该 PVC 是使用中的。如果用户删除正作为快照源的 PVC API 对象，则 PVC 对象不会立即被删除掉。相反，PVC 对象的删除将推迟到任何快照不在主动使用它为止。当快照的 `Status` 中的 `ReadyToUse`值为 `true` 时，PVC 将不再用作快照源。

+当从 `PersistentVolumeClaim` 中生成快照时，`PersistentVolumeClaim` 就在被使用了。如果删除一个作为快照源的 `PersistentVolumeClaim` 对象，这个 `PersistentVolumeClaim` 对象不会立即被删除的。相反，在快照可以被使用或者被放弃之后，才会执行删除 `PersistentVolumeClaim` 对象的动作。
+
 <!--
 ### Delete
+
+Deletion is triggered by deleting the `VolumeSnapshot` object, and the `DeletionPolicy` will be followed. If the `DeletionPolicy` is `Delete`, then the underlying storage snapshot will be deleted along with the `VolumeSnapshotContent` object. If the `DeletionPolicy` is `Retain`, then both the underlying snapshot and `VolumeSnapshotContent` remain.
 -->
-### 删除
+### 删除 {#delete}
+
+删除 `VolumeSnapshot` 对象触发删除 `VolumeSnapshotContent` 操作，并且 `DeletionPolicy` 会紧跟着执行。如果 `DeletionPolicy` 是 `Delete`，那么底层存储快照会和 `VolumeSnapshotContent` 一起被删除。如果 `DeletionPolicy` 是 `Retain`，那么底层快照和 `VolumeSnapshotContent` 都会被保留。

 <!--
-Deletion removes both the `VolumeSnapshotContent` object from the Kubernetes API, as well as the associated storage asset in the external infrastructure.
-->
-删除操作会从 Kubernetes API 中删除 `VolumeSnapshotContent` 对象，同时删除它在外部基础架构中关联存储资产。
-
-<!--
-## Volume Snapshot Contents
-->
-## 卷快照内容
-
-<!--
-Each VolumeSnapshotContent contains a spec, which is the specification of the volume snapshot.
-->
-每个 VolumeSnapshotContent 包含一个 spec，用来表示卷快照的规格。
-
-```yaml
-apiVersion: snapshot.storage.k8s.io/v1alpha1
-kind: VolumeSnapshotContent
-metadata:
-  name: new-snapshot-content-test
-spec:
-  snapshotClassName: csi-hostpath-snapclass
-  source:
-    name: pvc-test
-    kind: PersistentVolumeClaim
-  volumeSnapshotSource:
-    csiVolumeSnapshotSource:
-      creationTime:    1535478900692119403
-      driver:          csi-hostpath
-      restoreSize:     10Gi
-      snapshotHandle:  7bdd0de3-aaeb-11e8-9aae-0242ac110002
-```
-
-<!--
-### Class
-->
-### 类
-
-<!--
-A VolumeSnapshotContent can have a class, which is specified by setting the
-`snapshotClassName` attribute to the name of a
-[VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/).
-A VolumeSnapshotContent of a particular class can only be bound to VolumeSnapshots requesting
-that class. A VolumeSnapshotContent with no `snapshotClassName` has no class and can only be bound
-to VolumeSnapshots that request no particular class.
-->
-VolumeSnapshotContent 可以具有一个类，该类通过设置 `snapshotClassName` 属性为 [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/) 的名称来指定。一个特定类的 VolumeSnapshotContent 只能够绑定到请求该类的 VolumeSnapshots。没有 `snapshotClassName` 的 VolumeSnapshotContent 没有类，并且只能绑定到不要求特定类的 VolumeSnapshots。
-
-
 ## VolumeSnapshots

-<!--
-Each VolumeSnapshot contains a spec and a status, which is the specification and status of the volume snapshot.
+Each VolumeSnapshot contains a spec and a status.
 -->
-每个 VolumeSnapshot 对象包含 spec 和 status，用来表示卷快照的规格和状态。
+## 卷快照 {#volume-snapshots}
+
+每个 `VolumeSnapshot` 包含一个 spec 和一个状态。

 ```yaml
-apiVersion: snapshot.storage.k8s.io/v1alpha1
+apiVersion: snapshot.storage.k8s.io/v1beta1
 kind: VolumeSnapshot
 metadata:
  name: new-snapshot-test
 spec:
-  snapshotClassName: csi-hostpath-snapclass
+  volumeSnapshotClassName: csi-hostpath-snapclass
  source:
-    name: pvc-test
-    kind: PersistentVolumeClaim
+    persistentVolumeClaimName: pvc-test
 ```

 <!--
-### Class
-->
-### 类
+`persistentVolumeClaimName` is the name of the PersistentVolumeClaim data source for the snapshot. This field is required for dynamically provisioning a snapshot.

-<!--
 A volume snapshot can request a particular class by specifying the name of a
 [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/)
-using the attribute `snapshotClassName`.
-Only VolumeSnapshotContents of the requested class, ones with the same `snapshotClassName`
-as the VolumeSnapshot, can be bound to the VolumeSnapshot.
+using the attribute `volumeSnapshotClassName`. If nothing is set, then the default class is used if available.
 -->
-通过使用 `snapshotClassName` 属性来指定 [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/) 的名称，卷快照可以请求特定的类。
-只有所请求类（与 VolumeSnapshot 有相同的 `snapshotClassName`）的 VolumeSnapshotContents 才可以绑定到 VolumeSnapshot。
+`persistentVolumeClaimName` 是 `PersistentVolumeClaim` 数据源对快照的名称。这个字段是动态配置快照中的必填字段。
+
+卷快照可以通过指定 [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/) 使用 `volumeSnapshotClassName` 属性来请求特定类。如果没有设置，那么使用默认类（如果有）。
+
+<!--
+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.
+-->
+对于预配置的快照，像下面的例子一样，需要给快照指定 `volumeSnapshotContentName` 来作为源。对于预配置的快照 `source` 中的`volumeSnapshotContentName` 字段是必填的
+
+```
+apiVersion: snapshot.storage.k8s.io/v1beta1
+kind: VolumeSnapshot
+metadata:
+  name: test-snapshot
+spec:
+  source:
+        volumeSnapshotContentName: test-content
+```
+
+<!--
+## Volume Snapshot Contents
+
+Each VolumeSnapshot contains a spec and a status, which is the specification and status of the volume snapshot.
+Each VolumeSnapshotContent contains a spec and status. In dynamic provisioning, the snapshot common controller creates `VolumeSnapshotContent` objects. Here is an example:
+-->
+每个 VolumeSnapshotContent 对象包含 spec 和 status。在动态配置时，快照通用控制器创建 `VolumeSnapshotContent` 对象。下面是例子：
+
+```yaml
+apiVersion: snapshot.storage.k8s.io/v1beta1
+kind: VolumeSnapshotContent
+metadata:
+  name: snapcontent-72d9a349-aacd-42d2-a240-d775650d2455
+spec:
+  deletionPolicy: Delete
+  driver: hostpath.csi.k8s.io
+  source:
+    volumeHandle: ee0cfb94-f8d4-11e9-b2d8-0242ac110002
+  volumeSnapshotClassName: csi-hostpath-snapclass
+  volumeSnapshotRef:
+    name: new-snapshot-test
+    namespace: default
+    uid: 72d9a349-aacd-42d2-a240-d775650d2455
+```
+
+<!--
+`volumeHandle` is the unique identifier of the volume created on the storage backend and returned by the CSI driver during the volume creation. This field is required for dynamically provisioning a snapshot. It specifies the volume source of the snapshot.
+
+For pre-provisioned snapshots, you (as cluster administrator) are responsible for creating the `VolumeSnapshotContent` object as follows.
+-->
+`volumeHandle` 是存储后端创建卷的唯一标识符，在卷创建期间由 CSI 驱动程序返回。动态设置快照需要此字段。它指出了快照的卷源。
+
+对于预配置快照，你（作为集群管理员）要按如下命令来创建 `VolumeSnapshotContent` 对象。
+
+```yaml
+apiVersion: snapshot.storage.k8s.io/v1beta1
+kind: VolumeSnapshotContent
+metadata:
+  name: new-snapshot-content-test
+spec:
+  deletionPolicy: Delete
+  driver: hostpath.csi.k8s.io
+  source:
+    snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002
+  volumeSnapshotRef:
+    name: new-snapshot-test
+    namespace: default
+```
+<!--
+`snapshotHandle` is the unique identifier of the volume snapshot created on the storage backend. This field is required for the pre-provisioned snapshots. It specifies the CSI snapshot id on the storage system that this `VolumeSnapshotContent` represents.
+-->
+`snapshotHandle` 是存储后端创建卷的唯一标识符。对于预设置快照，这个字段是必须的。它指定此 `VolumeSnapshotContent` 表示的存储系统上的 CSI 快照 id。

 <!--
 ## Provisioning Volumes from Snapshots
@@ -248,7 +260,7 @@ as the VolumeSnapshot, can be bound to the VolumeSnapshot.
 You can provision a new volume, pre-populated with data from a snapshot, by using
 the *dataSource* field in the `PersistentVolumeClaim` object.
 -->
-你可以供应一个新卷，该卷预填充了快照中的数据，在 `持久卷声明` 对象中使用 *dataSource* 字段。
+你可以配置一个新卷，该卷预填充了快照中的数据，在 `持久卷声明` 对象中使用 *dataSource* 字段。

 <!--
 For more details, see
@@ -87,7 +87,7 @@ For an example of adding a new localization, see the PR to enable [docs in Frenc

 PR 必须包含所有[最低要求的内容](#minimum-required-content)，然后才能被批准。

-有关添加新本地化的示例，请参见添加[法语文档]（https://github.com/kubernetes/website/pull/12548） 的 PR。
+有关添加新本地化的示例，请参见添加[法语文档](https://github.com/kubernetes/website/pull/12548) 的 PR。
    
 ### Join the Kubernetes GitHub organization

@@ -44,11 +44,11 @@ This section of the Kubernetes documentation contains references.

 * [Kubernetes API Overview](/docs/reference/using-api/api-overview/) - Overview of the API for Kubernetes.
 * Kubernetes API Versions
+  * [1.17](/docs/reference/generated/kubernetes-api/v1.17/)
  * [1.16](/docs/reference/generated/kubernetes-api/v1.16/)
  * [1.15](/docs/reference/generated/kubernetes-api/v1.15/)
  * [1.14](/docs/reference/generated/kubernetes-api/v1.14/)
  * [1.13](/docs/reference/generated/kubernetes-api/v1.13/)
-  * [1.12](/docs/reference/generated/kubernetes-api/v1.12/)
 -->

 ## API 客户端库
@@ -179,14 +179,3 @@ kubeadm join phase kubelet-start [api-server-endpoint] [flags]
  </tbody>
 </table>

-
-
-<!--
-SEE ALSO
-->
-查看其他
-
-<!--
-* [kubeadm join phase](kubeadm_join_phase.md)	 - Use this command to invoke single phase of the join workflow
-->
-* [kubeadm join phase](kubeadm_join_phase.md)	 - 使用此命令可以调用 `join` 工作流程的某个阶段
@@ -256,14 +256,3 @@ kubeadm join phase preflight [api-server-endpoint] [flags]
  </tbody>
 </table>

-
-
-<!--
-SEE ALSO
-->
-查看其他
-
-<!--
-* [kubeadm join phase](kubeadm_join_phase.md)	 - Use this command to invoke single phase of the join workflow
-->
-* [kubeadm join phase](kubeadm_join_phase.md)	 - 使用此命令可以调用 `join` 工作流程的某个阶段
@@ -163,16 +163,3 @@ kubeadm reset [flags]
  </tbody>
 </table>

-
-
-<!--
-SEE ALSO
-->
-查看其他
-
-<!--
-* [kubeadm](kubeadm.md)	 - kubeadm: easily bootstrap a secure Kubernetes cluster
-* [kubeadm reset phase](kubeadm_reset_phase.md)	 - Use this command to invoke single phase of the reset workflow
-->
-* [kubeadm](kubeadm.md)	 - kubeadm: 轻松建立安全的 Kubernetes 集群
-* [kubeadm reset phase](kubeadm_reset_phase.md)	 - 使用此命令来调用 `reset` 工作流程的某个阶段
@@ -67,30 +67,3 @@ Use this command to invoke single phase of the reset workflow
 </table>


-
-<!--
-SEE ALSO
-->
-查看其他
-
-<!--
-* [kubeadm reset](kubeadm_reset.md)	 - Performs a best effort revert of changes made to this host by 'kubeadm init' or 'kubeadm join'
-->
-* [kubeadm reset](kubeadm_reset.md)	 - 尽最大努力还原通过 “kubeadm init” 或 “kubeadm join” 操作对主机所做的更改
-<!--
-* [kubeadm reset phase cleanup-node](kubeadm_reset_phase_cleanup-node.md)	 - Run cleanup node.
-->
-* [kubeadm reset phase cleanup-node](kubeadm_reset_phase_cleanup-node.md)	 - 执行 cleanup node（清理节点）操作。
-<!--
-* [kubeadm reset phase preflight](kubeadm_reset_phase_preflight.md)	 - Run reset pre-flight checks
-->
-* [kubeadm reset phase preflight](kubeadm_reset_phase_preflight.md)	 - 运行 reset 命令启动前检查
-<!--
-* [kubeadm reset phase remove-etcd-member](kubeadm_reset_phase_remove-etcd-member.md)	 - Remove a local etcd member.
-->
-* [kubeadm reset phase remove-etcd-member](kubeadm_reset_phase_remove-etcd-member.md)	 - 删除某个本地 etcd 成员。
-<!--
-* [kubeadm reset phase update-cluster-status](kubeadm_reset_phase_update-cluster-status.md)	 - Remove this node from the ClusterStatus object.
-->
-* [kubeadm reset phase update-cluster-status](kubeadm_reset_phase_update-cluster-status.md)	 - 从 ClusterStatus 对象中删除该节点。
-
@@ -99,16 +99,3 @@ kubeadm reset phase cleanup-node [flags]
  </tbody>
 </table>

-
-
-<!--
-SEE ALSO
-->
-查看其他
-
-
-<!--
-* [kubeadm reset phase](kubeadm_reset_phase.md)	 - Use this command to invoke single phase of the reset workflow
-->
-* [kubeadm reset phase](kubeadm_reset_phase.md)	 - 使用此命令来调用 `reset` 工作流程的某个阶段
-
@@ -139,12 +139,3 @@ kubeadm upgrade diff [version] [flags]
  <td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] “真实”主机根文件系统的路径。</td>
 </tr>

-<!--
-SEE ALSO
-->
-参考
-<!--
- [kubeadm upgrade](https://github.com/kubernetes/website/blob/release-1.16/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade.md) - Upgrade your cluster smoothly to a newer version with this command
-->
-
- [kubeadm upgrade](https://github.com/kubernetes/website/blob/release-1.16/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade.md) - 使用此命令将集群平滑升级到新版本
@@ -64,18 +64,3 @@ Use this command to invoke single phase of the node workflow

  </tbody>
 </table>
-
-
-<!--
-SEE ALSO
-->
-查看其他
-
-<!--
-* [kubeadm upgrade node](kubeadm_upgrade_node.md)	 - Upgrade commands for a node in the cluster
-* [kubeadm upgrade node phase control-plane](kubeadm_upgrade_node_phase_control-plane.md)	 - Upgrade the control plane instance deployed on this node, if any
-* [kubeadm upgrade node phase kubelet-config](kubeadm_upgrade_node_phase_kubelet-config.md)	 - Upgrade the kubelet configuration for this node
-->
-* [kubeadm upgrade node](kubeadm_upgrade_node.md)	 - 集群中某个节点的升级命令
-* [kubeadm upgrade node phase control-plane](kubeadm_upgrade_node_phase_control-plane.md)	 - 升级部署在此节点上的控制平面实例（如果有）
-* [kubeadm upgrade node phase kubelet-config](kubeadm_upgrade_node_phase_kubelet-config.md)	 - 升级此节点的 kubelet 配置
@@ -80,10 +80,6 @@ kubeadm upgrade node phase kubelet-config [flags]
  </tbody>
 </table>

-SEE ALSO
-
-* [kubeadm upgrade node phase](kubeadm_upgrade_node_phase.md)	 - Use this command to invoke single phase of the node workflow
-



@@ -145,10 +145,3 @@ kubeadm upgrade plan [version] [flags]
 <tr>
  <td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] “真实”主机根文件系统的路径。</td>
 </tr>
-
-<!--
-SEE ALSO
-->
-参考
-
- [kubeadm upgrade](https://github.com/kubernetes/website/blob/release-1.16/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade.md) - 使用此命令将集群平滑升级到新版本
@@ -48,19 +48,19 @@ See also [The upgrade documentation](/docs/tasks/administer-cluster/kubeadm/kube

 您也可以阅读 [升级文件](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15)。

-{{< caution >}}
 <!--
 This page does not address running your cluster on a cloud provider. In a cloud
 environment, neither approach documented here works with Service objects of type
 LoadBalancer, or with dynamic PersistentVolumes.
 -->
+{{< caution >}}
 这篇文档没有讲述在云提供商上运行集群的问题。在云环境中，此处记录的方法不适用于类型为 LoadBalancer 的服务对象，或者具有动态的 PersistentVolumes。
-
 {{< /caution >}}

 {{% /capture %}}

 {{% capture prerequisites %}}
+
 <!--
 For both methods you need this infrastructure:

@@ -107,8 +107,9 @@ There are many configurations for load balancers. The following example is only
 option. Your cluster requirements may need a different configuration.
 -->
 {{< note >}}
-**注意**：使用负载均衡器需要许多配置。您的集群搭建可能需要不同的配置。下面的例子只是其中的一方面配置。
+使用负载均衡器需要许多配置。您的集群搭建可能需要不同的配置。下面的例子只是其中的一方面配置。
 {{< /note >}}
+
 <!--

 1.  Create a kube-apiserver load balancer with a name that resolves to DNS.
@@ -130,6 +131,7 @@ option. Your cluster requirements may need a different configuration.
    - Make sure the address of the load balancer always matches
      the address of kubeadm's `ControlPlaneEndpoint`.
 -->
+
 1.  创建一个名为 kube-apiserver 的负载均衡器解析 DNS。

    - 在云环境中，应该将控制平面节点放置在 TCP 后面转发负载平衡。 该负载均衡器将流量分配给目标列表中所有运行状况良好的控制平面节点。健康检查 apiserver 是在 kube-apiserver 监听端口(默认值 `:6443`)上的一个 TCP 检查。
@@ -157,6 +159,7 @@ option. Your cluster requirements may need a different configuration.

 1.  Add the remaining control plane nodes to the load balancer target group.
 -->
+
 1.  添加第一个控制平面节点到负载均衡器并测试连接：

    ```sh
@@ -173,6 +176,7 @@ option. Your cluster requirements may need a different configuration.

 <!-- ### Steps for the first control plane node -->
 ### 控制平面节点的第一步
+
 <!--

 1.  Initialize the control plane:
@@ -200,42 +204,41 @@ option. Your cluster requirements may need a different configuration.

    - 您可以使用 `--kubernetes-version` 标志来设置要使用的 Kubernetes 版本。建议将 kubeadm、kebelet、kubectl 和 Kubernetes 的版本匹配。
    - 这个 `--control-plane-endpoint` 标志应该被设置成负载均衡器的地址或 DNS 和端口。
-
    - 这个 `--upload-certs` 标志用来将在所有控制平面实例之间的共享证书上传到集群。如果正好相反，你更喜欢手动地通过控制平面节点或者使用自动化
   工具复制证书，请删除此标志并参考如下部分[证书分配手册](#manual-certs)。

-{{< note >}}
 <!--
 The `kubeadm init` flags `--config` and `--certificate-key` cannot be mixed, therefore if you want
 to use the [kubeadm configuration](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2) you must add the `certificateKey` field in the appropriate config locations (under `InitConfiguration` and `JoinConfiguration: controlPlane`).
 -->
-**注意**：标志 `kubeadm init`、`--config` 和 `--certificate-key` 不能混合使用，因此如果您要使用[kubeadm 配置](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)，您必须在相应的配置文件（位于 `InitConfiguration` 和 `JoinConfiguration: controlPlane`）添加 `certificateKey` 字段。
+{{< note >}}
+标志 `kubeadm init`、`--config` 和 `--certificate-key` 不能混合使用，因此如果您要使用[kubeadm 配置](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)，您必须在相应的配置文件（位于 `InitConfiguration` 和 `JoinConfiguration: controlPlane`）添加 `certificateKey` 字段。
 {{< /note >}}

-{{< note >}}
 <!--
 Some CNI network plugins like Calico require a CIDR such as `192.168.0.0/16` and
 some like Weave do not. See the [CNI network documentation](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network).
 To add a pod CIDR pass the flag `--pod-network-cidr`, or if you are using a kubeadm configuration file
 set the `podSubnet` field under the `networking` object of `ClusterConfiguration`.
 -->
-**注意**：一些 CNI 网络插件如 Calico 需要 CIDR 例如 `192.168.0.0/16` 和一些像 Weave 没有。参考 [CNI 网络文档](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)。
-通过传递 `--pod-network-cidr` 标志添加 pod CIDR，或者您可以使用 kubeadm 配置文件，在 `ClusterConfiguration` 的 `networking` 对象下设置 `podSubnet` 字段。
 {{< note >}}
-<!--
+一些 CNI 网络插件如 Calico 需要 CIDR 例如 `192.168.0.0/16` 和一些像 Weave 没有。参考 [CNI 网络文档](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network)。
+通过传递 `--pod-network-cidr` 标志添加 pod CIDR，或者您可以使用 kubeadm 配置文件，在 `ClusterConfiguration` 的 `networking` 对象下设置 `podSubnet` 字段。
+{{< /note >}}

+<!--
    After the command completes you should see something like so:

    ```sh
    ...
    You can now join any number of control-plane node by running the following command on each as a root:
-      kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
+    kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07

    Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
    As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward.

    Then you can join any number of worker nodes by running the following on each as root:
-      kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
+    kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
    ```

    - Copy this output to a text file. You will need it later to join control plane and worker nodes to the cluster.
@@ -257,18 +260,18 @@ set the `podSubnet` field under the `networking` object of `ClusterConfiguration

 -->

-    命令完成后，您应该会看到类似以下内容：
+- 命令完成后，您应该会看到类似以下内容：

    ```sh
    ...
    现在，您可以通过在根目录上运行以下命令来加入任意数量的控制平面节点：
-     kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07
+    kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07

    请注意，证书密钥可以访问集群内敏感数据，请保密！
    为了安全起见，将在两个小时内删除上传的证书； 如有必要，您可以使用 kubeadm 初始化上传证书阶段，之后重新加载证书。

-     然后，您可以通过在根目录上运行以下命令来加入任意数量的工作节点：
-      kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
+    然后，您可以通过在根目录上运行以下命令来加入任意数量的工作节点：
+    kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866
    ```

    - 将此输出复制到文本文件。 稍后您将需要它来将控制平面节点和辅助节点加入集群。
@@ -286,17 +289,17 @@ set the `podSubnet` field under the `networking` object of `ClusterConfiguration
      kubeadm alpha certs certificate-key
      ```

-{{< note >}}
 <!--
 The `kubeadm-certs` Secret and decryption key expire after two hours.
 -->
-**注意**： `kubeadm-certs` 密钥和解密密钥会在两个小时后失效。
+{{< note >}}
+`kubeadm-certs` 密钥和解密密钥会在两个小时后失效。
 {{< /note >}}

-{{< caution >}}
 <!--
 As stated in the command output, the certificate key gives access to cluster sensitive data, keep it secret!
 -->
+{{< caution >}}
 正如命令输出中所述，证书密钥可访问群集敏感数据，并将其保密！
 {{< /caution >}}

@@ -337,13 +340,13 @@ As stated in the command output, the certificate key gives access to cluster sen
 -->
 ### 其余控制平面节点的步骤

-{{< note >}}
 <!--
 Since kubeadm version 1.15 you can join multiple control-plane nodes in parallel.
 Prior to this version, you must join new control plane nodes sequentially, only after
 the first node has finished initializing.
 -->
-**注意**：从 kubeadm 1.15 版本开始，您可以并行加入多个控制平面节点。
+{{< note >}}
+从 kubeadm 1.15 版本开始，您可以并行加入多个控制平面节点。
 在此版本之前，您必须在第一个节点初始化后才能依序的增加新的控制平面节点。
 {{< /note >}}

@@ -386,6 +389,7 @@ in the kubeadm config file.

 使用外部 etcd 节点设置集群类似于用于堆叠 etcd 的过程，
 不同之处在于您应该首先设置 etcd，并在 kubeadm 配置文件中传递 etcd 信息。
+
 <!--
 ### Set up the etcd cluster

@@ -462,15 +466,16 @@ in the kubeadm config file.
                certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
                keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key

-{{< note >}}
 <!--
 The difference between stacked etcd and external etcd here is that the external etcd setup requires
 a configuration file with the etcd endpoints under the `external` object for `etcd`.
 In the case of the stacked etcd topology this is managed automatically.
 -->
+{{< note >}}
 这里堆 etcd 和外部 etcd 之前的区别在于设置外部 etcd 需要一个 `etcd` 的 `external` 对象下带有 etcd 端点的配置文件。
 如果是堆 etcd 技术，是自动管理的。
 {{< /note >}}
+
 <!--

    -  Replace the following variables in the config template with the appropriate values for your cluster:
@@ -495,13 +500,13 @@ The following steps are similar to the stacked etcd setup:

 -->

-    -  在您的集群中，将配置模板中的以下变量替换为适当值：
+-  在您的集群中，将配置模板中的以下变量替换为适当值：

-        - `LOAD_BALANCER_DNS`
-        - `LOAD_BALANCER_PORT`
-        - `ETCD_0_IP`
-        - `ETCD_1_IP`
-        - `ETCD_2_IP`
+    - `LOAD_BALANCER_DNS`
+    - `LOAD_BALANCER_PORT`
+    - `ETCD_0_IP`
+    - `ETCD_1_IP`
+    - `ETCD_2_IP`

 以下的步骤与设置堆集群是相似的：

@@ -578,6 +583,7 @@ SSH is required if you want to control all nodes from a single machine.
 有许多方法可以实现这种操作。在下面的例子中我们使用 `ssh` 和 `scp`：

 如果要在单独的一台计算机控制所有节点，则需要 SSH。
+
 <!--
 1.  Enable ssh-agent on your main device that has access to all other nodes in
    the system:
@@ -680,12 +686,12 @@ SSH is required if you want to control all nodes from a single machine.
    done
    ```

-{{< caution >}}
 <!--
 Copy only the certificates in the above list. kubeadm will take care of generating the rest of the certificates
 with the required SANs for the joining control-plane instances. If you copy all the certificates by mistake,
 the creation of additional nodes could fail due to a lack of required SANs.
 -->
+{{< caution >}}
 只需要复制上面列表中的证书。kubeadm 将负责生成其余证书以及加入控制平面实例所需的 SAN。
 如果您错误地复制了所有证书，由于缺少所需的 SAN，创建其他节点可能会失败。
 {{< /caution >}}
@@ -7,7 +7,7 @@ reviewers:
 content_template: templates/task
 ---
 <!--
---
+
 title: Control CPU Management Policies on the Node
 reviewers:
 - sjenning
@@ -18,7 +18,7 @@ content_template: templates/task

 {{% capture overview %}}

-{{< feature-state state="beta" >}}
+{{< feature-state for_k8s_version="v1.12" state="beta" >}}

 <!--
 Kubernetes keeps many aspects of how pods execute on nodes abstracted
@@ -153,7 +153,10 @@ CPU 管理器不支持运行时下线和上线 CPUs。此外，如果节点上
 This policy manages a shared pool of CPUs that initially contains all CPUs in the
 node. The amount of exclusively allocatable CPUs is equal to the total
 number of CPUs in the node minus any CPU reservations by the kubelet `--kube-reserved` or
-`--system-reserved` options. CPUs reserved by these options are taken, in
+`--system-reserved` options. From 1.17, the CPU reservation list can be specified
+explicitly by kubelet `--reserved-cpus` option. The explicit CPU list specified by
+`--reserved-cpus` takes precedence over the CPU reservation specified by
+`--kube-reserved` and `--system-reserved`. CPUs reserved by these options are taken, in
 integer quantity, from the initial shared pool in ascending order by physical
 core ID.  This shared pool is the set of CPUs on which any containers in
 `BestEffort` and `Burstable` pods run. Containers in `Guaranteed` pods with fractional
@@ -162,20 +165,21 @@ both part of a `Guaranteed` pod and have integer CPU `requests` are assigned
 exclusive CPUs.
 --->
 该策略管理一个共享 CPU 资源池，最初，该资源池包含节点上所有的 CPU 资源。可用
-的独占性 CPU 资源数量等于节点的 CPU 总量减去通过 `--kube-reserved` 或 `--system-reserved` 参数保留的 CPU 。通过这些参数预留的 CPU 是以整数方式，按物理内
+的独占性 CPU 资源数量等于节点的 CPU 总量减去通过 `--kube-reserved` 或 `--system-reserved` 参数保留的 CPU 。从1.17版本开始，CPU保留列表可以通过 kublet 的 '--reserved-cpus' 参数显式地设置。
+通过 '--reserved-cpus' 指定的显式CPU列表优先于使用 '--kube-reserved' 和 '--system-reserved' 参数指定的保留CPU。 通过这些参数预留的 CPU 是以整数方式，按物理内
 核 ID 升序从初始共享池获取的。 共享池是 `BestEffort` 和 `Burstable` pod 运行
 的 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` when the static
+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` 来保证预留的 CPU 值大于零。 这是因为零预留 CPU 值可能使得共享池变空。
+当启用 static 策略时，要求使用 `--kube-reserved` 和/或 `--system-reserved` 或 `--reserved-cpus` 来保证预留的 CPU 值大于零。 这是因为零预留 CPU 值可能使得共享池变空。
 {{< /note >}}

 <!--
@@ -183,7 +183,7 @@ Corefile 配置包括以下 CoreDNS 的 [插件](https://coredns.io/plugins/)：
 * [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 上提供。
+* [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 进程。
@@ -44,7 +44,7 @@ following command to enable metrics-server:

 集群中的每个节点必须至少具有 1 个 CPU。

-此页面上的一些步骤要求您在集群中运行[metrics-server]（https://github.com/kubernetes-incubator/metrics-server）
+此页面上的一些步骤要求您在集群中运行[metrics-server](https://github.com/kubernetes-incubator/metrics-server)
 服务。如果您的集群中已经有正在运行的 metrics-server 服务，那么您可以跳过这些步骤。

 如果您正在运行{{< glossary_tooltip term_id="minikube" >}}，请运行以下命令启用 metrics-server：
@@ -132,7 +132,7 @@ Create the PersistentVolume:

 配置文件指定了该卷位于集群节点上的 `/mnt/data` 目录。
 该配置还指定了 10 吉比特的卷大小和 `ReadWriteOnce` 的访问模式，这意味着该卷可以在单个节点上以读写方式挂载。
-它为 PersistentVolume 定义了 [StorageClass 名称](/docs/concepts/storage/persistent-volumes/#class) 为 `manual`，StorageClass 名称用来将 PersistentVolumeClaim 请求绑定到该 PersistentVolum。
+它为 PersistentVolume 定义了 [StorageClass 名称](/docs/concepts/storage/persistent-volumes/#class) 为 `manual`，StorageClass 名称用来将 PersistentVolumeClaim 请求绑定到该 PersistentVolume。

 创建 PersistentVolume：

@@ -235,16 +235,16 @@ The format also includes extended `vixie cron` step values. As explained in the

 <!--
 > Step values can be	used in	conjunction with ranges.  Following a range
-> with ``/<number>''	specifies skips	of the number's	value through the
-> range.  For example, ``0-23/2'' can be used in the	hours field to specify
+> with `/<number>` specifies skips	of the number's	value through the
+> range.  For example, `0-23/2` can be used in the	hours field to specify
 > command execution every other hour	(the alternative in the	V7 standard is
-> ``0,2,4,6,8,10,12,14,16,18,20,22'').  Steps are also permitted after an
-> asterisk, so if you want to say ``every two hours'', just use ``*/2''.
+> `0,2,4,6,8,10,12,14,16,18,20,22`).  Steps are also permitted after an
+> asterisk, so if you want to say "every two hours", just use `*/2`.
 -->

-> 步长可被用于范围组合。范围后面带有 ``/<数字>'' 可以声明范围内的步幅数值。
-> 例如，``0-23/2'' 可被用在小时域来声明命令在其他数值的小时数执行（ V7 标准中对应的方法是``0,2,4,6,8,10,12,14,16,18,20,22''）。
-> 步长也可以放在通配符后面，因此如果你想表达 ``每两小时''，就用 ``*/2'' 。
+> 步长可被用于范围组合。范围后面带有 `/<数字>` 可以声明范围内的步幅数值。
+> 例如，`0-23/2` 可被用在小时域来声明命令在其他数值的小时数执行（ V7 标准中对应的方法是`0,2,4,6,8,10,12,14,16,18,20,22`）。
+> 步长也可以放在通配符后面，因此如果你想表达 "每两小时"，就用 `*/2` 。

 {{< note >}}
 <!--
@@ -0,0 +1,12 @@
+# See the OWNERS docs at https://go.k8s.io/owners
+
+# Owned by Kubernetes Blog reviewers
+
+approvers:
+  - sig-docs-blog-owners # Defined in OWNERS_ALIASES
+
+reviewers:
+  -  sig-docs-blog-reviewers # Defined in OWNERS_ALIASES
+
+labels:
+  - area/blog
Author	SHA1	Message	Date
Maksym Vlasov	2dfbdc2cd8	Initial commit for Ukrainian localization (#18569 ) * Initial commit for Ukrainian localization * Fix misspell and crosslink * Add Nikita Potapenko to PR reviewers https://github.com/kubernetes/website/pull/18569#issuecomment-573014402 Co-authored-by: Anastasiya Kulyk <56824659+anastyakulyk@users.noreply.github.com>	2020-01-13 08:51:38 -08:00
Pablo Castellano	10c3c6765a	Fix typo and remove duplicate reference (#17666 ) `AllowedHostPaths` appeared twice	2020-01-13 04:43:37 -08:00
André Martins	5cb0e3d7b4	Update Cilium related docs (#18563 ) * Extend Cilium CNI plugin description Mention that it works on top of other CNI plugins due to the CNI chaining [1]. [1]: http://docs.cilium.io/en/v1.6/gettingstarted/cni-chaining/ Signed-off-by: Martynas Pumputis <m@lambda.lt> * Update Cilium installation steps for kubeadm - Use the latest v1.6 Cilium. - By default, Cilium no longer needs/deploys ETCD store. Signed-off-by: Martynas Pumputis <m@lambda.lt> * Update Cilium NetworkPolicy guide - Update minikube min version requirement. - Use Cilium v1.6. - Remove the etcd store bits, as Cilium v1.6 no longer depend on it by default. Signed-off-by: Martynas Pumputis <m@lambda.lt> * Update Cilium installation steps for kubeadm - How to run without kube-proxy. Signed-off-by: Martynas Pumputis <m@lambda.lt> Co-authored-by: Martynas Pumputis <m@lambda.lt>	2020-01-13 04:35:36 -08:00
Zhang Yong	7969a84110	update zh-trans kubeadm_upgrade_diff.md (#18648 ) * update zh-trans kubeadm_upgrade_plan.md * update zh-trans kubeadm_upgrade_diff.md https://github.com/kubernetes/website/issues/18411	2020-01-13 00:53:37 -08:00
Zhang Yong	150958c231	update zh-trans kubeadm_upgrade_plan.md (#18647 )	2020-01-13 00:51:37 -08:00
YangQizhou	102fc59c2e	update zh ingress.md (#18417 ) * update zh ingress.md * content/zh/docs/concepts/services-networking/ingress.md update zh ingress.md content/zh/docs/concepts/services-networking/ingress.md Revert "update zh-translation content/zh/docs/reference/_index.md (#18300)" This reverts commit `58474188b0`. content/zh/docs/concepts/services-networking/ingress.md reset api update content/zh/docs/concepts/services-networking/ingress.md * update content/zh/docs/reference/_index.md	2020-01-13 00:49:38 -08:00
Zhang Yong	8fd4be60d9	update zh-trans kubeadm_upgrade_node_phase.md,kubeadm_upgrade_node_phase_kubelet-config.md (#18646 )	2020-01-13 00:47:37 -08:00
ares	919d8b8a7c	zh-trans content/en/blog/_post/2019-10-03-2019-Steering-Committee-Election-Results.md (#18525 )	2020-01-12 23:11:37 -08:00
helight	4d99da5610	Zh translation: /docs/concepts/storage/volume-snapshots.md (#18568 ) * update * zh-trans: /docs/concepts/storage/volume-snapshots.md	2020-01-12 23:07:38 -08:00
ares	a52621b3fe	zh-trans:blog/_posts/2019-11-05-kubernetes-with-microk8s.md (#18586 )	2020-01-12 22:49:37 -08:00
yuxiaobo96	9956cdf28f	update /zh/docs/concepts/scheduling/kube-scheduler.md (#18596 ) Signed-off-by: yuxiaobo <yuxiaobogo@163.com>	2020-01-12 19:43:37 -08:00
Jie Shen	76721b3a8c	Fix typo in zh/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md (#18620 )	2020-01-12 19:41:36 -08:00
cwocwo	aaf50d0a27	fix 86~90 in issue #18411 (#18602 )	2020-01-12 19:39:36 -08:00
Rudy Steiner	10800f7eaa	update zh cpu-management-policies.md (#18638 )	2020-01-12 19:37:36 -08:00
Jie Shen	ab9aa064b8	Fix backticks in zh automated-tasks-with-cron-jobs.md (#18633 )	2020-01-12 19:01:37 -08:00
zhouya0	0c57f2c46b	add kubectl diff to cheatsheet (#18481 )	2020-01-12 17:53:37 -08:00
ThoTischner	7fc323d451	Explain how a config map could be updated immediately in a pod. (#18082 )	2020-01-12 08:33:37 -08:00
Manuel Rüger	f3cde84ea7	kubectl-plugin example: Double-quote to prevent word splitting (#18081 ) See: https://www.shellcheck.net/wiki/SC2086 Signed-off-by: Manuel Rüger <manuel@rueg.eu>	2020-01-12 08:31:37 -08:00
tom1299	93eae7bf31	Improve wording of “Connecting Applications with Services” (#18076 ) * Exchanged developers with containers The meaning of original sentence: "Coordinating ports across multiple developers is very difficult to do at scale..." is not really obvious. From what I understand from the context of this page, the term containers would make more sense, because the context in this paragraph is on containers and ports rather than developers. * Clarify terms developer and container Rephrased statement on port coordination to make it claerer that the ports are part of the containers provided by developers or teams. * Update content/en/docs/concepts/services-networking/connect-applications-service.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com>	2020-01-12 08:23:37 -08:00
Jonathan McCall	ed95607ae6	Be more explicit about what kind of probe (#17943 ) My guess is that this refers to a TCP probe as opposed to the HTTP probe referred to above.	2020-01-12 08:21:37 -08:00
Slava Semushin	093245229b	ru/docs/tutorials/hello-minikube.md: minor improvements (#18611 ) * content/ru/docs/tutorials/hello-minikube.md: minor improvements. * Update Hello Minikube tutorial to use Metrics Service and not Heapster Co-authored-by: Ben Hall <ben@benhall.me.uk> Co-authored-by: Ben Hall <Ben@Benhall.me.uk>	2020-01-12 03:59:37 -08:00
Slava Semushin	526a6263f4	ru/examples/minikube/Dockerfile: modify CMD to use exec form (#18621 ) Replicate https://github.com/kubernetes/website/pull/18618	2020-01-12 03:57:37 -08:00
vyask	ee2960eac9	Update kops.md (#17278 ) kops uses DNS for discovery, both inside the cluster and outside so that you can reach the kubernetes API server from clients.	2020-01-11 10:39:36 -08:00
Slava Semushin	55ee59477e	en/examples/minikube/Dockerfile: modify CMD to use exec form. (#18618 ) Quote from https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#cmd: % CMD should almost always be used in the form of CMD ["executable", "param1", "param2"…] % This is because shell form doesn't pass the signal to an executable and it leads a longer shutdown time as Docker has to kill a process after some timeout. See for details: https://docs.docker.com/engine/reference/builder/#shell-form-entrypoint-example An example on official NodeJS site is also uses that form: https://nodejs.org/de/docs/guides/nodejs-docker-webapp/#creating-a-dockerfile	2020-01-11 10:23:37 -08:00
Jan Wozniak	78dad3ceb6	Fix CoreDNS requirement for ExternalName Service (#18566 )	2020-01-11 10:19:37 -08:00
Wojciech Sciesinski	03f9dd3dfd	An indentation corrected (#18530 )	2020-01-11 09:25:36 -08:00
Tim Bannister	d02332cb4f	id translation for project slogan (#18264 )	2020-01-11 09:11:37 -08:00
Slava Semushin	bfc7a485a3	content/ru/docs/reference/_index.md: sync and improve wording. (#18614 )	2020-01-11 01:59:37 -08:00
Slava Semushin	f9d951a8be	content/ru/docs/_index.md: minor improvements. (#18610 ) - fix typos - improve wording	2020-01-11 01:51:36 -08:00
Salavat	b094709c98	ru hello-minikube.md spelling mistake fix (#18603 ) "plus" was written as "плюч" - that is incorrect.	2020-01-11 01:39:36 -08:00
Eric Covener	b78d6dceb4	axe two stray words in service.md (#18160 ) changes for #14526 had either a stray "for a" or missed "service" as in "for a service". Since it's quite lengthy and "for a service" is unnecessary in service.md, I opted to removed it.	2020-01-10 15:17:37 -08:00
Javier Revillas	46033f8f0d	Fix typo in install-kubeadm.md (#18170 )	2020-01-10 15:15:38 -08:00
chendotjs	0c2a5ceb0b	Remove useless blank line (#18211 )	2020-01-10 14:25:37 -08:00
Anshu Prateek	6e94490186	Make wordpress snippet copy/pastable (#18240 ) Remove leading space to make it copy pastable.	2020-01-10 14:17:37 -08:00
Jesang Myung	02f0a2af86	fixed minor typo (#18247 )	2020-01-10 13:55:42 -08:00
Tim Bannister	93369effa8	Tidy Markdown & correct syntax (#18335 ) Use correct formatting for code blocks.	2020-01-10 13:21:38 -08:00
Tim Bannister	e86f038b11	Remove version checks for Job and CronJob task pages (#18337 ) * Specify minimum Kubernetes version for Job tasks Ask for v1.8 because CronJob went beta in v1.8 and some of the Job pages reference CronJob. * Drop version check from Job / CronJob task pages. Assume that readers have Kubernetes v1.8 or newer.	2020-01-10 12:52:40 -08:00
Tim Bannister	27ec99ffbb	Use built-in version check & metadata (#18338 )	2020-01-10 11:30:36 -08:00
Tim Bannister	c9825de1a2	Fix link to Minikube (#18341 )	2020-01-10 11:20:35 -08:00
huccshen	cdfc5d9c13	fix some 404 urls (#18348 )	2020-01-10 10:54:35 -08:00
Lubomir I. Ivanov	e5c3b8819e	kubeadm-join.md: correct alpha->beta wording (#18366 ) The kubeadm API has been beta for a while.	2020-01-10 10:44:36 -08:00
Afrizal Fikri	e19c758d6a	Adding Bahasa Indonesia translation for Deployment page (#17815 ) * Translate Use Case, Creating a Deployment * Translate deployment * Finish deployment updates, continue on deployment status * Finish scaling and deploy status * Finish rollback, clean up, canary * Finish specification, tyding up * Translate remaining typographs	2020-01-10 03:48:34 -08:00
Jie Shen	a1c4d04960	Fix markdown syntax issue for zh kubeadm high availability.md (#18592 )	2020-01-10 01:52:35 -08:00
Bob Killen	9caaac388b	Add blog image OWNERS (#18571 )	2020-01-10 01:00:35 -08:00
Poule Dodue	0d0ebae779	Add CCM Hetzner (#16766 )	2020-01-10 00:58:34 -08:00
ares	b342d7463a	fix error urls (#18047 )	2020-01-10 00:54:34 -08:00
Martin Helmich	035574273b	Link to current API reference on german translation (#18590 )	2020-01-10 00:38:34 -08:00
ares	d4f4f76fc6	zh-trans content/en/blog/_posts/2019-11-26-cloud-native-java-controller-sdk.md (#18526 )	2020-01-09 23:48:34 -08:00
Jie Shen	b66474dfb0	Fix broken link for zh/contribute/localization.md (#18584 )	2020-01-09 18:36:34 -08:00
xieyanker	3fd6285b2e	Fix incorrect Chinese brackets in Markdown hyperlinks (#18562 ) * Fix incorrect Chinese brackets in Markdown hyperlinks * remove spaces	2020-01-09 17:28:34 -08:00
Gerasimos Dimitriadis	29ec822d25	Fix typo in quantity suffix (#18578 )	2020-01-09 16:28:35 -08:00
Cat Yao	9700ac2586	Added Azure Application Gateway Ingress Controller (#17832 ) * Added Azure Application Gateway Ingress Controller Added Azure AppGW Ingress Controller (AGIC) to the list of additional controllers now that it has gone GA. * Update content/en/docs/concepts/services-networking/ingress-controllers.md Co-Authored-By: Tim Bannister <tim@scalefactory.com> Co-authored-by: Tim Bannister <tim@scalefactory.com>	2020-01-09 14:06:35 -08:00
Alexey Pyltsyn	f6dff1f944	ru: fix typos for templates/concept (#18576 )	2020-01-09 11:54:35 -08:00
Alexey Pyltsyn	6b60936999	Improve Russian translation of What is Kubernetes (#17847 )	2020-01-09 11:20:35 -08:00