Habilita clientes HTTP y sin SNI

En este tema, se explica cómo habilitar clientes sin SNI, clientes HTTP y una combinación de ambos para usar con Apigee Hybrid.

Configura un cliente que no sea SNI

En esta sección, se explica cómo habilitar la asistencia para clientes que no sean SNI (Indicador del nombre del servidor) en Apigee Hybrid. Un cliente sin SNI usa el puerto 443 y es obligatorio si deseas integrar instancias de entorno de ejecución híbrido con Google Cloud Load Balancing o clientes sin SNI.

Crea una definición de recurso personalizado (CRD) de ApigeeRouter. Asegúrate de que enableNonSniClient esté configurado como true:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: ApigeeRoute
metadata:
  name: route_name
  namespace: apigee
spec:
  hostnames:
  - "*"
  ports:
  - number: 443
    protocol: HTTPS
    tls:
      credentialName: credential_name
      mode: SIMPLE
      #optional
      minProtocolVersion: TLS_AUTO
  selector:
    app: apigee-ingressgateway
  enableNonSniClient: true
```
Aquí:
- route_name es el nombre que le asignas al recurso personalizado (CR).
- credential_name es el nombre de un Secret de Kubernetes implementado en el clúster que contiene credenciales TLS para tu host virtual. Puedes encontrar el nombre de la credencial con el siguiente comando kubectl:
```
kubectl -n apigee get ApigeeRoutes -o=yaml | grep credentialName
```
- hostnames se debe establecer en el comodín "*".
  Nota: No crees dos objetos de ApigeeRoute con un nombre de host comodín "*".
Abre tu archivo de anulación y realiza el cambio que se describe en el siguiente paso.

Para cada grupo de entornos, agrega el nombre de ApigeeRoute a la propiedad additionalGateways. Por ejemplo:

virtualhosts:
  - name: default
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    additionalGateways: ["route_name"]

Guarda el archivo CRD. Por ejemplo: ApigeeRoute.yaml

Aplica el CRD al clúster:

kubectl apply -f ApigeeRoute.yaml -n apigee

Aplica el cambio a virtualhosts:

Helm

helm upgrade ENV_GROUP apigee-virtualhost/ \
  --namespace apigee \
  --atomic \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE.yaml

Nota: Si ves un error que dice Error: UPGRADE FAILED: "ENV_GROUP" has no deployed releases, reemplaza upgrade por install y vuelve a intentar el comando.

`apigeectl`

$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE.yaml --settings virtualhosts --env $ENVIRONMENT

Notas de uso

¿Qué sucede si el clúster tiene más de una organización?
Dado que la entrada está a nivel del clúster para un puerto determinado (443), y solo puede haber un par clave-valor para la CRD de ApigeeRouter, todas las organizaciones deben compartir el mismo par de clave/certificado.
¿Qué sucede si el clúster tiene más de un grupo de entornos? ¿Funcionará si los hosts virtuales comparten el mismo par de claves o certificados?
Todos los nombres de host en todos los grupos de entornos deben usar el mismo par de clave/certificado.
¿Por qué crearemos una ApigeeRouter en lugar de Gateway?
ApigeeRoutes puede validar las rutas; sin embargo, la puerta de enlace (el CRD de Istio) no lo puede hacer. Técnicamente, incluso la puerta de enlace puede funcionar, pero podemos evitar posibles errores de configuración (a través de un webhook de validación).