Implementación de la resistencia de la infraestructura con Kubernetes
Para implementar la resistencia basada en la infraestructura, puede usar una malla de servicio. Además de la resistencia sin cambiar el código, una malla de servicio proporciona administración del tráfico, directiva, seguridad, identidad segura y observabilidad. La aplicación se desacopla de estas funcionalidades operativas, que se mueven al nivel de infraestructura. En términos arquitectónicos, una malla de servicio se compone de dos componentes: un plano de control y un plano de datos.
El componente del plano de control tiene muchos componentes que admiten la administración de la malla de servicio. El inventario de componentes normalmente incluye:
- Una interfaz de administración, que podría ser una interfaz de usuario o una API.
- Reglas y definiciones de directiva que definen cómo la malla de servicio debe implementar funcionalidades específicas.
- Administración de seguridad para cosas como identidad segura y certificados para mTLS.
- Métricas o observabilidad para recopilar y agregar métricas y telemetría de las aplicaciones.
El componente del plano de datos consta de servidores proxy que se insertan de forma transparente junto con cada servicio, que se conoce como patrón Sidecar. Cada proxy está configurado para controlar el tráfico de red dentro y fuera del pod que contiene el servicio. Esta configuración permite configurar cada proxy para:
- Proteger el tráfico a través de mTLS.
- Enrutar dinámicamente el tráfico.
- Aplicar directivas al tráfico.
- Recopile métricas e información de seguimiento.
Algunas opciones populares de malla de servicio para clústeres de Kubernetes incluyen Linkerd, Istio y Consul. Este módulo se centra en Linkerd. En el diagrama siguiente se muestran las interacciones entre los componentes dentro de los planos de datos y control:
Comparación con los enfoques basados en código
La estrategia principal de control de errores de Linkerd consta de reintentos y tiempos de espera. Dado que Linkerd tiene una visión sistémica de todo el clúster, puede emplear estrategias de resistencia de maneras innovadoras. Un ejemplo es volver a intentarlo de forma que agregue un máximo de 20 % de carga adicional en el servicio de destino. La vista basada en métricas de Linkerd permite adaptarse dinámicamente a las condiciones del clúster en tiempo real. Este enfoque agrega otra dimensión para administrar el clúster, pero no agrega ningún código.
Con un enfoque basado en código, como con Polly, puede:
- Son necesarios para adivinar qué parámetros de reintento y tiempo de espera son adecuados.
- Céntrese en una solicitud HTTP específica.
No hay ninguna manera razonable de responder a un error de infraestructura en el código de la aplicación. Tenga en cuenta los cientos o miles de solicitudes que se están procesando simultáneamente. Incluso un reintento con retroceso exponencial (número de solicitudes de tiempo) puede desbordar un servicio.
En cambio, los enfoques basados en la infraestructura como Linkerd no son conscientes de los elementos internos de la aplicación. Por ejemplo, las transacciones complejas de base de datos son invisibles para Linkerd. Estas transacciones pueden protegerse frente a errores con Polly.
En las unidades que vienen, implementará la resistencia para el servicio de cupones con Polly y Linkerd.