在 Azure Kubernetes 服务 (AKS) 中使用网络策略保护 Pod 之间的流量Secure traffic between pods using network policies in Azure Kubernetes Service (AKS)

在 Kubernetes 中运行最新的基于微服务的应用程序时,通常想要控制哪些组件可以相互通信。When you run modern, microservices-based applications in Kubernetes, you often want to control which components can communicate with each other. 对于在 Azure Kubernetes 服务 (AKS) 群集中的 Pod 之间流量的流动方式,应该应用最低特权原则。The principle of least privilege should be applied to how traffic can flow between pods in an Azure Kubernetes Service (AKS) cluster. 假设你要阻止流量直接流入后端应用程序。Let's say you likely want to block traffic directly to back-end applications. 在 Kubernetes 中,使用“网络策略”可在群集中定义用于 Pod 之间的入口和出口流量的规则。The Network Policy feature in Kubernetes lets you define rules for ingress and egress traffic between pods in a cluster.

本文介绍如何安装网络策略引擎,并创建 Kubernetes 网络策略来控制 AKS 中 Pod 之间的流量流动方式。This article shows you how to install the network policy engine and create Kubernetes network policies to control the flow of traffic between pods in AKS. 应该只对 AKS 中基于 Linux 的节点和 Pod 使用网络策略。Network policy should only be used for Linux-based nodes and pods in AKS.

准备阶段Before you begin

需要安装并配置 Azure CLI 2.0.61 或更高版本。You need the Azure CLI version 2.0.61 or later installed and configured. 运行  az --version 即可查找版本。Run az --version to find the version. 如果需要进行安装或升级,请参阅 安装 Azure CLIIf you need to install or upgrade, see Install Azure CLI.

提示

如果你在预览期使用了网络策略功能,则我们建议创建新的群集If you used the network policy feature during preview, we recommend that you create a new cluster.

如果你想要继续使用现有的测试群集,而这些群集在预览期使用了网络策略,请将群集升级到适用于最新正式版的新 Kubernetes 版本,然后部署以下 YAML 清单,以修复崩溃指标服务器和 Kubernetes 仪表板。If you wish to continue using existing test clusters that used network policy during preview, upgrade your cluster to a new Kubernetes versions for the latest GA release and then deploy the following YAML manifest to fix the crashing metrics server and Kubernetes dashboard. 只有使用 Calico 网络策略引擎的群集才需要进行这种修复。This fix is only required for clusters that used the Calico network policy engine.

作为安全最佳做法,请查看此 YAML 清单的内容,以了解 AKS 群集中部署的内容。As a security best practice, review the contents of this YAML manifest to understand what is deployed into the AKS cluster.

kubectl delete -f https://raw.githubusercontent.com/Azure/aks-engine/master/docs/topics/calico-3.3.1-cleanup-after-upgrade.yaml

网络策略概述Overview of network policy

默认情况下,AKS 群集中的所有 Pod 可以无限制地发送和接收流量。All pods in an AKS cluster can send and receive traffic without limitations, by default. 为了提高安全性,可定义用来控制流量流的规则。To improve security, you can define rules that control the flow of traffic. 例如,后端应用程序通常只向所需的前端服务公开。Back-end applications are often only exposed to required front-end services, for example. 或者,数据库组件只能由连接到它们的应用层访问。Or, database components are only accessible to the application tiers that connect to them.

网络策略是一种 Kubernetes 规范,其中针对 Pod 之间的通信定义了访问策略。Network Policy is a Kubernetes specification that defines access policies for communication between Pods. 使用网络策略可以定义有关发送和接收流量的有序规则集,并将其应用到与一个或多个标签选择器相匹配的 Pod 集合。Using Network Policies, you define an ordered set of rules to send and receive traffic and apply them to a collection of pods that match one or more label selectors.

这些网络策略规则定义为 YAML 清单。These network policy rules are defined as YAML manifests. 可以包含网络策略作为也会创建部署或服务的更丰富清单的一部分。Network policies can be included as part of a wider manifest that also creates a deployment or service.

AKS 中的网络策略选项Network policy options in AKS

Azure 提供两种方式来实现网络策略。Azure provides two ways to implement network policy. 可以在创建 AKS 群集时选择一个网络策略选项。You choose a network policy option when you create an AKS cluster. 创建群集后无法更改策略选项:The policy option can't be changed after the cluster is created:

  • Azure 自身的实现,称为“Azure 网络策略”。Azure's own implementation, called Azure Network Policies.
  • Calico 网络策略 - 由 Tigera 建立的开源网络和网络安全解决方案。Calico Network Policies, an open-source network and network security solution founded by Tigera.

这两个实现都使用 Linux IPTables 来实施指定的策略。Both implementations use Linux IPTables to enforce the specified policies. 策略将转换为一系列允许和禁止的 IP 对。Policies are translated into sets of allowed and disallowed IP pairs. 然后,这些对将编程为 IPTable 筛选规则。These pairs are then programmed as IPTable filter rules.

Azure 与 Calico 策略及其功能之间的差异Differences between Azure and Calico policies and their capabilities

功能Capability AzureAzure CalicoCalico
支持的平台Supported platforms LinuxLinux LinuxLinux
支持的网络选项Supported networking options Azure CNIAzure CNI Azure CNI 和 kubenetAzure CNI and kubenet
符合 Kubernetes 规范Compliance with Kubernetes specification 支持的所有策略类型All policy types supported 支持的所有策略类型All policy types supported
其他功能Additional features None 扩展的策略模型,包括全局网络策略、全局网络集和主机终结点。Extended policy model consisting of Global Network Policy, Global Network Set, and Host Endpoint. 有关使用 calicoctl CLI 管理这些扩展功能的详细信息,请参阅 calicoctl 用户参考For more information on using the calicoctl CLI to manage these extended features, see calicoctl user reference.
支持Support 由 Azure 支持部门和工程团队提供支持Supported by Azure support and Engineering team 由 Azure 社区提供支持。Calico community support. 有关其他付费支持的详细信息,请参阅 Project Calico 支持选项For more information on additional paid support, see Project Calico support options.
日志记录Logging 在 IPTables 中添加/删除的规则将记录到每个主机上的 /var/log/azure-npm.log 下。Rules added / deleted in IPTables are logged on every host under /var/log/azure-npm.log 有关详细信息,请参阅 Calico 组件日志For more information, see Calico component logs

创建 AKS 群集并启用网络策略Create an AKS cluster and enable network policy

为了了解网络策略的运行方式,让我们创建然后扩展一个定义流量流的策略:To see network policies in action, let's create and then expand on a policy that defines traffic flow:

  • 拒绝流向 Pod 的所有流量。Deny all traffic to pod.
  • 允许基于 Pod 标签的流量。Allow traffic based on pod labels.
  • 允许基于命名空间的流量。Allow traffic based on namespace.

首先,让我们创建一个支持网络策略的 AKS 群集。First, let's create an AKS cluster that supports network policy.

重要

只能在创建群集时启用网络策略功能。The network policy feature can only be enabled when the cluster is created. 无法在现有 AKS 群集上启用网络策略。You can't enable network policy on an existing AKS cluster.

若要使用 Azure 网络策略,必须使用 Azure CNI 插件并定义自己的虚拟网络和子网。To use Azure Network Policy, you must use the Azure CNI plug-in and define your own virtual network and subnets. 有关如何规划所需子网范围的更多详细信息,请参阅配置高级网络For more detailed information on how to plan out the required subnet ranges, see configure advanced networking. Calico 网络策略可与此 Azure CNI 插件配合使用,也可与 Kubenet CNI 插件配合使用。Calico Network Policy could be used with either this same Azure CNI plug-in or with the Kubenet CNI plug-in.

以下示例脚本:The following example script:

  • 创建虚拟网络和子网。Creates a virtual network and subnet.
  • 创建用于 AKS 群集的 Azure Active Directory (Azure AD) 服务主体。Creates an Azure Active Directory (Azure AD) service principal for use with the AKS cluster.
  • 对虚拟网络的 AKS 服务主体授予“参与者”权限。Assigns Contributor permissions for the AKS cluster service principal on the virtual network.
  • 在定义的虚拟网络中创建 AKS 群集并启用网络策略。Creates an AKS cluster in the defined virtual network and enables network policy.
    • 系统使用 Azure 网络策略选项。The Azure Network policy option is used. 若要改用 Calico 作为网络策略选项,请使用 --network-policy calico 参数。To use Calico as the network policy option instead, use the --network-policy calico parameter. 注意:Calico 既可与 --network-plugin azure 一起使用,也可与 --network-plugin kubenet 一起使用。Note: Calico could be used with either --network-plugin azure or --network-plugin kubenet.

请注意,可以使用托管标识而不是服务主体来获得权限。Note that instead of using a service principal, you can use a managed identity for permissions. 有关详细信息,请参阅使用托管标识For more information, see Use managed identities.

提供自己的安全 SP_PASSWORD。Provide your own secure SP_PASSWORD. 可以替换 RESOURCE_GROUP_NAMECLUSTER_NAME 变量:You can replace the RESOURCE_GROUP_NAME and CLUSTER_NAME variables:

RESOURCE_GROUP_NAME=myResourceGroup-NP
CLUSTER_NAME=myAKSCluster
LOCATION=chinaeast2

# Create a resource group
az group create --name $RESOURCE_GROUP_NAME --location $LOCATION

# Create a virtual network and subnet
az network vnet create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name myVnet \
    --address-prefixes 10.0.0.0/8 \
    --subnet-name myAKSSubnet \
    --subnet-prefix 10.240.0.0/16

# Create a service principal and read in the application ID
SP=$(az ad sp create-for-rbac --output json)
SP_ID=$(echo $SP | jq -r .appId)
SP_PASSWORD=$(echo $SP | jq -r .password)

# Wait 15 seconds to make sure that service principal has propagated
echo "Waiting for service principal to propagate..."
sleep 15

# Get the virtual network resource ID
VNET_ID=$(az network vnet show --resource-group $RESOURCE_GROUP_NAME --name myVnet --query id -o tsv)

# Assign the service principal Contributor permissions to the virtual network resource
az role assignment create --assignee $SP_ID --scope $VNET_ID --role Contributor

# Get the virtual network subnet resource ID
SUBNET_ID=$(az network vnet subnet show --resource-group $RESOURCE_GROUP_NAME --vnet-name myVnet --name myAKSSubnet --query id -o tsv)

# Create the AKS cluster and specify the virtual network and service principal information
# Enable network policy by using the `--network-policy` parameter
az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --generate-ssh-keys \
    --network-plugin azure \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --docker-bridge-address 172.17.0.1/16 \
    --vnet-subnet-id $SUBNET_ID \
    --service-principal $SP_ID \
    --client-secret $SP_PASSWORD \
    --network-policy azure

创建群集需要几分钟时间。It takes a few minutes to create the cluster. 群集准备就绪后,使用 az aks get-credentials 命令将 kubectl 配置为连接到 Kubernetes 群集。When the cluster is ready, configure kubectl to connect to your Kubernetes cluster by using the az aks get-credentials command. 此命令将下载凭据,并将 Kubernetes CLI 配置为使用这些凭据:This command downloads credentials and configures the Kubernetes CLI to use them:

az aks get-credentials --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME

拒绝流向 Pod 的所有入站流量Deny all inbound traffic to a pod

定义规则以允许特定网络流量之前,请首先创建用于拒绝所有流量的网络策略。Before you define rules to allow specific network traffic, first create a network policy to deny all traffic. 使用此策略,可为你提供起始点,仅为所需的流量创建允许列表。This policy gives you a starting point to begin to create an allow list for only the desired traffic. 此外,还可清楚看到,应用网络策略后,相关流量被丢弃。You can also clearly see that traffic is dropped when the network policy is applied.

对于示例应用程序环境和流量规则,让我们先创建名为 development 的命名空间,以运行示例 Pod:For the sample application environment and traffic rules, let's first create a namespace called development to run the example pods:

kubectl create namespace development
kubectl label namespace/development purpose=development

创建运行 NGINX 的示例后端 Pod。Create an example back-end pod that runs NGINX. 此后端 Pod 可用于模拟基于 Web 的示例后端应用程序。This back-end pod can be used to simulate a sample back-end web-based application. 在 development 命名空间中创建此 Pod,并且打开端口 80,以提供 Web 流量 。Create this pod in the development namespace, and open port 80 to serve web traffic. 将 Pod 贴上标签:app=webapp,role=backend,以便我们可在下一节中使用网络策略定向到它:Label the pod with app=webapp,role=backend so that we can target it with a network policy in the next section:

kubectl run backend --image=nginx --labels app=webapp,role=backend --namespace development --expose --port 80 --generator=run-pod/v1

创建另一个 Pod 并附加终端会话,以测试是否可以成功访问默认的 NGINX 网页:Create another pod and attach a terminal session to test that you can successfully reach the default NGINX webpage:

kubectl run --rm -it --image=alpine network-policy --namespace development --generator=run-pod/v1

在 shell 提示符下,使用 wget 确认是否可以访问默认的 NGINX 网页:At the shell prompt, use wget to confirm that you can access the default NGINX webpage:

wget -qO- http://backend

以下示例输出显示了返回的默认 NGINX 网页:The following sample output shows that the default NGINX webpage returned:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

退出附加的终端会话。Exit out of the attached terminal session. 测试 Pod 将自动删除。The test pod is automatically deleted.

exit

创建并应用网络策略Create and apply a network policy

确认可以在示例后端 Pod 上使用基本的 NGINX 网页后,接下来请创建一个拒绝所有流量的网络策略。Now that you've confirmed you can use the basic NGINX webpage on the sample back-end pod, create a network policy to deny all traffic. 创建名为 backend-policy.yaml 的文件并粘贴以下 YAML 清单。Create a file named backend-policy.yaml and paste the following YAML manifest. 此清单使用 podSelector 将策略附加到具有 app:webapp,role:backend 标签的 Pod,类似于示例 NGINX Pod。This manifest uses a podSelector to attach the policy to pods that have the app:webapp,role:backend label, like your sample NGINX pod. 入口下未定义任何规则,因此将拒绝流向 Pod 的所有入站流量:No rules are defined under ingress, so all inbound traffic to the pod is denied:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
  namespace: development
spec:
  podSelector:
    matchLabels:
      app: webapp
      role: backend
  ingress: []

使用 kubectl apply 命令应用网络策略,并指定 YAML 清单的名称:Apply the network policy by using the kubectl apply command and specify the name of your YAML manifest:

kubectl apply -f backend-policy.yaml

测试网络策略Test the network policy

让我们看看是否可以在后端 Pod 上再次使用 NGINX 网页。Let's see if you can use the NGINX webpage on the back-end pod again. 创建另一个测试 Pod,并附加一个终端会话:Create another test pod and attach a terminal session:

kubectl run --rm -it --image=alpine network-policy --namespace development --generator=run-pod/v1

在 shell 提示符下,使用 wget 确认是否可以访问默认的 NGINX 网页。At the shell prompt, use wget to see if you can access the default NGINX webpage. 这一次,将超时值设为 2 秒。This time, set a timeout value to 2 seconds. 网络策略现在会阻止所有入站流量,因此无法加载页面,如以下示例中所示:The network policy now blocks all inbound traffic, so the page can't be loaded, as shown in the following example:

wget -qO- --timeout=2 http://backend
wget: download timed out

退出附加的终端会话。Exit out of the attached terminal session. 测试 Pod 将自动删除。The test pod is automatically deleted.

exit

允许基于 Pod 标签的入站流量Allow inbound traffic based on a pod label

在上一部分,我们已计划了一个后端 NGINX Pod,并创建了拒绝所有流量的网络策略。In the previous section, a back-end NGINX pod was scheduled, and a network policy was created to deny all traffic. 让我们创建一个前端 Pod,并更新网络策略以允许来自前端 Pod 的流量。Let's create a front-end pod and update the network policy to allow traffic from front-end pods.

更新网络策略,以允许来自具有标签 app:webapp,role:frontend 的 Pod 和任何命名空间的流量。Update the network policy to allow traffic from pods with the labels app:webapp,role:frontend and in any namespace. 编辑前面所述的 backend-policy.yaml 文件,并添加 matchLabels 入口规则,使清单如以下示例所示:Edit the previous backend-policy.yaml file, and add matchLabels ingress rules so that your manifest looks like the following example:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
  namespace: development
spec:
  podSelector:
    matchLabels:
      app: webapp
      role: backend
  ingress:
  - from:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          app: webapp
          role: frontend

备注

此网络策略使用 namespaceSelector 和 podSelector 元素作为入口规则 。This network policy uses a namespaceSelector and a podSelector element for the ingress rule. YAML 语法对于入口规则的严格性非常重要。The YAML syntax is important for the ingress rules to be additive. 在此示例中,两个元素必须匹配要应用的入口规则。In this example, both elements must match for the ingress rule to be applied. 低于 1.12 的 Kubernetes 版本可能无法正确解释这些元素和按预期限制网络流量。Kubernetes versions prior to 1.12 might not interpret these elements correctly and restrict the network traffic as you expect. 有关此行为的详细信息,请参阅目标和来源选择器的行为For more about this behavior, see Behavior of to and from selectors.

使用 kubectl apply 命令应用已更新的网络策略,并指定 YAML 清单的名称:Apply the updated network policy by using the kubectl apply command and specify the name of your YAML manifest:

kubectl apply -f backend-policy.yaml

计划带有 app=webapp,role=frontend 标签的 Pod,并附加终端会话:Schedule a pod that is labeled as app=webapp,role=frontend and attach a terminal session:

kubectl run --rm -it frontend --image=alpine --labels app=webapp,role=frontend --namespace development --generator=run-pod/v1

在 shell 提示符下,使用 wget 确认是否可以访问默认的 NGINX 网页:At the shell prompt, use wget to see if you can access the default NGINX webpage:

wget -qO- http://backend

由于入口规则允许带有标签 app: webapp,role: frontend 的 Pod 的流量,因此允许来自前端 Pod 的流量。Because the ingress rule allows traffic with pods that have the labels app: webapp,role: frontend, the traffic from the front-end pod is allowed. 以下示例输出显示了返回的默认 NGINX 网页:The following example output shows the default NGINX webpage returned:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

退出附加的终端会话。Exit out of the attached terminal session. 该 Pod 将自动删除。The pod is automatically deleted.

exit

测试没有匹配标签的 PodTest a pod without a matching label

网络策略允许来自标记为 app: webapp,role: frontend 的 Pod 的流量,但应拒绝其他所有流量。The network policy allows traffic from pods labeled app: webapp,role: frontend, but should deny all other traffic. 让我们看看不带这些标签的另一个 Pod 是否可以访问后端 NGINX Pod。Let's test to see whether another pod without those labels can access the back-end NGINX pod. 创建另一个测试 Pod,并附加一个终端会话:Create another test pod and attach a terminal session:

kubectl run --rm -it --image=alpine network-policy --namespace development --generator=run-pod/v1

在 shell 提示符下,使用 wget 确认是否可以访问默认的 NGINX 网页。At the shell prompt, use wget to see if you can access the default NGINX webpage. 网络策略将阻止入站流量,因此无法加载页面,如以下示例所示:The network policy blocks the inbound traffic, so the page can't be loaded, as shown in the following example:

wget -qO- --timeout=2 http://backend
wget: download timed out

退出附加的终端会话。Exit out of the attached terminal session. 测试 Pod 将自动删除。The test pod is automatically deleted.

exit

仅允许来自定义命名空间的流量Allow traffic only from within a defined namespace

在前面的示例中,你已创建拒绝所有流量的网络策略,然后更新了该策略,以允许来自具有特定标签的 Pod 的流量。In the previous examples, you created a network policy that denied all traffic, and then updated the policy to allow traffic from pods with a specific label. 另一个常见需求是将流量限制在给定的命名空间内。Another common need is to limit traffic to only within a given namespace. 如果前面的示例适用于 development 命名空间中的流量,请创建一个网络策略用于阻止来自另一命名空间(例如 production)的流量访问 Pod。If the previous examples were for traffic in a development namespace, create a network policy that prevents traffic from another namespace, such as production, from reaching the pods.

首先,创建新的命名空间,模拟生产命名空间:First, create a new namespace to simulate a production namespace:

kubectl create namespace production
kubectl label namespace/production purpose=production

在具有标签 app=webapp,role=frontend 的 production 命名空间中计划测试 Pod 。Schedule a test pod in the production namespace that is labeled as app=webapp,role=frontend. 附加终端会话:Attach a terminal session:

kubectl run --rm -it frontend --image=alpine --labels app=webapp,role=frontend --namespace production --generator=run-pod/v1

在 shell 提示符下,使用 wget 确认是否可以访问默认的 NGINX 网页:At the shell prompt, use wget to confirm that you can access the default NGINX webpage:

wget -qO- http://backend.development

由于 Pod 的标签匹配网络策略中当前允许的内容,因此允许该流量。Because the labels for the pod match what is currently permitted in the network policy, the traffic is allowed. 网络策略不会查看命名空间,只有 Pod 标签会查看。The network policy doesn't look at the namespaces, only the pod labels. 以下示例输出显示了返回的默认 NGINX 网页:The following example output shows the default NGINX webpage returned:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

退出附加的终端会话。Exit out of the attached terminal session. 测试 Pod 将自动删除。The test pod is automatically deleted.

exit

更新网络策略Update the network policy

让我们更新入口规则 namespaceSelector 节,以仅允许来自 development 命名空间内部的流量。Let's update the ingress rule namespaceSelector section to only allow traffic from within the development namespace. 编辑 backend-policy.yaml 清单文件,如以下示例所示:Edit the backend-policy.yaml manifest file as shown in the following example:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
  namespace: development
spec:
  podSelector:
    matchLabels:
      app: webapp
      role: backend
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: development
      podSelector:
        matchLabels:
          app: webapp
          role: frontend

在更复杂的示例中,可以定义多个入口规则,例如,分别指定 namespaceSelectorpodSelectorIn more complex examples, you could define multiple ingress rules, like a namespaceSelector and then a podSelector.

使用 kubectl apply 命令应用已更新的网络策略,并指定 YAML 清单的名称:Apply the updated network policy by using the kubectl apply command and specify the name of your YAML manifest:

kubectl apply -f backend-policy.yaml

测试更新后的网络策略Test the updated network policy

production 命名空间中计划另一个 Pod,并附加终端会话:Schedule another pod in the production namespace and attach a terminal session:

kubectl run --rm -it frontend --image=alpine --labels app=webapp,role=frontend --namespace production --generator=run-pod/v1

在 shell 提示符下,使用 wget 查看目前拒绝流量的网络策略:At the shell prompt, use wget to see that the network policy now denies traffic:

wget -qO- --timeout=2 http://backend.development
wget: download timed out

退出测试 Pod:Exit out of the test pod:

exit

拒绝来自 production 命名空间的流量后,在 development 命名空间中计划一个测试 Pod,并附加终端会话:With traffic denied from the production namespace, schedule a test pod back in the development namespace and attach a terminal session:

kubectl run --rm -it frontend --image=alpine --labels app=webapp,role=frontend --namespace development --generator=run-pod/v1

在 shell 提示符下,使用 wget 查看允许流量的网络策略:At the shell prompt, use wget to see that the network policy allows the traffic:

wget -qO- http://backend

之所以允许流量,是因为该 Pod 计划在匹配网络策略中允许的内容的命名空间中。Traffic is allowed because the pod is scheduled in the namespace that matches what's permitted in the network policy. 以下示例输出显示了返回的默认 NGINX 网页:The following sample output shows the default NGINX webpage returned:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

退出附加的终端会话。Exit out of the attached terminal session. 测试 Pod 将自动删除。The test pod is automatically deleted.

exit

清理资源Clean up resources

在本文中,我们创建了两个命名空间并应用了一个网络策略。In this article, we created two namespaces and applied a network policy. 若要清理这些资源,请使用 kubectl delete 命令并指定资源名称:To clean up these resources, use the kubectl delete command and specify the resource names:

kubectl delete namespace production
kubectl delete namespace development

后续步骤Next steps

有关网络资源的详细信息,请参阅 Azure Kubernetes 服务 (AKS) 中应用程序的网络概念For more about network resources, see Network concepts for applications in Azure Kubernetes Service (AKS).

若要详细了解策略,请参阅 Kubernetes 网络策略To learn more about policies, see Kubernetes network policies.