Ative clientes HTTP e não SNI

Este tópico explica como ativar clientes não SNI, clientes HTTP e uma combinação de ambos para utilização com o Apigee hybrid.

Esta configuração funciona para o gateway de entrada do Apigee e o Anthos Service Mesh.

Como configurar um cliente não SNI

Esta secção explica como ativar o suporte para clientes não SNI (Indicação do nome do servidor) no Apigee hybrid. Um cliente não SNI usa a porta 443 e é necessário se quiser integrar instâncias de tempo de execução híbridas com o Cloud Load Balancing da Google ou para clientes que não suportam SNI.
  1. Crie uma definição de recurso personalizado (CRD) ApigeeRoute. Certifique-se de que enableNonSniClient está definido 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: APP_NAME
  enableNonSniClient: true

    Onde:

    • ROUTE_NAME é o nome que atribui ao CRD.
    • CREDENTIAL_NAME é o nome de um segredo do Kubernetes implementado no cluster que contém credenciais TLS para o seu anfitrião virtual. Pode encontrar o nome da credencial com o seguinte comando kubectl: 
      kubectl -n apigee get ApigeeRoutes -o=yaml | grep credentialName
    • APP_NAME Identifica o tipo de gateway de entrada:
      • apigee-ingressgateway para o gateway de entrada do Apigee.
      • istio-ingressgateway para o Anthos Service Mesh.
    • hostnames tem de ser definido como o caráter universal "*".
  2. Abra o ficheiro de substituições e faça a alteração descrita no passo seguinte.
  3. Para cada grupo de ambientes, adicione o nome ApigeeRoute à propriedade additionalGateways. Por exemplo: 
    virtualhosts:
  - name: default
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    additionalGateways: ["route_name"]
  4. Guarde o ficheiro CRD. Por exemplo: ApigeeRoute.yaml
  5. Aplique o CRD ao cluster: 
    kubectl apply -f ApigeeRoute.yaml -n apigee
  6. Aplique a alteração a virtualhosts: 
    $APIGEECTL_HOME/apigeectl apply -f overrides.yaml --settings virtualhosts --env $ENVIRONMENT

Notas de utilização

  • O que acontece se o cluster tiver mais do que uma organização?

    Uma vez que a entrada está ao nível do cluster para uma determinada porta (443) e só pode haver um par de chave/certificado para o CRD ApigeeRoute, todas as organizações têm de partilhar o mesmo par de chave/certificado.

  • O que acontece se o cluster tiver mais do que um grupo de ambientes? Funciona se os anfitriões virtuais partilharem o mesmo par de chave/certificado?

    Todos os nomes de anfitrião em todos os grupos de ambientes têm de usar o mesmo par de chave/certificado.

  • Por que motivo estamos a criar um ApigeeRoute em vez de um Gateway?

    As ApigeeRoutes podem ser validadas pelo Apigee. No entanto, não é possível validar o Gateway (o CRD do Istio). Tecnicamente, até o Gateway pode funcionar, mas podemos evitar potenciais erros de configuração (através de um webhook de validação).

Ative clientes HTTP

Esta secção explica o suporte para clientes HTTP para utilização com o Apigee hybrid.

  1. Crie uma definição de recurso personalizado (CRD) ApigeeRoute. Por exemplo: 
    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

    Onde:

    • route_name é o nome que atribui ao CRD.
    • hostnames tem de ser definido como o caráter universal "*".
  2. Abra o ficheiro de substituições e faça a alteração descrita no passo seguinte.
  3. Para cada grupo de ambientes, adicione o nome ApigeeRoute à propriedade additionalGateways. Por exemplo: 
    virtualhosts:
  - name: default
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    additionalGateways: ["route_name"]
  4. Guarde o ficheiro CRD. Por exemplo: ApigeeRoute.yaml
  5. Aplique o CRD ao cluster: 
    kubectl apply -f ApigeeRoute.yaml -n apigee
  6. Aplique a alteração a virtualhosts: 
    $APIGEECTL_HOME/apigeectl apply -f overrides.yaml --settings virtualhosts --env $ENVIRONMENT

Ative o suporte para clientes HTTP e não SNI

Esta secção explica como ativar ambos os clientes não SNI (porta 443) e HTTP (porta 80) para utilização com o Apigee hybrid.

  1. Crie uma definição de recurso personalizado (CRD) ApigeeRoute. Por exemplo: 
    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

    Onde:

    • route_name é o nome que atribui ao CRD.
    • hostname tem de ser definido como o caráter universal "*".
    • credential_name é o nome de um segredo do Kubernetes implementado no cluster que contém credenciais TLS para o seu anfitrião virtual. Pode encontrar o nome da credencial com o seguinte comando kubectl: 
      kubectl -n apigee get ApigeeRoutes -o=yaml | grep credentialName
  2. Abra o ficheiro de substituições e faça a alteração descrita no passo seguinte.
  3. Para cada grupo de ambientes, adicione o nome ApigeeRoute à propriedade additionalGateways. Por exemplo: 
    virtualhosts:
  - name: default
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    additionalGateways: ["route_name"]
  4. Guarde o ficheiro CRD. Por exemplo: ApigeeRoute.yaml
  5. Aplique o CRD ao cluster: 
    kubectl apply -f ApigeeRoute.yaml -n apigee
  6. Aplique a alteração a virtualhosts: 
    $APIGEECTL_HOME/apigeectl apply -f overrides.yaml --settings virtualhosts --env $ENVIRONMENT