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
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 Anthos 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 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.
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
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 Anthos 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 Anthos 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 aistio.io/rev=asm-1157-23
, em queasm-1157-23
identifica a versão do Anthos Service Mesh. A revisão se torna parte do nome do serviçoistiod
. Por exemplo,istiod-asm-1157-23.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"}'
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
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óriosamples
.Se você não instalou usando
asmcli
, copie os arquivos de configuração para os gateways pelo repositórioanthos-service-mesh
.É 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
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.
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
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 a versão 1.14 e posterior do Anthos 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 Anthos Service Mesh insere auto
como um
marcador no campo image
. Após a chamada para modificação do webhook,
o Anthos Service Mesh substitui automaticamente esse marcador pela imagem
real do proxy do Anthos 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.