Rede pública, DNS externo e operador autônomo do Couchbase

Por que expor o banco de dados do Couchbase na rede pública?

Agora, vamos ver isso em ação!

Agora, vamos percorrer as etapas para implantar o cluster do Couchbase usando o Autonomous Operator 2.0 no EKS e acessar o cluster do Couchbase por meio de uma rede pública gerenciada pelo DNS externo. Veja abaixo uma visão geral rápida da arquitetura da nossa implantação.

Rede pública com operador autônomo do Couchbase usando DNS externo do Kubernetes

Pré-requisitos

Antes de começarmos, há alguns pré-requisitos importantes abaixo.

1. 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. 
2. 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.
3. Implante o cluster EKS. O Grupo EKS pode ser implantado usando o Console AWS ou eksctl. Neste artigo, estaremos implantando o cluster EKS no us-east-1 com 3 nós de trabalho em três zonas de disponibilidade, conforme mencionado abaixo.

$ eksctl create cluster \
--name cb-op2-edns \
--region us-east-1 \
--zones us-east-1a,us-east-1b,us-east-1c \
--nodegroup-name eks-workers \
--node-type m4.xlarge \
--nodes 3 \
--nodes-min 3 \
--nodes-max 6 \
--node-ami auto

4. Você precisará de um domínio DNS público. O domínio pode ser adquirido de um registrador, como GoDaddy, AWS Route 53, Namecheapetc. Para este artigo, estou usando meu próprio domínio registrado (GoDaddy) balajiacloud.guru e eu sugeriria que você obtivesse o seu antes de continuar.

5. Por fim, você precisará de um provedor de DNS externo. Durante o ciclo de vida de um cluster do Couchbase, os nós podem ser adicionados e removidos para dimensionamento do cluster, atualizações ou recuperação de falhas. Em cada instância, novos nomes DNS precisam ser criados para quaisquer novos pods do Couchbase que forem criados ou nomes DNS removidos de pods que forem excluídos. O provedor de DDNS expõe uma API REST que permite que o controlador de DNS externo no Kubernetes sincronize a aparência do cluster do Couchbase com o DNS público. 

Aqui está a lista de todos os documentos e conhecidos DNS externo para a plataforma Kubernetes. Neste artigo, usaremos Cloudflare como nosso provedor de DNS externo. Se você planeja usar a Cloudflare como seu provedor de DNS externo, precisará criar uma conta na Cloudflare e adicionar o domínio DNS à conta.

Criação de certificados TLS

O Operador garante que você configure seus clusters do Couchbase com segurança. Se o Operator detectar que um cluster está sendo exposto na Internet pública, ele aplicará a criptografia TLS. 

Antes de gerarmos certificados TLS, precisamos determinar em qual domínio DNS o cluster do Couchbase estará. Podemos usar nosso balajiacloud.guru diretamente, mas, nesse caso, ele só poderá ser usado por um único cluster do Couchbase. Portanto, usaremos um subdomínio chamado cbdemo.balajiacloud.guru como um namespace exclusivo para o nosso cluster. Em geral, um nome DNS curinga (*.cbdemo.balajiacloud.guru) tratará todos os nomes DNS públicos gerados pelo Operador. Isso precisa ser adicionado ao certificado do cluster do Couchbase.

Usaremos o EasyRSA para criar os certificados TLS. O EasyRSA do OpenVPN torna a operação de uma infraestrutura de chave pública (PKI) relativamente simples e é o método recomendado para começar a funcionar rapidamente.

1. Vamos criar um diretório chamado tls e clonar o repositório do EasyRSA.

$ git clone https://github.com/OpenVPN/easy-rsa
Cloning into 'easy-rsa'...
remote: Enumerating objects: 26, done.
remote: Counting objects: 100% (26/26), done.
remote: Compressing objects: 100% (20/20), done.
remote: Total 1979 (delta 9), reused 19 (delta 6), pack-reused 1953
Receiving objects: 100% (1979/1979), 5.75 MiB | 1.92 MiB/s, done.
Resolving deltas: 100% (859/859), done.

2. Inicialize e crie o certificado/chave da CA. Você será solicitado a fornecer uma senha de chave privada e o nome comum (CN) da CA, algo como Couchbase CA é suficiente. O certificado CA estará disponível como pki/ca.crt.

$ cd easy-rsa/easyrsa3

$ ./easyrsa init-pki

init-pki complete; you may now create a CA or requests.
Your newly created PKI dir is: /Users/balajinarayanan/k8s/couchbase/operator/tls/easy-rsa/easyrsa3/pki

$ ./easyrsa build-ca
Using SSL: openssl LibreSSL 2.8.3

Enter New CA Key Passphrase:
Re-Enter New CA Key Passphrase:
Generating RSA private key, 2048 bit long modulus
..........................................+++
................................................................+++
e is 65537 (0x10001)
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Common Name (eg: your user, host, or server name) [Easy-RSA CA]:Couchbase CA

CA creation complete and you may now import and sign cert requests.
Your new CA certificate file for publishing is at:
/Users/balajinarayanan/k8s/couchbase/operator/tls/easy-rsa/easyrsa3/pki/ca.crt

3. Crie o certificado do servidor de cluster do Couchbase.

Você precisa criar um certificado curinga de servidor e uma chave a ser usada nos pods do Couchbase Server. Neste artigo, usaremos o comando abaixo para gerar um certificado para o cluster do Couchbase cbopedns no demonstração e usando o namespace cbdemo.balajiacloud.guru subdomínio.

$ ./easyrsa --subject-alt-name="DNS:*.cbopedns,DNS:*.cbopedns.demo,DNS:*.cbopedns.demo.svc,DNS:*.demo.svc,DNS:cbopedns-srv,DNS:cbopedns-srv.demo,DNS:cbopedns-srv.demo.svc,DNS:localhost,DNS:*.cbopedns.cbdemo.balajiacloud.guru,DNS:*.cbdemo.balajiacloud.guru" build-server-full couchbase-server nopass
Using SSL: openssl LibreSSL 2.8.3
Generating a 2048 bit RSA private key
..............................+++
.......................................................+++
writing new private key to '/Users/balajinarayanan/k8s/couchbase/operator/tls/easy-rsa/easyrsa3/pki/easy-rsa-10086.2Q0Q2S/tmp.emWXHL'
-----
Using configuration from /Users/balajinarayanan/k8s/couchbase/operator/tls/easy-rsa/easyrsa3/pki/easy-rsa-10086.2Q0Q2S/tmp.Phz9Az
Enter pass phrase for /Users/balajinarayanan/k8s/couchbase/operator/tls/easy-rsa/easyrsa3/pki/private/ca.key:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName            :ASN.1 12:'couchbase-server'
Certificate is to be certified until Aug  5 17:44:19 2022 GMT (825 days)

Write out database with 1 new entries
Data Base Updated

Observação: as chaves protegidas por senha não são compatíveis com o Couchbase Server ou com o Operator.

O par chave/certificado pode ser encontrado em pki/private/couchbase-server.key e pki/issued/couchbase-server.crt e usado como pkey.key e chain.pemrespectivamente, no spec.networking.tls.static.serverSecret parâmetro de agrupamento.

4. Formatação da chave privada - Devido a uma limitação Com o tratamento de chaves privadas do Couchbase Server, as chaves do servidor precisam ser formatadas como PKCS#1.

Primeiro, vamos copiar os arquivos .key e .pem para o diretório tls para facilitar o acesso.

$ cp easy-rsa/easyrsa3/pki/private/couchbase-server.key pkey.key

$ cp easy-rsa/easyrsa3/pki/issued/couchbase-server.crt chain.pem

$ cp easy-rsa/easyrsa3/pki/ca.crt ca.crt

Agora, vamos formatar as chaves do servidor.

$ openssl rsa -in pkey.key -out pkey.key.der -outform DER
writing RSA key

$ openssl rsa -in pkey.key.der -inform DER -out pkey.key -outform PEM
writing RSA key

Usaremos essas chaves para criar o segredo do servidor do cluster do Couchbase.

Implantar o Couchbase Autonomous Operator 2.0 (mais recente)

O Couchbase Autonomous Operator for Kubernetes permite a portabilidade da nuvem e automatiza as práticas recomendadas operacionais para implantar e gerenciar o Couchbase.

O operador é composto de dois componentes: um controlador de admissão dinâmica (DAC) por cluster e um operador por espaço de nome. Consulte o arquitetura da operadora para obter informações adicionais sobre o que é necessário e considerações de segurança.

1. Faça o download do pacote Operator

Você pode fazer o download da versão mais recente Operador autônomo do Couchbase e descompacte-o no computador local. O pacote Operator contém arquivos de configuração YAML e ferramentas de linha de comando que você usará para instalar o Operator.

2. Instale a definição de recursos personalizados (CRD)

A primeira etapa da instalação do Operator é instalar as definições de recursos personalizados (CRD) que descrevem os tipos de recursos do Couchbase. Isso pode ser feito executando o comando abaixo no diretório do pacote Operator:

$ kubectl create -f crd.yaml

customresourcedefinition.apiextensions.k8s.io/couchbasebuckets.couchbase.com created
customresourcedefinition.apiextensions.k8s.io/couchbaseephemeralbuckets.couchbase.com created
customresourcedefinition.apiextensions.k8s.io/couchbasememcachedbuckets.couchbase.com created
customresourcedefinition.apiextensions.k8s.io/couchbasereplications.couchbase.com created
customresourcedefinition.apiextensions.k8s.io/couchbaseusers.couchbase.com created
customresourcedefinition.apiextensions.k8s.io/couchbasegroups.couchbase.com created
customresourcedefinition.apiextensions.k8s.io/couchbaserolebindings.couchbase.com created
customresourcedefinition.apiextensions.k8s.io/couchbaseclusters.couchbase.com created
customresourcedefinition.apiextensions.k8s.io/couchbasebackups.couchbase.com created
customresourcedefinition.apiextensions.k8s.io/couchbasebackuprestores.couchbase.com created

3. Instale o Dynamic Admission Controller (DAC)

O DAC permite que os recursos personalizados sejam modificados e interrogados antes que um recurso seja aceito e comprometido com 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.

Agora, vamos instalar o Dynamic Admission Controller.

Abra uma janela do Terminal e vá para o diretório onde você descompactou o pacote Operator e cd para a pasta bin. Execute o seguinte comando para instalar o DAC no diretório padrão namespace.

$ ./cbopcfg --no-operator --namespace default | kubectl create -n default -f -

serviceaccount/couchbase-operator-admission created
clusterrole.rbac.authorization.k8s.io/couchbase-operator-admission created
clusterrolebinding.rbac.authorization.k8s.io/couchbase-operator-admission created
secret/couchbase-operator-admission created
deployment.apps/couchbase-operator-admission created
service/couchbase-operator-admission created
mutatingwebhookconfiguration.admissionregistration.k8s.io/couchbase-operator-admission created
validatingwebhookconfiguration.admissionregistration.k8s.io/couchbase-operator-admission created

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           70s

4. Criar um espaço de nome

Os namespaces são uma forma de alocar recursos de cluster, além de definir políticas de rede e segurança entre vários aplicativos. Criaremos um namespace exclusivo chamado demonstração para implantar o Operator e, posteriormente, usará o namespace de demonstração para implantar o cluster do Couchbase.

Execute o seguinte comando para criar o namespace.

$ kubectl create namespace demo

namespace/demo created

Confirme se o Namespace foi criado com sucesso.

$ kubectl get namespaces

NAME              STATUS   AGE
default           Active   37m
demo              Active   39s
kube-node-lease   Active   37m
kube-public       Active   37m
kube-system       Active   37m

5. Configurar o TLS

Os segredos são especificados no recurso CouchbaseCluster, e você perceberá isso no YAML de definição do cluster enquanto implantamos o cluster do Couchbase.

Segredo do servidor

Os segredos do servidor precisam ser montados como um volume dentro do pod do Couchbase Server com nomes específicos. A cadeia de certificados deve ter o nome chain.pem e a chave privada como pkey.key. Execute o comando abaixo para criar o segredo do servidor Couchbase.

$ kubectl create secret generic couchbase-server-tls -n demo --from-file tls/chain.pem --from-file tls/pkey.key

secret/couchbase-server-tls created

Segredo do operador

Os segredos do cliente Operator são lidos diretamente da API. Ele espera que apenas um único valor esteja presente; ca.crt é a CA de nível superior que é usada para autenticar todas as cadeias de certificados de servidores TLS. Execute o comando abaixo para criar o segredo do operador.

$ kubectl create secret generic couchbase-operator-tls -n demo --from-file tls/ca.crt

secret/couchbase-operator-tls created

6. Instalar o operador do Couchbase

Agora, vamos implementar o Operator no demonstração executando o seguinte comando, na pasta bin do diretório do pacote Operator.

$ ./cbopcfg --no-admission --namespace demo | kubectl create -n demo -f -

serviceaccount/couchbase-operator created
role.rbac.authorization.k8s.io/couchbase-operator created
rolebinding.rbac.authorization.k8s.io/couchbase-operator created
deployment.apps/couchbase-operator created
service/couchbase-operator created

A 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 pod do Operator é executado como implantação para que o Kubernetes possa reinicializar em caso de falha.

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.

Verificar o status da implantação do operador

Você pode usar o seguinte comando para verificar o status da implantação:

$ kubectl get deployments -n demo

NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
couchbase-operator   1/1     1            1           97s

Se você executar esse comando imediatamente após a implantação do Operator, a saída terá o formato DISPONÍVEL No entanto, o campo AVAILABLE indica que o pod ainda não está pronto, pois seu valor é 0 e não 1.

Execute o seguinte comando para verificar se o pod do Operator foi iniciado com êxito. Se o Operator estiver em funcionamento, o comando retornará uma saída em que o PRONTO shows de campo 1/1como, por exemplo:

$ kubectl get pods -l app=couchbase-operator -n demo

NAME                                  READY   STATUS    RESTARTS   AGE
couchbase-operator-7f799565f8-c29ts   1/1     Running   0          2m47s

Você também pode verificar os registros para confirmar que o Operator está ativo e em execução, executando o comando abaixo.

$ kubectl logs -f couchbase-operator-7f799565f8-c29ts -n demo

{"level":"info","ts":1588493860.1096337,"logger":"main","msg":"couchbase-operator","version":"2.0.0 (build 317)","revision":"release"}
{"level":"info","ts":1588493860.1100397,"logger":"leader","msg":"Trying to become the leader."}
{"level":"info","ts":1588493860.1653795,"logger":"leader","msg":"No pre-existing lock was found."}
{"level":"info","ts":1588493860.1700613,"logger":"leader","msg":"Became the leader."}
{"level":"info","ts":1588493860.2087,"logger":"kubebuilder.controller","msg":"Starting EventSource","controller":"couchbase-controller","source":"kind source: /, Kind="}
{"level":"info","ts":1588493860.3104734,"logger":"kubebuilder.controller","msg":"Starting Controller","controller":"couchbase-controller"}
{"level":"info","ts":1588493860.4107096,"logger":"kubebuilder.controller","msg":"Starting workers","controller":"couchbase-controller","worker count":4}

Implantar o DNS externo

Supondo que você já tenha concluído as etapas acima para implantar o Operator em um namespace, o demonstração a próxima coisa que você precisa instalar é o controlador de DNS externo. Ele deve ser instalado antes do cluster do Couchbase, pois o Operator aguardará a propagação do DNS antes de criar os pods do Couchbase Server. Isso ocorre porque os clientes devem ser capazes de alcançar os pods do Couchbase Server para atender ao tráfego e evitar erros de aplicativos.

1. Crie uma conta de serviço para o controlador de DNS externo no namespace em que você está instalando o Operator.

$ kubectl --namespace demo create serviceaccount external-dns

serviceaccount/external-dns created

2. O controlador de DNS externo requer uma função para que possa pesquisar recursos e procurar registros de DNS para replicar no provedor de DDNS. 

$ kubectl --namespace demo create -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: external-dns
rules:
- apiGroups: [""]
  resources: ["services","endpoints","pods"]
  verbs: ["get","watch","list"]
- apiGroups: ["extensions"]
  resources: ["ingresses"]
  verbs: ["get","watch","list"]
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get","watch","list"]
EOF

clusterrole.rbac.authorization.k8s.io/external-dns created

3. Agora, vincule a função de DNS externo à conta de serviço.

$ kubectl --namespace demo create -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: external-dns
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: external-dns
subjects:
- kind: ServiceAccount
  name: external-dns
  namespace: demo
EOF

clusterrolebinding.rbac.authorization.k8s.io/external-dns created

4. A última etapa é a implementação do DNS externo. Não se esqueça de atualizar os valores abaixo específicos para sua implementação.

• • O spec.template.spec.serviceAccountName garante que os pods de DNS externo estejam sendo executados como a conta de serviço que configuramos. Isso concede ao controlador permissão para pesquisar recursos e procurar solicitações de DDNS.
  • O -filtro de domínio O argumento diz ao External DNS para considerar apenas as entradas de DDNS que estão associadas às entradas de DNS relacionadas ao nosso balajiacloud.guru domínio.
  • O -txt-owner-id informa ao External DNS para rotular os registros de gerenciamento TXT com uma cadeia de caracteres exclusiva da instância do External DNS. O External DNS usa registros TXT para registrar metadados, especialmente informações de propriedade associadas aos registros DNS que está gerenciando. Se o registro balajiacloud.guru for usado por várias instâncias do DNS externo sem especificar nenhuma propriedade, elas entrarão em conflito umas com as outras.
  • O CF_API_KEY é usada pelo provedor da Cloudflare para autenticação na API da Cloudflare.
  • O CF_API_EMAIL é usada pelo provedor da Cloudflare para identificar a conta a ser usada na API da Cloudflare.

Você pode obter o CF_API_KEY na página de visão geral da conta do Cloudfare. Clique no link "Get your API token" (Obtenha seu token de API), conforme mostrado abaixo, e veja o Chave de API global.

Implantar o DNS externo

Por fim, instale a implementação do DNS externo executando o comando abaixo.

$ kubectl --namespace demo create -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: external-dns
spec:
  selector:
    matchLabels:
      app: external-dns
  template:
    metadata:
      labels:
        app: external-dns
    spec:
      serviceAccountName: external-dns
      containers:
      - name: external-dns
        image: registry.opensource.zalan.do/teapot/external-dns:latest
        args:
        - --source=service
        - --domain-filter=balajiacloud.guru
        - --provider=cloudflare
        - --txt-owner-id=cbop-edns-demo
        env:
          - name: CF_API_KEY
            value: YOUR_CF_API_KEY
          - name: CF_API_EMAIL
            value: YOUR_CF_API_EMAIL
EOF

deployment.apps/external-dns created

Verifique o status da implantação do DNS externo

Você pode usar o seguinte comando para verificar o status da implantação:

$ kubectl get deployments -n demo

NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
couchbase-operator   1/1     1            1           10m
external-dns         1/1     1            1           21s

Execute o seguinte comando para verificar se o external-dns foi iniciado com êxito. Se o external-dns estiver funcionando, o comando retornará uma saída em que o CORRIDA shows de campo 1/1como, por exemplo:

$ kubectl get pods -n demo

NAME                                  READY   STATUS    RESTARTS   AGE
couchbase-operator-7f799565f8-c29ts   1/1     Running   0          11m
external-dns-6f74575d54-fp2wh         1/1     Running   0          59s

Você também pode verificar os registros para confirmar se o external-dns está em funcionamento.

$ kubectl logs -f external-dns-6f74575d54-fp2wh -n demo

time="2020-05-03T08:27:44Z" level=info msg="config: {Master: KubeConfig: RequestTimeout:30s IstioIngressGatewayServices:[] ContourLoadBalancerService:heptio-contour/contour SkipperRouteGroupVersion:zalando.org/v1 Sources:[service] Namespace: AnnotationFilter: FQDNTemplate: CombineFQDNAndAnnotation:false IgnoreHostnameAnnotation:false Compatibility: PublishInternal:false PublishHostIP:false AlwaysPublishNotReadyAddresses:false ConnectorSourceServer:localhost:8080 Provider:cloudflare GoogleProject: GoogleBatchChangeSize:1000 GoogleBatchChangeInterval:1s DomainFilter:[balajiacloud.guru] ExcludeDomains:[] ZoneIDFilter:[] AlibabaCloudConfigFile:/etc/kubernetes/alibaba-cloud.json AlibabaCloudZoneType: AWSZoneType: AWSZoneTagFilter:[] AWSAssumeRole: AWSBatchChangeSize:1000 AWSBatchChangeInterval:1s AWSEvaluateTargetHealth:true AWSAPIRetries:3 AWSPreferCNAME:false AzureConfigFile:/etc/kubernetes/azure.json AzureResourceGroup: AzureSubscriptionID: AzureUserAssignedIdentityClientID: CloudflareProxied:false CloudflareZonesPerPage:50 CoreDNSPrefix:/skydns/ RcodezeroTXTEncrypt:false AkamaiServiceConsumerDomain: AkamaiClientToken: AkamaiClientSecret: AkamaiAccessToken: InfobloxGridHost: InfobloxWapiPort:443 InfobloxWapiUsername:admin InfobloxWapiPassword: InfobloxWapiVersion:2.3.1 InfobloxSSLVerify:true InfobloxView: InfobloxMaxResults:0 DynCustomerName: DynUsername: DynPassword: DynMinTTLSeconds:0 OCIConfigFile:/etc/kubernetes/oci.yaml InMemoryZones:[] OVHEndpoint:ovh-eu PDNSServer:https://localhost:8081 PDNSAPIKey: PDNSTLSEnabled:false TLSCA: TLSClientCert: TLSClientCertKey: Policy:sync Registry:txt TXTOwnerID:cbop-edns-demo TXTPrefix: Interval:1m0s Once:false DryRun:false UpdateEvents:false LogFormat:text MetricsAddress::7979 LogLevel:info TXTCacheInterval:0s ExoscaleEndpoint:https://api.exoscale.ch/dns ExoscaleAPIKey: ExoscaleAPISecret: CRDSourceAPIVersion:externaldns.k8s.io/v1alpha1 CRDSourceKind:DNSEndpoint ServiceTypeFilter:[] CFAPIEndpoint: CFUsername: CFPassword: RFC2136Host: RFC2136Port:0 RFC2136Zone: RFC2136Insecure:false RFC2136TSIGKeyName: RFC2136TSIGSecret: RFC2136TSIGSecretAlg: RFC2136TAXFR:false RFC2136MinTTL:0s NS1Endpoint: NS1IgnoreSSL:false TransIPAccountName: TransIPPrivateKeyFile:}"
time="2020-05-03T08:27:44Z" level=info msg="Instantiating new Kubernetes client"
time="2020-05-03T08:27:44Z" level=info msg="Using inCluster-config based on serviceaccount-token"
time="2020-05-03T08:27:44Z" level=info msg="Created Kubernetes client https://10.100.0.1:443"

Agora, implementamos com êxito o DNS externo.

Implantar o cluster do Couchbase

Agora que implantamos o operador autônomo do Couchbase e o DNS externo no EKS, vamos implantar o cluster do Couchbase.

Implantaremos o cluster do Couchbase com 3 nós de dados em 3 zonas de disponibilidade com os parâmetros mínimos de configuração necessários. Consulte a seção Configurar a rede pública para as opções de configuração necessárias. 

Criar o segredo para o console de administração do Couchbase

Vamos criar uma credencial secreta que será usada pelo console administrativo da Web durante o login. Quando você cria o segredo abaixo em seu cluster do Kubernetes, o segredo define o nome de usuário como Administrador e a senha para senha.

$ kubectl --namespace demo create -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: cb-example-auth
type: Opaque
data:
  username: QWRtaW5pc3RyYXRvcg== # Administrator
  password: cGFzc3dvcmQ=         # password
EOF

secret/cbopedns-auth created

Implantar a definição do cluster do Couchbase

Usaremos o padrão Classe de armazenamento que obtemos com o EKS, vamos verificar executando o seguinte comando. Você pode criar uma classe de armazenamento que atenda a seus requisitos.

$ kubectl get sc

NAME            PROVISIONER             AGE
gp2 (default)   kubernetes.io/aws-ebs   67m

A definição de cluster abaixo implantará o cluster do Couchbase com 3 pods de dados em 3 zonas diferentes usando volumes persistentes. Verifique a Recurso de cluster do Couchbase para obter a lista completa da configuração do cluster.

$ kubectl --namespace demo create -f - <<EOF
apiVersion: couchbase.com/v2
kind: CouchbaseBucket
metadata:
  name: default
---
apiVersion: couchbase.com/v2
kind: CouchbaseCluster
metadata:
  name: cbopedns
spec:
  image: couchbase/server:6.5.0
  networking:
    tls:
      static:
        serverSecret: couchbase-server-tls
        operatorSecret: couchbase-operator-tls
    exposeAdminConsole: true
    adminConsoleServiceType: LoadBalancer
    exposedFeatures:
      - xdcr
      - client
    exposedFeatureServiceType: LoadBalancer
    dns:
      domain: cbdemo.balajiacloud.guru
  disableBucketManagement: false
  cluster:
    clusterName: cbopedns
    dataServiceMemoryQuota: 2048Mi
  security:
    adminSecret: cbopedns-auth
  servers:
    - name: data-east-1a
      size: 1
      services:
        - data
      serverGroups:
        - us-east-1a
      pod:
        volumeMounts:
          default: pvc-default    # /opt/couchbase/var/lib/couchbase
          data: pvc-data    # /mnt/data
    - name: data-east-1b
      size: 1
      services:
        - data
      serverGroups:
        - us-east-1b
      pod:
        volumeMounts:
          default: pvc-default
          data: pvc-data
    - name: data-east-1c
      size: 1
      services:
        - data
      serverGroups:
        - us-east-1c
      pod:
        volumeMounts:
          default: pvc-default
          data: pvc-data
  volumeClaimTemplates:
    - metadata:
        name: pvc-default
      spec:
        storageClassName: gp2
        resources:
          requests:
            storage: 1Gi
    - metadata:
        name: pvc-data
      spec:
        storageClassName: gp2
        resources:
          requests:
            storage: 5Gi
EOF

couchbasebucket.couchbase.com/default created
couchbasecluster.couchbase.com/cbopedns created

Para verificar o progresso, execute o comando abaixo, que observará (argumento -w) o progresso da criação dos pods. Se tudo correr bem, teremos três pods do cluster do Couchbase hospedando os serviços de acordo com a definição do cluster do Couchbase.

kubectl get pods --namespace demo -w

cbopedns-0000                         1/1     Running   0          9m15s
cbopedns-0001                         1/1     Running   0          8m34s
cbopedns-0002                         1/1     Running   0          8m
couchbase-operator-7f799565f8-c29ts   1/1     Running   1          36m
external-dns-6f74575d54-fp2wh         1/1     Running   0          26m

Se, por algum motivo, houver uma exceção, você poderá encontrar os detalhes da exceção no arquivo de log do couchbase-operator. Para exibir as últimas 20 linhas do registro, copie o nome do pod do Operator e execute o comando abaixo, substituindo o nome do pod do Operator pelo nome do seu ambiente.

$ kubectl logs couchbase-operator-7f799565f8-c29ts -n demo --tail 20

{"level":"info","ts":1588495709.7896624,"logger":"cluster","msg":"Watching new cluster","cluster":"demo/cbopedns"}
{"level":"info","ts":1588495709.7898946,"logger":"cluster","msg":"Janitor starting","cluster":"demo/cbopedns"}
{"level":"info","ts":1588495709.7987065,"logger":"cluster","msg":"Couchbase client starting","cluster":"demo/cbopedns"}
{"level":"info","ts":1588495709.818881,"logger":"cluster","msg":"Cluster already exists, the operator will now manage it","cluster":"demo/cbopedns"}
{"level":"info","ts":1588495709.8903878,"logger":"cluster","msg":"Running","cluster":"demo/cbopedns"}
{"level":"info","ts":1588495710.0405645,"logger":"couchbaseutil","msg":"Cluster status","cluster":"demo/cbopedns","balance":"unbalanced","rebalancing":false}
{"level":"info","ts":1588495710.0406282,"logger":"couchbaseutil","msg":"Node status","cluster":"demo/cbopedns","name":"cbopedns-0000","version":"6.5.0","class":"data-east-1a","managed":true,"status":"active"}
{"level":"info","ts":1588495710.0406532,"logger":"couchbaseutil","msg":"Node status","cluster":"demo/cbopedns","name":"cbopedns-0001","version":"6.5.0","class":"data-east-1b","managed":true,"status":"pending_add"}
{"level":"info","ts":1588495710.040662,"logger":"couchbaseutil","msg":"Node status","cluster":"demo/cbopedns","name":"cbopedns-0002","version":"6.5.0","class":"data-east-1c","managed":true,"status":"pending_add"}
{"level":"info","ts":1588495710.0406775,"logger":"scheduler","msg":"Scheduler status","cluster":"demo/cbopedns","name":"cbopedns-0000","class":"data-east-1a","group":"us-east-1a"}
{"level":"info","ts":1588495710.0406868,"logger":"scheduler","msg":"Scheduler status","cluster":"demo/cbopedns","name":"cbopedns-0001","class":"data-east-1b","group":"us-east-1b"}
{"level":"info","ts":1588495710.040695,"logger":"scheduler","msg":"Scheduler status","cluster":"demo/cbopedns","name":"cbopedns-0002","class":"data-east-1c","group":"us-east-1c"}
{"level":"info","ts":1588495755.230221,"logger":"couchbaseutil","msg":"Rebalancing","cluster":"demo/cbopedns","progress":0}
{"level":"info","ts":1588495759.2380211,"logger":"cluster","msg":"Rebalance completed successfully","cluster":"demo/cbopedns"}
{"level":"info","ts":1588495759.286947,"logger":"cluster","msg":"Reconcile completed","cluster":"demo/cbopedns"}

Vamos verificar os logs external-dns para ver se os registros DNS para os pods do Couchbase estão sendo criados.

$ kubectl logs -f external-dns-6f74575d54-fp2wh -n demo

time="2020-05-03T08:46:46Z" level=info msg="Changing record." action=CREATE record=cbopedns-0000.cbdemo.balajiacloud.guru targets=1 ttl=1 type=CNAME zone=c3b835b8ec89e43a2492b62d5d82cc86
time="2020-05-03T08:46:46Z" level=info msg="Changing record." action=CREATE record=cbopedns-0002.cbdemo.balajiacloud.guru targets=1 ttl=1 type=CNAME zone=c3b835b8ec89e43a2492b62d5d82cc86
time="2020-05-03T08:46:47Z" level=info msg="Changing record." action=CREATE record=cbopedns-0001.cbdemo.balajiacloud.guru targets=1 ttl=1 type=CNAME zone=c3b835b8ec89e43a2492b62d5d82cc86
time="2020-05-03T08:46:47Z" level=info msg="Changing record." action=CREATE record=cbopedns-0000.cbdemo.balajiacloud.guru targets=1 ttl=1 type=TXT zone=c3b835b8ec89e43a2492b62d5d82cc86
time="2020-05-03T08:46:47Z" level=info msg="Changing record." action=CREATE record=cbopedns-0002.cbdemo.balajiacloud.guru targets=1 ttl=1 type=TXT zone=c3b835b8ec89e43a2492b62d5d82cc86
time="2020-05-03T08:46:47Z" level=info msg="Changing record." action=CREATE record=cbopedns-0001.cbdemo.balajiacloud.guru targets=1 ttl=1 type=TXT zone=c3b835b8ec89e43a2492b62d5d82cc86

Nesse momento, você também pode verificar a página DNS fazendo login na sua conta Cloudfare conta. Você pode ver os registros CNAME e TXT adicionados pelo seu provedor de DNS externo.

Acesso ao console da Web do Couchbase

Agora, você tem um cluster endereçável publicamente e pode começar a usá-lo. No ambiente EKS, o console da Web do Couchbase pode ser acessado por meio de um serviço LoadBalancer exposto de um pod específico. Você deve ser capaz de se conectar ao console do Couchbase usando o URL https://cbopedns-0000.cbdemo.balajiacloud.guru:18091/ (substitua o nome do pod e o domínio DNS com base no seu ambiente).

Consulte Acessar a interface do usuário do Couchbase Server para obter mais detalhes sobre como se conectar ao console do Couchbase. Além disso, você pode verificar Configurar SDKs de cliente para obter detalhes sobre como conectar o SDK do cliente ao cluster do Couchbase ao usar o endereçamento baseado em DNS com DNS externo.

Conclusão

Neste blog, vimos como o cluster do Couchbase pode ser endereçado publicamente usando o Couchbase Operator com o DNS externo do Kubernetes. Discutimos como a solução de DNS externo ajuda a gerenciar dinamicamente os registros de DNS externo de dentro de um cluster do Kubernetes. Neste artigo, usamos o Amazon EKS como nosso ambiente do Kubernetes, mas as mesmas etapas também serão aplicáveis se você estiver usando outros ambientes do Kubernetes, como AKS, GKE, OpenShift etc.

Recursos

• Experimente: Faça o download do Operador Autônomo do Couchbase 2.0
• Compartilhe suas ideias sobre o Fóruns do Couchbase
• Documentação: 
  • • Operador autônomo do Couchbase 2.0
    • Documentos do Kubernetes
    • DNS externo