Partager via


Fonctionnement de Bridge to Kubernetes

Note

Bridge to Kubernetes sera mis hors service le 30 avril 2025. Pour plus d’informations sur la mise hors service et les alternatives open source, consultez le problème GitHub.

Bridge to Kubernetes est un outil de développement itératif pour la création d’applications de microservice qui ciblent Kubernetes. L’extension Bridge to Kubernetes est disponible pour Visual Studio et Visual Studio Code (VS Code).

Bridge to Kubernetes vous permet d’exécuter et de déboguer du code sur votre ordinateur de développement. Cet ordinateur est toujours connecté à votre cluster Kubernetes avec le reste de votre application ou services. Si vous avez une architecture de microservices volumineuse avec de nombreux services et bases de données interdépendants, la réplication de ces dépendances sur votre ordinateur de développement peut être difficile. La création et le déploiement de code sur votre cluster Kubernetes pour chaque modification de code peuvent être lents, fastidieux et difficiles.

Le pont vers Kubernetes crée une connexion entre votre ordinateur de développement et votre cluster. Cette approche évite d’avoir à générer et déployer votre code sur votre cluster. Vous pouvez tester et développer votre service dans le contexte, connecté à votre cluster. Cette approche vous permet de déboguer sans créer de configuration Docker ou Kubernetes.

Le pont vers Kubernetes redirige le trafic entre votre cluster Kubernetes connecté et votre ordinateur de développement. Le code local et les services de votre cluster Kubernetes peuvent communiquer comme s’ils se trouvent dans le même cluster Kubernetes.

Le pont vers Kubernetes vous permet de répliquer des variables d’environnement et des volumes montés dans votre cluster Kubernetes sur votre ordinateur de développement. L’accès aux variables d’environnement et aux volumes montés vous permet de travailler sur votre code sans avoir à répliquer ces dépendances.

Exigences

Note

Le pont vers Kubernetes ne fonctionne pas avec docker pour les clusters Kubernetes de bureau. Pour utiliser Bridge to Kubernetes, vous avez besoin de l’une des configurations suivantes :

Vous pouvez utiliser Bridge to Kubernetes pour établir une connexion à votre cluster Kubernetes. Cette connexion redirige le trafic vers et depuis un pod existant dans le cluster vers votre ordinateur de développement.

Note

Lorsque vous utilisez Bridge to Kubernetes, vous êtes invité à indiquer le nom du service à rediriger vers votre ordinateur de développement. Cette option est un moyen pratique d’identifier un pod pour la redirection. Toutes les redirections entre votre cluster Kubernetes et votre ordinateur de développement concernent un pod. Pour plus d’informations, consultez Rendre un service disponible.

Dans VS Code, Bridge to Kubernetes prend en charge toutes les langues tant que vous pouvez les exécuter localement. Dans Visual Studio, Bridge to Kubernetes prend en charge .NET Core. Bridge to Kubernetes ne prend pas en charge .NET Framework dans Visual Studio, car il nécessite la prise en charge des nœuds Windows.

Attention

Bridge to Kubernetes est destiné à être utilisé uniquement dans les scénarios de développement et de test. Il n’est pas destiné ou pris en charge pour une utilisation avec des clusters de production ou des services en direct en cours d’utilisation active.

Pour connaître les fonctionnalités actuelles et les plans futurs, consultez la feuille de route Bridge to Kubernetes.

Établissement d’une connexion

Lorsque Bridge to Kubernetes établit une connexion à votre cluster, il effectue les actions suivantes :

  • Vous invite à configurer le service à remplacer sur votre cluster, le port sur votre ordinateur de développement à utiliser pour votre code et la tâche de lancement de votre code en tant qu’action unique.
  • Remplace le conteneur dans le pod sur le cluster par un conteneur d’agent distant qui redirige le trafic vers votre ordinateur de développement.
  • Exécute kubectl port-forward sur votre ordinateur de développement pour transférer le trafic de votre ordinateur de développement vers l’agent distant s’exécutant dans votre cluster.
  • Collecte des informations d’environnement à partir de votre cluster à l’aide de l’agent distant. Ces informations d’environnement incluent des variables d’environnement, des services visibles, des montages de volumes et des montages de secrets.
  • Configure l’environnement dans Visual Studio afin que le service sur votre ordinateur de développement puisse accéder aux mêmes variables que s’il s’exécutait sur le cluster.
  • Met à jour le fichier hôtes pour associer des services de votre cluster aux adresses IP locales sur votre ordinateur de développement. Ces entrées de fichier des hôtes permettent au code qui s'exécute sur votre ordinateur de développement d'envoyer des requêtes à d'autres services qui s'exécutent dans votre cluster. Pour mettre à jour le fichier des hôtes , Bridge to Kubernetes a besoin d’un accès administrateur sur votre ordinateur de développement.
  • Démarre l’exécution et le débogage de votre code sur votre ordinateur de développement. Si nécessaire, Bridge to Kubernetes libère les ports requis sur votre ordinateur de développement en arrêtant les services ou processus qui utilisent actuellement ces ports.

Utilisation de Bridge to Kubernetes

Après avoir établi une connexion à votre cluster, exécutez et déboguez du code en mode natif sur votre ordinateur, sans conteneurisation. Le code interagit avec votre cluster. Tout trafic réseau reçu par l’agent distant est redirigé vers le port local spécifié pendant la connexion. Votre code en cours d’exécution en mode natif peut accepter et traiter ce trafic. Les variables d’environnement, les volumes et les secrets de votre cluster sont mis à la disposition du code exécuté sur votre ordinateur de développement.

Bridge to Kubernetes ajoute des entrées de fichier hosts et le transfert de port sur votre ordinateur de développeur. Votre code peut envoyer le trafic réseau aux services s’exécutant sur votre cluster à l’aide des noms de service de votre cluster. Ce trafic est transféré aux services qui s’exécutent dans votre cluster. Le trafic est acheminé entre votre ordinateur de développement et votre cluster tout le temps que vous êtes connecté.

De plus, Bridge to Kubernetes permet de répliquer des variables d’environnement et des fichiers montés disponibles pour les pods de votre cluster sur votre ordinateur de développement via le fichier KubernetesLocalProcessConfig.yaml. Vous pouvez également utiliser ce fichier pour créer des variables d’environnement et des montages de volumes.

Note

Pendant la durée de la connexion au cluster, plus 15 minutes, Bridge to Kubernetes exécute un processus appelé EndpointManager avec des autorisations d’administrateur sur votre ordinateur local.

Vous pouvez déboguer en parallèle, avec plusieurs services. Lancez autant d’instances de Visual Studio que les services que vous souhaitez déboguer. Assurez-vous que vos services écoutent sur différents ports localement. Configurez et déboguez-les séparément. L’isolation n’est pas prise en charge dans ce scénario.

Configuration supplémentaire

Le fichier KubernetesLocalProcessConfig.yaml vous permet de répliquer des variables d’environnement et des fichiers montés disponibles pour vos pods dans votre cluster. Lorsque vous utilisez Visual Studio, le fichier KubernetesLocalConfig.yaml doit se trouver dans le même répertoire que le fichier projet du service. Pour plus d’informations, consultez Configurer Bridge to Kubernetes.

Utilisation des fonctionnalités de routage pour le développement en isolation

Par défaut, Bridge to Kubernetes redirige tout le trafic d’un service vers votre ordinateur de développement. Vous pouvez utiliser plutôt des fonctionnalités de routage pour rediriger uniquement les requêtes d’un sous-domaine vers votre ordinateur de développement. Ces fonctionnalités de routage vous permettent d’utiliser Bridge to Kubernetes pour développer en isolation et éviter d’interrompre d’autres trafics dans votre cluster.

L’animation suivante montre deux développeurs travaillant sur le même cluster isolé :

Animation montre l’isolation, avec deux développeurs travaillant avec le même cluster.

Lorsque vous activez l’isolation, Bridge to Kubernetes effectue les actions suivantes en plus de la connexion à votre cluster Kubernetes :

  • Vérifie que le cluster Kubernetes n’a pas activé Azure Dev Spaces.
  • Réplique le service que vous avez choisi dans le cluster dans le même espace de noms et ajoute une étiquette routing.visualstudio.io/route-from=SERVICE_NAME et l’annotation routing.visualstudio.io/route-on-header=kubernetes-route-as=GENERATED_NAME.
  • Configure et démarre le gestionnaire de routage dans le même espace de noms sur le cluster Kubernetes. Le gestionnaire de routage utilise un sélecteur d’étiquette pour rechercher l’étiquette routing.visualstudio.io/route-from=SERVICE_NAME et l’annotation routing.visualstudio.io/route-on-header=kubernetes-route-as=GENERATED_NAME lors de la configuration du routage dans votre espace de noms.

Note

Bridge to Kubernetes vérifie si Azure Dev Spaces est activé sur votre cluster Kubernetes. Il vous invite à désactiver Azure Dev Spaces avant de pouvoir utiliser Bridge to Kubernetes.

Le gestionnaire de routage effectue les actions suivantes lors du démarrage :

  • Duplique toutes les entrées, y compris les entrées de l’équilibreur de charge, trouvées dans l’espace de noms à l’aide de GENERATED_NAME pour le sous-domaine.
  • Il crée un pod d’envoi pour chaque service associé aux entrées en double avec le sous-domaine GENERATED_NAME.
  • Crée un autre pod d’envoi pour le service sur lequel vous travaillez de manière isolée. Cette configuration permet aux requêtes avec le sous-domaine d’être routées vers votre ordinateur de développement.
  • Configure les règles d’acheminement pour chaque pod d’envoi afin de gérer le routage des services avec le sous-domaine.

Le diagramme suivant montre un cluster Kubernetes avant que Bridge to Kubernetes se connecte à votre cluster :

Diagramme du cluster sans pont vers Kubernetes.

Le diagramme suivant montre le même cluster avec Bridge to Kubernetes activé en mode d’isolation. Ici, vous pouvez voir le service en double et les pods d’envoi qui prennent en charge le routage en isolation.

Diagramme de cluster avec Bridge to Kubernetes activé.

Lorsque le cluster reçoit une requête avec le sous-domaine GENERATED_NAME, il ajoute à la requête un en-tête kubernetes-route-as=GENERATED_NAME. Les pods Envoy s'occupent de l'acheminement de cette demande vers le service approprié dans le cluster. Pour une demande adressée au service en cours d’isolation, le cluster redirige la demande vers votre ordinateur de développement par l’agent distant.

Lorsque le cluster reçoit une demande sans le sous-domaine GENERATED_NAME, il n’ajoute pas d’en-tête à la requête. Les pods Envoy gèrent le routage de cette requête vers le service approprié dans le cluster. Pour le service en cours de remplacement, les pods acheminent la requête vers le service d’origine au lieu de l’agent distant.

Important

Chaque service de votre cluster doit transférer l’en-tête kubernetes-route-as=GENERATED_NAME lors de l’exécution de requêtes supplémentaires. Par exemple, lorsque serviceA reçoit une demande, il effectue ensuite une demande pour serviceB avant de retourner une réponse. Dans cet exemple, serviceA doit transférer l’en-tête kubernetes-route-as=GENERATED_NAME dans sa requête à serviceB. Certaines langues, telles que ASP.NET, peuvent avoir des méthodes pour gérer la propagation de l’en-tête.

Lorsque vous vous déconnectez de votre cluster, par défaut, Bridge to Kubernetes supprime tous les pods d’envoi et le service dupliqué.

Note

Le déploiement et le service du gestionnaire de routage restent en cours d’exécution dans votre espace de noms. Pour supprimer le déploiement et le service, exécutez les commandes suivantes pour votre espace de noms.

kubectl delete deployment routingmanager-deployment -n NAMESPACE
kubectl delete service routingmanager-service -n NAMESPACE

Diagnostics et journalisation

Lorsque vous utilisez Bridge to Kubernetes pour vous connecter à votre cluster, votre ordinateur journalise les diagnostics. Il les stocke dans le répertoire TEMP de votre ordinateur de développement dans le dossier Bridge to Kubernetes.

Autorisation RBAC Kubernetes

Kubernetes fournit le contrôle d’accès en fonction du rôle (RBAC) pour gérer les autorisations des utilisateurs et des groupes. Pour plus d’informations, consultez la documentation Kubernetes. Vous pouvez définir les autorisations d’un cluster avec RBAC en créant un fichier YAML et en utilisant kubectl pour l’appliquer au cluster.

Pour définir des autorisations sur le cluster, créez ou modifiez un fichier YAML tel que permissions.yml. Utilisez votre espace de noms pour <namespace> et les utilisateurs et groupes qui nécessitent un accès.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: bridgetokubernetes-<namespace>
  namespace: development
subjects:
  - kind: User
    name: jane.w6wn8.k8s.ginger.eu-central-1.aws.gigantic.io
    apiGroup: rbac.authorization.k8s.io
  - kind: Group
    name: dev-admin
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io

Appliquez les autorisations à l’aide de la commande suivante :

kubectl -n <namespace> apply -f <yaml file name>

Limitations

Le pont vers Kubernetes présente les limitations suivantes :

  • Un pod ne peut avoir qu'un seul conteneur s'exécutant dans ce pod pour que Bridge to Kubernetes puisse se connecter correctement.
  • Actuellement, les pods Bridge to Kubernetes doivent être des conteneurs Linux. Les conteneurs Windows ne sont pas pris en charge.
  • Bridge to Kubernetes a besoin d’autorisations élevées pour s’exécuter sur votre ordinateur de développement afin de modifier votre fichier hosts.
  • Le pont vers Kubernetes ne peut pas être utilisé sur des clusters avec Azure Dev Spaces activé.

Étapes suivantes

Pour commencer à utiliser Bridge to Kubernetes afin de connecter votre ordinateur de développement local à votre cluster, consultez Utiliser Bridge to Kubernetes (VS) ou Utiliser Bridge to Kubernetes (VS Code).