From f875adcb500325a1911c8cdb6cb883f51b8d7b96 Mon Sep 17 00:00:00 2001 From: James Sturtevant Date: Fri, 29 Apr 2022 10:55:13 -0700 Subject: [PATCH 01/25] Refresh kubeadm docs for Windows --- .../tools/kubeadm/create-cluster-kubeadm.md | 4 + .../kubeadm/adding-windows-nodes.md | 256 ------------------ .../kubeadm/upgrading-windows-nodes.md | 27 +- 3 files changed, 20 insertions(+), 267 deletions(-) delete mode 100644 content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md 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 d7897dfec5..d70056e71f 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 @@ -336,6 +336,10 @@ The nodes are where your workloads (containers and Pods, etc) run. To add new no kubeadm join --token : --discovery-token-ca-cert-hash sha256: ``` +{{< note >}} +On Windows you should specify the `--cri-socket` parameter in the `kubeadm join` command. The default path is "npipe:////./pipe/containerd-containerd" for containerd. +{{< /note >}} + If you do not have the token, you can get it by running the following command on the control-plane node: ```bash diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md deleted file mode 100644 index 30dd5c4cb0..0000000000 --- a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md +++ /dev/null @@ -1,256 +0,0 @@ ---- -reviewers: -- jayunit100 -- jsturtevant -- marosset -- perithompson -title: Adding Windows nodes -min-kubernetes-server-version: 1.17 -content_type: tutorial -weight: 30 ---- - - - -{{< feature-state for_k8s_version="v1.18" state="beta" >}} - -You can use Kubernetes to run a mixture of Linux and Windows nodes, so you can mix Pods that run on Linux on with Pods that run on Windows. This page shows how to register Windows nodes to your cluster. - - -## {{% heading "prerequisites" %}} - {{< version-check >}} - -* Obtain a [Windows Server 2019 license](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) -(or higher) in order to configure the Windows node that hosts Windows containers. -If you are using VXLAN/Overlay networking you must have also have [KB4489899](https://support.microsoft.com/help/4489899) installed. - -* A Linux-based Kubernetes kubeadm cluster in which you have access to the control plane (see [Creating a single control-plane cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)). - - - - -## {{% heading "objectives" %}} - - -* Register a Windows node to the cluster -* Configure networking so Pods and Services on Linux and Windows can communicate with each other - - - - - - -## Getting Started: Adding a Windows Node to Your Cluster - -### Networking Configuration - -Once you have a Linux-based Kubernetes control-plane node you are ready to choose a networking solution. This guide illustrates using Flannel in VXLAN mode for simplicity. - -#### Configuring Flannel - -1. Prepare Kubernetes control plane for Flannel - - Some minor preparation is recommended on the Kubernetes control plane in our cluster. It is recommended to enable bridged IPv4 traffic to iptables chains when using Flannel. The following command must be run on all Linux nodes: - - ```bash - sudo sysctl net.bridge.bridge-nf-call-iptables=1 - ``` - -1. Download & configure Flannel for Linux - - Download the most recent Flannel manifest: - - ```bash - wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml - ``` - - Modify the `net-conf.json` section of the flannel manifest in order to set the VNI to 4096 and the Port to 4789. It should look as follows: - - ```json - net-conf.json: | - { - "Network": "10.244.0.0/16", - "Backend": { - "Type": "vxlan", - "VNI": 4096, - "Port": 4789 - } - } - ``` - - {{< note >}}The VNI must be set to 4096 and port 4789 for Flannel on Linux to interoperate with Flannel on Windows. See the [VXLAN documentation](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan). - for an explanation of these fields.{{< /note >}} - - {{< note >}}To use L2Bridge/Host-gateway mode instead change the value of `Type` to `"host-gw"` and omit `VNI` and `Port`.{{< /note >}} - -1. Apply the Flannel manifest and validate - - Let's apply the Flannel configuration: - - ```bash - kubectl apply -f kube-flannel.yml - ``` - - After a few minutes, you should see all the pods as running if the Flannel pod network was deployed. - - ```bash - kubectl get pods -n kube-system - ``` - - The output should include the Linux flannel DaemonSet as running: - - ``` - NAMESPACE NAME READY STATUS RESTARTS AGE - ... - kube-system kube-flannel-ds-54954 1/1 Running 0 1m - ``` - -1. Add Windows Flannel and kube-proxy DaemonSets - - Now you can add Windows-compatible versions of Flannel and kube-proxy. In order - to ensure that you get a compatible version of kube-proxy, you'll need to substitute - the tag of the image. The following example shows usage for Kubernetes {{< param "fullversion" >}}, - but you should adjust the version for your own deployment. - - ```bash - curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f - - kubectl apply -f https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml - ``` - {{< note >}} - If you're using host-gateway use https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-host-gw.yml instead - {{< /note >}} - - {{< note >}} -If you're using a different interface rather than Ethernet (i.e. "Ethernet0 2") on the Windows nodes, you have to modify the line: - -```powershell -wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet" -``` - -in the `flannel-host-gw.yml` or `flannel-overlay.yml` file and specify your interface accordingly. - -```bash -# Example -curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml | sed 's/Ethernet/Ethernet0 2/g' | kubectl apply -f - -``` - {{< /note >}} - - - -### Joining a Windows worker node - -{{< note >}} -All code snippets in Windows sections are to be run in a PowerShell environment -with elevated permissions (Administrator) on the Windows worker node. -{{< /note >}} - -{{< tabs name="tab-windows-kubeadm-runtime-installation" >}} - -{{% tab name="CRI-containerD" %}} - -#### Install containerD - -```powershell -curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/Install-Containerd.ps1 -.\Install-Containerd.ps1 -``` - -{{< note >}} -To install a specific version of containerD specify the version with -ContainerDVersion. - -```powershell -# Example -.\Install-Containerd.ps1 -ContainerDVersion 1.4.1 -``` - -If you're using a different interface rather than Ethernet (i.e. "Ethernet0 2") on the Windows nodes, specify the name with `-netAdapterName`. - -```powershell -# Example -.\Install-Containerd.ps1 -netAdapterName "Ethernet0 2" -``` - -{{< /note >}} - -#### Install wins, kubelet, and kubeadm - -```PowerShell -curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1 -.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} -ContainerRuntime containerD -``` - -Install `crictl` from the [cri-tools project](https://github.com/kubernetes-sigs/cri-tools) -which is required so that kubeadm can talk to the CRI endpoint. - -#### Run `kubeadm` to join the node - -Use the command that was given to you when you ran `kubeadm init` on a control plane host. -If you no longer have this command, or the token has expired, you can run `kubeadm token create --print-join-command` -(on a control plane host) to generate a new token and join command. - -{{% /tab %}} - -{{% tab name="Docker Engine" %}} - -#### Install Docker Engine - -Install the `Containers` feature - -```powershell -Install-WindowsFeature -Name containers -``` - -Install Docker -Instructions to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/set-up-environment?tabs=Windows-Server#install-docker). - -[Install cri-dockerd](https://github.com/Mirantis/cri-dockerd) which is required so that the kubelet -can communicate with Docker on a CRI compatible endpoint. - -{{< note >}} -Docker Engine does not implement the [CRI](/docs/concepts/architecture/cri/) -which is a requirement for a container runtime to work with Kubernetes. -For that reason, an additional service [cri-dockerd](https://github.com/Mirantis/cri-dockerd) -has to be installed. cri-dockerd is a project based on the legacy built-in -Docker Engine support that was [removed](/dockershim) from the kubelet in version 1.24. -{{< /note >}} - -Install `crictl` from the [cri-tools project](https://github.com/kubernetes-sigs/cri-tools) -which is required so that kubeadm can talk to the CRI endpoint. - -#### Install wins, kubelet, and kubeadm - -```PowerShell -curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1 -.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} -``` - -#### Run `kubeadm` to join the node - -Use the command that was given to you when you ran `kubeadm init` on a control plane host. -If you no longer have this command, or the token has expired, you can run `kubeadm token create --print-join-command` -(on a control plane host) to generate a new token and join command. - -{{% /tab %}} - -{{< /tabs >}} - -### Verifying your installation - -You should now be able to view the Windows node in your cluster by running: - -```bash -kubectl get nodes -o wide -``` - -If your new node is in the `NotReady` state it is likely because the flannel image is still downloading. -You can check the progress as before by checking on the flannel pods in the `kube-system` namespace: - -```shell -kubectl -n kube-system get pods -l app=flannel -``` - -Once the flannel Pod is running, your node should enter the `Ready` state and then be available to handle workloads. - -## {{% heading "whatsnext" %}} - -- [Upgrading Windows kubeadm nodes](/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes) diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md b/content/en/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md index 35857d09a0..9efe6d8c2f 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md @@ -34,7 +34,7 @@ upgrade the control plane nodes before upgrading your Windows nodes. ```powershell # replace {{< param "fullversion" >}} with your desired version - curl.exe -Lo C:\k\kubeadm.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubeadm.exe + curl.exe -Lo https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubeadm.exe ``` ### Drain the node @@ -62,16 +62,28 @@ upgrade the control plane nodes before upgrading your Windows nodes. kubeadm upgrade node ``` -### Upgrade kubelet +### Upgrade kubelet and kubeproxy 1. From the Windows node, upgrade and restart the kubelet: ```powershell stop-service kubelet - curl.exe -Lo C:\k\kubelet.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubelet.exe + curl.exe -Lo https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubelet.exe restart-service kubelet ``` +2. From the Windows node, upgrade and restart the kube-proxy. + + ```powershell + stop-service kube-proxy + curl.exe -Lo https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kube-proxy.exe + restart-service kube-proxy + ``` + +{{< note >}} +If you are running kube-proxy in a HostProcess Container instead of a Windows Service, you can upgrade kube-proxy by applying a newer version of your kube-proxy manifests. +{{< /note >}} + ### Uncordon the node 1. From a machine with access to the Kubernetes API, @@ -81,14 +93,7 @@ bring the node back online by marking it schedulable: # replace with the name of your node kubectl uncordon ``` -### Upgrade kube-proxy - -1. From a machine with access to the Kubernetes API, run the following, -again replacing {{< param "fullversion" >}} with your desired version: - - ```shell - curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f - - ``` + From 3693d1cf3005a4405fb17354cfb37f041a3fccf2 Mon Sep 17 00:00:00 2001 From: James Sturtevant Date: Wed, 8 Jun 2022 17:40:20 +0000 Subject: [PATCH 02/25] updates from feedback --- .../tools/kubeadm/create-cluster-kubeadm.md | 4 ---- .../administer-cluster/kubeadm/upgrading-windows-nodes.md | 4 ++-- static/_redirects | 1 + 3 files changed, 3 insertions(+), 6 deletions(-) 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 d70056e71f..d7897dfec5 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 @@ -336,10 +336,6 @@ The nodes are where your workloads (containers and Pods, etc) run. To add new no kubeadm join --token : --discovery-token-ca-cert-hash sha256: ``` -{{< note >}} -On Windows you should specify the `--cri-socket` parameter in the `kubeadm join` command. The default path is "npipe:////./pipe/containerd-containerd" for containerd. -{{< /note >}} - If you do not have the token, you can get it by running the following command on the control-plane node: ```bash diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md b/content/en/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md index 9efe6d8c2f..a581cc16d3 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md @@ -62,7 +62,7 @@ upgrade the control plane nodes before upgrading your Windows nodes. kubeadm upgrade node ``` -### Upgrade kubelet and kubeproxy +### Upgrade kubelet and kube-proxy 1. From the Windows node, upgrade and restart the kubelet: @@ -81,7 +81,7 @@ upgrade the control plane nodes before upgrading your Windows nodes. ``` {{< note >}} -If you are running kube-proxy in a HostProcess Container instead of a Windows Service, you can upgrade kube-proxy by applying a newer version of your kube-proxy manifests. +If you are running kube-proxy in a HostProcess container within a Pod, and not as a Windows Service, you can upgrade kube-proxy by applying a newer version of your kube-proxy manifests. {{< /note >}} ### Uncordon the node diff --git a/static/_redirects b/static/_redirects index 48a5005f56..c3d181f097 100644 --- a/static/_redirects +++ b/static/_redirects @@ -544,6 +544,7 @@ /docs/setup/windows/intro-windows-in-kubernetes/ /docs/setup/production-environment/windows/intro-windows-in-kubernetes/ 301 /docs/setup/windows/user-guide-windows-nodes/ /docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/ 301 /docs/setup/production-environment/windows/user-guide-windows-nodes/ /docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/ 301 +/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/ /docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/ 301 /docs/setup/windows/user-guide-windows-containers/ /docs/setup/production-environment/windows/user-guide-windows-containers/ 301 /docs/setup/multiple-zones/ /docs/setup/best-practices/multiple-zones/ 301 /docs/setup/cluster-large/ /docs/setup/best-practices/cluster-large/ 301 From e849026b79f8e2c3b27d0426c3a6547bcf48ab72 Mon Sep 17 00:00:00 2001 From: javadoors Date: Tue, 14 Jun 2022 20:37:10 +0800 Subject: [PATCH 03/25] [zh] Translate /docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1/ to Chinese #34137 --- .../certificate-signing-request-v1.md | 1600 +++++++++++++++++ 1 file changed, 1600 insertions(+) create mode 100644 content/zh-cn/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1.md diff --git a/content/zh-cn/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1.md b/content/zh-cn/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1.md new file mode 100644 index 0000000000..8038b32484 --- /dev/null +++ b/content/zh-cn/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1.md @@ -0,0 +1,1600 @@ +--- +api_metadata: + apiVersion: "certificates.k8s.io/v1" + import: "k8s.io/api/certificates/v1" + kind: "CertificateSigningRequest" +content_type: "api_reference" +description: "CertificateSigningRequest 对象提供了一种通过提交证书签名请求并异步批准和颁发 x509 证书的机制。" +title: "证书签名请求" +weight: 4 +auto_generated: true +--- + + + + + + +`apiVersion: certificates.k8s.io/v1` + +`import "k8s.io/api/certificates/v1"` + + +## 证书签名请求 CertificateSigningRequest {#CertificateSigningRequest} + + +CertificateSigningRequest 对象提供了一种通过提交证书签名请求并异步批准和颁发 x509 证书的机制。 + +Kubelets 使用 CertificateSigningRequest API 来获取： + 1. 向 kube-apiserver 进行身份认证的客户端证书（使用 “kubernetes.io/kube-apiserver-client-kubelet” signerName）。 + 2. kube-apiserver 可以安全连接到 TLS 端点的服务证书（使用 “kubernetes.io/kubelet-serving” signerName）。 + + +此 API 可用于请求客户端证书以向 kube-apiserver 进行身份验证（使用 “kubernetes.io/kube-apiserver-client” 签名者名称）， +或从自定义非 Kubernetes 签名者那里获取证书。 + + +
+ +- **apiVersion**: certificates.k8s.io/v1 + +- **kind**: CertificateSigningRequest + +- **metadata** (}}">ObjectMeta) + + +- **spec** (}}"> + CertificateSigningRequestSpec)，必需 + + spec 包含证书请求，并且在创建后是不可变的。 + 只有 request、signerName、expirationSeconds 和 usages 字段可以在创建时设置。 + 其他字段由 Kubernetes 派生，用户无法修改。 + + +- **status** (}}"> + CertificateSigningRequestStatus) + + status 包含有关请求是被批准还是拒绝的信息，以及签名者颁发的证书或指示签名者失败的状况。 + + +## 证书签名请求规范 CertificateSigningRequestSpec {#CertificateSigningRequestSpec} + +CertificateSigningRequestSpec 包含证书请求。 + + +
+ +- **request** ([]byte)，必需 + + **Atomic：将在合并期间被替换** + + request 包含一个在 “CERTIFICATE REQUEST” PEM 块中编码的 x509 证书签名请求。 + 当序列化为 JSON 或 YAML 时，数据额外采用 base64 编码。 + + +- **signerName** (string)，必需 + + signerName 表示请求的签名者，是一个限定名。 + + CertificateSigningRequests 的 list/watch 请求可以使用 “spec.signerName=NAME” 字段选择器进行过滤。 + + + 众所周知的 Kubernetes 签名者有： + 1. “kubernetes.io/kube-apiserver-client”：颁发客户端证书，用于向 kube-apiserver 进行身份验证。 + 对此签名者的请求永远不会被 kube-controller-manager 自动批准， + 可以由 kube-controller-manager 中的 “csrsigning” 控制器颁发。 + 2. “kubernetes.io/kube-apiserver-client-kubelet”：颁发客户端证书，kubelet 用于向 kube-apiserver 进行身份验证。 + 对此签名者的请求可以由 kube-controller-manager 中的 “csrapproving” 控制器自动批准， + 并且可以由 kube-controller-manager 中的 “csrsigning” 控制器颁发。 + 3. “kubernetes.io/kubelet-serving” 颁发服务证书，kubelet 用于服务 TLS 端点，kube-apiserver 可以安全的连接到这些端点。 + 对此签名者的请求永远不会被 kube-controller-manager 自动批准， + 可以由 kube-controller-manager 中的 “csrsigning” 控制器颁发。 + + 更多详细信息，请访问 https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers + + + 也可以指定自定义 signerName。签名者定义如下： + 1. 信任分发：信任（CA 证书包）是如何分发的。 + 2. 许可的主体：当请求不允许的主体时的行为。 + 3. 请求中必需、许可或禁止的 x509 扩展（包括是否允许 subjectAltNames、哪些类型、对允许值的限制） + 以及请求不允许的扩展时的行为。 + 4. 必需、许可或禁止的密钥用途/扩展密钥用途。 + 5. 过期/证书生命周期：是否由签名者确定，管理员可配置。 + 6. 是否允许申请 CA 证书。 + + +- **expirationSeconds** (int32) + + expirationSeconds 是所颁发证书的所请求的有效期。 + 证书签署者可以颁发具有不同有效期的证书， + 因此客户端必须检查颁发证书中 notBefore 和 notAfter 字段之间的增量以确定实际持续时间。 + + + 众所周知的 Kubernetes 签名者在 v1.22+ 版本内实现将遵守此字段， + 只要请求的持续时间不大于最大持续时间，它们将遵守 Kubernetes 控制管理器的 + --cluster-signing-duration CLI 标志。 + + + 由于各种原因，证书签名者可能忽略此字段: + + 1. 不认识此字段的旧签名者(如 v1.22 版本之前的实现) + 2. 配置的最大持续时间小于请求持续时间的签名者 + 3. 配置的最小持续时间大于请求持续时间的签名者 + + expirationSeconds 的最小有效值为 600，即 10 分钟。 + + +- **extra** (map[string][]string) + + extra 包含创建 CertificateSigningRequest 的用户的额外属性。 + 在创建时由 API 服务器填充，且不可变。 + + +- **groups** ([]string) + + **Atomic：将在合并过程中被替换** + + groups 包含创建 CertificateSigningRequest 的用户的组成员关系。 + 在创建时由 API 服务器填充，且不可变。 + + +- **uid** (string) + + uid 包含创建 CertificateSigningRequest 的用户的 uid 。 + 在创建时由 API 服务器填充，且不可变。 + + +- **usages** ([]string) + + **Atomic：将在合并期间被替换** + + usages 指定颁发证书中请求的一组密钥用途。 + + TLS 客户端证书的请求通常要求："digital signature"、"key encipherment"、"client auth"。 + + TLS 服务证书的请求通常要求："key encipherment"、"digital signature"、"server auth"。 + + + 有效值： + "signing"、"digital signature"、"content commitment"、 + "key encipherment"、"key agreement"、"data encipherment"、 + "cert sign"、"crl sign"、"encipher only"、"decipher only"、"any"、 + "server auth"、"client auth"、 + "code signing"、"email protection"、"s/mime"、 + "ipsec end system"、"ipsec tunnel"、"ipsec user"、 + "timestamping"、"ocsp signing"、"microsoft sgc"、"netscape sgc"。 + + +- **username** (string) + + username 包含创建 CertificateSigningRequest 的用户名。 + 在创建时由 API 服务器填充，且不可变。 + + +## 证书签名请求状态 CertificateSigningRequestStatus {#CertificateSigningRequestStatus} + +CertificateSigningRequestStatus 包含用于指示请求的批准/拒绝/失败状态和颁发证书的状况。 + +
+ + +- **certificate** ([]byte) + + **Atomic：将在合并期间被替换** + + certificate 在出现 Approved 状况后，由签名者使用已颁发的证书填充。 + 这个字段通过 /status 子资源设置。填充后，该字段将不可变。 + + 如果证书签名请求被拒绝，则添加类型为 “Denied” 的状况，并且保持该字段为空。 + 如果签名者不能颁发证书，则添加类型为 “Failed” 的状况，并且保持该字段为空。 + + + 验证要求: + 1. 证书必须包含一个或多个 PEM 块。 + 2. 所有的 PEM 块必须有 “CERTIFICATE” 标签，不包含头和编码的数据， + 必须是由 BER 编码的 ASN.1 证书结构，如 RFC5280 第 4 节所述。 + 3. 非 PEM 内容可能出现在 “CERTIFICATE”PEM 块之前或之后，并且是未验证的， + 允许如 RFC7468 5.2 节中描述的解释性文本。 + + + 如果存在多个 PEM 块，并且所请求的 spec.signerName 的定义没有另外说明， + 那么第一个块是颁发的证书，后续的块应该被视为中间证书并在 TLS 握手中呈现。 + + + 证书编码为 PEM 格式。 + + 当序列化为 JSON 或 YAML 时，数据额外采用 base64 编码，它包括: + ``` + base64( + -----BEGIN CERTIFICATE----- + ... + -----END CERTIFICATE----- + ) + ``` + +- **conditions** ([]CertificateSigningRequestCondition) + + **Map：键类型的唯一值将在合并期间保留** + + 应用于请求的状况。已知的状况有 "Approved"、"Denied" 与 "Failed"。 + + + **CertificateSigningRequestCondition 描述 CertificateSigningRequest 对象的状况。** + + + - **conditions.status** (string)，必需 + + 状况的状态，True、False、Unknown 之一。Approved、Denied 与 Failed 的状况不可以是 "False" 或 "Unknown"。 + + + - **conditions.type** (string)，必需 + + 状况的类型。已知的状况是 "Approved"、"Denied" 与 "Failed"。 + + 通过 /approval 子资源添加 “Approved” 状况，表示请求已被批准并且应由签名者颁发。 + + 通过 /approval 子资源添加 “Denied” 状况，指示请求被拒绝并且不应由签名者颁发。 + + 通过 /status 子资源添加 “Failed” 状况，表示签名者未能颁发证书。 + + Approved 和 Denied 状况是相互排斥的。Approved、Denied 和 Failed 状况一旦添加就无法删除。 + + 给定类型只允许设置一种状况。 + + + + - **conditions.lastTransitionTime** (Time) + + lastTransitionTime 是状况上一次从一种状态转换到另一种状态的时间。 + 如果未设置，当添加新状况类型或更改现有状况的状态时，服务器默认为当前时间。 + + + **Time 是 time.Time 的包装器，支持正确编码为 YAML 和 JSON。为 time 包提供的许多工厂方法提供了包装器。** + + + - **conditions.lastUpdateTime** (Time) + + lastUpdateTime 是该状况最后一次更新的时间。 + + + **Time 是 time.Time 的包装器，支持正确编组为 YAML 和 JSON。为 time 包提供的许多工厂方法提供了包装器。** + + + - **conditions.message** (string) + + message 包含一个人类可读的消息，包含关于请求状态的详细信息。 + + + - **conditions.reason** (string) + + reason 表示请求状态的简短原因。 + + +## 证书签名请求列表 CertificateSigningRequestList {#CertificateSigningRequestList} + +CertificateSigningRequestList 是 CertificateSigningRequest 对象的集合。 + +
+ + +- **apiVersion**: certificates.k8s.io/v1 + +- **kind**: CertificateSigningRequestList + +- **metadata** (}}">ListMeta) + +- **items** ([]}}">CertificateSigningRequest)，必需 + + items 是 CertificateSigningRequest 对象的集合。 + + + +## 操作 {#Operations} + +
+ + +### `get` 读取指定的 CertificateSigningRequest + +#### HTTP 请求 + +GET /apis/certificates.k8s.io/v1/certificatesigningrequests/{name} + + +#### 参数 + +- **name** (**路径参数**): string，必需 + + CertificateSigningRequest 的名称。 + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">CertificateSigningRequest): OK + +401: Unauthorized + + +### `get` 读取指定 CertificateSigningRequest 的批准信息 + +#### HTTP 请求 + +GET /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/approval + + +#### 参数 + +- **name** (**路径参数**): string，必需 + + CertificateSigningRequest 的名称。 + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">CertificateSigningRequest): OK + +401: Unauthorized + +### `get` 读取指定 CertificateSigningRequest 的状态 + +#### HTTP 请求 + +GET /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/status + + +#### 参数 + +- **name** (**路径参数**): string，必需 + + CertificateSigningRequest 的名称。 + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">CertificateSigningRequest): OK + +401: Unauthorized + + +### `list` list 或 watch CertificateSigningRequest 类型的对象 + +#### HTTP 请求 + +GET /apis/certificates.k8s.io/v1/certificatesigningrequests + + +#### 参数 + +- **allowWatchBookmarks** (**查询参数**): boolean + + }}">allowWatchBookmarks + +- **continue** (**查询参数**): string + + }}">continue + + +- **fieldSelector** (**查询参数**): string + + }}">fieldSelector + +- **labelSelector** (**查询参数**): string + + }}">labelSelector + +- **limit** (**查询参数**): integer + + }}">limit + + +- **pretty** (**查询参数**): string + + }}">pretty + +- **resourceVersion** (**查询参数**): string + + }}">resourceVersion + +- **resourceVersionMatch** (**查询参数**): string + + }}">resourceVersionMatch + + +- **timeoutSeconds** (**查询参数**): integer + + }}">timeoutSeconds + +- **watch** (**查询参数**): boolean + + }}">watch + + +#### 响应 + +200 (}}">CertificateSigningRequestList): OK + +401: Unauthorized + + +### `create` 创建一个 CertificateSigningRequest + +#### HTTP 请求 + +POST /apis/certificates.k8s.io/v1/certificatesigningrequests + + +#### 参数 + +- **body**: }}">CertificateSigningRequest，必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">CertificateSigningRequest): OK + +201 (}}">CertificateSigningRequest): Created + +202 (}}">CertificateSigningRequest): Accepted + +401: Unauthorized + + +### `update` 替换指定的 CertificateSigningRequest + +#### HTTP 请求 + +PUT /apis/certificates.k8s.io/v1/certificatesigningrequests/{name} + +#### 参数 + + +- **name** (**路径参数**): string，必需 + + CertificateSigningRequest 的名称。 + +- **body**: }}">CertificateSigningRequest，必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">CertificateSigningRequest): OK + +201 (}}">CertificateSigningRequest): Created + +401: Unauthorized + + +### `update` 替换对指定 CertificateSigningRequest 的批准信息 + +#### HTTP 请求 + +PUT /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/approval + +#### 参数 + + +- **name** (**路径参数**): string，必需 + + CertificateSigningRequest 的名称。 + +- **body**: }}">CertificateSigningRequest，必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">CertificateSigningRequest): OK + +201 (}}">CertificateSigningRequest): Created + +401: Unauthorized + + +### `update` 替换指定 CertificateSigningRequest 的状态 + +#### HTTP 请求 + +PUT /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/status + +#### 参数 + + +- **name** (**路径参数**): string，必需 + + CertificateSigningRequest 的名称。 + +- **body**: }}">CertificateSigningRequest，必需 + +- **dryRun** (*in query*): string + + }}">dryRun + + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">CertificateSigningRequest): OK + +201 (}}">CertificateSigningRequest): Created + +401: Unauthorized + + +### `patch` 部分更新指定的 CertificateSigningRequest + +#### HTTP 请求 + +PATCH /apis/certificates.k8s.io/v1/certificatesigningrequests/{name} + +#### 参数 + + +- **name** (**路径参数**): string，必需 + + CertificateSigningRequest 的名称。 + +- **body**: }}">Patch，必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **force** (**查询参数**): boolean + + }}">force + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">CertificateSigningRequest): OK + +201 (}}">CertificateSigningRequest): Created + +401: Unauthorized + + +### `patch` 部分更新指定 CertificateSigningRequest 的批准信息 + +#### HTTP 请求 + +PATCH /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/approval + +#### 参数 + + +- **name** (**路径参数**): string，必需 + + CertificateSigningRequest 的名称。 + +- **body**: }}">Patch，必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **force** (**查询参数**): boolean + + }}">force + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">CertificateSigningRequest): OK + +201 (}}">CertificateSigningRequest): Created + +401: Unauthorized + + +### `patch` 部分更新指定 CertificateSigningRequest 的状态 + +#### HTTP 请求 + +PATCH /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/status + +#### 参数 + + +- **name** (**路径参数**): string，必需 + + CertificateSigningRequest 的名称。 + +- **body**: }}">Patch，必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **force** (**查询参数**): boolean + + }}">force + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 + +200 (}}">CertificateSigningRequest): OK + +201 (}}">CertificateSigningRequest): Created + +401: Unauthorized + + +### `delete` 删除一个 CertificateSigningRequest + +#### HTTP 请求 + +DELETE /apis/certificates.k8s.io/v1/certificatesigningrequests/{name} + +#### 参数 + + +- **name** (**路径参数**): string，必需 + + CertificateSigningRequest 的名称。 + +- **body**: }}">DeleteOptions + +- **dryRun** (**查询参数**): string + + }}">dryRun + + +- **gracePeriodSeconds** (**查询参数**): integer + + }}">gracePeriodSeconds + +- **pretty** (**查询参数**): string + + }}">pretty + +- **propagationPolicy** (**查询参数**): string + + }}">propagationPolicy + + +#### 响应 + +200 (}}">Status): OK + +202 (}}">Status): Accepted + +401: Unauthorized + + +### `deletecollection` 删除 CertificateSigningRequest 集合 + +#### HTTP 请求 + +DELETE /apis/certificates.k8s.io/v1/certificatesigningrequests + +#### 参数 + + +- **body**: }}">DeleteOptions + +- **continue** (**查询参数**): string + + }}">continue + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldSelector** (**查询参数**): string + + }}">fieldSelector + + +- **gracePeriodSeconds** (**查询参数**): integer + + }}">gracePeriodSeconds + +- **labelSelector** (**查询参数**): string + + }}">labelSelector + +- **limit** (**查询参数**): integer + + }}">limit + +- **pretty** (**查询参数**): string + + }}">pretty + + +- **propagationPolicy** (**查询参数**): string + + }}">propagationPolicy + +- **resourceVersion** (**查询参数**): string + + }}">resourceVersion + +- **resourceVersionMatch** (**查询参数**): string + + }}">resourceVersionMatch + +- **timeoutSeconds** (**查询参数**): integer + + }}">timeoutSeconds + + +#### 响应 + +200 (}}">Status): OK + +401: Unauthorized \ No newline at end of file From 8f3c935b26bbc0160390968d6f09cdc88430e54b Mon Sep 17 00:00:00 2001 From: Icarus9913 Date: Tue, 14 Jun 2022 17:54:26 +0800 Subject: [PATCH 04/25] improve chinese translation Signed-off-by: Icarus9913 --- .../architecture/garbage-collection.md | 21 +++++++++---------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/content/zh-cn/docs/concepts/architecture/garbage-collection.md b/content/zh-cn/docs/concepts/architecture/garbage-collection.md index 7fb0eb0d3e..c095601354 100644 --- a/content/zh-cn/docs/concepts/architecture/garbage-collection.md +++ b/content/zh-cn/docs/concepts/architecture/garbage-collection.md @@ -56,8 +56,8 @@ object. In most cases, Kubernetes manages owner references automatically. Kubernetes 中很多对象通过[*属主引用*](/zh/docs/concepts/overview/working-with-objects/owners-dependents/) 链接到彼此。属主引用（Owner Reference）可以告诉控制面哪些对象依赖于其他对象。 -Kubernetes 使用属主引用来为控制面以及其他 API 客户端在删除某对象时提供一个 -清理关联资源的机会。在大多数场合，Kubernetes 都是自动管理属主引用的。 +Kubernetes 使用属主引用来为控制面以及其他 API 客户端在删除某对象时提供一个清理关联资源的机会。 +在大多数场合，Kubernetes 都是自动管理属主引用的。 -属主关系与某些资源所使用的的[标签和选择算符](/zh/docs/concepts/overview/working-with-objects/labels/) -不同。例如，考虑一个创建 `EndpointSlice` 对象的 {{}} +属主关系与某些资源所使用的[标签和选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)不同。 +例如，考虑一个创建 `EndpointSlice` 对象的 {{}} 对象。Service 对象使用*标签*来允许控制面确定哪些 `EndpointSlice` 对象被该 Service 使用。除了标签，每个被 Service 托管的 `EndpointSlice` 对象还有一个属主引用属性。 属主引用可以帮助 Kubernetes 中的不同组件避免干预并非由它们控制的对象。 @@ -85,8 +85,7 @@ is subject to deletion once all owners are verified absent. --> 根据设计，系统不允许出现跨名字空间的属主引用。名字空间作用域的依赖对象可以指定集群作用域或者名字空间作用域的属主。 名字空间作用域的属主**必须**存在于依赖对象所在的同一名字空间。 -如果属主位于不同名字空间，则属主引用被视为不存在，而当检查发现所有属主都已不存在时， -依赖对象会被删除。 +如果属主位于不同名字空间，则属主引用被视为不存在，而当检查发现所有属主都已不存在时，依赖对象会被删除。 ### 前台级联删除 {#foreground-deletion} -在前台级联删除中，正在被你删除的对象首先进入 *deletion in progress* 状态。 +在前台级联删除中，正在被你删除的属主对象首先进入 *deletion in progress* 状态。 在这种状态下，针对属主对象会发生以下事情： -## CNCF Community Code of Conduct v1.0 + https://github.com/cncf/foundation/blob/main/code-of-conduct.md --> +## CNCF Community Code of Conduct v1.1 ### Contributor Code of Conduct -As contributors and maintainers of this project, and in the interest of fostering +As contributors and maintainers in the CNCF community, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities. -We are committed to making participation in this project a harassment-free experience for -everyone, regardless of level of experience, gender, gender identity and expression, +We are committed to making participation in the CNCF community a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality. -Examples of unacceptable behavior by participants include: +## Scope -* The use of sexualized language or imagery -* Personal attacks -* Trolling or insulting/derogatory comments +This code of conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. + +### CNCF Events + +CNCF events, or events run by the Linux Foundation with professional events staff, are governed by the Linux Foundation [Events Code of Conduct](https://events.linuxfoundation.org/code-of-conduct/) available on the event page. This is designed to be used in conjunction with the CNCF Code of Conduct. + +## Our Standards + +Examples of behavior that contributes to a positive environment include: + +* Demonstrating empathy and kindness toward other people +* Being respectful of differing opinions, viewpoints, and experiences +* Giving and gracefully accepting constructive feedback +* Accepting responsibility and apologizing to those affected by our mistakes, + and learning from the experience +* Focusing on what is best not just for us as individuals, but for the + overall community + +Examples of unacceptable behavior include: + +* The use of sexualized language or imagery, and sexual attention or + advances of any kind +* Trolling, insulting or derogatory comments, and personal or political attacks * Public or private harassment -* Publishing other's private information, such as physical or electronic addresses, - without explicit permission -* Other unethical or unprofessional conduct. +* Publishing others' private information, such as a physical or email + address, without their explicit permission +* Other conduct which could reasonably be considered inappropriate in a + professional setting -Project maintainers have the right and responsibility to remove, edit, or reject -comments, commits, code, wiki edits, issues, and other contributions that are not -aligned to this Code of Conduct. By adopting this Code of Conduct, project maintainers -commit themselves to fairly and consistently applying these principles to every aspect -of managing this project. Project maintainers who do not follow or enforce the Code of +Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. +By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect +of managing this project. +Project maintainers who do not follow or enforce the Code of Conduct may be permanently removed from the project team. -This code of conduct applies both within project spaces and in public spaces -when an individual is representing the project or its community. +## Reporting -Instances of abusive, harassing, or otherwise unacceptable behavior in Kubernetes may be reported by contacting the [Kubernetes Code of Conduct Committee](https://git.k8s.io/community/committee-code-of-conduct) via . For other projects, please contact a CNCF project maintainer or our mediator, Mishi Choudhary . +For incidents occuring in the Kubernetes community, contact the [Kubernetes Code of Conduct Committee](https://git.k8s.io/community/committee-code-of-conduct) via . You can expect a response within three business days. + +For other projects, please contact the CNCF staff via . You can expect a response within three business days. + +In matters that require an outside mediator, CNCF has retained Mishi Choudhary (mishi@linux.com). Use of an outside mediator can be requested when reporting or used at CNCF staff's discretion. In general, contacting directly is preferred. + + +## Enforcement + +The Kubernetes project's [Code of Conduct Committee](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct) enforces code of conduct issues. For all other projects, the CNCF enforces code of conduct issues. + +Both bodies try to resolve incidents without punishment, but may remove people from the project or CNCF communities at their discretion. + +## Acknowledgements This Code of Conduct is adapted from the Contributor Covenant -(https://contributor-covenant.org), version 1.2.0, available at -https://contributor-covenant.org/version/1/2/0/ - -### CNCF Events Code of Conduct - -CNCF events are governed by the Linux Foundation [Code of Conduct](https://events.linuxfoundation.org/code-of-conduct/) available on the event page. This is designed to be compatible with the above policy and also includes more details on responding to incidents. +(http://contributor-covenant.org), version 2.0 available at +http://contributor-covenant.org/version/2/0/code_of_conduct/ \ No newline at end of file diff --git a/content/en/docs/contribute/advanced.md b/content/en/docs/contribute/advanced.md index 9c37906f3d..34e0107035 100644 --- a/content/en/docs/contribute/advanced.md +++ b/content/en/docs/contribute/advanced.md @@ -136,7 +136,7 @@ The role of co-chair is one of service: co-chairs build contributor capacity, ha Responsibilities include: - Keep SIG Docs focused on maximizing developer happiness through excellent documentation -- Exemplify the [community code of conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) and hold SIG members accountable to it +- Exemplify the [community code of conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) and hold SIG members accountable to it - Learn and set best practices for the SIG by updating contribution guidelines - Schedule and run SIG meetings: weekly status updates, quarterly retro/planning sessions, and others as needed - Schedule and run doc sprints at KubeCon events and other conferences @@ -147,7 +147,7 @@ Responsibilities include: To schedule and run effective meetings, these guidelines show what to do, how to do it, and why. -**Uphold the [community code of conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md)**: +**Uphold the [community code of conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md)**: - Hold respectful, inclusive discussions with respectful, inclusive language. diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md index 7630bdc7d9..9b8890aef0 100644 --- a/content/en/docs/contribute/localization.md +++ b/content/en/docs/contribute/localization.md @@ -157,7 +157,7 @@ For example, for German the strings live in `data/i18n/de/de.toml`, and ### Localize the community code of conduct -Open a PR against the [`cncf/foundation`](https://github.com/cncf/foundation/tree/master/code-of-conduct-languages) repository to add the code of conduct in your language. +Open a PR against the [`cncf/foundation`](https://github.com/cncf/foundation/tree/main/code-of-conduct-languages) repository to add the code of conduct in your language. ### Setting up the OWNERS files diff --git a/content/en/docs/contribute/review/reviewing-prs.md b/content/en/docs/contribute/review/reviewing-prs.md index ec5ad21f6c..5a5bbce533 100644 --- a/content/en/docs/contribute/review/reviewing-prs.md +++ b/content/en/docs/contribute/review/reviewing-prs.md @@ -27,7 +27,7 @@ Before reviewing, it's a good idea to: Before you start a review: -- Read the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) and ensure that you abide by it at all times. +- Read the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) and ensure that you abide by it at all times. - Be polite, considerate, and helpful. - Comment on positive aspects of PRs as well as changes. - Be empathetic and mindful of how your review may be received. From ff77ce9716373575b66025a550b9b5d1c47b05a8 Mon Sep 17 00:00:00 2001 From: Seth McCombs Date: Tue, 31 May 2022 15:46:39 -0700 Subject: [PATCH 06/25] update from ci-robot to triage-robot --- content/ko/docs/contribute/participate/pr-wranglers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ko/docs/contribute/participate/pr-wranglers.md b/content/ko/docs/contribute/participate/pr-wranglers.md index 424f9b0227..833b006f1a 100644 --- a/content/ko/docs/contribute/participate/pr-wranglers.md +++ b/content/ko/docs/contribute/participate/pr-wranglers.md @@ -85,6 +85,6 @@ PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다. {{< note >}} -[`fejta-bot`](https://github.com/fejta-bot)이라는 봇은 90일 동안 활동이 없으면 이슈를 오래된 것(stale)으로 표시한다. 30일이 더 지나면 rotten으로 표시하고 종료한다. PR 랭글러는 14-30일 동안 활동이 없으면 이슈를 닫아야 한다. +[`k8s-triage-robot`](https://github.com/k8s-triage-robot)이라는 봇은 90일 동안 활동이 없으면 이슈를 오래된 것(stale)으로 표시한다. 30일이 더 지나면 rotten으로 표시하고 종료한다. PR 랭글러는 14-30일 동안 활동이 없으면 이슈를 닫아야 한다. {{< /note >}} From 2286d3652bf139fa3325623990004f3d8f9735a0 Mon Sep 17 00:00:00 2001 From: yancz2000 Date: Thu, 16 Jun 2022 22:34:49 +0800 Subject: [PATCH 07/25] Update deployment.md --- content/zh-cn/docs/concepts/workloads/controllers/deployment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh-cn/docs/concepts/workloads/controllers/deployment.md b/content/zh-cn/docs/concepts/workloads/controllers/deployment.md index f5249b60d6..77914f837b 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/deployment.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/deployment.md @@ -1230,7 +1230,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess 在你更新一个 Deployment 的时候，或者计划更新它的时候， 你可以在触发一个或多个更新之前暂停 Deployment 的上线过程。 -当你准备行应用这些变更时，你可以重新恢复 Deployment 上线过程。 +当你准备应用这些变更时，你可以重新恢复 Deployment 上线过程。 这样做使得你能够在暂停和恢复执行之间应用多个修补程序，而不会触发不必要的上线操作。 + +`apiVersion: storage.k8s.io/v1` + +`import "k8s.io/api/storage/v1"` + +## CSINode {#CSINode} + +CSINode 包含节点上安装的所有 CSI 驱动有关的信息。CSI 驱动不需要直接创建 CSINode 对象。 +只要这些驱动使用 node-driver-registrar 边车容器，kubelet 就会自动为 CSI 驱动填充 CSINode 对象， +作为 kubelet 插件注册操作的一部分。CSINode 的名称与节点名称相同。 +如果不存在此对象，则说明该节点上没有可用的 CSI 驱动或 Kubelet 版本太低无法创建该对象。 +CSINode 包含指向相应节点对象的 OwnerReference。 + +
+ +- **apiVersion**: storage.k8s.io/v1 + +- **kind**: CSINode + + +- **metadata** (}}">ObjectMeta) + + metadata.name 必须是 Kubernetes 节点的名称。 + +- **spec** (}}">CSINodeSpec)，必需 + + spec 是 CSINode 的规约。 + +## CSINodeSpec {#CSINodeSpec} + +CSINodeSpec 包含一个节点上安装的所有 CSI 驱动规约有关的信息。 + +
+ + +- **drivers** ([]CSINodeDriver)，必需 + + **补丁策略：按照键 `name` 合并** + + drivers 是节点上存在的所有 CSI 驱动的信息列表。如果列表中的所有驱动均被卸载，则此字段可以为空。 + + + **CSINodeDriver 包含一个节点上安装的一个 CSI 驱动规约有关的信息。** + + - **drivers.name** (string)，必需 + + 这是该对象引用的 CSI 驱动的名称。此字段值必须是针对该驱动由 CSI GetPluginName() 调用返回的相同名称。 + + + - **drivers.nodeID** (string)，必需 + + 从驱动角度来看，这是节点的 nodeID。 + 对于未与节点共享相同命名法的存储系统，此字段使得 Kubernetes 能够与之进行通信。 + 例如，Kubernetes 可能将给定节点视为 "node1"，但存储系统可以将同一节点视为 "nodeA"。 + 当 Kubernetes 向存储系统发出一条命令将一个卷挂接到特定的节点时， + 它可以藉此字段使用存储系统所理解的 ID 引用节点名称，例如使用 “nodeA” 而不是 “node1”。 + 此字段是必需的。 + + + - **drivers.allocatable** (VolumeNodeResources) + + allocatable 表示一个节点上可供调度的卷资源。此字段处于 beta 阶段。 + + + **VolumeNodeResources 是调度卷时所用的一组资源限制。** + + - **drivers.allocatable.count** (int32) + + 这是一个节点上可使用的、由 CSI 驱动管理的独立卷个数的上限。 + 挂接并挂载到一个节点上的卷被视为被使用一次，不是两次。 + 相同的规则适用于同一个节点上多个 Pod 之间共享的同一个卷。 + 如果未指定此字段，则该节点上支持的卷数量是无限的。 + + + - **drivers.topologyKeys** ([]string) + + topologyKeys 是驱动支持的键的列表。 + 在集群上初始化一个驱动时，该驱动将提供一组自己理解的拓扑键 + （例如 “company.com/zone”、“company.com/region”）。 + 在一个节点上初始化一个驱动时，该驱动将提供相同的拓扑键和值。 + Kubelet 将在其自己的节点对象上将这些拓扑键暴露为标签。 + 当 Kubernetes 进行拓扑感知的制备时，可以使用此列表决定应从节点对象中检索哪些标签并传回驱动。 + 不同的节点可以使用不同的拓扑键。 + 如果驱动不支持拓扑，则此字段可以为空。 + +## CSINodeList {#CSINodeList} + +CSINodeList 是 CSINode 对象的集合。 + +
+ +- **apiVersion**: storage.k8s.io/v1 + +- **kind**: CSINodeList + + +- **metadata** (}}">ListMeta) + + 标准的列表元数据。更多信息： + https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata + +- **items** ([]}}">CSINode)，必需 + + items 是 CSINode 的列表。 + + +## 操作 {#Operations} + +
+ +### `get` 读取指定的 CSINode +#### HTTP 请求 + +GET /apis/storage.k8s.io/v1/csinodes/{name} + + +#### 参数 +- **name** (**路径参数**): string，必需 + + CSINode 的名称 + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 +200 (}}">CSINode): OK + +401: Unauthorized + + +### `list` 列出或观测类别为 CSINode 的对象 +#### HTTP 请求 + +GET /apis/storage.k8s.io/v1/csinodes + + +#### 参数 +- **allowWatchBookmarks** (**查询参数**): boolean + + }}">allowWatchBookmarks + +- **continue** (**查询参数**): string + + }}">continue + +- **fieldSelector** (**查询参数**): string + + }}">fieldSelector + +- **labelSelector** (**查询参数**): string + + }}">labelSelector + +- **limit** (**查询参数**): integer + + }}">limit + +- **pretty** (**查询参数**): string + + }}">pretty + +- **resourceVersion** (**查询参数**): string + + }}">resourceVersion + +- **resourceVersionMatch** (**查询参数**): string + + }}">resourceVersionMatch + +- **timeoutSeconds** (**查询参数**): integer + + }}">timeoutSeconds + +- **watch** (**查询参数**): boolean + + }}">watch + + +#### 响应 +200 (}}">CSINodeList): OK + +401: Unauthorized + + +### `create` 创建 CSINode +#### HTTP 请求 + +POST /apis/storage.k8s.io/v1/csinodes + + +#### 参数 +- **body**: }}">CSINode，必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 +200 (}}">CSINode): OK + +201 (}}">CSINode): Created + +202 (}}">CSINode): Accepted + +401: Unauthorized + + +### `update` 替换指定的 CSINode +#### HTTP 请求 + +PUT /apis/storage.k8s.io/v1/csinodes/{name} + + +#### 参数 +- **name** (**路径参数**): string，必需 + + CSINode 的名称 + +- **body**: }}">CSINode，必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 +200 (}}">CSINode): OK + +201 (}}">CSINode): Created + +401: Unauthorized + + +### `patch` 部分更新指定的 CSINode +#### HTTP 请求 + +PATCH /apis/storage.k8s.io/v1/csinodes/{name} + + +#### 参数 +- **name** (**路径参数**): string，必需 + + CSINode 的名称 + +- **body**: }}">Patch，必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **force** (**查询参数**): boolean + + }}">force + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 +200 (}}">CSINode): OK + +201 (}}">CSINode): Created + +401: Unauthorized + + +### `delete` 删除 CSINode +#### HTTP 请求 +DELETE /apis/storage.k8s.io/v1/csinodes/{name} + + +#### 参数 +- **name** (**路径参数**): string，必需 + + CSINode 的名称 + +- **body**: }}">DeleteOptions + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **gracePeriodSeconds** (**查询参数**): integer + + }}">gracePeriodSeconds + +- **pretty** (**查询参数**): string + + }}">pretty + +- **propagationPolicy** (**查询参数**): string + + }}">propagationPolicy + + +#### 响应 +200 (}}">CSINode): OK + +202 (}}">CSINode): Accepted + +401: Unauthorized + + +### `deletecollection` 删除 CSINode 的集合 +#### HTTP 请求 +DELETE /apis/storage.k8s.io/v1/csinodes + + +#### 参数 +- **body**: }}">DeleteOptions + +- **continue** (**查询参数**): string + + }}">continue + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldSelector** (**查询参数**): string + + }}">fieldSelector + +- **gracePeriodSeconds** (**查询参数**): integer + + }}">gracePeriodSeconds + +- **labelSelector** (**查询参数**): string + + }}">labelSelector + +- **limit** (**查询参数**): integer + + }}">limit + +- **pretty** (**查询参数**): string + + }}">pretty + +- **propagationPolicy** (**查询参数**): string + + }}">propagationPolicy + +- **resourceVersion** (**查询参数**): string + + }}">resourceVersion + +- **resourceVersionMatch** (**查询参数**): string + + }}">resourceVersionMatch + +- **timeoutSeconds** (**查询参数**): integer + + }}">timeoutSeconds + + +#### 响应 +200 (}}">Status): OK + +401: Unauthorized \ No newline at end of file From 34369cba01d84221883aa78d527626e02c3db935 Mon Sep 17 00:00:00 2001 From: Sean Wei Date: Sat, 18 Jun 2022 14:44:00 +0800 Subject: [PATCH 10/25] [zh] Sync basic-stateful-set.md --- .../basic-stateful-set.md | 972 +++++++++--------- 1 file changed, 508 insertions(+), 464 deletions(-) diff --git a/content/zh-cn/docs/tutorials/stateful-application/basic-stateful-set.md b/content/zh-cn/docs/tutorials/stateful-application/basic-stateful-set.md index e7c37ff3b0..e51177de71 100644 --- a/content/zh-cn/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/zh-cn/docs/tutorials/stateful-application/basic-stateful-set.md @@ -20,109 +20,115 @@ weight: 10 - -本教程介绍了如何使用 [StatefulSets](/zh/docs/concepts/workloads/controllers/statefulset/) 来管理应用。 -演示了如何创建、删除、扩容/缩容和更新 StatefulSets 的 Pods。 - - +本教程介绍了如何使用 +{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} +来管理应用。 +演示了如何创建、删除、扩容/缩容和更新 StatefulSet 的 Pod。 ## {{% heading "prerequisites" %}} - - 在开始本教程之前，你应该熟悉以下 Kubernetes 的概念： -* [Pods](/zh/docs/concepts/workloads/pods/) -* [Cluster DNS](/zh/docs/concepts/services-networking/dns-pod-service/) -* [Headless Services](/zh/docs/concepts/services-networking/service/#headless-services) -* [PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/) + +* [Pods](/zh-cn/docs/concepts/workloads/pods/) +* [Cluster DNS](/zh-cn/docs/concepts/services-networking/dns-pod-service/) +* [Headless Services](/zh-cn/docs/concepts/services-networking/service/#headless-services) +* [PersistentVolumes](/zh-cn/docs/concepts/storage/persistent-volumes/) +* [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/) +* [StatefulSets](/zh-cn/docs/concepts/workloads/controllers/statefulset/) +* [kubectl](/zh-cn/docs/reference/kubectl/kubectl/) 命令行工具 +{{< note >}} - -本教程假设你的集群被配置为动态的提供 PersistentVolumes。如果没有这样配置，在开始本教程之前，你需要手动准备 2 个 1 GiB 的存储卷。 - - +本教程假设你的集群被配置为动态制备 PersistentVolume 卷。 +如果没有这样配置，在开始本教程之前，你需要手动准备 2 个 1 GiB 的存储卷。 +{{< /note >}} ## {{% heading "objectives" %}} - +StatefulSet 旨在与有状态的应用及分布式系统一起使用。然而在 Kubernetes +上管理有状态应用和分布式系统是一个宽泛而复杂的话题。 +为了演示 StatefulSet 的基本特性，并且不使前后的主题混淆，你将会使用 StatefulSet 部署一个简单的 web 应用。 + +在阅读本教程后，你将熟悉以下内容： + - -StatefulSets 旨在与有状态的应用及分布式系统一起使用。然而在 Kubernetes 上管理有状态应用和分布式系统是一个宽泛而复杂的话题。 -为了演示 StatefulSet 的基本特性，并且不使前后的主题混淆，你将会使用 StatefulSet 部署一个简单的 web 应用。 - -在阅读本教程后，你将熟悉以下内容： - * 如何创建 StatefulSet -* StatefulSet 怎样管理它的 Pods +* StatefulSet 怎样管理它的 Pod * 如何删除 StatefulSet * 如何对 StatefulSet 进行扩容/缩容 -* 如何更新一个 StatefulSet 的 Pods - - - +* 如何更新一个 StatefulSet 的 Pod +## 创建 StatefulSet {#creating-a-statefulset} + - -## 创建 StatefulSet - - -作为开始，使用如下示例创建一个 StatefulSet。它和 [StatefulSets](/zh/docs/concepts/workloads/controllers/statefulset/) 概念中的示例相似。 -它创建了一个 [Headless Service](/zh/docs/concepts/services-networking/service/#headless-services) `nginx` 用来发布 StatefulSet `web` 中的 Pod 的 IP 地址。 +作为开始，使用如下示例创建一个 StatefulSet。它和 +[StatefulSet](/zh-cn/docs/concepts/workloads/controllers/statefulset/) 概念中的示例相似。 +它创建了一个 [Headless Service](/zh-cn/docs/concepts/services-networking/service/#headless-services) +`nginx` 用来发布 StatefulSet `web` 中的 Pod 的 IP 地址。 {{< codenew file="application/web/web.yaml" >}} +下载上面的例子并保存为文件 `web.yaml`。 + - -下载上面的例子并保存为文件 `web.yaml`。 - - -你需要使用两个终端窗口。 在第一个终端中，使用 [`kubectl get`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#get) 来查看 StatefulSet 的 Pods 的创建情况。 +你需要使用两个终端窗口。在第一个终端中，使用 +[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get) +来监视 StatefulSet 的 Pod 的创建情况。 ```shell kubectl get pods -w -l app=nginx @@ -131,10 +137,10 @@ kubectl get pods -w -l app=nginx - -在另一个终端中，使用 [`kubectl apply`](/zh/docs/reference/generated/kubectl/kubectl-commands/#apply) 来创建定义在 `web.yaml` 中的 Headless Service 和 StatefulSet。 +在另一个终端中，使用 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) +来创建定义在 `web.yaml` 中的 Headless Service 和 StatefulSet。 ```shell kubectl apply -f web.yaml @@ -146,12 +152,10 @@ statefulset.apps/web created - -上面的命令创建了两个 Pod，每个都运行了一个 [NGINX](https://www.nginx.com) web 服务器。 -获取 `nginx` Service 和 `web` StatefulSet 来验证是否成功的创建了它们。 +上面的命令创建了两个 Pod，每个都运行了一个 [NginX](https://www.nginx.com) Web 服务器。 +获取 `nginx` Service： ```shell kubectl get service nginx @@ -160,10 +164,12 @@ kubectl get service nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx ClusterIP None 80/TCP 12s ``` + -...然后获取 `web` StatefulSet，以验证两者均已成功创建： +然后获取 `web` StatefulSet，以验证两者均已成功创建： + ```shell kubectl get statefulset web ``` @@ -173,19 +179,17 @@ web 2 1 20s ``` +### 顺序创建 Pod {#ordered-pod-creation} -For a StatefulSet with N replicas, when Pods are being deployed, they are -created sequentially, in order from {0..N-1}. Examine the output of the + - -### 顺序创建 Pod - - -对于一个拥有 N 个副本的 StatefulSet，Pod 被部署时是按照 {0 …… N-1} 的序号顺序创建的。 +对于一个拥有 _n_ 个副本的 StatefulSet，Pod 被部署时是按照 _{0..n-1}_ 的序号顺序创建的。 在第一个终端中使用 `kubectl get` 检查输出。这个输出最终将看起来像下面的样子。 ```shell @@ -205,31 +209,33 @@ web-1 1/1 Running 0 18s -请注意在 `web-0` Pod 处于 [Running和Ready](/zh/docs/user-guide/pod-states) 状态后 `web-1` Pod 才会被启动。 +请注意，直到 `web-0` Pod 处于 _Running_（请参阅 +[Pod 阶段]((/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase))） +并 _Ready_（请参阅 [Pod 状况](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions)中的 +`type`）状态后，`web-1` Pod 才会被启动。 +## StatefulSet 中的 Pod {#pods-in-a-statefulset} -## StatefulSet 中的 Pod + +StatefulSet 中的每个 Pod 拥有一个唯一的顺序索引和稳定的网络身份标识。 + +### 检查 Pod 的顺序索引 {#examining-the-pod-s-ordinal-index} -StatefulSet 中的 Pod 拥有一个唯一的顺序索引和稳定的网络身份标识。 - - -### 检查 Pod 的顺序索引 - - -获取 StatefulSet 的 Pod。 + +获取 StatefulSet 的 Pod： ```shell kubectl get pods -l app=nginx @@ -244,26 +250,31 @@ web-1 1/1 Running 0 1m As mentioned in the [StatefulSets](/docs/concepts/workloads/controllers/statefulset/) concept, the Pods in a StatefulSet have a sticky, unique identity. This identity is based on a unique ordinal index that is assigned to each Pod by the -StatefulSet controller. The Pods' names take the form -`-`. Since the `web` StatefulSet has two -replicas, it creates two Pods, `web-0` and `web-1`. +StatefulSet {{< glossary_tooltip term_id="controller" text="controller">}}. +The Pods' names take the form `-`. +Since the `web` StatefulSet has two replicas, it creates two Pods, `web-0` and `web-1`. +--> +如同 [StatefulSet](/zh-cn/docs/concepts/workloads/controllers/statefulset/) 概念中所提到的， +StatefulSet 中的每个 Pod 拥有一个具有黏性的、独一无二的身份标志。 +这个标志基于 StatefulSet +{{< glossary_tooltip term_id="controller" text="控制器">}}分配给每个 +Pod 的唯一顺序索引。 +Pod 的名称的形式为 `-<序号索引>`。 +`web` StatefulSet 拥有两个副本，所以它创建了两个 Pod：`web-0` 和 `web-1`。 + +### 使用稳定的网络身份标识 {#using-stable-network-identities} + - -如同 [StatefulSets](/zh/docs/concepts/workloads/controllers/statefulset/) 概念中所提到的， -StatefulSet 中的 Pod 拥有一个具有黏性的、独一无二的身份标志。 -这个标志基于 StatefulSet 控制器分配给每个 Pod 的唯一顺序索引。 -Pod 的名称的形式为`-`。 -`web`StatefulSet 拥有两个副本，所以它创建了两个 Pod：`web-0`和`web-1`。 - -### 使用稳定的网络身份标识 - -每个 Pod 都拥有一个基于其顺序索引的稳定的主机名。使用[`kubectl exec`](/zh/docs/reference/generated/kubectl/kubectl-commands/#exec)在每个 Pod 中执行`hostname`。 +每个 Pod 都拥有一个基于其顺序索引的稳定的主机名。使用 +[`kubectl exec`](/docs/reference/generated/kubectl/kubectl-commands/#exec) +在每个 Pod 中执行 `hostname`： ```shell for i in 0 1; do kubectl exec "web-$i" -- sh -c 'hostname'; done @@ -277,28 +288,31 @@ web-1 Use [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) to execute a container that provides the `nslookup` command from the `dnsutils` package. Using `nslookup` on the Pods' hostnames, you can examine their in-cluster DNS -addresses. +addresses: --> - -使用 [`kubectl run`](/zh/docs/reference/generated/kubectl/kubectl-commands/#run) +使用 [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) 运行一个提供 `nslookup` 命令的容器，该命令来自于 `dnsutils` 包。 -通过对 Pod 的主机名执行 `nslookup`，你可以检查他们在集群内部的 DNS 地址。 +通过对 Pod 的主机名执行 `nslookup`，你可以检查他们在集群内部的 DNS 地址： ```shell kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm ``` + -这将启动一个新的 shell。在新 shell 中，运行： +这将启动一个新的 Shell。在新 Shell 中运行： + ```shell # Run this in the dns-test container shell nslookup web-0.nginx ``` + 输出类似于： + ``` Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -314,29 +328,36 @@ Name: web-1.nginx Address 1: 10.244.2.6 ``` + +（现在可以退出容器 Shell：`exit`） + - headless service 的 CNAME 指向 SRV 记录（记录每个 Running 和 Ready 状态的 Pod）。 SRV 记录指向一个包含 Pod IP 地址的记录表项。 -在一个终端中查看 StatefulSet 的 Pod。 + +在一个终端中监视 StatefulSet 的 Pod： ```shell kubectl get pod -w -l app=nginx ``` + - -在另一个终端中使用 [`kubectl delete`](/zh/docs/reference/generated/kubectl/kubectl-commands/#delete) 删除 StatefulSet 中所有的 Pod。 +在另一个终端中使用 +[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) +删除 StatefulSet 中所有的 Pod： ```shell kubectl delete pod -l app=nginx @@ -348,10 +369,9 @@ pod "web-1" deleted - -等待 StatefulSet 重启它们，并且两个 Pod 都变成 Running 和 Ready 状态。 +等待 StatefulSet 重启它们，并且两个 Pod 都变成 Running 和 Ready 状态： ```shell kubectl get pod -w -l app=nginx @@ -368,11 +388,11 @@ web-1 1/1 Running 0 34s ``` - 使用 `kubectl exec` 和 `kubectl run` 查看 Pod 的主机名和集群内部的 DNS 表项。 +首先，查看 Pod 的主机名： ```shell for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done @@ -381,26 +401,32 @@ for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done web-0 web-1 ``` + 然后，运行： + ``` kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh ``` + -这将启动一个新的 shell。在新 shell 中，运行： +这将启动一个新的 Shell。在新 Shell 中，运行： + ```shell # Run this in the dns-test container shell nslookup web-0.nginx ``` + 输出类似于： + ``` Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -415,19 +441,33 @@ Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local Name: web-1.nginx Address 1: 10.244.2.8 ``` + + +（现在可以退出容器 Shell：`exit`） + +Pod 的序号、主机名、SRV 条目和记录名称没有改变，但和 Pod 相关联的 IP 地址可能发生了改变。 +在本教程中使用的集群中它们就改变了。这就是为什么不要在其他应用中使用 +StatefulSet 中 Pod 的 IP 地址进行连接，这点很重要。 - + +如果你需要查找并连接一个 StatefulSet 的活动成员，你应该查询 Headless Service 的 CNAME。 +和 CNAME 相关联的 SRV 记录只会包含 StatefulSet 中处于 Running 和 Ready 状态的 Pod。 + - -Pod 的序号、主机名、SRV 条目和记录名称没有改变，但和 Pod 相关联的 IP 地址可能发生了改变。 -在本教程中使用的集群中它们就改变了。这就是为什么不要在其他应用中使用 StatefulSet 中的 Pod 的 IP 地址进行连接，这点很重要。 - - -如果你需要查找并连接一个 StatefulSet 的活动成员，你应该查询 Headless Service 的 CNAME。 -和 CNAME 相关联的 SRV 记录只会包含 StatefulSet 中处于 Running 和 Ready 状态的 Pod。 - - -如果你的应用已经实现了用于测试 liveness 和 readiness 的连接逻辑，你可以使用 Pod 的 SRV 记录（`web-0.nginx.default.svc.cluster.local`， -`web-1.nginx.default.svc.cluster.local`）。因为他们是稳定的，并且当你的 Pod 的状态变为 Running 和 Ready 时，你的应用就能够发现它们的地址。 - +如果你的应用已经实现了用于测试是否已存活（liveness）并就绪（readiness）的连接逻辑， +你可以使用 Pod 的 SRV 记录（`web-0.nginx.default.svc.cluster.local`、 +`web-1.nginx.default.svc.cluster.local`）。因为他们是稳定的，并且当你的 +Pod 的状态变为 Running 和 Ready 时，你的应用就能够发现它们的地址。 +### 写入稳定的存储 {#writing-to-stable-storage} -### 写入稳定的存储 - -获取 `web-0` 和 `web-1` 的 PersistentVolumeClaims。 + +获取 `web-0` 和 `web-1` 的 PersistentVolumeClaims： ```shell kubectl get pvc -l app=nginx ``` + 输出类似于： + ``` NAME STATUS VOLUME CAPACITY ACCESSMODES AGE www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 48s @@ -472,27 +506,38 @@ www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO ``` +StatefulSet 控制器创建了两个 +{{< glossary_tooltip text="PersistentVolumeClaims" term_id="persistent-volume-claim" >}}， +绑定到两个 +{{< glossary_tooltip text="PersistentVolumes" term_id="persistent-volume" >}}。 -StatefulSet 控制器创建了两个 PersistentVolumeClaims，绑定到两个 [PersistentVolumes](/zh/docs/concepts/storage/volumes/)。由于本教程使用的集群配置为动态提供 PersistentVolume，所有的 PersistentVolume 都是自动创建和绑定的。 + +由于本教程使用的集群配置为动态制备 +PersistentVolume 卷，所有的 PersistentVolume 卷都是自动创建和绑定的。 + +NginX Web 服务器默认会加载位于 `/usr/share/nginx/html/index.html` 的 index 文件。 +StatefulSet `spec` 中的 `volumeMounts` 字段保证了 `/usr/share/nginx/html` +文件夹由一个 PersistentVolume 卷支持。 -NGINX web 服务器默认会加载位于 `/usr/share/nginx/html/index.html` 的 index 文件。 -StatefulSets `spec` 中的 `volumeMounts` 字段保证了 `/usr/share/nginx/html` 文件夹由一个 PersistentVolume 支持。 - - -将 Pod 的主机名写入它们的`index.html`文件并验证 NGINX web 服务器使用该主机名提供服务。 + +将 Pod 的主机名写入它们的 `index.html` 文件并验证 NginX Web 服务器使用该主机名提供服务： ```shell for i in 0 1; do kubectl exec "web-$i" -- sh -c 'echo "$(hostname)" > /usr/share/nginx/html/index.html'; done @@ -511,7 +556,6 @@ you will need to fix the permissions of the directory mounted by the `volumeMoun (due to a [bug when using hostPath volumes](https://github.com/kubernetes/kubernetes/issues/2630)), by running: --> - 请注意，如果你看见上面的 curl 命令返回了 **403 Forbidden** 的响应，你需要像这样修复使用 `volumeMounts` （原因归咎于[使用 hostPath 卷时存在的缺陷](https://github.com/kubernetes/kubernetes/issues/2630)） 挂载的目录的权限 @@ -522,25 +566,22 @@ by running: - 在你重新尝试上面的 `curl` 命令之前。 {{< /note >}} - -在一个终端查看 StatefulSet 的 Pod。 +在一个终端监视 StatefulSet 的 Pod： ```shell kubectl get pod -w -l app=nginx ``` - -在另一个终端删除 StatefulSet 所有的 Pod。 +在另一个终端删除 StatefulSet 所有的 Pod： ```shell kubectl delete pod -l app=nginx @@ -549,11 +590,11 @@ kubectl delete pod -l app=nginx pod "web-0" deleted pod "web-1" deleted ``` + - 在第一个终端里检查 `kubectl get` 命令的输出，等待所有 Pod 变成 Running 和 Ready 状态。 ```shell @@ -571,10 +612,9 @@ web-1 1/1 Running 0 34s ``` - -验证所有 web 服务器在继续使用它们的主机名提供服务。 +验证所有 Web 服务器在继续使用它们的主机名提供服务： ``` for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done @@ -588,35 +628,37 @@ web-1 Even though `web-0` and `web-1` were rescheduled, they continue to serve their hostnames because the PersistentVolumes associated with their PersistentVolumeClaims are remounted to their `volumeMounts`. No matter what -node `web-0`and `web-1` are scheduled on, their PersistentVolumes will be +node `web-0` and `web-1` are scheduled on, their PersistentVolumes will be mounted to the appropriate mount points. +--> +虽然 `web-0` 和 `web-1` 被重新调度了，但它们仍然继续监听各自的主机名，因为和它们的 +PersistentVolumeClaim 相关联的 PersistentVolume 卷被重新挂载到了各自的 `volumeMount` 上。 +不管 `web-0` 和 `web-1` 被调度到了哪个节点上，它们的 PersistentVolume 卷将会被挂载到合适的挂载点上。 + +## 扩容/缩容 StatefulSet {#scaling-a-statefulset} + + - -虽然 `web-0` 和 `web-1` 被重新调度了，但它们仍然继续监听各自的主机名，因为和它们的 PersistentVolumeClaim 相关联的 PersistentVolume 被重新挂载到了各自的 `volumeMount` 上。 -不管 `web-0` 和 `web-1` 被调度到了哪个节点上，它们的 PersistentVolumes 将会被挂载到合适的挂载点上。 - - -## 扩容/缩容 StatefulSet - 扩容/缩容 StatefulSet 指增加或减少它的副本数。这通过更新 `replicas` 字段完成。 -你可以使用[`kubectl scale`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#scale) -或者[`kubectl patch`](/zh/docs/user-guide/kubectl/{{< param "version" >}}/#patch)来扩容/缩容一个 StatefulSet。 +你可以使用 [`kubectl scale`](/docs/reference/generated/kubectl/kubectl-commands/#scale) +或者 [`kubectl patch`](/docs/reference/generated/kubectl/kubectl-commands/#patch) 来扩容/缩容一个 StatefulSet。 + +### 扩容 {#scaling-up} -### 扩容 - - -在一个终端窗口观察 StatefulSet 的 Pod。 + +在一个终端窗口监视 StatefulSet 的 Pod： ```shell kubectl get pods -w -l app=nginx @@ -624,9 +666,9 @@ kubectl get pods -w -l app=nginx - -在另一个终端窗口使用 `kubectl scale` 扩展副本数为 5。 +to 5: +--> +在另一个终端窗口使用 `kubectl scale` 扩展副本数为 5： ```shell kubectl scale sts web --replicas=5 @@ -634,11 +676,11 @@ kubectl scale sts web --replicas=5 ``` statefulset.apps/web scaled ``` + - 在第一个 终端中检查 `kubectl get` 命令的输出，等待增加的 3 个 Pod 的状态变为 Running 和 Ready。 ```shell @@ -669,19 +711,20 @@ The StatefulSet controller scaled the number of replicas. As with created each Pod sequentially with respect to its ordinal index, and it waited for each Pod's predecessor to be Running and Ready before launching the subsequent Pod. - -### Scaling Down - -In one terminal, watch the StatefulSet's Pods. --> - StatefulSet 控制器扩展了副本的数量。 -如同[创建 StatefulSet](#顺序创建pod) 所述，StatefulSet 按序号索引顺序的创建每个 Pod，并且会等待前一个 Pod 变为 Running 和 Ready 才会启动下一个 Pod。 +如同[创建 StatefulSet](#ordered-pod-creation) 所述，StatefulSet 按序号索引顺序创建各个 +Pod，并且会等待前一个 Pod 变为 Running 和 Ready 才会启动下一个 Pod。 -### 缩容 + +### 缩容 {#scaling-down} - -在一个终端观察 StatefulSet 的 Pod。 + +在一个终端监视 StatefulSet 的 Pod： ```shell kubectl get pods -w -l app=nginx @@ -689,10 +732,9 @@ kubectl get pods -w -l app=nginx - -在另一个终端使用 `kubectl patch` 将 StatefulSet 缩容回三个副本。 +在另一个终端使用 `kubectl patch` 将 StatefulSet 缩容回三个副本： ```shell kubectl patch sts web -p '{"spec":{"replicas":3}}' @@ -704,7 +746,6 @@ statefulset.apps/web patched - 等待 `web-4` 和 `web-3` 状态变为 Terminating。 ```shell @@ -727,21 +768,20 @@ web-3 1/1 Terminating 0 42s +### 顺序终止 Pod {#ordered-pod-termination} + - -### 顺序终止 Pod - - 控制器会按照与 Pod 序号索引相反的顺序每次删除一个 Pod。在删除下一个 Pod 前会等待上一个被完全关闭。 - -获取 StatefulSet 的 PersistentVolumeClaims。 + +获取 StatefulSet 的 PersistentVolumeClaims： ```shell kubectl get pvc -l app=nginx @@ -759,46 +799,50 @@ www-web-4 Bound pvc-e11bb5f8-b508-11e6-932f-42010a800002 1Gi RWO +五个 PersistentVolumeClaims 和五个 PersistentVolume 卷仍然存在。 +查看 Pod 的[稳定存储](#stable-storage)，我们发现当删除 StatefulSet 的 +Pod 时，挂载到 StatefulSet 的 Pod 的 PersistentVolume 卷不会被删除。 +当这种删除行为是由 StatefulSet 缩容引起时也是一样的。 + +## 更新 StatefulSet {#updating-statefulsets} + +从 Kubernetes 1.7 版本开始，StatefulSet 控制器支持自动更新。 +更新策略由 StatefulSet API 对象的 `spec.updateStrategy` 字段决定。这个特性能够用来更新一个 +StatefulSet 中 Pod 的的容器镜像、资源请求和限制、标签和注解。 + +`RollingUpdate` 更新策略是 StatefulSet 默认策略。 -五个 PersistentVolumeClaims 和五个 PersistentVolumes 仍然存在。 -查看 Pod 的 [稳定存储](#stable-storage)，我们发现当删除 StatefulSet 的 Pod 时，挂载到 StatefulSet 的 Pod 的 PersistentVolumes 不会被删除。 -当这种删除行为是由 StatefulSet 缩容引起时也是一样的。 - - -## 更新 StatefulSet - - -Kubernetes 1.7 版本的 StatefulSet 控制器支持自动更新。 -更新策略由 StatefulSet API Object 的`spec.updateStrategy` 字段决定。这个特性能够用来更新一个 StatefulSet 中的 Pod 的 container images，resource requests，以及 limits，labels 和 annotations。 -`RollingUpdate`滚动更新是 StatefulSets 默认策略。 - + +### 滚动更新 {#rolling-update} +`RollingUpdate` 更新策略会更新一个 StatefulSet 中的所有 +Pod，采用与序号索引相反的顺序并遵循 StatefulSet 的保证。 -### Rolling Update 策略 - - -`RollingUpdate` 更新策略会更新一个 StatefulSet 中所有的 Pod，采用与序号索引相反的顺序并遵循 StatefulSet 的保证。 - - -Patch `web` StatefulSet 来执行 `RollingUpdate` 更新策略。 + +对 `web` StatefulSet 应用 Patch 操作来应用 `RollingUpdate` 更新策略： ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}' @@ -806,12 +850,12 @@ kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpda ``` statefulset.apps/web patched ``` + - -在一个终端窗口中 patch `web` StatefulSet 来再次的改变容器镜像。 +在一个终端窗口中对 `web` StatefulSet 执行 patch 操作来再次改变容器镜像： ```shell kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"gcr.io/google_containers/nginx-slim:0.8"}]' @@ -821,18 +865,19 @@ statefulset.apps/web patched ``` - -在另一个终端监控 StatefulSet 中的 Pod。 +在另一个终端监控 StatefulSet 中的 Pod： ```shell -kubectl get po -l app=nginx -w +kubectl get pod -l app=nginx -w ``` + 输出类似于： + ``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 7m @@ -874,21 +919,26 @@ StatefulSet controller terminates each Pod, and waits for it to transition to Ru Ready prior to updating the next Pod. Note that, even though the StatefulSet controller will not proceed to update the next Pod until its ordinal successor is Running and Ready, it will restore any Pod that fails during the update to -its current version. Pods that have already received the update will be -restored to the updated version, and Pods that have not yet received the -update will be restored to the previous version. In this way, the controller -attempts to continue to keep the application healthy and the update consistent -in the presence of intermittent failures. - -Get the Pods to view their container images. +its current version. --> +StatefulSet 里的 Pod 采用和序号相反的顺序更新。在更新下一个 Pod 前，StatefulSet +控制器终止每个 Pod 并等待它们变成 Running 和 Ready。 +请注意，虽然在顺序后继者变成 Running 和 Ready 之前 StatefulSet 控制器不会更新下一个 +Pod，但它仍然会重建任何在更新过程中发生故障的 Pod，使用的是它们当前的版本。 -StatefulSet 里的 Pod 采用和序号相反的顺序更新。在更新下一个 Pod 前，StatefulSet 控制器终止每个 Pod 并等待它们变成 Running 和 Ready。 -请注意，虽然在顺序后继者变成 Running 和 Ready 之前 StatefulSet 控制器不会更新下一个 Pod，但它仍然会重建任何在更新过程中发生故障的 Pod，使用的是它们当前的版本。 + 已经接收到更新请求的 Pod 将会被恢复为更新的版本，没有收到请求的 Pod 则会被恢复为之前的版本。 像这样，控制器尝试继续使应用保持健康并在出现间歇性故障时保持更新的一致性。 -获取 Pod 来查看他们的容器镜像。 + +获取 Pod 来查看它们的容器镜像： ```shell for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done @@ -902,32 +952,37 @@ k8s.gcr.io/nginx-slim:0.8 +StatefulSet 中的所有 Pod 现在都在运行之前的容器镜像。 -**Tip** You can also use `kubectl rollout status sts/` to view -the status of a rolling update. +{{< note >}} + +你还可以使用 `kubectl rollout status sts/<名称>` 来查看 +StatefulSet 的滚动更新状态。 +{{< /note >}} + +#### 分段更新 {#staging-an-update} + + - -StatefulSet 中的所有 Pod 现在都在运行之前的容器镜像。 - - -**小窍门**：你还可以使用 `kubectl rollout status sts/` 来查看 rolling update 的状态。 - - -#### 分段更新 - 你可以使用 `RollingUpdate` 更新策略的 `partition` 参数来分段更新一个 StatefulSet。 -分段的更新将会使 StatefulSet 中的其余所有 Pod 保持当前版本的同时仅允许改变 StatefulSet 的 `.spec.template`。 +分段的更新将会使 StatefulSet 中的其余所有 Pod 保持当前版本的同时允许改变 +StatefulSet 的 `.spec.template`。 - -Patch `web` StatefulSet 来对 `updateStrategy` 字段添加一个分区。 + +对 `web` StatefulSet 执行 Patch 操作以为 `updateStrategy` 字段添加一个分区： ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":3}}}}' @@ -937,10 +992,9 @@ statefulset.apps/web patched ``` - -再次 Patch StatefulSet 来改变容器镜像。 +再次 Patch StatefulSet 来改变容器镜像： ```shell kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"k8s.gcr.io/nginx-slim:0.7"}]' @@ -950,10 +1004,9 @@ statefulset.apps/web patched ``` - -删除 StatefulSet 中的 Pod。 +删除 StatefulSet 中的 Pod： ```shell kubectl delete pod web-2 @@ -965,7 +1018,6 @@ pod "web-2" deleted - 等待 Pod 变成 Running 和 Ready。 ```shell @@ -980,10 +1032,9 @@ web-2 1/1 Running 0 18s ``` - -获取 Pod 的容器。 +获取 Pod 的容器镜像： ```shell kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' @@ -994,27 +1045,29 @@ k8s.gcr.io/nginx-slim:0.8 - -请注意，虽然更新策略是 `RollingUpdate`，StatefulSet 控制器还是会使用原始的容器恢复 Pod。 +请注意，虽然更新策略是 `RollingUpdate`，StatefulSet 还是会使用原始的容器恢复 Pod。 这是因为 Pod 的序号比 `updateStrategy` 指定的 `partition` 更小。 + +#### 金丝雀发布 {#rolling-out-a-canary} -#### 灰度发布 + +你可以通过减少[上文](#staging-an-update)指定的 +`partition` 来进行金丝雀发布，以此来测试你的程序的改动。 -你可以通过减少 [上文](#分段更新)指定的 `partition` 来进行灰度发布，以此来测试你的程序的改动。 - - -通过 patch 命令修改 StatefulSet 来减少分区。 + +通过 patch 命令修改 StatefulSet 来减少分区： ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}' @@ -1026,7 +1079,6 @@ statefulset.apps/web patched - 等待 `web-2` 变成 Running 和 Ready。 ```shell @@ -1041,10 +1093,9 @@ web-2 1/1 Running 0 18s ``` - -获取 Pod 的容器。 +获取 Pod 的容器： ```shell kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' @@ -1058,14 +1109,14 @@ k8s.gcr.io/nginx-slim:0.7 When you changed the `partition`, the StatefulSet controller automatically updated the `web-2` Pod because the Pod's ordinal was greater than or equal to the `partition`. - -Delete the `web-1` Pod. --> +当你改变 `partition` 时，StatefulSet 会自动更新 `web-2` +Pod，这是因为 Pod 的序号大于或等于 `partition`。 -当你改变 `partition` 时，StatefulSet 会自动的更新 `web-2` Pod，这是因为 Pod 的序号大于或等于 `partition`。 - - -删除 `web-1` Pod。 + +删除 `web-1` Pod： ```shell kubectl delete pod web-1 @@ -1077,16 +1128,17 @@ pod "web-1" deleted - 等待 `web-1` 变成 Running 和 Ready。 ```shell kubectl get pod -l app=nginx -w ``` + 输出类似于： + ``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 6m @@ -1102,10 +1154,9 @@ web-1 1/1 Running 0 18s ``` - -获取 `web-1` Pod 的容器。 +获取 `web-1` Pod 的容器镜像： ```shell kubectl get pod web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}' @@ -1121,28 +1172,31 @@ ordinal that is greater than or equal to the partition will be updated when the StatefulSet's `.spec.template` is updated. If a Pod that has an ordinal less than the partition is deleted or otherwise terminated, it will be restored to its original configuration. +--> +`web-1` 被按照原来的配置恢复，因为 Pod 的序号小于分区。当指定了分区时，如果更新了 +StatefulSet 的 `.spec.template`，则所有序号大于或等于分区的 Pod 都将被更新。 +如果一个序号小于分区的 Pod 被删除或者终止，它将被按照原来的配置恢复。 + +#### 分阶段的发布 {#phased-roll-outs} + + - -`web-1` 被按照原来的配置恢复，因为 Pod 的序号小于分区。当指定了分区时，如果更新了 StatefulSet 的 `.spec.template`，则所有序号大于或等于分区的 Pod 都将被更新。 -如果一个序号小于分区的 Pod 被删除或者终止，它将被按照原来的配置恢复。 - - -#### 分阶段的发布 - -你可以使用类似[灰度发布](#灰度发布)的方法执行一次分阶段的发布（例如一次线性的、等比的或者指数形式的发布）。 +你可以使用类似[金丝雀发布](#rolling-out-a-canary)的方法执行一次分阶段的发布 +（例如一次线性的、等比的或者指数形式的发布）。 要执行一次分阶段的发布，你需要设置 `partition` 为希望控制器暂停更新的序号。 - -分区当前为`2`。请将分区设置为`0`。 + +分区当前为 `2`。请将分区设置为 `0`： ```shell kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":0}}}}' @@ -1154,16 +1208,17 @@ statefulset.apps/web patched - 等待 StatefulSet 中的所有 Pod 变成 Running 和 Ready。 ```shell kubectl get pod -l app=nginx -w ``` + 输出类似于： + ``` NAME READY STATUS RESTARTS AGE web-0 1/1 Running 0 3m @@ -1181,11 +1236,11 @@ web-0 0/1 Pending 0 0s web-0 0/1 ContainerCreating 0 0s web-0 1/1 Running 0 3s ``` - -获取 Pod 的容器。 + +获取 StatefulSet 中 Pod 的容器镜像详细信息： ```shell for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done @@ -1197,46 +1252,48 @@ k8s.gcr.io/nginx-slim:0.7 ``` +将 `partition` 改变为 `0` 以允许 StatefulSet 继续更新过程。 + +### OnDelete 策略 {#on-delete} + +`OnDelete` 更新策略实现了传统（1.7 之前）行为，它也是默认的更新策略。 +当你选择这个更新策略并修改 StatefulSet 的 `.spec.template` 字段时，StatefulSet 控制器将不会自动更新 Pod。 - + +## 删除 StatefulSet {#deleting-statefulsets} + +StatefulSet 同时支持级联和非级联删除。使用非级联方式删除 StatefulSet 时，StatefulSet +的 Pod 不会被删除。使用级联删除时，StatefulSet 和它的 Pod 都会被删除。 + +### 非级联删除 {#non-cascading-delete} + - -将 `partition` 改变为 `0` 以允许 StatefulSet 控制器继续更新过程。 - -### On Delete 策略 - -`OnDelete` 更新策略实现了传统（1.7 之前）行为，它也是默认的更新策略。 -当你选择这个更新策略并修改 StatefulSet 的 `.spec.template` 字段时，StatefulSet 控制器将不会自动的更新 Pod。 - -## 删除 StatefulSet - - -StatefulSet 同时支持级联和非级联删除。使用非级联方式删除 StatefulSet 时，StatefulSet 的 Pod 不会被删除。使用级联删除时，StatefulSet 和它的 Pod 都会被删除。 - - -### 非级联删除 - - -在一个终端窗口查看 StatefulSet 中的 Pod。 +在一个终端窗口监视 StatefulSet 中的 Pod。 ``` kubectl get pods -w -l app=nginx @@ -1248,9 +1305,9 @@ StatefulSet. Make sure to supply the `--cascade=orphan` parameter to the command. This parameter tells Kubernetes to only delete the StatefulSet, and to not delete any of its Pods. --> - -使用 [`kubectl delete`](/zh/docs/reference/generated/kubectl/kubectl-commands/#delete) 删除 StatefulSet。 -请确保提供了 `--cascade=orphan` 参数给命令。这个参数告诉 Kubernetes 只删除 StatefulSet 而不要删除它的任何 Pod。 +使用 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) +删除 StatefulSet。请确保提供了 `--cascade=orphan` 参数给命令。这个参数告诉 +Kubernetes 只删除 StatefulSet 而不要删除它的任何 Pod。 ```shell kubectl delete statefulset web --cascade=orphan @@ -1260,10 +1317,9 @@ statefulset.apps "web" deleted ``` - -获取 Pod 来检查他们的状态。 +获取 Pod 来检查它们的状态： ```shell kubectl get pods -l app=nginx @@ -1277,11 +1333,10 @@ web-2 1/1 Running 0 5m - 虽然 `web` 已经被删除了，但所有 Pod 仍然处于 Running 和 Ready 状态。 -删除 `web-0`。 +删除 `web-0`： ```shell kubectl delete pod web-0 @@ -1291,10 +1346,9 @@ pod "web-0" deleted ``` - -获取 StatefulSet 的 Pod。 +获取 StatefulSet 的 Pod： ```shell kubectl get pods -l app=nginx @@ -1307,13 +1361,12 @@ web-2 1/1 Running 0 7m +由于 `web` StatefulSet 已经被删除，`web-0` 没有被重新启动。 + - -由于 `web` StatefulSet 已经被删除，`web-0`没有被重新启动。 - - 在一个终端监控 StatefulSet 的 Pod。 ```shell @@ -1322,10 +1375,11 @@ kubectl get pods -w -l app=nginx -在另一个终端里重新创建 StatefulSet。请注意，除非你删除了 `nginx` Service （你不应该这样做），你将会看到一个错误，提示 Service 已经存在。 +在另一个终端里重新创建 StatefulSet。请注意，除非你删除了 `nginx` +Service（你不应该这样做），你将会看到一个错误，提示 Service 已经存在。 ```shell kubectl apply -f web.yaml @@ -1334,16 +1388,17 @@ kubectl apply -f web.yaml statefulset.apps/web created service/nginx unchanged ``` - +请忽略这个错误。它仅表示 kubernetes 进行了一次创建 _nginx_ headless Service +的尝试，尽管那个 Service 已经存在。 + + - -请忽略这个错误。它仅表示 kubernetes 进行了一次创建 nginx Headless Service 的尝试，尽管那个 Service 已经存在。 - - 在第一个终端中运行并检查 `kubectl get` 命令的输出。 ```shell @@ -1371,18 +1426,17 @@ Running and Ready, it adopted this Pod. Since you recreated the StatefulSet with `replicas` equal to 2, once `web-0` had been recreated, and once `web-1` had been determined to already be Running and Ready, `web-2` was terminated. - -Let's take another look at the contents of the `index.html` file served by the -Pods' webservers: --> - 当重新创建 `web` StatefulSet 时，`web-0` 被第一个重新启动。 由于 `web-1` 已经处于 Running 和 Ready 状态，当 `web-0` 变成 Running 和 Ready 时， StatefulSet 会接收这个 Pod。由于你重新创建的 StatefulSet 的 `replicas` 等于 2， 一旦 `web-0` 被重新创建并且 `web-1` 被认为已经处于 Running 和 Ready 状态时，`web-2` 将会被终止。 - -让我们再看看被 Pod 的 web 服务器加载的 `index.html` 的内容： + +让我们再看看被 Pod 的 Web 服务器加载的 `index.html` 的内容： ```shell for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done @@ -1399,21 +1453,20 @@ serves the hostname originally entered into its `index.html` file. This is because the StatefulSet never deletes the PersistentVolumes associated with a Pod. When you recreated the StatefulSet and it relaunched `web-0`, its original PersistentVolume was remounted. +--> +尽管你同时删除了 StatefulSet 和 `web-0` Pod，但它仍然使用最初写入 `index.html` 文件的主机名进行服务。 +这是因为 StatefulSet 永远不会删除和一个 Pod 相关联的 PersistentVolume 卷。 +当你重建这个 StatefulSet 并且重新启动了 `web-0` 时，它原本的 PersistentVolume 卷会被重新挂载。 + +### 级联删除 {#cascading-delete} + - -尽管你同时删除了 StatefulSet 和 `web-0` Pod，但它仍然使用最初写入 `index.html` 文件的主机名进行服务。 -这是因为 StatefulSet 永远不会删除和一个 Pod 相关联的 PersistentVolumes。 -当你重建这个 StatefulSet 并且重新启动了 `web-0` 时，它原本的 PersistentVolume 会被重新挂载。 - - -### 级联删除 - - -在一个终端窗口观察 StatefulSet 里的 Pod。 +在一个终端窗口监视 StatefulSet 里的 Pod。 ```shell kubectl get pods -w -l app=nginx @@ -1423,7 +1476,6 @@ kubectl get pods -w -l app=nginx In another terminal, delete the StatefulSet again. This time, omit the `--cascade=orphan` parameter. --> - 在另一个窗口中再次删除这个 StatefulSet。这次省略 `--cascade=orphan` 参数。 ```shell @@ -1438,7 +1490,6 @@ statefulset.apps "web" deleted Examine the output of the `kubectl get` command running in the first terminal, and wait for all of the Pods to transition to Terminating. --> - 在第一个终端检查 `kubectl get` 命令的输出，并等待所有的 Pod 变成 Terminating 状态。 ```shell @@ -1466,17 +1517,19 @@ As you saw in the [Scaling Down](#scaling-down) section, the Pods are terminated one at a time, with respect to the reverse order of their ordinal indices. Before terminating a Pod, the StatefulSet controller waits for the Pod's successor to be completely terminated. - -Note that, while a cascading delete will delete the StatefulSet and its Pods, -it will not delete the Headless Service associated with the StatefulSet. You -must delete the `nginx` Service manually. --> - 如同你在[缩容](#ordered-pod-termination)一节看到的，Pod 按照和他们序号索引相反的顺序每次终止一个。 在终止一个 Pod 前，StatefulSet 控制器会等待 Pod 后继者被完全终止。 - -请注意，虽然级联删除会删除 StatefulSet 和它的 Pod，但它并不会删除和 StatefulSet 关联的 Headless Service。你必须手动删除`nginx` Service。 +{{< note >}} + +尽管级联删除会删除 StatefulSet 及其 Pod，但级联不会删除与 StatefulSet +关联的 Headless Service。你必须手动删除 `nginx` Service。 +{{< /note >}} ```shell kubectl delete service nginx @@ -1487,10 +1540,9 @@ service "nginx" deleted ``` - -再一次重新创建 StatefulSet 和 Headless Service。 +再一次重新创建 StatefulSet 和 headless Service： ```shell kubectl apply -f web.yaml @@ -1503,10 +1555,9 @@ statefulset.apps/web created - -当 StatefulSet 所有的 Pod 变成 Running 和 Ready 时，获取它们的 `index.html` 文件的内容。 +当 StatefulSet 所有的 Pod 变成 Running 和 Ready 时，获取它们的 `index.html` 文件的内容： ```shell for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done @@ -1520,15 +1571,15 @@ web-1 +即使你已经删除了 StatefulSet 和它的全部 Pod，这些 Pod 将会被重新创建并挂载它们的 +PersistentVolume 卷，并且 `web-0` 和 `web-1` 将继续使用它的主机名提供服务。 -即使你已经删除了 StatefulSet 和它的全部 Pod，这些 Pod 将会被重新创建并挂载它们的 PersistentVolumes，并且 `web-0` 和 `web-1` 将仍然使用它们的主机名提供服务。 - - -最后删除 `nginx` service... + +最后删除 `nginx` service ```shell kubectl delete service nginx @@ -1538,7 +1589,10 @@ kubectl delete service nginx service "nginx" deleted ``` -... 并且删除 `web` StatefulSet: + +并且删除 `web` StatefulSet: ```shell kubectl delete statefulset web @@ -1550,74 +1604,73 @@ statefulset "web" deleted +## Pod 管理策略 {#pod-management-policy} + - -## Pod 管理策略 - - - 对于某些分布式系统来说，StatefulSet 的顺序性保证是不必要和/或者不应该的。 这些系统仅仅要求唯一性和身份标志。为了解决这个问题，在 Kubernetes 1.7 中 我们针对 StatefulSet API 对象引入了 `.spec.podManagementPolicy`。 此选项仅影响扩缩操作的行为。更新不受影响。 -### OrderedReady Pod 管理策略 + +### OrderedReady Pod 管理策略 {#orderedready-pod-management} + +`OrderedReady` Pod 管理策略是 StatefulSet 的默认选项。它告诉 +StatefulSet 控制器遵循上文展示的顺序性保证。 -`OrderedReady` pod 管理策略是 StatefulSets 的默认选项。它告诉 StatefulSet 控制器遵循上文展示的顺序性保证。 + +### Parallel Pod 管理策略 {#parallel-pod-management} - -### Parallel Pod 管理策略 - - -`Parallel` pod 管理策略告诉 StatefulSet 控制器并行的终止所有 Pod， + +`Parallel` Pod 管理策略告诉 StatefulSet 控制器并行的终止所有 Pod， 在启动或终止另一个 Pod 前，不必等待这些 Pod 变成 Running 和 Ready 或者完全终止状态。 {{< codenew file="application/web/web-parallel.yaml" >}} - 下载上面的例子并保存为 `web-parallel.yaml`。 + +这份清单和你在上文下载的完全一样，只是 `web` StatefulSet 的 +`.spec.podManagementPolicy` 设置成了 `Parallel`。 -这份清单和你在上文下载的完全一样，只是 `web` StatefulSet 的 `.spec.podManagementPolicy` 设置成了 `Parallel`。 - - -在一个终端窗口查看 StatefulSet 中的 Pod。 + +在一个终端窗口监视 StatefulSet 中的 Pod。 ```shell -kubectl get po -lapp=nginx -w +kubectl get pod -l app=nginx -w ``` - 在另一个终端窗口创建清单中的 StatefulSet 和 Service： ```shell @@ -1631,7 +1684,6 @@ statefulset.apps/web created - 查看你在第一个终端中运行的 `kubectl get` 命令的输出。 ```shell @@ -1651,14 +1703,14 @@ web-1 1/1 Running 0 10s - StatefulSet 控制器同时启动了 `web-0` 和 `web-1`。 -保持第二个终端打开，并在另一个终端窗口中扩容 StatefulSet。 + +保持第二个终端打开，并在另一个终端窗口中扩容 StatefulSet： ```shell kubectl scale statefulset/web --replicas=4 @@ -1670,7 +1722,6 @@ statefulset.apps/web scaled - 在 `kubectl get` 命令运行的终端里检查它的输出。 ``` @@ -1685,17 +1736,15 @@ web-3 1/1 Running 0 26s - StatefulSet 启动了两个新的 Pod，而且在启动第二个之前并没有等待第一个变成 Running 和 Ready 状态。 ## {{% heading "cleanup" %}} + 你应该打开两个终端，准备在清理过程中运行 `kubectl` 命令。 ```shell @@ -1706,8 +1755,7 @@ kubectl delete sts web - -你可以监测 `kubectl get` 来查看那些 Pod 被删除 +你可以监视 `kubectl get` 来查看那些 Pod 被删除 ```shell kubectl get pod -l app=nginx -w @@ -1739,37 +1787,33 @@ web-3 0/1 Terminating 0 9m ``` +在删除过程中，StatefulSet 将并发的删除所有 Pod，在删除一个 +Pod 前不会等待它的顺序后继者终止。 -StatefulSet 控制器将并发的删除所有 Pod，在删除一个 Pod 前不会等待它的顺序后继者终止。 - - -关闭 `kubectl get` 命令运行的终端并删除`nginx` Service。 + +关闭 `kubectl get` 命令运行的终端并删除 `nginx` Service： ```shell kubectl delete svc nginx ``` - -## {{% heading "cleanup" %}} - - +{{< note >}} +你需要删除本教程中用到的 PersistentVolume 卷的持久化存储介质。 - + - -你需要删除本教程中用到的 PersistentVolumes 的持久化存储介质。基于你的环境、存储配置和提供方式，按照必须的步骤保证回收所有的存储。 - - - +基于你的环境、存储配置和制备方式，按照必须的步骤保证回收所有的存储。 +{{< /note >}} \ No newline at end of file From fc4db89d6ed18bbd048021880bc1925c2a540d52 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sat, 18 Jun 2022 15:23:19 +0800 Subject: [PATCH 11/25] Reformat blog case studies page --- .../new-content/blogs-case-studies.md | 164 ++++++++++++------ 1 file changed, 115 insertions(+), 49 deletions(-) diff --git a/content/en/docs/contribute/new-content/blogs-case-studies.md b/content/en/docs/contribute/new-content/blogs-case-studies.md index 83b950105c..3034f66ce8 100644 --- a/content/en/docs/contribute/new-content/blogs-case-studies.md +++ b/content/en/docs/contribute/new-content/blogs-case-studies.md @@ -16,16 +16,17 @@ Case studies require extensive review before they're approved. ## The Kubernetes Blog -The Kubernetes blog is used by the project to communicate new features, community reports, and any news that might be relevant to the Kubernetes community. -This includes end users and developers. -Most of the blog's content is about things happening in the core project, but we encourage you to submit about things happening elsewhere in the ecosystem too! +The Kubernetes blog is used by the project to communicate new features, community reports, and any +news that might be relevant to the Kubernetes community. This includes end users and developers. +Most of the blog's content is about things happening in the core project, but we encourage you to +submit about things happening elsewhere in the ecosystem too! Anyone can write a blog post and submit it for review. ### Submit a Post -Blog posts should not be commercial in nature and should consist of original content that applies broadly to the Kubernetes community. -Appropriate blog content includes: +Blog posts should not be commercial in nature and should consist of original content that applies +broadly to the Kubernetes community. Appropriate blog content includes: - New Kubernetes capabilities - Kubernetes projects updates @@ -43,75 +44,138 @@ Unsuitable content includes: To submit a blog post, follow these steps: -1. [Sign the CLA](https://kubernetes.io/docs/contribute/start/#sign-the-cla) if you have not yet done so. -1. Have a look at the Markdown format for existing blog posts in the [website repository](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts). +1. [Sign the CLA](https://github.com/kubernetes/community/blob/master/CLA.md) + if you have not yet done so. + +1. Have a look at the Markdown format for existing blog posts in the + [website repository](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts). + 1. Write out your blog post in a text editor of your choice. -1. On the same link from step 2, click the Create new file button. Paste your content into the editor. Name the file to match the proposed title of the blog post, but don’t put the date in the file name. The blog reviewers will work with you on the final file name and the date the blog will be published. + +1. On the same link from step 2, click the Create new file button. Paste your content into the editor. + Name the file to match the proposed title of the blog post, but don’t put the date in the file name. + The blog reviewers will work with you on the final file name and the date the blog will be published. + 1. When you save the file, GitHub will walk you through the pull request process. -1. A blog post reviewer will review your submission and work with you on feedback and final details. When the blog post is approved, the blog will be scheduled for publication. + +1. A blog post reviewer will review your submission and work with you on feedback and final details. + When the blog post is approved, the blog will be scheduled for publication. ### Guidelines and expectations - Blog posts should not be vendor pitches. - - Articles must contain content that applies broadly to the Kubernetes community. For example, a submission should focus on upstream Kubernetes as opposed to vendor-specific configurations. Check the [Documentation style guide](/docs/contribute/style/content-guide/#what-s-allowed) for what is typically allowed on Kubernetes properties. - - Links should primarily be to the official Kubernetes documentation. When using external references, links should be diverse - For example a submission shouldn't contain only links back to a single company's blog. - - Sometimes this is a delicate balance. The [blog team](https://kubernetes.slack.com/messages/sig-docs-blog/) is there to give guidance on whether a post is appropriate for the Kubernetes blog, so don't hesitate to reach out. + + - Articles must contain content that applies broadly to the Kubernetes community. For example, a + submission should focus on upstream Kubernetes as opposed to vendor-specific configurations. + Check the [Documentation style guide](/docs/contribute/style/content-guide/#what-s-allowed) for + what is typically allowed on Kubernetes properties. + - Links should primarily be to the official Kubernetes documentation. When using external + references, links should be diverse - For example a submission shouldn't contain only links + back to a single company's blog. + - Sometimes this is a delicate balance. The [blog team](https://kubernetes.slack.com/messages/sig-docs-blog/) + is there to give guidance on whether a post is appropriate for the Kubernetes blog, so don't + hesitate to reach out. + - Blog posts are not published on specific dates. - - Articles are reviewed by community volunteers. We'll try our best to accommodate specific timing, but we make no guarantees. - - Many core parts of the Kubernetes projects submit blog posts during release windows, delaying publication times. Consider submitting during a quieter period of the release cycle. - - If you are looking for greater coordination on post release dates, coordinating with [CNCF marketing](https://www.cncf.io/about/contact/) is a more appropriate choice than submitting a blog post. - - Sometimes reviews can get backed up. If you feel your review isn't getting the attention it needs, you can reach out to the blog team via [this slack channel](https://kubernetes.slack.com/messages/sig-docs-blog/) to ask in real time. + + - Articles are reviewed by community volunteers. We'll try our best to accommodate specific + timing, but we make no guarantees. + - Many core parts of the Kubernetes projects submit blog posts during release windows, delaying + publication times. Consider submitting during a quieter period of the release cycle. + - If you are looking for greater coordination on post release dates, coordinating with + [CNCF marketing](https://www.cncf.io/about/contact/) is a more appropriate choice than submitting a blog post. + - Sometimes reviews can get backed up. If you feel your review isn't getting the attention it needs, + you can reach out to the blog team via [this slack channel](https://kubernetes.slack.com/messages/sig-docs-blog/) + to ask in real time. + - Blog posts should be relevant to Kubernetes users. - - Topics related to participation in or results of Kubernetes SIGs activities are always on topic (see the work in the [Upstream Marketing Team](https://github.com/kubernetes/community/blob/master/communication/marketing-team/blog-guidelines.md#upstream-marketing-blog-guidelines) for support on these posts). - - The components of Kubernetes are purposely modular, so tools that use existing integration points like CNI and CSI are on topic. - - Posts about other CNCF projects may or may not be on topic. We recommend asking the blog team before submitting a draft. - - Many CNCF projects have their own blog. These are often a better choice for posts. There are times of major feature or milestone for a CNCF project that users would be interested in reading on the Kubernetes blog. - - Blog posts about contributing to the Kubernetes project should be in the [Kubernetes Contributors site](https://kubernetes.dev) + + - Topics related to participation in or results of Kubernetes SIGs activities are always on + topic (see the work in the [Upstream Marketing Team](https://github.com/kubernetes/community/blob/master/communication/marketing-team/blog-guidelines.md#upstream-marketing-blog-guidelines) + for support on these posts). + - The components of Kubernetes are purposely modular, so tools that use existing integration + points like CNI and CSI are on topic. + - Posts about other CNCF projects may or may not be on topic. We recommend asking the blog team + before submitting a draft. + - Many CNCF projects have their own blog. These are often a better choice for posts. There are + times of major feature or milestone for a CNCF project that users would be interested in + reading on the Kubernetes blog. + - Blog posts about contributing to the Kubernetes project should be in the + [Kubernetes Contributors site](https://kubernetes.dev) + - Blog posts should be original content + - The official blog is not for repurposing existing content from a third party as new content. - - The [license](https://github.com/kubernetes/website/blob/main/LICENSE) for the blog allows commercial use of the content for commercial purposes, but not the other way around. + - The [license](https://github.com/kubernetes/website/blob/main/LICENSE) for the blog allows + commercial use of the content for commercial purposes, but not the other way around. + - Blog posts should aim to be future proof - - Given the development velocity of the project, we want evergreen content that won't require updates to stay accurate for the reader. - - It can be a better choice to add a tutorial or update official documentation than to write a high level overview as a blog post. - - Consider concentrating the long technical content as a call to action of the blog post, and focus on the problem space or why readers should care. + + - Given the development velocity of the project, we want evergreen content that won't require + updates to stay accurate for the reader. + - It can be a better choice to add a tutorial or update official documentation than to write a + high level overview as a blog post. + - Consider concentrating the long technical content as a call to action of the blog post, and + focus on the problem space or why readers should care. ### Technical Considerations for submitting a blog post -Submissions need to be in Markdown format to be used by the [Hugo](https://gohugo.io/) generator for the blog. There are [many resources available](https://gohugo.io/documentation/) on how to use this technology stack. +Submissions need to be in Markdown format to be used by the [Hugo](https://gohugo.io/) generator +for the blog. There are [many resources available](https://gohugo.io/documentation/) on how to use +this technology stack. -We recognize that this requirement makes the process more difficult for less-familiar folks to submit, and we're constantly looking at solutions to lower this bar. If you have ideas on how to lower the barrier, please volunteer to help out. +We recognize that this requirement makes the process more difficult for less-familiar folks to +submit, and we're constantly looking at solutions to lower this bar. If you have ideas on how to +lower the barrier, please volunteer to help out. -The SIG Docs [blog subproject](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) manages the review process for blog posts. For more information, see [Submit a post](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post). +The SIG Docs [blog subproject](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) +manages the review process for blog posts. For more information, see +[Submit a post](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post). To submit a blog post follow these directions: -- [Open a pull request](/docs/contribute/new-content/open-a-pr/#fork-the-repo) with a new blog post. New blog posts go under the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/main/content/en/blog/_posts) directory. +- [Open a pull request](/docs/contribute/new-content/open-a-pr/#fork-the-repo) with a new blog post. + New blog posts go under the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/main/content/en/blog/_posts) + directory. -- Ensure that your blog post follows the correct naming conventions and the following frontmatter (metadata) information: +- Ensure that your blog post follows the correct naming conventions and the following frontmatter + (metadata) information: - - The Markdown file name must follow the format `YYYY-MM-DD-Your-Title-Here.md`. For example, `2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`. - - Do **not** include dots in the filename. A name like `2020-01-01-whats-new-in-1.19.md` causes failures during a build. + - The Markdown file name must follow the format `YYYY-MM-DD-Your-Title-Here.md`. For example, + `2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`. + - Do **not** include dots in the filename. A name like `2020-01-01-whats-new-in-1.19.md` causes + failures during a build. - The front matter must include the following: - ```yaml - --- - layout: blog - title: "Your Title Here" - date: YYYY-MM-DD - slug: text-for-URL-link-here-no-spaces - --- - ``` - - The first or initial commit message should be a short summary of the work being done and should stand alone as a description of the blog post. Please note that subsequent edits to your blog will be squashed into this main commit, so it should be as useful as possible. + ```yaml + --- + layout: blog + title: "Your Title Here" + date: YYYY-MM-DD + slug: text-for-URL-link-here-no-spaces + --- + ``` + + - The first or initial commit message should be a short summary of the work being done and + should stand alone as a description of the blog post. Please note that subsequent edits to + your blog will be squashed into this main commit, so it should be as useful as possible. + - Examples of a good commit message: - - _Add blog post on the foo kubernetes feature_ - - _blog: foobar announcement_ + - _Add blog post on the foo kubernetes feature_ + - _blog: foobar announcement_ - Examples of bad commit message: - _Add blog post_ - _._ - _initial commit_ - _draft post_ - - The blog team will then review your PR and give you comments on things you might need to fix. After that the bot will merge your PR and your blog post will be published. - - If the content of the blog post contains only content that is not expected to require updates to stay accurate for the reader, it can be marked as evergreen and exempted from the automatic warning about outdated content added to blog posts older than one year. + + - The blog team will then review your PR and give you comments on things you might need to fix. + After that the bot will merge your PR and your blog post will be published. + + - If the content of the blog post contains only content that is not expected to require updates + to stay accurate for the reader, it can be marked as evergreen and exempted from the automatic + warning about outdated content added to blog posts older than one year. + - To mark a blog post as evergreen, add this to the front matter: ```yaml @@ -121,13 +185,15 @@ To submit a blog post follow these directions: - **Tutorials** that only apply to specific releases or versions and not all future versions - References to pre-GA APIs or features - ## Submit a case study -Case studies highlight how organizations are using Kubernetes to solve -real-world problems. The Kubernetes marketing team and members of the {{< glossary_tooltip text="CNCF" term_id="cncf" >}} collaborate with you on all case studies. +Case studies highlight how organizations are using Kubernetes to solve real-world problems. The +Kubernetes marketing team and members of the {{< glossary_tooltip text="CNCF" term_id="cncf" >}} +collaborate with you on all case studies. Have a look at the source for the [existing case studies](https://github.com/kubernetes/website/tree/main/content/en/case-studies). -Refer to the [case study guidelines](https://github.com/cncf/foundation/blob/master/case-study-guidelines.md) and submit your request as outlined in the guidelines. +Refer to the [case study guidelines](https://github.com/cncf/foundation/blob/master/case-study-guidelines.md) +and submit your request as outlined in the guidelines. + From 1db141c2ee247bf138c389d8dca0555905f24a4f Mon Sep 17 00:00:00 2001 From: Arhell Date: Sat, 18 Jun 2022 10:39:09 +0300 Subject: [PATCH 12/25] [zh] fix typo rbac-good-practices.md --- content/zh-cn/docs/concepts/security/rbac-good-practices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh-cn/docs/concepts/security/rbac-good-practices.md b/content/zh-cn/docs/concepts/security/rbac-good-practices.md index f4e7c2237a..3e9ed6ef07 100644 --- a/content/zh-cn/docs/concepts/security/rbac-good-practices.md +++ b/content/zh-cn/docs/concepts/security/rbac-good-practices.md @@ -157,7 +157,7 @@ Within Kubernetes RBAC there are a number of privileges which, if granted, can a to escalate their privileges in the cluster or affect systems outside the cluster. This section is intended to provide visibility of the areas where cluster operators -should take care, to ensure that they do not inadvertantly allow for more access to clusters than intended. +should take care, to ensure that they do not inadvertently allow for more access to clusters than intended. --> ## Kubernetes RBAC - 权限提权的风险 {#privilege-escalation-risks} From f1f9a50f36bffaae9af7e44d29d7a06ac08814a2 Mon Sep 17 00:00:00 2001 From: Daniel Teunis Date: Sat, 18 Jun 2022 22:06:36 +0200 Subject: [PATCH 13/25] Fix typo in assign-pods-nodes.md Fix typo in 'tasks/configure-pod-container/assign-pods-nodes.md' (chose -> choose). --- .../en/docs/tasks/configure-pod-container/assign-pods-nodes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/configure-pod-container/assign-pods-nodes.md b/content/en/docs/tasks/configure-pod-container/assign-pods-nodes.md index f1e6e6e9ef..1e19a26fbb 100644 --- a/content/en/docs/tasks/configure-pod-container/assign-pods-nodes.md +++ b/content/en/docs/tasks/configure-pod-container/assign-pods-nodes.md @@ -34,7 +34,7 @@ Kubernetes cluster. worker1 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker1 worker2 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker2 ``` -1. Chose one of your nodes, and add a label to it: +1. Choose one of your nodes, and add a label to it: ```shell kubectl label nodes disktype=ssd From c9015d21599a8a37bfbc63bb686c45c342b72ec0 Mon Sep 17 00:00:00 2001 From: Rishit Dagli Date: Sun, 19 Jun 2022 05:46:26 +0000 Subject: [PATCH 14/25] Update Jobs page for 1.24 --- content/en/docs/concepts/workloads/controllers/job.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/en/docs/concepts/workloads/controllers/job.md b/content/en/docs/concepts/workloads/controllers/job.md index b7067ae0b8..9d917505de 100644 --- a/content/en/docs/concepts/workloads/controllers/job.md +++ b/content/en/docs/concepts/workloads/controllers/job.md @@ -691,7 +691,6 @@ In order to use this behavior, you must enable the `JobTrackingWithFinalizers` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/) and the [controller manager](/docs/reference/command-line-tools-reference/kube-controller-manager/). -It is enabled by default. When enabled, the control plane tracks new Jobs using the behavior described below. Jobs created before the feature was enabled are unaffected. As a user, From cddd7a1fc9cd7edc30ebf2acf462bdfe488c6998 Mon Sep 17 00:00:00 2001 From: Michael Date: Sat, 18 Jun 2022 11:16:37 +0800 Subject: [PATCH 15/25] [zh] resyn ref-k8s-api-config: persistent-volume-claim-v1.md --- .../persistent-volume-claim-v1.md | 993 ++++++++++++++++++ 1 file changed, 993 insertions(+) create mode 100644 content/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-claim-v1.md diff --git a/content/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-claim-v1.md b/content/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-claim-v1.md new file mode 100644 index 0000000000..cfe2fd37ab --- /dev/null +++ b/content/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-claim-v1.md @@ -0,0 +1,993 @@ +--- +api_metadata: + apiVersion: "v1" + import: "k8s.io/api/core/v1" + kind: "PersistentVolumeClaim" +content_type: "api_reference" +description: "PersistentVolumeClaim 是用户针对一个持久卷的请求和申领。" +title: "PersistentVolumeClaim" +weight: 4 +--- + + +`apiVersion: v1` + +`import "k8s.io/api/core/v1"` + +## PersistentVolumeClaim {#PersistentVolumeClaim} + +PersistentVolumeClaim 是用户针对一个持久卷的请求和申领。 + +
+ +- **apiVersion**: v1 + +- **kind**: PersistentVolumeClaim + + +- **metadata** (}}">ObjectMeta) + + 标准的对象元数据。更多信息： + https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata + +- **spec** (}}">PersistentVolumeClaimSpec) + + spec 定义 Pod 作者所请求的卷的预期特征。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes#persistentvolumeclaims + + +- **status** (}}">PersistentVolumeClaimStatus) + + status 表示一个持久卷申领的当前信息/状态。只读。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes#persistentvolumeclaims + +## PersistentVolumeClaimSpec {#PersistentVolumeClaimSpec} + +PersistentVolumeClaimSpec 描述存储设备的常用参数，并支持通过 source 来设置特定于提供商的属性。 + +
+ +- **accessModes** ([]string) + + accessModes 包含卷应具备的预期访问模式。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes#access-modes-1 + +- **selector** (}}">LabelSelector) + + selector 是在绑定时对卷进行选择所执行的标签查询。 + + +- **resources** (ResourceRequirements) + + resources 表示卷应拥有的最小资源。 + 如果启用了 RecoverVolumeExpansionFailure 功能特性，则允许用户指定这些资源要求， + 此值必须低于之前的值，但必须高于申领的状态字段中记录的容量。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes#resources + + + **ResourceRequirements 描述计算资源要求。** + + - **resources.limits** (map[string]}}">Quantity) + + limits 描述允许的最大计算资源量。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/ + + - **resources.requests** (map[string]}}">Quantity) + + requests 描述所需的最小计算资源量。 + 如果针对容器省略 requests，则在显式指定的情况下默认为 limits，否则为具体实现所定义的值。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/ + + +- **volumeName** (string) + + volumeName 是对此申领所对应的 PersistentVolume 的绑定引用。 + +- **storageClassName** (string) + + storageClassName 是此申领所要求的 StorageClass 名称。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes#class-1 + +- **volumeMode** (string) + + volumeMode 定义申领需要哪种类别的卷。当申领规约中未包含此字段时，意味着取值为 Filesystem。 + + +### Alpha 级别 +- **dataSource** (}}">TypedLocalObjectReference) + + dataSource 字段可用于二选一： + + * 现有的 VolumeSnapshot 对象（snapshot.storage.k8s.io/VolumeSnapshot） + + * 现有的 PVC (PersistentVolumeClaim) + + 如果制备器或外部控制器可以支持指定的数据源，则它将根据指定数据源的内容创建新的卷。 + 如果 AnyVolumeDataSource 特性门控被启用，此字段的内容将始终与 dataSourceRef 字段内容相同。 + + +- **dataSourceRef** (}}">TypedLocalObjectReference) + + dataSourceRef 指定一个对象，当需要非空卷时，可以使用它来为卷填充数据。 + 此字段值可以是来自非空 API 组（非核心对象）的一个本地对象，或一个 PersistentVolumeClaim 对象。 + 如果设置了此字段，则仅当所指定对象的类型与所安装的某些卷填充器或动态制备器匹配时，卷绑定才会成功。 + 此字段将替换 dataSource 字段的功能，因此如果两个字段非空，其取值必须相同。 + 为了向后兼容，如果其中一个字段为空且另一个字段非空， + 则两个字段（dataSource 和 dataSourceRef）将被自动设为相同的值。 + dataSource 和 dataSourceRef 之间有两个重要的区别： + + * dataSource 仅允许两个特定类型的对象，而 dataSourceRef 允许设置任何非核心对象以及 PersistentVolumeClaim 对象。 + + * dataSource 忽略不允许的值（这类值会被丢弃），dataSourceRef 保留所有值并在指定不允许的值时产生错误。 + + （Beta）使用此字段需要启用 AnyVolumeDataSource 特性门控。 + +## PersistentVolumeClaimStatus {#PersistentVolumeClaimStatus} + +PersistentVolumeClaimStatus 是持久卷申领的当前状态。 + +
+ +- **accessModes** ([]string) + + accessModes 包含支持 PVC 的卷所具有的实际访问模式。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes#access-modes-1 + + +- **allocatedResources** (map[string]}}">Quantity) + + allocatedResources 跟踪分配给 PVC 的容量。 + 当出现卷扩充操作请求时，此字段可能大于实际的容量。 + 就存储配额而言，将使用 allocatedResources 和 PVC.spec.resources 二者中的更大值。 + 如果未设置 allocatedResources，则 PVC.spec.resources 单独用于配额计算。 + 如果减小一个卷扩充容量请求，则仅当没有正在进行的扩充操作且实际卷容量等于或小于请求的容量时， + 才会减小 allocatedResources。 + 这是一个 Alpha 字段，需要启用 RecoverVolumeExpansionFailure 功能特性。 + + +- **capacity** (map[string]}}">Quantity) + + capacity 表示底层卷的实际资源。 + + +- **conditions** ([]PersistentVolumeClaimCondition) + + **补丁策略：按照键 `type` 合并** + + conditions 是持久卷声明的当前的状况。 + 如果正在调整底层持久卷的大小，则状况将被设为 “ResizeStarted”。 + + + **PersistentVolumeClaimCondition 包含有关 PVC 状态的详细信息。** + + + - **conditions.status** (string)，必需 + + - **conditions.type** (string)，必需 + + - **conditions.lastProbeTime** (Time) + + lastProbeTime 是我们探测 PVC 状况的时间。 + + + **Time 是 time.Time 的包装类，支持正确地序列化为 YAML 和 JSON。 + 为 time 包提供的许多工厂方法提供了包装类。** + + + - **conditions.lastTransitionTime** (Time) + + lastTransitionTime 是状况从一个状态转换为另一个状态的时间。 + + + **Time 是 time.Time 的包装类，支持正确地序列化为 YAML 和 JSON。 + 为 time 包提供的许多工厂方法提供了包装类。** + + - **conditions.message** (string) + + message 是人类可读的消息，指示有关上一次转换的详细信息。 + + - **conditions.reason** (string) + + reason 是唯一的，它应该是一个机器可理解的简短字符串，指明上次状况转换的原因。 + 如果它报告 “ResizeStarted”，则意味着正在调整底层持久卷的大小。 + + +- **phase** (string) + + phase 表示 PersistentVolumeClaim 的当前阶段。 + +- **resizeStatus** (string) + + resizeStatus 存储大小调整操作的状态。默认不设置 resizeStatus，但在扩充完成时， + resizeStatus 将由大小调整控制器或 kubelet 设为空。 + 这是一个 Alpha 字段，需要启用 RecoverVolumeExpansionFailure 功能特性。 + +## PersistentVolumeClaimList {#PersistentVolumeClaimList} + +PersistentVolumeClaimList 是 PersistentVolumeClaim 各项的列表。 + +
+ +- **apiVersion**: v1 + +- **kind**: PersistentVolumeClaimList + + +- **metadata** (}}">ListMeta) + + 标准的列表元数据。更多信息： + https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds + +- **items** ([]}}">PersistentVolumeClaim)，必需 + + items 是持久卷申领的列表。更多信息： + https://kubernetes.io/zh-cn/docs/concepts/storage/persistent-volumes#persistentvolumeclaims + + +## 操作 {#Operations} +
+ +### `get` 读取指定的 PersistentVolumeClaim +#### HTTP 请求 +GET /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name} + + +#### 参数 +- **name** (**路径参数**): string，必需 + + PersistentVolumeClaim 的名称 + +- **namespace** (**路径参数**): string，必需 + + }}">namespace + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 +200 (}}">PersistentVolumeClaim): OK + +401: Unauthorized + + +### `get` 读取指定的 PersistentVolumeClaim 的状态 +#### HTTP 请求 + +GET /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}/status + + +#### 参数 +- **name** (**路径参数**): string，必需 + + PersistentVolumeClaim 的名称 + +- **namespace** (**路径参数**): string，必需 + + }}">namespace + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 +200 (}}">PersistentVolumeClaim): OK + +401: Unauthorized + + +### `list` 列出或观测类别为 PersistentVolumeClaim 的对象 +#### HTTP 请求 +GET /api/v1/namespaces/{namespace}/persistentvolumeclaims + + +#### 参数 +- **namespace** (**路径参数**): string，必需 + + }}">namespace + +- **allowWatchBookmarks** (**查询参数**): boolean + + }}">allowWatchBookmarks + +- **continue** (**查询参数**): string + + }}">continue + +- **fieldSelector** (**查询参数**): string + + }}">fieldSelector + +- **labelSelector** (**查询参数**): string + + }}">labelSelector + +- **limit** (**查询参数**): integer + + }}">limit + +- **pretty** (**查询参数**): string + + }}">pretty + +- **resourceVersion** (**查询参数**): string + + }}">resourceVersion + +- **resourceVersionMatch** (**查询参数**): string + + }}">resourceVersionMatch + +- **timeoutSeconds** (**查询参数**): integer + + }}">timeoutSeconds + +- **watch** (**查询参数**): boolean + + }}">watch + + +#### 响应 +200 (}}">PersistentVolumeClaimList): OK + +401: Unauthorized + + +### `list` 列出或观测类别为 PersistentVolumeClaim 的对象 +#### HTTP 请求 +GET /api/v1/persistentvolumeclaims + + +#### 参数 +- **allowWatchBookmarks** (**查询参数**): boolean + + }}">allowWatchBookmarks + +- **continue** (**查询参数**): string + + }}">continue + +- **fieldSelector** (**查询参数**): string + + }}">fieldSelector + +- **labelSelector** (**查询参数**): string + + }}">labelSelector + +- **limit** (**查询参数**): integer + + }}">limit + +- **pretty** (**查询参数**): string + + }}">pretty + +- **resourceVersion** (**查询参数**): string + + }}">resourceVersion + +- **resourceVersionMatch** (**查询参数**): string + + }}">resourceVersionMatch + +- **timeoutSeconds** (**查询参数**): integer + + }}">timeoutSeconds + +- **watch** (**查询参数**): boolean + + }}">watch + + +#### 响应 +200 (}}">PersistentVolumeClaimList): OK + +401: Unauthorized + + +### `create` 创建 PersistentVolumeClaim +#### HTTP 请求 +POST /api/v1/namespaces/{namespace}/persistentvolumeclaims + + +#### 参数 +- **namespace** (**路径参数**): string，必需 + + }}">namespace + +- **body**: }}">PersistentVolumeClaim，必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 +200 (}}">PersistentVolumeClaim): OK + +201 (}}">PersistentVolumeClaim): Created + +202 (}}">PersistentVolumeClaim): Accepted + +401: Unauthorized + + +### `update` 替换指定的 PersistentVolumeClaim +#### HTTP 请求 +PUT /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name} + + +#### 参数 +- **name** (**路径参数**): string，必需 + + PersistentVolumeClaim 的名称 + +- **namespace** (**路径参数**): string，必需 + + }}">namespace + +- **body**: }}">PersistentVolumeClaim，必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 +200 (}}">PersistentVolumeClaim): OK + +201 (}}">PersistentVolumeClaim): Created + +401: Unauthorized + + +### `update` 替换指定的 PersistentVolumeClaim 的状态 +#### HTTP 请求 +PUT /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}/status + + +#### 参数 +- **name** (**路径参数**): string，必需 + + PersistentVolumeClaim 的名称 + +- **namespace** (**路径参数**): string，必需 + + }}">namespace + +- **body**: }}">PersistentVolumeClaim，必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 +200 (}}">PersistentVolumeClaim): OK + +201 (}}">PersistentVolumeClaim): Created + +401: Unauthorized + + +### `patch` 部分更新指定的 PersistentVolumeClaim +#### HTTP 请求 +PATCH /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name} + + +#### 参数 +- **name** (**路径参数**): string，必需 + + PersistentVolumeClaim 的名称 + +- **namespace** (**路径参数**): string，必需 + + }}">namespace + +- **body**: }}">Patch，必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **force** (**查询参数**): boolean + + }}">force + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 +200 (}}">PersistentVolumeClaim): OK + +201 (}}">PersistentVolumeClaim): Created + +401: Unauthorized + + +### `patch` 部分更新指定的 PersistentVolumeClaim 的状态 +#### HTTP 请求 +PATCH /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}/status + + +#### 参数 +- **name** (**路径参数**): string，必需 + + PersistentVolumeClaim 的名称 + +- **namespace** (**路径参数**): string，必需 + + }}">namespace + +- **body**: }}">Patch，必需 + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldManager** (**查询参数**): string + + }}">fieldManager + +- **fieldValidation** (**查询参数**): string + + }}">fieldValidation + +- **force** (**查询参数**): boolean + + }}">force + +- **pretty** (**查询参数**): string + + }}">pretty + + +#### 响应 +200 (}}">PersistentVolumeClaim): OK + +201 (}}">PersistentVolumeClaim): Created + +401: Unauthorized + + +### `delete` 删除 PersistentVolumeClaim +#### HTTP 请求 +DELETE /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name} + + +#### 参数 +- **name** (**路径参数**): string，必需 + + PersistentVolumeClaim 的名称 + +- **namespace** (**路径参数**): string，必需 + + }}">namespace + +- **body**: }}">DeleteOptions + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **gracePeriodSeconds** (**查询参数**): integer + + }}">gracePeriodSeconds + +- **pretty** (**查询参数**): string + + }}">pretty + +- **propagationPolicy** (**查询参数**): string + + }}">propagationPolicy + + +#### 响应 +200 (}}">PersistentVolumeClaim): OK + +202 (}}">PersistentVolumeClaim): Accepted + +401: Unauthorized + + +### `deletecollection` 删除 PersistentVolumeClaim 的集合 +#### HTTP 请求 +DELETE /api/v1/namespaces/{namespace}/persistentvolumeclaims + + +#### 参数 +- **namespace** (**路径参数**): string，必需 + + }}">namespace + +- **body**: }}">DeleteOptions + +- **continue** (**查询参数**): string + + }}">continue + +- **dryRun** (**查询参数**): string + + }}">dryRun + +- **fieldSelector** (**查询参数**): string + + }}">fieldSelector + +- **gracePeriodSeconds** (**查询参数**): integer + + }}">gracePeriodSeconds + +- **labelSelector** (**查询参数**): string + + }}">labelSelector + +- **limit** (**查询参数**): integer + + }}">limit + +- **pretty** (**查询参数**): string + + }}">pretty + +- **propagationPolicy** (**查询参数**): string + + }}">propagationPolicy + +- **resourceVersion** (**查询参数**): string + + }}">resourceVersion + +- **resourceVersionMatch** (**查询参数**): string + + }}">resourceVersionMatch + +- **timeoutSeconds** (**查询参数**): integer + + }}">timeoutSeconds + + +#### 响应 +200 (}}">Status): OK + +401: Unauthorized From d3b257837f1f5145467d7877f86019c794f0e8ee Mon Sep 17 00:00:00 2001 From: Stefanousd <48087217+Stefanousd@users.noreply.github.com> Date: Sat, 18 Jun 2022 18:24:29 +0200 Subject: [PATCH 16/25] [IT] Added overview descriptions [IT] Added description overview [IT] Added description overview Fixed naming convention --- content/it/docs/concepts/overview/components.md | 2 ++ content/it/docs/concepts/overview/kubernetes-api.md | 4 +++- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/content/it/docs/concepts/overview/components.md b/content/it/docs/concepts/overview/components.md index 906d1f7013..2734b38674 100644 --- a/content/it/docs/concepts/overview/components.md +++ b/content/it/docs/concepts/overview/components.md @@ -1,5 +1,7 @@ --- title: I componenti di Kubernetes +description: > + Un cluster di Kubernetes è costituito da un insieme di componenti che sono, come minimo, un Control Plane e uno o più sistemi di elaborazione, detti nodi. content_type: concept weight: 20 card: diff --git a/content/it/docs/concepts/overview/kubernetes-api.md b/content/it/docs/concepts/overview/kubernetes-api.md index 5214bea53a..78022336e8 100644 --- a/content/it/docs/concepts/overview/kubernetes-api.md +++ b/content/it/docs/concepts/overview/kubernetes-api.md @@ -1,5 +1,7 @@ --- -title: Le API di Kubernetes +title: Le API di Kubernetes +description: > + Le API di Kubernetes ti permettono di interrogare e manipolare lo stato degli oggetti in Kubernetes. Il cuore del Control Plane di Kubernetes è l'API server e le API HTTP che esso espone. Ogni entità o componente che si interfaccia con il cluster (gli utenti, le singole parti del tuo cluster, i componenti esterni), comunica attraverso l'API server. content_type: concept weight: 30 card: From 113bd960aa228c1c01a72764e00e92ec88e77fe7 Mon Sep 17 00:00:00 2001 From: "yanrong.shi" Date: Mon, 20 Jun 2022 02:54:06 +0800 Subject: [PATCH 17/25] Update enforce-standards-admission-controller.md --- .../enforce-standards-admission-controller.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/zh-cn/docs/tasks/configure-pod-container/enforce-standards-admission-controller.md b/content/zh-cn/docs/tasks/configure-pod-container/enforce-standards-admission-controller.md index 854205cbd8..fe0183514e 100644 --- a/content/zh-cn/docs/tasks/configure-pod-container/enforce-standards-admission-controller.md +++ b/content/zh-cn/docs/tasks/configure-pod-container/enforce-standards-admission-controller.md @@ -56,7 +56,7 @@ plugins: # # version 标签必须是如下取值之一： # - "latest" (默认) - # - 诸如 "v{{< skew latestVersion >}}" 这类版本号 + # - 诸如 "v{{< skew currentVersion>}}" 这类版本号 defaults: enforce: "privileged" enforce-version: "latest" @@ -99,7 +99,7 @@ plugins: # # version 标签必须是如下取值之一： # - "latest" (默认) - # - 诸如 "v{{< skew latestVersion >}}" 这类版本号 + # - 诸如 "v{{< skew currentVersion>}}" 这类版本号 defaults: enforce: "privileged" enforce-version: "latest" From b07a0b5e4db6fb3d2927f83b5f2ac508b59b6cda Mon Sep 17 00:00:00 2001 From: "paul.zhang" Date: Mon, 20 Jun 2022 10:56:36 +0800 Subject: [PATCH 18/25] Modify the wrong link Modify the wrong link:from https://git.k8s.io/community/contributors/design-proposals to https://github.com/kubernetes/design-proposals-archive/blob/main --- .../docs/tasks/configure-pod-container/security-context.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/zh-cn/docs/tasks/configure-pod-container/security-context.md b/content/zh-cn/docs/tasks/configure-pod-container/security-context.md index 29e5a3afb3..a97e5528f7 100644 --- a/content/zh-cn/docs/tasks/configure-pod-container/security-context.md +++ b/content/zh-cn/docs/tasks/configure-pod-container/security-context.md @@ -782,10 +782,10 @@ kubectl delete pod security-context-demo-4 * [PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core) API 定义 * [SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core) API 定义 * [使用最新的安全性增强来调优 Docker（英文）](https://github.com/containerd/containerd/blob/main/docs/cri/config.md) -* [安全上下文的设计文档（英文）](https://git.k8s.io/community/contributors/design-proposals/auth/security_context.md) -* [属主管理的设计文档（英文）](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md) +* [安全上下文的设计文档（英文）](https://github.com/kubernetes/design-proposals-archive/blob/main/auth/security_context.md) +* [属主管理的设计文档（英文）](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/volume-ownership-management.md) * [Pod 安全策略](/zh/docs/concepts/security/pod-security-policy/) -* [AllowPrivilegeEscalation 的设计文档（英文）](https://git.k8s.io/community/contributors/design-proposals/auth/no-new-privs.md) +* [AllowPrivilegeEscalation 的设计文档（英文）](https://github.com/kubernetes/design-proposals-archive/blob/main/auth/no-new-privs.md) * 关于在 Linux 系统中的安全机制的更多信息，可参阅 [Linux 内核安全性能力概述](https://www.linux.com/learn/overview-linux-kernel-security-features)。 From 664de5d7a89087b5b6e22edbc189f76b9baa7644 Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Thu, 9 Jan 2020 01:12:18 +0000 Subject: [PATCH 19/25] Use note and caution shortcode blocks --- .../run-replicated-stateful-application.md | 20 +++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/content/en/docs/tasks/run-application/run-replicated-stateful-application.md b/content/en/docs/tasks/run-application/run-replicated-stateful-application.md index 03da601a48..e31ad7d937 100644 --- a/content/en/docs/tasks/run-application/run-replicated-stateful-application.md +++ b/content/en/docs/tasks/run-application/run-replicated-stateful-application.md @@ -24,8 +24,6 @@ replication. on general patterns for running stateful applications in Kubernetes. {{< /note >}} - - ## {{% heading "prerequisites" %}} @@ -132,8 +130,11 @@ mysql-2 2/2 Running 0 1m ``` Press **Ctrl+C** to cancel the watch. + +{{< note >}} If you don't see any progress, make sure you have a dynamic PersistentVolume -provisioner enabled as mentioned in the [prerequisites](#before-you-begin). +provisioner enabled, as mentioned in the [prerequisites](#before-you-begin). +{{< /note >}} This manifest uses a variety of techniques for managing stateful Pods as part of a StatefulSet. The next section highlights some of these techniques to explain @@ -375,10 +376,14 @@ Then drain the Node by running the following command, which cordons it so no new Pods may schedule there, and then evicts any existing Pods. Replace `` with the name of the Node you found in the last step. -This might impact other applications on the Node, so it's best to -**only do this in a test cluster**. +{{< caution >}} +Draining a Node can impact other workloads and applications that are +running on the same node, so only do the following step in a test +cluster. +{{< /caution >}} ```shell +# See above advice about impact on other workloads kubectl drain --force --delete-emptydir-data --ignore-daemonsets ``` @@ -453,10 +458,13 @@ Scaling back down is also seamless: kubectl scale statefulset mysql --replicas=3 ``` -Note, however, that while scaling up creates new PersistentVolumeClaims +{{< note >}} +Although scaling up creates new PersistentVolumeClaims automatically, scaling down does not automatically delete these PVCs. + This gives you the choice to keep those initialized PVCs around to make scaling back up quicker, or to extract data before deleting them. +{{< /note >}} You can see this by running: From f3e3d2ca467ea9422a3a10a0a0d483f02aaa2b37 Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Thu, 9 Jan 2020 01:12:43 +0000 Subject: [PATCH 20/25] Reword in line with style guide Co-authored-by: ZSC --- .../run-replicated-stateful-application.md | 48 +++++++++---------- 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/content/en/docs/tasks/run-application/run-replicated-stateful-application.md b/content/en/docs/tasks/run-application/run-replicated-stateful-application.md index e31ad7d937..593dc6b212 100644 --- a/content/en/docs/tasks/run-application/run-replicated-stateful-application.md +++ b/content/en/docs/tasks/run-application/run-replicated-stateful-application.md @@ -14,7 +14,7 @@ weight: 30 This page shows how to run a replicated stateful application using a -[StatefulSet](/docs/concepts/workloads/controllers/statefulset/) controller. +{{< glossary_tooltip term_id="statefulset" >}}. This application is a replicated MySQL database. The example topology has a single primary server and multiple replicas, using asynchronous row-based replication. @@ -27,7 +27,7 @@ on general patterns for running stateful applications in Kubernetes. ## {{% heading "prerequisites" %}} -* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +* {{< include "task-tutorial-prereqs.md" >}} * {{< include "default-storage-class-prereqs.md" >}} * This tutorial assumes you are familiar with [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) @@ -44,7 +44,7 @@ on general patterns for running stateful applications in Kubernetes. ## {{% heading "objectives" %}} -* Deploy a replicated MySQL topology with a StatefulSet controller. +* Deploy a replicated MySQL topology with a StatefulSet. * Send MySQL client traffic. * Observe resistance to downtime. * Scale the StatefulSet up and down. @@ -58,7 +58,7 @@ on general patterns for running stateful applications in Kubernetes. The example MySQL deployment consists of a ConfigMap, two Services, and a StatefulSet. -### ConfigMap +### Create a ConfigMap {#configmap} Create the ConfigMap from the following YAML configuration file: @@ -78,7 +78,7 @@ portions to apply to different Pods. Each Pod decides which portion to look at as it's initializing, based on information provided by the StatefulSet controller. -### Services +### Create Services {#services} Create the Services from the following YAML configuration file: @@ -88,23 +88,24 @@ Create the Services from the following YAML configuration file: kubectl apply -f https://k8s.io/examples/application/mysql/mysql-services.yaml ``` -The Headless Service provides a home for the DNS entries that the StatefulSet -controller creates for each Pod that's part of the set. -Because the Headless Service is named `mysql`, the Pods are accessible by +The headless Service provides a home for the DNS entries that the StatefulSet +{{< glossary_tooltip text="controllers" term_id="controller" >}} creates for each +Pod that's part of the set. +Because the headless Service is named `mysql`, the Pods are accessible by resolving `.mysql` from within any other Pod in the same Kubernetes cluster and namespace. -The Client Service, called `mysql-read`, is a normal Service with its own +The client Service, called `mysql-read`, is a normal Service with its own cluster IP that distributes connections across all MySQL Pods that report being Ready. The set of potential endpoints includes the primary MySQL server and all replicas. -Note that only read queries can use the load-balanced Client Service. +Note that only read queries can use the load-balanced client Service. Because there is only one primary MySQL server, clients should connect directly to the -primary MySQL Pod (through its DNS entry within the Headless Service) to execute +primary MySQL Pod (through its DNS entry within the headless Service) to execute writes. -### StatefulSet +### Create the StatefulSet {#statefulset} Finally, create the StatefulSet from the following YAML configuration file: @@ -120,7 +121,7 @@ You can watch the startup progress by running: kubectl get pods -l app=mysql --watch ``` -After a while, you should see all 3 Pods become Running: +After a while, you should see all 3 Pods become `Running`: ``` NAME READY STATUS RESTARTS AGE @@ -156,10 +157,10 @@ properties to perform orderly startup of MySQL replication. ### Generating configuration Before starting any of the containers in the Pod spec, the Pod first runs any -[Init Containers](/docs/concepts/workloads/pods/init-containers/) +[init containers](/docs/concepts/workloads/pods/init-containers/) in the order defined. -The first Init Container, named `init-mysql`, generates special MySQL config +The first init container, named `init-mysql`, generates special MySQL config files based on the ordinal index. The script determines its own ordinal index by extracting it from the end of @@ -167,8 +168,7 @@ the Pod name, which is returned by the `hostname` command. Then it saves the ordinal (with a numeric offset to avoid reserved values) into a file called `server-id.cnf` in the MySQL `conf.d` directory. This translates the unique, stable identity provided by the StatefulSet -controller into the domain of MySQL server IDs, which require the same -properties. +into the domain of MySQL server IDs, which require the same properties. The script in the `init-mysql` container also applies either `primary.cnf` or `replica.cnf` from the ConfigMap by copying the contents into `conf.d`. @@ -188,7 +188,7 @@ logs might not go all the way back to the beginning of time. These conservative assumptions are the key to allow a running StatefulSet to scale up and down over time, rather than being fixed at its initial size. -The second Init Container, named `clone-mysql`, performs a clone operation on +The second init container, named `clone-mysql`, performs a clone operation on a replica Pod the first time it starts up on an empty PersistentVolume. That means it copies all existing data from another running Pod, so its local state is consistent enough to begin replicating from the primary server. @@ -203,7 +203,7 @@ Ready before starting Pod `N+1`. ### Starting replication -After the Init Containers complete successfully, the regular containers run. +After the init containers complete successfully, the regular containers run. The MySQL Pods consist of a `mysql` container that runs the actual `mysqld` server, and an `xtrabackup` container that acts as a [sidecar](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns). @@ -292,13 +292,13 @@ endpoint might be selected upon each connection attempt: You can press **Ctrl+C** when you want to stop the loop, but it's useful to keep it running in another window so you can see the effects of the following steps. -## Simulating Pod and Node downtime +## Simulate Pod and Node failure {#simulate-pod-and-node-downtime} To demonstrate the increased availability of reading from the pool of replicas instead of a single server, keep the `SELECT @@server_id` loop from above running while you force a Pod out of the Ready state. -### Break the Readiness Probe +### Break the Readiness probe The [readiness probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes) for the `mysql` container runs the command `mysql -h 127.0.0.1 -e 'SELECT 1'` @@ -372,13 +372,13 @@ NAME READY STATUS RESTARTS AGE IP NODE mysql-2 2/2 Running 0 15m 10.244.5.27 kubernetes-node-9l2t ``` -Then drain the Node by running the following command, which cordons it so +Then, drain the Node by running the following command, which cordons it so no new Pods may schedule there, and then evicts any existing Pods. Replace `` with the name of the Node you found in the last step. {{< caution >}} -Draining a Node can impact other workloads and applications that are -running on the same node, so only do the following step in a test +Draining a Node can impact other workloads and applications +running on the same node. Only perform the following step in a test cluster. {{< /caution >}} From 37400750f60636a25bc74bf0e71f5db3e23173a9 Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Thu, 9 Jan 2020 01:28:39 +0000 Subject: [PATCH 21/25] Add recommended labels --- content/en/examples/application/mysql/mysql-configmap.yaml | 1 + content/en/examples/application/mysql/mysql-services.yaml | 3 +++ content/en/examples/application/mysql/mysql-statefulset.yaml | 4 +++- 3 files changed, 7 insertions(+), 1 deletion(-) diff --git a/content/en/examples/application/mysql/mysql-configmap.yaml b/content/en/examples/application/mysql/mysql-configmap.yaml index 519334bc82..9adb0344a3 100644 --- a/content/en/examples/application/mysql/mysql-configmap.yaml +++ b/content/en/examples/application/mysql/mysql-configmap.yaml @@ -4,6 +4,7 @@ metadata: name: mysql labels: app: mysql + app.kubernetes.io/name: mysql data: primary.cnf: | # Apply this config only on the primary. diff --git a/content/en/examples/application/mysql/mysql-services.yaml b/content/en/examples/application/mysql/mysql-services.yaml index 6743cf707a..bc01506678 100644 --- a/content/en/examples/application/mysql/mysql-services.yaml +++ b/content/en/examples/application/mysql/mysql-services.yaml @@ -5,6 +5,7 @@ metadata: name: mysql labels: app: mysql + app.kubernetes.io/name: mysql spec: ports: - name: mysql @@ -21,6 +22,8 @@ metadata: name: mysql-read labels: app: mysql + app.kubernetes.io/name: mysql + readonly: "true" spec: ports: - name: mysql diff --git a/content/en/examples/application/mysql/mysql-statefulset.yaml b/content/en/examples/application/mysql/mysql-statefulset.yaml index bb61537fcf..275e057a1b 100644 --- a/content/en/examples/application/mysql/mysql-statefulset.yaml +++ b/content/en/examples/application/mysql/mysql-statefulset.yaml @@ -5,13 +5,15 @@ metadata: spec: selector: matchLabels: - app: mysql + app: mysql-server + app.kubernetes.io/name: mysql serviceName: mysql replicas: 3 template: metadata: labels: app: mysql + app.kubernetes.io/name: mysql spec: initContainers: - name: init-mysql From eca7f75f0ed4bcf8cfadd173344b45efa38592a1 Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Thu, 9 Jan 2020 01:29:02 +0000 Subject: [PATCH 22/25] =?UTF-8?q?Write=20=E2=80=9Creplica=E2=80=9D=20rathe?= =?UTF-8?q?r=20than=20=E2=80=9Cslave=E2=80=9D?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Leave "slave" intact where this is a technical term / meaningful to the code. --- .../run-application/run-replicated-stateful-application.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/content/en/docs/tasks/run-application/run-replicated-stateful-application.md b/content/en/docs/tasks/run-application/run-replicated-stateful-application.md index 593dc6b212..8d9e754c2e 100644 --- a/content/en/docs/tasks/run-application/run-replicated-stateful-application.md +++ b/content/en/docs/tasks/run-application/run-replicated-stateful-application.md @@ -69,7 +69,7 @@ kubectl apply -f https://k8s.io/examples/application/mysql/mysql-configmap.yaml ``` This ConfigMap provides `my.cnf` overrides that let you independently control -configuration on the primary MySQL server and replicas. +configuration on the primary MySQL server and its replicas. In this case, you want the primary server to be able to serve replication logs to replicas and you want replicas to reject any writes that don't come via replication. @@ -418,8 +418,9 @@ kubectl uncordon ## Scaling the number of replicas -With MySQL replication, you can scale your read query capacity by adding replicas. -With StatefulSet, you can do this with a single command: +When you use MySQL replication, you can scale your read query capacity by +adding replicas. +For a StatefulSet, you can achieve this with a single command: ```shell kubectl scale statefulset mysql --replicas=5 From bf59d416b48bbfcd511ed6a6aefc8f8073eff470 Mon Sep 17 00:00:00 2001 From: Nitish Kumar Date: Mon, 20 Jun 2022 17:58:50 +0530 Subject: [PATCH 23/25] Downward API concept made Correct --- content/en/docs/concepts/workloads/pods/downward-api.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/docs/concepts/workloads/pods/downward-api.md b/content/en/docs/concepts/workloads/pods/downward-api.md index 40b2362959..fcee383c45 100644 --- a/content/en/docs/concepts/workloads/pods/downward-api.md +++ b/content/en/docs/concepts/workloads/pods/downward-api.md @@ -16,7 +16,7 @@ or API server. An example is an existing application that assumes a particular well-known environment variable holds a unique identifier. One possibility is to wrap the -application, but that is tedious and error prone, and it violates the goal of low +application, but that is tedious and error-prone, and it violates the goal of low coupling. A better option would be to use the Pod's name as an identifier, and inject the Pod's name into the well-known environment variable. @@ -119,8 +119,8 @@ for resources such as CPU and memory. If CPU and memory limits are not specified for a container, and you use the downward API to try to expose that information, then the kubelet defaults to exposing the maximum allocatable value for CPU and memory -(based on the [node allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) -calculation). +based on the [node allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) +calculation. ## {{% heading "whatsnext" %}} From 6748cbe6ed69e14076a49af82da9fe6892040691 Mon Sep 17 00:00:00 2001 From: yanrongshi Date: Mon, 20 Jun 2022 21:50:05 +0800 Subject: [PATCH 24/25] [zh] Update /releases/_index.md (#34406) * Update _index.md * Update _index.md * Update content/zh-cn/releases/_index.md Co-authored-by: howieyuen Co-authored-by: howieyuen --- content/zh-cn/releases/_index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/zh-cn/releases/_index.md b/content/zh-cn/releases/_index.md index 1ecb83e127..721366fde3 100644 --- a/content/zh-cn/releases/_index.md +++ b/content/zh-cn/releases/_index.md @@ -13,9 +13,9 @@ type: docs -Kubernetes 项目维护最近三个次要版本（{{< skew latestVersion >}}、{{< skew prevMinorVersion >}}、{{< skew oldMinorVersion >}}）的发布分支。 +Kubernetes 项目维护最近三个次要版本（{{< skew currentVersion >}}、{{< skew currentVersionAddMinor -1 >}}、{{< skew currentVersionAddMinor -2 >}}）的发布分支。 Kubernetes 1.19 和更新版本获得[大约 1 年的补丁支持](/zh/releases/patch-releases/#support-period)。 Kubernetes 1.18 及更早版本获得了大约 9 个月的补丁支持周期。 @@ -41,9 +41,9 @@ Kubernetes 版本表示为 **x.y.z**， ## 未来的发行版本 -查看[时间表](https://github.com/kubernetes/sig-release/tree/master/releases/release-{{< skew nextMinorVersion >}})， +查看[时间表](https://github.com/kubernetes/sig-release/tree/master/releases/release-{{< skew currentVersionAddMinor 1 >}})， Kubernetes **{{< skew nextMinorVersion >}}** 版本即将发行！ From d9e5b56eab6e622670def1bf8700849c11e64ee3 Mon Sep 17 00:00:00 2001 From: ihuibin Date: Tue, 14 Jun 2022 18:45:40 +0800 Subject: [PATCH 25/25] [zh]update verify-signed-images.md Signed-off-by: bin.hui Co-authored-by: Qiming Teng --- .../verify-signed-images.md | 120 ++++++++++++++++++ 1 file changed, 120 insertions(+) create mode 100644 content/zh-cn/docs/tasks/administer-cluster/verify-signed-images.md diff --git a/content/zh-cn/docs/tasks/administer-cluster/verify-signed-images.md b/content/zh-cn/docs/tasks/administer-cluster/verify-signed-images.md new file mode 100644 index 0000000000..4fd9736b55 --- /dev/null +++ b/content/zh-cn/docs/tasks/administer-cluster/verify-signed-images.md @@ -0,0 +1,120 @@ +--- +title: 验证已签名容器镜像 +content_type: task +min-kubernetes-server-version: v1.24 +--- + + + + +{{< feature-state state="alpha" for_k8s_version="v1.24" >}} + +## {{% heading "prerequisites" %}} + + +这些说明适用于 Kubernetes {{< skew currentVersion >}}。如果你想要检查其他版本的 Kubernetes 组件的完整性， +请查看对应 Kubernetes 版本的文档。 + +你需要安装以下工具: + +- `cosign` ([安装指南](https://docs.sigstore.dev/cosign/installation/)) +- `curl` (通常由你的操作系统提供) + + +## 验证镜像签名 {#verifying-image-signatures} + +完整的镜像签名列表请参见[发行版本](/releases/download/)。 + +我们从这个列表中选择一个镜像，并使用 `cosign verify` 命令来验证它的签名： + +```shell +COSIGN_EXPERIMENTAL=1 cosign verify k8s.gcr.io/kube-apiserver-amd64:v1.24.0 +``` + +{{< note >}} + +`COSIGN_EXPERIMENTAL=1` 用于对以 `KEYLESS` 模式签名的镜像进行验证。想要进一步了解 `KEYLESS`，请参考 +[Keyless Signatures](https://github.com/sigstore/cosign/blob/main/KEYLESS.md#keyless-signatures)。 +{{< /note >}} + + +### 验证所有控制平面组件镜像 {#verifying-images-for-all-control-plane-components} + +验证所有已签名的控制平面组件镜像，请运行以下命令： + +```shell +curl -Ls https://sbom.k8s.io/$(curl -Ls https://dl.k8s.io/release/latest.txt)/release | grep 'PackageName: k8s.gcr.io/' | awk '{print $2}' > images.txt +input=images.txt +while IFS= read -r image +do + COSIGN_EXPERIMENTAL=1 cosign verify "$image" +done < "$input" +``` + + +当你完成某个镜像的验证时，可以在你的 Pod 清单通过摘要值来指定该镜像，例如： +`registry-url/image-name@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`。 + +要了解更多信息，请参考[镜像拉取策略](/zh-cn/docs/concepts/containers/images/#image-pull-policy)章节。 + + +## 使用准入控制器验证镜像签名 {#verifying-image-signatures-with-admission-controller} + +有一些非控制平面镜像 +（例如 [conformance 镜像](https://github.com/kubernetes/kubernetes/blob/master/test/conformance/image/README.md)）， +也可以在部署时使用 +[cosigned](https://docs.sigstore.dev/cosign/kubernetes/#cosigned-admission-controller) +控制器验证其签名。如要使用 `cosigned`，下面是一些有帮助的资源： + +* [安装](https://github.com/sigstore/helm-charts/tree/main/charts/cosigned) +* [配置选项](https://github.com/sigstore/cosign/tree/main/config) +