Container zu Google Cloud migrieren: OpenShift-Projekte zu GKE Enterprise migrieren

Last reviewed 2022-01-24 UTC

Dieses Dokument hilft Ihnen bei der Planung, Gestaltung und Implementierung der Migration Ihrer Projekte von OpenShift zu GKE Enterprise. Bei einer inkorrekten Vorgehensweise kann das Verschieben Ihrer Arbeitslasten von einer Umgebung in eine andere sehr schwierig sein. Seien Sie daher sehr sorgfältig bei der Planung und Durchführung Ihrer Migration.

Dieses Dokument ist Teil einer mehrteiligen Reihe zur Migration zu Google Cloud. Weitere Informationen zu der Reihe finden Sie unter Migration zu Google Cloud: Migrationspfad auswählen.

Dieses Dokument ist Teil einer Reihe zur Migration von Containern zu Google Cloud:

Dieses Dokument ist nützlich, wenn Sie OpenShift-Projekte zu GKE Enterprise migrieren möchten. Dieses Dokument ist auch hilfreich, wenn Sie die Möglichkeit zur Migration in Betracht ziehen und sich ein Bild davon machen möchten.

Dieses Dokument basiert auf Konzepten, die inMigration zu Google Cloud: Einstieg, inContainer zu Google Cloud migrieren: Von Kubernetes zu GKE migrieren, in Container zu Google Cloud migrieren: Von OpenShift zu GKE Enterprise migrieren und in Best Practices für GKE-Netzwerke beschrieben werden. Dieses Dokument verlinkt wo passend die vorherigen Dokumente.

In der Anleitung in diesem Dokument wird davon ausgegangen, dass Sie eine Lift-and-Shift-Migration Ihrer Arbeitslasten ausführen möchten. Bei einer Lift-and-Shift-Migration wenden Sie nur die Änderungen an, die Sie mindestens benötigen, damit Ihre Arbeitslasten in der GKE Enterprise-Zielumgebung ausgeführt werden können.

Wenn Sie OpenShift-Ressourcen zu GKE Enterprise migrieren möchten, ordnen Sie sie den entsprechenden Kubernetes-Entsprechungen zu und konvertieren Sie sie. In diesem Dokument wird die Migration der folgenden OpenShift-Projektkonfigurationsressourcen beschrieben, die zum Bereitstellen und Ausführen Ihrer Arbeitslasten in GKE Enterprise erforderlich sind:

So migrieren Sie die OpenShift-Projektkonfiguration und die zugehörigen Ressourcen nach GKE Enterprise:

  1. OpenShift-Projektkonfiguration-Ressourcendeskriptoren exportieren
  2. OpenShift-Projektkonfiguration-Ressourcen Kubernetes-Ressourcen zuordnen
  3. Kubernetes-Ressourcen erstellen, die den OpenShift-Projekt-Konfigurationsressourcen zugeordnet werden
  4. Kubernetes-Ressourcen mit Config Sync verwalten.

In diesem Dokument wird anhand von Beispielen gezeigt, wie Sie die Migrationsschritte ausführen.

OpenShift-Projektkonfiguration-Ressourcendeskriptoren exportieren

Zum Exportieren der OpenShift-Projektkonfigurationsressourcen empfehlen wir Folgendes Vorgehen:

  1. OpenShift-Projektdeskriptoren exportieren.
  2. Exportieren Sie clusterbezogene Ressourcendeskriptoren.
  3. Projektbezogene Ressourcendeskriptoren exportieren.

Die Deskriptoren, die Sie aus einem OpenShift-Cluster exportieren, enthalten Felder, die die Konfiguration und den Status von Ressourcen beschreiben, z. B. die Felder spec und status. Die Deskriptoren enthalten auch Felder mit Informationen zum Ressourcenstatus, z. B. das Feld metadata.managedFields. Kubernetes und OpenShift verwalten die Felder, die Informationen zum Ressourcenstatus und ihre Werte enthalten. Um die Bewertung von OpenShift-Ressourcendeskriptoren zu vereinfachen, empfehlen wir für jeden Ressourcendeskriptor Folgendes:

  1. Notieren Sie die Felder, die dynamisch generierte Informationen zum Ressourcenstatus und die Ressourcen-Werte enthalten, z. B.:

    • Alle Felder, die unter metadata.annotations verschachtelt sind und mit dem Präfix openshift.io beginnen
    • metadata.creationTimestamp
    • metadata.generation
    • metadata.managedFields
    • metadata.resourceVersion
    • metadata.selfLink
    • metadata.uid
    • status

  2. Entfernen Sie die Felder, die dynamisch generierte Informationen zum Ressourcenstatus aus dem Ressourcendeskriptor enthalten.

Zum Exportieren von OpenShift-Projektkonfiguration-Ressourcendeskriptoren verwenden Sie die OpenShift-Befehlszeile (oc-Befehlszeile). Zum Exportieren von Ressourcendeskriptoren in der oc-Befehlszeile müssen Sie sich mit der Rolle "cluster-admin" authentifizieren. Führen Sie den Befehl oc api-resources aus, um eine Liste aller OpenShift-Ressourcen aufzurufen, die von der oc-Befehlszeile unterstützt werden.

OpenShift-Projektdeskriptoren exportieren

In diesem Abschnitt wird beschrieben, wie Sie Projektdeskriptoren exportieren. Wir empfehlen, OpenShift-Projekte auszuschließen, die Systemkomponenten ausführen, wie z. B. die Komponente istio-system, und OpenShift-Projekte auszuschließen, deren Namen mit openshift-, kube- oder knative- beginnen. OpenShift verwaltet diese OpenShift-Projekte für Sie und liegt außerhalb des Bereichs dieser Migration, da Sie sie nicht zum Bereitstellen Ihrer Arbeitslasten verwenden. Gehen Sie für jeden OpenShift-Cluster folgendermaßen vor, um OpenShift-Projektdeskriptoren zu exportieren:

  1. Rufen Sie in einem Terminal mit Zugriff auf den OpenShift-Cluster die Liste der OpenShift-Projekte mithilfe von oc get-Befehl ab:

    oc get projects

    Die entsprechende Ausgabe sieht etwa so aus:

    NAME                 DISPLAY NAME      STATUS
example-project                        Active
...

    Die Ausgabe zeigt eine Liste der OpenShift-Projekte, die derzeit in Ihrem OpenShift-Cluster eingerichtet sind.

  2. Exportieren Sie für jedes OpenShift-Projekt in der Liste den Deskriptor im YAML-Dateiformat, zeigen Sie die Ausgabe an und speichern Sie sie mit dem Befehl tee in einer Datei, um sie später zu bearbeiten. Exportieren Sie beispielsweise den Deskriptor eines example-project-OpenShift-Projekts:

    oc get project example-project -o yaml | tee project-example-project.yaml

    Die entsprechende Ausgabe sieht etwa so aus:

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

    Die Ausgabe zeigt den Deskriptor des OpenShift-Projekts example-project im YAML-Dateiformat an. Die Ausgabe wird in der Datei project-example-project.yaml gespeichert.

Clusterbezogene Ressourcendeskriptoren exportieren

In diesem Abschnitt wird beschrieben, wie Sie die Deskriptoren für Ressourcen mit einem Clusterbereich exportieren, ohne Sicherheitskontextbeschränkungen anzugeben. Informationen zum Migrieren von Sicherheitsrichtlinien finden Sie unter Von OpenShift zu GKE Enterprise migrieren: OpenShift-SCCs zu Richtlinien-Controller-Einschränkungen migrieren. So exportieren Sie andere Ressourcendeskriptoren für jeden OpenShift-Cluster:

  1. Rufen Sie in Ihrem Terminal die Liste der ClusterResourceQuotas ab:

    oc get clusterresourcequotas

    Die entsprechende Ausgabe sieht etwa so aus:

    NAME       AGE
for-name   6m15s
for-user   4s
...

    Die Ausgabe zeigt eine Liste der ClusterResourceQuotas an, die derzeit in Ihrem OpenShift-Cluster eingerichtet sind.

  2. Exportieren Sie für jedes ClusterResourceQuota in der Liste den Deskriptor im YAML-Dateiformat, rufen Sie die Ausgabe auf und speichern Sie sie zur späteren Verarbeitung in einer Datei. Exportieren Sie beispielsweise den Deskriptor des ClusterResourceQuota for-name:

    oc get clusterresourcequota for-name -o yaml | tee clusterresourcequota-for-name.yaml

    Die entsprechende Ausgabe sieht etwa so aus:

    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

    Die Ausgabe zeigt den Deskriptor des ClusterResourceQuota for-name im YAML-Format an. Die Ausgabe wird in der Datei clusterresourcequota-for-name.yaml gespeichert.

  3. Rufen Sie die Liste der ClusterRoles ab:

    oc get clusterroles

    Die entsprechende Ausgabe sieht etwa so aus:

    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
...

    Die Ausgabe zeigt eine Liste der ClusterRoles an, die derzeit in Ihrem OpenShift-Cluster eingerichtet sind. Die Liste der ClusterRoles enthält OpenShift-Standard-ClusterRoles und ClusterRoles, die sich auf OpenShift-Systemkomponenten beziehen. Wir empfehlen Ihnen, alle ClusterRoles in der Liste zu bewerten, um festzustellen, welche Rollen migriert werden müssen und welche Rollen in der GKE Enterprise-Zielumgebung nicht anwendbar sind.

  4. Exportieren Sie für jeden ClusterRole in der Liste den Deskriptor im YAML-Dateiformat, rufen Sie die Ausgabe auf und speichern Sie sie zur späteren Verarbeitung in einer Datei. Exportieren Sie beispielsweise den Deskriptor der ClusterRole admin:

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

    Die entsprechende Ausgabe sieht etwa so aus:

    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
...

    Die Ausgabe zeigt den Deskriptor der ClusterRole admin im YAML-Format an. Die Ausgabe wird in der Datei clusterrole-admin.yaml gespeichert.

  5. Rufen Sie die Liste der ClusterRoleBindings ab:

    oc get clusterrolebindings

    Die entsprechende Ausgabe sieht etwa so aus:

    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
...

    Die Ausgabe zeigt eine Liste der ClusterRoleBindings an, die derzeit in Ihrem OpenShift-Cluster eingerichtet sind. Die Liste der ClusterRoleBindings enthält ClusterRoleBindings, die sich auf OpenShift-Systemkomponenten beziehen. Wir empfehlen Ihnen, alle ClusterRoleBindings in der Liste zu bewerten, um festzustellen, welche Bindungen migriert werden müssen und welche Bindungen in der GKE Enterprise-Zielumgebung nicht anwendbar sind.

  6. Exportieren Sie für jede ClusterRoleBinding in der Liste den Deskriptor im YAML-Dateiformat, rufen Sie die Ausgabe auf und speichern Sie sie zur späteren Verarbeitung in einer Datei. Exportieren Sie beispielsweise den Deskriptor der ClusterRoleBinding cluster-admin:

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

    Die entsprechende Ausgabe sieht etwa so aus:

    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

    Die Ausgabe zeigt den Deskriptor der ClusterRoleBinding cluster-admin im YAML-Format an. Die Ausgabe wird in der Datei clusterrolebinding-cluster-admin.yaml gespeichert.

Benutzerdefinierte NetNamespaces exportieren

In diesem Abschnitt wird beschrieben, wie Sie die Konfiguration der mandantenfähigen Umgebung bewerten. Dieser Abschnitt gilt, wenn Sie benutzerdefinierte NetNamespaces für ein OpenShift-Projekt in Ihrem Cluster erstellt haben, um Netzwerk-Namespaces zu isolieren oder zu verbinden. Wenn Sie keine benutzerdefinierten NetNamespaces erstellt haben, fahren Sie mit Projektbezogene Ressourcendeskriptoren exportieren fort.

OpenShift erstellt und verwaltet NetNamespaces für verwaltete OpenShift-Projekte automatisch. Dieser Abschnitt gilt, wenn Sie benutzerdefinierte NetNamespaces für ein OpenShift-Projekt in Ihrem Cluster erstellt haben, um Netzwerk-Namespaces zu isolieren oder zu verbinden.

So exportieren Sie benutzerdefinierte NetNamespaces:

  1. Rufen Sie die Liste der NetNamespaces ab:

    oc get netnamespaces

    Die entsprechende Ausgabe sieht etwa so aus:

    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
...

    Die Ausgabe zeigt eine Liste der NetNamespaces an, die derzeit in Ihrem OpenShift-Cluster eingerichtet sind.

  2. Exportieren Sie für jeden NetNamespace in der Liste den Deskriptor im YAML-Dateiformat, rufen Sie die Ausgabe auf und speichern Sie sie zur späteren Verarbeitung in einer Datei. Exportieren Sie beispielsweise den Deskriptor von dem default NetNamespace:

    oc get netnamespace example-project -o yaml | tee netnamespace-example-project.yaml

    Bei NetNamespaces, die nicht demselben netid-Wert haben, sieht die Ausgabe etwa so aus:

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

    Die Ausgabe zeigt den Deskriptor des NetNamespaces example-project im YAML-Dateiformat an. Die Ausgabe wird in der Datei netnamespace-example-project.yaml gespeichert.

    Bei NetNamespaces mit demselben netid-Wert sieht die Ausgabe etwa so aus:

    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

Projektbezogene Ressourcendeskriptoren exportieren

Sie exportieren die Deskriptoren für Ressourcen mit einem Projektbereich, indem Sie für jedes OpenShift-Projekt Folgendes tun.

  1. Wählen Sie in Ihrem Terminal das OpenShift-Projekt aus, das Sie bewerten möchten. Wählen Sie beispielsweise das OpenShift-Projekt example-project aus:

    oc project example-project

  2. Rufen Sie die Liste der ResourceQuotas ab:

    oc get resourcequotas

    Die entsprechende Ausgabe sieht etwa so aus:

    NAME        AGE   REQUEST                        LIMIT
gpu-quota   6s    requests.nvidia.com/gpu: 1/1
...

    Die Ausgabe zeigt eine Liste von ResourceQuotas an, die derzeit in Ihrem OpenShift-Cluster für das ausgewählte OpenShift-Projekt eingerichtet sind.

  3. Exportieren Sie für jedes ResourceQuota in der Liste den Deskriptor im YAML-Format, rufen Sie die Ausgabe auf und speichern Sie sie zur späteren Verarbeitung in einer Datei. Exportieren Sie beispielsweise den Deskriptor des ResourceQuota gpu-quota:

    oc get resourcequota gpu-quota -o yaml | tee resourcequota-gpu-quota.yaml

    Die entsprechende Ausgabe sieht etwa so aus:

    apiVersion: v1
kind: ResourceQuota
metadata:
  name: gpu-quota
  namespace: example-project
spec:
  hard:
    requests.nvidia.com/gpu: "1"

    Die Ausgabe zeigt den Deskriptor des ResourceQuota gpu-quota im YAML-Dateiformat an. Die Ausgabe wird in der Datei resourcequota-gpu-quota.yaml gespeichert.

  4. Rufen Sie die Liste der Roles ab:

    oc get roles

    Die entsprechende Ausgabe sieht etwa so aus:

    NAME             CREATED AT
example          2021-02-02T06:48:27Z

...

    Die Ausgabe zeigt eine Liste von Roles an, die derzeit in Ihrem OpenShift-Cluster für das ausgewählte OpenShift-Projekt eingerichtet sind. Die Liste der Roles enthält Roles, die auf Systemkomponenten von OpenShift verweisen. Wir empfehlen Ihnen, alle Roles in der Liste zu bewerten, um festzustellen, welche Roles migriert werden müssen und welche Roles in der GKE Enterprise-Zielumgebung nicht anwendbar sind.

  5. Exportieren Sie für jeden Role in der Liste den Deskriptor im YAML-Dateiformat, rufen Sie die Ausgabe auf und speichern Sie sie zur späteren Verarbeitung in einer Datei. Exportieren Sie beispielsweise den Deskriptor von der Role example :

    oc get role example -o yaml | tee role-example.yaml

    Die entsprechende Ausgabe sieht etwa so aus:

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: example
  namespace: example-project
rules:
- apiGroups:
  - ""
  resources:
  - services
  - endpoints
  - pods
  verbs:
  - get
  - list
  - watch

    Die Ausgabe zeigt den Deskriptor der Role example im YAML-Dateiformat an. Die Ausgabe wird in der Datei role-example.yaml gespeichert.

  6. Rufen Sie die Liste der RoleBindings ab:

    oc get rolebindings

    Die entsprechende Ausgabe sieht etwa so aus:

    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
...

    Die Ausgabe zeigt eine Liste von RoleBindings an, die in Ihrem OpenShift-Cluster für das ausgewählte OpenShift-Projekt eingerichtet sind. Die Liste der RoleBindings enthält RoleBindings, die auf Systemkomponenten von OpenShift verweisen. Wir empfehlen Ihnen, alle RoleBindings in der Liste zu bewerten, um festzustellen, welche Bindungen migriert werden müssen und welche Bindungen in der GKE Enterprise-Zielumgebung nicht anwendbar sind.

  7. Exportieren Sie für jede RoleBinding in der Liste den Deskriptor im YAML-Dateiformat, rufen Sie die Ausgabe auf und speichern Sie sie zur späteren Verarbeitung in einer Datei. Exportieren Sie beispielsweise den Deskriptor der RoleBinding example:

    oc get rolebinding example -o yaml | tee rolebinding-example.yaml

    Die entsprechende Ausgabe sieht etwa so aus:

    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

    Die Ausgabe zeigt den Deskriptor der RoleBinding example im YAML-Format an. Die Ausgabe wird in der Datei rolebinding-example.yaml gespeichert.

  8. Rufen Sie die Liste der EgressNetworkPolicies ab:

    oc get egressnetworkpolicies

    Die entsprechende Ausgabe sieht etwa so aus:

    NAME      AGE
default   2m2s
...

    Die Ausgabe zeigt eine Liste von EgressNetworkPolicies an, die derzeit in Ihrem OpenShift-Cluster für das ausgewählte OpenShift-Projekt eingerichtet sind.

  9. Exportieren Sie für jeden EgressNetworkPolicy in der Liste den Deskriptor im YAML-Dateiformat, rufen Sie die Ausgabe auf und speichern Sie sie zur späteren Verarbeitung in einer Datei. Exportieren Sie beispielsweise den Deskriptor der EgressNetworkPolicy default:

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

    Die entsprechende Ausgabe sieht etwa so aus:

    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

    Die Ausgabe zeigt den Deskriptor der EgressNetworkPolicy default im YAML-Format an. Die Ausgabe wird auch in der Datei egressnetworkpolicy-default.yaml gespeichert.

  10. Rufen Sie die Liste der NetworkPolicies ab:

    oc get networkpolicies

    Die entsprechende Ausgabe sieht etwa so aus:

    NAME          POD-SELECTOR   AGE
test-policy   app=mongodb    3s
...

    Die Ausgabe zeigt eine Liste von NetworkPolicies an, die derzeit in Ihrem OpenShift-Cluster für das ausgewählte OpenShift-Projekt eingerichtet sind.

  11. Exportieren Sie für jeden NetworkPolicy in der Liste den Deskriptor im YAML-Dateiformat, rufen Sie die Ausgabe auf und speichern Sie sie zur späteren Verarbeitung in einer Datei. Exportieren Sie beispielsweise den Deskriptor der test-policy NetworkPolicy:

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

    Die entsprechende Ausgabe sieht etwa so aus:

    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

    Die Ausgabe zeigt den Deskriptor der NetworkPolicy test-policy im YAML-Dateiformat an. Die Ausgabe wird in der Datei networkpolicy-test-policy.yaml gespeichert.

OpenShift-Projektkonfiguration-Ressourcen Kubernetes-Ressourcen zuordnen

Nachdem Sie das Inventar der OpenShift-Projekt-Konfigurationsressourcen abgeschlossen haben, bewerten Sie diese Ressourcen so:

  1. Ermitteln Sie, welche Ressourcen im Inventar Kubernetes-Ressourcen und welche OpenShift-Ressourcen sind.
  2. Ordnen Sie OpenShift-Ressourcen ihren Kubernetes-, GKE- und GKE Enterprise-Entsprechungen zu.

Anhand der folgenden Liste können Sie feststellen, welche Ressourcen, die Sie in Ihren OpenShift-Clustern bereitgestellt haben, Kubernetes-Ressourcen sind und Welche Ressourcen sind nur in OpenShift verfügbar:

  • OpenShift-Projekte sind Kubernetes-Namespaces mit zusätzlichen Annotationen.
  • Roles, ClusterRoles, RoleBindings und ClusterRoleBindings sind Kubernetes-Ressourcen.
  • ResourceQuotas sind Kubernetes-Ressourcen.
  • NetworkPolicies sind Kubernetes-Ressourcen.
  • ClusterResourceQuotas sind keine Kubernetes-Ressourcen, sie sind nur in OpenShift verfügbar.
  • NetNamespaces und EgressNetworkPolicies sind keine Kubernetes-Ressourcen. Sie sind nur in OpenShift verfügbar.

Die folgende Tabelle enthält eine Zusammenfassung darüber, wie Sie OpenShift-Projektkonfigurationsressourcen den Ressourcen zuordnen, die Sie in GKE Enterprise verwendet haben.

OpenShift GKE Enterprise
Projekte Konvertierung in Kubernetes-Namespaces mit zusätzlichen Annotationen
Roles, ClusterRoles, RoleBindings und ClusterRoleBindings Kubernetes RBAC-Ressourcen
ResourceQuotas Kubernetes RBAC-Ressourcen
ClusterResourceQuotas Konvertierung in ResourceQuotas oder Verwendung hierarchischer Ressourcenkontingente
NetworkPolicies Kubernetes-Netzwerkressourcen
NetNamespaces, EgressNetworkPolicies Umwandlung in NetworkPolicies

Nachdem Sie die Ressourcen aus Ihrer OpenShift-Umgebung ausgewertet haben, ordnen Sie die OpenShift-Ressourcen den Ressourcen zu, die Sie in GKE und GKE Enterprise bereitstellen und konfigurieren können. Sie müssen die Kubernetes-Ressourcen, die Sie in Ihren OpenShift-Clustern verwenden, nicht zuordnen, da GKE Enterprise sie direkt unterstützt. Wie unter Zusammenfassung der Funktionszuordnung von OpenShift zu GKE Enterprise beschrieben, empfehlen wir, Folgendes zuzuordnen:

  • OpenShift-Projekte zu Kubernetes-Namespaces
  • ClusterResourceQuotas zu ResourceQuotas.
  • NetNamespaces und EgressNetworkPolicies zu NetworkPolicies

Kubernetes-Ressourcen erstellen, die den OpenShift-Projekt-Konfigurationsressourcen zugeordnet werden

Nachdem Sie die Zuordnung abgeschlossen haben, erstellen Sie die Kubernetes-Ressourcen, die Sie Ihren OpenShift-Ressourcen zugeordnet haben. Wir empfehlen Ihnen, Folgendes zu erstellen:

  • Einen Kubernetes-Namespace für jedes OpenShift-Projekt
  • Ein ResourceQuota für jeden Kubernetes-Namespace, den Ihre ClusterResourceQuotas begrenzen.
  • NetworkPolicies, die zu Ihren NetNamespaces und EgressNetworkPolicies passen.

Kubernetes-Namespaces erstellen

OpenShift-Projekte sind Kubernetes-Namespaces mit zusätzlichen Annotationen. Die OpenShift project API entspricht weitgehend der Kubernetes Namespace API. Zum Migrieren Ihrer OpenShift-Projekte empfehlen wir die Erstellung eines Kubernetes-Namespaces für jedes OpenShift-Projekt. Da die APIs kompatibel sind, können Sie einen Kubernetes-Namespace aus einem OpenShift-Projekt erstellen.

Um einen Kubernetes Namespace aus einem OpenShift-Projekt zu erstellen, empfehlen wir, die Werte im OpenShift-Projektdeskriptor auf die entsprechende Kubernetes Namespace API-Version für jedes OpenShift-Projekt zu ändern. Ändern Sie dazu den Wert des Feldes apiVersion im OpenShift-Projektdeskriptor von der API-Version des OpenShift-Projektobjekts und den Wert des Feldes kind auf die entsprechende API-Version des Kubernetes-Namespace-Objekts. Das im vorherigen Abschnitt geprüfte OpenShift-Projekt sieht beispielsweise so aus:

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

Um das Projekt zu migrieren, ändern Sie den Feldwert apiVersion von project.openshift.io/v1 in v1 und den Feldwert kind von Project in Namespace:

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

Kubernetes-ResourceQuotas erstellen

Mit OpenShift-ClusterResourceQuotas können Sie Kontingente für mehrere OpenShift-Projekte freigeben. Wenn Sie ein ClusterResourceQuota erstellen, definieren Sie das Kontingent und definieren den Selektor zum Abgleich von OpenShift-Projekten, für die Sie das Kontingent erzwingen möchten. In diesem Abschnitt migrieren Sie Ihre OpenShift-ClusterResourceQuotas zu Kubernetes-ResourceQuotas in den Namespaces, die Sie zuvor erstellt haben.

Zum Migrieren Ihrer ClusterResourceQuotas empfehlen wir die folgenden Schritte für jedes ClusterResourceQuota:

  1. Ordnen Sie das ClusterResourceQuota zu OpenShift-Projekten zu. Bewerten Sie dazu das Feld spec.quota und das Feld spec.selector des ClusterResourceQuota. Das im vorherigen Abschnitt exportierte ClusterResourceQuota for-name sieht beispielsweise so aus:

    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

    Das ClusterResourceQuota for-name erzwingt Pod- und Secret-Kontingentlimits. Das Feld spec.selector erzwingt diese Limits für das OpenShift-Projekt frontend.

  2. Unter Kubernetes-Namespace erstellen haben Sie bereits Kubernetes-Namespaces erstellt, die Ihren OpenShift-Projekten entsprechen. Verwenden Sie diese Informationen, um das ClusterResourceQuota den neuen Kubernetes-Namespaces zuzuordnen. Das OpenShift-Projekt frontend enthält beispielsweise das ClusterResourceQuota for-name. Das Projekt entspricht dem Kubernetes-Namespace frontend. Daher ordnen Sie das ClusterResourceQuota for-name dem Kubernetes-Namespace frontend zu.

  3. Teilen Sie für jede Kontingentdefinition im Feld quota des ClusterResourceQuota den Kontingentmenge unter den Kubernetes-Namespaces auf, denen Sie das ClusterResourceQuota zugeordnet haben, gemäß den gewünschten Kriterien. Beispielsweise können Sie die vom ClusterResourceQuota for-name festgelegten Kontingentmengen gleichmäßig auf die Kubernetes-Namespaces frontend aufteilen.

  4. Für jeden Kubernetes-Namespace, den Sie dem ClusterResourceQuota zugeordnet haben, erstellen Sie ein Kubernetes-ResourceQuota, das das Kontingent für diesen Namespace durchsetzt. Sie legen die Kontingente gemäß den Informationen fest, die Sie im vorherigen Schritt erfasst haben. Erstellen Sie beispielsweise ein ResourceQuota für den Kubernetes-Namespace frontend:

    apiVersion: v1
kind: ResourceQuota
metadata:
  name: pods-secrets
  namespace: frontend
spec:
  hard:
    pods: "10"
    secrets: "20"

    Ein weiteres Beispiel: Sie verknüpfen das ClusterResourceQuota for-name mit zwei unterschiedlichen Kubernetes-Namespaces, example-1 und example-2. Um die Zuordnung abzuschließen, teilen Sie die Ressourcen gleichmäßig auf diese auf. Erstellen Sie dazu ein ResourceQuota für die Kubernetes-Namespaces. Weisen Sie die erste Hälfte des ResourceQuota zu:

    apiVersion: v1
kind: ResourceQuota
metadata:
  name: pods-secrets
  namespace: example-1
spec:
  hard:
    pods: "5"
    secrets: "10"

    Nachdem Sie die erste Hälfte des ResourceQuota zugewiesen haben, weisen Sie dann die zweite Hälfte des ResourceQuota zu:

    apiVersion: v1
kind: ResourceQuota
metadata:
  name: pods-secrets
  namespace: example-2
spec:
  hard:
    pods: "5"
    secrets: "10"

    Mit diesem Ansatz können Sie Limits für jeden Kubernetes-Namespace erzwingen, in dem Sie ResourceQuotas erstellen, anstatt ein einzelnes Limit für mehrere Kubernetes-Namespaces festzulegen.

Die Verwendung von ResourceQuotas zum Erzwingen von Kontingenten für Ihre Kubernetes-Namespaces ist nicht das gleiche wie die Verwendung eines ClusterResourceQuota zum Erzwingen eines Kontingents für alle Kubernetes-Namespaces. Die Aufteilung eines clusterbezogenen Kontingents auf verschiedene Kubernetes-Namespaces könnte suboptimal sein: Die Aufteilung könnte möglicherweise Kontingente für einige Kubernetes-Namespaces überdimensionieren und Kontingente für andere Kubernetes-Namespaces nicht ausreichend bereitstellen.

Wir empfehlen Ihnen, die Kontingentzuweisung zu optimieren. Optimieren Sie dazu die Konfiguration der ResourceQuotas in Ihren Kubernetes-Namespaces dynamisch und berücksichtigen Sie dabei das gesamte Menge an Kontingent, die das korrespondierende ClusterResourceQuota geschaffen hat. Sie können beispielsweise die Kontingentmengen, die durch diepods-secrets ResourceQuotas erzwungen werden, dynamisch erhöhen oder senken, um eine Über- oder Unterdimensionierung von Kontingentmengen für die example-1 und example-2 Kubernetes-Namespaces zu vermeiden: Die Gesamtkontingentmengen für die pods-secrets-ResourceQuotas sollten die Kontingentmengen im entsprechenden ClusterResourceQuota nicht überschreiten.

Berücksichtigen Sie beim Konfigurieren Ihrer ResourceQuotas GKE-Kontingente und -Limits und GKE auf VMware-Kontingente und -Limits. Diese Kontingente und Limits können niedrigere Limits als Ihre ResourceQuotas festlegen. Beispielsweise begrenzt GKE die maximale Anzahl an Pods pro Knoten, unabhängig davon, wie Sie Ihre ResourceQuotas konfiguriert haben.

NetworkPolicies erstellen

Mit OpenShift-NetNamespaces können Sie die Netzwerkisolation zwischen OpenShift-Projekten konfigurieren. Mit OpenShift EgressNetworkPolicies können Sie ausgehenden Traffic steuern, der Ihre OpenShift-Cluster verlässt. Dieser Abschnitt basiert auf Konzepten zur Traffic-Einschränkung.

So migrieren Sie Ihre NetNamespaces und EgressNetworkPolicies:

  1. Prüfen Sie Ihre NetNamespaces und EgressNetworkPolicies, um zu verstehen, wie sie den Netzwerktraffic zwischen OpenShift-Projekten und ausgehendem Traffic regeln, der Ihre OpenShift-Cluster verlässt. Prüfen Sie beispielsweise den NetNamespace und die EgressNetworkPolicy, die Sie im vorherigen Abschnitt exportiert haben:

    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

    Die NetNamespaces example-project und example-project-2 definieren ein Overlay-Netz mit demselben netid-Wert von 1234. Daher können Pods im OpenShift-Projekt example-project mit Pods im OpenShift-Projekt example-project-2 und umgekehrt kommunizieren.

    Die EgressNetworkPolicy default definiert die folgenden Regeln für ausgehenden Netzwerktraffic:

    • Lassen Sie ausgehenden Traffic zum Subnetz 1.2.3.0/24 zu.
    • Verweigern Sie ausgehenden Traffic, der nicht mit anderen Regeln übereinstimmt.

  2. Erstellen Sie NetworkPolicies und OPA-Richtlinien, die Ihren Anforderungen an den Netzwerktraffic entsprechen. Beispielsweise implementieren default-np und default-np-2 die folgenden Richtlinien:

    • Die Richtlinien, die durch die EgressNetworkPolicy default erzwungen werden.
    • Die Richtlinien, die von den NetNamespaces example-project und example-project-2 auf Namespaces erzwungen werden, deren netid-Label auf example-project und example-project-2 festgelegt ist:

    Die Richtlinien sehen in etwa so aus:

    ---
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

Kubernetes-Ressourcen mit Config Sync verwalten

Zum Verwalten der Kubernetes-Ressourcen und der Konfiguration Ihrer GKE Enterprise-Cluster empfehlen wir die Verwendung von Config Sync.

Informationen zum Aktivieren von Config Sync in Ihren GKE-Clustern finden Sie unter Config Sync installieren.

Nachdem Sie Config Sync in Ihrer GKE Enterprise-Umgebung bereitgestellt und konfiguriert haben, können Sie damit Konfigurationen erstellen und sie automatisch auf Ihre GKE-Cluster anwenden.

Nächste Schritte