Comment fonctionne Bridge to Kubernetes

Bridge to Kubernetes est un outil de développement itératif pour la création d’applications de microservices 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 de vos services. Si vous avez une architecture de microservices importante 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 s’avérer difficile. La génération et le déploiement de code sur votre cluster Kubernetes pour chaque modification du code peuvent être lents, longs et difficiles.

Bridge to 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 en contexte, connecté à votre cluster. Cette approche vous permet de déboguer sans créer davantage de configuration Docker ou Kubernetes.

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

Bridge to 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.

Spécifications

Notes

Bridge to Kubernetes ne fonctionne pas avec les clusters Kubernetes Docker for Desktop. Pour utiliser Bridge to Kubernetes, vous avez besoin de l’une des configurations suivantes :

• VS Code avec l’extension Bridge to Kubernetes installée.
• Visual Studio 2019 version 16.7 ou ultérieure s’exécutant sur Windows 10 ou version ultérieure. Assurez-vous que la charge de travail de développement ASP.NET et web est installée. Installez l’extension Bridge to Kubernetes.

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.

Notes

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

Dans VS Code, Bridge to Kubernetes prend en charge tous les langages 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 des scénarios de développement et de test. Il n’est pas destiné ni pris en charge pour une utilisation avec des clusters de production ou des services en direct dans une utilisation active.

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

Établissement d’une connexion

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

• Il 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 ponctuelle.
• Il remplace le conteneur du pod sur le cluster par un conteneur d’agent distant qui redirige le trafic vers votre ordinateur de développement.
• Elle exécute la commande kubectl port-forward sur votre ordinateur de développement pour transférer le trafic de celui-ci vers l’agent distant s’exécutant dans votre cluster.
• Elle collecte les informations d’environnement de votre cluster à l’aide de l’agent distant. Ces informations d’environnement incluent les variables d’environnement, les services visibles, les montages de volumes et les montages de secrets.
• Il 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.
• Il met à jour votre fichier hosts pour mapper les services sur votre cluster à des adresses IP locales sur votre ordinateur de développement. Ces entrées de fichier hosts permettent au code s’exécutant sur votre ordinateur de développement d’adresser des requêtes à d’autres services s’exécutant dans votre cluster. Pour mettre à jour votre fichier hosts, Bridge to Kubernetes a besoin d’un accès administrateur sur votre ordinateur de développement.
• Il 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 les 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 conteneur. Le code interagit avec votre cluster. Tout trafic réseau que l’agent distant reçoit est redirigé vers le port local spécifié pendant la connexion. Votre code en mode natif peut accepter et traiter ce trafic. Les variables d’environnement, volumes et secrets de votre cluster sont mis à la disposition du code s’exécutant 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 en cours d’exécution 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 routé entre votre ordinateur de développement et votre cluster pendant toute la durée de votre connexion.

En outre, Bridge to Kubernetes permet de répliquer les variables d’environnement et les 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.

Notes

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 de services que vous souhaitez déboguer. Assurez-vous que vos services écoutent sur différents ports localement. Configurez-les 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 pour le service. Pour plus d’informations, consultez Configurer Bridge to Kubernetes.

Utilisation des fonctionnalités de routage pour le développement isolé

Par défaut, Bridge to Kubernetes redirige tout le trafic d’un service vers votre ordinateur de développement. Vous pouvez utiliser les 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 de manière isolée et éviter de perturber d’autres trafics dans votre cluster.

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

Lorsque vous activez le travail isolé, Bridge to Kubernetes effectue les actions suivantes en plus de la connexion à votre cluster Kubernetes :

• Il vérifie qu’Azure Dev Spaces n’est pas activé dans le cluster Kubernetes.
• Il 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.
• Il 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’étiquettes 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.

Notes

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 lorsqu’il démarre :

• Il 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.
• Il crée un autre pod d’envoi pour le service sur lequel vous travaillez de manière isolée. Cette configuration permet d’acheminer les requêtes avec le sous-domaine vers votre ordinateur de développement.
• Il configure les règles de routage 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 ne se connecte à votre cluster :

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.

Lorsque le cluster reçoit une requête avec le sous-domaine GENERATED_NAME, il ajoute un en-tête kubernetes-route-as=GENERATED_NAME à la requête. Les pods d’envoi gèrent le routage de cette requête vers le service approprié dans le cluster. Pour une requête adressée au service utilisé de manière isolée, le cluster redirige la requête vers votre ordinateur de développement par l’agent distant.

Lorsque le cluster reçoit une requête sans le sous-domaine GENERATED_NAME, il n’ajoute pas d’en-tête à la requête. Les pods d’envoi 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 requête, il effectue une requête auprès de 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. Certains langages, tels que ASP.NET, peuvent avoir des méthodes pour gérer la propagation des en-têtes.

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

Notes

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 la connexion à 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 Kubernetes RBAC

Kubernetes fournit 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 les groupes qui ont besoin d’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 en utilisant la commande suivante :

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

Limites

Bridge to Kubernetes présente les limitations suivantes :

• Un pod ne peut comprendre qu’un seul conteneur en cours d’exécution pour que Bridge to Kubernetes se connecte 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.
• Bridge to Kubernetes ne peut pas être utilisé sur les clusters avec Azure Dev Spaces activé.

Étapes suivantes

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