Plano de controle para Kubernetes PaaS distribuído

(Ankur Singla) (15 de novembro , 2019)

Autores : Ankur Singla , Harshad Nakil

Este blog é o primeiro de uma série de blogs que cobrem vários aspectos do que foi necessário para construir e operar nosso Serviço SaaS :

  1. Plano de controle para Kubernetes PaaS
  2. (Malha de serviço global para aplicativos distribuídos)
  3. (Segurança de plataforma de infraestrutura distribuída, aplicativos e dados)
  4. (Segurança de aplicativo e rede de clusters distribuídos)
  5. Observabilidade em uma plataforma distribuída globalmente
  6. Operações e SRE de uma plataforma distribuída globalmente
  7. Estrutura de serviço Golang para microsserviço distribuído s

Conforme descrito em nosso blog anterior , nossos clientes estão criando conjuntos complexos e diversificados de soluções de negócios – como smart fabricação, vídeo forense para segurança pública, negociação algorítmica, redes telco 5G – e, portanto, precisamos fornecer uma experiência sempre ativa, conectada e confiável para esses aplicativos e seus usuários finais.

Desde esses aplicativos poderia ser executado em vários clusters em provedores de nuvem ou locais de presença de clientes, nossa equipe de plataforma teve que construir um plano de controle distribuído e um serviço PaaS para implantar, proteger e operar vários clusters Kubernetes multilocatários. Este plano de controle distribuído ofereceu muitos benefícios operacionais, de dimensionamento e de desempenho que abordaremos em nossa apresentação ( link de vídeo ) – por exemplo como gerenciar milhares de clusters K8s edge com GitOps – e também como um post de blog separado nas próximas semanas.

TL; DR (Resumo)

  1. Não foi possível encontrar uma solução simples de usar no mercado que poderia resolver o problema de implantação, proteção e operação de vários clusters de aplicativos que são distribuídos em provedores de nuvem, nuvens privadas ou vários pontos de presença.
  2. Não encontramos um robusto Distribuição do Kubernetes ou PaaS (por exemplo, OpenShift, Cloud Foundry etc.) que fornecia um conjunto abrangente de serviços operacionais e de segurança necessários para clusters distribuídos – por exemplo, identidade baseada em PKI, RBAC e gerenciamento de acesso de usuário, segredos e gerenciamento de chaves em provedores de nuvem , malha de serviço de vários clusters, observabilidade e registros de auditoria ou segurança de aplicativos e rede.
  3. Anthos (Google), Azure Arc (Microsoft) e Rancher são estações de gerenciamento de vários clusters e pacotes de vários serviços diferentes ; nossa análise foi que isso não teria resolvido os requisitos operacionais, de escalonamento, segurança e multilocação que tínhamos para serviços de aplicativo e infraestrutura em vários clusters.
  4. Tivemos que construir nosso próprio plano de controle distribuído para nossa PaaS gerenciada que se baseia no Kubernetes. Começamos com o vanilla Kubernetes e, em seguida, fizemos mudanças significativas para fornecer serviços de plataforma necessários para nossas equipes de DevOps e SRE. Além disso, tivemos que construir um plano de controle para gerenciar um grande número de clusters distribuídos e entregar multilocação em infraestrutura heterogênea (em borda, nossa rede e vários provedores de nuvem).

Kubernetes para gerenciamento de aplicativos: por que & Como

Escolhemos o Kubernetes (K8s) para ser o núcleo de nossa plataforma de gerenciamento de aplicativos distribuídos, pois fornece um conjunto rico de funcionalidades sem ser excessivamente prescritivo – dando-nos flexibilidade para inovar em coisas que acreditamos serem importantes para nossos clientes. Usamos isso como base para começar a construir nosso serviço e, com a popularidade crescente dos K8s, também ficou mais fácil encontrar desenvolvedores e operadores familiarizados com ele.

Dito isso, implantar e gerenciar um grande número de clusters Kubernetes de nível de produção em um ambiente híbrido (várias nuvens, POPs de rede e pontos de presença) não é muito fácil, pois não há out-of-the- -box soluções para Kubernetes que podem:

  1. Harmonizar recursos de infraestrutura heterogênea com clustering automatizado, escalonamento e provisionamento zero-touch; isso foi especialmente doloroso no limite e em nossos PoPs de rede
  2. Forneça alto desempenho e conectividade confiável em locais distintos – especialmente ao cruzar provedores de nuvem e vindo de locais de limite
  3. Resolva a segurança problema de dados em trânsito, dados em repouso, segredos, chaves e rede … tudo apoiado por uma identidade PKI uniforme que funciona em toda a borda, rede e nuvem
  4. Fornece multilocação verdadeira – isolamento de inquilino e garantias de segurança – com a capacidade de executar cargas de trabalho de produção e desenvolvimento para necessidades internas e do cliente nos mesmos clusters
  5. Fornece observabilidade e operações em clusters distribuídos que se relacionam com a política centralizada e a intenção, sem a necessidade de construção complexa coleta de registros e métricas

Depois de várias provas de conceito com vários provedores de nuvem e plataformas de código aberto como GKE, AKS, EKS e RKE, bem como OpenShift e Cloud Foundry – percebemos que nenhum deles poderia atender todos os fi cinco requisitos acima. Como resultado, decidimos construir nosso próprio PaaS – começando com o Kubernetes “vanilla” e fizemos várias adições – para identidade, rede, segurança, multilocação, registro, métricas etc. Enquanto usamos o Kubernetes para atender às nossas necessidades internas, tivemos que tomar algumas decisões difíceis, como não expor esses clusters Kubernetes diretamente para nossos usuários internos e / ou clientes para executar suas cargas de trabalho (mais sobre isso depois, já que multilocação era um objetivo principal para nós).

Além de vários novos recursos que precisávamos adicionar, havia também a necessidade de executar nossas cargas de trabalho / serviços junto com as cargas de trabalho do cliente em muitos locais na borda, nossa rede e nuvens públicas / privadas. Isso significa que tivemos que construir recursos adicionais para gerenciar vários clusters em vários ambientes … todos conectados usando nossa rede global e nossos gateways de aplicativos distribuídos para fornecer confiança zero e conectividade de nível de aplicativo entre esses clusters.

O Parte difícil: multilocação e multicluster para Kubernetes

Criar e operar aplicativos em execução em um único cluster Kubernetes é uma tarefa não trivial, mesmo que consuma um cluster gerenciado por provedor de nuvem. É por isso que é comum que as equipes de DevOps e SRE minimizem sua sobrecarga e não lidem com as complexidades de muitos clusters. É bastante comum ver equipes construírem um grande cluster do Kubernetes e colocar todos os tipos de recursos no mesmo cluster. Embora pareça ótimo, porque eles podem simplificar as operações e executar o cluster para obter o máximo de eficiência e custo de computação, essa não é a melhor ideia por vários motivos. Em primeiro lugar, as necessidades de cargas de trabalho de produção são muito diferentes do dev-test e do teste – cargas de trabalho de desenvolvimento instáveis ​​podem causar problemas para cargas de trabalho de produção mais estáveis.

Além das necessidades de cargas de trabalho variadas, segurança K8s e limitações de isolamento é outro driver para vários clusters. Uma abordagem típica para solucionar a segurança do K8 e o isolamento de recursos é criar clusters independentes para cada locatário usando um modelo multilocatário. Embora isso possa ser viável na nuvem, não é possível executar vários clusters na extremidade. Sites de ponta têm limitações de recursos de computação e armazenamento e largura de banda de rede restrita para enviar registros e métricas de cada cluster adicional para a nuvem central.

Para lidar com o problema de vários clusters Kubernetes, avaliamos o Rancher para gerenciamento centralizado de nossos clusters Kubernetes (quando começamos, o Anthos e o Azure Arc não existiam) e o KubeFed. As duas abordagens disponíveis naquela época eram (e ainda são a mesma situação hoje):

  1. Gerenciamento de vários clusters (por exemplo, Rancher) de um console central nos teria dado a capacidade de implantar vários clusters em qualquer local e realizar operações de gerenciamento de ciclo de vida, como upgrades, rollback, etc. Alguns desses sistemas também permitiram abordar um cluster individual com automação para configuração e implantação de aplicativos
  2. Outra abordagem é implantar um Kubernetes plano de controle de federação de cluster (KubeFed) e pode fazer vários clusters físicos parecerem um só cluster. Este projeto estava apenas começando na época em que analisamos e ainda hoje está apenas em estágio alfa.

Após o anúncio recente do GCP Anthos e do Azure Arc, reavaliamos nossa decisão original de construir um plano de controle distribuído e a conclusão foi que mesmo essas duas novas ofertas não poderiam ter resolvido dois problemas críticos com clusters distribuídos.Esses dois recursos principais que precisávamos para nossa plataforma eram:

  1. Gerenciar vários clusters como uma frota para resolver o problema de realizar operações em todos ou em um grupo lógico de clusters – operações como configuração implantação, métricas, etc. Isso é crítico, pois queremos reduzir a sobrecarga de operações para nossas equipes de SRE, melhorar a capacidade de depuração de nosso DevOps e melhorar a escalabilidade de nosso sistema
  2. Capacidade de dividir um físico individual Cluster Kubernetes para multilocação sem a necessidade de ativar clusters físicos – isso é especialmente crítico em ambientes com recursos limitados, onde não queremos adicionar novos clusters físicos apenas para multilocação

Para resolver esses dois problemas, tivemos que criar uma nova técnica – plano de controle distribuído – para resolver o overhead operacional de “Múltiplos” clusters e fornecem um equivalente a “múltiplos clusters” para multilocação em restrição de recursos ambientes d.

Plano de controle distribuído: como alcançamos o Kubernetes multicluster

Nossa equipe de plataforma decidiu criar um plano de controle distribuído para o Kubernetes que expõe APIs do Kubernetes para uso de nossa equipe. , essas APIs vêm de clusters “virtuais” que existem apenas em nosso plano de controle – um servidor de API K8s (vK8s) virtual para um cluster K8s virtual (conforme mostrado na Figura 1 ). Este plano de controle mapeia a intenção do usuário para vários clusters Kubernetes físicos em execução em nossa borda, nossos POPs de rede e locais de nuvem pública. Esses clusters físicos são acessíveis apenas ao nosso plano de controle distribuído, e não a qualquer locatário / usuário individual.

Figura 1: Plano de controle distribuído

Este plano de controle fornece a cada locatário um ou mais clusters de aplicativos “virtuais” onde eles podem implantar seus aplicativos (s ) e com base na configuração, o plano de controle irá replicar e gerenciar em vários clusters Kubernetes físicos. Além das operações de configuração e implantação, as operações de monitoramento também seguem esse cluster “virtual” sem a necessidade de construir ferramentas para coletar e dissecar dados de vários clusters físicos.

Vamos pegar um exemplo de aplicativo de IU chamado productpage, onde a intenção do usuário é executá-lo distribuído em 3 locais – pa2-par, ny8-nyc e ams9-ams com 2 réplicas em cada um deles. Conforme o usuário cria um objeto vK8s e o anexa a um cluster virtual, que provisiona imediatamente um servidor de API vK8s que pode ser usado com o kubectl padrão.

Na próxima etapa, o usuário baixa o kubeconfig para este virtual cluster e cria yaml padrão para descrever uma implantação K8s para a página do produto.

Após a criação da especificação de implantação , o usuário pode prosseguir para criar uma implantação neste cluster virtual:

Agora, se o usuário verificar sua implantação, ele vê 6 réplicas, foi iniciada com 2 em cada local (pa2-par, ny8-nyc e ams9-ams).

O resultado a seguir mostra 2 pods em execução em cada local com mapeamento para um nó físico específico

Este exemplo simples demonstra como é trivial obter replicação de vários clusters de qualquer aplicativo em minutos es sem qualquer carga de instalação e gerenciamento. Além de mapear a intenção, o plano de controle distribuído também oferece observabilidade para o cluster virtual e não em uma base de cluster individual.

Controle distribuído e gerenciamento centralizado para multilocação

Como você pode ver na Figura 2 , nosso plano de gerenciamento centralizado está sendo executado em dois provedores de nuvem pública (uma região cada) – um em AWS e um no Azure (para redundância). Este plano de gerenciamento permite que nosso SRE crie inquilinos com multilocação rígida – por exemplo, uma equipe de desenvolvimento trabalhando em nosso serviço VoltMesh pode ser um locatário e uma equipe de soluções para o cliente trabalhando em POCs do cliente pode ser seu próprio locatário com seu próprio conjunto de usuários.

Figura 2: Multi-Locação e Multi-Cluster

Cada um desses locatários pode criar muitos namespaces e atribuir um grupo de usuários para colaborar nesses namespaces. Esses namespaces não são Kubernetes – eles são um limite de isolamento em nossa plataforma com regras RBAC e políticas IAM para usuários.

Quando um usuário em um namespace deseja criar um cluster de aplicativo, ele cria um objeto vK8s e que, por sua vez, cria um servidor API vK8s em nosso plano de gerenciamento.Usando este objeto vK8s, o usuário pode criar implantações, conjuntos com estado, PVCs, etc. e o plano de controle garantirá que essas operações aconteçam em um ou mais clusters físicos, com base em sites associados ao objeto vK8s.

Uma vez que cada locatário e usuário está usando operações K8s padrão sem nenhuma modificação, ele permite que o sistema seja compatível com uma série de ferramentas que são populares entre os operadores – por exemplo, Spinnaker, Helm, Jenkins, etc.

Ganhos obtidos com um plano de controle distribuído

A grande vantagem de um plano de controle distribuído é que ele resolveu o overhead operacional de nosso SRE e DevOps equipes. Eles agora podem executar operações (configuração, implantação, monitoramento, política, etc) em um cluster virtual e o plano de controle irá mapeá-lo automaticamente em vários clusters físicos. Além da simplificação operacional para vários clusters, o plano de controle também resolveu o problema de segurança e isolamento para multilocação.

Este plano de controle distribuído também melhorou a produtividade dos desenvolvedores que desejam adicionar novos recursos ao nossa plataforma – eles não precisam construir uma nova automação toda vez que adicionam novos recursos que afetam a configuração ou as operações em vários clusters. Eles usam o modelo de configuração baseado em intenção e o plano de controle sabe o que precisa ser feito. Além disso, eles podem continuar a interagir com este objeto de cluster distribuído e múltiplo – kubernetes virtuais – usando kubectl e não outra CLI.

Depois de executar isso em nossos ambientes de teste de desenvolvimento, teste e produção para mais Há mais de um ano, percebemos que esse plano de controle distribuído globalmente (funcionando em nossos POPs de rede) também oferece vantagens significativas de escala, desempenho e confiabilidade – algo que não havíamos imaginado completamente em nossos primeiros dias. Abordaremos essa descoberta em nossa próxima apresentação da KubeCon e em uma postagem separada no blog nas próximas semanas.

Continuando…

Esta série de blogs cobrirá vários aspectos do que é levou para nós construir e operar nosso serviço SaaS distribuído globalmente com muitos clusters de aplicativos na nuvem pública, nossos PoPs de rede privada e sites de ponta. O próximo é (Rede de serviço global para aplicativos distribuídos)…