Compartir a través de

Configuración de Bridge to Kubernetes

  • Artículo

Nota

Bridge to Kubernetes se retirará el 30 de abril de 2025. Para obtener más información sobre las alternativas de retirada y código abierto, consulte el problema de GitHub.

Puede configurar el proceso local de Bridge to Kubernetes mediante dos métodos. Puede anotar los servicios en el clúster y puede proporcionar la configuración local.

Configuración de Kubernetes

El archivo de configuración de Kubernetes (kubeconfig) se almacena de forma predeterminada en ~/.kube/config, pero puede establecerlo mediante la variable de entorno KUBECONFIG.

Si usa Visual Studio, puede editar el perfil de inicio de Bridge to Kubernetes en el IDE mediante la interfaz de usuario de perfiles de inicio de depuración en las propiedades de depuración. Consulte Editar perfil de inicio.

Captura de pantalla que muestra la interfaz de usuario de los perfiles de inicio de depuración.

Desde allí, puede abrir la siguiente pantalla, que proporciona una manera de editar algunas de las propiedades de configuración más comunes.

Captura de pantalla que muestra la edición de algunas de las propiedades de perfil de Bridge to Kubernetes más comunes.

Impedir que Bridge to Kubernetes reenvíe puertos específicos

Configure Bridge to Kubernetes para omitir la asignación de puertos específicos en un servicio de Kubernetes a la máquina mediante la adición de la anotación bridgetokubernetes/ignore-ports en el servicio.

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

Configuración local mediante (KubernetesLocalProcessConfig.yaml)

El archivo KubernetesLocalProcessConfig.yaml te permite replicar las variables de entorno y los archivos montados que están disponibles para tus pods en el clúster. Puede especificar las siguientes acciones en un archivo KubernetesLocalProcessConfig.yaml:

  • Descargue un volumen y establezca la ruta de acceso a ese volumen como una variable de entorno.
  • Haga que un servicio que se ejecute en el clúster esté disponible para los procesos que se ejecutan en el equipo de desarrollo.
  • Cree una variable de entorno con un valor constante.

No se crea automáticamente un archivo KubernetesLocalProcessConfig.yaml predeterminado, por lo que debe crear manualmente el archivo en la raíz del proyecto.

Descargar un volumen

En env, especifique un nombre y un valor para cada volumen que desee descargar. El nombre es la variable de entorno que se utilizará en el equipo de desarrollo. El valor es el nombre del volumen y una ruta de acceso en el equipo de desarrollo. El valor de value toma la forma $ (volumeMounts:VOLUME_NAME)/PATH/TO/FILES.

Por ejemplo:

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

En el ejemplo anterior se descarga el volumen de listas de permitidos del contenedor y se establece esa ubicación más la ruta de acceso en la variable de entorno ALLOW_LIST_PATH. El comportamiento predeterminado es descargar los archivos en la ruta de acceso especificada en un directorio temporal del equipo de desarrollo. En el ejemplo anterior, ALLOW_LIST_PATH se establece en /TEMPORARY_DIR/allow-list.

Nota

Al descargar un volumen, se descargará todo el contenido de ese volumen, independientemente de la ruta de acceso que establezca. La ruta de acceso solo se usa para establecer la variable de entorno para su uso en el equipo de desarrollo. Agregar /allow-list o /path/to/files al final del token no afecta realmente al lugar donde se conserva el volumen. La variable de entorno es solo una comodidad en caso de que la aplicación necesite una referencia a un archivo específico dentro de ese volumen.

También tiene la opción de especificar una ubicación para descargar el montaje del volumen en el equipo de desarrollo en lugar de usar un directorio temporal. En volumeMounts, especifique un nombre y localPath para cada ubicación específica. El nombre es el nombre del volumen que desea comparar y localPath es la ruta de acceso absoluta del equipo de desarrollo. Por ejemplo:

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-*)

En el ejemplo anterior se usa la entrada de env para descargar un volumen que coincida con default-token-*, como default-token-1111 o default-token-1234-5678-90abcdef. En los casos en los que coinciden varios volúmenes, se usa el primer volumen coincidente. Todos los archivos se descargan en /var/run/secrets/kubernetes.io/serviceaccount, en el equipo de desarrollo, mediante la entrada de volumeMounts. La variable de entorno KUBERNETES_IN_CLUSTER_CONFIG_OVERRIDE se establece en /var/run/secrets/kubernetes.io/serviceaccount.

Hacer que un servicio esté disponible

En env, especifique un nombre y un valor para cada servicio que desea que esté disponible en su equipo de desarrollo. El nombre es la variable de entorno que se usará en la computadora de desarrollo. El valor es el nombre del servicio del clúster y una ruta de acceso. El valor de value toma la forma $(services:SERVICE_NAME)/PATH.

Por ejemplo:

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

En el ejemplo anterior, el servicio myapp1 está disponible para el equipo de desarrollo y la variable de entorno MYAPP1_SERVICE_HOST se establece en la dirección IP local del servicio myapp1 con el camino /api/v1 (es decir, 127.1.1.4/api/v1). El servicio myapp1 es accesible mediante la variable de entorno, myapp1o myapp1.svc.cluster.local.

Nota

Hacer que un servicio esté disponible en el equipo de desarrollo hará que todo el servicio esté disponible independientemente de la ruta de acceso que establezca. La ruta de acceso solo se usa para establecer la variable de entorno para su uso en el equipo de desarrollo. También puede hacer que un servicio de un espacio de nombres de Kubernetes específico esté disponible mediante $(services:SERVICE_NAME.NAMESPACE_NAME). Por ejemplo:

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

En el ejemplo anterior, se obtiene acceso a myapp2 del espacio de nombres mynamespace en el equipo de desarrollo y se establece la variable de entorno MYAPP2_SERVICE_HOST en la dirección IP local de myapp2 del espacio de nombres mynamespace.

Creación de una variable de entorno con un valor constante

En env, especifique un nombre y un valor para cada variable de entorno que desee crear en el equipo de desarrollo. El nombre es la variable de entorno que se utilizará en el equipo de desarrollo y value es el valor. Por ejemplo:

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

En el ejemplo anterior se crea una variable de entorno denominada DEBUG_MODE con un valor de true.

Adición de una dependencia de servicio

Puede especificar una dependencia de servicio, como una base de datos o una memoria caché, mediante un campo de dependencias genéricas, similar a cómo se declaran los servicios. Especifique una dependencia aquí cuando el servicio que está depurando necesite conectarse a los recursos que no se ejecutan en el clúster. Declare una dependencia como en el ejemplo siguiente:

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

Proporcione el nombre DNS de host (server-bridgetest13.database.windows.net en el ejemplo) y el puerto (1433 en el ejemplo) para la dependencia.

Al especificar dependencias como bases de datos, los modelos de autenticación de redireccionamiento no funcionarán. Por ejemplo, para Azure SQL Database, debe establecer la directiva de conexión en "Proxy" (en lugar de "Redirigir" o "Predeterminado").

Ejemplo de KubernetesLocalProcessConfig.yaml

Este es un ejemplo de un archivo KubernetesLocalProcessConfig.yaml completo:

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"

Pasos siguientes

Para empezar a usar Bridge to Kubernetes para conectarse desde su equipo de desarrollo local al clúster, consulte Uso de Bridge to Kubernetes con Visual Studio Code y Uso de Bridge to Kubernetes con Visual Studio.