Todos os seus ambientes pertencem a nós!

O que o Couchbase certifica

As plataformas Commodity Cloud são usadas pela equipe do Operador Autônomo do Couchbase para testar o funcionamento de tudo. Essas plataformas são aproveitadas devido à onipresença no ecossistema Kubernetes e à sua capacidade de serem provisionadas e desprovisionadas de maneira simples e genérica. Amazon EKS, Google GKE, Microsoft AKS e Red Hat OpenShift (no AWS) são nossas principais combinações. Essas plataformas são, em sua maioria, prontamente capazes de serem criadas sob demanda com tecnologias genéricas como HashiCorp Terraform.

Um pequeno subconjunto, não?

A resposta curta é sim e não. Por um lado, a certificação dessas quatro grandes plataformas abrange 99% de usuários (um número inventado!). Isso nos dá a melhor relação custo-benefício de uma perspectiva puramente comercial, pois os testes não são gratuitos, tanto em termos de tempo quanto de dinheiro.

Por outro lado, dezenas de fornecedores de plataformas diferentes podem ser usados, todos certificados sob o guarda-chuva do Programa de conformidade de software CNCF. A conformidade com o Kubernetes garante que um pod será um pod e se comportará como um pod onde quer que seja executado, quebrando assim a dependência do fornecedor a um certo grau. De fato, dadas essas restrições e se o Operador estiver usando apenas recursos genéricos, há um alto grau de certeza de que o Operador será executado em qualquer uma dessas plataformas sem necessidade de modificação.

Portanto, a autocertificação não é necessária, certo?

Errado. Quando eu disse "até certo ponto" anteriormente, foi proposital. Embora o núcleo do Kubernetes seja bem definido em termos de formato e comportamento, algumas partes podem ser personalizadas para uma plataforma específica, ou seja, armazenamento e rede, ambos fundamentais para a operação de um banco de dados distribuído.

Portanto, é compreensível que os usuários finais queiram que sua plataforma específica seja certificada para operação com o Couchbase. No passado, nós nos esforçamos para certificar as plataformas quando solicitado. Para algumas plataformas, como o Rancher, isso é simples. Suponhamos que tenhamos que lidar com um dispositivo de armazenamento de $1.000.000. Nesse caso, é financeiramente inviável e requer um data center, servidores, switches, roteadores, energia, refrigeração etc. Obviamente, não é uma solução prática e dimensionável. Isso é particularmente grave quando sua plataforma é um navio!

Apresentando a autocertificação

A autocertificação é a resposta para todos os problemas com a certificação de plataformas. Analisando o problema, se fôssemos certificar o Acme Cloud, provisionaríamos o Kubernetes nele e, em seguida, executaríamos nosso conjunto de testes usando APIs nativas.

A próxima etapa lógica é pegar esse conjunto de testes e empacotá-lo como um contêiner para qualquer pessoa em qualquer plataforma Kubernetes. Isso é tudo; o que estamos fornecendo a você é o que usamos internamente para todos os nossos esforços de certificação. Certificação distribuída!

De forma anedótica, não foi que fácil. Tivemos que mudar fundamentalmente o modelo de rede (tornando-o mais simples e mais rápido no processo). Também tivemos que tomar cuidado com a utilização da memória, já que o Kubernetes é uma plataforma com restrição de memória.

Então, o que ele faz?

A experiência me ensinou que, embora a maioria das pessoas deve É da natureza dos engenheiros de computação analisar as coisas e fazer muitas (muitas?) perguntas, portanto, serei franco. Esse produto pode não atender a todas as necessidades de todo o público-alvo.

Em um nível fundamental, a autocertificação executa um pod do Kubernetes que executa os testes e armazena os resultados em um volume persistente. Os resultados são extraídos do Kubernetes para serem enviados ao Couchbase para aceitação.

Infelizmente, as permissões necessárias são bastante intrusivas, portanto, aqui é onde a autocertificação pode não funcionar para você. O teste exigirá a criação e a exclusão de recursos com escopo de cluster, como namespaces, definições de recursos personalizados, funções e associações de funções. Por esse motivo, recomendamos que essa ferramenta seja executada em um cluster Kubernetes descartável e que não seja de produção.

Certificação de execução

Com o Couchbase Autonomous Operator 2.3, reunimos todas as ferramentas existentes em uma única ferramenta para governar todas elas. É aqui que reside o comando de certificação. As ferramentas estão disponíveis na seção Página da Web de downloads do Couchbase. 

Sua execução é tão simples quanto a linha de comando:

Talvez você queira revisar o documentação para ver se algum sinalizador precisa ser substituído em seu ambiente específico.

Fase de teste pré-voo

As primeiras verificações que os testes realizarão são uma verificação geral da integridade do cluster do Kubernetes:

A primeira verificação é dos limites de recursos da plataforma, conforme especificado pelo Guia de instalação não raiz do Couchbase Server. Já vimos casos no passado, especialmente com o CoreOS, em que o número de processos é definido como baixo (1024) e o Couchbase Server não consegue iniciar. A detecção precoce desses erros permite que o usuário faça o autoatendimento como um benefício adicional.

Verificação dos recursos de memória e CPU

Em seguida, são verificados os recursos de memória e CPU da plataforma. Os Requisitos de sistema do Couchbase Server definem os tamanhos mínimos de recursos necessários para uma única instância do Couchbase Server. Os testes em si serão executados com o recurso de reserva automática de memória ativado, facilitando assim a depuração de problemas de agendamento.

Por fim, são examinados os totais gerais de memória e CPU. Em resumo, a autocertificação executa testes em paralelo. Conhecendo o nível de simultaneidade e os requisitos do Couchbase Server, podemos adivinhar quantos recursos são necessários para executar o teste. O cálculo completo está documentado na seção Documentação dos conceitos de autocertificação.

Fase de configuração

O próximo passo é a configuração do cluster do Kubernetes. Isso faz tarefas de configuração únicas, como instalar as definições de recursos personalizados, o controlador de admissão dinâmica e quaisquer outras operações de limpeza da plataforma:

Fase de teste

Já mencionamos isso: os testes são executados em paralelo. Se todos os testes fossem executados um após o outro, o tempo necessário para executar tudo se estenderia por dias. Com a concorrência, podemos fazer isso em 3 a 4 horas!

Os mestres Jedi da nuvem sabem que tratar qualquer coisa como um floco de neve especial é "fazer errado". Ao se preparar para um desastre e presumir que as coisas precisarão ser recriadas do zero, você estará pronto e funcionando novamente em pouco tempo, enquanto outras pessoas entram em pânico tentando consertar as coisas e interagir com as organizações de suporte.

Dessa forma, em vez de gerenciar o desmembramento de recursos, os testes usam namespaces do Kubernetes. Cada teste obtém um namespace e cria recursos somente nesse namespace. Quando o teste é concluído, o namespace é excluído e todos os recursos são automaticamente recuperados.

Os testes geralmente fazem algumas coisas para garantir isso:

    • as APIs do Kubernetes funcionam conforme desejado
    • nossos recursos personalizados se comportam corretamente
    • trabalhos com ferramentas
    • o Operador toma as medidas corretas durante as atualizações e os cenários de recuperação
    • O Couchbase Server se comporta de forma consistente em todas as versões

O que você executa como usuário final será um subconjunto de testes que abrange a grande maioria de todas as funcionalidades suportadas.

Fase de resultados

Quando todos os testes tiverem sido executados até o fim, o conjunto de autocertificação exibirá um resumo dos resultados:

Quanto menos falhas, melhor! Como em todas as coisas, alguns testes estão sujeitos a condições de corrida inevitáveis. Mostrei isso como exemplo, mas o que você executará será uma versão reduzida, na qual somente testes estáveis e previsíveis serão incluídos. Ignorado são normalmente aqueles que não podem ser executados devido aos recursos da plataforma que está sendo testada ou a determinadas combinações de parâmetros.

Um segundo pod será criado, montando um volume persistente, e o arquivo de resultados será copiado. Esse pod terá um nome semelhante a couchbase-operator-certification-20060102T150405-0700.tar.bz2 e contêm o resumo dos resultados do teste e todos os registros relacionados a testes com falha usados para depurar problemas.

Fase de certificação

Embora você possa ver uma taxa de aprovação na 100% e queira continuar, isso ainda não acabou. Esperamos que todos os resultados da autocertificação sejam enviado ao Couchbase para aprovação. Isso nos dá uma visão de quais plataformas de Kubernetes, armazenamento e rede estão sendo usadas por nossos usuários finais. Com essas informações, podemos anunciar essas plataformas como experimentadas e testadas e evitar a duplicação de esforços.

Mesmo que você tenha algumas falhas, isso não é necessariamente um obstáculo para a aceitação da certificação. Pode ser que determinados recursos não sejam compatíveis com plataformas específicas. Podemos usar essas informações para anunciar isso a outros usuários e atualizar a imagem do contêiner de autocertificação e ignorar esses testes em determinadas circunstâncias, facilitando o processo para todos.

Resumo

A autocertificação do operador é um divisor de águas para nós. Ela nos ajuda a acessar e oferecer suporte aos usuários do Couchbase em uma variedade maior de plataformas. Usando uma abordagem colaborativa, podemos compartilhar o ônus e divulgar a aceitação para um público ainda maior.

Estamos ansiosos para ver seus resultados e ouvir seus comentários.

Faça o acompanhamento acessando os recursos mencionados no artigo:

Autor

Postado por Simon Murray, engenheiro de software sênior, Couchbase

Simon tem quase 20 anos de experiência em diversos tópicos, como programação de sistemas, desempenho de aplicativos e armazenamento em escala. A nuvem é agora seu foco atual, especializando-se em arquitetura de rede corporativa, segurança da informação e orquestração de plataformas em uma ampla gama de tecnologias.

Todas as publicações

Deixar uma resposta