将容器迁移到 Google Cloud：将 OpenShift 项目迁移到 GKE Enterprise

Last reviewed 2022-01-24 UTC

本文档可帮助您规划、设计和实现将项目从 OpenShift 迁移到 GKE Enterprise 的过程。如果操作不当，那么将工作负载从一个环境迁移到另一个环境可能会遭遇挑战，因此请谨慎规划和执行迁移。

本文档是关于迁移到 Google Cloud 的系列文章中的一篇。如果您想要了解该系列文章，请参阅迁移到 Google Cloud：选择迁移路径。

本文档是一系列文章中的一篇，介绍了如何将容器迁移到 Google Cloud：

将容器迁移到 Google Cloud：将 Kubernetes 迁移到 Google Kubernetes Engine (GKE)
将容器迁移到 Google Cloud：从 OpenShift 迁移到 GKE Enterprise
将容器迁移到 Google Cloud：将 OpenShift 项目迁移到 GKE Enterprise（本文档）
从 OpenShift 迁移到 GKE Enterprise：将 OpenShift SCC 迁移到 Policy Controller 限制条件

如果您计划将 OpenShift 项目迁移到 GKE Enterprise，则本文档非常有用。如果您正在评估迁移的时机并希望了解潜在的情况，本文档也可以提供帮助。

本文档涉及迁移到 Google Cloud：使用入门、将容器迁移到 Google Cloud：将 Kubernetes 迁移到 GKE、将容器迁移到 Google Cloud：从 OpenShift 迁移到 GKE Enterprise 和 GKE 网络的最佳实践中介绍的概念。本文档会适时提供上述文档的链接。

本文档中的指导假设您要执行工作负载的直接原样迁移。在直接原样迁移中，您只需应用工作负载在目标 GKE Enterprise 环境中运行所需的最小更改。

如需将 OpenShift 资源迁移到 GKE Enterprise，您需要将它们映射并转换为其 Kubernetes 等效资源。本文档介绍了如何迁移将工作负载部署到 GKE Enterprise 并进行操作所需的以下 OpenShift 项目配置资源：

如需将 OpenShift 项目配置和相关资源迁移到 GKE Enterprise，我们建议您执行以下操作：

导出 OpenShift 项目配置资源描述符。
将 OpenShift 项目配置资源映射到 Kubernetes 资源。
创建映射到 OpenShift 项目配置资源的 Kubernetes 资源。
使用 Config Sync 管理 Kubernetes 资源。

本文档提供了如何完成迁移步骤的示例。

导出 OpenShift 项目配置资源描述符

如需导出 OpenShift 项目配置资源，我们建议您执行以下操作：

导出 OpenShift 项目描述符。
导出集群级资源描述符。
导出项目级资源描述符。

从 OpenShift 集群中导出的描述符包括描述资源配置和状态的字段，例如 spec 和 status 字段。描述符还包含保存资源状态信息的字段，例如 metadata.managedFields 字段。Kubernetes 和 OpenShift 为您管理包含资源状态信息及其值的字段。为了简化 OpenShift 资源描述符的评估，我们建议您对每个资源描述符执行以下操作：

记录保存动态生成的资源状态信息及其值的字段，如下所示：
- 嵌套在 metadata.annotations 下且以 openshift.io 前缀开头的任何字段
- metadata.creationTimestamp
- metadata.generation
- metadata.managedFields
- metadata.resourceVersion
- metadata.selfLink
- metadata.uid
- status
从资源描述符中移除包含动态生成的资源状态信息的字段。

如需导出 OpenShift 项目配置资源描述符，请使用 OpenShift 命令行界面 (oc CLI)。如需在 oc CLI 中导出资源描述符，您需要使用 cluster-admin 角色进行身份验证。如需查看 oc CLI 支持的所有 OpenShift 资源的列表，请运行 oc api-resources 命令。

导出 OpenShift 项目描述符

本部分介绍如何导出项目描述符。我们建议您排除运行系统组件（例如 istio-system 组件）的 OpenShift 项目，并排除名称以 openshift-、kube- 或knative- 开头的 OpenShift 项目。OpenShift 会为您管理这些 OpenShift 项目，它们不在迁移范围内，因为您不使用它们来部署工作负载。如需导出 OpenShift 项目描述符，请对每个 OpenShift 集群执行以下操作：

在有权访问 OpenShift 集群的终端中，使用 oc get 命令获取 OpenShift 项目的列表：
```
oc get projects
```
输出内容类似如下：
```
NAME                 DISPLAY NAME      STATUS
example-project                        Active
...
```
输出会显示 OpenShift 集群中当前设置的 OpenShift 项目列表。
对于列表中的每个 OpenShift 项目，以 YAML 文件格式导出其描述符，显示输出，并使用 tee 命令将其保存到文件中，供日后处理。例如，导出 example-project OpenShift 项目的描述符：
```
oc get project example-project -o yaml | tee project-example-project.yaml
```
输出内容类似如下：
```
apiVersion: project.openshift.io/v1
kind: Project
metadata:
  annotations:
  name: example-project
spec:
  finalizers:
  - kubernetes
```
输出会以 YAML 文件格式显示 example-project OpenShift 项目的描述符。输出将保存到 project-example-project.yaml 文件中。

导出集群级资源描述符

本部分介绍如何导出具有集群范围的资源的描述符，不包括安全上下文限制。如需了解如何迁移安全政策，请参阅从 OpenShift 迁移到 GKE Enterprise：将 OpenShift SCC 迁移到 Policy Controller 限制条件。如需导出其他资源描述符，请对每个 OpenShift 集群执行以下操作：

在终端中，获取 ClusterResourceQuota 列表：
```
oc get clusterresourcequotas
```
输出内容类似如下：
```
NAME       AGE
for-name   6m15s
for-user   4s
...
```
输出会显示 OpenShift 集群中当前设置的 ClusterResourceQuota 列表。
对于列表中的每个 ClusterResourceQuota，以 YAML 文件格式导出其描述符，显示输出并将其保存到文件中以供以后处理。例如，导出 for-name ClusterResourceQuota 的描述符：
```
oc get clusterresourcequota for-name -o yaml | tee clusterresourcequota-for-name.yaml
```
输出内容类似如下：
```
apiVersion: quota.openshift.io/v1
kind: ClusterResourceQuota
metadata:
  name: for-name
spec:
  quota:
    hard:
      pods: "10"
      secrets: "20"
  selector:
    annotations: null
    labels:
      matchLabels:
        name: frontend
```
输出会以 YAML 格式显示 for-name ClusterResourceQuota 的描述符。输出将保存到 clusterresourcequota-for-name.yaml 文件中。
获取 ClusterRole 列表：
```
oc get clusterroles
```
输出内容类似如下：
```
NAME                           CREATED AT
admin                          2021-02-02T06:17:02Z
aggregate-olm-edit             2021-02-02T06:17:59Z
aggregate-olm-view             2021-02-02T06:18:01Z
alertmanager-main              2021-02-02T06:48:26Z
basic-user                     2021-02-02T06:26:42Z
...
```
输出会显示 OpenShift 集群中当前设置的 ClusterRole 列表。ClusterRole 列表包括 OpenShift 默认 ClusterRole，以及引用 OpenShift 系统组件的 ClusterRole。我们建议您评估列表中的所有 ClusterRole，以评估您需要迁移哪些角色以及哪些角色不适用于目标 GKE Enterprise 环境。

对于列表中的每个 ClusterRole，以 YAML 文件格式导出其描述符，显示输出并将其保存到文件中以供以后处理。例如，导出 admin ClusterRole 的描述符：

oc get clusterrole admin -o yaml | tee clusterrole-admin.yaml

输出内容类似如下：

aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.authorization.k8s.io/aggregate-to-admin: "true"
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: admin
rules:
- apiGroups:
  - operators.coreos.com
  resources:
  - subscriptions
  verbs:
  - create
  - update
  - patch
  - delete
...

输出会以 YAML 格式显示 admin ClusterRole 的描述符。输出将保存到 clusterrole-admin.yaml 文件中。

获取 ClusterRoleBinding 列表：

oc get clusterrolebindings

输出内容类似如下：

NAME                                        ROLE                                             AGE
alertmanager-main                           ClusterRole/alertmanager-main                    21d
basic-users                                 ClusterRole/basic-user                           21d
cloud-credential-operator-rolebinding       ClusterRole/cloud-credential-operator-role       21d
cluster-admin                               ClusterRole/cluster-admin                        21d
cluster-admins                              ClusterRole/cluster-admin                        21d
cluster-autoscaler                          ClusterRole/cluster-autoscaler                   21d
cluster-autoscaler-operator                 ClusterRole/cluster-autoscaler-operator          21d
cluster-monitoring-operator                 ClusterRole/cluster-monitoring-operator          21d
...

输出会显示 OpenShift 集群中当前设置的 ClusterRoleBinding 列表。ClusterRoleBinding 列表包含引用 OpenShift 系统组件的 ClusterRoleBinding。我们建议您评估列表中的所有 ClusterRoleBinding，以评估您需要迁移哪些绑定以及哪些绑定不适用于目标 GKE Enterprise 环境。

对于列表中的每个 ClusterRoleBinding，以 YAML 文件格式导出其描述符，显示输出并将其保存到文件中以供以后处理。例如，导出 cluster-admin ClusterRoleBinding 的描述符：

oc get clusterrolebinding cluster-admin -o yaml | tee clusterrolebinding-cluster-admin.yaml

输出内容类似如下：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:masters

输出会以 YAML 格式显示 cluster-admin ClusterRoleBinding 的描述符。输出将保存到 clusterrolebinding-cluster-admin.yaml 文件中。

导出自定义 NetNamespace

本部分介绍如何评估多租户隔离的配置。如果您为集群中的任何 OpenShift 项目创建了自定义 NetNamespace 以隔离或加入网络命名空间，则本部分适用。如果您未创建自定义 NetNamespace，请跳到导出项目级资源描述符。

OpenShift 会自动为代管式 OpenShift 项目创建和管理 NetNamespace。由 OpenShift 管理的项目的 NetNamespace 不在此次迁移范围之内。

如需导出自定义 NetNamespace，请执行以下操作：

获取 NetNamespace 列表：

oc get netnamespaces

输出类似于以下内容：

NAME                                          NETID      EGRESS IPS
default                                       0
kube-node-lease                               13240579
kube-public                                   15463168
kube-system                                   16247265
openshift                                     9631477
openshift-apiserver                           12186643
openshift-apiserver-operator                  6097417
openshift-authentication                      2862939
openshift-authentication-operator             723750
openshift-cloud-credential-operator           11544971
openshift-cluster-csi-drivers                 7650297
openshift-cluster-machine-approver            7836750
openshift-cluster-node-tuning-operator        7531826
...

输出会显示 OpenShift 集群中当前设置的 NetNamespace 列表。

对于列表中的每个 NetNamespace，以 YAML 文件格式导出其描述符，显示输出并将其保存到文件中以供以后处理。例如，导出 default NetNamespace 的描述符：
```
oc get netnamespace example-project -o yaml | tee netnamespace-example-project.yaml
```
对于没有相同 netid 值的 NetNamespace，输出类似于以下内容：
```
apiVersion: network.openshift.io/v1
kind: NetNamespace
metadata:
  name: example-project
netid: 1234
netname: example-project
```
输出会以 YAML 文件格式显示 example-project NetNamespace 的描述符。输出将保存到 netnamespace-example-project.yaml 文件中。

对于具有相同 netid 值的 NetNamespace，输出类似于以下内容：
```
apiVersion: network.openshift.io/v1
kind: NetNamespace
metadata:
  name: example-project
netid: 1234
netname: example-project

apiVersion: network.openshift.io/v1
kind: NetNamespace
metadata:
  name: example-project-2
netid: 1234
netname: example-project-2
```

导出项目级资源描述符

如需导出具有项目范围的资源的描述符，请为每个 OpenShift 项目执行以下操作。

在您的终端中，选择要评估的 OpenShift 项目。例如，选择 example-project OpenShift 项目：
```
oc project example-project
```
获取 ResourceQuota 列表：
```
oc get resourcequotas
```
输出内容类似如下：
```
NAME        AGE   REQUEST                        LIMIT
gpu-quota   6s    requests.nvidia.com/gpu: 1/1
...
```
输出会显示 OpenShift 集群中当前为所选 OpenShift 项目设置的 ResourceQuotas 列表。
对于列表中的每个 ResourceQuota，以 YAML 格式导出其描述符，显示输出并将其保存到文件中以供以后处理。例如，导出 gpu-quota ResourceQuota 的描述符：
```
oc get resourcequota gpu-quota -o yaml | tee resourcequota-gpu-quota.yaml
```
输出内容类似如下：
```
apiVersion: v1
kind: ResourceQuota
metadata:
  name: gpu-quota
  namespace: example-project
spec:
  hard:
    requests.nvidia.com/gpu: "1"
```
输出会以 YAML 文件格式显示 gpu-quota ResourceQuota 的描述符。输出将保存到 resourcequota-gpu-quota.yaml 文件中。
获取 Role 列表：
```
oc get roles
```
输出内容类似如下：
```
NAME             CREATED AT
example          2021-02-02T06:48:27Z

...
```
输出会显示 OpenShift 集群中当前为所选 OpenShift 项目设置的 Role 列表。Role 列表包括引用 OpenShift 系统组件的 Role。我们建议您评估列表中的所有 Role，以评估您需要迁移哪些角色以及哪些角色不适用于目标 GKE Enterprise 环境。
对于列表中的每个 Role，以 YAML 文件格式导出其描述符，显示输出并将其保存到文件中以供以后处理。例如，导出 example Role 的描述符：
```
oc get role example -o yaml | tee role-example.yaml
```
输出内容类似如下：
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: example
  namespace: example-project
rules:
- apiGroups:
  - ""
  resources:
  - services
  - endpoints
  - pods
  verbs:
  - get
  - list
  - watch
```
输出会以 YAML 文件格式显示 example Role 的描述符。输出将保存到 role-example.yaml 文件中。

获取 RoleBinding 列表：

oc get rolebindings

输出内容类似如下：

NAME                               ROLE                                           AGE
machine-config-controller-events   ClusterRole/machine-config-controller-events   21d
machine-config-daemon-events       ClusterRole/machine-config-daemon-events       21d
example                            Role/example                                   21d
system:deployers                   ClusterRole/system:deployer                    21d
system:image-builders              ClusterRole/system:image-builder               21d
system:image-pullers               ClusterRole/system:image-puller                21d
...

输出会显示 OpenShift 集群中为所选 OpenShift 项目设置的 RoleBinding 列表。RoleBinding 列表包括引用 OpenShift 系统组件的 RoleBinding。我们建议您评估列表中的所有 RoleBinding，以评估您需要迁移哪些绑定以及哪些绑定不适用于目标 GKE Enterprise 环境。

对于列表中的每个 RoleBinding，以 YAML 文件格式导出其描述符，显示输出并将其保存到文件中以供以后处理。例如，导出 example RoleBinding 的描述符：
```
oc get rolebinding example -o yaml | tee rolebinding-example.yaml
```
输出内容类似如下：
```
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: example
  namespace: example-project
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: example
subjects:
- kind: ServiceAccount
  name: example
  namespace: example-ns
```
输出会以 YAML 文件格式显示 example RoleBinding 的描述符。输出将保存到 rolebinding-example.yaml 文件中。
获取 EgressNetworkPolicy 列表：
```
oc get egressnetworkpolicies
```
输出内容类似如下：
```
NAME      AGE
default   2m2s
...
```
输出会显示 OpenShift 集群中当前为所选 OpenShift 项目设置的 EgressNetworkPolicy 列表。

对于列表中的每个 EgressNetworkPolicy，以 YAML 文件格式导出其描述符，显示输出并将其保存到文件中以供以后处理。例如，导出 default EgressNetworkPolicy 的描述符：

oc get egressnetworkpolicy default -o yaml | tee egressnetworkpolicy-default.yaml

输出内容类似如下：

apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: default
  namespace: example-project
spec:
  egress:
  - to:
      cidrSelector: 1.2.3.0/24
    type: Allow
  - to:
      dnsName: www.example.com
    type: Allow
  - to:
      cidrSelector: 0.0.0.0/0
    type: Deny

输出会以 YAML 格式显示 default EgressNetworkPolicy 的描述符。输出还将保存到 egressnetworkpolicy-default.yaml 文件中。

获取 NetworkPolicy 列表：
```
oc get networkpolicies
```
输出内容类似如下：
```
NAME          POD-SELECTOR   AGE
test-policy   app=mongodb    3s
...
```
输出会显示 OpenShift 集群中当前为所选 OpenShift 项目设置的 NetworkPolicy 列表。

对于列表中的每个 NetworkPolicy，以 YAML 文件格式导出其描述符，显示输出并将其保存到文件中以供以后处理。例如，导出 test-policy NetworkPolicy 的描述符：

oc get networkpolicy test-policy -o yaml | tee networkpolicy-test-policy.yaml

输出内容类似如下：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-policy
  namespace: example-project
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: app
    ports:
    - port: 27017
      protocol: TCP
  podSelector:
    matchLabels:
      app: mongodb
  policyTypes:
  - Ingress

输出会以 YAML 文件格式显示 test-policy NetworkPolicy 的描述符。输出将保存到 networkpolicy-test-policy.yaml 文件中。

将 OpenShift 项目配置资源映射到 Kubernetes 资源

完成 OpenShift 项目配置资源的清单后，您可以按如下方式评估这些资源：

评估清单中的哪些资源是 Kubernetes 资源，哪些是 OpenShift 资源。
将 OpenShift 资源映射到其 Kubernetes、GKE 和 GKE Enterprise 等效资源。

以下列表可帮助您评估 OpenShift 集群中预配的哪些资源是 Kubernetes 资源，以及哪些资源仅在 OpenShift 中可用：

OpenShift 项目是具有其他注释的 Kubernetes Namespace。
Role、ClusterRole、RoleBinding 和 ClusterRoleBinding 是 Kubernetes 资源。
ResourceQuota 是 Kubernetes 资源。
NetworkPolicy 是 Kubernetes 资源。
ClusterResourceQuota 不是 Kubernetes 资源；它们仅在 OpenShift 中可用。
NetNamespace 和 EgressNetworkPolicy 不是 Kubernetes 资源；它们仅在 OpenShift 中可用。

下表总结了如何将 OpenShift 项目配置资源映射到 GKE Enterprise 中使用的资源。

OpenShift	GKE Enterprise
项目	转换为具有其他注释的 Kubernetes Namespace
Role、ClusterRole、RoleBinding 和 ClusterRoleBinding	Kubernetes RBAC 资源
ResourceQuota	Kubernetes RBAC 资源
ClusterResourceQuota	转换为 ResourceQuota 或使用分层资源配额
NetworkPolicy	Kubernetes 网络资源
NetNamespace、EgressNetworkPolicy	转换为 NetworkPolicy

评估 OpenShift 环境中的资源后，请将 OpenShift 资源映射到您可以在 GKE 和 GKE Enterprise 中预配和配置的资源。您无需映射在 OpenShift 集群中使用的 Kubernetes 资源，因为 GKE Enterprise 直接支持这些资源。如 OpenShift 到 GKE Enterprise 功能映射摘要中所述，我们建议您执行以下映射：

将 OpenShift 项目映射到 Kubernetes Namespace。
将 ClusterResourceQuota 映射到 ResourceQuota。
将 NetNamespace 和 EgressNetworkPolicy 映射到 NetworkPolicy。

创建映射到 OpenShift 项目配置资源的 Kubernetes 资源

完成映射后，您需要创建映射到 OpenShift 资源的 Kubernetes 资源。我们建议您创建以下内容：

每个 OpenShift 项目都有一个 Kubernetes Namespace。
ClusterResourceQuota 限制的每个 Kubernetes Namespace 都有一个 ResourceQuota。
用以匹配 NetNamespace 和 EgressNetworkPolicy 的 NetworkPolicy。

创建 Kubernetes Namespace

OpenShift 项目是具有其他注释的 Kubernetes Namespace。OpenShift 项目 API 与 Kubernetes Namespace API 非常匹配。如需迁移 OpenShift 项目，我们建议您为每个 OpenShift 项目创建一个 Kubernetes Namespace。这些 API 兼容，因此您可以从 OpenShift 项目创建 Kubernetes Namespace。

如需通过 OpenShift 项目创建 Kubernetes Namespace，我们建议您将 OpenShift 项目描述符中的值更改为每个 OpenShift 项目对应的 Kubernetes Namespace API 版本。为此，您将 OpenShift 项目描述符中的 apiVersion 字段值从 OpenShift 项目对象 API 版本和 kind 字段值更改为相应的 Kubernetes Namespace 对象 API 版本。例如，您在上一部分中评估的 OpenShift 项目类似于以下内容：

apiVersion: project.openshift.io/v1
kind: Project
metadata:
  annotations:
  name: default
spec:
  finalizers:
  - kubernetes

如需迁移项目，请将 apiVersion 字段值从 project.openshift.io/v1 更改为 v1，并将 kind 字段值从 Project 更改为 Namespace：

apiVersion: v1
kind: Namespace
Metadata:
  annotations:
  name: default
spec:
  finalizers:
  - kubernetes

创建 Kubernetes ResourceQuota

OpenShift ClusterResourceQuota 可让您跨多个 OpenShift 项目共享配额。创建 ClusterResourceQuota 时，您可以定义配额并定义选择器以匹配要强制执行该配额的 OpenShift 项目。在本部分中，您需要将 OpenShift ClusterResourceQuota 迁移到您之前创建的 Namespace 中的 Kubernetes ResourceQuota。

如需迁移 ClusterResourceQuota，我们建议您为每个 ClusterResourceQuota 执行以下操作：

通过评估 ClusterResourceQuota 的 spec.quota 字段和 spec.selector 字段，将 ClusterResourceQuota 映射到 OpenShift 项目。例如，您在上一部分导出的 for-name ClusterResourceQuota 如下所示：
```
apiVersion: quota.openshift.io/v1
kind: ClusterResourceQuota
metadata:
  name: for-name
spec:
  quota:
    hard:
      pods: "10"
      secrets: "20"
  selector:
    annotations: null
    labels:
      matchLabels:
        name: frontend
```
for-name ClusterResourceQuota 会强制执行 Pod 和 Secret 配额限制。spec.selector 字段对 frontend OpenShift 项目强制执行这些限制。
在前面的创建 Kubernetes Namespace 中，您创建了与您的 OpenShift 项目相对应的 Kubernetes Namespace。使用该信息将 ClusterResourceQuota 映射到新的 Kubernetes Namespace。例如，frontend OpenShift 项目包含 for-name ClusterResourceQuota。该项目对应于 frontend Kubernetes Namespace，因此您可以将 for-name ClusterResourceQuota 映射到 frontend Kubernetes Namespace。
对于 ClusterResourceQuota 的 quota 字段中的每个配额定义，请根据相关条件将 ClusterResourceQuota 映射到的 Kubernetes Namespace 之间划分配额量。例如，您可以在 frontend Kubernetes Namespace 中平均分配 for-name ClusterResourceQuota 设置的配额量。
对于映射到 ClusterResourceQuota 的每个 Kubernetes Namespace，您创建一个 Kubernetes ResourceQuota 对 Namespace 实施配额。根据在上一步中收集的信息设置配额数量。例如，您可以为 frontend Kubernetes Namespace 创建 ResourceQuota：
```
apiVersion: v1
kind: ResourceQuota
metadata:
  name: pods-secrets
  namespace: frontend
spec:
  hard:
    pods: "10"
    secrets: "20"
```
再举一例，您需要将 for-name ClusterResourceQuota 映射到两个不同的 Kubernetes Namespace：example-1 和 example-2。如需完成映射，请通过为 Kubernetes Namespace 创建 ResourceQuota 以在这些资源之间平均分配资源。分配 ResourceQuota 的前半部分：
```
apiVersion: v1
kind: ResourceQuota
metadata:
  name: pods-secrets
  namespace: example-1
spec:
  hard:
    pods: "5"
    secrets: "10"
```
分配 ResourceQuota 的前半部分后，再分配 ResourceQuota 的后半部分：
```
apiVersion: v1
kind: ResourceQuota
metadata:
  name: pods-secrets
  namespace: example-2
spec:
  hard:
    pods: "5"
    secrets: "10"
```
这种方法允许您对创建 ResourceQuota 的每个 Kubernetes Namespace 强制执行限制，而不是为多个 Kubernetes Namespace 设置单个限制。

使用 ResourceQuota 对 Kubernetes Namespace 强制执行配额与使用 ClusterResourceQuota 对所有 Kubernetes Namespace 强制执行配额不同。在不同的 Kubernetes Namespace 之间划分集群范围的配额可能不是最理想的：这种划分可能会为某些 Kubernetes Namespace 预配过多的配额，而为其他 Kubernetes Namespace 预配不足的配额。

我们建议您根据相应的 ClusterResourceQuota 建立的总配额量来动态调整 Kubernetes Namespace 中的 ResourceQuota 的配置，以优化配额分配。例如，您可以动态增加或减少由 pods-secrets ResourceQuota 强制执行的配额量，以避免过度预配或预配不足的 example-1 和 example-2 Kubernetes Namespace。pods-secrets ResourceQuota 的总配额量不应超过对应ClusterResourceQuota 中的配额量。

配置 ResourceQuota 时，请考虑 GKE 配额和限制以及 GKE on VMware 配额和限制。这些配额和限制可能会强制执行比您的 ResourceQuota 更低的限制。例如，无论您如何配置 ResourceQuota，GKE 都会限制每个节点的最大 Pod 数。

创建 NetworkPolicy

OpenShift NetNamespace 可让您配置 OpenShift 项目之间的网络隔离。OpenShift EgressNetworkPolicy 可让您控制离开 OpenShift 集群的出站流量。本部分依赖于流量限制概念。

如需迁移 NetNamespace 和 EgressNetworkPolicy，请执行以下操作：

评估您的 NetNamespace 和 EgressNetworkPolicy，以了解它们如何调节 OpenShift 项目之间的网络流量以及离开 OpenShift 集群的出站流量。例如，请评估您在上一部分中导出的 NetNamespace 和 EgressNetworkPolicy：
```
apiVersion: network.openshift.io/v1
kind: NetNamespace
metadata:
  name: example-project
netid: 1234
netname: example-project

apiVersion: network.openshift.io/v1
kind: NetNamespace
metadata:
  name: example-project-2
netid: 1234
netname: example-project-2

apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: default
  namespace: example-project
spec:
  egress:
  - to:
      cidrSelector: 1.2.3.0/24
    type: Allow
  - to:
      cidrSelector: 0.0.0.0/0
    type: Deny
```
example-project 和 example-project-2 NetNamespace 定义了具有相同 netid 值 1234 的叠加网络。因此，example-project OpenShift 项目中的 Pod 可以与 example-project-2 OpenShift 项目中的 Pod 通信，反之亦然。

default EgressNetworkPolicy 定义了以下出站网络流量规则：
- 允许出站流量发送到 1.2.3.0/24 子网。
- 拒绝与其他规则不匹配的出站流量。

创建 NetworkPolicy 和 OPA 政策，以符合网络流量限制要求。例如，default-np 和 default-np-2 实现了以下政策：

由 default EgressNetworkPolicy 强制执行的政策。
由将 netid 标签设置为 example-project 和 example-project-2 的 Namespace 中的 example-project 和 example-project-2 NetNamespace 强制执行的政策：

这些政策如下所示：

---
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-np
  namespace: example-project
spec:
  policyTypes:
  - Ingress
  - Egress
  podSelector: {}
  egress:
    - to:
      - namespaceSelector:
          matchLabels:
            netid: example-project-2
      - podSelector: {}
      - ipBlock:
          cidr: 1.2.3.0/24
  ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            netname: example-project-2

---
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-np-2
  namespace: example-project-2
spec:
  policyTypes:
  - Ingress
  - Egress
  podSelector: {}
  egress:
    - to:
      - namespaceSelector:
          matchLabels:
            netid: example-project-2
      - podSelector: {}
      - ipBlock:
          cidr: 1.2.3.0/24
  ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            netname: example-project

使用 Config Sync 管理 Kubernetes 资源

如需管理 GKE 集群的 Kubernetes 资源和配置，我们建议您使用 Config Sync。

如需了解如何在 GKE 集群上启用 Config Sync，请参阅安装 Config Sync。

在 GKE Enterprise 环境中预配和配置 Config Sync 后，您可以使用它创建配置并将配置自动应用于 GKE 集群。

后续步骤

了解如何开始迁移到 Google Cloud。
了解构建和操作容器的最佳实践。
了解 GKE 网络的最佳做法。
了解如何强化集群的安全性。
阅读 GKE 安全概览。
探索有关 Google Cloud 的参考架构、图表和最佳实践。查看我们的 Cloud Architecture Center。