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

Last reviewed 2022-01-24 UTC

Questo documento ti aiuta a pianificare, progettare e implementare la migrazione progetti da OpenShift a GKE Enterprise Se questa operazione non è corretta, lo spostamento dei 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 in Google Cloud. Se ti interessa avere una panoramica della serie, guarda Migrazione a Google Cloud: scegliere il percorso di migrazione.

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

Questo documento è utile se hai intenzione di eseguire la migrazione Progetti OpenShift a GKE Enterprise Questo documento è utile anche se stai valutando l'opportunità di eseguire voglio vedere come potrebbe essere.

Questo documento si basa su concetti discussi in Migrazione a Google Cloud: introduzione, nel Migrazione dei container in Google Cloud: migrazione di Kubernetes a GKE, nel Migrazione dei container in Google Cloud: migrazione da OpenShift a GKE Enterprise, e dentro Best practice per il networking GKE. Questo documento contiene un link ai documenti precedenti, ove appropriato.

Le indicazioni in questo documento presuppongono che tu voglia eseguire migrazione lift and shift dei tuoi carichi di lavoro. In una migrazione lift and shift, applichi solo il valore minimo le modifiche necessarie affinché i carichi di lavoro operino nell'ambiente di destinazione nell'ambiente GKE Enterprise.

Per eseguire la migrazione delle risorse OpenShift a GKE Enterprise, devi mappare e convertire agli equivalenti Kubernetes. Questo documento descrive la migrazione le seguenti risorse di configurazione del progetto OpenShift necessarie per il deployment per gestire i tuoi carichi di lavoro su 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. Mappare le risorse di configurazione del progetto OpenShift alle risorse Kubernetes.
  3. Creare risorse Kubernetes mappate alla configurazione del progetto OpenShift Google Cloud.
  4. Gestire le risorse Kubernetes utilizzando Config Sync.

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

Esporta descrittori delle risorse di configurazione del progetto OpenShift

Per esportare le risorse di configurazione del progetto OpenShift, ti consigliamo di: procedi nel seguente modo:

  1. Esporta i descrittori del progetto OpenShift.
  2. Esporta i 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, ad esempio il campo metadata.managedFields. Kubernetes e OpenShift gestiscono campi contenenti informazioni sullo stato delle risorse e i relativi valori. A per semplificare la valutazione dei descrittori delle risorse OpenShift, ti consigliamo di esegui le operazioni seguenti per ogni descrittore di risorsa:

  1. Registra i campi che contengono lo stato delle risorse generato dinamicamente informazioni insieme ai relativi valori, ad esempio:

    • 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 i campi che contengono lo stato delle risorse generate dinamicamente le informazioni dal descrittore della risorsa.

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

Esporta descrittori del progetto OpenShift

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

  1. In un terminale che ha accesso al cluster OpenShift, ottieni l'elenco di Progetti OpenShift utilizzando 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 impostati nel tuo cluster OpenShift.

  2. Per ogni progetto OpenShift nell'elenco, esporta il relativo descrittore in YAML formato file, visualizza l'output e salvalo in un file utilizzando lo tee per elaborarle in seguito. Ad esempio, esporta il descrittore di un example-project Progetto OpenShift:

    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 di OpenShift example-project progetto in formato file YAML. L'output viene salvato project-example-project.yaml.

Esporta i descrittori delle risorse con ambito cluster

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

  1. Sul terminale, recupera l'elenco ClusterResourceQuotas:

    oc get clusterresourcequotas

    L'output è simile al seguente:

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

    L'output visualizza un elenco di ClusterResourceQuotes attualmente nel tuo cluster OpenShift.

  2. Per ogni ClusterResourceQuota nell'elenco, esporta il relativo descrittore in YAML, visualizzare l'output e salvarlo in un file per utilizzarlo in un secondo momento e l'elaborazione dei dati. Ad esempio, esporta il descrittore di for-name ClusterResourceQuota:

    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-name ClusterResourceQuota in formato YAML. L'output viene salvato clusterresourcequota-for-name.yaml.

  3. Ottieni 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 visualizza un elenco di ClusterRole attualmente configurati in nel tuo cluster OpenShift. L'elenco di ClusterRole include OpenShift predefinito ClusterRoles, e ClusterRoles che fanno riferimento ai componenti di sistema OpenShift. I nostri suggerimenti di valutare tutti i ClusterRole nell'elenco per valutare quali ruoli che devi eseguire la migrazione e quali ruoli non sono applicabili nell'ambiente GKE Enterprise.

  4. Per ogni ClusterRole nell'elenco, esporta il descrittore nel file YAML formato, visualizzare l'output e salvarlo in un file per elaborarlo in seguito. Per 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 visualizza il descrittore del ClusterRole admin in YAML formato. L'output viene salvato nel file clusterrole-admin.yaml.

  5. Ottieni 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 visualizza un elenco di ClusterRoleBinding attualmente impostati nel tuo cluster OpenShift. L'elenco di ClusterRoleBinding include ClusterRoleBinding che fanno riferimento ai componenti di sistema OpenShift. I nostri suggerimenti devi valutare tutti i ClusterRoleBinding nell'elenco per valutare quali le associazioni di cui devi eseguire la migrazione e quelle non applicabili nel l'ambiente GKE Enterprise di destinazione.

  6. Per ogni ClusterRoleBinding nell'elenco, esporta il relativo descrittore in YAML formato file, visualizzare l'output e salvarlo in un file per utilizzarlo in un secondo momento e l'elaborazione dei dati. Ad esempio, esporta il descrittore di cluster-admin ClusterRoleBinding:

    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 mostra il descrittore di cluster-admin ClusterRoleBinding in formato YAML. L'output viene salvato clusterrolebinding-cluster-admin.yaml.

Esporta NetNamespace personalizzati

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

OpenShift crea e gestisce automaticamente NetNamespace per OpenShift gestito in modo programmatico a gestire i progetti. Gli spazi dei nomi per i progetti gestiti da OpenShift non rientrano nell'ambito di della migrazione.

Per esportare NetNamespace personalizzati:

  1. Recupera l'elenco di NetNamespace:

    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 NetNamespaces attualmente configurati in nel tuo cluster OpenShift.

  2. Per ogni NetNamespace nell'elenco, esporta il descrittore nel file YAML formato, visualizzare l'output e salvarlo in un file per elaborarlo in seguito. Per Ad esempio, esporta il descrittore di default NetNamespace:

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

    Per gli spazi dei nomi Net 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 mostra il descrittore del NetNamespace example-project nel formato di file YAML. L'output viene salvato netnamespace-example-project.yaml.

    Per gli spazi NetNamespace 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 i descrittori delle risorse con ambito a livello di progetto

Per esportare i descrittori per le risorse che hanno un ambito di progetto, esegui la per ogni progetto OpenShift.

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

    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 configurate nel cluster OpenShift per il progetto OpenShift selezionato.

  3. Per ogni ResourceQuota nell'elenco, esporta il relativo descrittore in YAML formato, visualizzare l'output e salvarlo in un file per elaborarlo in seguito. Per 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 visualizza il descrittore di gpu-quota ResourceQuota in YAML. L'output viene salvato nell'resourcequota-gpu-quota.yaml .

  4. Ottieni l'elenco di 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 in Cluster OpenShift per il progetto OpenShift selezionato. L'elenco dei ruoli include Ruoli che fanno riferimento ai componenti di sistema OpenShift. È consigliabile valuti tutti i ruoli nell'elenco per valutare quali ruoli migrazione e i ruoli non applicabili nella destinazione nell'ambiente GKE Enterprise.

  5. Per ogni ruolo nell'elenco, esporta il descrittore in formato file YAML, visualizzare l'output e salvarlo in un file per elaborarlo in un secondo momento. Per 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 visualizza il descrittore del ruolo example nel file YAML formato. L'output viene salvato nel file role-example.yaml.

  6. Ottieni 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 configurate in OpenShift cluster per il progetto OpenShift selezionato. L'elenco di RoleBinding include RoleBinding che fanno riferimento ai componenti di sistema OpenShift. Me ti consigliamo di valutare tutte le associazioni dei ruoli nell'elenco per valutare le associazioni di cui devi eseguire la migrazione e quelle non applicabili nel l'ambiente GKE Enterprise di destinazione.

  7. Per ogni RoleBinding nell'elenco, esporta il descrittore nel file YAML formato, visualizzare l'output e salvarlo in un file per elaborarlo in seguito. Per Ad esempio, esporta il descrittore della RoleBinding example:

    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 YAML . L'output viene salvato nel file rolebinding-example.yaml.

  8. Ottieni l'elenco di EgressNetworkPolicies:

    oc get egressnetworkpolicies

    L'output è simile al seguente:

    NAME      AGE
default   2m2s
...

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

  9. Per ogni oggetto OutboundNetworkPolicy nell'elenco, esporta il relativo descrittore in YAML formato file, visualizzare l'output e salvarlo in un file per utilizzarlo in un secondo momento e l'elaborazione dei dati. Ad esempio, esporta il descrittore di default EgressNetworkPolicy:

    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 del valore EgressNetworkPolicy default in formato YAML. L'output viene salvato anche egressnetworkpolicy-default.yaml.

  10. Ottieni 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 descrittore nel file YAML formato, visualizzare l'output e salvarlo in un file per elaborarlo in seguito. Per 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 visualizza il descrittore di test-policy NetworkPolicy in YAML. L'output viene salvato networkpolicy-test-policy.yaml.

Mappa le risorse di configurazione del progetto OpenShift alle risorse Kubernetes

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

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

L'elenco seguente consente di valutare per quali risorse è stato eseguito il provisioning nei tuoi cluster OpenShift sono risorse Kubernetes e quali sono disponibile solo in OpenShift:

  • I progetti OpenShift 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 NetworkPolicy sono Risorse Kubernetes.
  • ClusterResourceQuote non sono risorse Kubernetes; sono disponibili in Solo OpenShift.
  • NetNamespaces e EgressNetworkPolicies non sono risorse Kubernetes, disponibili solo in OpenShift.

La tabella seguente fornisce un riepilogo di come mappare il progetto OpenShift di configurazione alle risorse che hai utilizzato con GKE Enterprise.

OpenShift GKE Enterprise
Progetti Converti in Kubernetes Spazi dei nomi con annotazioni aggiuntive
Role, ClusterRole, RoleBinding e ClusterRoleBinding RBAC per Kubernetes
ResourceQuotas RBAC per Kubernetes
ClusterResourceQuotas Converti in ResourceQuotas o utilizza le quote delle risorse gerarchiche
NetworkPolicies Rete Kubernetes
NetNamespaces, EgressNetworkPolicies Converti in NetworkPolicies

Dopo aver valutato le risorse del tuo ambiente OpenShift, mappa la OpenShift le risorse in risorse di cui puoi eseguire il provisioning e configurare GKE e GKE Enterprise. Non è necessario mappare Le risorse Kubernetes che stai utilizzando nei tuoi cluster OpenShift perché GKE Enterprise li supporta direttamente. Come descritto nella sezione Riepilogo della mappatura delle funzionalità da OpenShift a GKE Enterprise, ti consigliamo di mappare quanto segue:

  • i progetti OpenShift negli spazi dei nomi Kubernetes.
  • da ClusterResourceQuotes a ResourceQuotas.
  • da NetNamespaces e da OutboundNetworkPolicies a NetworkPolicies.

Creare risorse Kubernetes mappate alle risorse di configurazione del progetto OpenShift

Una volta completata la mappatura, crei le risorse Kubernetes che hai mappato alle tue risorse OpenShift. Ti consigliamo di creare quanto segue:

  • Uno spazio dei nomi Kubernetes per ogni progetto OpenShift.
  • Una ResourceQuota per ogni spazio dei nomi Kubernetes ClusterResourceQuotes stanno limitando.
  • NetworkPolicy in modo che corrispondano a NetNamespaces e OutboundNetworkPolicies.

Creazione di spazi dei nomi Kubernetes

I progetti OpenShift Spazi dei nomi Kubernetes con annotazioni aggiuntive. La API OpenShift project corrisponde esattamente API Kubernetes Namespace. Per eseguire la migrazione dei tuoi progetti OpenShift, ti consigliamo di creare un cluster Kubernetes Spazio dei nomi per ogni progetto OpenShift. Le API sono compatibili, quindi puoi creare uno spazio dei nomi Kubernetes da un progetto OpenShift.

Per creare uno spazio dei nomi Kubernetes da un progetto OpenShift, modifichi i valori nel descrittore del progetto OpenShift Versione dell'API Kubernetes Namespace per ogni progetto OpenShift. Per farlo, modifica il valore del campo apiVersion nel descrittore del progetto OpenShift La versione API dell'oggetto del progetto OpenShift e il valore del campo kind al valore corrispondente Versione API dell'oggetto Spazio dei nomi Kubernetes. 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 Da Project a Namespace:

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

Creazione ResourceQuotes di Kubernetes

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

Per eseguire la migrazione di ClusterResourceQuotes, ti consigliamo di: per ogni ClusterResourceQuota:

  1. Mappa la ClusterResourceQuota ai progetti OpenShift valutando il il campo spec.quota e il campo spec.selector del ClusterResourceQuota. ad esempio for-name ClusterResourceQuota 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

    La quota ClusterResourceQuota di for-name applica la quota di pod e secret limiti. Il campo spec.selector applica questi limiti a frontend Progetto OpenShift.

  2. Nel Crea spazio dei nomi Kubernetes in precedenza, hai creato spazi dei nomi Kubernetes che corrispondono in modo programmatico a gestire i progetti. Utilizza queste informazioni per mappare la ClusterResourceQuota al nuovo degli spazi dei nomi Kubernetes. Ad esempio, il progetto OpenShift frontend contiene for-name ClusterResourceQuota. Il progetto corrisponde lo spazio dei nomi Kubernetes frontend, quindi mapperai for-name ClusterResourceQuota nello spazio dei nomi Kubernetes frontend.

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

  4. Per ogni spazio dei nomi Kubernetes mappato ClusterResourceQuota, crei un cluster Kubernetes ResourceQuota che applica la quota sullo spazio dei nomi. Sei tu a impostare gli importi delle quote in base alle informazioni raccolte nel passaggio precedente. Per Ad esempio, crei una ResourceQuota per lo spazio dei nomi Kubernetes frontend:

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

    Per fare un altro esempio, puoi mappare for-name ClusterResourceQuota a due spazi dei nomi Kubernetes distinti, example-1 e example-2. Per completare del mapping, suddividi equamente le risorse tra loro creando un ResourceQuota per gli spazi dei nomi Kubernetes. Alloca la prima metà Quota delle risorse:

    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, devi assegnare nella seconda metà di ResourceQuota:

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

    Questo approccio ti consente di applicare limiti a ogni spazio dei nomi Kubernetes in cui crei ResourceQuotas, invece di impostare un unico limite più spazi dei nomi Kubernetes.

L'uso di ResourceQuotas per applicare le quote sugli spazi dei nomi Kubernetes non è equivale a utilizzare una ClusterResourceQuota per applicare una quota su tutte le risorse Kubernetes Spazi dei nomi. Dividere una quota con ambito cluster tra diversi Kubernetes Gli spazi dei nomi potrebbero non essere ottimali: la divisione potrebbe eseguire un overprovisioning delle quote per alcuni spazi dei nomi Kubernetes e le quote di underprovisioning per altri oggetti Kubernetes Spazi dei nomi.

Ti consigliamo di ottimizzare l'allocazione della quota tramite l'ottimizzazione dinamica la configurazione di ResourceQuotas negli spazi dei nomi Kubernetes, rispettando la quantità totale di quota che la ClusterResourceQuota corrispondente la creazione di un progetto. Ad esempio, puoi aumentare o diminuire in modo dinamico la quota applicati da pods-secrets ResourceQuotas per evitare delle quote di overprovisioning o underprovisioning per example-1 e example-2 Spazi dei nomi Kubernetes. Gli importi totali della quota di pods-secrets ResourceQuotas non deve superare gli importi della quota nel ClusterResourceQuota.

Quando configuri ResourceQuotas, considera Quote e limiti di GKE e Quote e limiti di Google Distributed Cloud. Queste quote e questi limiti potrebbero imporre limiti più bassi rispetto a ResourceQuotes. Per Ad esempio, GKE limita numero massimo di pod per nodo, a prescindere dalla configurazione di ResourceQuotas.

Creazione NetworkPolicy

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

Per eseguire la migrazione di NetNamespaces e EgressNetworkPolicies, segui questi passaggi:

  1. Valuta i tuoi NetNamespaces e EgressNetworkPolicies per capire come stanno regolando il traffico di rete tra progetti OpenShift e in uscita che lascia i cluster OpenShift. Ad esempio, valuta NetNamespace e il criterio OutboundNetworkPolicy che hai esportato nella sezione:

    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

    I netNamespace example-project e example-project-2 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 example-project-2 progetto OpenShift e viceversa.

    Il parametro OutboundNetworkPolicy default definisce la seguente rete in uscita regole del traffico:

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

  2. Crea criteri NetworkPolicies e OPA per farli corrispondere al traffico di rete requisiti di restrizione. Ad esempio, default-np e default-np-2 implementa le seguenti norme:

    • I criteri applicati da EgressNetworkPolicy default.
    • I criteri applicati da example-project e example-project-2 netNamespaces su spazi dei nomi con netid etichetta impostata su example-project e example-project-2:

    I criteri sono simili ai 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

Gestire le risorse Kubernetes con Config Sync

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

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

Dopo aver eseguito il provisioning e configurato Config Sync nell'ambiente GKE Enterprise, lo utilizzerai per creare e applicare automaticamente la configurazione ai tuoi cluster GKE.

Passaggi successivi