Cette page a été traduite par l'API Cloud Translation.

Amélioration des limites du proxy

Présentation

Les nouvelles organisations Apigee hybrides peuvent être provisionnées pour pouvoir déployer plus de 50 proxys par environnement. Cette fonctionnalité est également disponible pour Apigee X.

Le nombre maximal de proxys d'API déployés et de flux partagés par organisation est de 6 000.
Le nombre maximal d'unités de déploiement de proxy par instance Apigee est de 6 000.
Le nombre maximal de chemins de base d'API par organisation Apigee est de 3 000.

Lorsque plus de 50 proxys sont déployés dans un environnement, Apigee partitionne automatiquement l'environnement en plusieurs ensembles de réplicas distincts, chacun contenant un sous-ensemble de proxys déployés dans l'environnement. Ces sous-ensembles de réplicas se comportent comme un seul environnement en ce qui concerne la façon dont ils chargent et exécutent un ensemble de proxys et d'autres ressources d'environnement. Cette opération sera transparente pour l'utilisateur, et vous pourrez continuer à utiliser l'environnement comme vous le feriez avec un seul environnement.

Provisionnement

Pour provisionner une nouvelle organisation avec le nombre accru de proxys par environnement:

Indiquez votre ID de projet et le nom de votre organisation à votre représentant Apigee pour configurer la limite de proxy améliorée.
Suivez les instructions d'installation d'Apigee hybrid pour provisionner l'organisation hybride. Dans votre fichier de remplacement, ajoutez la propriété de premier niveau enhanceProxyLimits:
```
enhanceProxyLimits: true
```
Appliquez les modifications à enhanceProxyLimits en mettant à jour le graphique apigee-org et le graphique apigee-virtualhost pour chaque groupe d'environnements.

Avertissement:Une fois définie, ne modifiez pas cette valeur.
Créez et déployez un proxy.

Vérifiez que les limites de proxy améliorées sont activées :

Récupérez le nom du ConfigMap de votre espace de noms Apigee:

kubectl get configmap -n APIGEE_NAMESPACE

Vous devriez obtenir un résultat semblable à celui-ci :

NAME                                                             DATA   AGE
...
apigee-synchronizer-hybr-example-env-dggroupconfi-bc7726a       3      12m
...

Vérifiez le ConfigMap nommé:

kubectl get configmap -n APIGEE_NAMESPACE CONFIGMAP_NAME -o yaml

où CONFIGMAP_NAME est le nom du fichier de configuration de l'étape précédente.

Vous devriez obtenir un résultat semblable à celui-ci :

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

Vérifiez l'existence de pods d'exécution contenant la sous-chaîne auto:

kubectl get pods -n APIGEE_NAMESPACE | grep auto

Vous devriez obtenir un résultat semblable à celui-ci :

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

Limites

Apigee n'offre des limites de proxy améliorées que pour les organisations nouvellement créées. Il est possible de convertir des organisations existantes pour qu'elles utilisent les limites de proxy améliorées.

Les sauvegardes d'une organisation créée sans que les limites de proxy avancées ne soient activées ne peuvent pas être restaurées dans une organisation créée avec cette fonctionnalité activée.

Problèmes connus

Chaînage de proxys :
- La chaîne de proxy avec mTLS n'est pas prise en charge. Voir le problème connu 392135466.
- Lorsque vous disposez de plusieurs hôtes virtuels, la création de la version Helm peut échouer en raison de noms ApigeeRoute en conflit. Pour contourner ce problème, exécutez les commandes suivantes pour chaque hôte virtuel lors de l'installation ou de la mise à niveau du graphique apigee-virtualhost pour chaque groupe d'environnements:
```
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
```
  où :
  - PROJECT_ID_SUFFIX est un suffixe unique pour l'enchaînement interne de votre projet dans Kubernetes. Vous pouvez trouver ce suffixe à l'aide de la commande suivante:
```
kubectl get svc -n apigee -l app=apigee-ingressgateway | grep internal-chaining
```
    Le résultat doit se présenter comme suit:
```
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
```
    Dans l'exemple de sortie, my-project--1234567 correspond à PROJECT_ID_SUFFIX.
  - APIGEE_NAMESPACE est votre espace de noms Apigee.
  - NEW_ENV_GROUP_NAME est le nom du groupe d'environnements supplémentaire. Modifiez cette valeur pour chaque hôte virtuel.
  Consultez le problème connu 384937220.

Dépannage

Symptôme	Solution
La session de débogage n'affiche pas les requêtes.	Suivez la procédure décrite dans la section Définir le flux d'autorisation pour vérifier les autorisations du compte de service d'exécution Apigee.