Não, eu não perdi a cabeça. Unicórnio é o nome de código interno do Couchbase Autonomous Operator 2.0.0. Para uma versão de escopo tão grande, queríamos algo mítico e fantástico para resumir o esforço e a paixão que foram dedicados a ela. Também é um pouco divertido dar à gerência uma plataforma onde eles possam ter para falar sobre unicórnios e duendes! Para enfatizar a dificuldade desta versão, vamos nos concentrar em um aspecto fundamental do Operador: Recursos personalizados do Kubernetes. Os recursos personalizados sustentam tudo o que o Operator faz.
Esta postagem faz parte de uma série de blogs técnicos que se aprofundam no funcionamento interno do Operator. Este blog se concentrará em ir de A para B. Parece simples, não é? (Ou vago...) Como você verá, não foi nada disso. Definiremos o que queremos dizer com isso, examinaremos os desafios técnicos e, finalmente, chegaremos ao motivo pelo qual decidimos fazer o que fizemos.
Da equipe de desenvolvimento para você - o usuário final -, esperamos que tenha uma experiência de uso tão boa quanto a que tivemos ao criá-lo.
A para B com CRDs?
Então, o que queremos dizer com isso? Primeiro, vamos ver por que precisamos de um B em primeiro lugar. O Operator 1.x gerencia os clusters do Couchbase com um único objeto de configuração, um recurso personalizado na terminologia do Kubernetes. Essa abordagem tem benefícios - tudo é controlado de forma centralizada -, mas também tem suas desvantagens - para fazer qualquer alteração no cluster, você tem acesso a todos os aspectos do cluster.
Gosto da primeira abordagem e digo isso à equipe o tempo todo:
No entanto, estamos fornecendo um serviço empresarial acima de tudo. A segurança precisa ser uma preocupação primordial - desde a camada de rede até os processos comerciais existentes durante a vida útil de um cluster.
Separação de preocupações
Um requisito comercial claro era que um usuário pudesse criar um bucket de dados privado e usá-lo. Esse mesmo usuário não deveria poder fazer mais nada. Esse mesmo usuário não deve ter a capacidade de fazer qualquer outra coisa. A capacidade de dimensionar o cluster não deve ser permitida, pois isso pode causar interrupções para outros usuários. Portanto, nossos objetivos eram:
- Definir funções no Kubernetes
- Os usuários podem gerenciar buckets e processar dados sem afetar outros usuários
- Os administradores podem modificar a topologia do cluster conforme a necessidade
Além de oferecer fortes garantias de segurança, as funções separam as preocupações. Os usuários finais só precisam saber como manipular documentos e executar consultas N1QL. As principais preocupações dos administradores são a conformidade com a segurança, a utilização de recursos e o custo. No entanto, há uma compensação. Limitar o conhecimento a domínios específicos também cria barreiras entre esses domínios. A solução precisa de flexibilidade para oferecer a capacidade de escolher onde Existem barreiras.
Decomposição de recursos personalizados
A chave para atingir nossos objetivos é o Kubernetes RBAC. O Kubernetes RBAC permite que usuários específicos realizem ações específicas em tipos de recursos específicos. Avançamos em direção ao nosso objetivo dividindo nosso recurso de cluster monolítico do Couchbase em tipos de recursos separados de cluster principal e de bucket. Cada tipo de recurso pode ter um conjunto separado de usuários que têm permissão para usá-los.
Outra consideração com a qual temos que lidar é como a capacidade de configurar um aspecto do cluster pode comprometer outro. O Operator 2.0 introduz o gerenciamento de XDCR (Cross Data Center Replication). Seria bom permitir que os usuários do bucket configurassem suas próprias estratégias de replicação. Para configurar uma replicação, você precisa se conectar a um cluster remoto. Isso requer credenciais que são configuradas com segredos do Kubernetes. Ao conceder a um usuário acesso aos segredos, você revela todas as senhas e chaves privadas de TLS no espaço de nomes.
Portanto, consideramos qualquer configuração que exige acesso a segredos como uma operação "somente para administradores". Isso ajuda a limitar o escopo entre os domínios de conhecimento da melhor forma possível.
Agregação de recursos personalizados
A configuração de um cluster do Couchbase agora está distribuída em muitos recursos diferentes. Eles são controlados por muitas pessoas diferentes com funções específicas. O Operador, no entanto, precisa ver o imagem completa para criar e gerenciar o cluster.
Por padrão, e sem culpa própria, o Operator 2.0 age de forma ingênua. Quando começa a monitorar um cluster do Couchbase, ele também monitora todos os recursos de bucket que encontra. Um único cluster lógico é criado a partir da agregação desses recursos de cluster e de bucket. Se você criar outro cluster, ele também encontrará e agregará os mesmos recursos de bucket. Talvez você não deseje esse comportamento, e o Kubernetes fornece o caminho novamente.
Para cada tipo de recurso que é agregado, há um seletor de rótulo correspondente que pode ser configurado. Esse seletor de rótulo permite que você controle exatamente quais recursos são agregados. Somente os recursos com os rótulos correspondentes serão selecionados pelo Operador.
A partida
Agora sabemos que decompor o recurso de cluster do Couchbase é uma coisa boa. Embora isso não seja isento de falhas, os benefícios superam essas falhas.
O Kubernetes fornece primitivas que nos ajudam a atingir nosso objetivo com RBAC e seleção de rótulos. Nossa jornada de A a B será fácil, certo? Pense de novo.
Restrições da plataforma
Em um mundo perfeito, o Operator seria executado em todas as versões do Kubernetes disponíveis. Isso é provavelmente verdadeiro para futuras versões do Kubernetes que mantenham a compatibilidade com versões anteriores. Eu digo provavelmente porque podem ser introduzidas extensões que são incompatíveis com um aplicativo escrito antes de seu lançamento. Por esse motivo, cada versão do Operator tem uma janela de versões certificadas do Kubernetes.
As versões certificadas do Kubernetes têm um limite superior e um limite inferior. Os limites estão fora de nossas mãos. Só podemos certificar se um fornecedor de nuvem oferecer suporte a uma determinada versão. No momento em que escrevo, o Google Kubernetes Engine (GKE) só permite as versões 1.14 e 1.15 do Kubernetes. O Operator é certificado no Amazon Elastic Kubernetes Service (EKS), no Microsoft Azure Kubernetes Service (AKS) e na Red Hat OpenShift Container Platform (OCP). Mais uma vez, estamos limitados pelo conjunto comum de versões do Kubernetes compatíveis com todos plataformas.
O limite inferior para o CAO 2.0.0 foi o Kubernetes 1.13.
Controle de versão de recursos personalizados
O Kubernetes 1.13 introduziu definições de recursos personalizados (CRDs) com controle de versão. Isso permite que o Kubernetes esteja ciente de vários formatos diferentes de recursos personalizados. Isso parece perfeito para nossas necessidades, mas o diabo está nos detalhes.
O controle de versão do CRD armazena apenas recursos como uma única versão. Quando definimos uma v1 e uma v2 de um tipo de recurso, todos os recursos são armazenados pelo Kubernetes como uma única versão, por exemplo, v2. Os ganchos de conversão de recursos personalizados fornecem uma maneira de converter o recurso v2 armazenado em v1, quando um cliente está acessando o recurso com a API v1. A conversão foi projetada para receber um recurso e retornar um recurso, realizando apenas operações simples. Para o Operador, a conversão entre uma configuração de cluster monolítico e modular é um passo muito grande.
Outra preocupação era que, com o Kubernetes 1.13, a conversão de CRD era um recurso de nível alfa. Sou fã de qualquer coisa que proporcione uma experiência de usuário (UX) mais perfeita. Os usuários, no entanto, são menos entusiasmados com a habilitação de recursos de grau alfa por meio da reconfiguração intrusiva da API do Kubernetes. Em geral, só começamos a usar os recursos quando eles são APIs geralmente disponíveis, normalmente no estágio beta.
O problema final era que o controle de versão do CRD no Kubernetes 1.13 suportava apenas um único esquema JSON. Isso significa que, quando instalado, um CRD de cluster do Couchbase v2 poderia oferecer suporte aos tipos de recursos personalizados v1 e v2, mas qualquer atualização de um recurso v1 falharia porque a validação em relação ao esquema único v2 falharia.
Nunca chove, chove muito
À primeira vista, parece que estamos presos. É impossível realizar uma boa ideia sem começar do zero. Não podemos usar a conversão CRD porque ela não está disponível e não foi projetada para o que queremos. Não podemos executar versões diferentes do Operador simultaneamente porque somente um único esquema é suportado. Mas eu sou britânico:
Se apenas uma única versão de um recurso personalizado for compatível, que assim seja, atualizaremos tudo de uma vez. O que deixa o processo de conversão.
Já estamos quase lá?
De fato, sim. A chave para o sucesso é simples. Leia um recurso antigo, v1, do cluster do Couchbase - isso não é validado - e, em seguida, escreva um novo recurso v2 do cluster do Couchbase e quaisquer recursos de bucket que ele exija - esses são validados.
Conforme mencionado anteriormente, a experiência do usuário é muito importante, por isso fornecemos um para realizar a conversão para você. Como era de se esperar, isso usa seletores de rótulos e é seguro. Nenhum novo recurso é ativado - todo novo recurso é opcional -, portanto, as configurações existentes do XDCR e do Couchbase RBAC não são afetadas pelo processo de atualização.
A chegada
Finalmente chegamos ao B! De alguma forma, em meio às adversidades, conseguimos passar de um modelo de configuração monolítico para um modelo de configuração modular. Conseguimos definir um processo de atualização on-line quase perfeito. Agora o poder está em suas mãos para explorar as possibilidades oferecidas pelo CAO 2.0.
Como sempre, vocês escolheram os rumos que tomamos e escolherão os rumos que tomaremos. Aguardamos seus comentários, sugestões e - ouso dizer - críticas!
O que importa é a jornada, não o destino
Passei um enorme tempo fazendo a documentação técnica para esta versão (e eu realmente espero que você aproveite). Em vez de um blog seco e excessivamente técnico, achei que uma mudança seria necessária, daí a analogia interminável. O que tenho me esforçado para expressar são todos os desafios técnicos e as compensações que nós, como equipe, enfrentamos para entregar esses marcos. O que pode parecer um novo recurso simples, do ponto de vista do marketing do produto, é muito mais complexo sob o capô (capô).
Ao realizar essas tarefas complicadas em seu nome - e ser franco sobre isso -, espero sinceramente que você aprecie o trabalho que é necessário. Espero que nossa história também tenha repercussão em outras pessoas. O Kubernetes só pode ficar melhor para todos à medida que essas ideias forem refinadas e incorporadas. Ainda temos um longo caminho a percorrer, mas obrigado por nos acompanhar nessa jornada.
Sua próxima viagem...
- Anúncio de lançamento do Couchbase Autonomous Operator 2.0.0
- Documentação técnica do Couchbase Autonomous Operator 2.0.0
