Migrazione dei container in Google Cloud: migrazione dei progetti OpenShift in GKE Enterprise

Last reviewed 2022-01-24 UTC

Questo documento ti aiuta a pianificare, progettare e implementare la migrazione dei tuoi progetti da OpenShift a GKE Enterprise. Se eseguito in modo errato, spostare i carichi di lavoro da un ambiente all'altro può essere un'attività impegnativa, quindi pianifica ed esegui la migrazione con attenzione.

Questo documento fa parte di una serie in più parti sulla migrazione a Google Cloud. Se ti interessa una panoramica della serie, consulta Migrazione a Google Cloud: scelta del percorso di migrazione.

Questo documento fa parte di una serie che illustra la migrazione dei containers a Google Cloud:

Questo documento è utile se prevedi di eseguire la migrazione dei progetti OpenShift a GKE Enterprise. Questo documento è utile anche se stai valutando l'opportunità di eseguire la migrazione e vuoi esplorare il possibile aspetto.

Questo documento si basa sui concetti discussi in Migrazione a Google Cloud: Introduzione, Migrazione dei container in Google Cloud: migrazione di Kubernetes a GKE in Migrazione dei container in Google Cloud: migrazione da OpenShift a GKE Enterprise e Best practice per il networking di GKE. Questo documento rimanda ai documenti precedenti, ove appropriato.

Le indicazioni contenute in questo documento presuppongono che tu voglia eseguire una migrazione lift and shift dei carichi di lavoro. In una migrazione lift and shift, applichi solo le modifiche minime necessarie per far funzionare i carichi di lavoro nell'ambiente GKE Enterprise di destinazione.

Per eseguire la migrazione delle risorse OpenShift in GKE Enterprise, devi mapparle e convertirle nei loro equivalenti Kubernetes. Questo documento descrive la migrazione delle seguenti risorse di configurazione del progetto OpenShift necessarie per eseguire il deployment e il funzionamento dei carichi di lavoro in GKE Enterprise:

Per eseguire la migrazione della configurazione del progetto OpenShift e delle risorse correlate a GKE Enterprise, ti consigliamo di:

  1. Esporta i descrittori delle risorse di configurazione del progetto OpenShift.
  2. Mappa le risorse di configurazione del progetto OpenShift alle risorse Kubernetes.
  3. Creare risorse Kubernetes associate alle risorse di configurazione del progetto OpenShift.
  4. Gestire le risorse Kubernetes con Config Sync.

Questo documento fornisce esempi di come completare i passaggi della migrazione.

Esporta i descrittori delle risorse di configurazione del progetto OpenShift

Per esportare le risorse di configurazione del progetto OpenShift, ti consigliamo di fare quanto segue:

  1. Esporta i descrittori del progetto OpenShift.
  2. Esporta descrittori delle risorse con ambito cluster.
  3. Esporta i descrittori delle risorse con ambito a livello di progetto.

I descrittori esportati da un cluster OpenShift includono campi che descrivono la configurazione e lo stato delle risorse, ad esempio i campi spec e status. I descrittori includono anche campi contenenti informazioni sullo stato delle risorse, come il campo metadata.managedFields. Kubernetes e OpenShift gestiscono automaticamente i campi che contengono le informazioni sullo stato delle risorse e i relativi valori. Per semplificare la valutazione dei descrittori delle risorse OpenShift, ti consigliamo di seguire questi passaggi per ogni descrittore di risorsa:

  1. Registra i campi che contengono le informazioni sullo stato delle risorse generate dinamicamente insieme ai relativi valori, ad esempio quanto segue:

    • Qualsiasi campo nidificato sotto metadata.annotations che inizia con il prefisso openshift.io
    • metadata.creationTimestamp
    • metadata.generation
    • metadata.managedFields
    • metadata.resourceVersion
    • metadata.selfLink
    • metadata.uid
    • status

  2. Rimuovi dal descrittore della risorsa i campi che contengono le informazioni sullo stato delle risorse generate dinamicamente.

Per esportare i descrittori delle risorse di configurazione del progetto OpenShift, utilizza l'interfaccia a riga di comando di OpenShift (interfaccia a riga di comando oc). Per esportare i descrittori delle risorse nell'interfaccia a riga di comando oc, devi eseguire l'autenticazione con il ruolo cluster-admin. Per un elenco di tutte le risorse OpenShift supportate dall'interfaccia a riga di comando oc, esegui il comando oc api-resources.

Esporta descrittori progetto OpenShift

Questa sezione descrive come esportare i descrittori del progetto. Ti consigliamo di escludere i progetti OpenShift che eseguono componenti di sistema, come il componente istio-system, ed escludere i progetti OpenShift i cui nomi iniziano con openshift-, kube- o knative-. OpenShift gestisce questi progetti OpenShift per te, che non rientrano nell'ambito di questa migrazione perché non li utilizzi per eseguire il deployment dei carichi di lavoro. Per esportare i descrittori del progetto OpenShift, procedi nel seguente modo per ogni cluster OpenShift:

  1. In un terminale che ha accesso al cluster OpenShift, recupera l'elenco dei progetti OpenShift utilizzando il comando oc get:

    oc get projects

    L'output è simile al seguente:

    NAME                 DISPLAY NAME      STATUS
example-project                        Active
...

    L'output mostra un elenco dei progetti OpenShift attualmente configurati nel cluster OpenShift.

  2. Per ogni progetto OpenShift nell'elenco, esporta il descrittore in formato file YAML, visualizza l'output e salvalo in un file utilizzando il comando tee, per elaborarlo in un secondo momento. Ad esempio, esporta il descrittore di un progetto OpenShift example-project:

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

    L'output è simile al seguente:

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

    L'output mostra il descrittore del progetto OpenShift example-project in formato file YAML. L'output viene salvato nel file project-example-project.yaml.

Esporta descrittori delle risorse con ambito cluster

Questa sezione descrive come esportare i descrittori per le risorse che hanno un ambito cluster, esclusi i vincoli del contesto di sicurezza. Per informazioni sulla migrazione dei criteri di sicurezza, consulta Migrazione da OpenShift a GKE Enterprise: migrazione delle SCC di OpenShift ai vincoli di Policy Controller. Per esportare altri descrittori delle risorse, segui questi passaggi per ogni cluster OpenShift:

  1. Nel terminale, recupera l'elenco di ClusterResourceQuotas:

    oc get clusterresourcequotas

    L'output è simile al seguente:

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

    L'output mostra un elenco di ClusterResourceQuotas attualmente configurate nel tuo cluster OpenShift.

  2. Per ogni ClusterResourceQuota nell'elenco, esporta il descrittore in formato file YAML, visualizza l'output e salvalo in un file per elaborarlo in un secondo momento. Ad esempio, esporta il descrittore della quota for-nameClusterResourceQuota:

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

    L'output è simile al seguente:

    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

    L'output mostra il descrittore di for-nameClusterResourceQuota in formato YAML. L'output viene salvato nel file clusterresourcequota-for-name.yaml.

  3. Recupera l'elenco di ClusterRoles:

    oc get clusterroles

    L'output è simile al seguente:

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

    L'output mostra un elenco di ClusterRoles attualmente configurati nel cluster OpenShift. L'elenco di ClusterRoles include ClusterRoles predefiniti di OpenShift e ClusterRoles che fanno riferimento ai componenti di sistema OpenShift. Ti consigliamo di valutare tutti i ClusterRole nell'elenco per valutare i ruoli di cui devi eseguire la migrazione e quelli non applicabili nell'ambiente GKE Enterprise di destinazione.

  4. Per ogni ClusterRole nell'elenco, esporta il relativo descrittore in formato file YAML, visualizza l'output e salvalo in un file per elaborarlo in un secondo momento. Ad esempio, esporta il descrittore del ClusterRole admin:

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

    L'output è simile al seguente:

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

    L'output mostra il descrittore del ClusterRole admin in formato YAML. L'output viene salvato nel file clusterrole-admin.yaml.

  5. Recupera l'elenco di ClusterRoleBindings:

    oc get clusterrolebindings

    L'output è simile al seguente:

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

    L'output mostra un elenco di ClusterRoleBinding attualmente configurati nel cluster OpenShift. L'elenco di ClusterRoleBinding include ClusterRoleBinding che fanno riferimento ai componenti di sistema OpenShift. Ti consigliamo di valutare tutti i ClusterRoleBinding nell'elenco per valutare quali associazioni devi eseguire la migrazione e quali associazioni non sono applicabili nell'ambiente GKE Enterprise di destinazione.

  6. Per ogni ClusterRoleBinding nell'elenco, esporta il descrittore in formato file YAML, visualizza l'output e salvalo in un file per elaborarlo in un secondo momento. Ad esempio, esporta il descrittore del ruolo cluster-adminClusterRoleBinding:

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

    L'output è simile al seguente:

    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

    L'output visualizza il descrittore di cluster-adminClusterRoleBinding in formato YAML. L'output viene salvato nel file clusterrolebinding-cluster-admin.yaml.

Esporta NetNamespace personalizzati

Questa sezione descrive come valutare la configurazione dell'isolamento multi-tenant. Questa sezione si applica se hai creato NetNamespaces personalizzati per qualsiasi progetto OpenShift nel cluster al fine di isolare o unire gli spazi dei nomi di rete. Se non hai creato spazi NetNamespace personalizzati, passa a Esporta descrittori delle risorse con ambito a livello di progetto.

OpenShift crea e gestisce automaticamente NetNamespaces per i progetti OpenShift gestiti. NetNamespaces per i progetti gestiti da OpenShift non rientra nell'ambito di questa migrazione.

Per esportare i NetNamespace personalizzati, segui questi passaggi:

  1. Recupera l'elenco di NetNamespaces:

    oc get netnamespaces

    L'output è simile al seguente.

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

    L'output mostra un elenco di NetNamespace attualmente configurati nel cluster OpenShift.

  2. Per ogni NetNamespace nell'elenco, esporta il descrittore in formato file YAML, visualizza l'output e salvalo in un file per elaborarlo in un secondo momento. Ad esempio, esporta il descrittore del default NetNamespace:

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

    Per i NetNamespace che non hanno lo stesso valore netid, l'output è simile al seguente:

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

    L'output visualizza il descrittore di NetNamespace example-project in formato file YAML. L'output viene salvato nel file netnamespace-example-project.yaml.

    Per NetNamespaces che hanno lo stesso valore netid, l'output è simile al seguente:

    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

Esporta descrittori delle risorse con ambito a livello di progetto

Per esportare i descrittori per le risorse che hanno un ambito di progetto, procedi come segue per ogni progetto OpenShift.

  1. Nel terminale, seleziona il progetto OpenShift che vuoi valutare. Ad esempio, seleziona il progetto example-project OpenShift:

    oc project example-project

  2. Ottieni l'elenco di ResourceQuotas:

    oc get resourcequotas

    L'output è simile al seguente:

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

    L'output mostra un elenco di ResourceQuotas attualmente configurati nel cluster OpenShift per il progetto OpenShift selezionato.

  3. Per ogni ResourceQuota nell'elenco, esporta il descrittore in formato YAML, visualizza l'output e salvalo in un file per elaborarlo in un secondo momento. Ad esempio, esporta il descrittore di gpu-quota ResourceQuota:

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

    L'output è simile al seguente:

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

    L'output mostra il descrittore di gpu-quota ResourceQuota in formato file YAML. L'output viene salvato nel file resourcequota-gpu-quota.yaml.

  4. Scarica l'elenco dei ruoli:

    oc get roles

    L'output è simile al seguente:

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

...

    L'output mostra un elenco di ruoli attualmente configurati nel cluster OpenShift per il progetto OpenShift selezionato. L'elenco di ruoli include quelli che fanno riferimento ai componenti di sistema OpenShift. Ti consigliamo di valutare tutti i ruoli nell'elenco per valutare quali ruoli è necessario eseguire la migrazione e quali non sono applicabili nell'ambiente GKE Enterprise di destinazione.

  5. Per ogni ruolo nell'elenco, esporta il descrittore in formato file YAML, visualizza l'output e salvalo in un file per elaborarlo in un secondo momento. Ad esempio, esporta il descrittore del ruolo example:

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

    L'output è simile al seguente:

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

    L'output mostra il descrittore del ruolo example in formato file YAML. L'output viene salvato nel file role-example.yaml.

  6. Scarica l'elenco di RoleBindings:

    oc get rolebindings

    L'output è simile al seguente:

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

    L'output mostra un elenco di RoleBinding configurati nel cluster OpenShift per il progetto OpenShift selezionato. L'elenco di RoleBindings include RoleBindings che fanno riferimento a componenti di sistema OpenShift. Ti consigliamo di valutare tutte le associazioni di ruoli nell'elenco per valutare quali associazioni devi eseguire la migrazione e quali associazioni non sono applicabili nell'ambiente GKE Enterprise di destinazione.

  7. Per ogni RoleBinding nell'elenco, esporta il relativo descrittore in formato file YAML, visualizza l'output e salvalo in un file per elaborarlo in un secondo momento. Ad esempio, esporta il descrittore di example RoleBinding:

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

    L'output è simile al seguente:

    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

    L'output visualizza il descrittore della RoleBinding example in formato file YAML. L'output viene salvato nel file rolebinding-example.yaml.

  8. Scarica l'elenco di EgressNetworkPolicies:

    oc get egressnetworkpolicies

    L'output è simile al seguente:

    NAME      AGE
default   2m2s
...

    L'output mostra un elenco di OutboundNetworkPolicies attualmente configurati nel cluster OpenShift per il progetto OpenShift selezionato.

  9. Per ogni OutboundNetworkPolicy nell'elenco, esporta il relativo descrittore in formato file YAML, visualizza l'output e salvalo in un file per elaborarlo in un secondo momento. Ad esempio, esporta il descrittore del criterio defaultOutboundNetworkPolicy:

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

    L'output è simile al seguente:

    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

    L'output mostra il descrittore di default OutboundNetworkPolicy in formato YAML. L'output viene salvato anche nel file egressnetworkpolicy-default.yaml.

  10. Scarica l'elenco di NetworkPolicies:

    oc get networkpolicies

    L'output è simile al seguente:

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

    L'output mostra un elenco di NetworkPolicies attualmente configurati nel cluster OpenShift per il progetto OpenShift selezionato.

  11. Per ogni NetworkPolicy nell'elenco, esporta il relativo descrittore in formato file YAML, visualizza l'output e salvalo in un file per elaborarlo in un secondo momento. Ad esempio, esporta il descrittore di NetworkPolicy test-policy:

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

    L'output è simile al seguente:

    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

    L'output mostra il descrittore di NetworkPolicy test-policy in formato file YAML. L'output viene salvato nel file networkpolicy-test-policy.yaml.

Mappare le risorse di configurazione del progetto OpenShift alle risorse Kubernetes

Dopo aver completato l'inventario delle risorse di configurazione del progetto OpenShift, le valuti come segue:

  1. Valuta quali risorse nell'inventario sono risorse Kubernetes e quali sono risorse OpenShift.
  2. Mappare le risorse OpenShift agli equivalenti Kubernetes, GKE e GKE Enterprise.

Il seguente elenco ti aiuta a valutare quali risorse di cui hai eseguito il provisioning nei tuoi cluster OpenShift sono risorse Kubernetes e quali risorse sono disponibili solo in OpenShift:

  • I progetti OpenShift sono spazi dei nomi Kubernetes con annotazioni aggiuntive.
  • I ruoli Role, ClusterRole, RoleBinding e ClusterRoleBinding sono risorse Kubernetes.
  • Le quote delle risorse sono risorse Kubernetes.
  • I criteri di rete sono risorse Kubernetes.
  • ClusterResourceQuotas non è una risorsa Kubernetes, ma è disponibile solo in OpenShift.
  • NetNamespaces e OutboundNetworkPolicies non sono risorse Kubernetes, sono disponibili solo in OpenShift.

La tabella seguente fornisce un riepilogo di come mappare le risorse di configurazione del progetto OpenShift alle risorse utilizzate in GKE Enterprise.

OpenShift GKE Enterprise
Progetti Converti in spazi dei nomi Kubernetes con annotazioni aggiuntive
Role, ClusterRoles, RoleBindings e ClusterRoleBinding Risorse Kubernetes RBAC
ResourceQuotas Risorse Kubernetes RBAC
ClusterResourceQuotas Converti in ResourceQuotas o utilizza quote delle risorse gerarchiche
NetworkPolicies Risorse per la rete Kubernetes
NetNamespaces, OutboundNetworkPolicies Converti in NetworkPolicies

Dopo aver valutato le risorse del tuo ambiente OpenShift, mappa le risorse OpenShift alle risorse di cui puoi eseguire il provisioning e configurare in GKE e GKE Enterprise. Non è necessario mappare le risorse Kubernetes che utilizzi nei cluster OpenShift perché GKE Enterprise le supporta direttamente. Come descritto in Riepilogo della mappatura delle funzionalità di OpenShift alla mappatura delle funzionalità di GKE Enterprise, ti consigliamo di mappare quanto segue:

  • tra progetti OpenShift e spazi dei nomi Kubernetes.
  • da ClusterResourceQuotas a ResourceQuotas.
  • NetNamespaces e OutboundNetworkPolicies a NetworkPolicies.

crea risorse Kubernetes mappate alle risorse di configurazione del progetto OpenShift

Dopo aver completato la mappatura, puoi creare le risorse Kubernetes che hai mappato alle tue risorse OpenShift. Ti consigliamo di creare i seguenti elementi:

  • Uno spazio dei nomi Kubernetes per ogni progetto OpenShift.
  • Una risorsa ResourceQuota per ogni spazio dei nomi Kubernetes limitato da ClusterResourceQuota.
  • NetworkPolicy corrispondenti a NetNamespaces e OutboundNetworkPolicies.

Creazione di spazi dei nomi Kubernetes

I progetti OpenShift sono spazi dei nomi Kubernetes con annotazioni aggiuntive. L'API OpenShift Project ha una corrispondenza molto simile all'API Kubernetes Namespace. Per eseguire la migrazione dei tuoi progetti OpenShift, ti consigliamo di creare uno spazio dei nomi Kubernetes per ogni progetto OpenShift. Poiché le API sono compatibili, puoi creare uno spazio dei nomi Kubernetes da un progetto OpenShift.

Per creare uno spazio dei nomi Kubernetes da un progetto OpenShift, ti consigliamo di modificare i valori nel descrittore del progetto OpenShift con la versione dell'API Kubernetes Namespace corrispondente per ogni progetto OpenShift. A questo scopo, modifica il valore del campo apiVersion nel descrittore del progetto OpenShift dalla versione dell'API dell'oggetto del progetto OpenShift e il valore del campo kind alla versione dell'API dell'oggetto Kubernetes Namespace corrispondente. Ad esempio, il progetto OpenShift che hai valutato nella sezione precedente è simile al seguente:

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

Per eseguire la migrazione del progetto, modifica il valore del campo apiVersion da project.openshift.io/v1 a v1 e modifica il valore del campo kind da Project a Namespace:

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

Creazione di ResourceQuotas per Kubernetes

OpenShift ClusterResourceQuotas consente di condividere le quote tra più progetti OpenShift. Quando crei una quota ClusterResourceQuota, definisci la quota e definisci il selettore in modo che corrisponda ai progetti OpenShift per i quali vuoi applicare la quota. In questa sezione, eseguirai la migrazione di OpenShift ClusterResourceQuotas a Kubernetes ResourceQuotas negli spazi dei nomi che hai creato in precedenza.

Per eseguire la migrazione di ClusterResourceQuotas, ti consigliamo di procedere come segue, per ogni ClusterResourceQuota:

  1. Mappa ClusterResourceQuota ai progetti OpenShift valutando i campi spec.quota e spec.selector di ClusterResourceQuota. Ad esempio, for-name ClusterResourceQuota che hai esportato nella sezione precedente aveva il seguente aspetto:

    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

    ClusterResourceQuota for-name applica limiti di quota per pod e secret. Il campo spec.selector applica questi limiti al progetto frontendOpenShift.

  2. In precedenza, nel passaggio Crea spazio dei nomi Kubernetes, hai creato spazi dei nomi Kubernetes che corrispondono ai tuoi progetti OpenShift. Utilizza queste informazioni per mappare ClusterResourceQuota ai nuovi spazi dei nomi Kubernetes. Ad esempio, il progetto OpenShift frontend contiene for-name ClusterResourceQuota. Il progetto corrisponde allo spazio dei nomi Kubernetes frontend, quindi mapperai for-nameClusterResourceQuota allo spazio dei nomi Kubernetes frontend.

  3. Per ogni definizione di quota nel campo quota di ClusterResourceQuota, dividi la quantità di quota tra gli spazi dei nomi Kubernetes su cui hai mappato ClusterResourceQuota, in base ai criteri di interesse. Ad esempio, puoi dividere equamente le quantità di quota impostate da for-name ClusterResourceQuota tra i frontend spazi dei nomi Kubernetes.

  4. Per ogni spazio dei nomi Kubernetes che hai mappato a ClusterResourceQuota, creerai una ResourceQuota Kubernetes che applica la quota su quello spazio dei nomi. Puoi impostare gli importi delle quote in base alle informazioni raccolte nel passaggio precedente. Ad esempio, crei una quota delle risorse per lo spazio dei nomi Kubernetes frontend:

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

    Come ulteriore esempio, mapperai for-name ClusterResourceQuota a due spazi dei nomi Kubernetes distinti, example-1 e example-2. Per completare il mapping, dividi equamente le risorse tra loro creando una ResourceQuota per gli spazi dei nomi Kubernetes. Alloca la prima metà di ResourceQuota:

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

    Dopo aver allocato la prima metà di ResourceQuota, allocherai la seconda metà di ResourceQuota:

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

    Questo approccio consente di applicare limiti a ogni spazio dei nomi Kubernetes in cui crei ResourceQuotas, anziché impostare un limite singolo per più spazi dei nomi Kubernetes.

Utilizzare ResourceQuotas per applicare le quote nei tuoi spazi dei nomi Kubernetes non è la stessa cosa che utilizzare ClusterResourceQuota per applicare una quota su tutti gli spazi dei nomi Kubernetes. La suddivisione di una quota con ambito cluster tra diversi spazi dei nomi Kubernetes potrebbe non essere ottimale: la divisione potrebbe eseguire l'overprovisioning delle quote per alcuni spazi dei nomi Kubernetes e le quote di sotto-provisioning per altri spazi dei nomi Kubernetes.

Ti consigliamo di ottimizzare l'allocazione delle quote ottimizzando dinamicamente la configurazione di ResourceQuotas negli spazi dei nomi Kubernetes, rispettando la quantità totale di quota stabilita dalla corrispondente ClusterResourceQuota. Ad esempio, puoi aumentare o diminuire in modo dinamico gli importi delle quote applicati da pods-secrets ResourceQuotas per evitare quantità di provisioning eccessivo o insufficiente per gli spazi dei nomi Kubernetes example-1 e example-2. Le quantità totali di pods-secrets ResourceQuotas non devono superare quelle nella quota ClusterResourceQuota corrispondente.

Quando configuri ResourceQuotas, prendi in considerazione quote e limiti di GKE e quote e limiti di GKE su VMware. Queste quote e questi limiti potrebbero imporre limiti più bassi rispetto a ResourceQuotas. Ad esempio, GKE limita il numero massimo di pod per nodo, indipendentemente da come hai configurato ResourceQuotas.

Creazione criteri di rete

OpenShift NetNamespaces consente di configurare l'isolamento di rete tra progetti OpenShift. OpenShift OutboundNetworkPolicies ti consente di regolare il traffico in uscita dai cluster OpenShift. Questa sezione si basa sui concetti relativi alla limitazione del traffico.

Per eseguire la migrazione di NetNamespaces e OutboundNetworkPolicies, procedi nel seguente modo:

  1. Valuta NetNamespaces e OutboundNetworkPolicies per capire come regolano il traffico di rete tra i progetti OpenShift e il traffico in uscita che esce dai cluster OpenShift. Ad esempio, valuta NetNamespace e il OutboundNetworkPolicy che hai esportato nella sezione precedente:

    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 e example-project-2 NetNamespace definiscono una rete overlay con lo stesso valore netid di 1234. Di conseguenza, i pod nel progetto OpenShift example-project possono comunicare con i pod nel progetto OpenShift example-project-2 e viceversa.

    Il criterio default OutboundNetworkPolicy definisce le seguenti regole del traffico di rete in uscita:

    • Consenti il traffico in uscita verso la subnet 1.2.3.0/24.
    • Negare il traffico in uscita che non corrisponde alle altre regole.

  2. Crea criteri di rete e criteri OPA in modo che siano conformi ai requisiti relativi alle limitazioni del traffico di rete. Ad esempio, default-np e default-np-2 implementano le seguenti norme:

    • I criteri applicati dal criterio OutboundNetworkPolicy default.
    • I criteri applicati da NetNamespaces example-project e example-project-2 negli spazi dei nomi con l'etichetta netid impostata su example-project e example-project-2:

    Le norme sono simili alle seguenti:

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

Gestione delle risorse Kubernetes con Config Sync

Per gestire le risorse Kubernetes e la configurazione dei tuoi cluster GKE, ti consigliamo di utilizzare Config Sync.

Per scoprire come abilitare Config Sync sui tuoi cluster GKE, consulta Installare Config Sync.

Dopo aver eseguito il provisioning e aver configurato Config Sync nel tuo ambiente GKE Enterprise, potrai utilizzarlo per creare e applicare automaticamente la configurazione ai tuoi cluster GKE.

Passaggi successivi