Erweiterte Proxy-Limits

Übersicht

Neue Apigee-Hybridorganisationen können so bereitgestellt werden, dass mehr als 50 Proxys pro Umgebung bereitgestellt werden können. Diese Funktion ist auch für Apigee X verfügbar.

  • Die maximale Anzahl der bereitgestellten API-Proxys und freigegebenen Abläufe pro Organisation beträgt 6.000.
  • Die maximale Anzahl von Proxy-Bereitstellungseinheiten pro Apigee-Instanz beträgt 6.000.
  • Die maximale Anzahl von API-Basispfaden pro Apigee-Organisation beträgt 3.000.

Wenn in einer Umgebung mehr als 50 Proxys bereitgestellt werden, partitioniert Apigee die Umgebung automatisch in mehrere verschiedene Replikatensätze, die jeweils eine Teilmenge der in der Umgebung bereitgestellten Proxys enthalten. Diese Replika-Subsets verhalten sich wie eine einzelne Umgebung, da sie eine Reihe von Proxys und anderen Umgebungsressourcen laden und ausführen. Für den Nutzer ist das transparent und Sie können die Umgebung wie eine einzelne Umgebung verwenden.

Wird bereitgestellt

So stellen Sie eine neue Organisation mit der erweiterten Anzahl von Proxys pro Umgebung bereit:

  1. Geben Sie Ihre Projekt-ID und den Namen Ihrer Organisation an Ihren Apigee-Kundenbetreuer weiter, damit er das erweiterte Proxy-Limit einrichten kann.
  2. Folgen Sie der Installationsanleitung für Apigee Hybrid, um die Hybrid-Organisation bereitzustellen. Fügen Sie in der Überschreibungsdatei das Attribut enhanceProxyLimits der obersten Ebene hinzu:
    enhanceProxyLimits: true
    

    Wenden Sie Änderungen auf enhanceProxyLimits an, indem Sie das Diagramm apigee-org und das Diagramm apigee-virtualhost für jede Umgebungsgruppe aktualisieren.

  3. Erstellen und bereitstellen Sie einen Proxy.
  4. Prüfen Sie, ob die erweiterten Proxylimits aktiviert sind:
    1. Rufen Sie den Namen der ConfigMap für Ihren Apigee-Namespace ab:
      kubectl get configmap -n APIGEE_NAMESPACE

      Die Ausgabe sollte in etwa so aussehen:

      NAME                                                             DATA   AGE
      ...
      apigee-synchronizer-hybr-example-env-dggroupconfi-bc7726a       3      12m
      ...
    2. Prüfen Sie die benannte ConfigMap:
      kubectl get configmap -n APIGEE_NAMESPACE CONFIGMAP_NAME -o yaml

      Dabei ist CONFIGMAP_NAME der Name der ConfigMap aus dem vorherigen Schritt.

      Die Ausgabe sollte in etwa so aussehen:

      kubectl get configmap -n apigee apigee-synchronizer-hybr-example-env-dggroupconfi-bc7726a -o yaml
      apiVersion: v1
      data:
      contract.revid: "2"
      contract.uid: 4a792429-20fb-4b29-bed3-3f8ce7b3353e
      deploymentGroups: auto-2ecde5ae-04
      kind: ConfigMap
      metadata:
      creationTimestamp: "2024-05-15T20:04:26Z"
      labels:
          apigee.cloud.google.com/platform: apigee
      name: apigee-synchronizer-hybr-test-env-dggroupconfi-bc7726a
      namespace: apigee
      ownerReferences:
      - apiVersion: apigee.cloud.google.com/v1alpha2
          blockOwnerDeletion: true
          controller: true
          kind: ApigeeEnvironment
          name: hybrid-dev--test-env-4f37f70
          uid: 696e84ec-5c54-4858-a2e0-e36db5ff3506
      resourceVersion: "2520100"
      uid: b297bd33-300a-48cf-bf85-6c7cd0ff288f
      
  5. Prüfen Sie, ob Laufzeit-Pods vorhanden sind, die den Teilstring auto enthalten:
    kubectl get pods -n APIGEE_NAMESPACE | grep auto

    Die Ausgabe sollte in etwa so aussehen:

    kubectl get pods -n apigee | grep auto
    apigee-runtime-hybr-test-env-auto-2ecde5a-bca5298-4gsrw   1/1     Running     0                98m

Beschränkungen

Apigee bietet erweiterte Proxylimits nur für neu erstellte Organisationen. Die Umstellung bestehender Organisationen auf erweiterte Proxylimits wird unterstützt.

Sicherungen einer Organisation, die ohne erweiterte Proxylimits erstellt wurde, können nicht in einer Organisation wiederhergestellt werden, für die die Funktion aktiviert wurde.

Bekannte Probleme

  • Proxy-Verkettung:
    • Die Proxy-Kette mit mTLS wird nicht unterstützt. Siehe Bekanntes Problem 392135466.
    • Wenn Sie mehrere virtuelle Hosts haben, kann die Erstellung des Helm-Releases aufgrund von in Konflikt stehenden ApigeeRoute-Namen fehlschlagen. Als Workaround können Sie die folgenden Befehle für jeden virtuellen Host ausführen, wenn Sie das apigee-virtualhost-Diagramm für jede Umgebungsgruppe installieren oder aktualisieren:
      kubectl annotate ar apigee-ingressgateway-internal-chaining-PROJECT_ID_SUFFIX -n APIGEE_NAMESPACE meta.helm.sh/release-name=NEW_ENV_GROUP_NAME --overwrite
      kubectl annotate cert apigee-ingressgateway-internal-chaining-PROJECT_ID_SUFFIX -n APIGEE_NAMESPACE meta.helm.sh/release-name=NEW_ENV_GROUP_NAME --overwrite

      Dabei gilt:

      • PROJECT_ID_SUFFIX ist ein eindeutiges Suffix für die interne Verknüpfung Ihres Projekts in Kubernetes. Sie können dieses Suffix mit dem folgenden Befehl ermitteln:
        kubectl get svc -n apigee -l app=apigee-ingressgateway | grep internal-chaining

        Ihre Ausgabe sieht etwa so aus:

        kubectl get svc -n apigee -l app=apigee-ingressgateway | grep internal-chaining
        apigee-ingressgateway-internal-chaining-my-project--1234567    ClusterIP  34.118.226.140  <none>    15021/TCP,443/TCP    5d6h

        In der Beispielausgabe ist my-project--1234567 der PROJECT_ID_SUFFIX.

      • APIGEE_NAMESPACE ist Ihr Apigee-Namespace.
      • NEW_ENV_GROUP_NAME ist der Name der zusätzlichen Umgebungsgruppe. Aktualisieren Sie diesen Wert für jeden virtuellen Host.

      Siehe Bekanntes Problem 384937220.

Fehlerbehebung

Symptom Lösung
In der Debug-Sitzung werden keine Anfragen angezeigt. Führen Sie die Schritte unter Autorisierungsablauf festlegen aus, um die Berechtigungen für das Apigee-Laufzeitdienstkonto zu prüfen.