[Registro del entorno de producción K8S desde la construcción hasta la operación y mantenimiento (4)] Diseño de Kubernetes Cluster
1. Introducción
Kubernetes Cluster es sin duda el protagonista de nuestro sistema, al fin y al cabo, nuestros servicios van a correr sobre él. Por lo tanto, es muy importante planificar bien antes de crear un clúster de kubernetes. En esta ocasión, hablaremos sobre qué considerar al diseñar el Clúster de Kubernetes.
2. Un clúster de Kubernetes simple
Primero, veamos primero la composición de un clúster de Kubernetes de creación de grupos.
En este Cluster, es obvio que hay 3 Maestros y 5 Nodos, todos los cuales son números impares. La razón por la que se usan los números impares no se explica aquí. Si no lo sabe, puede buscarlo en línea. También puede ver que hay muchos recursos básicos de Kubenetes que se ejecutan en Master y Node. Analicémoslo en detalle a continuación.
2-1. La composición de Master y Node
-
Master: Tres
Masters son esenciales como centro de control de todo el clúster y deben agruparse en el entorno de producción. En cuanto al número de unidades, al menos un número impar de unidades con más de 3 también. -
Nodo:
como el operador para que proporcionemos el servicio Pod, los 5 nodos no pueden salir mal. Deben agruparse en el entorno de producción. En cuanto a los demasiados, se decidirá de acuerdo con sus necesidades reales, puede haber 3 o decenas.
2-2.Recurso de Kubenetes
Divido los recursos que se ejecutan en Master y Node en tres categorías:
-
Recurso de aplicación Recurso de
aplicación se refiere principalmente al Recurso de servicio que proporcionamos Recurso de pod de servicio y exponemos el servicio. Están programados para ejecutarse en cada nodo a través de la implementación, el conjunto de demonios y otros controladores para proporcionar nuestros servicios de forma externa.
Application Resource recomienda no ejecutarse en el Master, porque la función del Master no es ejecutar nuestros servicios, se utiliza para administrar todo nuestro Clúster de Kubenetes para garantizar el funcionamiento normal del Clúster de Kubenetes. Por lo general, la configuración de Master no es muy alta, por lo que no es adecuado para su uso como portador de nuestro servicio. En términos sencillos: el maestro está adentro, el nodo está afuera. -
La
función principal de Control Resource Control Resource es mejorar la confiabilidad de los servicios de Pod a través de HPA, quota, limitaRange y otros recursos, de manera que nuestro servicio no se cuelgue debido a una carga alta y no use mucha CPU debido a errores en nuestro programa. Los recursos como la memoria hacen que Node se bloquee. Además, los permisos se pueden administrar a través de Recursos como ServiceAccount, Role, etc., para evitar el uso indebido de permisos y errores de operación, y proteger indirectamente nuestros servicios. Además, estos recursos no deben ejecutarse en el maestro. -
Supervisar recursos
Supervisar recursos es fácil de entender, que consiste en supervisar y recopilar información en nuestro clúster, nodo y pod de Kubenetes. El monitoreo es para que podamos notificar al personal relevante a tiempo cuando hay una falla del sistema o falla del servicio. La recopilación de información es para que analicemos la información, determinemos el estado del sistema y prediga los problemas futuros del sistema, y también para realizar información comercial. El análisis puede crear valor comercial.
Lo anterior es solo un diagrama de estructura simple de Kubernetes Cluster, entonces, ¿cómo podemos diseñar un sistema para el entorno de producción? ¿Cuáles son las cosas que debemos considerar al diseñar Kubenetes Cluster? A continuación, hablemos de ello. .
3.Elementos de diseño de Kubenetes Cluster
Comience principalmente con los requisitos no funcionales, clasifique todos los requisitos no funcionales, encuentre una solución para cada requisito y luego refleje en el diseño.
Hablemos sobre cómo diseñar para cada requisito no funcional al diseñar el sistema Kubernetes.
- [Fiabilidad] Facilidad de recuperación y tolerancia a fallas,
un sistema robusto debe tener tolerancia a fallas y resistencia. Cuando una determinada parte del sistema falla, el servicio general del sistema no se detendrá; y el punto de falla se puede restaurar rápidamente a través del plan de recuperación preparado con anticipación, y el usuario del sistema no se dará cuenta de la ocurrencia durante todo el proceso. De todo esto. Para lograr los requisitos de confiabilidad del sistema, las contramedidas habituales incluyen redundancia, respaldo y restauración, monitoreo y alarma, y un sistema de respuesta de 24 horas.
Cómo implementar estas contramedidas de confiabilidad en el entorno de producción de Kubernetes Cluster, analicémoslas una por una.
- Redundancia
En el diagrama de composición anterior, se puede ver intuitivamente que tanto el maestro como el nodo están configurados en un modo de clúster, y el Pod que se ejecuta en el clúster también es una configuración detallada, pero estos por sí solos no son suficientes. Necesitamos averiguar todos los lugares donde pueden ocurrir puntos únicos de falla, y luego realizar la redundancia a través de las soluciones técnicas correspondientes. La longitud de todas las líneas de red, la longitud de los equipos de red, como los interruptores, y la longitud de los dispositivos de distribución de carga que generalmente son fáciles de ignorar. Espera, siempre que sea cualquier lugar y equipo relacionado con nuestro sistema, debemos considerar si necesitamos lograr verbosidad. Si se trata de utilizar servicios en la nube, el operador implementará por nosotros la redundancia de la infraestructura, por lo que reduciremos mucho trabajo. Además, la separación y el desacoplamiento de nuestro negocio también pueden mejorar indirectamente la fiabilidad del sistema hasta cierto punto.
| clasificación | Componente largo |
|---|---|
| servidor | Maestro |
| Nodo | |
| infraestructura | Línea de red |
| Equipos de red (conmutadores, distribución de carga) | |
| Dispositivo de almacenamiento | |
| Servicio empresarial | Por lo general, vainas en Kubernetes |
| otro | Todas las partes relacionadas con el sistema |
Muchas fallas de respaldo y restauración son causadas por nuestras operaciones humanas, como la eliminación accidental de datos, errores en la publicación de contenido. Tales fallas generalmente son fáciles de localizar la causa. Solo necesitamos restaurar datos y reversiones de versiones para lograr la recuperación de fallas. . Pero estos se basan en nuestra visión y preparación con visión de futuro, es decir, la gestión de copias de seguridad y versiones, que juegan un papel vital en la protección del sistema. Por lo general, es necesario realizar una copia de seguridad de la copia de seguridad general del sistema operativo, la copia de seguridad de los datos de la base de datos y la copia de seguridad de los archivos comerciales importantes. En el entorno de producción de Kubernetes Cluster, necesita hacer una copia de seguridad del etcd, que contiene información importante sobre el Cluster, así como la copia de seguridad del Master y Node. Si usa las herramientas de administración de Kubernetes de las que hablamos en el capítulo Sistema de control antes, no necesita hacer una copia de seguridad del Master Y el propio nodo, debido a que la herramienta registra la información completa de su clúster, puede restaurar todo el clúster cuando sea necesario. Además, está mi imagen de Docker y el gráfico de Helm, etc.
| clasificación | Parte de respaldo |
|---|---|
| Racimo | Maestro |
| Nodo | |
| datos etcd | |
| Servicio empresarial | Imagen de Docker |
| Gráfico de timón | |
| Datos comerciales, documentos comerciales, etc. | |
| Iniciar sesión |
-
Alarma de monitorización
Cuando falla el sistema, es muy importante averiguar y notificar al personal pertinente la primera vez, para que los técnicos puedan intervenir a tiempo para evitar que la falla se expanda aún más. Hemos presentado el sistema de monitorización en detalle en el Capítulo 3. No hay más explicaciones aquí. -
Sistema de respuesta 24 horas Después de que
ocurre una falla, el personal técnico debe intervenir lo antes posible y solucionar la falla lo antes posible, luego es necesario formar un equipo de operación y mantenimiento de reserva las 24 horas. El equipo de operación y mantenimiento acompaña nuestro sistema en todo momento.
2 [Requisitos de rendimiento] El tiempo de respuesta, el rendimiento, la utilización de recursos; el
tiempo de respuesta y el rendimiento son los principales indicadores para medir un sistema. A menudo se dice que "no acepte trabajos de porcelana sin el diamante", tenemos que hacer cosas al diseñar el sistema Para averiguar la presión que nuestro sistema enfrentará en el futuro, como el requisito de tiempo de respuesta de un solo procesamiento, el requisito del volumen máximo de acceso por unidad de tiempo, el requisito del volumen máximo de procesamiento por unidad de tiempo, etc. Después de clasificar estos requisitos, determinaremos la cantidad de servidores, la configuración del servidor, el ancho de banda de la red, la capacidad de almacenamiento, el algoritmo de distribución de carga y si se utilizará el almacenamiento en caché y otras tecnologías de acuerdo con estos requisitos al diseñar el sistema. De esta manera, el sistema que construimos es solo uno Un sistema saludable que puede cumplir con los requisitos de rendimiento.
3 [Seguridad] Confidencialidad, anti-fugas, control de acceso y anti-ataque, la
seguridad requiere que el sistema tenga una solución de defensa de seguridad efectiva y una estrategia de control de acceso para prevenir la fuga de información sensible del sistema y el acceso inadecuado. Al diseñar, generalmente estoy dispuesto a dividirlo en consideraciones externas e internas. Las contramedidas internas y externas son básicamente similares. La siguiente tabla es las contramedidas de seguridad habituales.
| clasificación | Contramedida | Descripción |
|---|---|---|
| Externo | Herramienta de seguridad antivirus | Evita virus y ataques del exterior |
| Certificación | Evite el acceso no autorizado desde el exterior | |
| Aislamiento de red | Ocultar la parte sensible | |
| interno | Herramienta de seguridad antivirus | Evita los virus desde adentro |
| Control de acceso | Nivel de autoridad para evitar la filtración de información o el mal funcionamiento debido a una autoridad excesiva | |
| Servidor de entrada único | Una forma de aislamiento interno, otros servidores en el sistema a los que solo se puede acceder a través del servidor de entrada, para facilitar el monitoreo de operaciones y la administración de autoridad. |
4 [Escalabilidad] La expansión horizontal y la expansión vertical
suelen ser fáciles de entender, incluida la expansión del número de servidores, la expansión de la CPU, la memoria, el almacenamiento, la expansión de servicios, etc., pero la diferencia en Kubernetes Cluster es que todos Los requisitos de expansión deben completarse automáticamente, sin intervención manual. Solo así se pueden reflejar las ventajas de Kubenetes. Al diseñar el clúster de Kubernetes, debemos al menos considerar los requisitos de expansión en la siguiente tabla.
| clasificación | Contenido expandido | Automático / no automático |
|---|---|---|
| Escalador automático de clúster | Expansión de racimo horizontal | Automático (requiere soporte de terceros, como servicios en la nube) |
| Expansión de clúster vertical | Automático (requiere soporte de terceros, como servicios en la nube) | |
| en Escalador automático | Expansión horizontal | HPA automático |
| Expansión vertical | VPA automático (pero no recomendado) |
5 [Mantenibilidad] Modularidad, reutilización y fácil análisis;
después de que el sistema sea lanzado oficialmente, entrará en la fase de operación y mantenimiento, que siempre estará acompañada por todo el ciclo de vida del sistema, por lo que un sistema de fácil mantenimiento puede ser Reducir la carga de trabajo del personal de operación y mantenimiento y la probabilidad de mal funcionamiento es equivalente a mejorar indirectamente la confiabilidad del sistema. Debido a que la composición del sistema de Kubenetes es básicamente fija, tanto en forma de maestro como de nodo, para el mantenimiento conveniente del sistema de Kubernetes en el futuro, las principales consideraciones son la reutilización y la facilidad de análisis. La siguiente tabla es para lograr contramedidas reutilizables y fáciles de analizar.
| clasificación | Contramedidas de diseño | Descripción |
|---|---|---|
| Reutilizable | Configurar un entorno de prueba | El mismo entorno que el entorno de producción equivale a reutilizar el entorno de producción, que es una garantía importante para reducir las fallas del entorno de producción. |
| Utilice herramientas de administración de terceros | Herramientas como Pivotal, que mencionamos en los capítulos anteriores, pueden ayudarnos a completar tareas repetitivas de administración de KubernetesCluster. | |
| Rico manual | Problemas y fallas repetidos o similares, escríbalos en el manual y podrá usarlos directamente en el futuro | |
| Fácil de analizar | Información de diseño detallada y fácil de entender | Los diagramas del marco del sistema y otros materiales de diseño son materiales de referencia importantes para la operación y el mantenimiento futuros |
| Recopilar información de registro válida | Recopile información de registro completa y efectiva para nosotros a través del sistema de recopilación de información de registro para su análisis |
4. Resumen
Independientemente del tipo de sistema que esté diseñando, debe clasificar y analizar los requisitos no funcionales antes de diseñar, encontrar las soluciones correspondientes para cada requisito no funcional y luego reflejar estas soluciones en su diseño, para que el sistema diseñado sea seguro. Es un sistema sano. Por supuesto, no es fácil clasificar y analizar los requisitos no funcionales y encontrar las soluciones correspondientes. Los diseñadores deben tener conocimientos técnicos y suficiente experiencia en diseño. Solo a través de la experiencia a largo plazo en proyectos y la acumulación de conocimientos técnicos pueden Póngase en contacto con un diseñador de marcos de sistemas reales.
Autor: rm *
Fecha de grupo : 12 de septiembre de 2020