Funcionamiento de Bridge to Kubernetes

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.

Bridge to Kubernetes es una herramienta de desarrollo iterativa para crear aplicaciones de microservicio que tienen como destino Kubernetes. La extensión Bridge to Kubernetes está disponible para Visual Studio y Visual Studio Code (VS Code).

Bridge to Kubernetes permite ejecutar y depurar código en el equipo de desarrollo. Ese equipo todavía está conectado al clúster de Kubernetes con el resto de la aplicación o los servicios. Si tiene una arquitectura de microservicios de gran tamaño con muchos servicios y bases de datos interdependientes, la replicación de esas dependencias en el equipo de desarrollo puede ser difícil. La compilación e implementación de código en su clúster de Kubernetes para cada cambio de código puede ser lenta, requerir mucho tiempo y ser difícil.

Bridge to Kubernetes crea una conexión entre el equipo de desarrollo y el clúster. Este enfoque evita tener que compilar e implementar el código en el clúster. Puede probar y desarrollar el servicio en contexto, conectado al clúster. Este enfoque le permite depurar sin crear más configuración de Docker o Kubernetes.

Bridge to Kubernetes redirige el tráfico entre el clúster de Kubernetes conectado y el equipo de desarrollo. El código local y los servicios del clúster de Kubernetes pueden comunicarse como si estuvieran en el mismo clúster de Kubernetes.

Bridge to Kubernetes permite replicar variables de entorno y volúmenes montados en el clúster de Kubernetes en el equipo de desarrollo. El acceso a variables de entorno y volúmenes montados le permite trabajar en el código sin tener que replicar esas dependencias.

Requisitos

Nota

Bridge to Kubernetes no funciona con los clústeres de Docker para Kubernetes de escritorio. Para usar Bridge to Kubernetes, necesita cualquiera de las siguientes configuraciones:

• VS Code con la extensión Bridge to Kubernetes instalada.
• Visual Studio 2019, versión 16.7 o posterior ejecutándose en Windows 10 o versiones posteriores. Asegúrese de que la carga de trabajo ASP.NET y de desarrollo web esté instalada. Instale la extensión Bridge to Kubernetes .

Puede usar Bridge to Kubernetes para establecer una conexión con el clúster de Kubernetes. Esta conexión redirige el tráfico hacia y desde un pod existente en el clúster al equipo de desarrollo.

Nota

Al usar Bridge to Kubernetes, se le pedirá el nombre del servicio que desea redirigir a su equipo de desarrollo. Esta opción es una manera cómoda de identificar un pod para el redireccionamiento. Todo el redireccionamiento entre el clúster de Kubernetes y el equipo de desarrollo es para un pod. Para obtener más información, consulte Hacer que un servicio esté disponible.

En VS Code, Bridge to Kubernetes admite todos los lenguajes siempre que pueda ejecutarlos localmente. En Visual Studio, Bridge to Kubernetes admite .NET Core. Bridge to Kubernetes no admite .NET Framework en Visual Studio porque requiere compatibilidad con nodos de Windows.

Cautela

Bridge to Kubernetes está diseñado solo para su uso en escenarios de desarrollo y pruebas. No está diseñado ni admitido para su uso con clústeres de producción o servicios en uso activo.

Para conocer las características actuales y los planes futuros, consulte la hoja de ruta Bridge to Kubernetes.

Establecimiento de una conexión

Cuando Bridge to Kubernetes establece una conexión con el clúster, realiza las siguientes acciones:

• Le pide que configure el servicio a reemplazar en su clúster, el puerto en su ordenador de desarrollo a utilizar para su código, y la tarea de lanzamiento para su código como una acción única.
• Reemplaza el contenedor en el pod del clúster por un contenedor de agente remoto que redirige el tráfico al equipo de desarrollo.
• Ejecuta kubectl port-forward en el equipo de desarrollo para reenviar el tráfico del equipo de desarrollo al agente remoto que se ejecuta en el clúster.
• Recopila información del entorno del clúster mediante el agente remoto. Esta información de entorno incluye variables de entorno, servicios visibles, montajes de volúmenes y montajes secretos.
• Configura el entorno en Visual Studio para que el servicio del equipo de desarrollo pueda tener acceso a las mismas variables que si se estuviera ejecutando en el clúster.
• Actualiza el archivo de hosts de para asignar los servicios de tu clúster a direcciones IP locales en tu equipo de desarrollo. Estas entradas de archivo de hosts permiten que el código que se ejecuta en el equipo de desarrollo realice solicitudes a otros servicios que se ejecutan en el clúster. Para actualizar el archivo de hosts, Bridge to Kubernetes necesita acceso de administrador en el equipo de desarrollo.
• Empieza a ejecutar y a depurar el código en el equipo de desarrollo. Si es necesario, Bridge to Kubernetes libera los puertos necesarios en el equipo de desarrollo deteniendo los servicios o procesos que actualmente usan esos puertos.

Uso de la herramienta Bridge to Kubernetes

Después de establecer una conexión con el clúster, ejecute y depure código de forma nativa en el equipo, sin contenedorización. El código interactúa con el clúster. Cualquier tráfico de red que reciba el agente remoto se redirige al puerto local especificado durante la conexión. El código en ejecución de forma nativa puede aceptar y procesar ese tráfico. Las variables de entorno, los volúmenes y los secretos del clúster están disponibles para el código que se ejecuta en tu equipo de desarrollo.

Bridge to Kubernetes agrega entradas de archivo de hosts y reenvío de puertos al equipo del desarrollador. El código puede enviar tráfico de red a los servicios que se ejecutan en el clúster mediante los nombres de servicio del clúster. Ese tráfico se reenvía a los servicios que se ejecutan en el clúster. El tráfico se enruta entre el equipo de desarrollo y el clúster todo el tiempo que esté conectado.

Además, Puente a Kubernetes proporciona una manera de replicar variables de entorno y archivos montados disponibles para pods en el clúster en el equipo de desarrollo mediante el archivo KubernetesLocalProcessConfig.yaml. También puede usar este archivo para crear nuevas variables de entorno y montajes de volumen.

Nota

Durante la conexión al clúster, más 15 minutos, Bridge to Kubernetes ejecuta un proceso denominado EndpointManager con permisos de administrador en el equipo local.

Puede depurar en paralelo, con varios servicios. Inicie tantas instancias de Visual Studio como servicios que quiera depurar. Asegúrese de que los servicios escuchan en distintos puertos localmente. Configúrelos y depúrelos por separado. El aislamiento no se admite en este escenario.

Configuración adicional

El archivo KubernetesLocalProcessConfig.yaml permite replicar variables de entorno y archivos montados disponibles para los pods del clúster. Cuando se usa Visual Studio, el archivo KubernetesLocalConfig.yaml debe estar en el mismo directorio que el archivo de proyecto para el servicio. Para obtener más información, consulte Configure Bridge to Kubernetes.

Uso de funciones de enrutamiento para desarrollar de forma aislada

De forma predeterminada, Bridge to Kubernetes redirige todo el tráfico de un servicio al equipo de desarrollo. En su lugar, puede usar funcionalidades de enrutamiento para redirigir solo las solicitudes de un subdominio al equipo de desarrollo. Estas funcionalidades de enrutamiento permiten usar Bridge to Kubernetes para desarrollar de forma aislada y evitar interrumpir otro tráfico del clúster.

En la siguiente animación se muestran dos desarrolladores que trabajan en el mismo clúster de forma aislada:

Al habilitar el trabajo de forma aislada, Bridge to Kubernetes realiza las siguientes acciones además de conectarse al clúster de Kubernetes:

• Comprueba que el clúster de Kubernetes no tiene Habilitado Azure Dev Spaces.
• Replica el servicio seleccionado en el clúster en el mismo espacio de nombres y agrega una etiqueta routing.visualstudio.io/route-from=SERVICE_NAME y una anotación routing.visualstudio.io/route-on-header=kubernetes-route-as=GENERATED_NAME.
• Configura e inicia el administrador de enrutamiento en el mismo espacio de nombres en el clúster de Kubernetes. El administrador de enrutamiento usa un selector de etiquetas para buscar la etiqueta routing.visualstudio.io/route-from=SERVICE_NAME y la anotación routing.visualstudio.io/route-on-header=kubernetes-route-as=GENERATED_NAME al configurar el enrutamiento en el espacio de nombres.

Nota

Bridge to Kubernetes comprueba si Azure Dev Spaces está habilitado en el clúster de Kubernetes. Se le pide que deshabilite Azure Dev Spaces antes de poder usar Bridge to Kubernetes.

El administrador de enrutamiento realiza las siguientes acciones cuando se inicia:

• Duplica todas las entradas (incluidas las del equilibrador de carga) que se encuentran en el espacio de nombres mediante el valor GENERATED_NAME del subdominio.
• Crea un pod de envío para cada servicio asociado a las entradas duplicadas con el subdominio GENERATED_NAME.
• Crea otro pod de Envoy para el servicio en el que se trabaja de forma aislada. Esta configuración permite que las solicitudes con el subdominio se enruten al equipo de desarrollo.
• Configura reglas de enrutamiento para que cada pod de envío controle el enrutamiento de servicios con el subdominio.

En el diagrama siguiente se muestra un clúster de Kubernetes antes de que Bridge to Kubernetes se conecte al clúster:

En el diagrama siguiente se muestra el mismo clúster con Bridge to Kubernetes habilitado en modo de aislamiento. Aquí puede ver el servicio duplicado y los pods de envío que admiten el enrutamiento en aislamiento.

Cuando el clúster recibe una solicitud con el subdominio GENERATED_NAME, agrega un encabezado kubernetes-route-as=GENERATED_NAME a la solicitud. Los pods de envío controlan el enrutamiento de la solicitud al servicio adecuado en el clúster. Si la solicitud se enruta al servicio en el que se trabaja de forma aislada, el agente remoto redirige esa solicitud al equipo de desarrollo.

Cuando el clúster recibe una solicitud sin el subdominio GENERATED_NAME, no agrega un encabezado a la solicitud. Los pods de envío controlan el enrutamiento de la solicitud al servicio adecuado en el clúster. Si la solicitud es para un servicio que se va a reemplazar, los pods la enrutan al servicio original en lugar de al agente remoto.

Importante

Cada servicio del clúster debe reenviar el encabezado kubernetes-route-as=GENERATED_NAME al realizar solicitudes adicionales. Por ejemplo, cuando serviceA recibe una solicitud, realiza una solicitud para serviceB antes de devolver una respuesta. En este ejemplo, serviceA tiene que reenviar el encabezado kubernetes-route-as=GENERATED_NAME de su solicitud a serviceB. Algunos lenguajes, como ASP.NET, pueden tener métodos para controlar la propagación de encabezados.

Cuando te desconectas de tu clúster, Bridge to Kubernetes elimina de forma predeterminada todos los pods de Envoy y el servicio duplicado.

Nota

La implementación y el servicio del gestor de enrutamiento continúan ejecutándose en su espacio de nombres. Para quitar la implementación y el servicio, ejecute los siguientes comandos para el espacio de nombres.

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

Diagnósticos y registro

Al usar Bridge to Kubernetes para conectarse al clúster, el equipo registra los diagnósticos. Los almacena en el directorio TEMP del equipo de desarrollo en la carpeta Bridge to Kubernetes.

Autorización de RBAC de Kubernetes

Kubernetes proporciona control de acceso basado en rol (RBAC) para administrar permisos para usuarios y grupos. Para obtener información, consulte la documentación de Kubernetes. Puede establecer los permisos para un clúster habilitado para RBAC mediante la creación de un archivo YAML y el uso de kubectl para aplicarlo al clúster.

Para establecer permisos en el clúster, cree o modifique un archivo YAML, como permissions.yml. Use el espacio de nombres para <namespace> y los usuarios y grupos que necesitan acceso.

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

Aplique los permisos mediante el comando siguiente:

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

Limitaciones

Bridge to Kubernetes tiene las siguientes limitaciones:

• Un pod solo puede tener un único contenedor que se ejecute en ese pod para que Bridge to Kubernetes se conecte correctamente.
• Actualmente, los pods de Bridge to Kubernetes deben ser contenedores de Linux. No se admiten contenedores de Windows.
• Bridge to Kubernetes necesita permisos elevados para ejecutarse en el equipo de desarrollo para editar el archivo de hosts.
• Bridge to Kubernetes no se puede usar en clústeres con Azure Dev Spaces habilitado.

Pasos siguientes

Para empezar a usar Bridge to Kubernetes y conectarse al equipo de desarrollo local con el clúster, consulte Use Bridge to Kubernetes (VS) o Use Bridge to Kubernetes (VS Code).