Skip to content

Commit 40d2fdb

Browse files
superleosuperleo
committed
Update content/zh/docs/tasks/configure-pod-container/configure-gmsa.md
1 parent 82fbc21 commit 40d2fdb

File tree

1 file changed

+107
-39
lines changed

1 file changed

+107
-39
lines changed

‎content/zh/docs/tasks/configure-pod-container/configure-gmsa.md

Lines changed: 107 additions & 39 deletions
Original file line numberDiff line numberDiff line change
@@ -381,32 +381,110 @@ As Pod specs with GMSA fields populated (as described above) are applied in a cl
381381
1. 容器运行时为每个 Windows 容器配置所指定的 GMSA 凭据规约，这样容器就可以以
382382
活动目录中该 GMSA 所代表的身份来执行操作，使用该身份来访问域中的服务。
383383

384+
<!--
385+
## Containerd
386+
387+
On Windows Server 2019, in order to use GMSA with containerd, you must be running OS Build 17763.1817 (or later) which can be installed using the patch [KB5000822](https://support.microsoft.com/en-us/topic/march-9-2021-kb5000822-os-build-17763-1817-2eb6197f-e3b1-4f42-ab51-84345e063564).
388+
389+
There is also a known issue with containerd that occurs when trying to connect to SMB shares from Pods. Once you have configured GMSA, the pod will be unable to connect to the share using the hostname or FQDN, but connecting to the share using an IP address works as expected.
390+
-->
391+
## Containerd
392+
在 Windows Server 2019 上对 containerd 使用 GMSA，需要使用 Build 17763.1817（或更新的版本），
393+
你可以安装补丁 [KB5000822](https://support.microsoft.com/en-us/topic/march-9-2021-kb5000822-os-build-17763-1817-2eb6197f-e3b1-4f42-ab51-84345e063564)。
394+
395+
containerd 场景从 Pod 连接 SMB 共享的时候有一个已知问题：
396+
配置了 GMSA 以后，无法通过主机名或者 FQDN 访问 SMB共享，但是通过 IP 地址访问没有问题。
397+
398+
```PowerShell
399+
ping adserver.ad.local
400+
```
401+
402+
<!--
403+
and correctly resolves the hostname to an IPv4 address. The output is similar to:
404+
-->
405+
406+
主机名可以被解析为 IPv4 地址，输出类似如下所示：
407+
408+
```
409+
Pinging adserver.ad.local [192.168.111.18] with 32 bytes of data:
410+
Reply from 192.168.111.18: bytes=32 time=6ms TTL=124
411+
Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
412+
Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
413+
Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
414+
```
415+
416+
<!--
417+
However, when attempting to browse the directory using the hostname
418+
-->
419+
但是，当尝试使用主机名浏览目录时:
420+
421+
```PowerShell
422+
cd \\adserver.ad.local\test
423+
```
424+
425+
<!--
426+
you see an error that implies the target share doesn't exist:
427+
-->
428+
你会看到一个错误，提示目标共享不存在:
429+
430+
```
431+
cd : Cannot find path '\\adserver.ad.local\test' because it does not exist.
432+
At line:1 char:1
433+
+ cd \\adserver.ad.local\test
434+
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
435+
+ CategoryInfo : ObjectNotFound: (\\adserver.ad.local\test:String) [Set-Location], ItemNotFoundException
436+
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.SetLocationCommand
437+
```
438+
439+
<!--
440+
but you notice that the error disappears if you browse to the share using its IPv4 address instead; for example:
441+
-->
442+
但是你会注意到，如果你改为使用其 IPv4 地址浏览共享，错误就会消失；例如：
443+
444+
```PowerShell
445+
cd \\192.168.111.18\test
446+
```
447+
448+
<!--
449+
After you change into a directory within the share, you see a prompt similar to:
450+
-->
451+
切换到共享中的目录后，你会看到类似于以下内容的提示：
452+
453+
```
454+
Microsoft.PowerShell.Core\FileSystem::\\192.168.111.18\test>
455+
```
456+
457+
<!--
458+
To correct the behaviour you must run the following on the node `reg add "HKLM\SYSTEM\CurrentControlSet\Services\hns\State" /v EnableCompartmentNamespace /t REG_DWORD /d 1` to add the required registry key. This node change will only take effect in newly created pods, meaning you must now recreate any running pods which require access to SMB shares.
459+
-->
460+
要解决问题，你需要在节点上运行以下命令以添加所需的注册表项
461+
`reg add "HKLM\SYSTEM\CurrentControlSet\Services\hns\State" /v EnableCompartmentNamespace /t REG_DWORD /d 1`。
462+
此更改只会在新创建的 Pod 中生效，这意味着你必须重新创建任何需要访问 SMB 共享的正在运行的 Pod。
384463
<!--
385464
## Troubleshooting
386465
387466
If you are having difficulties getting GMSA to work in your environment, there are a few troubleshooting steps you can take.
388467
-->
389468
## 故障排查
390469

391-
如果在你的环境中配置 GMSA 时遇到了困难，你可以采取若干步骤来排查可能
392-
的故障。
470+
如果在你的环境中配置 GMSA 时遇到了困难，你可以采取若干步骤来排查可能的故障。
393471

394472
<!--
395-
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:
473+
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.
396474
-->
397-
首先，确保凭据规约已经被传递到 Pod。要实现这点，你需要先通过 `exec` 进入到
398-
你的 Pod 之一，检查 `nltest.exe /parentdomain` 命令的输出。
475+
首先，确保 credspec 已传递给 Pod。为此，你需要先运行 `exec` 进入到你的一个 Pod 中并检查 `nltest.exe /parentdomain` 命令的输出。
399476
在下面的例子中，Pod 未能正确地获得凭据规约：
400477

401-
```shell
478+
```PowerShell
402479
kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe
480+
```
403481

404-
Windows PowerShell
405-
Copyright (C) Microsoft Corporation. All rights reserved.
406-
407-
PS C:\> nltest.exe /parentdomain
482+
<!--
483+
nltest.exe /parentdomain` results in the following error:
484+
-->
485+
`nltest.exe /parentdomain` 导致以下错误：
486+
```
408487
Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
409-
PS C:\>
410488
```
411489

412490
<!--
@@ -434,32 +512,37 @@ If the DNS and communication test passes, next you will need to check if the Pod
434512
安全通信通道。要执行这一检查，你需要再次通过 `exec` 进入到你的 Pod 中
435513
并执行 `nltest.exe /query` 命令。
436514

437-
```shell
438-
PS C:\> nltest.exe /query
439-
I_NetLogonControl failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
515+
```PowerShell
516+
nltest.exe /query
440517
```
441518

442519
<!--
443-
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.
520+
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 following:
444521
-->
445-
这一输出告诉我们，由于某些原因，Pod 无法使用凭据规约中的账号登录到域。
446-
你可以通过运行 `nltest.exe /sc_reset:domain.example` 命令尝试修复安全通道。
522+
这告诉我们，由于某种原因，Pod 无法使用 credspec 中指定的帐户登录到域。
523+
你可以尝试通过运行以下命令来修复安全通道：
447524

448-
```shell
449-
PS C:\> nltest /sc_reset:domain.example
525+
```PowerShell
526+
nltest /sc_reset:domain.example
527+
```
528+
529+
<!--
530+
If the command is successful you will see and output similar to this:
531+
-->
532+
如果命令成功，你将看到类似以下内容的输出：
533+
534+
```
450535
Flags: 30 HAS_IP HAS_TIMESERV
451536
Trusted DC Name \\dc10.domain.example
452537
Trusted DC Connection Status Status = 0 0x0 NERR_Success
453538
The command completed successfully
454-
PS C:\>
455539
```
456540

457541
<!--
458-
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.
542+
If the above 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.
459543
-->
460-
如果上述命令修复了错误，你就可以通过向你的 Pod 规约添加生命周期回调来将此操作
461-
自动化。如果上述命令未能奏效，你就需要再次检查凭据规约，以确保其数据时正确的
462-
而且是完整的。
544+
如果以上命令修复了错误，你可以通过将以下生命周期回调添加到你的 Pod 规约中来自动执行该步骤。
545+
如果这些操作没有修复错误，你将需要再次检查你的 credspec 并确认它是正确和完整的。
463546

464547
```yaml
465548
image: registry.domain.example/iis-auth:1809v1
@@ -477,18 +560,3 @@ If you add the `lifecycle` section show above to your Pod spec, the Pod will exe
477560
列举的命令来重启 `netlogon` 服务，直到 `nltest.exe /query`
478561
命令返回时没有错误信息。
479562

480-
<!--
481-
## GMSA limitations
482-
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).
483-
-->
484-
## GMSA 的局限 {#gmsa-limitations}
485-
486-
在使用 [Windows 版本的 ContainerD 运行时](/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#cri-containerd)
487-
时，通过 GMSA 域身份标识访问受限制的网络共享资源时会出错。
488-
容器会收到身份标识且 `nltest.exe /query` 调用也能正常工作。
489-
当需要访问网络共享资源时，建议使用
490-
[Docker EE 运行时](/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#docker-ee)。
491-
Windows Server 团队正在 Windows 内核中解决这一问题，并在将来发布解决此问题的补丁。
492-
你可以在 [Microsoft Windows Containers 问题跟踪列表](https://github.com/microsoft/Windows-Containers/issues/44)
493-
中查找这类更新。
494-

0 commit comments

Comments
 (0)