Erstellen eines Eingangscontrollers
Ein Eingangscontroller ist eine Softwarekomponente, die einen Reverseproxy, konfigurierbare Datenverkehrsweiterleitung und TLS-Terminierung für Kubernetes-Dienste bereitstellt. Mithilfe von Ressourcen für eingehende Kubernetes-Daten werden Eingangsregeln und Routen für einzelne Kubernetes-Dienste konfiguriert. Wenn Sie einen Eingangsdatencontroller und Eingangsregeln verwenden, kann eine einzelne IP-Adresse zum Weiterleiten von Datenverkehr an mehrere Dienste in einem Kubernetes-Cluster verwendet werden.
Dieser Artikel beschreibt, wie Sie den NGINX-Eingangscontroller in einem AKS-Cluster (Azure Kubernetes Service) bereitstellen. Es werden zwei Anwendungen im AKS-Cluster ausgeführt, die jeweils über eine einzelne IP-Adresse zugänglich sind.
Wichtig
Das Anwendungsrouting-Add-On wird für den Eingang in AKS empfohlen. Weitere Informationen finden Sie unter Verwalten von nginx-Eingang mit dem Anwendungsrouting-Add-On.
Hinweis
Es gibt zwei Open-Source-Eingangsdatencontroller für Kubernetes, die auf Nginx basieren: Ein Eingangsdatencontroller wird von der Kubernetes-Community verwaltet (kubernetes/ingress-nginx), und einer von NGINX, Inc. (nginxinc/kubernetes-ingress). In diesem Artikel wird der Eingangscontroller der Kubernetes-Community verwendet.
Voraussetzungen
- In diesem Artikel wird der NGINX-Eingangscontroller mithilfe von Helm 3 auf einer unterstützten Version von Kubernetes installiert. Stellen Sie sicher, dass Sie das neueste Release von Helm verwenden und auf das Helm-Repository ingress-nginx zugreifen können. Die in diesem Artikel beschriebenen Schritte sind mit früheren Versionen des Helm-Charts, des NGINX-Eingangscontrollers oder von Kubernetes möglicherweise nicht kompatibel.
- Darüber hinaus wird in diesem Artikel vorausgesetzt, dass Sie über einen vorhandenen AKS-Cluster mit einer integrierten Azure Container Registry-Instanz (ACR) verfügen. Weitere Informationen zum Erstellen eines AKS-Clusters mit integrierter ACR-Instanz finden Sie unter Authentifizieren über Azure Container Registry aus Azure Kubernetes Service.
- Der Integritätsendpunkt der Kubernetes-API
healthzwurde in Kubernetes v1.16 veraltet. Sie können diesen Endpunkt stattdessen durch die Endpunktelivezundreadyzersetzen. Unter Kubernetes-API-Endpunkte für Integrität finden Sie Informationen, um zu bestimmen, welcher Endpunkt für Ihr Szenario verwendet werden soll. - Wenn Sie Azure CLI verwenden, müssen Sie für diesen Artikel Version 2.0.64 oder höher der Azure-Befehlszeilenschnittstelle ausführen. Führen Sie
az --versionaus, um die Version zu ermitteln. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sie bei Bedarf unter Installieren der Azure CLI. - Wenn Sie Azure PowerShell verwenden, erfordert dieser Artikel, dass Sie Azure PowerShell-Version 5.9.0 oder höher verwenden. Führen Sie
Get-InstalledModule -Name Azaus, um die Version zu ermitteln. Falls Sie eine Installation oder ein Upgrade ausführen müssen, finden Sie unter Installieren von Azure PowerShell weitere Informationen.
Basiskonfiguration
Verwenden Sie Helm, um einen einfachen NGINX-Eingangsdatencontroller zu erstellen, ohne die Standardwerte anzupassen. Die folgende Konfiguration verwendet aus Gründen der Einfachheit die Standardkonfiguration. Sie können Parameter zum Anpassen der Bereitstellung hinzufügen, wie z. B. --set controller.replicaCount=3.
Hinweis
Wenn Sie die Beibehaltung der Clientquell-IP für Anforderungen an Container in Ihrem Cluster aktivieren möchten, fügen Sie dem Helm-Installationsbefehl --set controller.service.externalTrafficPolicy=Local hinzu. Die Clientquell-IP wird in der Anforderungskopfzeile unter X-Forwarded-For gespeichert. Wenn Sie einen Eingangsdatencontroller mit aktivierter Clientquell-IP-Beibehaltung verwenden, funktioniert TLS-Passthrough nicht.
NAMESPACE=ingress-basic
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm install ingress-nginx ingress-nginx/ingress-nginx \
--create-namespace \
--namespace $NAMESPACE \
--set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
--set controller.service.externalTrafficPolicy=Local
Hinweis
In diesem Tutorial wird service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path auf /healthz festgelegt. Dies bedeutet Folgendes: Falls der Antwortcode der Anforderungen an /healthz nicht 200 ist, ist der gesamte Eingangsdatencontroller nicht verfügbar. Sie können den Wert in Ihrem eigenen Szenario in einen anderen URI ändern. Sie können diesen Teil oder den Wert nicht löschen, andernfalls ist der Eingangscontroller weiterhin nicht verfügbar.
Das in diesem Tutorial verwendete Paket ingress-nginx, das in der offiziellen Kubernetes-Dokumentation bereitgestellt wird, gibt bei der Anforderung von /healthz immer den Antwortcode 200 zurück, da es als Standard-Back-End entworfen wurde, damit Benutzer schnell beginnen können, es sei denn, es wird von Eingangsregeln überschrieben.
Angepasste Konfiguration
Als Alternative zur Basiskonfiguration im obigen Abschnitt zeigen die nächsten Schritte, wie Sie einen benutzerdefinierten Eingangscontroller bereitstellen. Sie haben die Möglichkeit, eine interne statische IP-Adresse oder eine dynamische öffentliche IP-Adresse zu verwenden.
Importieren der vom Helm-Diagramm verwendeten Images in Ihre ACR
Sie müssen die Imageversionen in Ihre eigene Azure Container Registry-Instanz importieren, um deren Versionen zu steuern. Das Helm-Chart des NGINX-Eingangscontrollers basiert auf drei Containerimages. Verwenden Sie az acr import, um diese Images in Ihre ACR zu importieren.
REGISTRY_NAME=<REGISTRY_NAME>
SOURCE_REGISTRY=registry.k8s.io
CONTROLLER_IMAGE=ingress-nginx/controller
CONTROLLER_TAG=v1.8.1
PATCH_IMAGE=ingress-nginx/kube-webhook-certgen
PATCH_TAG=v20230407
DEFAULTBACKEND_IMAGE=defaultbackend-amd64
DEFAULTBACKEND_TAG=1.5
az acr import --name $REGISTRY_NAME --source $SOURCE_REGISTRY/$CONTROLLER_IMAGE:$CONTROLLER_TAG --image $CONTROLLER_IMAGE:$CONTROLLER_TAG
az acr import --name $REGISTRY_NAME --source $SOURCE_REGISTRY/$PATCH_IMAGE:$PATCH_TAG --image $PATCH_IMAGE:$PATCH_TAG
az acr import --name $REGISTRY_NAME --source $SOURCE_REGISTRY/$DEFAULTBACKEND_IMAGE:$DEFAULTBACKEND_TAG --image $DEFAULTBACKEND_IMAGE:$DEFAULTBACKEND_TAG
Hinweis
Zusätzlich zum Importieren von Containerimages in Ihre ACR können Sie auch Helm-Diagramme in Ihre ACR importieren. Weitere Informationen finden Sie unter Pushen und Pullen von Helm-Diagrammen in eine Azure Container Registry-Instanz.
Erstellen eines Eingangscontrollers
Verwenden Sie zum Erstellen des Eingangsdatencontrollers Helm, um ingress-nginx zu installieren. Der Eingangsdatencontroller muss auf einem Linux-Knoten geplant werden. Windows Server-Knoten dürfen nicht auf dem Eingangscontroller ausgeführt werden. Ein Knotenselektor wird mit dem Parameter --set nodeSelector angegeben, um den Kubernetes-Scheduler anzuweisen, den NGINX-Eingangscontroller auf einem Linux-basierten Knoten auszuführen.
Für zusätzliche Redundanz werden zwei Replikate der NGINX-Eingangscontroller mit dem Parameter --set controller.replicaCount bereitgestellt. Um vollständig von der Ausführung von Replikaten des Eingangscontrollers zu profitieren, stellen Sie sicher, dass sich mehr als ein Knoten im AKS-Cluster befindet.
Im folgenden Beispiel wird der Kubernetes-Namespace namens ingress-basic für die Eingangsressourcen erstellt, und es ist beabsichtigt, in diesem Namespace zu arbeiten. Geben Sie ggf. einen Namespace für Ihre eigene Umgebung an. Wenn in Ihrem AKS-Cluster keine rollenbasierte Zugriffssteuerung (RBAC) von Kubernetes aktiviert ist, fügen Sie den Helm-Befehlen --set rbac.create=false hinzu.
Hinweis
Wenn Sie die Beibehaltung der Clientquell-IP für Anforderungen an Container in Ihrem Cluster aktivieren möchten, fügen Sie dem Helm-Installationsbefehl --set controller.service.externalTrafficPolicy=Local hinzu. Die Clientquell-IP wird in der Anforderungskopfzeile unter X-Forwarded-For gespeichert. Wenn Sie einen Eingangsdatencontroller mit aktivierter Clientquell-IP-Beibehaltung verwenden, funktioniert TLS-Passthrough nicht.
# Add the ingress-nginx repository
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
# Set variable for ACR location to use for pulling images
ACR_LOGIN_SERVER=<REGISTRY_LOGIN_SERVER>
# Use Helm to deploy an NGINX ingress controller
helm install ingress-nginx ingress-nginx/ingress-nginx \
--version 4.7.1 \
--namespace ingress-basic \
--create-namespace \
--set controller.replicaCount=2 \
--set controller.nodeSelector."kubernetes\.io/os"=linux \
--set controller.image.registry=$ACR_LOGIN_SERVER \
--set controller.image.image=$CONTROLLER_IMAGE \
--set controller.image.tag=$CONTROLLER_TAG \
--set controller.image.digest="" \
--set controller.admissionWebhooks.patch.nodeSelector."kubernetes\.io/os"=linux \
--set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
--set controller.service.externalTrafficPolicy=Local \
--set controller.admissionWebhooks.patch.image.registry=$ACR_LOGIN_SERVER \
--set controller.admissionWebhooks.patch.image.image=$PATCH_IMAGE \
--set controller.admissionWebhooks.patch.image.tag=$PATCH_TAG \
--set controller.admissionWebhooks.patch.image.digest="" \
--set defaultBackend.nodeSelector."kubernetes\.io/os"=linux \
--set defaultBackend.image.registry=$ACR_LOGIN_SERVER \
--set defaultBackend.image.image=$DEFAULTBACKEND_IMAGE \
--set defaultBackend.image.tag=$DEFAULTBACKEND_TAG \
--set defaultBackend.image.digest=""
Erstellen eines Eingangsdatencontrollers mit einer internen IP-Adresse
Standardmäßig wird ein NGINX-Eingangscontroller mit Zuweisung einer dynamischen öffentlichen IP-Adresse erstellt. Eine verbreitete Konfigurationsanforderung stellt die Verwendung eines internen privaten Netzwerks und einer IP-Adresse dar. Dieser Ansatz ermöglicht die Beschränkung des Zugriffs auf Ihre Dienste auf interne Benutzer, sodass kein externer Zugriff möglich ist.
Verwenden Sie die Parameter --set controller.service.loadBalancerIP und --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-internal"=true, um Ihrem Eingangsdatencontroller eine interne IP-Adresse zuzuweisen. Geben Sie eine eigene interne IP-Adresse für die Verwendung für den Eingangscontroller an. Stellen Sie sicher, dass diese IP-Adresse nicht bereits in Ihrem virtuellen Netzwerk verwendet wird. Wenn Sie ein vorhandenes virtuelles Netzwerk und Subnetz verwenden, müssen Sie Ihren AKS-Cluster mit den richtigen Berechtigungen zur Verwaltung des virtuellen Netzwerks und Subnetzes konfigurieren. Weitere Informationen finden Sie unter Verwenden von kubenet-Netzwerken mit Ihren eigenen IP-Adressbereichen in Azure Kubernetes Service (AKS) oder Konfigurieren von Azure CNI-Netzwerken in Azure Kubernetes Service (AKS).
# Add the ingress-nginx repository
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
# Set variable for ACR location to use for pulling images
ACR_LOGIN_SERVER=<REGISTRY_LOGIN_SERVER>
# Use Helm to deploy an NGINX ingress controller
helm install ingress-nginx ingress-nginx/ingress-nginx \
--version 4.7.1 \
--namespace ingress-basic \
--create-namespace \
--set controller.replicaCount=2 \
--set controller.nodeSelector."kubernetes\.io/os"=linux \
--set controller.image.registry=$ACR_LOGIN_SERVER \
--set controller.image.image=$CONTROLLER_IMAGE \
--set controller.image.tag=$CONTROLLER_TAG \
--set controller.image.digest="" \
--set controller.admissionWebhooks.patch.nodeSelector."kubernetes\.io/os"=linux \
--set controller.service.loadBalancerIP=10.224.0.42 \
--set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-internal"=true \
--set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
--set controller.admissionWebhooks.patch.image.registry=$ACR_LOGIN_SERVER \
--set controller.admissionWebhooks.patch.image.image=$PATCH_IMAGE \
--set controller.admissionWebhooks.patch.image.tag=$PATCH_TAG \
--set controller.admissionWebhooks.patch.image.digest="" \
--set defaultBackend.nodeSelector."kubernetes\.io/os"=linux \
--set defaultBackend.image.registry=$ACR_LOGIN_SERVER \
--set defaultBackend.image.image=$DEFAULTBACKEND_IMAGE \
--set defaultBackend.image.tag=$DEFAULTBACKEND_TAG \
--set defaultBackend.image.digest=""
Prüfen Sie den Lastenausgleichsdienst
Überprüfen Sie den Lastenausgleichsdienst, indem Sie kubectl get services verwenden.
kubectl get services --namespace ingress-basic -o wide -w ingress-nginx-controller
Wird der Kubernetes-Lastenausgleichsdienst für den NGINX-Eingangsdatencontroller erstellt, wird eine IP-Adresse unter EXTERNAL-IP zugewiesen, wie in der folgenden Beispielausgabe gezeigt:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
ingress-nginx-controller LoadBalancer 10.0.65.205 EXTERNAL-IP 80:30957/TCP,443:32414/TCP 1m app.kubernetes.io/component=controller,app.kubernetes.io/instance=ingress-nginx,app.kubernetes.io/name=ingress-nginx
Wenn Sie zu diesem Zeitpunkt zu der externen IP-Adresse navigieren, wird die Seite 404 angezeigt. Dies liegt daran, dass Sie die Verbindung mit der externen IP-Adresse noch einrichten müssen, was in den nächsten Abschnitten erfolgt.
Ausführen von Demoanwendungen
Um den Eingangscontroller in Aktion zu sehen, führen Sie zwei Demoanwendungen im AKS-Cluster aus. In diesem Beispiel verwenden Sie kubectl apply, um mehrere Instanzen einer einfachen Hallo Welt-Anwendung auszuführen.
Erstellen Sie eine Datei
aks-helloworld-one.yaml, und kopieren Sie den folgenden YAML-Beispielcode:apiVersion: apps/v1 kind: Deployment metadata: name: aks-helloworld-one spec: replicas: 1 selector: matchLabels: app: aks-helloworld-one template: metadata: labels: app: aks-helloworld-one spec: containers: - name: aks-helloworld-one image: mcr.microsoft.com/azuredocs/aks-helloworld:v1 ports: - containerPort: 80 env: - name: TITLE value: "Welcome to Azure Kubernetes Service (AKS)" --- apiVersion: v1 kind: Service metadata: name: aks-helloworld-one spec: type: ClusterIP ports: - port: 80 selector: app: aks-helloworld-oneErstellen Sie eine Datei
aks-helloworld-two.yaml, und kopieren Sie den folgenden YAML-Beispielcode:apiVersion: apps/v1 kind: Deployment metadata: name: aks-helloworld-two spec: replicas: 1 selector: matchLabels: app: aks-helloworld-two template: metadata: labels: app: aks-helloworld-two spec: containers: - name: aks-helloworld-two image: mcr.microsoft.com/azuredocs/aks-helloworld:v1 ports: - containerPort: 80 env: - name: TITLE value: "AKS Ingress Demo" --- apiVersion: v1 kind: Service metadata: name: aks-helloworld-two spec: type: ClusterIP ports: - port: 80 selector: app: aks-helloworld-twoFühren Sie die beiden Demoanwendungen mit
kubectl applyaus:kubectl apply -f aks-helloworld-one.yaml --namespace ingress-basic kubectl apply -f aks-helloworld-two.yaml --namespace ingress-basic
Erstellen einer Eingangsroute
Beide Anwendungen werden jetzt in Ihrem Kubernetes-Cluster ausgeführt. Zum Weiterleiten von Datenverkehr an die einzelnen Anwendungen erstellen Sie eine Kubernetes-Eingangsressource. Die Eingangsressource konfiguriert Regeln, die den Datenverkehr an eine der beiden Anwendungen weiterleiten.
Im folgenden Beispiel wird der Datenverkehr an EXTERNAL_IP/hello-world-one an den Dienst mit dem Namen aks-helloworld-one weitergeleitet. Datenverkehr an EXTERNAL_IP/hello-world-two wird an den Dienst aks-helloworld-two weitergeleitet. Datenverkehr an EXTERNAL_IP/static wird für statische Ressourcen an den Dienst mit dem Namen aks-helloworld-one weitergeleitet.
Erstellen Sie eine Datei mit dem Namen
hello-world-ingress.yaml, und fügen Sie den folgenden YAML-Beispielcode ein:apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: hello-world-ingress annotations: nginx.ingress.kubernetes.io/ssl-redirect: "false" nginx.ingress.kubernetes.io/use-regex: "true" nginx.ingress.kubernetes.io/rewrite-target: /$2 spec: ingressClassName: nginx rules: - http: paths: - path: /hello-world-one(/|$)(.*) pathType: Prefix backend: service: name: aks-helloworld-one port: number: 80 - path: /hello-world-two(/|$)(.*) pathType: Prefix backend: service: name: aks-helloworld-two port: number: 80 - path: /(.*) pathType: Prefix backend: service: name: aks-helloworld-one port: number: 80 --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: hello-world-ingress-static annotations: nginx.ingress.kubernetes.io/ssl-redirect: "false" nginx.ingress.kubernetes.io/rewrite-target: /static/$2 spec: ingressClassName: nginx rules: - http: paths: - path: /static(/|$)(.*) pathType: Prefix backend: service: name: aks-helloworld-one port: number: 80Erstellen Sie die Eingangsressource mit dem Befehl
kubectl apply.kubectl apply -f hello-world-ingress.yaml --namespace ingress-basic
Testen des Eingangscontrollers
Navigieren Sie zu den beiden Anwendungen, um die Routen für den Eingangscontroller zu testen. Öffnen Sie in einem Webbrowser die IP-Adresse Ihres NGINX-Eingangscontrollers, z. B. EXTERNAL_IP. Die erste Demoanwendung wird im Webbrowser angezeigt, wie im folgenden Beispiel gezeigt:
Fügen Sie nun den Pfad /hello-world-two der IP-Adresse hinzu, z. B. EXTERNAL_IP/hello-world-two. Die zweite Demoanwendung mit dem benutzerdefinierten Titel wird angezeigt:
Testen einer internen IP-Adresse
Erstellen Sie einen Testpod, und fügen Sie an diesen eine Terminalsitzung an.
kubectl run -it --rm aks-ingress-test --image=mcr.microsoft.com/dotnet/runtime-deps:6.0 --namespace ingress-basicInstallieren Sie
curlmittelsapt-getim Pod.apt-get update && apt-get install -y curlGreifen Sie nun mit
curlauf die Adresse des Kubernetes-Eingangsdatencontrollers zu, beispielsweise http://10.224.0.42. Geben Sie Ihre eigene interne IP-Adresse an, die Sie beim Bereitstellen des Eingangscontrollers verwendet haben.curl -L http://10.224.0.42Die Adresse wurde ohne Pfad angegeben, sodass der Eingangsdatencontroller standardmäßig die Route / verwendet. Die erste Demoanwendung wird zurückgegeben, wie in der folgenden verkürzten Beispielausgabe gezeigt:
<!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <link rel="stylesheet" type="text/css" href="/static/default.css"> <title>Welcome to Azure Kubernetes Service (AKS)</title> [...]Fügen Sie den Pfad /hello-world-two der Adresse hinzu, beispielsweise http://10.224.0.42/hello-world-two.
curl -L -k http://10.224.0.42/hello-world-twoDie zweite Demoanwendung wird mit dem benutzerdefinierten Titel zurückgegeben, wie in der folgenden verkürzten Beispielausgabe gezeigt:
<!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <link rel="stylesheet" type="text/css" href="/static/default.css"> <title>AKS Ingress Demo</title> [...]
Bereinigen von Ressourcen
In diesem Artikel wird Helm verwendet, um die Eingangskomponenten und die Beispiel-Apps zu installieren. Wenn Sie ein Helm-Chart bereitstellen, werden zahlreiche Kubernetes-Ressourcen erstellt. Zu diesen Ressourcen gehören Pods, Bereitstellungen und Dienste. Sie können zur Bereinigung der Ressourcen entweder den gesamten Beispielnamespace oder die einzelnen Ressourcen löschen.
Löschen des Beispielnamespace und aller Ressourcen
Verwenden Sie den kubectl delete-Befehl mit dem Namespacenamen, um den gesamten Beispielnamespace zu löschen. Alle Ressourcen im Namespace werden gelöscht.
kubectl delete namespace ingress-basic
Löschen einzelner Ressourcen
Mehr Kontrolle bietet eine andere Vorgehensweise, bei der Sie einzelne Ressourcen löschen.
Listen Sie mit dem Befehl
helm listdie Helm-Releases auf.helm list --namespace ingress-basicSuchen Sie nach Diagrammen mit den Namen ingress-nginx und aks-helloworld, wie in der folgenden Beispielausgabe gezeigt:
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION ingress-nginx ingress-basic 1 2020-01-06 19:55:46.358275 -0600 CST deployed nginx-ingress-1.27.1 0.26.1Deinstallieren Sie die Versionen mit dem Befehl
helm uninstall.helm uninstall ingress-nginx --namespace ingress-basicEntfernen Sie die beiden Beispielanwendungen.
kubectl delete -f aks-helloworld-one.yaml --namespace ingress-basic kubectl delete -f aks-helloworld-two.yaml --namespace ingress-basicEntfernen Sie die Eingangsroute, die Datenverkehr an die Beispiel-Apps weitergeleitet hat.
kubectl delete -f hello-world-ingress.yamlLöschen Sie den Namespace mit dem
kubectl delete-Befehl und geben Sie Ihren Namespacenamen an.kubectl delete namespace ingress-basic
Nächste Schritte
Informationen zum Konfigurieren von TLS mit ihren vorhandenen Eingangskomponenten finden Sie unter Verwenden von TLS mit einem Eingangsdatencontroller.
Informationen zum Konfigurieren Ihres AKS-Clusters für die Verwendung von HTTP-Anwendungsrouting finden Sie unter Aktivieren des HTTP-Anwendungsrouting-Add-Ons.
In diesem Artikel werden einige externe Komponenten in AKS berücksichtigt. Weitere Informationen zu diesen Komponenten finden Sie auf den folgenden Projektseiten: