Programa de aprendizado: aplicativos escalonáveis - Criar um cluster


Este conjunto de tutoriais é destinado a administradores e operadores de TI que querem implantar, executar e gerenciar ambientes de aplicativos modernos executados no Google Kubernetes Engine (GKE). À medida que avança neste conjunto de tutoriais, você aprende a configurar o monitoramento e alertas, escalonar cargas de trabalho e simular falhas. Tudo isso usando o aplicativo de microsserviços de exemplo Cymbal Bank:

  1. Criar um cluster e implantar um aplicativo de amostra (este tutorial)
  2. Monitorar com o Google Cloud Managed Service para Prometheus
  3. Escalonar cargas de trabalho
  4. Simular uma falha

Visão geral e objetivos

O Cymbal Bank usa Python e Java para executar os diversos serviços e inclui um back-end PostgreSQL. Você não precisa ter experiência com essas linguagens ou plataformas de banco de dados para concluir a série de tutoriais, já que o Cymbal Bank é apenas um exemplo de aplicativo para mostrar como o GKE pode atender às necessidades da sua empresa.

Neste tutorial, você aprenderá a criar um único cluster do GKE e implantar um aplicativo de amostra baseado em microsserviços chamado Cymbal Bank em um cluster do GKE. Você aprenderá a concluir as seguintes tarefas:

  • Criar um cluster do GKE que usa o Autopilot.

  • Implantar um aplicativo de amostra baseado em microsserviços chamado Cymbal Bank.

  • Usar o console do Google Cloud para conhecer os recursos do GKE usados pelo aplicativo de amostra Cymbal Bank.

Custos

Ao ativar o GKE e implantar o aplicativo de exemplo do Cymbal Bank para esta série de tutoriais, você receberá cobranças por cluster do GKE no Google Cloud, conforme listado na nossa página de preços, até desativar o GKE ou excluir o projeto.

Você também é responsável por outros custos do Google Cloud gerados ao executar o aplicativo de amostra Cymbal Bank, como cobranças por VMs do Compute Engine e balanceadores de carga.

Antes de começar

Neste primeiro tutorial da série, conclua todas as etapas "Comece a configurar" a seguir antes de começar. Você só precisa concluir as etapas "Antes de começar" a seguir uma vez.

Configurar o shell e as ferramentas

Nesta série de tutoriais, você usará as seguintes ferramentas para implantar e gerenciar o ambiente:

  • gcloud CLI: crie e gerencie clusters e frotas do GKE, além de outros serviços do Google Cloud.
  • kubectl: gerencia o Kubernetes, o sistema de orquestração de clusters usado pelo GKE.

Para executar os comandos nesta página, configure a CLI do Google Cloud e o kubectl em um dos seguintes ambientes de desenvolvimento:

Cloud Shell

Para usar um terminal on-line com a gcloud CLI e o kubectl já configurados, ative o Cloud Shell:

Na parte inferior desta página, uma sessão do Cloud Shell é iniciada e exibe um prompt de linha de comando. A inicialização da sessão pode levar alguns segundos.

Shell local

Para usar um ambiente de desenvolvimento local, siga estas etapas:

Crie o projeto

Siga as etapas a seguir para configurar um projeto do Google Cloud, incluindo ativar o faturamento e os serviços do GKE. Esse será o projeto em que você ativará o GKE.

Talvez seja necessário que um administrador do Google Cloud na sua organização conceda a você acesso para criar ou usar um projeto e ativar APIs.

  1. No console do Google Cloud, acesse a página do Google Kubernetes Engine:

    Acessar a página do Google Kubernetes Engine

  2. Crie ou selecione um projeto. Este é o projeto em que você ativa o GKE.

  3. Se solicitado, ative a API GKE.

  4. Aguarde a ativação da API e dos serviços relacionados. Isso pode levar alguns minutos.

  5. Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

Conceder papéis do IAM

Se você é o proprietário do projeto (por exemplo, se criou o projeto por conta própria), já tem todas as permissões necessárias para concluir estes tutoriais. Se você não for o proprietário, verifique se sua conta do Google Cloud tem os papéis do IAM necessários ao projeto selecionado para este conjunto de tutoriais. Novamente, talvez você precise que um administrador do Google Cloud na sua organização ajude a conceder os papéis necessários.

Nos comandos a seguir, substitua PROJECT_ID pelo ID gerado automaticamente do projeto que você criou ou selecionou na seção anterior. O ID do projeto costuma ser diferente do nome do projeto. Por exemplo, seu projeto pode ser scalable-apps, mas o ID do projeto pode ser scalable-apps.

Grant roles to your user account. Run the following command once for each of the following IAM roles: roles/resourcemanager.projectIamAdmin, roles/iam.serviceAccountAdmin, roles/iam.serviceAccountUser, roles/iam.securityAdmin, roles/serviceusage.serviceUsageAdmin, roles/container.admin, roles/logging.logWriter, roles/gkehub.admin, roles/viewer, roles/monitoring.viewer

$ gcloud projects add-iam-policy-binding PROJECT_ID --member="USER_IDENTIFIER" --role=ROLE
  • Replace PROJECT_ID with your project ID.
  • Replace USER_IDENTIFIER with the identifier for your user account. For example, user:myemail@example.com.

  • Replace ROLE with each individual role.

Clonar o aplicativo de amostra

Clone o repositório Git que contém todos os manifestos de amostra do Cymbal Bank:

  git clone https://github.com/GoogleCloudPlatform/bank-of-anthos
  cd bank-of-anthos/

Crie um cluster

Com todas as etapas de pré-requisito das seções anteriores concluídas, agora você pode começar a criar um cluster do GKE e implantar um aplicativo de amostra.

O GKE é um serviço gerenciado do Kubernetes que pode ser usado para implantar e operar aplicativos conteinerizados. Um ambiente do GKE consiste em nós, que são máquinas virtuais (VMs) do Compute Engine, agrupadas para formar um cluster.

  • Crie um cluster do GKE para usar nos outros tutoriais desta série:

    gcloud container clusters create-auto scalable-apps \
      --project=PROJECT_ID \
      --region=REGION
    

    Substitua:

    • PROJECT_ID pelo ID gerado automaticamente do projeto que você criou na seção anterior. O ID do projeto costuma ser diferente do nome do projeto. Por exemplo, seu projeto pode ser scalable-apps, mas o ID do projeto pode ser scalable-apps.
    • REGION pela região onde você quer criar o cluster, como us-central1.

    O GKE leva alguns minutos para criar o cluster e verificar se tudo funciona corretamente.

Neste conjunto de tutoriais, você usa clusters no modo Autopilot e alguns intervalos de endereços IP padrão ao criar clusters. Uma implantação de produção dos próprios aplicativos requer um planejamento de endereço IP mais cuidadoso. No modo Autopilot, o Google gerencia a configuração do cluster, incluindo escalonamento automático, segurança e outras configurações pré-configuradas. Os clusters no modo Autopilot são otimizados para executar a maioria das cargas de trabalho de produção e provisionar recursos de computação com base nos seus manifestos do Kubernetes.

Implantar o Cymbal Bank

Empacote os aplicativos (também chamados de cargas de trabalho) em contêineres. Implante conjuntos de contêineres como pods nos nós.

Nesta série de tutoriais, você implantará um aplicativo de amostra baseado em microsserviços chamado Cymbal Bank em um ou mais clusters do GKE. O Cymbal Bank usa Python e Java para executar os diversos serviços e inclui um back-end PostgreSQL. Você não precisa ter experiência com essas linguagens ou plataformas de banco de dados para concluir a série de tutoriais. O Cymbal Bank é apenas um exemplo de aplicativo mostrar como o GKE atende às necessidades da sua empresa.

Ao usar o Cymbal Bank como parte deste conjunto de tutoriais, os seguintes serviços serão implantados no seu cluster do GKE:

Serviço Idioma Descrição
frontend Python Expõe um servidor HTTP para exibir o site. Contém a página de login, a página de inscrição e a página inicial.
ledger-writer Java Aceita e valida transações de entrada antes de gravá-las no livro razão.
balance-reader Java Fornece um cache legível eficiente de saldos de usuários, conforme lido em ledger-db.
transaction-history Java Fornece um cache legível eficiente de transações anteriores, conforme lido em ledger-db.
ledger-db PostgreSQL Livro razão de todas as transações. Opção de pré-preencher com transações de usuários de demonstração.
user-service Python Gerencia contas de usuário e autenticação. Assina JWTs usados para autenticação por outros serviços.
contacts Python Armazena uma lista de outras contas associadas a um usuário. Usado como menu suspenso nos formulários "Enviar pagamento" e "Depósito".
accounts-db PostgreSQL Banco de dados para contas de usuário e dados associados. Opção de pré-preencher com usuários de demonstração.
loadgenerator Python/Locust Envia solicitações continuamente ao front-end, imitando usuários. Cria periodicamente novas contas e simula transações entre elas.

Para implantar o Cymbal Bank no seu cluster do GKE, conclua as seguintes etapas:

  1. O Cymbal Bank usa JSON Web Tokens (JWTs) para processar a autenticação do usuário. Os JWTs usam pares de chaves assimétricas para assinar e verificar tokens. No Cymbal Bank, userservice cria e assina tokens com uma chave privada RSA quando um usuário faz login, e os outros serviços usam a chave pública correspondente para validar o usuário.

    Crie um JWT RS256 com 4.096 bits de força:

    openssl genrsa -out jwtRS256.key 4096
    openssl rsa -in jwtRS256.key -outform PEM -pubout -out jwtRS256.key.pub
    

    Se necessário, baixe e instale as ferramentas do OpenSSL na sua plataforma.

  2. Um secret do Kubernetes pode armazenar dados sensíveis, como chaves ou senhas. As cargas de trabalho que são executadas no cluster podem acessar o Secret para receber os dados sensíveis em vez de codificá-los no aplicativo.

    Crie um Secret do Kubernetes pelo arquivo de chave criado na etapa anterior para o Cymbal Bank usar com solicitações de autenticação:

    kubectl create secret generic jwt-key --from-file=./jwtRS256.key --from-file=./jwtRS256.key.pub
    
  3. Implante o Cymbal Bank no seu cluster. O comando a seguir implanta todos os arquivos de manifesto no diretório kubernetes-manifests. Cada arquivo de manifesto implanta e configura um dos Serviços:

    kubectl apply -f kubernetes-manifests/accounts-db.yaml
    kubectl apply -f kubernetes-manifests/balance-reader.yaml
    kubectl apply -f kubernetes-manifests/config.yaml
    kubectl apply -f kubernetes-manifests/contacts.yaml
    kubectl apply -f extras/postgres-hpa/kubernetes-manifests/frontend.yaml
    kubectl apply -f kubernetes-manifests/ledger-db.yaml
    kubectl apply -f kubernetes-manifests/ledger-writer.yaml
    kubectl apply -f extras/postgres-hpa/loadgenerator.yaml
    kubectl apply -f kubernetes-manifests/transaction-history.yaml
    kubectl apply -f kubernetes-manifests/userservice.yaml
    

    É possível ver mensagens na saída do kubectl conforme os manifestos são aplicados ao cluster sobre os limites do Autopilot. O Autopilot usa as solicitações de recursos especificadas na configuração da carga de trabalho para configurar os nós que executam suas cargas de trabalho. O Autopilot aplica solicitações mínimas e máximas de recursos com base na classe de computação ou na configuração de hardware usada pelas suas cargas de trabalho. Se você não especificar solicitações para alguns contêineres, o Autopilot atribuirá valores padrão para permitir que eles sejam executados corretamente.

    Analise o exemplo de manifesto a seguir para o Serviço frontend:

    # Copyright 2024 Google LLC
    #
    # Licensed under the Apache License, Version 2.0 (the "License");
    # you may not use this file except in compliance with the License.
    # You may obtain a copy of the License at
    #
    #     https://www.apache.org/licenses/LICENSE-2.0
    #
    # Unless required by applicable law or agreed to in writing, software
    # distributed under the License is distributed on an "AS IS" BASIS,
    # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    # See the License for the specific language governing permissions and
    # limitations under the License.
    
    apiVersion: v1
    kind: Service
    metadata:
      labels:
        application: bank-of-anthos
        environment: development
        team: frontend
        tier: web
      name: frontend
    spec:
      ports:
        - name: http
          port: 80
          targetPort: 8080
      selector:
        app: frontend
        application: bank-of-anthos
        environment: development
        team: frontend
        tier: web
      type: LoadBalancer
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        application: bank-of-anthos
        environment: development
        team: frontend
        tier: web
      name: frontend
    spec:
      selector:
        matchLabels:
          app: frontend
          application: bank-of-anthos
          environment: development
          team: frontend
          tier: web
      template:
        metadata:
          annotations:
            proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }'
          labels:
            app: frontend
            application: bank-of-anthos
            environment: development
            team: frontend
            tier: web
        spec:
          containers:
            - env:
                - name: VERSION
                  value: v0.6.5
                - name: PORT
                  value: "8080"
                - name: ENABLE_TRACING
                  value: "true"
                - name: SCHEME
                  value: http
                - name: LOG_LEVEL
                  value: info
                - name: DEFAULT_USERNAME
                  valueFrom:
                    configMapKeyRef:
                      key: DEMO_LOGIN_USERNAME
                      name: demo-data-config
                - name: DEFAULT_PASSWORD
                  valueFrom:
                    configMapKeyRef:
                      key: DEMO_LOGIN_PASSWORD
                      name: demo-data-config
                - name: REGISTERED_OAUTH_CLIENT_ID
                  valueFrom:
                    configMapKeyRef:
                      key: DEMO_OAUTH_CLIENT_ID
                      name: oauth-config
                      optional: true
                - name: ALLOWED_OAUTH_REDIRECT_URI
                  valueFrom:
                    configMapKeyRef:
                      key: DEMO_OAUTH_REDIRECT_URI
                      name: oauth-config
                      optional: true
              envFrom:
                - configMapRef:
                    name: environment-config
                - configMapRef:
                    name: service-api-config
              image: us-central1-docker.pkg.dev/bank-of-anthos-ci/bank-of-anthos/frontend:v0.6.5@sha256:d72050f70d12383e4434ad04d189b681dc625f696087ddf0b5df641645c9dafa
              livenessProbe:
                httpGet:
                  path: /ready
                  port: 8080
                initialDelaySeconds: 60
                periodSeconds: 15
                timeoutSeconds: 30
              name: front
              readinessProbe:
                httpGet:
                  path: /ready
                  port: 8080
                initialDelaySeconds: 10
                periodSeconds: 5
                timeoutSeconds: 10
              resources:
                limits:
                  cpu: 250m
                  memory: 128Mi
                requests:
                  cpu: 100m
                  memory: 64Mi
              securityContext:
                allowPrivilegeEscalation: false
                capabilities:
                  drop:
                    - all
                privileged: false
                readOnlyRootFilesystem: true
              volumeMounts:
                - mountPath: /tmp
                  name: tmp
                - mountPath: /tmp/.ssh
                  name: publickey
                  readOnly: true
          securityContext:
            fsGroup: 1000
            runAsGroup: 1000
            runAsNonRoot: true
            runAsUser: 1000
          serviceAccountName: bank-of-anthos
          terminationGracePeriodSeconds: 5
          volumes:
            - emptyDir: {}
              name: tmp
            - name: publickey
              secret:
                items:
                  - key: jwtRS256.key.pub
                    path: publickey
                secretName: jwt-key

    Esse manifesto para o serviço frontend solicita 100m de CPU e 64Mi e define limites de 250m de CPU e 128Mi por pod.

    Quando você implanta uma carga de trabalho em um cluster Autopilot, o GKE valida a configuração da carga de trabalho com os valores mínimos e máximos permitidos para a classe de computação ou a configuração de hardware selecionadas (como GPUs). Se as solicitações forem menores que o mínimo, o Autopilot modificará automaticamente a configuração da carga de trabalho para colocar as solicitações no intervalo permitido. Essas mensagens indicam que os limites apropriados serão atribuídos automaticamente.

  4. Aguarde até que os pods estejam prontos. Use kubectl para verificar o status dos pods:

    kubectl get pods
    

    A coluna STATUS muda de Pending para ContainerCreating. Leva alguns minutos para que todos os pods estejam em um estado Running, conforme mostrado no exemplo de saída a seguir:

    NAME                                  READY   STATUS    RESTARTS   AGE
    accounts-db-6f589464bc-6r7b7          1/1     Running   0          99s
    balancereader-797bf6d7c5-8xvp6        1/1     Running   0          99s
    contacts-769c4fb556-25pg2             1/1     Running   0          98s
    frontend-7c96b54f6b-zkdbz             1/1     Running   0          98s
    ledger-db-5b78474d4f-p6xcb            1/1     Running   0          98s
    ledgerwriter-84bf44b95d-65mqf         1/1     Running   0          97s
    loadgenerator-559667b6ff-4zsvb        1/1     Running   0          97s
    transactionhistory-5569754896-z94cn   1/1     Running   0          97s
    userservice-78dc876bff-pdhtl          1/1     Running   0          96s
    

    Quando todos os pods estiverem no estado Running, prossiga para a próxima etapa. Novamente, leva alguns minutos para que todos os pods estejam em um estado Running. É normal que alguns dos pods informem um status READY de 0/1 até que o Cymbal Bank esteja pronto para atender o tráfego corretamente.

  5. O serviço frontend expõe um servidor HTTP para exibir o site do Cymbal Bank, incluindo as páginas de login, de inscrição e inicial. Um objeto Ingress define regras para rotear o tráfego HTTP(S) para aplicativos em execução em um cluster usando um balanceador de carga HTTP(S) do Google Cloud.

    Encontre o endereço IP externo do Ingress frontend:

    kubectl get ingress frontend | awk '{print $4}'
    
  6. Em uma janela do navegador da Web, abra o endereço IP mostrado na saída do comando kubectl get ingress para acessar sua instância do Cymbal Bank.

    As credenciais padrão são preenchidas automaticamente para que você possa fazer login no app e explorar algumas das transações e saldos de amostra. Nenhuma ação específica que você precisa tomar, além de confirmar se o Cymbal Bank é executado com sucesso. Pode levar um ou dois minutos para que todos os serviços estejam se comunicando corretamente e permitam que você faça login.

Explore a implantação

Depois de criar um cluster do GKE e implantar cargas de trabalho, talvez seja necessário alterar as configurações ou analisar o desempenho do aplicativo. Nesta seção, você aprenderá a usar o console do Google Cloud para analisar os recursos que fazem parte do cluster e o aplicativo de amostra Cymbal Bank.

Clusters

Neste tutorial, você criou um cluster do GKE e implantou as cargas de trabalho do Cymbal Bank.

  1. Na página do Google Kubernetes Engine do console do Google Cloud, acesse a página Clusters.

    Acessar a página de clusters

  2. Clique no cluster scalable-apps recém-implantado. Na página de detalhes do cluster aberta, é possível conferir os detalhes básicos, além das configurações de rede e segurança do cluster. Também é possível verificar quais recursos do GKE estão ativados nesse cluster na seção Recursos.

Observabilidade

É possível ver métricas básicas de integridade e desempenho do cluster. No próximo tutorial desta série, você ativará o Google Cloud Managed Service para Prometheus para monitoramento e observabilidade mais granulares.

  1. Selecione o cluster na página Clusters do Google Kubernetes Engine no console do Google Cloud e acesse a guia Observabilidade.

  2. Analise alguns gráficos das métricas relacionadas a CPU e memória, por exemplo. Essa visualização permite monitorar o desempenho de diferentes partes das cargas de trabalho do cluster sem precisar implantar outros recursos de monitoramento.

  3. Para ver os registros transmitidos pelo cluster, selecione a guia Registros. É possível filtrar os registros por Gravidade ou criar seus próprios filtros para ver namespaces, Serviços ou pods específicos. Assim como acontece com os avisos e eventos de pods, essa visualização ordenada de registros do cluster pode ajudar a depurar problemas rapidamente usando o console do Google Cloud.

    É normal ver entradas de registro, já que o Cymbal Bank é implantado pela primeira vez quando alguns serviços ainda não podem se comunicar.

  4. Selecione a guia Erros do aplicativo. À medida que suas cargas de trabalho são executadas, é possível ver os avisos e eventos ordenados no console do Google Cloud. Essa abordagem pode ajudar a depurar problemas sem precisar se conectar individualmente ao cluster, aos nós ou aos pods.

    Novamente, é normal ver eventos registrados, já que o Cymbal Bank é implantado pela primeira vez quando alguns Serviços ainda não podem se comunicar.

Cargas de trabalho

A página do GKE no console do Google Cloud tem uma seção Cargas de trabalho que mostra uma visualização agregada das cargas de trabalho executadas em todos os clusters do GKE.

  1. Na página do Google Kubernetes Engine no console do Google Cloud, acesse a página Cargas de trabalho.

    Acessar a página "Cargas de trabalho"

    A guia Visão geral mostra uma lista de cargas de trabalho e namespaces do cluster do GKE. É possível filtrar por namespaces para saber quais cargas de trabalho estão em execução em cada namespace.

Serviços e entrada

A visualização Serviços e Entrada mostra os recursos de serviço e de entrada do projeto. Um serviço expõe um conjunto de pods como um serviço de rede com um endpoint, enquanto um Ingress gerencia o acesso externo aos serviços em um cluster.

  1. Na página do Google Kubernetes Engine do console do Google Cloud, acesse a página Gateways, Serviços e Ingress.

    Acessar a página "Gateways, Serviços e Ingress"

  2. Para encontrar o entrada do Cymbal Bank, clique na guia Ingress e encontre a entrada com o nome frontend. Uma entrada gerencia o tráfego recebido do seu aplicativo. É possível ver informações sobre o balanceador de carga, as portas e os endpoints externos.

  3. Clique no Endereço IP da entrada frontend, como 198.51.100.143:80. Esse endereço abre a interface da Web do Cymbal Bank.

Limpar

O conjunto de tutoriais do Cymbal Bank foi elaborado para ser concluído um após o outro. À medida que avança no conjunto de tutoriais, você aprende novas habilidades e usa outros produtos e serviços do Google Cloud.

Se você quiser fazer uma pausa antes de avançar para o próximo tutorial e evitar cobranças na sua conta do Google Cloud pelos recursos usados neste tutorial, exclua o projeto criado.

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

A seguir

Aprenda a monitorar suas cargas de trabalho no GKE usando o Google Cloud Managed Service para Prometheus e o Cloud Monitoring no próximo tutorial.