Monitorando o Kubernetes

• IBM Cloud Kubernetes Service Gerenciamento de monitoramento e desempenho
• Amazon Elastic Container Service for Kubernetes (EKS)
• Azure Kubernetes Service (AKS)
• Google Kubernetes Engine ( GKE ) - Apenas na versão padrão GKE. GKE O Enterprise (anteriormente Anthos), o Anthos on-premises e o Anthos Bare Metal não são compatíveis.
• IBM Cloud Kubernetes Service
• A VMware Tanzu Kubernetes Grid (TKG) e a VMware Tanzu Kubernetes Grid Integration (TKGI), anteriormente conhecidas como Pivotal Container Service (PKS)

Instana é compatível com as três últimas versões estáveis do Istio.

O sensor Legacy Kubernetes chegou ao fim da vida útil (EOL). A versão anterior ainda está disponível para instalação.

Clique em “Plataformas” > “ Kubernetes ” no menu de navegação da interface do usuário do Instana para visualizar as informações dos seus clusters e namespaces do Kubernetes.

Clique em “Aplicativos” no menu de navegação da interface do usuário do Instana e, em seguida, clique na guia “Aplicativos” ou “Serviços ”. Se o serviço ou aplicativo estiver em execução em um cluster do Kubernetes, você poderá ver as respectivas informações de contexto na guia Infraestrutura :

Para contêineres, o pod e o namespace são exibidos e vinculados diretamente; para hosts, o cluster e o nó também são mostrados e vinculados.

Clique em “Infraestrutura” no menu de navegação da interface do usuário do Instana. No mapa de infraestrutura, você pode ver as informações d Kubernetes e na barra lateral, tanto para o host quanto para o contêiner que você selecionar.

Você pode usar o Dynamic Focus para filtrar os dados. Por exemplo, procure uma implementação específica em um cluster.. Além disso, as palavras-chave entity.kubernetes.cluster.distribution e entity.kubernetes.cluster.managedBy permitem a procura de um cluster Kubernetes por camada de distribuição e gerenciamento. Valores suportados para entity.kubernetes.cluster.distribution são gke, eks, openshifte kubernetes. Os valores suportados para entity.kubernetes.cluster.managedBy são rancher e none.

Diversos serviços lógicos podem ser relacionados a um único serviço Kubernetes quando as regras de mapeamento de serviço correspondem e chamadas são geradas nesse serviço Kubernetes . Por exemplo, um serviço Kubernetes com o seletor de "service=my-service" rótulos pode conter pods que tenham os rótulos "env=dev" adicionais e, "env=staging" combinados com uma configuração personalizada de mapeamento de serviços em Instana com as seguintes tags kubernetes.container.name: kubernetes.pod.label,, e key: env. Isso resulta em vários serviços lógicos vinculados a esse único serviço Kubernetes e exibidos no painel Kubernetes Service.

Diversos serviços do Kubernetes podem ser relacionados a um único serviço lógico quando esses serviços do Kubernetes são destruídos e recriados ao longo de um tempo Por exemplo, se o serviço Kubernetes shop-service-a com chamadas geradas for substituído ao longo do tempo por shop-service-b com chamadas geradas, ambos os serviços serão exibidos no painel de serviço lógico quando o período de tempo selecionado sobrepor as chamadas geradas.

Para habilitar o HPA especificamente para o serviço de armazenamento em nuvem de última geração ( K8sensor ), consulte Habilitando o autoescalonamento (HPA) para o k8sensor (solução alternativa).

Estão disponíveis as seguintes métricas sobre o HPA:

Você pode monitorar os HPAs (Horizontal Pod Autoscalers) usando o recurso Infraestrutura do Analytics. Para obter mais informações, consulte “Analisar a infraestrutura” ). Na página “Analisar infraestrutura”, você pode pesquisar os Horizontal Pod Autoscalers e visualizar o número total.

Para visualizar a lista de HPAs, selecione “ Kubernetes : Horizontal Pod Autoscalers” na lista de tipos de infraestrutura.

Você pode criar alertas inteligentes para métricas relacionadas ao HPA. Para obter mais informações, consulte “Alertas inteligentes ”. É possível criar Alertas Inteligentes com as seguintes métricas do HPA: Réplicas atuais, Réplicas desejadas, Réplicas máximas, Contagem de mensagens e Réplicas mínimas.

Você pode configurar alertas com base na utilização das réplicas nas seguintes métricas:

• Current Replicas / Maximum Replicas
• Current Replicas / Minimum Replicas

Por exemplo, se a Current Replicas métrica atingir 80% do valor Maximum Replicas da métrica, o 0.8 valor da Current Replicas / Maximum Replicas métrica pode acionar um alerta. Da mesma forma, se a Current Replicas métrica atingir 100% do valor Minimum Replicas da métrica, o 1.0 valor da Current Replicas / Minimum Replicas métrica poderá acionar um alerta.

A tabela a seguir lista as métricas disponíveis relacionadas ao PV:

A tabela a seguir lista as métricas disponíveis relacionadas ao PVC:

Enquanto o PVC estiver vinculado a um PV, a maioria das métricas exibidas será a mesma que a disponível para o PV associado.

O painel do plano de controle exibe métricas em tempo real e tendências históricas para todos os componentes monitorados.

Ao visualizar um cluster do Kubernetes na interface do usuário do Instana, a guia “Control Plane” exibe informações de depuração que fornecem detalhes sobre o status de monitoramento e a configuração do cluster. Essas informações ajudam você a compreender o estado atual do monitoramento e a solucionar problemas.

Existem algumas regras de funcionamento integradas que acionam um problema para entidades Kubernetes .

• Agrupamento
  • Kubernetes indica que um componente mestre (apiserver, agendador e gerenciador de controladores) está com falha. Instana filtra o estado de integridade do componente mestre, sem gerar um alerta, mas exibindo apenas o estado de integridade na página de detalhes do cluster.
• Nó
  • A CPU solicitada está se aproximando da capacidade máxima. A proporção de CPU solicitada para a capacidade da CPU é maior que 80%
  • A memória solicitada está se aproximando da capacidade máxima. A proporção de memória solicitada para a capacidade de memória é maior que 80%
  • Os pods alocados estão se aproximando da capacidade máxima A proporção de capacidade de pods para pods alocados é maior do que 80% Para um nó, os pods nas fases 'Running' e 'Unknown ' são contados como alocados.. Para obter mais informações sobre a capacidade do nó, consulte Kubernetes docs.
  • O nó relata uma condição que não está pronta para mais de um minuto e todas as condições para esse nó estão além da condição "Pronto". Para obter mais informações sobre todas as condições dos nós, consulte a documentação em Kubernetes.
• Namespace
  • A CPU solicitada está se aproximando da capacidade máxima. A proporção de CPU solicitada para a capacidade da CPU é maior que 80%
  • A memória solicitada está se aproximando da capacidade máxima. A proporção de memória solicitada para a capacidade de memória é maior que 80%
  • Os pods alocados estão se aproximando da capacidade máxima A proporção de capacidade de pods para pods alocados é maior do que 80% Para um namespace, os pods nas fases 'Pendente', 'Em execução' e 'Desconhecido ' são contados como alocados Os valores de capacidade do namespace são baseados em ResourceQuotas , que podem ser configurados por namespace Para obter mais informações, consulte Kubernetes docs.
• Implementação
  • As réplicas disponíveis são inferiores às réplicas desejadas.
• Pod
  • Um pod deve estar pronto em um minuto após ser implantado, mas se ele não estiver pronto em um minuto, o motivo não é que ele tenha concluído sua tarefa (PodCondition=Ready, Status=False, Reason!= PodCompleted). Para obter mais informações sobre todas as condições dos pods, consulte a documentação em Kubernetes.

Além das regras integradas, também é possível criar regras customizadas em métricas de um cluster, namespace, implementação e pod. Por exemplo, se o limite para avisos de capacidade do nó for muito alto, você pode desativá-los e criar uma regra personalizada com um valor de limite mais baixo. Para obter mais informações, consulte a seção “Configuração de eventos e incidentes ”.

Você pode habilitar o monitoramento do agente do Instana Java com a malha de serviços Istio e OpenShift usando o agent.serviceMesh.enabled sinalizador. Essa abordagem nativa do Kubernetes utiliza uma única porta de rede dedicada para todas as cargas de trabalho do Java monitoradas em um único host ou nó. O valor padrão é configurado como true. Para obter mais informações sobre o parâmetro de configuração, consulte Helm Configuração do gráfico.

Se a configuração ` Istio ` estiver definida como REGISTRY_ONLY, serão necessárias etapas adicionais para que o serviço de soquete do agente funcione corretamente.

É necessário implementar a definição de recurso a seguir para cada nó do cluster individual Certifique-se de definir uma propriedade exclusiva do metadata.name para cada host ou nó Além disso, configure o valor para spec.hosts como <node-ip-address>.instana-agent-headless.instana-agent.svc, em que <node-ip-address> é o endereço IP do nó..

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: instana-agent-worker-<node-unique-counter>
spec:
  hosts:
  - <node-ip-address>.instana-agent-headless.instana-agent.svc
  ports:
  - number: 42699
    name: agent
    protocol: TCP
  resolution: DNS
  location: MESH_EXTERNAL
 

A abordagem legada alternativa é ativar o bypass de malha de serviço A instalação padrão do Istio funciona imediatamente com o Instana. Se você implantar o ` Istio ` com uma política de negação padrão (mode: REGISTRY_ONLY), poderá habilitar o desvio da malha de serviços do ` Instana ` usando a seguinte configuração do agente:

com.instana.container:
  serviceMesh:
    enableServiceMeshBypass: true
 

A configuração ignora a conectividade de rede bloqueada de duas maneiras diferentes:

• Permita o tráfego de saída do pod do aplicativo para o agente de host (em todos os endereços IPv4 nos quais o agente atende e todas as portas).
• Permitir o tráfego de entrada para o pod da aplicação proveniente do agente para aplicações do tipo “ JVM ” (de todos os endereços ipv4 nos quais o agente do host está à escuta, em todas as portas).

Se nenhum cluster ou namespaces estiver listado na página Kubernetes , nenhum cluster está sendo monitorado ativamente devido a um agente não estar sendo instalado ou nenhum cluster está sendo monitorado durante o prazo selecionado.

Clique em “Live” para verificar se há algum cluster ou namespace em modo ativo; caso nenhum esteja listado, você precisará instalar o agente do Instana no Kubernetes.

Tipo de problema de monitoramento: kubernetes_missing_permissions

O agente Instana requer as permissões apropriadas da função de cluster para que os recursos específicos possam monitorar um cluster Kubernetes com sucesso. Se essas permissões estiverem ausentes, os recursos correspondentes não serão exibidos nos painéis do Instana e Kubernetes. Para resolver esse problema, instale a versão mais recente do Agente do Instana YAML, do Helm Chart ou do Operator. Para obter mais informações sobre a versão mais recente de cada método de instalação, consulte Kubernetes ou OpenShift.

Para monitorar recursos personalizados (CRs) d Kubernetes, é necessário criar um ClusterRole recurso com regras específicas que concedam as permissões necessárias ao agente do Instana. Essa configuração permite que k8sensor o acesse e monitore recursos personalizados no seu cluster.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: instana-crmon
rules:
  - apiGroups: ["your.custom.group"]
    resources: ["yourcustomresources"]
    verbs: ["get", "list", "watch"]

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: instana-crmon
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: instana-crmon
subjects:
- kind: ServiceAccount
  name: instana-agent-k8sensor
  namespace: instana-agent

1. Clone o repositório de manutenção.

2. Navegue até o diretório agent/k8s.

3. Leia as instruções contidas no README.md arquivo nesse diretório, certificando-se de que os pré-requisitos foram atendidos e de que você está conectado ao cluster.

4. Execute o instana-k8s-mustgather.sh.

5. Após a conclusão do script, é gerado um .tgz arquivo que contém todas as informações de diagnóstico necessárias para que a equipe de suporte ao cliente possa dar atendimento ao ticket.