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

Merge remote-tracking branch 'upstream/main' into dev-1.29

This commit is contained in:
Kat Cosgrove 2023-11-27 14:23:58 +00:00
parent cb04844a32 e6677446fe
commit 6440c16724
No known key found for this signature in database
GPG Key ID: 9909DF75A59E4ABC
15 changed files with 301 additions and 80 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@ -5,7 +5,7 @@
This repository contains the assets required to build the [Kubernetes website and documentation](https://kubernetes.io/). We're glad that you want to contribute!
- [Contributing to the docs](#contributing-to-the-docs)
- [Localization READMEs](#localization-readmemds)
- [Localization READMEs](#localization-readmes)
## Using this repository

79
content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
View File

@ -431,3 +431,82 @@ See [Enabling signed kubelet serving certificates](/docs/tasks/administer-cluste
to understand how to configure the kubelets in a kubeadm cluster to have properly signed serving certificates.
Also see [How to run the metrics-server securely](https://github.com/kubernetes-sigs/metrics-server/blob/master/FAQ.md#how-to-run-metrics-server-securely).
## Upgrade fails due to etcd hash not changing
Only applicable to upgrading a control plane node with a kubeadm binary v1.28.3 or later,
where the node is currently managed by kubeadm versions v1.28.0, v1.28.1 or v1.28.2.
Here is the error message you may encounter:
```
[upgrade/etcd] Failed to upgrade etcd: couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced: static Pod hash for component etcd on Node kinder-upgrade-control-plane-1 did not change after 5m0s: timed out waiting for the condition
[upgrade/etcd] Waiting for previous etcd to become available
I0907 10:10:09.109104 3704 etcd.go:588] [etcd] attempting to see if all cluster endpoints ([https://172.17.0.6:2379/ https://172.17.0.4:2379/ https://172.17.0.3:2379/]) are available 1/10
[upgrade/etcd] Etcd was rolled back and is now available
static Pod hash for component etcd on Node kinder-upgrade-control-plane-1 did not change after 5m0s: timed out waiting for the condition
couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced
k8s.io/kubernetes/cmd/kubeadm/app/phases/upgrade.rollbackOldManifests
cmd/kubeadm/app/phases/upgrade/staticpods.go:525
k8s.io/kubernetes/cmd/kubeadm/app/phases/upgrade.upgradeComponent
cmd/kubeadm/app/phases/upgrade/staticpods.go:254
k8s.io/kubernetes/cmd/kubeadm/app/phases/upgrade.performEtcdStaticPodUpgrade
cmd/kubeadm/app/phases/upgrade/staticpods.go:338
...
```
The reason for this failure is that the affected versions generate an etcd manifest file with unwanted defaults in the PodSpec.
This will result in a diff from the manifest comparison, and kubeadm will expect a change in the Pod hash, but the kubelet will never update the hash.
There are two way to workaround this issue if you see it in your cluster:
- The etcd upgrade can be skipped between the affected versions and v1.28.3 (or later) by using:
```shell
kubeadm upgrade {apply|node} [version] --etcd-upgrade=false
```
This is not recommended in case a new etcd version was introduced by a later v1.28 patch version.
- Before upgrade, patch the manifest for the etcd static pod, to remove the problematic defaulted attributes:
```patch
diff --git a/etc/kubernetes/manifests/etcd_defaults.yaml b/etc/kubernetes/manifests/etcd_origin.yaml
index d807ccbe0aa..46b35f00e15 100644
--- a/etc/kubernetes/manifests/etcd_defaults.yaml
+++ b/etc/kubernetes/manifests/etcd_origin.yaml
@@ -43,7 +43,6 @@ spec:
scheme: HTTP
initialDelaySeconds: 10
periodSeconds: 10
- successThreshold: 1
timeoutSeconds: 15
name: etcd
resources:
@@ -59,26 +58,18 @@ spec:
scheme: HTTP
initialDelaySeconds: 10
periodSeconds: 10
- successThreshold: 1
timeoutSeconds: 15
- terminationMessagePath: /dev/termination-log
- terminationMessagePolicy: File
volumeMounts:
- mountPath: /var/lib/etcd
name: etcd-data
- mountPath: /etc/kubernetes/pki/etcd
name: etcd-certs
- dnsPolicy: ClusterFirst
- enableServiceLinks: true
hostNetwork: true
priority: 2000001000
priorityClassName: system-node-critical
- restartPolicy: Always
- schedulerName: default-scheduler
securityContext:
seccompProfile:
type: RuntimeDefault
- terminationGracePeriodSeconds: 30
volumes:
- hostPath:
path: /etc/kubernetes/pki/etcd
```
More information can be found in the [tracking issue](https://github.com/kubernetes/kubeadm/issues/2927) for this bug.

31
content/en/releases/download.md
View File

@ -28,15 +28,11 @@ Find your preferred operating system below.
- [Install kubectl on macOS](/docs/tasks/tools/install-kubectl-macos)
- [Install kubectl on Windows](/docs/tasks/tools/install-kubectl-windows)
## Container Images
## Container images
All Kubernetes container images are deployed to the
`registry.k8s.io` container image registry.
For Kubernetes {{< param "version" >}}, the following
container images are signed using [sigstore](https://sigstore.dev)
signatures:
| Container Image | Supported Architectures |
| ------------------------------------------------------------------------- | --------------------------------- |
| registry.k8s.io/kube-apiserver:v{{< skew currentPatchVersion >}} | amd64, arm, arm64, ppc64le, s390x |
@ -45,6 +41,14 @@ signatures:
| registry.k8s.io/kube-scheduler:v{{< skew currentPatchVersion >}} | amd64, arm, arm64, ppc64le, s390x |
| registry.k8s.io/conformance:v{{< skew currentPatchVersion >}} | amd64, arm, arm64, ppc64le, s390x |
### Container image architectures
All container images are available for multiple architectures, whereas the
container runtime should choose the correct one based on the underlying
platform. It is also possible to pull a dedicated architecture by suffixing the
container image name, for example
`registry.k8s.io/kube-apiserver-arm64:v{{< skew currentPatchVersion >}}`.
### Container image signatures
{{< feature-state for_k8s_version="v1.26" state="beta" >}}
@ -59,16 +63,6 @@ More information about this problem is available in the corresponding
[GitHub issue](https://github.com/kubernetes/registry.k8s.io/issues/187).
{{< /note >}}
### Container image architectures
All container images are available for multiple architectures, whereas the
container runtime should choose the correct one based on the underlying
platform. It is also possible to pull a dedicated architecture by suffixing the
container image name, for example
`registry.k8s.io/kube-apiserver-arm64:v{{< skew currentPatchVersion >}}`. All
those derivations are signed in the same way as the multi-architecture manifest lists.
The Kubernetes project publishes a list of signed Kubernetes container images
in [SPDX 2.3](https://spdx.dev/specifications/) format.
You can fetch that list using:
@ -77,13 +71,12 @@ You can fetch that list using:
curl -Ls "https://sbom.k8s.io/$(curl -Ls https://dl.k8s.io/release/stable.txt)/release" | grep "SPDXID: SPDXRef-Package-registry.k8s.io" | grep -v sha256 | cut -d- -f3- | sed 's/-/\//' | sed 's/-v1/:v1/'
```
For Kubernetes v{{< skew currentVersion >}}, the only kind of code artifact that
you can verify integrity for is a container image, using the experimental
signing support.
To manually verify signed container images of Kubernetes core components, refer to
[Verify Signed Container Images](/docs/tasks/administer-cluster/verify-signed-artifacts).
If you pull a container image for a specific architecture, the single-architecture image
is signed in the same way as for the multi-architecture manifest lists.
## Binaries
{{< release-binaries >}}

12
content/it/docs/tutorials/_index.md
View File

@ -21,9 +21,7 @@ Prima di procedere con vari tutorial, raccomandiamo di aggiungere il
## Per cominciare
* [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) è un approfondito tutorial che aiuta a capire cosa è Kubernetes e che permette di testare in modo interattivo alcune semplici funzionalità di Kubernetes.
* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#)
* [Hello Minikube](/docs/tutorials/hello-minikube/)
## Configurazione
@ -33,36 +31,26 @@ Prima di procedere con vari tutorial, raccomandiamo di aggiungere il
## Stateless Applications
* [Esporre un External IP Address per permettere l'accesso alle applicazioni nel Cluster](/docs/tutorials/stateless-application/expose-external-ip-address/)
* [Esempio: Rilasciare l'applicazione PHP Guestbook con Redis](/docs/tutorials/stateless-application/guestbook/)
## Stateful Applications
* [StatefulSet Basics](/docs/tutorials/stateful-application/basic-stateful-set/)
* [Esempio: WordPress e MySQL con i PersistentVolumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)
* [Esempio: Rilasciare Cassandra con i StatefulSets](/docs/tutorials/stateful-application/cassandra/)
* [Eseguire ZooKeeper, un sistema distribuito CP](/docs/tutorials/stateful-application/zookeeper/)
## Clusters
* [AppArmor](/docs/tutorials/clusters/apparmor/)
* [Seccomp](/docs/tutorials/clusters/seccomp/)
## Servizi
* [Utilizzare Source IP](/docs/tutorials/services/source-ip/)
## {{% heading "whatsnext" %}}
Se sei interessato a scrivere un tutorial, vedi
[Utilizzare i Page Templates](/docs/home/contribute/page-templates/)
per informazioni su come creare una tutorial page e sul tutorial template.

49
content/pl/releases/download.md Normal file
View File

@ -0,0 +1,49 @@
---
title: Ściągnij Kubernetesa
type: docs
---
Klaster Kubernetesa dostępny jest w formie plików binarnych dla każdego z jego komponentów i zestawu standardowych aplikacji klienckich wspomagających proces jego szybkiego rozruchu lub obsługi. Składniki Kubernetesa takie jak serwer API mogą być uruchamiane z poziomu obrazów kontenerowych wewnątrz klastra - te ostatnie są także częścią oficjalnego wydania Kubernetesa. Wszystkie pliki binarne i obrazy kontenerowe Kubernetesa udostępniane są dla różnych systemów operacyjnych i architektur sprzętowych.
### kubectl
<!--overview-->
[kubectl](/docs/reference/kubectl/kubectl/) to narzędzie powłoki umożliwiające wykonywanie komend w klastrze Kubernetesa służących do m.in. uruchamiania aplikacji, zarządzania zasobami klastra i przeglądania logów. Więcej informacji na temat kubectl, w tym pełną list operacji, jakie możesz za jego pomocą wykonać, znajdziesz w [Dokumentacji `kubectl`](/docs/reference/kubectl/).
kubectl można zainstalować w rozmaitych systemach z rodziny Linuxa, jak również w systemach macOS i Windows. Niżej znajdziesz odnośniki do instrukcji instalacji dla preferowanego przez siebie systemu:
- [Instalacja kubectl w Linuxie](/docs/tasks/tools/install-kubectl-linux)
- [Instalacja kubectl w macOS-ie](/docs/tasks/tools/install-kubectl-macos)
- [Instalacja kubectl w Windowsie](/docs/tasks/tools/install-kubectl-windows)
## Obrazy kontenerów
Wszystkie obrazy kontenerowe umieszczane są w rejestrze `registry.k8s.io`.
{{< feature-state for_k8s_version="v1.24" state="alpha" >}}
Dla wersji Kubernetesa {{< param "version">}} następujące obrazy kontenerów opatrzone są podpisem [cosign](https://github.com/sigstore/cosign):
| Obraz kontenera | Wspierana architektura |
| ------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| registry.k8s.io/kube-apiserver:v{{< skew currentPatchVersion >}} | amd64, arm, arm64, ppc64le, s390x |
| registry.k8s.io/kube-controller-manager:v{{< skew currentPatchVersion >}} | amd64, arm, arm64, ppc64le, s390x |
| registry.k8s.io/kube-proxy:v{{< skew currentPatchVersion >}} | amd64, arm, arm64, ppc64le, s390x |
| registry.k8s.io/kube-scheduler:v{{< skew currentPatchVersion >}} | amd64, arm, arm64, ppc64le, s390x |
| registry.k8s.io/conformance:v{{< skew currentPatchVersion >}} | amd64, arm, arm64, ppc64le, s390x |
Obrazy kontenerów Kubernetesa obsługują rozmaite architektury sprzętowe, ich wyboru powinno zaś dokonać środowisko uruchomieniowe w zależności od wybranej platformy. Istnieje też możliwość pobrania obrazu kontenera dla konkretnej architektury poprzez dodanie do jego nazwy odpowiedniego przyrostka, np. `registry.k8s.io/kube-apiserver-arm64:v{{< skew currentPatchVersion >}}`. Wszystkie te warianty obrazów Kubernetesa są podpisane w taki sam sposób jak w przypadku listy manifestów wieloarchitekturowych.
Wydawcy Kubernetesa publikują listę podpisanych obrazów kontenerowych w formacie [SPDX 2.3](https://spdx.dev/specifications/). Możesz ją pobrać wpisując w powłoce:
```shell
curl -Ls "https://sbom.k8s.io/$(curl -Ls https://dl.k8s.io/release/stable.txt)/release" | grep "SPDXID: SPDXRef-Package-registry.k8s.io" | grep -v sha256 | cut -d- -f3- | sed 's/-/\//' | sed 's/-v1/:v1/'
```
Dla wersji {{< skew currentVersion >}} Kubernetesa jedynym typem artefaktu kodu, którego integralność możesz zweryfikować, jest obraz kontenera (korzystając z eksperymentalnej opcji podpisu).
By ręcznie zweryfikować podpisane obrazy kontenerów głównych komponentów Kubernetesa, zobacz [Zweryfikuj podpisane obrazy kontenerów](/docs/tasks/administer-cluster/verify-signed-artifacts).
## Pliki binarne
{{< release-binaries >}}

15
content/zh-cn/docs/concepts/configuration/secret.md
View File

@ -1579,6 +1579,21 @@ Therefore, one Pod does not have access to the Secrets of another Pod.
针对同一节点上的多个 Pod 可能有多个 Secret。不过，只有某个 Pod 所请求的 Secret
才有可能对 Pod 中的容器可见。因此，一个 Pod 不会获得访问其他 Pod 的 Secret 的权限。
<!--
### Configure least-privilege access to Secrets
To enhance the security measures around Secrets, Kubernetes provides a mechanism: you can
annotate a ServiceAccount as `kubernetes.io/enforce-mountable-secrets: "true"`.
For more information, you can refer to the [documentation about this annotation](/docs/concepts/security/service-accounts/#enforce-mountable-secrets).
-->
### 配置 Secret 资源的最小特权访问
为了加强对 Secret 的安全措施，Kubernetes 提供了一种机制：
你可以为 ServiceAccount 添加 `kubernetes.io/enforce-mountable-secrets: "true"` 注解。
想了解更多信息，你可以参考[此注解的文档](/zh-cn/docs/concepts/security/service-accounts/#enforce-mountable-secrets)。
{{< warning >}}
<!--
Any containers that run with `privileged: true` on a node can access all

6
content/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction.md
View File

@ -158,7 +158,8 @@ like `free -m`. This is important because `free -m` does not work in a
container, and if users use the [node allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
feature, out of resource decisions
are made local to the end user Pod part of the cgroup hierarchy as well as the
root node. This [script](/examples/admin/resource/memory-available.sh)
root node. This [script](/examples/admin/resource/memory-available.sh) or
[cgroupv2 script](/examples/admin/resource/memory-available-cgroupv2.sh)
reproduces the same set of steps that the kubelet performs to calculate
`memory.available`. The kubelet excludes inactive_file (the number of bytes of
file-backed memory on inactive LRU list) from its calculation as it assumes that
@ -168,7 +169,8 @@ memory is reclaimable under pressure.
这很重要，因为 `free -m` 在容器中不起作用，如果用户使用
[节点可分配资源](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
这一功能特性，资源不足的判定是基于 cgroup 层次结构中的用户 Pod 所处的局部及 cgroup 根节点作出的。
这个[脚本](/zh-cn/examples/admin/resource/memory-available.sh)
这个[脚本](/zh-cn/examples/admin/resource/memory-available.sh)或者
[cgroupv2 脚本](/zh-cn/examples/admin/resource/memory-available-cgroupv2.sh)
重现了 kubelet 为计算 `memory.available` 而执行的相同步骤。
kubelet 在其计算中排除了 inactive_file（非活动 LRU 列表上基于文件来虚拟的内存的字节数），
因为它假定在压力下内存是可回收的。

18
content/zh-cn/docs/concepts/security/secrets-good-practices.md
View File

@ -24,8 +24,8 @@ application developers. Use these guidelines to improve the security of your
sensitive information in Secret objects, as well as to more effectively manage
your Secrets.
-->
以下良好实践适用于集群管理员和应用开发者。遵从这些指导方针有助于提高 Secret 对象中敏感信息的安全性，
还可以更有效地管理你的 Secret。
以下良好实践适用于集群管理员和应用开发者。遵从这些指导方针有助于提高 Secret
对象中敏感信息的安全性，还可以更有效地管理你的 Secret。
<!-- body -->
@ -112,6 +112,20 @@ recommendations include:
* 使用生命期短暂的 Secret
* 实现对特定事件发出警报的审计规则，例如同一用户并发读取多个 Secret 时发出警报
<!--
#### Additional ServiceAccount annotations for Secret management
You can also use the `kubernetes.io/enforce-mountable-secrets` annotation on
a ServiceAccount to enforce specific rules on how Secrets are used in a Pod.
For more details, see the [documentation on this annotation](/docs/reference/labels-annotations-taints/#enforce-mountable-secrets).
-->
#### 用于 Secret 管理的附加 ServiceAccount 注解
你还可以在 ServiceAccount 上使用 `kubernetes.io/enforce-mountable-secrets`
注解来强制执行有关如何在 Pod 中使用 Secret 的特定规则。
更多详细信息，请参阅[有关此注解的文档](/zh-cn/docs/reference/labels-annotations-taints/#enforce-mountable-secrets)。
<!--
### Improve etcd management policies

59
content/zh-cn/docs/concepts/security/service-accounts.md
View File

@ -374,6 +374,65 @@ You can also use TokenRequest to obtain short-lived tokens for your external app
你还可以使用 TokenRequest 为外部应用获取短期的令牌。
{{< /note >}}
<!--
### Restricting access to Secrets {#enforce-mountable-secrets}
-->
### 限制对 Secret 的访问 {#enforce-mountable-secrets}
<!--
Kubernetes provides an annotation called `kubernetes.io/enforce-mountable-secrets`
that you can add to your ServiceAccounts. When this annotation is applied,
the ServiceAccount's secrets can only be mounted on specified types of resources,
enhancing the security posture of your cluster.
You can add the annotation to a ServiceAccount using a manifest:
-->
Kubernetes 提供了名为 `kubernetes.io/enforce-mountable-secrets` 的注解，
你可以添加到你的 ServiceAccount 中。当应用了这个注解后，
ServiceAccount 的 Secret 只能挂载到特定类型的资源上，从而增强集群的安全性。
你可以使用以下清单将注解添加到一个 ServiceAccount 中：
```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
kubernetes.io/enforce-mountable-secrets: "true"
name: my-serviceaccount
namespace: my-namespace
```
<!--
When this annotation is set to "true", the Kubernetes control plane ensures that
the Secrets from this ServiceAccount are subject to certain mounting restrictions.
-->
当此注解设置为 "true" 时，Kubernetes 控制平面确保来自该 ServiceAccount 的 Secret 受到特定挂载限制。
<!--
1. The name of each Secret that is mounted as a volume in a Pod must appear in the `secrets` field of the
Pod's ServiceAccount.
-->
1. 在 Pod 中作为卷挂载的每个 Secret 的名称必须列在该 Pod 中 ServiceAccount 的 `secrets` 字段中。
<!--
1. The name of each Secret referenced using `envFrom` in a Pod must also appear in the `secrets`
field of the Pod's ServiceAccount.
-->
2. 在 Pod 中使用 `envFrom` 引用的每个 Secret 的名称也必须列在该 Pod 中 ServiceAccount 的 `secrets` 字段中。
<!--
1. The name of each Secret referenced using `imagePullSecrets` in a Pod must also appear in the `secrets`
field of the Pod's ServiceAccount.
-->
3. 在 Pod 中使用 `imagePullSecrets` 引用的每个 Secret 的名称也必须列在该 Pod 中
ServiceAccount 的 `secrets` 字段中。
<!--
By understanding and enforcing these restrictions, cluster administrators can maintain a tighter security profile and ensure that secrets are accessed only by the appropriate resources.
-->
通过理解并执行这些限制，集群管理员可以维护更严格的安全配置，并确保 Secret 仅被适当的资源访问。
<!--
## Authenticating service account credentials {#authenticating-credentials}
-->

2
content/zh-cn/docs/concepts/services-networking/network-policies.md
View File

@ -52,7 +52,7 @@ The entities that a Pod can communicate with are identified through a combinatio
3. IP blocks (exception: traffic to and from the node where a Pod is running is always allowed,
regardless of the IP address of the Pod or the node)
-->
Pod 可以通信的 Pod 是通过如下三个标识符的组合来辩识的：
Pod 可以与之通信的实体是通过如下三个标识符的组合来辩识的：
1. 其他被允许的 Pods（例外：Pod 无法阻塞对自身的访问）
2. 被允许的名字空间

8
content/zh-cn/docs/contribute/participate/issue-wrangler.md
View File

@ -14,12 +14,12 @@ weight: 20
<!--
Alongside the [PR Wrangler](/docs/contribute/participate/pr-wranglers),formal approvers,
and reviewers, members of SIG Docs take week long shifts
[triaging and categorising issues](/docs/contribute/review/for-approvers.md/#triage-and-categorize-issues)
[triaging and categorising issues](/docs/contribute/review/for-approvers/#triage-and-categorize-issues)
for the repository.
-->
除了承担 [PR 管理者](/zh-cn/docs/contribute/participate/pr-wranglers)的职责外，
SIG Docs 正式的批准人（Approver）、评审人（Reviewer）和成员（Member）
按周轮流[归类仓库的 Issue](/zh-cn/docs/contribute/review/for-approvers.md/#triage-and-categorize-issues)。
按周轮流[归类仓库的 Issue](/zh-cn/docs/contribute/review/for-approvers/#triage-and-categorize-issues)。
<!-- body -->
@ -29,7 +29,7 @@ SIG Docs 正式的批准人（Approver）、评审人（Reviewer）和成员（M
Each day in a week-long shift the Issue Wrangler will be responsible for:
- Triaging and tagging incoming issues daily. See
[Triage and categorize issues](/docs/contribute/review/for-approvers.md/#triage-and-categorize-issues)
[Triage and categorize issues](/docs/contribute/review/for-approvers/#triage-and-categorize-issues)
for guidelines on how SIG Docs uses metadata.
- Keeping an eye on stale & rotten issues within the kubernetes/website repository.
- Maintenance of the [Issues board](https://github.com/orgs/kubernetes/projects/72/views/1).
@ -39,7 +39,7 @@ Each day in a week-long shift the Issue Wrangler will be responsible for:
在为期一周的轮值期内，Issue 管理者每天负责：
- 对收到的 Issue 进行日常分类和标记。有关 SIG Docs 如何使用元数据的指导说明，
参阅[归类 Issue](/zh-cn/docs/contribute/review/for-approvers.md/#triage-and-categorize-issues)。
参阅[归类 Issue](/zh-cn/docs/contribute/review/for-approvers/#triage-and-categorize-issues)。
- 密切关注 kubernetes/website 代码仓库中陈旧和过期的 Issue。
- 维护 [Issues 看板](https://github.com/orgs/kubernetes/projects/72/views/1)。

10
content/zh-cn/docs/reference/access-authn-authz/admission-controllers.md
View File

@ -1494,6 +1494,16 @@ You should enable this admission controller if you intend to make any use of Kub
的自动化。强烈推荐为 Kubernetes 项目启用此准入控制器。
如果你打算使用 Kubernetes 的 `ServiceAccount` 对象，你应启用这个准入控制器。
<!--
Regarding the annotation `kubernetes.io/enforce-mountable-secrets`: While the annotation's name suggests it only concerns the mounting of Secrets,
its enforcement also extends to other ways Secrets are used in the context of a Pod.
Therefore, it is crucial to ensure that all the referenced secrets are correctly specified in the ServiceAccount.
-->
关于 `kubernetes.io/enforce-mountable-secrets` 注解：尽管注解的名称表明它只涉及 Secret 的挂载，
但其执行范围也扩展到 Pod 上下文中 Secret 的其他使用方式。
因此，确保所有引用的 Secret 在 ServiceAccount 中被正确指定是至关重要的。
### StorageObjectInUseProtection {#storageobjectinuseprotection}
<!--

16
content/zh-cn/docs/reference/config-api/apiserver-encryption.v1.md
View File

@ -1,5 +1,5 @@
---
title: kube-apiserver 加密配置 (v1)
title: kube-apiserver 加密配置（v1）
content_type: tool-reference
package: apiserver.config.k8s.io/v1
auto_generated: true
@ -29,8 +29,8 @@ Package v1 is the v1 version of the API.
## `EncryptionConfiguration` {#apiserver-config-k8s-io-v1-EncryptionConfiguration}
<!--
Use '<em>.<!!-- raw HTML omitted -->' to encrypt all resources within a group or '</em>.<em>' to encrypt all resources.
'</em>.' can be used to encrypt all resource in the core group. '<em>.</em>' will encrypt all
Use '&ast;&lt;group&gt;o encrypt all resources within a group or '&ast;.&ast;' to encrypt all resources.
'&ast;.' can be used to encrypt all resource in the core group. '&ast;.&ast;' will encrypt all
resources, even custom resources that are added after API server start.
Use of wildcards that overlap within the same resource list or across multiple
entries are not allowed since part of the configuration would be ineffective.
@ -232,7 +232,7 @@ KMSConfiguration 包含基于 KMS 的封套转换器的名称、缓存大小以
<!--
timeout for gRPC calls to kms-plugin (ex. 5s). The default is 3 seconds.
-->
对 KMS 插件执行 gRPC 调用的超时时长（例如，'5s'）。默认值为 3 秒。
对 KMS 插件执行 gRPC 调用的超时时长（例如：'5s'）。默认值为 3 秒。
</p>
</td>
</tr>
@ -398,9 +398,9 @@ ResourceConfiguration 中保存资源配置。
<!--
resources is a list of kubernetes resources which have to be encrypted. The resource names are derived from <code>resource</code> or <code>resource.group</code> of the group/version/resource.
eg: pandas.awesome.bears.example is a custom resource with 'group': awesome.bears.example, 'resource': pandas.
Use '<em>.</em>' to encrypt all resources and '<em>.< raw HTML omitted >' to encrypt all resources in a specific group.
eg: '</em>.awesome.bears.example' will encrypt all resources in the group 'awesome.bears.example'.
eg: '*.' will encrypt all resources in the core group (such as pods, configmaps, etc).</p>
Use '&ast;.&ast;' to encrypt all resources and '&ast;.&lt;group&gt;' to encrypt all resources in a specific group.
eg: '&ast;.awesome.bears.example' will encrypt all resources in the group 'awesome.bears.example'.
eg: '&ast;.' will encrypt all resources in the core group (such as pods, configmaps, etc).</p>
-->
<code>resources</code> 是必须要加密的 Kubernetes 资源的列表。
资源名称来自于组/版本/资源的 <code>resource</code> 或 <code>resource.group</code>。
@ -457,7 +457,7 @@ SecretboxConfiguration 包含用于某 Secretbox 转换器的 API 配置。
keys is a list of keys to be used for creating the Secretbox transformer.
Each key has to be 32 bytes long.
-->
<code>keys</code> 是一个密钥列表，用来创建 Secretbox 转换器。每个密钥必须是 32 字节长。
<code>keys</code> 是一个密钥列表，用来创建 Secretbox 转换器。每个密钥长度必须是 32 字节。
</p>
</td>
</tr>

8
content/zh-cn/docs/tutorials/_index.md
View File

@ -33,9 +33,7 @@ Kubernetes 文档的这一部分包含教程。
## Basics
* [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) is an in-depth interactive tutorial that helps you understand the Kubernetes system and try out some basic Kubernetes features.
* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#)
* [Hello Minikube](/docs/tutorials/hello-minikube/)
-->
## 基础知识 {#basics}
@ -49,7 +47,6 @@ Kubernetes 文档的这一部分包含教程。
## Configuration
* [Example: Configuring a Java Microservice](/docs/tutorials/configuration/configure-java-microservice/)
* [Configuring Redis Using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/)
-->
## 配置 {#configuration}
@ -61,7 +58,6 @@ Kubernetes 文档的这一部分包含教程。
## Stateless Applications
* [Exposing an External IP Address to Access an Application in a Cluster](/docs/tutorials/stateless-application/expose-external-ip-address/)
* [Example: Deploying PHP Guestbook application with MongoDB](/docs/tutorials/stateless-application/guestbook/)
-->
## 无状态应用程序 {#stateless-applications}
@ -73,11 +69,8 @@ Kubernetes 文档的这一部分包含教程。
## Stateful Applications
* [StatefulSet Basics](/docs/tutorials/stateful-application/basic-stateful-set/)
* [Example: WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)
* [Example: Deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/)
* [Running ZooKeeper, A CP Distributed System](/docs/tutorials/stateful-application/zookeeper/)
-->
## 有状态应用程序 {#stateful-applications}
@ -122,4 +115,3 @@ for information about the tutorial page.
-->
如果你要编写教程，请参阅[内容页面类型](/zh-cn/docs/contribute/style/page-content-types/)
以获取有关教程页面类型的信息。

66
content/zh-cn/releases/download.md
View File

@ -55,7 +55,7 @@ kubectl 可安装在各种 Linux 平台、macOS 和 Windows 上。
- [在 Windows 上安装 kubectl](/zh-cn/docs/tasks/tools/install-kubectl-windows)
<!--
## Container Images
## Container images
All Kubernetes container images are deployed to the
`registry.k8s.io` container image registry.
@ -64,39 +64,59 @@ All Kubernetes container images are deployed to the
所有 Kubernetes 容器镜像都被部署到 `registry.k8s.io` 容器镜像仓库。
{{< feature-state for_k8s_version="v1.24" state="alpha" >}}
<!--
For Kubernetes {{< param "version" >}}, the following
container images are signed using [cosign](https://github.com/sigstore/cosign)
signatures:
| Container Image | Supported Architectures |
-->
对于 Kubernetes {{< param "version" >}}，以下容器镜像使用
[cosign](https://github.com/sigstore/cosign) 进行签名：
<!--
| Container Image | Supported Architectures |
-->
| 容器镜像 | 支持架构 |
| ------------------------------------------------------------------- | --------------------------------- |
| 容器镜像 | 支持架构 |
| ------------------------------------------------------------------------- | --------------------------------- |
| registry.k8s.io/kube-apiserver:v{{< skew currentPatchVersion >}} | amd64, arm, arm64, ppc64le, s390x |
| registry.k8s.io/kube-controller-manager:v{{< skew currentPatchVersion >}} | amd64, arm, arm64, ppc64le, s390x |
| registry.k8s.io/kube-proxy:v{{< skew currentPatchVersion >}} | amd64, arm, arm64, ppc64le, s390x |
| registry.k8s.io/kube-scheduler:v{{< skew currentPatchVersion >}} | amd64, arm, arm64, ppc64le, s390x |
| registry.k8s.io/conformance:v{{< skew currentPatchVersion >}} | amd64, arm, arm64, ppc64le, s390x |
<!--
### Container image architectures
-->
### 容器镜像架构
<!--
All container images are available for multiple architectures, whereas the
container runtime should choose the correct one based on the underlying
platform. It is also possible to pull a dedicated architecture by suffixing the
container image name, for example
`registry.k8s.io/kube-apiserver-arm64:v{{< skew currentPatchVersion >}}`. All
those derivations are signed in the same way as the multi-architecture manifest lists.
`registry.k8s.io/kube-apiserver-arm64:v{{< skew currentPatchVersion >}}`.
-->
所有容器镜像都支持多架构，而容器运行时应根据下层平台选择正确的镜像。
也可以通过给容器镜像名称加后缀来拉取适合特定架构的镜像，例如
`registry.k8s.io/kube-apiserver-arm64:v{{< skew currentPatchVersion >}}`。
所有这些派生镜像都以与多架构清单列表相同的方式签名。
<!--
### Container image signatures
-->
### 容器镜像签名
{{< feature-state for_k8s_version="v1.26" state="beta" >}}
<!--
For Kubernetes {{< param "version" >}},
container images are signed using [sigstore](https://sigstore.dev)
signatures:
-->
对于 Kubernetes {{< param "version" >}}，容器镜像使用
[sigstore](https://sigstore.dev) 进行签名：
{{< note >}}
<!--
Container image sigstore signatures do currently not match between different geographical locations.
More information about this problem is available in the corresponding
[GitHub issue](https://github.com/kubernetes/registry.k8s.io/issues/187).
-->
目前，不同地理位置之间的容器镜像 sigstore 签名不匹配。
有关此问题的更多信息，请参阅相应的
[GitHub Issue](https://github.com/kubernetes/registry.k8s.io/issues/187)。
{{< /note >}}
<!--
The Kubernetes project publishes a list of signed Kubernetes container images
@ -111,18 +131,18 @@ curl -Ls "https://sbom.k8s.io/$(curl -Ls https://dl.k8s.io/release/stable.txt)/r
```
<!--
For Kubernetes v{{< skew currentVersion >}}, the only kind of code artifact that
you can verify integrity for is a container image, using the experimental
signing support.
To manually verify signed container images of Kubernetes core components, refer to
[Verify Signed Container Images](/docs/tasks/administer-cluster/verify-signed-artifacts).
-->
对于 Kubernetes v{{< skew currentVersion >}}，唯一可以验证完整性的代码工件就是容器镜像，它使用实验性签名支持。
如需手动验证 Kubernetes 核心组件的签名容器镜像，
请参考[验证签名容器镜像](/zh-cn/docs/tasks/administer-cluster/verify-signed-artifacts)。
<!--
If you pull a container image for a specific architecture, the single-architecture image
is signed in the same way as for the multi-architecture manifest lists.
-->
如果你要拉取特定架构的容器镜像，则单架构镜像的签名方式与多架构清单列表相同。
<!--
## Binaries
-->