[zh]Resync tasks files[7]
caodonghui
parent
a63b896950
commit
ef49d66139
|
|
@ -479,7 +479,7 @@ If you add the `lifecycle` section show above to your Pod spec, the Pod will exe
|
|||
|
||||
<!--
|
||||
## 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).
|
||||
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 receive 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 的局限 {#gmsa-limitations}
|
||||
|
||||
|
|
|
|||
|
|
@ -293,8 +293,17 @@ how.nice.to.look=fairlyNice
|
|||
```
|
||||
|
||||
<!--
|
||||
When `kubectl` creates a ConfigMap from inputs that are not ASCII or UTF-8, the tool puts these into the `binaryData` field of the ConfigMap, and not in `data`. Both text and binary data sources can be combined in one ConfigMap.
|
||||
If you want to view the `binaryData` keys (and their values) in a ConfigMap, you can run `kubectl get configmap -o jsonpath='{.binaryData}' <name>`.
|
||||
|
||||
Use the option `--from-env-file` to create a ConfigMap from an env-file, for example:
|
||||
-->
|
||||
当 `kubectl` 基于非 ASCII 或 UTF-8 的输入创建 ConfigMap 时，
|
||||
该工具将这些输入放入 ConfigMap 的 `binaryData` 字段，而不是 `data` 中。
|
||||
同一个 ConfigMap 中可同时包含文本数据和二进制数据源。
|
||||
如果你想查看 ConfigMap 中的 `binaryData` 键（及其值），
|
||||
你可以运行 `kubectl get configmap -o jsonpath='{.binaryData}' <name>`。
|
||||
|
||||
使用 `--from-env-file` 选项从环境文件创建 ConfigMap，例如：
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -190,7 +190,7 @@ then you will see that a token has automatically been created and is referenced
|
|||
|
||||
You may use authorization plugins to [set permissions on service accounts](/docs/reference/access-authn-authz/rbac/#service-account-permissions).
|
||||
|
||||
To use a non-default service account, simply set the `spec.serviceAccountName`
|
||||
To use a non-default service account, set the `spec.serviceAccountName`
|
||||
field of a pod to the name of the service account you wish to use.
|
||||
-->
|
||||
那么你就能看到系统已经自动创建了一个令牌并且被服务账户所引用。
|
||||
|
|
@ -198,7 +198,7 @@ field of a pod to the name of the service account you wish to use.
|
|||
你可以使用授权插件来
|
||||
[设置服务账户的访问许可](/zh/docs/reference/access-authn-authz/rbac/#service-account-permissions)。
|
||||
|
||||
要使用非默认的服务账户，只需简单的将 Pod 的 `spec.serviceAccountName` 字段设置为你想用的服务账户名称。
|
||||
要使用非默认的服务账户，将 Pod 的 `spec.serviceAccountName` 字段设置为你想用的服务账户名称。
|
||||
|
||||
<!--
|
||||
The service account has to exist at the time the pod is created, or it will be rejected.
|
||||
|
|
@ -489,18 +489,15 @@ The application is responsible for reloading the token when it rotates. Periodic
|
|||
-->
|
||||
## 发现服务账号分发者
|
||||
|
||||
{{< feature-state for_k8s_version="v1.20" state="beta" >}}
|
||||
{{< feature-state for_k8s_version="v1.21" state="stable" >}}
|
||||
|
||||
<!--
|
||||
The Service Account Issuer Discovery feature is enabled by enabling the
|
||||
`ServiceAccountIssuerDiscovery` [feature gate](/docs/reference/command-line-tools-reference/feature-gates)
|
||||
and then enabling the Service Account Token Projection feature as described
|
||||
The Service Account Issuer Discovery feature is enabled when the Service Account
|
||||
Token Projection feature is enabled, as described
|
||||
[above](#service-account-token-volume-projection).
|
||||
-->
|
||||
通过启用 `ServiceAccountIssuerDiscovery`
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates)，
|
||||
并按[前文所述](#service-account-token-volume-projection)启用服务账号令牌投射，
|
||||
可以启用发现服务账号分发者（Service Account Issuer Discovery）这一功能特性。
|
||||
当启用服务账号令牌投射时启用发现服务账号分发者（Service Account Issuer Discovery）这一功能特性，
|
||||
如[上文所述](#service-account-token-volume-projection)。
|
||||
|
||||
<!--
|
||||
The issuer URL must comply with the
|
||||
|
|
@ -542,14 +539,15 @@ JSON Web Key Set（JWKS）。
|
|||
这里的 OpenID 提供者配置有时候也被称作 _发现文档（Discovery Document）_。
|
||||
|
||||
<!--
|
||||
When enabled, the cluster is also configured with a default RBAC ClusterRole
|
||||
called `system:service-account-issuer-discovery`. No role bindings are provided
|
||||
Clusters include a default RBAC ClusterRole called
|
||||
`system:service-account-issuer-discovery`. No role bindings are provided
|
||||
by default. Administrators may, for example, choose whether to bind the role to
|
||||
`system:authenticated` or `system:unauthenticated` depending on their security
|
||||
requirements and which external systems they intend to federate with.
|
||||
-->
|
||||
特性被启用时，集群也会配置名为 `system:service-account-issuer-discovery`
|
||||
的默认 RBAC ClusterRole，但默认情况下不提供角色绑定对象。
|
||||
集群包括一个默认的 RBAC ClusterRole，
|
||||
名为 `system:service-account-issuer-discovery`。
|
||||
默认情况下不提供角色绑定对象。
|
||||
举例而言，管理员可以根据其安全性需要以及期望集成的外部系统选择是否将该角色绑定到
|
||||
`system:authenticated` 或 `system:unauthenticated`。
|
||||
|
||||
|
|
|
|||
|
|
@ -109,7 +109,8 @@ kubectl create secret docker-registry regcred \
|
|||
<!--
|
||||
where:
|
||||
|
||||
* `<your-registry-server>` is your Private Docker Registry FQDN. (https://index.docker.io/v1/ for DockerHub)
|
||||
* `<your-registry-server>` is your Private Docker Registry FQDN.
|
||||
Use `https://index.docker.io/v2/` for DockerHub.
|
||||
* `<your-name>` is your Docker username.
|
||||
* `<your-pword>` is your Docker password.
|
||||
* `<your-email>` is your Docker email.
|
||||
|
|
@ -119,7 +120,7 @@ You have successfully set your Docker credentials in the cluster as a Secret cal
|
|||
在这里：
|
||||
|
||||
* `<your-registry-server>` 是你的私有 Docker 仓库全限定域名（FQDN）。
|
||||
(参考 https://index.docker.io/v1/ 中关于 DockerHub 的部分)
|
||||
DockerHub 使用 `https://index.docker.io/v2/`。
|
||||
* `<your-name>` 是你的 Docker 用户名。
|
||||
* `<your-pword>` 是你的 Docker 密码。
|
||||
* `<your-email>` 是你的 Docker 邮箱。
|
||||
|
|
@ -129,7 +130,7 @@ You have successfully set your Docker credentials in the cluster as a Secret cal
|
|||
<!--
|
||||
## Inspecting the Secret `regcred`
|
||||
|
||||
To understand the contents of the `regcred` Secret you just created, start by viewing the Secret in YAML format:
|
||||
To understand the contents of the `regcred` Secret you created, start by viewing the Secret in YAML format:
|
||||
-->
|
||||
## 检查 Secret `regcred`
|
||||
|
||||
|
|
@ -231,7 +232,8 @@ janedoe/jdoe-private:v1
|
|||
|
||||
<!--
|
||||
To pull the image from the private registry, Kubernetes needs credentials.
|
||||
The `imagePullSecrets` field in the configuration file specifies that Kubernetes should get the credentials from a Secret named `regcred`.
|
||||
The `imagePullSecrets` field in the configuration file specifies that
|
||||
Kubernetes should get the credentials from a Secret named `regcred`.
|
||||
|
||||
Create a Pod that uses your Secret, and verify that the Pod is running:
|
||||
-->
|
||||
|
|
|
|||
Loading…
Reference in New Issue