Kubernetes em sua própria infraestrutura: prós e contras de nuvens privadas

Caros leitores, bom dia!



Neste artigo, Igor Kotenko, arquiteto-chefe da Neoflex, compartilha sua experiência de implantação de uma plataforma de conteinerização em uma infraestrutura corporativa.







Os motivos pelos quais as empresas geralmente escolhem uma solução local geralmente não são tecnológicos e costumam estar relacionados ao financiamento. Alguém está tentando reduzir custos operacionais (pagando por nuvens externas) em favor de capitalizar a empresa (comprando seus próprios servidores), alguém já possui recursos de hardware sólidos e deseja utilizá-los em uma arquitetura de microsserviço.



Antes de passar para os detalhes de implementação, vamos voltar aos termos.



O termo "nuvens" é considerado muito congestionado. É comum distinguir entre diferentes tipos de soluções em nuvem:



  • Infraestrutura como serviço (IAAS) - hardware (geralmente virtual);
  • Software as a Service (SAAS), por exemplo, DBAS - banco de dados como serviço;
  • Plataforma como Serviço (PAAS);
  • Aplicativo como serviço (AAAS).








Ao mesmo tempo, nada impede que as camadas sejam baseadas umas nas outras. Obviamente, haverá infraestrutura sob a plataforma ou software.



Existe alguma confusão sobre o termo "nuvens privadas". Às vezes, isso é chamado de nuvem implantada no local, às vezes implantada em uma infraestrutura alugada com isolamento completo de seu segmento de rede. Houve até uma menção de máquinas virtuais com memória e discos criptografados, enquanto um despejo de memória não dará ao provedor acesso às suas informações. Neste artigo, discutiremos as soluções implantadas internamente - no local.



Ao introduzir nuvens privadas, espera-se que sejam iguais às públicas, porém mais baratas, seguras e confiáveis. Portanto, muitas pessoas pensam que as nuvens privadas são, a priori, melhores. Muitas vezes, os especialistas simplesmente implantam a versão selecionada do Kubernetes ou Openshift e acreditam que é aqui que seu trabalho é concluído.



O que as empresas esperam obter ao implementar nuvens no local:



  1. Baixo custo de recursos. Porque você só paga pelo que usa.
  2. A capacidade de adicionar e devolver recursos o mais rápido possível.
  3. Tolerância ao erro. O servidor travou, outro foi fornecido automaticamente.
  4. Baixo custo de suporte.




Como isso é feito em nuvens públicas?



Via de regra, devido à automação de processos, economia de escala (mais barato no atacado) e compartilhamento de recursos entre diferentes consumidores.



Vejamos essas promessas no contexto de nuvens privadas.



1. Baixo custo de recursos em comparação com a infraestrutura convencional.



Na verdade, não é assim. O mesmo software foi implantado nas mesmas máquinas, mas em contêineres. Em nossa experiência, ao contrário, mais recursos são desperdiçados.



2. Capacidade de aumentar e diminuir recursos com extrema rapidez.



Não. Para expandir, você precisa manter a reserva quente de licenças de hardware e software ociosa ou primeiro descartar algo desnecessário. Você pode tirar os recursos de uso, mas eles ficarão ociosos.



3. Tolerância a falhas.



Sim, mas existem muitas nuances. Digamos que o servidor esteja inativo. Onde posso conseguir outro? Como implementar e adicionar rapidamente a um cluster? Se você não é a Amazon, não tem um suprimento infinito de recursos.



4. Baixo custo de suporte.



Adicionamos pelo menos mais uma camada (plataforma de contentorização), vários novos sistemas. Precisamos de especialistas com novas competências. De onde virá a economia?



Vamos examinar essas questões com mais detalhes. É importante lembrar que as nuvens privadas devem coexistir com os sistemas legados existentes. As organizações são obrigadas a manter em paralelo a infraestrutura dos sistemas existentes, organizando um ambiente de TI híbrido.



Naturalmente, 99% do sistema não é construído do zero. Via de regra, antes mesmo da implantação de uma solução PAAS, existe um conjunto de processos e automações para suportar a infraestrutura anterior. Processos DevOps, planejamento e propriedade de recursos, monitoramento, atualizações de software, segurança - todas essas questões devem ser acordadas e alteradas durante a implementação de uma nuvem privada.



Como os processos DevOps estão mudando



Normalmente, antes de implementar seu próprio PAAS, a abordagem para construir DevOps é baseada no uso de sistemas de automação de configuração, como Ansible ou Chef. Eles permitem que você automatize quase todos os processos de rotina de TI, geralmente usando bibliotecas de script prontas. No entanto, as plataformas de conteinerização estão promovendo uma abordagem alternativa - “infraestrutura imutável”. Sua essência não é mudar o sistema existente, mas pegar uma imagem virtual pronta do sistema com novas configurações e substituir a imagem antiga por uma nova. A nova abordagem não nega a antiga, mas força a automação da configuração na camada de infraestrutura. Obviamente, os sistemas legados exigem manter a abordagem antiga.



Vamos falar sobre a camada de infraestrutura



O padrão de fato em TI é o uso de infraestrutura virtual. Como mostra a prática, a opção mais comum é usar o vSphere. Existem muitas razões para isso, mas também existem consequências. Em nossa prática, problemas frequentes de superalocação em termos de recursos (tentativa de costurar sete gorros de uma pele) eram agravados pela quase total falta de controle e influência neste processo dos responsáveis ​​pelo desempenho da solução. A delimitação de áreas de responsabilidade nas divisões da empresa, a formalização de procedimentos de solicitação de recursos e diferentes objetivos da gestão das divisões geravam problemas no ambiente do produto e testes de carga inconsistentes. Em algum ponto, nosso departamento de desenvolvimento até criou uma ferramenta de medição de desempenho central virtual,para diagnosticar rapidamente a falta de recursos de hardware.



É óbvio que uma tentativa de colocar uma plataforma de conteinerização em tal infraestrutura trará novas cores ao caos existente.



A questão de saber se uma plataforma de conteinerização local precisa de uma infraestrutura virtual ou se é melhor colocá-la bare-metal (em servidores de ferro) tem sido discutida há muito tempo e de forma bastante ampla. Artigos pressionados por fabricantes de sistemas de virtualização argumentam que praticamente não há perdas de desempenho e os benefícios são muito grandes. Por outro lado, existem resultados de testes independentes que indicam perdas de desempenho de cerca de 10%. Não se esqueça do custo das licenças do vSphere. Por exemplo, instalar uma versão gratuita do Kubernetes em um hardware barato apenas para economizar dinheiro e pagar pelo vSphere? Decisão controversa.



Vale a pena mencionar uma solução de virtualização de infraestrutura de código aberto, por exemplo, Open Stack. No geral, ele era visto como uma solução que exigia um investimento significativo na equipe. Existem estatísticas na rede, segundo as quais o tamanho da equipe de suporte do Open Stack é de 20 a 60 pessoas. E isso é separado do suporte à plataforma de conteinerização! Existem poucos especialistas desse tipo no mercado, o que aumenta seu custo. Esses investimentos geralmente compensam apenas em grandes volumes de recursos.



É importante considerar a presença de especialistas com competências únicas na empresa. Infelizmente, as instalações bare-metal do Kubernetes, apesar dos benefícios de transparência e custos de licença mais baixos, costumam ser prejudicadas, por exemplo, pela falta de ferramentas de automação de instalação adequadas. Esperamos que o futuro pertença a esta abordagem.

Outro aspecto que influencia a escolha entre instalações virtuais e bare-metal é a organização de servidores de ferro.



Normalmente, uma organização adquire servidores para fins específicos. Você pode alugar servidores no data center (pelo que eles oferecem), pode padronizar e unificar a nomenclatura (simplificando a redundância de componentes), pode economizar em hardware (muitos servidores baratos), pode economizar espaço em rack. Abordagens diferentes em organizações diferentes. Em geral, esses são servidores poderosos com um grande número de núcleos e memória, ou relativamente pequeno em volume, ou uma mistura composta. Mas não se esqueça das necessidades dos sistemas legados. Nesse ponto, encontramos novamente uma contradição de conceitos. A ideologia do Kubernetes é muito hardware barato e prontidão para suas falhas. O servidor caiu - não importa, seus serviços foram movidos para outro. Os dados são fragmentados (duplicados), não vinculados a um contêiner. Ideologia legada - redundância no nível do hardware. Matrizes RAID,racks de disco, várias fontes de alimentação no servidor, hot swap. Concentre-se na confiabilidade máxima. Pode ser excessivamente caro apostar nessa infraestrutura do Kubernetes.



, …







Se uma empresa tiver servidores de alto desempenho com muitos núcleos a bordo, pode ser necessário dividi-los entre diferentes consumidores. Aqui você não poderá prescindir de um sistema de virtualização. Ao mesmo tempo, é necessário levar em consideração a possibilidade de falha do servidor ou paralisação para manutenção. A aritmética é simples: se você tiver dois servidores, se um falhar, você precisará de 50% de reserva de energia em cada um; se - 4 servidores, se um falhar, você precisa de reserva de 25%. À primeira vista, tudo é simples - você precisa de um número infinito de servidores, então a falha de um deles não afetará a capacidade total e você não precisa reservar nada. Infelizmente, o tamanho dos recursos de um host não pode ser muito reduzido. No mínimo, ele deve acomodar todos os componentes relacionados, que a terminologia do Kubernetes chama de “pods”. E, claro, ao compactar em servidores menores,os custos indiretos para serviços da própria plataforma estão crescendo.



Para fins práticos, é desejável unificar os parâmetros do host para a plataforma. Em exemplos quase reais, existem 2 data centers (suporte para o cenário de DR significa pelo menos 50% de reserva de recursos em termos de capacidade). Em seguida, são determinadas as necessidades da organização para os recursos da plataforma de conteinerização e a possibilidade de colocá-la em bare-metal padrão ou hosts virtuais. Recomendação do Kubernetes - não mais do que 110 pods por nó.



Assim, para determinar o tamanho do nó, você precisa considerar o seguinte:



  • É desejável tornar os nós iguais;
  • Os nós devem caber em seu hardware (para máquinas virtuais - múltiplos, N virtuais para uma peça de hardware);
  • Se um nó falhar (para a versão com infraestrutura virtual - um servidor de ferro), você deve ter recursos suficientes nos nós restantes para mover os pods para eles;
  • Não pode haver muitos (> 110) pods em um nó;
  • Outras coisas sendo iguais, é desejável tornar os nós maiores.




Esses tipos de recursos devem ser considerados em todos os aspectos da arquitetura.



Registro centralizado - como escolher entre várias opções?



Monitoramento - talvez o seu sistema de monitoramento existente não funcione, mantenha dois ou migre para um novo?



Atualizações da plataforma para uma nova versão - regularmente ou apenas quando absolutamente necessário?

Balanceamento tolerante a falhas entre dois data centers - como?



Arquitetura de segurança, interação com sistemas legados - existem diferenças em relação às nuvens públicas. É possível recomendar a construção de sistemas para que haja a possibilidade de migração para nuvens públicas, mas isso vai complicar a solução.



O planejamento, alocação e propriedade de recursos para nuvens públicas e privadas diferem pouco. A principal diferença é a quantidade limitada de recursos. Se em nuvens públicas for possível, a qualquer momento, obter recursos adicionais necessários, por exemplo, para teste de carga, então no local deve planejar cuidadosamente a sequência de seu uso. Isto significa que poderá ter lançamentos nocturnos e, consequentemente, o trabalho dos colaboradores das 2ª e 3ª linhas aumentará em horários inoportunos. Nada de novo para quem está sozinho, mas um sabor amargo de decepção pelos milagres que aguardam a adoção da nuvem privada.



"Os quadros decidem tudo"







Ao planejar a implementação de uma plataforma de conteinerização local, em primeiro lugar, são necessários especialistas com competências únicas. Claramente, eles não são suficientes no mercado de trabalho atual. Além disso, sem ter experiência em tal implementação, é difícil até fazer uma lista de todos os especialistas necessários.



Por exemplo, para que a plataforma funcione, você precisa selecionar e instalar um sistema de armazenamento. Seja qual for o sistema que você escolher (CEPH ou Portworx), será fundamental para a plataforma. Todos sabem que um administrador é obrigado a manter um banco de dados. Da mesma forma, um sistema de armazenamento de dados precisa de um especialista separado. Infelizmente, ninguém pensa sobre isso antes de implementar o sistema! Observe que a diferença entre administradores para produtos diferentes é significativa - comparável à diferença entre DBA Oracle e DBA MS SQL. Você precisará de pelo menos duas pessoas para cada função: funcionários saem de férias, adoecem e até, Deus me livre, pedem demissão. E assim por diante, para cada competência, e a lista de competências necessárias para dar suporte à solução é impressionante.



Gostaria de alertar imediatamente contra as tentativas de cruzar todas as competências em alguns soldados universais. Seu custo, raridade e riscos de perda excedem todos os limites razoáveis.



Mais uma vez, a manutenção da nuvem é um processo complexo. As empresas da nuvem não comem o pão à toa: ali, por trás da neblina nebulosa, há muita tecnologia e mão de obra investida.



Claro, o uso de serviços de consultoria pode acelerar significativamente a implementação da plataforma. Parceiros experientes irão ajudá-lo a evitar muitos erros, estabelecer processos e treinar sua equipe. No entanto, se você hospedar serviços essenciais para seu negócio na plataforma, é igualmente importante fornecer suporte e desenvolvimento de qualidade. Além disso, no momento, todos os sistemas existentes no mercado estão em desenvolvimento ativo, novas tecnologias aparecem, novas versões da plataforma podem exigir a migração de processos complexos e testes sérios antes da atualização. Uma forte equipe de suporte é necessária para garantir a operação confiável do sistema. E você precisará de uma equipe assim continuamente.



Quando você deve considerar a implementação de uma plataforma de conteinerização local?



Em primeiro lugar, é necessário avaliar a relação entre investimento e retorno, o volume de custos com hardware e funcionários. Deve haver boas razões para não poder viver em nuvens públicas ou requisitos de recursos realmente sérios. Ou seja, se cerca de 100 núcleos é o suficiente para uma organização e você não está pronto para expandir a equipe de suporte para dezenas de pessoas, provavelmente você deve se concentrar em nuvens públicas ou em configurações simples com servidores de aplicativos. É necessário um tamanho mínimo de equipe para dar suporte à plataforma e o custo pode não compensar. No entanto, com recursos de escala e automação competente de todos os processos, o benefício de uma solução privada pode ser muito significativo. Muitas centenas de nós podem ser mantidos praticamente com o mesmo comando.



Outro critério de seleção é a variabilidade das necessidades de recursos computacionais. Se os processos de negócios de uma empresa criam uma carga mais ou menos uniforme de recursos, é mais lucrativo desenvolver sua própria infraestrutura. Se você precisa usar grandes capacidades, mas raramente, considere nuvens públicas ou híbridas.



De qualquer forma, na hora de escolher soluções on-premise, fique atento ao trabalho sério e sistemático, prepare-se para investir na equipe. Vá do simples ao complexo. Esteja atento ao tempo de implementação e seja especialmente cuidadoso ao atualizar para novas versões da plataforma. Use a experiência adquirida com os erros dos outros, não os seus.



Obrigado por ler este artigo, esperamos que as informações sejam úteis.



All Articles