<ins> --- title: 升级 Windows 节点 min-kubernetes-server-version: 1.17 content_type: task weight: 40 --- <!-- title: Upgrading Windows nodes min-kubernetes-server-version: 1.17 content_type: task weight: 40 --> <!-- overview --> {{< feature-state for_k8s_version="v1.18" state="beta" >}} <!-- This page explains how to upgrade a Windows node [created with kubeadm](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes). --> 本页解释如何升级[用 kubeadm 创建的](/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes) Windows 节点。 ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} <!-- * Familiarize yourself with [the process for upgrading the rest of your kubeadm cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade). You will want to upgrade the control plane nodes before upgrading your Windows nodes. --> * 熟悉[更新 kubeadm 集群中的其余组件](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade)。 在升级你的 Windows 节点之前你会想要升级控制面节点。 <!-- steps --> <!-- ## Upgrading worker nodes ### Upgrade kubeadm --> ## 升级工作节点   {#upgrading-worker-nodes} ### 升级 kubeadm    {#upgrade-kubeadm} <!-- 1.  From the Windows node, upgrade kubeadm: ```powershell # replace {{< param "fullversion" >}} with your desired version curl.exe -Lo C:kkubeadm.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubeadm.exe ``` --> 1. 在 Windows 节点上升级 kubeadm： ```powershell # 将 {{< param "fullversion" >}} 替换为你希望的版本 curl.exe -Lo C:kkubeadm.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubeadm.exe ``` <!-- ### Drain the node 1.  From a machine with access to the Kubernetes API, prepare the node for maintenance by marking it unschedulable and evicting the workloads: ```shell # replace <node-to-drain> with the name of your node you are draining kubectl drain <node-to-drain> -ignore-daemonsets ``` You should see output similar to this: ``` node/ip-172-31-85-18 cordoned node/ip-172-31-85-18 drained ``` --> ### 腾空节点   {#drain-the-node} 1. 在一个能访问到 Kubernetes API 的机器上，将 Windows 节点标记为不可调度并 驱逐其上的所有负载，以便准备节点维护操作： ```shell # 将 <要腾空的节点> 替换为你要腾空的节点的名称 kubectl drain <要腾空的节点> -ignore-daemonsets ``` 你应该会看到类似下面的输出： ``` node/ip-172-31-85-18 cordoned node/ip-172-31-85-18 drained ``` <!-- ### Upgrade the kubelet configuration 1.  From the Windows node, call the following command to sync new kubelet configuration: ```powershell kubeadm upgrade node ``` --> ### 升级 kubelet 配置   {#upgrade-the-kubelet-configuration} 1. 在 Windows 节点上，执行下面的命令来同步新的 kubelet 配置： ```powershell kubeadm upgrade node ``` <!-- ### Upgrade kubelet 1.  From the Windows node, upgrade and restart the kubelet: ```powershell stop-service kubelet curl.exe -Lo C:kkubelet.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubelet.exe restart-service kubelet ``` --> ### 升级 kubelet   {#upgrade-kubelet} 1. 在 Windows 节点上升级并重启 kubelet： ```powershell stop-service kubelet curl.exe -Lo C:kkubelet.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubelet.exe restart-service kubelet ``` <!-- ### Uncordon the node 1.  From a machine with access to the Kubernetes API, bring the node back online by marking it schedulable: ```shell # replace <node-to-drain> with the name of your node kubectl uncordon <node-to-drain> ``` --> ### 对节点执行 uncordon 操作   {#uncordon-the-node} 1. 从一台能够访问到 Kubernetes API 的机器上，通过将节点标记为可调度，使之 重新上线： ```shell # 将 <要腾空的节点> 替换为你的节点名称 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 - ``` --> ### 升级 kube-proxy   {#upgrade-kube-proxy} 1. 在一台可访问 Kubernetes API 的机器上和，将 {{< param "fullversion" >}} 替换成你 期望的版本后再次执行下面的命令： ```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 - ``` </ins>


<ins> --- title: 为 Windows Pod 和容器配置 GMSA content_type: task weight: 20 --- <!-- title: Configure GMSA for Windows Pods and containers content_type: task weight: 20 --> <!-- overview --> {{< feature-state for_k8s_version="v1.18" state="stable" >}} <!-- This page shows how to configure [Group Managed Service Accounts](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) (GMSA) for Pods and containers that will run on Windows nodes. Group Managed Service Accounts are a specific type of Active Directory account that provides automatic password management, simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers. --> 本页展示如何为将运行在 Windows 节点上的 Pod 和容器配置 [组管理的服务账号（Group Managed Service Accounts，GMSA）](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview)。 组管理的服务账号是活动目录（Active Directory）的一种特殊类型，提供自动化的 密码管理、简化的服务主体名称（Service Principal Name，SPN）管理以及跨多个 服务器将管理操作委派给其他管理员等能力。 <!-- In Kubernetes, GMSA credential specs are configured at a Kubernetes cluster-wide scope as Custom Resources. Windows Pods, as well as individual containers within a Pod, can be configured to use a GMSA for domain based functions (e.g. Kerberos authentication) when interacting with other Windows services. As of v1.16, the Docker runtime supports GMSA for Windows workloads. --> 在 Kubernetes 环境中，GMSA 凭据规约配置为 Kubernetes 集群范围的自定义资源 （Custom Resources）形式。Windows Pod 以及各 Pod 中的每个容器可以配置为 使用 GMSA 来完成基于域（Domain）的操作（例如，Kerberos 身份认证），以便 与其他 Windows 服务相交互。自 Kubernetes 1.16 版本起，Docker 运行时为 Windows 负载支持 GMSA。 ## {{% heading "prerequisites" %}} <!-- You need to have a Kubernetes cluster and the `kubectl` command-line tool must be configured to communicate with your cluster. The cluster is expected to have Windows worker nodes. This section covers a set of initial steps required once for each cluster: --> 你需要一个 Kubernetes 集群，以及 `kubectl` 命令行工具，且工具必须已配置 为能够与你的集群通信。集群预期包含 Windows 工作节点。 本节讨论需要为每个集群执行一次的初始操作。 <!-- ### Install the GMSACredentialSpec CRD A [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)(CRD) for GMSA credential spec resources needs to be configured on the cluster to define the custom resource type `GMSACredentialSpec`. Download the GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml) and save it as gmsa-crd.yaml. Next, install the CRD with `kubectl apply -f gmsa-crd.yaml` --> ### 安装 GMSACredentialSpec CRD 你需要在集群上配置一个用于 GMSA 凭据规约资源的 [CustomResourceDefinition](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)(CRD)， 以便定义类型为 `GMSACredentialSpec` 的自定义资源。 首先下载 GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml) 并将其保存为 `gmsa-crd.yaml`。接下来执行 `kubectl apply -f gmsa-crd.yaml` 安装 CRD。 <!-- ### Install webhooks to validate GMSA users Two webhooks need to be configured on the Kubernetes cluster to populate and validate GMSA credential spec references at the Pod or container level: 1. A mutating webhook that expands references to GMSAs (by name from a Pod specification) into the full credential spec in JSON form within the Pod spec. 1. A validating webhook ensures all references to GMSAs are authorized to be used by the Pod service account. --> ### 安装 Webhook 来验证 GMSA 用户 你需要为 Kubernetes 集群配置两个 Webhook，在 Pod 或容器级别填充和检查 GMSA 凭据规约引用。 1. 一个修改模式（Mutating）的 Webhook，将对 GMSA 的引用（在 Pod 规约中体现为名字） 展开为完整凭据规约的 JSON 形式，并保存回 Pod 规约中。 1. 一个验证模式（Validating）的 Webhook，确保对 GMSA 的所有引用都是已经授权 给 Pod 的服务账号使用的。 <!-- Installing the above webhooks and associated objects require the steps below: 1. Create a certificate key pair (that will be used to allow the webhook container to communicate to the cluster) 1. Install a secret with the certificate from above. 1. Create a deployment for the core webhook logic. 1. Create the validating and mutating webhook configurations referring to the deployment. --> 安装以上 Webhook 及其相关联的对象需要执行以下步骤： 1. 创建一个证书密钥对（用于允许 Webhook 容器与集群通信） 1. 安装一个包含如上证书的 Secret 1. 创建一个包含核心 Webhook 逻辑的 Deployment 1. 创建引用该 Deployment 的 Validating Webhook 和 Mutating Webhook 配置 <!-- A [script](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/deploy-gmsa-webhook.sh) can be used to deploy and configure the GMSA webhooks and associated objects mentioned above. The script can be run with a `-dry-run=server` option to allow you to review the changes that would be made to your cluster. The [YAML template](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-webhook.yml.tpl) used by the script may also be used to deploy the webhooks and associated objects manually (with appropriate substitutions for the parameters) --> 你可以使用[这个脚本](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/deploy-gmsa-webhook.sh) 来部署和配置上述 GMSA Webhook 及相关联的对象。你还可以在运行脚本时设置 `--dry-run=server` 选项以便审查脚本将会对集群做出的变更。 脚本所使用的[YAML 模板](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-webhook.yml.tpl) 也可用于手动部署 Webhook 及相关联的对象，不过需要对其中的参数作适当替换。 <!-- steps --> <!-- ## Configure GMSAs and Windows nodes in Active Directory Before Pods in Kubernetes can be configured to use GMSAs, the desired GMSAs need to be provisioned in Active Directory as described in the [Windows GMSA documentation](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1). Windows worker nodes (that are part of the Kubernetes cluster) need to be configured in Active Directory to access the secret credentials associated with the desired GMSA as described in the [Windows GMSA documentation](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet) --> ## 在活动目录中配置 GMSA 和 Windows 节点 在配置 Kubernetes 中的 Pod 以使用 GMSA 之前，需要按 [Windows GMSA 文档](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1) 中描述的那样先在活动目录中准备好期望的 GMSA。 Windows 工作节点（作为 Kubernetes 集群的一部分）需要被配置到活动目录中，以便 访问与期望的 GSMA 相关联的秘密凭据数据。这一操作的描述位于 [Windows GMSA 文档](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet) 中。 <!-- ## Create GMSA credential spec resources With the GMSACredentialSpec CRD installed (as described earlier), custom resources containing GMSA credential specs can be configured. The GMSA credential spec does not contain secret or sensitive data. It is information that a container runtime can use to describe the desired GMSA of a container to Windows. GMSA credential specs can be generated in YAML format with a utility [PowerShell script](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1). --> ## 创建 GMSA 凭据规约资源 当（如前所述）安装了 GMSACredentialSpec CRD 之后，你就可以配置包含 GMSA 凭据 规约的自定义资源了。GMSA 凭据规约中并不包含秘密或敏感数据。 其中包含的信息主要用于容器运行时，便于后者向 Windows 描述容器所期望的 GMSA。 GMSA 凭据规约可以使用 [PowerShell 脚本](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1) 以 YAML 格式生成。 <!-- Following are the steps for generating a GMSA credential spec YAML manually in JSON format and then converting it: 1. Import the CredentialSpec [module](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/windows-server-container-tools/ServiceAccounts/CredentialSpec.psm1): `ipmo CredentialSpec.psm1` 1. Create a credential spec in JSON format using `New-CredentialSpec`. To create a GMSA credential spec named WebApp1, invoke `New-CredentialSpec -Name WebApp1 -AccountName WebApp1 -Domain $(Get-ADDomain -Current LocalComputer)` 1. Use `Get-CredentialSpec` to show the path of the JSON file. 1. Convert the credspec file from JSON to YAML format and apply the necessary header fields `apiVersion`, `kind`, `metadata` and `credspec` to make it a GMSACredentialSpec custom resource that can be configured in Kubernetes. --> 下面是手动以 JSON 格式生成 GMSA 凭据规约并对其进行 YAML 转换的步骤： 1. 导入 CredentialSpec [模块](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/windows-server-container-tools/ServiceAccounts/CredentialSpec.psm1): `ipmo CredentialSpec.psm1` 1. 使用 `New-CredentialSpec` 来创建一个 JSON 格式的凭据规约。 要创建名为 `WebApp1` 的 GMSA 凭据规约，调用 `New-CredentialSpec -Name WebApp1 -AccountName WebApp1 -Domain $(Get-ADDomain -Current LocalComputer)`。 1. 使用 `Get-CredentialSpec` 来显示 JSON 文件的路径。 1. 将凭据规约从 JSON 格式转换为 YAML 格式，并添加必要的头部字段 `apiVersion`、`kind`、`metadata` 和 `credspec`，使其成为一个可以在 Kubernetes 中配置的 GMSACredentialSpec 自定义资源。 <!-- The following YAML configuration describes a GMSA credential spec named `gmsa-WebApp1`: ```yaml apiVersion: windows.k8s.io/v1alpha1 kind: GMSACredentialSpec metadata: name: gmsa-WebApp1  #This is an arbitrary name but it will be used as a reference credspec: ActiveDirectoryConfig: GroupManagedServiceAccounts: - Name: WebApp1   #Username of the GMSA account Scope: CONTOSO  #NETBIOS Domain Name - Name: WebApp1   #Username of the GMSA account Scope: contoso.com #DNS Domain Name CmsPlugins: - ActiveDirectory DomainJoinConfig: DnsName: contoso.com  #DNS Domain Name DnsTreeName: contoso.com #DNS Domain Name Root Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a  #GUID MachineAccountName: WebApp1 #Username of the GMSA account NetBiosName: CONTOSO  #NETBIOS Domain Name Sid: S-1-5-21-2126449477-2524075714-3094792973 #SID of GMSA ``` --> 下面的 YAML 配置描述的是一个名为 `gmsa-WebApp1` 的 GMSA 凭据规约： ```yaml apiVersion: windows.k8s.io/v1alpha1 kind: GMSACredentialSpec metadata: name: gmsa-WebApp1  # 这是随意起的一个名字，将用作引用 credspec: ActiveDirectoryConfig: GroupManagedServiceAccounts: - Name: WebApp1   # GMSA 账号的用户名 Scope: CONTOSO  # NETBIOS 域名 - Name: WebApp1   # GMSA 账号的用户名 Scope: contoso.com # DNS 域名 CmsPlugins: - ActiveDirectory DomainJoinConfig: DnsName: contoso.com  # DNS 域名 DnsTreeName: contoso.com # DNS 域名根 Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a  # GUID MachineAccountName: WebApp1 # GMSA 账号的用户名 NetBiosName: CONTOSO  # NETBIOS 域名 Sid: S-1-5-21-2126449477-2524075714-3094792973 # GMSA 的 SID ``` <!-- The above credential spec resource may be saved as `gmsa-Webapp1-credspec.yaml` and applied to the cluster using: `kubectl apply -f gmsa-Webapp1-credspec.yml` --> 上面的凭据规约资源可以保存为 `gmsa-Webapp1-credspec.yaml`，之后使用 `kubectl apply -f gmsa-Webapp1-credspec.yml` 应用到集群上。 <!-- ## Configure cluster role to enable RBAC on specific GMSA credential specs A cluster role needs to be defined for each GMSA credential spec resource. This authorizes the `use` verb on a specific GMSA resource by a subject which is typically a service account. The following example shows a cluster role that authorizes usage of the `gmsa-WebApp1` credential spec from above. Save the file as gmsa-webapp1-role.yaml and apply using `kubectl apply -f gmsa-webapp1-role.yaml` --> ## 配置集群角色以启用对特定 GMSA 凭据规约的 RBAC 你需要为每个 GMSA 凭据规约资源定义集群角色。 该集群角色授权某主体（通常是一个服务账号）对特定的 GMSA 资源执行 `use` 动作。 下面的示例显示的是一个集群角色，对前文创建的凭据规约 `gmsa-WebApp1` 执行鉴权。 将此文件保存为 `gmsa-webapp1-role.yaml` 并执行 `kubectl apply -f gmsa-webapp1-role.yaml`。 <!-- ```yaml #Create the Role to read the credspec apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: webapp1-role rules: - apiGroups: ["windows.k8s.io"] resources: ["gmsacredentialspecs"] verbs: ["use"] resourceNames: ["gmsa-WebApp1"] ``` --> ```yaml # 创建集群角色读取凭据规约 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: webapp1-role rules: - apiGroups: ["windows.k8s.io"] resources: ["gmsacredentialspecs"] verbs: ["use"] resourceNames: ["gmsa-WebApp1"] ``` <!-- ## Assign role to service accounts to use specific GMSA credspecs A service account (that Pods will be configured with) needs to be bound to the cluster role create above. This authorizes the service account to use the desired GMSA credential spec resource. The following shows the default service account being bound to a cluster role `webapp1-role` to use `gmsa-WebApp1` credential spec resource created above. --> ## 将角色指派给要使用特定 GMSA 凭据规约的服务账号 你需要将某个服务账号（Pod 配置所对应的那个）绑定到前文创建的集群角色上。 这一绑定操作实际上授予该服务账号使用所指定的 GMSA 凭据规约资源的访问权限。 下面显示的是一个绑定到集群角色 `webapp1-role` 上的 default 服务账号，使之 能够使用前面所创建的 `gmsa-WebApp1` 凭据规约资源。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: allow-default-svc-account-read-on-gmsa-WebApp1 namespace: default subjects: - kind: ServiceAccount name: default namespace: default roleRef: kind: ClusterRole name: webapp1-role apiGroup: rbac.authorization.k8s.io ``` <!-- ## Configure GMSA credential spec reference in Pod spec The Pod spec field `securityContext.windowsOptions.gmsaCredentialSpecName` is used to specify references to desired GMSA credential spec custom resources in Pod specs. This configures all containers in the Pod spec to use the specified GMSA. A sample Pod spec with the annotation populated to refer to `gmsa-WebApp1`: --> ## 在 Pod 规约中配置 GMSA 凭据规约引用 Pod 规约字段 `securityContext.windowsOptions.gmsaCredentialSpecName` 可用来 设置对指定 GMSA 凭据规约自定义资源的引用。 设置此引用将会配置 Pod 中的所有容器使用所给的 GMSA。 下面是一个 Pod 规约示例，其中包含了对 `gmsa-WebApp1` 凭据规约的引用： ```yaml apiVersion: apps/v1 kind: Deployment metadata: labels: run: with-creds name: with-creds namespace: default spec: replicas: 1 selector: matchLabels: run: with-creds template: metadata: labels: run: with-creds spec: securityContext: windowsOptions: gmsaCredentialSpecName: gmsa-webapp1 containers: - image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019 imagePullPolicy: Always name: iis nodeSelector: kubernetes.io/os: windows ``` <!-- Individual containers in a Pod spec can also specify the desired GMSA credspec using a per-container `securityContext.windowsOptions.gmsaCredentialSpecName` field. For example: --> Pod 中的各个容器也可以使用对应容器的 `securityContext.windowsOptions.gmsaCredentialSpecName` 字段来设置期望使用的 GMSA 凭据规约。 例如： ```yaml apiVersion: apps/v1 kind: Deployment metadata: labels: run: with-creds name: with-creds namespace: default spec: replicas: 1 selector: matchLabels: run: with-creds template: metadata: labels: run: with-creds spec: containers: - image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019 imagePullPolicy: Always name: iis securityContext: windowsOptions: gmsaCredentialSpecName: gmsa-Webapp1 nodeSelector: kubernetes.io/os: windows ``` <!-- As Pod specs with GMSA fields populated (as described above) are applied in a cluster, the following sequence of events take place: 1. The mutating webhook resolves and expands all references to GMSA credential spec resources to the contents of the GMSA credential spec. 1. The validating webhook ensures the service account associated with the Pod is authorized for the `use` verb on the specified GMSA credential spec. 1. The container runtime configures each Windows container with the specified GMSA credential spec so that the container can assume the identity of the GMSA in Active Directory and access services in the domain using that identity. --> 当 Pod 规约中填充了 GMSA 相关字段（如上所述），在集群中应用 Pod 规约时会依次 发生以下事件： 1. Mutating Webhook 解析对 GMSA 凭据规约资源的引用，并将其全部展开， 得到 GMSA 凭据规约的实际内容。 1. Validating Webhook 确保与 Pod 相关联的服务账号有权在所给的 GMSA 凭据规约 上执行 `use` 动作。 1. 容器运行时为每个 Windows 容器配置所指定的 GMSA 凭据规约，这样容器就可以以 活动目录中该 GMSA 所代表的身份来执行操作，使用该身份来访问域中的服务。 <!-- ## Troubleshooting If you are having difficulties getting GMSA to work in your environment, there are a few troubleshooting steps you can take. --> ## 故障排查 如果在你的环境中配置 GMSA 时遇到了困难，你可以采取若干步骤来排查可能 的故障。 <!-- First, make sure the credspec has been passed to the Pod.  To do this you will need to `exec` into one of your Pods and check the output of the `nltest.exe /parentdomain` command.  In the example below the Pod did not get the credspec correctly: --> 首先，确保凭据规约已经被传递到 Pod。要实现这点，你需要先通过 `exec` 进入到 你的 Pod 之一，检查 `nltest.exe /parentdomain` 命令的输出。 在下面的例子中，Pod 未能正确地获得凭据规约： ```shell kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe Windows PowerShell Copyright (C) Microsoft Corporation. All rights reserved. PS C:> nltest.exe /parentdomain Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE PS C:> ``` <!-- If your Pod did get the credspec correctly, then next check communication with the domain.  First, from inside of your Pod, quickly do an nslookup to find the root of your domain. This will tell us 3 things: 1. The Pod can reach the DC 1. The DC can reach the Pod 1. DNS is working correctly. --> 如果 Pod 未能正确获得凭据规约，则下一步就要检查与域之间的通信。 首先，从 Pod 内部快速执行一个 nslookup 操作，找到域根。 这一操作会告诉我们三件事情： 1. Pod 能否访问域控制器（DC） 1. DC 能否访问 Pod 1. DNS 是否正常工作 <!-- If the DNS and communication test passes, next you will need to check if the Pod has established secure channel communication with the domain.  To do this, again, `exec` into your Pod and run the `nltest.exe /query` command. --> 如果 DNS 和通信测试通过，接下来你需要检查是否 Pod 已经与域之间建立了 安全通信通道。要执行这一检查，你需要再次通过 `exec` 进入到你的 Pod 中 并执行 `nltest.exe /query` 命令。 ```shell PS C:> nltest.exe /query I_NetLogonControl failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE ``` <!-- This tells us that for some reason, the Pod was unable to logon to the domain using the account specified in the credspec.  You can try to repair the secure channel by running the `nltest.exe /sc_reset:domain.example` command. --> 这一输出告诉我们，由于某些原因，Pod 无法使用凭据规约中的账号登录到域。 你可以通过运行 `nltest.exe /sc_reset:domain.example` 命令尝试修复安全通道。 ```shell PS C:> nltest /sc_reset:domain.example Flags: 30 HAS_IP  HAS_TIMESERV Trusted DC Name dc10.domain.example Trusted DC Connection Status Status = 0 0x0 NERR_Success The command completed successfully PS C:> ``` <!-- If the above command corrects the error, you can automate the step by adding the following lifecycle hook to your Pod spec.  If it did not correct the error, you will need to examine your credspec again and confirm that it is correct and complete. --> 如果上述命令修复了错误，你就可以通过向你的 Pod 规约添加生命周期回调来将此操作 自动化。如果上述命令未能奏效，你就需要再次检查凭据规约，以确保其数据时正确的 而且是完整的。 ```yaml image: registry.domain.example/iis-auth:1809v1 lifecycle: postStart: exec: command: ["powershell.exe","-command","do { Restart-Service -Name netlogon } while ( $($Result = (nltest.exe /query); if ($Result -like '*0x0 NERR_Success*') {return $true} else {return $false}) -eq $false)"] imagePullPolicy: IfNotPresent ``` <!-- If you add the `lifecycle` section show above to your Pod spec, the Pod will execute the commands listed to restart the `netlogon` service until the `nltest.exe /query` command exits without error. --> 如果你向你的 Pod 规约中添加如上所示的 `lifecycle` 节，则 Pod 会自动执行所 列举的命令来重启 `netlogon` 服务，直到 `nltest.exe /query` 命令返回时没有错误信息。 <!-- ## GMSA limitations When using the [ContainerD runtime for Windows](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#cri-containerd) accessing restricted network shares via the GMSA domain identity fails. The container will recieve the identity of and calls from `nltest.exe /query` will work.  It is recommended to use the [Docker EE runtime](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#docker-ee) if access to network shares is required.  The Windows Server team is working on resolving the issue in the Windows Kernel and will release a patch to resolve this issue in the future. Look for updates on the [Microsoft Windows Containers issue tracker](https://github.com/microsoft/Windows-Containers/issues/44). --> ## GMSA 的局限 在使用 [Windows 版本的 ContainerD 运行时](/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#cri-containerd) 时，通过 GMSA 域身份标识访问受限制的网络共享资源时会出错。 容器会收到身份标识且 `nltest.exe /query` 调用也能正常工作。 当需要访问网络共享资源时，建议使用 [Docker EE 运行时](/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#docker-ee)。 Windows Server 团队正在 Windows 内核中解决这一问题，并在将来发布解决此问题的补丁。 你可以在 [Microsoft Windows Containers 问题跟踪列表](https://github.com/microsoft/Windows-Containers/issues/44) 中查找这类更新。 </ins>


from the community. Please try it out and give us feedback! {{< /caution >}} <ins> ## kubeadm alpha certs {#cmd-certs} A collection of operations for operating Kubernetes certificates. {{< tabs name="tab-certs" >}} {{< tab name="overview" include="generated/kubeadm_alpha_certs.md" />}} {{< /tabs >}} </ins> ## kubeadm alpha certs renew {#cmd-certs-renew} You can renew all Kubernetes certificates using the `all` subcommand or renew them selectively.


{{< tab name="certificate-key" include="generated/kubeadm_alpha_certs_certificate-key.md" />}} {{< /tabs >}} <ins> ## kubeadm alpha certs generate-csr {#cmd-certs-generate-csr} This command can be used to generate certificate signing requests (CSRs) which can be submitted to a certificate authority (CA) for signing. {{< tabs name="tab-certs-generate-csr" >}} {{< tab name="certificate-generate-csr" include="generated/kubeadm_alpha_certs_generate-csr.md" />}} {{< /tabs >}} </ins> ## kubeadm alpha certs check-expiration {#cmd-certs-check-expiration} This command checks expiration for the certificates in the local PKI managed by kubeadm.


{{< tab name="bootstrap-token" include="generated/kubeadm_init_phase_bootstrap-token.md" />}} {{< /tabs >}} <ins> ## kubeadm init phase kubelet-finialize {#cmd-phase-kubelet-finalize-all} Use the following phase to update settings relevant to the kubelet after TLS bootstrap. You can use the `all` subcommand to run all `kubelet-finalize` phases. {{< tabs name="tab-kubelet-finalize" >}} {{< tab name="kublet-finalize" include="generated/kubeadm_init_phase_kubelet-finalize.md" />}} {{< tab name="kublet-finalize-all" include="generated/kubeadm_init_phase_kubelet-finalize_all.md" />}} {{< tab name="kublet-finalize-cert-rotation" include="generated/kubeadm_init_phase_kubelet-finalize_experimental-cert-rotation.md" />}} {{< /tabs >}} </ins> ## kubeadm init phase addon {#cmd-phase-addon}


{{< tabs name="tab-phase" >}} {{< tab name="phase" include="generated/kubeadm_upgrade_node_phase.md" />}} <ins> {{< tab name="preflight" include="generated/kubeadm_upgrade_node_phase_preflight.md" />}} </ins> {{< tab name="control-plane" include="generated/kubeadm_upgrade_node_phase_control-plane.md" />}} {{< tab name="kubelet-config" include="generated/kubeadm_upgrade_node_phase_kubelet-config.md" />}} {{< /tabs >}}


Notice how the number of desired replicas is 3 according to `.spec.replicas` field. <del> 3. To see the Deployment rollout status, run `kubectl rollout status deployment.v1.apps/nginx-deployment`. </del> <ins> 3. To see the Deployment rollout status, run `kubectl rollout status deployment/nginx-deployment`. </ins> The output is similar to: ```


2. To see the rollout status, run: ```shell <del> kubectl rollout status deployment.v1.apps/nginx-deployment </del> <ins> kubectl rollout status deployment/nginx-deployment </ins> ``` The output is similar to this:


* The rollout gets stuck. You can verify it by checking the rollout status: ```shell <del> kubectl rollout status deployment.v1.apps/nginx-deployment </del> <ins> kubectl rollout status deployment/nginx-deployment </ins> ``` The output is similar to this:


successfully, `kubectl rollout status` returns a zero exit code. ```shell <del> kubectl rollout status deployment.v1.apps/nginx-deployment </del> <ins> kubectl rollout status deployment/nginx-deployment </ins> ``` The output is similar to this: ```


returns a non-zero exit code if the Deployment has exceeded the progression deadline. ```shell <del> kubectl rollout status deployment.v1.apps/nginx-deployment </del> <ins> kubectl rollout status deployment/nginx-deployment </ins> ``` The output is similar to this: ```


<ins> --- title: 对象 id: object date: 2020-10-12 full_link: https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects short_description: > Kubernetes 系统中的实体, 代表了集群的部分状态。 aka: tags: - fundamental --- <!-- --- title: Object id: object date: 2020-10-12 full_link: https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects short_description: > A entity in the Kubernetes system, representing part of the state of your cluster. aka: tags: - fundamental --- --> <!-- An entity in the Kubernetes system. The Kubernetes API uses these entities to represent the state of your cluster. --> Kubernetes 系统中的实体。Kubernetes API 用这些实体表示集群的状态。 <!--more--> <!-- A Kubernetes object is typically a “record of intent”—once you create the object, the Kubernetes {{< glossary_tooltip text="control plane" term_id="control-plane" >}} works constantly to ensure that the item it represents actually exists. By creating an object, you're effectively telling the Kubernetes system what you want that part of your cluster's workload to look like; this is your cluster's desired state. --> Kubernetes 对象通常是一个“目标记录”-一旦你创建了一个对象，Kubernetes {{< glossary_tooltip text="控制平面" term_id="control-plane" >}} 不断工作，以确保它代表的项目确实存在。 创建一个对象相当于告知 Kubernetes 系统：你期望这部分集群负载看起来像什么；这也就是你集群的期望状态。 </ins>  No newline at end of file


--- reviewers: <del> title: Configuring kubelet Garbage Collection </del> <ins> title: Garbage collection for container images </ins> content_type: concept weight: 70 --- <!-- overview --> <del> Garbage collection is a helpful function of kubelet that will clean up unused images and unused containers. Kubelet will perform garbage collection for containers every minute and garbage collection for images every five minutes. </del> <ins> Garbage collection is a helpful function of kubelet that will clean up unused [images](/docs/concepts/containers/#container-images) and unused [containers](/docs/concepts/containers/). Kubelet will perform garbage collection for containers every minute and garbage collection for images every five minutes. </ins> External garbage collection tools are not recommended as these tools can potentially break the behavior of kubelet by removing containers expected to exist.


You can acquire all these from the [nginx https example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/). This requires having go and make tools installed. If you don't want to install those, then follow the manual steps later. In short: --> <del> ## Service 安全 </del> <ins> ## 保护 Service {#securing-the-service} </ins> <del> 到现在为止，我们只在集群内部访问了 Nginx server。在将 Service 暴露到 Internet 之前，我们希望确保通信信道是安全的。对于这可能需要： </del> <ins> 到现在为止，我们只在集群内部访问了 Nginx 服务器。在将 Service 暴露到因特网之前，我们希望确保通信信道是安全的。 为实现这一目的，可能需要： </ins> <del> * https 自签名证书（除非已经有了一个识别身份的证书） * 使用证书配置的 Nginx server </del> <ins> * 用于 HTTPS 的自签名证书（除非已经有了一个识别身份的证书） * 使用证书配置的 Nginx 服务器 </ins> * 使证书可以访问 Pod 的 [Secret](/zh/docs/concepts/configuration/secret/) <del> 可以从 [Nginx https 示例](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/examples/https-nginx/) 获取所有上述内容，简明示例如下： </del> <ins> 你可以从 [Nginx https 示例](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/staging/https-nginx/) 获取所有上述内容。你需要安装 go 和 make 工具。如果你不想安装这些软件，可以按照 后文所述的手动执行步骤执行操作。简要过程如下： </ins> ```shell make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt


<!-- Following are the manual steps to follow in case you run into problems running make (on windows for example): --> <del> 以下是您在运行make时遇到问题时要遵循的手动步骤（例如，在Windows上）： </del> <ins> 以下是你在运行 make 时遇到问题时要遵循的手动步骤（例如，在 Windows 上）： </ins> ```shell # Create a public private key pair


<!-- Use the output from the previous commands to create a yaml file as follows. The base64 encoded value should all be on a single line. --> <del> 使用前面命令的输出来创建yaml文件，如下所示。 base64编码的值应全部放在一行上。 </del> <ins> 使用前面命令的输出来创建 yaml 文件，如下所示。 base64 编码的值应全部放在一行上。 </ins> ```yaml apiVersion: "v1"


<!-- Now create the secrets using the file: --> <del> 现在使用文件创建 secrets： </del> <ins> 现在使用文件创建 Secrets： </ins> ```shell kubectl apply -f nginxsecrets.yaml


<!-- Now modify your nginx replicas to start an https server using the certificate in the secret, and the Service, to expose both ports (80 and 443): --> <del> 现在修改 Nginx 副本，启动一个使用在秘钥中的证书的 https 服务器和 Servcie，都暴露端口（80 和 443）： </del> <ins> 现在修改 nginx 副本，启动一个使用在秘钥中的证书的 HTTPS 服务器和 Servcie，暴露端口（80 和 443）： </ins> {{< codenew file="service/networking/nginx-secure-app.yaml" >}}


- Each container has access to the keys through a volume mounted at `/etc/nginx/ssl`. This is setup *before* the nginx server is started. --> <ins> 关于 nginx-secure-app 清单，值得注意的几点如下： </ins> <del> 关于 nginx-secure-app manifest 值得注意的点如下： - 它在相同的文件中包含了 Deployment 和 Service 的规格 - [Nginx 服务器](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/examples/https-nginx/default.conf) 处理 80 端口上的 http 流量，以及 443  端口上的 https 流量，Nginx Service 暴露了这两个端口。 - 每个容器访问挂载在 /etc/nginx/ssl 卷上的秘钥。这需要在 Nginx server 启动之前安装好。 </del> <ins> - 它在相同的文件中包含了 Deployment 和 Service 的规约 - [nginx 服务器](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/staging/https-nginx/default.conf) 处理 80 端口上的 HTTP 流量，以及 443  端口上的 HTTPS 流量，Nginx Service 暴露了这两个端口。 - 每个容器访问挂载在 /etc/nginx/ssl 卷上的秘钥。这需要在 Nginx 服务器启动之前安装好。 </ins> ```shell kubectl delete deployments,svc my-nginx; kubectl create -f ./nginx-secure-app.yaml


<!-- At this point you can reach the nginx server from any node. --> <del> 这时可以从任何节点访问到 Nginx server。 </del> <ins> 这时，你可以从任何节点访问到 Nginx 服务器。 </ins> ```shell kubectl get pods -o yaml | grep -i podip


so we have to tell curl to ignore the CName mismatch. By creating a Service we linked the CName used in the certificate with the actual DNS name used by pods during Service lookup. Let's test this from a pod (the same secret is being reused for simplicity, the pod only needs nginx.crt to access the Service): --> <del> 注意最后一步我们是如何提供 `-k` 参数执行 curl命令的，这是因为在证书生成时， 我们不知道任何关于运行 Nginx 的 Pod 的信息，所以不得不在执行 curl 命令时忽略 CName 不匹配的情况。 通过创建 Service，我们连接了在证书中的 CName 与在 Service 查询时被 Pod使用的实际 DNS 名字。 </del> <ins> 注意最后一步我们是如何提供 `-k` 参数执行 curl 命令的，这是因为在证书生成时， 我们不知道任何关于运行 nginx 的 Pod 的信息，所以不得不在执行 curl 命令时忽略 CName 不匹配的情况。 通过创建 Service，我们连接了在证书中的 CName 与在 Service 查询时被 Pod 使用的实际 DNS 名字。 </ins> 让我们从一个 Pod 来测试（为了简化使用同一个秘钥，Pod 仅需要使用 nginx.crt 去访问 Service）： {{< codenew file="service/networking/curlpod.yaml" >}}


Let's now recreate the Service to use a cloud load balancer, just change the `Type` of `my-nginx` Service from `NodePort` to `LoadBalancer`: --> <del> 让我们重新创建一个 Service，使用一个云负载均衡器，只需要将 `my-nginx` Service 的 `Type` 由 `NodePort` 改成 `LoadBalancer`。 </del> <ins> 让我们重新创建一个 Service，使用一个云负载均衡器，只需要将 `my-nginx` Service 的 `Type` 由 `NodePort` 改成 `LoadBalancer`。 </ins> ```shell kubectl edit svc my-nginx


在开始本教程之前，你应该熟悉以下 Kubernetes 的概念： <del> * [Pods](/zh/docs/user-guide/pods/single-container/) </del> <ins> * [Pods](/zh/docs/concepts/workloads/pods/) </ins> * [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/)


即使你已经删除了 StatefulSet 和它的全部 Pod，这些 Pod 将会被重新创建并挂载它们的 PersistentVolumes，并且 `web-0` 和 `web-1` 将仍然使用它们的主机名提供服务。 <del> 最后删除 `web` StatefulSet 和 `nginx` service。 </del> <ins> 最后删除 `nginx` service... </ins> ```shell kubectl delete service nginx <ins> ``` ``` </ins> service "nginx" deleted <ins> ``` ... 并且删除 `web` StatefulSet: ```shell </ins> kubectl delete statefulset web <ins> ``` ``` </ins> statefulset "web" deleted ```


<ins> <script src="/js/popper-1.14.3.min.js" integrity="sha384-ZMP7rVo3mIykV+2+9J3UJ46jBk0WLaUAdn689aCwoqbBJiSnjAK/l8WvCWPIPm49" crossorigin="anonymous"></script> <script src="/js/bootstrap-4.3.1.min.js" integrity="sha384-JjSmVgyd0p3pXB1rRibZUAYoIIy6OrQ6VrjIEaFf/nJGzIxFDsf4x0xIM+B07jRM" crossorigin="anonymous"></script> {{ if .Site.Params.mermaid.enable }} <script src="/js//mermaid.min.js" crossorigin="anonymous"></script> {{ end }} {{ $jsBase := resources.Get "js/base.js" }} {{ $jsAnchor := resources.Get "js/anchor.js" }} {{ $jsSearch := resources.Get "js/search.js" | resources.ExecuteAsTemplate "js/search.js" .Site.Home }} {{ $jsMermaid := resources.Get "js/mermaid.js" | resources.ExecuteAsTemplate "js/mermaid.js" . }} {{ if .Site.Params.offlineSearch }} {{ $jsSearch = resources.Get "js/offline-search.js" }} {{ end }} {{ $js := (slice $jsBase $jsAnchor $jsSearch $jsMermaid) | resources.Concat "js/main.js" }} {{ if .Site.IsServer }} <script src="{{ $js.RelPermalink }}"></script> {{ else }} {{ $js := $js | minify | fingerprint }} <script src="{{ $js.RelPermalink }}" integrity="{{ $js.Data.Integrity }}" crossorigin="anonymous"></script> {{ end }} {{ with .Site.Params.prism_syntax_highlighting }} <!-- scripts for prism --> <script src='/js/prism.js'></script> {{ end }} {{ partial "hooks/body-end.html" . }} </ins>


<ins> /* Copyright (C) Federico Zivolo 2018 Distributed under the MIT License (license terms are at http://opensource.org/licenses/MIT). */(function(e,t){'object'==typeof exports&&'undefined'!=typeof module?module.exports=t():'function'==typeof define&&define.amd?define(t):e.Popper=t()})(this,function(){'use strict';function e(e){return e&&'[object Function]'==={}.toString.call(e)}function t(e,t){if(1!==e.nodeType)return[];var o=getComputedStyle(e,null);return t?o[t]:o}function o(e){return'HTML'===e.nodeName?e:e.parentNode||e.host}function n(e){if(!e)return document.body;switch(e.nodeName){case'HTML':case'BODY':return e.ownerDocument.body;case'#document':return e.body;}var i=t(e),r=i.overflow,p=i.overflowX,s=i.overflowY;return /(auto|scroll|overlay)/.test(r+s+p)?e:n(o(e))}function r(e){return 11===e?re:10===e?pe:re||pe}function p(e){if(!e)return document.documentElement;for(var o=r(10)?document.body:null,n=e.offsetParent;n===o&&e.nextElementSibling;)n=(e=e.nextElementSibling).offsetParent;var i=n&&n.nodeName;return i&&'BODY'!==i&&'HTML'!==i?-1!==['TD','TABLE'].indexOf(n.nodeName)&&'static'===t(n,'position')?p(n):n:e?e.ownerDocument.documentElement:document.documentElement}function s(e){var t=e.nodeName;return'BODY'!==t&&('HTML'===t||p(e.firstElementChild)===e)}function d(e){return null===e.parentNode?e:d(e.parentNode)}function a(e,t){if(!e||!e.nodeType||!t||!t.nodeType)return document.documentElement;var o=e.compareDocumentPosition(t)&Node.DOCUMENT_POSITION_FOLLOWING,n=o?e:t,i=o?t:e,r=document.createRange();r.setStart(n,0),r.setEnd(i,0);var l=r.commonAncestorContainer;if(e!==l&&t!==l||n.contains(i))return s(l)?l:p(l);var f=d(e);return f.host?a(f.host,t):a(e,d(t).host)}function l(e){var t=1<arguments.length&&void 0!==arguments[1]?arguments[1]:'top',o='top'===t?'scrollTop':'scrollLeft',n=e.nodeName;if('BODY'===n||'HTML'===n){var i=e.ownerDocument.documentElement,r=e.ownerDocument.scrollingElement||i;return r[o]}return e[o]}function f(e,t){var o=2<arguments.length&&void 0!==arguments[2]&&arguments[2],n=l(t,'top'),i=l(t,'left'),r=o?-1:1;return e.top+=n*r,e.bottom+=n*r,e.left+=i*r,e.right+=i*r,e}function m(e,t){var o='x'===t?'Left':'Top',n='Left'==o?'Right':'Bottom';return parseFloat(e['border'+o+'Width'],10)+parseFloat(e['border'+n+'Width'],10)}function h(e,t,o,n){return $(t['offset'+e],t['scroll'+e],o['client'+e],o['offset'+e],o['scroll'+e],r(10)?o['offset'+e]+n['margin'+('Height'===e?'Top':'Left')]+n['margin'+('Height'===e?'Bottom':'Right')]:0)}function c(){var e=document.body,t=document.documentElement,o=r(10)&&getComputedStyle(t);return{height:h('Height',e,t,o),width:h('Width',e,t,o)}}function g(e){return le({},e,{right:e.left+e.width,bottom:e.top+e.height})}function u(e){var o={};try{if(r(10)){o=e.getBoundingClientRect();var n=l(e,'top'),i=l(e,'left');o.top+=n,o.left+=i,o.bottom+=n,o.right+=i}else o=e.getBoundingClientRect()}catch(t){}var p={left:o.left,top:o.top,width:o.right-o.left,height:o.bottom-o.top},s='HTML'===e.nodeName?c():{},d=s.width||e.clientWidth||p.right-p.left,a=s.height||e.clientHeight||p.bottom-p.top,f=e.offsetWidth-d,h=e.offsetHeight-a;if(f||h){var u=t(e);f-=m(u,'x'),h-=m(u,'y'),p.width-=f,p.height-=h}return g(p)}function b(e,o){var i=2<arguments.length&&void 0!==arguments[2]&&arguments[2],p=r(10),s='HTML'===o.nodeName,d=u(e),a=u(o),l=n(e),m=t(o),h=parseFloat(m.borderTopWidth,10),c=parseFloat(m.borderLeftWidth,10);i&&'HTML'===o.nodeName&&(a.top=$(a.top,0),a.left=$(a.left,0));var b=g({top:d.top-a.top-h,left:d.left-a.left-c,width:d.width,height:d.height});if(b.marginTop=0,b.marginLeft=0,!p&&s){var y=parseFloat(m.marginTop,10),w=parseFloat(m.marginLeft,10);b.top-=h-y,b.bottom-=h-y,b.left-=c-w,b.right-=c-w,b.marginTop=y,b.marginLeft=w}return(p&&!i?o.contains(l):o===l&&'BODY'!==l.nodeName)&&(b=f(b,o)),b}function y(e){var t=1<arguments.length&&void 0!==arguments[1]&&arguments[1],o=e.ownerDocument.documentElement,n=b(e,o),i=$(o.clientWidth,window.innerWidth||0),r=$(o.clientHeight,window.innerHeight||0),p=t?0:l(o),s=t?0:l(o,'left'),d={top:p-n.top+n.marginTop,left:s-n.left+n.marginLeft,width:i,height:r};return g(d)}function w(e){var n=e.nodeName;return'BODY'===n||'HTML'===n?!1:'fixed'===t(e,'position')||w(o(e))}function E(e){if(!e||!e.parentElement||r())return document.documentElement;for(var o=e.parentElement;o&&'none'===t(o,'transform');)o=o.parentElement;return o||document.documentElement}function v(e,t,i,r){var p=4<arguments.length&&void 0!==arguments[4]&&arguments[4],s={top:0,left:0},d=p?E(e):a(e,t);if('viewport'===r)s=y(d,p);else{var l;'scrollParent'===r?(l=n(o(t)),'BODY'===l.nodeName&&(l=e.ownerDocument.documentElement)):'window'===r?l=e.ownerDocument.documentElement:l=r;var f=b(l,d,p);if('HTML'===l.nodeName&&!w(d)){var m=c(),h=m.height,g=m.width;s.top+=f.top-f.marginTop,s.bottom=h+f.top,s.left+=f.left-f.marginLeft,s.right=g+f.left}else s=f}return s.left+=i,s.top+=i,s.right-=i,s.bottom-=i,s}function x(e){var t=e.width,o=e.height;return t*o}function O(e,t,o,n,i){var r=5<arguments.length&&void 0!==arguments[5]?arguments[5]:0;if(-1===e.indexOf('auto'))return e;var p=v(o,n,r,i),s={top:{width:p.width,height:t.top-p.top},right:{width:p.right-t.right,height:p.height},bottom:{width:p.width,height:p.bottom-t.bottom},left:{width:t.left-p.left,height:p.height}},d=Object.keys(s).map(function(e){return le({key:e},s[e],{area:x(s[e])})}).sort(function(e,t){return t.area-e.area}),a=d.filter(function(e){var t=e.width,n=e.height;return t>=o.clientWidth&&n>=o.clientHeight}),l=0<a.length?a[0].key:d[0].key,f=e.split('-')[1];return l+(f?'-'+f:'')}function L(e,t,o){var n=3<arguments.length&&void 0!==arguments[3]?arguments[3]:null,i=n?E(t):a(t,o);return b(o,i,n)}function S(e){var t=getComputedStyle(e),o=parseFloat(t.marginTop)+parseFloat(t.marginBottom),n=parseFloat(t.marginLeft)+parseFloat(t.marginRight),i={width:e.offsetWidth+n,height:e.offsetHeight+o};return i}function T(e){var t={left:'right',right:'left',bottom:'top',top:'bottom'};return e.replace(/left|right|bottom|top/g,function(e){return t[e]})}function C(e,t,o){o=o.split('-')[0];var n=S(e),i={width:n.width,height:n.height},r=-1!==['right','left'].indexOf(o),p=r?'top':'left',s=r?'left':'top',d=r?'height':'width',a=r?'width':'height';return i[p]=t[p]+t[d]/2-n[d]/2,i[s]=o===s?t[s]-n[a]:t[T(s)],i}function D(e,t){return Array.prototype.find?e.find(t):e.filter(t)[0]}function N(e,t,o){if(Array.prototype.findIndex)return e.findIndex(function(e){return e[t]===o});var n=D(e,function(e){return e[t]===o});return e.indexOf(n)}function P(t,o,n){var i=void 0===n?t:t.slice(0,N(t,'name',n));return i.forEach(function(t){t['function']&&console.warn('`modifier.function` is deprecated, use `modifier.fn`!');var n=t['function']||t.fn;t.enabled&&e(n)&&(o.offsets.popper=g(o.offsets.popper),o.offsets.reference=g(o.offsets.reference),o=n(o,t))}),o}function k(){if(!this.state.isDestroyed){var e={instance:this,styles:{},arrowStyles:{},attributes:{},flipped:!1,offsets:{}};e.offsets.reference=L(this.state,this.popper,this.reference,this.options.positionFixed),e.placement=O(this.options.placement,e.offsets.reference,this.popper,this.reference,this.options.modifiers.flip.boundariesElement,this.options.modifiers.flip.padding),e.originalPlacement=e.placement,e.positionFixed=this.options.positionFixed,e.offsets.popper=C(this.popper,e.offsets.reference,e.placement),e.offsets.popper.position=this.options.positionFixed?'fixed':'absolute',e=P(this.modifiers,e),this.state.isCreated?this.options.onUpdate(e):(this.state.isCreated=!0,this.options.onCreate(e))}}function W(e,t){return e.some(function(e){var o=e.name,n=e.enabled;return n&&o===t})}function B(e){for(var t=[!1,'ms','Webkit','Moz','O'],o=e.charAt(0).toUpperCase()+e.slice(1),n=0;n<t.length;n++){var i=t[n],r=i?''+i+o:e;if('undefined'!=typeof document.body.style[r])return r}return null}function H(){return this.state.isDestroyed=!0,W(this.modifiers,'applyStyle')&&(this.popper.removeAttribute('x-placement'),this.popper.style.position='',this.popper.style.top='',this.popper.style.left='',this.popper.style.right='',this.popper.style.bottom='',this.popper.style.willChange='',this.popper.style[B('transform')]=''),this.disableEventListeners(),this.options.removeOnDestroy&&this.popper.parentNode.removeChild(this.popper),this}function A(e){var t=e.ownerDocument;return t?t.defaultView:window}function M(e,t,o,i){var r='BODY'===e.nodeName,p=r?e.ownerDocument.defaultView:e;p.addEventListener(t,o,{passive:!0}),r||M(n(p.parentNode),t,o,i),i.push(p)}function I(e,t,o,i){o.updateBound=i,A(e).addEventListener('resize',o.updateBound,{passive:!0});var r=n(e);return M(r,'scroll',o.updateBound,o.scrollParents),o.scrollElement=r,o.eventsEnabled=!0,o}function F(){this.state.eventsEnabled||(this.state=I(this.reference,this.options,this.state,this.scheduleUpdate))}function R(e,t){return A(e).removeEventListener('resize',t.updateBound),t.scrollParents.forEach(function(e){e.removeEventListener('scroll',t.updateBound)}),t.updateBound=null,t.scrollParents=[],t.scrollElement=null,t.eventsEnabled=!1,t}function U(){this.state.eventsEnabled&&(cancelAnimationFrame(this.scheduleUpdate),this.state=R(this.reference,this.state))}function Y(e){return''!==e&&!isNaN(parseFloat(e))&&isFinite(e)}function j(e,t){Object.keys(t).forEach(function(o){var n='';-1!==['width','height','top','right','bottom','left'].indexOf(o)&&Y(t[o])&&(n='px'),e.style[o]=t[o]+n})}function K(e,t){Object.keys(t).forEach(function(o){var n=t[o];!1===n?e.removeAttribute(o):e.setAttribute(o,t[o])})}function q(e,t,o){var n=D(e,function(e){var o=e.name;return o===t}),i=!!n&&e.some(function(e){return e.name===o&&e.enabled&&e.order<n.order});if(!i){var r='`'+t+'`';console.warn('`'+o+'`'+' modifier is required by '+r+' modifier in order to work, be sure to include it before '+r+'!')}return i}function G(e){return'end'===e?'start':'start'===e?'end':e}function z(e){var t=1<arguments.length&&void 0!==arguments[1]&&arguments[1],o=me.indexOf(e),n=me.slice(o+1).concat(me.slice(0,o));return t?n.reverse():n}function V(e,t,o,n){var i=e.match(/((?:-|+)?d*.?d*)(.*)/),r=+i[1],p=i[2];if(!r)return e;if(0===p.indexOf('%')){var s;switch(p){case'%p':s=o;break;case'%':case'%r':default:s=n;}var d=g(s);return d[t]/100*r}if('vh'===p||'vw'===p){var a;return a='vh'===p?$(document.documentElement.clientHeight,window.innerHeight||0):$(document.documentElement.clientWidth,window.innerWidth||0),a/100*r}return r}function _(e,t,o,n){var i=[0,0],r=-1!==['right','left'].indexOf(n),p=e.split(/(+|-)/).map(function(e){return e.trim()}),s=p.indexOf(D(p,function(e){return-1!==e.search(/,|s/)}));p[s]&&-1===p[s].indexOf(',')&&console.warn('Offsets separated by white space(s) are deprecated, use a comma (,) instead.');var d=/s*,s*|s+/,a=-1===s?[p]:[p.slice(0,s).concat([p[s].split(d)[0]]),[p[s].split(d)[1]].concat(p.slice(s+1))];return a=a.map(function(e,n){var i=(1===n?!r:r)?'height':'width',p=!1;return e.reduce(function(e,t){return''===e[e.length-1]&&-1!==['+','-'].indexOf(t)?(e[e.length-1]=t,p=!0,e):p?(e[e.length-1]+=t,p=!1,e):e.concat(t)},[]).map(function(e){return V(e,i,t,o)})}),a.forEach(function(e,t){e.forEach(function(o,n){Y(o)&&(i[t]+=o*('-'===e[n-1]?-1:1))})}),i}function X(e,t){var o,n=t.offset,i=e.placement,r=e.offsets,p=r.popper,s=r.reference,d=i.split('-')[0];return o=Y(+n)?[+n,0]:_(n,p,s,d),'left'===d?(p.top+=o[0],p.left-=o[1]):'right'===d?(p.top+=o[0],p.left+=o[1]):'top'===d?(p.left+=o[0],p.top-=o[1]):'bottom'===d&&(p.left+=o[0],p.top+=o[1]),e.popper=p,e}for(var J=Math.min,Q=Math.round,Z=Math.floor,$=Math.max,ee='undefined'!=typeof window&&'undefined'!=typeof document,te=['Edge','Trident','Firefox'],oe=0,ne=0;ne<te.length;ne+=1)if(ee&&0<=navigator.userAgent.indexOf(te[ne])){oe=1;break}var i=ee&&window.Promise,ie=i?function(e){var t=!1;return function(){t||(t=!0,window.Promise.resolve().then(function(){t=!1,e()}))}}:function(e){var t=!1;return function(){t||(t=!0,setTimeout(function(){t=!1,e()},oe))}},re=ee&&!!(window.MSInputMethodContext&&document.documentMode),pe=ee&&/MSIE 10/.test(navigator.userAgent),se=function(e,t){if(!(e instanceof t))throw new TypeError('Cannot call a class as a function')},de=function(){function e(e,t){for(var o,n=0;n<t.length;n++)o=t[n],o.enumerable=o.enumerable||!1,o.configurable=!0,'value'in o&&(o.writable=!0),Object.defineProperty(e,o.key,o)}return function(t,o,n){return o&&e(t.prototype,o),n&&e(t,n),t}}(),ae=function(e,t,o){return t in e?Object.defineProperty(e,t,{value:o,enumerable:!0,configurable:!0,writable:!0}):e[t]=o,e},le=Object.assign||function(e){for(var t,o=1;o<arguments.length;o++)for(var n in t=arguments[o],t)Object.prototype.hasOwnProperty.call(t,n)&&(e[n]=t[n]);return e},fe=['auto-start','auto','auto-end','top-start','top','top-end','right-start','right','right-end','bottom-end','bottom','bottom-start','left-end','left','left-start'],me=fe.slice(3),he={FLIP:'flip',CLOCKWISE:'clockwise',COUNTERCLOCKWISE:'counterclockwise'},ce=function(){function t(o,n){var i=this,r=2<arguments.length&&void 0!==arguments[2]?arguments[2]:{};se(this,t),this.scheduleUpdate=function(){return requestAnimationFrame(i.update)},this.update=ie(this.update.bind(this)),this.options=le({},t.Defaults,r),this.state={isDestroyed:!1,isCreated:!1,scrollParents:[]},this.reference=o&&o.jquery?o[0]:o,this.popper=n&&n.jquery?n[0]:n,this.options.modifiers={},Object.keys(le({},t.Defaults.modifiers,r.modifiers)).forEach(function(e){i.options.modifiers[e]=le({},t.Defaults.modifiers[e]||{},r.modifiers?r.modifiers[e]:{})}),this.modifiers=Object.keys(this.options.modifiers).map(function(e){return le({name:e},i.options.modifiers[e])}).sort(function(e,t){return e.order-t.order}),this.modifiers.forEach(function(t){t.enabled&&e(t.onLoad)&&t.onLoad(i.reference,i.popper,i.options,t,i.state)}),this.update();var p=this.options.eventsEnabled;p&&this.enableEventListeners(),this.state.eventsEnabled=p}return de(t,[{key:'update',value:function(){return k.call(this)}},{key:'destroy',value:function(){return H.call(this)}},{key:'enableEventListeners',value:function(){return F.call(this)}},{key:'disableEventListeners',value:function(){return U.call(this)}}]),t}();return ce.Utils=('undefined'==typeof window?global:window).PopperUtils,ce.placements=fe,ce.Defaults={placement:'bottom',positionFixed:!1,eventsEnabled:!0,removeOnDestroy:!1,onCreate:function(){},onUpdate:function(){},modifiers:{shift:{order:100,enabled:!0,fn:function(e){var t=e.placement,o=t.split('-')[0],n=t.split('-')[1];if(n){var i=e.offsets,r=i.reference,p=i.popper,s=-1!==['bottom','top'].indexOf(o),d=s?'left':'top',a=s?'width':'height',l={start:ae({},d,r[d]),end:ae({},d,r[d]+r[a]-p[a])};e.offsets.popper=le({},p,l[n])}return e}},offset:{order:200,enabled:!0,fn:X,offset:0},preventOverflow:{order:300,enabled:!0,fn:function(e,t){var o=t.boundariesElement||p(e.instance.popper);e.instance.reference===o&&(o=p(o));var n=B('transform'),i=e.instance.popper.style,r=i.top,s=i.left,d=i[n];i.top='',i.left='',i[n]='';var a=v(e.instance.popper,e.instance.reference,t.padding,o,e.positionFixed);i.top=r,i.left=s,i[n]=d,t.boundaries=a;var l=t.priority,f=e.offsets.popper,m={primary:function(e){var o=f[e];return f[e]<a[e]&&!t.escapeWithReference&&(o=$(f[e],a[e])),ae({},e,o)},secondary:function(e){var o='right'===e?'left':'top',n=f[o];return f[e]>a[e]&&!t.escapeWithReference&&(n=J(f[o],a[e]-('right'===e?f.width:f.height))),ae({},o,n)}};return l.forEach(function(e){var t=-1===['left','top'].indexOf(e)?'secondary':'primary';f=le({},f,m[t](e))}),e.offsets.popper=f,e},priority:['left','right','top','bottom'],padding:5,boundariesElement:'scrollParent'},keepTogether:{order:400,enabled:!0,fn:function(e){var t=e.offsets,o=t.popper,n=t.reference,i=e.placement.split('-')[0],r=Z,p=-1!==['top','bottom'].indexOf(i),s=p?'right':'bottom',d=p?'left':'top',a=p?'width':'height';return o[s]<r(n[d])&&(e.offsets.popper[d]=r(n[d])-o[a]),o[d]>r(n[s])&&(e.offsets.popper[d]=r(n[s])),e}},arrow:{order:500,enabled:!0,fn:function(e,o){var n;if(!q(e.instance.modifiers,'arrow','keepTogether'))return e;var i=o.element;if('string'==typeof i){if(i=e.instance.popper.querySelector(i),!i)return e;}else if(!e.instance.popper.contains(i))return console.warn('WARNING: `arrow.element` must be child of its popper element!'),e;var r=e.placement.split('-')[0],p=e.offsets,s=p.popper,d=p.reference,a=-1!==['left','right'].indexOf(r),l=a?'height':'width',f=a?'Top':'Left',m=f.toLowerCase(),h=a?'left':'top',c=a?'bottom':'right',u=S(i)[l];d[c]-u<s[m]&&(e.offsets.popper[m]-=s[m]-(d[c]-u)),d[m]+u>s[c]&&(e.offsets.popper[m]+=d[m]+u-s[c]),e.offsets.popper=g(e.offsets.popper);var b=d[m]+d[l]/2-u/2,y=t(e.instance.popper),w=parseFloat(y['margin'+f],10),E=parseFloat(y['border'+f+'Width'],10),v=b-e.offsets.popper[m]-w-E;return v=$(J(s[l]-u,v),0),e.arrowElement=i,e.offsets.arrow=(n={},ae(n,m,Q(v)),ae(n,h,''),n),e},element:'[x-arrow]'},flip:{order:600,enabled:!0,fn:function(e,t){if(W(e.instance.modifiers,'inner'))return e;if(e.flipped&&e.placement===e.originalPlacement)return e;var o=v(e.instance.popper,e.instance.reference,t.padding,t.boundariesElement,e.positionFixed),n=e.placement.split('-')[0],i=T(n),r=e.placement.split('-')[1]||'',p=[];switch(t.behavior){case he.FLIP:p=[n,i];break;case he.CLOCKWISE:p=z(n);break;case he.COUNTERCLOCKWISE:p=z(n,!0);break;default:p=t.behavior;}return p.forEach(function(s,d){if(n!==s||p.length===d+1)return e;n=e.placement.split('-')[0],i=T(n);var a=e.offsets.popper,l=e.offsets.reference,f=Z,m='left'===n&&f(a.right)>f(l.left)||'right'===n&&f(a.left)<f(l.right)||'top'===n&&f(a.bottom)>f(l.top)||'bottom'===n&&f(a.top)<f(l.bottom),h=f(a.left)<f(o.left),c=f(a.right)>f(o.right),g=f(a.top)<f(o.top),u=f(a.bottom)>f(o.bottom),b='left'===n&&h||'right'===n&&c||'top'===n&&g||'bottom'===n&&u,y=-1!==['top','bottom'].indexOf(n),w=!!t.flipVariations&&(y&&'start'===r&&h||y&&'end'===r&&c||!y&&'start'===r&&g||!y&&'end'===r&&u);(m||b||w)&&(e.flipped=!0,(m||b)&&(n=p[d+1]),w&&(r=G(r)),e.placement=n+(r?'-'+r:''),e.offsets.popper=le({},e.offsets.popper,C(e.instance.popper,e.offsets.reference,e.placement)),e=P(e.instance.modifiers,e,'flip'))}),e},behavior:'flip',padding:5,boundariesElement:'viewport'},inner:{order:700,enabled:!1,fn:function(e){var t=e.placement,o=t.split('-')[0],n=e.offsets,i=n.popper,r=n.reference,p=-1!==['left','right'].indexOf(o),s=-1===['top','left'].indexOf(o);return i[p?'left':'top']=r[o]-(s?i[p?'width':'height']:0),e.placement=T(t),e.offsets.popper=g(i),e}},hide:{order:800,enabled:!0,fn:function(e){if(!q(e.instance.modifiers,'hide','preventOverflow'))return e;var t=e.offsets.reference,o=D(e.instance.modifiers,function(e){return'preventOverflow'===e.name}).boundaries;if(t.bottom<o.top||t.left>o.right||t.top>o.bottom||t.right<o.left){if(!0===e.hide)return e;e.hide=!0,e.attributes['x-out-of-boundaries']=''}else{if(!1===e.hide)return e;e.hide=!1,e.attributes['x-out-of-boundaries']=!1}return e}},computeStyle:{order:850,enabled:!0,fn:function(e,t){var o=t.x,n=t.y,i=e.offsets.popper,r=D(e.instance.modifiers,function(e){return'applyStyle'===e.name}).gpuAcceleration;void 0!==r&&console.warn('WARNING: `gpuAcceleration` option moved to `computeStyle` modifier and will not be supported in future versions of Popper.js!');var s,d,a=void 0===r?t.gpuAcceleration:r,l=p(e.instance.popper),f=u(l),m={position:i.position},h={left:Z(i.left),top:Q(i.top),bottom:Q(i.bottom),right:Z(i.right)},c='bottom'===o?'top':'bottom',g='right'===n?'left':'right',b=B('transform');if(d='bottom'==c?-f.height+h.bottom:h.top,s='right'==g?-f.width+h.right:h.left,a&&b)m[b]='translate3d('+s+'px, '+d+'px, 0)',m[c]=0,m[g]=0,m.willChange='transform';else{var y='bottom'==c?-1:1,w='right'==g?-1:1;m[c]=d*y,m[g]=s*w,m.willChange=c+', '+g}var E={"x-placement":e.placement};return e.attributes=le({},E,e.attributes),e.styles=le({},m,e.styles),e.arrowStyles=le({},e.offsets.arrow,e.arrowStyles),e},gpuAcceleration:!0,x:'bottom',y:'right'},applyStyle:{order:900,enabled:!0,fn:function(e){return j(e.instance.popper,e.styles),K(e.instance.popper,e.attributes),e.arrowElement&&Object.keys(e.arrowStyles).length&&j(e.arrowElement,e.arrowStyles),e},onLoad:function(e,t,o,n,i){var r=L(i,t,e,o.positionFixed),p=O(o.placement,r,t,e,o.modifiers.flip.boundariesElement,o.modifiers.flip.padding);return t.setAttribute('x-placement',p),j(t,{position:o.positionFixed?'fixed':'absolute'}),o},gpuAcceleration:void 0}}},ce}); //# sourceMappingURL=popper.min.js.map </ins>


- wget - "-O" - "/work-dir/index.html" <del> - http://kubernetes.io </del> <ins> - http://info.cern.ch </ins> volumeMounts: - name: workdir mountPath: "/work-dir"


See [Add ImagePullSecrets to a service account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) for a detailed explanation of that process. <del> ### Automatic mounting of manually created Secrets Manually created secrets (for example, one containing a token for accessing a GitHub account) can be automatically attached to pods based on their service account. </del> ## Details ### Restrictions


<ins> --- title: SIG Docsへの参加 content_type: concept weight: 60 card: name: contribute weight: 60 --- <!-- overview --> SIG Docsは、Kubernetesプロジェクト内の [special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md)の1つであり、 Kubernetes全体のドキュメントの作成、更新、および保守に重点を置いています。 SIGの詳細については、[SIG DocsのGithubリポジトリ](https://github.com/kubernetes/community/blob/master/sig-list.md)を参照してください。 SIG Docsは、すべての寄稿者からのコンテンツとレビューを歓迎します。 誰でもPull Request(PR)を開くことができ、コンテンツに関するissueを提出したり、進行中のPull Requestにコメントしたりできます。 あなたは、[member](/docs/contribute/participate/roles-and-responsibilities/#members)や、 [reviewer](/docs/contribute/participate/roles-and-responsibilities/#reviewers)、 [approver](/docs/contribute/participate/roles-and-responsibilities/#approvers)になることもできます。 これらの役割にはより多くのアクセスが必要であり、変更を承認およびコミットするための特定の責任が伴います。 Kubernetesコミュニティ内でメンバーシップがどのように機能するかについての詳細は、 [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) をご覧ください。 このドキュメントの残りの部分では、kubernetesの中で最も広く公開されている Kubernetesのウェブサイトとドキュメントの管理を担当しているSIG Docsの中で、これらの役割がどのように機能するのかを概説します。 <!-- body --> ## SIG Docs chairperson SIG Docsを含む各SIGは、議長として機能する1人以上のSIGメンバーを選択します。 これらは、SIGDocsとKubernetes organizationの他の部分との連絡先です。 それらには、Kubernetesプロジェクト全体の構造と、SIG Docsがその中でどのように機能するかについての広範な知識が必要です。 現在のchairpersonのリストについては、 [Leadership](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) を参照してください。 ## SIG Docs teamsと自動化 SIG Docsの自動化は、GitHub teamsとOWNERSファイルの2つの異なるメカニズムに依存しています。 ### GitHub teams GitHubには、二つのSIG Docs [teams](https://github.com/orgs/kubernetes/teams?query=sig-docs) カテゴリがあります: - `@sig-docs-{language}-owners`は承認者かつリードです。 - `@sig-docs-{language}-reviewers` はレビュアーです。 それぞれをGitHubコメントの`@name`で参照して、そのグループの全員とコミュニケーションできます。 ProwチームとGitHub teamsが完全に一致せずに重複する場合があります。 問題の割り当て、Pull Request、およびPR承認のサポートのために、自動化ではOWNERSファイルからの情報を使用します。 ### OWNERSファイルとfront-matter Kubernetesプロジェクトは、GitHubのissueとPull Requestに関連する自動化のためにprowと呼ばれる自動化ツールを使用します。 [Kubernetes Webサイトリポジトリ](https://github.com/kubernetes/website) は、2つの[prowプラグイン](https://github.com/kubernetes/test-infra/tree/master/prow/plugins)を使用します： - blunderbuss - approve これらの2つのプラグインは`kubernetes.website`のGithubリポジトリのトップレベルにある [OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS)ファイルと、 [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES)ファイルを使用して、 リポジトリ内でのprowの動作を制御します。 OWNERSファイルには、SIG Docsのレビュー担当者および承認者であるユーザーのリストが含まれています。 OWNERSファイルはサブディレクトリに存在することもでき、そのサブディレクトリとその子孫のファイルのレビュー担当者または承認者として機能できるユーザーを上書きできます。 一般的なOWNERSファイルの詳細については、 [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md)を参照してください。 さらに、個々のMarkdownファイルは、個々のGitHubユーザー名またはGitHubグループを一覧表示することにより、そのfront-matterでレビュー担当者と承認者を一覧表示できます。 OWNERSファイルとMarkdownファイルのfront-matterの組み合わせにより、PRの技術的および編集上のレビューを誰に依頼するかについてPRの所有者が自動化システムから得るアドバイスが決まります。 ## マージの仕組み Pull Requestがコンテンツの公開に使用されるブランチにマージされると、そのコンテンツは http://kubernetes.io に公開されます。 公開されたコンテンツの品質を高くするために、Pull RequestのマージはSIG Docsの承認者に限定しています。仕組みは次のとおりです。 - Pull Requestに`lgtm`ラベルと`approve`ラベルの両方があり、`hold`ラベルがなく、すべてのテストに合格すると、Pull Requestは自動的にマージされます。 - Kubernetes organizationのメンバーとSIG Docsの承認者はコメントを追加して、特定のPull Requestが自動的にマージされないようにすることができます(`/hold`コメントを追加するか、`/lgtm`コメントを保留します)。 - Kubernetesメンバーは誰でも、`/lgtm`コメントを追加することで`lgtm`ラベルを追加できます。 - `/approve`コメントを追加してPull Requestをマージできるのは、SIG Docsの承認者だけです。一部の承認者は、[PR Wrangler](/docs/contribute/participate/pr-wranglers/)や[SIG Docsのchairperson](#sig-docs-chairperson)など、追加の特定の役割も実行します。 ## {{% heading "whatsnext" %}} Kubernetesドキュメントへの貢献の詳細については、以下を参照してください： - [Contributing new content](/docs/contribute/new-content/overview/) - [Reviewing content](/docs/contribute/review/reviewing-prs) - [ドキュメントスタイルの概要](/ja/docs/contribute/style/) </ins>


title: "弃用 Dockershim 的常见问题" date: 2020-12-02 slug: dockershim-faq <del> aliases: [ '/dockershim' ] </del> --- <!-- layout: blog


--- title: Kubernetes 问题追踪 weight: 10 <del> aliases: [cve/,cves/] </del> --- <!--


--- title: Kubernetes 安全和信息披露 <del> aliases: [security/] </del> content_type: concept weight: 20 ---


### rbd `rbd` 볼륨을 사용하면 <del> [Rados Block Device](https://ceph.com/docs/master/rbd/rbd/)(RBD) 볼륨을 파드에 마운트할 수 </del> <ins> [Rados Block Device](https://docs.ceph.com/en/latest/rbd/)(RBD) 볼륨을 파드에 마운트할 수 </ins> 있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 다르게 `rbd` 볼륨의 내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는 RBD 볼륨에 데이터를 미리 채울 수 있으며, 데이터를


Area of Concern for Workload Security | Recommendation | ------------------------------ | --------------------- | RBAC Authorization (Access to the Kubernetes API) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/ <del> Authentication | https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/ </del> <ins> Authentication | https://kubernetes.io/docs/concepts/security/controlling-access/ </ins> Application secrets management (and encrypting them in etcd at rest) | https://kubernetes.io/docs/concepts/configuration/secret/ <br> https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ Pod Security Policies | https://kubernetes.io/docs/concepts/policy/pod-security-policy/ Quality of Service (and Cluster resource management) | https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/


容易受到资源枯竭的攻击，则如果你不限制服务 B 的资源的话，损害服务 A 的风险就会很高。 下表列出了安全性关注的领域和建议，用以保护 Kubernetes 中运行的工作负载： <del> 工作负载安全性关注领域 |  建议 | </del> <ins> 工作负载安全性关注领域         |  建议                 | </ins> ------------------------------ | --------------------- | RBAC 授权(访问 Kubernetes API) | https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/ <del> 认证方式 | https://kubernetes.io/zh/docs/reference/access-authn-authz/controlling-access/ </del> <ins> 认证方式 | https://kubernetes.io/zh/docs/concepts/security/controlling-access/ </ins> 应用程序 Secret 管理 (并在 etcd 中对其进行静态数据加密) | https://kubernetes.io/zh/docs/concepts/configuration/secret/ <br> https://kubernetes.io/zh/docs/tasks/administer-cluster/encrypt-data/ Pod 安全策略 | https://kubernetes.io/zh/docs/concepts/policy/pod-security-policy/ 服务质量（和集群资源管理）| https://kubernetes.io/zh/docs/tasks/configure-pod-container/quality-service-pod/


Container Vulnerability Scanning and OS Dependency Security | As part of an image build step, you should scan your containers for known vulnerabilities. Image Signing and Enforcement | Sign container images to maintain a system of trust for the content of your containers. Disallow privileged users | When constructing containers, consult your documentation for how to create users inside of the containers that have the least level of operating system privilege necessary in order to carry out the goal of the container. <ins> Use container runtime with stronger isolation | Select [container runtime classes](/docs/concepts/containers/runtime-class/) that provider stronger isolation </ins> --> ## 容器


容器漏洞扫描和操作系统依赖安全性 | 作为镜像构建的一部分，您应该扫描您的容器里的已知漏洞。 镜像签名和执行 | 对容器镜像进行签名，以维护对容器内容的信任。 禁止特权用户 | 构建容器时，请查阅文档以了解如何在具有最低操作系统特权级别的容器内部创建用户，以实现容器的目标。 <ins> 使用带有较强隔离能力的容器运行时 | 选择提供较强隔离能力的[容器运行时类](/zh/docs/concepts/containers/runtime-class/)。 </ins> <!-- ## Code


* [Data encryption in transit](/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane * [Data encryption at rest](/docs/tasks/administer-cluster/encrypt-data/) * [Secrets in Kubernetes](/docs/concepts/configuration/secret/) <ins> * [Runtime class](/docs/concepts/containers/runtime-class) </ins> --> 学习了解相关的 Kubernetes 安全主题：


* 为控制面[加密通信中的数据](/zh/docs/tasks/tls/managing-tls-in-a-cluster/) * [加密静止状态的数据](/zh/docs/tasks/administer-cluster/encrypt-data/) * [Kubernetes 中的 Secret](/zh/docs/concepts/configuration/secret/) <ins> * [运行时类](/zh/docs/concepts/containers/runtime-class) </ins>


<!-- overview --> This page explains how to upgrade a Kubernetes cluster created with kubeadm from version <del> {{< skew latestVersionAddMinor -1 >}}.x to version {{< skew latestVersion >}}.x, and from version {{< skew latestVersion >}}.x to {{< skew latestVersion >}}.y (where `y > x`). Skipping MINOR versions </del> <ins> {{< skew currentVersionAddMinor -1 >}}.x to version {{< skew currentVersion >}}.x, and from version {{< skew currentVersion >}}.x to {{< skew currentVersion >}}.y (where `y > x`). Skipping MINOR versions </ins> when upgrading is unsupported. To see information about upgrading clusters created using older versions of kubeadm, please refer to following pages instead: <del> - [Upgrading a kubeadm cluster from {{< skew latestVersionAddMinor -2 >}} to {{< skew latestVersionAddMinor -1 >}}](https://v{{< skew latestVersionAddMinor -1 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) - [Upgrading a kubeadm cluster from {{< skew latestVersionAddMinor -3 >}} to {{< skew latestVersionAddMinor -2 >}}](https://v{{< skew latestVersionAddMinor -2 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) - [Upgrading a kubeadm cluster from {{< skew latestVersionAddMinor -4 >}} to {{< skew latestVersionAddMinor -3 >}}](https://v{{< skew latestVersionAddMinor -3 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) - [Upgrading a kubeadm cluster from {{< skew latestVersionAddMinor -5 >}} to {{< skew latestVersionAddMinor -4 >}}](https://v{{< skew latestVersionAddMinor -4 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) </del> <ins> - [Upgrading a kubeadm cluster from {{< skew currentVersionAddMinor -2 >}} to {{< skew currentVersionAddMinor -1 >}}](https://v{{< skew currentVersionAddMinor -1 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) - [Upgrading a kubeadm cluster from {{< skew currentVersionAddMinor -3 >}} to {{< skew currentVersionAddMinor -2 >}}](https://v{{< skew currentVersionAddMinor -2 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) - [Upgrading a kubeadm cluster from {{< skew currentVersionAddMinor -4 >}} to {{< skew currentVersionAddMinor -3 >}}](https://v{{< skew currentVersionAddMinor -3 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) - [Upgrading a kubeadm cluster from {{< skew currentVersionAddMinor -5 >}} to {{< skew currentVersionAddMinor -4 >}}](https://v{{< skew currentVersionAddMinor -4 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) </ins> The upgrade workflow at high level is the following:


## Determine which version to upgrade to <del> Find the latest stable {{< skew latestVersion >}} version using the OS package manager: </del> <ins> Find the latest stable {{< skew currentVersion >}} version using the OS package manager: </ins> {{< tabs name="k8s_install_versions" >}} {{% tab name="Ubuntu, Debian or HypriotOS" %}} apt update apt-cache madison kubeadm <del> # find the latest {{< skew latestVersion >}} version in the list # it should look like {{< skew latestVersion >}}.x-00, where x is the latest patch </del> <ins> # find the latest {{< skew currentVersion >}} version in the list # it should look like {{< skew currentVersion >}}.x-00, where x is the latest patch </ins> {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} yum list --showduplicates kubeadm --disableexcludes=kubernetes <del> # find the latest {{< skew latestVersion >}} version in the list # it should look like {{< skew latestVersion >}}.x-0, where x is the latest patch </del> <ins> # find the latest {{< skew currentVersion >}} version in the list # it should look like {{< skew currentVersion >}}.x-0, where x is the latest patch </ins> {{% /tab %}} {{< /tabs >}}


{{< tabs name="k8s_install_kubeadm_first_cp" >}} {{% tab name="Ubuntu, Debian or HypriotOS" %}} <del> # replace x in {{< skew latestVersion >}}.x-00 with the latest patch version </del> <ins> # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version </ins> apt-mark unhold kubeadm &&  <del> apt-get update && apt-get install -y kubeadm={{< skew latestVersion >}}.x-00 &&  </del> <ins> apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 &&  </ins> apt-mark hold kubeadm - # since apt-get version 1.1 you can also use the following method apt-get update &&  <del> apt-get install -y --allow-change-held-packages kubeadm={{< skew latestVersion >}}.x-00 </del> <ins> apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00 </ins> {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} <del> # replace x in {{< skew latestVersion >}}.x-0 with the latest patch version yum install -y kubeadm-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes </del> <ins> # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes </ins> {{% /tab %}} {{< /tabs >}}


```shell # replace x with the patch version you picked for this upgrade <del> sudo kubeadm upgrade apply v{{< skew latestVersion >}}.x </del> <ins> sudo kubeadm upgrade apply v{{< skew currentVersion >}}.x </ins> ``` Once the command finishes you should see: ``` <del> [upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew latestVersion >}}.x". Enjoy! </del> <ins> [upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew currentVersion >}}.x". Enjoy! </ins> [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so. ```


{{< tabs name="k8s_install_kubelet" >}} {{< tab name="Ubuntu, Debian or HypriotOS" >}} <pre> <del> # replace x in {{< skew latestVersion >}}.x-00 with the latest patch version </del> <ins> # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version </ins> apt-mark unhold kubelet kubectl &&  <del> apt-get update && apt-get install -y kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 &&  </del> <ins> apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 &&  </ins> apt-mark hold kubelet kubectl - # since apt-get version 1.1 you can also use the following method apt-get update &&  <del> apt-get install -y --allow-change-held-packages kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 </del> <ins> apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 </ins> </pre> {{< /tab >}} {{< tab name="CentOS, RHEL or Fedora" >}} <pre> <del> # replace x in {{< skew latestVersion >}}.x-0 with the latest patch version yum install -y kubelet-{{< skew latestVersion >}}.x-0 kubectl-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes </del> <ins> # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes </ins> </pre> {{< /tab >}} {{< /tabs >}}


{{< tabs name="k8s_install_kubeadm_worker_nodes" >}} {{% tab name="Ubuntu, Debian or HypriotOS" %}} <del> # replace x in {{< skew latestVersion >}}.x-00 with the latest patch version </del> <ins> # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version </ins> apt-mark unhold kubeadm &&  <del> apt-get update && apt-get install -y kubeadm={{< skew latestVersion >}}.x-00 &&  </del> <ins> apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 &&  </ins> apt-mark hold kubeadm - # since apt-get version 1.1 you can also use the following method apt-get update &&  <del> apt-get install -y --allow-change-held-packages kubeadm={{< skew latestVersion >}}.x-00 </del> <ins> apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00 </ins> {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} <del> # replace x in {{< skew latestVersion >}}.x-0 with the latest patch version yum install -y kubeadm-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes </del> <ins> # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes </ins> {{% /tab %}} {{< /tabs >}}


{{< tabs name="k8s_kubelet_and_kubectl" >}} {{% tab name="Ubuntu, Debian or HypriotOS" %}} <del> # replace x in {{< skew latestVersion >}}.x-00 with the latest patch version </del> <ins> # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version </ins> apt-mark unhold kubelet kubectl &&  <del> apt-get update && apt-get install -y kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 &&  </del> <ins> apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 &&  </ins> apt-mark hold kubelet kubectl - # since apt-get version 1.1 you can also use the following method apt-get update &&  <del> apt-get install -y --allow-change-held-packages kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 </del> <ins> apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 </ins> {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} <del> # replace x in {{< skew latestVersion >}}.x-0 with the latest patch version yum install -y kubelet-{{< skew latestVersion >}}.x-0 kubectl-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes </del> <ins> # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes </ins> {{% /tab %}} {{< /tabs >}}


{{- $latestVersionAddMinor = printf "%s%s%d" (index $versionArray 0) $seperator $latestVersionAddMinor -}} {{- $latestVersionAddMinor -}} {{- end -}} <ins> {{- $currentVersion := site.Params.version -}} {{- $currentVersion := (replace $currentVersion "v" "") -}} {{- $currentVersionArray := split $currentVersion "." -}} {{- $currentMinorVersion := int (index $currentVersionArray 1) -}} <!-- output latestVersion based on captured arg --> {{- if eq $version "currentVersion" -}} {{- $currentVersion -}} {{- end -}} <!-- output currentVersionAddMinor based on captured args --> {{- if eq $version "currentVersionAddMinor" -}} {{- $seperator := .Get 2 -}} {{- if eq $seperator "" -}} {{- $seperator = "." -}} {{- end -}} {{- $currentVersionAddMinor := int (.Get 1) -}} {{- $currentVersionAddMinor = add $currentMinorVersion $currentVersionAddMinor -}} {{- $currentVersionAddMinor = printf "%s%s%d" (index $versionArray 0) $seperator $currentVersionAddMinor -}} {{- $currentVersionAddMinor -}} {{- end -}} </ins> <!-- example shortcode use: - skew nextMinorVersion - skew latestVersion <ins> - skew currentVersion </ins> - skew prevMinorVersion - skew oldestMinorVersion - skew latestVersionAddMinor -1 "-" <ins> - skew currentVersionAddMinor -1 "-" </ins> -->  No newline at end of file


A longstanding bug regarding exec probe timeouts that may impact existing pod definitions has been fixed. Prior to this fix, the field `timeoutSeconds` was not respected for exec probes. Instead, probes would run indefinitely, even past their configured deadline, until a result was returned. With this change, the default value of `1 second` will be applied if a value is not specified and existing pod definitions may no longer be sufficient if a probe takes longer than one second. A feature gate, called `ExecProbeTimeout`, has been added with this fix that enables cluster operators to revert to the previous behavior, but this will be locked and removed in subsequent releases. In order to revert to the previous behavior, cluster operators should set this feature gate to `false`. <del> Please review the updated documentation regarding [configuring probes](docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes) for more details. </del> <ins> Please review the updated documentation regarding [configuring probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes) for more details. </ins> ## Other Updates


{{< note >}} To be able to create Indexed Jobs, make sure to enable the `IndexedJob` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) <del> on the [API server](docs/reference/command-line-tools-reference/kube-apiserver/) </del> <ins> on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/) </ins> and the [controller manager](/docs/reference/command-line-tools-reference/kube-controller-manager/). {{< /note >}}


{{< note >}} Suspending Jobs is available in Kubernetes versions 1.21 and above. You must enable the `SuspendJob` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) <del> on the [API server](docs/reference/command-line-tools-reference/kube-apiserver/) </del> <ins> on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/) </ins> and the [controller manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) in order to use this feature. {{< /note >}}


### Migrating to the `systemd` driver in kubeadm managed clusters <del> Follow this [Migration guide](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver) </del> <ins> Follow this [Migration guide](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/) </ins> if you wish to migrate to the `systemd` cgroup driver in existing kubeadm managed clusters. ## Container runtimes


Refer to the following table for Windows operating system support in Kubernetes. A single heterogeneous Kubernetes cluster can have both Windows and Linux worker nodes. Windows containers have to be scheduled on Windows nodes and Linux containers on Linux nodes. | Kubernetes version | Windows Server LTSC releases | Windows Server SAC releases | <del> | --- | --- | --- | --- | </del> <ins> | --- | --- | --- | </ins> | *Kubernetes v1.17* | Windows Server 2019 | Windows Server ver 1809 | | *Kubernetes v1.18* | Windows Server 2019 | Windows Server ver 1809, Windows Server ver 1903, Windows Server ver 1909 | | *Kubernetes v1.19* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 |


## Enable Topology Aware Hints To enable service topology hints, enable the `TopologyAwareHints` [feature <del> gate](docs/reference/command-line-tools-reference/feature-gates/) for the </del> <ins> gate](/docs/reference/command-line-tools-reference/feature-gates/) for the </ins> kube-apiserver, kube-controller-manager, and kube-proxy: ```


{{< note >}} Kubeadm uses the same `KubeletConfiguration` for all nodes in the cluster. <del> The `KubeletConfiguration` is stored in a [ConfigMap](docs/concepts/configuration/configmap) </del> <ins> The `KubeletConfiguration` is stored in a [ConfigMap](/docs/concepts/configuration/configmap) </ins> object under the `kube-system` namespace. Executing the sub commands `init`, `join` and `upgrade` would result in kubeadm


To be able to create Indexed Jobs, make sure to enable the `IndexedJob` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) <del> on the [API server](docs/reference/command-line-tools-reference/kube-apiserver/) </del> <ins> on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/) </ins> and the [controller manager](/docs/reference/command-line-tools-reference/kube-controller-manager/). <!-- steps -->


## Downloads for v1.21.0 <ins> ### Source Code </ins> filename | sha512 hash -------- | ----------- [kubernetes.tar.gz](https://dl.k8s.io/v1.21.0/kubernetes.tar.gz) | `19bb76a3fa5ce4b9f043b2a3a77c32365ab1fcb902d8dd6678427fb8be8f49f64a5a03dc46aaef9c7dadee05501cf83412eda46f0edacbb8fc1ed0bf5fb79142`


## Changelog since v1.20.0 <del> # Release notes for v1.21.0-rc.0 [Documentation](https://docs.k8s.io/docs/home) # Changelog since v1.20.0 </del> ## What's New (Major Themes) ### Deprecation of PodSecurityPolicy


- sigs.k8s.io/kustomize: v2.0.3+incompatible <del> ## Dependencies ### Added - github.com/go-errors/errors: [v1.0.1](https://github.com/go-errors/errors/tree/v1.0.1) - github.com/gobuffalo/here: [v0.6.0](https://github.com/gobuffalo/here/tree/v0.6.0) - github.com/google/shlex: [e7afc7f](https://github.com/google/shlex/tree/e7afc7f) - github.com/markbates/pkger: [v0.17.1](https://github.com/markbates/pkger/tree/v0.17.1) - github.com/moby/spdystream: [v0.2.0](https://github.com/moby/spdystream/tree/v0.2.0) - github.com/monochromegane/go-gitignore: [205db1a](https://github.com/monochromegane/go-gitignore/tree/205db1a) - github.com/niemeyer/pretty: [a10e7ca](https://github.com/niemeyer/pretty/tree/a10e7ca) - github.com/xlab/treeprint: [a009c39](https://github.com/xlab/treeprint/tree/a009c39) - go.starlark.net: 8dd3e2e - golang.org/x/term: 6a3ed07 - sigs.k8s.io/kustomize/api: v0.8.5 - sigs.k8s.io/kustomize/cmd/config: v0.9.7 - sigs.k8s.io/kustomize/kustomize/v4: v4.0.5 - sigs.k8s.io/kustomize/kyaml: v0.10.15 ### Changed - dmitri.shuralyov.com/gpu/mtl: 666a987 → 28db891 - github.com/Azure/go-autorest/autorest: [v0.11.1 → v0.11.12](https://github.com/Azure/go-autorest/autorest/compare/v0.11.1...v0.11.12) - github.com/NYTimes/gziphandler: [56545f4 → v1.1.1](https://github.com/NYTimes/gziphandler/compare/56545f4...v1.1.1) - github.com/cilium/ebpf: [1c8d4c9 → v0.2.0](https://github.com/cilium/ebpf/compare/1c8d4c9...v0.2.0) - github.com/container-storage-interface/spec: [v1.2.0 → v1.3.0](https://github.com/container-storage-interface/spec/compare/v1.2.0...v1.3.0) - github.com/containerd/console: [v1.0.0 → v1.0.1](https://github.com/containerd/console/compare/v1.0.0...v1.0.1) - github.com/containerd/containerd: [v1.4.1 → v1.4.4](https://github.com/containerd/containerd/compare/v1.4.1...v1.4.4) - github.com/coredns/corefile-migration: [v1.0.10 → v1.0.11](https://github.com/coredns/corefile-migration/compare/v1.0.10...v1.0.11) - github.com/creack/pty: [v1.1.7 → v1.1.11](https://github.com/creack/pty/compare/v1.1.7...v1.1.11) - github.com/docker/docker: [bd33bbf → v20.10.2+incompatible](https://github.com/docker/docker/compare/bd33bbf...v20.10.2) - github.com/go-logr/logr: [v0.2.0 → v0.4.0](https://github.com/go-logr/logr/compare/v0.2.0...v0.4.0) - github.com/go-openapi/spec: [v0.19.3 → v0.19.5](https://github.com/go-openapi/spec/compare/v0.19.3...v0.19.5) - github.com/go-openapi/strfmt: [v0.19.3 → v0.19.5](https://github.com/go-openapi/strfmt/compare/v0.19.3...v0.19.5) - github.com/go-openapi/validate: [v0.19.5 → v0.19.8](https://github.com/go-openapi/validate/compare/v0.19.5...v0.19.8) - github.com/gogo/protobuf: [v1.3.1 → v1.3.2](https://github.com/gogo/protobuf/compare/v1.3.1...v1.3.2) - github.com/golang/mock: [v1.4.1 → v1.4.4](https://github.com/golang/mock/compare/v1.4.1...v1.4.4) - github.com/google/cadvisor: [v0.38.5 → v0.39.0](https://github.com/google/cadvisor/compare/v0.38.5...v0.39.0) - github.com/heketi/heketi: [c2e2a4a → v10.2.0+incompatible](https://github.com/heketi/heketi/compare/c2e2a4a...v10.2.0) - github.com/kisielk/errcheck: [v1.2.0 → v1.5.0](https://github.com/kisielk/errcheck/compare/v1.2.0...v1.5.0) - github.com/konsorten/go-windows-terminal-sequences: [v1.0.3 → v1.0.2](https://github.com/konsorten/go-windows-terminal-sequences/compare/v1.0.3...v1.0.2) - github.com/kr/text: [v0.1.0 → v0.2.0](https://github.com/kr/text/compare/v0.1.0...v0.2.0) - github.com/mattn/go-runewidth: [v0.0.2 → v0.0.7](https://github.com/mattn/go-runewidth/compare/v0.0.2...v0.0.7) - github.com/miekg/dns: [v1.1.4 → v1.1.35](https://github.com/miekg/dns/compare/v1.1.4...v1.1.35) - github.com/moby/sys/mountinfo: [v0.1.3 → v0.4.0](https://github.com/moby/sys/mountinfo/compare/v0.1.3...v0.4.0) - github.com/moby/term: [672ec06 → df9cb8a](https://github.com/moby/term/compare/672ec06...df9cb8a) - github.com/mrunalp/fileutils: [abd8a0e → v0.5.0](https://github.com/mrunalp/fileutils/compare/abd8a0e...v0.5.0) - github.com/olekukonko/tablewriter: [a0225b3 → v0.0.4](https://github.com/olekukonko/tablewriter/compare/a0225b3...v0.0.4) - github.com/opencontainers/runc: [v1.0.0-rc92 → v1.0.0-rc93](https://github.com/opencontainers/runc/compare/v1.0.0-rc92...v1.0.0-rc93) - github.com/opencontainers/runtime-spec: [4d89ac9 → e6143ca](https://github.com/opencontainers/runtime-spec/compare/4d89ac9...e6143ca) - github.com/opencontainers/selinux: [v1.6.0 → v1.8.0](https://github.com/opencontainers/selinux/compare/v1.6.0...v1.8.0) - github.com/sergi/go-diff: [v1.0.0 → v1.1.0](https://github.com/sergi/go-diff/compare/v1.0.0...v1.1.0) - github.com/sirupsen/logrus: [v1.6.0 → v1.7.0](https://github.com/sirupsen/logrus/compare/v1.6.0...v1.7.0) - github.com/syndtr/gocapability: [d983527 → 42c35b4](https://github.com/syndtr/gocapability/compare/d983527...42c35b4) - github.com/willf/bitset: [d5bec33 → v1.1.11](https://github.com/willf/bitset/compare/d5bec33...v1.1.11) - github.com/yuin/goldmark: [v1.1.27 → v1.2.1](https://github.com/yuin/goldmark/compare/v1.1.27...v1.2.1) - golang.org/x/crypto: 7f63de1 → 5ea612d - golang.org/x/exp: 6cc2880 → 85be41e - golang.org/x/mobile: d2bd2a2 → e6ae53a - golang.org/x/mod: v0.3.0 → ce943fd - golang.org/x/net: 69a7880 → 3d97a24 - golang.org/x/sync: cd5d95a → 67f06af - golang.org/x/sys: 5cba982 → a50acf3 - golang.org/x/time: 3af7569 → f8bda1e - golang.org/x/tools: c1934b7 → v0.1.0 - gopkg.in/check.v1: 41f04d3 → 8fa4692 - gopkg.in/yaml.v2: v2.2.8 → v2.4.0 - gotest.tools/v3: v3.0.2 → v3.0.3 - k8s.io/gengo: 83324d8 → b6c5ce2 - k8s.io/klog/v2: v2.4.0 → v2.8.0 - k8s.io/kube-openapi: d219536 → 591a79e - k8s.io/system-validators: v1.2.0 → v1.4.0 - sigs.k8s.io/apiserver-network-proxy/konnectivity-client: v0.0.14 → v0.0.15 - sigs.k8s.io/structured-merge-diff/v4: v4.0.2 → v4.1.0 ### Removed - github.com/codegangsta/negroni: [v1.0.0](https://github.com/codegangsta/negroni/tree/v1.0.0) - github.com/docker/spdystream: [449fdfc](https://github.com/docker/spdystream/tree/449fdfc) - github.com/golangplus/bytes: [45c989f](https://github.com/golangplus/bytes/tree/45c989f) - github.com/golangplus/fmt: [2a5d6d7](https://github.com/golangplus/fmt/tree/2a5d6d7) - github.com/gorilla/context: [v1.1.1](https://github.com/gorilla/context/tree/v1.1.1) - github.com/kr/pty: [v1.1.5](https://github.com/kr/pty/tree/v1.1.5) - rsc.io/quote/v3: v3.1.0 - rsc.io/sampler: v1.3.0 - sigs.k8s.io/kustomize: v2.0.3+incompatible </del> # v1.21.0-rc.0


<ins> --- title: アドオンのインストール content_type: concept --- <!-- overview --> {{% thirdparty-content %}} アドオンはKubernetesの機能を拡張するものです。 このページでは、利用可能なアドオンの一部の一覧と、それぞれのアドオンのインストール方法へのリンクを提供します。 <!-- body --> ## ネットワークとネットワークポリシー * [ACI](https://www.github.com/noironetworks/aci-containers)は、統合されたコンテナネットワークとネットワークセキュリティをCisco ACIを使用して提供します。 * [Antrea](https://antrea.io/)は、L3またはL4で動作して、Open vSwitchをネットワークデータプレーンとして活用する、Kubernetes向けのネットワークとセキュリティサービスを提供します。 * [Calico](https://docs.projectcalico.org/latest/introduction/)はネットワークとネットワークプリシーのプロバイダーです。Calicoは、BGPを使用または未使用の非オーバーレイおよびオーバーレイネットワークを含む、フレキシブルなさまざまなネットワークオプションをサポートします。Calicoはホスト、Pod、そして(IstioとEnvoyを使用している場合には)サービスメッシュ上のアプリケーションに対してネットワークポリシーを強制するために、同一のエンジンを使用します。 * [Canal](https://github.com/tigera/canal/tree/master/k8s-install)はFlannelとCalicoをあわせたもので、ネットワークとネットワークポリシーを提供します。 * [Cilium](https://github.com/cilium/cilium)は、L3のネットワークとネットワークポリシーのプラグインで、HTTP/API/L7のポリシーを透過的に強制できます。ルーティングとoverlay/encapsulationモードの両方をサポートしており、他のCNIプラグイン上で機能できます。 * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)は、KubernetesをCalico、Canal、Flannel、Romana、Weaveなど選択したCNIプラグインをシームレスに接続できるようにするプラグインです。 * [Contiv](https://contiv.github.io)は、さまざまなユースケースと豊富なポリシーフレームワーク向けに設定可能なネットワーク(BGPを使用したネイティブのL3、vxlanを使用したオーバーレイ、古典的なL2、Cisco-SDN/ACI)を提供します。Contivプロジェクトは完全に[オープンソース](https://github.com/contiv)です。[インストーラ](https://github.com/contiv/install)はkubeadmとkubeadm以外の両方をベースとしたインストールオプションがあります。 * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)は、[Tungsten Fabric](https://tungsten.io)をベースにしている、オープンソースでマルチクラウドに対応したネットワーク仮想化およびポリシー管理プラットフォームです。ContrailおよびTungsten Fabricは、Kubernetes、OpenShift、OpenStack、Mesosなどのオーケストレーションシステムと統合されており、仮想マシン、コンテナ/Pod、ベアメタルのワークロードに隔離モードを提供します。 * [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md)は、Kubernetesで使用できるオーバーレイネットワークプロバイダーです。 * [Knitter](https://github.com/ZTE/Knitter/)は、1つのKubernetes Podで複数のネットワークインターフェイスをサポートするためのプラグインです。 * [Multus](https://github.com/Intel-Corp/multus-cni)は、すべてのCNIプラグイン(たとえば、Calico、Cilium、Contiv、Flannel)に加えて、SRIOV、DPDK、OVS-DPDK、VPPをベースとするKubernetes上のワークロードをサポートする、複数のネットワークサポートのためのマルチプラグインです。 * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/)は、Open vSwitch(OVS)プロジェクトから生まれた仮想ネットワーク実装である[OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/)をベースとする、Kubernetesのためのネットワークプロバイダです。OVN-Kubernetesは、OVSベースのロードバランサーおよびネットワークポリシーの実装を含む、Kubernetes向けのオーバーレイベースのネットワーク実装を提供します。 * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)は、クラウドネイティブベースのService function chaining(SFC)、Multiple OVNオーバーレイネットワーク、動的なサブネットの作成、動的な仮想ネットワークの作成、VLANプロバイダーネットワーク、Directプロバイダーネットワークを提供し、他のMulti-networkプラグインと付け替え可能なOVNベースのCNIコントローラープラグインです。 * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in(NCP)は、VMware NSX-TとKubernetesなどのコンテナオーケストレーター間のインテグレーションを提供します。また、NSX-Tと、Pivotal Container Service(PKS)とOpenShiftなどのコンテナベースのCaaS/PaaSプラットフォームとのインテグレーションも提供します。 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)は、Kubernetes Podと非Kubernetes環境間で可視化とセキュリティモニタリングを使用してポリシーベースのネットワークを提供するSDNプラットフォームです。 * [Romana](https://romana.io)は、[NetworkPolicy API](/docs/concepts/services-networking/network-policies/)もサポートするPodネットワーク向けのL3のネットワークソリューションです。Kubeadmアドオンのインストールの詳細は[こちら](https://github.com/romana/romana/tree/master/containerize)で確認できます。 * [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/)は、ネットワークパーティションの両面で機能し、外部データベースを必要とせずに、ネットワークとネットワークポリシーを提供します。 ## サービスディスカバリ * [CoreDNS](https://coredns.io)は、フレキシブルで拡張可能なDNSサーバーです。Pod向けのクラスター内DNSとして[インストール](https://github.com/coredns/deployment/tree/master/kubernetes)できます。 ## 可視化と制御 * [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard)はKubernetes向けのダッシュボードを提供するウェブインターフェイスです。 * [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s)は、コンテナ、Pod、Serviceなどをグラフィカルに可視化するツールです。[Weave Cloud account](https://cloud.weave.works/)と組み合わせて使うか、UIを自分でホストして使います。 ## インフラストラクチャ * [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation)は仮想マシンをKubernetes上で実行するためのアドオンです。通常、ベアメタルのクラスタで実行します。 ## レガシーなアドオン いくつかのアドオンは、廃止された[cluster/addons](https://git.k8s.io/kubernetes/cluster/addons)ディレクトリに掲載されています。 よくメンテナンスされたアドオンはここにリンクしてください。PRを歓迎しています。 </ins>


Los objetos básicos de Kubernetes incluyen: <del> * [Pod](/docs/concepts/workloads/pods/pod-overview/) </del> <ins> * [Pod](/es/docs/concepts/workloads/pods/pod/) </ins> * [Service](/docs/concepts/services-networking/service/) * [Volume](/docs/concepts/storage/volumes/) <del> * [Namespace](/docs/concepts/overview/working-with-objects/namespaces/) </del> <ins> * [Namespace](/es/docs/concepts/overview/working-with-objects/namespaces/) </ins> Además, Kubernetes contiene abstracciónes de nivel superior llamadas Controladores. Los Controladores se basan en los objetos básicos y proporcionan funcionalidades adicionales sobre ellos. Incluyen: <del> * [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) * [Deployment](/docs/concepts/workloads/controllers/deployment/) * [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) * [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) * [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) </del> <ins> * [ReplicaSet](/es/docs/concepts/workloads/controllers/replicaset/) * [Deployment](/es/docs/concepts/workloads/controllers/deployment/) * [StatefulSet](/es/docs/concepts/workloads/controllers/statefulset/) * [DaemonSet](/es/docs/concepts/workloads/controllers/daemonset/) * [Job](/es/docs/concepts/workloads/controllers/jobs-run-to-completion/) </ins> ## Plano de Control de Kubernetes


#### Metadatos de los Objectos <del> * [Annotations](/docs/concepts/overview/working-with-objects/annotations/) </del> <ins> * [Annotations](/es/docs/concepts/overview/working-with-objects/annotations/) </ins> ## {{% heading "whatsnext" %}} <del> Si estás interesado en escribir una página sobre conceptos, revisa [Usando Templates de Páginas](/docs/home/contribute/page-templates/) para obtener información sobre el tipo de página conceptos y la plantilla conceptos. </del> <ins> Si quieres empezar a contribuir a la documentación de Kubernetes accede a la página [Empieza a contribuir](/es/docs/contribute/start/). </ins>


| `ProbeTerminationGracePeriod` | `false` | Alpha | 1.21 | | | `ProcMountType` | `false` | Alpha | 1.12 | | | `QOSReserved` | `false` | Alpha | 1.11 | | <del> | `RemainingItemCount` | `false` | Alpha | 1.15 | | </del> <ins> | `RemainingItemCount` | `false` | Alpha | 1.15 | 1.15 | | `RemainingItemCount` | `true` | Beta | 1.16 | | </ins> | `RemoveSelfLink` | `false` | Alpha | 1.16 | 1.19 | | `RemoveSelfLink` | `true` | Beta | 1.20 | | | `RotateKubeletServerCertificate` | `false` | Alpha | 1.7 | 1.11 |


} ``` <del> Note that the `resourceVersion` of the list remains constant across each request, indicating the server is showing us a consistent snapshot of the pods. Pods that are created, updated, or deleted after version `10245` would not be shown unless the user makes a list request without the `continue` token.  This allows clients to break large requests into smaller chunks and then perform a watch operation on the full set without missing any updates. </del> <ins> Note that the `resourceVersion` of the list remains constant across each request, indicating the server is showing us a consistent snapshot of the pods. Pods that are created, updated, or deleted after version `10245` would not be shown unless the user makes a list request without the `continue` token.  This allows clients to break large requests into smaller chunks and then perform a watch operation on the full set without missing any updates. `remainingItemCount` is the number of subsequent items in the list which are not included in this list response. If the list request contained label or field selectors, then the number of remaining items is unknown and the API server does not include a `remainingItemCount` field in its response. If the list is complete (either because it is not chunking or because this is the last chunk), then there are no more remaining items and the API server does not include a `remainingItemCount` field in its response. The intended use of the `remainingItemCount` is estimating the size of a collection. </ins> ## Receiving resources as Tables


<ins> --- title: 启用拓扑感知提示 content_type: task min-kubernetes-server-version: 1.21 --- <!-- --- reviewers: - robscott title: Enabling Topology Aware Hints content_type: task min-kubernetes-server-version: 1.21 --- --> <!-- overview --> {{< feature-state for_k8s_version="v1.21" state="alpha" >}} <!-- _Topology Aware Hints_ enable topology aware routing with topology hints included in {{< glossary_tooltip text="EndpointSlices" term_id="endpoint-slice" >}}. This approach tries to keep traffic close to where it originated from; you might do this to reduce costs, or to improve network performance. --> _拓扑感知提示_ 启用具有拓扑感知能力的路由，其中拓扑感知信息包含在 {{< glossary_tooltip text="EndpointSlices" term_id="endpoint-slice" >}} 中。 此功能尽量将流量限制在它的发起区域附近； 可以降低成本，或者提高网络性能。 ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} <!-- The following prerequisite is needed in order to enable topology aware hints: * Configure the {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} to run in iptables mode or IPVS mode * Ensure that you have not disabled EndpointSlices --> 为了启用拓扑感知提示，先要满足以下先决条件： * 配置 {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} 以 iptables 或 IPVS 模式运行 * 确保未禁用 EndpointSlices <!-- ## Enable Topology Aware Hints --> ## 启动拓扑感知提示 {#enable-topology-aware-hints} <!-- To enable service topology hints, enable the `TopologyAwareHints` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the kube-apiserver, kube-controller-manager, and kube-proxy: --> 要启用服务拓扑感知，请启用 kube-apiserver、kube-controller-manager、和 kube-proxy 的 [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) `TopologyAwareHints`。 ``` --feature-gates="TopologyAwareHints=true" ``` ## {{% heading "whatsnext" %}} <!-- * Read about [Topology Aware Hints](/docs/concepts/services-networking/topology-aware-hints) for Services * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) --> * 参阅面向服务的[拓扑感知提示](/zh/docs/concepts/services-networking/topology-aware-hints) * 参阅[用服务连通应用](/zh/docs/concepts/services-networking/connect-applications-service/) </ins>


/docs/tasks/administer-cluster/quota-memory-cpu-namespace/     /docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/ 301 /docs/tasks/administer-cluster/quota-pod-namespace/     /docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/ 301 /docs/tasks/administer-cluster/reserve-compute-resources/out-of-resource.md     /docs/tasks/administer-cluster/out-of-resource/ 301 <del> /docs/tasks/administer-cluster/out-of-resource/     /docs/concepts/scheduling-eviction/pod-eviction/ 301 </del> <ins> /docs/tasks/administer-cluster/out-of-resource/     /docs/concepts/scheduling-eviction/node-pressure-eviction/ 301 </ins> /docs/tasks/administer-cluster/romana-network-policy/     /docs/tasks/administer-cluster/network-policy-provider/romana-network-policy/ 301 /docs/tasks/administer-cluster/running-cloud-controller.md     /docs/tasks/administer-cluster/running-cloud-controller/ 301 /docs/tasks/administer-cluster/share-configuration/     /docs/tasks/access-application-cluster/configure-access-multiple-clusters/ 301