Configurer Bridge to Kubernetes

Article
04/26/2024

Remarque

Microsoft prévoit de ne plus maintenir activement le projet Bridge to Kubernetes. Au cours des prochains mois, nous allons faire passer le projet à un état d’archivage. Entre-temps, le projet reste disponible à l’utilisation et au téléchargement. Pendant cette période, nous espérons explorer et recommander des projets communautaires qui offrent des avantages similaires à Bridge to Kubernetes pour votre usage futur. Si vous avez des questions, veuillez nous contacter sur notre tableau des problèmes sur GitHub.

Vous pouvez configurer le processus Bridge to Kubernetes local à l’aide de deux méthodes. Vous pouvez annoter des services sur votre cluster et fournir une configuration locale.

Configuration Kubernetes

Le fichier de configuration Kubernetes (kubeconfig) est stocké par défaut sur ~/.kube/config, mais vous pouvez le définir à l’aide de la variable d’environnement KUBECONFIG.

Si vous utilisez Visual Studio, vous pouvez modifier le profil de lancement de Bridge to Kubernetes dans l’IDE à l’aide de l’interface utilisateur des profils de lancement de débogage dans les propriétés de débogage. Consultez Modifier le profil de lancement.

Ensuite, vous pouvez ouvrir l’écran suivant, qui permet de modifier certaines des propriétés de configuration les plus courantes.

Empêcher Bridge to Kubernetes de transférer des ports spécifiques

Configurez Bridge to Kubernetes pour ignorer le mappage de ports spécifiques sur un service Kubernetes sur votre machine en ajoutant l’annotation bridgetokubernetes/ignore-ports sur le service.

apiVersion: v1
kind: Service
metadata:
  annotations:
    bridgetokubernetes/ignore-ports:445,23

Configuration locale avec (KubernetesLocalProcessConfig.yaml)

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. Vous pouvez spécifier les actions suivantes dans un fichier KubernetesLocalProcessConfig.yaml :

Télécharger un volume et définir le chemin d’accès à ce volume en tant que variable d’environnement.
Rendre un service en cours d’exécution sur votre cluster disponible pour les processus en cours d’exécution sur votre ordinateur de développement.
Créer une variable d’environnement avec une valeur constante.

Un fichier KubernetesLocalProcessConfig.yaml par défaut n’est pas créé automatiquement et vous devez le créer manuellement à la racine de votre projet.

Télécharger un volume

Sous env, spécifiez les variables name et value pour chaque volume que vous souhaitez télécharger. La variable name est la variable d’environnement qui sera utilisée sur votre ordinateur de développement. La variable value est le nom du volume et un chemin d’accès sur votre ordinateur de développement. La valeur de value prend la forme $(volumeMounts:VOLUME_NAME)/PATH/TO/FILES.

Par exemple :

version: 0.1
env:
  - name: ALLOW_LIST_PATH
    value: $(volumeMounts:allow-list)/allow-list

L’exemple ci-dessus télécharge le volume allow-list à partir du conteneur et définit cet emplacement, ainsi que le chemin d’accès à la variable d’environnement ALLOW_LIST_PATH. Le comportement par défaut consiste à télécharger les fichiers sur le chemin que vous spécifiez dans un répertoire temporaire sur votre ordinateur de développement. Dans l’exemple ci-dessus, ALLOW_LIST_PATH a la valeur /TEMPORARY_DIR/allow-list.

Notes

Le téléchargement d’un volume télécharge l’intégralité du contenu de ce volume, quel que soit le chemin d’accès que vous définissez. Le chemin d’accès est utilisé uniquement pour définir la variable d’environnement à utiliser sur l’ordinateur de développement. L’ajout de /allow-list ou /path/to/files à la fin du jeton n’affecte pas réellement l’emplacement où le volume est conservé. La variable d’environnement présente simplement un aspect pratique, au cas où votre application aurait besoin d’une référence à un fichier spécifique à l’intérieur de ce volume.

Vous avez également la possibilité de spécifier un emplacement pour télécharger le montage du volume sur votre ordinateur de développement au lieu d’utiliser un répertoire temporaire. Sous volumeMounts, spécifiez les variables name et localPath pour chaque emplacement spécifique. La variable name est le nom du volume que vous souhaitez faire correspondre, et localPath est le chemin d’accès absolu sur votre ordinateur de développement. Par exemple :

version: 0.1
volumeMounts:
  - name: default-token-*
    localPath: /var/run/secrets/kubernetes.io/serviceaccount
env:
  - name: KUBERNETES_IN_CLUSTER_CONFIG_OVERRIDE
    value: $(volumeMounts:default-token-*)

L’exemple ci-dessus utilise l’entrée dans env pour télécharger un volume correspondant à default-token-*, tel que default-token-1111 ou default-token-1234-5678-90abcdef. Dans les cas où plusieurs volumes correspondent, le premier volume correspondant est utilisé. Tous les fichiers sont téléchargés dans /var/run/secrets/kubernetes.io/serviceaccount sur votre ordinateur de développement à l’aide de l’entrée dans volumeMounts. La variable d’environnement KUBERNETES_IN_CLUSTER_CONFIG_OVERRIDE est définie sur /var/run/secrets/kubernetes.io/serviceaccount.

Rendre un service disponible

Sous env, spécifiez les variables name et value pour chaque service que vous souhaitez rendre disponible sur votre ordinateur de développement. La variable name est la variable d’environnement qui sera utilisée sur votre ordinateur de développement. La variable value est le nom du service à partir de votre cluster et un chemin d’accès. La valeur de value prend la forme $(services:SERVICE_NAME)/PATH.

Par exemple :

version: 0.1
env:
  - name: MYAPP1_SERVICE_HOST
    value: $(services:myapp1)/api/v1/

L’exemple ci-dessus met le service myapp1 à la disposition de votre ordinateur de développement et la variable d’environnement MYAPP1_SERVICE_HOST est définie sur l’adresse IP locale du service myapp1 avec le chemin d’accès /api/v1 (autrement dit, 127.1.1.4/api/v1). Le service myapp1 est accessible à l’aide de la variable d’environnement, myapp1 ou myapp1.svc.cluster.local.

Notes

La mise à disposition d’un service sur votre ordinateur de développement rend l’ensemble du service disponible, quel que soit le chemin d’accès que vous définissez. Le chemin d’accès est utilisé uniquement pour définir la variable d’environnement à utiliser sur l’ordinateur de développement. Vous pouvez également rendre disponible un service d’un espace de noms Kubernetes spécifique à l’aide de $(services:SERVICE_NAME.NAMESPACE_NAME). Par exemple :

version: 0.1
env:
  - name: MYAPP2_SERVICE_HOST
    value: $(services:myapp2.mynamespace)

L’exemple ci-dessus rend le service myapp2 de l’espace de noms mynamespace disponible sur votre ordinateur de développement et définit la variable d’environnement MYAPP2_SERVICE_HOST sur l’adresse IP locale du service myapp2 de l’espace de noms mynamespace.

Créer une variable d’environnement avec une valeur constante

Sous env, spécifiez les éléments name et value pour chaque variable d’environnement que vous souhaitez créer sur votre ordinateur de développement. L’élément name est la variable d’environnement qui sera utilisée sur votre ordinateur de développement et value est sa valeur. Par exemple :

version: 0.1
env:
  - name: DEBUG_MODE
    value: "true"

L’exemple ci-dessus crée une variable d’environnement nommée DEBUG_MODE avec la valeur true.

Ajouter une dépendance de service

Vous pouvez spécifier une dépendance de service, telle qu’une base de données ou un cache, à l’aide d’un champ de dépendances générique, similaire à la façon dont les services sont déclarés. Spécifiez une dépendance ici lorsque le service que vous déboguez doit se connecter à des ressources qui ne s’exécutent pas sur votre cluster. Déclarez une dépendance comme dans l’exemple suivant :

version: 0.1
volumeMounts:
env:
  - name: DB_HOST
    value: $(externalendpoints:server-bridgetest123.database.windows.net:1433)

Fournissez le nom DNS de l’hôte (server-bridgetest13.database.windows.net dans l’exemple) et le port (1433 dans l’exemple) pour votre dépendance.

Lorsque vous spécifiez des dépendances telles que des bases de données, les modèles d’authentification de redirection ne fonctionnent pas. Par exemple, pour Azure SQL Database, vous devez définir la stratégie de connexion sur « Proxy » (plutôt que « Redirection » ou « Par défaut »).

Exemple de fichier KubernetesLocalProcessConfig.yaml

Voici un exemple d’un fichier KubernetesLocalProcessConfig.yaml complet :

version: 0.1
volumeMounts:
  - name: default-token-*
    localPath: /var/run/secrets/kubernetes.io/serviceaccount
env:
  - name: KUBERNETES_IN_CLUSTER_CONFIG_OVERRIDE
    value: $(volumeMounts:default-token-*)
  - name: ALLOW_LIST_PATH
    value: $(volumeMounts:allow-list)/allow-list
  - name: MYAPP1_SERVICE_HOST
    value: $(services:myapp1)/api/v1/
  - name: MYAPP2_SERVICE_HOST
    value: $(services:myapp2.mynamespace)
  - name: DEBUG_MODE 
    value: "true"

É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 avec Visual Studio Code et Utiliser Bridge to Kubernetes avec Visual Studio.

Partager via