Observar cargas de trabalho hierárquicas

Beta

Este produto está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço Gerais" dos Termos Específicos do Serviço. Os produtos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Controlador de hierarquia oferece melhor observabilidade nas cargas de trabalho usando o hierárquico eabstrato namespaces no cluster. Isso é feito propagando os rótulos de árvore do cluster para os pods, disponibilizando-os para qualquer sistema que possa ingerir rótulos do Kubernetes, incluindo:

• Consultas nativas do Kubernetes para pods
• Cloud Logging
• Medição de uso do GKE

Por exemplo, considere uma carga de trabalho em execução em um namespace do repositório de exemplo de herança de namespace. O repositório de exemplo de herança de namespace tem a seguinte arquitetura:

├── namespaces # Namespace directory
│   ├── eng # Namespace directory
│   │   ├── analytics # Abstract namespace directory
│   │   └── gamestore # Abstract namespace directory
│   ├── rnd # Namespace directory
│   │   ├── incubator-1 # Abstract namespace directory
│   │   └── incubator-2 # Abstract namespace directory
|   |── network-policy-default-deny-all.yaml
|   |── viewers-rolebinding.yaml

Com o controlador de hierarquia, você seleciona pods, registros ou medição de uso gerados por qualquer carga de trabalho descendente de eng, rnd ou qualquer outro namespace abstrato. Isso inclui as cargas de trabalho nos namespaces localizados no repositório do Git, como gamestore, e qualquer namespace filho de controle de hierarquia que você possa criar como descendente deles.

Ativar observabilidade hierárquica

Observação: a observabilidade hierárquica não é compatível com clusters do Autopilot no momento.

A observabilidade hierárquica é fornecida pelo controlador de hierarquia. Para ativar a observabilidade hierárquica, faça o seguinte:

1. Instale o Hierarchy Controller.

2. No arquivo de configuração do ConfigManagement Operator, no objeto spec.hierarchyController, defina o valor de enablePodTreeLabels como true:

   # config-management.yaml
   
   apiVersion: configmanagement.gke.io/v1
   kind: ConfigManagement
   metadata:
     name: config-management
   spec:
     hierarchyController:
       enabled: true
       # Set to true to enable hierarchical observability:
       enablePodTreeLabels: true
     # ...other fields...
   

3. Aplique a configuração:

   kubectl apply -f config-management.yaml
   

   Depois de cerca de um minuto, é possível utilizar o controlador de hierarquia e a observabilidade hierárquica no cluster.

Quando a capacidade de observabilidade hierárquica é ativada, o controlador de hierarquia instala um webhook de admissão mutável (em inglês) para adicionar os rótulos de árvore aos pods. Para verificar se esse webhook está funcionando corretamente:

1. Inicie uma carga de trabalho em qualquer namespace, como o exemplo a seguir:

   kubectl run websvr --image=nginx --namespace default --generator=run-pod/v1
   

2. Inspecione o pod e verifique se ele contém o rótulo default.tree.hnc.x-k8s.io/depth:

   kubectl describe pod --namespace default websvr
   

   Saída:

   Name:         websvr
   Namespace:    default
   # ...other fields...
   Labels:       default.tree.hnc.x-k8s.io/depth=0 # This is the Pod tree label
                 # ...other labels...
   # ...other fields...
   

3. Limpe a carga de trabalho:

   kubectl delete pod --namespace default websvr
   

Os pods atuais não recebem os rótulos da árvore de pods. Esses rótulos só são adicionados aos pods novos. Para mais informações, consulte Limitações, mais adiante neste documento.

Usar a observabilidade de carga de trabalho hierárquica

Depois que os rótulos de árvore de pod forem ativados, eles poderão ser usados para melhorar a observabilidade da carga de trabalho hierárquica tanto em clusters quanto em outros produtos do Google Cloud.

Consultar pods por hierarquia

Qualquer operação do Kubernetes que inclua um seletor de rótulos pode ser usada para consultar os rótulos de árvore de pods. Por exemplo, use esta consulta para ver todos os pods em todos os namespaces sendo executados em um descendente do namespace default:

kubectl get pods --all-namespaces -l default.tree.hnc.x-k8s.io/depth

Saída com base na carga de trabalho de amostra que criamos para verificar a instalação:

NAMESPACE   NAME     READY   STATUS    RESTARTS   AGE
default     websvr   1/1     Running   0          70s

Consultar o Cloud Logging por hierarquia

O Cloud Logging aceita um formato para rótulos um pouco diferente do que é aceito no Kubernetes. Por exemplo, para pesquisar qualquer carga de trabalho em execução em um descendente do namespace default, em vez de pesquisar o rótulo do Kubernetes default.tree.hnc.x-k8s.io/depth, o Cloud Logging espera uma consulta semelhante à esta no Console do Google Cloud:

resource.type="k8s_container" labels.k8s-pod/default_tree_hnc_x-k8s_io/depth!=""

Como alternativa, use um filtro semelhante no Google Cloud CLI:

gcloud logging read "resource.type=k8s_container AND labels.k8s-pod/default_tree_hnc_x-k8s_io/depth!=''"

Consultar a medição de uso do GKE por hierarquia

É possível usar rótulos de árvore de pods para atribuir solicitações e usos, desde a medição de uso do GKE a árvores de namespace. Para ativar a medição hierárquica de uso:

1. Ative a medição de uso regular do GKE no cluster.

2. Confirme se os dados estão sendo ingeridos para o BigQuery. No console do Google Cloud, acesse o BigQuery.

   Acessar o BigQuery

3. Procure por gke_cluster_resource_consumption.

   

   Exemplo de importação de dados bem-sucedida para o BigQuery

4. Siga as orientações da seção pré-requisitos para ativar a medição de uso do cluster do GKE.

5. Abra o Looker Studio, clique em Relatório em branco e selecione BigQuery como a fonte de dados.

6. Selecione Consulta personalizada e procure o ID do projeto. Na caixa de texto à direita, digite sua consulta personalizada. Para ver exemplos das consultas personalizadas, consulte as seções a seguir.

Exemplo: uso total de cada subárvore

Essa consulta retorna o uso de todos os namespaces regulares, abstratos e hierárquicos do cluster, incluindo todos os descendentes:

SELECT
  REGEXP_EXTRACT(label.key, r"^[a-zA-Z0-9\-]+") as subtree,
  resource_name,
  usage.unit,
  SUM(usage.amount) AS usage_amount
FROM
  `PROJECT_NAME.DATASET_NAME.TABLE_NAME`,
  UNNEST(labels) AS label
WHERE
  regexp_contains(label.key, "tree.hnc.x-k8s.io/depth")
GROUP BY
  subtree,
  resource_name,
  usage.unit
ORDER BY
  resource_name ASC,
  subtree ASC

Exemplo de saída parcial:

subárvore	resource_name	unit	usage_amount
a	cpu	segundos	0,09
a1	cpu	segundos	0,09
a2	cpu	segundos	0
a	memory	byte-seconds	6,315,303,690,240
a1	memory	byte-seconds	1.355.268.587.520
a2	memory	byte-seconds	4.960.035.102.720

Neste exemplo, o uso atribuído ao namespace a inclui o uso dos namespaces descendentes a1 e a2, que também são mostrados.

Exemplo: uso de uma única subárvore

Esta consulta exibe a quantidade total de uso no namespace a e em todos os namespaces descendentes:

SELECT
  resource_name,
  usage.unit,
  SUM(usage.amount) AS usage_amount
FROM
  `PROJECT_NAME.DATASET_NAME.TABLE_NAME`,
  UNNEST(labels) AS label
WHERE
  label.key="SUBTREE_NAME.tree.hnc.x-k8s.io/depth"
GROUP BY
  resource_name,
  usage.unit

Exemplo de saída para o namespace a:

resource_name	unit	usage_amount
cpu	segundos	0,09
memory	byte-seconds	6,315,303,690,240

Exemplo: uso de todos os namespaces em uma subárvore

Essa consulta exibe o uso individual de cada namespace em uma determinada subárvore:

SELECT
  namespace,
  resource_name,
  SUM(usage.amount) AS usage_amount
FROM
  `PROJECT_NAME.DATASET_NAME.TABLE_NAME`,
  UNNEST(labels) AS label
WHERE
  label.key="SUBTREE_NAME.tree.hnc.x-k8s.io/depth"
GROUP BY
  namespace,
  resource_name

Exemplo de saída para o namespace a:

namespace	resource_name	usage_amount
a2	memory	4.960.035.102.720
a1	memory	1.355.268.587.520
a2	cpu	0
a1	cpu	0,09

O namespace a não contém uso, por isso não é listado nos resultados desta consulta.

Limitações do monitoramento hierárquico

Veja a seguir as limitações do monitoramento hierárquico.

As alterações na hierarquia são ignoradas

Os rótulos de árvores de pods são adicionados aos pods quando são criados e não sofrem alterações depois que a execução do pod começa. Isso significa que os pods iniciados antes da ativação do monitoramento hierárquico não recebem rótulos da árvore de pods.

Além disso, os pods que tiverem uma hierarquia alterada após a inicialização, como ao usar o controlador de hierarquia para alterar o pai de um namespace, não terão os rótulos atualizados. Embora as modificações de hierarquia normalmente sejam raras, se essa situação ocorrer e causar um problema, reinicie todos os pods afetados após modificar a hierarquia.

Os pods ainda são criados mesmo que os rótulos não possam ser aplicados

O monitoramento hierárquico não se aplica a pods que estão sendo executados em namespaces importantes do sistema, como kube-system ou hnc-system. No entanto, a própria configuração do webhook não pode excluir esses namespaces. Sendo assim, se o controlador de hierarquia encontrar um problema, a criação de pods em todos os namespaces poderá ser afetada.

Como resultado, em vez de arriscar uma interrupção em todo o cluster, se o controlador de hierarquia não puder processar um pod em dois segundos, o webhook falhará e permitirá que o pod seja criado sem os rótulos. Essas falhas de webhook podem ser monitoradas por meio do servidor da API Kubernetes ao procurar falhas do webhook de admissão mutável podlabel.hierarchycontroller.configmanagement.gke.io.

A seguir

• Usar cotas de recursos hierárquicos.

• Saiba mais sobre tarefas comuns que podem ser realizadas pelo HNC no Guia do usuário do HNC: instruções.