Fuente: https://www.cnblogs.com/zisefeizhu/p/13692782.html
Prefacio
El clúster de nuestra empresa siempre está al borde del colapso. Después de casi tres meses de análisis, encontramos que las razones de la inestabilidad del clúster de nuestra empresa son las siguientes:
1. El proceso de liberación es inestable.
2. Falta de plataforma de seguimiento [la razón más importante]
3. Falta de sistema de registro
4. Falta extrema de documentación operativa relevante
5. La ruta de la solicitud no está clara.
En términos generales, la causa principal del problema es la falta de una plataforma de monitoreo predecible y siempre esperamos hasta que ocurra el problema. Las razones secundarias son funciones del servidor poco claras y procesos de lanzamiento inestables.
Recomiende un proyecto práctico Spring Boot gratuito y de código abierto:
solución
El proceso de liberación es inestable
Reestructurar el proceso de liberación. El negocio está totalmente basado en k8s y se construye un proceso de CI/CD con kubernetes como núcleo.
Proceso de liberación
El proceso de liberación es el siguiente:
Breve análisis: el personal de I + D envía el código a la rama de desarrollador (siempre asegúrese de que la rama de desarrollador tenga el código más reciente), la rama de desarrollador se fusiona con la rama correspondiente al entorno de lanzamiento, activa la alarma empresarial WeChat y activa gitlab-runner pod implementado en el clúster k8s. Nuevo Inicie el pod del corredor para realizar operaciones ci/cd. Se requieren tres pasos en este proceso: casos de prueba, imágenes de empaquetado y pods de actualización.
Al implementar servicios por primera vez en un entorno de clúster k8s, es posible que necesite: crear un espacio de nombres, crear imagepullsecret, crear pv (clase de almacenamiento), crear una implementación (controlador de pod), crear svc, crear ingreso, etc. Entre ellos, la imagen se empaqueta y se envía al almacén de Alibaba Cloud y se accede a la imagen descargada desde el almacén de Alibaba Cloud mediante VPC, sin pasar por la red pública y sin límite de velocidad de red. Una vez completado el proceso, el pod del corredor se destruye y gitlab devuelve los resultados.
Una cosa que debe enfatizarse es que la lista de recursos aquí no contiene mapas de configuración ni secretos, lo que implica problemas de seguridad y no debe usarse.
En el almacén de códigos actual, nuestra empresa utiliza Rancher como plataforma de gestión de múltiples clústeres K8. Los problemas de seguridad anteriores se manejan mediante operación y mantenimiento en el panel de Rancher.
Diagrama lógico de implementación de servicios
El diagrama lógico de implementación de servicios relevante es el siguiente:
Con base en un breve análisis del proceso de lanzamiento, el proceso de lanzamiento se puede aclarar según el diagrama lógico. Aquí vemos que nuestra empresa utiliza kong en lugar de nginx para autenticación, autenticación y agencia. La propiedad intelectual de slb está vinculada a Kong. 0, 1, 2 pertenecen al trabajo de prueba; 3 pertenece al trabajo de compilación; 4, 5, 6 y 7 pertenecen a la etapa de cambio del pod. No todos los servicios requieren almacenamiento, debe determinarse en función de la situación real, por lo que debe escribir un juicio en kubernetes.sh.
Aquí estoy tratando de usar un conjunto de aplicaciones CI y todos los entornos, por lo que necesito usar más juicios en kubernetes.sh, y .gitlab-ci.yml parece demasiado. La sugerencia es utilizar una plantilla ci y aplicarla a todos los entornos. Después de todo, ¿cómo se pueden evitar problemas?
También debe considerar su propio modo de bifurcación. Para referencia específica: https://www.cnblogs.com/zisefeizhu/p/13621797.html
Falta de plataforma de seguimiento y alerta temprana
Construya una plataforma de monitoreo federado confiable que sea consistente con el entorno de clúster de nuestra empresa para lograr el monitoreo simultáneo de varios entornos de clúster y alarmas previas a fallas, e intervenga con anticipación.
Diagrama lógico de seguimiento y alerta temprana.
El diagrama lógico de seguimiento y alerta temprana relevante es el siguiente:
Breve análisis: en general, la solución de monitoreo que uso aquí es prometheus➕shell script o go script➕sentry. El método de alarma utilizado es WeChat corporativo o correo electrónico corporativo. Las tres líneas de colores en la imagen de arriba representan los tres métodos de monitoreo que necesitan atención.
Los scripts se utilizan principalmente para alarmas de respaldo, alarmas de certificados, captura de ladrones, etc. Prometheus utiliza la lista de recursos de Prometheus modificada según Prometheus-opertor y los datos se almacenan en nas. Estrictamente hablando, Sentry es una plataforma de recopilación de registros. Aquí la clasifico como una categoría de monitoreo porque me gusta su capacidad para recopilar información sobre fallas del código subyacente de la aplicación. Pertenece al monitoreo de lógica de negocios y está diseñado para monitorear el funcionamiento del negocio. Los registros de errores generados durante el proceso se recopilan, resumen y monitorean para detectar alarmas.
Tenga en cuenta que aquí se utiliza la plataforma de monitoreo federal y se implementa una plataforma de monitoreo ordinaria.
Diagrama lógico de la plataforma federal de monitoreo y alerta temprana
El diagrama lógico de la plataforma de alerta temprana y monitoreo federado de múltiples clústeres es el siguiente:
Debido a que nuestra empresa tiene varios clústeres de k8, sería demasiado inconveniente de administrar si implementamos una plataforma de monitoreo y alerta temprana en cada clúster, por lo que la estrategia que adopto aquí es implementar una estrategia federada para cada plataforma de monitoreo y alerta temprana, utilizando Gestión de interfaz visual unificada. Aquí implementaré tres niveles de monitoreo: nivel de sistema operativo, nivel de aplicación y nivel comercial. Para monitorear el tráfico, puede monitorear directamente Kong, plantilla 7424.
Falta el sistema de registro
Con el avance del proceso empresarial integral basado en k8s, habrá una demanda aún mayor de sistemas de registro. Una característica de k8s es que los registros de fallas del servicio son difíciles de obtener. Establecer un sistema de registro observable y filtrable puede reducir la dificultad del análisis de fallas.
El diagrama lógico del sistema de registro es el siguiente:
Breve análisis: una vez que el negocio está completamente basado en k8s, la administración y el mantenimiento se facilitan, pero la dificultad de la administración de registros aumenta adecuadamente. Sabemos que el reinicio de un pod es multifactorial e incontrolable, y los registros se registrarán nuevamente cada vez que se reinicie el pod, es decir, los registros anteriores al nuevo pod no son visibles. Por supuesto, hay muchas formas de lograr el almacenamiento de registros a largo plazo: almacenamiento remoto de registros, montaje local de registros, etc. Por motivos de visualización, análisis, etc., elegimos utilizar elasticsearch para construir el sistema de recopilación de registros.
Extremadamente carente de documentación operativa.
Establezca un centro de documentos centrado en Yuque -> datos relacionados con la operación y el mantenimiento, y registre las operaciones, problemas, guiones, etc. relevantes en detalle para revisarlos en cualquier momento.
Breve análisis: por razones de seguridad, a muchos colegas les resulta inconveniente revisarlo. Los trabajos de operación y mantenimiento son bastante especiales y se debe garantizar la seguridad y la documentación. Creo que ya sea operación y mantenimiento o desarrollo de operación y mantenimiento, se debe dominar la redacción de documentos, ya sea para usted o para otros. El documento puede abreviarse, pero debe contener los pasos principales. Sigo pensando que se debe registrar cada paso de operación y mantenimiento.
Ruta de solicitud poco clara
De acuerdo con las nuevas ideas de reconstrucción de clústeres, se reorganiza la ruta de solicitud de tráfico a nivel de clúster y se construye una gestión de tráfico integrada con autenticación, autenticación, proxy, conexión, protección, control, observación, etc. para controlar eficazmente el alcance de la explosión de fallas. .
El diagrama lógico de ruta de solicitud es el siguiente:
Breve análisis: los clientes acceden a https://www.cnblogs.com/zisefeizhu e ingresan a un espacio de nombres específico después de ser autenticados por la puerta de enlace kong (distinguiendo proyectos a través de espacios de nombres). Debido a que el servicio se ha dividido en microservicios, la comunicación entre servicios se ha interrumpido. autenticado por istio. Para autorización, si necesita interactuar con la base de datos, vaya a la base de datos, si necesita escribir o leer el almacenamiento, vaya a pv, si necesita el servicio de conversión, vaya al servicio de conversión... y luego devolver la respuesta.
Resumir
En resumen, la construcción se basa en: el proceso de lanzamiento de CI/CD con Kubernetes como núcleo, la plataforma federal de monitoreo y alerta temprana con Prometheus como núcleo, el sistema de recopilación de registros con Elasticsearch como núcleo, el centro de gestión de documentos con Yuque como núcleo, y los servicios de tráfico integrados norte-sur y este-oeste con kong e istio como núcleo pueden garantizar una alta fluidez y alta confiabilidad.
Adjunto: diagrama lógico de arquitectura general
Nota: Analice según las flechas y los colores.
Breve análisis: la imagen de arriba parece demasiado confusa. Si se calma y la analiza capa por capa en función de los módulos divididos arriba, aún puede verla claramente. Aquí utilizo diferentes colores de conexiones para representar los sistemas de diferentes módulos. Es bastante claro seguir las flechas.
Según el tráfico comercial actual de nuestra empresa, los módulos funcionales anteriores pueden, en teoría, mantener la estabilidad del clúster. Personalmente, creo que esta solución puede garantizar que el negocio pueda funcionar de manera estable en el clúster k8s durante un período de tiempo. Si hay algún problema, será un problema a nivel de código. Aquí no se utiliza ningún middleware, pero se utiliza redis en caché, pero no se muestra. Planeo agregar middleware kafka o rq al sistema de registro y al servicio de conversión después de completar la imagen de arriba, depende de la situación.
Artículos populares recientes recomendados:
1. Recopilación de más de 1000 preguntas y respuestas de entrevistas en Java (última versión de 2022)
2. ¡Explosivo! Las corrutinas de Java están por llegar. . .
3. Tutorial de Spring Boot 2.x, ¡muy completo!
5. "Java Development Manual (Songshan Edition)" se lanzó recientemente, ¡descárguelo rápidamente!
Si crees que es bueno, ¡no olvides darle me gusta y retuitear!