Atualizações de configuração para modernização
Este documento descreve as atualizações de configuração que talvez sejam necessárias para o
Cloud Service Mesh gerenciado antes de modernizar sua malha para o
plano de controle TRAFFIC_DIRECTOR
do plano de controle
ISTIOD
.
Confira abaixo uma lista de possíveis atualizações de configuração necessárias para preparar seu cluster para modernização. Consulte cada seção para conferir as instruções de atualização:
- Multi-cluster
- Ativar a federação de identidade da carga de trabalho para o GKE
- Ativar a CNI gerenciada
- Uso binário não padrão no sidecar
- Migrar para o Istio Ingress Gateway
Para mais informações sobre o fluxo de trabalho de modernização, consulte a página Modernização do plano de controle gerenciado.
Migrar de chaves secretas do Istio para multicluster_mode
Os secrets de vários clusters não são compatíveis quando um cluster usa o plano de controle TRAFFIC_DIRECTOR
. Neste documento, descrevemos como modernizar o uso de secrets de vários clusters do Istio para multicluster_mode
.
Visão geral das chaves secretas do Istio x API declarativa
A descoberta de endpoints multi-cluster do Istio de código aberto funciona usando istioctl
ou outras ferramentas para criar um secret do Kubernetes em um cluster. Esse secret permite que um cluster faça o balanceamento de carga do tráfego para outro cluster
na malha. O plano de controle do ISTIOD
lê esse
secret e começa a rotear o tráfego para o outro cluster.
O Cloud Service Mesh tem uma API declarativa para controlar o tráfego entre vários clusters em vez de criar segredos do Istio diretamente. Essa API trata os secrets do Istio como um detalhe de implementação e é mais confiável do que criar secrets do Istio manualmente. Os futuros recursos do Cloud Service Mesh vão depender da API declarativa, e não será possível usar esses novos recursos diretamente com os secrets do Istio. A API declarativa é o único caminho compatível.
Se você estiver usando secrets do Istio, migre para a API declarativa
assim que possível. A configuração multicluster_mode
direciona cada cluster para direcionar o tráfego a todos os outros clusters na malha. O uso de secrets permite uma
configuração mais flexível, permitindo que você configure para cada cluster qual outro
cluster ele deve direcionar o tráfego na malha.
Para uma lista completa das diferenças entre os recursos compatíveis da API declarativa e os secrets do Istio, consulte Recursos compatíveis usando APIs do Istio.
Migrar de chaves secretas do Istio para a API declarativa
Se você provisionou o Cloud Service Mesh usando o gerenciamento automático com a
API de recursos da frota, não
é necessário seguir estas instruções.
Estas etapas só se aplicam se você fez a integração usando asmcli --managed
.
Observação: esse processo muda os secrets que apontam para um cluster. Durante esse processo, os endpoints são removidos e adicionados novamente. Entre a remoção e a adição dos endpoints, o tráfego vai voltar brevemente ao roteamento local em vez do balanceamento de carga para outros clusters. Para mais informações, consulte o problema no GitHub (em inglês).
Para migrar do uso de segredos do Istio para a API declarativa, siga estas etapas. Execute estas etapas ao mesmo tempo ou em seguida:
Ative a API declarativa para cada cluster na frota em que você quer ativar a descoberta de endpoints de vários clusters definindo
multicluster_mode=connected
. É necessário definir explicitamentemulticluster_mode=disconnected
se você não quiser que o cluster seja detectável.Use o comando a seguir para ativar um cluster para descoberta de endpoints de vários clusters:
kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'
Use o comando a seguir para desativar a descoberta de endpoints em um cluster:
kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'
Exclua os secrets antigos.
Depois de definir
multicluster_mode=connected
nos clusters, cada um deles terá um novo secret gerado para todos os outros que também tiveremmulticluster_mode=connected
definido. O secret é colocado no namespace istio-system e tem o seguinte formato:istio-remote-secret-projects-PROJECT_NAME-locations-LOCATION-memberships-MEMBERSHIPS
Cada secret também terá o rótulo
istio.io/owned-by: mesh.googleapis.com
aplicado.Depois que os novos secrets forem criados, você poderá excluir manualmente os secrets criados com
istioctl create-remote-secret
:kubectl delete secret SECRET_NAME -n istio-system
Depois da migração, verifique as métricas de solicitação para garantir que elas sejam encaminhadas conforme o esperado.
Ativar a federação de identidade da carga de trabalho do GKE
A federação de identidade da carga de trabalho é o método seguro recomendado para cargas de trabalho do Google Kubernetes Engine. Isso permite o acesso a serviços Google Cloud como Compute Engine, BigQuery e APIs de machine learning. A federação de identidade da carga de trabalho não exige configuração manual ou métodos menos seguros, como arquivos de chave da conta de serviço, porque usa políticas do IAM. Para mais detalhes sobre a federação de identidade da carga de trabalho, consulte Como funciona a federação de identidade da carga de trabalho para o GKE.
A seção a seguir descreve como ativar a federação de identidade da carga de trabalho.
Ativar a Federação de Identidade da Carga de Trabalho em clusters
Verifique se a federação de identidade da carga de trabalho está ativada no cluster. Para isso, verifique se o cluster do GKE tem um pool de federação de identidade da carga de trabalho configurado, o que é essencial para a validação de credenciais do IAM.
Use o comando a seguir para verificar o pool de identidades da carga de trabalho definido para um cluster:
gcloud container clusters describe CLUSTER_NAME \ --format="value(workloadIdentityConfig.workloadPool)"
Substitua
CLUSTER_NAME
pelo nome do cluster do GKE. Se você ainda não tiver especificado uma zona ou região padrão para o gcloud, talvez seja necessário especificar uma flag--region
ou--zone
ao executar este comando.Se a saída estiver vazia, siga as instruções em Atualizar um cluster atual para ativar a identidade da carga de trabalho em clusters do GKE.
Ativar a federação de identidade da carga de trabalho em pools de nós
Depois que a federação de identidade da carga de trabalho é ativada em um cluster, os pools de nós precisam ser configurados para usar o servidor de metadados do GKE.
Liste todos os pools de nós de um cluster Standard. Execute o comando gcloud container node-pools list:
gcloud container node-pools list --cluster CLUSTER_NAME
Substitua
CLUSTER_NAME
pelo nome do cluster do GKE. Se você ainda não tiver especificado uma zona ou região padrão para o gcloud, talvez seja necessário especificar uma flag--region
ou--zone
ao executar este comando.Verifique se cada pool de nós está usando o servidor de metadados do GKE:
gcloud container node-pools describe NODEPOOL_NAME \ --cluster=CLUSTER_NAME \ --format="value(config.workloadMetadataConfig.mode)"
Substitua:
NODEPOOL_NAME
pelo nome do pool de nós.CLUSTER_NAME
pelo nome do cluster do GKE.
Se a saída não contiver
GKE_METADATA
, atualize o pool de nós usando o guia Atualizar um pool de nós.
Ativar a interface de rede de contêiner gerenciada (CNI)
Nesta seção, mostramos como ativar a CNI gerenciada para o Cloud Service Mesh no Google Kubernetes Engine.
Visão geral da CNI gerenciada
A interface de rede de contêiner gerenciada (CNI) é uma implementação gerenciada pelo Google da
CNI do Istio. O plug-in CNI simplifica a rede de pods ao configurar regras de iptables. Isso permite o redirecionamento de tráfego entre aplicativos e proxies Envoy, eliminando a necessidade de permissões privilegiadas para o init-container necessário para gerenciar iptables
.
O plug-in CNI do Istio
substitui o contêiner istio-init
. Antes, o contêiner istio-init
era
responsável por configurar o ambiente de rede do pod para permitir a interceptação
de tráfego para o arquivo secundário do Istio. O plug-in CNI executa a mesma função de redirecionamento de rede, mas com o benefício adicional de reduzir a necessidade de privilégios elevados, aumentando assim a segurança.
Portanto, para aumentar a segurança e a confiabilidade e simplificar o gerenciamento e a solução de problemas, a CNI gerenciada é necessária em todas as implantações do Managed Cloud Service Mesh.
Impacto nos contêineres de inicialização
Os contêineres de inicialização são contêineres especializados que são executados antes dos contêineres de aplicativos para tarefas de configuração. As tarefas de configuração podem incluir o download de arquivos de configuração, a comunicação com serviços externos ou a inicialização pré-aplicativo. Os contêineres de inicialização que dependem do acesso à rede podem encontrar problemas quando a CNI gerenciada está ativada no cluster.
O processo de configuração de pods com CNI gerenciada é o seguinte:
- O plug-in da CNI configura interfaces de rede de pod, atribui IPs de pod e redireciona o tráfego para o proxy sidecar do Istio, que ainda não foi iniciado.
- Todos os contêineres de inicialização são executados e concluídos.
- O proxy sidecar do Istio é iniciado junto com os contêineres de aplicativos.
Portanto, se um contêiner de inicialização tentar fazer conexões de rede de saída ou se conectar a serviços na malha, as solicitações de rede dos contêineres de inicialização poderão ser descartadas ou encaminhadas incorretamente. Isso acontece porque o proxy sidecar do Istio, que gerencia o tráfego de rede do pod, não está em execução quando as solicitações são feitas. Para mais detalhes, consulte a documentação do CNI do Istio.
Ative a CNI gerenciada para o cluster
Siga as etapas desta seção para ativar o CNI gerenciado no cluster.
Remova as dependências de rede do contêiner de inicialização. Considere as seguintes alternativas:
- Modificar a lógica ou os contêineres do aplicativo:é possível modificar os serviços para remover a dependência de contêineres de inicialização que exigem solicitações de rede ou realizar operações de rede nos contêineres de aplicativos depois que o proxy sidecar for iniciado.
- Use ConfigMaps ou secrets do Kubernetes:armazene os dados de configuração buscados pela solicitação de rede em ConfigMaps ou secrets do Kubernetes e os monte nos contêineres de aplicativos. Para soluções alternativas, consulte a documentação do Istio.
Ative a CNI gerenciada no cluster:
Faça as seguintes mudanças de configuração:
Execute o comando a seguir para localizar o
controlPlaneRevision
.kubectl get controlplanerevision -n istio-system
No recurso personalizado (CR)
ControlPlaneRevision
(CPR), defina o rótulomesh.cloud.google.com/managed-cni-enabled
comotrue
.kubectl label controlplanerevision CPR_NAME \ -n istio-system mesh.cloud.google.com/managed-cni-enabled=true \ --overwrite
Substitua
CPR_NAME
pelo valor na coluna "NAME" da saída da etapa anterior.No ConfigMap asm-options, defina o valor
ASM_OPTS
comoCNI=on
.kubectl patch configmap asm-options -n istio-system \ -p '{"data":{"ASM_OPTS":"CNI=on"}}'
No recurso personalizado (CR)
ControlPlaneRevision
(CPR), defina o rótulomesh.cloud.google.com/force-reprovision
comotrue
. Essa ação aciona a reinicialização do plano de controle.kubectl label controlplanerevision CPR_NAME \ -n istio-system mesh.cloud.google.com/force-reprovision=true \ --overwrite
Verifique o estado do recurso. Recupere o estado do recurso usando o seguinte comando:
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
Substitua
FLEET_PROJECT_ID
pelo ID do projeto host da frota. Em geral, oFLEET_PROJECT_ID
tem o mesmo nome do projeto.- Verifique se a condição
MANAGED_CNI_NOT_ENABLED
foi removida deservicemesh.conditions
. - A atualização do estado pode levar de 15 a 20 minutos. Aguarde alguns minutos e execute o comando novamente.
- Verifique se a condição
Quando o
controlPlaneManagement.state
estiverActive
no estado do recurso do cluster, reinicie os pods.
Migrar do uso de binários não padrão no sidecar
Esta seção sugere maneiras de tornar suas implantações compatíveis com a imagem de proxy do Envoy sem distribuição.
Imagens de arquivo secundário do proxy Envoy distroless
O Cloud Service Mesh usa dois tipos de imagens secundárias de proxy do Envoy com base na sua configuração do plano de controle, uma imagem baseada no Ubuntu que contém vários binários e uma imagem sem distribuição. As imagens de base sem escala são imagens de contêiner mínimas que priorizam a segurança e a otimização de recursos, incluindo apenas componentes essenciais. A superfície de ataque é reduzida para ajudar a evitar vulnerabilidades. Para mais informações, consulte a documentação sobre a imagem de proxy sem distribuição.
Compatibilidade binária
Como prática recomendada, restrinja o conteúdo de um ambiente de execução do contêiner
apenas aos pacotes necessários. Essa abordagem melhora a segurança e a
proporção de sinal para ruído dos verificadores de vulnerabilidades e exposições comuns (CVEs, na sigla em inglês).
A imagem do sidecar sem distribuição tem um conjunto mínimo de dependências, sem todos os executáveis, bibliotecas e ferramentas de depuração não essenciais. Portanto, não é possível executar um comando de shell ou usar curl, ping ou outros utilitários de depuração, como kubectl exec
, no contêiner.
Tornar os clusters compatíveis com imagens sem distribuição
- Remova referências a binários sem suporte (como bash ou curl) da sua configuração. Principalmente dentro das sondagens de prontidão, inicialização e atividade e dos hooks PostStart e PreStop do ciclo de vida nos contêineres istio-proxy, istio-init ou istio-validation.
- Considere alternativas como holdApplicationUntilProxyStarts para determinados casos de uso.
- Para depuração, é possível usar contêineres temporários para anexar a um pod de carga de trabalho em execução. Depois, é possível inspecionar e executar comandos personalizados. Por exemplo, consulte Como coletar registros do Cloud Service Mesh.
Se você não encontrar uma solução para seu caso de uso específico, entre em contato com o suporte em Como receber suporte. Google Cloud
Migrar para o gateway de entrada do Istio
Nesta seção, mostramos como migrar para o gateway de entrada do Istio. Há dois métodos para migrar para o gateway de entrada do Istio:
Migração por etapas com divisão de tráfego
Esse método prioriza a minimização da interrupção, em que você envia o tráfego de forma incremental para o novo gateway do Istio, permitindo monitorar o desempenho em uma pequena porcentagem de solicitações e reverter rapidamente, se necessário. Configurar a divisão de tráfego da camada 7 pode ser difícil para alguns aplicativos. Por isso, é necessário gerenciar os dois sistemas de gateway simultaneamente durante a transição. Consulte Migração gradual com divisão de tráfego para conferir as etapas.
Migração direta
Esse método envolve o redirecionamento simultâneo de todo o tráfego para o novo gateway do Istio depois que você tiver realizado testes completos. A vantagem dessa abordagem é a separação completa da infraestrutura do gateway antigo, permitindo uma configuração adaptável do novo gateway sem as restrições da configuração atual. No entanto, há um risco maior de inatividade caso surjam problemas inesperados com o novo gateway durante a transição. Consulte Migração direta para conferir as etapas.
Os exemplos de migração a seguir pressupõem que você tenha um serviço HTTP (httpbin) em execução no namespace do aplicativo (padrão) e exposto externamente usando a API Gateway do Kubernetes. As configurações relevantes são:
- Gateway:
k8-api-gateway
(no namespaceistio-ingress
) – configurado para detectar tráfego HTTP na porta 80 para qualquer nome de host que termine com.example.com
. - HTTPRoute:
httpbin-route
(no namespacedefault
): direciona qualquer solicitação HTTP com o nome do hosthttpbin.example.com
e um caminho que começa com/get
para o serviçohttpbin
no namespacedefault
. - O aplicativo httpbin pode ser acessado usando o IP externo 34.57.246.68.
Migração por etapas com divisão de tráfego
Provisionar um novo gateway de entrada do Istio
Implante um novo gateway de entrada seguindo as etapas na seção "Implantar gateway de exemplo" e personalize as configurações de exemplo de acordo com seus requisitos. As amostras no repositório anthos-service-mesh (em inglês) são destinadas à implantação de um serviço
istio-ingressgateway
loadBalancer e dos podsingress-gateway
correspondentes.Exemplo de recurso de gateway (istio-ingressgateway.yaml)
apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: istio-api-gateway namespace: GATEWAY_NAMESPACE spec: selector: istio: ingressgateway # The selector should match the ingress-gateway pod labels. servers: - port: number: 80 name: http protocol: HTTP hosts: # or specific hostnames if needed - "httpbin.example.com"
Aplique a configuração do Gateway para gerenciar o tráfego:
kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE
Verifique se o "spec.selector" no recurso de gateway corresponde aos rótulos dos pods
ingress-gateway
. Por exemplo, se os podsingress-gateway
tiverem o rótuloistio=ingressgateway
, a configuração do gateway também precisará selecionar o rótuloistio=ingressgateway
.
Configurar o roteamento inicial para o novo gateway
Defina as regras de roteamento iniciais para seu aplicativo usando um VirtualService do Istio.
Exemplo de VirtualService (my-app-vs-new.yaml):
apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: httpbin-vs namespace: APPLICATION_NAMESPACE spec: gateways: - istio-ingress/istio-api-gateway # Replace with <gateway-namespace/gateway-name> hosts: - httpbin.example.com http: - match: - uri: prefix: /get route: - destination: host: httpbin port: number: 8000
Aplique o VirtualService:
kubectl apply -f my-app-vs-new.yaml -n MY_APP_NAMESPACE
Acesse o serviço de back-end (httpbin) pelo gateway de entrada do Istio recém-implantado.
Defina a variável de ambiente Ingress Host como o endereço IP externo associado ao balanceador de carga
istio-ingressgateway
implantado recentemente:export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
Verifique se o aplicativo (httpbin) pode ser acessado usando o novo gateway:
curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
A saída é semelhante a:
HTTP/1.1 200 OK
Modificar Entrada atual para divisão de tráfego
Depois de confirmar a configuração bem-sucedida do novo gateway (por exemplo, istio-api-gateway), comece a rotear uma parte do tráfego por ele. Para fazer isso, atualize sua HTTPRoute atual para direcionar uma pequena porcentagem do tráfego ao novo gateway, enquanto a maior parte continua usando o gateway atual (k8-api-gateway).
Abra o httproute para edição:
kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE
Adicione uma nova referência de back-end apontando para o serviço de balanceador de carga do novo gateway de entrada com um peso inicial de 10% e atualize o peso do back-end do gateway antigo.
apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: httpbin-route namespace: MY_APP_NAMESPACE # your application's namespace spec: parentRefs: - name: k8-api-gateway namespace: istio-ingress hostnames: ["httpbin.example.com"] rules: - matches: - path: type: PathPrefix value: /get backendRefs: - name: httpbin port: 8000 weight: 90 - name: istio-ingressgateway # Newly deployed load balancer service namespace: GATEWAY_NAMESPACE port: 80 weight: 10
Conceder permissão para referências entre namespaces com concessão de referência.
Para permitir que seu
HTTPRoute
no namespace do aplicativo (padrão) acesse o serviçoloadbalancer
no namespace do gateway (istio-ingress), talvez seja necessário criar uma permissão de referência. Esse recurso serve como um controle de segurança, definindo explicitamente quais referências entre namespaces são permitidas.O
istio-ingress-grant.yaml
a seguir descreve um exemplo de concessão de referência:apiVersion: gateway.networking.k8s.io/v1beta1 kind: ReferenceGrant metadata: name: istio-ingressgateway-grant namespace: istio-ingress # Namespace of the referenced resource spec: from: - group: gateway.networking.k8s.io kind: HTTPRoute namespace: MY_APP_NAMESPACE # Namespace of the referencing resource to: - group: "" # Core Kubernetes API group for Services kind: Service name: istio-ingressgateway # Loadbalancer Service of the new ingress gateway
Aplique a concessão de referência:
kubectl apply -f istio-ingress-grant.yaml -n GATEWAY_NAMESPACE
Verifique as solicitações para o endereço IP externo atual (por exemplo, 34.57.246.68) não estão falhando. O
check-traffic-flow.sh
a seguir descreve um script para verificar falhas de solicitação:# Update the following values based on your application setup external_ip="34.57.246.68" # Replace with existing external IP url="http://$external_ip/get" host_name="httpbin.example.com" # Counter for successful requests success_count=0 # Loop 50 times for i in {1..50}; do # Perform the curl request and capture the status code status_code=$(curl -s -HHost:"$host_name" -o /dev/null -w "%{http_code}" "$url") # Check if the request was successful (status code 200) if [ "$status_code" -eq 200 ]; then ((success_count++)) # Increment the success counter else echo "Request $i: Failed with status code $status_code" fi done # After the loop, check if all requests were successful if [ "$success_count" -eq 50 ]; then echo "All 50 requests were successful!" else echo "Some requests failed. Successful requests: $success_count" fi
Execute o script para confirmar que nenhuma solicitação falha, independente da rota de tráfego:
chmod +x check-traffic-flow.sh ./check-traffic-flow.sh
Aumentar lentamente a porcentagem de tráfego
Se não houver falhas de solicitação para o endereço IP externo atual (por exemplo, 34.57.246.68
), transfira gradualmente mais tráfego para o novo gateway de entrada do Istio ajustando os pesos de back-end em HTTPRoute
. Aumente o peso do istio-ingressgateway
e diminua o peso do gateway antigo em pequenos incrementos, como 10%, 20% e assim por diante.
Use o comando a seguir para atualizar seu HTTPRoute
:
kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE
Migração completa do tráfego e remoção do gateway antigo
Quando o novo gateway de entrada do Istio demonstrar performance estável e processamento de solicitações bem-sucedido, transfira todo o tráfego para ele. Atualize seu
HTTPRoute
para definir o peso do back-end do gateway antigo como0
e o do novo como100
.Quando o tráfego for totalmente roteado para o novo gateway, atualize os registros DNS externos para o nome do host do aplicativo (por exemplo,
httpbin.example.com
) para apontar para o endereço IP externo do serviço de balanceador de carga criado em Provisionar um novo gateway de entrada do Istio.Por fim, exclua o gateway antigo e os recursos associados:
kubectl delete gateway OLD_GATEWAY -n GATEWAY_NAMESPACE kubectl delete service OLD_GATEWAY_SERVICE -n GATEWAY_NAMESPACE
Migração direta
Provisionar um novo gateway de entrada do Istio
Implante um novo gateway de entrada seguindo as etapas na seção "Implantar gateway de exemplo" e personalize as configurações de exemplo de acordo com seus requisitos. As amostras no repositório anthos-service-mesh (em inglês) são destinadas à implantação de um serviço
istio-ingressgateway
loadBalancer e dos podsingress-gateway
correspondentes.Exemplo de recurso de gateway (istio-ingressgateway.yaml)
apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: istio-api-gateway namespace: GATEWAY_NAMESPACE spec: selector: istio: ingressgateway # The selector should match the ingress-gateway pod labels. servers: - port: number: 80 name: http protocol: HTTP hosts: # or specific hostnames if needed - "httpbin.example.com"
Aplique a configuração do Gateway para gerenciar o tráfego:
kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE
Verifique se o "spec.selector" no recurso de gateway corresponde aos rótulos dos pods
ingress-gateway
. Por exemplo, se os podsingress-gateway
tiverem o rótuloistio=ingressgateway
, a configuração do gateway também precisará selecionar o rótuloistio=ingressgateway
.
Configurar o roteamento inicial para o novo gateway
Defina as regras de roteamento iniciais para seu aplicativo usando um VirtualService do Istio.
Exemplo de VirtualService (my-app-vs-new.yaml):
apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: httpbin-vs namespace: APPLICATION_NAMESPACE spec: gateways: - istio-ingress/istio-api-gateway # Replace with <gateway-namespace/gateway-name> hosts: - httpbin.example.com http: - match: - uri: prefix: /get route: - destination: host: httpbin port: number: 8000
Aplique o VirtualService:
kubectl apply -f my-app-vs-new.yaml -n MY_APP_NAMESPACE
Acesse o serviço de back-end (httpbin) pelo gateway de entrada do Istio recém-implantado.
Defina a variável de ambiente Ingress Host como o endereço IP externo associado ao balanceador de carga
istio-ingressgateway
implantado recentemente:export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
Verifique se o aplicativo (httpbin) pode ser acessado usando o novo gateway:
curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
A saída é semelhante a:
HTTP/1.1 200 OK
Testar e monitorar o novo gateway
Teste todas as regras de roteamento, valide a configuração de TLS, as políticas de segurança e outros recursos. Realize testes de carga para verificar se o novo gateway consegue processar o tráfego esperado.
Depois que o novo gateway for totalmente testado, atualize os registros DNS externos para o nome do host do aplicativo (por exemplo,
httpbin.example.com
) para apontar para o endereço IP externo do serviço de balanceador de carga criado em Provisionar um novo gateway de entrada do Istio.Monitore as principais métricas, como taxa de sucesso de solicitações, latência, taxas de erro e a utilização de recursos dos pods de aplicativos para verificar a estabilidade com o novo Istio Ingress Gateway. Quando estiver estável, você poderá excluir o gateway antigo e os recursos associados a ele.
kubectl delete gateway OLD_GATEWAY -n GATEWAY_NAMESPACE kubectl delete service OLD_GATEWAY_SERVICE -n GATEWAY_NAMESPACE
Considerações importantes: verifique se os certificados e as configurações TLS estão configurados corretamente no novo gateway de entrada do Istio se o aplicativo exigir HTTPS. Consulte Configurar o término de TLS no gateway de entrada para mais detalhes.