Temos o prazer de anunciar o lançamento do Couchbase Autonomous Operator 1.2. Este é um lançamento histórico que marca vários recursos solicitados pelos clientes, principalmente
- Upgrade automatizado de clusters do Couchbase
- Validação integrada de recursos do CouchbaseCluster por meio do controlador de administração
- Suporte do leme
- Conectividade pública para clientes do Couchbase
- Atualização contínua de clusters do Kubernetes
- Rotação de certificados TLS x509
- Experiência unificada de coleta de registros para implementações com e sem estado
-
Suporte para serviços públicos do Kubernetes no GKE, AKS e EKS. O Kubernetes em execução na nuvem pública já estava funcionando desde o primeiro dia, mas com o Autonomous Operator 1.2, estamos oferecendo suporte oficial a ele. Para a perspectiva deste blog, usaremos o GKE para configurar o cluster do Kubernetes no GKE com a versão 1.12, depois implantaremos o Autonomous Operator e, por fim, implantaremos o Couchbase Cluster com Server Groups, com volumes persistentes e com certificados x509 TLS.
As etapas gerais que faremos neste blog são as seguintes:
-
Inicializar os utilitários do gcloud
-
Implante o cluster do Kubernetes (v1.12+) com 2 nós em cada zona de disponibilidade
-
Implante o Operador Autônomo 1.2
-
Implantar o cluster do Couchbase
-
Executar o Autofailover do grupo de servidores
Pré-requisitos
- kubectl (Os componentes do gcloud instalam o kubectl)
- Conta GCP com as credenciais corretas
Inicializar os utilitários do gcloud
Faça o download do sdk do gcloud para a versão do sistema operacional de sua escolha a partir deste URL.
É preciso ter credenciais do Google Cloud para inicializar o cli do gcloud
|
1 2 3 |
cd google-nuvem-sdk ./instalar.sh ./caixa/nuvem inicial |
Implante o cluster do Kubernetes (v1.12) com 2 nós em cada zona de disponibilidade
Implantar o cluster do Kubernetes no GKE é uma tarefa bastante simples. Para implantar clusters kubernetes resilientes, é uma boa ideia implantar nós em todas as zonas disponíveis em uma determinada região. Fazendo isso dessa forma, podemos usar o recurso de reconhecimento de Grupos de servidores ou Zona de rack ou Zona de disponibilidade (AZ) no servidor Couchbase, o que significa que, se perdermos toda a AZ, o couchbase poderá fazer failover de toda a AZ e o aplicativo ficará ativo, pois ainda tem o conjunto de dados em funcionamento.
|
1 |
nuvem contêiner agrupamentos criar rd-k8s-gke --região nós-leste1 --máquina-tipo n1-padrão-16 --num-nós 2 |
|
1 2 3 4 |
Detalhes sobre acima comando K8s agrupamento nome : rd-k8s-gke máquina-tipo: n1-padrão-16 (16 vCPUs e 60 GB RAM) num-nós/AZ : 2 |
Mais tipos de máquinas podem ser aqui
Nesse momento, o cluster do k8s com o número necessário de nós deve estar em funcionamento
|
1 2 3 |
$ nuvem contêiner agrupamentos lista NOME LOCALIZAÇÃO VERSÃO PRINCIPAL MASTER_IP TIPO DE MÁQUINA VERSÃO DO NÓ <forte>NUM_NODES</forte> STATUS rd-k8s-gke nós-leste1 1.12.6-gke.10 35.229.24.36 n1-padrão-16 1.12.6-gke.10 <forte>6</forte> CORRIDA |
Os detalhes do cluster k8s podem ser encontrados abaixo
|
1 2 3 4 5 6 |
$ kubectl agrupamento-informações Kubernetes mestre é em execução em https://55.229.24.36 GLBCDefaultBackend é em execução em https://55.229.24.36/api/v1/namespaces/kube-system/services/default-http-backend:http/proxy Heapster é em execução em https://55.229.24.36/api/v1/namespaces/kube-system/services/heapster/proxy KubeDNS é em execução em https://55.229.24.36/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy Métricas-servidor é em execução em https://55.229.24.36/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy |
Implante o Operador Autônomo 1.2
O GKE é compatível com o RBAC para limitar as permissões. Como o Couchbase Operator cria recursos em nosso cluster do GKE, precisaremos conceder a ele a permissão para fazer isso.
|
1 |
$ kubectl criar aglutinação de papéis agrupamento-administrador-vinculação --papel de agrupamento agrupamento-administrador --usuário $(nuvem configuração obter-valor conta) |
Baixar o pacote apropriado para a implantação do kubernetes em seu ambiente. Descompacte o pacote e implemente o controlador de admissão.
|
1 |
$ kubectl criar -f admissão.yaml |
Verificar o status do controlador de admissão
|
1 2 3 |
$ kubectl obter implantações NOME DESEJADO ATUAL UP-PARA-DATA DISPONÍVEL IDADE couchbase-operador-admissão 1 1 1 1 7s |
Para visualizar como o controlador de admissão funciona em sincronia com o operador e o cluster do couchbase, ele pode ser melhor ilustrado com o diagrama a seguir
As próximas etapas são criar o crd, a função de operador e o operador 1.2
|
1 2 3 |
$ kubectl criar -f crd.yaml $ kubectl criar -f operador-função.yaml $ kubectl criar -f operador-implantação.yaml |
Quando o operador é implantado, ele fica pronto e disponível em segundos
|
1 2 3 4 |
$ kubectl obter implantações NOME DESEJADO ATUAL UP-PARA-DATA DISPONÍVEL IDADE couchbase-operador-admissão 1 1 1 1 11m couchbase-operador 1 1 1 1 25s |
Implantar o cluster do Couchbase
O cluster do Couchbase será implantado com os seguintes recursos
-
Certificados TLS
-
Grupos de servidores (cada grupo de servidores em uma AZ)
-
Volumes persistentes (que são compatíveis com AZ)
-
Auto-failover do grupo de servidores
Certificados TLS
É bastante fácil gerar certificados tls; as etapas detalhadas podem ser encontradas em aqui
Depois de implantados, os segredos tls podem ser encontrados com o comando kubectl secret, como abaixo
|
1 2 3 4 |
$ kubectl obter segredos NOME TIPO DADOS IDADE couchbase-operador-tls Opaco 1 1d couchbase-servidor-tls Opaco 2 1d |
Grupos de servidores
A configuração de grupos de servidores também é simples, o que será discutido nas seções a seguir quando implantarmos o arquivo yaml do cluster do couchbase.
Volumes persistentes
Os volumes persistentes oferecem uma maneira confiável de executar aplicativos com estado. Criá-los na nuvem pública é uma operação de um clique.
Primeiro, podemos verificar qual classe de armazenamento está disponível para uso
|
1 2 3 |
$ kubectl obter classe de armazenamento NOME PROVISOR IDADE padrão (padrão) kubernetes.io/gce-pd 1d |
Todos os nós de trabalho disponíveis no cluster do k8s devem ter rótulos de domínio de falha, como abaixo
|
1 2 3 4 5 6 7 |
$ kubectl obter nós -o yaml | grep zona falha-domínio.beta.kubernetes.io/zona: nós-leste1-b falha-domínio.beta.kubernetes.io/zona: nós-leste1-b falha-domínio.beta.kubernetes.io/zona: nós-leste1-d falha-domínio.beta.kubernetes.io/zona: nós-leste1-d falha-domínio.beta.kubernetes.io/zona: nós-leste1-c falha-domínio.beta.kubernetes.io/zona: nós-leste1-c |
OBSERVAÇÃO: não preciso adicionar nenhum rótulo de domínio de falha, o GKE adicionou automaticamente.
Criar PV para cada AZ
|
1 |
$ kubectl aplicar -f svrgp-pv.yaml |
O arquivo yaml svrgp-pv.yaml pode ser encontrado aqui.
Criar segredo para acessar a interface do usuário do couchbase
|
1 |
$ kubectl aplicar -f segredo.yaml |
Por fim, implemente o cluster do Couchbase com suporte a TLS, juntamente com os Grupos de Servidores (que são compatíveis com o AZ) e em volumes persistentes (que também são compatíveis com o AZ).
|
1 |
$ kubectl aplicar -f couchbase-persistente-tls-svrgps.yaml |
O arquivo yaml couchbase-persistent-tls-svrgps.yaml pode ser encontrado aqui
Aguarde alguns minutos e o cluster do couchbase será ativado e deverá ter a seguinte aparência
|
1 2 3 4 5 6 7 8 9 10 11 12 |
$ kubectl obter cápsulas NOME PRONTO STATUS RESTARTS IDADE cb-gke-demonstração-0000 1/1 Em execução 0 1d cb-gke-demonstração-0001 1/1 Em execução 0 1d cb-gke-demonstração-0002 1/1 Em execução 0 1d cb-gke-demonstração-0003 1/1 Em execução 0 1d cb-gke-demonstração-0004 1/1 Em execução 0 1d cb-gke-demonstração-0005 1/1 Em execução 0 1d cb-gke-demonstração-0006 1/1 Em execução 0 1d cb-gke-demonstração-0007 1/1 Em execução 0 1d couchbase-operador-6cbc476d4d-mjhx5 1/1 Em execução 0 1d couchbase-operador-admissão-6f97998f8c-cp2mp 1/1 Em execução 0 1d |
Uma verificação rápida das reivindicações de volumes persistentes pode ser feita da seguinte forma
|
1 |
$ kubectl obter pvc |
Para acessar a interface do usuário do cluster do Couchbase, podemos fazer o port-foward da porta 8091 de qualquer pod ou serviço em si, no laptop local ou na máquina local, ou ela pode ser exposta via lb.
|
1 |
$ kubectl porto-avançar serviço/cb-gke-demonstração-ui 8091:8091 |
encaminhamento de porta para qualquer pod, como abaixo
|
1 |
$ kubectl porto-avançar cb-gke-demonstração-0002 8091:8091 |
Nesse ponto, o servidor couchbase está em funcionamento e temos como acessá-lo.
Executar o Autofailover do grupo de servidores
Auto-failover do grupo de servidores
Quando um nó do cluster do couchbase falha, ele pode fazer o failover automático e, sem nenhuma intervenção do usuário, TODO o conjunto de trabalho está disponível, não é necessária nenhuma intervenção do usuário e o aplicativo não sofrerá tempo de inatividade.
Se o cluster do Couchbase estiver configurado para ser compatível com o Server Group (SG) ou AZ ou Rack Zone (RZ), mesmo que percamos todo o SG, os grupos de servidores inteiros sofrerão falha e o conjunto de trabalho estará disponível, não será necessária nenhuma intervenção do usuário e o aplicativo não sofrerá tempo de inatividade.
Para ter uma recuperação de desastres, o XDCR pode ser usado para replicar os dados do Couchbase para outro cluster do Couchbase. Isso ajuda no caso de perda de todo o data center ou região de origem, os aplicativos podem ser transferidos para o site remoto e não haverá tempo de inatividade.
Vamos remover o grupo de servidores. Antes disso, vamos ver como é o cluster
Exclua todos os pods no grupo us-east1-b. Depois que os pods forem excluídos, o cluster do Couchbase verá que os nós são 
O operador está constantemente observando a definição do cluster e verá que o grupo de servidores foi perdido, girará os 3 pods, restabelecerá as reivindicações nos PVs e executará a recuperação do nó delta e, por fim, executará a operação de rebalanceamento e o cluster estará saudável novamente. Tudo isso sem nenhuma intervenção do usuário.
Depois de algum tempo, o cluster está de volta e funcionando.
Nos registros do operador,
|
1 |
$ kubectl registros -f couchbase-operador-6cbc476d4d-mjhx5 |
podemos ver que o cluster é automaticamente reequilibrado.
Epílogo
A diferenciação sustentada é fundamental para nossa tecnologia. Adicionamos um grande número de recursos novos e de suporte. Com todos esses recursos de suporte de nível empresarial, eles permitem que o usuário final encontre os problemas mais rapidamente e ajudam a operacionalizar o Couchbase Operator em seus ambientes de maneira mais rápida e eficiente. Estamos muito animados com o lançamento, sinta-se à vontade para experimentar!
Referências:
https://docs.couchbase.com/operator/1.2/whats-new.html
https://www.couchbase.com/downloads
https://docs.couchbase.com/server/6.0/manage/manage-groups/manage-groups.html
Livro do operador autônomo do K8s de @AnilKumar
https://info.couchbase.com/rs/302-GJY-034/images/Kubernetes_ebook.pdf
https://docs.couchbase.com/operator/1.2/tls.html
Todos os arquivos yaml e arquivos de ajuda usados para este blog podem ser encontrados aqui
