How to use network policies in ACK clusters and common scenarios - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Pré-requisitos

Criação de um cluster gerenciado ACK ou de um cluster dedicado ACK que utilize o Terway como plug-in de rede. Para mais informações, consulte Create an ACK managed cluster e Create an ACK dedicated cluster (discontinued).
You have obtained the kubeconfig file for the cluster and used kubectl to connect to the cluster.

Observações de uso

Para utilizar network policies no console, envie uma solicitação na Quota Center console.
Não é necessário enviar solicitação caso você gerencie as network policies via linha de comando.
As regras de NetworkPolicy utilizam LabelSelectors para selecionar namespaces ou pods. No entanto, um grande volume de NetworkPolicies no cluster pode aumentar o tempo de aplicação das regras e dificultar o gerenciamento e a solução de problemas. Recomendamos criar menos de 100 NetworkPolicies no seu cluster.
Este recurso aplica-se apenas a nós que usam o plug-in CNI Terway e estão configurados no modo ENI compartilhada. Ele não é suportado em nós de uma node pool configured in exclusive ENI mode.

Este documento não aborda configurações e limitações específicas para diferentes cenários de computação. Para usar este recurso em ambientes específicos, como cloud híbrida ou instâncias elásticas, consulte a documentação do product de computação correspondente.
O ACK suporta apenas network policies padrão do Kubernetes. Não há suporte para network policies personalizadas de terceiros, como Calico ou Cilium.

Itens suportados

Ao criar um cluster, a implementação da NetworkPolicy depende da versão inicial do Terway.

1.9.0 and later

Componente	Implementação da NetworkPolicy
terway-eniip	eBPF

Importante

Para corresponder a pods dentro do cluster, utilize podSelector ou namespaceSelector. O seletor ipBlock corresponde apenas a endereços externos ao cluster.
Se o cluster foi criado com uma versão do Terway anterior à 1.9.0, a implementação da NetworkPolicy permanece inalterada mesmo após a atualização do Terway para a versão 1.9.0 ou posterior.
A implementação da NetworkPolicy baseada em eBPF exige kernel versão 4,19 ou superior. Caso a versão do kernel do nó seja inferior a 4,19, o recurso NetworkPolicy não funcionará.
As observações acima aplicam-se apenas a nós ECS regulares que executam o componente Terway. Para ative a NetworkPolicy em nós virtuais, consulte Use a network policy.

Earlier than 1.9.0

Componente	Implementação da NetworkPolicy
terway-eniip sem IPvlan ou DataPath V2 ativado	iptables
terway-eniip com IPvlan ou DataPath V2 ativado	eBPF

Importante

Utilize podSelector ou namespaceSelector para corresponder a pods dentro do cluster. Na implementação eBPF, o seletor ipBlock corresponde apenas a endereços externos ao cluster.
Caso o cluster tenha sido criado com uma versão inicial do Terway anterior à 1.9.0, a implementação da NetworkPolicy não muda, mesmo após atualizar o Terway para 1.9.0 ou superior.
A implementação da NetworkPolicy baseada em eBPF requer kernel versão 4,19 ou superior. Se a versão do kernel do nó for inferior a 4,19, o recurso NetworkPolicy reverte para o modo iptables. Observe que as regras de NetworkPolicy podem não funcionar conforme o esperado.
Essas observações valem somente para nós ECS regulares que executam o componente Terway. Para ative a NetworkPolicy em nós virtuais, veja Use a network policy.

Ativação de network policies

É possível ative network policies durante a criação do cluster ou em um cluster existente.

New clusters

Ao criar um cluster, selecione Support for NetworkPolicies para ative o recurso de network policy. Para mais detalhes, consulte Create an ACK Pro cluster.

Existing clusters

Faça login no console ACK. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique em no nome do seu cluster. No painel de navegação à esquerda, clique em Components and Add-ons .
Na aba Networking, localize o add-on terway-eniip e clique em Configuration no canto inferior direito. Selecione Enables NetworkPolicy e clique em OK.

Importante
Em clusters sem o DataPath V2 ativado, a ativação do recurso NetworkPolicy não tem efeito imediato nos nós existentes. É necessário reiniciar os nós para que as alterações entrem em vigor.

Exemplos de uso de network policy

Preparar uma aplicação de exemplo

Siga estas etapas para criar uma aplicação de teste Nginx acessível por outros pods.

Use the console

Faça login no console ACK. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique em no nome do cluster desejado e, no painel de navegação à esquerda, escolha Workloads > Deployments.

Na página Deployments, clique em Create from Image. No assistente Create, crie uma aplicação chamada nginx e exponha-a usando um Service. Após configure a aplicação, clique em Create.

Neste exemplo, configure apenas os itens abaixo para a aplicação Nginx e mantenha as configurações padrão para os demais parâmetros. Para mais detalhes sobre as configurações, consulte Create a stateless workload (Deployment).

Item de configuração		Descrição	Valor de exemplo
Basic Information	Name	Um nome personalizado.	nginx
Basic Information	Replicas	Selecione conforme necessário.	1
Container	Image Name	Nome da imagem usada para iniciar o contêiner.	nginx:latest
Advanced	Services	À direita de Services, clique em Create para defina os itens de configuração do service.	Name: nginx
			Service Type: Cluster IP SLB Node Port
			Port Mapping: Name: nginx Service Port: 80 Container Port: 80 Protocol: TCP

Na página Deployments, clique em Create from Image. No assistente Create exibido, crie uma aplicação cliente chamada busybox para testar o acesso ao Service nginx criado na etapa anterior.

Para este exemplo, configure apenas os itens a seguir para a aplicação cliente busybox e mantenha as configurações padrão para os demais parâmetros. Para mais informações sobre as configurações, consulte Create a stateless workload (Deployment).

Item de configuração		Descrição	Valor de exemplo
Basic Information	Name	Um nome personalizado.	busybox
Basic Information	Replicas	Defina um valor conforme necessário.	1
Container	Image Name	Nome da imagem usada para iniciar o contêiner.	busybox:latest
Container	Container Start Parameter	Nenhum	Selecione stdin e tty

Verifique se a aplicação cliente busybox consegue acessar o Service Nginx.
1. Na página Deployments, clique em no nome da aplicação busybox.
2. Na aba Pods, localize o pod busybox-{valor hash} e clique em Terminal na coluna Actions.
3. No terminal de linha de comando do busybox, execute o comando wget nginx para testar o acesso ao Nginx.
  
  A saída indica que o busybox consegue acessar o Service Nginx.

Use the CLI

Execute os comandos a seguir para criar uma aplicação Nginx e expô-la usando um Service chamado nginx.

Crie uma aplicação Nginx:

kubectl run nginx --image=nginx

Saída esperada:

pod/nginx created

Verifique se o pod foi iniciado:

kubectl get pod

Saída esperada:

NAME                     READY   STATUS    RESTARTS   AGE
nginx                    1/1     Running   0          45s

Crie um Service chamado nginx:

kubectl expose pod nginx --port=80

Saída esperada:

service/nginx exposed

Visualize o Service:

kubectl get service

Saída esperada:

NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   172.XX.XX.1     <none>        443/TCP   30m
nginx        ClusterIP   172.XX.XX.48    <none>        80/TCP    12s

Execute o comando a seguir para criar um pod chamado busybox e acessar o Service chamado nginx.

kubectl run busybox --rm -ti --image=busybox /bin/sh

Saída esperada:

If you don't see a command prompt, try pressing enter.
/ #
/ #

Acesse o nginx:

If you don't see a command prompt, try pressing enter.
/ #
/ # wget nginx  # Enter wget nginx here.

Saída esperada:

Connecting to nginx (172.XX.XX.48:80)
saving to 'index.html'
index.html           100% |****************************************************************************************************************************************************|   612  0:00:00 ETA
'index.html' saved

Cenário 1: Restringir o acesso ao service a aplicações com rótulos específicos usando uma network policy

Use the console

Para usar network policies no console, é necessário envie uma solicitação para inclusão na lista de permissões. Para mais informações, consulte Usage notes.

Faça login no console ACK. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique em no nome do seu cluster. No painel de navegação à esquerda, clique em Network > Network Policies.

Na página Network Policies, selecione um namespace na parte superior da página. Este exemplo utiliza o namespace default. No canto superior esquerdo, clique em Create. No painel Create, configure a política.

Parâmetro	Descrição	Valor de exemplo
Name	Um nome personalizado para a network policy.	access-nginx
Pod Selectors	Clique em + Specify workload type and labels para defina os pods aos quais a network policy se aplica. Nota Se o seletor de pod estiver vazio, a network policy será aplicada a todos os pods no namespace.	Este exemplo usa as seguintes configurações: Defina Type como Deployments Defina Workloads como nginx Defina Labels como app=nginx
Source	Cada network policy pode conter uma lista de permissões de regras de origem (ingress). Cada regra permite tráfego que corresponda tanto à regra de origem quanto à seção de porta especificada. Rule: podSelector: Este seletor escolhe pods específicos no mesmo namespace da network policy e os permite como origens para tráfego de entrada. namespaceSelector: Este seletor escolhe namespaces específicos e usa todos os pods neles contidos como origens para tráfego de entrada. ipBlock: Este seletor escolhe intervalos CIDR de IP específicos para usar como origens para tráfego de entrada. Port: Suporta protocolos TCP e UDP. Nota Se nenhuma regra for adicionada, nenhum pod terá permissão para acessar os pods selecionados. Se DataPathv2 ou IPvlan estiver ativado no cluster, não será possível usar ipBlock para restringir tráfego de blocos CIDR de pods. Use podSelector.	Este exemplo não adiciona regras de origem.
Destination	Cada network policy pode conter uma lista de permissões de regras de saída (egress). Cada regra permite tráfego que corresponda à regra de destino e à seção de porta especificada. Rule: podSelector: Este seletor escolhe pods específicos no mesmo namespace da network policy e os permite como destinos para tráfego de saída. namespaceSelector: Este seletor escolhe namespaces específicos e usa todos os pods neles contidos como destinos para tráfego de saída. ipBlock: Este seletor escolhe intervalos CIDR de IP específicos como destinos para tráfego de saída. Port: Suporta protocolos TCP e UDP. Nota Se DataPathv2 ou IPvlan estiver ativado no cluster, não será possível usar ipBlock para restringir tráfego de blocos CIDR de pods. Use podSelector.	Este exemplo não adiciona regras de destino.

Clique em Next e, em seguida, clique em OK.
No terminal de linha de comando do busybox, execute o comando wget nginx para testar o acesso ao Service nginx. Para mais informações, consulte Step 5.

O acesso expira porque a network policy não permite conexões vindas do busybox.

Modifique a network policy para permitir o acesso da aplicação busybox.

Localize a network policy access-nginx na lista de network policies e clique em Edit na coluna Actions.

Adicione uma regra de origem.

À direita de Source, clique em + Add e execute as etapas a seguir:

À direita de Rule, clique em + Add. Configure uma regra de acesso para o podSelector da seguinte forma:

Parâmetro	Exemplo
Selector	podSelector
Type	Stateless
Workload	busybox
Label	app=busybox

À direita de Port, clique em + Add e configure a porta conforme abaixo:

Parâmetro	Exemplo
Protocol	TCP
Port	80

Clique em Next e depois em OK.
Execute o comando wget -O /dev/null nginx para testar o acesso do busybox ao nginx após modifique a network policy.

Após adicionar a regra para a aplicação busybox na network policy, o busybox consegue acessar o nginx.

Use The CLI

Execute o comando vim policy.yaml para criar um arquivo chamado policy.yaml e preencha-o com o modelo YAML a seguir.

vim policy.yaml

Segue o conteúdo do arquivo YAML.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: access-nginx
spec:
  podSelector:
    matchLabels:
      run: nginx
  ingress:
  - from:
    - podSelector:
        matchLabels:
          access: "true"

Execute o comando a seguir para criar uma network policy a partir do arquivo policy.yaml.
```
kubectl apply -f policy.yaml 
```
Saída esperada:
```
networkpolicy.networking.k8s.io/access-nginx created
```
Execute os comandos a seguir para testar o acesso ao Service nginx. Como nenhum rótulo de acesso está definido, a solicitação expira.
```
kubectl run busybox --rm -ti --image=busybox /bin/sh
```
Teste o acesso ao Service nginx:
```
wget nginx
```
Saída esperada:
```
Connecting to nginx (172.19.XX.XX:80)
wget: can't connect to remote host (172.19.XX.XX): Connection timed out
```

Execute os comandos a seguir para defina o rótulo de acesso.

kubectl run busybox --rm -ti --labels="access=true" --image=busybox /bin/sh

Teste o acesso ao Service Nginx:

wget nginx

Saída esperada:

Connecting to nginx (172.21.XX.XX:80)
saving to 'index.html'
index.html           100% |****************************************************************************************************************************************************|   612  0:00:00 ETA
'index.html' saved

A saída indica que o progresso da conexão é de 100%. Isso significa que a solicitação foi bem-sucedida e o service Nginx pode ser acessado.

Cenário 2: Restringir os blocos CIDR de origem que podem acessar um service voltado para a Internet usando uma network policy

Use the console

Crie uma network policy para o Service Nginx. Para mais informações sobre as configurações, consulte Restrict service access to applications with specific labels using a network policy.
Na coluna External Endpoint da lista de services, encontre o endereço de acesso público (47.xxx.xx.x) do Service da aplicação de exemplo Nginx e acesse-o em um navegador.

O acesso falha porque a network policy nega o acesso por padrão.

Adicione um bloco CIDR permitido à network policy para liberar o acesso do cliente.

Acesse myip.ipip.net em um navegador para obter o endereço IP público da sua máquina.

Na lista de network policies, localize a policy access-nginx, clique em Edit na coluna Actions e modifique a regra no painel Edit.

À direita de Source, clique em + Add e faça o seguinte:

À direita de Rule, clique em + Add. Configure a nova regra para permitir o acesso do endereço IP da sua máquina:

Parâmetro

Exemplo

Selector

ipBlock

cidr

<Endereço IP da sua máquina>/32

Por exemplo, 42.xx.xx.xx/32

À direita de Rule, clique em + Add. Configure a regra para permitir o acesso do bloco CIDR de verificação de integridade do SLB da Alibaba Cloud:

Parâmetro	Exemplo
Selector	ipBlock
cidr	100.0.0.0/8

À direita de Port, clique em + Add e configure a porta conforme abaixo:

Parâmetro	Exemplo
Protocol	TCP
Port	80

ipblock

Clique em Next e depois em OK.
Na coluna External Endpoint da lista de services, clique em no endereço IP do endpoint externo (47.xxx.xx.x:80) para acessar o service Nginx.

Após a modificação da network policy, o cliente consegue acessar o service Nginx através do SLB voltado para a Internet.

Use the CLI

Execute o comando a seguir para criar uma instância de SLB da Alibaba Cloud para a aplicação nginx. Especifique type=LoadBalancer para expor o service nginx à Internet.

vim nginx-service.yaml

Segue o modelo para o arquivo nginx-service.yaml.

# Paste the following YAML content into nginx-service.yaml.
apiVersion: v1
kind: Service
metadata:
  labels:
    run: nginx
  name: nginx-slb
spec:
  externalTrafficPolicy: Local
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx
  type: LoadBalancer

Execute o comando a seguir para criar uma network policy a partir do arquivo nginx-service.yaml.

kubectl apply -f nginx-service.yaml

Saída esperada:

service/nginx-slb created

Verifique se a aplicação expõe o service Nginx:

kubectl get service nginx-slb

Saída esperada:

NAME        TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE
nginx-slb   LoadBalancer   172.19.xx.xxx   47.110.xxx.xxx   80:32240/TCP   8m

Execute o comando a seguir para acessar o endereço IP da instância SLB recém-criada, 47.110.xxx.xxx. O acesso falhará.
```
wget 47.110.xxx.xxx
```
Saída esperada:
```
--2018-11-21 11:46:05--  http://47.110.xx.xxx/
Connecting to 47.110.XX.XX:80... failed: Connection refused.
```
Nota
O acesso falha pelos seguintes motivos:

O Service nginx configurado só pode ser acessado por aplicações com o rótulo específico access=true.

Acessar o endereço IP da instância SLB é considerado acesso externo ao Kubernetes. Isso difere do cenário de restrição de acesso ao service para aplicações com rótulos específicos.
Solução: Modifique a network policy para adicionar o bloco CIDR de origem permitido.

Execute o comando a seguir para visualize seu endereço IP local.

curl myip.ipip.net

Saída esperada:

Current IP: 10.0.x.x From: China Beijing Beijing        # This is an example. Use the actual device information.

Execute o comando a seguir para modifique o arquivo policy.yaml.

vim policy.yaml

Modifique o arquivo policy.yaml para incluir o seguinte conteúdo:

# The following is the content of the YAML file.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: access-nginx
spec:
  podSelector:
    matchLabels:
      run: nginx
  ingress:
  - from:
    - podSelector:
        matchLabels:
          access: "true"
    - ipBlock:
        cidr: 100.64.0.0/10
    - ipBlock:
        cidr: 10.0.0.1/24      # Local IP address. This is an example. Use the actual device information.

Execute o comando a seguir para criar uma network policy a partir do arquivo policy.yaml.

kubectl apply -f policy.yaml

Saída esperada:

networkpolicy.networking.k8s.io/access-nginx unchanged

Nota

Algumas redes possuem múltiplos endereços IP de saída. Recomendamos usar um intervalo de endereços /24.
Os endereços de verificação de integridade do SLB estão no bloco CIDR 100.64.0.0/10. Portanto, é necessário adicionar 100.64.0.0/10 à lista de permissões.

Execute o comando a seguir para acessar o service Nginx.

kubectl run busybox --rm -ti --labels="access=true" --image=busybox /bin/sh

Acesse o service nginx:

wget 47.110.XX.XX

Saída esperada:

Connecting to 47.110.XX.XX (47.110.XX.XX:80)
index.html           100% |***********************************************************|   612  0:00:00 ETA

A saída indica que o progresso da conexão é de 100%. Isso significa que você acessou o service Nginx com sucesso.

Cenário 3: Restringir um pod para acessar apenas um endereço especificado usando uma network policy

Use the console

Esta seção usa www.aliyun.com e registry.aliyuncs.com como exemplos para mostrar como configure uma network policy que permita a um pod acessar apenas registry.aliyuncs.com.

Use o comando ping para consultar o endereço IP (120,55.XXX.XXX) para o qual registry.aliyuncs.com resolve.

Crie uma regra de network policy que restrinja a aplicação busybox a acessar apenas registry.aliyuncs.com.

No canto superior esquerdo da página Network Policies, clique em Create e configure a regra de network policy no painel Create.

Para mais informações sobre os parâmetros, consulte Restrict service access to applications with specific labels using a network policy. Segue um exemplo de configuração.

Parâmetro	Descrição	Exemplo
Name	Um nome personalizado para a network policy.	busybox-policy
Pod Selectors	Clique em + Specify workload type and labels para defina os pods aos quais a network policy se aplica. Nota Se o seletor de pod estiver vazio, a network policy será aplicada a todos os pods no namespace.	Este exemplo usa as seguintes configurações: Defina Type como Deployments Defina Workloads como busybox Defina Labels como app=busybox
Destination	À direita de Destination, clique em + Add e, em seguida, à direita de Rule, clique em + Add. Adicione uma regra para ipBlock com o endereço IP resolvido (120,55.XXX.XXX)/32 de registry.aliyuncs.com obtido anteriormente.	Selector: ipBlock cidr: 120,55.XXX.XXX/32
Destination	À direita de Destination, clique em + Add. Adicione uma regra para permitir acesso à porta UDP 53 para todos os namespaces, garantindo que a aplicação possa realizar resolução DNS. À direita de Rule, clique em + Add. Adicione uma regra para selecione todos os namespaces. À direita de Port, clique em + Add. Adicione uma regra para UDP 53 para garantir que a aplicação possa realizar resolução DNS.	Rule: Selector: namespaceSelector Namespace: All Port: Protocol: UDP Port: 53

Clique em Next e depois em OK.
No terminal do busybox, execute os comandos a seguir para acessar www.aliyun.com e registry.aliyuncs.com.
```
nc -vz -w 1 www.aliyunc.com 443
```
```
nc -vz -w 1 registry.aliyuncs.com 443
```
A saída mostra que, após a adição da network policy, a aplicação busybox consegue acessar apenas registry.aliyuncs.com e não consegue acessar outros endereços.

Use the CLI

Execute o comando a seguir para obter a lista de endereços IP para os quais o nome de domínio www.aliyun.com resolve.

dig +short www.aliyun.com

Saída esperada:

www-jp-de-intl-adns.aliyun.com.
www-jp-de-intl-adns.aliyun.com.gds.alibabadns.com.
v6wagbridge.aliyun.com.
v6wagbridge.aliyun.com.gds.alibabadns.com.
106.XX.XX.21
140.XX.XX.4
140.XX.XX.13
140.XX.XX.3

Crie um arquivo chamado busybox-policy.yaml.

vim busybox-policy.yaml

Use o modelo a seguir para o arquivo busybox-policy.yaml:

# The following is the content of the YAML file.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: busybox-policy
spec:
  podSelector:
    matchLabels:
      run: busybox
  egress:
  - to:
    - ipBlock:
        cidr: 106.XX.XX.21/32
    - ipBlock:
        cidr: 140.XX.XX.4/32
    - ipBlock:
        cidr: 140.XX.XX.13/32
    - ipBlock:
        cidr: 140.XX.XX.3/32
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
    - namespaceSelector: {}
    ports:
    - protocol: UDP
      port: 53

Nota

No arquivo busybox-policy.yaml, as regras de egress são configuradas para restringir o acesso de saída da aplicação. Você deve configure as regras para permitir solicitações UDP. Caso contrário, a resolução DNS falhará.

Execute o comando a seguir para criar uma network policy a partir do arquivo busybox-policy.yaml.
```
kubectl apply -f busybox-policy.yaml 
```
Saída esperada:
```
networkpolicy.networking.k8s.io/busybox-policy created
```
Execute o comando a seguir para criar um pod busybox e testar o acesso.
```
kubectl run busybox --rm -ti --image=busybox /bin/sh
```
Acesse um site diferente de www.aliyun.com, como www.taobao.com:
```
wget www.taobao.com
```
Saída esperada:
```
Connecting to www.taobao.com (64.13.XX.XX:80)
wget: can't connect to remote host (64.13.XX.XX): Connection timed out
```
A mensagem can't connect to remote host indica que o acesso falhou.

Execute o comando a seguir para acessar www.aliyun.com.

wget www.aliyun.com

Saída esperada:

Connecting to www.aliyun.com (140.205.XX.XX:80)
Connecting to www.aliyun.com (140.205.XX.XX:443)
wget: note: TLS certificate validation not implemented
index.html           100% |***********************************************************|  462k  0:00:00 ETA

A saída indica que o progresso da conexão é de 100%. Isso significa que o service foi acessado com sucesso.

Cenário 4: Controlar o acesso à rede pública para pods em um namespace usando uma network policy

Nota

Esta operação pode afetar services online que estão acessando a rede pública. Recomendamos execute as operações a seguir em um namespace vazio.

Use the console

No canto superior esquerdo da página Network Policies, clique em Create e configure a regra de network policy no painel Create.

Para mais informações sobre os parâmetros e operações, consulte Restrict service access to applications with specific labels using a network policy. Segue um exemplo de configuração.

Parâmetro	Exemplo
Name	deny-public-net
Pod Selectors	Defina Type como All.
Source	Adicione as duas regras a seguir: Defina uma regra para permitir tudo para namespaceSelector. Defina uma regra para permitir tudo para ipBlock.
Destination	Adicione uma regra que permita acesso apenas à rede interna: Defina uma regra para permitir All para namespaceSelector, permitindo que o pod acesse todos os pods na rede interna. Defina três regras para ipBlock para os três blocos CIDR de rede interna a seguir: 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 Nota Não é possível adicionar múltiplos blocos CIDR em uma única regra ipBlock.

Clique em Next e depois em OK.
Na aba Basic Information da página de detalhes do cluster, obtenha o endereço IP interno e a porta do API server.
No terminal do busybox, execute os comandos a seguir para testar o acesso do pod à rede pública e interna.
```
nc -vz -w 1 www.aliyunc.com 443
```
```
nc -vz -w 1 10.xx.xx.xx:<IP port> # This is your internal IP address.
```
A saída mostra que o pod consegue acessar apenas endereços internos e não consegue acessar endereços públicos.

Use the CLI

Execute o comando a seguir para criar um namespace de teste.
Crie um namespace chamado test-np.
```
kubectl create ns test-np
```
Saída esperada:
```
namespace/test-np created
```

Execute o comando a seguir para criar uma network policy padrão para o namespace que permita apenas acesso de saída para redes privadas.

vim default-deny.yaml

Segue um modelo de exemplo para o arquivo default-deny.yaml:

# The following is the content of the YAML file.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: test-np
  name: deny-public-net
spec:
  podSelector: {}
  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0
  egress:
  - to:
    - ipBlock:
        cidr: 192.168.0.0/16
    - ipBlock:
        cidr: 172.16.0.0/12
    - ipBlock:
        cidr: 10.0.0.0/8

Verifique se o arquivo default-deny.yaml foi criado.

kubectl apply -f default-deny.yaml

Saída esperada:

networkpolicy.networking.k8s.io/deny-public-net created

Visualize a network policy:

kubectl get networkpolicy -n test-np

Saída esperada:

NAME                              POD-SELECTOR          AGE
deny-public-net                   <none>                1m

Execute o comando a seguir para criar uma network policy que permita aos pods com um rótulo específico acessar a rede pública.

vim allow-specify-label.yaml

Neste exemplo, o rótulo é public-network=true.

# The following is the content of the YAML file.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-public-network-for-labels
  namespace: test-np
spec:
  podSelector:
    matchLabels:
      public-network: "true"
  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
    - namespaceSelector:
        matchLabels:
          ns: kube-system  # Allows pods to access key services in kube-system (such as CoreDNS). This is an example. Configure as needed.

Execute o comando a seguir para criar a network policy:

kubectl apply -f allow-specify-label.yaml

Saída esperada:

networkpolicy.networking.k8s.io/allow-public-network-for-labels created

Visualize a network policy:

kubectl get networkpolicy -n test-np

Saída esperada:

NAME                              POD-SELECTOR          AGE
allow-public-network-for-labels   public-network=true    1m
deny-public-net                   <none>                 3m

Execute os comandos a seguir para verifique se um pod sem o rótulo especial não consegue acessar a rede pública.
```
kubectl run -it --namespace test-np --rm --image registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28 busybox-intranet
```
```
ping aliyun.com
```
Saída esperada:
```
PING aliyun.com (106.11.2xx.xxx): 56 data bytes
^C
--- aliyun.com ping statistics ---
9 packets transmitted, 0 packets received, 100% packet loss
```
A mensagem 0 packets received indica que o acesso falhou.

Nota
O acesso falhou porque a network policy deny-public-net restringe o acesso à rede pública para pods no namespace test-np por padrão. Portanto, pods iniciados neste namespace com rótulos padrão não conseguem acessar a rede pública.

Execute o comando a seguir para verifique se um pod com o rótulo public-network=true consegue acessar a rede pública.

kubectl run -it --namespace test-np --labels public-network=true --rm --image registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/busybox:1.28 busybox-internet

ping aliyun.com

Saída esperada:

PING aliyun.com (106.11.1xx.xx): 56 data bytes
64 bytes from 106.11.1xx.xx: seq=0 ttl=47 time=4.235 ms
64 bytes from 106.11.1xx.xx: seq=1 ttl=47 time=4.200 ms
64 bytes from 106.11.1xx.xx: seq=2 ttl=47 time=4.182 ms
^C
--- aliyun.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 4.182/4.205/4.235 ms

A mensagem 0% packet loss indica que o service foi acessado com sucesso.

Nota

O acesso é bem-sucedido porque a network policy allow-public-network-for-labels permite acesso à rede pública para pods com o rótulo public-network=true. Portanto, o pod busybox-internet, que possui esse rótulo, consegue acessar a rede pública.