Habilitar clientes que no sean SNI ni HTTP

En este tema se explica cómo habilitar clientes que no sean SNI, clientes HTTP y una combinación de ambos para usarlos con Apigee hybrid.

Cómo configurar un cliente que no es de la SNI

En esta sección se explica cómo habilitar la compatibilidad con clientes que no usan SNI (indicador del nombre del servidor) en Apigee hybrid. Un cliente que no usa SNI utiliza el puerto 443 y es necesario si quieres integrar instancias de tiempo de ejecución híbridas con Cloud Load Balancing de Google o para clientes que no admiten SNI.
  1. Crea una definición de recurso personalizado (CRD) de ApigeeRoute. 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: istio-ingressgateway
  enableNonSniClient: true

    Donde:

    • route_name es el nombre que le das al CRD.
    • credential_name es el nombre de un secreto de Kubernetes implementado en el clúster que contiene las credenciales TLS de tu host virtual.
    • hostnames debe tener el comodín "*".
  2. Abre el archivo de anulaciones y haz el cambio que se describe en el paso siguiente.
  3. En cada grupo de entornos, añade el nombre de ApigeeRoute a la propiedad additionalGateways. Por ejemplo: 
    virtualhosts:
  - name: default
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    additionalGateways: ["route_name"]
  4. Guarda el archivo CRD. Por ejemplo: ApigeeRoute.yaml
  5. Aplica el CRD al clúster: 
    kubectl apply -f ApigeeRoute.yaml -n apigee
  6. Aplica el cambio a virtualhosts: 
    $APIGEECTL_HOME/apigeectl apply -f overrides.yaml --settings virtualhosts --env $ENVIRONMENT

Notas de uso

  • ¿Qué ocurre si el clúster tiene más de una organización?

    Como el acceso se encuentra a nivel de clúster para un puerto determinado (443) y solo puede haber un par de claves y certificados para el CRD de ApigeeRoute, todas las organizaciones deben compartir el mismo par de claves y certificados.

  • ¿Qué ocurre si el clúster tiene más de un grupo de entornos? ¿Funcionará si los hosts virtuales comparten el mismo par de claves y certificados?

    Todos los nombres de host de todos los grupos de entornos deben usar el mismo par de clave y certificado.

  • ¿Por qué creamos un ApigeeRoute en lugar de un Gateway?

    Apigee puede validar ApigeeRoutes. Sin embargo, Gateway (el CRD de Istio) no puede hacerlo. Técnicamente, incluso Gateway puede funcionar, pero podemos evitar posibles errores de configuración (mediante un webhook de validación).

Habilitar clientes HTTP

En esta sección se explica la compatibilidad con clientes HTTP para usar con Apigee Hybrid.

  1. Crea una definición de recurso personalizado (CRD) de ApigeeRoute. 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

    Donde:

    • route_name es el nombre que le das al CRD.
    • hostnames debe tener el comodín "*".
  2. Abre el archivo de anulaciones y haz el cambio que se describe en el paso siguiente.
  3. En cada grupo de entornos, añade el nombre de ApigeeRoute a la propiedad additionalGateways. Por ejemplo: 
    virtualhosts:
  - name: default
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    additionalGateways: ["route_name"]
  4. Guarda el archivo CRD. Por ejemplo: ApigeeRoute.yaml
  5. Aplica el CRD al clúster: 
    kubectl apply -f ApigeeRoute.yaml -n apigee
  6. Aplica el cambio a virtualhosts: 
    $APIGEECTL_HOME/apigeectl apply -f overrides.yaml --settings virtualhosts --env $ENVIRONMENT

Habilitar la compatibilidad con clientes que no sean SNI ni HTTP

En esta sección se explica cómo habilitar clientes que no sean SNI (puerto 443) ni HTTP (puerto 80) para usarlos con Apigee hybrid.

  1. Crea una definición de recurso personalizado (CRD) de ApigeeRoute. 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

    Donde:

    • route_name es el nombre que le das al CRD.
    • hostname debe tener el comodín "*".
    • credential_name es el nombre de un secreto de Kubernetes implementado en el clúster que contiene las credenciales TLS de tu host virtual.
  2. Abre el archivo de anulaciones y haz el cambio que se describe en el paso siguiente.
  3. En cada grupo de entornos, añade el nombre de ApigeeRoute a la propiedad additionalGateways. Por ejemplo: 
    virtualhosts:
  - name: default
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    additionalGateways: ["route_name"]
  4. Guarda el archivo CRD. Por ejemplo: ApigeeRoute.yaml
  5. Aplica el CRD al clúster: 
    kubectl apply -f ApigeeRoute.yaml -n apigee
  6. Aplica el cambio a virtualhosts: 
    $APIGEECTL_HOME/apigeectl apply -f overrides.yaml --settings virtualhosts --env $ENVIRONMENT