Migrer des conteneurs vers Google Cloud : migrer des projets OpenShift vers GKE Enterprise

Last reviewed 2022-01-24 UTC

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 :

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 :

Pour migrer la configuration de projet OpenShift et les ressources associées vers GKE Enterprise, nous vous recommandons d'effectuer les opérations suivantes :

  1. Exporter les descripteurs de ressource de configuration du projet OpenShift.
  2. Mapper les ressources de configuration de projet OpenShift à des ressources Kubernetes
  3. Créer des ressources Kubernetes qui correspondent à des ressources de configuration de projet OpenShift
  4. 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 :

  1. Exportez les descripteurs de projet OpenShift.
  2. Exportez les descripteurs de ressources à l'échelle d'un cluster.
  3. 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 :

  1. 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éfixe openshift.io
    • metadata.creationTimestamp
    • metadata.generation
    • metadata.managedFields
    • metadata.resourceVersion
    • metadata.selfLink
    • metadata.uid
    • status

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

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

  2. 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 OpenShift example-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 fichier project-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 :

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

  2. 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 fichier clusterresourcequota-for-name.yaml.

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

  4. 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 fichier clusterrole-admin.yaml.

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

  6. 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 fichier clusterrolebinding-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 :

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

  2. 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 fichier netnamespace-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.

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

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

  3. 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 fichier resourcequota-gpu-quota.yaml.

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

  5. 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 fichier role-example.yaml.

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

  7. 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 fichier rolebinding-example.yaml.

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

  9. 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 fichier egressnetworkpolicy-default.yaml.

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

  11. 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 fichier networkpolicy-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 :

  1. Évaluez les quantités de ressources de l'inventaire qui sont des ressources Kubernetes ou des ressources OpenShift.
  2. 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 :

  1. Mappez le ClusterResourceQuota aux projets OpenShift en évaluant les champs spec.quota et spec.selector du ClusterResourceQuota. Par exemple, le ClusterResourceQuota for-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 champ spec.selector applique ces limites au projet OpenShift frontend.

  2. 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 ClusterResourceQuota for-name. Le projet correspond à l'espace de noms Kubernetes frontend. Par conséquent, vous devez mapper le ClusterRessourceQuota for-name à l'espace de noms Kubernetes frontend.

  3. 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 ClusterResourceQuota for-name de manière égale entre les espaces de noms Kubernetes frontend.

  4. 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 et example-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 :

  1. É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 et example-project-2 définissent un réseau superposé avec la même valeur netid de 1234. Par conséquent, les pods du projet OpenShift example-project peuvent communiquer avec les pods du projet OpenShift example-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.

  2. Créez des NetworkPolicies et des règles OPA qui correspondent à vos exigences de restriction du trafic réseau. Par exemple, default-np et default-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 et example-project-2 dans les espaces de nom dont le libellé netid est défini sur example-project et example-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

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