Ce document vous aide à planifier, concevoir et mettre en œuvre la migration de vos projets depuis OpenShift vers GKE Enterprise. Sans une sérieuse préparation, le transfert de charges de travail d'un environnement à un autre peut s'avérer compliqué. C'est pourquoi vous devez planifier et exécuter votre migration avec soin.
Ce document fait partie d'une série d'articles sur la migration vers Google Cloud. Si vous êtes intéressé par une présentation de la série, consultez la section Migration vers Google Cloud : choisir votre chemin de migration.
Ce document fait partie d'une série qui traite de la migration de conteneurs vers Google Cloud :
- Migrer des conteneurs vers Google Cloud : migrer Kubernetes vers Google Kubernetes Engine (GKE)
- Migrer des conteneurs vers Google Cloud : migrer OpenShift vers GKE Enterprise
- Migrer des conteneurs vers Google Cloud : migrer des projets OpenShift vers GKE Enterprise (le présent document)
- Migrer depuis OpenShift vers GKE Enterprise : migrer des contraintes de contexte de sécurité OpenShift vers des contraintes Policy Controller
Ce document est utile si vous envisagez de migrer des projets OpenShift vers GKE Enterprise. Ce document est également utile si vous évaluez l'opportunité d'effectuer une migration et si vous souhaitez découvrir à quoi elle pourrait ressembler.
Ce document s'appuie sur les concepts abordés dans les pages Migration vers Google Cloud : premiers pas, Migrer des conteneurs vers Google Cloud : migrer Kubernetes vers GKE, Migrer des conteneurs vers Google Cloud : migrer OpenShift vers GKE Enterprise et Bonnes pratiques de mise en réseau GKE. Ce document renvoie aux documents précédents, le cas échéant.
Les instructions du présent document supposent que vous souhaitez exécuter une migration Lift and Shift de vos charges de travail. Dans le cadre d'une migration Lift and Shift, vous n'appliquez que les modifications minimales nécessaires à votre charge de travail pour fonctionner dans l'environnement GKE Enterprise cible.
Pour migrer des ressources OpenShift vers GKE Enterprise, vous devez les mapper et les convertir en leurs équivalents Kubernetes. Ce document décrit la migration des ressources de configuration de projet OpenShift suivantes nécessaires pour déployer et exploiter vos charges de travail sur GKE Enterprise :
- Projets OpenShift
- Quotas de ressources pour chaque projet OpenShift et quotas de ressources partagés par plusieurs projets OpenShift
- Roles et ClusterRoles
- RoleBindings et ClusterRoleBindings
- Configuration des espaces de noms réseau OpenShift et NetworkPolicies
Pour migrer la configuration de projet OpenShift et les ressources associées vers GKE Enterprise, nous vous recommandons d'effectuer les opérations suivantes :
- Exporter les descripteurs de ressource de configuration du projet OpenShift.
- Mapper les ressources de configuration de projet OpenShift à des ressources Kubernetes
- Créer des ressources Kubernetes qui correspondent à des ressources de configuration de projet OpenShift
- Gérez les ressources Kubernetes avec Config Sync.
Ce document fournit des exemples de procédures de migration.
Exporter des descripteurs de ressource de configuration de projet OpenShift
Pour exporter les ressources de configuration de projet OpenShift, nous vous recommandons d'effectuer les opérations suivantes :
- Exportez les descripteurs de projet OpenShift.
- Exportez les descripteurs de ressources à l'échelle d'un cluster.
- Exportez des descripteurs de ressources au niveau du projet.
Les descripteurs que vous exportez depuis un cluster OpenShift incluent des champs décrivant la configuration et l'état des ressources (par exemple, les champs spec
et status
). Les descripteurs incluent également des champs contenant des informations sur l'état des ressources (par exemple, le champ metadata.managedFields
). Kubernetes et OpenShift gèrent pour vous les champs qui contiennent des informations sur l'état des ressources ainsi que leurs valeurs. Pour simplifier l'évaluation des descripteurs de ressources OpenShift, nous vous recommandons d'effectuer les opérations suivantes pour chaque descripteur de ressource :
Enregistrez les champs qui contiennent des informations sur l'état des ressources générées de manière dynamique, ainsi que leurs valeurs, tels que les suivants :
- Tout champ imbriqué sous
metadata.annotations
et commençant par le préfixeopenshift.io
metadata.creationTimestamp
metadata.generation
metadata.managedFields
metadata.resourceVersion
metadata.selfLink
metadata.uid
status
- Tout champ imbriqué sous
Supprimez les champs contenant des informations sur l'état des ressources générées de manière dynamique.
Pour exporter des descripteurs de ressource de configuration de projet OpenShift, utilisez l'interface de ligne de commande OpenShift (CLI oc
).
Pour exporter des descripteurs de ressource dans la CLI oc
, vous devez vous authentifier avec le rôle cluster-admin.
Pour obtenir la liste de toutes les ressources OpenShift compatibles avec la CLI oc
, exécutez la commande oc api-resources
.
Exporter des descripteurs de projet OpenShift
Cette section explique comment exporter des descripteurs de projet. Nous vous recommandons d'exclure les projets OpenShift exécutant des composants système (par exemple, le composant istio-system
) et d'exclure les projets OpenShift dont les noms commencent par openshift-
, kube-
ou knative-
OpenShift gère ces projets OpenShift pour vous. Ils ne sont pas concernés par cette migration car vous ne vous en servez pas pour déployer vos charges de travail. Pour exporter des descripteurs de projet OpenShift, procédez comme suit pour chaque cluster OpenShift :
Dans un terminal ayant accès au cluster OpenShift, obtenez la liste des projets OpenShift à l'aide de la commande
oc get
:oc get projects
Le résultat ressemble à ce qui suit :
NAME DISPLAY NAME STATUS example-project Active ...
Le résultat affiche la liste des projets OpenShift actuellement configurés dans votre cluster OpenShift.
Pour chaque projet OpenShift de la liste, exportez son descripteur au format de fichier YAML, affichez le résultat et enregistrez-le dans un fichier à l'aide de la commande
tee
en vue d'un traitement ultérieur. Par exemple, exportez le descripteur d'un projet OpenShiftexample-project
:oc get project example-project -o yaml | tee project-example-project.yaml
Le résultat ressemble à ce qui suit :
apiVersion: project.openshift.io/v1 kind: Project metadata: annotations: name: example-project spec: finalizers: - kubernetes
Le résultat affiche le descripteur du projet OpenShift
example-project
au format de fichier YAML. Le résultat est enregistré dans le fichierproject-example-project.yaml
.
Exporter des descripteurs de ressources à l'échelle du cluster
Cette section explique comment exporter les descripteurs des ressources disposant d'un champ d'application à l'échelle du cluster, à l'exclusion des contraintes de contexte de sécurité. Pour en savoir plus sur la migration des règles de sécurité, consultez la page Migrer depuis OpenShift vers GKE Enterprise : migrer des contraintes de contexte de sécurité OpenShift vers des contraintes Policy Controller. Pour exporter d'autres descripteurs de ressources, procédez comme suit pour chaque cluster OpenShift :
Dans votre terminal, obtenez la liste des ClusterResourceQuotas :
oc get clusterresourcequotas
Le résultat ressemble à ce qui suit :
NAME AGE for-name 6m15s for-user 4s ...
Le résultat affiche la liste des ClusterResourceQuota actuellement configurés dans votre cluster OpenShift.
Pour chaque ClusterResourceQuota de la liste, exportez son descripteur au format de fichier YAML, affichez le résultat et enregistrez-le dans un fichier pour un traitement ultérieur. Par exemple, exportez le descripteur du ClusterResourceQuota
for-name
:oc get clusterresourcequota for-name -o yaml | tee clusterresourcequota-for-name.yaml
Le résultat ressemble à ce qui suit :
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
Le résultat affiche le descripteur du ClusterResourceQuota
for-name
au format YAML. L'ensemble de données est enregistré dans le fichierclusterresourcequota-for-name.yaml
.Obtenez la liste des ClusterRoles :
oc get clusterroles
Le résultat ressemble à ce qui suit :
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 ...
Le résultat affiche une liste des ClusterRoles actuellement configurés dans votre cluster OpenShift. La liste des ClusterRoles inclut les ClusterRoles par défaut OpenShift et les ClusterRoles qui font référence aux composants système OpenShift. Nous vous recommandons d'évaluer tous les ClusterRoles de la liste pour évaluer les rôles que vous devez migrer et ceux qui ne sont pas applicables dans l'environnement GKE Enterprise cible.
Pour chaque ClusterRole de la liste, exportez son descripteur au format de fichier YAML, affichez la sortie et enregistrez-la dans un fichier pour un traitement ultérieur. Par exemple, exportez le descripteur du ClusterRole
admin
:oc get clusterrole admin -o yaml | tee clusterrole-admin.yaml
Le résultat ressemble à ce qui suit :
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 ...
Le résultat affiche le descripteur du ClusterRole
admin
au format YAML. L'ensemble de données est enregistré dans le fichierclusterrole-admin.yaml
.Obtenez la liste des ClusterRoleBindings :
oc get clusterrolebindings
Le résultat ressemble à ce qui suit :
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 ...
Le résultat affiche une liste des ClusterRoleBindings actuellement configurés dans votre cluster OpenShift. La liste des ClusterRoleBinding inclut les ClusterRoleBindings qui font référence aux composants système OpenShift. Nous vous recommandons d'évaluer tous les ClusterRoleBindings de la liste pour évaluer les liaisons que vous devez migrer et celles qui ne sont pas applicables dans l'environnement GKE Enterprise cible.
Pour chaque ClusterRoleBinding de la liste, exportez son descripteur au format de fichier YAML, affichez le résultat et enregistrez-le dans un fichier pour un traitement ultérieur. Par exemple, exportez le descripteur du ClusterRoleBinding
cluster-admin
:oc get clusterrolebinding cluster-admin -o yaml | tee clusterrolebinding-cluster-admin.yaml
Le résultat ressemble à ce qui suit :
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
Le résultat affiche le descripteur du ClusterRoleBinding
cluster-admin
au format YAML. L'ensemble de données est enregistré dans le fichierclusterrolebinding-cluster-admin.yaml
.
Exporter des NetNamespaces personnalisés
Cette section explique comment évaluer la configuration d'isolation mutualisée. Cette section s'applique si vous avez créé des NetNamespaces personnalisés pour un projet OpenShift de votre cluster afin d'isoler ou d'unir des espaces de noms réseau. Si vous n'avez pas créé d'espace de noms NetNamespaces personnalisé, passez à la section Exporter les descripteurs de ressources à l'échelle du projet.
OpenShift crée et gère automatiquement les NetNamespaces pour les projets OpenShift gérés. Les NetNamespaces de projets gérés par OpenShift ne sont pas concernés par cette migration.
Pour exporter des NetNamespaces personnalisés, procédez comme suit :
Obtenez la liste des NetNamespaces :
oc get netnamespaces
Le résultat renvoyé ressemble à ceci :
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 ...
Le résultat affiche une liste des NetNamespaces actuellement configurés dans votre cluster OpenShift.
Pour chaque NetNamespace de la liste, exportez son descripteur au format de fichier YAML, affichez le résultat et enregistrez-le dans un fichier pour un traitement ultérieur. Par exemple, exportez le descripteur du
NetNamespace
default
:oc get netnamespace example-project -o yaml | tee netnamespace-example-project.yaml
Pour les NetNamespaces qui n'ont pas la même valeur
netid
, le résultat ressemble à ce qui suit :apiVersion: network.openshift.io/v1 kind: NetNamespace metadata: name: example-project netid: 1234 netname: example-project
Le résultat affiche le descripteur du NetNamespace
example-project
au format de fichier YAML. L'ensemble de données est enregistré dans le fichiernetnamespace-example-project.yaml
.Pour les NetNamespaces disposant de la même valeur
netid
, le résultat ressemble à ce qui suit :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
Exporter des descripteurs de ressources au niveau du projet.
Pour exporter les descripteurs des ressources disposant d'un champ d'application à l'échelle du projet, procédez comme suit pour chaque projet OpenShift.
Dans votre terminal, sélectionnez le projet OpenShift que vous souhaitez évaluer. Par exemple, sélectionnez le projet OpenShift
example-project
:oc project example-project
Obtenez la liste des ResourceQuotas :
oc get resourcequotas
Le résultat ressemble à ce qui suit :
NAME AGE REQUEST LIMIT gpu-quota 6s requests.nvidia.com/gpu: 1/1 ...
Le résultat affiche la liste des
ResourceQuotas
actuellement configurées dans votre cluster OpenShift pour le projet OpenShift sélectionné.Pour chaque ResourceQuota de la liste, exportez son descripteur au format de fichier YAML, affichez le résultat et enregistrez-le dans un fichier pour un traitement ultérieur. Par exemple, exportez le descripteur de l'objet ResourceQuota
gpu-quota
:oc get resourcequota gpu-quota -o yaml | tee resourcequota-gpu-quota.yaml
Le résultat ressemble à ce qui suit :
apiVersion: v1 kind: ResourceQuota metadata: name: gpu-quota namespace: example-project spec: hard: requests.nvidia.com/gpu: "1"
Le résultat affiche le descripteur du ResourceQuota
gpu-quota
au format de fichier YAML. L'ensemble de données est enregistré dans le fichierresourcequota-gpu-quota.yaml
.Obtenez la liste des rôles :
oc get roles
Le résultat ressemble à ce qui suit :
NAME CREATED AT example 2021-02-02T06:48:27Z ...
Le résultat affiche la liste des Rôles actuellement configurés dans votre cluster OpenShift pour le projet OpenShift sélectionné. La liste des Rôles inclut des rôles qui font référence aux composants système OpenShift. Nous vous recommandons d'évaluer tous les Rôles répertoriés pour évaluer ceux que vous devez migrer et ceux qui ne sont pas applicables dans l'environnement GKE Enterprise cible.
Pour chaque Rôle de la liste, exportez son descripteur au format de fichier YAML, affichez le résultat et enregistrez-le dans un fichier pour un traitement ultérieur. Par exemple, exportez le descripteur du Rôle
example
:oc get role example -o yaml | tee role-example.yaml
Le résultat ressemble à ce qui suit :
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: example namespace: example-project rules: - apiGroups: - "" resources: - services - endpoints - pods verbs: - get - list - watch
Le résultat affiche le descripteur du Rôle
example
au format YAML. L'ensemble de données est enregistré dans le fichierrole-example.yaml
.Obtenez la liste des RoleBindings :
oc get rolebindings
Le résultat ressemble à ce qui suit :
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 ...
Le résultat affiche une liste des RoleBindings configurés dans votre cluster OpenShift pour le projet OpenShift sélectionné. La liste des RoleBindings inclut des RoleBinding faisant référence aux composants système OpenShift. Nous vous recommandons d'évaluer tous les RoleBindings de la liste pour évaluer les liaisons que vous devez migrer et celles qui ne sont pas applicables dans l'environnement GKE Enterprise cible.
Pour chaque RoleBinding de la liste, exportez son descripteur au format de fichier YAML, affichez le résultat et enregistrez-le dans un fichier pour un traitement ultérieur. Par exemple, exportez le descripteur du RoleBinding
example
:oc get rolebinding example -o yaml | tee rolebinding-example.yaml
Le résultat ressemble à ce qui suit :
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
Le résultat affiche le descripteur de l'objet RoleBinding
example
au format de fichier YAML. L'ensemble de données est enregistré dans le fichierrolebinding-example.yaml
.Obtenez la liste des EgressNetworkPolicies :
oc get egressnetworkpolicies
Le résultat ressemble à ce qui suit :
NAME AGE default 2m2s ...
Le résultat affiche la liste des EgressNetworkPolicies actuellement configurées dans votre cluster OpenShift pour le projet OpenShift sélectionné.
Pour chaque EgressNetworkPolicy de la liste, exportez son descripteur au format de fichier YAML, affichez la sortie et enregistrez-la dans un fichier pour un traitement ultérieur. Par exemple, exportez le descripteur de la règle de l'EgressNetworkPolicy
default
:oc get egressnetworkpolicy default -o yaml | tee egressnetworkpolicy-default.yaml
Le résultat ressemble à ce qui suit :
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
Le résultat affiche le descripteur de la EgressNetworkPolicy
default
au format YAML. Le résultat est également enregistré dans le fichieregressnetworkpolicy-default.yaml
.Obtenez la liste des NetworkPolicies :
oc get networkpolicies
Le résultat ressemble à ce qui suit :
NAME POD-SELECTOR AGE test-policy app=mongodb 3s ...
Le résultat affiche la liste des NetworkPolicies actuellement configurées dans votre cluster OpenShift pour le projet OpenShift sélectionné.
Pour chaque NetworkPolicy de la liste, exportez son descripteur au format de fichier YAML, affichez la sortie et enregistrez-la dans un fichier pour un traitement ultérieur. Par exemple, exportez le descripteur de la NetworkPolicy
test-policy
:oc get networkpolicy test-policy -o yaml | tee networkpolicy-test-policy.yaml
Le résultat ressemble à ce qui suit :
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
Le résultat affiche le descripteur de la NetworkPolicy
test-policy
au format YAML. Le résultat est enregistré dans le fichiernetworkpolicy-test-policy.yaml
.
Mapper des ressources de configuration de projet OpenShift à des ressources Kubernetes
Une fois que vous avez terminé l'inventaire des ressources de configuration du projet OpenShift, évaluez ces ressources comme suit :
- Évaluez les quantités de ressources de l'inventaire qui sont des ressources Kubernetes ou des ressources OpenShift.
- Mappez les ressources OpenShift à leurs équivalents Kubernetes, GKE et GKE Enterprise.
La liste suivante vous permet d'évaluer les ressources que vous avez provisionnées dans vos clusters OpenShift qui sont des ressources Kubernetes et celles qui ne sont disponibles que dans OpenShift :
- Les projets OpenShift sont des espaces de noms Kubernetes avec des annotations supplémentaires.
- Les Roles, ClusterRoles, RoleBindings et ClusterRoleBindings sont des ressources Kubernetes.
- Les ResourceQuotas sont des ressources Kubernetes.
- Les NetworkPolicies sont des ressources Kubernetes.
- Les ClusterResourceQuotas ne sont pas des ressources Kubernetes. Elles ne sont disponibles que dans OpenShift.
- Les NetNamespaces et EgressNetworkPolicies ne sont pas des ressources Kubernetes. Elles sont disponibles uniquement dans OpenShift.
Le tableau suivant fournit un résumé des correspondances entre les ressources de configuration de projet OpenShift et les ressources que vous avez utilisées dans GKE Enterprise.
OpenShift | GKE Enterprise |
---|---|
Projets | Conversion en espaces de nom Kubernetes avec des annotations supplémentaires |
Roles, ClusterRoles, RoleBindings et ClusterRoleBindings | Ressources Kubernetes RBAC |
ResourceQuotas | Ressources Kubernetes RBAC |
ClusterResourceQuotas | Convertissez-les en ResourceQuotas ou utilisez des quotas de ressources hiérarchiques. |
NetworkPolicies | Ressources réseau Kubernetes |
NetNamespaces, EgressNetworkPolicies | Conversion en NetworkPolicies |
Après avoir évalué les ressources de votre environnement OpenShift, mappez les ressources OpenShift aux ressources que vous pouvez provisionner et configurer dans GKE et GKE Enterprise. Vous n'avez pas besoin de mapper les ressources Kubernetes que vous utilisez dans vos clusters OpenShift, car GKE Enterprise offre une compatibilité directe pour ces ressources. Comme indiqué dans le Résumé des correspondances de fonctionnalités entre OpenShift et GKE Enterprise, nous vous recommandons de mapper les éléments suivants :
- Les projets OpenShift vers les espaces de noms Kubernetes
- Les ClusterResourceQuotas vers les ResourceQuotas.
- Les NetNamespaces et EgressNetworkPolicies vers les NetworkPolicies
Créer des ressources Kubernetes qui correspondent à des ressources de configuration de projet OpenShift
Une fois le mappage terminé, vous créez les ressources Kubernetes que vous avez mappées à vos ressources OpenShift. Nous vous recommandons de créer les éléments suivants :
- Un espace de noms Kubernetes pour chaque projet OpenShift
- Un ResourceQuota pour chaque espace de noms Kubernetes que vos ClusterResourceQuotas limitent.
- Les NetworkPolicies doivent correspondre à vos NetNamespaces et EgressNetworkPolicies.
Créer des Namespaces Kubernetes
Les projets OpenShift sont des espaces de noms Kubernetes avec des annotations supplémentaires. L'API de projet OpenShift correspond étroitement à l'API d'espace de noms Kubernetes. Pour migrer vos projets OpenShift, nous vous recommandons de créer un espace de noms Kubernetes pour chaque projet OpenShift. Les API étant compatibles, vous pouvez créer un espace de noms Kubernetes à partir d'un projet OpenShift.
Pour créer un espace de noms Kubernetes à partir d'un projet OpenShift, nous vous recommandons de remplacer les valeurs du descripteur de projet OpenShift par la version de l'API d'espace de noms Kubernetes correspondante pour chaque projet OpenShift. Pour ce faire, vous devez remplacer la valeur du champ apiVersion
dans le descripteur de projet OpenShift par la version de l'API d'objet du projet OpenShift, et la valeur du champ kind
par la Version de l'API d'objet d'espace de noms Kubernetes correspondante.
Par exemple, le projet OpenShift que vous avez évalué dans la section précédente est semblable à celui-ci :
apiVersion: project.openshift.io/v1
kind: Project
metadata:
annotations:
name: default
spec:
finalizers:
- kubernetes
Pour migrer le projet, remplacez la valeur project.openshift.io/v1
du champ apiVersion
par v1
et remplacez la valeur Project
du champ kind
par Namespace
:
apiVersion: v1
kind: Namespace
Metadata:
annotations:
name: default
spec:
finalizers:
- kubernetes
Créer des ResourceQuotas Kubernetes
Les ClusterResourceQuota OpenShift vous permettent de partager des quotas entre plusieurs projets OpenShift. Lorsque vous créez un ClusterResourceQuota, vous définissez le quota et le sélecteur afin qu'il corresponde aux projets OpenShift pour lesquels vous souhaitez appliquer le quota. Dans cette section, vous migrez vos ClusterResourceQuotas OpenShift vers les ResourceQuotas Kubernetes dans les espaces de noms que vous avez créés précédemment.
Pour migrer vos ClusterResourceQuotas, nous vous recommandons d'effectuer les opérations suivantes pour chaque ClusterResourceQuota :
Mappez le ClusterResourceQuota aux projets OpenShift en évaluant les champs
spec.quota
etspec.selector
du ClusterResourceQuota. Par exemple, le ClusterResourceQuotafor-name
que vous avez exporté dans la section précédente se présente comme suit :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'objet ClusterResourceQuota
for-name
applique les limites de quota pour les pods et les secrets. Le champspec.selector
applique ces limites au projet OpenShiftfrontend
.Dans la section précédente Créer un espace de noms Kubernetes, vous avez créé des espaces de noms Kubernetes correspondant à vos projets OpenShift. Utilisez ces informations pour mapper le ClusterResourceQuota aux nouveaux espaces de noms Kubernetes. Par exemple, le projet OpenShift
frontend
contient le cluster ClusterResourceQuotafor-name
. Le projet correspond à l'espace de noms Kubernetesfrontend
. Par conséquent, vous devez mapper le ClusterRessourceQuotafor-name
à l'espace de noms Kubernetesfrontend
.Pour chaque définition de quota dans le champ
quota
de ClusterResourceQuota, divisez le quota entre les espaces de noms Kubernetes auxquels vous avez mappé le ClusterResourceQuota, en fonction des critères d'intérêt. Par exemple, vous pouvez diviser les quotas définis par le ClusterResourceQuotafor-name
de manière égale entre les espaces de noms Kubernetesfrontend
.Pour chaque espace de noms Kubernetes que vous avez mappé à ClusterResourceQuota, vous créez un ResourceQuota Kubernetes qui applique le quota sur cet espace de noms. Vous définissez les montants de quota en fonction des informations que vous avez collectées à l'étape précédente. Par exemple, vous créez un ResourceQuota pour l'espace de noms Kubernetes
frontend
:apiVersion: v1 kind: ResourceQuota metadata: name: pods-secrets namespace: frontend spec: hard: pods: "10" secrets: "20"
Autre exemple : vous mappez le ClusterResourceQuota
for-name
à deux espaces de noms Kubernetes distincts,example-1
etexample-2
. Pour terminer le mappage, divisez les ressources de manière égale en créant un ResourceQuota pour les espaces de noms Kubernetes. Allouez la première moitié du ResourceQuota :apiVersion: v1 kind: ResourceQuota metadata: name: pods-secrets namespace: example-1 spec: hard: pods: "5" secrets: "10"
Après avoir alloué la première moitié du ResourceQuota, vous devez ensuite allouer la seconde moitié du ResourceQuota :
apiVersion: v1 kind: ResourceQuota metadata: name: pods-secrets namespace: example-2 spec: hard: pods: "5" secrets: "10"
Cette approche vous permet d'appliquer des limites à chaque espace de noms Kubernetes dans lequel vous créez des ResourceQuotas, au lieu de définir une seule limite pour plusieurs espaces de noms Kubernetes.
Utiliser des ResourceQuotas pour appliquer des quotas sur vos espaces de noms Kubernetes n'équivaut pas à utiliser un ClusterResourceQuota pour appliquer un quota sur tous les espaces de noms Kubernetes. Diviser un quota à l'échelle d'un cluster entre différents espaces de noms Kubernetes peut ne pas être optimal : la division peut surprovisionner les quotas pour certains espaces de noms Kubernetes et sous-provisionner les quotas pour d'autres espaces de noms Kubernetes.
Nous vous recommandons d'optimiser l'allocation de quotas en ajustant de manière dynamique la configuration des ResourceQuotas dans vos espaces de noms Kubernetes, en respectant le quota total établi dans le ClusterResourceQuota correspondant. Par exemple, vous pouvez augmenter ou diminuer de manière dynamique les montants des quotas appliqués par les ResourceQuotas pods-secrets
pour éviter le surprovisionnement ou le sous-provisionnement des quotas pour les espaces de noms Kubernetes example-1
et example-2
. Les montants totaux des quotas de la ressource pods-secrets
ne doivent pas dépasser les quotas dans la ressource ClusterResourceQuotas correspondante.
Lorsque vous configurez vos ResourceQuota, consultez les quotas et limites de GKE et les quotas et limites GKE sur VMware. Ces quotas et limites peuvent imposer des limites inférieures à celles de vos ResourceQuotas. Par exemple, GKE limite le nombre maximal de pods par nœud, quelle que soit la configuration de vos ResourceQuotas.
Créer des NetworkPolicies
Les NetNamespaces OpenShift vous permettent de configurer l'isolation du réseau entre les projets OpenShift. Les EgressNetworkPolicies OpenShift vous permettent de réguler le trafic sortant de vos clusters OpenShift. Cette section s'appuie sur des concepts de restriction du trafic.
Pour migrer vos NetNamespaces et EgressNetworkPolicies, procédez comme suit :
Évaluez vos NetNamespaces et EgressNetworkPolicies pour comprendre comment ils régulent le trafic réseau entre les projets OpenShift et le trafic sortant qui quitte vos clusters OpenShift. Par exemple, évaluez le NetNamespace et l'EgressNetworkPolicy que vous avez exportés dans la section précédente :
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
Les NetNamespaces
example-project
etexample-project-2
définissent un réseau superposé avec la même valeurnetid
de1234
. Par conséquent, les pods du projet OpenShiftexample-project
peuvent communiquer avec les pods du projet OpenShiftexample-project-2
, et inversement.L'EgressNetworkPolicy
default
définit les règles de trafic réseau suivantes :- Autorisez le trafic sortant vers le sous-réseau
1.2.3.0/24
. - Refusez le trafic sortant qui ne correspond pas à d'autres règles.
- Autorisez le trafic sortant vers le sous-réseau
Créez des NetworkPolicies et des règles OPA qui correspondent à vos exigences de restriction du trafic réseau. Par exemple,
default-np
etdefault-np-2
mettent en œuvre les règles suivantes :- Les règles appliquées par l'EgressNetworkPolicy
default
- Les règles appliquées par les NetNamespaces
example-project
etexample-project-2
dans les espaces de nom dont le libellénetid
est défini surexample-project
etexample-project-2
:
Les règles sont semblables aux suivantes :
--- 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
- Les règles appliquées par l'EgressNetworkPolicy
Gérer des ressources Kubernetes avec Config Sync
Pour gérer les ressources Kubernetes et la configuration de vos clusters GKE, nous vous recommandons d'utiliser Config Sync.
Pour savoir comment activer Config Sync sur vos clusters GKE, consultez la page Installer Config Sync.
Après avoir provisionné et configuré Config Sync dans votre environnement GKE, vous pouvez l'utiliser pour créer et appliquer automatiquement la configuration à vos clusters GKE.
Étapes suivantes
- Découvrez comment faire vos premiers pas pour la migration vers Google Cloud.
- Découvrez les bonnes pratiques concernant la création et l'exploitation des conteneurs.
- Découvrez les bonnes pratiques de mise en réseau GKE.
- Découvrez comment renforcer la sécurité de votre cluster.
- Consultez la présentation de la sécurité dans GKE.
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.