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:
- Container zu Google Cloud migrieren: Kubernetes zu Google Kubernetes Engine (GKE) migrieren
- Container zu Google Cloud migrieren: Von OpenShift zu GKE Enterprise migrieren
- Container zu Google Cloud migrieren: OpenShift-Projekte zu GKE Enterprise migrieren (dieses Dokument)
- Von OpenShift zu GKE Enterprise migrieren: OpenShift-SCCs zu Richtlinien-Controller-Einschränkungen migrieren
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:
- OpenShift-Projekte
- Ressourcenkontingente für jedes OpenShift-Projekt und Ressourcenkontingente für mehrere OpenShift-Projekte
- Roles und ClusterRoles
- RoleBindings und ClusterRoleBindings
- Konfiguration von OpenShift-Netzwerk-Namespaces und NetworkPolicies
So migrieren Sie die OpenShift-Projektkonfiguration und die zugehörigen Ressourcen nach GKE Enterprise:
- OpenShift-Projektkonfiguration-Ressourcendeskriptoren exportieren
- OpenShift-Projektkonfiguration-Ressourcen Kubernetes-Ressourcen zuordnen
- Kubernetes-Ressourcen erstellen, die den OpenShift-Projekt-Konfigurationsressourcen zugeordnet werden
- 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:
- OpenShift-Projektdeskriptoren exportieren.
- Exportieren Sie clusterbezogene Ressourcendeskriptoren.
- 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:
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äfixopenshift.io
beginnen metadata.creationTimestamp
metadata.generation
metadata.managedFields
metadata.resourceVersion
metadata.selfLink
metadata.uid
status
- Alle Felder, die unter
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:
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.
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 einesexample-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 Dateiproject-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:
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.
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 Dateiclusterresourcequota-for-name.yaml
gespeichert.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.
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 Dateiclusterrole-admin.yaml
gespeichert.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.
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 Dateiclusterrolebinding-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:
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.
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 Dateinetnamespace-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.
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
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.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 Dateiresourcequota-gpu-quota.yaml
gespeichert.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.
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 Dateirole-example.yaml
gespeichert.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.
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 Dateirolebinding-example.yaml
gespeichert.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.
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 Dateiegressnetworkpolicy-default.yaml
gespeichert.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.
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 Dateinetworkpolicy-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:
- Ermitteln Sie, welche Ressourcen im Inventar Kubernetes-Ressourcen und welche OpenShift-Ressourcen sind.
- 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:
Ordnen Sie das ClusterResourceQuota zu OpenShift-Projekten zu. Bewerten Sie dazu das Feld
spec.quota
und das Feldspec.selector
des ClusterResourceQuota. Das im vorherigen Abschnitt exportierte ClusterResourceQuotafor-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 Feldspec.selector
erzwingt diese Limits für das OpenShift-Projektfrontend
.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 ClusterResourceQuotafor-name
. Das Projekt entspricht dem Kubernetes-Namespacefrontend
. Daher ordnen Sie das ClusterResourceQuotafor-name
dem Kubernetes-Namespacefrontend
zu.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 ClusterResourceQuotafor-name
festgelegten Kontingentmengen gleichmäßig auf die Kubernetes-Namespacesfrontend
aufteilen.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
undexample-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:
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
undexample-project-2
definieren ein Overlay-Netz mit demselbennetid
-Wert von1234
. Daher können Pods im OpenShift-Projektexample-project
mit Pods im OpenShift-Projektexample-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.
- Lassen Sie ausgehenden Traffic zum Subnetz
Erstellen Sie NetworkPolicies und OPA-Richtlinien, die Ihren Anforderungen an den Netzwerktraffic entsprechen. Beispielsweise implementieren
default-np
unddefault-np-2
die folgenden Richtlinien:- Die Richtlinien, die durch die EgressNetworkPolicy
default
erzwungen werden. - Die Richtlinien, die von den NetNamespaces
example-project
undexample-project-2
auf Namespaces erzwungen werden, derennetid
-Label aufexample-project
undexample-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
- Die Richtlinien, die durch die EgressNetworkPolicy
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
- Erste Schritte bei der Migration zu Google Cloud
- Best Practices zum Erstellen und Betreiben von Containern.
- Best Practices für GKE-Netzwerke
- Sicherheit des Clusters erhöhen
- GKE-Sicherheitsübersicht lesen
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center