Oracle Cloud Infrastructure - Dokumentation

Voraussetzungen für das Deployment des OCI Native Ingress Controller als Standalone-Programm

Erfahren Sie, was Sie tun müssen, bevor Sie den nativen OCI-Ingress-Controller als Standalone-Programm bereitstellen können, um eingehenden Traffic zu laden und an Servicepods weiterzuleiten, die auf Worker-Knoten in einem Kubernetes-Cluster ausgeführt werden.

Vor dem Deployment des nativen OCI-Ingress-Controllers als Standalone-Programm:

Instanz-Principal, Benutzer-Principal oder Workload Identity Principal einrichten, um den Zugriff auf OCI-Services und -Ressourcen zu ermöglichen

Um einen Load Balancer zu erstellen und eingehenden Traffic weiterzuleiten, führt der native OCI-Ingress-Controller, unabhängig davon, ob er als Standalone-Programm oder als Cluster-Add-on installiert ist, Aktionen für andere Oracle Cloud Infrastructure-Serviceressourcen aus (einschließlich Load-Balancer-Service und Certificates-Service). Um diese Aktionen für OCI-Serviceressourcen auszuführen, verwendet der native OCI-Ingress-Controller-Pod die Zugangsdaten eines autorisierten Akteurs (oder Principals). Sie können derzeit die folgenden Principal-Typen einrichten, damit der native OCI-Ingress-Controller Aktionen mit OCI-Serviceressourcen ausführen kann:

Hinweis:

  • Die Verwendung von Instanz-Principals, damit der native OCI-Ingress-Controller auf OCI-Services und -Ressourcen zugreifen kann, wird in Clustern mit virtuellen Knoten nicht unterstützt.
  • Die Verwendung von Workload-Identitäts-Principals, damit der native OCI-Ingress-Controller auf OCI-Services und -Ressourcen zugreifen kann, wird mit erweiterten Clustern unterstützt, jedoch nicht mit einfachen Clustern.

Zugriff auf OCI-Services und -Ressourcen mit Instanz-Principals aktivieren

Sie können einen Instanz-Principal einrichten, damit der native OCI-Ingress-Controller Aktionen mit OCI-Serviceressourcen ausführen kann. Beachten Sie, dass Sie Instanz-Principals nur mit verwalteten Knoten verwenden können.

So richten Sie einen Instanz-Principal ein:

  1. Erstellen Sie eine neue dynamische Gruppe mit den Compute-Instanzen, die Worker-Knoten des Clusters hosten:
    1. Öffnen Sie das Navigationsmenü , und wählen Sie Identität und Sicherheit aus. Wählen Sie unter Identität die Option Domains aus. Wählen Sie unter Identitätsdomain die Option Dynamische Gruppen aus.

    2. Wählen Sie das Compartment aus, zu dem die Compute-Instanzen gehören.

    3. Befolgen Sie die Anweisungen unter So erstellen Sie eine dynamische Gruppe, und geben Sie der dynamischen Gruppe einen Namen (z.B. acme-oke-native-ingress-controller-dyn-grp).

    4. Geben Sie eine Regel mit den Compute-Instanzen im Compartment im folgenden Format ein:
      ALL {instance.compartment.id = '<compartment-ocid>'}

      wobei <compartment-ocid> die OCID des Compartments ist, in dem Clusterknotenpools erstellt werden.

      Beispiel:

      ALL {instance.compartment.id = 'ocid1.compartment.oc1..aaaaaaaa23______smwa'}
    5. Klicken Sie auf Dynamische Gruppe erstellen.

Bevor Sie den nativen OCI-Ingress-Controller bereitstellen, gehen Sie wie folgt vor:

Mit Benutzer-Principals den Zugriff auf OCI-Services und -Ressourcen aktivieren

Sie können einen Benutzer-Principal einrichten, damit der native OCI-Ingress-Controller Aktionen mit OCI-Serviceressourcen ausführen kann.

So richten Sie einen Benutzer-Principal ein:

  1. Wenn noch kein geeigneter Benutzer vorhanden ist, erstellen Sie einen Benutzer in IAM (siehe So erstellen Sie einen Benutzer).
  2. Wenn noch keine geeignete Gruppe vorhanden ist, erstellen Sie eine Gruppe in IAM (siehe So erstellen Sie eine Gruppe).
  3. Fügen Sie den Benutzer der Gruppe hinzu (siehe So fügen Sie einer Gruppe einen Benutzer hinzu).

  4. Rufen Sie diese Elemente ab:

  5. Laden Sie den Public Key aus dem Schlüsselpaar in der Konsole hoch. Siehe So laden Sie den Public Key hoch.
  6. Erstellen Sie eine Konfigurationsdatei als .yaml-Datei mit Zugangsdateninformationen im folgenden Format:
    auth:
  region: <region-identifier>
  passphrase: <passphrase>
  user: <user-ocid>
  fingerprint: <fingerprint>
  tenancy: <tenancy-ocid>
    Hierbei gilt:
    • region: <region-identifier> ist die Region, in der sich das Cluster befindet. Beispiel: us-ashburn-1
    • passphrase: <passphrase> gibt die Passphrase für den Schlüssel an, wenn er verschlüsselt ist.
    • user: <user-ocid> ist die OCID des Benutzers, den der native Ingress-Controller von OCI verwenden soll.
    • fingerprint: <fingerprint> ist der Fingerprint des Public Keys.
    • tenancy: <tenancy-ocid> ist die OCID des Mandanten, der das Cluster enthält.

    Beispiel:

    auth:
  region: us-ashburn-1
  passphrase: examplepass
  user: ocid1.user.oc1..aaaaaaaa_example
  fingerprint: 67:d9:74:4b:21:example
  tenancy: ocid1.tenancy.oc1..aaaaaaaa_example
  7. Erstellen Sie eine Kubernetes-Secret-Ressource im Cluster, indem Sie Folgendes eingeben:
    
kubectl create secret generic <secret-name> \
--from-file=config=<config-file>.yaml \
--from-file=private-key=<private-key-file-path>.pem \
--namespace <namespace>
    Hierbei gilt:
    • <secret-name> gibt den Namen des zu erstellenden Secrets an. Beispiel: oci-config
    • --from-file=config=<config-file>.yaml gibt den Namen und Pfad der .yaml-Datei mit den zuvor erstellten Zugangsdateninformationen an. Beispiel: user-auth-config.yaml
    • --from-file=private-key=./oci/oci_api_key.pem gibt den Namen und Pfad der heruntergeladenen Private-Key-Datei an. Beispiel: ./oci/oci_api_key.pem
    • --namespace <namespace> gibt den Namespace an, der den nativen OCI-Ingress-Controller enthält.

    Beispiel:

    
kubectl create secret generic oci-config \
--from-file=config=user-auth-config.yaml \
--from-file=private-key=./oci/oci_api_key.pem \
--namespace acme-namespace

Bevor Sie den nativen OCI-Ingress-Controller bereitstellen, gehen Sie wie folgt vor:

Workload Identity Principals verwenden, um Zugriff auf OCI-Services und -Ressourcen zu ermöglichen

Sie können einen Workload-Identitäts-Principal einrichten, damit der native OCI-Ingress-Controller Aktionen mit OCI-Serviceressourcen ausführen kann. Beachten Sie, dass Sie nur Workload-Identity Principals mit erweiterten Clustern verwenden können.

So richten Sie einen Workload Identity Principal ein:

  1. Rufen Sie die OCID des Clusters ab (z.B. mit der Registerkarte Clusterdetails in der Konsole).

  1. Bevor Sie den nativen OCI-Ingress-Controller bereitstellen, gehen Sie wie folgt vor:

OCI Native Ingress Controller Berechtigungen als Standalone-Programm erteilen

Der native OCI-Ingress-Controller erfordert Berechtigungen für den Zugriff auf Ressourcen, die von anderen Oracle Cloud Infrastructure-Services (wie dem Load-Balancer-Service und dem Certificates-Service) erstellt wurden. Sie erteilen dieselben Berechtigungen, unabhängig davon, ob Sie den nativen OCI-Ingress-Controller als eigenständiges Programm oder als Cluster-Add-on installieren. Und die Berechtigungen sind identisch, unabhängig davon, ob Sie einen Instanz-Principal, einen Benutzer-Principal oder einen Workload-Identitäts-Principal für den nativen OCI-Ingress-Controller eingerichtet haben. Die Art und Weise, wie Sie diese Berechtigungen erteilen, hängt jedoch von dem von Ihnen eingerichteten Principal-Typ ab:

Um Berechtigungen für den nativen Ingress-Controller von OCI einzurichten, erstellen Sie eine Policy für die Gruppe (im Fall von Benutzer-Principals), für die dynamische Gruppe (im Fall von Instanz-Principals) oder für die Workload (im Fall von Workload-Identitäts-Principals) mit Policy-Anweisungen für den Zugriff auf OCI-Services und -Ressourcen:

  1. Öffnen Sie das Navigationsmenü , und wählen Sie Identität und Sicherheit aus. Wählen Sie unter Identität die Option Policys aus.
  2. Folgen Sie den Anweisungen unter So erstellen Sie eine Policy, und geben Sie der Policy einen Namen (Beispiel: acme-oke-native-ingress-controller-policy).

  3. Wenn Sie Instanz-Principals oder Benutzer-Principals verwenden, geben Sie Policy-Anweisungen ein, um den Zugriff auf die OCI-Services und -Ressourcen zuzulassen, die vom nativen OCI-Ingress-Controller verwendet werden, in folgendem Format:

    Allow <group|dynamic-group> <subject-name> to <verb> <resource> in <location>

    Hierbei gilt:

    • <group|dynamic-group> ist entweder group (im Fall von Benutzer-Principals) oder dynamic-group (im Fall von Instanz-Principals)
    • <subject-name> ist entweder der Name der Gruppe (im Fall von Benutzer-Principals) oder der Name der dynamischen Gruppe (im Fall von Instanz-Principals). Beispiel: acme-oke-nat-ing-cont-dyn-grp. Wenn eine Gruppe oder dynamische Gruppe nicht in der Standardidentitätsdomain enthalten ist, stellen Sie dem Namen der Gruppe oder dynamischen Gruppe den Namen der Identitätsdomain im Format <group|dynamic-group> '<identity-domain-name>'/'<group-name|dynamic-group-name>' voran. Sie können auch eine Gruppe oder dynamische Gruppe mit ihrer OCID im Format group id <group-ocid> oder dynamic-group id <dynamic-group-ocid> angeben.
    • <verb> <resource> ist eine der folgenden Optionen (alle sind in separaten Policy-Anweisungen erforderlich):
      • manage load-balancers
      • use virtual-network-family
      • manage cabundles
      • manage cabundle-associations
      • manage leaf-certificates
      • read leaf-certificate-bundles
      • manage leaf-certificate-versions
      • manage certificate-associations
      • read certificate-authorities
      • manage certificate-authority-associations
      • read certificate-authority-bundles
      • read public-ips
      • manage floating-ips
      • manage waf-family
      • read cluster-family
      • use tag-namespaces (nur erforderlich, wenn der native OCI-Ingress-Controller definierte Tags auf Load Balancer anwenden soll. Informationen hierzu finden Sie unter Definierte Tags auf den Load Balancer anwenden)
    • <location> ist eine der folgenden Optionen:
      • tenancy, wenn der native OCI-Ingress-Controller Zugriff auf Ressourcen im gesamten Mandanten haben soll.
      • compartment <compartment-name>, wenn der native OCI-Ingress-Controller nur Zugriff auf Ressourcen im Compartment mit dem Namen haben soll, den Sie als compartment <compartment-name> angeben.

    Beispiel:

    Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage load-balancers in compartment acme-oke-cluster-compartment

    Die Syntax für die vollständige Liste der Policy-Anweisungen lautet wie folgt:

    Allow <group|dynamic-group> <subject-name> to manage load-balancers in <location>   
Allow <group|dynamic-group> <subject-name> to use virtual-network-family in <location>
Allow <group|dynamic-group> <subject-name> to manage cabundles in <location>
Allow <group|dynamic-group> <subject-name> to manage cabundle-associations in <location>
Allow <group|dynamic-group> <subject-name> to manage leaf-certificates in <location>
Allow <group|dynamic-group> <subject-name> to read leaf-certificate-bundles in <location>
Allow <group|dynamic-group> <subject-name> to manage leaf-certificate-versions in <location>
Allow <group|dynamic-group> <subject-name> to manage certificate-associations in <location>
Allow <group|dynamic-group> <subject-name> to read certificate-authorities in <location>
Allow <group|dynamic-group> <subject-name> to manage certificate-authority-associations in <location>
Allow <group|dynamic-group> <subject-name> to read certificate-authority-bundles in <location>
Allow <group|dynamic-group> <subject-name> to read public-ips in <location>
Allow <group|dynamic-group> <subject-name> to manage floating-ips in <location>
Allow <group|dynamic-group> <subject-name> to manage waf-family in <location>
Allow <group|dynamic-group> <subject-name> to read cluster-family in <location>
Allow <group|dynamic-group> <subject-name> to use tag-namespaces in <location>

    Beispiel für eine vollständige Liste der Policy-Anweisungen:

    Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage load-balancers in compartment acme-oke-cluster-compartment   
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to use virtual-network-family in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage cabundles in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage cabundle-associations in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage leaf-certificates in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read leaf-certificate-bundles in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage leaf-certificate-versions in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage certificate-associations in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read certificate-authorities in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage certificate-authority-associations in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read certificate-authority-bundles in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read public-ips in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage floating-ips in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage waf-family in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read cluster-family in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to use tag-namespaces in compartment acme-oke-cluster-compartment
  4. Wenn Sie Workload-Identitäts-Principals verwenden, geben Sie Policy-Anweisungen ein, um den Zugriff auf die OCI-Services und -Ressourcen zuzulassen, die vom nativen OCI-Ingress-Controller verwendet werden, in folgendem Format:
    Allow any-user to <verb> <resource> in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}

    Hierbei gilt:

    • <verb> <resource> ist eine der folgenden Optionen (alle sind in separaten Policy-Anweisungen erforderlich):
      • manage load-balancers
      • use virtual-network-family
      • manage cabundles
      • manage cabundle-associations
      • manage leaf-certificates
      • read leaf-certificate-bundles
      • manage leaf-certificate-versions
      • manage certificate-associations
      • read certificate-authorities
      • manage certificate-authority-associations
      • read certificate-authority-bundles
      • read public-ips
      • manage floating-ips
      • manage waf-family
      • read cluster-family
      • use tag-namespaces (nur erforderlich, wenn der native OCI-Ingress-Controller definierte Tags auf Load Balancer anwenden soll. Informationen hierzu finden Sie unter Definierte Tags auf den Load Balancer anwenden)
    • <location> ist eine der folgenden Optionen:
      • tenancy, wenn der native OCI-Ingress-Controller Zugriff auf Ressourcen im gesamten Mandanten haben soll.
      • compartment <compartment-name>, wenn der native OCI-Ingress-Controller nur Zugriff auf Ressourcen im Compartment mit dem Namen haben soll, den Sie als compartment <compartment-name> angeben.
    • request.principal.namespace = 'native-ingress-controller-system' ist der Name des Namespace, der während der Installation für den nativen Ingress-Controller von OCI erstellt wurde.
    • request.principal.service_account = 'oci-native-ingress-controller' ist der Name des Serviceaccounts, der während der Installation für den nativen Ingress-Controller von OCI erstellt wurde.
    • <cluster-ocid> ist die OCID des Clusters, die Sie zuvor abgerufen haben.

    Beispiel:

    Allow any-user to manage load-balancers in tenancy where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = 'ocid1.cluster.oc1.iad.aaaaaaaa______ska'}

    Die Syntax für die vollständige Liste der Policy-Anweisungen lautet:

    Allow any-user to manage load-balancers in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to use virtual-network-family in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage cabundles in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage cabundle-associations in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage leaf-certificates in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to read leaf-certificate-bundles in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage leaf-certificate-versions in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage certificate-associations in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to read certificate-authorities in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage certificate-authority-associations in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to read certificate-authority-bundles in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to read public-ips in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage floating-ips in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage waf-family in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to read cluster-family in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to use tag-namespaces in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}

cert-manager wird installiert

Der native OCI-Ingress-Controller, unabhängig davon, ob er als Standalone-Programm oder als Cluster-Add-on installiert ist, verwendet Webhooks, um Podbereitschaftsgates in Podspezifikationen zu injizieren. Um die Sicherheit zu gewährleisten, muss der Webhook-Server im HTTPS-Modus ausgeführt werden, für den ein Paar Zertifikate und Schlüssel erforderlich ist. Der native Ingress-Controller von OCI verwendet Certificate Manager (auch als Cert-Manager bezeichnet), um die Zertifikate und Schlüssel für den Webhook-Server zu generieren und zu verwalten. Daher müssen Sie den Cert-Manager auf dem Cluster installieren, um Pod Readiness-Gates zu verwenden.

Unabhängig davon, ob Sie den nativen OCI-Ingress-Controller als eigenständiges Programm oder als Cluster-Add-on installieren, können Sie cert-manager auf zwei Arten installieren und ausführen:

  • Sie können cert-manager als Open-Source-Produkt installieren und ausführen, indem Sie Folgendes eingeben:

    kubectl apply -f https://github.com/jetstack/cert-manager/releases/latest/download/cert-manager.yaml

  • Sie können cert-manager als Cluster-Add-on installieren und ausführen. Weitere Informationen zur Installation von cert-manager als Cluster-Add-on finden Sie unter Cluster-Add-on installieren.

Weitere Informationen zum cert-Manager finden Sie in der cert-manager.io-Dokumentation.

Helm-CLI installieren, um den OCI Native Ingress Controller als Standalone-Programm zu installieren

Helm ist ein Package Manager für Kubernetes. Helm wird häufig zum Erstellen, Packen, Konfigurieren und Bereitstellen von Kubernetes-Anwendungen verwendet, indem Konfigurationsdateien in einem einzigen wiederverwendbaren Package kombiniert werden, das als Helm-Diagramm bezeichnet wird. Diagramme werden in einem Archivformat verpackt und verteilt, das als Diagrammarchiv bezeichnet wird. Ein Diagramm enthält die erforderlichen Informationen zur Installation einer Gruppe von Kubernetes-Ressourcen in einem Kubernetes-Cluster. Ein Diagramm umfasst:

  • eine chart.yaml-Datei mit einer Beschreibung der Anwendung,
  • eine Datei values.yaml, die Standardwerte für Anwendungsparameter bereitstellt
  • Vorlagen von Dateien, die von der Anwendung verwendet werden
  • andere Abhängigkeiten

Helm verfügt auch über einen Befehlszeilenclient, die Helm-CLI (auch als "helm" bezeichnet, in Kleinbuchstaben)

Um den nativen OCI-Ingress-Controller als Standalone-Programm zu installieren, wird der native OCI-Ingress-Controller als Helm-Diagramm verfügbar gemacht. Bevor Sie das native Ingress-Controllerdiagramm von OCI installieren können, müssen Sie zuerst die Helm-CLI installieren.

Um die Helm-CLI zu installieren, befolgen Sie die Anweisungen in der Helm-Installationsdokumentation, um die entsprechende tar.gz- oder ZIP-Archivdatei herunterzuladen und zu extrahieren.

OCI Native Ingress Controller-Repository klonen und Parameter in values.yaml festlegen

So klonen Sie den nativen OCI-Ingress-Controller und legen Parameter in values.yaml fest, um den nativen OCI-Ingress-Controller als Standalone-Programm zu installieren:

  1. Klonen Sie das native OCI-Ingress-Controller-Repository aus GitHub, indem Sie Folgendes eingeben:
    git clone https://github.com/oracle/oci-native-ingress-controller
  2. Navigieren Sie im lokalen Git-Repository zum Verzeichnis oci-native-ingress-controller, und öffnen Sie die Datei values.yaml in einem Texteditor.
  3. Setzen Sie in der Datei values.yaml den Parameter compartment_id auf die OCID des Compartments, in dem der native OCI-Ingress-Controller den OCI-Load Balancer und das Zertifikat erstellen soll. Beispiel:
    compartment_id: "ocid1.compartment.oc1..aaaaaaaa______ddq"
  4. Setzen Sie in der Datei values.yaml den Parameter subnet_id auf die OCID des Load-Balancer-Subnetzes. Beispiel:
    subnet_id: "ocid1.subnet.oc1.iad.aaaaaaaa______dba"
  5. Legen Sie in der Datei values.yaml den Parameter cluster_id auf die OCID des Clusters fest. Beispiel:
    cluster_id: "ocid1.cluster.oc1.iad.aaaaaaaa______ska"
  6. Geben Sie in der Datei values.yaml wie folgt an, wie der native OCI-Ingress-Controller auf OCI-Services und -Ressourcen zugreifen soll:
  7. (Optional) Wenn Sie aus Verfügbarkeitsgründen mehrere Instanzen des nativen Ingress-Controllers von OCI ausführen möchten, ändern Sie den Wert von replicaCount in der Datei values.yaml. Beispiel:
    replicaCount: 3
    Standardmäßig ist replicaCount auf 1 gesetzt, d.h. eine Instanz des nativen Ingress-Controllers von OCI wird als einzelner Pod ausgeführt. Um die Verfügbarkeit sicherzustellen, können Sie replicaCount erhöhen (in der Regel auf 2 oder 3), um mehrere native Ingress-Controllerinstanzen von OCI als verschiedene Pods auszuführen. Ein Pod ist als Leader nominiert und fungiert als OCI-nativer Ingress-Controller, während die restlichen Pods in einem passiven Status warten. Wenn der Leader anschließend nicht mehr verfügbar ist, wird einer der anderen Pods als Leader nominiert und fungiert als OCI-nativer Ingress-Controller.
  8. Speichern Sie die Änderungen, die Sie in der Datei values.yaml vorgenommen haben, und schließen Sie die Datei.
  9. Wenn der native OCI-Ingress-Controller über einen Workload-Identity Principal auf OCI-Services und -Ressourcen zugreifen soll, müssen Sie zusätzliche Umgebungsvariablen wie folgt festlegen:
    1. Navigieren Sie im lokalen Git-Repository zum Verzeichnis oci-native-ingress-controller/templates, und öffnen Sie die Datei deployment.yaml in einem Texteditor.
    2. Legen Sie in der Datei deployment.yaml die folgenden Umgebungsvariablen wie dargestellt fest: 
        env:
    - name: OCI_RESOURCE_PRINCIPAL_VERSION
      value: "2.2"
    - name: OCI_RESOURCE_PRINCIPAL_REGION
      value: "us-ashburn-1"
    3. Speichern Sie die Änderungen, die Sie in der Datei deployment.yaml vorgenommen haben, und schließen Sie die Datei.