Criar políticas de rede entre projetos

Nesta página, você encontra instruções para configurar políticas de rede de tráfego entre projetos no Google Distributed Cloud (GDC) com isolamento físico.

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

Por padrão, os serviços e as cargas de trabalho em um projeto são isolados de serviços e cargas de trabalho externos. No entanto, serviços e cargas de trabalho de namespaces de projetos diferentes e dentro da mesma organização podem se comunicar entre si aplicando políticas de rede de tráfego entre projetos.

Por padrão, essas políticas são aplicadas globalmente em todas as zonas. Para mais informações sobre recursos globais em um universo do GDC, consulte Visão geral de várias zonas.

Para aplicar o tráfego entre projetos em uma única zona, consulte Criar uma política entre projetos no 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, você precisa ter o seguinte:

  • Os papéis necessários de identidade e acesso. Para gerenciar políticas de um projeto específico, você precisa da função project-networkpolicy-admin. Para ambientes multizona em que é necessário gerenciar políticas que abrangem todas as zonas, você precisa da função global-project-networkpolicy-admin. Para mais informações, consulte Preparar papéis predefinidos e acesso.
  • Um projeto atual. Para mais informações, consulte Criar um projeto.
  • Para políticas de rede de saída, também é necessário desativar a proteção contra exfiltração de dados do projeto.

Criar uma política entre projetos

É possível definir políticas de tráfego de entrada ou saída entre projetos para gerenciar a comunicação entre eles.

Criar uma política de entrada entre projetos

Para permitir conexões com as cargas de trabalho ou serviços do seu projeto de cargas de trabalho em outro projeto na sua organização, configure uma regra de firewall de entrada.

Essa política se aplica a todas as zonas da sua organização.

Siga estas etapas para criar uma regra de firewall e permitir o tráfego de entrada de cargas de trabalho em outro projeto:

Console

  1. No console do GDC do projeto que você está configurando, acesse 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 regra de firewall.

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

    1. No campo Nome, insira um nome válido para a regra de firewall.
    2. Na seção Direção do tráfego, selecione Entrada para permitir o tráfego de entrada de cargas de trabalho em outros projetos.
    3. Na seção Segmentação, selecione uma das seguintes opções:
      • Todas as cargas de trabalho do usuário:permite conexões com as cargas de trabalho do projeto que você está configurando.
      • Serviço:indica que essa regra de firewall tem como destino um serviço específico no projeto que você está configurando.
    4. Se o destino for um serviço do projeto, selecione o nome dele no menu suspenso Serviço.
    5. Na seção De, selecione uma das seguintes opções:
      • Todos os projetos:permite conexões de cargas de trabalho em todos os projetos da mesma organização.
      • Outro projeto e Todas as cargas de trabalho do usuário:permitem conexões de cargas de trabalho em outro projeto da mesma organização.
    6. Se você quiser transferir cargas de trabalho apenas de outro projeto, selecione um projeto a que você tenha acesso na lista de projetos do menu suspenso ID do projeto.
    7. Se o destino for todas as cargas de trabalho do usuário, selecione uma das seguintes opções na seção Protocolos e portas:
      • Permitir tudo:permite conexões usando qualquer protocolo ou porta.
      • Protocolos e portas especificados:permitem conexões usando apenas os protocolos e portas especificados nos campos correspondentes da regra de firewall de entrada.

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

Agora você permitiu conexões de outras cargas de trabalho de projetos na mesma organização. Depois de criar a regra de firewall, ela fica visível em uma tabela na página Firewall.

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

API

A política a seguir permite que as cargas de trabalho no projeto PROJECT_1 aceitem conexõ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 do kubeconfig do servidor da API global. Para mais informações, consulte Servidores de API globais e zonais. Se você ainda não gerou um arquivo kubeconfig para o servidor da API, consulte Fazer login para mais detalhes.

O comando anterior permite que PROJECT_2 acesse PROJECT_1, mas não permite conexões iniciadas de PROJECT_1 para PROJECT_2. Para o último, é preciso ter uma política recíproca no projeto PROJECT_2. Aplique a política recíproca:

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

Agora, as conexões são permitidas de e para PROJECT_1 e PROJECT_2.

Criar uma política de saída entre projetos

Quando você concede uma política de tráfego de entrada entre projetos para permitir que cargas de trabalho em um projeto aceitem conexões de cargas de trabalho em outro projeto, essa ação também concede o tráfego de retorno para os mesmos fluxos. Portanto, não é necessário ter uma política de rede de tráfego entre projetos de saída no projeto original.

Siga estas etapas para criar uma regra de firewall e permitir o tráfego de saída de cargas de trabalho em um projeto:

Console

  1. No console do GDC do projeto que você está configurando, acesse 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 regra de firewall.

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

    1. No campo Nome, insira um nome válido para a regra de firewall.
    2. Na seção Direção do tráfego, selecione Saída para indicar que essa regra de firewall está controlando o tráfego de saída.
    3. Na seção Segmentação, selecione uma das seguintes opções:
      • Todas as cargas de trabalho do usuário:permite conexões das cargas de trabalho do projeto que você está configurando.
      • Serviço:indica que essa regra de firewall tem como destino um serviço específico no projeto que você está configurando.
    4. Se o destino for um serviço do projeto, selecione o nome dele no menu suspenso Serviço.
    5. Na seção Para, selecione uma das seguintes opções:
      • Todos os projetos:permite conexões com cargas de trabalho em todos os projetos da mesma organização.
      • Outro projeto e Todas as cargas de trabalho do usuário:permitem conexões com cargas de trabalho em outro projeto da mesma organização.
    6. Se você quiser transferir cargas de trabalho apenas para outro projeto, selecione um projeto a que você tenha acesso na lista de projetos do menu suspenso ID do projeto.
    7. Se o destino for todas as cargas de trabalho do usuário, selecione uma das seguintes opções na seção Protocolos e portas:
      • Permitir tudo:permite conexões usando qualquer protocolo ou porta.
      • Protocolos e portas especificados:permite conexões usando apenas os protocolos e portas especificados nos campos correspondentes da regra de firewall de saída.

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

Agora você permitiu conexões com outras cargas de trabalho de projetos na mesma organização. Depois de criar a regra de firewall, ela fica visível em uma tabela na página Firewall.

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

API

A política a seguir permite que as cargas de trabalho no projeto PROJECT_1 se conectem às 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:

  • GLOBAL_API_SERVER: o caminho do kubeconfig do servidor de API global. Para mais informações, consulte Servidores de API globais e zonais. Se você ainda não gerou um arquivo kubeconfig para o servidor da API, consulte Fazer login para mais detalhes.
  • PROJECT_1: o nome do projeto que está recebendo o tráfego.
  • PROJECT_2: o nome do projeto de origem do tráfego.

O comando anterior permite conexões de saída de PROJECT_1 para PROJECT_2, mas não permite conexões de PROJECT_2 para PROJECT_1. Para o último, é necessário ter uma política recíproca no projeto PROJECT_2. Aplique a política recíproca:

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

Criar uma política de saída entre projetos no nível da carga de trabalho

  • Para criar uma política de saída entre projetos no nível da carga de trabalho, 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:

    • GLOBAL_API_SERVER: o caminho do kubeconfig do servidor de API global. Para mais informações, consulte Servidores de API globais e zonais. Se você ainda não gerou um arquivo kubeconfig para o servidor da API, consulte Fazer login para mais detalhes.
    • PROJECT_1: o nome do projeto que está recebendo o tráfego.
    • PROJECT_2: o nome do projeto de origem do tráfego.
    • SUBJECT_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho em questão. Por exemplo, app, tier ou role. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
    • 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 o rótulo app: backend estarão enviando o tráfego.
    • PEER_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho do mesmo nível. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
    • PEER_LABEL_VALUE: o valor associado ao PEER_LABEL_KEY.

Criar uma política entre projetos no nível da carga de trabalho de zona única

As políticas de rede no nível da carga de trabalho podem aplicar o PNP em uma única zona. Rótulos específicos podem ser adicionados a cargas de trabalho em uma única zona, permitindo controlar a comunicação entre cargas de trabalho individuais em um projeto ou em projetos diferentes para essa zona.

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

  1. Para criar uma política entre projetos no nível da carga de trabalho de entrada de zona única, 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

    Substitua:

    • GLOBAL_API_SERVER: o caminho do kubeconfig do servidor de API global. Para mais informações, consulte Servidores de API globais e zonais. Se você ainda não gerou um arquivo kubeconfig para o servidor da API, consulte Fazer login para mais detalhes.
    • PROJECT_1: o nome do projeto que está recebendo o tráfego.
    • PROJECT_2: o nome do projeto de origem do tráfego.
    • SUBJECT_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho em questão. Por exemplo, app, tier ou role. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
    • 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 o rótulo app: backend vão receber o tráfego.
    • PEER_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho do mesmo nível. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
    • PEER_LABEL_VALUE: o valor associado ao PEER_LABEL_KEY.
    • ZONE_SUBJECT_LABEL_KEY: a chave do rótulo usada para selecionar a zona de assunto. Por exemplo, zone ou region. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
    • ZONE_SUBJECT_LABEL_VALUE: o valor associado ao ZONE_SUBJECT_LABEL_KEY. Ele especifica qual zona está recebendo 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 o rótulo zone: us-central1-a vão receber o tráfego.
    • ZONE_PEER_LABEL_KEY: a chave do rótulo usado para selecionar a zona associada ao peer. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
    • ZONE_PEER_LABEL_VALUE: o valor associado ao ZONE_PEER_LABEL_KEY.

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

  • Para criar uma política entre projetos no 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

    Substitua:

    • GLOBAL_API_SERVER: o caminho do kubeconfig do servidor de API global. Para mais informações, consulte Servidores de API globais e zonais. Se você ainda não gerou um arquivo kubeconfig para o servidor da API, consulte Fazer login para mais detalhes.
    • PROJECT_1: o nome do projeto que está recebendo o tráfego.
    • PROJECT_2: o nome do projeto de origem do tráfego.
    • SUBJECT_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho em questão. Por exemplo, app, tier ou role. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
    • 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 o rótulo app: backend estarão enviando o tráfego.
    • PEER_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho do mesmo nível. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
    • PEER_LABEL_VALUE: o valor associado ao PEER_LABEL_KEY.
    • ZONE_SUBJECT_LABEL_KEY: a chave do rótulo usada para selecionar a zona de assunto. Por exemplo, zone ou region. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
    • 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 o rótulo zone: us-central1-a estarão enviando o tráfego.
    • ZONE_PEER_LABEL_KEY: a chave do rótulo usado para selecionar a zona associada ao peer. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
    • ZONE_PEER_LABEL_VALUE: o valor associado ao ZONE_PEER_LABEL_KEY.

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

Os clusters Standard são clusters do Kubernetes com escopo de projeto que oferecem mais controle, flexibilidade e permissões de administrador do cluster.

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

  1. Para criar uma política 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:

    • GLOBAL_API_SERVER: o caminho do kubeconfig do servidor de API global. Para mais informações, consulte Servidores de API globais e zonais. Se você ainda não gerou um arquivo kubeconfig para o servidor da API, consulte Fazer login para mais detalhes.
    • STANDARD_CLUSTER_1_PROJECT: o nome do projeto do cluster Standard que está recebendo o tráfego.
    • STANDARD_CLUSTER_2_PROJECT: o nome do projeto de cluster padrão de onde o tráfego está vindo.
    • STANDARD_CLUSTER_1_NAME: o nome do cluster padrão que está recebendo o tráfego.
    • STANDARD_CLUSTER_2_NAME: o nome do cluster padrão de onde o tráfego está vindo.
    • SUBJECT_NAMESPACE: o namespace do assunto no cluster padrão.
    • PEER_NAMESPACE: o namespace do peer no cluster padrão.
    • SUBJECT_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho em questão. Por exemplo, app, tier ou role. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
    • 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 o rótulo app: backend vão receber o tráfego.
    • PEER_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho do mesmo nível. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
    • PEER_LABEL_VALUE: o valor associado ao PEER_LABEL_KEY.

  2. Para criar uma política de entrada entre clusters padrão e compartilhados, 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:

    • GLOBAL_API_SERVER: o caminho do kubeconfig do servidor de API global. Para mais informações, consulte Servidores de API globais e zonais. Se você ainda não gerou um arquivo kubeconfig para o servidor da API, consulte Fazer login para mais detalhes.
    • STANDARD_CLUSTER_PROJECT: o nome do projeto do cluster padrão.
    • SHARED_CLUSTER_PROJECT: o nome do projeto de cluster compartilhado.
    • STANDARD_CLUSTER_NAME: o nome do cluster padrão.
    • PEER_NAMESPACE: o namespace do peer no cluster padrão.
    • SUBJECT_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho em questão. Por exemplo, app, tier ou role. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
    • 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 o rótulo app: backend vão receber o tráfego.
    • PEER_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho do mesmo nível. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
    • PEER_LABEL_VALUE: o valor associado ao PEER_LABEL_KEY.

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

  1. Para criar uma política 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:

    • GLOBAL_API_SERVER: o caminho do kubeconfig do servidor de API global. Para mais informações, consulte Servidores de API globais e zonais. Se você ainda não gerou um arquivo kubeconfig para o servidor da API, consulte Fazer login para mais detalhes.
    • STANDARD_CLUSTER_1_PROJECT: o nome do projeto do cluster Standard que está recebendo o tráfego.
    • STANDARD_CLUSTER_2_PROJECT: o nome do projeto de cluster padrão de onde o tráfego está vindo.
    • STANDARD_CLUSTER_1_NAME: o nome do cluster padrão que está recebendo o tráfego.
    • STANDARD_CLUSTER_2_NAME: o nome do cluster padrão de onde o tráfego está vindo.
    • SUBJECT_NAMESPACE: o namespace do assunto no cluster padrão.
    • PEER_NAMESPACE: o namespace do peer no cluster padrão.
    • SUBJECT_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho em questão. Por exemplo, app, tier ou role. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
    • 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 o rótulo app: backend estarão enviando o tráfego.
    • PEER_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho do mesmo nível. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
    • PEER_LABEL_VALUE: o valor associado ao PEER_LABEL_KEY.

  2. Para criar uma política de saída entre clusters padrão e compartilhados, 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:

    • GLOBAL_API_SERVER: o caminho do kubeconfig do servidor de API global. Para mais informações, consulte Servidores de API globais e zonais. Se você ainda não gerou um arquivo kubeconfig para o servidor da API, consulte Fazer login para mais detalhes.
    • STANDARD_CLUSTER_PROJECT: o nome do projeto do cluster padrão.
    • SHARED_CLUSTER_PROJECT: o nome do projeto de cluster compartilhado.
    • STANDARD_CLUSTER_NAME: o nome do cluster padrão.
    • SUBJECT_NAMESPACE: o namespace do assunto no cluster padrão.
    • SUBJECT_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho em questão. Por exemplo, app, tier ou role. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
    • 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 o rótulo app: backend estarão enviando o tráfego.
    • PEER_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho do mesmo nível. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
    • PEER_LABEL_VALUE: o valor associado ao PEER_LABEL_KEY.