Fonte｜Comunidade de código aberto KubeAdmiral
Endereço do projeto: https://github.com/kubewharf/kubeadmiral
Desde que foi open source em 2014, o Kubernetes se tornou o padrão de fato para sistemas de orquestração e agendamento, proporcionando grande conveniência aos desenvolvedores. À medida que mais e mais empresas adotam a nuvem nativa, a escala da infraestrutura global em nuvem ainda está acelerando. O cluster único de 5.000 nós da versão da comunidade Kubernetes não é mais capaz de atender a cenários de aplicativos de grande escala em nível empresarial. mais empresas estão optando por usar a arquitetura multinuvem para atender às suas necessidades. Com as demandas de redução de custos e melhoria da eficiência, recuperação remota de desastres e isolamento ambiental, a necessidade do gerenciamento multicluster está se tornando cada vez mais aparente.
fundo
Com o rápido desenvolvimento dos negócios, o número de clusters Kubernetes dentro do ByteDance também continuou a crescer. O número de clusters excede 500 e o número de cópias de aplicativos varia de 0 a 20.000. O maior aplicativo excede 100W de núcleo.
No início, devido a considerações de isolamento e segurança, cada linha de negócios da Byte tinha clusters exclusivos. Esses clusters exclusivos causavam ilhas de recursos, o que, em última análise, afetava a eficiência elástica dos recursos. Isto se reflete, em primeiro lugar, na necessidade de manter buffers independentes para cada linha de negócios; em segundo lugar, a empresa está profundamente ligada ao cluster, a empresa está ciente de um grande número de clusters e também aloca recursos para a aplicação entre os clusters. precisa estar profundamente consciente dos negócios e dos clusters em termos de recursos operacionais, o que acaba levando a uma rotatividade lenta de recursos entre várias linhas de negócios, baixa eficiência de automação e taxas de implantação abaixo do ideal. Portanto, precisamos introduzir a federação, dissociar a relação vinculativa entre aplicações e clusters, agrupar os recursos de cada linha de negócios, reduzir os buffers e melhorar a eficiência da automação dos recursos.
À medida que a multinuvem e a nuvem híbrida se tornam cada vez mais formas convencionais na indústria, e o Kubernetes se torna um sistema operacional nativo da nuvem, várias infraestruturas são ainda mais abstraídas e padronizadas para fornecer interfaces padrão mais unificadas para aplicativos. Nesta base, esperamos introduzir a federação como a base do sistema nativo da nuvem em cenários de nuvem distribuída, fornecer uma entrada de plataforma unificada para aplicações, melhorar a capacidade de distribuição de aplicações entre clusters, fazer um bom trabalho na distribuição e agendamento de aplicações em todos os clusters. clusters e gerenciar múltiplas nuvens em cenários nativos.
Implementação de bytes KubeFed V2
Diante dos desafios trazidos pelo gerenciamento de multiclusters, a equipe de infraestrutura iniciou a construção da federação de clusters baseada na comunidade KubeFed V2 em 2019. KubeFed V2 distingue entre clusters mestres e clusters membros. Os usuários criam "objetos de federação" no cluster mestre e vários controladores KubeFed distribuem recursos entre clusters membros com base em objetos de federação. Existem três campos no objeto federado: Template (modelo de objeto), Placement (cluster de destino) e Overrides (diferenciação de cluster) para declarar o status de implementação do objeto. Por exemplo, você pode criar um FederatedDeployment conforme mostrado abaixo no cluster mestre para distribuição de implantação:
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 implantações e ReplicaSets, o KubeFed também permite especificar estratégias de distribuição de réplicas mais avançadas por meio de ReplicaSchedulingPreference (RSP). Os usuários podem configurar o peso, o número mínimo e máximo de réplicas de cada cluster no RSP, e o controlador RSP calcula automaticamente o posicionamento e substitui campos e atualiza FederatedDeployment ou FederatedReplicaSet.
Fonte da imagem: https://www.kubernetes.org.cn/5702.html
No entanto, durante a implementação, descobrimos que o KubeFed não conseguia atender aos requisitos do ambiente de produção:
- Baixa utilização de recursos - A política de agendamento de réplicas RSP do KubeFed só pode definir pesos estáticos para cada cluster membro e não pode responder com flexibilidade às mudanças nos recursos do cluster, resultando em níveis de implantação desiguais de diferentes clusters membros.
- As mudanças não são suaves o suficiente – a distribuição desigual de instâncias geralmente ocorre durante o aumento ou redução, resultando na redução dos recursos de recuperação de desastres.
- Limitações semânticas de agendamento – apenas bom suporte para recursos sem estado, suporte insuficiente para diversos recursos, como serviços e empregos com estado, e escalabilidade de agendamento deficiente.
- O custo de acesso é alto – precisa ser distribuído por meio da criação de objetos federados, não é compatível com APIs nativas e os usuários e a plataforma superior precisam mudar completamente seus hábitos de uso.
Com a evolução da infraestrutura da Bytedance, apresentamos requisitos mais elevados de eficiência, escala, desempenho e custo ao mesmo tempo, à medida que cenários de negócios como serviços com estado, armazenamento, operações offline e aprendizado de máquina adotam ainda mais o nativo da nuvem e suportam diversos; Os recursos de orquestração e agendamento entre clusters em cenários especializados tornaram-se cada vez mais importantes. Portanto, desenvolvemos um sistema de federação de cluster de nova geração KubeAdmiral baseado em KubeFed v2 no final de 2021.
Evolução da arquitetura KubeAdmiral
O nome KubeAdmiral é derivado de almirante (pronuncia-se [ˈædm(ə)rəl]), que originalmente significa comandante de frota. A adição do prefixo Kube(rnetes) significa que a ferramenta possui poderosos recursos de orquestração e agendamento de vários clusters do Kubernetes.
KubeAdmiral oferece suporte à API nativa do Kubernetes, fornece uma estrutura de agendamento rica e escalonável e aprimora cuidadosamente o algoritmo de agendamento e o processo de distribuição. Alguns recursos notáveis são descritos em detalhes abaixo:
1. Recursos avançados de agendamento de vários clusters
O agendador é o componente principal do sistema federado. Ele é responsável por alocar recursos aos clusters membros. No cenário de agendamento de réplicas, ele também é responsável por calcular as réplicas que cada cluster merece. , eficiência de recursos, características importantes como estabilidade.
KubeFed fornece o agendador RSP para agendamento de réplicas, mas sua customização e escalabilidade são muito limitadas e sua abstração lógica é insuficiente. Para alterar seu comportamento, ele deve ser concluído modificando o código. , recursos de trabalho, etc.
KubeAdmiral introduz uma semântica de agendamento mais rica, oferece suporte à seleção de cluster mais flexível por meio de rótulos, manchas, etc., fornece recursos de agendamento de recursos de tipo de trabalho com estado e introduz otimizações, como agendamento de acompanhamento de dependência. A semântica do agendamento pode ser configurada através do objeto PropagationPolicy conforme mostrado abaixo:
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 # 是否开启依赖调度
Ao mesmo tempo, para recursos programados para clusters diferentes, OverridePolicy pode ser usado para diferenciar com base em nomes ou rótulos de cluster:
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. Os recursos de agendamento podem ser expandidos
KubeAdmiral refere-se ao design do kube-scheduler e fornece uma estrutura de agendamento extensível. Ele abstrai a lógica de agendamento em quatro etapas: Filtrar, Pontuar, Selecionar e Réplica, e usa vários plug-ins relativamente independentes para implementar sua lógica em cada etapa. Quase todos os campos da PropagionPolicy mostrados na figura acima são implementados por um plug-in de agendamento integrado independente. Os plug-ins não interferem entre si e o agendador chama os plug-ins necessários para orquestração global.
Além disso, o agendador KubeAdmiral também suporta interação com plug-ins externos por meio do protocolo http. Os usuários podem escrever e implantar lógica de agendamento customizada para atender às necessidades de acesso ao sistema interno da empresa para agendamento. O plug-in integrado implementa recursos mais gerais e complementa o plug-in externo. Os usuários podem expandir a lógica de agendamento com custo mínimo e sem alterar o plano de controle da federação e contar com o poderoso recurso de distribuição de vários clusters do KubeAdmiral para fazer o agendamento. resultados eficazes.
3. Migração automática se o agendamento do aplicativo falhar
Para recursos agendados por réplicas, o KubeAdmiral calculará quantas réplicas cada cluster membro merece, sobrescreverá o número de campos de réplicas e depois os entregará a cada cluster membro. Esse processo é chamado de agendamento federado após a entrega dos recursos, cada cluster membro; o agendador alocará o pod correspondente ao recurso para o nó correspondente. Este processo se torna o agendamento de cluster único.
Depois que os recursos são emitidos, o agendamento de cluster único às vezes pode falhar devido ao nó off-line, recursos insuficientes, afinidade do nó insatisfeita, etc. Se não for tratado, as instâncias de negócios disponíveis serão menores do que o esperado. KubeAdmiral fornece a função de migração automática quando o agendamento falha. Quando habilitado, ele pode identificar réplicas não programáveis em clusters membros e migrá-las para clusters que podem acomodar réplicas redundantes, realizando a rotatividade de recursos de vários clusters.
Por exemplo, três clusters A, B e C recebem 6 cópias com peso igual. Após o agendamento inicial da federação, cada cluster receberá 2 cópias. Se duas cópias no cluster C não forem agendadas em um único cluster, o KubeAdmiral as migrará automaticamente para A e B.
| conjunto | A | B | C |
|---|---|---|---|
| Pesos | 1 | 1 | 1 |
| Número de instâncias iniciais de agendamento federado | 2 | 2 | 2 |
| Réplicas que não são agendadas em um único cluster | 0 | 0 | 2 |
| Número de instâncias de agendamento federado após a migração automática | 3 | 3 | 0 |
4. Programe recursos dinamicamente com base nos níveis de água do cluster
Em um ambiente de vários clusters, os níveis de recursos de cada cluster mudam dinamicamente à medida que as máquinas ficam on-line e off-line. Depender apenas das réplicas de agendamento de peso estático fornecidas pelo KubeFed RSP pode facilmente levar a níveis de água desiguais do cluster. propenso a problemas durante atualizações de serviço, os pods parecem estar pendentes há muito tempo e os recursos do cluster com uma baixa taxa de implantação não podem ser totalmente utilizados. Nesse sentido, o KubeAdmiral introduz o agendamento de peso dinâmico com base no nível de água do cluster. Ele calcula a quantidade disponível coletando a quantidade total de recursos e o uso de cada cluster e usa a quantidade de recursos disponíveis como o peso do agendamento de cópias, alcançando, em última análise, o balanceamento de carga de. cada cluster membro e a taxa de implantação de todos os clusters membros é mantida acima de 95%.
5. Melhoria do algoritmo de alocação de cópias
O algoritmo de alocação de cópias do KubeFed geralmente faz com que o número de instâncias se desvie das expectativas ao aumentar ou diminuir, por exemplo:
30 instâncias são distribuídas em três clusters membros A, B e C. No caso de rsp.rebalance = false, o usuário deseja reduzir para 15 instâncias:
Antes de encolher:
| conjunto | A | B | C |
|---|---|---|---|
| Pesos | 10 | 10 | 10 |
| Número de Instâncias | 15 | 15 | 0 |
Depois de encolher:
| conjunto | A | B | C |
|---|---|---|---|
| Pesos | 10 | 10 | 10 |
| Número de Instâncias | 15 | 0 | 0 |
A razão para esse fenômeno é que o algoritmo de réplica do KubeFed primeiro pré-aloca o número de instâncias atualmente existentes no cluster e, em seguida, aloca as instâncias restantes de acordo com o peso de cada cluster. Se houver muitas réplicas no cluster atual, ele. will Isso leva a um sério desvio entre a distribuição e o peso das instâncias.
KubeAdmiral otimiza o algoritmo de cópia do KubeFed para tornar a distribuição final o mais próximo possível de uma distribuição de peso, garantindo ao mesmo tempo que nenhuma migração inesperada ocorra durante a expansão e contração. Tomando como exemplo a escala de 30 para 15 instâncias, o processo simplificado do algoritmo é o seguinte:
- distribuição atual = [15, 15, 0], total de réplicas: 30
- distribuição desejada = [5, 5, 5], total de réplicas: 15
- distância = desejada - corrente = [-10, -10, 5], distância total: 15
- Para cenários de redução, remova o termo positivo distância = [-10, -10, 0]
- Usando a distância como peso, redistribua a diferença 15: [-7, -8, 0]
- Resultado final do agendamento: [-7, -8, 0] + [15, 15, 0] -> [8, 7, 0]
| conjunto | A | B | C |
|---|---|---|---|
| Pesos | 10 | 10 | 10 |
| Número de Instâncias | 8 | 7 | 0 |
6. Apoie recursos nativos
Ao contrário do KubeFed, que exige que os usuários usem uma nova API completamente incompatível, o KubeAdmiral atende aos hábitos de uso dos usuários de cluster único do Kubernetes e fornece suporte para APIs nativas do Kubernetes. Depois que os usuários criam recursos nativos (como Implementação), o Federate Controller os converte automaticamente em objetos internos federados para uso por outros controladores. Os usuários podem migrar rapidamente de um único cluster para uma arquitetura de vários clusters e aproveitar a conveniência de vários clusters com uma arquitetura. baixo limiar.
KubeAdmiral não para por aí. Em um único cluster, o controlador nativo do Kubernetes atualizará o status de alguns recursos para refletir seu status atual. Os usuários ou sistemas de camada superior geralmente dependem do status para visualizar informações como status de implantação e status de integridade. Em vários clusters, o status dos recursos está espalhado por vários clusters. Para visualizar o status global, os usuários devem visualizar o status dos recursos em cada cluster, um por um, causando problemas como visualizações fragmentadas e baixa eficiência de operação e manutenção. Para resolver esse problema e oferecer suporte perfeito aos recursos nativos, o KubeAdmiral fornece recursos de agregação de status. O Status Aggregator mescla e integra o status dos recursos em clusters de vários membros e os grava de volta nos recursos nativos, para que os usuários não precisem estar cientes de vários clusters. -topologia de cluster O status dos recursos em toda a federação pode ser observado rapidamente.
presente e futuro
KubeAdmiral foi incubado na Byte por muitos anos. Ele apoia fortemente a plataforma TCE de negócios do Byte Group e gerencia mais de 210.000 máquinas e mais de 10 milhões de pods. experiência prática. . Para retribuir à comunidade, o KubeAdmiral foi oficialmente aberto no GitHub. Ao mesmo tempo, o Volcano Engine está construindo um novo modelo de gerenciamento multinuvem e multicluster de nível empresarial baseado no KubeAdmiral - a Plataforma Nativa de Nuvem Distribuída (DCP), portanto, fique atento.
Olhando para o futuro, pretendemos continuar a evoluir nas seguintes vertentes:
- Continuar a melhorar os recursos de orquestração e agendamento de recursos com estado, tipo de trabalho e outros, e desenvolver recursos avançados, como migração automática e agendamento de comparação de preços, para abraçar o advento da era multinuvem e multicluster da computação em lote.
- Melhore a experiência do usuário e forneça soluções prontas para uso para reduzir ainda mais a carga cognitiva dos usuários.
- Melhore a observabilidade, otimize os indicadores de registro e monitoramento e melhore a interpretabilidade do agendador.
- Explore funções como federação com um clique e migração de vários clusters para liberar totalmente o potencial da arquitetura de vários clusters.
A orquestração e o agendamento de vários clusters não são de natureza simples. Um sistema federado de vários clusters universal e completo deve ser aprimorado em vários cenários. Esperamos que mais amigos prestem atenção e se juntem à comunidade KubeAdmiral. e nos dê várias sugestões!
GitHub: https://github.com/kubewharf/kubeadmiral
Companheiro de frango, deepin-IDE de "código aberto" e finalmente conseguiu a inicialização! Bom cara, a Tencent realmente transformou o Switch em uma "máquina de aprendizagem pensante" Revisão de falhas e explicação da situação da Tencent Cloud em 8 de abril Reconstrução de inicialização de desktop remoto RustDesk Cliente Web Banco de dados de terminal de código aberto do WeChat baseado em SQLite WCDB inaugurou uma grande atualização Lista de abril TIOBE: PHP caiu para o nível mais baixo, Fabrice Bellard, o pai do FFmpeg, lançou a ferramenta de compressão de áudio TSAC , o Google lançou um grande modelo de código, CodeGemma , isso vai te matar? É tão bom que é de código aberto - ferramenta de edição de imagens e pôsteres de código aberto