Autor: Liu Jiaxu (apodo: Jiaxu), experto técnico en servicios de contenedores de Alibaba Cloud
introducción
Con el rápido desarrollo de la tecnología nativa de la nube y su aplicación profunda en el campo de la TI empresarial, la arquitectura de alta disponibilidad en escenarios nativos de la nube se ha vuelto cada vez más importante para la disponibilidad, estabilidad y seguridad de los servicios empresariales. A través de un diseño arquitectónico razonable y soporte técnico de plataforma en la nube, la arquitectura de alta disponibilidad nativa de la nube puede proporcionar alta disponibilidad, escalabilidad elástica, operación simplificada y gestión de mantenimiento, confiabilidad y seguridad mejoradas y otras ventajas, brindando a las empresas servicios más confiables y eficientes. entorno operativo.
Kubernetes es una de las tecnologías centrales nativas de la nube. Proporciona capacidades de gestión y orquestación de contenedores, incluida la automatización de la infraestructura, la escalabilidad elástica, la arquitectura de microservicios y la operación y el mantenimiento automatizados. Por lo tanto, la arquitectura de alta disponibilidad de aplicaciones de Kubernetes es nativa de la nube y tiene alta disponibilidad. piedra angular. Este artículo tomará Alibaba Cloud Container Service para Kubernetes (ACK) como ejemplo para presentar las mejores prácticas para la arquitectura de alta disponibilidad y el gobierno de aplicaciones basadas en ACK.
Diseño de arquitectura de aplicaciones de alta disponibilidad.
El diseño de la arquitectura de alta disponibilidad de las aplicaciones nativas de la nube es un requisito previo importante para el desarrollo, la implementación y la gobernanza de aplicaciones de alta disponibilidad y se puede considerar desde los siguientes aspectos:
1. Diseño del clúster: los componentes y nodos del plano de control y del plano de datos del clúster se implementan con alta disponibilidad de múltiples nodos y múltiples copias para garantizar la alta disponibilidad del clúster K8. Tomando ACK como ejemplo, proporciona capacidades de alta disponibilidad del clúster que cubren el plano de control y el plano de datos. En el plano de control, los componentes del plano de control del clúster de la versión administrada de ACK Pro se implementan en zonas de disponibilidad utilizando múltiples copias y son automáticamente elásticos según la presión de carga en el plano de control; la versión propietaria de ACK se puede configurar con 3 o 5 maestros. nodos. En el lado de los datos, ACK respalda la capacidad de los usuarios de elegir implementar y agregar nodos en zonas de disponibilidad y conjuntos de implementación de ECS.
2. Diseño de contenedor: las aplicaciones se implementan con múltiples copias en el clúster y las copias de las aplicaciones se administran según Deployment, Statefulset y OpenKruise CRD para lograr una alta disponibilidad de las aplicaciones; se configuran políticas elásticas automáticas para que las aplicaciones puedan hacer frente a los cambios dinámicos en la carga. . En el escenario de Pods de copias múltiples, dependiendo de si hay copias en los roles primario y secundario, se puede dividir en alta disponibilidad primaria y secundaria y alta disponibilidad multiactiva.
3. Programación de recursos: utilice el programador K8 para lograr el equilibrio de carga de la aplicación y la conmutación por error. Utilice etiquetas y selectores para especificar el rango de nodos de implementación de la aplicación y utilice reglas de restricción de programación de topología, antiafinidad y afinidad para controlar la estrategia de programación de la aplicación para implementar Pods por nodo, zona de disponibilidad, conjunto de implementación, dominio de topología, etc. Diferentes categorías de alta disponibilidad.
4. Diseño de almacenamiento: utilice almacenamiento persistente para guardar datos de aplicaciones, como volúmenes persistentes de K8 para montar almacenamiento, etc., para evitar la pérdida de datos. Para aplicaciones con estado, utilice StatefulSet para administrar réplicas y volúmenes de almacenamiento de aplicaciones con estado.
5. Recuperación de fallas: utilice el mecanismo de recuperación automática de K8 para manejar fallas de la aplicación. Puede utilizar comprobaciones de estado y reinicios automáticos para monitorear el estado de su aplicación y reiniciarla o migrarla automáticamente en caso de que falle.
6. Diseño de red: utilice las funciones de descubrimiento de servicios y equilibrio de carga de K8 para implementar el acceso a la red de aplicaciones y utilice Servicio e Ingreso para exponer los servicios de aplicaciones.
7. Monitoreo y alarmas: utilice los sistemas de monitoreo y alarmas de K8 (como Prometheus, Thanos, AlertManager, etc.) para monitorear el estado de ejecución de la aplicación y descubrir y manejar fallas de manera oportuna.
8. Diseño de alta disponibilidad de enlace completo: la alta disponibilidad de enlace completo se refiere a la alta disponibilidad de todos los componentes, módulos, servicios, redes y otros enlaces involucrados en sistemas y servicios de aplicaciones nativas de la nube. La alta disponibilidad de enlace completo es una consideración integral que requiere una consideración e implementación integral desde el diseño arquitectónico de todo el sistema, la selección y configuración de componentes, la implementación del servicio y la operación y mantenimiento. Al mismo tiempo, es necesario hacer concesiones y compensaciones adecuadas en función de las necesidades empresariales y requisitos técnicos específicos.
En resumen, diseñar una arquitectura de alta disponibilidad para aplicaciones K8 requiere una consideración integral de factores como clústeres, contenedores, programación de recursos, almacenamiento, recuperación de fallas, red y monitoreo de alarmas para lograr una arquitectura y funciones de alta disponibilidad de aplicaciones confiables y estables. La transformación de alta disponibilidad de los sistemas existentes también se puede implementar haciendo referencia a los principios anteriores.
A continuación se presentarán las diversas tecnologías de alta disponibilidad proporcionadas por Kubernetes basadas en los principios de diseño anteriores, así como las implementaciones de productos relacionados basadas en ACK.
Tecnología de alta disponibilidad K8s y su aplicación en ACK
Kubernetes proporciona una variedad de tecnologías y mecanismos de alta disponibilidad para garantizar una alta disponibilidad de clústeres y aplicaciones. Incluyendo restricciones de distribución de topología, PodAntiAffinity, verificación del estado del contenedor y reinicio automático, redundancia y persistencia del almacenamiento, descubrimiento de servicios y equilibrio de carga, etc. Estas tecnologías y mecanismos pueden ayudar a crear clústeres y aplicaciones de Kubernetes de alta disponibilidad y proporcionar servicios estables y confiables, que se presentarán a continuación.
3.1 El plano de control/plano de datos tiene alta disponibilidad en múltiples zonas de disponibilidad
La agrupación en clústeres logra una alta disponibilidad mediante la implementación de nodos/componentes del plano de control y del plano de datos en diferentes zonas de disponibilidad.Es un método importante de diseño de arquitectura de alta disponibilidad. Las zonas de disponibilidad son centros de datos lógicamente independientes proporcionados por un proveedor de nube dentro de un área geográfica. Al implementar nodos en diferentes zonas de disponibilidad, puede garantizar que el clúster pueda continuar brindando servicios incluso si una zona de disponibilidad falla o deja de estar disponible.
Los siguientes son los puntos clave del diseño de alta disponibilidad de los nodos del clúster K8 basados en zonas de disponibilidad, que se pueden utilizar para implementar la configuración de alta disponibilidad de los nodos del plano de control/plano de datos basados en zonas de disponibilidad en Kubernetes:
-
Múltiples opciones de zona de disponibilidad
Elija varias zonas de disponibilidad admitidas por su proveedor de nube para su clúster a fin de reducir el riesgo de puntos únicos de falla.
-
Implementar nodos/componentes del plano de control
Implemente nodos y componentes del plano de control (como etcd, kube-apiserver, kube-controller-manager, kube-scheduler) en diferentes zonas de disponibilidad y utilice el equilibrador de carga del proveedor de la nube o la resolución DNS para distribuir el tráfico al backend. Configure un clúster etcd de alta disponibilidad utilizando varios nodos etcd y distribúyalos en diferentes zonas de disponibilidad. Esto garantiza que incluso si uno de los nodos etcd falla, el clúster aún pueda continuar funcionando.
-
Implementar nodos del plano de datos
Distribuya los nodos del plano de datos en múltiples zonas de disponibilidad para garantizar que los pods se puedan programar en diferentes zonas de disponibilidad para lograr una alta disponibilidad entre zonas de disponibilidad.
-
Monitoreo y recuperación automática Configure sistemas de monitoreo para monitorear el estado del clúster y configurar mecanismos de recuperación automática para la conmutación por error y la recuperación automáticas en caso de falla del nodo o de la zona de disponibilidad.
Al implementar nodos/componentes del plano de control y nodos del plano de datos en múltiples zonas de disponibilidad, se puede mejorar la disponibilidad y la tolerancia a fallas del clúster de Kubernetes, asegurando que el clúster pueda continuar brindando servicios incluso cuando falla una única zona o nodo de disponibilidad.
ACK proporciona capacidades de alta disponibilidad del clúster que cubren el plano de control y el plano de datos. El servicio de contenedor ACK utiliza la arquitectura Kubernetes en Kubernetes para alojar los componentes del plano de control del clúster de Kubernetes del usuario, incluidos etcd, servidor API, programador, etc. Se implementan y administran múltiples instancias de cada componente del plano de control mediante una arquitectura de alta disponibilidad. Si el número de zonas de disponibilidad en la región donde está ubicado el clúster ACK Pro es 3 o más, el SLA del plano de control del clúster administrado ACK Pro es 99,95 %; si el número de zonas de disponibilidad en la región donde está el clúster ACK Pro ubicado es 2 o menos, el SLA del plano de control del clúster administrado ACK Pro es El SLA es 99,50 %.
El servicio de contenedor ACK es responsable de la alta disponibilidad, la seguridad y la expansión y contracción elástica de los componentes de alojamiento. El clúster ACK Pro proporciona capacidades completas de observabilidad para los componentes administrados, lo que ayuda a los usuarios a monitorear y alertar sobre el estado del clúster.
A continuación se presentan tecnologías comunes para controlar la fragmentación de alta disponibilidad por zonas de disponibilidad y su uso en escenarios ACK, que se utilizan ampliamente en escenarios de alta disponibilidad en el plano de datos.
3.1.1 Restricciones de extensión de topología
Topology Spread Constraints es una función que gestiona la distribución de Pod en un clúster de Kubernetes. Garantiza que los Pods se distribuyan uniformemente entre diferentes nodos y zonas de disponibilidad para mejorar la alta disponibilidad y estabilidad de las aplicaciones. Esta tecnología se aplica a las cargas de trabajo Deployment, StatefulSet, DaemonSet y Job/CronJob.
Al utilizar restricciones de distribución topológica, puede establecer la siguiente configuración para controlar la distribución de Pods:
-
MaxSkew
Especifique el valor de desviación máxima de Pods en cada dominio topológico. Los dominios de topología pueden ser nodos, zonas de disponibilidad u otros dominios de topología personalizados. El valor de desviación máxima es un número entero que representa la diferencia máxima entre Pods en dos dominios topológicos cualesquiera del clúster. Por ejemplo, si MaxSkew se establece en 2, la diferencia en la cantidad de Pods en dos dominios topológicos cualesquiera no debe exceder 2.
-
Clave de topología
Especifica la clave utilizada para identificar la etiqueta o anotación del dominio topológico. Puede utilizar etiquetas de nodo (como node.kubernetes.io/zone) o etiquetas o anotaciones personalizadas.
-
Cuando insatisfactorio
Especifica la acción a tomar cuando no se pueden cumplir las restricciones de distribución topológica. Las operaciones que se pueden seleccionar son DoNotSchedule (que no programa Pods), ScheduleAnyway (que obliga a programar Pods) y RequireDuringSchedulingIgnoredDuringExecution (que requiere restricciones de distribución de topología, pero no las aplica).
Al utilizar estas configuraciones, puede crear políticas con restricciones de distribución topológica para garantizar que los Pods se implementen en el clúster de acuerdo con la distribución topológica deseada. Esto es útil para aplicaciones que necesitan distribuir la carga de manera uniforme entre diferentes zonas de disponibilidad o nodos para mejorar la confiabilidad y la disponibilidad.
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-run-per-zone
spec:
replicas: 3
selector:
matchLabels:
app: app-run-per-zone
template:
metadata:
labels:
app: app-run-per-zone
spec:
containers:
- name: app-container
image: app-image
topologySpreadConstraints:
- maxSkew: 1
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: DoNotSchedule
En el ejemplo anterior, se crea una restricción de distribución de topología con maxSkew establecido en 1, topologyKey establecido en "topology.kubernetes.io/zone" y whenUnsatisfiable establecido en DoNotSchedule. Esto significa que los Pods se dispersan a la fuerza por zonas de disponibilidad de acuerdo con el dominio de topología definido por la etiqueta del nodo "topology.kubernetes.io/zone" (correspondiente a la zona de disponibilidad del proveedor de la nube) y la diferencia máxima en la cantidad de Pods entre topologías. dominios es 1. De esta manera, los Workload Pods se pueden dispersar y programar según las zonas de disponibilidad tanto como sea posible.
El plano de control del clúster ACK K8 adopta de forma predeterminada una arquitectura de alta disponibilidad de zona de disponibilidad múltiple y, además, necesitamos implementar una arquitectura de zona de disponibilidad múltiple para el plano de datos. El plano de datos del clúster ACK consta de grupos de nodos y nodos virtuales. Cada grupo de nodos es un grupo de instancias de ECS. A través del grupo de nodos, los usuarios pueden administrar, expandir y reducir los nodos y realizar operaciones y mantenimiento diarios. Los nodos virtuales pueden proporcionar un entorno de ejecución de contenedores sin servidor a través de instancias de contenedores elásticos ECI.
Detrás de cada grupo de nodos hay un grupo de escalamiento elástico (ESS), que admite la expansión manual y el escalado elástico automático de nodos. El grupo de nodos ACK admite conjuntos de implementación, que pueden dispersar e implementar instancias de ECS en el mismo conjunto de implementación en diferentes servidores físicos, evitando así el tiempo de inactividad de múltiples instancias de ECS debido a la falla de una máquina física. ACK también admite grupos de nodos multi-AZ: durante la creación y la operación, se pueden seleccionar varios vSwitches que abarcan diferentes AZ para el grupo de nodos. Y seleccione la estrategia de distribución equilibrada , para que las instancias de ECS se puedan distribuir uniformemente entre las múltiples zonas de disponibilidad especificadas por el grupo de escalamiento (es decir, especificando múltiples conmutadores de VPC). Si las zonas de disponibilidad se desequilibran debido a un inventario insuficiente u otros motivos, puede realizar una operación de equilibrio para equilibrar la distribución de recursos de la zona de disponibilidad.
Con base en la metainformación de diferentes dominios de falla, como nodos, conjuntos de implementación y AZ, combinadas con las restricciones de distribución de topología (Restricciones de distribución de topología) en la programación de K8, podemos lograr diferentes niveles de capacidades de aislamiento de dominio de falla. Primero, todos los nodos en el grupo de nodos ACK agregarán automáticamente etiquetas relacionadas con la topología, como "kubernetes.io/hostname", "topology.kubernetes.io/zone", "topology.kubernetes.io/region", etc. Los desarrolladores pueden utilizar restricciones de distribución topológica para controlar la distribución de Pods entre diferentes dominios de fallas para mejorar la tolerancia a fallas de infraestructura subyacentes.
3.1.2 Relación entre restricciones de distribución topológica y NodeAffinity/NodeSelector
La relación entre las restricciones de distribución de topología y NodeAffinity/NodeSelector es que Node Affinity y Node Selectors se utilizan principalmente para controlar la programación de Pods en un rango específico de nodos, mientras que las restricciones de distribución de topología se centran más en controlar la distribución de Pods entre diferentes dominios topológicos. . Estos mecanismos se pueden combinar para proporcionar un control más detallado sobre la programación y distribución de Pods.
NodeAffinity y NodeSelector se pueden utilizar con restricciones de distribución topológica. Primero puede usar NodeAffinity y NodeSelector para seleccionar nodos que cumplan condiciones específicas y luego usar restricciones de distribución topológica para garantizar que la distribución de Pods en estos nodos cumpla con los requisitos de distribución topológica esperados.
Para más detalles, consulte [1] .
Con respecto al uso mixto de Node Affinity y Node Selectors con restricciones de distribución topológica, consulte [2] .
3.1.3 Deficiencias de las restricciones de distribución topológica
Existen algunas limitaciones y deficiencias en las restricciones de distribución topológica, que deben tenerse en cuenta:
-
Limitación en la cantidad de zonas de disponibilidad: si la cantidad de zonas de disponibilidad es muy limitada, o solo hay una zona de disponibilidad disponible, es posible que el uso de restricciones de distribución topológica no brinde sus beneficios. En este caso, no se puede lograr un verdadero aislamiento de fallas de zona de disponibilidad y alta disponibilidad.
-
Cuando se elimina un Pod, no hay garantía de que las restricciones aún se cumplan. Por ejemplo, reducir una implementación puede resultar en una distribución desigual de los pods.
-
El planificador no tiene conocimiento previo de todas las regiones del clúster ni de otros dominios topológicos. Se determinan en función de los nodos existentes en el clúster. Esto puede causar problemas en los clústeres de escalamiento automático, cuando un grupo de nodos (o grupo de nodos) se reduce a cero nodos y el usuario espera que el clúster pueda escalar, momento en el cual estos dominios topológicos no se considerarán hasta al menos Hay un nodo en él.
Consulte [3] para más detalles .
3.1.4 Múltiples zonas de disponibilidad para lograr una expansión elástica rápida y simultánea
El componente de escalado automático del nodo ACK puede determinar si el servicio se puede implementar en un determinado grupo de escalado mediante la programación previa y luego envía una solicitud para expandir la cantidad de instancias al grupo de escalado especificado y, finalmente, el grupo de escalado ESS genera instancias. . Sin embargo, esta característica del modelo de configurar múltiples zonas de disponibilidad vSwtich en un grupo de escalamiento generará los siguientes problemas:
Cuando un Pod empresarial multi-AZ no se puede programar debido a recursos insuficientes del clúster, el servicio de escalado automático del nodo activará la expansión del grupo de escalado, pero la relación entre la zona de disponibilidad y la instancia que necesita expandirse no se puede pasar a El grupo de escalamiento elástico de ESS, por lo que puede aparecer continuamente. Múltiples instancias en una determinada región, en lugar de aparecer en múltiples vSwtich al mismo tiempo, no pueden satisfacer las necesidades de expansión simultánea en múltiples zonas de disponibilidad.
El equilibrio de zonas de disponibilidad múltiple es un método de implementación común en escenarios de alta disponibilidad para tipos de datos. Cuando aumenta la presión empresarial, la aplicación de una estrategia de programación equilibrada de zonas de disponibilidad múltiple espera expandir automáticamente las instancias en múltiples zonas de disponibilidad para cumplir con el nivel de programación del clúster.
Para resolver el problema de expandir simultáneamente nodos en múltiples zonas de disponibilidad, Container Service ACK introduce el componente ack-autoscaling-placeholder, que utiliza una pequeña cantidad de redundancia de recursos para transformar el problema de escalado elástico de múltiples zonas de disponibilidad en un problema de escalado direccional. de grupos de nodos concurrentes.
Los principios específicos son los siguientes:
-
Primero, cree un grupo de nodos para cada zona de disponibilidad y etiquete cada grupo de nodos con la zona de disponibilidad.
-
Al configurar la etiqueta de zona de disponibilidad nodeSelector, use ack-autoscaling-placeholder para crear un Pod de marcador de posición para cada zona de disponibilidad. El Pod de marcador de posición predeterminado tiene una PriorityClass de peso relativamente bajo y el Pod de aplicación tiene una prioridad más alta que el Pod de marcador de posición.
-
De esta manera, después de que la empresa aplique Pod Pendiente, se adelantará a los pods en cada zona de disponibilidad. Después de que los pods de zona de disponibilidad múltiple con la zona de disponibilidad nodeSelector estén en Pendiente, la política de programación percibida por el componente de escalado automático del nodo es de la antiafinidad se convierte en el selector de nodos para la zona de disponibilidad, lo que facilita el manejo de solicitudes de nodos que emiten zonas de expansión.
Las dos zonas de disponibilidad en la figura siguiente se toman como ejemplo para presentar el método de utilizar la arquitectura existente para cumplir con la expansión simultánea de múltiples zonas de disponibilidad.
Consulte [4] para obtener más detalles .
3.1.5 Recuperación automática después de que se daña la capacidad de la zona de disponibilidad
Cuando un clúster de alta disponibilidad multizona enfrenta una falla AZ, a menudo significa que la capacidad de la aplicación está dañada. K8 expandirá automáticamente la capacidad según la cantidad de copias de la aplicación o la configuración HPA (escalado horizontal de Pod). Esto requiere que el clúster esté configurado con Cluster AutoScaler o nodos virtuales para lograr la expansión automática de los recursos del clúster. Al utilizar Cluster AutoScaler, puede reservar recursos mediante la sobreasignación, lo que puede iniciar rápidamente aplicaciones de contenedor y evitar interrupciones comerciales causadas por una expansión subyacente lenta o fallida. Consulte [5] para obtener más detalles .
3.2 Aplicar antiafinidad Pod por nodo (PodAntiAffinity)
Pod Anti-Affinity es una estrategia de programación en Kubernetes que se utiliza para garantizar que los Pods no estén programados en el mismo nodo al programarlos. Esto se puede utilizar para dispersar los nodos Pod y mejorar la alta disponibilidad y las capacidades de aislamiento de fallas de la aplicación.
Al utilizar la política antiafinidad de Pods, puede configurar los siguientes métodos para controlar la dispersión de nodos de los Pods:
1.Requerido durante la programación, ignorado durante la ejecución
Esta es una política aplicada que requiere que las relaciones de antiafinidad entre Pods se cumplan en el momento de la programación. Esto significa que el programador de Kubernetes hará todo lo posible para garantizar que al programar Pods, no estén programados en el mismo nodo. Sin embargo, después de la programación, si los recursos del nodo son insuficientes u otras razones hacen necesario ejecutar estos Pods en el mismo nodo, Kubernetes ignorará esta política antiafinidad.
2.PreferredDuringSchedulingIgnoredDuringExecution
Esta es una estrategia preferida que recomienda mantener relaciones de antiafinidad entre Pods, pero no es un requisito. Cuando el programador tiene múltiples opciones, intentará evitar programar estos Pods en el mismo nodo. Sin embargo, el programador aún puede programar estos Pods en el mismo nodo si no hay otra opción viable disponible.
Al utilizar la política antiafinidad de Pods, puede controlar la distribución de Pods en el clúster y evitar programarlos en el mismo nodo, logrando así la dispersión de nodos. Esto es útil para aplicaciones que necesitan ejecutar Pods en diferentes nodos para mejorar la disponibilidad y el aislamiento de fallas.
El siguiente es un ejemplo de antiafinidad de Pod:
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-run-per-node
spec:
replicas: 3
selector:
matchLabels:
app: app-run-per-node
template:
metadata:
labels:
app: app-run-per-node
spec:
containers:
- name: app-container
image: app-image
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- app-run-per-node
topologyKey: "kubernetes.io/hostname"
En el ejemplo anterior, se establecen configuraciones antiafinidad para los Pods, lo que requiere que el programador se asegure de que estos Pods no estén programados en el mismo nodo al programar. La clave de topología está configurada en "kubernetes.io/hostname", lo que permite que el programador se distribuya entre diferentes nodos.
Tenga en cuenta que la antiafinidad de Pod y la afinidad de nodo (Node Affinity) son conceptos diferentes. La afinidad de nodo se usa para especificar que los Pods prefieren programarse en nodos con etiquetas específicas, mientras que la antiafinidad de Pod se usa para garantizar que los Pods no estén programados en el mismo nodo. La combinación de estas dos estrategias de programación permite una programación y distribución de nodos más flexible y tolerante a fallas.
Según TopologySpreadConstraints, también es posible lograr el efecto de programación de alta disponibilidad de Pods por nodo. Especificar topologyKey: "kubernetes.io/hostname" equivale a que cada nodo sea un dominio de topología para lograr una comparación sesgada entre nodos. El siguiente es un ejemplo de una restricción de distribución topológica:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app-container
image: my-app-image
topologySpreadConstraints:
- maxSkew: 1
topologyKey: "kubernetes.io/hostname"
whenUnsatisfiable: DoNotSchedule
En el ejemplo anterior, se crea una restricción de distribución de topología con maxSkew establecido en 1, topologyKey establecido en "kubernetes.io/hostname" y whenUnsatisfiable establecido en DoNotSchedule. Esto significa que solo se puede ejecutar 1 Pod en cada nodo para obligar a los Pods a dispersarse por nodo para lograr una alta disponibilidad.
3.3 Alta disponibilidad de copias múltiples de aplicaciones
En Kubernetes, se puede lograr una alta disponibilidad de copias múltiples de aplicaciones en función de una variedad de cargas de trabajo, como recursos avanzados de CRD como Deployment, Statefulset y OpenKruise. Tomando la implementación como ejemplo, el recurso de implementación es un controlador que se utiliza para definir la cantidad de copias de Pod. Es responsable de garantizar que la cantidad especificada de copias siempre se esté ejecutando y crea automáticamente nuevas copias cuando una copia falla.
3.3.1 Aplicación multiactividad y alta disponibilidad
La multiactividad y la alta disponibilidad de una aplicación significa que varias copias de la aplicación pueden recibir tráfico y procesar servicios de forma independiente. El número de copias se puede configurar a través de HPA y la elasticidad automática activada por la presión de carga se puede utilizar para adaptarse al tráfico dinámico, como como API Server y Nginx Ingress.Controller. Esta forma de diseño de alta disponibilidad debe considerar cuestiones como la coherencia de los datos y el rendimiento de múltiples copias.
3.3.2 Aplicación activa y alta disponibilidad de respaldo
La alta disponibilidad principal y de respaldo de una aplicación significa que hay copias primarias y copias de respaldo en múltiples copias de la aplicación, la más común es una maestra y una de respaldo, también hay formas más complejas como una maestra y múltiples esclavos. El maestro se selecciona basándose en el agarre de cerraduras y otros métodos. Es aplicable Componentes en forma de controladores. Por ejemplo, Etcd, KubeControllerManager y KubeScheduler son aplicaciones de alta disponibilidad en modo activo y de respaldo.
Los usuarios pueden diseñar el controlador para que utilice modo de espera activo o multiactivo según sus propios escenarios y formas comerciales.
3.3.3 PDB mejora la alta disponibilidad de la aplicación
Para mejorar aún más la disponibilidad de las aplicaciones, la configuración Pod Disruption Budget (PDB) también se puede utilizar en Kubernetes. PDB permite a los usuarios definir una cantidad mínima de réplicas disponibles. Cuando se produce una falla o mantenimiento del nodo, Kubernetes se asegurará de que al menos la cantidad especificada de réplicas permanezcan ejecutándose. PDB puede evitar que se terminen demasiadas réplicas al mismo tiempo, lo que es especialmente adecuado para escenarios donde varias réplicas en vivo manejan el tráfico, como los productos MessageQueue, evitando así la interrupción del servicio.
Para utilizar una PDB, agregue un recurso de PDB a la configuración de implementación o StatefulSet y especifique la cantidad mínima de réplicas disponibles. Por ejemplo, el siguiente es un ejemplo de configuración de implementación usando PDB:
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-with-pdb
spec:
replicas: 3
selector:
matchLabels:
app: app-with-pdb
template:
metadata:
labels:
app: app-with-pdb
spec:
containers:
- name: app-container
image: app-container-image
ports:
- containerPort: 80
---
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: pdb-for-app
spec:
minAvailable: 2
selector:
matchLabels:
app: app-with-pdb
En el ejemplo anterior, la configuración de implementación define 3 réplicas y la configuración de PDB especifica que al menos 2 réplicas deben mantenerse disponibles. Esto significa que incluso durante el mantenimiento o falla del nodo, Kubernetes garantizará que al menos 2 réplicas estén siempre en ejecución, mejorando la disponibilidad de las aplicaciones en el clúster de Kubernetes y reduciendo posibles interrupciones del servicio.
3.4 Detección de salud y autocuración
En Kubernetes, puede monitorear y administrar el estado y la disponibilidad de los contenedores configurando diferentes tipos de sondas. Las siguientes son configuraciones y estrategias de sonda comúnmente utilizadas en Kubernetes:
-
Sondas Liveness Las sondas Liveness se utilizan para monitorear si el contenedor todavía se está ejecutando normalmente. Si la prueba de actividad falla (devuelve un código de estado distinto de 200), Kubernetes reiniciará el contenedor. Al configurar una sonda de supervivencia, puede asegurarse de que el contenedor pueda reiniciarse automáticamente cuando ocurre un problema. Las sondas de actividad pueden detectar mediante solicitudes HTTP, sockets TCP o ejecución de comandos.
-
Sondas de preparación Las sondas de preparación se utilizan para monitorear si el contenedor está listo para recibir tráfico. Kubernetes reenviará el tráfico al contenedor solo si la prueba de preparación tiene éxito (devolviendo un código de estado 200). Al configurar sondas de preparación, puede garantizar que los contenedores se agreguen al balanceador de carga del servicio solo cuando estén completamente iniciados y listos para recibir solicitudes.
-
Sondas de inicio Las sondas de inicio se utilizan para monitorear si el contenedor se está iniciando. A diferencia de las sondas de actividad y de preparación, las sondas de inicio se ejecutan durante el inicio del contenedor y el contenedor se marca como listo solo después de que la sonda se realiza correctamente. Si falla el inicio de la sonda, Kubernetes marca el contenedor como fallido y lo reinicia.
-
Política de reinicio Una política de reinicio define las acciones que se deben tomar cuando sale un contenedor. Kubernetes admite las siguientes tres estrategias de reinicio:
<!---->
-
- Siempre: Kubernetes reiniciará automáticamente el contenedor sin importar cómo salga.
- OnFailure: Kubernetes reiniciará automáticamente el contenedor solo si el contenedor sale con un estado distinto de cero.
- Nunca: Kubernetes no reiniciará automáticamente el contenedor sin importar cómo salga.
Esto se puede configurar agregando las sondas correspondientes y las políticas de reinicio en la configuración del Pod o Deployment, por ejemplo:
apiVersion: v1
kind: Pod
metadata:
name: app-with-probe
spec:
containers:
- name: app-container
image: app-image
livenessProbe:
httpGet:
path: /health
port: 80
initialDelaySeconds: 10
periodSeconds: 5
readinessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 15
periodSeconds: 10
startupProbe:
exec:
command:
- cat
- /tmp/ready
initialDelaySeconds: 20
periodSeconds: 15
restartPolicy: Always
En el ejemplo anterior, una sonda de actividad (que detecta el puerto 80 con la ruta /health a través de una solicitud HTTP GET), una sonda de preparación (que detecta el puerto 8080 a través de un socket TCP) y una sonda de inicio (usando el comando cat /tmp/ready para detectar si el contenedor se ha iniciado) y la política de reinicio es Siempre. Según las necesidades reales, se puede realizar la configuración adecuada en función de las características del contenedor y los requisitos de control de salud.
3.5 Desacoplamiento de aplicaciones y datos
En Kubernetes, el desacoplamiento de aplicaciones y datos se puede lograr mediante el uso de volúmenes persistentes (PV) y reclamaciones de volumen persistente (PVC), o puede elegir un almacenamiento de servicio de base de datos de back-end adecuado.
PV y PVC proporcionan una capa de abstracción que las aplicaciones pueden utilizar independientemente de la tecnología de almacenamiento subyacente. Los volúmenes persistentes son recursos de almacenamiento en el clúster y son independientes de los pods y los nodos. Las reclamaciones de volumen persistente son solicitudes de volúmenes persistentes que se utilizan para vincular recursos de almacenamiento a los pods de la aplicación.
Para elegir las reclamaciones de volumen persistente y los volúmenes persistentes correctos, hay varios factores a considerar:
-
tipo de almacenamiento
Elija el tipo de almacenamiento adecuado según las necesidades de su aplicación. Kubernetes admite una variedad de tipos de almacenamiento, incluido el almacenamiento local, el almacenamiento en red (como NFS, iSCSI, etc.), el almacenamiento persistente del proveedor de la nube (como Alibaba Cloud OSS, etc.) y complementos de almacenamiento externo (como Ceph , GlusterFS, etc.). Elija el tipo de almacenamiento adecuado según los requisitos de disponibilidad, protección de datos y rendimiento de lectura y escritura de su aplicación.
-
almacenamiento
Elija la capacidad de almacenamiento adecuada según las necesidades de almacenamiento de su aplicación. Al crear un volumen persistente, puede especificar el rango de tamaño de la capacidad de almacenamiento. Al crear una reclamación de volumen persistente, puede especificar la capacidad de almacenamiento requerida. Asegúrese de proporcionar a su aplicación suficiente espacio de almacenamiento para satisfacer sus necesidades de almacenamiento de datos.
-
modo de acceso
Seleccione el modo de acceso apropiado según el modo de acceso de la aplicación. Kubernetes admite múltiples modos de acceso, incluida lectura y escritura consistentes (ReadWriteOnce), lectura y escritura varias veces (ReadWriteMany) y solo lectura (ReadOnlyMany). Elija el modo de acceso adecuado según las necesidades de acceso a múltiples nodos de su aplicación.
Al elegir un servicio de datos backend adecuado, como RDS, debe considerar los siguientes factores:
-
Tipos y funciones de bases de datos
Elija el tipo de base de datos adecuado según las necesidades de su aplicación. Los diferentes tipos de bases de datos, como las bases de datos relacionales (como MySQL, PostgreSQL), las bases de datos NoSQL (como MongoDB, Cassandra), etc., proporcionan diferentes funciones y adaptabilidad. Elija el tipo de base de datos adecuado según el modelo de datos de su aplicación y las necesidades de consulta.
-
Rendimiento y escalabilidad
Elija un servicio de datos backend según los requisitos de rendimiento de su aplicación. Considere las métricas de rendimiento de la base de datos (como el rendimiento, la latencia) y su capacidad de escalar.
-
Disponibilidad y confiabilidad
Considere la disponibilidad y la confiabilidad al elegir un servicio de datos backend. Los servicios de bases de datos administradas de los proveedores de la nube generalmente ofrecen alta disponibilidad y capacidades de respaldo automatizadas. Asegúrese de elegir un servicio de datos backend que satisfaga las necesidades de disponibilidad y protección de datos de su aplicación.
3.6 Configuración de alta disponibilidad de equilibrio de carga
El CLB de equilibrio de carga tradicional ha implementado múltiples zonas de disponibilidad en la mayoría de las regiones para lograr la recuperación ante desastres entre salas de máquinas en la misma región. Puede utilizar Service Annoation para especificar las zonas de disponibilidad activa y de respaldo de SLB/CLB. Las zonas de disponibilidad activa y de respaldo deben ser consistentes con las zonas de disponibilidad de ECS en el grupo de nodos, lo que puede reducir el reenvío de datos de zonas de disponibilidad cruzada y mejorar el acceso a la red. actuación.
apiVersion: v1
kind: Service
metadata:
annotations:
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-master-zoneid: "cn-hangzhou-a"
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-slave-zoneid: "cn-hangzhou-b"
name: nginx
namespace: default
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
run: nginx
type: LoadBalancer
Para reducir el tráfico de red de zonas de disponibilidad cruzada y mejorar el rendimiento de la red. Podemos utilizar las sugerencias de topología introducidas en Kubernetes 1.23 para implementar la función de enrutamiento más cercano con reconocimiento de topología.
3.7 Configuración de alta disponibilidad del disco en la nube
Actualmente, los discos en la nube de Alibaba Cloud solo se pueden crear y montar en una única zona de disponibilidad. Para utilizar los discos en la nube como almacenamiento de datos para aplicaciones persistentes en un clúster de zona de disponibilidad múltiple, debe seleccionar el tipo de almacenamiento en disco en la nube que tenga en cuenta la topología alicloud- topología de disco proporcionada por ACK. [6] para crear un PersistentVolumeClaim. El modo de enlace de volumen de esta clase de almacenamiento por defecto es WaitForFirstConsumer y admite el enlace retrasado hasta que se cree PersistentVolumeClaim en la zona de disponibilidad correspondiente. Puede crear una clase de almacenamiento en disco en la nube ESSD más refinada que especifique el conocimiento de la topología de la zona de disponibilidad múltiple para generar volúmenes de almacenamiento. Las aplicaciones de declaración de almacenamiento y persistencia son las siguientes. Para obtener más detalles, consulte el documento [7 ] .
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: alicloud-disk-topology-essd
provisioner: diskplugin.csi.alibabacloud.com
parameters:
type: cloud_essd
fstype: ext4
diskTags: "a:b,b:c"
zoneId: “cn-hangzhou-a,cn-hangzhou-b,cn-hangzhou-c” #指定可用区范围来生成云盘
encrypted: "false"
performanceLevel: PL1 #指定性能类型
volumeExpandAutoSnapshot: "forced" #指定扩容编配的自动备份开关，该设置仅在type为"cloud_essd"时生效。
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Retain
allowVolumeExpansion: true
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: topology-disk-pvc
spec:
accessModes:
- ReadWriteOnce
volumeMode: Filesystem
resources:
requests:
storage: 100Gi
storageClassName: alicloud-disk-topology-essd
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mysql
spec:
serviceName: "mysql"
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- image: mysql:5.6
name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: "mysql"
volumeMounts:
- name: data
mountPath: /var/lib/mysql
volumes:
- name: data
persistentVolumeClaim:
claimName: topology-disk-pvc
3.8 Configuración de alta disponibilidad del nodo virtual
Virtual Node admite que las aplicaciones Kubernetes se implementen en instancias de contenedores elásticos ECI, eliminando la necesidad de operación y mantenimiento de nodos y creándolos bajo demanda, reduciendo el desperdicio de recursos reservados. Al realizar una rápida expansión horizontal del negocio para hacer frente al tráfico repentino, o al lanzar una gran cantidad de instancias para procesar tareas de trabajo, puede encontrar situaciones como un inventario insuficiente de instancias de las especificaciones correspondientes en la zona de disponibilidad o el agotamiento de las IP de conmutador especificadas, lo que resulta en en error de creación de instancia ECI. El uso de la función de zona de disponibilidad múltiple de ACK Serverless puede mejorar la tasa de éxito en la creación de instancias ECI.
Los nodos virtuales se pueden implementar en múltiples aplicaciones AZ configurando vSwitches en diferentes AZ a través del perfil ECI.
- ECI distribuirá las solicitudes para crear Pods a todos los vSwitches para lograr el efecto de distribuir presión.
- Si una solicitud de creación de Pod encuentra una situación en la que no hay inventario en un vSwitch, cambiará automáticamente al siguiente vSwitch y continuará intentando crearlo.
Modifique el campo vswitch en el mapa de configuración de kube-system/eci-profile según las necesidades reales. La modificación entrará en vigor de inmediato.
kubectl -n kube-system edit cm eci-profile
apiVersion: v1
data:
kube-proxy: "true"
privatezone: "true"
quota-cpu: "192000"
quota-memory: 640Ti
quota-pods: "4000"
regionId: cn-hangzhou
resourcegroup: ""
securitygroupId: sg-xxx
vpcId: vpc-xxx
vswitchIds: vsw-xxx,vsw-yyy,vsw-zzz
kind: ConfigMap
El contenido relacionado se puede encontrar en [8].
3.9 Configuración de alarma de monitoreo
A través de los indicadores revelados por el propio K8 y componentes como kube-state-metrics, se puede monitorear de manera efectiva la alta disponibilidad de recursos como Pods y Nodos y la distribución de zonas disponibles, lo cual es de gran importancia para descubrir y localizar problemas rápidamente. En el entorno de producción, el sistema de monitoreo y alarma se construye continuamente y se actualiza iterativamente de acuerdo con la versión K8 y las actualizaciones de la versión de los componentes. Se recomienda continuar prestando atención a los nuevos indicadores e introducirlos en el sistema de monitoreo y alarma de acuerdo con los escenarios comerciales. A continuación se enumeran dos configuraciones de alarma para alta disponibilidad de recursos como referencia.
3.9.1 Monitoreo de alarma de que la copia de carga de la aplicación no está disponible
Las métricas de estado de kube de K8s pueden agregar y analizar el número de copias no disponibles, el número total de copias, etc. de la carga de la aplicación Despliegue/Statefulset/Daemonset. Con base en este tipo de indicadores, puede encontrar si hay copias no disponibles en la aplicación. y el porcentaje de copias no disponibles sobre el total de copias Realizar seguimiento y alarmas de los servicios parcial o totalmente afectados.
Tomando la implementación como ejemplo, los ejemplos de alarma de AlertManager/Thanos Ruler son los siguientes:
# kube-system或者monitoring中的Deployment存在不可用副本，持续1m，则触发告警，告警serverity配置为L1
- alert: SystemPodReplicasUnavailable
expr: kube_deployment_status_replicas_unavailable{namespace=~"kube-system|monitoring",deployment!~"ack-stub|kubernetes-kdm"} > 0
labels:
severity: L1
annotations:
summary: "namespace={{$labels.namespace}}, deployment={{$labels.deployment}}: Deployment存在不可用Replica"
for: 1m
# kube-system或者monitoring中的Deployment副本总数>0，且全部副本不可用，持续1m，则触发告警，告警serverity配置为L1
- alert: SystemAllPodReplicasUnavailable
expr: kube_deployment_status_replicas_unavailable{namespace=~"kube-system|monitoring"} == kube_deployment_status_replicas{namespace=~"kube-system|monitoring"} and kube_deployment_status_replicas{namespace=~"kube-system|monitoring"} > 0
labels:
severity: L1
annotations:
summary: "namespace={{$labels.namespace}}, deployment={{$labels.deployment}}: Deployment全部Replicas不可用"
for: 1m
3.9.2 Monitoreo de alarmas sobre el porcentaje de nodos en mal estado en la zona de disponibilidad del clúster
El componente kube-controller-manager de K8s cuenta la cantidad de nodos en mal estado, el porcentaje de nodos en buen estado y la cantidad total de nodos en la zona de disponibilidad, y puede configurar alarmas relacionadas.
# HELP node_collector_unhealthy_nodes_in_zone [ALPHA] Gauge measuring number of not Ready Nodes per zones.
# TYPE node_collector_unhealthy_nodes_in_zone gauge
node_collector_unhealthy_nodes_in_zone{zone="cn-shanghai::cn-shanghai-e"} 0
node_collector_unhealthy_nodes_in_zone{zone="cn-shanghai::cn-shanghai-g"} 0
node_collector_unhealthy_nodes_in_zone{zone="cn-shanghai::cn-shanghai-l"} 0
node_collector_unhealthy_nodes_in_zone{zone="cn-shanghai::cn-shanghai-m"} 0
node_collector_unhealthy_nodes_in_zone{zone="cn-shanghai::cn-shanghai-n"} 0
# HELP node_collector_zone_health [ALPHA] Gauge measuring percentage of healthy nodes per zone.
# TYPE node_collector_zone_health gauge
node_collector_zone_health{zone="cn-shanghai::cn-shanghai-e"} 100
node_collector_zone_health{zone="cn-shanghai::cn-shanghai-g"} 100
node_collector_zone_health{zone="cn-shanghai::cn-shanghai-l"} 100
node_collector_zone_health{zone="cn-shanghai::cn-shanghai-m"} 100
node_collector_zone_health{zone="cn-shanghai::cn-shanghai-n"} 100
# HELP node_collector_zone_size [ALPHA] Gauge measuring number of registered Nodes per zones.
# TYPE node_collector_zone_size gauge
node_collector_zone_size{zone="cn-shanghai::cn-shanghai-e"} 21
node_collector_zone_size{zone="cn-shanghai::cn-shanghai-g"} 21
node_collector_zone_size{zone="cn-shanghai::cn-shanghai-l"} 21
node_collector_zone_size{zone="cn-shanghai::cn-shanghai-m"} 21
node_collector_zone_size{zone="cn-shanghai::cn-shanghai-n"} 21
Los ejemplos de alarma de AlertManager/Thanos Ruler son los siguientes:
# node_collector_zone_health <= 80 如果可用区内健康节点比例小于80%，就触发告警。
- alert: HealthyNodePercentagePerZoneLessThan80
expr: node_collector_zone_health <= 80
labels:
severity: L1
annotations:
summary: "zone={{$labels.zone}}: 可用区内健康节点与节点总数百分比 <= 80%"
for: 5m
Arquitectura de alta disponibilidad de clúster único o múltiple para aplicaciones
Con base en la tecnología de alta disponibilidad presentada en el Capítulo 3 anterior y las capacidades del producto proporcionadas por las capacidades del producto de Alibaba Cloud, se puede implementar completamente una arquitectura de alta disponibilidad dentro de un solo clúster. La arquitectura de alta disponibilidad de múltiples clústeres es una arquitectura de alta disponibilidad que se actualiza aún más en la arquitectura de alta disponibilidad de un solo clúster, proporcionando capacidades de servicio de alta disponibilidad en todos los clústeres/regiones.
A través de la implementación multirregional y multiclúster y la arquitectura de aplicaciones unificadas, se pueden superar los desafíos del retraso, el costo y la tasa de fallas de la transmisión de la red entre regiones, garantizando al mismo tiempo una alta disponibilidad. Esto puede proporcionar a los usuarios una mejor experiencia de usuario y al mismo tiempo garantizar la estabilidad y confiabilidad del negocio.
4.1 Clúster de alta disponibilidad de zona de disponibilidad múltiple y región única
Con base en la tecnología de alta disponibilidad presentada en el Capítulo 3 anterior y las capacidades proporcionadas por los productos Alibaba Cloud, se puede implementar una arquitectura de alta disponibilidad dentro de una única dimensión de clúster, que no se describirá nuevamente aquí.
4.2 Alta disponibilidad de múltiples clústeres de una sola región + alta disponibilidad de múltiples clústeres de múltiples regiones
Primero, cada clúster ACK adopta una arquitectura de alta disponibilidad de zona de disponibilidad múltiple, y las aplicaciones comerciales adoptan un modo de implementación de zona de disponibilidad múltiple para proporcionar servicios externos a través de SLB.
La implementación multirregional y la implementación multi-AZ son similares en naturaleza, pero debido a las diferencias en los retrasos en la transmisión de la red, los costos y las tasas de falla entre regiones, se requieren diferentes arquitecturas de implementación y aplicaciones para adaptarse. Para la capa de plataforma, no se recomienda implementar clústeres de Kubernetes interregionales, sino adoptar un enfoque de múltiples clústeres multirregionales y combinarlo con una arquitectura de aplicación unificada para lograr una arquitectura multirregional de alta disponibilidad. . Implemente varios clústeres de Kubernetes independientes en diferentes regiones y cada clúster administre sus propios nodos y aplicaciones. El clúster de cada región es independiente y tiene su propio nodo maestro y nodo trabajador. Esto puede reducir los retrasos y las tasas de fallas de la red entre regiones y mejorar la disponibilidad y el rendimiento de las aplicaciones.
Al mismo tiempo, se adopta una arquitectura de aplicación unificada para dividir la aplicación en unidades independientes, y cada unidad implementa copias en clústeres en múltiples regiones. A través de la tecnología de equilibrio de carga y resolución DNS, las solicitudes de los usuarios se pueden enrutar a la ubicación más cercana, el tráfico se puede distribuir a la región más cercana, se puede reducir la latencia de la red y se pueden proporcionar capacidades de alta disponibilidad y recuperación ante desastres.
Si el clúster ACK entre regiones requiere interconexión de red, la interconexión entre VPC de múltiples regiones se puede lograr a través de Cloud Enterprise Network (CEN). La programación del tráfico empresarial interregional se implementa a través de la gestión del tráfico global GTM y los servicios de análisis de la nube.
Si desea realizar una gestión unificada de múltiples clústeres en múltiples regiones, como observabilidad, políticas de seguridad y entrega unificada de aplicaciones entre clústeres. Podemos usar ACK One para lograr esto. Distributed Cloud Container Platform ACK One (Distributed Cloud Container Platform for Kubernetes) es una plataforma nativa de la nube de nivel empresarial lanzada por Alibaba Cloud para nube híbrida, múltiples clústeres, computación distribuida, recuperación ante desastres y otros escenarios. ACK One puede conectar y administrar los clústeres de Kubernetes de los usuarios en cualquier región y en cualquier infraestructura, y proporciona administración consistente y API compatibles con la comunidad para respaldar la informática, la red, el almacenamiento, la seguridad, el monitoreo, los registros, los trabajos, las aplicaciones, el tráfico, etc. llevar a cabo una gestión y control unificados de operación y mantenimiento. Si desea saber más sobre ACK One, no dude en unirse al grupo con el número de grupo de búsqueda de DingTalk: 35688562 .
ACK One crea una solución de recuperación ante desastres para sistemas de aplicaciones en dos lugares y tres centros. Para contenido relacionado, consulte [9].
Resumen del enlace
La arquitectura de alta disponibilidad y el diseño de aplicaciones en escenarios nativos de la nube son cruciales para la disponibilidad, estabilidad y seguridad de los servicios empresariales: pueden mejorar eficazmente la disponibilidad de las aplicaciones y la experiencia del usuario, y proporcionar aislamiento y tolerancia a fallas. Este artículo presenta los principios clave del diseño de arquitectura de alta disponibilidad para aplicaciones nativas de la nube, la tecnología de alta disponibilidad de K8, su uso e implementación en escenarios ACK y el uso de arquitectura de alta disponibilidad de un solo clúster y de múltiples clústeres. Para proporcionar referencia y ayuda a las empresas con necesidades relacionadas, ACK continuará brindando a los clientes productos y servicios nativos de la nube que sean seguros, estables, con rendimiento, optimizados en costos y actualizados continuamente.
Este artículo se refiere al maravilloso intercambio del jefe de Alibaba Cloud Container Service, Yi Li, sobre el análisis de la arquitectura de alta disponibilidad ACK. ¡Me gustaría expresar mi más sincero agradecimiento!
Enlaces relacionados:
[2] https://kubernetes.io/blog/2020/05/introduciendo-podtopologyspread/
[5] https://help.aliyun.com/document_detail/184995.html
[8] https://help.aliyun.com/zh/ack/serverless-kubernetes/user-guide/create-ecis-across-zones
[9] https://developer.aliyun.com/article/913027
Se lanza oficialmente Qt 6.6. La ventana emergente en la página de lotería de la aplicación Gome insulta a su fundador . Se lanza oficialmente Ubuntu 23.10. ¡También puedes aprovechar el viernes para actualizar! RISC-V: no controlado por ninguna empresa o país. Episodio de lanzamiento de Ubuntu 23.10: la imagen ISO fue "retirada" urgentemente debido a que contenía discurso de odio. Las empresas rusas producen computadoras y servidores basados en procesadores Loongson. ChromeOS es una distribución de Linux que utiliza Google Desktop Medio ambiente: estudiante de doctorado de 23 años corrige un "error fantasma" de 22 años en Firefox Lanzamiento de TiDB 7.4: oficialmente compatible con MySQL 8.0 Microsoft lanza la versión Windows Terminal Canary