Instalar e atualizar gateways com APIs Istio

Nota: este guia só suporta a malha de serviços na nuvem com APIs Istio e não suporta Google Cloud APIs. Para mais informações, consulte o artigo Vista geral do Cloud Service Mesh.

O Cloud Service Mesh oferece-lhe a opção de implementar e gerir gateways como parte da sua malha de serviços. Um gateway descreve um balanceador de carga que opera no limite da malha e recebe ligações HTTP/TCP de entrada ou saída. Os gateways são usados principalmente para gerir o tráfego de entrada, mas também pode configurá-los para gerir outros tipos de tráfego.

• Gateways de saída: um gateway de saída permite-lhe configurar um nó de saída dedicado para o tráfego que sai da malha, o que lhe permite limitar os serviços que podem ou devem aceder a redes externas, ou ativar o controlo seguro do tráfego de saída para adicionar segurança à sua malha, por exemplo.

• Gateways de entrada: um gateway de entrada permite-lhe configurar um nó de entrada dedicado para receber ligações HTTP/TCP recebidas.

• Gateways leste-oeste: um proxy para tráfego leste-oeste para permitir que as cargas de trabalho de serviço comuniquem entre limites de clusters numa malha multiprimária em redes diferentes. Por predefinição, este gateway é público na Internet.

Esta página descreve as práticas recomendadas para implementar e atualizar os proxies de gateway, bem como exemplos de configuração dos seus próprios proxies de gateway istio-ingressgateway e istio-egressgateway.

Pode implementar gateways de diferentes formas e usar mais do que uma topologia no mesmo cluster. Consulte as topologias de implementação de gateways na documentação do Istio para saber mais sobre estas topologias.

Práticas recomendadas para a implementação de gateways

As práticas recomendadas para implementar gateways dependem de estar a usar o plano de dados gerido ou o plano de dados não gerido.

Práticas recomendadas para o plano de dados gerido

1. Ative o plano de dados gerido.
2. Adicione uma etiqueta de revisão gerida a um espaço de nomes.
3. Implemente e faça a gestão do plano de controlo e das gateways separadamente.
4. Como prática recomendada de segurança, recomendamos que implemente gateways num espaço de nomes diferente do plano de controlo.
5. Use a injeção automática de sidecar (injeção automática) para injetar a configuração do proxy para os gateways de forma semelhante à injeção dos proxies sidecar para os seus serviços.

Estas práticas recomendadas:

• Certifique-se de que os gateways geridos são mantidos automaticamente atualizados com os mais recentes melhoramentos e atualizações de segurança.
• Transfere a gestão e a manutenção de instâncias de gateway para o plano de dados gerido do Cloud Service Mesh.

Práticas recomendadas para o plano de dados não gerido

1. Implemente e faça a gestão do plano de controlo e das gateways separadamente.
2. Como prática recomendada de segurança, recomendamos que implemente gateways num espaço de nomes diferente do plano de controlo.
3. Use a injeção automática de sidecar (injeção automática) para injetar a configuração do proxy para os gateways de forma semelhante à injeção dos proxies sidecar para os seus serviços.

Estas práticas recomendadas:

• Permita que os administradores do espaço de nomes façam a gestão de gateways sem precisarem de privilégios elevados para todo o cluster.
• Permita que os seus administradores usem o mesmo mecanismo ou ferramentas de implementação que usam para gerir aplicações Kubernetes para implementar e gerir gateways.
• Dão aos administradores controlo total sobre a implementação da entrada e também simplificam as operações. Quando está disponível uma nova atualização ou uma configuração foi alterada, os administradores atualizam os pods de gateway reiniciando-os. Isto torna a experiência de operar uma implementação de gateway igual à de operar proxies sidecar para os seus serviços.

Implemente um gateway de exemplo

Para oferecer apoio técnico aos utilizadores com ferramentas de implementação existentes, o Cloud Service Mesh suporta as mesmas formas de implementar um gateway que o Istio: IstioOperator, Helm e YAML do Kubernetes. Cada método produz o mesmo resultado. Embora possa escolher o método com o qual tem mais familiaridade, recomendamos que use o método YAML do Kubernetes porque é mais fácil de modificar e pode armazenar manifestos preenchidos no controlo de origem.

Os passos seguintes mostram como implementar um gateway de amostra.

1. Crie um espaço de nomes para o gateway, se ainda não tiver um. Substitua GATEWAY_NAMESPACE pelo nome do seu espaço de nomes.

   kubectl create namespace GATEWAY_NAMESPACE
   

2. Ative o espaço de nomes para injeção. Os passos dependem da sua implementação do plano de controlo.

   Gerido (TD)

   1. Aplique a etiqueta de injeção predefinida ao espaço de nomes:

   kubectl label namespace GATEWAY_NAMESPACE \
       istio.io/rev- istio-injection=enabled --overwrite
   

   Gerido (Istiod)

   Recomendado: execute o seguinte comando para aplicar a etiqueta de injeção predefinida ao espaço de nomes:

     kubectl label namespace GATEWAY_NAMESPACE \
         istio.io/rev- istio-injection=enabled --overwrite
   

   Se for um utilizador existente com o plano de controlo do Istiod gerido: recomendamos que use a injeção predefinida, mas a injeção baseada em revisões é suportada. Siga as instruções abaixo:

   1. Execute o seguinte comando para localizar os canais de lançamento disponíveis:

      kubectl -n istio-system get controlplanerevision
      

      O resultado é semelhante ao seguinte:

      NAME                AGE
      asm-managed-rapid   6d7h
      

      NOTA: se aparecerem duas revisões do plano de controlo na lista acima, remova uma delas. Ter vários canais do plano de controlo no cluster não é suportado.

      Na saída, o valor na coluna NAME é a etiqueta de revisão que corresponde ao canal de lançamento disponível para a versão do Cloud Service Mesh.

   2. Aplique a etiqueta de revisão ao espaço de nomes:

      kubectl label namespace GATEWAY_NAMESPACE \
          istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      

   No cluster

   Recomendado: execute o seguinte comando para aplicar a etiqueta de injeção predefinida ao espaço de nomes:

     kubectl label namespace GATEWAY_NAMESPACE \
         istio.io/rev- istio-injection=enabled --overwrite
   

   Recomendamos que use a injeção predefinida, mas a injeção baseada em revisões é suportada: siga estas instruções:

   1. Use o seguinte comando para localizar a etiqueta de revisão em istiod:

      kubectl get deploy -n istio-system -l app=istiod -o \
         jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
      

   2. Aplique a etiqueta de revisão ao espaço de nomes. No comando seguinte, REVISION_LABEL é o valor da etiqueta de revisão istiod que anotou no passo anterior.

      kubectl label namespace GATEWAY_NAMESPACE \
          istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      

3. Copie os ficheiros de configuração para os gateways de exemplo do repositório anthos-service-mesh.

4. Altere o diretório para o diretório samples. Para garantir que está no diretório correto, execute o comando ls para listar o conteúdo do diretório e, em seguida, confirme que existe um diretório gateways (ao qual vai aceder no passo seguinte) e um diretório online-boutique.

5. Implemente um gateway de entrada ou saída. Estes encontram-se no diretório samples/gateways/ tal como estão ou pode modificá-los conforme necessário.

   Entrada

   kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-ingressgateway
   

   Saída

   kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-egressgateway
   

6. Depois de criar a implementação, verifique se os novos serviços estão a funcionar corretamente:

   kubectl get pod,service -n GATEWAY_NAMESPACE
   

   Verifique se o resultado é semelhante ao seguinte:

   NAME                                      READY   STATUS    RESTARTS   AGE
   pod/istio-ingressgateway-856b7c77-bdb77   1/1     Running   0          3s
   
   NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
   service/istio-ingressgateway   LoadBalancer   10.24.5.129    34.82.157.6      80:31904/TCP   3s

Gerir recursos de gateway como qualquer outra aplicação Kubernetes. As amostras no repositório anthos-service-mesh-packages destinam-se a orientações e a um início rápido. Personalize-os de acordo com as suas necessidades.

Seletores de gateway

Aplica uma configuração de Gateway aos proxies istio-ingressgateway e istio-egressgateway para gerir o tráfego de entrada e saída da sua malha, o que lhe permite especificar que tráfego quer que entre ou saia da malha. As etiquetas nos pods de uma implementação de gateway são usadas pelos recursos de configuração do gateway, pelo que é importante que o seletor de gateway corresponda a estas etiquetas.

Por exemplo, nas implementações anteriores, a etiqueta istio=ingressgateway é definida nos pods de gateway. Para aplicar uma configuração de gateway a estas implementações, tem de selecionar a mesma etiqueta:

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: gateway
spec:
  selector:
    istio: ingressgateway
...

Para ver um exemplo de uma configuração de gateway e um serviço virtual, consulte frontend.yaml na aplicação de exemplo Online Boutique.

Atualize gateways

Atualizações no local

Na maioria dos casos de utilização, deve atualizar as suas gateways seguindo o padrão de atualização no local. Uma vez que os gateways usam a injeção de pods, os novos pods de gateway criados são automaticamente injetados com a configuração mais recente, que inclui a versão.

Se quiser alterar a revisão do plano de controlo usada pela entrada, pode definir a etiqueta istio.io/rev na implementação da entrada, o que também aciona um reinício contínuo.

Plano de controlo gerido

Uma vez que a Google gere as atualizações do plano de controlo para o plano de controlo gerido, pode simplesmente reiniciar a implementação da gateway e os novos pods serão automaticamente injetados com a configuração e a versão mais recentes.

kubectl rollout restart deployment istio-ingressgateway \
  -n GATEWAY_NAMESPACE

Painel de controlo no cluster

Para aplicar o mesmo padrão aos gateways quando tiver o plano de controlo no cluster, tem de alterar a revisão do plano de controlo usada pelo gateway. Defina a etiqueta istio.io/rev na implementação da gateway, o que vai acionar um reinício progressivo. Os passos necessários dependem de ter de atualizar a etiqueta de revisão no espaço de nomes e/ou no pod do gateway.

• Se etiquetou o espaço de nomes para injeção, defina a etiqueta istio.io/rev no espaço de nomes para o novo valor de revisão:

    kubectl label namespace GATEWAY_NAMESPACE \
      istio-injection- istio.io/rev=REVISION \
      --overwrite
  

• Se ativou a injeção apenas para o pod de gateway, defina a etiqueta istio.io/rev no Deployment para o novo valor de revisão, como no seguinte ficheiro YAML do Kubernetes:

  cat <<EOF > gateway-deployment.yaml
  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: istio-ingressgateway
    namespace: GATEWAY_NAMESPACE
  spec:
    selector:
      matchLabels:
        istio: ingressgateway
    template:
      metadata:
        annotations:
          # This is required to tell Cloud Service Mesh to inject the gateway with the
          # required configuration.
          inject.istio.io/templates: gateway
        labels:
          istio: ingressgateway
          istio.io/rev: REVISION
      spec:
        containers:
        - name: istio-proxy
          image: auto # The image will automatically update each time the pod starts.
  EOF
  
  kubectl apply -f gateway-deployment.yaml
  

  Nota: se o image não for atualizado automaticamente com a imagem do proxy do Cloud Service Mesh real, o contentor não é encontrado e ocorre um erro. Consulte o artigo Resolva problemas de gateways para ver os passos seguintes.

Atualizações canary (avançadas)

Se estiver a usar o plano de controlo no cluster e quiser controlar a implementação de uma nova revisão do plano de controlo mais lentamente, pode seguir o padrão de atualização canário. Pode executar várias versões de uma implementação de gateway e garantir que tudo funciona conforme esperado com um subconjunto do seu tráfego. Por exemplo, se quiser implementar uma nova revisão, uma implementação canary, crie uma cópia da sua implementação do gateway com a etiqueta istio.io/rev=REVISION definida para a nova revisão e um novo nome, por exemplo, istio-ingressgateway-canary:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway-canary
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: REVISION # Set to the control plane revision you want to deploy
    spec:
      containers:
      - name: istio-proxy
        image: auto

Nota: se o image não for atualizado automaticamente com a imagem do proxy do Cloud Service Mesh real, o contentor não é encontrado e ocorre um erro. Consulte o artigo Resolva problemas de gateways para ver os passos seguintes.

Quando esta implementação é criada, tem duas versões do gateway, ambas selecionadas pelo mesmo serviço:

kubectl get endpoints -o "custom-columns=NAME:.metadata.name,PODS:.subsets[*].addresses[*].targetRef.name"

NAME                   PODS
istio-ingressgateway   istio-ingressgateway-788854c955-8gv96,istio-ingressgateway-canary-b78944cbd-mq2qf

Nota: ao contrário dos serviços de aplicações implementados na malha, não pode usar a mudança de tráfego do Istio para distribuir o tráfego entre as versões da gateway, porque o respetivo tráfego provém diretamente de clientes externos que o Istio não controla. Em alternativa, pode controlar a distribuição do tráfego pelo número de réplicas de cada implementação. Se usar outro equilibrador de carga à frente do Istio, também pode usá-lo para controlar a distribuição de tráfego.

Se tiver a certeza de que as suas aplicações estão a funcionar conforme esperado, execute este comando para fazer a transição para a nova versão eliminando a implementação com o conjunto de etiquetas istio.io/rev antigo:

kubectl delete deploy/istio-ingressgateway -n GATEWAY_NAMESPACE

Se encontrou um problema ao testar a sua aplicação com a nova versão da gateway, execute este comando para voltar à versão antiga através da eliminação da implementação com o novo conjunto de etiquetas istio.io/rev:

kubectl delete deploy/istio-ingressgateway-canary -n GATEWAY_NAMESPACE

Configuração avançada

Configure a versão mínima de TLS do gateway

Para a Cloud Service Mesh, a versão mínima predefinida do TLS para servidores de gateway é 1.2. Pode configurar a versão mínima do TLS através do campo minProtocolVersion. Para mais informações, consulte o artigo ServerTLSSettings.

Funcionalidades não suportadas

Se tiver uma TRAFFIC_DIRECTOR implementação do plano de controlo, os seguintes campos ou valores no Gateway não são suportados:

• ServerTLSSettings.TLSmode com o valor AUTO_PASSTHROUGH
• ServerTLSSettings.verifyCertificateSpki
• ServerTLSSettings.verifyCertificateHash

Resolva problemas de gateways

Falha ao atualizar a imagem do gateway de auto

Quando implementa ou atualiza um gateway, o Cloud Service Mesh insere auto como um marcador de posição no campo image. Após a chamada para o webhook de mutação, o Cloud Service Mesh substitui automaticamente este marcador de posição pela imagem do proxy do Cloud Service Mesh real. Se a chamada para o webhook de mutação falhar, o marcador de posição auto permanece e o contentor não é encontrado. Normalmente, isto deve-se a uma etiqueta de espaço de nomes incorreta. Certifique-se de que configurou o espaço de nomes correto e, em seguida, implemente ou atualize novamente o gateway.