Documentation sur Oracle Cloud Infrastructure

Migration vers des grappes natives du réseau en nuage virtuel

Découvrez comment migrer une grappe pour intégrer son point d'extrémité 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 a provisionné des grappes avec des points d'extrémité d'API Kubernetes qui n'étaient pas intégrés à votre propre VCN. Le point d'extrémité de l'API Kubernetes était public et vous ne pouvez pas y restreindre l'accès. Vous pouvez continuer à créer de telles grappes à l'aide de la CLI ou de l'API (jusqu'à la date spécifiée dans l'annonce de modification du service ici), mais pas de la console.

Après le 16 mars 2021, Kubernetes Engine peut provisionner des grappes avec leurs points d'extrémité d'API Kubernetes dans un sous-réseau de votre propre VCN (ces grappes sont appelées "grappes natives de VCN"). Vous disposez de plus de flexibilité pour configurer des grappes natives de VCN afin de répondre à vos propres exigences en matière de sécurité et de réseau. Vous pouvez configurer le point d'extrémité de l'API Kubernetes pour qu'il soit accessible de manière privée au sein de votre VCN (et d'un réseau appairé sur place), ou pour qu'il soit accessible de manière publique à partir d'Internet :

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

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

Pour tirer parti du contrôle de sécurité offert par les grappes natives de VCN, vous pouvez migrer une grappe existante afin d'intégrer son point d'extrémité d'API Kubernetes à votre propre VCN.

La migration de grappe comprend les étapes suivantes :

  • Étape 1 : Migrer la grappe

    Vous commencez la migration en sélectionnant la grappe à migrer, puis en spécifiant le VCN existant et le sous-réseau privé ou public pour héberger le nouveau point d'extrémité d'API Kubernetes. La migration dure généralement environ 15 minutes.

    Pendant ce temps, l'API Kubernetes continue d'être accessible au moyen du point d'extrémité public initial qui n'est pas intégré à votre propre VCN. Toutefois, les opérations de cycle de vie des grappes (telles que les mises à jour des grappes, la création et la suppression de groupes de noeuds) ne sont pas disponibles.

    Voir Migration d'une grappe existante vers un réseau VCN natif.

  • Étape 2 : Configurer l'accès à la grappe migrée

    Une fois la migration terminée, la grappe devient accessible au moyen du nouveau point d'extrémité d'API Kubernetes dans votre propre VCN, ainsi qu'au moyen du point d'extrémité d'API Kubernetes public initial qui n'est pas intégré à votre VCN. Vous pouvez maintenant mettre à jour la configuration de vos pipelines kubectl, d'outils et d'intégration et développement en continu pour utiliser le nouveau point d'extrémité d'API Kubernetes.

    Pour vérifier que vous avez correctement mis à jour vos pipelines kubectl, outils et intégration et développement en continu, vous avez la possibilité de mettre hors service temporairement le point d'extrémité d'API Kubernetes public initial, de tester l'utilisation par les configurations mises à jour du nouveau point d'extrémité d'API Kubernetes, puis d'annuler la mise hors service du point d'extrémité initial.

    Voir Configuration de l'accès à une grappe migrée.

  • Étape 3 : Mettre hors service le point d'extrémité d'API Kubernetes public initial qui n'est pas intégré à votre propre VCN

    Lorsque vous êtes sûr d'avoir correctement mis à jour la configuration de vos kubectl, outils et pipelines d'intégration et de développement en continu pour utiliser le nouveau point d'extrémité d'API Kubernetes dans votre propre VCN, vous pouvez mettre hors service le point d'extrémité d'API Kubernetes public initial qui n'est pas intégré à votre VCN. Lorsque vous mettez hors service le point d'extrémité de l'API Kubernetes initial, la grappe n'est accessible qu'au moyen du nouveau point d'extrémité de l'API Kubernetes. La mise hors service prend généralement moins de cinq minutes.

    Notez que si vous ne mettez pas explicitement hors service le point d'extrémité initial, la grappe continue d'être accessible au moyen du point d'extrémité initial et du nouveau point d'extrémité.

    Après la mise hors service du point d'extrémité d'origine, vous disposez d'un certain nombre de jours pendant lesquels vous pouvez annuler la mise hors service et réactiver ce point d'extrémité d'origine. La période de repositionnement par défaut est de 30 jours, mais vous pouvez l'augmenter jusqu'à un maximum de 60 jours.

    Voir Désactivation du point d'extrémité d'API Kubernetes public initial d'une grappe migrée.

Migration d'une grappe existante en tant que grappe native du VCN

Utilisation de la console

Pour migrer une grappe existante vers un VCN en la rendant accessible au moyen d'un nouveau point d'extrémité d'API Kubernetes dans votre VCN :

  1. Dans la page de liste Grappes, sélectionnez le nom de la grappe à migrer. Si vous avez besoin d'aide pour trouver la page de liste ou la grappe, voir Liste des grappes.

    Les étiquettes Migration requise apparaissent dans la page de liste Grappes à côté des noms des grappes avec des points d'extrémité d'API Kubernetes qui ne sont pas intégrés à votre VCN.

    Lorsque vous sélectionnez une grappe que vous pouvez migrer, le bouton Migrer la grappe s'affiche en haut de l'onglet Détails de la grappe.

  2. Si vous voulez que le point d'extrémité de l'API Kubernetes de la grappe soit accessible publiquement à partir d'Internet et hébergé dans un nouveau sous-réseau public dans le même VCN que la grappe (création et configuration de nouvelles ressources de réseau selon les besoins), effectuez une migration automatique comme suit :
    1. En haut de l'onglet Détails de la grappe, sélectionnez Migrer la grappe pour intégrer le point d'extrémité de l'API Kubernetes de la grappe dans votre propre VCN.
    2. Dans la boîte de dialogue Migrer vers une grappe native du réseau en nuage virtuel (VCN), sélectionnez Migration automatique pour créer un nouveau sous-réseau régional dans le VCN de la grappe 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 flux de travail et vérifiez le sommaire de migration dans la boîte de dialogue Migration de grappe de points d'extrémité natifs de VCN.
    4. Sélectionnez Migrer pour créer de nouvelles ressources de réseau et migrer la grappe.

      Kubernetes Engine commence la migration de la grappe, comme illustré dans la boîte de dialogue Migration de grappe.

    5. Sélectionnez Fermer pour fermer la boîte de dialogue Migration de grappe.
  3. Si vous voulez que le point d'extrémité de l'API Kubernetes de la grappe soit accessible en privé dans votre VCN ou accessible publiquement à partir d'Internet, et hébergé dans un sous-réseau public ou privé régional existant dans le même VCN que la grappe, effectuez une migration personnalisée comme suit :
    1. Vérifiez que les ressources de réseau suivantes existent déjà dans le VCN et qu'elles sont configurées correctement pour héberger le point d'extrémité de l'API Kubernetes (si ce n'est pas le cas, créez-les et configurez-les de manière appropriée) : Par exemple, des configurations, voir Exemples de configurations de ressources de réseau.
    2. En haut de l'onglet Détails de la grappe, sélectionnez Migrer la grappe pour intégrer le point d'extrémité de l'API Kubernetes de la grappe dans votre propre VCN.
    3. Dans la boîte de dialogue Migrer vers une grappe native du réseau en nuage virtuel (VCN), sélectionnez Migration personnalisée.
    4. Sélectionnez Lancer le flux de travail et spécifiez :
      • Sous-réseau de point d'extrémité d'API Kubernetes : Sous-réseau régional qui héberge le point d'extrémité de l'API Kubernetes de la grappe. Le sous-réseau que vous spécifiez peut être public ou privé. Une adresse IP privée est toujours affectée au point d'extrémité de l'API Kubernetes. Si vous spécifiez un sous-réseau public, vous pouvez éventuellement exposer le point d'extrémité de l'API Kubernetes à Internet en affectant une adresse IP publique au point d'extrémité (ainsi que l'adresse IP privée). Pour simplifier la gestion des accès, Oracle recommande que le point d'extrémité de l'API Kubernetes se trouve dans un sous-réseau différent des noeuds de travail et des équilibreurs de charge. Pour plus d'informations, voir Plan de contrôle de grappe Kubernetes et API Kubernetes.
      • Utiliser les groupes de sécurité de réseau pour contrôler le trafic : Facultativement, limitez l'accès au point d'extrémité de l'API Kubernetes de la grappe à l'aide d'un ou plusieurs groupes de sécurité de réseau que vous spécifiez. Pour plus d'informations sur les règles de sécurité à spécifier pour le groupe de sécurité de réseau, voir Règles de sécurité pour le point d'extrémité de l'API Kubernetes.
      • Affecter une adresse IP publique au point d'extrémité d'API : Si vous avez sélectionné un sous-réseau public pour le point d'extrémité de l'API Kubernetes, vous pouvez éventuellement exposer le point d'extrémité à Internet en affectant une adresse IP publique au point d'extrémité (ainsi qu'une 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 permettre l'accès au point d'extrémité à l'aide d'une passerelle de service et d'une passerelle NAT (voir Configuration du sous-réseau du point d'extrémité de l'API Kubernetes).
    5. Sélectionnez Migrer pour créer de nouvelles ressources de réseau et migrer la grappe.

      Le moteur Kubernetes commence la migration de la grappe.

La migration prend généralement environ 15 minutes. Pendant ce temps, l'API Kubernetes continue d'être accessible au moyen du point d'extrémité public initial qui n'est pas intégré à votre propre VCN. Toutefois, les opérations de cycle de vie des grappes (telles que les mises à jour des grappes, la création et la suppression de groupes de noeuds) ne sont pas disponibles.

Une fois la migration terminée, l'onglet Détails de la grappe affiche le nom du sous-réseau de point d'extrémité de l'API Kubernetes, l'adresse IP du point d'extrémité privé de l'API Kubernetes et (si vous avez affecté une adresse IP publique au point d'extrémité de l'API Kubernetes) l'adresse IP du point d'extrémité public de l'API Kubernetes.

Un message indique que la grappe a été migrée et qu'elle est en attente de la mise hors service du point d'extrémité de l'API publique. À ce stade, la grappe nouvellement migrée est accessible au moyen du nouveau point d'extrémité d'API Kubernetes dans votre VCN et au moyen du point d'extrémité d'API Kubernetes public initial qui n'est pas intégré à votre propre VCN.

Utilisation de l'interface de ligne de commande

Utilisez la commande oci ce cluster cluster-migrate-to-native-vcn et les paramètres requis pour migrer une grappe existante afin d'intégrer son point d'extrémité d'API Kubernetes dans votre propre VCN :

oci ce cluster cluster-migrate-to-native-vcn --cluster-id <cluster-ocid> --endpoint-config "{\"subnetId\":\"<kube-api-endpoint-subnet-ocid>\"}" [OPTIONS]

Pour la liste complète des paramètres et des valeurs pour les commandes de l'interface de ligne de commande, voir .

Utilisation de l'API

Exécutez l'opération ClusterMigrateToNativeVcn pour migrer une grappe afin d'intégrer son point d'extrémité d'API Kubernetes dans votre propre VCN.

Configuration de l'accès à une grappe migrée

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

Suivez les instructions de cette rubrique pour générer un nouveau fichier kubeconfig. Ces instructions supposent que le fichier kubeconfig de la grappe 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 où 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 de la grappe :

    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 de la grappe existante que vous voulez rendre native pour le VCN.
    • --file <kubeconfig-file-location> est l'emplacement du fichier kubeconfig de la grappe.
    • --region <region-name> est la région dans laquelle se trouve la grappe.
    • --kube-endpoint PRIVATE_ENDPOINT|PUBLIC_ENDPOINT indique si l'adresse IP privée ou l'adresse IP publique du point d'extrémité de l'API Kubernetes de la grappe doit être ajoutée au fichier kubeconfig. Pour plus d'informations, voir Plan de contrôle de grappe 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 spécifié, les détails de la grappe sont ajoutés en tant que nouveau contexte au fichier kubeconfig existant, y compris le nouveau point d'extrémité de l'API Kubernetes de la grappe dans votre propre VCN. L'élément current-context: du fichier kubeconfig est défini de manière à pointer vers le contexte qui vient d'être ajouté.

    Pour plus d'informations sur la configuration du fichier kubeconfig, voir Configuration de l'accès aux grappes.

  2. Vérifiez que kubectl peut se connecter à la grappe à l'aide du nouveau point d'extrémité d'API Kubernetes de la grappe en entrant la commande suivante :

    kubectl get nodes

    Les informations sur les noeuds de la grappe s'affichent.

    Vous pouvez maintenant utiliser kubectl pour effectuer des opérations sur la grappe à l'aide du nouveau point d'extrémité d'API Kubernetes de la grappe.

Note

Tant que le point d'extrémité d'API initial qui n'est pas intégré à votre réseau VCN n'est pas mis hors service, vous pouvez continuer à générer le fichier kubeconfig initial en omettant l'option --kube-endpoint de la commande oci ce cluster create-kubeconfig.

Mise hors service du point d'extrémité d'API Kubernetes public initial d'une grappe migrée

Utilisation de la console

Pour mettre hors service le point d'extrémité d'API Kubernetes public initial qui n'est pas intégré à votre propre VCN :

  1. En haut de l'onglet Détails de la grappe, sélectionnez Déconnexion lorsque vous voulez :

    • Mettez temporairement hors service le point d'extrémité initial, testez que les configurations mises à jour utilisent le nouveau point d'extrémité d'API Kubernetes, puis repositionnez la mise hors service.
    • Mettre définitivement hors service le point d'extrémité initial.

    La mise hors service prend généralement moins de cinq minutes. Une fois la mise hors service terminée, une période d'annulation par défaut de 30 jours est ajoutée. Pendant la période d'annulation, vous pouvez :

    • restaurer le point d'extrémité initial
    • prolonger la période de repositionnement
    Important

    Une fois la période d'annulation terminée, vous ne pouvez plus annuler la mise hors service du point d'extrémité d'origine. Le point d'extrémité initial est définitivement mis hors service et le processus de mise hors service ne peut pas être annulé.

  2. (Facultatif) Sélectionnez Repositionner pour repositionner la mise hors service et restaurer le point d'extrémité initial. Le repositionnement prend généralement moins de cinq minutes.
  3. (Facultatif) Sélectionnez Prolonger la date limite de repositionnement pour augmenter la période de repositionnement à un maximum de 60 jours.

Utilisation de l'interface de ligne de commande

Utilisez la commande oci ce cluster start-public-api-endpoint-decommission et les paramètres requis pour mettre hors service le point d'extrémité initial d'une grappe :

oci ce cluster start-public-api-endpoint-decommission --cluster-id <cluster-ocid> [OPTIONS]

Utilisez la commande oci ce cluster rollback-public-api-endpoint-decommission et les paramètres requis pour annuler le déclassement du point d'extrémité initial d'une grappe :

oci ce cluster rollback-public-api-endpoint-decommission --cluster-id <cluster-ocid> [OPTIONS]

Utilisez la commande oci ce cluster extension-endpoint-decommission-rollback-deadline et les paramètres requis pour augmenter la période de repositionnement lors de la mise hors service du point d'extrémité initial d'une grappe :

oci ce cluster extend-endpoint-decommission-rollback-deadline --cluster-id <cluster-ocid> --rollback-deadline-delay <duration> [OPTIONS]

où --rollback-deadline-delay <delay> spécifie une durée au format ISO 8601. Par exemple, --rollback-deadline-delay P10d pour augmenter la période de repositionnement de 10 jours.

Pour la liste complète des paramètres et des valeurs pour les commandes de l'interface de ligne de commande, voir .

Foire aux questions sur la migration de grappes

Que sont les grappes natives du VCN?

Le moteur Kubernetes crée des grappes Kubernetes qui sont complètement intégrées dans votre réseau en nuage virtuel (VCN) Oracle Cloud Infrastructure. Les noeuds de travail, les équilibreurs de charge et le point d'extrémité de l'API Kubernetes font partie de votre propre VCN, et vous pouvez les configurer comme publics ou privés. Les grappes entièrement intégrées dans votre propre VCN sont dites "natives du VCN".

Comment savoir si une grappe est déjà une grappe native du VCN?

Si vous ne savez pas si une grappe est déjà une grappe native du réseau en nuage virtuel (VCN), consultez les informations sur la grappe (par exemple, dans l'onglet Détails de la grappe de la console). Si la grappe est déjà une grappe native du VCN, les détails de la grappe incluent des informations sur le point d'extrémité de l'API Kubernetes. Si la grappe n'est pas encore une grappe native du réseau en nuage virtuel (VCN), les détails de la grappe incluent simplement l'adresse Kubernetes.

Dois-je migrer toutes mes grappes existantes?

Non, vous n'avez qu'à migrer les grappes existantes que vous voulez transformer en grappes natives de VCN. Si vous ne voulez pas intégrer le point d'extrémité de l'API Kubernetes d'une grappe dans votre propre VCN, il vous suffit de ne pas migrer cette grappe.

La migration implique-t-elle un temps d'arrêt?

Pendant la migration d'une grappe vers une grappe native du réseau en nuage virtuel (VCN), l'API Kubernetes de la grappe continue d'être accessible au moyen du point d'extrémité public initial qui n'est pas intégré à votre propre VCN. Toutefois, les opérations de cycle de vie des grappes (telles que les mises à jour des grappes, la création et la suppression de groupes 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 de la grappe avec un bloc CIDR 10.0.0.0/28, ainsi que des listes de sécurité et des tables de routage. Le sous-réseau est public et une adresse IP publique est affectée au point d'extrémité de l'API. La migration automatique prend uniquement en charge les grappes avec des groupes de noeuds dans le même compartiment que la grappe. Pour les grappes avec des groupes de noeuds dans des compartiments différents, 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 le point d'extrémité de l'API Kubernetes de la grappe. Si vous choisissez un sous-réseau régional public, vous pouvez éventuellement exposer le point d'extrémité de l'API Kubernetes à Internet en affectant une adresse IP publique au point d'extrémité. Vous pouvez éventuellement choisir d'utiliser des groupes de sécurité de réseau.

Comment configurer un sous-réseau dans mon réseau VCN pour héberger le point d'extrémité de l'API Kubernetes?

Reportez-vous à Configuration des ressources de réseau pour la création et le déploiement de grappes pour plus de détails sur la configuration du sous-réseau de point d'extrémité de l'API Kubernetes, des listes de sécurité et de la table de routage.

Je veux tester la migration vers une grappe native du VCN. Comment créer une grappe avec un point d'extrémité d'API Kubernetes qui n'est pas intégré à mon réseau VCN?

Dans la fenêtre de terminal où vous exécutez normalement les commandes de l'interface de ligne de commande Oracle Cloud Infrastructure (et jusqu'à la date spécifiée dans l'annonce de modification de service ici), exécutez la commande suivante pour créer une grappe de test avec un point d'extrémité d'API Kubernetes qui n'est pas intégré à 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 vous voulez que la grappe de test appartienne.
  • --kubernetes-version v<kubernetes-version-number> est une version prise en charge de Kubernetes (voir Versions de Kubernetes actuellement prises en charge). Par exemple, --kubernetes-version v1.19.7
  • --name <cluster-name> est le nom de votre choix pour la grappe de test. Par exemple, --name test-vcn-native-migration
  • --vcn-id <vcn-ocid> est l'OCID du VCN dans lequel créer la grappe de test.

Après avoir créé une grappe de test avec un point d'extrémité d'API Kubernetes qui n'est pas intégré à votre VCN, vous pouvez maintenant migrer la grappe de test pour en faire une grappe native du VCN. Voir Migration d'une grappe existante pour qu'elle soit native du VCN.

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