Crie políticas de rede entre projetos

Esta página fornece instruções para configurar políticas de rede de tráfego entre projetos no Google Distributed Cloud (GDC) air-gapped.

O tráfego entre projetos refere-se à comunicação entre serviços e cargas de trabalho de diferentes espaços de nomes de projetos, mas dentro da mesma organização.

Os serviços e as cargas de trabalho num projeto estão isolados dos serviços e das cargas de trabalho externos por predefinição. No entanto, os serviços e as cargas de trabalho de diferentes espaços de nomes de projetos e dentro da mesma organização podem comunicar entre si aplicando políticas de rede de tráfego entre projetos.

Por predefinição, estas políticas aplicam-se globalmente em todas as zonas. Para mais informações sobre os recursos globais num universo da GDC, consulte o artigo Vista geral de várias zonas.

Para aplicar o tráfego entre projetos numa única zona, consulte o artigo Crie uma política entre projetos ao nível da carga de trabalho de uma única zona.

Antes de começar

Para configurar políticas de rede de tráfego entre projetos, tem de ter o seguinte:

• As funções de identidade e acesso necessárias. Para gerir políticas de um projeto específico, precisa da função project-networkpolicy-admin. Para ambientes de várias zonas onde tem de gerir políticas que abrangem todas as zonas, precisa da função global-project-networkpolicy-admin. Para mais informações, consulte o artigo Prepare funções e acesso predefinidos.
• Um projeto existente. Para mais informações, consulte Crie um projeto.
• Para as políticas de rede de saída, também tem de desativar a proteção contra a exfiltração de dados para o projeto.

Crie uma política entre projetos

Pode definir políticas de tráfego de entrada ou saída entre projetos para gerir a comunicação entre projetos.

Nota: as políticas definidas nesta secção aplicam-se a clusters partilhados e padrão.

Crie uma política entre projetos de entrada

Para permitir ligações aos serviços ou cargas de trabalho do seu projeto a partir de cargas de trabalho noutro projeto na sua organização, tem de configurar uma regra de firewall de entrada.

Esta política aplica-se a todas as zonas na sua organização.

Siga os passos seguintes para criar uma nova regra de firewall e permitir o tráfego de entrada de cargas de trabalho noutro projeto:

Consola

1. Na consola do GDC do projeto que está a configurar, aceda a Rede > Firewall no menu de navegação para abrir a página Firewall.
2. Clique em Criar na barra de ações para começar a criar uma nova regra de firewall.

3. Na página Detalhes da regra de firewall, preencha as seguintes informações:

   1. No campo Nome, introduza um nome válido para a regra de firewall.
   2. Na secção Direção do tráfego, selecione Entrada para permitir o tráfego de entrada de cargas de trabalho noutros projetos.
   3. Na secção Segmentar, selecione uma das seguintes opções:
      • Todas as cargas de trabalho do utilizador: permite ligações às cargas de trabalho do projeto que está a configurar.
      • Serviço: indica que esta regra de firewall tem como alvo um serviço específico no projeto que está a configurar.
   4. Se o seu alvo for um serviço de projeto, selecione o nome do serviço na lista de serviços disponíveis no menu pendente Serviço.
   5. Na secção De, selecione uma das seguintes duas opções:
      • Todos os projetos: permite ligações de cargas de trabalho em todos os projetos da mesma organização.
      • Outro projeto e Todas as cargas de trabalho do utilizador: permitem ligações de cargas de trabalho noutro projeto da mesma organização.
   6. Se quiser transferir cargas de trabalho apenas de outro projeto, selecione um projeto ao qual tenha acesso na lista de projetos no menu pendente ID do projeto.
   7. Se o seu destino for todas as cargas de trabalho do utilizador, selecione uma das seguintes opções na secção Protocolos e portas:
      • Permitir tudo: permitir ligações através de qualquer protocolo ou porta.
      • Protocolos e portas especificados: permitem ligações que usam apenas os protocolos e as portas que especificar nos campos correspondentes para a regra de firewall de entrada.

4. Na página Detalhes da regra de firewall, clique em Criar.

Permitiu ligações de outras cargas de trabalho do projeto na mesma organização. Depois de criar a regra de firewall, esta fica visível numa tabela na página Firewall.

Para criar uma política de entrada recíproca na outra direção, visite a consola do GDC do outro projeto e repita o processo.

API

A seguinte política permite que as cargas de trabalho no projeto PROJECT_1 permitam ligações de cargas de trabalho no projeto PROJECT_2, bem como o tráfego de retorno para os mesmos fluxos. Aplique a política:

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-inbound-traffic-from-PROJECT_2
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
EOF

Substitua GLOBAL_API_SERVER pelo caminho kubeconfig do servidor da API global. Para mais informações, consulte o artigo Servidores de API globais e zonais. Se ainda não gerou um ficheiro kubeconfig para o servidor da API, consulte o artigo Iniciar sessão para ver detalhes.

O comando anterior permite que PROJECT_2 aceda a PROJECT_1, mas não permite ligações iniciadas a partir de PROJECT_1 para PROJECT_2. Para este último, precisa de uma política recíproca no projeto PROJECT_2. Aplicar a política de reciprocidade:

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_2
  name: allow-inbound-traffic-from-PROJECT_1
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_1
EOF

As ligações são agora permitidas de e para PROJECT_1 e PROJECT_2.

Crie uma política entre projetos de saída

Quando concede uma política de tráfego entre projetos de entrada para permitir que cargas de trabalho num projeto permitam ligações de cargas de trabalho noutro projeto, esta ação também concede o tráfego de retorno para os mesmos fluxos. Por conseguinte, não precisa de uma política de rede de tráfego entre projetos de saída no projeto original.

Siga os passos seguintes para criar uma nova regra de firewall e permitir o tráfego de saída de cargas de trabalho num projeto:

Consola

1. Na consola do GDC do projeto que está a configurar, aceda a Rede > Firewall no menu de navegação para abrir a página Firewall.
2. Na barra de ações, clique em Criar para criar uma nova regra de firewall.

3. Na página Detalhes da regra de firewall, preencha as seguintes informações:

   1. No campo Nome, introduza um nome válido para a regra de firewall.
   2. Na secção Direção do tráfego, selecione Saída para indicar que esta regra de firewall está a controlar o tráfego de saída.
   3. Na secção Segmentar, selecione uma das seguintes opções:
      • Todas as cargas de trabalho do utilizador: permitem ligações das cargas de trabalho do projeto que está a configurar.
      • Serviço: indica que esta regra de firewall tem como alvo um serviço específico no projeto que está a configurar.
   4. Se o seu alvo for um serviço de projeto, selecione o nome do serviço na lista de serviços disponíveis no menu pendente Serviço.
   5. Na secção Para, selecione uma das seguintes opções:
      • Todos os projetos: permitem ligações a cargas de trabalho em todos os projetos da mesma organização.
      • Outro projeto e Todas as cargas de trabalho do utilizador: permitem ligações a cargas de trabalho noutro projeto da mesma organização.
   6. Se quiser transferir cargas de trabalho apenas para outro projeto, selecione um projeto ao qual tenha acesso na lista de projetos no menu pendente ID do projeto.
   7. Se o seu destino for todas as cargas de trabalho do utilizador, selecione uma das seguintes opções na secção Protocolos e portas:
      • Permitir tudo: permitir ligações através de qualquer protocolo ou porta.
      • Protocolos e portas especificados: permitem ligações que usam apenas os protocolos e as portas que especificar nos campos correspondentes para a regra da firewall de saída.

4. Na página Detalhes da regra de firewall, clique em Criar.

Permitiu ligações a outras cargas de trabalho do projeto na mesma organização. Depois de criar a regra de firewall, esta fica visível numa tabela na página Firewall.

Para criar uma política de saída recíproca na outra direção, visite a consola do GDC do outro projeto e repita o processo.

API

A seguinte política permite que as cargas de trabalho no projeto PROJECT_1 permitam ligações a cargas de trabalho no projeto PROJECT_2. Aplique a política:

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-outbound-traffic-to-PROJECT_2
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
EOF

Substitua o seguinte:

• GLOBAL_API_SERVER: o caminho kubeconfig do servidor da API global. Para mais informações, consulte o artigo Servidores de API globais e zonais. Se ainda não gerou um ficheiro kubeconfig para o servidor da API, consulte o artigo Iniciar sessão para ver detalhes.
• PROJECT_1: o nome do projeto que está a receber o tráfego.
• PROJECT_2: o nome do projeto de onde o tráfego está a ser gerado.
• SUBJECT_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho do assunto. Por exemplo, app, tier ou role.
• SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Por exemplo, se SUBJECT_LABEL_KEY for app e SUBJECT_LABEL_VALUE for backend, as cargas de trabalho com a etiqueta app: backend estão a receber o tráfego.
• PEER_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho pares.
• PEER_LABEL_VALUE: o valor associado ao PEER_LABEL_KEY.

O comando anterior permite ligações de saída de PROJECT_1 para PROJECT_2, mas não permite ligações de PROJECT_2 para PROJECT_1. Para este último, precisa de uma política recíproca no projeto PROJECT_2. Aplicar a política de reciprocidade:

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_2
  name: allow-outbound-traffic-to-PROJECT_1
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_1
EOF

Crie uma política entre projetos ao nível da carga de trabalho de saída

• Para criar uma política entre projetos ao nível da carga de trabalho de saída, crie e aplique o seguinte recurso personalizado:

  kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
  apiVersion: networking.global.gdc.goog/v1
  kind: ProjectNetworkPolicy
  metadata:
    namespace: PROJECT_2
    name: allow-cross-project-outbound-traffic-from-project-2-to-project-1
  spec:
    policyType: Egress
    subject:
      subjectType: UserWorkload
      userWorkloadSelector:
        labelSelector:
          workloads:
            matchLabels:
              SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
    egress:
    - to:
      - projectSelector:
          projects:
            matchNames:
            - PROJECT_1
          workloadSelector:
            labelSelector:
              workloads:
                matchLabels:
                  PEER_LABEL_KEY: PEER_LABEL_VALUE
  EOF
  

  Substitua o seguinte:

  • GLOBAL_API_SERVER: o caminho kubeconfig do servidor da API global. Para mais informações, consulte o artigo Servidores de API globais e zonais. Se ainda não gerou um ficheiro kubeconfig para o servidor da API, consulte o artigo Iniciar sessão para ver detalhes.
  • PROJECT_1: o nome do projeto que está a receber o tráfego.
  • PROJECT_2: o nome do projeto de onde o tráfego está a ser gerado.
  • SUBJECT_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho do assunto. Por exemplo, app, tier ou role.
  • SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Por exemplo, se SUBJECT_LABEL_KEY for app e SUBJECT_LABEL_VALUE for backend, as cargas de trabalho com a etiqueta app: backend estão a enviar o tráfego.
  • PEER_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho pares.
  • PEER_LABEL_VALUE: o valor associado ao PEER_LABEL_KEY.

Crie uma política entre projetos ao nível da carga de trabalho de zona única

As políticas de rede ao nível da carga de trabalho podem aplicar o PNP ao longo de uma única zona. Podem ser adicionadas etiquetas específicas a cargas de trabalho numa única zona, o que lhe permite controlar a comunicação entre cargas de trabalho individuais num projeto ou em projetos diferentes para essa zona.

Crie uma política entre projetos ao nível da carga de trabalho de entrada de zona única

1. Para criar uma política entre projetos ao nível da carga de trabalho de entrada de uma única zona, crie e aplique o seguinte recurso personalizado:

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     namespace: PROJECT_1
     name: allow-single-zone-cross-project-inbound-traffic-from-project-2-to-project-1
   spec:
     policyType: Ingress
     subject:
       subjectType: UserWorkload
       userWorkloadSelector:
         labelSelector:
           workloads:
             matchLabels:
               SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
               ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
     ingress:
     - from:
       - projectSelector:
           projects:
             matchNames:
             - PROJECT_2
           workloadSelector:
             labelSelector:
               workloads:
                 matchLabels:
                   PEER_LABEL_KEY: PEER_LABEL_VALUE
                   ZONE_PEER_LABEL_KEY: ZONE_PEER_LABEL_VALUE
   EOF
   

   Nota: os recursos têm de ter etiquetas com correspondência exata. Para garantir que esta política é aplicada numa única zona, as cargas de trabalho de pares e de assuntos têm de ter a mesma etiqueta de zona.

   Substitua o seguinte:

   • GLOBAL_API_SERVER: o caminho kubeconfig do servidor da API global. Para mais informações, consulte o artigo Servidores de API globais e zonais. Se ainda não gerou um ficheiro kubeconfig para o servidor da API, consulte o artigo Iniciar sessão para ver detalhes.
   • PROJECT_1: o nome do projeto que está a receber o tráfego.
   • PROJECT_2: o nome do projeto de onde o tráfego está a ser gerado.
   • SUBJECT_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho do assunto. Por exemplo, app, tier ou role.
   • SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Por exemplo, se SUBJECT_LABEL_KEY for app e SUBJECT_LABEL_VALUE for backend, as cargas de trabalho com a etiqueta app: backend estão a receber o tráfego.
   • PEER_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho pares.
   • PEER_LABEL_VALUE: o valor associado ao PEER_LABEL_KEY.
   • ZONE_SUBJECT_LABEL_KEY: a chave da etiqueta usada para selecionar a zona do assunto. Por exemplo, zone ou region.
   • ZONE_SUBJECT_LABEL_VALUE: o valor associado ao ZONE_SUBJECT_LABEL_KEY. Especifica a zona que está a receber o tráfego. Por exemplo, se ZONE_SUBJECT_LABEL_KEY for zone e ZONE_SUBJECT_LABEL_VALUE for us-central1-a, as cargas de trabalho com a etiqueta zone: us-central1-a estão a receber o tráfego.
   • ZONE_PEER_LABEL_KEY: a chave da etiqueta usada para selecionar a zona associada ao par.
   • ZONE_PEER_LABEL_VALUE: o valor associado ao ZONE_PEER_LABEL_KEY.

Crie uma política entre projetos ao nível da carga de trabalho de saída de uma única zona

• Para criar uma política entre projetos ao nível da carga de trabalho de saída de uma única zona, crie e aplique o seguinte recurso personalizado:

  kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
  apiVersion: networking.global.gdc.goog/v1
  kind: ProjectNetworkPolicy
  metadata:
    namespace: PROJECT_2
    name: allow-single-zone-cross-project-outbound-traffic-from-project-2-to-project-1
  spec:
    policyType: Egress
    subject:
      subjectType: UserWorkload
      userWorkloadSelector:
        labelSelector:
          workloads:
            matchLabels:
              SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
              ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
    egress:
    - to:
      - projectSelector:
          projects:
            matchNames:
            - PROJECT_1
          workloadSelector:
            labelSelector:
              workloads:
                matchLabels:
                  PEER_LABEL_KEY: PEER_LABEL_VALUE
                  ZONE_PEER_LABEL_KEY: ZONE_PEER_LABEL_VALUE
  EOF
  

  Nota: os recursos têm de ter etiquetas com correspondência exata. Para garantir que esta política é aplicada numa única zona, as cargas de trabalho de pares e de assuntos têm de ter a mesma etiqueta de zona.

  Substitua o seguinte:

  • GLOBAL_API_SERVER: o caminho kubeconfig do servidor da API global. Para mais informações, consulte o artigo Servidores de API globais e zonais. Se ainda não gerou um ficheiro kubeconfig para o servidor da API, consulte o artigo Iniciar sessão para ver detalhes.
  • PROJECT_1: o nome do projeto que está a receber o tráfego.
  • PROJECT_2: o nome do projeto de onde o tráfego está a ser gerado.
  • SUBJECT_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho do assunto. Por exemplo, app, tier ou role.
  • SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Por exemplo, se SUBJECT_LABEL_KEY for app e SUBJECT_LABEL_VALUE for backend, as cargas de trabalho com a etiqueta app: backend estão a enviar o tráfego.
  • PEER_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho pares.
  • PEER_LABEL_VALUE: o valor associado ao PEER_LABEL_KEY.
  • ZONE_SUBJECT_LABEL_KEY: a chave da etiqueta usada para selecionar a zona do assunto. Por exemplo, zone ou region.
  • ZONE_SUBJECT_LABEL_VALUE: o valor associado ao ZONE_SUBJECT_LABEL_KEY. Por exemplo, se ZONE_SUBJECT_LABEL_KEY for zone e ZONE_SUBJECT_LABEL_VALUE for us-central1-a, as cargas de trabalho com a etiqueta zone: us-central1-a estão a enviar o tráfego.
  • ZONE_PEER_LABEL_KEY: a chave da etiqueta usada para selecionar a zona associada ao par.
  • ZONE_PEER_LABEL_VALUE: o valor associado ao ZONE_PEER_LABEL_KEY.

Crie uma política entre projetos para clusters padrão

Os clusters padrão são clusters Kubernetes ao nível do projeto que oferecem maior controlo, flexibilidade e autorizações de administrador do cluster.

Crie uma política entre projetos de entrada para clusters padrão

1. Para criar uma política intercluster de entrada entre clusters padrão, crie e aplique o seguinte recurso personalizado:

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     namespace: STANDARD_CLUSTER_1_PROJECT
     name: allow-ingress-from-standard-cluster-2-to-standard-cluster-1
   spec:
     policyType: Ingress
     subject:
       subjectType: UserWorkload
       userWorkloadSelector:
         labelSelector:
           clusters:
             matchLabels:
               kubernetes.io/metadata.name: STANDARD_CLUSTER_1_NAME
           namespaces:
             matchLabels:
               kubernetes.io/metadata.name: SUBJECT_NAMESPACE
           workloads:
             matchLabels:
               SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
     ingress:
     - from:
       - projectSelector:
           projects:
             matchNames:
             - STANDARD_CLUSTER_2_PROJECT
           workloadSelector:
             labelSelector:
               clusters:
                 matchLabels:
                   kubernetes.io/metadata.name: STANDARD_CLUSTER_2_NAME
               namespaces:
                 matchLabels:
                   kubernetes.io/metadata.name: PEER_NAMESPACE
               workloads:
                 matchLabels:
                   PEER_LABEL_KEY: PEER_LABEL_VALUE
   EOF
   

   Substitua o seguinte:

   • GLOBAL_API_SERVER: o caminho kubeconfig do servidor da API global. Para mais informações, consulte o artigo Servidores de API globais e zonais. Se ainda não gerou um ficheiro kubeconfig para o servidor da API, consulte o artigo Iniciar sessão para ver detalhes.
   • STANDARD_CLUSTER_1_PROJECT: o nome do projeto de cluster padrão que está a receber o tráfego.
   • STANDARD_CLUSTER_2_PROJECT: o nome do projeto de cluster padrão de onde o tráfego está a chegar.
   • STANDARD_CLUSTER_1_NAME: o nome do cluster padrão que está a receber o tráfego.
   • STANDARD_CLUSTER_2_NAME: o nome do cluster padrão de onde o tráfego está a chegar.
   • SUBJECT_NAMESPACE: o espaço de nomes do assunto no cluster padrão.
   • PEER_NAMESPACE: o espaço de nomes de pares no cluster padrão.
   • SUBJECT_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho do assunto. Por exemplo, app, tier ou role.
   • SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Por exemplo, se SUBJECT_LABEL_KEY for app e SUBJECT_LABEL_VALUE for backend, as cargas de trabalho com a etiqueta app: backend estão a receber o tráfego.
   • PEER_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho pares.
   • PEER_LABEL_VALUE: o valor associado ao PEER_LABEL_KEY.

2. Para criar uma política intercluster de entrada entre clusters padrão e partilhados, crie e aplique o seguinte recurso personalizado:

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     namespace: SHARED_CLUSTER_PROJECT
     name: allow-ingress-from-standard-cluster-to-shared-cluster
   spec:
     policyType: Ingress
     subject:
       subjectType: UserWorkload
       userWorkloadSelector:
         labelSelector:
           workloads:
             matchLabels:
               SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
     ingress:
     - from:
       - projectSelector:
           projects:
             matchNames:
             - STANDARD_CLUSTER_PROJECT
           workloadSelector:
             labelSelector:
               clusters:
                 matchLabels:
                   kubernetes.io/metadata.name: STANDARD_CLUSTER_NAME
               namespaces:
                 matchLabels:
                   kubernetes.io/metadata.name: PEER_NAMESPACE
               workloads:
                 matchLabels:
                   PEER_LABEL_KEY: PEER_LABEL_VALUE
   EOF
   

   Substitua o seguinte:

   • GLOBAL_API_SERVER: o caminho kubeconfig do servidor da API global. Para mais informações, consulte o artigo Servidores de API globais e zonais. Se ainda não gerou um ficheiro kubeconfig para o servidor da API, consulte o artigo Iniciar sessão para ver detalhes.
   • STANDARD_CLUSTER_PROJECT: o nome do projeto de cluster padrão.
   • SHARED_CLUSTER_PROJECT: o nome do projeto de cluster partilhado.
   • STANDARD_CLUSTER_NAME: o nome do cluster padrão.
   • PEER_NAMESPACE: o espaço de nomes de pares no cluster padrão.
   • SUBJECT_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho do assunto. Por exemplo, app, tier ou role.
   • SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Por exemplo, se SUBJECT_LABEL_KEY for app e SUBJECT_LABEL_VALUE for backend, as cargas de trabalho com a etiqueta app: backend estão a receber o tráfego.
   • PEER_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho pares.
   • PEER_LABEL_VALUE: o valor associado ao PEER_LABEL_KEY.

Crie uma política entre projetos de saída para clusters padrão

1. Para criar uma política intercluster de saída entre clusters padrão, crie e aplique o seguinte recurso personalizado:

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     namespace: STANDARD_CLUSTER_2_PROJECT
     name: allow-egress-from-standard-cluster-2-to-standard-cluster-1
   spec:
     policyType: Egress
     subject:
       subjectType: UserWorkload
       userWorkloadSelector:
         labelSelector:
           clusters:
             matchLabels:
               kubernetes.io/metadata.name: STANDARD_CLUSTER_2_NAME
           namespaces:
             matchLabels:
               kubernetes.io/metadata.name: SUBJECT_NAMESPACE
           workloads:
             matchLabels:
               SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
     egress:
     - to:
       - projectSelector:
           projects:
             matchNames:
             - STANDARD_CLUSTER_1_PROJECT
           workloadSelector:
             labelSelector:
               clusters:
                 matchLabels:
                   kubernetes.io/metadata.name: STANDARD_CLUSTER_1_NAME
               namespaces:
                 matchLabels:
                   kubernetes.io/metadata.name: PEER_NAMESPACE
               workloads:
                 matchLabels:
                   PEER_LABEL_KEY: PEER_LABEL_VALUE
   EOF
   

   Substitua o seguinte:

   • GLOBAL_API_SERVER: o caminho kubeconfig do servidor da API global. Para mais informações, consulte o artigo Servidores de API globais e zonais. Se ainda não gerou um ficheiro kubeconfig para o servidor da API, consulte o artigo Iniciar sessão para ver detalhes.
   • STANDARD_CLUSTER_1_PROJECT: o nome do projeto de cluster padrão que está a receber o tráfego.
   • STANDARD_CLUSTER_2_PROJECT: o nome do projeto de cluster padrão de onde o tráfego está a chegar.
   • STANDARD_CLUSTER_1_NAME: o nome do cluster padrão que está a receber o tráfego.
   • STANDARD_CLUSTER_2_NAME: o nome do cluster padrão de onde o tráfego está a chegar.
   • SUBJECT_NAMESPACE: o espaço de nomes do assunto no cluster padrão.
   • PEER_NAMESPACE: o espaço de nomes de pares no cluster padrão.
   • SUBJECT_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho do assunto. Por exemplo, app, tier ou role.
   • SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Por exemplo, se SUBJECT_LABEL_KEY for app e SUBJECT_LABEL_VALUE for backend, as cargas de trabalho com a etiqueta app: backend estão a enviar o tráfego.
   • PEER_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho pares.
   • PEER_LABEL_VALUE: o valor associado ao PEER_LABEL_KEY.

2. Para criar uma política de saída entre clusters padrão e partilhados, crie e aplique o seguinte recurso personalizado:

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     namespace: STANDARD_CLUSTER_PROJECT
     name: allow-egress-from-standard-cluster-to-shared-cluster
   spec:
     policyType: Egress
     subject:
       subjectType: UserWorkload
       userWorkloadSelector:
         labelSelector:
           clusters:
             matchLabels:
               kubernetes.io/metadata.name: STANDARD_CLUSTER_NAME
           namespaces:
             matchLabels:
               kubernetes.io/metadata.name: SUBJECT_NAMESPACE
           workloads:
             matchLabels:
               SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
     egress:
     - to:
       - projectSelector:
           projects:
             matchNames:
             - SHARED_CLUSTER_PROJECT
           workloadSelector:
             labelSelector:
               workloads:
                 matchLabels:
                   PEER_LABEL_KEY: PEER_LABEL_VALUE
   EOF
   

   Substitua o seguinte:

   • GLOBAL_API_SERVER: o caminho kubeconfig do servidor da API global. Para mais informações, consulte o artigo Servidores de API globais e zonais. Se ainda não gerou um ficheiro kubeconfig para o servidor da API, consulte o artigo Iniciar sessão para ver detalhes.
   • STANDARD_CLUSTER_PROJECT: o nome do projeto de cluster padrão.
   • SHARED_CLUSTER_PROJECT: o nome do projeto de cluster partilhado.
   • STANDARD_CLUSTER_NAME: o nome do cluster padrão.
   • SUBJECT_NAMESPACE: o espaço de nomes do assunto no cluster padrão.
   • SUBJECT_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho do assunto. Por exemplo, app, tier ou role.
   • SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Por exemplo, se SUBJECT_LABEL_KEY for app e SUBJECT_LABEL_VALUE for backend, as cargas de trabalho com a etiqueta app: backend estão a enviar o tráfego.
   • PEER_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho pares.
   • PEER_LABEL_VALUE: o valor associado ao PEER_LABEL_KEY.