Prefacio
TKEx-CSIG es una plataforma de servicio de contenedor en la nube interna desarrollada en base al servicio de contenedor de nube pública TKE y EKS de Tencent. Proporciona una plataforma nativa de nube para resolver la migración de contenedor interno a la nube de la empresa, con las características más importantes de compatibilidad con la nube nativa, negocios de desarrollo propio y colaboración de código abierto. .
En el proceso de transferencia de contenedores comerciales a la nube, se encontrarán algunos problemas: algunos requieren la transformación de contenedores comerciales y otros requieren la habilitación de la plataforma. En la parte del empoderamiento de la plataforma, hay una categoría de problemas que tienen solución en el escenario CVM, pero son incompatibles en la plataforma Kubernetes debido a diferentes métodos de operación y mantenimiento, como el problema de la preautorización de Pod. Esperamos resolver este tipo de problema de una manera nativa de la nube y proporcionar capacidades basadas en la plataforma para que cada usuario pueda implementar y administrar fácilmente su negocio en la plataforma.
antecedentes
¿Cómo preautorizar nuevos equipos al implementar nuevos servicios o expandir la capacidad? Creo que no está familiarizado con este problema. En función de las consideraciones de seguridad, los componentes importantes y el almacenamiento en la empresa a menudo controlan la fuente de las solicitudes de acceso, como la autorización de acceso IP de CDB, OIDB, autorización del módulo de palabra de comando VASKEY, etc. Tienen su propia WEB autorizada que permite a los usuarios solicitar conocimientos de embarque, o proporcionan API de autorización a las que puede llamar la plataforma de operación y mantenimiento. El sistema de enrutamiento a menudo necesita obtener con precisión la información geográfica del dispositivo IP durante el registro para brindar la capacidad de acceder a las cercanías, lo que requiere el registro previo de la CMDB.
Al usar CVM / TVM para implementar servicios en el pasado, este problema se puede resolver fácilmente, porque obtuvimos una máquina virtual con anticipación, se asignó la IP y se registró la CMDB. Todo lo que debe hacer la empresa es usar esta IP para autorizar el conocimiento de embarque. Implemente programas comerciales y agregue enrutamiento para conectarse en línea después de que todo esté completo. Este proceso se puede automatizar con las capacidades de canalización de la plataforma de operación y mantenimiento.
A diferencia de la implementación de procedimientos paso a paso de las VM después de obtener el equipo disponible, Kubernetes administra todo el ciclo de vida del Pod, desde la producción, la asignación de IP, el inicio del contenedor comercial y el mantenimiento del enrutamiento. El bucle de control de varios controladores del sistema se utiliza para la administración automatizada. La implementación basada en espejo ofrece una garantía de escalabilidad y consistencia de las instancias comerciales. La destrucción y reconstrucción de pod se han vuelto normales y la IP no se puede arreglar.
Los servicios a menudo enfrentan una variedad de necesidades de preautorización. El tiempo promedio de autorización varía de segundos a varios minutos. La mayoría de las API de autorización no están diseñadas para llevar un QPS alto, lo cual es complicado. Necesitamos encontrar una manera de procesar la autorización antes de que el contenedor comercial se active después de que se asigne la IP del pod, bloquear y garantizar el éxito antes de continuar con el proceso posterior, y controlar la presión del proceso de reconstrucción en la API de autorización.
Después del diseño y la optimización iterativa, la plataforma TKEx-CSIG proporciona capacidades de autorización basadas en productos fáciles de usar para empresas, lo que es conveniente para tratar estos problemas de autorización previa de Pod.
Análisis de arquitectura y capacidad
Arquitectura
La figura anterior muestra la arquitectura del sistema de autorización. La idea principal es usar la función de init Container para ejecutar antes del contenedor empresarial para implementar un preprocesamiento lógico complejo antes de que comience el pod empresarial. La definición oficial de init Container es la siguiente
This page provides an overview of init containers: specialized containers that run before app containers in a Pod. Init containers can contain utilities or setup scripts not present in an app imageSi se trata de una solución de pequeña escala o de una sola empresa, podemos hacerlo de manera muy simple, inyectar el contenedor init en el Worklooad yaml empresarial, llamar a la API de autorización requerida para lograrlo y para que la plataforma sea producible, debemos considerar Los siguientes puntos:
-
Fácil de usar y de mantener
Es necesario considerar completamente la eficiencia y la capacidad de administración del uso comercial, y usar los permisos como un recurso que la plataforma debe registrar y administrar para reducir el impacto intrusivo de los cambios en el negocio.
-
Limitación de frecuencia y autocuración
Las API de permisos a menudo no están diseñadas para un alto QPS y necesitan restringir las llamadas para protegerlas en sentido descendente.
-
Convergencia de permisos
La seguridad, la destrucción y reconstrucción de pods pueden causar cambios de IP; considere la posibilidad de reclamar de manera proactiva los permisos caducados
Capacidad del producto del proceso de autorización
La empresa solo necesita registrar los recursos de autoridad requeridos en la consola WEB de la plataforma, configurar el grupo de autoridad, asociar el grupo de autoridad a la carga de trabajo, la plataforma inyectará automáticamente la configuración del contenedor init, pasará el índice de configuración de autorización y la información relacionada a través de ENV y autorizará cuando se cree el Pod. proceso. Las funciones de varios componentes involucrados en el proceso de autorización se diseñan de la siguiente manera:
-
init-action-client
El contenedor init es solo un dispositivo de activación, y solo hace una cosa, que es iniciar una solicitud de llamada HTTP y permanecer inmutable, de modo que cuando se itera la función, no es necesario modificar el yaml comercial y la lógica principal se mueve hacia atrás.
-
init-action-server
La implementación se puede escalar horizontalmente, ejecutar la lógica de preprocesamiento, prerregistrar CMDB y otras operaciones, e iniciar llamadas de canalización, iniciar el proceso de solicitud de permisos y consultar la consulta, y exponer la información del proceso asociada con POD para facilitar el autoexamen empresarial y los problemas de ubicación del administrador. El reintento de retroceso y la lógica del disyuntor que se mencionan más adelante también se implementan aquí.
-
PermissionCenter
El componente de control de la plataforma, ubicado fuera del clúster, es responsable del almacenamiento y la aplicación real de los recursos de permisos. Contiene un centro de recursos de permisos, que almacena los detalles de los permisos y los parámetros del registro comercial para su fácil reutilización, proporciona administración de grupos de conjuntos de permisos y simplifica la transmisión de parámetros en el proceso de autorización; utiliza el modelo de productor / consumidor para implementar llamadas de API de autorización y consultas de resultados basadas en Pipline.
Disyuntor y mecanismo de reintento de retroceso
Puede haber muchas condiciones anormales en el proceso de autorización, como una configuración incorrecta de los parámetros de autorización, una calidad de servicio API de autorización reducida o no disponible, o incluso errores de interfaz y tiempos de espera causados por motivos de la red. Las API de autorización a menudo no están diseñadas para admitir QPS altos. Usamos reintentos de tiempo de espera, agregamos disyuntores y reintentos de retroceso exponencial para lograr la tolerancia a fallas.
-
Reintentar después del tiempo de espera
Reflejado en la configuración del tiempo de espera y el mecanismo de reintento de las llamadas de interfaz y las tareas asincrónicas, en respuesta a fallas transitorias, el contenedor init-action-client se reconstruirá si sale de manera anormal, y cada vez que se crea es una nueva ronda de reintento.
-
interruptor automático
Se utiliza un mapa de configuración para registrar específicamente la cantidad de aplicaciones de permisos de Pod fallidas en el clúster, y la aplicación no se emitirá 3 veces. Y proporcione una capacidad de reinicio, expuesta al front-end, para que los usuarios y administradores puedan volver a intentarlo fácilmente.
-
Retiro del índice
El modo de interruptor automático puede bloquear los errores de configuración del usuario, como los casos en los que la autorización nunca tendrá éxito, pero no puede hacer frente a fallas transitorias a largo plazo. Por ejemplo, durante el período de abolición, el backend de la API de autorización puede denegar el servicio durante un período de 10 minutos a varias horas. En este momento, habrá una gran cantidad de autorizaciones de pods que afectarán la regla del disyuntor y la autorización no podrá continuar, y el tiempo de procesamiento artificial es deficiente y engorroso. Agregamos un retroceso exponencial con fluctuación para cada pod y registramos la última marca de tiempo de falla, lo que permite un intento después de un período de tiempo. Si tiene éxito, restablecerá el retroceso para el pod especificado. Si falla, actualice la marca de tiempo y vuelva a sincronizar. , Los parámetros son los siguientes,
bk := &PodBreaker{
NamespacePod: namespacePod,
LastRequestFailTime: time.Now(),
Backoff: wait.Backoff{
Duration: 2 * time.Minute,
Factor: 2.0,
Jitter: 1.0,
Steps: 5,
Cap: 1 * time.Hour,
},
}Permisos de convergencia del finalizador
La convergencia de permisos a menudo se ignora, pero también es una consideración de seguridad. La destrucción y reconstrucción del pod puede ser normal, y la IP puede ser inexacta y cambiar dinámicamente. Se puede generar una gran cantidad de permisos basura durante mucho tiempo, o la IP autorizada puede asignarse a otros servicios. Pod crea riesgos de seguridad. Creamos un controlador Finalizer para reclamar el permiso antes de que se destruya el Pod. La acción de reclamo es idempotente y un mejor esfuerzo, porque la capacidad de reclamo también depende de si la parte autorizada tiene la capacidad de reclamar. Los permisos considerarán esto, como la autorización automática de IP de Tencent Cloud MySQL.
Para reducir la acción de golpear el Finalizador y tratar de no afectar los pods que no están autorizados por autorización, solo identificamos los pods con un contenedor de inicio autorizado cuando el pod se somete a un evento de cambio, marcamos el finalizador en el parche y recuperamos los permisos cuando estos pods se reducen y destruyen. Y elimine el Finalizador, y luego el GC eliminará el Pod.
kind: Pod
metadata:
annotations:
~
creationTimestamp: "2020-11-13T09:16:52Z"
finalizers:
- stke.io/podpermission-protectionpara resumir
Este artículo resuelve el problema del preprocesamiento, como la autorización automatizada, cuando la empresa utiliza la plataforma de contenedores antes de que comience el proceso empresarial. Use init Container para implementar el preprocesamiento antes del inicio del contenedor comercial y para permitir que la empresa administre y solicite recursos de permisos de manera más conveniente, el disyuntor y el mecanismo de reintento de retroceso para brindar tolerancia a fallas y el Finalizador para brindar una capacidad de recuperación para evitar Proliferación de permisos.