Nativen OCI-Ingress-Controller konfigurieren

Anforderungen basierend auf Host weiterleiten

Sie können den nativen OCI-Ingress-Controller so konfigurieren, dass eine eingehende Anforderung basierend auf dem Domainnamen im Hostheader der Anforderung (dem Host, an den die Anforderung ursprünglich gesendet wurde) weitergeleitet wird.

Um eine Anforderung basierend auf dem Host an einen bestimmten Backend-Service und -Port weiterzuleiten, erstellen Sie eine Routingregel im Manifest Ingress. Wenn der Host mit der Routingregel übereinstimmt, leitet der native OCI-Ingress-Controller die Anforderung an den zugehörigen Backend-Service und -Port weiter.

Beispiel: Sie können die folgende Regel definieren, um Anforderungen, die ursprünglich an http://foo.bar.com gesendet wurden, an einen Backend-Service namens ServiceA auf Port 80 weiterzuleiten. Der gesamte eingehende Traffic, der ursprünglich an http://foo.bar.com gesendet wurde, wird an Port 80 an ServiceA weitergeleitet.

kind: Ingress
...
spec:
  rules:
  - host: "foo.bar.com"
    http:
      paths:
        - pathType: Prefix
          path: /
          backend:
            serviceName: ServiceA
            servicePort: 80

Anforderungen basierend auf Pfad an verschiedene Backend-Services weiterleiten

Sie können den nativen OCI-Ingress-Controller so konfigurieren, dass eingehende Anforderungen basierend auf Elementen im Pfad, an den die Anforderungen ursprünglich gesendet wurden, an verschiedene Backend-Services weitergeleitet werden.

Um eine Anforderung basierend auf dem Pfad an einen bestimmten Backend-Service und -Port weiterzuleiten, erstellen Sie eine Routingregel im Manifest Ingress. Wenn der Pfad mit der Routingregel übereinstimmt, leitet der native Ingress-Controller von OCI die Anforderung an den zugehörigen Backend-Service und -Port weiter. Sie können mehrere Pfade in derselben Regel angeben, um Anforderungen an verschiedene Backends weiterzuleiten.

Beispiel: Sie können die folgende Regel definieren, um Anforderungen basierend auf dem Pfad weiterzuleiten, an den die Anforderung ursprünglich gesendet wurde:

• Wenn der Pfad mit /app1 beginnt, leitet der native OCI-Ingress-Controller die Anforderung an einen Backend-Service namens ServiceA auf Port 80 weiter.
• Wenn der Pfad mit /app2 beginnt, leitet der native OCI-Ingress-Controller die Anforderung an einen Backend-Service namens ServiceB auf Port 443 weiter.

Da die Regel keinen Host angibt, gilt die Regel für den gesamten eingehenden Datenverkehr.

kind: Ingress
...
spec:
  rules:
    - http:
      paths:
        - pathType: Prefix
          path: /app1
          backend:
            serviceName: ServiceA
            servicePort: 80
        - pathType: Prefix
          path: /app2
          backend:
            serviceName: ServiceB
            servicePort: 443

Anforderungen basierend auf Host und Pfad weiterleiten

Sie können den nativen OCI-Ingress-Controller so konfigurieren, dass eine eingehende Anforderung basierend auf dem Domainnamen im Hostheader der Anforderung (dem Host, an den die Anforderung ursprünglich gesendet wurde) und den Elementen im Pfad, an den die ursprüngliche Anforderung gesendet wurde, weitergeleitet wird.

Um eine Anforderung basierend auf Host und Pfad an einen bestimmten Backend-Service und -Port weiterzuleiten, erstellen Sie eine Routingregel im Manifest Ingress. Wenn Host und Pfad mit der Routingregel übereinstimmen, leitet der native OCI-Ingress-Controller die Anforderung an den zugehörigen Backend-Service und -Port weiter.

Beispiel: Sie können die folgende Regel definieren, um Anforderungen, die ursprünglich an http://foo.bar.com/app1 gesendet wurden, an einen Backend-Service namens foo auf Port 80 weiterzuleiten:

kind: Ingress
...
spec:
  rules:
  - host: "foo.bar.com"
    http:
      paths:
        - pathType: Prefix
          path: /app1
          backend:
            serviceName: foo
            servicePort: 80

Anforderungen an ein Standard-Backend weiterleiten

Sie können den nativen OCI-Ingress-Controller so konfigurieren, dass eingehende Anforderungen an ein Standard-Backend weitergeleitet werden. Sie können ein Standard-Backend konfigurieren, um Anforderungen zu verarbeiten, die mit keinen Routingregeln übereinstimmen.

Beispiel: Sie können die folgende defaultBackend definieren, um Anforderungen, die nicht mit anderen Regeln im Manifest Ingress übereinstimmen, an einen Backend-Service mit dem Namen ServiceC auf Port 8080 weiterzuleiten.

Wenn Sie keine anderen Regeln in einem Ingress-Manifest angeben, müssen Sie eine defaultBackend angeben.

kind: Ingress
...
spec:
  rules:
    - http:
      paths:
        - pathType: Prefix
          path: /app1
          backend:
            serviceName: ServiceA
            servicePort: 80
        - pathType: Prefix
          path: /app2
          backend:
            serviceName: ServiceB
            servicePort: 443
  defaultBackend:
    service:
      name: ServiceC
      port:
        number: 8080

Allgemeines Verhalten mit Anmerkungen anpassen

Sie können Annotationen zu den Ressourcenmanifesten IngressClass oder Ingress hinzufügen, um das allgemeine Verhalten des nativen Ingress-Controllers von OCI anzupassen.

Health-Check-Verhalten mit Annotationen anpassen

Sie können dem Ressourcenmanifest Ingress Annotationen hinzufügen, um die Health Checks anzupassen, die vom vom nativen OCI-Ingress-Controller erstellten Load Balancer ausgeführt werden. Weitere Informationen zu Load Balancer Health Checks finden Sie unter Health Checks für Load Balancer.

Option 1: OCI Native Ingress Controller ruft das Zertifikat vom Certificates-Service mit einem Kubernetes-Secret ab

So konfigurieren Sie den nativen Ingress-Controller von OCI, um ein Zertifikat vom OCI Certificates-Service abzurufen:

1. Rufen Sie ein TLS-Public- und Private-Key-Paar sowie ein Zertifikat ab.

   In Produktionsumgebungen erhalten Sie ein TLS-Zertifikat von der ausgewählten Certificate Authority, indem Sie eine Zertifikatssignieranforderung weiterleiten. Während des Zertifikatsanforderungsprozesses werden ein Public Key und ein entsprechender Private Key generiert.

   In Entwicklungs- und Testumgebungen können Sie ein selbstsigniertes Zertifikat erstellen und mit einem Tool wie OpenSSL selbst einen Private Key generieren. Beispiel (mit OpenSSL 3.0 oder höher):

   1. Generieren Sie ein Public/Private-Key-Paar, indem Sie die folgenden Befehle eingeben:

      openssl genrsa -out rootCA.key 4096

      openssl req -x509 -addext basicConstraints=critical,CA:TRUE -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.crt -subj /CN=RootCA

   2. Generieren Sie ein Zertifikat, indem Sie die folgenden Befehle eingeben:

      openssl genrsa -out server.key 4096

      openssl req -new -sha256 -key server.key -subj /C=US/ST=CA/O=MyOrg,Inc./CN=my.example.com -out server.csr

      openssl x509 -req -in server.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out server.crt -days 500 -sha256

   In diesem Beispiel:

   • rootCA.key enthält das Schlüsselpaar für die Root-CA.
   • rootCA.crt enthält das Root-CA-Zertifikat.
   • server.key enthält das Schlüsselpaar zum Generieren des Serverzertifikats.
   • server.csr enthält die Zertifikatssignieranforderung für das Serverzertifikat.
   • server.crt enthält das generierte Serverzertifikat.
2. Erstellen Sie eine Kubernetes-Secret-Ressource auf eine der folgenden Arten:

   • Geben Sie mit dem Befehl kubectl create secret generic Folgendes ein:

     kubectl create secret generic <k8s-secret-name> --type=kubernetes.io/tls --from-file=ca.crt=<path-and-filename>.crt --from-file=tls.crt=<path-and-filename>.crt --from-file=tls.key=<path-and-filename>.key

     Hierbei gilt:

     • <k8s-secret-name> ist der Name Ihrer Wahl für das Kubernetes-Secret
     • --from-file=ca.crt=<path-and-filename>.crt gibt den Pfad zu der Datei an, die das Root-CA-Zertifikat enthält. Beispiel: --from-file=ca.crt=rootCA.crt
     • --from-file=tls.crt=<path-and-filename>.crt gibt den Pfad zu der Datei an, die das generierte Serverzertifikat enthält. Beispiel: --from-file=tls.crt=server.crt
     • --from-file=tls.key=<path-and-filename>.key gibt den Pfad zu der Datei an, die den generierten Private Key enthält. Beispiel: --from-file=tls.key=server.key

     Beispiel:

     kubectl create secret generic example-tls-secret --type=kubernetes.io/tls --from-file=ca.crt=rootCA.crt --from-file=tls.crt=server.crt --from-file=tls.key=server.key

   • Verwenden Sie eine Ressourcenmanifestdatei Secret:

     1. Definieren Sie das Kubernetes-Secret in einer .yaml-Datei im folgenden Format:

        apiVersion: v1
        kind: Secret
        metadata:
          name: <k8s-secret-name>
        type: kubernetes.io/tls
        data:
          ca.crt: <base64-encoded-certificate-chain>
          tls.crt: <base64-encoded-server-certificate>
          tls.key: <base64-encoded-private-key>

        Hierbei gilt:

        • name: <k8s-secret-name> ist der Name Ihrer Wahl für die Kubernetes-Secret-Ressource.
        • ca.crt: <base64-encoded-certificate-chain> ist der Inhalt der Datei (oder Dateien) mit Zwischenzertifikaten, die eine Zertifikatskette vom Leaf-Zertifikat zurück zur Certificate Authority bilden. Beachten Sie, dass Sie ca.cert weglassen können, vorausgesetzt, Sie nehmen die gesamte Zertifikatskette als Wert von tls.cert auf (in diesem Fall starten Sie die Zertifikatskette mit dem Inhalt der Datei, die das generierte Serverzertifikat enthält, gefolgt von den restlichen Zertifikaten).
        • tls.crt: <base64-encoded-server-certificate> ist der Inhalt der Datei, die das generierte Serverzertifikat enthält.
        • tls.key: <base64-encoded-private-key> ist der Inhalt der Datei, die den generierten Private Key enthält.

        Beispiel:

        apiVersion: v1
        kind: Secret
        metadata:
          name: example-tls-secret
        type: kubernetes.io/tls
        data:
          ca.crt : MIIFGERTegcDFRTuSDGfghREdE______Jre
          tls.crt: MIIC2DCCAcCgAwIBAgIBATANBg______kqh
          tls.key: MIIEpgIBAAKCAQEA7yn3bRHQ5F______HMQ

     2. Erstellen Sie die Secret-Ressource, indem Sie kubectl create -f <filename>.yaml eingeben

3. Fügen Sie das Kubernetes-Secret zu einem Ingress-Ressourcenmanifest hinzu:
   1. Definieren Sie eine neue Ingress-Ressource in einer YAML-Datei. Siehe Ingress-Ressource erstellen.
   2. Fügen Sie im Abschnitt spec: des Manifests ein tls:-Element hinzu, das sowohl den Host, der HTTPS-Traffic empfangen soll, als auch den Namen des Kubernetes-Secrets im folgenden Format angibt:

      kind: Ingress
      ...
      spec:
        tls:
        - hosts:
            - <host-name>
          secretName: <k8s-secret-name>

      Beispiel:

      kind: Ingress
      ...
      spec:
        tls:
        - hosts:
            - my.example.com
          secretName: example-tls-secret

   3. Fügen Sie im Abschnitt rules: des Manifests eine Regel für den Host hinzu, der HTTPS-Datenverkehr empfangen soll, und geben Sie 443 als Port an, auf dem HTTPS-Datenverkehr abgehört werden soll.

      Beispiel:

      apiVersion: networking.k8s.io/v1
      kind: Ingress
      metadata:
        name: acme-tls-secret-ingress
      spec:
        tls:
        - hosts:
            - my.example.com
          secretName: example-tls-secret
        rules:
        - host: "my.example.com"
          http:
            paths:
            - pathType: Prefix
              path: "/TLSPath"
              backend:
                service:
                  name: tls-test
                  port:
                    number: 443

   4. Erstellen Sie die Ressource, indem Sie kubectl create -f <filename>.yaml eingeben.

Wenn Sie die Ingress-Ressource erstellen, verwendet der native Ingress-Controller von OCI das Kubernetes-Secret, um ein Zertifikat des Typs Importiert und ein CA-Bundle (Certificate Authority-Bundle) vom OCI Certificates-Service abzurufen. Der native OCI-Ingress-Controller verknüpft das Zertifikat mit dem Listener und das CA-Bundle mit dem Backend-Set.

Wenn der Listener, der auf Port 443 horcht, eine HTTPS-Anforderung an den angegebenen Host empfängt, verwendet der Listener das Zertifikat für die TLS-Beendigung. Der Listener leitet die Anforderung dann mit der Routingregel an das Backend-Set weiter. Das Backend-Set erstellt eine neue TLS-Verbindung mit den im Cluster ausgeführten Backends (mit dem CA-Bundle als Trust Authority für die neue Verbindung).

Option 2: Sie erhalten das Zertifikat vom Certificates-Service

So konfigurieren Sie den nativen Ingress-Controller von OCI so, dass er ein Zertifikat verwendet, das Sie vom OCI Certificates-Service erhalten haben:

1. Erstellen Sie ein Zertifikat im OCI Certificates-Service auf eine der folgenden Arten:
   • durch Importieren eines Zertifikats, das von einer Drittanbieter-CA ausgestellt wurde (das Zertifikat hat den Typ Importiert)
   • indem Sie das Zertifikat intern von einer CA des Certificates-Service ausstellen (das Zertifikat hat den Typ Von interner CA ausgestellt)

   Erstellen Sie kein Zertifikat für die externe Verwaltung (vom Typ Von interner CA ausgegeben, extern verwaltet). Weitere Informationen finden Sie unter Zertifikat erstellen.

2. Notieren Sie sich die OCID des Zertifikats.
3. Fügen Sie die OCID des Zertifikats zu einem Ingress-Ressourcenmanifest hinzu:
   1. Definieren Sie eine neue Ingress-Ressource in einer .yaml-Datei. Siehe Ingress-Ressource erstellen.
   2. Fügen Sie im Abschnitt metadata: ein annotations:-Element hinzu, das die OCID des Zertifikats angibt, das Sie im OCI Certificates-Service erstellt haben, im folgenden Format:

      kind: Ingress
      metadata:
        name: <i-name>
        annotations:
          oci-native-ingress.oraclecloud.com/certificate-ocid: <certificate-ocid>
      spec:
      ...

      Hierbei gilt:

      • name: <i-name> ist Ihr Name für die Ingress-Ressource.
      • oci-native-ingress.oraclecloud.com/certificate-ocid: <certificate-ocid> ist die OCID des Zertifikats, das Sie im OCI Certificates-Service erstellt haben.

      Beispiel:

      kind: Ingress
      metadata:
        name: acme-tls-certificate-ingress
        annotations:
          oci-native-ingress.oraclecloud.com/certificate-ocid: ocid1.certificate.oc1.iad.amaaaaaa______gabc
      spec:
      ...

   3. Fügen Sie im Abschnitt rules: des Ressourcenmanifests Ingress eine Regel für den Host hinzu, der HTTPS-Traffic empfangen soll, und geben Sie 443 als Port an, auf dem HTTPS-Traffic abgehört werden soll.

      Beispiel:

      apiVersion: networking.k8s.io/v1
      kind: Ingress
      metadata:
        name: acme-tls-certificate-ingress
        annotations:
          oci-native-ingress.oraclecloud.com/certificate-ocid: ocid1.certificate.oc1.iad.amaaaaaa______gabc
      spec:
        rules:
        - host: "my.example.com"
          http:
            paths:
            - pathType: Prefix
              path: "/TLSPath"
              backend:
                service:
                  name: tls-test
                  port:
                    number: 443

   4. Erstellen Sie die Ressource, indem Sie kubectl create -f <filename>.yaml eingeben.

Was beim Erstellen der Ingress-Ressource geschieht, hängt davon ab, wie Sie das Zertifikat im OCI Certificates-Service erstellt haben:

• Wenn Sie das Zertifikat durch Importieren eines Zertifikats erstellt haben, das von einer Drittanbieter-CA ausgestellt wurde, hat das Zertifikat den Typ Importiert. Der native OCI-Ingress-Controller verknüpft das Zertifikat mit dem Listener, erstellt ein CA-Bundle aus der Zertifikatskette und verknüpft das CA-Bundle mit dem Backend-Set. Beachten Sie, dass Sie Zertifikate des Typs Importiert nicht so konfigurieren können, dass sie automatisch rotiert werden.
• Wenn Sie das Zertifikat erstellt haben, indem Sie das Zertifikat intern von einer CA des Certificates-Service ausstellen, hat das Zertifikat den Typ Von interner CA ausgestellt. Der native OCI-Ingress-Controller verknüpft das Zertifikat mit dem Listener, ruft die OCID der CA ab und verknüpft diese OCID mit dem Backend-Set. Beachten Sie, dass Sie Zertifikate des Typs Von interner CA ausgegeben so konfigurieren können, dass sie automatisch rotiert werden.

Wenn der Listener, der auf Port 443 horcht, eine HTTPS-Anforderung an den angegebenen Host empfängt, verwendet der Listener das Zertifikat für die TLS-Beendigung. Der Listener leitet die Anforderung dann mit der Routingregel an das Backend-Set weiter. Das Backend-Set erstellt eine neue TLS-Verbindung mit den im Cluster ausgeführten Backends (mit dem CA-Bundle oder der mit seiner OCID identifizierten CA als Vertrauensstelle für die neue Verbindung).

Definierte Tags auf den Load Balancer anwenden

Definierte Tags werden von einem Tagadministrator eingerichtet und verwaltet. Ein definiertes Tag besteht aus einem Tag-Namespace, einem Schlüssel und einem Wert. Vor dem Anwenden eines definierten Tags auf eine Ressource müssen Sie in einem Mandanten den Tag-Namespace und die Tagschlüsseldefinition einrichten.

Um anzugeben, dass der native OCI-Ingress-Controller definierte Tags auf den Load Balancer anwenden soll, verwenden Sie die Annotation oci-native-ingress.oraclecloud.com/defined-tags im Manifest IngressClass im folgenden Format:

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: <ic-name>
  annotations:
    oci-native-ingress.oraclecloud.com/defined-tags: '{"<tag-namespace>": {"<tag-key>": "<tag-value>"}}'
spec:
  ...

Hierbei gilt:

• <tag-namespace> ist der Tag-Namespace, zu dem das Tag gehört.
• <tag-key> ist der Name eines definierten Tags, das auf den Load Balancer angewendet werden soll.
• <tag-value> ist entweder ein Wert für das Tag aus einer vordefinierten Werteliste oder ein neuer Wert oder leer (je nachdem, wie das definierte Tag eingerichtet wurde).

Der Wert der oci-native-ingress.oraclecloud.com/defined-tags-Annotation ist eine JSON-Zeichenfolge, mit der Sie mehrere Tag-Namespaces, Tagschlüssel und Tagwerte im JSON-Format angeben können.

Beispiel:

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: my-ingress-class
  annotations:
    oci-native-ingress.oraclecloud.com/defined-tags: '{"Operations": {"CostCenter": "42", "Department": "001"}, "Sales": {"Region": "US"}}'
spec:
  ...

Wenn Sie eines der Tags in der oci-native-ingress.oraclecloud.com/defined-tags-Annotation des Manifests IngressClass ändern, wird der native OCI-Ingress-Controller alle in der Annotation angegebenen definierten Tags erneut auf den Load Balancer anwenden. Wenn ein definiertes Tag jedoch eine Tagvariable enthält, wendet der native OCI-Ingress-Controller das definierte Tag nur dann erneut auf den Load Balancer an, wenn das Tag noch nicht vorhanden ist.

Damit der native Ingress-Controller von OCI definierte Tags auf einen Load Balancer anwenden kann, muss eine geeignete IAM-Policy vorhanden sein, damit der native Ingress-Controller von OCI den entsprechenden Tag-Namespace verwenden kann. Weitere Informationen finden Sie unter:

• Berechtigungen für OCI Native Ingress Controller als Standalone-Programm erteilen
• Berechtigungen für das OCI Native Ingress Controller-Cluster-Add-on erteilen

Freiformtags auf den Load Balancer anwenden

Freiformtags werden nicht von einem Tagadministrator verwaltet. Ein Freiformtag besteht aus einem Schlüssel und einem Wert. Im Gegensatz zu definierten Tags gehören Freiformtags nicht zu einem Tag-Namespace.

Um anzugeben, dass der native OCI-Ingress-Controller Freiformtags auf den Load Balancer anwenden soll, verwenden Sie die oci-native-ingress.oraclecloud.com/freeform-tags-Annotation im Manifest IngressClass im folgenden Format:

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: <ic-name>
  annotations:
    oci-native-ingress.oraclecloud.com/freeform-tags: '{"<tag-key>": "<tag-value>"}'
spec:
  ...

Hierbei gilt:

• <tag-key> ist ein Name für das Freiformtag, das auf den Load Balancer angewendet werden soll.
• <tag-value> ist ein Wert für das Freiformtag, das auf den Load Balancer angewendet werden soll.

Der Wert der oci-native-ingress.oraclecloud.com/freeform-tags-Annotation ist eine JSON-Zeichenfolge, mit der Sie mehrere Tagschlüssel und Tagwerte im JSON-Format angeben können.

Beispiel:

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: my-ingress-class
  annotations:
    oci-native-ingress.oraclecloud.com/freeform-tags: '{"Project": "Red", "Version": "Alpha"}'
spec:
  ...

Wenn Sie eines der Tags in der oci-native-ingress.oraclecloud.com/freeform-tags-Annotation des Manifests IngressClass ändern, wird der native OCI-Ingress-Controller alle in der Annotation angegebenen Freiformtags erneut auf den Load Balancer anwenden.

Tagstandardwerte auf den Load Balancer anwenden

Tagstandardwerte werden für ein bestimmtes Compartment eingerichtet. Tagstandardwerte sind Compartment-spezifisch. Tagstandards geben definierte Tags an, die automatisch auf alle Ressourcen angewendet werden, die zum Zeitpunkt der Erstellung in einem bestimmten Compartment erstellt wurden.

Wenn Sie den nativen OCI-Ingress-Controller der Version 1.4.0 (oder höher) verwenden, werden Tagstandardwerte automatisch auf Load Balancer angewendet, die der native OCI-Ingress-Controller erstellt. Anschließend behält der native Ingress-Controller von OCI einen Tagstandard bei, der auf einen Load Balancer angewendet wird, sofern eine der folgenden Bedingungen nicht erfüllt ist:

• Sie entfernen manuell einen Tagstandardwert, der automatisch auf einen Load Balancer angewendet wurde.
• Sie geben einen Tagstandardwert als definiertes Tag mit der oci-native-ingress.oraclecloud.com/defined-tags-Annotation an (in diesem Fall behandelt der native Ingress-Controller von OCI den Tagstandardwert wie jedes andere definierte Tag).

Beachten Sie, dass Tagstandardwerte mit vom Benutzer angewendeten Werten nicht unterstützt werden. Wenn ein Tagstandardwert mit einem vom Benutzer angewendeten Wert für ein Compartment eingerichtet wurde, in dem der native OCI-Ingress-Controller einen Load Balancer erstellen oder verwalten soll, müssen Sie mit der oci-native-ingress.oraclecloud.com/defined-tags-Annotation den Tagstandard als definiertes Tag angeben.

Für Load Balancer, die mit einer OCI-nativen Ingress-Controllerversion vor Version 1.4.0 erstellt wurden, oder wenn Sie mit der oci-native-ingress.oraclecloud.com/id-Annotation angeben, dass der OCI-native Ingress-Controller einen vorhandenen Load Balancer verwalten soll, beachten Sie, dass Tagstandardwerte nicht unterstützt werden. Um einen Tagstandardwert anzuwenden oder beizubehalten, verwenden Sie in beiden Fällen die Annotation oci-native-ingress.oraclecloud.com/defined-tags, um den Tagstandardwert stattdessen als definiertes Tag anzugeben.