[zh-cn] sync task files of task-3 (#40052)
* [zh-cn] sync task files of task-3 [zh-cn] sync task files of task-3 * [zh-cn] sync task files of task-3pull/40154/head
kinzhi
GitHub
parent
8eb8b5b40e
commit
dd0aee9466
|
|
@ -1,12 +1,12 @@
|
|||
---
|
||||
title: 为 Windows Pod 和容器配置 GMSA
|
||||
content_type: task
|
||||
weight: 20
|
||||
weight: 30
|
||||
---
|
||||
<!--
|
||||
title: Configure GMSA for Windows Pods and containers
|
||||
content_type: task
|
||||
weight: 20
|
||||
weight: 30
|
||||
-->
|
||||
<!-- overview -->
|
||||
|
||||
|
|
@ -55,6 +55,7 @@ Next, install the CRD with `kubectl apply -f gmsa-crd.yaml`
|
|||
|
||||
<!--
|
||||
### 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.
|
||||
|
|
@ -79,7 +80,7 @@ Installing the above webhooks and associated objects require the steps below:
|
|||
|
||||
1. Install a secret with the certificate from above.
|
||||
|
||||
1. Create a deployment for the core webhook logic.
|
||||
1. Create a deployment for the core webhook logic.
|
||||
|
||||
1. Create the validating and mutating webhook configurations referring to the deployment.
|
||||
-->
|
||||
|
|
@ -94,7 +95,7 @@ Installing the above webhooks and associated objects require the steps below:
|
|||
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.
|
||||
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)
|
||||
-->
|
||||
|
|
@ -142,7 +143,7 @@ Following are the steps for generating a GMSA credential spec YAML manually in J
|
|||
|
||||
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. 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.
|
||||
-->
|
||||
|
|
@ -258,6 +259,7 @@ rules:
|
|||
|
||||
<!--
|
||||
## 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 凭据规约的服务账号
|
||||
|
|
@ -285,6 +287,7 @@ roleRef:
|
|||
|
||||
<!--
|
||||
## 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 凭据规约引用
|
||||
|
|
@ -380,7 +383,11 @@ As Pod specs with GMSA fields populated (as described above) are applied in a cl
|
|||
1. 容器运行时为每个 Windows 容器配置所指定的 GMSA 凭据规约，这样容器就可以以
|
||||
活动目录中该 GMSA 所代表的身份来执行操作，使用该身份来访问域中的服务。
|
||||
|
||||
## 使用主机名或 FQDN 对网络共享进行身份验证
|
||||
<!--
|
||||
## Authenticating to network shares using hostname or FQDN
|
||||
-->
|
||||
## 使用主机名或 FQDN 对网络共享进行身份验证
|
||||
|
||||
<!--
|
||||
If you are experiencing issues connecting to SMB shares from Pods using hostname or FQDN, but are able to access the shares via their IPv4 address then make sure the following registry key is set on the Windows nodes.
|
||||
-->
|
||||
|
|
@ -512,4 +519,3 @@ If you add the `lifecycle` section show above to your Pod spec, the Pod will exe
|
|||
如果你向你的 Pod 规约中添加如上所示的 `lifecycle` 节，则 Pod 会自动执行所
|
||||
列举的命令来重启 `netlogon` 服务，直到 `nltest.exe /query`
|
||||
命令返回时没有错误信息。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: 配置 Pod 使用投射卷作存储
|
||||
content_type: task
|
||||
weight: 70
|
||||
weight: 100
|
||||
---
|
||||
|
||||
<!--
|
||||
|
|
@ -10,7 +10,7 @@ reviewers:
|
|||
- pmorie
|
||||
title: Configure a Pod to Use a Projected Volume for Storage
|
||||
content_type: task
|
||||
weight: 70
|
||||
weight: 100
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
|
@ -39,9 +39,7 @@ and `serviceAccountToken` volumes can be projected.
|
|||
<!--
|
||||
## Configure a projected volume for a pod
|
||||
|
||||
In this exercise, you create username and password {{< glossary_tooltip text="Secrets" term_id="secret" >}} from local files.
|
||||
You then create a Pod that runs one container, using a [`projected`](/docs/concepts/storage/volumes/#projected) Volume
|
||||
to mount the Secrets into the same shared directory.
|
||||
In this exercise, you create username and password {{< glossary_tooltip text="Secrets" term_id="secret" >}} from local files. You then create a Pod that runs one container, using a [`projected`](/docs/concepts/storage/volumes/#projected) Volume to mount the Secrets into the same shared directory.
|
||||
|
||||
Here is the configuration file for the Pod:
|
||||
-->
|
||||
|
|
@ -121,7 +119,7 @@ Delete the Pod and the Secrets:
|
|||
kubectl delete pod test-projected-volume
|
||||
kubectl delete secret user pass
|
||||
```
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: 为 Pod 配置服务账号
|
||||
content_type: task
|
||||
weight: 90
|
||||
weight: 120
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
|
|
@ -10,7 +10,7 @@ reviewers:
|
|||
- thockin
|
||||
title: Configure Service Accounts for Pods
|
||||
content_type: task
|
||||
weight: 90
|
||||
weight: 120
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
|
@ -134,7 +134,7 @@ automountServiceAccountToken: false
|
|||
...
|
||||
```
|
||||
<!--
|
||||
You can also opt out of automounting API credentials for a particular pod:
|
||||
You can also opt out of automounting API credentials for a particular Pod:
|
||||
-->
|
||||
你也可以选择不给特定 Pod 自动挂载 API 凭据：
|
||||
|
||||
|
|
@ -223,7 +223,7 @@ The output is similar to this:
|
|||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
creationTimestamp: 2015-06-16T00:12:59Z
|
||||
creationTimestamp: 2019-06-16T00:12:34Z
|
||||
name: build-robot
|
||||
namespace: default
|
||||
resourceVersion: "272500"
|
||||
|
|
@ -235,7 +235,7 @@ You can 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, set the `spec.serviceAccountName`
|
||||
field of a pod to the name of the service account you wish to use.
|
||||
field of a Pod to the name of the ServiceAccount you wish to use.
|
||||
-->
|
||||
你可以使用鉴权插件来[设置服务账号的访问许可](/zh-cn/docs/reference/access-authn-authz/rbac/#service-account-permissions)。
|
||||
|
||||
|
|
@ -251,11 +251,11 @@ of a Pod that already exists.
|
|||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The `spec.serviceAccount` field is a deprecated alias for `spec.serviceAccountName`.
|
||||
The `.spec.serviceAccount` field is a deprecated alias for `.spec.serviceAccountName`.
|
||||
If you want to remove the fields from a workload resource, set both fields to empty explicitly
|
||||
on the [pod template](/docs/concepts/workloads/pods#pod-templates).
|
||||
-->
|
||||
`spec.serviceAccount` 字段是 `spec.serviceAccountName` 的已弃用别名。
|
||||
`.spec.serviceAccount` 字段是 `.spec.serviceAccountName` 的已弃用别名。
|
||||
如果要从工作负载资源中删除这些字段，请在
|
||||
[Pod 模板](/zh-cn/docs/concepts/workloads/pods#pod-templates)上将这两个字段显式设置为空。
|
||||
{{< /note >}}
|
||||
|
|
@ -486,6 +486,11 @@ You can achieve the same outcome by editing the object manually:
|
|||
kubectl edit serviceaccount/default
|
||||
```
|
||||
|
||||
<!--
|
||||
The output of the `sa.yaml` file is similar to this:
|
||||
-->
|
||||
`sa.yaml` 文件的输出类似于：
|
||||
|
||||
<!--
|
||||
Your selected text editor will open with a configuration looking something like this:
|
||||
-->
|
||||
|
|
@ -551,7 +556,7 @@ myregistrykey
|
|||
```
|
||||
|
||||
<!--
|
||||
## Service Account Token Volume Projection
|
||||
## ServiceAccount token volume projection
|
||||
-->
|
||||
## 服务账号令牌卷投射 {#service-account-token-volume-projection}
|
||||
|
||||
|
|
@ -619,6 +624,7 @@ command line arguments to `kube-apiserver`:
|
|||
Kubernetes API 服务器当做合法的令牌。如果你指定了 `--service-account-issuer`
|
||||
参数，但沒有設置 `--api-audiences`，则控制面认为此参数的默认值为一个只有一个元素的列表，
|
||||
且该元素为令牌发放者的 URL。
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
|
|
@ -718,14 +724,14 @@ registered or accessible.
|
|||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
When enabled, the Kubernetes API server provides an OpenID Provider
|
||||
When enabled, the Kubernetes API server publishes an OpenID Provider
|
||||
Configuration document via HTTP. The configuration document is published at
|
||||
`/.well-known/openid-configuration`.
|
||||
The OpenID Provider Configuration is sometimes referred to as the _discovery document_.
|
||||
The Kubernetes API server publishes the related
|
||||
JSON Web Key Set (JWKS), also via HTTP, at `/openid/v1/jwks`.
|
||||
-->
|
||||
当此特性被启用时，Kubernetes API 服务器会通过 HTTP 提供一个 OpenID 提供者配置文档。
|
||||
当此特性被启用时，Kubernetes API 服务器会通过 HTTP 发布一个 OpenID 提供者配置文档。
|
||||
该配置文档发布在 `/.well-known/openid-configuration` 路径。
|
||||
这里的 OpenID 提供者配置（OpenID Provider Configuration）有时候也被称作
|
||||
“发现文档（Discovery Document）”。
|
||||
|
|
@ -755,7 +761,7 @@ bind the role to `system:authenticated` or `system:unauthenticated` depending on
|
|||
security requirements and which external systems they intend to federate with.
|
||||
-->
|
||||
使用 {{< glossary_tooltip text="RBAC" term_id="rbac">}} 的集群都包含一个的默认
|
||||
RBAC ClusterRole, 名为 `system:service-account-issuer-discovery`。
|
||||
RBAC ClusterRole, 名为 `system:service-account-issuer-discovery`。
|
||||
默认的 RBAC ClusterRoleBinding 将此角色分配给 `system:serviceaccounts` 组，
|
||||
所有 ServiceAccount 隐式属于该组。这使得集群上运行的 Pod
|
||||
能够通过它们所挂载的服务账号令牌访问服务账号发现文档。
|
||||
|
|
@ -819,4 +825,3 @@ See also:
|
|||
- 关于 OIDC 发现的相关背景信息，阅读[服务账号签署密钥检索 KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/1393-oidc-discovery)
|
||||
这一 Kubernetes 增强提案
|
||||
- 阅读 [OIDC 发现规范](https://openid.net/specs/openid-connect-discovery-1_0.html)
|
||||
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
---
|
||||
title: 从私有仓库拉取镜像
|
||||
content_type: task
|
||||
weight: 100
|
||||
weight: 130
|
||||
---
|
||||
|
||||
<!--
|
||||
title: Pull an Image from a Private Registry
|
||||
content_type: task
|
||||
weight: 100
|
||||
weight: 130
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
---
|
||||
title: 配置 Pod 的服务质量
|
||||
content_type: task
|
||||
weight: 30
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!--
|
||||
title: Configure Quality of Service for Pods
|
||||
content_type: task
|
||||
weight: 30
|
||||
weight: 60
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
|
@ -383,20 +383,6 @@ kubectl --namespace=qos-example get pod qos-demo-4 -o jsonpath='{ .status.qosCla
|
|||
Burstable
|
||||
```
|
||||
|
||||
<!--
|
||||
## Clean up
|
||||
-->
|
||||
## 清理 {#clean-up}
|
||||
|
||||
<!--
|
||||
Delete your Pod:
|
||||
-->
|
||||
删除 Pod：
|
||||
|
||||
```shell
|
||||
kubectl delete pod qos-demo-4 --namespace=qos-example
|
||||
```
|
||||
|
||||
<!--
|
||||
## Clean up
|
||||
|
||||
|
|
@ -428,12 +414,19 @@ kubectl delete namespace qos-example
|
|||
### For cluster administrators
|
||||
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
|
||||
|
||||
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)
|
||||
|
||||
* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
|
||||
|
||||
* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
|
||||
|
||||
* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
|
||||
|
||||
* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
|
||||
|
||||
* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
|
||||
|
||||
* [Control Topology Management policies on a node](/docs/tasks/administer-cluster/topology-manager/)
|
||||
-->
|
||||
### 集群管理员参考
|
||||
|
|
@ -446,4 +439,3 @@ kubectl delete namespace qos-example
|
|||
* [为名字空间配置 Pod 配额](/zh-cn/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
|
||||
* [为 API 对象配置配额](/zh-cn/docs/tasks/administer-cluster/quota-api-object/)
|
||||
* [控制节点上的拓扑管理策略](/zh-cn/docs/tasks/administer-cluster/topology-manager/)
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue