Versão1.11

Como instalar e fazer upgrade de gateways

O Anthos 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 de 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

  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 injeção automática de sidecar (injeção automática) para injetar a configuração de proxy para os gateways, assim como você usa para 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.
  • Concede aos administradores controle total sobre a implantação do gateway e também simplifica 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 Anthos 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. Ative a injeção automática no gateway aplicando um rótulo de revisão no namespace do gateway. O rótulo de revisão é usado pelo webhook do injetor do arquivo secundário para associar os proxies injetados a uma revisão específica do plano de controle. O rótulo de revisão usado depende da implantação do plano de controle gerenciado pelo Google ou do plano de controle no cluster.

    Gerenciada pelo Google

    Para o plano de controle gerenciado pelo Google, o rótulo de revisão corresponde a um canal de lançamento:

    Rótulo de revisão Channel
    istio.io/rev=asm-managed Normal
    istio.io/rev=asm-managed-rapid Rápido
    istio.io/rev=asm-managed-stable Canal Stable

    O namespace do gateway pode estar no mesmo canal de lançamento que os serviços ou em um canal de lançamento diferente. Recomendamos que você use o mesmo canal de lançamento em um cluster. Para ver qual canal de lançamento o namespace está usando:

    kubectl get namespace NAMESPACE -L istio.io/rev
    

    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-1112-17, em que asm-1112-17 identifica a versão do Anthos Service Mesh. A revisão se torna parte do nome do serviço istiod. Por exemplo, istiod-asm-1112-17.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.

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

    Você pode ignorar a mensagem "istio-injection not found" na saída. Isso significa que o namespace não tinha o rótulo istio-injection anteriormente, que é esperado em novas instalações do Anthos Service Mesh ou em novas implantações. Como a injeção automática falha se um namespace tiver o istio-injection e o rótulo de revisão, todos os comandos kubectl label na documentação do Anthos Service Mesh incluem a remoção do rótulo istio-injection

  4. Se você usou asmcli para instalar o Anthos Service Mesh, mude para o diretório especificado em --output_dir e, em seguida, cd no diretório samples. Se você não instalou usando asmcli, copie os arquivos de configuração para os gateways do 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 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 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

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 o tráfego que 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.

Como 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 rótulo istio.io/rev na implantação do gateway, que também acionará uma reinicialização contínua.

Plano de controle gerenciado pelo Google
Como o Google gerencia os upgrades do plano de controle gerenciado pelo Google, basta reiniciar a implantação do gateway. Os novos pods serão injetados automaticamente com o 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 rótulo istio.io/rev na implantação do gateway que acionará uma reinicialização contínua.

  1. Atualize o rótulo de revisão no namespace ou no pod do gateway.
    • Se você rotulou o namespace para injeção:
    • Defina o rótulo istio.io/rev no namespace como o novo valor de revisão
kubectl label namespace GATEWAY_NAMESPACE \
  istio-injection- istio.io/rev=REVISION \
  --overwrite

OU

  • Se você ativou a injeção apenas para o pod do gateway:
    • Defina o rótulo istio.io/rev na implantação como o novo valor de revisão.
      • 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

Upgrades Canary (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

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

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