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
```
出力には、example-project OpenShift プロジェクトの記述子が YAML ファイル形式で表示されます。出力は 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
```
出力には、for-name ClusterResourceQuota の記述子が YAML 形式で表示されます。出力は 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 を評価して、移行する必要がある Role と、移行先の GKE Enterprise 環境で適用されない Role を評価することをおすすめします。

リスト内の各 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
...

出力には、admin ClusterRole の記述子が YAML 形式で表示されます。出力は 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 クラスタに設定されている RoleBinding のリストが表示されます。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
```
出力には、cluster-admin ClusterRoleBinding の記述子が YAML 形式で表示されます。出力は 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
```
出力には、example-project NetNamespace の記述子が YAML ファイル形式で表示されます。出力は 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"
```
出力には、gpu-quota ResourceQuota の記述子が YAML ファイル形式で表示されます。出力は resourcequota-gpu-quota.yaml ファイルに保存されます。
Role のリストを取得します。
```
oc get roles
```
出力は次のようになります。
```
NAME             CREATED AT
example          2021-02-02T06:48:27Z

...
```
出力に、選択した OpenShift プロジェクトの OpenShift クラスタで現在設定されている Role のリストが表示されます。Role のリストには、OpenShift システムコンポーネントを参照する Role が含まれています。リスト内の Role をすべて評価して、移行する必要がある Role と、移行先の GKE Enterprise 環境で適用されない Role を評価することをおすすめします。
リスト内の各 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
```
出力には、example Role の記述子が YAML ファイル形式で表示されます。出力は 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
```
出力には、example RoleBinding の記述子が YAML ファイル形式で表示されます。出力は rolebinding-example.yaml ファイルに保存されます。
EgressNetworkPolicy のリストを取得します。
```
oc get egressnetworkpolicies
```
出力は次のようになります。
```
NAME      AGE
default   2m2s
...
```
出力に、選択した OpenShift プロジェクトの OpenShift クラスタで現在設定されている EgressNetworkPolicies のリストが表示されます。
リスト内の各 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
```
出力では、default EgressNetworkPolicy の記述子が YAML 形式で表示されます。出力は egressnetworkpolicy-default.yaml ファイルにも保存されます。
NetworkPolicy のリストを取得します。
```
oc get networkpolicies
```
出力は次のようになります。
```
NAME          POD-SELECTOR   AGE
test-policy   app=mongodb    3s
...
```
出力に、選択した OpenShift プロジェクトの OpenShift クラスタで現在設定されている NetworkPolicies のリストが表示されます。
リスト内の各 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
```
出力では、test-policy NetworkPolicy の記述子が YAML ファイル形式で表示されます。出力は 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 プロジェクトごとに 1 つの Kubernetes Namespace。
ClusterResourceQuota で制限している Kubernetes Namespace ごとに 1 つの ResourceQuota。
NetworkPolicy は NetNamespace と EgressNetworkPolicy に一致します。

Kubernetes Namespace を作成する

OpenShift プロジェクトは、追加のアノテーションが付加された Kubernetes Namespace です。OpenShift project 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 プロジェクトと一致するようにセレクタを定義します。このセクションでは、前に作成した Namespace の Kubernetes ResourceQuota に OpenShift ClusterResourceQuota を移行します。

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 間で割り当て量を分配します。たとえば、for-name ClusterResourceQuota によって設定された割り当て量を frontend Kubernetes Namespace に均等に分配できます。
ClusterResourceQuota にマッピングした Kubernetes Namespace ごとに、その Namespace に割り当てを適用する Kubernetes ResourceQuota を作成します。前の手順で収集した情報に基づいて割り当て量を設定します。たとえば、frontend Kubernetes Namespace に ResourceQuota を作成します。
```
apiVersion: v1
kind: ResourceQuota
metadata:
  name: pods-secrets
  namespace: frontend
spec:
  hard:
    pods: "10"
    secrets: "20"
```
別の例として、for-name ClusterResourceQuota を 2 つの異なる 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"
```
このアプローチでは、複数の Kubernetes Namespace に単一の上限を設定するのではなく、ResourceQuota を作成する Kubernetes Namespace ごとに上限を適用できます。

ResourceQuota を使用して Kubernetes Namespace に割り当てを適用することは、ClusterResourceQuota を使用して 1 つの割り当てをすべての 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 より低い上限が適用される場合があります。たとえば、GKE では、ResourceQuota の構成方法に関係なく、ノードあたりの 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 サブネットへのアウトバウンドトラフィックを許可します。
- 他のルールと一致しないアウトバウンドトラフィックを拒否します。

ネットワークトラフィック制限の要件に合わせて NetworkPolicies と 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 リソースを管理する

Kubernetes リソースと GKE クラスタの構成を管理するには、Config Sync を使用することをおすすめします。

GKE クラスタで Config Sync を有効にする方法については、Config Sync をインストールするをご覧ください。

GKE Enterprise 環境で Config Sync をプロビジョニングして構成したら、それを使用して構成を作成し GKE クラスタに自動的に適用します。

次のステップ

Google Cloud への移行に関するスタートガイドを確認する。
コンテナの構築と操作のベストプラクティスについて学習する。
GKE ネットワーキングのベストプラクティスを確認する。
クラスタのセキュリティを強化する方法について理解する。
GKE セキュリティの概要を確認する。
Google Cloud に関するリファレンスアーキテクチャ、図、ベストプラクティスを確認する。Cloud アーキテクチャセンターをご覧ください。

Google Cloud へのコンテナの移行: OpenShift プロジェクトから GKE Enterprise への移行

OpenShift プロジェクト構成のリソース記述子をエクスポートする

OpenShift プロジェクト記述子をエクスポートする

クラスタ スコープのリソース記述子をエクスポートする

カスタマイズされた NetNamespace をエクスポートする

プロジェクト スコープのリソース記述子をエクスポートする

OpenShift プロジェクト構成リソースを Kubernetes リソースにマッピングする

OpenShift プロジェクト構成リソースにマッピングする Kubernetes リソースを作成する

Kubernetes Namespace を作成する

Kubernetes ResourceQuota を作成する

NetworkPolicy を作成する

Config Sync を使用して Kubernetes リソースを管理する

次のステップ

クラスタスコープのリソース記述子をエクスポートする

プロジェクトスコープのリソース記述子をエクスポートする