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 obtener resistencia sin cambiar el código, una malla de servicio proporciona administración del tráfico, directivas, seguridad, identidad segura y observación. La aplicación está desacoplada de estas capacidades 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 de 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 directivas que definen el modo en que la malla de servicio debe implementar funciones específicas.
- Administración de la seguridad para elementos como identidad segura y certificados para mTLS.
- Métricas u observación para recopilar y agregar las métricas y la telemetría de las aplicaciones.
El componente de plano de datos consta de servidores proxy que se insertan de manera transparente junto con cada servicio, esto se conoce como patrón Sidecar. Cada proxy se configura para controlar el tráfico de red dentro y fuera del pod que contiene el servicio. Esta configuración permite configurar cada proxy para:
- Asegurar el tráfico a través de mTLS.
- Enrutar el tráfico de forma dinámica.
- Aplicar directivas al tráfico.
- Recopilar métricas e información de seguimiento.
Algunas opciones populares de la malla de servicio para los 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 de los planos de datos y de 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 vista sistémica de todo el clúster, puede emplear estrategias de resistencia de maneras novedosas. Un ejemplo es volver a intentar de forma que agregue un máximo de un 20 % de carga adicional en el servicio de destino. La vista basada en métricas de Linkerd permite adaptarse dinámicamente a las condiciones de clúster en tiempo real. Este enfoque agrega otra dimensión a la administración del clúster, pero no agrega ningún código.
Con un enfoque basado en código, como con Polly, usted:
- Tendrá que adivinar qué parámetros de reintento y tiempo de espera son adecuados.
- Se centra 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 las centenas 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.
Por el contrario, los enfoques basados en la infraestructura como Linkerd no son compatibles con las aplicaciones internas. Por ejemplo, las transacciones de bases de datos complejas 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.