GSP766

Visão geral

Ao considerar soluções de otimização de custos para qualquer infraestrutura do Google Cloud criada com base nos clusters do Google Kubernetes Engine (GKE), é importante fazer uso eficaz dos recursos que estão sendo cobrados. Um erro comum é atribuir aos clusters a proporção de um para um de usuários ou equipes, o que resulta na proliferação de clusters.

Com um cluster de multilocação, vários usuários ou equipes compartilham um cluster para as cargas de trabalho deles, mantendo o isolamento e o compartilhamento justo de recursos. Isso funciona devido à criação de namespaces. Com os namespaces, vários clusters virtuais podem existir no mesmo cluster físico.

Neste laboratório, você vai saber como configurar um cluster de multilocatários usando vários namespaces para otimizar o uso de recursos e, assim, reduzir os custos.

Objetivos

Neste laboratório, você vai aprender a:

• criar vários namespaces em um cluster do GKE;
• Configurar o controle de acesso baseado em papéis para acesso ao namespace.
• Configurar cotas de recursos do Kubernetes para recursos de compartilhamento justo em vários namespaces.
• Acessar e configurar painéis de monitoramento para conferir o uso de recursos por namespace.
• gerar um relatório de medição do GKE no Looker Studio para acessar métricas refinadas sobre o uso dos recursos por namespace.

Configuração e requisitos

Antes de clicar no botão Start Lab

Leia estas instruções. Os laboratórios são cronometrados e não podem ser pausados. O timer é iniciado quando você clica em Começar o laboratório e mostra por quanto tempo os recursos do Google Cloud vão ficar disponíveis.

Este laboratório prático permite que você realize as atividades em um ambiente real de nuvem, não em uma simulação ou demonstração. Você vai receber novas credenciais temporárias para fazer login e acessar o Google Cloud durante o laboratório.

Confira os requisitos para concluir o laboratório:

• Acesso a um navegador de Internet padrão (recomendamos o Chrome).

Observação: para executar este laboratório, use o modo de navegação anônima ou uma janela anônima do navegador. Isso evita conflitos entre sua conta pessoal e a conta de estudante, o que poderia causar cobranças extras na sua conta pessoal.

• Tempo para concluir o laboratório---não se esqueça: depois de começar, não será possível pausar o laboratório.

Observação: não use seu projeto ou conta do Google Cloud neste laboratório para evitar cobranças extras na sua conta.

Como iniciar seu laboratório e fazer login no console do Google Cloud

1. Clique no botão Começar o laboratório. Se for preciso pagar, você verá um pop-up para selecionar a forma de pagamento. No painel Detalhes do laboratório à esquerda, você vai encontrar o seguinte:

   • O botão Abrir console do Google Cloud
   • O tempo restante
   • As credenciais temporárias que você vai usar neste laboratório
   • Outras informações, se forem necessárias

2. Se você estiver usando o navegador Chrome, clique em Abrir console do Google Cloud ou clique com o botão direito do mouse e selecione Abrir link em uma janela anônima.

   O laboratório ativa os recursos e depois abre a página Fazer login em outra guia.

   Dica: coloque as guias em janelas separadas lado a lado.

   Observação: se aparecer a caixa de diálogo Escolher uma conta, clique em Usar outra conta.

3. Se necessário, copie o Nome de usuário abaixo e cole na caixa de diálogo Fazer login.

   {{{user_0.username | "Nome de usuário"}}}

   Você também encontra o Nome de usuário no painel Detalhes do laboratório.

4. Clique em Seguinte.

5. Copie a Senha abaixo e cole na caixa de diálogo de boas-vindas.

   {{{user_0.password | "Senha"}}}

   Você também encontra a Senha no painel Detalhes do laboratório.

6. Clique em Seguinte.

   Importante: você precisa usar as credenciais fornecidas no laboratório, e não as da sua conta do Google Cloud. Observação: se você usar sua própria conta do Google Cloud neste laboratório, é possível que receba cobranças adicionais.

7. Acesse as próximas páginas:

   • Aceite os Termos e Condições.
   • Não adicione opções de recuperação nem autenticação de dois fatores (porque essa é uma conta temporária).
   • Não se inscreva em testes gratuitos.

Depois de alguns instantes, o console do Google Cloud será aberto nesta guia.

Observação: clique em Menu de navegação no canto superior esquerdo para acessar uma lista de produtos e serviços do Google Cloud.

Início

Depois de pressionar o botão Começar o laboratório, você verá a mensagem Provisionando recursos do laboratório em azul com um tempo restante estimado. Ele está criando e configurando o ambiente que você vai usar para testar o gerenciamento de um cluster multilocatário. Em cerca de cinco minutos, um cluster será criado, conjuntos de dados do BigQuery serão copiados e contas de serviço que representam as equipes serão geradas.

Após a conclusão, a mensagem não será mais exibida.

Aguarde a conclusão desse processo de inicialização e a remoção da mensagem antes de continuar com o laboratório.

Ativar o Cloud Shell

O Cloud Shell é uma máquina virtual com várias ferramentas de desenvolvimento. Ele tem um diretório principal permanente de 5 GB e é executado no Google Cloud. O Cloud Shell oferece acesso de linha de comando aos recursos do Google Cloud.

1. Clique em Ativar o Cloud Shell na parte de cima do console do Google Cloud.

Depois de se conectar, vai notar que sua conta já está autenticada, e que o projeto está configurado com seu PROJECT_ID. A saída contém uma linha que declara o projeto PROJECT_ID para esta sessão:

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud é a ferramenta de linha de comando do Google Cloud. Ela vem pré-instalada no Cloud Shell e aceita preenchimento com tabulação.

2. (Opcional) É possível listar o nome da conta ativa usando este comando:

gcloud auth list

3. Clique em Autorizar.

4. A saída será parecida com esta:

Saída:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (Opcional) É possível listar o ID do projeto usando este comando:

gcloud config list project

Saída:

[core] project = <project_ID>

Exemplo de saída:

[core] project = qwiklabs-gcp-44776a13dea667a6 Observação: para conferir a documentação completa da gcloud, acesse o guia com informações gerais sobre a gcloud CLI no Google Cloud.

Tarefa 1: fazer o download dos arquivos necessários

1. Em algumas etapas deste laboratório, usaremos arquivos yaml para configurar o cluster do Kubernetes. No Cloud Shell, faça o download desses arquivos com base em um bucket do Cloud Storage:

gsutil -m cp -r gs://spls/gsp766/gke-qwiklab ~

2. Mude o diretório de trabalho atual para gke-qwiklab:

cd ~/gke-qwiklab

Tarefa 2: conferir e criar namespaces

• Execute o seguinte comando para definir uma zona do Compute padrão e autenticar o cluster multi-tenant-cluster fornecido:

export ZONE={{{project_0.default_zone|placeholder}}} gcloud config set compute/zone ${ZONE} && gcloud container clusters get-credentials multi-tenant-cluster

Namespaces padrão

Por padrão, os clusters do Kubernetes têm quatro namespaces do sistema.

1. É possível conseguir uma lista completa dos namespaces do cluster atual com:

kubectl get namespace

A resposta precisa ser semelhante a esta:

NAME STATUS AGE default Active 5m kube-node-lease Active 5m kube-public Active 5m kube-system Active 5m

• default: o namespace padrão usado quando nenhum outro namespace é especificado.
• kube-node-lease: gerencia os objetos de alocação associados aos sinais de funcionamento de cada um dos nós do cluster.
• kube-public: para recursos que podem precisar estar visíveis ou legíveis para todos os usuários no cluster inteiro.
• kube-system: usado para componentes criados pelo sistema do Kubernetes.

Nem tudo pertence a um namespace. Por exemplo, nós, volumes permanentes e os próprios namespaces não pertencem a um namespace.

2. Para uma lista completa de recursos com namespace:

kubectl api-resources --namespaced=true

Quando criados, os recursos com namespace precisam ser associados a um namespace. Isso é feito pela inclusão da sinalização --namespace ou pela indicação de um namespace no campo de metadados yaml.

3. O namespace também pode ser especificado com qualquer subcomando kubectl get para exibir os recursos de um namespace. Exemplo:

kubectl get services --namespace=kube-system

Todos os serviços no namespace kube-system serão retornados.

Como criar namespaces

Observação: ao criar mais namespaces, evite usar nomes com "kube", já que esse prefixo é reservado para namespaces do sistema.

1. Crie dois namespaces para a equipe A (team-a) e a equipe B (team-b):

kubectl create namespace team-a && \ kubectl create namespace team-b

A resposta do kubectl get namespace precisa incluir os dois novos namespaces:

namespace/team-a created namespace/team-b created

Ao especificar a tag --namespace, você pode criar recursos de cluster no namespace fornecido. Nomes dos recursos, como implantações ou pods, só precisam ser exclusivos nos próprios namespaces.

2. Como exemplo, execute o seguinte comando para implantar um pod nos namespaces das equipes A e B usando o mesmo nome:

kubectl run app-server --image=centos --namespace=team-a -- sleep infinity && \ kubectl run app-server --image=centos --namespace=team-b -- sleep infinity

3. Use o comando kubectl get pods -A para conferir que há dois pods chamados app-server, um para cada namespace de equipe:

kubectl get pods -A

Saída:

NAMESPACE NAME READY STATUS RESTARTS AGE kube-system event-exporter-gke-8489df9489-k2blq 2/2 Running 0 3m41s kube-system fluentd-gke-fmt4v 2/2 Running 0 113s kube-system fluentd-gke-n9dvn 2/2 Running 0 79s kube-system fluentd-gke-scaler-cd4d654d7-xj78p 1/1 Running 0 3m37s kube-system gke-metrics-agent-4jvn8 1/1 Running 0 3m33s kube-system gke-metrics-agent-b4vvw 1/1 Running 0 3m27s kube-system kube-dns-7c976ddbdb-gtrct 4/4 Running 0 3m41s kube-system kube-dns-7c976ddbdb-k9bgk 4/4 Running 0 3m kube-system kube-dns-autoscaler-645f7d66cf-jwqh5 1/1 Running 0 3m36s kube-system kube-proxy-gke-new-cluster-default-pool-eb9986d5-tpql 1/1 Running 0 3m26s kube-system kube-proxy-gke-new-cluster-default-pool-eb9986d5-znm6 1/1 Running 0 3m33s kube-system l7-default-backend-678889f899-xvt5t 1/1 Running 0 3m41s kube-system metrics-server-v0.3.6-64655c969-jtl57 2/2 Running 0 3m kube-system prometheus-to-sd-d6dpf 1/1 Running 0 3m27s kube-system prometheus-to-sd-rfdlv 1/1 Running 0 3m33s kube-system stackdriver-metadata-agent-cluster-level-79f9ddf6d6-7ck2w 2/2 Running 0 2m56s team-a app-server 1/1 Running 0 33s team-b app-server 1/1 Running 0 33s

Clique em Verificar meu progresso para conferir se você executou a tarefa. Criar namespaces

4. Use kubectl describe para conferir mais detalhes de cada um dos pods recém-criados, especificando o namespace com a tag --namespace:

kubectl describe pod app-server --namespace=team-a

5. Para trabalhar exclusivamente com recursos em um namespace, você pode defini-lo uma vez no contexto do kubectl em vez de usar a sinalização --namespace para cada comando:

kubectl config set-context --current --namespace=team-a

6. Depois disso, todos os comandos subsequentes serão executados no namespace indicado sem especificarem a sinalização --namespace:

kubectl describe pod app-server

Na próxima seção, você vai configurar o controle de acesso com base em papéis para seus namespaces a fim de ajudar a organizar o cluster.

Tarefa 3: controle de acesso em namespaces

Para provisionar o acesso a recursos com namespace em um cluster, conceda uma combinação de papéis do IAM e do controle de acesso integrado com base em papéis (RBAC, na sigla em inglês) do Kubernetes. Um papel do IAM concede à conta acesso inicial ao projeto, enquanto as permissões do RBAC concedem acesso granular aos recursos com namespace de um cluster (pods, implantações, serviços etc.).

Papéis do IAM

Observação: para conceder papéis do IAM a um projeto, você precisará ter o papel Administrador do Projeto do IAM atribuído. Isso já foi configurado na conta temporária do Qwiklabs.

Quando você gerencia o controle de acesso do Kubernetes, o Identity and Access Management (IAM) é usado para gerenciar o acesso e as permissões em níveis superiores de organização e projeto.

Há vários papéis que podem ser atribuídos a usuários e contas de serviço no IAM que controlam o nível de acesso deles ao GKE. As permissões granulares do RBAC são baseadas no acesso já fornecido pelo IAM e não podem restringir o acesso concedido por ele. Como resultado, para clusters multilocatários com namespace, o papel do IAM atribuído precisa conceder acesso mínimo.

Veja uma tabela com os papéis os comuns do IAM do GKE:

Papel	Descrição
Administrador do Kubernetes Engine	Concede acesso ao gerenciamento total de clusters e dos respectivos objetos da API Kubernetes. Um usuário com esse papel poderá criar, editar e excluir qualquer recurso em qualquer cluster e nos namespaces subsequentes.
Desenvolvedor do Kubernetes Engine	Concede acesso a objetos da API Kubernetes dentro de clusters. Um usuário com esse papel poderá criar, editar e excluir recursos em qualquer cluster e nos namespaces subsequentes.
Administrador de cluster do Kubernetes Engine	Concede acesso ao gerenciamento de clusters. Um usuário com esse papel não terá acesso para criar ou editar recursos diretamente nos clusters ou nos namespaces subsequentes, mas poderá criar, modificar e excluir qualquer cluster.
Leitor do Kubernetes Engine	Fornece acesso somente leitura aos recursos do GKE. Um usuário com esse papel terá acesso somente leitura aos namespaces e aos recursos deles.
Leitor de cluster do Kubernetes Engine	Concede acesso para receber e listar clusters do GKE. Esse é o papel mínimo necessário para quem precisar acessar recursos nos namespaces de um cluster.

A maioria desses papéis concede acesso excessivo que será restrito com o RBAC, mas o papel do IAM de Leitor de cluster do Kubernetes Engine dá aos usuários apenas permissões suficientes para acessar o cluster e os recursos com namespace.

O projeto do laboratório tem uma conta de serviço que vai representar o desenvolvedor a usar o namespace team-a.

• Conceda o papel de Leitor de cluster do Kubernetes Engine à conta executando o seguinte comando:

gcloud projects add-iam-policy-binding ${GOOGLE_CLOUD_PROJECT} \ --member=serviceAccount:team-a-dev@${GOOGLE_CLOUD_PROJECT}.iam.gserviceaccount.com \ --role=roles/container.clusterViewer

Controle de acesso baseado em função (RBAC, na sigla em inglês) no Kubernetes

Em um cluster, o acesso a qualquer tipo de recurso (pods, serviços, implantações etc.) é definido por um papel ou um papel de cluster. Somente papéis têm o escopo definido para um namespace. Enquanto um papel indica os recursos e a ação permitida para cada recurso, uma vinculação de papel indica a quais contas ou grupos de usuários é preciso atribuir esse acesso.

Para criar um papel no namespace atual, especifique o tipo de recurso e os verbos que indicarão o tipo de ação que será permitido.

1. Papéis com regras únicas podem ser criados com kubectl create:

kubectl create role pod-reader \ --resource=pods --verb=watch --verb=get --verb=list

Os papéis com várias regras podem ser criados usando um arquivo yaml. Há um exemplo de arquivo junto com os arquivos de que você fez download anteriormente no laboratório.

2. Inspecione o arquivo yaml:

cat developer-role.yaml

Exemplo de resposta:

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: team-a name: developer rules: - apiGroups: [""] resources: ["pods", "services", "serviceaccounts"] verbs: ["update", "create", "delete", "get", "watch", "list"] - apiGroups:["apps"] resources: ["deployments"] verbs: ["update", "create", "delete", "get", "watch", "list"]

3. Aplique o papel acima:

kubectl create -f developer-role.yaml

4. Crie uma vinculação de papel entre a conta de serviço de desenvolvedores da equipe A e a função de desenvolvedor:

kubectl create rolebinding team-a-developers \ --role=developer --user=team-a-dev@${GOOGLE_CLOUD_PROJECT}.iam.gserviceaccount.com

Teste a vinculação de papéis

1. Faça o download das chaves usadas para personificar a conta de serviço:

gcloud iam service-accounts keys create /tmp/key.json --iam-account team-a-dev@${GOOGLE_CLOUD_PROJECT}.iam.gserviceaccount.com

Clique em Verificar meu progresso para conferir se você executou a tarefa. Controle de acesso em namespaces

2. No Cloud Shell, clique em + para abrir uma nova guia no terminal.

3. Execute o comando abaixo para ativar a conta de serviço. Assim você poderá executar os comandos como a conta:

gcloud auth activate-service-account --key-file=/tmp/key.json

4. Encontre as credenciais do cluster, como a conta de serviço:

export ZONE={{{project_0.default_zone|placeholder}}} gcloud container clusters get-credentials multi-tenant-cluster --zone ${ZONE} --project ${GOOGLE_CLOUD_PROJECT}

5. Você verá que, como desenvolvedor da equipe A, é possível listar pods no namespace team-a:

kubectl get pods --namespace=team-a

Saída:

NAME READY STATUS RESTARTS AGE app-server 1/1 Running 0 6d

6. Mas a listagem de pods no namespace team-b é restrita:

kubectl get pods --namespace=team-b

Saída:

Error from server (Forbidden): pods is forbidden: User "team-a-dev@a-gke-project.iam.gserviceaccount.com" cannot list resource "pods" in API group "" in the namespace "team-b": requires one of ["container.pods.list"] permission(s).

7. Volte para a primeira guia do Cloud Shell ou abra uma nova.

8. Renove as credenciais do cluster e redefina o contexto para o namespace team-a:

export ZONE={{{project_0.default_zone|placeholder}}} gcloud container clusters get-credentials multi-tenant-cluster --zone ${ZONE} --project ${GOOGLE_CLOUD_PROJECT}

Tarefa 4: cotas de recursos

Quando um cluster é compartilhado em uma configuração de multilocatários, é importante garantir que os usuários não possam usar mais do que a parte justa dos recursos do cluster. Um objeto de cota de recurso (ResourceQuota) definirá restrições que limitarão o consumo de recursos em um namespace. Uma cota de recursos pode especificar um limite para as contagens de objetos (pods, serviços, conjuntos com estado etc.), a soma total dos recursos de armazenamento (reivindicações de volume permanente, armazenamento temporário, classes de armazenamento) ou a soma total dos recursos de computação (CPU e memória).

1. Por exemplo, o seguinte código vai definir um limite ao número de pods permitidos no namespace team-a como dois e o número de balanceadores de carga como um:

kubectl create quota test-quota \ --hard=count/pods=2,count/services.loadbalancers=1 --namespace=team-a

2. Crie um segundo pod no namespace team-a:

kubectl run app-server-2 --image=centos --namespace=team-a -- sleep infinity

3. Agora tente criar um terceiro pod:

kubectl run app-server-3 --image=centos --namespace=team-a -- sleep infinity

Você vai encontrar o seguinte erro:

Error from server (Forbidden): pods "app-server-3" is forbidden: exceeded quota: test-quota, requested: count/pods=1, used: count/pods=2, limited: count/pods=2

4. É possível verificar detalhes sobre sua cota de recursos usando kubectl describe:

kubectl describe quota test-quota --namespace=team-a

Saída:

Name: test-quota Namespace: team-a Resource Used Hard -------- ---- ---- count/pods 2 2 count/services.loadbalancers 0 1

Aqui você encontra uma lista de recursos restritos pela cota, além do limite absoluto configurado e da quantidade atual de recursos.

5. Atualize a test-quota para ter um limite de seis pods em execução:

export KUBE_EDITOR="nano" kubectl edit quota test-quota --namespace=team-a

Você poderá editar um arquivo yaml que o kubectl usará para atualizar a cota. A cota absoluta é o valor para count/pods em spec.

5. Mude o valor de count/pods na especificação para 6:

apiVersion: v1 kind: ResourceQuota metadata: creationTimestamp: "2020-10-21T14:12:07Z" name: test-quota namespace: team-a resourceVersion: "5325601" selfLink: /api/v1/namespaces/team-a/resourcequotas/test-quota uid: a4766300-29c4-4433-ba24-ad10ebda3e9c spec: hard: count/pods: "6" count/services.loadbalancers: "1" status: hard: count/pods: "5" count/services.loadbalancers: "1" used: count/pods: "2"

6. Pressione ctrl + X, Y e Enter para salvar e sair.

A cota atualizada será refletida na resposta:

kubectl describe quota test-quota --namespace=team-a

Saída:

Name: test-quota Namespace: team-a Resource Used Hard -------- ---- ---- count/pods 2 6 count/services.loadbalancers 0 1

Cotas de CPU e memória

Ao definir cotas para CPU e memória, você pode indicar uma cota para a soma das solicitações (um valor que um contêiner tem a garantia de receber) ou a soma dos limites (um valor que um contêiner nunca terá permissão para transmitir).

Neste laboratório, o cluster tem quatro máquinas e2-standard-2, com dois núcleos e 8 GB de memória cada. Você recebeu um arquivo yaml de cota de recursos de amostra para seu cluster:

cpu-mem-quota.yaml

apiVersion: v1 kind: ResourceQuota metadata: name: cpu-mem-quota namespace: team-a spec: hard: limits.cpu: "4" limits.memory: "12Gi" requests.cpu: "2" requests.memory: "8Gi"

1. Aplique a configuração do arquivo:

Observação: verifique se você ainda está no diretório gke-qwiklab. kubectl create -f cpu-mem-quota.yaml

Com essa cota ativada, a soma das solicitações de CPU e memória de todos os pods será limitada a 2 CPU e 8 GiB, além dos limites em 4 CPU e 12 GiB, respectivamente.

Observação: quando existe uma cota de recursos para CPU ou memória em um namespace, cada contêiner criado nesse namespace precisa ter o próprio limite de CPU e memória definido na criação ou ter um valor padrão atribuído no namespace como um intervalo de limite.

2. Para demonstrar a cota de CPU e memória, crie um novo pod usando cpu-mem-demo-pod.yaml:

cpu-mem-demo-pod.yaml:

apiVersion: v1 kind: Pod metadata: name: cpu-mem-demo namespace: team-a spec: containers: - name: cpu-mem-demo-ctr image: nginx resources: requests: cpu: "100m" memory: "128Mi" limits: cpu: "400m" memory: "512Mi"

3. Aplique a configuração do arquivo:

kubectl create -f cpu-mem-demo-pod.yaml --namespace=team-a

4. Depois que esse pod for criado, execute o seguinte comando para acessar as solicitações de CPU e memória e os limites refletidos na cota:

kubectl describe quota cpu-mem-quota --namespace=team-a

Saída:

Name: cpu-mem-quota Namespace: team-a Resource Used Hard -------- ---- ---- limits.cpu 400m 4 limits.memory 512Mi 12Gi requests.cpu 100m 2 requests.memory 128Mi 8Gi

Clique em Verificar meu progresso para conferir se você executou a tarefa. Cotas de recursos

Tarefa 5: monitorar o GKE e a medição de uso do GKE

Para a maioria dos clusters multilocatários, é provável que as cargas de trabalho e os requisitos de recursos de cada locatário sejam modificados, e as cotas de recursos talvez precisem ser ajustadas. Ao usar o Monitoring, você pode ter uma visão geral dos recursos usados em cada namespace.

Com a medição de uso do GKE, você tem uma visão mais granular do uso de recursos e, assim, uma ideia melhor dos custos associados a cada locatário.

Painel de monitoramento

1. No console do Cloud, expanda o menu de navegação na parte de cima à esquerda na página e depois selecione Operações > Monitoramento nesse menu.

Aguarde um minuto enquanto o espaço de trabalho do seu projeto é construído.

2. Na página "Informações gerais", selecione Painéis no menu à esquerda:

3. Selecione GKE na página Visão geral de painéis.

O painel do GKE apresenta uma coleção de tabelas que detalham a utilização de CPU, memória e disco agregadas por diversos recursos.

Por exemplo, a tabela de namespaces mostrará a utilização de cada um dos namespaces dos clusters:

Também é possível conferir os dados de utilização das cargas de trabalho em execução no cluster na tabela "Cargas de trabalho".

4. Clique em Ver tudo.

5. Na caixa ADICIONAR FILTRO selecione Namespaces > team-a.

6. Em seguida, clique em Aplicar.

Isso vai filtrar as cargas de trabalho para incluir apenas aquelas em execução no namespace team-a:

Metrics Explorer

1. No painel à esquerda, selecione Metrics Explorer:

2. No campo "Selecionar uma métrica", clique no menu suspenso Métrica.

3. Digite Kubernetes Container em "Filtrar por nome da métrica e do recurso".

4. Clique em Contêiner do Kubernetes > Contêiner.

5. Selecione Tempo de uso da CPU.

6. Clique em Aplicar.

Observação: digite cp no campo da métrica para exibir o tempo de uso da CPU como uma opção em um menu suspenso.

7. Para excluir o namespace kube-system, clique em Adicionar filtro na seção de filtro.

8. Selecione namespace_name como um rótulo.

9. Selecione != (does not equal) como a comparação e kube-system como o valor.

10. No menu suspenso Agregação, selecione Sum, defina a ordenação como namespace_name e clique em OK.

    Depois disso, você verá um gráfico que mostra o tempo de uso da CPU do contêiner por namespace:

Medição de uso do GKE

A medição de uso do GKE permite exportar a utilização e o consumo de recursos do cluster do GKE para um conjunto de dados do BigQuery e acessar usando o Looker Studio. Isso permite uma visualização mais granular do uso de recursos. Com a medição de uso, é possível tomar decisões mais fundamentadas sobre cotas de recursos e configuração eficiente de clusters.

Observação: como pode demorar várias horas para os dados de métricas do GKE preencherem o BigQuery, seu projeto de laboratório inclui conjuntos de dados do BigQuery com dados de uso de recursos simulados e de faturamento para fins demonstrativos.

Os dois conjuntos de dados a seguir foram adicionados ao seu projeto:

cluster_dataset: conjunto de dados criado manualmente antes de ativar a medição de uso do GKE no cluster. Esse conjunto de dados contém duas tabelas geradas pelo GKE (gke_cluster_resource_consumption e gke_cluster_resource_usage) e é atualizado continuamente com as métricas de uso do cluster.

billing_dataset: é um conjunto de dados criado manualmente antes de ativar a exportação do BigQuery para faturamento. Esse conjunto de dados contém uma tabela (gcp_billing_export_v1_xxxx) e é atualizado diariamente com os custos diários de um projeto.

• Execute o seguinte comando para ativar a medição de uso do GKE no cluster e especificar o conjunto de dados cluster_dataset:

export ZONE={{{project_0.default_zone|placeholder}}} gcloud container clusters \ update multi-tenant-cluster --zone ${ZONE} \ --resource-usage-bigquery-dataset cluster_dataset

Crie a tabela de detalhamento de custos do GKE

É possível gerar uma tabela cost_breakdown com base nas tabelas de faturamento e de uso de recursos no seu projeto. Você vai gerar essa tabela no conjunto de dados do cluster usando o arquivo usage_metering_query_template.sql. Esse template está disponível em Noções básicas sobre o uso de recursos do cluster.

Primeiro defina algumas variáveis de ambiente no Cloud Shell.

1. Defina o caminho da tabela de faturamento fornecida, o conjunto de dados de medição de uso fornecido e um nome para a nova tabela de detalhamento de custos:

export GCP_BILLING_EXPORT_TABLE_FULL_PATH=${GOOGLE_CLOUD_PROJECT}.billing_dataset.gcp_billing_export_v1_xxxx export USAGE_METERING_DATASET_ID=cluster_dataset export COST_BREAKDOWN_TABLE_ID=usage_metering_cost_breakdown

2. Agora especifique o caminho do modelo de consulta de medição de uso transferido por download no início deste laboratório, um arquivo de saída para a consulta de medição de uso que será gerada e uma data de início para os dados (a data mais antiga dos dados é 2020-10-26):

export USAGE_METERING_QUERY_TEMPLATE=~/gke-qwiklab/usage_metering_query_template.sql export USAGE_METERING_QUERY=cost_breakdown_query.sql export USAGE_METERING_START_DATE=2020-10-26

3. Com essas variáveis de ambiente e o modelo de consulta, gere a consulta de medição de uso:

sed \ -e "s/\${fullGCPBillingExportTableID}/$GCP_BILLING_EXPORT_TABLE_FULL_PATH/" \ -e "s/\${projectID}/$GOOGLE_CLOUD_PROJECT/" \ -e "s/\${datasetID}/$USAGE_METERING_DATASET_ID/" \ -e "s/\${startDate}/$USAGE_METERING_START_DATE/" \ "$USAGE_METERING_QUERY_TEMPLATE" \ > "$USAGE_METERING_QUERY"

4. Execute o comando a seguir para configurar sua tabela de detalhamento de custos usando a consulta renderizada na etapa anterior:

bq query \ --project_id=$GOOGLE_CLOUD_PROJECT \ --use_legacy_sql=false \ --destination_table=$USAGE_METERING_DATASET_ID.$COST_BREAKDOWN_TABLE_ID \ --schedule='every 24 hours' \ --display_name="GKE Usage Metering Cost Breakdown Scheduled Query" \ --replace=true \ "$(cat $USAGE_METERING_QUERY)"

5. A Transferência de dados deve fornecer um link para autorização. Clique nele, faça login com sua conta de aluno, siga as instruções e cole o version_info no Cloud Shell.

Em seguida, ela retornará uma mensagem indicando que a configuração de transferência foi criada.

Crie a origem de dados no Looker Studio

1. Abra a Página de origem de dados do Looker Studio.

2. Na parte de cima à direita, clique em Criar > Origem de dados para adicionar uma nova origem de dados.

Primeiro, será exibida a janela Para começar, vamos concluir a configuração da sua conta.

3. Marque a caixa de confirmação e clique em Continuar.

4. Selecione Não para cada Configurar suas preferências de e-mail, porque estamos usando uma conta e laboratório temporários.

5. Clique em Continuar.

Você receberá uma lista de conectores do Google compatíveis com o Looker Studio.

6. Selecione BigQuery na lista.

7. Clique no botão Autorizar para permitir que o Looker Studio acesse seu projeto do BigQuery.

8. Na parte de cima à esquerda da página, renomeie a origem de dados de Untitled Data Source para GKE Usage.

9. Na primeira coluna, selecione CONSULTA PERSONALIZADA.

10. Selecione o ID do projeto na coluna de projetos.

11. Digite o seguinte comando na caixa de consulta personalizada e substitua [PROJECT-ID] pelo ID do projeto do Qwiklabs:

SELECT * FROM `[PROJECT-ID].cluster_dataset.usage_metering_cost_breakdown`

12. Clique em CONECTAR.

Clique em Verificar meu progresso para conferir se você executou a tarefa. Como monitorar o GKE e a medição de uso do GKE

13. Em seguida, clique na parte de cima à direita.

Agora que a fonte foi adicionada, você pode usá-la para criar um relatório.

1. Na parte de cima da página da origem de dados, clique em CRIAR RELATÓRIO.

Observação: se você receber um erro neste momento, pode ser que seu job de transferência de dados ainda não tenha sido concluído. Aguarde um minuto e tente novamente.

Ao criar um novo relatório a partir de uma origem de dados, você precisará adicionar dados a ele.

2. Clique em ADICIONAR AO RELATÓRIO.

Criar um relatório do Looker Studio

No relatório, você poderá visualizar as métricas de uso da origem de dados com base na sua tabela do BigQuery.

Você vai começar com uma tabela simples:

Configure essa tabela para mostrar um detalhamento de custos por namespace. Com a tabela selecionada, você vai ver os dados relacionados a ela no painel à direita.

1. Mude o seguinte nesse painel:

• Dimensão do período: usage_start_time
• Dimensão: namespace
• Métrica: cost

Não mude os valores padrão dos outros campos.

Para limitar sua tabela a recursos com namespace, aplique um filtro.

2. No painel de dados, clique em Adicionar um filtro na seção "Filtro". Crie um filtro para excluir os recursos não alocados a um namespace:

3. Clique em Salvar.

4. Clique novamente em Adicionar um filtro e Criar um filtro para criar um segundo filtro que limita os dados às solicitações:

5. Clique em Salvar para aplicar o filtro. A tabela resultante terá esta aparência:

Em seguida, você vai adicionar um gráfico de pizza ao seu relatório que mostra o detalhamento de custos por namespace.

6. Clique com o botão direito do mouse na tabela que você criou e selecione Duplicar.

7. Arraste o objeto da tabela duplicada para qualquer lugar do relatório.

8. Em seguida, clique no cabeçalho do painel de configuração:

9. Nas opções apresentadas, clique no ícone do gráfico de pizza:

O gráfico de pizza resultante será semelhante a este:

Em seguida, adicione um gráfico de rosca que vai mostrar o detalhamento do custo por tipo de recurso.

1. Na barra de ferramentas superior, clique em Adicionar um gráfico e selecione (Rosca) para criar um gráfico de rosca.

2. Arraste o gráfico para qualquer parte do relatório e configure-o com o seguinte:

• Dimensão do período: usage_start_time
• Dimensão: resource_name
• Métrica: cost

3. Clique em Adicionar um filtro e selecione os dois filtros aplicados ao gráfico anterior. O gráfico de rosca resultante será semelhante a este:

4. Para adicionar um detalhamento por namespace, na barra de ferramentas superior, clique em Adicionar um controle e selecione Lista suspensa.

5. Arraste-o até o lado do gráfico de rosca e configure-o com o seguinte comando:

• Dimensão do período: usage_start_time
• Campo de controle: namespace
• Métrica: None

6. Clique em Adicionar um filtro.

7. Selecione não alocado (filtro do namespace) na lista.

8. A fim de configurar o controle para que afete apenas o gráfico de rosca, selecione o objeto de controle e o gráfico de rosca usando o cursor seletor para desenhar um retângulo em torno dos dois objetos.

9. Clique com o botão direito do mouse e selecione Grupo para vinculá-los a um grupo:

10. Para visualizar seu relatório, clique em Visualizar na barra de ferramentas superior.

No modo de visualização, é possível ajustar a visualização do gráfico de rosca para um namespace específico:

11. No menu Compartilhar na parte de cima da página, clique em Fazer download do relatório para salvar uma cópia do relatório completo como um arquivo PDF.

Parabéns!

Com os namespaces, é possível configurar clusters como multilocatários, minimizar o risco de subutilização de recursos e proliferação de clusters, além de evitar custos adicionais. Ao usar o monitoramento e a medição do GKE, também é possível visualizar o uso de recursos por namespaces para tomar decisões mais fundamentadas sobre cotas de recursos e a configuração dos clusters.

Próximas etapas / Saiba mais

• Documentos de multilocação de cluster
• Práticas recomendadas para executar aplicativos econômicos do Kubernetes no GKE

Treinamento e certificação do Google Cloud

Esses treinamentos ajudam você a aproveitar as tecnologias do Google Cloud ao máximo. Nossas aulas incluem habilidades técnicas e práticas recomendadas para ajudar você a alcançar rapidamente o nível esperado e continuar sua jornada de aprendizado. Oferecemos treinamentos que vão do nível básico ao avançado, com opções de aulas virtuais, sob demanda e por meio de transmissões ao vivo para que você possa encaixá-las na correria do seu dia a dia. As certificações validam sua experiência e comprovam suas habilidades com as tecnologias do Google Cloud.

Manual atualizado em 2 de fevereiro de 2024

Laboratório testado em 2 de fevereiro de 2024

Copyright 2024 Google LLC. Todos os direitos reservados. Google e o logotipo do Google são marcas registradas da Google LLC. Todos os outros nomes de produtos e empresas podem ser marcas registradas das respectivas empresas a que estão associados.