Instalar e atualizar gateways

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. As gateways são proxies Envoy que lhe oferecem um controlo detalhado sobre o tráfego que entra e sai da malha. 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. Por exemplo:

• 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 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. As ações como a divisão do tráfego, os redirecionamentos e a lógica de repetição são possíveis através da aplicação de uma configuração de gateway aos proxies de gateway. Em seguida, em vez de adicionar o encaminhamento de tráfego da camada de aplicação (L7) ao mesmo recurso da API, associa um serviço virtual à gateway. Isto permite-lhe gerir o tráfego de gateway como qualquer outro tráfego do plano de dados na malha de serviço.

Pode implementar gateways de diferentes formas e optar por 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 simplesmente. Isto torna a experiência de operar uma implementação de gateway igual à de operar proxies sidecar para os seus serviços.

Implemente gateways

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.

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. Para ativar a injeção automática, etiquete os seus espaços de nomes com as etiquetas de injeção predefinidas se a etiqueta predefinida estiver configurada ou com a etiqueta de revisão no seu espaço de nomes. A etiqueta que adiciona também depende de ter implementado a malha de serviços na nuvem gerida ou instalado o painel de controlo no cluster. A etiqueta é usada pelo webhook do injetor sidecar para associar sidecars injetados a uma revisão do plano de controlo específica.

   Selecione o separador abaixo de acordo com o tipo de instalação (gerida ou no cluster).

   Gerido

   Use 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         6d7h
   asm-managed-rapid   6d7h
   

   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.

   No cluster

   Para os painéis de controlo no cluster, o serviço e a implementação têm normalmente uma etiqueta de revisão semelhante a istio.io/rev=asm-1264-1, em que asm-1264-1 identifica a versão do Cloud Service Mesh.istiod A revisão passa a fazer parte do nome do serviço istiod, por exemplo: istiod-asm-1264-1.istio-system

   Use o seguinte comando para localizar a etiqueta de revisão em istiod para o plano de controlo no cluster:

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

3. Ative o espaço de nomes para injeção. Substitua REVISION pelo valor da etiqueta de revisão.

   Nota: pode substituir istio.io/rev pela etiqueta istio-injection=enabled se a etiqueta predefinida estiver configurada. Verifique se a etiqueta predefinida existe executando istioctl tag list com o istioctl de OUTPUT_DIR.

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

4. Se instalou o Cloud Service Mesh através do asmcli, altere para o diretório que especificou em --output_dir e, em seguida, cd para o diretório samples.

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

   Se não fez a instalação através do asmcli, copie os ficheiros de configuração das gateways do repositório anthos-service-mesh.

5. Pode implementar a configuração de gateway de exemplo localizada no diretório samples/gateways/ tal como está ou modificá-la conforme necessário.

   Entrada

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

   Saída

   kubectl apply -n GATEWAY_NAMESPACE -f 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

Importante: os recursos de gateway devem ser geridos como qualquer outra aplicação Kubernetes. Os exemplos no repositório anthos-service-mesh-packages destinam-se a orientações e um início rápido, e deve personalizá-los 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 acima, a etiqueta istio=ingressgateway está 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 Anthos 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" \
-n GATEWAY_NAMESPACE

O resultado é semelhante ao seguinte:

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 versão 1.14 e posteriores do 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.

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.