准备 Windows 集群以进行部署

本页介绍了如何准备 Windows 集群以进行部署。

准备工作

选择并设置 Docker 注册表

在部署过程中,您需要构建容器的 Docker 映像并将其上传到 Docker 注册表。

对于 Docker 注册表,您可以选择使用:

  • Artifact Registry

  • 支持基本身份验证的任何 Docker 注册表

建议的解决方案是在部署集群的同一项目中使用 Artifact Registry。默认情况下,GKE 可以访问该注册表。如需了解详情,请参阅与 GKE 集成的要求

如果您想使用私有 Docker 注册表,请了解如何配置注册表

将迁移的工作负载配置为使用 gMSA

Windows IIS 应用工作负载通常加入 Active Directory (AD) 并使用网域身份运行。将这些虚拟机迁移到容器时,容器本身未加入网域,但其主机 Kubernetes 集群节点可以加入网域。

将迁移的容器部署到集群时,您可以使用群组代管式服务账号 (gMSA)。使用 gMSA 在特定服务账号身份下执行容器。您可以在 Pod 集群中将 gMSA 作为 Pod 配置的一部分进行附加,而不是作为容器映像中的静态身份配置附加。

Migrate to Containers 可帮助您实现工作负载转换。 Migrate to Containers 会自动发现 IIS 应用池的配置,并向生成的迁移计划添加建议。然后,您可以评估这些建议,并根据您的具体环境和要求对其进行修改。

如果 Migrate to Containers 确定应用池的配置不需要 gMSA,则会保留原始的应用池配置。例如,当它使用内置账号类型(例如 ApplicationPoolIdentityNetworkServiceLocalSystemLocalService)时。

如需在迁移的 Windows 容器中支持 gMSA,您必须执行以下操作:

  1. 修改迁移计划以设置必要的属性,将迁移的容器配置为使用 gMSA。

  2. 配置用于托管已部署容器的目标集群

配置目标集群以支持 gMSA

您可以在 Pod 集群中将 gMSA 作为 Pod 配置的一部分进行关联,而不是作为容器映像中的静态身份配置关联。

如需配置托管迁移的 Windows 容器的集群以支持 gMSA,您必须执行以下操作:

  1. 配置 Active Directory 以使虚拟机自动加入网域

  2. 为 Windows Pod 和容器配置 gMSA

详情请参阅以下内容:

将 SSL 证书存储为 Kubernetes Secret 时部署容器

我们建议您使用 Cloud Load BalancingIngressCloud Service Mesh 作为 HTTPS 前端来保护对您所部署容器的外部访问。通过此选项,您可以保护外部通信,而无需在集群内包含任何证书。如需了解详情,请参阅自定义迁移计划

您还可以将安全套接层 (SSL) 证书存储为 Kubernetes Secret,并在运行时将其装载到容器中。

如需使用 Kubernetes Secret,请执行以下操作:

  1. 使用证书和密码创建 PFX 文件

  2. 创建用于定义网站访问权限的配置 YAML 文件:

    sites:
     - sitename: "sitename"
       sslport: 443
       pfxpath: c:\sslconfig\pfx
       password: "password"
       thumbprint: "3e858d0551fc0536f52d411dad92b680a4fad4da"

    其中:

    • sitename 指定配置为使用 SSL 的网站的名称。sites 属性可以包含多个 sitename 条目。

    • sslport 指定要监听 SSL 连接的端口(通常为 443)。

    • pfxpath 指定 PFX 文件的路径。将其配置为 pod 部署的 volumeMounts 的一部分。

    • password 指定 PFX 文件的密码。

    • thumbprint 指定 PFX 文件的 SHA-1 指纹,可通过 PowerShell 命令进行检索:

      Get-PfxCertificate -FilePath "path to pfx"

      也可以在 Windows 证书管理器中查看。

  3. 创建 Kubernetes Secret:

    kubectl create secret generic secret-name --from-file=pfx=path-to-pfx --from-file=config=path-to-config
  4. 在映像的部署中创建卷装载和卷装载:

    apiVersion: v1
    kind: Pod
    metadata:
     name: iis-pod
     labels:
       app: iis-server-simple
     spec:
       nodeSelector:
         kubernetes.io/os: windows
       containers:
       - name: iis-server
         image: your-image-url
         volumeMounts:
         - name: ssl-secret
           mountPath: c:\sslconfig
         env:
         - name: M4A_CERT_YAML
           value: c:\sslconfig\config
       volumes:
       - name: ssl-secret
         secret:
           secretName: secret-name

    其中:

    • mountPath 是您在第 2 步中创建的配置文件中由 pfxpath 指定的相同路径。
    • M4A_CERT_YAML 是一个环境变量,指向您在第 2 步中创建的配置 YAML 文件的完整路径。
    • secret-name 是您在第 3 步中创建的 Secret 的名称。

配置 SSL

建议不要将 SSL 证书私钥存储在容器映像中,因为读取该映像的任何人都可以访问这些私钥。Migrate to Containers 提供了几种处理 Windows SSL 的方法。

使用自动生成的自签名证书

默认情况下,系统会为具有 HTTPS 绑定的 Windows 容器分配一个自动生成的自签名证书,该证书会在初始化 Docker 容器时生成。此配置可让您测试已迁移的工作负载,但不能在生产环境中使用。每次运行容器时,证书都会自签名并重新生成。

推荐 - 使用 Cloud Load Balancing、Ingress 或 Cloud Service Mesh

您可以自定义迁移计划中的绑定以使用 HTTP,然后使用 Cloud Load BalancingIngressCloud Service Mesh 作为 HTTPS 前端来保护外部访问权限。通过此选项,您可以保护外部通信,而无需在集群内包含任何证书。

  • 如需自定义绑定关系,请在代表迁移的迁移计划中修改 site 定义,将 protocol 设置为 http

    sites:
      site:
      - applications:
        - path: /
          virtualdirectories:
            - path: /
              physicalpath: '%SystemDrive%\inetpub\wwwroot'
              bindings:
              - port: 8080
                protocol: http
              name: Default Web Site
    

然后,您可以将请求从 HTTPS 前端转发到 Windows 工作负载的 HTTP 路径和端口。

将 SSL 证书存储为 Kubernetes Secret

建议您使用 Cloud Load BalancingIngressCloud Service Mesh 作为 HTTPS 前端来保护外部访问权限。不过,您也可以将 SSL 证书存储为 Kubernetes Secret,并在运行时将其装载到容器中。

如需使用存储为 Kubernetes Secret 的 SSL 证书,您必须修改容器的部署映像。如需了解详情,请参阅将 SSL 证书存储为 Kubernetes Secret 时部署容器

给 Cloud Logging 配置日志记录

Migrate to Containers 使用 LogMonitor 工具从 Windows 容器提取日志并将其转发到您的 GKE 集群。然后,这些日志会自动转发到 Cloud Logging,而 Cloud Logging 提供了一套用于监控容器的工具。

默认情况下,Migrate to Containers 允许 IIS 日志记录监控 IIS 日志,还会将应用或系统事件日志转发到 Cloud Logging

配置日志记录

展开生成的 artifacts.zip 文件会创建若干目录,包括 m4a 目录。该目录包含每张图片的文件夹。 m4a 目录中包含您可修改以控制日志记录的 LogMonitorConfig.json 文件。

如需详细了解如何修改 LogMonitorConfig.json,请参阅编写配置文件

设置 ACL

某些 IIS 应用要求您对文件和文件夹设置特定的访问控制列表 (ACL) 权限,以确保应用正常运行。Migrate to Containers 会自动扫描所有已迁移的 IIS 应用,并添加在来源虚拟机中定义的、适用于 IIS 账号(IUSR 账号和 IIS_IUSRS 组)的特定权限,而且还会将这些权限应用到生成的容器映像中复制的文件和目录。

由于 Windows 容器映像不支持在 Docker COPY 命令中设置 ACL,因此 ACL 是在名为 set_acls.bat 的脚本中设置的。Migrate to Containers 会在特定 Windows 应用的已生成映像的目录中自动创建 set_acls.bat。然后,当您执行 docker build 命令时,Migrate to Containers 会调用 set_acls.bat

修改 set_acls.bat 以添加或移除自定义权限,或修改由于与特定 IIS 用户无关而未被 Migrate to Containers 检测到的权限。

该脚本使用 Windows 内置的 icacls 工具设置权限。

.NET Global Assembly Cache 简介

Migrate to Containers 会扫描源映像 .NET Global Assembly Cache (GAC),以查找在来源机器上安装但未包含在正式映像中的 .NET 资源。任何发现的 DLL 都会被复制到 Docker 上下文中,并通过一个实用程序脚本 install_gac.ps1 作为构建目标映像的一部分进行安装。

所有 .NET 组件都将复制到 m4a\gac 目录下的 Docker 上下文中。如需从映像中移除组件,请从 m4a\gac 目录中删除它们。

COM 对象 DLL 注册

系统会自动扫描和注册公开 COM 对象的 DLL。在提取阶段,系统会扫描复制的文件以查找注册为 COM 对象的 DLL,然后将其注册到容器中。

此过程无需用户输入即可完成。不过,您可以通过添加更多要复制的 DLL 来影响此过程。如果需要,系统将依次检查这些 DLL 并进行注册。

后续步骤