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 comotrue
: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 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 "*".
- 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
. Si configuraste la variable de entorno $ENV_GROUP en tu shell, puedes usarla en los siguientes comandos:helm upgrade $ENV_GROUP apigee-virtualhost/ \ --namespace apigee \ --atomic \ --set envgroup=$ENV_GROUP \ -f OVERRIDES_FILE.yaml
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).
Habilita clientes HTTP
En esta sección, se explica la compatibilidad con los clientes HTTP para usar con Apigee Hybrid.
- Crea una definición de recurso personalizado (CRD) de ApigeeRouter. Por ejemplo:
apiVersion: apigee.cloud.google.com/v1alpha1 kind: ApigeeRoute metadata: name: route_name namespace: apigee spec: hostnames: - "*" ports: - number: 80 protocol: HTTP selector: app: istio-ingressgateway enableNonSniClient: true
Aquí:
- route_name es el nombre que le asignas al CRD.
hostnames
se debe establecer en el 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 upgrade $ENV_GROUP apigee-virtualhost/ \ --namespace apigee \ --atomic \ --set envgroup=$ENV_GROUP \ -f OVERRIDES_FILE.yaml
Habilita la compatibilidad para los clientes que no usan SNI ni HTTP
En esta sección, se explica cómo habilitar los dos clientes, los que no tienen SNI (puerto 443) y los HTTP (puerto 80) para usarlos con Apigee Hybrid.
- Crea una definición de recurso personalizado (CRD) de ApigeeRouter. Por ejemplo:
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 - number: 80 protocol: HTTP selector: app: istio-ingressgateway enableNonSniClient: true
Aquí:
- route_name es el nombre que le asignas al CRD.
hostname
se debe establecer en el comodín "*".- 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
- 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 upgrade $ENV_GROUP apigee-virtualhost/ \ --namespace apigee \ --atomic \ --set envgroup=$ENV_GROUP \ -f OVERRIDES_FILE.yaml