Configurar o balanceador de carga de aplicativo clássico para o Cloud Service Mesh

Visualização — service mesh cloud gateway

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Visão geral

Este documento é ideal para usuários do Cloud Service Mesh que tenham plano de controle gerenciado do Istiod e quiser configurar balanceador de carga de aplicativo clássico como gateway de entrada. O balanceador de carga de aplicativo clássico também conhecido como balanceador de carga de aplicativo externo clássico.

Não use este documento se você for um novo usuário do Cloud Service Mesh. Novo os usuários são configurados automaticamente com o plano de controle gerenciado do Cloud Service Mesh. Você não poderá usar a configuração descrita neste documento com os Plano de controle gerenciado do Cloud Service Mesh

O Cloud Load Balancing oferece vários recursos de borda incluindo balanceamento de carga anycast global, balanceamento de carga Identity and Access Management, Cloud Next Generation Firewall e Sistema de detecção de intrusões do Cloud. O Cloud Service Mesh integra perfeitamente esses recursos de borda nas seguintes modelo de entrada da malha. O gateway de nuvem da malha de serviço fornece uma maneira unificada de configurar o gateway de entrada do Cloud Service Mesh com o Cloud Load Balancing simultaneamente pela API Kubernetes Gateway.

Em comparação com nosso guia do usuário anterior, Da borda à malha: como expor aplicativos de malha de serviço pelo Ingress do GKE, com o gateway de nuvem da malha de serviço, agora é possível implantar o modelo O recurso de gateway do Kubernetes, que simplifica o processo de implantação da nuvem e o balanceamento de carga hospedado em cluster.

Limitações de visualização

As seguintes limitações se aplicam à versão de pré-lançamento desse recurso:

• Não há suporte para gateways de vários clusters.
• clusters do Autopilot são não tem suporte.
• Somente o balanceador de carga clássico do aplicativo é compatível. O balanceador de carga de aplicativo externo global (também chamado de balanceador de carga avançado) e balanceador de carga de aplicativo interno.
• Tráfego entre o balanceador de carga de aplicativo clássico e a entrada do Cloud Service Mesh é criptografado usando TLS. No entanto, o balanceador de carga de aplicativo clássico não vai verificar o certificado fornecido pelo gateway de entrada do Cloud Service Mesh. Essa limitação se aplica a todos os usuários do balanceador de carga HTTP(S) do Google Cloud.
• Se os GatewayClasses do Cloud Service Mesh forem excluídos de um cluster, eles não serão reinstaladas automaticamente. No entanto, isso não vai afetar a usabilidade do recurso.
• A lógica de correspondência de rota não segue Especificações da API Gateway e corresponde na ordem de HTTPRoute. Isso mudará em versões futuras para seguir as especificações da API Gateway.

Requisitos

• Cloud Service Mesh gerenciado instalada em um cluster do Google Kubernetes Engine (GKE) com a versão 1.24 ou mais recente. Outros clusters do GKE Enterprise não são compatíveis.
• Apenas na versão v1beta1 da API Gateway do Kubernetes.

Pré-requisitos

• Ativar as APIs a seguir no projeto:

  • compute.googleapis.com
  • container.googleapis.com
  • certificatemanager.googleapis.com
  • serviceusage.googleapis.com

  gcloud services enable \
     compute.googleapis.com \
     container.googleapis.com \
     certificatemanager.googleapis.com \
     serviceusage.googleapis.com
  

Implantar o gateway da nuvem da malha de serviço em uma malha de cluster único

Nesta seção, mostramos como implantar um Recurso de gateway do Kubernetes, que implanta um balanceador de carga de aplicativo clássico e um gateway de entrada do Cloud Service Mesh.

Ativar a API Gateway com o Cloud Service Mesh gerenciado

1. Ative a API Gateway no cluster. O cluster do GKE precisa ser da versão 1.24 ou posterior.

2. Instalar Cloud Service Mesh gerenciado com rapid ou regular como canal de lançamento.

Implantar o recurso de gateway

Ao implantar o gateway de nuvem da malha de serviço, Os recursos de gateway são usados para implantar o Cloud Load Balancing e o Cloud Service Mesh para o gateway de entrada em uma única etapa. Observe que Os recursos do gateway do Kubernetes são diferente Gateway do Istio do Google Cloud.

Para mais informações sobre as diferenças, consulte Gateways do Kubernetes e gateways do Istio. Todo gateway do Kubernetes tem uma GatewayClass que indica o tipo e a recursos. gateway de nuvem da malha de serviço tem uma GatewayClass com a para implantar o gateway de entrada do Cloud Load Balancing e do Cloud Service Mesh.

1. Salve o seguinte manifesto GatewayClass em um arquivo chamado l7-gateway-class.yaml:

   apiVersion: gateway.networking.k8s.io/v1beta1
   kind: GatewayClass
   metadata:
     name: asm-l7-gxlb
   spec:
     controllerName: mesh.cloud.google.com/gateway
   

2. Implante o GatewayClass no cluster:

   kubectl apply -f l7-gateway-class.yaml
   

3. Verifique se o GatewayClass está presente após a instalação:

   kubectl get gatewayclasses.gateway.networking.k8s.io
   

   A resposta é semelhante a:

   NAME          CONTROLLER
   asm-l7-gxlb   mesh.cloud.google.com/gateway
   gke-l7-rilb   networking.gke.io/gateway
   gke-l7-gxlb   networking.gke.io/gateway
   

   A implantação de todos os recursos pode levar alguns minutos. Se você não o resultado esperado, verifique se você satisfez corretamente pré-requisitos.

   Você também vai ver o seguinte GatewayClass:

   gke-l7-gxlb   networking.gke.io/gateway
   

   Usado para implantar o balanceador de carga de aplicativo clássico do Google Cloud.

4. Crie um namespace dedicado para o gateway da nuvem da malha de serviço:

   kubectl create namespace istio-ingress
   

5. Salve o seguinte manifesto de gateway em um arquivo chamado gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: servicemesh-cloud-gw
     namespace: istio-ingress
   spec:
     gatewayClassName: asm-l7-gxlb
     listeners:
     - name: http
       protocol: HTTP
       port: 80
       allowedRoutes:
         namespaces:
           from: All
   

6. Implante o gateway no cluster no namespace istio-ingress:

   kubectl apply -f gateway.yaml
   

7. Verifique se os objetos da API Kubernetes Gateway foram criados:

   kubectl get gateways.gateway.networking.k8s.io -n istio-ingress
   

   A resposta é semelhante a:

   NAME                                CLASS         ADDRESS         READY   AGE
   asm-gw-gke-servicemesh-cloud-gw     gke-l7-gxlb   34.111.114.64   True    9m40s
   asm-gw-istio-servicemesh-cloud-gw   istio                                 9m44s
   servicemesh-cloud-gw                asm-l7-gxlb                           9m44s
   

Veja a seguir o que acontecerá quando esse objeto da API Kubernetes Gateway for implantado:

• Um balanceador de carga HTTP(S) externo é implantado e configurado. Pode levar alguns minutos para aparecer, mas, quando isso acontecer, o gateway indicará o endereço IP e será anotado com os nomes dos recursos do balanceador de carga do Compute Engine que foram criados.
• Uma implantação do gateway de entrada do Cloud Service Mesh é criada no arquivo istio-ingress . Isso cria as instâncias do proxy Envoy que receberão o tráfego dos de carga HTTP(S) externo global.
• O balanceador de carga vai criptografar e rotear todo o tráfego para a gateway de entrada do Cloud Service Mesh.

.

Aviso :no momento, é necessário ter pelo menos um arquivo secundário injetado para que o gateway de entrada do Cloud Service Mesh funcione corretamente.

Agora você tem a infraestrutura completa necessária para aceitar o tráfego da Internet na sua malha. Observe que essa é a implantação de gateway mais simples possível. Nas seções a seguir, você vai adicionar outras políticas e recursos que vão preparar a produção.

Implantação de apps e roteamento

Para demonstrar as capacidades, você vai implantar um aplicativo o Cloud Service Mesh e receber tráfego da Internet pelo gateway, por exemplo propósitos.

1. Identifique o namespace default para ativar a injeção de arquivo secundário.

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

2. Salve o seguinte manifesto de gateway em um arquivo chamado whereami.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: whereami-v1
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: whereami-v1
     template:
       metadata:
         labels:
           app: whereami-v1
       spec:
         containers:
         - name: whereami
           image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1.2.20
           ports:
             - containerPort: 8080
           env:
           - name: METADATA
             value: "whereami-v1"
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: whereami-v1
   spec:
     selector:
       app: whereami-v1
     ports:
     - port: 8080
       targetPort: 8080
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: whereami-v2
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: whereami-v2
     template:
       metadata:
         labels:
           app: whereami-v2
       spec:
         containers:
         - name: whereami
           image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1.2.20
           ports:
             - containerPort: 8080
           env:
           - name: METADATA
             value: "whereami-v2"
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: whereami-v2
   spec:
     selector:
       app: whereami-v2
     ports:
     - port: 8080
       targetPort: 8080
   

   Esse manifesto cria Service/whereami-v1, Service/whereami-v2, Deployment/whereami-v1 e Deployment/whereami-v2 para o whereami, um aplicativo simples que gera JSON para indicar a identidade e o local dele. Você implantará duas versões diferentes dele.

3. Crie os serviços e as implantações:

   kubectl apply -f whereami.yaml
   

   Depois que ele estiver em execução, você terá quatro pods whereami em execução no cluster.

4. Verifique se todos os quatro pods estão em execução:

   kubectl get pods
   

   A resposta é semelhante a:

   whereami-v1-7c76d89d55-qg6vs       2/2     Running   0          28s
   whereami-v1-7c76d89d55-vx9nm       2/2     Running   0          28s
   whereami-v2-67f6b9c987-p9kqm       2/2     Running   0          27s
   whereami-v2-67f6b9c987-qhj76       2/2     Running   0          27s
   

5. Salve o seguinte manifesto HTTPRoute em um arquivo chamado http-route.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: where-route
   spec:
    parentRefs:
    - kind: Gateway
      name: servicemesh-cloud-gw
      namespace: istio-ingress
    hostnames:
    - "where.example.com"
    rules:
    - matches:
      - headers:
        - name: version
          value: v2
      backendRefs:
      - name: whereami-v2
        port: 8080
    - backendRefs:
      - name: whereami-v1
        port: 8080
   

6. Implante http-route.yaml no cluster:

   kubectl apply -f http-route.yaml
   

   Esse HTTPRoute faz referência ao servicemesh-cloud-gw, o que significa que ele configurar o gateway de nuvem da malha de serviço para que ele configure o Cloud Service Mesh subjacente gateway de entrada com essas regras de roteamento. O HTTPRoute executa a mesma funciona como o VirtualService do Istio, mas usa a API Kubernetes Gateway para faça isso. Como a API Gateway é uma especificação OSS com muitos implementações, é a API mais adequada para definir o roteamento em uma de balanceadores de carga diferentes (como proxies do Cloud Service Mesh e balanceadores de carga de rede).

7. Recuperar o endereço IP do gateway para enviar tráfego ao aplicativo:

   VIP=$(kubectl get gateways.gateway.networking.k8s.io asm-gw-gke-servicemesh-cloud-gw -o=jsonpath="{.status.addresses[0].value}" -n istio-ingress)
   

   A saída é um endereço IP.

   echo $VIP
   
   34.111.61.135
   

8. Envie tráfego para o endereço IP do gateway para validar se essa configuração funciona corretamente. Envie uma solicitação com o cabeçalho version: v2 e outra sem para determinar se o roteamento é feito corretamente nas duas versões do aplicativo.

   Observação: isso pode levar até 10 minutos. Caso contrário, você verá o erro Empty reply from server ou Connection reset by peer

   curl ${VIP} -H "host: where.example.com"
   
   {
     "cluster_name": "gke1",
     "host_header": "where.example.com",
     "metadata": "whereami-v1",
     "node_name": "gke-gke1-default-pool-9b3b5b18-hw5z.c.church-243723.internal",
     "pod_name": "whereami-v1-67d9c5d48b-zhr4l",
     "pod_name_emoji": "⚒",
     "project_id": "church-243723",
     "timestamp": "2021-02-08T18:55:01",
     "zone": "us-central1-a"
   }
   
   curl ${VIP} -H "host: where.example.com" -H "version: v2"
   
   {
     "cluster_name": "gke1",
     "host_header": "where.example.com",
     "metadata": "whereami-v2",
     "node_name": "gke-gke1-default-pool-9b3b5b18-hw5z.c.church-243723.internal",
     "pod_name": "whereami-v2-67d9c5d48b-zhr4l",
     "pod_name_emoji": "⚒",
     "project_id": "church-243723",
     "timestamp": "2021-02-08T18:55:01",
     "zone": "us-central1-a"
   }
   

Implantação do gateway de produção

A seção anterior mostrou um exemplo muito simples de gateway da nuvem da malha de serviço. As etapas a seguir se baseiam no exemplo simples para mostrar uma configuração pronta para produção que demonstra as vantagens de delegar parte do roteamento de entrada para o balanceador de carga de aplicativo clássico.

Não use este documento se você for um novo usuário do Cloud Service Mesh. Novo os usuários são configurados automaticamente com o plano de controle gerenciado do Cloud Service Mesh. Você não poderá usar a configuração descrita neste documento com os Plano de controle gerenciado do Cloud Service Mesh

O Cloud Load Balancing oferece vários recursos de borda incluindo balanceamento de carga anycast global, balanceamento de carga Identity and Access Management, Cloud Next Generation Firewall e Sistema de detecção de intrusões do Cloud. O Cloud Service Mesh integra perfeitamente esses recursos de borda nas seguintes modelo de entrada da malha. O gateway de nuvem da malha de serviço fornece uma maneira unificada de configurar o gateway de entrada do Cloud Service Mesh com o Cloud Load Balancing simultaneamente pela API Kubernetes Gateway.

Em comparação com nosso guia do usuário anterior, Da borda à malha: como expor aplicativos de malha de serviço pelo Ingress do GKE, com o gateway de nuvem da malha de serviço, agora é possível implantar o modelo O recurso de gateway do Kubernetes, que simplifica o processo de implantação da nuvem e o balanceamento de carga hospedado em cluster.

Limitações de visualização

As seguintes limitações se aplicam à versão de pré-lançamento desse recurso:

• Não há suporte para gateways de vários clusters.
• clusters do Autopilot são não tem suporte.
• Somente o balanceador de carga clássico do aplicativo é compatível. O balanceador de carga de aplicativo externo global (também chamado de balanceador de carga avançado) e balanceador de carga de aplicativo interno.
• Tráfego entre o balanceador de carga de aplicativo clássico e a entrada do Cloud Service Mesh é criptografado usando TLS. No entanto, o balanceador de carga de aplicativo clássico não vai verificar o certificado fornecido pelo gateway de entrada do Cloud Service Mesh. Essa limitação se aplica a todos os usuários do balanceador de carga HTTP(S) do Google Cloud.
• Se os GatewayClasses do Cloud Service Mesh forem excluídos de um cluster, eles não serão reinstaladas automaticamente. No entanto, isso não vai afetar a usabilidade do recurso.
• A lógica de correspondência de rota não segue Especificações da API Gateway e corresponde na ordem de HTTPRoute. Isso mudará em versões futuras para seguir as especificações da API Gateway.

Requisitos

• Cloud Service Mesh gerenciado instalada em um cluster do Google Kubernetes Engine (GKE) com a versão 1.24 ou mais recente. Outros clusters do GKE Enterprise não são compatíveis.
• Apenas na versão v1beta1 da API Gateway do Kubernetes.

Pré-requisitos

• Ativar as APIs a seguir no projeto:

  • compute.googleapis.com
  • container.googleapis.com
  • certificatemanager.googleapis.com
  • serviceusage.googleapis.com

  gcloud services enable \
     compute.googleapis.com \
     container.googleapis.com \
     certificatemanager.googleapis.com \
     serviceusage.googleapis.com
  

Implantar o gateway da nuvem da malha de serviço em uma malha de cluster único

Nesta seção, mostramos como implantar um Recurso de gateway do Kubernetes, que implanta um balanceador de carga de aplicativo clássico e um gateway de entrada do Cloud Service Mesh.

Ativar a API Gateway com o Cloud Service Mesh gerenciado

1. Ative a API Gateway no cluster. O cluster do GKE precisa ser da versão 1.24 ou posterior.

2. Instalar Cloud Service Mesh gerenciado com rapid ou regular como canal de lançamento.

Implantar o recurso de gateway

Ao implantar o gateway de nuvem da malha de serviço, Os recursos de gateway são usados para implantar o Cloud Load Balancing e o Cloud Service Mesh para o gateway de entrada em uma única etapa. Observe que Os recursos do gateway do Kubernetes são diferente Gateway do Istio do Google Cloud.

Para mais informações sobre as diferenças, consulte Gateways do Kubernetes e gateways do Istio. Todo gateway do Kubernetes tem uma GatewayClass que indica o tipo e a recursos. gateway de nuvem da malha de serviço tem uma GatewayClass com a para implantar o gateway de entrada do Cloud Load Balancing e do Cloud Service Mesh.

1. Salve o seguinte manifesto GatewayClass em um arquivo chamado l7-gateway-class.yaml:

   apiVersion: gateway.networking.k8s.io/v1beta1
   kind: GatewayClass
   metadata:
     name: asm-l7-gxlb
   spec:
     controllerName: mesh.cloud.google.com/gateway
   

2. Implante o GatewayClass no cluster:

   kubectl apply -f l7-gateway-class.yaml
   

3. Verifique se o GatewayClass está presente após a instalação:

   kubectl get gatewayclasses.gateway.networking.k8s.io
   

   A resposta é semelhante a:

   NAME          CONTROLLER
   asm-l7-gxlb   mesh.cloud.google.com/gateway
   gke-l7-rilb   networking.gke.io/gateway
   gke-l7-gxlb   networking.gke.io/gateway
   

   A implantação de todos os recursos pode levar alguns minutos. Se você não o resultado esperado, verifique se você satisfez corretamente pré-requisitos.

   Você também vai ver o seguinte GatewayClass:

   gke-l7-gxlb   networking.gke.io/gateway
   

   Usado para implantar o balanceador de carga de aplicativo clássico do Google Cloud.

4. Crie um namespace dedicado para o gateway da nuvem da malha de serviço:

   kubectl create namespace istio-ingress
   

5. Salve o seguinte manifesto de gateway em um arquivo chamado gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: servicemesh-cloud-gw
     namespace: istio-ingress
   spec:
     gatewayClassName: asm-l7-gxlb
     listeners:
     - name: http
       protocol: HTTP
       port: 80
       allowedRoutes:
         namespaces:
           from: All
   

6. Implante o gateway no cluster no namespace istio-ingress:

   kubectl apply -f gateway.yaml
   

7. Verifique se os objetos da API Kubernetes Gateway foram criados:

   kubectl get gateways.gateway.networking.k8s.io -n istio-ingress
   

   A resposta é semelhante a:

   NAME                                CLASS         ADDRESS         READY   AGE
   asm-gw-gke-servicemesh-cloud-gw     gke-l7-gxlb   34.111.114.64   True    9m40s
   asm-gw-istio-servicemesh-cloud-gw   istio                                 9m44s
   servicemesh-cloud-gw                asm-l7-gxlb                           9m44s
   

Veja a seguir o que acontecerá quando esse objeto da API Kubernetes Gateway for implantado:

• Um balanceador de carga HTTP(S) externo é implantado e configurado. Pode levar alguns minutos para aparecer, mas, quando isso acontecer, o gateway indicará o endereço IP e será anotado com os nomes dos recursos do balanceador de carga do Compute Engine que foram criados.
• Uma implantação do gateway de entrada do Cloud Service Mesh é criada no arquivo istio-ingress . Isso cria as instâncias do proxy Envoy que receberão o tráfego dos de carga HTTP(S) externo global.
• O balanceador de carga vai criptografar e rotear todo o tráfego para a gateway de entrada do Cloud Service Mesh.

.

Aviso :no momento, é necessário ter pelo menos um arquivo secundário injetado para que o gateway de entrada do Cloud Service Mesh funcione corretamente.

Agora você tem a infraestrutura completa necessária para aceitar o tráfego da Internet na sua malha. Observe que essa é a implantação de gateway mais simples possível. Nas seções a seguir, você vai adicionar outras políticas e recursos que vão preparar a produção.

Implantação de apps e roteamento

Para demonstrar as capacidades, você vai implantar um aplicativo o Cloud Service Mesh e receber tráfego da Internet pelo gateway, por exemplo propósitos.

1. Identifique o namespace default para ativar a injeção de arquivo secundário.

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

2. Salve o seguinte manifesto de gateway em um arquivo chamado whereami.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: whereami-v1
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: whereami-v1
     template:
       metadata:
         labels:
           app: whereami-v1
       spec:
         containers:
         - name: whereami
           image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1.2.20
           ports:
             - containerPort: 8080
           env:
           - name: METADATA
             value: "whereami-v1"
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: whereami-v1
   spec:
     selector:
       app: whereami-v1
     ports:
     - port: 8080
       targetPort: 8080
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: whereami-v2
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: whereami-v2
     template:
       metadata:
         labels:
           app: whereami-v2
       spec:
         containers:
         - name: whereami
           image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1.2.20
           ports:
             - containerPort: 8080
           env:
           - name: METADATA
             value: "whereami-v2"
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: whereami-v2
   spec:
     selector:
       app: whereami-v2
     ports:
     - port: 8080
       targetPort: 8080
   

   Esse manifesto cria Service/whereami-v1, Service/whereami-v2, Deployment/whereami-v1 e Deployment/whereami-v2 para o whereami, um aplicativo simples que gera JSON para indicar a identidade e o local dele. Você implantará duas versões diferentes dele.

3. Crie os serviços e as implantações:

   kubectl apply -f whereami.yaml
   

   Depois que ele estiver em execução, você terá quatro pods whereami em execução no cluster.

4. Verifique se todos os quatro pods estão em execução:

   kubectl get pods
   

   A resposta é semelhante a:

   whereami-v1-7c76d89d55-qg6vs       2/2     Running   0          28s
   whereami-v1-7c76d89d55-vx9nm       2/2     Running   0          28s
   whereami-v2-67f6b9c987-p9kqm       2/2     Running   0          27s
   whereami-v2-67f6b9c987-qhj76       2/2     Running   0          27s
   

5. Salve o seguinte manifesto HTTPRoute em um arquivo chamado http-route.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: where-route
   spec:
    parentRefs:
    - kind: Gateway
      name: servicemesh-cloud-gw
      namespace: istio-ingress
    hostnames:
    - "where.example.com"
    rules:
    - matches:
      - headers:
        - name: version
          value: v2
      backendRefs:
      - name: whereami-v2
        port: 8080
    - backendRefs:
      - name: whereami-v1
        port: 8080
   

6. Implante http-route.yaml no cluster:

   kubectl apply -f http-route.yaml
   

   Esse HTTPRoute faz referência ao servicemesh-cloud-gw, o que significa que ele configurar o gateway de nuvem da malha de serviço para que ele configure o Cloud Service Mesh subjacente gateway de entrada com essas regras de roteamento. O HTTPRoute executa a mesma funciona como o VirtualService do Istio, mas usa a API Kubernetes Gateway para faça isso. Como a API Gateway é uma especificação OSS com muitos implementações, é a API mais adequada para definir o roteamento em uma de balanceadores de carga diferentes (como proxies do Cloud Service Mesh e balanceadores de carga de rede).

7. Recuperar o endereço IP do gateway para enviar tráfego ao aplicativo:

   VIP=$(kubectl get gateways.gateway.networking.k8s.io asm-gw-gke-servicemesh-cloud-gw -o=jsonpath="{.status.addresses[0].value}" -n istio-ingress)
   

   A saída é um endereço IP.

   echo $VIP
   
   34.111.61.135
   

8. Envie tráfego para o endereço IP do gateway para validar se essa configuração funciona corretamente. Envie uma solicitação com o cabeçalho version: v2 e outra sem para determinar se o roteamento é feito corretamente nas duas versões do aplicativo.

   Observação: isso pode levar até 10 minutos. Caso contrário, você verá o erro Empty reply from server ou Connection reset by peer

   curl ${VIP} -H "host: where.example.com"
   
   {
     "cluster_name": "gke1",
     "host_header": "where.example.com",
     "metadata": "whereami-v1",
     "node_name": "gke-gke1-default-pool-9b3b5b18-hw5z.c.church-243723.internal",
     "pod_name": "whereami-v1-67d9c5d48b-zhr4l",
     "pod_name_emoji": "⚒",
     "project_id": "church-243723",
     "timestamp": "2021-02-08T18:55:01",
     "zone": "us-central1-a"
   }
   
   curl ${VIP} -H "host: where.example.com" -H "version: v2"
   
   {
     "cluster_name": "gke1",
     "host_header": "where.example.com",
     "metadata": "whereami-v2",
     "node_name": "gke-gke1-default-pool-9b3b5b18-hw5z.c.church-243723.internal",
     "pod_name": "whereami-v2-67d9c5d48b-zhr4l",
     "pod_name_emoji": "⚒",
     "project_id": "church-243723",
     "timestamp": "2021-02-08T18:55:01",
     "zone": "us-central1-a"
   }
   

Implantação do gateway de produção

A seção anterior mostrou um exemplo muito simples de gateway da nuvem da malha de serviço. As etapas a seguir se baseiam no exemplo simples para mostrar uma configuração pronta para produção que demonstra as vantagens de delegar parte do roteamento de entrada de carga ao balanceador de carga.

No exemplo a seguir, você usará o servicemesh-cloud-gw da seção anterior e adicionará os seguintes recursos para criar um Gateway mais seguro e gerenciável:

• Implante o gateway com um endereço IP estático que será retido mesmo que a infraestrutura subjacente mude.
• Converta o gateway para receber tráfego HTTPS com um certificado autoassinado.

.

Observação: este exemplo se baseia na implantação de gateway, mas como a porta e do gateway de VPN de entrada forem alterados, essas etapas interromperão o tráfego ao gateway na porta 80. Em qualquer cenário realista, a porta de front-end do O gateway provavelmente não mudaria.

1. Criar um endereço IP externo estático. Um IP estático é útil porque a infraestrutura subjacente pode mudar no futuro, mas o endereço IP pode ser mantido.

   gcloud compute addresses create whereami-ip \
       --global \
       --project PROJECT_ID
   

2. Crie um certificado autoassinado para o domínio where-example-com:

   openssl genrsa -out key.pem 2048
   cat <<EOF >ca.conf
   [req]
   default_bits              = 2048
   req_extensions            = extension_requirements
   distinguished_name        = dn_requirements
   prompt                    = no
   [extension_requirements]
   basicConstraints          = CA:FALSE
   keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
   subjectAltName            = @sans_list
   [dn_requirements]
   0.organizationName        = example
   commonName                = where.example.com
   [sans_list]
   DNS.1                     = where.example.com
   EOF
   

   openssl req -new -key key.pem \
       -out csr.pem \
       -config ca.conf
   

   openssl x509 -req \
       -signkey key.pem \
       -in csr.pem \
       -out cert.pem \
       -extfile ca.conf \
       -extensions extension_requirements \
       -days 365
   

   gcloud compute ssl-certificates create where-example-com \
       --certificate=cert.pem \
       --private-key=key.pem \
       --global \
       --project PROJECT_ID
   

   Há muitas maneiras de gerar certificados TLS. Eles podem ser gerados manualmente na linha de comando, gerados com certificados gerenciados pelo Google ou internamente pelo sistema de infraestrutura de chave pública (ICP) de uma empresa. Neste exemplo, você gera manualmente um certificado autoassinado. Os certificados autoassinados geralmente não são usados para serviços públicos, mas demonstram esses conceitos com mais facilidade.

   Para mais informações sobre como criar um certificado autoassinado pelo Kubernetes Secret, consulte Proteger um gateway.

3. Atualize gateway.yaml com o seguinte manifesto:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: servicemesh-cloud-gw
     namespace: istio-ingress
   spec:
     gatewayClassName: asm-l7-gxlb
     listeners:
     - name: http
       protocol: HTTP
       port: 80
       allowedRoutes:
         namespaces:
           from: All
     - name: https
       protocol: HTTPS
       port: 443
       allowedRoutes:
         namespaces:
           from: All
       tls:
         mode: Terminate
         options:
           networking.gke.io/pre-shared-certs: where-example-com
     addresses:
     - type: NamedAddress
       value: whereami-ip
   

4. Reimplante o gateway no seu cluster:

   kubectl apply -f gateway.yaml
   

5. Consiga o endereço IP do IP estático:

   VIP=$(gcloud compute addresses describe whereami-ip --global --format="value(address)")
   

6. Use curl para acessar o domínio do gateway. Como o DNS não está configurado para esse domínio, use a opção --resolve para instruir o curl a resolver o nome de domínio para o endereço IP do gateway:

   curl https://where.example.com --resolve where.example.com:443:${VIP} --cacert cert.pem -v
   

   Observação :isso pode levar até 10 minutos para funcionar. Você verá Erro error:0A000126:SSL routines::unexpected eof while reading durante a espera.

   Quando concluída, a saída será semelhante a:

   ...
   * TLSv1.2 (OUT), TLS handshake, Client hello (1):
   * TLSv1.2 (IN), TLS handshake, Server hello (2):
   * TLSv1.2 (IN), TLS handshake, Certificate (11):
   * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
   * TLSv1.2 (IN), TLS handshake, Server finished (14):
   * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
   * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (OUT), TLS handshake, Finished (20):
   * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (IN), TLS handshake, Finished (20):
   * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
   * ALPN, server accepted to use h2
   * Server certificate:
   *  subject: O=example; CN=where.example.com
   *  start date: Apr 19 15:54:50 2021 GMT
   *  expire date: Apr 19 15:54:50 2022 GMT
   *  common name: where.example.com (matched)
   *  issuer: O=example; CN=where.example.com
   *  SSL certificate verify ok.
   ...
   {
     "cluster_name": "gke1",
     "host_header": "where.example.com",
     "metadata": "where-v1",
     "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal",
     "pod_name": "where-v1-84b47c7f58-tj5mn",
     "pod_name_emoji": "😍",
     "project_id": "agmsb-k8s",
     "timestamp": "2021-04-19T16:30:08",
     "zone": "us-west1-a"
   }
   

A saída detalhada inclui um handshake de TLS bem-sucedido seguido por uma resposta do aplicativo, como a saída a seguir. Isso prova que o TLS está sendo encerrado corretamente no gateway e que o aplicativo está respondendo ao cliente com segurança.

Você implantou a seguinte arquitetura:

O servicemesh-cloud-gw e o GatewayClass de asm-l7-gxlb abstraíram alguns componentes internos de infraestrutura para simplificar a experiência do usuário. O Cloud Load Balancing está encerrando o tráfego TLS usando um certificado interno e a verificação de integridade da camada de proxy do gateway de entrada do Cloud Service Mesh. A whereami-route implantado em Aplicativos e A implantação de roteamento Proxies de gateway de entrada do Cloud Service Mesh para rotear o tráfego para o local correto serviço hospedado na malha.

No exemplo a seguir, você usará o servicemesh-cloud-gw da seção anterior e adicionará os seguintes recursos para criar um Gateway mais seguro e gerenciável:

• Implante o gateway com um endereço IP estático que será retido mesmo que a infraestrutura subjacente mude.
• Converta o gateway para receber tráfego HTTPS com um certificado autoassinado.

.

Observação: este exemplo se baseia na implantação de gateway, mas como a porta e do gateway de VPN de entrada forem alterados, essas etapas interromperão o tráfego ao gateway na porta 80. Em qualquer cenário realista, a porta de front-end do O gateway provavelmente não mudaria.

1. Criar um endereço IP externo estático. Um IP estático é útil porque a infraestrutura subjacente pode mudar no futuro, mas o endereço IP pode ser mantido.

   gcloud compute addresses create whereami-ip \
       --global \
       --project PROJECT_ID
   

2. Crie um certificado autoassinado para o domínio where-example-com:

   openssl genrsa -out key.pem 2048
   cat <<EOF >ca.conf
   [req]
   default_bits              = 2048
   req_extensions            = extension_requirements
   distinguished_name        = dn_requirements
   prompt                    = no
   [extension_requirements]
   basicConstraints          = CA:FALSE
   keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
   subjectAltName            = @sans_list
   [dn_requirements]
   0.organizationName        = example
   commonName                = where.example.com
   [sans_list]
   DNS.1                     = where.example.com
   EOF
   

   openssl req -new -key key.pem \
       -out csr.pem \
       -config ca.conf
   

   openssl x509 -req \
       -signkey key.pem \
       -in csr.pem \
       -out cert.pem \
       -extfile ca.conf \
       -extensions extension_requirements \
       -days 365
   

   gcloud compute ssl-certificates create where-example-com \
       --certificate=cert.pem \
       --private-key=key.pem \
       --global \
       --project PROJECT_ID
   

   Há muitas maneiras de gerar certificados TLS. Eles podem ser gerados manualmente na linha de comando, gerados com certificados gerenciados pelo Google ou internamente pelo sistema de infraestrutura de chave pública (ICP) de uma empresa. Neste exemplo, você gera manualmente um certificado autoassinado. Os certificados autoassinados geralmente não são usados para serviços públicos, mas demonstram esses conceitos com mais facilidade.

   Para mais informações sobre como criar um certificado autoassinado pelo Kubernetes Secret, consulte Proteger um gateway.

3. Atualize gateway.yaml com o seguinte manifesto:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: servicemesh-cloud-gw
     namespace: istio-ingress
   spec:
     gatewayClassName: asm-l7-gxlb
     listeners:
     - name: http
       protocol: HTTP
       port: 80
       allowedRoutes:
         namespaces:
           from: All
     - name: https
       protocol: HTTPS
       port: 443
       allowedRoutes:
         namespaces:
           from: All
       tls:
         mode: Terminate
         options:
           networking.gke.io/pre-shared-certs: where-example-com
     addresses:
     - type: NamedAddress
       value: whereami-ip
   

4. Reimplante o gateway no seu cluster:

   kubectl apply -f gateway.yaml
   

5. Consiga o endereço IP do IP estático:

   VIP=$(gcloud compute addresses describe whereami-ip --global --format="value(address)")
   

6. Use curl para acessar o domínio do gateway. Como o DNS não está configurado para esse domínio, use a opção --resolve para instruir o curl a resolver o nome de domínio para o endereço IP do gateway:

   curl https://where.example.com --resolve where.example.com:443:${VIP} --cacert cert.pem -v
   

   Observação :isso pode levar até 10 minutos para funcionar. Você verá Erro error:0A000126:SSL routines::unexpected eof while reading durante a espera.

   Quando concluída, a saída será semelhante a:

   ...
   * TLSv1.2 (OUT), TLS handshake, Client hello (1):
   * TLSv1.2 (IN), TLS handshake, Server hello (2):
   * TLSv1.2 (IN), TLS handshake, Certificate (11):
   * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
   * TLSv1.2 (IN), TLS handshake, Server finished (14):
   * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
   * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (OUT), TLS handshake, Finished (20):
   * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (IN), TLS handshake, Finished (20):
   * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
   * ALPN, server accepted to use h2
   * Server certificate:
   *  subject: O=example; CN=where.example.com
   *  start date: Apr 19 15:54:50 2021 GMT
   *  expire date: Apr 19 15:54:50 2022 GMT
   *  common name: where.example.com (matched)
   *  issuer: O=example; CN=where.example.com
   *  SSL certificate verify ok.
   ...
   {
     "cluster_name": "gke1",
     "host_header": "where.example.com",
     "metadata": "where-v1",
     "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal",
     "pod_name": "where-v1-84b47c7f58-tj5mn",
     "pod_name_emoji": "😍",
     "project_id": "agmsb-k8s",
     "timestamp": "2021-04-19T16:30:08",
     "zone": "us-west1-a"
   }
   

A saída detalhada inclui um handshake de TLS bem-sucedido seguido por uma resposta do aplicativo, como a saída a seguir. Isso prova que o TLS está sendo encerrado corretamente no gateway e que o aplicativo está respondendo ao cliente com segurança.

Você implantou a seguinte arquitetura:

O servicemesh-cloud-gw e o GatewayClass de asm-l7-gxlb abstraíram alguns componentes internos de infraestrutura para simplificar a experiência do usuário. O Cloud Load Balancing está encerrando o tráfego TLS usando um certificado interno e a verificação de integridade da camada de proxy do gateway de entrada do Cloud Service Mesh. A whereami-route implantado em Aplicativos e A implantação de roteamento Proxies de gateway de entrada do Cloud Service Mesh para rotear o tráfego para o local correto serviço hospedado na malha.

A seguir

• Saiba mais sobre a implementação da API Kubernetes Gateway do Google Kubernetes Engine (GKE).
• Saiba como ativar os recursos opcionais gerenciados do Cloud Service Mesh.