Documentation Oracle Cloud Infrastructure

Dépannage des problèmes de configuration réseau pour les clusters Kubernetes à l'aide des tests d'analyse de chemin réseau

Découvrez comment utiliser les tests d'analyse de chemin réseau pour vous aider à résoudre les problèmes de connectivité réseau avec les clusters créés à l'aide de Kubernetes Engine (OKE).

Pour qu'un cluster que vous créez avec Kubernetes Engine fonctionne correctement, les ressources réseau indiquées pour le cluster doivent être configurées de manière appropriée. Lorsque vous créez un cluster à l'aide du workflow de création rapide, Kubernetes Engine crée et configure des ressources réseau pour vous, conformément aux directives décrites dans Configuration des ressources réseau pour la création et le déploiement de clusters. Toutefois, lorsque vous créez un cluster à l'aide du workflow de création personnalisée, vous indiquez les ressources réseau existantes que le nouveau cluster doit utiliser. Ces ressources doivent être configurées de manière appropriée pour permettre la communication réseau avec le cluster et pour permettre à différents composants du cluster de communiquer entre eux.

La configuration des ressources réseau pour les clusters Kubernetes peut devenir compliquée. Le moteur Kubernetes fournit donc un certain nombre de tests d'analyse de chemin réseau prédéfinis pour résoudre les problèmes de configuration réseau. Ces tests d'analyse de chemin examinent les topologies de réseau virtuel, parcourent plusieurs tables de routage et examinent les règles de sécurité dans les groupes de sécurité réseau et les listes de sécurité. Aucun trafic réel n'est envoyé, mais la configuration est examinée et utilisée pour vérifier l'accessibilité.

A l'aide des tests d'analyse de chemin, vous pouvez déterminer si une ressource OCI peut atteindre une autre ressource OCI (connectivité unidirectionnelle de la source vers la destination) et si deux ressources OCI peuvent atteindre l'autre (connectivité bidirectionnelle). Par exemple, vous pouvez utiliser un test d'analyse de chemin pour déterminer si un pod dans un cluster Kubernetes qui utilise le module d'extension CNI de mise en réseau de pod natif VCN peut atteindre les services OCI, et inversement.

Lorsque vous utilisez la console, vous pouvez sélectionner les tests d'analyse de chemin prédéfinis dans l'écran Détails du cluster. Pour plus d'informations sur les tests d'analyse de chemin prédéfinis disponibles, reportez-vous à Tests d'analyse de chemin prédéfinis.

Chaque test d'analyse de chemin prédéfini nécessite un certain nombre de paramètres de test différents. Lorsque vous exécutez un test, en fonction du test sélectionné, les valeurs par défaut de tout ou partie des paramètres de test sont dérivées des propriétés des ressources utilisées par le cluster. Dans certains cas, vous pouvez modifier les valeurs par défaut. Vous devez fournir des valeurs pour les paramètres de test qui n'ont pas de valeurs par défaut. Après avoir exécuté un test d'analyse de chemin prédéfini, vous pouvez enregistrer les résultats sous forme de fichier JSON, ce qui vous permet de comparer les résultats de test au fil du temps. Pour plus d'informations sur l'exécution de tests d'analyse de chemin prédéfinis pour un cluster, reportez-vous à Exécution de tests d'analyse de chemin prédéfinis.

Les tests d'analyse de chemin sont optimisés par Oracle Cloud Infrastructure Network Path Analyzer (NPA), qui identifie les problèmes de configuration de réseau virtuel ayant un impact sur la connectivité. Outre les tests d'analyse de chemin prédéfinis disponibles dans l'écran Détails du cluster, vous pouvez également créer vos propres tests d'analyse de chemin personnalisés à l'aide de l'outil NPA. Pour plus d'informations sur les NPA, y compris les autorisations requises pour exécuter les NPA, et sur la création et l'exécution de tests d'analyse de chemin avec les NPA, reportez-vous à Analyseur de chemin réseau.

Stratégies IAM requises pour exécuter les tests d'analyse de chemin

Pour exécuter des tests d'analyse de chemin afin de vérifier les chemins réseau d'un cluster Kubernetes que vous avez créé à l'aide de Kubernetes Engine, vous devez appartenir à un groupe autorisé à utiliser Network Path Analyzer (NPA). L'analyseur de chemin réseau doit également être autorisé à accéder à diverses ressources réseau.

Pour connaître les droits d'accès à accorder et la stratégie IAM recommandée, reportez-vous à Droits d'accès requis dans la documentation Network Path Analyzer.

Tests d'analyse de chemin prédéfinis

Vous pouvez utiliser différents tests d'analyse de chemin prédéfinis pour vérifier les chemins réseau d'un cluster Kubernetes que vous avez créé à l'aide de Kubernetes Engine. Dans la console, vous pouvez filtrer la liste des tests d'analyse de chemin par :

  • le type de problème à vérifier (par exemple, échecs DNS, échec du plan de contrôle Kubernetes, échec de l'inscription des noeuds)
  • chemins essentiels, recommandés ou facultatifs pour le bon fonctionnement de Kubernetes Engine

Les tests sont regroupés dans les grandes catégories de tests suivantes :

  • Tests d'API de cluster : utilisez cette option pour vérifier que des chemins sont disponibles afin de permettre à l'adresse d'API Kubernetes du cluster de communiquer de manière bidirectionnelle avec d'autres composants de cluster et emplacements réseau.
  • Tests de noeud : permet de vérifier que des chemins sont disponibles pour permettre aux noeuds de processus actif du plan de données Kubernetes de communiquer de manière bidirectionnelle avec d'autres composants de cluster et emplacements réseau.
  • Tests de pod : permet de vérifier que des chemins sont disponibles pour permettre aux pods du plan de données Kubernetes de communiquer de manière bidirectionnelle avec d'autres composants de cluster et emplacements réseau.
  • Tests d'équilibreur de charge : utilisez cette option pour vérifier que des chemins sont disponibles afin de permettre à un équilibreur de charge OCI ou à un équilibreur de charge réseau de communiquer de manière bidirectionnelle avec d'autres composants de cluster et emplacements réseau.

Les composants de cluster utilisent différents chemins pour communiquer avec d'autres composants de cluster et emplacements réseau, en fonction du type de réseau du cluster (surcouche de canal ou natif VCN) et du type de noeud de processus actif que le cluster contient (géré et/ou virtuel). Dans chaque catégorie de test, il existe différents tests d'analyse de chemin pour vérifier ces différents chemins.

Notez que la console affiche uniquement les tests d'analyse de chemin applicables au cluster en cours. Par exemple, si le type de réseau du cluster est Superposition Flannel, vous pouvez uniquement sélectionner des tests d'analyse de chemin qui s'appliquent au type de réseau Superposition Flannel.

Exécuter des tests d'analyse de chemin prédéfinis

Utilisez la console pour exécuter des tests d'analyse de chemin prédéfinis afin de vérifier les chemins réseau d'un cluster Kubernetes que vous avez créé à l'aide de Kubernetes Engine.

Utilisation de la console

  1. Sur la page de liste Clusters, sélectionnez le nom du cluster pour lequel vous souhaitez exécuter un test d'analyse de chemin réseau prédéfini. Si vous avez besoin d'aide pour trouver la page de liste ou le cluster, reportez-vous à Liste des clusters.
  2. Sous Ressources, sélectionnez Tests d'analyse de chemin.
    Les tests d'analyse de chemin prédéfinis sont regroupés dans les catégories générales suivantes, affichées dans différents onglets de catégorie de test :
    • Tests d'API de cluster : permet de vérifier que des chemins sont disponibles pour permettre à l'adresse d'API Kubernetes du cluster de communiquer de manière bidirectionnelle avec d'autres composants de cluster et emplacements réseau.
    • Tests de noeud : permet de vérifier que des chemins sont disponibles pour permettre aux noeuds de processus actifs du plan de données Kubernetes de communiquer bidirectionnellement avec d'autres composants de cluster et emplacements réseau.
    • Tests de pod : permet de vérifier que des chemins sont disponibles pour permettre aux pods du plan de données Kubernetes de communiquer de manière bidirectionnelle avec d'autres composants de cluster et emplacements réseau.
    • Tests d'équilibreur de charge : utilisez cette option pour vérifier que des chemins sont disponibles afin de permettre à un équilibreur de charge OCI ou à un équilibreur de charge réseau de communiquer de manière bidirectionnelle avec d'autres composants de cluster et emplacements réseau.
  3. (Facultatif) Sous Type de problème à vérifier, indiquez les tests d'analyse de chemin affichés dans les onglets de catégorie de test en sélectionnant le type de problème à vérifier :
    • Tous les problèmes
    • Echecs DNS
    • Echecs du plan de contrôle Kubernetes
    • Noeuds qui ne sont pas en cours d'inscription
  4. (Facultatif) Sous Filtres, réduisez ou développez le nombre de tests d'analyse de chemin affichés dans les onglets de catégorie de test en sélectionnant ou désélectionnant une ou plusieurs des options OKE required, comme suit :
    • Oui : affiche les tests d'analyse de chemin qui vérifient les chemins essentiels qui doivent être disponibles pour que Kubernetes Engine fonctionne correctement.
    • Recommandé : affiche les tests d'analyse de chemin qui vérifient les chemins recommandés (mais non requis) pour une utilisation par les applications exécutées sur des clusters créés par Kubernetes Engine.
    • Non : affiche les tests d'analyse de chemin qui vérifient les chemins qui ne sont ni requis par Kubernetes Engine ni particulièrement recommandés, mais qui peuvent néanmoins être utilisés par les applications exécutées sur des clusters créés par Kubernetes Engine.
    Si vous sélectionnez toutes les options requises OKE sous Filtres, tous les tests d'analyse de chemin disponibles sont affichés dans les onglets de catégorie de test. Si vous désélectionnez toutes les options OKE requises sous Filtres, aucun test d'analyse de chemin n'est affiché dans les onglets de catégorie de test.
  5. Recherchez le test d'analyse de chemin à exécuter dans l'un des onglets de la catégorie de test à l'aide du nom et de la description du test.
    A savoir : Si vous ne trouvez pas le test d'analyse de chemin que vous recherchez ou si aucun test d'analyse de chemin n'est affiché, vérifiez à nouveau que le type de problème que vous souhaitez rechercher et les options OKE required sont définis correctement. Vérifiez également que le test d'analyse de chemin que vous souhaitez exécuter est applicable au cluster en cours. Par exemple, si le type de réseau du cluster est Superposition Flannel, vous pouvez uniquement sélectionner des tests d'analyse de chemin qui s'appliquent au type de réseau Superposition Flannel.
  6. Sélectionnez Lancer l'analyse de chemin en regard du test d'analyse de chemin à exécuter pour afficher la page Analyse de chemin.
    Si vous ne disposez pas des droits d'accès appropriés pour exécuter le test d'analyse de chemin sélectionné, un message d'erreur s'affiche. Vous devez accorder les autorisations appropriées avant de continuer. Pour connaître les droits d'accès à accorder et la stratégie IAM recommandée, reportez-vous à Droits d'accès requis dans la documentation Network Path Analyzer.
  7. Selon le test d'analyse de chemin que vous sélectionnez, modifiez les valeurs par défaut ou fournissez des valeurs pour les paramètres de test source et de destination sur la page Analyse de chemin.
    Dans de nombreux cas, les valeurs par défaut des paramètres de test sont dérivées des propriétés des ressources utilisées par le cluster. Dans certains cas, vous pouvez modifier les valeurs par défaut. Vous devez fournir des valeurs pour les paramètres de test qui n'ont pas de valeurs par défaut.
  8. Sélectionnez Exécuter l'analyse pour exécuter le test d'analyse de chemin.
  9. Autorisez l'exécution du test d'analyse de chemin, qui peut prendre jusqu'à une minute.
    Pendant que le test d'analyse de chemin est en cours d'exécution, le trafic ne traverse pas réellement le réseau. Les informations de configuration réseau sont simplement collectées et analysées pour déterminer le fonctionnement ou l'échec des chemins entre la source et la destination.
    Une fois le test d'analyse de chemin exécuté, tous les chemins possibles (jusqu'à huit) identifiés entre la source et la destination sont affichés dans différents onglets de la section Chemins repérés.
    Chaque onglet affiche les options configurées pour le test d'analyse de chemin, ainsi que des diagrammes visualisant le chemin de transmission et (s'ils sont configurés) le chemin de renvoi du trafic entre la source et la destination, et le statut de chaque chemin :
    • Si le test d'analyse de chemin détermine que le trafic réseau peut traverser un chemin particulier, le diagramme correspondant à ce chemin a un statut de chemin accessible. Une flèche verte représente chaque saut réussi entre les noeuds du chemin global.
    • Si le test d'analyse de chemin détermine que le trafic réseau ne peut pas traverser un chemin particulier, le diagramme de ce chemin a un statut de chemin Inaccessible. Une flèche verte représente tout saut réussi dans le chemin global et une flèche rouge représente le saut ou le segment réseau inaccessible.
  10. Sélectionnez Afficher les informations du diagramme pour afficher plus de détails sur les sauts dans chaque chemin, ou sélectionnez une flèche spécifique pour obtenir des détails sur un saut particulier. Par exemple, pour déterminer si un saut a échoué à cause d'une erreur dans la configuration de routage ou de sécurité d'un noeud spécifique.
    Chaque saut a un statut de routage, avec l'une des valeurs suivantes :
    • Transféré : la table de routage appropriée autorise le trafic.
    • Aucun routage : la table de routage n'autorise pas explicitement le trafic.
    • Indéterminé : la table de routage ne peut pas être analysée, car votre compte ne dispose pas des droits d'accès requis ou parce que les informations de routage du noeud ne sont pas disponibles pour une autre raison.

    Si le noeud est une ressource OCI, les informations de routage sont directement liées à la règle de routage appropriée.

    Chaque saut a un statut de sécurité, avec l'une des valeurs suivantes :
    • Autorisé : la règle ou la liste de sécurité appropriée autorise le trafic.
    • Bloqué : la liste de sécurité ou la règle bloque le trafic.
    • Indéterminé : la liste ou la règle de sécurité ne peut pas être analysée, car votre compte ne dispose pas des droits d'accès requis ou parce que les informations de sécurité du noeud ne sont pas disponibles pour une autre raison.

    Si le noeud est une ressource OCI, les informations de sécurité sont directement liées à la règle ou liste de sécurité appropriée.

  11. (Facultatif) Sélectionnez Enregistrer en tant que JSON pour enregistrer la sortie du test d'analyse de chemin dans un fichier JSON dans votre répertoire de téléchargements par défaut.
    L'enregistrement de la sortie de test d'analyse de chemin sous forme de fichier JSON vous permet de comparer les résultats de test au fil du temps.
  12. Sélectionnez Fermer pour fermer la page d'analyse de chemin.