部署工作负载

本页面介绍了在 Google Distributed Cloud Connected 硬件上部署工作负载的步骤，以及在配置工作负载时必须遵守的限制。

在完成这些步骤之前，您必须满足 Distributed Cloud Connected 安装要求并订购 Distributed Cloud 硬件。

当 Google Distributed Cloud Connected 硬件到达您选择的目的地时，它已预配置了硬件、 Google Cloud以及您在订购 Distributed Cloud Connected 时指定的一些网络设置。

Google 安装人员会完成物理安装，而您的系统管理员会将 Distributed Cloud Connected 连接到本地网络。

硬件连接到本地网络后，会与 Google Cloud 通信，以下载软件更新并与您的Google Cloud 项目建立连接。然后，您就可以在 Distributed Cloud Connected 上预配节点池和部署工作负载了。

部署概览

如需在 Distributed Cloud 连接的硬件上部署工作负载，请完成以下步骤：

  1. 可选：启用 Distributed Cloud Edge Network API。

  2. 可选：初始化 Distributed Cloud connected 可用区的网络配置。

  3. 可选：配置 Distributed Cloud 网络。

  4. 创建 Distributed Cloud connected 集群。

  5. 可选：如果您想与 Cloud Key Management Service 集成，以支持为工作负载数据使用 CMEK，请为本地存储启用对客户管理的加密密钥 (CMEK) 的支持。如需了解 Distributed Cloud Connected 如何加密工作负载数据，请参阅本地存储安全。

  6. 创建节点池。 在此步骤中，您将节点分配给节点池，并可以选择性地将节点池配置为使用 Cloud KMS 来封装和解封装 Linux 统一密钥设置 (LUKS) 密码，以加密工作负载数据。

  7. 获取集群的凭据以测试集群。

  8. 通过向用户分配项目的 Edge Container Viewer 角色 (roles/edgecontainer.viewer) 或 Edge Container Admin 角色 (roles/edgecontainer.admin)，授予用户对集群的访问权限。

  9. 使用 RoleBinding 和 ClusterRoleBinding 为用户分配对集群资源的基于角色的精细访问权限。

  10. 可选：启用 VM Runtime on Google Distributed Cloud 支持，以便在 Distributed Cloud Connected 上的虚拟机中运行工作负载。

  11. 可选：启用 GPU 支持，以便在 Distributed Cloud Connected 上运行基于 GPU 的工作负载。

将 NGINX 负载均衡器部署为服务

以下示例展示了如何在连接的分布式云集群上部署 NGINX 服务器并将其公开为服务：

  1. 创建一个名为 nginx-deployment.yaml 的 YAML 文件，其中包含以下内容：

    apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
labels:
  app: nginx
spec:
replicas: 1
selector:
  matchLabels:
     app: nginx
template:
  metadata:
     labels:
     app: nginx
  spec:
     containers:
     - name: nginx
     image: nginx:latest
     ports:
     - containerPort: 80

  2. 使用以下命令将 YAML 文件应用到集群：

    kubectl apply -f nginx-deployment.yaml

  3. 创建一个名为 nginx-service.yaml 的 YAML 文件，其中包含以下内容：

    apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
type: LoadBalancer
selector:
  app: nginx
  ports:
     - protocol: TCP
       port: 8080
       targetPort: 80

  4. 使用以下命令将 YAML 文件应用到集群：

    kubectl apply -f nginx-deployment.yaml

  5. 使用以下命令获取 MetalLB 负载平衡器分配给服务的外部 IP 地址：

    kubectl get services

    该命令会返回类似于以下内容的输出：

    NAME            TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)          AGE
nginx-service   LoadBalancer   10.51.195.25   10.100.68.104   8080:31966/TCP   11d

配置 NodeSystemConfigUpdate 资源

为集群中的每个节点配置一个 NodeSystemConfigUpdate 网络功能运算符资源，如下所示。

  1. 使用以下命令列出目标集群的节点池中运行的节点：

    kubectl get nodes | grep -v master

    该命令会返回类似于以下内容的输出：

    NAME                                 STATUS   ROLES       AGE     VERSION
pool-example-node-1-01-b2d82cc7      Ready    <none>      2d      v1.22.8-gke.200
pool-example-node-1-02-52ddvfc9      Ready    <none>      2d      v1.22.8-gke.200

    记录返回的节点名称并推导其短名称。例如，对于 pool-example-node-1-01-b2d82cc7 节点，其简称为 node101。

  2. 对于您在上一步中记录的每个节点，创建一个专用的 NodeSystemConfigUpdate 资源文件，其中包含以下内容：

    apiVersion: networking.gke.io/v1
kind: NodeSystemConfigUpdate
metadata:
name: nodesystemconfigupdate-NODE_SHORT_NAME
namespace: nf-operator
spec:
kubeletConfig:
  cpuManagerPolicy: Static
  topologyManagerPolicy: SingleNumaNode
nodeName: NODE_NAME
osConfig:
  hugePagesConfig:
     ONE_GB: 2
     TWO_MB: 0
  isolatedCpusPerSocket:
     "0": 40
     "1": 40
sysctls:
  nodeLevel:
     net.core.rmem_max: "8388608"
     net.core.wmem_max: "8388608"

    替换以下内容：

    • NODE_NAME：目标节点的完整名称。例如 pool-example-node-1-01-b2d82cc7。
    • NODE_SHORT_NAME：目标节点的简称，从其全名派生而来。例如 node101。

    将每个文件命名为 node-system-config-update-NODE_SHORT_NAME.yaml。

  3. 使用以下命令将每个 NodeSystemConfigUpdate 资源文件应用于集群：

    kubectl apply -f node-system-config-update-NODE_SHORT_NAME.yaml

    将 NODE_SHORT_NAME 替换为相应目标节点的简称。

    将资源应用到集群后，每个受影响的节点都会重新启动，这可能需要长达 30 分钟的时间。

    1. 监控受影响节点的状态，直到所有节点都成功重启：
    kubectl get nodes | grep -v master

    随着每个节点的重新启动完成，其状态会从 not-ready 转换为 ready。

配置用于映像缓存的 Pod

您可以配置在 Distributed Cloud 连接集群上运行的 Pod 来缓存其映像。在首次从代码库拉取映像后，Pod 便开始使用缓存的映像。如果托管 Pod 的节点存储空间用尽，系统不会缓存新映像，并且会清除现有映像缓存，以确保工作负载继续不间断地运行。

您的 Pod 配置必须满足以下前提条件：

  • 您必须在 Pod 上设置 gdce.baremetal.cluster.gke.io/cache-image: true 标签。
  • 如果您使用的是私有映像代码库，则 ImagePullSecret 资源必须为 kubernetes.io/dockerconfigjson 类型。
  • 您必须将 Pod 的拉取政策设置为 IfNotPresent，以确保始终使用目标映像的缓存副本。如果本地没有缓存副本，则从代码库中拉取映像。

以下示例展示了启用缓存的 Pod 配置：

apiVersion: v1
kind: Pod
metadata:
  name: cached-image-pod
  labels:
    gdce.baremetal.cluster.gke.io/cache-image: "true"
spec:
  containers:
    - name: my-container
      image: your-private-image-repo/your-image:tag
      imagePullPolicy: IfNotPresent
  imagePullSecrets:
    - name: my-image-secret  # If using a private registry

以下示例展示了启用缓存的 Deployment 配置：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cached-image-deployment
spec:
  template:
    metadata:
      labels:
        gdce.baremetal.cluster.gke.io/cache-image: "true"
    spec:
      containers:
        - name: my-container
          image: your-private-image-repo/your-image:tag
          imagePullPolicy: IfNotPresent
      imagePullSecrets:
        - name: my-image-secret  # If using a private registry

Distributed Cloud 工作负载的限制

配置 Distributed Cloud 连接的工作负载时，您必须遵守本部分中所述的限制。这些限制由 Distributed Cloud connected 在您部署到 Distributed Cloud connected 硬件上的所有工作负载上强制执行。

Linux 工作负载限制

Distributed Cloud Connected 仅支持以下工作负载的 Linux 功能：

  • AUDIT_READ
  • AUDIT_WRITE
  • CHOWN
  • DAC_OVERRIDE
  • FOWNER
  • FSETID
  • IPC_LOCK
  • IPC_OWNER
  • KILL
  • MKNOD
  • NET_ADMIN
  • NET_BIND_SERVICE
  • NET_RAW
  • SETFCAP
  • SETGID
  • SETPCAP
  • SETUID
  • SYS_CHROOT
  • SYS_NICE
  • SYS_PACCT
  • SYS_PTRACE
  • SYS_RESOURCE
  • SYS_TIME

命名空间限制

Distributed Cloud Connected 不支持以下命名空间：

  • hostPID
  • hostIPC
  • hostNetwork

资源类型限制

Distributed Cloud Connected 不支持 CertificateSigningRequest 资源类型，该类型允许客户端根据签名请求请求颁发 X.509 证书。

安全上下文限制

Distributed Cloud Connected 不支持特权模式安全上下文。

Pod 绑定限制

Distributed Cloud Connected 不支持将 Pod 绑定到 HostNetwork 命名空间中的主机端口。此外，HostNetwork 命名空间不可用。

hostPath 音量限制

Distributed Cloud Connected 仅允许以下具有读/写访问权限的 hostPath 卷：

  • /dev/hugepages
  • /dev/infiniband
  • /dev/vfio
  • /dev/char
  • /sys/devices

PersistentVolumeClaim 个资源类型限制

Distributed Cloud Connected 仅允许以下 PersistentVolumeClaim 资源类型：

  • csi
  • nfs
  • local

卷类型限制

Distributed Cloud Connected 仅允许使用以下卷类型：

  • configMap
  • csi
  • downwardAPI
  • emptyDir
  • hostPath
  • nfs
  • persistentVolumeClaim
  • projected
  • secret

Pod 容忍限制

Distributed Cloud Connected 不允许在控制平面节点上创建用户创建的 Pod。具体而言，Distributed Cloud Connected 不允许调度具有以下容忍键的 Pod：

  • ""
  • node-role.kubernetes.io/master
  • node-role.kubernetes.io/control-plane

模拟限制

Distributed Cloud Connected 不支持用户或群组模拟。

管理命名空间限制

Distributed Cloud Connected 不允许访问以下命名空间：

  • ai-system
  • ai-speech-system
  • ai-ocr-system
  • ai-translation-system
  • anthos-identity-service
  • cert-manager
  • dataproc-system
  • dataproc-PROJECT_ID
  • dns-system
  • g-istio-system
  • gke-connect
  • gke-managed-metrics-server
  • gke-operators
  • g-ospf-servicecontrol-system
  • g-ospf-system
  • g-pspf-system
  • gke-system
  • gpc-backup-system
  • iam-system
  • kube-node-lease
  • kube-public
  • kube-system，但删除 ippools.whereabouts.cni.cncf.io 除外
  • metallb-system，但编辑 configMap 资源以设置负载平衡 IP 地址范围除外
  • nf-operator
  • oclcm-system
  • prediction
  • rm-system
  • robinio
  • saas-system
  • vm-system

PROJECT_ID 表示目标 Google Cloud 项目的 ID。

避免使用名称中包含 g- 前缀的任何命名空间。此类命名空间通常是 Distributed Cloud connected 使用的预留命名空间。

网络钩子限制

Distributed Cloud connected 对 Webhook 的限制如下：

  • 您创建的任何变更 webhook 都会自动排除 kube-system 命名空间。
  • 以下资源类型的更改性 webhook 已停用：
    • nodes
    • persistentvolumes
    • certificatesigningrequests
    • tokenreviews

Pod 优先级限制

Distributed Cloud Connected 要求您将工作负载 Pod 的优先级设置为低于 500000000 的值。

为 Pod 配置运行时类

借助 Distributed Cloud Connected，您可以使用 runtimeClassName 字段在 Pod 的配置中指定其运行时类。此设置会替换在集群级别指定的默认运行时类。可用的运行时类为 runc 和 gvisor。例如：

apiVersion: v1
kind: Pod
metadata:
  name: myPod
spec:
  runtimeClassName: gvisor
  containers:
  - name: myPod
    image: myPodImage 
  restartPolicy: OnFailure

如果您在 Pod 配置中省略此项，Pod 将使用集群级层指定的类。默认的集群级运行时类为 runc，除非您使用 --default-container-runtime 参数配置默认运行时类，如创建和管理集群中所述。

如果您在 Pod 或集群级别更改运行时类，则必须重启受影响的 Pod，更改才会生效。

gvisor 运行时类

指定 gvisor 运行时类会将 Pod 切换到基于 gVisor 的开放容器倡议 (OCI) 安全运行时。gVisor 是一种沙盒解决方案，可在工作负载及其宿主之间引入强大的隔离。

后续步骤