Ativar clientes não SNI e HTTP

Neste tópico, explicamos como ativar clientes não SNI, clientes HTTP e uma combinação de ambos para uso com o Apigee híbrido.

Como configurar um cliente não SNI

Nesta seção, explicamos como ativar o suporte para clientes que não são SNI (Indicação do nome do servidor) na Apigee híbrida. Um cliente não SNI usa a porta 443 e é necessário se você quiser integrar instâncias de ambiente de execução híbrida com o Cloud Load Balancing do Google ou para clientes que não aceitam SNI.

Crie uma definição de recurso personalizada (CRD, na sigla em inglês) do ApigeeRoute. Verifique se 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: apigee-ingressgateway
  enableNonSniClient: true
```
Em que:
- route_name é o nome do CRD;
- credential_name é o nome de um secret do Kubernetes implantado no cluster que contém as credenciais TLS do seu host virtual. Para encontrar o nome da credencial, use o seguinte comando kubectl:
```
kubectl -n apigee get ApigeeRoutes -o=yaml | grep credentialName
```
- hostnames precisa ser definido como o caractere curinga "*".
  Observação: não crie dois objetos ApigeeRoute com o nome de host "*".
Abra o arquivo de substituição e faça a alteração descrita na próxima etapa.

Para cada grupo de ambiente, adicione o nome do ApigeeRoute à propriedade additionalGateways. Exemplo:

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

Salve o arquivo CRD. Exemplo: ApigeeRoute.yaml

Aplique o CRD ao cluster:

kubectl apply -f ApigeeRoute.yaml -n apigee

Aplique a alteração a virtualhosts:

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

Observações sobre uso

O que acontece se o cluster tiver mais de uma organização?
Como a entrada está no nível do cluster para uma determinada porta (443) e só pode haver um par de chaves/certificados para o CRD do ApigeeRoute, todas as organizações precisam compartilhar o mesmo par de chaves/certificados.
O que acontece se o cluster tiver mais de um grupo de ambiente? Ele funcionará se os hosts virtuais compartilharem o mesmo par de chave/certificado?
Todos os nomes de host em todos os grupos de ambiente precisam usar o mesmo par de chave/certificado.
Por que estamos criando um ApigeeRoute em vez do Gateway?
O ApigeeRoutes pode ser validado pela Apigee. No entanto, o Gateway (CRD do Istio) não pode. Tecnicamente, até mesmo o Gateway pode funcionar, mas podemos evitar possíveis erros de configuração (por meio de um webhook de validação).

Ativar clientes HTTP

Nesta seção, explicamos o suporte aos clientes HTTP para uso com a Apigee híbrida.

Crie uma definição de recurso personalizada (CRD, na sigla em inglês) do ApigeeRoute. 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
```
Em que:
- route_name é o nome do CRD;
- hostnames precisa ser definido como o caractere curinga "*".
  Observação: não crie dois objetos ApigeeRoute com o nome de host "*".
Abra o arquivo de substituição e faça a alteração descrita na próxima etapa.

Para cada grupo de ambiente, adicione o nome do ApigeeRoute à propriedade additionalGateways. Exemplo:

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

Salve o arquivo CRD. Exemplo: ApigeeRoute.yaml

Aplique o CRD ao cluster:

kubectl apply -f ApigeeRoute.yaml -n apigee

Aplique a alteração a virtualhosts:

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

Ativar o suporte para clientes não SNI e HTTP

Esta seção explica como ativar tanto clientes não SNI (porta 443) como HTTP (porta 80) para uso com a Apigee híbrida.

Crie uma definição de recurso personalizada (CRD, na sigla em inglês) do ApigeeRoute. 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

Em que:

route_name é o nome do CRD;
hostname precisa ser definido como o caractere curinga "*".
Observação: não crie dois objetos ApigeeRoute com o nome de host "*".
credential_name é o nome de um secret do Kubernetes implantado no cluster que contém as credenciais TLS do seu host virtual. Para encontrar o nome da credencial, use o seguinte comando kubectl:
```
kubectl -n apigee get ApigeeRoutes -o=yaml | grep credentialName
```

Abra o arquivo de substituição e faça a alteração descrita na próxima etapa.

Para cada grupo de ambiente, adicione o nome do ApigeeRoute à propriedade additionalGateways. Exemplo:

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

Salve o arquivo CRD. Exemplo: ApigeeRoute.yaml

Aplique o CRD ao cluster:

kubectl apply -f ApigeeRoute.yaml -n apigee

Aplique a alteração a virtualhosts:

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