Funcionamiento del Puente a Kubernetes

Nota:

Microsoft tiene previsto dejar de mantener activamente el proyecto Puente a Kubernetes. En los próximos meses pasaremos a archivar el proyecto. Mientras tanto, el proyecto sigue disponible para su uso y descarga. Durante este período, esperamos explorar y recomendar proyectos de la comunidad que proporcionen beneficios similares a Puente a Kubernetes para su uso futuro. Si tiene alguna pregunta, póngase en contacto con nosotros en nuestro panel de problemas en GitHub.

Bridge to Kubernetes es una herramienta de desarrollo iterativo para la creación de aplicaciones de microservicios destinadas a 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. Compilar e implementar código en el clúster de Kubernetes con cada cambio de código puede ser lento y 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 configuraciones de Docker o Kubernetes.

Puente a Kubernetes redirige el tráfico entre el clúster de Kubernetes conectado y el equipo de desarrollo. El código y los servicios locales del clúster de Kubernetes pueden comunicarse como si se encontraran 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 las variables de entorno y los 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 Kubernetes de Docker para 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 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 Puente a Kubernetes, se le pedirá el nombre del servicio que desea redirigir al equipo de desarrollo. Esta opción es una forma 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 más información, consulte Hacer que un servicio esté disponible.

En Visual Studio Code, Bridge to Kubernetes admite todos los lenguajes, siempre y cuando 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.

Precaución

Puente a Kubernetes está pensado únicamente para su uso en escenarios de desarrollo y pruebas. No está pensado ni se admite para su uso con clústeres de producción o servicios en vivo que se utilizan de forma activa.

Para ver las características actuales y los planes futuros, consulte el plan de desarrollo de Bridge to Kubernetes.

Establecimiento de una conexión

Cuando Bridge to Kubernetes establece una conexión con el clúster, hace lo siguiente:

• Le pide que configure el servicio para reemplazar en el clúster, el puerto del equipo de desarrollo que se va a usar para el código y la tarea de inicio del código como una acción única.
• Reemplaza el contenedor del pod en el 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 desde el equipo de desarrollo al agente remoto que se ejecuta en el clúster.
• Recopila información de 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 de secretos.
• Configura el entorno en Visual Studio de modo que el servicio del equipo de desarrollo pueda acceder a las mismas variables como si se estuviera ejecutando en el clúster.
• Actualiza el archivo de hosts para asignar servicios en el clúster a direcciones IP locales en el 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.
• Comienza a ejecutar y depurar el código en el equipo de desarrollo. Si es necesario, Bridge to Kubernetes libera los puertos necesarios en el equipo de desarrollo mediante la detención de los servicios o procesos que usan actualmente esos puertos.

Uso de Puente a Kubernetes

Después de establecer una conexión con el clúster, ejecute y depure el 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 recibe el agente remoto se redirige al puerto local especificado durante la conexión. El código que se ejecuta de forma nativa puede aceptar y procesar ese tráfico. Las variables de entorno, los volúmenes y los secretos del clúster se ponen a disposición del código que se ejecuta en el 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 volúmenes.

Nota

Durante toda la conexión al clúster (más unos 15 minutos adicionales), Bridge to Kubernetes ejecuta un proceso llamado 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. En este escenario no se admite aislamiento.

Configuración adicional

El archivo KubernetesLocalProcessConfig.yaml le permite replicar las variables de entorno y los archivos montados disponibles para los pods en el 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 más información, consulte Configuración de Bridge to Kubernetes.

Uso de funciones de enrutamiento para desarrollar de forma aislada

De forma predeterminada, Puente a Kubernetes redirige todo el tráfico para 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 funciones de enrutamiento permiten usar Puente a Kubernetes para desarrollar de forma aislada y evitar interrumpir el resto del tráfico del clúster.

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

Cuando se habilita el trabajo de forma aislada, además de conectarse al clúster de Kubernetes, Bridge to Kubernetes hace lo siguiente:

• Comprueba que el clúster de Kubernetes no tenga 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, y le pide que deshabilite Azure Dev Spaces antes de poder usar Bridge to Kubernetes.

El administrador de enrutamiento hace lo siguiente 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 Puente a Kubernetes se conecte al clúster:

En el diagrama siguiente se muestra el mismo clúster con Puente a 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, se 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 a 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 se desconecta del clúster, de forma predeterminada, Bridge to Kubernetes quita todos los pods de Envoy y el servicio duplicado.

Nota

La implementación y el servicio del administrador de enrutamiento seguirán ejecutándose en el 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, y 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 de usuarios y grupos. Para información, consulte la documentación de Kubernetes. Puede establecer los permisos de 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:

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

Limitaciones

Puente a Kubernetes tiene las siguientes limitaciones:

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

Pasos siguientes

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