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:
- Migrazione dei container in Google Cloud: migrazione di Kubernetes a Google Kubernetes Engine (GKE)
- Migrazione dei container in Google Cloud: migrazione da OpenShift a GKE Enterprise
- Migrazione dei container in Google Cloud: migrazione dei progetti OpenShift a GKE Enterprise (questo documento)
- Migrazione da OpenShift a GKE Enterprise: migrazione delle SCC di OpenShift ai vincoli di Policy Controller
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:
- Progetti OpenShift
- Quote delle risorse per ogni progetto OpenShift e quote delle risorse in più progetti OpenShift
- Ruoli e ClusterRoles
- RoleBindings e ClusterRoleBindings
- Configurazione degli spazi dei nomi di rete OpenShift e NetworkPolicies
Per eseguire la migrazione della configurazione del progetto OpenShift e delle risorse correlate a GKE Enterprise, ti consigliamo di:
- Esporta i descrittori delle risorse di configurazione del progetto OpenShift.
- Mappare le risorse di configurazione del progetto OpenShift alle risorse Kubernetes.
- Creare risorse Kubernetes mappate alla configurazione del progetto OpenShift Google Cloud.
- 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:
- Esporta i descrittori del progetto OpenShift.
- Esporta i descrittori delle risorse con ambito cluster.
- 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:
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 prefissoopenshift.io
metadata.creationTimestamp
metadata.generation
metadata.managedFields
metadata.resourceVersion
metadata.selfLink
metadata.uid
status
- Qualsiasi campo nidificato sotto
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:
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.
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 unexample-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 salvatoproject-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:
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.
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 salvatoclusterresourcequota-for-name.yaml
.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.
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 fileclusterrole-admin.yaml
.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.
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 salvatoclusterrolebinding-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:
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.
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 salvatonetnamespace-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.
Nel terminale, seleziona il progetto OpenShift che vuoi valutare. Ad esempio, seleziona il progetto OpenShift
example-project
:oc project example-project
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.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
.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.
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 filerole-example.yaml
.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.
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 filerolebinding-example.yaml
.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.
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 ancheegressnetworkpolicy-default.yaml
.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.
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 salvatonetworkpolicy-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:
- Valutare quali risorse nell'inventario sono risorse Kubernetes che sono risorse OpenShift.
- 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:
Mappa la ClusterResourceQuota ai progetti OpenShift valutando il il campo
spec.quota
e il campospec.selector
del ClusterResourceQuota. ad esempiofor-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 campospec.selector
applica questi limiti afrontend
Progetto OpenShift.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
contienefor-name
ClusterResourceQuota. Il progetto corrisponde lo spazio dei nomi Kubernetesfrontend
, quindi mapperaifor-name
ClusterResourceQuota nello spazio dei nomi Kubernetesfrontend
.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 perfor-name
ClusterResourceQuota equamente trafrontend
Kubernetes Spazi dei nomi.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
eexample-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:
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
eexample-project-2
definiscono una rete overlay con lo stesso valorenetid
di1234
. Di conseguenza, i pod nel progetto OpenShiftexample-project
possono comunicare con i podexample-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.
- Consenti il traffico in uscita verso la subnet
Crea criteri NetworkPolicies e OPA per farli corrispondere al traffico di rete requisiti di restrizione. Ad esempio,
default-np
edefault-np-2
implementa le seguenti norme:- I criteri applicati da EgressNetworkPolicy
default
. - I criteri applicati da
example-project
eexample-project-2
netNamespaces su spazi dei nomi connetid
etichetta impostata suexample-project
eexample-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
- I criteri applicati da EgressNetworkPolicy
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
- Leggi come iniziare la migrazione a Google Cloud.
- Scopri le best practice per edificio e operativo containers.
- Impara best practice per il networking GKE.
- Comprendi come rafforzare la sicurezza del tuo cluster.
- Leggi Panoramica sulla sicurezza di GKE.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Centro architetture cloud.