Cubo sobre cubo, metaclusters, favos de mel, distribuição de recursos

Arroz. 1. Ecossistema Kubernetes no Alibaba Cloud

Desde 2015, o Alibaba Cloud Container Service for Kubernetes (ACK) tem sido um dos serviços em nuvem de crescimento mais rápido no Alibaba Cloud. Atende vários clientes e também oferece suporte à infraestrutura interna do Alibaba e a outros serviços em nuvem da empresa.

Tal como acontece com serviços de contentores semelhantes de fornecedores de nuvem de classe mundial, as nossas principais prioridades são a fiabilidade e a disponibilidade. Portanto, uma plataforma escalável e acessível globalmente foi criada para dezenas de milhares de clusters Kubernetes.

Neste artigo, compartilharemos nossa experiência no gerenciamento de um grande número de clusters Kubernetes em infraestrutura em nuvem, bem como a arquitetura da plataforma subjacente.

Entrada

O Kubernetes se tornou o padrão de fato para uma variedade de cargas de trabalho na nuvem. Como mostrado na Fig. 1 acima, cada vez mais aplicativos Alibaba Cloud estão sendo executados em clusters Kubernetes: aplicativos com e sem estado, bem como gerenciadores de aplicativos. O gerenciamento do Kubernetes sempre foi um tópico interessante e sério de discussão para engenheiros que constroem e mantêm infraestrutura. Quando se trata de provedores de nuvem como o Alibaba Cloud, a questão do dimensionamento vem à tona. Como gerenciar clusters Kubernetes nesta escala? Já abordamos as práticas recomendadas para gerenciar enormes clusters Kubernetes de 10 nós. Claro, este é um problema de escala interessante. Mas há outra escala: quantidade os próprios clusters.

Discutimos este tópico com muitos usuários do ACK. A maioria deles opta por executar dezenas, senão centenas, de clusters Kubernetes pequenos ou médios. Existem boas razões para isso: limitar danos potenciais, separar clusters para equipes diferentes, criar clusters virtuais para testes. Se o ACK pretende servir um público global com este modelo de utilização, deve gerir de forma fiável e eficiente um grande número de clusters em mais de 20 regiões.

Arroz. 2. Problemas de gerenciamento de um grande número de clusters Kubernetes

Quais são os principais desafios da gestão de clusters nesta escala? Conforme mostrado na figura, há quatro questões a serem resolvidas:

• Heterogeneidade

O ACK deve oferecer suporte a vários tipos de clusters, incluindo padrão, sem servidor, Edge, Windows e vários outros. Clusters diferentes exigem opções, componentes e modelos de hospedagem diferentes. Alguns clientes precisam de assistência na customização para seus casos específicos.

• Vários tamanhos de cluster

Os clusters variam em tamanho, desde alguns nós com alguns pods até dezenas de milhares de nós com milhares de pods. Os requisitos de recursos também variam muito. A alocação inadequada de recursos pode afetar o desempenho ou até mesmo causar falhas.

• Versões diferentes

O Kubernetes está evoluindo muito rapidamente. Novas versões são lançadas a cada poucos meses. Os clientes estão sempre dispostos a experimentar novos recursos. Então, eles querem colocar a carga de teste nas novas versões do Kubernetes e a carga de produção nas versões estáveis. Para atender a esse requisito, o ACK deve fornecer continuamente novas versões do Kubernetes aos clientes, mantendo versões estáveis.

• Conformidade de segurança

Os clusters são distribuídos em diferentes regiões. Como tal, devem cumprir vários requisitos de segurança e regulamentos oficiais. Por exemplo, um cluster na Europa deve ser compatível com o GDPR, enquanto uma nuvem financeira na China deve ter camadas adicionais de proteção. Estes requisitos são obrigatórios e é inaceitável ignorá-los, pois isso cria enormes riscos para os clientes da plataforma cloud.

A plataforma ACK foi projetada para resolver a maioria dos problemas acima. Atualmente, ele gerencia de forma confiável e estável mais de 10 mil clusters Kubernetes em todo o mundo. Vejamos como isso foi alcançado, inclusive por meio de vários princípios-chave de design/arquitetura.

Projeto

Cubo sobre cubo e favo de mel

Ao contrário de uma hierarquia centralizada, a arquitetura baseada em células é normalmente usada para escalar uma plataforma além de um único data center ou para expandir o escopo da recuperação de desastres.

Cada região do Alibaba Cloud consiste em várias zonas (AZ) e geralmente corresponde a um data center específico. Em uma região grande (por exemplo, Huangzhou), geralmente existem milhares de clusters de clientes Kubernetes executando ACK.

O ACK gerencia esses clusters Kubernetes usando o próprio Kubernetes, o que significa que temos um metacluster Kubernetes em execução para gerenciar os clusters clientes Kubernetes. Essa arquitetura também é chamada de “kube-on-kube” (KoK). A arquitetura KoK simplifica o gerenciamento de clusters de clientes porque a implantação de clusters é simples e determinística. Mais importante ainda, podemos reutilizar recursos nativos do Kubernetes. Por exemplo, gerenciar servidores API por meio de implantação, usando o operador etcd para gerenciar vários etcds. Essa recursão sempre traz um prazer especial.

Vários metaclusters do Kubernetes são implantados em uma região, dependendo do número de clientes. Chamamos esses metaclusters de células. Para proteger contra a falha de uma zona inteira, o ACK oferece suporte a implantações multiativas em uma única região: o metacluster distribui componentes mestres do cluster do cliente Kubernetes em várias zonas e os executa simultaneamente, ou seja, no modo multiativo. Para garantir a confiabilidade e eficiência do mestre, o ACK otimiza o posicionamento dos componentes e garante que o servidor API e o etcd estejam próximos um do outro.

Este modelo permite gerenciar Kubernetes de forma eficiente, flexível e confiável.

Planejamento de recursos do metacluster

Como já mencionamos, o número de metaclusters em cada região depende do número de clientes. Mas em que ponto adicionar um novo metacluster? Este é um problema típico de planejamento de recursos. Como regra, é comum criar um novo quando os metaclusters existentes esgotaram todos os seus recursos.

Vejamos os recursos de rede, por exemplo. Na arquitetura KoK, os componentes Kubernetes de clusters de clientes são implantados como pods em um metacluster. Nós usamos Terway (Fig. 3) é um plugin de alto desempenho desenvolvido pela Alibaba Cloud para gerenciamento de rede de contêineres. Ele fornece um rico conjunto de políticas de segurança e permite que você se conecte às nuvens privadas virtuais (VPCs) dos clientes por meio da Alibaba Cloud Elastic Networking Interface (ENI). Para distribuir eficazmente os recursos de rede entre nós, pods e serviços num metacluster, devemos monitorizar cuidadosamente a sua utilização dentro do metacluster de nuvens privadas virtuais. Quando os recursos da rede chegam ao fim, uma nova célula é criada.

Para determinar o número ideal de clusters de clientes em cada metacluster, também levamos em consideração nossos custos, requisitos de densidade, cota de recursos, requisitos de confiabilidade e estatísticas. A decisão de criar um novo metacluster é tomada com base em todas essas informações. Observe que pequenos clusters podem se expandir bastante no futuro, portanto, o consumo de recursos aumenta mesmo que o número de clusters permaneça inalterado. Geralmente deixamos espaço livre suficiente para cada cluster crescer.

Arroz. 3. Arquitetura de rede Terway

Dimensionando componentes do assistente em clusters de clientes

Os componentes do assistente têm necessidades de recursos diferentes. Eles dependem do número de nós e pods no cluster, do número de controladores/operadores não padrão interagindo com o APIServer.

No ACK, cada cluster de cliente Kubernetes difere em tamanho e requisitos de tempo de execução. Não existe uma configuração universal para colocar componentes do assistente. Se definirmos erroneamente um limite baixo de recursos para um cliente grande, seu cluster não será capaz de lidar com a carga. Se você definir um limite conservadoramente alto para todos os clusters, os recursos serão desperdiçados.

Para encontrar uma compensação sutil entre confiabilidade e custo, o ACK usa um sistema de tipos. Ou seja, definimos três tipos de clusters: pequenos, médios e grandes. Cada tipo possui um perfil de alocação de recursos separado. O tipo é determinado com base na carga dos componentes do assistente, no número de nós e em outros fatores. O tipo de cluster pode mudar com o tempo. O ACK monitora continuamente esses fatores e pode digitar para cima/para baixo de acordo. Depois que o tipo de cluster for alterado, a alocação de recursos será atualizada automaticamente com intervenção mínima do usuário.

Estamos trabalhando para melhorar este sistema com escalonamento mais refinado e atualização de tipo mais precisa para que essas mudanças ocorram de maneira mais suave e façam mais sentido do ponto de vista econômico.

Arroz. 4. Comutação inteligente de tipo multiestágio

Evolução dos clusters de clientes em escala

As seções anteriores cobriram alguns aspectos do gerenciamento de um grande número de clusters Kubernetes. Porém, há outro problema que precisa ser resolvido: a evolução dos clusters.

Kubernetes é o “Linux” do mundo da nuvem. Ele é continuamente atualizado e se torna mais modular. Devemos entregar constantemente novas versões aos nossos clientes, corrigir vulnerabilidades e atualizar clusters existentes, bem como gerenciar um grande número de componentes relacionados (CSI, CNI, Device Plugin, Scheduler Plugin e muitos outros).

Tomemos como exemplo o gerenciamento de componentes do Kubernetes. Para começar, desenvolvemos um sistema centralizado para registrar e gerenciar todos esses componentes conectados.

Arroz. 5. Componentes flexíveis e conectáveis

Antes de prosseguir, você precisa ter certeza de que a atualização foi bem-sucedida. Para isso, desenvolvemos um sistema de verificação da funcionalidade dos componentes. A verificação é realizada antes e depois da atualização.

Arroz. 6. Verificação preliminar dos componentes do cluster

Para atualizar esses componentes de forma rápida e confiável, um sistema de implantação contínua funciona com suporte para avanço parcial (tons de cinza), pausas e outras funções. Os controladores Kubernetes padrão não são adequados para este caso de uso. Portanto, para gerenciar os componentes do cluster, desenvolvemos um conjunto de controladores especializados, incluindo um plugin e um módulo de controle auxiliar (gestão sidecar).

Por exemplo, o controlador BroadcastJob foi projetado para atualizar componentes em cada máquina de trabalho ou verificar nós em cada máquina. O trabalho Broadcast executa um pod em cada nó do cluster, como um DaemonSet. No entanto, o DaemonSet sempre mantém o pod em execução por um longo tempo, enquanto o BroadcastJob o recolhe. O controlador Broadcast também inicia pods em nós recém-unidos e inicializa os nós com os componentes necessários. Em junho de 2019, abrimos o código-fonte do mecanismo de automação OpenKruise, que nós mesmos utilizamos na empresa.

Arroz. 7. OpenKurise organiza a execução da tarefa Broadcast em todos os nós

Para ajudar os clientes a selecionar as configurações de cluster corretas, também fornecemos um conjunto de perfis predefinidos, incluindo perfis Serverless, Edge, Windows e Bare Metal. À medida que o cenário se expande e as necessidades dos nossos clientes aumentam, adicionaremos mais perfis para simplificar o tedioso processo de configuração.

Arroz. 8. Perfis de cluster avançados e flexíveis para vários cenários

Observabilidade global em data centers

Como mostrado na fig. 9, o serviço de nuvem Alibaba Cloud Container foi implantado em vinte regiões ao redor do mundo. Dada essa escala, um dos principais objetivos do ACK é monitorar facilmente o estado dos clusters em execução para que, se um cluster cliente encontrar um problema, possamos responder rapidamente à situação. Em outras palavras, você precisa encontrar uma solução que permita coletar estatísticas em tempo real de maneira eficiente e segura de clusters de clientes em todas as regiões - e apresentar visualmente os resultados.

Arroz. 9. Implantação global do serviço Alibaba Cloud Container em vinte regiões

Como muitos sistemas de monitoramento Kubernetes, usamos o Prometheus como nossa ferramenta principal. Para cada metacluster, os agentes do Prometheus coletam as seguintes métricas:

• Métricas do sistema operacional, como recursos de host (CPU, memória, disco, etc.) e largura de banda da rede.
• Métricas para o metacluster e o sistema de gerenciamento de cluster do cliente, como kube-apiserver, kube-controller-manager e kube-scheduler.
• Métricas de kubernetes-state-metrics e cadvisor.
• métricas do etcd, como tempo de gravação em disco, tamanho do banco de dados, taxa de transferência de conexões entre nós, etc.

As estatísticas globais são coletadas usando um modelo típico de agregação multicamadas. Os dados de monitoramento de cada metacluster são primeiro agregados em cada região e depois enviados para um servidor central que mostra o panorama geral. Tudo funciona através do mecanismo da federação. Um servidor Prometheus em cada data center coleta métricas desse data center, e o servidor central do Prometheus é responsável por agregar os dados de monitoramento. O AlertManager se conecta à central do Prometheus e, se necessário, envia alertas via DingTalk, email, SMS, etc. Visualização - usando Grafana.

Na Figura 10, o sistema de monitoramento pode ser dividido em três níveis:

• Nível limite

A camada mais distante do centro. O Prometheus Edge Server é executado em cada metacluster, coletando métricas de metaclusters e clusters de clientes no mesmo domínio de rede.

• Nível de cascata

A função da camada em cascata do Prometheus é coletar dados de monitoramento de múltiplas regiões. Esses servidores operam em unidades geográficas maiores, como China, Ásia, Europa e América. À medida que os clusters crescem, a região pode ser dividida e, então, um servidor Prometheus em nível de cascata aparecerá em cada nova região grande. Com essa estratégia, você pode dimensionar facilmente conforme necessário.

• Nível central

O servidor central do Prometheus se conecta a todos os servidores em cascata e realiza a agregação final dos dados. Para maior confiabilidade, duas instâncias centrais do Prometheus foram criadas em zonas diferentes, conectadas aos mesmos servidores em cascata.

Arroz. 10. Arquitetura global de monitoramento multinível baseada no mecanismo de federação Prometheus

Resumo

As soluções em nuvem baseadas em Kubernetes continuam a transformar nossa indústria. O serviço de contêiner Alibaba Cloud oferece hospedagem segura, confiável e de alto desempenho - é uma das melhores hospedagens em nuvem Kubernetes. A equipe do Alibaba Cloud acredita fortemente nos princípios do código aberto e na comunidade de código aberto. Definitivamente continuaremos a compartilhar nosso conhecimento na área de operação e gerenciamento de tecnologias de nuvem.

Fonte: habr.com