Recentemente, anunciamos a última prévia do Operador autônomo do Couchbase (CAO) 2.0 beta. Este lançamento é uma atualização significativa do Couchbase Autonomous Operator. O Couchbase Autonomous Operator 2.0 apresenta vários novos recursos de nível empresarial com recursos totalmente autônomos - segurança, monitoramento, alta disponibilidade e capacidade de gerenciamento. Neste blog, examinaremos em detalhes como um deles funciona.
Coleção de métricas da Prometheus
O operador mais recente oferece integração nativa com o Couchbase Prometheus Exporter para coletar e expor as métricas do Couchbase Server. Essas métricas exportadas podem ser extraídas pelo Prometheus e, em seguida, visualizadas em ferramentas como o Grafana.
Descreveremos as etapas para implantar o cluster com o Couchbase Prometheus Exporter e analisaremos algumas das métricas por meio do Grafana. Esta será uma implantação simples de teste de cluster único e não detalhará todas as outras etapas necessárias para uma implantação em nível de produção.
Estaremos acompanhando de perto o Tutorial do Couchbase Autonomous Operator 2.0 Beta sobre a instalação no Amazon EKS.
Pré-requisitos
Presumo que você já tenha um Nuvem privada virtual da Amazon (VPC) a ser usado. Siga a documentação sobre Primeiros passos com o Amazon EKS e instale o seguinte:
- kubectl
- aws-iam-authenticator
- eksctl
- Pares de chaves do Amazon EC2
- Operador autônomo do Couchbase 2.0 Beta
Arquitetura de implantação
Uma rápida visão geral da arquitetura de nossa implantação.
Com base no diagrama acima:
1: Crie o cluster do Kubernetes no Amazon EKS. O cluster gerencia os recursos e serviços do Kubernetes.
2: Adicione recursos do Couchbase instalando as definições de recursos personalizados do Couchbase.
3: Instale o Operador Autônomo do Couchbase. Isso cria dois pods, o Operator e o Admission Controller no namespace Default.
4: implante um cluster do Couchbase de 3 nós no namespace padrão. Isso cria 3 pods, cada pod tem um contêiner do Couchbase 6.5.0 e um contêiner do Couchbase Metrics Exporter.
5: Crie um ServiceMonitor que informe ao Prometheus para monitorar um recurso de serviço que define os pontos de extremidade que o Prometheus coleta.
6: Criar um serviço definirá a porta que descrevemos em nosso ServiceMonitor anteriormente no namespace Default.
7: Adicione recursos do Prometheus instalando as definições de recursos personalizados do Prometheus.
8: Crie os pods do Prometheus/Grafana no namespace Monitoring.
Criar o cluster e configurar o kubectl
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 |
$ eksctl criar agrupamento \ --nome prasadCAO2 \ --região nós-leste-1 \ --zonas nós-leste-1a,nós-leste-1b,nós-leste-1c \ --nógrupo-nome padrão-trabalhadores \ --nó-tipo t3.médio \ --nós 3 \ --nós-min 1 \ --nós-máximo 4 \ --ssh-acesso \ --ssh-público-chave ~/couchbase-prasad.pub \ --gerenciado [ℹ] eksctl versão 0.16.0 [ℹ] usando região nós-leste-1 [ℹ] sub-redes para nós-leste-1a - público:192.168.0.0/19 privado:192.168.96.0/19 [ℹ] sub-redes para nós-leste-1b - público:192.168.32.0/19 privado:192.168.128.0/19 [ℹ] sub-redes para nós-leste-1c - público:192.168.64.0/19 privado:192.168.160.0/19 [ℹ] usando SSH público chave "/Users/krishna.doddi/couchbase-prasad.pub" como "eksctl-prasadCAO2-nodegroup-standard-workers-42:57:cd:cb:28:33:4a:d9:59:4e:73:3b:c0:e8:a3:fe" [ℹ] usando Kubernetes versão 1.14 [ℹ] criando EKS agrupamento "prasadCAO2" em "us-east-1" região com gerenciado nós [ℹ] vontade criar 2 separado Formação de nuvem pilhas para agrupamento em si e o inicial gerenciado nógrupo [ℹ] se você encontro qualquer problemas, verificar Formação de nuvem console ou tentar 'eksctl utils describe-stacks --region=us-east-1 --cluster=prasadCAO2' [ℹ] CloudWatch registro vontade não ser habilitado para agrupamento "prasadCAO2" em "us-east-1" [ℹ] você pode ativar ele com 'eksctl utils update-cluster-logging --region=us-east-1 --cluster=prasadCAO2' [ℹ] Kubernetes API ponto final acesso vontade uso padrão de {publicAccess=verdadeiro, privateAccess=falso} para agrupamento "prasadCAO2" em "us-east-1" [ℹ] 2 sequencial tarefas: { criar agrupamento controle avião "prasadCAO2", criar gerenciado nógrupo "trabalhadores padrão" } [ℹ] construção agrupamento pilha "eksctl-prasadCAO2-cluster" [ℹ] implantação pilha "eksctl-prasadCAO2-cluster" [ℹ] construção gerenciado nógrupo pilha "eksctl-prasadCAO2-nodegroup-standard-workers" [ℹ] implantação pilha "eksctl-prasadCAO2-nodegroup-standard-workers" [✔] todos EKS agrupamento recursos para "prasadCAO2" ter foram criado [✔] salvos kubeconfig como "/Users/krishna.doddi/.kube/config" [ℹ] nógrupo "trabalhadores padrão" tem 3 nó(s) [ℹ] nó "ip-192-168-13-207.ec2.internal" é pronto [ℹ] nó "ip-192-168-62-181.ec2.internal" é pronto [ℹ] nó "ip-192-168-93-184.ec2.internal" é pronto [ℹ] esperando para em menos 1 nó(s) para tornar-se pronto em "trabalhadores padrão" [ℹ] nógrupo "trabalhadores padrão" tem 3 nó(s) [ℹ] nó "ip-192-168-13-207.ec2.internal" é pronto [ℹ] nó "ip-192-168-62-181.ec2.internal" é pronto [ℹ] nó "ip-192-168-93-184.ec2.internal" é pronto [ℹ] kubectl comando deve trabalho com "/Users/krishna.doddi/.kube/config", tentar 'kubectl get nodes' [✔] EKS agrupamento "prasadCAO2" em "us-east-1" região é pronto |
|
1 2 3 4 5 6 7 8 9 10 11 12 |
$ kubectl obter serviço NOME TIPO CLUSTER-IP EXTERNO-IP PORTO(S) IDADE kubernetes ClusterIP 10.100.0.1 <nenhum> 443/TCP 15m $ kubectl obter nós NOME STATUS PAPÉIS IDADE VERSÃO ip-192-168-13-207.ec2.internal Pronto <nenhum> 4d4h v1.14.9-eks-1f0ca9 ip-192-168-62-181.ec2.internal Pronto <nenhum> 4d4h v1.14.9-eks-1f0ca9 ip-192-168-93-184.ec2.internal Pronto <nenhum> 4d4h v1.14.9-eks-1f0ca9 |
Configurar o kubectl
Esse comando é fundamental, pois define as variáveis relevantes do Amazon Resource Name (ARN) em ~/.kube/config. Opcionalmente, você pode adicionar --region regionName para especificar um cluster em uma região diferente da padrão. (Sua região padrão deve ter sido especificada quando você configurou a CLI do AWS pela primeira vez por meio de aws configurecomando).
|
1 2 3 |
$ aws eks atualização-kubeconfig --nome prasadCAO2 Adicionado novo contexto arn:aws:eks:nós-leste-1:429712224361:agrupamento/prasadCAO2 para /Usuários/krishna.doddi/.cubo/configuração |
Instalar as definições de recursos personalizados (CRD)
Observação: Fiz o download do Operator para MacOS, renomeei o pacote de couchbase-autonomous-operator-kubernetes_2.0.0-macos-x86_64 para cao-2 e cd'd nesse diretório.
A primeira etapa da instalação do Operator é instalar as definições de recursos personalizados (CRD) que descrevem os tipos de recursos do Couchbase.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
cao-2 $ kubectl criar -f crd.yaml definição de recursos personalizados.apiextensões.k8s.io/couchbasebuckets.couchbase.com criado definição de recursos personalizados.apiextensões.k8s.io/couchbaseephemeralbuckets.couchbase.com criado definição de recursos personalizados.apiextensões.k8s.io/couchbasemcachedbuckets.couchbase.com criado definição de recursos personalizados.apiextensões.k8s.io/couchbasereplications.couchbase.com criado definição de recursos personalizados.apiextensões.k8s.io/usuários do couchbase.couchbase.com criado definição de recursos personalizados.apiextensões.k8s.io/grupos de base de sofá.couchbase.com criado definição de recursos personalizados.apiextensões.k8s.io/sofá-base-rolo-ligações.couchbase.com criado definição de recursos personalizados.apiextensões.k8s.io/couchbaseclusters.couchbase.com criado definição de recursos personalizados.apiextensões.k8s.io/couchbasebackups.couchbase.com criado definição de recursos personalizados.apiextensões.k8s.io/couchbasebackuprestores.couchbase.com criado |
Instale o Operador Autônomo 2.0
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
cao-2 $ caixa/cbopcfg | kubectl criar -f - conta de serviço/couchbase-operador-admissão criado papel de agrupamento.rbac.autorização.k8s.io/couchbase-operador-admissão criado aglutinação de papéis.rbac.autorização.k8s.io/couchbase-operador-admissão criado segredo/couchbase-operador-admissão criado implantação.aplicativos/couchbase-operador-admissão criado serviço/couchbase-operador-admissão criado mutatingwebhookconfiguration.registro de admissão.k8s.io/couchbase-operador-admissão criado validando a configuração do webhook.registro de admissão.k8s.io/couchbase-operador-admissão criado conta de serviço/couchbase-operador criado função.rbac.autorização.k8s.io/couchbase-operador criado vinculação de função.rbac.autorização.k8s.io/couchbase-operador criado implantação.aplicativos/couchbase-operador criado serviço/couchbase-operador criado |
Verificar o status do Operador
|
1 2 3 4 5 |
cao-2 $ kubectl obter implantações NOME PRONTO UP-PARA-DATA DISPONÍVEL IDADE couchbase-operador 1/1 1 1 96s couchbase-operador-admissão 1/1 1 1 97s |
O Operator está pronto para implantar recursos do CouchbaseCluster quando as implantações do Dynamic Admission Controller (couchbase-operator-admission) e do Operator (couchbase-operator) estiverem totalmente prontas e disponíveis.
Preparar a configuração do cluster do Couchbase
Implantarei um cluster de 3 nós do Couchbase Server 6.5.0 com o Prometheus Couchbase Exporter. Para isso, criei meu-cluster.yaml no diretório atual. Este é apenas o meu exemplo. Aqui está o arquivo:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 |
Versão da API: v1 gentil: Secreto metadados: nome: cb-exemplo-autenticação tipo: Opaco dados: nome de usuário: QWRtaW5pc3RyYXRvcg== Administrador # senha: cGFzc3dvcmQ= Senha # --- Versão da API: couchbase.com/v2 gentil: CouchbaseCluster metadados: nome: cb-exemplo especificação: imagem: couchbase/servidor:6.5.0 segurança: adminSecret: cb-exemplo-autenticação pausado: falso antiafinidade: verdadeiro softwareUpdateNotifications: verdadeiro Grupos de servidores: - nós-leste-1a - nós-leste-1b - nós-leste-1c securityContext: runAsUser: 1000 runAsNonRoot: verdadeiro fsGroup: 1000 plataforma: aws agrupamento: clusterName: cb-exemplo DataServiceMemoryQuota: 512Mi indexServiceMemoryQuota: 256Mi searchServiceMemoryQuota: 256Mi indexStorageSetting: memória_otimizado autoFailoverTimeout: 120s autoFailoverMaxCount: 3 autoFailoverOnDataDiskIssues: verdadeiro autoFailoverOnDataDiskIssuesTimePeriod: 120s autoFailoverServerGroup: falso autoCompactação: databaseFragmentationThreshold: por cento: 30 tamanho: 1Gi viewFragmentationThreshold: por cento: 30 tamanho: 1Gi parallelCompaction: falso timeWindow: iniciar: 02:00 final: 06:00 abortCompactionOutsideWindow: verdadeiro tombstonePurgeInterval: 72h servidores: - tamanho: 3 nome: todos_serviços serviços: - dados - índice - consulta - pesquisa baldes: gerenciado: falso seletor: matchLabels: agrupamento: cb-exemplo monitoramento: prometeu: habilitado: verdadeiro imagem: couchbase/exportador:1.0.1 recursos: solicitações: CPU: 100m memória: 100Mi |
Observações:
- Usei apenas um conjunto mínimo de parâmetros de configuração. Consulte a seção Documentação do recurso de cluster do Couchbase para obter uma lista completa.
- Incluiu a seção de segredos no mesmo arquivo para manter as coisas simples.
- Utilizou apenas os serviços de dados, consulta, índice e pesquisa.
- Gerenciar meus próprios baldes em vez de deixar isso para o Operador.
- Anote o rótulo do cluster cb-exemplo pois isso será usado pelo Prometheus para descobrir o serviço posteriormente.
Dica: Certifique-se de que buckets.managed esteja definido como false. Caso contrário, se você criar um bucket manualmente quando o cluster estiver em funcionamento, o Kubernetes o descartará automaticamente.
Implantar o cluster do Couchbase
|
1 2 3 4 |
cao-2 $ kubectl criar -f meu-agrupamento.yaml segredo/cb-exemplo-autenticação criado conjunto de sofás.couchbase.com/cb-exemplo criado |
Tanto o segredo quanto o cluster são criados. Isso não significa que eles já estejam em funcionamento; para isso, você terá que verificar conforme descrito na próxima etapa.
Verificar a implantação
|
1 2 3 4 5 6 7 8 |
cao-2 $ kubectl obter cápsulas NOME PRONTO STATUS RESTARTS IDADE cb-exemplo-0000 2/2 Em execução 0 9m5s cb-exemplo-0001 2/2 Em execução 0 8m53s cb-exemplo-0002 2/2 Em execução 0 8m42s couchbase-operador-5c4bd54bbf-fcj9m 1/1 Em execução 0 10m couchbase-operador-admissão-6789cd5847-w9rfd 1/1 Em execução 0 10m |
Certifique-se de que todos os pods estejam Pronto e Em execução. Caso haja algum problema, você pode obter os registros do Operador.
Opcional: Obter os registros
Se você encontrar algum problema na etapa anterior, poderá verificar os registros conforme mostrado abaixo.
|
1 2 3 4 5 6 7 8 |
cao-2 $ kubectl registros couchbase-operador-5c4bd54bbf-fcj9m {"nível":"info","ts":1586879846.061044,"registrador":"principal","msg":"couchbase-operator","versão":"2.0.0","revisão":"release"} ...... {"nível":"info","ts":1586879986.2216492,"registrador":"cluster","msg":"Pod adicionado ao cluster","cluster":"default/cb-example","name" (nome):"cb-example-0002"} {"nível":"info","ts":1586879987.0798743,"registrador":"couchbaseutil","msg":"Rebalanceamento","cluster":"default/cb-example","progresso":0} {"nível":"info","ts":1586879993.087347,"registrador":"cluster","msg":"Rebalance completed successfully" (Rebalanceamento concluído com sucesso),"cluster":"default/cb-example"} {"nível":"info","ts":1586879993.124682,"registrador":"cluster","msg":"Reconciliação concluída","cluster":"default/cb-example"} |
Aqui, o cluster do Couchbase foi implantado sem nenhum erro.
Opcional: Examine um pod do Couchbase.
Vamos descrever um pod do Couchbase para verificar o que está sendo executado.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
cao-2 $ kubectl descrever cápsula cb-exemplo-0000 Nome: cb-exemplo-0000 Namespace: padrão ... Rótulos: aplicativo=couchbase cluster de base de sofá=cb-exemplo ... {"contêineres":[{"name" (nome):"couchbase-server","imagem":"couchbase/server:6.5.0","portas":[{"name" (nome):"admin","containerPort":8091,"protocolo":"TCP"} ... servidor.couchbase.com/versão: 6.5.0 Status: Em execução ... Controlado Por: CouchbaseCluster/cb-exemplo Contêineres: couchbase-servidor: Contêineres ID: doca://7b0e5df433582ad432114248fdce922fd92f63435b110265b823c013fea8c2ac Imagem: couchbase/servidor:6.5.0 ... Estado: Em execução ... métricas: Contêineres ID: doca://b4406ec41d2119978971c8fa41fb8077ace782611298ba23d254a0d4383ab5ca Imagem: couchbase/exportador:1.0.0 Imagem ID: ... Porto: 9091/TC ... Estado: Em execução |
Na saída acima, vemos que cada pod do Couchbase está executando 2 contêineres. O primeiro está executando o Couchbase Server 6.5.0 e o outro está executando o Couchbase Prometheus Exporter, que está usando a porta 9091.
Acessar a interface de administração do Couchbase
Em um ambiente de produção real, você normalmente implantaria usando o DNS e um LoadBalancer atuando como proxy e acessaria a interface do usuário do Couchbase de forma segura, com SSL usando registros DNS SRV. Como estamos em um ambiente de teste, acessaremos a interface do usuário do Couchbase diretamente da porta 8091. Precisamos de mais uma etapa para conseguir isso, que é o encaminhamento de porta.
Encaminhamento de portas
|
1 2 3 4 |
cao-2 $ kubectl porto-avançar cb-exemplo-0000 8091 & [1] 11375 cao-2 $ Encaminhamento de 127.0.0.1:8091 -> 8091 Encaminhamento de [::1]:8091 -> 8091 |
Agora implantamos três pods; no entanto, basta fazer o port forward de um pod para acessar a interface de usuário de administração do Couchbase.
Acessar a interface do usuário
http://localhost:8091
Criar os buckets
Adicione o bucket de amostra e crie o bucket de travesseiro
Executar uma carga de trabalho para gerar algumas métricas
Usaremos cbc-pillowfight para gerar a carga de trabalho. Felizmente, isso vem junto com o Operator e vamos implementá-lo. Vamos fazer uma pequena modificação no arquivo YAML primeiro, para que ele não pare de carregar os dados, mas execute operações no bucket. Usaremos o bucket de travesseiros que acabamos de criar.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
Versão da API: lote/v1 gentil: Emprego metadados: nome: briga de travesseiros especificação: modelo: metadados: nome: briga de travesseiros especificação: contêineres: - nome: briga de travesseiros imagem: sequoiatools/pillowfight:v5.0.1 comando: ["cbc-pillowfight", "-U", "couchbase://cb-example-0000.cb-example.default.svc/pillow?select_bucket=true", "-I", "10000", "-B", "1000", "-c", "10000", "-t", "1", "-u", "Administrador", "-P", "senha"] restartPolicy: Nunca |
Altere o bucket de padrão para pillow e altere a opção -c (número de loops) de 10 para 10.000.
Então:
|
1 2 |
cao-2 $ kubectl criar -f briga de travesseiros-dados-carregador.yaml trabalho.lote/briga de travesseiros criado |
Testando o Prometheus e o Grafana localmente
Agora temos um cluster do Couchbase de três nós com o Prometheus Couchbase Exporter. O Exporter está extraindo as métricas do Couchbase para a porta 9091. Agora, poderíamos encaminhar essa porta da mesma forma que encaminhamos a porta 8091 para acessar a interface do usuário do Console da Web do Couchbase em nosso desktop. Com essa porta encaminhada, poderíamos ter o Prometheus e o Grafana em execução em contêineres do Docker no desktop e usar a porta 9091 encaminhada para obter as métricas no Prometheus e visualizá-las no Grafana.
Com a abordagem acima, há uma limitação. A primeira é que teríamos que encaminhar a porta 9091 de todos os três nós e esses nomes de nós seriam codificados. A codificação de nomes de nós é um grande problema em um ambiente Kubernetes. Além disso, você realmente não faria o encaminhamento de portas em um ambiente de produção, onde normalmente faria a implantação com DNS e usaria o DNS SRV para se conectar ao cluster. Por fim, sua prática recomendada é executar o Prometheus e o Grafana no próprio Kubernetes, alinhando-se ao paradigma nativo da nuvem.
Próximas etapas
Em Parte 2Se você não tiver um DNS, faremos exatamente isso, com exceção do DNS, pois ainda queremos manter isso o mais simples possível para testes rápidos.
Recursos:
- Faça o download do Couchbase Autonomous Operator 2.0 Beta para Kubernetes
- Introdução ao Couchbase Autonomous Operator 2.0 Beta
- Tutorial - Operador autônomo do Couchbase no EKS
- Compartilhe suas ideias sobre o Fóruns do Couchbase
Obrigado, Prasad, por compartilhar. Posso perguntar quais são as principais métricas a serem monitoradas para decidir quando escalar o cluster e se é possível configurar o escalonamento automático do cluster couchbase no K8s?
Saudações