kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #29153 from PI-Victor/merged-main-dev-1.22 

Merge main into dev 1.22 to sync and fix conflicts
This commit is contained in:
Kubernetes Prow Robot 2021-07-29 08:14:19 -07:00 committed by GitHub
parent 845ff4682c 252c44c53d
commit 6b0351333e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
22 changed files with 83 additions and 53 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
content/en/docs/concepts/cluster-administration/flow-control.md
View File

@ -412,6 +412,10 @@ poorly-behaved workloads that may be harming system health.
queue) requests, broken down by the labels `priority_level` and queue) requests, broken down by the labels `priority_level` and
`flow_schema`. `flow_schema`.
* `apiserver_flowcontrol_request_concurrency_in_use` is a gauge vector
holding the instantaneous number of occupied seats, broken down by
the labels `priority_level` and `flow_schema`.
* `apiserver_flowcontrol_priority_level_request_count_samples` is a * `apiserver_flowcontrol_priority_level_request_count_samples` is a
histogram vector of observations of the then-current number of histogram vector of observations of the then-current number of
requests broken down by the labels `phase` (which takes on the requests broken down by the labels `phase` (which takes on the

2
content/en/docs/concepts/configuration/manage-resources-containers.md
View File

@ -115,7 +115,7 @@ CPU is always requested as an absolute quantity, never as a relative quantity;
Limits and requests for `memory` are measured in bytes. You can express memory as Limits and requests for `memory` are measured in bytes. You can express memory as
a plain integer or as a fixed-point number using one of these suffixes: a plain integer or as a fixed-point number using one of these suffixes:
E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi, E, P, T, G, M, k. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
Mi, Ki. For example, the following represent roughly the same value: Mi, Ki. For example, the following represent roughly the same value:
```shell ```shell

55
content/en/docs/concepts/configuration/secret.md
View File

@ -12,26 +12,33 @@ weight: 30
<!-- overview --> <!-- overview -->
Kubernetes Secrets let you store and manage sensitive information, such
as passwords, OAuth tokens, and ssh keys. Storing confidential information in a Secret
is safer and more flexible than putting it verbatim in a
{{< glossary_tooltip term_id="pod" >}} definition or in a
{{< glossary_tooltip text="container image" term_id="image" >}}.
See [Secrets design document](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md) for more information.
A Secret is an object that contains a small amount of sensitive data such as A Secret is an object that contains a small amount of sensitive data such as
a password, a token, or a key. Such information might otherwise be put in a a password, a token, or a key. Such information might otherwise be put in a
Pod specification or in an image. Users can create Secrets and the system {{< glossary_tooltip term_id="pod" >}} specification or in a
also creates some Secrets. {{< glossary_tooltip text="container image" term_id="image" >}}. Using a
Secret means that you don't need to include confidential data in your
application code.
Because Secrets can be created independently of the Pods that use them, there
is less risk of the Secret (and its data) being exposed during the workflow of
creating, viewing, and editing Pods. Kubernetes, and applications that run in
your cluster, can also take additional precautions with Secrets, such as
avoiding writing confidential data to nonvolatile storage.
Secrets are similar to {{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}}
but are specifically intended to hold confidential data.
{{< caution >}} {{< caution >}}
Kubernetes Secrets are, by default, stored as unencrypted base64-encoded Kubernetes Secrets are, by default, stored unencrypted in the API server's underlying data store (etcd). Anyone with API access can retrieve or modify a Secret, and so can anyone with access to etcd.
strings. By default they can be retrieved - as plain text - by anyone with API Additionally, anyone who is authorized to create a Pod in a namespace can use that access to read any Secret in that namespace; this includes indirect access such as the ability to create a Deployment.
access, or anyone with access to Kubernetes' underlying data store, etcd. In
order to safely use Secrets, it is recommended you (at a minimum): In order to safely use Secrets, take at least the following steps:
1. [Enable Encryption at Rest](/docs/tasks/administer-cluster/encrypt-data/) for Secrets. 1. [Enable Encryption at Rest](/docs/tasks/administer-cluster/encrypt-data/) for Secrets.
2. [Enable or configure RBAC rules](/docs/reference/access-authn-authz/authorization/) that restrict reading and writing the Secret. Be aware that secrets can be obtained implicitly by anyone with the permission to create a Pod. 2. Enable or configure [RBAC rules](/docs/reference/access-authn-authz/authorization/) that
restrict reading data in Secrets (including via indirect means).
3. Where appropriate, also use mechanisms such as RBAC to limit which principals are allowed to create new Secrets or replace existing ones.
{{< /caution >}} {{< /caution >}}
<!-- body --> <!-- body -->
@ -47,6 +54,10 @@ A Secret can be used with a Pod in three ways:
- As [container environment variable](#using-secrets-as-environment-variables). - As [container environment variable](#using-secrets-as-environment-variables).
- By the [kubelet when pulling images](#using-imagepullsecrets) for the Pod. - By the [kubelet when pulling images](#using-imagepullsecrets) for the Pod.
The Kubernetes control plane also uses Secrets; for example,
[bootstrap token Secrets](#bootstrap-token-secrets) are a mechanism to
help automate node registration.
The name of a Secret object must be a valid The name of a Secret object must be a valid
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
You can specify the `data` and/or the `stringData` field when creating a You can specify the `data` and/or the `stringData` field when creating a
@ -407,9 +418,9 @@ stringData:
There are several options to create a Secret: There are several options to create a Secret:
- [create Secrets using `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/) - [create Secret using `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
- [create Secrets from config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/) - [create Secret from config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
- [create Secrets using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/) - [create Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
## Editing a Secret ## Editing a Secret
@ -1164,7 +1175,7 @@ limit access using [authorization policies](
Secrets often hold values that span a spectrum of importance, many of which can Secrets often hold values that span a spectrum of importance, many of which can
cause escalations within Kubernetes (e.g. service account tokens) and to cause escalations within Kubernetes (e.g. service account tokens) and to
external systems. Even if an individual app can reason about the power of the external systems. Even if an individual app can reason about the power of the
secrets it expects to interact with, other apps within the same namespace can Secrets it expects to interact with, other apps within the same namespace can
render those assumptions invalid. render those assumptions invalid.
For these reasons `watch` and `list` requests for secrets within a namespace are For these reasons `watch` and `list` requests for secrets within a namespace are
@ -1236,10 +1247,8 @@ for secret data, so that the secrets are not stored in the clear into {{< glossa
if the API server policy does not allow that user to read the Secret, the user could if the API server policy does not allow that user to read the Secret, the user could
run a Pod which exposes the secret. run a Pod which exposes the secret.
## {{% heading "whatsnext" %}} ## {{% heading "whatsnext" %}}
- Learn how to [manage Secrets using `kubectl`](/docs/tasks/configmap-secret/managing-secret-using-kubectl/) - Learn how to [manage Secret using `kubectl`](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
- Learn how to [manage Secrets using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/) - Learn how to [manage Secret using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
- Learn how to [manage Secrets using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/) - Learn how to [manage Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)

5
content/en/docs/concepts/overview/working-with-objects/annotations.md
View File

@ -30,6 +30,11 @@ Annotations, like labels, are key/value maps:
} }
``` ```
{{<note>}}
The keys and the values in the map must be strings. In other words, you cannot use
numeric, boolean, list or other types for either the keys or the values.
{{</note>}}
Here are some examples of information that could be recorded in annotations: Here are some examples of information that could be recorded in annotations:
* Fields managed by a declarative configuration layer. Attaching these fields * Fields managed by a declarative configuration layer. Attaching these fields

4
content/en/docs/concepts/workloads/controllers/daemonset.md
View File

@ -230,6 +230,8 @@ storage servers).
Use a Deployment for stateless services, like frontends, where scaling up and down the Use a Deployment for stateless services, like frontends, where scaling up and down the
number of replicas and rolling out updates are more important than controlling exactly which host number of replicas and rolling out updates are more important than controlling exactly which host
the Pod runs on. Use a DaemonSet when it is important that a copy of a Pod always run on the Pod runs on. Use a DaemonSet when it is important that a copy of a Pod always run on
all or certain hosts, and when it needs to start before other Pods. all or certain hosts, if the DaemonSet provides node-level functionality that allows other Pods to run correctly on that particular node.
For example, [network plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) often include a component that runs as a DaemonSet. The DaemonSet component makes sure that the node where it's running has working cluster networking.

3
content/en/docs/concepts/workloads/pods/init-containers.md
View File

@ -291,7 +291,8 @@ Given the ordering and execution for init containers, the following rules
for resource usage apply: for resource usage apply:
* The highest of any particular resource request or limit defined on all init * The highest of any particular resource request or limit defined on all init
containers is the *effective init request/limit* containers is the *effective init request/limit*. If any resource has no
resource limit specified this is considered as the highest limit.
* The Pod's *effective request/limit* for a resource is the higher of: * The Pod's *effective request/limit* for a resource is the higher of:
* the sum of all app containers request/limit for a resource * the sum of all app containers request/limit for a resource
* the effective init request/limit for a resource * the effective init request/limit for a resource

2
content/en/docs/concepts/workloads/pods/pod-lifecycle.md
View File

@ -379,7 +379,7 @@ An example flow:
as terminating (a graceful shutdown duration has been set), the kubelet begins the local Pod as terminating (a graceful shutdown duration has been set), the kubelet begins the local Pod
shutdown process. shutdown process.
1. If one of the Pod's containers has defined a `preStop` 1. If one of the Pod's containers has defined a `preStop`
[hook](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), the kubelet [hook](/docs/concepts/containers/container-lifecycle-hooks), the kubelet
runs that hook inside of the container. If the `preStop` hook is still running after the runs that hook inside of the container. If the `preStop` hook is still running after the
grace period expires, the kubelet requests a small, one-off grace period extension of 2 grace period expires, the kubelet requests a small, one-off grace period extension of 2
seconds. seconds.

15
content/en/docs/contribute/generate-ref-docs/quickstart.md
View File

@ -6,7 +6,7 @@ weight: 40
<!-- overview --> <!-- overview -->
This page shows how to use the `update-imported-docs` script to generate This page shows how to use the `update-imported-docs.py` script to generate
the Kubernetes reference documentation. The script automates the Kubernetes reference documentation. The script automates
the build setup and generates the reference documentation for a release. the build setup and generates the reference documentation for a release.
@ -39,7 +39,7 @@ see the [contributing upstream guide](/docs/contribute/generate-ref-docs/contrib
## Overview of update-imported-docs ## Overview of update-imported-docs
The `update-imported-docs` script is located in the `<web-base>/update-imported-docs/` The `update-imported-docs.py` script is located in the `<web-base>/update-imported-docs/`
directory. directory.
The script builds the following references: The script builds the following references:
@ -48,7 +48,7 @@ The script builds the following references:
* The `kubectl` command reference * The `kubectl` command reference
* The Kubernetes API reference * The Kubernetes API reference
The `update-imported-docs` script generates the Kubernetes reference documentation The `update-imported-docs.py` script generates the Kubernetes reference documentation
from the Kubernetes source code. The script creates a temporary directory from the Kubernetes source code. The script creates a temporary directory
under `/tmp` on your machine and clones the required repositories: `kubernetes/kubernetes` and under `/tmp` on your machine and clones the required repositories: `kubernetes/kubernetes` and
`kubernetes-sigs/reference-docs` into this directory. `kubernetes-sigs/reference-docs` into this directory.
@ -69,7 +69,7 @@ The `generate-command` field defines a series of build instructions
from `kubernetes-sigs/reference-docs/Makefile`. The `K8S_RELEASE` variable from `kubernetes-sigs/reference-docs/Makefile`. The `K8S_RELEASE` variable
determines the version of the release. determines the version of the release.
The `update-imported-docs` script performs the following steps: The `update-imported-docs.py` script performs the following steps:
1. Clones the related repositories specified in a configuration file. For the 1. Clones the related repositories specified in a configuration file. For the
purpose of generating reference docs, the repository that is cloned by purpose of generating reference docs, the repository that is cloned by
@ -152,17 +152,17 @@ For example:
## Running the update-imported-docs tool ## Running the update-imported-docs tool
You can run the `update-imported-docs` tool as follows: You can run the `update-imported-docs.py` tool as follows:
```shell ```shell
cd <web-base>/update-imported-docs cd <web-base>/update-imported-docs
./update-imported-docs <configuration-file.yml> <release-version> ./update-imported-docs.py <configuration-file.yml> <release-version>
``` ```
For example: For example:
```shell ```shell
./update-imported-docs reference.yml 1.17 ./update-imported-docs.py reference.yml 1.17
``` ```
<!-- Revisit: is the release configuration used --> <!-- Revisit: is the release configuration used -->
@ -254,4 +254,3 @@ running the build targets, see the following guides:
* [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/) * [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/)
* [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) * [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/)

2
content/en/docs/reference/_index.md
View File

@ -39,7 +39,7 @@ client libraries:
- [Kubernetes Java client library](https://github.com/kubernetes-client/java) - [Kubernetes Java client library](https://github.com/kubernetes-client/java)
- [Kubernetes JavaScript client library](https://github.com/kubernetes-client/javascript) - [Kubernetes JavaScript client library](https://github.com/kubernetes-client/javascript)
- [Kubernetes C# client library](https://github.com/kubernetes-client/csharp) - [Kubernetes C# client library](https://github.com/kubernetes-client/csharp)
- [Kubernetes Haskell Client library](https://github.com/kubernetes-client/haskell) - [Kubernetes Haskell client library](https://github.com/kubernetes-client/haskell)
## CLI ## CLI

3
content/en/docs/reference/command-line-tools-reference/feature-gates.md
View File

@ -2,6 +2,9 @@
title: Feature Gates title: Feature Gates
weight: 10 weight: 10
content_type: concept content_type: concept
card:
name: reference
weight: 60
--- ---
<!-- overview --> <!-- overview -->

12
content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md
View File

@ -10,7 +10,7 @@ content_type: concept
<!-- overview --> <!-- overview -->
In a Kubernetes cluster, the components on the worker nodes - kubelet and kube-proxy - need to communicate with Kubernetes master components, specifically kube-apiserver. In a Kubernetes cluster, the components on the worker nodes - kubelet and kube-proxy - need to communicate with Kubernetes control plane components, specifically kube-apiserver.
In order to ensure that communication is kept private, not interfered with, and ensure that each component of the cluster is talking to another trusted component, we strongly In order to ensure that communication is kept private, not interfered with, and ensure that each component of the cluster is talking to another trusted component, we strongly
recommend using client TLS certificates on nodes. recommend using client TLS certificates on nodes.
@ -44,7 +44,7 @@ Note that the above process depends upon:
All of the following are responsibilities of whoever sets up and manages the cluster: All of the following are responsibilities of whoever sets up and manages the cluster:
1. Creating the CA key and certificate 1. Creating the CA key and certificate
2. Distributing the CA certificate to the master nodes, where kube-apiserver is running 2. Distributing the CA certificate to the control plane nodes, where kube-apiserver is running
3. Creating a key and certificate for each kubelet; strongly recommended to have a unique one, with a unique CN, for each kubelet 3. Creating a key and certificate for each kubelet; strongly recommended to have a unique one, with a unique CN, for each kubelet
4. Signing the kubelet certificate using the CA key 4. Signing the kubelet certificate using the CA key
5. Distributing the kubelet key and signed certificate to the specific node on which the kubelet is running 5. Distributing the kubelet key and signed certificate to the specific node on which the kubelet is running
@ -90,9 +90,9 @@ In addition, you need your Kubernetes Certificate Authority (CA).
## Certificate Authority ## Certificate Authority
As without bootstrapping, you will need a Certificate Authority (CA) key and certificate. As without bootstrapping, these will be used As without bootstrapping, you will need a Certificate Authority (CA) key and certificate. As without bootstrapping, these will be used
to sign the kubelet certificate. As before, it is your responsibility to distribute them to master nodes. to sign the kubelet certificate. As before, it is your responsibility to distribute them to control plane nodes.
For the purposes of this document, we will assume these have been distributed to master nodes at `/var/lib/kubernetes/ca.pem` (certificate) and `/var/lib/kubernetes/ca-key.pem` (key). For the purposes of this document, we will assume these have been distributed to control plane nodes at `/var/lib/kubernetes/ca.pem` (certificate) and `/var/lib/kubernetes/ca-key.pem` (key).
We will refer to these as "Kubernetes CA certificate and key". We will refer to these as "Kubernetes CA certificate and key".
All Kubernetes components that use these certificates - kubelet, kube-apiserver, kube-controller-manager - assume the key and certificate to be PEM-encoded. All Kubernetes components that use these certificates - kubelet, kube-apiserver, kube-controller-manager - assume the key and certificate to be PEM-encoded.
@ -234,7 +234,7 @@ In order for the controller-manager to sign certificates, it needs the following
### Access to key and certificate ### Access to key and certificate
As described earlier, you need to create a Kubernetes CA key and certificate, and distribute it to the master nodes. As described earlier, you need to create a Kubernetes CA key and certificate, and distribute it to the control plane nodes.
These will be used by the controller-manager to sign the kubelet certificates. These will be used by the controller-manager to sign the kubelet certificates.
Since these signed certificates will, in turn, be used by the kubelet to authenticate as a regular kubelet to kube-apiserver, it is important that the CA Since these signed certificates will, in turn, be used by the kubelet to authenticate as a regular kubelet to kube-apiserver, it is important that the CA
@ -319,7 +319,7 @@ collection.
## kubelet configuration ## kubelet configuration
Finally, with the master nodes properly set up and all of the necessary authentication and authorization in place, we can configure the kubelet. Finally, with the control plane nodes properly set up and all of the necessary authentication and authorization in place, we can configure the kubelet.
The kubelet requires the following configuration to bootstrap: The kubelet requires the following configuration to bootstrap:

2
content/en/docs/reference/tools/_index.md
View File

@ -8,7 +8,7 @@ no_list: true
--- ---
<!-- overview --> <!-- overview -->
Kubernetes contains several built-in tools to help you work with the Kubernetes system. Kubernetes contains several built-in tools and external tools that are commonly used or relevant that may as well be seen as required for Kubernetes to function.
<!-- body --> <!-- body -->

4
content/en/docs/reference/using-api/health-checks.md
View File

@ -25,7 +25,7 @@ The more verbose options shown below are intended to be used by human operators
The following examples will show how you can interact with the health API endpoints. The following examples will show how you can interact with the health API endpoints.
For all endpoints you can use the `verbose` parameter to print out the checks and their status. For all endpoints you can use the `verbose` parameter to print out the checks and their status.
This can be useful for a human operator to debug the current status of the Api server, it is not intended to be consumed by a machine: This can be useful for a human operator to debug the current status of the API server, it is not intended to be consumed by a machine:
```shell ```shell
curl -k https://localhost:6443/livez?verbose curl -k https://localhost:6443/livez?verbose
@ -93,7 +93,7 @@ The output show that the `etcd` check is excluded:
{{< feature-state state="alpha" >}} {{< feature-state state="alpha" >}}
Each individual health check exposes an http endpoint and could can be checked individually. Each individual health check exposes an HTTP endpoint and could can be checked individually.
The schema for the individual health checks is `/livez/<healthcheck-name>` where `livez` and `readyz` and be used to indicate if you want to check the liveness or the readiness of the API server. The schema for the individual health checks is `/livez/<healthcheck-name>` where `livez` and `readyz` and be used to indicate if you want to check the liveness or the readiness of the API server.
The `<healthcheck-name>` path can be discovered using the `verbose` flag from above and take the path between `[+]` and `ok`. The `<healthcheck-name>` path can be discovered using the `verbose` flag from above and take the path between `[+]` and `ok`.
These individual health checks should not be consumed by machines but can be helpful for a human operator to debug a system: These individual health checks should not be consumed by machines but can be helpful for a human operator to debug a system:

3
content/en/docs/setup/best-practices/cluster-large.md
View File

@ -124,3 +124,6 @@ components, including cluster-critical addons.
The [cluster autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme) The [cluster autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)
integrates with a number of cloud providers to help you run the right number of integrates with a number of cloud providers to help you run the right number of
nodes for the level of resource demand in your cluster. nodes for the level of resource demand in your cluster.
The [addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme)
helps you in resizing the addons automatically as your cluster's scale changes.

2
content/en/docs/tasks/administer-cluster/encrypt-data.md
View File

@ -157,7 +157,7 @@ program to retrieve the contents of your secret.
kubectl describe secret secret1 -n default kubectl describe secret secret1 -n default
``` ```
should match `mykey: bXlkYXRh`, mydata is encoded, check [decoding a secret](/docs/concepts/configuration/secret#decoding-a-secret) to should match `mykey: bXlkYXRh`, mydata is encoded, check [decoding a secret](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret) to
completely decode the secret. completely decode the secret.

6
content/en/docs/tasks/administer-cluster/kubelet-config-file.md
View File

@ -30,11 +30,15 @@ Here is an example of what this file might look like:
``` ```
apiVersion: kubelet.config.k8s.io/v1beta1 apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration kind: KubeletConfiguration
address: "192.168.0.8",
port: 20250,
serializeImagePulls: false,
evictionHard: evictionHard:
memory.available: "200Mi" memory.available: "200Mi"
``` ```
In the example, the Kubelet is configured to evict Pods when available memory drops below 200Mi. In the example, the Kubelet is configured to serve on IP address 192.168.0.8 and port 20250, pull images in parallel,
and evict Pods when available memory drops below 200Mi.
All other Kubelet configuration values are left at their built-in defaults, unless overridden All other Kubelet configuration values are left at their built-in defaults, unless overridden
by flags. Command line flags which target the same value as a config file will override that value. by flags. Command line flags which target the same value as a config file will override that value.

2
content/en/docs/tasks/extend-kubernetes/configure-aggregation-layer.md
View File

@ -17,7 +17,7 @@ Configuring the [aggregation layer](/docs/concepts/extend-kubernetes/api-extensi
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{< note >}} {{< note >}}
There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA. There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the Kubernetes general CA.
{{< /note >}} {{< /note >}}
{{< caution >}} {{< caution >}}

2
content/en/docs/tutorials/stateful-application/cassandra.md
View File

@ -50,7 +50,7 @@ To complete this tutorial, you should already have a basic familiarity with
### Additional Minikube setup instructions ### Additional Minikube setup instructions
{{< caution >}} {{< caution >}}
[Minikube](https://minikube.sigs.k8s.io/docs/) defaults to 1024MiB of memory and 1 CPU. [Minikube](https://minikube.sigs.k8s.io/docs/) defaults to 2048MB of memory and 2 CPU.
Running Minikube with the default resource configuration results in insufficient resource Running Minikube with the default resource configuration results in insufficient resource
errors during this tutorial. To avoid these errors, start Minikube with the following settings: errors during this tutorial. To avoid these errors, start Minikube with the following settings:

2
content/en/docs/tutorials/stateless-application/guestbook.md
View File

@ -19,7 +19,7 @@ ready)_, multi-tier web application using Kubernetes and
[Docker](https://www.docker.com/). This example consists of the following [Docker](https://www.docker.com/). This example consists of the following
components: components:
* A single-instance [Redis](https://www.redis.com/) to store guestbook entries * A single-instance [Redis](https://www.redis.io/) to store guestbook entries
* Multiple web frontend instances * Multiple web frontend instances
## {{% heading "objectives" %}} ## {{% heading "objectives" %}}

2
content/it/docs/concepts/cluster-administration/addons.md
View File

@ -26,7 +26,7 @@ I componenti aggiuntivi in ogni sezione sono ordinati alfabeticamente - l'ordine
* [Cilium](https://github.com/cilium/cilium) è un plug-in di criteri di rete e di rete L3 in grado di applicare in modo trasparente le politiche HTTP / API / L7. Sono supportate entrambe le modalità di routing e overlay / incapsulamento. * [Cilium](https://github.com/cilium/cilium) è un plug-in di criteri di rete e di rete L3 in grado di applicare in modo trasparente le politiche HTTP / API / L7. Sono supportate entrambe le modalità di routing e overlay / incapsulamento.
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) consente a Kubernetes di connettersi senza problemi a una scelta di plugin CNI, come Calico, Canal, Flannel, Romana o Weave. * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) consente a Kubernetes di connettersi senza problemi a una scelta di plugin CNI, come Calico, Canal, Flannel, Romana o Weave.
* [Contiv](http://contiv.github.io) offre networking configurabile (L3 nativo con BGP, overlay con vxlan, L2 classico e Cisco-SDN / ACI) per vari casi d'uso e un ricco framework di policy. Il progetto Contiv è completamente [open source](http://github.com/contiv). Il [programma di installazione](http://github.com/contiv/install) fornisce sia opzioni di installazione basate su kubeadm che non su Kubeadm. * [Contiv](http://contiv.github.io) offre networking configurabile (L3 nativo con BGP, overlay con vxlan, L2 classico e Cisco-SDN / ACI) per vari casi d'uso e un ricco framework di policy. Il progetto Contiv è completamente [open source](http://github.com/contiv). Il [programma di installazione](http://github.com/contiv/install) fornisce sia opzioni di installazione basate su kubeadm che non su Kubeadm.
* [Flanella](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) è un provider di reti sovrapposte che può essere utilizzato con Kubernetes. * [Flanell](https://github.com/flannel-io/flannel#deploying-flannel-manually) è un provider di reti sovrapposte che può essere utilizzato con Kubernetes.
* [Knitter](https://github.com/ZTE/Knitter/) è una soluzione di rete che supporta più reti in Kubernetes. * [Knitter](https://github.com/ZTE/Knitter/) è una soluzione di rete che supporta più reti in Kubernetes.
* [Multus](https://github.com/Intel-Corp/multus-cni) è un multi-plugin per il supporto di più reti in Kubernetes per supportare tutti i plugin CNI (es. Calico, Cilium, Contiv, Flannel), oltre a SRIOV, DPDK, OVS-DPDK e carichi di lavoro basati su VPP in Kubernetes. * [Multus](https://github.com/Intel-Corp/multus-cni) è un multi-plugin per il supporto di più reti in Kubernetes per supportare tutti i plugin CNI (es. Calico, Cilium, Contiv, Flannel), oltre a SRIOV, DPDK, OVS-DPDK e carichi di lavoro basati su VPP in Kubernetes.
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) fornisce l'integrazione tra VMware NSX-T e orchestratori di contenitori come Kubernetes, oltre all'integrazione tra NSX-T e piattaforme CaaS / PaaS basate su container come Pivotal Container Service (PKS) e OpenShift. * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) fornisce l'integrazione tra VMware NSX-T e orchestratori di contenitori come Kubernetes, oltre all'integrazione tra NSX-T e piattaforme CaaS / PaaS basate su container come Pivotal Container Service (PKS) e OpenShift.

2
content/zh/docs/concepts/configuration/manage-resources-containers.md
View File

@ -227,7 +227,7 @@ Mi, Ki. For example, the following represent roughly the same value:
## 内存的含义 {#meaning-of-memory} ## 内存的含义 {#meaning-of-memory}
内存的约束和请求以字节为单位。你可以使用以下后缀之一以一般整数或定点数字形式来表示内存： 内存的约束和请求以字节为单位。你可以使用以下后缀之一以一般整数或定点数字形式来表示内存：
E、P、T、G、M、K。你也可以使用对应的 2 的幂数：Ei、Pi、Ti、Gi、Mi、Ki。 E、P、T、G、M、k。你也可以使用对应的 2 的幂数：Ei、Pi、Ti、Gi、Mi、Ki。
例如，以下表达式所代表的是大致相同的值： 例如，以下表达式所代表的是大致相同的值：
``` ```

2
content/zh/docs/tasks/debug-application-cluster/debug-application.md
View File

@ -124,7 +124,7 @@ Once your pod has been scheduled, the methods described in [Debug Running Pods](
#### Pod 处于 Crashing 或别的不健康状态 #### Pod 处于 Crashing 或别的不健康状态
一旦 Pod 被调度，就可以采用 一旦 Pod 被调度，就可以采用
[调试运行中的 Pod](/zh/docs/concepts/configuration/manage-resources-containers/) [调试运行中的 Pod](/zh/docs/tasks/debug-application-cluster/debug-running-pod/)
中的方法来进一步调试。 中的方法来进一步调试。
<!-- <!--