Como instalar e fazer upgrade de gateways com as APIs do Istio

Observação :este guia só oferece suporte ao Cloud Service Mesh com APIs do Istio e que não são compatíveis com as APIs do Google Cloud. Para mais informações, consulte Visão geral do Cloud Service Mesh.

O Cloud Service Mesh oferece a opção de implantar e gerenciar gateways como parte do a malha de serviço. Um gateway descreve um balanceador de carga que opera na borda da malha e recebe conexões HTTP/TCP de entrada ou saída. Os gateways são usados principalmente para gerenciar o tráfego de entrada, mas também é possível configurá-los para gerenciar outros tipos de tráfego.

• 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 precisam acessar redes externas ou permitir o controle seguro do tráfego de saída para adicionar a segurança da malha, por exemplo.

• Gateways de entrada: um gateway de entrada permite configurar um nó de entrada dedicado para receber conexões HTTP/TCP de entrada.

• Gateways leste-oeste: um proxy para leste-oeste para permitir que 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.

É possível implantar gateways de diferentes maneiras e usar mais de uma topologia dentro do 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 reiniciando-os. Isso torna a experiência de operar uma implantação de gateway igual à a operação de proxies sidecar para seus serviços.

Implantar gateway de amostra

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.

As etapas a seguir mostram como implantar um gateway de exemplo.

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. Ativar o namespace para injeção. As etapas dependem da implementação do plano de controle.

   Gerenciado (TD)

   1. Aplique o rótulo de injeção padrão ao namespace:

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

   Gerenciado (Istiod)

   Recomendado:execute o seguinte comando para aplicar o rótulo de injeção padrão ao namespace:

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

   Se você já for usuário do plano de controle do Istiod gerenciado: recomendamos que você use a injeção padrão, mas a injeção baseada em revisão é compatível. Siga estas instruções:

   1. Execute 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-rapid   6d7h
      

      OBSERVAÇÃO: se duas revisões do plano de controle aparecerem na lista acima, remova uma. Não é possível ter vários canais de plano de controle no cluster.

      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.

   2. Aplique o rótulo de revisão ao namespace:

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

   No cluster

   Recomendado: execute o comando a seguir para aplicar o rótulo de injeção padrão ao namespace:

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

   Recomendamos que você use a injeção padrão, mas a injeção baseada em revisão é compatível: Siga estas instruções:

   1. Use o seguinte comando para localizar o rótulo 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 o rótulo de revisão ao namespace. No comando a seguir, REVISION_LABEL é o valor do rótulo de revisão istiod que você anotou na etapa anterior.

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

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

4. Altere seu diretório para o diretório samples. Para garantir que você esteja diretório correto, execute o comando ls para listar o conteúdo do diretório e Depois, confirme se há um diretório gateways (que você vai acessar na próxima etapa) e um diretório online-boutique.

5. Implante um gateway de entrada ou de saída. Eles estão localizados samples/gateways/ no estado em que se encontra ou modifique-o 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 implantação, verifique se os novos serviços estão funcionando corretamente:

   kubectl get pod,service -n GATEWAY_NAMESPACE
   

   Verifique se a saída é semelhante a esta:

   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

Gerencie os recursos do gateway como qualquer outro aplicativo do Kubernetes. As amostras no repositório anthos-service-mesh-packages servem para orientação e um guia de início rápido. Personalize-os de acordo com suas necessidades.

Seletores de gateway

Você aplica uma Gateway a configuração com os proxies istio-ingressgateway e istio-egressgateway para gerenciar o tráfego de entrada e saída da malha, permitindo especificar quais tráfego que você quer entrar 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 anteriores, 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 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
  

  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 o image não for atualizado automaticamente com o Cloud Service Mesh real imagem de proxy, o contêiner não será encontrado e ocorrerá um erro. Consulte Resolva 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"

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

Observação: diferentemente dos serviços de aplicativos implantados na malha, não é possível usar Mudança de tráfego do Istio para distribuir o tráfego entre as versões do gateway porque o tráfego deles vem diretamente de clientes externos que o Istio não são controladas. 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

No Cloud Service Mesh, a versão mínima padrão de TLS 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.

Recursos não suportados

Se você tiver uma TRAFFIC_DIRECTOR implementação de plano de controle, os seguintes campos ou valores no Gateway não serão compatíveis:

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

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 a modificação do webhook falhar, o auto permanece, e o contêiner não é encontrado. Isso geralmente é causado por um rótulo de namespace incorreto. Verifique se você configurou namespace e implantar ou fazer upgrade do gateway novamente.