Kubernetes abstrae todo lo que está dentro de sus límites como recursos. La parte principal es el controlador de carga de trabajo representado por Deployment y StatefulSet, y otros recursos diversos funcionan en torno a estos recursos principales. Combinados, estos recursos pueden presentar un modelo centrado en la carga de trabajo para los trabajadores técnicos de TI. Todos los recursos en Kubernetes se editan y describen a través de archivos de configuración declarativos, y las definiciones de campo de Yaml se definen una por una, lo que no solo brinda a los técnicos de TI el mayor grado de libertad, sino que también presenta requisitos extremadamente altos sobre la capacidad de los técnicos.
Simplifique la gestión de Kubernetes con modelos de aplicaciones
Cuando su equipo haya estado usando Kubernetes nativo por un tiempo, probablemente encontrará que no todos los técnicos de TI son buenos para escribir archivos de configuración declarativos complejos de Kubernetes (YAML). Especialmente para los desarrolladores cuya responsabilidad principal es el desarrollo empresarial, aprender y escribir YAML puede aumentar su carga e incluso resistirse a usarlo.
El proyecto de código abierto Rainbond es una plataforma de gestión de aplicaciones nativa de la nube que utiliza un patrón de diseño centrado en la aplicación. En función de este patrón de diseño, se vuelve a abstraer un modelo de aplicación de nivel superior al de la carga de trabajo. No es necesario aprender y escribir YAML a partir de la experiencia de uso y realizar la gestión del ciclo de vida completo de las aplicaciones comerciales. La aplicación corresponde a un sistema empresarial completo, que consta de varios componentes de servicio que se pueden gestionar de forma independiente. Al implementar los componentes empresariales, puede editar la relación de invocación del servicio "arrastrando y soltando" desde el código fuente y las imágenes del contenedor. Cada componente de servicio puede definir y utilizar algunas características comunes de operación y mantenimiento basadas en la interfaz gráfica. Sobre esta base, los usuarios también pueden utilizar el concepto central del modelo de aplicación para realizar operaciones más avanzadas, como publicar todo el sistema comercial en forma de una plantilla de aplicación, y el sistema comercial se puede instalar/actualizar con un solo clic en función de la plantilla. En el campo de la entrega de software, esta capacidad es muy útil Ya sea que el entorno de entrega final sea en línea o fuera de línea, se puede entregar rápidamente en función de plantillas de aplicaciones e incluso entrega personalizada.
El modelo de aplicación utilizado por Rainbond facilita que los desarrolladores se concentren en la aplicación y el negocio en sí. Las funciones de operación y mantenimiento retenidas después del corte se muestran e interactúan a través de una interfaz gráfica, lo que reduce en gran medida la dificultad de uso. Al aplicar plantillas, la mayoría de los desarrolladores pueden usar Kubernetes sin problemas sin editar archivos de configuración declarativos complejos.
Convierta Kubernetes YAML en modelo de aplicación
Todo el proceso de conversión se puede resumir en tres pasos:
- Para las cargas de trabajo más utilizadas por los desarrolladores, se pueden generar automáticamente a partir del código fuente y las imágenes del contenedor de manera similar a un asistente, o importando YAML existente y aplicaciones en ejecución. El proceso de importación identifica automáticamente todos los recursos de tipo de carga de trabajo convertibles, incluida la implementación, Tipos StatefulSet, Job y CronJob. Estos recursos se transformarán en modelos de aplicaciones, que luego se ejecutarán como componentes de servicio.
- Después de importar los componentes de servicio generados, las propiedades básicas de la carga de trabajo se pueden ver y editar a través de la interfaz, como variables de entorno, direcciones espejo, etc. Durante el proceso de conversión, las propiedades avanzadas de carga de trabajo identificadas se agregarán a los componentes del servicio, que se pueden ver y administrar en forma de clave/valor o Yaml.
- Los tipos de recursos que no son de carga de trabajo, como Secret, ServiceAccount, Role y otros recursos, se clasificarán, identificarán y cargarán en la
k8s资源página para que el operador los edite en una experiencia interactiva.
Las propiedades avanzadas de la carga de trabajo que se pueden administrar y transformar incluyen:
| nombre de la propiedad | efecto |
|---|---|
| selector de nodos | Selector de nodos: se utiliza al especificar un cierto tipo de programación de nodos. |
| etiquetas | Etiquetas: se utilizan para personalizar las etiquetas de los componentes de servicio que utilizarán los selectores. |
| volúmenes | Volúmenes de almacenamiento: montajes utilizados para definir tipos de volúmenes que Rainbond no administra. |
| montajes de volumen | Montar volúmenes: se utiliza junto con volúmenes para montar volúmenes en contenedores. |
| afinidad | Afinidad: métodos de programación más avanzados, incluida la afinidad de nodos y la afinidad de pods. |
| tolerancias | Tolerancia: se usa junto con la contaminación del nodo, los pods con tolerancia específica se pueden programar para nodos específicos. |
| serviceAccountName | Nombre de cuenta de servicio: especifique una SA existente para el componente de servicio, de modo que el Pod correspondiente tenga ciertos permisos. |
| privilegiado | Modo privilegiado: Una verdadera configuración, no activada a menos que sea necesario. |
| env | Variables de entorno: se utilizan para definir variables de entorno que Rainbond no gestiona y admiten operaciones de referencia. |
Vale la pena señalar que el modelo de RAM expandido todavía se puede publicar como una plantilla de aplicación para la instalación/actualización/entrega posterior con un solo clic de todo el sistema empresarial.
Prueba y práctica de importación de aplicaciones Kubernetes existentes
La siguiente prueba se basa en Rainbond v5.8 Para probar la importación de aplicaciones existentes en Kubernetes, planeo wpusar el Wordpresssistema de creación de estaciones que se implementó en el espacio de nombres para realizar una prueba de importación. El sistema consta de los siguientes recursos:
[root@localhost ~]# kubectl get secret,service,deployment,statefulset,pod -n wp
NAME TYPE DATA AGE
secret/default-token-nq5rs kubernetes.io/service-account-token 3 27m
secret/mysql-secret Opaque 2 27m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/wordpress NodePort 10.43.157.40 <none> 8080:30001/TCP 5m19s
service/wp-mysql ClusterIP 10.43.132.223 <none> 3306/TCP 27m
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/wordpress 1/1 1 1 5m19s
NAME READY AGE
statefulset.apps/wp-mysql 1/1 27m
NAME READY STATUS RESTARTS AGE
pod/wordpress-66bc999449-qv97v 1/1 Running 0 5m19s
pod/wp-mysql-0 1/1 Running 0 27m
Visite Rainbond y seleccione Importar en el clúster En esta página, puede seleccionar el espacio de nombres para importar recursos wp. La plataforma agrupará los recursos según etiquetas:
Rainbond divide las aplicaciones de acuerdo labelcon . Por ejemplo, los recursos que coinciden oapp.kubernetes.io/name:wp-mysql se distribuirán a dos aplicaciones diferentes en la figura. Si los recursos anteriores no están disponibles, se dividirán uniformemente en una aplicación sin agrupar. La división de aplicaciones es muy crítica, porque la aplicación avanzada del modelo de aplicación es para una aplicación como un todo, por lo que debe planificar cuidadosamente antes de importar y agregar otras razonables .app:wordpresslabellabel
Durante el proceso de importación, Rainbond asigna diferentes propiedades al modelo extendido para su administración. La mayoría de las operaciones de operación y mantenimiento se han vuelto muy fáciles de usar, mientras que la otra parte es administrada por la página de propiedades de Kubernetes.
Una vez importadas, ambaswordpress aplicaciones se pueden gestionar mediante Rainbond.wp-mysql
- gestión portuaria
wordpressAntes de importar, confíe en el NodePorttipo de Serviceexposición externa, pero después de importar la gestión de Rainbond, puede usar la puerta de enlace para exponer su propio puerto 80 al mundo exterior. Tenga en cuenta que debe reiniciar el componente de wordpressservicio para que la política de acceso surta efecto.
Para algunos servicios, la entrada de acceso no admite la designación dinámica, lo que requiere algunos cambios en el lado comercial para adaptarse a la nueva entrada de acceso. WordpressPara , se debe redefinir la dirección del sitio en las opciones generales.
- Administración de almacenamiento
El wordpresssistema usa el hostpathmodo de almacenamiento para todos los componentes. Aunque esta configuración es simple, no es adecuada para entornos de Kubernetes a gran escala Podque pueden derivar. Después de implementar Rainbond, proporcionará almacenamiento compartido fácil de usar, que admite el intercambio de datos entre varios pods y la migración de pods entre hosts. El almacenamiento de hostpath original se puede redefinir. La ruta de almacenamiento redefinida quedará vacía, así que recuerde encontrar las rutas nueva y antigua y realizar una migración de datos.
significado práctico
A través del modelo de aplicación, los técnicos de TI pueden prestar más atención al negocio en sí, en lugar del uso de las complejas herramientas subyacentes. El efecto final es simplificar el costo de operación y la dificultad de comprensión, y hacer que Kubernetes sea más fácil de implementar.