Como observar cargas de trabalho hierárquicas

O controlador de hierarquia e o Cloud Logging trabalham juntos para permitir que você tenha melhor observabilidade nas cargas de trabalho com base na estrutura hierárquica dos namespaces do cluster.

O Cloud Logging permite analisar ou rotear registros das cargas de trabalho de acordo com vários critérios, como nome do cluster, namespace do Kubernetes ou rótulos do pod do Kubernetes. O controlador de hierarquia estende esses critérios para incluir namespaces hierárquicos e abstratos propagando os rótulos de árvore do cluster para os pods, disponibilizando-os para o Logging.

Por exemplo, pense em uma carga de trabalho em execução em um namespace do repositório de exemplo (em inglês).

Com o controlador de hierarquia, você seleciona registros gerados por qualquer carga de trabalho descendente de shipping-app-backend, online ou de qualquer outro namespace abstrato. Isso inclui as cargas de trabalho nos namespaces localizados no repositório do Git, como shipping-prod, e qualquer subnamespace de controle de hierarquia que você possa criar como descendente deles.

Como ativar a observabilidade hierárquica

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

  1. No arquivo de configuração do operador do Config Sync, no objeto spec.hierarchyController, defina o valor de enabled e enablePodTreeLabels como true:

    # config-management.yaml
    
    apiVersion: configmanagement.gke.io/v1
    kind: ConfigManagement
    metadata:
      name: config-management
    spec:
      # Set to true to enable hierarchical namespaces and logging
      hierarchyController:
        enabled: true
        enablePodTreeLabels: true
      # ...other fields...
    
  2. 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.

Como verificar a instalação

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. Esses rótulos são ingeridos pelo Cloud Logging e disponibilizados para analisar ou encaminhar registros. Esses rótulos também podem ser ingeridos por qualquer outro sistema que entenda os rótulos do Kubernetes.

Para verificar se o registro hierárquico está ativado, siga estas etapas:

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

    kubectl run websvr --image=nginx -n 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 -n 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
                  run=websvr
    # ...other fields...
    
  3. Limpe a carga de trabalho:

    kubectl delete pod -n default websvr
    

Como 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.

Como 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 anterior:

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

Como filtrar registros 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 ao seguinte 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 na ferramenta de linha de comando gcloud:

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

Como filtrar o uso 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. A medição de uso hierárquico exige que a medição de uso regular do GKE tenha sido ativada:

  1. Ative a medição de uso do GKE no cluster.
  2. Confirme se os dados estão sendo ingeridos para o BigQuery. No Console do Cloud, acesse o BigQuery.

    Ir para o BigQuery

  3. Procure por gke_cluster_resource_consumption.

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

  5. Abra o Google Data Studio, clique em Relatório em branco e selecione BigQuery como origem dos 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

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:

subárvore resource_name unit usage_amount
a cpu segundos 0,09
a1 cpu segundos 0,09
a2 cpu segundos 0
config-management-system cpu segundos 9.252,45
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
config-management-system memory byte-seconds 49.986.574.663.680

Essa saída mostra o recurso e o uso da nuvem total atribuídos ao namespace a e individualmente para os namespaces descendentes a1 e a2.

Exemplo: uso de uma única subárvore

O exemplo a seguir mostra a quantidade total de uso no namespace a e em todos os seus namespaces filhos.

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:

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

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:

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

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 geralmente sejam raras, se essa situação ocorrer e causar um problema, modifique a hierarquia e reinicie todos os pods.

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 (em inglês) ao procurar falhas do webhook de admissão mutável podlabel.hierarchycontroller.configmanagement.gke.io.

A seguir