Fuente ｜ Comunidad de código abierto KubeAdmiral
Dirección del proyecto: https://github.com/kubewharf/kubeadmiral
Desde que fue de código abierto en 2014, Kubernetes se ha convertido en el estándar de facto para sistemas de orquestación y programación, brindando a los desarrolladores una gran comodidad. A medida que más y más empresas adoptan la nube nativa, la escala de la infraestructura de la nube global aún se está acelerando. El clúster único de 5000 nodos de la versión comunitaria de Kubernetes ya no puede cumplir con escenarios de aplicaciones a gran escala a nivel empresarial. Cada vez más empresas optan por utilizar la arquitectura de múltiples nubes para satisfacer sus necesidades. Con las demandas de reducción de costos y mejora de la eficiencia, recuperación remota de desastres y aislamiento ambiental, la necesidad de una gestión de múltiples clústeres se vuelve cada vez más evidente.
fondo
Con el rápido desarrollo del negocio, el número de clústeres de Kubernetes dentro de ByteDance también ha seguido creciendo. El número de clústeres supera los 500 y el número de copias de aplicaciones oscila entre 0 y 20.000. La aplicación más grande supera los 100 W de núcleo.
Al principio, debido a consideraciones de aislamiento y seguridad, cada línea de negocio de Byte tenía grupos exclusivos. Estos grupos exclusivos provocaron islas de recursos, lo que en última instancia afectó la eficiencia elástica de los recursos. Esto se refleja, en primer lugar, en la necesidad de mantener reservas independientes para cada línea de negocio; en segundo lugar, la empresa está profundamente ligada al clúster, la empresa conoce una gran cantidad de clústeres y también asigna recursos a la aplicación entre los clústeres. Necesita estar profundamente consciente del negocio y los clústeres en términos de recursos operativos, lo que en última instancia conduce a una lenta rotación de recursos entre varias líneas de negocios, baja eficiencia de automatización y tasas de implementación subóptimas. Por lo tanto, necesitamos introducir la federación, desacoplar la relación vinculante entre aplicaciones y clústeres, agrupar los recursos de cada línea de negocio, reducir los buffers y mejorar la eficiencia de la automatización de los recursos.
A medida que las nubes múltiples y las nubes híbridas se vuelven cada vez más comunes en la industria, y Kubernetes se convierte en un sistema operativo nativo de la nube, varias infraestructuras se abstraen y estandarizan aún más para proporcionar interfaces estándar más unificadas para las aplicaciones. Sobre esta base, esperamos introducir la federación como la base del sistema nativo de la nube en escenarios de nube distribuida, proporcionar una entrada de plataforma unificada para las aplicaciones, mejorar la capacidad de distribuir aplicaciones entre clústeres y hacer un buen trabajo en la distribución y programación de aplicaciones entre clústeres y gestionar múltiples nubes en escenarios nativos.
Implementación de bytes de KubeFed V2
Ante los desafíos que plantea la gestión de múltiples clústeres, el equipo de infraestructura comenzó la construcción de una federación de clústeres basada en la comunidad KubeFed V2 en 2019. KubeFed V2 distingue entre clústeres maestros y clústeres miembros. Los usuarios crean "objetos de federación" en el clúster maestro y varios controladores KubeFed distribuyen recursos entre los clústeres miembros en función de los objetos de federación. Hay tres campos en el objeto federado: Plantilla (plantilla de objeto), Ubicación (clúster de destino) y Anulaciones (diferenciación de clúster) para declarar el estado de implementación del objeto. Por ejemplo, puede crear una implementación federada como se muestra a continuación en el clúster maestro para la distribución de la implementación:
apiVersion: types.kubefed.k8s.io/v1beta1
kind: FederatedDeployment
metadata:
name: test-deployment
namespace: test-namespace
spec:
template: # 定义 Deployment 的所有內容，可理解成 Deployment 与 Pod template 之间的关联。
metadata:
labels:
app: nginx
spec:
...
placement:
# 分发到指定的两个集群中
clusters:
- name: cluster1
- name: cluster2
overrides:
# 在cluster2中修改副本数为5
- clusterName: cluster2
clusterOverrides:
- path: spec.replicas
value: 5
Para implementaciones y ReplicaSets, KubeFed también permite especificar estrategias de distribución de réplicas más avanzadas a través de ReplicaSchedulingPreference (RSP). Los usuarios pueden configurar el peso, el número mínimo y máximo de réplicas de cada clúster en RSP, y el controlador RSP calcula automáticamente la ubicación y anula los campos y actualiza FederatedDeployment o FederatedReplicaSet.
Fuente de la imagen: https://www.kubernetes.org.cn/5702.html
Sin embargo, durante la implementación, descubrimos que KubeFed no podía cumplir con los requisitos del entorno de producción:
- Baja utilización de recursos: la política de programación de réplicas RSP de KubeFed solo puede establecer pesos estáticos para cada clúster miembro y no puede responder de manera flexible a los cambios en los recursos del clúster, lo que resulta en niveles de implementación desiguales de diferentes clústeres miembros.
- Los cambios no son lo suficientemente fluidos: a menudo se produce una distribución desigual de las instancias al ampliar o reducir la escala, lo que da como resultado capacidades reducidas de recuperación ante desastres.
- Limitaciones semánticas de programación: solo un buen soporte para recursos sin estado, soporte insuficiente para recursos diversos, como servicios y trabajos con estado, y escalabilidad de programación deficiente.
- El costo de acceso es alto: debe distribuirse mediante la creación de objetos federados, no es compatible con las API nativas y los usuarios y la plataforma superior deben cambiar completamente sus hábitos de uso.
Con la evolución de la infraestructura de Bytedance, hemos planteado mayores requisitos de eficiencia, escala, rendimiento y costo al mismo tiempo, a medida que escenarios comerciales como servicios con estado, almacenamiento, operaciones fuera de línea y aprendizaje automático adoptan aún más el soporte nativo de la nube; Las capacidades de orquestación y programación entre clústeres en escenarios especializados se han vuelto cada vez más importantes. Por lo tanto, desarrollamos un sistema de federación de clústeres de nueva generación, KubeAdmiral, basado en KubeFed v2 a finales de 2021.
Evolución de la arquitectura KubeAdmiral
El nombre KubeAdmiral se deriva de almirante (pronunciado [ˈædm(ə)rəl]), que originalmente significa comandante de flota. La adición del prefijo Kube(rnetes) significa que la herramienta tiene poderosas capacidades de programación y orquestación de múltiples clústeres de Kubernetes.
KubeAdmiral admite la API nativa de Kubernetes, proporciona un marco de programación rico y escalable y pule cuidadosamente el algoritmo de programación y el proceso de distribución. Algunas características notables se describen en detalle a continuación:
1. Ricas capacidades de programación de múltiples clústeres
El programador es el componente central del sistema federado. Es responsable de asignar recursos a los clústeres miembros. En el escenario de programación de réplicas, también es responsable de calcular las réplicas que cada clúster merece. Su lógica de programación afecta directamente la recuperación ante desastres de múltiples clústeres federados. , eficiencia de recursos, características importantes como la estabilidad.
KubeFed proporciona el programador RSP para la programación de réplicas, pero su personalización y escalabilidad son muy limitadas y su abstracción lógica es insuficiente para cambiar su comportamiento, y debe completarse modificando el código. Al mismo tiempo, carece de soporte para servicios con estado. , recursos laborales, etc.
KubeAdmiral presenta una semántica de programación más rica, admite una selección de clústeres más flexible a través de etiquetas, manchas, etc., proporciona capacidades de programación de recursos de tipo trabajo con estado e introduce optimizaciones como la programación de seguimiento de dependencias. La semántica de la programación se puede configurar a través del objeto PropagationPolicy como se muestra a continuación:
apiVersion: core.kubeadmiral.io/v1alpha1
kind: PropagationPolicy
metadata:
name: mypolicy
namespace: default
spec:
# 提供多种集群选择方式，最终结果取交集
placement: # 手动指定集群与权重
- cluster: Cluster-01
preferences:
weight: 40
- cluster: Cluster-02
preferences:
weight: 30
- cluster: Cluster-03
preferences:
weight: 40
clusterSelector: # 类似Pod.Spec.NodeSelector，通过label过滤集群
IPv6: "true"
clusterAffinity: # 类似Pod.Spec.NodeAffinity，通过label过滤集群，语法比clusterSelector更加灵活
- matchExpressions:
- key: region
operator: In
values:
- beijing
tolerations: # 通过污点过滤集群
- key: "key1"
operator: "Equal"
value: "value1"
effect: "NoSchedule"
schedulingMode: Divide # 是否为副本数调度
stickyCluster: false # 仅在首次调度，适合有状态服务或作业类服务
maxClusters: 1 # 最多可分发到多少个子集群，适合有状态服务或作业类服务
disableFollowerScheduling: false # 是否开启依赖调度
Al mismo tiempo, para los recursos programados para diferentes clústeres, OverridePolicy se puede utilizar para diferenciarlos según los nombres o etiquetas de los clústeres:
apiVersion: core.kubeadmiral.io/v1alpha1
kind: OverridePolicy
metadata:
name: example
namespace: default
spec:
# 最终匹配的集群是所有rule匹配集群的交集
overrideRules:
- targetClusters:
# 通过名称匹配集群
clusters:
- member1
- member2
# 通过标签selector匹配集群
clusterSelector:
region: beijing
az: zone1
# 通过基于标签的affinity匹配集群
clusterAffinity:
- matchExpressions:
- key: region
operator: In
values:
- beijing
- key: provider
operator: In
values:
- volcengine
# 在匹配的集群中，使用jsonpatch语法修改第一个容器的镜像
overriders:
jsonpatch:
- path: "/spec/template/spec/containers/0/image"
operator: replace
value: "nginx:test"
2. Las capacidades de programación se pueden ampliar
KubeAdmiral se refiere al diseño de kube-scheduler y proporciona un marco de programación extensible. Resume la lógica de programación en cuatro pasos: filtrar, calificar, seleccionar y replicar, y utiliza múltiples complementos relativamente independientes para implementar su lógica en cada paso. Casi todos los campos de PropagaionPolicy que se muestran en la figura anterior se implementan mediante un complemento de programación integrado independiente. Los complementos no interfieren entre sí y el programador llama a los complementos necesarios para la orquestación global.
Además, el programador KubeAdmiral también admite la interacción con complementos externos a través del protocolo http. Los usuarios pueden escribir e implementar una lógica de programación personalizada para satisfacer las necesidades de acceso al sistema interno de la empresa para la programación. El complemento integrado implementa capacidades más generales y complementa el complemento externo. Los usuarios pueden expandir la lógica de programación a un costo mínimo y sin cambiar el plano de control de la federación, y confiar en la poderosa capacidad de distribución de múltiples clústeres de KubeAdmiral para realizar la programación. resultados efectivos.
3. Migración automática si falla la programación de la aplicación
Para los recursos programados por réplicas, KubeAdmiral calculará cuántas réplicas merece cada clúster miembro, sobrescribirá la cantidad de campos de réplicas y luego las entregará a cada clúster miembro. Este proceso se denomina programación federada después de que se entreguen los recursos, el kube de cada clúster miembro. El programador asignará el pod correspondiente al recurso al nodo correspondiente. Este proceso se convierte en programación de un solo clúster.
Una vez que se emiten los recursos, la programación de un solo clúster a veces puede fallar debido a que el nodo está fuera de línea, recursos insuficientes, afinidad de nodo insatisfecha, etc. Si no se maneja, las instancias comerciales disponibles serán menores de lo esperado. KubeAdmiral proporciona la función de migración automática cuando falla la programación. Cuando está habilitado, puede identificar réplicas no programables en clústeres miembros y migrarlas a clústeres que puedan acomodar réplicas redundantes, logrando una rotación de recursos de múltiples clústeres.
Por ejemplo, a tres grupos A, B y C se les asignan 6 copias con el mismo peso. Después de la programación de federación inicial, a cada grupo se le asignarán 2 copias. Si dos copias en el clúster C no se pueden programar en un solo clúster, KubeAdmiral las migrará automáticamente a A y B.
| grupo | A | B | C |
|---|---|---|---|
| Pesos | 1 | 1 | 1 |
| Número de instancias iniciales de programación federada | 2 | 2 | 2 |
| Réplicas que no se pueden programar en un solo clúster | 0 | 0 | 2 |
| Número de instancias de programación federada después de la migración automática | 3 | 3 | 0 |
4. Programe recursos dinámicamente según los niveles de agua del grupo
En un entorno de múltiples clústeres, los niveles de recursos de cada clúster cambian dinámicamente a medida que las máquinas se conectan y desconectan. Depender únicamente de las réplicas de programación de peso estáticas proporcionadas por KubeFed RSP puede provocar fácilmente niveles desiguales de agua en los clústeres. Es propenso a sufrir problemas durante las actualizaciones del servicio. Los pods parecen estar pendientes durante mucho tiempo y los recursos del clúster con una tasa de implementación baja no se pueden utilizar por completo. En este sentido, KubeAdmiral introduce una programación de peso dinámica basada en el nivel de agua del clúster. Calcula la cantidad disponible recopilando la cantidad total de recursos y el uso de cada clúster, y utiliza la cantidad de recursos disponibles como el peso de la programación de copias, logrando finalmente el equilibrio de carga. cada grupo de miembros. Y la tasa de implementación de todos los grupos de miembros se mantiene por encima del 95%.
5. Mejora del algoritmo de asignación de copias.
El algoritmo de asignación de copias de KubeFed a menudo hace que la cantidad de instancias se desvíe de las expectativas al aumentar o reducir, por ejemplo:
Se distribuyen 30 instancias en tres grupos de miembros A, B y C. En el caso de rsp.rebalance = false, el usuario desea reducir la escala a 15 instancias:
Antes de encogerse:
| grupo | A | B | C |
|---|---|---|---|
| Pesos | 10 | 10 | 10 |
| Número de instancias | 15 | 15 | 0 |
Después de encogerse:
| grupo | A | B | C |
|---|---|---|---|
| Pesos | 10 | 10 | 10 |
| Número de instancias | 15 | 0 | 0 |
La razón de este fenómeno es que el algoritmo de réplica de KubeFed primero preasigna el número de instancias existentes actualmente en el clúster y luego asigna las instancias restantes de acuerdo con el peso de cada clúster. Si hay demasiadas réplicas en el clúster actual. will Esto conduce a una desviación grave entre la distribución de instancias y el peso.
KubeAdmiral optimiza el algoritmo de copia de KubeFed para hacer que la distribución final sea lo más cercana posible a una distribución de peso y, al mismo tiempo, garantiza que no se produzca ninguna migración inesperada durante la expansión y contracción. Tomando como ejemplo la escala de 30 instancias a 15, el proceso del algoritmo simplificado es el siguiente:
- distribución actual = [15, 15, 0], réplicas totales: 30
- distribución deseada = [5, 5, 5], réplicas totales: 15
- distancia = deseada - actual = [-10, -10, 5], distancia total: 15
- Para escenarios de reducción, elimine el término positivo distancia = [-10, -10, 0]
- Usando la distancia como peso, redistribuya la diferencia 15: [-7, -8, 0]
- Resultado final de la programación: [-7, -8, 0] + [15, 15, 0] -> [8, 7, 0]
| grupo | A | B | C |
|---|---|---|---|
| Pesos | 10 | 10 | 10 |
| Número de instancias | 8 | 7 | 0 |
6. Apoye los recursos nativos
A diferencia de KubeFed, que requiere que los usuarios utilicen una nueva API completamente incompatible, KubeAdmiral se adapta a los hábitos de uso de los usuarios de un solo clúster de Kubernetes y brinda soporte para las API nativas de Kubernetes. Después de que los usuarios crean recursos nativos (como la implementación), Federate Controller los convierte automáticamente en objetos internos federados para que los utilicen otros controladores. Los usuarios pueden migrar rápidamente de un solo clúster a una arquitectura de múltiples clústeres y disfrutar de la conveniencia de múltiples clústeres con una. umbral bajo.
KubeAdmiral no se detiene ahí. En un solo clúster, el controlador nativo de Kubernetes actualizará el estado de algunos recursos para reflejar su estado actual. Los usuarios o los sistemas de capa superior a menudo dependen del estado para ver información como el estado de implementación y el estado de salud. En varios clústeres, el estado de los recursos está disperso en varios clústeres. Para ver el estado global, los usuarios deben ver el estado de los recursos en cada clúster uno por uno, lo que provoca problemas como vistas fragmentadas y baja eficiencia de operación y mantenimiento. Para resolver este problema y admitir sin problemas los recursos nativos, KubeAdmiral proporciona capacidades de agregación de estado. Status Aggregator fusiona e integra el estado de los recursos en múltiples grupos de miembros y los vuelve a escribir en recursos nativos, de modo que los usuarios no necesitan estar al tanto de múltiples. -Topología de clúster. El estado de los recursos en toda la federación se puede observar de un vistazo.
presente y futuro
KubeAdmiral ha estado incubado dentro de Byte durante muchos años. Respalda firmemente la plataforma comercial TCE de Byte Group y administra más de 210,000 máquinas y más de 10 millones de pods. Ha sido pulido por empresas a gran escala como Douyin y Toutiao, y ha acumulado mucho valor. experiencia práctica. . Para poder retribuir a la comunidad, KubeAdmiral se ha abierto oficialmente en GitHub. Al mismo tiempo, Volcano Engine está construyendo un nuevo modelo de gestión de múltiples nubes y clústeres a nivel empresarial basado en KubeAdmiral, la plataforma nativa de nube distribuida (DCP), así que estad atentos.
De cara al futuro, tenemos previsto seguir evolucionando en los siguientes aspectos:
- Continuar mejorando las capacidades de orquestación y programación de recursos con estado, de tipo de trabajo y de otro tipo, y desarrollar capacidades avanzadas como la migración automática y la programación de comparación de precios para abrazar el advenimiento de la era de la computación por lotes de múltiples nubes y múltiples clústeres.
- Mejore la experiencia del usuario y proporcione soluciones listas para usar para reducir aún más la carga cognitiva de los usuarios.
- Mejore la observabilidad, optimice los indicadores de registro y monitoreo y mejore la interpretabilidad del programador.
- Explore funciones como la federación con un solo clic y la migración de múltiples clústeres para liberar completamente el potencial de la arquitectura de múltiples clústeres.
La orquestación y programación de múltiples clústeres no son simples por naturaleza. Un sistema federado de múltiples clústeres universal y completo debe pulirse en varios escenarios. Esperamos que más amigos presten atención y se unan a la comunidad de KubeAdmiral. También invitamos a todos a probar KubeAdmiral. ¡Y bríndenos varias sugerencias!
GitHub: https://github.com/kubewharf/kubeadmiral
¡Compañero pollo deepin-IDE de "código abierto" y finalmente logró el arranque! Buen chico, Tencent realmente ha convertido Switch en una "máquina de aprendizaje pensante" Revisión de fallas de Tencent Cloud del 8 de abril y explicación de la situación Reconstrucción de inicio de escritorio remoto de RustDesk Cliente web Base de datos de terminal de código abierto WeChat basada en SQLite WCDB marcó el comienzo de una actualización importante Lista de abril de TIOBE: PHP cayó a un mínimo histórico, Fabrice Bellard, el padre de FFmpeg, lanzó la herramienta de compresión de audio TSAC , Google lanzó un modelo de código grande, CodeGemma , ¿te va a matar? Es tan bueno que es de código abierto: herramienta de edición de carteles e imágenes de código abierto