Installation des Backends „ Instana “

• Das Plug-in „ Instana “ kubectl muss installiert sein.
• Erforderliche Datenspeicher müssen betriebsbereit sein. Siehe „Einrichten von Datenspeichern “.
• Der „ Instana Enterprise“-Operator muss installiert sein.

Bevor Sie Core und Uniterstellen können, müssen Sie Namensbereiche erstellen und eine Reihe von geheimen Schlüsseln für die Namensbereiche platzieren, damit Sie Core -und Unit -Images aus der artifact-public.instana.io -Registry extrahieren können.

Ein Core stellt gemeinsam genutzte Komponenten dar und ist für die Konfiguration des Datenspeicherzugriffs verantwortlich. Daher werden die meisten Konfigurationen hier ausgeführt.

Weitere Informationen finden Sie unter „ API -Referenz “.

Eine angepasste Core -Ressource muss die Version instana.io/v1beta2 und die Art Corehaben. Konfigurationen für Core werden im Abschnitt spec beschrieben.

Erstellen Sie eine core.yaml-Datei. Konfigurationen für Core werden im Abschnitt spec beschrieben.

apiVersion: instana.io/v1beta2
kind: Core
metadata:
  namespace: instana-core
  name: instana-core
spec:
  ...
 

Stellen Sie sicher, dass mindestens ein Knoten im Cluster nicht markiert ist und nicht über das Label verfügt node-role.kubernetes.io/monitor: "true". Fügen Sie die folgenden Zeilen in die Datei core.yaml ein, um die Toleranzen und den Knotenselektor festzulegen.

 spec:
   tolerations:
     - key: node.instana.io/monitor
       operator: Equal
       effect: NoSchedule
       value: "true"
   nodeSelector:
     node-role.kubernetes.io/monitor: "true"
 

Führen Sie einige Basiskonfigurationen wie folgt aus:

apiVersion: instana.io/v1beta2
kind: Core
metadata:
  namespace: instana-core
  name: instana-core
spec:
  # The domain under which Instana is reachable
  baseDomain: <instana.example.com>

  # Depending on your cluster setup, you may need to specify an image pull secret.
  imagePullSecrets:
    - name: my-registry-secret

  # This configures an SMTP server for sending e-mails.
  # Alternatively, Amazon SES is supported. Please see API reference for details.
  emailConfig:
    smtpConfig:
      from: smtp@example.com
      host: smtp.example.com
      port: 465
      useSSL: true
 

Sie können für jeden Komponenten-Pod individuelle CPU- und Speicherressourcen konfigurieren. Im folgenden Beispiel wird die Komponente filler verwendet. Ersetzen Sie filler durch die Komponente, die verwendet werden soll, und geben Sie CPU-und Speicherressourcen mit den Gesamtsummen an, die Sie bereitstellen möchten.

spec:
  componentConfigs:
    - name: filler
      resources:
        requests:
          cpu: 2.5
          memory: 5000Mi
        limits:
          cpu: 4
          memory: 20000Mi
 

Die folgende Konfiguration ist veraltet. Verwenden Sie die Konfiguration, die unter „Gateway-Konfiguration“ angegeben ist.

Der Acceptor ist der Endpunkt, den die Agenten von „ Instana “ erreichen müssen, um Traces oder Metriken an das Backend von „ Instana “ zu übermitteln. Der Akzeptor ist normalerweise eine Unterdomäne für baseDomain , die zuvor im Abschnitt Basiskonfiguration konfiguriert wurde.

spec:
  agentAcceptorConfig:
    host: ingress.<instana.example.com>
    port: 443
 

Sie können die Hosts und Ports für die folgenden Arten von eingehendem Datenverkehr konfigurieren:

• Instana-Agent
• Synthetics
• Serverless
• OTLP (HTTP/gRPC)
• EUM
• OpAMP

Um die Hosts und Ports für die verschiedenen „ Instana “-Akzeptoren zu konfigurieren, fügen Sie die folgende Konfiguration in die CoreSpec ein:

spec:
  gatewayConfig:
    enabled: true # enables gateway-v2 and gateway-controller
  acceptors:
    agent:
      host: ingress.<instana.example.com>
      port: 443
    opamp:
      host: opamp-acceptor.<instana.example.com>
      port: 443
    otlp:
      http:
        host: otlp-http.<instana.example.com>
        port: 443
      grpc:
        host: otlp-grpc.<instana.example.com>
        port: 443
    eum:
      host: eum.<instana.example.com>
      port: 443
    synthetics:
      host: synthetics.<instana.example.com>
      port: 443
    serverless:
      host: serverless.<instana.example.com>
      port: 443
 

Die folgenden Beispiele zeigen, wie Sie die Datenaufnahme Ihres Akzeptors entsprechend unterschiedlichen Anforderungen konfigurieren können:

1. Verwenden Sie Subdomains mit einem einzigen Port (443). Dieser Ansatz ermöglicht es Ihnen, nur einen Port (443) freizugeben und gleichzeitig Subdomains zu nutzen, um den Datenverkehr für jeden Acceptor zu unterscheiden.

    spec:
      acceptors:
        agent:
          host: ingress.<instana.example.com>
          port: 443
        opamp:
          host: opamp-acceptor.<instana.example.com>
          port: 443
        otlp:
          http:
            host: otlp-http.<instana.example.com>
            port: 443
          grpc:
            host: otlp-grpc.<instana.example.com>
            port: 443
        eum:
          host: eum.<instana.example.com>
          port: 443
        synthetics:
          host: synthetics.<instana.example.com>
          port: 443
        serverless:
          host: serverless.<instana.example.com>
          port: 443
    

2. Verwenden Sie eine einzige Domain mit unterschiedlichen Ports. Mit diesem Ansatz können Sie eine einzige Domain verwenden und den eingehenden Datenverkehr anhand der Portnummern unterscheiden. Sie können nur die Custom Edition v 1.3.0 und höher mit einer einzigen Domäne konfigurieren.

    spec:
      acceptors:
        agent:
          port: 1444
        otlp:
          http:
            port: 4318
          grpc:
            port: 4317
        eum:
          port: 1555
        synthetics:
          port: 1666
        serverless:
          port: 1777
    

   In diesem Fall müssen Sie die Konfiguration Ihres Loadbalancers in Ihrem Cluster aktualisieren, um die verschiedenen Acceptor-Ports freizugeben. Siehe „Einrichten von Load Balancern“ und „ DNS “.

Ihre Custom Edition -Umgebung kann den Datenverkehr für alle Mandanten über eine einzige Basisdomain leiten. Um dieses Verhalten zu aktivieren, konfigurieren Sie die folgende Eigenschaft in Ihrem CoreSpec :

kind: Core
metadata:
  name: instana-core
  namespace: instana-core
spec:
  properties:
    ...
    - name: config.url.format.pathStyle
      value: "true"
    ...
 

Nachdem Sie diese Funktion aktiviert haben, wird die URL „ URL “ für den Zugriff auf die Benutzeroberfläche aller Ihrer „ Instana “-Mandanten unter <basedomain>.com/<unitname>/<tenantname> anstelle von bereitgestellt <unitname>-<tenantname>.<basedomain>.com. Der gesamte eingehende Datenverkehr von Instana kann über einen einzigen A-Eintrag in Ihrer DNS geleitet werden, indem Sie diesen mit der Konfiguration im zweiten Beispiel unter „Gateway-Konfiguration“ verknüpfen.

Ihre Custom Edition -Umgebung unterstützt die automatische Erstellung der Dienste „ LoadBalancerKubernetes “ für die Komponente „ gateway-v2 “. Sie müssen die „ LoadBalancer “-Dienste nicht manuell erstellen.

Um diese Funktion zu aktivieren, fügen Sie die folgende Konfiguration zu Ihrem CoreSpec hinzu:

spec:
  gatewayConfig:
    enabled: true
    gateway:
      loadBalancerConfig:
        enabled: true # enables automatic loadbalancer creation
        ip: <your public IP>
        externalTrafficPolicy: Local # default
        annotations:
          your-annotation-key: your-annotation-value
 

Bevor Sie diese Funktion aktivieren, stellen Sie sicher, dass ein Front-Proxy bereitgestellt wurde, um den gesamten eingehenden Datenverkehr von Instana an den Dienst gateway-v2 weiterzuleiten. Wenn für jeden Akzeptor eigene Ports konfiguriert sind, stellen Sie sicher, dass der Front-Proxy den Datenverkehr an diese Ports weiterleitet. Die Ports auf gateway-v2 müssen eine Eins-zu-Eins-Zuordnung zu den Ports aufweisen, die vom Front-Proxy freigegeben werden.

Ihre Custom Edition -Umgebung unterstützt zudem die Deaktivierung der „ TLS “-Terminierung (d. h. die Annahme von eingehendem Datenverkehr ohne „ SSL “). Diese Option ist nützlich, wenn Sie einen Front-Proxy bereitstellen, der die Beendigung von TLS vor Ihrer Custom Edition -Umgebung übernimmt.

Um dieses Verhalten zu aktivieren, fügen Sie die folgende Konfiguration zu Ihrem CoreSpec hinzu:

spec:
  gatewayConfig:
    enabled: true
    disableTLS: true # disables TLS termination for all ingress traffic
 

Sie müssen eine der folgenden drei Optionen verwenden, um unformatierte Spandaten zu speichern:

• S3 (oder kompatibel)
• Google Cloud Storage (GCS)
• Dateisystem Azure
• Dateisystem

Der S3 -Endpunkt ist je nach Region unterschiedlich.

Wenn Sie S3 (oder kompatibel) zum Speichern von unformatierten Daten verwenden möchten, konfigurieren Sie Core wie im folgenden Beispiel gezeigt:

spec:
  storageConfigs:
    rawSpans:
      s3Config:
        # Endpoint address of the object storage.
        # S3 Endpoint Ref: https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_region
        endpoint:
        # Region.
        region: eu-central-1
        # Bucket name.
        bucket: mybucket
        # Prefix for the storage bucket.
        prefix: myspans
        # Storage class.
        storageClass: STANDARD
        # Bucket name for long-term storage.
        bucketLongTerm: mybucket
        # Prefix for the long-term storage bucket.
        prefixLongTerm: myspans-longterm
        # Storage class for objects that are written to the long-term bucket.
        storageClassLongTerm: STANDARD

  # If using IRSA
  # Appropriate IAM Role should be provisioned including IAM policy with sufficient privileges.
  serviceAccountAnnotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/my-role
 

Wenn Sie GCS zum Speichern von unformatierten Daten verwenden möchten, konfigurieren Sie Core wie folgt:

spec:
  storageConfigs:
    rawSpans:
      gcloudConfig:
        # Bucket name.
        bucket: mybucket
        # Prefix for the storage bucket.
        prefix: myspans
        # Storage class.
        storageClass: STANDARD
        # Bucket name for long-term storage.
        bucketLongTerm: mybucket
        # Prefix for the long-term storage bucket.
        prefixLongTerm: myspans-longterm
        # Storage class for objects that are written to the long-term bucket.
        storageClassLongTerm: STANDARD

  # If using Workload Identity
  serviceAccountAnnotations:
    iam.gke.io/gcp-service-account: rawspans@myproject.iam.gserviceaccount.com
 

Führen Sie die folgenden Schritte aus, um das Dateisystem Azure zum Speichern von unformatierten span-Daten zu verwenden:

1. Erstellen Sie einen geheimen Schlüssel mit dem Speicherkontonamen und dem Datenträger:

   kubectl create secret generic storage-account --from-literal=azurestorageaccountname={storage_account_name} --from-literal=azurestorageaccountkey={storage_account_key} -n instana-core
    

2. Erstellen Sie einen persistenten Datenträger, indem Sie pv.yamlerstellen:

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: my-nfs-volume
   spec:
     capacity:
       storage: 100Gi
     accessModes:
       - ReadWriteMany
     azureFile:
       secretName: storage-account
       shareName: <storage_account_name>
       readOnly: false
     persistentVolumeReclaimPolicy: Retain
    

3. Konfigurieren Sie Core wie im folgenden Beispiel gezeigt:

   spec:
     storageConfigs:
       rawSpans:
         pvcConfig:
           accessModes:
             - ReadWriteMany
           resources:
             requests:
               storage: 100Gi
           volumeName: my-nfs-volume
    

Konfigurieren Sie Core wie folgt, um das Dateisystem zum Speichern von unformatierten Spans zu verwenden:

spec:
  storageConfigs:
    rawSpans:
      pvcConfig:
        accessModes:
          - ReadWriteMany
        resources:
          requests:
            storage: 100Gi
        volumeName: my-nfs-volume
        storageClassName: ""
 

Sie müssen die folgenden Datenspeicher im Abschnitt spec von Corekonfigurieren:

• cassandra
• postgres
• clickhouse
• elasticsearch
• kafka

Hinweise:

• Für jeden Datenspeicher müssen mindestens Adressen konfiguriert werden. Sehen Sie sich das folgende Beispiel an:

  spec:
    datastoreConfigs:
      cassandraConfigs:
        - hosts:
            - <IP address or hostname>
      clickhouseConfigs:
        - hosts:
            - <IP address or hostname>
      postgresConfigs:
        - hosts:
            - <IP address or hostname>
      elasticsearchConfig:
        hosts:
          - <IP address or hostname>
      kafkaConfig:
        hosts:
          - <IP address or hostname>
   

  Ersetzen Sie < IP-Adresse oder Hostname > durch die IP-Adresse oder den Hostnamen des Datenspeichers.

• Wenn Datenspeicher mithilfe von Operatoren von Drittanbietern im selben Cluster installiert werden, können Sie die Verbindung zu den Datenspeichern datastoreConfigs so konfigurieren, dass die Hostnamen der „ DNS “ innerhalb des Clusters verwendet werden, wie im folgenden Konfigurationsbeispiel gezeigt:

  spec:
    datastoreConfigs:
      cassandraConfigs:
        - authEnabled: true
          datacenter: cassandra
          hosts:
            - <IP address or hostname>
      clickhouseConfigs:
        - authEnabled: true
          clusterName: local
          hosts:
            - <IP address or hostname>
            - <IP address or hostname>
      elasticsearchConfig:
        authEnabled: true
        clusterName: instana
        hosts:
          - <IP address or hostname>
      kafkaConfig:
        saslMechanism: SCRAM-SHA-512
        authEnabled: true
        hosts:
          - <IP address or hostname>
      postgresConfigs:
        - authEnabled: true
          hosts:
            - <IP address or hostname>
   

• Stellen Sie sicher, dass der korrekte Name für das Cassandra -Data Center (Standardwert: cassandra) im Abschnitt cassandraConfigs der Kernspezifikation über das Attribut datacenter konfiguriert ist.

• Für Power-Architektur: Stellen Sie sicher, dass der genaue Name des Cassandra -Data Centers (Standardwert: datacenter1) im Abschnitt cassandraConfigs der Kernspezifikation über das Attribut datacenter konfiguriert ist.

• ClickHouse (Standardwert: local) und Elasticsearch (Standardwert onprem_onprem) akzeptieren einen Clusternamen über das Attribut clusterName .

  Datenspeicher ermöglichen die Konfiguration eines tcp -Ports. Außerdem kann ein http -Port für clickhouse und elasticsearchkonfiguriert werden.

  spec:
    datastoreConfigs:
      clickhouseConfigs:
        - clusterName: local
          hosts:
            - <IP address or hostname>
          ports:
            - name: tcp
              port: 9000
            - name: http
              port: 8123
   

Wenn keine Ports konfiguriert sind, gelten die folgenden Standardwerte:

Das Überschreiben der Standardaufbewahrungseinstellungen ist optional und sollte nur bewusst erfolgen. Diese Werte für Aufbewahrungseinstellungen werden als Eigenschaften in CoreSpeckonfiguriert.

Die folgenden Aufbewahrungseigenschaften gelten für die Metrik-Rollup-Tabellen und die aufgelisteten Werte sind die Standardwerte in Sekunden. Der Wert 0 weist das System an, keine Rollups dieser Zeitspanne zu löschen. Ein Wert von Null für Rollups mit geringerer Größe kann dazu führen, dass sich die Festplatten schnell füllen.

kind: Core
metadata:
  name: instana-core
  namespace: instana-core
spec:
  properties:
    - name: retention.metrics.rollup5
      value: "86400"
    - name: retention.metrics.rollup60
      value: "2678400"
    - name: retention.metrics.rollup300
      value: "8035200"
    - name: retention.metrics.rollup3600
      value: "34214400"
    - name: retention.metrics.rawPayload
      value: "2592000"
...
 

Anwendungsperspektiven und die Endbenutzerüberwachung (EUM) verwenden jeweils dieselben Aufbewahrungseinstellungen für Kurzzeit- und Langzeitdaten. Der Kurzzeit-Speicher speichert die Daten vollständig und ist standardmäßig auf 7 Tage eingestellt. Bei der Langzeitaufbewahrung wird eine zufällige Stichprobe von 1 % der Daten gespeichert; die Standardeinstellung beträgt 13 Monate. Bei Standardeinstellungen und kontinuierlicher Datenerfassung beanspruchen Langzeitdaten etwa die Hälfte des Speicherplatzes von Kurzzeitdaten.

Sie können die kurzfristige Aufbewahrungsdauer auf einen Zeitraum zwischen 2 und 31 Tagen festlegen. Sie können die langfristige Aufbewahrungsdauer auf einen Wert zwischen 31 und 396 Tagen festlegen. Wenn Sie Werte außerhalb dieser Bereiche angeben, schlagen die Dienste von „ Instana “ beim Start fehl.

Neben vollständigen Kurzzeitdaten und Stichproben aus Langzeitdaten speichert „ Instana “ aggregierte Kennzahlen, um die Abfrageleistung zu verbessern. Instana Es ist nicht möglich, die Aufbewahrungsdauer für aggregierte Metriken zu konfigurieren; sie ist standardmäßig auf 31 Tage festgelegt.

kind: Core
metadata:
  name: instana-core
  namespace: instana-core
spec:
  properties:
    - name: config.appdata.shortterm.retention.days
      value: "7"

    - name: config.appdata.longterm.retention.days
      value: "396"
...
 

Änderungen an den Aufbewahrungseinstellungen wirken sich auf unterschiedliche Weise auf die Anwendungsansichten und die Überwachungsdaten der Endbenutzer aus:

• Kurzfristige Speicherung für Anwendungszwecke: Das System wendet die neue Einstellung nur auf neue Daten an. Es löscht zuvor gespeicherte Daten gemäß der Aufbewahrungsdauer, die zum Zeitpunkt der Speicherung galt. Nach der Änderung passt sich die tatsächliche Datenspeicherdauer schrittweise an den neuen Wert an.
• Kurzfristige Speicherung für EUM: Das System wendet die neue Einstellung sowohl auf bereits vorhandene als auch auf neue Daten an. Es löscht alle Daten gemäß der aktuellen Aufbewahrungsdauer.
• Langfristige Speicherung: Das System wendet Änderungen auf alle bestehenden und neuen Langzeitdaten für Anwendungsperspektiven und EUM an.

Sehen Sie sich die folgenden Auswirkungen auf Daten aus Anwendungsperspektiven an:

Beispiele:

• config.appdata.shortterm.retention.days wird von 7 Tagen auf 14 Tage geändert: Das System löscht Daten, die vor der Änderung gespeichert wurden, sobald sie älter als 7 Tage sind. Es löscht Daten, die nach der Änderung gespeichert wurden, sobald sie älter als 14 Tage sind. Das System benötigt 14 Tage, um einen vollständigen Datenverlauf für „ 14‑day “ zu erstellen. Instana geht jedoch sofort davon aus, dass vollständige Daten für 14 Tage vorliegen, was während der Umstellungsphase vorübergehend zu ungenauen Ergebnissen führen kann.
• config.appdata.shortterm.retention.days wird von 14 Tagen auf 7 Tage geändert: Das System löscht Daten, die vor der Änderung gespeichert wurden, sobald sie älter als 14 Tage sind. Es löscht Daten, die nach der Änderung gespeichert wurden, sobald sie älter als 7 Tage sind. Das gespeicherte Kurzzeitdatenvolumen schrumpft innerhalb von 14 Tagen auf die neue Größe. Instana beschränkt jedoch Abfragen, die über die letzten 7 Tage hinausgehen, sofort auf Langzeit- oder aggregierte Daten.
• config.appdata.longterm.retention.days wird von 396 Tagen auf 60 Tage geändert: Das System löscht Langzeit-Messdaten, sobald diese älter als 60 Tage sind. Es löscht im nächsten Bereinigungszyklus alle derzeit gespeicherten Daten, die älter als 60 Tage sind.
• config.appdata.longterm.retention.days wird von 60 Tagen auf 120 Tage geändert: Das System löscht langfristig erfasste Daten erst, wenn sie älter als 120 Tage sind. Daten, die bereits 60 Tage alt sind, bleiben nun für den verlängerten Zeitraum von 120‑day verfügbar.

Beachten Sie die folgenden Auswirkungen auf die Überwachungsdaten der Endbenutzer:

Beispiele:

• config.appdata.shortterm.retention.days wird von 7 Tagen auf 14 Tage geändert: Kurzfristige Daten werden gelöscht, sobald sie älter als 14 Tage sind.
• config.appdata.shortterm.retention.days wird von 14 Tagen auf 7 Tage geändert: Kurzfristige Daten werden gelöscht, sobald sie älter als 7 Tage sind.
• config.appdata.longterm.retention.days wird von 396 Tagen auf 60 Tage geändert: Alle langfristig erfassten Daten werden gelöscht, sobald sie älter als 60 Tage sind.
• config.appdata.longterm.retention.days wird von 60 Tagen auf 120 Tage geändert: Alle langfristig erfassten Daten werden gelöscht, sobald sie älter als 120 Tage sind.

Die synthetische Überwachung verfügt über eine separate Datenaufbewahrungseigenschaft mit einem Standardwert von 60 Tagen. Über diese Einstellung wird die Beibehaltung der Ergebnisse des synthetischen Tests und der Details des Ergebnisses des synthetischen Tests gesteuert.

kind: Core
metadata:
  name: instana-core
  namespace: instana-core
spec:
  properties:
    - name: config.synthetics.retention.days
      value: "60"
...
 

Sehen Sie sich die folgenden Auswirkungen auf synthetische Überwachungsdaten an:

Beispiele:

• config.synthetics.retention.days wird von 60 Tagen in 90 Tage geändert: Daten, die vor der Konfigurationsänderung gespeichert wurden, werden gelöscht, wenn sie älter als 60 Tage sind, und Daten, die nach der Konfigurationsänderung gespeichert wurden, wenn sie älter als 90 Tage ist.
• config.synthetics.retention.days wurde von 60 Tagen in 7 Tage geändert: Daten, die vor der Konfigurationsänderung gespeichert wurden, werden gelöscht, wenn sie älter als 60 Tage sind, und Daten, die nach der Konfigurationsänderung gespeichert sind, werden gelöscht, wenn sie älter als 7 Tage sind.

Wenn Ihre Konfigurationsdatei für Core bereit ist, wenden Sie sie wie folgt an:

kubectl apply -f path/to/core.yaml
 

Überprüfen Sie, ob alle Pods ausgeführt werden, bevor Sie wie folgt fortfahren:

kubectl get pods -n instana-core
 

Überprüfen Sie den Status der Ressource „core“ im Namespace „instana-core“:

kubectl get core -n instana-core
 

Das folgende Beispiel zeigt eine Beispielausgabe:

NAME           VERSION   INSTANA VERSION   DB MIGRATION STATUS   COMPONENTS STATUS
instana-core   1.2.0     3.289.589-0       Ready                 Ready
 

Das Erstellen einer Einheit und eines Tenants ist einfach.

Um eine Einheit und einen Mieter anzulegen, erstellen Sie eine Datei „Unit YAML “, unit.yaml wie im folgenden Beispiel gezeigt:

apiVersion: instana.io/v1beta2
kind: Unit
metadata:
  namespace: instana-units
  name: tenant0-unit0
spec:
  # Must refer to the namespace of the associated Core object that was created previously
  coreName: instana-core

  # Must refer to the name of the associated Core object that was created previously
  coreNamespace: instana-core

  # The name of the tenant
  # Tenant name must match the regular expression pattern `^[a-z][a-z0-9]*$`
  # Tenant name must not exceed a maximum length of 15 characters
  # Tenant name must begin with an alphabetical character
  # Tenant name can consist of alphanumeric characters
  # Characters must be in lowercase
  tenantName: tenant0

  # The name of the unit within the tenant
  unitName: unit0

  # The same rules apply as for Cores. May be ommitted. Default is 'medium'
  resourceProfile: large
 

Wenn Ihre Konfiguration bereit ist, wenden Sie Ihre Einstellungen wie folgt an:

kubectl apply -f path/to/unit.yaml
 

Überprüfen Sie, ob alle Pods ausgeführt werden, bevor Sie wie folgt fortfahren:

kubectl get pods -n instana-units
 

Eine Liste der Einheiten im Namensraum „instana-units“ abrufen:

kubectl get unit -n instana-units
 

Das folgende Beispiel zeigt eine Beispielausgabe:

AME           VERSION   INSTANA VERSION   DB MIGRATION STATUS   COMPONENTS STATUS
instana-unit   1.2.0     3.289.589-0       Ready                 Ready
 

Fügen Sie die folgenden Zeilen in die Datei unit.yaml ein, um die Toleranzen und den Knotenselektor festzulegen

 spec:
   tolerations:
     - key: node.instana.io/monitor
       operator: Equal
       effect: NoSchedule
       value: "true"
   nodeSelector:
     node-role.kubernetes.io/monitor: "true"
 

Einige Funktionen sind in einem selbst gehosteten Back-End standardmäßig nicht aktiviert. Sie können diese Funktionen mithilfe zusätzlicher Konfigurationsoptionen aktivieren.

Weitere Informationen zu den optionalen Funktionen und deren Aktivierung finden Sie unter „Optionale Funktionen aktivieren “.