Introdução
Imagine que você está indo se encontrar com um cliente importante no centro de São Francisco, CA, e recebeu um e-mail com detalhes sobre para quem ligar quando chegar ao saguão do escritório. Você está no saguão, mas a recepção da rede móvel está totalmente inoperante. Você tenta abrir o cliente de e-mail, mas ele precisa de conexão de rede sempre que você inicia o aplicativo. Tenho certeza de que a incapacidade de ler o e-mail sem conectividade levará a uma experiência frustrante para o usuário.
Para evitar essas situações, os aplicativos agora são criados com o off-line primeiro paradigma. Isso significa simplesmente que a funcionalidade do aplicativo não é afetada pela falta intermitente de conectividade de rede. Além disso, o primeiro off-line geralmente implica a capacidade de sincronizar dados entre dispositivos de borda e o banco de dados de back-end.
Muitas soluções de banco de dados relacionais ou mesmo não relacionais tratam o celular e o backend como dois problemas separados, portanto, criar aplicativos off-line primeiro com essas soluções pontuais é praticamente impossível.
O Couchbase, por outro lado, é o principal fornecedor de uma solução de borda para a nuvem totalmente integrada. Couchbase Lite product é o banco de dados incorporado para os dispositivos de borda (onde você pode executar consultas declarativas localmente no dispositivo), Gateway de sincronização é a tecnologia de gel que permite a sincronização de dados dos dispositivos de borda com o Cluster do Couchbase.
Neste artigo, vamos nos concentrar na implantação do Couchabse Cluster e do Sync Gateway na plataforma Kubernetes. O objetivo é que você obtenha experiência em primeira mão trabalhando com essas tecnologias e entenda a mecânica por trás de cada uma delas.
Mais uma lição que eu gostaria que você tirasse deste artigo são algumas das práticas recomendadas ao implementar essa solução em sua própria nuvem privada ou pública.
Práticas recomendadas
Como ouço essas perguntas de muitos dos meus clientes corporativos, decidi abordá-las primeiro falando sobre algumas das práticas recomendadas quando se trata de implementar o Couchbase na plataforma Kubernetes.
- Sempre execute análise de dimensionamento do cluster do Couchbase primeiro, para planejar qual instância do EC2, tipos de dispositivos de armazenamento e espaço seriam necessários para o cluster. As estimativas de dimensionamento permanecem as mesmas para o cluster do Kubernetes, como seria feito para o cluster no local.
No entanto, lembre-se de que, no K8s, estamos fazendo o dimensionamento dos nós do Kubernetes, onde os pods do Couchbase serão executados. É aí que a segunda prática recomendada entra em cena. - Uso
spec.antiAffinity=trueem couchbase-cluster.yaml durante a implantação do cluster na produção. Esse campo especifica se dois pods nesse cluster podem ou não ser implantados no mesmo nó do Kubernetes. Do ponto de vista da alta disponibilidade, não queremos colocar mais de um pod em cada um dos nós do K8s, de modo que a falha de um único nó derrube apenas um único pod. - No ambiente Kubernetes, é aconselhável gerenciar o posicionamento de pods em tipos de nós predefinidos (grande, xlarge, 4xlarge etc.), de modo que os recursos desejados possam ser garantidos no momento da implantação do cluster ou da recuperação automática. Você pode usar
spec.servers[].pod.spec.nodeSelector(conforme mencionado em cluster couchbase.yaml), que especifica um mapa de valores-chave das restrições no posicionamento de nós para pods. Para que um pod seja elegível para execução em um nó, o nó deve ter cada um dos pares de valores-chave indicados como rótulos. - Uma última observação antes de começarmos a diversão: se o seu cluster K8s tiver nós homogêneos e você não quiser usar o
seletor de nópara determinar o posicionamento do pod e, em seguida, use o método spec.servers[].resources para definirsolicitaçõeselimites. Novamente, isso ajudará a colocar pods com um pool predefinido de recursos.
OBSERVAÇÃO: No exemplo abaixo, usaremos
nodeSelectorpara colocar os respectivos tipos de pod nogrupos de nóspara garantir os recursos desejados.
Pré-requisitos
Certifique-se de que você tenha uma conta AWS configurada (instruções fora do escopo deste blog) e que todas as ferramentas necessárias para experimentar essas instruções estejam prontas. Aqui está a lista de itens de que você precisa:
- Faça o download da versão mais recente Operador autônomo do Couchbase e descompacte-o no computador local. O pacote Operator contém ferramentas de linha de comando que você usará para instalar o Operator.
- Instalação e configuração kubectl em seu computador local - o kubectl é uma interface de linha de comando para executar comandos em clusters do Kubernetes.
- Instale a versão mais recente CLI DO AWS - A CLI da AWS é uma ferramenta unificada que permite interagir com os serviços da AWS usando comandos em seu shell de linha de comando. Neste caso, usaremos a CLI da AWS para nos comunicarmos de forma segura com o cluster do Kubernetes em execução na AWS.
Quando você tiver cli do aws com as credenciais da sua conta, você pode passar para a seção de criação de um cluster do Kubernetes.
Etapa 1: criar um cluster K8s com vários nós
O Kubernetes (K8s) nos oferece a flexibilidade de provisionar máquinas de computação de tamanhos diferentes (vCPU, RAM, tamanho do disco) em um único cluster do Kubernetes para que os requisitos de recursos de vários serviços gerenciados possam ser atendidos em um único cluster do K8s.
Vamos aproveitar a mesma flexibilidade e oferecer três NodeGroupsque usaremos posteriormente para hospedar um conjunto específico de serviços do Couchbase.
1.1. Crie um cluster EKS na região de sua escolha
Primeiro, vamos implantar um cluster K8s em us-west-2 região e em duas zonas de disponibilidade us-west-2a/b. Você pode mencionar um vpc-cidr de acordo com suas necessidades, mas, neste exemplo, usaremos o bloco 172.16.0.0/20fornecendo-nos um intervalo de mais de 4K (212) endereços IP, o que deve ser mais do que suficiente para nós.
$ eksctl create cluster --name k8sEKS \
--versão 1.18 \
--region us-west-2 \
--zonas us-west-2a,us-west-2b \
--vpc-cidr 172.16.0.0/20 \
--without-nodegroup1.2. Criar grupos de nós separados
Vamos criar nógrupo no cluster EKS para que possamos hospedar o Couchbase Dados instâncias de serviço. Neste exemplo, usaremos m5.large (2 vCPU e 8 GB de RAM) Máquinas EC2 como tipo de nómas o tamanho real do nó EC2 dependerá do planejamento da capacidade e do desempenho com base na sua carga de trabalho. Portanto, certifique-se de escolher o tipo certo de nós em sua implementação de produção.
$ eksctl create nodegroup --cluster=k8sEKS \
--name=m5l-pool \
--node-type m5.large \
--region us-west-2 \
--nodes 2 \
--nodes-min 2 \
--nodes-max 4 \
--node-ami autoPara hospedar Índice/Consulta criaremos um nodegroup separado com mais computação e RAM. Neste exemplo, usaremos r5.large (2 vCPUs e 16 GB de RAM) máquinas.
$ eksctl create nodegroup --cluster=k8sEKS \
--name=r5l-pool \
--node-type r5.large \
--region us-west-2 \
--nodes 2 \
--nodes-min 2 \
--nodes-max 4 \
--node-ami autoPor último, mas não menos importante, usaremos t2.xlarge (4 vCP e 16 GB de RAM) para hospedar Gateway de sincronização instância.
$ eksctl create nodegroup --cluster=k8sEKS \
--name=t2xl-pool \
--node-type t2.xlarge \
--region us-west-2 \
--nodes 1 \
--nodes-min 1 \
--nodes-max 2 \
--node-ami autoQuando os três grupos de nós estão prontos, podemos começar a rotular cada nó no nodegroup ou usar o rótulo pré-existente, mas primeiro confirme todos os grupos de nós estão prontos:
$ eksctl get nodegroups --cluster=k8sEKS --region=us-west-2
LUSTER NODEGROUP CREATED MIN SIZE MAX SIZE DESIRED CAPACITY INSTANCE TYPE IMAGE ID
k8sEKS m5l-pool 2020-07-24T18:58:02Z 2 4 2 m5.largeami-04387c277e83865b2
k8sEKS r5l-pool 2020-07-24T18:58:09Z 2 4 2 r5.largeami-04387c277e83865b2
k8sEKS t2xl-pool 2020-07-24T19:09:09Z 1 2 1 t2.xlargeami-04387c277e83865b21.3. Rotular nós EKS
Escolhemos três tipos diferentes de máquinas EC2 para hospedar dados, Índice/Consultae gateway de sincronização máquinas apenas para dedicar os serviços do Couchbase a uma nógrupo tipo. Vamos usar um rótulo existente chamado beta.kubernetes.io/instance-type para a seleção de nós. Esse rótulo estará disponível por padrão para que não seja necessário criar um novo rótulo. Você pode simplesmente ver os rótulos dos nós executando este cmd:
$ kubectl get nodes --show-labels
NOME STATUS ROLES IDADE VERSÃO RÓTULOS
ip-172-16-0-12.us-west-2.compute.internal Ready 21m v1.14.9-eks-a0a484 ...,beta.kubernetes.io/instance-type=t2.xlarge,...
ip-172-16-0-127.us-west-2.compute.internal Ready 32m v1.14.9-eks-a0a484 ...,beta.kubernetes.io/instance-type=m5.large,...
ip-172-16-3-234.us-west-2.compute.internal Ready 32m v1.14.9-eks-a0a484 ...,beta.kubernetes.io/instance-type=m5.large,...
ip-172-16-1-29.us-west-2.compute.internal Pronto 32m v1.14.9-eks-a0a484 ...,beta.kubernetes.io/instance-type=r5.large,...
ip-172-16-3-119.us-west-2.compute.internal Pronto 32m v1.14.9-eks-a0a484 ...,beta.kubernetes.io/instance-type=r5.large,...Neste exemplo, estaremos hospedando dados serviço em m5.large máquinas, índice/consulta em r5.large máquinas e gateway de sincronização em t2.xlarge máquina.
Em um ambiente de produção real, entendemos que você pode ter um tipo diferente de máquina, mas não essencialmente um tipo dedicado a um tipo específico de serviço do Couchbase. Nesse caso, você pode criar rótulos mutuamente exclusivos para cada tipo de nó.
Você usaria rótulo do kubectl cmd para rotular todos os nós que você deseja usar somente para nós de dados desta forma:
$ kubectl label nodes 'ec2-node-ip' instanceType=dataDa mesma forma para rotular todos os nós de índice (consulta ou outro):
$ kubectl label nodes 'ec2-node-ip' instanceType=indexDepois de rotular todos os nós, você estará pronto para passar para a próxima seção.
OBSERVAÇÃO: Estamos usando beta.kubernetes.io/instance-type como rótulo, portanto, não precisamos criar nenhum novo rótulo para os nós.
Etapa 2: Instalar a definição de recurso personalizado
A primeira etapa da instalação do Operator é instalar a definição de recurso personalizado (CRD) que descreve o Couchbase tipos de recursos. Isso pode ser feito executando o comando abaixo no diretório do pacote Operator:
kubectl create -f crd.yamlEtapa 3: Criar um espaço de nome
Os namespaces são uma forma de dividir os recursos do cluster entre vários usuários.
Os namespaces são uma forma de dividir os recursos do cluster entre vários usuários.
- Execute o seguinte comando para criar um namespace.
$ kubectl create namespace cbdb
namespace/cbdb criado- Confirme se o Namespace foi criado com sucesso.
$ kubectl get namespaces
NOME STATUS IDADE
cbdb Ativo 34s
default Ativo 5h20mEtapa 4: Instalar o operador
O operador é composto de dois componentes: um controlador de admissão dinâmico por cluster (DAC) e um Operador por espaço de nome. Consulte a seção arquitetura da operadora para obter informações adicionais sobre o que é necessário e considerações de segurança.
4.1. Instalar o controlador de admissão dinâmico (DAC)
O DAC permite que os recursos personalizados sejam modificados e interrogados antes que um recurso seja aceito e confirmado no etcd. A execução do DAC nos permite adicionar padrões sensatos às configurações do cluster do Couchbase, minimizando assim o tamanho das especificações. Ele também nos permite manter a compatibilidade com versões anteriores quando novos atributos são adicionados e precisam ser preenchidos. Isso torna a experiência de uso dos recursos do Couchbase semelhante à dos tipos de recursos nativos.
Vamos agora instalar o Dynamic Admission Controller.
- Abra uma janela do Terminal e vá para o diretório em que você descompactou o pacote Operator. Execute o seguinte comando para instalar o DAC no diretório
padrãonamespace.
$ bin/cbopcfg generate admission --namespace default | kubectl create -f -
serviceaccount/couchbase-operator-admission criado
clusterrole.rbac.authorization.k8s.io/couchbase-operator-admission criado
clusterrolebinding.rbac.authorization.k8s.io/couchbase-operator-admission criado
secret/couchbase-operator-admission criado
deployment.apps/couchbase-operator-admission criado
service/couchbase-operator-admission criado
mutatingwebhookconfiguration.admissionregistration.k8s.io/couchbase-operator-admission criado
validatingwebhookconfiguration.admissionregistration.k8s.io/couchbase-operator-admission criado- Confirme se o controlador de admissão foi implantado com êxito.
$ kubectl get deployments
NAME READY UP-TO-DATE AVAILABLE AGE
couchbase-operator-admission 1/1 1 1 48s4.2. Instalar o operador do Couchbase
Agora, vamos implementar o Operator no oficina executando o seguinte comando.
$ bin/cbopcfg generate operator --namespace cbdb | kubectl create -f -
serviceaccount/couchbase-operator criado
role.rbac.authorization.k8s.io/couchbase-operator criado
rolebinding.rbac.authorization.k8s.io/couchbase-operator criado
deployment.apps/couchbase-operator criado
service/couchbase-operator criadoA execução do comando acima faz o download da imagem do Operator Docker e cria um arquivo implantaçãoque gerencia uma única instância do Operator. O Operator usa uma implantação para que possa reiniciar o pod se ele morrer.
Depois de executar o kubectl create geralmente leva menos de um minuto para o Kubernetes implantar o Operator e para que ele esteja pronto para ser executado.
4.3. Verificar o status da implantação
Você pode usar o seguinte comando para verificar o status da implantação:
$ kubectl get deployments -n cbdb
NOME READY UP-TO-DATE AVAILABLE IDADE
couchbase-operator 1/1 1 1 1 73s4.4. Verificar o status do Operador
Execute o seguinte comando para verificar se o Operator foi iniciado com êxito:
$ kubectl get pods -l app=couchbase-operator -n cbdb
NOME READY STATUS RESTARTS AGE
couchbase-operator-558fd8486c-788jr 1/1 Executando 0 2m9sSe o Operator estiver ativo e em execução, o comando retornará uma saída em que o PRONTO shows de campo 1/1como, por exemplo:
Etapa 5. Implantar o cluster do Couchbase
Em um ambiente de produção em que o desempenho e o SLA do sistema são mais importantes, devemos sempre planejar a implantação do cluster do Couchbase usando volumes persistentes, pois isso ajuda:
- Recuperação de dados: Os volumes persistentes permitem que os dados associados aos pods sejam recuperados no caso de um pod ser encerrado. Isso ajuda a evitar a perda de dados e a construção demorada de índices ao usar serviços de dados ou de índices.
- Realocação de cápsulas: O Kubernetes pode decidir expulsar pods que atingem limites de recursos, como limites de CPU e memória. Os pods que têm backup com Volumes persistentes podem ser encerrados e reiniciados em nós diferentes sem incorrer em tempo de inatividade ou perda de dados.
- Provisionamento dinâmico: O Operator criará Persistent Volumes sob demanda à medida que seu cluster for dimensionado, aliviando a necessidade de pré-provisionar o armazenamento do cluster antes da implementação.
- Integração com a nuvem: O Kubernetes se integra aos provisionadores de armazenamento nativos disponíveis nos principais fornecedores de nuvem, como AWS e GCE.
5.1. Criar segredo para o console de administração do Couchbase
A primeira coisa que precisamos fazer é criar uma credencial secreta que será usada pelo console administrativo da Web durante o login. Por conveniência, um exemplo de segredo é fornecido no pacote Operator. Quando você o envia para o cluster do Kubernetes, o segredo define o nome de usuário como Administrator e a senha como password.
Para empurrar o secret.yaml em seu cluster do Kubernetes, execute o seguinte comando:
$ kubectl create -f secret.yaml -n cbdb
Secret/cb-admin-auth criado5.2 Criar classe de armazenamento para o cluster k8s
Para usar o PersistentVolume nos serviços do Couchbase (dados, índice, pesquisa etc.), precisamos criar classes de armazenamento (sc-nas.yaml). Execute o kubectl para criar uma nova classe de armazenamento baseada em SSD:
$ kubectl create -f sc-nas.yaml -n cbdb
storageclass.storage.k8s.io/nas criado5.3. Implantar o cluster do Couchbase
A especificação completa para implantar o cluster do Couchbase em 3 zonas diferentes usando volumes persistentes pode ser vista na seção couchbase-cluster.yaml . Esse arquivo, juntamente com outros arquivos YAML de amostra usados neste artigo, pode ser baixado deste repositório git.
Abra o arquivo YAML que você acabou de baixar e observe como estamos usando nodeSelector para colocar os pods nos nós que têm o valor específico de beta.kubernetes.io/instance-type etiqueta.
servidores:
- nome: data-service-2a
tamanho: 1
serviços:
- data
volumeMounts:
default: pvc-default # /opt/couchbase/var/lib/couchbase
dados: pvc-data # /mnt/data
pod:
spec:
nodeSelector:
beta.kubernetes.io/instance-type: m5.large
- nome: index-quer-service-2a
tamanho: 1
serviços:
- index
- consulta
volumeMounts:
default: pvc-default
índice: pvc-index
pod:
spec:
nodeSelector:
beta.kubernetes.io/instance-type: r5.largeAgora use kubectl para implantar o cluster, mas certifique-se de que esteja usando couchbase-cluster.yaml do git, e não o arquivo de mesmo nome presente no diretório de trabalho atual.
$ kubectl create -f couchbase-cluster.yaml -n cbdb --save-config
couchbasecluster.couchbase.com/cbdemo criadoIsso iniciará a implantação do cluster do Couchbase e, se tudo correr bem, teremos quatro pods do cluster do Couchbase hospedando os serviços de acordo com o arquivo de configuração acima. Para verificar o progresso, execute este comando, que observará (argumento -w) o progresso da criação dos pods:
$ kubectl get pods -n cbdb -w
NOME READY STATUS RESTARTS AGE
cbdemo-0000 0/1 Em execução 0 1m
cbdemo-0001 0/1 Em execução 0 53s
cbdemo-0002 0/1 Em execução 0 20s
couchbase-operator-558fd8486c-788jr 1/1 Em execução 0 21m
cbdemo-0003 0/1 Pendente 0 3s
cbdemo-0003 0/1 Pendente 0 3s
cbdemo-0003 0/1 ContainerCreating 0 3s
cbdemo-0003 0/1 Em execução 0 18s
cbdemo-0001 1/1 Em execução 0 2m
cbdemo-0000 1/1 Em execução 0 2m
cbdemo-0002 1/1 Em execução 0 1m
cbdemo-0003 1/1 Em execução 0 1mPara visualizar qual pod está sendo executado em qual nó, você pode executar:
$ kubectl get pods -owide -n cbdb
NOME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
cbdemo-0000 1/1 Em execução 0 10m 172.16.2.134 ip-172-16-3-234.us-west-2.compute.internal
cbdemo-0001 1/1 Executando 0 10m 172.16.1.116 ip-172-16-0-127.us-west-2.compute.internal
cbdemo-0002 1/1 Executando 0 9m51s 172.16.1.5 ip-172-16-1-29.us-west-2.compute.internal
cbdemo-0003 1/1 Executando 0 9m3s 172.16.2.98 ip-172-16-3-119.us-west-2.compute.internal
couchbase-operator-558fd8486c-r2tcc 1/1 Em execução 0 31m 172.16.1.230 ip-172-16-0-12.us-west-2.compute.internalVocê notaria que Índice/Consulta O serviço está sendo executado no pod cbdemo-0002 e cbdemo-0003 que é hospedado nos nós EKS com rótulo beta.kubernetes.io/instance-type: r5.large e dados pods de serviço (cbdemo-0000, cbdemo-0001) são colocados em nós EKS com rótulo beta.kubernetes.io/instance-type: m5.large. Isso significa que nodeSelector definido em couchbase-cluster.yaml aplicou com sucesso o posicionamento de pods nos nós com os recursos desejados.
Nesse ponto, você pode fazer o encaminhamento de porta da seguinte forma:
$ kubectl port-forward cbdemo-0000 18091:18091 -n cbdb
Encaminhamento de 127.0.0.1:18091 -> 18091
Encaminhamento de [::1]:18091 -> 18091E acesse o console da Web digitando https://localhost:18091 no navegador.
Etapa 6. Implantação de um cluster do Sync Gateway
Grande progresso até agora na implantação de um cluster do Couchbase com várias zonas e altamente disponível usando volumes de armazenamento persistentes. Agora, antes de começarmos a implementar o Sync Gateway, precisamos nos certificar de mais duas coisas:
6.1 Pré-requisitos do Sync Gateway
- Temos um bucket disponível no qual o aplicativo cliente e o Sync Gateway gravarão os dados. Ainda não temos nenhum bucket disponível para gravação, portanto, vamos criar um bucket
preparaçãodo balde doConsole da Web.
Figura 2: Preparação bucket criado com 2 GB de espaço.
OBSERVAÇÃO: Usamos 2 GB de RAM para esse bucket, mas no ambiente de produção você atribuiria a RAM com base nas estimativas de dimensionamento que você ou o arquiteto de soluções do Couchbase fizeram para o seu caso de uso comercial.
- Temos um usuário RBAC em vigor com o nome
Acesso a aplicativosno nível do balde.
Podemos simplesmente criar um Couchbase User como geralmente fazemos, mas para tornar isso um pouco mais interessante, vamos usar um externo (também conhecido como LDAP). Na seção couchbase-cluster.yaml você pode encontrar detalhes de um terceiro Servidor de teste LDAP que usamos neste exemplo.
segurança:
adminSecret: cb-admin-auth
rbac:
managed: false
ldap:
hosts:
- ldap.forumsys.com
port: 389
bindDN: "cn=read-only-admin,dc=example,dc=com"
bindSecret: cb-admin-auth
authenticationEnabled: true
userDNMapping:
template: "uid=%u,dc=example,dc=com"
authorizationEnabled: falseSe você quiser se conectar a um servidor LDAP diferente, basta atualizar ldap detalhes do servidor no couchbase-cluster.yaml e aplicar as alterações. Voltemos à criação de um usuário e à atribuição do nível de bucket Acesso a aplicativos função.
Figura 3: Usando newton como o usuário externo, que será automaticamente confirmado como existe.
Figura 4: Detalhes do usuário após clicar no botão Adicionar usuário botão.
Até agora, tudo bem. O usuário do Bucket e do RBAC está pronto, portanto, podemos prosseguir com a configuração do Gateway de sincronização.
6.2 Configuração do gateway de sincronização
Para que Gateway de sincronização Para nos comunicarmos com o Couchbase Cluster, precisamos fornecer detalhes do banco de dados, do bucket e da credencial. Usaremos o banco de dados string de conexão como couchbase://cbdemo-srv.cbdb.svc.cluster.local como pode ser visto no trecho abaixo:
...
},
"bancos de dados": {
"cbdemo": {
"servidor": "couchbase://cbdemo-srv.cbdb.svc.cluster.local",
"bucket": "staging",
"nome de usuário": "newton",
"password": "password",
"allow_conflicts": falso,
"revs_limit": 20,
"enable_shared_bucket_access": true,
"import_docs": true,
"sync": function(doc, oldDoc) {
channel(doc.channels);
},
}
...Uma coisa que eu gostaria de destacar é que, com Sync Gateway 2.7 (ou superior), os clientes corporativos agora podem designar vários nós do Sync Gateway como nós de importação (para lidar com as gravações do Couchbase Server), o que proporciona maior resiliência. Portanto, estamos usando import_docs: true no arquivo de configuração.
Você pode encontrar todos os outros atributos de configuração em sgw-config.yaml file. Usaremos esse arquivo para criar o segredo e salvar as configurações nele também.
$ kubectl create -f sgw-config.yaml -n cbdb --save-config
secret/sync-gateway criadoPara visualizar sgw-config executar secretamente o cmd abaixo:
$ kubectl get secret -n cbdb
NOME TIPO DADOS IDADE
cb-admin-auth Opaco 2 4h
couchbase-operator-token-p4qzb kubernetes.io/service-account-token 3 4h
default-token-x7cvw kubernetes.io/service-account-token 3 4h
sgw-config Opaco 1 30s6.3 Controlador de implantação
Depois de definir o segredo e a configuração, estamos quase prontos para implantar Gateway de sincronização em nosso cluster Kubernetes. Ajuste o réplicas e GOMAXPROCS com base em seus requisitos de produção, mas, neste exemplo, vamos implantar duas réplicas com um máximo de uma única vCPU por réplica.
apiVersion: apps/v1
Tipo: Deployment
metadados:
nome: sync-gateway
especificações:
réplicas: 2
selector:
matchLabels:
app: sync-gateway
template:
metadata:
labels:
app: sync-gateway
especificações:
containers:
- nome: sync-gateway
imagem: couchbase/sync-gateway:2.7.3-enterprise
volumeMounts:
- nome: config
mountPath: /etc/sync_gateway
readOnly: true
env:
- name: GOMAXPROCS
value: "1"
volumes:
- name: config
secret:
secretName: sync-gatewayImplementar sgw-deployment.yaml arquivo via kubectl cmd:
$ kubectl create -f sgw-deployment.yaml -n cbdb --save-config
deployment.extensions/sync-gateway criadoVocê pode visualizar o progresso da implantação executando:
$ kubectl get deployments sync-gateway -n cbdb
$ kubectl get deployments sync-gateway -n cbdb
NOME PRONTO ATUALIZADO DISPONÍVEL IDADE
sync-gateway 2/2 2 2 98sComo pode ser visto acima, as duas instâncias de réplica estão em funcionamento e agora só precisamos colocar um balanceador de carga na frente.
6.4 Implantar um balanceador de carga
Em uma implementação de produção, você provavelmente terá um ou mais nós do Sync Gateway liderados por um balanceador de carga.
Você implantará o balanceador de carga usando o Balanceador de carga do Kubernetes serviço. O serviço de balanceador de carga fornece um endereço IP acessível externamente e roteia o tráfego para as portas corretas no cluster.
- Crie um novo arquivo chamado sgw-lb.yaml com os seguintes atributos. Observe que estamos encaminhando tanto a 4984 (porta de acesso público) quanto a 4985 (porta de administração)
Tipo: Serviço
Versão da API: v1
metadados:
nome: sgw-lb
especificações:
type: LoadBalancer
selector:
app: sync-gateway
portas:
- nome: http
protocolo: TCP
port: 4984
targetPort: 4984
- nome: http2
protocolo: TCP
port: 4985
targetPort: 4985Observação Estamos encaminhando a 4984 (porta de acesso público) e a 4985 (porta de administração) por meio do balanceador de carga.
- Implante o balanceador de carga usando sgw-lb.yaml arquivo.
$ kubectl create -f sgw-lb.yaml -n cbdb
service/sgw-load-balancer criado- Verifique os pods que o balanceador de carga está direcionando.
Se tudo estiver implantado corretamente, você verá algo semelhante ao seguinte:
$ kubectl describe service sgw-load-balancer -n cbdb
Nome: sgw-load-balancer
Espaço de nome: cbdb
Etiquetas:
Anotações:
Seletor: app=sync-gateway
Tipo: LoadBalancer
IP: 10.100.106.138
Entrada do LoadBalancer: a8ce.us-west-2.elb.amazonaws.com
Port: 4984/TCP
TargetPort: 4984/TCP
NodePort: 31066/TCP
Pontos de extremidade: 172.16.11.2:4984, 172.16.11.3:4984
Afinidade de sessão: Nenhum
Política de tráfego externo: Cluster
Eventos:
Tipo Motivo Idade Da Mensagem
---- ------ ---- ---- -------
Normal EnsuringLoadBalancer 3m controlador de serviço Garantir o balanceador de carga
Normal EnsuredLoadBalancer 3m controlador de serviço Balanceador de carga garantidoAnote os Ingresso do LoadBalancer valor.
6.5 Teste a instalação
Quando o Load Balancer estiver on-line, poderemos confirmar a acessibilidade do cluster do Sync Gateway por meio de Ingresso do LoadBalancer (conforme mencionado na saída acima). Basta usar enrolar cmd:
curl https://a8ce.us-west-2.elb.amazonaws.com:4984Ele deve retornar o seguinte.
{"couchdb": "Welcome", "vendor":{"name": "Couchbase Sync \
Gateway", "version": "2.7"}, "version": "Couchbase Sync Gateway/2.7.3(3;33d352f) EE"}Pronto! O Sync Gateway está totalmente funcional e pronto para assumir a carga de trabalho do aplicativo cliente (via Couchbase Lite).
6.5.1 Teste de leitura/escrita de documentos
Em um blog separado, discutirei como é possível desenvolver aplicativos para os dispositivos de borda usando Couchbase Lite mas para testar a sanidade de nossa configuração de ponta a ponta, podemos executar rapidamente operações simples de POST e GET usando Gateway de sincronização API REST pública.
Vamos usar o comando curl para inserir alguns documentos:
$ curl -u admin:password -X POST "https://a8ce.us-west-2.elb.amazonaws.com:4984/cbdemo/" -H "accept: application/json" -H "Content-Type: application/json" -d "{\"id\":\"doc3\",\"channels\":\"newton\"}"
saída
{"id":"c4988cff19c632a724e13d4390b23b82","ok":true,"rev":"1-f99195111681fe7361b74eb5ebca23d4"}O primeiro documento foi inserido e a chave do documento foi gerada automaticamente como c4988cff19c632a724e13d4390b23b82.
$ curl -u admin:password -X POST "https://a8ce.us-west-2.elb.amazonaws.com:4984/cbdemo/" -H "accept: application/json" -H "Content-Type: application/json" -d "{\"id\":\"doc4\",\"channels\":\"newton\"}"
saída
{"id":"8f02cab34faa17d61ca89aa05ade372e","ok":true,"rev":"1-68b03bf8df34c5854d852e3b549d0572"}O segundo documento também foi inserido com sucesso, usando credenciais de administrador e a chave de documento gerada automaticamente é 8f02cab34faa17d61ca89aa05ade372e.
Agora podemos obter o documento executando a operação GET usando o Sync Gateway API REST pública:
$ curl -u admin:password -X GET "https://a8ce.us-west-2.elb.amazonaws.com:4984/cbdemo/c4988cff19c632a724e13d4390b23b82" -H "accept: application/json" -H "Content-Type: application/json"
saída
{"_id":"c4988cff19c632a724e13d4390b23b82","_rev":"1-f99195111681fe7361b74eb5ebca23d4","channels":"foo","id":"doc3"}Conclusão
O Couchbase Sync Gateway é a tecnologia crítica de sincronização de dados que permite que os desenvolvedores de aplicativos criem soluções de borda para a nuvem. Neste artigo, usamos a versão mais recente do Couchbase Autonomous Operator para instalar o cluster do Couchbase e o Sync Gateway na plataforma Kubernetes da nuvem pública. Em artigos futuros, vou me basear neste artigo e mostrar como você pode fazer muitas outras coisas de nível empresarial (como criptografia, LDAP, desenvolvimento do Couchbase Lite e muito mais). Até lá, bom aprendizado.
