Como instalar e fazer upgrade de gateways

O Cloud Service Mesh oferece a opção de implantar e gerenciar gateways como parte da malha de serviço. Um gateway descreve um balanceador de carga operando na borda da malha que recebe conexões HTTP/TCP de entrada ou saída. Os gateways são proxies Envoy que fornecem um controle refinado sobre o tráfego que entra e sai da malha. Os gateways são usados principalmente para gerenciar o tráfego de entrada, mas também é possível configurar gateways para gerenciar outros tipos de tráfego. Exemplo:

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

• Gateways leste-oeste: um proxy para o tráfego east-west que permite que as cargas de trabalho de serviço se comuniquem entre os limites do cluster em uma malha multiprimária em diferentes redes. Por padrão, esse gateway será público na Internet.

Esta página descreve as práticas recomendadas para implantar e fazer upgrade dos proxies de gateway, bem como exemplos de configuração de seus próprios proxies de gateway istio-ingressgateway e istio-egressgateway. Coisas como divisão de tráfego, redirecionamentos e lógica de repetição são possíveis com a aplicação de uma configuração de Gateway aos proxies de gateway. Em vez de adicionar o roteamento de tráfego da camada do aplicativo (L7) ao mesmo recurso da API, você vincula um serviço virtual ao gateway. Isso permite gerenciar o tráfego do gateway como qualquer outro tráfego de plano de dados na malha de serviço.

É possível implantar gateways de maneiras diferentes e usar mais de uma topologia no mesmo cluster. Consulte Topologias de implantação de gateway na documentação do Istio para saber mais sobre essas topologias.

Práticas recomendadas para implantar gateways

As práticas recomendadas para a implantação de gateways dependem do uso do plano de dados gerenciado ou do plano de dados não gerenciado.

Práticas recomendadas para o plano de dados gerenciado

1. Ative o plano de dados gerenciado.
2. Adicionar um rótulo de revisão gerenciado a um namespace.
3. Implante e gerencie o plano de controle e os gateways separadamente.
4. Como prática recomendada de segurança, recomendamos implantar gateways em um namespace diferente do plano de controle.
5. Use a injeção automática de sidecar (injeção automática) para injetar a configuração de proxy dos gateways de forma semelhante ao injetar os proxies sidecar nos serviços.

Veja as práticas recomendadas:

• Os gateways gerenciados precisam estar sempre atualizados com as melhorias e as atualizações de segurança mais recentes.
• Descarrega o gerenciamento e a manutenção de instâncias de gateway para o plano de dados gerenciado do Cloud Service Mesh.

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

1. Implante e gerencie o plano de controle e os gateways separadamente.
2. Como prática recomendada de segurança, recomendamos implantar gateways em um namespace diferente do plano de controle.
3. Use a injeção automática de sidecar (injeção automática) para injetar a configuração de proxy dos gateways de forma semelhante ao injetar os proxies sidecar nos serviços.

Veja as práticas recomendadas:

• Permita que os administradores de namespace gerenciem gateways sem precisar de privilégios elevados em todo o cluster.
• Permita que os administradores usem as mesmas ferramentas ou o mesmo mecanismo de implantação que usam para gerenciar aplicativos do Kubernetes para implantar e gerenciar gateways.
• Dê aos administradores controle total sobre a implantação do gateway e também simplifique as operações. Quando um novo upgrade está disponível ou uma configuração é alterada, os administradores atualizam os pods de gateway simplesmente reiniciando-os. Isso torna a experiência de operação de uma implantação de gateway a mesma que operando proxies sidecar para seus serviços.

Implantar gateways

Para oferecer suporte aos usuários com ferramentas de implantação atuais, o Cloud Service Mesh é compatível com as mesmas maneiras de implantar um gateway que o Istio: IstioOperator, Helm e YAML do Kubernetes. Cada método produz o mesmo resultado. Embora seja possível escolher o método com o qual você está mais familiarizado, recomendamos usar o método YAML do Kubernetes porque é mais fácil de modificar e você pode armazenar manifestos hidratados no controle de origem.

1. Crie um namespace para o gateway, se você ainda não tiver um. Substitua GATEWAY_NAMESPACE pelo nome do namespace.

   kubectl create namespace GATEWAY_NAMESPACE
   

2. Para ativar a injeção automática, rotule os namespaces com os rótulos de injeção padrão se a tag padrão estiver configurada ou com o rótulo de revisão ao namespace. O rótulo adicionado depende de você ter implantado o Cloud Service Mesh gerenciado ou instalado o plano de controle no cluster. O rótulo é usado pelo webhook do injetor do arquivo secundário para associar os arquivos secundários injetados a uma revisão específica do plano de controle.

   Selecione a guia abaixo de acordo com o tipo de instalação (gerenciada ou em cluster).

   Gerenciado

   Use o seguinte comando para localizar os canais de lançamento disponíveis:

   kubectl -n istio-system get controlplanerevision
   

   O resultado será assim:

   NAME                AGE
   asm-managed         6d7h
   asm-managed-rapid   6d7h
   

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

   No cluster

   Para planos de controle no cluster, o Serviço e a Implantação istiod costumam ter um rótulo de revisão semelhante a istio.io/rev=asm-1233-2, em que asm-1233-2 identifica a versão do Cloud Service Mesh. A revisão se torna parte do nome do serviço istiod. Por exemplo, istiod-asm-1233-2.istio-system.

   Use o comando a seguir para localizar o rótulo de revisão em istiod para o plano de controle no cluster:

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

3. Ativar o namespace para injeção. Substitua REVISION pelo valor do rótulo de revisão.

   Observação: é possível substituir istio.io/rev pelo rótulo istio-injection=enabled se a tag padrão for configurada. Verifique se a tag padrão existe executando istioctl tag list com o istioctl em OUTPUT_DIR.

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

4. Se você instalou o Cloud Service Mesh usando asmcli, mude para o diretório especificado em --output_dir e, em seguida, cd no diretório samples.

   Importante: para garantir que você esteja no diretório samples correto, execute o comando ls para listar o conteúdo do diretório e confirmar se há um diretório gateways (que você vai acessar na próxima etapa) e um diretório online-boutique.

   Se você não instalou usando asmcli, copie os arquivos de configuração para os gateways pelo repositório anthos-service-mesh.

5. É possível implantar a configuração de exemplo do gateway localizada no diretório samples/gateways/ como ela 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 implantação, verifique se os novos serviços estão funcionando corretamente:

   kubectl get pod,service -n GATEWAY_NAMESPACE
   

   Verifique que a saída seja assim:

   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 precisam ser gerenciados como qualquer outro aplicativo do Kubernetes. As amostras no repositório anthos-service-mesh-packages são destinadas a orientação e um guia de início rápido, e você precisa personalizá-las de acordo com suas necessidades.

Seletores de gateway

Aplique uma configuração do gateway aos proxies istio-ingressgateway e istio-egressgateway para gerenciar o tráfego de entrada e saída da sua malha, permitindo especificar qual tráfego você quer inserir ou sair da malha. Os rótulos nos pods de uma implantação de gateway são usados pelos recursos de configuração do gateway, portanto, é importante que o seletor de gateway corresponda a esses rótulos.

Por exemplo, nas implantações acima, o rótulo istio=ingressgateway é definido nos pods de gateway. Para aplicar uma configuração de gateway a essas implantações, você precisa selecionar o mesmo rótulo:

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

Para um exemplo de configuração de gateway e serviço virtual, consulte frontend.yaml no aplicativo de amostra Online Boutique.

Fazer upgrade de gateways

Upgrades no local

Para a maioria dos casos de uso, faça upgrade dos gateways seguindo o padrão de upgrade no local. Como os gateways usam a injeção de pod, novos pods criados serão automaticamente injetados com a configuração mais recente, que inclui a versão.

Se você quiser alterar a revisão do plano de controle em uso pelo gateway, defina o identificador istio.io/rev na implantação do gateway, que também acionará uma reinicialização contínua.

Plano de controle gerenciado

Como o Google gerencia os upgrades do plano de controle gerenciado, basta reiniciar a implantação do gateway. Os novos pods serão injetados automaticamente com a configuração e versão mais recentes.

kubectl rollout restart deployment istio-ingressgateway \
  -n GATEWAY_NAMESPACE

Plano de controle no cluster

Para aplicar o mesmo padrão aos gateways quando você tiver o plano de controle no cluster, será necessário alterar a revisão do plano de controle em uso pelo gateway. Defina o identificador istio.io/rev na implantação do gateway que acionará uma reinicialização gradual. As etapas necessárias dependem de você precisar atualizar o identificador de revisão no namespace e/ou no pod de gateway.

• Se você identificou o namespace para injeção, defina o identificador istio.io/rev no namespace como o novo valor da revisão:

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

• Se você ativou a injeção apenas para o pod do gateway, defina o identificador istio.io/rev na implantação com o novo valor de revisão, como o seguinte arquivo 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
  

  Observação: se image não for atualizado automaticamente com a imagem de proxy real do Cloud Service Mesh, o contêiner não será encontrado e um erro vai ocorrer. Consulte Resolver problemas de gateways para saber as próximas etapas.

Upgrades canário (avançado)

Se você estiver usando o plano de controle no cluster e quiser controlar mais lentamente o lançamento de uma nova revisão, é possível seguir o padrão de upgrade canário. É possível executar várias versões de uma implantação de gateway e garantir que tudo funcione conforme o esperado com um subconjunto de seu tráfego. Por exemplo, se você quiser implantar uma nova revisão, o canário, crie uma cópia da implantação de gateway com o rótulo istio.io/rev=REVISION definido 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

Observação: se image não for atualizado automaticamente com a imagem de proxy real do Cloud Service Mesh, o contêiner não será encontrado e um erro vai ocorrer. Consulte Resolver problemas de gateways para saber as próximas etapas.

Quando essa implantação for criada, você terá 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 será assim:

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

Observação: ao contrário dos serviços de aplicativos implantados na malha, não é possível usar a alteração de tráfego do Istio para distribuir o tráfego entre as versões de gateway, porque o tráfego vem diretamente de clientes externos que o Istio não controla. Em vez disso, é possível controlar a distribuição do tráfego pelo número de réplicas de cada implantação. Se você usar outro balanceador de carga na frente do Istio, também será possível usá-lo para controlar a distribuição de tráfego.

Se o aplicativo estiver funcionando conforme o esperado, execute este comando para fazer a transição para a nova versão excluindo a implantação com o antigo conjunto de rótulos istio.io/rev:

kubectl delete deploy/istio-ingressgateway -n GATEWAY_NAMESPACE

Se você encontrar um problema ao testar seu aplicativo com a nova versão do gateway, execute este comando para fazer a transição de volta para a versão antiga excluindo a implantação com o novo conjunto de rótulos istio.io/rev:

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

Configuração avançada

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

Para a versão 1.14 e posterior do Cloud Service Mesh, a versão mínima de TLS padrão para servidores de gateway é 1.2. É possível configurar a versão mínima de TLS usando o campo minProtocolVersion. Para mais informações, consulte ServerTLSSettings.

Resolver problemas de gateways

Falha ao atualizar a imagem do gateway de auto

Ao implantar ou fazer upgrade de um gateway, o Cloud Service Mesh insere auto como um marcador no campo image. Após a chamada para modificar o webhook, o Cloud Service Mesh substitui automaticamente esse marcador pela imagem real do proxy do Cloud Service Mesh. Se a chamada para modificar o webhook falhar, o marcador auto permanecerá e o contêiner não será encontrado. Isso geralmente é causado por um rótulo de namespace incorreto. Verifique se você configurou o namespace correto e implante ou faça upgrade do gateway novamente.