O Couchbase Autonomous Operator 1.0.0 foi lançado há apenas 8 meses. Em seguida, foi lançada a versão 1.1.0. Durante esse período, recebemos um enorme feedback da nossa comunidade de usuários. Antes de mais nada, agradeço a todos que ajudaram e continuam a moldar este produto.
A versão 1.2.0 do Operator é a primeira grande atualização e atende a um grande número de solicitações de alteração.
Este artigo analisa todas as principais novas funcionalidades e melhorias de usabilidade desta versão. As novas opções de rede e implementação (com o Helm) merecem suas próprias postagens. Os links são fornecidos na parte inferior da página.
Certificação em nuvem
O Kubernetes é mais do que apenas uma estrutura de implantação de aplicativos, é uma camada de abstração. A mudança entre provedores de nuvem, conforme a necessidade dos negócios, deve ser simples e econômica. Como diz o velho ditado "não guarde todos os seus ovos em uma única cesta", é realmente prudente adotar uma estratégia de implantação em várias nuvens. O Kubernetes é o meio perfeito para facilitar isso.
No entanto, existem diferenças sutis entre os provedores de nuvem. O armazenamento e a rede são os principais infratores. Onde há diferenças, há incerteza e imprevisibilidade.
A versão Operator 1.2.0 é a primeira a ser totalmente certificada no Amazon EKS, Google GKE e Microsoft Azure AKS. Nosso conjunto interno de testes de regressão agora é o primeiro na nuvem. Todos os testes serão executados nessas plataformas principais. Isso proporciona a nós e aos nossos clientes a confiança de que o Operator será executado de forma previsível e confiável em qualquer ambiente, independentemente das diferenças que existem entre os provedores de nuvem.
Para obter mais informações sobre a execução em ambientes de nuvem, consulte o guias de início rápido.
Melhorias no armazenamento
As plataformas Kubernetes suportadas pelo Operador também foram expandidas para abranger as versões 1.11 a 1.13 e 3.11 para Redhat Openshift.
Antes do Kubernetes 1.12, era preciso ter muito cuidado com o agendamento de volumes persistentes entre zonas de disponibilidade. Não havia nenhuma inteligência no agendamento, portanto, era possível ter um volume persistente criado em uma zona de disponibilidade enquanto um pod que tentava acessar esse volume seria criado em uma zona de disponibilidade diferente. Isso não funcionará, pois os volumes precisam existir no mesmo data center que seus consumidores.
Embora seja possível criar um cluster do Couchbase que leve em consideração essas restrições, essa mesma configuração é muito detalhada e difícil de entender e manter.
Um novo modo de encadernação de volumes - WaitForFirstConsumer - foi introduzido no Kubernetes 1.12 e pode ser aplicado a uma classe de armazenamento provisionada dinamicamente. Ao criar uma reivindicação de volume persistente, ele não cria o volume persistente subjacente imediatamente. Quando a reivindicação de volume persistente é anexada a um pod, então, e somente então, o volume persistente é criado na mesma zona de disponibilidade em que o pod está programado.
Nossa forte recomendação é usar uma versão do Kubernetes superior à 1.12 e provisionar seus clusters do Couchbase com esse novo modo de ligação preguiçosa. Os arquivos de configuração do cluster ficarão muito simplificados e mais fáceis de gerenciar e manter. Esse método de volume persistente é usado por todos os nossos testes internos, portanto, você pode ter certeza de que ele funciona para o seu caso de uso.
Atualização do Couchbase
O upgrade automatizado foi um dos recursos mais solicitados desde que o Operator foi lançado. Agora, ele é totalmente compatível com o Operator 1.2.0.
O processo de atualização segue nossas práticas recomendadas padrão para a execução manual desse procedimento. Um pod que executa a versão antiga da plataforma de dados do Couchbase é selecionado para upgrade e uma nova instância do Couchbase é criada. Um balanceamento de troca de alto desempenho move os dados existentes para o novo nó e o antigo é excluído. Isso continua até que todos os pods tenham atingido a versão de destino.
Operar dessa forma permite atualizações seguras e on-line sem degradação do desempenho ou interrupção do cliente.
Os caminhos de upgrade padrão são aplicados, portanto, um upgrade de versão pontual (5.5.3 para 5.5.4) e um upgrade de versão principal (5.5.3 para 6.0.1) são permitidos. Os upgrades que ignoram as versões principais (5.5.3 a 7.0.0) e os downgrades não são permitidos e são rejeitados.
As reversões são permitidas no meio de uma operação de atualização, mas somente para a versão original. Se estiver realizando uma atualização para a versão 6.0.1 a partir da 5.5.3 e 3 dos 8 pods tiverem sido atualizados, você poderá reverter para a 5.5.3.
O acionamento de uma atualização é realizado com a edição do arquivo spec.version em seu recurso personalizado do cluster do Couchbase.
Atualização do Kubernetes
Muitas plataformas de nuvem oferecem atualizações com um clique de todo o cluster do Kubernetes. Isso é perigoso para um aplicativo com estado, como a plataforma de dados Couchbase, e pode resultar em perda de dados. Para evitar esse cenário, a versão Operator 1.2.0 cria alguns recursos adicionais para gerenciar quando os pods podem ser eliminados de maneira segura. O cluster do Couchbase precisa ser atualizado primeiro para aproveitar esse recurso.
Para obter mais detalhes, leia nosso Artigo anterior sobre o tema.
Rotação e verificação de certificados TLS
O suporte a TLS é fornecido desde a versão 1.0.0 do Operator. Esse recurso permite que o administrador forneça uma cadeia de certificados curinga e uma chave privada a ser instalada na plataforma de dados do Couchbase pelo Operator, juntamente com um certificado CA raiz.
Embora isso não tenha mudado, agora oferecemos suporte à rotação de certificados de servidor ou até mesmo de toda a PKI. Isso fornece um mecanismo para lidar com a expiração de certificados ou o comprometimento de chaves privadas. O acionamento de uma operação de rotação requer uma atualização dos segredos TLS e o Operador cuidará do resto. Consulte nosso Documentação do TLS para obter mais detalhes.
O TLS não é fácil. Você precisa ter um bom conhecimento de rede e do padrão X.509 para fazê-lo funcionar, e vemos vários casos em que os clusters não conseguem provisionar devido à configuração incorreta do TLS. As mensagens de erro eram, na melhor das hipóteses, enigmáticas, por isso nos esforçamos para melhorar a experiência do usuário nessa área.
Agora, quando um cluster é criado, se houver um segredo TLS, o conteúdo será validado. Isso verifica se os certificados e as chaves estão no formato correto, se os certificados são válidos para esse cluster específico do Couchbase e para o namespace do Kubernetes, se o certificado do servidor é validado em relação à CA raiz etc. Tudo isso é informado ao usuário em uma mensagem simples e fácil de entender. Como isso é feito é explicado na próxima seção...
Controle dinâmico de admissão
A API do Kubernetes reportará erros em seus manifestos YAML para tipos de núcleo. Antes do Operator 1.2.0, empregávamos um esquema JSON associado ao tipo CouchbaseCluster definição de recurso personalizado para detectar erros simples de formatação. Para outras validações mais complexas específicas de uma implantação do Couchbase, distribuímos um binário separado para validar seu YAML.
Embora esse método tenha funcionado, ele pode não ter sido empregado pelos usuários finais. Ele certamente não se encaixava bem nos fluxos de trabalho existentes que usavam kubectl ou oc clientes. Com os controladores de admissão dinâmicos, podemos conectar essa validação profunda diretamente à API do Kubernetes.
Agora, quando você criar um cluster do Couchbase com kubectl, Por exemplo, a API passa a solicitação para um controlador de admissão dinâmico distribuído como parte do Operator 1.2.0. O controlador de admissão dinâmica pode então validar e modificar o recurso personalizado antes de responder se deve ou não admitir a solicitação. Se a solicitação for rejeitada, o motivo será retransmitido diretamente ao cliente. Ter que procurar nos arquivos de registro os motivos pelos quais a implementação não está funcionando é coisa do passado.
A modificação do recurso personalizado nos fornece um mecanismo pelo qual também podemos preencher automaticamente os novos campos exigidos pelo tipo de recurso personalizado. Isso ajuda a manter a compatibilidade com arquivos YAML antigos do cluster do Couchbase.
Para obter mais informações sobre como o controlador de admissão dinâmica funciona e é instalado, consulte A documentação.
Aprimoramentos de registro
Alguns aprimoramentos foram feitos em nossa ferramenta de suporte quando lançamos o Operator 1.1.0. Esses aprimoramentos foram feitos especificamente para lidar com o uso de volumes de registro quando usados com pods do Couchbase sem estado. A coleção de volumes de log apresentava ao usuário um menu interativo para permitir a seleção e o download local. Embora esse seja um acréscimo bem-vindo, ele era ortogonal à forma como os logs eram coletados dos pods em execução. Os logs de pods em execução eram coletados incondicionalmente e deixados no próprio pod, e o usuário final era responsável pelo download e pela limpeza.
Com a versão 1.2.0 do operador, todos os pods e volumes de log em execução são exibidos em um menu interativo unificado. O usuário pode selecionar exatamente quais logs devem ser coletados. A ferramenta de suporte agora também faz o download automático de todos os logs solicitados localmente e remove todos os arquivos intermediários dos pods em execução.
Também fornecemos a mesma funcionalidade por meio de sinalizadores da CLI para que os registros disponíveis possam ser pesquisados e a coleta automatizada. Para obter mais informações, consulte a seção Documentação do cbopinfo.
Quando o Operador tenta criar um pod e falha, excluímos esse pod e tentamos criá-lo novamente, caso o erro que causou a falha tenha sido transitório. No caso comum de a imagem do contêiner ter sido especificada incorretamente ou de o agendador não conseguir encontrar um nó para executar o pod, não tínhamos nada que indicasse que esse era o caso.
Na versão 1.2.0 do Operator, ampliamos os logs do Operator para atender a esses casos e permitir a determinação simples do problema. A criação de pods com falha acionará uma coleção do estado do pod e dos eventos associados e a saída para o fluxo de registro.
Kubernetes RBAC
O Operator funciona criando e manipulando recursos do Kubernetes. O Operador deve receber permissões para fazer isso. Nas versões anteriores à 1.2.0, dizíamos simplesmente "conceder todas as permissões nos pods", por exemplo. Embora conciso e fácil de entender, ele concedia privilégios ao Operador que não eram estritamente necessários para a operação.
A partir da versão 1.2.0 do Operator, qualquer exemplo de função do Kubernetes distribuída pelo Couchbase será explícita sobre exatamente quais operações são necessárias em quais tipos de recursos. Todas as permissões declaradas são necessárias, o Operator não pode funcionar sem elas. Para obter mais detalhes sobre quais permissões são necessárias e por quê, consulte a seção Documentação do RBAC.
A capacidade de o Operador funcionar com uma função, em vez de uma função de cluster, agora é totalmente suportada. As verificações anteriores de verificação e sanidade que exigiam acesso aos recursos do cluster agora são tratadas exclusivamente pelo controlador de admissão dinâmica.
Próximas etapas
O Couchbase Autonomous Operator 1.2.0 é uma grande versão com muitos recursos novos. Os principais focos são a capacidade de atualização e a facilidade de uso. Esperamos que você goste de fazer coisas novas e legais com ele tanto quanto nós gostamos de criá-lo. Como sempre, seu feedback é fundamental!
- Experimente: https://www.couchbase.com/downloads
- Fóruns de suporte: https://www.couchbase.com/forums/c/couchbase-server/Kubernetes
- Documentação: https://docs.couchbase.com/operator/1.2/whats-new.html
Leia mais
- Operador Autônomo 1.2.0 Rede: https://www.couchbase.com/blog/autonomous-operator-1-2-0-networking
