Documentation Oracle Cloud Infrastructure

Migration vers un cluster natif de réseau cloud virtuel

Découvrez comment migrer un cluster pour intégrer son adresse d'API Kubernetes dans votre propre VCN, à l'aide de Kubernetes Engine (OKE).

Dans les versions antérieures (avant le 16 mars 2021), Kubernetes Engine provisionnait des clusters avec des adresses d'API Kubernetes qui n'étaient pas intégrées à votre propre VCN. L'adresse d'API Kubernetes était publique et vous n'avez pas pu y limiter l'accès. Vous pouvez continuer à créer de tels clusters en utilisant l'interface de ligne de commande ou l'API, mais pas la console.

Après le 16 mars 2021, Kubernetes Engine peut provisionner des clusters avec leurs adresses d'API Kubernetes dans un sous-réseau de votre propre VCN (ces clusters sont connus sous le nom de "clusters natifs VCN"). Vous avez plus de flexibilité pour configurer des clusters natifs VCN afin de répondre à vos propres exigences en matière de sécurité et de réseau. Vous pouvez configurer l'adresse d'API Kubernetes pour qu'elle soit accessible en privé au sein de votre VCN (et d'un réseau appairé sur site), ou pour qu'elle soit accessible publiquement à partir d'Internet :

  • Pour rendre l'adresse d'API Kubernetes accessible de manière privée, hébergez l'adresse d'API Kubernetes dans un sous-réseau privé et ne lui affectez pas d'adresse IP publique.
  • Pour rendre l'adresse d'API Kubernetes accessible publiquement à partir d'Internet, hébergez l'adresse d'API Kubernetes dans un sous-réseau public et affectez-lui une adresse IP publique.

Vous pouvez contrôler l'accès au sous-réseau d'adresse d'API Kubernetes à l'aide de règles de sécurité définies pour des groupes de sécurité réseau (recommandé) ou de listes de sécurité.

Pour tirer parti du contrôle de sécurité offert par les clusters natifs VCN, vous pouvez migrer un cluster existant pour intégrer son adresse d'API Kubernetes dans votre propre VCN.

La migration de cluster comporte les étapes suivantes :

  • Etape 1 : migration en cours

    Pour démarrer la migration, sélectionnez le cluster à migrer, puis indiquez le VCN existant et le sous-réseau privé ou public pour héberger la nouvelle adresse d'API Kubernetes. La migration prend généralement environ 15 minutes.

    Pendant ce temps, l'API Kubernetes continue d'être accessible via l'adresse publique qui n'est pas intégrée à votre propre VCN. Toutefois, les opérations de cycle de vie de cluster (telles que les mises à jour de cluster, la création et la suppression de pools de noeuds) ne sont pas disponibles.

  • Etape 2 : la migration est terminée et en attente de la mise hors service de l'adresse d'API Kubernetes publique qui n'est pas intégrée à votre propre VCN

    Une fois la migration terminée, le cluster devient accessible via la nouvelle adresse d'API Kubernetes dans votre propre VCN, ainsi que via l'adresse d'API Kubernetes publique qui n'est pas intégrée à votre VCN. Au cours de cette période de mise hors service, mettez à jour la configuration de vos pipelines kubectl, outils et CI/CD pour utiliser la nouvelle adresse d'API Kubernetes. Par défaut, vous disposez de 30 jours pour effectuer les mises à jour, mais vous pouvez réduire la période de mise hors service à un minimum de 5 jours ou l'augmenter à plus de 30 jours. Enregistrez un ticket d'assistance si vous souhaitez réduire ou augmenter le temps avant la mise hors service de l'adresse d'API Kubernetes publique qui n'est pas intégrée à votre propre VCN.

  • Etape 3 : l'adresse d'API Kubernetes publique qui n'est pas intégrée à votre propre VCN est mise hors service

    A la fin de la période de déclassement (30 jours après la migration ou l'heure à laquelle vous demandez), le cluster cesse d'être accessible via l'adresse d'API Kubernetes publique qui n'est pas intégrée à votre VCN. Le cluster est uniquement accessible via la nouvelle adresse d'API Kubernetes intégrée à votre VCN.

Migration d'un cluster existant pour qu'il soit natif VCN

Pour migrer un cluster existant afin d'intégrer son adresse d'API Kubernetes dans votre propre VCN, procédez comme suit :

  1. Dans la page de liste Clusters, sélectionnez le nom du cluster à migrer. Si vous avez besoin d'aide pour trouver la page de liste ou le cluster, reportez-vous à Liste des clusters.

    Les libellés Migration requise apparaissent sur la page de liste Clusters en regard des noms des clusters avec des adresses d'API Kubernetes qui ne sont pas intégrés à votre VCN.

    Lorsque vous sélectionnez un cluster que vous pouvez migrer, le bouton Migrer le cluster apparaît en haut de la page Détails du cluster.

  2. Si vous voulez que l'adresse d'API Kubernetes du cluster soit accessible publiquement à partir d'Internet et hébergée dans un nouveau sous-réseau public du même VCN que le cluster (création et configuration de nouvelles ressources réseau selon les besoins), effectuez une migration automatique comme suit :
    1. En haut de la page Détails du cluster, sélectionnez Migrer le cluster pour intégrer l'adresse d'API Kubernetes du cluster dans votre propre VCN.
    2. Dans la boîte de dialogue Migrer vers un cluster natif VCN, sélectionnez Migration automatique pour créer un sous-réseau régional dans le VCN du cluster avec un bloc CIDR 10.0.0.0/28, ainsi que des listes de sécurité et des tables de routage.
    3. Sélectionnez Lancer le workflow et vérifiez le récapitulatif de la migration dans la boîte de dialogue Migration de cluster d'adresses natives VCN.
    4. Sélectionnez Migrer pour créer des ressources réseau et migrer le cluster.

      Kubernetes Engine démarre la migration du cluster, comme indiqué dans la boîte de dialogue Migration de cluster.

    5. Sélectionnez Fermer pour fermer la boîte Migration de cluster.
  3. Si vous voulez que l'adresse d'API Kubernetes du cluster soit accessible en privé dans votre VCN ou accessible publiquement à partir d'Internet, et hébergée dans un sous-réseau public ou privé régional existant dans le même VCN que le cluster, effectuez une migration personnalisée comme suit :
    1. Vérifiez que les ressources réseau suivantes existent déjà dans le VCN et sont configurées correctement pour héberger l'adresse d'API Kubernetes (si ce n'est pas le cas, créez-les et configurez-les correctement) :

      Par exemple, reportez-vous à la section Example Network Resource Configurations.

    2. En haut de la page Détails du cluster, sélectionnez Migrer le cluster pour intégrer l'adresse d'API Kubernetes du cluster dans votre propre VCN.
    3. Dans la boîte de dialogue Migrer vers un cluster natif VCN, sélectionnez Migration personnalisée.
    4. Sélectionnez Lancer le workflow et indiquez les éléments suivants :
      • Sous-réseau d'adresse d'API Kubernetes : sous-réseau régional permettant d'héberger l'adresse d'API Kubernetes du cluster. Le sous-réseau que vous indiquez peut être public ou privé. Une adresse IP privée est toujours affectée à l'adresse d'API Kubernetes. Si vous indiquez un sous-réseau public, vous pouvez éventuellement exposer l'adresse d'API Kubernetes sur Internet en affectant une adresse IP publique à l'adresse (ainsi que l'adresse IP privée). Pour simplifier la gestion des accès, Oracle recommande que l'adresse d'API Kubernetes se trouve dans un sous-réseau différent de ceux des noeuds de processus actif et des équilibreurs de charge. Pour plus d'informations, reportez-vous à Plan de contrôle de cluster Kubernetes et API Kubernetes.
      • Utiliser les groupes d'accès réseau pour le contrôle du trafic : limitez éventuellement l'accès à l'adresse d'API Kubernetes du cluster à l'aide de groupes d'accès réseau que vous indiquez. Pour plus d'informations sur les règles de sécurité à spécifier pour le groupe de sécurité système, reportez-vous àRègles de sécurité pour l'adresse d'API Kubernetes.
      • Affecter une adresse IP publique à l'adresse d'API : si vous avez sélectionné un sous-réseau public pour l'adresse d'API Kubernetes, vous pouvez éventuellement exposer l'adresse à Internet en lui affectant une adresse IP publique (ainsi que l'adresse IP privée), Si vous n'affectez pas d'adresse IP publique, mettez à jour les règles de routage et les règles de sécurité pour activer l'accès à l'adresse à l'aide d'une passerelle de service et d'une passerelle NAT (reportez-vous à Configuration de sous-réseau d'adresse d'API Kubernetes).
    5. Sélectionnez Migrer pour créer des ressources réseau et migrer le cluster.

      Le moteur Kubernetes démarre la migration du cluster.

La migration prend généralement environ 15 minutes. Pendant ce temps, l'API Kubernetes continue d'être accessible via l'adresse publique qui n'est pas intégrée à votre propre VCN. Toutefois, les opérations de cycle de vie de cluster (telles que les mises à jour de cluster, la création et la suppression de pools de noeuds) ne sont pas disponibles.

Une fois la migration terminée, la page Détails du cluster affiche le nom du sous-réseau d'adresse d'API Kubernetes, l'adresse IP de l'adresse privée d'API Kubernetes et (si vous avez affecté une adresse IP publique à l'adresse d'API Kubernetes) l'adresse IP de l'adresse publique d'API Kubernetes.

La page Détails du cluster indique également que vous disposez de 30 jours pour mettre à jour la configuration de vos pipelines kubectl, d'outils et d'intégration continue et de déploiement continu afin d'accéder à la nouvelle adresse d'API Kubernetes (reportez-vous à Configuration de l'accès à un cluster migré). Au cours de cette période de mise hors service, le cluster nouvellement migré est accessible via la nouvelle adresse d'API Kubernetes dans votre VCN et via l'adresse d'API Kubernetes publique qui n'est pas intégrée à votre propre VCN.

Configuration de l'accès à un cluster migré

Après avoir migré un cluster pour intégrer son adresse d'API Kubernetes dans votre propre VCN, vous devez mettre à jour la configuration de votre kubectl, de vos outils et de vos pipelines d'intégration continue et de déploiement continu pour utiliser la nouvelle adresse d'API Kubernetes. Au minimum, vous devez mettre à jour le fichier de configuration Kubernetes du cluster (communément appelé fichier kubeconfig) pour permettre l'accès au cluster migré à l'aide de kubectl, comme décrit dans cette rubrique. Vous devez également mettre à jour les fichiers manifestes qui incluent des références à l'adresse IP de l'adresse d'API Kubernetes du cluster.

Suivez les instructions de cette rubrique pour générer un nouveau fichier kubeconfig. Ces instructions partent du principe que le fichier kubeconfig du cluster est enregistré à l'emplacement par défaut ($HOME/.kube) et avec le nom par défaut (config). Si ce n'est pas le cas, adaptez les instructions en conséquence.

  1. Dans la fenêtre de terminal dans laquelle vous exécutez normalement les commandes de l'interface de ligne de commande Oracle Cloud Infrastructure, exécutez la commande suivante pour mettre à jour le fichier kubeconfig existant du cluster :

    oci ce cluster create-kubeconfig --cluster-id <cluster-ocid> --file <kubeconfig-file-location> --region <region-name> --token-version 2.0.0 --kube-endpoint PRIVATE_ENDPOINT|PUBLIC_ENDPOINT

    où :

    • --cluster-id <cluster-ocid> est l'OCID du cluster existant à rendre VCN natif.
    • --file <kubeconfig-file-location> est l'emplacement du fichier kubeconfig du cluster.
    • --region <region-name> est la région dans laquelle se trouve le cluster.
    • --kube-endpoint PRIVATE_ENDPOINT|PUBLIC_ENDPOINT indique si l'adresse IP privée ou l'adresse IP publique de l'adresse d'API Kubernetes du cluster doit être ajoutée au fichier kubeconfig. Pour plus d'informations, reportez-vous à Plan de contrôle de cluster Kubernetes et API Kubernetes.

    Par exemple :

    oci ce cluster create-kubeconfig --cluster-id ocid1.cluster.oc1.phx.aaaaaaaaae... --file $HOME/.kube/config --region us-phoenix-1 --token-version 2.0.0 --kube-endpoint PUBLIC_ENDPOINT

    En supposant que le fichier kubeconfig existe déjà à l'emplacement que vous indiquez, les détails relatifs au cluster sont ajoutés en tant que nouveau contexte au fichier kubeconfig existant, y compris la nouvelle adresse d'API Kubernetes du cluster dans votre propre VCN. L'élément current-context: du fichier kubeconfig est défini pour pointer vers le contexte nouvellement ajouté.

    Pour plus d'informations sur la configuration du fichier kubeconfig, reportez-vous à Configuration de l'accès au cluster.

  2. Vérifiez que kubectl peut se connecter au cluster à l'aide de l'adresse d'API Kubernetes dans votre propre VCN en saisissant la commande suivante :

    kubectl get nodes

    Les informations relatives aux noeuds du cluster apparaissent.

    Vous pouvez désormais utiliser kubectl pour effectuer des opérations sur le cluster à l'aide de l'adresse d'API Kubernetes dans votre propre VCN.

Remarque

Tant que l'adresse d'API d'origine qui n'est pas intégrée à votre VCN n'est pas mise hors service, vous pouvez continuer à générer le fichier kubeconfig d'origine en omettant l'option --kube-endpoint de la commande oci ce cluster create-kubeconfig.

Foire aux questions sur la migration de cluster

Que sont les clusters VCN natifs ?

Kubernetes Engine crée des clusters Kubernetes entièrement intégrés à votre réseau cloud virtuel (VCN) Oracle Cloud Infrastructure. Les noeuds de processus actif, les équilibreurs de charge et l'adresse d'API Kubernetes font partie de votre propre VCN, et vous pouvez les configurer en tant que publics ou privés. Ces clusters qui sont entièrement intégrés à votre propre VCN sont connus sous le nom de "clusters natifs VCN".

Comment savoir si un cluster est déjà un cluster natif VCN ?

Si vous ne savez pas si un cluster est déjà un cluster natif VCN, affichez les informations sur le cluster (par exemple, sur la page Détails du cluster de la console). Si le cluster est déjà un cluster natif VCN, les détails du cluster incluent des informations sur l'adresse d'API Kubernetes. Si le cluster n'est pas encore un cluster natif VCN, les détails du cluster incluent simplement l'adresse Kubernetes.

Dois-je migrer tous mes clusters existants ?

Non, il vous suffit de migrer les clusters existants que vous souhaitez transformer en clusters natifs VCN. Si vous ne voulez pas intégrer l'adresse d'API Kubernetes d'un cluster dans votre propre VCN, ne migrez simplement pas ce cluster.

La migration implique-t-elle un temps d'inactivité ?

Pendant la migration d'un cluster vers un cluster natif VCN, l'API Kubernetes du cluster reste accessible via l'adresse publique qui n'est pas intégrée à votre propre VCN. Toutefois, les opérations de cycle de vie de cluster (telles que les mises à jour de cluster, la création et la suppression de pools de noeuds) ne sont pas disponibles.

Dois-je choisir la migration automatique ou la migration personnalisée ?

La migration automatique crée un sous-réseau régional dans le VCN du cluster avec un bloc CIDR 10.0.0.0/28, ainsi que des listes de sécurité et des tables de routage. Une adresse IP publique est affectée au sous-réseau et à l'adresse d'API. La migration automatique prend uniquement en charge les clusters avec des pools de noeuds dans le même compartiment que le cluster. Pour les clusters avec des pools de noeuds dans différents compartiments, effectuez une migration personnalisée.

La migration personnalisée vous permet de choisir un sous-réseau régional public ou privé existant pour héberger l'adresse d'API Kubernetes du cluster. Si vous choisissez un sous-réseau régional public, vous pouvez éventuellement exposer l'adresse d'API Kubernetes à Internet en affectant une adresse IP publique à l'adresse. Vous pouvez éventuellement choisir d'utiliser des groupes de sécurité réseau.

Comment configurer un sous-réseau dans mon VCN pour héberger l'adresse d'API Kubernetes ?

Pour plus d'informations sur la configuration du sous-réseau d'adresse d'API Kubernetes, des listes de sécurité et de la table de routage, reportez-vous à Configuration de ressources réseau pour la création et le déploiement de clusters.

Je veux tester la migration vers un cluster natif VCN. Comment créer un cluster avec une adresse d'API Kubernetes qui n'est pas intégrée à mon VCN ?

Dans la fenêtre de terminal où vous exécutez normalement les commandes de l'interface de ligne de commande Oracle Cloud Infrastructure, exécutez la commande suivante pour créer un cluster de test avec une adresse d'API Kubernetes qui n'est pas intégrée à votre VCN :

oci ce cluster create --compartment-id <compartment-ocid> --kubernetes-version v<kubernetes-version-number> --name <cluster-name> --vcn-id <vcn-ocid>

où :

  • --compartment-id <compartment-ocid> est l'OCID du compartiment auquel le cluster de test doit appartenir.
  • --kubernetes-version v<kubernetes-version-number> est une version prise en charge de Kubernetes (reportez-vous à Versions de Kubernetes actuellement prises en charge). Par exemple, --kubernetes-version v1.19.7
  • --name <cluster-name> est le nom de votre choix pour le cluster de test. Par exemple, --name test-vcn-native-migration
  • --vcn-id <vcn-ocid> est l'OCID du VCN dans lequel créer le cluster de test.

Après avoir créé un cluster de test avec une adresse d'API Kubernetes qui n'est pas intégrée à votre VCN, vous pouvez désormais migrer le cluster de test pour en faire un cluster natif VCN. Reportez-vous à Migration d'un cluster existant pour qu'il soit natif VCN.

N'oubliez pas de supprimer le cluster de test lorsque vous n'en avez plus besoin.

Comment augmenter ou réduire le temps jusqu'à la mise hors service de l'adresse d'API Kubernetes publique qui n'est pas intégrée à mon propre VCN ?

La période de mise hors service correspond à la durée pendant laquelle un cluster nouvellement migré est accessible via la nouvelle adresse d'API Kubernetes dans votre propre VCN et via l'adresse d'API publique qui n'a pas été intégrée à votre VCN. La période de mise hors service garantit l'absence de temps d'inactivité lors de la mise à jour de la configuration de kubectl, des outils et des pipelines d'intégration continue et de déploiement continu pour utiliser la nouvelle adresse d'API Kubernetes.

La période de mise hors service commence dès que Kubernetes Engine a migré le cluster pour intégrer son adresse d'API Kubernetes dans votre propre VCN. Par défaut, vous disposez de 30 jours pour effectuer les mises à jour, mais vous pouvez réduire la période de mise hors service à 5 jours ou l'augmenter à plus de 30 jours. Enregistrez un ticket d'assistance si vous souhaitez réduire ou augmenter la période de mise hors service et spécifiez :

  • Récapitulatif : Request to modify Reclamation Extension in <region-name>
  • Région : <region-name>
  • Composant : Control Plane
  • Détails : incluez les éléments suivants :
    • Tenancy: <tenancy-name>
    • Tenancy Id: <tenancy-ocid>
    • Cluster: <cluster-name>
    • Cluster Id: <cluster-ocid>
    • Requested expiration date/time: <date-and-time>