Se usó la API de Cloud Translation para traducir esta página.

Límites de proxy mejorados

Descripción general

Las nuevas organizaciones híbridas de Apigee se pueden aprovisionar con la capacidad de implementar más de 50 proxies por entorno habilitado. Esta función también está disponible para Apigee X.

La cantidad máxima de proxies de API y flujos compartidos implementados por organización es de 6,000.
La cantidad máxima de unidades de implementación de proxy por instancia de Apigee es de 6,000.
La cantidad máxima de rutas de acceso base de la API por organización de Apigee es de 3,000.

Cuando se implementen más de 50 proxies en un entorno, Apigee lo particionará automáticamente en varios conjuntos de réplicas distintos, cada uno de los cuales contendrá un subconjunto de proxies implementados en el entorno. Estos subconjuntos de réplicas son equivalentes en comportamiento a un solo entorno en la forma en que carga y ejecuta un conjunto de proxies y otros recursos del entorno. Esto será transparente para el usuario, y podrás seguir usando el entorno como lo harías con un solo entorno.

Aprovisionamiento

Para aprovisionar una organización nueva con la cantidad mejorada de proxies por entorno, sigue estos pasos:

Proporciona el ID de tu proyecto y el nombre de la organización a tu representante de Apigee para configurar el límite de proxy mejorado.
Sigue las instrucciones de instalación de Apigee Hybrid para aprovisionar la organización híbrida. En tu archivo de anulaciones, agrega la propiedad de nivel superior enhanceProxyLimits:
```
enhanceProxyLimits: true
```
Para aplicar los cambios a enhanceProxyLimits, actualiza el gráfico apigee-org y el gráfico apigee-virtualhost de cada grupo de entorno.

Alerta: No cambies este valor una vez establecido.
Crea e implementa un proxy.

Verifica que los límites de proxy mejorados estén habilitados:

Obtén el nombre del configmap para tu espacio de nombres de Apigee:

kubectl get configmap -n APIGEE_NAMESPACE

El resultado debería ser similar al siguiente:

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

Verifica el configmap con nombre:

kubectl get configmap -n APIGEE_NAMESPACE CONFIGMAP_NAME -o yaml

En el que CONFIGMAP_NAME es el nombre del configmap del paso anterior.

El resultado debería ser similar al siguiente:

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

Verifica si existen pods de entorno de ejecución que contengan la substring auto:

kubectl get pods -n APIGEE_NAMESPACE | grep auto

El resultado debería ser similar al siguiente:

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

Limitaciones

Apigee ofrece límites de proxy mejorados solo en las organizaciones creadas recientemente. Se admite la conversión de organizaciones existentes para usar límites de proxy mejorados.

Las copias de seguridad de una organización que se creó sin habilitar los límites de proxy mejorados no se pueden restablecer en una organización creada con la función habilitada.

Problemas conocidos

Encadenamiento de proxy:
- No se admite la encadenación de proxy con mTLS. Consulta el problema conocido 392135466.
- Cuando tienes varios hosts virtuales, es posible que la creación de la versión de Helm falle debido a nombres de ApigeeRoute en conflicto. La solución alternativa es ejecutar los siguientes comandos para cada host virtual cuando instales o actualices el gráfico apigee-virtualhost para cada grupo de entornos:
```
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
```
  Donde:
  - PROJECT_ID_SUFFIX es un sufijo único para la encadenación interna de tu proyecto en Kubernetes. Puedes encontrar este sufijo con el siguiente comando:
```
kubectl get svc -n apigee -l app=apigee-ingressgateway | grep internal-chaining
```
    El resultado se verá similar a lo siguiente:
```
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
```
    En el resultado de ejemplo, my-project--1234567 es el PROJECT_ID_SUFFIX.
  - APIGEE_NAMESPACE es el espacio de nombres de Apigee.
  - NEW_ENV_GROUP_NAME es el nombre del grupo de entornos adicional. Actualiza este valor para cada host virtual.
  Consulta el problema conocido 384937220.

Soluciona problemas

Síntoma	Solución
La sesión de depuración no muestra solicitudes.	Sigue los pasos que se indican en Configura el flujo de autorización para verificar los permisos de la cuenta de servicio del entorno de ejecución de Apigee.