diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES
index 2c90bb82a4..c31b04d5b0 100644
--- a/OWNERS_ALIASES
+++ b/OWNERS_ALIASES
@@ -176,14 +176,20 @@ aliases:
# zhangxiaoyu-zidif
sig-docs-pt-owners: # Admins for Portuguese content
- femrtnz
+ - jailton
- jcjesus
- devlware
- jhonmike
+ - rikatz
+ - yagonobre
sig-docs-pt-reviews: # PR reviews for Portugese content
- femrtnz
+ - jailton
- jcjesus
- devlware
- jhonmike
+ - rikatz
+ - yagonobre
sig-docs-vi-owners: # Admins for Vietnamese content
- huynguyennovem
- ngtuna
diff --git a/config.toml b/config.toml
index d77c315331..04329284d8 100644
--- a/config.toml
+++ b/config.toml
@@ -91,7 +91,7 @@ blog = "/:section/:year/:month/:day/:slug/"
[outputs]
home = [ "HTML", "RSS", "HEADERS" ]
page = [ "HTML"]
-section = [ "HTML"]
+section = [ "HTML", "print" ]
# Add a "text/netlify" media type for auto-generating the _headers file
[mediaTypes]
diff --git a/content/en/blog/_posts/2018-08-03-make-kubernetes-production-grade-anywhere.md b/content/en/blog/_posts/2018-08-03-make-kubernetes-production-grade-anywhere.md
index 024506a2de..a28196d568 100644
--- a/content/en/blog/_posts/2018-08-03-make-kubernetes-production-grade-anywhere.md
+++ b/content/en/blog/_posts/2018-08-03-make-kubernetes-production-grade-anywhere.md
@@ -176,7 +176,7 @@ Cluster-distributed stateful services (e.g., Cassandra) can benefit from splitti
[Logs](/docs/concepts/cluster-administration/logging/) and [metrics](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) (if collected and persistently retained) are valuable to diagnose outages, but given the variety of technologies available it will not be addressed in this blog. If Internet connectivity is available, it may be desirable to retain logs and metrics externally at a central location.
-Your production deployment should utilize an automated installation, configuration and update tool (e.g., [Ansible](https://github.com/kubernetes-incubator/kubespray), [BOSH](https://github.com/cloudfoundry-incubator/kubo-deployment), [Chef](https://github.com/chef-cookbooks/kubernetes), [Juju](/docs/getting-started-guides/ubuntu/installation/), [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), [Puppet](https://forge.puppet.com/puppetlabs/kubernetes), etc.). A manual process will have repeatability issues, be labor intensive, error prone, and difficult to scale. [Certified distributions](https://www.cncf.io/certification/software-conformance/#logos) are likely to include a facility for retaining configuration settings across updates, but if you implement your own install and config toolchain, then retention, backup and recovery of the configuration artifacts is essential. Consider keeping your deployment components and settings under a version control system such as Git.
+Your production deployment should utilize an automated installation, configuration and update tool (e.g., [Ansible](https://github.com/kubernetes-incubator/kubespray), [BOSH](https://github.com/cloudfoundry-incubator/kubo-deployment), [Chef](https://github.com/chef-cookbooks/kubernetes), [Juju](/docs/getting-started-guides/ubuntu/installation/), [kubeadm](/docs/reference/setup-tools/kubeadm/), [Puppet](https://forge.puppet.com/puppetlabs/kubernetes), etc.). A manual process will have repeatability issues, be labor intensive, error prone, and difficult to scale. [Certified distributions](https://www.cncf.io/certification/software-conformance/#logos) are likely to include a facility for retaining configuration settings across updates, but if you implement your own install and config toolchain, then retention, backup and recovery of the configuration artifacts is essential. Consider keeping your deployment components and settings under a version control system such as Git.
## Outage recovery
diff --git a/content/en/blog/_posts/2018-12-03-kubernetes-1-13-release-announcement.md b/content/en/blog/_posts/2018-12-03-kubernetes-1-13-release-announcement.md
index 247bfa2c8d..8aba0dc232 100644
--- a/content/en/blog/_posts/2018-12-03-kubernetes-1-13-release-announcement.md
+++ b/content/en/blog/_posts/2018-12-03-kubernetes-1-13-release-announcement.md
@@ -17,7 +17,7 @@ Let’s dive into the key features of this release:
## Simplified Kubernetes Cluster Management with kubeadm in GA
-Most people who have gotten hands-on with Kubernetes have at some point been hands-on with kubeadm. It's an essential tool for managing the cluster lifecycle, from creation to configuration to upgrade; and now kubeadm is officially GA. [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) handles the bootstrapping of production clusters on existing hardware and configuring the core Kubernetes components in a best-practice-manner to providing a secure yet easy joining flow for new nodes and supporting easy upgrades. What’s notable about this GA release are the now graduated advanced features, specifically around pluggability and configurability. The scope of kubeadm is to be a toolbox for both admins and automated, higher-level system and this release is a significant step in that direction.
+Most people who have gotten hands-on with Kubernetes have at some point been hands-on with kubeadm. It's an essential tool for managing the cluster lifecycle, from creation to configuration to upgrade; and now kubeadm is officially GA. [kubeadm](/docs/reference/setup-tools/kubeadm/) handles the bootstrapping of production clusters on existing hardware and configuring the core Kubernetes components in a best-practice-manner to providing a secure yet easy joining flow for new nodes and supporting easy upgrades. What’s notable about this GA release are the now graduated advanced features, specifically around pluggability and configurability. The scope of kubeadm is to be a toolbox for both admins and automated, higher-level system and this release is a significant step in that direction.
## Container Storage Interface (CSI) Goes GA
diff --git a/content/en/blog/_posts/2021-03-09-The-Evolution-of-Kubernetes-Dashboard/along-the-way-ui.png b/content/en/blog/_posts/2021-03-09-The-Evolution-of-Kubernetes-Dashboard/along-the-way-ui.png
new file mode 100644
index 0000000000..e83656a624
Binary files /dev/null and b/content/en/blog/_posts/2021-03-09-The-Evolution-of-Kubernetes-Dashboard/along-the-way-ui.png differ
diff --git a/content/en/blog/_posts/2021-03-09-The-Evolution-of-Kubernetes-Dashboard/current-ui.png b/content/en/blog/_posts/2021-03-09-The-Evolution-of-Kubernetes-Dashboard/current-ui.png
new file mode 100644
index 0000000000..7d96058165
Binary files /dev/null and b/content/en/blog/_posts/2021-03-09-The-Evolution-of-Kubernetes-Dashboard/current-ui.png differ
diff --git a/content/en/blog/_posts/2021-03-09-The-Evolution-of-Kubernetes-Dashboard/first-ui.png b/content/en/blog/_posts/2021-03-09-The-Evolution-of-Kubernetes-Dashboard/first-ui.png
new file mode 100644
index 0000000000..ba7fec5408
Binary files /dev/null and b/content/en/blog/_posts/2021-03-09-The-Evolution-of-Kubernetes-Dashboard/first-ui.png differ
diff --git a/content/en/blog/_posts/2021-03-09-The-Evolution-of-Kubernetes-Dashboard/index.md b/content/en/blog/_posts/2021-03-09-The-Evolution-of-Kubernetes-Dashboard/index.md
new file mode 100644
index 0000000000..345394f809
--- /dev/null
+++ b/content/en/blog/_posts/2021-03-09-The-Evolution-of-Kubernetes-Dashboard/index.md
@@ -0,0 +1,63 @@
+---
+layout: blog
+title: "The Evolution of Kubernetes Dashboard"
+date: 2021-03-09
+slug: the-evolution-of-kubernetes-dashboard
+---
+
+Authors: Marcin Maciaszczyk, Kubermatic & Sebastian Florek, Kubermatic
+
+In October 2020, the Kubernetes Dashboard officially turned five. As main project maintainers, we can barely believe that so much time has passed since our very first commits to the project. However, looking back with a bit of nostalgia, we realize that quite a lot has happened since then. Now it’s due time to celebrate “our baby” with a short recap.
+
+## How It All Began
+
+The initial idea behind the Kubernetes Dashboard project was to provide a web interface for Kubernetes. We wanted to reflect the kubectl functionality through an intuitive web UI. The main benefit from using the UI is to be able to quickly see things that do not work as expected (monitoring and troubleshooting). Also, the Kubernetes Dashboard is a great starting point for users that are new to the Kubernetes ecosystem.
+
+The very [first commit](https://github.com/kubernetes/dashboard/commit/5861187fa807ac1cc2d9b2ac786afeced065076c) to the Kubernetes Dashboard was made by Filip Grządkowski from Google on 16th October 2015 – just a few months from the initial commit to the Kubernetes repository. Our initial commits go back to November 2015 ([Sebastian committed on 16 November 2015](https://github.com/kubernetes/dashboard/commit/09e65b6bb08c49b926253de3621a73da05e400fd); [Marcin committed on 23 November 2015](https://github.com/kubernetes/dashboard/commit/1da4b1c25ef040818072c734f71333f9b4733f55)). Since that time, we’ve become regular contributors to the project. For the next two years, we worked closely with the Googlers, eventually becoming main project maintainers ourselves.
+
+{{< figure src="first-ui.png" caption="The First Version of the User Interface" >}}
+
+{{< figure src="along-the-way-ui.png" caption="Prototype of the New User Interface" >}}
+
+{{< figure src="current-ui.png" caption="The Current User Interface" >}}
+
+As you can see, the initial look and feel of the project were completely different from the current one. We have changed the design multiple times. The same has happened with the code itself.
+
+## Growing Up - The Big Migration
+
+At [the beginning of 2018](https://github.com/kubernetes/dashboard/pull/2727), we reached a point where AngularJS was getting closer to the end of its life, while the new Angular versions were published quite often. A lot of the libraries and the modules that we were using were following the trend. That forced us to spend a lot of the time rewriting the frontend part of the project to make it work with newer technologies.
+
+The migration came with many benefits like being able to refactor a lot of the code, introduce design patterns, reduce code complexity, and benefit from the new modules. However, you can imagine that the scale of the migration was huge. Luckily, there were a number of contributions from the community helping us with the resource support, new Kubernetes version support, i18n, and much more. After many long days and nights, we finally released the [first beta version](https://github.com/kubernetes/dashboard/releases/tag/v2.0.0-beta1) in July 2019, followed by the [2.0 release](https://github.com/kubernetes/dashboard/releases/tag/v2.0.0) in April 2020 — our baby had grown up.
+
+## Where Are We Standing in 2021?
+
+Due to limited resources, unfortunately, we were not able to offer extensive support for many different Kubernetes versions. So, we’ve decided to always try and support the latest Kubernetes version available at the time of the Kubernetes Dashboard release. The latest release, [Dashboard v2.2.0](https://github.com/kubernetes/dashboard/releases/tag/v2.2.0) provides support for Kubernetes v1.20.
+
+On top of that, we put in a great deal of effort into [improving resource support](https://github.com/kubernetes/dashboard/issues/5232). Meanwhile, we do offer support for most of the Kubernetes resources. Also, the Kubernetes Dashboard supports multiple languages: English, German, French, Japanese, Korean, Chinese (Traditional, Simplified, Traditional Hong Kong). Persian and Russian localizations are currently in progress. Moreover, we are working on the support for 3rd party themes and the design of the app in general. As you can see, quite a lot of things are going on.
+
+Luckily, we do have regular contributors with domain knowledge who are taking care of the project, updating the Helm charts, translations, Go modules, and more. But as always, there could be many more hands on deck. So if you are thinking about contributing to Kubernetes, keep us in mind ;)
+
+## What’s Next
+
+The Kubernetes Dashboard has been growing and prospering for more than 5 years now. It provides the community with an intuitive Web UI, thereby decreasing the complexity of Kubernetes and increasing its accessibility to new community members. We are proud of what the project has achieved so far, but this is by far not the end. These are our priorities for the future:
+
+* Keep providing support for the new Kubernetes versions
+* Keep improving the support for the existing resources
+* Keep working on auth system improvements
+* [Rewrite the API to use gRPC and shared informers](https://github.com/kubernetes/dashboard/pull/5449): This will allow us to improve the performance of the application but, most importantly, to support live updates coming from the Kubernetes project. It is one of the most requested features from the community.
+* Split the application into two containers, one with the UI and the second with the API running inside.
+
+## The Kubernetes Dashboard in Numbers
+
+* Initial commit made on October 16, 2015
+* Over 100 million pulls from Dockerhub since the v2 release
+* 8 supported languages and the next 2 in progress
+* Over 3360 closed PRs
+* Over 2260 closed issues
+* 100% coverage of the supported core Kubernetes resources
+* Over 9000 stars on GitHub
+* Over 237 000 lines of code
+
+## Join Us
+
+As mentioned earlier, we are currently looking for more people to help us further develop and grow the project. We are open to contributions in multiple areas, i.e., [issues with help wanted label](https://github.com/kubernetes/dashboard/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22). Please feel free to reach out via GitHub or the #sig-ui channel in the [Kubernetes Slack](https://slack.k8s.io/).
diff --git a/content/en/docs/concepts/configuration/overview.md b/content/en/docs/concepts/configuration/overview.md
index fce8a0c7a8..25cfb2e7f1 100644
--- a/content/en/docs/concepts/configuration/overview.md
+++ b/content/en/docs/concepts/configuration/overview.md
@@ -81,9 +81,9 @@ The [imagePullPolicy](/docs/concepts/containers/images/#updating-images) and the
- `imagePullPolicy: Always`: every time the kubelet launches a container, the kubelet queries the container image registry to resolve the name to an image digest. If the kubelet has a container image with that exact digest cached locally, the kubelet uses its cached image; otherwise, the kubelet downloads (pulls) the image with the resolved digest, and uses that image to launch the container.
-- `imagePullPolicy` is omitted and either the image tag is `:latest` or it is omitted: `Always` is applied.
+- `imagePullPolicy` is omitted and either the image tag is `:latest` or it is omitted: `imagePullPolicy` is automatically set to `Always`. Note that this will _not_ be updated to `IfNotPresent` if the tag changes value.
-- `imagePullPolicy` is omitted and the image tag is present but not `:latest`: `IfNotPresent` is applied.
+- `imagePullPolicy` is omitted and the image tag is present but not `:latest`: `imagePullPolicy` is automatically set to `IfNotPresent`. Note that this will _not_ be updated to `Always` if the tag is later removed or changed to `:latest`.
- `imagePullPolicy: Never`: the image is assumed to exist locally. No attempt is made to pull the image.
@@ -96,7 +96,7 @@ You should avoid using the `:latest` tag when deploying containers in production
{{< /note >}}
{{< note >}}
-The caching semantics of the underlying image provider make even `imagePullPolicy: Always` efficient. With Docker, for example, if the image already exists, the pull attempt is fast because all image layers are cached and no image download is needed.
+The caching semantics of the underlying image provider make even `imagePullPolicy: Always` efficient, as long as the registry is reliably accessible. With Docker, for example, if the image already exists, the pull attempt is fast because all image layers are cached and no image download is needed.
{{< /note >}}
## Using kubectl
diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md
index 99698668c4..1166d4106a 100644
--- a/content/en/docs/concepts/containers/images.md
+++ b/content/en/docs/concepts/containers/images.md
@@ -49,16 +49,32 @@ Instead, specify a meaningful tag such as `v1.42.0`.
## Updating images
-The default pull policy is `IfNotPresent` which causes the
-{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} to skip
-pulling an image if it already exists. If you would like to always force a pull,
-you can do one of the following:
+When you first create a {{< glossary_tooltip text="Deployment" term_id="deployment" >}},
+{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}, Pod, or other
+object that includes a Pod template, then by default the pull policy of all
+containers in that pod will be set to `IfNotPresent` if it is not explicitly
+specified. This policy causes the
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} to skip pulling an
+image if it already exists.
+
+If you would like to always force a pull, you can do one of the following:
- set the `imagePullPolicy` of the container to `Always`.
-- omit the `imagePullPolicy` and use `:latest` as the tag for the image to use.
+- omit the `imagePullPolicy` and use `:latest` as the tag for the image to use;
+ Kubernetes will set the policy to `Always`.
- omit the `imagePullPolicy` and the tag for the image to use.
- enable the [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) admission controller.
+{{< note >}}
+The value of `imagePullPolicy` of the container is always set when the object is
+first _created_, and is not updated if the image's tag later changes.
+
+For example, if you create a Deployment with an image whose tag is _not_
+`:latest`, and later update that Deployment's image to a `:latest` tag, the
+`imagePullPolicy` field will _not_ change to `Always`. You must manually change
+the pull policy of any object after its initial creation.
+{{< /note >}}
+
When `imagePullPolicy` is defined without a specific value, it is also set to `Always`.
## Multi-architecture images with image indexes
diff --git a/content/en/docs/concepts/extend-kubernetes/operator.md b/content/en/docs/concepts/extend-kubernetes/operator.md
index 64b9ed3eb8..323200ec3a 100644
--- a/content/en/docs/concepts/extend-kubernetes/operator.md
+++ b/content/en/docs/concepts/extend-kubernetes/operator.md
@@ -103,26 +103,27 @@ as well as keeping the existing service in good shape.
## Writing your own Operator {#writing-operator}
If there isn't an Operator in the ecosystem that implements the behavior you
-want, you can code your own. In [What's next](#what-s-next) you'll find a few
-links to libraries and tools you can use to write your own cloud native
-Operator.
+want, you can code your own.
You also implement an Operator (that is, a Controller) using any language / runtime
that can act as a [client for the Kubernetes API](/docs/reference/using-api/client-libraries/).
+Following are a few libraries and tools you can use to write your own cloud native
+Operator.
+{{% thirdparty-content %}}
+
+* [kubebuilder](https://book.kubebuilder.io/)
+* [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)
+* [Metacontroller](https://metacontroller.app/) along with WebHooks that
+ you implement yourself
+* [Operator Framework](https://operatorframework.io)
## {{% heading "whatsnext" %}}
* Learn more about [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
* Find ready-made operators on [OperatorHub.io](https://operatorhub.io/) to suit your use case
-* Use existing tools to write your own operator, eg:
- * using [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)
- * using [kubebuilder](https://book.kubebuilder.io/)
- * using [Metacontroller](https://metacontroller.app/) along with WebHooks that
- you implement yourself
- * using the [Operator Framework](https://operatorframework.io)
* [Publish](https://operatorhub.io/) your operator for other people to use
* Read [CoreOS' original article](https://web.archive.org/web/20170129131616/https://coreos.com/blog/introducing-operators.html) that introduced the Operator pattern (this is an archived version of the original article).
* Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators
diff --git a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md
index 8b13ed3b45..41c4d0ceca 100644
--- a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md
+++ b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md
@@ -5,7 +5,7 @@ reviewers:
- bsalamat
title: Assigning Pods to Nodes
content_type: concept
-weight: 50
+weight: 20
---
diff --git a/content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md
index a327f1de24..94bfaa1280 100644
--- a/content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md
+++ b/content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md
@@ -5,7 +5,7 @@ reviewers:
- ahg-g
title: Resource Bin Packing for Extended Resources
content_type: concept
-weight: 50
+weight: 30
---
diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md
index 08ef19c068..5500c19412 100644
--- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md
+++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md
@@ -738,7 +738,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
[ServiceTopology](/docs/concepts/services-networking/service-topology/)
for more details.
- `SizeMemoryBackedVolumes`: Enables kubelet support to size memory backed volumes.
- See [volumes](docs/concepts/storage/volumes) for more details.
+ See [volumes](/docs/concepts/storage/volumes) for more details.
- `SetHostnameAsFQDN`: Enable the ability of setting Fully Qualified Domain
Name(FQDN) as the hostname of a pod. See
[Pod's `setHostnameAsFQDN` field](/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field).
diff --git a/content/en/docs/setup/best-practices/certificates.md b/content/en/docs/setup/best-practices/certificates.md
index a065462baf..1648cc4e9e 100644
--- a/content/en/docs/setup/best-practices/certificates.md
+++ b/content/en/docs/setup/best-practices/certificates.md
@@ -9,7 +9,7 @@ weight: 40
Kubernetes requires PKI certificates for authentication over TLS.
-If you install Kubernetes with [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/), the certificates that your cluster requires are automatically generated.
+If you install Kubernetes with [kubeadm](/docs/reference/setup-tools/kubeadm/), the certificates that your cluster requires are automatically generated.
You can also generate your own certificates -- for example, to keep your private keys more secure by not storing them on the API server.
This page explains the certificates that your cluster requires.
@@ -74,7 +74,7 @@ Required certificates:
| kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | |
| front-proxy-client | kubernetes-front-proxy-ca | | client | |
-[1]: any other IP or DNS name you contact your cluster on (as used by [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)
+[1]: any other IP or DNS name you contact your cluster on (as used by [kubeadm](/docs/reference/setup-tools/kubeadm/)
the load balancer stable IP and/or DNS name, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`,
`kubernetes.default.svc.cluster`, `kubernetes.default.svc.cluster.local`)
@@ -100,7 +100,7 @@ For kubeadm users only:
### Certificate paths
-Certificates should be placed in a recommended path (as used by [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)).
+Certificates should be placed in a recommended path (as used by [kubeadm](/docs/reference/setup-tools/kubeadm/)).
Paths should be specified using the given argument regardless of location.
| Default CN | recommended key path | recommended cert path | command | key argument | cert argument |
diff --git a/content/en/docs/setup/best-practices/multiple-zones.md b/content/en/docs/setup/best-practices/multiple-zones.md
index 107ee2d0f7..8f51a3bd06 100644
--- a/content/en/docs/setup/best-practices/multiple-zones.md
+++ b/content/en/docs/setup/best-practices/multiple-zones.md
@@ -59,7 +59,7 @@ When nodes start up, the kubelet on each node automatically adds
{{< glossary_tooltip text="labels" term_id="label" >}} to the Node object
that represents that specific kubelet in the Kubernetes API.
These labels can include
-[zone information](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone).
+[zone information](/docs/reference/labels-annotations-taints/#topologykubernetesiozone).
If your cluster spans multiple zones or regions, you can use node labels
in conjunction with
diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md
index e59b497302..15f3e3a9b6 100644
--- a/content/en/docs/setup/production-environment/container-runtimes.md
+++ b/content/en/docs/setup/production-environment/container-runtimes.md
@@ -63,7 +63,7 @@ configuration, or reinstall it using automation.
### containerd
-This section contains the necessary steps to use `containerd` as CRI runtime.
+This section contains the necessary steps to use containerd as CRI runtime.
Use the following commands to install Containerd on your system:
@@ -92,165 +92,57 @@ sudo sysctl --system
Install containerd:
{{< tabs name="tab-cri-containerd-installation" >}}
-{{% tab name="Ubuntu 16.04" %}}
+{{% tab name="Linux" %}}
-```shell
-# (Install containerd)
-## Set up the repository
-### Install packages to allow apt to use a repository over HTTPS
-sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common
-```
+1. Install the `containerd.io` package from the official Docker repositories. Instructions for setting up the Docker repository for your respective Linux distribution and installing the `containerd.io` package can be found at [Install Docker Engine](https://docs.docker.com/engine/install/#server).
-```shell
-## Add Docker's official GPG key
-curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add -
-```
+2. Configure containerd:
-```shell
-## Add Docker apt repository.
-sudo add-apt-repository \
- "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
- $(lsb_release -cs) \
- stable"
-```
+ ```shell
+ sudo mkdir -p /etc/containerd
+ containerd config default | sudo tee /etc/containerd/config.toml
+ ```
-```shell
-## Install containerd
-sudo apt-get update && sudo apt-get install -y containerd.io
-```
+3. Restart containerd:
-```shell
-# Configure containerd
-sudo mkdir -p /etc/containerd
-containerd config default | sudo tee /etc/containerd/config.toml
-```
+ ```shell
+ sudo systemctl restart containerd
+ ```
-```shell
-# Restart containerd
-sudo systemctl restart containerd
-```
-{{% /tab %}}
-{{% tab name="Ubuntu 18.04/20.04" %}}
-
-```shell
-# (Install containerd)
-sudo apt-get update && sudo apt-get install -y containerd
-```
-
-```shell
-# Configure containerd
-sudo mkdir -p /etc/containerd
-containerd config default | sudo tee /etc/containerd/config.toml
-```
-
-```shell
-# Restart containerd
-sudo systemctl restart containerd
-```
-{{% /tab %}}
-{{% tab name="Debian 9+" %}}
-
-```shell
-# (Install containerd)
-## Set up the repository
-### Install packages to allow apt to use a repository over HTTPS
-sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common
-```
-
-```shell
-## Add Docker's official GPG key
-curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add -
-```
-
-```shell
-## Add Docker apt repository.
-sudo add-apt-repository \
- "deb [arch=amd64] https://download.docker.com/linux/debian \
- $(lsb_release -cs) \
- stable"
-```
-
-```shell
-## Install containerd
-sudo apt-get update && sudo apt-get install -y containerd.io
-```
-
-```shell
-# Set default containerd configuration
-sudo mkdir -p /etc/containerd
-containerd config default | sudo tee /etc/containerd/config.toml
-```
-
-```shell
-# Restart containerd
-sudo systemctl restart containerd
-```
-{{% /tab %}}
-{{% tab name="CentOS/RHEL 7.4+" %}}
-
-```shell
-# (Install containerd)
-## Set up the repository
-### Install required packages
-sudo yum install -y yum-utils device-mapper-persistent-data lvm2
-```
-
-```shell
-## Add docker repository
-sudo yum-config-manager \
- --add-repo \
- https://download.docker.com/linux/centos/docker-ce.repo
-```
-
-```shell
-## Install containerd
-sudo yum update -y && sudo yum install -y containerd.io
-```
-
-```shell
-## Configure containerd
-sudo mkdir -p /etc/containerd
-containerd config default | sudo tee /etc/containerd/config.toml
-```
-
-```shell
-# Restart containerd
-sudo systemctl restart containerd
-```
{{% /tab %}}
{{% tab name="Windows (PowerShell)" %}}
-
Start a Powershell session, set `$Version` to the desired version (ex: `$Version=1.4.3`), and then run the following commands:
-
-```powershell
-# (Install containerd)
-# Download containerd
-curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.gz
-tar.exe xvf .\containerd-windows-amd64.tar.gz
-```
+1. Download containerd:
-```powershell
-# Extract and configure
-Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force
-cd $Env:ProgramFiles\containerd\
-.\containerd.exe config default | Out-File config.toml -Encoding ascii
+ ```powershell
+ curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.gz
+ tar.exe xvf .\containerd-windows-amd64.tar.gz
+ ```
-# Review the configuration. Depending on setup you may want to adjust:
-# - the sandbox_image (Kubernetes pause image)
-# - cni bin_dir and conf_dir locations
-Get-Content config.toml
+2. Extract and configure:
-# (Optional - but highly recommended) Exclude containerd form Windows Defender Scans
-Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe"
-```
+ ```powershell
+ Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force
+ cd $Env:ProgramFiles\containerd\
+ .\containerd.exe config default | Out-File config.toml -Encoding ascii
-```powershell
-# Start containerd
-.\containerd.exe --register-service
-Start-Service containerd
-```
+ # Review the configuration. Depending on setup you may want to adjust:
+ # - the sandbox_image (Kubernetes pause image)
+ # - cni bin_dir and conf_dir locations
+ Get-Content config.toml
+
+ # (Optional - but highly recommended) Exclude containerd from Windows Defender Scans
+ Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe"
+ ```
+
+3. Start containerd:
+
+ ```powershell
+ .\containerd.exe --register-service
+ Start-Service containerd
+ ```
{{% /tab %}}
{{< /tabs >}}
@@ -455,138 +347,38 @@ in sync.
### Docker
-On each of your nodes, install Docker CE.
+1. On each of your nodes, install the Docker for your Linux distribution as per [Install Docker Engine](https://docs.docker.com/engine/install/#server)
-The Kubernetes release notes list which versions of Docker are compatible
-with that version of Kubernetes.
+2. Configure the Docker daemon, in particular to use systemd for the management of the container’s cgroups.
-Use the following commands to install Docker on your system:
+ ```shell
+ sudo mkdir /etc/docker
+ cat <}}
-{{% tab name="Ubuntu 16.04+" %}}
+ {{< note >}}
+ `overlay2` is the preferred storage driver for systems running Linux kernel version 4.0 or higher, or RHEL or CentOS using version 3.10.0-514 and above.
+ {{< /note >}}
-```shell
-# (Install Docker CE)
-## Set up the repository:
-### Install packages to allow apt to use a repository over HTTPS
-sudo apt-get update && sudo apt-get install -y \
- apt-transport-https ca-certificates curl software-properties-common gnupg2
-```
+3. Restart Docker and enable on boot:
-```shell
-# Add Docker's official GPG key:
-curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add -
-```
+ ```shell
+ sudo systemctl enable docker
+ sudo systemctl daemon-reload
+ sudo systemctl restart docker
+ ```
-```shell
-# Add the Docker apt repository:
-sudo add-apt-repository \
- "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
- $(lsb_release -cs) \
- stable"
-```
-
-```shell
-# Install Docker CE
-sudo apt-get update && sudo apt-get install -y \
- containerd.io=1.2.13-2 \
- docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \
- docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs)
-```
-
-```shell
-## Create /etc/docker
-sudo mkdir /etc/docker
-```
-
-```shell
-# Set up the Docker daemon
-cat <}}
-
-If you want the `docker` service to start on boot, run the following command:
-
-```shell
-sudo systemctl enable docker
-```
-
-Refer to the [official Docker installation guides](https://docs.docker.com/engine/installation/)
-for more information.
+{{< note >}}
+For more information refer to
+ - [Configure the Docker daemon](https://docs.docker.com/config/daemon/)
+ - [Control Docker with systemd](https://docs.docker.com/config/daemon/systemd/)
+{{< /note >}}
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
index 6516a18825..a9b37e8167 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
@@ -137,7 +137,7 @@ is not supported by kubeadm.
### More information
-For more information about `kubeadm init` arguments, see the [kubeadm reference guide](/docs/reference/setup-tools/kubeadm/kubeadm/).
+For more information about `kubeadm init` arguments, see the [kubeadm reference guide](/docs/reference/setup-tools/kubeadm/).
To configure `kubeadm init` with a configuration file see [Using kubeadm init with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file).
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
index 3f6e991eac..7d74a862f9 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
@@ -175,16 +175,34 @@ For more information on version skews, see:
{{< tabs name="k8s_install" >}}
{{% tab name="Debian-based distributions" %}}
-```bash
-sudo apt-get update && sudo apt-get install -y apt-transport-https curl
-curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
-cat <
diff --git a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
index 57f867d0db..3998b48501 100644
--- a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
+++ b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
@@ -237,7 +237,7 @@ Overlay (VXLAN) networks on Windows do not support dual-stack networking today.
Windows is only supported as a worker node in the Kubernetes architecture and component matrix. This means that a Kubernetes cluster must always include Linux master nodes, zero or more Linux worker nodes, and zero or more Windows worker nodes.
-#### Compute {compute-limitations}
+#### Compute {#compute-limitations}
##### Resource management and process isolation
@@ -297,7 +297,7 @@ As a result, the following storage functionality is not supported on Windows nod
* NFS based storage/volume support
* Expanding the mounted volume (resizefs)
-#### Networking {networking-limitations}
+#### Networking {#networking-limitations}
Windows Container Networking differs in some important ways from Linux networking. The [Microsoft documentation for Windows Container Networking](https://docs.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture) contains additional details and background.
diff --git a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md
index de9ab8181c..62251eb222 100644
--- a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md
+++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md
@@ -1129,8 +1129,6 @@ resources that have the scale subresource enabled.
### Categories
-{{< feature-state state="beta" for_k8s_version="v1.10" >}}
-
Categories is a list of grouped resources the custom resource belongs to (eg. `all`).
You can use `kubectl get ` to list the resources belonging to the category.
diff --git a/content/en/docs/tasks/tools/install-kubectl-linux.md b/content/en/docs/tasks/tools/install-kubectl-linux.md
index 12a8d641d8..243dbf4e0d 100644
--- a/content/en/docs/tasks/tools/install-kubectl-linux.md
+++ b/content/en/docs/tasks/tools/install-kubectl-linux.md
@@ -100,15 +100,38 @@ For example, to download version {{< param "fullversion" >}} on Linux, type:
### Install using native package management
{{< tabs name="kubectl_install" >}}
-{{< tab name="Ubuntu, Debian or HypriotOS" codelang="bash" >}}
-sudo apt-get update && sudo apt-get install -y apt-transport-https gnupg2 curl
-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="Debian-based distributions" %}}
-{{< tab name="CentOS, RHEL or Fedora" codelang="bash" >}}cat < /etc/yum.repos.d/kubernetes.repo
+1. Update the `apt` package index and install packages needed to use the Kubernetes `apt` repository:
+
+ ```shell
+ sudo apt-get update
+ sudo apt-get install -y apt-transport-https ca-certificates curl
+ ```
+
+2. Download the Google Cloud public signing key:
+
+ ```shell
+ sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
+ ```
+
+3. Add the Kubernetes `apt` repository:
+
+ ```shell
+ echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
+ ```
+
+4. Update `apt` package index with the new repository and install kubectl:
+
+ ```shell
+ sudo apt-get update
+ sudo apt-get install -y kubectl
+ ```
+
+{{% /tab %}}
+
+{{< tab name="Red Hat-based distributions" codelang="bash" >}}
+cat < /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
diff --git a/content/es/docs/concepts/containers/runtime-class.md b/content/es/docs/concepts/containers/runtime-class.md
new file mode 100644
index 0000000000..8c53cde87d
--- /dev/null
+++ b/content/es/docs/concepts/containers/runtime-class.md
@@ -0,0 +1,205 @@
+---
+reviewers:
+title: RuntimeClass
+content_type: concept
+weight: 20
+---
+
+
+
+{{< feature-state for_k8s_version="v1.20" state="stable" >}}
+
+Esta página describe el recurso RuntimeClass y el mecanismo de selección del
+motor de ejecución.
+
+RuntimeClass es una característica que permite seleccionar la configuración del
+motor de ejecución para los contenedores. La configuración del motor de ejecución para
+los contenedores se utiliza para ejecutar los contenedores de un Pod.
+
+
+
+
+
+
+## Motivación
+
+Se puede seleccionar un RuntimeClass diferente entre diferentes Pods para
+proporcionar equilibrio entre rendimiento y seguridad. Por ejemplo, si parte de
+la carga de trabajo requiere un alto nivel de garantía de seguridad, se podrían
+planificar esos Pods para ejecutarse en un motor de ejecución que use
+virtualización de hardware. Así se beneficiaría con un mayor aislamiento del motor
+de ejecución alternativo, con el coste de alguna sobrecarga adicional.
+
+También se puede utilizar el RuntimeClass para ejecutar distintos Pods con el
+mismo motor de ejecución pero con distintos parámetros.
+
+## Configuración
+
+1. Configurar la implementación del CRI en los nodos (depende del motor de
+ ejecución)
+2. Crear los recursos RuntimeClass correspondientes.
+
+### 1. Configurar la implementación del CRI en los nodos
+
+La configuración disponible utilizando RuntimeClass dependen de la
+implementación de la Interfaz del Motor de ejecución de Containers (CRI). Véase
+la sección [Configuración del CRI](#cri-configuration) para más
+información sobre cómo configurar la implementación del CRI.
+
+{{< note >}}
+RuntimeClass por defecto asume una configuración de nodos homogénea para todo el
+clúster (lo que significa que todos los nodos están configurados de la misma
+forma para el motor de ejecución de los contenedores). Para soportar configuraciones
+heterogéneas de nodos, véase [Planificación](#scheduling) más abajo.
+{{< /note >}}
+
+Las configuraciones tienen un nombre de `handler` (manipulador) correspondiente, referenciado
+por la RuntimeClass. El `handler` debe ser una etiqueta DNS 1123 válida
+(alfanumérico + caracter `-`).
+
+### 2. Crear los recursos RuntimeClass correspondientes.
+
+Cada configuración establecida en el paso 1 tiene un nombre de `handler`, que
+identifica a dicha configuración. Para cada `handler`, hay que crear un objeto
+RuntimeClass correspondiente.
+
+Actualmente el recurso RuntimeClass sólo tiene dos campos significativos: el
+nombre del RuntimeClass (`metadata.name`) y el `handler`. La
+definición del objeto se parece a ésta:
+
+```yaml
+apiVersion: node.k8s.io/v1 # La RuntimeClass se define en el grupo node.k8s.io
+kind: RuntimeClass
+metadata:
+ name: myclass # Nombre por el que se referenciará la RuntimeClass
+ # no contiene espacio de nombres
+handler: myconfiguration # El nombre de la configuración CRI correspondiente
+```
+
+El nombre de un objeto RuntimeClass debe ser un [nombre de subdominio
+DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)
+válido.
+
+{{< note >}}
+Se recomienda que las operaciones de escritura de la RuntimeClass
+(creación/modificación/parcheo/elimiación) se restrinjan al administrador del
+clúster. Habitualmente es el valor por defecto. Véase [Visión general de la
+Autorización](/docs/reference/access-authn-authz/authorization/) para más
+detalles.
+{{< /note >}}
+
+## Uso
+
+Una vez se han configurado las RuntimeClasses para el clúster, el utilizarlas es
+muy sencillo. Solo se especifica un `runtimeClassName` en la especificación del Pod.
+Por ejemplo:
+
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ name: mypod
+spec:
+ runtimeClassName: myclass
+ # ...
+```
+
+Así se informa a Kubelet del nombre de la RuntimeClass a utilizar para
+este pod. Si dicha RuntimeClass no existe, o el CRI no puede ejecutar el
+`handler` correspondiente, el pod entrará en la
+[fase](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) final `Failed`.
+Se puede buscar por el correspondiente
+[evento](/docs/tasks/debug-application-cluster/debug-application-introspection/)
+con el mensaje de error.
+
+Si no se especifica ninguna `runtimeClassName`, se usará el RuntimeHandler por
+defecto, lo que equivale al comportamiento cuando la opción RuntimeClass está
+deshabilitada.
+
+### Configuración del CRI
+
+Para más detalles sobre cómo configurar los motores de ejecución del CRI, véase
+[instalación del CRI](/docs/setup/production-environment/container-runtimes/).
+
+#### dockershim
+
+El CRI dockershim incorporado por Kubernetes no soporta manejadores del motor de
+ejecución.
+
+#### {{< glossary_tooltip term_id="containerd" >}}
+
+Los `handlers` del motor de ejecución se configuran mediante la configuración
+de containerd en `/etc/containerd/config.toml`. Los `handlers` válidos se
+configuran en la sección de motores de ejecución:
+
+```
+[plugins.cri.containerd.runtimes.${HANDLER_NAME}]
+```
+
+Véase la configuración de containerd para más detalles:
+https://github.com/containerd/cri/blob/master/docs/config.md
+
+#### {{< glossary_tooltip term_id="cri-o" >}}
+
+Los `handlers` del motor de ejecución se configuran a través de la
+configuración del CRI-O en `/etc/crio/crio.conf`. Los manejadores válidos se
+configuran en la [tabla
+crio.runtime](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table)
+
+```
+[crio.runtime.runtimes.${HANDLER_NAME}]
+ runtime_path = "${PATH_TO_BINARY}"
+```
+
+Véase la [documentación de la
+configuración](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md)
+de CRI-O para más detalles.
+
+## Planificación
+
+{{< feature-state for_k8s_version="v1.16" state="beta" >}}
+
+Especificando el campo `scheduling` en una RuntimeClass se pueden establecer
+restricciones para asegurar que los Pods ejecutándose con dicha RuntimeClass se
+planifican en los nodos que la soportan.
+
+Para asegurar que los pods sean asignados en nodos que soportan una RuntimeClass
+determinada, ese conjunto de nodos debe tener una etiqueta común que se
+selecciona en el campo `runtimeclass.scheduling.nodeSelector`. El nodeSelector
+de la RuntimeClass se combina con el nodeSelector del pod durante la admisión,
+haciéndose efectiva la intersección del conjunto de nodos seleccionados por
+ambos. Si hay conflicto, el pod se rechazará.
+
+Si los nodos soportados se marcan para evitar que los pods con otra RuntimeClass
+se ejecuten en el nodo, se pueden añadir `tolerations` al RuntimeClass. Igual
+que con el `nodeSelector`, las tolerancias se mezclan con las tolerancias del
+pod durante la admisión, haciéndose efectiva la unión del conjunto de nodos
+tolerados por ambos.
+
+Para saber más sobre configurar el selector de nodos y las tolerancias, véase
+[Asignando Pods a Nodos](/docs/concepts/scheduling-eviction/assign-pod-node/).
+
+### Sobrecarga del Pod
+
+{{< feature-state for_k8s_version="v1.18" state="beta" >}}
+
+Se pueden especificar recursos de _sobrecarga_ adicional que se asocian a los
+Pods que estén ejecutándose. Declarar la sobrecarga permite al clúster (incluido
+el planificador) contabilizarlo al tomar decisiones sobre los Pods y los
+recursos. Para utilizar la sobrecarga de pods, se debe haber habilitado la
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+PodOverhead (lo está por defecto).
+
+La sobrecarga de pods se define en la RuntimeClass a través del los campos de
+`overhead`. Con estos campos se puede especificar la sobrecarga de los pods en
+ejecución que utilizan esta RuntimeClass para asegurar que estas sobrecargas se
+cuentan en Kubernetes.
+
+## {{% heading "whatsnext" %}}
+
+
+- [Diseño de RuntimeClass](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
+- [Diseño de programación de RuntimeClass](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
+- Leer sobre el concepto de [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/)
+- [Diseño de capacidad de PodOverhead](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
diff --git a/content/es/docs/concepts/policy/_index.md b/content/es/docs/concepts/policy/_index.md
index 3182c94f7d..d5ebfed4f5 100755
--- a/content/es/docs/concepts/policy/_index.md
+++ b/content/es/docs/concepts/policy/_index.md
@@ -1,4 +1,6 @@
---
-title: "Políticas"
+title: Políticas
weight: 90
----
\ No newline at end of file
+---
+
+La sección de Políticas describe las diferentes políticas configurables que se aplican a grupos de recursos:
diff --git a/content/es/docs/concepts/policy/limit-range.md b/content/es/docs/concepts/policy/limit-range.md
new file mode 100644
index 0000000000..22d4c74f51
--- /dev/null
+++ b/content/es/docs/concepts/policy/limit-range.md
@@ -0,0 +1,70 @@
+---
+reviewers:
+- raelga
+title: Rangos de límites (Limit Ranges)
+description: >
+ Aplica límites de recursos a un Namespace para restringir y garantizar la asignación y consumo de recursos informáticos.
+content_type: concept
+weight: 10
+---
+
+
+
+### Contexto
+
+Por defecto, los contenedores se ejecutan sin restricciones sobre los [recursos informáticos disponibles en un clúster de Kubernetes](/docs/concepts/configuration/manage-resources-containers/).
+Si el {{< glossary_tooltip text="Nodo" term_id="node" >}} dispone de los recursos informáticos, un {{< glossary_tooltip text="Pod" term_id="pod" >}} o sus {{< glossary_tooltip text="Contenedores" term_id="container" >}} tienen permitido consumir por encima de la cuota solicitada si no superan el límite establecido en su especificación.
+Existe la preocupación de que un Pod o Contenedor pueda monopolizar todos los recursos disponibles.
+
+### Utilidad
+
+Aplicando restricciones de asignación de recursos, los administradores de clústeres se aseguran del cumplimiento del consumo de recursos por espacio de nombre ({{< glossary_tooltip text="Namespace" term_id="namespace" >}}).
+
+Un **{{< glossary_tooltip text="LimitRange" term_id="limitrange" >}}** es la política que permite:
+
+- Imponer restricciones de requisitos de recursos a {{< glossary_tooltip text="Pods" term_id="pod" >}} o {{< glossary_tooltip text="Contenedores" term_id="container" >}} por Namespace.
+- Imponer las limitaciones de recursos mínimas/máximas para Pods o Contenedores dentro de un Namespace.
+- Especificar requisitos y límites de recursos predeterminados para Pods o Contenedores de un Namespace.
+- Imponer una relación de proporción entre los requisitos y el límite de un recurso.
+- Imponer el cumplimiento de las demandas de almacenamiento mínimo/máximo para {{< glossary_tooltip text="Solicitudes de Volúmenes Persistentes" term_id="persistent-volume-claim" >}}.
+
+### Habilitar el LimitRange
+
+La compatibilidad con LimitRange está habilitada por defecto en Kubernetes desde la versión 1.10.
+
+Para que un LimitRange se active en un {{< glossary_tooltip text="Namespace" term_id="namespace" >}} en particular, el LimitRange debe definirse con el Namespace, o aplicarse a éste.
+
+El nombre de recurso de un objeto LimitRange debe ser un
+[nombre de subdominio DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido.
+
+### Aplicando LimitRanges
+
+- El administrador crea un LimitRange en un {{< glossary_tooltip text="Namespace" term_id="namespace" >}}.
+- Los usuarios crean recursos como {{< glossary_tooltip text="Pods" term_id="pod" >}}, {{< glossary_tooltip text="Contenedores" term_id="container" >}} o {{< glossary_tooltip text="Solicitudes de Volúmenes Persistentes" term_id="persistent-volume-claim" >}} en el Namespace.
+- El controlador de admisión `LimitRanger` aplicará valores predeterminados y límites, para todos los Pods o Contenedores que no establezcan requisitos de recursos informáticos. Y realizará un seguimiento del uso para garantizar que no excedan el mínimo, el máximo, y la proporción de ningún LimitRange definido en el Namespace.
+- Si al crear o actualizar un recurso del ejemplo (Pods, Contenedores, {{< glossary_tooltip text="Solicitudes de Volúmenes Persistentes" term_id="persistent-volume-claim" >}}) se viola una restricción al LimitRange, la solicitud al servidor API fallará con un código de estado HTTP "403 FORBIDDEN" y un mensaje que explica la restricción que se ha violado.
+- En caso de que en se active un LimitRange para recursos de cómputos como `cpu` y `memory`, los usuarios deberán especificar los requisitos y/o límites de recursos a dichos valores. De lo contrario, el sistema puede rechazar la creación del Pod.
+- Las validaciones de LimitRange ocurren solo en la etapa de Admisión de Pod, no en Pods que ya se han iniciado (Running {{< glossary_tooltip text="Pods" term_id="pod" >}}).
+
+Algunos ejemplos de políticas que se pueden crear utilizando rangos de límites son:
+
+- En un clúster de 2 nodos con una capacidad de 8 GiB de RAM y 16 núcleos, podría restringirse los {{< glossary_tooltip text="Pods" term_id="pod" >}} en un {{< glossary_tooltip text="Namespace" term_id="namespace" >}} a requerir `100m` de CPU con un límite máximo de `500m` para CPU y requerir `200Mi` de memoria con un límite máximo de `600Mi` de memoria.
+- Definir el valor por defecto de límite y requisitos de CPU a `150m` y el valor por defecto de requisito de memoria a `300Mi` {{< glossary_tooltip text="Contenedores" term_id="container" >}} que se iniciaron sin requisitos de CPU y memoria en sus especificaciones.
+
+En el caso de que los límites totales del {{< glossary_tooltip text="Namespace" term_id="namespace" >}} sean menores que la suma de los límites de los {{< glossary_tooltip text="Pods" term_id="pod" >}},
+puede haber contienda por los recursos. En este caso, los contenedores o pods no seran creados.
+
+Ni la contención ni los cambios en un LimitRange afectarán a los recursos ya creados.
+
+## {{% heading "whatsnext" %}}
+
+Consulte el [documento de diseño del LimitRanger](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) para más información.
+
+Los siguientes ejemplos utilizan límites y están pendientes de su traducción:
+
+- [how to configure minimum and maximum CPU constraints per namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/).
+- [how to configure minimum and maximum Memory constraints per namespace](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/).
+- [how to configure default CPU Requests and Limits per namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/).
+- [how to configure default Memory Requests and Limits per namespace](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/).
+- [how to configure minimum and maximum Storage consumption per namespace](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage).
+- [a detailed example on configuring quota per namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/).
diff --git a/content/es/docs/reference/glossary/limitrange.md b/content/es/docs/reference/glossary/limitrange.md
new file mode 100755
index 0000000000..9311ddc557
--- /dev/null
+++ b/content/es/docs/reference/glossary/limitrange.md
@@ -0,0 +1,23 @@
+---
+title: LimitRange
+id: limitrange
+date: 2019-04-15
+full_link: /docs/concepts/policy/limit-range/
+short_description: >
+ Proporciona restricciones para limitar el consumo de recursos por Contenedores o Pods en un espacio de nombres
+
+aka:
+tags:
+ - core-object
+ - fundamental
+ - architecture
+related:
+ - pod
+ - container
+---
+
+Proporciona restricciones para limitar el consumo de recursos por {{< glossary_tooltip text="Contenedores" term_id="container" >}} o {{< glossary_tooltip text="Pods" term_id="pod" >}} en un espacio de nombres ({{< glossary_tooltip text="Namespace" term_id="namespace" >}})
+
+
+
+LimitRange limita la cantidad de objetos que se pueden crear por su tipo (vease {{< glossary_tooltip text="Workloads" term_id="workload" >}}), así como la cantidad de recursos informáticos que pueden ser requeridos/consumidos por {{< glossary_tooltip text="Pods" term_id="pod" >}} individuales en un espacio de nombres.
diff --git a/content/ja/docs/concepts/cluster-administration/manage-deployment.md b/content/ja/docs/concepts/cluster-administration/manage-deployment.md
index 90f96547d5..cb9c7c0fc3 100644
--- a/content/ja/docs/concepts/cluster-administration/manage-deployment.md
+++ b/content/ja/docs/concepts/cluster-administration/manage-deployment.md
@@ -237,7 +237,7 @@ guestbook-redis-slave-qgazl 1/1 Running 0 3m
image: gb-frontend:v3
```
-そして2つの異なるPodのセットを上書きしないようにするため、`track`ラベルに異なる値を持つ(例: `canary`)ようなguestbookフロントエンドの新しいリリースを作成できます。
+そして2つの異なるPodのセットを上書きしないようにするため、`track`ラベルに異なる値を持つ(例: `canary`)ようなguestbookフロントエンドの新しいリリースを作成できます。
```yaml
name: frontend-canary
diff --git a/content/ja/docs/concepts/overview/what-is-kubernetes.md b/content/ja/docs/concepts/overview/what-is-kubernetes.md
index 3ca8fa78fe..dab17c9b1b 100644
--- a/content/ja/docs/concepts/overview/what-is-kubernetes.md
+++ b/content/ja/docs/concepts/overview/what-is-kubernetes.md
@@ -17,7 +17,7 @@ card:
Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームです。Kubernetesは巨大で急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。
-Kubernetesの名称は、ギリシャ語に由来し、操舵手やパイロットを意味しています。Googleは2014年にKubernetesプロジェクトをオープンソース化しました。Kubernetesは、本番環境で大規模なワークロードを稼働させた[Googleの15年以上の経験](/blog/2015/04/borg-predecessor-to-kubernetes/)と、コミュニティからの最高のアイディアや実践を組み合わせています。
+Kubernetesの名称は、ギリシャ語に由来し、操舵手やパイロットを意味しています。Googleは2014年にKubernetesプロジェクトをオープンソース化しました。Kubernetesは、本番環境で大規模なワークロードを稼働させた[Googleの15年以上の経験](/blog/2015/04/borg-predecessor-to-kubernetes/)と、コミュニティからの最高のアイディアや実践を組み合わせています。
## 過去を振り返ってみると
diff --git a/content/ja/docs/concepts/policy/resource-quotas.md b/content/ja/docs/concepts/policy/resource-quotas.md
index e7368a8f94..7b00056fcf 100644
--- a/content/ja/docs/concepts/policy/resource-quotas.md
+++ b/content/ja/docs/concepts/policy/resource-quotas.md
@@ -22,7 +22,7 @@ weight: 10
- 異なる名前空間で異なるチームが存在するとき。現時点ではこれは自主的なものですが、将来的にはACLsを介してリソースクォータの設定を強制するように計画されています。
- 管理者は各名前空間で1つの`ResourceQuota`を作成します。
- ユーザーが名前空間内でリソース(Pod、Serviceなど)を作成し、クォータシステムが`ResourceQuota`によって定義されたハードリソースリミットを超えないことを保証するために、リソースの使用量をトラッキングします。
-- リソースの作成や更新がクォータの制約に違反しているとき、そのリクエストはHTTPステータスコード`403 FORBIDDEN`で失敗し、違反した制約を説明するメッセージが表示されます。
+- リソースの作成や更新がクォータの制約に違反しているとき、そのリクエストはHTTPステータスコード`403 FORBIDDEN`で失敗し、違反した制約を説明するメッセージが表示されます。
- `cpu`や`memory`といったコンピューターリソースに対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を強制するために、`LimitRanger`アドミッションコントローラーを使用してください。この問題を解決する例は[walkthrough](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)で参照できます。
`ResourceQuota`のオブジェクト名は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります.
diff --git a/content/ja/docs/concepts/security/overview.md b/content/ja/docs/concepts/security/overview.md
index b50a4ea1a5..0157b28f78 100644
--- a/content/ja/docs/concepts/security/overview.md
+++ b/content/ja/docs/concepts/security/overview.md
@@ -77,7 +77,7 @@ Kubernetesを保護する為には２つの懸念事項があります。
### クラスター内のコンポーネント(アプリケーション) {#cluster-applications}
-アプリケーションを対象にした攻撃に応じて、セキュリティの特定側面に焦点をあてたい場合があります。例:他のリソースとの連携で重要なサービス(サービスA)と、リソース枯渇攻撃に対して脆弱な別のワークロード(サービスB)が実行されている場合、サービスBのリソースを制限していないとサービスAが危険にさらされるリスクが高くなります。次の表はセキュリティの懸念事項とKubernetesで実行されるワークロードを保護するための推奨事項を示しています。
+アプリケーションを対象にした攻撃に応じて、セキュリティの特定側面に焦点をあてたい場合があります。例:他のリソースとの連携で重要なサービス(サービスA)と、リソース枯渇攻撃に対して脆弱な別のワークロード(サービスB)が実行されている場合、サービスBのリソースを制限していないとサービスAが危険にさらされるリスクが高くなります。次の表はセキュリティの懸念事項とKubernetesで実行されるワークロードを保護するための推奨事項を示しています。
ワークロードセキュリティに関する懸念事項 | 推奨事項 |
diff --git a/content/ja/docs/concepts/workloads/pods/ephemeral-containers.md b/content/ja/docs/concepts/workloads/pods/ephemeral-containers.md
index 0fa45de94b..db69d83fcd 100644
--- a/content/ja/docs/concepts/workloads/pods/ephemeral-containers.md
+++ b/content/ja/docs/concepts/workloads/pods/ephemeral-containers.md
@@ -42,7 +42,7 @@ weight: 80
エフェメラルコンテナを利用する場合には、他のコンテナ内のプロセスにアクセスできるように、[プロセス名前空間の共有](/ja/docs/tasks/configure-pod-container/share-process-namespace/)を有効にすると便利です。
-エフェメラルコンテナを利用してトラブルシューティングを行う例については、[デバッグ用のエフェメラルコンテナを使用してデバッグする](/docs/tasks/debug-application-cluster/debug-running-pod/#debugging-with-ephemeral-debug-container)を参照してください。
+エフェメラルコンテナを利用してトラブルシューティングを行う例については、[デバッグ用のエフェメラルコンテナを使用してデバッグする](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)を参照してください。
## Ephemeral containers API
diff --git a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
index b2ebc16d18..d5f6b72296 100644
--- a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
+++ b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
@@ -31,9 +31,9 @@ card:
## クラスター、ユーザー、コンテキストを設定する
-例として、開発用のクラスターが一つ、実験用のクラスターが一つ、計二つのクラスターが存在する場合を考えます。`development`と呼ばれる開発用のクラスター内では、フロントエンドの開発者は`frontend`というnamespace内で、ストレージの開発者は`storage`というnamespace内で作業をします。`scratch`と呼ばれる実験用のクラスター内では、開発者はデフォルトのnamespaceで作業をするか、状況に応じて追加のnamespaceを作成します。開発用のクラスターは証明書を通しての認証を必要とします。実験用のクラスターはユーザーネームとパスワードを通しての認証を必要とします。
+例として、開発用のクラスターが一つ、実験用のクラスターが一つ、計二つのクラスターが存在する場合を考えます。`development`と呼ばれる開発用のクラスター内では、フロントエンドの開発者は`frontend`というnamespace内で、ストレージの開発者は`storage`というnamespace内で作業をします。`scratch`と呼ばれる実験用のクラスター内では、開発者はデフォルトのnamespaceで作業をするか、状況に応じて追加のnamespaceを作成します。開発用のクラスターは証明書を通しての認証を必要とします。実験用のクラスターはユーザーネームとパスワードを通しての認証を必要とします。
-`config-exercise`というディレクトリを作成してください。`config-exercise`ディレクトリ内に、以下を含む`config-demo`というファイルを作成してください:
+`config-exercise`というディレクトリを作成してください。`config-exercise`ディレクトリ内に、以下を含む`config-demo`というファイルを作成してください:
```shell
apiVersion: v1
@@ -61,7 +61,7 @@ contexts:
設定ファイルには、クラスター、ユーザー、コンテキストの情報が含まれています。上記の`config-demo`設定ファイルには、二つのクラスター、二人のユーザー、三つのコンテキストの情報が含まれています。
-`config-exercise`ディレクトリに移動してください。クラスター情報を設定ファイルに追加するために、以下のコマンドを実行してください:
+`config-exercise`ディレクトリに移動してください。クラスター情報を設定ファイルに追加するために、以下のコマンドを実行してください:
```shell
kubectl config --kubeconfig=config-demo set-cluster development --server=https://1.2.3.4 --certificate-authority=fake-ca-file
@@ -89,7 +89,7 @@ kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=develo
kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratch --namespace=default --user=experimenter
```
-追加した情報を確認するために、`config-demo`ファイルを開いてください。`config-demo`ファイルを開く代わりに、`config view`のコマンドを使うこともできます。
+追加した情報を確認するために、`config-demo`ファイルを開いてください。`config-demo`ファイルを開く代わりに、`config view`のコマンドを使うこともできます。
```shell
kubectl config --kubeconfig=config-demo view
diff --git a/content/ja/docs/tutorials/services/source-ip.md b/content/ja/docs/tutorials/services/source-ip.md
index 05a54152a3..17317bbeae 100644
--- a/content/ja/docs/tutorials/services/source-ip.md
+++ b/content/ja/docs/tutorials/services/source-ip.md
@@ -272,7 +272,7 @@ graph TD;
## `Type=LoadBalancer`を使用したServiceでの送信元IP
-[`Type=LoadBalancer`](/ja/docs/concepts/services-networking/service/#loadbalancer)を使用したServiceに送られたパケットは、デフォルトでは送信元のNATは行われません。`Ready`状態にあるすべてのスケジュール可能なKubernetesのNodeは、ロードバランサーからのトラフィックを受付可能であるためです。そのため、エンドポイントが存在しないノードにパケットが到達した場合、システムはエンドポイントが*存在する*ノードにパケットをプロシキーします。このとき、(前のセクションで説明したように)パケットの送信元IPがノードのIPに置換されます。
+[`Type=LoadBalancer`](/ja/docs/concepts/services-networking/service/#loadbalancer)を使用したServiceに送られたパケットは、デフォルトで送信元のNATが行われます。`Ready`状態にあるすべてのスケジュール可能なKubernetesのNodeは、ロードバランサーからのトラフィックを受付可能であるためです。そのため、エンドポイントが存在しないノードにパケットが到達した場合、システムはエンドポイントが*存在する*ノードにパケットをプロシキーします。このとき、(前のセクションで説明したように)パケットの送信元IPがノードのIPに置換されます。
ロードバランサー経由でsource-ip-appを公開することで、これをテストできます。
diff --git a/content/pt/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md b/content/pt/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md
new file mode 100644
index 0000000000..ada16762a0
--- /dev/null
+++ b/content/pt/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md
@@ -0,0 +1,45 @@
+---
+layout: blog
+title: "Não entre em pânico: Kubernetes e Docker"
+date: 2020-12-02
+slug: dont-panic-kubernetes-and-docker
+---
+
+**Autores / Autoras**: Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas
+
+**Tradução:** João Brito
+
+Kubernetes está [deixando de usar Docker](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation) como seu agente de execução após a versão v1.20.
+
+**Não entre em pânico. Não é tão dramático quanto parece.**
+
+TL;DR Docker como um agente de execução primário está sendo deixado de lado em favor de agentes de execução que utilizam a Interface de Agente de Execução de Containers (Container Runtime Interface "CRI") criada para o Kubernetes. As imagens criadas com o Docker continuarão a funcionar em seu cluster com os agentes atuais, como sempre estiveram.
+
+Se você é um usuário final de Kubernetes, quase nada mudará para você. Isso não significa a morte do Docker, e isso não significa que você não pode, ou não deva, usar ferramentas Docker em desenvolvimento mais. Docker ainda é uma ferramenta útil para a construção de containers, e as imagens resultantes de executar `docker build` ainda rodarão em seu cluster Kubernetes.
+
+Se você está usando um Kubernetes gerenciado como GKE, EKS, ou AKS (que usa como [padrão containerd](https://github.com/Azure/AKS/releases/tag/2020-11-16)) você precisará ter certeza que seus nós estão usando um agente de execução de container suportado antes que o suporte ao Docker seja removido nas versões futuras do Kubernetes. Se você tem mudanças em seus nós, talvez você precise atualizá-los baseado em seu ambiente e necessidades do agente de execução.
+
+Se você está rodando seus próprios clusters, você também precisa fazer mudanças para evitar quebras em seu cluster. Na versão v1.20, você terá o aviso de alerta da perda de suporte ao Docker. Quando o suporte ao agente de execução do Docker for removido em uma versão futura (atualmente planejado para a versão 1.22 no final de 2021) do Kubernetes ele não será mais suportado e você precisará trocar para um dos outros agentes de execução de container compatível, como o containerd ou CRI-O. Mas tenha certeza que esse agente de execução escolhido tenha suporte às configurações do daemon do Docker usadas atualmente (Ex.: logs)
+
+## Então porque a confusão e toda essa turma surtando?
+
+Estamos falando aqui de dois ambientes diferentes, e isso está criando essa confusão. Dentro do seu cluster Kubernetes, existe uma coisa chamada de agente de execução de container que é responsável por baixar e executar as imagens de seu container. Docker é a escolha popular para esse agente de execução (outras escolhas comuns incluem containerd e CRI-O), mas Docker não foi projetado para ser embutido no Kubernetes, e isso causa problemas.
+
+Se liga, o que chamamos de "Docker" não é exatamente uma coisa - é uma stack tecnológica inteira, e uma parte disso é chamado de "containerd", que é o agente de execução de container de alto-nível por si só. Docker é legal e útil porque ele possui muitas melhorias de experiência do usuário e isso o torna realmente fácil para humanos interagirem com ele enquanto estão desenvolvendo, mas essas melhorias para o usuário não são necessárias para o Kubernetes, pois ele não é humano.
+
+Como resultado dessa camada de abstração amigável aos humanos, seu cluster Kubernetes precisa usar outra ferramenta chamada Dockershim para ter o que ele realmente precisa, que é o containerd. Isso não é muito bom, porque adiciona outra coisa a ser mantida e que pode quebrar. O que está atualmente acontecendo aqui é que o Dockershim está sendo removido do Kubelet assim que que a versão v1.23 for lançada, que remove o suporte ao Docker como agente de execução de container como resultado. Você deve estar pensando, mas se o containerd está incluso na stack do Docker, porque o Kubernetes precisa do Dockershim?
+
+Docker não é compatível com CRI, a [Container Runtime Interface](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/) (interface do agente de execução de container). Se fosse, nós não precisaríamos do shim, e isso não seria nenhum problema. Mas isso não é o fim do mundo, e você não precisa entrar em pânico - você só precisa mudar seu agente de execução de container do Docker para um outro suportado.
+
+Uma coisa a ser notada: Se você está contando com o socket do Docker (`/var/run/docker.sock`) como parte do seu fluxo de trabalho em seu cluster hoje, mover para um agente de execução diferente acaba com sua habilidade de usá-lo. Esse modelo é conhecido como Docker em Docker. Existem diversas opções por aí para esse caso específico como o [kaniko](https://github.com/GoogleContainerTools/kaniko), [img](https://github.com/genuinetools/img), e [buildah](https://github.com/containers/buildah).
+
+## O que essa mudança representa para os desenvolvedores? Ainda escrevemos Dockerfiles? Ainda vamos fazer build com Docker?
+
+Essa mudança aborda um ambiente diferente do que a maioria das pessoas usa para interagir com Docker. A instalação do Docker que você está usando em desenvolvimento não tem relação com o agente de execução de Docker dentro de seu cluster Kubernetes. É confuso, dá pra entender.
+Como desenvolvedor, Docker ainda é útil para você em todas as formas que era antes dessa mudança ser anunciada. A imagem que o Docker cria não é uma imagem específica para Docker e sim uma imagem que segue o padrão OCI ([Open Container Initiative](https://opencontainers.org/)).
+
+Qualquer imagem compatível com OCI, independente da ferramenta usada para construí-la será vista da mesma forma pelo Kubernetes. Ambos [containerd](https://containerd.io/) e [CRI-O](https://cri-o.io/) sabem como baixar e executá-las. Esse é o porque temos um padrão para containers.
+
+Então, essa mudança está chegando. Isso irá causar problemas para alguns, mas nada catastrófico, no geral é uma boa coisa. Dependendo de como você interage com o Kubernetes, isso tornará as coisas mais fáceis. Se isso ainda é confuso para você, tudo bem, tem muita coisa rolando aqui; Kubernetes tem um monte de partes móveis, e ninguém é 100% especialista nisso. Nós encorajamos toda e qualquer tipo de questão independente do nível de experiência ou de complexidade! Nosso objetivo é ter certeza que todos estão entendendo o máximo possível as mudanças que estão chegando. Esperamos que isso tenha respondido a maioria de suas questões e acalmado algumas ansiedades! ❤️
+
+Procurando mais respostas? Dê uma olhada em nosso apanhado de [questões quanto ao desuso do Dockershim](/blog/2020/12/02/dockershim-faq/).
diff --git a/content/pt/docs/concepts/containers/_index.md b/content/pt/docs/concepts/containers/_index.md
new file mode 100644
index 0000000000..6ce26043c5
--- /dev/null
+++ b/content/pt/docs/concepts/containers/_index.md
@@ -0,0 +1,34 @@
+---
+title: Contêineres
+weight: 40
+description: Tecnologia para empacotar aplicações com suas dependências em tempo de execução
+content_type: concept
+no_list: true
+---
+
+
+
+Cada contêiner executado é repetível; a padronização de ter
+dependências incluídas significa que você obtém o mesmo comportamento onde quer que você execute.
+
+Os contêineres separam os aplicativos da infraestrutura de _host_ subjacente.
+Isso torna a implantação mais fácil em diferentes ambientes de nuvem ou sistema operacional.
+
+
+
+
+## Imagem de contêiner
+Uma [imagem de contêiner](/docs/concepts/containers/images/) é um pacote de software pronto para executar, contendo tudo que é preciso para executar uma aplicação:
+o código e o agente de execução necessário, aplicação, bibliotecas do sistema e valores padrões para qualquer configuração essencial.
+
+Por _design_, um contêiner é imutável: você não pode mudar o código de um contêiner que já está executando. Se você tem uma aplicação conteinerizada e quer fazer mudanças, você precisa construir uma nova imagem que inclui a mudança, e recriar o contêiner para iniciar a partir da imagem atualizada.
+
+## Agente de execução de contêiner
+
+{{< glossary_definition term_id="container-runtime" length="all" >}}
+
+## {{% heading "whatsnext" %}}
+
+* [Imagens de contêineres](/docs/concepts/containers/images/)
+* [Pods](/docs/concepts/workloads/pods/)
+
diff --git a/content/pt/docs/concepts/containers/container-environment.md b/content/pt/docs/concepts/containers/container-environment.md
new file mode 100644
index 0000000000..af28e2dd3f
--- /dev/null
+++ b/content/pt/docs/concepts/containers/container-environment.md
@@ -0,0 +1,56 @@
+---
+title: Ambiente de Contêiner
+content_type: concept
+weight: 20
+---
+
+
+
+Essa página descreve os recursos disponíveis para contêineres no ambiente de contêiner.
+
+
+
+
+
+## Ambiente de contêiner
+
+O ambiente de contêiner do Kubernetes fornece recursos importantes para contêineres:
+
+* Um sistema de arquivos, que é a combinação de uma [imagem](/docs/concepts/containers/images/) e um ou mais [volumes](/docs/concepts/storage/volumes/).
+* Informação sobre o contêiner propriamente.
+* Informação sobre outros objetos no cluster.
+
+### Informação de contêiner
+
+O _hostname_ de um contêiner é o nome do Pod em que o contêiner está executando.
+Isso é disponibilizado através do comando `hostname` ou da função [`gethostname`](https://man7.org/linux/man-pages/man2/gethostname.2.html) chamada na libc.
+
+O nome do Pod e o Namespace são expostos como variáveis de ambiente através de um mecanismo chamado [downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/).
+
+Variáveis de ambiente definidas pelo usuário a partir da definição do Pod também são disponíveis para o contêiner, assim como qualquer variável de ambiente especificada estáticamente na imagem Docker.
+
+### Informação do cluster
+
+Uma lista de todos os serviços que estão executando quando um contêiner foi criado é disponibilizada para o contêiner como variáveis de ambiente.
+Essas variáveis de ambiente são compatíveis com a funcionalidade _docker link_ do Docker.
+
+Para um serviço nomeado *foo* que mapeia para um contêiner nomeado *bar*, as seguintes variáveis são definidas:
+
+```shell
+FOO_SERVICE_HOST=
+FOO_SERVICE_PORT=
+```
+
+Serviços possuem endereço IP dedicado e são disponibilizados para o contêiner via DNS,
+se possuírem [DNS addon](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/) habilitado.
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+* Aprenda mais sobre [hooks de ciclo de vida do contêiner](/docs/concepts/containers/container-lifecycle-hooks/).
+* Obtenha experiência prática
+ [anexando manipuladores a eventos de ciclo de vida do contêiner](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
+
+
diff --git a/content/pt/docs/concepts/containers/images.md b/content/pt/docs/concepts/containers/images.md
new file mode 100644
index 0000000000..6f8b81dd7c
--- /dev/null
+++ b/content/pt/docs/concepts/containers/images.md
@@ -0,0 +1,290 @@
+---
+reviewers:
+- femrtnz
+- jcjesus
+- hugopfeffer
+title: Imagens
+content_type: concept
+weight: 10
+---
+
+
+
+Uma imagem de contêiner representa dados binários que encapsulam uma aplicação e todas as suas dependências de software. As imagens de contêiner são pacotes de software executáveis que podem ser executados de forma autônoma e que fazem suposições muito bem definidas sobre seu agente de execução do ambiente.
+
+Normalmente, você cria uma imagem de contêiner da sua aplicação e a envia para um registro antes de fazer referência a ela em um {{< glossary_tooltip text="Pod" term_id="pod" >}}
+
+Esta página fornece um resumo sobre o conceito de imagem de contêiner.
+
+
+
+## Nomes das imagens
+
+As imagens de contêiner geralmente recebem um nome como `pause`, `exemplo/meuconteiner`, ou `kube-apiserver`.
+As imagens também podem incluir um hostname de algum registro; por exemplo: `exemplo.registro.ficticio/nomeimagem`,
+e um possível número de porta; por exemplo: `exemplo.registro.ficticio:10443/nomeimagem`.
+
+Se você não especificar um hostname de registro, o Kubernetes presumirá que você se refere ao registro público do Docker.
+
+Após a parte do nome da imagem, você pode adicionar uma _tag_ (como também usar com comandos como `docker` e` podman`).
+As tags permitem identificar diferentes versões da mesma série de imagens.
+
+Tags de imagem consistem em letras maiúsculas e minúsculas, dígitos, sublinhados (`_`),
+pontos (`.`) e travessões (` -`).
+Existem regras adicionais sobre onde você pode colocar o separador
+caracteres (`_`,`-` e `.`) dentro de uma tag de imagem.
+Se você não especificar uma tag, o Kubernetes presumirá que você se refere à tag `latest` (mais recente).
+
+{{< caution >}}
+Você deve evitar usar a tag `latest` quando estiver realizando o deploy de contêineres em produção,
+pois é mais difícil rastrear qual versão da imagem está sendo executada, além de tornar mais difícil o processo de reversão para uma versão funcional.
+
+Em vez disso, especifique uma tag significativa, como `v1.42.0`.
+{{< /caution >}}
+
+## Atualizando imagens
+
+A política padrão de pull é `IfNotPresent` a qual faz com que o
+{{}} ignore
+o processo de *pull* da imagem, caso a mesma já exista. Se você prefere sempre forçar o processo de *pull*,
+você pode seguir uma das opções abaixo:
+
+- defina a `imagePullPolicy` do contêiner para` Always`.
+- omita `imagePullPolicy` e use`: latest` como a tag para a imagem a ser usada.
+- omita o `imagePullPolicy` e a tag da imagem a ser usada.
+- habilite o [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) controlador de admissão.
+
+Quando `imagePullPolicy` é definido sem um valor específico, ele também é definido como` Always`.
+
+## Multiarquitetura de imagens com índice de imagens
+
+Além de fornecer o binário das imagens, um registro de contêiner também pode servir um [índice de imagem do contêiner](https://github.com/opencontainers/image-spec/blob/master/image-index.md). Um índice de imagem pode apontar para múltiplos [manifestos da imagem](https://github.com/opencontainers/image-spec/blob/master/manifest.md) para versões específicas de arquitetura de um contêiner. A ideia é que você possa ter um nome para uma imagem (por exemplo: `pause`, `exemple/meuconteiner`, `kube-apiserver`) e permitir que diferentes sistemas busquem o binário da imagem correta para a arquitetura de máquina que estão usando.
+
+O próprio Kubernetes normalmente nomeia as imagens de contêiner com o sufixo `-$(ARCH)`. Para retrocompatibilidade, gere as imagens mais antigas com sufixos. A ideia é gerar a imagem `pause` que tem o manifesto para todas as arquiteturas e `pause-amd64` que é retrocompatível com as configurações anteriores ou arquivos YAML que podem ter codificado as imagens com sufixos.
+
+## Usando um registro privado
+
+Os registros privados podem exigir chaves para acessar as imagens deles.
+As credenciais podem ser fornecidas de várias maneiras:
+ - Configurando nós para autenticação em um registro privado
+ - todos os pods podem ler qualquer registro privado configurado
+ - requer configuração de nó pelo administrador do cluster
+ - Imagens pré-obtidas
+ - todos os pods podem usar qualquer imagem armazenada em cache em um nó
+ - requer acesso root a todos os nós para configurar
+ - Especificando ImagePullSecrets em um Pod
+ - apenas pods que fornecem chaves próprias podem acessar o registro privado
+ - Extensões locais ou específicas do fornecedor
+ - se estiver usando uma configuração de nó personalizado, você (ou seu provedor de nuvem) pode implementar seu mecanismo para autenticar o nó ao registro do contêiner.
+
+Essas opções são explicadas com mais detalhes abaixo.
+
+### Configurando nós para autenticação em um registro privado
+
+Se você executar o Docker em seus nós, poderá configurar o contêiner runtime do Docker
+para autenticação em um registro de contêiner privado.
+
+Essa abordagem é adequada se você puder controlar a configuração do nó.
+
+{{< note >}}
+O Kubernetes padrão é compatível apenas com as seções `auths` e` HttpHeaders` na configuração do Docker.
+Auxiliares de credencial do Docker (`credHelpers` ou` credsStore`) não são suportados.
+{{< /note >}}
+
+Docker armazena chaves de registros privados no arquivo `$HOME/.dockercfg` ou `$HOME/.docker/config.json`. Se você colocar o mesmo arquivo na lista de caminhos de pesquisa abaixo, o kubelet o usa como provedor de credenciais ao obter imagens.
+
+* `{--root-dir:-/var/lib/kubelet}/config.json`
+* `{cwd of kubelet}/config.json`
+* `${HOME}/.docker/config.json`
+* `/.docker/config.json`
+* `{--root-dir:-/var/lib/kubelet}/.dockercfg`
+* `{cwd of kubelet}/.dockercfg`
+* `${HOME}/.dockercfg`
+* `/.dockercfg`
+
+{{< note >}}
+Você talvez tenha que definir `HOME=/root` explicitamente no ambiente do processo kubelet.
+{{< /note >}}
+
+Aqui estão as etapas recomendadas para configurar seus nós para usar um registro privado. Neste
+exemplo, execute-os em seu desktop/laptop:
+
+ 1. Execute `docker login [servidor]` para cada conjunto de credenciais que deseja usar. Isso atualiza o `$HOME/.docker/config.json` em seu PC.
+ 1. Visualize `$HOME/.docker/config.json` em um editor para garantir que contém apenas as credenciais que você deseja usar.
+ 1. Obtenha uma lista de seus nós; por exemplo:
+ - se você quiser os nomes: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )`
+ - se você deseja obter os endereços IP: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )`
+ 1. Copie seu `.docker/config.json` local para uma das listas de caminhos de busca acima.
+ - por exemplo, para testar isso: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done`
+
+{{< note >}}
+Para clusters de produção, use uma ferramenta de gerenciamento de configuração para que você possa aplicar esta
+configuração em todos os nós que você precisar.
+{{< /note >}}
+
+Verifique se está funcionando criando um pod que usa uma imagem privada; por exemplo:
+
+```shell
+kubectl apply -f - <}}
+Essa abordagem é adequada se você puder controlar a configuração do nó. Isto
+não funcionará de forma confiável se o seu provedor de nuvem for responsável pelo gerenciamento de nós e os substituir
+automaticamente.
+{{< /note >}}
+
+Por padrão, o kubelet tenta realizar um "pull" para cada imagem do registro especificado.
+No entanto, se a propriedade `imagePullPolicy` do contêiner for definida como` IfNotPresent` ou `Never`,
+em seguida, uma imagem local é usada (preferencial ou exclusivamente, respectivamente).
+
+Se você quiser usar imagens pré-obtidas como um substituto para a autenticação do registro,
+você deve garantir que todos os nós no cluster tenham as mesmas imagens pré-obtidas.
+
+Isso pode ser usado para pré-carregar certas imagens com o intuíto de aumentar a velocidade ou como uma alternativa para autenticação em um registro privado.
+
+Todos os pods terão permissão de leitura a quaisquer imagens pré-obtidas.
+
+### Especificando imagePullSecrets em um pod
+
+{{< note >}}
+Esta é a abordagem recomendada para executar contêineres com base em imagens
+de registros privados.
+{{< /note >}}
+
+O Kubernetes oferece suporte à especificação de chaves de registro de imagem de contêiner em um pod.
+
+#### Criando um segredo com Docker config
+
+Execute o seguinte comando, substituindo as palavras em maiúsculas com os valores apropriados:
+
+```shell
+kubectl create secret docker-registry --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
+```
+
+Se você já tem um arquivo de credenciais do Docker, em vez de usar o
+comando acima, você pode importar o arquivo de credenciais como um Kubernetes
+{{< glossary_tooltip text="Secrets" term_id="secret" >}}.
+[Criar um segredo com base nas credenciais Docker existentes](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) explica como configurar isso.
+
+Isso é particularmente útil se você estiver usando vários registros privados de contêineres, como `kubectl create secret docker-registry` cria um Segredo que
+só funciona com um único registro privado.
+
+{{< note >}}
+Os pods só podem fazer referência a *pull secrets* de imagem em seu próprio namespace,
+portanto, esse processo precisa ser feito uma vez por namespace.
+{{< /note >}}
+
+#### Referenciando um imagePullSecrets em um pod
+
+Agora, você pode criar pods que fazem referência a esse segredo adicionando uma seção `imagePullSecrets`
+na definição de Pod.
+
+Por exemplo:
+
+```shell
+cat < pod.yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ name: foo
+ namespace: awesomeapps
+spec:
+ containers:
+ - name: foo
+ image: janedoe/awesomeapp:v1
+ imagePullSecrets:
+ - name: myregistrykey
+EOF
+cat <> ./kustomization.yaml
+resources:
+- pod.yaml
+EOF
+```
+
+Isso precisa ser feito para cada pod que está usando um registro privado.
+
+No entanto, a configuração deste campo pode ser automatizada definindo o imagePullSecrets
+em um recurso de [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/).
+
+Verifique [Adicionar ImagePullSecrets a uma conta de serviço](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) para obter instruções detalhadas.
+
+Você pode usar isso em conjunto com um `.docker / config.json` por nó. As credenciais
+serão mescladas.
+
+## Casos de uso
+
+Existem várias soluções para configurar registros privados. Aqui estão alguns
+casos de uso comuns e soluções sugeridas.
+
+1. Cluster executando apenas imagens não proprietárias (por exemplo, código aberto). Não há necessidade de ocultar imagens.
+ - Use imagens públicas no Docker hub.
+ - Nenhuma configuração necessária.
+ - Alguns provedores de nuvem armazenam em cache ou espelham automaticamente imagens públicas, o que melhora a disponibilidade e reduz o tempo para extrair imagens.
+1. Cluster executando algumas imagens proprietárias que devem ser ocultadas para quem está fora da empresa, mas
+ visível para todos os usuários do cluster.
+ - Use um [registro Docker](https://docs.docker.com/registry/) privado hospedado.
+ - Pode ser hospedado no [Docker Hub](https://hub.docker.com/signup) ou em outro lugar.
+ - Configure manualmente .docker/config.json em cada nó conforme descrito acima.
+ - Ou execute um registro privado interno atrás de seu firewall com permissão de leitura.
+ - Nenhuma configuração do Kubernetes é necessária.
+ - Use um serviço de registro de imagem de contêiner que controla o acesso à imagem
+ - Funcionará melhor com o escalonamento automático do cluster do que com a configuração manual de nós.
+ - Ou, em um cluster onde alterar a configuração do nó é inconveniente, use `imagePullSecrets`.
+1. Cluster com imagens proprietárias, algumas das quais requerem controle de acesso mais rígido.
+ - Certifique-se de que o [controlador de admissão AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) está ativo. Caso contrário, todos os pods têm potencialmente acesso a todas as imagens.
+ - Mova dados confidenciais para um recurso "secreto", em vez de empacotá-los em uma imagem.
+1. Um cluster multilocatário em que cada locatário precisa de seu próprio registro privado.
+ - Certifique-se de que o [controlador de admissão AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) está ativo. Caso contrário, todos os Pods de todos os locatários terão potencialmente acesso a todas as imagens.
+ - Execute um registro privado com autorização necessária.
+ - Gere credenciais de registro para cada locatário, coloque em segredo e preencha o segredo para cada namespace de locatário.
+ - O locatário adiciona esse segredo a imagePullSecrets de cada namespace.
+
+
+Se precisar de acesso a vários registros, você pode criar um segredo para cada registro.
+O Kubelet mesclará qualquer `imagePullSecrets` em um único `.docker/config.json` virtual
+
+## {{% heading "whatsnext" %}}
+
+* Leia a [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md)
diff --git a/content/pt/docs/concepts/overview/_index.md b/content/pt/docs/concepts/overview/_index.md
new file mode 100644
index 0000000000..f254849b77
--- /dev/null
+++ b/content/pt/docs/concepts/overview/_index.md
@@ -0,0 +1,7 @@
+---
+title: "Visão Geral"
+weight: 20
+description: Obtenha uma visão em alto-nível do Kubernetes e dos componentes a partir dos quais ele é construído.
+sitemap:
+ priority: 0.9
+---
diff --git a/content/pt/docs/concepts/overview/components.md b/content/pt/docs/concepts/overview/components.md
new file mode 100644
index 0000000000..b03946c4ae
--- /dev/null
+++ b/content/pt/docs/concepts/overview/components.md
@@ -0,0 +1,117 @@
+---
+reviewers:
+title: Componentes do Kubernetes
+content_type: concept
+description: >
+ Um cluster Kubernetes consiste de componentes que representam a camada de gerenciamento, e um conjunto de máquinas chamadas nós.
+weight: 20
+card:
+ name: concepts
+ weight: 20
+---
+
+
+Ao implantar o Kubernetes, você obtém um cluster.
+{{< glossary_definition term_id="cluster" length="all" prepend="Um cluster Kubernetes consiste em">}}
+
+Este documento descreve os vários componentes que você precisa ter para implantar um cluster Kubernetes completo e funcional.
+
+Esse é o diagrama de um cluster Kubernetes com todos os componentes interligados.
+
+
+
+
+
+## Componentes da camada de gerenciamento
+
+Os componentes da camada de gerenciamento tomam decisões globais sobre o cluster (por exemplo, agendamento de _pods_), bem como detectam e respondem aos eventos do cluster (por exemplo, iniciando um novo _{{< glossary_tooltip text="pod" term_id="pod" >}}_ quando o campo `replicas` de um _Deployment_ não está atendido).
+
+Os componentes da camada de gerenciamento podem ser executados em qualquer máquina do cluster. Contudo, para simplificar, os _scripts_ de configuração normalmente iniciam todos os componentes da camada de gerenciamento na mesma máquina, e não executa contêineres de usuário nesta máquina. Veja [Construindo clusters de alta disponibilidade](/docs/admin/high-availability/) para um exemplo de configuração de múltiplas VMs para camada de gerenciamento (_multi-main-VM_).
+
+### kube-apiserver
+
+{{< glossary_definition term_id="kube-apiserver" length="all" >}}
+
+### etcd
+
+{{< glossary_definition term_id="etcd" length="all" >}}
+
+### kube-scheduler
+
+{{< glossary_definition term_id="kube-scheduler" length="all" >}}
+
+### kube-controller-manager
+
+{{< glossary_definition term_id="kube-controller-manager" length="all" >}}
+
+Alguns tipos desses controladores são:
+
+ * Controlador de nó: responsável por perceber e responder quando os nós caem.
+ * Controlador de _Job_: Observa os objetos _Job_ que representam tarefas únicas e, em seguida, cria _pods_ para executar essas tarefas até a conclusão.
+ * Controlador de _endpoints_: preenche o objeto _Endpoints_ (ou seja, junta os Serviços e os _pods_).
+ * Controladores de conta de serviço e de _token_: crie contas padrão e _tokens_ de acesso de API para novos _namespaces_.
+
+### cloud-controller-manager
+
+{{< glossary_definition term_id="cloud-controller-manager" length="short" >}}
+
+O cloud-controller-manager executa apenas controladores que são específicos para seu provedor de nuvem.
+Se você estiver executando o Kubernetes em suas próprias instalações ou em um ambiente de aprendizagem dentro de seu
+próprio PC, o cluster não possui um gerenciador de controlador de nuvem.
+
+Tal como acontece com o kube-controller-manager, o cloud-controller-manager combina vários ciclos de controle logicamente independentes em um binário único que você executa como um processo único. Você pode escalar horizontalmente (exectuar mais de uma cópia) para melhorar o desempenho ou para auxiliar na tolerância a falhas.
+
+Os seguintes controladores podem ter dependências de provedor de nuvem:
+
+ * Controlador de nó: para verificar junto ao provedor de nuvem para determinar se um nó foi excluído da nuvem após parar de responder.
+ * Controlador de rota: para configurar rotas na infraestrutura de nuvem subjacente.
+ * Controlador de serviço: Para criar, atualizar e excluir balanceadores de carga do provedor de nuvem.
+
+## Node Components
+
+Os componentes de nó são executados em todos os nós, mantendo os _pods_ em execução e fornecendo o ambiente de execução do Kubernetes.
+
+### kubelet
+
+{{< glossary_definition term_id="kubelet" length="all" >}}
+
+### kube-proxy
+
+{{< glossary_definition term_id="kube-proxy" length="all" >}}
+
+### Container runtime
+
+{{< glossary_definition term_id="container-runtime" length="all" >}}
+
+## Addons
+
+Complementos (_addons_) usam recursos do Kubernetes ({{< glossary_tooltip term_id="daemonset" >}}, {{< glossary_tooltip term_id="deployment" >}}, etc) para implementar funcionalidades do cluster. Como fornecem funcionalidades em nível do cluster, recursos de _addons_ que necessitem ser criados dentro de um _namespace_ pertencem ao _namespace_ `kube-system`.
+
+Alguns _addons_ selecionados são descritos abaixo; para uma lista estendida dos _addons_ disponíveis, por favor consulte [Addons](/docs/concepts/cluster-administration/addons/).
+
+### DNS
+
+Embora os outros complementos não sejam estritamente necessários, todos os clusters do Kubernetes devem ter um [DNS do cluster](/docs/concepts/services-networking/dns-pod-service/), já que muitos exemplos dependem disso.
+
+O DNS do cluster é um servidor DNS, além de outros servidores DNS em seu ambiente, que fornece registros DNS para serviços do Kubernetes.
+
+Os contêineres iniciados pelo Kubernetes incluem automaticamente esse servidor DNS em suas pesquisas DNS.
+
+### Web UI (Dashboard)
+
+[Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) é uma interface de usuário Web, de uso geral, para clusters do Kubernetes. Ele permite que os usuários gerenciem e solucionem problemas de aplicações em execução no cluster, bem como o próprio cluster.
+
+### Monitoramento de recursos do contêiner
+
+[Monitoramento de recursos do contêiner](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) registra métricas de série temporal genéricas sobre os contêineres em um banco de dados central e fornece uma interface de usuário para navegar por esses dados.
+
+### Logging a nivel do cluster
+
+Um mecanismo de [_logging_ a nível do cluster](/docs/concepts/cluster-administration/logging/) é responsável por guardar os _logs_ dos contêineres em um armazenamento central de _logs_ com um interface para navegação/pesquisa.
+
+## {{% heading "whatsnext" %}}
+
+* Aprenda sobre [Nós](/docs/concepts/architecture/nodes/).
+* Aprenda sobre [Controladores](/docs/concepts/architecture/controller/).
+* Aprenda sobre [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/).
+* Leia a [documentação](https://etcd.io/docs/) oficial do **etcd**.
diff --git a/content/pt/docs/concepts/overview/what-is-kubernetes.md b/content/pt/docs/concepts/overview/what-is-kubernetes.md
new file mode 100644
index 0000000000..29473a7f75
--- /dev/null
+++ b/content/pt/docs/concepts/overview/what-is-kubernetes.md
@@ -0,0 +1,94 @@
+---
+reviewers:
+title: O que é Kubernetes?
+description: >
+ Kubernetes é um plataforma de código aberto, portável e extensiva para o gerenciamento de cargas de trabalho e serviços distribuídos em contêineres, que facilita tanto a configuração declarativa quanto a automação. Ele possui um ecossistema grande, e de rápido crescimento. Serviços, suporte, e ferramentas para Kubernetes estão amplamente disponíveis.
+content_type: concept
+weight: 10
+card:
+ name: concepts
+ weight: 10
+sitemap:
+ priority: 0.9
+---
+
+
+Essa página é uma visão geral do Kubernetes.
+
+
+
+Kubernetes é um plataforma de código aberto, portável e extensiva para o gerenciamento de cargas de trabalho e serviços distribuídos em contêineres, que facilita tanto a configuração declarativa quanto a automação. Ele possui um ecossistema grande, e de rápido crescimento. Serviços, suporte, e ferramentas para Kubernetes estão amplamente disponíveis.
+
+O Google tornou Kubernetes um projeto de código-aberto em 2014. O Kubernetes combina [mais de 15 anos de experiência do Google](/blog/2015/04/borg-predecessor-to-kubernetes/) executando cargas de trabalho produtivas em escala, com as melhores idéias e práticas da comunidade.
+
+O nome **Kubernetes** tem origem no Grego, significando _timoneiro_ ou _piloto_. **K8s** é a abreviação derivada pela troca das oito letras "ubernete" por "8", se tornado _K"8"s_.
+
+## Voltando no tempo
+
+Vamos dar uma olhada no porque o Kubernetes é tão útil, voltando no tempo.
+
+
+
+**Era da implantação tradicional:** No início, as organizações executavam aplicações em servidores físicos. Não havia como definir limites de recursos para aplicações em um mesmo servidor físico, e isso causava problemas de alocação de recursos. Por exemplo, se várias aplicações fossem executadas em um mesmo servidor físico, poderia haver situações em que uma aplicação ocupasse a maior parte dos recursos e, como resultado, o desempenho das outras aplicações seria inferior. Uma solução para isso seria executar cada aplicação em um servidor físico diferente. Mas isso não escalava, pois os recursos eram subutilizados, e se tornava custoso para as organizações manter muitos servidores físicos.
+
+**Era da implantação virtualizada:** Como solução, a virtualização foi introduzida. Esse modelo permite que você execute várias máquinas virtuais (VMs) em uma única CPU de um servidor físico. A virtualização permite que as aplicações sejam isoladas entre as VMs, e ainda fornece um nível de segurança, pois as informações de uma aplicação não podem ser acessadas livremente por outras aplicações.
+
+A virtualização permite melhor utilização de recursos em um servidor físico, e permite melhor escalabilidade porque uma aplicação pode ser adicionada ou atualizada facilmente, reduz os custos de hardware e muito mais. Com a virtualização, você pode apresentar um conjunto de recursos físicos como um cluster de máquinas virtuais descartáveis.
+
+Cada VM é uma máquina completa que executa todos os componentes, incluindo seu próprio sistema operacional, além do hardware virtualizado.
+
+**Era da implantação em contêineres:** Contêineres são semelhantes às VMs, mas têm propriedades de isolamento flexibilizados para compartilhar o sistema operacional (SO) entre as aplicações. Portanto, os contêineres são considerados leves. Semelhante a uma VM, um contêiner tem seu próprio sistema de arquivos, compartilhamento de CPU, memória, espaço de processo e muito mais. Como eles estão separados da infraestrutura subjacente, eles são portáveis entre nuvens e distribuições de sistema operacional.
+
+Contêineres se tornaram populares porque eles fornecem benefícios extra, tais como:
+
+* Criação e implantação ágil de aplicações: aumento da facilidade e eficiência na criação de imagem de contêiner comparado ao uso de imagem de VM.
+* Desenvolvimento, integração e implantação contínuos: fornece capacidade de criação e de implantação de imagens de contêiner de forma confiável e frequente, com a funcionalidade de efetuar reversões rápidas e eficientes (devido à imutabilidade da imagem).
+* Separação de interesses entre Desenvolvimento e Operações: crie imagens de contêineres de aplicações no momento de construção/liberação em vez de no momento de implantação, desacoplando as aplicações da infraestrutura.
+* A capacidade de observação (Observabilidade) não apenas apresenta informações e métricas no nível do sistema operacional, mas também a integridade da aplicação e outros sinais.
+* Consistência ambiental entre desenvolvimento, teste e produção: funciona da mesma forma em um laptop e na nuvem.
+* Portabilidade de distribuição de nuvem e sistema operacional: executa no Ubuntu, RHEL, CoreOS, localmente, nas principais nuvens públicas e em qualquer outro lugar.
+* Gerenciamento centrado em aplicações: eleva o nível de abstração da execução em um sistema operacional em hardware virtualizado à execução de uma aplicação em um sistema operacional usando recursos lógicos.
+* Microserviços fracamente acoplados, distribuídos, elásticos e livres: as aplicações são divididas em partes menores e independentes e podem ser implantados e gerenciados dinamicamente - não uma pilha monolítica em execução em uma grande máquina de propósito único.
+* Isolamento de recursos: desempenho previsível de aplicações.
+* Utilização de recursos: alta eficiência e densidade.
+
+## Por que você precisa do Kubernetes e o que ele pode fazer{#why-you-need-kubernetes-and-what-can-it-do}
+
+Os contêineres são uma boa maneira de agrupar e executar suas aplicações. Em um ambiente de produção, você precisa gerenciar os contêineres que executam as aplicações e garantir que não haja tempo de inatividade. Por exemplo, se um contêiner cair, outro contêiner precisa ser iniciado. Não seria mais fácil se esse comportamento fosse controlado por um sistema?
+
+É assim que o Kubernetes vem ao resgate! O Kubernetes oferece uma estrutura para executar sistemas distribuídos de forma resiliente. Ele cuida do escalonamento e do recuperação à falha de sua aplicação, fornece padrões de implantação e muito mais. Por exemplo, o Kubernetes pode gerenciar facilmente uma implantação no método canário para seu sistema.
+
+O Kubernetes oferece a você:
+
+* **Descoberta de serviço e balanceamento de carga**
+O Kubernetes pode expor um contêiner usando o nome DNS ou seu próprio endereço IP. Se o tráfego para um contêiner for alto, o Kubernetes pode balancear a carga e distribuir o tráfego de rede para que a implantação seja estável.
+* **Orquestração de armazenamento**
+O Kubernetes permite que você monte automaticamente um sistema de armazenamento de sua escolha, como armazenamentos locais, provedores de nuvem pública e muito mais.
+* **Lançamentos e reversões automatizadas**
+Você pode descrever o estado desejado para seus contêineres implantados usando o Kubernetes, e ele pode alterar o estado real para o estado desejado em um ritmo controlada. Por exemplo, você pode automatizar o Kubernetes para criar novos contêineres para sua implantação, remover os contêineres existentes e adotar todos os seus recursos para o novo contêiner.
+* **Empacotamento binário automático**
+Você fornece ao Kubernetes um cluster de nós que pode ser usado para executar tarefas nos contêineres. Você informa ao Kubernetes de quanta CPU e memória (RAM) cada contêiner precisa. O Kubernetes pode encaixar contêineres em seus nós para fazer o melhor uso de seus recursos.
+* **Autocorreção**
+O Kubernetes reinicia os contêineres que falham, substitui os contêineres, elimina os contêineres que não respondem à verificação de integridade definida pelo usuário e não os anuncia aos clientes até que estejam prontos para servir.
+* **Gerenciamento de configuração e de segredos**
+O Kubernetes permite armazenar e gerenciar informações confidenciais, como senhas, tokens OAuth e chaves SSH. Você pode implantar e atualizar segredos e configuração de aplicações sem reconstruir suas imagens de contêiner e sem expor segredos em sua pilha de configuração.
+
+## O que o Kubernetes não é
+
+O Kubernetes não é um sistema PaaS (plataforma como serviço) tradicional e completo. Como o Kubernetes opera no nível do contêiner, e não no nível do hardware, ele fornece alguns recursos geralmente aplicáveis comuns às ofertas de PaaS, como implantação, escalonamento, balanceamento de carga, e permite que os usuários integrem suas soluções de _logging_, monitoramento e alerta. No entanto, o Kubernetes não é monolítico, e essas soluções padrão são opcionais e conectáveis. O Kubernetes fornece os blocos de construção para a construção de plataformas de desenvolvimento, mas preserva a escolha e flexibilidade do usuário onde é importante.
+
+Kubernetes:
+
+* Não limita os tipos de aplicações suportadas. O Kubernetes visa oferecer suporte a uma variedade extremamente diversa de cargas de trabalho, incluindo cargas de trabalho sem estado, com estado e de processamento de dados. Se uma aplicação puder ser executada em um contêiner, ele deve ser executado perfeitamente no Kubernetes.
+* Não implanta código-fonte e não constrói sua aplicação. Os fluxos de trabalho de integração contínua, entrega e implantação (CI/CD) são determinados pelas culturas e preferências da organização, bem como pelos requisitos técnicos.
+* Não fornece serviços em nível de aplicação, tais como middleware (por exemplo, barramentos de mensagem), estruturas de processamento de dados (por exemplo, Spark), bancos de dados (por exemplo, MySQL), caches, nem sistemas de armazenamento em cluster (por exemplo, Ceph), como serviços integrados. Esses componentes podem ser executados no Kubernetes e/ou podem ser acessados por aplicações executadas no Kubernetes por meio de mecanismos portáteis, como o [Open Service Broker](https://openservicebrokerapi.org/).
+* Não dita soluções de _logging_, monitoramento ou alerta. Ele fornece algumas integrações como prova de conceito e mecanismos para coletar e exportar métricas.
+* Não fornece nem exige um sistema/idioma de configuração (por exemplo, Jsonnet). Ele fornece uma API declarativa que pode ser direcionada por formas arbitrárias de especificações declarativas.
+* Não fornece nem adota sistemas abrangentes de configuração de máquinas, manutenção, gerenciamento ou autocorreção.
+* Adicionalmente, o Kubernetes não é um mero sistema de orquestração. Na verdade, ele elimina a necessidade de orquestração. A definição técnica de orquestração é a execução de um fluxo de trabalho definido: primeiro faça A, depois B e depois C. Em contraste, o Kubernetes compreende um conjunto de processos de controle independentes e combináveis que conduzem continuamente o estado atual em direção ao estado desejado fornecido. Não importa como você vai de A para C. O controle centralizado também não é necessário. Isso resulta em um sistema que é mais fácil de usar e mais poderoso, robusto, resiliente e extensível.
+
+
+## {{% heading "whatsnext" %}}
+
+* Dê uma olhada em [Componentes do Kubernetes](/docs/concepts/overview/components/).
+* Pronto para [Iniciar](/docs/setup/)?
diff --git a/content/pt/docs/concepts/scheduling-eviction/_index.md b/content/pt/docs/concepts/scheduling-eviction/_index.md
new file mode 100644
index 0000000000..e9e036f0c3
--- /dev/null
+++ b/content/pt/docs/concepts/scheduling-eviction/_index.md
@@ -0,0 +1,8 @@
+---
+title: "Escalonamento"
+weight: 90
+description: >
+ No Kubernetes, agendamento refere-se a garantia de que os pods correspondam aos nós para que o kubelet possa executá-los.
+ Remoção é o processo de falha proativa de um ou mais pods em nós com falta de recursos.
+---
+
diff --git a/content/pt/docs/concepts/scheduling/kube-scheduler.md b/content/pt/docs/concepts/scheduling-eviction/kube-scheduler.md
similarity index 93%
rename from content/pt/docs/concepts/scheduling/kube-scheduler.md
rename to content/pt/docs/concepts/scheduling-eviction/kube-scheduler.md
index 575a8e7839..8c8b0ec39a 100644
--- a/content/pt/docs/concepts/scheduling/kube-scheduler.md
+++ b/content/pt/docs/concepts/scheduling-eviction/kube-scheduler.md
@@ -91,4 +91,7 @@ do escalonador:
* Aprenda como [configurar vários escalonadores](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
* Aprenda sobre [políticas de gerenciamento de topologia](/docs/tasks/administer-cluster/topology-manager/)
* Aprenda sobre [Pod Overhead](/docs/concepts/configuration/pod-overhead/)
-
+* Saiba mais sobre o agendamento de pods que usam volumes em:
+ * [Suporte de topologia de volume](/docs/concepts/storage/storage-classes/#volume-binding-mode)
+ * [Rastreamento de capacidade de armazenamento](/docs/concepts/storage/storage-capacity/)
+ * [Limites de volumes específicos do nó](/docs/concepts/storage/storage-limits/)
\ No newline at end of file
diff --git a/content/pt/docs/concepts/configuration/pod-overhead.md b/content/pt/docs/concepts/scheduling-eviction/pod-overhead.md
similarity index 54%
rename from content/pt/docs/concepts/configuration/pod-overhead.md
rename to content/pt/docs/concepts/scheduling-eviction/pod-overhead.md
index 78ba1d6ffd..c3788b22fa 100644
--- a/content/pt/docs/concepts/configuration/pod-overhead.md
+++ b/content/pt/docs/concepts/scheduling-eviction/pod-overhead.md
@@ -1,9 +1,5 @@
---
-reviewers:
-- dchen1107
-- egernst
-- tallclair
-title: Pod Overhead
+title: Sobrecarga de Pod
content_type: concept
weight: 50
---
@@ -12,10 +8,10 @@ weight: 50
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
-Quando executa um Pod num nó, o próprio Pod usa uma quantidade de recursos do sistema. Estes
-recursos são adicionais aos recursos necessários para executar o(s) _container(s)_ dentro do Pod.
+Quando você executa um Pod num nó, o próprio Pod usa uma quantidade de recursos do sistema. Estes
+recursos são adicionais aos recursos necessários para executar o(s) contêiner(s) dentro do Pod.
Sobrecarga de Pod, do inglês _Pod Overhead_, é uma funcionalidade que serve para contabilizar os recursos consumidos pela
-infraestrutura do Pod para além das solicitações e limites do _container_.
+infraestrutura do Pod para além das solicitações e limites do contêiner.
@@ -23,27 +19,27 @@ infraestrutura do Pod para além das solicitações e limites do _container_.
-No Kubernetes, a sobrecarga de _Pods_ é definido no tempo de
+No Kubernetes, a sobrecarga de Pods é definido no tempo de
[admissão](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)
de acordo com a sobrecarga associada à
-[RuntimeClass](/docs/concepts/containers/runtime-class/) do _Pod_.
+[RuntimeClass](/docs/concepts/containers/runtime-class/) do Pod.
Quando é ativada a Sobrecarga de Pod, a sobrecarga é considerada adicionalmente à soma das
-solicitações de recursos do _container_ ao agendar um Pod. Semelhantemente, o _kubelet_
+solicitações de recursos do contêiner ao agendar um Pod. Semelhantemente, o _kubelet_
incluirá a sobrecarga do Pod ao dimensionar o cgroup do Pod e ao
-executar a classificação de despejo do Pod.
+executar a classificação de prioridade de migração do Pod em caso de _drain_ do Node.
-## Possibilitando a Sobrecarga do Pod {#set-up}
+## Habilitando a Sobrecarga de Pod {#set-up}
-Terá de garantir que o [portão de funcionalidade](/docs/reference/command-line-tools-reference/feature-gates/)
-`PodOverhead` está ativo (está ativo por defeito a partir da versão 1.18)
-por todo o cluster, e uma `RuntimeClass` é utilizada que defina o campo `overhead`.
+Terá de garantir que o [Feature Gate](/docs/reference/command-line-tools-reference/feature-gates/)
+`PodOverhead` esteja ativo (está ativo por padrão a partir da versão 1.18)
+em todo o cluster, e uma `RuntimeClass` utilizada que defina o campo `overhead`.
## Exemplo de uso
Para usar a funcionalidade PodOverhead, é necessário uma RuntimeClass que define o campo `overhead`.
-Por exemplo, poderia usar a definição da RuntimeClass abaixo com um _container runtime_ virtualizado
-que usa cerca de 120MiB por Pod para a máquina virtual e o sistema operativo convidado:
+Por exemplo, poderia usar a definição da RuntimeClass abaixo com um agente de execução de contêiner virtualizado
+que use cerca de 120MiB por Pod para a máquina virtual e o sistema operacional convidado:
```yaml
---
@@ -88,9 +84,9 @@ spec:
memory: 100Mi
```
-Na altura de admissão o [controlador de admissão](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) RuntimeClass
+No tempo de admissão o [controlador de admissão](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) RuntimeClass
atualiza o _PodSpec_ da carga de trabalho de forma a incluir o `overhead` como descrito na RuntimeClass. Se o _PodSpec_ já tiver este campo definido
-o _Pod_ será rejeitado. No exemplo dado, como apenas o nome do RuntimeClass é especificado, o controlador de admissão muda o _Pod_ de forma a
+o Pod será rejeitado. No exemplo dado, como apenas o nome do RuntimeClass é especificado, o controlador de admissão muda o Pod de forma a
incluir um `overhead`.
Depois do controlador de admissão RuntimeClass, pode verificar o _PodSpec_ atualizado:
@@ -99,44 +95,43 @@ Depois do controlador de admissão RuntimeClass, pode verificar o _PodSpec_ atua
kubectl get pod test-pod -o jsonpath='{.spec.overhead}'
```
-O output é:
+A saída é:
```
map[cpu:250m memory:120Mi]
```
-Se for definido um _ResourceQuota_, a soma dos pedidos dos _containers_ assim como o campo `overhead` são contados.
+Se for definido um _ResourceQuota_, a soma das requisições dos contêineres assim como o campo `overhead` são contados.
-Quando o kube-scheduler está a decidir que nó deve executar um novo _Pod_, o agendador considera o `overhead` do _Pod_,
-assim como a soma de pedidos aos _containers_ para esse _Pod_. Para este exemplo, o agendador adiciona os
-pedidos e a sobrecarga, depois procura um nó com 2.25 CPU e 320 MiB de memória disponível.
+Quando o kube-scheduler está decidindo que nó deve executar um novo Pod, o agendador considera o `overhead` do pod,
+assim como a soma de pedidos aos contêineres para esse _Pod_. Para este exemplo, o agendador adiciona as requisições e a sobrecarga, depois procura um nó com 2.25 CPU e 320 MiB de memória disponível.
-Assim que um _Pod_ é agendado a um nó, o kubelet nesse nó cria um novo {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}
-para o _Pod_. É dentro deste _pod_ que o _container runtime_ subjacente vai criar _containers_.
+Assim que um Pod é agendado a um nó, o kubelet nesse nó cria um novo {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}
+para o Pod. É dentro deste Pod que o agente de execução de contêiners subjacente vai criar contêineres.
-Se o recurso tiver um limite definido para cada _container_ (_QoS_ garantida ou _Burstrable QoS_ com limites definidos),
-o kubelet definirá um limite superior para o cgroup do _pod_ associado a esse recurso (cpu.cfs_quota_us para CPU
-e memory.limit_in_bytes de memória). Este limite superior é baseado na soma dos limites do _container_ mais o `overhead`
+Se o recurso tiver um limite definido para cada contêiner (_QoS_ garantida ou _Burstrable QoS_ com limites definidos),
+o kubelet definirá um limite superior para o cgroup do Pod associado a esse recurso (cpu.cfs_quota_us para CPU
+e memory.limit_in_bytes de memória). Este limite superior é baseado na soma dos limites do contêiner mais o `overhead`
definido no _PodSpec_.
-Para o CPU, se o _Pod_ for QoS garantida ou _Burstrable QoS_, o kubelet vai definir `cpu.shares` baseado na soma dos
-pedidos ao _container_ mais o `overhead` definido no _PodSpec_.
+Para CPU, se o Pod for QoS garantida ou _Burstrable QoS_, o kubelet vai definir `cpu.shares` baseado na soma dos
+pedidos ao contêiner mais o `overhead` definido no _PodSpec_.
-Olhando para o nosso exemplo, verifique os pedidos ao _container_ para a carga de trabalho:
+Olhando para o nosso exemplo, verifique as requisições ao contêiner para a carga de trabalho:
```bash
kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}'
```
-O total de pedidos ao _container_ são 2000m CPU e 200MiB de memória:
+O total de requisições ao contêiner são 2000m CPU e 200MiB de memória:
```
map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi]
```
-Verifique isto contra o que é observado pelo nó:
+Verifique isto comparado ao que é observado pelo nó:
```bash
kubectl describe node | grep test-pod -B2
```
-O output mostra que 2250m CPU e 320MiB de memória são solicitados, que inclui _PodOverhead_:
+A saída mostra que 2250m CPU e 320MiB de memória são solicitados, que inclui _PodOverhead_:
```
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE
--------- ---- ------------ ---------- --------------- ------------- ---
@@ -145,12 +140,12 @@ O output mostra que 2250m CPU e 320MiB de memória são solicitados, que inclui
## Verificar os limites cgroup do Pod
-Verifique os cgroups de memória do Pod no nó onde a carga de trabalho está em execução. No seguinte exemplo, [`crictl`] (https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)
-é usado no nó, que fornece uma CLI para _container runtimes_ compatíveis com CRI. Isto é um
-exemplo avançado para mostrar o comportamento do _PodOverhead_, e não é esperado que os utilizadores precisem de verificar
+Verifique os cgroups de memória do Pod no nó onde a carga de trabalho está em execução. No seguinte exemplo, [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)
+é usado no nó, que fornece uma CLI para agentes de execução compatíveis com CRI. Isto é um
+exemplo avançado para mostrar o comportamento do _PodOverhead_, e não é esperado que os usuários precisem verificar
cgroups diretamente no nó.
-Primeiro, no nó em particular, determine o identificador do _Pod_:
+Primeiro, no nó em particular, determine o identificador do Pod:
```bash
# Execute no nó onde o Pod está agendado
@@ -163,15 +158,15 @@ A partir disto, pode determinar o caminho do cgroup para o _Pod_:
sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath
```
-O caminho do cgroup resultante inclui o _container_ `pause` do _Pod_. O cgroup no nível do _Pod_ está um diretório acima.
+O caminho do cgroup resultante inclui o contêiner `pause` do Pod. O cgroup no nível do Pod está um diretório acima.
```
"cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a"
```
-Neste caso especifico, o caminho do cgroup do pod é `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2`. Verifique a configuração cgroup de nível do _Pod_ para a memória:
+Neste caso especifico, o caminho do cgroup do Pod é `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2`. Verifique a configuração cgroup de nível do Pod para a memória:
```bash
# Execute no nó onde o Pod está agendado
-# Mude também o nome do cgroup de forma a combinar com o cgroup alocado ao pod.
+# Mude também o nome do cgroup para combinar com o cgroup alocado ao Pod.
cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes
```
@@ -182,10 +177,10 @@ Isto é 320 MiB, como esperado:
### Observabilidade
-Uma métrica `kube_pod_overhead` está disponível em [kube-state-metrics] (https://github.com/kubernetes/kube-state-metrics)
-para ajudar a identificar quando o _PodOverhead_ está a ser utilizado e para ajudar a observar a estabilidade das cargas de trabalho
+Uma métrica `kube_pod_overhead` está disponível em [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics)
+para ajudar a identificar quando o _PodOverhead_ está sendo utilizado e para ajudar a observar a estabilidade das cargas de trabalho
em execução com uma sobrecarga (_Overhead_) definida. Esta funcionalidade não está disponível na versão 1.9 do kube-state-metrics,
-mas é esperado num próximo _release_. Os utilizadores necessitarão entretanto de construir kube-state-metrics a partir da fonte.
+mas é esperado em uma próxima versão. Os usuários necessitarão entretanto construir o kube-state-metrics a partir do código fonte.
diff --git a/content/pt/docs/concepts/scheduling/_index.md b/content/pt/docs/concepts/scheduling/_index.md
deleted file mode 100644
index 577dbb8c87..0000000000
--- a/content/pt/docs/concepts/scheduling/_index.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: "Escalonamento"
-weight: 90
----
-
diff --git a/content/pt/docs/reference/glossary/cloud-controller-manager.md b/content/pt/docs/reference/glossary/cloud-controller-manager.md
new file mode 100644
index 0000000000..622d3f842e
--- /dev/null
+++ b/content/pt/docs/reference/glossary/cloud-controller-manager.md
@@ -0,0 +1,21 @@
+---
+title: Gerenciador de controle de nuvem
+id: cloud-controller-manager
+date: 2018-04-12
+full_link: /docs/concepts/architecture/cloud-controller/
+short_description: >
+ Componente da camada de gerenciamento que integra Kubernetes com provedores de nuvem de terceiros.
+aka:
+tags:
+- core-object
+- architecture
+- operation
+---
+
+ Um componente da {{< glossary_tooltip text="camada de gerenciamento" term_id="control-plane" >}} do Kubernetes
+ que incorpora a lógica de controle específica da nuvem. O gerenciador de controle de nuvem permite que você vincule seu
+ _cluster_ na API do seu provedor de nuvem, e separar os componentes que interagem com essa plataforma de nuvem a partir de componentes que apenas interagem com seu cluster.
+
+
+
+Desassociando a lógica de interoperabilidade entre o Kubernetes e a infraestrutura de nuvem subjacente, o componente gerenciador de controle de nuvem permite que os provedores de nuvem desenvolvam e disponibilizem recursos em um ritmo diferente em comparação com o projeto principal do Kubernetes.
diff --git a/content/pt/docs/reference/glossary/cncf.md b/content/pt/docs/reference/glossary/cncf.md
new file mode 100644
index 0000000000..f9ad249547
--- /dev/null
+++ b/content/pt/docs/reference/glossary/cncf.md
@@ -0,0 +1,20 @@
+---
+title: Cloud Native Computing Foundation (CNCF)
+id: cncf
+date: 2019-05-26
+full_link: https://cncf.io/
+short_description: >
+ Cloud Native Computing Foundation
+
+aka:
+tags:
+- community
+---
+ A **Cloud Native Computing Foundation (CNCF)** constrói um ecossistema sustentável e promove uma comunidade no entorno dos [projetos](https://www.cncf.io/projects/) que orquestram contêineres como parte de uma arquitetura de microserviços.
+
+**Kubernetes** é um projeto CNCF.
+
+
+
+A **CNCF** é uma sub-fundação da [Linux Foundation](https://www.linuxfoundation.org/).
+Sua missão é tornar a computação nativa em nuvem onipresente.
diff --git a/content/pt/docs/reference/glossary/container-runtime.md b/content/pt/docs/reference/glossary/container-runtime.md
new file mode 100644
index 0000000000..8c1cb808ef
--- /dev/null
+++ b/content/pt/docs/reference/glossary/container-runtime.md
@@ -0,0 +1,18 @@
+---
+title: Agente de execução de contêiner
+id: container-runtime
+date: 2019-06-05
+full_link: /docs/setup/production-environment/container-runtimes
+short_description: >
+ O agente de execução de contêiner é o software responsável por executar os contêineres.
+
+aka:
+tags:
+- fundamental
+- workload
+---
+ O agente de execução (_runtime_) de contêiner é o software responsável por executar os contêineres.
+
+
+
+O Kubernetes suporta diversos agentes de execução de contêineres: {{< glossary_tooltip term_id="docker">}}, {{< glossary_tooltip term_id="containerd" >}}, {{< glossary_tooltip term_id="cri-o" >}}, e qualquer implementação do [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
diff --git a/content/pt/docs/reference/glossary/control-plane.md b/content/pt/docs/reference/glossary/control-plane.md
index 0465d5a2b8..c65759b83b 100644
--- a/content/pt/docs/reference/glossary/control-plane.md
+++ b/content/pt/docs/reference/glossary/control-plane.md
@@ -1,13 +1,13 @@
---
-title: Ambiente de gerenciamento
+title: Camada de gerenciamento
id: control-plane
date: 2020-04-19
full_link:
short_description: >
- A camada de orquestração de contêiner que expõe a API e as interfaces para definir, implantar e gerenciar o ciclo de vida dos contêineres.
+ A camada de gerenciamento de contêiner que expõe a API e as interfaces para definir, implantar e gerenciar o ciclo de vida dos contêineres.
aka:
tags:
- fundamental
---
- A camada de orquestração de contêiner que expõe a API e as interfaces para definir, implantar e gerenciar o ciclo de vida dos contêineres.
+ A camada de gerenciamento de contêiner que expõe a API e as interfaces para definir, implantar e gerenciar o ciclo de vida dos contêineres.
diff --git a/content/pt/docs/reference/glossary/etcd.md b/content/pt/docs/reference/glossary/etcd.md
new file mode 100644
index 0000000000..0761a53865
--- /dev/null
+++ b/content/pt/docs/reference/glossary/etcd.md
@@ -0,0 +1,19 @@
+---
+title: etcd
+id: etcd
+date: 2018-04-12
+full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/
+short_description: >
+ Armazenamento do tipo Chave-Valor consistente e em alta-disponibilidade usado como repositório de apoio do Kubernetes para todos os dados do cluster.
+aka:
+tags:
+- architecture
+- storage
+---
+ Armazenamento do tipo Chave-Valor consistente e em alta-disponibilidade usado como repositório de apoio do Kubernetes para todos os dados do cluster.
+
+
+
+Se o seu cluster Kubernetes usa **etcd** como seu armazenamento de apoio, certifique-se de ter um plano de [back up](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) para seus dados.
+
+Você pode encontrar informações detalhadas sobre o etcd na seção oficial da [documentação](https://etcd.io/docs/).
diff --git a/content/pt/docs/reference/glossary/kube-apiserver.md b/content/pt/docs/reference/glossary/kube-apiserver.md
new file mode 100644
index 0000000000..f5ce3dba1a
--- /dev/null
+++ b/content/pt/docs/reference/glossary/kube-apiserver.md
@@ -0,0 +1,22 @@
+---
+title: API server
+id: kube-apiserver
+date: 2018-04-12
+full_link: /docs/concepts/overview/components/#kube-apiserver
+short_description: >
+ O componente da camada de gerenciamento que serve a API do Kubernetes.
+
+aka:
+- kube-apiserver
+tags:
+- architecture
+- fundamental
+---
+ O servidor de API é um componente da {{< glossary_tooltip text="Camada de gerenciamento" term_id="control-plane" >}} do Kubernetes que expõe a API do Kubernetes.
+O servidor de API é o _front end_ para a camada de gerenciamento do Kubernetes.
+
+
+
+A principal implementação de um servidor de API do Kubernetes é [kube-apiserver](/docs/reference/generated/kube-apiserver/).
+O kube-apiserver foi projetado para ser escalonado horizontalmente — ou seja, ele pode ser escalado com a implantação de mais instâncias.
+Você pode executar várias instâncias do kube-apiserver e balancear (balanceamento de carga, etc) o tráfego entre essas instâncias.
diff --git a/content/pt/docs/reference/glossary/kube-controller-manager.md b/content/pt/docs/reference/glossary/kube-controller-manager.md
new file mode 100644
index 0000000000..0a52ec27ea
--- /dev/null
+++ b/content/pt/docs/reference/glossary/kube-controller-manager.md
@@ -0,0 +1,18 @@
+---
+title: kube-controller-manager
+id: kube-controller-manager
+date: 2018-04-12
+full_link: /docs/reference/command-line-tools-reference/kube-controller-manager/
+short_description: >
+ Componente da camada de gerenciamento que executa os processos de controle.
+
+aka:
+tags:
+- architecture
+- fundamental
+---
+ Componente da camada de gerenciamento que executa os processos de {{< glossary_tooltip text="controlador" term_id="controller" >}}.
+
+
+
+Logicamente, cada _{{< glossary_tooltip text="controlador" term_id="controller" >}}_ está em um processo separado, mas para reduzir a complexidade, eles todos são compilados num único binário e executam em um processo único.
diff --git a/content/pt/docs/reference/glossary/kube-proxy.md b/content/pt/docs/reference/glossary/kube-proxy.md
new file mode 100644
index 0000000000..1f9a075bd6
--- /dev/null
+++ b/content/pt/docs/reference/glossary/kube-proxy.md
@@ -0,0 +1,22 @@
+---
+title: kube-proxy
+id: kube-proxy
+date: 2018-04-12
+full_link: /docs/reference/command-line-tools-reference/kube-proxy/
+short_description: >
+ `kube-proxy` é um _proxy_ de rede executado em cada nó do _cluster_.
+
+aka:
+tags:
+- fundamental
+- networking
+---
+ kube-proxy é um _proxy_ de rede executado em cada {{< glossary_tooltip text="nó" term_id="node" >}} no seu _cluster_,
+implementando parte do conceito de {{< glossary_tooltip text="serviço" term_id="service">}} do Kubernetes.
+
+
+
+[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)
+mantém regras de rede nos nós. Estas regras de rede permitem a comunicação de rede com seus _pods_ a partir de sessões de rede dentro ou fora de seu _cluster_.
+
+kube-proxy usa a camada de filtragem de pacotes do sistema operacional se houver uma e estiver disponível. Caso contrário, o kube-proxy encaminha o tráfego ele mesmo.
diff --git a/content/pt/docs/reference/glossary/kube-scheduler.md b/content/pt/docs/reference/glossary/kube-scheduler.md
new file mode 100644
index 0000000000..1030d27853
--- /dev/null
+++ b/content/pt/docs/reference/glossary/kube-scheduler.md
@@ -0,0 +1,17 @@
+---
+title: kube-scheduler
+id: kube-scheduler
+date: 2018-04-12
+full_link: /docs/reference/generated/kube-scheduler/
+short_description: >
+ Componente da camada de gerenciamento que observa os _pods_ recém-criados sem nenhum nó atribuído, e seleciona um nó para executá-los.
+aka:
+tags:
+- architecture
+---
+Componente da camada de gerenciamento que observa os _{{< glossary_tooltip term_id="pod" text="pods" >}}_ recém-criados sem nenhum {{< glossary_tooltip term_id="node" text="nó">}} atribuído, e seleciona um nó para executá-los.
+
+
+
+Os fatores levados em consideração para as decisões de agendamento incluem:
+requisitos de recursos individuais e coletivos, hardware/software/política de restrições, especificações de afinidade e antiafinidade, localidade de dados, interferência entre cargas de trabalho, e prazos.
diff --git a/content/zh/docs/concepts/storage/volumes.md b/content/zh/docs/concepts/storage/volumes.md
index 4c49adb4b2..66e8d34718 100644
--- a/content/zh/docs/concepts/storage/volumes.md
+++ b/content/zh/docs/concepts/storage/volumes.md
@@ -2087,7 +2087,7 @@ persistent volume:
-->
- `volumeHandle`：唯一标识卷的字符串值。
该值必须与 CSI 驱动在 `CreateVolumeResponse` 的 `volume_id` 字段中返回的值相对应；
- 接口定义在 [CSI spec](https://github.com/container-storageinterface/spec/blob/master/spec.md#createvolume) 中。
+ 接口定义在 [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume) 中。
在所有对 CSI 卷驱动程序的调用中，引用该 CSI 卷时都使用此值作为 `volume_id` 参数。
-Job `pi-with-ttl` 在结束 100 秒之后，可以成为被自动删除的标的。
+Job `pi-with-ttl` 在结束 100 秒之后，可以成为被自动删除的对象。
如果该字段设置为 `0`，Job 在结束之后立即成为可被自动删除的对象。
如果该字段没有设置，Job 不会在结束之后被 TTL 控制器自动清除。
diff --git a/content/zh/docs/reference/using-api/_index.md b/content/zh/docs/reference/using-api/_index.md
index 88b6bce641..303f2152ac 100644
--- a/content/zh/docs/reference/using-api/_index.md
+++ b/content/zh/docs/reference/using-api/_index.md
@@ -1,6 +1,10 @@
---
-title: 使用 Kubernetes API
+title: API 概述
weight: 10
+no_list: true
+card:
+ name: reference
+ weight: 50
---
@@ -68,7 +72,7 @@ can find more information about the criteria for each level in the
[API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions).
-->
不同的 API 版本代表着不同的稳定性和支持级别。
-你可以在 [API 变更文档]https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)
+你可以在 [API 变更文档](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)
中查看到更多的不同级别的判定标准。
-## 启用或禁用 API 组 {#enabling-or-disabling}
+## 启用或禁用 API 组 {#enabling-or-disabling}
资源和 API 组是在默认情况下被启用的。
你可以通过在 API 服务器上设置 `--runtime-config` 参数来启用或禁用它们。
`--runtime-config` 参数接受逗号分隔的 `[=]` 对，
diff --git a/content/zh/docs/tasks/administer-cluster/access-cluster-api.md b/content/zh/docs/tasks/administer-cluster/access-cluster-api.md
index 59b4fa758f..4f2ee3b05a 100644
--- a/content/zh/docs/tasks/administer-cluster/access-cluster-api.md
+++ b/content/zh/docs/tasks/administer-cluster/access-cluster-api.md
@@ -251,11 +251,12 @@ Kubernetes 官方支持 [Go](#go-client)、[Python](#python-client)、[Java](#ja
#### Go 客户端 {#go-client}
+* To get the library, run the following command: `go get k8s.io/client-go@kubernetes-` See [https://github.com/kubernetes/client-go/releases](https://github.com/kubernetes/client-go/releases) to see which versions are supported.
+* Write an application atop of the client-go clients.
+-->
-* 要获取库，运行下列命令：`go get k8s.io/client-go/<版本号>/kubernetes`，
- 参见 [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go) 查看受支持的版本。
+* 要获取库，运行下列命令：`go get k8s.io/client-go/kubernetes-`，
+ 参见 [https://github.com/kubernetes/client-go/releases](https://github.com/kubernetes/client-go/releases) 查看受支持的版本。
* 基于 client-go 客户端编写应用程序。
-* 要安装 [Java 客户端](https://github.com/kubernetes-client/java)，只需执行：
+要安装 [Java 客户端](https://github.com/kubernetes-client/java)，运行：
```shell
# 克隆 Java 库
@@ -522,168 +523,8 @@ exampleWithKubeConfig = do
>>= print
```
-
+## {{% heading "whatsnext" %}}
-### 从 Pod 中访问 API
-
-从 Pod 内部访问 API 时，定位 API 服务器和向服务器认证身份的操作
-与上面描述的外部客户场景不同。
-
-
-从 Pod 使用 Kubernetes API 的最简单的方法就是使用官方的
-[客户端库](/zh/docs/reference/using-api/client-libraries/)。
-这些库可以自动发现 API 服务器并进行身份验证。
-
-
-#### 使用官方客户端库
-
-从一个 Pod 内部连接到 Kubernetes API 的推荐方式为：
-
-- 对于 Go 语言客户端，使用官方的 [Go 客户端库](https://github.com/kubernetes/client-go/)。
- 函数 `rest.InClusterConfig()` 自动处理 API 主机发现和身份认证。
- 参见[这里的一个例子](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)。
-
-- 对于 Python 客户端，使用官方的 [Python 客户端库](https://github.com/kubernetes-client/python/)。
- 函数 `config.load_incluster_config()` 自动处理 API 主机的发现和身份认证。
- 参见[这里的一个例子](https://github.com/kubernetes-client/python/blob/master/examples/in_cluster_config.py)。
-
-- 还有一些其他可用的客户端库，请参阅[客户端库](/zh/docs/reference/using-api/client-libraries/)页面。
-
-在以上场景中，客户端库都使用 Pod 的服务账号凭据来与 API 服务器安全地通信。
-
-
-#### 直接访问 REST API
-
-在运行在 Pod 中时，可以通过 `default` 命名空间中的名为 `kubernetes` 的服务访问
-Kubernetes API 服务器。也就是说，Pod 可以使用 `kubernetes.default.svc` 主机名
-来查询 API 服务器。官方客户端库自动完成这个工作。
-
-
-向 API 服务器进行身份认证的推荐做法是使用
-[服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/)凭据。
-默认情况下，每个 Pod 与一个服务账号关联，该服务账户的凭证（令牌）放置在此 Pod 中
-每个容器的文件系统树中的 `/var/run/secrets/kubernetes.io/serviceaccount/token` 处。
-
-
-如果由证书包可用，则凭证包被放入每个容器的文件系统树中的
-`/var/run/secrets/kubernetes.io/serviceaccount/ca.crt` 处，
-且将被用于验证 API 服务器的服务证书。
-
-
-最后，用于命名空间域 API 操作的默认命名空间放置在每个容器中的
-`/var/run/secrets/kubernetes.io/serviceaccount/namespace` 文件中。
-
-
-#### 使用 kubectl proxy {#use-kubectl-proxy}
-
-如果你希望不实用官方客户端库就完成 API 查询，可以将 `kubectl proxy` 作为
-[command](/zh/docs/tasks/inject-data-application/define-command-argument-container/)
-在 Pod 启动一个边车（Sidecar）容器。这样，`kubectl proxy` 自动完成对 API
-的身份认证，并将其暴露到 Pod 的 `localhost` 接口，从而 Pod 中的其他容器可以
-直接使用 API。
-
-
-#### 不使用代理 {#without-using-a-proxy}
-
-通过将认证令牌直接发送到 API 服务器，也可以避免运行 kubectl proxy 命令。
-内部的证书机制能够为链接提供保护。
-
-```shell
-# 指向内部 API 服务器的主机名
-APISERVER=https://kubernetes.default.svc
-
-# 服务账号令牌的路径
-SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
-
-# 读取 Pod 的名字空间
-NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
-
-# 读取服务账号的持有者令牌
-TOKEN=$(cat ${SERVICEACCOUNT}/token)
-
-# 引用内部整数机构（CA）
-CACERT=${SERVICEACCOUNT}/ca.crt
-
-# 使用令牌访问 API
-curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api
-```
-
-
-输出类似于：
-
-```json
-{
- "kind": "APIVersions",
- "versions": [
- "v1"
- ],
- "serverAddressByClientCIDRs": [
- {
- "clientCIDR": "0.0.0.0/0",
- "serverAddress": "10.0.1.149:443"
- }
- ]
-}
-```
-
+* [从 Pod 中访问 API](/zh/docs/tasks/run-application/access-api-from-pod/)
diff --git a/content/zh/docs/tasks/administer-cluster/certificates.md b/content/zh/docs/tasks/administer-cluster/certificates.md
new file mode 100644
index 0000000000..a61ad671c0
--- /dev/null
+++ b/content/zh/docs/tasks/administer-cluster/certificates.md
@@ -0,0 +1,366 @@
+---
+title: 证书
+content_type: task
+weight: 20
+---
+
+
+
+
+
+在使用客户端证书认证的场景下，你可以通过 `easyrsa`、`openssl` 或 `cfssl` 等工具以手工方式生成证书。
+
+
+
+### easyrsa
+
+
+**easyrsa** 支持以手工方式为你的集群生成证书。
+
+
+1. 下载、解压、初始化打过补丁的 easyrsa3。
+
+ curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz
+ tar xzf easy-rsa.tar.gz
+ cd easy-rsa-master/easyrsa3
+ ./easyrsa init-pki
+
+
+1. 生成新的证书颁发机构（CA）。参数 `--batch` 用于设置自动模式；
+ 参数 `--req-cn` 用于设置新的根证书的通用名称（CN）。
+
+ ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
+
+
+1. 生成服务器证书和秘钥。
+ 参数 `--subject-alt-name` 设置 API 服务器的 IP 和 DNS 名称。
+ `MASTER_CLUSTER_IP` 用于 API 服务器和控制管理器，通常取 CIDR 的第一个 IP，由 `--service-cluster-ip-range` 的参数提供。
+ 参数 `--days` 用于设置证书的过期时间。
+ 下面的示例假定你的默认 DNS 域名为 `cluster.local`。
+
+ ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\
+ "IP:${MASTER_CLUSTER_IP},"\
+ "DNS:kubernetes,"\
+ "DNS:kubernetes.default,"\
+ "DNS:kubernetes.default.svc,"\
+ "DNS:kubernetes.default.svc.cluster,"\
+ "DNS:kubernetes.default.svc.cluster.local" \
+ --days=10000 \
+ build-server-full server nopass
+
+
+1. 拷贝文件 `pki/ca.crt`、`pki/issued/server.crt` 和 `pki/private/server.key` 到你的目录中。
+1. 在 API 服务器的启动参数中添加以下参数：
+
+ --client-ca-file=/yourdirectory/ca.crt
+ --tls-cert-file=/yourdirectory/server.crt
+ --tls-private-key-file=/yourdirectory/server.key
+
+### openssl
+
+
+**openssl** 支持以手工方式为你的集群生成证书。
+
+
+1. 生成一个 2048 位的 ca.key 文件
+
+ openssl genrsa -out ca.key 2048
+
+
+1. 在 ca.key 文件的基础上，生成 ca.crt 文件（用参数 -days 设置证书有效期）
+
+ openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt
+
+
+1. 生成一个 2048 位的 server.key 文件：
+
+ openssl genrsa -out server.key 2048
+
+
+1. 创建一个用于生成证书签名请求（CSR）的配置文件。
+ 保存文件（例如：`csr.conf`）前，记得用真实值替换掉尖括号中的值（例如：``）。
+ 注意：`MASTER_CLUSTER_IP` 就像前一小节所述，它的值是 API 服务器的服务集群 IP。
+ 下面的例子假定你的默认 DNS 域名为 `cluster.local`。
+
+ [ req ]
+ default_bits = 2048
+ prompt = no
+ default_md = sha256
+ req_extensions = req_ext
+ distinguished_name = dn
+
+ [ dn ]
+ C =
+ ST =
+ L =
+ O =
+ OU =
+ CN =
+
+ [ req_ext ]
+ subjectAltName = @alt_names
+
+ [ alt_names ]
+ DNS.1 = kubernetes
+ DNS.2 = kubernetes.default
+ DNS.3 = kubernetes.default.svc
+ DNS.4 = kubernetes.default.svc.cluster
+ DNS.5 = kubernetes.default.svc.cluster.local
+ IP.1 =
+ IP.2 =
+
+ [ v3_ext ]
+ authorityKeyIdentifier=keyid,issuer:always
+ basicConstraints=CA:FALSE
+ keyUsage=keyEncipherment,dataEncipherment
+ extendedKeyUsage=serverAuth,clientAuth
+ subjectAltName=@alt_names
+
+
+1. 基于上面的配置文件生成证书签名请求：
+
+ openssl req -new -key server.key -out server.csr -config csr.conf
+
+
+1. 基于 ca.key、ca.key 和 server.csr 等三个文件生成服务端证书：
+
+ openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
+ -CAcreateserial -out server.crt -days 10000 \
+ -extensions v3_ext -extfile csr.conf
+
+
+1. 查看证书：
+
+ openssl x509 -noout -text -in ./server.crt
+
+
+最后，为 API 服务器添加相同的启动参数。
+
+### cfssl
+
+
+**cfssl** 是另一个用于生成证书的工具。
+
+
+1. 下载、解压并准备如下所示的命令行工具。
+ 注意：你可能需要根据所用的硬件体系架构和 cfssl 版本调整示例命令。
+
+ curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl
+ chmod +x cfssl
+ curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson
+ chmod +x cfssljson
+ curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo
+ chmod +x cfssl-certinfo
+
+
+1. 创建一个目录，用它保存所生成的构件和初始化 cfssl：
+
+ mkdir cert
+ cd cert
+ ../cfssl print-defaults config > config.json
+ ../cfssl print-defaults csr > csr.json
+
+
+1. 创建一个 JSON 配置文件来生成 CA 文件，例如：`ca-config.json`：
+
+ {
+ "signing": {
+ "default": {
+ "expiry": "8760h"
+ },
+ "profiles": {
+ "kubernetes": {
+ "usages": [
+ "signing",
+ "key encipherment",
+ "server auth",
+ "client auth"
+ ],
+ "expiry": "8760h"
+ }
+ }
+ }
+ }
+
+
+1. 创建一个 JSON 配置文件，用于 CA 证书签名请求（CSR），例如：`ca-csr.json`。
+ 确认用你需要的值替换掉尖括号中的值。
+
+ {
+ "CN": "kubernetes",
+ "key": {
+ "algo": "rsa",
+ "size": 2048
+ },
+ "names":[{
+ "C": "",
+ "ST": "",
+ "L": "",
+ "O": "",
+ "OU": ""
+ }]
+ }
+
+
+1. 生成 CA 秘钥文件（`ca-key.pem`）和证书文件（`ca.pem`）：
+
+ ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca
+
+
+1. 创建一个 JSON 配置文件，用来为 API 服务器生成秘钥和证书，例如：`server-csr.json`。
+ 确认用你需要的值替换掉尖括号中的值。`MASTER_CLUSTER_IP` 是为 API 服务器 指定的服务集群 IP，就像前面小节描述的那样。
+ 以下示例假定你的默认 DSN 域名为`cluster.local`。
+
+ {
+ "CN": "kubernetes",
+ "hosts": [
+ "127.0.0.1",
+ "",
+ "",
+ "kubernetes",
+ "kubernetes.default",
+ "kubernetes.default.svc",
+ "kubernetes.default.svc.cluster",
+ "kubernetes.default.svc.cluster.local"
+ ],
+ "key": {
+ "algo": "rsa",
+ "size": 2048
+ },
+ "names": [{
+ "C": "",
+ "ST": "",
+ "L": "",
+ "O": "",
+ "OU": ""
+ }]
+ }
+
+
+1. 为 API 服务器生成秘钥和证书，默认会分别存储为`server-key.pem` 和 `server.pem` 两个文件。
+
+ ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \
+ --config=ca-config.json -profile=kubernetes \
+ server-csr.json | ../cfssljson -bare server
+
+
+## 分发自签名的 CA 证书
+
+
+客户端节点可能不认可自签名 CA 证书的有效性。
+对于非生产环境，或者运行在公司防火墙后的环境，你可以分发自签名的 CA 证书到所有客户节点，并刷新本地列表以使证书生效。
+
+在每一个客户节点，执行以下操作：
+
+```bash
+sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt
+sudo update-ca-certificates
+```
+
+```
+Updating certificates in /etc/ssl/certs...
+1 added, 0 removed; done.
+Running hooks in /etc/ca-certificates/update.d....
+done.
+```
+
+
+## 证书 API {#certificates-api}
+
+
+你可以通过 `certificates.k8s.io` API 提供 x509 证书，用来做身份验证，
+如[本](/zh/docs/tasks/tls/managing-tls-in-a-cluster)文档所述。
+
diff --git a/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md b/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md
index 7a93c9c932..381697d352 100644
--- a/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md
+++ b/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md
@@ -256,12 +256,11 @@ If the Kubelet **does not** have `--system-reserved-cgroup` and `--kube-reserved
the explicit cpuset provided by `reserved-cpus` will take precedence over the CPUs
defined by `--kube-reserved` and `--system-reserved` options.
-->
-`reserved-cpus` 旨在为操作系统守护程序和 kubernetes 系统守护程序定义一个显式 CPU
-集合。`reserved-cpus` 适用于不打算针对 cpuset 资源为操作系统守护程序和 kubernetes
+`reserved-cpus` 旨在为操作系统守护程序和 kubernetes 系统守护程序保留一组明确指定编号的
+CPU。`reserved-cpus` 适用于不打算针对 cpuset 资源为操作系统守护程序和 kubernetes
系统守护程序定义独立的顶级 cgroups 的系统。
如果 Kubelet **没有** 指定参数 `--system-reserved-cgroup` 和 `--kube-reserved-cgroup`，
-则 `reserved-cpus` 提供的显式 cpuset 将优先于 `--kube-reserved` 和 `--system-reserved`
-选项定义的 cpuset。
+则 `reserved-cpus` 的设置将优先于 `--kube-reserved` 和 `--system-reserved` 选项。
### 分类 {#categories}
-{{< feature-state state="beta" for_k8s_version="v1.10" >}}
-
[Kustomize](https://github.com/kubernetes-sigs/kustomize) 是一个独立的工具，用来通过
-[kustomization 文件](https://kubernetes-sigs.github.io/kustomize/api-reference/glossary/#kustomization)
+[kustomization 文件](https://kubectl.docs.kubernetes.io/references/kustomize/glossary/#kustomization)
定制 Kubernetes 对象。
+
+
+
+
+本指南演示了如何从 Pod 中访问 Kubernetes API。
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+
+
+
+### 从 Pod 中访问 API {#accessing-the-api-from-within-a-pod}
+
+从 Pod 内部访问 API 时，定位 API 服务器和向服务器认证身份的操作
+与外部客户端场景不同。
+
+
+从 Pod 使用 Kubernetes API 的最简单的方法就是使用官方的
+[客户端库](/zh/docs/reference/using-api/client-libraries/)。
+这些库可以自动发现 API 服务器并进行身份验证。
+
+
+#### 使用官方客户端库 {#using-official-client-libraries}
+
+从一个 Pod 内部连接到 Kubernetes API 的推荐方式为：
+
+- 对于 Go 语言客户端，使用官方的 [Go 客户端库](https://github.com/kubernetes/client-go/)。
+ 函数 `rest.InClusterConfig()` 自动处理 API 主机发现和身份认证。
+ 参见[这里的一个例子](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)。
+
+- 对于 Python 客户端，使用官方的 [Python 客户端库](https://github.com/kubernetes-client/python/)。
+ 函数 `config.load_incluster_config()` 自动处理 API 主机的发现和身份认证。
+ 参见[这里的一个例子](https://github.com/kubernetes-client/python/blob/master/examples/in_cluster_config.py)。
+
+- 还有一些其他可用的客户端库，请参阅[客户端库](/zh/docs/reference/using-api/client-libraries/)页面。
+
+在以上场景中，客户端库都使用 Pod 的服务账号凭据来与 API 服务器安全地通信。
+
+
+#### 直接访问 REST API {#directly-accessing-the-rest-api}
+
+在运行在 Pod 中时，可以通过 `default` 命名空间中的名为 `kubernetes` 的服务访问
+Kubernetes API 服务器。也就是说，Pod 可以使用 `kubernetes.default.svc` 主机名
+来查询 API 服务器。官方客户端库自动完成这个工作。
+
+
+向 API 服务器进行身份认证的推荐做法是使用
+[服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/)凭据。
+默认情况下，每个 Pod 与一个服务账号关联，该服务账户的凭证（令牌）放置在此 Pod 中
+每个容器的文件系统树中的 `/var/run/secrets/kubernetes.io/serviceaccount/token` 处。
+
+
+如果证书包可用，则凭证包被放入每个容器的文件系统树中的
+`/var/run/secrets/kubernetes.io/serviceaccount/ca.crt` 处，
+且将被用于验证 API 服务器的服务证书。
+
+
+最后，用于命名空间域 API 操作的默认命名空间放置在每个容器中的
+`/var/run/secrets/kubernetes.io/serviceaccount/namespace` 文件中。
+
+
+#### 使用 kubectl proxy {#use-kubectl-proxy}
+
+如果你希望不使用官方客户端库就完成 API 查询，可以将 `kubectl proxy` 作为
+[command](/zh/docs/tasks/inject-data-application/define-command-argument-container/)
+在 Pod 中启动一个边车（Sidecar）容器。这样，`kubectl proxy` 自动完成对 API
+的身份认证，并将其暴露到 Pod 的 `localhost` 接口，从而 Pod 中的其他容器可以
+直接使用 API。
+
+
+### 不使用代理 {#without-using-a-proxy}
+
+通过将认证令牌直接发送到 API 服务器，也可以避免运行 kubectl proxy 命令。
+内部的证书机制能够为链接提供保护。
+
+```shell
+# 指向内部 API 服务器的主机名
+APISERVER=https://kubernetes.default.svc
+
+# 服务账号令牌的路径
+SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
+
+# 读取 Pod 的名字空间
+NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
+
+# 读取服务账号的持有者令牌
+TOKEN=$(cat ${SERVICEACCOUNT}/token)
+
+# 引用内部证书机构（CA）
+CACERT=${SERVICEACCOUNT}/ca.crt
+
+# 使用令牌访问 API
+curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api
+```
+
+
+输出类似于：
+
+```json
+{
+ "kind": "APIVersions",
+ "versions": [
+ "v1"
+ ],
+ "serverAddressByClientCIDRs": [
+ {
+ "clientCIDR": "0.0.0.0/0",
+ "serverAddress": "10.0.1.149:443"
+ }
+ ]
+}
+```
diff --git a/content/zh/examples/access/certificate-signing-request/clusterrole-sign.yaml b/content/zh/examples/access/certificate-signing-request/clusterrole-sign.yaml
index 29bbc6a9cd..6d1a2f7882 100644
--- a/content/zh/examples/access/certificate-signing-request/clusterrole-sign.yaml
+++ b/content/zh/examples/access/certificate-signing-request/clusterrole-sign.yaml
@@ -21,7 +21,7 @@ rules:
- certificates.k8s.io
resources:
- signers
- resourceName:
+ resourceNames:
- example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain
verbs:
- sign
diff --git a/themes/docsy b/themes/docsy
index 0f6717470e..a7dc77412c 160000
--- a/themes/docsy
+++ b/themes/docsy
@@ -1 +1 @@
-Subproject commit 0f6717470e74b274e9f554a5ebf2465f2123d6a9
+Subproject commit a7dc77412c533fefc71730927350677fed35f576