Helm Chart installiert EFK und überprüft die Funktionalität
In diesem Artikel wird erläutert, wie Sie mithilfe von Helm Chart schnell das Protokollerfassungssystem EFK (Elasticsearch, Filebeat, Kibana) V8.5.1 in der Kubernetes-Umgebung erstellen und seine Funktionen überprüfen können. Wenn Sie nur an der Installation interessiert sind, gehen Sie bitte direkt zum Kapitel „EFK (Elasticsearch, Filebeat, Kibana) V8.5.1 Installation“.
Hintergrundanforderungen für das Protokollerfassungssystem
Da die Komplexität verschiedener Softwaresysteme immer höher wird, insbesondere nach der Bereitstellung in der Cloud, ist es grundsätzlich unmöglich, sich bei jedem Knoten anzumelden, um die Protokolle jedes Moduls anzuzeigen. Denn es ist nicht nur ineffizient, sondern manchmal ist es aus Sicherheitsgründen auch unmöglich, Ingenieuren direkten Zugriff auf einzelne physische Knoten zu gewähren. Darüber hinaus übernehmen große Softwaresysteme mittlerweile grundsätzlich die Cluster-Bereitstellungsmethode, was bedeutet, dass für jeden Dienst mehrere identische PODs gestartet werden, um externe Dienste bereitzustellen, und jeder Container nur aus dem generierten Protokoll ein eigenes Protokoll generiert. , Sie Ich weiß nicht, welcher POD es überhaupt generiert hat, was es schwieriger macht, verteilte Protokolle anzuzeigen.
Im Cloud-Zeitalter ist daher eine Lösung zum Sammeln und Analysieren von Protokollen erforderlich. Zunächst ist es notwendig, die in verschiedenen Ecken verteilten Baumstämme an einem zentralen Ort zu sammeln, damit sie leicht sichtbar sind.
Vergleich mehrerer Mainstream-Lösungen
- ELK (Elasticsearch, Logstash, Kibana)
- EFK (Elasticsearch, Filebeat, Kibana)
- EFK (Elasticsearch, Fluentd, Kibana)
Im Internet gibt es viele verwandte Einführungen zu den Vor- und Nachteilen sowie den anwendbaren Szenarien dieser Protokollerfassungssysteme. Ich werde hier nur einen einfachen Vergleich anstellen.
a. ELK (Elasticsearch, Logstash, Kibana) vs. EFK (Elasticsearch, Fluentd, Kibana)
Architektur und Anwendbarkeit:
EFK: Die EFK-Architektur basiert auf Fluentd, das Protokolldaten über Fluentd sammelt und an Elasticsearch überträgt und dann Kibana zur Visualisierung und Analyse verwendet. EFK eignet sich für komplexe Protokollerfassungs- und Analyseanforderungen und eignet sich besonders gut für die Verarbeitung umfangreicher Protokolldaten.
ELK: Die ELK-Architektur basiert auf Logstash, das Protokolldaten über Logstash sammelt, umwandelt und an Elasticsearch überträgt und anschließend Kibana zur Visualisierung und Analyse verwendet. ELK eignet sich für mittlere Protokollerfassungs- und Analyseanforderungen und kann Daten aus mehreren Quellen verarbeiten.
Komponenten und Technologien:
EFK: EFK steht für Elasticsearch, Fluentd und Kibana. Elasticsearch ist eine verteilte Such- und Analysemaschine zum Speichern und Indizieren von Protokolldaten. Fluentd ist ein Open-Source-Protokollerfassungs- und -übertragungstool zum Sammeln und Übertragen von Protokolldaten aus verschiedenen Quellen an Elasticsearch. Kibana ist ein Visualisierungstool zum Suchen, Analysieren und Visualisieren von in Elasticsearch gespeicherten Daten.
ELK: ELK steht für Elasticsearch, Logstash und Kibana. Die Rolle von Elasticsearch und Kibana ist dieselbe wie in EFK. Logstash ist ein Open-Source-Tool zur Datenerfassung, -transformation und -übertragung zum Sammeln, Filtern und Transformieren von Daten aus verschiedenen Quellen und zum Senden dieser an Elasticsearch.
Konfiguration und Plug-in-Ökosystem:
EFK: Fluentd verfügt über ein umfangreiches Plug-in-Ökosystem, das problemlos verschiedene Datenquellen und -ziele integrieren und eine benutzerdefinierte Plug-in-Entwicklung durchführen kann. Seine Konfiguration ist relativ komplex, aber auch sehr flexibel.
ELK: Logstash hat auch ein Plugin-Ökosystem, aber im Vergleich zu Fluentd relativ klein. Die Konfiguration von Logstash ist relativ einfach, hauptsächlich über Konfigurationsdateien.
Leistung und Skalierbarkeit:
EFK: Aufgrund der Verwendung von Fluentd als Datenübertragungstool ist EFK leichter, leistungsfähiger und skalierbarer als ELK. Fluentd verwendet einen Puffermechanismus zum Verarbeiten und Zwischenspeichern von Protokollereignissen, was einen höheren Durchsatz und eine höhere Skalierbarkeit bietet.
ELK: Aufgrund der Verwendung von Logstash als Datenübertragungstool kann ELK bei der Verarbeitung großer Datenmengen mehr Ressourcen beanspruchen und einen gewissen Einfluss auf die Leistung haben. Aber für mittlere Anforderungen an die Protokollerfassung und -analyse kann ELK immer noch eine gute Leistung bieten.
Zusammenfassend lässt sich sagen, dass die aktuelle Leistung und Anwendungsbreite von EFK (Elasticsearch, Fluentd, Kibana) höher ist als die von ELK (Elasticsearch, Logstash, Kibana).
b.ELK (Elasticsearch, Filebeat, Kibana) und EFK (Elasticsearch, Fluentd, Kibana)
Sowohl Fluentd als auch Filebeat sind Open-Source-Tools, die häufig zur Protokollerfassung verwendet werden und uns dabei helfen können, große Mengen an Protokolldaten zu sammeln, zu verarbeiten und weiterzuleiten. Obwohl sie alle ähnliche Funktionen haben, unterscheiden sie sich deutlich in der Designphilosophie und den Implementierungsdetails.
Fluentd ist ein von Treasure Data entwickeltes und verwaltetes Tool zur Protokollsammlung und -aggregation. Es unterstützt eine Vielzahl von Datenein- und -ausgaben und bietet eine Fülle von Plug-ins und Filtern zur Verarbeitung und Transformation von Daten. Fluentd verarbeitet Protokolldaten über Pipelines und kann komplexe Datenverarbeitungsprozesse flexibel aufbauen. Fluentd bietet außerdem einen integrierten Caching-Mechanismus, der das Risiko eines Datenverlusts verringert. Gleichzeitig ist Fluentd ein leichtes Tool, das weniger Systemressourcen beansprucht.
Filebeat ist ein leichter Protokolldatensammler von Elastic, der zum Sammeln, Analysieren und Weiterleiten verschiedener Arten von Protokolldaten entwickelt wurde. Es unterstützt mehrere Datenquellen und kann neue Protokolldateien automatisch erkennen. Filebeat hat einen geringen Ressourcenverbrauch und unterstützt Hochverfügbarkeit und Failover. Filebeat kann Protokolldaten an mehrere Ausgabeziele weiterleiten, z. B. Elasticsearch, Logstash oder Kafka usw.
Der Unterschied im Designkonzept zwischen den beiden besteht darin, dass Fluentd sich mehr auf die Datenverarbeitung und -konvertierung konzentriert, während Filebeat sich mehr auf die Datenerfassung und -übertragung konzentriert. Daher müssen bei der Auswahl des zu verwendenden Tools die spezifischen Szenarien und Anforderungen berücksichtigt werden.
Im Allgemeinen eignet sich Fluentd besser für Szenarien, die eine komplexe Datenverarbeitung und -konvertierung erfordern, während Filebeat eher für einfache Protokolldatenerfassungs- und -weiterleitungsszenarien geeignet ist. Wenn Sie ein leichtes Tool zum Verarbeiten umfangreicher Protokolldaten benötigen, ist Fluentd möglicherweise besser geeignet. Wenn Sie nur einen einfachen Protokollsammler zum schnellen Sammeln und Weiterleiten von Protokolldaten benötigen, ist Filebeat möglicherweise besser für Ihre Anforderungen geeignet.
1. Installation von EFK (Elasticsearch, Filebeat, Kibana) V8.5.1
1.1 Voraussetzungen
a. Helm-Version >=v3.2.0, Informationen zur Installation von Helm finden Sie unter: Helm-Installation
b. Eine Standard-StorageClass ist erforderlich. Den spezifischen Vorbereitungsprozess finden Sie unter: StorageClass auf Kubernetes installieren
c. (Nicht erforderlich) Es wird empfohlen, die Standard-IngressClasses zu verwenden. Den spezifischen Vorbereitungsprozess finden Sie unter: IngressClass auf Kubernetes installieren. Schritt 4 „Festlegen als Standard-Ingress-Klasse“ ist erforderlich. Gleichzeitig ist dies der Fall Am besten stellen Sie den NodePort-Port des Ingress auf 80 oder 443 ein
1.2 Installationsprozess
a. Erstellen Sie das Installationsverzeichnis
#切换到当前用户根目录并建立logging文件夹
cd ~ && mkdir logging
cd logging
b. Erstellen Sie einen Protokollierungs-Namespace. Ein unabhängiger Namespace hilft bei der Ressourcenverwaltung
kubectl create ns logging
c. Fügen Sie ein elastisches offizielles Repo-Warehouse hinzu
helm repo add elastic https://helm.elastic.co
d. Um Elasticsearch zu installieren und
einige benutzerdefinierte Anforderungen zu erfüllen, lesen Sie bitte die offizielle Datei „values.yaml“, in der jeder Parameter ausführlich beschrieben wird: offizielle Website-Referenz
helm pull elastic/elasticsearch --version 8.5.1
tar -xvf elasticsearch-8.5.1.tgz
cd elasticsearch
#（非必要）以下的操作主要是修改elasticsearch服务暴露方式以及ingress设置
vi values.yaml
#搜索ClusterIP关键字
service:
enabled: true
labels: {
}
labelsHeadless: {
}
type: ClusterIP #将此处改为NodePort
# Consider that all endpoints are considered "ready" even if the Pods themselves are not
# https://kubernetes.io/docs/reference/kubernetes-api/service-resources/service-v1/#ServiceSpec
publishNotReadyAddresses: false
nodePort: ""
annotations: {
}
httpPortName: http
transportPortName: transport
loadBalancerIP: ""
loadBalancerSourceRanges: []
externalTrafficPolicy: ""
#搜索ingress关键字
ingress:
enabled: false #改为true
annotations: {
}
# kubernetes.io/ingress.class: nginx #取消注释
# kubernetes.io/tls-acme: "true" #取消注释
className: "nginx"
pathtype: ImplementationSpecific
hosts:
- host: chart-example.local
paths:
- path: /
Führen Sie den Installationsbefehl aus
cd ~/logging
helm install elasticsearch ./elasticsearch -n logging
#成功后看到如下提示
NAME: elasticsearch
LAST DEPLOYED: Wed May 31 02:37:03 2023
NAMESPACE: logging
STATUS: deployed
REVISION: 1
NOTES:
1. Watch all cluster members come up.
$ kubectl get pods --namespace=logging -l app=elasticsearch-master -w
2. Retrieve elastic user's password.
$ kubectl get secrets --namespace=logging elasticsearch-master-credentials -ojsonpath='{
.data.password}' | base64 -d
3. Test cluster health using Helm test.
$ helm --namespace=logging test elasticsearch
#通过如下命令检测&确保Pod正确运行
kubectl get pods --namespace=logging -l app=elasticsearch-master -w
NAME READY STATUS RESTARTS AGE
elasticsearch-master-0 1/1 Running 0 3h10m
elasticsearch-master-1 1/1 Running 0 3h10m
elasticsearch-master-2 1/1 Running 0 3h10m
e. Installieren Sie
die offizielle Website-Referenz von Filebeat
cd ~/logging
helm pull elastic/filebeat --version 8.5.1
tar -xvf filebeat-8.5.1.tgz
执行安装命令
helm install filebeat ./filebeat -n logging
#成功后看到如下提示
NAME: filebeat
LAST DEPLOYED: Wed May 31 02:55:52 2023
NAMESPACE: logging
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
1. Watch all containers come up.
$ kubectl get pods --namespace=logging -l app=filebeat-filebeat -w
#通过如下命令检测&确保Pod正确运行
kubectl get pods --namespace=logging -l app=filebeat-filebeat -w
NAME READY STATUS RESTARTS AGE
filebeat-filebeat-asdn6 1/1 Running 0 3h6m
filebeat-filebeat-sdab4 1/1 Running 0 3h6m
filebeat-filebeat-asbvg 1/1 Running 0 175m
f. Installieren Sie die
offizielle Kibana-Website-Referenz
cd ~/logging
helm pull elastic/kibana --version 8.5.1
tar -xvf kibana-8.5.1.tgz
cd kibana
vi values.yaml
#对外暴露方式设置为NodePort，搜索ClusterIP关键字
service:
type: ClusterIP #此处修改为NodePort
loadBalancerIP: ""
port: 5601
nodePort: ""
labels: {
}
annotations: {
}
# cloud.google.com/load-balancer-type: "Internal"
# service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0
# service.beta.kubernetes.io/azure-load-balancer-internal: "true"
# service.beta.kubernetes.io/openstack-internal-load-balancer: "true"
# service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true"
loadBalancerSourceRanges: []
# 0.0.0.0/0
httpPortName: http
#（非必须）设置ingress地址，搜索ingress关键字
ingress:
enabled: false #修改为true
className: "nginx"
pathtype: ImplementationSpecific
annotations: {
}
# kubernetes.io/ingress.class: nginx #取消注释
# kubernetes.io/tls-acme: "true" #取消注释
hosts:
- host: kibana-example.local
paths:
- path: /
Führen Sie den Installationsbefehl aus
cd cd ~/logging
helm install kibana ./kibana -n logging
#成功后看到如下提示
NAME: kibana
LAST DEPLOYED: Wed May 31 03:16:37 2023
NAMESPACE: logging
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
1. Watch all containers come up.
$ kubectl get pods --namespace=logging -l release=kibana -w
2. Retrieve the elastic user's password.
$ kubectl get secrets --namespace=logging elasticsearch-master-credentials -ojsonpath='{
.data.password}' | base64 -d
3. Retrieve the kibana service account token.
$ kubectl get secrets --namespace=logging kibana-kibana-es-token -ojsonpath='{
.data.token}' | base64 -d
#通过如下命令检测&确保Pod正确运行
kubectl get pods --namespace=logging -l release=kibana -w
NAME READY STATUS RESTARTS AGE
kibana-kibana-234897xx1c-h38ncj 1/1 Running 0 177m
2. Funktionsüberprüfung
2.1 GUI-Anmeldung
a. Ermitteln Sie die NodePort-Portnummer des Kibana-Dienstes
kubectl get svc -n logging | grep kibana
kibana-kibana NodePort 172.16.67.29 <none> 5601:30239/TCP 3h3m
Sehen Sie, die Portnummer ist 19812
b. Holen Sie sich das Anmeldekennwort für die Kibana-Schnittstelle
. Nach der erfolgreichen Installation von Kibana über Helm Chart wird die Eingabeaufforderung angezeigt:
Rufen Sie das Kennwort des elastischen Benutzers ab.
$ kubectl get Secrets --namespace=logging elasticsearch-master-credentials -ojsonpath='{.data. Passwort} ' | base64 -d
kubectl get secrets --namespace=logging elasticsearch-master-credentials -ojsonpath='{.data.password}' | base64 -d
54iEaxD2AFE838H
c. Melden Sie sich über die grafische Oberfläche an, der Standardbenutzername ist „elastic“
und geben Sie „Datenströme“ in die Indexverwaltung ein. Sie können sehen, dass Filebeat-8.5.1 als Datenindexelement aufgeführt wurde
2.2 Überprüfung der Protokollsammlung
a. Erstellen Sie einen Pod, der Protokolle erstellt
cd ~/logging
vi test-logging-pod.yaml
#写入如下内容
apiVersion: v1
kind: Pod
metadata:
name: counter
spec:
containers:
- name: count
image: busybox
args: [/bin/sh, -c,
'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done']
b. Observability->Logs->Stream in der Schnittstelle anzeigen
