Anwendungslogs auf virtuellen Knoten anzeigen

Erfahren Sie, wie Sie die Logs der Anwendungen anzeigen, die auf virtuellen Knoten in einem Kubernetes-Cluster ausgeführt werden, das Sie mit der Kubernetes Engine (OKE) erstellt haben.

Nachdem Sie mit Kubernetes Engine ein Cluster mit virtuellen Knoten erstellt haben, haben Sie zwei Optionen für den Zugriff auf die Logs von Anwendungen, die auf den virtuellen Knoten ausgeführt werden:

Zeigen Sie die stdout- und stderr-Logs aus Anwendungscontainern mit dem Befehl kubectl logs an.
Senden Sie Anwendungslogs zur Anzeige an einen persistenten Log-Server.

stdout- und stderr-Logs mit dem kubectl logs-Befehl anzeigen

So zeigen Sie die stdout- und stderr-Logs aus den Containern einer Anwendung mit dem Befehl kubectl logs an:

Falls noch nicht geschehen, führen Sie die Schritte zum Einrichten der kubeconfig-Konfigurationsdatei des Clusters aus, und legen Sie (gegebenenfalls) die Umgebungsvariable KUBECONFIG so fest, dass sie auf die Datei verweist. Beachten Sie, dass Sie Ihre eigene kubeconfig-Datei einrichten müssen. Sie können nicht mit einer kubeconfig-Datei, die von einem anderen Benutzer eingerichtet wurde, auf ein Cluster zugreifen. Siehe Clusterzugriff einrichten.
Führen Sie in einem Terminalfenster den Befehl kubectl logs aus, indem Sie Folgendes eingeben:
```
kubectl logs <pod-name>
```
Beispiel:
```
kubectl logs nginx
```
Wenn der Pod mehrere Container enthält, geben Sie den Container an, für den Sie die Logs anzeigen möchten. Beispiel: Wenn der myapp-Pod zwei Container mit den Namen nginx und logging enthält und Sie die Logs des logging-Containers anzeigen möchten, geben Sie Folgendes ein:
```
kubectl logs myapp logging
```

Logs an einen persistenten Log-Server senden

Sie können die Logs von Anwendungen, die auf virtuellen Knoten ausgeführt werden, an einen Remote-Logserver wie OpenSearch senden und die Logs auf diesem Server anzeigen. Da virtuelle Knoten das Kubernetes-Daemonset nicht unterstützen, können Sie keinen Logging-Agent auf Knotenebene ausführen. Stattdessen können Sie einen Lightweight Logging Agent als Sidecar für jeden Pod der Anwendung ausführen. Sie können jeden Logging-Agent verwenden, der als Sidecar auf einem Kubernetes-Pod ausgeführt werden kann, wie Fluent Bit.

Beispiel: So führen Sie Fluent Bit als Sidecar auf einem Pod aus, um Anwendungslogs an einen Remote-Logserver OpenSearch zu senden:

Erstellen Sie eine Kubernetes-ConfigMap pro Cluster oder pro Namespace, und geben Sie die zu verwendenden Fluent Bit-Konfigurationseinstellungen an. Beachten Sie insbesondere, dass Sie die IP-Adresse, Portnummer und Authentifizierungsparameter des Remote-Logservers angeben müssen.
Beispiel:
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: fluentbit-config
data:
  fluent-bit.conf: |
    [SERVICE]
        flush        1
        daemon       Off
 
    [INPUT]
        Name              tail
        Path              /mnt/log/*
 
    [OUTPUT]
        name  opensearch
        match *
        host <ip-address>
        port <port-number>
        tls On
        HTTP_User <username>
        HTTP_Passwd <example-password>
        Index fluent-bit
        Suppress_Type_Name On
```
Hierbei gilt:
- host <ip-address> gibt die IP-Adresse des Openearch-Servers an.
- port <port-number> gibt den Port des Openearch-Servers an (standardmäßig 9200).
- HTTP_User <username> gibt den Benutzernamen für den Openearch-Server an.
- HTTP_Passwd <example-password> gibt das Kennwort für den Openearch-Server an.

Fügen Sie jedem Pod einen Fluent Bit Sidecar hinzu. Beachten Sie, dass Sie alle Pods mit einem Fluent Bit-Sidecar konfigurieren müssen, um sicherzustellen, dass Anwendungslogs an das persistente Logziel gesendet werden.

Geben Sie im Abschnitt volumes jeder Podspezifikation Folgendes an:
- Eine emptyDir, in die Anwendungslogs geschrieben werden:
```
- name: logs
  emptyDir: {}
```
- Eine Referenz auf die zuvor erstellte ConfigMap wie folgt:
```
- name: fluentbit-config
  configMap:
    name: fluentbit-config
```

Im Abschnitt containers jeder Podspezifikation müssen Sie angeben, dass der Loggingcontainer:

Verwendet das Image fluent/fluent-bit.
Hängt die logs emptyDir und die fluentbit-config ConfigMap ein.

Beispiel:

- name: logging
  image: fluent/fluent-bit
  resources:
    requests:
      cpu: 100m
      memory: 50Mi
  volumeMounts:
  - name: logs
    mountPath: /mnt/log
  - name: fluentbit-config
    mountPath: /fluent-bit/etc

Im Folgenden finden Sie ein Beispiel für eine vollständige Podspezifikation:

apiVersion: v1
kind: Pod
metadata:
  name: date-logging
spec:
  containers:
  - name: date
    image: busybox
    resources:
      requests:
        cpu: 500m
        memory: 200Mi
    command: ["sh", "-c"]
    args:
      - while [ 1 ]; do
        echo "Writing the date in /mnt/log/date.log";
        date >> /mnt/log/date.log;
        sleep 10;
        done
    volumeMounts:
    - name: logs
      mountPath: /mnt/log
  - name: logging
    image:
     resources:
      requests:
        cpu: 100m
        memory: 50Mi
    volumeMounts:
    - name: logs
      mountPath: /mnt/log
    - name: fluentbit-config
      mountPath: /fluent-bit/etc
  volumes:
  - name: logs
    emptyDir: {}
  - name: fluentbit-config
    configMap:
      name: fluentbit-config

Oracle Cloud Infrastructure - Dokumentation

Anwendungslogs auf virtuellen Knoten anzeigen

stdout- und stderr-Logs mit dem kubectl logs-Befehl anzeigen

Logs an einen persistenten Log-Server senden