Distribuzione di Agent di registrazione per cluster Kubernetes utilizzando un grafico Helm

È possibile utilizzare un diagramma Helm per distribuire l'istanza Agent di registrazione v1.6.x per raccogliere e instradare i log dell'infrastruttura e delle applicazioni da un cluster Kubernetes a un'istanza IBM Cloud Logs.

È inoltre possibile utilizzare Terraform IBM Modules (TIM) per Agent di registrazione per distribuire e configurare l'agente dei registri sui cluster Kubernetes supportati. Questo modulo automatizza la distribuzione basata su Helm e le impostazioni di configurazione chiave utilizzando l'automazione Infrastructure as Code ( IaC ).

Completare i seguenti passaggi per distribuire un agente su un cluster Kubernetes:

Prima di iniziare

  • Assicurarsi di avere accesso al cluster Kubernetes con i permessi per creare spazi dei nomi e distribuire l'agente.

  • Installa le seguenti CLI:

    • La IBM Cloud CLI per accedere al IBM Cloud e gestire i servizi IBM Cloud come la creazione di una chiave API.

    • La CLI Kubernetes per gestire il cluster utilizzando i comandi kubectl. Ulteriori informazioni.

  • Leggete il Agent di registrazione.

  • Controllare le versioni dell'agente disponibili. Per ulteriori informazioni, vedere Verifica delle versioni dell'agente disponibili. Si noti che la versione del diagramma Helm corrisponderà alla versione dell'agente; ad esempio, se si utilizza la versione 1.3.0 dell'agente, esiste un diagramma Helm con la versione 1.3.0 che accompagna tale versione.

Passo 1. Definire il metodo di autenticazione per l'agente

Scegliere il tipo di identità e il metodo di autenticazione per l'agente. Quindi, creare un profilo di fiducia o una chiave API. Il ruolo richiesto per l'invio dei registri a IBM Cloud Logs è Sender.

È possibile utilizzare un ID di servizio o un profilo attendibile come identità utilizzata dall'agente per autenticarsi con il servizio IBM® Cloud Logs. Per ulteriori informazioni, vedere Concessione di autorizzazioni IAM per l'ingestione.

Scegli una delle seguenti opzioni:

Opzione 1: Autenticazione tramite un profilo di fiducia

Creare un profilo di fiducia. Per ulteriori informazioni, vedere Generazione di un profilo attendibile per l'ingestione.

Opzione 2: Autenticazione tramite chiave API dell'ID del servizio

Generare una chiave API per l'autenticazione dell'ID del servizio. Per ulteriori informazioni, vedere Generazione di una chiave API per l'ingestione.

Passo 2. Configurazione del file dei valori del grafico Helm per il Agent di registrazione

Completa i seguenti passi:

  1. Creare un file chiamato logs-values.yaml con il seguente contenuto:

    Questo file contiene le configurazioni specifiche dell'installazione.

    metadata:
  name: "logs-agent"
image:
  version: "1.6.1"  # required

clusterName: "ENTER_CLUSTER_NAME"     # Enter the name of your cluster. This information is used to improve the metadata and help with your filtering.

env:
  # ingestionHost is a required field. For example:
  # ingestionHost: "<logs instance>.ingress.us-east.logs.cloud.ibm.com"
  ingestionHost: "" # required

  # If you are using private CSE proxy, then use port number "3443"
  # If you are using private VPE Gateway, then use port number "443"
  # If you are using the public endpoint, then use port number "443"
  ingestionPort: "" # required

  iamMode: "TrustedProfile"
  # trustedProfileID - trusted profile id - required for iam trusted profile mode
  trustedProfileID: "Profile-yyyyyyyy-xxxx-xxxx-yyyy-zzzzzzzzzzzz" # required if iamMode is set to TrustedProfile

  2. Aggiornare i campi del file yaml con i valori specifici del proprio ambiente.

    Parametri richiesti dalla cartaHelm
    Nome campo Descrizione
    image.version La versione dell'agente da distribuire vedi Fase 1
    clusterName Il nome del cluster: questo introdurrà il tag kubernetes.cluster_name in tutte le righe di log
    env.ingestionHost L'endpoint di ingresso pubblico o privato per l'istanza dell' IBM Cloud Logs, per ricevere i registri
    env.ingestionPort Porta di ingresso dell'endpoint pubblico
    . Ingresso endpoint pubblico = 443
    . Ingresso endpoint privato (VPE) = 443
    . Ingresso endpoint privato (CSE) = 3443
    env.iamMode TrustedProfile o IAMAPIKey in base al metodo di autenticazione scelto in Fase 1
    env.trustedProfileID Se iamMode è TrustedProfile, fornire l'ID profilo attendibile, altrimenti non è necessario (ad esempio: Profile-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ).
    env.iamEnvironment Determina il punto finale di autenticazione IAM corretto. I valori validi sono Production, PrivateProduction o Custom. Se omesso, il valore predefinito è " Production".
    env.iamHost Se iamEnvironment è Custom, fornire l'host IAM (ad esempio: private.eu-de.iam.cloud.ibm.com), altrimenti non è necessario.

Passo 3. Installare il grafico Helm

Se si utilizza iamMode come IAMAPIKey, l'apikey deve essere presente in un segreto Kubernetes chiamato logs-agent con il nome della chiave IAM_API_KEY. Il segreto può essere creato utilizzando il diagramma Helm, includendo l'opzione --set secret.iamAPIKey=<your iamAPIKey> quando si esegue l'installazione del timone. Se il segreto è stato creato manualmente o se si utilizza iamMode=TrustedProfile, non includere questa opzione.

Completa i seguenti passi:

  1. Accedi al cluster. Per ulteriori informazioni, vedere Accesso al cluster.

  2. Eseguire un Helm dry run per vedere le risorse che verranno create dal grafico Helm.

    Se si utilizza il comando iamMode=TrustedProfile, il comando completo è:

    helm install <install-name> --dry-run oci://icr.io/ibm-observe/logs-agent-helm --version <chart-version> --values <PATH>/logs-values.yaml -n ibm-observe --create-namespace

    Se si utilizza il comando iamMode=IAMAPIKey, il comando completo è:

    helm install <install-name> --dry-run oci://icr.io/ibm-observe/logs-agent-helm --version <chart-version> --values <PATH>/logs-values.yaml -n ibm-observe --create-namespace --set secret.iamAPIKey=<APIKey-value> --hide-secret

    dove:

    • <install-name> è il nome dell'installazione dell' Helm. (logs-agent)
    • <chart-version> è la versione della carta del timone. La versione del grafico Helm deve corrispondere alla versione dell'immagine dell'agente. Per ulteriori informazioni, vedere Helm versioni del grafico.
    • <PATH> è il percorso della directory in cui si trova il file logs-values.yaml.
    • <APIKey-value> è l'apikey IAM associata al ServiceID impostato al passo 1
    • Aggiungere --hide-secret per nascondere la chiave API dai dati di output dopo l'esecuzione del comando.

    Se si desidera esaminare il contenuto della carta del timone in locale, è possibile scaricare la carta del timone sul proprio computer utilizzando il comando: helm pull oci://icr.io/ibm-observe/logs-agent-helm --version <chart-version>. Il file tgz scaricato contiene il contenuto del grafico.

    Ad esempio, è possibile eseguire il seguente comando dalla directory in cui è disponibile il file logs-values.yaml:

    helm install logs-agent --dry-run oci://icr.io/ibm-observe/logs-agent-helm --version 1.6.0 --values ./logs-values.yaml -n ibm-observe --create-namespace --set secret.iamAPIKey=<secret> --hide-secret

  3. Una volta verificate le risorse da creare, eseguire l'installazione Helm senza l'opzione --dry-run

    Se si utilizza il comando iamMode=TrustedProfile, il comando completo è:

    helm install <install-name>  oci://icr.io/ibm-observe/logs-agent-helm --version <chart-version> --values <PATH>/logs-values.yaml -n ibm-observe --create-namespace

    Se si utilizza il comando iamMode=IAMAPIKey, il comando completo è:

    helm install <install-name> oci://icr.io/ibm-observe/logs-agent-helm --version <chart-version> --values <PATH>/logs-values.yaml -n ibm-observe --create-namespace --set secret.iamAPIKey=<APIKey-value>

    dove:

    • <install-name> è il nome dell'installazione dell' Helm. (logs-agent)
    • <chart-version> è la versione della carta del timone. La versione del grafico Helm deve corrispondere alla versione dell'immagine dell'agente. Per ulteriori informazioni, vedere Helm versioni del grafico.
    • <PATH> è il percorso della directory in cui si trova il file logs-values.yaml.
    • <APIKey-value> è l'apikey IAM associata al ServiceID impostato al passo 1

Passo 4. Verificare che l'agente sia stato distribuito correttamente

Quando l'agente viene distribuito, verificare che vengano create le seguenti risorse:

  • Lo spazio dei nomi ibm-observe.

    Eseguire il seguente comando per elencare gli spazi dei nomi nel cluster e verificare che logger-agent mostri lo stato attivo.

    kubectl get namespace

  • Una mappa di configurazione logs-agent nello spazio dei nomi ibm-observe.

    Eseguire il seguente comando per visualizzare i dettagli della configurazione dell'agente.

    kubectl get configmap logs-agent -n ibm-observe

    È possibile utilizzare anche:

    kubectl describe configmaps logs-agent -n ibm-observe

  • Un daemonset logs-agent nello spazio dei nomi ibm-observe.

    Eseguite il seguente comando per visualizzare il daemonset.

    kubectl get ds -n ibm-observe

  • Verificare che gli agenti siano avviati:

    kubectl -n ibm-observe get ds logs-agent

  • Recuperare l'elenco dei pod dell'agente utilizzando il seguente comando:

    kubectl get pods -n ibm-observe -o wide

    NAME                  READY   STATUS    RESTARTS   AGE    IP              NODE           NOMINATED NODE   READINESS GATES
logs-agent-4lwvt      1/1     Running   0          2d5h   172.17.61.181   192.168.16.4   <none>           <none>
logs-agent-g7z87      1/1     Running   0          2d5h   172.17.0.48     192.168.32.4   <none>           <none>
logs-agent-nw56s      1/1     Running   0          2d5h   172.17.32.232   192.168.0.10   <none>           <none>

    La colonna READY mostra 1/1 per tutti i pod, con un STATUS di Running. Verificare che sia pronto un pod agente per ogni nodo del cluster.

    Per verificare quanti lavoratori sono disponibili nel cluster, è possibile eseguire il seguente comando:

    kubectl get nodes

    NAME           STATUS   ROLES           AGE   VERSION
192.168.0.10   Ready    master,worker   8d    v1.20.0+558d959
192.168.32.4   Ready    master,worker   8d    v1.20.0+558d959
192.168.16.4   Ready    master,worker   8d    v1.20.0+558d959

    Il numero di elementi in ciascuno di questi due elenchi deve essere lo stesso e si possono far corrispondere gli indirizzi IP nei nomi dei nodi con i valori nella colonna NODE dell'elenco pod.

    Se i nodi non sono denominati in base al loro IP, è possibile aggiungere l'opzione -o wide e confrontare i valori nella colonna INTERNAL-IP.

    Per visualizzare i log di un pod, eseguire kubectl logs <POD_NAME>> -n ibm-observe

    Per controllare la carta del timone distribuita, eseguire helm list -n ibm-observe

Passo 5. Verificare che i registri vengano consegnati alla destinazione di destinazione

Completa i seguenti passi:

  1. Andare all'interfaccia web della propria istanza IBM Cloud Logs.

  2. Quando l'agente è configurato correttamente, è possibile visualizzare i registri attraverso la vista predefinita del dashboard. Il Agent di registrazione etichetta i record di log con un oggetto kubernetes che include il nome del cluster.

    kubernetes.cluster_name:<CLUSTER_NAME>

    È possibile eseguire la query kubernetes.cluster_name:<YOUR_CLUSTER_NAME> nella propria istanza IBM Cloud Logs per cercare i registri generati dal cluster.