Limiti dei proxy migliorati

Panoramica

Per le nuove organizzazioni ibride Apigee è possibile eseguire il provisioning con la possibilità di eseguire il deployment di più di 50 proxy per ambiente. Questa funzionalità è disponibile anche per Apigee X.

  • Il numero massimo di proxy API e flussi condivisi di cui è stato eseguito il deployment per organizzazione è 6000.
  • Il numero massimo di unità di deployment dei proxy per istanza Apigee è 6000.
  • Il numero massimo di percorsi base dell'API per organizzazione Apigee è 3000.

Quando in un ambiente viene eseguito il deployment di più di 50 proxy, Apigee partiziona automaticamente l'ambiente in diversi set di repliche distinti, ciascuno contenente un sottoinsieme di proxy di cui è stato eseguito il deployment nell'ambiente. Questi sottoinsiemi di repliche sono equivalenti per comportamento a un singolo ambiente per il modo in cui carica ed esegue un insieme di proxy e altre risorse dell'ambiente. L'operazione sarà trasparente per l'utente e potrai continuare a utilizzare l'ambiente come faresti con un singolo ambiente.

Provisioning

Per eseguire il provisioning di una nuova organizzazione con il numero aumentato di proxy per ambiente:

  1. Fornisci il tuo ID progetto e il nome della tua organizzazione al tuo rappresentante Apigee per configurare il limite di proxy avanzato.
  2. Segui le istruzioni di installazione di Apigee hybrid per eseguire il provisioning dell'organizzazione ibrida. Nel file delle sostituzioni, aggiungi la proprietà di primo livello enhanceProxyLimits: 
    enhanceProxyLimits: true

    Applica le modifiche a enhanceProxyLimits aggiornando il grafico apigee-org e il grafico apigee-virtualhost per ogni gruppo di ambienti.

  3. Crea ed esegui il deployment di un proxy.
  4. Verifica che i limiti dei proxy avanzati siano abilitati:
    1. Recupera il nome del file configmap per lo spazio dei nomi Apigee: 
      kubectl get configmap -n APIGEE_NAMESPACE

      Dovresti vedere un output simile al seguente: 

      NAME                                                             DATA   AGE
...
apigee-synchronizer-hybr-example-env-dggroupconfi-bc7726a       3      12m
...
    2. Controlla il configmap denominato: 
      kubectl get configmap -n APIGEE_NAMESPACE CONFIGMAP_NAME -o yaml

      dove CONFIGMAP_NAME è il nome del configmap del passaggio precedente.

      Dovresti vedere un output simile al seguente: 

      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. Controlla l'esistenza di pod di runtime contenenti la sottostringa auto: 
    kubectl get pods -n APIGEE_NAMESPACE | grep auto

    Dovresti vedere un output simile al seguente: 

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

Limitazioni

Apigee offre limiti di proxy avanzati solo per le organizzazioni appena create. È supportata la conversione delle organizzazioni esistenti per l'utilizzo dei limiti dei proxy avanzati.

I backup di un'organizzazione creata senza i limiti dei proxy avanzati abilitati non possono essere ripristinati in un'organizzazione creata con la funzionalità abilitata.

Problemi noti

  • Catena di proxy:
    • La catena di proxy con mTLS non è supportata. Consulta il problema noto 392135466.
    • Quando sono presenti più host virtuali, la creazione della release di Helm potrebbe non riuscire a causa di nomi ApigeeRoute in conflitto. La soluzione alternativa consiste nell'eseguire i seguenti comandi per ogni host virtuale durante l'installazione o l'upgrade del grafico apigee-virtualhost per ogni gruppo di ambienti: 
      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

      dove:

      • PROJECT_ID_SUFFIX è un suffisso univoco per l'accodamento interno del tuo progetto in Kubernetes. Puoi trovare questo suffisso con il seguente comando: 
        kubectl get svc -n apigee -l app=apigee-ingressgateway | grep internal-chaining

        L'output sarà simile al seguente:

        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

        Nell'output di esempio, my-project--1234567 è il PROJECT_ID_SUFFIX.

      • APIGEE_NAMESPACE è lo spazio dei nomi Apigee.
      • NEW_ENV_GROUP_NAME è il nome del gruppo di ambienti aggiuntivo. Aggiorna questo valore per ogni host virtuale.

      Consulta il problema noto 384937220.

Risoluzione dei problemi

Sintomo Risoluzione
La sessione di debug non mostra le richieste. Segui i passaggi descritti in Impostare il flusso di autorizzazione per verificare le autorizzazioni per l'account di servizio di runtime Apigee.