Você está vendo a documentação da Service Mesh v1.22.

Versões disponíveis

Cloud Service Mesh
1.22 archive
1.21 archive
1.20 archive
1.19 archive
1.18 archive

Esta página foi traduzida pela API Cloud Translation.

Como instalar e fazer upgrade de gateways com APIs do Istio

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 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 devem acessar redes externas ou ativar o controle seguro do tráfego de saída para adicionar segurança à sua 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 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.

É 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

Ative o plano de dados gerenciado.
Adicionar um rótulo de revisão gerenciado a um namespace.
Implante e gerencie o plano de controle e os gateways separadamente.
Como prática recomendada de segurança, recomendamos implantar gateways em um namespace diferente do plano de controle.
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

Implante e gerencie o plano de controle e os gateways separadamente.
Como prática recomendada de segurança, recomendamos implantar gateways em um namespace diferente do plano de controle.
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 operação de uma implantação de gateway a mesma que operar proxies sidecar para seus serviços.

Implantar gateway de exemplo

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.

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
```
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 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
```
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 tem suporte: 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
Copie os arquivos de configuração dos gateways de exemplo do repositório anthos-service-mesh.
Mude o diretório para samples. Para garantir que você esteja no diretório correto, execute o comando ls para listar o conteúdo do diretório e confirme se há um diretório gateways (que você vai acessar na próxima etapa) e um diretório online-boutique.
Implante um gateway de entrada ou de saída. Eles estão localizados no diretório samples/gateways/ como estão ou podem ser modificados 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
```

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

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 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

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

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

Configuração avançada

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

Para o 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.

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 modificar o webhook falhar, o marcador de posição 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.